Multi-Temporalität in Data Vault 2.0
Der folgende Artikel gibt einen Überblick über das theoretische Verständnis der Multi-Temporalität in einer data warehouse.
Multitemporalität in Data Vault 2.0
Vielleicht haben Sie schon einmal von bi-temporalen Daten gehört. Aber in der Regel gibt es mehr als nur zwei Zeitlinien in Ihren Daten, die Ihre Arbeit erschweren. In der Regel finden Sie in Ihren Datensätzen mehrere Zeitstempel und Daten aus verschiedenen Perspektiven, die mehrere Möglichkeiten bieten, wie Sie Ihre Daten aus einer zeitlichen Perspektive betrachten können. Aber Sie sollten auch in der Lage sein, mit diesem Ungetüm von Zeitmaschine umzugehen. Wussten Sie, dass Data Vault 2.0 in der Lage ist, multitemporale Daten zu verarbeiten? Welchen Einfluss hat dies auf Ihre Arbeit und wie können Sie sich dies zunutze machen? Nehmen Sie an diesem Webinar teil und erfahren Sie, 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 uns mit der Multitemporalität befassen, sollten wir zunächst den Begriff der Bi-Temporalität definieren, denn es ist ein weit verbreiteter Irrglaube, dass Data Vault 2.0 nur bi-temporal ist (was falsch ist):
"Bitemporale Modellierung ist ein spezieller Fall der Modellierung von Informationen in temporalen Datenbanken, die für den Umgang mit historischen Daten entlang zweier unterschiedlicher Zeitlinien entwickelt wurde. Dadurch ist es möglich, die Informationen so zurückzuspulen, wie sie tatsächlich waren, in Kombination mit den Daten, wie sie zu einem bestimmten Zeitpunkt aufgezeichnet wurden. (Nach Angaben von Wikipedia)
Die Zweizeitigkeit bezieht sich nur auf zwei Zeitlinien, die allgemein als "Systemzeit" (die technische Zeitlinie) und "Gültige Zeit" (die geschäftliche Zeitlinie) bezeichnet werden. Data Vault Satellites, Point-in-Time-Tabellen (PIT), and Bridge-Tabellen sind in der Lage, mehrere aktive Zeitleisten in ein und demselben Datensatz anzusprechen. Lassen Sie uns nur einige von ihnen kategorisieren:
- Quellengesteuerte Zeiten
- Erstellte Zeit
- Aktualisierte Zeit
- Gelöschte Zeit
- Systemzeiten
- CDC-Zeit
- Ereigniszeit der Nachricht
- Geschäftszeiten
- any times that represent when something happened or will happen in the “real world” like a purchase or sell timestamp.
- Zeitspannen
- can be technical, can be business-driven
- Datum und Uhrzeit des Vertragsbeginns und -endes
- Technische Gültig-von und Gültig-bis-Daten/Zeitstempel
- Enterprise Data Warehouse (EDW ignorieren)
- Zeitstempel des Ladedatums (wird beim Einfügen in der ersten Schicht des EDW gesetzt)
- Zeitstempel, wenn ein Datensatz in die Tabelle geschrieben wird
Alle diese Daten und Zeitstempel können in nur einem Datensatz in einer Satellitentabelle gefunden werden. Auf diese Weise können wir die Daten aus verschiedenen Zeitperspektiven betrachten. Daher berücksichtigt das Data Vault-Modell die Multitemporalität und nicht nur die Bi-Temporalität.
Der Zeitstempel des Ladedatums mit Multi-Temporalität
One requirement to realize multi-temporality on the data is that the Load Date Timestamp is used for loading data into Satellites when doing the delta check. Only the Load Date Timestamp can provide us with a consistent, gapless, and non-overlapping time which is under our control. This allows us to have an unrestricted view of the multi-timelines in Satellites.
All other timestamps are not qualified. First, they would restrict the number of possible perspectives on the data to a single instance. Additionally, they can have gaps, and overlappings, be NULL, and are not controlled by the Enterprise Data Warehouse teams.
Kurz gesagt: Wir werden den Zeitstempel des Ladedatums nie loswerden, der während des Einfügens in der ersten Schicht der Enterprise Data Warehouse-Architektur festgelegt und so weit wie möglich durch alle Schichten geschoben wird (denken Sie an Aggregate im Business Vault über mehrere Zeitstempel des Ladedatums).
3 Unterschiedliche Sichtweisen auf Daten
The core Data Vault is differentiated into the Raw Data Vault (RDV) and the Business Vault (BV). The reason is to split soft business rules from hard business rules as soft business rules can change the content of the data. The result is that the number of possible perspectives on the raw data is reduced when soft business rules are applied early in the loading architecture. The same rules have to be applied to timelines. Timeline-driven business perspectives on raw data happen earliest in the Business Vault.
There are basically three different perspectives related to timelines in the data warehouse: A data warehouse perspective, a business perspective, and an information delivery perspective.
Die Perspektive data warehouse bezieht sich auf den Zeitstempel des Ladedatums, um eine konsistente inkrementelle Integration der Daten in die Raw Data Vault und Business Vault zu erreichen.
The business perspective relates to all dates and timestamps which are delivered by the source system. Also, the technical fields are counted in the same way as the created, updated, or deleted date/timestamp from the source system. Everything that is part of the payload is handled as beschreibenden Daten beim Laden von Raw Data Vault.
Now, different queries can create all possible views of the raw data; for example, aggregates based on the most recent record per Business Key and grouped by a sales date.
Die Perspektive der Informationsbereitstellung stützt sich auf eine Momentaufnahme, um alle Daten so "einzufrieren", wie sie zu einem bestimmten Zeitpunkt aktiv waren. Die Interpretation dessen, was "aktiv" bedeutet, kann jedoch unterschiedlich sein.
To address this, multiple perspectives can be created. That’s also the reason why we talk about the single version of the facts in the Raw Data Vault and multiple versions of the truth in the Business Vault (different perspectives on raw data = different truths from different standpoints).
This could, for example, be an hourly, daily, weekly, monthly, or yearly snapshot or timespan. The Data Vault entities that are used here are the PIT and Bridge tables. The current delta of master data like customer data in a Satellite can be “frozen” based on a daily snapshot in a PIT table. Also, transactional data kept in a Non-Historized Link kann an einen stündlichen Schnappschuss in einer Brückentisch.
How that exactly looks will be shown in the next part of the multi-temporal newsletter series. To enhance your understanding of these data perspectives, you can also explore our Multitemporal Data Vault Klasse.
Schlussfolgerung
Incorporating multi-temporality into Data Vault 2.0 enables organizations to manage and analyze data across various timelines, providing a comprehensive view of historical changes from multiple perspectives. This approach enhances the ability to track and understand data evolution, leading to more informed decision-making and improved data governance. By effectively handling multiple temporal aspects, Data Vault 2.0 ensures a robust and flexible framework for capturing the complexities of time-variant data.