Erfasst das Datenelement Load Date Timestamp (LDTS) im Hub, Link oder in einem Satelliten den Zeitstempel des Batches, oder eher den Transaktionszeitstempel zu dem die Daten im operativen System entstanden sind?
In vielen Projekten zu Datenlösungen, die das Team des Data Management Center of Excellence (DMCE) bei FastChangeCo™ umsetzt, stellt sich immer wieder diese Frage.Der erste Beitrag in der Temporal Data Serie ist eine Überarbeitung eines alten Blogposts von mir. Die Gründe dafür, den alten Beitrag wieder herauszukramen, waren eure zahlreichen Anfragen nach eine Übersetzung und einer Verfeinerung einzelner Abschnitte. Das Original ist immer noch zum Nachlesen verfügbar: Welche Zeit für Data Vault Timelines?
Oder soll das DMCE-Team besser den Zeitstempel der Extraktion der Daten aus der jeweiligen Quelle verwenden? Oder den Zeitstempel zu dem die Datensätze der Datenlösung in die jeweiligen Zieldatenobjekte (z.B. Tabellen) schreibt? Nicht einfach zu beantworten, oder?
Um eine Entscheidung zu finden, betrachtet das DMCE-Team diese Fragestellung aus Sicht der Fachabteilung. Wie möchten die Nutzer aus den Fachabteilungen die Daten (zeitlich) betrachten?
Accuracy - Genauigkeit, wann habe ich meine Daten erhalten
In sich konsistente, widerspruchsfreie Berichte, die jederzeit reproduzierbar sind.
Das bedeutet, es ist notwendig zu wissen: Wann waren die Daten der Datenlösung bekannt? Genauer gesagt, wann wurden die Daten in die Datenlösung geschrieben. Dabei spielt es keine Rolle, wann die Daten entstanden sind.
Damit lässt sich aus Sicht der Datenlösung die Frage konsistent beantworten: Welche Daten aus dem Datenobjekt A passen/gehören/entsprechen zeitlich zu welchen Daten im Datenobjekt B um ein einheitliches Bild des Geschäfts bei FastChangeCo™ zu zeigen?
Consistency - Konsistenz, bezogen auf Quellensysteme
Möglichst genaue, präzise Informationen darüber, wann Daten in einem Quellsystem entstanden sind.
Das bedeutet, dass die Daten in der Datenlösung möglichst exakt die Entstehung der Daten in dem originären Quellsystem widerspiegeln, dafür aber evtl. keine zeitlich konsistenten Reports ermöglichen.
Damit lässt sich aus Sicht der Datenlösung die Frage akkurat beantworten: Wann hat ein Ereignis in der Realität stattgefunden? Die Daten der Datenlösung liefern ein möglichst exaktes Bild über den Zeitpunkt des Geschäfts bei FastChangeCo™.
Entscheidung Genauigkeit oder Konsistenz
Um eine Entscheidung zu treffen, muss das DMCE-Team für sich die folgenden Fragen beantworten:
- Ist es zwingend notwendig, dass Berichte zu 100% reproduzierbar sind? Z.B. können sogenannte Late-Arriving Data die zeitliche Reihenfolge durcheinander bringen und damit einen Report nachträglich verändern.
- Sind alle Systeme (Quellsysteme, Datenbanken, Anwendungen) mit der gleichen Zeit (z.B. über einen Zeitserver) synchronisiert? Gerade Anwendungen kümmern sich nicht immer “liebevoll” um die korrekte Zeit beim Speichern der Daten. Das kann ebenfalls zu inkonsistenten Zeitlinien führen.
- Erhalte ich Informationen über die Zeitzonen in der Daten entstanden sind oder nur UTC?
- Werden Sommer- und Winterzeit in den operativen Systemen berücksichtigt?
- Ist der Transaktions- ( Erstellungs- ) Zeitstempel der Quelle in der Realität nicht ein Transaktions- ( Zuletzt-Geändert- ) Zeitstempel?
Das DMCE-Team ist sich im Klaren darüber, dass es Zeitstempeln, die nicht unter der eigenen Kontrolle unterliegen, genauer gesagt unter der Kontrolle der Datenlösung sind, nicht immer trauen kann!
Daher ist es wichtig diese Fragen zuerst zu beantworten, wenn Datenlösungen bei FastChangeCo™ mit unitemporalen Datenobjekten, also mit einer einzelnen Zeitlinie, umgesetzt werden. Sie sind entscheidend für die Wahl der zu verwendeten Zeit im Data Vault Datenmodell der Datenlösung.
Mit der Entscheidung Genauigkeit oder Konsistenz beeinflusst das DMCE-Team maßgeblich, wie sich im weiteren Projektverlauf Daten und Informationen in der Abfrageschicht zeitlich darstellen.
Darüber hinaus macht sich das DMCE-Team Gedanken, welcher Zeitpunkt, z.B. Transaction Time (Source), Extraktionszeitpunkt, Load Cycle Date, Load Transaction Time usw., der geeignetste ist, um als weiteres Datenelement im Zieldatenobjekt oder als zusätzliche beschreibende Information in einem geeigneten Metadatenmodell zu speichern.
Ein durchdachtes Metadatenmodell ist in der Lage die Grenzen zwischen Genauigkeit oder Konsistenz aufzuheben. Durch die Dokumentation der unterschiedlichen Zeiten im Metadatenmodell kann eine Abfrageschicht zwischen Genauigkeit und Konsistenz wechseln.
Eine andere Variante ist, dass Genauigkeit und Konsistenz im bitemporalen Kontext gelöst werden und beide Sichten auf die Daten möglich sind. So entspricht Genauigkeit nach wie vor dem Ansatz “Wann wusste die Datenlösung etwas über die Daten" und Konsistenz bedeutet im für die Datenlösung “Wann waren die Daten in der Realität gültig”!
Aber das ist eine andere Geschichte. Mehr darüber in einem der nächsten Artikel der Serie. Ihr solltet unbedingt wieder vorbeischauen.
So long,
Euer Dirk