Multi-Temporalität in Data Vault 2.0
Der folgende Artikel gibt einen Überblick über das theoretische Verständnis von Multi-Temporalität in einem Data Warehouse.
Multi-Temporalität in Data Vault 2.0
Vielleicht haben Sie bereits von bitemporalen Daten gehört. Doch in der Regel gibt es in Ihren Daten mehr als nur zwei Zeitachsen, was Ihre Arbeit komplexer macht. Meist finden Sie in Ihren Datensätzen mehrere Zeitstempel und Daten aus unterschiedlichen Perspektiven. Dies eröffnet vielfältige Möglichkeiten, Ihre Daten aus einer zeitlichen Perspektive zu betrachten. Sie sollten jedoch auch in der Lage sein, dieses „Biest“ von einer Zeitmaschine zu beherrschen. Wussten Sie, dass Data Vault 2.0 in der Lage ist, multi-temporale Daten zu verarbeiten? Wie beeinflusst dies Ihre Arbeit und wie können Sie davon profitieren? Nehmen Sie an diesem Webinar teil, um zu erfahren, wie Data Vault 2.0 Ihnen helfen kann, die Multi-Temporalität zu meistern.
Was ist „Multi-Temporalität“ in einem Data Warehouse?
Bevor wir über Multi-Temporalität sprechen, definieren wir zunächst den Begriff Bitemporalität, da ein weit verbreitetes Missverständnis darin besteht, dass Data Vault 2.0 nur bitemporal sei (was falsch ist):
„Die bitemporale Modellierung ist ein Spezialfall einer temporalen Datenbank-Modellierungstechnik, die für den Umgang mit historischen Daten entlang zweier unterschiedlicher Zeitachsen entwickelt wurde. Dies ermöglicht es, die Informationen auf den Zustand zurückzuspulen, ‚wie sie tatsächlich waren‘, kombiniert mit dem Zustand, ‚wie sie zu einem bestimmten Zeitpunkt aufgezeichnet wurden‘.“ (Frei nach Wikipedia)
Die Bitemporalität adressiert lediglich zwei Zeitachsen, die gemeinhin als „System Time“ (die technische Zeitachse) und „Valid Time“ (die fachliche Zeitachse) bezeichnet werden. Data-Vault-Satelliten (Satellites), Point-in-Time-Tabellen (PIT) und Bridge-Tabellen sind in der Lage, mehrere aktive Zeitachsen im selben Datensatz abzubilden. Diese lassen sich wie folgt kategorisieren:
- Quellgesteuerte Zeiten (Source-driven Times)
- Erstellungszeitpunkt (Created Time)
- Aktualisierungszeitpunkt (Updated Time)
- Löschzeitpunkt (Deleted Time)
- Systemzeiten (System Times)
- CDC-Zeitstempel (CDC Time)
- Ereigniszeitpunkt der Nachricht (Message Event Time)
- Fachliche Zeiten (Business Times)
- alle Zeiten, die darstellen, wann etwas in der „realen Welt“ passiert ist oder passieren wird (wie z. B. ein Kauf- oder Verkaufszeitstempel)
- Zeitspannen (Time Spans)
- können technisch oder fachlich motiviert sein
- Vertragsstart- und -enddaten/-zeiten (Contract Start and End Dates/Times)
- Technische Gültig-von- und Gültig-bis-Daten/Zeitstempel (Technical Valid-from and Valid-to Dates/Timestamps)
- Enterprise Data Warehouse (EDW)
- Load Date Timestamp (beim Einfügen in der ersten Schicht des EDW gesetzt)
- Zeitstempel des Schreibvorgangs eines Datensatzes in die Tabelle
All diese Datumsangaben und Zeitstempel könnten in nur einem einzigen Datensatz in einer Satellitentabelle zu finden sein. Dies ermöglicht es uns, die Daten aus mehreren zeitlichen Perspektiven zu betrachten. Daher berücksichtigt das Data-Vault-Modell die Multi-Temporalität und nicht nur die Bitemporalität.
Der Load-Date-Timestamp bei Multi-Temporalität
Eine Voraussetzung für die Realisierung von Multi-Temporalität in den Daten ist, dass der Load-Date-Timestamp beim Laden von Daten in Satelliten für den Delta-Abgleich (Delta Check) verwendet wird. Nur der Load-Date-Timestamp kann uns eine konsistente, lückenlose und überschneidungsfreie Zeit liefern, die unter unserer eigenen Kontrolle steht. Dies ermöglicht uns eine uneingeschränkte Sicht auf die verschiedenen Zeitachsen in den Satelliten.
Alle anderen Zeitstempel sind dafür nicht geeignet. Erstens würden sie die Anzahl der möglichen Perspektiven auf die Daten auf eine einzige Instanz beschränken. Zudem können sie Lücken und Überschneidungen aufweisen, NULL sein und werden nicht von den Enterprise-Data-Warehouse-Teams kontrolliert.
Kurz gesagt: Auf den Load-Date-Timestamp können wir keinesfalls verzichten. Er wird beim Einfügen (Insert) in der ersten Schicht der Enterprise-Data-Warehouse-Architektur gesetzt und so weit wie möglich durch alle Schichten durchgeschleust (beispielsweise bei Aggregaten im Business Vault über mehrere Load-Date-Timestamps hinweg).
Drei verschiedene Perspektiven auf Daten
Das Data-Vault-Kernmodell wird in den Raw Data Vault (RDV) und den Business Vault (BV) unterteilt. Der Grund dafür ist die Trennung von Soft Business Rules und Hard Business Rules, da Soft Business Rules den Inhalt der Daten verändern können. Dies führt dazu, dass sich die Anzahl der möglichen Perspektiven auf die Rohdaten verringert, wenn Soft Business Rules früh in der Ladearchitektur angewendet werden. Dieselben Regeln müssen auch auf Zeitachsen angewendet werden. Zeitachsengesteuerte geschäftliche Perspektiven auf Rohdaten finden frühestens im Business Vault statt.
Es gibt im Wesentlichen drei verschiedene Perspektiven im Zusammenhang mit Zeitachsen im Data Warehouse: eine Data-Warehouse-Perspektive, eine geschäftliche Perspektive und eine Perspektive der Informationsbereitstellung.
Die Data-Warehouse-Perspektive bezieht sich auf den Load-Date-Timestamp, um eine konsistente, inkrementelle Integration der Daten in den Raw Data Vault und den Business Vault zu gewährleisten.
Die geschäftliche Perspektive bezieht sich auf alle Daten und Zeitstempel, die vom Quellsystem geliefert werden. Auch technische Felder wie das Erstellungs-, Aktualisierungs- oder Löschdatum bzw. der entsprechende Zeitstempel aus dem Quellsystem werden auf dieselbe Weise behandelt. Alles, was Teil der Nutzdaten (Payload) ist, wird beim Laden in den Raw Data Vault als beschreibende Daten behandelt.
Nun können verschiedene Abfragen alle möglichen Sichten auf die Rohdaten erstellen – zum Beispiel Aggregate basierend auf dem neuesten Datensatz pro Business Key, gruppiert nach einem Verkaufsdatum.
Die Perspektive der Informationsbereitstellung stützt sich auf einen Snapshot, um alle Daten so „einzufrieren“, wie sie zu einem bestimmten Zeitpunkt aktiv waren. Die Interpretation dessen, was „aktiv“ bedeutet, kann jedoch unterschiedlich sein.
Um dem Rechnung zu tragen, können mehrere Perspektiven erstellt werden. Das ist auch der Grund, warum wir von der „Single Version of the Facts“ im Raw Data Vault und von „Multiple Versions of the Truth“ im Business Vault sprechen (unterschiedliche Perspektiven auf Rohdaten = unterschiedliche Wahrheiten aus verschiedenen Blickwinkeln).
Dies könnte beispielsweise ein stündlicher, täglicher, wöchentlicher, monatlicher oder jährlicher Snapshot oder eine entsprechende Zeitspanne sein. Die hier verwendeten Data-Vault-Entitäten sind die PIT- und Bridge-Tabellen. Das aktuelle Delta von Stammdaten wie Kundendaten in einem Satelliten kann basierend auf einem täglichen Snapshot in einer PIT-Tabelle „eingefroren“ werden. Auch Transaktionsdaten, die in einem Non-Historized-Link vorgehalten werden, können an einen stündlichen Snapshot in einer Bridge-Tabelle angehängt werden.
Wie das genau aussieht, wird im nächsten Teil der multitemporalen Newsletter-Serie gezeigt. Um Ihr Verständnis dieser Datenperspektiven zu vertiefen, können Sie auch unseren Kurs „Multi-Temporal Data Vault“ besuchen.
Fazit
Die Integration von Multi-Temporalität in Data Vault 2.0 ermöglicht es Unternehmen, Daten über verschiedene Zeitachsen hinweg zu verwalten und zu analysieren, was eine umfassende Sicht auf historische Änderungen aus mehreren Perspektiven bietet. Dieser Ansatz verbessert die Fähigkeit, die Datenentwicklung zu verfolgen und zu verstehen, was zu einer fundierteren Entscheidungsfindung und einer verbesserten Data Governance führt. Durch den effektiven Umgang mit mehreren zeitlichen Aspekten gewährleistet Data Vault 2.0 ein robustes und flexibles Framework zur Erfassung der Komplexität zeitvarianter Daten.
