Einführung
Nach der anfänglichen Euphorie über die neue kalenderbasierte Zeitintelligenz begann ich, mich eingehender mit der neuen Funktion zu befassen, um zu sehen, was diese neuen Möglichkeiten in der realen Welt bedeuten.
Im Abschnitt „Referenzen“ am Ende dieses Artikels finden Sie mehrere Hyperlinks dazu, darunter einen SQLBI-Artikel, der Sie tief in das Thema einführt.
Ich empfehle dringend, diese Artikel zu lesen, um ein gutes Verständnis zu erlangen.
Aber mit der Zeit wurde mir klar, dass dieses glänzende neue Function auch Schattenseiten hat.
Nun zeige ich Ihnen vier Beispiele, bei denen ich interessante Effekte entdeckt habe.
Wenn möglich, werde ich für jedes Downside Problemumgehungen oder Lösungen anbieten.
Einrichtung der Kalender
Für diesen Artikel habe ich zwei Energy BI-Berichte mit jeweils zwei Datumstabellen verwendet, um Interferenzen zu vermeiden. Alle Datumstabellen haben dieselbe Quelltabelle.
Eine mögliche Interferenz zwischen Kalendern wird beschrieben Hier.
Für den gregorianischen Kalender habe ich diese Konfiguration verwendet:
Für den wochenbasierten Kalender habe ich diese Konfiguration verwendet:
Der Wochenkalender enthält die Spalte „YearOfWeek“ für die Kategorie „Jahr“.
Diese Spalte enthält die wochenbündige Jahresangabe, die für einen solchen Kalender benötigt wird. Diese Spalte basiert auf der ISO-Wochendefinition. Jedes Jahr beginnt am Montag der ersten Woche.
Eine Erklärung zur ISO-Woche finden Sie hier Hier.
Beide Energy BI-Datenmodelle verwendeten dieselbe Konfiguration.
Vorherige Monate und unterschiedliche Monatslängen
Okay, schauen wir uns zunächst Monate mit unterschiedlicher Länge an.
Ich beschreibe diesen Fall, um Ihnen die Unterschiede zur klassischen Zeit-Intelligenz-Logik bewusst zu machen.
Ich habe zwei Maßnahmen erstellt:
On-line Gross sales (PM) =
CALCULATE((On-line Gross sales)
,DATEADD('Date'(Date), -1, MONTH)
)Und dieser verwendet den gregorianischen Kalender:
On-line Gross sales (PY Gregorian) =
CALCULATE((On-line Gross sales)
,DATEADD('Gregorian Calendar', -1, YEAR)
)Ich habe beides zu einem Tabellenvisual hinzugefügt.
Schauen Sie sich nun die Unterschiede zwischen diesen beiden Maßnahmen für März an:
Obwohl dieses Ergebnis sehr interessant ist, schauen Sie sich dieses an:
In beiden Fällen ist das Ergebnis sehr unterschiedlich.
Während die Messung mit klassischer Zeitintelligenz den gleichen Wert für die letzten drei Tage im März zeigt, lassen die Ergebnisse für Februar die letzten Tage im Januar weg.
Die kalenderbasierte Messung schneidet viel besser ab.
Der entscheidende Punkt hierbei ist, dass die Zeilensummen der Summe entsprechen, die in der Zeile „Gesamt“ angezeigt wird.
Darüber hinaus ist die DATEADD() Die Funktion verfügt jetzt über zwei zusätzliche Parameter, die sich auf die Ergebnisse für Monate mit ungleicher Länge auswirken.
Obwohl es nicht seltsam ist, handelt es sich definitiv um ein anderes Verhalten der Funktion, dessen Sie sich bewusst sein müssen. Dies gilt überall dort, wo Perioden nicht gleich lang sind. Ich werde später darauf zurückkommen.
Was passiert mit dem Vorjahr?
Jetzt kommt die erste seltsame State of affairs.
Beachten Sie die folgende Tabelle unter Verwendung einer Kennzahl mit einem DATEADD()-Aufruf unter Verwendung des Gregorianischen Kalenders für PY:
Wie Sie sehen, sieht alles intestine aus.
Schauen Sie sich nun die Ergebnisse an, wenn Sie 2024 mit 2025 vergleichen:
Wie Sie sehen können, sind die Vorjahreswerte für März 2025 um 1 Tag verschoben.
Das ist nicht korrekt.
Schlimmer noch: Wenn man die Gesamtwerte der Monate vergleicht, sind sie zwischen 2024 und dem Vorjahresmaß im Jahr 2025 gleich.
Dieser Effekt ist bis Dezember zu beobachten, wobei die Ergebnisse wie folgt lauten:
Dies ist derselbe Effekt, den wir bei der zuvor gezeigten Kennzahl „Vormonat“ beobachten können, da diese beiden Jahre nicht gleich lang sind.
Dieser seltsame Effekt ist darauf zurückzuführen, wie DAX Ergebnisse basierend auf der Kalenderhierarchie berechnet.
Der Mechanismus heißt „Distance from Guardian“.
Aber das Guardian wird durch den dritten Parameter von DATEADD() definiert: Yr
Daher berechnet DATEADD() den Abstand vom Jahresanfang und gibt das Ergebnis unter Verwendung des gleichen Abstands für das vorherige Jahr zurück.
Eine Lösung für dieses Downside besteht darin, sicherzustellen, dass alle Monate gleich lang sind.
In meinem ersten Artikel über diese neue Funktion, der im Abschnitt „Referenzen“ weiter unten verlinkt ist, habe ich eine benutzerdefinierte Datumstabelle und einen Kalender mit 31 Tagen für alle Monate erstellt.
Wenn Sie denselben Vorgang mit diesem Kalender ausführen, verschwindet der Effekt:
Dieser Ansatz funktioniert zwar einwandfrei, erfordert jedoch einen benutzerdefinierten Kalender, der andere Probleme verursachen oder bestimmte Anforderungen nicht erfüllen kann. Vor allem, weil die Datumsspalten keine echten Daten enthalten und die Spalte „date_real“ Lücken aufweist. Dies kann bei der Verwendung in benutzerdefinierten Berechnungen zu Problemen führen.
Eine andere Lösung besteht darin, das Geschäftsjahr um 12 Monate zurück zu berechnen:
On-line Gross sales (-12 M Gregorian) =
CALCULATE((On-line Gross sales)
,DATEADD('Gregorian Calendar', -12, MONTH)
)Und das sind die Ergebnisse der neuen Maßnahme:
In Rot sehen Sie die gleichen Ergebnisse wie zuvor, um einen Tag verschoben.
In Grün sehen Sie die Ergebnisse für die Kennzahl mit Monatsgranularität.
Interessanterweise stimmen auch die Summen für die Quartale und die Jahre.
Im Second sehe ich kein Downside darin, diesen Ansatz zu verwenden, und ich werde ihn in Zukunft verwenden und testen.
Wöchentliche Berechnungen – Kopfkratzen
Das ist eine sehr seltsame Sache.
Schauen Sie sich das folgende Bild mit derselben Tabelle in verschiedenen Zuständen nebeneinander an:
Auf der linken Seite sehen Sie, dass alle Zeilen für 2023 identisch sind, wenn 2022 ausgeblendet ist.
Rechts sehen Sie die korrekten Werte für 2023, sie werden jedoch nur angezeigt, wenn ich mindestens eine Woche von 2022 bis zum Datum erweitere.
Aber die Werte im Jahr 2022 sind wieder alle gleich.
Ich habe dies bereits erlebt und in meinem ersten Artikel über die Kalenderfunktion gezeigt (Hyperlink unten).
In diesem Fall habe ich das Downside gelöst, indem ich eine separate Tabelle für den Wochenkalender erstellt habe. Doch dieses Mal klappte es nicht.
Ich musste das Datenmodell von Grund auf neu erstellen und es funktionierte sofort:
Wie Sie sehen, sind die Ergebnisse korrekt.
Wenn Sie genau hinschauen, sind die PJ-Ergebnisse korrekt, um den PJ-Wert derselben Woche und desselben Wochentags des Vorjahres zu erhalten.
Ich habe keine Ahnung, was der Unterschied zwischen diesen beiden Setups ist.
Die Datumstabelle stammt in beiden Datenmodellen aus derselben Quelle und der Kalender wird mithilfe derselben Spalten definiert.
Aber ich mache mir darüber ein wenig Sorgen, weil ich den Grund nicht verstehe und keine Lösung habe. Selbst nachdem ich die TMDL-Datei für diese Tabelle überprüft hatte, konnte ich nichts finden, was auf die Ursache hindeutete.
Einen solchen Effekt habe ich nur bei wöchentlichen Berechnungen festgestellt.
Mischen wöchentlicher mit monatlicher Logik
Einer meiner Kunden möchte einen Bericht sehen, der die Tagesergebnisse für den aktuellen Monat im Vergleich zur gleichen Woche und zum gleichen Wochentag des Vorjahres zeigt.
Dies ist eine Mischung aus dem monatlichen (gregorianischen) Kalender und der wöchentlichen Logik.
Wie ich im nächsten Fall genauer zeigen werde, ordnet die Wochenlogik die Wochen und Wochentage korrekt dem Vorjahr zu. Daher sollte dies ein Downside sein.
Da die Wochen jedoch nicht mit den Monaten übereinstimmen, kann ich die Kategorie „Monat“ nicht hinzufügen. Ich erhalte bei der Validierung eine Fehlermeldung, wenn ich versuche, die Kategorie „Monat“ hinzuzufügen.
Daher kann ich keine MTD-Berechnung verwenden, da die Funktion die benötigte Kategorie nicht findet:
Ich kann der gleichen Datumstabelle keinen gregorianischen Kalender hinzufügen, da die Engine für alle Kalender in derselben Tabelle dieselbe Spalte für dieselbe Kategorie erwartet.
Siehe hier für die Stellungnahme von Microsoft hierzu.
Da ich die Spalte „YearForWeek“ für die Kategorie „Jahr“ verwende, funktioniert es nicht mit der Kategorie „Monat“, da sie nicht übereinstimmen.
Infolgedessen musste ich eine benutzerdefinierte Logik schreiben, um alle Anforderungen zu erfüllen.
Wöchentliche Berechnungen – Das ist interessant!
Um es positiv zu sagen: Ich kann Ihnen etwas zeigen, das sehr intestine funktioniert.
Erinnern Sie sich an das Downside mit den unterschiedlich langen Monaten und daran, wie sich die PJ-Werte verschoben haben?
Dieser Effekt tritt bei wöchentlichen Berechnungen nicht auf.
Wie Sie sehen, werden die Ergebnisse anhand der Woche und der richtigen Wochentage korrekt berechnet.
Wie erwartet werden die Werte nicht auf die Daten des Vorjahres abgebildet, sondern auf die Wochentage professional Woche.
Das ist es, was ich erwarte, wenn ich die Ergebnisse nach Woche und Wochentagen betrachte.
Der Grund dafür ist, dass jede Woche gleich lang ist und die Datumstabelle so aufgebaut ist, dass sie ein solches Szenario unterstützt.
Abschluss
Wie Sie sehen, sind die Ergebnisse gemischt.
Betrachtet man die Ergebnisse früherer Zeiträume unterschiedlicher Länge (Monate oder Jahre), verschieben sich die Ergebnisse.
Wenn die Zeiträume gleich lang sind (Wochen oder benutzerdefinierter Kalender), funktioniert alles wie erwartet.
Ich warfare äußerst überrascht und verärgert, als ich die Ergebnisse für die Schaltjahre sah.
Aber glücklicherweise lässt sich dieses Downside lösen, indem man versteht, wie die neue Logik funktioniert.
Das andere Downside, bei dem ich ein schlechtes Gefühl habe, ist die inkonsistente Funktionsweise des Wochenkalenders und der PJ-Berechnung.
Das ist beunruhigend, da es nicht immer so einfach ist, ein Datenmodell neu aufzubauen.
Ein weiteres Downside, das ich habe, ist, dass SQLBI in seinem Artikel potenzielle Probleme bei der Verwendung mehrerer Kalender in derselben Datumstabelle meldet. Ich habe unten einen Hyperlink dazu hinzugefügt.
Dies führt dazu, dass mehrere Datumstabellen im selben Datenmodell erforderlich sind.
Etwas, das ich nur ungern tue.
Ich kann mir vorstellen, dass sich dies auf mehrere visuelle Elemente in einem Bericht auswirkt, bei denen die Logik verschiedener Kalender, aber mit unterschiedlichen Kategorien verwendet wird.
Die Lösung dieses Issues kann schwierig sein.
Aber wir werden sehen, wie sich diese Funktion weiterentwickeln wird, da wir uns noch in der Vorschau befinden.
Referenzen
Der SQLBI-Artikel erläutert die kalenderbasierte Zeitintelligenzfunktion im Element:
https://www.sqlbi.com/articles/introducing-calendar-based-time-intelligence-in-dax
Der SQLBI-Artikel erklärt DATEADD() mit den neuen Parametern:
Microsoft-Dokumentation zur neuen Funktion (URL kann sich im Laufe der Zeit ändern):
Mein Artikel mit drei realen Anwendungsfällen mit den neuen Kalendern:
Mein zweiter Artikel über kalenderbasierte Zeitintelligenz und gleitenden Durchschnitt:
Ein Blogbeitrag von Chris Webb über die Auswirkungen der kalenderbasierten Zeitintelligenz:
Definition der ISO-Woche basierend auf dem ISO8601-Commonplace
https://www.calendarz.com/weblog/iso-week-numbers-explained-week-1-week-53-and-year-boundaries
Wie in meinen vorherigen Artikeln verwende ich den Contoso-Beispieldatensatz. Sie können den ContosoRetailDW-Datensatz kostenlos von Microsoft herunterladen Hier.
Die Contoso-Daten können wie beschrieben unter der MIT-Lizenz frei verwendet werden in diesem Dokument. Ich habe den Datensatz aktualisiert, um die Daten auf aktuelle Daten zu übertragen, und alle für dieses Beispiel nicht benötigten Tabellen entfernt.