Objektorientierung ist eine sehr an die Realität angelehnte Sache. Jedes Objekt kapselt in sich Daten und Funktionalität. Ein Kunde wird in beinah allen Programmen mit einer Kundennummer, einem Vor- und Nachnamen sowie einer Anschrift angelegt. Hinzu kommt die Vererbung von Attributen und Methoden. Diese Attribute sind, einfach beschrieben, Daten, die von Programmen meist in Tabellen von SQL-Datenbanken abgelegt werden.

Datenbanken wie Oracle, Sy- base, MS-SQL oder Informix haben sich seit Jahren auf breiter Basis etabliert und arbeiten sehr zuverlässig. Sie sind zu einer Zeit entstanden, in der Objektorientierung (OO) allenfalls diskutiert wurde und noch niemand so recht an ihre Zukunft glauben wollte.

Heute werden strategische Entscheidungen für Programmiersprachen davon abhängig gemacht, ob die eine oder die an- dere Sprache objektorientiert ist oder nicht. Nur bei Datenbanken scheint es dieses Entscheidungskriterium nicht zu geben.

Das Mißtrauen gegenüber der relativ jungen Generation objektorientierter Datenbanken scheint besonders groß zu sein. Begründetes Mißtrauen oder nicht, mittlerweile gibt es einige sehr erfolgreiche Vertreter der OO-Datenbanken wie "Objectivity", "Objectstore", "O2" oder "Poet". Der Anbieter Poet geht dabei sogar noch einen Schritt weiter und entwickelt eine OO-Datenbank für Embedded Systems in Handys oder Handheld-PCs.

Was ist an objektorientierten Datenbank-Management-Systemen (OODBMS) denn nun anders als an relationalen SQL-Datenbanken? Der gravierende Unterschied ist, einfach ausgedrückt, daß Daten in Form von vieldimensionalen Objekten gespeichert werden. Bei relationalen Datenbanken sind die Daten in zweidimensionalen Zeilen und Spalten von Tabellen abgelegt.

Für den Endanwender objektorientierter Datenbanken ergibt sich zumeist kein sichtbarer Unterschied zu relationalen Systemen; den erfährt allerdings ein Programmierer ziemlich kraß. Vergleichbar ist das Konzept mit einem Auto. Während man mit einer OO-Datenbank sein Auto komplett in die Garage fahren kann, müßte man es bei der SQL-Datenbank zuvor in Einzelteile zerlegen und in Regale packen und vor dem nächsten Gebrauch wieder zusammenbauen. Im Prinzip passiert dasselbe mit den Daten eines Objekts "Auto".

Dieses simple Beispiel verdeutlicht die Diskrepanz zwischen relationalen und objektorientierten DBMS. Gerade bei sehr großen Projekten kommt es in der Regel zu einem signifikanten Mehraufwand an Zeit und Budget, um objektorientierte Programme so auszustatten, daß sie auf relationale Datenbanken zugreifen können. Objektorientierte Programmentwicklung ist mit den entsprechenden Datenbanken wesentlich effektiver als mit den traditionellen relationalen Systemen.

Das haben auch die Hersteller relationaler DBMS erkannt, sie bieten für ihre Datenbanken und darauf bezogene Entwicklungs-Tools sogenannte Objektlinsen oder Object-Mapper an. Diese dienen dazu, die notwendigen Konvertierungen von SQL-Daten in Objekte und umgekehrt zu automatisieren. Dadurch erhalten Programmierer eine Objektsicht auf strukturierte Daten.

Der Nachteil ist dabei allerdings die zum Teil mangelhafte Performanz solcher Helfer, denn das automatische Umsetzen von Tabellen in Objekte und umgekehrt braucht nun einmal seine Zeit. Der Vorteil hierbei liegt allerdings an anderer Stelle. Wer nämlich ein relationales System einsetzt und dies als strategische Plattform betrachtet, kann seine einmal getätigten Investitionen schützen.

Wenn Anwender aber vor der Neuanschaffung einer Datenbank stehen oder über ihre DV-Strategie nachdenken, sollten sie sich eingehend mit OO-Datenbanken befassen. Heute werden OODBMS in Multimedia-Applikationen oder für grafische Informationssysteme eingesetzt, wobei ihr Anwendungsgebiet keineswegs auf den Landschaftsbau beschränkt ist.

Es gibt einige Anhaltspunkte, unter welchen Bedingungen eine objektorientierte Datenbank in Frage kommt, an denen sich Anwender orientieren können. Sollten sie eine OO-Sprache wie Java oder C++ einsetzen und mit Vererbung und Aggregation von Objekten arbeiten oder wenn sie Daten mit variablen Strukturgrößen haben, dann lohnt sich ein Blick auf die andere Seite in jedem Fall.

Aus technischer Sicht gibt es jedenfalls eine Menge Unterschiede, die dem Entwickler eigentlich transparent erscheinen sollten. Wie sieht es also mit entsprechenden Werkzeugen für die Modellierung von OO-Datenbanken aus? Schließlich müssen Daten ja auch abgefragt und angelegt werden.

Die Object Database Management Group (ODMG) ist eine Vereinigung, die sich aus Anbietern objektorientierter Datenbanken zusammensetzt. Ergebnis der Standardisierungsbestrebungen der ODMG ist unter anderem das Java-Binding, durch das sich Java-Objekte mit OODBMS austauschen können. Demnach werden bestimmte Java-Datentypen auf entsprechende OODBMS-Pendants abgebildet.

Für den Programmierer ist das Binding bisher nahezu die einzige Möglichkeit einen gleichgearteten Ansatz auf verschiedenen OO-Datenbanken zu realisieren. Werkzeuge für die grafische Modellierung von OO-Datenbanken wie bei Objectstore gibt es derzeit nur selten. Auch weiß kaum ein Entwickler, wie er die Datenbanksprache Object Query Lan- guage (OQL) anpacken soll, um Abfragen ähnlich wie bei SQL in relationalen Umgebungen abzusetzen.

Diese beiden Probleme sind wohl die gravierendsten, mit denen OO-Datenbanken zu kämpfen haben. Doch es ist Land in Sicht. Objectstore von Object Design macht es vor, und andere werden folgen. Diese Lösung stellt Tools zur Verfügung, mit denen sich, ausgehend von sogenannten UML-Diagrammen (Unified Modelling Language), Datenbanken aufbauen lassen. Abfragen werden mit Hilfe grafischer Werkzeuge erstellt.

Wenn erst einmal mittels solcher und weiter verbesserter Werkzeuge Objekte einfacher zu handhaben sind, werden auch viele andere Vorurteile fallen - und OO-Datenbanken zum Main- stream. Doch bis dahin gibt es noch einiges zu tun. Warum lassen sich viel mehr Unternehmen auf Java ein als auf OO-Datenbanken? Spielt Marketing etwa die entscheidende Rolle?

Heute kann man bequem jede SQL-Tabelle in Excel importieren. Solange dies mit OO-Datenbanken nur über Umwege machbar ist, wird sich immer eine Scheu vor den OODBMS ergeben. In puncto Performanz können heute bereits einige OO-Systeme die relationalen Vorgänger schlagen.

Bleibt also die Frage: Für wen lohnt sich der Einsatz wirklich? Auf Objectstore setzt British Telecom. BT erwartet durch den Einsatz der OO-Datenbank bis zu 40 Prozent weniger Entwicklungsaufwand.

Wo das Hubble-Teleskop Sternenobjekte speichert

Für Objektorientierung in Sachen Datenbanken hat sich auch das Space Telescope Science Institute, ST ScI, entschieden, das für den Betrieb des "Hubble"-Teleskops verantwortlich ist. Hier wird eine riesige Datenbank für den "Guide Star Catalog" und die "Catalogs of Objects and Measured Parameters from All Sky Surveys (Compass)" auf der Basis von Objectivity erstellt.

Anhand der hier versammelten Daten läßt sich Hubble auf seine Zielobjekte am Himmel ausrichten. Eine Sammlung von über 6000 ausgewerteten Segmenten mit 109 Objekten steht in einer allein schon über 4 TB umfassenden Datenbank bereit. Hinzu kommen noch einmal rund 33000 Bereiche mit jeweils rund 50000 Objekten, die wiederum eine Größe von gut 4 TB besitzen. Eine derart riesige Datenmenge kann nur eine skalierbare und leistungsfähige Datenbank handhaben.

Neue Ansätze der OODBMS-Anbieter

Die Anbieter relationaler Datenbanken kennen solche Beispiele natürlich, weshalb sie ähnliche vorführen, um zu zeigen, daß es für derlei Anwendungen nicht unbedingt objektorientierter Systeme bedarf. So reklamiert Microsoft die weltweit größte Online-Datenbank für sich. Unter der Web-Adresse www.terraserver. com finden sich unzählige Satellitenaufnahmen der USA und anderer Teile der Welt. Diese Datenbank wurde mit dem SQL-Server 7.0 implementiert. Ihre Größe: rund 3,5 TB.Einen Bereich, in dem SQL-Datenbanken zu klobig wirken und zuviel Overhead mitbringen, könnten von vornherein OO-Pendants besetzen. Für den Einsatz unter Personal-Java, einer Plattform für Consumer-Geräte, eignet sich das neueste Release "Objectstore Pro 2.0" aus dem Haus Object Design.

Die Firmen Gemstone und Ontos verfolgen neue Wege im Marketing ihrer Produkte. Sie verkaufen nicht mehr das Produkt OO-Datenbank, sondern bieten einen Applikations-Server an, der das OODBMS enthält. Vielleicht ein cleverer Schachzug, denn Applikations-Servern wird eine goldene Zukunft prophezeit.

Angeklickt

OO-Datenbanken wirken auf viele Entscheider wie Exoten. Wer jedoch eine objektorientierte Entwicklungssprache wie Java oder C++ einsetzt, sollte sich vor seinem nächsten Projekt einmal eine OO-Datenbank näher ansehen. Doch: Wann lassen sich OO-Datenbanken effektiver einsetzen als relationale Datenbanken oder ihre objektrelationalen Erweiterungen? Trifft der alte Vorwurf mangelnder Performance noch zu? Wie ist es um Werkzeuge für die Applikationsentwicklung bestellt? In welchen Punkten lassen sich strategische Ausrichtungen der Anbieter aus der objektorientierten Fraktion erkennen?

Diplomingenieur Michael Johann, Münster, ist Unternehmensberater auf dem Gebiet Java. E-Mail: mjohannjavatalk.net