Funktionen BERÄKNA DAX: Problem och lösningar

I dagens blogg kommer vi att utforska varför du inte ska använda DAX-funktionen för att få medel per kategori och ge några alternativa lösningar för att få samma resultat som du vill ha. Du kan se hela videon av denna handledning längst ner på den här bloggen .

Att få ett genomsnitt per kategori i DAX är konstigt komplicerat. Genom att använda BERÄKNA-funktionen för att lösa dessa beräkningar kan nya DAX-användare få DAX-koden svårare att förstå än den borde vara. Den goda nyheten är att det finns enklare lösningar på detta problem. 

Innehållsförteckning

• Översikt över funktionen BERÄKNA DAX
• BERÄKNA DAX-formeln
• DAX-kod för genomsnitt per kategori
• Vad är problemet då?
• Den enklare lösningen
  • Använda SUMMARIZE-funktionen
  • Använda GROUPBY-funktionen
• Jämföra resultaten: SUMMARIZE vs GROUPBY vs CALCUATE DAX-funktioner
• Slutsats

Översikt över funktionen BERÄKNA DAX

För några månader sedan presenterade jag på LuckyTemplates. Det kallades DAX-motkulturen där jag gav några alternativa synpunkter på DAX. 

En av de viktigaste gäller användningen av funktionen BERÄKNA. Jag pratade om varför du inte ska använda CALCULATE, särskilt om du är ny på DAX. 

BERÄKNA är en riktigt komplex funktion att förstå och använda. Det gör vissa antaganden om din datamodell och kan få dig i mycket problem. 

Jag grävde också i Microsofts för Running Total eftersom det inte fungerar i situationer med enstaka tabeller och det behöver ett stjärnschema för att fungera korrekt.

Så jag visade ett enklare alternativ som fungerar oavsett om det är ett stjärnschema eller en enstaka tabellmodell utan behov av BERÄKNA. 

BERÄKNA DAX-formeln

Den här bloggen kommer att fördjupa sig i ett snabbt mått som heter Average Per Category . Om du är i LuckyTemplates skrivbord, börja med att gå till fältrutan och skapa en ny snabbåtgärd .

I fönstret Snabbmätning som kommer upp, välj Genomsnitt per kategori i rullgardinsmenyn Beräkning . Dra sedan ? Värde i textfältet Basvärde och Månad i fältet Kategori .

Klicka sedan på OK så får du en bild som ser ut så här. 

På x-axeln finns kvartarna – Kvartal 1, 2, 3 och 4. 

Och vad du vill göra är att summera värdena för varje månad som visas nedan och sedan ta genomsnittet över dessa värden. Kort sagt, genomsnittet per kategori, som är ämnet för vår blogg. 

Vår datamodell för detta är väldigt enkel. Vi har en tabell med datum , värden som genereras slumpmässigt och månad , månadssortering och kvartal i separata kolumner. 

Och vi har samma sak i vår med kalendertabellen, månad, månadssortering och kvartal. Det betyder att vi kan välja Kvartal eller Månad från antingen datumtabellen eller den första tabellen. 

De goda nyheterna med Average Per Category är att det faktiskt fungerar oavsett om du har en enkel tabellmodell eller ett stjärnschema.

I de här bilderna använder vi kvartalet från det första bordet...

 …medan den här använder kvartalet från vår datumtabell. Det fungerar hur som helst. 

Men problemet med Average Per Category är helt enkelt DAX-koden. 

Den här DAX-koden är konstig, för även om du är en DAX-expert kommer den förmodligen att förvirra dig vid första anblicken. Den är konstigt nog konstruerad med en CALCULATE-sats utan filtersats och lindar bara en summasats. 

Faktum är att det är en av mina husdjur när jag ser folk ute på forumen som använder CALCULATE som bara slår in en summa utan anledning. Men i det här fallet har det faktiskt en anledning.

Det förbryllar mig när jag ser dem eftersom det bara är en omedelbar indikation på att de inte har någon aning om vad de gör med BERÄKNA-funktionen. Så jag rekommenderar att du bara håller dig borta från det istället. 

DAX-kod för genomsnitt per kategori

DAX-koden som visas ovan använder . Den här funktionen är inte i ett CALCUATE-segment, vilket återigen gör det konstigt. Förmodligen är den här funktionen byggd för användning i CALCULATE-satser baserat på dess dokumentation.

Koden använder också , vilket jag inte håller med om. De ska aldrig använda VALUES eftersom distinkta värden har en tendens att returnera en tom rad om det finns en rad som inte matchar. Det kan få dig i mycket problem, men det är ett ämne för en annan video.

Vad som händer här är att de använder en VALUES-funktion för att få alla våra kategorier. Till exempel i kvartal 1, det är januari, februari och mars. VALUES returnerar också en tabell men de använder en KEEPFILTER-sats för att göra den giltig som en första parameter i . 

De behåller också CALCULATE-funktionen för att köras inom ramen för KEEPFILTERS. På grund av hur AVERAGEX fungerar tar det det andra uttrycket och exekverar det inom det första uttryckets sammanhang. 

Vad är problemet då?

Sammantaget fungerar det okej men inte för någon som är ny på DAX. Jag tror att Microsoft verkligen saknade båten när de skapade den här snabba åtgärden eftersom snabba åtgärder förmodligen är för personer som är nya i DAX.

Snabba mått är en bra idé, som "Låt oss skriva några vanliga mått med olika beräkningar för dig eftersom du är ny på DAX och du inte vet allt som finns att veta om DAX." Men varför skulle de konstruera dem på så konstiga, komplicerade sätt? 

Hur ska någon ny inom DAX ta en titt på det här och ta reda på vad som händer när till och med förmodligen DAX-proffs kliar sig lite i huvudet över den här? 

Så för mig missade de ett gyllene tillfälle att hjälpa människor att lära sig DAX med sina snabba åtgärder genom att insistera på att de inkluderade BERÄKNA och att de måste hoppa genom bågar för att få BERÄKNA där. 

Den enklare lösningen

Använda SUMMARIZE-funktionen

Som jag har nämnt tidigare finns det ett bättre och enklare sätt att göra det på.

Skapa först en tabellvariabel med VAR_Table . Sedan använder vi för att ta tabellen, sammanfatta den efter månad, skapa en värdekolumn och summera våra värden.

Slutligen tar vi medelvärdet av våra värden med hjälp av AVERAGEX -funktionen. 

Den här koden är enklare och är så mycket mer logisk. Den innehåller inte BERÄKNA, som du inte behöver i alla fall. 

Du kanske stöter på en bloggartikel där ute som kritiserar SUMMARIZE. Bloggen säger att SUMMARIZE fungerar internt är ganska komplicerat.

Det tyder också på att du kan hamna i problem i ett specifikt fall, men du kommer aldrig att stöta på det. Det skulle bara hända om din beräkning involverar en mycket komplex beräkning och en mycket stor tabell. Först då kommer SUMMARIZE att ge dig knasiga resultat. 

Det är åtminstone vad bloggartikeln hävdar. Och det är bra om du vill undvika SUMMARIZE. Använd i så fall funktionen istället.

Använda GROUPBY-funktionen

Ingen har problem med att använda GROUPBY-funktionen så låt oss lära oss hur man använder den också. Återigen, skapa en tabellvariabel med VAR_Table. Sedan GROUPBY Month och skapar en Value-kolumn.

Därefter använder vi CURRENTGROUP , vilket är hur GROUPBY fungerar. Låt oss summera vårt värde och återigen ta AVERAGEX över det. 

Vår kod ska se ut så här.

Jämföra resultaten: SUMMARIZE vs GROUPBY vs CALCUATE DAX-funktioner

Låt oss nu se om genvägarna vi gjorde ger samma resultat. 

Som du kan se på bilderna nedan ger både SUMMARIZE märkta som Bättre medel per kategori och GROUPBY märkta som Bättre genomsnitt per kategori 2 samma siffror. 

Båda våra formler ger 3,4K för Q1, 3,6K för Q2, 3,4K för Q3 och 3,5K för Q4. Och återigen, de arbetar i en enda tabelldatamodell med Quarters för vår tabell.

De fungerar även i ett stjärnschema där vi använder Quarters i vår datumtabell. 

Slutsats

Vi behöver inte tvinga oss in i en vriden kontextlogik bara för att få BERÄKNA in i våra formler. Använd bara enkla standard DAX-funktioner så kan du uppnå samma saker. 

I själva verket, förmodligen i 80% – 90% av fallen, finns det absolut ingen anledning att bry sig om att använda CALCULATE för någonting. Istället kan du använda funktionerna SUMMARIZE och GROUPBY som är enklare och mer logiska.

Om du vill utforska den här PBIX-filen har jag redan publicerat den till Quick Measures Gallery och döpt filen till Better Average Per Category . Bläddra bara hela vägen ner på sidan för att hitta PBIX-filen som du kan ladda ner och du spelar med dig själv. 

Med vänliga hälsningar,

Greg Deckler