Deduktive und Aktive Datenbanken

Deduktive und Aktive Datenbanken
• Idee: Mehr Funktionalität (= Semantik) zu den Daten bzw. zu den Operationen auf den Daten
Operationen auf den Daten
• Deduktive Datenbanken
d k
b k
– Idee: Inferenz in die Datenbank,
Beispiel. Transitivität: Vater(x,y) und Vater(y, z) impliziert Großvater(x,z)
– Datenbank + (deduktive) Regeln
– Basiert auf formale Logik (eingeschränkte PL I)
– Regelsprache ist DATALOG – Relationen werden als Menge von Literalen (Faktenmengen betrachtet)
– Um Mengen gut verarbeiten zu können: Vorwärtsauswertung
– Gegenüber Wissensbasierten Systemen Ergänzung um Persistenz – Mehrbenutzerfähigkeit oft nicht weiter betrachtet, da nur Abfragen von expliziten und impliziten Daten untersucht
20. Prof. Jasper: Datenbanksysteme
1
Deduktive Datenbanken
• Begriffsbildung
–
–
–
–
Prädikat definiert durch Name und Stelligkeit
g
Argumente konstant => Fakt (entspricht Eintrag in einer Relation)
Regel: „Kopfliteral“ gilt dann, wenn alle „Rumpfliterale gelten“
Argumente einer Regel können Variablen sein, Scope einer Variabel ist die Regel
anton
chef(anton, bernd).
chef(anton, dirk).
chef(anton, fred).
chef(bernd, hugo).
chef(bernd, egon).
chef(fred, hugo_2).
chef(fred erwin).
chef(fred,
erwin)
bernd
h
hugo
vorgesetzter(X, Y) :- chef(X, Y).
vorgesetzter(X, Y) :- chef(X, Z),
vorgesetzter(Z,Y).
untergebener(X,Y) :- vorgesetzter(Y,X).
? vorgesetzter(X,
?vorgesetzter(X hugo
hugo_2).
2)
„Tabelle“:
liefert
20. Prof. Jasper: Datenbanksysteme
egon
dirk
fred
h
hugo_2
2
vorgesetzter fred
anton
erwin
i
hugo_2
hugo 2
hugo_2
2
Deduktive Datenbanken
• Auswertung von DATALOG‐Programmen
– „Faktdefinierte Prädikate“ werden durch Auflistung der gespeicherten Wertekombinationen ausgewertet (entspricht der Ausgabe der explizit gespeicherten Relation)
– Regeldefinierte Prädikate sind über den Kopf einer oder mehrerer DATALOG‐Regeln Regeldefinierte Prädikate sind über den Kopf einer oder mehrerer DATALOG‐Regeln
definiert
– DATALOG‐Programme müssen sicher (safe) sein:
• sie generieren eine endliche Faktenmenge
• ist i.a. nicht entscheidbar
i ti
i ht t h idb
• Beispiele
– hohes_Gehalt(Y) :‐ Y > 60000.
versus
– hohes_Gehalt(Y) :‐ angestellter(X), gehalt(X, Y), Y > 60000.
– hohes_Gehalt(Y) :‐ Y > 60000, angestellter(X), gehalt(X, Y).
• Die beiden letzten Regeln sind sicher
– Anmerkung: relationale Operatoren lassen sich in DATALOG ausdrücken
A
k
l i
l O
l
i h i DATALOG
dü k
20. Prof. Jasper: Datenbanksysteme
3
Deduktive Datenbanken
– Das Ergebnis jeder DATALOG‐Anfrage ist eine Relation (d.h. nur einzelne Prädikate als Anfrage!)
– Nicht‐rekursive Anfragen p :‐
Ni ht k i A f
p1, ..., pn. werden wie folgt berechnet: Berechen
1
d
i f l tb
h t B
h erst alle t ll
Relationen zu p1 bis pn, anschließend die Relation zu p.
– Nicht‐rekursive DATALOG‐Anfragen lassen sich in einen relationalen Ausdruck g
transformieren und dann vom DBMS bearbeiten.
– Fü
Für rekursive Anfragen betrachte:
k i A f
b
h
• Prädikate, die als Relationen in der Datenbank gespeichert sind heißen EDB‐
(
DB))
Prädikate (extensionale
• Prädikate, die über Regeln definiert sind heißen IDB‐Prädikate (intensionale DB)
• EDB und IDB sind disjunkt
• Ersetze „:‐“ in IDB durch Gleichheit „=“ => der „kleinste Fixpunkt“ des so entstehenden Gleichungssystems ist Antwortmenge rekursiver Anfragen
20. Prof. Jasper: Datenbanksysteme
4
Deduktive Datenbanken
• Naive Auswertung rekursiver DATALOG‐Programme
– Voraussetzung: Umschreibung des DATALOG‐Programms
– Jedes Prädikat wird als Relation betrachtet (Pi entspricht Ri)
– Jedes Prädikat wird definiert als relationaler Ausdruck (Ei) über alle Prädikate: Ri = Ei(R1
Ei(R1, ..., Rn)
R )
– Eingabe: Ein System algebraischer Gleichungen und die EDB
– Ausgabe: Die Relationen R1, ... Rn.
Ausgabe: Die Relationen R1, ... Rn.
For i = 1 to n do begin
if Pi aus IDB then
Pi aus IDB then Ri = 

else Ri = Tupelmenge aus EDB
end
Repeat
condition = true;
for i = 1 to n do Si = Ri;
for i = 1 to
i = 1 to n do n do
begin
Ri = Ei(S1, ..., Sn);
if Ri  Si then
Si then condition = false
false
end
until conditon;
20. Prof. Jasper: Datenbanksysteme
5
Deduktive Datenbanken
– Beispiel:
v(X,Y) :‐ e(X,Y).
v(X Y) :‐ v(X,Z), e(Z,Y).
v(X,Y) :‐
v(X Z) e(Z Y)
Rv(X,Y) = zy(Rv(X,Z)  Re(Z,Y)) Rv(Z,Y)
Re ({(bert, alice), (bert, george), (alice, derek), (alice, pat), (derek, frank)}
• Rv(0) = leer
• Rv(1) = {(bert, alice), (bert, george), (alice, derek), (alice, pat), (derek, frank)}
• Rv(2) = {(bert, alice), (bert, george), (alice, derek), (alice, pat), (derek, frank), (bert, derek), (bert, pat), (alice, frank)}
• Rv(3) = {(bert, alice), (bert, george), (alice, derek), (alice, pat), (derek, frank), (bert, derek), (bert, pat), (alice, frank), (bert, frank)}
• Rv(4) = {(bert, alice), (bert, george), (alice, derek), (alice, pat), (derek, frank), (bert, derek), (bert, pat), (alice frank) (bert frank)}
(alice, frank), (bert, frank)}
•
•
Weitere Methoden nutzen Zusatzinformation des Programms / der Abfragen, z. B. Magic‐
Set‐Methode (siehe Literatur)
Negation ist ein Problem: minimaler Fixpunkt existiert i. a. nicht! Daher stratifizierte Programme: keine Negation durch Rekursion!
Programme: keine Negation durch Rekursion!
20. Prof. Jasper: Datenbanksysteme
6
Aktive Datenbanken
• Datenbank + ECA‐Regeln = erweiterte Form der Trigger
– ECA‐Regel:
g rule_spec
::=
"RULE" rule_id
"ON" event_id
"DO" action_id
"STATUS" active | deactive
["EXPLAIN"string]
[
EXPLAIN string]
"END_RULE"
– Ereignisse: atomar oder komplex:
• Atomare Ereignisse
– Einfügen, Löschen und Ändern sowie Lesen von Daten
– Ereignisse des Zeitmodells: Das zugrundeliegende Zeitmodell basiert auf Teilen des Intervalkalküls erweitert um absolute und relative Zeitpunkte als Zeitobjekte. Zeitereignisse werden durch Zeitpunkte (T_POINT) und Zeitintervalle (T_INTERVAL) ausgewiesen. Sie können absolut, durch Angabe von [Jahr.Monat.Tag/Stunde:Minute] (bei Intervallen durch Angabe des exakten, absoluten Anfangs‐ und Endzeitpunkts), sowie relativ in Bezug zu einem anderen Ereignis (E1 + [0.0.0/00:20]) definiert werden.
– Weitere atomare Ereignisse: Durch Integration von aktiven abstrakten Datentypen (AADT, siehe auch ADT für ORDMBS, z.B. Statistik‐AADT, Geo‐AADT, User‐Interface‐
AADT
20. Prof. Jasper: Datenbanksysteme
7
Aktive Datenbanken
• Komplexe Ereignisse als Ausdrücke einer entsprechenden Ereignissprache:
event_type
t t
::=
simple_event
i l
t
| comp_event
| "["simple_event "WEHRE" condition"]"
| "["comp
[ comp_event
event "WERE"
WERE condition
condition"]"
]
simple_event
::=
database_event
| time_event
| user_event
| geo_event
| statistic_event
comp_event
::=
event_id
| event_type "AND" event_type
| event_type "OR" event_type
| "NOT" event_type
| "SEQ" "("event_type
"("
t t
{" " event_type}")"
{","
t t
}")"
| "COUNT" num "OF" event_type
Desweiteren kann jedes Ereignis (atomar oder komplex) mit einer eindeutigen Identifikation versehen werden, indem der
gebildete Ausdruck als Objekt spezifiziert wird.
event_spec
::=
"EVENT" event_id
"DEFINITION" event_type
"END_EVENT"
20. Prof. Jasper: Datenbanksysteme
8
Aktive Datenbanken
– Bedingungen:
• Sind hier mit den Ereignissen verknüpft
• Andere Ansätze separate Bedingungen entsprechend der„WHERE“‐Klausel von SQL
– Aktionen:
• Hier analog der externen Prozeduren von SQL:2003:
g
Q
action_spec
::=
"ACTION" action_id ["("parameter_list")"]
"METHOD CALLS" "("method_name
"METHOD_CALLS"
"(" th d
["("
["("parameter_list")"]
t
li t")"]
{","method_name["("parameter_list")"]}
")"
"END ACTION"
"END_ACTION"
20. Prof. Jasper: Datenbanksysteme
9
Aktive Datenbanken
• Anwendungsbeispiel: Geschäftsregeln und ‐prozesse
• Geschäftsregel
• Beschreibt
Beschreibt Bedingungen bzgl. betriebswirtschaftlich relevanter Objekte (Kunde, Bedingungen bzgl betriebswirtschaftlich relevanter Objekte (Kunde
Vertrag, Rechnung, Lieferung, Mitarbeiter, ...).
• Geschäftsprozess
• steuert und dokumentiert die Durchführung von Geschäftsvorfällen unter Berücksichtigung von Geschäftsregeln.
• besteht aus einer partiell geordneten Menge von Funktionen auf besteht aus einer partiell geordneten Menge von Funktionen auf
betriebswirtschaftlich relevanten Objekten (Auftragsbearbeitung, Krankmeldung, etc.).
• integriert externe Partner
20. Prof. Jasper: Datenbanksysteme
10
Aktive Datenbanken
• Beispiel: Krankmeldung (Geschäftsprozess)
Mitarbeiter
Personalabteilung
Geschäftsregel:
5 Tage
“Falls ein erkrankter Mitarbeiter nach 5 Tagen die Arbeit nicht wieder aufgenommen hat: Auftragsbearbeitung anpassen.”
20. Prof. Jasper: Datenbanksysteme
Fachabteilung
11
Aktive Datenbanken
• Beschreibung der obigen Geschäftsregel mittels ECA:
•
EEreignis: Änderung
i i Ä d
eines Zustands oder Nachricht
i
Z
d d N h i h von außen
ß
– Krankmeldung
– Termin überschritten
– Eingang eines Antrags
– ...
•
Bedingung: Prädikat
di
dik bzgl. eines Zustands
b l
d oder einer Zustandsfolge
d
df l
– Datum hat falschen Wert
– Antrag hat definierten Zustand
g
– ...
•
Aktion: Aufruf einer Funktion bzw. Nachricht nach außen
– Meldung an zuständige(n) Fachabteilung(smanager)
– Meldung des falschen Wertes
– Versenden des Antrags an zuständigen Sachbearbeiter
g
g
– ...
20. Prof. Jasper: Datenbanksysteme
12
Aktive Datenbanken
• Abstrakte Realisierungsarchitektur
Anwendungen
Abfrage
Antwort
Änderung
Ereignis
DB‐
Ereignis
Datenbankverwaltungssystem
DML
QL
Regelverwaltungssystem
Regel‐
Regel‐
spezifikation
ifik ti
verwaltung
lt
Ereignis‐
Bedingungs‐
überwachung prüfung
Erklärungs‐
k
komponente
t
Aktions‐
ausführung
Aktive Regeln
Datenbank
Regel
Tab A B C
Situation
Aktion
Ereignis
g
Bedingung
g g
20. Prof. Jasper: Datenbanksysteme
13
Aktive Datenbanken
• Anwendungsszenario: Aktives Informationssystem (AIS)
AIS
Auffälligkeiten
Abfragen / Änderungen
Betriebliche Daten
Antworten
Anwender
Regeln
Zeit
DB
Geo‐ & Umweltdaten
20. Prof. Jasper: Datenbanksysteme
14
Aktive Datenbanken
• Ereignisse in aktiven Informationssystemen
– Datenbank
• Update (Einfügen, Ändern, Löschen)
• Lesen
– Benutzungsschnittstelle
• Menüauswahl
• Objektselektion
• Fenster‐/ Applikationswechsel
EVENT Mitarbeiter_meldet_krank =
INSERT_DB (...)
END EVENT
– Applikation
• spezifisch
– Umgebung
• Mail, Internet
– Kombinationen
• Algebra: AND, OR, NOT, COUNT
20. Prof. Jasper: Datenbanksysteme
15
Aktive Datenbanken
• Bedingungen und Aktionen in aktiven Informationssystemen
– Bedingungen:Prädikate über
• Datenbankzustand
• Ereignisparameter
• Anwendungszustand
“IF Projekt.Mitarbeiter = Projekt.Manager“
– Aktionen: Programmfragmente
Akti
P
f
t
• Sprachabhängig
Imperative Kontrollstrukturen
• Imperative Kontrollstrukturen
• Berechnungsvollständig ACTION
BEGIN
Mail (“Bitte Vertretung für Mitarbeiter X übernehmen”)
END ACTION.
20. Prof. Jasper: Datenbanksysteme
16
Aktive Datenbanken
• Regeln in aktiven Informationssystemen
RULE Lange_Krankheit
ON Lange
O
a ge_Krank(P)
a ( )
DO Projekt.Anpassen(P)
END RULE.
EVENT Lange
Lange_Krank(P)
Krank(P) =
Mitarbeiter.Erkrankung(P)
AND NOT Mitarbeiter.Gesund(P)
BETWEEN
(Mitarbeiter.Erkrankung(P).Timestamp,
Mitarbeiter.Erkrankung(P).Timestamp+ 5 DAYS)
END EVENT
ACTION Projekt.Anpassen(P)
Projekt Anpassen(P)
BEGIN
...
END ACTION.
20. Prof. Jasper: Datenbanksysteme
17
Aktive Datenbanken
• Anwendungsbeispiel Geschäftsregel (s.o.)
Mitarbeiter
P
Personalabteilung
l bt il
Fachabteilung
aDB
20. Prof. Jasper: Datenbanksysteme
18
Aktive Datenbanken
• Anwendungsbeispiele AIS
Ereignisse
EIS
Active_EIS (Studie)
48 ET; 180 Attr.
Krebs-Epidemiologie
Active_INEKS (Prototyp)
Active_WfM (Prototyp)
Fremdsysteme
• Budget überschritten • Fachbereich warnen
• Exmatrikulation
E
t ik l ti
• St
Statistik
ti tik berechnen
b
h
• SAP R/3
• HIS
• Neuer Krebsfall
• Signifikanter Wert
• Statistik berechnen
• Epidemiologen
informieren
• Statistik
• GIS
• Objekt bearbeiten
• Bearbeiter
B b it erkrankt
k kt
• Objekt umleiten
• Ablauf
Abl f äändern
d
• Scanner
• Mail
M il Tool
T l
• Meilenstein
• Fehlerzahl zu hoch
• Qualität sichern
• Manager warnen
• SE-Werkzeuge
• Mail Tool
87 Regeln; 18 ET
Workflow Management
Aktionen
WfM-DB; generiert aus FDL
bzw. ARIS
PCSE
Active_CASE (Prototyp)
240 Regeln; 90 ET; 480 Attr.
20. Prof. Jasper: Datenbanksysteme
19
Aktive Datenbanken
• Erfahrungen mit aktiven Datenbanken und Informationssystemen
•
Modell
• Ereignisorientierte Regelsprache
• Konzept zur Integration externer Komponenten
K
t
I t
ti
t
K
t
•
Implementierung
• Basis: relationale & objektorientierte DBMS
Basis relationale & objektorientierte DBMS
• Offene Systeme notwendig
• Standards wie CORBA hilfreich
•
Anwendungen
• Ereignisorientierung bewährt
g
g
• Zeitinformationen differenziert
• Systemintegration möglich
• Offene Systeme selten
ff
l
• Standards (noch) nicht berücksichtigt
Verhalten großer Regelmengen unbekannt
großer Regelmengen unbekannt
• “Verhalten”
20. Prof. Jasper: Datenbanksysteme
20