OO-DBMS werden meist als Datenbanksysteme der nächsten Generation gehandelt, und in gewisser Weise sind sie das auch, denn ihre Entwicklung erfolgte nachweislich später als die von relationalen, hierarchischen und Codasyl-Systemen, nämlich in den 80er Jahren. Falls damit aber gesagt sein soll, daß OO-DBMS alle älteren Produkte ablösen werden - und dieses Gefühl vermitteln manche Auguren -, dann meldet Michael Peltzer* im folgenden erhebliche Bedenken an.
Relationale Datenbank-Management-Systeme (RDBMS) passen für die meisten kommerziellen Anwendungen sehr gut. Mit der deklarativen Abfragesprache SQL lassen sich die in der Applikation benötigten Sätze flexibel aus den anwendungsunabhängig in normalisierten Relationen (Tabellen) gespeicherten Daten zusammenkomponieren. Markige OO-Werbesprüche wie "Die Welt ist nicht so flach wie Tabellen" bringen RDBMS auch keineswegs in Mißkredit - jedenfalls nicht bei Fachleuten. Solange sich die Entitäten und Beziehungen eines Datenmodells effektiv Tabellen und deren Schlüsselabhängigkeiten darstellen lassen, ist die relationale Welt noch in Ordnung. Und das ist der Fall bei nahezu alle heutige Applikationen im kommerziellen Umfeld.
Anderes sieht es allerdings aus, wenn man Anwendungen betrachtet, die zur Unterstützung der kreativen Tätigkeiten des Entwerfens konzipiert sind, etwa in CAD- oder CASE-Bereich. Hier gibt es in der Tat Anforderungen, denen RDBMS nicht gerecht werden, da komplexe Datenstrukturen nicht mit guter Performance zu bearbeiten sind. Bislang behalf man sich damit, ganz auf DBMS und deren Vorteile wie die Einhaltung der Datenintegrität bei gleichzeitigem Zugriff zu verzichten, indem man applikationseigene Dateisysteme schrieb. OO-DBMS sollen genau an diesem Punkt helfen. Sie stellen also vom Ausgangspunkt her weniger eine Konkurrenz zu RDBMS für kommerzielle Systeme dar als vielmehr deren Ergänzung gemäß den Bedürfnissen spezieller Applikationen: CAD, CASE, Büroautomatisierung etc. Natürlich lassen sich diese Bereiche von den Einsatzgebieten betrieblicher Informationssysteme im wirklichen Leben nicht völlig trennen - bei Office-Applikationen liegt das auf der Hand. OO-DBMS sollten also jedenfalls verträglich mit RDBMS sein!
Zur Zeit kann man von einem OO-DBMS-Modell eigentlich gar nicht sprechen. Es gibt nämlich eine ganze Reihe davon.
Anders als RDBMS basieren OO-DBMS nicht auf einem theoretischen Konzept wie dem relationalen Modell, das versucht, größtmögliche Datenunabhängigkeit und eine flexible, formal optimierbare Abfragesprache zu schaffen. Sie gründen vielmehr auf Überlegungen, wie man den spezifischen Anforderungen spezieller Applikationsklassen gerecht werden kann - und da gibt es eben verschiedene Alternativen.
Zwei Architekturtypen stehen sich gegenüber
Zwei Ansätze hinsichtlich der Architekturen sind von Bedeutung. Bei Systemen wie Ontos, Object Store, Gem Store oder Orion handelt es sich um objektorientierte DB-Programmiersprachen. In diesem Fall wird eine Programmiersprache, meist C++, so erweitert, daß sie DB-Funktionalität bietet, das heißt Präprozessor, Compiler und die Laufzeitumgebung werden entsprechend ergänzt. Die ganze Anwendung läßt sich nun in derselben Sprache schreiben und auch in derselben Umgebung ausführen. Hierin liegen Vorteile: Zum einen braucht der Entwickler nicht die Sprache zu wechseln. Zum anderen, und das ist entscheidend, entscheidend, entfallen die Mängel von deklarativen Abfragesprachen wie SQL, da die in imperativen Sprachen üblichen logischen Konstrukte durchgängig zur Verfügung stehen. Außerdem erübrigen sich alle Aufwendungen für die Interprozeß-Kommunikation zwischen Anwendung und DBMS, da beide im selben Prozeß ablaufen.
Dem stehen Systeme wie Postgres von der University of California in Berkeley oder Starburst (IBM, Almalden) gegenüber, die auf Erweiterung des relationalen Ansatzes basieren. Hier wird SQL um imperative Konstrukte (zum Beispiel DO WHILE) erweitert, und es werden objektorientierte Leistungsmerkmale wie Vererbung und die Möglichkeit zur Definition komplexer Attribute zusätzlich implementiert. Der entscheidende Vorteil dieses Ansatzes liegt darin, daß eine gewisse Kompatibilität zu RDBMS herstellbar und auf diese Weise auch eine eventuelle Migration von R nach OO leichter möglich ist.
Man kann annehmen, daß sich die OODB-Sprachen wegen ihrer höheren Performance im technisch-wissenschaftlichen Umfeld durchsetzen, die erweiterten RDBMS dagegen aufgrund ihrer besseren Verträglichkeit mit gewöhnlichen relationalen Systemen im kommerziellen Bereich reüssieren werden.
Worin bestehen nun die Bedürfnisse von Design-Applikationen, denen RDBMS nur schlecht genügen können?
Zunächst muß man Objekte eindeutig identifizieren können. Das geschieht normalerweise durch Schlüsselattribut-Werte. Diese Methode hat den Haken, daß eine Veränderung der Attribute, die als Schlüssel dienen, nicht möglich ist, ohne die Identität
des Objekts aufzuheben. Hier muß man sich in RDBMS mit der Kreierung eines künstlichen Schlüssels helfen, der keine sachliche Beschreibung beinhaltet und den der Benutzer pflegen muß. Beim Design eines Schaltkreises oder auch beim. Entwurf von Softwaremodulen tritt dieser Fall, daß es keinen sinnvollen echten Schlüssel gibt, häufig ein. Ein OO-DBMS nun generiert automatisch einen Identifier, den dann auch das System selbst pflegt, was den Aufwand und die Fehlermöglichkeit reduziert.
Die DB-Objekte eines RDBMS sind Tables und Views, virtuelle Tabellen. Sie entsprechen per definitionem der ersten Normalform, das heißt, es existieren keine Wiederholungsgruppen. Jedes Attribut besitzt also zu jedem Schlüsselwert genau eine Eintragung. Dies ist in vielen Fällen unpraktisch. Denkt man an CAD, ergeben sich beispielsweise Vorteile, wenn man geordnete Mengen oder Listen als Attribute zuläßt. So besteht ein Schaltkreis aus verschiedenen Widerständen und Transistoren mit einer bestimmten Anzahl unterschiedlicher Aus- und Eingänge.
Bildung von Einheiten ermöglicht Clusterung
Betrachten wir nun ein Dokument. Es besteht aus verschiedenen Komponenten, etwa der Inhaltsangabe, Kapiteln, einem Index und einer Menge von Suchbegriffen. Nun gibt es Operationen wie das Kopieren, die das ganze Dokument betreffen. Es wäre also sinnvoll, wenn das DBMS in der Lage wäre, Dokument X dementsprechend als Ganzes aufzufassen. Diese Einheitenbildung dient dann auch zur Clusterung beim Schreiben auf Sekundärspeicher, um die Zugriffszeit zu verkürzen. Die Kapitel als Komponenten des Dokuments sind selbst wieder Objekte mit Attributen wie Autor, Erstellungsdatum, Unterkapitel (Liste) etc. Die zu den einzelnen Unterkapiteln gehörigen Texte endlich sind mit gewöhnlichen Datentypen nur unzureichend zu erfassen. Ein Text hat nicht den Typ Varchar, dem er im RDBMS zugeordnet wird. Denn auf diese Weise wird er als strukturlose Einheit behandelt, die er zum Beispiel für einen Editor nicht ist. Die Texte selbst enthalten vielleicht Grafiken oder Bilder, die noch eine gesonderte Behandlung brauchen, da sie extrem große Datenblöcke vertreten (Binary Large Objects).
In relationalen Systemen werden Beziehungen über Fremdschlüssel dargestellt. Auf diese Weise ist die Referenz an bestimmte Werte zu gewählten Attributen gekettet. In OO-Systemen hingegen kann man die Beziehungen explizit angeben, so daß sie auch
bei Änderung der Attributwerte erhalten bleiben. Sie sind mit vom System gepflegten Pointern vergleichbar. Definieren läßt sich etwa die Liste der zu einem Objekt Applikation X gehörigen Code-Module und bei den einzelnen Modulen umgekehrt die Gruppe der
Programmsysteme, zu denen sie gehören.
Prozeduren mit OO-DB-Objekten assoziieren
Bislang ging es um Objekte als Datenstrukturen. Im Sinne objektorientierter Programmierung bildet eine Klasse von Objekten aber einen abstrakten Datentyp, das heißt eine Menge von gleichartig strukturierten Daten und definierten Operationen. Einkapselung bedeutet, daß auf die Daten ausschließlich über die fixierten Operationen (auch Methoden genannt) zuzugreifen ist, also nicht direkt. Für OO-DBs heißt das, daß sie zum einen die Möglichkeit bieten müssen, Prozeduren mit den DB-Objekten zu assoziieren. Zum anderen stellen diese Prozeduren die einzige Schnittstelle für Applikationsprogramme dar. Dieses umfassende Konzept eines Behaviorally-object-oriented-systems, ist allerdings in den meisten käuflichen Produkten nicht verwirklicht, obwohl es sich um eine Idee handelt, mit der die in RDBMS erreichte Unabhängigkeit von Daten und Anwendungen (Data Independence) noch zu verbessern wäre.
Prozeduren lassen sich allerdings nicht nur in dem strikten Sinn der Einkapselung mit Datenstrukturen verbinden. Sie können auch dazu dienen, komplizierte sachliche Abhängigkeiten der Zustände verschiedener Objekte in der Datenbank statt in der Applikation zu definieren. Damit sind sie zum einen nicht umgehbar und gleichzeitig, wiederverwendbar. Man könnte zum Beispiel in einer CASE-DB automatisch prüfen, ob die Datenstrukturen einer Komponente kompatibel mit der Systemkonfiguration sind, als deren Teilobjekt sie gedacht sind. Derartige Prozeduren können zum Beispiel auch durch Wertveränderungen ausgelöst werden (Trigger). Dieser Fall ist für kommerzielle RDBMS von großem Interesse, und manche Produzenten haben so etwas bereits eingebaut (Ingres, Sybase). Wer wollte bestreiten, daß es sinnvoll ist, wenn die Routine, die den Versand eines Mahnschreibens in Abhängigkeit von Bestellung, Datum und Kontostand veranlaßt, gleich in der Datenbank implementiert wird. Von entscheidender Bedeutung sind solche Trigger auch bei der Prozeßsteuerung, wo sie die Komplexität der Anwendung reduzieren helfen.
Konzept der Vererbung wirkt vielversprechend
Die Vererbung ist ein besonders vielversprechendes Konzept der objektorientierten Programmierung. Mit ihr wird Wiederverwendung gleichsam strukturell eingebaut. Es geht darum, daß man Nachkommensklassen einer bereits bestehenden Klasse definieren kann und die Nachkommen die Datenstruktur und Methodendefinition des Vorfahren erben.
Für DBMS läßt sich dieser Mechanismus der Generalisierung in einer Typ-Hierarchie in verschiedener Weise nützlich machen. Benötigt man in einer Anwendung Subtypen, so kann man diese als Nachkommen definieren. Beispielsweise ist der Objekttyp Programm auf diese Weise nach den respektiven Programmiersprachen differenzierbar. Man kann auch eine Spezialisierung, eine Erweiterung der Attribute vornehmen. Dies ist zum Beispiel der Fall, wenn Quellprogramm als Subtyp von Dokument durch das Attribut Programmiersprache zusätzlich spezifiziert wird.
Wichtig ist hierbei die Möglichkeit, ererbte Merkmale zu überschreiben. Damit kann man das Konzept der Polymorphie aus der OO-Programmierung übernehmen. Beispielsweise können Text und Grafik als Nachkommen von Dokument verschiedene Implementierungen für die geerbte Prozedur Anzeigen erhalten.
Betrachten wir ein Software Repository. Zur Pflege der Anwendungssysteme ist es wichtig, präzise zu wissen, welche Versionen welcher Komponenten in den verschiedenen Lokationen des Unternehmens in den installierten Releases eingebaut sind. Ein Sortier-Modul zum Beispiel mag in 13 Versionen in den unterschiedlichsten Systemkonfigurationen aktuell in Betrieb sein. Diese Problemlage tritt bei der Entwicklung und Produktion eines Chips oder von Autos ganz genauso auf, und OO-DBMS sollten deshalb, in der Lage sein, Versionen von Objekten und Konfigurationen automatisch zu verwalten. Eine Konfiguration ist dabei nichts anderes als eine Version eines aus mehreren anderen Objekten zusammengesetzten Objekts.
Bei kommerziellen Systemen gibt es übrigens ähnliche Anforderungen die zur Zeit nur durch zusätzlichen Anwendungscode zu befriedigen sind. So müssen Versicherer etwa eine Historie ihrer Vertragsdatenbestände pflegen.
SQL heißt der große Schlager bei RDBMS, und das nicht ohne Grund. SQL ist deklarativ das heißt, man gibt im Statement an, welche Anforderungen an welche Daten man hat und nicht, wie das System auf diese zugreifen soll. SQL beruht auf der relationalen Algebra, also der Basis für die Konstruktion der Algorithmen des Optimizers, und damit der DBMS-Komponente, die die Auswahl des Zugriffspfades besorgt. SQL ist standardisiert. Damit ist zwar nicht gesagt, daß die respektiven Herstellerdialekte identisch sind, aber sie stimmen immerhin mit dem von der ANSI abgesteckten Rahmen überein. Ferner sind Kenntnisse über SQL weit verbreitet.
Es spricht also einiges dafür, SQL zu erweitern, statt es zu verwerfen. Vom OO-Standpunkt aus fehlen zum Beispiel Konstrukte für komplexe Attribute und zusammengesetzte Objekte. Außerdem ist es hinderlich, daß SQL keine vollständige Programmiersprache ist, so mangelt es an logischen Ausdrücken und Variablen. Deren Einbau
erschwert allerdings den Optimierungsprozeß, da es nicht mehr ausreicht, auf die relationale Algebra zurückzugreifen.
Den Weg der "Extended Relational Architecture" gehen zum Beispiel Ingres und IBM. Andererseits ist das Prinzip der Einkapselung letztlich unverträglich mit SQL, und in manchen OO-DBMS muß der Programmierer den Weg durch Typ-Hierachien und Aggregationen selbst festlegen. Auch für diesen scheinbaren Rückfall spricht ein sehr starkes Argument, nämlich die Performance.
Programmsteuerung spart langwierige Operationen
Die Separierung von Anwendung und DBMS in verschiedenen Laufzeitumgebungen und die Automatisierung des Zugriffs durch den Optimizer kosten Zeit. Will man komplexe Objekte in einer relationalen Datenbank abbilden, so sind die
Informationen unter Umständen in sehr vielen Tabellen abgelegt. Die beim Zugriff nötigen JOIN-Operationen kosten viel Aufwand. Es ist aber nicht bloß lästig, sondern es verhindert mehr oder weniger die Arbeit zum Beispiel mit einem CAD-Tool, wenn man bei Speicherung beziehungsweise Zugriff ein oder vier Minuten abwarten muß, bis das System mit solch simplen Arbeitsschritten zu Rande kommt.
Um Zeit zu sparen, erfolgt in manchen OO-DBMS der Zugriff programmgesteuert - nicht weil die Konstrukteure noch nichts von einem Optimizer gehört hätten. In den OO-DB-Programmiersprachen entfallen überdies die Transformationskosten zwischen Sprach- und DBMS-Umgebung. Unabhängig davon liegen aber im OO-Konzept selbst noch Möglichkeiten der Beschleunigung des Zugriffs, und zwar insofern als dem System mehr Informationen für die Clusterung, das heißt die Bildung von Blocks beim Schreiben auf Magnetplatte, zur Verfügung stehen, nämlich Typ-Hierachien und Aggregationen (zusammengesetzte Objekte). Ein anderer wichtiger Faktor der Performance sind durch Sperrungen verursachte Wartezeiten (Locking).
Bei kommerziellen Online-Transaktions- Anwendungen ist es sinnvoll, daß das DBMS den gleichzeitigen Zugriff möglichst feinkörnig kontrollieren kann. Das Ideal besteht darin, möglichst nur diejenigen Felder oder jedenfalls Sätze, das heißt im RDBMS Zeilen, zu sperren, die in der Transaktion angesprochen sind. Auf diese Weise können viele Transaktionen sogar auf dieselbe Tabelle gleichzeitig zugreifen, und auch die Anzahl möglicher Deadlock-Situationen sinkt. Dieses Low-Level-Locking generiert allerdings einen hohen Verwaltungsaufwand für das System.
Außerdem sind zu ändernde Sätze auch für Lesezugriffe gesperrt. Sonst könnte ein Anwender ja bereits falsche Werte als aktuelle vorgespiegelt bekommen. Das alles macht bei kurzlaufenden Transaktionen wie Kontenkorrekturen viel Sinn, nicht aber bei Design-Applikationen. Bei diesen werden große (Teil-)Objekte in längeren Phasen bearbeitet, und man kann mit nur wenigen konkurrierenden Zugriffen auf Feldniveau rechnen. Die Entwicklung von Datenmodellen oder die Konstruktion zum Beispiel von Karosserieteilen sind Beispiele. Gewöhnliche Concurrency Control würde beständig große Teile der Daten sperren. In OO-DBs ermöglichen es Techniken wie Versionen, sogenannte optimistische Sperrmethoden und langlaufende Transaktionen, Datenintegrität bei gleichzeitiger Bearbeitung zu gewährleisten.
OO-BMS werden als Produkte angeboten, und zwar im allgemeinen von kleinen Firmen, die auf einen Nischenmarkt zielen. Ob sie überleben, wenn die Software-Riesen dieses Marktsegment für sich entdecken, ist unklar. Aber es ist ausschlaggebend für die Wahl eines OO-DBMS, denn es gibt zur Zeit keinerlei Standards. Das bedeutet, daß mit dem Hersteller des DBMS auch die Investition in die eigenen Anwendungen mehr oder weniger verlorengehen würde.
Auf der anderen Seite ist es unsinnig, auf das Standard-OO-DBMS zu warten, und zwar nicht nur deshalb, weil die Technologie sich beständig fortentwickelt und Probleme wie die Beziehung von Programmier- und Abfragesprache, die Optimierung, der physischen Speicherung, die Bereitstellung von Anwendungsentwicklungs-Tools und die Gestaltung der verteilten Verarbeitung erst noch zu lösen sind.
Alle Anforderungen lassen sich nie erfüllen
Das allen Anforderungen entsprechende OO-DBMS wird es nie als Produkt, sondern nur als Ideal geben. Der Grund liegt in den verschiedenen und sich teilweise widersprechenden Anforderungen der Anwendungstypen, die die Entwicklung von OO-DBMS motiviert haben. So behindern sich zum Beispiel die Techniken zur Realisierung der für die einen Anwendungen notwendigen Datensicherheit und die zur Verwirklichung der bei anderen geforderten Zugriffsgeschwindigkeit wechselseitig.
Bei der langfristigen Planung in Unternehmen, die ihren Datenbestand möglichst flexibel benutzen wollen, ist es jedenfalls meist sinnvoll, auf die erweiterte relationale Architektur mit "OO-SQL" zu setzen. Reine OO-Systeme werden in diesem Umfeld Inseln bleiben. Das spricht nicht prinzipiell gegen sie, aber man sollte es wissen - schon um die Kosten für den eventuellen Brückenbau in Rechnung stellen zu können. +
Die Lage ist verwickelt
Daß der Ausdruck Objektorientierung nicht bloß ein modisches Etikett darstellt, sondern einen ernstzunehmenden Trend der Informationsverarbeitung bezeichnet, wird mittlerweile von keinem zurechnungsfähigen Vertreter der Zunft mehr bezweifelt. Umstritten ist aber die Reichweite des neuen Ansatzes. In der CW Nr. 42 vom 16. Oktober l992, S. 13 meinte Rene Purwin lapidar: "Die Zukunft heißt Objektorientierung" - auch bei Datenbanken. Michael Peltzer, Autor des nebenstehenden Artikels, hält die Lage
für verwickelter. Er behauptet, daß OODBs auf die Anforderungen einer speziellen Klasse von Anwendungen ausgerichtet sind. Es gehe um die Computerunterstützung der kreativen Tätigkeit des Entwerfens.