In zirka 14 Jahren erarbeitete das "Codasyl"-Komitee seine Empfehlungen für eine allgemeine Datenbankstruktur in der heutigen Form. Das Konzept hat sich langsam durchgesetzt. Da tauchen nicht nur neue Konzepte relationaler Datenbanken auf, sondern auch der Wunsch nach verteilten Datenbankkonzepten wird immer stärker. Dabei wird jedoch oft vergessen, daß dies nicht mehr nur eine Frage der Softwareprodukte ist, die die einzelnen Hersteller anbieten und als Hilfsmittel zur Verfügung stellen, sondern, daß das Anforderungen an eine Organisationsabteilung stellt, die vielerorts unterschätzt werden.
Mitte der 60er Jahre begann die "Conference on Data Systems Languages" (Codasyl) mit den Überlegungen, ein allgemeines Datenbankkonzept zu definieren. Diese führten zu der Bildung der "Data Base Task Group" (DBTG). Das Konzept das hier erarbeitet wurde, ist unbestritten. Da einige Mainframe-Hersteller es auch schon relativ früh installiert haben, kann man davon ausgehen, daß es auch seine praktische Erprobung bestanden hat. Es ist auch nicht auszuschließen, daß diese Empfehlungen so oder in modifizierter Form eine ANSI-Norm im nächsten Jahr werden.
Bei dem DBTG-Entwurf wurden als Ziele gesehen:
- Flexible Strukturierung von Daten, passend für jede Anwendung ohne die Notwendigkeit von Daten-Redundanz
- Flexible Möglichkeiten zur Definition von Datenstrukturen
- Unabhängige Definition der Daten in der Datenbasis und des Datendetails im Programm
- Programmiersprachenunabhängige Definition der Datenstruktur
- Gleichzeitiger Zugriff mehrerer Programme auf eine Datenbasis
- Flexible Zugriffsmöglichkeiten auf die Daten
- Schutz der Daten vor unberechtigtem Zugriff
Die Vorstellungen zielten eindeutig in Richtung lokaler Datenbanken. Bis sie in der jetzigen Form in die Codasyl-Empfehlungen eingingen, vergingen annähernd 14 Jahre.
Kaum beginnt sich dieses Konzept auf breiterer Basis bei Herstellern und Anwendern durchzusetzen, kommen neue Konzepte relationaler Datenbanken auf. Diese Situation zeigt, daß in den Datenbankkonzepten eine Bewegung ist, die vom Anwender kaum noch mitgemacht werden kann. Dabei sollte allerdings nicht verschwiegen werden, daß die erwähnten relationalen Datenbanken ihren Praxistest noch nicht einwandfrei bestanden haben.
War bisher immer nur von dem Konzept einer abgeschlossenen lokalen Datenbank die Rede, so ist der Ruf nach verteilten Datenbanken schon lange hörbar und die Forderung an Hersteller, hier vernünftige Konzepte zu bieten. Dabei wird jedoch oft übersehen, daß schon der Installation einer lokalen Datenbank eine Designphase vorausgehen muß, die erhebliche Anforderungen an die Organisation stellt. Die Arbeit, die in dieser Phase geleistet wird, entscheidet darüber, ob der Anwender später den optimalen Nutzen von seinem Datenbanksystem hat. Ein gutes Datenbanksystem des Herstellers kann in dieser Phase zwar von großem Nutzen sein, jedoch ist gerade die Flexibilität eines Datenbanksystems eines seiner großen Vorteile und deshalb kann dem Anwender nicht die Arbeit eines guten Designs abgenommen werden.
Ausgehend von diesen Voraussetzungen kommt man zu dem Schluß, daß bei dem Ruf nach verteilten Datenbanken vielerorts der organisatorische Aufwand für die Vorbereitung der Installation eines solchen Systems unterschätzt wird, obwohl auch hier, ebenso wie beim Installieren eines lokalen Systems die Hilfsmittel und Systeme des Herstellers von großer Bedeutung sind, vergrößert sich der Aufwand, den der Anwender zu treiben hat.
Für die Installation einer verteilten Datenbank gibt es im Prinzip zwei Konzepte.
Wenn von verteilten Datenbanken gesprochen wird, denken viele an dieses Konzept: Eine Datenbank, die auf verschiedene Systeme im Netz verteilt ist, wobei die Zugriffe zwischen den Bindungen für den Benutzer nicht sichtbar erfolgen. Dieses System ist nicht nur von der Konzeption des eigentlichen Datenbanksystems her das komplexere, sondern würde auch in der Designphase den meisten Aufwand erfordern. Dabei kann man davon ausgehen, daß Designfehler bei diesem System die gravierendsten Folgen beim Betrieb haben.
Die Zielsetzung der Vermeidung von Daten-Redundanzen kann nur bei diesem Konzept vollkommen aufrecht erhalten werden. Jedoch gerade diese Maxime sollte bei verteilten Datenbanken gegenüber der Forderung nach Reduzierung der Belastung der Kommunikationswege etwas in den Hintergrund treten. Große Mengen an Informationen, die zwischen den Rechnern ausgetauscht werden, belasten den Verbund mehr, als die Redundanz, die sich nur auf die Gruppe der Externspeicher auswirkt.
Auch Distributed Data-Base- Konzepte greifen auf Komponenten von vorhandener Netzwerk-Software zurück. Die Schnittstellen sind jedoch intern. Der Benutzer kennt bei einem solchen System in der Regel nicht die Abläufe innerhalb des Datenbanksystems. Diese fehlenden Kenntnisse erhöhen die Gefahr, daß zu viele Zugriffe zwischen den einzelnen Systemen erfolgen, die nicht nur die Rechner stark belasten, sondern auch die Kommunikationsverbindungen über Gebühr strapazieren. Dies natürlich vor allem, wenn die Datenkomponenten aufgrund gewisser organisatorischer Fehler falsch im Netz verteilt sind.
Remote Data Base
Die Alternative zum vorangegangenen Konzept ist die Installation von mehreren, abgeschlossenen Datenbanken im Netz. Natürlich muß hier als zusätzliche Komponente ein leistungsfähiges Netzverwaltungssystem vorhanden sein. Die im vorigen Abschnitt genannten Fehlerquellen versucht man bei diesem System etwas einzugrenzen, indem die Schnittstelle zwischen Datenbank-Software und Netzwerk-Software transparent ist. Dem Benutzer wird die Verantwortung mitübertragen, zu entscheiden, wann er lokal zugreift und wann er Zugriffe auf entfernte Datenbanken im Netz macht. Das Konzept setzt voraus, daß neben den lokalen Datenbanken, die in sich abgeschlossen sein sollen, die Möglichkeit bestehen muß, auf entfernte Datenbanken zuzugreifen. Da dieser Zugriff dem Anwender bei Bedarf sichtbar gemacht werden kann, kann hier auch eine gewisse Kontrolle erfolgen, ob die Verteilung der Daten innerhalb des Netzes optimal ist. Dieses zweite Konzept wird von vielen deswegen als mangelhaft angesehen, weil es vielleicht nicht die Eleganz aufweist, die der Informatiker in ihm sehen möchte, jedoch sollte man dabei nicht außer acht lassen, daß dieses zweite Konzept die Höchstanforderungen, die an die Organisatoren gestellt werden, wenigstens etwas herunterschraubt. Trotzdem sollten auch hier die Vorarbeiten nicht unterschätzt werden.
Mini-Chance
Wenn man von der Gegenüberstellung der beiden Konzepte ausgeht, dann sieht man auch eine Chance der Minicomputer:
Die Bezeichnung Mini mag vielleicht noch für die Computer gerechtfertigt sein, nicht mehr aber für ihre Leistung, die in den letzten Jahren stark gesteigert wurde.
Mit dieser Leistung erfüllen sie Anforderungen, die an einen Rechner im Netz gestellt werden, der eine lokale Datenbasis halten soll. Und leistungsfähige Werkzeuge, sowohl im Hinblick auf Datenbanksysteme, als auch Netzwerkverwaltungssysteme mit den Möglichkeiten des Remotezugriffes auf Datenbanken, sind durchaus vorhanden.
* Ulrich Schöll ist Leiter der Systemunterstützung des Distrikts Mitte der Data General GmbH, Eschborn.