Home
» Power BI
»
A DAX KISZÁMÍTÁSA függvény: problémák és megoldások
A DAX KISZÁMÍTÁSA függvény: problémák és megoldások
A mai blogban megvizsgáljuk, miért ne használja a DAX függvényt a kategóriánkénti átlag lekérésére, és kínálunk néhány alternatív megoldást a kívánt eredmények eléréséhez. Az oktatóanyag teljes videóját a blog alján tekintheti meg .
A kategóriánkénti átlag kiszámítása a DAX-ban furcsán bonyolult. A CALCULATE funkció használatával ezeknek a számításoknak a megoldására az új DAX-felhasználók a DAX-kódot nehezebben érthetik meg, mint kellene. A jó hír az, hogy vannak egyszerűbb megoldások erre a problémára.
Néhány hónappal ezelőtt bemutatkoztam a LuckyTemplates számára. DAX Ellenkultúrának hívták, ahol alternatív nézeteket adtam a DAX-ról.
Az egyik fő a CLCULATE funkció használatához kapcsolódik. Arról beszéltem, hogy miért ne használja a CALCULATE-t, különösen akkor, ha még nem ismeri a DAX-ot.
A CALCULATE egy nagyon összetett függvény, amelyet megérteni és használni kell. Bizonyos feltételezéseket tesz az adatmodellről, és sok bajba kerülhet.
Beleástam a Microsoft Running Total-hoz is, mert nem működik egytáblás helyzetekben, és csillagsémára van szüksége a megfelelő működéshez.
Tehát egy egyszerűbb alternatívát mutattam be, amely működik, akár csillagsémáról, akár egyetlen táblás modellről van szó, anélkül, hogy CLCULATE-re lenne szükség.
A DAX képlet SZÁMÍTÁSA
Ez a blog az Átlag kategóriánkénti gyors méréssel foglalkozik . Ha a LuckyTemplates asztalon tartózkodik, először lépjen a Mezők panelre, és hozzon létre egy Új gyorsmérőt .
A felugró Gyors mérés ablakban a Számítás legördülő menüben válassza az Átlag kategóriánként lehetőséget . Aztán húzd ? Értéket az Alapérték szövegmezőben, és Hónapot a Kategória mezőben.
Ezután kattintson az OK gombra, és egy ilyen kép jelenik meg.
Az x tengelyen vannak a negyedek – Negyed 1, 2, 3 és 4.
Az alábbiakban bemutatott minden hónapra vonatkozóan összegezni szeretné az értékeket, majd ezekből az értékekből átlagolni szeretné. Röviden az Átlag kategóriánként, ami blogunk témája.
Erre vonatkozó adatmodellünk nagyon egyszerű. Van egy táblázatunk a dátumokkal , a véletlenszerűen generált értékekkel és a hónap , a hónap rendezése és a negyedévekkel külön oszlopokban.
És ugyanez van a naptártáblázatban, a hónapban, a hónapos rendezésben és a negyedévben. Ez azt jelenti, hogy a dátumtáblázatból vagy az első táblázatból választhatjuk ki a negyedévet vagy a hónapot.
A jó hír az Átlag kategóriánként, hogy valójában attól függetlenül működik, hogy egyetlen táblázatmodellről vagy csillagsémáról van-e szó.
Ezekben a látványelemekben az első táblázatból származó negyedet használjuk…
…míg ez a dátumtáblázatunk Negyedjét használja. Akárhogy is működik.
De az Átlag kategóriánkénti probléma egyszerűen a DAX-kód.
Furcsa ez a DAX-kód, mert még ha DAX-szakértő is vagy, első pillantásra valószínűleg meg fogja zavarni. Furcsa módon egy CALCULATE utasítással van felépítve, szűrőzáradék nélkül, és csak egy összeg utasítást burkol.
Valójában ez egyike azoknak a kedvteléseknek, amikor olyan embereket látok a fórumokon, akik a CALCULATE-t használják, amely ok nélkül csak egy összeget csomagol. De ebben az esetben valójában oka van.
Valahányszor meglátom ezeket, megzavarja a fejem, mert ez csak azonnali jele annak, hogy fogalmuk sincs, mit csinálnak a CALCULATE funkcióval. Ezért azt javaslom, inkább maradjon távol tőle.
Kategóriánkénti átlag DAX-kód
A fent látható DAX kód a következőt használja: Ez a függvény nem a CLCULATE szegmensben található, ami ismét furcsává teszi. Állítólag ez a függvény a dokumentációja alapján CALCULATE utasításokban való használatra készült.
A kód is használja, amivel nem értek egyet. Soha ne használjanak az ÉRTÉKEKET, mert a különböző értékek hajlamosak üres sort visszaadni, ha nem egyező sor van. Ez sok gondot okozhat, de ez egy másik videó témája.
Lényegében az a helyzet, hogy egy ÉRTÉK függvényt használnak az összes kategóriánk lekéréséhez. Például az 1. negyedévben ez január, február és március. A VALUES szintén egy táblát ad vissza, de egy KEEPFILTER utasítást használnak annak érdekében, hogy első paraméterként érvényes legyen a -ban.
Ezenkívül megtartják a CALCULATE függvényt, hogy a KEEFILTERS kontextusában végre lehessen hajtani. Az AVERAGEX működése miatt a második kifejezést veszi fel, és az első kifejezés környezetében hajtja végre.
Akkor mi a probléma?
Összességében jól működik, de nem olyanok számára, akik újak a DAX-ban. Úgy gondolom, hogy a Microsoft nagyon lemaradt, amikor létrehozta ezt a gyors intézkedést, mert a gyors intézkedések állítólag a DAX-szal kezdők számára készültek.
A gyors mérések nagyszerű ötlet, például: „Írjunk néhány általános mérőszámot különböző számításokkal, mert még nem ismeri a DAX-ot, és nem tud mindent, amit a DAX-ról tudni kell.” De miért építették fel őket ilyen furcsa, bonyolult módon?
Hogyan kellene valakinek, aki új a DAX-ban, hogy megnézze ezt, és kitalálja, mi történik, amikor még valószínűleg a DAX-szakemberek is vakarják a fejüket ezen?
Szóval számomra elszalasztottak egy remek lehetőséget, hogy segítsenek az embereknek megtanulni a DAX-ot gyors intézkedéseikkel, ragaszkodva a CALCULATE-hoz, és át kellett ugrani, hogy a CALCULATE bekerüljön.
A könnyebb megoldás
A SUMMARIZE funkció használata
Mint korábban említettem, van egy jobb és egyszerűbb módja ennek.
Először hozzon létre egy táblázatváltozót a VAR_Table használatával . Ezután fogjuk a táblázatot, összegezzük hónaponként, létrehozunk egy Érték oszlopot, és összegezzük értékeinket.
Végül az AVERAGEX függvény segítségével vesszük értékeink átlagát .
Ez a kód egyszerűbb és sokkal logikusabb. Nincs benne SZÁMÍTÁS, amire amúgy nincs is szükséged.
Lehet, hogy találkozhatsz egy olyan blogcikkel, amely az ÖSSZEFOGLALÓT kritizálja. A blog szerint a SUMMARIZE belső működése meglehetősen bonyolult.
Azt is sugallja, hogy egy adott esetben bajba keverheti magát, de soha nem fog belefutni. Ez csak akkor történne meg, ha a számítás nagyon összetett számítást és nagyon nagy táblázatot tartalmaz. Az ÖSSZEFOGLALÁS csak akkor fog rossz eredményeket elérni.
Legalábbis a blogcikk ezt állítja. És nem baj, ha vissza akarsz térni a SUMMARIZE elől. Ebben az esetben használja helyette a függvényt.
A GROUPBY függvény használata
Senkinek sem okoz problémát a GROUPBY funkció használata, ezért tanuljuk meg azt is. Ismét hozzon létre egy táblázat változót a VAR_Table használatával. Ezután GROUPBY hónapot csoportosítunk, és létrehozunk egy Érték oszlopot.
Ezután a CURRENTGROUP segítségével alkalmazzuk , így működik a GROUPBY. Összegezzük az Értékünket, és ismét vegyük át rajta az ÁTLAGX-et .
A kódunknak így kell kinéznie.
Az eredmények összehasonlítása: SUMMARIZE vs GROUPBY vs CLCULATE DAX függvények
Most nézzük meg, hogy a parancsikonok ugyanazokat az eredményeket adták-e vissza.
Amint az az alábbi képeken is látható, mind a SUMMARIZE, mind a Better Average Per Category , mind a GROUPBY a Better Average Per Category 2 címkével ugyanazokat a számokat adja vissza.
Mindkét képletünk 3,4 ezer Q1-re, 3,6 000 Q2-re, 3,4 000 Q3-ra és 3,5 000 Q4-re ad vissza. És ismét egyetlen táblás adatmodellben dolgoznak a Quarters használatával a táblánkhoz.
Csillag sémában is működnek, ahol a dátumtáblázatban a Quarters-t használjuk.
Következtetés
Nem kell egy torz kontextus-logikára kényszeríteni magunkat csak azért, hogy a SZÁMÍTÁS a képleteinkbe kerüljön. Csak egyszerű szabványos DAX-függvényeket használjon, és ugyanazokat a dolgokat érheti el.
Valójában az esetek 80-90%-ában egyáltalán nincs ok arra, hogy a CALCULATE használatával foglalkozzunk. Ehelyett használhatja az SUMMARIZE és GROUPBY függvényeket, amelyek egyszerűbbek és logikusabbak.
Ha szeretné felfedezni ezt a PBIX-fájlt, már közzétettem a Quick Measures Gallery-ben, és a fájlnak Better Average Per Category nevet adtam . Csak görgessen le egészen az oldalon, hogy megtalálja a letölthető PBIX-fájlt, és játsszon önmagával.