Oracle 12c - Das umfassende Handbuch

22.5

Das Datenmodell

553

쐽 Ein hoher Feinheitsgrad, der Informationen so detailliert wie möglich abspei-

chern kann, garantiert Ihnen, dass alle benötigten Informationen aus dem Da-

ta Warehouse abgerufen werden können.

쐽 Ein niedrigerer Feinheitsgrad garantiert eine gute Performance, da die Gesamt-

größe der Datenbank kleiner ist. Allerdings muss befürchtet werden, dass die

Anwender nicht alle Informationen im Data Warehouse finden.

Falls Sie bei der Wahl des Feinheitsgrades unentschlossen sind, wählen Sie im

Zweifelsfall den höheren. Das Schlechteste, was Ihnen passieren kann, ist, ein teu-

res Data Warehouse-Projekt zu realisieren und dann festzustellen, dass gewisse

Auswertungen nicht möglich sind, weil Daten fehlen. Das setzt die Akzeptanz des

Data Warehouse im Unternehmen stark herab und schließt die Gefahr ein, dass

die Anwender sich die Informationen aus anderen Quellen besorgen. Eine man-

gelhafte Performance können Sie immer durch technische Maßnahmen oder das

Anhängen von Data Marts verbessern.

22.5 Das Datenmodell

Es existieren branchenspezifische Empfehlungen für das Datenmodell eines Data

Warehouse. Am Ende hat jedoch jedes Projekt ein eigenes Modell mit unterneh-

mensspezifischen Besonderheiten. Das Beispiel in diesem Abschnitt ist ein Star-

Schema für eine Bank.

Eine Bank verfügt über eine Produktpalette mit Giro- und Sparkonten, einer Reihe

von Kreditprodukten sowie Schließfächern. Der Feinheitsgrad wird so gewählt,

dass die Konteninformationen eines jeden Kunden auf Monatsbasis verfügbar

sind. In Abbildung 22.2 finden Sie die Tabellen des Star-Schemas. Es besteht aus

einer Fact Table mit dem Namen accounts_fact sowie Dimension Tables für Kun-

den, Zeit, Status, Filialen und Produkte.

Hinweis

Ein sehr wichtiger Punkt beim Erstellen eines Datenmodells ist die Festlegung

des Feinheitsgrades. Im Englischen werden die Ausdrücke »Grain« und »Granu-

larity« verwendet. Mit dem Feinheitsgrad legen Sie fest, wie detailliert die Infor-

mationen sind, die in einem Data Warehouse gespeichert werden sollen. Die

Wahl des Feinheitsgrades hat signifikanten Einfluss auf die Größe der Daten-

bank. So kann eine zusätzliche Stufe an Granularität eine Verzehnfachung der

Größe der Datenbank zur Folge haben. Die Kunst bei der Modellierung liegt

darin, einen Kompromiss zwischen den folgenden zwei Argumenten zu finden:

Kapitel 22

Ein Data Warehouse planen

554

Abb. 22.2: Einfaches Star-Schema für eine Bank

Im Zusammenhang mit DSS-Abfragen tritt häufig der Begriff Drill Down auf. Drill

Down im Data Warehouse bedeutet: »Zeig mir zu den vorhandenen Informatio-

nen weitere Details«. Weiter ins Detail zu gehen, bedeutet für gewöhnlich, eine

zusätzliche Dimension in die Abfrage oder den Report aufzunehmen. Abfragen

mit wenigen Dimensionen laufen schnell und ohne signifikanten Ressourcenver-

brauch, da hierfür die Summary Tables verwendet werden. Jedes Drill Down bedeu-

tet eine Erhöhung der Antwortzeiten.

Der wohl wichtigste Beitrag zur Verbesserung der Performance sind Aggregates.

Aggregates sind aufsummierte Tabellen, in denen Summen über Dimensionen

gebildet werden. Sie werden wie Fact Tables behandelt. Moderne OLAP-Tools, aber

auch die Oracle-Datenbank mit dem Query Rewrite-Feature, sind in der Lage, die

SQL-Anweisungen der Benutzer so zu verändern, dass eine automatische Erken-

nung erfolgt und auf die Summary Tables zugegriffen wird.

Dimension Tables können hierarchisch aufgebaut sein. Die Dimension Table

customer_dim enthält naturgemäß demografische Informationen. An dieser Stelle

ist es sinnvoll, diese in eine angeschlossene zusätzliche Tabelle auszulagern. Die

neue Tabelle besitzt dann eine Eins-zu-n-Beziehung zur Dimension Table custo-

mer_dim. Ein solches Modell wird als Snowflake-Struktur bezeichnet.

Tipp

Auch wenn Snowflakes das Modell übersichtlicher machen und logisch sauberer

sind, sollten sie nur sparsam eingesetzt werden. Abfragen, die Snowflake-Tabel-

len enthalten, liefern eine schlechtere Performance.