Vysvětlení hvězdicového schématu a jeho důležitosti pro Power BIUnderstand star schema and the importance for Power BI

Tento článek je určen pro modelátory dat v Power BI Desktopu.This article targets Power BI Desktop data modelers. Popisuje návrh hvězdicového schématu a jeho důležitost pro vývoj datových modelů Power BI, které jsou optimalizované z hlediska výkonu a použitelnosti.It describes star schema design and its relevance to developing Power BI data models optimized for performance and usability.

Účelem tohoto článku není podrobný rozbor návrhu hvězdicového schématu.This article isn't intended to provide a complete discussion on star schema design. Další podrobnosti najdete například v publikaci The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3. vydání, 2013), jejímiž autory jsou Ralph Kimball a další.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.

Základní informace o hvězdicovém schématuStar schema overview

Hvězdicové schéma představuje vyspělý přístup k modelování, který je široce využíván relačními datovými sklady.Star schema is a mature modeling approach widely adopted by relational data warehouses. Vyžaduje, aby modelátoři klasifikovali tabulky modelu buď jako tabulky dimenzí, nebo jako tabulky faktů.It requires modelers to classify their model tables as either dimension or fact.

Tabulky dimenzí popisují obchodní entity – věci, které modelujete.Dimension tables describe business entities—the things you model. Entity můžou zahrnovat produkty, osoby, místa a koncepty zahrnující samotný čas.Entities can include products, people, places, and concepts including time itself. Nejkonzistentnější tabulkou, kterou v hvězdicovém schématu najdete, je tabulka dimenzí kalendářních dat.The most consistent table you'll find in a star schema is a date dimension table. Tabulka dimenzí obsahuje klíčový sloupec (nebo sloupce), který funguje jako jedinečný identifikátor, a popisné sloupce.A dimension table contains a key column (or columns) that acts as a unique identifier, and descriptive columns.

Tabulky faktů uchovávají pozorování nebo události. Můžou to být prodejní objednávky, zůstatky zásob, směnné kurzy, teploty atd. Tabulka faktů obsahuje klíčové sloupce dimenzí, které se vztahují k tabulkám dimenzí, a sloupce číselných měr.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. Klíčové sloupce dimenzí určují dimenzionalitu tabulky faktů, zatímco hodnoty klíčů dimenzí určují členitost tabulky faktů.The dimension key columns determine the dimensionality of a fact table, while the dimension key values determine the granularity of a fact table. Představme si například tabulku faktů navrženou pro ukládání cílů prodeje, která má dva klíčové sloupce dimenzí Date a ProductKey.For example, consider a fact table designed to store sale targets that has two dimension key columns Date and ProductKey. Snadno lze zjistit, že tabulka má dvě dimenze.It's easy to understand that the table has two dimensions. Členitost se však nedá určit bez toho, že by se vzaly v úvahu hodnoty klíčů dimenzí.The granularity, however, can't be determined without considering the dimension key values. V tomto příkladu předpokládejme, že hodnoty uložené ve sloupci Date představují první den v každém měsíci.In this example, consider that the values stored in the Date column are the first day of each month. V tomto případě je členitost na úrovni měsíc-produkt.In this case, the granularity is at month-product level.

Obecně platí, že tabulky dimenzí obsahují relativně malý počet řádků.Generally, dimension tables contain a relatively small number of rows. Oproti tomu tabulky faktů můžou obsahovat velmi velký počet řádků a v průběhu času se můžou dále zvětšovat.Fact tables, on the other hand, can contain a very large number of rows and continue to grow over time.

Obrázek hvězdicového schématu

Důležitost hvězdicového schématu pro modely Power BIStar schema relevance to Power BI models

Návrh hvězdicového schématu a řada souvisejících konceptů, které jsou představené v tomto článku, jsou velmi důležité pro vývoj modelů Power BI, které jsou optimalizované z hlediska výkonu a použitelnosti.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.

Předpokládejme, že každý vizuál sestavy Power BI generuje dotaz, který se odešle do modelu Power BI (který se ve službě Power BI nazývá datová sada).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). Tyto dotazy se používají k filtrování, seskupování a souhrnům dat modelu.These queries are used to filter, group, and summarize model data. Dobře navržený model je pak ten, který poskytuje tabulky pro filtrování a seskupování a tabulky pro souhrny.A well-designed model, then, is one that provides tables for filtering and grouping, and tables for summarizing. Principy hvězdicového schématu tomuto návrhu dobře odpovídají:This design fits well with star schema principles:

  • Tabulky dimenzí podporují filtrování a seskupování.Dimension tables support filtering and grouping
  • Tabulky faktů podporují souhrny.Fact tables support summarization

Neexistuje žádná vlastnost tabulky, kterou by modelování nastavilo pro konfiguraci typu tabulky jako tabulky dimenzí nebo faktů.There's no table property that modelers set to configure the table type as dimension or fact. Ve skutečnosti se to určuje relacemi modelu.It's in fact determined by the model relationships. Relace modelu vytváří cestu šíření filtrů mezi dvěma tabulkami a typ tabulky je určen vlastností Kardinalita dané relace.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. Obvyklá kardinalita relace je 1:N nebo její inverze N:1.A common relationship cardinality is one-to-many or its inverse many-to-one. Stranou 1 je vždy tabulka dimenzí a stranou N je vždy tabulka faktů.The "one" side is always a dimension-type table while the "many" side is always a fact-type table. Další informace o relacích najdete v tématu Relace modelu v Power BI Desktopu.For more information about relationships, see Model relationships in Power BI Desktop.

Konceptuální hvězdicové schéma

Dobře strukturovaný návrh modelu by měl obsahovat tabulky, které jsou buď tabulkami dimenzí, nebo tabulkami faktů.A well-structured model design should include tables that are either dimension-type tables or fact-type tables. Vyhněte se kombinaci obou těchto typů v jedné tabulce.Avoid mixing the two types together for a single table. Doporučujeme také, abyste usilovali o vhodný počet tabulek s vhodnými relacemi.We also recommend that you should strive to deliver the right number of tables with the right relationships in place. Je také důležité, aby tabulky faktů vždy načítaly data s konzistentní úrovni podrobností.It's also important that fact-type tables always load data at a consistent grain.

A je důležité uvědomit si, že optimální návrh modelu je z části věda a z části umění.Lastly, it's important to understand that optimal model design is part science and part art. Někdy může být vhodné třeba i nedodržet dobře míněné pokyny, když k tomu bude důvod.Sometimes you can break with good guidance when it makes sense to do so.

S návrhem hvězdicového schématu souvisí řada dalších konceptů, které je možné pro model Power BI použít.There are many additional concepts related to star schema design that can be applied to a Power BI model. Patří mezi ně:These concepts include:

MíryMeasures

Míra v návrhu hvězdicového schématu je sloupec tabulky faktů, ve kterém jsou uložené hodnoty určené pro souhrny.In star schema design, a measure is a fact table column that stores values to be summarized.

V modelu Power BI má míra jinou, avšak podobnou definici.In a Power BI model, a measure has a different—but similar—definition. Jedná se o vzorec zapsaný v jazyku DAX (Data Analysis Expressions), jehož výsledkem je souhrn.It's a formula written in Data Analysis Expressions (DAX) that achieves summarization. Výrazy měr často k získání výsledku tvořeného skalární hodnotou v době dotazu využívají agregační funkce jazyka DAX, jako jsou SUM, MIN, MAX, AVERAGE atd. (hodnoty se nikdy neukládají do modelu).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 měr můžou být v rozsahu od jednoduchých sloupcových agregací až po složitější vzorce, které přepisují kontext filtrů nebo šíření relací.Measure expression can range from simple column aggregations to more sophisticated formulas that override filter context and/or relationship propagation. Další informace najdete v článku Základy jazyka DAX v Power BI Desktopu.For more information, read the DAX Basics in Power BI Desktop article.

Důležité je porozumět tomu, že modely Power BI podporují druhou metodu pro získání souhrnu.It's important to understand that Power BI models support a second method for achieving summarization. Souhrn libovolného sloupce (obvykle číselných sloupců) lze provést pomocí vizuálu sestavy nebo pomocí Q&A.Any column—and typically numeric columns—can be summarized by a report visual or Q&A. Tyto sloupce se označují jako implicitní míry.These columns are referred to as implicit measures. Pro vás jako vývojáře modelu je to praktické, protože v mnoha případech není potřeba vytvářet míry.They offer a convenience for you as a model developer, as in many instances you do not need to create measures. Například souhrn sloupce Sales Amount (Částka prodeje) maloobchodního prodeje společnosti Adventure Works lze provést mnoha způsoby (součet, počet, průměr, medián, minimum, maximum atd.), aniž by bylo nutné vytvářet míru pro každý možný typ agregace.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říklad ikon v seznamu polí

Existují však tři přesvědčivé důvody pro vytváření měr i pro jednoduché souhrny na úrovni sloupců:However, there are three compelling reasons for you to create measures, even for simple column-level summarizations:

  • Pokud víte, že autoři sestav budou dotazovat model pomocí jazyka MDX (Multidimensional Expressions), musí daný model obsahovat explicitní míry.When you know your report authors will query the model by using Multidimensional Expressions (MDX), the model must include explicit measures. Explicitní míry se definují pomocí jazyka DAX.Explicit measures are defined by using DAX. Tento přístup k návrhu je velmi důležitý při dotazování datové sady Power BI pomocí jazyka MDX, protože jazyk MDX nedokáže získat souhrny hodnot sloupců.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. Zejména se jedná se o případ, kdy se provádí funkce Analyzovat v aplikaci Excel, protože dotazy MDX vydávají kontingenční tabulky.Notably, MDX will be used when performing Analyze in Excel, because PivotTables issue MDX queries.
  • Pokud víte, že autoři sestav vytvoří stránkované sestavy Power BI pomocí návrháře dotazů MDX, musí daný model obsahovat explicitní míry.When you know your report authors will create Power BI paginated reports using the MDX query designer, the model must include explicit measures. Agregované hodnoty serveru podporuje pouze návrhář dotazů MDX.Only the MDX query designer supports server aggregates. Pokud tedy autoři sestav potřebují vyhodnotit míry pomocí Power BI (místo modulu stránkovaných sestav), musí použít návrháře dotazů 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.
  • Pokud potřebujete zajistit, aby autoři sestav mohli provádět souhrny sloupců určitými způsoby.When you need to ensure that your report authors can only summarize columns in specific ways. Například souhrn sloupce Unit Price (Jednotková cena) maloobchodního prodeje (který představuje cenu za jednotku) lze provést, ale jenom pomocí určitých agregačních funkcí.For example, the reseller sales Unit Price column (which represents a per unit rate) can be summarized, but only by using specific aggregation functions. U tohoto sloupce by se nikdy neměl provádět součet, ale je možné u něj provést souhrn pomocí jiných agregačních funkcí, jako je minimum, maximum, průměr atd. V tomto případě může modelátor sloupec Unit Price (Jednotková cena) skrýt a vytvořit míry pro všechny přípustné agregační funkce.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 přístup k návrhu funguje dobře pro sestavy vytvořené ve službě Power BI a pro Q&A.This design approach works well for reports authored in the Power BI service and for Q&A. Živá připojení Power BI Desktopu však autorům sestav umožňují zobrazit skrytá pole v podokně Pole, což může vést k obcházení tohoto pří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í klíčeSurrogate keys

Náhradní klíč je jedinečný identifikátor, který se do tabulky přidává kvůli podpoře modelování hvězdicového schématu.A surrogate key is a unique identifier that you add to a table to support star schema modeling. Z povahy věci se nedefinuje ani neuchovává ve zdrojových datech.By definition, it's not defined or stored in the source data. Náhradní klíče se obvykle přidávají do tabulek dimenzí relačního datového skladu proto, aby poskytovaly jedinečný identifikátor pro každý řádek tabulky dimenzí.Commonly, surrogate keys are added to relational data warehouse dimension tables to provide a unique identifier for each dimension table row.

Relace modelu Power BI jsou založené na jedinečném sloupci v jedné tabulce, který šíří filtry do jednoho sloupce v jiné tabulce.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. Pokud tabulka dimenzí v modelu neobsahuje jedinečný sloupec, je nutné přidat jedinečný identifikátor, který se stane v relaci stranou 1.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 Power BI Desktopu můžete požadavek snadno splnit vytvořením indexového sloupce Power Query.In Power BI Desktop, you can easily achieve this requirement by creating a Power Query index column.

Vytvoření indexového sloupce na panelu nástrojů Power Query

Tento dotaz musíte sloučit s dotazem strany N, abyste i do něj mohli přidat indexový sloupec.You must merge this query with the "many"-side query so that you can add the index column to it also. Když tyto dotazy načtete do modelu, můžete pak mezi tabulkami modelu vytvořit relaci 1:N.When you load these queries to the model, you can then create a one-to-many relationship between the model tables.

Vločkové dimenzeSnowflake dimensions

Vločková dimenze je sada normalizovaných tabulek pro jednu obchodní entitu.A snowflake dimension is a set of normalized tables for a single business entity. Například společnost Adventure Works třídí produkty podle kategorií a podkategorií.For example, Adventure Works classifies products by category and subcategory. Podkategorie jsou přiřazeny ke kategoriím a produkty jsou zase přiřazeny k podkategoriím.Categories are assigned to subcategories, and products are in turn assigned to subcategories. V relačním datovém skladu společnosti Adventure Works je dimenze produktů normalizována a uložena ve třech souvisejících tabulkách: DimProductCategory, DimProductSubcategory a DimProduct.In the Adventure Works relational data warehouse, the product dimension is normalized and stored in three related tables: DimProductCategory, DimProductSubcategory, and DimProduct.

S trochou fantazie si lze normalizované tabulky představit s umístěním vně tabulky faktů a tvořící vločkový návrh.If you use your imagination, you can picture the normalized tables positioned outwards from the fact table, forming a snowflake design.

Příklad vločkového diagramu

V Power BI Desktopu můžete zvolit napodobení návrhu vločkových dimenzí (třeba proto, že zdrojová data mají takovou podobu) nebo integrovat (denormalizovat) zdrojové tabulky do jediné tabulky modelu.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. Obecně platí, že výhody jediné tabulky modelu převažují nad výhodami více tabulek modelu.Generally, the benefits of a single model table outweigh the benefits of multiple model tables. Optimální rozhodnutí pro model může záviset na množství dat a požadavcích na použitelnost.The most optimal decision can depend on the volumes of data and the usability requirements for the model.

Pokud se rozhodnete napodobit návrh vločkové dimenze:When you choose to mimic a snowflake dimension design:

  • Power BI načítá více tabulek, což je méně efektivní z hlediska úložiště a výkonu.Power BI loads more tables, which is less efficient from storage and performance perspectives. Tyto tabulky musí obsahovat sloupce pro podporu relací modelu, což může mít za následek větší velikost modelu.These tables must include columns to support model relationships, and it can result in a larger model size.
  • Bude nutné procházet delší řetězce šíření filtrů relací, což bude pravděpodobně méně efektivní než filtry použité pro jedinou tabulku.Longer relationship filter propagation chains will need to be traversed, which will likely be less efficient than filters applied to a single table.
  • Podokno Pole nabízí autorům sestav více tabulek modelu, což může vést k méně intuitivnímu prostředí, zejména v případě, že tabulky vločkových dimenzí obsahují jenom jeden nebo dva sloupce.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.
  • Hierarchii, která zahrnuje tyto tabulky, není možné vytvořit.It's not possible to create a hierarchy that spans the tables.

Pokud se rozhodnete pro integraci do jediné tabulky modelu, můžete rovněž definovat hierarchii, která zahrnuje nejvyšší a nejnižší úroveň podrobností dané dimenze.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. Úložiště redundantních denormalizovaných dat může mít za následek zvýšení velikosti úložiště modelu, zejména pro velmi velké tabulky dimenzí.Possibly, the storage of redundant denormalized data can result in increased model storage size, particularly for very large dimension tables.

Hierarchie v rámci dimenze

Pomalu se měnící dimenzeSlowly changing dimensions

Pomalu se měnící dimenze je ta, která patřičně spravuje změny členů dimenze v průběhu času.A slowly changing dimension (SCD) is one that appropriately manages change of dimension members over time. Používá se, když se hodnoty obchodních entit mění v průběhu času a ad hoc.It applies when business entity values change over time, and in an ad hoc manner. Dobrým příkladem pomalu se měnící dimenze je dimenze zákazníků, konkrétně její sloupce s kontaktními údaji, jako jsou e-mailová adresa a telefonní číslo.A good example of a slowly changing dimension is a customer dimension, specifically its contact detail columns like email address and phone number. Některé dimenze se naopak považují za rychle se měnící, pokud se atribut dimenze často mění, například tržní cena akcií.In contrast, some dimensions are considered to be rapidly changing when a dimension attribute changes often, like a stock's market price. Běžným přístupem k návrhu v těchto případech je uchovávání rychle se měnících hodnot atributů v míře tabulky faktů.The common design approach in these instances is to store rapidly changing attribute values in a fact table measure.

Teorie návrhu hvězdicového schématu odkazuje na dva běžné typy pomalu se měnících dimenzí: typ 1 a typ 2.Star schema design theory refers to two common SCD types: Type 1 and Type 2. Tabulka dimenzí může být typu 1 nebo typu 2, nebo může pro různé sloupce podporovat oba typy současně.A dimension-type table could be Type 1 or Type 2, or support both types simultaneously for different columns.

Pomalu se měnící dimenze typu 1Type 1 SCD

Pomalu se měnící dimenze typu 1 vždy obsahují nejnovější hodnoty a po zjištění změn ve zdrojových datech se data tabulky dimenzí přepíšou.A Type 1 SCD always reflects the latest values, and when changes in source data are detected, the dimension table data is overwritten. Tento přístup k návrhu je běžný u sloupců, které uchovávají doplňkové hodnoty, jako je e-mailová adresa nebo telefonní čí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. Když se e-mailová adresa nebo telefonní číslo zákazníka změní, tabulka dimenzí aktualizuje řádek příslušného zákazníka novými hodnotami.When a customer email address or phone number changes, the dimension table updates the customer row with the new values. Je to, jako by zákazník měl vždycky tyto kontaktní údaje.It's as if the customer always had this contact information.

Výsledkem nepřírůstkové aktualizace tabulky dimenzí modelu Power BI je pomalu se měnící dimenze typu 1.A non-incremental refresh of a Power BI model dimension-type table achieves the result of a Type 1 SCD. Data tabulky se aktualizují, aby se zajistilo, že jsou načteny nejnovější hodnoty.It refreshes the table data to ensure the latest values are loaded.

Pomalu se měnící dimenze typu 2Type 2 SCD

Pomalu se měnící dimenze typu 2 podporují správu verzí členů dimenze.A Type 2 SCD supports versioning of dimension members. Pokud zdrojový systém neuchovává verze, pak je to obvykle proces načítání datového skladu, který zjišťuje změny a patřičně je spravuje v tabulce dimenzí.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 tom případě musí tabulka dimenzí používat náhradní klíč, který poskytuje jedinečný odkaz na verzi člena dimenze.In this case, the dimension table must use a surrogate key to provide a unique reference to a version of the dimension member. Obsahuje také sloupce definující dobu platnosti verze (např. StartDate a EndDate), případně sloupec s příznakem (např. IsCurrent), aby bylo možné snadno filtrovat podle aktuálních členů dimenze.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.

Společnost Adventure Works například přiřazuje prodejce k prodejní oblasti.For example, Adventure Works assigns salespeople to a sales region. Když se u některého prodejce změní oblast, je potřeba vytvořit novou verzi daného prodejce, aby se zajistilo, že historická fakta zůstanou přidružená k dřívější 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. Kvůli podpoře přesné historické analýzy prodeje podle prodejců musí tabulka dimenzí uchovávat verze prodejců a jejich přidružených oblastí.To support accurate historic analysis of sales by salesperson, the dimension table must store versions of salespeople and their associated region(s). Tabulka by měla také obsahovat hodnoty počátečních a koncových dat, které definují dobu platnosti.The table should also include start and end date values to define the time validity. Aktuální verze můžou definovat prázdné koncové datum (nebo 31. 12. 9999), což indikuje, že v příslušném řádku je aktuální verze.Current versions may define an empty end date (or 12/31/9999), which indicates that the row is the current version. Tabulka musí také definovat náhradní klíč, protože obchodní klíč (v tomto případě ID zaměstnance) nebývá 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é uvědomit si, že pokud zdrojová data neuchovávají verze, je nutné ke zjištění a uložení změn použít zprostředkující systém (například datový sklad).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čítání tabulky musí zachovat stávající data a zjistit změny.The table load process must preserve existing data and detect changes. Po zjištění změny musí proces načítání tabulky platnost aktuální verze ukončit.When a change is detected, the table load process must expire the current version. Změny zaznamená tak, že aktualizuje hodnotu EndDate a vloží novou verzi s hodnotou StartDate začínající od předchozí 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. Související fakty musí také pomocí časového vyhledávání načítat hodnotu klíče dimenze, která je relevantní pro datum daného faktu.Also, related facts must use a time-based lookup to retrieve the dimension key value relevant to the fact date. Model Power BI, který používá Power Query, tohoto výsledku nedosáhne.A Power BI model using Power Query can't produce this result. Může však načítat data z předem načtené tabulky dimenzí v pomalu se měnících dimenzích typu 2.It can, however, load data from a pre-loaded SCD Type 2 dimension table.

Model Power BI by měl podporovat dotazování na historická data člena bez ohledu na změnu a na verzi člena, která představuje konkrétní 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 kontextu společnosti Adventure Works tento návrh umožňuje dotazovat se na prodejce bez ohledu na přiřazenou prodejní oblast nebo na konkrétní verzi prodejce.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.

Aby se toho dosáhlo, musí tabulka dimenzí modelu Power BI obsahovat sloupec pro filtrování prodejce a další sloupec pro filtrování konkrétní verze prodejce.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 sloupec verze poskytoval jednoznačný popis, například „Michael Blythe (15. 12. 2008 – 26. 6. 2019)“ nebo „Michael Blythe (aktuální)“.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)". Je také důležité informovat autory sestav a uživatele o základech pomalu se měnících dimenzí typu 2 a o tom, jak použitím správných filtrů dosáhnout vhodných návrhů sestav.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.

Dobrým zvykem při návrhu je také použití hierarchie, která umožňuje ve vizuálech přejít k podrobnostem na úrovni verzí.It's also a good design practice to include a hierarchy that allows visuals to drill down to the version level.

Příklad hierarchie v seznamu polí

Výstup příkladu hierarchie

Dimenze rolíRole-playing dimensions

Dimenze role je dimenze, která umožňuje různé filtrování souvisejících faktů.A role-playing dimension is a dimension that can filter related facts differently. Například ve společnosti Adventure Works má tabulka dimenzí kalendářních dat tři relace k faktům maloobchodního prodeje.For example, at Adventure Works, the date dimension table has three relationships to the reseller sales facts. Stejnou tabulku dimenzí lze použít k filtrování faktů podle data objednávky, data expedice nebo data dodání.The same dimension table can be used to filter the facts by order date, ship date, or delivery date.

V datovém skladu je přijatelným přístupem k návrhu definování jediné tabulky dimenzí kalendářních dat.In a data warehouse, the accepted design approach is to define a single date dimension table. Při dotazu je „role“ dimenze kalendářních dat stanovena tím, který sloupec faktů pro propojení tabulek použijete.At query time, the "role" of the date dimension is established by which fact column you use to join the tables. Například při analýze prodeje podle data objednávky se propojení tabulek týká sloupce s daty objednávek maloobchodního prodeje.For example, when you analyze sales by order date, the table join relates to the reseller sales order date column.

V modelu Power BI lze tento návrh imitovat vytvořením několika relací mezi dvěma tabulkami.In a Power BI model, this design can be imitated by creating multiple relationships between two tables. V příkladu společnosti Adventure Works by tabulky kalendářních dat a maloobchodního prodeje měly tři relace.In the Adventure Works example, the date and reseller sales tables would have three relationships. To je sice možné, ale je důležité uvědomit si, že mezi dvěma tabulkami modelu Power BI může být jenom jedna aktivní relace.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šechny zbývající relace musí být nastavené jako neaktivní.All remaining relationships must be set to inactive. Jediná aktivní relace znamená, že výchozí šíření filtru probíhá od kalendářních dat k maloobchodnímu prodeji.Having a single active relationship means there is a default filter propagation from date to reseller sales. V tomto případě je aktivní relace nastavena na nejběžnější filtr, který sestavy používají, což je v Adventure Works relace data objednávky.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říklad jediné dimenze rolí a relací

Jediným způsobem, jak použít neaktivní relaci, je definovat výraz jazyka DAX, který používá funkci USERELATIONSHIP.The only way to use an inactive relationship is to define a DAX expression that uses the USERELATIONSHIP function. V našem příkladu musí vývojář modelu vytvořit míry, které umožní analýzu maloobchodního prodeje podle data expedice a data dodání.In our example, the model developer must create measures to enable analysis of reseller sales by ship date and delivery date. Taková práce může být zdlouhavá, zejména když tabulka prodejců definuje mnoho měr.This work can be tedious, especially when the reseller table defines many measures. Velké množství měr také způsobí, že se vytvoří nepotřebné prvky v podokně Pole.It also creates Fields pane clutter, with an overabundance of measures. Jsou tu i další omezení:There are other limitations, too:

  • Pokud autoři sestav používají místo definic měr spíše souhrny sloupců, nemůžou provést souhrny neaktivních relací bez toho, že by vytvořili míru na úrovni sestavy.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. Míry na úrovni sestavy lze definovat jenom při vytváření sestav v Power BI Desktopu.Report-level measures can only be defined when authoring reports in Power BI Desktop.
  • Když je mezi kalendářními daty a maloobchodním prodejem jenom jedna aktivní cesta relace, není možné filtrovat maloobchodní prodej současně podle různých typů kalendářních dat.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 například vytvořit vizuál, který znázorňuje data objednávek prodeje podle expedovaného prodeje.For example, you can't produce a visual that plots order date sales by shipped sales.

Běžnou technikou při modelování Power BI, která řeší tato omezení, je vytvoření tabulky dimenzí pro každou instanci rolí.To overcome these limitations, a common Power BI modeling technique is to create a dimension-type table for each role-playing instance. Obvykle pomocí jazyka DAX vytvoříte další tabulky dimenzí jako počítané tabulky.You typically create the additional dimension tables as calculated tables, using DAX. Při použití počítaných tabulek může model obsahovat tabulky Date (Datum), Ship Date (Datum expedice) a Delivery Date (Datum dodání), přičemž každá z nich bude mít jedinou a aktivní relaci k příslušným sloupcům tabulky maloobchodního prodeje.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říklad dimenzí rolí a relací

Tento přístup k návrhu nevyžaduje, abyste definovali více měr pro různé role kalendářních dat, a umožňuje současné filtrování podle různých rolí kalendářních dat.This design approach doesn't require you to define multiple measures for different date roles, and it allows simultaneous filtering by different date roles. Drobnou nevýhodou tohoto přístupu k návrhu je však duplicita tabulky dimenzí kalendářních dat, což má za následek zvýšení velikosti úložiště 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. Většinou to ale není důvod k obavám, protože tabulky dimenzí obvykle obsahují méně řádků než tabulky faktů.As dimension-type tables typically store fewer rows relative to fact-type tables, it is rarely a concern.

Při vytváření návrhu tabulek dimenzí modelu pro jednotlivé role dodržujte následující osvědčené postupy:Observe the following good design practices when you create model dimension-type tables for each role:

  • Zajistěte, aby názvy sloupců popisovaly samy sebe.Ensure that the column names are self-describing. Je sice možné mít ve všech tabulkách kalendářních dat sloupec Rok (názvy sloupců jsou jedinečné v rámci tabulky), ale nejedná se o názvy vizuálů, které standardně popisují samy sebe.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. Zvažte přejmenování sloupců v každé tabulce rolí dimenzí tak, aby tabulka Datum expedice měla sloupec pro rok s názvem Rok expedice atd.Consider renaming columns in each dimension role table, so that the Ship Date table has a year column named Ship Year, etc.
  • V případě potřeby zajistěte, aby popisy tabulek poskytovaly autorům sestav zpětnou vazbu (prostřednictvím popisů v podokně Pole) o konfiguraci šíření filtrů.When relevant, ensure that table descriptions provide feedback to report authors (through Fields pane tooltips) about how filter propagation is configured. Tato přehlednost je důležitá, když model obsahuje obecně pojmenovanou tabulku, například Datum, která se používá k filtrování mnoha tabulek faktů.This clarity is important when the model contains a generically named table, like Date, which is used to filter many fact-type tables. Když má tato tabulka například aktivní relaci se sloupcem dat objednávek maloobchodního prodeje, zvažte zadání popisu tabulky, třeba „Filtruje maloobchodní prodej podle data 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".

Další informace najdete v tématu Pokyny k aktivním a neaktivním relacím.For more information, see Active vs inactive relationship guidance.

Sběrné dimenzeJunk dimensions

Sběrná dimenze je užitečná v případě, že existuje mnoho dimenzí, zejména když jsou tyto dimenze tvořeny malým počtem atributů (třeba jedním) a tyto atributy mají málo hodnot.A junk dimension is useful when there are many dimensions, especially consisting of few attributes (perhaps one), and when these attributes have few values. Mezi vhodné kandidáty patří sloupce se stavem objednávky nebo sloupce s demografickými údaji o zákazníkovi (pohlaví, věková skupina atd.).Good candidates include order status columns, or customer demographic columns (gender, age group, etc.).

Cílem návrhu sběrné dimenze je sloučení mnoha „malých“ dimenzí do jediné dimenze, aby se zmenšila velikost úložiště modelu a také aby se díky menšímu počtu tabulek modelu omezily nepotřebné prvky v podokně Pole.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.

Tabulka sběrných dimenzí je obvykle kartézský součin všech členů atributů dimenzí a obsahuje sloupec s náhradním klíčem.A junk dimension table is typically the Cartesian product of all dimension attribute members, with a surrogate key column. Náhradní klíč poskytuje jedinečný odkaz na každý řádek v tabulce.The surrogate key provides a unique reference to each row in the table. Dimenzi můžete sestavit v datovém skladu, nebo můžete pomocí Power Query vytvořit dotaz, který provede úplné vnější spojení a pak přidá náhradní klíč (indexový sloupec).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říklad sběrné dimenze

Tento dotaz načtete do modelu jako tabulku dimenzí.You load this query to the model as a dimension-type table. Tento dotaz je také nutné sloučit s dotazem na fakty, a proto se do modelu načte indexový sloupec pro podporu vytvoření relace modelu 1:N.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.

Degenerované dimenzeDegenerate dimensions

Degenerovaná dimenze odkazuje na atribut tabulky faktů, který se vyžaduje pro filtrování.A degenerate dimension refers to an attribute of the fact table that is required for filtering. Dobrým příkladem je číslo objednávky maloobchodního prodeje v Adventure Works.At Adventure Works, the reseller sales order number is a good example. V tomto případě nemá smysl při návrhu modelu vytvářet nezávislou tabulku, která by byla tvořena jenom tímto jedním sloupcem, protože by se tím zvýšila velikost úložiště modelu a v podokně Pole by byly nepotřebné prvky.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 modelu Power BI může být vhodné přidat do tabulky faktů sloupec s čísly prodejních objednávek, aby bylo možné filtrovat nebo seskupovat podle čísla prodejní 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. Jedná se o výjimku z výše uvedeného pravidla, že typy tabulek by se neměly kombinovat (tabulky modelu by obecně měly být buď typu dimenzí, nebo typu faktů).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říklad degenerované dimenze

Pokud ale tabulka maloobchodních prodejů společnosti Adventure Works Sales obsahuje sloupec čísel objednávek a sloupec čísel řádků objednávek a tyto sloupce jsou požadovány pro filtrování, je vhodné vytvořit tabulku degenerované dimenze.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. Další informace najdete v tématu Pokyny k relacím 1:1 (degenerované dimenze).For more information, see One-to-one relationship guidance (Degenerate dimensions).

Tabulky faktů bez ukazatelůFactless fact tables

Tabulka faktů bez ukazatelů neobsahuje žádné sloupce měr.A factless fact table doesn't include any measure columns. Obsahuje jenom klíče dimenzí.It contains only dimension keys.

Tabulka faktů bez ukazatelů může uchovávat pozorování definovaná pomocí klíčů dimenzí.A factless fact table could store observations defined by dimension keys. Například v určitém datu a čase se k vašemu webu přihlásil určitý zákazník.For example, at a particular date and time, a particular customer logged into your web site. Můžete definovat míru, která počítá řádky tabulky faktů bez ukazatelů, aby se mohla provést analýza, kdy a kolik zákazníků se přihlá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.

Zajímavějším využitím tabulky faktů bez ukazatelů je uchovávání relací mezi dimenzemi a tento přístup k návrhu modelu Power BI doporučujeme pro definování relací dimenzí M:M.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. V návrhu relací dimenzí M:M se tabulka faktů bez ukazatelů označuje jako tabulka přemostění.In a many-to-many dimension relationship design, the factless fact table is referred to as a bridging table.

Představme si například, že prodejce je možné přiřadit k jedné nebo více prodejních oblastí.For example, consider that salespeople can be assigned to one or more sales regions. Tabulka přemostění by se navrhla jako tabulka faktů bez ukazatelů, kterou tvoří dva sloupce: klíč prodejce a klíč oblasti.The bridging table would be designed as a factless fact table consisting of two columns: salesperson key and region key. V obou sloupcích můžou být uloženy duplicitní hodnoty.Duplicate values can be stored in both columns.

Příklad tabulky faktů bez ukazatelů

Přístup k návrhu M:M je dobře zdokumentovaný a je možné ho použít bez tabulky přemostění.This many-to-many design approach is well documented, and it can be achieved without a bridging table. Pro vytvoření relace mezi dvěma dimenzemi se však použití tabulky přemostění považuje za nejlepší postup.However, the bridging table approach is considered the best practice when relating two dimensions. Další informace najdete v tématu Pokyny k relacím M:N (spojení dvou tabulek typu dimenze).For more information, see Many-to-many relationship guidance (Relate two dimension-type tables).

Další krokyNext steps

Další informace o návrhu hvězdicového schématu nebo návrhu modelu Power BI najdete v těchto článcích:For more information about star schema design or Power BI model design, see the following articles: