Objektorientierte Datenbanken haben ihren Ursprung in der objektorientierten Programmierung und den relationalen Datenbanksystemen.
Außerdem gibt es eine Reihe diverser objektorientierter Datenbanksysteme (beispielsweise
"O2" von Ardent Software oder "Jasmine" von Computer Associates), die von Grund
auf neu entwickelt wurden, um speziellen Anforderungen gerecht zu werden.
Bei der objekt-orientierten Programmierung war es den Menschen ein Anliegen effektive Wiederverwertbarkeit von Programmteilen oder gar ganzer Softwarepakete zu erreichen, die logisch gegliedert und für sich selbst abgeschlossen sind. Objektorientierte Programmierung geht bis zurück in die 60er Jahre, wo mit SIMULA 1967 der Grundstein in diese Richtung gelegt wurde. Sprachen wie Smalltalk, Objective-C, Eiffel, C++ und andere folgten ihr.
Aus unser heutigen Welt sind objektorientierte Sprachen kaum noch wegzudenken und erfreuen sich heute mehr denn je großer Beliebtheit.
Meersman, Kent und Khosla meinen dazu folgendes:
"It is not uncommon that Object-Oriented software engineers design objects by personifying them or even identifying themselves with the object! ('If I am this window then that display message will make me show myself on the screen …')"
Es stellt sich natürlich nun die Frage nach der Verbesserung die wir durch die Verwendungen des objektorientierten Ansatzen in Bezug auf Datenbanken erreichen bzw. was denn an herkömmlichen relationalen Datenbanken verkehrt sei.
Nun, bisherige Datenbankmodelle, insbesondere das Relationenmodell, sind für viele Anwendungen sehr gut einsetzbar. Sie stellen effiziente Konstruktion für die Organisation von Daten dar und unterstützen durch ihre Systemfunktionen weitgehend die Synchronisation quasiparalleler Transaktionen und die Datensicherheit.
Für datenintensive, komplexe Anwendungen, wie sie insbesondere bei CAD/CASE-Anwendungen und des CASE vorkommen, sind jedoch die Möglichkeiten der Datenmodellierung zu sehr eingeschränkt. Datenobjekte können nur als Tupel einfacher, unstrukturierter Attribute dargestellt werden. Komplexere Integrationsbedingungen lassen sich nicht unmittelbar beim logischen Entwurf des Datenmodells einbringen. Meist werden werden diese dann als zusätzliche Prozeduren formuliert.
Ein zusätzliches Problem ergibt sich durch die mit Normalisierung verbundene Aufsplittung in viele einzelne Relationen, die zu vielen Externspeicherzugriffen und lang andauernden Transaktionen führen kann.
Beispiel:
| ISBN | TITLE | AUTOR |
| 112233 | Ein gutes Omen | Terry Pratchett |
| 112233 | Ein gutes Omen | Neil Gaiman |
| 456777 | Die Differenz Maschine | William Gibson |
| 456777 | Die Differenz Maschine | Bruce Sterling |
Durch Normalisierung erhalten wir:
|
|
Echtzeit-Anwendungen im Bereich der Automatisierung von schnellen technischen Prozessen sind somit kaum möglich.
Im Gegenzug dazu bieten objektorientierte Programmiersprachen beispielsweise ein Höchstmaß an Abstraktionsmöglichkeiten und stellen umfassende Konzepte für die Datenmodellierung zu Verfügung. Es ist daher nahe liegend, den objektorientierten Ansatz auch für Datenbanksysteme zu nutzen.
Objektorientierte Programmiersprachen
|
Erweiterung um Datenbankkomponenten wie Speicherung von Objekten, um für Datenbanken wichtige Operatoren sowie um Speicherstrukturen für Mengen von Objekten. Die Fähigkeiten der Programmiersprachen werden nur zur Beschreibung des Verhaltens von Objekten genutzt. Die komplexe Struktur der Objekte wird hingegen mit herkömmlichen Mitteln beschrieben. Solche Datenbanksysteme werden als optional oder verhaltensmäßig objektorientiert bezeichnet. "ObjectStore" der Firma ‚Object Design' sowie "POET" von der Firma ‚POET' sind Produkte dieser Art. Im Allgemeinen sind heutige Produkte für C++, SmallTalk oder auch JAVA konzipiert. Ziel ist es, bei der Aktualisierung der Objekte möglichst effizient zu sein, indem Objekte persistent auf dem Hintergrundspeicher verwaltet werden. |
Relationale DBs
| Schrittweises hinzufügen objektorientierter Konzepte wie Typkonstruktoren, Objektidentität, Klasses usw. Bei diesem Ansatz wird speziell die komplexe Struktur von Anwendungsobjekten berücksichtigt. Die Beschreibung des Verhaltens wurde hingegen oft vernachlässigt. Diese Art von Datenbanksystemen bezeichnet man als strukturell objektorientiert. |