Kalendertabellen gehören in (fast) jede Auswertung. Aber was sind Kalendertabellen? Wozu und wie viele benötigt man? Wie geht man mit Urlaub und Betriebsferien um? Wie verhält sich Power BI ohne Kalendertabelle? Wir finden: genug Stoff für eine Serie. Wir fangen an mit: Was ist das, wozu und wie viele.

Eine Serie über Kalendertabellen?

Fast alle Auswertungen haben einen Zeitbezug. Kalendertabellen sollten daher in fast jeder Auswertung vorkommen. Eigentlich gilt: jedes Datum in einer Faktentabelle (Auftrag, Position, Buchung,...) verdient eine Kalendertabelle. Und wenn man keine hat, wird eine gestellt. Das ist nicht immer offensichtlich. Das betrachten wir auch in einem späteren Artikel.

Auf unserem Blog haben wir vor schon vor vielen Jahren diverse Artikel über Kalender-Tabellen geschrieben. Das Thema kommt aber immer wieder. Weil es eigentlich keine Auswertung ohne Zeitbezug gibt: Umsatz zu Vorjahr, Einkaufspreisentwicklung in den letzten 24 Monaten, Entwicklung von Absatzzahlen etc. Und deswegen machen wir jetzt eine Serie über das Thema:

  • Was ist eine Kalendertabelle, wozu braucht man sie und wie viele?
  • Wie erzeugt man eine Kalendertabelle? Viele Wege führen nach Rom.
  • Fiskaljahre: Was machen wir, wenn das Geschäftsjahr nicht am 1. Januar beginnt?
  • Wochenenden? Feiertage? Betriebskalender? Wie gehen wir mit diesen Ausnahmen um?
  • Wenn Sie keine haben wird Ihnen eine gestellt: Warum in Power BI immer mindestens eine Kalendertabelle vorhanden ist
  • Heute - wann ist das eigentlich?

Was ist eine Kalendertabelle

Eine Kalendertabelle ist eine Tabelle, in der pro Tag genau eine Zeile vorhanden ist. Die Mindestanforderung an eine Kalendertabelle ist eine Spalte mit einem fortlaufenden Datum. Fortlaufend bedeutet, dass zwischen dem kleinsten und größten Datum kein Datum fehlen darf - also auch keine Wochenenden, Feiertage oder Betriebsferien. Ein Datum darf außerdem nicht mehrfach vorkommen.

Neben dem Datum kann man dann weitere Spalten angeben, wie beispielsweise

  • Jahr
  • Quartal als Zahl
  • Quartal als Name
  • Jahr und Quartal
  • Monat als Zahl
  • Monatsname
  • Jahr + Monat als Zahl
  • Jahr und Monatsname
  • Wochentag als Zahl
  • Wochentagsname
  • und noch sehr viele Informationen mehr

Die eigentliche Information ist letztlich nur das Datum. Alle anderen Spalten leiten sich aus dem Datum ab. Ein bisschen so, wie eine Produkttabelle: Die Artikelnummer ist das bestimmende - der Name die Beschreibung, die Farbe, die Zolltarifnummer etc. leiten sich (wenn man so will) fachlich davon nur ab.

Wozu benötigt man eine Kalendertabelle?

Gerade, wenn du deine Auswertungen bisher in Excel gemacht hast, bist du gewohnt, alle benötigten Daten in einer große, zweidimensionale Matrix aufzubauen. Und über diese Matrix wird eine Pivot-Tabelle oder ein Pivot-Chart erzeugt. SVERWEIS & Co werden zu täglichen Begleitern. Das bläht das Datenmodell aber unnötig auf. So muss bei einer solchen Vorgehensweise beispielsweise die Artikelbeschreibung bei jeder verkauften Position vorhanden sein. Obwohl der Text doch immer gleich ist, wenn der Artikel verkauft wird.

In Power BI lernt man schnell, dass man über Beziehungen sein Datenmodell beispielsweise im Star- oder Snowflake-Schema aufbaut. Wenn du nicht weiß, was das ist, schau dir unseren (zugegeben schon etwas älteren) Artikel über Star/Snowflake-Schema in unserem Excel-Power-Pivot-Blog an.

Baut man sein Datenmodell anhand dieser "Vorgaben", erhält man Dimensionstabellen, wie Produkte, Länder, Kunden, Vertriebswege und vieles mehr. So nutzt man in der Faktentabelle nur einen Schlüssel beispielsweise zu einem Produkt, den man mit der Produkttabelle verknüpft, in der man alle weiteren Produktinformationen findet. Die Vorteile liegen auf der Hand:

  • das Datenmodell wird klarer: Statt vielen SVerweisen für jedes benötigte Feld sieht man klare Beziehungen zwischen Tabellen.
  • das Modell wird schneller: Bei Zeichnen beispielsweise eines Säulendiagramms muss Power BI nicht erst alle eindeutigen Produkte in den Positionen suchen. Power BI nimmt eindfach alle Sätze aus der Produkt-Tabelle (was normalerweise deutlich weniger sind als in der Positionstabelle)
  • kein Datenverlust: Möchte man herausfinden, welches Produkt nie bestellt wurde, ist die Suche über eine Verkaufsposition nicht möglich - weil dort kommen nur verkaufte Positionen vor. Hat man eine Produkttabelle ist die Aussage für welche Produkte keine Position vorliegt möglich.
  • das Datenmodell wird kleiner: Gerade Artikelnummern oder noch schlimmer Artikelbeschreibungen benötigen viel Speicherplatz. Legt man diese Information pro Position ab vervielfacht man den benötigten Speicherplatz.

Weitere Gründe für eine Kalendertabelle

DAX kennt viele Datumsbezogene-Funktionen (sog. Time-Intelligence Funktionen). Beispielsweise die häufig verwendete Funktion SAMEPERIODLASTYEAR. Diese Funktion erhält als ersten Parameter eine Referenz auf eine Spalte einer Tabelle, die im Datumsformat sein muss, deren Tage eindeutig und fortlaufend sein müssen. Oder nach der Definition im ersten Abschnitt: eben eine Kalendertabelle. Es gibt viele weitere Funktionen, wie

  • DATEADD
  • DATESYTD
  • DATESBETWEEN
  • DATESMTD
  • TOTALYTD
  • und noch sehr viele mehr

Und alle diese Funktionen benötigen eine: Kalendertabelle.

Und mal ehrlich: Achsenbeschriftungen mit 1,2 statt Januar, Februar sind nicht mehr zeitgemäß. Mit einer Kalendertabelle hat man durch Spalten, die man ja selbst definieren kann, alle Freiheiten:

  • lange Monatsnamen
  • kurze Monatsnamen
  • Wochentage
  • Wochentage kurz
  • Jahr mit Monat im Format beispielsweise "2020-Jan" oder "2020/Januar"

Wie viele Kalendertabellen brauche ich?

In den Daten einer Verkaufsposition hat man einen Schlüssel als Referenz zum Produkt - entweder einen internen Schlüssel oder ienfach die Artikelnummer. Die beiden Tabellen Position und Produkt werden in Beziehung gesetzt. Die Frage "wie viele Produkttabellen gibt es" kann man wohl immer mit "eine" beantworten. Bei Kalendertabellen ist das nicht ganz so einfach.

Ein Verkaufsauftrag in der Adventure-Works-Datenbank hat drei Datumsinformationen:

  • ein Bestelldatum (OrderDate)
  • ein Wunschliefertermin (DueDate)
  • und ein Versanddatum (ShipDate)

Tabelle SalesOrderHeader mit drei Datumsspalten

Prinzipiell handelt es sich um drei verschiedene Dimensionen, die nur das gleiche Datenformat haben: Einen Zeitstrahl der Bestellungen, einen Zeitstrahl der Wunschlieferungen und einen Zeitstrahl der Versendungen. Betrachten wir die Entwicklung der Anzahl der Aufträge über die Zeit, muss man sich entscheiden, welches Datum man für die Betrachtung verwendet. Möchte man alle drei betrachten, sind das drei verschiedenen Auswertungen. In diesem Fall würde man den Kalender dreimal importieren (in Power Query kann man Abfragen ja leicht duplizieren). Dann hat man eben keine Tabelle DimKalender, sondern drei Tabellen

  • DimKalenderBestellung
  • DimKalenderWunschliefertermin
  • DimKalenderVersand

Datenmodell mit drei Kalendertabellen

Wenn du aber die Anzahl Aufträge bezogen auf den Bestell- und auf den Versandtermin gemeinsam (wir lassen das Wunschlieferdatum jetzt mal außen vor), auf der selben Achse auswerten willst und, um eine Differenz oder eine "Welle" zu visualisieren, kommst du mit verschiedenen Kalendertabellen nicht weiter. In der Achse eines Säulendiagramms muss man sich für einen Wert, also für eine konkrete Kalendertabele entscheiden. In Power BI (wie auch in Excel Power Pivot) kann man zwischen zwei Tabellen nur eine (aktive) Verbindung herstellen. Möchte man zwei Datumsfelder mit der gleichen Kalendertabelle verbinden, ist eine der beiden Verbindungen inaktiv (gestrichelt). Wenn man diese inaktive Verbindung nutzen will, benötigt man eben eine Measure.

In unserem Beispiel verbinden wir die beiden Tabellen zweimal. Die Beziehung zu OrderDate ist aktiv, die zu ShipDate inaktiv (gestrichelt).

Aktive und inaktive Verbindungen zur Kalendertabelle

Die Entwicklung der Anzahl Aufträge nach dem Bestelldatum ist dann einfach:

Die Entwicklung der Anzahl Aufträge nach dem Versanddatum ist ein wenig komplexer:

Hier geben wir im Measure eindeutig an, dass nicht die aktive, sondern die inaktive Verbindung verwendet werden soll. Zu USERELATIONSHIP und dem Thema mit mehreren Datumsinformationen gibt es auf unserer Partner Seite einen eigenen Artikel..

Fazit

(Fast) jede Auswertung hat (mindestens) einen Datumsbezug. Dann benötigt die Auswertung (mindestens) eine Datumstabelle. Wenn du ein Datum aus einer Faktentabelle verwendest (Aufträge, Positionen, Buchungen,...) für eine Achse oder als Zeile/Spalte in einer Pvitodarstellung, dann machst du etwas falsch.

Im nächsten Artikel schauen wir uns an, wie man Kalendertabellen erzeugt.