Olvasás angol nyelven

Megosztás a következőn keresztül:


A csillagséma és a Power BI fontossága

Ez a cikk a Power BI Desktop adatmodellezőit célozza meg. Ismerteti a csillagséma kialakítását és jelentőségét a teljesítményre és használhatóságra optimalizált Power BI szemantikai modellek fejlesztésében.

Fontos

A Power BI szemantikai modelljei a Power Querytől függnek az adatok importálásához vagy az adatokhoz való csatlakozáshoz. Ez azt jelenti, hogy a Power Query használatával kell átalakítania és előkészítenie a forrásadatokat, ami nagy adatmennyiségek esetén kihívást jelenthet, vagy olyan speciális fogalmakat kell implementálnia, mint a dimenziók lassan változó (a cikk későbbi részében ismertetett).

Amikor ezeket a kihívásokat mutatják be, javasoljuk, hogy először dolgozzon ki egy adattárházat, majd bontsa ki, alakítsa át és töltse be (ETL) folyamatokat az adattárház rendszeres betöltéséhez. A szemantikai modell ezután csatlakozhat az adattárházhoz. További információ: Dimenziómodellezés a Microsoft Fabric Warehouse-ban.

Tipp.

Ez a cikk nem célja a csillagséma-tervezés teljes körű megvitatása. További információkért tekintse meg közvetlenül a széles körben elfogadott közzétett tartalmakat, például Ralph Kimball és mások által kiadott The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3. kiadás, 2013).

Csillagséma áttekintése

A csillagséma a relációs adattárházak által széles körben alkalmazott, kiforrott modellezési megközelítés. A modellezőknek dimenzióként vagy tényként kell besorolniuk a modelltábláikat.

  • A dimenziótáblák az üzleti entitásokat írják le – a modellel kapcsolatos dolgokat . Az entitások tartalmazhatnak termékeket, személyeket, helyeket és fogalmakat, beleértve magát az időt is. A csillagsémában a legkonzisztensebb táblázat egy dátum dimenziótábla. A dimenziótáblák olyan kulcsoszlopokat (vagy oszlopokat) tartalmaznak, amelyek egyedi azonosítóként szolgálnak, és más oszlopokat is tartalmaznak. Más oszlopok támogatják az adatok szűrését és csoportosítását.
  • A ténytáblák megfigyeléseket vagy eseményeket tárolnak, és lehetnek értékesítési rendelések, részvényegyenlegek, árfolyamok, hőmérsékletek stb. A ténytáblák dimenziótáblákhoz és numerikus mértékoszlopokhoz kapcsolódó dimenziókulcs-oszlopokat tartalmaznak. A dimenziókulcs oszlopai határozzák meg egy ténytábla dimenzióját , a dimenziókulcs értékei pedig a ténytáblák részletességét . Vegyük például egy olyan ténytáblát, amely két dimenziókulcsoszlopot Date és ProductKey. Könnyen érthető, hogy a táblázat két dimenzióval rendelkezik. A részletesség azonban nem határozható meg a dimenziókulcs értékeinek mérlegelése nélkül. Ebben a példában vegye figyelembe, hogy az oszlopban Date tárolt értékek minden hónap első napja. Ebben az esetben a részletesség havi termékszinten van.

A dimenziótáblák általában viszonylag kis számú sort tartalmaznak. A ténytáblák viszont nagy számú sort tartalmazhatnak, és idővel tovább növekedhetnek.

Csillagséma illusztrációját ábrázoló ábra.

Normalizálás és denormalizálás

A cikkben ismertetett csillagséma-fogalmak megértéséhez fontos, hogy két kifejezést ismerjen: a normalizálást és a denormalizálást.

A normalizálás az ismétlődő adatok csökkentése érdekében tárolt adatok leírására használatos kifejezés. Fontolja meg egy olyan terméktáblát, amely egyedi kulcsértékoszlopot tartalmaz, például a termékkulcsot és a termékjellemzőket leíró egyéb oszlopokat, például a termék nevét, kategóriáját, színét és méretét. Az értékesítési tábla akkor tekinthető normalizáltnak, ha csak kulcsokat tárol, például a termékkulcsot. Az alábbi képen figyelje meg, hogy csak az ProductKey oszlop rögzíti a terméket.

Termékkulcs oszlopot tartalmazó adattáblát ábrázoló diagram.

Ha azonban az értékesítési tábla a kulcson túl tárolja a termék részleteit, akkor azt denormalizáltnak tekintjük. Az alábbi képen figyelje meg, hogy a ProductKey termékhez kapcsolódó egyéb oszlopok rögzítik a terméket.

Egy termékkulcsot és más termékhez kapcsolódó oszlopokat tartalmazó adattáblát ábrázoló diagram, beleértve a Kategória, a Szín és a Méret oszlopot.

Ha egy exportálási fájlból vagy adatkivonatból származó adatokat hoz létre, valószínű, hogy denormalizált adatkészletet jelöl. Ebben az esetben a Power Query használatával alakítsa át és alakítsa át a forrásadatokat több normalizált táblává.

A cikkben leírtaknak megfelelően törekedjen optimalizált Power BI szemantikai modellek fejlesztésére olyan táblákkal, amelyek normalizált tény- és dimenzióadatokat képviselnek. Van azonban egy kivétel, amikor egy hópehelydimenzió denormalizálható egyetlen modelltábla létrehozásához.

Csillagséma relevanciája a Power BI szemantikai modelljeiben

A csillagséma kialakítása és a cikkben bemutatott számos kapcsolódó fogalom rendkívül fontos a teljesítményre és használhatóságra optimalizált Power BI-modellek fejlesztése szempontjából.

Vegye figyelembe, hogy minden Power BI-jelentésvizualizáció létrehoz egy lekérdezést, amelyet a Power BI szemantikai modellnek küld. A lekérdezések általában szűrik, csoportosítják és összegzik a modelladatokat. A jól megtervezett modell tehát olyan, amely táblákat biztosít a szűréshez és csoportosításhoz, valamint táblákat az összegzéshez. Ez a kialakítás jól illeszkedik a csillagséma alapelveihez:

  • A dimenziótáblák lehetővé teszik a szűrést és a csoportosítást.
  • A ténytáblák lehetővé teszik az összegzést.

Nincs olyan táblatulajdonság, amelyet a modellezők dimenzióként vagy tényként állíthatnak be. Valójában a modellkapcsolatok határozzák meg. A modellkapcsolat két tábla közötti szűrőpropagálási útvonalat hoz létre, és a táblatípust meghatározó kapcsolat számosságtulajdonsága. A gyakori kapcsolatok számossága az egy-a-többhöz vagy az inverz több-az-egyhez. Az "egy" oldal mindig dimenziótábla, míg a "több" oldal mindig ténytábla.

Csillagséma fogalmi ábráját ábrázoló ábra.

A jól strukturált modellterv olyan táblákat tartalmaz, amelyek dimenziótáblák vagy ténytáblák. Ne keverje össze a két típust egyetlen táblához. Azt is javasoljuk, hogy törekedjen arra, hogy a megfelelő számú táblát adja meg a megfelelő kapcsolatokkal. Az is fontos, hogy a ténytáblák mindig konzisztens szemcseméretben töltik be az adatokat.

Végül fontos tisztában lenni azzal, hogy az optimális modelltervezés részben tudomány, részben művészet. Néha szakíthat a jó útmutatással, ha van értelme ezt megtenni.

A csillagséma-tervezéshez számos olyan fogalom kapcsolódik, amely alkalmazható a Power BI szemantikai modellre. Ezek a fogalmak a következők:

Mértékek

A csillagséma kialakításában a mérték egy ténytábla oszlop, amely az összegzendő értékeket tárolja. A Power BI szemantikai modellben a mértékek definíciója eltérő , de hasonló. A modellek explicit és implicit mértékeket is támogatnak.

  • Az explicit mértékek kifejezetten létrejönnek, és egy adatelemzési kifejezésekben (DAX) írt képleten alapulnak, amely lehetővé teszi az összegzést. A mértékkifejezések gyakran használnak DAX aggregációs függvényeket, például SUM, MIN, MAX, AVERAGEés más függvényeket a skaláris érték eredményének lekérdezési időpontban történő létrehozásához (az értékek soha nem tárolódnak a modellben). A mértékkifejezés az egyszerű oszlopösszesítésektől a szűrőkörnyezetet és/vagy a kapcsolat propagálását felülíró kifinomultabb képletekig terjedhet. További információkért olvassa el a DAX alapjait a Power BI Desktopban.
  • Az implicit mértékek olyan oszlopok, amelyeket egy jelentésvizualizáció vagy a Q&A összegzhet. Modellfejlesztőként kényelmes megoldást kínálnak, mivel sok esetben nem kell (explicit) mértékeket létrehoznia. Az Adventure Works viszonteladói értékesítési Sales Amount oszlopa például számos módon (összeg, darabszám, átlag, medián, perc, max és egyéb) összegezhető anélkül, hogy minden lehetséges összesítési típushoz létre kellene hoznia egy mértéket.

Az Adatok panelen az explicit mértékeket a számológép ikon, míg az implicit mértékeket a szigma szimbólum (∑) jelöli.

Az Adatok panelen található ikonokat ábrázoló diagram.

A mértékek létrehozásának azonban három meggyőző oka lehet, még az egyszerű oszlopszintű összegzésekhez is:

  • Ha tudja, hogy a jelentéskészítők többdimenziós kifejezések (MDX) használatával kérdezik le a szemantikai modellt, a modellnek explicit mértékeket kell tartalmaznia. Ennek az az oka, hogy az MDX nem képes az oszlopértékek összegzésére. Az MDX-et az Elemzés excelben történő végrehajtásakor használják, mivel a kimutatások MDX-lekérdezéseket adnak ki.

  • Ha tudja, hogy a jelentéskészítők többoldalas Power BI-jelentéseket hoznak létre az MDX lekérdezéstervezővel, a szemantikai modellnek explicit mértékeket kell tartalmaznia. Csak az MDX-lekérdezéstervező támogatja a kiszolgálói összesítéseket. Ha tehát a jelentéskészítőknek a Power BI által kiértékelt mértékekkel kell rendelkezniük (a lapszámozott jelentésmotor helyett), akkor az MDX-lekérdezéstervezőt kell használniuk.

  • Ha azt szeretné szabályozni, hogy a jelentéskészítők hogyan összegzik az oszlopokat bizonyos módokon. A viszonteladói értékesítési Unit Price oszlop (amely egységenkénti díjszabást jelöl) például összegezhető, de csak adott aggregációs függvények használatával. Soha nem kell összegezni, de célszerű más összesítési függvények( például min, max vagy átlag) használatával összegezni. Ebben az esetben a modellező elrejtheti az Unit Price oszlopot, és mértékeket hozhat létre az összes megfelelő összesítési függvényhez.

    Ez a tervezési megközelítés jól működik a Power BI szolgáltatás és a Q&A-ban készített jelentésekhez. A Power BI Desktop élő kapcsolatai azonban lehetővé teszik a jelentéskészítők számára, hogy rejtett mezőket jelenítsenek meg az Adatok panelen, ami megkerülheti ezt a tervezési megközelítést.

Helyettesítő kulcsok

A helyettesítő kulcs egy egyedi azonosító, amelyet a csillagséma modellezésének támogatásához ad hozzá egy táblához. Definíció szerint nincs definiálva vagy tárolva a forrásadatokban. A relációs adattárház dimenziótábláihoz gyakran helyettesítő kulcsokat adnak hozzá, hogy egyedi azonosítót adjanak az egyes dimenziótáblák soraihoz.

A Power BI szemantikai modellkapcsolatai egy tábla egyetlen egyedi oszlopán alapulnak, amely egy másik tábla egyetlen oszlopára propagálja a szűrőket. Ha a szemantikai modell egyik dimenziótáblája nem tartalmaz egyetlen egyedi oszlopot, egy egyedi azonosítót kell hozzáadnia ahhoz, hogy a kapcsolat "egy" oldalává váljon. A Power BI Desktopban ezt a követelményt egy Power Query-indexoszlop hozzáadásával érheti el.

Diagram az indexoszlop létrehozása parancsról Power Query-szerkesztő.

A lekérdezést egyesítenie kell a "többoldalas lekérdezéssel", hogy az indexoszlopot is hozzá lehessen adni. Amikor betölti ezeket a lekérdezéseket a szemantikai modellbe, létrehozhat egy-a-többhöz kapcsolatot a modelltáblák között.

Hópehely méretei

A hópehely dimenzió egy üzleti entitás normalizált tábláinak készlete. Az Adventure Works például kategóriák és alkategóriák szerint sorolja be a termékeket. A termékek alkategóriákhoz vannak rendelve, az alkategóriák pedig kategóriákhoz vannak rendelve. Az Adventure Works relációs adattárházban a termék dimenziója normalizálva van, és három kapcsolódó táblában van tárolva: DimProductCategory, DimProductSubcategoryés DimProduct.

Egy három kapcsolódó táblából álló hópehelydiagramot bemutató ábra.

Ha a képzeletét használja, a normalizált táblákat a ténytáblától kifelé helyezve képzelheti el, és hópehely-kialakítást alkothat.

Három kapcsolódó táblázatból álló hópehelydiagram fogalmi példáját bemutató ábra.

A Power BI Desktopban választhat, hogy egy hópehely dimenziótervet utánoz (talán azért, mert a forrásadatok igen), vagy kombinálhatja a forrástáblákat egyetlen, denormalizált modelltábla létrehozásához. Általában az egyetlen modelltábla előnyei több modelltábla előnyeit is felülmúlják. A legoptimálisabb döntés az adatok mennyiségétől és a modell használhatósági követelményeitől függhet.

Ha a hópehely dimenzióterv utánzása mellett dönt:

  • A Power BI több táblát tölt be, ami a tárolás és a teljesítmény szempontjából kevésbé hatékony. Ezeknek a tábláknak oszlopokat kell tartalmazniuk a modellkapcsolatok támogatásához, és nagyobb modellméretet eredményezhetnek.
  • Hosszabb kapcsolatszűrő-propagálási láncokat kell bejárni, ami kevésbé hatékony, mint az egyetlen táblára alkalmazott szűrők.
  • Az Adatpanel több modelltáblát jelenít meg a jelentéskészítők számára, ami kevésbé intuitív élményt eredményezhet, különösen akkor, ha a hópehely dimenziótáblái csak egy vagy két oszlopot tartalmaznak.
  • Nem lehet olyan hierarchiát létrehozni, amely egynél több táblából származó oszlopokat tartalmaz.

Ha úgy dönt, hogy egyetlen modelltáblába integrálódik, meghatározhat egy hierarchiát is, amely a dimenzió legmagasabb és legalacsonyabb szemcséit foglalja magában. Lehetséges, hogy a redundáns denormalizált adatok tárolása megnövelheti a modell tárolási méretét, különösen a nagy méretű táblák esetében.

Egy olyan dimenziótáblán belüli hierarchia példáját bemutató diagram, amely olyan oszlopokat tartalmaz, mint a Kategória, az Alkategória és a Termék.

Lassan változó dimenziók

A lassan változó dimenzió (vagy SCD) megfelelően kezeli a dimenziótagok időbeli változásait. Akkor érvényes, ha az üzleti entitások értékei nem tervezett módon lassan változnak az idő múlásával. Az SCD-re jó példa az ügyfél dimenziója, mivel az olyan kapcsolattartási adatok oszlopai, mint az e-mail-cím és a telefonszámok ritkán változnak. Ezzel szemben egyes dimenziók gyorsan változónak tekinthetők, amikor egy dimenzióattribútum gyakran változik, például egy részvény piaci ára. Ezekben a példányokban a gyakori tervezési módszer a gyorsan változó attribútumértékek tárolása egy ténytábla-mértékben.

A csillagséma-tervezés elmélete két gyakori SCD-típusra utal: 1. és 2. típusra. A dimenziótáblák lehetnek 1- vagy 2-es típusúak, vagy mindkét típust egyszerre támogatják a különböző oszlopokhoz.

1. típus SCD

Az 1 . típusú SCD mindig a legújabb értékeket tükrözi, és a forrásadatok változásainak észlelésekor a dimenziótábla adatai felülíródnak. Ez a kialakítási módszer gyakori az olyan oszlopok esetében, amelyek kiegészítő értékeket tárolnak, például egy ügyfél e-mail-címét vagy telefonszámát. Amikor egy ügyfél e-mail-címe vagy telefonszáma megváltozik, a dimenziótábla frissíti az ügyfélsort az új értékekkel. Ez olyan, mintha az ügyfél mindig ezeket a kapcsolattartási adatokat.

Egy lassan változó 1. dimenziótípust bemutató diagram, amelyen egy alkalmazott telefonszáma frissül.

A Power BI-modell dimenziótábláinak nem növekményes frissítése 1- es típusú SCD-t eredményez. Frissíti a táblaadatokat, hogy a legújabb értékek be legyenek töltve.

2. típus SCD

A 2 . típusú SCD támogatja a dimenziótagok verziószámozását. Ha a forrásrendszer nem tárolja a verziókat, általában az adattárház betöltési folyamata észleli a változásokat, és megfelelően kezeli a módosítást egy dimenziótáblában. Ebben az esetben a dimenziótáblának helyettesítő kulccsal kell megadnia a dimenziótag egy verziójára mutató egyedi hivatkozást. Olyan oszlopokat is tartalmaz, StartDate amelyek meghatározzák a verzió dátumtartományának érvényességét (például és EndDate) és esetleg egy jelzőoszlopot (például IsCurrent) a jelenlegi dimenziótagok egyszerű szűréséhez.

Az Adventure Works például minden értékesítőt hozzárendel egy értékesítési régióhoz. Amikor egy értékesítő áthelyezi a régiót, létre kell hozni az értékesítő új verzióját annak érdekében, hogy a korábbi adatok továbbra is a korábbi régióhoz legyenek társítva. Az értékesítők által történő értékesítések pontos múltbeli elemzésének támogatásához a dimenziótáblának tárolnia kell az értékesítők és a hozzájuk tartozó régió(k) verzióit. A táblának tartalmaznia kell a kezdő és a záró dátum értékeit is az idő érvényességének meghatározásához. Az aktuális verziók üres záródátumot (vagy 9999. 12. 31.) definiálhatnak, ami azt jelzi, hogy a sor az aktuális verzió. A táblának helyettesítő kulccsal is rendelkeznie kell, mert az üzleti kulcs (ebben az esetben az alkalmazott azonosítója) nem lesz egyedi.

Egy lassan változó 2. dimenziótípust bemutató ábra, amelyben egy alkalmazotti értékesítési régió frissül egy új verzió létrehozásával.

Fontos tisztában lenni azzal, hogy ha a forrásadatok nem tárolnak verziókat, köztes rendszert (például adattárházat) kell használnia a változások észleléséhez és tárolásához. A táblabetöltési folyamatnak meg kell őriznie a meglévő adatokat, és észlelnie kell a módosításokat. Ha változás észlelhető, a táblabetöltési folyamatnak le kell járnia az aktuális verziót. Ezeket a módosításokat úgy rögzíti, hogy frissíti az EndDate értéket, és beszúr egy új verziót az StartDate előző EndDate értékből kiinduló értékkel. Emellett a kapcsolódó tényeknek időalapú kereséssel kell lekérniük a ténydátum szempontjából releváns dimenziókulcs-értéket. A Power BI szemantikai modellje a Power Queryt használja, ezért nem tudja előállítani ezt az eredményt. Azonban adatokat tölthet be egy előre betöltött SCD 2. típusú dimenziótáblából.

Tipp.

Ha tudni szeretné, hogyan implementálhat 2. típusú SCD dimenziótáblát egy Fabric-raktárban, olvassa el az előzményváltozás kezelése című témakört.

A Power BI szemantikai modelljének támogatnia kell egy tag előzményadatainak lekérdezését a változástól függetlenül, valamint a tag egy olyan verziójához, amely a tag egy adott állapotát jelöli időben. Az Adventure Works kontextusában ez a kialakítás lehetővé teszi az értékesítő lekérdezését a hozzárendelt értékesítési régiótól vagy az értékesítő egy adott verziójától függetlenül.

Ennek a követelménynek az eléréséhez a Power BI szemantikai modell dimenziótáblájának tartalmaznia kell egy oszlopot az értékesítő szűréséhez, és egy másik oszlopot az értékesítő egy adott verziójának szűréséhez. Fontos, hogy a verzió oszlop nem egyértelmű leírást adjon, például David Campbell (12/15/2008-06/26/2019) vagy David Campbell (06/27/2019-Current). Fontos továbbá, hogy a jelentéskészítők és a felhasználók megismerkedjenek az SCD 2. típusának alapjaival, valamint a megfelelő szűrők alkalmazásával a megfelelő jelentéstervek kialakításának módjával.

Ez egy jó tervezési gyakorlat, ha olyan hierarchiát tartalmaz, amely lehetővé teszi a vizualizációk számára a verziószintre való lehatolást.

A Salesperson és a Salesperson Version oszlopokat tartalmazó Adat panelt ábrázoló diagram.

Többszerepű dimenziók

A szerepkör-lejátszási dimenziók olyan dimenziók, amelyek eltérő módon szűrhetik a kapcsolódó tényeket. Az Adventure Works esetében például a dátum dimenziótábla három kapcsolatban áll a viszonteladói értékesítési tényekkel. Ugyanezzel a dimenziótáblával szűrheti a tényeket a rendelés dátuma, a szállítási dátum vagy a szállítási dátum alapján.

Egyetlen szerepkör-lejátszási dimenzió és kapcsolatok fogalmi példáját bemutató ábra. A Dátum tábla két kapcsolatot tartalmaz a ténytáblával a rendelés dátuma és a szállítási dátum esetében.

Az adattárházakban az elfogadott tervezési módszer egy dátumdimenziós tábla definiálása. Lekérdezéskor a dátumdimenzió "szerepkörét" az határozza meg, hogy melyik tényoszlopot használja a táblákhoz való csatlakozáshoz. Ha például rendelési dátum alapján elemzi az értékesítéseket, a tábla összekapcsolása a viszonteladói értékesítési rendelés dátum oszlopához kapcsolódik.

Egy Power BI szemantikai modellben ezt a tervet két tábla közötti több kapcsolat létrehozásával lehet utánozni. Az Adventure Works-példában a dátum- és viszonteladói értékesítési táblák három kapcsolatból állhatnak.

Egy példa egy szerepjáték dimenzióra és kapcsolatokra. A Date tábla három kapcsolatot tartalmaz a ténytáblával.

Bár ez a kialakítás lehetséges, csak egy aktív kapcsolat lehet két Power BI szemantikai modelltábla között. Minden fennmaradó kapcsolatot inaktívra kell állítani. Egyetlen aktív kapcsolat azt jelenti, hogy egy alapértelmezett szűrőpropagálás van a dátumtól a viszonteladói értékesítésig. Ebben az esetben az aktív kapcsolat a jelentések által használt leggyakoribb szűrőre van állítva, amely az Adventure Works-ben a rendelési dátum kapcsolat.

Az inaktív kapcsolatok egyetlen módja egy OLYAN DAX-kifejezés definiálása, amely a USERELATIONSHIP függvényt használja. Példánkban a modellfejlesztőnek olyan mértékeket kell létrehoznia, amelyek lehetővé teszik a viszonteladói értékesítések elemzését szállítási dátum és szállítási dátum szerint. Ez a munka fárasztó lehet, különösen akkor, ha a viszonteladói tábla számos mértéket határoz meg. Emellett létrehoz egy zsúfolt adatpanelt is, amely túlterjed a mértékek között. Vannak más korlátozások is:

  • Ha a jelentéskészítők a mértékek meghatározása helyett az oszlopok összegzésére támaszkodnak, akkor jelentésszintű mérték írása nélkül nem érhetik el az inaktív kapcsolatok összegzését. Jelentésszintű mértékek csak jelentések Power BI Desktopban történő létrehozásakor határozhatók meg.
  • Egyetlen aktív kapcsolati útvonallal a dátum és a viszonteladói értékesítés között nem lehet egyszerre szűrni a viszonteladói értékesítéseket különböző dátumtípusok szerint. Nem hozhat létre például olyan vizualizációt, amely a rendelési dátum értékesítését szállítási értékesítések szerint ábrázolja.

Ezeknek a korlátozásoknak a leküzdése érdekében a Power BI modellezési módszere gyakran egy dimenziótáblát hoz létre az egyes szerepkör-lejátszású példányokhoz. Az egyes dimenziótáblákat hivatkozási lekérdezésként hozhatja létre a Power Query vagy a DAX használatával. A modell tartalmazhat egy táblát Date , egy táblát Ship Date és egy táblát Delivery Date , amelyek mindegyike egyetlen és aktív kapcsolatban áll a viszonteladói értékesítési tábla oszlopaival.

Példa a szerepkör-lejátszás dimenzióira és kapcsolataira. A ténytáblához három különböző dátumdimenzió-tábla kapcsolódik.

Ez a tervezési megközelítés nem követeli meg, hogy több mértéket definiáljon a különböző dátumszerepkörökhöz, és lehetővé teszi az egyidejű szűrést különböző dátumszerepkörök szerint. Ezzel a kialakítási megközelítéssel azonban kisebb árat kell fizetni, ha a dátum dimenziótáblájának duplikálása megnöveli a modell tárterületének méretét. Mivel a dimenziótáblák általában kevesebb sort tárolnak a ténytáblákhoz képest, ez ritkán okoz problémát.

Javasoljuk, hogy kövesse a helyes tervezési eljárásokat, amikor modelldimenzió-táblákat hoz létre az egyes szerepkörökhöz:

  • Győződjön meg arról, hogy az oszlopnevek önleírók. Bár lehetséges, hogy minden dátumtáblában szerepel egy Year oszlop (az oszlopnevek egyediek a táblájukban), az alapértelmezett vizualizációcímek nem önleírók. Fontolja meg az oszlopok átnevezését minden dimenziószerepkör-táblában, hogy a Ship Date táblában legyen egy év oszlop neve Ship Year, és így tovább.
  • Ha releváns, győződjön meg arról, hogy a táblaleírások visszajelzést küldenek a jelentéskészítőknek (az Adatpanel elemleírásain keresztül) a szűrőpropagálás beállításáról. Ez az egyértelműség akkor fontos, ha a modell egy általánosan elnevezett táblát tartalmaz, például Dateegy olyan táblát, amely számos ténytáblát szűr. Abban az esetben, ha ez a tábla például aktív kapcsolatban áll a viszonteladói értékesítési rendelés dátum oszlopával, érdemes lehet megadni a tábla leírását, például Filters reseller sales by order date: .

További információ: Aktív és inaktív kapcsolati útmutató.

Levélszemétdimenziók

A levélszemét dimenzió akkor hasznos, ha sok dimenzió van, különösen kevés attribútumból (talán egyből), és ha ezek az attribútumok kevés értékkel rendelkeznek. A jó jelöltek közé tartoznak a rendelési állapotoszlopok, vagy az ügyfél demográfiai oszlopai, például a nem vagy a korcsoport.

A levélszemétdimenziók tervezési célja, hogy számos kis dimenziót egyetlen dimenzióba egyesítsenek a modell tárolási méretének csökkentése és az Adatpanel zsúfoltságának csökkentése érdekében kevesebb modelltáblával.

A levélszemét dimenziótáblák általában az összes dimenzióattribútum-tag Cartesian-terméke, egy helyettesítő kulcsoszlopmal , amely egyedileg azonosítja az egyes sorokat. Létrehozhatja a dimenziót egy adattárházban, vagy a Power Query használatával létrehozhat egy olyan lekérdezést, amely teljes külső lekérdezési illesztéseket hajt végre, majd hozzáad egy helyettesítő kulcsot (indexoszlop).

Egy levélszemét dimenziótáblát bemutató ábra. A rendelés állapota három állapotú, míg a kézbesítési állapot két állapotú. A levélszemét dimenziótáblája a két állapot mind a hat kombinációját tárolja.

Ezt a lekérdezést dimenziótáblaként tölti be a modellbe. Ezt a lekérdezést a tény lekérdezéssel is egyesítenie kell, hogy az indexoszlop be legyen töltve a modellbe, hogy támogassa az "egy-a-többhöz" modellkapcsolat létrehozását.

Dimenziók degenerálása

A degenerált dimenzió a szűréshez szükséges ténytábla attribútumára utal. Az Adventure Worksben a viszonteladói értékesítési rendelés száma jó példa. Ebben a példában nincs értelme olyan független táblát létrehozni, amely csak ebből az egy oszlopból áll, mert növeli a modell tárterületének méretét, és zsúfoltsághoz vezetne az Adatpanelen.

A Power BI szemantikai modelljében célszerű lehet hozzáadni az értékesítési rendelésszám oszlopot a ténytáblához, hogy lehetővé tegye a szűrést vagy csoportosítást értékesítési rendelésszám alapján. Ez kivétel a korábban bevezetett szabály alól, amely alól nem szabad táblatípusokat keverni (általában a modelltábláknak dimenziónak vagy ténynek kell lenniük).

Az Adatok panelt és az értékesítési ténytáblát ábrázoló diagram, amely tartalmazza a Rendelésszám mezőt.

Ha azonban az Adventure Works viszonteladói értékesítési tábla rendelésszámmal és rendeléssorszám oszlopokkal rendelkezik, és szűrésre van szükség, akkor a degenerált dimenziótáblák létrehozása jó terv lenne. További információ: Egy-az-egyhez kapcsolat útmutató (Dimenziók degenerálása).

Tény nélküli ténytáblák

A tény nélküli ténytáblák nem tartalmaznak mértékoszlopokat. Csak dimenziókulcsokat tartalmaz.

A tény nélküli ténytáblák a dimenziókulcsok által meghatározott megfigyeléseket tárolhatják. Például egy adott napon és időpontban egy adott ügyfél jelentkezett be a webhelyére. Meghatározhat egy mértéket, amely megszámolja a tény nélküli ténytábla sorait annak elemzéséhez, hogy mikor és hány ügyfél jelentkezett be.

A tény nélküli ténytáblák meggyőzőbb használata a dimenziók közötti kapcsolatok tárolása, és ez egy Power BI szemantikai modelltervezési megközelítés, amelyet a több-a-többhöz dimenziókapcsolatok definiálásához ajánlott. A több-a-többhöz dimenziókapcsolat kialakításában a tény nélküli ténytáblát áthidaló táblának nevezzük.

Tegyük fel például, hogy az értékesítők egy vagy több értékesítési régióhoz rendelhetők. Az áthidaló tábla egy tény nélküli ténytáblaként lett kialakítva, amely két oszlopból áll: az üzletkötőkulcsból és a régiókulcsból. Az ismétlődő értékek mindkét oszlopban tárolhatók.

Az üzletkötő és a régió dimenzióit áthidaló ténytáblát ábrázoló ábra. A tény nélküli ténytábla két oszlopból áll, amelyek a dimenziókulcsok.

Ez a több-a-többhöz tervezési megközelítés jól dokumentált, és áthidaló tábla nélkül is megvalósítható. Két dimenzió összekapcsolásakor azonban az áthidaló táblázat megközelítése az ajánlott eljárás. További információ: Több-a-többhöz kapcsolati útmutató (Két dimenzió típusú tábla összekapcsolás).

A csillagséma tervezésével vagy a Power BI szemantikai modelltervével kapcsolatos további információkért tekintse meg az alábbi cikkeket: