Funksjonen BEREGN DAX: Problemer og løsninger

I dagens blogg vil vi utforske hvorfor du ikke bør bruke DAX-funksjonen for å få Average Per Category og gi noen alternative løsninger for å få de samme resultatene du ønsker. Du kan se hele videoen av denne opplæringen nederst på denne bloggen .

Å få et gjennomsnitt per kategori i DAX er merkelig komplisert. Ved å bruke CALCUATE-funksjonen for å løse disse beregningene, kan nye DAX-brukere finne DAX-koden vanskeligere å forstå enn den burde være. Den gode nyheten er at det finnes enklere løsninger på dette problemet. 

Innholdsfortegnelse

• Oversikt over CALCUATE DAX-funksjonen
• BEREGN DAX-formelen
• DAX-kode for gjennomsnitt per kategori
• Hva er problemet, da?
• Den enklere løsningen
  • Bruke SUMMARIZE-funksjonen
  • Bruk av GROUPBY-funksjonen
• Sammenligning av resultatene: SUMMARIZE vs GROUPBY vs CALCUATE DAX-funksjoner
• Konklusjon

Oversikt over CALCUATE DAX-funksjonen

For noen måneder siden presenterte jeg for LuckyTemplates. Det ble kalt DAX-motkulturen hvor jeg ga noen alternative syn på DAX. 

En av de viktigste gjelder bruken av CALCUATE-funksjonen. Jeg snakket om hvorfor du ikke bør bruke CALCULATE, spesielt hvis du er ny på DAX. 

CALCUATE er en veldig kompleks funksjon å forstå og bruke. Det gjør visse antakelser om datamodellen din og kan få deg i mye trøbbel. 

Jeg har også gravd i Microsofts for Running Total fordi det ikke fungerer i enkelttabellsituasjoner og det trenger et stjerneskjema for å fungere ordentlig.

Så jeg viste et enklere alternativ som fungerer enten det er et stjerneskjema eller en enkelt tabellmodell uten behov for CALCUATE. 

BEREGN DAX-formelen

Denne bloggen vil fordype seg i et raskt mål som heter Average Per Category . Hvis du er i LuckyTemplates-skrivebordet, start med å gå til feltruten og opprette et nytt hurtigmål .

I hurtigmålingsvinduet som vises, velg Gjennomsnitt per kategori i rullegardinmenyen Beregning . Så, dra ? Verdi i tekstfeltet Grunnverdi og Måned i Kategori- feltet.

Klikk deretter OK og du får opp et bilde som ser slik ut. 

I x-aksen er kvartalene – kvartal 1, 2, 3 og 4. 

Og det du vil gjøre er å summere verdiene for hver måned vist nedenfor og deretter ta gjennomsnittet over disse verdiene. Kort sagt, gjennomsnittet per kategori, som er temaet for bloggen vår. 

Vår datamodell for dette er veldig enkel. Vi har en tabell med Datoer , Verdier som genereres tilfeldig, og Måned , Månedssortering og Kvartal i separate kolonner. 

Og vi har det samme i vår med kalendertabellen, måned, månedssortering og kvartal. Dette betyr at vi kan velge kvartal eller måned fra enten datotabellen eller den første tabellen. 

Den gode nyheten med Average Per Category er at det faktisk fungerer uavhengig av om du har en enkelt tabellmodell eller et stjerneskjema.

I disse bildene bruker vi kvartalet fra det første bordet...

 … mens denne bruker kvartalet fra datotabellen vår. Det fungerer uansett. 

Men problemet med Average Per Category er ganske enkelt DAX-koden. 

Denne DAX-koden er rar, for selv om du er en DAX-ekspert, vil den sannsynligvis forvirre deg ved første øyekast. Den er merkelig nok konstruert med en CALCULATE-setning uten filterklausul og omslutter bare en sumsetning. 

Faktisk er det en av de kjæledyrene mine når jeg ser folk ute på forumene som bruker CALCULATE som bare pakker inn en sum uten grunn. Men i dette tilfellet har det faktisk en grunn.

Det forvirrer meg hver gang jeg ser dem fordi det bare er en umiddelbar indikasjon på at de ikke aner hva de gjør med CALCUATE-funksjonen. Så jeg anbefaler å bare holde seg unna det i stedet. 

DAX-kode for gjennomsnitt per kategori

DAX-koden vist ovenfor bruker . Denne funksjonen er ikke i et CALCUATE-segment, noe som igjen gjør det rart. Denne funksjonen er visstnok bygget for bruk i CALCULATE-setninger basert på dokumentasjonen.

Koden bruker også , som jeg ikke er enig i. De bør aldri bruke VERDIER fordi distinkte verdier har en tendens til å returnere en tom rad hvis det er en rad som ikke samsvarer. Det kan få deg i mye trøbbel, men det er et emne for en annen video.

I hovedsak, det som skjer her er at de bruker en VERDI-funksjon for å få alle kategoriene våre. For eksempel i kvartal 1, det er januar, februar og mars. VALUES returnerer også en tabell, men de bruker en KEEPFILTER-setning for å gjøre den gyldig som en første parameter i . 

De beholder også CALCULATE-funksjonen for å kjøre innenfor konteksten av KEEPFILTERS. På grunn av måten AVERAGEX fungerer på, tar den det andre uttrykket og kjører det innenfor konteksten til det første uttrykket. 

Hva er problemet, da?

Totalt sett fungerer det greit, men ikke for noen nye til DAX. Jeg tror Microsoft virkelig savnet båten da de opprettet dette raske tiltaket fordi raske tiltak visstnok er for folk som er nye til DAX.

Raske mål er en god idé, som "La oss skrive noen vanlige mål med forskjellige beregninger for deg fordi du er ny på DAX og ikke vet alt som er å vite om DAX." Men hvorfor skulle de konstruere dem på så rare, kompliserte måter? 

Hvordan skal noen nye til DAX ta en titt på dette og finne ut hva som skjer når til og med sannsynligvis DAX-profesjonelle klør seg litt i hodet over denne? 

Så for meg gikk de glipp av en gylden mulighet til å hjelpe folk å lære DAX med sine raske tiltak ved å insistere på at de inkluderer CALCUATE og måtte hoppe gjennom bøyler for å få CALCUATE der. 

Den enklere løsningen

Bruke SUMMARIZE-funksjonen

Som jeg har nevnt tidligere, er det en bedre og enklere måte å gjøre det på.

Først oppretter du en tabellvariabel ved å bruke VAR_Table . Deretter bruker vi til å ta tabellen, oppsummere den etter måned, lage en verdikolonne og oppsummere verdiene våre.

Til slutt tar vi gjennomsnittet av verdiene våre ved å bruke AVERAGEX- funksjonen. 

Denne koden er enklere og så mye mer logisk. Den inkluderer ikke CALCUATE, som du uansett ikke trenger. 

Du kan komme over en bloggartikkel der ute som kritiserer SUMMARIZE. Bloggen sier at måten SUMMARIZE fungerer internt på er ganske komplisert.

Det antyder også at du kan få deg selv i trøbbel i ett spesifikt tilfelle, men du vil aldri støte på det. Det ville bare skje hvis beregningen din involverer en veldig kompleks beregning og en veldig stor tabell. Først da vil SUMMARIZE gi deg vanvittige resultater. 

Det er i hvert fall det bloggartikkelen hevder. Og det er greit hvis du vil vike unna SUMMARIZE. Bruk i så fall funksjonen i stedet.

Bruk av GROUPBY-funksjonen

Ingen har problemer med å bruke GROUPBY-funksjonen, så la oss lære hvordan du bruker den også. Igjen, opprett en tabellvariabel ved å bruke VAR_Table. Deretter grupperer vi måneden og oppretter en verdikolonne.

Deretter bruker vi CURRENTGROUP , som er hvordan GROUPBY fungerer. La oss summere verdien vår og igjen ta AVERAGEX over den. 

Koden vår skal se slik ut.

Sammenligning av resultatene: SUMMARIZE vs GROUPBY vs CALCUATE DAX-funksjoner

La oss nå se om snarveiene vi gjorde, gir de samme resultatene. 

Som du kan se på bildene nedenfor, returnerer både SUMMARIZE merket som Better Average Per Category og GROUPBY merket som Better Average Per Category 2 de samme tallene. 

Begge formlene våre gir 3,4K for Q1, 3,6K for Q2, 3,4K for Q3 og 3,5K for Q4. Og igjen, de jobber i en enkelt tabelldatamodell ved å bruke Quarters for tabellen vår.

De fungerer også i et stjerneskjema der vi bruker Quarters i datotabellen vår. 

Konklusjon

Vi trenger ikke å tvinge oss selv inn i en vridd kontekstlogikk bare for å få CALCULATE inn i formlene våre. Bare bruk enkle standard DAX-funksjoner og du kan oppnå de samme tingene. 

Faktisk, sannsynligvis i 80 % – 90 % av tilfellene, er det absolutt ingen grunn til å bry seg med å bruke CALCUATE for noe. I stedet kan du bruke SUMMARIZE- og GROUPBY-funksjonene som er enklere og mer logiske.

Hvis du vil utforske denne PBIX-filen, har jeg allerede publisert den til Quick Measures Gallery og kalt filen Better Average Per Category . Bare scroll hele veien ned på siden for å finne PBIX-filen som du kan laste ned og du leker med deg selv. 

Beste ønsker,

Greg Deckler