Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Mona Ziegler Geändert vor über 8 Jahren
1
25. 6. 2007 Vortrag: OSCAR und die Regelsprache ORCA Seminar: „Aktive Datenbanken“ FSU Jena Lehrstuhl für Datenbanken und Informationssysteme Betreuer: David Wiese Stefanie Müller
2
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
3
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
4
1. Entwicklungsgeschichte Zugehöriges objektorientiertes Datenbanksystem: OSCAR (Objekt-Management-System Clausthal Approach Relational) Weitere Verbesserungen und Aktualisierungen an EXTREM und OSCAR bis 1992
5
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)
6
1. Entwicklungsgeschichte Interne Ebene DATEN höhere Anfrage- sprachen DBPL MEDEL Zugriff auf ORCA- Regeln
7
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“
8
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)
9
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
10
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
11
– 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
12
EXTREM - Beispielschema
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 O 2 QL 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 RuleNameList ist 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 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
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 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.
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 O 2 QL- 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
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
23
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
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 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
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
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.