Data Warehouse Technologien

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