Modellkapcsolatok a Power BI Desktopban
Ez a cikk a Power BI Desktoppal dolgozó adatmodellezőket célozza meg. Ez egy fontos modelltervezési témakör, amely elengedhetetlen az intuitív, pontos és optimális modellek biztosításához.
Az optimális modelltervezésről, beleértve a táblaszerepköröket és a kapcsolatokat is, részletesebben a csillagséma és a Power BI fontosságának ismertetése című témakörben olvashat.
Kapcsolat célja
A modellkapcsolatok propagálja az egyik modelltábla oszlopában alkalmazott szűrőket egy másik modelltáblára. A szűrők addig propagáljanak, amíg van követendő kapcsolati útvonal, amely több táblára való propagálást is magában foglalhat.
A kapcsolati útvonalak determinisztikusak, ami azt jelenti, hogy a szűrők mindig ugyanúgy és véletlenszerű variációk nélkül propagálásra kerülnek. A kapcsolatok azonban letilthatók, vagy adott DAX-függvényeket használó modellszámításokkal módosíthatják a szűrőkörnyezetet. További információkért tekintse meg a dax-függvényekkel kapcsolatos témakört a jelen cikk későbbi részében.
Fontos
A modellkapcsolatok nem kényszerítik ki az adatintegritást. További információkért tekintse meg a cikk későbbi, Kapcsolatértékelési témakörét, amely bemutatja, hogyan működnek a modellkapcsolatok az adatok integritási problémái esetén.
A kapcsolatok így propagálják a szűrőket egy animált példával.
Ebben a példában a modell négy táblából áll: Kategória, Termék, Év és Értékesítés. A Kategória tábla a Termék táblához, a Termék tábla pedig a Sales táblához kapcsolódik. Az Év tábla a Sales táblához is kapcsolódik. Minden kapcsolat egy-a-többhöz típusú (amelynek részleteit a cikk későbbi részében ismertetjük).
Egy power BI-kártyavizualizáció által generált lekérdezés az egyetlen kategória ( Cat-A) és egyetlen év ( CY2018) értékesítési rendeléseinek teljes értékesítési mennyiségét kéri le. Ezért láthatók a kategória - és évtáblákra alkalmazott szűrők. A Kategória tábla szűrője a Termék táblába propagálva elkülönít két terméket, amelyek a Cat-A kategóriához vannak rendelve. Ezután a Termék tábla szűrői a Sales táblába propagálva csak két értékesítési sort különítenek el ezekhez a termékekhez. Ez a két értékesítési sor a Cat-A kategóriához rendelt termékek értékesítését jelöli. Együttes mennyiségük 14 egység. Ugyanakkor az Év tábla szűrő propagálása tovább szűri a Sales táblát, ami csak azt az értékesítési sort eredményezi, amely a Cat-A kategóriába rendelt termékekhez tartozik, és amelyet a CY2018 évben rendeltek. A lekérdezés által visszaadott mennyiségi érték 11 egység. Vegye figyelembe, hogy ha több szűrőt alkalmaz egy táblára (például a Példában a Sales táblára), az mindig EGY ÉS művelet, amely megköveteli, hogy minden feltételnek igaznak kell lennie.
Csillagséma tervezési alapelveinek alkalmazása
Javasoljuk, hogy a csillagséma tervezési alapelveit alkalmazza a dimenzió- és ténytáblákból álló modell létrehozásához. Gyakori, hogy a Power BI-t úgy állítja be, hogy kikényszerítse a dimenziótáblák szűrésére vonatkozó szabályokat, így a modellkapcsolatok hatékonyan propagálja ezeket a szűrőket ténytáblákra.
Az alábbi képen az Adventure Works értékesítési elemzési adatmodelljének modelldiagramja látható. Egy csillagséma-kialakítást jelenít meg, amely egyetlen Sales nevű ténytáblát tartalmaz. A másik négy tábla dimenziótáblák, amelyek támogatják az értékesítési mértékek dátum, állapot, régió és termék szerinti elemzését. Figyelje meg az összes táblát összekötő modellkapcsolatokat. Ezek a kapcsolatok szűrőket propagálnak (közvetlenül vagy közvetve) a Sales táblába.
Leválasztott táblák
Szokatlan, hogy a modelltáblák nem kapcsolódnak egy másik modelltáblához. Az ilyen táblák egy érvényes modelltervben leválasztott táblának minősülnek. A leválasztott táblák nem arra szolgálnak, hogy szűrőket propagáljanak más modelltáblákra. Ehelyett elfogadja a "felhasználói bemenetet" (esetleg szeletelő vizualizációval), lehetővé téve, hogy a modellszámítások értelmes módon használják a bemeneti értéket. Vegyük például azt a leválasztott táblát, amely a pénznemárfolyam-értékek tartományával van betöltve. Mindaddig, amíg egy szűrőt alkalmaz a szűrésre egyetlen díjérték alapján, a mértékkifejezések ezt az értéket használhatják az értékesítési értékek konvertálásához.
A Power BI Desktop lehetőségparamétere egy olyan szolgáltatás, amely leválasztott táblát hoz létre. További információt a Változók Power BI Desktopban való megjelenítéséhez használt What if paraméter létrehozása és használata című témakörben talál.
Kapcsolat tulajdonságai
A modellkapcsolatok egy tábla egyik oszlopát egy másik tábla egyik oszlopához kapcsolják. (Van egy speciális eset, ahol ez a követelmény nem igaz, és csak a DirectQuery-modellek többoszlopos kapcsolataira vonatkozik. További információ: COMBINEVALUES DAX függvénycikk.)
Feljegyzés
Egy oszlop nem kapcsolható egy másik oszlophoz ugyanabban a táblában. Ezt a fogalmat néha összekeverik azzal a képességgel, hogy egy relációs adatbázis idegenkulcs-korlátozását definiálja, amely a tábla önhivatkozása. Ezzel a relációsadatbázis-koncepcióval szülő-gyermek kapcsolatokat tárolhat (például minden alkalmazotti rekord egy "jelentéshez" alkalmazotthoz kapcsolódik). A modellkapcsolatok azonban nem használhatók modellhierarchia létrehozásához az ilyen típusú kapcsolatok alapján. Szülő-gyermek hierarchia létrehozásához tekintse meg a Szülő és gyermek függvényeket.
Oszlopok adattípusai
A kapcsolat "from" és "to" oszlopának adattípusának azonosnak kell lennie. Előfordulhat, hogy a DateTime-oszlopokban definiált kapcsolatok használata nem a várt módon működik. A Power BI-adatokat tároló motor csak DateTime-adattípusokat használ; A dátum,idő és dátum/idő/időzón adattípusok felül implementált Power BI-formázási szerkezetek. A modellfüggő objektumok továbbra is DateTime-ként jelennek meg a motorban (például kapcsolatok, csoportok stb.). Így ha egy felhasználó a Dátum lehetőséget választja az ilyen oszlopok Modellezés lapján, akkor sem regisztrálja ugyanazt a dátumot, mert az adatok időrészét a motor továbbra is figyelembe veszi. További információ a dátum-/időtípusok kezeléséről. A viselkedés javítása érdekében az oszlop adattípusokat frissíteni kell a Power Query-szerkesztő az importált adatok Idő részének eltávolításához, így amikor a motor kezeli az adatokat, az értékek ugyanúgy jelennek meg.
Számosság
Minden modellkapcsolatot számosságtípus határoz meg. Négy számosságtípus-beállítás létezik, amelyek a "from" és a "to" kapcsolódó oszlopok adatjellemzőit jelölik. Az "egy" oldal azt jelenti, hogy az oszlop egyedi értékeket tartalmaz; a "több" oldal azt jelenti, hogy az oszlop ismétlődő értékeket tartalmazhat.
Feljegyzés
Ha egy adatfrissítési művelet ismétlődő értékeket próbál betölteni egy "egy" oldaloszlopba, a teljes adatfrissítés sikertelen lesz.
A négy lehetőség és a rövidített jelölések a következő felsorolásban találhatók:
- Egy-a-többhöz (1:*)
- Több az egyhez (*:1)
- Egy az egyhez (1:1)
- Több a többhöz (*:*)
Amikor kapcsolatot hoz létre a Power BI Desktopban, a tervező automatikusan észleli és beállítja a számosság típusát. A Power BI Desktop lekérdezi a modellt, hogy melyik oszlopok tartalmaznak egyedi értékeket. Importálási modellek esetében belső tárolási statisztikákat használ; DirectQuery-modellek esetén profilkészítési lekérdezéseket küld az adatforrásnak. Előfordulhat azonban, hogy a Power BI Desktop téved. Ez akkor lehet hibás, ha a táblák még nem tölthetők be adatokkal, vagy mert az ismétlődő értékeket tartalmazó oszlopok jelenleg egyedi értékeket tartalmaznak. Mindkét esetben frissítheti a számosságtípust, ha bármely "egy" oldaloszlop egyedi értékeket tartalmaz (vagy a táblázatot még be kell tölteni adatsorokkal).
Egy-a-többhöz (és több az egyhez) számosság
Az egy-a-többhöz és a több-az-egyhez számosság beállításai lényegében ugyanazok, és ezek a leggyakoribb számosságtípusok is.
Egy-a-többhöz vagy több-az-egyhez kapcsolat konfigurálásakor azt a sorrendet fogja választani, amelyben az oszlopokat összekapcsolta. Fontolja meg, hogyan konfigurálná a Termék tábla és a Sales tábla közötti kapcsolatot az egyes táblákban található ProductID oszlop használatával. A számosság típusa egy a többhöz típusú lehet, mivel a Product tábla ProductID oszlopa egyedi értékeket tartalmaz. Ha a táblákat fordított irányban( Értékesítés termékre) kapcsolta, akkor a számosság több-az-egyhez lesz.
Egy az egyhez számosság
Az egy-az-egyhez kapcsolat azt jelenti, hogy mindkét oszlop egyedi értékeket tartalmaz. Ez a számosságtípus nem gyakori, és valószínűleg a redundáns adatok tárolása miatt nem optimális modelltervet jelent.
Ennek a számosságtípusnak a használatáról további információt az Egy-az-egyhez kapcsolat útmutatóban talál.
Több-a-többhöz számosság
A több-a-többhöz kapcsolat azt jelenti, hogy mindkét oszlop duplikált értékeket tartalmazhat. Ez a számosságtípus ritkán használatos. Ez általában összetett modellkövetelmények tervezésekor hasznos. A több-a-többhöz típusú tények összekapcsolására vagy magasabb szintű tények összekapcsolására használható. Ha például az értékesítési céladatok a termékkategória szintjén vannak tárolva, és a termék dimenziótáblája termékszinten van tárolva.
Ennek a számosságtípusnak a használatával kapcsolatos útmutatásért tekintse meg a több-a-többhöz kapcsolatra vonatkozó útmutatást.
Feljegyzés
A több-a-többhöz számosság típus támogatott a 2024. január Power BI jelentéskészítő kiszolgáló- és újabb verziókhoz kifejlesztett modellekhez.
Tipp.
A Power BI Desktop modellnézetben a kapcsolat számosságtípusát úgy értelmezheti, hogy a kapcsolatvonal mindkét oldalán az (1 vagy *) jelzőket vizsgáljuk meg. A kapcsolódó oszlopok meghatározásához ki kell jelölnie vagy a kurzort a kurzor fölé kell helyeznie az oszlopok kiemeléséhez.
Keresztszűrés iránya
Minden modellkapcsolat keresztszűréssel van definiálva. A beállítás határozza meg a szűrők propagálásának irányát. A keresztszűrés lehetséges beállításai a számosság típusától függenek.
Számosság típusa | Keresztszűrés beállításai |
---|---|
Egy-a-többhöz (vagy több-az-egyhez) | Egyszeres Mindkettő |
Egyhez | Mindkettő |
Több-a-többhöz | Single (Table1 to Table2) Single (Table2 to Table1) Mindkettő |
Az egy keresztszűrés iránya "egyetlen irányt" jelent, a Mindkettő pedig "mindkét irányt". A kétirányú szűrőket gyakran kétirányúnak nevezik.
Az egy-a-többhöz kapcsolatok esetében a keresztszűrés iránya mindig az "egy" oldalról, és opcionálisan a "több" oldalról (kétirányú) történik. Az egy-az-egyhez kapcsolatok esetében a keresztszűrés iránya mindig mindkét táblából származik. Végül, a több-a-többhöz kapcsolatok esetén a keresztszűrés iránya bármelyik táblából vagy mindkét táblából származhat. Figyelje meg, hogy ha a számosságtípus egy "egy" oldalt tartalmaz, akkor a szűrők mindig erről az oldalról propagálásra kerülnek.
Ha a keresztszűrés iránya Mindkettő értékre van állítva, egy másik tulajdonság válik elérhetővé. Kétirányú szűrést alkalmazhat, ha a Power BI sorszintű biztonsági (RLS) szabályokat kényszerít ki. További információ az RLS-ről: Sorszintű biztonság (RLS) a Power BI Desktoppal.
Modellszámítással módosíthatja a kapcsolat keresztszűrési irányát, beleértve a szűrőpropagálás letiltását is. Ez a CROSSFILTER DAX függvény használatával érhető el.
Ne feledje, hogy a kétirányú kapcsolatok negatív hatással lehetnek a teljesítményre. Emellett a kétirányú kapcsolat konfigurálásának megkísérlése nem egyértelmű szűrőpropagálási útvonalakat eredményezhet. Ebben az esetben előfordulhat, hogy a Power BI Desktop nem véglegesíti a kapcsolat módosítását, és hibaüzenetet küld. Előfordulhat azonban, hogy a Power BI Desktop lehetővé teszi, hogy kétértelmű kapcsolati útvonalakat határozzon meg a táblák között. A kapcsolati út kétértelműségének feloldásáról a cikk későbbi részében olvashat.
Javasoljuk, hogy csak szükség esetén használjunk kétirányú szűrést. További információkért tekintse meg a kétirányú kapcsolatra vonatkozó útmutatást.
Tipp.
A Power BI Desktop modellnézetben a kapcsolat keresztszűrési irányát úgy értelmezheti, hogy a kapcsolatvonal mentén a nyílhegy(ek)et észleli. Egyetlen nyílhegy egy egyirányú szűrőt jelöl a nyílfej irányában; a kettős nyílfej kétirányú kapcsolatot jelöl.
Kapcsolat aktívvá tétele
Két modelltábla között csak egy aktív szűrőpropagálási útvonal lehet. Azonban további kapcsolati útvonalakat is bevezethet, azonban ezeket a kapcsolatokat inaktívként kell beállítania. Az inaktív kapcsolatok csak a modellszámítás kiértékelése során tehetők aktívvá. Ez az U Standard kiadás RELATIONSHIP DAX függvény használatával érhető el.
Általában azt javasoljuk, hogy amikor csak lehetséges, definiálja az aktív kapcsolatokat. Kibővítik annak hatókörét és lehetőségeit, hogy a jelentéskészítők hogyan használhatják a modellt. Ha csak aktív kapcsolatokat használ, az azt jelenti, hogy a szerepkör-lejátszási dimenziótáblákat duplikálni kell a modellben.
Adott körülmények között azonban definiálhat egy vagy több inaktív kapcsolatot egy szerepkör-játék dimenziótáblához. Ezt a kialakítást akkor érdemes megfontolni, ha:
- Nincs szükség arra, hogy a jelentésvizualizációk egyszerre szűrjenek különböző szerepkörök szerint.
- A
USERELATIONSHIP
DAX függvénnyel aktiválhat egy adott kapcsolatot a releváns modellszámításokhoz.
További információ: Aktív és inaktív kapcsolati útmutató.
Tipp.
A Power BI Desktop modellnézetben értelmezheti egy kapcsolat aktív és inaktív állapotát. Az aktív kapcsolatot egy folytonos vonal jelöli; az inaktív kapcsolat szaggatott vonalként jelenik meg.
Hivatkozási integritás feltételezése
A Hivatkozási integritás feltételezése tulajdonság csak az egy-a-többhöz és az egy-az-egyhez típusú kapcsolatokhoz érhető el két DirectQuery tárolási módú tábla között, amelyek ugyanahhoz a forráscsoporthoz tartoznak. Ezt a tulajdonságot csak akkor engedélyezheti, ha a "sok" oldaloszlop nem tartalmaz NULL-eket.
Ha engedélyezve van, az adatforrásnak küldött natív lekérdezések összekapcsolják a két táblát egy helyett egy INNER JOIN
OUTER JOIN
. A tulajdonság engedélyezése általában javítja a lekérdezési teljesítményt, bár ez az adatforrás jellemzőitől függ.
Mindig engedélyezze ezt a tulajdonságot, ha a két tábla között adatbázis-idegenkulcs-korlátozás van érvényben. Még ha nem is létezik idegenkulcs-korlátozás, fontolja meg a tulajdonság engedélyezését mindaddig, amíg bizonyos adatok integritása fennáll.
Fontos
Ha az adatintegritás sérül, a belső illesztés megszünteti a táblák közötti nem egyező sorokat. Vegyük például az Értékesítési modell táblát egy ProductID oszlopértékkel, amely nem létezik a kapcsolódó Termék táblában. A Termék táblából a Sales táblába történő szűrési propagálás megszünteti az ismeretlen termékek értékesítési sorait. Ez az értékesítési eredmények alulértékelését eredményezné.
További információ: Hivatkozási integritási beállítások feltételezése a Power BI Desktopban.
Releváns DAX-függvények
Számos DAX-függvény van, amelyek relevánsak a modellkapcsolatokhoz. Az egyes függvényeket röviden a következő listajeles listában ismertetjük:
- KAPCSOLÓDÓ: Egy kapcsolat "egy" oldaláról kéri le az értéket. Hasznos, ha a sorkörnyezetben kiértékelt különböző táblákból származó számításokat von be.
- RELATEDTABLE: Egy sortábla lekérése egy kapcsolat "több" oldaláról.
- U Standard kiadás RELATIONSHIP: Lehetővé teszi, hogy egy számítás inaktív kapcsolatot használjon. (Ez a függvény technikailag módosítja egy adott inaktív modellkapcsolat súlyát, ami segít befolyásolni a használatát.) Ez akkor hasznos, ha a modell tartalmaz egy szerepkör-lejátszási dimenziótáblát, és inaktív kapcsolatokat hoz létre ebből a táblából. Ezzel a függvénnyel a szűrőútvonalak kétértelműségét is feloldhatja.
- KERESZTSZŰRŐ: Módosítja a kapcsolat keresztszűrési irányát (egy vagy mindkettőre), vagy letiltja a szűrőpropagálást (nincs). Ez akkor hasznos, ha egy adott számítás kiértékelése során módosítania vagy figyelmen kívül kell hagynia a modellkapcsolatokat.
- COMBINEVALUES: Két vagy több szöveges sztringet illeszt egy szöveges sztringbe. Ennek a függvénynek a célja, hogy támogassa a DirectQuery-modellek többoszlopos kapcsolatait, ha a táblák ugyanahhoz a forráscsoporthoz tartoznak.
- TREATAS: Egy táblakifejezés eredményét alkalmazza szűrőkként egy nem kapcsolódó tábla oszlopaira. Speciális helyzetekben hasznos, ha virtuális kapcsolatot szeretne létrehozni egy adott számítás kiértékelése során.
- Szülő- és gyermekfüggvények: Egy kapcsolódó függvénycsalád, amellyel számított oszlopokat hozhat létre a szülő-gyermek hierarchia honosításához. Ezek az oszlopok ezután rögzített szintű hierarchiát hozhatnak létre.
Kapcsolat kiértékelése
A modellkapcsolatok kiértékelési szempontból normálnak vagy korlátozottnak minősülnek. Ez nem konfigurálható kapcsolattulajdonság. Valójában a két kapcsolódó tábla számosságtípusából és adatforrásából következik. Fontos megérteni a kiértékelési típust, mert az adatok integritásának sérülése teljesítménybeli következményekkel vagy következményekkel járhat. Ezeket a következményeket és integritási következményeket ebben a témakörben ismertetjük.
Először is néhány modellezési elméletre van szükség a kapcsolatértékelések teljes megértéséhez.
Egy importálási vagy DirectQuery-modell az összes adatát a Veripaq gyorsítótárból vagy a forrásadatbázisból származtatja. A Power BI mindkét esetben meg tudja állapítani, hogy létezik-e kapcsolat "egy" oldala.
Az összetett modellek azonban különböző tárolási módokat (importálás, DirectQuery vagy kettős) vagy több DirectQuery-forrást használó táblákat is tartalmazhatnak. Minden forrás, beleértve az importált adatok Veripaq gyorsítótárát is, forráscsoportnak minősül. A modellkapcsolatok ezután a forráscsoporton belüli vagy a forrásközi csoportként is besorolhatók. A forráscsoporton belüli kapcsolatok két táblát kapcsolnak össze egy forráscsoporton belül, míg a forráscsoportközi kapcsolatok két forráscsoport tábláit. Vegye figyelembe, hogy az importálási vagy DirectQuery-modellek kapcsolatai mindig forráscsoporton belüliek.
Íme egy példa egy összetett modellre.
Ebben a példában az összetett modell két forráscsoportból áll: egy Veripaq forráscsoportból és egy DirectQuery-forráscsoportból. A Veripaq forráscsoport három táblát, a DirectQuery-forráscsoport pedig két táblát tartalmaz. Egy forráscsoportközi kapcsolat létezik a Veripaq forráscsoport egyik táblájának a DirectQuery-forráscsoport egyik táblához való kapcsolásához.
Normál kapcsolatok
A modellkapcsolat akkor rendszeres , ha a lekérdezési motor meg tudja határozni a kapcsolat "egy" oldalát. Megerősíti, hogy az "egy" oldaloszlop egyedi értékeket tartalmaz. A forráscsoporton belüli összes egy-a-többhöz kapcsolat normál kapcsolat.
Az alábbi példában két reguláris kapcsolat van, mindkettő R-ként van megjelölve. A kapcsolatok közé tartozik a Veripaq forráscsoportban található egy-a-többhöz kapcsolat, valamint a DirectQuery-forrásban található egy-a-többhöz kapcsolat.
Az importálási modellek esetében, ahol az összes adat a Veripaq gyorsítótárban van tárolva, a Power BI adatstruktúrát hoz létre minden rendszeres kapcsolathoz adatfrissítéskor. Az adatstruktúrák az összes oszlopról oszlopra mutató értékek indexelt leképezéseiből állnak, és a céljuk a táblák lekérdezési idejének felgyorsítása.
Lekérdezéskor a rendszeres kapcsolatok lehetővé teszik a táblabővítést . A táblázatbővítés eredménye egy virtuális tábla létrehozása az alaptábla natív oszlopainak beiktatásával, majd a kapcsolódó táblákká való kibontással. Az importálási táblák esetében a táblabővítés a lekérdezési motorban történik; DirectQuery-táblák esetében ez a forrásadatbázisba küldött natív lekérdezésben történik (feltéve, hogy a Hivatkozási integritás feltételezése tulajdonság nincs engedélyezve). A lekérdezési motor ezután a kibontott táblára lép, szűrőket alkalmazva és csoportosítva a kibontott táblaoszlopok értékei alapján.
Feljegyzés
Az inaktív kapcsolatok akkor is ki vannak bontva, ha a kapcsolatot nem használják számítások. A kétirányú kapcsolatok nem befolyásolják a táblabővítést.
Az egy-a-többhöz kapcsolatok esetében a táblabővítés a "több" oldalról az "egy" oldalra kerül szemantikával LEFT OUTER JOIN
. Ha nem létezik egyező érték a "több" és az "egy" oldal között, a rendszer egy üres virtuális sort ad hozzá az "egy" oldaltáblához. Ez a viselkedés csak a normál kapcsolatokra vonatkozik, a korlátozott kapcsolatokra nem.
A táblabővítés a forráscsoporton belüli egy-az-egyhez kapcsolatok esetében is előfordul, de szemantika használatával FULL OUTER JOIN
. Ez az illesztéstípus biztosítja, hogy szükség esetén az üres virtuális sorok mindkét oldalon hozzá legyenek adva.
Az üres virtuális sorok gyakorlatilag ismeretlen tagok. Az ismeretlen tagok hivatkozási integritási szabálysértéseket jelölnek, ahol a "több" oldal értéke nem rendelkezik megfelelő "egy" oldal értékkel. Ideális esetben ezek az üres cellák nem létezhetnek. A forrásadatok tisztításával vagy javításával kiküszöbölhetők.
A táblázatbővítés így működik animált példával.
Ebben a példában a modell három táblából áll: Kategória, Termék és Értékesítés. A Kategória tábla egy-a-többhöz kapcsolattal rendelkező Termék táblához kapcsolódik, a Termék tábla pedig az Egy-a-többhöz kapcsolattal rendelkező Sales táblához. A Kategória tábla két sort tartalmaz, a Termék tábla három sort, a Sales táblák pedig öt sort. Az összes kapcsolat mindkét oldalán vannak egyező értékek, ami azt jelenti, hogy nincsenek hivatkozási integritás megsértései. A lekérdezési idő kibontott táblája ki lesz derítve. A tábla mindhárom tábla oszlopaiból áll. Ez tulajdonképpen a három táblában található adatok denormalizált perspektívája. Egy új sor kerül a Sales táblába, és egy éles azonosító (9) értékkel rendelkezik, amelynek nincs egyező értéke a Termék táblában. Hivatkozási integritás megsértése. A kibontott táblában az új sor (Üres) értékeket tartalmaz a Kategória és a Termék tábla oszlopaihoz.
Korlátozott kapcsolatok
A modellkapcsolatok akkor korlátozottak, ha nincs garantált "egy" oldal. A korlátozott kapcsolat két okból fordulhat elő:
- A kapcsolat több-a-többhöz számosságtípust használ (akkor is, ha egy vagy mindkét oszlop egyedi értékeket tartalmaz).
- A kapcsolat forráscsoportközi (ez csak összetett modellek esetében lehet így).
Az alábbi példában két korlátozott kapcsolat van, mindkettő L-ként van megjelölve. A két kapcsolat magában foglalja a Veripaq forráscsoportban található több-a-többhöz kapcsolatot, valamint az egy-a-többhöz forráscsoport közötti kapcsolatot.
Importálási modellek esetében az adatstruktúrák soha nem jönnek létre korlátozott kapcsolatokhoz. Ebben az esetben a Power BI a lekérdezési időpontban feloldja a táblaillesztéseket.
A táblabővítés soha nem fordul elő korlátozott kapcsolatok esetén. A táblaillesztések szemantikával INNER JOIN
érhetők el, ezért a rendszer nem ad hozzá üres virtuális sorokat a hivatkozási integritás megsértésének kompenzálásához.
A korlátozott kapcsolatokra más korlátozások is vonatkoznak:
- A
RELATED
DAX-függvény nem használható az "egy" oldaloszlop értékeinek lekérésére. - Az RLS kényszerítése topológiakorlátozásokkal rendelkezik.
Tipp.
A Power BI Desktop modellnézetben a kapcsolatok korlátozottként értelmezhetők. A számosságjelzők után a korlátozott kapcsolat zárójelszerű jelekkel ( ) jelenik meg.
Kapcsolati útvonal kétértelműségének feloldása
A kétirányú kapcsolatok több, ezért nem egyértelmű szűrési propagálási útvonalat is bevezethetnek a modelltáblák között. A kétértelműség kiértékelésekor a Power BI a szűrés propagálási útvonalát a prioritása és súlya alapján választja ki.
Prioritás
A prioritási szintek olyan szabályok sorozatát határozzák meg, amelyeket a Power BI a kapcsolati út kétértelműségének feloldására használ. Az első szabályegyezés határozza meg, hogy a Power BI milyen útvonalat követ. Az alábbi szabályok azt írják le, hogyan haladnak a szűrők a forrástáblából a céltáblába.
- Egy-a-többhöz kapcsolatokból álló elérési út.
- Egy-a-többhöz vagy több-a-többhöz kapcsolatokból álló elérési út.
- Több-az-egyhez kapcsolatokból álló elérési út.
- A forrástábla és a köztes tábla közötti egy-a-többhöz kapcsolatokból álló elérési út, amelyet a köztes tábla és a céltábla közötti több-az-egyhez kapcsolatok követnek.
- A forrástábla és a köztes tábla közötti egy-a-többhöz vagy több-a-többhöz kapcsolatokból álló elérési út, amelyet a köztes tábla és a céltábla közötti több-az-egyhez vagy több-a-többhöz kapcsolatok követnek.
- Bármilyen más elérési út.
Ha egy kapcsolat az összes elérhető elérési út részét képezi, a rendszer eltávolítja azt az összes elérési útból.
Betűvastagság
Az elérési út minden kapcsolatának súlya van. Alapértelmezés szerint minden kapcsolati súly egyenlő, kivéve, ha az U Standard kiadás RELATIONSHIP függvényt használja. Az elérési út súlya az elérési út mentén található összes kapcsolati súly maximuma. A Power BI az elérési utak súlyozásával oldja fel az azonos prioritási szinten lévő több elérési út közötti kétértelműséget. Nem az alacsonyabb prioritású útvonalat választja, hanem a nagyobb súlyú útvonalat. Az elérési út kapcsolatainak száma nem befolyásolja a súlyt.
A kapcsolat súlyát az U Standard kiadás RELATIONSHIP függvény használatával befolyásolhatja. A súlyt a függvény hívásának beágyazási szintje határozza meg, ahol a legbelső hívás kapja a legnagyobb súlyt.
Gondolja át a következő példát. A Termékértékesítés mérték nagyobb súlyt rendel a Sales[ProductID] és a Product[ProductID] közötti kapcsolathoz, majd az Inventory[ProductID] és a Product[ProductID] közötti kapcsolathoz.
Product Sales =
CALCULATE(
CALCULATE(
SUM(Sales[SalesAmount]),
USERELATIONSHIP(Sales[ProductID], Product[ProductID])
),
USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)
Feljegyzés
Ha a Power BI több azonos prioritású és súlyú elérési utat észlel, az nem egyértelmű elérési utat eredményez. Ebben az esetben meg kell oldania a kétértelműséget a kapcsolat súlyának befolyásolásával az U Standard kiadás RELATIONSHIP függvény használatával, vagy a modellkapcsolatok eltávolításával vagy módosításával.
Teljesítménybeállítás
Az alábbi lista a szűrés propagálási teljesítményét rendeli el a leggyorsabbtól a leglassabbig:
- Egy-a-többhöz a forráscsoporton belüli kapcsolatok
- Több-a-többhöz modellkapcsolatok egy köztes táblával, és amelyek legalább egy kétirányú kapcsolatot foglalnak magukban
- Több-a-többhöz számosságú kapcsolatok
- Forráscsoportközi kapcsolatok
Kapcsolódó tartalom
A cikkről további információt a következő forrásokban talál:
- A csillagséma és a Power BI fontossága
- Egy-az-egyhez kapcsolati útmutató
- Több-a-többhöz kapcsolati útmutató
- Aktív és inaktív kapcsolatokra vonatkozó útmutató
- Kétirányú kapcsolati útmutató
- Kapcsolat hibaelhárítási útmutatója
- Videó: A Power BI-kapcsolatok do's and don's and dons of Power BI Relationships
- Kérdése van? Kérdezze meg a Power BI-közösség
- Javaslatok? Ötletek hozzáadása a Power BI fejlesztéséhez