Summarize By Power BI tulajdonság buktatói

Egy oszlop Summarize By tulajdonsága azt mondja meg, hogy az adott oszlop a kimutatásokban hogyan legyen aggregálva.

Megj.: A cikkben végig „Summarize By” néven fogok hivatkozni a jelenségre, mert az SSAS Tabularban a mai napig így hívják ezt az oszlop tulajdonságot, Power BI-ban viszont verzióról verzióra változott a a neve. Volt már Summarize By, volt Default Summarization, most éppen Summarization, de a lényeg ugyanaz: Egy oszlop tulajdonságáról beszélünk, amely megmondja a Power BI vizualizációinak, hogy az oszlopot behúzva egy vizualizációba, hogyan összegezze azt fel.

Power BI Summarize By property

 

Látszólag ez a tulajdonság semmilyen hatással sincs ránk hiszen mi a legjobb gyakorlatoknak megfelelően azokra az oszlopokra, amelyeket aggregálva is meg akarunk jeleníteni, számított mezőt (Measure-t) építünk. Sosem használunk olyan úgynevezett implicit measure-öket, amelyek úgy jönnek létre, hogy egy oszlopot behúzunk a vizualizációk érték területére. 

Vannak azonban olyan numerikus mezők, amelyek – bár számként vannak tárolva – a valóságban szövegek is lehetnek. Ilyen például az év, az adóazonosító jel, a cikkszám, vagy egyéb azonosítók. A Power BI ezeket a numerikus oszlopokat ugyanúgy kezeli, mint a forint vagy doboz forgalmakat. És ennek vannak mellékhatásai:

Slicer

Ha egy behúzzuk a számként tárolt évet, adóazonosítót, egyéb azonosítót egy szeletelőbe (Slicer) akkor a Power BI – mivel folytonos halmaznak gondolja – ezért csuszkát tesz ki. Pedig ezek diszkrét halmazok.

Tábla (vizualizáció)

Ha szeretnénk egy olyan kimutatást, amely országrész és év bontásban mutatja a forgalmat, akkor össze fogja adni az éveket, hiszen számként kezeli őket:

Ez fel fog tűnni, de ha az azonosítókat adja össze, akkor már korántsem biztos hogy feltűnik. Hibaüzenet nincs, csak hibás azonosítók.

Filter

Ha a fenti vizualizációt szűrni akarjuk 2020-as sorokra akkor egy sort sem fogunk visszakapni. Nem azért, mert 2020-ban nem volt forgalom, hanem azért mert az évek összege sehol sem 2020.

Ebben a szituációban rá fogunk jönni, hogy baj van, de ha az oszlopokon azonosítók vannak és rászűrünk egy azonosítóra és nem kapunk vissza eredményt, akkor bug-osnak fogjuk mondani a Power BI-t: „Az nem létezik, hogy nincs benne ez az azonosító”. Én is így futottam bele egy on-the-job Power BI tréningen anno, és most újra szembejött. Úgyhogy bele is teszem a készülő haladó Power BI tanfolyamba, mert az ártatlan kis Summarize By tulajdonság elég nehezen észrevehető hibát eredményezhet. 

Összefoglalva: A Best Practice az, hogy

  1. minden olyan oszlopra, amely aggregálható számokat tartalmaz számított mezőt (Measure-t) építünk
  2. A measure-ök alapját képező oszlopokat elrejtjük a felhasználók elöl
  3. És az összes többi numerikus oszlop alapértelmezett aggregációs módját (Summarize By) át billentjük None-ra (SSAS Tabular), vagy Don’t  Summarize-ra (Power BI).

Egy szép Power BI adatmodell mezőlistájában ritkán láthatunk ilyen szumma jeleket:

Vagy azért, mert az aggregálható oszlopokra számított mezőt építünk, és az oszlopot elrejtjük, vagy azért mert a szűrésre használt attribútum Summarize By tulajdnonságát none-ra állítjuk.

Kővári Attila - BI projekt

POWER BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2025. február 27.-i Power BI workshopra vagy rendeljen kihelyezett képzést! Részletek >>

 

Új hozzászólás