Verteilte Datenbanken allein reichen nicht. Wollen die Anbieter die Wünsche der Anwender nach mehr Funktionalität ernst nehmen, dann kommen sie langfristig nicht um objektorientierte Ansätze herum. Nur damit könnten globale Optimierungsstrategien realisiert und das semantische Niveau verbessert werden.

Verteilte Datenbanken sind Elemente in einem unternehmensweiten Verteilungskonzept der DV-Leistungen. Sie sollen die Funktionalität, Verfügbarkeit und Performance erhöhen. Paradox daran ist, daß die Verteilung sowohl für den Enduser als auch für die Anwendungen transparent - sprich verdeckt - funktionieren soll.

Der Verteilung der Endbenutzer die qualitativ und quantitativ immer höherwertige DV-Leistungen mit geringeren Kosten und steigender Betriebssicherheit beanspruchen, folgt die Verteilung der Rechenleistung. Das hat verteilte Anwendungen zur Folge, zu denen auch Datenbanksysteme (DBMS) gehören.

Verteilte Datenbanksysteme sind Mittel zum Zweck und sollten daher aus der Erwartung heraus beurteilt werden, optimale, effiziente und semantisch hochwertige Dienste zu erhalten. Besonders wichtig ist hier das Zusammenwirken mit einer optimalen, dynamischen Verteilung der Anwendungsfunktionen innerhalb einer intelligenten Client-Server-Lösung.

Aber nicht für jedes Unternehmen sind verteilte Datenbanksysteme die optimale Lösung. Wo Standardpakte eingesetzt oder mittelfristige Umstellungen betrieben werden, kommt es häufig zur gleichzeitigen Verwendung heterogener Datenbanksysteme. In solchen Fällen spielt eine Verteilung der Anwendungen typischerweise eine untergeordnete Rolle.

Die vorrangige Funktionalität auf der Ebene verteilter Datenbanksysteme sind die Abfrage- und Update-Dekomposition, Deadlockauflösung sowie die netzwerkweite Erhaltung der Datenkonsistenz. Dazu gehören globale Optimierung der Dekomposition und synchronisiertes Transaktionsmanagement mit Koordination von Restart- und Recoverysituationen.

Locking und Synchronisation

Ein Kommunikationsnetz ist notwendig, um Benutzer und Datenbanksysteme miteinander zu verbinden. Es dient als Servicemechanismus, der Datenbanksystemaufrufe richtig transportiert. Dabei sollten beliebige Netz-Architekturen unterstützt werden. Locking und Synchronisation finden nicht auf der Netz-, sondern auf der Datenbank-System-Ebene statt.

Inkompatibilitäten bei der Zusammenarbeit von heterogener Hardware in einem Netz entstehen nach wie vor durch die unterschiedliche Darstellung von Daten in ASCII-Code bei PCs und EBCDIC bei größeren Systemen. Auch wegen der Dialekte dieser Codes und länderspezifischer Zeichen können Probleme beim Auswählen, Mischen oder Synchronisieren von Daten auftreten.

Auf der technischen Ebene gibt es heute starke Unterschiede in Funktionalität und Kompatibilität, denn nicht alle Forderungen lassen sich leicht implementieren, und einige Probleme sind derzeit noch prinzipiell ungelöst. Grundsätzlich gilt, daß als Benutzer weniger der Mensch als die verteilten Anwendungsprogramme zu verstehen sind.

Verteilte Datenbanksysteme lassen sich anhand der Verteilungsart, der Datenbanksichtbarkeit sowie der Aktualisierungsform und der Schnittstellenkompatibilität beschreiben.

Bei der replizierten Verteilung existieren mehrfache Kopien einer gesamten Datenbank oder von Teilen daraus. So ist zum Beispiel eine Preisliste in jeder Filiale vorhanden. Änderungen sollen sofort in allen Kopien wirksam werden. Es gilt, permanent die Konsistenz zu bewahren, auch wenn zeitweise Teile im Netz ausfallen.

Bei partitionierter Verteilung bestehen dagegen disjunkte Bestände logisch gleichartiger Daten an verschiedenen Orten. So haben beispielsweise alle Filialen Kunden, aber nur die eigenen sind vor Ort gespeichert. Abfragen auf den Kundenbestand müssen richtig aufgeteilt, Ergebnisse zusammengemischt und beim Update die Daten in die richtige Datenbank dirigiert werden.

Die Datenbanksicherheit muß physisch und logisch gewährleistet werden. Im ersten Fall rufen die Benutzer (Anwendungsprogramme) die Datenbanksysteme mit sogenannten physischen Aufrufen auf. Sie müssen dabei "wissen", welche Daten sich wo befinden. Die Steuerung und Verantwortung der Verteilung liegt hier beim Benutzer. Präzise sollte man hier von "Remote "Datenbankzugriffen anstatt von verteilten Datenbanksystemen sprechen.

Bei logischen (transparenten) Zugriffen weiß der Benutzer nichts von der Verteilung. Dies entspricht der Date'schen Regel von der Verarbeitung verteilter Zugriffe (siehe Kasten S. 37).

Zwischen Benutzer und Datenbanksystemen wird deshalb eine Schicht in Form eines Koordinators gebraucht, der die logischen Zugriffe in eine optimale Kombination physischer Zugriffe zerlegt und sie auf optimalem Weg durch das Netz weiterleitet.

Dieser Koordinator ist der eigentliche zusätzliche Teil für verteilte DBS mit vielfältigen Aufgaben: Auf dieser Ebene müssen die Informationen über die Datenverteilung netzweit abgeglichen, globale Optimierungen durchgeführt, die Updateverteilung protokolliert und Transaktionen synchronisiert werden. Der Koordinator braucht dazu einen eigenen Datensicherungsmechanismus.

Will der Anwender nicht von einem zentralen Knoten abhängen, muß eine Kopie dieses Koordinators auf jedem Knoten vorhanden sein, und alle Koordinatoren müssen miteinander über das Netz kommunizieren. In aller Regel wird dann der jeweils lokale Koordinator von den Benutzern adressiert (siehe Abbildung 1).

Wegen des schwierigen Problems des koordinierten Restart-/Recovery kommt es bei vielen Lösungen zu Einschränkungen für das Ändern von Daten durch die Benutzer. Man unterscheidet hier die Aktualisierungsformen "remote lesen" und "remote ändern".

Beim Lesen können die Benutzer Daten nur in ihrem lokalen Datenbanksystem ändern. Auf entfernte Daten dürfen sie nur lesend zugreifen. Die konsistente Aktualisierung verteilter Datenbanksysteme ist dagegen ein schwer zu lösendes Problem. Sie kann sowohl synchron als auch asynchron vorgenommen werden.

- Bei der zentralen Aktualisierung lesen die Benutzer lokal und ändern zentral. Da Änderungen nur in einem Datenbanksystem zugelassen sind, ergibt sich kein zusätzliches Synchronisierungsproblem. Die Änderungen werden in der Regel nachts, bei gesperrtem Benutzerbetrieb, von einem zentralen Job wieder an alle lokalen Datenbanksysteme verteilt.

- Bei der asynchronen Aktualisierung ändern die Benutzer lokal und remote, wobei nicht synchronisiert wird. Transaktionen dürfen sich deshalb nur auf ein Datenbanksystem beziehen. Es handelt sich hier eigentlich nur um traditionelle "Remote-Verarbeitung", die dem Benutzer die Verantwortung für die übergreifende Datenkonsistenz aufbürdet.

- Die synchrone Aktualisierung stellt den Wunschtraum für verteilte Datenbanksysteme schlechthin dar, zumal sie Dates Regel über verteiltes Transaktionsmanagement entspricht. Gleichzeitig ist sie aber auch das schwierigste Verfahren.

Nur DBMS, die das Transaktionskonzept beinhalten, kommen für eine synchrone Aktualisierung in Betracht - also bei weitem nicht alle am Markt erhältlichen Systeme. Darüber hinaus ist ein kompatibles Zwei-Phasen-Commit, das bisher nur von ganz wenigen DBMS-Herstellern implementiert ist, notwendig.

Transaktionen sind nach dem derzeitigen Stand der Technik die beste Art, Datenkonsistenz zu bewahren. Eine Transaktion umfaßt eine Menge von Änderungen, die von einem konsistenten Datenbankinhalt wieder zu einem konsistenten Zustand führen, und nur dieser wird konserviert. Kann das Transaktionsende nicht erfolgreich erreicht werden, wird vom DBMS ein Backout vorgenommen. Änderungen einer solchen Transaktion werden nicht wirksam. Es gilt das Alles-oder-Nichts-Prinzip Das DBMS erhält bei Transaktionsende ein Signal vom Benutzer (auch Commit genannt) und führt dann die notwendige Datensicherung durch.

Zur Synchronisierung der Commits reicht ein einfaches Commit-Konzept nicht aus, wie man an folgendem Beispiel leicht erkennen kann: Angenommen, während einer Commit-Synchronisation fallen Teile im Netzwerk aus. Einige beteiligte DBMS haben den Commit schon fertig bearbeitet, während andere ihn gar nicht erhalten können. Wie steht es dann mit der Datenkonsistenz?

Dieses Problem löst nur der Zwei-Phasen-Commit. Dabei wird eine Runde vorläufiger Commits an alle DBS ausgelöst, die in dieser Transaktion geändert wurden, und gewartet, bis alle die Durchführung dieser Phase bestätigen. Überall bleiben die Lockzustände bestehen, die jeweiligen Änderungen werden jedoch permanent gesichert.

Die zweite Phase wird erst danach ausgelöst. Sie beendet die Transaktion endgültig; dabei werden dann die Locksituationen beendet. Im Fehlerfall wird auch in der zweiten Phase ein Backout bei allen noch erreichbaren DBS ausgelöst und ein entsprechender Befehl an alle nicht erreichbaren DBS zwischengespeichert und später nachgereicht.

Diese Forderungen für synchrone Änderungen reduzieren heute mangels Standardisierung die praktischen Realisierungsmöglichkeiten auf homogenen, verteilten Datenbanksystemen. Nur unter starken Einschränkungen kann man heute in zwei lokalen, homogenen Software-Umgebungen drei heterogene Datenbanksysteme synchronisieren.

Ein weiteres Problem bei verteilten Datenbanksystemen ist die Schnittstellenkompatibilität. Am einfachsten ist ein System mit gleichartigen DBMS, das durch Kompatibilität und einheitliche Transaktionssynchronisation hervorsticht.

Anders sieht das für heterogene Systeme mit gleichem konzeptionellen Datenmodell aus. Gemäß Dates Regel über die DBMS-Unabhängigkeit sollen heterogene relationale DBMS für den Benutzer unsichtbar sein. Dies läßt sich nur realisieren, wenn die Abfragesprache aller im Verbund beteiligten DBMS gleich ist. Dies impliziert, daß alle Systeme genau das gleichekonzeptionelle Modell nach der Dreischema-Architektur von ANSI/SPARC unterstützen müssen.

In diesem Zusammenhang sind Standardisierungsbemühungen zu sehen, wie sie heute weltweit bezüglich SQL diskutiert werden. Aus Sicht der verteilten Datenbanken muß die gleichwertige und volle Unterstützung eines Standards von allen im Verbund beteiligten DBMS geordert werden. Dialekte nützen in diesem Zusammenhang nichts. Diese Steckerkompatibilität sowie die zugehörige Optimierbarkeit ist heute noch nicht erreicht. Zum Problem könnte höchstens werden, daß man mit SQL auf einem zu niedrigen semantischen Niveau standardisiert.

Aufgrund historischer Unternehmensentwicklungen, aber auch durch getätigte Hard/Software-Investitionen ist die Koexistenz verschiedenartiger DBMS heute die Regel. Jedes Datenbanksystem hat unterschiedliche Funktionalität, ein logisches und physisches Datenmodell mit unterschiedlichen Strukturen und abweichender Semantik. Das Spektrum reicht heute von hierarchischen, netzwerkartigen über relationale zu Entity-Relationship-basierten und bald zu Objekt-orientierten DBMS.

Verteilte Datenbanken worden zu Views

Diese Situation erschwert die Realisierung erhebliche da die Anwendungen die jeweils fehlende Semantik enthalten müssen, diese aber wegen der Verteilung zielsystemspezifisch ist. Forschung und Entwicklung haben sich dieses Problems angenommen in Form von Bridge, und View-Prozessoren, die nach und nach auf dem Markt erscheinen. Diese stellen Frontends für die DBMS dar. Für den Benutzer werden verteilte Datenbanken, auch solche mit unterschiedlichen SQL-Dialekten, damit zu VIEWS (vergleiche Abbildung 2).

Es besteht ein gewaltiger Druck in Richtung höherwertiger Leistungen im Verbund mit verteilten Datenbanksystemen. Das relationale Modell hat, wie die Mengenlehre, eine Euphorie hervorgerufen, entspricht aber wie diese bei weitem nicht allen praktischen Anforderungen.

Die Innovationszyklen sind kürzer denn je. Heute wird schon in Monaten, anstatt in Jahren gerechnet. Wie lassen sich neue DBMS-Typen integrieren, wie Systeme nach dem Entity-Relationship-Modell, wie solche mit Freitext-Recherche, geographisch-orientierte Datenbank-Systeme, CAD/CIM-Systeme, objektorientierte DBMS... Um all diese Anforderungen zu erfüllen, brauchen wir neue Technologien. Aus heutiger Sicht können dies nur objektorientierte Ansätze effizient und zuverlässig leisten.

Eine konsequente Dokumentation des unternehmensweiten Informationsmodells mit einem mächtigen Dictionary-Tool auf der Basis des Entity-Relationship-Modells erscheint unerläßlich. Dabei soll hier nicht erörtert werden, wie das Dictionary zweckmäßig verteilt wird.

Mit dem praktischen Einsatz verteilter Datenbanken kann die Erhaltung der netzweiten Datenkonsistenz zu einer Überlebensfrage für Unternehmen werden. Das spricht für eine bedachtsame Verwirklichung verteilter Datenbanksysteme in der Praxis, wobei die Verantwortungsstruktur für die Daten und die Organisation der Dictionary- und Datenbankadministration berücksichtigt wird.

Konsistenz auf einem semantisch höheren Niveau

Es sollte aber auch ein Ansporn an die Entwickler solcher Systeme sein, Konsistenz auf einem semantisch höheren Niveau in den Datenbanksystemen zur Verfügung zu stellen. Auch das gehört zu den Forderungen von Praktikern nach höherwertigen Diensten. Dazu werden zuerst semantisch reichere Datenmodelle als das relationale Modell benötigt, auf deren Basis dann komplexere Locking-, Konsistenz- und Recovery-Mechanismen definiert und implementiert werden können. Das ist der Zusammenhang, in dem die aktuelle Diskussion um strukturelle Objekt-Orientierung zu sehen ist.

Da pro Bildschirmtransaktion in der Regel mehrere Datenbankzugriffe erforderlich sind, kann aus der Datenbankschicht allein der Verkehr im Netz nicht minimiert werden. Deshalb ist es notwendig, über höherwertige Dienste wie das objektorientierte "Function-shipping" nachzudenken.

Bei diesem Verfahren wird eine angestoßene Benutzerfunktion im Sinne einer objektorientierten Aktion im Netz an denjenigen Knoten (Client-Server) delegiert, der diese Funktion am besten (schnellsten, billigsten, mit geringster Netzbelastung) erfüllen kann. Nur die Ergebnisse kommen über das Netz an den Benutzer zurück. Hier könnten datenbankorientierte Kriterien bei der Auswahl des Servers dazu führen, daß derjenige Server benutzt wird, der für die gegebene Transaktion die Daten auf kürzestem Wege erreicht. Ziel ist nicht nur eine Optimierung der Netzbelastung aus einer höheren Sicht, sondern auch eine Vereinfachung der zu programmierenden Logik in den Anwendungsprogrammen durch mächtigere, Semantik-intensive Operatoren.

Dieses Optimierung kommt der Produktivität bei Entwicklung und Wartung solcher Anwendungen zugute. Dazu wäre es notwendig, die gesamte Protokollebene (APPC) auf die Systemebene zu verlagern.

Sprengung des relationalen Rahmens

Objektorientierte aktive View-Prozessoren werden als erstes auf diesem Wege heutige und zukünftige, heterogene DBMS in Abfragen und Transaktionen verbinden. Dabei verhalten sich die Views dem Benutzer gegenüber als Objekte komplexen Struktur mit definierten Aktionen.

Bei Views werden die Aktionen über mehrere Datenbanksysteme hinweg in DBMS-orientierte Einheiten aufgesparten, die dann dynamisch aufgerufen werden, um die Teile zusammenzusetzen. Dies gilt auch für Transaktionen mit Updates. Die Unterstützung strukturell komplexer und zusammengesetzter Objekte sprengt den relationalen Rahmen, der sich für die Zukunft mehr als Engpaß denn als Hilfe erweist.

Die landläufige Abgrenzung des Begriffes Datenbank zerfließt hier erneut. Wir werden objektorientierte Datenbankschnittstellen und damit objektorientierte DBMS schneller als erwartet brauchen.

Das Kennzeichen der Objektorientierung ist, daß man beliebig dekomponieren und aggregieren kann, ohne das Prinzip der Objektorientierung zu verlassen. Damit ist man auf einer einheitlichen Ebene, die gleichermaßen für einfache wie komplexe Services geeignet ist, angekommen. Unsere Directories und Dictionaries werden dann Objektdefinitionen und verteilte, ausfahrende Instanzen und nicht nur Datenbankschemata enthalten.

Anforderungen an die Funktionalität steigen

Verteilte Datenbanksysteme gewinnen zusammen mit den hohen und noch steigenden Erwartungen an die Funktionalität an Bedeutung. Dazu zählen eine für die Benutzer transparente Transaktionssynchronisation nach dem Zwei-Phasen-Prinzip, standardisierte Schnittstellen und globale Optimierungsstrategien. Auch Lösungen für das Koexistenzproblem werden gebraucht.

Damit nicht genug. Amerikanische Analysten berichten heute schon über Klagen, daß Funktionalität auf einem höheren Niveau fehlt. Die Zukunft geht in Richtung objektorientierter Ansätze wie aktive View-Prozessoren und das Function-Shipping, in das nicht nur verteilte Datenbanksysteme eingebunden sein werden.

Zwölf Regeln für verteilte Datenbanken nach Chris Date

1: Lokale Autonomie: Jeder Knoten kann allein arbeiten.

2: Unabhängigkeit von einem zentralen Knoten.

3: Ununterbrochener Betrieb.

4, 5 und 6: Orts-, Fragmentierungs- und Replizierungsunabhängigkeit: Für den Benutzer ist die Verteilung transparent.

7: Verteilte Zugriffsverarbeitung.- Der Benutzer stellt nur logische Datenbankfragen.

8: Verteiltes Transaktionsmanagement: Netzweites Update und Transaktionssynchronisation mit Zwei-Phasen-Commit.

9, 10 und 11: Hardware-, Betriebssystem- und Netzwerkunabhängigkeit: Unterstützung heterogener Umgebungen in einem Netz.

12: DBMS-Unabhängigkeit: Unterstützung verschiedener DBMS im Verbund.

Grundbegriffe:

- Unter einer Datenbank wird der Datenbestand als Teil eines Datenbanksystems verstanden.

- Datenbank-Management-Systeme (DBMS) sind leistungsstarke, systemnahe Programme als Teil eines Datenbanksystems. Sie bearbeiten die Aufrufe der Benutzer und managen die Datenbank, wobei sie unter anderem deren Konsistenzerhalt gewährleisten. DBMS haben daher alleiniges physisches Zugriffsrecht auf die Datenbank. Alle Benutzer sehen die Daten nur durch diese "Brille".

- Die operationale Kombination eines DBMS mit einer Datenbank wird Datenbanksystem (DB) genannt. Nur diese Kombination bedient die Benutzerwünsche.

- Als verteilte Datenbanken bezeichnet man Datenbestände, die insgesamt benutzt werden können. Dies ist die Minimalforderung. Chris Date ist mit seinen "Twelve rules for a distributed data base" (Computerworld, June 8, 1987) wesentlich weitergegangen. Seine Regeln stellen als Sollforderungen eine gute Meßlatte dar (vergleiche Kasten).

* Jürgen Kirbach ist Berater bei der international Marketing consultant der Software AG, Darmstadt.