Flexible Behandlung von Slowly Changing Dimensions mit SQL Server
Langsamer Wandel
Sollen beim Data Warehousing die Änderungen an den Dimensionstabellen verfolgbar bleiben, kommen entweder Bordmittel des Datenbanksystems zum Einsatz – oder der hier vorgestellte Algorithmus. Er ist zudem nicht auf die Microsoft-Datenbank beschränkt.
Wer beim Data Warehousing auf die typischen Schwierigkeiten beim Aktualisieren der Slowly Changing Dimensions (SCDs) trifft, muss sich nach Auswegen umsehen. Dieser Artikel zeigt, wie weit dabei die Standardhilfsmittel des Microsoft SQL Server reichen und wo deren Grenzen liegen. Ein neuer, generischer Algorithmus in T-SQL behebt die Schwierigkeiten beim Behandeln der SCDs, und seine Logik lässt sich zudem mit kleineren Modifikationen in anderen Datenbanksystemen einsetzen.
In analytischen Systemen – etwa in den Bereichen Data Warehousing oder Online Analytical Processing (OLAP) – wird in der Regel eine spezielle denormalisierte Organisation der Daten verwendet. Im einfachsten Fall kommt das Star-Schema zum Einsatz, in der Praxis ist jedoch öfter das erweiterte Snowflake-Schema anzutreffen. Die Tabelle mit den Kennzahlen heißt Faktentabelle und befindet sich im Zentrum des Schemas. Sie ist von mehreren Dimensionstabellen umgeben, die die Beschreibungen der Fakten liefern und ihnen Bedeutung verleihen, sozusagen die Stammdaten zu den Werten.
Die Datenhaltung ist unkompliziert, wenn die Daten in der Dimensionstabelle statisch sind. Das ist des Öfteren der Fall bei der Zeitdimension, die üblicherweise nur einen Zeitstrahl in Form der einzelnen Tage enthält. Hier müssen nur gelegentlich neue Datensätze hinzugefügt werden.
Uneingeschränkte historische Sicht
Andere Dimensionen wie Kunden und Produkte unterliegen einem ständigen Veränderungsprozess. Um dies korrekt abbilden zu können, wurden folgende typische Arten der SCDs definiert:
– Typ 1: Die Daten (Attribute) des Dimensionsdatensatzes werden überschrieben. Einfach zu realisieren, es ist aber keine historische Betrachtung möglich (Abbildung 1).
– Typ 2: Es wird ein neuer Datensatz angelegt mit demselben Business Key (auch Natural Key oder sprechender Schlüssel) und neuen Attributen. Hierbei werden die Gültigkeitszeiträume des alten und des neuen Datensatzes korrigiert oder gesetzt. In diesem Fall ist immer eine uneingeschränkte historische Betrachtung möglich (Abbildung 2).
Man sieht, dass der Gültigkeitszeitraum eines Datensatzes als [Gültig von; Gültig bis) definiert wird. Dieses Beispiel zeigt allerdings nur die einfachste Variante: Wenn ein einziger, unbegrenzt gültiger Datensatz gesplittet wurde. Bei mehreren Dimensionseinträgen, die zum gleichen Business Key gehören, muss man die Position des neuen Datensatzes relativ zu den vorhandenen ermitteln, damit die „Gültig von“- und „Gültig bis“-Attribute sowohl für den neuen Eintrag korrekt ermittelt werden können als auch in den benachbarten Einträgen eine entsprechende Anpassung stattfinden kann.
Eine weitere Schwierigkeit bei Typ-2-SCDs ist das Anpassen der Dimensionsreferenzen in der Faktentabelle. Angenommen, alle Faktendatensätze zeigen auf einen einzigen Dimensionsdatensatz, der im Intervall (-unendlich; +unendlich) gültig war. Nun wurde der Dimensionsdatensatz im Zuge der Aktualisierung gesplittet und es liegen drei Datensätze für folgende Intervalle vor: (-unendlich; 01.01.2016), [01.01.2016; 17.01.2017) und [17.01.2016; +unendlich). Deshalb müssen die Faktendatensätze, die sich – über eine weitere Zeitdimension gesehen – im Zeitraum [01.01.2016; 17.01.2017) befinden, auf den Warehouse Key des neu hinzugefügten Dimensionsdatensatzes verweisen.
– Typ 3: Eine eingeschränkte Historie wird innerhalb desselben Datensatzes gespeichert, was zusätzliche Felder in der Dimensionstabelle erfordert. Eine historische Betrachtung ist begrenzt möglich, allerdings lassen sich die Daten per SQL weder einfach verwalten noch abfragen. Diese Technik findet in einigen sehr speziellen Fällen Verwendung, ist jedoch in der Praxis selten zu sehen. Die Behandlung einer Typ-3-Dimension ist vereinfacht in Abbildung 3 dargestellt. Es können zusätzliche Felder vorhanden sein, in denen man den Gültigkeitszeitstempel des jeweiligen Wertes speichert.
Des Öfteren sind in der Praxis Dimensionen vom Typ 1 in Reinform oder in einer Mischung aus Typ 1 und Typ 2 anzutreffen – das heißt, die Historie ist wichtig, aber nicht alle Attribute müssen historisiert werden. In diesem Fall unterscheidet man die Attribute des Dimensionseintrags auf drei Arten:
– Fixed: Attribute nach Business-Logik ändern sich nicht und dürfen nicht geändert werden; solche Attribute sind selten zu sehen.
– Changing: Die Attribute können sich ändern, die Änderung muss aber auf alle vorhandenen Datensätze desselben Business Keys angewendet werden (vergleichbar mit Typ 1).
– Historical: Für diese Attribute muss eine Historisierung stattfinden, das heißt, es muss ein neuer Datensatz angelegt werden.
Als Beispiel dient ein Star-Schema, das die Kennzahlen der Bestellungen unter anderem hinsichtlich Produkte und Zeit darstellt (Abbildung 4). Aus dem Schema kann man folgende Schlüsse ziehen: Die ProductID ändert sich nicht und ist Business Key; die Benennung des Produkts (Name) sollte einheitlich über die Zeit lauten; Herstellungsmaterial, Lagerhalle und Regal (Material, Hall, Shelf) sollten historisch vorliegen.
Hilfe bei Transformationen
Um das Beladen (Load) einer solchen Dimension zu ermöglichen, bietet der SQL Server im ETL-Bereich (Extract Transform Load) – hier SQL Server Integration Services genannt (SSIS) – ein Hilfsmittel an: die Slowly-Changing-Dimension-Transformation in einem Data-Flow-Task. Diese Transformation übernimmt ein SCD-Wizard, der die wesentlichen Parameter erfragt und darauf basierend einen entsprechenden, aus mehreren Komponenten bestehenden Workflow erzeugt.