Miért építsünk számított mezőt, ha csak egy oszlop összegét akarjuk megmutatni?

Régen számtalan válaszom volt rá, de mára annyira bolondbiztosra fejlesztették a Power BI-t, hogy gyakorlatilag csak pár maradt. Az egyik, hogy Excel pivot táblából nem tudjuk lekérdezni a modellt, ha nem csinálunk számított mezőket.

A hallgatók erre persze legyintenek, és meg is kérdezik, hogy miért kérdeznék le az adatmodellt Excelből amikor ott a barátságos és közkedvelt Power BI? Örülnek, hogy megszabadulhatnak végre az Exceltől, nem akarnak visszamenni hozzá.

Csakhogy az Excelnél nincs jobb ad-hoc elemzőeszköz. A barátságos és közkedvelt Power BI-ban még egy nyomorult Ctrl+C – Ctrl+V sincs, nem hogy cellaszintű képletek. Ad-hoc elemzésre (szerintem) alkalmatlan, úgyhogy nagyvállalati környezetben Ad-hoc elemzésre továbbra is az Excelt használjuk. Csak máshogy, mint eddig: az adatokat nem az Excelben tároljuk, hanem a Power BI-ban és az Excel-nek csak a rácsát, a pivot tábláját, és a kocka függvényeit használjuk. Pont azokat a szolgáltatásokat, amelyek a Power BI-ból hiányoznak, vagy nehezen használhatóak.

A másik, hogy addig boldogulnak csak el számított mezők nélkül, ameddig összegezni kell. De onnantól kezdve, hogy egy kicsit is bonyolultabb számított mezőt kell létrehoznunk – mondjuk egy súlyozott átlagot - már nem boldogulunk a vizualizációkba behúzott nyers oszlopokkal. A Power BI nem fogja tudni helyettünk kiszámolni a súlyozott átlagot. Szóval lehet húzni, halasztani, de úgyis meg kell csinálni a számított mezőket. Akkor miért halogassuk?

Összefoglalva: Aki nálam tanulta a Power BI-t, az tudja, hogy “Egy vizualizáció érték területére sosem húzunk oszlopot, csak számított mezőt (measure-t)” A tanulási pálya kezdetén ennek persze semmi jelentősége, de aki így csinálja, az jövőálló, mások, más eszközök által is használható adatmodellt épít.