Jörg Menker

Im ersten Teil des Blogs zum Datenmodell habe ich mich mit Geschäftsvorfällen als fachlich abgrenzbare Teilbereiche befasst, im zweiten Teil mit der Bestimmung von Kennzahlen und deren Beziehungen untereinander. In der grundsätzlichen Reihenfolge

  • Bestimmung von Geschäftsvorfällen
  • Bestimmung von Kennzahlen
  • Bestimmung von Dimensionen

rücken wir jetzt also wieder einen Schritt weiter zum nächsten Schritt, der Bestimmung von Dimensionen.

Dimensionen stellen die Auswertungsachsen dar, also das „pro was?“ mit dem die Kennzahlen analysiert werden sollen. Das Schöne an dimensionalen Modelle ist, dass sie die Sachverhalte im Prinzip genauso darstellen wie wir Menschen denken. Wir wollen Kennzahlen aus unterschiedlichen Blickwinkeln betrachten, und die Dimensionen entsprechen diesen Blickwinkeln. Deswegen sind dimensionale Modelle sehr viel leichter verständlich als andere Modelle (zum Beispiel solche in 3. Normalform).

Unabhängig von der späteren Ausgestaltung des physischen Datenmodells ist es häufig in Workshops für die Kundenseite verständlicher, wenn man Dimensionen als Snowflake (normalisierte Dimensionen mit eigenen Tabellen für jede Hierarchiestufe) modelliert, auch wenn dieser später wieder zum Star (eine flache Tabelle pro Dimension) wird.

star_vs_snowflake

Dimensionen ermöglichen erst die Auswertung von Kennzahlen. Gleiche Dimensionen in unterschiedlichen Modellen sollten unbedingt als konforme Dimensionen gestaltet werden. D.h. es werden dieselben Dimensionen auch in anderen Modellen verwendet. Das ist ein wichtiger Punkt, denn dadurch erreichen wir eine Verknüpfbarkeit verschiedener Modelle und ermöglichen erst den sogenannten SPOT-Charakter (Single Point of Truth) des Data Warehouse. In der untenstehenden symbolischen Abbildung sind alle konformen Dimensionen blau gefärbt.

konforme_dimensionen

Konforme Dimensionen haben noch einen weiteren, nicht zu unterschätzenden Vorteil: Mit jedem neuen Geschäftsvorfall, der sich in einem neuen dimensionalen Modell niederschlägt, kommen immer weniger völlig neue Dimensionen hinzu, weil ein Großteil der Dimensionalität schon vorhanden ist. Nachfolgende Gecshäftsvorfälle sind daher auch mit weniger Aufwand implementierbar, da bereits für andere Geschäftsvorfälle gefüllte Dimensionen hierfür nicht neu bewirtschaftet werden müssen.

Bei der Bestimmung der Kennzahlen haben wir bereits Ankerpunkte der Dimensionalität bestimmt, die Ausgangsbasis für die Dimensionen darstellen. So unterschiedlich die Dimensionalität dimensionaler Modelle auch sein kann, so weisen sie alle mindestens eine Zeitdimension auf (meistens mit der Granularität Tag). Eine Dimension sollte zudem mindestens folgende typische Attribute aufweisen:

  • Surrogatschlüssel (PK)
  • Business Key (fachlicher Schlüssel; unique Key allein oder in Verbindung mit einem Gültig-von-Datum bei SCD 2 (s.u.))
  • Bezeichnung (z.B. Produktbezeichnung)

Der nächste Schritt im Design der Dimensionen ist die Bestimmung ihrer Attribute und der Beziehungen der Attribute untereinander (z.B. Hierarchien). Die Attribute der Dimensionen bestimmen letztendlich die mögliche Vielfalt der Auswertungen. Die Analyse der Attributbeziehungen ermöglicht das Aufdecken von polyhierarchischen Attributen oder unbalancierten Hierarchien, bei denen eine oder mehrere Hierarchiestufe(n) übersprungen wird bzw. werden. Wie man mit solchen Hierarchien oder mit solchen mit einer im Vorhinein unbekannten Anzahl von Hierarchieebenen umgeht bedarf der Vertiefung in einem eigenen Beitrag und ist ggf. komplex.

hierarchie_zeit

Einfache hierarchische Attributbeziehungen anhand einer Zeitdimension.

Oft fällt es schwer zu entscheiden ob ein Attribut einfach nur ein Attribut ist oder doch selbst eine Dimension darstellt. Z.B. können Informationen zur Geographie (Adresse) Attribut einer Dimension sein oder auch eine eigene Dimension. Wenn die gleichen Attribute in mehreren Dimensionen vorkommen ist das ein Indiz dafür, dass es sich um eine eigenständige Dimension handeln könnte, muss aber nicht unbedingt so sein. Der Unterschied liegt vor allem in der Zuordnung: Diese ist bei einem Attribut zwingend, bei einer Dimension nur optional, weil die Zuordnung nur dann zustande kommt, wenn es auch Kennzahlen dazu gibt.

Hat man alle Attribute aller Dimensionen bestimmt und auch deren Beziehungen geklärt, stellen sich die nächsten Fragen:

  • Passen alle Kennzahlen zu allen Dimensionen?
  • Wie muss mit Änderungen an Attributen im Zeitablauf umgegangen werden?

Häufig stellt man bei der Anforderungsaufnahme fest, dass nicht alle Dimensionen zu allen Kennzahlen passen, z.B. weil es unterschiedliche Granularitäten in den Dimensionen gibt. Dies ist ein klarer Hinweis darauf, dass hier verschiedene Geschäftsvorfälle vorliegen, die in separaten Modellen abzubilden sind. Aus Vereinfachungsgründen verwendet man ein etwas generischeres Modell oft für mehrere Geschäftsvorfälle und unterscheidet diese anhand einer zusätzlichen Dimension, die angibt um was für einen Geschäftsvorfall es sich handelt. Hierbei hängen Fakten dann häufig an den „unknown Records“ (Dummy-Einträge) von Dimensionen, weil die eine oder andere Dimension für den jeweiligen Geschäftsvorfall nicht zutrifft bzw. relevant ist. Hilfreich zur Bestimmung der Anzahl (theoretisch) notwendiger Modelle ist die sogenannte Busmatrix, in der die Zuordnung von Dimensionen und Fakten in tabellarischer Form erfolgt.

Attribute in Dimensionen ändern sich mehr oder weniger häufig, meist jedoch deutlich weniger häufig als Bewegungsdaten. Kimball, der Vater der dimensionalen Modellierung, spricht daher von Slowly Changing Dimensions (SCD). Es ist wichtig zu wissen wie im DWH mit Änderungen umgegangen werden soll. Am gebräuchlichsten sind die Verfahren

  • Überschreiben mit dem aktuellen Wert (SCD 1)
  • Neue Version des Business Keys und zeitlicher Abschluss der alten Version (SCD 2)

Nachdem die Attribute und deren Beziehungen untereinander sowie die Historisierung geklärt ist, bleibt noch die Frage einer eventuellen toolspezifischen Modellierung, da manche BI-Frontends bestimmte Modellierungsarten bevorzugen, aber das ist nicht mehr Gegenstand dieses Blogbeitrags.