Rijcontext en filtercontext in een LuckyTemplates DAX-code

In deze zelfstudie gaan we een stukje DAX-code bekijken. Misschien heb je zoiets al gebruikt. Of u kunt het tegenkomen en in de war raken over hoe deze code werkt en hoe zowel rijcontext als filtercontext met elkaar lijken te communiceren in slechts één enkele DAX-code. Hoe dan ook, deze tutorial zal al het bovenstaande in detail bekijken. Je kunt de volledige video van deze tutorial onderaan deze blog bekijken.

Eerst gaan we naar de code zelf kijken. Daarna zullen we het theoriegedeelte doornemen om het beter te begrijpen. Ten slotte zullen we alles achter de schermen bekijken met behulp van DAX Studio .

Het gegevensmodel dat we gaan gebruiken is in feite een eenvoudig verkoopgegevensmodel dat Datums, Verkoop en de tabel Producten bevat. De tabel Verkoop bevat transacties voor elke bepaalde dag. De tabel Producten bevat informatie over de verkoopinformatie over de producten op elke bepaalde dag. De tabel Datums bevat slechts een paar kolommen voor het doel van deze zelfstudie.

We zijn alleen geïnteresseerd in de tabel Datums, maar we gaan de tabel Verkoop en de tabel Producten gebruiken om uit te leggen hoe de filtercontext en rijcontext zich verspreiden met behulp van relaties.

Inhoudsopgave

• Rijcontext en filtercontext in een lopend totaal
• DAX Studio gebruiken om rijcontext en filtercontext te begrijpen
• Conclusie

Rijcontext en filtercontext in een lopend totaal

Laten we nu een lopende totaalmeting maken omdat deze zowel rij- als filtercontexten bevat. Dit is een standaard lopende totaalmaat, waarbij ik COUNTROWS gebruik boven de FILTER, en de ALL-functie om alle jaren terug te geven die ik in de datumtabel heb. Als ik die maat in de onderstaande tabel breng, kun je zien dat we het resultaat krijgen dat we verwachten.

Laten we nu proberen te analyseren hoe die DAX-code werkt.

In de meting kun je zien dat we eerst COUNTROWS hebben, maar dat is niet de eerste functie die wordt geëvalueerd of uitgevoerd. Dan hebben we de FILTER-functie en dan de ALL. Het eerste in de evaluatievolgorde is ALLES. ALL retourneert alle unieke waarden van de datums kalender jaarnummer door elke filtercontext te negeren die buiten de functie ALL bestaat.

Dus in de statistieken hebben we de kolom Kalenderjaarnummer en deze filtert actief die kolom. Maar aangezien ALL de bestaande filtercontext gaat negeren, krijgen we alle unieke waarden van die kolom.

In het tweede argument, in de rijcontext, hebben we geschreven dat het datums kalenderjaarnummer kleiner moet zijn dan het MAX datums kalenderjaarnummer. Nu, als je een beginner bent en nog steeds DAX probeert te begrijpen en te leren, zou je kunnen denken dat zowel de referenties aan de linkerkant als in de MAX-functie tot dezelfde kolom behoren en dezelfde tabel zijn die we in de ALLE functie.

Maar dat is niet waar. Het enige deel van de rijcontext dat bij de functie ALLES hoort, is het deel dat we aan de linkerkant hebben. Degene die we op de MAX hebben, wordt geëvalueerd binnen een filtercontext en niet in de rijcontext.

FILTER probeert dus een rijcontext te maken op de tabel die u in het eerste argument opgeeft, en dit deel van de code wordt feitelijk opgehaald uit die specifieke rijcontext. Dus elke rij, FILTER herhaalt die tabel die we in ALL hebben, en dan hebben we toegang tot alle waarden die we momenteel herhalen.

Dus in de eerste iteratie hebben we maar één waarde. In de tweede iteratie hebben we de tweede waarde. Maar wanneer we MAX schrijven, is dit onafhankelijk van de rijcontext die we maken met behulp van de FILTER-functie. Dus MAX wordt geëvalueerd in de filtercontext die wordt gemaakt door het huidige jaarnummer dat we in die matrix hebben gebruikt.

Wanneer we in 2006 zijn, zal MAX 2006 retourneren, terwijl de huidige rij 2006, 2007 of 2008 kan zijn. FILTER zal de tabel retourneren die voldoet aan de criteria die we specificeren in het tweede argument. Wanneer we naar 2007 gaan, zal MAX 2007 retourneren. In 2008 zal het 2008 retourneren. En afhankelijk van alle waarden die kleiner zijn dan de waarde die wordt geretourneerd door de functie MAX, zal FILTER een tafel.

Om te bewijzen dat MAX niet afhankelijk is van de rijcontext, kunnen we dit stuk DAX-code opsplitsen in verschillende variabelen. En dan zullen we kunnen begrijpen dat de kolomverwijzing aan de linkerkant en aan de rechterkant niet hetzelfde zijn.

Laten we dus een variabele maken.

Zoals je in de onderstaande maat kunt zien, heb ik drie variabelen ( ) gemaakt. Vervolgens heb ik de FILTER-code als laatste toegevoegd met een variabele Resultaat die COUNTROWS gebruikt . Als ik deze maat in onderstaande tabel gebruik, zie je dat er niets verandert. De resultaten zijn nog steeds hetzelfde. We krijgen nog steeds hetzelfde lopende totaal dat we eerder kregen.

Als we teruggaan naar de code en proberen de waarde van de eerste variabele op te halen en dat te bevestigen, kun je zien dat we voor elke rij hetzelfde jaar krijgen.

Dus hopelijk heb ik je kunnen uitleggen dat de MAX-functie, in deze specifieke code, niet echt afhangt van de echte context voor zijn waarden. En als u uw begrip van de evaluatiecontext wilt vereenvoudigen, kunt u de code altijd opsplitsen in verschillende variabelen, zodat u de evaluatievolgorde kunt begrijpen en hoe de code wordt uitgevoerd.

Nu wil ik u een scenario laten zien waarin de MAX-functie afhangt van de rijcontext die wordt gemaakt door de FILTER-functie.

Dus laten we teruggaan naar die maat. Laten we dat dupliceren, en in plaats van Last Visible Year heb ik MAX Dates Calendar Year Number. Als ik dat in de matrix breng, zie je dat we een spatie krijgen.

Waarom?

Het punt is dat we alle jaren herhalen en wat CALCULATE doet, is dat het de momenteel herhaalde rij converteert naar een equivalente filtercontext.

Als ik hier een gelijkteken schrijf, kun je zien dat we zeven, zeven en zeven krijgen.

Waarom?

Laat me een nieuwe berekende tabel maken zodat u gemakkelijk kunt begrijpen wat er gebeurt.

Ik ga een nieuwe tabel maken. over het ALLE datums kalenderjaarnummer schrijven . Dan schrijf ik Max Year, en dan gebruik ik CALCULATE over de MAX van de Data Calendar Year Number. En nu kun je zien dat we voor elke rij dezelfde waarde herhalen.

Aangezien deze getallen niet strikt kleiner zijn dan zijzelf, krijgen we een spatie. Maar als we gelijk aan (=) gebruiken, zeggen we dat alle waarden die kleiner zijn dan 2011 een zeven krijgen.

Bovendien, zelfs als u een maatreferentie gebruikt, zoals iets als Max Year, zal deze code niet werken.

Als ik op bevestigen klik, zie je dat we nog steeds niets krijgen. Dit komt omdat wanneer we Max Year schrijven, we simpelweg CALCULATE MAX Dates Calendar Year Number schrijven.

Een maatreferentie heeft altijd een CALCULATE daarbuiten. Deze meting initieert dus een contextovergang die de momenteel herhaalde rij converteert naar een filtercontext.

Maar als u gebonden bent en u een maatreferentie moet gebruiken, kunt u die maat opslaan in een variabele. En zoals u wellicht weet, zijn variabelen constant en kunnen ze geen contextovergang creëren. Het kan de rijcontext dus niet omzetten in een filtercontext.

Dat is dus een snelle demonstratie van hoe een rijcontext en een filtercontext met elkaar omgaan in een DAX-code.

Laten we nu naar DAX Studio gaan om te begrijpen wat er achter de schermen gebeurt.

DAX Studio gebruiken om rijcontext en filtercontext te begrijpen

Laten we naar de externe tools gaan en DAX Studio starten. We moeten verbinding maken met het LuckyTemplates-bestand met behulp van Query Plan en de Server Timings .

Vervolgens ga ik een querymaat maken. Ik schrijf DEFINE MEASURE in de tabel Datums, Datums lopend totaal. En dan ga ik de originele code gebruiken die we hadden.

Aangezien we geacht worden een tabel terug te geven, kunnen we EVALUATE schrijven. Ten slotte gaan we de tabel maken met behulp van de SAMENVATTINGKOLOMMEN. Dus we gaan Datums Kalender Jaarnummer schrijven, en de virtuele kolom, die het Lopend Totaal zal zijn. En dan kan ik zoiets als DT schrijven als een DAX Studio-trefwoord.

Als ik deze code uitvoer, kun je zien dat de code compleet is en krijgen we nog steeds hetzelfde resultaat dat we in LuckyTemplates hebben gezien.

Laten we nu naar het queryplan gaan om te begrijpen wat er achter de schermen gebeurt. Laten we eens kijken of de MAX-functie daadwerkelijk afhankelijk is van de rijcontext of niet. Laten we naar het logische queryplan gaan, omdat het fysieke queryplan over het algemeen complexer is en een beetje moeilijk te lezen is.

U kunt zien dat de eerste operator op de eerste regel GroupSemiJoin is en dat deze wordt gebruikt door de SUMMARIZECOLUMNS om een ​​binnenste verbinding tussen twee kolommen te maken.

Om aan die kolommen deel te nemen, is er Scan_Vertipaq , de opslagengine die we binnen de analyseservices hebben. We kunnen zien dat er staat dat we een kolom nodig hebben, namelijk Datums Kalender Jaar Nummer. In LuckyTemplates kunt u zien dat we in de matrix deze kolom Kalenderjaarnummer hebben, die fungeert als toegang tot ons rapport.

Vervolgens hebben we de COUNTROWS-functie in onze meting als operator op het hoogste niveau, waarna COUNTROWS de FILTER-functie voor het filter aanroept. Er is weer een Scan_Vertipaq , die zegt dat RequiredCols Dates Calendar Year Number is.

Regel 2 en 5 zijn hetzelfde, maar de eerste Scan_Vertipaq is gemarkeerd met een nul en de tweede met een. Dat betekent dat de kolom waartoe we toegang hebben, met behulp van de ALL-functie, afzonderlijk wordt geëxtraheerd uit de kolom die we hebben in de SUMMARIZECOLUMNS-functie.

Dan is er een LessThan- operator. In de volgende regel kunnen we zien dat er een vergelijking is tussen de rijcontext en de MAX-functie .

Dit wordt gevolgd door de Max_Vertipaq . We halen dus eigenlijk de Max-waarde uit de opslagengine. Aan de rechterkant ziet u dat er staat: DependOnCols Dates Calendar Year Number. Dit is het belangrijkste dat we moeten onthouden. Eerder zei ik dat er geen afhankelijkheid is van de MAX-functie van de rijcontext, en dit is wat het feitelijk bewijst.

En dus staat hier nul.

Waar hebben we nul gevonden?

Bovenaan (de tweede regel), die wordt geëxtraheerd voor de SAMENVATTINGKOLOMMEN. Dat betekent dat de MAX-functie niet afhankelijk is van de rijcontext, maar in feite afhankelijk is van de kolom (kalenderjaarnummer) die we in die tabel hebben. Dus die tabel maakt eigenlijk de filtercontext.

Kortom, de MAX-functie is afhankelijk van de filtercontext en niet van de rijcontext.

Vervolgens kunt u zien dat we voor het berekenen van de Max_Vertipaq een Scan_Vertipaq hebben , die zegt dat DependOnCols nul (0) Datum Kalender Jaarnummer. En dan zijn er verschillende andere kolommen waarvoor kolommen nodig zijn.

Laten we nu eens kijken naar de variabele versie van de code. In plaats van het LastVisibleYear terug te geven, ga ik de COUNTROWS-versie of de resultaatvariabele retourneren, en je kunt zien dat we nog steeds hetzelfde resultaat krijgen.

Als we naar het Query Plan kijken, kun je zien dat het wat langer is, maar het is veel gemakkelijker te lezen.

Ten slotte is hier ook de berekende versie van de code

En zo ziet het logische queryplan eruit.

DAX LuckyTemplates: wat is rijcontext
Inleiding tot filtercontext in LuckyTemplates
Wat is contextovergang en waarom is het belangrijk?

Conclusie

In deze zelfstudie heb ik uitgelegd hoe een bepaalde functie kan communiceren en niet kan communiceren met de rijcontext. Ik heb je ook laten zien hoe de MAX, in dit geval, werd geëvalueerd in de filtercontext en niet in de rijcontext.

Het is belangrijk om altijd te onthouden dat de filtercontext het hele model filtert en dat de rijcontext alleen de gegeven tabel herhaalt en nooit het model filtert. De filtercontext herhaalt een tabel niet.

Ik hoop dat je deze tutorial nuttig vond. Houd ons in de gaten voor onze DAX Studio- code die we zeer binnenkort vrijgeven. We gaan veel dieper in op vergelijkbare scenario's. We leren u ook hoe u uw DAX-code kunt optimaliseren.