Data Warehouse Technologien

Im Fehlerfall erfolgt die Dokumentation der Fehler. Außerdem müssen ge-

eignete Wiederanlaufmechanismen für die auftretenden Fehlersituationen vor-

gesehen und im Fehlerfall gestartet werden.

2.3.2 Monitore

In einem DW- System sind ein oder mehrere Monitore realisiert, die die Daten-

quellen auf Änderungen überwachen. Ein Monitor muss Datenmanipulationen

in einer Datenquelle erkennen und an den DW-Manager melden.

Monitor-

strategien

Kooperative

Quellen

Trigger-

basiert

Replikations-

basiert

Nicht-kooperative

Quellen

Zugriff auf

interne Daten

Log-

basiert

Zeitstempel-

basiert

Snapshot-

basiert

Abbildung 2.7: Strategien von Monitoren

Monitore müssen unterschiedliche Strategien implementieren, um Daten-

quellen zu überwachen, da Datenquellen sehr unterschiedlich aufgebaut und

mehr oder weniger kooperativ sein können. Abbildung 2.7 klassifiziert die un-

terschiedlichen Strategien von Monitoren, die wir im Folgenden genauer be-

trachten werden.

Es gibt folgende Strategien für das Monitoring:

• Die trigger-basierte Monitorstrategie kann bei kooperierenden Datenbank-

systemen eingesetzt werden, die aktive Datenbankfunktionalität bereit-

stellen. Trigger als aktive Datenbankmechanismen werden bei Datenän-

derungen ausgelöst, und starten als Aktion das Kopieren der geänderten

Tupel in einen gesonderten Bereich. Dieser Bereich muss von einem Ex-

traktor dann nur noch ausgelesen werden.

Trigger müssen explizit nach dem ECA-Paradigma (Event Condition Acti-

on) kodiert werden. In einer ECA Regel wird angeben, dass bei dem Eintre-

ten eines bestimmten Ereignisses (E, zum Beispiel ein Einfügen in die Kun-

dendatei) eine Aktion ausgeführt wird (A, zum Beispiel Kopieren des neuen

2.3 Referenzarchitektur 33

Datensatzes in die temporäre Datei Neukunden), sofern eine bestimmte Be-

dingung gilt (C, etwa der neue Kunde ist kein interner Mitarbeiter).

• Die replikations-basierte Monitorstrategie vermeidet das (fehlerträchtige)

Kodieren von Triggern, indem die internen Mechanismen zur Verwaltung

von Replikaten eines DBMS ausgenutzt werden. Diese internen Mecha-

nismen sind in der Regel effizienter realisiert als benutzerprogrammierte

Trigger.

Faktisch wird dabei einer Datenquelle vorgetäuscht, dass das Data Ware-

house Teile der Daten der Datenquelle als Replikat speichert. Die Nach-

richten zur Synchronisierung des Duplikats werden sozusagen abgefangen

und gespeichert, um dann später vom Extraktor ausgelesen zu werden.

• Die log-basierte Monitorstrategie kann bei nicht aktiv kooperierenden Da-

tenquellen genutzt werden, die aber den Zugriff auf interne Daten ermögli-

chen. Ein Log-Buch protokolliert alle Änderungen der Datenquelle, um im

Fehlerfall ein Recovery zu ermöglichen [SSH11].

Ein Monitor muss dann derartige Transaktions-Log-Dateien des DBMS

analysieren, um relevante Änderungen zu identifizieren.

• Ebenfalls auf internen Informationen eines DBMS beruht die zeitstempel-

basierte Monitorstrategie. Einige DBMS ordnen jedem Tupel einen eindeu-

tigen Zeitstempel zu. Dieser Zeitstempel protokolliert den Zeitpunkt der

letzten Änderung bzw. des Einfügens.

Der Zeitpunkt der letzten Extraktion dient als Referenzzeitpunkt. Alle Tu-

pel mit einem Zeitstempel größer als dieser Referenzpunkt sind seit diesem

Zeitpunkt geändert oder neu eingefügt werden.

Wurde ein Tupel seit dem letzten Referenzzeitpunkt mehrfach geändert,

wird nur die letzte Änderung erfasst. Je nach DBMS muss für das Löschen

von Tupeln eine gesonderte Strategie realisiert werden, da dies sonst nicht

erfasst wird.

• Die snapshot-basierte Monitorstrategie kommt ohne aktive Kooperation

oder interne Informationen des DBMS aus. Hierzu erfolgt ein periodisches

Kopieren des relevanten Datenbestandes in eine Datei (der sogenannte

Snapshot). Die Identifizierung von Änderungen erfolgt nun durch einen

Vergleich des aktuellen Snapshots n mit dem zuletzt gespeicherten Snaps-

hot n − 1.

Die snapshot-basierte Strategie funktioniert auch bei Datenquellen, die

keine DBMS-Funktionalität anbieten, etwa Katalogdaten im Internet, so-

fern diese sich in eine Liste von Tupeln transformieren lassen.

Der Vergleich von Snapshots ist als differential snapshot computation be-

kannt und wird später noch detailliert behandelt werden.

34 2 Architektur