DAX SZÁMÍTHATÓ Vs SZŰRŐ függvény

Mindkétéshatékony eszközök a DAX-lekérdezés adatainak manipulálására és elemzésére, de van néhány lényeges különbség, amelyeket fontos megérteni.

Ebben a blogban áttekintjük a CALCULATETABLE függvényt és annak , valamint megértjük, miben különbözik a FILTER függvénytől. A végére jobban megérti, hogyan válassza ki az adatelemzési igényeinek megfelelő funkciót.

A bemutatáshoz az alábbi DAX kódot használjuk.

A kód futtatásakor megjelenik egy táblázat, amely a márkát és a színt mutatja.

A Lekérdezési tervek lapon egy kódot kap, amely megfelel a CrossApply operátornak a .

Ugyanakkor láthatja, hogy a kód csak a termék színét és márkáját kéri le a Kiszolgálóidőzítések lapon.

Tartalomjegyzék

• A DAX Studio kiszolgáló időzítései eredménye a SZÁMÍTHATÓBAN
• SZÁMÍTHATÓ Lekérdezési terv a DAX Studio-ban
• Kontextus átmenet hasonló DAX-függvényekhez
  • Szerver időzítése
  • Lekérdezési terv
• Következtetés

A DAX Studio kiszolgáló időzítései eredménye a SZÁMÍTHATÓBAN

Példaként szűrjük a termék színét úgy, hogy csak a piros és/vagy a fekete legyen látható.

Ezt a SZŰRŐ funkció segítségével teheti meg. Amikor futtatja, a Kiszolgálóidőzítések azt mutatják, hogy a FILTER argumentum nincs alkalmazva a .

Ha azonban a SZÁMÍTHATÓ függvényt használja, a Kiszolgálóidőzítések lap lekérdezése azt mutatja, hogy az eredményeket a termék színe szerint szűrték.

SZÁMÍTHATÓ Lekérdezési terv a DAX Studio-ban

Nézzük meg az egyes függvények lekérdezési tervét.

A CALCULATETABLE a logikai lekérdezési terv első sorában található, mert a kód legfelső szintű függvénye, ezért nem függ semmilyen követelménytől.

Amikor elolvassa egy SZÁMÍTHATÓ függvény lekérdezési tervét, nem az első argumentummal kezdi. Először meg kell értenie a használt szűrőkörnyezetet. Tehát menjünk az 5. sorra.

Látható, hogy az alkalmazott szűrő miatt az operátor megköveteli a termékszín oszlopot. Ezután megvizsgálja ezt az oszlopot, és a Not IsEmpty Filter kombinációt használja a termék színének az egyes sorokhoz való viszonyítására.

A szűrőkontextus előkészítése után az argumentum végrehajtásra kerül.

Utólag visszatekintve, ha a FILTER funkciót használja, más lekérdezési tervet fog látni, így a CROSSJOIN argumentum a szűrőkörnyezet azonosítása előtt kerül végrehajtásra.

Ennek a megközelítésnek az a hátránya, hogy nem tolja el a szűrő állapotát a Storage Engine-hez. Nem fogja tudni használni a WHERE záradékot az xmSQL-ben, ami súlyos terhet ró a Formula Engine-re.

És amikor több táblával dolgozik, a CROSSJOIN függvény szűrőkombinációja hatalmas lesz. Ez lelassítja a DAX kód teljesítményét. Ezért a legtöbb esetben a CALCULATETABLE függvény használata javasolt.

Tehát ahelyett, hogy a Formula Engine összes számítását elvégezné, beillesztheti a szűrőfeltételt az XMSQL kód WHERE osztályába.

Kontextus átmenet hasonló DAX-függvényekhez

Szerver időzítése

Ez a koncepció a CALCULATE függvényre is alkalmazható. Példaként használjuk az alábbi DAX kódot.

Egy mérték körül automatikusan SZÁMÍTÁS funkció van.

A kód futtatásakor megjelenik egy táblázat, amely az egyes színekhez tartozó teljes értékesítési összeget mutatja.

A Kiszolgálóidőzítések lapon láthatja, hogy a kód két lekérdezést hajt végre. Az első lekérdezés az Értékesítési tábla értékesítési összegének kiszámítása a Termékek táblához képest.

Másrészt a második lekérdezés ismét lekéri a termék színét a Termékek táblából. Ez megfelel a DAX kódban szereplő függvénynek.

A Formula Engine a két lekérdezés adatgyorsítótárát egymás mellé helyezi. Először lekéri az értékeket a második adatgyorsítótárból, majd keresést hajt végre az első adatgyorsítótárban.

Lekérdezési terv

A Lekérdezési terv lapon a Logikai lekérdezési terv az argumentum miatt ellenőrzi a termék színét.

Ezután a VertiPaq a termék színétől függően összesíti a teljes értékesítési összeget. Végrehajtja a kontextus-átmenetet, amely a termék színértékét egyenértékű szűrőkörnyezetté alakítja.

A kontextus-átmenet által létrehozott szűrő egy DependOnCols tulajdonsággá lesz lefordítva a lekérdezési tervben. Miután a VertiPaq átvizsgálta a teljes értékesítés kiszámításához szükséges oszlopokat, megszorozza az értékesítési mennyiséget a nettó árral.

A teljes értékesítést ezután a rendszer pénznem adattípus formájában adja vissza. Végül az ADDCOLUMNS egy táblázatot ad vissza két oszloppal, amelyek a színt és a teljes értékesítési összeget tartalmazzák.

Következtetés

A lekérdezési terv jelentős hatással lehet egy lekérdezés teljesítményére, mivel a különböző lekérdezési tervek eltérő hatékonysággal rendelkezhetnek.

Ha a CALCULATETABLE és a FILTER függvényt használja egy DAX-lekérdezésben, a lekérdezési terv az adott forgatókönyvtől és számos tényezőtől függően eltérő lehet, például a használt konkrét képletkifejezéstől és a lekérdezőmotor képességeitől függően.

Általában célszerű tesztelni és összehasonlítani a különböző lekérdezési tervek teljesítményét annak érdekében, hogy meghatározzuk a leghatékonyabb megközelítést egy adott forgatókönyvhöz.

Minden jót,