Vysvetlenie hviezdicovej schémy a jej dôležitosti pre Power BIUnderstand star schema and the importance for Power BI

Tento článok je určený pre modelárov údajov v aplikácii Power BI Desktop.This article targets Power BI Desktop data modelers. Popisuje sa v ňom návrh hviezdicovej schémy a jej význam pre vývoj dátových modelov Power BI optimalizovaných z hľadiska výkonu a použiteľnosti.It describes star schema design and its relevance to developing Power BI data models optimized for performance and usability.

Cieľom tohto článku nie je poskytnúť kompletné informácie o návrhu hviezdicovej schémy.This article isn't intended to provide a complete discussion on star schema design. Ďalšie podrobnosti nájdete priamo v publikovanom obsahu, napríklad: The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (Súprava nástrojov skladu údajov: Definitívny sprievodca dimenzionálnym modelovaním) (3. vydanie, 2013), Ralph Kimball a kol.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.

Prehľad o hviezdicovej schémeStar schema overview

Hviezdicová schéma predstavuje pokročilý prístup k modelovaniu, často používaný v skladoch relačných údajov.Star schema is a mature modeling approach widely adopted by relational data warehouses. Vyžaduje sa, aby modelári klasifikovali svoje tabuľky modelov ako tabuľku dimenzií alebo tabuľku faktov.It requires modelers to classify their model tables as either dimension or fact.

Tabuľky dimenzií popisujú podnikové entity – objekty, ktoré modelujete.Dimension tables describe business entities—the things you model. Entity môžu zahŕňať produkty, ľudí, miesta a koncepty vrátane samotného času.Entities can include products, people, places, and concepts including time itself. Najkonzistentnejšia tabuľka, ktorú vo hviezdicovej schéme nájdete, je dátumová tabuľka dimenzií.The most consistent table you'll find in a star schema is a date dimension table. Tabuľka dimenzií obsahuje kľúčový stĺpec (alebo stĺpce), ktorý sa správa ako jedinečný identifikátor, a tiež popisné stĺpce.A dimension table contains a key column (or columns) that acts as a unique identifier, and descriptive columns.

Tabuľky faktov ukladajú pozorovania alebo udalosti a môže ísť o predajné objednávky, zostatky skladových zásob, výmenné kurzy, teploty atď. Tabuľka faktov obsahuje kľúčové stĺpce dimenzií, ktoré sa vzťahujú na tabuľky dimenzií, a tiež číselné stĺpce mierky.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. Kľúčové stĺpce dimenzií určujú dimenzionalitu tabuľky faktov, zatiaľ čo kľúčové hodnoty dimenzií určujú granularitu tabuľky faktov.The dimension key columns determine the dimensionality of a fact table, while the dimension key values determine the granularity of a fact table. Ako príklad si vezmime tabuľku faktov určenú na ukladanie cieľov predaja, ktorá má dva kľúčové stĺpce dimenzií, a to Date (Dátum) a ProductKey.For example, consider a fact table designed to store sale targets that has two dimension key columns Date and ProductKey. Pochopiť to, že má tabuľka dve dimenzie, je jednoduché.It's easy to understand that the table has two dimensions. Granularitu však nie je možné určiť bez toho, aby sa zohľadnili kľúčové hodnoty dimenzie.The granularity, however, can't be determined without considering the dimension key values. V tomto príklade je potrebné vziať do úvahy, že hodnoty uložené v stĺpci Date (Dátum) predstavujú prvé dni jednotlivých mesiacov.In this example, consider that the values stored in the Date column are the first day of each month. V tomto prípade je granularita na úrovni produktov za mesiac.In this case, the granularity is at month-product level.

Tabuľky dimenzií vo všeobecnosti obsahujú relatívne malý počet riadkov.Generally, dimension tables contain a relatively small number of rows. Naopak, tabuľky faktov môžu obsahovať veľmi veľký počet riadkov a v priebehu času môžu naďalej rásť.Fact tables, on the other hand, can contain a very large number of rows and continue to grow over time.

Ilustrácia hviezdicovej schémy

Význam hviezdicovej schémy pre modely v službe Power BIStar schema relevance to Power BI models

Návrh hviezdicovej schémy a mnohé súvisiace koncepty predstavené v tomto článku majú veľký význam pre vývoj modelov Power BI, ktoré sú optimalizované z hľadiska výkonu a použiteľnosti.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.

Zoberme si, že každý vizuál zostavy Power BI vygeneruje dotaz, ktorý sa odošle do modelu Power BI (v službe Power BI sa nazýva množina údajov).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). Tieto dotazy sa používajú na filtrovanie, zoskupovanie a sumarizáciu údajov modelu.These queries are used to filter, group, and summarize model data. Dobre navrhnutý model následne poskytuje tabuľky na filtrovanie a zoskupovanie a tabuľky na sumarizáciu.A well-designed model, then, is one that provides tables for filtering and grouping, and tables for summarizing. Takýto návrh je v súlade s princípmi hviezdicovej schémy:This design fits well with star schema principles:

  • tabuľky dimenzií podporujú filtrovanie a zoskupovanie,Dimension tables support filtering and grouping
  • tabuľky faktov podporujú sumarizáciu.Fact tables support summarization

Neexistuje žiadna vlastnosť tabuľky, ktorú by modelári nastavili na konfigurovanie typu tabuľky ako dimenzie alebo faktu.There's no table property that modelers set to configure the table type as dimension or fact. V skutočnosti to určujú modelové vzťahy.It's in fact determined by the model relationships. Vzťah modelov vytvára medzi dvomi tabuľkami cestu, ktorou sa šíri filter, a práve Kardinalita ako vlastnosť vzťahu určuje typ tabuľky.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. Bežný typ kardinality vzťahu je one-to-many alebo naopak many-to-one.A common relationship cardinality is one-to-many or its inverse many-to-one. Časť „one“ vždy predstavuje tabuľku dimenzií a časť „many“ zasa vždy predstavuje tabuľku faktov.The "one" side is always a dimension-type table while the "many" side is always a fact-type table. Ďalšie informácie o vzťahoch nájdete v téme Modelové vzťahy v aplikácii Power BI Desktop.For more information about relationships, see Model relationships in Power BI Desktop.

Koncept hviezdicovej schémy

Dobre štruktúrovaný návrh modelu by mal obsahovať tabuľky, a to buď tabuľky dimenzií, alebo tabuľky faktov.A well-structured model design should include tables that are either dimension-type tables or fact-type tables. Vyhýbajte sa prelínaniu týchto dvoch typov spolu v jednej tabuľke.Avoid mixing the two types together for a single table. Tiež sa odporúča, aby ste sa snažili dosiahnuť vhodný počet tabuliek spolu s vhodnými vzťahmi.We also recommend that you should strive to deliver the right number of tables with the right relationships in place. Dôležité je tiež to, že tabuľky faktov vždy načítavajú údaje v súvislom vlákne.It's also important that fact-type tables always load data at a consistent grain.

Napokon je dôležité uvedomiť si, že optimálny návrh modelu predstavuje sčasti vedu a sčasti umenie.Lastly, it's important to understand that optimal model design is part science and part art. Niekedy môžete dosiahnuť prienik vďaka správnym pokynom, ak je taký postup vhodný.Sometimes you can break with good guidance when it makes sense to do so.

V modeli Power BI je však možné použiť mnoho ďalších konceptov, ktoré sa vzťahujú na hviezdicovú schému.There are many additional concepts related to star schema design that can be applied to a Power BI model. Tieto koncepty zahŕňajú:These concepts include:

MierkyMeasures

Mierka v návrhu hviezdicovej schémy predstavuje stĺpec tabuľky faktov, ktorý ukladá hodnoty určené na sumarizáciu.In star schema design, a measure is a fact table column that stores values to be summarized.

V modeli Power BI má mierka inú, no predsa podobnú definíciu.In a Power BI model, a measure has a different—but similar—definition. Ide o vzorec napísaný v jazyku Data Analysis Expressions (DAX), ktorým sa dosahuje sumarizácia.It's a formula written in Data Analysis Expressions (DAX) that achieves summarization. Výrazy mierok často využívajú agregačné funkcie jazyka DAX, ako napríklad SUM, MIN, MAX, AVERAGE atď., čím sa získava výsledok v podobe skalárnej hodnoty v čase dotazu (hodnoty sa nikdy neukladajú v modeli).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). Výrazy mierok majú rozsah od jednoduchých stĺpcových agregácií až po sofistikovanejšie vzorce, ktoré prepíšu kontext filtra alebo šírenie vzťahov.Measure expression can range from simple column aggregations to more sophisticated formulas that override filter context and/or relationship propagation. Ďalšie informácie nájdete v článku Základy výrazov DAX v aplikácii Power BI Desktop.For more information, read the DAX Basics in Power BI Desktop article.

Dôležité je pochopiť, že modely Power BI podporujú aj druhú metódu na dosiahnutie sumarizácie.It's important to understand that Power BI models support a second method for achieving summarization. Ľubovoľné stĺpce, no zvyčajne číselné stĺpce, je možné sumarizovať pomocou vizuálu zostavy alebo funkcie Q&A.Any column—and typically numeric columns—can be summarized by a report visual or Q&A. Tieto stĺpce sa označujú ako implicitné mierky.These columns are referred to as implicit measures. Pre vás ako vývojára modelov predstavujú výhodu, keďže v prípade mnohých inštancií nie je potrebné vytvárať mierky.They offer a convenience for you as a model developer, as in many instances you do not need to create measures. Stĺpec Čiastka predaja, ktorý obsahuje údaje o predaji predajcu Adventure Works, je napríklad možné sumarizovať mnohými spôsobmi (sčítať, vypočítať priemer, hodnotu mediánu, minimálnu a maximálnu hodnotu a pod.), a to bez potreby vytvoriť mierku pre jednotlivé možné typy agregácie.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.

Príklady ikon v zozname polí

Existujú však dva presvedčivé dôvody, prečo by ste mali vytvárať mierky, a to dokonca aj pri jednoduchých sumarizáciách na úrovni stĺpcov:However, there are three compelling reasons for you to create measures, even for simple column-level summarizations:

  • Keď viete, že autori vašich zostáv budú dotazovať model pomocou multidimenzionálnych výrazov (MDX), tento model musí obsahovať explicitné mierky.When you know your report authors will query the model by using Multidimensional Expressions (MDX), the model must include explicit measures. Explicitné mierky sa definujú pomocou jazyka DAX.Explicit measures are defined by using DAX. Tento prístup k návrhom má veľký význam pri dotazovaní množiny údajov Power BI pomocou jazyka MDX, pretože jazyk MDX nemôže dosiahnuť sumarizáciu hodnôt stĺpcov.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. Jazyk MDX sa bude používať predovšetkým pri vykonávaní funkcie Analyzovať v Exceli, pretože kontingenčné tabuľky vytvárajú dotazy MDX.Notably, MDX will be used when performing Analyze in Excel, because PivotTables issue MDX queries.
  • Keď viete, že autori vašich zostáv budú vytvárať stránkované zostavy služby Power BI pomocou návrhára dotazov služby MDX, tento model musí obsahovať explicitné mierky.When you know your report authors will create Power BI paginated reports using the MDX query designer, the model must include explicit measures. Iba návrhár dotazov služby MDX podporuje agregáty servera.Only the MDX query designer supports server aggregates. Ak teda autori zostáv musia mať mierky vyhodnocované službou Power BI (namiesto nástroja stránkovaných zostáv), musia použiť návrhára dotazov služby MDX.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.
  • Keď potrebujete zabezpečiť, aby autori zostáv mohli stĺpce sumarizovať iba určitými spôsobmi.When you need to ensure that your report authors can only summarize columns in specific ways. Stĺpec Jednotková cena s údajmi o predaji predajcu, ktorý predstavuje pomer na jednotku, je napríklad možné sumarizovať, ale len pomocou určitých agregačných funkcií.For example, the reseller sales Unit Price column (which represents a per unit rate) can be summarized, but only by using specific aggregation functions. Nikdy by sa nemal sčítavať, ale je vhodné sumarizovať ho použitím iných agregačných funkcií ako min, max, average atď. V tejto inštancii môže modelár stĺpec Jednotková cena skryť a vytvoriť mierky pre všetky vhodné agregačné funkcie.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.

Tento prístup k návrhom funguje veľmi dobre pri zostavách, ktoré boli vytvorené v službe Power BI a pre funkciu Q&A.This design approach works well for reports authored in the Power BI service and for Q&A. Dynamické pripojenia aplikácie Power BI Desktop však umožňujú autorom zostáv zobrazovať skryté polia na table Polia, čo môže mať za následok obídenie tohto prístupu k návrhu.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.

Náhradné kľúčeSurrogate keys

Náhradný kľúč je jedinečný identifikátor, ktorý sa pridáva do tabuľky ako podpora modelovania hviezdicových schém.A surrogate key is a unique identifier that you add to a table to support star schema modeling. Predvolene nie je v zdrojových údajoch definovaný ani uložený.By definition, it's not defined or stored in the source data. Náhradné kľúče sa bežne pridávajú do tabuliek dimenzií skladov relačných údajov, kde slúžia ako jedinečné identifikátory pre jednotlivé riadky tabuľky dimenzií.Commonly, surrogate keys are added to relational data warehouse dimension tables to provide a unique identifier for each dimension table row.

Vzťahy modelov služby Power BI sa zakladajú na jednom jedinečnom stĺpci v jednej tabuľke, ktorý vypĺňa filtre do jedného stĺpca v inej tabuľke.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. Ak tabuľka dimenzií v modeli neobsahuje jeden jedinečný stĺpec, musíte pridať jedinečný identifikátor, ktorý bude vo vzťahu predstavovať časť „one“.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. V aplikácii Power BI Desktop môžete túto požiadavku jednoducho dosiahnuť vytvorením stĺpca indexov doplnku Power Query.In Power BI Desktop, you can easily achieve this requirement by creating a Power Query index column.

Vytvorenie stĺpca indexu na paneli s nástrojmi doplnku Power Query

Tento dotaz musíte zlúčiť s časťou dotazu „many“, aby ste doň mohli pridať aj stĺpec indexu.You must merge this query with the "many"-side query so that you can add the index column to it also. Keď v modeli načítate tieto dotazy, môžete následne medzi tabuľkami modelov vytvoriť vzťah typu one-to-many.When you load these queries to the model, you can then create a one-to-many relationship between the model tables.

Vločkové dimenzieSnowflake dimensions

Vločková dimenzia predstavuje súpravu normalizovaných tabuliek jednej podnikovej entity.A snowflake dimension is a set of normalized tables for a single business entity. Spoločnosť Adventure Works napríklad klasifikuje produkty podľa kategórií a podkategórií.For example, Adventure Works classifies products by category and subcategory. Kategórie sa priraďujú do podkategórií a do podkategórií sa zasa priraďujú produkty.Categories are assigned to subcategories, and products are in turn assigned to subcategories. V sklade relačných údajov Adventure Works sa dimenzia produktov normalizuje a uloží sa do troch súvisiacich tabuliek: DimProductCategory, DimProductSubcategoryDimProduct.In the Adventure Works relational data warehouse, the product dimension is normalized and stored in three related tables: DimProductCategory, DimProductSubcategory, and DimProduct.

Ak použijete svoju fantáziu, môžete si predstaviť normalizované tabuľky umiestnené smerom von z tabuľky faktov, čím sa vytvorí vzhľad snehovej vločky.If you use your imagination, you can picture the normalized tables positioned outwards from the fact table, forming a snowflake design.

Príklad schémy v tvare snehovej vločky

V aplikácii Power BI Desktop si môžete vybrať, či chcete napodobniť návrh dimenzie v tvare snehovej vločky (možno preto, lebo tak robia zdrojové údaje), alebo chcete zdrojové tabuľky integrovať (denormalizovať) do jednej tabuľky modelov.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. Výhody jednej tabuľky modelov vo všeobecnosti prevyšujú výhody viacerých tabuliek modelov.Generally, the benefits of a single model table outweigh the benefits of multiple model tables. Najoptimálnejšie rozhodnutie závisí od objemu údajov a použiteľnosti požiadaviek na model.The most optimal decision can depend on the volumes of data and the usability requirements for the model.

Ak sa rozhodnete napodobniť návrh dimenzie v tvare vločky:When you choose to mimic a snowflake dimension design:

  • Služba Power BI načítava viac tabuliek, čo je menej efektívne z hľadiska ukladacieho priestoru a výkonu.Power BI loads more tables, which is less efficient from storage and performance perspectives. Tieto tabuľky musia obsahovať stĺpce, ktoré podporujú vzťahy modelov, čím môže vzniknúť model väčšieho rozsahu.These tables must include columns to support model relationships, and it can result in a larger model size.
  • Bude potrebné prechádzať dlhšie reťazce na rozširovanie vzťahových filtrov, čo bude pravdepodobne menej efektívne ako filtre použité na jednu tabuľku.Longer relationship filter propagation chains will need to be traversed, which will likely be less efficient than filters applied to a single table.
  • Tabla Polia zobrazuje autorom zostáv viac tabuliek modelov, čo môže mať za následok menej intuitívne prostredie, obzvlášť vtedy, keď tabuľky dimenzií v tvare vločky obsahujú len jeden alebo dva stĺpce.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.
  • Nie je možné vytvoriť hierarchiu, ktorá presahuje tabuľky.It's not possible to create a hierarchy that spans the tables.

Ak sa rozhodnete využiť integráciu do jednej tabuľky modelu, môžete tiež definovať hierarchiu, ktorá obsiahne najvyššie aj najnižšie umiestnené vlákno dimenzie.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. Je možné, že ukladací priestor s nadbytočnými denormalizovanými údajmi zvýši veľkosť ukladacieho priestoru modelu, obzvlášť v prípade veľmi veľkých tabuliek dimenzií.Possibly, the storage of redundant denormalized data can result in increased model storage size, particularly for very large dimension tables.

Hierarchia v rámci dimenzie

Málo premenlivé dimenzieSlowly changing dimensions

Málo premenlivá dimenzia (SCD) je dimenzia, ktorá vhodným spôsobom spravuje zmeny členov dimenzie v priebehu času.A slowly changing dimension (SCD) is one that appropriately manages change of dimension members over time. Uplatňuje sa v prípade, keď sa hodnoty podnikovej entity menia v priebehu času a spôsobom ad hoc.It applies when business entity values change over time, and in an ad hoc manner. Vhodným príkladom málo premenlivej dimenzie je zákaznícka dimenzia, konkrétne jej stĺpce s kontaktnými údajmi, ako je napríklad e-mailová adresa a telefónne číslo.A good example of a slowly changing dimension is a customer dimension, specifically its contact detail columns like email address and phone number. Niektoré dimenzie sa naopak považujú za veľmi premenlivé, keď sa atribút dimenzie, ako napríklad trhová cena skladových zásob, mení často.In contrast, some dimensions are considered to be rapidly changing when a dimension attribute changes often, like a stock's market price. Častým prístupom k návrhu v týchto inštanciách je ukladanie rýchlo sa meniacich hodnôt atribútov do mierky tabuľky faktov.The common design approach in these instances is to store rapidly changing attribute values in a fact table measure.

Teória návrhu hviezdicovej schémy odkazuje na dva časté typy málo premenlivých dimenzií (SCD): 1. typ a 2. typ.Star schema design theory refers to two common SCD types: Type 1 and Type 2. Tabuľka dimenzií môže predstavovať 1. typ aj 2. typ alebo podporovať oba typy súčasne v prípade odlišných stĺpcov.A dimension-type table could be Type 1 or Type 2, or support both types simultaneously for different columns.

1. typ málo premenlivej dimenzie (SCD)Type 1 SCD

SCD 1. typu vždy odráža najnovšie hodnoty a keď sa zistia zmeny v zdrojových údajoch, údaje tabuľky dimenzií sa prepíšu.A Type 1 SCD always reflects the latest values, and when changes in source data are detected, the dimension table data is overwritten. Tento prístup k návrhu je bežný v prípade stĺpcov, ktoré ukladajú dodatočné hodnoty, ako je napríklad e-mailová adresa alebo telefónne číslo zákazníka.This design approach is common for columns that store supplementary values, like the email address or phone number of a customer. Keď sa zmení e-mailová adresa alebo telefónne číslo zákazníka, tabuľka dimenzií riadok zákazníka aktualizuje o nové hodnoty.When a customer email address or phone number changes, the dimension table updates the customer row with the new values. Potom to vyzerá tak, ako by sa kontaktné informácie zákazníka nikdy nezmenili.It's as if the customer always had this contact information.

Obnovenie tabuľky dimenzií modelu Power BI bez prírastku dosahuje výsledok v podobe 1. typu SCD.A non-incremental refresh of a Power BI model dimension-type table achieves the result of a Type 1 SCD. Obnovia sa údaje tabuľky a zaistí sa, aby sa načítali najnovšie hodnoty.It refreshes the table data to ensure the latest values are loaded.

2. typ málo premenlivej dimenzie (SCD)Type 2 SCD

SCD 2. typu podporuje tvorbu verzií členov dimenzie.A Type 2 SCD supports versioning of dimension members. Ak zdrojový systém verzie neukladá, zvyčajne zistí zmeny práve proces načítania skladu údajov a vhodným spôsobom vykoná zmenu v tabuľke dimenzií.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. V tomto prípade musí tabuľka dimenzií použiť náhradný kľúč a poskytnúť jedinečný odkaz verzii patriacej členovi dimenzie.In this case, the dimension table must use a surrogate key to provide a unique reference to a version of the dimension member. Obsahuje tiež stĺpce, ktoré definujú platnosť rozsahu údajov vo verzii (napríklad StartDate (Dátum začatia) a EndDate (Dátum ukončenia)), a prípadne aj stĺpec príznakov (napríklad IsCurrent (Je aktuálne)) na jednoduché filtrovanie aktuálnych členov dimenzie.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.

Spoločnosť Adventure Works napríklad priraďuje obchodníkov k oblastiam predaja.For example, Adventure Works assigns salespeople to a sales region. Keď obchodník zmení oblasť, musí sa vytvoriť nová verzia obchodníka, aby sa zabezpečilo, že historické údaje budú aj naďalej priradené k predchádzajúcej oblasti.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. Tabuľka dimenzií musí ukladať verzie obchodníkov a im priradené oblasti, aby sa podporovala presná historická analýza predaja podľa obchodníkov.To support accurate historic analysis of sales by salesperson, the dimension table must store versions of salespeople and their associated region(s). Tabuľka by tiež mala obsahovať aj hodnoty dátumov začatia a ukončenia, ktoré definujú časovú platnosť.The table should also include start and end date values to define the time validity. Aktuálne verzie môžu definovať prázdny dátum ukončenia (alebo 31.12.1999), čo značí, že verzia daného riadku je aktuálna.Current versions may define an empty end date (or 12/31/9999), which indicates that the row is the current version. Tabuľka musí tiež definovať náhradný kľúč, pretože podnikový kľúč (v tejto inštancii ID zamestnanca) nebude jedinečný.The table must also define a surrogate key because the business key (in this instance, employee ID) won't be unique.

Je dôležité uvedomiť si, že ak zdrojové údaje neukladajú verzie, musíte na zisťovanie a ukladanie zmien použiť nejaký sprostredkujúci systém (napríklad sklad údajov).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. Proces načítania tabuľky musí zachovať existujúce údaje a zistiť zmeny.The table load process must preserve existing data and detect changes. Keď sa zistí zmena, proces načítania tabuľky musí ukončiť platnosť danej aktuálnej verzie.When a change is detected, the table load process must expire the current version. Tieto zmeny zaznamená tak, že aktualizuje hodnotu EndDate (Dátum ukončenia) a vloží novú verziu s hodnotou StartDate (Dátum začatia) začínajúcou od predchádzajúcej hodnoty EndDate.It records these changes by updating the EndDate value and inserting a new version with the StartDate value commencing from the previous EndDate value. Súvisiace fakty musia tiež používať vyhľadávanie na základe času, aby sa načítala hodnota kľúča dimenzie relevantná k dátumu faktov.Also, related facts must use a time-based lookup to retrieve the dimension key value relevant to the fact date. Model Power BI používajúci doplnok Power Query takýto výsledok dosiahnuť nedokáže.A Power BI model using Power Query can't produce this result. Môže však načítať údaje z vopred načítanej tabuľky dimenzií 2. typu SCD.It can, however, load data from a pre-loaded SCD Type 2 dimension table.

Model Power BI by mal bez ohľadu na zmeny podporovať dotazovanie historických údajov člena, a verzie člena, ktorá predstavuje konkrétny stav člena v čase.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. V súvislosti so spoločnosťou Adventure Works vám tento návrh umožňuje dotazovať obchodníkov bez ohľadu na priradenú oblasť predaja, alebo pre konkrétnu verziu obchodníka.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.

Ak chcete dosiahnuť splnenie tejto požiadavky, tabuľka dimenzií modelu Power BI musí obsahovať stĺpec na filtrovanie obchodníka a iný stĺpec na filtrovanie konkrétnej verzie obchodníka.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. Je dôležité, aby stĺpec verzie neobsahoval nejednoznačné popisy, ako napríklad „Michal Balog (15.12.2008 – 26.06.2019)“ alebo „Michal Balog (aktuálne)“.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)". Tiež je podstatné, aby boli autori a používatelia zostáv poučení o základoch 2. typu SCD a o tom, ako dosiahnuť vhodný návrh zostáv použitím správnych filtrov.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.

V prípade návrhu je tiež vhodné zahrnúť doň hierarchiu, ktorá vizuálom umožňuje prejsť až na detaily na úrovni verzie.It's also a good design practice to include a hierarchy that allows visuals to drill down to the version level.

Príklad hierarchie v zozname polí

Výstup z príkladu hierarchie

Dimenzie zohrávajúce rolyRole-playing dimensions

Dimenzia zohrávajúca rolu je dimenzia, ktorá umožňuje filtrovať súvisiace fakty iným spôsobom.A role-playing dimension is a dimension that can filter related facts differently. V spoločnosti Adventure Works má napríklad dátumová tabuľka dimenzií tri vzťahy k faktom o predaji predajcu.For example, at Adventure Works, the date dimension table has three relationships to the reseller sales facts. Tú istú tabuľku dimenzií možno použiť na filtrovanie faktov podľa dátumu objednávky, dátumu odoslania alebo dátumu doručenia.The same dimension table can be used to filter the facts by order date, ship date, or delivery date.

V sklade údajov sa akceptuje prístup k návrhu v podobe definovania jednej dátumovej tabuľky dimenzií.In a data warehouse, the accepted design approach is to define a single date dimension table. V čase vykonávania dotazu sa vytvorí „rola“ dimenzie dátumu podľa toho, ktorý stĺpec faktov používate na prepojenie tabuliek.At query time, the "role" of the date dimension is established by which fact column you use to join the tables. Ak napríklad analyzujete predaj podľa dátumu objednávky, tabuľka pripojí príbuzné dátumy k stĺpcu dátumov s predajnými objednávkami predajcu.For example, when you analyze sales by order date, the table join relates to the reseller sales order date column.

V modeli Power BI je možné tento návrh napodobniť vytvorením viacnásobných vzťahov medzi dvoma tabuľkami.In a Power BI model, this design can be imitated by creating multiple relationships between two tables. V príklade spoločnosti Adventure Works by mali tabuľky údajov a predajov predajcu tri vzťahy.In the Adventure Works example, the date and reseller sales tables would have three relationships. Hoci je tento návrh možný, je dôležité pochopiť, že medzi tabuľkami modelov Power BI môže byť len jeden aktívny vzťah.While this design is possible, it's important to understand that there can only be one active relationship between two Power BI model tables. Všetky zostávajúce vzťahy musia byť nastavené ako neaktívne.All remaining relationships must be set to inactive. Ak už máte jeden aktívny vzťah, znamená to, že existuje predvolené šírenie filtra od dátumu až po predaj predajcu.Having a single active relationship means there is a default filter propagation from date to reseller sales. V tejto inštancii je aktívny vzťah nastavený na najbežnejší filter, ktorý používajú zostavy, a ktorý v službe Adventure Works predstavuje vzťah poradia dátumov.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.

Príklad dimenzie a vzťahov, ktoré zohrávajú jedinú rolu

Jediný spôsob, ako využiť neaktívny vzťah, je definovať výraz DAX, ktorý používa funkciu USERELATIONSHIP.The only way to use an inactive relationship is to define a DAX expression that uses the USERELATIONSHIP function. V našom príklade musí vývojár modelov vytvoriť mierky na umožnenie analýzy predaja predajcu podľa dátumu odoslania a dátumu doručenia.In our example, the model developer must create measures to enable analysis of reseller sales by ship date and delivery date. Táto práca môže byť zdĺhavá, najmä keď tabuľka predajcu definuje mnohé mierky.This work can be tedious, especially when the reseller table defines many measures. Zároveň sa vytvoria nepotrebné položky na table Polia s nadbytočným množstvom mierok.It also creates Fields pane clutter, with an overabundance of measures. Existujú aj ďalšie obmedzenia:There are other limitations, too:

  • Ak sa autori zostáv spoliehajú na stĺpce súhrnu a nie na definovanie mierok, nemôžu dosiahnuť sumarizáciu neaktívnych vzťahov bez zápisu mierky na úrovni zostavy.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. Mierky na úrovni zostavy možno definovať iba pri vytváraní zostáv v aplikácii Power BI Desktop.Report-level measures can only be defined when authoring reports in Power BI Desktop.
  • Ak je aktívny iba jeden vzťah medzi dátumom a predajom predajcu, nie je možné súčasne filtrovať predaj predajcu podľa rôznych typov dátumov.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ôžete napríklad vytvoriť vizuál, ktorý vykreslí predaj podľa dátumu objednávky podľa dodaného predaja.For example, you can't produce a visual that plots order date sales by shipped sales.

Na prekonanie týchto obmedzení je bežnou technikou modelovania v službe Power BI vytvorenie tabuľky typu dimenzie pre každú inštanciu zohrávajúcu rolu.To overcome these limitations, a common Power BI modeling technique is to create a dimension-type table for each role-playing instance. Zvyčajne vytvoríte ďalšie tabuľky dimenzií ako vypočítané tabuľky pomocou jazyka DAX.You typically create the additional dimension tables as calculated tables, using DAX. V prípade použitia vypočítaných tabuliek môže model obsahovať tabuľku Dátum, tabuľku Dátum odoslania a tabuľku Dátum doručenia, pričom každá z nich má jediný a aktívny vzťah k príslušným stĺpcom tabuľky predaja predajcu.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.

Príklad dimenzií a vzťahov zohrávajúcich roly

Tento prístup k návrhu nevyžaduje definovanie viacerých mierok pre rôzne roly dátumov a umožňuje simultánne filtrovanie podľa rôznych rolí dátumov.This design approach doesn't require you to define multiple measures for different date roles, and it allows simultaneous filtering by different date roles. Menšou nevýhodou tohto prístupu k návrhu je však to, že bude sa duplikuje tabuľka dimenzií dátumov, čo má za následok viac potrebného ukladacieho priestoru modelu.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. Keďže tabuľky dimenzií zvyčajne ukladajú menej riadkov vzhľadom na tabuľky faktov, tento problém je zriedkavý.As dimension-type tables typically store fewer rows relative to fact-type tables, it is rarely a concern.

Pri vytváraní tabuliek dimenzií pre každú rolu dodržiavajte tieto najvhodnejšie postupy návrhu:Observe the following good design practices when you create model dimension-type tables for each role:

  • Uistite sa, že názvy stĺpcov sú samopopisné.Ensure that the column names are self-describing. Aj keď je možné mať stĺpec Rok vo všetkých dátumových tabuľkách (názvy stĺpcov sú v rámci tabuľky jedinečné), nie je samopopisný podľa predvolených názvov vizuálov.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. Pouvažujte o premenovaní stĺpcov v každej tabuľke rolí dimenzií, aby tabuľka Dátum odoslania mala stĺpec roka s názvom Rok odoslania atď.Consider renaming columns in each dimension role table, so that the Ship Date table has a year column named Ship Year, etc.
  • Ak je to dôležité, zabezpečte, aby popisy tabuliek poskytovali spätnú väzbu autorom zostáv (prostredníctvom popisov tably Polia) o spôsobe konfigurácie distribúcie filtrov.When relevant, ensure that table descriptions provide feedback to report authors (through Fields pane tooltips) about how filter propagation is configured. Táto jasnosť je dôležitá, keď model obsahuje všeobecne pomenovanú tabuľku, ako je napríklad Dátum, ktorá sa používa na filtrovanie viacerých tabuliek faktov.This clarity is important when the model contains a generically named table, like Date, which is used to filter many fact-type tables. V prípade, že táto tabuľka má napríklad aktívny vzťah k stĺpcu dátumov predajných objednávok predajcu, pouvažujte o uvedení popisu tabuľky, napríklad „Filtruje predaj predajcu podľa dátumu objednávky“.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".

Ďalšie informácie nájdete v téme Pokyny na prácu s aktívnymi a neaktívnymi vzťahmi.For more information, see Active vs inactive relationship guidance.

Nevyžiadané dimenzieJunk dimensions

Nevyžiadaná dimenzia je užitočná v prípade existencie väčšieho počtu dimenzií, najmä ak obsahujú málo atribútov (možno jeden), a keď tieto atribúty majú málo hodnôt.A junk dimension is useful when there are many dimensions, especially consisting of few attributes (perhaps one), and when these attributes have few values. Dobrými kandidátmi sú stĺpce stavu objednávok alebo demografické stĺpce zákazníkov (pohlavie, veková skupina atď.).Good candidates include order status columns, or customer demographic columns (gender, age group, etc.).

Cieľom návrhu nevyžiadanej dimenzie je zlúčiť veľa „malých“ dimenzií do jednej dimenzie, aby sa zmenšila veľkosť ukladacieho priestoru modelu a tiež zmenšil počet nepotrebných položiek na table Polia sprístupňovaním menšieho počtu tabuliek modelov.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.

Tabuľka nevyžiadanej dimenzie je zvyčajne kartézskym súčinom všetkých členov atribútu dimenzie so stĺpcom náhradného kľúča.A junk dimension table is typically the Cartesian product of all dimension attribute members, with a surrogate key column. Náhradný kľúč poskytuje jedinečný odkaz na každý riadok v tabuľke.The surrogate key provides a unique reference to each row in the table. Dimenziu môžete vytvoriť v sklade údajov alebo použitím doplnku Power Query na vytvorenie dotazu, ktorý vykoná úplné vonkajšie spojenie dotazu a potom pridá náhradný kľúč (stĺpec indexu).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).

Príklad nevyžiadanej dimenzie

Tento dotaz načítate do modelu ako tabuľku dimenzie.You load this query to the model as a dimension-type table. Tento dotaz tiež treba zlúčiť s dotazom faktu, takže stĺpec indexu sa načíta do modelu a podporí vytvorenie vzťahu typu „one-to-many“.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.

Dimenzie faktovDegenerate dimensions

Dimenzia faktov odkazuje na atribút tabuľky faktov, ktorá sa vyžaduje na filtrovanie.A degenerate dimension refers to an attribute of the fact table that is required for filtering. Čo sa týka spoločnosti Adventure Works, dobrým príkladom je číslo predajnej objednávky predajcu.At Adventure Works, the reseller sales order number is a good example. V tomto prípade v rámci návrhu modelu nedáva zmysel vytvoriť nezávislú tabuľku, ktorá sa skladá len z tohto jedného stĺpca, pretože by sa zvýšila veľkosť ukladacieho priestoru modelu a vznikli nepotrebné položky na table Polia.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.

V modeli Power BI môže byť vhodné pridať stĺpec s číslom predajnej objednávky do tabuľky faktov a povoliť tak filtrovanie alebo zoskupenie podľa čísla predajnej objednávky.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. Toto je výnimka z predtým zavedeného pravidla, že by ste nemali kombinovať typy tabuliek (vo všeobecnosti by tabuľky modelov mali byť buď tabuľkami dimenzií, alebo tabuľkami faktov).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).

Príklad dimenzie faktov

Ak však tabuľka predaja predajcov Adventure Works obsahuje stĺpce s číslom objednávky a s číslom riadka objednávky a sú potrebné na filtrovanie, tabuľka dimenzií faktov by bola vhodným návrhom.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. Ďalšie informácie nájdete v téme Pokyny na prácu so vzťahmi one-to-one (Dimenzie faktov).For more information, see One-to-one relationship guidance (Degenerate dimensions).

Tabuľky faktov bez faktovFactless fact tables

Tabuľka faktov bez faktov neobsahuje žiadne stĺpce mierok.A factless fact table doesn't include any measure columns. Obsahuje iba kľúče dimenzie.It contains only dimension keys.

Tabuľka faktov bez faktov môže ukladať pozorovania definované kľúčmi dimenzie.A factless fact table could store observations defined by dimension keys. V konkrétnom dátume a čase sa napríklad konkrétny zákazník prihlásil na vašu webovú lokalitu.For example, at a particular date and time, a particular customer logged into your web site. Mohli by ste definovať mierku tak, aby sa spočítali riadky tabuľky faktov bez faktov a vykonala sa analýza toho, kedy a koľko zákazníkov sa prihlásilo.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.

Zaujímavejším použitím tabuľky faktov bez faktov je ukladanie vzťahov medzi dimenziami, pričom je to prístup návrhu modelu Power BI, ktorý odporúčame pri definovaní vzťahov dimenzií typu „many-to-many“.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. návrhu vzťahov dimenzií typu „many-to-many“ sa na tabuľku faktov bez faktov odkazuje ako na premosťovaciu tabuľku.In a many-to-many dimension relationship design, the factless fact table is referred to as a bridging table.

Predpokladajme napríklad, že predajcovia môžu byť priradení k jednej alebo viacerým oblastiam predaja.For example, consider that salespeople can be assigned to one or more sales regions. Premosťovacia tabuľka by bola navrhnutá ako tabuľka faktov bez faktov pozostávajúca z dvoch stĺpcov: kľúč predajcu a kľúč oblasti.The bridging table would be designed as a factless fact table consisting of two columns: salesperson key and region key. Duplicitné hodnoty môžu byť uložené v oboch stĺpcoch.Duplicate values can be stored in both columns.

Príklad tabuľky faktov bez faktov

Tento prístup návrhu typu „many-to-many“ je dobre zdokumentovaný a možno ho dosiahnuť bez premosťovacej tabuľky.This many-to-many design approach is well documented, and it can be achieved without a bridging table. Prístup premosťovacej tabuľky sa však považuje za najlepší postup, keď ide o dve dimenzie.However, the bridging table approach is considered the best practice when relating two dimensions. Ďalšie informácie nájdete v téme Pokyny na prácu so vzťahmi many-to-many (Vytvorenie vzťahu medzi dvomi tabuľkami dimenzií).For more information, see Many-to-many relationship guidance (Relate two dimension-type tables).

Ďalší postupNext steps

Ďalšie informácie o návrhu hviezdicovej schémy alebo návrhu modelov v službe Power BI nájdete v nasledujúcich článkoch:For more information about star schema design or Power BI model design, see the following articles: