Wekelijkse DAX-berekeningen – LuckyTemplates Time Intelligence-problemen

In de tutorial van vandaag zal ik enkele technieken en tips geven over hoe om te gaan met veelvoorkomende problemen die worden veroorzaakt door DAX wekelijkse granulariteit in tijdintelligentieberekeningen. Je kunt de volledige video van deze tutorial onderaan deze blog bekijken.

Ik heb onlangs een zelfstudie gedaan over het verkrijgen van waarden van vorige week in LuckyTemplates. Sindsdien heb ik verschillende vragen met betrekking tot tijdinformatie en in het bijzonder met betrekking tot wekelijkse DAX-waarden. Dat is niet verwonderlijk, want weken zijn echt de slechtst gedragen granulariteit op het gebied van tijdintelligentie.

In het geval van maanden heb je altijd 12 maanden in een jaar. In het geval van kwartalen heb je altijd vier kwartalen. Weken zijn verschillend omdat er zeven dagen in een week zijn en 52 weken in een jaar – dat zijn 364 dagen. Dus je hebt die extra dag om daar rond te hangen. In schrikkeljaren heb je twee extra dagen.

Dus dat komt in sommige jaren, op basis van het nummeringsschema voor het ISO-weeknummer, soms uit op 52 weken, soms op 53 weken. Week 53 is degene die de meeste problemen gaat veroorzaken.

Inhoudsopgave

• Tijdintelligentiekwesties van een wekelijkse DAX-berekening
• Conclusie

Tijdintelligentiekwesties van een wekelijkse DAX-berekening

In dit voorbeeld gebruik ik de totale spotprijs. Met totalen is het gemakkelijker om te visualiseren en erover te praten.

In dit geval willen we voor elk van de jaren een lijn tonen voor week 53, of er in dat jaar een week 53 was of niet. Dus je kunt zien dat er in 2018 en 2019 geen week 53 is, maar in 2020 wel. We willen het consistent hebben, zodat de 53e lijn elk jaar zou zijn. Maar dan zou de statistiek blanco zijn voor de jaren waarin er geen 53e jaar was.

Een van de gebruikelijke manieren waarop we dat doen, is door items zonder gegevens weer te geven en ervoor te zorgen dat deze is ingeschakeld. In dit geval is het ingeschakeld, maar het zal niet helpen, want dat werkt als je een fysieke rij hebt, maar er zijn gewoon geen gegevens aan die rij gekoppeld. In dit geval hebben we niet eens de rij.

Technieken zoals gebruiken of Filters verwijderen zullen niet werken omdat er niets te verwijderen is. Het filter op die rij bestaat gewoon niet. En dus is de vraag hoe we die rij invoegen in elk jaar waarin hij niet bestaat? En dan wordt dit echt een datamodelleringsprobleem.

Een van de dingen die we mogelijk kunnen doen, is naar een sneeuwvlokschema gaan, waarbij we de tabel Datums filteren op iets dat die 53e week elk jaar in onze visual dwingt. De functie die hierbij in je opkomt is .

CROSSJOIN wordt gebruikt om twee velden met elkaar te matchen die al dan niet een relatie hebben. Ze hoeven geen relatie te hebben in tegenstelling tot de meeste of of andere tabelfuncties.

In dit geval neemt CROSSJOIN twee kolommen en maakt elke combinatie van die twee kolommen, of die nu in de dataset voorkomt of niet. Dat is precies wat we willen.

We hebben onze om een ​​tabel uit de kolom te maken. CROSSJOIN neemt twee tabellen en dan VALUES op het ISO-weeknummer, en we matchen die gewoon bij elkaar. Dat geeft ons 53 weken per jaar.

En dan voegen we een derde kolom toe aan de tabel. We zouden dit kunnen doen in Power Query, maar het is gewoon eenvoudiger om u de logica in DAX te laten zien. Wat we hier doen, is dat we het jaar samenvoegen met een koppelteken en vervolgens het weeknummer, zodat we een sleutelveld hebben om het samen te voegen met de tabel Datums.

We moeten hier echter wat meer werk verzetten, want de manier waarop het sleutelveld in de tabel Datums werkt, is een viercijferig koppelteken voor een jaar en vervolgens een tweecijferige week. Dus in gevallen waarin het ISO-weeknummer uit twee cijfers bestaat, kunnen we gewoon de eenvoudige aaneenschakeling doen. In gevallen waarin het uit één cijfer bestaat, moeten we het jaartal nemen en dat vervolgens samenvoegen met een koppelteken, dan een voorloopnul en dan het weeknummer.

Als we dat eenmaal hebben, kunnen we die tabel in het datamodel nemen en onze Week & Jaar-kolom vinden. Vervolgens voegen we die toe aan een een-op-veel-relatie. Ik zet deze optie altijd graag aan Pin-gerelateerde velden bovenaan de kaart , zodat we het meteen kunnen zien als we het controleren.

Als we teruggaan naar de visual, moeten we de rijen veranderen. In plaats van het jaar- en weeknummer willen we het jaar- en weeknummer uit de tabel CROSSJOIN gebruiken. En nu hebben we die 53e week in 2018 met een blanco, en de 53e week in 2019 met een blanco. In 2020 hebben we een reëel aantal omdat het de 53e week heeft.

We zouden hier kunnen stoppen, behalve dat we nu uit het Star Schema-model zijn gestapt. Telkens wanneer u het Star Schema in LuckyTemplates verlaat, gaat u buiten het gebied van wat algemeen als best practice wordt beschouwd.

En dus is het voor Snowflake Schema geen grote overtreding. Er zijn gevallen waarin u het zeker wilt gebruiken, maar als u het kunt vermijden, probeer het dan. Het vermindert duplicatie, maar niet noodzakelijkerwijs de grootte. Hiermee kunt u rechtstreekse tellingsmetingen gebruiken, maar er zijn prestatieproblemen en mogelijke bruikbaarheidsproblemen, en neemt zeker toe in DAX-complexiteit. Het verhindert dat u hiërarchieën over tabellen opbouwt, en waarschijnlijk het meest problematische is dat het uw vermogen om slicers over verschillende velden te synchroniseren echt kan verstoren.

Dus hoewel dit het probleem oplost, doet het dit op een manier die niet geweldig is. Laten we eens kijken of we het beter kunnen doen dan dit. Laten we naar een ander gegevensmodel springen. In dit model heb ik exact dezelfde gegevens, de datums en de spotprijs genomen, maar deze keer heb ik de CROSSJOIN-tabel verwijderd. Het bestaat nog steeds, maar het is niet aangesloten.

Maar als we naar de DAX kijken, zien we dat het exact dezelfde DAX is die die tabel in het andere rapport heeft gemaakt. Dus in plaats van het te verbinden in een fysieke relatie, en dan het Star Schema te schenden en dat om te zetten in een Snowflake Schema, kunnen we het Star Schema behouden en gewoon een virtuele relatie gebruiken.

Om dat te doen, gebruiken we een functie genaamd . Het creëert die relatie tussen tabellen, maar doet dit virtueel. We doen dat met omdat we de context gaan veranderen. In dit geval zal de context betrekking hebben op de relatie. Dus we hebben onze totale spotprijs en dan hebben we TREATAS. We hebben de om van die kolom een ​​tabel te maken.

En dan hebben we het veld Jaar en week, de sleutel die we hebben gemaakt. We hebben dat op een virtuele manier samengevoegd met Week & Jaar in de tabel Datums. Dus nu hebben we die Crossjoint-tabel die de Dates-tabel filtert op dezelfde manier als toen we een fysieke relatie hadden, maar zonder het Star Schema te schenden.

We kunnen nu die Total Spot Price TREATAS in de matrix nemen en laten vallen en wat we zien zijn exact dezelfde totalen. Op deze manier hebben we dit gedaan zonder ons datamodel te verstoren en de nadelen op te lopen waar we het over hadden met betrekking tot het Snowflake Schema.

Waarden van vorige week in LuckyTemplates ophalen met behulp van DAX en Power Query
Wekelijkse verkopen berekenen met DAX In LuckyTemplates
Tijdinformatie in DAX: hoe u de startperiode dynamisch kunt selecteren

Conclusie

In deze zelfstudie heb ik u een aantal manieren laten zien om het probleem met de wekelijkse DAX-berekening in LuckyTemplates aan te pakken. Een daarvan is door CROSSJOIN te gebruiken, maar het heeft enkele nadelen. De tweede manier is door TREATAS te gebruiken, een virtuele relatie te creëren en de Star Schema-benadering niet te schenden.

Dat is een techniek die best handig is om met dat probleem van week 53 om te gaan. Ik hoop dat je dat nuttig vond. Ik wil uw mening hierover weten. Laat het me weten in de reacties hieronder.

Al het beste,