Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

Eine Kalendertabelle, das kannst Du in meinem vorangegangenen Beitrag lesen, muss gewisse technische Voraussetzungen erfüllen, damit zeitbezogene Kalkulationen in DAX fehlerfrei funktionieren. Darüber hinaus ist man in der Gestaltung dieser Dimensionstabelle jedoch völlig frei. Das ist auch notwendig, denn Kalendertabellen müssen in unterschiedlichen Unternehmen teils sehr verschiedene Logiken abbilden.

Beispiele für Unterschiede zwischen Kalendertabellen

Unternehmen „ticken“ verschieden und orientieren sich unterschiedlich am Kalender. So haben sie relativ häufig ein Geschäftsjahr, das nicht am 1. Januar beginnt, sondern vom Kalenderjahr abweicht. Bei allen Texten innerhalb einer Kalendertabelle, wie z. B. Monatsnamen (Januar, January, janvier) und Tagesnamen (Montag, Monday, lundi) spielt die Sprache eine Rolle. Hier muss je nach Unternehmenssprache ein Konsenz gefunden werden. Darüber hinaus haben verschiedene Ländern ebenso verschiedene Kalender. Betrachtet man z. B. den Chinesischen Kalender, so variiert hier sogar jährlich der Jahresanfang, der im Gregorianischen Kalender ja stets der 1. Januar ist.

Die meisten Unterschiede zwischen Kalendern gibt es meiner Meinung nach im Bereich der Definition der Kalenderwochen. Hier gibt es die verschiedensten Kreationen:

Definition der 1. Woche des Jahres

• In den USA beginnt die 1. Kalenderwoche immer mit dem 1. Januar.
• Im deutschsprachigen Raum hat sich die ISO-Kalenderwoche durchgesetzt. Hier ist die Woche 1 diejenige Woche im Jahr, die den ersten Donnerstag des Jahres enthält.

Unterschiedliche Systematiken für die Zuordnung der Kalenderwochen zu einem Kalendermonat

Es gibt viele verschiedene Systematiken für das Bilden von Monaten. Hier ein paar Beispiele:

• 4-5-4 Methode, bei der das Gemeinjahr (Nicht-Schaltjahr) aus 4 gleichlangen Quartalen besteht. Jedes Quartal besteht aus drei Monaten, von denen der erste 28 Tage („4“ Wochen), der zweite 35 Tage („5“ Wochen) und der dritte wieder 28 Tage („4“ Wochen) umfasst.
• 5-4-4 Methode, bei der das Gemeinjahr (Nicht-Schaltjahr) aus 4 gleichlangen Quartalen besteht. Jedes Quartal besteht aus drei Monaten, von denen der erste 35 Tage („5“ Wochen), der zweite 28 Tage („4“ Wochen) und der dritte wieder 28 Tage („4“ Wochen) umfasst.
• 13-Monate-Kalender-Methode, bei der von Monaten ausgegangen wird, die exakt 4 Wochen (28 Tage) beinhalten.

Nachdem ich nun ein wenig Theorie zu Kalendern, Jahresanfängen und Wochenzuordnungen beschrieben habe, sollte klar sein, warum eine Kalendertabelle viele verschiedene Formen haben kann und muss. Der weitere Beitrag zeigt, wie einige der geläufigsten Bestandteile einer Kalendertabelle mit Power Query gebildet werden können. Ich werde ihn bei Bedarf immer mal wieder anpassen und ergänzen.

Anlegen einer Kalendertabelle in Power BI

In Power BI gibt es diverse Möglichkeiten, eine Kalendertabelle zu erstellen. Falls Du schnell eine einfache Kalendertabelle in Power Pivot für Excel erstellen willst, zeigt Dir Uwe in diesem Video, wie das geht. Marco Russo hat ein sehr umfangreiches Skript in DAX geschrieben und erstellt damit eine kalkulierte Tabelle im Datenmodell. Da Power Pivot gegenwärtig keine kalkulierten Tabellen erstellen kann, funktioniert diese Lösung nicht in Power Pivot für Excel. Es spricht prinzipiell auch nichts dagegen, sich eine entsprechende Tabelle in Excel zu erstellen und diese in Power BI zu importieren. Falls eine entsprechende Tabelle bereits in einem Dir zur Verfügung stehendem Date Warehouse „herumliegt“, dann importiere sie Dir einfach von dort. Es gibt viele Wege.

Ich bin ein Freund von Power Query und schreibe mir daher alle Funktionalitäten für eine Kalendertabelle gerne in M. Darüber hinaus ist die Nutzung von Power Query der übliche Weg, Tabellen in mein Datenmodell zu bekommen und ich bleibe hier gerne konsistent. Im weiteren Teil dieses Beitrags beschreibe ich nützliche Bestandteile einer Kalendertabelle, zeige, wie Du sie mit nativen oder auch benutzerdefinierten M-Funktionen erstellst und erläutere zudem den Zweck, den diese Spalten im Datenmodell erfüllen. Alle Berechnungen innerhalb dieser Kalendertabelle  nehmen Bezug auf die Spalte Kalendertabelle[Datum]. Du solltest in Deiner Tabelle also eine Spalte Datum haben, damit alle weiteren Formeln und Funktionen auch bei Dir funktionieren.

Es gibt datumsbezogene Funktionen in Power Query, die Texte zurückgeben. Hierbei handelt es sich beispielsweise um Monats- und Tagesnamen. Ein Beispiel für eine solche Funktion ist

Date.DayOfWeekName([Datum], culture),  die zu einem Datum den Namen des Wochentages zurückgibt. Diese Funktionen haben einen optionalen Parameter Culture. Darüber kann programmatisch gesteuert werden, in welcher Sprache dieser Text ausgegeben wird. Lässt man diesen optionalen Parameter leer, so orientiert sich die Funktion an der Spracheinstellung Deines Betriebssystems. Eine Liste der durch Microsoft unterstützten Cultures findest Du hier. Der Parameter muss als Text übergeben werden, also z. B. so: „de-de“ (mit Anführungsstrichen).

Alle folgende Bestandteile dieses Beitrags können als Baukasten betrachtet werden. Suche Dir eine benötigte Formel für Deine zu erstellende Kalendertabelle heraus und nutzen sie. Falls Dir eine Formel fehlt, schreibe mir gerne eine Nachricht, oder einen Kommentar. Ich werde versuchen, dies dann in diesen Beitrag mit aufzunehmen.

Kalenderjahresbezug

Die Basis einer jeden Kalendertabelle ist eine Datumsspalte. Diese in Power Query via M-Code zu erzeugen, ist nicht sonderlich intuitiv. Aus diesem Grund habe ich eine eigene Funktion geschrieben, die Dir das Anlegen einer solchen Spalte stark vereinfacht. Erzeuge einfach eine leere Abfrage in Power Query und kopiere Dir diese Funktion in den Erweiterten Editor. Als Ergebnis erhältst Du eine Funktion, deren Parameter Du über die GUI wie folgt füllen kannst:

Die Schritte 1 und 2 passe dabei bitte nach Deinem Belang an. Bedenke jedoch, dass Du in Deiner Kalendertabelle immer vollständige Kalender- bzw. Geschäftsjahre abbilden solltest (Warum das so ist , liest du hier). Benenne die entstandene Spalte um in Datum. Mit der bestehenden Datumsspalte, können alle hier weiter aufgeführten Berechnungen vorgenommen werden.

Tagesbasierte Kalkulationen

Volle Datumsbezeichnung

Funktion: Date.ToText([Datum], "dd. MMMM yyyy", culture)

Beispielwert: 01. Januar 2015

Zweck/ Nutzen: Vergleich und Filterung auf Ebene des spezifischen Tages.

Nutzung der Funktion: Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Culture: Culture ist ein optionaler Parameter und muss als Text – also in Anführungszeichen –  übergeben werden. Ein Beispiel für einen englischen Text wäre „en-US“. Eine Übersicht unterstützter Cultures findest Du hier.

Name des Tages

Funktion: Date.DayOfWeekName([Datum], culture)

Beispielwert: Sonntag

Zweck/ Nutzen: Vergleich und Filterung von Wochentagen.

Nutzung der Funktion: Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Culture: Culture ist ein optionaler Parameter und muss als Text – also in Anführungszeichen –  übergeben werden. Ein Beispiel für einen englischen Text wäre „en-US“. Eine Übersicht unterstützter Cultures findest Du hier.

Ermittlung, ob Arbeitstag oder Wochenende

Funktion: if (Date.DayOfWeek([Datum], Day.Monday) + 1) < 6 then "AT" else "WE"

Beispielwert: „AT“, „WE“

Zweck/ Nutzen: Vergleiche von Monaten, Quartalen etc. bzgl. enthaltener Arbeistage.

Nutzung der Funktion: Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Tag in der Kalenderwoche (nicht ISO-Kalenderwoche)

Funktion: Date.DayOfWeek([Datum], Day.Monday) + 1

Beispielwert: 1-7

Zweck/ Nutzen: Kann als Spalte zur Sortierung der Tagesbezeichnung genutzt werden

Nutzung der Funktion: Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Tag im Kalendermonat

Funktion: Date.Day([Datum])

Beispielwert: 1-31

Zweck/ Nutzen: Tagesbasierte Vergleiche in DAX Measures.

Nutzung der Funktion: Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Tag im Kalenderjahr

Funktion: Date.DayOfYear([Datum])

Beispielwert: 1-366

Zweck/ Nutzen: Tagesbasierte Vergleiche in DAX Measures.

Nutzung der Funktion: Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Fortlaufende Tagesnummer

Hierfür sieh bitte unter Kalkulation fortlaufender Nummern nach.

Wochenbasierte Kalkulationen

Kalenderwoche im Jahr (nicht ISO-Kalenderwoche)

Funktion: Date.WeekOfYear([Datum])

Beispielwert: 1-54

Zweck/ Nutzen: Wochenbasierte Vergleiche in DAX Measures.

Nutzung der Funktion:Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

ISO-Kalenderwochennummer

Funktion:

Beispielwert: 1-53

Zweck/ Nutzen: Diese Funktion ordnet einen Kalendertag einer nach ISO-Norm 8601 definierten Kalenderwoche zu.

Nutzung der Funktion: Kopiere diese Funktion in eine leere Abfrage und speichere diese unter einem Namen, z. B. „fnIsoWeek“. Gehe dann in Deine Abfrage, in der Du die ISO-Kalenderwoche hinzufügen möchtest. Erzeuge eine benutzerdefinierte Spalte und gibt dann ein „= fnIsoWeek([Datum])“. Dies erzeugt eine Spalte mit der Iso-Kalenderwoche.

ISO-Kalenderwochenbezeichnung

Funktion:

Beispielwert: „ISO KW 15“

Zweck/ Nutzen:Diese Funktion ordnet einen Kalendertag einer nach ISO-Norm 8601 definierten Kalenderwoche zu und erzeugt einen Text nach der Form „ISO KW 15“.

Nutzung der Funktion: Kopiere diese Funktion in eine leere Abfrage und speichere diese unter einem Namen, z. B. „fnIsoWeekName“. Gehe dann in Deine Abfrage, in der Du die ISO-Kalenderwochenbezeichnung hinzufügen möchtest. Erzeuge eine benutzerdefinierte Spalte und gibt dann ein „= fnIsoWeekName([Datum])“. Dies erzeugt eine Spalte mit der Iso-Kalenderwochenbezeichnung.

Monatsbasierte Kalkulationen

Monatsnummer im Kalenderjahr

Funktion: Date.Month([Datum])

Beispielwert: 1-12

Zweck/ Nutzen: Kann als Spalte zur Sortierung der Monatsbezeichnung genutzt werden

Nutzung der Funktion: Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Name des Monats

Funktion: Date.MonthName([Datum], culture)

Beispielwert: Februar

Zweck/ Nutzen: Vergleich und Filterung von Monaten.

Nutzung der Funktion: Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Culture: Culture ist ein optionaler Parameter und muss als Text – also in Anführungszeichen –  übergeben werden. Ein Beispiel für einen englischen Text wäre „en-US“. Eine Übersicht unterstützter Cultures findest Du hier.

Fortlaufende Monatsnummer

Hierfür sieh bitte unter Kalkulation fortlaufender Nummern nach.

Quartalsbasierte Kalkulationen

Quartal im Kalenderjahr

Funktion: Date.QuarterOfYear([Datum])

Beispielwert: 1-4

Zweck/ Nutzen: Kann als Spalte zur Sortierung des Quartalsnamens genutzt werden.

Nutzung der Funktion: Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Name des Quartals im Kalenderjahr

Funktion: "Q"&Number.ToText(Date.QuarterOfYear([Datum]))

Beispielwert: „Q1“ – „Q4“

Zweck/ Nutzen: Vergleich und Filterung von Quartalen.

Nutzung der Funktion: Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Fortlaufende Quartalsnummer

Hierfür sieh bitte unter Kalkulation fortlaufender Nummern nach.

Halbjahresbasierte Kalkulationen

Halbjahr im Kalenderjahr

Funktion: Number.RoundUp(Date.Month([Datum])/6,0)

Beispielwert: 1-2

Zweck/ Nutzen: Kann als Spalte zur Sortierung der Halbjahresbezeichnung genutzt werden

Nutzung der Funktion:Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Name des Halbjahres im Kalenderjahr

Funktion: "HJ"&Number.ToText(Number.RoundUp(Date.Month([Datum])/6,0))

Beispielwert: „HJ1“ – „HJ2“

Zweck/ Nutzen: Vergleich und Filterung von Halbjahren.

Nutzung der Funktion: Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Fortlaufende Halbjahresnummer

Hierfür sieh bitte unter Kalkulation fortlaufender Nummern nach.

Jahresbasierte Kalkulationen

Kalenderjahr 

Funktion: Date.Year([Datum])

Beispielwert: 2018

Zweck/ Nutzen: Vergleich und Filterung von Kalenderjahren.

Nutzung der Funktion: Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Kalkulation fortlaufender Nummern

Fortlaufende Nummern sind wichtig für den Fall, dass man benutzerdefinierte Time Intelligence-Funktionen in DAX schreiben will. Wer sich damit detaillierter auseinandersetzen möchte, dem kann ich folgenden englischsprachigen Beitrag ans Herz legen: Time Patterns.

fortlaufende Tagesnummer

Funktion: =Table.AddIndexColumn(#"Name des vorherigen Schrittes", "Index", 1, 1)

Beispielwert: 723

Zweck/ Nutzen: Beginnend beim ersten Tag wird der Zähler pro Tag um 1 erhöht. Dies kann für benutzerdefinierte Time Intelligence-Funktionen sehr hilfreich sein.

Nutzung der Funktion: Füge über die fx-Schaltfläche (links neben der Formelleiste) einen neuen Schritt hinzu und füge die Formel in die Funktionsleiste ein. Beachte,  „Namen des vorherigen Schrittes“ auf den Namen Deines letzten Schrittes in Power Query anzupassen.

fortlaufende Monatsnummer

Funktion:

Beispielwert: 25

Zweck/ Nutzen: Beginnend beim ersten Kalendermonat wird der Zähler pro Monat um 1 erhöht. Dies kann für benutzerdefinierte Time Intelligence-Funktionen sehr hilfreich sein.

Nutzung der Funktion: Kopiere diese Funktion in eine leere Abfrage und speichere diese unter einem Namen, z. B. „fnfortlaufendeMonatsnummer“. Gehe dann in Deine Abfrage, in der Du die fortlaufende Monatsnummer hinzufügen möchtest. Erzeuge eine benutzerdefinierte Spalte und gibt dann ein „= fnfortlaufendeMonatsnummer([Datum])„. Dies erzeugt eine Spalte mit der fortlaufenden Monatsnummer.

fortlaufende Quartalsnummer

Funktion:

Beispielwert: 5

Zweck/ Nutzen: Beginnend beim ersten Quartal wird der Zähler pro Quartal um 1 erhöht. Dies kann für benutzerdefinierte Time Intelligence-Funktionen sehr hilfreich sein.

Nutzung der Funktion: Kopiere diese Funktion in eine leere Abfrage und speichere diese unter einem Namen, z. B. „fnfortlaufendeQuartalsnummer“. Gehe dann in Deine Abfrage, in der Du die fortlaufende Quartalsnummer hinzufügen möchtest. Erzeuge eine benutzerdefinierte Spalte und gibt dann ein

„= fnfortlaufendeQuartalsnummer([Datum])„.

Dies erzeugt eine Spalte mit der fortlaufenden Quartalsnummer.

fortlaufende Halbjahresnummer

Funktion:

Beispielwert: 5

Zweck/ Nutzen: Beginnend beim ersten Halbjahr wird der Zähler pro Quartal um 1 erhöht. Dies kann für benutzerdefinierte Time Intelligence-Funktionen sehr hilfreich sein.

Nutzung der Funktion: Kopiere diese Funktion in eine leere Abfrage und speichere diese unter einem Namen, z. B. „fnfortlaufendeHalbjahresnummer“. Gehe dann in Deine Abfrage, in der Du die fortlaufende Halbjahresnummer hinzufügen möchtest. Erzeuge eine benutzerdefinierte Spalte und gibt dann ein

„= fnfortlaufendeHalbjahresnummer([Datum])„.

Dies erzeugt eine Spalte mit der fortlaufenden Halbjahresnummer.

Vom Kalenderjahr abweichende Geschäftsjahre

Geschäftsmonat

Funktion:

Beispielwert: GM05

Zweck/ Nutzen: Weicht das Geschäftsjahr vom Kalenderjahr ab, so ist der Januar nicht der erste Monat des Geschäftsjahres. Um die Geschäftsmonatsnummer zu ermitteln, kann diese Funktion genutzt werden.

Nutzung der Funktion: Kopiere diese Funktion in eine leere Abfrage und speichere diese unter einem Namen, z. B. „fnGeschaeftsmonat“. Gehe dann in Deine Abfrage, in der Du den Geschäftsmonat hinzufügen möchtest. Erzeuge eine benutzerdefinierte Spalte und gibt dann ein

„= fnGeschaeftsmonat([Datum], Monat des Geschäftsjahresanfangs)„.

Als Monat des Geschäftsjahresanfangs nutze „Januar“ bis „Dezember„. Dies erzeugt eine Spalte mit dem Geschäftsmonat.

Geschäftsmonat und Geschäftsjahr

Funktion:

Beispielwert: GM05_2017

Zweck/ Nutzen: Weicht das Geschäftsjahr vom Kalenderjahr ab, so ist der Januar nicht der erste Monat des Geschäftsjahres. Um die Geschäftsmonatsnummer in Kombination mit dem Geschäftsjahr zu ermitteln, kann diese Funktion genutzt werden.

Nutzung der Funktion: Kopiere diese Funktion in eine leere Abfrage und speichere diese unter einem Namen, z. B. „fnGeschaeftsMonatUndJahr“. Gehe dann in Deine Abfrage, in der Du den Geschäftsmonat mit Geschäftsjahr hinzufügen möchtest. Erzeuge eine benutzerdefinierte Spalte und gibt dann ein „= fnGeschaeftsMonatUndJahr([Datum],Monat des Geschäftsjahresanfangs)„.

Als Monat des Geschäftsjahresanfangs nutze „Januar“ bis „Dezember„. Dies erzeugt eine Spalte mit dem Geschäftsmonat in Kombination mit dem Geschäftsjahr.

Geschäftsquartal

Funktion:

Beispielwert: GQ1-GQ4

Zweck/ Nutzen: Zweck/ Nutzen: Weicht das Geschäftsjahr vom Kalenderjahr ab, so ist der Januar nicht der erste Monat des Geschäftsjahres. Um die Quartalsnummer zu ermitteln, kann diese Funktion genutzt werden.

Nutzung der Funktion: Kopiere diese Funktion in eine leere Abfrage und speichere diese unter einem Namen, z. B. „fnGeschaeftsQuartal“. Gehe dann in Deine Abfrage, in der Du das Geschäftsquartal hinzufügen möchtest. Erzeuge eine benutzerdefinierte Spalte und gibt dann ein

„= fnGeschaeftsQuartal([Datum],Monat des Geschäftsjahresanfangs)„.

Als Monat des Geschäftsjahresanfangs nutze „Januar“ bis „Dezember„. Dies erzeugt eine Spalte mit dem Geschäftsquartal.

Geschäftsquartal und Geschäftsjahr

Funktion:

Beispielwert: Q04_2017

Zweck/ Nutzen: Zweck/ Nutzen: Weicht das Geschäftsjahr vom Kalenderjahr ab, so ist der Januar nicht der erste Monat des Geschäftsjahres. Um die Quartalsnummer in Kombination mit dem Geschäftsjahr zu ermitteln, kann diese Funktion genutzt werden.

Nutzung der Funktion: Kopiere diese Funktion in eine leere Abfrage und speichere diese unter einem Namen, z. B. „fnGeschaeftsQuartal“. Gehe dann in Deine Abfrage, in der Du das Geschäftsquartal hinzufügen möchtest. Erzeuge eine benutzerdefinierte Spalte und gibt dann ein

„= fnGeschaeftsQuartal([Datum],Monat des Geschäftsjahresanfangs)„.

Als Monat des Geschäftsjahresanfangs nutze „Januar“ bis „Dezember„. Dies erzeugt eine Spalte mit dem Geschäftsquartal.

Geschäftshalbjahr

Funktion:

Beispielwert: GHJ1-GHJ2

Zweck/ Nutzen: Zweck/ Nutzen: Weicht das Geschäftsjahr vom Kalenderjahr ab, so ist der Januar nicht der erste Monat des Geschäftsjahres. Um die Halbjahressnummer innerhalb des Geschäftsjahres zu ermitteln, kann diese Funktion genutzt werden.

Nutzung der Funktion: Kopiere diese Funktion in eine leere Abfrage und speichere diese unter einem Namen, z. B. „fnGeschaeftsHalbjahr“. Gehe dann in Deine Abfrage, in der Du das Geschäftsquartal hinzufügen möchtest. Erzeuge eine benutzerdefinierte Spalte und gibt dann ein

„= fnGeschaeftsHalbjahr([Datum],Monat des Geschäftsjahresanfangs)„.

Als Monat des Geschäftsjahresanfangs nutze „Januar“ bis „Dezember„. Dies erzeugt eine Spalte mit dem Geschäftshalbjahres.

Geschäftshalbjahr und Geschäftsjahr

Funktion:

Beispielwert: GHJ2_2017

Zweck/ Nutzen: Zweck/ Nutzen: Weicht das Geschäftsjahr vom Kalenderjahr ab, so ist der Januar nicht der erste Monat des Geschäftsjahres. Um die Halbjahressnummer innerhalb des Geschäftsjahres in Kombination mit dem Geschäftsjahr zu ermitteln, kann diese Funktion genutzt werden.

Nutzung der Funktion: Kopiere diese Funktion in eine leere Abfrage und speichere diese unter einem Namen, z. B. „fnGeschaeftsHalbjahrUndJahr“. Gehe dann in Deine Abfrage, in der Du das Geschäftsquartal hinzufügen möchtest. Erzeuge eine benutzerdefinierte Spalte und gibt dann ein

„=fnGeschaeftsHalbjahrUndJahr([Datum],Monat des Geschäftsjahresanfangs)„.

Als Monat des Geschäftsjahresanfangs nutze „Januar“ bis „Dezember„. Dies erzeugt eine Spalte mit dem Geschäftshalbjahres in Kombination mit dem Geschäftsjahr.

Ermittlung von Schaltjahren

Funktion: Date.IsLeapYear([Datum])

Beispielwert: True/ False

Zweck/ Nutzen: Ermittlung, ob der betreffende Tag in einem Schaltjahr liegt.

Nutzung der Funktion: Füge eine neue benutzerdefinierte Spalte hinzu und kopiere die Funktion in das Fenster benutzerdefinierte Spaltenformel.

Diese Auflistung hat keineswegs den Anspruch vollständig zu sein. Das wäre mit Sicherheit eine Si­sy­phus-Aufgabe. Aber ich werde, wie bereits weiter oben beschrieben, bei Bedarf an diesem Dokument arbeiten und es ergänzen.

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Ich schreibe meine Beiträge für Dich, den Leser. Bitte schenke mir eine Minute Deiner Zeit und bewerte die folgenden Kategorien, um mir zu helfen meine Beiträge so gut wie möglich zu schreiben. Danke 🙂

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Inhaltliche Anforderungen an eine Kalendertabelle in Power BI und Power Pivot erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

ACHTUNG: Ich benutze in diesem Beitrag durchgehend den Begriff der Kalendertabelle. In der Literatur und auch in Power BI selbst, werden auch andere Begrifflichkeiten wie Datumstabelle, Datums-Dimension, etc. verwendet. Lass Dich durch die unterschiedlichen Begriffe nicht verwirren: Sie sind alle Synonyme für dieselbe Tabelle im Datenmodell!

Was ist eine Kalendertabelle

Die Kalendertabelle ist eine spezielle Dimensionstabelle innerhalb eines Power BI Datenmodells. Jede Zeile innerhalb dieser Tabelle repräsentiert einen einzelnen Tag und jede Spalte innerhalb dieser Tabelle bezieht sich auf diesen repräsentierten Tag der jeweiligen Zeile. Ein Beispiel für eine solche Kalendertabelle siehst Du im folgenden Screenshot:

Aus dieser Darstellung wird deutlich, dass jede Zeile einen einzelnen Tag repräsentiert, der als Datum in Spalte Datum vermerkt ist. Die Bezeichnung der Spalte ist hierbei irrelevant für die Funktionalität. Alle anderen Spalten beziehen sich auf die Spalte Datum und ordnen diesen entsprechenden Tag beispielsweise einem Monat, einem Kalenderjahr, oder auch einem Wochentag zu. Doch wozu benötige ich überhaupt eine Kalendertabelle in meinem Datenmodell?

Wozu benötigt ein Power BI Datenmodell eine Kalendertabelle?

In den meisten Fällen möchte ich zeitbezogene Analysen meiner Daten vornehmen. Dies erleichtern mir in DAX die sog. Time Intelligence-Funktionen. Zu diesen Funktionen gehört beispielsweise die Funktion TOTALYTD(), die ich in diesem Artikel behandelt habe.

Eine Kalendertabelle benötige ich im Wesentlichen aus zwei Gründen:

1. Alle Time Intelligence-Funktionen in DAX müssen auf Basis einer Kalendertabelle kalkuliert werden, um fehlerfrei funktioniere zu können. Zeitbezogene Kalkulationen auf Basis von Datumsspalten in Faktentabellen (die Tabelle, in der die Transaktionen/ Ereignisse stehen) sollten hier unbedingt vermieden werden!
2. Das gleichzeitige Filtern mehrerer Faktentabellen hinsichtlich einer zeitlichen Dimension ist nur dann einfach möglich (d. h. ohne das Schreiben komplexer DAX-Formeln), wenn diese Faktentabellen über Beziehungen mit einer entsprechenden Kalendertabelle verknüpft sind.

Doch welche Anforderungen muss eine Kalendertabelle nun erfüllen? Ich unterscheide die Anforderungen an eine Kalendertabelle in zwei Kategorien: in technische und inhaltliche Anforderungen. Diesen Beitrag widme ich den technischen Anforderungen.

Technische Anforderungen an eine Kalendertabelle in Power BI

Die technischen Anforderungen an eine Kalendertabelle lassen sich im Wesentlichen von den Anforderungen der Time Intelligence-Funktionen in DAX ableiten. Damit diese DAX-Funktionen korrekte Ergebnisse liefern können, muss die Kalendertabelle gewisse Anforderungen erfüllen. Auf diese gehe ich jetzt ein.

Die datetime-Spalte

Alle Time Intelligence-Funktionen in DAX enthalten einen <dates>-Parameter. Hier einmal beispielhaft die TOTALYTD()-Funktion:

= TOTALYTD(<expression>,<dates>[,<filter>][,<year_end_date>])

Über diesen <dates>-Parameter wird die Datumsspalte aus der Kalendertabelle an die Funktion übergeben. Diese übergebene Spalte muss vom Typ datetime sein. Nur so kalkulieren Time Intelligence-Funktionen richtig. Der Typ datetime suggeriert, dass es sich hierbei um eine Spalte handeln kann, die nicht nur Datumsangaben, sondern auch Uhrzeitangaben beinhalten darf. Dass dies nicht so ist, verdeutlicht der nächste Abschnitt.

Ein Datensatz pro Tag

Sofern ich Kalender- und Faktentabelle über die Datumsspalte miteinander verknüpfen möchte, ist es für die Erstellung der Beziehung unerheblich, ob in der Datumsspalte nur eindeutige Datumswerte stehen, oder ob es sich um eindeutige Datums- und Uhrzeitangaben handelt, bei denen pro Tag auch mehrere Datensätze existieren. Hauptsache die Einträge sind eindeutig. Ob mit, oder ohne Uhrzeit spielt für die Datenmodellierung keine Rolle. Eine Beziehung kann problemlos auf Basis einer solchen Spalte erstellt werden.

Auch das Erstellen eines DAX-Measures mit einer Time Intelligence-Funktion ist kein Problem. Das folgende Measure kann problemlos geschrieben und gespeichert werden:

= TOTALYTD ( SUM ( Tabelle[Spalte] ); Kalendertabelle[Datum] )

Problematisch wird es jedoch, wenn ich dieses Measure für Analysen in Pivottabellen oder Visualisierungen nutzen möchte. Die entsprechenden Fehlermeldungen aus Excel und Power BI Desktop sehen wie folgt aus:

Ein einzelner Tag darf in der Kalendertabelle also nur ein einziges Mal enthalten sein, da die Time Intelligence-Funktionen sonst ihre Arbeit verweigern 😉 Sollte es für Dein Datenmodell notwendig sein, auch die Uhrzeiten zu berücksichtigen, so solltest Du Dir speziell für die Uhrzeiten eine separate Dimensionstabelle erzeugen. Dies ist jedoch nicht Gegenstand dieses Beitrags.

Datensätze müssen lückenlos aufgeführt sein

Bis hier steht also fest, dass die Kalendertabelle eine Datumsspalte haben muss, in der pro Tag genau ein Datensatz enthalten ist. Eine weitere Notwendigkeit für korrekt rechnende Time Intelligence-Funktionen ist, dass es zwischen den einzelnen Tagen in der Kalendertabelle keine Lücken geben darf.

Tage, die inmitten der Kalendertabelle fehlen, können nicht als Ergebnis einer Time Intelligence-Funktion zurückgegeben werden. Dies ist unabhängig davon, ob für die entsprechenden Tage Werte in den Faktentabellen vorliegen. Ein Beispiel macht dies plastischer. Für mein Beispiel liegen folgende Tabellen vor:

Die Kalendertabelle ist lückenlos. Die Faktentabelle weist der Einfachheit halber für jeden Tag im Januar 2018 den Wert 1 aus. Das Datenmodell ist das folgende:

Basierend auf diesem Datenmodell erstelle ich folgendes Measure, das den Year-to-date-Wert der Spalte Faktentabelle[Wert] kalkuliert:

= TOTALYTD ( SUM ( Faktentabelle[Wert] ); Kalender[Datum] )

Die folgende Pivottabelle verwendet die Spalte Datum der Kalendertabelle als Zeilenbeschriftung und zeigt das korrekt kalkulierte Ergebnis je Tag:

Wie wirkt es sich auf das Ergebnis in der Pivottabelle aus, wenn ich (vollkommen willkürlich) den 14.01.2018 aus der Kalendertabelle entferne?! ACHTUNG: Auch hier wird die Spalte Datum der Kalendertabelle als Zeilenbeschriftung der Pivot genutzt!

Dass der 14.01.2018 in der Pivottabelle fehlen würde, entsprach meiner Erwartung. Dennoch wäre es nicht abwegig gewesen, dass der YTD-Wert am 15.01.2018 trotzdem den Wert 15 ausweist. Schließlich fehlt der 14.01.2018 ja nur in der Kalendertabelle. In der Faktentabelle ist diesem Tag jedoch ein Wert (1€) zugeordnet. Dennoch fällt dieser Wert komplett aus der Kalkulation heraus, so dass zum 31.01.2018 nur 30€ zusammenkommen und nicht, wie es korrekt wäre, 31€. Time Intelligence-Funktionen scannen vor der Kalkulation die in der Kalendertabelle vorhandenen Tage und berechnen auch nur für diese die gewünschten Werte. Fehlt ein Tag in der Kalendertabelle, dann wird der entsprechende Wert aus der Faktentabelle in der Kalkulation nicht berücksichtigt!

Beziehung zwischen Kalender- und Faktentabelle

Ich hatte bereits unter Ein Datensatz pro Tag das Erstellen von Beziehungen mit der Kalendertabelle thematisiert. Damit die Faktentabelle durch die Kalendertabelle gefiltert werden kann, muss zuvor eine Beziehung zwischen diesen Tabelle hergestellt werden. Diese Beziehung kann auf Basis der Datumsspalte erzeugt werden, muss es aber nicht. Notwendig für eine funktionierende Verknüpfung ist, dass die Werte in der entsprechenden Schlüsselspalte in der Kalendertabelle eindeutig sind. Ob der Datentyp der Schlüsselspalte datetime, integer, oder text ist, spielt keine Rolle. Denkbar wäre beispielsweise folgender Aufbau des Schlüsselkriteriums: 20180215 für den 15.02.2018. Es ist an dieser Stelle wichtig zu erwähnen, dass diese Spalte lediglich als Schlüsselspalte zum Verknüpfen der Tabellen fungieren darf, nicht jedoch als Parameter in den Time Intelligence-Funktionen. In Time Intelligence-Funktionen muss eine Spalte vom Typ datetime genutzt werden, damit die Kalkulationen korrekt funktionieren.

Kalender- bzw. Geschäftsjahre müssen vollständig in der Kalendertabelle enthalten sein

An dieser Stelle herrscht nun Klarheit darüber, warum die Kalendertabelle keine Lücken in den Tagen haben darf und es ist auch klar, welche Optionen für Beziehungen zwischen den Tabellen bestehen. Aber müssen Geschäftsjahr bzw. Kalenderjahre auch komplett sein? Ich habe schon einige Entwickler von Datenmodellen erlebt, die die Kalendertabelle nur bis zum letzten vorhandenen Tag in der Faktentabelle fortgeschrieben hatten. Schließlich betrachtet man sowieso meist die Vergangenheit und nicht die Zukunft. Je kleiner die Kalendertabelle, desto weniger wird das Datenmodell damit belastet. Das war zumindest die gutgemeinte Idee dahinter. Lass mich dir zeigen, was passieren kann, wenn Du eine unvollständige Kalendertabelle in Time Intelligence-Funktionen nutzt. Ich habe das vorherige Beispiel etwas angepasst:

In der Faktentabelle sind die Werte vom 01.01.2016 bis zum 15.02.2018 enthalten. Da liegt es doch nahe, die Kalendertabelle auch nur bis zum 15.02.2018 zu erstellen und dabei darauf zu achten, dass sie lückenlos ist. Das sollte man jedoch besser vermeiden. Ich nutze die folgenden zwei Measures, um die Problematik aufzuzeigen:

YTD = TOTALYTD ( SUM ( Faktentabelle[Wert] ); Kalender[Datum] )

und

YTD_PY = CALCULATE ( [YTD]; DATEADD ( Kalender[Datum]; -1; YEAR ) )

Das Measure YTD kalkuliert den kumulierten Jahreswert der aktuellen Periode, während YTD_PY den kumulierten Jahreswert derselben Periode des Vorjahres kalkuliert. Ich ziehe beide Measures in die bereits bekannte Pivottabelle. Hierbei fokussiere ich aus didaktischen Gründen auf den Monat Februar der drei Jahre:

Beim ersten Jahr (1) handelt es sich um ein Schaltjahr. Der Februar hat also 29 Tage, wodurch sich der kumulierte Jahreswert (Jan+Feb 2016) mit 60 € ergibt. Im darauffolgenden Jahr 2017 (2) hat der Februar 28 Tage. Damit ergibt sich der kumulierte Jahreswert zum 28.02.2017 mit 59 €. Was an dieser Stelle interessant ist, ist die Tatsache, dass der YTD_PY-Wert am 28.02.2017 59€ beträgt, auf Monatsebene (oben im Zwischenergebnis) jedoch 60€ ausweist. Gleich vorweg: Beide Werte sind richtig. In 2016 gab es den 29.02., in 2017 jedoch nicht. Deswegen kann dieser auf Tagesebene im Jahr 2017 auch nicht ausgewiesen werden. Auf Monatsebene gibt die Funktion DATEADD ( Kalender[Datum]; -1; YEAR ) jedoch den gesamten Monat des Vorjahres zurück, so dass immer ganze Monate miteinander verglichen werden, unabhängig davon, wie viele Tage sie haben. Daher ist der YTD_PY-Wert am 28.02.2017 verschieden vom YTD_PY-Wert des gesamten Kalendermonats. Dieses Verhalten muss man kennen, um das Ergebnis richtig zu interpretieren.

Nun aber zu dem Punkt, an dem eine vollständige Kalendertabelle wichtig wird. Betrachten wir den Februar für 2018 (3), so fällt auch hier auf, dass der YTD_PY-Wert (46€) am 15.02.2018 verschieden ist vom Wert des gesamten Februar (59€). Ein solches Ergebnis verwundert den Betrachter eines Berichtes häufig, denn es sieht nicht korrekt aus. Diesmal liegt das Ergebnis jedoch nicht am Schaltjahr, sondern daran, dass meine Kalendertabelle lediglich bis zum 15.02.2018 geht. Es ist also vermeidbar. Zwar habe ich in meiner Faktentabelle bisher nur Werte bis zum 15.02.2018, aber meine Kalendertabelle sollte das gesamte Kalender- bzw. Geschäftsjahr abbilden. Ich erweitere nun meine Kalendertabelle und aktualisiere das Datenmodell:

Auch, wenn ich noch nicht alle Werte für Februar 2018 in meiner Faktentabelle habe, bin ich in der Lage, für in der Zukunft liegende Tage (rot gerahmt), Vorjahreswerte zu kalkulieren. Dies geschieht in meinem Beispiel automatisch, wenn ich die Kalendertabelle vollständig erstelle. Es gibt dem Betrachter ein größeres Vertrauen in die erzeugten Zahlen, wenn ein Year-to-date-Wert am letzten Tag des Monats auch gleichzeitig dem Gesamtwert des Monats entspricht, denn das wäre auch meine Erwartung 🙂

Sortierspalten für Textspalten

Die nächste technische Anforderung an eine Kalenderatbelle, die ich in diesem Beitrag erwähnen möchte, beschäftigt sich mit dem Sortieren von Textspalten. Textspalten innerhalb einer Kalendertabelle, wie beispielsweise die Spalte „Name des Tages“, mit Ihren Werten „Montag, Dienstag, …“ werden in Visualisierungen automatisch alphabetisch sortiert. Für die Tage der Woche ergäbe sich also folgende Darstellung:

Da eine alphabetische Sortierung in den seltesten Fällen gewünscht ist, ist es sinnvoll zusätzlich zu der entsprechenden Textspalte eine weitere nummerische Spalte zu erzeugen. Wichtig ist hierbei, dass es je Textwert genau einen eindeutigen nummerischen Wert geben muss:

Indem ich im Datenmodell definiere, dass die Spalte „Name des Tages“ nach der Spalte „Tag der Woche (Sort.)“ sortiert werden soll, werden die Tagesnamen danach in allen Visualisierungen korrekt sortiert.

Die Kalendertabelle als Datumstabelle markieren

Sowohl Power Pivot, als auch Power BI Desktop verfügen über die Möglichkeiten, eine Kalendertabelle als Datumstabelle zu markieren. Nachfolgend siehst Du, wie dies in Power BI Desktop und Power Pivot bewerkstelligt werden kann:

Wichtig ist diese Festlegung aus zwei Gründen:

1. Gilt für Power Pivot/ Power BI Desktop: Nur, wenn die Datumsspalte der Kalendertabelle explizit als solche definiert ist, kann zweifelsfrei davon ausgegangen werden, dass die Time Intelligence-Funktionen in DAX einwandtfrei funktionieren. Marco Russo hat hierzu einen detaillierten Artikel verfasst, den ich Dir für das tiefere Verständnis sehr ans Herz legen kann.
2. Gilt für Power BI Desktop: Power BI Desktop erstellt grundsätzlich für jede im Datenmodell existierende Datumsspalte eine versteckte, sehr einfache Kalendertabelle, bestehend aus Jahr, Quartal Monat und Tag. Dies bläht das Datenmodell unnötig auf. Definiert man in Power BI Desktop eine Datumstabelle , werden diese versteckten Datumstabellen nicht mehr erzeugt und bereits bestehende entfernt. ACHTUNG: Falls Du bereits Kalkulationen basierend auf diesen automatisch erzeugten Tabellen vorgenommen hast (was nicht best practise wäre), werden deine bestehenden Measures danach nicht mehr funktionieren.

Fazit

Ich habe mich in diesem Beitrag bemüht aufzuzeigen, welche Regeln beim Erstellen einer Kalendertabelle für Power BI und Power Pivot beachtet werden sollten. Mein Anliegen war es dabei, nicht nur die Regeln zu nennen, sondern auch aufzuzeigen, warum diese Regeln notwendig sind, oder anders: Welche Konsequenzen es hat, diese Regeln nicht einzuhalten.

Das Entwicklerteam der DAX-Engine, hat einmal Grundregeln formuliert, die sich auf die Nutzung von Time Intelligence-Funktionen in DAX beziehen:

1. Nutze niemals datime-Spalten aus Faktentabellen in Deinen Time Intelligence-Funktionen
2. Erzeuge immer eine separate Kalendertabelle
3. Versichere Dich, dass Deine Kalendertabelle einen lückenlosen Zeitraum abdeckt
4. Erzeuge Beziehungen zwischen den Faktentabellen und Deiner Kalendertabelle
5. Die datetime-Spalte in der Kalendertabelle muss die Granularität Tag haben und darf nicht kleiner sein (keine Uhrzeiten)
6. Markiere die Kalendertabelle als Datumstabelle und definiere die Datumsspalte.

Ich hoffe mein Beitrag hat dazu beigetragen, dass Du diese Regeln verstehen kannst 🙂

Nachdem ich in diesem Beitrag über die technischen Anforderungen einer Kalendertabelle geschrieben habe, wird sich im nächsten Beitrag alles um die inhaltlichen Anforderungen einer Kalendertabelle drehen.

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Ich schreibe meine Beiträge für Dich, den Leser. Bitte schenke mir eine Minute Deiner Zeit und bewerte die folgenden Kategorien, um mir zu helfen meine Beiträge so gut wie möglich zu schreiben. Danke 🙂

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Technische Anforderungen an eine Kalendertabelle in Power BI und Power Pivot erschien zuerst auf THE SELF-SERVICE-BI BLOG.