Databases Reference
In-Depth Information
21
C H A
P
I
T
R
E
I
N
F
I
N
I
Objektdatenbanken
Die Kapitel 18.3 und 19 haben uns gelehrt, dass wir Objekte aufgrund des Impe-
dance Mismatch nur über Umwege in relationale Datenbanken speichern können.
Sie müssen dazu möglicherweise in viele Einzelteile zerlegt werden, um dann
mit Hilfe komplexer
select
-Anweisungen wieder zusammengesetzt zu werden.
Doch gibt es so genannte Objektdatenbanksysteme (ODBMS), die Objekte auch
ohne weitere Zerlegung als Objekte verwalten und persistieren. Dieser Ansatz
wirkt für objektorientierte Datenbankanwendungen sehr natürlich. Bereits in den
Kindertagen der relationalen Systeme gab es erste ODBMS, und zeitweilig wirkte
es so, als ob diese Variante eines DBMS sich mindestens wie relationale Systeme
verbreiten könnte. Warum das nicht geschehen ist, erfahren wir, nachdem wir die
Grundkonzepte eines ODBMS gelernt und einfache praktische Erfahrungen ge-
sammelt haben.
21.1
Das Manifest
Grundsätze für ODBMS, die ein wenig an das Coddsche Regelwerk erinnern,
wurden bereits Ende der 1980er-Jahre - also etwa 10 Jahre bevor objektorientier-
te Sprachen populär wurden - im „Object-Oriented Database System Manifesto“
[Atk89] zusammengetragen. Die Anforderungen an Objektdatenbanken, die wir
im Manifest finden, können eingeteilt werden in solche, die ihre Wurzeln im ob-
jektorientierten Paradigma haben, und solche, wie wir sie in Kapitel 1 für allge-
meine DBMS diskutiert haben.
ODBMS müssen also die objektorientierte Denkweise und insbesondere die fol-
genden Konzepte unterstützen.
Abstraktion:
Der Anwender eines ODBMS muss die Möglichkeit zur Abstrakti-
on haben. Er kann ähnliche Objekte zu selbstdefinierten Typen wie zum Beispiel
