Kétirányú szűrések Power BI-ban


A Power BI Desktopban és a 2016-os Analysis Services-ben jelent meg a táblák keresztszűrések lehetősége. Korábbi SSAS verziókban - és az Excelben a mai napig is - csak arra van lehetőségünk hogy egyirányba szűrjünk. A dimenzió táblából meg tudjuk szűrni a ténytáblákat de fordítva nem. Vagy másképpen fogalmazva az 1:n-es kapcsolatok 1-es oldala felől tudjuk szűrni a n-es oldalt fordítva nem.

Ez a korlát szűnt meg az SSAS 2016-ban és a Power BI desktopban és vált lehetővé a kétirányú szűrés (bidirectional cross-filtering), azaz megnyílt a lehetősége annak, hogy a ténytáblákból is szűrjük a dimenzió táblákat vagy másképpen fogalmazva az 1:n-es kapcsolatok n-es oldala felől tudjuk szűrni a 1-es oldalt.

Ez az újdonság alapértelmezett is lett a Power BI Desktopban magával hozva ennek minden előnyét és hátrányát. A kétségtelen előnyök között szerepel, hogy könnyen meg tudjuk vele oldani az n:m-es táblakapcsolatok problémáit (many to many relationships, bridge table Kimball irodalmában), illetve az is hogy a kezdő felhasználóknak így természetes a működése: minden szűr mindent… De itt ki is fújtak az előnyök...

A kétirányú kapcsolatok már egyszerű modelleknél félreértéseket okozhatnak. Adott például a következő faék egyszerűségű értékesítési adatmodell

Ebből a modellből előállítunk egy lekérdezést, amely régiónként mutatja a népességet és a forint forgalmat (Népesség a régió táblából, forgalom a forgalmi adatok táblából jön):

Majd szűrünk egy termékre, és megváltozik Dunántúl népessége:

Mi történt? Egy termékszűréstől hogy változhat meg  Dunántúl népessége? Úgy hogy a termék megszűrte a forgalmi adatok táblát azokra a sorokra, ahol volt értékesítés az adott termékből. Ez eddig OK. Csakhogy a termékből nem minden megyében értékesítettek. A forgalmi adatok tábla szűrve lett azokra a megyékre, ahol volt értékesítés és a szűrést megörökölte a Régió tábla is és a benne számolt népesség számított mező csak a szűrt megyékre számolta ki a népesség összegét…

Hogyan lehet elkerülni a problémát?

Egyirányúvá kell tenni a régió tábla és a forgalmi adatok tábla közti kapcsolatot:

És a modellünk jól fog számolni:

Összefoglalva: Nagyon örülünk a kétirányú kapcsolatoknak, de annak, hogy alapértelmezetté tették a Power BI Desktopban már kevésbe. Ahelyett ugyanis, hogy a felhasználókat rákényszerítené a helyes adatmodell elkészítésére ad egy kerülőutat, ami technikai oldalról nézve mindig működik, de nem mindig hozza a várt eredményt.

Mi a megoldás? 

  • Használjunk mindig egyirányú kapcsolatot addig amíg meg nem értjük hogyan működnek a szűrések a kapcsolatok mentén
  • A kapocslatok többes oldalán található oszlopot rejtsük el a felhasználók elöl,
  • és használjuk a CROSSFILTER() és USERRELATIONSHIP() függvényeket azoknál a mutatószámoknál, ahol szeretnénk élvezni a keresztszűrés előnyeit.

Ráadásul ez a módszer működik Power Pivotban is :-)

Hasznos irodalom: Bidirectional cross-filtering in SQL Server Analysis Services 2016 and Power BI Desktop

POWER BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2017. november 30.-i Power BI workshopra. Részletek >>

  

ÖNKISZOLGÁLÓ BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2017. november 23.-i Önkiszolgáló BI workshopra. Részletek >>

  

Elválasztó

Már készül a következő cikk. Iratkozzon fel az értesítőre.

|

Kővári Attila
2017. április 10.
Címkék:

Szóljon hozzá!

Szabály: Legyen kedves, segítõkész és vállalja a nevét.
A mező tartalma nem nyilvános.
  • A web és email címek automatikusan linkekké alakulnak.
  • Engedélyezett HTML elemek: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • A sorokat és bekezdéseket automatikusan felismeri a rendszer.
ANTI SPAM
A robot regisztrációk elkerülésére.
Image CAPTCHA
Figyeljen a kis és nagybetűk használatára

POWER BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2017. november 30.-i Power BI workshopra. Részletek >>