Sdílet prostřednictvím

Vysvětlení hvězdicového schématu a důležitosti pro Power BI

  • Článek

Tento článek se zaměřuje na modelátory dat Power BI Desktopu. Popisuje návrh hvězdicového schématu a jeho význam pro vývoj sémantických modelů Power BI optimalizovaných pro výkon a použitelnost.

Důležité

Sémantické modely Power BI závisí na Power Query při importu nebo připojení k datům. To znamená, že k transformaci a přípravě zdrojových dat musíte použít Power Query , což může být náročné, pokud máte velké objemy dat nebo potřebujete implementovat pokročilé koncepty, jako jsou pomalé změny dimenzí (popsané dále v tomto článku).

Při prezentování těchto výzev doporučujeme nejprve vyvinout procesy datového skladu a extrakce, transformace a načítání (ETL), které budou pravidelně načítat datový sklad. Sémantický model se pak může připojit k datovému skladu. Další informace naleznete v tématu Dimenzionální modelování v Microsoft Fabric Warehouse.

Tip

Tento článek nemá v úmyslu poskytnout úplnou diskuzi o návrhu hvězdicového schématu. Další informace najdete přímo na široce přijímaný publikovaný obsah, například The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3. vydání, 2013) od Ralph Kimball a dalších.

Přehled hvězdicové schéma

Hvězdicové schéma je vyspělý přístup k modelování široce přijímaný relačními datovými sklady. Vyžaduje, aby modelátoři klasifikovali tabulky modelu jako dimenze nebo fakta.

  • Tabulky dimenzí popisují obchodní entity – věci, které modelujete. Entity můžou zahrnovat produkty, lidi, místa a koncepty včetně samotného času. Nejkonzistence tabulky, kterou najdete ve hvězdicovém schématu, je tabulka dimenzí kalendářních dat. Tabulka dimenzí obsahuje klíčový sloupec (nebo sloupce), který funguje jako jedinečný identifikátor a další sloupce. Ostatní sloupce podporují filtrování a seskupování dat.
  • Tabulky faktů ukládají pozorování nebo události a mohou to být prodejní objednávky, zůstatky zásob, směnné kurzy, teploty a další. Tabulka faktů obsahuje klíčové sloupce dimenzí, které souvisejí s tabulkami dimenzí a sloupci číselné míry. Klíčové sloupce dimenze určují dimenzionalitu tabulky faktů, zatímco hodnoty klíče dimenze určují členitost tabulky faktů. Představte si například tabulku faktů navrženou tak, aby ukládaly cíle prodeje, které mají dva klíčové sloupce Date dimenzí a ProductKey. Je snadné pochopit, že tabulka má dvě dimenze. Členitost však nelze určit bez ohledu na hodnoty klíče dimenze. V tomto příkladu vezměte v úvahu, že hodnoty uložené ve Date sloupci jsou prvním dnem každého měsíce. V tomto případě je členitost na úrovni měsíčního produktu.

Obecně platí, že tabulky dimenzí obsahují relativně malý počet řádků. Tabulky faktů na druhé straně můžou obsahovat velký počet řádků a v průběhu času se stále zvětšovat.

Diagram znázorňující ilustraci hvězdicového schématu

Normalizace vs. denormalizace

Abyste pochopili některé koncepty hvězdicových schémat popsaných v tomto článku, je důležité znát dva termíny: normalizaci a denormalizaci.

Normalizace je termín použitý k popisu dat uložených způsobem, který repetitní data snižuje. Představte si tabulku produktů, která má sloupec jedinečné klíčové hodnoty, například kód Product Key, a další sloupce, které popisují vlastnosti produktu, jako je název produktu, kategorie, barva a velikost. Tabulka prodejů se považuje za normalizovanou, když ukládá jenom klíče, jako je kód Product Key. Na následujícím obrázku si všimněte, že pouze ProductKey sloupec zaznamenává produkt.

Diagram znázorňující tabulku dat, která obsahuje sloupec Kód Product Key

Pokud ale tabulka sales ukládá podrobnosti o produktu nad rámec tohoto klíče, považuje se za nenormalizovaný. Na následujícím obrázku si všimněte, že ProductKey sloupce a další sloupce související s produktem zaznamenávají produkt.

Diagram znázorňující tabulku dat, která obsahují kód Product Key a další sloupce související s produktem, včetně kategorie, barvy a velikosti

Když zdrojujete data ze souboru exportu nebo extrahování dat, je pravděpodobné, že představuje denormalizovanou sadu dat. V tomto případě pomocí Power Query transformujte a tvarujte zdrojová data do několika normalizovaných tabulek.

Jak je popsáno v tomto článku, měli byste se snažit vyvíjet optimalizované sémantické modely Power BI s tabulkami, které představují normalizovaná data faktů a dimenzí. Existuje však jedna výjimka, kdy může být dimenze sněhové vločky denormalizována, aby se vytvořila jedna tabulka modelu.

Relevance hvězdicových schémat pro sémantické modely Power BI

Návrh hvězdicového schématu a mnoho souvisejících konceptů představených v tomto článku jsou vysoce relevantní pro vývoj modelů Power BI, které jsou optimalizované pro výkon a použitelnost.

Vezměte v úvahu, že každý vizuál sestavy Power BI generuje dotaz, který se odešle do sémantického modelu Power BI. Obecně platí, že dotazy filtrují, seskupují a shrnují data modelu. Dobře navržený model je pak ten, který poskytuje tabulky pro filtrování a seskupování a tabulky pro shrnutí. Tento návrh dobře odpovídá principům hvězdicového schématu:

  • Tabulky dimenzí umožňují filtrování a seskupení.
  • Tabulky faktů umožňují sumarizaci.

Neexistuje žádná vlastnost tabulky, kterou modelátoři nastavují tak, aby typ tabulky nastavily jako dimenzi nebo fakta. Ve skutečnosti je určen relacemi modelu. Relace modelu vytvoří cestu šíření filtru mezi dvěma tabulkami a je to vlastnost kardinality relace, která určuje typ tabulky. Společná kardinalita relace je 1:N nebo její inverzní funkce M:1. Strana "jedna" je vždy tabulka dimenzí, zatímco strana N je vždy tabulkou faktů.

Diagram znázorňující koncepční ilustraci hvězdicového schématu

Dobře strukturovaný návrh modelu zahrnuje tabulky, které jsou tabulky dimenzí nebo tabulky faktů. Vyhněte se kombinování těchto dvou typů pro jednu tabulku. Doporučujeme také, abyste se snažili zajistit správný počet tabulek se správnými relacemi. Je také důležité, aby tabulky faktů vždy načítá data s konzistentním agregačním intervalem.

Nakonec je důležité pochopit, že optimální návrh modelu je part science and part art. Někdy se můžete porušit dobrými pokyny, když to dává smysl.

Existuje mnoho konceptů souvisejících s návrhem hvězdicového schématu, které je možné použít u sémantického modelu Power BI. Mezi tyto koncepty patří:

Opatření

V návrhu hvězdicového schématu je míra sloupec tabulky faktů, který ukládá hodnoty, které se mají shrnout. V sémantickém modelu Power BI má míra jinou ( ale podobnou) definici. Model podporuje explicitní i implicitní míry.

  • Explicitní míry se explicitně vytvářejí a jsou založené na vzorci napsaného v jazyce DAX (Data Analysis Expressions), který umožňuje sumarizaci. Výrazy měr často používají agregační funkce jazyka DAX, jako jsou SUM, MIN, MAXAVERAGEa další k vytvoření výsledku skalární hodnoty v době dotazu (hodnoty se nikdy neukládají v modelu). Výraz míry může být v rozsahu od jednoduchých agregací sloupců až po sofistikovanější vzorce, které přepisují kontext filtru nebo šíření relací. Další informace najdete v tématu Základy jazyka DAX v Power BI Desktopu.
  • Implicitní míry jsou sloupce, které lze shrnout vizuálem sestavy nebo Q&A. Nabízejí vám pohodlí jako vývojář modelu, protože v mnoha případech nemusíte vytvářet (explicitní) míry. Například sloupec prodejů Sales Amount prodejců Adventure Works lze shrnout mnoha způsoby (součet, počet, průměr, medián, minimum, maximum a další), aniž by bylo nutné vytvořit míru pro každý možný typ agregace.

V podokně Data jsou explicitní míry reprezentovány ikonou kalkulačky, zatímco implicitní míry jsou reprezentovány symbolem sigma (∑).

Diagram znázorňující ikony nalezené v podokně Data

Existují však tři přesvědčivé důvody, proč můžete vytvářet míry, a to i pro jednoduché souhrny na úrovni sloupců:

  • Pokud víte, že autoři sestav budou dotazovat sémantický model pomocí multidimenzionálních výrazů (MDX), musí model obsahovat explicitní míry. Důvodem je to, že MDX nemůže dosáhnout souhrnu hodnot sloupců. Při provádění funkce Analyzovat v aplikaci Excel se používá zejména jazyk MDX, protože kontingenční tabulky vydávají dotazy MDX.

  • Pokud víte, že autoři sestav vytvoří stránkované sestavy Power BI pomocí návrháře dotazů MDX, musí sémantický model obsahovat explicitní míry. Agregace serverů podporuje pouze návrhář dotazů MDX. Takže pokud autoři sestav potřebují mít míry vyhodnocené Power BI (nikoli stránkovaným modulem sestav), musí použít návrháře dotazů MDX.

  • Pokud chcete řídit, jak autoři sestav shrnují sloupce určitými způsoby. Například sloupec prodejů Unit Price prodejců (který představuje jednotkovou sazbu), lze shrnout, ale pouze pomocí konkrétních agregačních funkcí. Nikdy by se neměl sečíst, ale je vhodné shrnout pomocí jiných agregačních funkcí, jako je min, maximum nebo průměr. V tomto případě může modeler sloupec skrýt Unit Price a vytvořit míry pro všechny příslušné agregační funkce.

    Tento přístup k návrhu funguje dobře pro sestavy vytvořené v služba Power BI a pro Q&A. Živá připojení Power BI Desktopu ale autorům sestav umožňují zobrazit skrytá pole v podokně Data, což může vést k obcházení tohoto přístupu k návrhu.

Náhradní klíče

Náhradní klíč je jedinečný identifikátor, který přidáte do tabulky pro podporu modelování hvězdicového schématu. Podle definice není definován nebo uložen ve zdrojových datech. Do tabulek dimenzí relačního datového skladu se obvykle přidávají náhradní klíče, které poskytují jedinečný identifikátor pro každý řádek tabulky dimenzí.

Sémantické relace modelu Power BI jsou založené na jednom jedinečném sloupci v jedné tabulce, který šíří filtry do jednoho sloupce v jiné tabulce. Pokud tabulka dimenzí v sémantickém modelu neobsahuje jediný jedinečný sloupec, musíte přidat jedinečný identifikátor, který se stane stranou 1 relace. V Power BI Desktopu můžete tohoto požadavku dosáhnout přidáním indexového sloupce Power Query.

Diagram znázorňující příkaz Vytvořit indexový sloupec v Editor Power Query

Tento dotaz musíte sloučit s dotazem na straně N, abyste do něj mohli přidat také indexový sloupec. Když tyto dotazy načtete do sémantického modelu, můžete mezi tabulkami modelu vytvořit relaci 1:N.

Sněhové vločkové rozměry

Dimenze sněhové vločky je sada normalizovaných tabulek pro jednu obchodní entitu. Například Adventure Works klasifikuje produkty podle kategorie a podkategorie. Produkty se přiřazují k podkategorií a podkategorie jsou zase přiřazené kategoriím. V relačním datovém skladu Společnosti Adventure Works je dimenze produktu normalizována a uložena ve třech souvisejících tabulkách: DimProductCategory, DimProductSubcategorya DimProduct.

Diagram znázorňující příklad sněhového vločkového diagramu, který obsahuje tři související tabulky

Pokud používáte svoji fantazii, můžete si představit normalizované tabulky umístěné ven z tabulky faktů, které tvoří sněhové vločky návrh.

Diagram znázorňující koncepční příklad sněhového vločkového diagramu, který obsahuje tři související tabulky

V Power BI Desktopu můžete napodobit návrh sněhové vločkové dimenze (možná proto, že zdrojová data dělá) nebo zkombinovat zdrojové tabulky a vytvořit jednu denormalizovanou tabulku modelu. Obecně platí, že výhody jedné tabulky modelu převáží nad výhodami více tabulek modelu. Nejoptimálnější rozhodnutí může záviset na objemech dat a požadavcích na použitelnost modelu.

Když se rozhodnete napodobovat návrh sněhové vločkové dimenze:

  • Power BI načte více tabulek, což je méně efektivní z hlediska úložiště a výkonu. Tyto tabulky musí obsahovat sloupce pro podporu relací modelu a výsledkem může být větší velikost modelu.
  • Delší řetězce šíření filtru relací je potřeba projít, což může být méně efektivní než filtry použité u jedné tabulky.
  • Podokno Data představuje 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 dimenzí sněhové vločky obsahují pouze jeden nebo dva sloupce.
  • Není možné vytvořit hierarchii, která se skládá ze sloupců z více než jedné tabulky.

Když se rozhodnete integrovat do jedné tabulky modelu, můžete také definovat hierarchii, která zahrnuje nejvyšší a nejnižší úroveň dimenze. Úložiště redundantních denormalizovaných dat může mít za následek větší velikost úložiště modelu, zejména u velkých tabulek dimenzí.

Diagram znázorňující příklad hierarchie v tabulce dimenzí, která obsahuje sloupce, jako jsou Category (Kategorie), Subcategory (Podkategorie) a Product (Produkt).

Pomalu se měnící dimenze

Pomalu se měnící dimenze (neboli SCD) je ta , která v průběhu času správně spravuje změnu členů dimenze. Platí, když se hodnoty obchodních entit pomalu mění v průběhu času neplánovaným způsobem. Dobrým příkladem SCD je dimenze zákazníka, protože sloupce podrobností o kontaktu, jako jsou e-mailová adresa a telefonní číslo, se mění zřídka. Naproti tomu některé dimenze se považují za rychle se měnící, když se atribut dimenze často mění, například tržní cena akcie. Běžným přístupem k návrhu v těchto instancích je ukládání rychle se měnících hodnot atributů do míry tabulky faktů.

Teorie návrhu hvězdicového schématu odkazuje na dva běžné typy SCD: Typ 1 a Typ 2. Tabulka dimenzí může být Typu 1 nebo Typ 2 nebo podporuje oba typy současně pro různé sloupce.

Typ 1 – SCD

ScD typu 1 vždy odráží nejnovější hodnoty a při zjištění změn zdrojových dat se přepíšou data tabulky dimenzí. Tento přístup k návrhu je běžný u sloupců, které ukládají doplňkové hodnoty, například e-mailovou adresu nebo telefonní číslo zákazníka. Když se změní e-mailová adresa zákazníka nebo telefonní číslo, tabulka dimenzí aktualizuje řádek zákazníka o nové hodnoty. Je to jako by zákazník měl vždy tyto kontaktní informace.

Diagram znázorňující příklad pomalu se měnícího typu dimenze 1, kde se aktualizuje telefonní číslo zaměstnance

Nekrementální aktualizace tabulky dimenzí modelu Power BI dosáhne výsledku scD typu 1. Aktualizuje data tabulky, aby se zajistilo načtení nejnovějších hodnot.

Typ 2 – SCD

ScD typu 2 podporuje správu verzí členů dimenze. Pokud zdrojový systém neukládá verze, obvykle se jedná o proces načítání datového skladu, který detekuje změny a správně spravuje změnu v tabulce dimenzí. V tomto případě musí tabulka dimenzí použít náhradní klíč k poskytnutí jedinečného odkazu na verzi člena dimenze. Obsahuje také sloupce, které definují platnost rozsahu dat verze (například StartDate a EndDate) a případně sloupec příznaku (například IsCurrent) pro snadné filtrování podle aktuálních členů dimenze.

Například Adventure Works přiřadí každému prodejci prodejní oblast. Když prodejce přemístí oblast, musí být vytvořena nová verze prodejce, aby se zajistilo, že historická fakta zůstanou přidružená k bývalé oblasti. Aby byla podpora přesné historické analýzy prodeje podle prodejce, musí tabulka dimenzí ukládat verze prodejců a jejich přidružených oblastí. Tabulka by také měla obsahovat hodnoty počátečního a koncového data pro definování doby platnosti. Aktuální verze můžou definovat prázdné koncové datum (nebo 12. 31. 9999), které označuje, že řádek je aktuální verzí. Tabulka musí mít také náhradní klíč , protože obchodní klíč (v tomto případě ID zaměstnance) nebude jedinečný.

Diagram znázorňující příklad pomalu se měnícího typu dimenze 2, kde je oblast prodeje zaměstnanců aktualizována vytvořením nové verze

Je důležité vědět, že pokud zdrojová data neukládají verze, musíte k detekci a uložení změn použít zprostředkující systém (například datový sklad). Proces načtení tabulky musí zachovat existující data a detekovat změny. Po zjištění změny musí proces načtení tabulky vypršet aktuální verzi. Tyto změny zaznamenává aktualizací EndDate hodnoty a vložením nové verze s StartDate hodnotou začínající od předchozí EndDate hodnoty. Související fakta také musí použít vyhledávání založené na čase k načtení hodnoty klíče dimenze relevantní pro datum faktu. Sémantický model Power BI používá Power Query, takže nemůže tento výsledek vytvořit. Může ale načíst data z předem načtené tabulky dimenzí TYPU 2.

Tip

Informace o implementaci tabulky dimenzí SCD typu 2 v skladu Fabric najdete v tématu Správa historických změn.

Sémantický model Power BI by měl podporovat dotazování historických dat pro člena bez ohledu na změnu a pro verzi člena, která představuje konkrétní stav člena v čase. V kontextu společnosti Adventure Works umožňuje tento návrh dotazovat prodejce bez ohledu na přiřazenou prodejní oblast nebo pro konkrétní verzi prodejce.

K dosažení tohoto požadavku musí tabulka dimenzí sémantického modelu Power BI obsahovat sloupec pro filtrování prodejce a jiný sloupec pro filtrování konkrétní verze prodejce. Je důležité, aby sloupec verze poskytoval nejednoznačný popis, například David Campbell (12/15/2008-06/26/2019) nebo David Campbell (06/27/2019-Current). Je také důležité informovat autory sestav a uživatele o základech SCD Type 2 a o tom, jak dosáhnout vhodných návrhů sestav pomocí správných filtrů.

Osvědčeným postupem návrhu je zahrnout hierarchii, která umožňuje vizuálům přejít k podrobnostem na úrovni verze.

Diagram znázorňující podokno Data se sloupci pro prodejce a verzi prodejce

Dimenze role

Dimenze role je dimenze , která může filtrovat související fakta odlišně. Například v Adventure Works tabulka dimenzí kalendářních dat má tři relace k faktům prodeje prodejců. Stejnou tabulku dimenzí lze použít k filtrování faktů podle data objednávky, data expedice nebo data doručení.

Diagram znázorňující koncepční příklad jedné dimenze role a vztahů Tabulka Date (Datum) má dvě relace s tabulkou faktů pro datum objednávky a datum expedice.

V datovém skladu je akceptovaným přístupem k návrhu definovat jednu tabulku dimenzí kalendářních dat. V době dotazu je "role" dimenze data stanovena sloupcem faktů, který používáte ke spojení tabulek. Když například analyzujete prodej podle data objednávky, spojení tabulky se vztahuje ke sloupci data prodejní objednávky prodejce.

V sémantickém modelu Power BI může být tento návrh napodobován vytvořením více relací mezi dvěma tabulkami. V příkladu Adventure Works by tabulky kalendářních dat a prodejů prodejců měly tři relace.

Diagram znázorňující příklad jedné dimenze role a vztahů Tabulka Kalendářní data má tři relace s tabulkou faktů.

I když je tento návrh možný, může existovat pouze jedna aktivní relace mezi dvěma tabulkami sémantických modelů Power BI. Všechny zbývající relace musí být nastavené na neaktivní. Když máte jednu aktivní relaci, znamená to, že existuje výchozí šíření filtru od data po prodej prodejců. V tomto případě je aktivní relace nastavená na nejběžnější filtr používaný sestavou, který v Adventure Works představuje relaci data objednávky.

Jediným způsobem, jak použít neaktivní relaci, je definovat výraz DAX, který používá funkci USERELATIONSHIP . V našem příkladu musí vývojář modelu vytvořit míry, které umožní analýzu prodeje prodejců podle data expedice a data doručení. Tato práce může být zdlouhavá, zejména pokud tabulka prodejců definuje mnoho měr. Vytvoří také nepotřebné podokno Data , které má nadlimitnost měr. Existují i další omezení:

  • Když autoři sestav spoléhají na sumarizaci sloupců místo definování měr, nemůžou dosáhnout souhrnu neaktivních relací, aniž by museli psát míru na úrovni sestavy. Míry na úrovni sestav se dají definovat jenom při vytváření sestav v Power BI Desktopu.
  • S pouze jednou aktivní cestou relace mezi datem a prodejem prodejců není možné současně filtrovat prodej prodejců podle různých typů kalendářních dat. Nemůžete například vytvořit vizuál, který vykresluje prodej data objednávky podle expedovaných prodejů.

Pro vyřešení těchto omezení je běžnou technikou modelování Power BI vytvoření tabulky dimenzí pro každou instanci role. Každou tabulku dimenzí můžete vytvořit jako odkazující dotaz pomocí Power Query nebo počítané tabulky pomocí jazyka DAX. Model může obsahovat Date tabulku, Ship Date tabulku a Delivery Date tabulku, z nichž každá má jednu a aktivní relaci se sloupci příslušné tabulky prodejů prodejců.

Diagram znázorňující příklad dimenzí rolí a vztahů Existují tři různé tabulky dimenzí kalendářních dat, které souvisejí s tabulkou faktů.

Tento přístup k návrhu nevyžaduje definování více měr pro různé role kalendářních dat a umožňuje souběžné filtrování podle různých rolí kalendářních dat. Menší cena za platbu tímto přístupem k návrhu však spočívá v tom, že bude duplicitní tabulka dimenzí kalendářních dat, což vede ke zvýšení velikosti úložiště modelu. Vzhledem k tomu, že tabulky dimenzí obvykle ukládají méně řádků vzhledem k tabulkám faktů, je to jen zřídkakdy problém.

Při vytváření tabulek dimenzí modelu pro každou roli doporučujeme postupovat podle osvědčených postupů návrhu:

  • Ujistěte se, že názvy sloupců popisují samy sebe. I když je možné mít Year sloupec ve všech tabulkách kalendářních dat (názvy sloupců jsou jedinečné v rámci tabulky), ve výchozím nastavení se názvy vizuálů nepopisují samostatně. Zvažte přejmenování sloupců v každé tabulce rolí dimenzí tak, aby Ship Date tabulka má sloupec s názvem Ship Yearrok atd.
  • Pokud je to relevantní, ujistěte se, že popisy tabulek poskytují autorům sestav zpětnou vazbu (prostřednictvím popisů podokna dat ) o nastavení šíření filtru. Tato přehlednost je důležitá, když model obsahuje obecně pojmenovanou tabulku, například Date, která se používá k filtrování mnoha tabulek faktů. V případě, že má tato tabulka například aktivní relaci se sloupcem data prodejní objednávky prodejce, zvažte zadání popisu tabulky, například Filters reseller sales by order date.

Další informace najdete v tématu Aktivní vs. Pokyny k neaktivním relacím.

Rozměry nevyžádané pošty

Nevyžádaná dimenze je užitečná, pokud existuje mnoho dimenzí, zejména skládající se z několika atributů (třeba jednoho) a když mají tyto atributy několik hodnot. Mezi vhodné kandidáty patří sloupce stavu objednávky nebo demografické sloupce zákazníků, jako je pohlaví nebo věková skupina.

Cílem návrhu nevyžádané dimenze je konsolidovat mnoho malých dimenzí do jedné dimenze, aby se zmenšila velikost úložiště modelu, a také zmenšit nepotřebné podokno dat tím, že zmenšuje méně tabulek modelu.

Tabulka nevyžádaných dimenzí je obvykle kartézský součin všech členů atributů dimenze s náhradním klíčovým sloupcem pro jedinečnou identifikaci jednotlivých řádků. Dimenzi můžete vytvořit v datovém skladu nebo pomocí Power Query vytvořit dotaz, který provede úplné spojení s vnějšími dotazy, a pak přidá náhradní klíč (indexový sloupec).

Diagram znázorňující příklad tabulky nevyžádaných dimenzí Stav objednávky má tři stavy, zatímco stav doručení má dva stavy. Tabulka nevyžádaných dimenzí ukládá všech šest kombinací těchto dvou stavů.

Tento dotaz načtete do modelu jako tabulku dimenzí. Tento dotaz také musíte sloučit s dotazem faktů, aby se indexový sloupec načetl do modelu, aby podporoval vytvoření relace modelu 1:N.

Degenerované dimenze

Degenerační dimenze odkazuje na atribut tabulky faktů, který je nutný pro filtrování. V Adventure Works je dobrým příkladem číslo prodejní objednávky prodejce. V tomto případě nemá smysl vytvořit nezávislou tabulku, která se skládá jenom z tohoto sloupce, protože by se zvětšila velikost úložiště modelu a v podokně Data byla nepotřebná.

V sémantickém modelu Power BI může být vhodné přidat sloupec čísla prodejní objednávky do tabulky faktů, aby bylo možné filtrovat nebo seskupovat podle čísla prodejní objednávky. Jedná se o výjimku z dříve zavedeného pravidla, které byste neměli kombinovat typy tabulek (obecně by tabulky modelu měly být dimenze nebo fakt).

Diagram znázorňující podokno Data a tabulku faktů prodeje, která obsahuje pole Číslo objednávky

Pokud má tabulka prodejů Adventure Works číslo objednávky a čísla řádku objednávky a jsou potřeba k filtrování, vytvoření degenerované tabulky dimenzí by ale bylo dobrým návrhem. Další informace najdete v tématu Pokyny k relacím 1:1 (degenerované dimenze).

Tabulky faktů bez faktů

Tabulka faktů bez faktů neobsahuje žádné sloupce měr. Obsahuje pouze klíče dimenzí.

Tabulka faktů bez faktů může ukládat pozorování definovaná klíči dimenzí. Například v určitém datu a čase se konkrétní zákazník přihlásil k vašemu webu. Můžete definovat míru, která spočítá řádky tabulky faktů bez faktů, abyste mohli provádět analýzu, kdy a kolik zákazníků se přihlásilo.

Poutavějším použitím tabulky faktů bez faktů je ukládání relací mezi dimenzemi a jedná se o sémantický přístup k návrhu modelu Power BI, který doporučujeme definovat relace dimenzí M:N. V návrhu relací dimenzí M:N se tabulka faktů bez faktů označuje jako přemostění tabulky.

Představte si například, že prodejce je možné přiřadit k jedné nebo více prodejním oblastem. Tabulka přemostění by byla navržena jako tabulka faktů bez faktů skládající se ze dvou sloupců: klíč prodejce a klíč oblasti. Duplicitní hodnoty lze uložit do obou sloupců.

Diagram znázorňující tabulku faktů bez faktů přemostění dimenzí Prodejce a Oblast Tabulka faktů bez faktů obsahuje dva sloupce, což jsou klíče dimenzí.

Tento přístup návrhu M:N je dobře zdokumentovaný a dá se dosáhnout bez přemostění tabulky. Přístup k přemostění tabulky se však považuje za osvědčený postup při spojování dvou dimenzí. Další informace najdete v tématu Pokyny k relacím M:N (Propojení dvou tabulek typu dimenze).

Související obsah

Další informace o návrhu hvězdicového schématu nebo návrhu sémantického modelu Power BI najdete v následujících článcích: