DAX ugentlige beregninger – LuckyTemplates Time Intelligence-problemer

I dagens selvstudie vil jeg give nogle teknikker og tips til, hvordan man håndterer almindelige problemer forårsaget af DAX ugentlig granularitet i tidsintelligensberegninger. Du kan se den fulde video af denne tutorial nederst på denne blog.

Jeg lavede for nylig en tutorial om at opnå værdier fra forrige uge i LuckyTemplates. Siden da har jeg fået flere spørgsmål relateret til tidsintelligens og især relateret til DAX ugentlige værdier. Det er ikke overraskende, fordi uger virkelig er den mest dårligt opførte granularitet inden for tidsintelligens-sfæren.

I tilfælde af måneder har du altid 12 måneder på et år. I tilfælde af kvarterer, har du altid fire kvarterer. Uger er forskellige, fordi der er syv dage i en uge og 52 uger i et år – det er 364 dage. Så du har den ekstra dag til at hænge derude. I skudår har du to ekstra dage.

Så det ender faktisk med at i nogle år, baseret på nummereringsskemaet for ISO-ugenummeret, nogle gange have 52 uger, nogle gange 53 uger. Uge 53 er den, der vil give flest problemer.

Indholdsfortegnelse

• Tidsintelligensproblemer i en DAX-ugentlig beregning
• Konklusion

Tidsintelligensproblemer i en DAX-ugentlig beregning

I dette eksempel bruger jeg Total Spot Price. Med totaler er det nemmere at visualisere og tale om.

I dette tilfælde vil vi for hvert af årene vise en linje for uge 53, uanset om der var en uge 53 i det pågældende år eller ej. Så du kan se i 2018 og 2019, der er ingen uge 53, men i 2020 er der. Vi ønsker at have det konsekvent, så den 53. linje ville være i hvert år. Men så ville metrikken være tom for de år, hvor der ikke var et 53. år.

En af de almindelige måder, vi gør det på, er at gå Vis elementer uden data og sørge for, at det er slået til. I dette tilfælde er det slået til, men det vil ikke hjælpe, fordi det virker, når du har en fysisk række, men bare ingen data knyttet til den række. I dette tilfælde har vi ikke engang rækken.

Teknikker som at brugeeller Fjern filtre vil ikke virke, fordi der ikke er noget at fjerne. Filteret på den række eksisterer bare ikke. Og så er spørgsmålet, hvordan vi indsætter den række i hvert år, hvor den ikke eksisterer? Og så bliver dette virkelig et datamodelleringsproblem.

En af de ting, vi potentielt kan gøre, er at gå til en snefnug-ordning, hvor vi filtrerer Datoer-tabellen efter noget, der vil tvinge den 53. uge ind i vores visuelle hvert år. Den funktion, der springer i øjnene for dette, er.

CROSSJOIN bruges til at matche to felter sammen, der muligvis har en relation. De behøver ikke at have et forhold i modsætning til de fleste ellereller andre tabelfunktioner.

I dette tilfælde tager CROSSJOIN to kolonner og opretter hver kombination af disse to kolonner, uanset om den findes i datasættet eller ej. Det er præcis, hvad vi ønsker.

Vi skal lave en tabel ud af kolonnen. CROSSJOIN tager to tabeller og derefter VALUES på ISO-ugenummeret, og vi matcher dem bare. Det vil give os 53 uger hvert år.

Og så tilføjer vi en tredje kolonne til tabellen. Vi kunne gøre dette i Power Query, men det er bare nemmere at vise dig logikken i DAX. Det, vi laver her, er, at vi faktisk tager og sammenkæder året med en bindestreg og derefter ugenummeret, så vi har et nøglefelt til at forbinde det med Datoer-tabellen.

Vi er dog nødt til at arbejde lidt mere her, fordi den måde, som nøglefeltet fungerer i tabellen Datoer, er, at det er en firecifret år-bindestreg og derefter en tocifret uge. Så i tilfælde, hvor ISO-ugenummeret er to cifre, kan vi bare lave den simple sammenkædning. I tilfælde, hvor det er et ciffer, skal vi tage årstallet og derefter sammenkæde det med en bindestreg, derefter et indledende nul og derefter ugenummeret.

Når vi har fået det, kan vi tage den tabel i datamodellen og finde vores Uge & År-kolonne. Derefter slutter vi os til dem i et en-til-mange forhold. Jeg kan altid godt lide at slå denne mulighed på Pin-relaterede felter til toppen af ​​kortet, så når vi tjekker det, kan vi se det med det samme.

Hvis vi går tilbage til det visuelle, er vi nødt til at ændre rækkerne. I stedet for År & Ugenummer vil vi bruge År & Ugenummer fra CROSSJOIN tabellen. Og nu har vi den 53. uge i 2018 med en blank og den 53. uge i 2019 med en blank. I 2020 har vi et faktisk tal, da det har den 53. uge.

Vi kunne stoppe her, bortset fra det faktum, at vi nu er flyttet ud af Star Schema-modellen. Hver gang du bevæger dig væk fra stjerneskemaet i LuckyTemplates, bevæger du dig uden for det område, der generelt betragtes som bedste praksis.

Så for Snowflake Schema er det ikke en stor overtrædelse. Der er tilfælde, hvor du helt sikkert vil bruge det, men hvis du kan undgå det, så prøv at. Det reducerer dobbeltarbejde, men ikke nødvendigvis størrelse. Det giver dig mulighed for at bruge lige tællemål, men der er problemer med ydeevnen og potentielle brugervenlighedsproblemer, og DAX-kompleksiteten stiger helt sikkert. Det forhindrer dig i at opbygge hierarkier på tværs af tabeller, og nok det mest problematiske er, at det virkelig kan ødelægge din evne til at synkronisere slicere på tværs af forskellige felter.

Så selvom dette løser problemet, gør det det på en måde, der ikke er fantastisk. Lad os se, om vi kan gøre det bedre end dette. Lad os hoppe ind i en anden datamodel. I denne model har jeg taget nøjagtig samme data, datoerne og spotprisen, men denne gang har jeg fjernet CROSSJOIN tabellen. Det eksisterer stadig, men det er ikke forbundet.

Men hvis vi ser på DAX, vil vi se, at det er nøjagtig den samme DAX, som skabte den tabel i den anden rapport. Så i stedet for at forbinde det i et fysisk forhold og derefter overtræde stjerneskemaet og konvertere det til et snefnugskema, kan vi opretholde stjerneskemaet og bare bruge et virtuelt forhold.

For at gøre det bruger vi en funktion kaldet. Det skaber det forhold mellem tabeller, men gør det virtuelt. Det gør vi ved at bruge, fordi vi kommer til at ændre konteksten. I dette tilfælde vil konteksten være med hensyn til forholdet. Så vi har fået vores samlede spotpris, og så har vi TREATAS. Vi skal gøre den kolonne til en tabel.

Og så har vi feltet År og uge, som er nøglen, vi har oprettet. Vi har samlet det på en virtuel måde til Uge og år i tabellen Datoer. Så nu har vi den Crossjoint-tabel, der filtrerer Dates-tabellen på samme måde, som den gjorde, da vi havde et fysisk forhold, men uden at overtræde stjerneskemaet.

Vi kan nu tage og slippe den samlede spotpris TREATAS ind i matrixen, og det, vi ser, er nøjagtig de samme totaler. På denne måde har vi gjort det uden at forstyrre vores datamodel og pådrage os nogen af ​​de ulemper, som vi talte om i forhold til Snowflake Schema.

Konklusion

I denne øvelse har jeg vist dig et par måder at løse problemet med DAX-ugentlig beregning i LuckyTemplates. Den ene er ved at bruge CROSSJOIN, men det har nogle ulemper. Den anden måde er ved at bruge TREATAS, skabe et virtuelt forhold og ikke overtræde Star Schema-tilgangen.

Det er en teknik, der er ret nyttig til at håndtere problemet i uge 53. Jeg håber du fandt det nyttigt. Jeg vil gerne vide dine tanker om dette. Fortæl mig det i kommentarerne nedenfor.

Alt det bedste,