Bitemporale Datenmodelle für Marktdaten valid time und transaction time sauber trennen.
Marktdaten haben zwei Zeitachsen, auch wenn die meisten Datenbanken nur eine speichern. Die erste: Für welchen Zeitpunkt gilt ein Wert — der Schlusskurs vom 31. März, der Gewinn für Q1. Die zweite, leicht übersehene: Wann wurde dieser Wert in unserem System bekannt und gespeichert? Wer nur die erste Achse führt und Korrekturen einfach überschreibt, verliert die Fähigkeit, einen Backtest exakt mit dem Wissensstand der Vergangenheit zu rechnen — und verschenkt zugleich jede Nachvollziehbarkeit, wenn später jemand fragt, warum ein historisches Ergebnis sich verändert hat. Bitemporale Datenmodellierung führt beide Achsen explizit: valid time und transaction time. Das macht Datenkorrekturen reproduzierbar, ermöglicht exakte As-of-Abfragen und schafft eine prüffähige Historie. Dieser Beitrag erklärt die beiden Zeitachsen, zeigt, wie bitemporale Tabellen aufgebaut werden, welche Abfragen sie ermöglichen, welchen Aufwand das kostet — und wann der volle bitemporale Apparat angemessen ist und wann er das Datenmodell unnötig verkompliziert.
Zwei Zeitachsen — valid time und transaction time.
Der Kern der bitemporalen Idee ist die saubere Trennung zweier Fragen, die in einfachen Datenbanken verschmelzen und dadurch Verwirrung stiften.
Die valid time beantwortet: Auf welchen Zeitpunkt oder Zeitraum bezieht sich der Wert in der realen Welt? Der Schlusskurs gehört zum 31. März, der gemeldete Gewinn zum ersten Quartal. Diese Achse beschreibt die Wirklichkeit, die der Wert abbildet.
Die transaction time beantwortet: Wann wurde dieser Datensatz in unserem System angelegt, geändert oder als ungültig markiert? Sie beschreibt die Wissensgeschichte des Systems — wann wir etwas erfahren haben. Wird ein Quartalsgewinn am 15. Mai erstmals gespeichert und am 20. August korrigiert, sind das zwei transaction-time-Ereignisse für dieselbe valid time.
Erst beide Achsen zusammen erlauben die entscheidende Aussage: "Am 1. Juni wussten wir, dass der Gewinn für Q1 X betrug — auch wenn wir heute wissen, dass es in Wahrheit Y war." Eine einachsige Datenbank kann das nicht; sie kennt entweder nur den heutigen Stand oder verliert beim Überschreiben die Geschichte. Genau diese verlorene Geschichte ist es, die Backtests und Audits brauchen.
Wie eine bitemporale Tabelle aufgebaut ist.
Technisch ergänzt man eine fachliche Tabelle um vier Zeitstempel-Spalten — je zwei pro Achse:
| Spalte | Bedeutung |
|---|---|
| valid_from | Ab wann gilt der Wert in der Realität |
| valid_to | Bis wann gilt er |
| tx_from | Ab wann ist diese Version im System bekannt |
| tx_to | Bis wann galt diese Version als aktuell (offen = bis heute) |
Der zentrale Grundsatz: Es wird nie überschrieben und nie gelöscht. Eine Korrektur erzeugt eine neue Zeile. Die alte Version wird nicht entfernt, sondern bekommt nur ein tx_to gesetzt — sie ist damit "war mal aktuell, ist es nicht mehr", bleibt aber für historische Abfragen erhalten. Jeder Wert, den das System je geglaubt hat, bleibt rekonstruierbar.
Daraus folgt, dass bitemporale Tabellen nur wachsen. Jede Korrektur, jede Revision, jeder Late-Arriving-Datensatz fügt Zeilen hinzu. Das ist gewollt: Der Speicherverbrauch ist der Preis für vollständige Nachvollziehbarkeit. Bei Daten mit vielen Revisionen — Fundamentaldaten, Schätzungen — kann die Tabelle ein Vielfaches der "naiven" Zeilenzahl erreichen; bei selten korrigierten Daten bleibt der Aufschlag gering.
Die As-of-Query als eigentlicher Gewinn.
Der praktische Wert des Modells zeigt sich in der Abfrage. Eine bitemporale Tabelle erlaubt es, beide Zeitachsen unabhängig zu fixieren — und genau das macht exakte historische Rekonstruktion möglich.
Für den Backtest entscheidend ist die Frage: "Welchen Wert für valid time V hätten wir am Wissensstand transaction time T gesehen?" Man fixiert tx auf den historischen Handelstag und valid auf die fragliche Periode — und erhält genau die Datenversion, die damals aktuell war, frei von allen späteren Korrekturen. Das ist die saubere Grundlage für leakagefreie Backtests: Die Strategie handelt mit dem, was bekannt war, nicht mit dem, was sich später herausstellte.
Genauso lassen sich zwei nützliche Spezialfragen beantworten: "Was glauben wir heute über die Vergangenheit?" (transaction time = jetzt, also der korrigierte Stand) und "Was glaubten wir damals?" (transaction time = historisch). Der Vergleich beider deckt auf, wie stark und in welche Richtung Daten nachträglich revidiert wurden — eine Analyse, die ohne bitemporale Speicherung schlicht unmöglich ist, weil die alte Wahrheit überschrieben wäre.
Reproduzierbarkeit und Audit.
Über den Backtest hinaus löst Bitemporalität ein hartnäckiges Problem der quantitativen Praxis: die Reproduzierbarkeit von Ergebnissen. Wer kennt nicht die Situation, dass ein Backtest, der vor drei Monaten eine bestimmte Kurve zeigte, heute leicht andere Zahlen liefert — obwohl der Code identisch ist? Die Ursache sind fast immer still revidierte Daten.
Mit transaction time wird dieser Effekt nicht nur erklärbar, sondern eliminierbar. Man kann den Backtest "einfrieren", indem man die transaction time auf den ursprünglichen Auswertungszeitpunkt setzt — und erhält exakt dieselben Daten und damit dasselbe Ergebnis wie damals. Das ist die Grundlage für reproduzierbare Forschung: Ein Resultat lässt sich später bit-genau nachstellen, was bei einachsigen, überschriebenen Datenbanken prinzipiell unmöglich ist.
Im regulierten Umfeld kommt der Audit-Aspekt hinzu. Wenn eine Aufsichtsbehörde oder ein interner Prüfer fragt, auf welcher Datenbasis eine Handelsentscheidung getroffen wurde, liefert die bitemporale Historie eine lückenlose, manipulationsresistente Antwort: Sie zeigt, welcher Wert zum Entscheidungszeitpunkt im System stand. Diese Prüffähigkeit ist in vielen institutionellen Kontexten keine Kür, sondern Anforderung.
Abgrenzung zu Point-in-Time.
Bitemporale Modellierung und Point-in-Time-Daten werden oft synonym verwendet, sind aber nicht dasselbe — die Beziehung lohnt eine klare Trennung. Point-in-Time ist die Anforderung: Ein Backtest darf nur Information nutzen, die zum jeweiligen Zeitpunkt bekannt war. Bitemporalität ist die technische Umsetzung, die diese Anforderung sauber und allgemein erfüllt.
Man kann Point-in-Time auch mit simpleren Mitteln erreichen — etwa durch tägliche, unveränderliche Snapshots des Datenstands. Das ist leichtgewichtiger, hat aber Grenzen: Snapshots sind grobkörnig (man sieht den Stand nur zu den Snapshot-Zeitpunkten), speicherintensiv bei feiner Granularität und unhandlich, wenn man gezielt einzelne Korrekturen nachvollziehen will. Bitemporale Tabellen sind feiner, abfragefreundlicher und kompakter, dafür im Modell komplexer.
Die Faustregel: Wer nur leakagefreie Backtests braucht, kommt oft mit Snapshots aus. Wer zusätzlich Reproduzierbarkeit, Revisions-Analyse und Audit-Fähigkeit benötigt — typisch im institutionellen oder regulierten Umfeld — fährt mit dem vollen bitemporalen Modell besser.
Aufwand, Fallstricke und Performance.
Der Preis der Bitemporalität ist Komplexität — und die trifft an mehreren Stellen. Die Abfragen werden anspruchsvoller: Jede Query muss beide Zeitachsen korrekt einschränken, und ein vergessenes tx_to IS NULL oder eine falsche Intervalllogik liefert leise falsche Ergebnisse. Bitemporale Queries sind eine bekannte Quelle subtiler Fehler, gerade weil sie plausibel aussehen, wenn sie falsch sind.
Auch die Performance braucht Aufmerksamkeit. Weil die Tabellen nur wachsen, werden Indizes auf den vier Zeitstempel-Spalten und durchdachtes Partitionieren wichtig, sonst werden As-of-Queries auf großen Historien langsam. Moderne Datenbanken bieten teils native Unterstützung für temporale Tabellen, was die Implementierung erleichtert, das konzeptionelle Verständnis aber nicht ersetzt.
Ein häufiger Fallstrick ist der Late-Arriving-Datensatz: Daten, die erst spät eintreffen, aber für eine zurückliegende valid time gelten. Das bitemporale Modell handhabt das korrekt — neue Zeile mit aktueller transaction time, vergangener valid time — aber die Pipeline drumherum muss diesen Fall bewusst behandeln, sonst landen Werte mit falschen Zeitstempeln im System und unterlaufen die ganze Disziplin.
Wann sich der volle Apparat lohnt.
Bitemporale Modellierung ist kein Standard für jedes Datenprojekt, sondern eine bewusste Entscheidung mit klarem Anwendungsprofil. Sie lohnt sich, wenn mehrere der folgenden Bedingungen zutreffen:
- Stark revidierte Daten: Fundamentaldaten, Analystenschätzungen, Makrozahlen — überall, wo nachträgliche Korrekturen die Regel sind, ist der Nutzen am größten.
- Reproduzierbarkeitsanspruch: Wenn Backtest-Ergebnisse später bit-genau nachstellbar sein müssen, führt am vollen Modell kaum ein Weg vorbei.
- Regulatorische oder institutionelle Prüfpflicht: Wo Entscheidungen auditierbar dokumentiert sein müssen, ist die lückenlose Historie eine Anforderung, kein Komfort.
Umgekehrt ist der volle Apparat überdimensioniert für reine Preis- und Volumendaten ohne nennenswerte Revisionen, für kleine Forschungsprototypen oder für Kontexte, in denen tägliche Snapshots ausreichen. Hier verkompliziert Bitemporalität das Datenmodell, ohne proportionalen Nutzen zu liefern.
Die ehrliche Einordnung lautet: Bitemporalität ist ein mächtiges, aber spezialisiertes Werkzeug. Richtig eingesetzt schafft sie eine Datengrundlage, die leakagefrei, reproduzierbar und prüffähig ist — die Eigenschaften, die belastbare quantitative Forschung von hübschen, aber nicht nachstellbaren Ergebnissen unterscheiden. Falsch oder zu früh eingesetzt, wird sie zur Komplexitätsfalle. Die Kunst liegt darin, den Aufwand am tatsächlichen Bedarf auszurichten.
Sie wollen Backtest-Ergebnisse reproduzierbar machen und Datenrevisionen sauber nachvollziehen, statt sie still zu überschreiben? Unverbindlich anfragen — wir entwerfen ein bitemporales Datenmodell für Ihre revisionsanfälligen Quellen, richten saubere As-of-Queries ein und schaffen so eine Grundlage, auf der Ihre Forschung leakagefrei, reproduzierbar und prüffähig wird.