6 Konzeptioneller Vergleich von Data Vault und konsolidierter

White Paper der saracus consulting GmbH
Core DWH Modellierung:
Vergleich Data Vault und
konsolidierte Ankermodellierung
von
saracus consulting GmbH
Münster 2015
Autor:
Nadine Röse
saracus consulting GmbH
saracus consulting veröffentlicht regelmäßig White Paper zum Themenbereich Big Data, Business Intelligence und
Data Warehousing. Diese White Paper vermitteln den BI-Praktikern umsetzbares Wissen, konkrete Anleitungen zur
Einführung von Best Practice-Methoden und filtert aus den (vermeintlichen) Innovationen die Praxisrelevanz für
Anwendungsunternehmen. Die saracus White Paper sind keine Auftragsarbeiten für einen Sponsor (z.B. Hardware
oder Softwareanbieter aus dem BI-Markt) sondern basieren auf über 20 Jahren BI, DWH und neuerdings auch Big
Data-Erfahrungen, die sich in über 300 BI-Projekten widerspiegeln.

saracus IBM Cognos TM1 Whitepaper (2011)

saracus Big Data Whitepaper I (07/2012)

saracus Big Data Whitepaper II (01/2013)

saracus Datenmodellierung Whitepaper I (04/2013)

saracus Big Data Whitepaper III (06/2013)

saracus Datenmodellierung Whitepaper II (01/2014)

saracus Social Media Whitepaper I (04/2014)

saracus BI-Trends Whitepaper (05/2014)

saracus ETL Whitepaper I (07/2014)
Die White Paper stehen auf unserer Webseite unter http://www.saracus.com/saracus_240_white_paper.html als
PDF zum Download bereit.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 1
saracus consulting GmbH
Vergleich Data Vault und konsolidierte Ankermodellierung
1 Einleitung ............................................................................................................................................. 3
2 Zusammenfassung konsolidierte Ankermodellierung .......................................................................... 4
2.1
2.2
2.3
2.4
Ankertabellen .......................................................................................................................... 4
Standardtabellen mit zeitbezogenen Stammdaten ................................................................. 4
Relationstabellen ..................................................................................................................... 5
Beispiel konsolidierte Ankermodellierung............................................................................... 6
3 Bewertung der konsolidierten Ankermodellierung .............................................................................. 7
3.1
3.2
Vorteile der konsolidierten Ankermodellierung ...................................................................... 7
Nachteile der konsolidierten Ankermodellierung ................................................................... 7
4 Zusammenfassung Data Vault Modellierung........................................................................................ 8
4.1
4.2
4.3
4.4
4.5
Hubs ......................................................................................................................................... 8
Links ......................................................................................................................................... 9
Satelliten ................................................................................................................................ 10
Beispiel Data Vault Modellierung .......................................................................................... 11
Weitere Tabellentypen .......................................................................................................... 12
5 Bewertung der Data Vault Modellierung im Vergleich zur konsolidierten Ankermodellierung ........ 13
5.1
5.2
Vorteile der Data Vault Modellierung ................................................................................... 13
Nachteile der Data Vault Modellierung ................................................................................. 14
6 Konzeptioneller Vergleich von Data Vault und konsolidierter Ankermodellierung ........................... 15
6.1
6.2
6.3
6.4
6.5
6.6
6.7
Konsolidierte Ankermodellierung: Core DWH als “Single Source of Truth” .......................... 15
Nachteile eines konsolidierten Core DWH ............................................................................ 16
Antworten auf die Nachteile ................................................................................................. 17
Data Vault: neutrale Datendrehscheibe als “Single Version of Facts” .................................. 18
Vorteile des Data Vault im Vergleich zum konsolidierten CDW ............................................ 19
Data Vault im Gesamtkontext einer typischen Architektur................................................... 20
Bewertung von Data Vault in der Gesamtarchitektur ........................................................... 21
7 Fazit ..................................................................................................................................................... 22
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 2
saracus consulting GmbH
1
Einleitung
Das Herzstück eines unternehmensweiten Data Warehouses ist das Core Data Warehouse (Core
DWH). Im Laufe der Zeit haben sich verschiedene Methoden zur Datenmodellierung entwickelt, um
den projekt- und unternehmensspezifischen Herausforderungen zu begegnen. Um die passende
Modellierungsmethode auszuwählen, müssen Faktoren wie Flexibilität, (Lade-)Performance,
Historisierung, Auditfähigkeit, Datenqualität, Abfragekomplexität, Entwicklungs-, Wartungs- und
Weiterentwicklungsaufwand abgewogen werden.
Data Vault
Modellierung und die
konsolidierte
Ankermodellierung
sind sich in vielen
Aspekten ähnlich.
Im vorangegangenen White Paper „Ankermodellierung im Core DWH“ werden die am weitesten
verbreiteten Modellierungsansätze beschrieben: quellsystem-nahes Core DWH, Data-Mart-nahes
Core DWH und das Core DWH mit der konsolidierten Ankermodellierung.
Im White Paper
werden die
Modellierungsmethoden dargestellt
und in Abhängigkeit
mit der
Gesamtarchitektur
bewertet.
Im folgenden White Paper werden Data Vault und die konsolidierte Ankermodellierung vorgestellt
und ihre Stärken und Schwächen im Vergleich zueinander gezeigt. Im ersten Teil werden die
Modellierungsmethoden im Core DWH mit den jeweiligen Vor- und Nachteilen betrachtet.
Anschließend werden die Methoden basierend auf einer typischen Architektur im Gesamtkontext
analysiert und bewertet.
Die Data Vault Modellierung* (von Dan Linstedt erfunden und im Jahr 2000 veröffentlicht) gilt als
modernste Art der Modellierung. Die konsolidierte Anker-Modellierung mit Kopf- und
Versionstabellen, welche bei der Umsetzung von umfangreicheren DWH Umgebungen von saracus
oft eingesetzt wird, ist dem Data Vault in vielen Aspekten sehr ähnlich. Dieser saracusModellierungsstandard ist aus den Erfahrungen zahlreicher DWH Projekte entstanden und wurde
kontinuierlich verfeinert sowie erweitert. Damit hat dieser Ansatz seine Praxistauglichkeit seit vielen
Jahren bewiesen.
Das vorliegende White Paper setzt Vorkenntnisse mit den Begriffen der Datenmodellierung und
dem Data Warehouse Bereich voraus.
*Das White Paper bezieht sich auf die Modellierungsmethode wie im Data Vault Model 1.0
beschrieben und auf eine typische Architektur, wie sie in Data Vault 2.0 vorgestellt wird.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 3
saracus consulting GmbH
2
Zusammenfassung konsolidierte Ankermodellierung
Eine umfassende Herleitung und Beschreibung ist im White Paper „Ankermodellierung im Core
DWH“ zu finden. Achtung, die von saracus verwendete konsolidierte Ankermodellierung mit Kopfund Versionstabellen ist nicht zu verwechseln mit der „Anchor“-Modellierung, die mittels einer
formalisierten Modellierungstechnik zu einem Modell in der sechsten Normalform führt.
Ein Grundsatz der konsolidierten Ankermodellierung ist es, mittels stabilen künstlichen Schlüsseln
die zeitbezogenen Stamm- und Bewegungsdaten von den Beziehungen der Subjekte
untereinander zu entkoppeln.
Maßgebend sind die Anforderungen und Definitionen, wie sie vom Business vorgegeben werden.
Der Modellierung voraus geht daher immer eine Informationsbedarfsanalyse, in der die
inhaltlichen Anforderungen und fachlichen Regeln erhoben werden.
Im Core DWH werden die Daten in drei standardisierte Tabellentypen aufgeteilt: Ankertabellen,
(versionierte) Standardtabellen und Relationstabellen.
Im White Paper „Ankermodellierung im
Core DWH“ sind die
Hintergründe beschrieben, warum ein Ankerkonstrukt sinnvoll ist.
Die konsolidierte Ankermodellierung darf
nicht mit der „Anchor“Modellierung zu verwechselt werden.
Die Ankermodellierung ist eine Form des ERM (Entity Relationship Modeling) und beruht auf der
3. Normalform.
2.1
Ankertabellen

Bezogen auf ein fachliches Subjekt (z.B. Vertrag oder Kunde) wird pro fachlichem Schlüssel
(Business Key) im ETL-Prozess eine stabile, künstliche ID erzeugt (TIK, Time-invariant key). Z.B.
für jede Vertragsnummer wird eine TIK-Sequenz ID per Datenbank-Sequenz zugeordnet.

Der TIK wird in einer „Ankertabelle“ abgespeichert und ist Primärschlüssel (Vertrag_TIK).

Im Extremfall enthält die Ankertabelle ausschließlich den TIK. In der Praxis wird der fachliche
Schlüssel (z.B. Vertragsnummer) ebenfalls in der Ankertabelle abgelegt, was die
Abfragequeries und Datenbewirtschaftung vereinfacht.

Die Ankertabelle enthält nie Fremdschlüssel anderer Tabellen sondern wird ausschließlich als
Elterntabelle in Relations- und Standardtabellen referenziert.
2.2
Die Ankertabellen trennen die Schlüsselattribute von den veränderlichen Stamm- und
Beziehungsdaten.
Standardtabellen mit zeitbezogenen Stammdaten

Sie enthalten den TIK der Parent-Tabelle, einen Zeitbezug (Versionierung bzw.
gültig_ab/gültig_bis), den Business Key und alle weiteren dem Subjekt zugehörigen Daten.

Es wird entweder pro Datensatz eine eindeutige Datensatz-ID als Primärschlüssel erzeugt
(RowID/Sequenz) oder der Primärschlüssel wird zusammengesetzt aus TIK + gültig_ab.

Bei Bedarf können neben dem fachlichen Gültigkeitsverlauf, der oft aus dem Quellsystem
geliefert wird, auch Quellsystem- und DWH-technische Änderungszeitstempel hinzugefügt
werden (doppelte Versionierung bzw. bitemporale Modellierung und dreifache Versionierung
bzw. tritemporale Modellierung).

1:N Beziehung mit fachlicher Zusammengehörigkeit werden als Fremdschlüssel (FK) in den
Standardtabellen abgebildet. Z.B. ein FK zur „Vertragsart“ kann in der Standardtabelle
„Vertrag“ eingefügt werden.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
In den Standardtabellen
werden die Stammdaten eines Subjekts abgelegt inklusive den benötigten zeitlichen Änderungs- und Gültigkeitshistorien.
Seite 4
saracus consulting GmbH
2.3
Relationstabellen stellen Beziehungen zwischen Subjekten dar
und enthalten den benötigten Änderungsund Gültigkeitsverlauf
der Beziehung und zusätzliche weitere Informationen, welche die
Beziehung beschreiben.
Relationstabellen

Diese zeigen Assoziationen (Verbindungen von Subjekten), Bewegungsdaten und Hierarchien.

Alle 1:N und N:M Beziehungen zwischen Subjekten werden als Relationstabellen modelliert.

Die Beziehungen werden durch die Kombination der jeweiligen TIKs der referenzierten
Tabellen hergestellt sowie bei Bedarf einer Versionierung oder Verlaufsbildung ein
gültig_von/gültig_bis hinzugefügt, um die zeitliche Zuordnung der Relation abzubilden.

Der Primärschlüssel setzt sich zusammen aus dem führenden TIK des Subjekts (bzw. bei N:M
mehrere TIKs), welcher die Relation fachlich definiert und dem gültig_ab, welches die
Relation zeitlich einordnet.

Die Schlüsselkombination spiegelt den fachlichen Zusammenhang wider. Beispielsweise kann
ein Kunde mehrere Verträge haben, aber ein Vertrag gehört genau zu einem Kunden, der
aber mit der Zeit wechseln kann (Vertrag wird übernommen): in diesem Fall wird der PK der
Relationstabelle aus dem TIK des Vertrags + einem Zeitstempel gebildet.

Die Relationstabellen können noch weitere Datenfelder enthalten, die sich auf die
abgebildete Relation der verknüpften Subjekte beziehen.

Auch in den Relationstabellen kann es wie in den Standardtabellen einen einfachen oder
bitemporalen Zeitverlauf geben, im Extremfall sogar tritemporal (z.B. fachlicher und
technischer Verlauf des Quellsystems + DWH Ladezeitstempel zur Historisierung).

Zeitverläufe werden immer mit einem Anfangs- (gültig von) und Endzeitpunkt (gültig bis)
dargestellt. Bei Bewegungsdaten (z.B. Rechnungsbeträge) gibt es oft keinen fachlichen
Änderungsverlauf zu einem Subjekt, bei dem ein gültiger Zustand den nächsten ablöst.
Vielmehr besteht eine Abfolge von Buchungs- bzw. Transaktionssätzen. In diesen Situationen
wird eine künstliche ID erzeugt (RowID) und die Daten ggf. mit einem DWHMutationszeitstempel angereichert. Beziehungen zu anderen Subjekten können wiederum
als FKs zu deren TIKs eingefügt werden.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 5
saracus consulting GmbH
2.4
Beispiel konsolidierte Ankermodellierung
Die konsolidierte Ankermodellierung ergibt
eine intuitive und gut
lesbare Darstellung der
Geschäftsbeziehungen,
ohne Überflüssiges zu
enthalten.
Abbildung 1: Beispiel Ankermodellierung
Das Beispiel zeigt einen reduzierten, typischen Ausschnitt aus einem konsolidierten Core DWH mit
den Ankern Sachbearbeiter, Vertrag und Produkt.
Die Anker Vertrag und Produkt sind über eine Relationstabelle verbunden, wohingegen der
Sachbearbeiter in den zwei Rollen „Sachbearbeiter Betreuer“ und „Sachbearbeiter
Abschluss“ direkt mit der Standardtabelle des Vertrags verknüpft ist. In der Tabelle
Vertrag_Produkt_Relation sind alle Attribute abgelegt, die speziell für diese Kombination aus
Vertrag und Produkt gelten, wie z.B. eine individualisierte Prämie oder eine
vertragsproduktspezifische Risikoklasse.
Es entsteht ein relativ kompaktes, lesbares Modell, das die tatsächlichen Business-Beziehungen
abbildet und nichts Überflüssiges enthält. Der Overhead kann klein gehalten werden.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 6
saracus consulting GmbH
Im Vergleich zu anderen einfachen Modellierungen ohne Ankerund Versionstabellen
bietet die konsolidierte
Ankermodellierung
viele Vorteile: Standardisierung, Automatisierung, Lesbarkeit, Stabilität und Erweiterbarkeit.
3
Bewertung der konsolidierten Ankermodellierung
3.1
Vorteile der konsolidierten Ankermodellierung
Im Vergleich zu anderen gängigen Modellierungsmethoden im Core DWH wie quellsystem-nahem
Core DWH, Data-Mart-nahem Core DWH oder einer Auswertungslandschaft ohne EnterpriseDWH Schicht, bietet die Ankermodellierung folgende Vorteile:

Erweiterbarkeit: neue Bereiche können einfach und schrittweise ergänzt werden, in der Regel
ohne bestehende Subjekte zu beeinflussen.

Stabilität: Die Versionierung bezieht sich jeweils auf ein Subjekt oder eine Beziehung und wird
nicht in referenzierte Tabellen vererbt.

Weitgehend standardisierte ETL-Prozesse durch definierte Standards und Tabellentypen.

Kaum Redundanz durch die Verwendung der 3NF und generischer Bestandteile (z.B.
Geographie).

Die Grundprinzipien der Ankermodellierung bieten in der Praxis einen gewissen
Modellierungsspielraum und können abhängig von der Kunden- und Projektsituation und den
Business-Anforderungen optimal eingesetzt werden.

Das Modell ist intuitiv und bildet auf granularem Level die Geschäftsanforderungen ab.
3.2
Verglichen mit einfachen Modellierungsansätzen muss durch die
relativ hohe Anzahl
Tabellen und den konsolidierten Ansatz
mehr Aufwand in die
Modellierung und Bewirtschaftung investiert werden.
Nachteile der konsolidierten Ankermodellierung

Initial relativ hoher Modellierungs- und Bewirtschaftungsaufwand.

ETL Prozesse sind zwar in den meisten Fällen einfach und standardisiert, können bei
speziellen Relations- oder Standardtabellen aber auch komplex ausfallen.

Viele Tabellen, die auf den ersten Blick unübersichtlich sein können.

Für Abfragen muss oft mit Joins über viele Tabellen gearbeitet werden.

Freiräume in der Modellierung bieten auch Fehlerpotential: die Modellierungsmethode muss
beherrscht werden und es muss abgewogen werden, welche Variante am sinnvollsten ist.

Es muss ein gutes Verständnis der abzubildenden Geschäftsanforderungen vorhanden sein.
Die Vor- und Nachteile im Vergleich zur Data Vault Modellierung werden weiter unten im White
Paper betrachtet. Die große Herausforderung bleibt, die Balance zwischen den zu erfüllenden
Anforderungen (wie z.B. eine komplette Datenhistorie, Auditfähigkeit, hohe Datenqualität, Ladeund Quell-Performance oder Konsolidierungsgrad) und der dieser gegenüberstehenden
wachsenden Komplexität zu finden.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 7
saracus consulting GmbH
4
Zusammenfassung Data Vault Modellierung
Wie bei der Ankermodellierung handelt es sich bei der Data Vault Modellierung um eine Form des
Enterprise Data Warehouse mit ERM (Entitiy Relationship Modeling), in dem historische Daten auf
einem granularen Level in einer zentralen Datenhaltungsschicht abgelegt werden.
Auch beim Data Vault werden im Grundsatz die zeitabhängigen Daten von den Schlüsseln
entkoppelt. Wie bei der Ankermodellierung gibt es drei Tabellentypen, die im groben auch eine
ähnliche Verwendungsweise haben: Hubs, Links und Satelliten anstatt Ankertabellen,
Relationstabellen und Standardtabellen.
Abgesehen von der abweichenden Bezeichnung sind die Konzepte also auf den ersten Blick recht
ähnlich. In der Modellierung gibt es jedoch einen gravierenden Unterschied in der Handhabung
der Relationstabellen bzw. Links. Die Trennung zwischen Struktur und Kontext ist bei Data Vault
wesentlich konsequenter als bei der Ankermodellierung. Es ist zwingend erforderlich, die
Grundregeln der Modellierungsmethode einzuhalten.
Data Vault Modeling
verwendet das gleiche
Prinzip der Trennung
von Schlüsselattributen
und veränderlichen Daten.
Data Vault ist hier allerdings formeller und
konsequenter.
Die hier beschriebene formale Data Vault Modellierung findet insbesondere in der (Raw) Data
Vault-Schicht statt (für eine Abgrenzung der Begriffe siehe Kapitel 6.4).
4.1
Hubs
Die Schlüssel- bzw. Ankertabellen werden als „Hubs“ bezeichnet und enthalten wie bei der
Ankermodellierung einen künstlichen Schlüssel aus einer Datenbank-Sequenz oder Hashcodes. Der
künstliche Schlüssel ist 1:1 dem Business Key zugeordnet, der immer im Hub mit abgelegt ist.
Leider ist es nicht immer einfach, den Business Key zu bestimmen – manchmal ist es einfacher, den
systemtechnischen Schlüssel des Quellsystems anstatt einem „echten“ natürlichen Business Key zu
verwenden.
In jeder Tabelle (nicht nur in den Hubs) gibt es mindestens zwei Metadatenspalten: einen
Zeitstempel, wann der Datensatz eingefügt wurde (Ladezeitstempel) und das Quellsystem, das den
Datensatz (erstmalig) eingefügt hat. Die Hubs bestehen immer genau aus der ID-Spalte, dem
fachlichen Schlüssel (der zusammengesetzt sein kann) und den Metadaten
Ladezeitstempel+Quellsystem.
Konsolidierte Ankermodellierung
Data Vault Modellierung
Bezeichnung
Hauptzweck
Ankertabelle
Hub
Entkopplung der fachlichen,
Sammeln von Business Keys, Zuordnung
zeitbezogenen Daten mittels des TIK
von fachlichem Schlüssel zur künstlichen ID
Künstliche ID/
Ist eine Sequenz oder ein Hash-Schlüssel.
TIK (Time
1:1 zum fachlichen Schlüssel.
Invariant Key)
Der fachliche Schlüssel wird als unveränderlich betrachtet (*).
Fachlicher
In der Praxis immer enthalten. Kann
Immer enthalten. Kann zusammengesetzt
Schlüssel
zusammengesetzt sein.
sein.
ETL Metadaten In separaten Tabellen über
Quellsystem und Lade-Timestamp sind in
Ladelaufnummer ersichtlich.
jeder Datentabelle direkt enthalten
Inhalt
Konsolidiert:
Rohdaten: kein Matching von
Zugehörige fachliche Schlüssel
unterschiedlichen fachlichen Schlüsseln, die
zusammengeführt zu einer ID.
das gleiche bedeuten (z.B. bei
unterschiedlichen Quellsystemen).
Tabelle 1: Vergleich Ankertabellen mit Hubs
Die Hubs entsprechen
den Ankertabellen und
beinhalten den Business Key.
Im Data Vault kann
eine leichte Integration
der Daten über die Business Keys erfolgen.
Es erfolgt jedoch keine
Zusammenführung unterschiedlicher zusammengehöriger Business
Keys.
(*) ist der fachliche Schlüssel in der Realität leider manchmal nicht unveränderlich, gibt es auch
dazu eine Lösung. Im Data Vault kann mittels eines „SAME-AS“ Link und einem zusätzlichen Satellit
die Zuordnung der Business Keys zueinander dokumentiert werden.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 8
saracus consulting GmbH
In der Ankermodellierung löst sich der Fall dadurch, dass der Business Key nicht im Anker, sondern
ausschließlich in der versionierten Standardtabelle steht. Der TIK bleibt stabil, auch wenn sich die
Business Keys mit der Zeit ändern. Zusätzlich kann ähnlich wie im Data Vault eine
Schlüsselzuordnungstabelle erstellt werden, die das Matching erleichtert und auch komplexere Fälle
lösen kann (Splittung und Zusammenfassung von Business Keys).
4.2
Links
Bei den Relationstabellen spricht man von „Links“. Werden 1:1 und 1:N Beziehungen in der
konsolidierten Ankermodellierung oft in den Standardtabellen als Fremdschlüssel abgebildet, so wird
im Data Vault für jede Beziehung eine separate Linktabelle erzeugt. In den Linktabellen sind keine FKs
ausser der identifizierenden ID erlaubt.
Links entsprechen den
Relationstabellen,
enthalten allerdings
ausschließlich die IDs
der Hubs und sind
immer neutral in der
Kardinalität.
Darf in der konsolidierten Ankermodellierung der Zeitbezug sowie weitere beschreibende Attribute
zur Relation direkt in der Relationstabelle stehen, ist das im Data Vault nicht erlaubt. Der GültigkeitsZeitbezug wird nie im Link, sondern immer in den Satelliten abgelegt. Das führt zu einer klaren
Trennung von Struktur (Hubs, Links) und Inhalten inkl. Zeitbezug (Satelliten).
Der Link besteht immer ausschließlich aus einer eigenen PK-ID, den Fremdschlüsseln der Vatertabellen
und den Metadaten Ladezeitstempel und Quellsystem.
Die Links werden generell als N:M-Beziehungen angelegt und sind somit frei von Business Regeln, die
sich mit der Zeit ändern können. Z.B. wenn früher ein Vertrag genau ein Sachbearbeiter haben konnte
und neuerdings ein Vertrag mehrere Sachbearbeiter gleichzeitig haben kann, muss die Link-Tabelle
durch diese Business-Regel Änderung nicht angepasst werden.
Konsolidierte Ankermodellierung
Data Vault Modellierung
Bezeichnung
Relationstabelle
Link
Hauptzweck
Zuordnung von Subjekten nach BusinessLogik inkl. Zeitbezug und zusätzlich zur
Relation gehörigem Kontext.
Gemäß Business Logik 1:N, N:1 oder N:M
Struktur aufbauen. Hubs und Links bilden das
Skelett des Core DWH.
Kardinalität
Primärschlüssel
Fremdschlüssel
Immer als N:M angelegt.
der PK wird gemäß Business Logik
Jede Relation/Zuordnung erhält obligatorisch
gesetzt: einer oder mehrere der TIKeine eigene ID, welche den PK bildet.
Fremdschlüssel und der Zeitbezug.
FKs sind TIKs der Anker bzw. Hubs, welche die Relation identifizieren.
FK-Constraints werden in der Regel nicht physisch angelegt.
Weitere die Relation beschreibende
Attribute und TIK-FKs werden eingefügt
Keine weiteren Attribute oder FKs erlaubt.
ETL Metadaten
In separaten Tabellen über
Ladelaufnummer ersichtlich.
Quellsystem und Lade-Timestamp sind in
jeder Datentabelle direkt enthalten.
Inhalt
Konsolidiert.
Rohdaten, Vergleich siehe Kapitel 6.
Tabelle 2: Vergleich Relationstabellen und Links
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 9
saracus consulting GmbH
4.3
Satelliten
Die Satelliten entsprechen im Groben den Standardtabellen in der Ankermodellierung und
beinhalten den Kontext und Zeitbezug.
Die Satelliten bieten dem Modellierer eine gewisse Freiheit in der Gruppierung der Attribute. Gibt
es für ein Subjekt viele Attribute, können diese auf mehrere Satelliten aufgeteilt werden. Es ist
üblich, die Satelliten entweder nach Quellsystem, nach inhaltlicher Zusammengehörigkeit oder
nach Änderungshäufigkeit zu gruppieren (eine Vertragsart ändert sich ggf. seltener als der
bearbeitende Mitarbeiter des Vertrages).
Der DWH Ladezeitstempel ist Teil des Schlüssels. Nur wenn sich ein Attribut im Satellit ändert, wird
ein neuer Datensatz mit aktuellem Ladezeitstempel eingefügt.
Satelliten entsprechen
den Standardtabellen.
Satelliten können
Stammdaten zu den
Hubs enthalten oder
Informationen zu den
Links. Es kann mehrere
Satelliten pro Hub
geben.
Im Extremfall kann jedes Attribut als eigener Satellit angelegt werden (wie in der anfangs
erwähnten „Anchor“- Modellierungsmethode). Bewegungsdaten werden modelliert, in dem für
jede Bewegung eine ID generiert wird, welche in einem Hub abgelegt werden und mittels Links
verknüpft und durch Satelliten beschrieben sind.
Bezeichnung
Hauptzweck
Kardinalität
Konsolidierte Ankermodellierung
Standardtabelle
Kontext/Attribute zu einem Subjekt.
Immer mit dem Anker verknüpft.
Primärschlüssel
Künstliche ID
Fremdschlüssel
TIK der Vatertabelle und Zeitbezug
(gültig_von), ggf. bi-/tritemporal
Keine eigene künstliche ID
Es ist immer der TIK der Vatertabelle
enthalten. Es können noch weitere FK als
beschreibende Attribute eingefügt
werden (3NF).
ETL
Metadaten
In separaten Tabellen über
Ladelaufnummer ersichtlich.
Gruppierung
Alle zum Subjekt fachlich zugehörigen
Informationen werden in einer
Standardtabelle zusammengefasst (3NF).
Inhalt
Zusammengefasst
Alle Informationen zu einem Subjekt sind
in einer Tabelle zusammengefasst.
ETL
Achtung: durch das Zusammenführen
verschiedener Zeitverläufe aus
unterschiedlichen Quelltabellen können
die Ladeprozesse sehr komplex werden.
Data Vault Modellierung
Satellit
alle Inhalte/Kontext des Core DWH.
Mit dem Hub oder einem Link
verknüpft.
ID des Links oder Hubs und der DWH
Ladezeitstempel der Version.
Die technische Versionierung des DWH ist in
Form des
Ladezeitstempels
immer als Teil des
Primärschlüssels
enthalten.
Die ID der Vatertabelle (Link oder
Hub) ist einziger Fremdschlüssel. Alle
1:N Beziehungen müssen als Link
modelliert werden (bei Bedarf mit
zusätzlichem Satelliten).
Quellsystem und Lade-Timestamp
sind in jeder Datentabelle direkt
enthalten.
Der Modellierer kann Attribute zu
einem Subjekt auf verschiedene
Satelliten aufteilen: Nach Inhalt,
Quellsystem und/oder
Änderungsrate.
Granular
Auch 1:N Beziehungen zwischen Hubs
werden getrennt als Link modelliert,
nur beschreibende Attribute des
Hubs sind direkt an Satelliten
angehängt
Der Kontext von Links/Relationen ist
ebenfalls in Satelliten ausgelagert.
Durch eine Trennung der Satelliten
nach Quellsystem / Zeitverlauf
können die Ladeprozesse einfach
gehalten werden.
Tabelle 3: Vergleich Standardtabellen und Satelliten
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 10
saracus consulting GmbH
4.4
Beispiel Data Vault Modellierung
Abbildung 2: Beispiel einer Data Vault Modellierung
Im Beispiel gibt es Hubs für die Subjekte Vertrag, Sachbearbeiter und Produkt, wie bei der
konsolidierten Ankermodellierung. Die Hubs haben im Falle Vertrag und Sachbearbeiter mehrere
Satelliten, die hier nach Inhalten mit verschiedenen Zeitverläufen aufgeteilt sind.
Im Gegensatz zur konsolidierten Ankermodellierung, wo die beiden Sachbearbeiter-Rollen direkt in
der Standardtabelle als FK verlinkt waren, ist im Data Vault pro Rolle ein Link eingefügt
(Vertrag_SB_Betreuer_LINK und Vertrag_SB_Abschluss_LINK). Grundsätzlich ist es als Variante auch
zulässig, im Data Vault die verschiedenen Rollen mit einem Link und zwei rollenspezifischen
Satelliten abzubilden, oben gezeigte Variante bewährt sich jedoch besser.
Anstatt die zeitlichen Gültigkeiten der Sachbearbeiter-Vertrag Beziehungen direkt in die
Linktabellen zu integrieren, wird jeweils ein zusätzlicher Satellit an den Link gehängt, um den
Zeitbezug abzubilden (Vertrag_SB_Abschluss_SAT und Vertrag_SB_Betreuer_SAT).
Die Bewegungs- bzw. Transaktionsdaten für den Rechnungsbeleg sind ebenfalls gemäß Data Vault
Standard in einen Hub und einen Satelliten aufgeteilt, auch wenn der Rechnungsbeleg nicht mehr
geändert werden kann und keine Versionierung benötigt (PK des Hubs und PK des Satelliten
entsprechen einander 1:1). Das kann in manchen Fällen zu Performanceproblemen führen, weshalb
manchmal „Transactional Links“ eingefügt werden (Hub und Link der Transaktionsdaten in einer
Tabelle kombiniert). Das Ergebnis gleicht der konsolidierten Ankermodellierung, widerspricht aber
den Data Vault Regeln.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Die Data Vault Modellierung ergibt ein hochstandardisiertes Modell.
Es entsteht eine Vielzahl
an Tabellen, die durch
die konsequente Einhaltung der Standards
jedoch grundsätzlich
verständlich bleiben.
Achtung bei Transaktionsdaten: hier kann die
Data Vault Modellierung zu Perfomanceproblemen führen.
Seite 11
saracus consulting GmbH
4.5
Weitere Tabellentypen
Generische Tabellen: Separate generische Tabellen wie Geographie, Zeit und andere
Referenztabellen sind in beiden Modellierungsarten erlaubt.
Domänen-Entitäten im konsolidierten Ankermodell: In der konsolidierten Ankermodellierung
können noch zusätzlich die Domänen-Entitäten zugefügt werden. Diese Super-Typen der AnkerEntitäten bilden Gruppierungen der logisch ähnlichen fachlichen Objekte, z. B. Verträge,
Produkte, Partner, usw.
Zu einer Domänen-Entität (z.B. Partner-Domäne) kann es verschiedene Anker/StandardtabellenPaare geben, die jeweils eine Ausprägung des fachlichen Objekts darstellen (z.B. bei der PartnerDomäne: Kunde, Lieferant, Prospekt/Suspekt, Mitarbeiter). Die Ausprägungen können gleiche
oder unterschiedliche Strukturen haben. Zusätzlich können die Gruppierungen nach
Quellsystemen (z.B. Partner-Strukturen aus den unterschiedlichen Quellen, wie CRM,
Partnersystem, Buchhaltung, Vertriebssystem usw.) oder Release-Versionen (jedes Release bringt
neue Attribute in einem neuen Paar von Anker- und Standardtabelle) gebildet werden.
Sowohl im Data Vault
als auch bei der konsolidierten Ankermodellierung gibt es Konstrukte, welche bei speziellen
Anforderungen oder
Performanceproblemen
eingesetzt werden können.
Hybrid-Tabellen: Zur Performanceverbesserung und Reduktion der Abfragekomplexität gibt es im
Data Vault Hybrid-Tabellentypen wie Bridge- und Point In Time Tabellen. Diese ändern aber nicht
den Kern von Data Vault sondern sind als Zusatz zu sehen. Solche Hilfstabellen können aus den
Daten der Hubs, Links und Satelliten abgeleitet werden.
ETL Metadaten: Quellsystem und Lade-Timestamp sind beim Data Vault immer in den Tabellen
mit abgelegt. In der konsolidierten Ankermodellierung befindet sich in der Regel eine Job-ID und
ggf. ein Löschkennzeichnen. Weitere Informationen wie Quellsystem, Ladezeitpunkt, Ladeprozess
etc. befinden sich in separaten Metadatentabellen.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 12
saracus consulting GmbH
5
Bewertung der Data Vault Modellierung im Vergleich
zur konsolidierten Ankermodellierung
5.1
Data Vault bietet einen
noch höheren Standardisierungsgrad.
Die konsequente
Standardisierung und
das Fehlen von Business
Regeln im Modell führt
zu noch einfacherer
Automatisierung, Erweiterbarkeit und Stabilität.
Vorteile der Data Vault Modellierung
Alle allgemeinen Vorteile der Ankermodellierung treffen auch für die Data Vault Modellierung zu,
oft sogar noch in verstärkter Form.

Erweiterbarkeit: wie bei der Ankermodellierung können neue Bereiche einfach ergänzt
werden, ohne bereits bestehende Bereiche zu beeinflussen. Selbst Erweiterungen um Attribute
bei bestehenden Subjekten können einfach durch das Anhängen von neuen Satellitentabellen
behandelt werden, was eine Anpassung und einen Regressionstest der bestehenden Tabellen
überflüssig macht. Data Vault eignet sich daher besonders gut für eine Agile
Projektvorgehensweise.
Hier bietet der Data Vault einen Vorteil, da in der konsolidierten Ankermodellierung in diesem
Fall die entsprechende Standardtabelle erweitert würde. Alternativ kann in der konsolidierten
Ankermodellierung dem Problem mit der Einführung des Entitätsdomänen-Konzeptes begegnet
werden, das im Grundsatz wieder die gleiche Funktionalität wie der Data Vault bietet.

Stabilität: Dadurch, dass die Links „wertungsfrei“ von vorne herein strukturell immer N:MBeziehungen abbilden können, braucht die Link-Tabelle nicht geändert werden, wenn sich die
Kardinalität ändert. Zum Beispiel: Heute gilt die Regel „Ein Kunde kann genau ein
Sachbearbeiter haben“ (1:N). Irgendwann wird die Business-Regel geändert: „Ein Kunden kann
von mehreren Sachbearbeitern gleichzeitig betreut werden“ (N:M). Das führt in der
Ankermodellierung zu einer Anpassung in der Datenbewirtschaftung mit oft nicht
unbedeutendem Aufwand.

Auditfähigkeit: Dadurch, dass keine Business Regeln umgesetzt werden und konsequent der
Ladezeitstempel abgelegt ist, ist die Rückverfolgbarkeit der Daten gewährleistet.

Einfachheit: ist das Modellierungskonzept einmal verstanden, kann das Konzept mit den
vorgegebenen Standards theoretisch einfach und konsistent über das gesamte Core DWH (Raw
Data Vault) angewendet werden. Entscheidungen über die Modellierung können im Data Vault
eindeutiger getroffen werden als in der Ankermodellierung, wo der Einfluss des Modellierers
grösser ist. Auch wenn das Modell durch die große Tabellenanzahl komplex wirkt, kann es durch
die Standards mit entsprechendem Aufwand nachvollzogen werden.
Durch die Aufteilung der Satelliten im Data Vault nach Änderungshäufigkeit kann die
Datenmenge und Redundanz noch weiter reduziert werden. Bei der konsolidierten
Ankermodellierung wird eher nach fachlichem Inhalt in den Standardtabellen gruppiert als nach
Änderungshäufigkeit.

www.saracus.com
Standardisierte ETL-Prozesse: Die ETL-Prozesse im Data Vault können hochgradig standardisiert
werden, insbesondere bei Links und Hubs. Dadurch kann ein sehr hoher Automatisierungsgrad
erreicht werden. Auch in der konsolidierten Ankermodellierung sind in vielen Fällen
standardisierte ETL-Prozesse möglich, jedoch können in gewissen Fällen die ETL Prozesse für
Relationstabellen und Standardtabellen komplex werden (z.B. Zusammenführen mehrerer
Quelltabellen mit unterschiedlicher Versionierung).
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 13
saracus consulting GmbH
5.2

Nachteile der Data Vault Modellierung
Unbedingte Einhaltung der Standards: Es ist wichtig, dass die Regeln für die Modellierung
verstanden und unbedingt eingehalten werden. Bei jedem Regelverstoß werden die
gewonnenen Vorteile sofort gefährdet.
In manchen Fällen sind die vorgegebenen Standards für die Modellierung nicht intuitiv, z.B. bei
transaktionalen Daten wie Finanzdaten, oder es werden „Abkürzungen“ modelliert. In der
Praxis werden deshalb oft Ausnahmen von den Regeln gemacht. Es besteht die große Gefahr,
dass sobald Ausnahmen zugelassen werden, der Ansatz immer mehr verwässert wird. Im
schlimmsten Fall gehen die Vorteile verloren, die Nachteile bleiben und das Datenmodell ist
nicht mehr handhabbar.

Die Umsetzung erfordert viel Erfahrung: Auch bei der Data Vault Modellierung gibt es in Bezug
auf die Gesamtarchitektur und die Implementierung verschiedene Varianten, die optimal
umgesetzt werden müssen.
Viele Data Vault Projekte scheitern beim ersten Versuch, weil Erfahrungswerte fehlen und/oder
die Prinzipien nicht konsequent eingehalten werden.

Unübersichtliche Anzahl von Tabellen: Es wird eine sehr grosse Anzahl an Tabellen generiert,
die das Modell schnell unübersichtlich und sehr komplex macht.

Abfragekomplexität und -Performance: Viele Tabellen bedeuten viele Joins, was sich auf die
Abfragekomplexität und natürlich auch die Abfrageperformance auswirkt und ggf. weitere
Hilfskonstrukte zur Vereinfachung und Performanceoptimierung notwendig macht.

Lesbarkeit: Das neutrale Design der Links hat zum Nachteil, dass man den Business-Kontext
nicht mehr aus dem Modell „ablesen“ kann und damit die Zusammenhänge nicht mehr
automatisch ersichtlich sind. Es muss eine andere Form gefunden werden, um die BusinessLogik zu dokumentieren.

Endbenutzerzugriff: Ein Zugriff für Endbenutzer (PowerUser) auf das Core DWH Modell für
Auswertungszwecke ist bei Data Vault noch anspruchsvoller wie bei der Ankermodellierung. In
der Regel können Business-User den schwer lesbaren und komplex abzufragenden Raw Data
Vault nicht für AdHoc Auswertungen nutzen.

Physische Umsetzung im DBMS: Besondere Achtsamkeit muss der physischen
Implementierung auf Datenbankebene entgegen gebracht werden. Ist die Datenbank nicht
optimal aufgesetzt, kann die benötigte Parallelisierung und Ladereihenfolge bei der Befüllung
der Tabellen nicht gewährleistet werden und es entstehen schwerwiegende
Performanceprobleme beim Load.
Es ist wichtig, dass die
Standards im Data Vault
konsequent eingehalten
werden, da sonst die
Vorteile gefährdet sind.
Obwohl die Standards
in der Theorie klar definiert sind, ist es in der
Praxis oft nicht einfach,
diese richtig umzusetzen.
Viele Data Vault Projekte scheitern beim ersten
Versuch, weil die Erfahrungswerte fehlen.
Achtung:
Diese Nachteile stellen ein Data Vault Projekt vor viele Herausforderungen und bringen nicht
selten ein Projekt zum Scheitern. Was in der Theorie die Lösung aller Probleme verspricht, ist in
der Praxis oft nicht handhabbar.
Es ist wichtig, sich im Vorfeld genau mit den Chancen und Risiken auseinander zu setzen. Nach
der Auswahl der passenden Architekturvariante und Modellierungsmethode muss möglichen
Problemen aktiv durch solide Konzepte vorgebeugt werden.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 14
saracus consulting GmbH
6 Konzeptioneller Vergleich von Data Vault und konsolidierter
Ankermodellierung
Neben den eher kleineren Unterschieden in
der Modellierung ist
der Hauptunterschied
in dem Grad der Datenintegration in der Core
DWH Schicht zu finden.
Dieser konzeptionelle
Unterschied führt zu
unterschiedlichen
Sichtweisen auf das
Projekt, die Architektur
und das Verständnis
des DWHs.
Neben den oben beschriebenen Unterschieden im Modellierungsansatz der konsolidierten
Ankermodellierung bzw. Data Vault gibt es noch ein grundsätzliches konzeptionelles
Hauptunterscheidungsmerkmal:
Beim Data Vault findet keine Konsolidierung im Core Data Warehouse statt. Alle Daten werden
„roh“ und inhaltlich unverändert aus allen relevanten Datenquellen in diese „Raw Data
Vault“ Schicht geladen.
Bei der konsolidierten Ankermodellierung wird im Gegensatz dazu eine integrierte Sicht erzeugt
nach dem Grundprinzip der „Single Source of Truth“.
Dieser fundamentale Unterschied in der Philosophie hat Auswirkungen auf das gesamte DWH
Projekt, die Architektur und das Verständnis, wie das DWH in einem Unternehmen wahrgenommen
wird und welche Aufgaben und Ziele man für das DWH System definiert.
In den folgenden Abschnitten werden die beiden Philosophien mit einer jeweils typischen
Referenzarchitektur analysiert und deren Vor- und Nachteile beleuchtet.
6.1
Konsolidierte Ankermodellierung: Core DWH als “Single
Source of Truth”
Die konsolidierte Ankermodellierung sieht
das Core DWH als „Single Source of Truth“.
Die Anker-Modellierung unterstützt das Grundprinzip der „Single Source of Truth“. Das bedeutet,
dass Daten verschiedener Quellsysteme in ein konsolidiertes Core DWH zusammen gefügt werden.
Im CDW werden Data Cleansing, Klassifizierungen, Fehlermanagement, Kategorisierungen und
andere allgemeingültige Businesslogik umgesetzt.
Bei konkurrierenden Daten aus mehreren Quellsystemen wird mit Regeln im ETL Prozess
entschieden, welche Daten führend sind. Gibt es mehrere Business Keys, die dasselbe aussagen,
werden sie mittels eines Regelwerks priorisiert und zu einem einzigen konsolidierten Datensatz
verschmolzen.
Das Ziel ist es, Daten verschiedener Systeme zu integrieren und in auswertbare Informationen
zu transformieren.
Es wird eine qualitätsgesicherte, verständliche Datenbasis bereitgestellt, die von allen Data
Marts konsistent verwendet werden kann, ohne dass Regeln mehrfach an verschiedenen Stellen
implementiert werden müssen.
Folgende konzeptionelle Grundlagen gelten in einem konsolidierten Core DWH:

Integration der Daten aus unterschiedlichen Quellsystemen: Zusammenführen von Datensätzen
mit verschiedenen fachlichen Schlüsseln zu einer fachlichen Einheit (Master Data Management)

Vereinheitlichung der Formate der in verschiedenen (operativen) Quellsystemen unterschiedlich
strukturierten Daten (z.B. Decodierung, Standardisierung, Cleansing, Matching)

Fachliche Beziehungen: Die Modellierung der Relationen spiegelt die fachliche Zuordnung der
Subjekte zueinander wider (wie im Kapitel 2.3 erwähnt).

Umsetzen der
Klassifizierung
www.saracus.com
unternehmensweiten
Business-Regeln:
Kategorisierung,
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Subtypisierung,
Seite 15
saracus consulting GmbH
 Minimalistischer Ansatz: es wird häufig nur modelliert und ins Core DWH geladen, was
gebraucht wird. Das heisst, Historisierung und Versionierung werden nur in der
Komplexitätsstufe implementiert, wie das für die Auswertungen gefordert ist. Das reduziert die
Komplexität für die ETL-Prozesse und Abfragelogik

AdHoc Zugriff für PowerUser: analytische PowerUser sind meist in der Lage, auf dem Core
Data Warehouse mittels SQL-Zugriff eigene AdHoc-Analysen zu erstellen

Anwendungsneutralität: Die Datenmodellierung hat zum Ziel das Business abzubilden und ist
daher (theoretisch) anwendugsneutral. Wird das Quellsystem ausgetauscht, muss das Core
DWH Modell nicht neu designt werden. In der Praxis ändert sich z.B. durch die Umstellung auf
andere operative Systeme allerding oft auch der Business-Prozess, was wiederum eine
Anpassung im Core DWH notwendig machen kann.

Fehlermanagement
und
Datenqualität:
Abfangen
von
ungültigen
Werten,
Datenqualitätsmanagement und Data Cleansing. Auch wenn Datenqualitätsprobleme im
Idealfall im Quellsystem behoben werden sollten, ist die Datenqualität grundsätzlich ein
Aufgabengebiet des DWH
6.2
Nachteile eines konsolidierten Core DWH
Dieser Ansatz bietet isoliert betrachtet generell einige gravierende Nachteile, denen aber in der
Praxis mit einer geeigneten Architektur begegnet werden kann (wie in Abschnitt 6.3 beschrieben):
(1) Auditfähigkeit: werden Daten durch den ETL Prozess z.B. beim Cleansing modifiziert und in
geänderter Form gespeichert, ist es im CDW nicht mehr möglich, die Rohdaten exakt zu
rekonstruieren. Mit dem CDW allein ist eine Auditfähigkeit nicht gegeben
(2) Datenhistorie und Versionierung: da man sich an den Business-Anforderungen orientiert, ist in
vielen Fällen nicht die maximale Auswertungskapazität im Core Data Warehouse abgebildet.
Wird z.B. eine bitemporale Versionierung aus Business Sicht nicht benötigt, wird diese auch
nicht im CDW abgebildet. Wird diese für Spezialabfragen oder Audits benötigt, kann die
Änderungshistorie aus dem CDW nicht mehr rekonstruiert werden.
(3) Komplexität der ETL-Prozesse: mit den verschiedenen Tabellentypen können zwar die ETLProzesse im Grundmuster standardisiert werden, müssen aber individuell definiert und
angepasst werden (Schlüsselmanagement, Business Logik, Datenqualitätsmassnahmen,
Fehlerbehandlung). Eine Automatisierung vieler Aspekte ist möglich, aber ein gewisses
„Mitdenken“ des Entwicklers ist notwendig.
Isoliert auf die Core
DWH Schicht betrachtet bietet der konsolidierte Ansatz einige
Schwächen, die mit
einer geeigneten Gesamtarchitektur ausgeglichen werden können.
(4) Definition von unternehmensweiten Business Rules: der Aufwand zur Definition von
einheitlichen Kennzahlen und Unternehmensregeln wird in der Praxis fast immer unterschätzt.
Vor der Entwicklung eines konsolidierten CDW ist eine gute Business Analyse notwendig.
Dieser Aufwand fällt früh im Projekt an und die „Time-To-Market“ der CDW-Schicht ist somit
relativ lange.
(5) Auswertungsflexibilität: die „Wahrheit“ kann für unterschiedliche Empfänger eine andere sein.
Die Abbildung von verschiedenen Ansichten und Definitionen im Data Mart sind oft komplex in
der Definition und Handhabung und können zusätzlichen Aufwand verursachen.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 16
saracus consulting GmbH
Eine quellsystemnahe
Datenhaltungsschicht
erfüllt auf sehr einfache Art die Anforderungen an Auditfähigkeit, Datenhistorie
und vollständige
Versionierung.
(6) Änderungen von Business Rules: „Die einzige Konstante ist der Wandel“. Durch Änderungen des
Business oder des Quellsystems müssen diese Änderungen im CDW und/oder im Data Mart
nachgezogen werden.
6.3
Antworten auf die Nachteile
(1) (2) Auditfähigkeit, Datenhistorie und Versionierung:
Es bewährt sich, in der Praxis eine quellsystemnahe Datenhaltungsschicht einzuführen, welche
die komplette Datenhistorie vorhält. In dieser Schicht werden die Quelltabellen strukturell 1:1
übernommen und mit der technischen Versionierung (Ladezeitstempel) angereichert. Die ETL
Prozesse dafür können hochgradig standardisiert und automatisiert werden und es wird kein
Modellierungsaufwand benötigt (da 1:1 zur Quelltabelle).
Mit dieser Datenhaltungsschicht lässt sich das Problem der Auditfähigkeit und der fehlenden
Historie des Core DWH lösen, da der Zustand der Quelldaten immer historisch korrekt
nachvollzogen werden kann. Ändern sich die Anforderungen für das Core DWH dahingehend,
dass z.B. eine Änderungshistorie nachträglich eingebaut werden muss, stehen die Daten zur
Verfügung und können „nachgerüstet“ werden.
(3) Komplexität der ETL-Prozesse:
Der Komplexität der ETL-Prozesse und dem damit höheren Entwicklungsaufwand kann durch ein
durchdachtes ETL-Konzept entgegengewirkt werden. Standardisierung, Metadatensteuerung, ein
hoher Automatisierungsgrad und ein einheitliches Fehlermanagement helfen ETL Prozesse
einfach und schnell zu entwickeln und zu warten.
(4) Definition von unternehmensweiten Business Rules:
Es gilt, frühzeitig im Projekt die Business Analyse durchzuführen. Der Aufwand lässt sich nicht
umgehen, ist aber gut investiert - spätestens beim Design der Data Marts wird dieses tiefere
fachliche Verständnis benötigt. Je früher und besser das Business in der Tiefe verstanden wird,
desto zielgerichteter und effektiver kann das DWH aufgesetzt werden. Im Gesamtkontext gesehen
spart eine solide Analyse und Konzeption in einer frühen Projektphase immer Aufwand bei der
späteren Realisierung.
Zudem ist es in vielen DWH Projekten ein wichtiges Ziel, Definitionen und Kennzahlen zu
vereinheitlichen. Die Diskussion von verschiedenen Fachabteilungen ist oft nicht einfach und
zeitintensiv, kann aber im Zuge eines DWH Projektes von erfahrenen Beratern unterstützt und
moderiert werden.
(5) Auswertungsflexibilität:
Wie bei den Business Rules müssen unterschiedliche Analysebedürfnisse und (begründet)
unterschiedliche Sichten und Definitionen frühzeitig im Projekt erkannt werden. Das Design des
konsolidierten CDWs wird daraufhin so angepasst, dass sich alle regulären
Auswertungsbedürfnisse erfüllen lassen. Auswertungsoptimierte Data Mart bedienen
verschiedene Sichten. Spezialauswertungen sind bei Bedarf auch auf der quellsystemnahen
Datenhaltungsschicht möglich, die über die volle Datenbreite und Datenhistorie verfügen.
(6) Änderungen von Business Rules:
Treten Erweiterungen oder fachliche Änderungen auf, ist es mit einem guten
Änderungsmanagement und erweiterbarem Design in den Data Marts oft möglich, auf fachliche
Änderungen relativ schnell zu reagieren.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 17
saracus consulting GmbH
Öfter als eine Änderung des Business ändert sich jedoch ein Quellsystem. Dadurch, dass das Core
DWH (theoretisch) anwendungsneutral modelliert ist, muss zwar ein neuer ETL Prozess hinzugefügt
werden, um die neuen Quelldaten ins Core DWH zu laden. Die Prozesse in den Data Marts müssen
jedoch nicht angepasst werden.
Eine Architektur mit
konsolidiertem Core
DWH und quellsystemnaher Datenhaltungsschicht erfüllt in
der Praxis die Anforderungen oft am besten.
Abbildung 3: einfache Referenzarchitektur mit konsolidiertem Core DWH und quellsystemnaher
Datenhistorisierungsschicht
6.4 Data Vault: neutrale Datendrehscheibe als “Single Version of
Facts”
Der Data Vault ist eine
neutrale Datendrehscheibe ohne Business
Rules.
Der Data Vault im Core Data Warehouse hat konzeptionell nicht das Ziel, eine “Single Version of
Truth” bereitzustellen, sondern versteht sich als ein großer Datenspeicher für die
Unternehmensdaten, aus dem jede benötigte Wahrheit erzeugt werden kann (in der Data Mart
Schicht). Beim Data Vault liegt der Fokus klar auf Auditfähigkeit, Standardisierung von Struktur und
Ladeprozessen, einfache Erweiterbarkeit und Zukunftssicherheit.
Die Verantwortlichkeit nach den fachlichen Regeln, Datenqualitätsmanagement und Konsolidierung
wird aus der Core DWH Schicht ausgelagert und in den Data Mart Layer geschoben. Neben der
Auswertungsschicht (Data Access Layer), der die Data Marts enthält, wird oft noch eine
Zwischenschicht, ein „Business Data Vault“ eingezogen, der einige Konsolidierungsfunktionen
übernimmt.
Der Ansatz „Single Source of Truth“ wird also durch den Raw Vault nicht erfüllt, da an dieser
Stelle noch gar nicht definiert ist, was die „Wahrheit“ aus Business-Sicht ist.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 18
saracus consulting GmbH
Zu den Begrifflichkeiten:
Die Verwendung der
Begriffe in der Data
Vault Architektur werden nicht einheitlich
verwendet und es
existieren in der Data
Vault Community unterschiedliche Ansichten, was genau mit
welchem Begriff gemeint ist.
Auch wenn der oben genannte Grundsatz sicher für Data Vault gilt, gibt es innerhalb der Data Vault
Community dennoch verschiedene Ansichten über die Feinheiten, was ein Data Vault genau
beinhaltet und wie die Umsetzung im Detail aussieht. Auch ist eine genaue Abgrenzung der Begriffe
oft schwierig. Die Varianten reichen von einem „Raw Data Vault“ oder „Source Data Vault“, der ohne
Integration die Daten der Quellsysteme in die Data Vault Modellierung bringt (quellsystemtechnische
Schlüssel werden in den Hubs verwendet) – bis hin zu einem Data Vault, der bereits eine Integration
über die Business Keys beinhaltet und somit bereits einen wichtigen Teil der Business Logik umsetzt.
Dan Linstedt gibt im
Data Vault 1.0 lediglich
die Modellierungsmethode vor. In der
Praxis herrscht große
Uneinigkeit über die
Feinheiten und die
Umsetzung im Gesamtkontext. Es bleibt
abzuwarten, ob sich
dies mit der Verbreitung von Data Vault 2.0
verbessert.
Der Begriff „Data Vault“, wie er im White Paper verwendet wird, meint eine Core-Schicht, welche die
klassischen Data Vault Regeln der Modellierung (Data Vault 1.0) umsetzt mit einer leichten
Integration oder als Raw Data Vault.
Vergleicht man lediglich die Core DWH
Schichten, zeigt der
Data Vault viele Stärken.

Das (Roh-)Datenmanagement mit den Aspekten von Schlüsselverwaltung, Historisierung, Datenbereitstellung ist getrennt von der Umsetzung der fachlichen Logik und der Interpretation der
Daten.

Daten verschiedener Quellsysteme werden in eine gemeinsame Struktur überführt und
komplexe Aufgaben wie Historisierung sind bereits gelöst. Aufbauend auf dieser Struktur ist es
einfacher, die Business Logik umzusetzen.

Im Idealfall wird durch die Integration auf Basis der Business Keys und durch sinnvolle Definition
der Hubs die Granularität der Daten sinnvoll gesetzt und die späteren Auswertungen vorbereitet.

Fachliche Regeln können in der Auswertungsschicht angepasst werden, ohne das
Datenfundament im Data Vault zu berühren.

Änderungen und Erweiterungen können relativ einfach in den Data Vault eingefügt werden.

Volle Flexibilität bei der Definition der „Wahrheit“ für die Data Marts. Die Daten können
weiterhin auf verschiedene Weise interpretiert werden.

Die Auditfähigkeit wird maximiert und eine Rückverfolgbarkeit der Daten ist möglich.

Die ETL-Prozesse lassen sich hochgradig standardisieren. Aus
Automatisierungsgrad
folgt
ein
geringerer
Entwicklungsaufwand
Fehlerwahrscheinlichkeit.

Durch die schnelle, automatisierte Umsetzung sind die initialen Investitionskosten gering

Hohe Ladegeschwindigkeit durch großes Parallelisierungspotential der ETL-Prozesse.
In Betrachtung der
Gesamtarchitektur
werden diese wieder
relativiert.
Darüber hinaus gibt es verschiedene optionale Zwischenschichten wie ein „Business Data Vault“,
„EDW+“ oder „Staging Out“, die alle auf die ein- oder andere Weise zur Aufgabe haben, die Kluft
zwischen der technischen und semantischen Sicht zu überbrücken.
Das White Paper soll nicht auf die Feinheiten einer Data Vault Architektur eingehen, sondern die
wichtigen Punkte mit einer typischen Architektur veranschaulichen.
Wird von „Business Data Vault“ gesprochen, ist im White Paper eine Zwischenschicht gemeint,
welche als Hilfskonstrukt und Vorstufe für die Data Marts bereits einige der allgemeine Business
Regeln umgesetzt hat aus Gründen der Performance, Übersichtlichkeit und Wiederverwendbarkeit.
Mit Data Marts ist eine Auswertungsschicht gemeint, diese kann technisch verschiedenartig sein
(relationale Star-Schema-Marts, Service Marts, FlatFiles, Cubes, OLAP, virtuellen Marts (Views)).
6.5
Vorteile des Data Vault im Vergleich zum konsolidierten CDW
Vergleicht man isoliert betrachtet die CDW Schichten einer konsolidierten Ankermodellierung mit
einem Data Vault, bietet das Konzept der „neutralen Datendrehscheibe“ folgende Vorteile:
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
einem hohen
und
geringe
Seite 19
saracus consulting GmbH

Near Real Time Verarbeitung: In einer Near Real Time Umgebung können Änderungen aus den
Quellsystemen direkt in den Data Vault weitergeschrieben werden. Sofern Staging Area und
Data Marts virtualisiert sind (Views), werden neue Daten nahezu sofort nutzbar.
6.6
Data Vault im Gesamtkontext einer typischen Architektur
Auch wenn der (Raw-) Data Vault Themen wie Konsolidierung, Data Cleansing, Matching, Master
Data Management (Selektion der führenden Daten bei mehreren Quellen) und
Datenqualitätsmassnahmen weitgehend ausklammert, müssen sie dennoch erfüllt werden, um
sinnvolle und konsistente Auswertungen zu liefern.
Diese Anforderungen werden entweder direkt in den Data Marts umgesetzt, oder in einer
optionalen zusätzlichen Business Vault Schicht (oder ähnliches, z.B. EDW+, Staging Out). Der
Business Data Vault ist eine separate Komponente mit einem eigenen Modell und ergänzt den
eigentlichen Data Vault. Dort werden allgemeingültige Business Regeln, Schlüsselzuordnungen und
Konsolidierungen umgesetzt (und entspricht dann inhaltlich in etwa dem Core DWH mit
konsolidierter Ankermodellierung).
Business Regeln
werden entweder
direkt in den Data
Marts umgesetzt oder
in einer zusätzlichen
Business Vault Schicht.
Der Data Vault wie im
Schema gezeigt wird
auch oft als „Raw
Vault“ bezeichnet.
Das Enterprise Data
Warehouse besteht
hier aus den Schichten
(Raw-) Data Vault und
der Business Vault.
Abbildung 4: typische Architektur eines Data Vault mit Business Data Vault
Die Zusammenführung der Business Keys zu einer fachlichen Einheit kann über Link-Tabellen gelöst
werden, was aber auch ein Bestandteil der Business Data Vault Schicht ist.
Data Marts sind nicht unbedingt persistent und werden oft nur als Views realisiert. Nur wenn die
Performance nicht ausreicht, werden die Data Mart Tabellen physisch angelegt.
Die Modellierung der Data Marts (auch „Information Marts“ genannt) erfolgt wie beim
konsolidierten Core DWH ausgerichtet auf die Abfrageoptimierung mit den Zielen Einfachheit und
Performance. Konzepte zur Data Mart Modellierung werden in einem folgenden White Paper
erläutert.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 20
saracus consulting GmbH
6.7
Bewertung von Data Vault in der Gesamtarchitektur
Quellsystemnahe Schicht vs. (Raw) Data Vault
Vergleicht man die Gesamtarchitektur der beiden Konzepte, ist ein zentraler gemeinsamer Punkt,
dass in beiden Architekturen eine Schicht existiert, um die komplette Datenhaltung und Datenhistorie
zu gewährleisten.
Im konsolidierten Core DWH ist das die quellsystemnahe Schicht mit historisierten Tabellen, bei der
Data Vault Architektur ist es der Data Vault selbst.
Eine quellsystemnahe
Schicht bietet dieselben Vorteile wie ein
Data Vault in Hinblick
auf Historisierung,
Versionierung und
Auditfähigkeit, ist aber
einfacher und mit
deutlich weniger Aufwand aufzubauen.
Die Umsetzung der
Business Regeln ist in
jeder ModellierungsVariante mit beträchtlichem Aufwand verbunden, sei es in einem
konsolidierten Core
DWH oder in einem
Business Vault.
In vielen Data Warehouse Projekten ist
es ein wichtiges Ziel,
Definitionen zu vereinheitlichen und Daten
unternehmensweit
konsistent zu verwenden.
Eine quellsystemnahe Schicht mit Historisierung kann die Anforderungen einer kompletten
Datenhistorie und Auditfähigkeit jedoch mit wesentlich geringerem Entwicklungs- und
Wartungsaufwand erfüllen wie ein Data Vault Modell. Eine einfache 1:1 Kopie der Quelltabellen steht
dem umfangreiche Data Vault Modell gegenüber. Modellierungs-, ETL- und Wartungsaufwand sind
beim Data Vault in diesem Vergleich wesentlich höher, obwohl Data Vault in Bezug auf Datenhistorie
und Auditfähigkeit keinen Mehrwert bietet.
Konsolidiertes CDW mit Ankermodellierung vs. Business Data Vault
In beiden Architekturen existiert ein Modell, in dem die Business Regeln umgesetzt werden. In der
konsolidierten Ankermodellierung passiert ein wichtiger Teil davon schon im Core DWH durch die
Definition von „sprechenden“ Relationen sowie Matching, Cleansing und Kategorisierung.
Bei der Data Vault Architektur werden diese Aufgaben in den Data Mart ausgelagert, müssen dort
jedoch in gleichem Masse umgesetzt werden. Werden die Data Marts direkt aus dem Data Vault
bewirtschaftet und brauchen dieselbe Business Logik, wird das Regelwerk an verschiedenen Stellen
mehrfach umgesetzt und birgt dadurch Risiken bei der Wartung. Alternativ wird ein zusätzliches
Zwischenkonstrukt wie ein Business Data Vault eingeführt. Das wiederum verursacht oft mehr
Aufwand, als eine konsolidierte Sicht einmalig im Core DWH umzusetzen.
Komplexität im Core DWH vs. Komplexität in der Auswertungsschicht: Sind im Data Vault die ETL
Prozesse zwar einfach, so steigt die Komplexität des ETL in den Data Mart bzw. in den
Zwischenschichten. Die Komplexität der Konsolidierung und Business Rules kann nicht umgangen
werden.
Near-Real-Time: die Data Vault Architektur ist für Near-Real-Time Anforderungen sehr gut geeignet,
wenn Staging Area und Data Marts virtualisiert werden können. Oft wird das durch die
Abfrageperformance für die Data Marts verhindert.
Außerdem lassen sich Near-Real-Time Bedürfnisse auch in anderen Architekturen gut hinzufügen.
Parallel zum konsolidierten CDW kann ein nicht-konsolidierter Teilbereich aufgebaut werden, der
speziell die Near-Real-Time Anforderungen bedient.
Single Version of Truth vs. Single Version of Facts
Es muss hinterfragt werden, wie viel der Vorteil der unbegrenzten Auswerteflexibilität im Data Vault
wiegt im Vergleich zu einer abgestimmten Datenbasis. In den meisten Unternehmen werden grosse
Anstrengungen unternommen, um Business-Definitionen zu vereinheitlichen. In der Praxis ist es in
den meisten Data Warehouse Projekten ein ausdrückliches Ziel, Definitionen und Daten im gesamten
Unternehmen zu vereinheitlichen und konsistent zu verwenden. Alle Auswertungen sollen auf
dieselbe qualitätsgeprüfte Datenbasis zugreifen und unterschiedliche Kennzahlendefinitionen sind
unerwünscht.
Ist es für Datenanalyse oder AdHoc Auswertungen notwendig, andere Datensichten einzunehmen,
die von der konsolidierten Sicht im Core DWH abweichen, ist es immer noch möglich auf die
quellsystemnahe Schicht zuzugreifen (mit entsprechendem Aufwand).
Sicher ist es ein Vorteil, wenn mit einem Data Vault schnell Ergebnisse erzielt werden und eine
Datenbasis unkompliziert bereitgestellt werden kann. Im Projekt darf das aber nicht als Vorwand
genommen werden, den aufwändigen, aber für das Endresultat unbedingt wichtigen Prozess einer
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Seite 21
saracus consulting GmbH
fachlichen Anforderungsanalyse zu umgehen.
7
Fazit
Auch wenn die Modellierungsmethode von Data Vault nicht revolutionär ist und anderen ERMVarianten mit Ankertabellen ähnelt, ist es gelungen, einen intelligenten und schlüssigen
Modellierungsstandard für ein unternehmensweites DWH zu definieren, der viele Stärken hat.
Der elegante Modellierungsstandard von Data Vault ist verknüpft mit einer Philosophie, welche
das DWH als Datendrehscheibe versteht und den Fokus klar auf diese wichtigen Aspekte setzt:
komplette Datenhistorie, Auditfähigkeit, Geringer Wartungsaufwand, Konformität durch
Integration der Business Keys, Geringer Entwicklungsaufwand durch Automatisation.
Zugunsten dieser Kriterien wird die Business Logik in die Data Mart Schicht (oder Business Vault)
verlagert. Für die meisten formalen Probleme der Datenmodellierung bieten beide vorgestellten
Konzepte Lösungsmöglichkeiten. Dennoch bleiben methodenspezifische Herausforderungen
bestehen, die den Projekterfolg gefährden können.
Der entscheidende Unterschied ist im konzeptionellen Selbstverständnis und Einsatzzweck der
Methoden zu sehen. Ein konsolidiertes Ankermodell entspricht konzeptionell eher einer Business
Vault Schicht. Wird also die Gesamtarchitektur betrachtet, bietet der Data Vault keinen klaren
Mehrwert mehr gegenüber einer Architektur mit konsolidiertem Core DWH inkl.
quellsystemnaher Schicht:
Auf Ebene der Datenhaltung steht auf der einen Seite eine einfache, historisierte 1:1 Kopie des
Quellsystems einem umfangreichen (Raw-)Data Vault Modell gegenüber, das letztendlich
„nur“ die Rolle einer Datendrehscheibe erfüllen kann, und das mit einem hohem
Realisierungsaufwand und nicht unerheblichen Risiken.
Die konkrete Umsetzung und physische Konfiguration ist bei beiden Ansätzen mit
Herausforderungen verbunden und bedarf Erfahrung.
Data Vault Modellierung ist eine elegante
und gut strukturierte
Art der Datenhaltung.
Die Modellierung löst
jedoch nicht die
Herausforderung, die
Business Regeln
umzusetzen.
Die konsolidierte Ankermodellierung hat sich bereits vielfach in erfolgreichen DWH-Projekten
bewährt und wird wohl auch weiterhin in vielen Fällen der präferierte und praxistaugliche Ansatz
bleiben.
Data Vault und andere Modellierungsansätze haben mit den jeweiligen Vor- und Nachteilen ihre
Berechtigung und können je nach Anforderungen und Rahmenbedingungen eine optimale Lösung
darstellen. Letztendlich muss die gewählte Methode konsequent und kompetent angewendet
werden, um die Vorteile zu realisieren und ein langlebiges, erfolgreiches DWH zu bauen.
Sicher sind die Auswahl der Modellierungsmethode und auch der Technologien wichtige
Entscheidungen in einem DWH/BI Projekt, garantieren aber allein noch keinen Erfolg und werden
oft überbewertet. Der Erfolg hängt viel mehr an Faktoren wie einer durchdachten Konzeption,
solider Architektur, guten Standards, Projektmanagement und Vorgehensmethodik.
Entscheidend sind letztendlich die Menschen, die am Aufbau eines DWH beteiligt sind: die
Unterstützung durch das Management und durch den Fachbereich, und natürlich ein
kompetentes, erfahrenes DWH/BI Team mit guter Projektleitung.
www.saracus.com
Core DWH Modellierung: Vergleich Data Vault und konsolidierte Ankermodellierung
Bezogen auf eine Gesamtarchitektur bietet
die konsolidierte Ankermodellierung mit
quellsystemnaher
Schicht dieselben Vorteile mit weniger Aufwand in der Datenhaltungsschicht.
Seite 22

Download Report