Je stärker die Integration von Office-Anwendungen in den Mittelpunkt rückt, desto lebhafter gestaltet sich die Diskussion um "Objektorientierte Datenbanken". Denn immerhin setzen sich die typischen Büro-Dokumente zu 95 Prozent aus unformatierten Daten wie Text, Grafik, Sprache und Bild zusammen. Dr. Raymond Vorwerk* erklärt, warum dennoch Objektorientierte DBs kein Ersatz, sondern eine sinnvolle Ergänzung für Relationale Datenbanken sind.

Es ist eine natürliche Konsequenz der bisherigen Diskussion über Objektorientierung, nicht nur die theoretischen Eigenschaften von Objekten und ihrer Programmierung zu betrachten, sondern auch einen Blick auf gesamte Umfeld zu werfen, um den Nutzen oder gar die Notwendigkeit solcher "OODBMS" ins rechte Licht zu rücken.

Bislang sind zur Objektorientierung nur zwei Komponenten in der Diskussion. Dieses sind auf der einen Seite objektorientierte Programmiersprachen, wie zum Beispiel Smalltalk, C + + etc. Die Anwendung dieser Programmiersprachen läßt eine erhebliche Steigerung der Produktivität und Qualität neuer Softwareprodukte erwarten. Eine Betrachtung des Marktes zeigt, daß bis zum Jahresende zirka 300 000 Implementierungen dieser Sprachen vorgenommen worden sind.

Drei klassische Komponenten der Software

Zum anderen ist die Arbeit mit grafischen Benutzeroberflächen seit langem state-of-the-art. Grafische Benutzeroberflächen sind von sich aus objektorientiert, obwohl die meisten Anwender von Windows oder Presentation Manager dieses nicht direkt zu spüren bekommen. Die weite Verbreitung dieser Benutzeroberflächen zeigen die Verkaufszahlen von Windows und Presentation Manager, die bis zum Jahresende zirka sieben Millionen Installationen erreicht haben werden. Als natürliche Ergänzung dieser beiden Komponenten fehlen nur die Object Database Management Systems, kurz die Objektorientierten Datenbanken. Mit der Verfügbarkeit von Objektorientierten Datenbanken wären die klassischen drei Komponenten der Software, nämlich Benutzeroberfläche, Programmiersprache und Datenspeicherung, komplett.

Ein Manko objektorientierter Sprachen ist heute noch, daß sie zwar Objekte erzeugen, manipulieren und vernichten, diese jedoch nicht speichern können. Das bedeutet, daß die Lebensdauer eines Objektes in einer objektorientierten Sprache im Regelfall auf die Verarbeitungszeit begrenzt ist. Diese Objekte haben also einen transienten Charakter. Da es wenig Sinn macht, jedesmal bei Beginn einer Verarbeitung alle Objekte neu zu erzeugen und sämtliche Verarbeitungsschritte erneut durchzuführen, besteht die Notwendigkeit, Objekte persistent zu machen, das heißt, sie in einer Datenbank zu speichern. Darüber hinaus ist es sicherlich ebenso sinnvoll, Objekte auch zwischen anderen Systemen auszutauschen und zu verteilen. Die Aufgabe von Objektorientierten Datenbanken ist es deshalb, die in einer Objektorientierten Programmiersprache erzeugten Objekte zu speichern und damit persistent zu machen.

Die heutige Arbeitsweise in einem administrativen Bereich (Schlagwort "Re-Taylorisierung") zielt verstärkt in Richtung der Unterstützung von Workgroups.

Die Anforderungen an Workgroups sind leicht zu definieren: Zum einen ist es notwendig, verteilte Datenbanken in einem LAN oder auch WAN bereitzustellen. Das bedeutet, daß nicht nur Suchverfahren über diese verteilten Datenbanken notwendig sind, sondern auch bestimmte Arten des Versions- und Konfigurationsmanagements. Die bisherigen Verfahren der Zugriffskontrolle scheinen nicht mehr plausibel, sobald die Teilnehmer einer Workgroup an denselben Objekten und Dokumenten arbeiten. Zum zweiten bedeutet die Unterstützung von zum Beispiel administrativen Verfahren die Verarbeitung nicht strukturierter oder strukturierbarer Daten wie zum Beispiel Text, Grafik und Bildern - aus denen heute mehr als 95 Prozent aller Dokumente bestehen.

Die bisherigen traditionellen (sequentiellen) Speicherverfahren oder auch relationale Datenbank-Management-Systeme können die oben postulierten Notwendigkeiten nicht erfüllen: Die traditionelle Speicherung in Form von Files erlaubt zwar eine persistente Datenhaltung, jedoch keine Verkapselung. Eine der Eigenschaften eines Objektes ist die Verkapselung, das heißt, der Benutzer eines Objektes sieht nicht die interne Datenstruktur wie die Implementation des Objektes, kann sie jedoch über Methoden verwenden. Bei der Speicherung in Form von Files sieht jedes Programm die vollständige Datenstruktur. Darüber hinaus zieht jegliche Veränderung in dieser Struktur Veränderungen aller Programme nach sich, die diese Daten verwenden.

Dadurch, daß mehrere Mitarbeiter einer Workgroup auf diese Files zugreifen, existieren im Regelfall viele physische Kopien für logisch identische Vorgänge. Traditionelle Speicherungsverfahren besitzen jedoch zumeist keine Unterstützung für irgendeine Art der Versions- und Konfigurationskontrolle. Was also spricht gegen die Verwendung von relationalen Datenbanksystemen zur Speicherung von Objekten? Zunächst einmal muß festgestellt werden, daß Relationale Datenbank-Management-Systeme ursprünglich für andere Aufgaben entwickelt wurden, als für die Unterstützung von Workgroups und zur Verarbeitung sogenannter integrierter Office-Anwendungen.

Dokumente, wie sie zum Beispiel das compound document im Bereich von Büro-Architekturen darstellt, beinhalten üblicherweise gerichtete azyklische Netzwerkstrukturen.

Diese Art der Strukturen können relationale Datenbanken nicht abbilden. Dieses liegt darin, daß es keine Unterscheidungen im Relationenmodell zwischen der externen Schnittstelle zu einem "object-type" und der internen Darstellung eines Objektes gibt. Relationale Datenbanken kennen nur die Darstellung "tuple" = record". Für formatierten Text, Grafiken etc. ist dieses keine geeignete Darstellungsform.

Es gibt die Möglichkeiten, Binary large objects zu verwenden. Dieses scheint eine Lösung zur Speicherung von Objekten zu sein, macht jedoch nur dann Sinn, wenn es sich um große Objekte wie zum Beispiel Bitmaps handelt. Bei kleinstrukturierten Objekten kommt hier jedes relationale Datenbanksystem an die Grenzen seiner Leistungsfähigkeit. Darüber hinaus bedeutet die Verwendung von "blobs" die implizite Anwendung der traditionellen, sequentiellen Speicherung.

Ein weiterer Grund gegen die Verwendung von relationalen Datenbanksystemen ist die Performance. Relationale Datenbanken sind dazu da, eine große Anzahl von "records" mit einer speziellen Fragestellung (query) zu durchsuchen. Komplexe Anwendungen, wie etwa Office-Anwendungen benötigen eine derartige Verarbeitung nur selten. Im Regelfall traversieren sie in einem komplexen Netzwerk von Strukturen wie zum Beispiel Dokumenten und Bildern. Um dort von einem Knoten zum nächsten zu gelangen, kann es nicht sinnvoll sein, jedesmal eine SQL-Abfrage zu erzeugen.

Die bislang bekannte Client-Server-Architektur einer relationalen Datenbank steht im Widerspruch zu den Anforderungen heutiger komplexer Anwendungen. Die Traversierung derartiger netzwerkähnlicher Strukturen geschieht nicht auf dem Server, sondern die notwendigen Datenstrukturen werden auf den Client verlegt und die gesamte Traversierung geschieht dann dort. Dieses widerspricht nahezu vollständig der heutigen Verwendung von relationalen Datenbanken.

Abgesehen von den Einsatz zielen spielt das Thema Zugriffskontrolle eine wichtige Rolle:

Relationale Datenbanken halten kurze Transaktionen (< = 1 sec) für eine Vielzahl von Benutzern mit einer einfachen "restart"-Möglichkeit. Transaktionen in einer objektorientierten Datenbank sind jedoch sehr lang. Man stelle sich zum Beispiel einen Konstrukteur vor, der wochenlang an einem einzelnen Objekt arbeitet. Das gleiche gilt für mehrere Teilnehmer an einer "working group", die über längere Zeit am selben Dokument arbeitet, bevor gegebenenfalls eine notwendige Integration beginnen kann. Relationale Datenbanken sind also sinnvoll und notwendig bei der Verarbeitung von Massendaten, sind jedoch nicht unbedingt geeignet zur Speicherung von Objekten.

Wichtig für die Funktionalität einer objektorientierten Datenbank sind die folgenden Punkte:

- Physische Speicherung und Zugriffsmechanismus:

Vom Grundsatz her verwenden objektorientierte Datenbanken die gleichen Speichermechanismen wie jede andere Datenbank auch, das heißt lineare Dateien auf einem externen Medium. Üblicherweise besteht eine einzelne objektorientierte Datenbank aus zwei Dateien, nämlich einer Index-Datei (über welche die Object-IDs verwaltet werden und die Zeiger für die physische Position des Objektes enthalten sind). Auf der anderen Seite gibt es eine zweite Datei, in der das Objekt selber gespeichert wird. Die Datenstruktur dort besteht aus einem Header, mit den strukturbeschreibenden Informationen zu einem Objekt sowie dem "linearisierten" Objekt.

Grundlage für die Speicherung eines jeden Objektes ist ein Linearisierungs-/Delinearisierungs-Mechanismus. Ein externer Speicher ist immer ein linearer Speicher. Ein Objekt besteht jedoch im Regelfall aus einer azyklisch gerichteten Netzwerkstruktur. Die Aufgabe des Linearisierungs-/Delinearisierungs-Algorithmus ist es, die Objektstruktur im Speicher eines Programmes in eine lineare Form zu bringen, damit sie entsprechend gespeichert werden kann. Beim Laden eines Objektes ist der umgekehrte Vorgang notwendig (Abb. 2).

Die Effizienz einer objektorientierten Datenbank hängt im wesentlichen von der Güte dieses Algorithmus ab.

- Object-Cache:

Alle objekte, die von einer objektorientierten Datenbank verwaltet werden, werden in einem Object-Cache gehalten. Dieses Object-Cache verwaltet sämtliche Zustands-Informationen für ein Objekt. Dazu gehören nicht nur die Object-ID und der Hinweis auf Klasse und physischen Speicherungsort, sondern auch weitere Informationen wie Status, "lock-level", Besitzer etc. Darüber hinaus ist es notwendig, auch aktive Objekte in einer derartigen Datenbank speichern zu können, die andere Objekte darüber informieren, wenn sie selbst verändert worden sind (Abb 1).

- Zugriffsmechanismus:

Prinzipiell ist es möglich, die Multi-User-Fähigkeit einer objektorientierten Datenbank durch ein Time-stamp-Verfahren zu lösen. Time-stamp-Verfahren bedeutet, beim Schreiben des Objektes wird die auf dem Datenträger gespeicherte Time-stamp geprüft und entsprechend dem Ergebnis der Prüfung die Speicherung des Objektes versagt. In diesem Fall greift dann ein Versionsverwaltungs-Verfahren, das es erlaubt, von demselben Objekt mehrere Versionen zur gleichen Zeit zu verwalten. Dieses entspricht auch der Arbeit in einer Workgroup, bei der mehrere Mitarbeiter an demselben Dokument arbeiten und später eine Integration betreiben.

Alternativ zu dieser Art des Zugriffsmechanismus kann natürlich auch ein klassisches "Lock"-Verfahren implementiert werden, das auf verbesserten Implementierungen der "optimistic concurrency control" basiert.

Zur Ausführung sämtlicher Datenbankfunktionen sollte ein Datenbank-Interface vorhanden sein, das es erlaubt, nicht nur die Datenbank aus ihrer objektorientierten Implementierung heraus anzufragen, sondern auch auf der Basis zum Beispiel einer DDE-Schnittstelle aus anderen Anwendungen heraus. Ferner sollte das Datenbank-Interface es ermöglichen, auch von anderen Sprachen über API oder Croll-Schnittstellen die Datenbank zu erreichen.

Für Anfragesprachen sind Normierungsbemühungen zum Thema Object-SQL im Gespräch. Es handelt sich hierbei um eine Sprachverabredung über die klassischen SQL-Funktionen, nämlich "select", "insert", "update" und "delete". Die in einer objektorientierten Datenbank zu speichernden Strukturen müssen beliebig sein können. Dieses heißt, daß vom Grundsatz her die drei allgemeinen Verknüpfungsarten "is a", "is part of", "uses" unterstützt sein müssen. Hierdurch ist es möglich, beliebig komplexe Objekte aufzubauen und in der objektorientierten Datenbank zu speichern.

Anforderungen an die Objektorientierung:

- Eine objektorientierte Datenbank muß sämtliche Paradigmen der Objektorientierung unterstützen, insbesondere behalten Objekte ihre Identität, solange sie existieren, unabhängig von ihren Werten.

- Komplexe Objekte können beliebig aus anderen Objekten zusammengesetzt werden.

- Der interne Zustand eines Objektes ist nur durch die für seine Klasse definierten Methoden veränderbar, das heißt, die Verkapselung der Objektorientierung wird unterstützt.

- Objekte werden nach gemeinsamen Eigenschaften klasifiziert (Klassen oder Typen).

- Klassen können in einer Hierarchie angeordnet werden, wobei Teilklassen die Eigenschaften und Methoden der übergeordneten Klassen haben.

- Eine objektorientierte Datenbank sollte die Eigenschaften des overloading oder des late-binding unterstützen.

- Die Abfragesprache einer objektorientierten Datenbank sollte die Mächtigkeit einer Programmiersprache besitzen, bei SQL ist dieses nicht der Fall.

- Der Benutzer sollte in der Datenbank noch nicht enthaltene Typen und Methoden nach seinen eigenen Vorstellungen definieren können.

Anforderungen an die Datenspeicherung:

- Alle Datenobjekte werden persistent gehalten und gehen somit nach Beendigung eines Programms nicht verloren.

- Die Datenspeicherungsmethoden ermöglichen einen effizienten Zugriff auf Daten, die im Sekundärspeicher abgelegt sind.

- Das Datenbank-Management-System stellt die Konsistenz der Daten bei parallelem Zugriff mehrerer Benutzer auf die gleichen Daten sicher.

- Das Datenbanksystem muß in der Lage sein, nach einem Systemabsturz wieder einen konsistenten Zustand zu erreichen.

- Der Benutzer sollte in einfacher Weise Ad-hoc-Abfragen an die Datenbank stellen können.

Es gibt weitere Eigenschaften die im Rahmen einer objektorientierten Datenbank wünschenswert sind. Es handelt sich dabei um die Unterstützung von Mehrfachvererbung, von Typ-Überprüfung, von der Verteilung von Daten im Netz, von der Unterstützung langer Transaktionen sowie der Verwaltung von Versionen.

Zur Zeit sind mehr als zwölf Produkte auf dem Markt, die den größten Teil dieser Anforderungen erfüllen. Diese Produkte sind im wesentlichen Unix-basiert und unterstützen als Programmiersprache C + + und Smalltalk. Im Bereich des PCs ist dem Autor nur eine Datenbank bekannt, die Windows beziehungsweise OS/2 Presentation Manager unterstützt. Objektorientierte Datenbanken auf den klassischen Host-Systemen sind bei verschiedenen Herstellern in Entwicklung und werden mit Sicherheit innerhalb der nächsten zwei Jahre auf dem Markt verfügbar sein.

Objektorientierte Datenbanken sind eine sehr neue Technik, um beliebig komplexe, geschachtelte Strukturen abzuspeichern und wiederzufinden. Objektorientierte Datenbanken bilden dabei die dritte Komponente zu objektorientierten grafischen Benutzeroberflächen und objektorientierten Programmiersprachen. Sie stehen nicht im Gegensatz zu relationalen Datenbanksystemen, sondern ergänzen sie auf andere Weise.

Es scheint sicher zu sein, daß objektorientierte Datenbanken in naher Zukunft wesentlich für die Unterstützung von Workgroups zur Speicherung nicht strukturierter Dokumente sein werden.

*Dr. rer. nat. R. Vorwerk ist Geschäftsführer der VC Software Construction GmbH in Braunschweig.