Die Funktion "verteilte" Datenbanken stellt die wichtigste Entwicklung im Rahmen von DB-Systemen in den kommenden Jahren dar. Denn nur hiermit läßt sich die Vielzahl der Computer in einem Unternehmen wieder zu einer organisatorischen Einheit zusammenschweißen. Keineswegs sollte sich der Anwender jedoch im Glauben wiegen, daß mit diesen noch sehr jungen Produkten alle Probleme lösbar sind.

Mit der zunehmenden Verbesserung des Preis/Leistungs-Verhältnisses der Hardware geht eine Verteilung der Rechnerleistung an den Arbeitsplatz Hand in Hand. Dabei handelt es sich nicht nur um eine geographische Verteilung - also an entfernte Filialen, Werke oder Lagerstätten -, sondern eher sogar um eine funktionale Verteilung am gleichen Standort; das heißt dedizierte Rechner für Abteilungen, besondere Arbeitsgebiete oder einzelne Personen. Aber selbst im zentralen Rechenzentrum setzt die verteilte Verarbeitung ein. Nach einer von der Siemens AG durchgeführten Untersuchung steht zum Beispiel bei 60 Prozent aller Kunden mehr als ein Siemens-Mainframe im Rechenzentrum.

Das Problem verteilter Verarbeitung liegt bei den Daten. Da die Daten physisch dort vorhanden sein müssen, wo die Anwendungsprogramme ablaufen, werden sie entsprechend auch an dem jeweiligen Rechner gespeichert. Und damit entsteht das Problem: Welche Daten sollen wo gespeichert werden ? Was macht man wenn Daten an zwei Rechnern gebraucht werden? Wie kann man rechnerübergreifende Informationen gewinnen?

Natürlich kann man durch verteilte Transaktionsverarbeitung auch auf Daten anderer Rechner zugreifen. Bei dieser Funktion des TP-Monitors (zum Beispiel CICS-ISC oder UTM-D) stößt ein Dialogprogramm ein anderes in einem entfernten Rechner an und läßt sich von ihm Daten besorgen. Nur müssen hierbei drei Probleme gesehen werden :

- auf dein entfernten Rechner muß ein geeignetes Anwendungsprogramm verfügbar sein,

- das lokale Programm muß wissen, auf welchem Rechner welche Daten sind, und

- die inhaltliche Pflege der Daten zum Beispiel bei redundanter Speicherung liegt in Verantwortung der Programme.

Deshalb erhofft man sich eine Lösung, wenn die Verteilung und Zusammenführung von Daten durch das Datenbanksystem statt durch die Anwenderprogramme erfolgt. Leider wird der Begriff "verteilte Datenbanken" allzu oft mißbräuchlich genutzt, so daß eine Klarstellung sinnvoll ist.

In einer verteilten Datenbank erscheint dem Anwender - Programmierer oder Endbenutzer - die Gesamtheit aller Daten als eine Einheit, eine logische Datenbank 1, wobei er nicht auf den bei seinen Operationen physischen Speicherungsort Rücksicht nehmen muß (siehe Abbildung

1). Welche Daten von geholt oder wieder zurückgespeichert werden, ist für ihn unsichtbar oder "transparent". Das Wissen über die Verteilung besitzt nur das DBMS.

Dies unterscheidet sich deutlich von den Funktionen, die ebenfalls unter der Bezeichnung "verteilte Datenbanken" heute von den meisten DBMS-Herstellern angeboten werden. Hierbei kann ein Programm zwar auf eine entfernte Datenbank zugreifen und gegebenenfalls dort sogar ändern, aber es muß den Ort der Daten noch selbst spezifizieren, sei es über einen Knoten- oder Datenbanknamen. Damit steckt das Wissen über die Verteilung weiterhin im Programm. Änderungen der Verteilung führen dann zu Programmänderungen.

Inzwischen gibt es die ersten Produkte , die eine wirklich verteilte Datenbank unterstützen. Hierzu gehören neben "Ingres-Star" und "Oracle-Star" auf VAX-Rechnern auch "Sesam-DCN" und "UTM-D" auf Siemens Rechnern. Für IBM-Rechner steht "Adanet" für "Adabas" vor der Auslieferung. Bemerkenswerterweise gibt es noch kein Angebot seitens der IBM.

Um vom systemtechnischen Umfeld unabhängige portable Anwendungen zu erhalten, ist auch in einem Netz verteilter Datenbanken eine Transparenz dieser Verteilung gegenüber den eingesetzten Anwendungsprogrammen gefordert. Dies bedeutet nichts anderes, als daß die Kenntnis über den Ort, an dem die Daten liegen, nicht im Programm eingebettet sein darf. Vielmehr können von den Kontrollmechanismen des Datenbanksystems zusammen mit dem Netz-Driver die gewünschten Daten jederzeit an. ein beliebiges Programm im Netz geliefert werden.

Die Notwendigkeit der Bekanntgabe des Knotens, an dem die Daten für eine Applikation abgeholt werden sollen, verhindert die Unabhängigkeit der Programme gegenüber der Datenstrukturierung im Netz und macht außerdem DB-übergreifende Operationen unmöglich.

Bei verteilten DB-Systemen werden heute vor allem zwei große Gruppen von Verteilungsmechanismen .-(mehr oder weniger) in diesem Sinne unterstützt: Replizierung (replicated databases) und Partitionierung (partitioned databases).

Dabei steckt hinter der Technik der replicated databases" nichts anderes als eine geplante Datenredundanz im DB-Netz (siehe Abbildung 2). Der Vorteil ist, daß gerade bei statischen Datenmengen, die an mehreren Knoten für Leseoperationen verfügbar gehalten werden, die Übertragungszeiten und Leitungsbelastung und damit auch die Kosten erheblich gesenkt werden können.

Führen einer Log-Datei wird zum Muß

Dies bedingt aber auch eine automatische Pflege dieser redundanten Daten über DDB-Mechanismen, wenn an einer Stelle im Netz Änderungen an diesen so verteilten Daten vorgenommen wurden. Nur über derartige Automatismen ist die Konsistenz aller im Netz verwendeten Daten sichergestellt.

Lösungen mit "Masterkopie" und asynchronen Abgleichen werden angeboten (ADR/D-Net, Ingres-Star). Das Führen einer Log-Datei mit "time-stamp" und Knoteninformationen für die Log-Sätze wird im DDB-Netz zum Muß. Die Komplexität der verschiedenen Verfahren jedoch läßt auch die Frage nach der Effektivität solcher Methoden laut werden.

Weitaus komplizierter noch stellt sich die Technik "partitionierter Daten" in einem DDB-Netz dar. Partitioned "databases" verlangen nach einer (beliebigen) horizontalen und vertikalen Verteilung aller im Netz verfügbaren Datensätze. Im Bereich relationaler Datenbanken heißt das, daß einerseits Datensätze nach Wertebereichen ihrer Feldausprägungen, und jede Relation in der Konsistenz ihrer Attribute (Felder) beliebig über das Netz verteilt werden kann.

Die Forderung an die Transparenz gegenüber dem Benutzer heißt: Für den User bietet sich das Netz so dar, als würde er alle Daten an seinem lokalen Knoten verfügbar haben. Die DDB-Mechanismen sind dafür verantwortlich, seine Informationsanforderungen wo nötig an den verschiedensten Knoten zu lokalisieren und an ihn abzuliefern.

Als Beispiel für die horizontale/vertikale Verteilung der Daten (siehe Abbildung 3) sollen die Personalabrechnungsdaten den abrechnenden Stellen lokal zugeordnet werden (horizontal, Personalnummer 1201 bis 2001 Werk 1 und 2002 bis nnn Werk 2). Aber es könnte auch sein, daß Personaldaten wie Name, Vorname an einem anderen Ort benötigt werden, wie die Gehaltsdaten (vertikale Aufteilung der Relation). Die Systeme, die eine derartige Verteilung zu leisten in der Lage sind, sind unbedingt erforderlich. Erste Ansätze bietet das angekündigte Release von "Ada-Net" der Software AG.

Die Problematik verteilter "Systeme" wäre nur halb so groß, wenn sich die Möglichkeiten und Notwendigkeiten der User auf "retrieval"-Funktionen beschränken ließen. Die Erlaubnis, Daten an anderen Knoten von einem lokalen Punkt aus in beliebiger Weise zu manipulieren (INSERT, UPDATE, DELETE), wirft in bezug auf die Datenintegrität im DDB-Netz eine neue Dimension an Problemen auf.

Kritisch wird die Umgebung verteilter Datenbanken erst in dem Augenblick, wo Leitungen gestört, entfernte Datenbank- oder Kommunikationssysteme nicht verfügbar sind, oder während eines Datenmodifikationsprozesses über das Netz an einem der Knoten für das DDB-System nicht behebbare Fehler auftauchen. Den Synchronisationsmechanismen, netzweiten Restart/Recovery-Funktionen und Log-Funktionen kommt hier eine lebenswichtigem Bedeutung zu.

Doppelte Leitungsführung soll Schwächen ausgleichen

Die Koordinaten der verschiedenen Aktionen (Tasks) an den verschiedenen Knoten im Rahmen einer Datenbanktransaktion wird heute bei den bekannten DDB-Systemen (ADR/D-Net, Ada-Net/Net-Work) über das Konzept des sogenannten "2-Phasen-Commits" sichergestellt. Dies erlaubt auch ein gezieltes transaktionsbezogenes "roll-back" von Dateninhalten im gesamten Netz. Es stellt sich die Frage: Was passiert, wenn zum Zeitpunkt des "roll-back" über mehrere Knoten Leitungsfehler auftreten, die diese Aktion nur teilweise, das heißt, an bestimmten (aktiven) Knoten zulassen? Was, wenn diese "backout"-Aktionen an einem Teil der betroffenen Daten bereits abgeschlossen sind und andere Transaktionen auf die betroffenen Daten zum Zeitpunkt des Fehlers bereits wieder (verändernd) zugegriffen haben? Eine endgültige Lösung ist noch offen.

Die Behandlung von "deadlocks"/ "hang ups" kann wegen der dann fehlenden Möglichkeiten von Rückmeldungen an den Verursacher ebenfalls "nur" über "time-out"-Routinen sicher gelöst werden. Zur Abdeckung solcher Schwächen werden heute doppeltem Leitungsführungen empfehlen. Erhebliche Mehrkosten sind die Konsequenz.

Verteilte Datenbanken bieten zwar den Anwendern einen uneingeschränkten Zugriff auf Daten unabhängig von ihrem Speicherungsort. Doch das Ganze hat auch seinen Preis: Für jeden Zugriff auf eine entfernte Datenbank muß man als zusätzlichen Aufwand rechnen:

- CPU-Zeit für Verwaltung und Kommunikation (zirka 60 000 bis 70 000 Instruktionen),

- Übertragungszeit für DB-Aufruf und Daten.

Transport unnötiger Daten ist zu vermeiden

Bei einer Leitungsverbindung zwischen den Daten bedeutet dies, daß sich bei nur einem DB-Zugriff innerhalb einer Transaktion die Antwortzeit am Terminal mindestens verdoppelt. Bei mehreren DB-Zugriffen wird sie entsprechend schlechter bis unzumutbar.

Deshalb ist es besonders wichtig, daß keine unnötigen Daten transportiert werden messen. Doch bei Selektionen kann das oft auftreten. Wenn zum Beispiel ein Anwendungsprogramm einen Kundenauftrag nach dem anderen abholt, um daraus einen bestimmten auswählen, ist dies auf einer lokalen Datenbank kein Problem, auf einer entfernten jedoch unzumutbar. Hier ist es notwendig, daß ein qualifizierter Zugriffswunsch verschickt und nur noch die zutreffende Datenmenge zurücktransportiert wird. Erst relationale Datenbanken bieten eine mächtige, mengenorientierte Sprache, mit der diese Anforderungen abgedeckt werden.

Doch auch mit relationaler Algebra ist das Problem noch lange nicht gelöst. Es kommt nämlich darauf an, wie intelligent eine relationale DB-Anweisung aufgelöst wird. Besonders heikel sind Join- und Subquery-Operationen. Dazu ein Beispiel, das mit der Abbildung 4 illustriert wird: "Finde alle Konten mit einem Saldo über 10 000 Mark von Kunden, die länger als 10 Jahre bereits Kunden sind." Die Tabellen "Konto" und "Kunde" sind jeweils in einer entfernten Datenbank gespeichert.

Expertensystem-Technik kommt ins Spiel

Eine triviale Lösung ist, zunächst alle korrespondierenden Zeilen beider Tabellen zusammenzumischen und daraus die qualifizierten Zeilen zu selektieren. Dazu müssen aber große Datenmengen unnötigerweise zum lokalen Rechner transportiert werden. Geschickter ist es, zunächst Subqueries vor Ort auszufahren und nur die so eingeschränkten Mengen zum Mischen an den lokalen Rechner zu senden. Hierbei werden wesentlich weniger unnötige Daten transportiert.

Dieses Beispiel zeigt bereits auf, welche unterschiedlichen Auswirkungen ein einfacher DB-Befehl in einer verteilten Datenbank haben kann. Komplexe Abfragen, mehrere beteiligte Datenbanken, redundante oder partitionierte Datenverteilung, unterschiedliche Kommunikationswege zwischen den Rechnern - alle diese Faktoren erhöhen den Komplexitätsgrad bei der Befehlsauflösung. Dem heutigen Angebot an Distributet Databases mangelt es an diesen Funktionen noch weitgehend. Für die hierfür erforderlichen Abwägungsmechanismen werden Anleihen bei Expertensystemen erforderlich.

Woher erhält nun das DBMS die notwendigen Informationen über die Daten und ihre Verteilung? Eine verteilte Datenbank besteht aus einer Anzahl lokaler Datenbanksysteme, die über Kommunikationswege miteinander in Verbindung stehen. Jeder Knoten dieses Netzes benötigt ein Verzeichnis ("Directory") über die Gesamtheit aller Daten, Knoten, und Verbindungen (siehe Abbildung 5). Dadurch ist es möglich, daß ein lokales DBMS selbständig DB-Operationen auflösen und versenden, sowie auch unabhängig von der Verfügbarkeit anderer Knoten operieren kann. Verteilte Directories ermöglichen die lokale Autonomie eines Knotens. Da alle Knoten gleichberechtigt sind, müssen sie alle auch über die gesamte verteilte Datenbank Bescheid wissen. Was passiert, wenn an einem Knoten eine neue Tabelle angelegt wird?

Es bieten sich zwei Verfahren an: Im einen Fall müssen die DB-Administratoren aller Rechner, denen diese neue Tabelle bekannt werden soll, ihre Directories manuell ergänzen. Dies erfordert eine entsprechende Kommunikation. Im anderen Fall versendet das lokale DBMS automatisch ein Update an alle entfernten Directories. Dies erfolgt zwar sofort und ohne menschliche Eingriffe, doch es gibt Probleme, wenn zu diesem Zeitpunkt ein Knoten nicht erreichbar ist. Dazu muß wiederum eine netzweite Aktualitätskontrolle zwischen den Directories vorhanden sein, die bei jedem Verbindungsaufbau zwischen den Knoten überprüft wird. Die Implementierung solcher Funktionen in die heutigen Datenbanksysteme stellt keine kleine Aufgabe dar.

Abschließend muß bemerkt werden, daß Angebote an Distributed Database Systems (DDBS) im Markt zunehmend an Bedeutung und Umfang gewinnen. Ihr Reifegrad und ihre Einsatzerprobung ist in keiner Weise mit etablierten systemnahen Umgebungen wie Datenbanken oder TP-Monitoren vergleichbar. Den Anforderungen der Anwender konnte bisher nur in Teilen Rechnung getragen werden.

Beurteilungskriterien verteilter Datenbanksysteme

Kommunikationsfähigkeit

- DDB-Verarbeitung über Hauptspeicher

- CIC-Kommunikation

-Unterstützung der ISO-Levels

-Unterstützung verschiedener Netztopologien

-Support heterogener Rechnernetze

DDB-Datadictionary/Directory

-zentrales (globales) DD/Dir gefordert

-"master-slave"-Prinzip realisiert

-lokale Autonomie gegeben

-manuelle Administration erforderlich

-automatische Verwaltung vorhanden

Verteilungsunabhängigkeit

-Kenntnis der Datenlokation erforderlich

-netzübergreifende Funktionen verfügbar

-unterstützende Zugriffsverfahren angeboten

Unterstützte Verteilungskonzepte

-eine Tabelle an einem Ort

-Replizierung

- ohne Pflege der Redundanz

- mit asynchroner Pflege der Redundanz

- mit "real-time" Pflege der redundanten Daten

-Partitionierung

- horizontal

- vertikal

- gemischt: "replicated" und "partitioned"

Zugriffswegoptimierung

- keine

- "subquery"-Technik

- Weitergabe von "query"(-Teilen)

Datensicherheit/Datenintegrität

- Unterstützung von modifizierten Zugriffen (UPDATE)

- Synchronisation mehrerer Datenbanken

- (automatische) Behandlung von Fehlern in Kommunikationssystem/Leitungen

- Klärung netzweiter " dead lock"/"hang up" Situationen

Offenheit des Systems

- homogene DBMS-Umgebungen notwendig

- heterogene DBMS Umgebungen unterstützt

-homogene Rechnerumgebungen gefordert

-heterogene Rechenumgebungen zugelassen

Michael Bauer ist Geschäftsführer der Informatik Training GmbH, Radolfzell. Josef Kraus ist Berater bei Plenum Consulting, München.