Ob­jekt­ori­en­tier­te Datenbank: Der Ge­heim­tipp unter den Da­ten­bank­mo­del­len

Die meisten Menschen, die re­gel­mä­ßig mit Da­ten­ban­ken zu tun haben – zum Beispiel in der Soft­ware­pro­gram­mie­rung, bei der Web­ent­wick­lung oder im Bi­blio­theks­we­sen – arbeiten mit re­la­tio­na­len Da­ten­ban­ken, be­zie­hungs­wei­se mit ent­spre­chen­den Da­ten­bank­ma­nage­ment­sys­te­men (DBMS) wie MySQL oder MariaDB. Doch es gibt auch Al­ter­na­ti­ven: Ob­jekt­ori­en­tier­te Da­ten­ban­ken (auch als Ob­jekt­da­ten­ban­ken bekannt) sind zwar nur selten im Einsatz, können aber einige Projekte enorm wei­ter­brin­gen.

Das ob­jekt­ori­en­tier­te Da­ten­bank­mo­dell schnürt quasi zu­sam­men­ge­hö­ri­ge Pakete: Ein Datensatz wird mit all seinen At­tri­bu­ten zu einem Objekt zu­sam­men­ge­fasst. So sind alle In­for­ma­tio­nen direkt verfügbar. Statt also alles auf ver­schie­de­ne Tabellen zu verteilen, sind die Daten gebündelt abrufbar. Neben den At­tri­bu­ten werden in den Objekten auch Methoden ge­spei­chert. Hierbei wird die Nähe der Da­ten­ban­ken zu ob­jekt­ori­en­tier­ten Pro­gram­mier­spra­chen klar. Wie bei der Pro­gram­mier­wei­se hat jedes Objekt bestimmte Ak­ti­vi­tä­ten, die es ausführen kann.

Objekte wiederum werden zu Klassen zu­sam­men­ge­fasst. Oder genauer for­mu­liert: Ein Objekt ist eine konkrete Einheit einer abs­trak­ten Klasse. Hierdurch entsteht eine Hier­ar­chie aus Klassen und Un­ter­klas­sen. Innerhalb dieses Kon­strukts ist es so, dass Un­ter­klas­sen die Ei­gen­schaf­ten von über­ge­ord­ne­ten Klassen annehmen und durch eigene Attribute ergänzen. Gleich­zei­tig können Objekte einer Klasse auch mit anderen Klassen verbunden sein. Dies bricht die strenge Hier­ar­chie auf und sorgt für eine Ver­net­zung. Einfache Objekte lassen sich zu komplexen Objekten zu­sam­men­fas­sen.

Um die ver­schie­de­nen Objekte an­zu­spre­chen, vergibt das ent­spre­chen­de ob­jekt­ori­en­tier­te DBMS jeder Einheit au­to­ma­tisch eine einmalige Iden­ti­fi­ka­ti­on. So kann man Objekte leicht wieder aufrufen, nachdem diese ge­spei­chert wurden.

Ein Beispiel: Im Sinne einer ob­jekt­ori­en­tier­ten Einheit speichern wir das konkrete Objekt eines Fahrrades mit all seinen Ei­gen­schaf­ten und Methoden. Es ist rot, kann fahren, hat einen Sattel, und so weiter. Dieses Objekt ist gleich­zei­tig Teil der Klasse „Fahrräder“. Innerhalb derselben Klasse können bei­spiels­wei­se auch ein blaues und ein grünes Rad zu finden sein. Die Klasse „Fahrräder“ ist wiederrum eine Un­ter­ka­te­go­rie von „Fahrzeuge“, zu der auch „Autos“ gehört. Gleich­zei­tig hat das Objekt aber auch eine Ver­bin­dung zur Klasse „Frei­zeit­ak­ti­vi­tä­ten“. Rufen wir unser Objekt über die ein­zig­ar­ti­ge ID auf, stehen alle Attribute und Methoden direkt zur Verfügung.

Wie gesagt sind re­la­tio­na­le Da­ten­ban­ken seit längerer Zeit der Standard in der Web- und Soft­ware­ent­wick­lung. Bei diesem Modell werden In­for­ma­tio­nen in un­ter­ein­an­der ver­knüpf­ten Tabellen ab­ge­spei­chert. Auch hierbei können durch die Ver­knüp­fun­gen kom­ple­xe­re In­for­ma­tio­nen aus ver­schie­de­nen Be­stand­tei­len ab­ge­spei­chert und abgerufen werden. Bei einer Ob­jekt­da­ten­bank sind aber alle Be­stand­tei­le der Einheit auch sofort verfügbar. Das lässt außerdem zu, dass die Da­ten­sät­ze sehr viel komplexer sein können. Bei einer re­la­tio­na­len Datenbank versucht man eher, einfache In­for­ma­tio­nen un­ter­zu­brin­gen. Je komplexer der Datensatz wird, desto um­fang­rei­cher sind die Ver­knüp­fun­gen un­ter­ein­an­der. Das bremst die Datenbank aus.

Es hängt sehr stark vom An­wen­dungs­fall ab, für welchen Da­ten­bank­typ man sich ent­schei­den sollte. Gerade wenn man ohnehin mit ob­jekt­ori­en­tier­ten Pro­gram­mier­spra­chen wie bei­spiels­wei­se Java arbeitet, ist eine Ob­jekt­da­ten­bank vor­teil­haft. Die Objekte des Quell­codes können einfach in die Datenbank auf­ge­nom­men werden. Greift man hier zu einer re­la­tio­na­len Datenbank, was durchaus nicht unüblich ist, lassen sich gerade komplexe Objekte nur schwer in das Ta­bel­len­kon­strukt ein­glie­dern.

Ein Nachteil ist vor allem die schlechte Ver­brei­tung. Obwohl das Modell seit den 1980ern bekannt ist, haben sich bisher nur wenige DBMS für Ob­jekt­da­ten­ban­ken etabliert. Ent­spre­chend klein ist auch die Community, die sich mit dem Modell be­schäf­tigt. Die meisten Ent­wick­ler greifen deshalb lieber zu den weit­ver­brei­te­ten, gut do­ku­men­tier­ten und hoch ent­wi­ckel­ten re­la­tio­na­len Da­ten­ban­ken.

Was in be­stimm­ten Si­tua­tio­nen ein Vorteil ist, kann in anderen wiederum zu einem Nachteil werden: Die Kom­ple­xi­tät der Objekte sorgt dafür, dass ebenfalls komplexe Anfragen und Schreib­vor­gän­ge viel schneller als in re­la­tio­na­len Modellen vor­ge­nom­men werden können. Sind die Vorgänge aber ver­gleichs­wei­se simpel, muss dennoch mit der komplexen Struktur ge­ar­bei­tet werden. Das führt zu Ge­schwin­dig­keits­ein­bu­ßen.