Michael Bauer und Josef Kraus leiten das Seminar "Distributed Database" bei der Informatik Training GmbH, Radolfzell.

Eine fast zwangsläufige Entwicklung: Verteilte Datenverarbeitung zieht verteilte Datenhaltung nach sich. Entsprechende Produkte, nämlich "verteilte Datenbanksysteme", sind bereits am Markt, allerdings noch nicht ganz ausgereift. Michael Bauer und Josef Kraus beschreiben Wunsch und Wirklichkeit.

In den größeren Unternehmen finden wir heute eine heterogene Landschaft von Rechnersystemen vor, die die Informationsverarbeitung im Unternehmen abwickeln sollen: Neben dem klassischen zentralen Rechnersystem haben sich die PCs als Arbeitsplatzrechner etabliert.

Verteilte Verarbeitung ist heute fast schon ein Muß

Hinzu kommen Abteilungsrechner für funktional oder regional abgegrenzte Aufgaben. In zunehmendem Maße halten auch Rechner für bestimmte Arbeitsgebiete wie Bürokommunikation oder CAD Einzug in die Unternehmen.

Auf diese Weise entsteht eine dreischichtige Rechnerarchitektur für die Informationsverarbeitung: PCs als Arbeitsplatzrechner für individuelle Aufgaben, Mehrplatzsysteme als Abteilungsrechner für ein abgrenzbares Aufgabengebiet und Zentralrechner für übergreifende Aufgaben und hohe Verarbeitungsbelastung.

Sicherlich ist eine solche Rechnerarchitektur noch nicht in allen Unternehmen gleichermaßen ausgeprägt. Speziell die Ebene der Abteilungsrechner fehlt oft in Unternehmen mit stark zentralem Charakter wie Versicherungen, Banken und Behörden, Dennoch ist die Entwicklung zur verteilten Verarbeitung nicht abzustreiten. Damit ist es nicht mehr die Frage, ob man die Informationsverarbeitung verteilen sollte oder nicht, sondern nur noch, wie man es geschickt anfängt.

Mit der Verteilung der Verarbeitung auf mehrere Rechner entsteht automatisch das Problem der Datenverteilung, da jeder Rechner so viele Daten wie möglich auf seinen Platten gespeichert halten sollte. Solange es sich um Daten für IDV-Anwendung handelt, gibt es wenig Probleme. Solche Datenbestände sind entweder "privat" oder Extrakte aus allgemeinen Datenbeständen. Zugriffe von anderen Benutzern auf diese Daten sind nicht zulässig. Damit bietet eine Selektionssoftware mit File-Transfer sicherlich eine ausreichende Anbindung für PCs.

Anders ist es mit allgemeinen Daten, also Daten für operative Anwendungen und Informationssysteme. Eine Dezentralisierung der Hardware darf nicht dazu führen, daß der Integrationsgrad der Anwendungen verloren geht. Gerade unter dem Aspekt, daß Information zunehmend als wesentliche Ressource eines Unternehmens erkannt wird, muß die Verfügbarkeit der Daten in aktueller und konsistenter Form für alle Bereiche eines Unternehmens gewährleistet sein. Deshalb treten hier folgende Fragen auf:

- Wer braucht Zugriff zu welchen Daten?

- Welche Daten lassen sich verteilen und welche müssen zentral gehalten werden?

- Weicher Aktualitätsgrad der Daten ist erforderlich?

- Wie erfolgt die Weitergabe von Verarbeitungsergebnissen an andere Stellen?

- Wie hoch wird der Aufwand für Zugriffe auf entfernte Daten?

- Welche Auswirkungen hat die Datenverteilung auf die Programme und den RZ-Betrieb?

Gerade der letztgenannte Aspekt ist wichtig: Durch die verteilte Verarbeitung soll nicht noch eine zusätzliche Dimension an Komplexität entstehen. Verteilung und Änderung der Verteilung muß auf den Anwender - sei er Programmierer oder Endbenutzer - keinen Einfluß haben; für ihn soll es wie ein System erscheinen.

Bei der Verteilung der Daten gibt es drei prinzipielle Formen:

- Unikate Daten: Eine Datenmenge befindet sich nur an einem Ort; Zugriffsanforderungen müssen zu dem Rechner gesendet werden, auf dem diese Daten gespeichert sind.

- Partitionierte Daten: Teile einer Datenmenge sind jeweils über mehrere Rechner verteilt gespeichert (Beispiel: Nur die Kundendaten eines Regionalgebietes sind auf dem Rechner der jeweiligen Filiale gespeichert). Bearbeitungen des Gesamtbestandes müssen sich demnach immer über die Daten mehrerer Rechner erstrecken.

- Replikate Daten: Eine Datenmenge wird redundant auf mehreren Rechnern gespeichert (Beispiel: Alle Artikeldaten eines Unternehmens sind bei jedem Auslieferungslager gespeichert). Änderungen der Daten führen damit zu gleichzeitigen Änderungen in mehreren Kopien.

Bisher fanden drei verschiedene Lösungen der Datenverwaltung beim "Distributed Processing" Anwendung: File Transfer, Remote Transaction

Processing und Remote Data Base Access (siehe Abbildung). Jede der drei Techniken hat ihren sinnvollen Einsatzbereich, aber auch ihre Restriktionen.

Beim File-Transfer werden Kopien oder Extrakte von Dateien redundant an mehreren Knoten gehalten. Sinnvoll ist das nur bei geringem Aktualitätsgrad und "Read-only" - Benutzung. Die Verwaltung der Kopien erfolgt manuell.

Remote Transaction Processing bedeutet: Die Daten werden unikat gespeichert. Ebenso müssen die geeigneten Anwendungsprogramme verfügbar sein. Das Versenden der Nachricht an den entfernten Rechner übernimmt der jeweilige TP-Monitor, wobei der Transaktions-Code in der Nachricht den Speicherungsort der Daten beinhaltet (zum Beispiel CICS-ISC, UTM-D).

Netzübergreifende Operationen nötig

Für das Remote Data Base Access braucht das Anwendungsprogramm nicht den Speicherort der Daten zu kennen. Aus dem DB-Befehl (beispielsweise Datenbankname oder Tabellenname) ergibt sich der Speicherungsort der Daten, und der Zugriff kann automatisch zum richtigen DBMS geschickt werden. Allerdings klappt das nur, wenn die Daten unikat gespeichert sind und der Befehl keine rechnerübergreifenden Zugriffe erforderlich macht.

Gegenüber diesen bisher verfügbaren Techniken soll eine wirkliche "Distributed Data Base" jedes Verteilungskonzept unterstützen und .transparent" (unsichtbar!) für die Programme auch netzübergreifende Operationen durchfuhren. Dabei darf die Verteilung der Daten zweckmäßigerweise nur dem DBMS bekannt sein, so daß sich die Daten den Anwendern wieder als eine Gesamtheit darstellen. Auch eine Veränderung der Verteilung hat somit keinen Einfluß auf die Anwendungen.

Deshalb muß jeder Knoten in einem verteilten DB-System sowohl über ein lokales DBMS als auch über eine DDB-Funktion verfügen. Die DDB-Funktion besitzt eine Beschreibung der Gesamtheit aller Daten (Directory) und kann somit eine DB-Anforderung versenden, lokal ausführen lassen oder in Teilfunktionen auflösen; weiterhin benötigt sie eine Kommunikationskomponente, die in der Lage ist, DB-Anforderungen zu versenden und zu empfangen.

Die Wissenschaft beschäftigt sich schon seit Jahren mit dem Thema verteilte Datenbanken und hat einige grundlegende Konzepte erkannt. Chris Date, Schüler und Mitstreiter des Datenbank-Papstes Ted Code, hat diese Erkenntnis in zwölf Anforderungen umgesetzt (siehe Kasten).

Mehr als nur DB-Zugriff über eine gewisse Distanz

Manche dieser Anforderungen erscheinen als selbstverständlich (zum Beispiel die Einhaltung des Transaktionskonzeptes), manche nahezu utopisch (beispielsweise die DBMS-Unabhängigkeit). Im großen und ganzen aber bilden sie eine gute Meßlatte, um das Produktangebot zu beurteilen.

Fast alle DBMS-Hersteller bieten heute bereits "verteilte Datenbanken" an. Die verfügbaren Produkte fallen jedoch meist eher unter die Kategorie "Remote Data Base Access", als daß sie wirklich verteilte Datenbanken sind. Das heutige Produktangebot kann man deshalb nur als den ersten Schritt bezeichnen. Entwicklungsbedarf gibt es noch auf folgenden Gebieten:

- Abdeckung aller Verteilungsformen: Heute mangelt es meist an der Unterstützung partitionierter und replikater Daten. Hierzu gehört auch das automatische Update aller redundanten Kopien eines Datenbestandes;

- Datenbank-übergreifende Operationen: Dies schließt auch Datensichten ("views") ein, die sich über mehrere entfernte Datenbanken erstrecken;

- Netzweites Update sowohl in bezug auf unikate als auch auf replikate Daten,

- Netzweite Optimierung von DB-Operationen, (speziell: Join-Operationen);

- Netzweite Konsistenzsicherung bei allen Fehlersituationen;

- Synchronisation der Datenbank-Operationen mit dem jeweiligen TP-Monitor;

- Eignung für heterogene Rechnersysteme: Dies ist wichtig im Zusammenhang mit den geschilderten Drei-Rechner-Ebenen;

- Unterstützung heterogener Datenbanksysteme.

Die DB-Hersteller arbeiten jedoch an der Weiterentwicklung ihrer Produkte, so daß wir in einigen Jahren mit zufriedenstellenden Lösungen rechnen können.

Die Entwicklung zu verteilten Systemen macht es jedenfalls erforderlich, sich intensiv auch mit verteilten Datenbanken auseinanderzusetzen; denn die organisatorischen Konzepte und Vorarbeiten dauern wesentlich länger als die Entwicklung der technischen Lösung. Deshalb sollte im Rahmen der Informationsanalyse, die heute für jedes DV-Projekt üblich ist, auch die potentielle Verteilung der Daten ermittelt werden.

Hierbei muß festgehalten werden, inwieweit unterschiedliche betriebliche Funktionen oder regionale Standorte isolierbare oder gemeinsame Daten benötigen. Daraufhin erst kann ein Verteilungsmodell der Daten und ein Verteilungsmodell der Verarbeitungsfunktionen erarbeitet werden (siehe CW-Extra vom Mai 1987: Die Kunst, Daten zu verteilen und nicht zu verstreuen").

Einen wesentlichen Faktor der Überlegungen stellt dabei der Aktualitätsbedarf dar. Nur wenn dieses Umfeld geklärt ist, können der erwartete Nutzen aus den technischen Möglichkeiten der verteilten Informationsverarbeitung gezogen und für das Unternehmen gewinnbringend verwendet werden.