Historisierte Dimension auf den Kopf gestellt

Jeder, der eine Standard SCD „Slowly Changing Dimensions“ Komponente von ETL Tools nutzt, kennt die Vorgehensweise bei Typ2 mit der wohl am meisten genutzten Form der Historisierung.

Die Tabelle ist wie folgt aufgebaut:

Stellvertreter Schlüssel:

Hierbei handelt es sich um einen „Surrogate Key“, ein eindeutiger Wert, der sich bei jedem Hinzufügen eines neuen Datensatzes erhöht. Dieses Feld ist der Primärschlüssel.

Geschäftsschlüssel:

Dieses Feld einhält einen eindeutigen Wert aus dem Quellsystem, mit dem die Entität im Quellsystem eindeutig identifiziert werden kann.

Feld 1-n:

Dies sind Attribute der Entität, bei deren Änderung ein neuer historischer Satz in der Dimensionstabelle anzulegen ist.

Gültig Ab und Gültig Bis:

Diese Datumsangaben begrenzen den Gültigkeitszeitraum eines Datensatzes. Der Wert „31.12.2999“ oder ein anderes Datum jenseits der erwarteten Lebensdauer des DWH steht hier für die nicht begrenzte Gültigkeit.

Historischer Stellvertreter Schlüssel:

Dieses Feld klammert die verschiedenen Datensätze einer Entität. Beim ersten Satz entspricht es dem Stellvertreter Schlüssel. Es hat im Allgemeinen eine 1:1-Beziehung zum Geschäftsschlüssel und ist wie dieser nur in der Kombination mit dem Gültigkeitszeitraum eindeutig.

Bei einer Änderung der Entität wird der aktuell gültige Satz terminiert, also das Gültig Bis-Datum auf den aktuellen Zeitpunkt gesetzt. Dann wird ein neuer Satz angelegt, dessen Gültigkeit sich anschließt. Dieser erhält einen neuen Stellvertreter-Schlüssel und wird durch den historischen Stellvertreter mit den anderen Sätzen verbunden.
Referenzen aus den Faktentabellen verwenden den historischen Stellvertreter. Bei der Selektion für Auswertungen o.ä. muss dann zusätzlich auf den Gültigkeitszeitraum eingeschränkt werden („Buchungsdatum between Gültig ab and Gültig Bis“). Den aktuellen Satz erhält man mit „Gültig Bis >= sysdate“ oder „Gültig Bis = 31.12.2999“.

Aus Datenbank- und Anwendungssicht hat dieses übliche Vorgehen bei der Historisierung folgende Nachteile:

• Unnötige Logik in den Abfragen - Im Reporting wird in den allermeisten Fällen der aktuelle Datensatz (as is-Sicht) benötigt. Die durch die Historisierung bedingte, zusätzliche Einschränkung ist fachlich nicht begründet und macht den Zugriff geringfügig langsamer.

• Erhöhter Aufwand bei nachträglicher Historisierung - Wenn im Zuge einer Weiterentwicklung Dimensionen nachträglich historisiert werden sollen, so beschränkt sich der Aufwand nicht auf die Laderoutinen für die Dimensionstabelle. Darüber hinaus sind alle Abfragen auf diese Tabelle um die oben erwähnte zeitliche Einschränkung zu erweitern. Dies schränkt die Wartbarkeit erheblich ein.

• Mangelnde Sicherstellung der referentiellen Integrität - Zur Gewährleistung einer hohen Datenqualität ist es sinnvoll, die referentielle Integrität durch Constraints auf der Datenbank abzusichern. Ein entsprechendes referentielles Constraint auf den historischen Stellvertreter ist jedoch nicht möglich, da das Ziel eindeutig sein muss. Aus diesem Grund wird häufig ein Constraint auf den Stellvertreter-Schlüssel gesetzt. Dieses ist zwar anfänglich problemlos, wird aber unhaltbar, wenn im Laufe der Zeit alte Daten aus dem DWH gelöscht werden sollen. Es bleibt dann nur, auf referentielle Constraints zu verzichten oder aber die Altdaten in der Datenbank zu lassen. Das Letztere wirkt sich negativ auf die Kosten und die Performanz aus.

Eleganter ist eine alternative Vorgehensweise bei der Historisierung. Ändert sich eine Entität, so wird der aktuelle Datensatz der Dimension mit den alten Werten, aber einem neuen Stellvertreter-Schlüssel sowie einer entsprechenden Terminierung kopiert. Der aktuelle Satz wird anschließend mit den geänderten Werten und einem neuen Gültig Ab-Datum überschrieben.

Damit ergibt sich für das einleitende Beispiel folgender Datenstand:

Bei dieser Variante bleibt der erste Datensatz eines Dimensionseintrags immer gültig. Referenzen aus den Fakten können einfach über den Stellvertreter-Schlüssel erfolgen, wenn aktuelle Daten gefragt sind. Der Zugriff auf historische Daten erfolgt unverändert über den historischen Stellvertreter und den Gültigkeitszeitraum. Dies ist aber nur dort notwendig, wo explizit historische Datenstände gefordert sind.

Da der Satz mit dem ursprünglichen Primärschlüssel immer der aktuelle Datensatz ist und daher auch bei Datenbereinigungen erhalten bleibt, kann problemlos ein referentielles Constraint in der Datenbank definiert werden.

Die Implementierung ist in den meisten ETL Tools durch Konfigurieren der SCD Komponente oder durch Nutzung einer CDC „Change Data Capture“ Komponente einfach umzusetzen. Es ist allerdings bei aktivierten referentiellen Constraints darauf zu achten, dass keinesfalls die Stellvertreter-Schlüssel getauscht werden dürfen. Wird der Primärschlüssel eines Datensatzes in der Dimension geändert, so löst dies einen Scan der referenzierenden Tabellen (oder der passenden Indices) aus.

Bei dieser Variante bleibt der erste Datensatz eines Dimensionseintrags immer gültig. Referenzen aus den Fakten können einfach über den Stellvertreter-Schlüssel erfolgen, wenn aktuelle Daten gefragt sind. Der Zugriff auf historische Daten erfolgt unverändert über den historischen Stellvertreter und den Gültigkeitszeitraum. Dies ist aber nur dort notwendig, wo explizit historische Datenstände gefordert sind.
Da der Satz mit dem ursprünglichen Primärschlüssel immer der aktuelle Datensatz ist und daher auch bei Datenbereinigungen erhalten bleibt, kann problemlos ein referentielles Constraint in der Datenbank definiert werden.

Die Implementierung ist in den meisten ETL Tools durch Konfigurieren der SCD Komponente oder durch Nutzung einer CDC „Change Data Capture“ Komponente einfach umzusetzen. Es ist allerdings bei aktivierten referentiellen Constraints darauf zu achten, dass keinesfalls die Stellvertreter-Schlüssel getauscht werden dürfen. Wird der Primärschlüssel eines Datensatzes in der Dimension geändert, so löst dies einen Scan der referenzierenden Tabellen (oder der passenden Indices) aus.