PDF file - IDB - Universität Bonn

Diplomarbeit
Entwurf und Realisierung eines datenbankgestützten Systems
zur Simulation und Überwachung mobiler Objekte auf
Netzwerken
von
Dennis Wegener
Institut für Informatik III
Rheinische Friedrich-Wilhelms-Universität Bonn
Prof. Dr. R. Manthey
31.03.2006
Inhaltsverzeichnis
1 Einführung
1
2 Datenbanken
2
2.1
2.2
2.3
Deduktive Datenbanken
. . . . . . . . . . . . . . . . . . . . . . . . .
2
2.1.1
Einführung
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.2
Syntax von Datalog . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.3
Semantik von Datalog
. . . . . . . . . . . . . . . . . . . . . .
8
2.1.4
Änderungspropagierung
. . . . . . . . . . . . . . . . . . . . .
10
MS Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2.1
Jet SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.2
Visual-Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.3
DAO und ADO . . . . . . . . . . . . . . . . . . . . . . . . . .
12
ODBC und JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3 SIMON
15
3.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2
Überwachung von Datenströmen durch kontinuierliche Anfragen . . .
17
3.2.1
Monitoring
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.2
Datenströme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.2.3
Kontinuierliche Anfragen über Datenströmen . . . . . . . . . .
22
Gesamtarchitektur SIMON . . . . . . . . . . . . . . . . . . . . . . . .
23
3.3
i
ii
Inhaltsverzeichnis
3.4
MOSIM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.5
VISMONET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.6
Monitor
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.7
Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.7.1
Architektur
31
3.7.2
Beispiel zur Kompilierung
3.7.3
Einbettung des Compilers in MS-Access
3.8
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
36
Beipsielszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4 Überwachung von Datenströmen in SIMON
4.1
4.2
4.3
34
39
Klassikation von Datenstrom-Anwendungen . . . . . . . . . . . . . .
39
4.1.1
Klassikationsschema . . . . . . . . . . . . . . . . . . . . . . .
40
4.1.2
SIMON
42
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ansätze zur Überwachung von Datenströmen in SIMON
. . . . . . .
44
. . . . . . . . . . . . . . . . .
46
4.2.1
Datenbankmanagementsysteme
4.2.2
rule engines
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.2.3
Datenstrommanagementsysteme . . . . . . . . . . . . . . . . .
48
4.2.4
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
Ein Ansatz zur DBMS-gestützten Analyse von Datenströmen . . . . .
53
4.3.1
Prinzipielle Vorgehensweise
. . . . . . . . . . . . . . . . . . .
53
4.3.2
Architektur
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.3.3
Inkrementelle Beantwortung kontinuierlicher Anfragen
. . . .
56
Inhaltsverzeichnis
iii
5 Spezialisierung von SQL-Sichten
62
5.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5.2
Mengen- vs. Multimengensemantik
. . . . . . . . . . . . . . . . . . .
63
5.3
Ansatz mit Mengensemantik . . . . . . . . . . . . . . . . . . . . . . .
64
5.3.1
Delta- und Transitionssichten
. . . . . . . . . . . . . . . . . .
64
5.3.2
Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
Alternativer Ansatz mit Multimengensemantik . . . . . . . . . . . . .
69
5.4.1
Duplikate
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
5.4.2
Eektivitäts- vs Wirksamkeitstest . . . . . . . . . . . . . . . .
70
5.4.3
Delta Regeln
71
5.4.4
Delta-Regeln: Das OR-Problem
5.4.5
Möglichkeiten der Umsetzung
5.4
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
73
. . . . . . . . . . . . . . . . . .
76
6 SIMON II
78
6.1
Gesamtarchitektur
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
6.2
MOSIM II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
6.3
Monitor
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1
Architektur
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
6.3.2
Inputmanager . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.3.3
Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
6.3.4
CQ-Manager
. . . . . . . . . . . . . . . . . . . . . . . . . . .
91
6.4
VISMONET II
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
6.5
Schnittstellen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
6.6
Beispiel-Szenario (ICE-Verkehr) . . . . . . . . . . . . . . . . . . . . . 101
7 Zusammenfassung und Ausblick
102
Literaturverzeichnis
103
Anhang
107
Kapitel 1
Einführung
1
Kapitel 2
Datenbanken
In diesem Kapitel werden die in dieser Arbeit verwendeten Grundlagen hinsichtlich
der Themen deduktive Datenbanken, MS Access sowie der Anbindung von Datenbanken an Anwendungsprogramme vorgestellt. In Abschnitt 2.1 wird eine Einführung in das Thema Deduktive Datenbanken gegeben, die sich im Wesentlichen an
[Man04] und [Pie01] orientiert. Der Ansatz zur datenbankgestützten Überwachung
beruht auf einigen Konzepten deduktiver Datenbanken und wird innerhalb einer
Analysekomponente realisiert. Im Besonderen wird daher auf die deduktive Datenbanksprache Datalog eingegangen, in deren Kontext das der Analysekomponente
zugrundeliegende Prinzip der Änderungspropagierung dargestellt wird. Die Implementierung basiert auf dem relationalen Datenbankmanagementsystem Access von
Microsoft, welches in Abschnitt 2.2 vorgestellt wird. Abschnitt 2.3 beschreibt die
Anbindung von Datenbanken an Anwendungsprogramme, insbesondere hinsichtlich
der objektorientierten Programmiersprache Java, in der die Simulations-, Visualisierungs und Teile der Analysekomponente implementiert sind.
2.1
Deduktive Datenbanken
Im Folgenden wird eine Einführung in das Thema deduktive Datenbanken gegeben und die relationale, deduktive Datenbanksprache Datalog vorgestellt. Obwohl
Datalog weitgehend als Standardsprache der Forschung im Bereich deduktiver Datenbanken gilt, hat sich nur hinsichtlich der Regelsprache ein Quasi-Standard etabliert ([Pie01]). Für die beiden anderen Teilsprachen Datenmanipulation (DML) und
Datendenition (DDL) existieren verschiedene Ansätze. In Abschnitt 2.1.1 werden
Grundbegrie deduktiver Datenbanken eingeführt. Die Abschnitte 2.1.2 und 2.1.3
beschreiben Syntax und Semantik von deduktiven Regeln und Änderungen in Datalog. Abschnitt 2.1.4 befasst sich schlieÿlich mit dem Prinzip der Änderungspropagierung im Kontext von Datalog. Auf eine Einführung in die Datendenitionssprache,
2
2.1
Deduktive Datenbanken
3
die Syntax und Semantik von Anfragen sowie Integritätsbedingungen wird an dieser
Stelle verzichtet und statt dessen auf [Man04] verwiesen.
2.1.1 Einführung
Ein deduktives Datenbanksystem erlaubt zusätzlich zu den üblichen Funktionalitäten eines DBMS die Spezikation, Verwaltung und Anwendung von Sichten und
Integritätsbedingungen ([Man04]). Eine deduktive Datenbank enthält neben explizit gespeicherten Daten (Basisfakten) eine Menge von Regeln. Diese Regeln stellen
zusätzliches anwendungsspezisches Wissen dar und sind unterteilt in deduktive
Regeln (Sichten, views) und normative Regeln (Integritätsbedingungen und Assertions, constraints). Mit Hilfe deduktiver Regeln (Sichtdenitionen) in der Datendenitionssprache (DDL) des verwendeten Datenmodells lassen sich ableitbare
Informationen darstellen. Prinzipieller Aufbau einer solchen deduktiven Regel ist
ein deklarativer Ausdruck der Form Regelkopf
← Regelrumpf ,
wobei der Re-
gelkopf ein Muster für eine Informationseinheit einer ableitbaren Datenmenge und
der Regelrumpf eine denierende Anfrage ist. Der Ausdruck beschreibt eine Menge
impliziter (ableitbarer) Daten, die aus einer Menge expliziter (Basis-)Daten herleitbar ist. Zur Verwaltung und Anwendung der Regeln (Datenherleitung) sowie zur
Konsistenzprüfung werden gererische, anwendungsunbhängige Methoden innerhalb
einer Inferenzkomponente zur Verfügung gestellt.
Generell unterscheidet man zwischen virtueller und materialisierter Darstellung regeldenierter Daten. Bei der virtuellen Darstellung werden die ableitbaren Daten
nicht persistent gespeichert. Sie müssen bei jeder Anfrage erneut temporär erzeugt
werden, d.h. es ndet eine Deduktion bei jeder Anfrage statt. Das System berechnet die Antwortmenge sowie alle zur Herleitung dieser benötigten Daten. Bei der
materialisierten Darstellung werden die Daten einmalig abgeleitet und anschlieÿend
persistent als Fakten abgespeichert. Bei einer Anfrage müssen sie nicht neu abgeleitet
werden. Im Falle von Basisdatenänderungen ist jedoch eine Anpassung der materialisierten Daten notwendig. Bei jeder Änderungsanweisung werden die induzierten
Folgeänderungen hinsichtlich der ableitbaren materialisierten Daten berechnet und
die Daten entsprechend angepasst.
2.1.2 Syntax von Datalog
Die Regelsprache Datalog basiert auf dem relationalen Bereichskalkül (DRC) (vgl.
[KE04]). In Datalog wird eine positionelle Schreibweise der Attribute einer Relation verwendet, wobei die Attribute von Datalog-Relationen nicht benannt werden.
Datalog hat eine mengenorientierte Semantik und nutzt nur einen minimalen Satz
an Operatoren (Konjunktion und Negation). Im weiteren ist mit der Bezeichnung
¬
Datalog immer Datalog mit Negation (Datalog ) gemeint.
4
Kapitel 2.
Eine Datalog-Bereichsvariable ist ein Groÿbuchstabe (z.B.
X ,X1 ,..)
Datenbanken
oder eine mit
einem Groÿbuchstaben beginnende Zeichenreihe. Datalog-Konstanten sind Ziern,
Kleinbuchstaben, Zeichenreihen, die mit einer Zier oder einem Kleinbuchstaben beginnen oder beliebige Zeichenketten in Hochkommata. Ein Datalog-Term
ti
ist eine
Konstante (Grundterm) oder eine Bereichsvariable. Relationsnamen sind Zeichenreihen, die mit einem Kleinbuchstaben beginnen. Die Grundbausteine aller DatalogAusdrücke sind positive und negative Formeln, aus denen Fakten und Regeln bestehen.
Denition 2.1 (atomare Datalog-Formeln)
Eine
atomare
Datalog-Formel
(DB-Atom) ist ein Ausdruck der Form
1.
p(t1 , . . . , tn ), wobei p ein n-stelliges Relationssymbol mit n ≥ 0 ist und t1 , . . . , tn
Terme sind, oder
2.
ti Θtj ,
wobei ti , tj Terme sind und
Θ ∈ {=, 6=, <, >, ≤, ≥}
ein Vergleichsopera-
tor ist.
Gemäÿ Punkt 1 denierte atomare Formeln werden als Literale und gemäÿ Punkt
2 denierte als Vergleichsliterale bezeichnet. Variablenfreie Literale heiÿen Grundliterale. Ein Fakt ist ein positives Grundliteral.
Denition 2.2 (Datalog-Formeln)
Eine Datalog-Formel F ist
1. eine Aussagenlogische Konstante TRUE oder FALSE,
2. ein positives oder negatives Literal L bzw. not L oder
3. eine Konjunktion von Literalen
L1 , . . . , L n
, wobei die
Li
für
1 ≤ i ≤ n positive
oder negative Literale sind.
Eine variablenfreie Datalog-Formel wird als grundinstanziiert bezeichnet.
Denition 2.3 (Ableitungsregel)
Eine Ableitungsregel (Deduktionsregel) ist ein
Ausdruck der Form
H←B [
WITH
help
R1help ← B1 , . . . , Rm
← Bm ]
mit einem DB-Atom H als Kopteral und einer Datalog-Formel B als Regelrumpf.
2.1
Deduktive Datenbanken
5
Eine Ableitungsregel in Datalog kann über eine Hilfsregel verfügen. Die WITH-Liste
help
help
mit den Hilfsrelationen Ri
ist optional (0 ≤ i ≤ m). Ri
← Bi ist eine Hilfsregel
help
mit dem DB-Atom Ri
als Kopteral und einer Datalog-Formel Bi als Regelrumpf.
help
Die Hilfsregeln Ri
besitzen nur einen lokal und temporär begrenzten Gültigkeitsbereich innerhalb der Regelspezikation. Die Hilfsregeln können über keine eigene
WITH-Klausel verfügen (Schachtelungsverbot).
Regelköpfe und Fakten sind positive Literale, Regelrümpfe bestehen aus positiven
und ggf. negativen Literalen. Lokale Variablen sind Variablen, die nur im Rumpf
einer Datalog-Regel vorkommen. Sie gelten zu Beginn des Regelrumpfs als implizit
existenzquantiziert. Die Existenzquantizierung sorgt für Duplikateliminierung in
den abgeleiteten Relationen. Eine wichtige Voraussetzung für eine sinnvolle Semantik von Regeln ist die Forderung nach Bereichsbeschränkung (Sicherheit von Regeln)
([Ull89]).
Denition 2.4 (beschränkte Variable)
ne Variable
1.
Xi
Xi
In einer Regel
H ← L1 , . . . , L n
tritt ei-
beschränkt auf, gdw.
in mindestens einem positiven Rumpiteral
Li
auftritt, das ein DB-Atom
ist,
2.
Xi
Li
in mindestens einem positiven Rumpiteral
Built-In der Form
Xi = Y
ist, und
Y
auftritt, das ein Vergleichs-
entweder eine Konstante ist oder selbst
eine beschränkte Variable oder
3.
Xi
in mindestens einem negativen Rumpiteral
Builtin der Form
Xi 6= Y
ist, und
Y
Li
auftritt, das ein Vergleichs-
entweder eine Konstante ist oder selbst
eine beschränkte Variable.
Denition 2.5 (bereichsbeschränkte Regel)
bereichsbeschränkt (sicher), gdw. jede Variable
Xi
Eine Regel
H ← L1 , . . . , L n
ist
beschränkt ist.
Eine Regel mit Hilfsregeln
H ← L1 , . . . , L n
WITH
Rihelp ← Bi
mit
1≤i≤m
ist bereichsbeschränkt, gdw. die Regel H und jede Hilfsregel
Rihelp
mit
1 ≤ i ≤ m
bereichsbeschränkt sind.
In einer Datenbank liegen nur wahre Fakten gespeichert oder ableitbar vor, somit ist
die Auswertung positiver Literale unproblematisch. Der Auswertung negativer Literale liegt die closed world assumption (CWA) zugrunde, bei der ein Fakt als falsch
angenommen wird, wenn es weder gespeichert noch ableitbar ist. Auf dieser Annahme über vollständiges Wissen basiert das Prinzip des negation as failure (NAF).
6
Kapitel 2.
Datenbanken
Ist für ein negatives Literal das entsprechende positive Fakt nicht in der Datenbank gespeichert und auch nicht durch Regeln ableitbar, wird auf die Wahrheit des
negativen Literals geschlossen. Aus diesem Grund ist für negierte Literale eine zusätzliche Sicherheitsanforderung nötig: Jede Variable, die in einem negierten Literal
vorkommt, muss auch in mindestens einem positiven Literal vorkommen. Aufgrund
der impliziten Existenzquantizierung ist Negation also nur unmittelbar vor Rumpfliteralen zulässig.
Denition 2.6 (Deduktive Datenbank)
D =< F, R >
Eine deduktive Datenbank ist ein Tupel
mit
1. einer endlichen, ggf. leeren Menge
F
von Grundatomen der Basisrelationen
(Basisfakten)
2. und einer endlichen Menge
rel(R)
R
von deduktiven Regeln .
ist die Menge der Relationssymbole. Der sog. Abhängigkeitsgraph stellt die
Beziehungen der Regeln untereinander dar, die beliebig (auch rekursiv) aufeinander aufbauen können. Um eine sinnvolle Ableitung der durch eine Regelmenge
R
beschriebenen abgeleiteten Fakten sowie Propagierung von Folgeänderungen unter
Berücksichtigung von Rekursion und Negation zu gewährleisten, wird eine Schichteneinteilung (Stratikation) der Regelmenge vorgenommen.
Denition 2.7 (Stratikation)
Sei R eine Menge deduktiver Regeln (inkl. lokaler
help
Hilfsregeln Ri
). Eine Stratikation λ bzgl. R ist eine Abbildung λ : rel(R) → N0
der Menge der Relationssymbole rel(R) auf eine Menge von positiven natürlichen
Zahlen. Für alle Relationssymbole
p, q ∈ rel(R)
gilt:
⇔ λ(p) = 0
1.
p
ist eine Basisrelation
2.
p
ist eine abgeleitete Relation
3.
p
hängt positiv von q ab
4.
p
hängt negativ von q ab
⇔ λ(p) ≥ 1
⇔ λ(q) ≤ λ(p)
⇔ λ(q) < λ(p).
Eine deduktive Datenbank heiÿt stratizierbar, wenn mindestens eine solche Stra-
λ von rel(R) induziert eine entsprechende
λR auf der Regelmange R. Dabei ist λR : R→ N0 deniert durch
λR ( p(...) ← ... ) =def λ(p).
tikation existiert. Jede Stratikation
Stratikation
Denition 2.8 (Klassen von Regelmengen, Datenbanken)
duktive DB mit der Menge deduktiver Regeln
R.
Sei
D
eine
de-
2.1
Deduktive Datenbanken
7
1. Die Regelmenge/DB heiÿt positiv, gdw. keine Relationssymbole
p, q ∈ rel(R)
existieren, die negativ voneinander abhängen.
2. Die Regelmenge/DB heiÿt semi-positiv, gdw. negative Abhängigkeiten nur von
Basisrelationen existieren.
3. Die Regelmenge/DB heiÿt hierarchisch (nicht rekursiv), gdw. kein Relationssymbol
p ∈ rel(R)
existiert, das von sich selbst abhängt.
4. Die Regelmenge/DB heiÿt rekursiv, gdw. mindestens ein Relationssymbol
rel(R)
existiert, das von sich selbst abhängt.
5. Die Regelmenge/DB R heiÿt stratizierbar, gdw. kein Relationssymbol
rel(R)
p∈
p ∈
existiert, das von sich selbst negativ abhängt.
Es gibt grundsätzlich drei Arten von Datenbankänderungen: Einfügung, Löschung
und Modikation. Im Folgenden sollen nur Einfügung und Löschung betrachtet werden, eine Modikation lässt sich durch eine Kombination von Einfügung und Löschung simulieren. Einfache Formen von Änderungsanweisungen sind Änderungen
von Fakten (primitive Änderungen). Komplexe Änderungsanweisungen (bedingte
Änderungen) induzieren in Abhängigkeit von einer Bedingung eine Menge von primitiven Änderungen genau einer Basisrelation. Syntaktische Grundbausteine aller
Datalog-Änderungen sind dynamische Literale ([Gri97]). Redundante Änderungen
werden akzeptiert, haben aber keinen Eekt auf den aktuellen Datenbankzustand.
Denition 2.9 (Änderungsanweisung)
Befehl) bzgl. einer deduktiven Datenbank
1. Sind
M, M new , M old
D
Eine
Änderungsanweisung
(DML-
ist induktiv deniert durch:
grundinstanziierte DB-Atome und
{+, −}
Änderungsope-
ratoren, dann sind folgende primitive Änderungsanweisungen spezizierbar:
Einfügung:
Löschung:
2. Sind
+M (t1 , . . . , tn )!
−M (t1 , . . . , tn )!
M, M new , M old
kurz:
kurz:
DB-Atome,
+M
−M
{+, −, ±}
Änderungsoperatoren und
B
eine
Datalog- Formel, dann sind folgende bedingte (komplexe) Änderungsanweisungen spezizierbar:
Einfügung:
Löschung:
+M
−M
WHERE
WHERE
help
B ! [WITH R1help , . . . , Rm
]
help
help
B ! [WITH R1 , . . . , Rm ]
Für Änderungen gelten analog zu den Regeln Sicherheitsanforderungen.
8
Kapitel 2.
Denition 2.10 (bereichsbeschränkte Änderungsanweisung)
Datenbanken
Eine
primiti-
ve Änderungsanweisung ist aufgrund ihrer Grundinstanziierung immer bereichsbeschränkt (sicher). Eine bedingte Änderungsanweisung
+M, −M
mit der Formel
B
im Qualikationsteil ist bereichsbeschränkt (sicher), gdw. die analog denierte Deduktionsregel
M ←B
bereichsbeschränkt ist.
Änderungen können in einer Transaktion zu einer zusammengehörigen Menge zusammengefasst werden. Die Transaktion wird ganz oder gar nicht ausgeführt (Atomarität). Dabei werden die Bedingungen der einzelnen Änderungen komplett über
dem alten Zustand der Datenbank ausgewertet. Das Transaktionskonzept ist mengenorientiert, d.h. es wird angenommen, dass alle Änderungen der Transaktion reihenfolgenunabhängig simultan ausgeführt werden. Eine Transaktion besteht aus einer Menge von primitiven und/oder bedingten Änderungen. Nach Auswertung der
Bedingungen erhält man daraus eine Multimenge von Elementaränderungen. Nach
dem Eliminieren konträrer Änderungen sowie der Duplikate ergibt sich eine Menge
von Elementaränderungen ohne wechselseitige Beziehung (Eekt der Transaktion).
Durch einen Test auf Wirksamkeit hinsichtlich der zu ändernden Relation (ein einzufügendes Fakt darf nicht in der Relation und ein zu löschendes muss in der Relation
enthalten sein) ergibt sich der Netto-Eekt der Transaktion.
Denition 2.11 (Transaktion)
oder bedingten Änderungen
U := {U1 , . . . , Un } von primitiven
Ui ∈ {+U, −U }, (1 ≤ i ≤ n) heiÿt eine Transaktion.
Eine Menge
Änderungen werden nur ausgeführt, wenn sie keine Integritätsbedingung verletzen.
Die Bearbeitung einer Transaktion ndet unter Berücksichtigung der Atomarität
statt, d.h. die Änderungen der Transaktion werden nur ausgeführt, wenn keine dieser
Änderungen eine Integritätsbedingung verletzt.
2.1.3 Semantik von Datalog
Die Semantik einer deduktiven Datenbank D =< F, R > ist die Menge aller ableit∗
baren Fakten F und wird bestimmt durch die Menge der Basisfakten F und die
∗
Menge der gegebenen deduktiven Regeln R. Zur Bestimmung der Menge F wird
eine konstruktive Fixpunktsemantik vorgestellt. Eine deduktive Regel wird dabei als
∗
faktengenerierende Funktion dargestellt. F wird deniert als der kleinste Fixpunkt
einer Funktion (vgl. [Gri97]).
Die Anwendung deduktiver Regeln wird modelliert durch den Tarski-Operator T .
0
Die zu einer Regel Ri := A ← B1 , . . . , Bn gehörige Ableitungsfunktion T [Ri ](F ) bil0
0
det eine beliebige Input-Faktenmenge F auf die Menge aller mittels Ri aus F ableitbaren Fakten ab. Um eine Regelmenge auf dieselbe Input-Faktenmenge anzuwenden,
2.1
Deduktive Datenbanken
9
wird die kollektive Ableitungsfunktion T [R] eingeführt. Die kumulative Ableitungs∗
funktion T [R] führt eine wiederholte Anwendung der T [R]-Funktion aus und stellt
sicher, dass die abgeleiteten Fakten der vorangegangenen
T [R]-Anwendungen
bei
weiteren Herleitungen berücksichtigt werden.
Denition 2.12 (Ableitungsoperator)
Ri := A ← B1 , . . . , Bn , not C1 , . . . , Cm
einer beliebigen Regelmenge R.
Sei
F0
eine beliebige Faktenmenge und
eine bereichsbeschränkte Datalog-Regel aus
1.
T [Ri ](F 0 ) := {Aσ | σ ist eine konsistente Variablensubstitution,
j ≤ n : Bj ∈ F 0 und ∀ 1 ≤ k ≤ m : Ck ∈
/ F 0 }.
2.
T [R](F 0 ) :=
3.
T ∗ [R](F 0 ) := F ∪ T [R](F 0 ).
S
Ri ∈R
so dass
∀1≤
T [Ri ](F 0 ).
Eine konsistente Variablensubstitution
σ ist die Ersetzung aller Variablen eines Aus-
drucks durch Konstanten, so dass jedes Vorkommen derselben Variablen durch dieselbe Konstante ersetzt wird.
Um ein verspätetes Ableiten positiver Fakten bei der Anwendung des
T ∗ [R]-
Operators auf eine Regelmenge mit Negation bzw. Rekursion zu verhindern, wird
∗
die Ausführung des T [R]-Operators bei stratizierbaren Regelmengen anhand der
Stratikationsebenen durchgeführt.
Denition 2.13 (Fixpunktsemantik deduktiver Datenbanken)
1. Sei
von
D =< F, R > eine positive oder semi-positive DB. Dann ist die Bedeutung
D der kleinste Fixpunkt F ∗ := lf p(T ∗ [R](F )) von T ∗ [R], der F ganz
enthält.
D eine stratizierbare DB und λ eine Stratikation von R mit n Ebenen
(n ≥ 0), dann ist die iterierte Anwendung des T ∗ [R]-Operators deniert als:
F0 := F
Fi := lf p(T ∗ [R](Fi−1 )) mit 1 ≤ i ≤ n. Die Bedeutung (iterierter Fixpunkt)
∗
von D ist deniert als F := Fn .
2. Ist
∗
Die Semantik F einer deduktiven Datenbank D =< F, R >, also der kleinste Fix∗
punkt von T [R, der F vollständig enthält, existiert immer, ist endlich und eindeutig
bestimmt ([vEK76]). Eziente Auswertungsverfahren für Datalog-Regeln (Anfragen), wie etwa die Magic Sets Methode [BMUS86], beruhen auf Regeltransformation
und Fixpunktberechnung.
10
Kapitel 2.
Datenbanken
2.1.4 Änderungspropagierung
Basisdatenänderungen können implizite Änderungen abgeleiteter Daten induzieren.
Virtuell dargestellte Sichten werden bei jedem Zugri neu berechnet, materialisierte
Sichten müssen jedoch angepasst werden. Eine naive Möglichkeit zur Bestimmung
dieser Änderungen stellt der Vergleich der DB-Zustände vor und nach der Durchführung einer Änderungsanweisung dar. Dieser Ansatz ist jedoch inezient, da eine
zweimalige vollständige Materialisierung der deduktiven Datenbank nötig ist. Zudem werden im Verhältnis zur Gröÿe der Relationen meist nur wenige Daten geändert. Ein ezienteres Verfahren ist die inkrementelle Berechnung der Änderungen
hinsichtlich abgeleiteter Daten. Im folgenden wird ein solches Verfahren zur Änderungspropagierung beschrieben.
Bei der Propagierung von Änderungen werden zwei Strategien unterschieden. Induzierte Änderungen werden beim top down -Ansatz abgeleitet, indem man Anfragen
nach neuen ableitbaren Fakten (∆-Fakten) stellt. Beim bottom up -Ansatz verläuft
der Propagierungsprozess änderungs- bzw. datengetrieben. Über einen Fixpunktprozess werden, beginnend bei den durch die Basisdatenänderungen induzierten Änderungen, die induzierten Änderungen der jeweils direkt abhängigen Sichten berechnet,
bis alle Änderungen ermittelt sind.
Durch Transformation der deduktiven Regeln werden die zur Berechnung der induzierten Änderungen benötigten Propagierungsregeln (∆-, Delta-Regeln) erzeugt.
Dabei werden für jedes Rumpiteral einer deduktiven Regel zwei ∆-Regeln erstellt,
+
−
eine ∆ -Regel für induzierte Einfügungen und eine ∆ -Regel für induzierte Löschun-
∆-Literal ersetzt. Je nach Polarität des
∆-Literals wird die Polarität des Literals im
Regelkopf bestimmt. Bei einem positiven ∆-Literal wird die Polarität beibehalten,
bei einem negativen wird die Polarität negiert. Die Rumpiterale der ∆-Regeln, die
keine ∆-Literale sind, werden als Seitenliterale (Residuen) bezeichnet. Der Zustand
old
der Datenbank vor der Ausführung der Änderungen wird mit F
bezeichnet, der
new
Zustand nach Ausführung der Änderungen (auch der induzierten) mit F
. Da
gen. Das Rumpiteral wird jeweils durch ein
zum Rumpiteral korrespondierenden
nur echte Änderungen abgeleitet werden sollen, wird zusätzlich ein Eektivitätstest
new
durchgeführt, d.h. ein einzufügendes Fakt muss im neuen Zustand F
ableitbar
sein, durfte aber nicht bereits im alten Zustand existiert haben. Ein zu löschendes
old
Fakt muss im alten Zustand F
ableitbar gewesen sein und es dürfen im neuen Zustand keine alternativen Ableitungswege existieren. Die Seitenliterale einer ∆-Regel
new
werden in Abhängigkeit der Polarität der propagierten Änderung bzgl. F
bei eiold
ner Einfügung und F
bei einer Löschung angewendet. Der Eektivitätstest führt
dazu, dass bei der Propagierung von Änderungen keine Duplikate auftreten können
(keine Multimengensemantik).
Denition 2.14 (Propagierungsregeln)
einer deduktiven Datenbank
Für jedes
Li , 1 ≤ i ≤ n
D.
Sei
Ri ∈ R
Sei
R
die stratizierbare Regelmenge
eine Regel der Form
A ← L1 , . . . , L n .
ist eine Propagierungsregel ein Ausdruck der Form:
2.2
MS Access
11
new
new
new
new
old
A+ ← L +
i , L1 , . . . , Li−1 , Li+1 , . . . , Ln , not A
old
new
new
new
new
A+ ← L −
i , L1 , . . . , Li−1 , Li+1 , . . . , Ln , not A
falls
old
old
old
old
new
A+ ← L −
i , L1 , . . . , Li−1 , Li+1 , . . . , Ln , not A
+
old
old
old
new
A+ ← Li , Lold
1 , . . . , Li−1 , Li+1 , . . . , Ln , not A
falls
falls
falls
Li ≡ L
Li ≡ not L
Li ≡ L
Li ≡ not L
Die Propagierungsregeln arbeiten mit zwei unterschiedlichen Datenbankzuständen.
Da es nicht sinnvoll ist, beide Datenbankzustände zu materialisieren, muss entwenew
old
der F
oder F
simuliert werden. Dies geschieht mit Hilfe der Transitionsregeln.
Welcher der beiden Zustände simuliert wird, hängt von der Reihenfolge der Ausführung von Basisfaktenänderung und Änderungspropagierung ab. Wird zuerst die
Änderung der Basisdaten durchgeführt, muss der alte Zustand simuliert werden (optimistischer Ansatz). Findet die Propagierung vor der Änderung an den Basisdaten
statt, wird der neue Zustand simuliert (pessimistischer Ansatz). Im Folgenden wird
der pessimistische Ansatz verfolgt.
Denition 2.15 (Transitionsregeln)
deduktiven Datenbank
Sei
R
die stratizierbare Regelmenge einer
D.
1. Ist A eine Basisrelation, dann ist eine inkrementelle Transitionsregel ein Ausdruck der Form
Anew ← A, not
new
+
A
2. Ist
A− .
←A .
Ri ∈ R
eine Regel der Form
A ← L1 , . . . , L n .
, dann ist eine naive Tran-
sitionsregel ein Ausdruck der Form
new
Anew ← Lnew
1 , . . . , Ln .
2.2
MS Access
Microsoft Access ist ein Datenbank-Produkt des Herstellers Microsoft ([WWW]).
Das Datenbankmanagementsystem basiert auf dem relationalen Datenmodell. Eine
Vielzahl von Datenquellen werden von Access unterstützt, u.a. auch ODBC (vgl. Abschnitt 2.3). Access bietet im Gegensatz zu den meisten üblichen DBMS zusätzliche
Funktionalitäten wie eine graphische Benutzeroberäche und eine Entwicklungsumgebung für VBA (Visual Basic for Applications). Mittels VBA können benutzerdenierte Erweiterungen von Access erstellt sowie auf Daten anderer Anwendungen oder
Datenbanken zugegrien werden. Access verwendet die sog. JET-Engine (Joint Engine Technology) als Datenbank-Backend ([WIKI]), über die die Daten verwaltet und
alle Datenbankoperationen abgewickelt werden. In dieser Arbeit wird die Version Access 2003 verwendet. Einige der Vorarbeiten innerhalb des SIMON-Projektes sind in
älteren Versionen (Access 2000, Access XP/2002) implementiert. In den folgenden
Abschnitten 2.2.1 bis 2.2.3 werden Jet SQL , VBA und die Datenbankanbindung
über VBA vorgestellt.
12
Kapitel 2.
Datenbanken
2.2.1 Jet SQL
Das Datenbankmodul Microsoft Jet SQL ist mit SQL ANSI-89 Level 1 kompatibel. Bestimmte ANSI SQL-Features sind jedoch nicht in Jet SQL implementiert.
Umgekehrt enthält Microsoft Jet SQL reservierte Wörter und Features, die in ANSI SQL nicht unterstützt werden. Ab Version 4.X wird zusätzlich ANSI-92-SQLSyntax unterstützt ([HLP]). Die in dieser Arbeit verwendeten Komponenten des
SIMON-Projektes, die in Access-Datenbanken implementiert sind (Compiler für
SQL-Sichten, vgl. Abschnitt 3.7, sowie Beispieldatenbank, vgl. Abschnitt 3.8), verwenden die ANSI-89 Syntax. Es können Inkompatibilitäten auftreten, wenn Anwendungsprogramme z.B. über die ODBC-Schnittstelle (vgl. Abschnitt 2.3) auf eine Jet
SQL-Datenbank zugreifen und die dabei verwendeten Operatoren nicht durch das
Datenbanksystem unterstützt werden.
2.2.2 Visual-Basic
Im Kontext dieser Arbeit wichtige Bestandteile von Access sind Formulare und Module. Formulare werden hauptsächlich zur Eingabe oder Anzeige von Daten der
Datenbank verwendet. Sie können an DB-Objekte wie Tabellen oder Abfragen gebunden werden, um die entsprechenden Daten anzuzeigen bzw. Benutzereingaben
zu verarbeiten. Steuerelemente innerhalb der Formulare stellen verschiedene Funktionen zur Verfügung und reagieren auf vom Benutzer ausgelöste Ereignisse wie
neue Eintragungen oder Mausklicks. Die Prozeduren zur Verarbeitung der Ereignisse können vom Benutzer mittels VBA selbst deniert bzw. erweitert werden. Module
stellen benutzerdenierte Erweiterungen von Access dar, die in der Programmiersprache VBA implementiert werden können. Ein Modul besteht aus Subroutinen
und Funktionen (Funktionen geben Werte zurück, Subroutinen führen ausschlieÿlich Code aus). Funktionen lassen sich auch innerhalb von SQL-Abfragen verwenden,
um so die Ausdrucksstärke von SQL zu erweitern. Zusätzlich können Steuerelemente
(Textfelder, Listenfelder o. ä.) von Objekten (Tabellen, Formulare, Berichte o. ä.)
direkt angesprochen werden. Aus VBA-Programmen kann auf die Daten der Datenbank und (eingeschränkt) auf die Daten anderer Anwendungen zugegrien werden
(vgl. Abschnitt 2.2.3). Das Tool zur Spezialisierung von SQL-Sichten (Compiler, vgl.
Abschnitt 3.7), welches in dieser Arbeit erweitert wird, stellt eine benutzerdenierte
VBA-Erweiterung einer Access-Datenbank dar.
2.2.3 DAO und ADO
VBA bietet die Möglichkeit, über die Microsoft Windows-Schnittstellensysteme
DAO (Data Access Objects) oder ADO (Active(X) Data Objects) auf Daten einer Datenbank oder Daten anderer Applikationen zuzugreifen. DAO ist für den
2.3
ODBC und JDBC
13
Zugri auf JET-Datenbanken konzipiert. Der Nachfolger ADO wurde als einheitliche Schnittstelle zwischen unterschiedlichen Datenbanken und Programmiersprachen entwickelt. Mit ADO lassen sich nahezu alle gebräuchlichen Datenbanken ansprechen, wie z.B. Microsoft Access, SQL-Server, Oracle oder Informix ([WIKI]).
2.3
ODBC und JDBC
Damit Anwendungsprogramme mit einer Datenbank kommunizieren können, sind
entsprechende Schnittstellen erforderlich. Ein CLI (Call Level Interface) ist eine
Schnittstellen-Spezikation für den Zugri auf relationale Datenbanken aus anderen Anwendungen heraus ([WIKI]), d.h. zum Ansteuern von Datenbanken wird eine CLI-Implementierung benötigt. Anstatt den Funktionsumfang zum Ansprechen
einer Datenbank in jedem Programm einzeln zu implementieren, greift man auf
bestehende Module zurück. Die CLI-Implementierung bildet ebenfalls die Befehlssätze verschiedener Datenbanksysteme auf eine immer gleiche Funktionsbibliothek
ab, um eine Unabhängigkeit von der konkreten Datenbank zu gewährleisten. Der
CLI-Standard wurde Anfang 1990 von einem Konsortium aus Datenbankherstellern
- der SQL Access Group - entwickelt. Eine erste Umsetzung wurde durch das API
(application programming interface) ODBC von Microsoft (1992) entwickelt. JDBC
(Java Database Connectivity) ist ein API der Java-Plattform, die ebenfalls einer
universellen Datenbankschnittstelle entspricht ([WIKI]).
ODBC (Open Database Connectivity) ist ein API von Microsoft für den dynamischen Zugri auf Datenbanken. Die standardisierte Schnittstelle wurde für C/C++
konzipiert ([KE04]) und erlaubt eine Entwicklung von Anwendungen unabhängig
vom verwendeten DBMS ([WIKI]). Bei der Kommunikation mit dem Datenbanksystem werden SQL-Befehle mit Hilfe von ODBC-Anweisungen an den ODBC-Treiber
weitergeleitet. Dieser ist abhängig von dem verwendeten DBMS. Er sendet die Befehle an die Datenbank und leitet die Antworten zurück. ODBC Treiber haben einen
unterschiedlichen Funktionsumfang: Core (nur Basisfunktionalität), Level 1, Level 2
([WIKI]). Auch das für das Microsoft-Jet-Datenbankmodul optimierte DAO (Data
Access Objects) ermöglicht den mittelbaren Zugri auf ODBC ([WIKI]).
JDBC (Java Database Connectivity) ist ein API der Java-Plattform, die eine universelle Schnittstelle zwischen der Sprache Java und Datenbanken darstellt. Sie stellt eine Weiterentwicklung von ODBC speziell für JAVA-Programme dar ([KE04]). JDBC
beinhaltet einen Satz von Klassen und Methoden, um relationale Datenbanksysteme unter Beibehaltung von Abstraktion aus Java heraus zugänglich zu machen
(DB-Verbindung aufbauen und Verwalten, SQL-Anfragen weiterleiten, Ergebnisse
für Java nutzbar umwandeln). Es kann jede Datenbank angesprochen werden, für
die ein JDBC-Treiber existiert oder die über ODBC zugreifbar ist.
14
Kapitel 2.
Datenbanken
Java-Applikationen greifen auf ein Datenbanksystem über den JDBC Driver Manager zu. In der JDBC Spezikation werden verschiedene Kategorien von JDBCTreibern unterschieden, die der Driver Manager verwenden kann. Ein JDBC Typ 1
Treiber kommuniziert ausschlieÿlich über den von Sun vertriebenen JDBC-ODBCBridge-Treiber. Damit ist es möglich, auf jede Datenbank mit ODBC-Anbindung
1
zuzugreifen . Ein Typ-1 Treiber ist somit abhängig von einem installierten ODBCTreiber. ODBC ist systemabhängig, dementsprechend enthält der Typ1-Treiber native Methoden. Ein Typ 2 Treiber übersetzt JDBC-Aufrufe direkt mit Hilfe einer
plattformspezischen Programmbibliothek in Aufrufe der Datenbank-API. Der Typ
2 Treiber benötigt eine zusätzliche Programmbibliothek und ruft native Methoden
auf. Typ 1 und 2 Treiber sind aufgrund ihrer Plattformabhängigkeit nicht portabel.
Mittels eines Typ 3 Treibers werden die JDBC-API-Befehle in DBMS-Befehle des
Datenbankservers übersetzt und (über ein Netzwerkprotokoll) an einen MiddlewareTreiber übertragen. Die Middleware leitet die Befehle an den Datenbankserver weiter. Es ndet keine direkte Kommunikation seitens des Typ 3 Treibers mit dem Datenbankserver statt, eine plattformspezische Bibliothek wird nicht benötigt. Typ
3 Treiber sind in Java programmiert und eignen sich sehr gut für Internet-Dienste
(Verschlüsselung, geringe Ladezeit). Typ 4 Treiber kommunizieren direkt mit dem
Datenbankserver über ein datenbankspezisches Netzwerk-Protokoll (MiddlewareTreiber werden dabei nicht verwendet). Ein Typ 4 Treiber (univerlesser Treiber)
stellt die performanteste Lösung dar, jedoch denieren nicht alle Datenbanken (z.B.
MS Access) ein entsprechendes Protokoll ([WIKI],[CU04]).
Die in Java implementierten Komponenten MOSIM (vgl. Abschnitt 3.4) und VISMONET (vgl. Abschnitt 3.5) des SIMON-Projektes, die in dieser Arbeit verwendet
und erweitert werden, kommunizieren über einen Typ 1 Treiber mit einer AccessDatenbank.
1 Ein
Typ 1 Treiber wird meist genutzt, falls kein eigenständiger JDBC-Treiber vorhanden ist
Kapitel 3
SIMON
Innerhalb des universitätsinternen Projekts SIMON (Simulation and Monitoring
of Mobile Objects) soll eine prototypische Implementierung eines Systems zur datenbankgestützten Überwachung mobiler Objekte auf Verkehrsnetzen ([MS04]) entwickelt werden. Im Rahmen des Projektes wurden durch mehrere Diplomarbeiten
Komponenten einer Testumgebung konzeptuell modelliert und implementiert. Dazu gehören u.a. ein Simulator (MOSIM), eine Visualisierungskomponente (VISMONET) sowie eine Datenbank, die u.a. Daten eines Beispielszenarios enthält. Ein
Compiler für SQL-Sichten bildet die Basis der regelbasierenden Monitoringkomponente, die in dieser Arbeit entworfen wird. Abschnitt 3.1 motiviert den Einsatz
von Datenbanken bei der Überwachung von Datenströmen. Abschnitt 3.2 gibt eine Einführung in die rechnergestützte Überwachung von Datenströmen. Dabei wird
insbesondere auf die Thematik des Monitorings im allgemeinen, die Modellierung
und Eigenschaften von Datenströmen sowie auf kontinuierliche Anfragen über Datenströmen eingegangen. Abschnitt 3.3 gibt einen Überblick über die Architektur
von SIMON. Die Komponenten aus den Vorarbeiten werden in den Abschnitten 3.4
bis 3.8 vorgestellt. Im Zuge des Entwurfs des Gesamtsystems werden diese Komponenten in den Kapiteln 5 und 6 diskutiert und erweitert.
3.1
Motivation
Im Kontext moderner Geoinformationssysteme gewinnt die Überwachung komplexer
Systeme mobiler Objekte zunehmend an Bedeutung ([MS04]). Dabei liefern Netzwerke von Sensoren umfangreiche Datenströme sich kontinuierlich bewegender Objekte.
Mögliche Anwendungsszenarien sind in Abbildung 3.1 aufgezeigt. Die Daten werden
i.a. zum automatischen Verfolgen (tracking) der Objekte und zur Visualisierung ihrer Bewegungen genutzt. Um jedoch auÿergewöhnliche Ereignisse und Zustände zu
15
16
Kapitel 3.
SIMON
erkennen, bedarf es einer Analyse der Daten. Diese wurde meist durch den Menschen vorgenommen, da intelligentes Überwachen (monitoring) die Fähigkeit zur
Analyse komplexer Situationen voraussetzt. Gleiches gilt für das Auslösen entsprechender Reaktionen auf die Zustände bzw. Ereignisse ([MS04]). Rechnergestütztes
Monitoring bietet jedoch Vorteile, da sehr viel gröÿere Datenmengen in kürzerer
Zeit analysiert werden können, als dies vom Menschen möglich wäre. Zudem sind
die Analyseergebnisse verlässlicher und objektiv. Dafür muss das Prinzip einer intelligenten Analyse in die rechnergestützte Überwachung integriert werden. Das Ziel
der intelligenten Analyse von Datenströmen ist das zeitnahe Aufdecken mehr oder
weniger komplexer Ausnahmesituationen sowie das entsprechende Auslösen vordenierter anwendungsspezischer Systemreaktionen.
Abbildung 3.1: Analyse von Sensordaten [MS04]
Die groÿe Menge an raum-zeitlichen Daten, die die Sensoren in Form von kontinuierlichen Datenströmen (data streams) liefern, sowie meist vorhandene zusätzliche (Meta-)Daten über weitere Zustandsparameter der überwachten Objekte, erfordern zur Bewältigung den Einsatz geeigneter Softwaresysteme. Dabei kann z.B.
Datenbanktechnologie verwendet werden. Entsprechende Datenbank-ManagementSysteme müssen jedoch über Funktionalitäten verfügen, die über den gebräuchlichen
Funktionsumfang hinausgehen, um Monitoring-Anwendungen zu ermöglichen. Von
besonderer Bedeutung ist dabei die Fähigkeit zur Spezikation anwendungsspezischer relevanter Situationen, zum ezienten automatischen Erkennen und Bewerten
von Ereignissen sowie zur Auslösung vordenierter Reaktionen in kritischen Ausnah-
3.2
Überwachung von Datenströmen durch kontinuierliche Anfragen
17
mesituationen (vgl. [MS04]). Das SIMON-System verfolgt zur Bewältigung dieser
Aufgaben einen regelbasierten Ansatz zur datenbankgestützten, reaktiven Überwachung mobiler Objekte auf Verkehrsnetzen, der auf einem DBMS mit aktiven
und deduktiven Regelkonzepten basiert. Die komplexen Situationen werden in Form
von zu überwachenden Bedingungen durch Anfragen speziziert, die kontinuierlich
über den jeweils aktuellen Daten der Datenströme ausgewertet werden (continuous
querys). Mit Methoden der Änderungspropagierung werden die Ergebnisse ezient
berechnet, um mit Hilfe von Triggern Reaktionen des Systems zu veranlassen.
3.2
Überwachung von Datenströmen durch kontinuierliche Anfragen
In diesem Abschnitt wird eine Einführung in die Überwachung von Datenströmen
gegeben. Abschnitt 3.2.1 führt in die Thematik des Monitorings ein und erleutert
wichtige Begrie. In Abschnitt 3.2.2 wird näher auf die Modellierung und die Eigenschaften von Datenströmen und in Abschnitt 3.2.3 auf Anfragen über Datenströmen
und den Zusammenhang mit dem Monitoring eingegangen.
3.2.1 Monitoring
Beim Monitoring wird ein bestimmter Ausschnitt der realen Welt beobachtet. Innerhalb des Realweltauschnitts gibt es bestimmte Objekte und es treten bestimmte
Ereignisse in Zusammenhang mit diesen Objekten auf. Das beobachtete Szenario
kann als Modell innerhalb eines Rechners abgebildet werden. Anhand der beobachteten Daten sollen die eingetretenen Ereignisse vom Rechner mit Hilfe von weiteren
(Meta-)Daten erkannt werden.
Im Kontext des Monitorings sind Objekte eindeutig zu identizierende physische Gegenstände der realen Welt. Jedes Objekt wird durch bestimmte Attribute und die
dazugehörigen Werte beschrieben (Beispiel: Ein grünes Objekt wird durch das Attribut Farbe und den dazugehörigen Wert grün beschrieben ([WIKI])). Objekte
können zu einander in Beziehung stehen und zu Klassen von gleichartigen Objekten
zusammengefasst werden. Der Zustand eines Objekts beschreibt die Werte der Attribute des Objekts zu einem bestimmten Zeitpunkt.
Geschehnisse sind eindeutig identizierbare Phänomene, die ein bestimmtes Zeitintervall andauern (Beispiel: Das Auftreten eines Objekts an einem bestimmten Ort).
Ereignisse sind punktuelle Geschehnisse.
Monitoring ist also das Beobachten von Objekten und Geschehnissen in einem bestimmten Ausschnitt der realen Welt. Ziel dabei ist, die Werte der das Objekt beschreibenden Attribute zu erkennen, um die Objekte zu klassizieren und die Beziehungen der Objekte untereinander zu entdecken. Zusätzlich sollen Geschehnisse
18
Kapitel 3.
SIMON
erkannt und festgestellt werden, welche Objekte davon betroen sind bzw. wie sich
die Werte der Attribute der Objekte verändern.
Die Beobachtung wird meist mit Hilfe von Sensoren oder Detektoren vorgenommen.
Primitive Ereignisse sind Ereignisse, die sich ausschlieÿlich direkt anhand der beobachteten Daten erkennen lassen. Unter Verknüpfung mit Hintergrundwissen bzw.
weiteren primitiven Ereignissen (indirekt) erkannte Ereignisse sind komplexe Ereignisse.
Beispiel 3.1 (Monitoring Szenario)
Bei dem in dieser Arbeit verwendete Bei-
spielszenario (vgl. Abschnitt 3.8) wird der ICE-Verkehr der Deutschen Bahn überwacht. Die wohlunterschiedenen Objekte sind die ICE-Züge. Attribute dieser Objekte
sind z.B. die Koordinaten, an denen sich das Objekt bendet, die Geschwindigkeit
oder die Verbindung, auf der sich das Objekt bendet. Primitive Ereignisse sind etwa das Auftreten eines Objekts an einem bestimmten Ort zu einer bestimmten Zeit,
welches sich anhand der Koordinaten feststellen lässt, oder das Stoppen des Objekts
(anhand der Geschwindigkeit). Ein komplexes Ereignis ist z.B. die Verspätung eines
Objekts hinsichtlich eines Fahrplans, welches durch eine Verknüpfung von primitiven
Ereignissen und Hintergrundwissen zu erkennen ist.
Monitoring wird bei einer Vielzahl von Anwendungen vorgenommen (vgl. Abbildung
3.1). Aufgrund der gewaltigen Datenmengen, die beim Beobachten von Objekten
der realen Welt auftreten, ist eine Analyse dieser Daten kaum vom Menschen durchzuführen. Beispielsweise bei Anwendungen im Kontext der Verkehrsüberwachung
und (automatischen) -steuerung oder der Bewertung von Aktienkursen übersteigt
die Analyse der entsprechenden Daten die Fähigkeiten des Menschen. Aus diesem
Grund gewinnt die rechnergestützte Überwachung zunehmend an Bedeutung. Ziel
ist dabei insbesondere die zeitnahe und objektive Bewertung und Analyse groÿer
Datenmengen.
Beispiel 3.2 (Monitoring Szenario Teil 2)
Das Beispiel 3.1 wird im Kontext
des rechnergestützten Monitorings fortgeführt. Mit Hilfe von Sensoren werden die
Daten hinsichtlich der ICE-Züge beobachtet. Anhand dieser Daten sollen primitive und komplexe Ereignisse von einem Softwaresystem erkannt und der Anwender
benachrichtigt werden. Dazu müssen die entsprechenden zu erkennenden Ereignisse
im Softwaresystem speziziert werden. Das primitive Ereignis Zug angehalten wird
z.B. speziziert durch Attribut: Geschwindigkeit, Wert: 0 und lässt sich direkt aus
den beobachteten Daten herleiten. Zur Spezikation komplexer Ereignisse wie der
Verspätung eines Zuges hinsichtlich des vorgegebenen Fahrplans ist eine Verknüpfung mit Hintergrundwissen (Fahrplandaten) nötig. Die beobachteten Daten müssen
zum Erkennen dieser Ereignisse analysiert werden. Zusätzlich muss die Reaktion
des Softwaresystems im Anschluss an das Erkennen eines Ereignisses (z.B. in Form
einer Warnung) speziziert werden können.
3.2
Überwachung von Datenströmen durch kontinuierliche Anfragen
19
Eine Anwendung ndet rechnergestütztes Monitoring im Kontext der Überwachung
von Datenströmen. In vielen Anwendungen lässt sich das Monitoring als Überwachung von Datenströmen modellieren, z.B. im Verkehrsmanagement ([CHKS03]).
Dabei sollen die bestehenden Kapazitäten eines Verkehrsnetzwerks möglichst ezient ausgenutzt und auf Verkehrsbelastung intelligent (z.B. durch das Herabsetzen
der Geschwindigkeit oder die Umleitung des Verkehrs auf Ausweichstrecken) reagiert
werden. Es ist eine Vielzahl an (Meta-)Daten über das zugrundeliegende Netzwerk
(Steckennetz) sowie die sich darauf bewegenden mobilen Objekte (Verkehrsteilnehmer) vorhanden. Durch die Erfassung von Daten über die Objekte (insbesondere der
Bewegung) durch entsprechende Sensoren wird zudem ein kontinuierlicher Datenstrom (z.B. laufende Positionsdaten) generiert. Diese Daten sollen analysiert werden,
um Ausnahmesituationen zu erkennen und das System darauf reagieren zu lassen.
Einfache Ereignisse wie eine Positionsfeststellung können direkt aus dem Datenstrom abgelesen werden. Um jedoch komplexe Ereignisse wie z.B. das Auftreten von
Stau bzw. Verzögerungen hinsichtlich eines Fahrplans zu erkennen, ist eine komplexe
Analyse der Daten nötig.
Folgende Aufzählung gibt einen Überblick über verschiedene Anwendungen im Kontext der Überwachung von Datenströmen (vgl. [GÖ03]):
•
Überwachung von Sensornetzwerken: Sensornetzwerke können z.B. für Anwendungen im Geo-, Verkehrs- oder im medizinischen Bereich verwendet werden.
•
Überwachung von Netzwerkverkehr: Analyse des Verkehrs innerhalb von Datennetzen (z.B. Datenverkehr im Internet).
•
Finanzanalyse: Analyse von Aktienkursen, um Zusammenhänge aufzudecken,
Trends zu identizieren und zukünftige Kursentwicklungen zu prognostizieren.
•
Log-Analyse: Analyse von Web-Logs, Telefon-Verbindungsdaten oder BankTransaktionen.
Beispiel 3.3 (Monitoring Szenario Teil 3)
Das Beispiel 3.2 wird im Kontext
der Überwachung von Datenströmen fortgeführt. Der zu Überwachende Datenstrom
besteht dabei aus den beobachteten Daten über die sich bewegenden Züge wie etwa
die aktuelle Position, die Geschwindigkeit, die aktuelle Verbindung usw. Diese sich
ändernden Daten sollen kontinuierlich auf das Auftreten der im System spezizierten
Ereignisse analysiert werden.
Abstrahiert man von der konkreten Anwendung, geht es also darum, Datenströme zu
überwachen und dabei benutzerdenierte Ereignisse zu erkennen. Es wird ein Ausschnitt der realen Welt beobachtet und entsprechenden Daten bestimmte primitive
Ereignisse hinsichtlich vordenierter Objekte erkannt, so z.B. das Auftreten eines bestimmten mobilen Objekts an einem Ort mit einer bestimmten Geschwindigkeit. Aus
20
Kapitel 3.
SIMON
den so übermittelten Daten wird ein Datenstrom mit festgelegten Attributen hinsichtlich der beobachteten Objekte generiert. Zur Erkennung komplexer Ereignisse,
die sich i.a. aus Kombinationen primitiver und/oder weiterer komplexer Ereignisse
sowie deren Interpretation und der Berücksichtigung von Meta-Daten ergeben, ist
eine komplexere Analyse der Datenströme nötig.
Die Überwachung eines Datenstroms ist also das Erkennen bestimmter Muster innerhalb der gesendeten Daten ([GIL]). Die Muster entsprechen dabei i.a. den Ereignissen aus der realen Welt. Um die Datenströme kontinuierlich auf das Auftreten dieser
Ereignisse zu überprüfen, müssen die Ereignisse im System speziziert werden. Die
Ereignisse können dabei z.B. als Anfragen speziziert werden, die ununterbrochen
oder kontinuierlich an das Softwaresystem gestellt und anhand der eintreenden
Stromdaten ausgewertet werden (kontinuierliche Anfragen). Die Benachrichtigung
des Benutzers hinsichtlich der Antworten auf die kontinuierlich muss dabei nicht
zwingend auch kontinuierlich erfolgen, sondern kann auch in vorgegebenen Zeitintervallen, nur beim Eintreten bestimmter Ereignisse oder auf explizite Anforderung
des Benutzers geschehen ([GIL]).
In den folgenden Abschnitten 3.2.2 und 3.2.3 wird näher auf die Modellierung von
Datenströmen und Anfragen über Datenströmen eingegangen.
3.2.2 Datenströme
Ein Datenstrom ist eine in Echtzeit übermittelte kontinuierliche Sequenz von Datensätzen in einer bestimmten Reihenfolge ([GIL], [GÖ03], [HRR99]). Bei vielen Anwendungen (vgl. Abschnitt
??) liegen Informationen in Form einer Sequenz (Strom)
von Daten vor ([GÖ03]). Je nach Anwendung bestehen diese Daten z.B. aus Sensordaten ([PGS01], [MF02]), Verkehrsdaten in Datennetzen ([GKMS01], [SH98]), Börsendaten ([CDTW00], [ZS02]), Onlineauktionen ([ABW02]) oder transaction logs
wie Web usage logs oder Telefon-Verbindungsdaten ([CFP+00]). Die Reihenfolge,
in der die Daten eintreen, kann dabei nicht beeinusst werden. Zusätzlich kann auf
die Stromdaten, sofern sie nicht zwischengespeichert werden, nur ein mal zugegrien
werden ([GÖ03],[HRR99]).
Die einzelnen Elemente der Stromdaten können z.B. relationale Tupel oder Instanzen
von Objekten sein ([GÖ03]). Bei Verwendung des relationalen Modells können die
Datenströme als append-only Relationen mit vorübergehenden Tuplen angesehen
werden ([BBD+02]). Es nden dabei keine Modikationen an den Daten, sondern
ausschlieÿlich Einfügungen statt.
Diese Modellierung von Datenströmen weist wesentliche Unterschiede zum konventionellen Modell gespeicherter Relationen auf ([BBD+02]). Bei Datenströmen liegen die Daten nicht in Form von persistenten Relationen vor, sie sind also nicht
3.2
Überwachung von Datenströmen durch kontinuierliche Anfragen
21
für einen wahlfreien Zugri auf einem Speichermedium (z.B. HDD oder RAM) zugänglich. Vielmehr bestehen die Daten aus einem oder mehreren kontinuierlichen
Datenströmen unterschiedlicher Geschwindigkeit. Ebenso ist die Datenmenge sowie der Zeitraum, über den die Daten eintreen, nicht festgelegt. Erst nach einer
Vorverarbeitung der Daten können sie z.B. innerhalb einer DB in Form von persistenten Relationen gespeichert werden. Zusätzlich werden dann innerhalb des DBMS
weitere Funktionalitäten hinsichtlich der Verwaltung der Stromdaten (wie z.B. eine
Historienverwaltung, garbage-collection usw.) benötigt.
Die folgende Aufzählung gibt eine Übersicht über die wichtigsten Eingenschaften
von Datenströmen ([BBD+02], [CHKS03], [GÖ03]):
•
Die Daten des Datenstroms werden direkt verarbeitet (online) bzw. erst nach
einer Vorverarbeitung gespeichert.
•
Das verarbeitende System hat keinen Einuss auf die Reihenfolge und die
Geschwindigkeit, mit der die Daten auf den Datenströmen eintreen.
•
Die Datenmenge ist möglicherweise unbegrenzt.
•
Die Daten werden nur ein mal geliefert. Sie werden verarbeitet und sind danach
nicht mehr zugänglich, sofern sie nicht zwischengespeichert wurden.
Probleme bei der Verarbeitung von Datenströmen bereitet die möglicherweise
unbegrenzte Datenmenge der innerhalb der Datenströme gesendeten Daten, die
eine vollständige Speicherung evtl. unmöglich macht. Dies führt dazu, dass zur
Beantwortung von Anfragen nur ein begrenzter Ausschnitt der Daten verfügbar
ist, da die Daten aufgrund des begrenzten Speicherplatzes nicht komplett vorliegen
bzw. bei der Speicherung aggregiert werden. Daraus resultiert die Tatsache, dass
u.U. nur approximative Antworten auf bestimmte Anfragen möglich sind.
Auf den Elementen der Datenströme kann anhand eines timestamp Attributs (Zeitstempel) eine explizite oder implizite Ordnung hergestellt werden ([BBD+02],
[GÖ03]). Explizite Zeitstempel liegen vor, wenn die Tupel jeweils zu einem Ereignis der realen Welt zu einem bestimmten Zeitpunkt korrespondieren und die
entsprechende Information den Daten durch den Sensor hinzugefügt werden kann.
Explizite Zeitstempel entsprechen dann den jeweiligen Zeitpunkten, an denen die
Daten generiert wurden. Implizite Zeitstempel können den Tupeln vom Softwaresystem automatisch beim Eintreen der Daten hinzugefügt werden, wenn die jeweilige
Datenquelle keine Informationen über das zeitliche Auftreten der Daten mitliefert.
Implizite Zeitstempel entsprechen also dem Zeitpunkt des Eintreens der Daten im
System ([BBD+02]). Probleme bei Zeitstempeln treten auf, wenn das Attribut z.B.
22
Kapitel 3.
SIMON
nach einem JOIN bei der Verarbeitung nicht mehr eindeutig ist oder vollständig
fehlt.
Weitere Probleme bei der Verarbeitung von Stromdaten können auftreten, wenn
z.B. Elemente der Datenströme nicht in chronologischer Reihenfolge oder mit zeitlicher Verzögerung eintreen. Durch eine blockweise oder gefensterte Verarbeitung
der Daten (sliding window ), wie sie z.B. in [CCC+02], [BBD+02] oder [CBB+03]
thematisiert wird, kann man dieses Problem lösen. Die Elemente der Stromdaten
werden zu Blöcken bzw. Fenstern zusammengefasst, auf welchen die Analyse dann
jeweils nacheinander durchgeführt werden. Die gefensterte bzw. blockweise Verarbeitung wird zusätzlich angewandt, wenn leweils nur ein Ausschnitt der Stromdaten
für die Analyse von Interesse ist ([GÖ03]).
3.2.3 Kontinuierliche Anfragen über Datenströmen
Im Kontext von Anfragen über Datenströmen werden zwei wichtige Unterscheidungen getroen ([BBD+02], [TGNO92]). Zum einen wird unterschieden zwischen ein-
1
maligen (one-time ) und kontinuierlichen (continuous ) Anfragen (CQs).
one-time querys sind Anfragen, die (genau) ein mal über dem jeweils zu einem
bestimmten Zeitpunkt aktuellen Zustand der Datenbank ausgewertet werden. Die
entsprechende Antwort wird an den Benutzer übermittelt. continuous querys sind
Anfragen, die kontinuierlich über dem jeweils aktuellen Datenbankzustand ausgewertet werden. Im Kontext der Analyse von Datenströmen werden ständig die selben
Anfragen über den sich ändernden Daten der Datenströme gestellt. Dabei werden
schrittweise neue Antworten auf die Anfragen zurückgegeben, sobald neue Stromdaten eintreen ([GÖ03]). Die Antworten auf die kontinuierlichen Anfragen basieren
dabei auf den bis zum jeweiligen Zeitpunkt auf den Datenströmen eingetroenen
Daten. Da die Daten der Datenströme meist nicht komplett abgespeichert werden
können, steht zur Beantwortung nur eine Teilmenge dieser Daten zur Verfügung.
Die Menge der Daten, die gespeichert werden kann, ist dabei von der Architektur
des Systems abhängig. Im Falle einer Online-Analyse ist die Menge der der Anfragebeantwortung zugrundeliegenden Daten z.B. wesentlich kleiner (Hauptspeicher) als
bei Verwendung eines Sekundärspeichers (z.B. DBMS). Dies beeinusst auch den
Grad der Genauigkeit der Antworten. Die Antworten auf die kontinuierlichen Anfragen können gespeichert und jeweils aktualisiert werden, wenn neue Daten auf den
Datenströmen eintreen, oder auch selbst als Datenströme weiterverarbeitet werden
([BBD+02]).
Eine weitere Unterscheidung wird zwischen vordenierten (predined ) und ad hocAnfragen getroen ([TGNO92], [BBD+02]). Eine vordenierte Anfrage wird dem
Softwaresystem übermittelt, bevor irgendwelche relevanten Daten eingetroen sind
1 Diese
Klasse beinhaltet die Anfragen traditioneller DBMS
3.3
Gesamtarchitektur SIMON
23
(oine). Zu den vordenierten Anfragen zählen i.a. auch die kontinuierlichen Anfragen. Ad hoc-Anfragen werden online während der Verarbeitung der Datenströme
gestellt. Die Verwaltung von ad hoc-Anfragen stellt höhere Anforderungen an das
DSMS. Im Gegensatz zu den vordenierten Anfragen ist die Optimierung von Anfragen, die erst zur Laufzeit an das System übermittelt werden, schwieriger. Zusätzlich
ist bei vordenierten Anfragen bekannt, auf welche Daten sie sich beziehen. Das
DSMS kann darauf reagieren und die benötigten Daten evtl. zwischenspeichern. Ad
hoc-Anfragen können sich jedoch auch auf historische Daten beziehen, die möglicherweise nicht mehr verfügbar sind ([BBD+02]).
Anhand der Daten der Datenströme sollen benutzerdenierte Ereignisse erkannt
werden. Diese Ereignisse lassen sich mit Hilfe von Anfragen spezizieren. Dabei entspricht das Eintreten eines Ereignisses dem Auftreten eines entsprechenden Tupels
in der Antwort der dem Ereignis zugehörigen Anfrage bzw. dem Auftreten eines
entsprechenden Tupels in der dem Ereignis zugehörigen Sicht. Da die Datenströme
kontinuierlich Überwacht werden sollen, werden beim rechnergestützten Monitoring
meist kontinuierliche Anfragen über den Daten der Datenströme ausgewertet.
Die Reaktionen des Systems auf eine Anfrage können in unterschiedlicher Weise
erfolgen. Zum einen werden die Antworten auf die Anfragen berechnet. Zusätzlich
können Meldungen (alerts) an den Benutzer bzw. Applikationen übermittelt werden,
um auf Änderungen bzw. Ergebnisse der Anfrage aufmerksam zu machen. Auch
können entsprechende Folgereaktionen (Trigger) ausgelöst werden, die das System
autonom auf die berechneten Ergebnisse reagieren lassen.
3.3
Gesamtarchitektur SIMON
Das SIMON-System besteht im wesentlichen aus drei Komponenten: Simulator, Monitor und Visualisierer. Ziel ist es, eine prototypische Implementierung eines Systems zur datenbankgestützten Überwachung mobiler Objekte auf Verkehrsnetzen
([MS04]) zu entwickeln. Der Simulator simuliert kontinuierliche Bewegungen mobiler Objekte auf Netzwerken. Die entsprechend generierten Daten werden von einer
regelbasierten Monitoring-Komponente mit Hilfe von Methoden der inkrementellen
Änderungspropagierung analysiert. Die Visualisierungskomponente stellt die simulierten Daten sowie die Ergebnisse der komplexen Analyse dar. Abbildung 3.2 gibt
einen Überblick über die Architektur von SIMON und den Zusammenhang der einzelnen Komponenten.
Als Vorarbeiten aus mehreren Diplomarbeiten stehen folgende Komponenten zur
Verfügung: Simulator MOSIM, Visualisierungskomponente VISMONET, Compiler
für SQL-Sichten, Datenbank mit Beispielszenario. Die Implementierungen von MOSIM und VISMONET wurden in Java vorgenommen, der Sichtencompiler sowie das
24
Kapitel 3.
SIMON
Abbildung 3.2: Architektur SIMON
Beispielszenario sind in eine Access-Datenbank integriert. In den folgenden Abschnitten werden die einzelnen Komponenten hinsichtlich der für diese Arbeit relevanten
Aspekte im Detail vorgestellt.
3.4
MOSIM
Der Simulator MOSIM (Mobile Object Simulator, [Bua03]) ermöglicht es, die kontinuierliche Bewegung mobiler Objekte in einer Netzwerktopologie zu simulieren.
MOSIM ist in Java implementiert und ersetzt momentan von realen Sensornetzen
gelieferte Datenströme. Funktionalität und Architektur von MOSIM wurden von
[Bri02] beeinusst. MOSIM generiert in benutzerdenierten Intervallen Positionsdaten mobiler Objekte, die die kontinuierliche Bewegung der Objekte nachbilden,
sowie je nach Anwendungsszenario weitere Zustandsparameter der zu überwachenden mobilen Objekte. Die Berechnung der aktuellen Positionssdaten jedes einzelnen
Objektes erfolgt skriptgetrieben, d.h. für jedes sich auf dem Netzwerk bewegende
mobile Objekt ist ein Fahrplan mit Angaben wie Startpunkt, Abfahrtszeitpunkt und
Zielort gegeben.
Abbildung 3.3 zeigt die Programmoberäche von MOSIM mit den Schaltächen zur
Steuerung der Simulation. Der Benutzer kann interaktiv in die Simulation eingreifen. Er hat die Möglichkeit, Parameter der Simulation zu beeinussen, so z.B. die
Simulationsgeschwindigkeit (welche Zeitspanne innerhalb der Simulation in einer
3.4
MOSIM
25
Echtzeit-Sekunde vergehen soll). Dem Simulationsbetrieb liegt ein diskretes Zeitmodell zu Grunde. Die Aktualisierungsrate, mit der die Positionsdaten der mobilen
Objekte generiert werden, kann variabel eingestellt werden. Zusätzlich ist eine Routine zur Verarbeitung von selbst-denierten Ereignissen vorbereitet, mit Hilfe derer
man den Ablauf der Simulation gezielt zu vordenierten Zeitpunkten oder aber interaktiv während des Simulationsbetriebes beeinussen kann. Solche Ereignisse sind
z.B. das Sperren von Verbindungen oder das Herabsetzen der Geschwindigkeit.
Abbildung 3.3: GUI MOSIM [Bua03]
Das Netzwerk, auf dem sich die mobilen Objekte bewegen, wird durch einen gerichteten Graphen modelliert. Jedes Netzwerk besitzt einen Typ sowie eine bestimmte
Anzahl von Orten (Knoten) und Verbindungen (Kanten). Ebenso sind die Orte und
Verbindungen von einem bestimmten Typ abgeleitet. Der Netzwerktyp legt die in einem Netzwerk zulässigen Verbindungs- und Ortstypen fest. Ein Ort wird speziziert
durch den zugehörigen Typ, einen Namen sowie seine Position in Form von (X,Y)Koordinaten und eine Verbindung durch einen Verbindungstyp, einen Namen, die
Länge sowie einen Start- und einen Zielort. Der Verbindungstyp legt dabei spezielle
vordenierte, aber auch erweiterbare Klasseneigenschaften wie maximale Kapazität
oder Höchstgeschwindigkeit fest.
Ebenso wie die Orte und Verbindungen besitzen die mobilen Objekte besitzen einen
bestimmten Typ, d.h. sie gehören Klassen mit spezischen Eigenschaften wie maximale Geschwindigkeit oder Fahrzeugtyp an. Die mobilen Objekte werden über
Skripte gesteuert, d.h. zu jedem mobilen Objekt ist ein Skript deniert, das festlegt,
in welcher Weise sich die Objekte auf dem Netzwerk bewegen sollen. Das Skript
26
Kapitel 3.
SIMON
besteht aus einer Liste von Verbindungen, die das entsprechende Objekt nach der
Reihe abfahren soll, und zugehörigen Abfahrtszeiten (Skripteinträge). Ist keine Abfahrtszeit angegeben, fährt das Objekt so schnell wie möglich los. Angefangen beim
Startort der ersten Verbindung sowie dem Startzeitpunkt bewegt sich das Objekt
auf dem Netzwerk. Das Skript ist durch einen Vector realisiert, ein Index deniert
den aktuellen Skripteintrag und somit die nächste Station in der Route an. MOSIM wird in Abschnitt 6.2 hinsichtlich des Funktionsumfangs der Skripte sowie des
Verhaltens der mobilen Objekte erweitert.
Abbildung 3.4 verdeutlicht das in MOSIM verwendete konzeptuelle Modell mobiler
Objekte auf Netzwerken. Es werden die Systemkomponenten (ohne ihre jeweiligen
Attribute) aufgezeigt, auf denen die Simulation beruht. Das Verhalten der mobi-
Abbildung 3.4: Konzeptuelles Modell mobiler Objekte auf Netzwerken [Bua03]
len Objekte wurde auf die folgende Weise modelliert: Jedes mobile Objekt versucht
immer seine bzw. die maximal auf der Verbindung zulässige Höchstgeschwindigkeit
zu erreichen. Deshalb überprüfen mobile Objekte zu jedem Zeitpunkt der Positionsaktualisierung, ob sie ihre Geschwindigkeit erhöhen können, sofern die eigene
Höchstgeschwindigkeit oder maximale Geschwindigkeit der Verbindung noch nicht
erreicht wurde. Im Fall einer gesperrten Verbindung oder falls die Abfahrtszeit des
entsprechenden Skripteintrags noch nicht erreicht wurde, wartet das Objekt an seiner Ausgangsposition bis zur Aufhebung der Sperrung einer Verbindung oder dem
3.5
VISMONET
27
Erreichen der Abfahrtszeit. Ist das mobile Objekt in Bewegung, ändert sich somit
die eigene Position. Die neue Position errechnet sich aus der zuletzt bekannten Geschwindigkeit, der zuletzt bekannten Position sowie dem vergangenen Zeitintervall.
Überschreitet die zurückgelegte Entfernung die noch verbliebene bis zum nächsten
Ort, so ndet anhand des Skripts ein Wechsel auf die nächste Verbindung im Skript
statt, sofern die nicht gesperrt ist, oder das Objekt verbleibt an seinem Zielort.
Die Protokollierung der Simulationsdaten ndet in der Datenbank statt, d.h. bei
jeder Positionsaktualisierung werden die aktuellen Daten aller mobilen Objekte in
der Datenbank gespeichert.
3.5
VISMONET
In [Yer04] wurde das Visualisierungssystem VISMONET entwickelt, welches mobile
Objekte, die sich auf einem Netzwerk bewegen, darstellt. Das in Java implementierte System wertet zur Echtzeit Positionsdaten aus und stellt sie in einer 2DBildschirmkarte dar (vgl. Abbildung 3.5).
Das Verkehrsnetz wird repräsentiert durch die Orte (Knoten) und Verbindungen
(Kanten). Die Darstellung des Netzwerks basiert auf den selben Daten (Koordinaten), die auch der Simulator MOSIM benutzt. Für die Anzeige des Netzwerks werden jedoch zusätzliche Daten benötigt. Jeder Ort und jede Verbindung sind einem
bestimmten Typ zugeordnet, der das Aussehen auf dem Bildschirm repräsentiert.
Die entsprechenden Typen sind in einer Datenbank hinterlegt und spezizieren bestimmte Eigenschaften wie Farbe, Form, Gröÿe oder Linientyp. Die Orte werden
als Punkte (Kreise) dargestellt. Die Verbindungen bestehen aus gerichteten Kanten
(Linien), die die verschiedenen Spurrichtungen modellieren und ein wenig versetzt
angezeigt werden. Dabei wird von Rechts-Verkehr ausgegangen, d.h. die Objekte
bewegen sich immer auf der in Fahrtrichtung rechten Spur.
Die mobilen Objekte werden als Quadrate angezeigt. Die Positionsdaten für die Objekte werden unmittelbar vom Simulator MOSIM geliefert. Diese werden in Form der
ID der Verbindung, auf der sich die Objekte benden, sowie der zurückgelegten Strecke direkt per Java übergeben. Anhand dieser Daten wird die Position der Objekte
auf dem Bildschirm bestimmt, indem aus den Koordinaten des Start- bzw. Zielortes der Verbindung die Richtung bestimmt und so mit der zurückgelegten Strecke
die neue Position relativ zur Startposition auf der Verbindung (Startort) berechnet
wird.
Die Visualisierung ndet getaktet statt. Die entsprechende Aktualisierungsrate bzw.
die Verzögerung zwischen zwei gezeichneten Zuständen kann vom Benutzer beeinusst werden. Die Aktualisierungsrate der Visualisierung und die der Positionsaktualisierung des Simulators sind nicht synchronisiert. In Abschnitt 6.4 werden Erweiterungen von VISMONET vorgenommen.
28
Kapitel 3.
SIMON
Abbildung 3.5: GUI VISMONET [Yer04]
Im Folgenden soll eine Übersicht über einige Klassen bzgl. Netzwerk und mobiler
Objekte gegeben werden. Die Klasse MainFrame entspricht dem Programmfenster
von VISMONET. Sie enthält u.a. die Buttons, über die die Funktionen des Programms zugänglich gemacht werden, die Zeichenäche, auf der die mobilen Objekte
und das Netzwerk gezeichnet werden sowie einen Bereich mit Karteikarten-Layout,
auf dem weitere Informationen zu den gezeichneten Komponenten zur Verfügung
stehen und auch editiert werden können. Die Zeichenäche wird durch die Klasse
DrawingPaneJava2D bereitgestellt. Auf der Zeichenäche werden drei verschiedene
Komponenten dargestellt. Dies sind die mobilen Objekte, die Orte sowie die Verbindungen. Ein Ort wird repräsentiert durch die Klasse NodeObject. Zusätzlich gibt es
Darstellungstypen für Orte (DisplayNOType), die verschiedenartiges Aussehen auf
der Zeichenäche ermöglichen. Jedem NodeObject ist ein DisplayNOType zugewiesen. Analog gilt dies für die Verbindungen (Connections, DisplayCType) und die
mobilen Objekte (MobileObject, DisplayMOType). Die Darstellungstypen beziehen
sich u.a. auf Gröÿe und Farbe der jeweiligen Objekte, die Formen sind an anderer
Stelle teilweise x festgelegt. Das Zeichnen der Objekte, also das Aussehen und die
Positionierung, ergibt sich aus den Attributwerten der Objekte sowie dem zugewie-
3.5
VISMONET
29
Abbildung 3.6: Klassendiagramm Netzwerk [Yer04]
senen Darstellungstyp. Die Zuordnung der Orte und Verbindungen zu ihren Typen
wird in der Datenbank vorgenommen (Tabellen ort_displayNOType bzw. verbindung_displayCType). Die Klasse Network (vgl. Abbildung 3.6) beinhaltet alle Verbindungen und Orte sowie deren Darstellungstypen und stellt das Netzwerk dar, die
Menge der mobilen Objekte entspricht der Klasse MobileObjects (vgl. Abbildung
3.7) und beinhaltet alle mobilen Objekte und die jeweiligen Darstellungstypen.
Abbildung 3.7: Klassendiagramm mobile Objekte [Yer04]
30
3.6
Kapitel 3.
SIMON
Monitor
Die Überwachung und Analyse der vom Simulator erzeugten Daten sollen durch
die Monitoring-Komponente (Monitor) vorgenommen werden. Sie erkennt kritische
Situationen und Ereignisse innerhalb der simulierten Daten, löst ggf. Reaktionen aus
und gibt die Analyseresultate an die Visualisierungskomponente weiter. Der Kern
dieser Komponente ist ein Compiler für Sichten und wurde in [Ber05] entwickelt.
Dieser Compiler wird in Abschnitt 3.7 vorgestellt.
Abbildung 3.8 zeigt die Architektur des Monitors. Vom Benutzer können Anfragen
speziziert werden, welche kontinuierlich durch den Monitor beantwortet werden.
Die Anfragen werden dabei durch den Compiler in eine Form gebracht, die eine eziente Auswertung möglich macht. Basierend auf den Stromdaten, die von MOSIM
simuliert werden, und weiteren in der Datenbank verfügbaren Metadaten werden die
von Benutzer spezizierten Anfragen beantwortet. Die Analyse des Datenstroms besteht also in der Beantwortung kontinuierlichen Anfragen über den Stromdaten und
weiteren Metadaten. Die entsprechenden Antworten bzw. Analyseergebnisse werden
zur graphischen Darstellung an die Visualisierungskomponente weiterleitet.
Abbildung 3.8: Architektur Monitor
In Kapitel 4 wird das Konzept des Monitors motiviert und der dabei verwendete
Ansatz zur datenbankgestützten Überwachung von Datenströmen vorgestellt. Der
Compiler aus [Ber05] wird in Kapitel 6.3.3 diskutiert und erweitert. Insbesondere
wird dabei das Prinzip zur Generierung der Propagierungsregeln verbessert. Die
Monitoring-Komponente selbst wird in Abschnitt 6.3 entworfen.
3.7
3.7
Compiler
31
Compiler
Der innerhalb von Access mittels VBA als Modul implementierte Compiler erstellt
für in einer Access-DB spezizierte Sichten entsprechende weitere Sichten, die für
eine Anwendung des Prinzips der Änderungspropagierung (vgl. Abschnitt 2.1.4) benötigt werden. Die Access-Datenbank wird dabei mit Hilfe der Schnittstelle DAO
manipuliert (vgl. Abschnitt 2.2.3). Die vom Compiler erstellten Sichten erlauben ein
ezientes Berechnen der Änderungen hinsichtlich der zu überwachenden Bedingungen.
Abschnitt 3.7.1 beschreibt die Architektur des Compilers und die prinzipielle Vorgehensweise beim Kompilieren der Sichten. In Abschnitt 3.7.2 wird die Generierung
der Sichten mit Hilfe eines Ansatzes zur Änderungspropagierung in SQL anhand
von Beispielen erläutert. Abschnitt 3.7.3 zeigt die Einbettung des Compilers in MSAccess auf.
3.7.1 Architektur
Das in [Ber05] entwickelte Tool zur Spezialisierung von SQL-Sichten besteht aus der
Implementierung eines Algorithmus, der das Konzept der inkrementellen Sichtenanpassung aus dem Bereich der deduktiven Datenbanken im relationalen Datenbanksystem MS Access (Version: XP/2002) realisiert. Motivation dabei ist, beim Auftreten von Basisdatenänderungen eine komplette Rematerialisierung der abhängigen
Sichten zu vermeiden und statt dessen die Änderungen inkrementell zu propagieren.
In Anlehnung an die in Abschnitt 2.1.4 vorgestellte Methode zur Änderungspropagierung wurde eine Methode der inkrementellen Anpassung von Sichten in ein
SQL-DBMS (Access) implementiert. Die Komponente kann induzierte Sichtenänderungen hinsichtlich der entsprechenden zugrundeliegenden Sichten festzustellen
und berechnen. Die Methoden der Änderungspropagierung werden dabei direkt in
SQL übertragen. Dieser Ansatz wurde einem transformationbasierten Ansatz, der
die SQL-Sichten in eine äquivalente Datalog-Form überführt, dort die entsprechenden Propagierungs- und Transitionsregeln generiert und die Ergebnisse zurück in
eine SQL-Darstellung überführt, vorgezogen. Gründe dafür sind die mangelnde Unterstützung von Duplikaten und Aggregatfuktionen im Kontext von Datalog sowie
die Inezienz, die ein solches Vorgehen mit sich bringt (vlg. [Ber05]).
Abbildung 3.9 zeigt den prinzipiellen Aufbau des Compilers. Der Compiler erhält
eine Sichtdenition als Input und erstellt für die der Sicht zugrundeliegenden Sichten sowie die Sicht selbst die entsprechenden Delta-Sichten (vgl. 2.1.4), die die sich
aus Basisfaktenänderungen ergebenden induzierten Änderungen enthalten, sowie die
Transitionssichten, mit Hilfe derer der Datenbankzustand nach Durchführung der
32
Kapitel 3.
SIMON
Abbildung 3.9: Skizze des Compilers [Ber05]
Änderungen simuliert wird. Für die zugrundeliegenden Basistabellen werden entsprechend Delta-Tabellen, die die Basisfaktenänderungen enthalten, und Transitionssichten generiert. Der Compiler stellt eine Erweiterung von Access dar und ist
mittels VBA in Access integriert. Er kann SQL-Ausdrücke des von Access verwendetet Dialekt JET-SQL verarbeiten.
Der Compiler besteht aus drei Teilen: Parser, Analyser und Code Generator (vgl.
Abbildung 3.9). Im Parser wird die zu kompilierende Sichtdenition verarbeitet.
Die Zeichen werden in Tokens aufgeteilt und auf Bestandtteile überprüft, die der
Compiler nicht bearbeiten kann. Der Analyser bearbeitet und verändert den Code
in der Weise, dass er leichter in ein Zielprogramm übersetzt werden kann. Der Code
Generator wandelt die Zwischendarstelllung des Quellprogramms in ein äquivalentes
Zielprogramm um.
Parser
Der Parser erhält als Eingabe den Namen der zu kompilierenden SQL-Sicht. Die
entsprechende Sichtdenition wird aus dem Datenbankschema ausgelesen und als
Zeichenkette (String) übergeben. Es wird angenommen, dass diese Denition korrekt ist, da sie beim Abspeichern in der DB auf ihre Korrektheit überprüft worden
sein sollte. Die Zeichenkette wird auf eine einheitliche Form gebracht, indem Zeilenumbrüche entfernt und zwischen Operatoren und Relationen und deren Attributen
Leerzeichen eingefügt werden. Dies ist notwendig, um später zwischen Relationsnamen und deren Attributen unterscheiden zu können. Anschlieÿend wird der String
auf Operatoren geprüft, die vom Compiler nicht bearbeitet werden können. Die sind
z.B. OUTER JOINs, SOME-, ANY-, ALL- Unterabfragen, Access-eigene Aggregatfunktionen sowie Aggregatfunktionen in Selektions- und Gruppierungsbedingungen.
Zusätzlich wird sichergestellt, dass die Sicht eine Sicht im Sinne einer virtuellen
Relation ist, da Access Sichten als Abfragen speichert und somit dort auch Konstrukte mit CREATE, ALTER, DROP, DELETE, INSERT, UPDATE, SELECT
3.7
Compiler
33
INTO usw. auftreten können. Im Anschluss wird der SQL-String in einzelne Tokens
aufgesplittet, wobei zwischen zwei Leerzeichen genau ein Token liegt (Funktion:
String-Tokenizer (Text As String) As Liste ). Die Liste von Tokens wird zurückgegeben.
Analyser
Der Analyser erhält als Eingabe die vom Parser generierte Liste von Tokens. Die
Prozedur Polaritaet_bestimmen(Tokenliste, Pos_Pol, Neg_Pol, Alle_Rel) splittet
die Menge Alle_Rel aller darin vorkommenden Relationen entsprechend der Polaritäten disjunkt in die Mengen Pos_Pol und Neg_Pol auf. Es werden die Tokens
als Relationen erkannt, die sich zwischen FROM- und WHERE-Teil benden und
durch Kommata getrennt sind. Wichtig ist, die Schachtelungstiefe hinsichtlich negierter Negationen zu beachten, da diese nur in Verschachtelungen auftreten können
(vgl. [Ber05]).Falls die erkannte Relation selbst eine Sicht und keine Basistabelle ist,
wird die Bearbeitung des aktuellen Strings unterbrochen und ein neuer Compilierungsschritt gestartet. Dies kann sich kaskadierend fortsetzen. Sobald der Compilierungsschritt einer Relation beendet ist, wird der entsprechend vorher aktive Schritt
weitergeführt. Zurückgegeben werden die Menge aller Relationen (Alle_Rel ), die
Menge der Relationen mit positiver Polarität (Pos_Pol ) und die Menge der Relationen mit negativer Polarität (Neg_Pol ).
Code-Generator
Der Code-Generator erzeugt aus den in den vorherigen Schritten durch Parser und
Analyser berechneten Ergebnissen (Listen und Mengen) den Code der Delta-Sichten.
Dies erfolgt in 4 Schritten:
Schritt 1:
Zuerst werden die in Alle_Rel vorkommenden Basisrelationen bearbei-
tet. Durch die Methode Transitionssicht_Inkrementell(Tabellenname) werden die
entsprechenden Delta-Tabellen, in denen die Einfügungen und Löschungen von Basisdaten gespeichert werden sollen sowie die entsprechenden inkrementellen Transitionssichten erstellt.
Schritt 2:
Für die zu bearbeitende Sicht wird mittels der Methode Transitions-
sicht_Naiv (Tokenliste, Sichtname, Alle_Rel) eine naive Transitionssicht erstellt.
Zuerst wird die aktuelle Sichtdenition in eine Tokenliste umgewandelt. In Abhängigkeit der Anzahl
n
der der Sicht zugrundeliegenden Relationen wird
n
mal die
Methode Sub Ersetzen(..) auf, innerhalb der die Tokenliste angepasst wird. Dabei
wird sukzessive das Token jeweils einer der zugrundeliegenden Relationen durch die
entsprechende Transitionssicht ersetzt. Die neue Tokenliste entspricht der naiven
Transitionssicht der zu bearbeitenden Sicht und wird mittels der Methode SQL-
String_aufbauen zu einer solchen zusammengesetzt und unter dem neuen Namen in
der DB gespeichert.
34
Kapitel 3.
Schritt 3:
SIMON
Durch die Prozeduren Delta_Sicht_Plus (Tokenliste, Sichtname) und
Delta_Sicht_Minus (Tokenliste, Sichtname) werden die Delta-Sichten erstellt.
Schritt 4:
In Abhängigkeit davon, ob die zu kompilierende Sicht innerhalb
der SELECT-Klausel eine Aggregatfunktion enthält, wird eine der Funktionen
Aggregatfunktion_Min_Max_First_Last(Tokenliste,
Sichtname),
on_Count_Sum_Avg(Tokenliste,
Eektivitaetstest(Sichtname)
Sichtname)
oder
Aggregatfunkti-
aufgerufen. Diese erstellen die Delta2-Sichten, die spezielle Auswertungen für Aggragatfunktionen oder den Eektivitätstest enthalten (vlg. [Ber05]).
Die konkrete Vorgehensweise bei der Generierung der Delta- und Transitionssichten
wird im folgenden Abschnitt 3.7.2 beschrieben.
3.7.2 Beispiel zur Kompilierung
Der Compiler erstellt anhand einer Sichtdenition für die zugrundeliegenden Basistabellen und Sichten sowie die Sicht selbst Propagierungs- und Transitionsregeln
im Kontext von SQL. Beim Erstellen der Delta- und Transitionsregeln wird intuitiv
in Anlehnung an die entsprechenden Datalog-Regeln vorgegangen. Für komplexere
Beispiele und die Behandlung weiterer SQL-Operatoren sei auf [Ber05] verwiesen.
Für die Basistabellen werden folgende Tabellen und Sichten generiert:
•
Delta-Plus-Tabelle
•
Delta-Minus-Tabelle
•
inkrementelle Transitionssicht
Die Delta-Tabellen stellen Kopien der jeweiligen Basistabelle (Sux _Plus bzw.
_Minus) dar. In diesen Tabellen werden die Einfügungen bzw. Löschungen der
Basisdaten zwischengespeichert. Die inkrementelle Transitionssicht (Sux _New)
entspricht einer inkrementeller Transitionsregel in Datalog, die den neuen Zustand
der Tabelle nach Durchführung der Änderungen simuliert. Beispiel 3.4 zeigt die
Generierung einer inkrementellen Transitionssicht.
Beispiel 3.4 (inkrementelle Transitionssicht [Ber05])
SELECT * FROM a WHERE NOT EXISTS
( SELECT a− .name FROM a− WHERE a.name = a− .name )
UNION ALL
SELECT * FROM a+
Für die Sichten werden folgende Sichten generiert:
3.7
Compiler
•
Delta-Plus-Sicht
•
Delta-Minus-Sicht
•
naive Transitionssicht
35
Die Delta-Sichten (Sux _Plus bzw. _Minus) entsprechen den Delta-Regeln in
Datalog und enthalten die entsprechend induzierten Änderungen. Beispiel 3.5 zeigt
die Generierung einer Delta-Plus-Sicht. Die naive Transitionssicht (Sux _New)
entspricht einer naiver Transitionsregel in Datalog und dient zur Simulation des neuen Zustands der entsprechenden Sicht. Eine naive Transitionssicht wird in Beispiel
3.6 aufgezeigt.
Beispiel 3.5 (Delta-plus-Sicht [Ber05])
Sicht in SQL:
SELECT a.name FROM a,b,c WHERE a.name=b.name AND a.name=c.name
Sicht in Datalog:
q(y) ← a(y), b(y), c(y).
Delta-Regeln in Datalog:
+
+
new
new
q ← a (y), b (y), c (y), not q(y)
q + ← anew (y), b+ (y), cnew (y), not q(y)
q + ← anew (y), bnew (y), c+ (y), not q(y)
Delta-plus-Sicht in SQL:
SELECT a+ .name FROM a+ ,bnew ,cnew
WHERE a+ .name=bnew .name AND
a+ .name=cnew .name
UNION ALL
SELECT anew .name FROM anew ,b+ ,cnew WHERE anew .name=b+ .name AND
anew .name=cnew .name
UNION ALL
SELECT anew .name FROM anew ,bnew ,c+ WHERE anew .name=bnew .name AND
anew .name=c+ .name
Beispiel 3.6 (naive Transitionssicht [Ber05])
SELECT anew .name FROM anew ,bnew ,cnew WHERE anew .name=bnew .name AND
anew .name=cnew .name
In [Ber05] wird die Notwendigkeit eines Eektivitätstests begründet. Im Falle einer Mengensemantik ist ein solcher Test auf echte Änderungen sinnvoll ([Man04]).
36
Kapitel 3.
SIMON
Zusätzlich macht das Verfahren zur Erstellung der Delta-Sichten einen Eektivitätstest nötig, um ein Auftreten falscher Fakten in den Delta-Relationen zu verhindern
(vgl. [Ber05]). Da von Access der MINUS-Operator nicht unterstützt wird, ist der
Eektivitätstest durch den NOT EXISTS-Operator realisiert. Für jede Sicht, die keine Aggregatfunktion enthält, werden (Delta2-)Sichten mit Eektivitätstest (Sux
_Plus2 bzw. _Minus2) generiert. Beispiel 3.7 zeigt den Eektivitätstest der in
Beispiel 3.5 generierten Delta-Sicht. Die enthaltenen Access-Funktionen garantieren
eine korrekte Behandlung von NULL-Werten.
Beispiel 3.7 (Eektivitätstest [Ber05])
SELECT DISTINCT r+ .name
FROM r+
WHERE NOT EXISTS
( SELECT *
FROM q
WHERE IIF ( ISNULL (q.name),
IIF (ISNULL ( q + .name), TRUE, FALSE),
IIF (ISNULL(q + .name),FALSE,q.name=q + .name)
)
);
Der Compiler garantiert keine korrekte Behandlung von Duplikaten in den DeltaSichten, somit ist auch eine korrekte Behandlung von Aggregatfunktionen nicht garantiert [Ber05]. Der Compiler behandelt nur die Aggregatfunktionen (MIN, MAX,
COUNT, SUM, AVG). Diese Aggregatfunktionen dürfen nur im Haupt-SELECTTeil einer Sicht auftreten. Die aggragatfunktionen werden in zwei Gruppen eingeteilt
(MIN/MAX sowie COUNT/SUM/AVG) und entsprechend unterschiedlich behandelt. Bei der Behandlung von MIN/MAX werden zwei weitere Delta-Sichten (Delta2)
erstellt, innerhalb derer die Aggregatfunktionen ausschlieÿlich auf die Ergebnisse der
Delta-Sichten angewendet werden. Diese (Delta2-)Sichten enthalten die gewünschten Tupel. Im Falle von COUNT/SUM/AVG wird eine (Delta2-)Sicht erstellt, die
den gewünschten Wert aus der Anwendung der entsprechenden Aggregatfunktion
auf die Sicht und den jeweiligen Delta-Sichten berechnet.
3.7.3 Einbettung des Compilers in MS-Access
Der Compiler ist durch mehrere benutzerdenierte VBA-Prozeduren und Funktionen in Access implementiert. Mit Hilfe der Formulare Start, Sichten_Generieren,
Tabellen_Ändern, Sichten_Ansehen können die Funktionalitäten des Compilers genutzt werden. Abbildung 3.10 zeigt die Einbettung in MS Access. Mittels
3.8
Beipsielszenario
37
des Startformulars werden die anderen Formulare geönet. Der Algorithmus zum
Erstellen der Delta- und Transitionssichten (Kompilierung) wird ausgeführt, indem man im Formular Sichten_Generieren eine Sicht auswählt und den Button
Generieren drückt. Dabei werden die entsprechend hinterlegten VBA-Routinen
aufgerufen (vgl. Abschnitt 3.7.1) Mittels des Formulars Tabellen_Ändern kann
man Tupel in einzelne Delta-Tabellen einfügen bzw. löschen. Das Formular Sichten_Ansehen kann einzelne Delta-Sichten anzeigen lassen. Zusätzlich bietet das
Startformular die Möglichkeit, alle nach Durchführung der Änderungspropagierung
in den Delta-Tabellen vorhandenen Tupel in die entsprechenden Tabellen zu übertragen und so den Propagierungsschritt zu vervollständigen bzw. die Tupel zu löschen
und somit die Propagierung abzubrechen.
Abbildung 3.10: Einbettung des Compilers in Access [Ber05]
3.8
Beipsielszenario
Um das SIMON-System testen zu können, wird ein Anwendungsszenario benötigt.
Es sind dabei Daten zur Netzwerktopologie, Daten der mobilen Objekte einschlieÿlich ihrer Skripte sowie die zu überwachenden Bedingungen und die zugrundeliegenden Basisdaten notwendig. In [Roh05] wurde eine Datenbank zur Verwaltung
von Netz- und Fahrplandaten im Bahnverkehr entworfen und realisiert. Darin enthalten sind zusätzlich verschiedene Überwachungsszenarien für den Bahnverkehr in
Deutschland sowie ein datenbankgestütztes Fahrplanauskunftssystem. Die Realisierung der Datenbank erfolgte in Microsoft Access 2000. Ziel war es, eine Datenbank
38
Kapitel 3.
SIMON
zu entwerfen, die sowohl den Anforderungen des SIMON-Systems als auch denen
eines Fahrplanauskunftssystems genügen. Für die Repräsentation des Bahnverkehrs
in Deutschland wurde ein geeigneter Ausschnitt (ICE-Verkehr) gewählt, um den
Umfang der Arbeit in angemessenem Rahmen zu halten. Als Datenbasis dienten
das Streckennetz und der Fahrplan der Deutschen Bahn AG. Aufgrund der groÿen
Datenmenge der Fahrplandaten wurde eine möglichst kompakte und änderungsfreundliche Darstellung des Fahrplans entwickelt.
Es wurde die Integration der Datenbank in das SIMON-System vorgenommen. Dadurch wird eine Simulation des Bahnverkehrs durch den Simulator MOSIM ([Bua03])
ermöglicht. Die Fahrplandatenbank versorgt MOSIM mit Informationen über bestimmte Anfangszustände der zu simulierenden mobilen Objekte, die zu Beginn der
Simulation bereitgestellt werden müssen. Zusätzlich dient die Fahrplandatenbank als
Datenbasis für die (datenbankgestützte) Analyse zur Aufdeckung von auÿerplanmäÿigen Situationen. Aufgrund der Anforderungen des SIMON-Systems und des Fahrplanauskunftssystems war es nötig, auÿer der expliziten Repräsentation der Fahrplandaten weitere (Meta-)Daten (wie die Entfernungen zwischen zwei Bahnhöfen, die
Höchstgeschwindigkeiten der Züge usw.) zu speichern. Die für MOSIM benötigten
Tabellen und Daten werden in Form von in Access verfügbaren Tabellenerstellungsabfragen aus den geeigneten Tabellen und Daten der Fahrplandatenbank abgeleitet.
Eine geeignete Typkonversion und -anpassung (z.B. des Datums) wurde mit Hilfe
von Access-Funktionen vorgenommen. Hinsichtlich der Vilualisierungskomponente
VISMONET wurden verschiedene Lösungswege diskutiert, wie die Geokoordinatendarstellung geeignet für eine Darstellung auf dem Bildschirm umgerechnet werden
können.
Das in [Roh05] entwickelte Überwachungsszenario verfolgt den Ansatz der regelbasierten Analyse. Es wurden aus den Basisdaten der Fahrplandatenbank und den
protokollierten Daten des Simulators entsprechende Monitoring- Sichten abgeleitet, um auÿerplanmäÿige bzw. kritische Situationen (wie Anschlusszüge, falsche
Strecken, Geschwindigkeitsabweichungen, Verspätungen, ...) zu erkennen. Zusätzlich wurde dargestellt, wie mit Hilfe von Triggern Reaktionen auf die ermittelten
Situationen ausgelöst werden können.
Kapitel 4
Überwachung von Datenströmen in
SIMON
Dieses Kapitel beschreibt einen Ansatz für ein datenbankgestütztes System zur
Überwachung von Datenströmen. In Abschnitt 3.2 wurde bereits eine Einführung
in die Überwachung von Datenströmen sowie die Modellierung von Datenströmen
und Anfragen über Datenströmen gegeben. In Abschnitt 4.1 wird die Klassikation verschiedener Anwendungen im Kontext der Überwachung von Datenströmen
beschrieben sowie die Anwendungsklasse des SIMON-Projektes festgelegt. Im Anschluss daran werden in Abschnitt 4.2 ausgehend von dieser Anwendungsklasse die
Anforderungen an Systeme zur Überwachung von Datenströmen aufgezeigt und verschiedene Ansätze für solche Systeme bzw. deren Architekturen vorgestellt. In Abschnitt 4.2.4 werden die Funktionalitäten der einzelnen Systeme den spezischen
Anforderungen hinsichtlich der SIMON-Anwendungsklasse gegenübergestellt und
die Einsatzmöglichkeiten der Systeme bewertet. Im Zuge der Bewertung wird ein
Ansatz zur Überwachung von Datenströmen auf Basis eines DBMS motiviert. Abschnitt 4.3 beschreibt diesen Ansatz zur DB-Überwachung von Datenströmen.
4.1
Klassikation von Datenstrom-Anwendungen
Hinsichtlich der Anwendungsszenarien, bei denen Systeme zur Überwachung von
Datenströmen eingesetzt werden, gibt es Unterschiede. In Abschnitt 4.1.1 werden
die Parameter vorgestellt, anhand derer sich die Anwendungen klassizieren lassen.
Abschnitt 4.1.2 erläutert die im Kontext des SIMON-Projektes betrachtete Anwendungsklasse. Diese dient später als Grundlage für die Diskussion der Verwendbarkeit
verschiedener Ansätze zur Analyse von Datenströmen (vgl. Abschnitte 4.2 und 4.2.4)
39
40
Kapitel 4.
Überwachung von Datenströmen in SIMON
4.1.1 Klassikationsschema
Die Unterschiede hinsichtlich der Anwendungsszenarien, bei denen Systeme zur Analyse von Datenströmen eingesetzt werden, lassen sich anhand anhand der Ausprägung bestimmter Parameter hinsichtlich der Vorverarbeitung der Datenströme, der
Anfragen, die an das System gestellt werden, der Analyse der Stromdaten sowie den
daraus resultierenden Ergebnissen (Antworten, Alerts oder Reaktionen) feststellen.
Anhand der Ausprägung der unterschiedliche Parameter können die Anwendungen
klassiziert werden. Abbildung 4.1 skizziert eine allgemeine Architektur von Systemen zur Überwachung und Analyse von Datenströmen und zeigt die Stellen auf, an
denen die verschiedenen Parameter festgestellt werden können.
Abbildung 4.1: Architektur
Die Datenströme (1) können mit folgenden Parametern beschrieben werden:
•
Anzahl der Datenströme
•
Gröÿe der Datenelemente
•
Frequenz
Die zu analysierenden Stromdaten variieren ja nach Anwendung. Zum einen können
die Daten von mehreren Datenströmen stammen. Zudem kann man sich z.B.
4.1
Klassikation von Datenstrom-Anwendungen
41
vorstellen, dass die Datenrate der Datenströme variiert. Die einzelnen Datenelemente haben jeweils eine bestimmte Gröÿe. Pro Zeiteinheit trit eine bestimmte
Anzahl (Menge) dieser Datenelemente auf dem Datenstrom ein. Aus diesen Parametern sowie der Frequenz, mit der die Daten gesendet werden, ergibt sich das
Datenvolumen der Stromdaten. Die Stromdaten können auch in Abhängigkeit der
Anwendung geltert werden. So lässt sich z.B. die zu analysierende Datenmenge
bereits an dieser Stelle reduzieren, wenn bekannt ist, welche Teile der Stromdaten
für die Beantwortung der Anfragen relevant sind. Ebenso unterschiedlich kann
die Weitergabe der Stromdaten ablaufen. Dies kann von der Weitergabe einzelner
Tupel bis hinzu groÿen zusammengehörigen Mengen (Transaktionen) von Tupeln
bzw. synchonisierten oder geordneten Sequenzen (Fenster, Blöcke) variieren.
Folgende Parameter sind im Kontext der Analyse (2) vorstellbar:
•
Art der zur Analyse zugelassenen Daten
•
Umfang (zeitlicher Horizont) der zugreifbaren Stromdaten
Hinsichtlich der Analyse unterscheiden sich die Art der Daten (Strom-, Metadaten)
sowie der Umfang bzw. zeitliche Rahmen der Daten, die zur Analyse zur Verfügung
stehen. Die zur Verfügung stehenden Stromdaten sind dabei von den Parametern
der Vorverarbeitung abhängig. Zusätzlich variiert die Menge der zur Verfügung
stehenden Daten aufgrund der Art der Zwischenspeicherung. Diese kann von
reiner online-Analyse über Benutzung des Hauptspeichers bis hin zur Speicherung
auf einem Sekundärdatenträger variieren. Entsprechend ergibt sich daraus der
Umfang bzw. zeitliche Horizont an historischen Daten, die zur Analyse verwendet
werden können. Die Einbeziehung von weiteren (Meta-)Daten ist ebenso je nach
Anwendung verschieden. So können z.B. gar keine Metadaten zur Analyse benötigt
werden, wenn eine Analyse allein aus den Stromdaten erfolgt. Andererseits kann
man sich ebenso eine Analyse auf Basis riesiger Datenbestände vorstellen. Diese
Daten müssen dem System auf einem geeigneten Speicher in kompatibler Form
verfügbar sein.
Hinsichtlich der Anfragen (3) gibt es u.a. folgende Parameter:
•
Anzahl der Anfragen
•
Typ der Anfragen
•
Frequenz
•
Komplexität
42
Kapitel 4.
Überwachung von Datenströmen in SIMON
Die Parameter hinsichtlich der Anfragen (3) ergeben sich aus dem Typ der Anfragen, der Anzahl der Anfragen sowie der Frequenz, mit der sie an das System gestellt
werden. Die verschiedenen Arten von Anfragen wurden bereits in Abschnitt 3.2.3
vorgestellt. Wichtig ist dabei die Unterscheidung zwischen ad hoc und vordenierten
Anfragen. Im Falle von vordenierten Anfragen kann die Vorverarbeitung bzw.
Analyse evtl. hinsichtlich der zur Beantwortung der Anfrage benötigten Daten
beeinusst werden. Bei ad hoc Anfragen ist dies nicht möglich, was dazu führt, dass
diese evtl. nur approximativ oder evtl. auch gar nichtbeantwortet werden können.
Einmalige Antworten werden nur ein mal an das System gestellt. Im Falle von
kontinuierlichen Anfragen unterscheidet sich je nach Anwendung die Frequenz, mit
der die Anfragen kontinuierlich gestellt werden. Zusätzlich variiert die Komplexität
der Anfragen, d.h. es kann z.B. Unterschiede hinsichtlich der Anzahl der genutzten
Operatoren sowie hinsichtlich der Daten, über denen die Antworten ausgewertet
werden.
Die
Komplexität
hinsichtlich
der
zugrundeliegenden
Daten
(Umfang,
Zeitraum) steht dabei in Zusammenhang mit den entsprechenden Parametern der
Analyse.
Die Analyseergebnisse (4) können mit folgenden Parametern beschrieben werden:
•
Granularität
•
Genauigkeit
•
Benötigte Zeit zur Berechnung
Die Ergebnisse der Analyse bestehen meist aus den Antworten auf die an das System gestellten Anfragen und stehen somit ebenso in Zusammenhang mit den zur
Verfügung stehenden Daten. Dementsprechend resultiert die Genauigkeit der Antworten (exakt oder zu einem bestimmten Grad approximativ) aus den Parametern
hinsichtlich der Analyse. Die Granularität der Antworten ist durch die Parameter
der Anfragen festgelegt und variiert somit zwischen one-time und kontinuierlich mit
einer bestimmten Frequenz. Ein weiterer Parameter, der nicht direkt beeinusst
werden kann, ist die zur Berechnung der Ergebnisse bzw. zur Beantwortung der Anfragen benötigte Zeitspanne. Diese resultiert aus anderen festgelegten Parametern
und kann z.B. in Bezug auf eine Echtzeit-Forderung im Kontext einer Anwendung
wichtig sein. Diese ist erfüllt, wenn die Anfragen mit einer hohen Frequenz gestellt
und die Antworten innerhalb eines sehr geringen Zeitintervalls berechnet werden.
Die Komplexität der Anfrage muss darauf z.B. entsprechend angepasst werden.
4.1.2 SIMON
Monitoring-Anwendungen können eine unterschiedliche Charakteristik aufweisen.
Maÿgeblich für diese Charakteristik sind die Ausprägungen der Parameter in vorangegangenen Abschnitt vorgestellten Parameter, anhand derer sich die Anwendungen
4.1
Klassikation von Datenstrom-Anwendungen
43
klassizieren lassen. Die im Kontext des SIMON-Projektes betrachteten Anwendungen werden durch die in Abbildung 4.2 dargestellten Ausprägungen der Parameter
klassiziert.
Parameter
Ausprägung
Anzahl der Datenströme
niedrig
Gröÿe der Datenelemente
klein
Frequenz hinsichtlich Datenstrom
niedrig
Anzahl der Anfragen
hoch
Typ der Anfragen
kontinuierlich
Frequenz der Anfragen
niedrig
Komplexität der Anfragen
hoch
Menge an historischen Stromdaten
hoch
Menge an zusätzlichen Metadaten
hoch
Granularität der Antworten
hoch
Genauigkeit der Antworten
hoch
Beschränkung hinsichtlich der Berechnungszeit
gering
Abbildung 4.2: Anforderungen der Anwendungsklasse im Kontext von SIMON
Bei Anwendungen dieser Klasse, wie z.B. bei dem in dieser Arbeit verwendeten Szenario der Überwachung des ICE-Verkehrs der deutschen Bahn, ist das Datenvolumen
der Stromdaten eher gering. Die Stromdaten bestehen dabei meist aus den Positionsdaten der mobilen Objekte des Szenarios, d.h. die einzelnen Datenelemente haben
eine geringe Gröÿe. Dadurch dass keine Forderung nach Echtzeit-Analyse vorhanden ist, ist keine hohe Frequenz hinsichtlich der Übermittlung der Daten notwendig.
Die Stromdaten können somit über einen hinreichend groÿen Zeitraum zwischengespeichert werden. Zudem reicht es aus, wenn die Ergebnisse der Analyse nicht
innerhalb weniger Millisekunden, sondern innerhalb von bis zu einigen Sekunden
vorliegen. Vielmehr ist für die Analyse die Einbeziehung von Metadaten sowie einer
groÿen Menge an (historischen) Stromdaten wichtig. Dadurch sind Anfragen von
hoher Komplexität möglich, d.h. es werden eine groÿe Menge an Operatoren und an
zugrundeliegenden Daten verwendet. Zusätzlich soll auf die Analyseergebnisse aktiv
reagiert werden.
Beispiel 4.1 (Monitoring Szenario Teil 4)
Das Beispiel 3.3 wird fortgeführt.
Die Daten des Datenstroms werden in geringem Takt (>1s) an das System weitergeleitet. Ein geringerer Takt ist im Kontext der Anwendung nicht sinnvoll, da die
exakte Position der ICE-Züge (bis auf wenige mm genau) nicht von Interesse ist.
Die Datenmenge ist nicht sehr groÿ, es wird meist für jeden Zug ein Tupel innerhalb
des Datenstroms gesendet. Die Analyse des Datenstroms verlangt die Einbeziehung
von Metadaten, um z.B. einen Vergleich mit dem Fahrplan durchführen zu können.
44
Kapitel 4.
Überwachung von Datenströmen in SIMON
Die Anwendung ist nicht zeitkritisch, d.h. die Ergebnisse der Analyse müssen nicht
in Realzeit (innerhalb weniger ms) ausgegeben werden, eine Zeitspanne von einigen
Sekunden ist ausreichend.
4.2
Ansätze zur Überwachung von Datenströmen in
SIMON
Um rechnergestützte Überwachung von Datenströmen durchführen zu können,
wird eine geeignete Softwarekomponente benötigt, die solche Datenströme verarbeiten kann. Die Verarbeitung der Daten im Kontext der Überwachung von Datenströmen unterscheidet sich wesentlich von der konventioneller Datenverarbeitung
([CCC+02]). Statt einer häugen Kommunikation zwischen dem Software-System
und dem Benutzer sollen statt dessen kontinuierliche Inputs autonom verarbeitet
werden. Die Software soll selbstständig auf entdeckte Ereignisse reagieren und den
Benutzer darüber informieren.
Die Verarbeitung und Analyse von Datenströmen stellen einige Anforderungen an
die zugrundeliegende Softwarekomponente ([CCC+02], [SCZ05]):
•
•
•
•
Verarbeitung von Stromdaten
üchtige Daten
sequentieller Zugri
ungeordnete Daten
unsicherer Datentransfer
ggf. Filterung
Analyse von Stromdaten
ggf. Einbeziehung statischer Daten zur Analyse
ggf. Zwischenspeicherung von Stromdaten
geeignete Anfragesprache
kontinuierliche Anfragen
Fensterung
möglicherweise approximative Antworten
4.2
Ansätze zur Überwachung von Datenströmen in SIMON
45
So handelt es sich im Kontext der Verwaltung von Datenströmen um üchtige Daten. Jeder Datensatz innerhalb der Datenströme wird nur ein mal gesendet und ist
danach, sofern er nicht zwischengespeichert wird, nicht mehr zugreifbar. Auf die
Daten der Datenströme kann, sofern sie nicht zwischengespeichert werden, nicht
wahlfrei, sondern nur sequentiell in Abhängigkeit der Reihenfolge, in der die Datensätze eintreen, zugegrien werden. Zusätzlich können bei der Verarbeitung von Datenströmen Fehler hinsichtlich der Datenübertragung auftreten. Die Daten können
ungeordnet eintreen und es können sich Verzögerungen bei der Datenübertragung
ergeben, sodass Datensätze entweder verspätet oder gar nicht eintreen. Es müssen
entsprechende Techniken in die Systeme integriert werden können, die eine Verarbeitung auch bei verlorengegangenen Tupeln möglich macht ([SCZ05]). Dies kann
z.B. durch eine blockweise Verarbeitung bzw. Fensterung der Daten durchgeführt
werden. Dadurch wird ein nicht-blockierendes Verhalten bei der Anfragebearbeitung
gewährleistet.
Die zu analysierende Datenmenge der Datenströme verbietet je nach Anwendung
eine vollständige Speicherung aller Daten. Somit können die Daten entweder ausschlieÿlich im Hauptspeicher verarbeitet werden, oder es wird vor dem Speichern
eine Vorverarbeitung durchgeführt.
Anfragen an die Softwarekomponente müssen in einer geeigneten Anfragesprache
speziziert werden können. Die Anfragen werden meist nicht nur einmalig, sondern
kontinuierlich gestellt. Da je nach Anwendung meist keine vollständige Speicherung
der Daten vorgenommen werden kann, können die Anfragen meist nur approximativ beantwortet werden. Hinsichtlich der Komplexität der Analyse ist es wichtig,
dass weitere (Meta-)Daten im System gespeichert werden können, um diese bei der
Analyse der Stromdaten einbeziehen zu können. Zusätzlich sollte es die Möglichkeit
geben, relevante Teile der Stromdaten zwischenzuspeichern, um später Vergleiche
der aktuellen Stromdaten mit den historischen Daten durchführen zu können.
Im Kontext verschiedener Anwendungen (vgl. Abschnitt
??) ergeben sich einige An-
forderungen hinsichtlich der Operationen, die die zugrundeliegende Anfragesprache
bei der Spezizierung von kontinuierlichen Anfragen unterstützen sollte ([GÖ03]).
Dies sind u.a. Selektion (komplexes Filtern), Joins (Multi-Stream Loins bzw. Joins
zwischen Stream- und statischen Meta-Daten), Fensteranfragen etc.
Zusätzlich gibt es weitere Anforderungen hinsichtlich der Anwendungen aufgrund
der Charakteristik von Datenströmen und kontinuierlichen Anfragen ([GÖ03]). Das
Datenmodell der Datenströme und der Anfragen müssen ordnungs- und zeitbasierte
Operationen unterstützen (z.B. Anfragen über ein sliding window einer xen Länge).
Falls der Datenstrom nicht vollständig gespeichert werden kann, müssen Funktionalitäten zur Reduzierung der Datenmenge (z.B. Approximieren durch Aggregation)
vorhanden sein. Daraus resultiert, dass die Antworten auf Anfragen möglicherweise
nicht mehr exakt sind.
46
Kapitel 4.
Überwachung von Datenströmen in SIMON
Abbildung 4.3 zeigt die abstrakte Architektur, die Systemem zur Überwachung von
Datenströmen meist zugrunde liegt. Das System erhält als Input die Daten der
Datenströme. Es werden Anfragen an die Software gestellt, hinsichtlich derer die
Datenströme analysiert werden. Die Resultate der Analyse werden an den Benutzer
oder andere Applikationen weitergeleitet.
Abbildung 4.3: allgemeine Architektur
Im folgenden werden nun verschiedene Ansätze für Klassen für Software-Systeme
(Systemarchitekturen) zur Verarbeitung von Datenströmen vorgestellt. Darunter
Fallen aktive Datenbankmanagementsysteme, die auch bislang zur datenbankgestützten Analyse verwendet wurden, regelverarbeitende Systeme sowie speziell für
den Umgang mit Datenströmen autonomer Datenquellen entworfene Datenstrommanagementsysteme, welche in der Forschung in den letzten Jahren verstärkt behandelt
wurden. Die Aufteilung in Klassen erfolgt in Anlehnung an [SCZ05].
4.2.1 Datenbankmanagementsysteme
Traditionelle Datenbankmanagementsysteme (DBMS) werden meist zur Verwaltung
persistenter Daten verwendet ([GÖ03]). Sie sind konzipiert, um unterschiedliche
Anfragen über einem aktuellen Datenbestand auszuwerten. Die Verarbeitung der
Daten ndet bei einem DBMS i.d.R. erst nach dem Speichern statt [SCZ05]. Die
Speicherung von Daten in einem DBMS wird i.a. durch einen Benutzer bzw. ein
Anwendungsprogramm vorgenommen. Das System selbst ist passiv. Die Daten werden dabei in persistenten Relationen auf einem sekundären Datenspeicher abgelegt,
auf die wahlfrei zugegrien werden kann. Der wahlfreie Zugri ermöglicht Anfragen
über groÿe Zeiträume. Aufgrund der Speicherung aller Daten sind die Antworten
auf die Anfragen exakt.
Ein
aktives
DBMS,
DBMS
welches
die
(ADBMS)
ist
Spezikation
ein
um
reaktiven
aktive
Regelkonzepte
Verhaltens
des
DBMS
erweitertes
ermöglicht
([Cha92],[PD99]). Ein ADBMS kann anwendungsspezisch denierte Situationen
4.2
Ansätze zur Überwachung von Datenströmen in SIMON
47
erkennen und daraufhin anwendungsspezisch denierte Reaktionen auslösen und
eignet sich somit für datenbankgestützte Monitoring-Anwendungen ([Cha92]). Die
Spezikation des reaktiven Verhaltens erfolgt in aktiven Datenbanken mittels einer
aktiven Regelsprache.
Abbildung 4.4 beschreibt die Architektur bei Verwendung eines DBMS zur Verwaltung von Stromdaten. Dabei werden die Stromdaten direkt in der Datenbank
gespeichert. Applikationen oder Benutzer können Anfragen stellen (pull), die über
diesen Daten ausgewertet werden. Im Falle eines ADBMS (vgl. Abbildung 4.5) kann
das System autonom auf Inputs reagieren. Durch die aktiven Regeln (Trigger) können benutzerdenierte Reaktionen ausgelöst werden, wie z.B. die Generierung einer
Meldung oder die Weitergabe von Daten an Applikationen (push).
Abbildung 4.4: Basisarchitektur eines DBMS
Abbildung 4.5: Basisarchitektur ADBMS
4.2.2 rule engines
In Systemen dieser Art, wie z.B. Prolog [XXX], werden Regeln speziziert, die aus
einem Bedingungs- und einem Aktions-Teil bestehen (z.b. in if-then-Notation).
48
Kapitel 4.
Überwachung von Datenströmen in SIMON
Abbildung 4.6 beschreibt die Architektur von rule engines bei der Überwachung von
Datenströmen. In der Regelbank (rule base ) werden die Regeln persistent gespeichert. Die Stromdaten werden innerhalb des Systems mit den Regeln abgeglichen.
Wenn die Bedingung einer Regel erfüllt ist, wird die zur Regel korrespondierende
Aktion ausgeführt. Dies kann z.B. das Produzieren von Outputs bzw. Meldungen
oder die Änderung interner Variablen des Systems sein, wodurch weitere Regeln
ausgelöst werden können.
Abbildung 4.6: Basisarchitektur einer Rule Engine
4.2.3 Datenstrommanagementsysteme
Datenstrommanagementsysteme (DSMS) sind Systeme, die speziell zur Analyse von
kontinuierlichen Datenströmen entworfen wurden ([SCZ05]). Bei Systemen dieser
Architektur (vgl. Abbildung 4.7) werden die Daten der Datenströme direkt verarbeitet und nicht zwingend gespeichert. Falls eine Speicherung der Daten vorgenommen
werden soll, kann ein traditionelles DBMS zur Verwaltung der Daten in das System
integriert werden ([SCZ05]).
Abbildung 4.7: Basisarchitektur eines DSMS
4.2
Ansätze zur Überwachung von Datenströmen in SIMON
49
Ein DSMS dient der Verwaltung von Daten kontinuierlicher Datenströme. Die Analyse der Daten wird dabei entweder direkt im Hauptspeicher durchgeführt (online)
oder es werden nach einer Vorverarbeitung relevante Teildaten aus den Datenströmen extrahiert und auf einem Sekundärspeicher abgelegt. Generell ist also nur ein
sequentieller Zugri bzw. ein Zugri nur auf Teildaten möglich. Im allgemeinen
werden kontinuierliche Anfragen an das DSMS gestellt. Wesentlicher Unterschied
zum Einsatz eines klassischen DBMS ist, dass nicht meist identische Anfragen über
einem bestimmten Datenbestand gestellt werden, sondern kontinuierlich gleichbleibende Anfragen über sich ändernden Daten ausgewertet werden. Das Zeitfenster,
über dem die Anfragen ausgewertet werden können, hängt von der Kapazität des
Hauptspeichers bzw. der Menge der gespeicherten Daten ab. Da nur Daten innerhalb eines bestimmten Zeitfensters vorliegen oder z.B. Daten bei der Speicherung
aggregiert werden, um die Datenmenge zu begrenzen, sind bei Verwendung eines
DSMS die Antworten auf Anfragen i.a. nicht exakt, sondern approximativ.
Die Forschungsinteressen im Kontext der rechnergestützten Überwachung von Datenströmen haben zu einer Vielzahl an akademischen Projekten mit unterschiedlichsten thematischen Schwerpunkten geführt. Die folgende Aufzählung gibt (in Anlehnung an [GÖ03]) eine Übersicht über einige dieser akademischen Projekte im
Kontext von Datenstrommanagementsystemen:
•
Aurora ([CCC+02], [CBB+03]) ist ein work ow -orientiertes System. Der Benutzer erstellt die Auswertungspläne für Anfragen, indem er Boxen (Operatoren) und Pfeile (Datenuss zwischen den Operatoren) graphisch anordnet.
•
COUGAR ([BGS00], [BGS01]) ist eine Sensornetz-Datenbank. Die Sensoren
werden als abstrakte Datentypen und die ausgegebenen Daten als Zeitreihe
modelliert. Aktuell wird im COUGAR Projekt an der Anfragebearbeitung
innerhalb von Sensornetzen gearbeitet.
•
Gigascope ([CGJ+02]) ist eine Architektur zur Überwachung verteilter Netzwerke. Dabei werden Anfrageoperatoren zu den Quellen der Daten verschoben
•
NiagaraCQ ([CDTW00]) ist ein System zur Analyse dynamischen Webinhalts
mittels kontinuierlicher Anfragen. Das System führt mehrere kontinuierliche
Anfragen (in XML-QL speziziert) unterteilt in Gruppen über Stromdaten
aus, wobei jede Gruppe ähnlicher Anfragen einen gemeinsamen Auswertungsplan besitzt.
•
OpenCQ ([LPT99]) ist ein System zur Analyse streambasierten Webinhalts.
Dabei wird der Fokus auf skalierbare ereignisgetriebene Anfragebearbeitung
gelegt.
•
StatStream ([ZS02]) ist ein Datenstrom-Analyse-System zur Berechnung von
online Statistiken über mehreren Datenströmen.
50
Kapitel 4.
•
Überwachung von Datenströmen in SIMON
STREAM ([MWA+03]) ist ein universelles relationales System mit dem
Schwerpunkt des Speichermanagements sowie der approximativen Anfragebeantwortung.
•
TelegraphCQ ([CCD+03]) ist ein System zur Verwaltung kontinuierlicher Anfragen mit Fokus auf geteilter Anfrageauswertung und adaptiver Anfragebearbeitung.
•
Tribeca ([SH98]) ist ein Tool zur online Überwachung von Datenverkehr im
Internet.
4.2.4 Fazit
Im Kontext der in Abschnitt 4.1.2 vorgestellten Klasse von Anwendungen sollen im
folgenden die vorgestellten Ansätze zur Analyse von Datenströmen verglichen und
bewertet werden.
DBMS rule engine DSMS
Vorverarbeitung der Datenströme
o
(x)
x
Einbeziehung von historischen Stromdaten
x
o
(x)
Einbeziehung groÿer Mengen von Metadaten
x
o
o
kontinuierliche Anfragen
o
(x)
x
Erkennen komplexer Ereignisse
o
o
(x)
Abbildung 4.8: Gegenüberstellung der Anforderungen der Szenarioklasse mit den
Architekturen
Abbildung 4.8 gibt einen Überblick über die Erfüllung der Anforderungen der verschiedenen Ansätze hinsichtlich der Anwendungsklasse.
Ein wesentlicher Unterschied zwischen dem Einsatz eines DSMS und dem ausschlieÿlichen Einsatz eines DBMS besteht in der Verarbeitung der Stromdaten ([CHKS03]).
Bei Verwendung eines DBMS ist keine Komponente zur Vorverarbeitung der Stromdaten vorhanden. Die Daten werden ohne jegliche Vorverarbeitung direkt in der
Datenbank gespeichert und erst danach analysiert ([SCZ05]). Bei Verwendung eines
DSMS ndet im Gegensatz dazu eine Vorverarbeitung statt. Die Stromdaten werden
direkt online analysiert. Die Stromdaten werden direkt online analysiert. Möglicherweise ndet danach eine Speicherung der Daten statt, um historische Stomdaten für
entsprechende kontinuierliche Anfragen zur Verfügung zu stellen. Bei Verwendung
einer rule engine werden die Stromdaten ebenfalls ohne Zwischenspeicherung direkt
verarbeitet.
Besonders zeitkritische Analysen der Datenströme lassen sich meist nur durch eine Verarbeitung der Daten im Cache bzw. Hauptspeicher erreichen ([SCZ05]), da
4.2
Ansätze zur Überwachung von Datenströmen in SIMON
51
eine Speicherung dieser Daten aufgrund von längeren Zugriszeiten auf den Sekundärspeicher nicht möglich ist. Dadurch wird jedoch die Komplexität der Anfragen
eingeschränkt, da z.B. die für die Beantwortung benötigten Daten evtl. hinsichtlich der zeitlichen Dimension ohne Zwischenspeicherung nicht verfügbar sind. Bei
der betrachteten Anwendungsklasse ist jedoch keine Forderung nach einer EchtzeitAnalyse vorhanden (vgl. Abschnitt 4.1.2).
Wichtig ist jedoch die Speicherung einer groÿen Menge an Stromdaten, um Anfragen
über einen groÿen Zeitraum beantworten zu können. Beim Einsatz von Datenbanken können groÿe Mengen an Stromdaten archiviert werden, die Datenmenge im
Kontext der Anwendungsklasse lässt eine Speicherung zu. Der Umfang der verfügbaren historischen Stromdaten ist bei einem DSMS von der speziellen Architektur
abhängig. Meist ist jedoch, sofern überhaupt eine Speicherung durchgeführt wird,
nur kleiner Teil der Stromdaten zugänglich bzw. die historischen Stromdaten liegen
in aggregierter Form vor und erlauben nur approximative Antworten auf entsprechende Anfragen. Rule engines erlauben keine Speicherung von Stromdaten, da nur
lokale Variablen mit Daten gefüllt werden können. Ebenso verhält es sich bei den zur
Analyse benötigten Meta-Daten. Ein DBMS kann eine groÿe Menge an Meta-Daten
in homogener Form zur Verfügung stellen, wohingegen dies bei einem DSMS meist
nicht der Fall und bei rule engines nicht möglich ist. Im Falle der Speicherung groÿer
Mengen an Stromdaten werden jedoch zusätzliche Funktionalitäten wie eine geeignete Histroienverwaltung sowie eine garbage collection für die Stromdaten benötigt,
welche ein DBMS nicht bereitstellt.
Datenstrommanagementsysteme beinhalten Mechanismen zur Verwaltung und Beantwortung kontinuierlicher Anfragen, da sie meist speziell für diesen Zweck entworfen wurden ([SCZ05]). Bei rule engines werden ebenfalls die im System spezizieten
Regeln kontinuierlich ausgeführt, die zur Verfügung stehenden Operatoren der Regelsprache sind jedoch beschränkt ([SCZ05]). Kontinuierliche Anfragen auf Datenströmen lassen sich ebenfalls mit den in gängigen DBMS bereitgestellten Mechanismen
nicht realisieren ([BBD+02]), da erforderliche Funktionalitäten zur Verwaltung und
Ausführung der kontinuierlichen Anfragen fehlen.
Die Umsetzung von Techniken wie z.B. der blockweisen Verarbeitung von Stromdaten zur Behandlung von Fehlern bei der Datenübertragung ist bei einem DSMS und
bei rule engines wesentlich einfacher als innerhalb eines DBMS ([SCZ05]).
Der ausschlieÿliche Einsatz eines klassischen DBMS zur Verwaltung von Stromdaten
wird also in Frage gestellt. Ein Ansatz dieser Art scheinet weniger gut geeignet, den
Anforderungen der Analyse von Datenströmen gerecht zu werden. Dabei wird hinsichtlich der Anwendungsklasse im Kontext des SIMON-Projektes im Gegensatz zu
[CHKS03] nicht das persistente Speichern aller Stromdaten aufgrund der Datenmenge in Frage gestellt. Statt dessen ist ein DBMS aufgrund fehlender Funktionalitäten
wie Historienverwaltung etc. und der fehlenden Möglichkeit, die Ereignisse geeignet zu spezizieren, nicht geeignet. Bei Einsatz eines DSMS ist die Möglichkeit,
52
Kapitel 4.
Überwachung von Datenströmen in SIMON
zusätzliche (Meta-)Daten sowie relevante Teile der Datenströme zu speichern, um
Berechnungen aus Stromdaten und gespeicherten (historischen) Daten zu erlauben,
ist je nach Architektur des DSMS eingeschränkt und bei rule engines nicht möglich.
Damit ist auch die Komplexität der Analyse begrenzt, da nur auf einen sehr kleinen
Teil der Daten der Datenströme zugegrien werden kann Zum Erkennen komplexer Ereignisse werden eine Vielzahl von Operatoren hinsichtlich der kontinuierlichen
Anfragen, sowie groÿe Mengen an historischen Strom- sowie Meta-Daten benötigt.
Aus diesem Grund ist keiner der Ansätze zur Überwachung von Datenströmen hinsichtlich der Anwendungsklasse im Kontext des SIMON-Projektes geeignet.
Im folgenden Abschnitt wird ein DB-gestützter Ansatz zur Analyse von Datenströmen thematisiert. Da zur Analyse groÿe Mengen an historischen Strom- und MetaDaten zur Verfügung stehen müssen, liegt die Verwendung eines DBMS nahe. Es
werden zusätzlich Konzepte eines DSMS, wie z.B. die Vorverarbeitung der Stromdaten, verwendet. Dabei werden die Daten, im Gegensatz zum gängigen Ansatz bei
einem DSMS ([SCZ05]) nicht nach der Analyse im Hinblick auf Anfragen über historischen Daten archiviert, sondern vorverarbeitet sowie zwischengespeichert und erst
danach analysiert.
Abbildung 4.9: DB-gestützter DSMS-Ansatz
Dieser Ansatz basiert auf einem DBMS sowie einigen zusätzlichen Komponenten
und ist in Abbildung 4.9 beschrieben. Die zusätzlichen Komponenten bieten Funktionalitäten hinsichtlich der Verarbeitung und Speicherung der Stromdaten, der Verwaltung von kontinuierlichen Anfragen sowie der Verarbeitung der Ergebnisse der
Analyse bzw. Antworten (z.B. Meldungen ausgeben oder Reaktionen auslösen). Die
Analyse selbst wird mit generischen Methoden innerhalb des DBMS durchgeführt.
Die Analyse ndet regelbasiert statt, um komplexe Ereignisse spezizieren und automatisch durch eine entsprechende Deduktionskomponente erkennen zu können.
Der anwendungsspezische Anteil liegt dabei modular in Form von Regeln in der
4.3
Ein Ansatz zur DBMS-gestützten Analyse von Datenströmen
53
Datenbank vor, die jeweiligen technischen Methoden sind anwendungsunabhängiger Bestandteil des DBMS. Mit Techniken der Änderungspropagierung sollen die
Analyseergebnisse ezient berechnet werden.
4.3
Ein Ansatz zur DBMS-gestützten Analyse von
Datenströmen
In Abschnitt 4.2.4 wurden verschiedenen Ansätze für Systeme zur Analyse von Datenströmen im Kontext der im SIMON-Projekt betrachteten Anwendungsklasse (vgl.
Abschnitt 4.1.2) verglichen. Es wurde ein Ansatz zur datenbankgestützten Überwachung von Datenströmen motiviert. Dabei handelt es sich um ein Datenstrommanagementsystem, welches spezisch an die Anforderungen SIMON-Anwendungsklasse
angepasst ist. Dieser Ansatz wird im folgenden vorgestellt und diskutiert.
Abschnitt 4.3.1 erläutert die prinzipielle Vorgehensweise der Analyse sowie den Zusammenhang zwischen dem Monitoring (vgl. Abschnitt 3.2.1) und der Modellierung
der Überwachung im Kontext des DB-gestützten Ansatzes. Dabei wird die Verwendung von Konzepten der deduktiven Datenbanken zur Analyse der Datenströme
motiviert. Abschnitt 4.3.2 stellt die Architektur des Systems vor. Abschnitt 4.3.3
beschreibt die Methode zur inkrementellen Beantwortung kontinuierlicher Anfragen.
4.3.1 Prinzipielle Vorgehensweise
Im Kontext von Monitoring-Anwendungen werden Datenströme überwacht (vgl. Abschnitt 3.2.1). Anhand der Daten der Datenströme sollen benutzerdenierte Ereignisse erkannt werden. Ein primitives Ereignis ist ein Ereignis, welches direkt aus den
Daten des Datenstroms erkannt werden kann. Ein solches primitives Ereignis ist z.B.
das Auftreten eines Objekts an einem bestimmten Sensor (vgl. Abschnitt 3.2.1). Für
das Erkennen komplexer Ereignisse, die sich aus Kombinationen primitiver Ereignisse und/oder weiteren komplexen Ereignissen ergeben, ist eine weitreichendere
Analyse der Datenströme nötig. Die Ereignisse lassen sich mit Hilfe von Anfragen
spezizieren (vgl. Abschnitt 3.2.3). Dabei entspricht das Eintreten eines Ereignisses dem Auftreten eines entsprechenden Tupels in der Antwort der dem Ereignis
zugehörigen Anfrage.
In einem aktiven DBMS lassen sich mit Hilfe einer Regelsprache aktive Regeln
(Trigger) spezizieren. Die Syntax dieser Regelsprachen basiert auf dem allgemeinen
ECA-Spezikationsparadigma. Die aktiven Regeln haben folgende Form:
ON E(vent) IF C(ondition) DO A(ction)
54
Kapitel 4.
Überwachung von Datenströmen in SIMON
Der Ereignisteil (E-Teil) speziziert auslösende Ereignisse, der Bedingungsteil (CTeil) stellt eine Aktivierungsbedingung dar, die zum Auslösen des Aktionsteils erfüllt
sein muss, und der Aktionsteil (A-Teil) speziziert auszulösende Reaktionen.
Primitive Ereignisse lassen sich z.B. mit Hilfe von Triggern erkennen, indem das
entsprechende Ereignis im Ereignis- sowie Bedingungs-Teil des Triggers speziziert
wird. Der Aktions-Teil speziziert die zu erfolgende Reaktion des Systems auf das
Erkennen des Ereignisses. Theoretisch ist auf diese Weise auch unter ausschlieÿliche
Verwendung von Triggern ein Erkennen komplexer Ereignisse möglich. Dabei muss
ebenso im Ereignis- sowie Bedingungs-Teil des Triggers das entsprechende komplexe
Ereignis speziziert werden, auf das das System reagieren soll.
Gängige Datenbankmanagementsysteme wie Oracle oder DB2 sowie auch der SQLStandard 1999 [XXXX] sehen ausschlieÿlich DB-Ereignisse wie DML-Kommandos
im Ereignis-Teil eines Triggers vor ([Pat98], [WC96]). Diese DML-Kommandos
(INSERT-, UPDATE- und DELETE-Statements) sind nur auf Tabellen und nicht
auf Sichten verwendbar. Das DBMS PostgreSQL ([PDoc]) lässt DML-Kommandos
hinsichtlich Views im Ereignis-Teil eines Triggers (TRIGGER bzw. RULE) zu. Jedoch werden die Trigger nur ausgelöst, wenn das Statement auf der Sicht selbst
ausgeführt wird und nicht, wenn sich durch zugrundeliegende Daten Änderungen
hinsichtlich der Tupel der Sicht ergeben. Komplexes reaktives Verhalten mit Hilfe
existierender aktiver Regelsprachen ist nur schwer zu spezizieren ([SKdM92]). Zudem ist eine solche Vorgehensweise unpraktikabel. Komplexe Ereignisse bestehen aus
Kombinationen von primitiven und/oder komplexen Ereignissen. Zur Spezikation
komplexer Ereignisse wäre eine Vielzahl an Triggern nötig, um jede entsprechende
Ereignis-Kombination abzudecken.
Statt dessen ist das Verwenden deduktiver Regeln zum Spezizieren der Ereignisse
vorzuziehen. Dabei erfolgt die Spezikation komplexer Ereignisse durch Sichten. Die
Abhängigkeiten zwischen den verschiedenen primitiven Ereignissen und Zwischenergebnissen der Analyse können so regelbasiert innerhalb einer Hierarchie von Sichten
zum Ausdruck gebracht werden. Abbildung 4.10 zeigt beispielhaft die Abhängigkeiten innerhalb einer Sichtenhierarchie. Die Sichten der oberen Hierarchieebene sind
die Antwortmengen der Anfragen, die über den Stromdaten ausgewertet werden sollen (vgl. Abschnitt 3.2.3). Wird ein Tupel in eine dieser Sichten eingefügt, wird dies
als Eintritt des entsprechenden Ereignisses interpretiert. Die Tupel, die in der Antwort der einem Ereignis zugehörigen Anfrage auftreten, entsprechen also hier den
Tupeln in der jeweiligen Sicht und stellen die eingetretenen Ereignisse dar.
Die Verarbeitung der Stromdaten erfolgt in Anlehnung an die in Abschnitt 3.2.2
beschriebene Fensterung bzw. Blockbildung. Es wird dabei eine zeitlich zusammengehörige Menge von Tupeln zu einer Transaktion zusammengefasst und in der Datenbank gespeichert. Der Begri Transaktion ist in diesem Zusammenhang nicht
mit dem Transaktionsbegri aus SQL gleichzusetzen. Im Kontext von SQL bedeutet
eine Transaktion die Anwendung des ACID-Paradigmas
1 Atomarity,
Consistency, Integrity, Durability
1
auf eine zusammengefass-
4.3
Ein Ansatz zur DBMS-gestützten Analyse von Datenströmen
55
Abbildung 4.10: Sichtenhierarchie
te Menge von Datenbankoperationen. Hier bedeutet eine Transaktion die Zusammenfassung einer Menge von Daten eines Datenstroms, die zu einem bestimmten
Zeitpunkt gleichzeitig an das DBMS weitergeleitet wird.
4.3.2 Architektur
Der Ansatz zur datenbankgestützten Überwachung von Datenströmen ist spezisch
an die Anwendungsklasse im Kontext des SIMON-Projektes angepasst ist. Die Architektur dieses Ansatzes ist in Abbildung 4.11 aufgezeigt.
Der DSMS-Ansatz basiert auf einem DBMS sowie einigen zusätzlichen Komponenten. Dazu zählt eine Komponente zur Verarbeitung und Speicherung der Stromdaten
(Input-Manager), ein Tool zur Spezialisierung von SQL-Sichten (Compiler) sowie eine Komponente zur Verwaltung von kontinuierlichen Anfragen (CQ-Manager).
Die Daten der Datenströme werden vom Input-Manager vorverarbeitet. Dazu zählt
ein anwendungsabhängiges Filtern sowie die Zusammenfassung zu Transaktionen.
Die Daten (Tupel) werden synchronisiert, sodass jeweils alle Daten einer Transaktion einen identischen Zeitstempel besitzen. Die Transaktionen werden in der Datenbank in entsprechenden Relationen (Stromrelationen) gespeichert. Diese werden
kontinuierlich gefüllt.
Mit Hilfe des CQ-Managers können kontinuierliche Anfragen speziziert werden,
die als Sichten in der Datenbank gespeichert werden und deren Ergebnis virtuell
oder materialisiert verwaltet wird. Die zur Verfügung stehenden Basisdaten sind die
56
Kapitel 4.
Überwachung von Datenströmen in SIMON
Abbildung 4.11: Architektur
Stromdaten sowie weitere Metadaten. Auf diesen Daten basierend wird eine Hierarchie von Sichten erstellt, dessen oberste Ebene die den kontinuierlichen Anfragen
entsprechenden Sichten bilden. Weitere Sichten stellen Zwischenergebnisse dar.
Zur ezienten Berechnung der zu überwachenden Sichten werden Konzepte der deduktiven Datenbanken (vgl. Abschnitt 2.1) angewendet. Zu jeder Sicht und jeder
Basistabelle werden Delta- und Transitionssichten benötigt. Die Generierung erfolgt
durch einen Compiler, der die Tabellen- bzw. Sichtdenitionen analysiert und anschlieÿend die entsprechenden Sichten erstellt.
Wird eine neue Transaktion ausgeführt, ergeben sich aus den in die Stromtabellen eingefügten Tupeln (induzierte) Änderungen hinsichtlich der zu überwachenden
Sichten der oberen Hierarchieebene. Zur Berechnung dieser Sichten, welche im folgenden Abschnitt vorgestellt wird, werden generische Konzepte des DBMS verwendet.
4.3.3 Inkrementelle Beantwortung kontinuierlicher Anfragen
In Form von individuell zugreifbaren Regeln werden Monitorbedingungen und nichtfaktisches Domänenwissen in der Datenbank abgelegt. Deduktive Regeln (Sichten)
spezizieren dabei die zu überwachenden Bedingungen. Die entsprechend darauf
auszulösenden Reaktionen sind z.B. durch aktive Regeln (Trigger) im System hinterlegt. Die Stromdaten, die fortlaufend in die Stromrelationen eingefügt werden,
4.3
Ein Ansatz zur DBMS-gestützten Analyse von Datenströmen
57
sollen anhand der Überwachungskriterien, die zusätzlich auf weiteren Metadaten
basieren können, kontinuierlich analysiert werden. Das Prinzip der Analyse wird in
Abbildung 4.12 verdeutlicht.
Abbildung 4.12: Regelbasierter Monitoring-Ansatz
Die Überwachung der Stromdaten besteht in der kontinuierlichen Beantwortung
identischer Anfragen über sich ständig verändernden Daten. Das bedeutet, dass der
Inhalt der Sichten, die die gespeicherten Antwortmengen darstellen, kontinuierlich
berechnet werden muss. Eine naive Auswertung der Sichten in Form einer vollständigen Neuberechnung ist nicht sinnvoll [XXXXX]. Statt dessen sollen anhand der Methode der Änderungspropagierung aus dem Datalog-Kontext (vgl. Abschnitt 2.1.4)
jeweils nur die Änderungen hinsichtlich der Sichten bei Änderung der Basisdaten
berechnet werden.
Ein Compiler erstellt dazu anhand der Sichtdenitionen die Delta-Sichten (DeltaPlus für Einfügungen, Delta-Minus für Löschungen). Ebenso werden für die Basistabellen, auf denen die Sichten basieren (sowohl für die Tabellen, in denen die Stromdaten gespeichert werden, als auch für die Tabellen mit Meta-Daten), entsprechende
Delta-Tabellen generiert. Änderungen hinsichtlich der Basisdaten werden nicht mehr
auf den Tabellen selbst, sondern auf den Delta-Tabellen ausgeführt. Soll z.B. ein Tupel in eine Stromtabelle eingefügt werden, wird es in die entsprechende Delta-PlusTabelle eingefügt. Die darauf aufbauenden Delta-Sichten enthalten die induzierten
Änderungen, die sich aus den Änderungen der Basisdaten ergeben. Sobald sich also
58
Kapitel 4.
Überwachung von Datenströmen in SIMON
die Basisdaten verändern, werden durch Berechnung der den Ereignissen zugehörigen Delta-Sichten neue Antworttupel erkannt. Abbildung 4.13 zeigt beispielhaft die
Abhängigkeiten innerhalb einer Sichtenhierarchie. Die untere Ebene besteht aus den
Stromtabellen, Metadatentabellen sowie den zugehörigen Delta-Tabellen. Die obere
Ebene bilden die Sichten mit den zugehörigen Delta-Sichten, die kontinuierlich überwacht werden sollen. Dazwischen benden sich weitere Sichten und Delta-Sichten
innerhalb der Hierarchie.
Abbildung 4.13: Sichtenhierarchie mit Delta-Tabellen und Delta-Sichten
Die Analyse erfolgt schrittweise. Ein Analyse-Schritt läuft wie folgt ab. Sobald eine
neue Transaktion an Stromdaten vorliegt, wird diese in die entsprechende DeltaPlus-Stromtabelle gespeichert. Daraufhin werden die Delta-Sichten der Sichten der
oberen Hierarchieebene, die die zu überwachenden Sichten darstellen, berechnet. Die
Tupel in diesen Delta-Sichten sind die neuen Antworttupel hinsichtlich der entsprechenden kontinuierlichen Anfrage dar, welches im Kontext des betrachteten Szenarios meist neu eingetretene Ereignisse sind. Als Ergebnis können z.B. die Tupel selbst
weitergegeben werden oder eine Reaktion des Systems ausgelöst werden. Nachdem
die Delta-Sichten berechnet und die Ergebnisse verarbeitet wurden, werden zum Ende des Analyse-Schrittes die Daten in den zugrundeliegenden Delta-Tabellen in die
zugehörigen Tabellen integriert und alle Delta-Sichten geleert.
Sind nur die Änderungen hinsichtlich der Sichten von Interesse, müssen nur die
Ergebnisse aus der Berechnung der Delta-Sichten weiterverwendet werden. In diesem
Fall können die Sichten selbst virtuell verwaltet werden, da auf diese selbst nicht
mehr zugegrien wird. Im anderen Fall, wenn auf die Ergebnisse in den Sichten später
noch zugegrien werden soll bzw. die Sichten zur Berechnung der Delta-Sichten
einer höheren Ebene benötigt werden, ist es sinnvoll, diese zu materialisieren, um
4.3
Ein Ansatz zur DBMS-gestützten Analyse von Datenströmen
59
auch an dieser Stelle eine naive Neuberechnung zu vermeiden. Am Ende eines jeden
Analyse-Schrittes müssen die Tupel der Delta-Sichten, bevor diese geleert werden,
in die entsprechenden Sichten eingefügt bzw. aus diesen entfernt werden.
Die materialisierten Sichten werden in Form von Tabellen innerhalb des DBMS verwaltet. Dabei können generische Methoden des DBMS, wie etwa das Materialisieren
und das Leeren der Tabellen, verwendet werden. Manche Datenbankmanagementsysteme (z.B. XXXXX) unterstützen bereits direkt die Verwendung von materialisierten Sichten. Eine Verwendung dessen ist nicht jedoch nicht sinnvoll, sofern eine
automatische Anpassung der materialisierten Sichten durchgeführt wird. Diese ist
nicht gewünscht, da speziell die Änderungen hinsichtlich der Sichten von Interesse
sind. Zusätzlich sind in vorhandenen Systemen keine inkrementellen Methoden zur
ezienten Anpassung materialisierter Sichten integriert (!!! XXXX noch überprüfen
bzw. belegen.....!!!).
Abbildung 4.14: top-down Berechnung
Die Berechnung der Delta-Sichten der oberen Hierarchieebene selbst kann auf unterschiedliche Art und Weise vorgenommen werden. Bei der top-down -Berechnung wird
ein pull-basierter Ansatz verfolgt. In Abbildung 4.14 ist dieser Ansatz dargestellt.
Sobald vom Input-Manager eine neue Transaktion von Stromdaten in den Stromrelationen (genauer gesagt in den entsprechenden Delta-Plus-Tabellen) gespeichert
wurden, wird durch die CQ-Manager die Berechnung der CQs veranlasst. Dabei
werden die Delta-Sichten angefangen bei der oberen Hierarchieebene neu berechnet.
Anhand der Abhängigkeiten innerhalb der Hierarchie werden so von oben nach
unten alle Delta-Sichten sukzessive neu berechnet, bis die Ebene der Delta-Tabellen
erreicht ist.
Die bottom-up -Berechnung basiert auf einem push-basierten Ansatz. Abbildung
60
Kapitel 4.
Überwachung von Datenströmen in SIMON
4.15 beschreibt diesen Ansatz. Dabei werden, ausgehend von der untersten Ebene
der Delta-Tabellen, die Änderungen sukzessive an die abhängigen Delta-Sichten
der jeweils nächsten höheren Ebene propagiert. Die Berechnung der Delta-Sichten
erfolgt also datengetrieben von unten nach oben.
Abbildung 4.15: bottom-up Berechnung
Die Delta-Sichten werden bei jedem Analyse-Schritt neu berechnet. Aufgrund der
Abhängigkeiten innerhalb der Sichtenhierarchie kann es vorkommen, dass auf die
Delta-Sichten, die sich zwischen den Basistabellen und den zu überwachenden Sichten der oberen Hierarchieebene benden (diese stellen sozus. Zwischenergebnisse
dar), mehrfach zugegrien wird. Dies ist sowohl bei der top-down - als auch bei der
bottom-up -Berechnung der Fall (vgl. Abbildungen 4.14 und 4.15). Aus diesem Grund
sollten die Delta-Sichten in materialisierter Form vorliegen. So kann gewährleistet
werden, dass diese nicht innerhalb eines Analyse-Schrittes wiederholt neu berechnet
werden. Ein geeigneter Mechanismus muss dafür sorgen, dass die Delta-Sichten
in der richtigen Reihenfolge die Abhängigkeiten respektierend jeweils nur ein
mal neu materialisiert werden. Zusätzlich kann man sich beim top-down -Ansatz
vorstellen, dass der CQ-Manager durch den Input-Manager Informationen über die
von der Transaktion betroenen Stromrelationen erhält. Dann ist ebenfalls eine
datengetriebene Berechnung möglich, da anhand der Abhängigkeiten innerhalb
der Sichtenhierarchie festgestellt werden kann, welche CQs von den Änderungen
betroen sein können und nur die zu diesen CQs zugehörigen Delta-Sichten neu
berechnet werden müssen.
Von der jeweiligen Anwendung hängt ab, ob eine push- oder eine pull-basierte
4.3
Ein Ansatz zur DBMS-gestützten Analyse von Datenströmen
61
Berechnung der Analyseergebnisse vorteilhaft ist. Sollen die zu überwachenden
Bedingungen nur selten bzw. in einem groÿen zeitlichen Abstand abgefragt werden,
ist die pull-Variante vorzuziehen. Dort werden die zu überwachenden Delta-Sichten
von einer Komponente auÿerhalb abgefragt. Dies kann z.B. ein zeitlich gesteuerter
Trigger oder eine Erweiterungskomponente (CQ-Manager) sein. Die push-Variante
bietet Vorteile bei zeitkritischen Anwendungen, da die Berechnung direkt nach dem
Eintreen neuer Basisdaten durchgeführt wird. Entsprechende Reaktionen auf neue
Ergebnisse der Analyse können z.B. von der Komponente, die die Delta-Sichten
der oberen Hierarchieebene materialisiert, ausgelöst werden. Auch ist ein Trigger
auf der Sicht vorstellbar, in die zum Ende eines Analyseschrittes die Tupel der
Delta-Sichten integriert werden.
Die Analyse wird mit Hilfe generischer Methoden eines DBMS durchgeführt. Durch
die Techniken der Änderungspropagierung wird ein ezientes Auswerten der Monitorbedingungen gewährleistet. Ein weiterer Vorteil des Einsatzes von Datenbanken
liegt in der Tatsache, dass im Gegensatz zu üblicherweise speziell für das jeweilige Anwendungsszenario programmierten Monitoring-Anwendungen eine modulare
Darstellung des anwendungsspezischen Anteils eines solchen Systems möglich ist
([MS04]), da dieser in Form von Regeln in der Datenbank vorliegt. Sowohl hinsichtlich der Ezienz, als auch hinsichtlich der Erweiterbarkeit und Wiederverwendbarkeit ist die Architektur eines solchen Systems von Vorteil, da die Regeln modular aufgebaut sind und die Verwaltung von anwendungsunabhängigen Diensten des
DBMS durchgeführt wird.
Der Nachteil eines Systems mit diesem Ansatz liegt darin, dass es speziell auf eine
bestimmte Anwendungsklasse (vgl. Abschnitt 4.1.2) zugeschnitten ist. Sobald sich
Parameter hinsichtlich der Anwendung ändern, ist die Eignung eines solchen Systems
nicht mehr garantiert. Ändert sich z.B. der Umfang der Datenströme derart, dass
Transaktionen von wesentlich gröÿerem Umfang oder mit einer wesentlich geringeren
Frequenz in den Stromtabellen gespeichert werden, können die zu überwachenden
Sichten nicht mehr in angemessener Zeit berechnet werden.
Kapitel 5
Spezialisierung von SQL-Sichten
In Abschnitt 3.7 wurde der in [Ber05] entwickelte Compiler für SQL-Sichten vorgestellt. Er erstellt in Anlehnung an die in 2.1.4 vorgestellte Methode zur Änderungspropagierung SQL-Sichten, die eine inkrementelle Propagierung von Änderungen in
einem SQL-System möglich machen. Der Compiler wird zu einem Bestandteil der
Analysekomponente des SIMON-Systems weiterentwickelt. In diesem Zusammenhang sind einige Verbesserungen und Erweiterungen vorzunehmen. Diese werden
in Abschnitt 5.1 motiviert. Insbesondere wird dabei auf Erweiterungen hinsichtlich
der Erstellung der Delta- und Transitionssichten und der Behandlung von Aggregatfunktionen eingegangen. In 5.2 wird grundsätzlich die Verwendung von Mengenbzw. Multimengensemantik diskutiert. Die Erweiterungen des Compilers werden im
Kontext einer Mengensemantik in Abschnitt 5.3 vorgenommen. In 5.4 wird ein alternativer Ansatz unter Verwendung einer Multimengensemantik aufgezeigt. Die
Monitoring-Komponente, in die der Compiler integriert wird, wird später in Abschnitt 6.3 entworfen.
5.1
Motivation
In [Ber05] wird beschrieben, dass der Sichtencompiler nicht korrekt mit Duplikaten
in den Delta-Tabellen umgehen kann. Beim Erstellen der Delta-Sichten werden Methoden und Ergebnisse aus dem Datalog-Kontext verwendet, die auf einer Mengensemantik beruhen. Bei den in SQL erstellten Delta-Sichten wird von einer Multimengensemantik ausgegangen (vgl. Abschnitt 3.7.2). Die einzelnen SELECT-Blöcke sind
durch den Operator UNION ALL verknüpft. Bei den Delta2-Sichten, werden durch
die Implementierung des Eektivitätstests Duplikate entfernt, d.h. dort wird eine
Mengensemantik verwendet. Beim generieren der Delta-Sichten durch den Compiler
ndet also eine inkonsequente Verwendung von Mengen- bzw. Multimengensemantik
62
5.2
Mengen- vs. Multimengensemantik
63
statt. Aus diesem Grund sollten Duplikate bei der Änderungspropagierung entweder
korrekt behandelt oder generell ausgeschlossen werden.
Der Algorithmus aus [Ber05] bzw. der Code-Generator (Schritt 3) arbeiten nicht
korrekt. In [Ber05] wir die Notwendigkeit eines Eektivitätstests begründet, ohne
den falsche Tupel in den Delta-Relationen auftreten könnten. Der Eektivitätstest
wird in den jeweils zu den Delta-Sichten korrespondierenden Delta2-Sichten (siehe
Schritt 4) implementiert. In einer Hierarchie aufeinander aufbauender Sichten führt
dies zu Problemen. Der Algorithmus erstellt die Delta-Sichten einer höheren Schicht
so, dass kein Bezug auf die Delta2-Sichten der unteren Schichten genommen wird.
Es werden lediglich die Delta-Sichten referenziert, in denen aufgrund des fehlenden
Eektivitätstests falsche Tupel enthalten sein können. Bei voneinander abhängigen
Sichten werden also jeweils die Delta-Sichten verwendet, innerhalb derer der Eektivitätstest nicht durchgeführt wird. Die Erstellung der Delta-Sichten muss in der
weise angepasst werden, dass eine Durchführung des Eektivitätstests immer gewährleistet ist. Nur diese Sichten mit Eektivitätstest dürfen referenziert werden.
Aufgrund der inkorrekten Behandlung von Duplikaten ist auch die Korrektheit der
Auswertung der Aggregatfunktionen (Schritt 4) nicht garantiert.
Zudem wird vorausgesetzt, dass die Einträge in den Delta-Tabellen echte Änderungen darstellen. Dies müsste also die Programmkomponente gewährleisten, die die
Eintragungen vornimmt. Um ein in sich geschlossenes System zu erhalten, sollte die
Überprüfung auf echte Änderungen auch durch die erstellten Sichten erfolgen.
Zusätzlich muss eine Anpassung in Hinblick auf die Monitoring-Anfragen aus dem
Beispielszenario (vgl. Abschnitt 3.8) vorgenommen werden. An einigen Stellen muss
Access-spezische JET-SQL Syntax (vgl. Abschnitt 2.2.1) abgefangen und korrekt
interpretiert werden.
5.2
Mengen- vs. Multimengensemantik
Grundsätzlich stellt sich die Frage ob der Änderungspropagierung eine Multimengensemantik oder eine Mengensemantik zugrundeliegen soll. Da in SQL-basierten
Systemen die Relationen Multimengen darstellen, liegt der Ansatz nahe, die Verwendung von Multimengen beizubehalten, um einen gröÿeren Funktionsumfang zu
gewährleisten. SQL-Systeme verwalten die Duplikate in den Tabellen explizit ja gerade explizit. So wären alle denkbaren Szenarien abgedeckt.
Probleme treten allerdings auf, wenn man den Ansatz der Änderungspropagierung
aus Datalog (Mengensemantik) auf eine Multimengensemantik in SQL übertragen
will (insbes. hinsichtlich Eektivitätstest usw.). Die Umsetzung ist sehr viel aufwändiger und nicht trivial.
Die Daten von Datenströmen besitzen i.a. ein Timestamp-Attribut (vgl. Abschnitt
3.2.2). Es können also keine Duplikate in den Stream-Tabellen auftreten. Im Kontext
64
Kapitel 5.
Spezialisierung von SQL-Sichten
der Überwachung von Datenströmen entsprechen die Tupel in den zu überwachenden
Sichten der höchsten Sichtenebene komplexen Ereignissen, die zu einem bestimmten
Zeitpunkt eingetreten sind (Zeitstempel). Die beobachteten Objekte sind wohlunterschieden und haben in der Regel eine eindeutige ID. Da die Ereignisse immer
mit einem bestimmten Objekt zusammenhängen, ergibt sich somit eine Eindeutigkeit der jeweiligen Datensätze in den Sichten (Schlüssel). Diese Schlüssel werden in
allen Delta-Relationen beibehalten, da immer ein bezug auf das Objekt und den
Zeitpunkt vorhanden sein muss, um ein sinnvolles Analyseresultat zu erhalten. Die
Zeitstempel der Basisdaten sollten also beibehalten werden, damit keinen Informationsverlust auftritt.
Im Falle von Verkehrs- oder Börsenszenarien ist diese Eindeutigkeit der Datensätze immer gegeben. Die mobilen Objekte bzw. die Aktien können eindeutig identiziert werden. Entsprechende weitere Daten bzw. Ereignisse (Auftreten eines Objekts,
Kurs,...) haben immer einen Bezug zu einem bestimmten Zeitpunkt.
Bei Mengensemantik sind Duplikate in Tabellen und Sichten theoretisch zugelassen,
da die Relationen in SQL Duplikate aufweisen können. Diese treten aber bei den
betrachteten Szenarien nicht in der Praxis auf. In den Delta- und Transitionssichten
benden sich per Konstruktion keine Duplikate.
Im folgenden Abschnitt 5.3 wird eine Mengensemantik zugrundegelegt. Ein Ansatz
bzw. Entwurf einer Komonente für Änderungspropagierung mit Duplikaten wird in
Abschnit 5.4 vorgestellt und es werden die Probleme beim Übertragen der Ergebnisse
aus dem Datalog-Kontext aufgeführt.
5.3
Ansatz mit Mengensemantik
In Abschnitt 5.1 wurden einige Probleme und Verbesserungsmöglichkeiten hinsichtlich des Compilers bei der Generierung der Delta- und Transitionssichten aufgezeigt.
Im Kontext einer Mengensemantik wird im folgenden ein Lösungsvorschlag erarbeitet. In Abschnitt 5.3.1 wird auf die Generierung der Delta- und Transitionssichten
eingegangen. Abschnitt 5.3.2 beschäftigt sich speziell mit der Behandlung von Aggregatfunktionen.
Die Algorithmen aus [Ber05] zum Generieren der Delta-Sichten in SQL müssen entsprechend der Ergebnisse aus den Abschnitten 5.3.1 und 5.3.2 angepasst werden
(vgl. Abschnitt 6.3.3).
5.3.1 Delta- und Transitionssichten
Die Generierung der Delta- und Transitionssichten (vgl. Abschnitt 3.7.2) muss aufgrund der in Abschnitt 5.1 beschriebenen Probleme angepasst werden. Zu jeder
5.3
Ansatz mit Mengensemantik
65
Delta-Tabelle sowie zu jeder Delta-Sicht muss eine entsprechende Delta-Sicht mit
Implementierung des Eektivitätstests erstellt werden. Nur auf diese Sicht darf sich
im Falle von Abhängigkeiten bezogen werden.
Für ein ezientes Vorgehen könnte beim Erstellen der Sichten anstatt des UNIONALL der UNION-Operator verwendet werden. Semantisch ist es irrelevant, ob UNION oder UNION ALL verwendet wird, da durch den Eektivitätstest Duplikate
sowieso eliminiert werden.
Abbildung 5.1: Compilers: Vorgehensweise
Es ist eine zweistuge Erstellung der Delta-Sichten notwendig. Die Delta-Tabellen
und Delta-Sichten können prinzipiell nach dem Algorithmus aus [Ber05] wie in Abschnitt 3.7 beschrieben erstellt werden. Diese stellen zuerst aber nur die Tabellen,
in die die Delta-Tupel eingetragen werden bzw. Hilfssichten dar. Die Delta-Tabellen
werden mit _Tabelle benannt, bei den Sichten wird das Postx _hlp angehängt.
Auf diese Tabellen bzw. Sichten aufbauend werden im zweiten Schritt die eigentlichen Delta-Tabellen erstellt, die den Eektivitätstest implementieren. Erst diese
enthalten die für die Delta-Sichten gewünschten Tupel. Abbildung 5.1 zeigt die Änderungen hinsichtlich der Generierung der Delta-Sichten. Die Generierung der Transitionssichten aus [Ber05] wird beibehalten. Das Beispiel 5.1 zeigt die Generierung
der Delta- und Transitionssichten.
Aufgrund der Beziehungen zwischen den Delta-Plus und Delta-Minus-Sichten innerhalb des Eektivitätstests muss die zweistuge Generierung beibehalten werden.
66
Beispiel 5.1
Kapitel 5.
Spezialisierung von SQL-Sichten
S:
SELECT Tabelle1.Feld1, Tabelle1.Feld2
FROM Tabelle1;
S_minus_hlp:
SELECT Tabelle1_minus.Feld1 AS Feld1, Tabelle1_minus.Feld2 AS Feld2
FROM Tabelle1_minus;
S_minus:
SELECT DISTINCT S_minus_hlp.Feld1, S_minus_hlp.Feld2
FROM S_minus_hlp
WHERE NOT EXISTS
( SELECT * FROM S_new WHERE
IIF(isNull(S_new.Feld1),
IIF(isNull(S_minus_hlp.Feld1),true,false),
IIF(isNull(S_minus_hlp.Feld1),false,S_new.Feld1 = S_minus_hlp.Feld1))
AND IIF(isNull(S_new.Feld2),
IIF(isNull(S_minus_hlp.Feld2),true,false),
IIF(isNull(S_minus_hlp.Feld2),false,S_new.Feld2 = S_minus_hlp.Feld2)));
S_plus_hlp:
SELECT Tabelle1_plus.Feld1 AS Feld1, Tabelle1_plus.Feld2 AS Feld2
FROM Tabelle1_plus;
S_plus:
SELECT DISTINCT S_plus_hlp.Feld1, S_plus_hlp.Feld2
FROM S_plus_hlp
WHERE NOT EXISTS
( SELECT * FROM S WHERE
IIF(isNull(S.Feld1),
IIF(isNull(S_plus_hlp.Feld1),true,false),
IIF(isNull(S_plus_hlp.Feld1),false,S.Feld1 = S_plus_hlp.Feld1))
AND IIF(isNull(S.Feld2),
IIF(isNull(S_plus_hlp.Feld2),true,false),
IIF(isNull(S_plus_hlp.Feld2),false,S.Feld2 = S_plus_hlp.Feld2)));
S_new:
SELECT Tabelle1_new.Feld1 AS Feld1, Tabelle1_new.Feld2 AS Feld2
FROM Tabelle1_new;
5.3.2 Aggregation
Es werden wie in [Ber05] die ANSI-Standard SQL-Aggregatfunktionen Min, Max,
Count, Sum und Avg behandelt, die im Select-Teil einer Sicht auftreten. Im Gegensatz zu [Ber05] muss bei der Verwendung der Aggregatfunktionen zwingend ein
5.3
Ansatz mit Mengensemantik
67
correlation name (AS) angegeben werden. Dies gewährleistet, dass für die Sicht,
die die Aggregatfunktion beinhaltet, Delta-Sichten gleicher Struktur generiert werden können. Dies ist innerhalb einer Hierarchie von Sichten notwendig, da für den
Fall, dass kein correlation name angegeben wurde, Access automatisch generierte
correlation names verwendet. Diese sind jedoch den Sichten einer höheren Hierarchieebene nicht bekannt, da diese automatisch generierten correlation names nicht
in der Sichtdenition der zu kompilierenden Sicht deniert sind.
Unteranfragen mit Aggregatfunktionen werden nicht behandelt, da der Parser aus
[Ber05] Ausdrücke solcher syntaktischer Komplexität nicht erkennen und gesondert
behandeln kann. Statt dessen sollten die Unteranfragen, die Aggregatfunktionen
beinhalten, als separate Sichten deniert werden, auf diese dann innerhalb einer
Unteranfrage zugegrien werden kann.
Access lässt im SELECT-Teil einer Abfrage keine gemeinsame Verwendung von aggregierten und nicht aggregierten Attributen zu. Daher wird davon ausgegangen,
dass die zu kompilierende Sicht nur Aggregatfunktionen im SELECT-Teil enthält:
Syntax:
SELECT <Aggregatfunktion> AS <name>
FROM ...
WHERE ...
In [Ber05] werden Sichten mit Aggregatfunktionen folgendermaÿen behandelt:
Für die zu kompilierende Sicht werden jeweils die entsprechenden Delta-Tabellen
(Delta_plus und Delta_minus) nach dem Algorithmus für gewöhnliche Sichten
erstellt. Diese enthalten die Tupel, die sich ergeben, wenn die Aggregatfunktion
auf
die
jeweils
zugrundeliegenden
Delta-Sichten
angewendet
werden.
Darauf
aufbauend werden für die Aggregatfunktionen MIN und MAX Delta2-Sichten
(Delta2_plus und Delta2_minus) erstellt, die die Aggregatfunktionen wiederholt
auf die Delta-Sichten anwenden. Im Falle von AVG, SUM oder COUNT wird nur
eine Delta2-Sicht erstellt, die den neuen Wert der Aggregatfunktion aus dem alten
sowie den Werten aus den Delta-Tabellen berechnet.
Diese Vorgehensweise wird im folgenden abgeändert. Die Delta-Sichten hinsichtlich Sichten mit Aggregatfunktionen enthalten in [Ber05] falsche Tupel. Die DeltaSichten hinsichtlich einer Sicht
new
chung genügen: S
= (S old −
S müssen die Tupel enthalten, die folgender GleiS Delta_minus ) ∪ S Delta_plus . Dies ist bei [Ber05] of-
fensichtlich nach Konstruktion der Delta-Sichten nicht der Fall. Zusätzlich ist eine
spezialisierte Sicht wie in [Ber05] zur Berechnung des neuen Wertes bei den Aggregatfunktionen COUNT, SUM und AVG nicht nötig, da durch die erstellten Transitionssichten der neue Zustand zugreifbar ist (naiv). Auÿerdem sollen die Delta-Sichten
bei der Generierung das Schema der zu kompilierenden Sicht beibehalten, um auch
innerhalb einer Hierarchie von Sichten verwendbar zu sein.
68
Kapitel 5.
Spezialisierung von SQL-Sichten
Zuerst wird nun eine intuitive Vorgehensweise bei der Verbesserung der Methode aus
[Ber05] geprüft. Ähnlich wie bei der Generierung der Delta-Sichten für Sichten ohne
Aggregatfunktionen (vgl. Abschnitt 5.3.1) erfolgt die Generierung der Delta-Sichten
hier in zwei Stufen. In der ersten Stufe werden die Delta-Hilfssichten wie in Abschnitt
5.3.1 erstellt. Aufgrund der Konstruktion der Delta-Hilfssichten als Ausdruck, bei
dem einzelner SELECT-Blöcke mit UNION ALL (wenn die zu kompilierende Sicht
auf mehr als einer Basistabelle aufbaut) verknüpft werden, können in den Hilfssichten
mehrere Werte auftreten (für jeden SELECT-Block eins). Auf diese Hilfssichten wird
deshalb in der zweiter Stufe innerhalb der Delta-Sichten die selbe Aggregatfunktion
noch einmal angewandt, um das korrekte Ergebnis zu erhalten. Dieses Vorgehen
ist ähnlich zu dem in [Ber05]. Entscheidend ist jedoch der unterschiedliche Aufbau
mit Hilfssichten als Zwischenrelationen und darauf aufbauend der Delta-Sichten.
Zusätzlich muss in den Delta-Sichten eine Art von Test stattnden, ob die Einträge
in den Delta-Tabellen den Wert der zu kompilierenden Sicht betreen. So soll in der
Delta_minus-Sicht nur ein Wert auftauchen, wenn genau dieser Wert auch aus der
Sicht entfernt wird. Somit kann der Wert in der Delta_minus-Sicht nur diesen Wert
annehmen. Ebenso soll auch in der Delta_plus-Sicht nur der Wert enthalten sein,
der den neuen Wert der Sicht darstellt. Folgendes Beispiel zeigt die Generierung
einer Delta_minus-Sicht hinsichtlich einer Sicht mit der Aggregatfunktion MAX:
Beispiel 5.2
Sicht: MaximumSicht
SELECT Max(a.ID) AS Maximum
FROM Tabelle1 AS a INNER JOIN Tabelle2 AS b ON a.ID=b.ID;
Delta-hlp-minus: MaximumSicht_minus_hlp
SELECT Max ( a.ID ) AS Maximum
FROM Tabelle1_minus AS a INNER JOIN Tabelle2 AS b ON a.ID = b.ID
UNION SELECT Max ( a.ID ) AS Maximum
FROM Tabelle1 AS a INNER JOIN Tabelle2_minus AS b ON a.ID = b.ID;
Delta-minus: MaximumSicht_minus
SELECT Max ( MaximumSicht_minus_hlp.Maximum) AS Maximum
FROM MaximumSicht_minus_hlp
WHERE MaximumSicht_minus_hlp.Maximum IN
(SELECT Maximum FROM MaximumSicht);
Das Beispiel der Delta_minus-Sicht zeigt, dass ein Vorgehen auf diese Art nicht
zum gewünschten Ziel führt. Die Delta_minus-Sicht enthält im Beispiel nur Tupel,
die sich aus einer Löschung hinsichtlich einer zugrundeliegenden Tabelle ergeben.
Es kann sich jedoch auch durch eine Einfügung auf eine zugrundeliegende Tabelle
der Wert der Aggregatfunktion der Sicht ändern und somit einen Eintrag in der
Delta_minus-Sicht induzieren. Die Werte in den Delta_minus-Sichten hinsichtlich
Sichten mit Aggregatfunktionen ergeben sich also nicht allein aus den zugrundeliegenden Delta_minus-Sichten. Dies gilt ebenso für die Delta_plus-Sichten. Bei
5.4
Alternativer Ansatz mit Multimengensemantik
69
COUNT und AVG führt diese Vorgehensweise zudem zu falschen Ergebnissen, da
diese Aggregatfunktionen bei wiederholter Anwendung andere Ergebnisse liefern.
Es ist somit ein anderer Ansatz nötig. Dabei ist jeweils in den Delta-Sichten ein Vergleich der Werte der Aggregatfunktionen im alten und im neuen Zustand der Sicht
notwendig. Die Delta-Sichten werden also naiv unter Bezug auf die Transitionssicht
erstellt. Die Behandlung ist dabei für alle Aggregatfunktionen gleich. Folgendes Beispiel verdeutlicht diese Vorgehensweise:
Beispiel 5.3
Sicht: MaximumSicht
SELECT Max(a.ID) AS Maximum
FROM Tabelle1 AS a INNER JOIN Tabelle2 AS b ON a.ID=b.ID;
Transitionssicht: MaximumSicht_new
SELECT Max ( a.ID ) AS Maximum
FROM Tabelle1_new AS a INNER JOIN Tabelle2_new AS b ON a.ID = b.ID;
Delta-minus: MaximumSicht_minus
SELECT MaximumSicht.Maximum
FROM MaximumSicht
WHERE NOT EXISTS
(SELECT MaximumSicht_new.Maximum
FROM MaximumSicht_new
WHERE MaximumSicht.Maximum = MaximumSicht_new.Maximum);
Delta-plus: MaximumSicht_plus
SELECT MaximumSicht_new.Maximum
FROM MaximumSicht_new
WHERE NOT EXISTS
(SELECT MaximumSicht.Maximum
FROM MaximumSicht
WHERE MaximumSicht_new.Maximum = MaximumSicht.Maximum);
oder:
Delta-plus: MaximumSicht_plus
SELECT MaximumSicht_new.Maximum
FROM MaximumSicht_new
WHERE NOT EXISTS
(SELECT * FROM MaximumSicht_minus);
5.4
Alternativer Ansatz mit Multimengensemantik
Für spezielle Anwendungen muss dem Verwalten der Daten in der Datenbank eine
Multimengensemantik zugrunde gelegt werden. Dann ist auch ein korrekter Umgang mit Duplikaten bei der Änderungspropagierung notwendig. Im folgenden soll
70
Kapitel 5.
Spezialisierung von SQL-Sichten
nun untersucht werden, ob und in welcher Weise der oben beschriebene Ansatz zur
inkrementellen Änderungspropagierung in SQL auf ein System mit einer Multimengensemantik übertragbar ist. Dazu muss festgelegt werden, in welcher Art und Weise
die möglichen Duplikate in den Relationen verwaltet werden. Eine Diskussion ndet
in 5.4.1 statt. Im Anschluss daran wird in Abschnitt 5.4.2 beschrieben, wie der Effektivitätstest zu einem Wirksamkeitstest angepasst werden muss. Die generelle Generierung der Delta-Sichten wird in Abschnitt 5.4.3 thematisiert. Sehr weitreichende
Anpassungen und Erweiterungen des Compilers sind im Kontext einer Multimengensemantik nötig. Viele Operatoren müssen neu diskutiert werden. Beispielhaft wird in
Abschnitt 5.4.4 das Problem hinsichtlich des OR-Operators aufgeführt. Zum Schluss
werden in Abschnitt 5.4.5 Anregungen für eine Umsetzung gegeben.
5.4.1 Duplikate
Hinsichtlich der Behandlung von Duplikaten bei der Änderungspropagierung gibt es
verschiedene Ansätze, wie z.B. [GMS93] und [GL95]. Dort werden unterschiedliche
Ansätze im Kontext relationaler Multimengen vorgestellt. Der Änderungspropagierung mit Duplikaten liegt zugrunde, dass nicht mehr nur die Existenz verschiedener
Ableitungswege für Fakten relevant ist, sondern zusätzlich die Anzahl alternativer
Ableitungen. Wesentlicher Unterschied beider Ansätze ist die Repräsentation der
Duplikate. Der Ansatz von Gupta et al [GMS93] stellt eine algorithmische Lösung
im Datalog-Kontext dar. Dort werden anhand der Sicht-Denition Regeln erstellt,
die mit Hilfe der alten materialisierten Daten der Sicht sowie den Änderungen an den
Basisrelationen die induzierten Änderungen der Sicht berechnen. Dabei besitzt jedes
Fakt einen Count-Wert, d.h. die Fakten liegen nur ein mal explizit in der Datenbank
vor, entsprechende Duplikate werden implizit durch den Count-Wert repräsentiert.
Der Ansatz von Grin et. al. [GL95] basiert auf einer Multimengenalgebra, die
um einige Operationen erweitert wird hinsichtlich der Behandlung von Multimengen erweitert wird. Dabei werden die Duplikate explizit gespeichert.
Insbesondere [GL95] verdeutlicht die Schwierigkeiten bei der Behandlung der verschiedenen Operatoren im Kontext einer Multimengenalgebra. Im folgenden soll nun
überprüft werden, ob sich der in diesem Kapitel erweiterte Ansatz im SQL-Kontext
auf die Behandlung von Duplikaten ausweiten lässt. Dabei sollen die Duplikate explizit behandelt werden, um die schon in SQL vorhandenen Multimengen-Operatoren
verwenden zu können.
5.4.2 Eektivitäts- vs Wirksamkeitstest
Im Kontext einer Multimengensemantik sind Duplikate in den Relationen zulässig. Dies gilt ebenso für die Delta-Relationen. Aus diesem Grund müssen Duplikate
auch bei der Änderungspropagierung korrekt behandelt werden. Bei der bisherigen
5.4
Alternativer Ansatz mit Multimengensemantik
71
Vorgehensweise wird innerhalb der Delta-Sichten ein Eektivitätstest durchgeführt,
um zu gewährleisten, dass die in den Sichten enthaltenen Tupel echte Änderungen darstellen. Aufgrund der Duplikatbehandlung ist ein Eektivitätstest bei den
Delta-Sichten wie in [Ber05] in dieser Form jedoch nicht sinnvoll, da dieser u.a. eine
Eliminierung der Duplikate durchführt. Statt dessen muss ein Test auf Wirksamkeit der Einfügungen und Löschungen vorgenommen werden, um korrekte Einträge
in den Delta-Sichten sicherzustellen. Gegeben sei eine Relation R sowie die entsprechenden Delta-Relationen. Für die Einfügungen bzw. die Löschungen sieht der
Wirksamkeitstest wie folgt aus:
∆R+
echt
: ∆R+ − ∆R−echt
∆R−
echt
: R − (R − (∆R− − ∆R+ )) = R ∩ (∆R− − ∆R+ )
Der Operator
−
stellt dabei eine Multimengendierenz (in Anlehnung an [GL95])
dar. Aufgrund der wechselseitigen Bezüge ist eine geeignete Reihenfolge bei der Bearbeitung sicherzustellen. Zuerst werden die echten Löschungen berechnet. Konträre
Änderungen hinsichtlich der Löschungen und Einfügungen werden eliminiert. Anschlieÿend wird überprüft, ob die Löschungen auch in der Relation vorhanden sind,
um die wirksamen Löschungen zu erhalten. Diese Menge der wirksamen Löschungen
ist eine Teilmenge der Löschungen. Erst danach werden die Einfügungen berechnet,
indem man konträre Änderungen hinsichtlich der Einfügungen und echten Löschungen eliminiert.
Es ist weiterhin eine zweistuge Generierung der Delta-Sichten erforderlich. In der
ersten Stufe werden wie beim obigen Vorgehen die Delta-Hilfssichten erstellt. Danach
wird in den eigentlichen Delta-Sichten der Wirksamkeitstest implementiert.
5.4.3 Delta Regeln
Das Verfahren aus [Ber05] zur Generierung der Delta-Sichten muss im Kontext einer Multimengensemantik angepasst werden. Aufgrund des Fehlens des Eektivitätstests verläuft die Propagierung der Änderungen der erstellten Delta-Regeln in
[Ber05] nicht mehr korrekt. In [Ber05] wird begründet, dass ohne Eektivitätstest
falsche Tupel in den Delta-Sichten auftreten können. Es können bei der Auswertung
der Regeln zu viele Tupel erzeugt werden.
Im Datalog-Kontext lässt sich diese Tatsache wie folgt begründen (vgl. [Pie01]). Zum
Ende einer Datalog-Transaktion ist eine Menge von Änderungen bzgl. verschiedener Basisrelationen zu propagieren. Dadurch können bei der Anwendung der DeltaRegeln (Denition XXX) Änderungen, die durch verschiedene Basisfaktenänderungen induziert werden, wiederholt abgeleitet werden. Ursache dafür ist die Auswertung der Seitenliterale. Diese werden z.B. bei Einfügungen jeweils im neuen Zustand
72
Kapitel 5.
Spezialisierung von SQL-Sichten
(inkl. aller neuen Fakten) ausgewertet. Dieses Redundanzproblem wird in [GMS93]
syntaktisch dadurch gelöst, dass alle Seitenliterale links vom
∆-Rumpliteral für den
neuen und alle rechts davon für den alten Datenbank-Zustand ausgewertet werden.
In [Man94] wird eine zusätzliche Regel generiert, mittels der die Folgeänderungen
abgeleitet werden, die nur auf den neuen Fakten (∆s) basieren. Die Seitenliterale
der anderen Delta-Regeln werden immer über den alten Zustand ausgewertet.
Beispiel 5.4
s(X, Y ) ← a(X, Z), b(Z, Y ) gegeben,
Verfahren folgende ∆-/Transitionsregeln
Sei eine Regel
mäÿ den verschiedenen
dann können gefür Einfügungen
modelliert werden.
[GM S93]:
∆+ s(X, Y ) ← ∆+ a(X, Z), b(Z, Y )
∆+ s(X, Y ) ← anew (X; Z), ∆+ b(Z; Y )
[M an94]:
∆+ s(X, Y ) ← ∆+ a(X, Z), b(Z, Y )
∆+ s(X, Y ) ← a(X, Z), ∆+ b(Z, Y )
∆+ s(X, Y ) ← ∆+ a(X, Z), ∆+ b(Z, Y )
Im Kontext einer Mengensemantik mit Implementierung eines Eektivitätstests
stellt dieses Problem lediglich eine Inezienz dar. Bei einer Multimengensemantik
ohne Eektivitätstest lassen sich die Redundanten Fakten aber nicht mehr entfernen, somit muss die Generierung der Delta-Regeln entsprechend angepasst werden.
Im folgenden soll die Methode von
[GM S93] verwendet werden, um weniger Regeln
handhaben zu müssen. Die Auswertung der Seitenliterale muss in der Art abgeändert werden, dass rechts des
∆-Literals
im alten und links davon im neuen Zustand
ausgewertet wird.
Beispiel 5.5
Wir betrachten das Beispiel 3.5 der intuitiven Generierung der Delta-
Regeln aud [Ber05] ein weiteres mal.
Gegeben ist folgende SQL-Sicht:
SELECT a.name FROM a,b,c WHERE a.name=b.name AND a.name=c.name
Der Compiler generiert daraus folgende Delta-plus-Sicht:
+
+ new new
SELECT a .name FROM a ,b
,c
+
new
+
new
WHERE a .name=b
.name AND a .name=c
.name
UNION ALL
new
new + new
SELECT a
.name FROM a
,b ,c
new
+
new
new
WHERE a
.name=b .name AND a
.name=c
.name
UNION ALL
new
new new +
SELECT a
.name FROM a
,b
,c
new
new
new
+
WHERE a
.name=b
.name AND a
.name=c .name
5.4
Alternativer Ansatz mit Multimengensemantik
73
Die Generierung muss in folgender Weise angepasst werden:
+
+
SELECT a .name FROM a ,b,c
+
+
WHERE a .name=b.name AND a .name=c.name
UNION ALL
new
new +
SELECT a
.name FROM a
,b ,c
new
+
new
WHERE a
.name=b .name AND a
.name=c.name
UNION ALL
new
new new +
SELECT a
.name FROM a
,b
,c
new
new
new
+
WHERE a
.name=b
.name AND a
.name=c .name
Diese Sichten stellen die Delta-Hilfssichten dar (vgl. Abschnitt 5.3.1). Die DeltaSichten mit Wirksamkeitstest müssen aufbauend auf diese Hilfssichten noch erstellt
werden.
Das Beispiel zeigt, dass der AND-Operator wie bisher korrekt verarbeitet wird.
Bei Verwendung des OR-Operators jedoch treten schon erste Probleme auf, wie im
folgenden Abschnitt aufgezeigt wird.
5.4.4 Delta-Regeln: Das OR-Problem
Die Behandlung des OR-Operator bereitet im Kontext einer Multimengensemantik
Probleme. Die Ergebnisse aus der Datalog-Welt können nicht ohne weiteres übertragen werden, da die Disjunktion in Datalog eine andere Semantik besitzt als die
Disjunktion in SQL. Der OR-Operator ist in SQL nicht direkt durch UNION noch
durch UNION ALL simulierbar, sodass keine direkte Entsprechung für die Disjunktion in Datalog (mehrere Regeln) gefunden werden kann.
Beispiel 5.6
Gegeben sein folgende Datalog-Sicht:
s(y) ← a(y), b(y)
s(y) ← a(y), c(y)
sowie die entsprechende Delta-Plus-Sicht (ohne Eektivitätstest):
+
+
new
s (y) ← a (y), b (y), not
s+ (y) ← anew (y), b+ (y), not
s+ (y) ← a+ (y), cnew (y), not
s+ (y) ← anew (y), c+ (y), not
r
r
r
r
Weiterhin sei die entsprechende Sicht in SQL gegeben:
SELECT a.name FROM a,b,c WHERE a.name=b.name OR a.name=c.name
Die nach alter Vorgehensweise generierte Delta-Plus-Sicht sieht wie folgt aus:
+
+ new new
SELECT a .name FROM a ,b
,c
+
new
+
new
WHERE a .name=b
.name OR a .name=c
.name
74
Kapitel 5.
Spezialisierung von SQL-Sichten
UNION ALL
new
new + new
SELECT a
.name FROM a
,b ,c
new
+
new
new
WHERE a
.name=b .name OR a
.name=c
.name
UNION ALL
new
new new +
SELECT a
.name FROM a
,b
,c
new
new
new
+
WHERE a
.name=b
.name OR a
.name=c .name
Diese Delta-Regel ist im Kontext einer Multimengensemantik oensichtlich falsch.
Es treten zu viele Vergleichsliterale auf. Aber auch ein Anpassen an die neue Vorgehensweise bei der Auswertung der Seitenliterale und ein Weglassen genau der Vergleichsliterale, bei denen keine Delta-Literale betroen sind, bringt keine Abhilfe,
wie folgendes Beispiel zeigt:
Beispiel 5.7
+
Nach dem neuen Verfahren generierte Datalog-Delta-plus-Sicht:
+
s (y) ← a (y), b(y)
s+ (y) ← anew (y), b+ (y)
s+ (y) ← a+ (y), c(y)
s+ (y) ← anew (y), c+ (y)
Die entsprechende neue SQL-Delta-plus-Sicht:
+
+
+
SELECT a .name FROM a ,b,c WHERE a .name=b.name OR
UNION ALL
new
SELECT a
.name FROM
anew ,b+ ,c
UNION ALL
new
SELECT a
.name FROM
anew ,bnew ,c+
WHERE
a+ .name=c.name
anew .name=b+ .name
WHERE
anew .name=c+ .name
Diese Vorgehensweise entspricht in etwa der in [GMS93]. Dort werden Duplikate
durch Count-Werte repräsentiert, während sie hier explizit vorliegen. Das Verfahren liefert an dieser Stelle nicht die gewünschten Ergebnisse. Das Problem liegt in
der vorausgesetzten Datalog-Sicht, deren Ergebnisse nicht direkt übertragen werden
können. Da die Duplikate explizit behandelt werden sollen, müsste sie quasi so
aussehen:
s(y) ← a(y), b(y), c(z)
s(y) ← a(y), b(z), c(y)
Die jeweiligen z produzieren Duplikate. Dementsprechend ergeben sich andere
Datalog-Delta-Plus-Regeln:
s+ (y) ← a+ (y), b(y), c(z)
s+ (y) ← anew (y), b+ (y), c(z)
s+ (y) ← anew (y), bnew (y), c+ (z)
s+ (y) ← a+ (y), b(z), c(y)
s+ (y) ← anew (y), b+ (z), c(y)
s+ (y) ← anew (y), bnew (z), c+ (y)
5.4
Alternativer Ansatz mit Multimengensemantik
Das OR-Problem: Lösung 1
zu OR
≡
75
Durch ein Umdenieren der Semantik von OR
UNION ALL (d.h., dass zwei Tupel generiert werden, wenn beide Tei-
le des OR-Ausdrucks true ergeben) lässt sich das Verfahren zur Generierung der
SQL-Delta-Relationen hinsichtlich der OR-Operators anpassen. Dazu wird zuerst
der SQL-Ausdruck, in dem der OR-Operator auftritt, in einen äquivalenten Ausdruck mit dem UNION ALL-Operator aufgesplittet und dann das intuitive Verfahren angewendet.
Beispiel 5.8
Gegeben ist folgende SQL-Sicht:
SELECT a.name FROM a,b,c WHERE a.name=b.name
UNION ALL
SELECT a.name FROM a,b,c WHERE a.name=c.name
Die neue SQL-Delta-plus-Sicht sieht folgendermaÿen aus:
+
+
+
SELECT a .name FROM a ,b,c WHERE a .name=b.name
UNION ALL
new
SELECT a
.name FROM
anew ,b+ ,c
UNION ALL
new
SELECT a
.name FROM
anew ,bnew ,c+
UNION ALL
SELECT
a+ .name
FROM
a+ ,b,c
WHERE
WHERE
WHERE
UNION ALL
new
SELECT a
.name FROM
anew ,b+ ,c
UNION ALL
new
SELECT a
.name FROM
anew ,bnew ,c+
Das OR-Problem: Lösung 2
anew .name=b+ .name
anew .name=bnew .name
a+ .name=c.name
WHERE
anew .name=c.name
WHERE
anew .name=c+ .name
Unter Beibehaltung
der Semantik des OR-
Operators ist ebenfall eine Anpassung des Verfahrens möglich. Dazu wird der ORAusdruck zuerst aussagenlogisch umgeformt. Sobald nur noch der AND-Operator
vorhanden ist, kann die obige naive Vorgehensweise verwendet werden.
(a = b) ∨ (a = c) ≡
((a = b) ∧ ¬(a = c)) ∪ (¬(a = b) ∧ (a = c)) ∪ ((a = b) ∧ (a = c))
6= (a = b) ∪ (a = c)
Beispiel 5.9
SELECT
Umgeformte Sicht in SQL:
a.name
FROM
a,b,c
WHERE
a.name=b.name
AND
NOT
FROM
a,b,c
WHERE
NOT
a.name=b.name
AND
a.name=c.name
UNION ALL
SELECT
a.name
a.name=c.name
UNION ALL
76
Kapitel 5.
Spezialisierung von SQL-Sichten
SELECT a.name FROM a,b,c WHERE a.name=b.name AND a.name=c.name
Angepasste neue SQL-Delta-plus-Sicht:
SELECT a+ .name FROM a+ ,b,c WHERE a+ .name=b.name
AND NOT a+ .name=c.name
UNION ALL
SELECT anew .name FROM anew ,b+ ,c WHERE anew .name=b+ .name AND NOT
anew .name=c.name
UNION ALL
SELECT anew .name FROM anew ,bnew ,c+ WHERE anew .name=bnew .name AND NOT
anew .name=c+ .name
UNION ALL
SELECT a+ .name FROM a+ ,b,c WHERE NOT a+ .name=b.name AND a+ .name=c.name
UNION ALL
SELECT anew .name FROM anew ,b+ ,c WHERE NOT anew .name=b+ .name AND
anew .name=c.name
UNION ALL
SELECT anew .name FROM anew ,bnew ,c+ WHERE NOT anew .name=bnew .name AND
anew .name=c+ .name
UNION ALL
SELECT a+ .name FROM a+ ,b,c WHERE a+ .name=b.name AND a+ .name=c.name
UNION ALL
SELECT anew .name FROM anew ,b+ ,c WHERE anew .name=b+ .name AND anew .name=c.name
UNION ALL
SELECT anew .name FROM anew ,bnew ,c+ WHERE anew .name=bnew .name AND
anew .name=c+ .name
Weitere SQL-Operatoren müssen noch in gleicher Weise diskutiert werden. Es ist
leicht zu erkennen, dass die Ergebnisse hinsichtlich der Änderungspropagierung aus
dem Datalog-Kontext nicht ohne weiteres auf den Kontext einer Multimengensemantik in SQL übertragbar sind.
5.4.5 Möglichkeiten der Umsetzung
Für eine Implementierung des Ansatzen mit korrekter Behandlung von Duplikaten
wird ein DBMS benötigt, welches die entsprechenden Multimengenoperatoren wie
z.B: wie EXCEPT ALL oder INTERSECT ALL unterstützt. Dies bietet z.B. das
DBMS PostgreSQL. Zusätzlich wären bei der Verwendung von PostgreSQL Technologien wie Trigger, Java-Stored-Procedures usw. verwendbar.
5.4
Alternativer Ansatz mit Multimengensemantik
77
Probleme würde eine Verbindung zwischen VBA und PostgreSQL aufgrund einer mangelnden Treiber-Unterstützung bereiten. Anbieten würde sich eine JavaImplementierung des Sichtencompilers, da von Java aus eine vollständige Unterstützung verschiedenster DB-Treiber möglich ist.
Kapitel 6
SIMON II
In Kapitel 3 wurde das bisher bestehende System SIMON zur Überwachung mobiler
Objekte auf Netzwerken vorgestellt. In diesem Kapitel werden konzeptuelle Erweiterungen hinsichtlich des SIMON-Systems beschrieben, die im Rahmen dieser Arbeit
realisiert werden. Dazu gehören Erweiterungen hinsichtlich der bestehenden Komponenten MOSIM, VISMONET und dem Compiler sowie der Entwurf des Monitors,
der den von MOSIM generierten Datenstrom analysiert und die Analyseergebnisse
an VISMONET weiterleitet. Der Monitor orientiert sich an den Ergebnissen der
theoretischen Behandlung der Überwachung von Datenströmen in den Kapiteln 4
und 5. Es werden bei der Beschreibung der konzeptuellen Erweiterungen jeweils
auch Details der Implementierung vorgestellt. Abschnitt 6.1 beschreibt die Architektur des erweiterten Systems und geht insbesondere auf das Zusammenwirken der
Komponenten bzw. deren Interaktion ein. Im Anschluss daran werden in den Abschnitten 6.2 bis 6.5 XXXX die Erweiterungen hinsichtlich der Komponenten von
SIMON sowie die neuen Komponenten vorgestellt.
6.1
Gesamtarchitektur
Das SIMON-System besteht aus den drei Komponenten MOSIM, Monitor und VISMONET. MOSIM ist ein Simulator für mobile Objekte auf Netzwerken (vgl. Abschnitt 3.4). Dabei wird das Verhalten mobiler Objekte auf einem zugrundeliegenden Verkehrsnetz simuliert, um kontinuierliche Positionsdaten zu generieren. In Abschnitt 6.2 werden u.a. Erweiterungen von MOSIM hinsichtlich des Verhaltens der
mobilen Objekte sowie der Eingabe und Verwaltung von benutzerdenierten Ereignissen vorgenommen.
Der Monitor überwacht den von MOSIM generierten Strom an Positionsdaten. Die
Komponente basiert auf der in Abschnitt 4 entwickelten Architektur und wird in
78
6.1
Gesamtarchitektur
79
Abschnitt 6.3 entworfen. Der Monitor führt eine datenbankgestützte Analyse des von
MOSIM generierten Datenstroms durch. Der Monitor besteht aus den Komponenten
Input-Manager, Compiler, CQ-Manager sowie einem DBMS. Der Input-Manager
führt eine Vorverarbeitung der Datenströme durch und speichert die Stromdaten
blockweise in der Datenbank. Über den CQ-Manager können Anfragen speziziert
werden, die kontinuierlich über den gespeicherten Stromdaten sowie weiteren in der
Datenbank enthaltenen Metadaten ausgewertet werden. Der in [Ber05] entwickelte
Compiler bringt die Anfragen in eine Form, mit der man eine eziente Beantwortung
der Anfragen durchführen kann. Das Prinzip des Compilers basiert auf Methoden der
Änderungspropagierung (vgl. Abschnitt 2.1.4) und wurde in Kapitel 5 überarbeitet.
VISMONET visualisiert das Netzwerk sowie die mobilen Objekte (vgl. Abschnitt
3.5) und stellt die Bewegung der Objekte anhand der von MOSIM generierten Positionsdaten grasch auf einer Bildschirmkarte dar. In Abschnitt 6.2 werden u.a.
Erweiterungen von VISMONET hinsichtlich der Darstellung der Ereingnisse in MOSIM und der Analyseergebnisse der Monitors vorgenommen.
Abbildung 6.1 zeigt die Architektur des Systems. Dort werden die einzelnen Komponenten und ihre Zusammenhänge sowie der Datenuss zwischen den Komponenten
dargestellt.
Abbildung 6.1: SIMON Zielarchitektur
Es gibt zwei verschiedene Wege des Datenusses. Zum einen werden die von MOSIM simulierten Stromdaten direkt von VISMONET visualisiert (Tracking-Mode).
Die Daten werden dabei unmittelbar ohne zwischenzeitliche Verarbeitung von MOSIM an VISMONET weitergeleitet. Die Positionen der mobilen Objekte werden
dann in Abhängigkeit von der Positionsaktualisierungsrate auf Seite von MOSIM
bzw. der Bildaktualisierungsrate auf Seite von VISMONET kontinuierlich grasch
80
Kapitel 6.
SIMON II
dargestellt.
Die zweite Möglichkeit des Datenusses ist der Weg über die Analyse-Komponente.
Dabei werden die von MOSIM simulierten Stromdaten an den Monitor weitergegeben und entsprechend den vom Benutzer eingegebenen Spezikationen analysiert
(Analyse-Mode). Der Analyse-Mode kann zusätzlich zum Tracking-Mode verwendet werden. Die Resultate der Analyse werden an VISMONET weitergeleitet. Die
Dastellung der mobilen Objekte beim Tracking-Mode wird entsprechend der Daten
des Analyse-Modes angepasst. Der Datenuss zwischen den einzelnen Komponenten
MOSIM, VISMONET und Monitor wird genauer in Abschnitt 6.5 erläutert.
Für die Komponenten MOSIM, VISMONET und Monitor wurde eine gemeinsame
Startkomponente entwickelt. Das Gesamtsystem wird mit der Klasse MainVisMoNet.java gestartet. Diese erstellt das Startfenster (StartFrame.java). Das Startfenster
ist in Abbildung 6.2 aufgezeigt. Die einzelnen Komponenten MOSIM, VISMONET
und Monitor werden im Hintergrund initialisiert. Über die Buttons werden die Fenster aufgerufen. Die Komponenten werden automatisch miteinander Verbunden. So
ist es möglich, an zentraler Stelle ein Szenario zu laden, sodass dessen Parameter von MOSIM und VISMONET synchron ausgelesen werden (über die Methode
loadSzenario() des VISMONET-Controllers).
Abbildung 6.2: SIMON Startfenster
6.2
MOSIM II
Die Komponente MOSIM, die für die Simulation der Positionsdaten sich kontinuirlich bewegender mobiler Objekte auf Netzwerken zuständig ist, wurde in Abschnitt
3.4 beschrieben. Im folgenden werden nun Erweiterungen von MOSIM vorgestellt
und einige Implementierungsdetails beschrieben. Diese umfassen folgende Punkte:
•
Anpassung der Geschwindigkeit in Bezug auf eine vorgegebene Ankunftszeit
eines mobilen Objekts am Zielort
•
Einführung einer Haltezeit an Orten
•
Anpassung der GUI bzw. Bedienung
•
Verwaltung von benutzerdenierten Ereignissen
•
Anpassungen des Netzwerks
6.2
MOSIM II
Anpassung hinsichtlich der Ankunftszeit
81
Hinsichtlich des in [Roh05] entwor-
fenen Szenarios (ICE-Verkehr der Deutschen Bahn) ist ein erweitertes Verhalten der
mobilen Objekte aus [Bua03] nötig. Die Objekte bewegen sich nach einem Fahrplan, d.h. es sind nicht nur die Abfahrtszeiten der Objekte relevant, sondern auch
die entsprechenden Ankunftszeiten am nächsten Ort. Dementsprechend muss die
Geschwindigkeit der Objekte in Abhängigkeit von der gewünschten Ankunftszeit
gewählt werden Dadurch ist eine realistischere Simulation gewährleistet. Die Skripteinträge werden um einen Eintrag Ankunftszeit erweitert. Das Verhalten der mobilen Objekte muss wie folgt abgeändert werden: Ist eine Ankunftszeit angegeben,
versuchen die mobilen Objekte nicht wie bisher, immer ihre Höchstgeschwindigkeit
zu erreichen und somit so schnell wie möglich anzukommen. Das Objekt berechnet
statt dessen aus der verbleibenden Strecke und der noch zur Verfügung stehenden
Zeitspanne bis zur Ankunftszeit die zu fahrende Geschwindigkeit, sodass es genau
zur spezizierten Zeit ankommt. Eine Überprüfung der aktuellen Geschwindigkeit
ndet wie bisher bei jeder Positionsaktualisierung des Objektes. Dadurch ist gewährleistet, dass die Geschwindigkeit auch nachträglich angepasst wird, falls das
Objekt zwischenzeitlich durch bestimmte Ereignisse (Sperrung, schlechtes Wetter
usw.) aufgehalten wurde.
Wenn sich das mobile Objekt aktuell auf einer Verbindung bendet, wird bei jeder
Positionsaktualisierung die erwartete Ankunftszeit des Objekts anhand der noch zu
fahrenden Strecke und der aktuellen Geschwindigkeit berechnet. Folgendes CodeBeispiel gibt wieder, wie die genau die Ankunftszeit berechnet wird:
private SimZeit berechneAnkunft() {
SimZeit ankunft;
double differenzStrecke =
this.getPositionMO().getVerbindung().getLaenge()
- this.positionMO.getStrecke();
long differenzIntervall =
(long) (differenzStrecke / this.aktGeschwindigkeit * 3600000.0);
ankunft =
new SimZeit(simzeit.getSimzeit().getTime() + differenzIntervall);
return ankunft;
}
Sofern die berechnete Ankunftszeit bei aktueller Geschwindigkeit von der im Skripteintrag festgelegten Ankunftszeit abweicht, muss die Geschwindigkeit des mobilen
Objekts angepasst werden.
Dies passiert innerhalb der Methode erhoeheGeschwindigkeit(), die bei jeder Positionsaktualisierung (Methode aktualisierePositionMO()) aufgerufen wird. Das mobile
Objekt versucht dabei, die maximal mögliche Geschwindigkeit zu erreichen. Diese ergibt sich aus dem Minimum der auf der Verbindung möglichen Maximalgeschwindgkeit und der Maximalgeschwindgkeit des mobilen Objekts. Das mobile Objekt soll
82
Kapitel 6.
SIMON II
jedoch auch nicht vor der festgelegten Ankunftszeit am Zielort ankommen. Folgender Code zeigt, wie die Geschwindigkeit des mobilen Objekts angepasst wird, sodass
es genau zur vorgegebenen Ankunftszeit am Zielort ankommt:
...
if (this.simzeit.getSimzeit().getTime() <
this.skript.getaktuellenSkripteintrag().getAnkunftszeit()
.getSimzeit().getTime()) {
longdifferenzIntervall =
this.skript.getaktuellenSkripteintrag().getAnkunftszeit().
getSimzeit().getTime()
- this.simzeit.getSimzeit().getTime();
double differenzStrecke =
this.getPositionMO().getVerbindung().getLaenge()
- this.positionMO.getStrecke();
double neueGeschwindigkeit =
(double) (differenzStrecke / (differenzIntervall / 3600000.0));
if (neueGeschwindigkeit < this.aktGeschwindigkeit) {
this.aktGeschwindigkeit = neueGeschwindigkeit;
}
}
...
Einführung einer Haltezeit
Um eine realistischere Simulation zu erhalten, ist
eine zusätzliche Erweiterung notwendig. Diese umfasst die Einführung einer minimalen Haltezeit am Ende einer Fahrt eines Streckenabschnitts. Dadurch dass die
Objekte aufgrund von bestimmten Ereignissen wie Streckensperrungen oder dem
Herabsetzen der Geschwindigkeit auf einer Strecke vom Fahrplan abweichen können
und dadurch die Ankunftszeit nicht zwingend eingehalten werden kann, ist eine implizite Angabe der Haltezeit allein aus der Dierenz zwischen der Ankunftszeit und
dem nächsten Abfahrtszeitpunkt nicht sinnvoll. Stattdessen sollte die Haltezeit, da
diese durchaus je nach Objekt (Zugtyp) bzw. Ort (bahnhofspezische Eigenschaften...) variieren kann, zusätzlich explizit angegeben werden. Keine Angabe bzw. eine
Angabe von 0 bedeutet dabei, dass der Zug den Ort durchfährt. Sinnvoll ist eine
Angabe der minimalen Haltezeit, die das Objekt am entsprechenden Ort verbleiben muss, bevor es weiterfahren kann. Die Skripteinträge werden um einen Eintrag
Haltezeit erweitert. Eine längere Haltezeit ergibt sich ggf. automatisch, wenn der
nächste Abfahrtszeitpunkt noch nicht erreicht ist.
6.2
MOSIM II
83
Das Verhalten des mobilen Objekts ist in folgender Weise umgesetzt: Die Skripteinträge (Skripteintrag.java) werden um das Attribut haltezeit erweitert. Diese
speziziert die Zeitspanne in Sekunden, die das mobile Objekt am Ende einer gefahrenen Verbindung warten muss, bevor es auf eine neue Verbindung wechseln kann.
Folgender Code zeigt, wie innerhalb der Methode aktualisierePositionMO() der Klasse MobilObjektImpl.java getestet wird, ob die angegebene Haltezeit vorüber ist, falls
das mobile Objekt die nächste zu fahrende Verbindung erreicht hat. Die Methode
haltezeitvorüber() überprüft dabei, ob die nächstmögliche Abfahrtszeit aufgrund der
Haltezeit später liegt als die im Skripteintrag angegebene Abfahrtszeit.
{ ...
if (haltezeitvorüber()) {
this.warteStatus = false;
}
else {
this.warteWegenHaltezeit();
}
...
}
private void warteWegenHaltezeit() {
positionMO.setaufVerbindung(false);
positionMO.setVerbindung(skript.getaktuellenSkripteintrag().getVerbindung());
positionMO.setOrt(positionMO.getVerbindung().getZielort());
this.aktGeschwindigkeit = 0;
this.warteStatus = true;
}
private boolean haltezeitvorüber() {
boolean haltezeitvorüber = true;
int haltezeit = skript .getaktuellenSkripteintrag() .getHaltezeit();
if (this.ankunftszeit.getSimzeit().getTime() + haltezeit * 1000 <
this.simzeit.getSimzeit().getTime()) {
haltezeitvorüber = true;
} else {
haltezeitvorüber = false;
nächstmöglicheAbfahrtszeit.setSimzeit(
this.ankunftszeit.getSimzeit().getTime()
+ haltezeit * 1000);
}
return haltezeitvorüber;
}
84
Kapitel 6.
Anpassung der GUI bzw. Bedienung
SIMON II
Die Programmoberäche wurde ange-
passt und ist in Abbildung 6.3 zu sehen. Sie beinhaltet die Anzeige der Simulationszeit sowie die Steuerung der Simulation mittels der Buttons start, stop und pause. Neu sind dabei die Möglichkeiten der Einstellung der Simulationsgeschwindigkeit
per Eingabefeld sowie per Slider und die Einstellung des Aktualisierungsintervalls
per Eingabefeld sowie per Slider.
XXXX Protokollierung? evtl. rausnehmen.... XXXX
Abbildung 6.3: neue MOSIM GUI
Verwaltung benutzerdenierter Ereignisse
Die interaktive Beeinussung der
Simulation durch benutzerdenierte Ereignisse ist noch nicht vollständig implementiert worden. Die Routine zur Verarbeitung der Ereignisse ist vorhanden, ebenso
einige vordenierte Ereignisse. Es müssen ggf. weitere Ereignistypen vordeniert
werden. Folgende vordenierte Ereignisse sind verfügbar:
•
Meldung (Testereignis)
•
SperreVerbindung
•
EntsperreVerbindung
•
SchlechtesWetter
6.2
MOSIM II
•
85
SetzeGeschwindigkeit
XXXX Bisher benden sich die Klassen in VISMONET: EventTableModel, EventPanel, EventFrame XXXX
Zusätzlich muss die Schnittstelle zum Benutzer entworfen werden, mit der die Ereignisse oine und online eingegeben und editiert werden können. Diese wird innerhalb
eines Ereignismanagers implementiert (vgl. Abbildung 6.4). Je nach Typ der vordenierten Ereignisse ändern sich die Parameter.
Abbildung 6.4: Ereignismanager
Je nach Ereignistyp bzw. Angabe der Daten werden intern zwei Ereignisse erstellt.
Dies geschieht z.B. dann, wenn man eine Strecke sperrt und dabei eine Dauer bzw.
End-Zeit angibt und damit die Strecke wieder entsperrt.
Die generierten Daten der Simulation (ausschlieÿlich Positionsdaten der mobilen
Objekte und entsprechende Parameter) werden im Tracking-Mode von MOSIM an
86
Kapitel 6.
SIMON II
VISMONET weitergegeben. Um aber in der Visualisierungskomponente auch die benutzerdenierten Ereignisse darstellen zu können, müssen zusätzlich weitere Daten
des Simulators an die Visualisierungskomponente übergeben werden, z.B. Zustandsdaten hinsichtlich der Verbindungen. Es muss ein Verknüpfen der Verbindungen
zwischen MOSIM und VISMONET stattnden. Die Ereignisse (wie z.B. Streckensperrung) beeinussen dabei auf der Seite von MOSIM jeweils den Zustand (bzw.
Attribute) der Verbindungen. Diese Attribute werden dann von VISMONET abgefragt, den entsprechenden Verbindungen zugeordnet und visualisiert. Details zur
Anbindung von MOSIM an VISMONET und den Monitor werden in Abschnitt 6.5
beschrieben.
Die Daten der Simulation werden zudem nicht direkt in der Datenbank gespeichert.
Stattdessen werden die Daten im Analyse-Mode dem Input-Manager des Monitors
zur Verfügung gestellt (vgl. Abschnitte 6.3.2 und 6.5).
Anpassungen am Netzwerk
Eine weitere Änderung wurde am Konzept des
Netzwerks vorgenommen, indem die Verbindungen zusätzlich zur Höchstgeschwindigkeit, die durch den Typ deniert ist, eine eigene Instanz-Geschwindigkeit erhalten haben. Dies ist nötig, da die Geschwindigkeit durch Ereignisse geändert werden
soll. Sie kann jedoch nicht höher sein als die im Typ denierte Geschwindigkeit.
6.3
Monitor
In den folgenden Abschnitten wird die Monitoring-Komponente vorgestellt. Der Monitor besteht im Wesentlichen aus den drei Komponenten Inputmanager, Compiler
und CQ-Manager sowie einem zugrundeliegenden DBMS. Er basiert hinsichtlich der
Gesamtarchitektur auf den Ergebnissen aus Kapitel 4 und hinsichtlich des Compilers auf den Ergebnissen aus Kapitel 5. Da sowohl die Vorversion des Compilers
([Ber05]) als auch das Beispielszenario ([Roh05]) in eine Access-Datenbank integriert sind, wird Access als zugrundeliegendes DBMS weiterverwendet. In Abschnitt
6.3.1 wird die Architektur des Monitors vorgestellt. Abschnitt 6.3.2 befasst sich mit
dem Inputmanager, Abschnitt 6.3.3 mit dem Compiler und Abschnitt 6.3.4 mit dem
CQ-Manager.
6.3.1 Architektur
Der Monitor besteht aus den Komponenten Input-Manager, Compiler, CQ-Manager
und einem DBMS. Abbildung 6.5 zeigt die Architektur des Monitors auf. Der InputManager verarbeitet die Stromdaten, die von MOSIM generiert werden. Nach der
Vorverarbeitung werden Teile der Stromdaten in einer Datenbank gespeichert. In
6.3
Monitor
87
Abschnitt 6.3.2 wird der Input-Manager im Detail vorgestellt. Die Anfragen, welche über den in der Datenbank gespeicherten Stromdaten sowie weiteren Metadaten
ausgewertet werden, werden durch den CQ-Manager verwaltet. Er nimmt die vom
Benutzer spezizierten Anfragen entgegen und leitet sie an den Compiler weiter.
Der Compiler bringt die Anfragen auf eine Form, die eine eziente Auswertung
mit Hilfe des Konzepts der Änderungspropagierung möglich macht und speichert im
Zuge dessen die Anfrage als Sicht sowie einige neu generierte Sichten in der Datenbank. Der CQ-Manager berechnet anhand dieser Sichten die Ergebnisse hinsichtlich
der zu überwachenden Anfragen und stellt diese Analyseergebnisse zur Verfügung.
Compiler und CQ-Manager werden in den Abschnitten 6.3.3 und 6.3.4 im Detail
besprochen.
Abbildung 6.5: Architektur Monitor
Die zur Verwaltung der Stromdaten verwendete Tabelle (Protokoll-Tabelle) enthält
die historischen Stromdaten. Neue Stromdaten, die beim nächsten Analyse-Schritt
verwendet werden sollen, werden in die im Zuge der Kompilierung der zu überwachenden Anfragen erstellten Protokoll-Delta-Tabelle gespeichert. Die zu überwachenden Bedingungen, die durch den Compiler erstellten spezialisierten Sichten,
sowie die Metadaten, auf denen die Sichten zusätzlich basieren, stehen in der AccessDatenbank als Teil des Anwendungsszenarios zur Verfügung.
6.3.2 Inputmanager
Der Input-Manager führt eine Vorverarbeitung der Stromdaten durch. Eine anwendungsabhängige Vorverarbeitung vor der Speicherung der Stromdaten in der DB ist
z.B. sinnvoll, um die Datenmenge zu begrenzen. Je nach Art der Anwendung sind
nicht alle Daten der Datenströme von Interesse. Die anwendungsspezisch nicht relevanten Daten sollen eliminiert werden, da die Analyse umso ezienter durchgeführt
88
Kapitel 6.
SIMON II
werden kann, je geringer der Umfang der Daten ist. Zusätzlich ist eine blockweise
Verarbeitung der Daten sinnvoll, falls die Daten der Datenströme ungeordnet und
nicht in einheitlichem Takt eintreen.
Der Input-Manager stellt die Verknüpfung von MOSIM zum Monitor dar. Die genaue Vorgehensweise hinsichtlich der Anbindung mit MOSIM wird in Abschnitt 6.5
beschrieben. Die Vorverarbeitung besteht aus der Entgegennahme der von MOSIM
simulierten Stromdaten, dem Filtern sowie dem Zusammenstellen von Transaktionen von Stromdaten. Aufgrund der Art der Anbindung an MOSIM ist keine explizite
Puerung bzw. Filterung der Stromdaten nötig. Die Datenmenge der Stromdaten
kann auf Seite des Simulators MOSIM durch die Simulationsparameter beeinusst
werden (vgl. Abschnitt 6.2). Zusätzlich ndet eine implizite Filterung statt, da jeweils zu Begin eines Analyseschrittes des CQ-Managers (vgl. Abschnitt 6.3.4) die
aktuell generierten Stromdaten eingelesen und die zwischen zwei Analyseschritten
simulierten Daten verworfen werden.
Bei der Vorverarbeitung von Stromdaten in Form von Blöcken wird jeweils eine
Menge von Datensätzen zu einer Einheit zusammengefasst und weiterverarbeitet.
Bei der blockweisen Verarbeitung sind aufeinanderfolgende Blöcke disjunkt. Details
der Verarbeitung wie z.B. die Länge und der Abstand zwischen den Fenstern sind
durch Parameter zu beeinussen.
Die Blöcke werden im Fall des SIMON-Systems wie folgt generiert: Innerhalb eines
Blocks jeweils zu jedem Objekt im System die Sensordaten eines bestimmten Zeitpunktes zusammengefasst. Die Blockweise Verarbeitung wird zusätzlich auch aus
ezienzgründen beim Übertragen der Daten (per ODBC) zur Datenbank verwendet. Ein solcher Block bzw. eine Transaktion beinhaltet also eine zusammengehörige
Menge von Stromdaten, die gemeinsam in der Datenbank gespeichert werden (vgl.
Abschnitt 4.3.1). Die Analyse wird jeweils auf neuem Block ausgeführt, d.h. pro
neuer Transaktion wird ein Analyseschritt durchgeführt.
Da das System keine Online-Analyse der Stromdaten durchführt, sondern auf einer
DBMS-internen Analyse mittels generischer Methoden des DBMS basiert, müssen
die Daten der Datenströme intern im System verwaltet werden. Zuerst müssen die
Daten abgespeichert werden. In Abhängigkeit von der Attributstruktur der Stromdaten ist dabei zu entscheiden, ob die Daten beim konkreten Abspeichern in eine
groÿe Strom-Relation gespeichert werden, oder ob ein Verteilen der Daten auf mehrere Relationen erfolgt. Ist die Attributstruktur einheitlich, ist das Speichern in einer
einzelnen Relation ohne weiteres möglich. Im Falle von unterschiedlicher Attributstruktur muss diese entweder unter ggf. möglichem Verlust an Daten vereinheitlicht oder die Datenströme in verschiedenen Relationen gespeichert werden. Je nach
Attributstruktur sind auch andere Aufteilungen der Datenströme auf verschiedene
Relationen möglich, z.B. nach semantischen Gesichtspunkten wie der Position, an
der die Daten aufgetreten sind o.ä. Mögliche Aufteilungen können z.B. anhand der
Attributstruktur, in der die Daten geliefert werden, oder nach den unterschiedlichen
6.3
Monitor
89
Datenströmen vorgenommen werden. Im Falle des betrachteten Anwendungsszenarios (vgl. Abschnitt 3.8) ist eine Aufteilung nicht nötig. Es ist lediglich ein Datenstrom
vorhanden, der in eine Stromrelation (Protokolltabelle) gespeichert wird.
Der Input-Manager ist innerhalb der Klasse DBProtokollManager.java implementiert. Die Methode collectProtokollEntries() stellt eine Kollektion von Protokolleinträgen eines festen Zeitpunktes zusammen (für jedes mobile Objekt ein Eintrag).
Dazu greift die Methode (per pull) auf die Daten von MOSIM zu:
Vector protokollEinträge = controller.getSimulatorManager().
getController().getAktuelleProtokollDaten();
Aus den einzelnen Einträgen wird jeweils ein SQL-Statement erstellt. Dazu müssen u.a. die Koordinaten anhand der gefahrenen Strecke auf der aktuellen Verbindung sowie dem Start- und Zielort der Verbindung zurückgerechnet werden. Das
Statement wird einem Vector zugefügt (protokollStatements). Die Methode writeProtokoll() überprüft, ob die Delta-Plus-Protokolltabelle existiert. Die Einträge des
Vectors mit den Protokollstatements werden einem DB-Batch angehängt, dessen
Statements dann simultan ausgeführt werden (entspricht einer Transaktion). Folgendes Code-Beispiele zeigt die Generierung und Ausführung einer Transaktion:
public void writeProtokoll() {
...
if(protokollPlusTableAvailable) {
try {
if(!protokollStatements.isEmpty()) {
Statement stmt = this.dbConnection.createStatement();
Enumeration enum = protokollStatements.elements();
while(enum.hasMoreElements()) {
String sql = (String) enum.nextElement();
stmt.addBatch(sql);
}
protokollStatements.removeAllElements();
stmt.executeBatch();
stmt.close();
}
}
catch (SQLException e) {
e.printStackTrace();
}
}
}
Die Methode moveProtokollEntries() speichert nach einem Analyseschritt die Tupel der Delta-Plus-Protokolltabelle in die Protokolltabelle um. Die Methode wird
dabei vom CQ-Manager (vgl. 6.3.4) nach der Durchführung eines Analyseschrittes
aufgerufen.
90
Kapitel 6.
SIMON II
6.3.3 Compiler
Das in Abschnitt 3.7 vorgestellte Tool zur Spezialisierung von SQL-Sichten ([Ber05])
legt in der Datenbank Sichten (Delta- und Transitionssichten) an, mit denen sich
die Änderungen (d.h. neue Tupel bzw. Einfügungen und Tupel, die entfernt werden
bzw. Löschungen) an einer bestimmten Monitoring-Sicht bestimmen lassen. Die Vorgehensweise basiert auf dem in Abschnitt 2.1.4 vorgestellten Prinzip der Änderungspropagierung. Die jeweiligen Tupel in den Delta-Tabellen sind die durch die aktuellen Daten des Datenstroms hervorgerufenen Änderungen der jeweiligen Sicht. Es ist
sinnvoll, nur diese Änderungen, die in den entsprechenden Delta-Relationen stehen,
zu betrachten, um ein inezientes Berechnen der gesamten Sicht zu vermeiden. Die
erforderlichen Anpassungen und Erweiterungen hinsichtlich des Sichtencompilers,
der die Kernkomponente des Monitors darstellt, wurden in der Theorie in Kapitel 5
behandelt. Diese umfassen u.a. eine Anpassung der Generierung der Delta-Sichten,
insbesondere derer mit Aggregatfunktionen. Im folgenden wird die Umsetzung dieser
Erweiterungen mit Hilfe einiger Implementierungsdetails beschrieben.
In
der
Haupt-Methode
Basistabellen
angepasst.
me_minus_Tabelle
wurde
Die
die
Generierung
Delta-Tabellen
der
werden
Delta-Tabellen
nun
bzw. Tabellenname_minus_Tabelle
mit
für
die
Tabellenna-
benannt werden. In-
nerhalb der Haupt-Methode werden auf diesen Tabellen basieren die Delta-Sichten
erstellt, die einen Eektivitätstest implementieren. Die Generierung der inkrementellen Transitionssichten wurde in der Weise abgeändert, dass die neuen Bezeichnungen der Delta-Tabellen verwendet werden. Folgendes Codebeispiel verdeutlicht
die Umsetzung für Tabellen:
If TabVorhanden(v.Name) = True Then
Call Transitionssicht_Inkrementell(v.Name)
If TabVorhanden(v.Name + _minus_Tabelle) = False And
TabVorhanden(v.Name + _plus_Tabelle) = False Then
DoCmd.TransferDatabase acExport, Microsoft Access, CurrentDb.Name,
acTable, v.Name, v.Name + _minus_Tabelle, True
DoCmd.TransferDatabase acExport, Microsoft Access, CurrentDb.Name,
acTable, v.Name, v.Name + _plus_Tabelle, True
Call Effiktivitaetstest(v.Name, v.Name + _minus_Tabelle,
v.Name + _new, True)
Call Effiktivitaetstest(v.Name, v.Name + _plus_Tabelle,
v.Name, True)
End If
Alle_Tab.Add Item:=v.Name, Key:=v.Name
...
Die Generierung der naiven Transitionssichten wurde beibehalten. Die Methoden,
die vorher die Delta-Sichten generiert haben, erstellen nun die Delta-Hilfssichten.
6.3
Monitor
91
Auf diesen aufbauend werden die Delta-Sichten generiert, die den Eektivitätstest
implementieren, bzw. die Delta-Sichten hinsichtlich der Aggregatfunktionen generiert. Aufgrund der Tatsache, dass die Generierung im Kontext einer Mengensemantik durchgeführt wird (vgl. Abschnitte 5.1 und 5.2), werden die einzelnen Teilregeln der Delta-Regeln mit UNION statt mit UNION ALL verknüpft. Folgendes
Codebeispiel verdeutlicht die Umsetzung für Sichten:
...
Call Polaritaet_bestimmen(c_statement, Neg_Pol, Pos_Pol, Alle_rel, 2)
Call Transitionssicht_Naiv(c_statement, SIchtname, Alle_rel)
Call Delta_Sicht_Plus(coll, SIchtname)
Call Delta_Sicht_Minus(coll, SIchtname)
If InStr(1, c_statement.Item(2), max) <> 0 Or
InStr(1, c_statement.Item(2), min) <> 0 Or
InStr(1, c_statement.Item(2), count) <> 0 Or
InStr(1, c_statement.Item(2), sum) <> 0 Or
InStr(1, c_statement.Item(2), avg) <> 0 Then
Call Aggregatfunktion(c_statement, SIchtname, minus)
Call Aggregatfunktion(c_statement, SIchtname, plus)
Else
Call Effiktivitaetstest(SIchtname, SIchtname + _minus_hlp,
SIchtname + _new, False) 'dennis
Call Effiktivitaetstest(SIchtname, SIchtname + _plus_hlp,
SIchtname, False)
End If
Die neu erstellte Methode Sub Aggregatfunktion() setzt dabei das in 5.3.2 beschriebene Prinzip zur Generierung der Sichten mit Aggregatfunktionen um. Zusätzlich
wird eine Methode eingefügt, die die Namen der kompilierten Sichten (nur der CQs,
also der Sichten der oberen Hierarchieebene) in eine Tabelle einträgt. Diese wird
von Java aus durch den CQ-Manager (vgl. Abschnitt 6.3.4) abgefragt werden, um
zu erfahren, welche Sichten zur Analyse verwendet werden können.
Zudem ist bei der Eingabe von Sichten zu beachten, dass keine Schlüsselwörter bei
den Attributen bzw. Correlation Names verwendet werden, ebenso keine Klammern,
Bindestriche, Punkte o.ä. Diese werden vom Compiler nicht korrekt interpretiert.
6.3.4 CQ-Manager
Die zu überwachenden Sichten müssen eingegeben und verwaltet werden können.
Dies ist realisiert in der zum Monitor gehörenden Komponente CQ-Manager (vgl.
Abbildung 6.6). Die kontinuierlichen Anfragen lassen sich nicht direkt über die JavaGUI eingeben. Statt dessen ist eine Eingabe direkt in MS Access erforderlich, um
92
Kapitel 6.
SIMON II
die anschlieÿende Kompilierung (vgl. Abschnitt 6.3.3) der Sichten vorzunehmen. Der
CQ-Manager verfügt über einen Button, mit dem sich MS Access önen lässt. Es
wird direkt das Startformular des Sichtencompilers aufgerufen. Die entsprechend
kompilierten Sichten werden in der Liste im linken Bereich des Fensters angezeigt.
Mit Hilfe des Buttons Liste aktualisieren kann man die Liste neu laden, wenn man
in Access Änderungen hinsichtlich der Monitoring-Sichten durchgeführt hat. Die
einzelnen Sichten in der Liste lassen sich durch Checkboxes an- und ausschalten.
Die Auswahl wird durch den Button Liste speichern bestätigt.
Abbildung 6.6: CQ-Manager
Durch die Buttons Start und Stop kann der Analyseprozess gestartet bzw. angehalten werden. Der Analyseprozess selbst besteht aus einem getakteten Abfragen der
Delta-Sichten der jeweils gewählten Monitoring-Sichten. Die Taktrate ist durch den
Benutzer einstellbar.
Jeweilige Änderungen hinsichtlich der Sichten werden durch das getaktete Abfragen
der entsprechenden Delta-Sichten verarbeitet. Das An- und Abwählen der einzelnen Monitoring-Sichten verlangt jedoch auch ein Verwalten der Analyseresultate
auf der Java-Seite. Es würde zwar ausreichen, in diesem Fall einfach die MonitoringSicht komplett abzufragen, aber im Falle einer Mehrfach-Markierung eines Objekts durch mehrere Sichten ist auf jeden Fall eine Verarbeitung und temporäre
6.3
Monitor
93
Speicherung im Java-Programm nötig. Gleiches gilt für die textuelle Anzeige der
Analyseresultate. Die Anbindung an VISMONET, innerhalb der die Analyseresultate weiterverarbeitet werden, wird in Abschnitt 6.5 beschrieben.
Die Einspeisung der Stromdaten in die Datenbank (TA-Generierung) und die Berechnung der kontinuierlichen Anfragen laufen synchronisiert ab. Innerhalb der Klasse CQManager.java läuft ein Thread ab, der die Analyse steuert. Dies ist im folgenden Codebeispiel zu sehen. Mit der vorgegebenen Aktualisierungsrate führt der
CQ-Manager die Analyse durch:
Zuerst wird veranlasst, dass der InputManager eine neue Transaktion von Stromdaten einliest und in der Datenbank speichert. Im nächsten Schritt werden die DeltaTabellen aller aktivierten Monitoring-Sichten berechnet (top-down Berechnung). Danach wird der Observer (das TableModell der im Fenster des CQ-Managers angezeigten Tabelle) benachrichtigt. Zuletzt werden am Ende des Analyseschrittes die
Einträge der Delta-Plus-ProtokollTabelle in die Protokoll-Tabelle verschoben.
public void run() {
Thread me = Thread.currentThread();
while (myThread == me) {
controller.getInputManager().collectProtokollEntries();
controller.getInputManager().writeProtokoll();
this.computeAnalysation();
this.setChanged();
this.notifyObservers(Analysation);
controller.getProtokollManager().moveProtokollEntries();
try{
myThread.sleep(threadSleep);
}
catch (InterruptedException e) {
break;
}
}
}
Der Unterschied zwischen top-down- und bottom-up-Berechnung wurde bereits in
4.3.3 diskutiert. Die in dieser Arbeit entwickelte Implementierung verwendet eine top-down-Berechnung. Der CQ-Manager fragt die jeweiligen Monitoring-Sichten
(die Sichten der oberen Hierarchieebene) getaktet ab. Aus folgenden Gründen wird
eine top-down-Berechnung verwendet:
Da die Einspeisung neuer Transaktionen von Stromdaten und die Durchführung der
Analyse synchronisiert abläuft, ist es hinsichtlich des Zeitpunktes, zu dem die Berechnung der zu überwachenden Sichten stattndet, unerheblich, ob eine top-down-
94
Kapitel 6.
SIMON II
oder eine bottom-up-Berechnung durchgeführt wird. Ein Analyse-Schritt wird jeweils durchgeführt, wenn eine neue Transaktion von Stromdaten in die Datenbank
gespeichert wurde.
Die Umsetzung der top-down-Berechnung gestaltet sich jedoch wesentlich einfacher.
Eine bottom-up-Berechnung ist nur bei Verwendung materialisierter Delta-Sichten
möglich. Da das Auslösen aktiver Reaktionen in Access nur schwer zu realisieren ist,
ist eine bottom-up-Berechnung nicht von Vorteil. Für eine bottom-up-Berechnung,
bei der keine externe Komponente die Berechnung steuert, ist ein solches aktives
verhalten jedoch notwendig. Zusätzlich wäre die Verknüpfung der dazu nötigen Erweiterungen in Form von VBA-Programmteilen, die die Materialisierung und Verwaltung der Sichten vornehmen, mit Java (bzw. dem CQ-Manager) nur schwer zu
implementieren. Eine top-down-Berechnung lässt sich auch ohne die Verwendung
materialisierter Sichten vornehmen.
6.4
VISMONET II
Die Visualisierungskomponente VISMONET wurde in Abschnitt 3.5 vorgestellt. Sie
ist verantwortlich für die Visualisierung des Netzwerkes sowie der mobilen Objekte
und stellt die Bewegung der Objekte anhand der von MOSIM generierten Positionsdaten grasch auf einer Bildschirmkarte dar. Folgende VISMONET-Tabellen
wurden in die Szenario-Datenbank integriert:
•
vmn_displayCType
(Darstellungstypen der Verbindungen)
•
vmn_displayNOType
(Darstellungstypen der Verbindungen)
•
vmn_ort_displayNOType
(Zuweisung eines Eintrags aus vmn_displayNOType zu jedem Ort)
•
vmn_verbindung_displayCType
(Zuweisung eines Eintrags aus vmn_displayCType zu jeder Verbindung)
Im folgenden werden einige konzeptuelle Erweiterungen von VISMONET vorgestellt
und im Zuge dessen einige Details der Implementierung beschrieben. Die Erweiterungen umfassen folgende Punkte:
•
Anpassung der Darstellung des Netzwerkes und der mobilen Objekte im Kontext von Geo-Koordinaten
•
Grasche Anzeige der benutzerdenierten MOSIM-Ereignisse
6.4
VISMONET II
95
•
Grasche Anzeige der Analyseergebnisse des Monitors
•
Anpassung der GUI bzw. Bedienung
Anpassung der Darstellung
Die Darstellung des Netzwerkes und der mobilen
Objekte innerhalb des Beisielszenarios ndet anhand von Geo-Koordinaten anstatt
von Pixelpositionen statt. Aus diesem Grund sind Anpassungen hinsichtlich der
Darstellung des Netzwerkes und der mobilen Objekte nötig. Beim Laden der Orte (in
der Methode getNodeObject() der Klasse DBReader.java) werden die Koordinaten
aus der Datenbank ausgelesen und transformiert, wie folgendes Code-Beispiel zeigt:
double xkoord = resultSet.getDouble(x);
double ykoord = resultSet.getDouble(y);
int xpos;
int ypos;
// Transformation der Koordinaten
double ytmp = Math.toDegrees(Math.cos(Math.toRadians(ykoord)));
double xtmp = ytmp / Math.toDegrees(Math.cos(Math.toRadians(47)));
double xposition = xtmp * ( xkoord -6 )*100 / 9;
double yposition = (90 -(ykoord*1.4-47))*100 / 8;
xpos = (int) xposition;
ypos = (int) yposition;
nodeObj = new NodeObject(id, nodeName, xpos, ypos);
Die Anzeige des Netzwerkes orientiert sich an den jeweiligen Maximal- und Minimalwerten der Längen- bzw. Breitengrade. Diese wird ebenfalls wie folgt beim Laden
der Orte ermittelt:
// Dimension des Netzwerks berechnen
if(xpos < network.getMinPosX()) {
network.setMinPosX(xpos);
}
if (xpos > network.getMaxPosX()) {
network.setMaxPosX(xpos);
}
if (ypos < network.getMinPosY()) {
network.setMinPosY(ypos);
}
if (ypos > network.getMaxPosY()) {
network.setMaxPosY(ypos);
}
96
Kapitel 6.
SIMON II
Die Gröÿe der Anzeigeäche wird jeweils um eine bestimmte Anzahl von Bildpunkten in jede Richtung erweitert (initialxoset, initialyoset), damit die Orte an den
Grenzen des Ausschnitts bzw. der Bildschirmkarte sichtbar sind. Es werden zwei
neue Attribute xoset und yoset eingeführt, die zum temporären Verschieben des
Netzwerkes auf der Anzeigeäche dienen. Durch die Methoden moveLeft(), moveRight(), moveUp(), moveDown() können diese Attribute verändert werden. Durch
diese Funktionalität ist es möglich, die Anzeige des Netzwerkes z.B. genau an eine
hinterlegte Karte anzupassen. Die Anzeige der Mobilen Objekte wird ebenfalls an
die Verschiebung des Netzwerks angepasst.
Ereignisanzeige
In Abschnitt 6.2 wurde eine Erweiterung von MOSIM hinsicht-
lich der benutzerdenierten Ereignisse aufgezeigt. Somit muss auf der Seite von
VISMONET ebenfalls eine Erweiterung in Form einer geeigneten Anzeige dieser
Ereignisse vorgenommen werden. Es ist dazu eine Verknüpfung der Verbindungen
von MOSIM und VISMONET nötig, sodass die Attribute (z.B. gesperrt oder maxGeschwindigkeit) der Verbindungsobjekte in MOSIM durch die Verbindungsobjekte
in VISMONET zugreifbar sind. Dadurch wird die Anzeige der Ereingisse bzw. der
geänderten Attribute der Verbindungen von MOSIM erst möglich. Die genaue Anbindung von MOSIM an VISMONET wird in Abschnitt 6.5 beschrieben. Folgendes
Codebeispiel zeigt, wie innerhalb der Methode drawNetworkDisplay() der Klasse
DrawingPane2D.java ein highlichting der Verbindungen durchgeführt wird:
Vector connections = controller.getSimulatorManager().getVerbindungen();
Iterator iter = connections.iterator();
while (iter.hasNext()) {
Verbindung v = (Verbindung) iter.next();
if (v.getName().equals(edgeObj.getName())) {
if (v.isGesperrt()) {
networkDisplayLayerGraphics.setColor(Color.RED);
}
else if (v.getMaxGeschwindigkeit() < v.getTyp().getMaxGeschwindigkeit()) {
networkDisplayLayerGraphics.setColor(Color.ORANGE);
}
else {
networkDisplayLayerGraphics.setColor(Color.BLACK);
}
}
}
6.4
VISMONET II
Analyse-Anzeige
97
Zusätzlich muss eine grasche Darstellung der Analyseergeb-
nisse des Monitors entworfen werden. Die textuelle Darstellung der Analyseergebnisse wird innerhalb des CQ-Managers (vgl. Abschnitt 6.3.4) vorgenommen. Die genaue
Anbindung des Monitors an VISMONET wird in Abschnitt 6.5 beschrieben. Die grasche Anzeige läuft wie folgt ab: Die IDs der mobilen Objekte, die in der Antwort
auf eine zu überwachende Anfrage auftreten, werden in einem Vector zusammengefasst. Die im folgenden Codebeispiel aufgezeigte Methode gleicht die IDs mit denen
der im System bendlichen mobilen Objekte ab und führt ein highlighting durch,
indem die Farbe der betroenen Objekte verändert wird.
public void setAnalysationResult(int type, Vector moIDs) {
while (!moIDs.isEmpty()) {
String mobilObjektID = (String) moIDs.firstElement();
Iterator keyIter = mobileObjects.getMobileObjects().keySet().iterator();
while (keyIter.hasNext()) {
MobileObject dobject = (MobileObject) mobileObjects
.getMobileObjects().get(keyIter.next());
if (Integer.toString(dobject.getMOID()).equals(mobilObjektID)) {
if (type == controller.getDBAnalyser().deltaPlus) {
// Delta-Plus-Eintrag -> highlighting
dobject.setActualMOColor(Color.RED);
dobject.setImgChanged(true);
}
else if (type == controller.getDBAnalyser().deltaMinus) {
// Delta-Minus-Eintrag -> highlichting aufheben
dobject.resetMOColor();
dobject.setImgChanged(true);
}
}
}
}
}
moIDs.removeElement(moIDs.firstElement());
Anpassung der GUI bzw. Bedienung
Die Programmoberäche von VISMO-
NET wurde überarbeitet. Mit Hilfe der Buttons Start, Stop und dem Slider für
die Aktualisierungsrate kann die Anzeige der mobilen Objekte gesteuert werden.
Der Button Monitor (name noch ändern!!!) önet das Fenster zur textuellen Anzeige der von MOSIM generierten Positionsdaten. Die Anzeigeäche kann mit einem
98
Kapitel 6.
SIMON II
Bild hinterlegt werden (Button Bild). Mit den Buttons Zoom +, Zoom - sowie
der Auswahl-Box kann der angezeigte Bildbereich verändert werden. Durch die Buttons links, rechts+, hoch und runter kann das Netzwerk in alle Richtungen
verschoben werden. Dies ist z.B. notwendig, um die Anzeige des Netzwerkes mit
einer hinterlegten Karte zu synchronisieren.
Abbildung 6.7: neue VISMONET GUI
6.5
Schnittstellen
Im folgenden wird der Datenuss zwischen den einzelnen Komponenten erläutert.
Abbildung 6.8 zeigt noch einmal kurz die Architektur des Systems auf. Im Folgenden wird die Anbindung von MOSIM an VISMONET und den Monitor sowie des
Monitors an VISMONET beschrieben.
MOSIM - VISMONET
In den Komponenten MOSIM und VISMONET gibt
es jeweils eigene Java-Objekte. Die mobilen Objekte werden bei VISMONET durch
6.5
Schnittstellen
99
Abbildung 6.8: Architektur
eine Hashmap (MobileObjects.java) verwaltet, die Objekte sind jeweils über ihre ID
zugreifbar. Bei MOSIM sind die mobilen Objekte innerhalb eines Vektors (Klasse
Szenario.java) durch den Index zugreifbar. Beim Laden der mobilen Objekte in VISMONET (innerhalb der Klasse DBReader.java) werden aus diesem Grund zusätzlich
zur ID auch der Index, über den das entsprechende Objekt in MOSIM zugreifbar
ist, gespeichert (moKey).
Abbildung 6.9: Datenuss MOSIM - VISMONET
Der Datenuss zwischen MOSIM und VISMONET ist in Abbildung 6.9 dargestellt.
Durch die Positionsaktualisierungsroutine werden innerhalb von MOSIM die Positionen (Variable position.strecke) der mobilen Objekte kontinuierlich verändert.
Die Klasse SimulatorManager stellt die Funktionen getAktVerbindungID() und getStrecke() bereit. Über diese gelangen die geänderten Daten zu dem entsprechenden
mobilen Objekt in VISMONET.
Es liegt eine Art automatischer Filterfunktion für die Stromdaten vor. Wenn Bildaktualisierungsrate von VISMONET geringer ist als die Positionsaktualisierungsrate
von MOSIM, werden die Stromdaten, die zwischen zwei Bildaktualisierungen in die
MOSIM-internen Variablen gespeichert wurden, verworfen.
Zusätzlich zu den Positionsdaten der mobilen Objekte muss ein Datenaustausch
100
Kapitel 6.
SIMON II
der Zustandsdaten hinsichtlich der Verbindungen vorgenommen werden. Durch die
Ereignisroutinen werden innerhalb von MOSIM die Zustandsparameter (z.B. gesperrt, geringere Geschwindigkeit) der Verbindungen geändert. Beim Zeichnen des
Netzwerks wird beim zeichnen der Verbindungen auf einen Vector, der die MOSIMVerbindungen enthält, über den Simulatormanager zugegrien und die Parameter
abgefragt. Dadurch ist es möglich, die in MOSIM aufgetretenen Ereignisse (d.h. die
Aufgetretenen Änderungen hinsichtlich der Zustandsparameter der Verbindungen)
zu visualisieren.
MOSIM - MONITOR
Die Daten, die der Simulator generiert, werden nicht
mehr (wie vorher per push) in der DB gespeichert. Sie werden nur von auÿen zugreifbar gemacht, um durch den InputManager (per pull) ausgelesen zu werden.
Abbildung 6.10 zeigt den Datenuss zwischen MOSIM und dem Monitor.
Abbildung 6.10: Datenuss MOSIM - Monitor
Durch die Positionsaktualisierungsroutine werden innerhalb von MOSIM die Positionen der mobilen Objekte kontinuierlich verändert. Zugleich wird ein neuer Protokolleintrag für jedes mobile Objekt erzeugt. Durch die Methode collectProtokollEntries() in InputManager.java werden die jeweils aktuellen Protokolldaten der mobilen
Objekte aus MOSIM (pull) ausgelesen .
MONITOR - VISMONET
Abbildung 6.11 zeigt den Datenuss zwischen dem
Monitor und VISMONET. Der CQ-Manager berechnet die Antwortmengen auf die
vom Benutzer spezizierten kontinuierlichen Anfragen. Diese Stellen die Analyseergebnisse dar. Es wird ein Vector mit den betroenen Objekten, die mit den jeweiligen Antwortmengen korrelieren, in einem Vector zusammengestellt. Jeder Eintrag
enthält den Namen der entsprechenden Anfrage, den Typ (Delta-Plus oder DeltaMinus) sowie die ID des mobilen Objekts. Der Vector wird an VISMONET übertragen. Innerhalb der Klasse DrawingPane.java wird der Vector verwendet, um die
betroenen mobilen Objekte entsprechend des Analyseresultates zu highlighten bzw.
das highlighting zu entfernen.
6.6
Beispiel-Szenario (ICE-Verkehr)
Abbildung 6.11: Datenuss Monitor - VISMONET
6.6
Beispiel-Szenario (ICE-Verkehr)
101
Kapitel 7
Zusammenfassung und Ausblick
102
Literaturverzeichnis
[ABW02]
A. Arasu, S. Babu, J. Widom: An Abstract Semantics and Concrete
Language for Continuous Queries over Streams and Relations. Stanford
University Technical Report 2002-57, November 2002.
[BBD+02]
B. Babcock, S. Babu, M. Datar, R. Motwani, J. Widom: Models and
Issues in Data Streams. In Proc. ACM SIGACT-SIGMOD Symp. on
Principles of Database Systems, 2002, pp. 1-16.
[Ber05]
O. Berman:
Entwurf und Realisierung eines Tools zur Spezialisie-
rung von SQL-Sichten.
Diplomarbeit, Rheinische Friedrich-Wilhelm-
Universität Bonn, Institut für Informatik III, Juni 2005.
[BGS00]
P. Bonnet, J. Gehrke, P. Seshadri:
Querying the PhysicalWorld.
In
IEEE Personal Communications, 7(5):10-15, Oct. 2000.
[BGS01]
P. Bonnet, J. Gehrke, P. Seshadri: Towards Sensor Database Systems.
In Proc. 2nd Int. Conf. on Mobile Data Management, 2001, pages 3-14.
[BMUS86]
F. Bancilhon, D. Maier, J.Ullmann, Y. Sagiv:
Magic Sets and other
strange ways to implement logic programs. 1986.
[Bri02]
T. Brinkho:
A Framework for Generating Network-Based Moving
Objects. GeoInformatica 6 (2):153-180, 2002.
[Bua03]
R. Buamar:
Entwurf und Implementierung eines Simulators für mo-
bile Objekte. Diplomarbeit, Rheinische Friedrich-Wilhelm-Universität
Bonn, Institut für Informatik III, September 2003.
[CBB+03]
M. Cherniack, H. Balakrishnan, M. Balazinska, D. Carney, U. Cetintemel, Y. Xing, S. Zdonik: Scalable Distributed Stream Processing. In
Proc. 1st Biennial Conf. on Innovative Data Syst. Res, 2003.
[CCC+02]
D. Carney, U. Cetinternel, M. Cherniack, C. Convey, S. Lee, G. Seidman, M. Stonebraker, N. Tatbul, S. Zdonik: Monitoring streams - A
New Class of Data Management Applications. In Proc. 28th Int. Conf.
on Very Large Data Bases, 2002, pp. 215-226.
103
104
[CCD+03]
Literaturverzeichnis
S. Chandrasekaran, O. Cooper, A. Deshpande, M. J. Franklin, J. M.
Hellerstein, W. Hong, S. Krishnamurthy, S. Madden, V. Raman, F.
Reiss, M. Shah: TelegraphCQ: Continuous Dataow Processing for an
Uncertain World. In Proc. 1st Biennial Conf. on Innovative Data Syst.
Res, 2003, pp. 269-280.
[CDTW00]
J. Chen, D. DeWitt, F. Tian, Y. Wang: NiagaraCQ: A Scalable Continuous Query System for Internet Databases. In Proc. ACM Int. Conf.
on Management of Data, 2000, pp. 379-390.
[CFP+00]
C. Cortes, K. Fisher, D. Pregibon, A. Rogers, F. Smith: Hancock: A
Language for Extracting Signatures from Data Streams. In Proc. 6th
ACM SIGKDD Int. Conf. on Knowledge Discovery and Data Mining,
2000, pp. 9-17.
[CGJ+02]
C. Cranor, Y. Gao, T. Johnson, V. Shkapenyuk, O. Spatscheck: GigaScope: High Performance Network Monitoring with an SQL Interface.
In Proc. ACM Int. Conf. on Management of Data, 2002, p. 623.
[Cha92]
S. Chakravarthy: Architectures and Monitoring Techniques for Active
Databases: An Evaluation. XXXXXXXXXXXXXXXXXXXXX 1992.
[CHKS03]
M.
Cammert,
tenströme
C.
im
Heinz,
J.
Krämer,
Kontext
des
B.
Seeger:
Da-
Verkehrsmanagements.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 2003.
[CHKS04]
M.
Cammert,
ger:
C.
Heinz,
J.
Anfrageverarbeitung
Krämer,
auf
B.
See-
Datenströmen.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 2004.
[CU04]
C. Ullenboom: Java ist auch eine Insel. Galileo Computing, Bonn, 4.
aktualisierte und erweiterte Auage, 2004.
[Gri97]
U. Griefahn: Reactive Model Computation - A Uniform Approach to
the Implementation of Deductive Databases. Dissertation, Institut für
Informatik III, Rheinische Friedrich-Wilhelm-Universität Bonn, 1997.
[GIL]
[GKMS01]
Wikipedia:
A.
C.
http://www.gi-ev.de/service/informatiklexikon/
Gilbert,
Y.
Kotidis,
S.
Muthukrishnan,
M.
J.
Strauss:
QuickSAND: Quick Summary and Analysis of Network Data. DIMACS
Technical Report 2001-43, Dec. 2001.
[GL95]
T. Grin, L. Libkin: Incremental Maintenance of Views with Duplikates. 1995
[GMS93]
A. Gupta, I.S. Mumick, V.S. Subrahmanian: Maintaining Views Incrementally. Proc. SIGMOD 1993, Washington/DC, USA, S. 157-166.
Literaturverzeichnis
[GÖ03]
105
L.Golab, M.T.Özsu: Data Stream Management Issues - A Survey. ACM
SIGMOD Record Volume 32, Issue 2, pp. 5-14, 2003
[HLP]
Microsoft Access Hilfe
[HRR99]
M. Henzinger, P. Raghavan, S. Rajagopalan: Computing on Data Streams. In DIMACS series in Discrete Mathematics and Theoretical Computer Science, vol. 50, pp. 107-118, 1999.
[KE04]
A. Kemper, A. Eickler: Datenbanksysteme. Oldenbourg Verlag, München, 5. Auage, 2004.
[LPT99]
L. Liu, C. Pu, W. Tang: Continual Queries for Internet- Scale EventDriven Information Delivery.
In IEEE Trans. Knowledge and Data
Eng., 11(4): 610-628, 1999.
[Man94]
R. Manthey: Reections on Some Fundamental Issues of Rule-Based
Incremental Update Propagation. Proc. DAISD 1994, Aiguablara, Spanien, Report de recerca LSI/94-28-R, Universität Barcelona, Spanien,
S. 255-276.
[Man04]
R. Manthey: Deduktive Datenbanken SS04. Skript zur Vorlesung, Rheinische Friedrich-Wilhelm-Universität Bonn, Institut für Informatik III,
2004.
[MF02]
S. Madden, M. J. Franklin: Fjording the Stream: An Architecture for
Queries Over Streaming Sensor Data. In Proc. 18th Int. Conf. on Data
Engineering, 2002, pp. 555-566.
[MS04]
R. Manthey, O. Speidel: Simulation und Monitoring mobiler Objekte
in Verkehrsnetzen. Proc. 5. Geoinformatik-Tage, Münster, 2004.
[MWA+03]
R. Motwani, J. Widom, A. Arasu, B. Babcock, S. Babu, M. Datar, G.
Manku, C. Olston, J. Rosenstein, R. Varma: Query Processing, Approximation, and Resource Management in a Data Stream Management
System. In Proc. 1st Biennial Conf. on Innovative Data Syst. Res, pp.
245-256, 2003.
[Pat98]
N.W. Paton, O. Díaz:
Active Rules in Database Systems.
Springer,
1998, S. 197-220
[PD99]
N.W. Paton, O. Díaz:
Active database systems.
ACM Computing
Surveys (CSUR) Volume 31, Issue 1, pp. 63-103, 1999.
[PGS01]
P. Bonnet, J. Gehrke, P. Seshadri: Towards Sensor Database Systems.
In Proc. 2nd Int. Conf. on Mobile Data Management, 2001, pages 3-14.
106
[Pie01]
Literaturverzeichnis
B. Pieper: Inkrementelle Integritätsprüfung und Sichtenaktualisierung
in SQL. Dissertation, Rheinische Friedrich-Wilhelm-Universität Bonn,
2001.
[PDoc]
B.
Pieper:
on.
PostgreSQL
The
PostgreSQL
Global
8.1.2
Documentati-
Development
Group
http://www.postgresql.org/docs/8.1/static/index.html
[Roh05]
E. Rohde: Entwurf und Realisierung einer Datenbank zur Verwaltung
von Netz- und Fahrplandaten im Bahnverkehr. Diplomarbeit, Rheinische Friedrich-Wilhelm-Universität Bonn, Institut für Informatik III,
Mai 2005.
[SCZ05]
M. Stonebraker, U. Çetintemel, S. Zdonik: The 8 requirements of realtime stream processing. ACM SIGMOD Record Volume 34, Issue 4,
Pages 42-47, December 2005
[SH98]
M. Sullivan, A. Heybey: Tribeca: A System for Managing Large Databases of Network Trac. In Proc. USENIX Annual Technical Conf. ,
1998.
[SKdM92]
E. Simon, J. Kiernan, C. de Maindreville:
Implementing high-level
active rules on top of relational databases. In Proceedings of the 18th
Conference on Very Large Databases, Morgan Kaufman pubs. (Los
Altos CA), Vancouver, pages 315-326, 1992
[TGNO92]
D. Terry, D. Goldberg, D. Nichols, and B. Oki:
Continuous queries
over append-only databases. In Proc. of the 1992 ACM SIGMOD Intl.
Conf. on Management of Data, pages 321330, June 1992.
[Ull89]
J.D. Ullman:
Principles of Database and Knowledge-Base Systems.
Volume I and II, Computer Science Press, Rockville/MA, USA, 1989,
1990.
[vEK76]
M.H. van Emden, R.A. Kowalski: The Semantics of Predicate Logic as
Progamming Language. Journal of the ACM 23(4), S. 733-742, 1976.
[WC96]
J. Widom, S. Ceri: Active Database Systems. Morgan Kaufman Publ.,
1996, S. 233-258
http://www.microsoft.de
[WWW]
Microsoft:
[WIKI]
Wikipedia:
[Yer04]
N. Yerlikaya:
http://de.wikipedia.org
Visualisierung mobiler Objekte auf Netzwerken.
Di-
plomarbeit, Rheinische Friedrich-Wilhelm-Universität Bonn, Institut
für Informatik III, April 2004.
Literaturverzeichnis
[ZS02]
107
Y. Zhu, D. Shasha: StatStream: Statistical Monitoring of Thousands
of Data Streams in Real Time. In Proc. 28th Int. Conf. on Very Large
Data Bases, 2002, pp. 358-369.
Anhang