Unternehmensspezifische Anwendungssoftware wird heutzutage meist nach dem Prinzip der Client-Server-Architektur entwickelt. Kernstücke solcher Anwendungen sind relationale Datenbanken auf der Server-Seite. Was die Clients angeht, existieren Anwendungen mit grafischer Oberfläche, die oft mit Hilfe von Rapid-Application-Development und CASE-Tools entstehen.
Als grundlegendes Abstraktionsprinzip hat sich weitgehend die Objektorientierung durchgesetzt. Jedoch ist das vorherrschende technische Prinzip dabei häufig noch die Verknüpfung von Feldern in der grafischen Oberfläche des Clients mit Spalten und Zeilen aus den Tabellen einer relationalen Datenbank auf dem Server.
Die immer komplexeren Geschäftsmodelle der Unternehmen stellen jedoch diese relational geprägte Client-Server-Architektur zunehmend in Frage. Mehrschichtige Architekturen dienen der Entkopplung der Business-Logik von der Benutzerschnittstelle und den Basisdiensten, den Services.
Ganz gleich, ob neu definierte Kunden- und Lieferantenbeziehungen, Flexibilisierung der internen Prozesse oder Electronic Commerce - fast immer bewirkt ein komplexeres Geschäftsmodell auch ein komplexeres Datenmodell. Es gibt somit gute Gründe, diese Komplexität durch objektorientierte Persistenz zu verringern und von der ohnehin komplizierten Business-Logik zu trennen. Damit lassen sich auch die Anforderungen des Change-Management besser erfüllen.
Doch mit komplexeren Datenmodellen wird der sogenannte Impedance Mismatch (die "semantische Lücke") größer: Komplexe Business-Modelle mit vielfältigen Beziehungen der Objekte untereinander haben schon heute zu relationalen Schemata geführt, die kaum noch überschaubar oder zu warten sind. Dabei liegt ein Großteil des Problems schon in der grundsätzlich eingeschränkten, um nicht zu sagen mangelnden, Modellierungsfähigkeit des relationalen Modells begründet.
Als Reaktion versuchen alle bedeutenden Hersteller relationaler Datenbanken (RDBMS) ihre Systeme mit objektrelationalen Erweiterungen auszustatten. Das zugrundeliegende relationale Modell bleibt jedoch davon unberührt.
Aus diesem Grund gibt es keine Unterstützung für die Aufgabe, beliebig komplexe unternehmensspezifische Objektmodelle abzubilden. Lediglich für eine Reihe vorgefertigter Datentypen werden proprietäre Erweiterungen in Form von Cartridges, Datablades etc. angeboten. Die Abbildung von Objekten auf Tabellen bleibt weiterhin dem Anwender überlassen. Insofern ist die neue Welle objektrelationaler Datenbanken (ORDBMS) eher ein Marketing-Schachzug, um auf neue Kundenwünsche zu reagieren.
Trotz der Notwendigkeit einer Objektsicht auf die Daten und der naheliegenden Speicherung der Objekte in einer entsprechenden Datenbank beherrschen relationale Systeme eindeutig den Markt. Zudem sind Objektdatenbanken (ODBMS) heutzutage noch nicht so gut skalierbar wie relationale Datenbanken, die über Jahre hinweg auf Online Transaction Processing (OLTP) ausgerichtet wurden. Skalierbarkeit meint hier die Anzahl der Benutzer und den Transaktionsdurchsatz. In anderen Skalierungsaspekten, wie Komplexität des Schemas und dessen Versionierung, Performanz bei navigierendem Zugriff, Verteilung von Objekten im Netzwerk, sind Objektdatenbanken den relationalen überlegen.
Aber auch wenn objektorientierte Datenbanken viele der Anforderungen besser als relationale erfüllen, sind doch die meisten Informationen heutzutage in einer Datenbank letzteren Typs gespeichert. Und daran wird sich auch in naher Zukunft wenig ändern. Ohne einen transparenten Zugriff auf Daten in den Tabellenkäfigen werden sich neue Architekturen nicht durchsetzen. Auch können die Anwender ihre riesigen Investitionen in ein RDBMS nicht einfach verwerfen.
Die Konsequenz daraus ist, daß eine neue Architektur eine Schicht besitzen muß, die in der Lage ist, Objekte transparent auf Tabellen abzubilden. Eine Lösung des Dilemmas besteht also darin, die physikalische Speicherung, wenn nötig, bei der relationalen Datenbank zu belassen, das Objekt-Management jedoch durch Einführung einer objektorientierten Zwischenschicht in den Griff zu bekommen.
Eine solche Schicht zwischen physikalischer Datenhaltung und der Eingabemaske am Bildschirm ist ohnehin für die explizite Formulierung von Geschäftsprozessen unumgänglich. Denn in einer Architektur, die lediglich Felder einer Dialogmaske mit Spalten einer Datenbanktabelle verknüpft, ist es nahezu unmöglich, Geschäftsprozesse abzubilden beziehungsweise zu reorganisieren.
Allerdings helfen in einer solchen dreistufigen ("3-Tier") Architektur die Werkzeuge zur Erstellung von Client-Server-Applikationen der ersten Generation nicht mehr weiter. Grund: Die mittlere Schicht der 3-Tier-Architektur ist notwendigerweise objektorientiert und sollte ebenfalls eine objektorientierte Sicht auf die Daten haben. Andernfalls muß sie neben der Abbildung von Geschäftsprozessen noch die Abbildung auf Tabellen übernehmen und wird dadurch unnötig kompliziert.
Viele Firmen sind bereits vor einiger Zeit an die Grenzen der herkömmlichen Architektur gestoßen und haben begonnen, selbst Unterstützungssoftware für die objektorientierte Datenspeicherung zu entwickeln. Diese Software ist hochkomplex, fehleranfällig und kostenträchtig.
Häufig wird zudem übersehen, daß es nicht nur darum geht, Klassen auf Tabellen abzubilden. Versionierung, gleichzeitiger Zugriff ("Concurrency"), Transaktions-Management spielen eine ebenso entscheidende Rolle. Da die Anforderungen in Zukunft noch steigen, ist davon auszugehen, daß sich eine Eigenentwicklung nicht lohnt.
Seit zwei bis drei Jahren etablieren sich auch Standardprodukte auf diesem Markt. Die meisten beschränken sich jedoch darauf, aus einem Tabellenschema Programmcode für ein Klassenschema zu generieren. Dieser Ansatz ist nicht transparent und läßt häufig die anderen Aspekte einer objektorientierten Datenhaltung unberücksichtigt.
Auch wenn der Zugriff auf Zeilen einer Tabelle mit Hilfe einer generischen Klasse gegenüber dem ersten Ansatz einen Vorteil bringt, erfüllen die meisten Systeme bislang die beschriebenen Anforderungen nicht. Ein wichtiger Mangel bei der Codegenerierung ist die fehlende Unterstützung von Schemaänderungen.
Fehlende Standards erschweren zudem den breiten Einsatz objektrelationaler Systeme. Der Standard der Objekt Database Management Group ist der einzige in Sachen ODBMS. Dieser enthält ein Objektmodell und Programmierschnittstellen, schreibt aber nicht vor, daß das Datenbanksystem objektorientiert sein muß.
Objektrelationale Middleware sollte sich an diesen Standard halten. Javasoft hat dies Problem auch erkannt und will die ODMG-Vorgaben mit einer angekündigten objektrelationalen Middleware ("Javablend") unterstützen. Sie soll Java-Applikationen eine Objektsicht auf Daten ermöglichen, die persistent in relationalen Systemen gespeichert sind.
Zugegebenermaßen wird ein RDBMS trotz transparentem objektorientiertem Zugriff sich niemals wie ein echtes ODBMS verhalten. Ebensowenig wird letzteres nicht bestimmte Merkmale eines relationalen Systems erreichen. Dazu sind die technischen Unterschiede in der Kernarchitektur beider Systeme zu fundamental. Für einfache Schemata mag das noch nicht so evident sein, aber je stärker die zuvor beschriebenen Anforderungen zutage treten, desto augenfälliger sind die Unterschiede der Technologien.
Unterschiede müssen nicht immer negativ sein. Ein guter Ansatz ermöglicht die wahlweise Verwendung einer relationalen oder objektorientierten Datenbank. Die Sicht auf die Datenbank sollte immer objektorientiert sein, und je nach Anforderungsprofil beziehungsweise aufgrund firmenpolitischer Entscheidungen, wird das eine oder andere System verwendet. Erlaubt diese Middleware die gleichzeitige Verwendung beider Speichertechnologien, kann man sich sozusagen "das Beste von beiden Welten" heraussuchen.
Angeklickt
Die Komplexität der Anwendungen steigt. Software gilt nicht mehr nur als unterstützender Service, sondern ist vielfach integraler Bestandteil der Geschäftsprozesse. Es entstehen - heutige Extranets sind nur eine Vorstufe - virtuelle Wertschöpfungsketten, in denen beispielsweise ein Dienstleister gleichzeitig Kunde eines weiteren Dienstleisters wird, um einen Kundenauftrag abzuwickeln. Geschäftsprozesse lassen sich mit Geschäftsprozessen anderer Unternehmen verzahnen. Der Autor vertritt die Ansicht, unter solchen Vorzeichen könne nur Objektorientierung künftiges Change-Management ermöglichen.
*Jörg Beckert ist Project Manager Architect Gateway Technology bei der Poet Software GmbH in Hamburg.