1 Einführung

1.1 Von der zentralisierten zur verteilten Datenbankverarbeitung

Die traditionelle Datenbankverarbeitung ist zentralisiert, das heißt DBVS sowie Anwendungsprogramme, die auf die Datenbank zugreifen, laufen in einem Rechner ab. Die eigentlichen Benutzer (z.B. Sachbearbeiter einzelner Abteilungen) sind mit dem zentralen Verarbeitungsrechner nur über Terminals oder sonstige Endgeräte verbunden (Abb. 1-1). Diese Organisationsform bringt vor allem Administrationsvorteile mit sich, da die Datenbank sowie die gesamte Software zentral verwaltet werden können.

Abb. 1-1: Zentralisierte Datenbankverwaltung in einer Bankanwendung

Andererseits wird die zentralisierte Systemstruktur in vielen Fällen der Organisationsform eines Unternehmens nicht gerecht. So würde bei einer Großbank mit mehreren Filialen damit verlangt, 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.
Weiterhin führt ein einziger Verarbeitungsrechner oft zu inakzeptablen Leistungs- und Verfügbarkeitsproblemen. Durchsatz- und Antwortzeitanforderungen können i.a. nur mit einem Großrechner (Mainframe) erfüllt werden, was zu hohen Kosten führt. Für große Anwendungen ist selbst die Kapazität eines Großrechners oft nicht ausreichend, zumal die Leistungsforderungen zum Teil stärker steigen als die Prozessorgeschwindigkeit. Weiterhin führt die zentralisierte Lösung zu einer geringen Verfügbarkeit, da der Ausfall des zentralen DB-Rechners den gesamten Betrieb lahmlegt, wenn nicht ein Reserverechner die Verarbeitung fortsetzen kann. Längere Ausfallzeiten beim Datenbankbetrieb sind in vielen Anwendungsbereichen wie etwa bei Telefongesellschaften, Platzreservierungssystemen oder Banken völlig inakzeptabel.

Aufgrund der Beschränkungen zentralisierter Datenbanksysteme wurden unterschiedliche Typen sogenannter Mehrrechner-Datenbanksysteme entwickelt, bei denen die Datenbankverwaltungsfunktionen auf mehreren Prozessoren bzw. Rechnern ausgeführt werden. Im folgenden wollen wir einführend auf einige Vertreter von Mehrrechner-Datenbanksystemen eingehen. Genauere Definitionen sowie eine Klassifikation und Abgrenzung der wesentlichen Alternativen erfolgen in Kap. 3.

Einen relativ geringen Entwicklungsschritt stellt der Übergang von einem zentralisierten DBS zu Multiprozessor-Datenbanksystemen[2] dar, mit denen die Kapazität von Multiprozessoren zur DB-Verarbeitung genutzt werden kann. Hierzu wird das DBVS i.a. innerhalb mehrerer Prozesse ausgeführt, die vom Betriebssystem dynamisch den Prozessoren zugewiesen werden. Da mit einem solchen Ansatz die meisten Nachteile zentralisierter Datenbanksysteme weiterhin Bestand haben, wird bei den wichtigsten Mehrrechner-DBS die Datenbankverarbeitung auf mehreren unabhängigen Rechnern ausgeführt, die selbst wiederum als Multiprozessoren ausgelegt sein können. Dabei läuft auf jedem der Rechner ein eigenes DBVS; die DBVS kooperieren untereinander, um den Anwendungen gegenüber Aspekte der Verteilung möglichst zu verbergen.

Abb. 1-2: Einsatz eines Verteilten Datenbanksystems

Verteilte Datenbanksysteme [BEKK84, CP84, Da86, ÖV91, BG92] repräsentieren einen bekannten Vertreter solch allgemeinerer Mehrrechner-Datenbanksysteme, sind jedoch nicht mit ihnen gleichzusetzen. Eine wesentliche Eigenschaft Verteilter Datenbanksysteme ist, daß sie eine geographisch verteilte Datenbankverwaltung und damit eine Anpassung an dezentrale Organisationsstrukturen gestatten. Wie im Beispiel von Abb. 1-2 gezeigt, kann somit jeder Zweigstelle einer Bank ein lokales DBVS zugeordnet werden, das die Konto- und Personaldaten der jeweiligen Filiale in einer lokalen Datenbank(partition) hält. Da i.a. die meisten Datenbankzugriffe auf lokale Daten erfolgen, läßt sich ein Großteil der Kommunikationsverzögerungen einsparen. Dennoch kann weiterhin auf die gesamte Datenbank zugegriffen werden, da die DBVS der einzelnen Rechner hierzu miteinander kooperieren. Betrifft ein Datenbankzugriff Daten eines anderen Rechners, wird der entsprechende Auftrag unsichtbar für den Benutzer bzw. das Anwendungsprogramm an diesen weitergeleitet. Der Einsatz mehrerer Verarbeitungsrechner erlaubt eine gesteigerte Leistungsfähigkeit und Verfügbarkeit gegenüber zentralisierten DBS. Der Ausfall eines Rechners betrifft insbesondere lediglich dessen lokale Daten; auf die restliche Datenbank kann weiterhin zugegriffen werden. Nachteilig bei Verteilten Datenbanksystemen ist u.a. die Notwendigkeit einer Systemadministration an jedem Knoten. Weiterhin können Zugriffe auf nicht-lokale Daten zu erheblichen Leistungseinbußen führen, da die Kommunikation in Weitverkehrsnetzen i.a. relativ langsam ist und einen hohen Instruktionsbedarf erfordert (Kap. 2.2).

Abb. 1-3: Einsatz eines Parallelen Datenbanksystems vom Typ "Shared Disk"

Einen Kompromiß zwischen zentralisierten bzw. Mehrprozessor-DBS und Verteilten Datenbanksystemen stellen bestimmte Parallele Datenbanksysteme bzw. lokal verteilte Mehrrechner-DBS dar (Abb. 1-3). Wie bei Verteilten Datenbanksystemen kooperieren dabei mehrere DBVS untereinander, die jeweils auf einem eigenen Rechner ablaufen. Allerdings sind die Rechner in räumlicher Nachbarschaft angeordnet (innerhalb eines Rechenzentrums), um die Nutzung eines schnellen Kommunikationsmediums zwischen den Verarbeitungsrechnern sowie eine zentrale Systemadministration zu erlauben. Für die Zuordnung der physischen Datenbank auf den Externspeichern zu den DBVS bestehen zwei wesentliche Alternativen. Die Datenbank kann entweder partitioniert werden (ähnlich wie bei Verteilten Datenbanksystemen), so daß jedes DBVS eine Partition zugeordnet bekommt, oder jedes DBVS kann direkt auf die gesamte Datenbank (sämtliche Platten) zugreifen. Im letzteren Fall spricht man von einem DB-Sharing- oder Shared-Disk-Ansatz (Abb. 1-3), im ersteren Fall von Shared-Nothing[3].

Solche Parallelen DBS erlauben weit bessere Leistungs- und Verfügbarkeitsmerkmale als zentralisierte Datenbanksysteme unter Beibehaltung einer zentralen Administrierbarkeit. Gegenüber Verteilten Datenbanksystemen schlägt neben der einfacheren Systemverwaltung vor allem die Nutzung eines effizienten Kommunikationssystems positiv zu Buche. Dafür ist jedoch eine Anpassung an geographisch verteilte Organisationsstrukturen ("DB-Verarbeitung vor Ort") nicht mehr möglich. Die Bezeichnung "Parallele DBS" rührt daher, daß diese Ansätze die Nutzung von Parallelrechnern mit zahlreichen Prozessoren für die DB-Verarbeitung ermöglichen. Dabei soll auch eine Parallelverarbeitung innerhalb von Transaktionen bzw. DB-Anfragen unterstützt werden.

Mehrrechner-Datenbanksysteme stellen nicht die einzige Möglichkeit einer verteilten Transaktionsbearbeitung dar. Diese kann nämlich auch außerhalb des DBVS realisiert werden, z.B. indem Anwendungen und DBVS auf getrennten Rechnern ablaufen. Eine solche Systemstruktur findet sich häufig in Client/Server-Umgebungen, wenn Anwendungsprogramme von Workstations und PCs auf entfernte Datenbanken von Server-Rechnern zugreifen. Die Realisierungsalternativen zur verteilten Transaktionsverarbeitung werden in Kap. 11 behandelt.

[2] Solche Systeme werden wir später auch als "Shared-Everything" bezeichnen (Kap. 3).
[3] In unserer Klassifikation in Kap. 3 werden wir Verteilte DBS als geographisch verteilte Shared-Nothing-Systeme definieren.