Die Erstellung eines geeigneten Datenmodells ist in vielen Data Warehouses eine der größeren Herausforderungen. Wie werden die analytischen Anforderungen an das Data Warehouse in geeignete Datenstrukturen übersetzt? Das vorliegende Kapitel befasst sich mit der Thematik der Datenmodellierung im Data Warehouse.

• Abschnitt 3.1 beschreibt die unterschiedlichen Vorgehensweisen für die Datenmodellierung im Data Warehouse mit ihren Vor- und Nachteilen.

• Abschnitt 3.2 gibt einen kurzen Überblick über die relationale Datenmodellierung und zeigt auf, in welchen Bereichen im Data Warehouse sie eingesetzt werden kann.

• Abschnitt 3.3 erklärt die wichtigsten Konzepte und Begriffe der dimensionalen Datenmodellierung. Diese Art der Datenmodellierung kommt in fast allen DWH-Systemen zur Anwendung, zumindest für die Implementierung von Data Marts.

• Das Kapitel schließt mit Hinweisen zu Datenmodellierungswerkzeugen, die in Abschnitt 3.4 zusammengefasst sind.

Um ein Data Warehouse zu modellieren, also die Datenmodelle für Staging Area, Cleansing Area, Core und Data Marts zu entwickeln, gibt es verschiedene Vorgehensweisen. Nachfolgend werden zwei typische Ansätze vorgestellt. In den meisten DWH-Projekten werden Mischformen davon eingesetzt.

Bei diesem Ansatz werden zuerst die analytischen Anforderungen mittels fachlicher Analyse und Betrachtung der fachlichen Zusammenhänge ermittelt. Daraus werden die Datenmodelle der Data Marts und des Core abgeleitet. Erst dann werden die Quellsysteme untersucht, um zu ermitteln, woher die Daten beschafft werden können. Im Rahmen einer Gap-Analyse wird untersucht, welche erforderlichen Daten nicht in der gewünschten Form zur Verfügung stehen und unter Umständen von weiteren Datenquellen beschafft werden müssen.

Der Vorteil der in Bild 3.1 dargestellten Vorgehensweise ist, dass nur die fachlich relevanten Informationen im Data Warehouse gespeichert werden. Allerdings kann dies auch zu einem Nachteil werden: Werden in weiteren Phasen zusätzliche Anforderungen an das DWH gestellt, fehlen die dazu benötigten Informationen im Core, und das Datenmodell sowie die Schnittstellen zu den Quellsystemen und die ETL-Prozesse müssen nachträglich erweitert werden. Dieser Ansatz eignet sich deshalb nur dann, wenn die analytischen Anforderungen an das Data Warehouse bekannt und einigermaßen vollständig sind. Nachträgliche Erweiterungen sind möglich, aber aufwendig.

Wichtig bei diesem Ansatz ist deshalb, dass die Fachbereiche, die mit den Data Marts arbeiten werden, bereits zu Beginn des Projekts in die Entscheidungsprozesse eingebunden werden. Welche Informationen in welcher Form in den Data Marts zur Verfügung stehen sollen, muss von den zuständigen Fachbereichen festgelegt werden. Aus diesem Grund sollten geeignete Fachvertreter bei der Anforderungsanalyse und der logischen Modellierung der Data Marts involviert sein.

Die logische Datenmodellierung der Data Marts, also das Festlegen von Dimensionen und Hierarchien sowie Kennzahlen und Fakten, sollte nicht IT-getrieben, sondern in Zusammenarbeit zwischen dem DWH-Entwicklungsteam und den zuständigen Fachbereichen durchgeführt werden. Die physische Datenmodellierung der Data Marts, insbesondere die technische Umsetzung mittels relationaler oder multidimensionaler Technologie, wird ausschließlich von der Informatik gemacht. Die Fachseite wird für diese Aufgaben nicht einbezogen.

Bei der Datenmodellierung des Core besteht die Hauptschwierigkeit darin zu entscheiden, welche zusätzlichen Informationen im Core gespeichert werden sollen. Werden nur genau die Daten ins Core übernommen, die in den Data Marts benötigt werden, tritt bei zusätzlichen Anforderungen oder der Erweiterung bestehender Data Marts das Problem auf, dass das Core auch erweitert werden muss. Dies ist mit viel Aufwand verbunden. Deshalb sollte von Anfang an bei der Modellierung des Core überlegt werden, welche Daten fachlich relevant sein können und somit „auf Vorrat“ im Core abgelegt werden sollen. Ein empfehlenswerter Ansatz ist es, die Daten in der feinsten Granularität, die vom Quellsystem geliefert wird, im Core abzulegen und in den Data Marts auf die erforderliche Verdichtungsstufe zu aggregieren.

Dieser Ansatz geht von den zur Verfügung stehenden Daten der Quellsystemeaus, wie in Bild 3.2 dargestellt. Vorerst wird ‒ in der Regel IT-getrieben ‒ ermittelt, welche Informationen für das Data Warehouse relevant sind. Daraus wird das Datenmodell für das Core erstellt. Basierend auf dem Core werden dann in Zusammenarbeit mit den Fachabteilungen für unterschiedliche Bedürfnisse spezifische Data Marts erstellt. Wenn sich bei der Modellierung der Data Marts herausstellt, dass gewisse Informationen nicht zur Verfügung stehen, muss das Core entsprechend erweitert werden.

Diese Vorgehensweise wird oft verwendet, wenn die analytischen Anforderungen der Fachbereiche an das Data Warehouse noch unklar oder nur ansatzweise vorhanden sind. Darin besteht auch die Gefahr dieses Ansatzes: Oft werden zu viele oder die falschen Daten ins DWH übernommen, und das Core tendiert zu einem Archivierungssystem für Daten, die in keinem Data Mart benötigt werden. Wenn nur ein Quellsystem vorhanden ist, wird das Core mit großer Wahrscheinlichkeit nichts anderes als eine historisierte Kopie des Quellsystems werden, indem das gleiche oder ein sehr ähnliches Datenmodell verwendet wird.

Ein reiner quellsystemgetriebener Ansatz sollte als Vorgehensweise für die Datenmodellierung eines Data Warehouse möglichst vermieden werden, da es typischerweise zu DWH-Systemen mit vielen Daten führt, aber nicht den erforderlichen Informationen, die von den Fachbereichen benötigt werden.

Eine sinnvolle und oft angewendete Vorgehensweise ist es, in einem ersten Schritt die anforderungsgetriebene Datenmodellierung zu wählen, um dann in einer zweiten Phase mithilfe der quellsystemgetriebenen Modellierung das Datenmodell zu ergänzen.

Durch die Kombination der beiden Modellierungsvarianten kann sichergestellt werden, dass die Anforderungen an die Data Marts erfüllt werden. Zusätzlich werden fachlich relevante Informationen ins Core übernommen, die momentan zwar noch nicht benötigt werden, aber in Zukunft von Interesse sein könnten.

Die relationale Datenmodellierung wird typischerweise in OLTP-Systemen eingesetzt. Ein großer Teil der Quellsysteme, welche Daten an ein Data Warehouse liefern, besitzen ein Datenmodell in 3. Normalform.

Ob diese Art der Datenmodellierung auch im Data Warehouse eingesetzt werden soll, hängt von verschiedenen Faktoren ‒ und Meinungen ‒ ab. Während für Data Marts hauptsächlich dimensionale Datenmodelle verwendet werden (siehe Abschnitt 3.3), wird für das Core je nach verwendeter Architektur ein dimensionales oder ein relationales Datenmodell verwendet. Auch Mischformen zwischen diesen Ansätzen sind weit verbreitet.

Relationale Datenmodelle werden typischerweise als Entity-Relationship-Diagramme dargestellt. Die Entitätstypen werden als Tabellen implementiert. Die Beziehungen (Relationships) zwischen den Entitäten werden als Fremdschlüsselbeziehungen bzw. Foreign Key Constraints implementiert.

Entitätstypen werden im Entity-Relationship-Diagramm als Rechtecke dargestellt. Je nach verwendeter Darstellung und Modellierungstool werden darin nur die Namen der Entitätstypen oder auch die Attribute aufgeführt. Die Verbindungen zwischen den Entitätstypen werden als Linien zwischen den einzelnen Rechtecken dargestellt.

Für die Kardinalitäten und Bedeutungen der Beziehungen gibt es ebenfalls verschiedene Darstellungen (Chen, IDEF1X, UML, Bachmann etc.). Bild 3.3 zeigt ein Beispiel eines Entity-Relationship-Diagramms mit IDEF1X-Notation, erstellt mit dem CA Erwin Data Modeler.

Das wichtigste Grundkonzept der relationalen Datenmodellierung ist die Normalisierung der Daten. Ziel der Normalisierung ist es, Redundanz zu vermeiden. Der ursprüngliche Grund, damit Speicherplatz zu sparen, ist heute nicht mehr relevant. Nach wie vor wichtig ist es aber, durch die Vermeidung mehrfach gespeicherter Daten sicherzustellen, dass die Datenkonsistenz gewährleistet werden kann. Ein redundanzfreies relationales...