Was Lawrence J. Ellison, Präsident der Oracle Corp., auf der diesjährigen Benutzerkonferenz in Cannes zu sagen hatte, schlug ein. Er erklärte, daß "das Relationale Datenmodell" (RDM) nicht mehr alle Bedürfnisse der Anwender relationaler Datenbankmanagement Systeme trifft". Die Überraschung war groß, weil es Ellison war, der in den letzten Jahren stets allen Benutzerforderungen nach mehr Ausdruckskraft in Syntax und Semantik ablehnend gegenüberstand.

Für die Wünsche der Anwender nach Definition von strukturierten Objekten, deduktiven Methoden, nach smarten Optimizern oder der Integration von KI-Methoden mit Datenbanktechniken zeigte Ellison in der Vergangenheit wenig Verständnis. Streng auf dem Kurs der IBM-Forschung gab es seiner Ansicht nach jenseits des RDM keinen Markt, der die notwendigen Investitionen hätte rechtfertigen können.

Inzwischen nähert sich der Markt der objektorientierten Datenbankmanagement-Systeme (OO-DBMS) einem jährlichen Volumen von 200 Millionen Dollar. Aber es ist sicherlich nicht die Größe dieses Marktes, weshalb Oracle nun zum Aufbruch bläst. Als Ellison begann, relationale DBMS mit der Datenbanksprache SQL zu entwickeln, gab es überhaupt keinen Markt für SQL-Produkte. SQL war nur eine der verschiedenen Definitionen des RDM, entlehnt aus dem IBM-Prototyp "System/R" .

Was also brachte den kühlen Rechner Larry Ellison zu einer Meinungsänderung? Eine Reihe von Vermutungen bietet sich an. Zunächst einmal wächst der Markt der OO-DBMS überdurchschnittlich schnell. Er wird in wenigen Jahren die Milliardengrenze erreichen. Die langjährigen Anwender relationaler Datenbanktechnologie stoßen immer häufiger an die Grenzen des konventionellen

Datenmodells, wenn sie Systeme mit großer Komplexität darzustellen haben.

Nun hat die Oracle Corp. auch keine schlechten Voraussetzungen, um einen Hattrick zu versuchen: Erstens gibt es Hunderttausende von Oracle-Installationen weltweit, die robusten Versionen 5 und 6 fahren. Zweitens hat sich Oracle mit der PL/SQL ein Werkzeug für die Entwicklung innovativer Produkte geschaffen. Schließlich sollte man auch nicht die geschäftliche Intuition Ellisons unterschätzen. Die Zeit ist einfach reif, um über Edgar Codds RDM hinauszugehen und das Potential der Relationentheorie voll auszuschöpfen.

Die Oracle Corp. hat ein Signal gegeben, das niemand übersehen darf, der auch morgen noch im DBMS-Markt mitmischen will. Für die kleinen OO-DBMS-Hersteller ist es ein Alarmzeichen: Das Budget für Forschung und Entwicklung von Oracle Corp. übersteigt die Jahresumsätze dieser Hersteller bei weitem.

Noch auf der Fachmesse "Tool 91" im November vorigen Jahres wurde in einigen Vorträgen die Meinung vertreten, daß relationale DBMS und objektorientierte DBMS zwei völlig verschiedene Paar Stiefel seien. Es gibt akademische Hardliner, die behaupten, daß es niemals relationale, objektorientierte DBMS geben kann. Sie verweisen darauf, daß es bei den objektorientierten DBMS um strukturierte Entitäten geht, während man mit dem relationalen Datenmodell nur atomare, also strukturlose Sachverhalte darstellen könne.

Diese Dogmatiker seien auf die seriöse Gruppe von französischen Mathematikern verwiesen, die seit Generationen unter dem Pseudonym "Nicolas Bourbaki" für Furore sorgt. Bourbaki hat das Gebäude der reinen Mathematik auf dem Strukturbegriff aufgebaut. Wenn eine Grundmenge gegeben ist, dann wird der Begriff "Struktur" als eine geordnete Menge von Relationen definiert (siehe Kasten).

Wenn man das traditionelle Relationenmodell in geeigneter Weise erweitert, so läßt sich jede Form einer mengenorientierten Struktur definieren. Herausgefordert, zur These der Unverträglichkeit Stellung zu nehmen, erwiderte Ellison: "Wenn man es richtig macht, dann wird es auch arbeiten. Wir werden eine neue API-Ebene über die SQL-Ebene legen. Die technische Implementation aber ist nicht der entscheidende Punkt. Entscheidend ist, daß unsere Benutzer nicht den Rückfluß aus ihren großen Investitionen in die Datenbanktechnologie verlieren."

Ken Jacobs, Oracles Vizepräsident für die RDBMS-Entwicklung, verwies auf die Standardisierungsbemühungen um SQL 3. Hier wurde versucht, eine objektorientierte Sprache OSQL zu entwickeln; daneben gibt SQL 3 dem Benutzer die Möglichkeit, weitere Typen von Tabellen zu definieren. Bekanntlich erlaubt das traditionelle Datenmodell nur die Definition eines einzigen Tabellentyps, nämlich die Definition eines Sachverhalts durch eine symmetrische Relation.

Die bereits im Markt angebotenen OO-DBMS beruhen heute meist auf objektorientierten Sprachen wie C + + oder Smalltalk. Angesichts des Fehlens eines wohldefinierten objektorientierten Datenmodells und einer allgemein akzeptierten Syntax zur Definition von strukturierten Objekten sprechen Kritiker davon, daß die heute verfügbaren OO-DBMS nichts anders sind als Dateimanagement-Systeme für gewisse, prozedurale Sprachen.

Wenn man diese OO-DBMS bewerten soll und als Maßstab die Reife, Robustheit und Benutzerfreundlichkeit relationaler DBMS heranzieht, dann sind sie mit Risiken und gravierenden technischen Schwächen belastet:

- Die heutigen OO-DBMS erlauben keine Migration existierender Datenbanken. Der Entwickler beginnt wieder am Nullpunkt; das heißt, man muß neu investieren. Bestenfalls gibt es Bridge-Programme, die mittels einfacher SQL-Kommandos Daten aus existierenden Datenbanken extraktieren können.

- Hersteller und Vertreiber von OO-DBMS sind relativ kleine Firmen, die mit Hilfe von Risikokapital in mehreren Finanzierungsrunden versuchen, marktfähige Produkte herzustellen und zu vertreiben. Fast alle diese Hersteller kämpfen ums Überleben. Die mangelnde Kapitalausstattung bietet wenig Sicherheit, den Rückfluß aus Investitionen zu gewährleisten.

- Es gibt immer noch keinen Standard für die Definition von strukturierten Entitäten. Über den Vorschlag des Herstellervereins "Objekt Management Group" (OMG), der Spezifikationen für einen Standard beschreibt, herrscht noch keine Übereinstimmung. Offenbar spielt das OMG-Mitglied "Microsoft Corp." nicht mit. Man hat bei Microsoft mit dem Betriebssystem Windows NT und dem "Cairo"-Projekt offenkundig etwas anderes im Sinn. Es ist zu befürchten, daß das Ringen um einen Standard wieder bei einem Kompromiß endet, den alle Beteiligten schließlich als unbefriedigend beurteilen werden.

- Aus dem Mangel an Standards folgt das Fehlen von "offenen Systemen". Nichtgenormte Syntax und Semantik binden den Benutzer fest an den Hersteller. Man fällt in die alte Abhängigkeit von "proprietary systems" zurück.

Den heute verfügbaren OODBMS fehlt der Komfort einer nicht-prozeduralen Sprache, die es erlaubt, jedes Datum ohne Kenntnis eines Zugriffspfades auszuwählen.

- Robuste OO-DBMS mit effizienter Transaktionsverarbeitung sucht man im Markt heute noch vergeblich, ebenso verteilte OO-DBMS mit Two-Phase-Commit.

- Die benutzerfreundlichen Entwicklungswerkzeuge relationaler DBMS fehlen fast völlig. Nur zögernd erscheinen Konturen von einem CASE für OOP, aber es gibt noch kein CASE für OO-DBMS. RDBMS-Benutzer äußern sich enttäuscht über das Angebot an OO-DBMS-Tools: "Man sieht sich zurückversetzt in alte Zeiten, in denen Compiler-Sprachen die einzigen Werkzeuge waren."

- Ein entscheidender Grundsatz für die Einführung der Datenbanktechniken in den 60er Jahren war die Trennung von Daten und Prozeduren. Die heutigen Techniken der OO-DBMS verstoßen gegen diesen Grundsatz, weil Daten durch prozedurale Sprachen definiert und manipuliert werden. Es fehlt eine Data Definition Language (DDL) und eine Data Manipulation Language (DML). Dadurch disqualifizieren sich die heutigen OO-DBMS auch für die Wissensverarbeitung, denn die Computerbenutzer fordern deklarative Wissensdarstellungen, also Wissen, das für jede beliebige Anwendung zu gebrauchen ist.

Die Entscheidung der Oracle Corp., die Grenzen des RDM in einem evolutionären Prozeß zu überschreiten, trifft die Bedürfnisse der DBMS-Benutzer. Diese erwarten zwar eine Erweiterung der Ausdruckskraft, sind aber im allgemeinen nicht bereit, dafür die genannten Schwächen in Kauf zu nehmen.

Eine neue Generation relationaler Systeme

Die Weichen wurden für eine Erweiterung der Ausdrucksmöglichkeiten bereits mit Oracle, Version 6, gestellt. Nach heftigen Geburtswehen bei der Definition des Sprachumfanges brachte Oracle ein Novum auf den Markt: die "Programm Language/SQL" (PL/SQL), eine prozedurale Erweiterung von SQL. Zwar gab es stets Programmschnittstellen zu den Compiler Sprachen, aber keine dieser Schnittstellen oder Precompiler genügte der Forderung nach höchster Effizienz in der Transaktionsverarbeitung. Für die Realisierung einer großen Zahl von Schreibprozessen pro Sekunde die gleichzeitige Sicherung von Daten war das "Embedded SQL" in den Compilersprachen zu langsam. Die Lösung des Problems lag in der Minimalisierung der Plattenzugriffe durch eine Bündelung von SQL-Kommandos in "Paketen". Solche Pakete ließen sich aber nur dann effizient verarbeiten, wenn man die prozedurale Sprache in der Nähe des Datenbank-Kernels einbettete. Man stand vor der Aufgabe, eine prozedurale Sprache mit dem nicht-prozeduralen SQL zu verheiraten.

Trotzdem ist Ada ebensowenig eine objektorientierte Sprache wie C, Cobol oder Pascal. Aber diese Sprachen waren und sind die Grundlagen für objektorientierte Sprachen wie C + +, Cobol oder Object Pascal. Abgesehen davon, daß Ada die standardisierte Sprache des weltgrößten Auftraggebers ist, nämlich des Department of Defense in Washington/DC, gibt es bereits objektorientierte Sprachen auf der Basis von Ada, wie zum Beispiel Dragoon, der Ableger eines Esprit-Projektes. Dragoon implementiert wesentliche Merkmale der eleganten objektorientierten Sprache, "Eiffel".

Die Entscheidung, PL/SQL auf der Basis von Ada zu entwickeln, ersparte der Oracle Corp. den Aufwand, eine Basissprache für "Pakete" zu erarbeiten.

Derartige Pakete aus Daten, Funktionen und Prozeduren werden für die Einkapselung in objektorientierten Darstellungen benötigt.

Die Existenz von PL/SQL und die Möglichkeit, Kommandoprozeduren in PL/SQL abzuspeichern und aufzurufen, geben Oracle einen wettbewerblichen Vorteil, der weit über die Entwicklung von OO-DBMS hinausgeht. Die Einkapselung von Daten, Funktionen, Relationen und Prozeduren in ausgetestete Kommandoprozeduren, die nur minimale Plattenzugriffe erfordern, erlaubt auch die Definition von benutzerdefinierten Datentypen, konzeptionellen Strukturen, Wissensdarstellungen und Interferenzmechanismen. Hier wird das Fundament zu einer neuen Generation von relationalen DBMS gelegt: zu relationalen wissensbasierten - Systemen (Relational Knowledge Based Management Systems). Mit der Integration von KI-Methoden in die Datenbank-Technologie wäre endlich der Durchbruch für die dringend notwendige Entwicklung von intelligenten Systemen gekommen.

So wie die Dinge heute liegen, stehen die Chancen für Larry Ellisons Absichten also gar nicht so schlecht.

*Hans J. Drucks ist Mitarbeiter der Logos Gesellschaft für Wissensbasierte Systeme in Österreich.