Gerade für komplexe, unternehmenskritische Anwendungen klingen die Vorteile objektorientierter Techniken verheißungsvoll: Man verspricht sich Skalierbarkeit und einfachere Erweiterbarkeit der Lösungen, Unterstützung für komplexe Datenmodelle und steigende Programmiererproduktivität durch den Einsatz von Componentware. Und nachdem objektorientierte Projekte über lange Jahre hinweg kaum aus dem Experimentierstadium herausgekommen sind, stehen heute von unterschiedlichen Anbietern kommerzielle Werkzeuge in hinreichender Qualität zur Verfügung, mit denen sich diese Vorteile in der Praxis auch erfolgreich umsetzen lassen.

Hinzu kommen die zunehmende Standardisierung der Objekttechnologie und die millionenfache Verbreitung von Java in den führenden Browser-Plattformen. Bedenkt man außerdem, daß der "Message-Passing"-Ansatz objektorientierter Systeme sich für den Einsatz in den heutigen verteilten Umgebungen optimal eignet, wird rasch klar, warum objektorientierte Anwendungsentwicklung vielerorts mit geradezu religiösem Eifer als der Ausweg aus der Softwarekrise gehandelt wird.

Die Verfechter vergessen nicht, darauf hinzuweisen, daß die besonderen Stärken der Objekttechnologie in der Handhabung komplexer Datenmodelle liegen. Und die gibt es reichlich: So geht etwa Diebold davon aus, daß von den in heutigen Unternehmen zu verwaltenden Daten rund 80 Prozent in die Kategorie "komplex strukturiert" fallen - etwa Web-Seiten, multimediale Daten, Zeitreihen, Raum- und CAD-Daten, Office-Dokumente, Business-Objekte etc.

Modelliert man diese komplex strukturierten Daten allerdings tatsächlich als Objekte, ergibt sich fast zwangsläufig die Forderung nach der persistenten Speicherung von Objekten. Objektorientiert modellierte Daten im klassischen relationalen Datenmodell zu speichern führt zum als "Impedance Mismatch" bezeichneten Bruch der Modelle. Relationale Datenbanken zwingen die Entwickler letztlich, ihre komplexen Strukturen zur Speicherung wieder in ein simples tabellarisches Modell zu zerlegen.

Als klassische Metapher für das Beschreiben dieser Unzulänglichkeit wird gern das Parken eines Autos in einer Garage angeführt. Das Auto steht hierbei für ein Geschäftsobjekt und die Garage für die Datenbank. Um nun das Fahrzeug in einer relationalen Garage abzustellen, muß man es zunächst in seine Einzelteile zerlegen und diese Teile dann in entsprechende Fächer einsortieren. Will man es wieder aus der Garage herausbekommen, muß man die benötigten Teile in den verschiedenen Fächern erst einmal wiederfinden und sie korrekt zusammensetzen. Dieses - durch die Datenbanknormalisierung erzwungene - Zerlegen und Wiederzusammensetzen ist also allerhöchstens dann nützlich, wenn man eine Reihe von Motoren nach bestimmten Merkmalen durchsuchen oder die Vergaser von Autos, Booten und Flugzeugen vergleichen will.

Aus diesem Grund erfreuen sich Datenbanken mit "postrelationalen" Datenmodellen steigender Beliebtheit am Markt. Sie folgen einem objektorientierten, verschachtelt relationalen oder multidimensionalen Modell und sind damit in der Lage, das Auto im ganzen in der Garage zu parken und wieder herauszuholen. Durch die Vermeidung des Impedance Mismatch wird eine große Fehlerquelle in der Anwendungsentwicklung ausgeschaltet.

Auch die meisten Anbieter relationaler Datenbanken entwickeln deshalb ihre Produkte zu sogenannten objektrelationalen Datenbanken oder Universal Databases weiter. Damit lassen sich immerhin einige Limitierungen des relationalen Modells umgehen. Nach wie vor decken aber die meisten Produkte grundlegende objektorientierte Eigenschaften wie Vererbung und Polymorphismus nicht ab.

Trotz dieser Richtungsverschiebung wird der Datenbankmarkt bisher noch deutlich von den klassischen relationalen Datenbanken dominiert. Laut IDC-Zahlen für 1997 entfielen auf sie 78 Prozent des Gesamtumsatzes, lediglich drei Prozent auf Datenbanken mit postrelationalen Modellen. Letztere fielen allerdings mit einer Wachstumsrate von über 50 Prozent auf.

Solche Zahlen machen deutlich, daß die postrelationalen Datenbanken langfristig eine entscheidende Rolle am Markt spielen werden. Zugleich ist aber offensichtlich, daß bei allen strategischen Lippenbekenntnissen einiger Anbieter zur Objekttechnologie die zugehörigen Datenbanken noch auf Jahre ein Nischendasein führen werden.

Als wichtigster Hemmschuh für den flächendeckenden Einsatz neuer Datenbanktechnologien erweist sich dabei die vorhandene große installierte Basis relationaler Applikationen und der zugehörigen Datenmodelle. Relationale Applikationen bilden heute das Rückgrat der unternehmenskritischen Datenverarbeitung in praktisch allen Unternehmen. Zudem wird durch Erfordernisse wie die Euro-Einführung und die Jahr-2000-Problematik gerade in diese Anwendungen weiter massiv investiert, so daß an eine umfassende Ablösungswelle in den nächsten Jahren nicht zu denken ist.

Will man die Vorteile objektorientierter Anwendungsentwicklung nutzen, wird dies also kurz- und mittelfristig im wesentlichen in zwei Bereichen möglich sein: in neu entstehenden Anwendungsnischen - etwa dem Internet/Intranet-Bereich - und in der Fortentwicklung bestehender Lösungen, also für neue Softwaremodule zu existierenden Anwendungen.

Soll hier mit Objekttechnologie gearbeitet werden, ohne zugleich auf die bewährten relationalen Applikationen zu verzichten, stellt dies eine Reihe von Anforderungen an die eingesetzte Datenbanktechnologie:

Die vollständige Unterstützung der Eigenschaften objektorientierter Datenbanken gemäß Spezifikationen der Object Database Management Group (ODMG) sollte selbstverständlich sein. Hierzu zählen die grundlegenden Objekteigenschaften Kapselung, Vererbung, Polymorphismus ebenso wie anwenderspezifische Datentypen, Sicherstellung der Objektidentität, Speicherung von Objekteigenschaften und -verhalten sowie Unterstützung von Programmiersprachen mit Datenbankzugriff ohne Semantikverlust.

Persistente Objektspeicherung ist zumindest für Java, C++ und Active X erforderlich. Für durchsatzstarke mehrstufige Client-Server-Lösungen ist zudem ein ausgeklügeltes verteiltes Objekt-Caching Voraussetzung. Vorhandene SQL-basierte Tools müssen voll unterstützt werden. Hierzu ist eine ODBC-Level-2-Schnittstelle erforderlich; OCI ist wünschenswert.

Die Ausführung vorhandener relationaler Applikationen erfordert SQL-Transaktionssicherung sowie volle Unterstützung für Stored Procedures und SQL/ DML.

Zur Übernahme des relationalen Datenmodells ist vollständige DDL-Kompatibilität nötig. Eine wichtige Frage ist es, ob eine automatische Generierung von Objekten aus Tabellen (und umgekehrt) erfolgt beziehungsweise ob und wie die relationalen und objektorientierten Repositorien synchronisiert werden. Optimal ist eine einheitliche Definition für Tabellen und Objekte. Zu klären ist weiterhin, ob sich relationale und/ oder objektorientierte Modellierungs-Tools einbinden lassen.

Relationale und objektorientierte Zugriffe sollten möglichst direkt auf die Datenbank erfolgen. Gehen Objektzugriffe durch die SQL-Schicht (wie meist in objektrelationalen Datenbanken), kostet dies unnötig Performance. Gleiches gilt für Objektdatenbanken, bei denen die SQL-Zugriffe durch die Objektschicht geleitet werden.

Mit einer Datenbanktechnologie, die alle genannten Kriterien hinreichend berücksichtigt, lassen sich relationale Applikationen verlustfrei portieren. Und es ist möglich, objektorientierte neue Module und Applikationen zu entwickeln, die ohne Semantikverlust auf die bestehenden Datenstrukturen zugreifen.

Bei entsprechend sorgfältiger Auswahl der Datenbanktechnologie ist eine verlustfreie Migra- tion von der relationalen in die objektorientierte Welt realistisch. Für den Anwender bedeutet dies, die vorhandenen Applikationen weiter nutzen zu können, und zwar durchaus mit beachtlichen Gewinnen bei Transaktionsleistung und Skalierbarkeit.

Angeklickt

Wer die Anforderungen komplexerer Geschäftsmodelle bewältigen will, kommt über kurz oder lang nicht an der Objektorientierung vorbei. Während sich dieser Ansatz bei der Anwendungsentwicklung langsam, aber sicher durchsetzt, stehen dem flächendeckenden Einsatz objektorientierter Datenbanken noch manche Hindernisse im Weg. Als wichtigster Hemmschuh hierbei erweist sich die vorhandene große installierte Basis relationaler Applikationen und der zugehörigen Datenmodelle. Die hat gute Gründe - versperrt allerdings nicht grundsätzlich neue Wege.

Michael Ihringer ist Marketing-Manager der Intersystems GmbH in Darmstadt.