Wir haben schon immer nach optimalen Lösungen gesucht, um Informationen intelligent und platzsparend abzulegen. Gleichzeitig wollen wir sie aber auch schnell wieder verfügbar machen. Das hat jahrelang mehr oder weniger gut funktioniert. Seit geraumer Zeit kommen aber auf die IT-Abteilungen neue Herausforderungen zu: es müssen quasi per sofort mehr und flexibler Informationen bereitgestellt werden. Außerdem kommen immer mehr Daten mit teils sehr unterschiedlichen Granularität zusammen, die in ein System zu integrieren sind. Mit Data Vault als Modellierungstechnik behalten Sie Kosten, Daten und Zeit im Griff.
Das Beste aus beiden Welten
Bereits Mitte der 1990er Jahre beschäftigten sich eine ganze Reihe von Datenbankspezialisten mit der Data Vault Idee. So auch der Amerikaner Daniel Linstedt. Er war ein Pionier im Bereich der Datenbanken sowie der Prozess-Optimierung von ETL-Strecken (und ist es auch heute noch!). Seine Ideen konnte er in einigen Firmen und auch bei der amerikanischen Regierung umsetzen. Die Erfahrungen, die er dabei gemacht hat, führten zu dem Data Vault Modell: ein Hybrid aus einem klassischem 3NF- und einem Star Schema-Modell. Es nutzt jedoch jeweils nur die Vorteile der beiden Modelle und fügt darüber hinaus noch weitere hinzu. So lassen sich beispielsweise neue Informationen auf einfache Weise in den ETL-Prozess einbinden, ohne das Datenmodell zu verbiegen oder in zahlreichen Anpassungen die Prozessketten an die neuen Gegebenheiten anzupassen. Eine Win-win-Situation für die IT-Zeitkonten und das Fachbereichs-Budget.
Im Kern besteht ein Data Vault Modell aus drei Objekten
HUB
Dieser Objekttyp beinhaltet den fachlichen Schlüssel, also beispielsweise eine Kunden- oder Artikelnummer. Dieser fachliche Schlüssel wird mit einem technischen Schlüssel sowie einer Zeitstempel- und einer Datenquellen-Spalte ergänzt. So weiß man schon einmal, wann welcher Schlüssel zu welchem Zeitpunkt aus welcher Quelle kam. Der technische Schlüssel besteht in der Regel aus einem Hashkey, der aus den fachlichen Schlüsseln gebildet wird. In vielen Datenbanken sind entsprechende Funktionen bereits vorhanden und können auf einfache Weise verwendet werden.
LINK
In diesem Objekttyp werden alle Beziehungen zwischen den HUBs gespeichert. Was in der 3. Normalform der Fremdschlüssel ist, wird hier in ein eigenes Datenbank-objekt ausgelagert.
Der Vorteil: Bei Veränderung der Zuordnung (beispiels-weise des Vertreters bei einem Kunden) wird über die auch in diesem Objekttyp vorhandene Zeitstempel- und Datenquellen-Spalte ein Nachvollziehbarkeit protokolliert. Eine Protokollierung per Definition so zusagen.
SATELLITE
Hier werden Informationen zu einem HUB oder einem LINK abgelegt, beispielsweise der Name des Kunden oder das Datum des letzten Kundenbesuchs des Vertreters. Durchaus auch, welchen Preis ein Artikel in einem Auftrag hat. Da auch dieser Objekttyp über eine Zeitstempel- und eine Datenquelle-Spalte verfügt, sind gleichartige Informationen aber aus unter-schiedlichen Datenquellen nachvollziehbar bzw. abgrenzbar. Mit Hilfe dieser Objekttypen-Verbindungen lassen sich also sowohl Stamm- als auch Bewegungs-daten abbilden. So bekommen Stammdaten eine Historie und Bewegungsdaten eine eindeutige Struktur.
Einfach rein, aber schwieriger wieder raus
Das Prinzip ist simpel, es braucht aber Hilfsmittel, um den Daten Dschungel am Ende auch wieder zusammenzubringen.
Was für die IT, beziehungsweise den ETL-Prozess, der dahintersteht, eine tolle Sache ist, löst auf Anwenderseite eher Stirnrunzeln aus. Bei der Aufteilung in die drei Objekttypen können schnell eine Vielzahl an Tabellen und Beziehungen entstehen, die auch die Datenbank affinen Fachbereichskollegen schnell an ihre Grenzen stoßen lassen. Wie schon Konfuzius sagte: „Wer bei seinen Handlungen immer auf Vorteil bedacht ist, wird sich viele Feinde machen.“ Nun sind wir sicher weit ab von dem Verlangen nach Ärger, darum gibt es einige weitere Objekte, die auch dem Kollegen des Fachbereichs das Leben wieder einfacher machen. Wir erweitern den Data Vault um einige Hilfsobjekte und erlangen so einen Business Vault, also ein Datenmodell, mit dem auch der Fachbereich etwas anfangen kann.
Point-in-Time Table (PIT)
Bridges
Brückentabellen (Bridges) dienen wie die PITs dazu, Abfragen an die Daten sowie das System selbst im Hinblick auf den Durchsatz zu verbessern. Im Gegensatz zu einer PIT, die sich einem einzelnen HUB widmet, sind Bridges gedacht, um mehrere Schlüssel aus HUBS und LINKS in einer Tabelle zu bündeln. So ist ein einfacherer Zugriff auf übergreifende Informationen möglich.
Bridges sollten eher keine fachlichen Schlüssel der HUBS enthalten, da es sonst zu einer höheren Anzahl an Sätzen und somit zu Performanceverlusten führt.
Business Hubs/Derived Tables
Dieser Objekttyp ist dann sinnvoll einzusetzen, wenn Informationen in aggregierter Form oder aus unterschiedlichen Datenquellen zusammengeführt werden sollen. Wie schon bei Pits und Bridges, steht auch hier der Gewinn an Performance im Vordergrund. Abzuwägen bei der Verwendung dieser Form ist zwischen dem Zeitgewinn und der Notwendigkeit des Aufbaus. Manchmal ist weniger mehr.
Ich habe bereits einiges an Erfahrung in dieser Technik gesammelt und gebe Ihnen gerne Tipps dazu. Am besten in einem persönlichen Gespräch. Ich freue mich, wenn Sie mir dazu einen Terminvorschlag an kontakt@mip.de schicken.
Ihr
Ulrich Drexelius
Principal Consultant
