Das Star-Schema (Sternschema)

Das Star-Schema unterstützt die logische Datenmodellierung. Dabei werden die eigentlichen Werte der Kennzahlen in den Faktentabellen gespeichert und die Dimensionseinträge in sogenannten Dimensionstabellen. Außerdem sind die Beziehungen zu den entsprechenden Dimen­sionstabellen in den Faktentabellen hinterlegt.

Abbildung 4-21 Star-Schema Cash Flow

Wie in obigem Schema zu sehen ist, werden Dimensionstabellen sternförmig um die Faktentabelle aufgebaut. Dabei wird bewußt von der logischen Datenmodellierung in operativen DBS abgewichen und die Daten nur noch in der zweiten Normalform modelliert anstatt in der dritten Normalform. Dadurch wird die logische Datenmodellierung flexibler.

Die Modellierung der Daten in einem Star-Schema mit atomaren Daten auf der untersten Hierarchieebene innerhalb der Dimensionen ist unproblematisch.117 Werden jedoch aggregierte Daten modelliert, so gibt es zwei Möglichkeiten der Realisierung. Entweder man berechnet die aggregierten Daten in den Analyseabfragen oder die aggregierten Daten werden im Data Warehouse gespeichert. Hierbei ist zwischen Performanceverlusten und Administrationsaufwand abzuwägen. Im folgenden soll der zweite Fall näher erläutert werden.

Werden aggregierte Daten im Data Warehouse gespeichert, ergibt sich das Problem der Un­terscheidung von aggregierten und atomaren Daten. Dieses Problem kann durch Hinzufügen eines weiteren Attributs in die Dimensionstabellen gelöst werden. Dieses Attribut „level“ enthält Informationen über die Stufen bzw. Art der Aggregation.

Abbildung 4-22 Dimension: Zeit

Ein Problem bei der Einführung des Attributs „level“ liegt in der Inflexibiliät bei Veränderungen der Dimensionstabellen. Dadurch verändert sich nicht nur die Datenbasis des Data Warehouse, sondern es müssen auch Veränderungen in den Analysetools vorgenommen werden.

Die Galaxie

Eine Erweiterung des Star-Schemas ist die Galaxie. Diesen Begriff hat McGuff118 geprägt. Bei der Galaxie existiert nicht nur eine Faktentabelle sondern mehrere Faktentabellen. Die einzelnen Fakten (z.B. Kennzahlen: Umsatz, Cash Flow) werden jeweils in eigenen Faktentabellen gespeichert. Die verschieden Dimensionstabellen bleiben von den Veränderungen unberührt. Einzige Veränderung zum Star-Schema ist die Möglichkeit mehrerer Joins von Dimensionsta­bellen zu Faktentabellen.

Fact Constellation Schema

Das Fact Constellation Schema (FCS) ist eine Abwandlung des Star-Schemas. Der Kritik der Inflexibilität des Star-Schemas wurde durch das FCS entgegengewirkt. Im FCS werden die aggregierten Daten nicht mehr in den Dimensionstabellen modelliert, sondern es wird für jede denkbare Aggregationsform eine eigene Faktentabelle aufgebaut. Dadurch steigt die Anzahl der Faktentabellen entsprechend der Anzahl der Dimensionen explosionsartig an. Jedoch wird dadurch die Modellierung des Attributes „level“ überflüssig, so daß Veränderungen am Modell keine so weitreichenden Folgen der Modellveränderungen mit sich bringen würden wie beim Star-Schema. Die Modellierung eines FCS ist der Modellierung eines Star-Schemas dann vorzuziehen, wenn besonders große Faktentabellen entstehen.119

Partitionierte Dimensionstabellen

Die Probleme, die bei der Modellierung mit Hilfe des Attributes „level“ im Star-Schema ent­stehen, können auch durch Teilung der Dimensionstabellen gelöst werden. Dabei werden die Dimensionstabellen normalisiert120, das heißt die Dimensionstabellen werden entsprechend ihrer Aggregationsstufe („level“) aufgesplittet. Die Ersparnis durch das Weglassen des „level“-Eintrages und des geringeren Speicherplatzes muß mit einem Performance-Verlust erkauft werden.121

Abbildung 4-23 partitionierte Dimensionstabelle

Snow Flake Schema

Das Snow Flake Schema (SFS) ist eine Mischung aus partitionierten Dimensionstabellen und dem Fact Constellation Schema. Die Dimensionstabellen werden partitioniert und die Faktentabellen werden für jede Aggregations-Kombination jeweils als eine Faktentabelle gespeichert. Der Nachteil dieses SFS liegt in der Komplexität des Modelles. Mittels Tools kann diese Problematik durch Verwaltung des Data Warehouse auf semantischer Ebene umgangen werden.122

114 Heuer, A. (1992)

115 Vgl.: Hahne, M. (1998), S. 109ff

116 Vgl.: Raden, N.

117 Vgl.: Hahne, M. (1998), S. 111

118 Vgl.: Hahne, M. (1998), S.116; McGuff, F. (1996)

119 Vgl.: Hahne, M. (1998), S.117

120 Vgl.: Hahne, M. (1998), S.118

121 Vgl.: Hahne, M. (1998), S.120

122 Vgl.: Hahne, M. (1998), S.120-121