Több-a-többhöz kapcsolatok alkalmazása a Power BI Desktopban

A Power BI Desktop több-a-többhöz számosságú kapcsolataival több-a-többhöz számosságú táblákat is összekapcsolhat, amelyek több-a-többhöz számosságot használnak. Egyszerűbben és intuitívabban hozhat létre két vagy több adatforrást tartalmazó adatmodelleket. A több-a-többhöz számosságú kapcsolatok a Power BI Desktopban a nagyobb összetett modellek képességeinek részét képezik. További információ az összetett modellekről: Összetett modellek használata a Power BI Desktopban

A több-a-többhöz számossággal való kapcsolat megoldása

Mielőtt a több-a-többhöz számosságú kapcsolatok elérhetővé váltak, a két tábla közötti kapcsolat a Power BI-ban lett definiálva. A kapcsolatban érintett táblaoszlopok közül legalább egynek egyedi értékeket kellett tartalmaznia. Gyakran azonban egyetlen oszlop sem tartalmaz egyedi értékeket.

Előfordulhat például, hogy két tábla országrégió nevű oszlopot tartalmazott. A CountryRegion értékei azonban egyik táblában sem voltak egyediek. Az ilyen táblák összekapcsolásához kerülő megoldást kellett létrehoznia. Az egyik kerülő megoldás lehet, ha további táblákat vezet be a szükséges egyedi értékekkel. A több-a-többhöz számosságú kapcsolatok esetén közvetlenül összekapcsolhatja az ilyen táblákat, ha több-a-többhöz számosságú kapcsolatot használ.

Több-a-többhöz számosságú kapcsolatok használata

Amikor két tábla közötti kapcsolatot határoz meg a Power BI-ban, meg kell határoznia a kapcsolat számosságát. Például a ProductSales és a Product közötti kapcsolat – a ProductSales[ProductCode] és a Product[ProductCode] oszlopot használva – több-1 értékként lesz definiálva. A kapcsolatot így határozzuk meg, mivel minden termék sok értékesítéssel rendelkezik, és a Product tábla (ProductCode) oszlopa egyedi. Ha több-1, 1-több vagy 1-1 számosságot határoz meg, a Power BI érvényesíti azt, így a kiválasztott számosság megegyezik a tényleges adatokkal.

Tekintse meg például a képen látható egyszerű modellt:

Képzelje el, hogy a Termék tábla csak két sort jelenít meg, ahogy az látható:

Tegyük fel, hogy a Sales tábla mindössze négy sorból áll, köztük egy C termék sorával. Hivatkozási integritási hiba miatt a C terméksor nem létezik a Product táblában.

A ProductName és price (a Product táblából), valamint az egyes termékek teljes mennyiségének (a ProductSales táblából) a következőképpen jelenik meg:

Ahogy az előző képen látható, a C termék értékesítéséhez egy üres ProductName sor van társítva. Ez az üres sor a következő szempontokat veszi figyelembe:

• A ProductSales tábla azon sorai, amelyekhez nincs megfelelő sor a Termék táblában. Hivatkozási integritási probléma merült fel, ahogy ebben a példában a C terméknél látjuk.

• A ProductSales tábla azon sorai, amelyeknél az idegen kulcs oszlopa null.

Ezen okok miatt az üres sor mindkét esetben olyan értékesítéseket tartalmaz, ahol a ProductName és az Price ismeretlen.

Néha a táblákat két oszlop összekapcsolja, de egyik oszlop sem egyedi. Vegyük például ezt a két táblát:

• A Sales tábla állapot szerint jeleníti meg az értékesítési adatokat, és minden sor tartalmazza az adott állapotban lévő értékesítés típusának értékesítési összegét. Az állapotok közé tartozik a CA, a WA és a TX.

  

• A CityData tábla a városok adatait jeleníti meg, beleértve a lakosságot és az államot (például CA, WA és New York).

  

Az Állapot oszlop most már mindkét táblában szerepel. Érdemes az egyes állapotok teljes értékesítéséről és teljes populációiról is jelentést készíteni. Probléma azonban van: az Állapot oszlop egyik táblában sem egyedi.

Az előző kerülő megoldás

A Power BI Desktop 2018. júliusi kiadása előtt nem tudott közvetlen kapcsolatot létrehozni ezek között a táblák között. Gyakori megkerülő megoldás a következő volt:

• Hozzon létre egy harmadik táblát, amely csak az egyedi állapotazonosítókat tartalmazza. A tábla a következő lehet:

  • Számított tábla (data analysis expressions [DAX]) használatával definiálva.
  • Egy Power Query-szerkesztő definiált lekérdezésen alapuló tábla, amely megjelenítheti az egyik tábla egyedi azonosítóit.
  • A kombinált teljes készlet.

• Ezután kapcsolja össze a két eredeti táblát az új táblával a gyakori Több-1 kapcsolatok használatával.

A megkerülő táblát láthatóan hagyhatja. Vagy elrejtheti a megkerülő táblát, hogy ne jelenjen meg a Mezők listában. Ha elrejti a táblát, a Több-1 kapcsolatok általában mindkét irányba szűrnek, és bármelyik táblából használhatja az Állapot mezőt. Az utóbbi keresztszűrés a másik táblába propagálja. Ez a megközelítés az alábbi képen látható:

Az államot (a CityData táblából) megjelenítő vizualizáció a teljes népességgel és a teljes értékesítéssel együtt a következőképpen jelenik meg:

Feljegyzés

Mivel ebben a kerülő megoldásban a CityData táblából származó állapotot használja a rendszer, csak a táblázatban szereplő állapotok jelennek meg, így a TX ki van zárva. A Több-1 kapcsolatoktól eltérően, míg a teljes sor tartalmazza az összes értékesítést (beleértve a TX-et is), a részletek nem tartalmaznak üres sort, amely az ilyen eltérő sorokat fedi le. Hasonlóképpen egyetlen üres sor sem fedi le azokat az értékesítéseket , amelyeknél null érték van az állam számára.

Tegyük fel, hogy a Cityt is hozzáadja a vizualizációhoz. Bár a városonkénti népesség ismert, a Város esetében megjelenített értékesítések egyszerűen megismétlik a megfelelő állam értékesítéseit. Ez a forgatókönyv általában akkor fordul elő, ha az oszlopcsoportolás nem kapcsolódik valamilyen összesített mértékhez, ahogyan az itt látható:

Tegyük fel, hogy az új Sales táblát az összes állam kombinációjaként definiálja, és láthatóvá tesszük a Mezők listában. Ugyanez a vizualizáció az államot (az új táblázatban), a teljes sokaságot és a teljes értékesítést jeleníti meg:

Mint látható, a TX – az értékesítési adatokkal, de az ismeretlen népességi adatokkal – és New Yorkdal együtt, ismert népességi adatokkal, de értékesítési adatok nélkül szerepelne. Ez a megkerülő megoldás nem optimális, és számos problémával rendelkezik. A több-a-többhöz számosságú kapcsolatok esetén az ebből eredő problémákat a következő szakaszban leírtak szerint oldjuk meg.

A kerülő megoldás implementálásával kapcsolatos további információkért tekintse meg a több-a-többhöz kapcsolatra vonatkozó útmutatást.

Használjon több-a-többhöz számosságú kapcsolatot a kerülő megoldás helyett

Közvetlenül összekapcsolhatja a táblákat, például a korábban ismertetetteket, anélkül, hogy hasonló kerülő megoldásokat kellene alkalmaznia. Most már beállíthatja a kapcsolat számosságát több-a-többhöz. Ez a beállítás azt jelzi, hogy egyik tábla sem tartalmaz egyedi értékeket. Ilyen kapcsolatok esetén továbbra is szabályozhatja, hogy melyik tábla szűri a másik táblát. Vagy alkalmazhat kétirányú szűrést is, ahol az egyes táblák a másikat szűrik.

A Power BI Desktopban a számosság alapértelmezés szerint a több-a-többhöz lesz, ha azt határozza meg, hogy egyik tábla sem tartalmaz egyedi értékeket a kapcsolatoszlopokhoz. Ilyen esetekben egy figyelmeztető üzenet megerősíti, hogy kapcsolatot szeretne beállítani, és hogy a módosítás nem az adatproblémák nem szándékos hatása.

Ha például közvetlenül a CityData és a Sales között hoz létre kapcsolatot – ahol a szűrőknek a CityData-ból az Értékesítések közé kell áramlanuk –, a Power BI Desktop megjeleníti a Kapcsolat szerkesztése párbeszédpanelt:

Az eredményként kapott Kapcsolat nézet ekkor megjeleníti a két tábla közötti közvetlen, több-a-többhöz kapcsolatot. A táblák megjelenése a Mezők listában és a vizualizációk létrehozásakor a későbbi viselkedésük hasonló a kerülő megoldás alkalmazásakor használthoz. A kerülő megoldásban a különálló állapotadatokat megjelenítő extra tábla nem lesz látható. A korábban leírtaknak megfelelően megjelenik egy állapot-, népesség- és értékesítési adatokat megjelenítő vizualizáció:

A több-a-többhöz számosságú kapcsolatok és a tipikusabb Több-1 kapcsolatok közötti főbb különbségek a következők:

• A megjelenített értékek nem tartalmaznak üres sort, amely a másik tábla eltérő sorait tartalmazza. Emellett az értékek nem veszik figyelembe azokat a sorokat, ahol a másik tábla kapcsolatában használt oszlop null értékű.

• Nem használhatja a függvényt RELATED() , mert több sor is kapcsolódhat egymáshoz.

• ALL() A táblafüggvény használata nem távolítja el a több-a-többhöz kapcsolat által más kapcsolódó táblákra alkalmazott szűrőket. Az előző példában az itt látható módon definiált mérték nem távolítja el a kapcsolódó CityData-tábla oszlopainak szűrőit:

  

  Az állapot, értékesítés és értékesítés teljes adatait megjelenítő vizualizáció a következő ábrát eredményezné:

  

A fenti különbségeket szem előtt tartva győződjön meg arról, hogy a használt ALL(<Table>)számítások , például a végösszeg %-a, a kívánt eredményeket adja vissza.

Szempontok és korlátozások

A több-a-többhöz számosságú és összetett modellekkel való kapcsolatok ezen kiadására van néhány korlátozás.

A következő élő Csatlakozás (többdimenziós) források nem használhatók összetett modellekkel:

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services
• Power BI szemantikai modellek
• Azure Analysis Services

Ha a DirectQuery használatával csatlakozik ezekhez a többdimenziós forrásokhoz, nem csatlakozhat egy másik DirectQuery-forráshoz, és nem kombinálhatja azokat importált adatokkal.

A DirectQuery használatának meglévő korlátozásai továbbra is érvényesek, ha több-a-többhöz számosságú kapcsolatokat használ. A tábla tárolási módjától függően most már számos korlátozás van táblánként. Egy importált tábla számított oszlopa például hivatkozhat más táblákra, de a DirectQuery-táblák számított oszlopai továbbra is csak ugyanazon a táblán lévő oszlopokra hivatkozhatnak. Egyéb korlátozások vonatkoznak a teljes modellre, ha a modellen belüli táblák DirectQueryek. A Gyors Elemzések és a Q&A szolgáltatás például nem érhető el a modellen, ha a benne lévő táblák rendelkeznek DirectQuery tárolási móddal.

Kapcsolódó tartalom

Az összetett modellekről és a DirectQueryről az alábbi cikkekben talál további információt:

• Összetett modellek használata a Power BI Desktopban
• Tárolási mód kezelése a Power BI Desktopban
• DirectQuery a Power BI-ban
• Power BI-adatforrások