Data Vault 2.0 Definition

Um einen flexibleren Ansatz zu ermöglichen, kann Data Vault 2.0 mit mehreren Quellsystemen und sich häufig ändernden Beziehungen umgehen, indem der Wartungsaufwand minimiert wird.

Das bedeutet, dass eine Änderung in einem Quellsystem, die neue Attribute erzeugt, einfach durch Hinzufügen eines weiteren Satelliten zum Data Vault-Modell umgesetzt werden kann. Einfach ausgedrückt: Neue und sich ändernde Beziehungen schließen einfach eine Verbindung und erstellen eine andere.

Diese Beispiele zeigen die hohe Flexibilität von Data Vault 2.0.

Wenn ein Unternehmen wächst, steigen auch die Anforderungen an die Daten.

In einer traditionellen Umgebung würde dies lange Implementierungsprozesse, hohe Kosten und eine umfangreiche Liste von dienstübergreifenden Auswirkungen erfordern.

Mit Data Vault 2.0 können neue Funktionalitäten einfach und schnell hinzugefügt werden, ohne dass dies Auswirkungen auf die nachgelagerten Systeme hat.

Daten werden immer häufiger für wichtige Geschäftsentscheidungen verwendet.

Um sicherzustellen, dass diesen Daten vertraut werden kann, ist Datenkonsistenz entscheidend.

Zu diesem Zweck ist in Data Vault 2.0 die Datenkonsistenz in das Data Vault-Modell eingebettet. Auf diese Weise ist es möglich, Daten auf konsistente Weise zu erfassen, selbst wenn die Quelldaten oder ihre Lieferung inkonsistent sind.

Und das alles bei gleichzeitiger Möglichkeit, Daten mit Hilfe von Hashwerten parallel zu laden.
Dies ermöglicht einen schnelleren Datenzugriff und verbessert gleichzeitig die Zufriedenheit der Geschäftsanwender.

Aus diesem Grund ebnet die hohe Konsistenz von Data Vault den Weg für den Einsatz von Automatisierungstools zur automatischen Modellierung Ihres Data Vault 2.0-Modells.

Die Methodik von Data Vault folgt dem CMMI-Prinzip.

CMMI ist ein Schulungs- und Bewertungsprogramm zur Prozessverbesserung, das fünf verschiedene Reifegrade eines Unternehmens umfasst.

So kann es sich auf die kontinuierliche Verbesserung der Prozesse auf der Grundlage quantitativer und präskriptiver Analysen konzentrieren.

Das ist auch der Grund, warum Data Vault 2.0 darauf abzielt, den genauen Reifegrad für die Implementierung strukturierter Entwicklungsprozesse zu ermitteln.

Dieser einfache, aber detaillierte Prozess ermöglicht eine leichte Wiederholbarkeit, wenn es darum geht, eine neue Änderung an einem bereits geplanten Prozess vorzunehmen.

Eine der Säulen von Data Vault 2.0 ist die Methodik, die mehrere Prinzipien agiler Arbeitsprozesse beinhaltet.

Daher haben Data Vault-Projekte einen kurzen, umfangskontrollierten Release-Zyklus. Normalerweise besteht dieser Zyklus aus einem Produktionsrelease alle zwei bis drei Wochen. Dies ermöglicht es dem Entwicklungsteam, eng mit den Anforderungen des Unternehmens zusammenzuarbeiten, um eine bessere Lösung zu schaffen.

Ein modernes Geschäftsumfeld ist häufig von häufigen Veränderungen geprägt.

Dabei kann es sich entweder um kleine Änderungen handeln, die sich kaum oder gar nicht auf die Datenstruktur auswirken, oder um große Änderungen, die erhebliche Auswirkungen auf die zugrunde liegende Datenstruktur haben.

Ein guter möglicher Anwendungsfall wäre die Übernahme eines anderen Unternehmens.

Dadurch würde die Notwendigkeit entstehen, komplexe neue Datenquellen zu integrieren, was eine der Hauptstärken von Data Vault ist. Die neuen Quellen würden als Erweiterung des bestehenden Data Vault 2.0-Modells modelliert werden, ohne dass sich das bestehende Modell ändert.

Dadurch wird der Wartungsaufwand auf ein Minimum reduziert.

Die Arbeit mit Daten erfordert oft detaillierte Informationen über die Herkunft der verarbeiteten Daten. Mit Data Vault 2.0 gibt es verschiedene Methoden, die helfen, den Überblick über Ihre Daten zu behalten.

So sind beispielsweise für jede Zeile, die im Data Warehouse ankommt, ein Ladezeitstempel und eine detaillierte Datensatzquelle erforderlich. Das Data Vault-Modell verfolgt auch alle Änderungen an Ihren Daten, indem es das Ladedatum als Teil des Primärschlüssels des Satelliten verwendet. Durch diese Faktoren wird die Überprüfbarkeit von Data Vault verbessert.

Der Staging Layer wird beim Laden von Batch-Daten in das Data Warehouse verwendet.
Sein Hauptzweck besteht darin, die Quelldaten schnell zu extrahieren, so dass die Arbeitslast auf den operativen Systemen verringert werden kann. Beachten Sie, dass der Staging-Bereich die Daten im Gegensatz zu den traditionellen Architekturen nicht aufbewahrt.

Die unveränderten Daten werden in den Raw Data Vault geladen, der die Data-Warehouse-Schicht des Unternehmens darstellt. Der Zweck des Data Warehouses besteht darin, alle historischen, zeitlich variablen Daten zu speichern. Alle Daten werden in der Granularität gespeichert, die von den Quellsystemen bereitgestellt wird. Die Daten sind nicht flüchtig und jede Änderung im Quellsystem wird von der Data-Vault-Struktur verfolgt.

Nachdem die Daten in das Data Vault-Modell geladen wurden, komplett mit Hubs, Links und Satellites, werden die business rules im Business Vault angewendet. Dieser Prozess findet auf den Daten im raw data vault statt.
Sobald die Geschäftslogik angewendet wurde, werden sowohl der raw data vault als auch der business vault zusammengeführt und in das Geschäftsmodell für die Informationsbereitstellung in den Information Marts umstrukturiert.

Darüber hinaus kann die Data-Warehouse-Schicht des Unternehmens durch optionale Vaults - einen Metrics Vault und einen Operational Vault - erweitert werden. Der Metrics Vault dient der Erfassung und Aufzeichnung von Laufzeitinformationen. Der Operational Vault speichert Daten, die von operativen Systemen in das Data Warehouse eingespeist werden. Alle optionalen Vaults, der Metrics Vault, der Business Vault und der Operational Vault, sind Teil des Data Vault und in die Data Warehouse-Schicht integriert.

Im Gegensatz zu herkömmlichen Data Warehouses wird auf die Data Warehouse-Schicht der Data Vault 2.0-Architektur nicht direkt von den Endnutzern zugegriffen. Der Grund dafür ist, dass das Ziel des Enterprise Data Warehouse darin besteht, den Endnutzern wertvolle Informationen zur Verfügung zu stellen. Beachten Sie, dass wir für diese Schicht den Begriff "Informationen" anstelle von "Daten" verwenden.

Ferner ist zu beachten, dass die Informationen im Information Mart themenorientiert sind und in aggregierter Form, flach oder breit, für das Reporting aufbereitet, hochgradig indexiert, redundant und qualitätsbereinigt sein können. 

Es folgt häufig dem Sternschema und bildet die Grundlage sowohl für relationale Reports als auch für multidimensionale OLAP-Würfel. Weitere Beispiele für Information Marts sind der Error Mart und der Meta Mart. Sie sind der zentrale Ort für Fehler im Data Warehouse bzw. für die Metadaten. 

Aufgrund der Plattformunabhängigkeit von Data Vault 2.0 kann NoSQL für jede Data-Warehouse-Schicht verwendet werden, einschließlich der Staging-Schicht, der Enterprise-Data-Warehouse-Schicht und der Information Delivery. Daher kann eine NoSQL-Datenbank als Staging-Area verwendet werden, die Daten in die relationale Data Vault-Schicht laden kann.

Jede Regel, die den Inhalt einzelner Felder oder die Granularität nicht verändert. Stattdessen ändert sie nur die Struktur der eingehenden Daten.

Jede Regel, die den Inhalt der Daten verändert, z. B. die Umwandlung von Daten in Informationen.

Jede Struktur, auf die der Endnutzer Zugriff hat und die zur Erstellung von Reports verwendet werden kann.

Die als Hubs, Links und Satellites modellierten Rohdaten sowie der Inhalt dieser Artefakte, die von der Quelle bereitgestellt werden.

Daten, die durch die Business Rules geändert wurden und in DV-Tabellen modelliert sind; spärlich erstellt.

Echtzeitdaten werden als ein Strom von Transaktionsdaten geladen.