Beitragsseiten

 

4.3 Objektorientierte Datenbanken

Ein objektorientiertes Datenbankmanagementsystem ist ein DBMS mit einem objektorientierten Datenmodell. Diese Definition impliziert zwei Sachverhalte (GÜNTHER 1998, S. 111):

  1. Ein OODBMS enthält die volle Funktionlität eines modernen DBMS und bietet Merkmale wie Sekundärspeicherverwaltung, parallelen Zugriff mehrerer Benutzer, Recovery, Unterstützung von ad hoc-Abfragen, verteilte Datenbanken und Integritäts­bedingungen.

  2. Ein OODBMS bietet die Merkmale objektorientierter Systeme wie Objektidentitäten, Klassen und Vererbung, komplexe Objekte und benutzerdefinierte Datentypen.

Mit strukturell objektorientierten DBMS können beliebig komplexe Objekte modelliert werden, während verhaltensmäßig objektorientierte Systeme die Definition von Typen mit eigenen Methoden erlauben. Voll objektorientierte Systeme unterstützen sowohl strukturelle als auch verhaltensmäßige Merkmale (FRITSCH/ANDERS 1996, S. 7).

Durch die zunehmende Bedeutung neuer Anwendungsbereiche wie GIS, CAD, Bildver­arbeitung oder Automatisierungstechniken (Computer Aided Manufactoring - CAM), den sog. Nicht-Standard-Anwendungen, werden an die Datenbanktechnik Anforderungen hin­sichtlich der Flexibilität und Strukturierung gestellt, die konventionelle Systeme wie die relationalen DBMS nicht erfüllen können. Die auf dem Objektmodell basierenden Systeme bieten diese geforderten Merkmale: Bildung komplexer Objekte, Schnittstellen zu objektorientierten Programmiersprachen und weitestgehend redundanzfreie Daten­modellierung (ROCHE 1996, S. 6f.).

In der Praxis können OODBMS als eine Erweiterung von objektorientierten Programmier­sprachen angesehen werden, da die meisten Systeme direkt auf die Anbindung an eine Sprache wie C++, Java oder Smalltalk aufbauen (FRITSCH/ANDERS 1996, S. 6). In einem normalen Softwaresystem werden Objekte zur Laufzeit des Programms erzeugt und stehen spätestens zu dem Zeitpunkt nicht mehr zur Verfügung, an dem das Programm be­endet wird. Sollen die in einem Objekt gekapselten Daten auch zu einem späteren Zeit­punkt verfügbar sein, müssen sie zunächst auf einen Sekundärspeicher geschrieben werden. Objektorientierte Datenbanksysteme bieten hierzu die Möglichkeit, den Inhalt der Objekte in einer speziellen Struktur abzulegen, mit deren Hilfe es möglich ist, nicht nur einfache Datentypen wie Zahlen und Zeichenketten sondern auch Referenzen zwischen Objekten dauerhaft zu speichern. Wird dann ein Objekt aus der Datenbank gelesen, prüft das Datenbanksystem, ob sich die von diesem Objekt referenzierten Instanzen bereits im Arbeitsspeicher befinden und liest diese gegebenenfalls dorthin aus. Die gespeicherten Referenzen werden dann in Adressen des Arbeitspeichers umgewandelt, die die Stelle bezeichnen, an der das Objekt nun vorliegt und über die man jetzt auf das Objekt zu­greifen kann (SCHADER 1997 , S.13).

Im Unterschied zu relationalen Datenbanken fehlten objektorientierten Datenbank­systemen lange Zeit eine klare theoretische Fundierung und entsprechende Festlegungen, über welche Eigenschaften ein objektorientiertes Datenbankmanagementsystem verfügen muß. Erste Ansätze dazu lieferten ATKINSON u.a. 1992, indem sie obligatorische und optionale Merkmale erstmals publizierten. Um auf dem kommerziellen Datenbanksektor einen Standard aufzustellen, haben sich mehrere Hard- und Softwarehersteller (z.B. IBM, Poet, ONTOS, O2) zur „Object Database Management Group“ (ODMG) zusammenge­schlossen. Dabei werden mit dem Standard vorrangig zwei Ziele verfolgt:

  • Ein standardkonformes Anwendungsprogramm soll ohne Änderung des Sourcecodes auf unterschiedlichen Datenbankprodukten und in verschiedensten Hard- und Software­umgebungen übersetzbar und lauffähig sein.

  • Auf die Datenbanken sollen in verschiedenen Programmiersprachen entwickelte An­wendungsprogramme gleichzeitig zugreifen können. Momentan stehen hier die objektorientierten Programmiersprachen C++ und Java im Vordergrund, vereinzelt wird auch Smalltalk unterstützt.

Die Standardisierung betrifft lediglich die Schnittstelle, über die die Produkte ange­sprochen werden können, wobei die Art der internen Datenverwaltung voneinander ab­weicht. Grundbestandteile des Standards sind ein Objektmodell, die Objektdefinitions-Sprache ODL (Object Definition Language) und die Anfragesprache OQL (Object Query Language) (SCHADER 1997, S. 1ff.; HELOKUNNAS 1994, S. 1201f.).

Das ODMG-Objektmodell spezifiziert, welche Softwareeinheiten in der Datenbank ge­speichert werden können und welche Merkmale objektorientierter Systementwicklung anwendbar sind. Der Standard unterstützt Vererbungsstrukturen und verwendet diesen Mechanismus, um Objekte benutzerdefinierter Klassen persistenzfähig zu machen. Dazu ist eine Klasse d_Object definiert, die über Fähigkeiten zum Schreiben und Lesen seiner Datenfelder verfügt und damit als Superklasse für alle benutzerdefinierten persistenten Klassen dient. Jedes persistente Objekt erhält vom Datenbanksystem eine eindeutige Identität, die für die gesamte Lebensdauer des Objekts gültig bleibt, auch wenn sich des­sen Eigenschaften ändern. Die Eigenschaften der Objekte können mit Hilfe von Literalen (long, short, float, double, string usw.) sowie über Beziehungen zu anderen Objekten be­schrieben werden. Neben diesen atomaren Objekten sind auch diverse Collection-Typen, d.h. Objektmengen, definiert (set, bag, list, array), die sich darin unterscheiden, ob die Menge geordnet ist und ob Duplikate gestattet sind (SCHADER 1997, S. 10 ff.).