Der OLAP-Ansatz ist für die Entscheidungsunterstützung ausgelegt. Dabei sind historische, aggregierte und konsolidierte Daten viel wichtiger als die einzelnen detaillierten Datensätze. Meist sind diese Daten über verschieden lange historische Zeiträume vorhanden. Da also in einem Data-Warehouse (DWH) üblicherweise historische Daten verwaltet werden, sind beispielsweise bei Änderungen der Zuordnung von Kunden zu Kundengruppen in den Datenquellen in Form von periodischen “Snapshots” im DWH zu speichern. In anderen Blog-Beiträgen konnten Sie schon erfahren, wie etwa die historische Betrachtung von Bestandswerten, die als Bewegungsdaten gelten, implementiert werden kann. In diesem Blogbeitrag stellen wir Ihnen Methoden zur Historisierung von Stammdaten vor.

Implementierungsansätze

Betrachten wir einmal das Verhalten von “Kunde” zu “Kundengruppe”. Die Kundenstammdaten werden z. B. täglich mit dem üblichen Import-Konzept (Full-Load) geladen. Bei allen weiter unten dargestellten Ansätzen muss aber sichergestellt sein, dass die vorhergehenden Zustände im DWH nicht überschrieben werden. Nach der Datenübernahme folgt dann wiederum innerhalb des DWH die Aufbereitung der neuen Daten. Hierzu kann für den täglichen Import z. B. die Tabelle “T_Import_Kunde” dienen. Diese Tabelle wird täglich komplett gelöscht und wieder neugefüllt. Eine zweite Tabelle “T_Import_Kunde_Backup” kann dann für die Historisierung verwendet werden.

Lösung 1: Trennung der Dimensionen

Bei unserer 2-leveligen Kundendimension (Kundengruppe – Kunde) werden durch die Trennung zwei Dimensionen erstellt. Eine Dimension enthält nur die Kundengruppe, die andere nur den Kunden.

Nachteil: Bei der Analyse in DeltaMaster muss der Anwender die korrekte Zuordnung zwischen Kundengruppe/Kunde für den ausgewählten Zeitraum wissen. Bei einer falschen Auswahl in der Sicht werden schlicht keine Daten geliefert.

Lösung 2: Verkettung der Dimensionselemente

Eine andere nicht analysefreundliche Methode wäre die Verkettung der Dimensionselemente der beiden Ebenen. Etwa:
A_0815 (KdGrp_Kdnr)
B_0815 (KdGrp_Kdnr)

Nachteil: Bei dieser Lösung ist faktisch keine Analyse über den Kunden „0815“ möglich. Die Gesamtsumme der Analysewerte für den Kunden „0815“ muss nachträglich gebildet werden.

Lösung 3: Historisieren durch zusätzlichen Schlüssel in den Stammdaten

Bei dieser Methode wird ein sogenannter “Künstlicher” Schlüssel (Surrogatschlüssel) in der Dimensionstabelle und auch in der Fakttabelle erstellt. Bei jeder Änderung wird ein zusätzlicher Datensatz in die entsprechende Dimensionstabelle geschrieben. Dieser Datensatz enthält die neue Zuordnung der Kundengruppe zum Kunden und hebt sich durch den davor eingefügten Schlüssel vom bisherigen Datensatz ab. Die Zuordnung der einzelnen Datensätze zur Fakttabelle wird durch den zusätzlich eingefügten Schlüssel erfolgen, damit bleibt die Eindeutigkeit der Zuordnung Fakttabelle/Dimension gewährleistet.

Abb. 1: T_Import_Kunde

Abb. 2: T_Import_Fakt

Nachteil: Kritisch bei dieser Methode ist das Speichern redundanter Information in allen von der Änderung nicht betroffenen Attributen z. B. der Kundenname und der erhöhte Speicherplatzbedarf. Dennoch wird durch diese Implementierung die Anforderung erfüllt und das Führen einer Historie im DWH ermöglicht.

Lösung 4: Historisieren durch zusätzliche Attribute

Bei dieser Methode werden zwei neue Datenspalten “KdGrp_Alt”, “KdGrp_Aktuell” in der Kundenstammtabelle angelegt.

Abb. 3: T_Import_Kunde

Abb. 4: T_Import_Fakt

Diese Methode garantiert also immer den originären und den aktuellen Zustand.

Nachteil: Die Änderungen zwischen diesen beiden Zuständen werden jedoch nicht festgehalten. Diese Methode stellt sozusagen eine begrenzte Historie zur Verfügung, benötigt dafür aber keine weiteren Fremdschlüssel und erzeugt keine Redundanz.

Fazit

Alle oben vorgestellten Methoden zeigen auf, dass Daten eines DWH historisch und zeitabhängig sind. Es fehlte aber in den obigen Ansätzen jeweils der Faktor “Zeit”.

Optimale Lösung: Historisieren durch Zeitbetrachtung

Der sogenannte temporale Ansatz ist genau auf diese Anforderung zugeschnitten. Bei dieser Methode wird die Zeit nicht mehr nur als eine Dimension sondern zusätzlich in Form von Zeitstempeln “Gültig_Ab” und “Gültig_Bis” in die Stammtabelle implementiert. Zuerst sind alle Kundengruppen bei dem ersten Import der Stammdaten für den jeweiligen Kunden “gültig”: Es wird ein “Gültig_Ab” Datum, etwa der Tag des Imports, in diese Spalte geschrieben. Dieser repräsentiert einen Zustand zu einem gewissen Zeitpunkt, der gültig ist bis zur erneuten Änderung. Die Spalte “Gültig_Bis” kann z. B. den Wert “31.12.9999″ beinhalten. Solange dieser Wert sich nicht ändert, ist die Zuordnung gültig.

Beim täglichen Import findet ein Abgleich zwischen den beiden im Punkt 1 genannten Importtabellen statt. Folgende Schritte werden ausgeführt:

1. Bei allen vorhandenen Kunden in der Backup-Tabelle deren “Gültig_Bis” den Wert “31.12.9999″ aufweist und bei denen das “Gültig_Ab” aus der Importtabelle dem Importdatum entspricht, wird das “Gültig_Bis” der Backup-Tabelle auf “Gültig_Ab” der Importtabelle -1, also gestern, gesetzt.

Der folgende SQL-Code verdeutlicht den erläuterten Schritt:

update  b

set b.Gültig_Bis = convert(smalldatetime, a.Gültig_Ab, 104) -1

from    T_Import_Kunde_Backup b, T_Import_Kunde a

where   b.Kunde_ID = a.Kunde_ID

and b.Gültig_Bis = convert(datetime, '31.12.9999', 104)

and a.Gültig_Ab = convert(datetime, a.ImportDate, 104)

2. Nach der Aktualisierung des Gültig-Bis-Datums im 1. Schritt werden all diese Kunden mit Ihrer neuen Kundengruppenzugehörigkeit, mit neuem Gültig-Ab-Datum und einem “nicht-limitierten” Gültig-Bis-Datum der Backup-Tabelle hinzugefügt.

INSERT INTO T_Import_Kunde_Backup
        (   Kunde_ID
           ,Kunde_Name
           ,Kunde_GRP
           ,Gültig_Ab
           ,Gültig_Bis
           ,ImportDate
        )

SELECT  Kunde_ID
           ,Kunde_Name
           ,Kunde_GRP
           ,Gültig_Ab
           ,'31.12.9999' as Gültig_Bis
           ,ImportDate
FROM   T_Import_Kunde a
where  a.Gültig_Ab = convert(datetime, a.ImportDate, 104)

3. Neue Kunden werden in der Backup-Tabelle aufgenommen.

INSERT INTO T_Import_Kunde_Backup
        (   Kunde_ID
           ,Kunde_Name
           ,Kunde_GRP
           ,Gültig_Ab
           ,Gültig_Bis
           ,ImportDate
        )

SELECT  Kunde_ID
           ,Kunde_Name
           ,Kunde_GRP
           ,Gültig_Ab
           ,'31.12.9999' as Gültig_Bis
           ,ImportDate
FROM   T_Import_Kunde a
where   a.Kunde_ID not in (select Kunde_ID from T_Import_Kunde_Backup)

4. Und schließlich wird die Importtabelle geleert.

Endergebnis

Die Backup-Tabelle sieht wie folgt aus und zeigt die Zugehörigkeiten der Kunden zur Kundengruppe im Zeitverlauf an.

Abb. 5: T_Import_Kunde_Backup

Durch einen einfachen Trick, die Stammtabelle als eine eigenständige Measuregruppe mit einem “Kundenzähler” in OLAP zu implementieren, kann man später in DeltaMaster die Kundengruppen und die Anzahl der Kunden im Zeitverlauf betrachten. Als Dimensionszuordnungs-Element für die Periode dient die Spalte “Gültig_Ab”.