Michael Klein
[email protected]
N-K-I
Vorlesung
Informationssysteme: „Neuere Konzepte“
Persistenz von Objekten
Dipl.-Inform. Michael Klein
[email protected]
Dipl.-Inform. Heiko Schepperle
[email protected]
1/56
Michael Klein
[email protected]
N-K-I
Details zu Teil I
I-1: Web und Datenbanken
 1. Webinformationssysteme, JSP
 2. Praktische Übung zu JSP
 3. Komponentenarchitekturen, EJB
 4. Web Services & Fragestunde
I-2: Objektorientierte Datenbanksysteme
 1. Persistenz von Objekten
2/56
Michael Klein
[email protected]
N-K-I
Persistenz von Objekten
 Problem: Objekte einer objektorientierten
Programmiersprache (wie Java) sind transient
 Bei Programmende verloren
 Aber: Viele Anwendungen benötigen die Erhaltung
bestimmter Objekte über das Programmende
hinaus. Beispiele: Kundenobjekte, Bestellungsobjekt
 Ziel daher: persistente Objekte
3/56
Michael Klein
[email protected]
Anforderungen an Objektpersistenz
N-K-I
Gewünschte Eigenschaften der Persistenz:
4/56

Transparenz

Interoperabilität

Skalierbare Wiederauffindbarkeit

Mehrbenutzer, Konflikterkennung, Verteilung
Benutzer arbeiten in gleicher Weise mit transienten und
persistenten Objekten. Persistenz erfordert keine
Sonderbehandlung bei der Programmierung
Persistente Objekte können auch in anderen als der
Erstellungsumgebung verwendet werden UND das Festschreiben
ist von konkreten Persistenzsystemen unabhängig.
 Laufzeitumgebung und persistenter Speicher sind
austauschbar
Das Auffinden von persistenten Objekten erfolgt ohne
vollständiges Durchsuchen des Objektpools
Michael Klein
[email protected]
N-K-I
Persistenztechniken (1)
 Welche Persistenztechniken für
(Java-)Objekte gibt es?
 BRAINSTORMING
5/56
Michael Klein
[email protected]
N-K-I
Persistenztechniken (2)
 1) Objektserialisierung
 2) Manuelles Objekt-Relationales Mapping
 3) OR-Mapping-Tools
 Einfache Mapper
 Container Managed Persistence (EJB2)
 NEU: Java Data Objects (JDO)
 4) Objektorientierte Datenbanksysteme (OODMBS)
6/56
Michael Klein
[email protected]
Technik 1: Objektserialisierung - Idee
N-K-I

Idee: Wandle Objekt in einen Bytestrom um und lege
diesen in einer Datei auf dem Filesystem ab.
peter : Kunde
name = „Peter Pan“
kundennr = 12345
b1 : Bestellung
Artikelnr = 887
b2 : Bestellung
Artikelnr = 998
1001100010110100111001
Dateisystem
Persistentes Medium
7/56
Michael Klein
[email protected]
Objektserialisierung in Java
N-K-I

In Java durch zwei Streams:
ObjectOutputStream, ObjectInputStream
Standard-Methoden:
void writeObject(Object o)
Object readObject()

Für Ablage in Datei: Umleiten der Ströme z.B. in
FileOutputStream / FileInputStream

Beispiel:
Kunde peter = new Kunde();
peter.name = „Peter Pan“;
peter.kundennr = 12345;
peter.bestellungen = {new Bestellung(887), new Bestellung(998)};
8/56
FileOutputStream out = new FileOutputStream(„peter.ser");
ObjectOutputStream s = new ObjectOutputStream(out);
s.writeObject(peter);
s.close();
out.close();
Michael Klein
[email protected]
Was wird serialisiert?
N-K-I
Was wird von Objekt o serialisiert?



o‘s Klasse (im Beispiel also „Kunde“)
Signatur von o‘s Klassen (z.B. public etc.)
Werte von o‘s Attributen
 wenn sie nicht als „transient“ markiert sind und
 wenn sie nicht statisch sind

Weitere Objekte, auf die o‘s Attribute verweisen
Generell gilt: Klassen, die serialisiert werden können,
implementieren das leere Interface „Serializable“.
Aufruf von writeObject auf Objekte, deren Klasse nicht
Serializable implementiert, führt zu Exception.
9/56
Michael Klein
[email protected]
Serialisierung – Bewertung
N-K-I
 Transparenz

Nicht gegeben. Klassen müssen von Hand
serialisiert/deserialisiert werden.
 Interoperabilität

Problematisch. Feste Bindung an Java (sogar spezielle
Versionsbindung). Generell aber unabhängig von
verwendeter Speichermethode.
 Skalierbare Wiederauffindbarkeit

Nicht gegeben. Objekte müssen vollständig
(inkrementelles Laden nicht möglich) im Hauptspeicher
deserialisiert werden, um Bedingungen testen zu können.
 Einfache Technik, aber nur für kleine Datenbestände
10/56
Michael Klein
[email protected]
N-K-I
T 2: Manuelles objekt-relationales Mapping
 Idee: Bilde Klassen und Beziehungen als
Relationen ab und speichere Objekte per JDBC in
relationalem DBMS mit diesem Schema
b1 : Bestellung
peter : Kunde
artikelnr = 887
name = „Peter Pan“
kundennr = 12345
b2 : Bestellung
artikelnr = 998
Kunde
name
kundennr
Peter Pan
11/56
12345
Bestellung
artikelnr
kundennr
887
12345
998
12345
JDBC
RDBMS
Michael Klein
[email protected]
N-K-I
OR-Mapping: Probleme
 Grundproblem:
Objektorientiertes Modell ist mächtiger als
relationales Modell
 nur verlustbehaftete Abbildung möglich
Probleme:
 Methoden: nicht abbildbar
 Objektidentität: nur durch künstliche Schlüssel
 Klassenzugehörigkeit: Schwierig, nur durch
externes Zusatzwissen
 Vererbunghierarchien: unter Abstrichen (siehe
später)
12/56
Michael Klein
[email protected]
N-K-I
Grundsätzliche Abbildungsvorschriften
Klasse k
 Relation k
 dabei eindeutige Attributfolge als Schlüssel s festlegen
 Attribute von k geben Attribute der Relation
1:n-Beziehung b zwischen k und m
 Schlüssel von k wird als Fremdschlüsselattribute in m
aufgenommen. Attribute von b werden in m
aufgenommen.
n:m-Beziehung b zwischen k und m
 neue Relation b mit folgenden Attributen
 Schlüssel aus k
 Schlüssel aus m
 Attribute der Beziehung b (falls vorhanden)
13/56
Michael Klein
[email protected]
Abbildungsvorschriften – Vererbung (1)
N-K-I
Vererbung
Möglichkeit 1: Alle Attribute in
die Blattklassen ziehen und nur
diese als Tabellen umsetzen
Person
nr
name
Student
matnr
14/56
Professor
rang
Mitarbeiter
stundenzahl
Assistent
Programmierer
fachgebiet
sprache
Student(nr, name, matnr)
Professor(nr, name, rang)
Assistent(nr, name,
stundenzahl, fachgebiet)
Programmierer(nr, name,
stundenzahl, sprache)
Charakteristika:
 Es kann keine Objekte von
inneren Klassen geben.
 Vererbungsbeziehung nicht
mehr ersichtlich
 Kein Verbinden (Join) von
Relationen nötig
Michael Klein
[email protected]
Abbildungsvorschriften – Vererbung (2)
N-K-I
Vererbung
Möglichkeit 2: Jede Klasse als
Relation nur mit ihren eigenen
Attributen und dem Schlüssel
Person
nr
name
Student
matnr
Professor
rang
Mitarbeiter
stundenzahl
Person(nr, name)
Student(nr, matnr)
Professor(nr, rang)
Mitarbeiter(nr, stundenzahl)
Assistent(nr, fachgebiet)
Programmierer(nr, sprache)
Charakteristika:
Assistent
Programmierer
fachgebiet
sprache




15/56
Objekte auch von inneren Klassen
Vererbungsbeziehung gut nachgebildet,
aber nur durch Zusatzwissen erkennbar
keine redundanten Attribute außer
Schlüssel
Attribute von Objekten blattnaher
Klassen müssen mit aufwändigen Joins
gesammelt werden
Michael Klein
[email protected]
Abbildungsvorschriften – Vererbung (3)
N-K-I
Vererbung
Möglichkeit 3: Jede Klasse als
Relation mit allen (d.h. auch
geerbten) Attributen und dem
Schlüssel
Person
nr
name
Student
matnr
Professor
rang
Mitarbeiter
stundenzahl
Assistent
Programmierer
fachgebiet
sprache
Person(nr, name)
Student(nr, name, matnr)
Professor(nr, name, rang)
Mitarbeiter(nr, name, stundenzahl)
Assistent(nr, name, stundenzahl,
fachgebiet)
Programmierer(nr, name,
stundenzahl, sprache)
Charakteristika:



16/56

Objekte auch von inneren Klassen
Vererbungsbeziehung nur durch
Zusatzwissen erkennbar
Redundante Attribute 
Fehleranfälligkeit, Änderungsaufwand
Keine Joins nötig
Michael Klein
[email protected]
Abbildungsvorschriften – Vererbung (4)
N-K-I
Vererbung
Möglichkeit 4: Eine Relation, die
alle Attribute und zusätzlich
einen Typ enthält. Nicht
benötigte Attribute werden mit
NULL belegt.
Person
nr
name
Student
matnr
Professor
rang
Mitarbeiter
stundenzahl
Person(personentyp, nr, name,
matnr, rang, stundenzahl,
fachgebiet, sprache)
Charakteristika:

17/56
Assistent
Programmierer
fachgebiet
sprache


Vererbungshierarchie nicht mehr
erkennbar
Relation stark aufgebläht mit vielen
NULL-Werten
Da nur eine Relation: keine Joins nötig
Michael Klein
[email protected]
N-K-I
Abbildungsvorschriften – N-äre Beziehungen
Mehrstellige Beziehungen als Relation, die
Schlüssel aller beteiligten Relationen sowie eigene
Beziehungsattribute enthält.
note
Professor
name
uni
rang
Vorlesung
0..1
0..*
prüft
name
sws
0..*
Student
matnr
fach
18/56
 Prüfung(profName, profUni, vorlesungName, matnr, note)
Michael Klein
[email protected]
OR-Mapping – Bewertung
N-K-I

Transparenz

Nicht gegeben. Objekte müssen eigenständig (durch spezielle
Methoden) dafür sorgen, dass sie per JDBC persistent gehalten
werden. Zudem: Abstriche bei der Abbildbarkeit.

Interoperabilität

Gegeben, sofern OR-Umsetzung keine programmiersprachenoder DBMS-spezifischen Funktionen verwendet.

Skalierbare Wiederauffindbarkeit

Gegeben, wenn OO-Anfragesprache (z.B. OQL) genügend gut in
eine relationale Anfragesprache (z.B. SQL) transformiert werden
kann.
 Geeignet, wenn Datenmodell nicht zu komplex (d.h. wenige
Klassen, flache Hierarchien, keine langen Beziehungsketten)
 Hoch skalierbare Technik, aufgrund langjähriger Erfahrung mit
dem rel. Modell und ausgereiften, leistungsfähigen RDBMS.
19/56
Michael Klein
[email protected]
N-K-I
Technik 3: OR-Mapping Tools
Idee: Füge zwischen Anwendung und RDBMS eine
zusätzliche Softwareschicht ein, die das OR-Mapping
automatisch und transparent durchführt.
OO-Anwendung
Java
Klassen, Objekte
OR-Mapping-Schicht
JDBC, SQL
Relationen, Tupel
RDBMS
20/56
Michael Klein
[email protected]
N-K-I
Generelle Probleme bei OR-Mapping-Tools
Hauptspeicherobjekte:
 Anwendungen greifen direkt auf Variablen und
Methoden zu, verändern Instanzvariablen. ORMSchicht muss dies erkennen und die Änderungen
in die DB übertragen.
 Mehrere verteilte Anwendungen können auf das
gleiche Objekt zugreifen (hier z.B. Objekt 3).
OO-Anwendung1
1
2
OO-Anwendung2
3
Objekt
OR-Mapping-Schicht
Tupel
RDBMS
1
2
3
4
Objekt
OR-Mapping-Schicht
21/56
3
Tupel
4
5
6
7
8
9
A
B
5
Michael Klein
[email protected]
N-K-I
Generelle Ansätze
Generelle Ansätze:
 Direkte Mapper
 Container Managed Persistence (wie in EJB2)
 Bytecode-Postprozessor (wie in Suns JDO)
22/56
Michael Klein
[email protected]
Direkte Mapper (1)
N-K-I
 Tool zum Hinzufügen zusätzlicher Methoden, die
Abbildung von Instanzvariablen zu Tabellenspalten
durchführen.
MyClass
attr1
attr2
attr3
23/56
MyClass
Tool
(mittels
Reflection
oder Metafile
meist in
XML)
Read: Fragt DB mittels JDBC/SQL ab und
erzeugt aus Ergebnis das Objekt
Update: Überprüft per Attributvergleich
auf Änderung und schreibt ggf. zurück
attr1
attr2
attr3
MyClass read(key)
void update()
 geerbt von
Oberklasse oder
 im Quellcode
hinzugefügt
Michael Klein
[email protected]
N-K-I
Direkte Mapper (2)
Probleme
 Generell: Zugriffe auf Objekt werden nicht abgefangen.
Daher:
 Problematisch, wenn mehrere Anwendungen das gleiche
Objekt verändern und zu unterschiedlichen Zeitpunkten
zurückschreiben  Konflikte, die nicht erkannt werden
 Kein Nachladen von Objektgraphen möglich. Bei read wird
Objekt und alle abhängigen Objekte geladen
Geeignet für:
 Dokumentartiges Verarbeiten von Objekten (z.B. CAD)
 Alleine komplett einladen, editieren, speichern.
 Nicht: freingranulares Laden/Schreiben von Einzelobjekten
24/56
Michael Klein
[email protected]
Direkte Mapper (3)
N-K-I
Bekannte Tools:
25/56

Castor/JDO
castor.exolab.org

JRelationalFramework
http://jrf.sourceforge.net/

Turbine/Torque
jakarta.apache.org/turbine/torque/

Hibernate
http://hibernate.sourceforge.net/

Cayenne
http://objectstyle.org/cayenne/
Michael Klein
[email protected]
N-K-I
Container Managed Persistence (EJB2)
 Idee: Verwende zum Zugriff auf Instanzvariablen
get/set-Methoden. Diese werden abstract definiert
und automatisch generiert. Beziehungen zwischen
Klassen werden im Deployment-Deskriptor
abgelegt.
26/56
Michael Klein
[email protected]
N-K-I
Container Managed Persistence (2)
Kunde
Kunde
Descriptor
Dateien
name: String
<<abstract>>
getName() : String
setName(String)
getBestellung() :
Collection<Bestellung>
setBestellung
(Collection<Bestellung>)
Generator
name: String
getName() : String
setName(String)
getBestellung() :
Collection<Bestellung>
setBestellung
(Collection<Bestellung>)
1
0..*
Bestellung
27/56
Containermanager
implementiert Methoden
so, dass er Änderungen
am Objekt abfangen und
entsprechend darauf
reagieren kann.
Michael Klein
[email protected]
N-K-I
CMP – Probleme
Probleme:
 get/set-Methoden abstrakt  keine weitere
Geschäftlogik kann eingebaut werden
 Viele Descriptor-Dateien nötig. Abhilfe schaffen
Generatoren wie XDoclet oder EJBGen
28/56
Michael Klein
[email protected]
Bytecode-Postprozessor
N-K-I
Idee: Verändere Bytecode so, dass Zugriffe auf
Instanzvariablen abgefangen und entsprechend
verarbeitet werden.
Beispieltechnik: Java Data Objects (JDO)
Quelldateien
.java
JDO PersistenzDefinitionen
javac
Bytecodedateien
.class
29/56
JDO Enhancer
Enhanced Bytecode
.class
Michael Klein
[email protected]
N-K-I
Bytecode-Postprozessoren
Probleme:
 Änderungen am Bytecode kritisch
 Veränderte Semantik für den Programmierer nicht
direkt ersichtlich
 Auch Nicht-JDO-Klassen müssen verändert werden
 Konflikte mit anderen Postprozessoren
 Verlangsamte Kompilierung
30/56
Michael Klein
[email protected]
OR-Mapping-Tools – Bewertung
N-K-I
 Transparenz

Eingeschränkt gegeben. Nutzer muss sich über
veränderte Semantik im Klaren sein. Einschränkungen bei
get/set-Methoden.
 Interoperabilität

Nicht gegeben. Anwendung ist fest an das ORM-Tool
gebunden. Austausch meist nicht möglich, da
Code/Bytecode speziell verändert.
 Skalierbare Wiederauffindbarkeit

31/56
Gegeben. Spezielle Anfragesprachen (OQL, JDOQL,
EJBQL) werden auf SQL gemappt und direkt im RDBMS
ausgeführt.
Michael Klein
[email protected]
N-K-I
Technik 4: Objektorientierte DBMS
Idee: Erstelle mehrschichtiges System, das speziell
auf das Speichern und Wiederauffinden von Objekten
ausgelegt ist.
Dazu:
Verwandle Objekte in flache Strukturen (Records,
Tupel, Arrays etc.) und lege diese unter Verwendung
von bekannten DB-Indexmechanismen (B-Baum,
Hashtable etc.) direkt auf den Seiten der Festplatte
ab.
32/56
Michael Klein
[email protected]
N-K-I
OODBMS – Beispiel O2
........Client.........
Beispiel: O2-Systemarchitektur
Object Layer
Memory Management Lr.
Communication Layer
 Objekterzeugung, Objektlöschung
 Auffinden von ObjektenD
 Zuordnung: OID  HSp-Adresse
 Behandlung von Objektzugriffsfehlern
 Freispeicherverwaltung
 Objektversendung
Server
evtl. über Netzwerk
33/56
Storage Layer




Persistente Ablage
Speicherverwaltung
Indizierung
Transaktionsmanagement
Michael Klein
[email protected]
N-K-I
Persistenz durch Erreichbarkeit
 Welche Objekte werden persistent gespeichert?
 Solche, die direkt unter Namen abgelegt werden
  Wurzelelemente
 Solche, die von persistenten Objekten erreichbar sind
 Solche, die in persistenten Kollektionen enthalten sind
34/56
Michael Klein
[email protected]
Bekannte OODBMS (für Java)
N-K-I










Ozone
 FastObjects
CudenDB
db4o
Jeevan
JYD Object Database
PJODe
SOD
VORTeX01
XL2
Weitere unter:
http://dmoz.org/Computers/Software/Databases/Object-Oriented/
35/56
Michael Klein
[email protected]
OODBMS – Bewertung
N-K-I
 Transparenz

Gegeben. Ermöglicht objektorientiertes Arbeiten ohne
Impedance Mismatch.
 Interoperabilität

Nicht gegeben. Feste Bindung an OODBMS und dessen
API.
 Skalierbare Wiederauffindbarkeit
36/56

Gegeben durch skalierbare Indexmechanismen

zudem: weitere Datenbankfunktionalität wie
Transaktionsschutz, Mehrbenutzerfähigkeit etc.
Michael Klein
[email protected]
N-K-I
OODBMS FastObjects
37/56
Michael Klein
[email protected]
N-K-I
FastObjects
FastObjects
 Java-Datenbank
 Grundsätzliches Vorgehen: Veränderung des JavaBytecodes mittels Enhancer
 Persistenz durch Erreichbarkeit
 Homepage: http://www.versant.net
38/56
Michael Klein
[email protected]
FastObjects - Produkte
N-K-I

FastObjects ist kommerzielles Produkt:

Produkte:
 FastObjects j2: Reine Java-DB, sehr klein (450 kB), nur 1
Benutzer, kein OQL, keine Benutzer
 FastObjects e7: Java/C++-DB, alle Features, nur 1
Benutzer
 FastObjects t7: Komplett-DB, mehrere Benutzer
 Alle kostenpflichtig
 Kostenfreie Varianten
 FastObjects j1 (Community Edition): ähnlich j2,
Community-Registrierung erforderlich. Nur für nichtkommerziellen/akademischen/privaten Einsatz
 Trial-Edition: ähnlich e7, Registrierung erforderlich, nur 30
Tage lauffähig
39/56
Michael Klein
[email protected]
N-K-I
Persistenzfähige Klassen
 Klassen müssen explizit als persistenzfähig
gekennzeichnet werden, so dass deren Objekte in
FastObjects speicherbar sind.
 Angabe in der Konfigurationsdatei ptj.opt
 Persistenzfähige Klassen werden von einem
Enhancer verändert.
 Klassen, die persistenzfähige Klassen verwenden,
selbst aber nicht persistenzfähig sind, werden als
persistenzbewusst (persistence aware)
bezeichnet und auch verändert.
40/56
Michael Klein
[email protected]
N-K-I
Erstellung einer Datenbank
Quellcode
.java
javac
Normaler Bytecode
.class
Enhancer ptj
Persistenzfähiger
Bytecode und
DatenbankVerzeichnisse
41/56
Persistenzkonfiguration
ptj.opt
.jdo
schema
base
 Ausführung mit normalem java-Befehl
Michael Klein
[email protected]
N-K-I
Persistenzkonfigurationsdatei
Aufbau der ptj.opt-Datei:
[schemata\<Name des Schemas>]
name = <Name des Schemas>
[databases\<Name der DB>]
name = <Name der DB>
schema = <Name des Schemas>
<FÜR ALLE PERSISTENZFÄHIGEN KLASSEN>
[classes\<Klassenname>]
persistent = true
hasExtent = <true oder false>
schema = <Name des Schemas>
42/56
Michael Klein
[email protected]
N-K-I
Neue Kollektionstypen
Persistenzfähige Kollektionstypen in FastObjects:
Im Paket: com.poet.odmg.util:
 BagOfObject
 SetOfObject
 ListOfObject
 ArrayOfObject
Standardmethoden:
add, remove, clearAll, iterator etc.
43/56
Michael Klein
[email protected]
N-K-I
Transaktionen
Alle Datenbankoperationen müssen in Transaktionen
gekapselt werden:
Transaktion = Object der Klasse com.poet.odmg.Transaction
Erzeugen einer Transaktion = Objekterzeugung:
 Transaction tr = new Transaction();
Beginnen einer Transaktion = Methodenaufruf:
tr.begin();
Beenden einer Transaktion = Methodenaufruf:
 tr.abort();
 tr.commit();
44/56
Michael Klein
[email protected]
N-K-I
Öffnen und Schließen der Datenbank
Komplette Datenbank wird durch Objekt der Klasse
com.poet.odmg.Database repräsentiert.
Vorgehensweise:
 Erzeugen: Database db = new Database()
 Öffnen: db.open(URL, Zugriffstyp)
 URL = FastObjects://LOCAL/<DBNAME>
 Zugriffstyp: Database.OPEN_READ_WRITE,
Database.OPEN_READ_ONLY
 Arbeiten mit der Datenbank innerhalb von TAs
 Schließen: db.close()
45/56
Michael Klein
[email protected]
Beispiel-Datenbank: Web-Shop
N-K-I
Person
1
0..1
käufer
Warenkorb
0..*
enthält
1
getGesamtpreis() : double
0..*
Buch
isbn : String
46/56
Artikel
preis: double
titel: String
name:String
autorVon
0..*
CD
interpret : String
laenge : int
DVD
laenge : int
Michael Klein
[email protected]
N-K-I
Erzeugen und Benennen von Objekten
Erzeugen von persistenzfähigen Objekten durch
gewöhnlichen Konstruktoraufruf:
 DVD harryPotter = new DVD(„Harry Potter“);
Das Objekt ist dann noch nicht persistent. Es muss dazu
explizit bei der DB unter einem Namen bekannt
gemacht werden:
 <Datenbankobjekt>.bind(<Objekt>, <Name>);
 db.bind(harryPotter, „dvd28“);
Hierbei können Exceptions auftreten:
 ObjectNameNotUniqueException
 ObjectNotPersistentException
 NoUniqueTransactionException
47/56
Michael Klein
[email protected]
Entnehmer benannter Objekte
N-K-I
Benannte Objekte können mit der lookup-Methode
wieder aus der DB entnommen werden:


Object o = <Datenbankobjekt>.lookup(<Name>);
Object o = db.lookup(„dvd28“);
Das Object muss dann noch in den richtigen Typ
konvertiert (gecastet) werden:
 DVD harryPotter = (DVD)o;
Mögliche Exceptions bei lookup:
 ObjectNameNotFoundException
 NoUniqueTransactionException
48/56
Michael Klein
[email protected]
N-K-I
Löschen persistenter Objekten
Löschen eines persistenten Objekts mit Hilfe der
deletePersistent-Methode:
 <Datenbankobjekt>.deletePersistent(<objekt>);
 db.deletePersistent(harryPotter);
Die Methode funktioniert nur, wenn das persistente
Objekt von keinem anderen persistenten Objekt
referenziert wird.
49/56
Michael Klein
[email protected]
Extents - Idee
N-K-I

Idee: Extent
= Menge aller Objekte einer bestimmten Klasse (inkl.
Objekte aller Unterklassen)

Stehen automatisch für alle Klassen zur Verfügung, die
in der Persistenzkonfiguration „hasExtent = true“ haben.
Sie müssen daher nicht mit add/remove-Methoden
verwaltet werden.

Erstellung eines Extents:
 Konstruktoraufruf: Extent e = new Extent(<Klassenname>)
 Funktioniert nur, wenn genau eine DB offen und genau eine
Transaktion gestartet ist, sonst komplexere Konstruktoren
50/56
Michael Klein
[email protected]
Verwendung von Extents
N-K-I
Durchlaufen eines Extents mithilfe spezieller
Navigationsmethoden, bei denen Cursor durch das
Extent wandert
O1 O2 O3 O4 O5 O6 O7 O8 O9 O10 O11 O12
Cursor
boolean hasNext(): Zeigt der Cursor auf ein gültiges Element?
void advance(): Bewegt den Cursor zum nächsten Element
void previous(): Bewegt den Cursor zum vorherigen Element
void reset(): Bewegt den Cursor zum ersten Element
void finish(): Bewegt den Cursor auf die Position nach dem
letzten Element
 Object current(): Liefert das Element, auf das der Cursor
gerade zeigt
 Object next(): Kombination aus current() und advance()





51/56
Michael Klein
[email protected]
OQL-Anfragen
N-K-I


Verwendung der OQLQuery-Klasse
Verwendung ähnlich zu JDBC

Erstellung der Anfrage über Konstruktor:


Ausführung der Anfrage:

52/56
OQLQuery query = new OQLQuery(<OQL-Anweisung>);
Object o = query.execute();

Rückgabe ist entweder Einzelobjekt oder Kollektionstyp

 siehe nächste Woche
Michael Klein
[email protected]
N-K-I
Dokumentation
Alle Dokumentationen im FastObjects-Unterordner
doc:
 CollectedODMGGuides.pdf
 Komplett-Dokumentation. Infos für diese Präsentation
in Kapitel 1-4 und 9.1
 Ausführliche OQL-Referenz ab Seite 363
 Einstieg in die Javadoc-Dokumentation:
 doc/JavaODMG3Reference/index.html
 Hilfreiche Beispiele unter:
 Examples_ODMG/Javac2
53/56
Michael Klein
[email protected]
N-K-I
Zusammenfassung: Objektpersistenz
 1) Objektserialisierung
 2) Manuelles Objekt-Relationales Mapping
 3) OR-Mapping-Tools
 Einfache Mapper
 Container Managed Persistence (EJB2)
 NEU: Java Data Objects (JDO)
 4) Objektorientierte Datenbanksysteme (OODMBS)
 Bsp: FastObjects
54/56
Michael Klein
[email protected]
Vielen Dank!
N-K-I
 Danke für die Aufmerksamkeit!
 Nächster Termin:
 Montag, 04.07.2004, 10:45 - 13:15 Uhr
(mit Fragestunde)
55/56
Michael Klein
[email protected]
Quellen
N-K-I

Codron Matthieu, Universität Stuttgart
„Java Data Objects – Write once, persist everywhere“
http://www.informatik.uni-stuttgart.de/ipvr/as/lehre/seminar/docss02/jdo_slides.pdf

Anthony Berglas, SimpleORM
„Object Relational Mapping Tools“
http://www.uq.net.au/~zzabergl/simpleorm/ORMTools.html

David Dueck, Yiwen Jiang, and Archana Sawhney
„Storage Management for Object-Oriented Database Management
Systems: A Comparative Survey“
http://www.cs.uwaterloo.ca/cs-archive/CS-1991/46/storage.pdf
56/56

2005-06-30-Objektpersistenz