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

Ez a cikk a Power BI Desktop adatmodellezőit célozza meg. A csillagséma kialakítását és a teljesítményre és használhatóságra optimalizált Power BI-adatmodellek fejlesztéséhez való relevanciáját ismerteti.

Ez a cikk nem célja a csillagséma-tervezés teljes körű megvitatása. További részletekért tekintse meg közvetlenül a közzétett tartalmakat, például Ralph Kimball és mások által készített 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 kulcsoszlopot (vagy oszlopokat) tartalmaznak, amelyek egyedi azonosítóként és leíró oszlopokként szolgálnak.

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 az értékesítési célok tárolására szolgál, és két dimenziókulcsoszlopot tartalmaz Dátum é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 a Dátum oszlopban 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 nagyon sok sort tartalmazhatnak, és idővel tovább növekedhetnek.

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, valamint a termék jellemzőit leíró további oszlopokat, beleértve 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. A következő képen figyelje meg, hogy csak a ProductKey oszlop rögzíti a terméket.

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. A következő képen figyelje meg, hogy a ProductKey és más termékhez kapcsolódó oszlopok rögzítik a terméket.

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-adatmodellek 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ót denormalizálni kell egyetlen modelltábla létrehozásához.

Csillagséma relevanciája a Power BI-modellekben

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 Rendszer elküld a Power BI-modellnek (amelyet a Power BI szolgáltatás szemantikai modellnek hív – korábban adatkészletnek). Ezek a lekérdezések a modelladatok szűrésére, csoportosítására és összegzésére szolgálnak. 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 támogatják a szűrést és a csoportosítást
• A ténytáblák támogatják az összegzést

Nincs olyan táblatulajdonság, amelyet a modellezők dimenzióként vagy tényként konfigurálnak. Valójában a modellkapcsolatok határozzák meg. A modellkapcsolatok két tábla között létrehoznak egy szűrőpropagálási útvonalat, és a táblatípust meghatározó kapcsolat Számosság tulajdonsá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ípusú tábla, míg a "több" oldal mindig tény típusú tábla. További információ a kapcsolatokról: Modellkapcsolatok a Power BI Desktopban.

A jól strukturált modelltervnek dimenzió típusú vagy tény típusú táblákat tartalmazó táblákat kell tartalmaznia. 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ény típusú tá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éssel kapcsolatban számos további fogalom alkalmazható a Power BI-modellekre. Ezek a fogalmak a következők:

• Intézkedések
• Helyettesítő kulcsok
• Hópehely méretei
• Szerepkör-lejátszási dimenziók
• Lassan változó dimenziók
• Levélszemétdimenziók
• Dimenziók degenerálása
• Tény nélküli ténytáblá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-modellekben a mértékek definíciója eltérő , de hasonló. Ez egy adatelemzési kifejezésekben (DAX) írt képlet, amely összegzést valósít meg. A mértékkifejezések gyakran használják a DAX aggregációs függvényeket, például a SZUM, a MIN, a MAX, az ÁTLAG stb. függvényt 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 Power BI Desktop DAX-alapjai című cikkét.

Fontos tisztában lenni azzal, hogy a Power BI-modellek támogatnak egy második módszert az összegzés eléréséhez. Bármely oszlopot – és általában numerikus oszlopot – egy jelentésvizualizáció vagy a Q&A összegzhet. Ezeket az oszlopokat implicit mértéknek nevezzük. Modellfejlesztőként kényelmes megoldást kínálnak, mivel sok esetben nem kell mértékeket létrehoznia. Az Adventure Works viszonteladói értékesítési mennyiség oszlopa például számos módon (összeg, darabszám, átlag, medián, min, max stb.) összegezhető anélkül, hogy minden lehetséges összesítési típushoz létre kellene hoznia egy mértéket.

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

• Ha tudja, hogy a jelentéskészítők többdimenziós kifejezések (MDX) használatával kérdezik le a modellt, a modellnek explicit mértékeket kell tartalmaznia. Az explicit mértékek dax használatával vannak definiálva. Ez a tervezési megközelítés rendkívül fontos, ha egy Power BI-adatkészletet MDX használatával kérdeznek le, mert az MDX nem tudja elérni az oszlopértékek összegzését. Az MDX-et az Elemzés az Excelben való végrehajtásakor fogja használni, 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 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 gondoskodnia kell arról, hogy a jelentéskészítők csak bizonyos módokon összegezzenek oszlopokat. A viszonteladói értékesítési egységár oszlop (amely egységár-értéket 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, átlag stb.) használatával összegezni. Ebben az esetben a modellező elrejtheti az Egységár 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, hogy a jelentéskészítők rejtett mezőket jelenítsenek meg a Mezők 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-modellkapcsolatok 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 modell egyik dimenzió típusú 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 egyszerűen elérheti ezt a követelményt egy Power Query-indexoszlop létrehozásával.

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 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 és tárolva van három kapcsolódó táblában: DimProductCategory, DimProductSubcategory és DimProduct.

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.

A Power BI Desktopban választhat, hogy egy hópehely dimenziótervet utánoz (talán azért, mert a forrásadatok igen), vagy integrálhatja (denormalizálhatja) a forrástáblákat egyetlen modelltáblába. Á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 valószínűleg kevésbé lesz hatékony, mint az egyetlen táblára alkalmazott szűrők.
• A Mezők panel 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 a táblákra terjed ki.

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óméretét, különösen a nagyon nagy méretű táblák esetében.

Lassan változó dimenziók

A lassan változó dimenziók (SCD) megfelelően kezelik a dimenziótagok időbeli változásait. Akkor érvényes, ha az üzleti entitások értékei idővel és ad hoc módon változnak. A lassan változó dimenzióra jó példa az ügyféldimenzió, különösen a kapcsolattartási adatok oszlopai, például az e-mail-cím és a telefonszám. 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 árfolyama. 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ípusú táblák lehetnek 1-es 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.

A Power BI-modell dimenzió típusú tábláinak nem növekményes frissítése egy 1. típusú SCD eredményét eredményezi. 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, akkor á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, amelyek meghatározzák a verzió dátumtartományának érvényességét (például StartDate és EndDate), és esetleg egy jelzőoszlopot (például IsCurrent), amellyel egyszerűen szűrhetők az aktuális dimenziótagok.

Az Adventure Works például értékesítőket 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 befejezési dátumot (vagy 9999. 12. 31.) határozhatnak meg, ami azt jelzi, hogy a sor az aktuális verzió. A táblának helyettesítő kulcsot is meg kell határoznia, mert az üzleti kulcs (ebben az esetben az alkalmazott azonosítója) nem lesz egyedi.

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 az EndDate érték frissítésével és egy új verzió beszúrásával rögzíti az előző EndDate értékből kiinduló StartDate é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 Queryt használó Power BI-modellek nem tudják létrehozni ezt az eredményt. Azonban adatokat tölthet be egy előre betöltött SCD 2. típusú dimenziótáblából.

A Power BI-modellnek 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 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-modell dimenzió típusú 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ó oszlopban ne legyen egyértelmű leírás, például "Michael Blythe (2008.12.15.-2019.06.26.)" vagy "Michael Blythe (aktuális)". 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.

Az is 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.

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áblájának három kapcsolata van 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.

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-modellben ez a kialakítás két tábla közötti több kapcsolat létrehozásával utánozható. Az Adventure Works-példában a dátum- és viszonteladói értékesítési táblák három kapcsolatból állhatnak. Bár ez a kialakítás lehetséges, fontos tisztában lenni azzal, hogy két Power BI-modelltábla között csak egy aktív kapcsolat lehet. 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 beállítva, amely az Adventure Works-ben a rendelési dátum kapcsolat.

Az inaktív kapcsolatok egyetlen módja az U Standard kiadás RELATIONSHIP függvényt használó DAX-kifejezés definiálása. 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 a Mezők panel zsúfoltsága is létrejön, a mértékek túlterjedése mellett. Vannak más korlátozások is:

• Ha a jelentéskészítők az oszlopok összegzésére támaszkodnak a mértékek meghatározása helyett, 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 általában egy dimenzió típusú tábla létrehozása minden szerepkör-lejátszási példányhoz. A további dimenziótáblákat általában számított táblákként hozza létre a DAX használatával. Számított táblák használatával a modell tartalmazhat Dátum táblát, Szállítási dátum táblát és Szállítási dátum táblát, amelyek mindegyike egyetlen és aktív kapcsolatban áll a megfelelő viszonteladói értékesítési tábla oszlopaival.

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 fizetnie, mivel a dátum dimenziótáblájának duplikálása megnöveli a modell tárolási méretét. Mivel a dimenzió típusú táblák általában kevesebb sort tárolnak a tény típusú táblákhoz képest, ez ritkán okoz problémát.

Az egyes szerepkörökhöz tartozó modell dimenzió típusú tábláinak létrehozásakor kövesse az alábbi ajánlott tervezési eljárásokat:

• Győződjön meg arról, hogy az oszlopnevek önleírók. Bár minden dátumtáblában lehet Egy Év 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 az egyes dimenziószerepkör-táblákban, hogy a Szállítási dátum táblában legyen egy Ship Year nevű évoszlop stb.
• Ha releváns, győződjön meg arról, hogy a táblaleírások visszajelzést adnak a jelentéskészítőknek (a Mezők panel elemleírásain keresztül) a szűrőpropagálás konfigurálá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 a Dátumot, amely számos tény típusú tábla szűrésére szolgál. 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: "Viszonteladói értékesítések szűrése rendelési dátum szerint".

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 ügyfelek demográfiai oszlopai (nem, korcsoport stb.).

A levélszemétdimenziók tervezési célja, hogy számos "kicsi" dimenziót egyetlen dimenzióba egyesítsenek, hogy egyszerre csökkentse a modell tárterületének méretét, és kevesebb modelltáblát használva csökkentse a Mezők panel zsúfoltságát.

A levélszemét dimenziótáblák általában az összes dimenzióattribútum-tag Cartesian-terméke, helyettesítő kulcsoszlopmal. A helyettesítő kulcs egyedi hivatkozást biztosít a tábla minden egyes sorára. 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).

Ezt a lekérdezést dimenzió típusú táblaként tölti be a modellbe. A lekérdezést a tény lekérdezéssel is egyesítenie kell, így az indexoszlop betöltődik 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 az esetben nem érdemes egy olyan független táblát létrehozni, amely csak ebből az egy oszlopból áll, mert növeli a modell tárolási méretét, és a Mezők panel zsúfoltságához vezet.

A Power BI-modellben célszerű lehet hozzáadni az értékesítési rendelésszám oszlopot a tény típusú táblához, hogy lehetővé tegye a szűrést vagy a csoportosítást értékesítési rendelések száma alapján. A korábban bevezetett szabály alól kivételt képez, hogy nem szabad táblatípusokat keverni (általában a modelltábláknak dimenzió- vagy ténytípusnak kell lenniük).

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éshez szükséges, akkor a degenerált dimenziótáblák jó kialakítást jelentenek. 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 bejelentkezett 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 a Power BI-modell tervezési megközelítése, amelyet a több-a-többhöz dimenziókapcsolatok definiálását javasoljuk. 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.

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

Kapcsolódó tartalom

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

• Dimenziómodellezés Wikipédia-cikk
• Kapcsolatok létrehozása és kezelése a Power BI Desktopban
• Egy-az-egyhez kapcsolati útmutató
• Több-a-többhöz kapcsolati útmutató
• Kétirányú kapcsolati útmutató
• Aktív és inaktív kapcsolatokra vonatkozó útmutató
• Kérdése van? Kérdezze meg a Power BI-közösség
• Javaslatok? Ötletek hozzáadása a Power BI fejlesztéséhez