Michael Klein [email protected] 1/56 N-K-I Vorlesung Informationssysteme: Neuere Konzepte Dipl.-Inform. Michael Klein [email protected]

Michael [email protected]

1/56

N-K-IN-K-I

VorlesungInformationssysteme: „Neuere Konzepte“

Dipl.-Inform. Michael [email protected]

Dipl.-Inform. Heiko [email protected]

Persistenz von Objekten


2/56

N-K-IN-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


3/56

N-K-IN-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


4/56

N-K-IN-K-I Anforderungen an Objektpersistenz

Gewünschte Eigenschaften der Persistenz:

TransparenzBenutzer arbeiten in gleicher Weise mit transienten und persistenten Objekten. Persistenz erfordert keine Sonderbehandlung bei der Programmierung

InteroperabilitätPersistente 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

Skalierbare WiederauffindbarkeitDas Auffinden von persistenten Objekten erfolgt ohne vollständiges Durchsuchen des Objektpools

Mehrbenutzer, Konflikterkennung, Verteilung


5/56

N-K-IN-K-I Persistenztechniken (1)

Welche Persistenztechniken für (Java-)Objekte gibt es?

BRAINSTORMING


6/56

N-K-IN-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)


7/56

N-K-IN-K-I Technik 1: Objektserialisierung - Idee

Idee: Wandle Objekt in einen Bytestrom um und lege diesen in einer Datei auf dem Filesystem ab.

name = „Peter Pan“kundennr = 12345

peter : Kunde

1 0 0 1 1 0 0 0 1 0 1 1 0 1 0 0 1 1 1 0 0 1

b1 : Bestellung

Artikelnr = 887

b2 : Bestellung

Artikelnr = 998

DateisystemPersistentes Medium


8/56

N-K-IN-K-I Objektserialisierung in Java

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)};

FileOutputStream out = new FileOutputStream(„peter.ser");ObjectOutputStream s = new ObjectOutputStream(out);s.writeObject(peter); s.close(); out.close();


9/56

N-K-IN-K-I Was wird serialisiert?

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 nichtSerializable implementiert, führt zu Exception.


10/56

N-K-IN-K-I Serialisierung – Bewertung

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


11/56

N-K-IN-K-IT 2: Manuelles objekt-relationales

Mapping

Idee: Bilde Klassen und Beziehungen als Relationen ab und speichere Objekte per JDBC in relationalem DBMS mit diesem Schema

name = „Peter Pan“kundennr = 12345

peter : Kunde b1 : Bestellung

artikelnr = 887

b2 : Bestellung

artikelnr = 998

RDBMS

JDBCname kundennr artikelnr kundennr

Peter Pan 12345 887

998

12345

12345

Kunde Bestellung


12/56

N-K-IN-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)


13/56

N-K-IN-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)


14/56

N-K-IN-K-I Abbildungsvorschriften – Vererbung (1)

Vererbung

Person

Student Professor Mitarbeiter

nrname

matnr rang stundenzahl

Möglichkeit 1: Alle Attribute in die Blattklassen ziehen und nur diese als Tabellen umsetzen

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

Assistent

fachgebiet

Programmierer

sprache


15/56


Vererbung

Person


nrname


Möglichkeit 2: Jede Klasse als Relation nur mit ihren eigenen Attributen und dem Schlüssel

Person(nr, name)Student(nr, matnr)Professor(nr, rang)Mitarbeiter(nr, stundenzahl)Assistent(nr, fachgebiet)Programmierer(nr, sprache)

Charakteristika: 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

Assistent

fachgebiet

Programmierer

sprache


16/56


Vererbung

Person


nrname


Möglichkeit 3: Jede Klasse als Relation mit allen (d.h. auch geerbten) Attributen und dem Schlüssel

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: Objekte auch von inneren Klassen Vererbungsbeziehung nur durch

Zusatzwissen erkennbar Redundante Attribute

Fehleranfälligkeit, Änderungsaufwand Keine Joins nötig

Assistent

fachgebiet

Programmierer

sprache


17/56


Vererbung

Person


nrname


Möglichkeit 4: Eine Relation, die alle Attribute und zusätzlich einen Typ enthält. Nicht benötigte Attribute werden mit NULL belegt.

Person(personentyp, nr, name, matnr, rang, stundenzahl, fachgebiet, sprache)

Charakteristika: Vererbungshierarchie nicht mehr

erkennbar Relation stark aufgebläht mit vielen

NULL-Werten Da nur eine Relation: keine Joins nötig

Assistent

fachgebiet

Programmierer

sprache


18/56

N-K-IN-K-IAbbildungsvorschriften – N-äre

Beziehungen

Professor

nameunirang

Vorlesung

namesws

Student

matnrfach

Mehrstellige Beziehungen als Relation, die Schlüssel aller beteiligten Relationen sowie eigene Beziehungsattribute enthält.

prüft

0..*0..1

0..*

note

Prüfung(profName, profUni, vorlesungName, matnr, note)


19/56

N-K-IN-K-I OR-Mapping – Bewertung

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 programmiersprachen- oder

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.


20/56

N-K-IN-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

OR-Mapping-Schicht

RDBMS

JDBC, SQL

Java

Relationen, Tupel

Klassen, Objekte


21/56

N-K-IN-K-IGenerelle Probleme bei OR-Mapping-

Tools

OO-Anwendung1

OR-Mapping-Schicht

RDBMS

Tupel

Objekt

1 2 3

1 2 3 4 5 6 7 8 9 A B

Hauptspeicherobjekte: Anwendungen greifen direkt auf Variablen und

Methoden zu, verändern Instanzvariablen. ORM-Schicht 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-Anwendung2 3 4 5

OR-Mapping-Schicht

Objekt

Tupel


22/56

N-K-IN-K-I Generelle Ansätze

Generelle Ansätze:

Direkte Mapper Container Managed Persistence (wie in EJB2) Bytecode-Postprozessor (wie in Suns JDO)


23/56

N-K-IN-K-I Direkte Mapper (1)

Tool zum Hinzufügen zusätzlicher Methoden, die Abbildung von Instanzvariablen zu Tabellenspalten durchführen.

MyClass

attr1attr2attr3

MyClass read(key)void update()

MyClass

attr1attr2attr3

Tool(mittels

Reflection oder Metafile

meist in XML)

geerbt von Oberklasse oder

im Quellcode hinzugefügt

Read: Fragt DB mittels JDBC/SQL ab underzeugt aus Ergebnis das ObjektUpdate: Überprüft per Attributvergleich auf Änderung und schreibt ggf. zurück


24/56


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


25/56


Bekannte Tools:

Castor/JDOcastor.exolab.org

JRelationalFrameworkhttp://jrf.sourceforge.net/

Turbine/Torquejakarta.apache.org/turbine/torque/

Hibernatehttp://hibernate.sourceforge.net/

Cayennehttp://objectstyle.org/cayenne/


26/56

N-K-IN-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.


27/56

N-K-IN-K-I Container Managed Persistence (2)

Bestellung

Kunde

name: String

1

0..*

Generator

<<abstract>>getName() : StringsetName(String)getBestellung() : Collection<Bestellung>setBestellung (Collection<Bestellung>)

Kunde

name: String

getName() : StringsetName(String)getBestellung() : Collection<Bestellung>setBestellung (Collection<Bestellung>)

Containermanager implementiert Methoden so, dass er Änderungen am Objekt abfangen und entsprechend darauf reagieren kann.

DescriptorDateien


28/56

N-K-IN-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


29/56

N-K-IN-K-I Bytecode-Postprozessor

Idee: Verändere Bytecode so, dass Zugriffe auf Instanzvariablen abgefangen und entsprechend verarbeitet werden.

Beispieltechnik: Java Data Objects (JDO)

Quelldateien.java

Bytecodedateien.class

Enhanced Bytecode.class

javac

JDO Enhancer

JDO Persistenz-Definitionen


30/56

N-K-IN-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


31/56

N-K-IN-K-I OR-Mapping-Tools – Bewertung

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 Gegeben. Spezielle Anfragesprachen (OQL, JDOQL, EJBQL)

werden auf SQL gemappt und direkt im RDBMS ausgeführt.


32/56

N-K-IN-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.


33/56

N-K-IN-K-I OODBMS – Beispiel O2

Beispiel: O2-Systemarchitektur

Object Layer Objekterzeugung, Objektlöschung Auffinden von ObjektenD

Memory Management Lr.

Communication Layer

Storage Layer

Zuordnung: OID HSp-Adresse Behandlung von Objektzugriffsfehlern Freispeicherverwaltung

Objektversendung

Persistente Ablage Speicherverwaltung Indizierung Transaktionsmanagement

....

....

Clie

nt.

....

....

Serv

er

evtl. über Netzwerk


34/56

N-K-IN-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


35/56

N-K-IN-K-I Bekannte OODBMS (für Java)

Ozone FastObjects CudenDB db4o Jeevan JYD Object Database PJODe SOD VORTeX01 XL2

Weitere unter:http://dmoz.org/Computers/Software/Databases/Object-Oriented/


36/56

N-K-IN-K-I OODBMS – Bewertung

Transparenz Gegeben. Ermöglicht objektorientiertes Arbeiten ohne

Impedance Mismatch.

Interoperabilität Nicht gegeben. Feste Bindung an OODBMS und dessen

API.

Skalierbare Wiederauffindbarkeit Gegeben durch skalierbare Indexmechanismen

zudem: weitere Datenbankfunktionalität wie Transaktionsschutz, Mehrbenutzerfähigkeit etc.


37/56

N-K-IN-K-I

OODBMS FastObjects


38/56

N-K-IN-K-I FastObjects

FastObjects Java-Datenbank Grundsätzliches Vorgehen: Veränderung des Java-

Bytecodes mittels Enhancer Persistenz durch Erreichbarkeit Homepage: http://www.versant.net


39/56

N-K-IN-K-I FastObjects - Produkte

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 nicht-kommerziellen/akademischen/privaten Einsatz

Trial-Edition: ähnlich e7, Registrierung erforderlich, nur 30 Tage lauffähig


40/56

N-K-IN-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.


41/56

N-K-IN-K-I Erstellung einer Datenbank

.java

.class

javac

Enhancer ptj

.jdoschema

base

Quellcode

Normaler Bytecode

Persistenzfähiger Bytecode und

Datenbank-Verzeichnisse

Persistenz-konfiguration

ptj.opt

Ausführung mit normalem java-Befehl


42/56

N-K-IN-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 = truehasExtent = <true oder false>schema = <Name des Schemas>


43/56

N-K-IN-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.


44/56

N-K-IN-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();


45/56

N-K-IN-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()


46/56

N-K-IN-K-I Beispiel-Datenbank: Web-Shop

Person

name:String

Warenkorb

getGesamt-preis() : double

Artikel

preis: doubletitel: String

CD

interpret : Stringlaenge : int

DVD

laenge : int

Buch

isbn : String

autorVon

0..*

1

0..11

käufer

0..* 0..*

enthält


47/56

N-K-IN-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


48/56

N-K-IN-K-I Entnehmer benannter Objekte

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


49/56

N-K-IN-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.


50/56

N-K-IN-K-I Extents - Idee

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


51/56

N-K-IN-K-I Verwendung von Extents

Durchlaufen eines Extents mithilfe spezieller Navigationsmethoden, bei denen Cursor durch das Extent wandert

O1 O2 O3 O4 O5 O6 O7 O8 O9 O10 O11 O12Cursor

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()


52/56

N-K-IN-K-I OQL-Anfragen

Verwendung der OQLQuery-Klasse Verwendung ähnlich zu JDBC

Erstellung der Anfrage über Konstruktor: OQLQuery query = new OQLQuery(<OQL-Anweisung>);

Ausführung der Anfrage: Object o = query.execute();

Rückgabe ist entweder Einzelobjekt oder Kollektionstyp

siehe nächste Woche


53/56

N-K-IN-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


54/56

N-K-IN-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


55/56

N-K-IN-K-I Vielen Dank!

Danke für die Aufmerksamkeit!

Nächster Termin: Montag, 04.07.2004, 10:45 - 13:15 Uhr

(mit Fragestunde)


56/56

N-K-IN-K-I Quellen

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

Documents

Michael Klein [email protected] 1/56 N-K-I Vorlesung Informationssysteme: Neuere Konzepte Dipl.-Inform. Michael Klein [email protected]