Udalosti
Pridajte sa k nám vo Vegas FabCon
31. 3., 23 - 2. 4., 23
Konečná udalosť pod vedením komunity služby Microsoft Fabric, Power BI, SQL a AI. Marec 31 až Apríl 2, 2025.
Zaregistrujte saTento prehliadač už nie je podporovaný.
Inovujte na Microsoft Edge a využívajte najnovšie funkcie, aktualizácie zabezpečenia a technickú podporu.
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.
Tip
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ší.
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.
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ť.
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.
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.
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.
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:
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.
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ú:
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.
SUM
, MIN
, MAX
, AVERAGE
a ď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.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 (∑).
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ľúč 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.
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á 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 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:
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í.
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.
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.
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ý.
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.
Tip
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.
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 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.
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:
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.
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:
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 Year
atď.Date
naprí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á 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).
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".
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).
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ľ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.
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í).
Ď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:
Udalosti
Pridajte sa k nám vo Vegas FabCon
31. 3., 23 - 2. 4., 23
Konečná udalosť pod vedením komunity služby Microsoft Fabric, Power BI, SQL a AI. Marec 31 až Apríl 2, 2025.
Zaregistrujte saŠkolenie
Modul
Návrh sémantického modelu v službe Power BI - Training
Proces vytvárania zložitého sémantického modelu v službe Power BI je jednoduchý. Ak vaše údaje pochádzajú z viacerých transakčných systémov, ani sa nenazdáte a budete mať pred sebou desiatky tabuliek, ktoré bude treba spracovať. Vytvorenie veľkého sémantického modelu je o zjednodušení zmätku. Jedným zo spôsobov zjednodušenia sémantického modelu je hviezdicová schéma. V tomto module sa oboznámite s terminológiou a s jej implementáciou. Získate tiež informácie o tom, prečo je výber správnej granularity údajov
Certifikácia
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Demonstrate methods and best practices that align with business and technical requirements for modeling, visualizing, and analyzing data with Microsoft Power BI.