esemény
Power BI DataViz világbajnokság
febr. 14. 16 - márc. 31. 16
4 esélye, hogy belépjen, nyerhet egy konferenciacsomagot, és bejuthat a LIVE Grand Finale-be Las Vegasban
További információEzt 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.
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 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:
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:
Összetett modellek használatával például létrehozhat egy olyan modellt, amely a következő adattípusokat egyesíti:
Ö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.
Megjegyzé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.
Összetett modell például egy olyan jelentés, amely a DirectQuery használatával csatlakozik 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 és 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:
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.
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.
Megjegyzé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á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óval Power BI szolgáltatás, hacsak nem felel meg bizonyos követelményeknek. Erről további információt a jelen cikk szemantikai modellen alapuló összetett modellekkel foglalkozó szakaszában talál.
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 egy titkosított kapcsolattal adatokat kérjen le egy forrásból, majd véletlenül belevehesse azokat egy másik forrásnak egy 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ó a natív SQL-lekérdezéseket tartalmazó fájl megnyitásakor megjelenőhöz.
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, az SQL Servernek küldött lekérdezés Termékmenedzser táblájának adatait kell átadnia. 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.
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:
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áscsoportot adnak hozzá:
Megjegyzé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ó.
Az összetett modellben kétféle kapcsolat létezik:
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:
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])
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 dátumra 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 meghatároz egy olyan számítási csoportot, 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 határozták meg. 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:
[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.
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.
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:
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 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ödnek, é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 teheti közzé a szolgáltatásban. A jelentés és a modell közzétételekor a következő hibaüzenet jelenik meg, és a kiadvány le van tiltva:
A Power BI szemantikai modelljeihez való élő kapcsolatokat nem befolyásolja a kapcsoló, és az Analysis Services élő vagy DirectQuery kapcsolatai sem. Ezek továbbra is működnek, 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.
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 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.
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 egy Sales (Értékesítés) nevű Analysis Services-modellen alapuló Értékesítés és költségvetés nevű Power BI szemantikai modellt tesz közzé, és kombinálja egy Költségvetés nevű Excel-munkalaptal.
Amikor a munkatársa által közzétett Sales and Budget Power BI szemantikai modell alapján közzétesz egy Sales and Budget Europe nevű új jelentést (és szemantikai modellt), és további módosításokat vagy bővítményeket végez, 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.
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)
Összetett C modell (tulajdonos: C)
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.
Megjegyzé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.
A Power BI szemantikai modellek és az Analysis Services-modellek összetett modelljeinek használata egy biztonsági figyelmeztetési párbeszédpanelt jelenít meg, 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, olvassa el az összetett modellek használatát a Power BI Desktopban.
Ö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:
A Power BI szemantikai modelljeihez és az Analysis Serviceshez készült DirectQuery használatakor vegye figyelembe a következő információkat:
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óhoz vagy az IAAS-hez való csatlakozáshoz helyszíni adatátjáróra (Standard mód) van szükség.
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 vannak alkalmazva, amelyen definiálva vannak, de a modellben lévő többi szemantikai modellre nem vonatkoznak. A jelentésben definiált RLS-t a rendszer nem alkalmazza a távoli forrásokra, a távoli forrásokra beállított RLS-t pedig nem alkalmazza a rendszer 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 importálhatók 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:
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 :
További szempontokért és útmutatásért tekintse meg az összetett modell útmutatását.
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 Desktoppal Ash DirectQuery-kapcsolatot hoz létre egy Analysis Services-modellhez, amely a Fabrikam bérlőjében található.
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 működik.
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ér az Analysis Services-modellhez (5. lépés), és a jelentés megfelelően működik.
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. 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:
Fontos szempont, hogy az első felsorolásban leírt eset ellenére az összetett modell felhasználói soha nem látják azokat a tényleges adatokat, amelyeket nem kellene látniuk, mert az adatok 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:
Admin_user közzétett egy vállalati szemantikai modellt egy Power BI szemantikai modell vagy egy Ügyfél táblával és Egy Territory táblával rendelkező Analysis Services-modell használatával. Admin_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:
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.
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.
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 egy oszlopot használ, a rendszer hibát ad vissza, mert ezen a ponton a DirectQuery megpróbálja lekérni az adatokat 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 ezt láthatják Finance_user, 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.
Most tegyük fel, hogy Admin_user frissíti a vállalati szemantikai modell OLS-szabályait, hogy megakadályozza a Finance számára a Territory táblát.
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érnek hozzá a Terület táblához.
Összegezve:
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. Ha 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 rejtettek. Ezenkívül a perspektívához esetleg hozzáadott táblák automatikusan hozzáadódnak. A Beállítások 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.
Megjegyzé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ályokat adhat meg, hogy a mérték és a táblanevek egyediek maradjanak az összetett modellben a beállítások beállításával a korábban látható párbeszédpanelen:
Az előző példában a " (marketing)" utótagot adtunk hozzá minden olyan tábla- vagy mértéknévhez, amely ütközik az összetett modell egy másik forrásával. A következőket teheti:
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 az Ügyfél táblában névütközés van, az egyik "Ügyfél" tábla neve "Ügyfél 2".
Ha XMLA használatával módosít egy szemantikai modellt, frissítenie kell a módosított objektum ChangedProperties és PBI_RemovedChildren gyűjteményét, hogy az tartalmazza a módosított vagy eltávolított tulajdonságokat. Ha nem hajtja végre ezt a frissítést, a Power BI modellezési eszközei felülírhatják a módosításokat, amikor a séma legközelebb szinkronizálódik az adatforrással.
További információt a Power BI szemantikai modellekhez kapcsolódó vonalcímkékről a vonalcímkék a szemantikai modellekhez című cikkben talál.
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ő Live Connect táblázatos források nem használhatók összetett modellekkel:
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 olyan táblákra is, amelyek nem szerepelnek a DirectQueryben, 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 QuickInsights 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.
Ha sorszintű biztonságot használ egy összetett modellben, és néhány táblát DirectQuery módban használ, frissítenie kell a modellt a DirectQuery-táblák új frissítéseinek alkalmazásához. Ha például egy Felhasználó tábla DirectQuery módban új felhasználói rekordokat tartalmaz a forrásnál, az új rekordok csak a következő modellfrissítés után lesznek felvéve. A Power BI szolgáltatás gyorsítótárazza a Felhasználók lekérdezést a teljesítmény javítása érdekében, és nem tölti be újra az adatokat a forrásból a következő manuális vagy ütemezett frissítésig.
Az összetett modellekről és a DirectQueryről az alábbi cikkekben talál további információt:
esemény
Power BI DataViz világbajnokság
febr. 14. 16 - márc. 31. 16
4 esélye, hogy belépjen, nyerhet egy konferenciacsomagot, és bejuthat a LIVE Grand Finale-be Las Vegasban
További információOktatás
Modul
Power BI-modell biztonságának érvényesítése - Training
Modellbiztonság kényszerítése a Power BI-ban sorszintű biztonság és objektumszintű biztonság használatával.
Tanúsítvány
Microsoft minősítéssel rendelkező: Power BI Adatelemző Munkatárs - Certifications
Bemutatjuk azokat a módszereket és ajánlott eljárásokat, amelyek megfelelnek az adatok modellezésére, vizualizációira és elemzésére vonatkozó üzleti és műszaki követelményeknek a Microsoft Power BI-jal.
Dokumentáció
Csatlakozás szemantikai modellekhez a Power BI-ban - Power BI
Egy megosztott, gyakori szemantikai modell használatával több Power BI Desktop-jelentést hozhat létre több munkaterületen, és kezelheti a jelentés életciklusát.
Mi a különbség az élő kapcsolatok és a DirectQuery között? - Power BI
Az élő kapcsolatok és a DirectQuery összehasonlítása
DirectQuery-kapcsolatok kezelése közzétett szemantikai modellel - Power BI
Megtudhatja, hogyan kezelheti a DirectQuery-kapcsolatokat egy közzétett szemantikai modellel a Power BI-ban. Emellett megtudhatja, hogyan akadályozhatja meg a DirectQuery-kapcsolatok létrejöttét.