4 Architektur von Verteilten Datenbanksystemen

4.1 Transparenzeigenschaften

Die in Kap. 1.2 genannten Anforderungen an Mehrrechner-DBS sollen natürlich auch von Verteilten DBS erfüllt werden, insbesondere hohe Leistungsfähigkeit, hohe Verfügbarkeit, Verteilungstransparenz sowie Unterstützung dezentraler (geographisch verteilter) Organisationsstrukturen. Ähnliche Anforderungen postulierte Date [Da90] innerhalb von zwölf "Regeln" (Abb. 4-2), wobei als Grundregel ("Regel 0") Verteilungstransparenz (distribution transparency) verlangt wird. Die meisten der 12 Anforderungen betreffen daher auch Einzelaspekte hinsichtlich der Gewährleistung von Verteilungstransparenz, insbesondere die Unterstützung von Orts-, Fragmentierungs- und Replikationstransparenz (Regeln 4-6) sowie Unabhängigkeit gegenüber der eingesetzten Hardware, Betriebssysteme, Netzwerke und Datenbanksysteme (Regeln 9-12). Ferner muß das Transaktionskonzept auch im verteilten Fall gewahrt bleiben (Regel 8), insbesondere für Änderungstransaktionen. Dies impliziert die Gewährleistung von Fehlertransparenz (Atomarität von Transaktionen) sowie Transparenz der Nebenläufigkeit (concurrency transparency [TGGL82], logischer Einbenutzerbetrieb). Da eine DB-Anfrage (Query) den Zugriff auf Daten mehrerer Rechner erfordern kann, ist daneben eine verteilte Anfragebearbeitung zu unterstützen (Regel 7).

Die Diskussion in Kap. 3 zeigte bereits, daß heterogene DBS i.a. den Einsatz föderativer Mehrrechner-DBS bzw. von verteilten DC-Systemen verlangen, so daß Forderung 12 von Verteilten DBS nicht erfüllt werden kann[12]. Auch die Forderung nach Knotenautonomie bzw. lokaler Autonomie (Regel 1) kann i.a. nur teilweise erfüllt werden, da sie der Unterstützung vollständiger Verteilungstransparenz entgegensteht. Denn die Unterstützung eines globalen konzeptionellen Schemas durch alle Knoten erfordert, daß jede DB-Operation darauf auf jedem Rechner ausführbar sein muß. Dies verlangt eine enge Zusammenarbeit der einzelnen DBVS bei der Anfragebearbeitung, eine Koordinierung bei Änderungen im logischen DB-Aufbau sowie die globale Definition von Zugriffsberechtigungen. Allerdings ist generell anzustreben, daß die Zugriffe auf lokale Daten eines Rechners unabhängig von der Verfügbarkeit externer Knoten möglich sein sollten. Dies impliziert u.a., daß Abhängigkeiten zu zentralisierten Systemfunktionen möglichst zu verhindern sind (Regel 2). Jeder Knoten sollte stattdessen auch die Metadaten, Zugriffsrechte, Sperren etc. für die bei ihm gespeicherten Daten verwalten.

Abb. 4-2: Zwölf "Regeln" für Verteilte DBS nach Date [Da90]
  1. Lokale Autonomie
    Jeder Rechner sollte ein Maximum an Kontrolle über die bei ihm gespeicherten Daten haben. Insbesondere sollte der Zugriff auf diese Daten nicht von anderen Rechnern abhängen.

  2. Keine Abhängigkeit von zentralen Systemfunktionen
    Zur Unterstützung einer hohen Knotenautonomie und Verfügbarkeit sollte die Datenbankverarbeitung nicht von zentralen Systemfunktionen abhängen. Solche Komponenten stellen zudem einen potentiellen Leistungsengpaß dar.

  3. Hohe Verfügbarkeit
    Die Datenbankverarbeitung sollte trotz Fehlern im System (z.B. Rechnerausfall) oder Konfigurationsänderungen (Installation neuer Software oder Hardware) idealerweise nicht unterbrochen werden.

  4. Ortstransparenz
    Die physische Lokation von Datenbankobjekten sollte für den Benutzer verborgen bleiben. Der Datenzugriff sollte wie auf lokale Objekte möglich sein.

  5. Fragmentierungstransparenz
    Eine Relation der Datenbank sollte verteilt an mehreren Knoten gespeichert werden können. Die dabei zugrundeliegende Zerlegung (Fragmentierung) der Relation sollte für den Datenbankbenutzer transparent bleiben.

  6. Replikationstransparenz
    Die replizierte Speicherung von Teilen der Datenbank sollte für den Benutzer unsichtbar bleiben; die Wartung der Redundanz obliegt ausschließlich der DB-Software.

  7. Verteilte Anfrageverarbeitung
    Innerhalb einer DB-Operation sollte auf Daten mehrerer Rechner zugegriffen werden können. Zur effizienten Bearbeitung sind durch das Verteilte DBS geeignete Techniken bereitzustellen (Query-Optimierung).

  8. Verteilte Transaktionsverwaltung
    Die Transaktionseigenschaften sind auch bei verteilter Bearbeitung einzuhalten, wozu entsprechende Recovery- und Synchronisationstechniken bereitzustellen sind (verteiltes Commit-Protokoll, Behandlung globaler Deadlocks, u.a.).

  9. Hardware-Unabhängigkeit
    Die DB-Verarbeitung sollte auf verschiedenen Hardware-Plattformen möglich sein. Sämtliche Hardware-Eigenschaften sind für den DB-Benutzer zu verbergen.

  10. Betriebssystemunabhängigkeit
    Die DB-Benutzung sollte unabhängig von den eingesetzten Betriebssystemen sein.

  11. Netzwerkunabhängigkeit
    Die verwendeten Kommunikationsprotokolle und -netzwerke sollten ohne Einfluß auf die DB-Verarbeitung bleiben.

  12. Datenbanksystemunabhängigkeit
    Es sollte möglich sein, unterschiedliche (heterogene) Datenbanksysteme an den verschiedenen Rechnern einzusetzen, solange sie eine einheitliche Benutzerschnittstelle (z.B. eine gemeinsame SQL-Version) anbieten.

Neben den erwähnten Transparenzeigenschaften wird gelegentlich noch Leistungstransparenz (performance transparency) gefordert. Dies bedeutet, daß die verteilte Bearbeitung von Anfragen und Transaktionen trotz Kommunikationsverzögerungen möglichst keine merkliche Verschlechterung in den Bearbeitungszeiten verursachen sollte[13]. Weiterhin soll die Bearbeitungszeit einer Anfrage weitgehend unabhängig davon sein, an welchem Rechner sie gestartet wurde [St89].

[12] Diese Aussage bezieht sich auf unsere Definition von Verteilten Datenbanksystemen. Leider wird dieser Begriff in vielfältiger Bedeutung angewendet, so zum Teil als Oberbegriff von homogenen und heterogenen Mehrrechner-DBS.
[13] Bei paralleler Anfragebearbeitung wird sogar eine Verbesserung der Bearbeitungszeiten angestrebt.