esemény
Csatlakozzon hozzánk a FabCon Vegas
márc. 31. 23 - ápr. 2. 23
A Microsoft Fabric, a Power BI, az SQL és az AI közösség által vezetett végső eseménye. 2025. március 31. és április 2. között.
Regisztráljon még maEzt a böngészőt már nem támogatjuk.
Frissítsen a Microsoft Edge-re, hogy kihasználhassa a legújabb funkciókat, a biztonsági frissítéseket és a technikai támogatást.
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).
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.
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.
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.
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.
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.
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:
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.
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:
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.
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.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.
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.
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.
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.
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
.
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 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:
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.
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.
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á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.
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.
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 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.
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.
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:
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.
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:
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.Date
egy 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ó.
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).
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.
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).
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).
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.
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:
esemény
Csatlakozzon hozzánk a FabCon Vegas
márc. 31. 23 - ápr. 2. 23
A Microsoft Fabric, a Power BI, az SQL és az AI közösség által vezetett végső eseménye. 2025. március 31. és április 2. között.
Regisztráljon még maOktatás
Modul
Szemantikai modell tervezése a Power BI-ban - Training
A bonyolult szemantikai modellek Power BI-ban való létrehozásának folyamata egyszerű. Ha az adatok több tranzakciós rendszerből származnak, több tucatnyi táblázat állhat a rendelkezésére a munkához. Egy nagyszerű szemantikai modell létrehozása a szétesés leegyszerűsítéséről szól. A star sémával egyszerűsítheti a szemantikai modelleket, és ebben a modulban megismerheti azok terminológiáját és megvalósítását. Emellett megtudhatja, miért fontos a Power BI-jelentések teljesítményének és használhatóságának szemp
Tanúsítvány
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.