S wiss A ctive M echanism based O bject-oriented Database S ystem

Swiss Active Mechanism based Object-oriented Database

System

Aktive Datenbanken SS2007 Yves Laske

Aktive Datenbanken

Fahrplan

1 Grundsätzliches

2 Ereignisarten

3 Regeldefinition

4 SAMOS-Architektur

5 Kritische Wertung

Swiss Active Mechanism based Object-oriented Database System


1 Grundsätzliches


„60 Minuten nach Buchung auf dem Waren-eingangskonto, jedoch nur vormittags…“


1 Grundsätzliches



• SAMOS als Prototyp eines aDBS• Umfasst eigene Architektur/

Implementierung und Ereignissprache• Entwicklung an der Universität Zürich

seit 1991, Ende der 90er Jahre abgeschlossen

• Vertreter: Stella Gatziu, Klaus R. Dittrich

• Es erfolgte keine Veröffentlichung

1 Grundsätzliches



• SAMOS auf kommerziellen DBMS ObjectStore auf

• Läuft auf SUN-Rechnern unter UNIX• Objektorientierung in SAMOS:

– Aktive Mechanismen mit Obj.-or. Eigenschaften realisiert

– Ereignisse und Regeln sind Objekte

• Ziel: Ausdrucksstarkes Konzept zur Modellierung komplexer Umwelt-

situationen

2 Ereignisarten



a) Primitive Ereignisse• Zeitereignisse

Absolute: 07.06.21,09:30Wiederkehrende: EVERY [frequency]

(YEAR|DAY|HOUR|MINUTE) <time>

[interval] EVERY 10 DAY 20:00 06.01.-07.31.Implizite: Eintritt aufgrund anderer Ereignisse occ_point(event_name) end_execution(rule_name)

2 Ereignisarten



• Methodenereignisse– Objekte kommunizieren durch Nachrichten– Nachrichten lösen Methoden aus– Methoden brauchen Zeitdauer zur Ausführung– BEFORE oder AFTER als Schlüsselwörter

(BEFORE|AFTER).(class_name|object_name|*).method_name

Klasse Ort, Methode Freie_Zimmer():integer BEFORE.Siegmundsburg.Freie_Zimmer

• WertereignisseOperationen auf dem Wert eines Objektes(BEFORE|AFTER).(class_name|object_name).update(attr_name)

2 Ereignisarten



• TransaktionenereignisseZu Beginn oder Ende der TA(BOT|EOT|ABORT)[transaction_name]

• Abstrakte EreignisseFestlegung nicht automatisch erkennbarer EreignisseDEFINE EVENT Zimmer_AbgebranntRAISE Zimmer_Abgebrannt

2 Ereignisarten



b) Zusammengesetzte Ereignisse• Ereigniskonstruktoren

Möglichkeit der Ereigniskombination

Konjunktion (E1,E2) Beide eingetreten,

Reihenfolge beliebig

Disjunktion (E1|E2) Eines von beiden

Sequenz (E1;E2) Beide in der angegebenen Reihenfolge

Negation NOT E Nichteintritt

*-Operator *E Signalisierung nur beim ersten Auftritt

2 Ereignisarten



Historische Ereignisse:Bei Relevanz der Auftrittshäufigkeit

TIMES(n,E)

TIMES([n1,n2],E)

3 Regeldefinition



• Kommunikationsmedium des Anwenders (Entwicklers)

• Basiert auf spezieller Syntax zum Beschreiben von Szenarien

• Umsetzung der ECA-Regeln

• Zahlreiche Methoden zum Arbeiten mit Ereignissen bereitgestellt z.B. occ_point(event_name),…

3 Regeldefinition



DEFINE RULE <rule_name>ON <event_clause>IF <condition>DO <action>COUPLING MODE (<coupling>,<coupling>)PRIORITIES (BEFORE | AFTER) <rule_name>

I.d.R. wird jedes Ereigniss vorab deklariert:

DEFINE EVENT <event_Name><event_clause>

3 Regeldefinition



„60 Minuten nach Buchung auf dem Wareneingangs-konto, jedoch nur vormittags erfolgt Parallelbuchung auf Konto K1“

DEFINE EVENT PB

Einkauf.Buchung_erfolgt

DEFINE RULE R1

ON PB

IF if((occ_point(PB)+01:00) < 12:00)

DO Einkauf.PB_K1

COUPLING MODE (immediate,deferred)

3 Regeldefinition



Coupling ModeWann Bedingungsauswertung bzw. Aktionsausführung beginnen• Immediate: direkt nach Ereignisauslösung, nach

Bedingungsauswertung• Deferred: Am Ende der auslösenden TA, nach

Bedingungsauswertung• Decoupled: Ausweisung in separate TA

COUPLING MODE (<coupling1>,<coupling2>)

coupling1: Wann wird Bedingung ausgeführt?

coupling2: Wann wird Aktion ausgeführt?

4 SAMOS-Architektur



3-SchichtenarchitekturVorteil der Schichtenarchitektur:

schnellere Implementierung

Schichten:• Objektorientiertes DBMS• SAMOS-Kern• Toolschicht

4 SAMOS-Architektur



Untere Schicht: DBMS-Ebene als Black-Box• DBMS ObjectStore (Object Design)• C++-Implementierung• Regeldefinitionen sind Instanzen der Klasse rule• Speicherung von Regeln und Ereignissen in

ObjectStore als Objekt

4 SAMOS-Architektur



Mittlere Schicht: SAMOS-Kern• Funktionale Elemente zur

Ereigniserkennung • Ausführung zur Laufzeit

4 SAMOS-Architektur



Obere Schicht: Toolebenea) Vorabtools zur Regeldefinition

– Editor/Compiler– Termination Analyzer– Browser

b) Laufzeittools– Testing Component (vollst. Testumgebung)– Explanation Component (Visualisierung aktueller

Vorgänge)

4 SAMOS-Architektur



„SAMOS in Hindsight: Experiences in Building an Active Object-Oriented BDMS“

5 Kritische Wertung



• Ereignissprache mächtig, teilw. Zu komplex

• Beast-Benchmark als Indikator zur Performancesteigerung

• Event-Detector ist maßgebend für Performance

• Abhängigkeit vom DBMS problematisch

Literatur



S. Gatziu, A. Geppert, K.R. Dittrich. The SAMOS Active DBMS Prototype (Demonstration). Proc. ACM SIGMOD Int’l Conf. on Management of Data, San Jose, CA, May 1995.

S. Gatziu, K.R. Dittrich: Events in an Active Object-Oriented Database System. In N.W. Paton, H.W. Williams (eds): Proc. Workshop on Rules in Database Systems, Edinburgh, UK, September 1993 (Workshops in Computing, Springer-Verlag, 1994).

S. Gatziu, K.R. Dittrich: Detecting Composite Events in an Active Database Systems Using Petri Nets. Proc. of the 4th Intl. Workshop on Research Issues in Data Engineering: Active Database Systems, Houston, February 1994.

K.R. Dittrich, H. Fritschi, S. Gatziu, u.a.: SAMOS in Hindsight: Experiences in Building an Active Object-Oriented DBMS. Database Technology Research Group. Technical Report 2000.05, Zurich, 2000.

S. Gatziu, K.R. Dittrich: Eine Ereignissprache für das aktive, objektorientierte Datenbanksystem SAMOS. Datenbanksysteme in Büro, Technik und Wissenschaft, 1993.

Documents

S wiss A ctive M echanism based O bject-oriented Database S ystem