DARMSTADT - Mit einer verteilten Datenbank besonderer Art arbeiten IBM-Anwender, die sich für die Installation von SQL/DS entscheiden und im Verbund damit ihr bisher schon gefahrenes Datenbanksystem weiterbenutzen. Die Verknüpfung, die hier angesprochen ist, wird durch die in SQL/DS enthaltene Extraktfunktion hergestellt, mit deren Hilfe die in der "alten" Datenbank gespeicherten Informationen auch dem SQL/DS-User verfügbar gemacht werden. Über Vor- und Nachteile des vor einiger Zeit angekündigten neuen DB-Konzepts der IBM sprach Bernd Löfflath in Darmstadt vor Teilnehmern des Forums '81 für Wissenschaft und Verwaltung (Veranstalter: IBM).

Löfflath, der bei IBM an der zentralen Produktverantwortung für mittlere Systeme mitträgt und den einzelnen Geschäftsstellen Vertriebsunterstützung zukommen läßt, bezeichnete Edgar F. Codd, den Entwickler des fast schon legendären relationalen DB-Konzepts "System R", als den Paten des nach nunmehr fünf Jahren "echter Erprobung" (Löfflath) ab März 1982 marktreifen Produkts, das in Langschrift "Structured Query Language/Data System" heißt.

Es sei kein Geheimnis, meinte er, daß das einstweilen auf den mittleren Systembereich (DOS/VSE) zugeschnittene SQL/DS auch für andere VM- (also für diverse OS-) Umgebungen zu erwarten stehe. Schon daraus sei ersichtlich, daß für den SQL/DS-Anwender der parallele Einsatz einer bestimmten zusätzlichen oder überhaupt einer Datenbank keinesfalls zwingend erforderlich sei.

Dennoch, wandte Löfflath sich an seine Zuhörer aus dem DOS-Lager, sei es von großem Vorteil, neben dem relationalen SQL/DS auch eine DL/1-Datenbank zu betreiben. Es werde in der Praxis des DV-Alltags nämlich immer Anwendungen geben, die mit dem "Korsett" (Löfflath) der DL/1-Formalismen besser zu fahren seien. Löfflath begründete dies mit dem unterschiedlichen Antwortzeitverhalten und der anders angelegten Benutzerfreundlichkeit der beiden DB-Systeme (siehe Grafik).

Demzufolge gebe es in SQL/DS im Gegensatz zu DL/1 eine - in Worten Codds - "automatische Navigation des Systems zu den Zieldaten" und in den Tabellen keinerlei "Verpointerungen" (Löfflath). Welche Daten mit welchen zu verbinden seien, bestimmte der Anwender im jeweiligen Einzelfall. Aus diesem Grunde liege der Haupteinsatzbereich von SQL/DS in der ungeplanten Datenverarbeitung, ferner in der Bewältigung des Problems der spontanen Abfragen und der sich strukturell häufig ändernden Daten.

Für den SQL/DS-Komfort - zu ihm gehört beispielsweise die non-prozedurale Sprache mit stets gleicher Syntax - hat der Anwender einige Vorleistungen zu erbringen. Auf Dinge wie Lizenzgebühren oder zusätzlichen Speicherbedarf ging Löfflath dabei jedoch nicht ein, sondern begnügte sich mit der DV-technischen Seite: "Man muß auch bei SQL/DS die Daten mehr oder weniger sorgfältig vorbereiten; die Vorarbeit ist hier mit dem Design einer DL/1-Datenbank identisch."

Weitere Grenzen von SQL/DS nannte Löfflath beim Namen, als er die Beziehungen dieses Systems zu DL/1 charakterisierte: "Es gibt immer ein Pro und Kontra bei den jeweiligen Datenbankkonzepten, wie es etwa bei der Autorisierung von Mitarbeitern zu Update- und Löschbefehlen in einer SQL/DS-Tabelle deutlich wird. Hier kann es Probleme geben, die der DL/1-Anwender nicht hat."

Löfflath ließ jedoch keine Zweifel an seiner Überzeugung, daß SQL/DS sich - anders als sein relationaler Vorgänger "Query By Example" - am Markt durchsetzen wird. Gründe dafür seien: Die relationale Form der Darstellung von Daten und die für die Definitionen und Operationen zu verwendende Structured Query Language seien leicht erlernbar. In der DL/1-Datenbank gespeicherte Daten seien mittels der Extraktfunktion in eine relationale Form überführbar. SQL/DS verfüge über diverse Sicherheits- und Kontrolleinrichtungen sowie über Recovery/Restart-Funktionen.

Wie Untersuchungen ergeben hätten, fügte Löfflath hinzu, mache der Einsatz von SQL/DS die nach üblichem Verfahren geplante Entwicklung von Applikationsprogrammen vielfach überflüssig: Sechs von 24 geplanten Programmen, nannte er als Erfahrungswert, müßten auch weiterhin auf konventionelle Weise erstellt werden. Der Softwareentwickler habe bei SQL/DS die Möglichkeit, die in der relationalen Datenbank gespeicherten Daten auch von den Anwendungsprogrammen aufrufen zu lassen.

In einem historischen Zusammenhang betrachtet, meinte Löfflath, bleibe festzuhalten, daß im Falle von SQL/DS die Software der Hardware - speziell der Speichertechnologie - voraus sei. Aus dem gleichen Grunde sei eben auf dem Feld der Speichertechnologie etwas zu erwarten - in ferner Zukunft, wie er sich zu versichern beeilte. Bis dahin werde SQL/DS das VSAM-Speicherverfahren anwenden.

Verteilte Basen noch in den Kinderschuhen

Durch die drastischen Preisreduktionen der Mainframe-Hardware in den letzten drei Jahren und die Leistungssteigerungen der schon immer preisgünstigen Minis können sich immer mehr Unternehmen den Weg von der rein zentral-orientierten DV zu verteilten Computersystemen leisten. Andererseits sind in den letzten Jahren zunehmend Datenbanksysteme installiert worden, deren integrierender und zentralisierender Charakter nicht zu leugnen ist. Wie bekommt man diese beiden widersprüchlichen Trends unter einen Hut? "Distributed Data Bases" heißt die Lösung, mit der inzwischen viele Anbieter von Datenbank-Software hausieren gehen. Was steckt eigentlich dahinter? Wie weit ist die tatsächliche Entwicklung?

Schon seit Jahren wird das Für und Wider von Distributed Data Processing (DDP) diskutiert. Häufig ähneln die Auseinandersetzungen darüber eher Glaubensfragen als sachlicher Argumentation. Für manchen Datenverarbeiter handelt es sich dabei um einen Stellungskrieg.

Schuld am Ausufern der Diskussion hat der Begriff "Distributed Data Processing" selbst, der so vage ist, daß er ein schier unüberschaubares Spektrum an Lösungen und Konzepten umfassen kann. "Distributed" heißt im Deutschen "verteilt".

Was hier unter "verteilt" gemeint ist und was nicht, soll folgende Gegenüberstellung verdeutlichen:

- Dezentralisierte Datenverarbeitung = eine Anzahl autonomer Computersysteme;

- Verteilte (distributierte) Datenverarbeitung = physisch unterschiedliche Computersysteme unter einer zentralen Kontrolle und Koordination. Die separaten Computer kommunizieren in irgendeiner Form miteinander; das reicht von gelegentlichem Datenaustausch auf Magnetbandbasis bis zu direkter Channel-to-Channel-Verbindung.

Und bezogen auf Datenbanken:

- Dezentralisierte Datenbanken = autonome Datenbanken, die üblicherweise einen individuellen funktionalen Bereich repräsentieren. Merke: Dezentralisierte Datenbanken könnten sich im Prinzip auf einem Rechner befinden.

- Verteilte (distributierte) Datenbanken = physisch unterschiedliche Datenbanken unter einem globalen Design und einer umfassenden Koordination, die den Datenaustausch und die Datenzusammenführung ohne besondere Kenntnisse der Anwender übernimmt.

"Distributed" steht also immer für eine geordnete und koordinierte Verteilung - nicht für eine chaotische Ansammlung von Computern und Datenbanken.

Warum überhaupt verteilen?

Um die konzeptionellen Ansätze von Distributed Data Bases besser zu verstehen, ist noch eine weitere Überlegung wesentlich: Billigere Hardware ermöglicht Distributed Data Processing, aber zwingt uns nicht dazu. Warum aber sollen wir denn überhaupt die DV-Leistung verteilen?

Ganz knapp hierfür die drei wichtigsten Gründe:

- Die Kommunikationskosten für Unternehmen, die geografisch verstreut sind, werden extrem hoch, wenn jede einzelne Terminaleingabe bis zum zentralen Rechner transportiert werden muß.

- Lokale (oder teilweise lokale) Verarbeitung bietet den Anwendern besseren Service hinsichtlich Antwortzeitverhalten, Verfügbarkeit und Disposition der DV-Arbeiten. Zugleich erhöht die Eigenverantwortung den Grad der Zufriedenheit.

- Vielfach können für große Unternehmen noch nicht einmal Jumbo-Rechner den gravierend steigenden Leistungsbedarf an TP- und Batch-Anwendungen sowie Programmentwicklung abdecken und müssen durch mehrere Anlagen ersetzt werden. Distributed Processing kann also auch innerhalb eines Raumes stattfinden.

Das Problem: Die Verfügbarkeit der Daten

Anwendungen auf verschiedene Rechner zu verteilen, ist keine Schwierigkeit. Das eigentliche Problem liegt in der Verteilung und Koordinierung der Daten.

Daten sind ein "globales" Betriebsmittel. Ihre Verfügbarkeit ist an den Rechner gekoppelt, an dem die jeweiligen Datenträger angeschlossen sind. Bei ihrer Verteilung im Rahmen des Distributed Processing gibt es drei Möglichkeiten:

- Daten, die nur von jeweils einer Stelle benötigt werden, lassen sich meist problemlos aufteilen ("Partitioned Data Bases").

- Daten, die von vielen Stellen benötigt werden, müssen in mehreren Inkarnationen vorhanden sein ("Replicated Data Bases"). Dies ist nur problemlos, solange sie nicht von vielen Stellen auch aktualisiert werden.

- Daten, die von vielen Stellen geändert werden und sofort für alle Benutzer verfügbar sein müssen, müssen zwangsläufig an einem Ort konzentriert sein.

Hieraus ergeben sich Kriterien für die Beurteilung der verschiedenen Ansätze für verteilte Datenbanken.

Message-Switching-Systeme

Ein Konzept, das beispielsweise in dem Multiple System Coupling (MSC) des IMS/VS realisiert ist, besteht darin, eine Nachricht, die Daten einer Datenbank an einem anderen Rechner benötigt, zur Bearbeitung an diesen Rechner weiterzuleiten. Sowohl das notwendige Anwendungsprogramm als auch die Daten residieren an dem anderen Rechner (siehe Abbildung 1).

Obwohl IMS/VS ein DB- und DC-System ist, hat diese Funktion mit Distributed Data Base nichts zu tun, denn es handelt sich hierbei um eine Fähigkeit des TP-Monitors. Die Datenbanken sind in diesem Fall völlig autonom, und es besteht kein übergreifendes Design oder eine zentrale Koordination. Dies wäre aber für eine wirklich verteilte Datenbank erforderlich.

Shared Data Base

Eine weitere Möglichkeit besteht in dem Konzept, das bei IDMS verwirklicht wurde. Hierbei befindet sich die Datenbank geschlossen an einem Rechner unter Kontrolle eines realen DBMS. TP- und Batch-Anwendungen auf anderen Rechnern arbeiten zwar so, als hätten sie ein eigenes DBMS auf ihrem Rechner, in Wirklichkeit handelt es sich nur um ein scheinbares ("virtuelles") DBMS, das den DB-Zugriff an das reale DBMS auf dem anderen Rechner weiterleitet (siehe Abbildung 2).

Mehrere Anwendungen teilen sich also eine gemeinsame Datenbank. Durch die zentrale Verwaltung kann die Konsistenz der Daten und ein korrektes Recovery mit den heute verfügbaren Techniken problemlos abgesichert werden. Doch es gibt auch Haken.

Performance-Probleme

Solange die Rechner physisch zusammenstehen, ist eine Kanalverbindung möglich, die die Performance nicht so stark beeinträchtigt.

Wenn aber zwischen den Rechnern ein Datentransport über Leitungen erfolgen muß, wird es problematisch: Eine Nachricht löst mindestens drei, meistens aber noch wesentlich mehr DB-Aufrufe aus. Besonders die "One record at a time"-Technik strukturierter Datenbanksysteme (IMS, IDMS, UDS, Total etc.) führt bei einem Suchprozeß zu einer Vielzahl von DB-Aufrufen. Ihr Transport über die recht langsamen Leitungen vervielfacht die Antwortzeiten. Damit wird ein wesentlicher Vorteil verteilter Verarbeitung wieder aufgehoben.

Problem: Maschinen-übergreifende Koordination

Eine zentrale Datenbank ist dann nötig, wenn Daten von vielen Stellen aus aktualisiert werden und sofort verfügbar sein sollen. Handelt es sich aber um Daten nur für lokale Anwendungen, so sollten sie auch lokal angesiedelt sein.

Dafür erlaubt das IDMS-Konzept mehrere reale und virtuelle DBMS zu kombinieren. In diesem Fall fehlt jedoch eine übergreifende Koordination. Es gibt keine maschinenübergreifenden Sets (also Verkettung von Daten), keine globalen "User Views" (Subschemata) über mehrere Datenbanken und kein umfassendes Directory. Jedes reale DBMS ist somit eine eigene autonome Datenbank und eine umfassende Datenintegrität mit einem synchronisierten Recovery ist in Frage gestellt.

Vernetzte Datenbanken

Ein anderes Konzept geht davon aus, lokale Daten in einer lokalen Datenbank zu halten und Zugriffe zu Daten auf anderen Rechnern - seien es ebenfalls lokale oder zentrale Datenbestände - automatisch weiterzuleiten.

Vorgeschlagen vor jedem lokalen DBMS muß sich eine DB-Netzwerksoftware befinden, die jede DB-Anforderung prüft, wo sie ausgeführt wird und die Kommunikation mit den anderen Rechnern übernimmt. Dazu muß an jedem Rechner ein Verzeichnis (Directory) existieren, wo welche Daten gespeichert sind.

Diesem Lösungsansatz folgen beispielsweise die Produkte Net-work für Adabas, D/Net für Datacom und IQ/ Net für Inquire, die sich in unterschiedlichen Realisierungsstadien befinden.

Problem: Synchronisation mehrerer Datenbanken

Solange eine Transaktion nur Daten aus jeweils einer der Datenbanken bearbeitet, können Konsistenz der Daten und Recovery mit den heute verfügbaren Techniken abgewickelt werden.

Arbeitet aber eine Transaktion mit mehreren Datenbanken gleichzeitig, muß das Transaktionsende mit den Datensicherungsmaßnahmen mehrerer DBMS abgestimmt werden. Das ist nicht so einfach. Besonders, wenn man daran denkt, daß heute oft noch nicht einmal das Recovery eines TP-Monitors mit einem einzigen DBMS synchronisiert werden kann.

Hierfür bringt zum Beispiel die Software AG mit der nächsten Version von Adabas eine geeignete Voraussetzung: Die Funktion "preliminary ET" ermöglicht die Synchronisation einer Anwendung mit mehreren Datenbanken.

Datenbank-übergreifende Operationen

Für vernetzte Datenbanken eignen sich die ausgeführten DBMS (Adabas, Datacom, Inquire) aus zweierlei Gründen:

- Suchoperationen arbeiten nach Mengen-algebraischer (relationaler) Technik: Durch "many records at a time" ist die Anzahl der zu übertragenden DB-Anforderungen geringer als bei strukturierten Datenbanken.

- Zwischen einzelnen Dateien beziehungsweise Datenbanken dieser Systeme brauchen keine Verkettungen aufgebaut werden, um logische Datenbeziehungen herzustellen. Logische Beziehungen zwischen Daten entstehen automatisch aufgrund gleicher Dateninhalte, die mittels invertierter Listen gefunden werden.

Dadurch können sich DB-Operationen auch über mehrere Datenbanken erstrecken, etwa "Finde die Aufträge mit Lieferdatum vor dem 31. 10. 81 von Kunden aus dem Gebiet Hannover", wobei die Aufträge und die Kundendaten auf getrennten Datenbanken liegen.

Was sind die Konsequenzen?

- Für verteilte Datenbanken sind nichtstrukturierte DBMS auf Basis invertierter Dateien besser geeignet, da sie flexibler sind und problemlos Datenbank-übergreifende Operationen abdecken.

- Die Verwaltung der einzelnen Datenbanken muß durch das gleiche DBMS erfolgen. Ein Zusammenwirken unterschiedlicher DBMS zu einem globalen Datenbanksystem ist unrealistisch.

- Dadurch können in einem Distributed-Processing-System nur Rechner eingesetzt werden, auf denen dieses DBMS auch ablauffähig ist. Dadurch reduziert sich der Spielraum, geeignete und preisgünstige Minis verschiedener Provenienz um einen Mainframe-Computer zu gruppieren, lediglich auf einen Mix kleinerer und größerer Mainframer.

Nach dem heutigen Stand könnten also neben IBM- und Siemens-Anlagen lediglich noch DEC-Rechner in ein DDP-Konzept einbezogen werden, für die es Versionen von Adabas und IDMS gibt. Total unterstützt zwar viele Minicomputer, aber keine verteilten Datenbanken.

Die hier dargestellten Lösungen für verteilte Datenbanken sind weitgehend schon technisch realisiert und werden bereits angeboten. Trotzdem steckt die Entwicklung der Software

hierfür noch in den Anfangsstadien. Zum einen müssen die bisherigen Ankündigungen erst vollständig realisiert und praxiserprobt sein; zum anderen müssen die Konzepte noch weiterentwickelt werden, um die grundsätzlichen Probleme zu beseitigen.

Dazu gehören zum Beispiel:

- Globales Directory/Data Dictionary;

- "User Views" über mehrere Datenbanken;

- Verknüpfungen über mehrere Datenbanken ( "Cross-Machine-Set" ).

Fazit: Es ist ein Trugschluß zu glauben, daß mit Distributed Data Bases die konzeptionellen und organisatorischen Probleme des Distributed Data Processing einfach gelöst werden. Ganz im Gegenteil. Verteilte Datenbanken sind ein Werkzeug, das enorme Komplikationen mit sich bringen kann, wenn das Konzept für eine DDP-Lösung nicht konsequent und sauber durchorganisiert ist.