»The key, the whole key, and nothing but the key. So help me Codd!« (»Der Schlüssel, der ganze Schlüssel und nichts als der Schlüssel. So wahr mir Codd helfe!«)
Eine kleine Historie zu Data Vault
In den 1960er Jahren hat Edgar F. Codd das relationale Modell entwickelt, das zur Grundlage für relationale Datenbanken wurde. Die Normalisierung von Datenmodellen ist ein Aspekt des relationalen Modells und führte unter anderem zu Normalformen (NF), wie z.B. 1NF, 2NF, 3NF, 4NF, 5NF, 6NF und der Boyce-Codd-Normalform (BCNF), die sich zwischen der 3NF und 4NF einordnet. Die 3NF wird bis heute erfolgreich in operativen Systemen für das On-Line Transaction Processing (OLTP) verwendet.
In den frühen 1980er wurde durch Bill Inmon die 3NF den wachsenden Ansprüchen an das Data Warehousing angepasst und von diesem adaptiert. Dafür hat sich der Primärschlüssel jeder Tabelle um einen Datum-Zeit-Stempel erweitert, um die Historisierung der Daten im Data Warehouse zu ermöglichen. Mitte der 1980er führte Ralph Kimball die dimensionale Modellierung mit seinem typischen Star-Schema ein und perfektionierte diese. Sie wurde entwickelt, um fachspezifische Probleme und Fragestellungen zu lösen (dazu gehören unter anderem Aggregationen, Abfrageperformance, wiederverwendbare Informationen sowie die einfache Handhabung der Daten) und um On-Line Analytical Processing (OLAP) zu unterstützen. In der Folgezeit erweiterte sich die dimensionale Modellierung, um multifachspezifischen Fragestellungen eines Enterprise Data Warehouse Rechnung zu tragen.
Leistung und Effizienz sowie andere Schwächen der 3NF und des Star Schema als Core eines Enterprise Data Warehouse zeigten sich Ende der 1990er als die Datenvolumen anwuchsen. Dan Linstedt entwickelte zu dieser Zeit die ersten Ideen für Data Vault, um die Mängel und Schwächen auszubügeln, aber trotzdem die Stärken der 3NF und Star Schema Architekturen zu erhalten.
Um die Jahrtausendwende veröffentliche Dan Linstedt die Technik der Data Vault Modellierung. In den Jahren davor und bis heute wurde Data Vault positiv von Experten aufgenommen. Es zeigt sich immer mehr, dass Data Vault und die Anchor Style Familie die nächste Stufe der Evolution für Data Warehousing ist, denn es wurde ausschließlich dafür entwickelt.
Business Nutzen von Data Vault
Ich werde immer wieder gefragt: Was ist der Business-Nutzen von Data Vault? Warum soll ich mich mit etwas Neuem befassen, wo doch die Corporate Information Factory (CIF 1.0) oder die BUS-Architektur erprobt und das Wissen verbreitet ist?
In der Sprache des Business gesprochen: Data Vault gibt uns Architekten heute die Möglichkeit, Anpassungen schnell umzusetzen, das Business korrekt abzubilden und mit den Anforderungen zu wachsen.
- Managen und durchsetzen von Compliance, z.B. Sarbanes-Oxley und BASEL II im Enterprise Data Warehouse
- Beleuchten von fachlichen Problemen, die bisher nie sichtbar wurden
- Enorme Reduzierung von Durchlaufzeiten um fachliche Anforderungen umzusetzen
- Schnelles integrieren neuer Fachbereiche oder Einheiten in das Enterprise Data Warehouse
- Kurzfristige Bereitstellung von Informationen in neue Data Marts oder neuer Informationen in bestehende Data Marts
- Unterstützung zur Konsolidierung von Daten, z.B. beim Master Data Management (MDM)
- Effiziente Skalierung hin zu großen Datenmengen, Terabyte oder sogar Petabyte
- Historisierung ist frei Haus dabei; Non-, Mono-, Bi-Temporal oder noch mehr.
- Vollständige Auditfähigkeit und Data Lineage
- Agil und anpassungsfähig an Veränderungen im Umfeld
- Flexible Anpassung von Business Rules
Technischer Nutzen durch Data Vault
Und was bringt mir Data Vault im technischen Bereich für Vorteile? Ebenfalls eine gern gestellte Frage.
Ein Enterprise Data Warehouse, das mit Data Vault im Core gebaut wurde, ist extrem skalierbar, die Architektur ist flexibel. Das zusammen erlaubt dem Business zu wachsen und sich zu verändern, ohne ohnmächtig und hilflos mit den enormen Kosten, langlaufenden Änderungszyklen und den endlosen Listen an Auswirkungen auf das bestehende Enterprise Data Warehouse konfrontiert zu sein.
Wer kennt es nicht, dass Änderungswünsche an das Datenmodell eines Enterprise Data Warehouse genau diese angesprochenen Punkte in Änderungsprojekten bedeuten?
Mit Data Vault ist es nicht annähernd so ausufernd. Typischerweise können neue Fachbereiche oder Kernkonzepte des Fachbereichs einfach und schnell integriert werden. Je nach der vorhandenen Architektur sind die Änderungen am bestehenden System viel schneller, d.h. in weniger als der halben Zeit gegenüber herkömmlichen Projekten umgesetzt. Da das Datenmodell abwärtskompatibel ist, sind bestehende, auf dem Enterprise Data Warehouse aufbauende Systeme nur wenig bis gar nicht von den Änderungen betroffen.
Data Vault integriert als Kernelement einer Architektur Daten und verknüpft diese fachlich sinnvoll. Dafür sind nur einige Standards und Definitionen für Elemente, wie z.B. Datenbankobjekte oder ETL-Prozesse notwendig.
- Near-Real-Time Loads – Mini-Batches
- Herkömmliche Batch Loads
- Data Mining im Enterprise Data Warehouse
- Abwärtskompatibel
- Ausbau des Enterprise Data Warehouse in kleinen Schritten – Inkrementell
- Nahtlose Integration unstrukturierter Daten (BigData)
- Leichte Anpassungen, Änderungen und Integration von Business Rules
Quellen: