Anne Christina Remus ist selbständige Beraterin bei Marketingteam, München.
Kaum ein Produkt, das nicht mit dem Hiweis auf objektorientiertes Features prahlt. Zweifellos bringt diese Technik Vorteile für die Anwender, jedoch nur wenn die Werbeslogans einer Überprüfung standhalten. Voraussetzung dafür ist eine durchgängige Orientierung am Objektmodell für Datenbank-Systeme, Designtools und Benutzerschnittstelle.
Klassische Datenbanken arbeiten heute meist überwiegend als relationale Datenbank (RDBMS). Das heißt, die Daten liegen in Tabellen vor, die für die Verarbeitung in verschiedenen Beziehungen (Relationen) zueinander gesetzt werden. Der Inhalt dieser Tabellen ist üblicherweise auf einfache Texte und Zahlen beschränkt, wobei auch Erweiterungen natürlich auch Erweiterungen gibt, die erlauben, alles mögliche bis hin zu Bildern einzubinden. Die Integration komplexerer Daten ist dabei in vielen Fällen nicht sonderlich transparent - sie bleibt meist eine arbeitsintensive Ausnahme.
Drei objectorientierte Detenbanken im Vergleich
Objektorientierte Datenbanken, so das Versprechen der Hersteller, können beinahe jeden Input verarbeiten, denn schließlich verwalten sie Objekte und nicht nur ein paar einfache Datentypen. Der Objektbegriff bleibt hier etwas nebulös. Nimmt man die Spezifikationen diverser obiektorientierter Datenbanken (OODBMS) etwas genauer unter die Lupe, so stellt man schnell fest, daß es sich bei einigen Produkten um des Kaisers neue Kleider handelt.
Ein richtiges OODBMS sollte nicht nur mit ein paar neuen Datentypen ausgestattet sein.
Derartiges wäre auch mit einer relationalen Datenbank machbar. Für echte Objektorientierung ist es vielmehr notwendig, daß Objekte beliebige andere Objekte enthalten können und auch Prozeduren (im OO-Jargon: Methoden) müssen innerhalb der Objekte abzulegen sein. Die Beziehung von Objekten zueinander, sowie die Bearbeitungsmethoden sollten also in der Datenbank vereint und nicht, wie heute üblich, in RDBMS und Datenbankabfragesprache (4GL) getrennt sein.
Die Objekte liegen üblicherweise in einer Hierarchie vor, so daß jedes Objekt mindestens ein Elternteil hat. Diese Hierarchie ist im Normalfall eine zweidimensionale Baumstruktur. Eltern vererben dabei all ihre Eigenschaften an die Kinder. Hat ein Objekt mehr als ein Elternteil von dem es seine Basiseigenschaften erbt, so spricht man von multipler Vererbung. Eine objektorientierte Datenbank läßt sich als ein zweidimensionaler Stammbaum darstellen, der durch Hinzufügen von Daten in eine dritte Dimension wächst.
Die Anzahl der Anbieter von OODBMS hält sich nach wie vor in Grenzen. Dafür gibt es gute Gründe. Einerseits setzen diese Systeme leistungsfähige Hardware voraus, um ihre Features voll ausspielen zu können, und andererseits ist es nicht ganz trivial, einen völlig neuen Produkttypen zu entwickeln und auf den Markt zu bringen.
Es gibt diverse Ebenen, auf denen Produkte im Bereich der OODBMS angeboten werden. Die im folgenden genannten Produkte sind als Beispiele zu sehen. Auf unterster Ebene begegnet man Bibliotheken für objektorientierte Sprachen (C + +, Smalltalk) wie beispielsweise Poet von der Berliner BKS Software. Poet ist eine Bibliothek von "C + +" Funktionen, die es dem Anwendungsentwickler erlauben eine objektorientierte Datenbank in seine Applikation zu integrieren. Damit steht einerseits die volle Flexibilität von "C + +" zur Verfügung, andererseits wird vom Entwickler die Beherrschung einer zwar objektorientierten, aber dennoch sehr primitiven Sprache verlangt. Tools für das Applikationsdesign stehen nicht zur Verfügung.
Einen Schritt weiter ist "Ontos", in Deutschland von Gopas, München vertrieben. Hier bekommt der Kunde ein Datenbank-Designtool, das unter einer grafischen Benutzeroberfläche das Design der Datenbank unterstützt. Daraus werden entsprechende C + + -Programme erzeugt, die man dann noch mit eigenen Routinen "aufbohren" kann.
Für das Design der Benutzerschnittstelle ist ein weiteres Ontos-Werkzeug zuständig. Totz dieser Hilfsmittel sind für den Entwickler nach wie vor Basiskenntnisse von C + + Voraussetzung. Ein weiterer Nachteil ist der Zwang, Applikationen compilieren zu müssen. Interaktives Design mit sofortigem Austesten wird damit unmöglich.
Wer sich einen Level höher begibt, stößt auf "Gemstone" von Servio-Produkte, die hierzulande von Georg Heeg, Dortmund, vermerktet werden.
Gemstone benutzt ebenfalls eine objektorientierte Sprache als Basis: Smalltalk. Sie wird in diesem Falle aber nicht als zugrundeliegendes Programmiersystem eingesetzt, sondern dient als Datenbanksprache, statt SQL oder einer 4GL wie bei den meisten RDBMS.
Wie auch bei Ontos, ist es unter Gemstone möglich, in verteilten Umgebungen zu arbeiten, da die immer stärker verbreitete Client-Server-Architektur unterstützt wird. Für Gemstone steht zudem ein grafisches Designtool für den Aufbau und die Wartung der Datenbank zur Verfügung. Ein ähnliches Tool für die Erstellung von Benutzerschnittstellen ist in Vorbereitung.
Eine zentrale Eigenschaft von Gemstone liegt darin, daß Datenbankprogramme als Smalltalk-Objekte abgelegt werden. Damit ist die Trennung zwischen Datenbank und Programmiersprache nicht mehr so scharf wie bei den oben genannten Tools. Da Gemstone mit einem Precompiler beziehungsweise Interpreter für die Sprache arbeitet, ist ein interaktives Austesten der Datenbank ohne weiteres möglich. Die gute Integrierbarkeit in eine Smalltalk-Umgebung ist ein weiterer Pluspunkt, der den Entwicklungsaufwand reduziert.
Allen bisher exemplarisch vorgestellten Systemen ist ein gemeinsames Manko zueigen. Sie müssen in klassischem Sinne programmiert werden und setzen ein hohes Maß an DV-Kenntnissen voraus. Der große Vorteil objektorientierter Systeme soll aber sein, daß sie die Realität direkt in Objekten abbilden und damit leichter zu begreifen und bedienen sind. Zu erwarten wäre also ein System, bei dem nicht mehr programmiert werden muß, in dem Applikationen einfach durch Abbildung von realen Vorgängen auf ein Objektmodell entstehen.
Das Kieler Softwarehaus PBS Professional Business Software bietet mit "Hyperwork" ein OODBMS an, das dieser Anforderungen gerecht werden soll. Design, Kodierung und Integration sollen vermieden werden, die interaktive Erarbeitung des Pflichtenheftes ist die einzige Vorstufe zum Ergebnis. Die Applikationen können Herstellerangaben zufolge per Maus durch die Verknüpfung von Objekten erstellt werden. Auf ähnliche Weise erfolgt die Anpassung an neue Gegebenheiten.