Kapitel 22
Ein Data Warehouse planen
550
Entwickler haben unter Umständen wenig Erfahrung bei der Optimierung von
SQL-Anweisungen. Hier muss der Datenbankadministrator Unterstützung leisten.
Für die Entwicklung und Umsetzung einer Strategie für Backup and Recovery
sind die besonderen Anforderungen des Data Warehouse zu beachten. Da die
Datenbanken sehr groß sind, muss über ein effizientes Sicherungsverfahren
nachgedacht werden. Möglicherweise ist eine wiederholte Durchführung des
nächtlichen Ladeprozesses schneller als ein Recovery-Prozess über mehrere Stun-
den. Dieser Strategie kommt die Tatsache entgegen, dass das Laden mit der
NOLOGGING-Option zu einer signifikanten Beschleunigung der Prozesse führt.
Als Datenbankadministrator müssen Sie die Größe der Datenbank prognostizieren
und das weitere Wachstum überwachen. Dabei geht es nicht nur um die Tatsache,
dass genügend Disk-Kapazitäten zur Verfügung stehen. Mit einer wachsenden
Datenbank vergrößern sich die Laufzeiten sowohl für den Ladeprozess als auch für
die DSS-Abfragen und die Reports. Da viele Daten in ein Data Warehouse einflie-
ßen, muss über eine effiziente Archivierung nachgedacht werden.
Der Datenbankadministrator sollte nicht warten, bis sich Anwender über mangel-
hafte Performance beschweren. Auch wenn sich das Wachstum der Datenbank im
geplanten Rahmen bewegt, kann sich die Laufzeit einiger Abfragen überproportio-
nal verschlechtern. Kontrollieren Sie deshalb regelmäßig die Laufzeit. Werden kri-
tische Abfragen frühzeitig erkannt, können Maßnahmen wie die Einführung von
aggregierten Tabellen ergriffen werden, bevor die Probleme größere Störungen
verursachen.
22.4 Die Architektur des Data Warehouse
In Abbildung 22.1 sehen Sie eine typische Data Warehouse-Architektur. Kommen
die Daten aus vielen verschiedenen Quellen, wird häufig eine Staging Area verwen-
det. Die in der Staging Area gespeicherten Daten besitzen die Struktur der Quell-
daten und können von da aus weiter für das Data Warehouse aufbereitet werden.
Im eigentlichen Ladeprozess erfolgt die Denormalisierung der Daten.
Im Umfeld von großen Data Warehouse-Datenbanken werden häufig Data Marts
gebildet. Das sind kleinere Datenbanken mit den Daten eines bestimmten Teilbe-
Wichtig
Achten Sie unbedingt auf Transparenz im Ladeprozess. Es ist nicht sinnvoll,
individuelle Programme zu entwickeln, die nur von »Spezialisten« geändert wer-
den können. Gerade der Ladeprozess unterliegt permanenten Änderungen, die
sich wie die operativen Systeme ebenfalls verändern.
22.4
Die Architektur des Data Warehouse
551
reichs. Der Vorteil von Data Marts liegt in der schnelleren Verfügbarkeit der Daten
in Abfragen und Reports sowie einer stärkeren Transparenz für die Anwender.
Abb. 22.1: Die Data Warehouse-Architektur
DSS-Abfragen werden zwischen Reports, also immer wiederkehrenden Abfragen,
und Ad-hoc-Abfragen unterschieden. Für die Abfragen werden spezielle OLAP-
Tools eingesetzt. Diese verwalten die Metadaten, generieren und speichern die
Abfragen und unterstützen die Anwender in vielerlei Hinsicht wie z.B. dem Sum-
mary-Management.
Im Gegensatz zu den operativen Datenbanken unterscheidet sich das Datenmo-
dell eines Data Warehouse vor allem darin, dass es stark denormalisiert ist. In
Tabelle 22.1 finden Sie eine Unterscheidung der Charakteristiken zwischen Data
Kapitel 22
Ein Data Warehouse planen
552
Warehouse- und OLTP-Datenbanken.
In einer normalisierten Datenbank gibt es keine oder nur wenig Redundanz in den
Daten. Dagegen beinhaltet eine denormalisierte Datenbank viele Redundanzen.
Das logische Data Warehouse-Design ist konzeptionell und abstrakt. Dabei wer-
den die Details für die Implementierung nicht beachtet. Das Ziel des logischen
Designs ist es, den Rahmen für die benötigten Informationen abzustecken, diese
zu sammeln und in einem Datenmodell zu verankern.
Ein weit verbreitetes Modell im Data Warehouse-Bereich ist das Star-Schema.
Dabei handelt es sich um die relationale Nachbildung eines dimensionalen
Modells. In der Mitte befinden sich eine oder mehrere Fact Tables, die von Dimen-
sion Tables umgeben sind.
In einer Fact Table werden die numerischen Werte von Informationen gespei-
chert. Dazu gehören zum Beispiel Preis, Stückzahl oder Mehrwertsteuer. Neben
den eigentlichen Fakten enthält eine Fact Table Fremdschlüssel, die auf die
Dimension Tables verweisen.
In einer Dimension Table werden die beschreibenden Daten der Dimensionen
gespeichert. Sie besitzen einen Primärschlüssel, auf den die Fremdschlüssel der
Fact Tables zeigen. Dimension Tables enthalten vergleichsweise wenige Sätze,
haben jedoch eine größere Satzlänge.
OLTP Data Warehouse
Normalisiertes Design Denormalisiertes Design
Wenige aggregierte Tabellen Viele aggregierte Tabellen
SQL-Optimierung nach Antwortzeit SQL-Optimierung nach Durchsatz
Geringe oder keine Parallelisierung Starke Parallelisierung
Kurze Transaktionen Lange Transaktionen und lang laufende SQL-Abfragen
Viele Nested Loop-Operationen mit
Index-benutzung
Viele Hash Joins mit Full Table Scans
Tabelle 22.1: Unterschiede zwischen Data Warehouse- und OLTP-Datenbanken
Tipp
Fact Tables enthalten sehr viele Datensätze und können deshalb sehr groß wer-
den. Halten Sie deshalb die Satzlänge so klein wie möglich und speichern Sie
keine beschreibenden Daten. Eine Fact Table sollte ausschließlich numerische
Spalten für Fakten und Fremdschlüssel enthalten.

Get Oracle 12c - Das umfassende Handbuch now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.