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

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

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)

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

Java enhanced class file Architektur Java Binding (postprocessing) Java source file javac Java class file Property file ptj.opt ptj –enhance Java enhanced class file Database dictionary

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

Architektur Datenbank ist ein Verzeichnis des Dateisystems enthält hauptsächlich die beiden Dateien objects.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)

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

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 Objektnetzwerk RDBMS OODBS Interface Database { … public void bind(Object o, String name); public Object lookup(String name); }

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

Architektur Referentielle Integrität Datenintegrität Einfügen: persistance by reachability garantiert beim Einfügen, dass alle referenzierten Objekte persistent werden Löschen: ODMG Standard sieht garbage collection vor Persistente 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

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

Architektur FastObjects Sperr-Typen Angeforderte Sperre Gehaltene Sperre RvD RvW WvW DvW DvR Exc None + ReadvDelete - ReadvWrite WritevWrite DeletevWrite DeletevRead ODMG Java Standard FastObjects Transaction.READ READvDELETE Transaction.UPGRADE WRITEvWRITE Transaction.WRITE DELETEvWrite Transaction.DELETE DELETEvREAD Mapping der Sperr-Typen kann dynamisch verändert werden java.util.Properties myTransaction.setProperties(props)

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 wieder Beispiel: 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();

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

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

Architektur Person 1 level 0 mother father friends Person 5 Person 2 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 Person 1 level 0 mother father friends Person 5 Person 2 Person 3 Person 4 mother level 1 friends father Person 7 Person 8 Person 7 Person 6 level 2

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

Architektur //… Product product = db.lookup(“Ferrari”); OBJECT Product DIRECT Data-member String title value: “Ferrari” DIRECT Data-member int year value: 1999 OBJECT Product REFERENCE Data-member Person manager //… Product product = db.lookup(“Ferrari”); OBJECT Person DIRECT Data-member String name value: “Enzo” REFERENCE Application variable Product product resolves resolves

Architektur Objektidentität Jedes Objekt in der DB hat eine eindeutige ObjectID zugeordnet ObjectID: (<db>:<HVal>-<LVal>#<blkid>,<classid> Komponente Beschreibung <db> Datenbankidentifikation innerhalb der Anwendung (ändert sich je nachdem in welcher Reihenfolge versch. Datenbanken geöffnet werden) <HVal> High-order bytes (Konstante für den gesamten Lebenszyklus des Objekts) <LVal> Low-order bytes (Konstante für den gesamten Lebenszyklus des Objekts) <blkid> Blockadresse des Objekts in der Datenbankdatei <classid> Interne Identifizierung für die zugehörige Klasse

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,…)