Vortrag: OSCAR und die Regelsprache ORCA

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

2. 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 Inhalt

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

4. Zugehöriges objektorientiertes Datenbanksystem: OSCAR (Objekt-Management-System Clausthal Approach Relational) Weitere Verbesserungen und Aktualisierungen an EXTREM und OSCAR bis 1992 1. Entwicklungsgeschichte

5. 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. Entwicklungsgeschichte

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

7. 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“ 1. Entwicklungsgeschichte

8. 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“

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

10. Unterscheidung zwischen Werten und Objekten Wertehinreichend 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

11. Typenbeschreiben 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

12. EXTREM - Beispielschema 3.1 Datenmodell EXTREM

13. 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 OSCAR

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

15. 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 RuleNameListist eine durch Kommata getrennte Liste von Namen bereits definierter Regeln  Partielle Ordnung auf den Regeln

16. Definition eines Event in ORCA: Operation TO Classexp[.Attribut] [WHERE Selectexp] 4. ORCA - Syntax und Optionen Classexpist ein Ausdruck, der eine abgeleitete Klasse definiert. Attribut ist ein Attribut, das für eine abgeleitete Klasse definiert ist. Selectexpist der WHERE-Teil eines Selektionsausdruckes aus der Anfragesprache O2QL

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

18. Definition einer Operation in ORCA: Operation:= ²INSERT² | ²UPDATE² | ²INCREASE² | ²DECREASE² | ²DELETE² | ²RETRIEVE² | Methodname 4. ORCA - Syntax und Optionen Methodnameist ein Methodenaufruf. INCREASE der entsprechende Attributwert vor der UPDATE – Operation > als der Attributwert nach der UPDATE – Operation, damit das Ereignis eintritt. DECREASEanalog zu INCREASE.

19. Atomare Ereignisse in ORCA: INCREASE TO Angestellte.Gehalt WHERE Alter > 40 4. 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 O2QL- Selektionsausdrucks (hier: Alter > 40)

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

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

22. 5. Vergleichende Aspekte

23. 5. Vergleichende Aspekte

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

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

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

27. 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 Aspekte

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

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

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