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

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 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 ď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 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 čí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í, a to Date (Dátum) a ProductKey (KódProduktu). 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 stĺpci Date (Dátum ) predstavujú prvý deň každého mesiaca. 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ľmi veľký počet riadkov a v priebehu času môžu naďalej rásť.

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 popisujúce vlastnosti produktu vrátane názvu produktu, kategórie, farby a veľkosti. 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á iba stĺpec ProductKey .

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 ProductKey (KódProduktu) a ďalších stĺpcoch súvisiacich s produktom sa produkt zaznamená.

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 dátových modelov Power BI s tabuľkami, ktoré predstavujú normalizované údaje faktov a údaje dimenzií. Existuje však jedna výnimka, kde by sa mal denormalizovať dimenzia v tvare snehovej vločky na vytvorenie jednej tabuľky modelu.

Význam hviezdicovej schémy pre modely 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 (ktorý služba Power BI nazýva sémantický model – predtým známy ako 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 konfiguráciu 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" vždy predstavuje tabuľku dimenzií a strana "many" 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.

Dobre štruktúrovaný návrh modelu by mal obsahovať 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ť vhodný počet tabuliek s vhodnými vzťahmi. Dôležité je tiež to, že tabuľky faktov vždy načítavajú údaje v súvislom 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ý.

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ú:

• Opatrenia
• Náhradné kľúče
• Vločkové dimenzie
• Dimenzie zohrávajúci roly
• Pomaly sa meniace dimenzie
• Nevyžiadané dimenzie
• Dimenzie faktov
• Tabuľky faktov bez faktov

Miery

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 rámci 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 .

Je dôležité pochopiť, že modely Power BI podporujú aj druhú metódu na dosiahnutie sumarizácie. Všetky stĺpce, zvyčajne číselné stĺpce, možno 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 predajcu Adventure Works je napríklad možné sumarizovať mnohými spôsobmi (súčet, počet, priemer, medián, minimum, maximum atď.) bez toho, aby bolo potrebné vytvoriť mierku pre každý možný typ agregácie.

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ú model dotazovať pomocou multidimenzionálnych výrazov (MDX), 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 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 služby MDX, 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ď 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 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, 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ž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 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 poskytujú jedinečný identifikátor pre každý riadok tabuľky dimenzií.

Vzťahy modelov služby Power BI vychádzajú z jedného jedinečného stĺpca v jednej tabuľke, ktorý šíri 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 obsahovať časť "one". V aplikácii Power BI Desktop môžete túto požiadavku jednoducho dosiahnuť vytvorením stĺpca indexu doplnku 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 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, DimProductSubcategory a DimProduct.

Ak použijete svoju fantáziu, môžete si predstaviť normalizované tabuľky umiestnené smerom von z tabuľky faktov, čím sa vytvorí vzhľad snehovej vločky.

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 majú 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:

• 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, najmä 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 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, obzvlášť v prípade veľmi veľkých tabuliek dimenzií.

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 vtedy, 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 podrobnosťami, 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. 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 predstavovať 1. typ aj 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.

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 (Dátum začatia) a EndDate (Dátum ukončenia)), a prípadne aj stĺpec príznaku (napríklad IsCurrent (Je aktuálne)) na jednoduché filtrovanie aktuálnych členov dimenzie.

Adventure Works napríklad priraďuje obchodníkov k oblasti predaja. 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.1999), čo značí, že tento riadok je aktuálnou verziou. 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é 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á aktualizáciou hodnoty EndDate (Dátum ukončenia) a vložením novej verzie s hodnotou StartDate (Dátum začatia ) začínajúca 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 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í 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 neobslúval nejednoznačné popisy, ako napríklad "Michal Novák (15.12.2008 – 26.06.2019)" alebo "Michal Michal Michal (aktuálne)". 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.

Vhodné je tiež zahrnúť do návrhu hierarchiu, ktorá vizuálom umožňuje prejsť na detaily na úrovni verzie.

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.

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 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 dátumov 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.

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:

• Keď 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. Zvyčajne vytvoríte ďalšie tabuľky dimenzií ako vypočítané tabuľky pomocou jazyka DAX. Pomocou 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.

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ú treba zaplatiť, je však takýto prístup k návrhu, že bude sa duplikuje tabuľka dimenzií dátumov, čo má za následok zvýšenú veľkosť 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 obsahuje 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 šírenia 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 zadaní 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 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 (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šili nepotrebné položky na table Polia 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 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).

Tento dotaz načítate do modelu ako tabuľku dimenzií. 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. V spoločnosti Adventure Works je dobrým príkladom čí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 vytvorili by 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).

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 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, 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.

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 modelu v službe Power BI nájdete v nasledujúcich článkoch:

• Článok o dimenzionálnom modelovaní z Wikipédie
• Vytvorenie a spravovanie vzťahov v aplikácii Power BI Desktop
• Pokyny na prístup k vzťahom one-to-one
• Pokyny na vzťahy typu many-to-many
• Pokyny na dvojsmerné vzťahy
• Pokyny na prístup k aktívnym a neaktívnym vzťahom
• Máte nejaké otázky? Skúste sa spýtať Komunita Power BI
• Návrhy? Prispejte nápadmi na zlepšenie služby Power BI