DWH-Temporalität Teil 1: Die Herausforderung

In den letzten Jahren wurde ich immer wieder mit der Anforderung konfrontiert, Reports mit SCD Type 2-Dimensionen zu erstellen – hier ist meine Orientierungshilfe.

DWH-Temporalität Teil 1: Die Herausforderung

In den letzten Jahren wurde ich wiederholt mit der Anforderung konfrontiert, ein Reporting mit SCD Type 2-Dimensionen zu erstellen. Da im Data Warehouse üblicherweise 3 oder mehr Zeitachsen vorhanden sind, musste ich immer wieder klären, was die eigentliche fachliche Anforderung ist. Hier versuche ich, meine Gedanken zu ordnen und eine Orientierungshilfe für solche Diskussionen zu geben.

Der Artikel ist in drei Teile gegliedert: - Definition der verschiedenen Zeitachsen - Erstellung einfach nutzbarer Reports durch Reduktion der im DWH-Output enthaltenen Zeitachsen - Welche Use Cases machen es notwendig, die verschiedenen Zeitachsen auszugeben - Technische Lösungen für die Anforderung, vollständige Zeitflächen auszugeben. Was ist ein Time Slice? Was ist SCD Type 2? Was ist der Zusammenhang mit as-is, as-was, as-of?

In einer einfachen Welt gibt es nur das Hier und Jetzt: die Gegenwart. Wenn ich die Entwicklung über die Zeit erfassen möchte, brauche ich eine Zeitachse.

Was ist eine Zeitdimension (Zeitachse)? Was ist ein Time Slice? Was ist SCD Type 2? Was ist der Zusammenhang mit as-is, as-was, as-of?

In einer einfachen Welt gibt es nur das Hier und Jetzt. Also die Gegenwart. Wenn ich die Entwicklung über die Zeit erfassen möchte, brauche ich eine Zeitachse.

Ich kann eine Zeitachse in einen Zeitpunkt umwandeln, indem ich sie an einer beliebigen Stelle schneide.

Wenn ich nun auf meine Zeitachse zurückgehe und Korrekturen vornehme, kann ich die Änderungszeitpunkte auf einer separaten Zeitachse erneut eintragen.

Wenn ich diese beiden Zeitachsen im 90-Grad-Winkel zueinander aufzeichne, erhalte ich eine Zeitfläche.

Diese Zeitfläche kann ich jederzeit wieder auf eine Zeitachse reduzieren, indem ich sie an einem beliebigen Punkt entweder parallel zur einen oder zur anderen Achse schneide.

So kann ich eine Zeitfläche auf eine Zeitachse und diese wiederum auf einen Zeitpunkt reduzieren.

Solche Schnitte werden als sogenannte As-of-Views bezeichnet. Es gibt einen besonderen Schnitt: den auf den aktuell gültigen Zeitpunkt (der nicht immer das Ende einer Zeitachse ist): as-is. Und einen weiteren speziellen Schnitt, der die Kombination der Informationen zum Zeitpunkt eines Ereignisses darstellt: as-was. Unabhängig davon, ob ich einen as-is-, as-was- oder as-of-Schnitt vornehme – die daraus resultierende Vereinfachung von der Fläche zur Linie oder von der Linie zum Punkt ist dieselbe.

In diesem vereinfachten Beispiel kann ich die fachliche Gültigkeit als Zeitachse wählen und den Zeitpunkt, zu dem diese Information in einem IT-System erfasst wurde, als zweite Zeitachse. Damit haben wir eine Zeitfläche.

Im Data Warehousing kommt in jedem Fall eine dritte Zeitachse hinzu: der Zeitpunkt, zu dem das Data Warehouse von neuen oder geänderten Informationen Kenntnis erlangt. Zeichnet man diese dritte Zeitachse senkrecht zur bestehenden Zeitfläche ein, erhält man vereinfacht gesagt einen Würfel. Das ist der Grund, warum ich gerne von Zeitdimensionen spreche. Da es schwierig ist, sich mehr als 3 Dimensionen vorzustellen, werde ich auf weitere Zeitachsen jenseits der bereits genannten drei nicht eingehen.

Um die unterschiedlichen Probleme mit den verschiedenen Terminologien zu vermeiden, bevorzuge ich den Ansatz, die verschiedenen Zeitachsen – sofern sie als in einem Würfel angeordnete Dimensionen verstanden werden – mit Dimensionsnummern zu bezeichnen:

  • 1d: Wann war ein Eintrag aus fachlicher Sicht gültig. Nach Snodgrass, zitiert von Kaul: „capturing the history of a changing reality": Valid Time.

  • 2d: Capturing Time / System Time / Logged Time / Inscription Time / (((Transaction Time))) / Approximation for Assertion Time im Quell-IT-System. Assertion Time nach Johnston, zitiert von Kaul: „the time during which a row of data is asserted to make a true statement".

  • 3d: Acquisition Time / System Time / Logged Time / Load Time / Inscription Time / (((Transaction Time))) / Approximation Assertion Time im DWH-System. Assertion Time nach Johnston, zitiert von Kaul: „the time during which a row of data is asserted to make a true statement".

Time Slice

Ein Time Slice ist ein Abschnitt auf einer Zeitachse, in dem sich die Attribute für ein bestimmtes und identifizierbares Objekt nicht verändern. Ein Time Slice kann explizit mit einem Start- und einem Enddatum beschrieben werden, oder implizit gilt ein Time Slice per Definition als abgeschlossen, sobald ein neuer beginnt. In diesem Fall sind alle noch nicht abgeschlossenen Time Slices bis in alle Ewigkeit gültig (bzw. technisch bis zum höchsten von einer Datenbank unterstützten Datum).

Für die fachliche 1d-Gültigkeit ist es üblich, einen Start- und einen Endzeitpunkt zu definieren, da es auch Zeiten geben kann, in denen ein Geschäftsobjekt nicht gültig ist (z. B. ein gekündigter Vertrag). Der Vertrag kann später auch mit denselben Attributen reaktiviert werden, auch wenn er zwischenzeitlich ruhend war.

Bei der 2d- und 3d-Zeitachse hingegen wird davon ausgegangen, dass der Zeitpunkt eines neuen Eintrags automatisch das Ende des vorherigen bedeutet und umgekehrt nur ein neuer Eintrag die Gültigkeit des alten beenden kann. Das bedeutet, dass der Endzeitpunkt nicht gespeichert werden muss.

Bezeichnungen

Auch wenn Christian Kaul sehr gut zusammengefasst hat, wie die verschiedenen Zeitachsen bezeichnet werden können (https://www.linkedin.com/pulse/all-time-world-christian-kaul/), scheint es keinen allgemeinen Konsens zu geben. Der kleinste gemeinsame Nenner könnte noch sein, dass die erste Zeitachse als Valid Time bezeichnet wird (auch wenn manche verwirrenderweise die Load Time des DWH als VALID_FROM und VALID_TO bezeichnen).

Hier meine persönlichen Favoriten (Stand 20. Februar 2020): 1d: Valid Time 2d: Inscription Time 3d: Load Time

Der Punkt ist: Wir müssen uns gar nicht auf die Bezeichnungen einigen, solange alle wissen, welche Zeitachse was bedeutet – und wir haben eine eindeutige Kurzform über die Nummerierung 1d, 2d und 3d, einfach in der Reihenfolge, in der die Zeiten üblicherweise entstehen bzw. erfasst werden.

Was bedeutet SCD Type 2?

SCD Type 2 ist ein Verfahren zur Dokumentation einer neuen Zeitachse aus Informationen, die zu verschiedenen Zeitpunkten eingehen.

In der Regel wird der Begriff als Synonym für die Erstellung der 3d-Zeitachse im Data Warehouse verwendet. Die Ladezeit ins DWH wird üblicherweise verwendet, um einen neuen Time Slice zu beginnen. Implizit wird die Ladezeit des nächsten Datensatzes für denselben Schlüssel herangezogen, um die Assertion Period des vorherigen Eintrags zu beenden.

Diese Methode hat den großen Vorteil, dass alle Änderungen im Quellsystem erfasst und für jeden Assertion-Zeitpunkt ausgegeben werden können, was zu diesem Zeitpunkt als wahr galt.

Das Problem ist, dass es Data Warehouse-Implementierungen und auch Modellierer gibt, die DWHs erstellen, ohne sich überhaupt zu fragen: Welche Zeitachse bilden wir hier eigentlich ab? Ist diese Zeitachse überhaupt geeignet, die Anforderungen unseres Reportings zu erfüllen? Brauchen wir diese Zeitachse überhaupt für unsere Auswertungen? Sind die erfassten Änderungen nur Korrekturen, oder bilden wir wirklich Änderungen in der realen Welt ab?

Aus meiner persönlichen Sicht führt dieser Mangel an Analyse der fachlichen Anforderungen zu unüberlegten Implementierungen, bei denen alle Dimensionen in allen Reports in SCD Type 2-Form ausgegeben werden. Dieses Unverständnis ist auch der Grund für die schlechte Gewohnheit, die Begriffe VALID_FROM und VALID_TO für diese 3d-Zeitachse zu verwenden (glücklicherweise hat Dan Linstedt für die Data Vault-Welt den Begriff Load Time etabliert).

Im weiteren Verlauf dieser Serie werde ich versuchen zu erläutern, dass dies in bestimmten Fällen nicht nur überflüssig, sondern auch in manchen Fällen falsch sein kann. Gleichzeitig möchte ich alternative Lösungen anbieten, wie im Data Vault (und Data Warehouse) generell mit Zeit umgegangen werden kann.

https://wp.gr5qncwxtlc5sqo.static3.studio2020/03/12/temporality-data-warehouse-part-2-3-getting-rid-temporal-complexity/ https://wp.gr5qncwxtlc5sqo.static3.studio2020/03/23/temporality-data-warehouse-part-3-4-give-me-the-damn-times/