DAX Weekly Calculations – LuckyTemplates Time Intelligence Issues

I dagens handledning kommer jag att ge några tekniker och tips om hur man hanterar vanliga problem som orsakas av DAX veckovisa granularitet i tidsintelligensberäkningar. Du kan se hela videon av denna handledning längst ner på den här bloggen.

Jag gjorde nyligen en handledning om att få värden för föregående vecka i LuckyTemplates. Sedan dess har jag fått flera frågor relaterade till tidsintelligens och särskilt relaterade till DAX veckovärden. Det är inte förvånande eftersom veckor verkligen är den sämst uppförda granulariteten inom tidsintelligenssfären.

När det gäller månader har du alltid 12 månader på ett år. När det gäller kvarter har du alltid fyra kvarter. Veckor är olika eftersom det är sju dagar på en vecka och 52 veckor på ett år – det är 364 dagar. Så, du har den där extra dagen där ute. Under skottår har du två extra dagar.

Så, det slutar faktiskt i vissa år, baserat på numreringsschemat för ISO-veckonummer, att ibland ha 52 veckor, ibland 53 veckor. Vecka 53 är den som kommer att orsaka flest problem.

Innehållsförteckning

• Tidsintelligensfrågor i en DAX-veckoberäkning
• Slutsats

Tidsintelligensfrågor i en DAX-veckoberäkning

I det här exemplet använder jag Total Spot Price. Med totaler är det lättare att visualisera och prata om.

I det här fallet vill vi för vart och ett av åren visa en linje för vecka 53, oavsett om det fanns en vecka 53 det året eller inte. Så du kan se 2018 och 2019, det finns ingen vecka 53, men 2020 finns det. Vi vill ha det konsekvent så att den 53:e linjen skulle vara i varje år. Men då skulle måttet vara tomt för de år då det inte fanns ett 53:e år.

Ett av de vanligaste sätten vi gör det är att gå Visa objekt utan data och se till att den är påslagen. I det här fallet är det aktiverat, men det kommer inte att hjälpa eftersom det fungerar när du har en fysisk rad, men bara ingen data kopplad till den raden. I det här fallet har vi inte ens raden.

Tekniker som att användaeller Ta bort filter kommer inte att fungera eftersom det inte finns något att ta bort. Filtret på den raden finns helt enkelt inte. Och så, frågan är hur vi infogar den raden i varje år som den inte existerar? Och då blir detta verkligen ett datamodelleringsproblem.

En av de saker vi potentiellt kan göra är att gå till ett snöflingaschema där vi filtrerar datumtabellen efter något som kommer att tvinga in den 53:e veckan i vår visuella bild varje år. Funktionen som hoppar till minnet för detta är.

CROSSJOIN används för att matcha två fält som kan ha en relation eller inte. De behöver inte ha ett förhållande till skillnad från de flesta eller, eller andra tabellfunktioner.

I det här fallet tar CROSSJOIN två kolumner och skapar varje kombination av dessa två kolumner, oavsett om det finns i datamängden eller inte. Det är precis vad vi vill.

Vi måste skapa en tabell från kolumnen. CROSSJOIN tar två tabeller och sedan VÄRDEN på ISO-veckans nummer, och vi matchar dem bara. Det kommer att ge oss 53 veckor varje år.

Och sedan lägger vi till en tredje kolumn i tabellen. Vi skulle kunna göra detta i Power Query, men det är bara lättare att visa logiken i DAX. Vad vi gör här är att vi faktiskt tar och sammanfogar året med ett bindestreck och sedan veckonumret, så att vi har ett nyckelfält för att koppla det till datumtabellen.

Men vi måste göra lite mer arbete här eftersom nyckelfältet fungerar i tabellen Datum är att det är ett fyrsiffrigt år bindestreck och sedan en tvåsiffrig vecka. Så i fall där ISO-veckans nummer är tvåsiffrigt kan vi bara göra den enkla sammanlänkningen. I de fall där det är en siffra måste vi ta årtalet och sedan sammanfoga det med ett bindestreck, sedan en inledande nolla och sedan veckonumret.

När vi väl har det kan vi ta den tabellen i datamodellen och hitta kolumnen Vecka & År. Sedan sammanfogar vi dem i ett en-till-många-förhållande. Jag gillar alltid att aktivera det här alternativet på Pin-relaterade fält till toppen av kortet så att vi kan se det direkt när vi kontrollerar det.

Om vi ​​går tillbaka till det visuella, måste vi ändra raderna. Istället för år & veckonummer vill vi använda år & veckonummer från CROSSJOIN-tabellen. Och nu har vi den 53:e veckan i 2018 med en tom, och den 53:e veckan i 2019 med en tom. År 2020 har vi ett verkligt antal eftersom det har den 53:e veckan.

Vi kunde sluta här, förutom det faktum att vi nu har flyttat ut från Star Schema-modellen. Varje gång du går bort från stjärnschemat i LuckyTemplates, rör du dig utanför sfären av vad som allmänt anses vara bästa praxis.

Och så, för Snowflake Schema, är det inte en stor överträdelse. Det finns fall där du kanske definitivt vill använda det, men om du kan undvika det, försök att göra det. Det minskar dubbelarbete, men inte nödvändigtvis storleken. Det låter dig använda raka räkningsmått, men det finns prestandaproblem och potentiella användbarhetsproblem, och definitivt ökar DAX-komplexiteten. Det hindrar dig från att bygga hierarkier över tabeller, och förmodligen det mest problematiska är att det verkligen kan förstöra din förmåga att synkronisera slicers över olika fält.

Så även om detta löser problemet, gör det det på ett sätt som inte är bra. Låt oss se om vi kan göra bättre än så här. Låt oss hoppa in i en annan datamodell. I den här modellen har jag tagit exakt samma data, datumen och spotpriset, men den här gången har jag tagit bort CROSSJOIN-tabellen. Det finns fortfarande, men det är inte kopplat.

Men om vi tittar på DAX kommer vi att se att det är exakt samma DAX som skapade den tabellen i den andra rapporten. Så istället för att koppla ihop det i en fysisk relation, och sedan bryta mot stjärnschemat och omvandla det till ett snöflingaschema, kan vi underhålla stjärnschemat och bara använda en virtuell relation.

För att göra det använder vi en funktion som heter. Det skapar den relationen mellan tabeller men gör det virtuellt. Vi gör det med hjälp av eftersom vi kommer att ändra sammanhanget. I det här fallet kommer sammanhanget att vara med avseende på relationen. Så, vi har vårt totala spotpris, och sedan har vi TREATAS. Vi måste förvandla den kolumnen till en tabell.

Och så har vi fältet År och vecka, som är nyckeln som vi skapade. Vi har förenat det på ett virtuellt sätt till Vecka & År i tabellen Datum. Så nu har vi den där Crossjoint-tabellen som filtrerar tabellen Datum på samma sätt som den gjorde när vi hade en fysisk relation, men utan att bryta mot stjärnschemat.

Vi kan nu ta och släppa det totala spotpriset TREATAS i matrisen och vad vi ser är exakt samma summor. På detta sätt har vi gjort det utan att störa vår datamodell och ådra sig några av de nackdelar som vi pratade om i förhållande till Snowflake Schema.

Slutsats

I den här handledningen har jag visat dig ett par sätt att ta itu med problemet med DAX-veckoberäkning i LuckyTemplates. En är genom att använda CROSSJOIN, men det har vissa nackdelar. Det andra sättet är att använda TREATAS, skapa en virtuell relation och inte bryta mot Star Schema-metoden.

Det är en teknik som är ganska användbar för att hantera problemet med vecka 53. Jag hoppas att du tyckte att det var användbart. Jag vill veta dina tankar om detta. Låt mig veta i kommentarerna nedan.

Med vänliga hälsningar,