Sorkontextus és szűrőkontextus egy LuckyTemplates DAX-kódban

Ebben az oktatóanyagban a DAX kód egy darabját fogjuk megnézni. Lehet, hogy már használtál ilyesmit. Vagy találkozhat vele, és megzavarhatja, hogyan működik ez a kód, és hogy a sorkontextus és a szűrőkontextus hogyan kölcsönhatásba lép egymással egyetlen DAX-kódban. Akárhogy is, ez az oktatóanyag a fentieket részletesen megvizsgálja. Az oktatóanyag teljes videóját a blog alján tekintheti meg.

Először magát a kódot nézzük meg. Ezután áttekintjük az elméleti részt, hogy jobban megértsük. Végül mindent a kulisszák mögé nézünk a használatával.

Az adatmodell, amelyet használni fogunk, alapvetően egy egyszerű értékesítési adatmodell, amely tartalmazza a dátumokat, az értékesítéseket és a Termékek táblát. Az Értékesítési tábla minden adott napra vonatkozóan tartalmazza a tranzakciókat. A Termékek táblázat az egyes napokon a termékek értékesítési információit tartalmazza. A Dátumok táblázat csak néhány oszlopot tartalmaz az oktatóanyag céljaira.

Minket csak a Dátumok tábla érdekel, de az Értékesítési táblát és a Termékek táblát fogjuk használni, hogy elmagyarázzuk, hogyan terjed a szűrőkontextus és a sorkontextus kapcsolatok segítségével.

Tartalomjegyzék

• Sorkontextus és szűrőkontextus egy futó összmértékben
• A DAX Studio használata a sorkontextus megértéséhez és a szűrési kontextushoz
• Következtetés

Sorkontextus és szűrőkontextus egy futó összmértékben

Most hozzunk létre egy futó teljes mértéket, mert mind sor-, mind szűrőkontextusokat tartalmaz. Ez egy alapvető futó összmérték, ahol a COUNTROWS-t használom a SZŰRŐNÉL, és az ALL függvényt a Dátum táblában lévő összes év visszaadásához. Ha ezt az intézkedést beviszem az alábbi táblázatba, láthatja, hogy azt az eredményt kapjuk, amit várunk.

Most próbáljuk meg elemezni, hogyan működik ez a DAX-kód.

A mértéken látható, hogy először COUNTROWS-unk van, de nem ez az első függvény, amely kiértékelésre vagy végrehajtásra kerül. Ezután megvan a FILTER funkció, majd az ALL. Az első dolog az értékelési sorrendben az ÖSSZES. Az ALL visszaadja a Dátumok naptári évszámának összes egyedi értékét, figyelmen kívül hagyva az ALL függvényen kívüli szűrőkörnyezetet.

Tehát a metrikákban van a Naptári év száma oszlop, és ez aktívan szűri ezt az oszlopot. De mivel az ALL figyelmen kívül hagyja a meglévő szűrőkörnyezetet, megkapjuk az oszlop összes egyedi értékét.

A második argumentumban, a sorkontextusban azt írtuk, hogy a dátumok naptári évszáma kisebb legyen, mint a MAX dátumok naptári év száma. Most, ha Ön kezdő, és még mindig próbálja megérteni és megtanulni a DAX-ot, akkor azt gondolhatja, hogy a bal oldalon és a MAX függvényen belüli hivatkozások is ugyanabba az oszlopba tartoznak, és ugyanazt a táblázatot jelentik. MINDEN funkció.

De ez nem igaz. A sorkontextus egyetlen része, amely az ALL függvényhez tartozik, az, amelyik a bal oldalon található. A MAX-on található egy szűrőkontextuson belül kerül kiértékelésre, nem pedig a sorkontextusban.

Tehát a FILTER megpróbál létrehozni egy sorkörnyezetet az első argumentumban megadott táblázatban, és a kódnak ez a része valójában az adott sorkontextusból származik. Tehát minden sor a FILTER azt a táblát iterálja, amely az ALL-ban van, és ezután hozzáférhetünk az összes éppen iterált értékhez.

Tehát az első iterációban csak egy értékünk van. A második iterációban megkapjuk a második értéket. De amikor a MAX értéket írjuk, az független attól a sorkontextustól, amelyet a FILTER funkcióval hozunk létre. Tehát a MAX a szűrőkontextusban kerül kiértékelésre, amelyet a mátrixban használt aktuális évszám hoz létre.

Amikor 2006-nál tartunk, a MAX 2006-ot ad vissza, míg az aktuális sor 2006, 2007 vagy 2008 lehet. A FILTER azt a táblát adja vissza, amely megfelel a második argumentumban megadott kritériumoknak. Ha 2007-re lépünk, a MAX 2007-et fog visszaadni. 2008-ban 2008-at. És attól függően, hogy az összes érték kisebb, mint a MAX függvény által visszaadott érték, a FILTER egy asztal.

Annak bizonyítására, hogy a MAX nem függ a sorkontextustól, szétválaszthatjuk ezt a DAX-kódrészletet több változóra. És akkor meg fogjuk érteni, hogy a bal és a jobb oldali oszlophivatkozás nem ugyanaz.

Tehát hozzunk létre egy változót.

Amint az alábbi mértéken látható, három változót hoztam létre (). Végül hozzáadtam a FILTER kódot egy Result változóval, amely használja. Amikor ezt a mértéket használom az alábbi táblázatban, látni fogja, hogy semmi sem változik. Az eredmények továbbra is ugyanazok. Még mindig ugyanazt a futóösszeget kapjuk, mint korábban.

Ha visszamegyünk a kódhoz, és megpróbáljuk lekérni az első változó értékét, és ezt megerősítjük, láthatjuk, hogy minden sornál ugyanazt az évet kapjuk.

Tehát remélhetőleg sikerült elmagyaráznom, hogy a MAX függvény ebben a kódban valójában nem függ az értékek valódi kontextusától. Ha pedig egyszerűsíteni szeretné az értékelési környezet megértését, a kódot mindig több változóra bonthatja, hogy megértse a kiértékelési sorrendet és a kód végrehajtásának módját.

Most egy olyan forgatókönyvet szeretnék bemutatni, amelyben a MAX függvény a FILTER függvény által létrehozott sorkontextustól függ .

Tehát térjünk vissza ehhez a mértékhez. Lemásoljuk ezt, és a Last Visible Year helyett nekem leszMAX Dátumok Naptár év száma. Amikor ezt beviszem a mátrixba, láthatod, hogy ürességet kapunk.

Miért?

A helyzet az, hogy az összes évet iteráljuk, és amit a CALCULATE tesz, az az, hogy a jelenleg iterált sort egyenértékű szűrőkörnyezetté alakítja.

Ha egyenlőségjelet írok ide, akkor láthatja, hogy hét, hét és hét kapunk.

Miért?

Hadd készítsek egy új számítási táblázatot, hogy könnyen megérthesd, mi történik.

Megyek, csinálok egy új táblázatot. Következő, írokaz ÖSSZES dátum naptári évszáma felett. Ezután írom a Max Year-t, majd a CALCULATE-t használom a dátumok naptári évszámának MAX-a fölé. És most láthatja, hogy minden sornál ugyanazt az értéket ismételjük.

Mivel ezek a számok szigorúan nem kisebbek önmaguknál, ürességet kapunk. De ha egyenlőt (=) használunk, akkor azt mondjuk, hogy minden 2011-nél kisebb érték hetest kap.

Sőt, még ha mértékhivatkozást használ is, mint például a Max Year, ez a kód nem fog működni.

Ha a megerősítésre kattintok, láthatja, hogy továbbra sem kapunk semmit. Ez azért van így, mert amikor Max Year-t írunk, akkor egyszerűen a MAX DÁTUMOK KISZÁMÍTÁSA Naptári évszámot írunk.

A mértékhivatkozáson kívül mindig van egy CLCULATE. Tehát ez az intézkedés kontextus-átmenetet kezdeményez, amely az aktuálisan iterált sort szűrőkontextussá alakítja.

De ha kötött vagy, és mértékhivatkozást kell használnod, akkor ezt a mértéket egy változóban tárolhatod. És amint azt talán tudod, a változók állandóak, és nem hozhatnak létre kontextus-átmenetet. Így nem tudja átalakítani a sorkontextust szűrőkontextussá.

Tehát ez egy gyors bemutató annak, hogy egy sorkontextus és egy szűrőkontextus hogyan hatnak egymásra egy DAX-kódban.

Most menjünk a DAX Stúdióba, hogy megértsük, mi történik a színfalak mögött.

A DAX Studio használata a sorkontextus megértéséhez és a szűrési kontextushoz

Lépjünk a Külső eszközökbe, és indítsuk el a DAX Studio alkalmazást. Csatlakoznunk kell a LuckyTemplates fájlhoz a Query Plan és a Server Timings segítségével .

Ezután létrehozok egy lekérdezési mértéket. A Dátumok táblázatba beírom a MÉRÉS MEGHATÁROZÁSA Dátumok Összesen. És akkor az eredeti kódot fogom használni, ami nálunk volt.

Mivel egy táblát kell visszaadnunk, írhatjuk ÉRTÉKELÉS. Végül elkészítjük a táblázatot az ÖSSZEFOGLALÓK segítségével. Tehát fel fogjuk írni a Dátumok Naptár Év számát, és a virtuális oszlopot, ami a Futóösszeg lesz. És akkor írhatok olyasmit, mint a DT a DAX Studio kulcsszóként.

Ha végrehajtom ezt a kódot, láthatja, hogy a kód kész, és továbbra is ugyanazt az eredményt kapjuk, mint amit a LuckyTemplatesben láttunk.

Most menjünk a lekérdezési tervhez, hogy megértsük, mi történik a színfalak mögött. Nézzük meg, hogy a MAX függvény valóban függ-e a sorkontextustól vagy sem. Lépjünk a logikai lekérdezési tervre, mert a fizikai lekérdezési terv általában összetettebb, és kissé nehezen olvasható.

Látható, hogy az első sorban az első operátor a GroupSemiJoin , és ezt használja a SUMMARIZECOLUMNS két oszlop közötti belső illesztés létrehozására.

Ezután az oszlopok összekapcsolásához ott van a Scan_Vertipaq , amely az elemzési szolgáltatásokon belüli tárolómotor. Láthatjuk, hogy azt írja, hogy szükségünk van egy oszlopra, ami a dátumok naptári év száma. A LuckyTemplates-ben láthatja, hogy a mátrixon ez a naptári évszám oszlop található, amely hozzáférésként szolgál jelentésünkhöz.

Ezután a COUNTROWS függvény felső szintű operátorként szerepel a mérésünkben, majd a COUNTROWS meghívja aa szűrőhöz. Ismét van egy Scan_Vertipaq , amely szerint a RequiredCols a Dátumok naptári év száma.

A 2. és 5. sor megegyezik, de az első Scan_Vertipaq nullával, míg a második eggyel van jelölve. Ez azt jelenti, hogy az általunk elért oszlop az ALL függvény segítségével külön lesz kivonva attól az oszloptól, amely a SUMMARIZECOLUMNS függvényben található.

Ezután van egy LessThan operátor. A következő sorban láthatjuk, hogy van egy összehasonlítás a sorkontextus és a MAX függvény között .

Ezt követi a Max_Vertipaq . Tehát valójában a Max értéket kinyerjük a tárolómotorból. Jobb oldalt láthatja, hogy ez áll: DependOnCols Dátumok Naptári Év száma. Ez a legfontosabb dolog, amire emlékeznünk kell. Korábban azt mondtam, hogy a MAX függvénynek nincs függősége a sorkontextustól, és ez az, ami valójában ezt bizonyítja.

És itt azt írja, hogy nulla.

Hol találtuk a nullát?

A tetején (a második sor), amely az ÖSSZEFOGLALÓKHOZ készül. Ez azt jelenti, hogy a MAX függvény nem függ a sorkontextustól, de valójában attól függ, hogy melyik oszlopban (naptári évszám) található a táblázatban. Tehát ez a táblázat valójában a szűrőkörnyezetet hozza létre.

Röviden, a MAX függvény a szűrőkontextustól függ, és nem a sorkontextustól.

Ezután láthatja, hogy a Max_Vertipaq kiszámításához van egy Scan_Vertipaq , amely szerint a DependOnCols nulla (0) Date Calendar Year Number. Aztán van még néhány olyan oszlop, amelyhez oszlopokra van szükség.

Most nézzük a kód változó verzióját. A LastVisibleYear visszaadása helyett a COUNTROWS verziót vagy a Result változót fogom visszaadni, és láthatja, hogy továbbra is ugyanazt az eredményt kapjuk.

Ha megnézzük a Lekérdezési tervet, láthatja, hogy egy kicsit hosszabb, de sokkal könnyebben olvasható.

Végül itt van a kód kiszámított verziója is

És így néz ki a logikai lekérdezési terve.

Következtetés

Ebben az oktatóanyagban elmagyaráztam, hogy egy adott függvény hogyan tud kölcsönhatásba lépni a sorkontextussal, és hogyan nem. Azt is megmutattam, hogy ebben az esetben a MAX hogyan lett kiértékelve a szűrőkontextusban, nem pedig a sorkontextusban.

Fontos mindig emlékezni arra, hogy a szűrőkontextus a teljes modellt szűri, a sorkontextus pedig csak az adott táblát iterálja, és soha nem szűri a modellt. A szűrőkontextus nem iterál táblázatot.

Remélem hasznosnak találtad ezt az oktatóanyagot. Maradjon velünkkódot, amelyet hamarosan kiadunk. Sokkal mélyebben fogunk belemenni hasonló forgatókönyvekbe. Azt is megtanítjuk, hogyan optimalizálhatja DAX-kódját.