Calcoli settimanali DAX: problemi di LuckyTemplates Time Intelligence

Nell'esercitazione di oggi verranno fornite alcune tecniche e suggerimenti su come gestire i problemi comuni causati dalla granularità settimanale di DAX nei calcoli di Time Intelligence. Puoi guardare il video completo di questo tutorial in fondo a questo blog.

Di recente ho fatto un tutorial su come ottenere i valori della settimana precedente in LuckyTemplates. Da allora, ho diverse domande relative all'intelligenza temporale e in particolare relative ai valori settimanali DAX. Non è sorprendente perché le settimane sono davvero la granularità più mal gestita nella sfera dell'intelligenza temporale.

Nel caso dei mesi, hai sempre 12 mesi in un anno. Nel caso dei quarti, hai sempre quattro quarti. Le settimane sono diverse perché ci sono sette giorni in una settimana e 52 settimane in un anno, ovvero 364 giorni. Quindi, hai quel giorno in più in giro là fuori. Negli anni bisestili hai due giorni in più.

Quindi, in realtà in alcuni anni, in base allo schema di numerazione per il numero della settimana ISO, si arriva a volte a 52 settimane, a volte a 53 settimane. La settimana 53 è quella che causerà più problemi.

Sommario

• Problemi di Time Intelligence di un calcolo settimanale DAX
• Conclusione

Problemi di Time Intelligence di un calcolo settimanale DAX

In questo esempio, sto utilizzando il prezzo spot totale. Con i totali, è più facile visualizzare e parlare.

In questo caso, per ciascuno degli anni, vogliamo mostrare una linea per la settimana 53, indipendentemente dal fatto che ci sia stata o meno una settimana 53 in quell'anno. Quindi, puoi vedere nel 2018 e nel 2019, non c'è la settimana 53, ma nel 2020 c'è. Vogliamo che sia coerente in modo che la 53a riga sia presente ogni anno. Ma poi, la metrica sarebbe vuota per gli anni in cui non c'era un 53esimo anno.

Uno dei modi comuni in cui lo facciamo è andare a Mostra elementi senza dati e assicurarci che sia attivato. In questo caso, è attivato, ma non aiuterà perché funziona quando hai una riga fisica, ma solo nessun dato associato a quella riga. In questo caso, non abbiamo nemmeno la fila.

Tecniche come l'utilizzo di o Rimuovi filtri non funzioneranno perché non c'è nulla da rimuovere. Il filtro su quella riga semplicemente non esiste. E quindi, la domanda è come inseriamo quella riga in ogni anno in cui non esiste? E poi, questo diventa davvero un problema di modellazione dei dati.

Una delle cose che possiamo potenzialmente fare è andare a uno schema a fiocco di neve in cui filtriamo la tabella delle date in base a qualcosa che forzerà la 53a settimana nella nostra visuale ogni anno. La funzione che mi viene in mente per questo è .

CROSSJOIN viene utilizzato per abbinare due campi che possono avere o meno una relazione. Non devono avere una relazione a differenza della maggior parte o o altre funzioni di tabella.

In questo caso, CROSSJOIN prende due colonne e crea ogni combinazione di queste due colonne, indipendentemente dal fatto che esista o meno nel set di dati. Questo è esattamente quello che vogliamo.

Abbiamo i nostri per creare una tabella fuori dalla colonna. CROSSJOIN prende due tabelle e poi VALUES sul numero della settimana ISO, e le abbiniamo semplicemente insieme. Questo ci darà 53 settimane all'anno.

E poi, aggiungiamo una terza colonna alla tabella. Potremmo farlo in Power Query, ma è solo più semplice mostrarti la logica in DAX. Quello che stiamo facendo qui è prendere e concatenare l'anno con un trattino, e poi il numero della settimana, in modo da avere un campo chiave per unirlo alla tabella delle date.

Tuttavia, dobbiamo fare un po' più di lavoro qui perché il modo in cui il campo chiave funziona nella tabella Date è un trattino dell'anno a quattro cifre e poi una settimana a due cifre. Quindi, nei casi in cui il numero della settimana ISO è di due cifre, possiamo semplicemente fare la semplice concatenazione. Nei casi in cui è una cifra, dobbiamo prendere il numero dell'anno e poi concatenarlo con un trattino, poi uno zero iniziale e poi il numero della settimana.

Una volta ottenuto questo, possiamo prendere quella tabella nel modello di dati e trovare la nostra colonna Settimana e anno. Quindi, ci uniamo a quelli in una relazione uno-a-molti. Mi piace sempre attivare questa opzione sui campi relativi ai Pin nella parte superiore della carta in modo che quando la controlliamo, possiamo vederla subito.

Se torniamo all'aspetto visivo, dobbiamo cambiare le righe. Invece del numero dell'anno e della settimana, vogliamo utilizzare il numero dell'anno e della settimana dalla tabella CROSSJOIN. E ora, abbiamo quella 53a settimana nel 2018 con uno spazio vuoto e la 53a settimana nel 2019 con uno spazio vuoto. Nel 2020, abbiamo un numero effettivo poiché ha la 53a settimana.

Potremmo fermarci qui, tranne per il fatto che ora siamo usciti dal modello Star Schema. Ogni volta che ti allontani dallo schema a stella in LuckyTemplates, ti sposti al di fuori del regno di ciò che è generalmente considerato la migliore pratica.

E così, per Snowflake Schema, non è una grande violazione. Ci sono casi in cui potresti sicuramente volerlo usare, ma se puoi evitarlo, prova a farlo. Riduce la duplicazione, ma non necessariamente le dimensioni. Ti consente di utilizzare misure di conteggio diretto, ma ci sono problemi di prestazioni e potenziali problemi di usabilità e aumenta decisamente la complessità DAX. Ti impedisce di creare gerarchie tra le tabelle e probabilmente il più problematico è che può davvero rovinare la tua capacità di sincronizzare affettatrici su diversi campi.

Quindi, mentre questo risolve il problema, lo fa in un modo che non è eccezionale. Vediamo se possiamo fare meglio di così. Passiamo a un altro modello di dati. In questo modello, ho preso gli stessi identici dati, le date e il prezzo spot, ma questa volta ho rimosso la tabella CROSSJOIN. Esiste ancora, ma non è connesso.

Ma se guardiamo al DAX, vedremo che è esattamente lo stesso DAX che ha creato quella tabella nell'altro report. Quindi, invece di collegarlo in una relazione fisica, e poi violare lo Star Schema e convertirlo in uno Snowflake Schema, possiamo mantenere lo Star Schema e usare solo una relazione virtuale.

Per farlo, useremo una funzione chiamata . Crea quella relazione tra i tavoli ma lo fa virtualmente. Lo facciamo usando perché cambieremo il contesto. In questo caso, il contesto sarà relativo alla relazione. Quindi, abbiamo il nostro prezzo spot totale e poi abbiamo TREATAS. Abbiamo il per trasformare quella colonna in una tabella.

E poi, abbiamo il campo Year & Week, che è la chiave che abbiamo creato. L'abbiamo unito in modo virtuale a Settimana e anno nella tabella Date. Quindi ora abbiamo quella tabella Crossjoint che filtra la tabella Date nello stesso modo in cui lo faceva quando avevamo una relazione fisica, ma senza violare lo Star Schema.

Ora possiamo prendere e rilasciare il prezzo spot totale TREATAS nella matrice e ciò che vediamo sono esattamente gli stessi totali. In questo modo, lo abbiamo fatto senza interrompere il nostro modello di dati e incorrere in nessuno degli svantaggi di cui abbiamo parlato in relazione allo schema Snowflake.

Ottieni i valori della settimana precedente di LuckyTemplates utilizzando DAX e Power Query
Calcolo delle vendite settimanali con DAX In LuckyTemplates
Time Intelligence In DAX: come selezionare dinamicamente il periodo iniziale

Conclusione

In questo tutorial, ti ho mostrato un paio di modi per affrontare il problema del calcolo settimanale DAX in LuckyTemplates. Uno è l'utilizzo di CROSSJOIN, ma presenta alcuni svantaggi. Il secondo modo è utilizzare TREATAS, creando una relazione virtuale e non violando l'approccio Star Schema.

Questa è una tecnica molto utile per affrontare il problema della settimana 53. Spero che tu l'abbia trovato utile. Voglio conoscere i tuoi pensieri su questo. Fammi sapere nei commenti qui sotto.

Ti auguro il meglio,