Überblick über das POET-Datenbanksystem

1. Überblick über dasPOET-Datenbanksystem Kurzvortrag im Rahmen der Vorlesung Datenbanksysteme II FU-Berlin im WS03/04 by Jürgen Broß

2. Inhalt • Einführung • Architektur (Java Binding) • Java Binding (ODMG) • Beispiel: Ferienhaus Datenbank • Einschränkungen • Konformität zum ODMG Standard • Fragen

3. Einführung • Gründung der Poet Software GmbH 1993 • Hauptsitz in Hamburg • Börsennotiertes Unternehmen • Zwei Produktreihen: • Katalogplattform: Poet X-Solutions • Datenbanksystem: FastObjects • Produktreihe FastObjects: • Objektorientierte Datenbank • wird in verschiedenen Versionen angeboten (t7, e7, j2) • j2 in 100% Java geschrieben < 500KB (für eingebettete Systeme)

4. Architektur • Binding Language • Unterstützt C++ und Java • Java Binding mit ODMG oder JDO • ODMG-Gruppe 2001 aufgelöst, JDO soll anstelle des ODMG Java Bindings treten • Smalltalk Binding nicht unterstützt

5. Architektur • Java Binding (postprocessing) Java source file javac Java class file Property fileptj.opt ptj –enhance Java enhancedclass file Database dictionary

6. Architektur • Dictionary • enthält alle Informationen über die Struktur der persistenten Klassen Klassenschema • kann verschiedene Versionen von Klassen verwalten • teilt der DB mit, wie Klassen gelesen und geschrieben werden müssen

7. Architektur • Datenbank • ist ein Verzeichnis des Dateisystems • enthält hauptsächlich die beiden Dateienobjects.dat und objects.idx • objects.dat  enthält persistente Objekte • objects.idx  enthält Indexinformationen • Name der Datenbank entspricht Namen des Verzeichnisses • Objekte werden in kanonischer Form in der DB abgelegt • Plattformunabhängigkeit • Anwendungen in unterschiedlichen Bindings können auf die gleiche DB zugreifen • proprietäres Format (andere Implementierungen können nicht auf DB zugreifen)

8. Dictionary Datenbank Datenbank Datenbank Architektur • Datenbank & Dictionary • Dictionary ist auch eine DB, also auch ein Verzeichnis (_objects.dat, _objects.idx) • Ein Dictionary kann von mehreren Datenbanken benutzt werden

9. Objektnetzwerk RDBMS OODBS Architektur • Datenbank • Objektnetzwerk • Persistance by reachability(unabhängig von Sichtbarkeit) • Wurzelobjekte werden mit eindeutigem Namen an Datenbank gebunden • Alle Objekte, die von einem persistenten Objekt referenziert werden, müssen persistenten Klassen angehören Interface Database { … public void bind(Object o, String name); public Object lookup(String name); … }

10. Architektur • Transaktionen • Erstellen, Zugriff und Modifikation von persistenen Objekten nur innerhalb einer Transaktion möglich • Transaktionen können verschachtelt werden(nicht mehr ODMG Standard) jede Transaktion hat ihren eigenen Puffer • besonders nützlich bei GUI Programmierung (Wizards) • Verschiedene Threads können sich eine Transaktion “teilen” eigene Synchronisation notwendig txn.begin(); //Level 1 // some Product objects to work with . . . Product firstProduct = . . . Product secondProduct = . . . Product thirdProduct = . . . firstProduct.setTitle( “Ferrari" ); txn.begin(); //Level 2 secondProduct.setTitle( “Porsche" ); txn.begin(); //Level 3 secondProduct.setTitle( “Mercedes" ); thirdProduct.setTitle( "Stock Fishing" ); txn.commit(); //commit to transaction level 2 txn.commit(); // commit to level 1 txn.abort(); // abort to level 0

11. Architektur • Referentielle Integrität • Einfügen: persistance by reachability garantiert beim Einfügen, dass alle referenzierten Objekte persistent werden • Löschen: • ODMG Standard sieht garbage collection vorPersistente Objekte, die nicht mehr referenziert werden oder per Namen gebunden sind, werden automatisch gelöscht • Nachteil: FastObjects weicht hier vom Standard ab Programmierer muss sich selber um referentielle Integrität kümmern • Datenintegrität • Datenintegrität nicht durch Anweisungen oder Deklarationen im Datenbankschema zu gewährleisten • Programmierer muss sich um Integrität der Daten kümmern

12. Architektur • Interface Constraints • Beispiel public interface Constraints{ public void postRead(); public void preWrite() throws ConstraintViolation; public void preDelete() throws ConstraintViolation;} class Provider implements Constraints{ private SetOfObject houses; private Address address; private Date birthday; transient int age; // don’t make it persistent … public void postRead(){ // berechne Alter aus aktuellem Datum und Geburtstag } public void preWrite() throws Constraint Violation{ // prüfe z.B. die Addressangaben auf Integrität } public void preDelete() throws ConstraintViolation{ Iterator iter = houses.iterator(); while(iter.hasNext()) Database.current().deletePersistent(iter.next()); //may cascade } }

13. Architektur Mapping der Sperr-Typen kanndynamisch verändert werdenjava.util.PropertiesmyTransaction.setProperties(props)

14. Architektur • Extents • Extents sind im ODMG 3.0 Standard nicht vorgesehen • FastObjects unterstützt Extents: • Ein mit einem eindeutigen Namen an die DB gebundenes Wurzelobjekt ist nicht mehr notwendigObjekte über Extents erreichbar • FastObjects-API stellt Extent Klasse zur Verfügung • Extents spiegeln Vererbungsstruktur wiederBeispiel: Der Extent von Kunde ist eine Untermenge des Extents von Person • jede persistente Klasse hat standardmäßig einen Extent • Extents werden automatisch von FastObjects verwaltet Verwaltung verschlechtert die Performance so wenig Extents wie möglich nutzen (in ptj.opt ausschalten) txn.begin() Extent ext = new Extent(Person.class); int size = ext.size(); while(ext.hasNext()){ … } txn.commit();

15. Architektur • Indexstrukturen • Indexe können auf Membervariablen persistenter Objekte angelegt werden • mehrdimensionale Indexe möglich • Indexsystem von FastObjects ist erweiterbarDrittanbieter können FastObjects Service Provider Interface (SPI) nutzen • Indexe werden werden in ptj.opt deklariert ptj.opt /* * CLASS * Provider * */ [classes\Provider] persistent = true schema = FerienhausSchema hasExtent = true //optional useIndexes = ProviderNameIndex /* * INDEX * ProviderNameIndex * */ [indexes\ProviderNameIndex] class = Provider members = name

16. Architektur • Objektzugriffsverhalten (Access Patterns) • Nur sinnvoll bei Client-Server-Architektur • Zweischneidiges Schwert: • Bei Zugriff auf ein persistentes Objekt wollen wir nicht direkt alle referenzierten Objekte mitübertragen  Traffic sparen • Wir wollen nicht jedes referenzierte Objekt bei explizitem Zugriff einzeln übertragen  Verbindungsoverhead sparen • Lösung: • Lege mit Access Patterns fest welche Zugriffspfade in welcher Tiefe genutzt werden • Gesamtzahl der zu übertragenden Objekte kann beschränkt werden • Access Patterns werden in der ptserver.cfg Datei angegeben • Zu beachten: • Access Patterns gelten für alle Versionen einer Klasse Access Patterns die sich auf Instanzvariablen beziehen, die eine Version der Klasse nicht mehr besitzt werden für diese ignoriert

17. Architektur ptserver.cfg Datei: [schemata\dict\accessPatterns] usedPatterns = FriendsAndRelatives maxPreloadObjects = 7 [schemata\dict\accessPatterns\FriendsAndRelatives] pattern = *.Person.father:2, *.Person.mother:4, *.Person.friends[0-$]:1 Person1 level 0 mother father friends Person5 Person2 Person3 Person4 mother level 1 friends Person7 father Person8 Person7 Person6 level 2

18. Architektur • Objektauflösung • Java: Objekte werden per Referenz modifiziert, Objektvariablen enthalten Zeiger auf Speicheradresse • Wohin zeigt eine Objektvariable, wenn sie ein persistentes Objekt referenziert? • FastObjects implementiert Objektvariablen als spezielle Referenzobjekte, die die eigentliche Referenz kapseln • Referenzobjekte dienen als Proxy und liefern die eigentlichen Objekte nur, wenn auf diese wirklich zugegriffen wird • Basistypen wie int, float, double, … werden nicht gekapselt und direkt in den Speicher geladen • FastObjects behandelt folgende Typen als Basistypen: • eindimensionale Arrays von Java-Basistypen • String, Date und eindimesionales Array von beiden • alle durch FastObjects definierten Collections (SetOfObject, BagOfObject,…) • com.poet.Blob

19. OBJECT Product OBJECT Person DIRECTData-member String namevalue: “Enzo” DIRECTData-member String titlevalue: “Ferrari” DIRECTData-memberint yearvalue: 1999 REFERENCEData-memberPerson manager Architektur //… Product product = db.lookup(“Ferrari”); //… REFERENCEApplication variableProduct product resolves resolves

20. Architektur • Objektidentität • Jedes Objekt in der DB hat eine eindeutige ObjectID zugeordnet

21. OQL Einschränkungen • In SELECT keine kommagetrennte Liste möglich es können keine Strukturtypen selektiert werden • Nur zwei Mengendefinitionen in FROM Klausel möglich. Die Mengen sind entweder Extents, eingebettete Mengen oder das Resultat einer verschachtelten Anfrage • nur ein Extent in FROM Klausel • Kein DISTINCT Operator • Kein Zugriff auf Methoden der Objekte, also auch kein late binding • GROUP BY nicht implementiert • Ausser COUNT keine weitere Aggregatfunktion • Keine Vergleichsoperatoren für Mengen (Inklusion,…)