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.

A kapcsolatszűrő propagálásának animált diagramja.

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.

Képernyőkép egy Power BI Desktop-modelldiagramról, amely az előző bekezdésben leírt táblákat és kapcsolatokat tartalmazza.

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.

Képernyőkép a modelldiagram két tábláról, kiemelt számosságjelzőkkel.

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.

Képernyőkép a modelldiagram két táblázatáról a keresztszűrő nyílfej kiemelésével.

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.

Képernyőkép a modelldiagram két tábláról és két kapcsolatról; egy egyszínű vonal az aktív és egy szaggatott vonal az inaktívak számára

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 JOINOUTER 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.

Két forráscsoportból álló összetett modell diagramja.

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.

Két forráscsoportból álló összetett modell diagramja, amelyen a normál kapcsolatok vannak megjelölve.

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.

Táblázatbővítés animált diagramja.

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.

Két táblából álló összetett modell diagramja, amelyen a korlátozott kapcsolatok vannak megjelölve.

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.

Képernyőkép a modelldiagram két tábláról, a korlátozott kapcsolat kiemelésével.

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.

  1. Egy-a-többhöz kapcsolatokból álló elérési út.
  2. Egy-a-többhöz vagy több-a-többhöz kapcsolatokból álló elérési út.
  3. Több-az-egyhez kapcsolatokból álló elérési út.
  4. 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.
  5. 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.
  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.

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:

  1. Egy-a-többhöz a forráscsoporton belüli kapcsolatok
  2. Több-a-többhöz modellkapcsolatok egy köztes táblával, és amelyek legalább egy kétirányú kapcsolatot foglalnak magukban
  3. Több-a-többhöz számosságú kapcsolatok
  4. Forráscsoportközi kapcsolatok

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