Jörg Menker

Historisierung ist eine Methode, mit der Änderungen an Daten nachvollziehbar gemacht werden können. Es gibt viele verschiedene Historisierungsformen, von denen hier nur die vollständige Historisierung betrachtet werden soll, die Ralph Kimball als Slowly Changing Dimensions Typ 2 (SCD 2) bezeichnet und bei der jede Version mit einem gültig von und gültig bis gekennzeichnet wird. Den Begriff SCD 2 verwende ich im weiteren Verlauf dieses Beitrags nicht mehr, weil das Verfahren auf beliebige Tabellen angewendet werden kann und nicht nur auf Dimensionen. Wie man ein solches Verfahren technisch umsetzt ist hinlänglich bekannt und wird daher an dieser Stelle nicht weiter repetiert.

Den Vorteil einer lückenlosen Historie erkauft man sich jedoch mit größerer Komplexität, insbesondere bei der Datenbewirtschaftung, die im Normalfall aber gut handhabbar ist. Es gibt jedoch ein paar Punkte, die zu beachten sind:

  1. Man sollte nach Möglichkeit die Historisierung selbst durchführen und sich nicht auf die Historisierung von Quellsystemen verlassen.
  2. Bei Strukturänderungen an historisierten Tabellen muss man sich der Herausforderungen, die sich daraus ergeben, bewusst sein und entsprechend reagieren.
  3. Historisierung führt in Verbindung mit referenzierten Tabellen zu neuen Versionen, wenn sich in den referenzierten Tabellen etwas ändert – die Zeitscheiben werden so immer kleiner.

Ad 1.:

Manche Quellsysteme historisieren selbst. Dann kann man (zumindest theoretisch) die Versionen übernehmen. Manchmal hat man dazu auch gar keine Alternative, weil man selbst i.d.R. erst ab „jetzt“ historisieren kann und nicht mehr rückwärts in die Vergangenheit hinein oder weil es schon zukünftige Versionen gibt, die in den Daten berücksichtigt werden müssen. Wenn man aber die Wahl hat tut man gut daran, die Historisierung selbst zu übernehmen, denn dann weiß man, dass sie richtig ist. Auch wenn die Quellsysteme richtig historisieren kann das Ergebnis für uns falsch sein.

Dazu ein kleines Beispiel:

Eine historisierte Quellsystemtabelle mit mehreren hundert Spalten (keine Seltenheit bei ERP-Systemen) wird historisiert. Wir verwenden eine Handvoll Spalten aus dieser Tabelle für eine ebenfalls historisierte Dimensionstabelle (SCD2). Wenn sich in den hunderten Spalten der Quelltabelle irgendwo etwas ändert, wird korrekt eine neue Version mit neuem gültig von und gültig bis angelegt. Wenn die Änderung in Spalten erfolgt ist, die für unsere Dimensionstabelle irrelevant sind, bekommen wir aus Sicht unserer Dimension Dubletten in Form von genau gleichen Datensätzen mit unterschiedlichen gültig-von- und gültig-bis-Datumsangaben (obere Tabelle):

historisierung_selbst

 

Aus Sicht unserer Dimensionstabelle gibt es nur eine Version (untere Tabelle), die vom 01.01.2004 an gültig ist. Zwar kann man das Minimum des Gültig-von-Datums und das Maximum des Gültig-bis-Datums selektieren, aber das muss man dann auch tun und eventuelle Lücken in der Gültigkeit würden dadurch zugekleistert. Besser wäre es hier also die Quelltabellendaten mit den vorhandenen Daten aus der Dimension zu vergleichen und dann selbst zu historisieren.

Ad 2.:

Wenn sich Strukturänderungen (z.B. neue Spalten) an historisierten Tabellen einstellen, dann wirken sich diese eigentlich auch auf die Vergangenheit aus. Daher ändern sich rückwirkend die Gültigkeitszeiträume von Versionen und neue Zwischenversionen entstehen, wodurch dann Fakten plötzlich an falschen Dimensionseinträgen hängen und umgeschlüsselt werden müssen. In der Praxis ist das oft nicht mit vertretbarem Aufwand machbar. Deswegen macht man es sich gerne einfach und lässt die neuen Spalten für nicht mehr aktuelle Versionen einfach leer oder projeziert den aktuellen Stand in die Vergangenheit zurück und berücksichtigt die neuen Spalten ab „jetzt“. Eine rückwirkende Neuhistorisierung scheitert aber häufig schon daran, dass man für die Vergangenheit keine Daten mehr hat, anhand derer eine solche rückwirkende Neuhistorisierung, die mit den gängigen ETL-Tools auch nicht machbar wäre, erfolgen könnte.

Ad 3.:

Stehen historisierte Tabellen in Beziehungen mit anderen historisierten Tabellen, so ergeben sich ähnlich wie bei Strukturänderungen neue, zeitlich granularere Versionen. Für die Datenbewirtschaftung ist es eine Herausforderung, die Gültigkeitszeiträume aus unterschiedlichen Tabellen mit einander zu verschneiden und die korrekten Gültigkeiten zu ermitteln.

Einfaches Beispiel:

Es gibt Sachbearbeiter, die einem Team zugeordnet sind. Die Teams wiederum gehören zu einem Teambereich:

historisierung_versionsgranularität_1

Wenn sich in diesem einfachen Beispiel die Bezeichnung des Teambereichs ändert, aus Teambereich 1 wird Innendienst, hat das Auswirkungen auf alle darunterliegenden Ebenen, und dort entstehen neue Versionen, obwohl sich dort eigentlich nichts geändert hat. Der Sachbearbeiter Müller (4711) gehört noch immer zum gleichen Team (Team 1), aber das Team hängt nun an einer neuen Version des Teambereichs, weswegen es auch eine neue Version des Teams gibt, zu dem nun auch eine neue Version des Sachbearbeiters Müller (4711) gehört:

historisierung_versionsgranularität_2

Wie man die zeitlichen Gültigkeiten richtig schneidet erläutert ein lesenswerter Blogbeitrag des Kollegen Hilmar Buchta.