Dieser Exkurs kann keine vollständige Darstellung von objekt-orientierten Datenmodellen und objekt-orientierten Datenbankmanagementsystemen (ODBMS) sein.
Das angestrebte Ziel dieses Exkurses ist, einen Überblick über ODB zu schaffen und aufzuzeigen, aus welcher Motivation heraus, die Notwendigkeit des Einsatzes von ODBMS liegen.

1. Motivation von ODBMS
2. Kennzeichen von objektorientierten Datenmodellen
3. Der ODMG Standard 2.0 für ODBMS
4. Persistenzmechanismen

---

1. Motivation von ODBMS

 
Die Motivation, ODBMS einzusetzen liegt sicherlich in der Entwicklung und der wachsenden Bedeutung der Objektorientierung in der Informatik allgemein.
Betrachtet man die wachsende Bedeutung der Objektorientierung in den unterschiedlichen Teilgebieten der Informatik, wie z.B.
• objektorientierte Analyse und Design in der Softwareentwicklung mit den unterschiedlichen Notationen OMT und UML
• objektorientierte Programmiersprachen wie JAVA, C++, SmallTalk u.v.m
Es hat sich gezeigt, daß das relationale Datenmodell bei der Speicherung von Objekten Schwächen besitzt.
Es ist zwar möglich, eine Klassenhierachie in ein relationales Datenmodell zu transformieren, indem man folgende Annahmen trifft :
• Klassen entsprechen Entities
• Attribute entsprechen Entity-Attributen
• Objekte entsprechen Entity-Sets
• Objektreferenzen entsprechen Fremdschlüssel aus anderen Entities
Jedoch wird an dieser Stelle schon deutlich, daß nur der Zustand eines Objektes in einem RDBMS gespeichert wird. Das Verhalten, welches durch Methoden der Klassen gekennzeichnet ist, bleibt unberücksichtigt.
Weiterhin bleiben die Vererbungsmechanismen unberücksichtigt, die in der Objektorientierung eine sehr entscheidende Rolle übernehmen.
Der Nachteil einer Transformation liegt also im Prinzip darin, daß Informationen „verloren" gehen (z.B. Verhalten eines Objektes) oder überhaupt nicht bzw. nur mit erheblichen Aufwand modelliert werden können (z.B. Klassenhierachien, die bei der Vererbung entstehen).
Deswegen ist es wünschenswert, die Objekte ohne Transformationen in einer Datenbank zu speichern.
Aus diesem Wunsch heraus entstanden die ODBMS, die die Speicherung von Objekten ermöglichen.

---

2. Kennzeichen von objektorientierten Datenmodellen

 
Wesentliche Modellierungs - Eigenschaften für ein objektorientiertes Datenmodell nach Vossen :
• Darstellbarkeit komplexer Objekte
• Objekte mit einer eigenen Objektidentität · Schema einer Datenbank besteht aus Klassen, deren Attribute von einem bestimmten Typ sind
• Klassen können in einer Vererbungshierachie angeordnet werden und sich darüber hinaus gegenseitig (auch zyklisch) referenzieren
• Möglichkeit der Kapselung von Struktur und Verhalten eines Objektes Typen als Abstrakte Datentypen beschreibbar
• Polymorphie in der Vererbungshierachie
• vordefinierte und benutzerdefinierte Typen werden gleich behandelt

---

3. Der ODMG Standard 2.0 für ODBMS

 
Lange Zeit existierte kein Standard für ODBMS.
Verschiedene Hersteller von DBMS entwickelten unterschiedliche Ansätze, z.B.:
• Oracle erweiterte den SQL-2 Standard um zusätzliche Sprachkonstrukte für Kollektionen und Bags Þ solche DBMS werden als objekt-relational bezeichnet.

Dieser Ansatz hat aber den Nachteil, daß Vererbungen weiterhin nicht modelliert werden können
• ObjectDesign besitzt kein festes Objektmodell.

Das Objektmodell wird durch die Klassenhierachie beschrieben.
Dieser Ansatz ist sicherlich der Flexibelste.
 
Aus diesen beiden Ansätzen wird schon deutlich, daß eine Standardisierung notwendig ist, da durch die unterschiedlichen Ansätze auch unterschiedliche Objektmodelle entstanden.
Diese Standardisierung erfolgte nun durch die ODMG (Object Data Management Group) mit der Veröffentlichung des ODMG 2.0 Standards im Juli 1997.

Die ODMG ist eine aus mehreren DBMS - Herstellern zusammengesetzte Gruppe, die als Hauptziel verfolgt, einen „führenden Industriestandard für Objektspeicherung zu entwickeln".

Die Standardisierung stellt eine Schnittmenge aus 3 bereits bestehenden Standards dar :

• Datenbanken mit SQL - Standard
• Objekte mit OMG - Standard (CORBA,IIOP)
• objektorientierten Programmiersprachen (C++, SmallTalk, JAVA)
Die Spezifikation beinhaltet :
• ein Objektmodell
• Objektdefinitionssprache (Object Definition Language ODL)
• Objektabfragesprache (Object Query Language OQL) (auch mit Ziel eine Kompatibilität zu SQL-3 zu schaffen)
• Programmiersprachen - Verpflichtung (Language Bindings)
Hier erkennt man ein Analogie zur Standardisierung im Zusammenhang mit RDBMS :
• relationales Datenmodell
• Datendefinitionssprache (Data Definition Language DDL)
• Abfragesprache (Structure Query Language SQL)
• Schnittstellenspezifikation SQL Call Level Interface
Steht eine Implementierung der geforderten Spezifikation eines ODBMS zu Verfügung, so wird es als ODMG-kompliant zertifiziert als Zeichen, daß der Standard unterstützt wird. 

---

4. Persistenzmechnismen

 
Es existieren unterschiedliche Möglichkeiten, Objekte in einer Datenbank persistent zu machen.
• persistent (persistent - capable) :

Der Begriff definiert die Fähigkeit eines Objektes, in der Datenbank gespeichert zu werden. Um die Instanzen einer Klassen jedoch in einer Datenbank speichern zu können, müssen Modifikation an der Klassendefinition vorgenommen werden.
• persistent - bewußt (persistent - aware) :

Eine Klasse ist „persistent-bewußt", wenn deren Methoden direkt auf Instanzvariablen eines persistenten Objektes zugreifen können. Auch in diesem Fall sind spezielle Erweiterungen nötig, die sicherstellen, daß die entsprechenden Instanzvariablen vom Sekundärspeicher in den Hauptspeicher transferiert werden können ( und umgekehrt).
Werden anstelle des direkten Zugriffs jedoch auf die Instanzvariablen über „get"- bzw. „set"-Methoden des persistenten Objektes zugegriffen, so sind die Erweieterungen nicht notwendig.
• transitive Persistenz (transitive persistence / Persistence by reachability) :

Dieser Begriff bechreibt den Mechanismus, daß nach der Bestätigung einer Transaktion durch „commit" alle (veränderten) Objekte in die Datenbank geschrieben werden, die von einem persistenten Objekt referenziert werden.
Es reicht im Prinzip also aus ein Objekt alas Datenbank-Wurzel zu speichern, und alle von diesem Objekt über Referenzen erreichbaren Objekte werden ebenfalls in der Datenbank gespeichert.
Man sieht in diesem Fall, daß auch transiente Objekte persistent gespeichert werden können. Der Übergang von transient zu persistent hängt von den Referenzen des Objektes ab.
Beim Zugriff auf ein persistentes Objekt während einer Transaktionen existieren zwei gleiche Objekte :
• das eigentliche Objekt in der Datenbank
• eine Kopie im Hauptspeicher
Das im Hauptspeicher befindliche Objekt kann einen der folgenden Zustände besitzen:
• aktiv (active) : das persistente Objekt befindet sich in einem initialisierten Zustand (z.B. durch Laden des Objektes aus der DB) veränderten Zustand (z.B. durch eine abgeschlossene Transaktion)
• hohl (hollow) : die Variablen des persistenten Objektes wurden mit Nullwerten initialisiert.

Beim Aktivieren von Objekten (z.B. Laden in den Hauptspeicher) werden in der Regel bei Referenzen nur deren hohle Stellvertreter erzeugt. Referenzen auf aktive und hohle Objekte sind gültig.
• verbraucht (stale): ein persistentes Objekt gilt als verbraucht, nachdem man es explizit aus der Datenbank gelöscht hat eine Transaktion beendet wurde.

Eine Referenz auf ein verbrauchtes Objekt ist nicht gültig und wird somit vom Garbage Collector „eingesammelt".

Last Updated on $Date: 1998/08/18 20:34:50 $