Objektorientierte Datenbanken zBeim vorigen Mal: yTransaktionen, Sperren yODMG-OQL zHeute: yODMG-OQL und FastObjects-OQL yIntegritätsbedingungen und Schema-Evolution zLernziele: yAnwendung und Bewertung des ODMG-Standards Ralf Möller, FH-Wedel

Literatur

Select-From-Where-Anfragen zselect query from var_def (, var_def )* [ where query ] [ group by name: query (, name: query )* [ having (query (, query)* ) ]] [ order by query [ asc | desc ] (, query [ asc | desc ])* zvar_def = extent | var in extent | extent [as] var

Beispiel (1) zselect a from a in AuthorExtent where exists p in a.publication: count(p.keywords) > 10 zselect p.publkey from p in flatten(select a.publications from Authorextent a where a.name like "G*") zelement(select a from a in Authorextent where a.name = "Dittrich")

Beispiel (2) zmax( select p.accesses from p in PublicationExtent) zselect author1: a, author2: b, publication: p from PublicationsExtent p, a in p.getAuthors(), b in p.getAuthors() where a.name < b.name

Beispiel (3) zselect aucount, kwcount, partition from publ in PublicationExtent group by aucount: count(publ.getAuthors()), kwcount: count(publ.keywords) having count(partition) > 1 zErgebnistyp: set(struct(aucount: integer, kwcount: integer, partition: bag(struct(publ: Publication))))

Definitionen zdefine [query] query-name [ params ] as query yparams = ( type identifier (, type identifier )* ) zdefine extent extent-name class-name

Einschränkungen in FastObjects-OQL zExtraktion einzelner Attributwerte oder ganzer Objekte (kein struct) zKeine Methodenaufrufe znur Aggregatfunktion count

Integritätsüberprüfung zIntegrität: semantische (oder auch logische) Korrektheit der Datenbank in bezug auf den modellierten Weltausschnitt zIm ODMG-Standard Überprüfung durch Java-Prozeduren möglich zInterface: com.poet.odmg.Constraints ypreDelete() ypreWrite() ypostRead()

Beispiel (1) class Person implements Constraints { String name_; Date dateBorn_; transient int age_; public void postRead() { Date now = new Date(); age_ = now.getYear() - dateBorn_.getYear(); } public void preWrite() { //... } public void preDelete() { //... }

Beispiel (2) zEach manager has references to the products on which the manager has worked. class Manager extends Person { //... SetOfObject products_; // Product objects //... }

Beispiel (3) class Product implements Constraints { //... public void postRead() { //... } public void preWrite() { //... } public void preDelete() { Iterator iter = managers_.iterator(); while ( iter.hasNext() ) { ((Manager) iter.next()).removeProduct( this ); } //... }

Integritätsbedingungen zDas Gehalt des Mitarbeiters `Mario De Monti' darf nicht unter 4000,- DM liegen. ybetrifft genau ein einzelnes Objekt einer Klasse zKein Qualitätssicherer darf mehr als 5000,- DM im Monat verdienen. ybetrifft zwar alle möglichen Objekte einer Klasse, kann aber jeweils für die einzelnen Objekte überprüft werden zProdukte werden durch ihre Nummern identifiziert, das heißt, keine Produktnummer darf mehrfach vorkommen. ybetrifft alle Objekte einer Klasse und kann nicht einzeln für die jeweiligen Objekte überprüft werden

Integritätsbedingungen (2) zFür die Mitarbeiter gilt, daß das Durchschnittsgehalt der Qualitätssicherer unter dem der Arbeitsplaner liegen muß. ybetrifft eine Teilmenge einer Klasse zZu jedem Produkt muß es mindestens eine Unterlage geben. yklassenübergreifende Integritätsbedingung zDer Status eines Projekts darf nicht direkt von dem Zustand "in Planung" nach "abgeschlossen" übergehen. ybetrifft Zustandsübergänge anstelle einzelner Datenbankzustände

Integritätsbedingungen (3) zEine Gehaltserhöhung eines Mitarbeiters darf nur dann ausgeführt werden, wenn das neue Gehalt nicht zehn Prozent über dem alten Gehalt liegt. ybetrifft Zustandsübergänge, bezieht sich aber explizit auf die Änderungsoperation, die den Übergang durchführt zDer Durchschnittsverkaufspreis eines Produktes bezogen auf die letzten zwölf Monate darf nicht mehr als fünf Prozent vom Durchschnittspreis der letzten beiden Jahre abweichen. ylangfristig zu überprüfende Bedingung, für die historische Preisinformationen zusätzlich gespeichert werden müssen

Integritätsbedingungen (4) zEinkaufsteile müssen gelöscht werden, wenn sie von keinem Lieferanten mehr beziehbar sind. yIntegritätsregel, die bei bestimmten Änderungen der DB als Folgeaktion auslöst wird zQualitätssicherer, Arbeitsplaner sowie Konstrukteure sind spezielle Mitarbeiter. ydefiniert eine Untermengenbeziehung zwischen Klassen zJeder Mitarbeiter muß entweder ein Qualitätssicherer, ein Arbeitsplaner oder ein Konstrukteur sein. yerzwingt eine Klassenpartitionierung

Schema-Evolution zNicht ist stetiger als der Wandel zÄnderung von Klassendefinitionen durch Anpassung von Software an neue Einsatzbedingungen zWas passiert mit "alten" Objekten? zVerzögerte vs. eifrige Anpassung

Arten der Schema-Evolution (1) zÄnderung des Status von Instanzvariablen von transient (oder static) auf persistent zHinzufügung oder Entfernung von Instanzvariablen zÄnderung der Typen von Werten von Instanzvariable yneuer Typ ist allgemeiner: verlustfreie Anpassung yneuer Typ ist spezieller: Informationsverlust mögl. yneuer Typ ist unvergleichbar

Typumwandlung in FastObjects (Auszug) VonNachBermerkung short, int, long, float,double numerischer TypVerlust mögl. numerischer Typjava.lang.String numerischer TypbyteVerlust mögl. numerischer TypcharVerl. mög., undefi- niert bei neg. Werten numerischer Typboolean1 -> true, sonst false booleannumerischer Typfalse -> 0, sonst true

Umwandlung von Kollektionen VonNachBermerkung Array elementweise Umwandlung ObjektreferenzKollektion oder Array einelementige Koll. oder Array Kollektion Typ AKollektion Typ B Kollektion oder Array Objektreferenznur erstes Objekt betrachtet

Standardwerte

Arten der Schema-Evolution (2) zÄnderung der Vererbungsbeziehungen zRestrukturierung von Klassen yEinfügung, Löschung, Aufspaltung, Kombination, Namensänderung

Zusammenfassung, Kernpunkte zObject Query Language zAspekte der Schema-Evolution und Versionsverwaltung

Was kommt beim nächsten Mal? zObjektrelationale Datenbanken