Fachbeitrag · Wirtschaftsinformatik ·
Historisierte Dimensionen: Warum derselbe Kunde mehrere technische Schlüssel haben kann
Ein Kunde wechselt die Vertriebsregion. Soll ein älterer Auftrag weiterhin zur damaligen Region gehören oder nach heutiger Zuständigkeit ausgewertet werden? Beide Sichtweisen können sinnvoll sein. Sie benötigen jedoch unterschiedliche Datenbeziehungen. Eine historisierte Dimension hält mehrere gültige Versionen eines Geschäftspartners vor, statt frühere Merkmale bei jeder Änderung einfach zu überschreiben.
Geschäftliche Identität und Version unterscheiden
Der fachliche Kundenschlüssel bleibt über den Regionswechsel hinweg gleich. Für jede historische Merkmalsversion wird zusätzlich ein eigener technischer Schlüssel geführt. Ein Gültigkeitsintervall beschreibt, zu welchem Zeitraum die Version gehört. Ein Auftrag kann dann auf die zum Geschäftsereignis passende Version verweisen. Das Verfahren wird häufig als langsam veränderliche Dimension vom Typ 2 bezeichnet. Sein entscheidender Nutzen liegt nicht in zusätzlichen Zeilen, sondern darin, dass frühere Zuordnungen reproduzierbar erhalten bleiben und spätere Berichte dieselbe fachliche Geschichte nachvollziehen können.
Zwei Sichtweisen im Beispiel
Ein Kunde gehört bis Ende März zur Region Nord und ab April zur Region Süd. Ein Auftrag aus Februar bleibt bei historischer Betrachtung Nord zugeordnet. Ein Bericht nach aktueller Betreuung kann denselben Auftrag dagegen Süd zuschlagen. Diese Ergebnisse widersprechen sich nicht, solange die gewählte Sicht ausdrücklich benannt ist. Fehler entstehen, wenn ein Bericht historische Versionsschlüssel verwendet, ein zweiter nur den aktuellen Kundenstammsatz verbindet und beide anschließend als identische Regionsauswertung verglichen werden.
Zeitliche Zuordnung absichern
Gültigkeitsintervalle dürfen für dieselbe Identität nicht unbeabsichtigt überlappen. Beim Übergang muss klar sein, ob ein Endzeitpunkt eingeschlossen oder ausgeschlossen ist. Spät eintreffende Aufträge benötigen die Version zum Ereigniszeitpunkt, nicht zwangsläufig die beim Import aktuelle Version. Rückwirkend korrigierte Stammdaten erfordern ebenfalls eine Regel: Wird eine fehlerhafte Geschichte berichtigt oder eine damals tatsächlich gültige Zuordnung dokumentiert? Diese fachliche Entscheidung sollte vor der technischen Ladeverarbeitung getroffen und mit gezielten Grenzfällen getestet werden.
Historie gezielt einsetzen
Nicht jedes Attribut braucht unbegrenzt viele Versionen. Häufig geänderte technische Felder können eine Dimension unnötig vergrößern, ohne Berichte zu verbessern. Fachbereiche sollten daher festlegen, welche Veränderungen für historische Fragen relevant sind. Ein kleiner Prüfsatz mit Regionswechsel, verspätetem Auftrag und korrigiertem Stichtag macht die Auswirkungen sichtbar. Ein zusätzliches aktuelles Kennzeichen erleichtert heutige Sichten, ersetzt aber keine sauberen Intervalle. Verlässliche Historisierung setzt eine gemeinsame Bedeutung von Identität, Zeitpunkt und Berichtsperspektive voraus, statt lediglich alle Änderungen unterschiedslos zu protokollieren.
Bei der Abnahme sollten derselbe Kunde vor und nach dem Wechsel sowie ein Auftrag genau am Übergangstag betrachtet werden. Diese wenigen Fälle prüfen die Zeitgrenzen oft wirkungsvoller als eine große Liste zufällig ausgewählter Stammdatensätze.
Technical article · Business informatics ·
Historical dimensions: Why one customer can have several technical keys
A customer moves to another sales region. Should an older order remain assigned to the region responsible at the time, or be reported under today's ownership? Both views can be useful, but they require different data relationships. A historical dimension retains several valid versions of a business entity instead of simply overwriting earlier attributes whenever something changes.
Separate business identity from version
The business customer identifier remains the same across the regional change. Each historical attribute version receives an additional technical key. A validity interval describes the period to which the version belongs. An order can then reference the version appropriate to its business event. This approach is often called a type 2 slowly changing dimension. Its value is not merely the creation of extra rows: it preserves earlier assignments reproducibly so later reports can reconstruct the same business history without depending on today's customer attributes.
Two legitimate views in one example
A customer belongs to region North until the end of March and region South from April onwards. Under a historical view, a February order remains in North. A report based on current account ownership can assign that same order to South. These results are not contradictory when their perspectives are explicit. Problems arise when one report uses historical version keys while another joins only the current customer record, and the two are then compared as though they represented the same regional analysis.
Protect temporal assignment
Validity intervals for the same identity must not overlap unintentionally. Boundary rules need to specify whether an end timestamp is included or excluded. Late-arriving orders require the version corresponding to the event time, not necessarily the version current at import. Retrospectively corrected master data also needs a policy: is an erroneous history being corrected, or is an assignment that genuinely applied at the time being documented? Make this business decision before implementing the load process, and test it with deliberate boundary cases.
Use history selectively
Not every attribute requires an unlimited sequence of versions. Frequently changing technical fields can enlarge a dimension without improving reporting. Business owners should identify which changes matter for historical questions. A small test dataset with a region change, a late order and a corrected reference date makes the consequences visible. An additional current-row indicator can simplify present-day views, but it does not replace sound intervals. Reliable history requires a shared meaning for identity, time and reporting perspective rather than recording every change indiscriminately and assuming that the resulting extra rows will explain themselves.
Acceptance tests should include the same customer before and after the change, plus an order exactly at the transition boundary. These few cases often test temporal rules more effectively than a long list of randomly selected customer records.