5 Allgemeine Datenmodelle

5 Allgemeine Datenmodelle
Ziel der Datenmodellierung ist immer, ein Abbild der Realität in einer
datentechnisch darstellbaren Form zu schaffen. Die einzelnen Formen
der Abbildung unterscheiden sich hinsichtlich Realitätsnähe, Einfachheit
und Performance. Diese Ziele sind einander entgegengesetzt, so
dass die unterschiedlichen Modelle eine unterschiedlich starke Fokussierung
auf die einzelnen Zielrichtungen legen und es nicht »das beste
Datenmodell« geben kann. Jedes Modell verfügt über spezifische Vorzüge,
so dass der Aufbau eines Datenmodells nur in Abhängigkeit von
den betrieblichen Anforderungen erfolgen kann.
Nachfolgend wird zunächst auf die Grundlagen für die Entwicklung
von Datenmodellen eingegangen. Anschließend werden die gängigsten
Modelle erläutert, die bei der Modellierung von Data-Warehouse-Systemen
zum Einsatz kommen. Dies sind
■ Transaktionale Strukturen
■ Flache Strukturen
■ Star-Schema
■ Snowflake-Schema.
5.1 Grundlagen der Datenmodellierung
Das Ziel jedes Datenmodells ist die Abbildung eines bestimmten Ausschnittes
der Realität. Die klare Definition dieses Ausschnittes charakterisiert
jedes Data Warehouse und grenzt es von anderen Systemen
wie zum Beispiel Dokumenten-Management-Systemen oder Web-Content-Systemen
ab.
Dabei handelt es sich um nicht volatile (nicht veränderliche)
Daten, die ab dem Zeitpunkt der Übernahme ins Data Warehouse
nicht (oder nur geringfügig) verändert werden und zur Analyse und
47

48
5 Allgemeine Datenmodelle
Entscheidungsfindung verwendet werden sollen, also nicht für den
operativen Geschäftsbetrieb.
Bestandteil der Datenmodellierung sind Fakten, die sich in Form
quantifizierbarer Größen (Kennzahlen) ausdrücken lassen und in eine
Beziehung zu gruppierenden Größen (Merkmale, Attribute) gestellt
werden können.
5.1.1 Merkmale
Merkmale sind Bezugsgrößen mit betriebswirtschaftlicher Bedeutung
(zum Beispiel Kunde, Produkte, Werke oder Sachkonten), nach denen
eine sinnvolle Gruppierung von Kennzahlen möglich ist (Umsatz pro
Kunde, Produktionskosten der Produkte A bis G, durchschnittliche
Lieferzeit aller Werke und so weiter).
5.1.2 Attribute
Bei Attributen handelt es sich um Merkmale, die von anderen Merkmalen
abhängig sind. Dies ist zum Beispiel bei der Postleitzahl (Abhängigkeit
vom Kunden) oder bei Produkteigenschaften (Abhängigkeit
vom Material) der Fall.
Die Abhängigkeit der Attribute von Merkmalen wird immer dann
gestört, wenn sie sich im Zeitverlauf ändern. Dies wäre zum Beispiel
der Fall, wenn sich die Adresse eines Kunden ändert oder Produkteigenschaften
verändert werden.
Während OLTP-Systeme zwingend auf aktuelle Attribute angewiesen
sind, stellt sich beim Data Warehousing die Situation anders dar,
da auch andere Möglichkeiten sinnvoll sein können, um derartige Veränderungen
von Attributen im Zeitverlauf darzustellen.
Diese Historisierung von Attributen kann im Datenmodell auf drei
unterschiedlichen Wegen nachvollzogen werden:
■ Aktuelle Darstellung: Attribute werden immer so ausgeprägt, wie
sie sich zum Zeitpunkt des Reportings darstellen. Dabei ist es
unabhängig, ob Daten des aktuellen Monats oder Vorjahresdaten
analysiert werden.
■ Stichtagsbezogene Darstellung: Alle Attribute werden im Reporting
so dargestellt, wie sie sich zu einem festgelegten Stichtag dargestellt
haben. Diesen Stichtag legt der Benutzer in der Regel selbst
vor der Ausführung der Analyse fest.

5.1 Grundlagen der Datenmodellierung
■ Historisierte Darstellung: Attribute werden immer so dargestellt,
wie sie sich zum Bezugszeitraum des Reportings dargestellt haben.
So werden Daten des Vorjahres mit den Attributen dargestellt, die
im Vorjahr aktuell waren, während Daten des Vormonats im gleichen
Bericht mit den Attributen dargestellt werden, die im Vormonat
aktuell waren.
Diese drei Möglichkeiten zur Historisierung von Attributen stellen
sehr unterschiedliche Anforderungen an ein Datenmodell. Je nach
Datenmodell werden unterschiedliche Historisierungen von Stammdaten
unterstützt.
5.1.3 Kennzahlen
Kennzahlen sind quantifizierende Größen, mit denen mathematische
Operationen möglich sind. Kennzahlen sind nur dann sinnvoll zu
benutzen, wenn ihnen entsprechende Bezugsgrößen (Merkmale) zugeordnet
werden. So erfordert die Angabe eines Umsatzes zum Beispiel
immer die Angabe eines Zeitraumes, eines Kunden, eines Produktes
oder Ähnliches.
Im Rahmen der Datenanalyse werden Kennzahlen entweder mit
Hilfe arithmetischer Operationen zusammengefasst (Summierung,
Durchschnittsbildung, MIN/MAX-Werte etc.) oder sie dienen zur
Berechnung weiterer Kennzahlen (zum Beispiel prozentuale Veränderungen,
Differenzen etc.)
Bei Analysen im BW werden Kennzahlen immer in Verbindung mit
Merkmalen verwendet und umgekehrt. Die Verwendung von Kennzahlen
ohne Merkmale oder umgekehrt ist in der Betrachtungsweise
eines Data Warehouse nicht sinnvoll.
5.1.4 Status Tracking
Status Tracking beschreibt die Abbildung belegnaher Informationen in
einem Datenmodell, zum Beispiel die Speicherung von Auftragsdaten.
Ebenso wie bei der Historisierung von Attributen erhält die Aktualisierung
auftragsbezogener Daten eine besondere Bedeutung.
Ändert sich im OLTP-System zum Beispiel der Auftragsstatus (dieser
ist im Datenmodell abhängig von der Auftragsnummer), so muss
sich auch der Auftragsstatus im Datenmodell des Data Warehouse
ändern. Im Unterschied zu Kennzahlen können die Informationen
jedoch nicht auf einer aggregierten Ebene abgelegt werden, sondern
müssen auf derselben Detaillebene gespeichert werden wie im OLTP-
System.
49

50
Abb. 5–1
Transaktionales
Datenmodell
5 Allgemeine Datenmodelle
5.2 Transaktionale Strukturen
Transaktionale Strukturen dienen dazu, Daten eines OLTP-Systems in
einer relationalen Datenbank zu speichern. Diese Strukturen werden
dabei vor allem für die Speicherung von Daten auf einer atomaren
Ebene 1 , zur Vermeidung von Redundanzen 2 und für den schnellen
Zugriff auf einzelne Transaktionsdaten benötigt.
Zu diesem Zweck werden die Daten in der Regeln in der dritten
Normalform abgelegt, welche diese Anforderungen erfüllt (siehe
Abbildung 5–1).
Frühe OLAP-Tools haben für die Analyse direkt auf die Transaktionsdaten
in OLTP-Systemen zurückgegriffen. da ihnen keine andere
Datenbasis zu Verfügung stand. Dies bringt jedoch zwei gravierende
Nachteile mit sich: Schlechte Performance und eingeschränkte
betriebswirtschaftlichen Analysemöglichkeiten.
Die schlechte Performance transaktionaler Strukturen ist dadurch
bedingt, dass analytische Anwendungen in der Regel keinen Nutzen
aus einzelnen Transaktionen gewinnen können, sondern eine übergreifende
Information zu mehreren Transaktionen benötigen.
In einem transaktionalen Datenmodell würde jedoch eine Abfrage,
welchen Umsatz ein Unternehmen in den letzten zwei Jahren erbracht
hat, das Lesen sämtlicher Transaktionen der letzten zwei Jahre mit sich
bringen, was mitunter mehrere Stunden, Tage oder gar Wochen dauern
könnte – und das, obwohl diese genaue Detaillierungstiefe gar nicht
benötigt wird.
1. Die atomare Ebene beschreibt die Speicherung von Informationen auf dem
Detaillierungsgrad einzelner Transaktionen (zum Beispiel einer Auftragsposition).
2. Zum Beispiel durch einmaliges Vorhalten von Stammdaten in der aktuellsten
Form.

5.3 Flache Strukturen
Des Weiteren würden die OLTP-Systeme mit Analysen belastet
werden, für die sie ursprünglich nicht entworfen wurden.
Neben den Performance-Problemen haben transaktionale Strukturen
den Nachteil, dass sie ausschließlich die aktuelle Darstellung von
Attributen unterstützen.
Aus diesen Gründen werden die Daten der OLTP-Systeme in
modernen Data-Warehouse-Systemen nur noch genutzt, um Informationen
einmalig auszulesen und in spezielle Datenmodelle zu transformieren,
die eher für analytische Anwendungen geeignet sind (Flache
Strukturen, Star-Schema, Snowflake-Schema).
5.3 Flache Strukturen
Flache Tabellenstrukturen sind die »Urform« der OLAP-spezifischen
Datenmodelle. Sie stellen den ersten Anfang dar, analytische Daten
von operativen (transaktionalen) Daten zu trennen und bieten damit
die Möglichkeit, Daten in einer aggregierten Form zu speichern, so
dass Analysen je nach Aggregationsstufe auf eine stark verkleinerten 3
Datenbasis zugreifen können. Abbildung 5–2 verdeutlicht dies.
Während transaktionale Strukturen normalisiert sind (zum Teil bis zur
dritten Normalform), werden flache Strukturen bewusst denormalisiert,
um die Datenbasis auf einer höheren Aggregationsstufe und in
einer einfacheren Form abzubilden. Dies stellt aus analytischer Sicht
bereits eine Verbesserung gegenüber transaktionalen Strukturen dar,
jedoch werden sie aufgrund einiger Nachteile in der Regel nicht mehr
als Datenbasis für OLAP-Anwendungen genutzt:
3. Bitte beachten Sie immer: Die Summe aller Kennzahlen bleibt auch nach der
Aggregation gleich, vermindert wird lediglich die Detaillierungstiefe!
Abb. 5–2
Flaches Datenmodell
51

52
5 Allgemeine Datenmodelle
■ Sämtliche Merkmale müssen als Tabellenschlüssel abgelegt werden.
Mit den so entstehenden sehr langen Schlüsseln ergeben sich bei
relationalen Datenbanksystemen häufig Performance-Nachteile.
■ Die Anzahl der Felder in Tabellen werden durch das Datenbanksystem
begrenzt, so dass unter Umständen nicht alle Anforderungen
erfüllt werden können.
■ Es ist ausschließlich eine historisierte Darstellung von Attributen
möglich.
■ Änderung des Datenmodells machen einen aufwändigen Neuaufbau
der gesamten Tabelle notwendig.
Flache Strukturen werden in Data-Warehouse-Systemen heute vor
allem noch zum Austausch von Daten zwischen Systemen und im
Bereich des Staging eingesetzt. Gerade beim Datenaustausch kommt
der Vorteil der flachen Strukturen zum Tragen, dass sie nicht auf relationale
Datenbanken angewiesen sind und ebensogut auch als (Text-
)Dateien abgelegt werden können.
Im BW werden flache Strukturen in allen Bereichen verwendet, die
für einen Datenaustausch zuständig sind (Extraktion von Daten aus
Quellsystemen, Staging), da diese Form des Datenaustauschs am einfachsten
und performantesten zu realisieren ist. Dabei werden die
Daten bei Bedarf auch aus ihren jeweiligen Datenmodellen in flache
Strukturen transformiert.
5.4 Star-Schema
Das Star-Schema bietet aus analytischer Sicht die selben Leistungsmerkmale
wie flache Strukturen, das heißt eine historisierte Darstellung
von Attributen. Allerdings hat das Star-Schema nicht die Nachteile
flacher Strukturen bezüglich der Performance, da es speziell auf
die Leistungsmerkmale relationaler Datenbanken abgestimmt ist und
die Daten auf mehrere Tabellen aufteilt. Dabei bleibt das Datenmodell
denormalisiert wie in der flachen Struktur.
Das Star-Schema setzt sich aus einer zentralen Faktentabelle und
mehreren damit relational verbundenen Dimensionstabellen zusammen.
Die relationale Verbindung zwischen Faktentabelle und Dimensionstabellen
wird mittels künstlicher Schlüssel (Surrogate Keys) abgebildet.
Bei entsprechender grafischer Darstellung erinnert das Datenmodell
an einen Stern, was den Namen dieses Modells erklärt (siehe
Abbildung 5–3).

5.4 Star-Schema
Die Faktentabelle nimmt ausschließlich Kennzahlen und die Schlüsselfelder
für die Dimensionen auf. Dabei wird es möglich, Schlüssel mit
möglichst wenigen und kurzen Feldern (in der Regel 4 Byte) einzusetzen,
was eine bessere Performance für die Datenbank ermöglicht.
Zugriffe auf die Faktentabelle erfolgen normalerweise immer in
Verbindung mit einer oder mehreren Dimensionstabellen, deren
Schlüsselfelder den Zugriffsschlüssel für die Faktentabelle bilden.
Die Dimensionstabellen bilden die Enden des »Sterns«. In ihnen
werden Merkmale und Attribute zu den jeweiligen Datensätzen der
Faktentabelle gespeichert. Auch Textinformationen (»Müller« für
Kunde 4711) wird bei einem reinen Star-Schema in den Dimensionen
gespeichert.
Die Verknüpfung der Dimensionstabellen mit der Faktentabelle
wird über eindeutige, künstliche Schlüssel (siehe unten) realisiert. Jeder
dieser Schlüssel kennzeichnet eine Zeile in der Dimensionstabelle und
eine oder mehrere Zeilen in der Faktentabelle. Der Schlüssel aller
Dimensionstabellen zusammen identifiziert jeweils eine Zeile in der
Faktentabelle.
Dimensionstabellen sind denormalisiert (wie flache Strukturen)
und häufig nach thematischen Geschichtspunkten gebildet. So werden
Produktattribute in der Regeln in einer Produktdimension gespeichert,
Kundenattribute in einer Kundendimension und so weiter.
Die Verbindung der Dimensionstabellen mit der Faktentabelle
wird über eindeutige Schlüssel realisiert. Dabei wird als Schlüssel nicht
der Merkmalswert einer Dimension, sondern ein künstlicher Schlüssel
gewählt.
Abb. 5–3
Star-Schema
Faktentabelle
Dimensionstabellen
Künstliche Schlüssel
53

54
Abb. 5–4
Snowflake-Schema
5 Allgemeine Datenmodelle
Dies vereinfacht die Modellierung in der Form, dass Merkmale
und Attribute frei in den Dimensionen verteilt werden können und
auch n:m-Relationen innerhalb einer Dimension möglich sind. Dies ist
die Grundvoraussetzung für die historisierte Darstellung von Attributen.
Solche Dimensionen werden auch als Slowly Changing Dimensions
bezeichnet; hier werden unterschiedliche Kombinationen von
Merkmalen/Attributen in einer Dimension abgelegt.
5.5 Snowflake-Schema
Das Snowflake-Schema ist eine Erweiterung des Star-Schemas. Es
erweitert das Star-Schema um Stammdatentabellen, die es ermöglichen,
Attribute nicht nur historisiert, sondern auch aktuell darzustellen.
Dabei wird das Grundmodell des Star-Schemas beibehalten. Hinzu
kommt jedoch die Option, Attribute nicht in Dimensionen, sondern in
Stammdatentabellen abzulegen, die relational mit Merkmalen in den
Dimensionen verbunden sind.
In Abbildung ist dies am Beispiel der Postleitzahl dargestellt. Diese
kann entweder in der Kundendimension (historische Darstellung)
oder in den Kundenstammdaten (aktuelle Darstellung) aufgenommen
werden.
Ebenso ist es möglich, die Postleitzahl in beiden Tabellen aufzunehmen,
so dass der Anwender bei der Datenanalyse zwischen beiden
Alternativen wählen kann. Dadurch wird das Snowflake-Schema
jedoch wesentlich komplexer. Die Administration ist aufwändiger und
für das Datenbankmanagementsystem ist es schwieriger, das Modell
performant zu lesen

.
5.6 Zusammenfassung
Für Anwender ist die wahlweise historische oder aktuelle Darstellung von
Attributen teilweise verwirrend. Setzen Sie daher die Möglichkeiten des
Snowflake-Schemas sehr bewusst ein, um spätere Verwirrung oder gar die
Ablehnung des Systems zu vermeiden.
5.6 Zusammenfassung
Die folgende Übersicht fasst noch einmal die wichtigsten Eigenschaften
der beschriebenen Datenmodelle zusammen.
Modell Transaktional Flach Star Snowflake
Performance schlecht gut sehr gut sehr gut
Komplexität hoch gering mittel hoch
Historisiert – ✓ ✓ ✓
Aktuell ✓ – – ✓
Stichtag – – – –
In der Praxis werden die vorgestellten Datenmodelle mit zahlreichen
Abwandlungen und Erweiterungen eingesetzt. Auch das BW verwendet
Datenmodelle, die speziellen Anforderungen angepasst wurden.
55
Tab. 5–1
Überblick über allgemeine
Datenmodelle