DAX ukentlige beregninger – LuckyTemplates Time Intelligence-problemer

I dagens veiledning vil jeg gi noen teknikker og tips om hvordan du kan håndtere vanlige problemer forårsaket av DAX ukentlig granularitet i beregninger av tidsintelligens. Du kan se hele videoen av denne opplæringen nederst på denne bloggen.

Jeg har nylig laget en opplæring om å skaffe forrige ukes verdier i LuckyTemplates. Siden den gang har jeg fått flere spørsmål knyttet til tidsintelligens og spesielt knyttet til ukentlige DAX-verdier. Det er ikke overraskende fordi uker egentlig er den mest dårlig oppførte granulariteten i tidsintelligenssfæren.

Når det gjelder måneder, har du alltid 12 måneder på et år. Når det gjelder kvartaler, har du alltid fire kvartaler. Uker er forskjellige fordi det er syv dager i en uke og 52 uker i et år - det er 364 dager. Så, du har den ekstra dagen til å henge der ute. I skuddår har du to ekstra dager.

Så, det ender faktisk opp i noen år, basert på nummereringsskjemaet for ISO-ukenummeret, til å ha noen ganger 52 uker, noen ganger 53 uker. Uke 53 er den som kommer til å skape flest problemer.

Innholdsfortegnelse

• Tidsinformasjonsproblemer i en DAX-ukentlig beregning
• Konklusjon

Tidsinformasjonsproblemer i en DAX-ukentlig beregning

I dette eksemplet bruker jeg Total Spot Price. Med totaler er det lettere å visualisere og snakke om.

I dette tilfellet, for hvert av årene, ønsker vi å vise en linje for uke 53, om det var en uke 53 i det året eller ikke. Så du kan se i 2018 og 2019, det er ingen uke 53, men i 2020 er det det. Vi ønsker å ha det konsistent slik at 53. linje vil være i hvert år. Men da ville beregningen være blank for årene der det ikke var et 53. år.

En av de vanlige måtene vi gjør det på er å gå Vis elementer uten data og sørge for at den er slått på. I dette tilfellet er det slått på, men det kommer ikke til å hjelpe fordi det fungerer når du har en fysisk rad, men bare ingen data knyttet til den raden. I dette tilfellet har vi ikke engang raden.

Teknikker som å brukeeller Fjern filtre kommer ikke til å fungere fordi det ikke er noe å fjerne. Filteret på den raden eksisterer bare ikke. Og så er spørsmålet hvordan vi setter inn den raden i hvert år der den ikke eksisterer? Og da blir dette virkelig et datamodelleringsproblem.

En av tingene vi potensielt kan gjøre er å gå til et snøfnuggopplegg der vi filtrerer Datoer-tabellen etter noe som vil tvinge den 53. uken inn i det visuelle vårt hvert år. Funksjonen som hopper til tankene for dette er.

CROSSJOIN brukes til å matche to felt sammen som kan ha et forhold eller ikke. De trenger ikke ha et forhold i motsetning til de fleste eller, eller andre tabellfunksjoner.

I dette tilfellet tar CROSSJOIN to kolonner og oppretter hver kombinasjon av disse to kolonnene, enten det finnes i datasettet eller ikke. Det er akkurat det vi ønsker.

Vi må lage en tabell ut av kolonnen. CROSSJOIN tar to tabeller og deretter VERDIER på ISO-ukenummeret, og vi matcher dem bare. Det kommer til å gi oss 53 uker hvert år.

Og så legger vi til en tredje kolonne i tabellen. Vi kunne gjøre dette i Power Query, men det er bare enklere å vise deg logikken i DAX. Det vi gjør her er at vi faktisk tar og setter sammen året med en bindestrek, og deretter ukenummeret, slik at vi har et nøkkelfelt for å slå det sammen med Datoer-tabellen.

Vi må imidlertid gjøre litt mer arbeid her fordi måten nøkkelfeltet fungerer på i Datoer-tabellen er at det er en firesifret år-bindestrek og deretter en tosifret uke. Så, i tilfeller der ISO-ukenummeret er to sifre, kan vi bare gjøre den enkle sammenkoblingen. I tilfeller der det er ett siffer, må vi ta årstallet og deretter sette det sammen med en bindestrek, deretter en innledende null og deretter ukenummeret.

Når vi har fått det, kan vi ta den tabellen i datamodellen og finne Uke og år-kolonnen. Deretter blir vi med dem i et en-til-mange-forhold. Jeg liker alltid å slå dette alternativet på Pin-relaterte felt til toppen av kortet, slik at når vi sjekker det, kan vi se det med en gang.

Hvis vi går tilbake til det visuelle, må vi endre radene. I stedet for år- og ukenummer ønsker vi å bruke år- og ukenummer fra CROSSJOIN-tabellen. Og nå har vi den 53. uken i 2018 med en blank, og den 53. uken i 2019 med en blank. I 2020 har vi et faktisk tall siden det har den 53. uken.

Vi kunne stoppet her, bortsett fra det faktum at vi nå har flyttet ut av Star Schema-modellen. Hver gang du beveger deg bort fra stjerneskjemaet i LuckyTemplates, beveger du deg utenfor riket av det som generelt anses som beste praksis.

Og så, for Snowflake Schema, er det ikke et stort brudd. Det er tilfeller der du definitivt vil bruke det, men hvis du kan unngå det, prøv å. Det reduserer duplisering, men ikke nødvendigvis størrelsen. Den lar deg bruke direkte tellemål, men det er ytelsesproblemer og potensielle brukervennlighetsproblemer, og definitivt øker DAX-kompleksiteten. Det hindrer deg i å bygge hierarkier på tvers av tabeller, og sannsynligvis det mest problematiske er at det virkelig kan ødelegge evnen din til å synkronisere slicere på tvers av forskjellige felt.

Så selv om dette løser problemet, gjør det det på en måte som ikke er bra. La oss se om vi kan gjøre det bedre enn dette. La oss hoppe inn i en annen datamodell. I denne modellen har jeg tatt nøyaktig samme data, datoene og spotprisen, men denne gangen har jeg fjernet CROSSJOIN-tabellen. Den eksisterer fortsatt, men den er ikke tilkoblet.

Men hvis vi ser på DAX, vil vi se at det er nøyaktig samme DAX som laget den tabellen i den andre rapporten. Så i stedet for å koble det til et fysisk forhold, og deretter bryte stjerneskjemaet, og konvertere det til et snøfnuggskjema, kan vi opprettholde stjerneskjemaet og bare bruke et virtuelt forhold.

For å gjøre det bruker vi en funksjon kalt. Det skaper det forholdet mellom tabeller, men gjør det virtuelt. Vi gjør det ved å bruke fordi vi kommer til å endre konteksten. I dette tilfellet vil konteksten være med hensyn til forholdet. Så vi har fått vår totale spotpris, og så har vi TREATAS. Vi må gjøre den kolonnen til en tabell.

Og så har vi feltet År og uke, som er nøkkelen vi har laget. Vi har lagt det sammen på en virtuell måte til Uke og år i Datoer-tabellen. Så nå har vi den Crossjoint-tabellen som filtrerer Datoer-tabellen på samme måte som den gjorde da vi hadde et fysisk forhold, men uten å bryte stjerneskjemaet.

Vi kan nå ta og slippe den totale spotprisen TREATAS inn i matrisen, og det vi ser er nøyaktig samme totalsum. På denne måten har vi gjort det uten å forstyrre datamodellen vår og pådra oss noen av ulempene som vi snakket om i forhold til Snowflake Schema.

Konklusjon

I denne opplæringen har jeg vist deg et par måter å løse problemet med DAX-ukentlig beregning i LuckyTemplates. Den ene er ved å bruke CROSSJOIN, men den har noen ulemper. Den andre måten er å bruke TREATAS, skape et virtuelt forhold og ikke bryte Star Schema-tilnærmingen.

Det er en teknikk som er ganske nyttig for å håndtere problemet i uke 53. Jeg håper du fant det nyttig. Jeg vil vite dine tanker om dette. Gi meg beskjed i kommentarene nedenfor.

Beste ønsker,