Praktizierbare Konzepte sind bei den verteilten Datenbanken heute noch eine Seltenheit. Doch die Bedeutung dieses DB-Ansatzes nimmt ständig zu." Im Vordergrund steht dabei vor allem die Flexibilität in der Anpassung an die jeweiligen Benutzerbedürfnisse, die durch die

Dezentralisierung erreicht wird", konstatiert Jürgen Delp*.

Die Problematik stellt sich in den unterschiedlichsten Unternehmen auf die mehr oder weniger gleiche Art und Weise: Irgendwann erkennt das Management den Produktionsfaktor

"Information" in seiner ganzen Bedeutung. Die Forderung lautet dann, daß sämtliche im Laufe der Jahre eingerichteten Hard- und Software-Systeme in einen einheitlichen Verbund gebracht werden, damit sich die gespeicherten Informationen gemeinsam verwalten und nutzen lassen.

Die Lösung des Problems hat einen Namen- man spricht bei datenbankorientierten DV-Systemen, die sich über unterschiedliche, möglicherweise auch örtlich voneinander getrennte Hardware-Einheiten erstrecken: von verteilten Datenbanken (Distributed Databases). Praktizierbare Konzepte, die gemeinhin an ein Datenbank-Management-System (DBMS) gestellt werden, sind auf dem Sektor der verteilten Datenbanken derzeit aber noch gelten.

Schneller Zugriff und hohe Zuverlässigkeit

Oft werden, bei denen die Informationen zentral abgelegt sind und nur der Zugriff von verschiedenen Konfigurationen aus erfolgen kann, bereits als verteilte DBMS bezeichnet. Der Sinn und Zweck verteilter Systeme besteht jedoch darin, daß auch die Datenbestände auf verschiedenen Rechnern abgelegt sind. Erst dadurch lassen sich die entscheidenden Vorteile dieses Konzepts realisieren: Zu nennen ist zunächst einmal die Verbesserung der Verfügbarkeit der Informationen. Dies geschieht dadurch, daß die Daten an den Stellen gespeichert und gepflegt werden, an denen sie vornehmlich benötigt werden. Auf diese Weise reduzieren sich die Kommunikationsaufwendungen und der Zugriff wird beschleunigt.

Des weiteren erhöht die verteilte Speicherung die Zuverlässigkeit, da es nicht mehr nur den einen zentralen Rechner gibt, dessen Ausfall das gesamte System zum Erliegen bringt. Auch die Erweiterung der Kapazitäten läßt sich durch Hinzufügen neuer

Netz-Knoten auf einfache Art vornehmen.

In weit verzweigten DV-Systemen stellt sich für die Benutzer häufig das Problem, daß sie Daten benötigen die für sie nur sehr umständlich oder überhaupt nicht zugänglich sind. Sie kopieren dann die entsprechenden Dateien in die eigene Umgebung, um sie in Zukunft verfügbar zu haben. Daraus ergibt sich die Folge, daß die Datenbestände nebeneinander gepflegt, aktualisiert und geändert werden.

Es entstehen also unterschiedliche Versionen des gleichen Datenbestands. Dies verursacht nicht nur einen überflüssigen konzeptionellen und administrativen Mehraufwand sondern es geht auch die Datenintegrität, die Einheitlichkeit der Datenbank und damit die Kontrolle über die gespeicherten Informationen verloren. Irgendwann weiß man nicht mehr, welche Version die aktuellste und letztlich gültige ist.

Ein echtes verteiltes DBMS bietet neben der Datenintegrität auch sämtliche anderen für eine effizient arbeitende Datenbank erforderlichen Funktionen. Dazu gehört unter anderem ein Restart-/Recovery-Mechanismus. Darunter ist die Fähigkeit zu verstehen, nach einen. "Systemzusammenbruch" - wie er durch einen Hard- oder Softwarefehler verursacht werden kann - den Zustand wiederherzustellen, in dem sich die Datenbestände vor Beginn der während des Vorfalls gerade laufenden Transaktionen befanden. Ein konsistent und schnell arbeitender Restart-/Recovery-Mechanismus ist eine Grundbedingung für die hohe Verfügbarkeit des Systems. Oft ist es so, daß die Rekonstruktion der Datenbasis weit mehr Zeit beansprucht als die Behebung des verursachenden Fehlers.

Gesichtspunkte wie Transaktions-Kontrolle, Datenintegrität, Restart-/Recovery oder auch Datensicherheit lassen sich in einem verzweigten DV-System letztlich nur mit einem umfassenden Datenbank-Konzept realisieren. Denn der Programmier- und vor allem auch der Pflege-Aufwand wäre bei einer auf der Anwendungsebene operierenden Lösung zu groß. Sämtliche im System gespeicherten logischen Daten sind als Teile einer einheitlichen Informationssammlung zu verstehen. Dazu benötigt man ein Managementsystem, das auf die in den verschiedenen Teilsystemen enthaltenen Ressourcen zugreift, ohne daß die Benutzer wissen müssen wo die Daten tatsächlich abgelegt sind.

Einzelsysteme lösen mehr und mehr die Zentral-DV ab

Verteilte Datenbanken, die diese Eigenschaft besitzen, werden ortstransparent (location transparent) genannt. Das heißt, die Anwendungsebene ist von der physikalischen Speicherung unabhängig. Alle Daten erscheinen auf der Benutzeroberfläche als Teile einer großen logischen Datenbank, auf die ein beliebiger Zugriff möglich ist.

Die Bedeutung, die verteilte DBMS in Zukunft erlangen werden, läßt sich allein schon aus den Marktentwicklungen bei der Hardware erschließen. Entfiel 1980 noch fast die Hälfte des Hardware-Umsatzes auf Großrechner, so wird es im Jahre 1990 einer Studie des Marktforschungsinstituts IDC zufolge weniger als ein Viertel sein. Ein Drittel des Marktes entfällt auf PCs und Workstations, die Anfang des Jahrzehnts praktisch ohne Bedeutung waren.

Der Trend zur Dezentralisierung der in den Unternehmen eingesetzten Computer-Intelligenz ist aus diesen Zahlen klar ablesbar. Die Zentral-EDV wird mehr und mehr durch Einzelsysteme abgelöst, die sich flexibel an die Bedürfnisse der verschiedenen Benutzergruppen anpassen lassen.

Auch der Trend bei der Datenbank-Software folgt dem verstärkten Bedürfnis nach Flexibilität: Bis vor wenigen Jahren dominierten noch die hierarchisch strukturierten Datenbanken, bei denen der Anwender den Aufbau kennen muß, um die von ihm benötigten Informationen zusammenstellen zu können. Heute hingegen werden bei Neuinstallationen für gewöhnlich relationale Systeme gewählt. Sie bieten den Vorteil, daß sich die Struktur der abgelegten Daten, da es sich ausschließlich um gleichwertig nebeneinanderstehende Tabellen handelt, schnell und einfach erfassen läßt.

Relationale Systeme erlauben auch den Einsatz einer Abfragesprache der vierten Generation. Die Anweisungen sollen dem relationalen Datenbank-Management-System (RDBMS) nicht den Weg erläutern müssen, wie es die benötigten Daten findet, sondern es muß nur noch formuliert werden, was man möchte. Wird zum Beispiel eine Liste der in den verschiedenen Standorten eines Unternehmens verfügbaren Artikel benötigt, sind für eine solche Anfrage bei hierarchischen Datenbanken viele Anweisungen zum Herauslesen und Zusammenführen der einzelnen Datensätze aus den unterschiedlichen Dateien zu schreiben.

Bei relationalen Systemen lassen sich Anfragen mit wenigen auf der Relationenlogik beruhenden Operationen - Vereinigung, Selektion, Projektion etc. - ausführen. Das gleiche gilt für Aktualisierungen, deren einfache und konsistente Handhabung eines der Hauptargumente für das relationale Datenbank-Modell darstellt.

Verteilte Systeme arbeiten mit der relationalen Technologie Hand in Hand. Die strikte Differenzierung zwischen der Datenbankverwaltung und der Anwendungsebene erfährt bei verteilten Systemen eine Erweiterung, indem die Benutzer nicht mehr direkt mit dem DBMS der jeweiligen Datenbasis kommunizieren, sondern mit dem Systemteil Distributed Data Manager (DDM). Dieser ist im zugrundeliegenden DBMS in die Multiuser-Einrichtung eingebettet.

Die Informationen über die Datenverteilung werden an jedem Knoten in einem speziellen Data-Dictionary abgelegt. Ist der Knoten, an dem die Informationen gespeichert sind, bekannt, übernimmt eine Kommunikationsfunktion (ITM - Information Transmission Manager) das Versenden einer DB-Anweisung. Die Anwender arbeiten dann mit dem

System genauso, als wenn sie sich in einer einfachen Datenbank-Umgebung bewegen würden. Der Komfort, den eine Sprache der vierten Generation bietet, steht ihnen dabei in gleicher Weise zur Verfügung.

Die zusätzlich in die Software-Architektur eingezogene Schicht muß speziell auf dem Gebiet der Update-Operationen sehr komplexe Aufgaben bewältigen. Zu diesem Zweck wird ein sogenannter Zwei-Phasen-Commit eingesetzt, der die in den verschiedenen Netzknoten vorgenommen Aktualisierungen miteinander synchronisiert.

Um eine angemessene Performance zu gewährleisten, muß der Datenverwalter des verteilten Systems über die Fähigkeit verfügen, eine optimale Lokalisierung der Datenbestände vorzunehmen und gegebenenfalls Datenredundanzen herzustellen. Denn es bringt große Performance-Vorteile, wenn möglichst viele Transaktionen lokal, also vollständig auf einem einzigen Netzknoten abgewickelt werden.

Überhaupt ist die weitgehende Autonomie der Einzelsysteme eine vorrangige Zielsetzung bei der effizienten Organisation verteilter Datenbanken. Die wesentlichen Kontrollfunktionen wie auch die Aufgabe der Integritätspflege sollten bei den einzelnen Netzwerken angesiedelt sein. Wichtig ist auch, daß Applikationen, die nicht auf entfernte Datenbestände zugreifen, ohne den Kommunikations-Overhead des DDM arbeiten, also wie bei einem einfachen DBMS funktionieren.

Die wachsende Bedeutung verteilter Datenbanken ist also unverkennbar. Im Vordergrund steht dabei vor allem die Flexibilität in der Anpassung an die Benutzerbedürfnisse, die durch die Dezentralisation erzielt wird. Trotz der Autonomie der lokalen Systeme bleibt die Integrität der Datenbestände gewahrt, und sämtliche Benutzer arbeiten mit einem einheitlichen, stets aktuellen Datenbestand. Nicht zuletzt spielen auch die verbesserte Verfügbarkeit und die erhöhte Ausfallsicherheit des gesamten Systems eine wichtige Rolle.

Oft werden LAN-Datenbanken, bei denen die Informationen zentral abgelegt sind und nur der Zugriff von verschiedenen Konfigurationen aus erfolgen kann, bereits als verteilte Datenbanksysteme bezeichnet. Der Zweck eines echten verteilten DBMS besteht Jedoch darin, daß auch die Datenbestände auf verschiedenen Rechnern abgelegt sind. Verteilte DB-Systeme sollten den Anforderungen an ein einheitliches DBMS gerecht werden und auch eine weitgehende Autonomie der Einzelsysteme gewährleisten. Die Voraussetzung dafür ist eine von funktionsfähige relationale Datenbank.