Calcule săptămânale DAX – Probleme de inteligență temporală LuckyTemplates

În tutorialul de astăzi, voi oferi câteva tehnici și sfaturi despre cum să rezolvați problemele obișnuite cauzate de granularitatea săptămânală DAX în calculele de inteligență temporală. Puteți viziona videoclipul complet al acestui tutorial în partea de jos a acestui blog.

Am făcut recent un tutorial despre obținerea valorilor din săptămâna anterioară în LuckyTemplates. De atunci, am mai multe întrebări legate de inteligența timpului și în special legate de valorile săptămânale DAX. Nu este surprinzător, deoarece săptămânile sunt într-adevăr cea mai prost comportament granular din sfera de inteligență temporală.

În cazul lunilor, aveți întotdeauna 12 luni într-un an. În cazul sferurilor, ai întotdeauna patru sferturi. Săptămânile sunt diferite, deoarece există șapte zile într-o săptămână și 52 de săptămâni într-un an - adică 364 de zile. Deci, ai acea zi în plus pe acolo. În anii bisecți, ai două zile în plus.

Deci, asta se termină de fapt în câțiva ani, pe baza schemei de numerotare pentru numărul săptămânii ISO, să aibă uneori 52 de săptămâni, alteori 53 de săptămâni. Săptămâna 53 este cea care va cauza cele mai multe probleme.

Cuprins

• Probleme de inteligență temporală ale unui calcul săptămânal DAX
• Concluzie

Probleme de inteligență temporală ale unui calcul săptămânal DAX

În acest exemplu, folosesc Prețul spot total. Cu totaluri, este mai ușor să vizualizați și să vorbiți despre.

În acest caz, pentru fiecare dintre ani, dorim să arătăm o linie pentru săptămâna 53, indiferent dacă a existat o săptămână 53 în acel an sau nu. Deci, puteți vedea în 2018 și 2019, nu există săptămâna 53, dar în 2020, există. Vrem să fie consistentă, astfel încât linia a 53-a să fie în fiecare an. Dar apoi, metrica ar fi necompletată pentru anii în care nu a existat un al 53-lea an.

Una dintre modalitățile obișnuite în care facem asta este să mergem să Afișăm elemente fără date și să ne asigurăm că este activat. În acest caz, este pornit, dar nu va ajuta, deoarece funcționează atunci când aveți un rând fizic, dar nu există date asociate cu acel rând. În acest caz, nici măcar nu avem rândul.

Tehnici precum folosirea sau Eliminarea filtrelor nu vor funcționa, deoarece nu este nimic de eliminat. Filtrul de pe acel rând pur și simplu nu există. Și așa, întrebarea este cum inserăm acel rând în fiecare an în care nu există? Și apoi, aceasta devine cu adevărat o problemă de modelare a datelor.

Unul dintre lucrurile pe care le putem face este să mergem la o schemă de fulgi de zăpadă în care filtrăm tabelul Date după ceva care va forța acea a 53-a săptămână în vizualul nostru în fiecare an. Funcția care vine în minte pentru aceasta este .

CROSSJOIN este folosit pentru a potrivi două câmpuri împreună care pot avea sau nu o relație. Nu trebuie să aibă o relație spre deosebire de majoritatea sau sau alte funcții de tabel.

În acest caz, CROSSJOIN ia două coloane și creează fiecare combinație a acestor două coloane, indiferent dacă aceasta există sau nu în setul de date. Exact asta ne dorim.

Avem noastre pentru a crea un tabel din coloană. CROSSJOIN ia două tabele și apoi VALUES pe numărul săptămânii ISO și le potrivim împreună. Asta ne va oferi 53 de săptămâni în fiecare an.

Și apoi, adăugăm o a treia coloană la tabel. Am putea face acest lucru în Power Query, dar este mai ușor să vă arătăm logica în DAX. Ceea ce facem aici este că de fapt luăm și concatenăm Anul cu o cratimă și apoi numărul săptămânii, astfel încât să avem un câmp cheie pentru a-l uni la tabelul Date.

Cu toate acestea, trebuie să lucrăm mai mult aici, deoarece modul în care câmpul cheie funcționează în tabelul Date este o cratimă An de patru cifre și apoi o săptămână de două cifre. Deci, în cazurile în care numărul săptămânii ISO este de două cifre, putem face doar concatenarea simplă. În cazurile în care este o cifră, trebuie să luăm numărul anului și apoi să îl concatenăm cu o cratimă, apoi cu un zero înainte și apoi cu numărul săptămânii.

Odată ce avem asta, putem lua acel tabel în modelul de date și găsim coloana Săptămâna și Anul. Apoi, ne alăturăm celor într-o relație unu-la-mulți. Îmi place întotdeauna să activez această opțiune pe Câmpurile legate de Pin în partea de sus a cardului, astfel încât atunci când o bifăm, să o putem vedea imediat.

Dacă ne întoarcem la vizual, trebuie să schimbăm rândurile. În loc de numărul Anului și Săptămânii, dorim să folosim numărul Anului și Săptămânii din tabelul CROSSJOIN. Și acum, avem acea a 53-a săptămână din 2018 cu un spațiu liber și a 53-a săptămână din 2019 cu un spațiu liber. În 2020, avem un număr real, deoarece are a 53-a săptămână.

Ne-am putea opri aici, cu excepția faptului că acum ne-am mutat din modelul Star Schema. Ori de câte ori vă îndepărtați de Schema Star din LuckyTemplates, vă mutați în afara domeniului a ceea ce este în general considerat cea mai bună practică.

Și așa, pentru Snowflake Schema, nu este o încălcare mare. Există cazuri în care cu siguranță doriți să-l utilizați, dar dacă îl puteți evita, încercați. Reduce dublarea, dar nu neapărat dimensiunea. Vă permite să utilizați măsuri de numărare directă, dar există probleme de performanță și potențiale probleme de utilizare și, cu siguranță, crește complexitatea DAX. Vă împiedică să construiți ierarhii între tabele și, probabil, cel mai problematic este că vă poate distruge cu adevărat capacitatea de a sincroniza slicere în diferite câmpuri.

Deci, deși acest lucru rezolvă problema, o face într-un mod care nu este grozav. Să vedem dacă putem face mai bine decât asta. Să trecem la alt model de date. În acest model, am luat exact aceleași date, datele și prețul spot, dar de data aceasta am eliminat tabelul CROSSJOIN. Încă există, dar nu este conectat.

Dar dacă ne uităm la DAX, vom vedea că este exact același DAX care a creat acel tabel în celălalt raport. Deci, în loc să o conectăm într-o relație fizică și apoi să încălcăm Schema Stelară și să o transformăm într-o Schemă Fulg de Neadă, putem menține Schema Stelară și doar să folosim o relație virtuală.

Pentru a face asta, vom folosi o funcție numită . Creează acea relație între tabele, dar o face virtual. Facem asta folosind pentru că vom schimba contextul. În acest caz, contextul va fi referitor la relație. Așadar, avem prețul nostru total spot, apoi avem TREATAS. Avem pentru a transforma acea coloană într-un tabel.

Și apoi, avem câmpul An și Săptămâna, care este cheia pe care am creat-o. Le-am alăturat într-un mod virtual la Săptămâna și Anul în tabelul Date. Deci, acum avem acel tabel Crossjoint care filtrează tabelul Date în același mod în care a făcut-o atunci când aveam o relație fizică, dar fără a încălca Schema Stelară.

Putem acum să luăm și să aruncăm acel preț total spot TREATAS în matrice și ceea ce vedem sunt exact aceleași totaluri. În acest fel, am făcut acest lucru fără a perturba modelul nostru de date și fără a suporta niciunul dintre dezavantajele despre care am vorbit în legătură cu Schema fulg de zăpadă.

Obțineți valori LuckyTemplates din săptămâna anterioară folosind DAX și Power Query
Calcularea vânzărilor săptămânale cu DAX în LuckyTemplates
Time Intelligence în DAX: Cum să selectați dinamic perioada de pornire

Concluzie

În acest tutorial, v-am arătat câteva modalități de a aborda problema de calcul săptămânal DAX în LuckyTemplates. Una este utilizarea CROSSJOIN, dar are unele dezavantaje. A doua modalitate este prin utilizarea TREATAS, crearea unei relații virtuale și fără încălcarea abordării Schemei Stelare.

Aceasta este o tehnică care este destul de utilă pentru a rezolva problema din săptămâna 53. Sper că ați găsit asta util. Vreau să știu părerile tale despre asta. Anunță-mă în comentariile de mai jos.

Toate cele bune,