Von Marc Gille*

Der Einsatz von objektorientierten Datenbank-Management-Systemen in Verbindung mit Operationenobjekten beseitigt nicht die grundsaetzlichen Probleme bei der Datenreplikation. Allerdings liefert dieser Ansatz jedoch eine elegante Moeglichkeit, sie auf semantischer Ebene anzugehen.

Datenreplikation ist kein neues Thema und zunaechst auch keine Frage der verwendeten Datenbanktechnologie. Das Duplizieren von Daten wird dann notwendig, wenn eine oder mehrere Applikationen auf Datenbestaende zugreifen muessen, die im Netz verteilt sind, das zudem haeufig heterogen ist. Dass manche Netzverbindungen nicht immer online verfuegbar oder instabil sind, ist nur einer der haeufigsten Gruende dafuer. Performance-Schwaechen machen ebenfalls oft den lokalen Datenzugriff erforderlich.

Daten zu duplizieren ist grundsaetzlich ein Problem

Bei rein lesenden Applikationen ist das Kopieren der Daten vergleichsweise unproblematisch. Komplizierter wird es, wenn die Kopien durch Datenbank-Transaktionen in den verschiedenen Anwendungen modifiziert werden. Da es bei fehlenden Netzverbindungen keine Instanz ueber die konsistente Abwicklung von Modifikationen wacht, wie etwa Serverprozesse oder ein Transaktionsmonitor, sind Replikatbestaende zeitweilig getrennt voneinander zu modifizieren, aktualisieren oder zu migrieren.

Die Migrationsvorgaenge lassen sich im allgemeinen nicht ohne Wissen um die semantische Bedeutung der erfolgten Modifikationen durchfuehren. Dieses Problem besteht grundsaetzlich und wird bisher durch keine Datenbanktechnologie geloest.

Original und Kopie wissen voneinander

Die Objektdatenbanken bieten jedoch einen Ansatz, der Semantik und Technik elegant miteinander verknuepft: In Objektdatenbanken lassen sich zwischen Objekten, eben zwischen Datenbestaenden und verschieden typisierte Verbindungen in Form einer "Kenntnis-von"- Beziehung (Assoziation) etablieren. Zum Beispiel kennt eine Firma alle Mitarbeiter. Somit kann eine derartige Assoziation Original- Kopie-Beziehungen abbilden, die implizit durch Replikationsvorgaenge entstehen.

Wird bei dieser Voraussetzung in einer Applikation der Bestand an replizierten Objekten modifiziert, so "schneidet" das System diese Modifikationen mit Hilfe sogenannter Logging-Mechanismen mit, zeichnet sie auf. Die Transaktionsverwaltung des Datenbanksystems verwaltet hiermit sowohl die Objektmodifikation als auch das Logging. Der atomare Charakter einer Modifikation ist sichergestellt.

Das Logging erfolgt ueber das Speichern von "Operationenobjekten", die wiederum "Kenntnis" von anderen Objekten besitzen. Sie haben Informationen ueber die Objekte, die durch Operationen modifiziert wurden. Es entsteht eine Folge von Operationenobjekten, die sich bezueglich ihres Informationsgehalts einfach auf Redundanzen untersuchen und somit optimieren lassen. Wird eine Kontonummer in einer Transaktion dreimal geaendert, etwa bei Datenkorrekturen, ist auf diese Weise nur noch die Ausfuehrung der letzten Operation erforderlich.

Loest ein Benutzer oder ein Replikations-Server einen Replikations- und Migrationsvorgang aus, wird eine "Kette" von Operationenobjekten zum Abgleich gegen den jeweils anderen Replikatbestand angewandt. Da ein Operationenobjekt die Objekte kennt, deren Modifikation es repraesentiert, und da diese Objekte wiederum ihre Kopien oder Originale kennen, ist im Online-Betrieb eine Migration technisch leicht durchfuehrbar.

Mit dieser Strategie allein kann das grundsaetzliche Konsistenzproblem bei der Modifikation replizierter Datenbestaende noch nicht beseitigt werden. Unter Beruecksichtigung der Tatsache, dass die Applikation, die die Operationenobjekte erzeugt hat, den semantischen Kontext kennt, in dem diese Operationen ausgefuehrt werden, laess sich ein "semantischer Softwarefilter" konstruieren, der die komplexen Operationen auswerten kann.

Fuer den Filter lassen sich zur Laufzeit des Systems Regeln als "Filterparameter" formulieren: "Wenn am Artikel X Preisaenderungen vor dem Datum Y vorgenommen wurden, dann duerfen keine Bestellungen fuer diesen Artikel mehr angenommen werden", waere eine solche Bedingung. Fuer viele, insbesondere kommerzielle Anwendungen ist die dynamische Formulierung solcher Regeln unerlaesslich. Hart kodierte Aenderungen in Vertriebs- oder Buchungssytemen etwa lassen sich in der gewuenschten Haeufigkeit nicht vornehmen.

Die Maechtigkeit dieses Konzepts zeigt sich vor allem bei Aenderungen an zwei oder mehreren sich ueberlappenden "Ausgangsdatenbestaenden", die in einen Zielbestand ueberfuehrt werden sollen. Da das Datenbanksystem im Offline-Betrieb keine Moeglichkeit hat, ueber Transaktionsmechanismen die Konsistenz der Aenderungen bei den Ausgangsbestaenden sicherzustellen, bleibt nur die Ueberpruefung der Konsistenz waehrend eines spaeteren Replikationsvorgangs ueber den semantischen Filter. Zeitstempel fuer die einzelnen Operationenobjekte ermoeglichen eine zusaetzliche Auswertung.

Ein Szenario nach dem beschriebenen Ansatz wurde mit dem ODBMS "Objectivity/DB" implementiert. Die Netzverbindung autonomer Bereiche der verteilten Datenbank sind hier partiell ueber ISDN- Verbindungen realisiert. Im Offline-Betrieb arbeiten die jeweiligen Datenbankpartitionen autonom und unabhaengig voneinander. Im Online-Betrieb werden Operationenketten ausgewertet, wobei alle verbundenen Datenbankpartitionen als ein durchgaengiger semantischer Adressraum nutzbar sind.

Die Implementierung des Konzepts semantischer Filter steht groesstenteils anwendungsunabhaengig zur Verfuegung. Lediglich die Auswertung semantischer Informationen ist applikationsabhaengig zu formulieren.

Die Object Database Management Group (siehe Kasten), die sich mit der Standardisierung der Benutzer- und Administrations- Schnittstellen von ODBMS beschaeftigt, arbeitet zur Zeit an Konzepten zur Standardisierung von Replikationsaufgaben. Demzufolge koennte ein Ansatz aehnlich dem vorgetragenen spaeter moeglicherweise produktunabhaengig zur Verfuegung stehen.

*Marc Gille leitet die Entwicklung und den Support bei der Micram Object Technology GmbH in Bochum. Er ist zudem Reviewing Member der ODMG.