Rækkekontekst og filterkontekst i en LuckyTemplates DAX-kode

I denne tutorial skal vi tage et kig på et stykke DAX-kode. Du har måske allerede brugt noget som dette. Eller du kan støde på det og blive forvirret over, hvordan denne kode fungerer, og hvordan både Row Context og Filter Context ser ud til at interagere med hinanden i blot en enkelt DAX-kode. Uanset hvad, vil denne tutorial se på alt det ovenstående i detaljer. Du kan se den fulde video af denne tutorial nederst på denne blog.

Først skal vi se på selve koden. Så vil vi gennemgå teoridelen for at forstå den bedre. Til sidst vil vi se på alt bag kulisserne ved at bruge.

Datamodellen, som vi skal bruge, er grundlæggende en simpel salgsdatamodel, der indeholder Datoer, Salg og tabellen Produkter. Salgstabellen indeholder transaktioner for hver given dag. Tabellen Produkter indeholder oplysninger om salgsoplysningerne om produkterne på hver given dag. Datoer-tabellen indeholder kun nogle få kolonner til formålet med denne øvelse.

Vi er kun interesserede i tabellen Datoer, men vi vil bruge tabellen Salg og tabellen Produkter til at forklare, hvordan filterkonteksten og rækkekonteksten udbreder sig ved hjælp af relationer.

Indholdsfortegnelse

• Rækkekontekst og filterkontekst i et løbende mål
• Brug af DAX Studio til at forstå rækkekontekst og filterkontekst
• Konklusion

Rækkekontekst og filterkontekst i et løbende mål

Lad os nu oprette et løbende totalmål, fordi det indeholder både række- og filterkontekster. Dette er et grundlæggende løbende totalmål, hvor jeg bruger COUNTROWS over FILTER, og funktionen ALLE til at returnere alle de år, jeg har inde i Dato-tabellen. Når jeg bringer det mål inde i tabellen nedenfor, kan du se, at vi får det resultat, vi forventer.

Lad os nu prøve at analysere, hvordan den DAX-kode fungerer.

I målingen kan du se, at vi først har COUNTROWS, men det er ikke den første funktion, der bliver evalueret eller udført. Så har vi FILTER-funktionen og derefter ALL. Den første ting i evalueringsrækkefølgen er ALLE. ALL returnerer alle de unikke værdier af Dates Calendar Year Number ved at ignorere enhver filterkontekst, der eksisterer uden for funktionen ALL.

Så i metrikken har vi kolonnen Kalenderårnummer, og den filtrerer aktivt denne kolonne. Men da ALL kommer til at ignorere den eksisterende filterkontekst, får vi alle de unikke værdier i den kolonne.

I det andet argument, i rækkekonteksten, har vi skrevet, at Dates Calendar Year Number skal være mindre end MAX Dates Calendar Year Number. Hvis du nu er nybegynder og stadig prøver at forstå og lære DAX, tror du måske, at både referencerne i venstre side og inde i MAX-funktionen tilhører den samme kolonne og er den samme tabel, som vi har inde i ALT funktion.

Men det er ikke sandt. Den eneste del af rækkekonteksten, der hører til ALL-funktionen, er den, vi har i venstre side. Den, vi har på MAX, bliver evalueret i en filterkontekst og ikke i rækkekonteksten.

Så FILTER forsøger at skabe en rækkekontekst på tabellen, som du angiver i det første argument, og denne del af koden hentes faktisk fra den pågældende rækkekontekst. Så hver række, FILTER itererer den tabel, som vi har inde i ALL, og så er vi i stand til at få adgang til alle de værdier, som vi i øjeblikket itererer.

Så i den første iteration har vi kun én værdi. I den anden iteration har vi den anden værdi. Men når vi skriver MAX, er det uafhængigt af rækkekonteksten, som vi opretter ved hjælp af FILTER-funktionen. Så MAX bliver evalueret i den filterkontekst, der skabes af det aktuelle årstal, som vi har brugt i den matrix.

Når vi er ved 2006, vil MAX returnere 2006, hvorimod den nuværende række kan være 2006, 2007 eller 2008. FILTER vil returnere den tabel, der opfylder de kriterier, som vi angiver i det andet argument. Når vi flytter til 2007, vil MAX returnere 2007. I 2008 vil det returnere 2008. Og afhængigt af alle de værdier, der er mindre end den værdi, der returneres af MAX-funktionen, vil FILTER returnere en bord.

For at bevise, at MAX ikke er afhængig af rækkekonteksten, kan vi adskille dette stykke DAX-kode i flere variable. Og så vil vi være i stand til at forstå, at kolonnehenvisningen på venstre side og på højre side ikke er den samme.

Så lad os oprette en variabel.

Som du kan se i målingen nedenfor, oprettede jeg tre variabler (). Jeg tilføjede derefter FILTER-koden til sidst med en variabel Resultat, der bruger. Når jeg bruger dette mål i tabellen nedenfor, vil du se, at intet ændrer sig. Resultaterne er stadig de samme. Vi får stadig den samme løbende total, som vi fik tidligere.

Hvis vi går tilbage til koden og prøver at hente værdien af ​​den første variabel og bekræfter det, kan du se, at vi for hver række får samme år.

Så forhåbentlig var jeg i stand til at forklare dig, at MAX-funktionen i denne særlige kode faktisk ikke afhænger af dens værdier i den virkelige kontekst. Og hvis du vil forenkle din forståelse af evalueringskonteksten, kan du altid opdele koden i flere variabler, så du kan forstå evalueringsrækkefølgen og hvordan koden bliver eksekveret.

Nu vil jeg vise dig et scenarie, hvor MAX-funktionen vil afhænge af rækkekonteksten , der oprettes af FILTER-funktionen.

Så lad os gå tilbage til det mål. Lad os duplikere det, og i stedet for Sidste synlige år har jeg detMAX Datoer Kalenderår nummer. Når jeg bringer det ind i matricen, kan du se, at vi får en blank.

Hvorfor?

Sagen er, at vi itererer alle årene, og hvad CALCUATE gør, er, at den konverterer den aktuelt itererede række til en tilsvarende filterkontekst.

Hvis jeg skriver et lighedstegn her, kan du se, at vi får syv, syv og syv.

Hvorfor?

Lad mig lave en ny beregnet tabel, så du nemt kan forstå, hvad der sker.

Jeg laver en ny tabel. Dernæst vil jeg skriveover ALLE Datoer kalenderårnummer. Derefter skriver jeg Max Year, og så bruger jeg CALCUATE over MAX'et af Datoer kalenderårnummer. Og nu kan du se, at vi for hver række gentager den samme værdi.

Da disse tal ikke er strengt mindre end dem selv, får vi en blank. Men når vi bruger lig med (=), siger vi, at alle de værdier, der er mindre end 2011, får en syv.

Desuden, selvom du bruger en målreference, såsom noget som Max Year, vil denne kode ikke fungere.

Hvis jeg klikker på bekræft, kan du se, at vi stadig ikke får noget. Dette skyldes, at når vi skriver Max år, skriver vi simpelthen BEREGN MAKS Datoer Kalenderårnummer.

En målreference har altid en CALCUATE uden for sig. Så denne foranstaltning initierer en kontekstovergang, der konverterer den aktuelt itererede række til en filterkontekst.

Men hvis du er bundet, og du skal bruge en målreference, er det, du kan gøre, at gemme det mål i en variabel. Og som du måske ved, er variabler konstante, og de kan ikke skabe en kontekstovergang. Så den kan ikke konvertere rækkekonteksten til en filterkontekst.

Så det er en hurtig demonstration af, hvordan en rækkekontekst og en filterkontekst interagerer med hinanden i en DAX-kode.

Lad os nu gå til DAX Studio for at forstå, hvad der sker bag kulisserne.

Brug af DAX Studio til at forstå rækkekontekst og filterkontekst

Lad os gå til de eksterne værktøjer og starte DAX Studio. Vi skal oprette forbindelse til LuckyTemplates-filen ved hjælp af Query Plan og Server Timings .

Derefter vil jeg oprette et forespørgselsmål. Jeg skriver DEFINE MEASURE i Datoer-tabellen, Dates Running Total. Og så vil jeg bruge den originale kode, som vi havde.

Da vi formodes at returnere et bord, kan vi skrive EVALUER. Til sidst skal vi oprette tabellen ved hjælp af SUMMARIZECOLUMNS. Så vi skal skrive Datoer kalenderårnummer og den virtuelle kolonne, som vil være den løbende total. Og så kan jeg skrive noget som DT som et DAX Studio nøgleord.

Hvis jeg udfører denne kode, kan du se, at koden er komplet, og vi får stadig det samme resultat, som vi har set inde i LuckyTemplates.

Lad os nu gå til forespørgselsplanen for at forstå, hvad der sker bag kulisserne. Lad os se, om MAX-funktionen faktisk er afhængig af rækkekonteksten eller ej. Lad os gå til den logiske forespørgselsplan, fordi den fysiske forespørgselsplan generelt er mere kompleks og er lidt svær at læse.

Du kan se, at den første operator på den første linje er GroupSemiJoin , og den bruges af SUMMARIZECOLUMNS til at skabe en indre samling mellem to kolonner.

Så, for at forbinde disse kolonner, er der Scan_Vertipaq , som er den lagermotor, vi har inde i analysetjenesterne. Vi kan se, at der står, at vi skal bruge en kolonne, som er Datoer kalenderårnummer. I LuckyTemplates kan du se, at vi på matrixen har denne kolonne med kalenderårnummer, som fungerer som adgang til vores rapport.

Dernæst har vi COUNTROWS-funktionen i vores mål som operatør på øverste niveau, så kalder COUNTROWSfor filteret. Der er en Scan_Vertipaq igen, som siger, at RequiredCols er Dates Calendar Year Number.

Linje 2 og 5 er ens, men den første Scan_Vertipaq er markeret med nul, mens den anden er med en. Det betyder, at den kolonne, som vi har adgang til, ved hjælp af ALL-funktionen, udtrækkes separat fra den kolonne, vi har inde i SUMMARIZECOLUMNS-funktionen.

Så er der en LessThan- operatør. På næste linje kan vi se, at der er en sammenligning mellem rækkekonteksten og MAX-funktionen .

Dette efterfølges af Max_Vertipaq . Så vi udtrækker faktisk Max-værdien fra lagermotoren. Mod højre kan du se, at der står, DependOnCols Dates Calendar Year Number. Dette er det vigtigste, vi skal huske. Tidligere sagde jeg, at der ikke er nogen afhængighed af MAX-funktionen af ​​rækkekonteksten, og det er det, der faktisk beviser det.

Og her står der altså nul.

Hvor fandt vi nul?

På toppen (den anden linje), som er ved at blive udtrukket for SUMMARISECOLUMNS. Det betyder, at MAX-funktionen ikke afhænger af rækkekonteksten, men den er faktisk afhængig af kolonnen (kalenderårsnummer), som vi har inde i den tabel. Så den tabel skaber faktisk filterkonteksten.

Kort sagt er MAX-funktionen afhængig af filterkonteksten og ikke rækkekonteksten.

Dernæst kan du se, at til beregning af Max_Vertipaq har vi en Scan_Vertipaq , som siger, at DependOnCols nul (0) Dato Kalender Årnummer. Og så er der flere andre kolonner, der kræver kolonner.

Lad os nu se på den variable version af koden. I stedet for at returnere LastVisibleYear, vil jeg returnere COUNTROWS-versionen eller Result-variablen, og du kan se, at vi stadig får det samme resultat.

Hvis vi ser på forespørgselsplanen, kan du se, at den er lidt længere, men den er meget nemmere at læse.

Til sidst, her er også den beregnede version af koden

Og sådan ser dens logiske forespørgselsplan ud.

Konklusion

I denne øvelse har jeg forklaret, hvordan en given funktion kan interagere og ikke kan interagere med rækkekonteksten. Jeg har også vist dig, hvordan MAX, i dette tilfælde, blev evalueret i filterkonteksten og ikke i rækkekonteksten.

Det er vigtigt altid at huske, at filterkonteksten filtrerer hele modellen, og rækkekonteksten gentager kun den givne tabel og filtrerer aldrig modellen. Filterkonteksten itererer ikke en tabel.

Jeg håber, du fandt denne tutorial nyttig. Hold øje med voreskode, som vi vil frigive meget snart. Vi vil gå meget dybere ind i lignende scenarier. Vi vil også lære dig, hvordan du kan optimere din DAX-kode.