In letzter Zeit sind objektorientierte Datenbank-Management-Systeme (OODBS) zunehmend als Alternativen zu relationalen Datenbanken ins Gespräch gekommen. Das gilt insbesondere für technische Anwendungen, bei denen herkömmliche Speichertechniken Probleme aufwerfen. Christoph Mathis* zeigt die Technologie der Objektorientierung von Datenbanken und ihre hauptsächlichen Einsatzgebiete auf.

Die Technologie der OODBMS überträgt die Prinzipien der objektorientierten Entwicklung auf die Datenbanktechnologie. Diese Datenbankprodukte erlauben es, dasselbe Grundprinzip durchgängig - ohne semantische Brüche - zu verwenden. Daraus ergeben sich Vorteile in der Konsistenz und Geschlossenheit der Software.

Bei geeigneten Anwendungen entstehen darüber hinaus dramatische Performancevorteile. Dann verbinden die OODBMS die Vorteile eines echten Datenbanksystems mit der Geschwindigkeit eines maßgeschneiderten Datei-Speichersystems.

Die Evolution der Technologie

In den vergangenen Jahren hat die Technologie der Datenspeicher eine Folge von Lösungen hervorgebracht: von der einfachen Speicherung in ISAM-Dateien über hierarchische Datenbankmodelle wie IMS und Codasyl-konforme Datenbanksysteme bis zu den relationalen Datenbanken. Von einer Datenbank-Technologie reden wir erst, seit gewisse Strukturen aus der eigentlichen Applikation ausgelagert wurden und damit Daten von mehreren Applikationen gemeinsam genutzt werden können.

Der Mangel an Unabhängigkeit von der konkreten Speicherstruktur und die aufwendigen Prozeduren zur Navigation in den Strukturen waren die Wurzeln für das Aufkommen der relationalen Datenbanken. Mit diesem Datenbanktyp können wir die Struktur der Datenbank deklarativ beschreiben, wodurch wir eine Abstraktion von der Speicherstruktur in der Applikation erreicht haben.

In den vergangenen 20 Jahren hat die DB-Technologie in den klassischen kommerziellen Anwendungsgebieten einen hohen Reife- und Verbreitungsgrad erreicht. Dagegen bereiten technische Anwendungen mit typischen komplizierten Strukturen und hohen Performance-Anforderungen in puncto Speichertechnik noch große Probleme. Die Datenstrukturen wollen einfach nicht auf vorgegebene Record-Strukturen der Datenbanken passen. Meist werden die Daten solcher Systeme daher noch in selbstentworfenen Dateistrukturen abgelegt.

Um die Begrenzungen der bisherigen Speichertechniken zu überwinden, ist ein reichhaltigeres Datenmodell erforderlich, als es die traditionellen Datenbanken bieten. Die Datenbanken müssen künftig über neue Eigenschaften verfügen.

Das relationale Datenmodell hat seine Vorzüge in der Einfachheit seiner Struktur. Das zugrundeliegende Mengenkalkül ist übersichtlich und eignet sich auch zur konzeptionellen Abbildung (und als Kommunikationsgrundlage) typischer Business-Strukturen. Die starke Unabhängigkeit der Programmstruktur von der Speicherung der Daten hat das relationale Modell attraktiv sowohl für Anwender als auch für Programmierer gemacht und seinen Siegeszug in der kommerziellen Datenverarbeitung begründet.

Gerade in dieser Einfachheit liegen aber die Grenzen des relationalen Datenmodells. In den Strukturen der Business-Anwendungen werden große Datenmengen mit einer relativ einfachen und regelmäßigen Struktur bearbeitet. Das relationale Modell ist hingegen zu simpel um komplexe, verschachtelte Datenstrukturen, wie sie zum Beispiel in Design und Engineering-Anwendungen vorkommen, adäquat darzustellen.

Der "User" des Datenbanksystems ist bei solchen Anwendungen typischerweise ein anderes Programmsystem, dessen Strukturen in der Datenbank verwaltet werden. Bei einem konventionellen DBMS kommt es daher zu einer "semantischen Lücke", wenn die komplizierten internen Datenstrukturen der Applikation auf die einfache und regelmäßige Record-Struktur der relationalen Datenbank abgebildet werden. Als Folge davon ist auch die Performance von relationalen DBMS bei komplizierteren Datenstrukturen meist nicht akzeptabel.

Weder Abstraktion noch Generalisierung

Konventionelle DBMS unter stützen nur einen begrenzte Satz von Datentypen. Diese Datentypen sind für Standardanwendungen zumeist aus reichend. Daß dieser Satz vom Datentypen nicht erweiterbar ist, bereitet aber dann Probleme, wenn zum Beispiel ein CAD-System Ecken, Oberflächen und Produkteigenschaften sowie deren Zusammenhänge verwaltet.

Konzepte wie Generalisierung und Abstraktion lassen sich in konventionellen Datenbanksystemen einfach nicht abbilden. Das führt zu einem hohen Maß von redundanten Datenstrukturen, die der Anwendungsprogrammierer selbst verwalten muß.

Anwendungen sind in prozeduralen Sprachen geschrieben, Datenbankzugriffe auf ein relationales DBMS hingegen in einem Mengenkalkül. Daraus ergibt sich ein Konflikt der Strukturen bei der Umsetzung von einer Darstellung in die andere. Die Folgen sind: Komplexität der Schnittstellen, Performanceverluste, mangelnde konzeptionelle Klarheit und Geschlossenheit des Gesamtsystems.

Eine neue Richtung zeichnet sich ab

Diese Grenzen der konventionellen Datenbanktechnologie sind seit langem bekannt. Bisher schien es aber so, daß die Zielkonflikte nur durch Kompromisse lösbar seien - sowohl bei den Erwartungen als auch beim konkreten Einsatz von Datenbanken im technischen Bereich. Das zunehmende Wissen über Softwarestrukturierungstechniken - insbesondere das Aufkommen des objektorientierten Ansatzes - machte aber deutlich, wie Datenbankkonzepte auf solche "Nicht-Standard-Einsatzgebiete" zugeschnitten werden können.

Einer der wesentlichen Punkte ist dabei ein starker "semantischer" Ansatz, durch den die gespeicherten Daten gleichzeitig in ihrer Bedeutung beschrieben werden. Dieser Trend zur adäquaten Repräsentation von Daten für technische Anwendungsbereiche führte inzwischen zu unterschiedlichen Entwicklungen im Datenbankbereich, welche zunächst als "Nicht-Standard-Datenbanken" bezeichnet wurden.

Das Hauptziel bei der Entwicklung solcher Datenbanken bestand zum einen in der adäquaten "Wissensrepräsentation". Außerdem sollten bestimmte Arbeitsweisen unter stützt werden, so zum Beispiel lange Transaktionszeiten, wie sie in technischen Entwurfssystemen vorkommen.

Die nächste Generation

Wie sehen nun die Datenbanken der nächsten Generation aus? Sicher werden diese Datenbanken - neue Applikationen unterstützen - mächtigere Strukturierungsmechanismen und neue Formen der Arbeitsweise, - starker in die Anwendungsstruktur eingebettet sein und damit eine transparente Datenspeicherung erleichtern (dies ist möglich, wenn Mechanismen zur Verfügung stehen, mit denen die Datenbankstruktur entsprechend der Applikationsstruktur erstellt werden kann), - über stärkere Repräsentationsformalismen als nur das Mengenmodell verfügen (im Idealfall über dieselben Strukturierungsmechanismen wie die Applikation insgesamt).

Als Hauptrichtung dieser neuen Generation von Datenbanken haben sich die objektorientierten Datenbanken herausgebildet. Der Grundgedanke bei der Entwicklung objektorientierter Datenbanksysteme ist der, die Semantik von Anwendungen vollständiger und adäquater im Datenbanksystem zu repräsentieren sowie einen Wechsel der Repräsention zu vermeiden, der in den meisten Fällen zu semantischen Verlusten (impedance mismatch) bei der Transformation vom Daten Modell der Programmiersprache in das Modell des Datenbanksystems führt.

Diese reichere Strukturierung der möglichen Repräsentationen bezieht auf jeden Fall das Mengenkalkül ein, das an sich keinerlei Strukturen in den Daten voraussetzt. Insofern kann SQL als eine Teilmenge der Abfragemöglichkeiten weiter verwendet werden.

Welche sind nun solche neuen Anwendungen, für die objektorientierte Datenbanken das geeignete Speicherkonzept darstellen? Zunächst drängen sich da die CAD-Anwendungen auf: CAD-Systeme müssen, um wirklich Multiuser-fähig zu sein, komplizierte Synchronisationsmechanismen einbauen. Meist wird einfach eine komplette Zeichnung gesperrt und erst nach beendeter Bearbeitung wieder freigegeben. Mit einer geeigneten Datenbank könnten mehrere Personen gleichzeitig an verschiedenen Aspekten einer Konstruktion arbeiten.

Optimal wäre eine objektorientierte Datenbank auch als "Information Broker" oder "Object Handler" zwischen verschiedenen ClM-Komponenten. Die verschiedenen Komponente können die für sie relevante Aspekte der Informationen entweder - wenn sie darauf eingerichtet sind - direkt oder aber über eine allgemeine Schnittstelle bearbeiten.

Auch Multimedia-Anwendungen benötigen große Mengen an Daten, die mit äußerster Effizienz zur Verfügung gestellt werden müssen. Gleichzeitig ist es notwendig, zum Beispiel die Strukturen von Bildsequenzen verfügbar zu haben, damit ein Editieren möglich wird.

Als Repository für eine CASE-Umgebung ist eine objektorientierte Datenbank ebenfalls mindestens ebenso geeignet wie eine relationale. In einer CASE-Umgebung geht es nämlich um eine Vielzahl unterschiedlicher Dokumente, die die verschiedensten Bezüge zueinander haben.

Beim Netzwerk-Management werden viele verschiedene Objektarten mit komplizierten Verhaltensweisen und jeweils eigenen Strukturen verwaltet. Deshalb liegt auch hier ein Einsatzschwerpunkt für objektorientierte Datenbanken.

Ähnliches gilt für den Bereich Office Automation. Die Dokumentverwaltung in einem Office-Automation System weist viele Gemeinsamkeiten mit einer Multimedia-Umgebung auf; bisweilen ist es sogar schon selbst eine solche Umgebung. Last, but not least werden sich objektorientierte Datenbanken auch bei den geographischen Informationssystemen durchsetzen.

In den genannten Anwendungsbereichen sind folgende zentrale Erweiterungen gegenüber relationalen Datenbanken besonders hervorzuheben: Komplizierte Strukturen lassen sich direkt repräsentieren, und der Katalog der Datentypen kann anwendungsspezifisch erweitert werden. Damit ergibt sich gerade für Bereiche, in denen solche Strukturen von zentraler Bedeutung sind, eine wesentlich höhere Unterstützung der Datenbank für die Anwendungsstrukturierung.