Verteilte Datenbanksysteme

Erhard Rahm
Fachbereich Informatik,
Universität Kaiserslautern

Computer-Anwendungen verlangen zunehmend den Zugriff auf verteilt gespeicherte Datenbanken. Verteilte Datenbanksysteme stellen hierzu eine geeignete Systemstruktur dar, die Anwendungsprogrammen und Benutzern eine Zugriffsschnittstelle wie auf eine zentrale Datenbank bietet. Um eine solche Verteilungstransparenz zu erreichen, sind von der Datenbank-Software jedoch eine Reihe schwieriger technischer Probleme zu bewältigen.

Herkömmlicherweise werden die Daten eines Unternehmens, einer Institution o.ä. in einer zentralen Datenbank (DB) gespeichert, auf die über ein Datenbank-Managementsystem (DBMS) zugegriffen wird. Das DBMS verbirgt sämtliche Internas der Datenorganisation und -speicherung gegenüber den Anwendungen; der Datenbankzugriff erfolgt in der Regel über eine deskriptive und ausdrucksstarke Anfragesprache wie z.B. SQL. Datenbanksystem sowie Anwendungsprogramme, die auf die Datenbank zugreifen, laufen meist in einem Rechner ab. Die eigentlichen Benutzer (z.B. Sachbearbeiter einzelner Abteilungen) sind mit der Zentralen nur über Terminals oder sonstige Endgeräte verbunden. Diese, an einem Rechenzentrum orientierte Systemstruktur wird jedoch in vielen Fällen der Organisationsform eines Unternehmens nicht gerecht. So würde bei einer Großbank mit mehreren Filialen das zentralistische Modell vorschreiben, sämtliche Konten, Personaldaten usw. aller Zweigstellen zentral zu führen. Dies führt zum einen zu einem hohen Kommunikationsaufwand zwischen Filialen und Zentrale, da in den Zweigstellen kein lokaler Datenzugriff möglich ist. Zudem können die starken Abhängigkeiten von der Zentrale zu Akzeptanzproblemen führen und ggf. eine unkontrollierte Verwaltung lokaler Daten hervorrufen. Werden z. B. in den Zweigstellen Kopien der sie betreffenden Personaldaten geführt, dann sind dort eigene Anwendungen zu entwickeln, die u.a. sicherstellen, daß die Kopien der einzelnen Datenbestände auf dem gleichen Stand sind. Eine Vervielfachung derartiger Datenverwaltungs- und Konsistenzprobleme ergibt sich mit der Möglichkeit, private Datenbanken auf PCs und Workstations zu halten.

Signifikante Vorteile durch Verteilte Datenbanksysteme

Verteilte Datenbanksysteme gestatten eine Anpassung der Systemstruktur an die jeweilige Organisationsstruktur, ohne die Konsistenz der Datenbank zu beeinträchtigen. Eine logische Datenbank wird dabei unter mehreren Datenbanksystemen physisch aufgeteilt, wobei die einzelnen DBMS in der Regel auf verschiedenen und üblicherweise geographisch verteilten Rechnern laufen. Die DBMS der einzelnen Rechner kooperieren eng miteinander, um Datenbankoperationen auf dem verteilten Datenbestand zu bearbeiten. Durch die Kooperation auf Ebene der Datenbanksysteme können gegenüber Anwendungsprogrammen und Benutzern sämtliche Aspekte der Verteilung verborgen werden; für sie ergibt sich keine Änderung in der Zugriffsschnittstelle gegenüber dem zentralen Fall. Die Gewährleistung einer solchen Verteilungstransparenz ist die Hauptforderung an Verteilte Datenbanksysteme. Sie ist wesentlich für eine einfache Benutzbarkeit des verteilten Systems, da trotz der Verteilung sämtliche Funktionen der Datenverwaltung Aufgabe der Datenbank-Software bleiben. Insbesondere bleiben somit Änderungen in der Datenverteilung ohne Auswirkungen auf bestehende Anwendungsprogramme. In der erwähnten Bankanwendung ließe sich so eine Anpassung an die Organisationsstruktur erreichen, in dem jeder Zweigstelle ein lokales DBMS zugeordnet wird, das die sie betreffenden Konto- und Personaldaten verwaltet. Durch Kooperation mit den DBMS anderer Zweigstellen ist weiterhin der Zugriff auf den gesamten Datenbestand möglich. Die Anwendungen der zentralistischen Systemstruktur sollten dabei im Idealfall ohne Modifikation übernommen werden können.

Neben der Unterstützung dezentraler Organisationsformen bieten Verteilte Datenbanksysteme eine Reihe wesentlicher Vorteile bezüglich Leistungsfähigkeit, Verfügbarkeit und Kosteneffektivität. Ein einzelner Rechner kann leicht zum Systemengpaß werden und somit Durchsatz und Antwortzeiten beim Datenbankzugriff beeinträchtigen. Bei Verteilten Datenbanksystemen steht dagegen die Verarbeitungskapazität mehrerer Rechner zur Verfügung; zudem kann die Leistungsfähigkeit durch Erhöhung der Rechneranzahl inkrementell erweitert werden. Kurze Antwortzeiten werden dadurch unterstützt, da in vielen Anwendungen die Mehrzahl der Zugriffe nur lokal gespeicherte Daten betreffen, so daß Kommunikationsverzögerungen mit entfernten Rechnern weitgehend entfallen. So betreffen z.B. bei der Bankanwendung die meisten Kontenbewegungen (Abhebung, Einzahlung, etc.) Konten der jeweiligen Zweigstelle. Ein weiterer Nachteil der zentralisierten Systemarchitektur ist ihre geringe Verfügbarkeit, da der Ausfall des zentralen DB-Rechners den gesamten Betrieb lahmlegt, wenn nicht ein Reserverechner die Verarbeitung fortsetzen kann. Im verteilten Fall dagegen betrifft ein Rechnerausfall lediglich die von ihm verwaltete Datenmenge; die DB-Verarbeitung auf den übrigen Rechnern (in anderen Zweigstellen) bleibt davon unberührt. Eine weitere Steigerung der Verfügbarkeit wird erreicht, wenn Teile der Datenbank - unter Kontrolle der DBMS - repliziert gespeichert werden. Damit kann nach einem Rechnerausfall weiterhin auf die gesamte Datenbank zugegriffen werden, wenn die vom Ausfall betroffenen Daten an einem weiteren Rechner vorliegen. Schließlich unterstützen Verteilte Datenbanksysteme eine höhere Kosteneffektivität als mit einem zentralisiertem Ansatz. In letzterem Fall kann nämlich eine ausreichend hohe Verarbeitungskapazität oft nur durch Großrechner (Mainframes) und damit zu hohen Kosten erreicht werden. Verteilte Datenbanksysteme erlauben dagegen die Nutzung mikroprozessorbasierter Rechnerknoten mit typischerweise weit geringeren Kosten pro MIPS als Großrechner.

Hohe Anforderungen an DB-Software und Administration

Um die genannten Vorteile erreichen zu können, wird jedoch eine komplexe Realisierung für die DB-Software erforderlich. C.J. Date [4] formulierte die wichtigsten Anforderungen, die ein Verteiltes Datenbanksystem idealerweise erfüllen sollte, durch 12 sogenannte "Regeln" (siehe Kasten). Die technischen Schwierigkeiten, diese Anforderungen zu erfüllen, führten dazu, daß trotz intensiver Forschungsarbeiten auf dem Gebiet der Verteilten Datenbanksysteme erst Mitte der achtziger Jahre die ersten Systeme auf den Markt kamen. Mittlerweile ist bereits eine Vielzahl verteilter Datenbanksysteme kommerziell verfügbar (z.B. Ingres Star, Tandem NonStop SQL, Oracle, etc.), jedoch zumeist ohne den wünschenswerten Funktionsumfang voll abzudecken. Die meisten der 12 Anforderungen betreffen Einzelaspekte hinsichtlich der Gewährleistung von Verteilungstransparenz, insbesondere die Unterstützung von Orts-, Fragmentierungs- und Replikationstransparenz (Regeln 4-6) sowie von Hardware-, Betriebssystem-, Netzwerk- und Datenbanksystemunabhängigkeit (Regeln 9-12). Da eine DB-Anfrage (Query) den Zugriff auf Daten mehrerer Rechner erfordern kann, ist daneben eine verteilte Anfragebearbeitung zu unterstützen (Regel 7). Regel 8 betrifft verteilte Änderungstransaktionen, deren korrekte Abwicklung geeignete Erweiterungen in der Transaktionsverwaltung erfordert (s.u.). Während die Gewährleistung von Verteilungstransparenz eine enge Kooperation der beteiligten DBMS erfordert, repräsentiert die Forderung nach lokaler Autonomie (Regel 1) eine offenbar entgegengesetzte Zielsetzung, die sich daher i.a. auch nur zum Teil erfüllen läßt. Generell ist jedoch anzustreben, daß die Zugriffe auf lokale Daten eines Rechners unabhängig von der Verfügbarkeit externer Knoten möglich sein sollte. Dies impliziert u.a., daß Abhängigkeiten zu zentralisierten Systemfunktionen zu verhindern sind (Regel 2).

Auch die Administration eines Verteilten Datenbanksystems ist weitaus komplexer als die eines zentralen DBMS. Insbesondere ist die physische Aufteilung der Datenbank i.a. durch die Systemverwalter festzulegen und anzupassen, wobei unter Berücksichtigung von Anwendungsmerkmalen ein möglichst hoher Anteil lokaler Datenbankzugriffe unterstützt werden sollte. Diese komplexe Aufgabe sollte systemseitig durch geeignete Werkzeuge unterstützt werden. Änderungen bezüglich logischem Datenbankaufbau, Zugriffsberechtigungen, etc. sind auch global abzustimmen und können daher eine Beeinträchtigung der lokalen Autonomie darstellen.

Bestimmung der Datenverteilung

Der Einsatz eines Verteilten Datenbanksystems verlangt die Festlegung einer physischen Aufteilung des Datenbestandes. Diese Aufgabe läßt sich in zwei Teilprobleme, Fragmentierung und Allokation, unterteilen. Im Rahmen der Fragmentierung werden dabei zunächst die Einheiten der Datenverteilung (Fragmente) festgelegt. Die Allokation bestimmt danach, welchem Rechner (DBMS) jedes der Fragmente zugeordnet wird. Unterstützt das Verteilte Datenbanksystem eine replizierte Speicherung von Daten, können die Fragmente mehreren Rechnern zugeordnet werden.

In relationalen Datenbanksystemen, auf die wir uns hier ausschließlich beziehen, stellen im einfachsten Fall Relationen (Tabellen) die kleinsten Verteilungsgranulate dar. Da dies jedoch häufig zu inflexibel ist, sollte es möglich sein, feinere Fragmente zu definieren. Hierzu kommt eine zeilenweise (horizontale) oder spaltenweise (vertikale) Aufteilung von Sätzen der Relation in Betracht. Am weitesten verbreitet ist dabei die horizontale Fragmentierung, bei der jeder Satz genau einem Fragment zugeordnet ist. Die Zuordnung von Sätzen zu Fragmenten wird dabei i.a. über Prädikate auf den Attributen der Relation definiert. Fragmentierung sowie Allokation sind natürlich auf die jeweilige Anwendung abzustimmen, um eine Verarbeitung mit möglichst wenig Kommunikationsaufwand zu unterstützen. In der Bankanwendung könnten z.B. die Kontodaten nach der zugehörigen Zweigstelle horizontal fragmentiert und jedes der Fragmente dem DBMS der jeweiligen Zweigstelle zugeordnet werden.

Fragmentierungstransparenz verlangt, daß die vorgenommene Fragmentierung für den Benutzer verborgen bleibt; er bezieht sich auf die logische Definition der Relation. Um in dem Bankbeispiel etwa die Summe aller Kontostände zu ermitteln, kann die Anfrage auch bei Fragmentierung der Kontorelation wie im zentralen Fall formuliert werden:

      SELECT SUM (Ktostand) FROM KONTO.

Bei fehlender Fragmentierungstransparenz müßte dagegen für jede Zweigstelle die lokale Summe durch eine eigene Anweisung bestimmt werden, um daraus anschließend die Gesamtsumme manuell zu berechnen. Dies ist auch erforderlich, wenn nur Ortstransparenz gewährleistet wird, da diese keine Fragmentierungstransparenz impliziert (Ortstransparenz besagt lediglich, daß der Ort, an dem ein Fragment gespeichert ist, für den Benutzer nicht bekannt sein muß).

Anfrageübersetzung

Aufgabe der Anfrageübersetzung ist es, zu einer relationalen DB-Anfrage einen Ausführungsplan zu bestimmen, der eine möglichst effiziente Bearbeitung der Operation ermöglicht. Diese Aufgabe ist bereits für zentralisierte DBMS komplex, da i.a. eine große Anzahl alternativer Ausführungsstrategien besteht. Im verteilten Fall ist die Bestimmung eines möglichst optimalen Ausführungsplans noch weitaus komplizierter, da neben CPU- und E/A-bezogenen Ausführungskosten der Kommunikationsaufwand (Anzahl und Umfang von Nachrichten) als weiterer Faktor zu berücksichtigen ist. Sind Teile der Datenbank repliziert gespeichert, ergeben sich für die Anfrageübersetzung weitergehende Optimierungsmöglichkeiten. Denn für den Datenzugriff kann dann unter mehreren Kopien gewählt werden, um möglichst geringe Kommunikationskosten zu erhalten. Weiterhin besteht die Möglichkeit, eine Anfrage parallel an verschiedenen Rechnern zu bearbeiten, um ihre Antwortzeit zu reduzieren.

Die Erstellung eines verteilten Ausführungsplanes ist für die Beispielanfrage zur Berechnung der Kontostandsumme vergleichsweise einfach. Hierzu fordert das DBMS, welches die Anfrage zur Bearbeitung erhielt, die DBMS der anderen Rechner auf, bezüglich ihrer Konten die Kontostände zu summieren. Dies kann natürlich in jedem Rechner parallel erfolgen. Aus den Teilergebnissen wird dann einfach die Gesamtsumme errechnet und an den Benutzer zurückgeliefert. Eine alternative Vorgehensweise wäre, keine lokale Summenberechnung vorzunehmen, sondern sämtliche Kontostände an einen Rechner zu übertragen, der dann direkt die Gesamtsumme ermittelt. Dieser Ansatz verursacht offenbar einen weit höheren Kommunikationsaufwand und scheidet daher aus. Kommunikation läßt sich bei der Anfragebearbeitung einsparen, wenn Teile der Datenbank repliziert gespeichert sind. Hält z.B. ein Rechner eine Kopie sämtlicher Fragmente der Kontorelation, kann die Anfrage an diesem Knoten vollkommen lokal bearbeitet werden. Für komplexere Anweisungen, die z.B. einen Verbund (Join) zwischen mehreren Relationen erfordern, ist die Auswertung natürlich weitaus schwieriger zu optimieren als für unsere Beispielanfrage. Aus Platzgründen sei hierzu jedoch auf die weiterführende Literatur verwiesen.

Anwendungsprogramme bleiben aufgrund der Verteilungstransparenz von Änderungen in der Datenverteilung unberührt, nicht jedoch die bei der Programmübersetzung erstellten Ausführungspläne. Das System muß daher in der Lage sein, von Umverteilungen betroffene Ausführungspläne automatisch zu erkennen und neu zu bestimmen.

Transaktionsverwaltung

Wie in zentralisierten DBMS stellen auch in Verteilten Datenbanksystemen Transaktionen die Einheiten der DB-Verarbeitung dar. Eine Transaktion umfaßt dabei eine oder mehrere DB-Operationen, für die die DB-Software die sogenannten Transaktionseigenschaften gewährleistet. Dazu zählt vor allem die Alles-oder-Nichts-Eigenschaft (Atomarität), die besagt, daß Änderungen einer Transaktion entweder vollständig oder überhaupt nicht in die Datenbank übernommen werden. Weiterhin wird erfolgreichen Transaktionen die Dauerhaftigkeit ihrer Änderungen zugesichert, d.h. sie gehen trotz möglicher Fehlersituationen (Rechner- oder Plattenausfall, Kommunikationsfehler) nicht mehr verloren. Diese Zusicherungen werden möglich, in dem das DBMS Änderungen in spezielle Log-Dateien protokolliert und für die erwarteten Fehlerfälle geeignete Recovery-Funktionen bereitstellt. Eine weitere Aufgabe der Transaktionsverwaltung betrifft die Synchronisation (Concurrency Control) von gleichzeitig auf der Datenbank arbeitenden Benutzern, um Inkonsistenzen zu vermeiden. Dazu werden üblicherweise Sperrverfahren verwendet (Locking), bei denen vor dem Zugriff auf ein DB-Objekt eine entsprechende Sperre für die Transaktion angefordert wird, um zu verhindern, daß andere Transaktionen dasselbe Objekt in unverträglicher Weise referenzieren.

Die Transaktionseigenschaften sind nun auch bei verteilter Verarbeitung einer Transaktion einzuhalten. Da dabei eine Transaktion Änderungen an mehreren Rechnern vornehmen kann, ist vor allem zur Sicherstellung der Atomarität eine Koordinierung zwischen den beteiligten DBMS erforderlich. Hierzu wird üblicherweise ein verteiltes Zweiphasen-Commit-Protokoll eingesetzt. Dabei fungiert das DBMS des Rechners, an dem die Transaktion gestartet wurde, als Koordinator. Das Protokoll, das am Ende einer Transaktion durch den Koordinator gestartet wird, umfaßt folgende zwei Phasen:

• 1. Der Koordinator schickt eine "Prepare-to-Commit"-Nachricht an alle DBMS, die an der Bearbeitung der Transaktion beteiligt waren. Jedes dieser DBMS trifft eine lokale Entscheidung über den Ausgang der Transaktion (Commit für erfolgreiche, Abort für erfolglose Beendigung) und sendet das Ergebnis an den Koordinator zurück. Nach Eingang aller Teilergebnisse beim Koordinator ist Phase 1 beendigt.
• 2. Der Koordinator bestimmt aus den Teilergebnissen den Ausgang der Transaktion und protokolliert das Ergebnis in seine Log-Datei. Das Gesamtergebnis ist dabei "Commit", falls alle beteiligten DBMS mit "Commit" gestimmt haben, ansonsten ist die Transaktion zurückzusetzen (Abort). Das Gesamtergebnis wird vom Koordinator den beteiligten DBMS mitgeteilt, die daraufhin die Transaktion entweder zurücksetzen oder erfolgreich beenden. Sperren der Transaktion werden erst zu diesem Zeitpunkt freigegeben. Danach wird eine Quittierung an den Koordinator geschickt, um dort die Beendigung der Transaktion zu ermöglichen.

Ein gewisses Problem bei dem skizzierten Protokoll ist die Abhängigkeit vom Koordinator, da eine Sperrfreigabe an anderen Rechnern erst möglich ist, wenn dieser das Commit-Ergebnis mitgeteilt hat. Der Ausfall des Koordinatorrechners während des Commit-Protokolls kann daher zu langen Blockierungen führen. In der Literatur wurden zwar verschiedene Abhilfen dazu (auf Kosten einer erhöhten Nachrichtenanzahl) vorgeschlagen, jedoch sind diese Verfahren in kommerziellen Systemen nicht implementiert.

Die Sperrverwaltung ist auch im verteilten Fall relativ einfach möglich, in dem jedes DBMS die Sperren bezüglich der ihm zugeordneten Daten verwaltet. Wartesituationen aufgrund unverträglicher Sperren können jetzt jedoch zu rechnerübergreifenden Verklemmungen führen. Ein solcher globaler Deadlock tritt z.B. auf, wenn eine Transaktion T1 von Rechner R1 an Rechner R2 auf eine Sperre einer Transaktion T2 warten muß und T2 danach auf Rechner R1 eine Sperre anfordert, die von T1 bereits gehalten wird. In der Bankanwendung wäre dies etwa der Fall, wenn T1 eine Überweisung von einem Konto K1 von Rechner (Filiale) R1 auf Konto K2 von R2 vornimmt und T2 zeitgleich eine Überweisung von K2 nach K1. Die einfachste Methode zur Behandlung globaler Deadlocks ist ein Timeout-Verfahren, bei dem eine Transaktion nach Überschreiten einer maximalen Sperrwartezeit zurückgesetzt wird. Eine genauere Analyse der Wartebeziehungen im Rahmen eines verteilten Deadlock-Erkennungsverfahrens ermöglicht i.a. globale Deadlocks mit weniger Rücksetzungen zu beheben, jedoch unter Inkaufnahme zusätzlicher Nachrichten.

Replizierte Datenbanken

Wie erwähnt gestattet die replizierte Speicherung von Teilen der Datenbank eine Erhöhung der Verfügbarkeit sowie größere Möglichkeiten zur effizienten Bearbeitung lesender DB-Operationen. Auf der anderen Seite wird natürlich ein erhöhter Speicherplatzbedarf eingeführt und Änderungen sind auf sämtliche Kopien anzuwenden, um die Konsistenz der Datenbank zu wahren. Die Forderung nach Replikationstransparenz verlangt dabei, daß die Replikation für den Benutzer unsichtbar bleibt und die Wartung der Redundanz somit durch das DBMS zu erfolgen hat.

Ein Ansatz zur Wahrung der DB-Konsistenz bei replizierten Datenbanken besteht darin, bei der Änderung eines Objektes sämtliche Kopien zu sperren und diese im Rahmen der Commit-Behandlung zu aktualisieren. Der offensichtliche Nachteil besteht in einer hohen Nachrichtenanzahl zum Sperren und Aktualisieren aller Kopien, was zudem eine starke Antwortzeitverlängerung für ändernde Transaktionen bewirkt. Darüber hinaus ergibt sich potentiell keine Verbesserung, sondern sogar eine Verschlechterung der Verfügbarkeit, da eine Änderung prinzipiell verlangt, daß sämtliche Kopien verfügbar sind. Ein alternativer Ansatz besteht darin, für jedes Objekt an einem der Rechner eine sogenannte Primärkopie zu führen. In diesem Fall brauchen Änderer nur die Primärkopie zu sperren und zu aktualisieren. Die übrigen Kopien werden vom Primärkopienrechner asynchron aktualisiert, ohne also die Antwortzeit für die Änderungstransaktionen zu erhöhen. Ein Nachteil dabei ist, daß die asynchron aktualisierten Kopien leicht veraltet sein können, was in vielen Anwendungen jedoch toleriert werden kann.

Ausblick

Verteilte Datenbanksysteme stellen aus Benutzersicht die optimale Systemstruktur zur Nutzung verteilter Datenbestände dar, da sämtliche Aspekte der Verteilung durch System-Software verborgen werden. Auf der anderen Seite führen sie zu einer hohen Komplexität des DBMS sowie der Systemadministration und lassen - aufgrund der erforderlichen Kooperation zwischen den beteiligten Datenbanksystemen - nur ein begrenztes Maß an lokaler Autonomie zu. Vor allem letzterer Punkt, der insbesondere bei heterogenen Datenbanksystemen mit unabhängig voneinander entworfenen Datenbanken von Bedeutung ist, führte dazu, daß in der Praxis weitere Systemstrukturen zur verteilten Datenbankverarbeitung anzutreffen sind, die einen geringeren Grad an Verteilungstransparenz bieten. Zu nennen sind hier vor allem aktuelle Standardisierungsbemühungen wie RDA (Remote Database Access), die es erlauben, in einem Anwendungsprogramm DB-Operationen an unterschiedliche Datenbanksysteme zu stellen. Die Existenz verschiedener Datenbanken ist dabei jedoch für den Anwendungsprogrammierer sichtbar; zudem kann innerhalb einer DB-Operation nur auf Daten eines Rechners (DBMS) zugegriffen werden. Einen Kompromiß zwischen letzterem Ansatz sowie Verteilten Datenbanksystemen stellen sogenannte Föderative Datenbanksysteme (federated DBMS) dar, die derzeit im Mittelpunkt vieler Forschungsprojekte stehen. Diese Ansätze streben eine weitgehende Autonomie der einzelnen Rechner sowie eine Unterstützung heterogener DBMS an, die z.B. Unterschiede bezüglich Anfragesprache, Datenmodell, Datentypen, Synchronisations- und Recovery-Verfahren aufweisen können. Trotzdem soll durch eine begrenzte Kooperation der einzelnen DBMS eine verteilte Bearbeitung einzelner DB-Operationen sowie eine korrekte Transaktionsverwaltung ermöglicht werden. Einen weiteren Entwicklungstrend stellen Parallele Datenbanksysteme zur hochgradig parallelen Bearbeitung von komplexen und datenintensiven DB-Operationen dar. Solche Architekturen weisen zwar viele Gemeinsamkeiten mit Verteilten Datenbanksystemen auf, jedoch steht bei ihnen die effiziente DB-Bearbeitung innerhalb eines lokal verteilten Mehrrechnersystems mit hoher Kommunikationsbandbreite im Vordergrund.

Literatur

[1] R. Bayer, K. Elhardt, K. Kießling, D. Killar: Verteilte Datenbanksysteme - Eine Übersicht über den heutigen Entwicklungsstand. Informatik-Spektrum 7 (1), S. 1-19, 1984

[2] D. Bell, J. Grimson: Distributed Database Systems. Addison Wesley, 1992

[3] S. Ceri, G. Pelagatti: Distributed Databases: Principles and Systems. McGraw-Hill, 1984

[4] C.J. Date: An Introduction to Database Systems, 5th edition (Chapter 23). Addison Wesley, 1990

[5] M.T. Özsu, P. Valduriez: Principles of Distributed Database Systems. Prentice Hall, 1991

[6] A. Reuter: Verteilte Datenbanksysteme: Stand der Technik und aktuelle Entwicklungen. Proc. 18. GI-Jahrestagung, Informatik-Fachberichte 187, Springer-Verlag, S. 16-33, 1988

---

Last Modified: 11:05am MEZ, June 04, 1996