Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Michael Klein 1/56 N-K-I Vorlesung Informationssysteme: Neuere Konzepte Dipl.-Inform. Michael Klein"—  Präsentation transkript:

1 Michael Klein kleinm@ipd.uni-karlsruhe.de 1/56 N-K-I Vorlesung Informationssysteme: Neuere Konzepte Dipl.-Inform. Michael Klein kleinm@ipd.uni-karlsruhe.de Dipl.-Inform. Heiko Schepperle schepperle@ipd.uni-karlsruhe.de Persistenz von Objekten

2 Michael Klein kleinm@ipd.uni-karlsruhe.de 2/56 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

3 Michael Klein kleinm@ipd.uni-karlsruhe.de 3/56 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

4 Michael Klein kleinm@ipd.uni-karlsruhe.de 4/56 N-K-I Anforderungen an Objektpersistenz Gewünschte Eigenschaften der Persistenz: Transparenz Benutzer arbeiten in gleicher Weise mit transienten und persistenten Objekten. Persistenz erfordert keine Sonderbehandlung bei der Programmierung Interoperabilität 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 Skalierbare Wiederauffindbarkeit Das Auffinden von persistenten Objekten erfolgt ohne vollständiges Durchsuchen des Objektpools Mehrbenutzer, Konflikterkennung, Verteilung

5 Michael Klein kleinm@ipd.uni-karlsruhe.de 5/56 N-K-I Persistenztechniken (1) Welche Persistenztechniken für (Java-)Objekte gibt es? BRAINSTORMING

6 Michael Klein kleinm@ipd.uni-karlsruhe.de 6/56 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)

7 Michael Klein kleinm@ipd.uni-karlsruhe.de 7/56 N-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 Dateisystem Persistentes Medium

8 Michael Klein kleinm@ipd.uni-karlsruhe.de 8/56 N-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 Michael Klein kleinm@ipd.uni-karlsruhe.de 9/56 N-K-I Was wird serialisiert? Was wird von Objekt o serialisiert? os Klasse (im Beispiel also Kunde) Signatur von os Klassen (z.B. public etc.) Werte von os Attributen wenn sie nicht als transient markiert sind und wenn sie nicht statisch sind Weitere Objekte, auf die os 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.

10 Michael Klein kleinm@ipd.uni-karlsruhe.de 10/56 N-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 Michael Klein kleinm@ipd.uni-karlsruhe.de 11/56 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 name = Peter Pan kundennr = 12345 peter : Kunde b1 : Bestellung artikelnr = 887 b2 : Bestellung artikelnr = 998 RDBMS JDBC namekundennrartikelnrkundennr Peter Pan12345 887 998 12345 KundeBestellung

12 Michael Klein kleinm@ipd.uni-karlsruhe.de 12/56 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)

13 Michael Klein kleinm@ipd.uni-karlsruhe.de 13/56 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)

14 Michael Klein kleinm@ipd.uni-karlsruhe.de 14/56 N-K-I Abbildungsvorschriften – Vererbung (1) Vererbung Person StudentProfessorMitarbeiter nr name matnrrangstundenzahl 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 Michael Klein kleinm@ipd.uni-karlsruhe.de 15/56 N-K-I Abbildungsvorschriften – Vererbung (2) Vererbung Person StudentProfessorMitarbeiter nr name matnrrangstundenzahl 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 Michael Klein kleinm@ipd.uni-karlsruhe.de 16/56 N-K-I Abbildungsvorschriften – Vererbung (3) Vererbung Person StudentProfessorMitarbeiter nr name matnrrangstundenzahl 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 Michael Klein kleinm@ipd.uni-karlsruhe.de 17/56 N-K-I Abbildungsvorschriften – Vererbung (4) Vererbung Person StudentProfessorMitarbeiter nr name matnrrangstundenzahl 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 Michael Klein kleinm@ipd.uni-karlsruhe.de 18/56 N-K-I Abbildungsvorschriften – N-äre Beziehungen Professor name uni rang Vorlesung name sws Student matnr fach 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 Michael Klein kleinm@ipd.uni-karlsruhe.de 19/56 N-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 Michael Klein kleinm@ipd.uni-karlsruhe.de 20/56 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 OR-Mapping-Schicht RDBMS JDBC, SQL Java Relationen, Tupel Klassen, Objekte

21 Michael Klein kleinm@ipd.uni-karlsruhe.de 21/56 N-K-I Generelle Probleme bei OR-Mapping-Tools OO-Anwendung1 OR-Mapping-Schicht RDBMS Tupel Objekt 123 123456789AB 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 345 OR-Mapping-Schicht Objekt Tupel

22 Michael Klein kleinm@ipd.uni-karlsruhe.de 22/56 N-K-I Generelle Ansätze Generelle Ansätze: Direkte Mapper Container Managed Persistence (wie in EJB2) Bytecode-Postprozessor (wie in Suns JDO)

23 Michael Klein kleinm@ipd.uni-karlsruhe.de 23/56 N-K-I Direkte Mapper (1) Tool zum Hinzufügen zusätzlicher Methoden, die Abbildung von Instanzvariablen zu Tabellenspalten durchführen. MyClass attr1 attr2 attr3 MyClass read(key) void update() MyClass attr1 attr2 attr3 Tool (mittels Reflection oder Metafile meist in XML) geerbt von Oberklasse oder im Quellcode hinzugefügt 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

24 Michael Klein kleinm@ipd.uni-karlsruhe.de 24/56 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

25 Michael Klein kleinm@ipd.uni-karlsruhe.de 25/56 N-K-I Direkte Mapper (3) Bekannte Tools: 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/

26 Michael Klein kleinm@ipd.uni-karlsruhe.de 26/56 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.

27 Michael Klein kleinm@ipd.uni-karlsruhe.de 27/56 N-K-I Container Managed Persistence (2) Bestellung Kunde name: String 1 0..* Generator > getName() : String setName(String) getBestellung() : Collection setBestellung (Collection ) Kunde name: String getName() : String setName(String) getBestellung() : Collection setBestellung (Collection ) Containermanager implementiert Methoden so, dass er Änderungen am Objekt abfangen und entsprechend darauf reagieren kann. Descriptor Dateien

28 Michael Klein kleinm@ipd.uni-karlsruhe.de 28/56 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

29 Michael Klein kleinm@ipd.uni-karlsruhe.de 29/56 N-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 Michael Klein kleinm@ipd.uni-karlsruhe.de 30/56 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

31 Michael Klein kleinm@ipd.uni-karlsruhe.de 31/56 N-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 Michael Klein kleinm@ipd.uni-karlsruhe.de 32/56 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.

33 Michael Klein kleinm@ipd.uni-karlsruhe.de 33/56 N-K-I OODBMS – Beispiel O 2 Beispiel: O 2 -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........Client......... Server evtl. über Netzwerk

34 Michael Klein kleinm@ipd.uni-karlsruhe.de 34/56 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

35 Michael Klein kleinm@ipd.uni-karlsruhe.de 35/56 N-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 Michael Klein kleinm@ipd.uni-karlsruhe.de 36/56 N-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 Michael Klein kleinm@ipd.uni-karlsruhe.de 37/56 N-K-I OODBMS FastObjects

38 Michael Klein kleinm@ipd.uni-karlsruhe.de 38/56 N-K-I FastObjects Java-Datenbank Grundsätzliches Vorgehen: Veränderung des Java- Bytecodes mittels Enhancer Persistenz durch Erreichbarkeit Homepage: http://www.versant.net

39 Michael Klein kleinm@ipd.uni-karlsruhe.de 39/56 N-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 Michael Klein kleinm@ipd.uni-karlsruhe.de 40/56 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.

41 Michael Klein kleinm@ipd.uni-karlsruhe.de 41/56 N-K-I Erstellung einer Datenbank.java.class javac Enhancer ptj.jdo schema base Quellcode Normaler Bytecode Persistenzfähiger Bytecode und Datenbank- Verzeichnisse Persistenz- konfiguration ptj.opt Ausführung mit normalem java-Befehl

42 Michael Klein kleinm@ipd.uni-karlsruhe.de 42/56 N-K-I Persistenzkonfigurationsdatei Aufbau der ptj.opt-Datei: [schemata\ ] name = [databases\ ] name = schema = [classes\ ] persistent = true hasExtent = schema =

43 Michael Klein kleinm@ipd.uni-karlsruhe.de 43/56 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.

44 Michael Klein kleinm@ipd.uni-karlsruhe.de 44/56 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();

45 Michael Klein kleinm@ipd.uni-karlsruhe.de 45/56 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/ Zugriffstyp: Database.OPEN_READ_WRITE, Database.OPEN_READ_ONLY Arbeiten mit der Datenbank innerhalb von TAs Schließen: db.close()

46 Michael Klein kleinm@ipd.uni-karlsruhe.de 46/56 N-K-I Beispiel-Datenbank: Web-Shop Person name:String Warenkorb getGesamt- preis() : double Artikel preis: double titel: String CD interpret : String laenge : int DVD laenge : int Buch isbn : String autorVon 0..* 1 0..11 käufer 0..* enthält

47 Michael Klein kleinm@ipd.uni-karlsruhe.de 47/56 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:.bind(, ); db.bind(harryPotter, dvd28); Hierbei können Exceptions auftreten: ObjectNameNotUniqueException ObjectNotPersistentException NoUniqueTransactionException

48 Michael Klein kleinm@ipd.uni-karlsruhe.de 48/56 N-K-I Entnehmer benannter Objekte Benannte Objekte können mit der lookup-Methode wieder aus der DB entnommen werden: Object o =.lookup( ); 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 Michael Klein kleinm@ipd.uni-karlsruhe.de 49/56 N-K-I Löschen persistenter Objekten Löschen eines persistenten Objekts mit Hilfe der deletePersistent-Methode:.deletePersistent( ); db.deletePersistent(harryPotter); Die Methode funktioniert nur, wenn das persistente Objekt von keinem anderen persistenten Objekt referenziert wird.

50 Michael Klein kleinm@ipd.uni-karlsruhe.de 50/56 N-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( ) Funktioniert nur, wenn genau eine DB offen und genau eine Transaktion gestartet ist, sonst komplexere Konstruktoren

51 Michael Klein kleinm@ipd.uni-karlsruhe.de 51/56 N-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 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()

52 Michael Klein kleinm@ipd.uni-karlsruhe.de 52/56 N-K-I OQL-Anfragen Verwendung der OQLQuery-Klasse Verwendung ähnlich zu JDBC Erstellung der Anfrage über Konstruktor: OQLQuery query = new OQLQuery( ); Ausführung der Anfrage: Object o = query.execute(); Rückgabe ist entweder Einzelobjekt oder Kollektionstyp siehe nächste Woche

53 Michael Klein kleinm@ipd.uni-karlsruhe.de 53/56 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

54 Michael Klein kleinm@ipd.uni-karlsruhe.de 54/56 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

55 Michael Klein kleinm@ipd.uni-karlsruhe.de 55/56 N-K-I Vielen Dank! Danke für die Aufmerksamkeit! Nächster Termin: Montag, 04.07.2004, 10:45 - 13:15 Uhr (mit Fragestunde)

56 Michael Klein kleinm@ipd.uni-karlsruhe.de 56/56 N-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


Herunterladen ppt "Michael Klein 1/56 N-K-I Vorlesung Informationssysteme: Neuere Konzepte Dipl.-Inform. Michael Klein"

Ähnliche Präsentationen


Google-Anzeigen