Unternehmen müssen heutzutage eine Vielzahl von Daten erheben, verwalten
und interpretieren. Der Anspruch, auch auf historische Daten zurückzugreifen,
stellt eine zusätzliche Anforderung dar.

Ein Data Warehouse unterstützt den Anwender bei diesem Prozess, um
letztendlich eine sinnvolle Analyse durchführen zu können.
Zu diesem Zweck werden Informationen aus verschiedenen Quellen in eine
Staging Area integriert, damit Daten in einem nachfolgenden ETL-Prozess
zur weiteren Verwendung weiterverarbeitet werden.

Generell werden beim Data Warehousing zwischen den Fakten– und
Dimensionstabellen unterschieden.

• Die Faktentabelle enthält Bewegungsdaten aus den Quelldatenbanken.
  Das können Kennzahlen wie Umsatz, Aufwendungen und Erträge sein.

• Dimensionstabellen hingegen gruppieren inhaltlich zusammengefasste
  Merkmale unter einem Oberbegriff (z.B. Zeit, Produkte, Mitarbeiter).
  Sie stellen also die sogenannten „beschreibenden“ Daten dar, mit deren
  Hilfe Antworten auf W-Fragen (Wer, Was, Wann) ermittelt werden können.

Während Bewegungsdaten (Faktentabelle) in großer Anzahl in einem
Unternehmen anfallen und ständig aktualisiert werden, ändern sich die
beschreibenden Daten (Dimensionen) dagegen kaum. Informationen zu
einem Produkt sind in der Regel einmal festgelegt und überdauern eine
lange Zeit. Ein Beispiel für eine Änderung könnte das Umbenennen einer
Warengruppe oder eines Artikel sein. Absatzzahlen müssten auf der
anderen Seite regelmäßig aktualisiert werden. Daher werden sie in der
Faktentabelle erfasst.

Um den seltenen Änderungen innerhalb einer Dimensionstabelle gerecht zu
werden und sinnvoll zu verwalten, gibt es das Prinzip des Slowly Changing
Dimensions (SCD).

Dieses Prinzip wurde erstmals 1994 von Ralph Kimball eingeführt und
behandelt Vorgehensweisen im Umgang mit Änderungen an Dimensionen.
Primär gibt es drei Typen, die in der Praxis eingesetzt werden. Diese werden
nachfolgend vorgestellt:

Typ 1: Überschreiben der Werte

Diese ist die einfachste Vorgehensweise. Der neue Wert wird einfach im Datensatz überschrieben. Hierbei findet keine Historisierung statt, da der ursprüngliche Inhalt durch das Überschreiben verloren geht.

Hierzu ein kleines Beispiel:
Der Verantwortliche der Kostenstelle 22000 ändert sich im Laufe der Zeit. Anstatt „Max Mustermann“ ist nun ein Mitarbeiter namens „John Doe“ für diese Kostenstelle verantwortlich.

In der Spalte Verantwortlicher wird der entsprechende Eintrag überschrieben.

Wenn es also beispielsweise darum geht, einen Eintrag zu berichtigen und dafür keine Historisierung notwendig erscheint, dann ist dieser Ansatz des Überschreibens die richtige Vorgehensweise.

Typ 2: Hinzufügen eines neuen Datensatzes

Wenn man jedoch eine Änderung historisieren möchte, dann ist dieser Ansatz eine der beiden Möglichkeiten, um dies zu bewerkstelligen.

Im Allgemeinen werden in der Dimension zwei weitere Attribute hinzugefügt, die die Gültigkeit eines Datensatzes repräsentieren. Dazu wird anhand eines Datums bestimmt, ab und bis wann ein Datensatz aktuell ist. Gegebenenfalls kann durch ein drittes Attribut diese Aktualität durch ein Flag (true, false) gekennzeichnet werden.

Auch dazu ein kleines Beispiel:
Seit 01.01.2010 ist „Martin Mustermann“ der Verantwortliche der Kostenstelle 22000. Da bislang noch nicht klar ist, dass er die Verantwortung verlieren wird, wird die Gültigkeit des Datensatzes auf ein fernes zukünftiges Datum gesetzt. In diesem Fall auf 31.12.2099.

Am 15.06.2012 wurde von der Geschäftsleitung festgelegt, dass nun der neue Kollege „John Doe“ am nächsten Tag die Verantwortung für diese Kostenstelle erhält.

Im ursprünglichen Datensatz wird dieser Umstand in der Spalte Gültig_Bis vermerkt und die Aktualität auf false gesetzt, da dieser Datensatz nicht mehr aktuell ist. Vielmehr ist der nun neu erstellt Datensatz mit der Gültigkeit ab 16.06.12 der aktuelle. Und da bis zu diesem Zeitpunkt nicht klar ist, wann „John Doe“ wiederum die Verantwortung für die Kostenstelle verliert, wird Gültig_Bis auf den 31.12.2099 gesetzt.

Mit diesem Ansatz geht die Veränderung nicht verloren und bleibt in der Dimension bestehen. Das bedeutet, dass gegebenenfalls auf diese Information zurückgegriffen werden kann, falls sie in einem Bericht notwendig wird. Die Frage, wie ein Bericht die Gültigkeit eines Datensatzes erkennt, ist schnell beantwortet. Denn durch die Markierung aktuell wird dem Bericht der aktuelle Satz mitgeteilt.

Typ 3: Hinzufügen einer neuen Spalte

Dieser Ansatz stellt die andere Möglichkeit zur Historisierung der Daten innerhalb einer Dimension dar. Doch anstatt (wie bei Typ 2) eine Zeile mit den neuen Informationen hinzuzufügen, werden Attribute mit den neuen Werten überschrieben. Damit aber diese Informationen nicht verloren gehen, werden sie in zusätzlichen Spalten in einem Datensatz gespeichert. Aber: in Abhängigkeit des Modells wird in der Regel jeweils nur der neue und der alte Zustand gespeichert. Konkret bedeutet das also, dass jeweils nur die unmittelbar aktuelle Änderung historisiert wird. Ändert sich abermals der Inhalt eines Attributs, so werden die Werte in den entsprechenden Spalten „neu“ und „alt“ überschrieben und die vorherige Historisierung geht verloren.

Und wieder dazu ein Beispiel:
Nach wie vor ist zunächst „Max Mustermann“ der  Verantwortliche der Kostenstelle 22000.

Und wieder wird „Max Mustermann“ die Verantwortung verlieren und sie an „John Doe“ übergeben.

Wie man erkennt, wird die alte Information mit dem neuen Wert überschrieben. Doch zusätzlich wird in einer neuen Spalte der ursprüngliche Wert gespeichert.
Bei einer erneuten Änderungen wandert der Eintrag „John Doe“ zu alt_Verantwortlich und der Inhalt Max Mustermann geht verloren.

Der Nachteil dieser Vorgehensweise liegt auf der Hand. Zwar besagt die Theorie des Slowly Changing Dimensions , dass Informationen in einer Dimension selten verändert werden, doch in der Praxis kann dies häufiger vorkommen. Zum Beispiel bei Preisänderungen eines Produktes.
Die Vorgehensweise bei Typ 3 fordert, bei jeder neuen Änderung den ursprünglichen Wert zu überschreiben und den alten Wert in eine vordefinierte Spalte zu erfassen. Bei häufigen Änderungen wiederholt sich dieser Prozess, sodass immer die jeweils vorherige Historisierung nicht mehr sichtbar ist. Doch genau das ist in der Regel nicht immer erwünscht und führt unter Umständen zu Verwirrungen.
Bei sehr seltenen Änderungen kann aber diese Vorgehensweise ideal sein, wenn eine Gegenüberstellung der unmittelbar vorherigen Veränderung in einem Bericht erwünscht ist.

Alles in allem wurden in diesem Beitrag drei verschiedene Ansätze dargestellt, die je nach Anforderungen an ein Data Warehouse in Betracht gezogen werden. Hier nochmal eine kurze Zusammenfassung dieser Vorgehensweisen:

• Sollen Informationen einfach nur berichtigt werden…
  … dann wäre der erste Typ der richtige Ansatz. Hier wird nicht historisiert und die ursprüngliche Information geht verloren.

• Sollen Informationen über Änderungen hinweg gespeichert werden…
  … so kommt Typ 2 in Betracht, in dem eine Historisierung durch Kennzeichnung der Gültigkeit vorgenommen wird. Die ursprüngliche Information geht nicht verloren und bleibt in der Dimension bestehen. Diese Vorgehensweise ist sicherlich die populärste.

• Werden Informationen innerhalb einer Dimension nur sehr selten geändert…
  … dann ist Typ 3 eine Möglichkeit der Historisierung. Die alte Information wird mit der neuen überschrieben. Die Historisierung wird durch das Speichern in eine vordefinierte Spalte realisiert, in der die ursprüngliche Information erfasst wird. Als Nachteil sei erwähnt, dass schon bei häufigeren Änderungen die Dimension sehr unübersichtlich werden kann, da bei wiederholten Änderungen die unmittelbar vorherige Historisierung verloren geht.