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 lekéri az egyetlen kategóriára, Cat-A, és egyetlen évre, CY2018, vonatkozó értékesítési rendelések teljes mennyiségét. 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 "mi lenne, ha" paramétere egy olyan funkció, 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.)

Megjegyzé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ós adatbázis-koncepcióval szülő-gyermek kapcsolatokat tárolhat (például minden alkalmazotti rekord egy "közvetlen feletteséhez" 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ásához az oszlop adattípusokat frissíteni kell a Power Query-szerkesztőben , hogy eltávolítsa az importált adatokból az Idő részt, így amikor a motor kezeli az adatokat, az értékek ugyanazok lesznek.

Számossága

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.

Megjegyzé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-többhöz (1:*)
• Több az egyhez (*:1)
• Egy az egyhez (1:1)
• Több-több (*:*)

Amikor kapcsolatot hoz létre a Power BI Desktopban, a tervező észleli és automatikusan beállítja a kardinalitás 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-a-egyhez) számosság

Az egy-a-többhöz és több-az-egyhez kardinalitási beállítások lényegében ugyanazok, és ezek a leggyakoribb kardinalitási tí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éstermé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-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.

A számosságtípus használatával kapcsolatos útmutatásért tekintse meg a több-a-többhöz kapcsolatra vonatkozó útmutatást.

Megjegyzés

A Több-a-többhöz kardinalitás-típus támogatott a Power BI Report Server számára kifejlesztett modellekhez, amelyek a 2024 januári és későbbi verziókhoz készültek.

Jótanács

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 kapcsolati vonal fölé kell helyeznie az oszlopok kiemeléséhez.

Keresztszűrés iránya

Minden modellkapcsolat keresztszűrési iránnyal van definiálva. A beállítás határozza meg a szűrők propagálásának irányát. A lehetséges keresztszűrési beállítások a kardinalitás 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)	Egyedülálló Mindkettő
Egy az egyhez	Mindkettő
Sok-sokhoz	Egyetlen (Table1 to Table2) Egyszeri (Table2–Table1) Mindkettő

Az egy keresztszűrés iránya "egyetlen irányt" jelent, a Mindkettő pedig "mindkét irányt". Olyan kapcsolatot, amely mindkét irányban szűr, 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 kardinalitás típus "egy" oldalt tartalmaz, akkor a szűrők mindig erről az oldalról terjednek.

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.

Jótanács

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 a USERELATIONSHIP 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ó.

Jótanács

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 úgy kapcsolják össze a két táblát, hogy egy INNER JOIN-t használnak egy OUTER JOIN helyett. 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 a különböző táblákból származó, sorkörnyezetben kiértékelt számítások bevonásakor.
• RELATEDTABLE: Egy sortábla lekérése egy kapcsolat "több" oldaláról.
• USERELATIONSHIP: 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 Vertipaq-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 Vertipaq 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 Vertipaq-forráscsoportból és egy DirectQuery-forráscsoportból. A Vertipaq 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 Vertipaq-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 Vertipaq-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 Vertipaq 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.

Megjegyzés

Az inaktív kapcsolatok akkor is ki vannak bővítve, ha a kapcsolatot nem használja egy számítás. A kétirányú kapcsolatok nem befolyásolják a tábla bővítését.

Az egy-a-többhöz kapcsolatok esetében a táblabővítés a "több" oldalról az "egy" oldalra történik a(z) LEFT OUTER JOIN szemantika használatával. 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én is előfordul, de a FULL OUTER JOIN szemantikát használva. 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. Lekérdezés idejében kibővített tábla jelenik meg. 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, gyártási azonosító (9) értékkel, amelyhez nem tartozik egyező érték 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 típusú számosságot használ (akkor is, ha az egyik 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 Vertipaq 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.

Jótanács

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.

Elsőbbség

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.

1. Egy-a-többhöz kapcsolatokból álló útvonal.
2. Egy-többhöz vagy több-többhöz kapcsolatokból álló út.
3. Több-az-egyhez kapcsolatokból álló útvonal.
4. A forrástáblától a köztes tábláig tartó 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.
5. A forrástáblától a köztes tábláig tartó út egy-a-többhöz vagy több-a-többhöz kapcsolatokból áll, amelyet a köztes tábla és a céltábla közötti több-a-többhöz vagy több-az-egyhez kapcsolatok követnek.
6. 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.

Súly

Az útvonal minden kapcsolatának súlya van. Alapértelmezés szerint minden kapcsolati súly egyenlő, kivéve, ha a USERELATIONSHIP 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 útvonal kapcsolatainak száma nem befolyásolja a súlyt.

Egy kapcsolat súlyát a USERELATIONSHIP függvény használatával befolyásolhatja. A súlyt a függvényhívás beágyazási szintje határozza meg, ahol a legbelső függvényhívás kapja a legnagyobb súlyt.

Vegye figyelembe az alábbi 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])
)

Megjegyzés

Ha a Power BI több azonos prioritású és súlyú elérési utat észlel, akkor egyértelműtlen elérési út hibát ad vissza. Ebben az esetben meg kell oldania a kétértelműséget a kapcsolat súlyának befolyásolásával a USERELATIONSHIP függvény használatával, vagy a modellkapcsolatok eltávolításával vagy módosításával.

Teljesítmény-preferencia

Az alábbi lista a szűrés propagálási teljesítményét rendeli el a leggyorsabbtól a leglassabbig:

1. Az egy-a-többhöz típusú kapcsolatok a forráscsoporton belül.
2. Több-a-többhöz modellkapcsolatok egy köztes táblával valósulnak meg, és amelyek közül legalább egy kétirányú kapcsolatot foglal magában.
3. Több-több típusú számossági kapcsolatok
4. Forráscsoportközi kapcsolatok

Kapcsolódó tartalom

A cikkről további információt a következő forrásokban talál:

• Értsd meg a csillagsémát és annak fontosságát a Power BI esetében
• Egy-az-egyhez kapcsolati útmutató
• Több-több 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 helyes és helytelen használata
• Kérdések? Próbálja meg megkérdezni a Power BI közösséget
• Javaslatok? Ötletek hozzáadása a Power BI fejlesztéséhez