Data Warehouse Technologien

4.5 Die Ladephase

Der Ladevorgang hat das effiziente Einbringen der Daten in das Data Warehou-

se zur Aufgabe. Hierbei wird davon ausgegangen, dass es sich um externe Da-

ten handelt. Aufgrund unterschiedlicher Entwicklungen im Data-Warehouse-

Umfeld entkoppeln wir den Ladevorgang von der Extraktionsphase und dem

Transformationsschritt. In der Praxis sind diese jedoch vielfach nicht unmittel-

bar entkoppelbar. Somit können für den Ladevorgang zwei Bereiche unterschie-

den werden: das Laden externer Daten in den Datenbeschaffungsbereich und

das Laden der transformierten Daten in die Basisdatenbank. Beim Beladen der

Basisdatenbank bzw. des Datenwürfels kann es vorkommen, dass das gesamte

Data Warehouse blockiert wird und die Analyseprozesse beeinträchtigt werden.

Dies kann zum Beispiel durch eine Schreibsperre innerhalb der Faktentabelle

verursacht werden.

Wir wollen uns daher in diesem Abschnitt insbesondere mit Aspekten zu

Triggern, Integritätsbedingungen und Indexaktualisierungen befassen. Auf-

grund der Historisierung der Daten in Faktentabellen wird nur ein Insert neuer

Daten angewendet. Sollte es trotzdem unabdingbar sein, dass Berichtigungen

vorgenommen werden müssen, so kann entweder die Initialbefüllung erneut

durchgeführt werden, was einen hohen Gesamtaufwand für das Data Ware-

house bedeutet, Korrekturbuchungen oder eine Verschiebung der zu korrigie-

renden Daten erfolgen. Häufiger tritt jedoch der Fall auf, dass sich Werte inner-

halb der Dimensionsattribute ändern. Diesbezüglich wird in Abhängigkeit der

Analyseanforderungen zwischen drei Typen unterschieden: dem Überschreiben

der Historie (Update), der Abbildung der kompletten Historie (Insert und Up-

date auf den Dimensionsdaten) und der Abbildung der Historie und dem ak-

tuellen Zustand (Insert). Dies wird auch als Slowly Changing Dimensions be-

zeichnet, siehe hierzu insbesondere [KR02]. Wir wollen uns im Folgenden auf

Insert-Operationen konzentrieren.

Beim satzbasierten Bearbeiten der Daten kann der Einsatz von Standard-

schnittstellen wie z.B. PRO*SQL, JDBC oder ODBC erfolgen. Das Laden erfolgt

hierbei im normalen Transaktionskonzept. Dies bedeutet, dass Trigger, Indexe

und Constraints aktiv bleiben. Für die schnellere Verarbeitung lassen sich die-

se Mechanismen jedoch manuell deaktivieren. Es gilt dabei insbesondere zu be-

achten, dass großräumige Sperren vermieden werden. Durch den Einsatz von

COMMIT lassen sich die Sperren verringern. Für Oracle gilt dies für Leseope-

rationen jedoch nicht, da diese im Multi-Version Concurrency Control System

nie gesperrt werden. Auch die Nutzung von vorbereiteten SQL-Statements ist

an dieser Stelle möglich. Zudem existieren proprietäre Erweiterungen, z.B. auf

Basis multidimensionaler Arrays.

4.5 Die Ladephase 113