Wie funktionieren objektorientierte Datenbanken?
Wie eine objektorientierte Datenbank arbeitet, zeigt etwa das Beispiel "ObjectStore" der Firma Progress: Bei dieser Datenbank ist die Persistenz (Speicherung) eines Objekts nicht als Eigenschaft der Klasse definiert. Vielmehr wird ein Objekt bei seiner Instanziierung (Erstellung) als persistent oder transient festgelegt. Beispielsweise wird in der Programmiersprache C++ ein Objekt einer Klasse mit dem "new Operator" angelegt. Wenn diesem Operator ein "Persistenzparameter" übergeben wird, ist dieses Objekt damit sofort in der Datenbank gespeichert.
Eine transiente oder persistente Instanz eines gleichen Objekts unterscheidet sich dadurch, dass sich das transiente Objekt nur im Hauptspeicher des Rechners befindet, das persistente Objekt identisch in der Datenbank. Gleichzeitig lässt sich das persistente Objekt als transientes bearbeiten. Seine Attribute kann man durch einfache Wertzuweisungen direkt in der Datenbank verändern. Da sich das persistente Objekt in der Datenbank befindet, kann die Veränderung natürlich nur über eine Datenbank-Transaktion erfolgen. Am Ende der Transaktion sind die Veränderungen in der Datenbank gespeichert. Bricht die Transaktion ab, führt ein "Roll Back" das Objekt in seinen Ursprungszustand zurück.
Der Programmcode unterscheidet nicht, ob es sich um transiente oder persistente Objekte handelt. Einen expliziten Lese- oder Schreibvorgang gibt es nicht. Ein Objekt ist im Quellcode des Programms über eine nicht leere Variable verfügbar oder eben nicht. Ein weiterer entscheidender Unterschied besteht darin, dass das persistente Objekt in der Datenbank liegt und beliebig viele weitere persistente Objekte erzeugt werden können.
Nur, wie findet man diese Objekte wieder? Objekte werden nicht per se in Tabellen abgelegt. Jedes Objekt steht für sich als individuelle Einheit allein. Hier muss der Entwickler selbst aktiv werden. Aber das ist ein nicht zu unterschätzender Vorteil.
Die scheinbare Exotik objektorientierter Datenbanken löst sich auf, wenn man sie als "OR-Mapper mit integrierter Datenbank" oder als "Object Broker" bezeichnet.
Abbildung komplexer Klassenmodelle
-
Eingebettete Klassen (zum Beispiel Zahlen-Klassen mit Einheiten für Mengen- oder Wertangaben)
-
Eingebettete Objektrelationen, bei denen ein (Ursprungs-)Objekt auf beliebig viele (Gegen-)Objekte verweisen und jedes Gegen-Objekt auf beliebig viele Ursprungs-Objekte zurückverweisen kann (zum Beispiel zur Verknüpfung von Vorgänger- und Nachfolgerbelegen in Geschäftsprozessen)
-
Polymorphe Relationen (Relationen auf verschieden vererbte Tabellen) und um eigene Eigenschaften erweiterbare Relationen (Wrapper)
-
Gültigkeitseigenschaften von Objekten, OLAP-Datenwürfeln und so weiter
Ein Anwendungsmodell kümmert sich nicht um die Speicherung eines Objekts, was letztlich als große Freiheit gelten darf: Zwar werden die Modelle dadurch abstrakter und komplexer, aber auf der Anwendungsseite führt das zu mehr Flexibilität. Metainformationen lassen sich dabei über Hierarchien vererben.