25. 6. 2007

Vortrag: Vortrag: OSCAR und die OSCAR und die

Regelsprache ORCARegelsprache ORCASeminar: „Aktive Datenbanken“

FSU JenaLehrstuhl für Datenbanken und InformationssystemeBetreuer: David Wiese

Stefanie Müller

InhaltInhalt1. Entwicklungsgeschichte von OSCAR

und der Regelsprache ORCA2. Einordnung in das Themenfeld der

aktiven Datenbanken3. Vorstellung des Datenmodells EXTREM

und des OODBMS OSCAR4. Die Regelsprache ORCA –

Besonderheiten in Syntax und Optionen5. Vergleichende Aspekte zu anderen

Regelsprachen6. Zusammenfassung

1. Entwicklungsgeschichte1. 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. Entwicklungsgeschichte1. Entwicklungsgeschichte Zugehöriges objektorientiertes

Datenbanksystem: OSCAR(Objekt-Management-System Clausthal Approach Relational)

Weitere Verbesserungen und Aktualisierungen an EXTREM und OSCAR bis 1992

1. Entwicklungsgeschichte1. Entwicklungsgeschichte Grundlegendes Zugriffsmittel auf die

Daten der internen Ebene: – Generische Updates– Objektalgebra

Benutzung von höheren Anfragesprachen:– O2QL (Object-oriented Query Language)

SQL-kompatibel– `Living in a Lattice´(regelbasiert)

Datenbankprogrammiersprache (DBPL) Methodendefinitionssprache MEDEL

(Method Definition Language)

1. Entwicklungsgeschichte1. EntwicklungsgeschichteInterne Ebene

DATEN

höhere Anfrage-sprachen

DBPL MEDEL

Zugriff auf

ORCA-Regeln

1. Entwicklungsgeschichte1. 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 2. Einordnung in das Themenfeld „Aktive DB“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 Datenbank-Kontext einsetzbar)

2. Einordnung in das 2. Einordnung in das Themenfeld „Aktive DB“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

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 EXTREM3.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 EXTREM3.1 Datenmodell EXTREM

3.1 Datenmodell EXTREM3.1 Datenmodell EXTREM

EXTREM - Beispielschema

– 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

3.2 Datenbanksystem 3.2 Datenbanksystem OSCAR OSCAR

– 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 - 4. ORCA - Syntax und Syntax und OptionenOptionen

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]

4. ORCA - 4. ORCA - Syntax und Syntax und OptionenOptionen

RuleNameList ist eine durch Kommata getrennte Liste von Namen bereits definierter Regeln Partielle Ordnung auf den Regeln

Definition eines Event in ORCA:Operation TOClassexp[.Attribut][WHERE Selectexp]

4. ORCA - 4. ORCA - Syntax und Syntax und OptionenOptionen

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 - 4. ORCA - Syntax und Syntax und OptionenOptionen

• 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

Definition einer Operation in ORCA:Operation:=

INSERTUPDATEINCREASEDECREASEDELETERETRIEVEMethodname

4. ORCA - 4. ORCA - Syntax und Syntax und OptionenOptionen

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.

Atomare Ereignisse in ORCA:INCREASE TO Angestellte.GehaltWHERE Alter > 40

4. ORCA - 4. ORCA - Syntax und Syntax und OptionenOptionen

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 O2QL-Selektionsausdrucks (hier: Alter > 40)

Beispiel für eine Regel in ORCA:

CREATE RULE zu_alt IMMEDIATEON INCREASE TO Angestellte.Alter WHRERE NEW.Alter >= 60THEN DO DELETE FROM Angestellte WHERE Alter >= 60;

4. ORCA - 4. ORCA - Syntax und Syntax und OptionenOptionen

• 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

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 Aspekte5. Vergleichende Aspekte

5. Vergleichende Aspekte5. Vergleichende AspekteKriterium HiPAC Ingres SAMOS ORCA Update-granularität, Regel-granularität

Instanz-orientiert,Instanz-orientiert

Mengen-orientiertInstanz-orientiert

Instanz-orientiertInstanz-orientiert

Mengen-orientiertMengen-orientiert

E – C -Kopplung

IMMEDIATE und DELAYED

nur IMMEDIATE

IMMEDIATE und DELAYED

IMMEDIATE und DELAYED

C – A -Kopplung

IMMEDIATE und DELAYED

nur IMMEDIATE

IMMEDIATE und DELAYED

nur IMMEDIATE

Aktions-ausführung

nicht unter-brechbar

unter-brechbar

unter-brechbar

unter-brechbar

5. Vergleichende Aspekte5. Vergleichende AspekteKriterium HiPAC Ingres SAMOS ORCA Konflikt-resolution

parallel seriell seriell seriell

Zugriff auf alte Werte

nicht verfügbar

Zustand vor Eintreten des Ereignisses durch Prädikate NEW und OLD

nein, aber versch. Ereignis-parameter

über Transitions-klassen

Komplexe Ereignisse

Dis-junktion, Sequenz und Hülle

nur einfache Disjunktion von DML – Kommandos für eine Relation

sehr komplexe Ereignis-algebra

Disjunktion und Sequenz

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 Aspekte5. 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 Aspekte5. 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 Aspekte5. 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)

5. Vergleichende Aspekte5. Vergleichende Aspekte

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 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

6. Zusammenfassung 6. Zusammenfassung

Weik, Thomas: Terminierung und Konfluenz in einer aktiven objektorientierten Datenbank, Rostock 1997.

7. Literatur 7. Literatur