Der erste Teil endete mit einem Versprechen: Damit zwei Zeitlinien sauber ineinandergreifen, müssen ihre Zeitperioden in eine klare Beziehung zueinander gebracht werden. Genau diese Mechanik schauen wir uns jetzt an.
Teil 1 hat das Was und das Warum geklärt: Sobald Daten nicht in der Reihenfolge ankommen, in der sie real passiert sind, kippt ohne bitemporale Historisierung die Datenqualität. Bleibt das Wie – und da landen die meisten Teams an derselben Stelle: Konzeptionell ist klar, was passieren soll, aber wie fasst man es methodisch an?
Wer Diego, Amal und Xuefang noch nicht kennt: Sie sind fiktive Figuren aus dem FastChangeCo-Universum, mit dem ich reale Herausforderungen aus Projekten und Coachings greifbar mache.
Dieser Artikel ist Teil 2 einer vierteiligen Serie über bitemporale Daten in der Praxis. Er nimmt sich den vierten der acht Gründe aus dem Hub-Artikel „8 Gründe, warum man bitemporale Daten benötigt“ vor: die Fähigkeit, in Daten durch die Zeit zu reisen.
Die Kernthese: Zeitreisen sind kein Nebeneffekt der Bitemporalität, sondern ihr eigentlicher Zweck – und sie haben eine erlernbare Grammatik.
Der DeLorean im Büro
Es gibt eine Analogie, die im Zusammenhang mit temporalen Daten erstaunlich gut trägt: der DeLorean aus „Zurück in die Zukunft“ der in meinem Büro steht. Ein Auto, das durch die Zeit reist. Genau das macht eine bitemporale Datenlösung – nur dass sie nicht in die Zukunft fährt, sondern dich an jeden beliebigen Punkt der Vergangenheit setzt und dir zeigt, wie deine Daten von dort aus aussahen.
Bei FastChangeCo wird daraus eine ganz konkrete Frage. Amal Leyla Qasim, Data Modeler im Team, hat aus Teil 1 verstanden, dass zwei Zeitlinien das Late-Arrival-Problem auflösen. Aber sie hängt an einer praktischen Frage: „Schön, jetzt haben wir zwei Zeitstempel statt einem. Aber was mache ich konkret damit, wenn jemand mich nach einem alten Stand fragt?“
Diego Pasión, der das Team als Coach begleitet, nimmt die Frage auf. „Das ist genau der richtige Einstieg. Bevor wir über Joins und SQL reden, klären wir, welche Art von Frage du überhaupt stellst. Es gibt nämlich nicht eine Zeitreise, es gibt drei verschiedene.“
As-Is, As-Was, As-Of: drei Sichten auf dieselben Daten
Diego geht ans Whiteboard und schreibt drei Begriffe untereinander. „Dieselbe Tabelle, dieselben Zeilen – und trotzdem drei völlig verschiedene Antworten, je nachdem, von welchem Zeitpunkt aus du schaust.“
As-Is – Wie sieht die Realität heute aus? Das ist die Gegenwartssicht. Der aktuell gültige Stand, so wie er jetzt im System steht. Die meisten Reports, die ein Fachbereich täglich zieht, sind As-Is-Abfragen, auch wenn niemand sie so nennt.
As-Was – Wie sah die Realität damals aus? Hier reist du entlang der fachlichen Zeitlinie. Du fragst nicht, was heute gilt, sondern was an einem bestimmten vergangenen Datum in der Realität galt. Was war der Preis dieses Produkts am 1. März? Welche Adresse hatte diese Kundin im letzten Quartal?
As-Of – Was wussten wir damals? Das ist die Sicht, die ohne Bitemporalität schlicht nicht existiert. Du reist entlang der technischen Zeitlinie und fragst: Welches Bild der Realität hatte unser Warehouse an einem bestimmten Datum? Nicht was stimmte – sondern was wir damals für richtig hielten.
Xuefang Kaya, Junior im Team, hakt an genau der Stelle ein, an der es bei den meisten zum ersten Mal klickt. „Moment – As-Was und As-Of klingen für mich gleich. Beides ist doch Vergangenheit.“
Diego nickt. „Guter Einwand, das ist der Knoten. Ein Wechselkurs war im März falsch, im Mai korrigieren wir ihn. As-Was fragt: Was war der korrekte Kurs am 10. März? Der korrigierte Wert – das ist die Realität. As-Of fragt: Was hätte unser Report am 10. März angezeigt? Der falsche Wert – die Korrektur kannten wir damals noch nicht. Zwei verschiedene Wahrheiten über denselben Tag. Genau dieser Unterschied ist die Bitemporalität.“
Zwei Zeitlinien, kein gemeinsamer Kalender
Damit die drei Sichten funktionieren, brauchst du zwei voneinander unabhängige Zeitlinien. Teil 1 hat sie eingeführt, hier werden sie zum Werkzeug.
Die Assertion Timeline (technisch) hält fest, wann ein Wert bei uns im Warehouse bekannt wurde. Der zugehörige Zeitstempel ist der Inscription Timestamp. Die State Timeline (fachlich) hält fest, ab wann ein Wert in der Realität galt – über den State Timestamp.
Der entscheidende Punkt: Diese beiden Achsen sind unabhängig. Es gibt keinen gemeinsamen Kalender, der beide Fragen zugleich beantwortet. Jeder bitemporale Fakt sitzt am Kreuzungspunkt zweier Achsen – einmal die Frage „wann war das wahr?“, einmal die Frage „wann wussten wir es?“.
Genau hier liegt die Lösung des Late-Arrival-Problems aus Teil 1. Eine verspätet eingetroffene Korrektur landet auf der Assertion Timeline an einer anderen Position als das Original – und überschreibt es deshalb nicht mehr. Sie bekommt ihren eigenen Platz im Raster, statt den alten Wert zu verdrängen.
„Das heißt“, fasst Amal zusammen, „ich höre auf, eine Zeitlinie zwei Fragen beantworten zu lassen. Ich gebe jeder Frage ihre eigene Achse.“ Diego: „Genau. Und sobald du das tust, kannst du gezielt reisen – auf der einen Achse, auf der anderen, oder auf beiden gleichzeitig.“
Closed-Open-Intervalle: „vor“ statt „bis“
Bevor es an die Beziehungen zwischen Zeitperioden geht, ein Detail, das in der Implementierung viel Zeit spart – oder kostet, wenn man es ignoriert: wie eine Zeitperiode überhaupt begrenzt wird.
In der bitemporalen Historisierung arbeitest du mit Closed-Open-Intervallen: Der Anfangszeitpunkt gehört zur Periode, der Endzeitpunkt nicht mehr. Diego macht es am Umzugsbeispiel fest: „Du wohnst ab dem 1. Januar an einer Adresse, am 12. September ziehst du um. Deine alte Periode heißt dann nicht ‚1. Januar bis 12. September‘, sondern ‚ab 1. Januar, vor dem 12. September‘. Der 11. gehört noch dazu, der 12. schon zur neuen Periode.“
Daraus folgt die Sprachregelung dieser Serie: Wir schreiben „vor“, nicht „bis“. „Bis“ lässt offen, ob der Endtag noch dazugehört; „vor“ macht es eindeutig. Beide Perioden teilen sich genau einen Grenzwert – ohne Lücke, ohne Überlappung.
Das ist mehr als Kosmetik: Eine lückenlose, überlappungsfreie Zeitlinie macht jede Beladung einfacher. Beim Einfügen eines Datensatzes musst du nie prüfen, ob ein Endtag doppelt vergeben ist – die Grenze gehört immer genau einer Seite. Diese Entscheidung triffst du einmal am Anfang, danach trägt sie von selbst.
Die Grammatik der Zeitreise: Allen Relationship
Jetzt zum Herzstück. Amals Ausgangsfrage war: Was mache ich konkret, wenn eine Korrektur reinkommt und sich irgendwo einsortieren muss? Die Antwort heißt Allen Relationship.
Die Allen Relationship beschreibt, wie sich zwei Zeitperioden zueinander verhalten können – und davon gibt es nicht beliebig viele, sondern genau dreizehn. Zwei Perioden können vor- oder nacheinander liegen, sich berühren, überlappen, ineinander liegen, gleich anfangen, gleich enden oder identisch sein. Das war die ganze Liste.
„Dreizehn klingt erst mal nach viel“, sagt Xuefang. Diego winkt ab. „Dreizehn ist eine Einkaufsliste. Du musst sie nicht auswendig können – du musst nur wissen, dass sie endlich ist. Sobald du eine konkrete Korrektur vor dir hast, schaust du nach: Welche der dreizehn Beziehungen liegt hier vor? Daraus ergibt sich, was zu tun ist.“
Das ist der Unterschied zwischen einer, zwei oder drei neu eingefügten Zeilen. Wichtig dabei: Die bestehende Zeile wird nie verändert – sie wird auf der Assertion Timeline end-dated, und zusätzlich kommen neue Zeilen dazu. Reiht sich die Korrektur sauber an, genügt eine: die neue Periode. Überlappt sie eine bestehende Periode an einem Ende, kommen zwei dazu – ein Duplikat der alten Zeile für das weiterhin gültige Stück plus die neue Periode. Und schneidet die Korrektur mitten hinein, sind es drei: je ein Duplikat für das Stück davor und danach plus die neue Periode. Welcher Fall vorliegt, sagt dir die Allen Relationship. Wie man sie „wie eine Einkaufsliste“ liest, übt man im Temporal Data Training.
Über diese Serie: Dies ist Teil 2 von 4 unserer Serie „Bitemporale Daten in der Praxis“, die vom konkreten Engineering-Schmerz bis zur strategischen Entscheidung führt. Teil 1 zeigt, warum eine Zeitlinie bei Late Arrivals nicht reicht. Den Gesamtüberblick gibt der Hub-Artikel „8 Gründe, warum man bitemporale Daten benötigt“. Teil 3 verlässt die reine Fehlerkorrektur und blickt auf Vergangenheit, Gegenwart und Zukunft.
Zeitreisen, die wirklich funktionieren
Modul 1 und 2 des Temporal Data Trainings vermitteln genau diese Denkweise: Allen Relationship, Clock Ticks und bitemporale Strukturen – mit SQL-Tutorials und Übungen, die du direkt auf deine Architektur überträgst. Das Training wird gerade neu aufgezeichnet.
→ Training vormerken (Warteliste mit Early-Bird-Vorteil als Serien-Leser)
Was der Endnutzer nie sieht
An dieser Stelle kommt regelmäßig ein Einwand, und Xuefang spricht ihn aus: „Das klingt alles nach ziemlich viel Komplexität. Müssen unsere Fachbereiche das jetzt alles verstehen?“
Die Antwort ist einfach: Bitemporale Daten sind in der Regel nicht für den Endnutzer gedacht. Ihre Aufgabe ist es, die Daten im Hintergrund in die richtige Reihenfolge zu bringen. Die Bitemporalität agiert unter der Oberfläche – sie soll gar nicht sichtbar sein.
Was der Fachbereich am Ende bekommt, ist eine klare Sicht: meist die aktuelle Sicht auf die Daten, manchmal die fachliche Sicht auf einen bestimmten Zeitpunkt. Was war mein Preis gestern? Was gilt heute? Was ist für die Zukunft geplant? Diese Fragen beantwortet eine schlanke Abfrage – die ganze Maschinerie aus zwei Zeitlinien und dreizehn Beziehungen bleibt dahinter verborgen.
Wichtig ist das für die Teams, die es implementieren: Dort braucht es einen gewissen Reifegrad und das Verständnis dafür, was im Hintergrund passiert. Aber auch hier gilt – einmal sauber implementieren, zu Beginn der Datenlösung, dann automatisieren. „Ihr baut die Komplexität einmal richtig ein“, sagt Diego, „danach ist sie ein Lösungsmuster, das ihr immer wieder verwendet – nicht ein Problem, das ihr in jedem Projekt neu durchdenkt.“
Vom Konzept zur Methode
Amals Ausgangsfrage war: Konzeptionell verstehe ich das jetzt – aber wie fange ich methodisch an? Die Zeitreise trägt auf drei Bausteinen: erstens klären, welche Art von Frage du stellst – As-Is, As-Was oder As-Of; zweitens die beiden Achsen sauber trennen und mit Closed-Open-Intervallen lückenlos halten; drittens die Allen Relationship als endliche Liste nutzen, um jede Korrektur einzusortieren.
Das ist der technische Kern der Bitemporalität. Keine geheimnisvolle Tiefe, sondern ein abzählbares Handwerk – einmal gelernt, dann beherrscht.
„Den Knoten im Hirn“, sagt Diego zum Abschluss des Meetings, „den hatten wir heute fast aufgelöst. Was bleibt: Bisher haben wir nur über Korrekturen geredet – über Vergangenes, das wir richtigstellen. Aber Zeitreisen gehen auch vorwärts. Rückwirkende Buchungen, geplante Preise, Szenarien für die Zukunft. Das schauen wir uns beim nächsten Mal an.“ Genau da machen wir in Teil 3 weiter.
So long,
Dirk