Mehrrechner-Datenbanksysteme

10 Autonomie und Heterogenität

Verteilte Datenbanksysteme (sowie andere Typen integrierter Mehrrechner-Datenbanksysteme, s. Kap. 3.2) unterstützen die verteilte Verarbeitung auf einer einzigen logischen Datenbank, die durch ein entsprechendes (globales) konzeptionelles Schema beschrieben wird. In der Praxis zeigt sich jedoch daneben zunehmend die Notwendigkeit, in koordinierter Weise auf mehrere selbständige Datenbanken zuzugreifen, die jeweils von einem eigenem DBVS verwaltet werden. Dies ist z.B. in zahlreichen Unternehmen und Institutionen der Fall, in denen meist mehrere Datenbanken in unkoordinierter Weise geführt werden[45]. Die verschiedenen Datenbanken, welche wir hier als Lokale DBS (LDBS) bezeichnen, sind in der Regel unabhängig voneinander entworfen worden und daher auch heterogen (s.u.); sie enthalten jedoch häufig inhaltlich verwandte Informationen. Der isolierte Einsatz der LDBS bringt gravierende Nachteile mit sich, da Benutzer jeweils nur mit einer Datenbank arbeiten können. Damit ist die Verteilung der Daten für die Benutzer voll sichtbar (keinerlei Verteilungstransparenz), und die Datenkonsistenz über mehrere Datenbanken hinweg wird systemseitig nicht überwacht. Sind z.B. einzelne Informationen in verschiedenen Datenbanken repliziert, ist diese Redundanz seitens der Benutzer zu warten.

Beispiel 10-1

In einer Universitätsumgebung finden sich meist mehrere, unabhängig voneinander betriebene Datenbanken (Abb. 10-1). Bei der Personalverwaltung wird z.B. eine Datenbank über alle Universitätsbediensteten geführt; personenbezogene Daten werden daneben etwa in der Zentralbibliothek sowie im Rechenzentrum für die jeweiligen Benutzer gespeichert. Die unabhängige Verwaltung dieser verwandten Daten führt zu unkontrollierter Redundanz sowie den damit verbundenen Änderungsproblemen. So müssen z.B. Änderungen der Adresse ggf. in allen drei Datenbanken manuell nachgeführt werden. Weiterhin ist es nicht möglich, in einer Transaktion auf die verschiedenen Datenbanken zuzugreifen, z.B. um eine Person beim Ausscheiden aus der Universität aus allen Datenbanken zu löschen

Abb. 10-1: Heterogene Datenbanken in einer Universitätsumgebung

Der entscheidende Unterschied zu den integrierten Mehrrechner-DBS liegt in der notwendigen Unterstützung mehrerer unabhängiger und heterogener Datenbanken. Eine fundamentale Anforderung ist dabei, daß innerhalb einer Transaktion auf mehrere solcher Datenbanken zugegriffen werden kann - unter Wahrung der ACID-Eigenschaften. Wünschenswert ist darüber hinaus, daß selbst innerhalb einer DB-Operation Daten mehrerer Datenbanken bearbeitet werden können, z.B. um globale Join-Berechnungen vorzunehmen. Die Zugriffe auf die einzelnen Datenbanken sollten ferner über eine einheitliche Schnittstelle möglich sein, auch wenn unterschiedliche DBVS an der Verarbeitung beteiligt sind. Dies verlangt die Bereitstellung eines gemeinsamen Application Programming Interface (API) zwischen Anwendungen und Datenbanksystemen.

Die Erfüllung dieser Anforderungen wird durch zwei wesentliche Randbedingungen erschwert, nämlich die zu wahrende Knotenautonomie sowie die vorliegende Heterogenität. Diese beiden Aspekte sollen im folgenden genauer diskutiert werden. Danach werden die Rolle von Standards erörtert und das Konzept der "Middleware" eingeführt (Kap. 10.3). Abschließend erfolgt eine Kurzcharakterisierung der wesentlichen Realisierungsalternativen zur Unterstützung heterogener Datenbanken, welche in den weiteren Kapiteln behandelt werden.

[45] Eine Verschärfung dieser Problematik ergibt sich durch die zunehmende Anzahl von Firmen-Zusammenschlüssen, die auch den Zugriff auf vormals getrennte Datenbestände verlangen.
10.1 - Knotenautonomie
10.2 - Heterogenität
10.3 - Die Rolle von Standards
10.4 - Realisierungsansätze