Cotygodniowe obliczenia języka DAX — problemy z analizą czasową usługi LuckyTemplates

W dzisiejszym samouczku przedstawię kilka technik i wskazówek, jak radzić sobie z typowymi problemami powodowanymi przez cotygodniową szczegółowość DAX w obliczeniach analizy czasowej. Możesz obejrzeć pełny film z tego samouczka na dole tego bloga.

Niedawno zrobiłem samouczek dotyczący uzyskiwania wartości z poprzedniego tygodnia w usłudze LuckyTemplates. Od tego czasu mam kilka pytań związanych z analizą czasową, aw szczególności z wartościami tygodniowymi DAX. Nie jest to zaskakujące, ponieważ tygodnie są naprawdę najgorzej zachowującymi się ziarnistościami w sferze inteligencji czasowej.

W przypadku miesięcy zawsze masz 12 miesięcy w roku. W przypadku ćwiartek zawsze masz cztery ćwiartki. Tygodnie są inne, ponieważ w tygodniu jest siedem dni, a w roku 52 tygodnie – czyli 364 dni. Więc masz ten dodatkowy dzień spędzania czasu. W latach przestępnych masz dwa dodatkowe dni.

Tak więc to faktycznie kończy się po kilku latach, w oparciu o schemat numeracji dla numeru tygodnia ISO, czasami 52 tygodnie, czasami 53 tygodnie. Tydzień 53 jest tym, który spowoduje najwięcej problemów.

Spis treści

• Problemy z analizą czasu w obliczeniach tygodniowych języka DAX
• Wniosek

Problemy z analizą czasu w obliczeniach tygodniowych języka DAX

W tym przykładzie używam Total Spot Price. Dzięki sumom łatwiej jest wizualizować i mówić o nich.

W tym przypadku dla każdego roku chcemy pokazać linię dla tygodnia 53, niezależnie od tego, czy w tym roku był tydzień 53, czy nie. Widzicie więc, że w 2018 i 2019 roku nie ma tygodnia 53, ale w 2020 roku jest. Chcemy, aby było to spójne, aby 53. linia była w każdym roku. Ale wtedy metryka byłaby pusta dla lat, w których nie było 53. roku.

Jednym z typowych sposobów na to jest przejście do opcji Pokaż elementy bez danych i upewnienie się, że jest włączona. W tym przypadku jest włączony, ale nie pomoże, ponieważ działa, gdy masz fizyczny wiersz, ale po prostu nie ma danych powiązanych z tym wierszem. W tym przypadku nie mamy nawet wiersza.

Techniki takie jak użycie lub Usuń filtry nie będą działać, ponieważ nie ma nic do usunięcia. Filtr w tym wierszu po prostu nie istnieje. A więc pytanie brzmi: jak wstawić ten wiersz do każdego roku, w którym go nie ma? A potem to naprawdę staje się problemem modelowania danych.

Jedną z rzeczy, które możemy potencjalnie zrobić, jest przejście do schematu płatka śniegu, w którym filtrujemy tabelę Daty według czegoś, co każdego roku wymusza wyświetlanie tego 53. tygodnia w naszej grafice. Funkcja, która przychodzi na myśl, to .

CROSSJOIN służy do dopasowywania dwóch pól, które mogą, ale nie muszą, mieć związek. Nie muszą mieć relacji w przeciwieństwie do większości lub lub innych funkcji tabelowych.

W tym przypadku CROSSJOIN pobiera dwie kolumny i tworzy każdą kombinację tych dwóch kolumn, niezależnie od tego, czy istnieje ona w zbiorze danych, czy nie. Właśnie tego chcemy.

Mamy nasze , aby utworzyć tabelę z kolumny. CROSSJOIN bierze dwie tabele, a następnie WARTOŚCI w numerze tygodnia ISO i po prostu dopasowujemy je razem. To da nam 53 tygodnie każdego roku.

Następnie dodajemy trzecią kolumnę do tabeli. Moglibyśmy to zrobić w dodatku Power Query, ale po prostu łatwiej jest pokazać logikę w języku DAX. W rzeczywistości bierzemy i łączymy Rok z łącznikiem, a następnie numer tygodnia, tak że mamy kluczowe pole do połączenia go z tabelą Daty.

Musimy jednak wykonać tutaj trochę więcej pracy, ponieważ sposób działania pola klucza w tabeli Daty to czterocyfrowy łącznik roku, a następnie dwucyfrowy tydzień. Tak więc w przypadkach, gdy numer tygodnia ISO jest dwucyfrowy, możemy po prostu wykonać prostą konkatenację. W przypadkach, gdy jest to jedna cyfra, musimy wziąć numer roku, a następnie połączyć go z łącznikiem, następnie wiodącym zerem, a następnie numerem tygodnia.

Kiedy już to mamy, możemy wziąć tę tabelę do modelu danych i znaleźć naszą kolumnę Tydzień i rok. Następnie łączymy się z nimi w relacji jeden-do-wielu. Zawsze lubię włączać tę opcję w polach związanych z Pinem na górze karty , abyśmy mogli to od razu zobaczyć, gdy to sprawdzimy.

Jeśli wrócimy do wizualizacji, musimy zmienić wiersze. Zamiast numeru Year & Week chcemy użyć numeru Year & Week z tabeli CROSSJOIN. A teraz mamy ten 53 tydzień w 2018 roku z pustym miejscem i 53 tydzień w 2019 roku z pustym miejscem. W 2020 roku mamy rzeczywistą liczbę, ponieważ ma 53 tydzień.

Moglibyśmy na tym poprzestać, gdyby nie fakt, że wyszliśmy już z modelu Star Schema. Za każdym razem, gdy odchodzisz od schematu gwiezdnego w usłudze LuckyTemplates, wychodzisz poza sferę tego, co jest ogólnie uważane za najlepszą praktykę.

Tak więc w przypadku schematu płatka śniegu nie jest to duże naruszenie. Są przypadki, w których zdecydowanie chcesz go użyć, ale jeśli możesz tego uniknąć, spróbuj. Zmniejsza powielanie, ale niekoniecznie rozmiar. Pozwala używać prostych miar zliczania, ale występują problemy z wydajnością i potencjalnymi problemami z użytecznością, a także zdecydowanie wzrasta złożoność języka DAX. Uniemożliwia budowanie hierarchii między tabelami, a prawdopodobnie najbardziej problematyczne jest to, że może naprawdę zepsuć twoją zdolność do synchronizowania fragmentatorów w różnych polach.

Tak więc, chociaż to rozwiązuje problem, robi to w sposób, który nie jest świetny. Zobaczmy, czy możemy zrobić to lepiej. Przejdźmy do innego modelu danych. W tym modelu wziąłem dokładnie te same dane, daty i cenę spot, ale tym razem usunąłem tabelę CROSSJOIN. Nadal istnieje, ale nie jest podłączony.

Ale jeśli spojrzymy na DAX, zobaczymy, że jest to dokładnie ten sam DAX, który utworzył tę tabelę w innym raporcie. Tak więc, zamiast łączyć to w fizyczny związek, a następnie naruszać schemat gwiazdy i przekształcać go w schemat płatka śniegu, możemy zachować schemat gwiazdy i po prostu użyć wirtualnej relacji.

W tym celu użyjemy funkcji o nazwie . Tworzy tę relację między tabelami, ale robi to wirtualnie. Robimy to za pomocą , ponieważ będziemy zmieniać kontekst. W tym przypadku kontekst będzie dotyczył relacji. Mamy więc całkowitą cenę spot, a następnie TREATAS. Mamy , aby zamienić tę kolumnę w tabelę.

Następnie mamy pole Year & Week, które jest kluczem, który stworzyliśmy. Mamy to połączone wirtualnie z Tygodniem i rokiem w tabeli Daty. Więc teraz mamy tę tabelę Crossjoint filtrującą tabelę Dates w taki sam sposób, jak to miało miejsce, gdy mieliśmy fizyczny związek, ale bez naruszania schematu gwiazdy.

Możemy teraz wziąć i upuścić tę całkowitą cenę spotową TREATAS do macierzy, a to, co widzimy, to dokładnie te same sumy. W ten sposób zrobiliśmy to bez zakłócania naszego modelu danych i ponoszenia jakichkolwiek wad, o których mówiliśmy w odniesieniu do schematu płatka śniegu.

Uzyskaj wartości LuckyTemplates z poprzedniego tygodnia za pomocą DAX i Power Query
Obliczanie tygodniowej sprzedaży w/DAX w LuckyTemplates
Analiza czasowa w języku DAX: jak dynamicznie wybrać okres początkowy

Wniosek

W tym samouczku pokazałem kilka sposobów rozwiązania problemu z tygodniowymi obliczeniami języka DAX w usłudze LuckyTemplates. Jednym z nich jest użycie CROSSJOIN, ale ma to pewne wady. Drugim sposobem jest użycie TREATAS, stworzenie wirtualnej relacji i nie naruszanie podejścia Star Schema.

Jest to jedna technika, która jest całkiem przydatna w radzeniu sobie z problemem w 53. tygodniu. Mam nadzieję, że uznałeś to za przydatne. Chcę poznać twoje przemyślenia na ten temat. Daj mi znać w komentarzach pod spodem.

Wszystkiego najlepszego,