Wer behauptet, objektmorientierte Datenbanken wuerden ihre relationalen Pendants ersetzen koennen, irrt. Wer behauptet, relationale Datenbanken wuerden den Kampf der Technologien gewinnen, irrt auch. Beide gedachten Kommentare analysieren am Kern des Problems vorbei, denn es kann nicht darum gehen, eine Technologie gegen die andere auszutauschen. Vielmehr muss man sich bei beiden Technologien jeweils fragen, ob sie fuer die betreffende Anwendung geeignet ist und welche Vorteile durch ihren Einsatz zu erwarten sind.
Ein Blick in die Historie der Datenbanken zeigt: Koexistenz ist moeglich, ja sogar noetig. Als Anfang der 80er Jahre die relationalen Datenbanken aufkamen, waren die wenigsten Unternehmen willens und in der Lage, ihre Datenbestaende komplett dem neuen Paradigma zu unterwerfen. So haben bis heute hierarchische Datenbanken ihren festen Platz in der DV grosser Unternehmen. Umgestellt wurde jedoch dort, wo dies sinnvoll war und Vorteile brachte: Die Verwaltung von Adressen, Finanz- und Personaldaten gehoert heute zu den klassischen Aufgaben relationaler Datenbanken, da es sich bei ihnen um einfach strukturierte Daten handelt.
Muessen dagegen komplexe und umfangreiche Datenstrukturen verwaltet werden, sind die Grenzen eines relationalen Systems schnell erreicht: Die "Objekte" muessen fuer die Speicherung auf der Festplatte in Tabellenform gebracht und bei erneutem Aufruf im Hauptspeicher wieder zusammengesetzt werden.
Obwohl mittlerweile etwas ueberstrapaziert, hilft hier der Vergleich mit einem Auto: Die relationale Datenbank "parkt" das Auto, indem sie es komplett demontiert - sie legt Schrauben zu Schrauben, Reifen zu Reifen und so weiter. Wird das Auto wieder benoetigt, muss sie es erst wieder zusammenbauen. Ein umstaendliches und zeitraubendes Verfahren, das objektmorientierte Datenbanken nicht kennen: Sie sind schon laengst am Ziel - sprich: das Objekt ist im Hauptspeicher -, waehrend die relationale Datenbank die Einzelteile noch aus den verschiedenen Listen heraussucht.
Technisch gesprochen bedeutet das: Objektorientierte Datenbanken legen komplexe, stark verzweigte Datenstrukturen ohne umstaendliche Transformationen ab. Relationale Datenbanken hingegen muessen erst ein viele hundert Instruktionen umfassendes Select-Statement interpretieren, um an die Daten zu kommen.
Der Einwand, irgendwann sei die Hardware so schnell, dass der Anwender diesen Performance-Unterschied nicht merke, kann historisch widerlegt werden: Die Ansprueche hinsichtlich Komplexitaet und Komfort der Anwendungen steigen immer schneller, als Computer an Rechenleistung zunehmen koennen.
Aus dem Autobeispiel das absolute Primat objektorientierter Datenbanken zu folgern, waere unsinnig. Relationale Datenbanken haben ihre Existenzberechtigung dort, wo sie sinnvoll eingesetzt werden koennen. Dies ist nach einschlaegigen Untersuchungen bei etwa fuenf Prozent aller weltweit gespeicherten Daten der Fall.
Die ueberwiegende Mehrheit der Daten wird jedoch nach wie vor in Files gespeichert. Sie ermoeglichen zwar schnellen Zugriff, sind aber mehr noch als die relationale Speicherung ungeeignet zur Speicherung komplexer Datenstrukturen - insbesondere in Mehrbenutzer-Umgebungen. Sie unterstuetzen die Anforderungen an Transaktions- und Versionskontrolle nur unvollstaendig. Trotzdem hat auch die dateibasierte Speicherung ihre Berechtigung: Naemlich in kleinen, relativ isolierten Anwendungen mit ueberschaubaren Datenstrukturen, die weder Mehrbenutzer-Faehigkeit noch Versionskontrolle erfordern.
Ein - besonders fuer Entwickler relevantes - Manko haben relationale und dateibasierte Datenhaltung gemeinsam: Es muessen umstaendliche Routinen geschrieben werden, um Daten persistent zu speichern, da sie im Hauptspeicher in einem anderen Format vorliegen als auf der Festplatte. Die objektorientierte Datenbank bietet hier neben dem direkten Zugriff auf die Objekte noch einen weiteren Vorteil: die von Software-Ingenieuren geforderte Durchgaengigkeit des Paradigmas. Wer objektorientierte Analyse- und Designmethoden, Programmiermsprachen, Benutzeroberflaechen und Datenbanken einsetzt, erleichtert in komplexen Projekten die Datenmodellierung und verringert nachweislich Entwicklungs- und Wartungskosten.
Nochmals: Wegen dieser Vorteile den Niedergang relationaler wie hierarchischer Datenbanken zu behaupten, ist verfehlt. Fuer herkoemmliche Anwendungen, etwa eine Kundenadressverwaltung, sind sie nach wie vor gut geeignet. Objektdatenbanken werden sich aber in Bereichen durchsetzen, in denen mit komplexen Informationen im Team gearbeitet wird, wie zum Beispiel bei CAD-, Bueroautomations- und Multimedia-Anwendungen.
Wie ein sinnvoller Weg der Koexistenz begangen werden kann, hat IBM vorgefuehrt. Kuerzlich wurde ein langfristiges Commitment fuer eine Objektdatenbank (Objectstore) abgegeben, ohne die hierarchischen und relationalen Klassiker IMS und DB2 aufzugeben. Dies waere auch wenig sinnvoll: Schliesslich wird kaum ein DV- Verantwortlicher - allen Trends zu Down- und Rightsizing zum Trotz - seine seit Jahren gewachsene Unternehmensdatenbank einem neuen Paradigma unterwerfen. Vielmehr wird er Anwendungsbereiche identifizieren, die vom Einsatz einer Objektdatenbank profitieren, so wie er vor einigen Jahren bestimmte Daten einem relationalen System anvertraut hat.
Hinzu kommt, dass zukuenftige Betriebssystem-Versionen - beispielsweise von Solaris oder Nextstep - bereits Teilfunktionalitaeten objektorientierter Datenbanken enthalten. Hierdurch wird die Implementierung einer Volldatenbank erheblich erleichtert. Entsprechende Produkte werden von zahlreichen Anwendern bereits erfolgreich eingesetzt.
Ein Blick in die Mitgliederliste des Standardisierungsgremiums Object Management Group zeigt ferner, dass die Reduktion auf die Frage "Objektmorientiert oder relational" an der Realitaet vorbei geht: Hier sind - neben anderen - Anbieter beider Technologien vertreten. Ein weiteres Indiz fuer den Trend zur Koexistenz. Diese koennte so aussehen: Hersteller relationaler Datenbanken implementieren Werkzeuge, die eine relationale Sicht auf Objektdatenbanken erlauben und umgekehrt. So koennen existierende Anwendungen mit objektmorientierten Datenbestaenden arbeiten und neue, objektmorientierte Anwendungen auf relationale Daten zugreifen. Der Anwender hat die Wahl, ob er die Investitionen in seine Applikationen oder in seine Datenbestaende schuetzen will. In jedem Fall hat er einen sinnvollen Migrationspfad und kann die Vorteile beider Technologien nutzen.
Oscar Wilde hat einmal gesagt: "Alles ist richtig, nur nicht immer, nur nicht ueberall." Ein Hersteller - ob einer hierarchischen, einer relationalen oder einer objektorientierten Datenbank -, der von seinem Produkt behauptet, es sei immer und ueberall die richtige Loesung, macht sich verdaechtig: Er argumentiert an den individuellen Beduerfnissen des Kunden vorbei.
Rasp: "Den Niedergang relationaler wie hierarchischer Datenbanken zu behaupten, ist verfehlt."