ppt

Vortrag:
OSCAR und die
Regelsprache ORCA
Seminar: „Aktive Datenbanken“
FSU Jena
Lehrstuhl für Datenbanken
und Informationssysteme
Betreuer: David Wiese
25. 6. 2007
Stefanie
Müller
Inhalt
1.
2.
3.
4.
5.
6.
Entwicklungsgeschichte von OSCAR
und der Regelsprache ORCA
Einordnung in das Themenfeld der
aktiven Datenbanken
Vorstellung des Datenmodells EXTREM
und des OODBMS OSCAR
Die Regelsprache ORCA –
Besonderheiten in Syntax und Optionen
Vergleichende Aspekte zu anderen
Regelsprachen
Zusammenfassung
1. Entwicklungsgeschichte

Datenmodell EXTREM (Extended
Relational Model) wurde seit 1989
unter der Leitung von A. Heuer
entwickelt implementiert

EXTREM ist ein
semantisches
Datenbankmodell, basierend auf
der Untermenge des IFO-Modells
1. Entwicklungsgeschichte

Zugehöriges objektorientiertes
Datenbanksystem: OSCAR
(Objekt-Management-System
Clausthal Approach Relational)
 Weitere Verbesserungen und
Aktualisierungen an EXTREM
und OSCAR bis 1992
1. Entwicklungsgeschichte
Grundlegendes Zugriffsmittel auf die
Daten der internen Ebene:

–
–
Benutzung von höheren
Anfragesprachen:

–
–


Generische Updates
Objektalgebra
O2QL (Object-oriented Query Language)
 SQL-kompatibel
`Living in a Lattice´(regelbasiert)
Datenbankprogrammiersprache (DBPL)
Methodendefinitionssprache MEDEL
(Method Definition Language)
1. Entwicklungsgeschichte
Interne Ebene



höhere
Anfragesprachen
DBPL
MEDEL
Zugriff auf
ORCARegeln
DATEN
1. Entwicklungsgeschichte



1997 Entwicklung von ORCA (OSCAR
Rules – confluent and terminating
approach) durch
Prof.Dr. Thomas Weik (Uni Rostock 
ehem. Mitglied der Projektgruppe um
Prof. A. Heuer)
= Sprache zur Erzeugung von
Produktionsregeln u. deren
Semantik
Veröffentlicht in: „Terminierung und
Konfluenz in einer aktiven
objektorientierten Datenbank“
2. Einordnung in das
Themenfeld „Aktive DB“
Durch Definition von
Produktionsregeln wird aus einem
(passiven) DBS ein aktives DBS
Vorteile:


–
Selbstständige Reaktion auf das
Auftreten von verschiedensten
Ereignissen
– Ausführung vorab definierter Aktionen
– Sehr flexibler Mechanismus (für
verschiedenste Probleme im DatenbankKontext einsetzbar)
2. Einordnung in das
Themenfeld „Aktive DB“
Beispiele für den Einsatz dieser
Mechanismen (Produktionsregeln):

–
–
–
–
Automatische Überwachung sehr
komplexer temporaler
Integritätsbedingungen in der DB
Verwaltung materialisierter Sichten
Zugriffsschutz feiner Granularität
realisierbar
… Ständig neue Erweiterungen und
Anwendungsgebiete
3.1 Datenmodell EXTREM

Unterscheidung zwischen Werten
und Objekten
– Werte hinreichend durch sich selbst
beschrieben (Bsp.: numerischer
Wert 1)
– Objekte (abstrakt)



müssen explizit erzeugt werden,
besitzen dann eine eindeutige Identität,
Eigenschaften werden durch Werte und
andere Objekte beschrieben
3.1 Datenmodell EXTREM
– Typen beschreiben Mengen von
Werten zusammen mit den dafür
verfügbaren Operationen
– Klassen



Können mit Containern für Objekte
verglichen werden
Beschreiben der gemeinsamen Struktur
(m.H. von Typen)
Beschreiben des gemeinsamen
Verhaltens (m.H. von Methoden)
3.1 Datenmodell EXTREM
EXTREM - Beispielschema
3.2 Datenbanksystem
OSCAR
–
–
OSCAR besitzt eine streng definierte formale
Basis ( zur Beweisführung)
OSCAR bietet:


–
–
Generische Update-Operationen
Methoden
OSCAR stellt eine Klassenverband mit
Inklusionseigenschaften zur Verfügung
Objekterhaltende Anfragen, werden in der auf
OSCAR basierenden Anfragesprache O2QL
getätigt
4. ORCA - Syntax und
Optionen
– ORCA dient zur Definition von ECA-
Regeln für das OODBMS OSCAR
– Liefert eine formale Semantik
– ORCA erfüllt fast alle Forderungen des
Manifestos für aktive DBMS
– Unter Semantik wird in ORCA nicht wie in
den meisten Systemen das Verhalten der
Implementierung verstanden, sondern die
Definition einer exakten
Regelausführungssemantik
4. ORCA - Syntax und
Optionen

Syntax einer Regeldefinition in ORCA:
CREATE RULE name [DEFERRED|IMMEDIATE|DECOUPLED]
ON Event {OR Event | AND THEN Event}
[IF Condition]
THEN DO Action
[PRECEDES RuleNameList]
[FOLLOWS RuleNameList]
RuleNameList ist eine durch Kommata getrennte
Liste von Namen bereits definierter Regeln
 Partielle Ordnung auf den Regeln
4. ORCA - Syntax und
Optionen

Definition eines Event in ORCA:
Operation TO
Classexp[.Attribut]
[WHERE Selectexp]
Classexp ist ein Ausdruck, der eine abgeleitete
Klasse definiert.
Attribut ist ein Attribut, das für eine abgeleitete
Klasse definiert ist.
Selectexp ist der WHERE-Teil eines
Selektionsausdruckes aus der
Anfragesprache O2QL
4. ORCA - Syntax und
Optionen
• Verfügbare Optionen - Regelbedingungen:
DEFERRED: Regelbedingung wird am Ende der
Wurzeltransaktion ausgewertet, in der das
Ereignis eingetreten ist (Ausführung direkt
nach der Auswertung der Bedingung
 DEFAULT)
IMMEDIATE: Regelbedingung wird unmittelbar nach
Eintreten des Ereignisses überprüft
(Ausführung der Aktion erfolgt sofort, falls
Bedingung TRUE)
DECOUPLED: bei wahrer Bedingung
 Start in einer neuen Wurzeltransaktion
4. ORCA - Syntax und
Optionen

Definition einer Operation in ORCA:
Operation:= INSERTUPDATEINCREASE
DECREASEDELETERETRIEVE
Methodname
Methodname ist ein Methodenaufruf.
INCREASE der entsprechende Attributwert vor der
UPDATE – Operation > als der Attributwert
nach der UPDATE – Operation, damit das
Ereignis eintritt.
DECREASE analog zu INCREASE.
4. ORCA - Syntax und
Optionen

Atomare Ereignisse in ORCA:
INCREASE TO Angestellte.Gehalt
WHERE Alter > 40
Ein atomares Ereignis e ist ein 4-Tupel e=(O,C,A,S):
• O ist eine Operation (hier: INCREASE)
• C ist ein nicht leerer Ausdruck mit Namen bereits
definierter Klassen als Operanden und den
Mengenoperatoren \ (hier: Angestellte)
• A ist eine Menge von Attributnamen (hier: {Gehalt} )
• S ist ein WHERE-Teil eines O2QLSelektionsausdrucks (hier: Alter > 40)
4. ORCA - Syntax und
Optionen

Beispiel für eine Regel in ORCA:
CREATE RULE zu_alt IMMEDIATE
ON INCREASE TO Angestellte.Alter WHRERE NEW.Alter >= 60
THEN DO DELETE FROM Angestellte WHERE Alter >= 60;
• Die Regel zu_alt ist eine IMMEDATE-Regel
• sie besitzt keine Condition
• sie wird durch alle DML-Befehle ausgelöst,
die das Alter mindestens eines Angestellten –
Objektes auf mindestens 60 Jahre erhöht
5. Vergleichende Aspekte

HiPAC: Urvater, der auf ECA-Regeln
basierenden Systeme
–
–

Parallele Ausführung der Aktionen aller zum
gleichen Zeitpunkt ausgeführten Regeln
Vielzahl verschiedener Kopplungsmodi
Ingres: Vertreter der kommerziellen relat.
Datenbanksysteme mit ihren Triggern
–
–

Mächtige Ereignisdefinition
Menge der betroffenen Tupel kann durch einen
WHERE-Teil eingeschränkt werden
SAMOS: basiert auf einem
objektorientierten Datenmodell
–
Bietet eine der mächtigsten Ereignisalgebren
5. Vergleichende Aspekte
Kriterium HiPAC
Ingres
SAMOS ORCA

Mengenorientiert
Instanzorientiert
Instanzorientiert
Instanzorientiert
Updategranularität,
 Regelgranularität
E–CKopplung
Instanzorientiert,
Instanzorientiert

C–AKopplung
IMMEDIATE nur
IMMEDIATE nur
IMMEDIATE und
IMMEDIATE
und
DELAYED
DELAYED

nicht unter- unterbrechbar
brechbar
Aktionsausführung
Mengenorientiert
Mengenorientiert
IMMEDIATE nur
IMMEDIATE IMMEDIATE
IMMEDIATE und
und
und
DELAYED
DELAYED
DELAYED
unterbrechbar
unterbrechbar
5. Vergleichende Aspekte
Kriterium HiPAC

Konfliktresolution
parallel
Ingres
seriell
SAMOS
seriell
ORCA
seriell
Zustand vor
Zugriff auf nicht
alte Werte
verfügbar Eintreten des

nein, aber über
versch.
TransitionsEreignisses
Ereignis- klassen
durch Prädikate
parameter
NEW und OLD

nur einfache
Disjunktion
von DML –
Kommandos
für eine
Relation
Komplexe DisEreignisse
junktion,
Sequenz
und Hülle
sehr
Disjunktion
komplexe und
Ereignis- Sequenz
algebra
5. Vergleichende Aspekte

Ereignisalgebra von ORCA:
durchschnittliche Mächtigkeit
bezogen auf unterstützte
Operatoren zur Bildung komplexer
Ereignisse
–
–
–
Bewusste Beschränkung der
Ereignisalgebra auf die von HiPAC
bekannten Basiskonstrukte
Keine Definition von BEFORE- und INSTEAD
– Ereignissen
Keine Unterstützung von abstrakten
Transaktions- und Zeitereignissen
5. Vergleichende Aspekte

ORCA – Schlüsselworte
INCREASE und DECREASE
zur Ereignisdefinition  wird
von keinem anderen System
in der Weise unterstützt
– Vorteil: Ereignisse können exakter
spezifiziert werden  Nutzen für die
statische Analyse von Terminierung
und Konfluenz
5. Vergleichende Aspekte

Erweiterung der
Ereignisspezifikation um
Klassenausdrücke und den
WHERE-Teil
(Zugriff auf alte und neue Werte)
–
Vorteil: genauere Spezifizierung der von
der Regel betroffenen Menge von
Objekten schon im Ereignisteil einer
Regel
5. Vergleichende Aspekte
Beliebige O2QL – Anfragen in der
Condition: gleiche Mächtigkeit des
Condition-Teil im Vergleich zu
anderen Systemen
 Aktionsspezifikation:

–
–
darf sowohl Aufruf generischer Updates
als auch Methoden enthalten (andere
Systeme lassen meist nur eine Variante zu)
6. Zusammenfassung



Aktive Datenbanken haben die
Probleme der Terminierung und
Konfluenz gemein
Diese Probleme einer Regelmenge
lassen sich am besten durch eine
statische Analyse zur Definitionszeit
handhaben
Für eine exakte Behandlung der
statischen Analyse ist eine formale
Semantik notwendig
6. Zusammenfassung



ORCA zeigt, dass eine mächtige und
gleichzeitig sichere Sprache zur
Definition von ECA-Regeln möglich ist
Die meisten in ORCA aufgezeigten
Techniken zur Statischen Analyse
sind auf andere Systeme übertragbar
Wünschenswert: Erfahrungen über
den Einsatz von ORCA für komplexe
Anwendungen
7. Literatur

Weik, Thomas: Terminierung und
Konfluenz in einer aktiven
objektorientierten Datenbank,
Rostock 1997.