Zdieľať cez

Vysvetlenie hviezdicovej schémy a jej dôležitosti pre Power BI

  • Článok

Tento článok sa zameriava na modelárov údajov v aplikácii Power BI Desktop. Popisuje sa v ňom návrh hviezdicovej schémy a jej význam pre vývoj sémantických modelov Power BI optimalizovaných z hľadiska výkonu a použiteľnosti.

Dôležité

Sémantické modely služby Power BI závisia od doplnku Power Query z importu údajov alebo od pripojenia k údajom. To znamená, že na transformáciu a prípravu zdrojových údajov musíte použiť Doplnok Power Query , čo môže byť náročné, ak máte veľké objemy údajov, alebo ak potrebujete implementovať pokročilé koncepty, ako napríklad pomaly sa meniace dimenzie (popis nájdete ďalej v tomto článku).

Pred vtedy, keď sa vám zobrazia tieto výzvy, odporúčame najskôr vyvinúť sklad údajov a procesy extrahovania, transformácie a načítania (ETL), aby ste mohli pravidelne načítavať sklad údajov. Váš sémantický model sa potom môže pripojiť k skladu údajov. Ďalšie informácie nájdete v téme Dimenzionálne modelovanie v sklade služby Microsoft Fabric.

Prepitné

Cieľom tohto článku nie je poskytnúť kompletné informácie o návrhu hviezdicovej schémy. Ďalšie informácie nájdete priamo v široko prijatom 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 ďalší.

Prehľad hviezdicovej schémy

Hviezdicová schéma predstavuje vyspelý prístup k modelovaniu, často používaný v skladoch relačných údajov. Vyžaduje sa, aby modelári klasifikovali svoje tabuľky modelov ako tabuľku dimenzií alebo tabuľku faktov.

  • Tabuľky dimenzií popisujú podnikové entity – veci, ktoré modelujete. Entity môžu zahŕňať produkty, ľudí, miesta a koncepty vrátane samotného času. Naj konzistentnejšia tabuľka, ktorú vo hviezdicovej schéme nájdete, je dátumová tabuľka dimenzií. Tabuľka dimenzií obsahuje kľúčový stĺpec (alebo stĺpce), ktorý sa správa ako jedinečný identifikátor, a ďalšie stĺpce. Iné stĺpce podporujú filtrovanie a zoskupovanie údajov.
  • Tabuľky faktov ukladajú pozorovania alebo udalosti a môže ísť o predajné objednávky, zostatky skladových zásob, výmenné kurzy, teploty a ďalšie. Tabuľka faktov obsahuje kľúčové stĺpce dimenzií, ktoré sa vzťahujú na tabuľky dimenzií, a číselné stĺpce mierky. Kľúčové stĺpce dimenzií určujú dimenzionalitu tabuľky faktov, zatiaľ čo kľúčové hodnoty dimenzií určujú granularitu tabuľky faktov. Zoberme si napríklad tabuľku faktov určenú na ukladanie cieľov predaja, ktorá má dva kľúčové stĺpce dimenzií Date a ProductKey. Pochopiť to, že tabuľka má dve dimenzie, je jednoduché. Granularitu však nie je možné určiť bez toho, aby sa zvážili kľúčové hodnoty dimenzie. V tomto príklade je potrebné vziať do úvahy, že hodnoty uložené v Date stĺpci predstavujú prvý deň v každom mesiaci. V tomto prípade je granularita na úrovni produktov za mesiac.

Tabuľky dimenzií vo všeobecnosti obsahujú relatívne malý počet riadkov. Na druhej strane, tabuľky faktov môžu obsahovať veľký počet riadkov a v priebehu času môžu naďalej rásť.

Diagram znázorňujúci ilustráciu hviezdicovej schémy.

Normalizácia vs. denormalizácia

Ak chcete pochopiť niektoré koncepty hviezdicovej schémy popísané v tomto článku, je dôležité vedieť dva pojmy: normalizáciu a denormalizáciu.

Normalizácia je výraz, ktorý sa používa na popis údajov uložených spôsobom, ktorý znižuje počet opakujúcich sa údajov. Predstavte si tabuľku produktov, ktorá má stĺpec s jedinečnou kľúčovou hodnotou, ako je napríklad kód Product Key a ďalšie stĺpce, ktoré popisujú vlastnosti produktu, ako sú napríklad názov produktu, kategória, farba a veľkosť. Tabuľka predaja sa považuje za normalizovanú, keď ukladá iba kľúče, ako je napríklad kód Product Key. Na nasledujúcom obrázku si všimnite, že produkt zaznamenáva iba ProductKey stĺpec.

Diagram znázorňujúci tabuľku údajov, ktorá obsahuje stĺpec Product Key.

Ak však tabuľka predaja ukladá podrobnosti o produktoch za kľúč, považuje sa za denormalizovanú. Na nasledujúcom obrázku si všimnite, že v stĺpcoch, ktoré ProductKey súvisia s produktom, sú záznamy v produkte.

Diagram znázorňujúci tabuľku údajov, ktorá obsahuje kód Product Key a ďalšie stĺpce súvisiace s produktom vrátane kategórií, farby a veľkosti.

Keď získavate údaje z exportného súboru alebo extrahovania údajov, je pravdepodobné, že predstavuje denormalizovanú množinu údajov. V tomto prípade použite doplnok Power Query na transformáciu a tvarovanie zdrojových údajov do viacerých normalizovaných tabuliek.

Ako je popísané v tomto článku, mali by ste sa snažiť o vytvorenie optimalizovaných sémantických modelov služby Power BI s tabuľkami, ktoré predstavujú normalizované údaje faktov a dimenzií. Existuje však jedna výnimka, kde by sa dimenzia v tvare snehovej vločky mohla denormalizovať, aby sa vytvorila jedna tabuľka modelu.

Význam hviezdicovej schémy pre sémantické modely služby Power BI

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.

Zoberme si, že každý vizuál zostavy Power BI vygeneruje dotaz odoslaný do sémantického modelu služby Power BI. Vo všeobecnosti dotazy filtrujú, zoskupujú a sumarizujú údaje modelu. Dobre navrhnutý model následne poskytuje tabuľky na filtrovanie a zoskupovanie a tabuľky na sumarizáciu. Takýto návrh je v súlade s princípmi hviezdicovej schémy:

  • Tabuľky dimenzií umožňujú filtrovanie a zoskupovanie.
  • Tabuľky faktov umožňujú sumarizáciu.

Neexistuje žiadna vlastnosť tabuľky, ktorú by modelári nastavili na nastavenie typu tabuľky ako dimenzie alebo faktu. V skutočnosti to určujú modelové vzťahy. 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. Bežný typ kardinality vzťahu je one-to-many alebo naopak many-to-one. Strana "one" je vždy tabuľkou dimenzií, zatiaľ čo strana "many" vždy predstavuje tabuľku faktov.

Diagram znázorňujúci konceptuálnu ilustráciu hviezdicovej schémy.

Dobre štruktúrovaný návrh modelu zahŕňa tabuľky, ktoré sú buď tabuľkami dimenzií, alebo tabuľkami faktov. Vyhýbajte sa premiešaniu oboch typov spolu v jednej tabuľke. Tiež sa odporúča, aby ste sa snažili dosiahnuť správny počet tabuliek s vhodnými vzťahmi. Dôležité je tiež to, že tabuľky faktov vždy načítavajú údaje v konzistentnom v granuláli.

Napokon je dôležité pochopiť, že optimálny návrh modelu predstavuje sčasti vedu a sčasti umenie. Niekedy môžete dosiahnuť prienik vďaka dobrým pokynom, ak je taký prístup vhodný.

Existuje mnoho konceptov súvisiacich s návrhom hviezdicovej schémy, ktoré možno použiť na sémantický model služby Power BI. Tieto koncepty zahŕňajú:

Miery

Mierka v návrhu hviezdicovej schémy predstavuje stĺpec tabuľky faktov, ktorý ukladá hodnoty určené na sumarizáciu. V sémantickom modeli Power BI má mierka inú, ale predsa podobnú definíciu. Model podporuje explicitné aj implicitné mierky.

  • Explicitné mierky sú výslovne vytvorené a založené na vzorci zapísanom v jazyku DAX (Data Analysis Expressions), ktorým sa dosahuje sumarizácia. Výrazy mierok často používajú agregačné funkcie jazyka DAX, ako napríklad SUM, MIN, MAX, AVERAGEa ďalšie, na vytvorenie výsledku skalárnej hodnoty v čase dotazu (hodnoty sa nikdy neukladajú v modeli). 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. Ďalšie informácie nájdete v téme Základy jazyka DAX v aplikácii Power BI Desktop.
  • Implicitné mierky sú stĺpce, ktoré možno sumarizovať vo vizuáli zostavy alebo vo funkcii Q&A. 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ť (explicitné) mierky. Stĺpec predaja Sales Amount predajcu Adventure Works je napríklad možné sumarizovať mnohými spôsobmi (súčet, počet, priemer, medián, minimum, maximum a ďalšie) bez toho, aby bolo potrebné vytvoriť mierku pre každý možný typ agregácie.

Na table Údaje sú explicitné mierky zastúpené ikonou kalkulačky, zatiaľ čo implicitné mierky sú zastúpené symbolom sigma (∑).

Diagram znázorňujúci ikony na table Údaje.

Existujú však tri presvedčivé dôvody, prečo by ste mohli vytvárať mierky, a to dokonca aj pri jednoduchých sumarizáciách na úrovni stĺpcov:

  • Keď viete, že autori vašich zostáv budú dotazovať sémantický model pomocou multidimenzionálnych výrazov (MDX), tento model musí obsahovať explicitné mierky. Dôvodom je, že jazyk MDX nemôže dosiahnuť súhrn hodnôt stĺpcov. Jazyk MDX sa používa predovšetkým pri vykonávaní funkcie Analyzovať v Exceli , pretože kontingenčné tabuľky vydávajú dotazy MDX.

  • Ak viete, že autori vašich zostáv budú vytvárať stránkované zostavy služby Power BI pomocou návrhára dotazov jazyka MDX, sémantický model musí obsahovať explicitné mierky. Iba návrhár dotazov služby MDX podporuje agregáty servera. Takže, ak autori zostáv potrebujú mať mierky vyhodnocované službou Power BI (namiesto pomocou nástroja stránkovanej zostavy), musia použiť návrhára dotazov MDX.

  • Keď chcete ovládať, ako autori zostáv sumarizujú stĺpce určitými spôsobmi. Stĺpec predajov Unit Price predajcu, ktorý predstavuje pomer na jednotku, je napríklad možné sumarizovať, ale len pomocou konkrétnych agregačných funkcií. Nikdy by sa nemal sčítavať, ale je vhodné sumarizovať ho použitím iných agregačných funkcií ako min, max alebo average. V tejto inštancii môže modelár stĺpec skryť Unit Price a vytvoriť mierky pre všetky vhodné agregačné funkcie.

    Tento prístup k návrhom funguje veľmi dobre pri zostavách, ktoré boli vytvorené v služba Power BI a pre funkciu Q&A. Dynamické pripojenia aplikácie Power BI Desktop však umožňujú autorom zostáv zobrazovať skryté polia na table Údaje, čo môže mať za následok obídenie tohto prístupu k návrhu.

Náhradné kľúče

Náhradný kľúč je jedinečný identifikátor, ktorý sa pridáva do tabuľky ako podpora modelovania hviezdicových schém. Predvolene nie je v zdrojových údajoch definovaný ani uložený. Náhradné kľúče sa bežne pridávajú do tabuliek dimenzií skladov relačných údajov, kde poskytujú jedinečný identifikátor pre každý riadok tabuľky dimenzií.

Vzťahy sémantických modelov služby Power BI sú založené na jednom jedinečnom stĺpci v jednej tabuľke, ktorý šíri filtre do jedného stĺpca v inej tabuľke. Ak tabuľka dimenzií v sémantickom modeli neobsahuje jeden jedinečný stĺpec, musíte pridať jedinečný identifikátor, ktorý sa stane stranou "one" vzťahu. V aplikácii Power BI Desktop môžete túto požiadavku splniť pridaním stĺpca indexu doplnku Power Query.

Diagram znázorňujúci príkaz Vytvoriť stĺpec indexu v službe Editor Power Query.

Tento dotaz musíte zlúčiť s dotazom na strane "many", aby ste doň mohli pridať aj stĺpec indexu. Keď načítate tieto dotazy do sémantického modelu, môžete následne medzi tabuľkami modelov vytvoriť vzťah typu one-to-many.

Vločkové dimenzie

Vločková dimenzia predstavuje súpravu normalizovaných tabuliek jednej podnikovej entity. Spoločnosť Adventure Works napríklad klasifikuje produkty podľa kategórie a podkategórie. Produkty sú priradené do podkategórií a podkategórie sú potom priradené kategóriám. V sklade relačných údajov Adventure Works sa dimenzia produktov normalizuje a uloží sa do troch súvisiacich tabuliek: DimProductCategory, DimProductSubcategorya DimProduct.

Diagram znázorňujúci príklad schémy snehovej vločky obsahujúcej tri súvisiace tabuľky.

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.

Diagram znázorňujúci koncepčný príklad snehovej vločky diagramu obsahujúci tri súvisiace tabuľ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 vytvárajú zdrojové údaje), alebo môžete kombinovať zdrojové tabuľky a vytvoriť jednu denormalizovanú tabuľku modelu. Výhody jednej tabuľky modelov vo všeobecnosti prevyšujú výhody viacerých tabuliek modelov. Najoptimálnejšie rozhodnutie závisí od objemu údajov a použiteľnosti požiadaviek na model.

Ak sa rozhodnete napodobniť návrh dimenzie v tvare vločky:

  • Power BI načítava viac tabuliek, čo je menej efektívne z hľadiska ukladacieho priestoru a výkonu. Tieto tabuľky musia obsahovať stĺpce, ktoré podporujú vzťahy modelov, čím môže vzniknúť model väčšieho rozsahu.
  • Je potrebné prechádzať dlhšie reťazce na rozširovanie vzťahových filtrov, čo môže byť menej efektívne ako filtre použité na jednu tabuľku.
  • Tabla Údaje zobrazuje autorom zostáv viac tabuliek modelov, čo môže mať za následok menej intuitívne prostredie, najmä keď tabuľky dimenzií v tvare vločky obsahujú len jeden alebo dva stĺpce.
  • Nie je možné vytvoriť hierarchiu, ktorá obsahuje stĺpce z viacerých tabuliek.

Ak sa rozhodnete zapojiť sa do jednej tabuľky modelu, môžete tiež definovať hierarchiu, ktorá obsiahne najvyššie aj najnižšie vlákno dimenzie. Je možné, že ukladací priestor s nadbytočnými denormalizovanými údajmi zvýši veľkosť ukladacieho priestoru modelu, najmä v prípade veľkých tabuliek dimenzií.

Diagram znázorňujúci príklad hierarchie v rámci tabuľky dimenzií, ktorá obsahuje stĺpce ako Kategória, Podkategória a Produkt.

Pomaly sa meniace dimenzie

Málo premenlivá dimenzia (SCD) je dimenzia , ktorá vhodným spôsobom spravuje zmeny členov dimenzie v priebehu času. Uplatňuje sa v prípade, že sa hodnoty podnikovej entity menia pomaly v priebehu času neplánovaným spôsobom. Vhodným príkladom scd je zákaznícka dimenzia, pretože stĺpce s kontaktnými podrobnosťami, ako sú napríklad e-mailová adresa a telefónne číslo, sa menia zriedkavo. Niektoré dimenzie sa naopak považujú za veľmi premenlivé, keď sa atribút dimenzie, ako napríklad trhová cena akcie, mení často. Bežný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.

Teória návrhu hviezdicovej schémy odkazuje na dva časté typy scd: 1. typ a 2. typ. Tabuľka dimenzií môže byť 1. typ alebo 2. typ alebo podporovať oba typy súčasne v prípade rôznych stĺpcov.

1\. typ 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. 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. Keď sa zmení e-mailová adresa alebo telefónne číslo zákazníka, tabuľka dimenzií riadok zákazníka aktualizuje o nové hodnoty. Potom to vyzerá tak, ako by tieto kontaktné informácie zákazníka mal.

Diagram znázorňujúci príklad málo premenlivej dimenzie typu 1, v ktorej sa aktualizuje telefónne číslo zamestnanca.

Obnovenie tabuľky dimenzií modelu Power BI bez prírastku dosahuje výsledok v rámci 1. typu SCD. Obnovia sa údaje tabuľky, aby sa zabezpečilo načítanie najnovších hodnôt.

2\. typ scd

SCD 2. typu podporuje tvorbu verzií členov dimenzie. 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í. V tomto prípade musí tabuľka dimenzií použiť náhradný kľúč, aby poskytla jedinečný odkaz verzii člena dimenzie. Obsahuje tiež stĺpce, ktoré definujú platnosť rozsahu dátumov vo verzii (napríklad StartDate a EndDate), a prípadne aj stĺpec príznakov (napríklad IsCurrent) na jednoduché filtrovanie aktuálnych členov dimenzie.

Adventure Works napríklad priradí k oblasti predaja každého predajcu. Keď obchodník premiestni 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. Tabuľka dimenzií musí ukladať verzie predajcov a ich súvisiacich oblastí, aby sa podporovala presná historická analýza predaja podľa obchodníkov. Tabuľka by tiež mala obsahovať hodnoty dátumov začatia a ukončenia, ktoré definujú časovú platnosť. Aktuálne verzie môžu definovať prázdny dátum ukončenia (alebo 31. 12. 9999), čo značí, že tento riadok je aktuálnou verziou. Tabuľka musí mať aj náhradný kľúč , pretože obchodný kľúč (v tejto inštancii ID zamestnanca) nebude jedinečný.

Diagram znázorňujúci príklad málo premenlivého typu dimenzie 2, v ktorom sa oblasť predaja zamestnancov aktualizuje vytvorením novej verzie.

Je dôležité vedieť, že ak zdrojové údaje neukladá verzie, musíte na zisťovanie a ukladanie zmien použiť sprostredkujúce systémy (napríklad sklad údajov). Proces načítania tabuľky musí zachovať existujúce údaje a zistiť zmeny. Keď sa zistí zmena, proces načítania tabuľky musí skončiť platnosť aktuálnej verzie. Tieto zmeny zaznamená tak, EndDate že aktualizuje hodnotu a vloží novú verziu s hodnotou StartDate začínajúca od predchádzajúcej EndDate hodnoty. 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. Sémantický model služby Power BI používa Power Query, a preto tento výsledok nedokáže vytvoriť. Môže však načítať údaje z vopred načítanej tabuľky dimenzií 2. typu SCD.

Prepitné

Informácie o implementácii tabuľky dimenzií SCD 2. typu v sklade tkaniny nájdete v téme Spravovanie historických zmien.

Sémantický model služby 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. V súvislosti so službou Adventure Works vám tento návrh umožňuje dotazovať obchodníka bez ohľadu na priradenú oblasť predaja alebo pre konkrétnu verziu obchodníka.

Ak chcete dosiahnuť splnenie tejto požiadavky, tabuľka dimenzií sémantického modelu v službe Power BI musí obsahovať stĺpec na filtrovanie obchodníka a iný stĺpec na filtrovanie konkrétnej verzie obchodníka. Je dôležité, aby stĺpec verzií neobslúval nejednoznačné popisy ako David Campbell (12/15/2008-06/26/2019) alebo David Campbell (06/27/2019-Current). Tiež je dôležité, aby boli autori a používatelia zostáv poučovaní o základoch 2. typu SCD a o tom, ako dosiahnuť vhodný návrh zostáv použitím správnych filtrov.

Odporúča sa zahrnúť do návrhu hierarchiu, ktorá vizuálom umožňuje prejsť na detaily na úrovni verzie.

Diagram znázorňujúci tablu Údaje so stĺpcami pre salesperson (Predajca) a Salesperson Version (Verzia predajcu).

Dimenzie zohrávajúce roly

Dimenzia zohrávajúná rolou je dimenzia, ktorá umožňuje filtrovať súvisiace fakty iným typom údajov. V spoločnosti Adventure Works má napríklad dátumová tabuľka dimenzií tri vzťahy k faktom o predaji predajcu. 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.

Diagram znázorňujúci koncepčný príklad dimenzie a vzťahov, ktoré majú funkciu roly. Tabuľka Date (Dátum) má dva vzťahy s tabuľkou faktov pre dátum objednávky a dátum odoslania.

V sklade údajov sa akceptuje prístup k návrhu v definovaní jednej dátumovej tabuľky dimenzií. V čase dotazu sa "rola" dimenzie dátumu vytvorí na základe stĺpca faktov, ktorý použijete na spojenie tabuliek. Ak napríklad analyzujete predaj podľa dátumu objednávky, tabuľka pripojí vzťahy k stĺpcu dátumov predajných objednávok predajcu.

V sémantickom modeli služby Power BI je možné tento návrh napodobniť vytvorením viacnásobných vzťahov medzi dvoma tabuľkami. V príklade spoločnosti Adventure Works by mali tabuľky dátumov a predajov predajcu tri vzťahy.

Diagram znázorňujúci príklad dimenzie a vzťahov, ktoré majú funkciu roly. Tabuľka Date má tri vzťahy s tabuľkou faktov.

Hoci je tento návrh možný, medzi dvoma sémantickými tabuľkami modelu služby Power BI môže byť len jeden aktívny vzťah. Všetky zostávajúce vzťahy musia byť nastavené ako neaktívne. Ak už máte jeden aktívny vzťah, znamená to, že existuje predvolené šírenie filtra od dátumu až po predaj predajcu. 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.

Jediný spôsob, ako využiť neaktívny vzťah, je definovať výraz DAX, ktorý používa funkciu USERELATIONSHIP . 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. Táto práca môže byť zdĺhavá, najmä keď tabuľka predajcu definuje mnohé mierky. Vytvorí tiež preplnenú tablu Údaje s nadbytočným množstvom mierok. Existujú aj ďalšie obmedzenia:

  • 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. Mierky na úrovni zostavy možno definovať iba pri vytváraní zostáv v aplikácii 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. Nemôžete napríklad vytvoriť vizuál, ktorý vykreslí predaj podľa dátumu objednávky podľa dodaného predaja.

Na prekonanie týchto obmedzení je bežnou technikou modelovania v službe Power BI vytvorenie tabuľky dimenzií pre každú inštanciu zohrávajúcu rolu. Každú tabuľku dimenzií môžete vytvoriť ako odkazujúci dotaz pomocou doplnku Power Query alebo vypočítavanej tabuľky pomocou jazyka DAX. Model môže obsahovať tabuľku Date , tabuľku Ship Date a tabuľku Delivery Date , pričom každý z nich má jediný a aktívny vzťah k príslušným stĺpcom tabuľky predaja predajcu.

Diagram znázorňujúci príklad dimenzií a vzťahov, ktoré majú funkciu roly. S tabuľkou faktov súvisia tri rôzne tabuľky dimenzií dátumov.

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. Menšou cenou, ktorú je potrebné pri tomto prístupe k návrhu zaplatiť, je však to, že bude sa duplikuje tabuľka dimenzií dátumov, čo má za následok zvýšenú veľkosť úložiska modelu. Keďže tabuľky dimenzií zvyčajne ukladajú menej riadkov vzhľadom na tabuľky faktov, tento problém je zriedkavý.

Pri vytváraní tabuliek dimenzií modelu pre každú rolu sa odporúča postupovať podľa osvedčených postupov návrhu:

  • Uistite sa, že názvy stĺpcov sú samopopisné. Aj keď je možné mať Year stĺpec 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. Pouvažujte o premenovaní stĺpcov v každej tabuľke rolí dimenzií tak, Ship Date aby tabuľka obsahuje stĺpec roka s názvom Ship Yearatď.
  • Ak je to dôležité, zabezpečte, aby popisy tabuliek poskytovali spätnú väzbu autorom zostáv (prostredníctvom popisov tably Údaje ) o tom, ako je nastavené šírenie filtrov. Táto jasnosť je dôležitá, keď model obsahuje všeobecne pomenovanú tabuľku, ako Datenapríklad , ktorá sa používa na filtrovanie viacerých tabuliek faktov. 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, zvážte poskytnutie popisu tabuľky, napríklad Filters reseller sales by order date.

Ďalšie informácie nájdete v téme Pokyny na pomoc pri aktívnych a neaktívnych vzťahoch.

Nevyžiadané dimenzie

Nevyžiadaná dimenzia je užitočná v prípade množstva dimenzií, najmä ak obsahujú málo atribútov (možno jeden), a keď tieto atribúty majú málo hodnôt. Dobrými kandidátmi sú stĺpce stavu objednávok alebo demografické stĺpce zákazníkov, ako je pohlavie alebo veková skupina.

Cieľom návrhu nevyžiadanej dimenzie je zlúčiť mnoho malých dimenzií do jednej dimenzie, aby sa zmenšila veľkosť ukladacieho priestoru modelu, a tiež zmenšiť nepotrebné položky na table Údaje s povrchom menšieho počtu tabuliek modelov.

Tabuľka nevyžiadanej dimenzie je zvyčajne kartézskym súčinom všetkých členov atribútu dimenzie, pričom stĺpec náhradného kľúča slúži na jedinečnú identifikáciu každého riadka. 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).

Diagram znázorňujúci príklad tabuľky nevyžiadanej dimenzie. Order Status (Stav objednávky) má tri štáty, zatiaľ čo Stav doručenia má dva štáty. Tabuľka nevyžiadanej dimenzie obsahuje všetkých šesť kombinácií dvoch stavov.

Tento dotaz načítate do modelu ako tabuľku dimenzií. Tento dotaz tiež treba zlúčiť s dotazom faktu, aby sa stĺpec indexu načítal do modelu a podporil vytvorenie vzťahu typu "one-to-many".

Dimenzie faktov

Dimenzia faktov odkazuje na atribút tabuľky faktov, ktorá sa vyžaduje na filtrovanie. V spoločnosti Adventure Works je dobrým príkladom číslo predajnej objednávky predajcu. V tejto inštancii 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ť úložiska modelu a vytvorili by nepotrebné položky na table Údaje .

V sémantickom modeli služby 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. 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).

Diagram znázorňujúci tablu Údaje a tabuľku faktov predaja, ktorá obsahuje pole Číslo objednávky.

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, vytvorenie tabuľky dimenzií faktov by bolo vhodným návrhom. Ďalšie informácie nájdete v téme Pokyny na poskytovanie vzťahov typu One-to-one (Dimenzie faktov).

Tabuľky faktov bez faktov

Tabuľka faktov bez faktov neobsahuje žiadne stĺpce mierok. Obsahuje iba kľúče dimenzie.

Tabuľka faktov bez faktov môže ukladať pozorovania definované kľúčmi dimenzie. V konkrétnom dátume a čase sa napríklad konkrétny zákazník prihlásil na vašu webovú lokalitu. 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.

Zaujímavejším použitím tabuľky faktov bez faktov je ukladanie vzťahov medzi dimenziami. Ide o prístup návrhu sémantických modelov v službe Power BI, ktorý odporúčame pri definovaní vzťahov dimenzií typu many-to-many. V návrhu vzťahov dimenzií typu many-to-many sa na tabuľku faktov bez faktov odkazuje ako na premosťovaciu tabuľku.

Predpokladajme napríklad, že predajcovia môžu byť priradení k jednej alebo viacerým oblastiam predaja. 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. Duplicitné hodnoty môžu byť uložené v oboch stĺpcoch.

Diagram znázorňujúci tabuľku faktov bez faktov premosťujúcu dimenzie Salesperson (Predajca) a Region (Oblasť). Tabuľka faktov bez faktov sa skladá z dvoch stĺpcov, ktoré predstavujú kľúče dimenzií.

Tento prístup návrhu typu many-to-many je dobre zdokumentovaný a možno ho dosiahnuť bez premosťov tabuľky. Prístup premosťovky sa však považuje za najlepší postup, keď ide o dve dimenzie. Ďalšie informácie nájdete v téme Pokyny na vytvorenie vzťahov typu Many-to-many (Vytvorenie vzťahu medzi dvomi tabuľkami dimenzií).

Súvisiaci obsah

Ďalšie informácie o návrhu hviezdicovej schémy alebo návrhu sémantického modelu v službe Power BI nájdete v nasledujúcich článkoch: