Összetett modellek használata a Power BI Desktopban

Korábban a Power BI Desktopban, amikor DirectQueryt használt egy jelentésben, a jelentéshez más adatkapcsolatok nem voltak engedélyezve, akár DirectQuery, akár importálás. Összetett modellek esetén ez a korlátozás el lesz távolítva. A jelentések zökkenőmentesen tartalmazhatnak több DirectQuery-kapcsolatból származó adatkapcsolatokat, vagy importálhatnak adatkapcsolatokat tetszőleges kombinációban.

A Power BI Desktop összetett modelljeinek képessége három kapcsolódó funkcióból áll:

• Összetett modellek: Lehetővé teszi, hogy a jelentések két vagy több adatkapcsolattal rendelkezzenek különböző forráscsoportokból. Ezek a forráscsoportok lehetnek egy vagy több DirectQuery-kapcsolat és egy importálási kapcsolat, két vagy több DirectQuery-kapcsolat vagy ezek bármilyen kombinációja. Ez a cikk részletesen ismerteti az összetett modelleket.

• Több-a-többhöz kapcsolatok: Összetett modellekkel több-a-többhöz kapcsolatokat hozhat létre a táblák között. Ez a módszer eltávolítja a táblák egyedi értékeire vonatkozó követelményeket. Ez továbbá a korábbi megkerülő megoldásokat is eltávolítja, például új táblák bevezetését kizárólag kapcsolatok létrehozásához. További információ: Több-többhöz kapcsolatok alkalmazása a Power BI Desktopban.

• Tárolási mód: Mostantól megadhatja, hogy mely vizualizációk kérdezik le a háttérbeli adatforrásokat. Ez a funkció segít javítani a teljesítményt és csökkenteni a háttérbetöltést. Korábban még az egyszerű vizualizációk, például a szeletelők is kezdeményezték a lekérdezéseket a háttérforrások felé. További információ: Tárolási mód kezelése a Power BI Desktopban.

Összetett modellek használata

Összetett modellekkel különböző típusú adatforrásokhoz csatlakozhat a Power BI Desktop vagy a Power BI szolgáltatás használatakor. Ezeket az adatkapcsolatokat többféleképpen is létrehozhatja:

• Adatok power BI-ba importálásával, amely az adatok lekérésének leggyakoribb módja.
• Ha közvetlenül csatlakozik az eredeti forrásadattár adataihoz a DirectQuery használatával. A DirectQueryről további információt a Power BI DirectQuery szolgáltatásában talál.

A DirectQuery használata esetén az összetett modellek lehetővé teszik Egy Power BI-modell, például egyetlen .pbix Power BI Desktop-fájl létrehozását, amely az alábbi műveletek egyikét vagy mindkettőt végrehajtja:

• Egy vagy több DirectQuery-forrásból származó adatokat egyesít.
• DirectQuery-forrásokból származó adatokat egyesít és adatokat importál.

Összetett modellek használatával például létrehozhat egy olyan modellt, amely a következő adattípusokat egyesíti:

• Vállalati adattárházból származó értékesítési adatok.
• Értékesítési céladatok egy részlegszintű SQL Server-adatbázisból.
• Számolótáblából importált adatok.

Összetett modellnek nevezzük azt a modellt, amely több DirectQuery-forrásból származó adatokat egyesít, vagy a DirectQueryt az importálási adatokkal kombinálja.

A táblák között ugyanúgy hozhat létre kapcsolatokat, mint mindig, még akkor is, ha ezek a táblák különböző forrásokból származnak. A több-a-többhöz típusú kapcsolatok a tényleges számosságuktól függetlenül több-a-többhöz számossággal jönnek létre. Módosíthatja őket egy-a-többhöz, több-az-egyhez vagy egy-az-egyhez. Bármelyik számosságot is állítja be, a forrásközi kapcsolatok eltérő viselkedéssel rendelkeznek. Nem használhat adatelemzési kifejezéseket (DAX- függvényeket) az one oldalon lévő értékek oldalról many való lekéréséhez. Az is előfordulhat, hogy egy forráson belüli több-a-többhöz kapcsolatok teljesítménybeli hatása van.

Feljegyzés

Az összetett modellek kontextusában az összes importált tábla gyakorlatilag egyetlen forrás, függetlenül a tényleges mögöttes adatforrásoktól.

Példa összetett modellre

Egy összetett modellre példaként tekintsen meg egy jelentést, amely a DirectQuery használatával csatlakozott egy vállalati adattárházhoz az SQL Serveren. Ebben az esetben az adattárház ország, negyedév és kerékpár (termék) szerinti értékesítést tartalmaz, ahogyan az alábbi képen látható:

Ezen a ponton egyszerű vizualizációkat hozhat létre a forrásból származó mezők használatával. Az alábbi képen a productName szerinti összes értékesítés látható egy kiválasztott negyedévben.

De mi a teendő, ha egy Excel-számolótáblában szereplő adatokkal rendelkezik az egyes termékekhez rendelt termékmenedzserről, valamint a marketing prioritásáról? Ha termékmenedzser szerint szeretné megtekinteni az értékesítési összeget, előfordulhat, hogy ezeket a helyi adatokat nem lehet hozzáadni a vállalati adattárházhoz. Vagy akár hónapokig is eltarthat.

Előfordulhat, hogy a DirectQuery használata helyett az adattárházból importálhatja ezeket az értékesítési adatokat. Az értékesítési adatok ezután kombinálhatók a számolótáblából importált adatokkal. Ez a megközelítés azonban ésszerűtlen azoknak az okoknak a miatt, amelyek a DirectQuery használatának első lépéseként vezettek. Ennek okai lehetnek a következők:

• A mögöttes forrásban kikényszerített biztonsági szabályok néhány kombinációja.
• A legújabb adatok megtekintésének szükségessége.
• Az adatok skálázása.

Itt jönnek be az összetett modellek. Az összetett modellek lehetővé teszik az adattárházhoz való csatlakozást a DirectQuery használatával, majd az Adatok lekérése további forrásokhoz való használatát. Ebben a példában először létrehozzuk a DirectQuery-kapcsolatot a vállalati adattárházhoz. Az Adatok lekérése lehetőséget használjuk, az Excelt választjuk, majd a helyi adatokat tartalmazó számolótáblára lépünk. Végül importáljuk a termékneveket, a hozzárendelt Sales Managert és a prioritást tartalmazó számolótáblát.

A Mezők listában két tábla látható: az SQL Server eredeti bike táblája és egy új ProductManagers tábla. Az új táblázat az Excelből importált adatokat tartalmazza.

Hasonlóképpen, a Power BI Desktop Kapcsolat nézetében egy másik, ProductManagers nevű táblázat is látható.

Ezeket a táblákat most a modell többi tábláihoz kell kapcsolnunk. Mint mindig, létrehozunk egy kapcsolatot az SQL Server bike táblája és az importált ProductManagers tábla között. Vagyis a kapcsolat a Bike[ProductName] és a ProductManagers[ProductName] között van. Ahogy korábban már említettem, az összes kapcsolat, amely a forráson keresztül halad át, alapértelmezés szerint több-a-többhöz számosságra terjed ki.

Most, hogy létrehoztuk ezt a kapcsolatot, a Power BI Desktop Kapcsolat nézetében jelenik meg, ahogy vártuk.

Mostantól a Mezők lista bármelyik mezőjével létrehozhatunk vizualizációkat. Ez a módszer zökkenőmentesen egyesíti a több forrásból származó adatokat. Az egyes Termékmenedzserekhez tartozó teljes SalesAmount például az alábbi képen jelenik meg:

Az alábbi példa egy olyan dimenziótábla gyakori esetét jeleníti meg, mint például a Termék vagy az Ügyfél, amely máshonnan importált további adatokkal bővül. Azt is lehetővé teszi, hogy a táblák a DirectQuery használatával csatlakozzanak a különböző forrásokhoz. A példánk folytatásához képzelje el, hogy az országonkénti és időszakonkénti értékesítési célok egy külön részlegadatbázisban vannak tárolva. A szokásos módon az Adatok lekérése használatával csatlakozhat az adatokhoz, ahogy az alábbi képen is látható:

Ahogyan korábban is tettük, létrehozhatunk kapcsolatokat az új tábla és a modell többi táblája között. Ezután létrehozhatunk olyan vizualizációkat, amelyek egyesítik a táblaadatokat. Vizsgáljuk meg újra a Kapcsolatok nézetet, ahol létrehoztuk az új kapcsolatokat:

A következő kép a létrehozott új adatokon és kapcsolatokon alapul. A bal alsó vizualizáció a teljes értékesítési összegetés a célértéket jeleníti meg, a variancia kiszámítása pedig a különbséget mutatja. Az értékesítési összeg és a céladatok két különböző SQL Server-adatbázisból származnak.

A tárolási mód beállítása

Az összetett modell minden táblája rendelkezik tárolási móddal, amely jelzi, hogy a tábla DirectQueryn vagy importáláson alapul-e. A tárolási mód a Tulajdonság panelen tekinthető meg és módosítható. A tárolási mód megjelenítéséhez kattintson a jobb gombbal egy táblára a Mezők listában, majd válassza a Tulajdonságok lehetőséget. Az alábbi képen a SalesTargets tábla tárolási módja látható.

A tárolási mód az egyes táblák elemleírásában is megtekinthető.

Minden Olyan Power BI Desktop-fájl (.pbix-fájl) esetében, amely a DirectQuery néhány tábláját és néhány importálási táblát tartalmaz, az állapotsor egy Vegyes nevű tárolási módot jelenít meg. Ezt a kifejezést az állapotsoron választhatja ki, és az összes táblát egyszerűen importálhatja.

A tárolási módról további információt a Tárolási mód kezelése a Power BI Desktopban című témakörben talál.

Feljegyzés

Vegyes tárolási módot használhat a Power BI Desktopban és a Power BI szolgáltatás.

Számított táblák

Számított táblákat a DirectQueryt használó Power BI Desktopban adhat hozzá egy modellhez. A számított táblát meghatározó adatelemzési kifejezések (DAX) hivatkozhatnak importált vagy DirectQuery táblákra, vagy a kettő kombinációjára.

A számított táblák mindig importálva vannak, és a táblák frissítésekor frissülnek az adataik. Ha egy számított tábla DirectQuery-táblára hivatkozik, a DirectQuery-táblára hivatkozó vizualizációk mindig a legújabb értékeket jelenítik meg az alapul szolgáló forrásban. Másik lehetőségként a számított táblára hivatkozó vizualizációk a számított tábla utolsó frissítésének időpontjában lévő értékeket jelenítik meg.

Fontos

A számított táblák nem támogatottak a funkciót használó Power BI szolgáltatás. További információt a jelen cikk szemantikai modellen alapuló összetett modellekkel foglalkozó szakaszában talál.

Biztonsági következmények

Az összetett modellek biztonsági következményekkel járnak. Az egyik adatforrásba küldött lekérdezések tartalmazhatnak olyan adatértékeket, amelyeket egy másik forrásból kérnek le. A korábbi példában a Product Manager által látható (Értékesítési mennyiség) vizualizáció SQL-lekérdezést küld a Sales relációs adatbázisba. Ez az SQL-lekérdezés tartalmazhatja a termékmenedzserek és a hozzájuk tartozó termékek nevét.

Így a számolótáblában tárolt információk mostantól bekerülnek a relációs adatbázisba küldött lekérdezésekbe. Ha ezek az információk bizalmasak, vegye figyelembe a biztonsági következményeket. Különösen vegye figyelembe a következő szempontokat:

• Az adatbázis minden olyan rendszergazdája, aki megtekintheti a nyomkövetéseket vagy a naplókat, megtekintheti ezeket az információkat, még az eredeti forrás adataihoz való engedély nélkül is. Ebben a példában a rendszergazdának engedélyekre lenne szüksége az Excel-fájlhoz.

• Figyelembe kell venni az egyes forrásokkal kapcsolatos titkosítási beállításokat. El szeretné kerülni, hogy titkosított kapcsolattal adatokat kérjen le egy forrásból, majd véletlenül belevesse azokat egy másik forrásba titkosítatlan kapcsolat által küldött lekérdezésbe.

Annak érdekében, hogy megerősítse, hogy figyelembe vette a biztonsági következményeket, a Power BI Desktop figyelmeztető üzenetet jelenít meg egy összetett modell létrehozásakor.

Ezenkívül ha egy szerző hozzáadja a Table1-et az A modellből egy összetett modellhez (nevezzük referenciaként a C modellnek), akkor a C modellre épülő jelentést megtekintő felhasználó lekérdezheti az A modell olyan tábláit, amelyeket nem véd sorszintű biztonsági RLS.

Hasonló okokból óvatosnak kell lennie, ha nem megbízható forrásból küldött Power BI Desktop-fájlt nyit meg. Ha a fájl összetett modelleket tartalmaz, a rendszer a lekérdezés részeként egy másik adatforrásba küldi el a fájlt megnyitó felhasználó hitelesítő adataival az egyik forrásból lekért információkat. Az információkat a Power BI Desktop-fájl rosszindulatú szerzője tekintheti meg. Amikor először megnyit egy több forrást tartalmazó Power BI Desktop-fájlt, a Power BI Desktop figyelmeztetést jelenít meg. A figyelmeztetés hasonló ahhoz, amely natív SQL-lekérdezéseket tartalmazó fájl megnyitásakor jelenik meg.

A teljesítményre gyakorolt hatások

A DirectQuery használatakor mindig a teljesítményt kell figyelembe vennie, elsősorban annak biztosítása érdekében, hogy a háttérforrás elegendő erőforrással rendelkezzen ahhoz, hogy jó élményt nyújtson a felhasználóknak. A jó élmény azt jelenti, hogy a vizualizációk öt másodperc alatt frissülnek. További teljesítménytanácsadásért lásd a DirectQueryt a Power BI-ban.

Az összetett modellek használata további teljesítménybeli szempontokat is figyelembe vehet. Egyetlen vizualizáció több forrásba is küldhet lekérdezéseket, amelyek gyakran egy lekérdezés eredményeit adják át egy második forrásnak. Ez a helyzet a következő végrehajtási formákat eredményezheti:

• Olyan forrás lekérdezés, amely számos literális értéket tartalmaz: Például egy vizualizációnak, amely a kiválasztott termékmenedzserek összes értékesítési összegét kéri le, először meg kell keresnie, hogy mely termékeket kezelték ezek a termékmenedzserek. Ennek a sorozatnak még azelőtt kell történnie, hogy a vizualizáció elküld egy SQL-lekérdezést, amely egy záradékban tartalmazza az összes termékazonosítót WHERE .

• Olyan forrás lekérdezés, amely alacsonyabb részletességi szinten kérdez le, és az adatokat később helyileg összesítik: Mivel a Product Manager szűrőfeltételeinek megfelelő termékek száma egyre nő, nem hatékony vagy nem megvalósítható az összes termék belefoglalása egy WHERE záradékba. Ehelyett lekérdezheti a relációs forrást a Termékek alsó szintjén, majd helyileg összesítheti az eredményeket. Ha a termékek számossága meghaladja az 1 milliós korlátot, a lekérdezés meghiúsul.

• Több forrás lekérdezés, egy csoportonként érték szerint: Ha az összesítés a DistinctCount függvényt használja, és egy másik forrásból származó oszlop szerint van csoportosítva, és ha a külső forrás nem támogatja a csoportosítást meghatározó számos literális érték hatékony átadását, akkor csoportonként egy SQL-lekérdezést kell elküldeni érték szerint.

  Egy olyan vizualizációnak, amely a CustomerAccountNumber különböző darabszámát kéri az SQL Server táblából a számolótáblából importált termékmenedzserek számára, meg kell adnia az SQL Servernek küldött lekérdezés Termékmenedzser táblájának adatait. Más forrásoknál például a Redshift nem valósítható meg. Ehelyett a Sales Managerenként egy SQL-lekérdezést küldenek egy gyakorlati korlátig, amelynél a lekérdezés sikertelen lesz.

Az ilyen esetek mindegyike saját hatással van a teljesítményre, és a pontos részletek az egyes adatforrások esetében eltérőek. Bár a két forrást összekapcsoló kapcsolatban használt oszlopok számossága továbbra is alacsony, néhány ezer, a teljesítményt nem szabad befolyásolni. Ahogy ez a számosság növekszik, nagyobb figyelmet kell fordítania az eredményül kapott teljesítményre gyakorolt hatásra.

Emellett a több-a-többhöz kapcsolatok használata azt is jelenti, hogy a részletes értékek helyi összesítése helyett külön lekérdezéseket kell küldeni a mögöttes forrásnak minden egyes összeg vagy részösszeg szintjén. Egy egyszerű, összegeket tartalmazó táblavizualizáció két forrás lekérdezést küld egy helyett.

Forráscsoportok

A forráscsoport egy DirectQuery-forrásból származó elemek, például táblák és kapcsolatok gyűjteménye, vagy az adatmodellben részt vevő összes importálási forrás. Egy összetett modell egy vagy több forráscsoportból áll. Tekintse az alábbi példákat:

• Egy Olyan összetett modell, amely egy Sales nevű Power BI szemantikai modellhez csatlakozik, és egy Értékesítési YTD-mérték hozzáadásával bővíti a szemantikai modellt, amely nem érhető el az eredeti szemantikai modellben. Ez a modell egy forráscsoportból áll.
• Összetett modell, amely adatokat egyesít egy Táblák nevű Excel-munkalapról és egy Régiók nevű CSV-fájlból származó táblázat importálásával, valamint DirectQuery-kapcsolat létesítésével egy Sales nevű Power BI szemantikai modellel. Ebben az esetben két forráscsoport van, ahogyan az alábbi képen látható:
  • Az első forráscsoport tartalmazza a Targets Excel munkalap és a Regions CSV fájl tábláját.
  • A második forráscsoport a Sales Power BI szemantikai modell elemeit tartalmazza.

Ha egy másik DirectQuery-kapcsolatot adott hozzá egy másik forráshoz, például egy DirectQuery-kapcsolatot egy Inventory nevű SQL Server-adatbázishoz, a forrás elemei egy másik forráscsoportként lesznek hozzáadva:

Feljegyzés

Ha adatokat importál egy másik forrásból, az nem ad hozzá másik forráscsoportot, mert az összes importált forrás minden eleme egy forráscsoportban található.

Forráscsoportok és kapcsolatok

Az összetett modellben kétféle kapcsolat létezik:

• Forráscsoporton belüli kapcsolatok. Ezek a kapcsolatok egy forráscsoporton belüli elemeket kapcsolnak össze. Ezek a kapcsolatok mindig normál kapcsolatok, kivéve, ha több-a-többhöz, ami esetben korlátozottak.
• Forráscsoportközi kapcsolatok. Ezek a kapcsolatok egy forráscsoportban kezdődnek, és egy másik forráscsoportban végződnek. Ezek a kapcsolatok mindig korlátozott kapcsolatok.

További információ a rendszeres és korlátozott kapcsolatok és azok hatásai közötti különbségről.

Az alábbi képen például három forráscsoportközi kapcsolatot adtunk hozzá, amelyek a különböző forráscsoportok tábláit együttesen tartalmazzák:

Helyi és távoli

A DirectQuery-forráscsoportba tartozó bármely elem távolinak minősül, kivéve, ha az elemet helyileg a DirectQuery-forrás kiterjesztése vagy bővítése részeként határozták meg, és nem része a távoli forrásnak, például mértéknek vagy számított táblának. A DirectQuery-forráscsoport tábláján alapuló számított tábla az "Importálás" forráscsoporthoz tartozik, és helyinek számít. Az "Importálás" forráscsoportban található elemek helyinek minősülnek. Ha például a következő mértéket definiálja egy olyan összetett modellben, amely DirectQuery-kapcsolatot használ az Inventory-forráshoz, a mérték helyinek minősül:

[Average Inventory Count] = Average(Inventory[Inventory Count])

Számítási csoportok, lekérdezések és mértékek kiértékelése

A számítási csoportok lehetővé teszik a redundáns mértékek számának csökkentését és a közös mértékkifejezések csoportosítását. A tipikus használati esetek olyan időintelligencia-számítások, amelyekben a tényleges adatokról hónapról hónapra, negyedévről napra vagy évről évre történő számításra szeretne váltani. Összetett modellek használatakor fontos tisztában lenni a számítási csoportok közötti interakcióval, és hogy a mértékek csak egyetlen távoli forráscsoport elemeire vonatkoznak-e. Ha egy mérték csak egyetlen távoli forráscsoport elemeire hivatkozik, és a távoli modell egy olyan számítási csoportot határoz meg, amely hatással van a mértékre, akkor is alkalmazza a számítási csoportot, még akkor is, ha a mértéket a távoli modellben vagy a helyi modellben definiálták. Ha azonban egy mérték nem egyetlen távoli forráscsoport elemeire hivatkozik, hanem egy távoli forráscsoport azon elemeire hivatkozik, amelyeken távoli számítási csoport van alkalmazva, a mérték eredményeit továbbra is befolyásolhatja a távoli számítási csoport. Vegyük a következő példát:

• A Reseller Sales a távoli modellben definiált mérték.
• A távoli modell egy olyan számítási csoportot tartalmaz, amely módosítja a viszonteladói értékesítés eredményét
• Az internetes értékesítés a helyi modellben meghatározott mérték.
• A Total Sales a helyi modellben definiált mérték, amelynek definíciója a következő:

[Total Sales] = [Internet Sales] + [Reseller Sales]

Ebben a forgatókönyvben az Internet Sales mértéket nem befolyásolja a távoli modellben definiált számítási csoport, mert nem részei ugyanannak a modellnek. A számítási csoport azonban módosíthatja a Reseller Sales mérték eredményét, mivel ugyanabban a modellben vannak. Ez a tény azt jelenti, hogy a Total Sales mérték által visszaadott eredményeket gondosan kell értékelni. Tegyük fel, hogy a távoli modell számítási csoportját használjuk az éves eredmények visszaadásához. A Reseller Sales által visszaadott eredmény mostantól egy évről napra érvényes érték, míg az internetes értékesítések által visszaadott eredmény továbbra is tényleges. A Teljes értékesítés eredménye valószínűleg váratlan, mivel egy tényleges értéket ad hozzá egy évről napra.

Összetett modellek Power BI szemantikai modelleken és Analysis Servicesen

Ha összetett modelleket használ a Power BI szemantikai modellekkel és az Analysis Services szolgáltatással, directQuery-kapcsolattal hozhat létre összetett modellt a Power BI szemantikai modellekhez, az Azure Analysis Serviceshez (AAS) és az SQL Server 2022 Analysis Serviceshez való csatlakozáshoz. Összetett modell használatával egyesítheti az ezekben a forrásokban lévő adatokat más DirectQuery- és importált adatokkal. Különösen hasznosnak találják ezt a funkciót azok a jelentéskészítők, akik a vállalati szemantikai modelljükből származó adatokat más adataikkal, például egy Excel-számolótáblával szeretnék kombinálni, vagy személyre szeretnék szabni vagy bővíteni szeretnék a vállalati szemantikai modell metaadatait.

Összetett modellek kezelése Power BI szemantikai modelleken

Az összetett modellek Power BI szemantikai modelleken való létrehozásának és felhasználásának engedélyezéséhez a bérlőnek engedélyeznie kell a következő kapcsolókat:

• XMLA-végpontok és elemzés engedélyezése az Excelben helyszíni szemantikai modellekkel. Ha ez a kapcsoló le van tiltva, a Power BI szemantikai modellhez nem hozható létre DirectQuery-kapcsolat.
• A felhasználók élő kapcsolat használatával használhatják a Power BI szemantikai modelljeit az Excelben. Ha ez a kapcsoló le van tiltva, a felhasználók nem tudnak élő kapcsolatot létesíteni a Power BI szemantikai modellekkel, így a Modell módosítása gomb nem érhető el.
• DirectQuery-kapcsolat engedélyezése Power BI szemantikai modellekkel. A kapcsolóról és annak letiltásának hatásáról az alábbi bekezdésekben olvashat bővebben.

Emellett a Prémium szintű kapacitások és a Felhasználónkénti Premium esetében az "XMLA-végpont" beállítást engedélyezni kell, és "Csak olvasható" vagy "Olvasás/Írás" értékre kell állítani.

A bérlői rendszergazdák a Felügyeleti portálon engedélyezhetik vagy letilthatják a Power BI szemantikai modellekkel létesített DirectQuery-kapcsolatokat. Bár ez alapértelmezés szerint engedélyezve van, a letiltás hatékonyan megakadályozza, hogy a felhasználók új összetett modelleket tegyenek közzé a Power BI szemantikai modelljeiben a szolgáltatásban.

A Power BI szemantikai modellen összetett modellt használó meglévő jelentések továbbra is működni fognak, és a felhasználók továbbra is létrehozhatják az összetett modellt a Desktop használatával, de nem tehetnek közzé a szolgáltatásban. Ha directQuery-kapcsolatot hoz létre a Power BI szemantikai modellhez a Modell módosítása lehetőség kiválasztásával, a következő figyelmeztető üzenet jelenik meg:

Így továbbra is megismerheti a szemantikai modellt a helyi Power BI Desktop-környezetben, és létrehozhatja az összetett modellt. A jelentést azonban nem fogja tudni közzétenni a szolgáltatásban. A jelentés és a modell közzétételekor a következő hibaüzenet jelenik meg, és a közzététel le lesz tiltva:

Vegye figyelembe, hogy a Power BI szemantikai modellekkel való élő kapcsolatokat nem befolyásolja a kapcsoló, és az Analysis Services élő vagy DirectQuery-kapcsolatai sem. Ezek továbbra is működni fognak, függetlenül attól, hogy a kapcsoló ki van-e kapcsolva. Emellett minden olyan közzétett jelentés, amely összetett modellt használ egy Power BI szemantikai modellen, akkor is működni fog, ha a kapcsolót a közzétételük után kikapcsolták.

Összetett modell létrehozása szemantikai modellre vagy modellre

Ha összetett modellt készít egy Power BI szemantikai modellre vagy Analysis Services-modellre, a jelentésnek helyi modellel kell rendelkeznie. Az élő kapcsolatból kiindulva hozzáadhat vagy frissíthet egy helyi modellre, vagy DirectQuery-kapcsolattal vagy importált adatokkal kezdhet, amely automatikusan létrehoz egy helyi modellt a jelentésben.

A modellben használt kapcsolatok megtekintéséhez ellenőrizze a Power BI Desktop jobb alsó sarkában található állapotsort. Ha csak egy Analysis Services-forráshoz csatlakozik, az alábbihoz hasonló üzenet jelenik meg:

Ha Power BI szemantikai modellhez csatlakozik, megjelenik egy üzenet, amely közli, hogy melyik Power BI szemantikai modellhez csatlakozik:

Ha testre szeretné szabni az élő kapcsolattal rendelkező szemantikai modell mezőinek metaadatait, válassza a Modell módosításainak végrehajtása lehetőséget az állapotsoron. Másik lehetőségként választhatja a modell módosításainak gombot a menüszalagon, ahogyan az az alábbi képen látható. A Jelentés nézetben a Modellezés lapon a modell módosításainak végrehajtása gomb jelenik meg. Modell nézetben a gomb a Kezdőlap lapon található.

A gomb kiválasztásával megjelenik egy párbeszédpanel, amely megerősíti a helyi modell hozzáadását. Válassza a Helyi modell hozzáadása lehetőséget az új oszlopok létrehozásához vagy a metaadatok módosításához a Power BI szemantikai modelljeiből vagy az Analysis Servicesből származó mezők esetében. Az alábbi képen a megjelenő párbeszédpanel látható.

Ha élőben csatlakozik egy Analysis Services-forráshoz, nincs helyi modell. Ha a DirectQueryt élő csatlakoztatott forrásokhoz, például a Power BI szemantikai modellekhez és az Analysis Serviceshez szeretné használni, hozzá kell adnia egy helyi modellt a jelentéshez. Ha helyi modellel rendelkező jelentést tesz közzé a Power BI szolgáltatás, a rendszer közzéteszi a helyi modell szemantikai modelljét.

Láncolás

A szemantikai modellek és azok a szemantikai modellek, amelyeken alapulnak, láncot alkotnak. Ez a láncolásnak nevezett folyamat lehetővé teszi, hogy más Power BI szemantikai modelleken alapuló jelentést és szemantikai modellt tegyen közzé, amely korábban nem volt lehetséges.

Tegyük fel például, hogy a munkatársa közzétesz egy Értékesítés és költségvetés nevű Power BI szemantikai modellt, amely egy Sales nevű Analysis Services-modellen alapul, és kombinálja azt egy Költségvetés nevű Excel-munkalaptal.

Amikor a munkatársa által közzétett Sales and Budget Power BI szemantikai modellen alapuló, Sales and Budget Europe nevű új jelentést (és szemantikai modellt) tesz közzé, és további módosításokat vagy bővítményeket hajt végre, hatékonyan hozzáad egy jelentést és szemantikai modellt egy három hosszúságú lánchoz, amely a Sales Analysis Services modellel kezdődött. és a Sales and Budget Europe Power BI szemantikai modellel végződik. Az alábbi képen ez a láncolási folyamat látható.

Az előző képen szereplő lánc hossza három, ami a maximális hossz. A három lánchosszon túlra való kiterjesztés nem támogatott, és hibákat eredményez.

Engedélyek és licencelés

Az összetett modellt használó jelentésekhez hozzáférő felhasználóknak megfelelő engedélyekkel kell rendelkezniük a láncban lévő összes szemantikai modellhez és modellhez.

Az összetett modell tulajdonosának buildelési engedélyre van szüksége a forrásként használt szemantikai modellekhez, hogy más felhasználók is hozzáférhessenek ezekhez a modellekhez a tulajdonos nevében. Ennek eredményeképpen az összetett modell kapcsolatának a Power BI Desktopban való létrehozása vagy a jelentés Power BI-ban való létrehozása buildelési engedélyeket igényel a forrásként használt szemantikai modellekhez.

Azok a felhasználók, akik az összetett modell használatával tekintik meg a jelentéseket, általában olvasási engedélyekre lesz szükségük az összetett modellre és a forrásként használt szemantikai modellekre. Buildelési engedélyekre lehet szükség, ha a jelentések Pro-munkaterületen találhatók. Ezeket a bérlői kapcsolókat engedélyezni kell a felhasználó számára.

A szükséges engedélyek az alábbi példával szemléltethetők:

• A összetett modell (az A tulajdonos tulajdonában)

  • Adatforrás A1: Szemantikai B modell.
    Az A tulajdonosnak buildelési engedéllyel kell rendelkeznie a B szemantikai modellen ahhoz, hogy a felhasználók az A összetett modell használatával tekintsék meg a jelentést.

• Összetett C modell (tulajdonos: C)

  • Adatforrás C1: Szemantikai D modell
    A C tulajdonosnak buildelési engedéllyel kell rendelkeznie a D szemantikai modellen ahhoz, hogy a felhasználók a C összetett modell használatával tekintsék meg a jelentést.
  • C2 adatforrás: A összetett modell
    A C tulajdonosnak buildelési engedéllyel kell rendelkeznie az A összetett modellhez és olvasási engedéllyel a B szemantikai modellhez.

Az összetett A modellt használó jelentéseket megtekintő felhasználóknak olvasási engedélyekkel kell rendelkezniük mind az összetett A modellhez, mind a B szemantikai modellhez, míg a C összetett modellt használó jelentéseket megtekintő felhasználóknak olvasási engedélyekkel kell rendelkezniük a C összetett modellre, a szemantikai modellre, a D szemantikai modellre, az A összetett modellre és a B szemantikai modellre.

Feljegyzés

Ebben a blogbejegyzésben fontos információkat talál az összetett modellekhez szükséges engedélyekről a Power BI szemantikai modelljeihez és az Analysis Services-modellekhez.

Ha a lánc bármely adathalmaza felhasználónkénti prémium szintű munkaterületen található, az azt elérő felhasználónak felhasználónkénti Premium licencre van szüksége. Ha a lánc bármely adathalmaza Pro-munkaterületen található, az azt elérő felhasználónak Pro-licencre van szüksége. Ha a lánc összes adathalmaza Prémium szintű kapacitáson vagy Fabric F64 vagy nagyobb kapacitáson található, a felhasználó ingyenes licenccel érheti el.

Biztonsági figyelmeztetés

A Power BI szemantikai modelljeihez készült DirectQuery és az Analysis Services funkció használatával megjelenik egy biztonsági figyelmeztetési párbeszédpanel, amely az alábbi képen látható.

Az adatok leküldhetők az egyik adatforrásból a másikba, ami ugyanaz a biztonsági figyelmeztetés, amely a DirectQuery és az importálási források adatmodellben való kombinálására vonatkozik. Ha többet szeretne megtudni erről a viselkedésről, tekintse meg az összetett modellek használatát a Power BI Desktopban.

Támogatott esetek

Összetett modelleket power BI szemantikai modellekből vagy Analysis Services-modellekből származó adatokkal hozhat létre a következő forgatókönyvek kiszolgálásához:

• Csatlakozás különböző forrásokból származó adatokhoz: Importálás (például fájlok), Power BI szemantikai modellek, Analysis Services-modellek
• Kapcsolatok létrehozása különböző adatforrások között
• Különböző adatforrásokból származó mezőket használó mértékek írása
• Új oszlopok létrehozása táblákhoz Power BI szemantikai modellekből vagy Analysis Services-modellekből
• Különböző adatforrásokból származó oszlopokat használó vizualizációk létrehozása
• A mezőlistával eltávolíthat egy táblát a modellből, hogy a modellek a lehető tömörek és soványak maradjanak (ha egy perspektívához csatlakozik, nem távolíthat el táblákat a modellből)
• Megadhatja, hogy mely táblákat kell betöltenie ahelyett, hogy az összes táblát be kellene töltenie, ha csak a táblák egy adott részhalmazát szeretné betölteni. Lásd: Táblák egy részhalmazának betöltése a dokumentum későbbi részében.
• Megadhatja, hogy hozzáadjon-e olyan táblákat, amelyeket később hozzáad a szemantikai modellhez a modellben való kapcsolat létrehozása után.

Szemantikai modellen alapuló összetett modell használata

A Power BI szemantikai modelljeihez és az Analysis Serviceshez készült DirectQuery használatakor vegye figyelembe a következőket:

• Ha frissíti az adatforrásokat, és ütköző mező- vagy táblanevekkel kapcsolatos hibák merülnek fel, a Power BI megoldja a hibákat.

• Nem szerkeszthet, törölhet és nem hozhat létre új kapcsolatokat ugyanabban a Power BI szemantikai modellben vagy Analysis Services-forrásban. Ha szerkesztési hozzáféréssel rendelkezik ezekhez a forrásokhoz, a módosításokat közvetlenül az adatforrásban végezheti el.

• A Power BI szemantikai modellből vagy Analysis Services-forrásból betöltött oszlopok adattípusai nem módosíthatók. Ha módosítania kell az adattípust, módosítsa a forrásban, vagy használjon számított oszlopot.

• Ha egy másik szemantikai modellen alapuló összetett modellen szeretne jelentéseket készíteni a Power BI szolgáltatás, minden hitelesítő adatot be kell állítani.

• Az SQL Server 2022- és újabb Analysis Services-kiszolgálóra vagy az IAAS-ra való Csatlakozás helyszíni adatátjárót (Standard mód) igényel.

• A távoli Power BI szemantikai modellekkel való minden kapcsolat egyszeri bejelentkezéssel történik. A szolgáltatásnévvel való hitelesítés jelenleg nem támogatott.

• Az RLS-szabályok azon a forráson lesznek alkalmazva, amelyen definiálva vannak, de a modell más szemantikai modelljeire nem lesznek alkalmazva. A jelentésben definiált RLS nem lesz alkalmazva a távoli forrásokra, és a távoli forrásokra beállított RLS nem lesz alkalmazva más adatforrásokra. Nem definiálhat RLS-t távoli forrásból betöltött táblán, és a helyi táblákon definiált RLS nem szűri a távoli forrásból betöltött táblákat.

• A KPI-k, a sorszintű biztonság és a fordítások nem lesznek importálva a forrásból.

• Előfordulhat, hogy váratlan viselkedés jelenik meg egy dátumhierarchia használatakor. A probléma megoldásához használjon inkább dátumoszlopot. Miután hozzáadta a dátumhierarchiát egy vizualizációhoz, a mezőnév lefelé mutató nyílra kattintva válthat dátumoszlopra, majd a Dátumhierarchia használata helyett a mező nevére kattintva válthat:

  

  A dátumoszlopok és a dátumhierarchiák használatáról további információt a Power BI Desktop automatikus dátum- vagy időalkalmazásában talál.

• A modellek láncának maximális hossza három. A három lánchosszon túlra való kiterjesztés nem támogatott, és hibákat eredményez.

• A láncok létrehozásának vagy kiterjesztésének megakadályozása érdekében a modellen beállítható a láncok visszatartó jelzője. További információ: DirectQuery-kapcsolatok kezelése közzétett szemantikai modellel .

• A Power BI szemantikai modellhez vagy Analysis Services-modellhez való kapcsolat nem jelenik meg a Power Queryben.

A DirectQuery power BI szemantikai modellekhez és Analysis Serviceshez való használatakor a következő korlátozások érvényesek:

• Az adatbázis- és kiszolgálónevek paraméterei jelenleg le vannak tiltva.
• Az RLS távoli forrásból származó táblákon való definiálása nem támogatott.
• Az alábbi források használata DirectQuery-forrásként nem támogatott:
  • AZ SQL Server Analysis Services (SSAS) táblázatos modelljei a 2022-es verzió előtt
  • Többdimenziós SSAS-modellek
  • SAP HANA
  • SAP Business Warehouse
  • Valós idejű szemantikai modellek
  • Szemantikai mintamodellek
  • Excel Online frissítés
  • Excel- vagy CSV-fájlokból importált adatok a szolgáltatásban
  • Használati metrikák
  • A "Saját munkaterület" fájlban tárolt szemantikai modellek
• A Power BI Embedded olyan szemantikai modellekkel való használata, amelyek DirectQuery-kapcsolatot tartalmaznak egy Analysis Services-modellhez, jelenleg nem támogatottak.
• A jelentések webes közzététele a webes közzététel funkcióval nem támogatott.
• A távoli források számítási csoportjai nem támogatottak, nem definiált lekérdezési eredményekkel.
• A szolgáltatás nem támogatja a számított táblákat ezzel a funkcióval. Ha egy számított táblával vagy egy DirectQuery-adatforrásra hivatkozó számított oszlopmal kísérel meg frissítést végezni egy szemantikai modellen, az "Egyszeri bejelentkezés (SSO) hitelesítő adatok nem jelennek meg" hibaüzenet jelenik meg.
• Ha a DirectQuery-kapcsolat beállítása után átnevez egy munkaterületet, frissítenie kell az adatforrást a Power BI Desktopban, hogy a jelentés továbbra is működjön.
• Az automatikus oldalfrissítés (APR) csak bizonyos esetekben támogatott, az adatforrás típusától függően. További információt az Automatikus oldalfrissítés a Power BI-ban című cikkben talál.
• A DirectQueryt más szemantikai modellekre használó szemantikai modellek átvétele jelenleg nem támogatott.
• Mint minden DirectQuery-adatforrás esetében, az Analysis Services-modellben vagy a Power BI szemantikai modellben definiált hierarchiák sem jelennek meg, amikor DirectQuery módban csatlakozik a modellhez vagy a szemantikai modellhez az Excel használatával.

A Power BI szemantikai modelljeihez és az Analysis Serviceshez készült DirectQuery használatakor néhány további szempontot is figyelembe kell venni :

• Használjon alacsony számosságú oszlopokat a forráscsoportok közötti kapcsolatokban: Ha két különböző forráscsoport között hoz létre kapcsolatot, a kapcsolatban részt vevő oszlopoknak (más néven illesztőoszlopoknak) alacsony számosságúnak kell lennie, ideális esetben 50 000 vagy annál kevesebb. Ez a szempont a nem sztring típusú kulcsoszlopokra vonatkozik; sztringkulcsoszlopok esetén lásd az alábbi szempontokat.
• Kerülje a nagy sztringek kulcsoszlopainak használatát a forráscsoportok közötti kapcsolatokban: Forráscsoportközi kapcsolatok létrehozásakor kerülje a nagy sztringoszlopok használatát kapcsolatoszlopként, különösen a nagyobb számosságú oszlopok esetében. Ha sztringoszlopokat kell használnia kapcsolatoszlopként, akkor a sztringoszlop (A) átlagos hosszával szorozva számítsa ki a szűrő várható sztringhosszát (C). Győződjön meg arról, hogy a várt sztringhossz 250 000 alatt van, hogy az A ∗ C < 250 000 legyen.

További szempontokért és útmutatásért tekintse meg az összetett modell útmutatását.

Bérlői szempontok

A Power BI szemantikai modellhez vagy az Analysis Serviceshez DirectQuery-kapcsolattal rendelkező modelleket ugyanabban a bérlőben kell közzétenni, ami különösen fontos a Power BI szemantikai modell vagy egy B2B-vendégidentitásokat használó Analysis Services-modell elérésekor, ahogyan az az alábbi ábrán látható. Tekintse meg azokat a vendégfelhasználókat, akik tartalmat szerkeszthetnek és kezelhetnek a közzétételhez szükséges bérlői URL-cím megkereséséhez.

Fontolja meg a következő diagramot. A diagram számozott lépéseit az alábbi bekezdések ismertetik.

A diagramon Ash a Contoso-val dolgozik, és hozzáfér a Fabrikam által biztosított adatokhoz. A Power BI Desktop használatával Ash DirectQuery-kapcsolatot hoz létre a Fabrikam bérlőjében üzemeltetett Analysis Services-modellhez.

A hitelesítéshez Ash egy B2B vendégfelhasználói identitást használ (a diagram 1. lépése).

Ha a jelentést közzéteszik a Contoso Power BI szolgáltatás (2. lépés), a Contoso-bérlőben közzétett szemantikai modell nem tudja sikeresen hitelesíteni a Fabrikam Analysis Services-modelljét (3. lépés). Emiatt a jelentés nem fog működni.

Ebben a forgatókönyvben, mivel a használt Analysis Services-modell a Fabrikam bérlőjében található, a jelentést a Fabrikam bérlőjében is közzé kell tenni. Miután sikeresen megjelent a Fabrikam bérlőjében (4. lépés), a szemantikai modell sikeresen hozzáférhet az Analysis Services-modellhez (5. lépés), és a jelentés megfelelően fog működni.

Objektumszintű biztonság használata

Ha egy összetett modell adatokat kap egy Power BI szemantikai modellből vagy az Analysis Servicesből DirectQuery használatával, és a forrásmodellt objektumszintű biztonság védi, az összetett modell felhasználói váratlan eredményeket tapasztalhatnak. Az alábbi szakasz bemutatja, hogyan fordulhatnak elő ezek az eredmények.

Az objektumszintű biztonság (OLS) lehetővé teszi, hogy a modellkészítők elrejtsék a modellsémát alkotó objektumokat (például táblákat, oszlopokat, metaadatokat stb.) a modellfelhasználóktól (például jelentéskészítőtől vagy összetett modellkészítőtől). Az OLS objektumhoz való konfigurálásakor a modell szerzője létrehoz egy szerepkört, majd eltávolítja az objektumhoz való hozzáférést az adott szerepkörhöz rendelt felhasználók számára. A felhasználók szempontjából a rejtett objektum egyszerűen nem létezik.

Az OLS a forrásmodellhez van definiálva és alkalmazva. Nem definiálható a forrásmodellre épülő összetett modellhez.

Ha egy összetett modell egy OLS által védett Power BI szemantikai modellre vagy Analysis Services-modellre épül DirectQuery-kapcsolaton keresztül, a forrásmodell modellséma át lesz másolva az összetett modellbe. A másolt adatok attól függenek, hogy az összetett modell szerzője mit láthat a forrásmodellben az ott érvényes OLS-szabályok szerint. Maga az adatok nem lesznek átmásolva az összetett modellbe – ehelyett mindig a DirectQueryn keresztül kérik le őket a forrásmodellből, ha szükséges. Más szóval az adatlekérés mindig visszakerül a forrásmodellbe, ahol OLS-szabályok érvényesek.

Mivel az összetett modellt nem OLS-szabályok védik, az összetett modell felhasználói által látott objektumok azok, amelyeket az összetett modell szerzője láthat a forrásmodellben, nem pedig az, amelyhez maguk is hozzáférhetnek. Ez a következő helyzeteket eredményezheti:

• Az összetett modellt megtekintő személyek láthatják az OLS által a forrásmodellben elrejtett objektumokat.
• Ezzel szemben előfordulhat, hogy nem látnak olyan objektumot az összetett modellben, amelyet a forrásmodellben láthatnak, mert az objektumot elrejtették az összetett modell készítője elől a forrásmodellhez való hozzáférést szabályozó OLS-szabályok.

Fontos szempont, hogy az első felsorolásban leírt eset ellenére az összetett modell felhasználói soha nem fogják látni azokat a tényleges adatokat, amelyeket nem kellene látniuk, mivel az adatok valójában nem az összetett modellben találhatók. Ehelyett a DirectQuery miatt szükség szerint lekéri a forrás szemantikai modellből, ahol az OLS blokkolja a jogosulatlan hozzáférést.

Ezt a hátteret szem előtt tartva vegye figyelembe a következő forgatókönyvet:

1. Rendszergazda_user közzétett egy vállalati szemantikai modellt Egy Power BI szemantikai modell vagy egy Ügyfél táblával és Egy Terület táblával rendelkező Analysis Services-modell használatával. Rendszergazda_user közzéteszi a szemantikai modellt a Power BI szolgáltatás, és beállítja a következő hatással rendelkező OLS-szabályokat:

   • A pénzügyi felhasználók nem látják az Ügyfél táblát
   • A marketingfelhasználók nem láthatják a Territory táblát

2. Finance_user közzétesz egy "Pénzügyi szemantikai modell" nevű szemantikai modellt, valamint egy "Pénzügyi jelentés" nevű jelentést, amely DirectQueryn keresztül kapcsolódik az 1. lépésben közzétett vállalati szemantikai modellhez. A Pénzügyi jelentés tartalmaz egy vizualizációt, amely a Territory tábla egyik oszlopát használja.

3. Marketing_user megnyitja a Pénzügyi jelentést. Megjelenik a Territory táblát használó vizualizáció, de hibát ad vissza, mert a jelentés megnyitásakor a DirectQuery a Marketing_user hitelesítő adataival próbálja lekérni az adatokat a forrásmodellből, aki a vállalati szemantikai modell olS-szabályainak megfelelően letiltja a Territory tábla megtekintését.

4. Marketing_user létrehoz egy "Marketingjelentés" nevű új jelentést, amely a pénzügyi szemantikai modellt használja forrásként. A mezőlista azokat a táblákat és oszlopokat jeleníti meg, amelyekhez Finance_user hozzáféréssel rendelkezik. Ezért a Terület tábla megjelenik a mezők listájában, de az Ügyfél tábla nem. Amikor azonban a Marketing_user megpróbál létrehozni egy olyan vizualizációt, amely a Territory táblából származó oszlopot használja, a rendszer hibát ad vissza, mert ezen a ponton a DirectQuery megpróbál adatokat lekérni a forrásmodellből Marketing_user hitelesítő adataival, és az OLS-szabályok ismét beindulnak, és blokkolják a hozzáférést. Ugyanez történik, amikor Marketing_user létrehoz egy új szemantikai modellt és jelentést, amely DirectQuery-kapcsolattal csatlakozik a Pénzügyi szemantikai modellhez – a Mezők listában a Territory táblát látják, mivel Finance_user ezt láthatják, de amikor megpróbálnak létrehozni egy olyan vizualizációt, amely ezt a táblát használja, a vállalati szemantikai modell OLS-szabályai blokkolják őket.

5. Most tegyük fel, hogy Rendszergazda_user frissíti a vállalati szemantikai modell OLS-szabályait, hogy megakadályozza a Finance számára a Territory táblát.

6. A frissített OLS-szabályok csak akkor jelennek meg a Pénzügyi szemantikai modellben, ha frissül. Így amikor a Finance_user frissíti a Pénzügyi szemantikai modellt, a Territory tábla már nem jelenik meg a mezők listájában, és a Terület tábla oszlopát használó Pénzügyi jelentés vizualizációja hibát ad vissza a Finance_user, mert most már nem férhetnek hozzá a Terület táblához.

Összegezve:

• Az összetett modell felhasználói megtekinthetik azoknak az OLS-szabályoknak az eredményeit, amelyek a modell létrehozásakor az összetett modell szerzője számára alkalmazhatók voltak. Így ha az összetett modell alapján hoz létre új jelentést, a mezőlista megjeleníti azokat a táblákat, amelyekhez az összetett modell szerzője hozzáfért a modell létrehozásakor, függetlenül attól, hogy az aktuális felhasználó milyen hozzáféréssel rendelkezik a forrásmodellben.
• Az OLS-szabályok nem definiálhatók az összetett modellen.
• Az összetett modellek felhasználói soha nem fogják látni azokat a tényleges adatokat, amelyek nem láthatók, mert a forrásmodell megfelelő OLS-szabályai blokkolni fogják őket, amikor a DirectQuery megpróbálja lekérni az adatokat a hitelesítő adataikkal.
• Ha a forrásmodell frissíti az OLS-szabályait, ezek a módosítások csak az összetett modellt érintik a frissítéskor.

Táblák egy részhalmazának betöltése Power BI szemantikai modellből vagy Analysis Services-modellből

Ha DirectQuery-kapcsolattal csatlakozik Egy Power BI szemantikai modellhez vagy Analysis Services-modellhez, eldöntheti, hogy mely táblákhoz szeretne csatlakozni. Azt is választhatja, hogy automatikusan hozzáadja a szemantikai modellhez vagy modellhez hozzáadott táblákat a modellhez való kapcsolódás után. Amikor egy perspektívához csatlakozik, a modell a szemantikai modell összes tábláját tartalmazza, és a perspektívában nem szereplő táblák el lesznek rejtve. Ezenkívül a perspektívához esetleg hozzáadott táblák automatikusan hozzáadódnak. A Gépház menüben dönthet úgy, hogy a kapcsolat első beállítása után automatikusan csatlakozik a szemantikai modellhez hozzáadott táblákhoz.

Ez a párbeszédpanel nem jelenik meg élő kapcsolatok esetén.

Feljegyzés

Ez a párbeszédpanel csak akkor jelenik meg, ha DirectQuery-kapcsolatot ad hozzá egy Power BI szemantikai modellhez vagy az Analysis Services-modellhez egy meglévő modellhez. Ezt a párbeszédpanelt úgy is megnyithatja, hogy a DirectQuery-kapcsolatot a Power BI szemantikai modelljére vagy az Analysis Services-modellre módosítja az adatforrás beállításai között a létrehozás után.

Deduplikációs szabályok beállítása

Deduplikációs szabályokat adhat meg, hogy a mérték és a táblanevek egyediek maradjanak az összetett modellben a korábban látható párbeszédpanel Gépház beállításával:

Az előző példában úgy döntöttünk, hogy utótagként hozzáadjuk a " (marketing)" nevet minden olyan tábla- vagy mértéknévhez, amely ütközik az összetett modell egy másik forrásával. Vegye figyelembe, hogy a következőt teheti:

• adjon meg egy szöveget, amely hozzáadódik az ütköző táblák vagy mértékek nevéhez
• adja meg, hogy a szöveget előtagként vagy utótagként szeretné-e hozzáadni a táblázathoz vagy a mérték nevéhez
• deduplikációs szabály alkalmazása táblákra, mértékekre vagy mindkettőre
• Válassza ki, hogy a deduplikációs szabályt csak névütközés esetén vagy mindig alkalmazza. Az alapértelmezett beállítás a szabály alkalmazása csak duplikáció esetén. A példánkban a marketingforrásból származó olyan táblák vagy mértékek, amelyek nem rendelkeznek duplikációval az értékesítési forrásban, nem kapnak névmódosítást.

Miután létrehozta a kapcsolatokat, és beállította a deduplikációs szabályt, a mezőlista a példánkban beállított deduplikációs szabálynak megfelelően az "Ügyfél" és az "Ügyfél (marketing)" értéket is megjeleníti:

Ha nem ad meg deduplikációs szabályt, vagy a megadott deduplikációs szabályok nem oldják fel a névütközést, a szokásos deduplikációs szabályok továbbra is érvényesek lesznek. A standard deduplikációs szabályok egy számot adnak hozzá az ütköző elem nevéhez. Ha a "Customer" táblában névütközés lép fel, az egyik "Ügyfél" tábla neve "Ügyfél 2".

Szempontok és korlátozások

Az összetett modellek néhány szempontot és korlátozást mutatnak be:

Vegyes módú kapcsolatok – Ha olyan vegyes módú kapcsolatot használ, amely online adatokat (például Power BI szemantikai modellt) és helyszíni szemantikai modellt (például Excel-munkafüzetet) tartalmaz, a vizualizációk megfelelő megjelenítéséhez átjáróleképezést kell létrehoznia.

Jelenleg a növekményes frissítés csak sql-, Oracle- és Teradata-adatforrásokhoz csatlakozó összetett modellek esetében támogatott.

A következő élő Csatlakozás táblázatos források nem használhatók összetett modellekkel:

• SAP HANA
• SAP Business Warehouse
• AZ SQL Server Analysis Services 2022-es verziónál korábbi verziója
• Használati metrikák (Saját munkaterület)

A streamelt szemantikai modellek használata összetett modellekben nem támogatott.

A DirectQuery meglévő korlátozásai továbbra is érvényesek összetett modellek használatakor. Ezek közül a korlátozások közül sok már táblázatonként van, a tábla tárolási módjától függően. Egy importálási tábla számított oszlopa például hivatkozhat más, a DirectQueryben nem szereplő táblákra, de a DirectQuery-táblák számított oszlopai továbbra is csak ugyanazon a táblán lévő oszlopokra hivatkozhatnak. A modell egészére egyéb korlátozások vonatkoznak, ha a modellen belüli táblák bármelyike DirectQuery. A Gyors Elemzések funkció például nem érhető el a modellen, ha a benne lévő táblák bármelyike rendelkezik DirectQuery tárolási móddal.

Kapcsolódó tartalom

Az összetett modellekről és a DirectQueryről az alábbi cikkekben talál további információt:

• Több-a-többhöz kapcsolatok alkalmazása a Power BI Desktopban
• Tárolási mód kezelése a Power BI Desktopban
• DirectQuery a Power BI-ban
• Power BI-adatforrások
• Modellkapcsolatok a Power BI Desktopban