Datenbankprodukte, die sich auf sogenannte strukturelle, also hierarchische und netzwerkartige Datenmodelle stützen, haben sich im Markt seit langem etabliert. Jedoch steigen die Implementationen von relationalen DB-Systemen auffallend an. Die daraus resultierende Debatte zwischen den Verfechtern der jeweiligen Konzeption um das "bessere" beziehungsweise zukünftig allein maßgebliche Datenmodell wurde und wird weiterhin heftig geführt - allerdings nicht frei von Mißverständnissen. So ist die Ansicht daß sich relationale Systeme erst auf der Basis neuer Hardware-Architekturen, wie etwa dem Assoziativspeicher, auch für den Produktiveinsatz eignen werden, ebenso unzutreffend wie die Meinung, daß ein Navigieren in komplexen Datenstrukturen und deren genaue Kenntnis für den Anwender bei einem relationalen System quasi von selbst überflüssig wird.

Die wachsende Bedeutung des Endbenutzer-Computings und der Programmiersprachen der vierten Generation haben inzwischen zu einer vielfach akzeptierten, wenngleich nicht unproblematischen Abgrenzung des Terrains geführt. Unterschieden wird zum einen nach den Produktivbedingungen, das heißt, Verwaltung großer Datenbestände unter entsprechende Integritäts-, Sicherheits- und Verfügbarkeitsanforderungen. Hohe Transaktionsraten im Echtzeitbetrieb sind demnach die Domäne der konventionellen, strukturellen Systeme. Andererseits sprechen Performance-unkritische, jedoch Informations- beziehungsweise Endbenutzer-orientierte Probleme hingegen für die relationalen Datenbanksysteme.

Diese Einteilung ist schon deswegen unbefriedigend, weil sie mit der häufig propagierten Anwendung beider Modelle in einem Unternehmen verbunden ist (mit Überführung der Daten zwischen den Systemen in Form von Extrakten). Die Frage nach der Konsistenz und Redundanz der so entstehenden unterschiedlichen Datenbestände bleibt dabei unbeantwortet. Im übrigen wird diese Vorgehensweise durch am Markt erfolgreiche Produkte beider Typen widerlegt.

Herausragende Bedeutung für die Fortentwicklung der Datenbanktechnik im allgemeinen und für die Einordnung der unterschiedlichen Datenmodelle im besonderen kommt der Idee zu, eine konsequente Trennung von Anwendersicht beziehungsweise logischer Sicht der Daten und deren physischer Speicherung durchzuführen, wie sie etwa im Drei-Schichten-Modell von ANSI/ X3/SPARC formuliert wurde: Externe Schemata (Anwendersichten), konzeptionelles Schema (Gesamtansicht aller Daten) und internes Schema (Speicherebene) bilden voneinander unabhängige, allerdings durch Abbildungsregeln verbundene Organisationsebenen einer Datenbank.

Drei-Schichten-Modell als Qualitätskriterium

Dadurch können insbesondere die Eigenschaften des logischen Datenmodells und dessen Beschreibungsformalismen, also Codasyl- oder relationaler Ansatz, weitestgehend unabhängig gemacht werden von den technischen Eigenschaften und Leistungsparametern eines Systems. Obwohl dieses Prinzip derzeit in kaum einem Datenbankprodukt kompromißlos verwirklicht ist zeichnet es doch eindeutig den Trend der Entwicklung vor und verhilft auch heute schon zu brauchbaren Kriterien für die Beurteilung der Qualität von DB-Systemen.

Die scheinbare Unvereinbarkeit zwischen Eignung für den Produktiveinsatz und Flexibilität beziehungsweise Endbenutzerfreundlichkeit ist jedenfalls auf diese Weise zu überwinden, ohne daß vom Anwender verschiedene Datenbankprodukte mit unterschiedlichen Benutzerschnittstellen und getrennten Datenbeständen eingesetzt werden müßten.

Die Analyse der Eigenschaften eines Datenbankproduktes sollte vor diesem Hintergrund erfolgen. Der Abgleich mit den eigenen derzeitigen und künftigen Anforderungen des Anwenders kann so jedenfalls verläßlich, einsehbar und auch unter Berücksichtigung mittel- und längerfristiger Aspekte durchgeführt werden.

Zu berücksichtigen sind zunächst solche Merkmale, die Qualität und Einsetzbarkeit eines Datenbankproduktes entscheidend prägen, häufig bestimmten Datenmodellen zugeschrieben werden, tatsächlich jedoch vollkommen oder überwiegend unabhängig davon sind:

- Eignung für große Datenmengen: Sie wird nur durch interne Implementierungstechniken beeinflußt, wie zum Beispiel die Möglichkeit der Datenkomprimierung.

- Garantie von Sicherheit, Verfügbarkeit und Fehlerfreiheit der Daten: Dies ist eine grundsätzliche Frage der Produktqualität, keinesfalls irgendeines Datenmodells.

- Generelle Eignung für hohe Transaktionslasten (ohne Berücksichtigung des Transaktionstyps): Voraussetzung hierfür ist die Minimierung der Pfadlängen und Anzahlen physischer Input/Outputs bei der Bearbeitung von Datenbankaufträgen.

Den wichtigsten Beitrag zur Pfadlängen-Reduzierung liefert die Optimierung der Datenbank-Suchstrategien. Sie kann in einer eigenen, der Analyse der Datenbankaufträge vorbehaltenen Funktionsebene des Data-Base-Handlers erfolgen: Auf

diese Weise werden zum Beispiel komplexe Suchfragen intern so auf bereitet und gegebenenfalls umformuliert, daß aufgrund vorhandener (dem System bekannter) schneller Zugriffspfade und Verteilungsstatistiken jeweils eine minimale Pfadlänge und damit Antwortzeit zu erwarten ist.

Gewisse Einflüsse der Datenmodelle sind an dieser Stelle zu beachten: Relationale Sprachen sind deskriptiv - sie formulieren das Was, nicht das Wie der Suchoperation - und lassen dem System alle Freiheitsgrade für solche Optimierungen.

Die prozedurale Codasyl-DML (Datenmanipulationssprache) legt hingegen die Verantwortung weitgehend in die Hand des Anwenders beziehungsweise Programmierers. Das Potential der relationalen Technik läßt hier sehr effiziente Entwicklungen erwarten, ist in heute verfügbaren Produkten allerdings noch bei weitem nicht von ausgeschöpft.

B-Baum kontra Tuning

Die Minimierung physischer Inputs/Outputs wird zum einen durch wirksame Puffertechniken, zum anderen durch datenbanktypische Maßnahmen der Speicheroptimierung (Daten-Clustering) und des Aufbaus schneller Zugriffspfade erreicht. Strukturelle Systeme bieten dafür, quasi "von Hause aus", ein reichhaltiges Reservoir an Tuning-Möglichkeiten, vor allem zur Anpassung an spezielle Anwendungen beziehungsweise Transaktionstypen. Damit haben sie derzeit einen Entwicklungs- und Erfahrungsvorsprung vor den meisten relationalen Systemen.

Diese nutzen bislang fast ausschließlich die Technik der "inverted files" mit B-Baum-Suchpfaden, die laut Anwenderurteil allerdings auch heute schon, in vielen Fällen, von befriedigende Anwortzeiten garantiert.

Zu den Eigenschaften, die jedoch durch das Datenmodell beeinflußt werden, zählen insbesondere die Darstellung von konzeptionellen Datenstrukturen, die Art der Datenmanipulationssprache, die Benutzersicht, kritische Transaktionen sowie das Endbenutzer-Computing und die Softwaretechniken der vierten Generation.

Entgegen bisweilen auftretenden Mißverständnissen, vielleicht wegen der unterschiedlichen Datendefinitions-Sprachen, sind alle denkbaren Beziehungen zwischen Datenobjekten sowohl im Codasyl- als auch im Relationenmodell vollkommen äquivalent abbildbar.

Eine Besonderheit stellt allerdings, die automatische Überwachung von Owner-member-Abhängigkeiten in Codasyl-Systemen dar: Ein Auftragssatz kann dadurch zum Beispiel nicht in die Datenbank. "eingehängt" werden, ohne daß der zugehörige Kundensatz (der Owner) bereits definiert ist. Derartige Konsistenzüberwachung obliegt in relationalen Systemen dem Anwender.

Die Datenmanipulation wird vom Benutzer eines strukturellen Systems prinzipiell als Vorgang beschrieben, der zum gewünschten Ergebnis führt, das heißt in einer prozeduralen Sprache. Die Sprachen relationaler Systeme hingegen beschreiben die Ergebnisse selbst, also deskriptiv.

Ihnen wird daher generell hohe Endbenutzerfreundlichkeit im Sinne von Einfachheit und Verständlichkeit zugeschrieben. Dies bestätigt sich zumindest bei einfacheren Operationen der Datenwiedergewinnung ohne Verknüpfung verschiedener Datenobjekte.

Endbenutzer wünscht deskriptive Sprache

Unter Benutzersichten oder Views werden logische Ausschnitte aus der Gesamtdatenstruktur verstanden, die genau auf einen bestimmten Anwender zugeschnitten sind und von diesem wie einfache Dateien ("logische Dateien" ) oder Tabellen hantiert werden können. Da sie die größtmögliche Unabhängigkeit zwischen Anwendungen (Programmen) und Daten garantieren, sind sie von zentraler Bedeutung für den Nutzen von Datenbanksystemen.

Zudem bieten sie ein elegantes Hilfsmittel, um komplexere, schwer formulierbare Datenverknüpfungen vor dem Endbenutzer zu verbergen. Der View-Begriff ist bereits im Grundkonzept des Relationenmodells enthalten und bildet dort ein wichtiges "Betriebsmittel" für den Anwender. Das Subschema stellt in Codasyl-Systemen das entsprechende Gegenstück dar, erreicht aber nicht die Flexibilität des relationalen View.

Die besondere Eignung der relationalen Datenbanktechnik liegt zweifelsfrei auf dem Gebiet des Endbenutzer-Computings und der Softwaretechniken der Vierten Generation. Fourth-Generation-Languages sind häufig auf der Basis relationaler Datenbankprodukte entwickelt beziehungsweise darin von integriert worden.

Allerdings gibt es auch heute schon für weitverbreitete Codasyl-Produkte leistungsfähige Endbenutzerschnittstellen mit deskriptiver Sprache, die im Sinne des obengenannten Schichtenmodells auf der externen Ebene der Systeme implementiert wurden.

Join-Operation als K.-o.-Kriterium

Abhängig vom Datenmodell ist auch die Verarbeitung zeitkritischer Transaktionen auf stark vernetzten Datenstrukturen. Der sachliche Hintergrund für die vermeintlich ungenügende Leistungsfähigkeit relationaler Systeme ist im wesentlichen hier zu suchen. Dabei ist klarzustellen, daß das Problem nicht im Vernetzungsgrad der Datenstrukturen an sich liegt, sondern in deren Verarbeitung in einer Transaktion.

Da die Pflege und Überwachung vordefinierter und damit starrer Datenverknüpfungen den Grundideen des Relationenmodells widerspricht, müssen diese im Bedarfsfall durch die sogenannte Join-Operation hergestellt werden.

Dies garantiert zwar höchste Flexibilität bei der Kombinierbarkeit von Daten, bedingt aber ein im Vergleich zu strukturellen Systemen zeitlich sehr aufwendiges Verfahren. Sind also Transaktionen der beschriebenen Art in wesentlichen Anwenderverfahren zu erwarten, was durch entsprechende Untersuchungen zu klären ist, so kann dies beim derzeitigen Stand der Technik durchaus zu einem Ausschlußkriterium für ein relationales System werden.

Es bleibt festzuhalten, daß vereinfachende und undifferenzierte. "Kochrezepte" zur richtigen Systemauswahl derzeit mit Vorsicht ZU betrachten sind. Die kontrovers geführte Debatte um das strukturelle oder relationale Datenmodelle wird noch einige Zeit die Gemüter erhitzen, wenn auch der Trend zu relationalen Sprachen auf der externen Datenebene eindeutig erscheint.

Die Schwierigkeit, die beiden Datenmodelle technisch in konkreten Produkten zu vereinen, hat verschiedene DV-Hersteller (IBM, Siemens, Univac) zu der pragmatischen Vorgehensweise veranlaßt, beide Alternativen in verschiedenen Produkten anzubieten und den Anwender auswählen zu lassen, welches Produkt er aufgrund seiner spezifischen Anforderungen einsetzen will.

Diese Vorgehensweise wird vom Markt durchaus akzeptiert. Geeignete Entscheidungskriterien für den Anwender sind vorhanden. Sie werden auch heute schon in zahlreichen Fällen zur Auswahl eines relationalen Systems führen. Andererseits stellt die Auswahl eines strukturellen Systems keine" Sackgasse" auf dem Weg in die Zukunft dar, falls die heutige Produktstruktur bereits eine moderne Benutzeroberfläche und Ansätze zur Schichtenarchitektur erkennen läßt.

Dr. Bernadin Denzel ist Produktplaner für DB/DC-Systeme im BS2000 bei der Siemens AG, München.