Konrad Supper Leiter Datenbanken und verteilte Systeme mbp, Dortmund

Alle sprechen heute von Verteilung, Verteilung ist "in". Viele reden auch von Datenbanken, doch wie sieht es mit verteilten Datenbanken aus?

Für diesen Aufsatz soll eine Datenbank (DB) eine Menge von Benutzerdaten sein. Dazu gehören auch ihre Namen sowie die Beschreibung ihrer Formate, ihres inneren Aufbaus und ihrer Verknüpfung miteinander. Das DB-Management-System (DBMS) enthält alle Prozeduren zum Zugriff auf die und zur Verwaltung der DB. Ist eine DB unter einem bestimmten DBMS angelegt worden, so kann sie in der Regel nur mit diesem und mit keinem anderen DBMS verarbeitet werden. DB und DBMS bilden zusammen das DB-System (DBS).

Dem DB-Ansatz liegt die Idee zugrunde, Daten verschiedener Anwendungsbereiche eines Unternehmens in eine gemeinsame Struktur zu überführen (integrieren). Diese Integration ging bisher meist einher mit Zentralisation und der eine Begriff wurde synonym für den anderen gebraucht. Tatsächlich handelt es sich jedoch um zwei vollkommen unabhängige Begriffe: Während "lntegration" ein logisches Konzept des Anwendungsentwurfs verkörpert, steht "Zentralisation" für eine örtliche Verteilung von Ressourcen.

Ein DBMS, das Integration ohne Zentralisation unterstützt, ist ein verteiltes DS, das heißt DB und/ oder DBMS sind auf mehreren, unabhängig voneinander arbeitenden DV-Systemen installiert. Gegenüber dem Benutzer verhält das verteilte DBS sich jedoch wie ein zentrales DBS.

Beim Betrieb eines verteilten DBS müssen folgende Aufgaben gelöst werden:

þKommunikation zwischen den DV-Systemen

þVerwaltung der verteilten DBS-Komponenten.

Die Kommunikationsaufgabe (Übermittlung von Zeichenketten) wird bereits heute in zufriedenstellender Weise von der Hardware- und DFÜ-Technik bewältigt. Die Verwaltung der verteilten DBS-Komponenten ist jedoch in erster Linie eine durch zusätzliche Software zu lösende Aufgabe. Dabei sind von einem idealtypischen System unter anderem folgende Teilaufgaben zu erledigen:

þVerteilung der Daten

Einem idealtypischen, verteilten DBS teilt man mit, welche Daten voraussichtlich wie genutzt werden. Zusätzlich führt das System selbst Benutzungsstatistiken. Ausgehend von dieser Information speichert es die Benutzerdaten mit oder ohne Redundanz an den verschiedenen Orten des verteilten Systems. Mindestens jedoch stellt es selbst fest, welche Daten wo gespeichert sind.

Bei Datenbankanfragen stellt das System selbst fest, welche Daten beziehungsweise DBMS-Prozeduren benötigt werden. Nach Bedarf werden die Daten zu den Prozeduren transportiert. Auch der umgekehrte Fall oder Mischformen sind denkbar. Grundsätzlich sind dann nur noch die Anfragen "leicht" zu beantworten, für die Daten und Programme an einem Ort liegen. Andernfalls entsteht ein erheblicher Verwaltungsaufwand.

þKonsistenzerhaltung

Insbesondere dann, wenn Änderungen zulässig sind, wird die Gewährleistung der Konsistenz der Daten erheblich schwieriger als in einem zentralen System. Schon für zentrale Systeme ist strittig, welche die "richtige Lösung" sei. In dezentralen DBS kommen gegebenenfalls die Gewährleistung der Identität redundant gehaltener Datenbestände hinzu. Schwer zu lösen ist auch der Wiederanlauf nach Änderungen dezentraler Bestände durch eine Transaktion. Weitere Probleme entstehen durch die Forderung nach netzweitem Datenschutz und vielem mehr.

Die heute existierenden Systeme bedürfen noch einer langen und intensiven Entwicklung, um der Vorstellung eines verteilten DBS in diesem Sinne einigermaßen gerecht zu werden. Die derzeit auf dem Markt befindlichen Systeme bieten unter einschränkenden Voraussetzungen Teile des Services eines verteilten DBS an. Zum Beispiel:

þNur lesenden Zugriff

In sogenannten Directories ist festgehalten, wo welche Daten abgelegt sind. Im Suchbefehl spricht der Benutzer Dateien und Felder lediglich mit ihrem Namen an. Das System zerlegt den Suchbefehl dann in Teilbefehle, überwacht deren Ausführung auf den verschiedenen DV-Anlagen, bildet aus den lokalen Teilergebnissen ein Gesamtergebnis und übergibt dies dem aufrufenden Benutzer oder Programm. Will der Benutzer in einem derartigen System ändern, so muß er mindestens den Speicherort jedes Daten(typs) angeben.

þDezentrale Initiierung - Dezentrale Ausführung am vordefinierten Ort

Bei der Systemgenerierung wird für jede Transaktion festgelegt, in welchem DV-System sie ausgeführt wird.

Der Benutzer kann dann diese Transaktionen in einem beliebigen DV-System des Netzes starten, sie werden zum vordefinierten Rechner weitergeleitet, dort ausgeführt und das Ergebnis wird zum Startort zurückgeleitet. Voraussetzung dabei ist, daß alle von einer Transaktion benötigten Daten sich im Zugriff des DV-Systems befinden, in dem die Transaktion abläuft. Demgegenüber obliegt dem initiierenden System die Aufgabe, die Ausführung der Transaktion zu überwachen.

þDezentrale Initiierung - Zentrale Ausführung der DBMS Funktionen

Bei dieser Alternative werden die Daten zentral in einem DV-System gespeichert und auch alle Transaktionen werden zentral auf demselben DV-System ausgeführt. Lediglich das Anstoßen einer Transaktion kann dezentral erfolgen. Der Benützer arbeitet mit solch einem System fast so wie mit einem zentralen DBMS; der wesentliche Unterschied ist, daß das die Transaktion aufrufende Anwendungsprogramm dezentral laufen kann.

Fazit: Verteilte DBMS - so wie sie heute angeboten werden stecken noch in den Kinderschuhen. Fast alle DV-technischen Lösungen müssen noch durch organisatorische Lösungen ergänzt werden.

Fast alle DBMS-Anbieter arbeiten zum Teil seit Jahren an Konzepten für verteilte DBMS und deren Realisierung. In naher Zukunft darf mit Ankündigung und Freigabe leistungsfähiger Software gerechnet werden.

Daß die Hersteller hierfür erheblichen Aufwand treiben mußten, zeigt wie schwer diese Aufgabe zu lösen ist. Nur wenige Firmen dürften das geeignete Personal zur Verfügung haben, um die vorhandenen DV-Lösungen selbst zu verbessern. Neben dem Aufwand muß der Anwender dann noch ein, erhebliches Entwicklungsrisiko tragen.

Für viele Firmen ist die gedankliche und häufig auch die mit dem Einsatz eines zentralen DBMS einhergehende organisatorische Umstellung kaum zu schaffen. Die beim Übergang auf dezentrale Datenbanksysteme zu erwartenden Probleme sind in jeder Hinsicht größer.