Datenbanken sind heute zumeist relationale Systeme, die Informationen in Tabellenstrukturen speichern und Logik durch Beziehungen (Relationen) innerhalb dieser Tabellenstrukturen abbilden. In einer Warenwirtschaftssoftware wird so zum Beispiel festgelegt, daß eine Zeile in der Tabelle "Kunden" beliebig viele Einträge in der Spalte "Bestellungen" haben kann. Für den Anwender ergibt sich daraus, daß ein bestimmter Kunde eine beliebige Anzahl von Bestellungen aufgeben darf.
Der große Vorteil von Tabellenstrukturen ist, daß sich die Daten gezielt durchsuchen oder ordnen lassen. Dies geschieht mit der standardisierten Abfragesprache Structured Query Language (SQL). Ferner ist durch SQL die Auswertung von Daten in Tabellen prinzipiell auch ohne die Anwendung möglich, die die Informationen in der Datenbank abgelegt hat. Die Integrität der Daten ist durch Regeln, sogenannte Constraints, die man für die Beziehung von Tabellen festlegen kann, sichergestellt. Beispiele für Regeln sind: Eine Buchung auf ein Konto darf nur durchgeführt werden, wenn das Konto bereits angelegt wurde; oder: Eine Löschung von Datensätzen darf in einer bestimmten Tabelle nicht mehr erfolgen.
Betriebswirtschaftliche Daten wie Buchungssätze in einer Finanzbuchhaltung oder Auftragspositionen sind in einer relationalen Datenbank aufgrund des schnellen Zugriffs und großer Sicherheit bei der Integrität von Daten sinnvoll abgelegt. Selbst Dateien aus gängigen Office-Anwendungen oder Multimedia-Informationen wie Videos, Bilder oder Sounds, die sich allein durch verschiedene Größen schwer in eine statische Tabellenstruktur pressen lassen, sind inzwischen in fast allen relationalen Datenbanksystemen in Form von Binary Large Objects (Blobs) speicherbar. Hier zeigen sich allerdings Schwächen, denn Blobs werden im Datenbanksystem zwar abgelegt, können aber nicht mit gängigen SQL-Anweisungen durchsucht oder für Integritätsprüfungen herangezogen werden.
Der größte Nachteil relationaler Strukturen liegt jedoch in der eingeschränkten Möglichkeit, Hierarchien abbilden zu können, ohne für jede Ebene eine eigene Tabelle anlegen zu müssen. Dies wäre bei einer großen Anzahl von Hierarchieebenen bereits mühsam, ist bei den sich ständig verändernden Hierarchiestufen aber fast unmöglich, denn dieses Szenario hätte unweigerlich eine ständige dynamische Änderung von Tabellenstrukturen zur Folge.
Aus diesem Grund kamen vor einigen Jahren Objektdatenbank-Management-Systeme (ODBMS) auf, die in wichtigen Dingen gegenüber den relationalen Mitbewerbern überzeugen: ODBMS speichern Daten so, wie sie im Speicher des Rechners als Objekte abgelegt sind. Beziehungen und Abhängigkeiten von Objekten untereinander werden dabei ebenfalls berücksichtigt, so daß es möglich ist, in einer modernen Software ein komplexes Netz aus Objekten und ihren Abhängigkeiten ohne Aufwand direkt in einer Datenbank abzulegen. Zusätzlicher Aufwand für die Datenhaltung fällt dabei nicht an. Direkte Vorteile sind zunächst die gute Integration in bestehende Objektmodelle und die für den Entwickler fast vollständig transparenten Lese- und Schreiboperationen auf die Datenbank.
ODBMS haben Akzeptanzprobleme
Anfängliche Inkompatibilitäten der ODBMS wurden durch eine Standardisierung unter Kontrolle gebracht, so daß sich die Systeme heute für den Entwickler in der Handhabung fast vollständig gleichen. Sie verfügen über eine SQL-ähnliche Abfragesprache mit der Bezeichnung Object Query Language (OQL). Viele Hersteller bieten inzwischen nicht nur eine direkte Unterstützung für die jeweilige Sprache wie C++ oder Java an, sondern liefern auch fertige Komponenten in Form von OCX-Controls für alle nicht direkt unterstützten oder nicht einmal objektorientierten Windows-Entwicklungssysteme.
Obwohl ODBMS in Projekten zum Teil mit großem Erfolg eingesetzt werden, will der wirkliche Durchbruch dieser Systeme auf dem Markt bis zum heutigen Zeitpunkt nicht gelingen. Zu groß ist die Angst vieler Firmen, in eine unausgereifte Technologie zu investieren, zu gering ist gleichzeitig das Angebot an qualifizierten Mitarbeitern oder Dienstleistern, die Impulse für die Entwicklung auf Basis von ODBMS geben könnten. Außerdem haben sich die meisten Kunden erst vor wenigen Jahren für die Einführung eines relationalen Systems entschieden und ihren Mitarbeiterstamm entsprechend aufgebaut. Darüber hinaus konzentrieren sich Hersteller relationaler Systeme wie etwa Oracle mehr und mehr in der Implementierung von OO-Technologien.
Mit der Extensible Markup Language (XML) als universeller Standard für den Austausch von Daten spezifiziert, bekommen Objektdatenbanken nun, so die Meinung von Herstellern und Marktforschern gleichermaßen, Rückenwind. Daten werden in XML mit Hilfe von Tags inhaltlich organisiert.
XML als ein rettender Strohhalm?
Der Aufbau eines XML-Dokuments und seiner Tags können in einer eigenen Datei, der Document Type Definition (DTD), definiert werden. Der Vorteil liegt auf der Hand: Durch die Weitergabe der XML zusammen mit der entsprechenden DTD-Datei läßt sich diese Adreßdatenbank von verschiedenen unabhängigen Programmen verarbeiten. Während der Austausch von Daten mit XML besonders im betriebswirtschaftlichen Bereich als Konkurrenz zu EDI zu sehen ist, bietet sich für die Hersteller von Dokumenten-Management- und Archivsystemen mit XML die Möglichkeit, Dokumente inhaltlich zu gliedern und so abzulegen, daß eine gezielte Suche nach Inhalten möglich ist.
Angeklickt
Die Chancen für eine breitere Akzeptanz von Objektdatenbanken steigen wieder. Lange Zeit galten Produkte wie "Poet" oder "Objectstore" trotz ihrer im Vergleich zu relationalen Systemen erweiterten Fähigkeiten als Außenseiter im Datenbank-Business. Hoffnung kommt nun von der Extended Markup Language (XML), die Objektdatenbanken zu dem Ruhm ihrer relationalen Kollegen verhelfen könnte.
*Stefan Beyer arbeitet als Berater, Trainer und Entwickler für das Büro für Netzwerke und Systeme in Frankfurt am Main.