Megosztás a következőn keresztül:

Aktív és inaktív kapcsolatokra vonatkozó útmutató

  • Cikk

Ez a cikk adatmodellezőként célozza meg Önt, aki a Power BI Desktoppal dolgozik. Ú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.

Jegyzet

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 modellkapcsolatokat a Power BI Desktop című cikkben.

Az is fontos, hogy tisztában legyen a csillagséma kialakításával. További információért lásd: Értsd meg a csillagsémát és annak fontosságát a Power BI szempontjából.

Aktív kapcsolatok

Általában azt javasoljuk, hogy amikor csak lehetséges, határozzon meg 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-vel dolgozó felhasználók számára.

Vegyünk egy példát egy Import modellre,, amely a légi járatok időalapú teljesítményének (OTP) elemzésére szolgál. A modell egy Flight táblával rendelkezik, amely egy ténytá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 Airport tábla is, amely egy dimenzió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.

két táblát tartalmazó modellt ábrázoló diagram: Flight and Airport. A kapcsolat kialakítását a következő bekezdés ismerteti.

A Flight és Airport táblák között két modellkapcsolat van. A Flight táblában a DepartureAirport és ArrivalAirport oszlopok a Airport tábla Airport oszlopához kapcsolódnak. A csillagséma-tervezésben a Airport tábla szerepkör-játszás dimenzióként. Ebben a modellben a két szerepkör indulási repülőtér és é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-modellek esetében nem működik jól. 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énekfeloldásával kapcsolatban talál. Ezért – ahogyan az ebben a példában is látható – az egyik kapcsolat aktív, míg a másik inaktív (a szaggatott vonallal jelölve). Pontosabban az aktív ArrivalAirport oszlophoz való viszony, ami azt jelenti, hogy a Airport 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 Airport táblázatot, hogy automatikusan elkülönítse az indulási repülőtér járatadatait. A jelentéseknek az indulási és érkezési repülőterek szerint kell szűrnie (vagy csoportosítania)egyidejűleg, ezért 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.

diagram egy négy táblát tartalmazó modellt ábrázol: Dátum, Járat, Indulási repülőtér és Érkezési repülőtér.

A modell most két repülőtéri táblával rendelkezik: Departure Airport és Arrival Airport. A táblák és a Flight tábla közötti modellkapcsolatok aktívak. Figyelje meg azt is, hogy a Departure Airport és Arrival Airport táblák oszlopnevei az indulási vagy Érkezésiszó előtaggal vannak elnevítve.

A továbbfejlesztett modellterv támogatja a következő jelentésterv elkészítését.

jelentésoldalt ábrázoló diagram két szeletelővel és egy táblavizualizációval rendelkezik. A szeletelők a hónap és az indulási repülőtér.

A jelentés oldala Melbourne repülőtér szerint szűr, és a táblázat az érkezési repülőterek szerint csoportosít.

Jegyzet

Az importálási modellek esetében egy másik dimenziótábla hozzáadása nagyobb modellméretet és hosszabb frissítési időt eredményezett. Ezért ellentmond a Importálási modellezés adatcsökkentési módszerei cikkben ismertetett 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áblák alacsony sorszámokat tárolnak a ténytáblák sorszámához képest. Így a modell méretének és frissítési idejének növekedése valószínűleg nem lesz túl nagy.

Átstrukturálási módszertan

Az alábbiakban bemutatjuk a modell újrabontásának módszertanát egyetlen szerepkör-játék dimenziótábláról egy olyan kialakításra, amely szerepkörönként egy táblát.

  1. Távolítsa el az inaktív kapcsolatokat.

  2. Fontolja meg a szerepjáték dimenziótáblájának átnevezését annak szerepének jobb leírása érdekében. A jelen cikkben szereplő példában a Airport tábla a Flight tábla ArrivalAirport oszlopához kapcsolódik, ezért Arrival Airportnéven lett átnevezve.

  3. 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. Ez egy importálási tábla esetén javasoljuk, hogy hozzon létre 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'

  4. Hozzon létre egy aktív kapcsolatot az új tábla összekapcsolásához.

  5. Fontolja meg a táblák oszlopainak átnevezését, hogy azok pontosan tükrözzék a szerepkörüket. A cikkben szereplő példában az összes oszlop neve az Indulási vagy Érkezésiszóval kezdődik. 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 felületet is, így a felhasználók egyszerűen írhatnak pontos kérdéseket.

  6. Érdemes lehet leírásokat hozzáadni a szerepkör-lejátszási táblákhoz. (Az Adat 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 más szűrőpropagálási adatokat is továbbíthat a jelentéskészítőknek.

Inaktív kapcsolatok

Adott körülmények között az inaktív kapcsolatok adott jelentéskészítési igényeket is kielégíthetnek.

Fontolja meg a különböző modell- és jelentéskészítési követelményeket:

  • Az értékesítési modell egy Sales táblát tartalmaz, amely két dátumoszlopot tartalmaz: OrderDate és ShipDate.
  • A Sales tábla minden sora egyetlen sorrendet rögzít.
  • A dátumszűrők szinte mindig a OrderDate oszlopra vannak alkalmazva, amely mindig érvényes dátumot tárol.
  • Csak egy mértékhez szükséges, hogy a dátumszűrő hatását érvényesítsük a ShipDate oszlopban, amely üres értékeket tartalmazhat (a rendelés kiszállításáig).
  • Nem szükséges egyszerre szűrni (vagy csoportosítani) a rendelési és szállítási dátumidőszakokat.

Íme egy részleges modelldiagram a két tábláról.

diagram egy két táblát tartalmazó modellt ábrázol: Értékesítés és Dátum. A Sales tábla hat mértéket tartalmaz.

A Sales és Date táblák között két modellkapcsolat van. A Sales táblában a OrderDate és ShipDate oszlopok a Date tábla Date oszlopához kapcsolódnak. Ebben a modellben a Date tábla két szerepköre rendelési dátum és szállítási dátum. Ez a kapcsolat az aktív OrderDate oszlophoz.

Mind a hat mértéknek – egy kivételével – a OrderDate oszlop alapján kell szűrnie. A Orders Shipped mértéket azonban a ShipDate oszlop alapján kell szűrni.

Íme a Orders mértékdefiníció. Egyszerűen megszámolja a Sales tábla sorait a szűrőkörnyezetben. A Date táblára alkalmazott szűrők a OrderDate oszlopba propagálásra kerülnek.

Orders = COUNTROWS(Sales)

Íme a Orders Shipped mértékdefiníció. A USERELATIONSHIP DAX függvényt használja, amely egy adott kapcsolat szűrőpropagálását aktiválja, de csak a kifejezés kiértékelése során. 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.

Egy jelentésoldalt ábrázoló diagram, amely tartalmaz egy szeletelőt és egy táblázatvizualizációt. A szeletelő a Negyedévet jelöli, a táblázat pedig a havi értékesítési statisztikákat sorolja fel.

A jelentésoldal a 2019. negyedik negyedévalapján szűr. A tábla vizualizáció hónap szerint csoportosít és különböző értékesítési statisztikákat jelenít meg. A Orders és Orders Shipped intézkedések eltérő eredményeket eredményeznek. Mindegyik ugyanazt az összegző logikát használja (a Sales tábla sorainak megszámlálását), de különböző Date táblaszűrő propagálását.

Figyelje meg, hogy a negyedéves szeletelő tartalmaz egy BLANK lehetőséget. Ez a szeletelőbeállítás a táblabővítésénekeredményeként jelenik meg. Bár minden Sales táblasornak érvényes rendelési dátuma van, 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.

Jegyzet

A sorszintű biztonsági (RLS) szűrők csak aktív kapcsolatokon keresztül propagálnak. Az RLS-szűrők soha nem érvényesülnek inaktív kapcsolatok esetén, még akkor sem, ha egy mérték a USERELATIONSHIP DAX-függvényt használja.

Ajánlások

Javasoljuk, hogy amikor csak lehetséges, határozzon meg aktív kapcsolatokat, különösen akkor, ha az adatmodellhez RLS-szerepkörök vannak definiálva. 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-vel dolgozó felhasználók számára. Ez 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 megközelí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.

Kapcsolódó tartalom

A cikkhez kapcsolódó további információkért tekintse meg a következő forrásokat: