Vortrag: OSCAR und die Regelsprache ORCA Seminar: „Aktive Datenbanken“ FSU Jena Lehrstuhl für Datenbanken und Informationssysteme Betreuer: David Wiese Stefanie Müller

Inhalt 1. Entwicklungsgeschichte von OSCAR und der Regelsprache ORCA 2. Einordnung in das Themenfeld der aktiven Datenbanken 3. Vorstellung des Datenmodells EXTREM und des OODBMS OSCAR 4. Die Regelsprache ORCA – Besonderheiten in Syntax und Optionen 5. Vergleichende Aspekte zu anderen Regelsprachen 6. 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: – Generische Updates – Objektalgebra Benutzung von höheren Anfragesprachen: – O 2 QL (Object-oriented Query Language)  SQL-kompatibel – `Living in a Lattice´(regelbasiert) Datenbankprogrammiersprache (DBPL) Methodendefinitionssprache MEDEL (Method Definition Language)

1. Entwicklungsgeschichte Interne Ebene DATEN höhere Anfrage- sprachen DBPL MEDEL Zugriff auf ORCA- Regeln

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

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

– 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 O 2 QL getätigt 3.2 Datenbanksystem 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 - 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] 4. ORCA - Syntax und Optionen RuleNameList ist eine durch Kommata getrennte Liste von Namen bereits definierter Regeln  Partielle Ordnung auf den Regeln

Definition eines Event in ORCA: Operation TO Classexp[.Attribut] [WHERE Selectexp] 4. ORCA - Syntax und Optionen 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 O 2 QL

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

Definition einer Operation in ORCA: Operation:=  INSERT  UPDATE  INCREASE   DECREASE  DELETE  RETRIEVE  Methodname 4. ORCA - Syntax und Optionen 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.Gehalt WHERE Alter > ORCA - Syntax und Optionen 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 O 2 QL- Selektionsausdrucks (hier: Alter > 40)

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; 4. ORCA - Syntax und Optionen 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 Aspekte

KriteriumHiPACIngresSAMOSORCA Update- granularität, Regel- granularität Instanz- orientiert, Instanz- orientiert Mengen- orientiert Instanz- orientiert Mengen- orientiert E – C - Kopplung IMMEDIATE und DELAYED nur IMMEDIATE IMMEDIATE und DELAYED C – A - Kopplung IMMEDIATE und DELAYED nur IMMEDIATE IMMEDIATE und DELAYED nur IMMEDIATE Aktions- ausführung nicht unter- brechbar unter- brechbar

5. Vergleichende Aspekte KriteriumHiPACIngres SAMOS ORCA Konflikt- resolution parallelseriell 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 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 O 2 QL – 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 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

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

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