Radkontekst og filterkontekst i en LuckyTemplates DAX-kode

I denne opplæringen skal vi ta en titt på et stykke DAX-kode. Du har kanskje allerede brukt noe slikt. Eller du kan komme over det og bli forvirret over hvordan denne koden fungerer og hvordan både Row Context og Filter Context ser ut til å samhandle med hverandre i bare en enkelt DAX-kode. Uansett vil denne opplæringen se på alt det ovennevnte i detalj. Du kan se hele videoen av denne opplæringen nederst på denne bloggen.

Først skal vi se på selve koden. Så skal vi gå gjennom teoridelen for å forstå den bedre. Til slutt vil vi se på alt bak kulissene ved å bruke.

Datamodellen vi skal bruke er i utgangspunktet en enkel salgsdatamodell som inneholder Datoer, Salg og Produkttabellen. Salgstabellen inneholder transaksjoner for hver gitt dag. Produkttabellen inneholder informasjon om salgsinformasjonen om produktene på hver gitt dag. Datoer-tabellen inneholder bare noen få kolonner for formålet med denne opplæringen.

Vi er kun interessert i Datoer-tabellen, men vi skal bruke Salgstabellen og Produkttabellen for å forklare hvordan filterkonteksten og radkonteksten forplanter seg ved hjelp av relasjoner.

Innholdsfortegnelse

• Radkontekst og filterkontekst i et løpende totalmål
• Bruke DAX Studio for å forstå radkontekst og filterkontekst
• Konklusjon

Radkontekst og filterkontekst i et løpende totalmål

La oss nå lage et løpende totalmål fordi det inneholder både rad- og filterkontekster. Dette er et grunnleggende løpende totalmål, der jeg bruker COUNTROWS over FILTER, og ALL-funksjonen for å returnere alle årene jeg har inne i Dato-tabellen. Når jeg tar med det målet inne i tabellen nedenfor, kan du se at vi får det resultatet vi forventer.

La oss nå prøve å analysere hvordan den DAX-koden fungerer.

I tiltaket kan du først se at vi har COUNTROWS, men det er ikke den første funksjonen som blir evaluert eller utført. Deretter har vi FILTER-funksjonen, og deretter ALL. Det første i evalueringsrekkefølgen er ALLE. ALL returnerer alle de unike verdiene til Dates Calendar Year Number ved å ignorere enhver filterkontekst som eksisterer utenfor ALL-funksjonen.

Så i beregningene har vi kolonnen Kalenderårnummer, og den filtrerer aktivt den kolonnen. Men siden ALL kommer til å ignorere den eksisterende filterkonteksten, kommer vi til å få alle de unike verdiene til den kolonnen.

I det andre argumentet, i radkonteksten, har vi skrevet at datokalenderårtallet skal være mindre enn MAKS datokalenderårnummeret. Nå, hvis du er nybegynner og fortsatt prøver å forstå og lære DAX, tror du kanskje at både referansene på venstre side og inne i MAX-funksjonen tilhører samme kolonne og er den samme tabellen som vi har inne i ALL funksjon.

Men det er ikke sant. Den eneste delen av radkonteksten som hører til ALL-funksjonen er den vi har på venstre side. Den vi har på MAX blir evaluert i en filterkontekst og ikke i radkonteksten.

Så, FILTER prøver å lage en radkontekst på tabellen som du oppgir i det første argumentet, og denne delen av koden hentes faktisk fra den bestemte radkonteksten. Så hver rad, FILTER itererer den tabellen som vi har inne i ALL, og så kan vi få tilgang til alle verdiene som vi gjentar.

Så i den første iterasjonen har vi bare én verdi. I den andre iterasjonen har vi den andre verdien. Men når vi skriver MAX, er det uavhengig av radkonteksten vi lager ved å bruke FILTER-funksjonen. Så MAX blir evaluert i filterkonteksten som blir opprettet av gjeldende årstall som vi har brukt i den matrisen.

Når vi er i 2006, kommer MAX til å returnere 2006, mens gjeldende rad kan være 2006, 2007 eller 2008. FILTER kommer til å returnere tabellen som tilfredsstiller kriteriene som vi spesifiserer i det andre argumentet. Når vi flytter til 2007, kommer MAX til å returnere 2007. I 2008 kommer det til å returnere 2008. Og avhengig av alle verdiene som er mindre enn verdien som blir returnert av MAX-funksjonen, vil FILTER returnere en bord.

For å bevise at MAX ikke er avhengig av radkonteksten, kan vi dele denne delen av DAX-koden i flere variabler. Og da vil vi kunne forstå at kolonnereferansen på venstre side og på høyre side ikke er den samme.

Så la oss lage en variabel.

Som du kan se i målet nedenfor, opprettet jeg tre variabler (). Jeg la til FILTER-koden til slutt med en variabel Resultat som bruker. Når jeg bruker dette målet i tabellen nedenfor, vil du se at ingenting endres. Resultatene er fortsatt de samme. Vi får fortsatt den samme løpende summen som vi fikk tidligere.

Hvis vi går tilbake til koden og prøver å hente verdien av den første variabelen og bekrefter det, kan du se at for hver rad får vi samme år.

Så, forhåpentligvis, var jeg i stand til å forklare deg at MAX-funksjonen, i denne spesielle koden, faktisk ikke avhenger av den virkelige konteksten for verdiene. Og hvis du ønsker å forenkle forståelsen av evalueringskonteksten, kan du alltid dele koden inn i flere variabler slik at du kan forstå evalueringsrekkefølgen og hvordan koden blir utført.

Nå vil jeg vise deg et scenario der MAX-funksjonen vil avhenge av radkonteksten som er opprettet av FILTER-funksjonen.

Så la oss gå tilbake til det målet. La oss duplisere det, og i stedet for Siste synlige år, vil jeg ha detMAKS Datoer Kalenderårnummer. Når jeg tar det inn i matrisen, kan du se at vi får en blank.

Hvorfor?

Saken er at vi itererer alle årene, og det CALCUATE gjør er at den konverterer den gjentatte raden til en tilsvarende filterkontekst.

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

Hvorfor?

La meg lage en ny beregnet tabell slik at du enkelt kan forstå hva som skjer.

Jeg skal lage et nytt bord. Deretter skal jeg skriveover ALLE datoer kalenderårnummer. Deretter skriver jeg Max Year, og så bruker jeg CALCUATE over MAKS for Datoer kalenderårnummer. Og nå kan du se at for hver rad gjentar vi den samme verdien.

Siden disse tallene strengt tatt ikke er mindre enn dem selv, får vi en blank. Men når vi bruker lik (=), sier vi at alle verdiene som er mindre enn 2011 får en sjuer.

Dessuten, selv om du bruker en målreferanse som for eksempel Max Year, vil ikke denne koden fungere.

Hvis jeg klikker bekrefte, kan du se at vi fortsatt ikke får noe. Dette er fordi når vi skriver Max Year, skriver vi ganske enkelt BEREGN MAKS Datoer Kalenderårnummer.

En målreferanse har alltid en CALCUATE utenfor seg. Så dette tiltaket initierer en kontekstovergang som konverterer den gjentatte raden til en filterkontekst.

Men hvis du er bundet og du må bruke en målreferanse, er det du kan gjøre å lagre det målet i en variabel. Og som du kanskje vet, er variabler konstante, og de kan ikke skape en kontekstovergang. Så den kan ikke konvertere radkonteksten til en filterkontekst.

Så det er en rask demonstrasjon av hvordan en radkontekst og en filterkontekst samhandler med hverandre i en DAX-kode.

La oss nå gå til DAX Studio for å forstå hva som skjer bak kulissene.

Bruke DAX Studio for å forstå radkontekst og filterkontekst

La oss gå til de eksterne verktøyene og starte DAX Studio. Vi må koble til LuckyTemplates-filen ved hjelp av Query Plan og Server Timings .

Deretter skal jeg lage et spørringsmål. Jeg skriver DEFINE MÅL i Datoer-tabellen, Datoer totalt. Og så skal jeg bruke den originale koden vi hadde.

Siden vi skal returnere en tabell, kan vi skrive EVALUER. Til slutt skal vi lage tabellen ved å bruke SUMMARISECOLUMNS. Så vi skal skrive Datoer kalenderårnummer, og den virtuelle kolonnen, som vil være den løpende totalen. Og så kan jeg skrive noe sånt som DT som et DAX Studio-nøkkelord.

Hvis jeg kjører denne koden, kan du se at koden er komplett og vi fortsatt får det samme resultatet som vi har sett inne i LuckyTemplates.

La oss nå gå til spørreplanen for å forstå hva som skjer bak kulissene. La oss se om MAX-funksjonen faktisk er avhengig av radkonteksten eller ikke. La oss gå til den logiske spørreplanen fordi den fysiske spørreplanen generelt er mer kompleks og litt vanskelig å lese.

Du kan se at den første operatøren på den første linjen er GroupSemiJoin , og som brukes av SUMMARISECOLUMNS for å lage en indre skjøt mellom to kolonner.

Så, for å slå sammen disse kolonnene, er det Scan_Vertipaq , som er lagringsmotoren som vi har inne i analysetjenestene. Vi kan se at det står at vi trenger en kolonne, som er Datoer kalenderårnummer. I LuckyTemplates kan du se at på matrisen har vi denne kalenderårnummer-kolonnen, som fungerer som tilgang til rapporten vår.

Deretter har vi COUNTROWS-funksjonen i målet vårt som en toppnivåoperatør, deretter kaller COUNTROWSfor filteret. Det er en Scan_Vertipaq igjen, som sier at RequiredCols er Dates Calendar Year Number.

Linje 2 og 5 er like, men den første Scan_Vertipaq er merket med null mens den andre er med en. Det betyr at kolonnen som vi får tilgang til, ved hjelp av ALL-funksjonen, trekkes ut separat fra kolonnen som vi har inne i SUMMARISECOLUMNS-funksjonen.

Så er det en LessThan- operatør. I neste linje kan vi se at det er en sammenligning mellom radkonteksten og MAX-funksjonen .

Dette etterfølges av Max_Vertipaq . Så vi trekker faktisk ut Max-verdien fra lagringsmotoren. Mot høyre kan du se at det står, DependOnCols Dates Calendar Year Number. Dette er det viktigste vi trenger å huske. Tidligere sa jeg at det ikke er noen avhengighet av MAX-funksjonen av radkonteksten, og det er dette som faktisk beviser det.

Og så, her står det null.

Hvor fant vi null?

På toppen (den andre linjen), som trekkes ut for SUMMARISECOLUMNS. Det betyr at MAX-funksjonen ikke avhenger av radkonteksten, men den er faktisk avhengig av kolonnen (kalenderårnummer) som vi har i den tabellen. Så den tabellen skaper faktisk filterkonteksten.

Kort sagt, MAX-funksjonen er avhengig av filterkonteksten og ikke radkonteksten.

Deretter kan du se at for å beregne Max_Vertipaq, har vi en Scan_Vertipaq , som sier at DependOnCols null (0) dato kalenderårnummer. Og så er det flere andre kolonner som krever kolonner.

La oss nå se på variabelversjonen av koden. I stedet for å returnere LastVisibleYear, kommer jeg til å returnere COUNTROWS-versjonen eller Result-variabelen, og du kan se at vi fortsatt får det samme resultatet.

Hvis vi ser på spørreplanen, kan du se at den er litt lengre, men den er mye lettere å lese.

Til slutt, her er den beregnede versjonen av koden også

Og slik ser dens logiske spørreplan ut.

Konklusjon

I denne opplæringen har jeg forklart hvordan en gitt funksjon kan samhandle og ikke kan samhandle med radkonteksten. Jeg har også vist deg hvordan MAX, i dette tilfellet, ble evaluert i filterkonteksten og ikke i radkonteksten.

Det er viktig å alltid huske at filterkonteksten filtrerer hele modellen og radkonteksten bare gjentar den gitte tabellen og aldri filtrerer modellen. Filterkonteksten itererer ikke en tabell.

Jeg håper du fant denne veiledningen nyttig. Følg med på vårkode som vi vil gi ut veldig snart. Vi vil gå mye dypere inn i lignende scenarier. Vi vil også lære deg hvordan du kan optimalisere DAX-koden din.