Auch der Typ 7 stellt einen hybriden Ansatz dar. Es werden sowohl al-
te wie auch aktuelle Werte analog zu Typ 6 historisiert. In der Faktentabelle
werden beide (der dauerhafte und der künstliche) Dimensionsschlüssel gespei-
chert. Anfragen nach aktuellem und historischem Kontext können somit über
den Verbund realisiert werden.
Typ Anpassung Dimensionsschema Einfluss auf die Analyse
0 keine: keine Änderungen (Updates) Analyse auf Originalwerten
zulässig
1 keine: Überschreiben (Update) auf Analyse auf aktuellen Werten
aktuelle Werte
2 keine: Hinzufügen neuer Zeilen Analysen wenn Fakten auftreten
3 neue Spalte für letzten historischen Analysen alter und aktueller
Wert Dimensionswerte
4 neue Mini-Dimensionstabelle Performanz von sich schnell ändernden
Dimensionswerten bei Anfrage
5 neue Mini-Dimensionstabelle und wie zuvor plus aktuell sich
Überschreiben auf aktuelle Werte ändernde Werte
6 neue Zeilen mit Überschreiben, alle Fakten verbunden mit Auftritt der
anderen Zeilen werden ebenfalls geändert Dimensionsänderung und aktuelle Werte
7 neue Zeilen mit aktuellen Werten und Fakten verbunden mit Auftritt der
View für aktuelle oder Attributwerte Dimensionsänderung und aktuelle Werte
Tabelle 3.1: Typen der Slowly Changing Dimensions nach Kimball [KR13]
Die Tabelle 3.1 fasst die Typendefinition nach Kimball noch einmal kurz
zusammen. Hinsichtlich der Änderungen im Dimensionsschema sind unter-
schiedliche Realisierungen möglich. Auch die möglichen Anfragetypen werden
mit dem Konzept der Slowly Changing Dimensions stark beeinflusst. Abhän-
gig von der Umsetzung sind Fragen bezüglich der Performanz im Data Ware-
house zu berücksichtigen. Daher muss sich bereits im Data Warehouse-Design
dieser Fragestellung angenommen werden. Aus diesem Grund stellen wir im
folgenden Abschnitt Anforderungen seitens des Berichtswesens vor und zeigen
mögliche Implementierungen.
3.4.3 Realisierungen im Data Warehouse
Die Berichtsanforderungen bzw. die im vorhergehenden Abschnitt dargestell-
ten Typdefinitionen lassen sich im Data Warehouse mit unterschiedlichem Auf-
wand umsetzen. Einerseits ist es möglich, eine Anpassung des historischen Da-
tenmaterials an die neuen Strukturen vorzunehmen. Dabei handelt es sich um
die Umsetzung der Berichtsanforderung as-is. Zugleich ist der zu speichernde
Datenbestand gering. Jedoch geht dies mit dem Informationsverlust der alten
Dimensionsstrukturen einher. Andererseits kann eine separate Speicherung
des historischen Datenbestandes zusätzlich zu den aktuell gültigen Struktu-
ren realisiert werden. Dies führt zu einem großen Datenbestand und einer ho-
74 3 Modellierung von Data Warehouses
hen Komplexität für die Anwender. Bei dieser Strategie sind dann die alten
Strukturen abrufbar. Alternativ lassen sich auch parallele Hierarchien mit al-
len Strukturen aufbauen. Neben der daraus resultierenden Komplexität der
Dimensionsstruktur ist ein beliebiges Reporting möglich. Letztlich ist auch die
Nutzung von Zeitstempeln für die Gültigkeit eine Realisationsstrategie, in der
beliebige Strukturen abrufbar sind. Dies ist aber unter besonderer Berücksich-
tigung der Performance für den jeweiligen Anwendungsfall zu analysieren.
Im Folgenden werden wir die wichtigsten Realisationsmöglichkeiten dis-
kutieren. Hierbei unterschieden wir unterschiedliche Szenarien der Berichts-
anforderungen und werden diese am obigen Beispiel erläutern.
Berichtsanforderung as-is
Im „as-is“-Szenario erfolgt keine Historisierung der Dimensionsattribute und
daher ist dieses Szenario sehr einfach zu realisieren, kann aber andererseits
nur für die Berichtsanforderung nach aktueller Struktur genutzt werden. Das
Historisierungskonzept erfordert keine Änderung des Schemas der Dimension.
Dabei handelt es sich um den nach Kimball definierten Typ 1.
Jahr 2010
Getraenk_ID Produkt Produktgruppe
1 Dornfelder Rotwein
2 Müller-Thurgau Weißwein
Jahr 2011
Getraenk_ID Produkt Produktgruppe
1 Dornfelder Rotwein
2 Müller-Thurgau Weißwein
3 Portugieser Weißherbst Rotwein
3
Portugieser Weißherbst Weißwein
Abbildung 3.24: Realisierung des as-is-Szenarios
In Abbildung 3.24 stellen wir einen Ausschnitt für unser Beispiel aus Ab-
bildung 3.19 für das as-is-Szenario dar. Hierbei führt die neue Kategorisie-
rung hinsichtlich des Portugieser Weißherbst in der Dimensionstabelle zu ei-
nem Überschreiben der bisherigen Zuordnung zum Rotwein. Somit sind mit der
Änderung alle Fakten für den Portugieser Weißherbst der Kategorie Weißwein
zuzuordnen.
Berichtsanforderung as-is und as-of
Das Szenario „as-is“ & quasi „as-of“ benötigt zum vorhergehenden Szenario
einen etwas höheren Speicherbedarf. Die Historisierung der Dimensionsattri-
bute erfolgt ohne eine Zeitzuordnung und wird daher als quasi „as-of“ bezeich-
net. Die Implementierung entspricht der parallelen Hierarchie. Diese Realisie-
rung entspricht dem Typ 3 der Slowly Changing Dimensions. Es werden somit
Auswertungen nach aktuellem Stand und nach (einem) historischen Zeitpunkt
ermöglicht.
3.4 Slowly Changing Dimensions 75

Get Data Warehouse Technologien now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.