Wer Daten modelliert, landet früher oder später bei einer einfachen, aber folgenreichen Frage: Wann gilt ein Wert eigentlich? In der aktuellen Podcastfolge geht es genau um diesen Punkt, entlang von Slowly Changing Dimensions und der Frage, wie sich Veränderung fachlich sauber abbilden lässt. Nicht jeder Datensatz ist nur ein Datensatz. Manche Informationen verändern sich langsam, manche müssen rückwirkend verstanden werden, manche sollen nur den aktuellen Stand zeigen. Genau an dieser Stelle wird aus Modellierung eine Zeitfrage.
Zeit ist eine Modellierungsfrage
Die naheliegende Annahme lautet oft: Wenn sich ein Wert ändert, wird der alte Wert einfach überschrieben. Das ist die Logik des Slowly Changing Dimension Typ 1. Sie ist einfach, gut verständlich und in vielen Fällen völlig ausreichend. Genau darin liegt ihre Stärke. Wer nur den aktuellen Zustand braucht, muss keine Historie mitschleppen, die später niemand mehr sauber erklären kann.
Aber nicht jede Veränderung ist gleich zu behandeln. Sobald die Entwicklung eines Werts selbst fachlich relevant wird, reicht das Überschreiben nicht mehr. Dann braucht das Modell einen Gültigkeitsbereich, also die Fähigkeit, einen Wert einem Zeitraum zuzuordnen. Das ist die Logik von Typ 2. Der Datensatz bleibt nicht allein wegen seines Inhalts unterscheidbar, sondern auch wegen seiner zeitlichen Einordnung. Das Modell wird damit präziser, aber auch komplexer.
Typ 3 liegt dazwischen. Hier wird nicht jeder historische Zustand als eigener Datensatz geführt, sondern ein vorheriger Wert zusätzlich neben dem aktuellen Wert abgelegt. Das ist pragmatischer als Typ 2, aber auch begrenzter. Die historische Tiefe bleibt klein. Die Struktur wird breiter. Und auch hier zeigt sich wieder derselbe Grundsatz: Nicht die Theorie entscheidet, sondern der Zweck.
Historie ist nicht gleich Historie
Es gibt nicht nur die fachliche Gültigkeit einer Änderung, sondern auch ihre systemische Gültigkeit. Ein Kunde kann in der Realität längst umgezogen sein, während das Quellsystem den neuen Wohnort erst später erhält. Dann liegt die fachliche Wahrheit vor dem System, das sie abbildet. Oder anders gesagt: Die Wirklichkeit hat sich schon verändert, aber die Plattform noch nicht.
Genau hier wird Historisierung heikel. Wenn das BI-System Historie selbst erzeugt, trägt es auch das Risiko, den Zeitverlauf falsch oder unvollständig zu rekonstruieren. Wenn Historie dagegen möglichst nah an der Quelle entsteht, steigt die Chance, dass sie später auch in anderen Systemen wiederverwendbar bleibt. Das ist kein technischer Luxus, sondern eine Frage der Belastbarkeit.
Darum ist es klüger, Historisierung nicht vorschnell in die BI-Plattform zu verlagern. Wer die Quelle historisieren kann, sollte das tun. Wer Historie erst im Zielsystem baut, macht sich abhängig von der Qualität des Ladeprozesses und von allen Lücken, die unterwegs entstehen können. Das Modell kann nur so gut sein wie seine Zeitlogik.
Verschiedene Sichtweisen brauchen einen klaren Zweck
Besonders interessant wird es dort, wo unterschiedliche Sichtweisen auf dieselben Daten sichtbar werden. Eine Ist-Sicht zeigt den aktuellen Stand. Eine Vergangenheitsansicht zeigt, wie die Welt zu einem bestimmten Zeitpunkt aussah. Eine As-Reported-Sicht friert den Stand ein, wie er damals gemeldet wurde. Eine As-Planned- oder Forecast-Sicht vergleicht die Realität mit dem Zustand, auf den ursprünglich geplant wurde.
Diese Unterscheidungen sind nicht bloß Varianten desselben Sachverhalts. Sie beantworten unterschiedliche Fragen. Wer aktuelle Regionen sehen will, braucht eine andere Sicht als jemand, der eine frühere Planung gegen die heutige Wirklichkeit prüfen will. Wer rückwirkend verstehen möchte, welchen Umsatz ein Kunde zu einem bestimmten Zeitpunkt in einer bestimmten Region erzeugt hat, braucht wieder eine andere Modellierung.
Die eigentliche Klarstellung lautet deshalb: Eine Datenplattform muss nicht nur Werte speichern, sondern auch den Bezugsrahmen, in dem diese Werte gelten. Ohne diesen Rahmen entstehen Berichte, die korrekt aussehen, aber semantisch unsicher bleiben.
Typ 1 ist nicht schwach, sondern oft vernünftig
Ein starker Punkt der Argumentation ist ihre Pragmatik. Typ 2 ist nicht automatisch besser als Typ 1. Mehr Historie bedeutet nicht automatisch mehr Erkenntnis. Oft wird das Modell nur schwerer zu verstehen und schwerer zu warten. Genau deshalb ist die Empfehlung so nachvollziehbar, zunächst mit Typ 1 zu starten und Historisierung nur dann weiter auszubauen, wenn der fachliche Bedarf es wirklich verlangt.
Das ist eine wichtige Gegenposition zu Modellierungsreflexen, die jede potenzielle Veränderung sofort maximal absichern wollen. In der Praxis hilft oft zuerst die einfache, lesbare Lösung. Sie hält das Modell verständlich, reduziert Pflegeaufwand und macht die fachliche Kommunikation leichter. Historie sollte nicht entstehen, weil sie technisch möglich ist, sondern weil sie analytisch gebraucht wird.
Auch die Grenze zwischen Vorsystem und BI-System gehört in diesen Zusammenhang. Wenn eine Information bereits sauber historisiert aus der Quelle kommt, kann das analytische Modell darauf aufbauen. Wenn BI die Historie selbst herstellen muss, übernimmt es Verantwortung, die es fachlich nicht immer sauber tragen kann. Darum ist der zentrale Gedanke so stark: Historie ist am stabilsten, wenn sie dort entsteht, wo die fachliche Wahrheit am nächsten liegt.
Was das Modell wirklich leisten soll
Am Ende geht es nicht um Typ-Nummern, sondern um Klarheit. Ein gutes Modell muss beantworten können, ob es den aktuellen Zustand, den damaligen Zustand oder einen gemeldeten Zustand zeigt. Es muss unterscheiden können zwischen Realität, Systemstand und Berichtssicht. Und es muss entscheiden, ob die Zeitlogik im Modell selbst entstehen soll oder besser aus der Quelle kommt.
Damit wird Slowly Changing Dimension zu mehr als einem technischen Begriff. Es wird zu einem Prüfstein für Informationsarchitektur. Wer Zeit nur als Zusatz versteht, baut Modelle, die später schwer zu erklären sind. Wer Zeit als Teil der Bedeutung versteht, baut Modelle, die Entscheidungen verlässlicher machen.
Die ruhigste Zuspitzung lautet deshalb: Nicht jede Änderung muss historisiert werden. Aber jede Historisierung braucht einen klaren Zweck. Und je näher sie an der Quelle bleibt, desto weniger muss das BI-System die Vergangenheit erraten.
🎧 Die komplette Folge findest du im thinkBI Podcast.
Musik: Great Podcast Intro (short & long) von Lundstroem
Quelle: freemusicarchive.org (Creative Commons) – https://freemusicarchive.org/music/lundstroem/songs-for-leona/great-podcast-intro-both-short-and-long-version-included/
