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
Download
Report
Transcript 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
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