In 6 Schritten zum DWH-Datenmodell

Im letzten Post habe ich Euch etwas über unser neues Projekt im Immobilien-Umfeld erzählt. Wenn man ein Management-Informationssystem entwirft, ist ein zentrales Element davon die Modellierung der Daten. Sie definiert die Anordnung dieser innerhalb eines Data Warehouse Systems und ist somit das Herzstück eines jeden analytischen Informationssystems. Ein DWH-Kerndatenmodell sollte folgende Anforderungen erfüllen:

  1. Ermöglicht schnelle Abfragen von grossen Datenmengen
  2. Stellt tiefe Granularität von Daten und lückenlose Historisierung bereit
  3. Bietet Flexibilität bei der Erweiterbarkeit für neue Use Cases in der Analyse
  4. Stellt Stabilität der Kernstrukturen (Tabellen, Sichten, Attribute) sicher
  5. Verfügt über eine stringente Namensgebung bei allen Objekten

Wie bei anderen Entscheidungen muss man auch hier zwangsläufig Kompromisse eingehen. Denn ein System, das zu 100% stabil ist, ist nicht mehr flexibel  und umgekehrt. Man sollte dabei beachten, dass ein Data Warehouse verschiedene Anspruchsgruppen hat. Der Betrieb ist in der Regel daran interessiert, die Komplexität zu reduzieren um die Kosten in den Griff zu kriegen. Der Anwender hingegen legt zu Recht mehr Wert auf Flexibilität und Erweiterbarkeit in der Datenanalyse.

Nun, wie erstellt man so ein Data Warehouse Kerndatenmodell? Zwei Aspekte sind dabei zentral:

  1. Das WAS: Welche Modellierungsvariante wird für den DWH-Kern gewählt? Bekannte Modelle sind das Snowflake-Schema, das Star-Schema oder etwas moderner «Data Vault».  Alle diese Modelle haben ihre Vor- und Nachteile. Der Einsatz ist abhängig von der gewählten Data Warehouse Architektur und diese wiederum von den Zielen, die das neue System erfüllen muss sowie von den Voraussetzungen der bestehenden Prozess- und Applikationslandschaft. Die meisten Architekturen sind durch Bill Inmon oder Ralph Kimball beinflusst.
  2. Das WIE: Welches Vorgehensmodell wird gewählt? Die Frage lautet: top down oder bottom up? Entweder wir gehen von den verfügbaren Quellen aus und bauen die Datenstrukturen nach, oder wir richten uns konsequent an den Anforderungen der Nutzer nach Kennzahlen aus. Das Problem: Beide Ansätze sind nicht perfekt. Reproduziert man einfach die Quellsystemstrukturen, so ist es möglich, dass man am Nutzer vorbei produziert. Richtet man sich hingegen nach einem ersten Anwendungsfall (z.B. Finanz-Reporting) aus, besteht die Gefahr, dass mann sich zu stark auf einen Use Case beschränkt und keine weiteren (z.B. Produkt-Management) mehr bedienen kann. Zentral ist dabei, dass das Kerndatenmodell anwendungsfallunabhängig bleibt. Selbst dann, wenn man sich konsequent nach einem ersten Anwendungsfall ausrichtet.

Bezogen auf Punkt 1) ist wichtig, dass man sich für eine Variante entscheidet und diese dann so konsequent wie möglich durchzieht. Denn einer der Vorteile eines Data Warehouse ist die Harmonisierung der Daten zu einem gemeinsamen übergreifenden Datenmodell. Das schafft die Basis für viele neue Anwendungsfälle in der Datenanalyse.

Bezogen auf Punkt 2) verfolgen wir einen 6-Punkte Ansatz:

  1. Evaluation der Kennzahlen-Anforderungen: Im ersten Schritt sollte mit dem Kunden evaluiert werden, welche Kennzahlen er generell brauchen wird. Dabei ist noch nicht wichtig, in welcher Form diese wo dargestellt werden. Viel zentraler ist es,  die wichtigsten Steuergrössen (KPI) zu bestimmen.
  2. Im zweiten Schritt erarbeiten wir darauf basierend ein Business Entity Model. Eine Art konzeptionelles Datenmodell, das mit einem hohen Abstraktionsgrad aufzeigt, welche Geschäftsobjekte relevant sind, um diese Anforderungen zu erfüllen. Dieses Modell zeigt zum Beispiel die Beziehung von «Kunde», «Produkt» und «Verrechunngsdaten» auf. Es widerspiegelt die zentralen Objekte der Geschäftsprozesse eines Unternehmens.
  3. Im nächsten Schritt machen wir eine Ist-Aufnahme aller Quellsysteme, die der Kunde hat und prüfen die Relevanz hinsichtlich des Business Entity Model (enthält das System Geschäftsobjekte, die für den Kontext relevant sind?). Betrachtet wird das ganze Universum an Tabellen und Attributen, die das Quellsystem zur Verfügung stellen kann.
  4. Nun gilt es den Abstraktionsgrad des Datenmodells zu vertiefen. Dazu werden die Quellsystemtabellen und deren Attribute hinsichtlich der Zugehörigkeit zu einem Geschäftsobjekt im Business Entity Model überprüft. Damit können die physische Datenmodellierung des DWH-Kerns gemacht und die Quellattribute zum Zielmodell gemappt werden. Hier kommen die erwähnten Konzepte (Snowflake- & Sternschema) zum tragen.
  5. Das ganze ist ein iterativer Prozess. Im Sinne der Qualitätssicherung ist es ratsam, regelmässig die modellierten Objekte auf Erfüllung der Anforderungen hin zu prüfen. Als DWH Architekt ist es darum wichtig, eine übergreifende Sicht auf das Datenmodell zu haben. Besonders dann, wenn mehrere Modellierer an unterschiedlichen Subject Areas arbeiten. Es ist absolut zentral, sicherzustellen, dass z.B. Beziehungen zwischen diesen Elementen richtig und konsequent abgebildet werden. Die Datenkonsumenten werden mit dem Ergebnis wesentlich glücklicher sein. 😉
  6. Steht das logische Datenmodell, legen wir die physischen Strukturen auf dem System an und entwickeln die ETL-Prozessketten, welche die Daten harmonisieren und regelmässig im Data Warehouse zur Verfügung stellen.

Wenn das Kerndatenmodell fertig entwickelt ist, bauen wir darauf in einer weiteren Schicht anwendungsfallspezifische Datensichten in Form von Views, verdichteten Tabellen oder multidimensionalen Cubes. Ein Reporting- oder Analyse-Anwender kann diese dann in beliebigen Business Intelligence Tools (z.B SAP Lumira) konsumieren und profitiert von einer zentral gewarteten und einheitlichen Datenwahrheit.

Viele Grüsse
Matthias