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

Tento článok je určený pre 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 dátových modelov Power BI optimalizovaných z hľadiska výkonu a použiteľnosti.

Cieľom tohto článku nie je poskytnúť kompletné informácie o návrhu hviezdicovej schémy. Ďalšie podrobnosti nájdete priamo v publikovanom obsahu, napríklad: The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (Súprava nástrojov skladu údajov: Definitívny sprievodca dimenzionálnym modelovaním) (3. vydanie, 2013), Ralph Kimball a kol.

Prehľad o hviezdicovej schéme

Hviezdicová schéma predstavuje pokročilý 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 – objekty, ktoré modelujete. Entity môžu zahŕňať produkty, ľudí, miesta a koncepty vrátane samotného času. Najkonzistentnejš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 tiež popisné stĺpce.

Tabuľky faktov ukladajú pozorovania alebo udalosti a môže ísť o predajné objednávky, zostatky skladových zásob, výmenné kurzy, teploty atď. Tabuľka faktov obsahuje kľúčové stĺpce dimenzií, ktoré sa vzťahujú na tabuľky dimenzií, a tiež číselné stĺpce mierky. Kľúčové stĺpce dimenzií určujú dimenzionalitu tabuľky faktov, zatiaľ čo kľúčové hodnoty dimenzií určujú granularitu tabuľky faktov. Ako príklad si vezmime tabuľku faktov určenú na ukladanie cieľov predaja, ktorá má dva kľúčové stĺpce dimenzií, a to Date (Dátum) a ProductKey. Pochopiť to, že má tabuľka dve dimenzie, je jednoduché. Granularitu však nie je možné určiť bez toho, aby sa zohľadnili kľúčové hodnoty dimenzie. V tomto príklade je potrebné vziať do úvahy, že hodnoty uložené v stĺpci Date (Dátum) predstavujú prvé dni jednotlivých mesiacov. V tomto prípade je granularita na úrovni produktov za mesiac.

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

Ilustrácia hviezdicovej schémy

Význam hviezdicovej schémy pre modely v službe 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, ktorý sa odošle do modelu Power BI (v službe Power BI sa nazýva množina údajov). Tieto dotazy sa používajú na filtrovanie, zoskupovanie a sumarizáciu údajov 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í podporujú filtrovanie a zoskupovanie,
  • tabuľky faktov podporujú sumarizáciu.

Neexistuje žiadna vlastnosť tabuľky, ktorú by modelári nastavili na konfigurovanie 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. Časť „one“ vždy predstavuje tabuľku dimenzií a časť „many“ zasa vždy predstavuje tabuľku faktov. Ďalšie informácie o vzťahoch nájdete v téme Modelové vzťahy v aplikácii Power BI Desktop.

Koncept hviezdicovej schémy

Dobre štruktúrovaný návrh modelu by mal obsahovať tabuľky, a to buď tabuľky dimenzií, alebo tabuľky faktov. Vyhýbajte sa prelínaniu týchto dvoch typov spolu v jednej tabuľke. Tiež sa odporúča, aby ste sa snažili dosiahnuť vhodný počet tabuliek spolu s vhodnými vzťahmi. Dôležité je tiež to, že tabuľky faktov vždy načítavajú údaje v súvislom vlákne.

Napokon je dôležité uvedomiť si, že optimálny návrh modelu predstavuje sčasti vedu a sčasti umenie. Niekedy môžete dosiahnuť prienik vďaka správnym pokynom, ak je taký postup vhodný.

V modeli Power BI je však možné použiť mnoho ďalších konceptov, ktoré sa vzťahujú na hviezdicovú schému. Tieto koncepty zahŕňajú:

Mierky

Mierka v návrhu hviezdicovej schémy predstavuje stĺpec tabuľky faktov, ktorý ukladá hodnoty určené na sumarizáciu.

V modeli Power BI má mierka inú, no predsa podobnú definíciu. Ide o vzorec napísaný v jazyku Data Analysis Expressions (DAX), ktorým sa dosahuje sumarizácia. Výrazy mierok často využívajú agregačné funkcie jazyka DAX, ako napríklad SUM, MIN, MAX, AVERAGE atď., čím sa získava výsledok v podobe skalárnej hodnoty v čase dotazu (hodnoty sa nikdy neukladajú v modeli). 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 článku Základy výrazov DAX v aplikácii Power BI Desktop.

Dôležité je pochopiť, že modely Power BI podporujú aj druhú metódu na dosiahnutie sumarizácie. Ľubovoľné stĺpce, no zvyčajne číselné stĺpce, je možné sumarizovať pomocou vizuálu zostavy alebo funkcie Q&A. Tieto stĺpce sa označujú ako implicitné mierky. Pre vás ako vývojára modelov predstavujú výhodu, keďže v prípade mnohých inštancií nie je potrebné vytvárať mierky. Stĺpec Čiastka predaja, ktorý obsahuje údaje o predaji predajcu Adventure Works, je napríklad možné sumarizovať mnohými spôsobmi (sčítať, vypočítať priemer, hodnotu mediánu, minimálnu a maximálnu hodnotu a pod.), a to bez potreby vytvoriť mierku pre jednotlivé možné typy agregácie.

Príklady ikon v zozname polí

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

  • Keď viete, že autori vašich zostáv budú dotazovať model pomocou multidimenzionálnych výrazov (MDX), tento model musí obsahovať explicitné mierky. Explicitné mierky sa definujú pomocou jazyka DAX. Tento prístup k návrhom má veľký význam pri dotazovaní množiny údajov Power BI pomocou jazyka MDX, pretože jazyk MDX nemôže dosiahnuť sumarizáciu hodnôt stĺpcov. Jazyk MDX sa bude používať predovšetkým pri vykonávaní funkcie Analyzovať v Exceli, pretože kontingenčné tabuľky vytvárajú dotazy MDX.
  • Keď viete, že autori vašich zostáv budú vytvárať stránkované zostavy služby Power BI pomocou návrhára dotazov služby MDX, tento model musí obsahovať explicitné mierky. Iba návrhár dotazov služby MDX podporuje agregáty servera. Ak teda autori zostáv musia mať mierky vyhodnocované službou Power BI (namiesto nástroja stránkovaných zostáv), musia použiť návrhára dotazov služby MDX.
  • Keď potrebujete zabezpečiť, aby autori zostáv mohli stĺpce sumarizovať iba určitými spôsobmi. Stĺpec Jednotková cena s údajmi o predaji predajcu, ktorý predstavuje pomer na jednotku, je napríklad možné sumarizovať, ale len pomocou určitých agregačných funkcií. Nikdy by sa nemal sčítavať, ale je vhodné sumarizovať ho použitím iných agregačných funkcií ako min, max, average atď. V tejto inštancii môže modelár stĺpec Jednotková cena skryť a vytvoriť mierky pre všetky vhodné agregačné funkcie.

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

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 slúžia ako jedinečné identifikátory pre jednotlivé riadky tabuľky dimenzií.

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

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

Tento dotaz musíte zlúčiť s časťou dotazu „many“, aby ste doň mohli pridať aj stĺpec indexu. Keď v modeli načítate tieto dotazy, 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órií a podkategórií. Kategórie sa priraďujú do podkategórií a do podkategórií sa zasa priraďujú produkty. V sklade relačných údajov Adventure Works sa dimenzia produktov normalizuje a uloží sa do troch súvisiacich tabuliek: DimProductCategory, DimProductSubcategoryDimProduct.

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.

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

V aplikácii Power BI Desktop si môžete vybrať, či chcete napodobniť návrh dimenzie v tvare snehovej vločky (možno preto, lebo tak robia zdrojové údaje), alebo chcete zdrojové tabuľky integrovať (denormalizovať) do jednej tabuľky modelov. 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:

  • Služba 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.
  • Bude potrebné prechádzať dlhšie reťazce na rozširovanie vzťahových filtrov, čo bude pravdepodobne menej efektívne ako filtre použité na jednu tabuľku.
  • Tabla Polia zobrazuje autorom zostáv viac tabuliek modelov, čo môže mať za následok menej intuitívne prostredie, obzvlášť vtedy, keď tabuľky dimenzií v tvare vločky obsahujú len jeden alebo dva stĺpce.
  • Nie je možné vytvoriť hierarchiu, ktorá presahuje tabuľky.

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

Hierarchia v rámci dimenzie

Málo premenlivé 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, keď sa hodnoty podnikovej entity menia v priebehu času a spôsobom ad hoc. Vhodným príkladom málo premenlivej dimenzie je zákaznícka dimenzia, konkrétne jej stĺpce s kontaktnými údajmi, ako je napríklad e-mailová adresa a telefónne číslo. Niektoré dimenzie sa naopak považujú za veľmi premenlivé, keď sa atribút dimenzie, ako napríklad trhová cena skladových zásob, mení často. Častým prístupom k návrhu v týchto inštanciách je ukladanie rýchlo sa meniacich hodnôt atribútov do mierky tabuľky faktov.

Teória návrhu hviezdicovej schémy odkazuje na dva časté typy málo premenlivých dimenzií (SCD): 1. typ a 2. typ. Tabuľka dimenzií môže predstavovať 1. typ aj 2. typ alebo podporovať oba typy súčasne v prípade odlišných stĺpcov.

1. typ málo premenlivej dimenzie (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 sa kontaktné informácie zákazníka nikdy nezmenili.

Obnovenie tabuľky dimenzií modelu Power BI bez prírastku dosahuje výsledok v podobe 1. typu SCD. Obnovia sa údaje tabuľky a zaistí sa, aby sa načítali najnovšie hodnoty.

2. typ málo premenlivej dimenzie (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ľúč a poskytnúť jedinečný odkaz verzii patriacej členovi dimenzie. Obsahuje tiež stĺpce, ktoré definujú platnosť rozsahu údajov vo verzii (napríklad StartDate (Dátum začatia) a EndDate (Dátum ukončenia)), a prípadne aj stĺpec príznakov (napríklad IsCurrent (Je aktuálne)) na jednoduché filtrovanie aktuálnych členov dimenzie.

Spoločnosť Adventure Works napríklad priraďuje obchodníkov k oblastiam predaja. Keď obchodník zmení oblasť, musí sa vytvoriť nová verzia obchodníka, aby sa zabezpečilo, že historické údaje budú aj naďalej priradené k predchádzajúcej oblasti. Tabuľka dimenzií musí ukladať verzie obchodníkov a im priradené oblasti, aby sa podporovala presná historická analýza predaja podľa obchodníkov. Tabuľka by tiež mala obsahovať aj 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.1999), čo značí, že verzia daného riadku je aktuálna. Tabuľka musí tiež definovať náhradný kľúč, pretože podnikový kľúč (v tejto inštancii ID zamestnanca) nebude jedinečný.

Je dôležité uvedomiť si, že ak zdrojové údaje neukladajú verzie, musíte na zisťovanie a ukladanie zmien použiť nejaký sprostredkujúci systém (napríklad sklad údajov). Proces načítania tabuľky musí zachovať existujúce údaje a zistiť zmeny. Keď sa zistí zmena, proces načítania tabuľky musí ukončiť platnosť danej aktuálnej verzie. Tieto zmeny zaznamená tak, že aktualizuje hodnotu EndDate (Dátum ukončenia) a vloží novú verziu s hodnotou StartDate (Dátum začatia) začínajúcou od predchádzajúcej hodnoty EndDate. 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. Model Power BI používajúci doplnok Power Query takýto výsledok dosiahnuť nedokáže. Môže však načítať údaje z vopred načítanej tabuľky dimenzií 2. typu SCD.

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

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

V prípade návrhu je tiež vhodné zahrnúť doň hierarchiu, ktorá vizuálom umožňuje prejsť až na detaily na úrovni verzie.

Príklad hierarchie v zozname polí

Výstup z príkladu hierarchie

Dimenzie zohrávajúce roly

Dimenzia zohrávajúca rolu je dimenzia, ktorá umožňuje filtrovať súvisiace fakty iným spôsobom. 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.

V sklade údajov sa akceptuje prístup k návrhu v podobe definovania jednej dátumovej tabuľky dimenzií. V čase vykonávania dotazu sa vytvorí „rola“ dimenzie dátumu podľa toho, ktorý stĺpec faktov používate na prepojenie tabuliek. Ak napríklad analyzujete predaj podľa dátumu objednávky, tabuľka pripojí príbuzné dátumy k stĺpcu dátumov s predajnými objednávkami predajcu.

V modeli 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 údajov a predajov predajcu tri vzťahy. Hoci je tento návrh možný, je dôležité pochopiť, že medzi tabuľkami modelov Power BI môže byť len jeden aktívny vzťah. 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.

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

Jediný spôsob, ako využiť neaktívny vzťah, je definovať výraz DAX, ktorý používa funkciu USERELATIONSHIP. 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. Zároveň sa vytvoria nepotrebné položky na table Polia 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 typu dimenzie pre každú inštanciu zohrávajúcu rolu. Ďalšie tabuľky dimenzií zvyčajne vytvoríte ako vypočítané tabuľky pomocou jazyka DAX. V prípade použitia vypočítaných tabuliek môže model obsahovať tabuľku Dátum, tabuľku Dátum odoslania a tabuľku Dátum doručenia, pričom každá z nich má jediný a aktívny vzťah k príslušným stĺpcom tabuľky predaja predajcu.

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

Tento prístup k návrhu nevyžaduje definovanie viacerých mierok pre rôzne roly dátumov a umožňuje simultánne filtrovanie podľa rôznych rolí dátumov. Menšou nevýhodou tohto prístupu k návrhu je však to, že bude sa duplikuje tabuľka dimenzií dátumov, čo má za následok viac potrebného ukladacieho priestoru modelu. 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í pre každú rolu dodržiavajte tieto najvhodnejšie postupy návrhu:

  • Uistite sa, že názvy stĺpcov sú samopopisné. Aj keď je možné mať stĺpec Rok vo všetkých dátumových tabuľkách (názvy stĺpcov sú v rámci tabuľky jedinečné), nie je samopopisný podľa predvolených názvov vizuálov. Pouvažujte o premenovaní stĺpcov v každej tabuľke rolí dimenzií, aby tabuľka Dátum odoslania mala stĺpec roka s názvom Rok odoslania atď.
  • Ak je to dôležité, zabezpečte, aby popisy tabuliek poskytovali spätnú väzbu autorom zostáv (prostredníctvom popisov tably Polia) o spôsobe konfigurácie distribúcie filtrov. Táto jasnosť je dôležitá, keď model obsahuje všeobecne pomenovanú tabuľku, ako je napríklad Dátum, ktorá sa používa na filtrovanie viacerých tabuliek faktov. V prípade, že táto tabuľka má napríklad aktívny vzťah k stĺpcu dátumov predajných objednávok predajcu, pouvažujte o uvedení popisu tabuľky, napríklad „Filtruje predaj predajcu podľa dátumu objednávky“.

Ďalšie informácie nájdete v téme Pokyny na prácu s aktívnymi a neaktívnymi vzťahmi.

Nevyžiadané dimenzie

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

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

Tabuľka nevyžiadanej dimenzie je zvyčajne kartézskym súčinom všetkých členov atribútu dimenzie so stĺpcom náhradného kľúča. Náhradný kľúč poskytuje jedinečný odkaz na každý riadok v tabuľke. 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).

Príklad nevyžiadanej dimenzie

Tento dotaz načítate do modelu ako tabuľku dimenzie. Tento dotaz tiež treba zlúčiť s dotazom faktu, takže stĺpec indexu sa načíta do modelu a podporí vytvorenie vzťahu typu „one-to-many“.

Dimenzie faktov

Dimenzia faktov odkazuje na atribút tabuľky faktov, ktorá sa vyžaduje na filtrovanie. Čo sa týka spoločnosti Adventure Works, dobrým príkladom je číslo predajnej objednávky predajcu. V tomto prípade v rámci návrhu modelu nedáva zmysel vytvoriť nezávislú tabuľku, ktorá sa skladá len z tohto jedného stĺpca, pretože by sa zvýšila veľkosť ukladacieho priestoru modelu a vznikli nepotrebné položky na table Polia.

V modeli Power BI môže byť vhodné pridať stĺpec s číslom predajnej objednávky do tabuľky faktov a povoliť tak filtrovanie alebo zoskupenie podľa čísla predajnej objednávky. 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).

Príklad dimenzie faktov

Ak však tabuľka predaja predajcov Adventure Works obsahuje stĺpce s číslom objednávky a s číslom riadka objednávky a sú potrebné na filtrovanie, tabuľka dimenzií faktov by bola vhodným návrhom. Ďalšie informácie nájdete v téme Pokyny na prácu so vzťahmi 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, pričom je to prístup návrhu modelu 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.

Príklad tabuľky faktov bez faktov

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

Ďalší postup

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