A csillagséma és a Power BI-ban játszott szerepének a bemutatásaUnderstand star schema and the importance for Power BI

Ez a cikk a Power BI Desktopot használó adatmodellezőknek szól.This article targets Power BI Desktop data modelers. Ismerteti a csillagséma tervezését és annak jelentőségét a teljesítményre és használhatóságra optimalizált Power BI-adatmodellek fejlesztésében.It describes star schema design and its relevance to developing Power BI data models optimized for performance and usability.

A cikknek nem célja a csillagséma tervezésének teljes körű leírása.This article isn't intended to provide a complete discussion on star schema design. Részletesebb tudnivalókat olyan nyilvánosan közzétett tartalmakban találhat, mint az Adattárház eszközkészlet: Részletes útmutató a dimenzionális modellezéshez (3. kiadás, 2013) [Ralph Kimball et al.]For more details, refer directly to published content, like The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd edition, 2013) by Ralph Kimball et al.

A csillagséma áttekintéseStar schema overview

A csillagséma a relációs adattárházakhoz gyakran használt, fejlett modellezési megközelítés.Star schema is a mature modeling approach widely adopted by relational data warehouses. Használatához a modellezőknek a dimenzió vagy a tény kategóriába kell besorolniuk a modelltáblákat.It requires modelers to classify their model tables as either dimension or fact.

A dimenziótáblák üzleti entitásokat – a modellben lévő dolgokat – írják le.Dimension tables describe business entities—the things you model. Az entitások lehetnek termékek, személyek, helyek és fogalmak, akár maga az idő is.Entities can include products, people, places, and concepts including time itself. Egy csillagséma legkonzisztensebb táblája egy dátum-dimenziótábla lehet.The most consistent table you'll find in a star schema is a date dimension table. A dimenziótáblák egyedi azonosítóként szolgáló kulcsoszlopot (vagy kulcsoszlopokat), valamint leíró oszlopokat tartalmaznak.A dimension table contains a key column (or columns) that acts as a unique identifier, and descriptive columns.

A ténytáblák megfigyeléseket vagy eseményeket tárolnak, és lehetnek például értékesítési rendelések, készletegyenlegek, árfolyamok, hőmérsékletek stb. A ténytáblák a dimenziótáblákhoz kapcsolódó dimenziókulcs-oszlopokat, valamint numerikus mértékoszlopokat tartalmaznak.Fact tables store observations or events, and can be sales orders, stock balances, exchange rates, temperatures, etc. A fact table contains dimension key columns that relate to dimension tables, and numeric measure columns. A dimenziós kulcsoszlopok határozzák meg egy ténytábla dimenziószámát a dimenziókulcs értékek pedig egy ténytábla részletességét.The dimension key columns determine the dimensionality of a fact table, while the dimension key values determine the granularity of a fact table. Tekintsünk például egy értékesítési célok tárolására tervezett ténytáblát, amelynek két dimenziókulcs-oszlopa a Date (dátum) és a ProductKey (termékazonosító).For example, consider a fact table designed to store sale targets that has two dimension key columns Date and ProductKey. Nyilvánvaló, hogy a tábla kétdimenziós.It's easy to understand that the table has two dimensions. A részletessége azonban nem határozható meg a dimenziókulcs értékek figyelembe vétele nélkül.The granularity, however, can't be determined without considering the dimension key values. Tekintsük úgy, hogy a példánkban a Date oszlopban tárolt értékek az egyes hónapok első napjának felelnek meg.In this example, consider that the values stored in the Date column are the first day of each month. Ebben az esetben a részletesség hónap-termék szintű.In this case, the granularity is at month-product level.

A dimenziótáblák általában viszonylag kevés sorból állnak.Generally, dimension tables contain a relatively small number of rows. A ténytáblák viszont rengeteg sort tartalmazhatnak, és idővel egyre növekedhetnek.Fact tables, on the other hand, can contain a very large number of rows and continue to grow over time.

Csillagséma bemutató ábra

A csillagséma jelentősége a Power BI-modellek számáraStar schema relevance to Power BI models

A csillagséma szerinti tervezés és az ebben a cikkben bemutatott számos kapcsolódó fogalom kitűnően alkalmazható a teljesítményre és használhatóságra optimalizált Power BI-adatmodellek fejlesztésében.Star schema design and many related concepts introduced in this article are highly relevant to developing Power BI models that are optimized for performance and usability.

Figyelembe kell venni, hogy minden Power BI-jelentésbeli vizualizáció lekérdezést generál, amely (a Power BI szolgáltatásban adathalmaznak nevezett) Power BI-modellhez van továbbítva.Consider that each Power BI report visual generates a query that is sent to the Power BI model (which the Power BI service calls a dataset). Ezek a lekérdezések használhatók a modell adatainak szűrésére, csoportosítására és összegzésére.These queries are used to filter, group, and summarize model data. A jól megtervezett modellek tehát azok, amelyek biztosítanak szűrésre, csoportosításra és összegzésre szolgáló táblákat is.A well-designed model, then, is one that provides tables for filtering and grouping, and tables for summarizing. Ez a kialakítás összhangban van a csillagséma alapelveivel:This design fits well with star schema principles:

  • A dimenziótáblák a szűrést és a csoportosítást támogatjákDimension tables support filtering and grouping
  • A ténytáblák az összegzést támogatjákFact tables support summarization

A táblának nincs a modellező által megadható beállítása, amellyel a tábla típusa (dimenzió vagy tény) konfigurálható.There's no table property that modelers set to configure the table type as dimension or fact. Ezt a modellen belüli kapcsolatok határozzák meg.It's in fact determined by the model relationships. Egy modellbeli kapcsolat szűrőátadási útvonalat hoz létre két tábla között, a tábla típusát pedig ennek a kapcsolatnak a Számosság tulajdonsága határozza meg.A model relationship establishes a filter propagation path between two tables, and it's the Cardinality property of the relationship that determines the table type. Gyakori kapcsolatszámosság az egy-a-többhöz, vagy a több-az-egyhez.A common relationship cardinality is one-to-many or its inverse many-to-one. Az „egy” oldal mindig dimenzió típusú tábla, a „több” oldal pedig mindig tény típusú tábla.The "one" side is always a dimension-type table while the "many" side is always a fact-type table. További információ a kapcsolatokról: Modellkapcsolatok a Power BI Desktopban.For more information about relationships, see Model relationships in Power BI Desktop.

Elvi csillagséma

Egy jól felépített modellnek olyan táblákból kell állnia, amelyek mindegyike vagy dimenzió típusú, vagy tény típusú.A well-structured model design should include tables that are either dimension-type tables or fact-type tables. Kerülje a két típus egy táblán belüli keverését.Avoid mixing the two types together for a single table. Ugyanakkor arra is ajánlott törekedni, hogy a megfelelő számú táblát biztosítsa a megfelelő kapcsolatokkal.We also recommend that you should strive to deliver the right number of tables with the right relationships in place. Az is lényeges, hogy a tény típusú táblákban következetes részletességgel legyenek betöltve az adatok.It's also important that fact-type tables always load data at a consistent grain.

Végül azzal is fontos tisztában lenni, hogy az optimális modell megtervezése félig tudomány, és félig művészet.Lastly, it's important to understand that optimal model design is part science and part art. Olykor, ha a józan ész ezt diktálja, az amúgy jó irányelvekkel is szabad szakítani.Sometimes you can break with good guidance when it makes sense to do so.

Egy Power BI-modellben a csillagséma-kialakítással kapcsolatos sok további fogalom is hasznosítható.There are many additional concepts related to star schema design that can be applied to a Power BI model. Ezek a fogalmak a következők:These concepts include:

MértékekMeasures

Csillagséma kialakításánál a mérték egy táblabeli oszlopot jelent, amely összesítendő adatokat tartalmaz.In star schema design, a measure is a fact table column that stores values to be summarized.

A Power BI-modellekben a mérték definíciója más, de ehhez hasonló.In a Power BI model, a measure has a different—but similar—definition. Egy adatelemzési kifejezésként (DAX) megírt képlet, amely elvégzi az összesítést.It's a formula written in Data Analysis Expressions (DAX) that achieves summarization. A mértékkifejezések gyakran hasznosítanak olyan összesítési DAX-függvényeket, mint a SUM, MIN, MAX, AVERAGE stb., így skaláris értéket állítva elő a lekérdezés idejére (az értékek soha nincsenek a modellben tárolva).Measure expressions often leverage DAX aggregation functions like SUM, MIN, MAX, AVERAGE, etc. to produce a scalar value result at query time (values are never stored in the model). A mértékkifejezések egy oszlop egyszerű összegzésétől olyan kidolgozott képletekig terjedhetnek, amelyek felülírják a szűrési környezetet és/vagy a kapcsolatok továbbítását.Measure expression can range from simple column aggregations to more sophisticated formulas that override filter context and/or relationship propagation. További információt A DAX alapjai a Power BI Desktopban című cikkben találhat.For more information, read the DAX Basics in Power BI Desktop article.

Fontos tudnivaló, hogy a Power BI-modellek egy másféle összegzési módot is támogatnak.It's important to understand that Power BI models support a second method for achieving summarization. Bármely – általában numerikus – oszlop összegezhető jelentésbeli vizualizáció vagy Q&A használatával.Any column—and typically numeric columns—can be summarized by a report visual or Q&A. Ezeket az oszlopokat implicit mértékeknek nevezzük.These columns are referred to as implicit measures. Ez kényelmes megoldás a modellfejlesztők számára, mert sokszor szükségtelenné teszi a mértékek létrehozását.They offer a convenience for you as a model developer, as in many instances you do not need to create measures. Az Adventure Works viszonteladói értékesítéseinek Értékesítési összeg oszlopa például többféleképpen összesíthető (összeg, darabszám, átlag, medián, minimum, maximum stb.) anélkül, hogy minden lehetséges összesítési típushoz külön mértéket kellene létrehozni.For example, the Adventure Works reseller sales Sales Amount column could be summarized in numerous ways (sum, count, average, median, min, max, etc.), without the need to create a measure for each possible aggregation type.

Példaikon a mezőlistában

A mértékek létrehozása mellett azonban még egyszerű, oszlopszintű összegzések esetén is három meggyőző érv szól:However, there are three compelling reasons for you to create measures, even for simple column-level summarizations:

  • Ha tudja, hogy a jelentéskészítők többdimenziós kifejezések (MDX) használatával fogják lekérdezni a modellt, akkor a modellnek explicit mértékeket kell tartalmaznia.When you know your report authors will query the model by using Multidimensional Expressions (MDX), the model must include explicit measures. Az explicit mértékek meghatározása a DAX segítségével történik.Explicit measures are defined by using DAX. Ez a tervezési megközelítés különösen fontos, ha Power BI-adatkészleteket kérdez le az MDX használatával, mivel az MDX nem tudja elérni az oszlopok értékeinek összegzését.This design approach is highly relevant when a Power BI dataset is queried by using MDX, because MDX can't achieve summarization of column values. A rendszer az MDX-et használja az Excelben való elemzéshez mert a kimutatások MDX-lekérdezéseket adnak ki.Notably, MDX will be used when performing Analyze in Excel, because PivotTables issue MDX queries.
  • Ha tudja, hogy a jelentésszerzők lapszámozott Power BI-jelentéseket fognak létrehozni az MDX-lekérdezéstervezővel, a modellnek explicit mértékeket kell tartalmaznia.When you know your report authors will create Power BI paginated reports using the MDX query designer, the model must include explicit measures. Csak az MDX-lekérdezéstervező támogatja a kiszolgálói összesítéseket.Only the MDX query designer supports server aggregates. Ha tehát a jelentéskészítőknek a Power BI (és nem a lapszámozott jelentések motorja) által kiértékelt mértékekre van szükségük, az MDX-lekérdezéstervezőt kell használniuk.So, if report authors need to have measures evaluated by Power BI (instead of by the paginated report engine), they must use the MDX query designer.
  • Ha biztosítania kell, hogy a jelentéskészítők csak bizonyos módokon összegezhessenek oszlopokat.When you need to ensure that your report authors can only summarize columns in specific ways. A viszonteladói értékesítések Egységár oszlopa (amely az egységenkénti árat jelenti) összesíthető, de csak meghatározott összesítő függvényekkel.For example, the reseller sales Unit Price column (which represents a per unit rate) can be summarized, but only by using specific aggregation functions. Összeadni értelmetlen, más összesítő függvényekkel (például minimum, maximum, átlag stb.) viszont összesíthető. Ebben az esetben a modellező elrejtheti az Egységár oszlopot, és mértékeket hozhat létre az összes megfelelő összesítő függvényhez.It should never be summed, but it's appropriate to summarize by using other aggregation functions like min, max, average, etc. In this instance, the modeler can hide the Unit Price column, and create measures for all appropriate aggregation functions.

Ez a kialakítási elv jól megfelel a Power BI szolgáltatásban készített jelentésekhez és a Q&A-hoz.This design approach works well for reports authored in the Power BI service and for Q&A. A Power BI Desktop élő kapcsolatai viszont lehetővé teszik, hogy a jelentéskészítők felfedjék a rejtett mezőket a Mezők panelen, ezáltal megkerüljék a tervező szándékát.However, Power BI Desktop live connections allow report authors to show hidden fields in the Fields pane, which can result in circumventing this design approach.

Helyettes kulcsokSurrogate keys

A helyettes kulcs egyedi azonosító, amelyet a csillagséma-modell támogatása érdekében vehet fel egy táblához.A surrogate key is a unique identifier that you add to a table to support star schema modeling. Definíció szerint nem a forrásadatokban van meghatározva vagy tárolva.By definition, it's not defined or stored in the source data. A helyettes kulcsok általában a relációs adattárházak dimenziótábláihoz vannak felvéve, hogy a dimenziótábla minden sorának egyedi azonosítót biztosítsanak.Commonly, surrogate keys are added to relational data warehouse dimension tables to provide a unique identifier for each dimension table row.

A Power BI-modell kapcsolatai egy tábla egyetlen egyedi oszlopán alapulnak, amely egy másik tábla egy oszlopára viszi át a szűrőket.Power BI model relationships are based on a single unique column in one table, which propagates filters to a single column in a different table. Ha a modell egy dimenzió típusú táblája nem tartalmaz egy egyedi oszlopot, akkor Önnek kell egyedi azonosítót hozzáadnia, hogy az egy kapcsolat „egy” oldala lehessen.When a dimension-type table in your model doesn't include a single unique column, you must add a unique identifier to become the "one" side of a relationship. A Power BI Desktopban ennek a követelménynek egyszerűen eleget tehet egy Power Query-indexoszlop létrehozásával.In Power BI Desktop, you can easily achieve this requirement by creating a Power Query index column.

Indexoszlop létrehozása a Power Query-eszköztárban

Ezt a lekérdezést a „több”-oldali lekérdezéssel kell egyesítenie, hogy ahhoz is hozzáadhassa az indexoszlopot.You must merge this query with the "many"-side query so that you can add the index column to it also. Miután ezeket a lekérdezéseket betölti a modellbe, egy-a-többhöz kapcsolatot hozhat létre a modellbeli táblák között.When you load these queries to the model, you can then create a one-to-many relationship between the model tables.

Hópehely dimenziókSnowflake dimensions

Egy hópehely dimenzió egyetlen üzleti entitáshoz tartozó normalizált táblák halmaza.A snowflake dimension is a set of normalized tables for a single business entity. Az Adventure Works például kategóriákba és alkategóriákba sorolja a termékeket.For example, Adventure Works classifies products by category and subcategory. Az alkategóriák kategóriákhoz vannak rendelve, a termékek pedig alkategóriákhoz.Categories are assigned to subcategories, and products are in turn assigned to subcategories. Az Adventure Works relációs adattárházban a termékdimenzió normalizálva van, és három kapcsolódó táblában van tárolva: DimProductCategory, DimProductSubcategory és DimProduct.In the Adventure Works relational data warehouse, the product dimension is normalized and stored in three related tables: DimProductCategory, DimProductSubcategory, and DimProduct.

Egy kis képzelőerővel a normalizált táblák elhelyezhetők a ténytáblától kifelé haladva egy hópihe ágaihoz hasonlóan.If you use your imagination, you can picture the normalized tables positioned outwards from the fact table, forming a snowflake design.

Példa hópehelydiagramra

A Power BI Desktopban választhat, hogy utánozza a hópehely dimenzió kialakítását (esetleg azért, mert a forrásadatok ilyenek), vagy egyetlen modelltáblába integrálja (denormalizálja) a forrástáblákat.In Power BI Desktop, you can choose to mimic a snowflake dimension design (perhaps because your source data does) or integrate (denormalize) the source tables into a single model table. Az egyetlen modelltábla általában több előnnyel jár, mint a több modelltábla használata.Generally, the benefits of a single model table outweigh the benefits of multiple model tables. Az optimális választás az adattömeg méretétől és a modellel szembeni használhatósági követelményektől függhet.The most optimal decision can depend on the volumes of data and the usability requirements for the model.

Ha a hópehely dimenzió kialakítás másolása mellett dönt:When you choose to mimic a snowflake dimension design:

  • A Power BI több táblát tölt be, ez pedig kevésbé hatékony a tárolás és a teljesítmény szempontjából.Power BI loads more tables, which is less efficient from storage and performance perspectives. Ezeknek a tábláknak tartalmazniuk kell a modellbeli kapcsolatokat támogató oszlopokat, emiatt a modell mérete nagyobb lehet.These tables must include columns to support model relationships, and it can result in a larger model size.
  • A szűrőket hosszabb kapcsolati láncokon kell továbbadni, ez pedig feltehetően kevésbé hatékony az egyetlen táblára alkalmazott szűrőknél.Longer relationship filter propagation chains will need to be traversed, which will likely be less efficient than filters applied to a single table.
  • A Mezők panel több modellbeli táblát kínál fel a jelentéskészítőknek, ez pedig kevésbé áttekinthető felületet eredményezhet, különösen akkor, ha a hópehely dimenziótáblák csak egy vagy két oszlopból állnak.The Fields pane presents more model tables to report authors, which can result in a less intuitive experience, especially when snowflake dimension tables contain just one or two columns.
  • Nem lehet az összes táblára kiterjedő hierarchiát létrehozni.It's not possible to create a hierarchy that spans the tables.

Ha az egyetlen modelltáblába integrálása mellett dönt, meghatározhat egy hierarchiát is, amely a dimenzió legnagyobb és legkisebb részletességét is magában foglalja.When you choose to integrate into a single model table, you can also define a hierarchy that encompasses the highest and lowest grain of the dimension. A redundáns denormalizált adatok tárolása a modell megnövekedett tárigényéhez vezethet, főleg nagyon nagy dimenziótáblák esetén.Possibly, the storage of redundant denormalized data can result in increased model storage size, particularly for very large dimension tables.

Dimenzión belüli hierarchia

Lassan változó dimenziókSlowly changing dimensions

Lassan változó dimenzió (SCD) az, amely megfelelően kezeli a dimenziótagok időbeli változását.A slowly changing dimension (SCD) is one that appropriately manages change of dimension members over time. Akkor használatos, amikor az üzleti entitások értékei időben, alkalmi jelleggel változnak.It applies when business entity values change over time, and in an ad hoc manner. Lassan változó dimenzióra jó példa az ügyféldimenzió, különösen az olyan kapcsolattartási adatok oszlopai, mint az e-mail-cím és a telefonszám.A good example of a slowly changing dimension is a customer dimension, specifically its contact detail columns like email address and phone number. Ezzel ellentétben egyes dimenziókat gyorsan változónak nevezünk, ha egy dimenzióattribútum gyakran változik. Ilyen például egy tőzsdepiaci ár.In contrast, some dimensions are considered to be rapidly changing when a dimension attribute changes often, like a stock's market price. Az általános tervezési irányelv ilyen esetekben az, hogy a gyorsan változó attribútumértékeket egy ténytáblabeli mértékben tárolnak.The common design approach in these instances is to store rapidly changing attribute values in a fact table measure.

A csillagséma-tervezés elmélete a lassan változó dimenzió két gyakori típusát különbözteti meg: 1. típust és 2. típust.Star schema design theory refers to two common SCD types: Type 1 and Type 2. Egy dimenzió típusú tábla lehet 1. típusú, 2. típusú, vagy támogathatja mindkét típust egyszerre különböző oszlopoknál.A dimension-type table could be Type 1 or Type 2, or support both types simultaneously for different columns.

1. típusú lassan változó dimenzió (SCD)Type 1 SCD

Egy 1. típusú lassan változó dimenzió a legutóbbi értékeket tükrözi, és a forrásadatok változásának észlelésekor a dimenziótábla adatai felül lesznek írva.A Type 1 SCD always reflects the latest values, and when changes in source data are detected, the dimension table data is overwritten. Ez a tervezési megközelítés kiegészítő adatokat, például egy ügyfél e-mail-címét vagy telefonszámát tartalmazó oszlopoknál gyakori.This design approach is common for columns that store supplementary values, like the email address or phone number of a customer. Amikor egy ügyfél e-mail-címe vagy telefonszáma megváltozik, a dimenziótábla az új értékekkel frissíti az ügyfél sorát.When a customer email address or phone number changes, the dimension table updates the customer row with the new values. Mintha az ügyfél kapcsolattartási adatai mindig ezek lettek volna.It's as if the customer always had this contact information.

A Power BI-modell dimenzió típusú tábláinak nem növekményes frissítése 1. típusú lassan változó dimenziót eredményez.A non-incremental refresh of a Power BI model dimension-type table achieves the result of a Type 1 SCD. A táblabeli adatok frissítésével biztosítja a legújabb értékek betöltését.It refreshes the table data to ensure the latest values are loaded.

2. típusú lassan változó dimenzió (SCD)Type 2 SCD

A 2. típusú lassan változó dimenzió támogatja a dimenziótagok verziószámozását.A Type 2 SCD supports versioning of dimension members. Ha a forrásrendszer nem tárol verziókat, akkor általában az adattárház betöltési folyamata észleli a változásokat, és kezeli ennek megfelelően a változást a dimenziótáblákban.If the source system doesn't store versions, then it's usually the data warehouse load process that detects changes, and appropriately manages the change in a dimension table. Ilyen esetben a dimenziótáblának helyettes kulcs használatával kell egyedi hivatkozást biztosítania a dimenziótag egy verziójára.In this case, the dimension table must use a surrogate key to provide a unique reference to a version of the dimension member. Olyan oszlopokat is tartalmaz, amelyek meghatározzák a verzió érvényességi időtartományát (például KezdoDatum és LejaratDatum), és esetleg egy jelzőoszlopot (például Aktuális), amellyel egyszerűbb az aktuális dimenziótagok szűrése.It also includes columns that define the date range validity of the version (for example, StartDate and EndDate) and possibly a flag column (for example, IsCurrent) to easily filter by current dimension members.

Az Adventure Works például értékesítőket rendel ki egy értékesítési régióba.For example, Adventure Works assigns salespeople to a sales region. Amikor egy értékesítő régiót változtat, ennek az értékesítőnek egy új verzióját kell létrehozni, hogy a tényelőzmények továbbra is megmaradjanak a korábbi régióval társítva.When a salesperson relocates region, a new version of the salesperson must be created to ensure that historical facts remain associated with the former region. Egy értékesítő értékesítéseinek pontos, előzményeket is felölelő elemzésének támogatásához a dimenziótáblának az értékesítők és a hozzájuk társított régiók több verzióját kell tartalmaznia.To support accurate historic analysis of sales by salesperson, the dimension table must store versions of salespeople and their associated region(s). A táblának kezdő- és záródátum-értékeket is tartalmaznia kell az érvényességi idő meghatározásához.The table should also include start and end date values to define the time validity. Az aktuális verziókhoz meghatározhat üres záródátum (például 9999.12.31.), ezzel jelezve, hogy ez a sor az aktuális verzió.Current versions may define an empty end date (or 12/31/9999), which indicates that the row is the current version. A táblának helyettes kulcsot is definiálnia kell, hiszen az üzleti kulcs (ebben az esetben az alkalmazott-azonosító) nem lesz egyedi.The table must also define a surrogate key because the business key (in this instance, employee ID) won't be unique.

Fontos szem előtt tartani, hogy ha a forrásadatok nem tárolnak verziókat, köztes rendszert (például adattárházat) kell használni a változások észleléséhez és tárolásához.It's important to understand that when the source data doesn't store versions, you must use an intermediate system (like a data warehouse) to detect and store changes. A táblabetöltés folyamatának a meglévő adatok megőrzése mellett kell észlelnie a változásokat.The table load process must preserve existing data and detect changes. Változás észlelésekor a táblabetöltési folyamat lejárttá kell tennie az aktuális verziót.When a change is detected, the table load process must expire the current version. Ezen változások rögzítéséhez frissíti az EndDate értékét, és új verziót szúr be a korábbi EndDate értékéből származtatott StartDate értékkel.It records these changes by updating the EndDate value and inserting a new version with the StartDate value commencing from the previous EndDate value. A kapcsolódó tényeknek ugyanakkor időalapú kereséssel kell lekérniük a tény dátuma szempontjából lényeges dimenzió kulcsértékét.Also, related facts must use a time-based lookup to retrieve the dimension key value relevant to the fact date. Egy Power Queryt használó Power BI-modell erre nem alkalmas.A Power BI model using Power Query can't produce this result. Képes viszont adatokat betölteni egy előre betöltött 2. típusú lassan változó dimenziótáblából.It can, however, load data from a pre-loaded SCD Type 2 dimension table.

A Power BI-modellnek támogatnia kell egy tag előzményadatainak változástól független lekérdezését, valamint a tag egy verziójának lekérdezését, amely a tag abban az időpontban aktuális állapotát adja meg.The Power BI model should support querying historical data for a member, regardless of change, and for a version of the member, which represents a particular state of the member in time. Az Adventure Works esetén ez a kialakítás lehetővé teszi az értékesítő lekérdezését a hozzárendelt értékesítési régiótól függetlenül, vagy az értékesítő egy adott verziójának lekérdezését.In the context of Adventure Works, this design enables you to query the salesperson regardless of assigned sales region, or for a particular version of the salesperson.

A követelmény teljesítéséhez a Power BI-modell dimenzió típusú táblájának tartalmaznia kell egy oszlopot az értékesítő szűréséhez, valamint egy további oszlopot az értékesítő adott verziójának szűréséhez.To achieve this requirement, the Power BI model dimension-type table must include a column for filtering the salesperson, and a different column for filtering a specific version of the salesperson. Lényeges, hogy a verzióoszlop egyértelmű leírást adjon, például „Michael Blythe (2008.12.15.–2019.06.26.)”, vagy „Michael Blythe (aktuális)”.It's important that the version column provides a non-ambiguous description, like "Michael Blythe (12/15/2008-06/26/2019)" or "Michael Blythe (current)". Az is fontos, hogy a jelentések készítői és felhasználói elsajátítsák a 2. típusú lassan változó dimenzió alapelveit, és hogy hogyan állíthatnak elő megfelelő jelentésterveket a helyes szűrők alkalmazásával.It's also important to educate report authors and consumers about the basics of SCD Type 2, and how to achieve appropriate report designs by applying correct filters.

Ajánlott tervezési eljárás egy olyan hierarchia beépítése, amellyel a vizualizációk verziószintű részletezést végezhetnek.It's also a good design practice to include a hierarchy that allows visuals to drill down to the version level.

Példahierarchia a mezőlistában

Példahierarchia kimenete

Többszerepű dimenziókRole-playing dimensions

Többszerepű az a dimenzió, amely képes eltérő módon szűrni a kapcsolódó tényeket.A role-playing dimension is a dimension that can filter related facts differently. Az Adventure Worksnél például a dátumdimenzió-táblának három kapcsolata vagy a viszonteladói értékesítési tényekkel.For example, at Adventure Works, the date dimension table has three relationships to the reseller sales facts. Ugyanaz a dimenziótábla használható a tények megrendelési dátum, szállítási dátum vagy teljesítési dátum szerinti szűréséhez.The same dimension table can be used to filter the facts by order date, ship date, or delivery date.

Egy adattárházban a bevett tervezési módszer egyetlen dátumdimenzió-tábla definiálása.In a data warehouse, the accepted design approach is to define a single date dimension table. Lekérdezéskor a dátumdimenzió „szerepét” az határozza meg, hogy melyik tényoszlop van a táblák összekapcsolására használva.At query time, the "role" of the date dimension is established by which fact column you use to join the tables. Ha az értékesítéseket például a megrendelés dátuma alapján elemzik, a tábla kapcsolata a viszonteladói értékesítések megrendelési dátum oszlopával áll kapcsolatban.For example, when you analyze sales by order date, the table join relates to the reseller sales order date column.

A Power BI-modellben ez a kialakítás két tábla között több kapcsolat létrehozásával utánozható.In a Power BI model, this design can be imitated by creating multiple relationships between two tables. Az Adventure Works példájában a dátum és a viszonteladói értékesítés tábla között három kapcsolat volna.In the Adventure Works example, the date and reseller sales tables would have three relationships. Bár ez a kialakítás lehetséges, fontos tisztában lenni azzal, hogy a Power BI-modellek két táblája között csak egy aktív kapcsolat lehet.While this design is possible, it's important to understand that there can only be one active relationship between two Power BI model tables. A többi kapcsolatot inaktívra kell beállítani.All remaining relationships must be set to inactive. Az, hogy csak egyetlen aktív kapcsolat van, azzal jár, hogy alapértelmezett szűrőtovábbítás áll fenn a dátum és a viszonteladói értékesítések között.Having a single active relationship means there is a default filter propagation from date to reseller sales. Ebben a esetben az aktív kapcsolat a jelentések által leggyakrabban használt szűrőre van beállítva, amely az Adventure Worksnél a megrendelés dátuma szerinti kapcsolat.In this instance, the active relationship is set to the most common filter that is used by reports, which at Adventure Works is the order date relationship.

Példa egyetlen többszerepű dimenzióra és kapcsolatokra

Inaktív kapcsolat csak a USERELATIONSHIP függvényt használó DAX-kifejezés definiálásával használható.The only way to use an inactive relationship is to define a DAX expression that uses the USERELATIONSHIP function. Példánkban a modell fejlesztőjének mértékeket kell létrehoznia, hogy lehetővé tegye a viszonteladói értékesítések szállítási dátum és teljesítési dátum szerinti elemzését.In our example, the model developer must create measures to enable analysis of reseller sales by ship date and delivery date. Ez a munka körülményes lehet, különösen akkor, ha a viszonteladói tábla sok mértéket definiál.This work can be tedious, especially when the reseller table defines many measures. Ezáltal a Mezők panel is zsúfolttá válik a rengeteg mérték miatt.It also creates Fields pane clutter, with an overabundance of measures. Más korlátozások is érvényben vannak:There are other limitations, too:

  • Ha a jelentéskészítők mértékek definiálása helyett az oszlopok összesítésére alapoznak, akkor jelentésszintű mérték megírása nélkül nem érhetnek el az inaktív kapcsolatokra épülő összesítést.When report authors rely on summarizing columns, rather than defining measures, they can't achieve summarization for the inactive relationships without writing a report-level measure. Jelentésszintű mértékek csak akkor definiálhatók, ha a jelentéseket a Power BI Desktopban készítik.Report-level measures can only be defined when authoring reports in Power BI Desktop.
  • Mivel a dátum és a viszonteladói értékesítések között csak egy aktív kapcsolat van, a viszonteladói értékesítéseket nem lehet egyidejűleg különböző típusú dátumok szerint szűrni.With only one active relationship path between date and reseller sales, it's not possible to simultaneously filter reseller sales by different types of dates. Nem állítható elő például olyan vizualizáció, amely a megrendelési dátumokat ábrázol kiszállítási dátum szerint.For example, you can't produce a visual that plots order date sales by shipped sales.

Ezeknek a korlátozásoknak a leküzdésére gyakori Power BI-modellezési technika, hogy minden egyes szerephez külön dimenzió típusú táblát hoznak létre.To overcome these limitations, a common Power BI modeling technique is to create a dimension-type table for each role-playing instance. A további dimenziótáblák általában számított táblákként vannak létrehozva, DAX használatával.You typically create the additional dimension tables as calculated tables, using DAX. Számított táblák használatával a modell tartalmazhat egy Dátum táblát, egy Kiszállítási dátum táblát és egy Teljesítési dátum táblát, amelyek mindegyikének egyetlen és aktív kapcsolata van a viszonteladói értékesítés tábla megfelelő oszlopával.Using calculated tables, the model can contain a Date table, a Ship Date table and a Delivery Date table, each with a single and active relationship to their respective reseller sales table columns.

Példa többszerepű dimenziókra és kapcsolatokra

Ez a tervezési megközelítés nem igényli több mérték definiálását a különböző szerepű dátumokhoz, és lehetővé teszi a különböző szerepű dátumok szerinti egyidejű szűrést.This design approach doesn't require you to define multiple measures for different date roles, and it allows simultaneous filtering by different date roles. Ez azonban azzal a csekély áldozattal jár, hogy a dátum dimenziótábla több példánya miatt nő a tárolandó modell mérete.A minor price to pay, however, with this design approach is that there will be duplication of the date dimension table resulting in an increased model storage size. Mivel a dimenziótáblák többnyire kevesebb sorból állnak, mint a tény típusú táblák, ez ritkán okoz gondot.As dimension-type tables typically store fewer rows relative to fact-type tables, it is rarely a concern.

Ha minden szerephez külön dimenzió típusú táblát hoz létre, kövesse az alábbi ajánlott eljárásokat:Observe the following good design practices when you create model dimension-type tables for each role:

  • Gondoskodjon róla, hogy az oszlopok neve érthető legyen.Ensure that the column names are self-describing. Bár megengedett, hogy mindegyik dátumtábla tartalmazzon egy Év oszlopot (az oszlopnevek a táblán belül egyediek), ez a vizualizációk alapértelmezett címeiben nem lesz egyértelmű.While it's possible to have a Year column in all date tables (column names are unique within their table), it's not self-describing by default visual titles. Érdemes mindegyik dimenziótábla oszlopait átnevezni, így például a Kiszállítási dátum táblázat év oszlopának neve lehet Kiszállítási év stb.Consider renaming columns in each dimension role table, so that the Ship Date table has a year column named Ship Year, etc.
  • Ahol alkalmazható, ott gondoskodjon a táblák érthető (a Mezők panel elemleírásaiban elérhető) leírásáról, amely a szűrők továbbadásának konfigurálásáról tájékoztatja a jelentéskészítőket.When relevant, ensure that table descriptions provide feedback to report authors (through Fields pane tooltips) about how filter propagation is configured. Ez az egyértelműség akkor lényeges, ha a modell egy általános elnevezésű táblát (például Dátum) is tartalmaz, amely több tény típusú tábla szűrésére is használatos.This clarity is important when the model contains a generically named table, like Date, which is used to filter many fact-type tables. Ha ez a tábla például a viszonteladói értékesítések megrendelési dátum oszlopával áll aktív kapcsolatban, ajánlott a következőhöz hasonló leírást megadni: „Megrendelési dátum szerint szűri a viszonteladói értékesítéseket”.In the case that this table has, for example, an active relationship to the reseller sales order date column, consider providing a table description like "Filters reseller sales by order date".

További információ: Útmutató aktív vagy inaktív kapcsolatokhoz.For more information, see Active vs inactive relationship guidance.

Vegyes dimenziókJunk dimensions

A vegyes dimenziók kevés dimenzió esetén hasznosak, főleg akkor, ha ezek kevés (esetleg egy) attribútumból állnak, és ezeknek az attribútumoknak kevés értéke van.A junk dimension is useful when there are many dimensions, especially consisting of few attributes (perhaps one), and when these attributes have few values. Erre jó jelölt a rendelés állapota oszlop, vagy az ügyfelek demográfiai oszlopai (nem, korcsoport stb.).Good candidates include order status columns, or customer demographic columns (gender, age group, etc.).

Egy vegyes dimenzió tervezési célja sok „kis” dimenzió egyetlen dimenzióba egyesítése, ezzel csökkentve a modell tárolási méretét, és kevesebb modelltábla előállításával a Mezők panel zsúfoltságát is.The design objective of a junk dimension is to consolidate many "small" dimensions into a single dimension to both reduce the model storage size and also reduce Fields pane clutter by surfacing fewer model tables.

Egy vegyes dimenziótábla általában az összes dimenzióattribútum-tag keresztszorzata egy helyettes kulcs oszloppal kiegészítve.A junk dimension table is typically the Cartesian product of all dimension attribute members, with a surrogate key column. A helyettes kulcs biztosít egyedi hivatkozást a tábla egyes soraira.The surrogate key provides a unique reference to each row in the table. A dimenzió felépíthető egy adattárházban, vagy egy Power Query használatával létrehozott lekérdezéssel, amely teljes külső lekérdezési összekapcsolást végez, majd beszúr egy helyettes kulcsot (indexoszlopot).You can build the dimension in a data warehouse, or by using Power Query to create a query that performs full outer query joins, then adds a surrogate key (index column).

Példa vegyes dimenzióra

Ezt a lekérdezést kell dimenzió típusú táblaként betölteni a modellbe.You load this query to the model as a dimension-type table. A lekérdezést a ténylekérdezéssel is egyesíteni kell, hogy az indexoszlop be legyen töltve a modellbe és támogassa egy „egy-a-többhöz” modellkapcsolat létrehozását.You also need to merge this query with the fact query, so the index column is loaded to the model to support the creation of a "one-to-many" model relationship.

Ténybe ágyazott dimenziókDegenerate dimensions

Egy ténybe ágyazott dimenzió a ténytábla olyan attribútumára hivatkozik, amely szűréshez szükséges.A degenerate dimension refers to an attribute of the fact table that is required for filtering. Az Adventure Works esetében erre jó példa az értékesítési rendelésszám.At Adventure Works, the reseller sales order number is a good example. Ilyen helyzetben tervezési szempontból nincs értelme ebből az egy oszlopból álló független táblát létrehozni, mert az növelné a modell tárolási méretét, és zsúfolttá tenné a Mezők panelt.In this case, it doesn't make good model design sense to create an independent table consisting of just this one column, because it would increase the model storage size and result in Fields pane clutter.

A Power BI-modellben az értékesítési rendelésszám oszlopát érdemesebb lehet a tény típusú táblába felvenni, hogy szűrni és csoportosítani lehessen az értékesítési rendelésszám szerint.In the Power BI model, it can be appropriate to add the sales order number column to the fact-type table to allow filtering or grouping by sales order number. Ez egy kivétel a korábban ismertetett szabály alól, amely szerint a táblatípusok nem keverendők (tehát a modell tábláinak általában vagy dimenzió, vagy tény típusúnak kell lenniük).It is an exception to the formerly introduced rule that you should not mix table types (generally, model tables should be either dimension-type or fact-type).

Példa ténybe ágyazott dimenzióra

Ha azonban az Adventure Works viszonteladói táblája rendelésszám és sorszám oszlopot is tartalmaz, és ezek szükségesek a szűréshez, érdemes lehet ténybe ágyazott dimenziótáblát használni.However, if the Adventure Works resellers sales table has order number and order line number columns, and they're required for filtering, a degenerate dimension table would be a good design. További információ: Útmutató egy-az-egyhez kapcsolatokhoz (Ténybe ágyazott dimenziók).For more information, see One-to-one relationship guidance (Degenerate dimensions).

Tények nélküli ténytáblákFactless fact tables

A tények nélküli tény típusú táblák nem tartalmaznak mértékoszlopot.A factless fact table doesn't include any measure columns. Csak dimenziókulcsokat tartalmaznak.It contains only dimension keys.

Egy tények nélküli ténytáblában dimenziókulcsok által meghatározott megfigyelések tárolhatók.A factless fact table could store observations defined by dimension keys. Ilyen például, hogy egy adott dátum egy adott időpontjában egy adott ügyfél bejelentkezett a webhelyre.For example, at a particular date and time, a particular customer logged into your web site. Definiálható egy mérték, amely a tény nélküli ténytábla sorait számolja meg annak elemzéséhez, hogy mikor hány ügyfél jelentkezett be.You could define a measure to count the rows of the factless fact table to perform analysis of when and how many customers have logged in.

A tény nélküli ténytáblák felhasználásának egy érdekesebb módja a dimenziók közötti kapcsolatok tárolása. Ezt a megközelítést javasoljuk Power BI-modell tervezésekor a több-a-többhöz kapcsolatok definiálására.A more compelling use of a factless fact table is to store relationships between dimensions, and it's the Power BI model design approach we recommend defining many-to-many dimension relationships. Több-a-többhöz kapcsolat tervezésekor a tény nélküli ténytáblát áthidaló táblának nevezzük.In a many-to-many dimension relationship design, the factless fact table is referred to as a bridging table.

Tegyük fel például, hogy az értékesítők egy vagy több értékesítési régióhoz is hozzárendelhetők.For example, consider that salespeople can be assigned to one or more sales regions. Az áthidaló tábla tények nélküli ténytáblaként volna megtervezve, amely két oszlopot tartalmaz: értékesítőazonosító és régióazonosító.The bridging table would be designed as a factless fact table consisting of two columns: salesperson key and region key. Mindkét oszlopban tárolhatók ismétlődő értékek.Duplicate values can be stored in both columns.

Példa tények nélküli ténytáblára

A több-a-többhöz kapcsolat tervezésének ez a módja jól dokumentált, és áthidaló tábla nélkül is megvalósítható.This many-to-many design approach is well documented, and it can be achieved without a bridging table. Két dimenzió kapcsolata esetén mégis az áthidaló tábla használata ajánlott.However, the bridging table approach is considered the best practice when relating two dimensions. További információ: Útmutató a több-a-többhöz kapcsolatokhoz (Két dimenziótábla összekapcsolása).For more information, see Many-to-many relationship guidance (Relate two dimension-type tables).

Következő lépésekNext steps

Csillagséma vagy Power BI-modell tervezéséről a következő cikkekből tájékozódhat bővebben:For more information about star schema design or Power BI model design, see the following articles: