Aktív és inaktív kapcsolatokra vonatkozó útmutató
Ez a cikk a Power BI Desktopban dolgozó adatmodellezőkre irányul. Útmutatást nyújt az aktív vagy inaktív modellkapcsolatok létrehozásának időpontjához. Alapértelmezés szerint az aktív kapcsolatok szűrőket propagálnak más táblákba. Az inaktív kapcsolat azonban csak akkor propagálja a szűrőket, ha egy DAX-kifejezés aktiválja (használja) a kapcsolatot.
Feljegyzés
Ebben a cikkben nem foglalkozunk a modellkapcsolatok bemutatásával. Ha nem ismeri teljesen a kapcsolatokat, azok tulajdonságait vagy konfigurálását, javasoljuk, hogy először olvassa el a Modellkapcsolatok című cikket a Power BI Desktopban .
Az is fontos, hogy tisztában legyen a csillagséma kialakításával. További információ: A csillagséma és a Power BI fontossága.
Aktív kapcsolatok
Általában azt javasoljuk, hogy amikor csak lehetséges, definiálja az aktív kapcsolatokat. Kibővítik a modell használatának hatókörét és lehetőségeit a jelentéskészítők és a Q&A-val dolgozó felhasználók számára.
Vegyünk egy példát egy olyan importmodellre, amely a légitársaságok menetrend szerinti teljesítményének (OTP) elemzésére lett kialakítva. A modell egy Flight táblával rendelkezik, amely egy tény típusú tábla, amely járatonként egy sort tárol. Minden sor rögzíti a járat dátumát, a járat számát, az indulási és érkezési repülőtereket, valamint az esetleges késési időt (percekben). Van egy Repülőtér tábla is, amely egy dimenzió típusú tábla, amely repülőtérenként egy sort tárol. Minden sor a repülőtér kódját, a repülőtér nevét és az országot vagy régiót írja le.
Íme egy részleges modelldiagram a két tábláról.
A Flight és a Airport tábla között két modellkapcsolat van. A Flight tábla DepartureAirport és ArrivalAirport oszlopa a Repülőtér tábla Repülőtér oszlopához kapcsolódik. A csillagséma-kialakításban a Repülőtér tábla szerepkör-játék dimenzióként van leírva. Ebben a modellben a két szerepkör az indulási repülőtér és az érkezési repülőtér.
Bár ez a kialakítás jól működik a relációs csillagséma-tervekhez, a Power BI-modellekhez nem. Ennek az az oka, hogy a modellkapcsolatok a szűrőpropagálás elérési útjai, és ezeknek az útvonalaknak determinisztikusnak kell lenniük. A szűrőpropagálási útvonalak determinisztikus működésének biztosításáról további információt a kapcsolati útvonal kétértelműségének feloldásáról talál. Ezért – a példában leírtak szerint – az egyik kapcsolat aktív, míg a másik inaktív (a szaggatott vonal jelöli). Pontosabban az ArrivalAirport oszlop aktív kapcsolata. Ez azt jelenti, hogy a Repülőtér táblára alkalmazott szűrők automatikusan propagálásra kerülnek a Flight tábla ArrivalAirport oszlopára.
Ez a modellterv súlyos korlátozásokat ró az adatok jelentésére. Pontosabban nem lehet szűrni a Repülőtér táblát, hogy automatikusan elkülönítse az indulási repülőtér járatadatait. Mivel a jelentéskészítési követelmények magukban foglalják az indulási és érkezési repülőterek szerinti szűrést (vagy csoportosítást), két aktív kapcsolatra van szükség. Ha ezt a követelményt Power BI-modelltervre fordítja, az azt jelenti, hogy a modellnek két repülőtéri táblával kell rendelkeznie.
Íme a továbbfejlesztett modellterv.
A modell most két repülőtéri táblával rendelkezik: az indulási repülőtér és az érkezési repülőtér. A táblák és a Flight tábla közötti modellkapcsolatok aktívak. Figyelje meg azt is, hogy az Indulási repülőtér és az Érkezési repülőtér táblák oszlopnevei az Indulás vagy érkezés szóra vannak előtagban.
A továbbfejlesztett modellterv támogatja a következő jelentésterv elkészítését.
A jelentésoldal az indulási repülőtérként szűri Melbourne-t, a tábla vizualizációs csoportjait pedig érkezési repülőterek szerint.
Feljegyzés
Az Importálási modellek esetében a további táblázat nagyobb modellméretet és hosszabb frissítési időt eredményezett. Ezért ellentmond az importálásmodellezési cikk adatcsökkentési technikáiban leírt javaslatoknak . A példában azonban a csak aktív kapcsolatokra vonatkozó követelmény felülírja ezeket a javaslatokat.
Emellett gyakori, hogy a dimenzió típusú táblák a tény típusú táblasorok számához képest alacsony sorszámokat tartalmaznak. Így a modell méretének és frissítési idejének növekedése valószínűleg nem lesz túl nagy.
Újrabontási módszertan
Az alábbiakban bemutatjuk a modell újrabontásának módszertanát egyetlen szerepkörrel rendelkező dimenzió típusú tábláról egy szerepkörönként egy táblával rendelkező kialakításra.
Távolítsa el az inaktív kapcsolatokat.
Érdemes lehet átnevezni a szerepkört játszó dimenzió típusú táblát a szerepkör jobb leírásához. A példában a Repülőtér tábla a Flight tábla ArrivalAirport oszlopához kapcsolódik, ezért az át lett nevezve érkezési repülőtérként.
Hozzon létre egy másolatot a szerepkör-lejátszási tábláról, és adja meg a szerepkörét tükröző nevet. Ha importálási tábla, javasoljuk, hogy definiáljon egy számított táblát. Ha DirectQuery-tábla, duplikálhatja a Power Query-lekérdezést.
A példában a Departure Airport tábla a következő számított tábladefinícióval lett létrehozva.
Departure Airport = 'Arrival Airport'Hozzon létre egy aktív kapcsolatot az új tábla összekapcsolásához.
Fontolja meg a táblák oszlopainak átnevezését, hogy azok pontosan tükrözzék a szerepkörüket. A példában az összes oszlop előtagja az Indulás vagy az Érkezés szó. Ezek a nevek biztosítják, hogy a jelentésvizualizációk alapértelmezés szerint önleíró és nem egyértelmű címkéket tartalmazzanak. Emellett javítja a Q&A-élményt is, így a felhasználók egyszerűen megírhatják kérdéseiket.
Érdemes lehet leírásokat hozzáadni a szerepkör-lejátszási táblákhoz. (A A Mezők panelen egy leírás jelenik meg egy elemleírásban, amikor egy jelentés szerzője a kurzort a táblázat fölé viszi.) Így bármilyen további szűrőpropagálási részletet közölhet a jelentés szerzőivel.
Inaktív kapcsolatok
Adott körülmények között az inaktív kapcsolatok speciális jelentéskészítési igényeket is kielégíthetnek.
Most vegyük figyelembe a különböző modell- és jelentéskészítési követelményeket:
- Az értékesítési modell tartalmaz egy Sales táblát, amely két dátumoszlopot tartalmaz: OrderDate és ShipDate
- A Sales tábla minden sora egyetlen rendelést rögzít
- A dátumszűrők szinte mindig az OrderDate oszlopra vannak alkalmazva, amely mindig érvényes dátumot tárol
- Csak egy mértékhez van szükség dátumszűrő propagálására a ShipDate oszlopban, amely BLANK-okat tartalmazhat (a rendelés kiszállításáig)
- Nincs szükség a rendelési és szállítási dátum időszakok egyidejű szűrésére (vagy csoportosítására)
Íme egy részleges modelldiagram a két tábláról.
A Sales és a Date táblák között két modellkapcsolat van. A Sales (Értékesítés) táblában az OrderDate és a ShipDate oszlop a Dátum tábla Dátum oszlopához kapcsolódik. Ebben a modellben a Dátum tábla két szerepköre a rendelés dátuma és a szállítási dátum. Ez a kapcsolat az OrderDate oszlop aktív.
Mind a hat mértéknek – egy kivételével – az OrderDate oszlop alapján kell szűrnie. A Szállítási rendelések mértéknek azonban a ShipDate oszlop alapján kell szűrnie.
Itt található az Orders mértékdefiníciója. Egyszerűen megszámolja a Sales tábla sorait a szűrőkörnyezetben. A Date táblára alkalmazott szűrők az OrderDate oszlopba lesznek propagálva.
Orders = COUNTROWS(Sales)
Itt található a Szállítási rendelések mértékdefiníciója. Az U Standard kiadás RELATIONSHIP DAX függvényt használja, amely csak a kifejezés kiértékelése során aktiválja egy adott kapcsolat szűrőpropagálását. Ebben a példában a ShipDate oszlophoz való kapcsolatot használjuk.
Orders Shipped =
CALCULATE(
COUNTROWS(Sales)
,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)
Ez a modellterv a következő jelentésterv készítését támogatja.
A jelentésoldal 2019 negyedik negyedéve szerint szűr. A tábla vizualizációs csoportjai hónap szerint, és különböző értékesítési statisztikákat jelenít meg. A Rendelések és rendelések kiszállított mértékek eltérő eredményeket eredményeznek. Mindegyik ugyanazt az összegző logikát használja (a Sales tábla darabsorait), de eltérő Dátumtábla szűrőpropagálást.
Figyelje meg, hogy a negyedéves szeletelő tartalmaz egy BLANK elemet. Ez a szeletelőelem a táblázatbővítés eredményeként jelenik meg. Bár minden Sales táblasorhoz tartozik rendelési dátum, egyes sorok üres szállítási dátummal rendelkeznek – ezeket a rendeléseket még ki kell szállítani. A táblabővítés az inaktív kapcsolatokat is figyelembe veszi, így a BLANK-ok a kapcsolat több oldalán lévő BLANK-ok vagy adatintegritási problémák miatt is megjelenhetnek.
Feljegyzés
A sorszintű biztonsági szűrők csak aktív kapcsolatokon keresztül propagálnak. A sorszintű biztonsági szűrők akkor sem propagálják az inaktív kapcsolatokat, ha a UseRelationship explicit módon hozzáadva van egy mértékdefinícióhoz.
Ajánlások
Összefoglalva azt javasoljuk, hogy amikor csak lehetséges, definiáljon aktív kapcsolatokat, különösen akkor, ha sorszintű biztonsági szerepkörök vannak definiálva az adatmodellhez. Kibővítik a modell használatának hatókörét és lehetőségeit a jelentéskészítők és a Q&A-val dolgozó felhasználók számára. Ez azt jelenti, hogy a szerepkör-lejátszási dimenzió típusú 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 szerepjáték dimenzió típusú 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 U Standard kiadás RELATIONSHIP DAX függvénnyel aktiválhat egy adott kapcsolatot a releváns modellszámításokhoz
Kapcsolódó tartalom
A cikkhez kapcsolódó további információkért tekintse meg a következő forrásokat:
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: