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
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,
Ebből a blogból megtudhatja, hogyan mentheti automatikusan az e-mail mellékleteket a SharePointba, majd törölheti az e-maileket a Power Automate segítségével.
A Microsoft LuckyTemplates irányítópult 18 legjobb példája 2023
Ismerje meg, hogyan hozhat létre <strong>Power Automate</strong> folyamatokat a semmiből. Sablon használata helyett mi magunk hozzuk létre a kiváltó okokat és a műveleteket.
4 módszer a Pi használatára a Pythonban példákkal
Ebben az útmutatóban bemutatom, hogyan lehet Pénzügyi információk mátrixát létrehozni a Profit és veszteség (P&L) kimutatással a LuckyTemplates alkalmazásban.
Fedezze fel, hogyan lehet dinamikusan egyesíteni oszlopokat a Power Query Table.CombineColumns függvény segítségével.
Ismerje meg, hogyan adhatjuk hozzá és szinkronizálhatjuk SharePoint-fájljainkat az asztalon és a OneDrive-on.
Tudja meg, miért fontos egy dedikált dátumtáblázat a LuckyTemplatesben, és ismerje meg ennek leggyorsabb és leghatékonyabb módját.
Ez a rövid oktatóanyag kiemeli a LuckyTemplates mobil jelentési funkcióját. Megmutatom, hogyan készíthet hatékony jelentéseket mobileszközökön.
Ebben a LuckyTemplates bemutatóban olyan jelentéseket tekintünk át, amelyek professzionális szolgáltatáselemzést mutatnak be egy olyan cégtől, amely több szerződéssel és ügyfél-elkötelezettséggel rendelkezik.
