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
Recommended