Objektorientierte Datenbanken
Beim vorigen Mal:
Transaktionen, Sperren
ODMG-OQL
Heute:
ODMG-OQL und FastObjects-OQL
Integritätsbedingungen und Schema-Evolution
Lernziele:
Anwendung und Bewertung des ODMG-Standards
Ralf Möller, FH-Wedel
Literatur
Select-From-Where-Anfragen
select 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 ])*
var_def =
extent | var in extent | extent [as] var
Beispiel (1)
select a
from a in AuthorExtent
where exists p in a.publication:
count(p.keywords) > 10
select p.publkey
from p in flatten(select a.publications from Authorextent a where a.name like "G*")
element(select a from a in Authorextent
where a.name = "Dittrich")
Beispiel (2)
max(
select p.accesses
from p in PublicationExtent)
select author1: a, author2: b, publication: p from PublicationsExtent p,
a in p.getAuthors(),
b in p.getAuthors()
where a.name < b.name
Beispiel (3)
select aucount, kwcount, partition from publ in PublicationExtent
group by aucount: count(publ.getAuthors()), kwcount: count(publ.keywords)
having count(partition) > 1
Ergebnistyp:
set(struct(aucount: integer, kwcount: integer,
partition: bag(struct(publ: Publication))))
Definitionen
define [query] query-name [ params ] as query
params = ( type identifier (, type identifier )* )
define extent extent-name class-name
Einschränkungen in FastObjects-OQL
Extraktion einzelner Attributwerte oder ganzer Objekte (kein struct)
Keine Methodenaufrufe
nur Aggregatfunktion count
Integritätsüberprüfung
Integrität: semantische (oder auch logische) Korrektheit der Datenbank in bezug auf den modellierten
Weltausschnitt
Im ODMG-Standard Überprüfung durch Java-Prozeduren möglich
Interface: com.poet.odmg.Constraints
preDelete()
preWrite()
postRead()
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)
Each 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
Das Gehalt des Mitarbeiters `Mario De Monti' darf nicht unter 4000,- DM liegen.
betrifft genau ein einzelnes Objekt einer Klasse
Kein Qualitätssicherer darf mehr als 5000,- DM im Monat verdienen.
betrifft zwar alle möglichen Objekte einer Klasse, kann aber jeweils für die einzelnen Objekte überprüft werden
Produkte werden durch ihre Nummern identifiziert, das heißt, keine Produktnummer darf mehrfach vorkommen.
betrifft alle Objekte einer Klasse und kann nicht einzeln für die jeweiligen Objekte überprüft werden
Integritätsbedingungen (2)
Für die Mitarbeiter gilt, daß das Durchschnittsgehalt der Qualitätssicherer unter dem der Arbeitsplaner liegen muß.
betrifft eine Teilmenge einer Klasse
Zu jedem Produkt muß es mindestens eine Unterlage geben.
klassenübergreifende Integritätsbedingung
Der Status eines Projekts darf nicht direkt von dem Zustand "in Planung" nach "abgeschlossen" übergehen.
betrifft Zustandsübergänge anstelle einzelner Datenbankzustände
Integritätsbedingungen (3)
Eine Gehaltserhöhung eines Mitarbeiters darf nur dann ausgeführt werden, wenn das neue Gehalt nicht zehn Prozent über dem alten Gehalt liegt.
betrifft Zustandsübergänge, bezieht sich aber explizit auf die Änderungsoperation, die den Übergang durchführt
Der Durchschnittsverkaufspreis eines Produktes bezogen auf die letzten zwölf Monate darf nicht mehr als fünf
Prozent vom Durchschnittspreis der letzten beiden Jahre abweichen.
langfristig zu überprüfende Bedingung, für die historische Preisinformationen zusätzlich gespeichert werden müssen
Integritätsbedingungen (4)
Einkaufsteile müssen gelöscht werden, wenn sie von keinem Lieferanten mehr beziehbar sind.
Integritätsregel, die bei bestimmten Änderungen der DB als Folgeaktion auslöst wird
Qualitätssicherer, Arbeitsplaner sowie Konstrukteure sind spezielle Mitarbeiter.
definiert eine Untermengenbeziehung zwischen Klassen
Jeder Mitarbeiter muß entweder ein Qualitätssicherer, ein Arbeitsplaner oder ein Konstrukteur sein.
erzwingt eine Klassenpartitionierung
Schema-Evolution
Nicht ist stetiger als der Wandel
Änderung von Klassendefinitionen durch Anpassung von Software an neue
Einsatzbedingungen
Was passiert mit "alten" Objekten?
Verzögerte vs. eifrige Anpassung
Arten der Schema-Evolution (1)
Änderung des Status von Instanzvariablen von transient (oder static) auf persistent
Hinzufügung oder Entfernung von Instanzvariablen
Änderung der Typen von Werten von Instanzvariable
neuer Typ ist allgemeiner: verlustfreie Anpassung
neuer Typ ist spezieller: Informationsverlust mögl.
neuer Typ ist unvergleichbar
Typumwandlung in FastObjects (Auszug)
Von Nach Bermerkung
short, int, long, float,double
numerischer Typ Verlust mögl.
numerischer Typ java.lang.String
numerischer Typ byte Verlust mögl.
numerischer Typ char Verl. mög., undefi-
niert bei neg. Werten numerischer Typ boolean 1 -> true, sonst false boolean numerischer Typ false -> 0, sonst true
Umwandlung von Kollektionen
Von Nach Bermerkung
Array Array elementweise
Umwandlung Objektreferenz Kollektion oder
Array
einelementige Koll.
oder Array Kollektion Typ A Kollektion Typ B
Kollektion oder Array
Objektreferenz nur erstes Objekt betrachtet
Standardwerte
Arten der Schema-Evolution (2)
Änderung der Vererbungsbeziehungen
Restrukturierung von Klassen
Einfügung, Löschung, Aufspaltung, Kombination, Namensänderung