Eine Realisierung des ” Game of Life“ als - IDB

Rheinische Friedrich-Wilhelms-Universität Bonn
Institut für Informatik III
Diplomarbeit
Eine Realisierung des
Game of Life“ als datenbankbasiertes
”
Monitoringsystem
von
Torsten Schoppe
Betreuer: Prof. Dr. Rainer Manthey
14. April 2008
ii
iv
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung
anderer als der angegebenen Hilfsmittel angefertigt habe.
..............................
(Torsten Frank Schoppe)
Bonn, den 26.März 2008
v
vi
Inhaltsverzeichnis
1 Einleitung
1
2 Grundlagen aus der Informatik
2.1 Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Datenbankentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Konzeptueller Datenbankentwurf mit dem ER-Modell . . . . .
2.2.2 Logischer Datenbankentwurf mit dem relationalen Datenmodell
2.3 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Datendefinition . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Datenmanipulation . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Grundlegende Konzepte . . . . . . . . . . . . . . . . . . . . . .
2.4.2 JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3 Threads in Java . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Grundlagen zellulärer Automaten
3.1 Geschichte und wissenschaftlicher Kontext . . . . . . . . .
3.2 Formale Definition zellulärer Automaten . . . . . . . . . .
3.3 Game of Life . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Formale Definition des Game of Life“ . . . . . . .
”
3.3.2 Komplexe Objekte und Anfangskonstellationen des
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
7
7
11
12
13
14
16
16
17
18
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
Game of Life“
”
.
.
.
.
.
21
22
27
31
32
35
.
.
.
.
.
.
.
.
.
39
39
39
45
48
48
50
58
58
62
.
.
.
.
.
65
65
68
71
72
73
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
4.1 Datenbankentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Konzeptueller Datenbankentwurf . . . . . . . . . . . . . . . . . . .
4.1.2 Logischer Datenbankentwurf . . . . . . . . . . . . . . . . . . . . .
4.2 Konzeption von Simulations- und Analyseprozessen . . . . . . . . . . . . .
4.2.1 Simulationsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Analyseprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Erweiterung des Entwurfs um Visualisierungskonzepte . . . . . . . . . . .
4.3.1 Prinzip des Visualisierungaspektes . . . . . . . . . . . . . . . . . .
4.3.2 Erweiterung des Datenbankentwurfs . . . . . . . . . . . . . . . . .
5 Architektur und Funktionalität des Life-Monitoringsystems
5.1 Architektur des Gesamtsystems . . . . . . . . . . . . . .
5.2 Interaktion der globalen Komponenten . . . . . . . . . .
5.3 Struktur und Funktionalität des GUI . . . . . . . . . . .
5.3.1 Simulationssteuerung . . . . . . . . . . . . . . . .
5.3.2 Analyse-Steuerung . . . . . . . . . . . . . . . . .
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Ausgewählte Aspekte der Implementierung
6.1 Realisierung der Simulation des GOL . .
6.2 Realisierung der Clusterbestimmung . .
6.2.1 Preprocessor . . . . . . . . . . .
6.2.2 Bestimmung der Zellenpfade . .
6.2.3 Ausnahmebehandlung . . . . . .
6.3 Realisierung der Evolutionsumgebung .
7 Zusammenfassung und Ausblick
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
77
77
82
85
86
89
91
97
Literaturverzeichnis
101
viii
1 Einleitung
Heute werden zunehmend rechnergestützte Systeme eingesetzt, die gezielt zu aktuellen
Abläufen eine Vielzahl von Daten erfassen, die teilweise nur kurzzeitig Beachtung finden. Bei solchen Systeme werden oft Sensornetze verwendet, die kontinuierliche Datenströme mit hoher Frequenz erzeugen. Solche Systeme werden zum Beispiel im Verkehrswesen eingesetzt, etwa zur Registrierung des Verkehrsaufkommens, um Staus zu erkennen,
beim LKW-Mautsystem von Toll Collect oder auch zur Steuerung des Schienenverkehrs.
Bei kontinuierlichen Systemen, wie der Verkehrsüberwachung, wird der zu betrachtende
Raum für die Erfassung diskretisiert und die sich ständig ändernden Abläufe in diskreten
Zeitschritten erfasst. Es handelt sich dabei oft um große Datenmengen, die einem kontinuierlichen Wandel unterliegen. Die erhaltenen Messdatenströme sind nutzlos, wenn sie
nicht beobachtet und nach spezifischen Kriterien ausgewertet werden. Die automatische
Erfassung von Autokennzeichen ist ein aktuelles Beispiel für eine derartige automatisierte
Datenerhebung. Da die erfassten Nummerschilder aus rechtlichen Gründen nicht auf Vorrat gespeichert werden dürfen, muss eine zeitnahe Verarbeitung dieser Daten durchgeführt
werden.
Eine kostengünstige und effiziente Auswertung von Sensordatenströmen ist also gefragt, im
Besonderen wenn Anfragen nur durch komplexe Analysen zu beantworten sind. Es besteht
das Interesse, diese Aufgaben nicht Menschen zu übertragen, sondern sie automatisch,
computergesteuert durchzuführen. Um den Herausforderungen einer zeitnahen Auswertung solcher Datenströme gerecht zu werden, werden heutzutage in zunehmendem Maße so
genannte Monitoringsysteme implementiert. Solche Systeme können die Überwachung von
Messdatenströme hinsichtlich der Suche nach spezifisch Mustern übernehmen. Die Analysefunktionen eines Monitoringsystems werden bei einer hohen Fluktuation der Daten
nicht bei jeder Änderung angewendet, sondern in großen Abständen (Zeitfenstern) durchgeführt. Die Ergebnisse einer Auswertung können dabei direkt erfolgen oder nach einer
bestimmten zeitlichen Distanz. Neben der Beobachtung und der Auswertung von Daten
könnten auch noch Steuerungssysteme einem Monitoringsystem nachgeschaltet werden,
die beim Eintreten bestimmter Zustände aktiv eingreifen, wie zum Beispiel der Steuerung
einer Ampel.
In dieser Diplomarbeit wird prototypisch evaluiert, inwieweit es vorteilhaft ist, ein Monitoringsystem datenbankbasiert zu implementieren. Die Analysen und Anfrageauswertung
werden dabei deklarativ mit SQL-Anfragen umgesetzt. Eine datenbankbasierte Umsetzung
bietet im Vergleich zu einem auf ein Datenbanksystem aufgesetzten Programm verschiedene Vorteile. In einem externen Programm, das mit dem Datenbanksystem interagiert,
1
1 Einleitung
müssten die relevanten Daten innerhalb eines kurzen Zeitfensters sequentiell in ein internes
Format transformiert und eventuell nachfolgend in der Datenbank modifiziert werden. Da
externe Programme nicht wie ein Datenbanksystem spezialisiert sind, müssen zusätzlich
explizit Funktionen realisiert werden, die effizient mit strukturierten Daten hantieren, auf
diese zugreifen und diese modifizieren. Im Gegensatz zu solchen prozeduralen Umsetzung
kann bei einem datenbankbasierten Verfahren direkt mit den intern vorliegenden Daten
gearbeitet werden. Das Datenbankmanagementsystem (DBMS) ist dabei spezifisch für die
Datenstruktur ausgelegt und bietet die benötigten darauf spezialisierten Funktionalitäten
zur Verwaltung und Bearbeitung der Daten. Im Rahmen dieser Diplomarbeit wird untersucht, inwieweit komplexe Analysen mittels Sichten in reinem SQL realisiert werden
können. Von Interesse ist dabei, ob SQL (hier insbesondere der verwendete Dialekt JetSQL des zugrundeliegenden, sehr einfachen relationalen DBMS MS Access) als Konkur”
rent“ einer konventionellen Programmiersprache zumindest für bestimmte Kernaufgaben
der Datenstromanalyse tauglich ist. Ziel ist es zu zeigen, dass eingesetzte Datenbanktechnologie bei der Umsetzung eines regelbasierten Monitoringsystems in Konkurrenz zu
bestehenden Software-Systemen bestehen kann. Die Analyse von Datenströmen ist ein
sehr aktives, aktuelles Forschungsgebiet der Informatik. Im Vergleich zu herkömmlichen
Datenbankanwendungen werden nicht stabile Daten mit variierenden Anfragen ausgewertet, sondern variierende Daten mit stabilen, kontinuierlich angewendeten Anfragen.
Zu Testzwecken wird in dieser Arbeit eine Versuchsumgebung auf der Basis eines zellulären
Automaten konzipiert. Diese Automatenklasse wurden von dem Mathematiker John von
Neumann und seinem damaligem Kollegen Stanislaw Marcin Ulam in den 40er Jahren
entwickelt. Ein zellulärer Automat besteht aus einer Anzahl identischer Zellen, für die
uniforme Regeln gleichzeitig in diskreten Zeitschritten angewendet werden. Die Zustände
der Zellen ergeben sich in Bezug zu ihrer wohldefinierten Nachbarschaft und den darauf
angewendeten Regeln. Der Physiker Stephen Wolfram greift diese Automaten in dem Buch
A New Kind of Science“ [Wolfram1983] auf und schlägt eine induktive Herangehensweise
”
bei der Untersuchung von dynamischen (zeitbezogenen) Systemen vor. Das bedeutet, dass
man Systeme mit simplen“ Regeln verwendet, diese mittels Simulation durchspielt und
”
auf komplexe Verhaltensweisen überprüft. Zelluläre Automaten bieten dabei eine elegante Methode, um erstellte Modelle von spezifischen dynamischen Systemen simulieren zu
lassen. Diese ermöglichen damit eine hervorragende simulierte Testumgebung, für automatisches Monitoring, da Parameter und Gesetzmäßigkeiten beliebig ausgewählt werden
können und die Generationen in diskreten Zeitschritten berechnet werden. Die durchgeführten Simulationen weisen einen großen Bezug zur Realität auf ( artifical life“).
”
Heutzutage kommen zelluläre Automaten in vielen Gebieten zum Einsatz. Beim Verkehrswesen und der Simulation von Verkehrsszenarien wird teilweise mit einem probabilistischen
zellulären Automaten ein mikroskopisches Modell aufgestellt, womit individuelles Verhalten der Verkehrsteilnehmer imitiert und somit jedes einzelne Fahrzeug simuliert wird, was
zu einer erhöhten Wirklichkeitsnähe führt. Dieses Prinzip wird u. a. genutzt bei der Unter-
2
suchung des Kaufverhaltens von Supermarktkunden, einer Fluchtwege-Analyse bei Großveranstaltungen, bei der Simulation von Waldbränden, beim Verhalten von Gasteilchen
oder zur Darstellung chemischer Oszillationen. Das Spektrum potentieller Anwendungen
umfasst Gebiete der Physik, Biologie, Mathematik, Chemie, Informatik u.v.m. (siehe u.a.
[Milbradt]).
Das Game of Life“, oft auch nur Life“ genannt, wurde 1970 von dem Mathematiker
”
”
John Horton Conway publiziert und erlangte auch außerhalb der Mathematik und Informatik Berühmtheit. Es handelt sich dabei um ein Simulationsspiel und ist eines der
populärsten Umsetzungen eines zellulären Automaten. Diesem zellulären Automaten ist
ein 2-dimensionaler Raum aus gleichmäßig verteilten Zellen zugeordnet, dessen Zellen entweder lebendig oder tot sind. Die Faszination für das Spiel ergibt sich aus der großen
Einfachheit der Regeln für Sterben, Geburt und Überleben der Zellen und der daraus entstehenden Komplexität des Systems, in dem sich die Zellen ausbreiten, austauschen und
sich Zellkonstellationen selbst reproduzieren können. Durch die sorgsam ausgewählten Regeln und die Wechselwirkungen der Zellen untereinander entsteht eine nicht vorhersehbare
Entwicklung und Interaktion. Der Name dieses spezifischen zellulären Automaten wurde
in Analogie zum realen Leben gewählt, da das Game of Life“ als theoretisches Evolutions”
modell dienen kann. Die Zellen und deren evolutionäre Entwicklung ahmen Eigenschaften
des realen Lebens nach. Einzelne interessante Zellkonstellationen mit speziellen Eigenschaften werden intuitiv als Objekte bezeichnet. Sogar eine Turingmaschine lässt sich mit
dem Game of Life“ simulieren.
”
Die Zellen, insbesondere die Erfassung der sich bildenden Zellkonstellationen, stehen im
Mittelpunkt des Monitoringsystems. Zellkonstellationen werden dabei als Cluster erfasst
und nach spezifischen Merkmalen und Verhaltensweisen hin untersucht und klassifiziert.
Bei der räumlichen-zeitlichen Ausbreitung dieser Cluster werden zudem spezifische Ereignisse automatisch entdeckt, wie etwas das Kollidieren von mobilen Clustern oder das
Entstehen von Oszillationen. Durch die komplexen Eigenschaften der Clusterfamilie ist
ein breites Spektrum für derartige Überwachungen geboten. Für diese prototypische Realisierung wird die Simulation des GOL und die darauf ausgerichtete Überwachung datenbankbasiert implementiert. Es wird zwar hybrid mit Java und SQL programmiert, jedoch
dient das in Java implementierte Programm nur zur Synchronisation der SQL-Befehle,
zur graphischen Darstellung der Ergebnisse und zur Unterstützung der datenbankbasierten Operationen, wo es unüberwindliche Beschränkungen geben sollte.
Der Aufbau dieser Diplomarbeit sieht wie folgt aus: Das 2. Kapitel beschäftigt sich
zunächst mit den theoretischen Grundlagen der Informatik, auf die sich im weiteren
Verlauf der Diplomarbeit bezogen wird. Im Mittelpunkt dieses Kapitels steht der Datenbankentwurf. Kapitel 3 erläutert ausführlich die Geschichte und die wissenschaftlichen Hintergründe von zellulären Automaten. Des Weiteren wird die formale Definition
dieser Automaten und im speziellen die des GOL aufgezeigt gefolgt von Beispielen in-
3
1 Einleitung
teressanter Objekte dieses Spiels. In Kapitel 4 wird mit dem in Kapitel 2 vorgestellten
Entity-Relationship-Modell der konzeptuelle Entwurf für die Objekte des GOL und den
datenbankbasierten Analysen durchgeführt. Darauf aufbauend folgt der logische Entwurf
anhand des relationalen Datenmodells. Die Konzeption der Simulations- und Analyseprozesse wird diskutiert und Algorithmen erarbeitet. Die Clusterbestimmung nimmt eine
Schlüsselrolle bei den Analysen ein. Die Struktur des Gesamtsystems, sowie die Interaktion ihrer einzelnen Komponenten und die Funktionalität des Monitoringsystems werden
in Kapitel 5 vorgestellt. Abschließend werden im 6. Kapitel drei ausgewählte Aspekte der
Implementierung und ihre detaillierte datenbankbasierte Umsetzung diskutiert, welche die
vielfältigen Möglichkeiten des datenbankbasierten Verfahrens erkennen lassen.
4
2 Grundlagen aus der Informatik
In diesem Kapitel werden die Grundlagen zu denjenigen Gebieten der Informatik erläutert,
auf die im späteren Verlauf Bezug genommen wird. Kapitel 2.1 legt den Aufbau und die
Konzeption von Datenbanksystemen dar. Abschnitt 2.2 beschäftigt sich den verschiedenen
Phasen des Datenbankentwurfs. Der Abschnitt 2.3 widmet sich der Datenbanksprache SQL
für relationale Datenbanksysteme. In 2.4 folgt sodann die Erörterung der Konzepte der
Programmiersprache Java und die verwendete Schnittstelle zwischen Java-Programmen
und Datenbankmanagementsystemen. Da die Themen recht umfangreich sind, wird nur
das Wesentliche kurz erläutert. Die Darstellung orientiert sich hauptsächlich an den Vorlesungen von [Manthey2004] und [Bode2007] sowie dem Buch [KemEik2004].
2.1 Datenbanksysteme
Ein Datenbanksystem (DBS) setzt sich aus einem Datenbankmanagementsystem
(DBMS) und einer Anzahl von Datenbanken (DB) zusammen.
DBS = DBMS + n ∗ DB
Das Datenbankmanagementsystem bietet anwendungsunabhängige Funktionen an, die
dem Anwendungsprogrammierer eine Vielzahl von Aufgaben abnehmen, welche er sonst in
jedem Programm neu zu implementieren hätte. Dem Benutzer werden i.a. zwei Schnittstellen zur Kommunikation mit dem DBMS angeboten. Zum einen kann über ein Terminal mit
dem DBMS kommuniziert werden, zum anderen gibt es die Möglichkeit über höhere Programmiersprachen eingebettete Kommandos zu übermitteln. Aufgaben eines DBMS sind
u. a. die Schemaverwaltung, Anfragebearbeitung, Speicherverwaltung sowie das Transaktionsmanagement, worunter die Überwachung der Integritätsbedingungen, Fehlerbehandlung, Synchronisation und Zugriffskontrolle fällt.
Ein Datenmodell bestimmt die Konzeption der Modellierungsstruktur der Daten und
ihrer Beziehungen zueinander. Dabei werden generische Strukturen und Operatoren festgelegt, die zur Modellierung eines Abbildes der realen Welt verwendet werden. Zu dem
Datenmodell gehören zwei Teilsprachen, die Datendefinitionssprache (Data Definition
Language,DDL) und die Datenmanipulationssprache (Data Manipulation Language,
DML). Die DDL dient dazu, das Datenbankschema nach dem vorliegenden Datenmodell
5
2 Grundlagen aus der Informatik
zu konzipieren. Dieses Datenbankschema bildet eine Struktur, also eine logische Unterteilung der abgelegten Daten, welche durch eine Menge von Metadaten gekennzeichnet
ist. Diese logische Abstraktion bedeutet jedoch nicht, dass die Daten in der Form auch
physisch auf dem Hintergrundspeicher abgelegt sind. Die DML unterteilt sich wiederum in
eine tatsächliche Manipulationssprache, die das Einfügen, Löschen und ändern von Daten
erlaubt sowie einer Anfragesprache (Query Language).
Die folgenden Datenmodelle dienen zur Klassifizierung generischer DBS. Neben den generischen unterscheidet man auch noch die spezifischen DBS, wie zum Beispiel GEOInformationsysteme oder Multimedia-DBen, die genau auf ein Anwendungsfeld zugeschnitten sind. Die spezifischen DBS werden im weiteren Verlauf nicht näher behandelt.
Bekannte Datenmodelle, welche die logische Ebene des DBS bestimmen sind u. a. die
folgenden:
ˆ
ˆ
ˆ
ˆ
Netzwerkmodell,
hierarchisches Datenmodell,
objektorientiertes Datenmodell
relationales Datenmodell
Das Netzwerkmodell und das hierarchische Datenmodell sind satzorientierte Modelle, die heutzutage als überholt gelten und kaum noch genutzt werden. Das objektorientierte Datenmodell wird als das zukunftsträchtigste Datenmodell gehandelt. Es
orientiert sich, wie der Name bereits erkennen lässt, an objektorientierten Konzepten und
bietet Strukturen für komplexe Objekte, Typen, Klassen, Objektidentität und Vererbung
an, um nur einige zu nennen (siehe u. a. [TürSaa2005]). Das relationale Datenmodell
ist das am weitesten verbreitete Modell und wurde von Edgar F. Codd in A Relatio”
nal Model for Large Shared Data Banks“ [Codd1970] vorgeschlagen. Im Gegensatz zu
den damaligen satzorientierten Modellen handelt es sich beim relationalen Modell um ein
mengenorientiertes Modell. Die Daten werden in Relationen gespeichert, die über Tabellen
visualisiert werden.
Datenmodelle überschneiden sich oftmals konzeptionell und sind nicht immer klar voneinander abzugrenzen. Heutzutage wird häufig objektorientierter Programmierung der Vorzug gegeben. Bei Kopplung objektorientierter Programme mit relationalen Datenbanken
kann es zu einem sogenannten Object-relational impedance mismatch“ kommen. Das be”
deutet es besteht eine Unverträglichkeit der verschiedenen Konzepte. Um dieses Problem
zu beheben,wird das relationale Modell mit objektorientierten Elementen erweitert. Hier
spricht man von objektrelationalen Erweiterungen, wie zum Beispiel Typed Tables oder
User-Defined Types (UDTs). Für nähere Informationen siehe u. a. [TürSaa2005]. Für diese
Diplomarbeit ist das relationale Datenbankmanagementsystem Access 2007 von Microsoft
vorgegeben.
6
2.2 Datenbankentwurf
2.2 Datenbankentwurf
Der Prozess der Datenbankentwicklung erfolgt in drei Ebenen. Entscheidend ist eine konsistente top-down-Entwurfsmethodik“. Die erste Ebene ist die Anforderungsanalyse, ge”
folgt vom Entwurf und der anschließenden Realisierung. In der Anforderungsanalyse
wird ein detailliertes Pflichtenheft erstellt. Inhalt des Pflichtenheftes sind die Spezifikationen über alle relevanten Informationen, die Anforderungen der verschiedenen Benutzer, die Verarbeitungsabläufe bestimmter Prozesse u.s.w. Dabei ist auf Vollständigkeit,
Verständlichkeit und Redundanzfreiheit zu achten. In [KemEik2004] wird darauf hingewiesen, dass begangene Fehler in einer Ebene und die Kosten, diese zu beheben, sich für jede
folgende Ebene, in der man den Fehler bemerkt, verzehnfachen. Der Entwurf teilt sich
in die Phasen des konzeptuellen, des logischen und des physischen Entwurfs ein. Im konzeptuellen Entwurf wird ein systemunabhängiges Schema der abzubildenden Welt erstellt.
Darauf aufbauend wird im logischen Entwurf das Schema im verwendeten Datenmodell
umgesetzt. Der physische Entwurf ist gekennzeichnet durch die Definition des internen
Schemas und die Organisation der Speicherstrukturen (Clustering, Partionierung,..), der
Indexierung und der Einstellung bestimmter Tunnnig-Parameter. Die beiden nachfolgenden Kapitel behandeln den konzeptuellen und den logischen Entwurf.
2.2.1 Konzeptueller Datenbankentwurf mit dem ER-Modell
Der konzeptuelle Datenbankentwurf ist gekennzeichnet durch die formale Darstellung der
Strukturen und Anforderungen und wird meist mit dem Entity-Relationship-Modell
(ER-Modell) realisiert. Dieses ER-Modell wurde durch Peter Chen in seiner Arbeit The
”
Entity-Relationship Model“ 1976 [Chen1976] vorgestellt. Es handelt sich dabei um ein
Konzept zur graphischen Darstellung von Entities (Gegenständen) und Relationships
(Beziehungen). Gegenstände (bzw. Entities) sind wohlunterscheidbare, physisch oder
”
gedanklich existierende Konzepte der zu modellierenden Welt“ [KemEik2004]. In diesem
Modellierungskonzept sind Entities durch ihre zugeordnete Attributstruktur gekennzeichnet und durch deren Werte genau charakterisiert. Entities mit gleicher Attributstruktur
können in Klassen, den sogenannten Entity-Typen, zusammengefasst werden. Diese werden durch Rechtecke dargestellt, die dazugehörigen Attribute durch Ovale (siehe Abbildung 2.1).
Abbildung 2.1: Entity-Typ Student
7
2 Grundlagen aus der Informatik
Ein Entity ist immer Instanz mindestens eines Entity-Typen. Alle Instanzen bilden die
Population ihres Entity-Typs. Die Attribute, die zusammen den Primärschlüssel bilden,
also die minimale Menge von Attributen die eine Instanz eindeutig identifizieren, werden
unterstrichen. Die Primärschlüssel müssen eindeutig sein, das bedeutet, dass kein weiteres
Entity denselben Primärschlüssel haben kann.
Beziehungen von Entities untereinander werden durch Relationships dargestellt. Die Relationships können mehrere Attribute zugeordnet bekommen, durch welche sie in Verbindung mit den Schlüsseln der Entities eindeutig charakterisiert werden. Wie Entities zu
Entity-Typen zusammengefasst werden, so gilt dies auch für gleichartige Relationships,
die in Relationship-Typen klassifiziert werden. Bei den Relationships wird ebenfalls von
Instanzen eines Typs gesprochen. Relationship-Typen werden graphisch durch eine Raute
(mit oder ohne Attribute) in Verbindung mit den Entity-Typen dargestellt.
Abbildung 2.2: Relationship-Typ mit Entity-Typen
Es sind auch Relationships zwischen Entities desselben Entity-Typen möglich. Zur Unterscheidung, in welchen Formen die Entity-Typen an dieser Relationship partizipieren,
bekommen sie an den jeweiligen Kanten Rollen zugewiesen
.
Abbildung 2.3: Relationship-Typ mit mehrfach Beteiligung eines Entity-Typen
Rollenzuweisungen sind bei Relationships ohne Mehrdeutigkeit auch einseitig zugelassen. Sie dienen dann lediglich als zusätzliche Information zur Erläuterung des Schemas. Relationship-Typen können weiter über ihre Funktionalitäten charakterisiert werden.
Funktionalität definiert die Form des Beziehungtyps zwischen Entity-Typen. Bei binären
8
2.2 Datenbankentwurf
Beziehungen gibt es vier verschiedene Formen, ausgedrückt durch ganzzahlige Werte M
und N ≥ 0. Wenn einer Instanz eines Entity-Typen höchstens eine andere Instanz eines
anderen Entity-Typen zugeordnet wird, dann spricht man von einer 1:1−Beziehung. Anschaulich könnte man sich hier zum Beispiel eine Vater-Sohn-Beziehung vorstellen. Eine
Beziehung mit der Funktionalität 1:N ist zum Beispiel eine Beziehung einer Universität zu
den eingeschriebenen Studenten, bei umgekehrter Betrachtung ist es eine N:1−Beziehung.
Keinerlei Restriktionen gelten bei einer N:M−Beziehung, die eine Instanz eines EntityTypen zu denen eines anderen haben kann. Die Funktionalitäten sind partielle Funktionen, bei denen nicht jede Instanz abgebildet werden muss.
Die bisher betrachteten binären Beziehungen kann man auch auf n-stellige Beziehungen
erweitern. Die Funktionalitäten werden durch partielle Funktionen ausgedrückt, pro 1 an
den Kanten gibt es eine partielle Funktion.
Im ER-Modell findet sich auch das Konzept des schwachen Entity-Typen. Schwache
Entity-Typen sind dadurch gekennzeichnet, dass sie keine autonomen Typen sind. Die Instanzen eines solchen Typs können nur existieren, wenn sie in einer Relationship zu einem
anderen, übergeordnetem Entity-Typen stehen und oft nur in Verbindung mit diesen Instanzen des zugeordneten Typs eindeutig identifizierbar sind.
Abbildung 2.4: Schwacher Entity-Typ Raum
Die Begriffe Generalisierung und Aggregierung bezeichnen zwei weitere Modellierungskonzepte, durch die das ER-Modell erweitert wird. Generalisierung bedeutet eine
Abstraktion der Entity-Typen in Unter- und Obertyp. Die Obertypen vererben an die
Untertypen allgemeine Attribute, die für alle Untertypen gelten. Die Untertypen sind
Spezialisierungen der Obertypen mit weiteren spezifischen Attributen. Entities eines Untertyps bilden Teilmengen von Populationen des Obertyps und sind somit auch Instanzen
des Obertyps. Diese Beziehung wird graphisch durch ein Sechseck mit der Inschrift is a“
”
dargestellt (siehe Abbildung 2.5).
Wird ein übergeordneter Entity durch eine Ansammlung von unterschiedlichen Instanzen
von Entity-Typen gebildet, spricht man von Aggregierung. Diese Art von Beziehung zwischen Entities wird durch den Begriff is part of“ dargestellt (siehe Abbildung 2.6).
”
9
2 Grundlagen aus der Informatik
Abbildung 2.5: Generalisierung mit Vererbung der Attribute des Obertyps
Abbildung 2.6: Bildung von Hierarchien: Aggregierung
10
2.2 Datenbankentwurf
2.2.2 Logischer Datenbankentwurf mit dem relationalen Datenmodell
Hier wird eine kurze Einführung zur Umsetzung von ER-Schemata ins relationale Modell
gegeben, also von der konzeptuellen zur logischen Ebene des Entwurfes. Das relationale
Datenmodell ist im wesentlichen vom dem Modellierungskonzept der Relation geprägt.
Relationen sind dabei formal als Teilmenge eines kartesischen Produktes mit n(n > 1)
Wertebereichen definiert. Die Elemente (Datensätze) einer Relation sind die Tupel. Die
einzelnen Spalten werden mit Attributen bezeichnet.
Im Prinzip gilt, dass jeder Entity-Typ durch eine Relation dargestellt wird.Die Relationen werden durch Tabellen veranschaulicht, die mit dem Namen des Entity-Typen und
den Spaltennamen als Attribute versehen sind. In den Tabellen werden Primärschlüssel
kenntlich gemacht. Relationship-Typen kann man ebenfalls in Relationen darstellen. Sie
besitzen im Gegensatz zu den Entity-Typen jedoch keine Primärschlüssel, sie sind mit
den Attributen des Relationship-Typen und den Primärschlüsseln des beteiligten EntityTypen eindeutig identifizierbar. Bei den oben genannten Funktionalitäten 1:N,N:1,1:1,
kann es von Vorteil sein, auf eine explizite Tabelle für den Relationship-Typen zu verzichten und diese Informationen in die mit N markierte Entity-Typ Relation zu integrieren.
Wird ein Entity-Typ oder ein Relationship in einer Relation abgebildet, so stellt jedes
Tupel ein Entity bzw. ein Relationship dar.
Abbildung 2.7: Beispiel: Abbildung vom ER-Modell ins relationale Modell
Ein schwacher Entity-Typ wird in einer Relation mit dem Fremdschlüssel des ihm
übergeordneten Entity-Typen zur die Identifizierung gekennzeicht. Der Fremdschlüssel
und ein eindeutiges Attribut des schwachen Entity-Typen ergeben seinen Primärschlüssel.
Es ist dabei auf referentielle Aktionen zu achten, wie beispielsweise einer Löschweitergabe
(On Delete Cascade).
Die is part of“-Beziehung kann wie ein normaler Relationship-Typ behandelt werden. Die
”
Umsetzung der is a“-Beziehung zwischen Entity-Typen mit der sich ergebenen Vererbung
”
erweist sich als komplexer. In der Vorlesung von Prof. Manthey werden 3 verschiedene
Variationen vorgestellt.
11
2 Grundlagen aus der Informatik
Der erste Vorschlag ist, den Obertypen E1 und den Untertypen E2 jeweils als eigene Relationen darzustellen. Dabei werden redundant die Attribute von E1 in E2 mit gespeichert.
Beim zweiten Vorschlag wird auf diese Redundanzen verzichtet und in der E2-Relation
neben den eigenen Attributen der Primärschlüssel von E1 abgelegt. Die vollständige E2Relation muss dann mittels einer Sicht unter Verwendung eines JOINs“ erzeugt werden.
”
Als dritte Alternative werden E1 und E2 mit einer Verteilung der vererbten Attribute
auf verschiedene Relationen dargestellt. Die vollständige Relation des E1 kann dann nur
mittels einer Sicht hergeleitet werden, dafür wird vollkommen auf Redundanzen verzichtet.
2.3 SQL
SQL (Structured Query Language) ist die bedeutendste Datenbanksprache für relationale
Datenbanken. SQL ist standardisiert von ISO (International Organization for Standardization) und ANSI (American National Standards Institute). Jedes DBMS, das SQL unterstützt, verwendet einen eigenen Dialekt von SQL, der sich mehr oder weniger an diesen
festgelegten Standards orientiert. Im Allgemeinen ist die Microsoft JET-Engine (Microsoft
Joint Engine Technology Engine), welche die Sprache Microsoft Access SQL verwendet,
mit ANSI-89 Level 1 kompatibel. Zusätzlich werden Features vom ANSI-92-SQL Syntax
unterstützt. Bei Microsoft Access SQL kommen weitere Funktionen und reservierte Wörter
hinzu, die nicht in dem Standard zu finden sind, als Beispiel wäre hier die Parameterabfrage zu nennen.
In SQL unterscheidet man drei verschiedene Arten von Tabellen:
ˆ Die Basistabellen (base tables), welche man weiter untergliedert in die persistent
base tables und die in SQL 1999 hinzugekommenen global temporary, die created
local temporary und die declared local temporary tables. In Access existieren nur
die persisten base tables, welche dauerhaft physisch in der Datenbank gespeichert
sind und die Daten durch den Anwender erweitert und modifiziert werden können.
Siehe dazu u.a. [Bode2007]
ˆ Die Sichten (derived tables) repräsentieren durch eine spezifische Anfrage abgeleitete Daten. Hierbei handelt es sich um virtuelle Tabellen, im Grunde hergeleitet von
Anfragen aus Basistabellen oder materialisierten Sichten.
ˆ Bei den materialisierten Sichten (viewed tables) handelt es sich um Sichten, die
dauerhaft physisch gespeichert werden.
MS Access unterstützt keine materialisierten Sichten. Hingegen kann man bei Oracle mit
CREATE MATERIALIZED VIEW explizit materialisierte Sichten erstellen. Zudem werden weitere Optionen bereitgestellt, wie die Bestimmung des Zeitpunktes der Materialisierung einer Sicht, also die dauerhafte physisch Speicherung. Ein weiteres Feature ist die
Festlegung eines Zeitpunktes bei dem die Daten in Bezug zu den referenzierten Basistabellen aktualisiert werden. Wird MS Access verwendet, lässt sich eine Sicht nur in eine
vorher erstellte Tabelle speichern und somit die Materialisierung simulieren.
12
2.3 SQL
2.3.1 Datendefinition
Ein Datenbankschema, welches die Struktur der abzuspeichernen Daten darstellt, lässt
sich mittels Datendefinitionsbefehlen in SQL erstellen. Ein grundlegender Datendefinitionsbefehl ist die Tabellendefinition, angeführt mit CREATE TABLE, gefolgt von Spaltendefinitionen mit den Spalten-Namen und den Wertebereichen. Es können dabei zu
jeder Tabelle, wie zu jeder Spalte, Integritätsbedingungen (Beschränkungen) formuliert werden. Änderungsoperationen, die eine Bedingung verletzen würden werden dann
vom DBMS zurückgewiesen. Die Syntax von Spaltenbeschränkungen ist folgende:
ˆ [NOT NULL | UNIQUE]:
Die Spalte darf keinen Nullwert enthalten | Der Wert dieser Spalte darf nicht mehrfach in dieser Tabelle vorkommen.
ˆ [PRIMARY KEY]:
Primärschlüssel der Tabelle darf nicht NULL sein.
ˆ [DEFAULT {Wert|NULL} ]:
Bei keinem oder einem ungültig gesetzten Eintrag wird der angegebene DEFAULTWert gesetzt.
ˆ [REFERENCES <Tabellenname>] : Der Wert dieser Spalte muss dem Wert der
entsprechend referenzierten Tabelle gleichen.
ˆ [CHECK (<Bedingung>)] : Mit dem CHECK-CONSTRAINT ist es möglich, Bereichseinschränkungen zu definieren. Diese booleschen Ausdrücke können eine hohe
Komplexität einnehmen und sich auf andere Tabellen beziehen.
Die Tabellenbeschränkungen haben im allgemeinen Einfluss auf mehrere Spalten. Deren
verwendete Syntax ist meist analog zu der der Spaltenbeschränkungen:
ˆ [UNIQUE (<Spaltennamen>)]
ˆ [PRIMARY KEY (<Spaltennamen>)]
ˆ [FOREIGN KEY (<Spaltennamen>) PREFERENCES <Tabellennamen>]
ˆ [CHECK (<Bedingung>)]
PRIMARY KEY und UNIQUE bedeuten als Tabellenbeschränkung, dass mehrere
Spalten zusammengefasst, eindeutig seien müssen und somit ein Primärschlüssel bzw.
Schlüsselkandidat sind. Durch die Bestimmung eines Primärschlüssels wird in Access automatisch auf diese Spalte(n) ein Index angelegt.
13
2 Grundlagen aus der Informatik
Mit Access-SQL ist es auch möglich eigene Wertebereiche für die Spalten festzulegen. Dies
wird mit dem Befehl CREATE DOMAIN ausgeführt, mit der Option einer Angabe eines
DEFAULT -Wertes und eines CHECK-CONSTRAINT, also einem selbst definierten Wertebereich.
Die bisher vorgestellten Integritätsbedingungen sind auf lokale Bereiche wie die Spalten
oder der ganzen Tabelle, mit eventueller Referenz auf eine andere Tabelle, ausgerichtet. Zur
Umsetzung von globalen Integritätsbedingungen bietet der SQL-Standard die sogenannten ASSERTIONS an. Da sie in der vorliegenden Diplomarbeit jedoch keine bedeutende
Rolle spielen, sollen sie hier nur erwähnt worden sein.
Das in dieser Arbeit verwendete DBMS, unterstützt von den oben vorgestellten Integritätsbedindungen, die Primär - und Fremdschlüsselbedingungen, sowie Gültigkeitsregeln
für Felder. Weitergehende Integritätsbedingungen oder Assertions lassen sich bei MS Access aber auch über Umwege erreichen. Durch definierte Kontrollsichten könnten Verstöße
erkannt und falls erwünscht durch eine übergeordnete Anwendung korrigiert werden.
Für das Anlegen von Sichten gilt allgemein folgende Syntax:
CREATE VIEW <Sichtname> AS
< Anfrage >
Die Anfragen werden im folgendem Abschnitt betrachtet.
2.3.2 Datenmanipulation
Die Datenmanipulationssprache wird bei [KemEik2004] in die eigentliche Manipulationssprache und Anfragesprache (Query Language) eingeteilt. Die Manipulationssprache bezieht sich auf Einfüge-, Lösch- und Änderungsoperationen der Daten in einer Tabelle.
Einzelne Daten werden dabei wie folgt eingefügt:
INSERT INTO Tabellenname (Liste von Spaltennamen)
VALUES (Pro einzufügendem Datensatz eine Liste von Werten);
Vorhandene Datensätze einer Tabelle lassen sich mit einer UPDATE -Anweisung modifizieren. Es können Werte ganzer Spalten verändert werden oder optional nur die Werte die
eine bestimmte Bedingung erfüllen.
UPDATE Tabellenname
SET < Spaltenname1 >=< W ert1 >, < Spaltenname2 >=< W ert2 >,...
WHERE <Bedingung>;
Durch Auslassung einer Bedingung werden alle Datensätze gelöscht, ansonsten nur die,
welche einen angegebenen Bedingungs-Teil erfüllen.
DELETE FROM <Tabellenname>
WHERE < Bedingung >
14
2.3 SQL
Es werden drei Anfrage-Typen unterschieden: die query expressions, die eine abgeleitete
Tabelle als Ergebnis liefern, die value expressions, bei denen das Resultat ein Wert ist
und die boolean value expressons, die einen Wahrheitswert liefern. Die Grundstruktur
einer Anfrage wird in Abbildung 2.8 deutlich.
Abbildung 2.8: Allgemeine Syntax
Im SELECT -Teil werden explizit die Spaltennamen oder auch Aggregationen auf Spalten angegeben, die den Spalten der Tabellen des FROM-Teils angehören. Die Angabe
eines ∗“ bedeutet, dass alle Spalten ausgegeben werden. Die Tabellen die im FROM -Teil
”
durch Kommat getrennt aufgezählt werden, bilden ein Kreuzprodukt, wie man es von der
relationalen Algebra kennt. MS Access bietet für die Verknüpfung von Tabellen mehrere
JOIN -Variationen an:
[INNER | LEFT | RIGHT] JOIN
Bei einem JOIN muss eine Bedingung angegeben werden, über welche Spalten die Tabellen verknüpft werden. Dies geschieht mit dem Schlüsselwort ON. Bei dem INNER
JOIN werden nur die Datensätze ausgegeben, für die diese Bedingung erfüllt ist. Der bei
MS Access verwendete LEFT bzw. RIGHT JOIN ist ein linker bzw. rechter OUTERJOIN. Das bedeutet, dass grundsätzlich alle linken bzw. rechten Datensätze angegeben
werden, unabhängig davon, ob sie einen JOIN-Partner gefunden haben oder nicht. Es gibt
in der Relationenalgebra noch weitere JOIN-Varianten, wie den SEMI-JOIN, wobei nur
die linken bzw. rechten JOIN-Partner hergeleitet werden. Dieser muss in Access simuliert
werden. Alle Datensätze werden beim FULL OUTER-JOIN angezeigt, auch diejenigen,
welche keinen JOIN-Partner gefunden haben. Eine diesbezügliche Simulation kann mit
einem RIGHT-/LEFT-JOIN und dem Vereinigungsoperator UNION erreicht werden.
Gruppierungen nach bestimmten Werten werden mit dem GROUP BY -Befehl vorgenommen. Dies hat das Entstehen von Teil-Tabellen zur Folge, welche mit einer Aggregation
eines Wertes in jeweils einer Ergebniszeile ausgegeben werden kann. Eine hinzugefügte
HAVING-Klausel dient als Filterkriterium der Ergebnisse.
15
2 Grundlagen aus der Informatik
SELECT SUM(Gehalt), Abteilung
FROM Firmen Buchhaltung
GROUP BY Abteilung
HAVING SUM(Gehalt) > 10000
Die Aggregatfunktion SUM summiert alle Werte der angegebenen Spalte der Teiltabellen.
MIN und MAX ermitteln das Minimum bzw. Maximum der angegebenen Spalte. AVG
berechnet den Mittelwert der Spalte, wobei NULL-Werte ignoriert werden. Die Aggregatfunktion COUNT, mit Angabe einer Spalte, zählt die Werte, die nicht NULL entsprechen.
COUNT(*) hingegen ermittelt ausnahmslos alle Tupel.
Anfragen können unter Beachtung der Verträglichkeit (Spaltenanzahl,Typgleichheit) mittels RA-Mengenoperatoren wie UNION (entspricht algebraisch ∪) ,EXCEPT (−) und
INTERSECT (∩) miteinander verknüpft werden. Von diesen Operatoren unterstützt
MS Access nur UNION. INTERSECT kann auf MINUS zurückgeführt werden (A ∩ B ⇔
A − (A − B)) und MINUS wird in Access durch NOT IN im Bedingungs-Teil verwirklicht.
2.4 Java
Im folgenden wird ein kurzer Überblick über Java und die genutzte Entwicklungsumgebung
gegeben. In Abschnitt 2.4.2 wird die Datenbankschnittstelle JDBC betrachtet. Zur näheren
Information siehe auch [Bode2007], [DatDar1998] und [Ullenboom2007].
2.4.1 Grundlegende Konzepte
Der Prototyp dieser Diplomarbeit wurde mit Java entwickelt. Java bezeichnet dabei sowohl
eine Programmiersprache, als auch eine Technologie. Es wurde Java 2 Standard Edition 5.0
(JSE 5.0) von Sun verwendet 1 . Diese beinhaltet die Komponente des Java Development
Kit (JDK) und des Java Runtime Enviroment (JRE). JRE beinhaltet die Java Virtual
Machine(JVM), welche Plattformunabhängigkeit gewährleistet. Plattformunabhängigkeit
bedeutet, dass das Programm unabhängig von einem Betriebssystem und einer zugrunde
liegenden Hardware verwendbar ist. Eine Vielzahl von angebotenen Open-Source-Pakten
können Programmieraufwand abnehmen.
Entwicklungsumgebung ist das Open-Source-Framework Eclipse, welches erstmalig von
IBM im November 2001 freigegeben wurde 2 . Eclipse ist eine Rich-Client-Plattform, bei
der sich Anwender Module und Plug-Ins selbst zusammenstellen können und somit die
Kernfunktionalitäten von Eclipse erweitern. Zur Programmierung der prototypischen Realisierung der graphischen Benutzeroberfläche (GUI) dieser Diplomarbeit wurde der Visual Editor3 installiert. Die einzelnen graphischen Elemente werden durch diesen Editor
1
http://java.sun.com/j2se/1.5.0/
www.eclipse.org
3
http://www.eclipse.org/vep/WebContent/main.php
2
16
2.4 Java
als Werkzeug mittels Darg&Drop kombiniert. Graphische Bausteine sind hier Elemente
aus dem Abstract Window Toolkit (AWT) und dem darauf entwickelten Swing-Paket.
Dieses Paket beinhaltete nicht nur Fenster, Textfelder, Menüs oder dergleichen, sondern
auch Ereignisbehandlungen. Zu den Ereignisbehandlungen gehört das Registrieren einer
betätigten Maustaste oder einer Mausbewegung, um beispielsweise durch den actionlistener 4 interaktiv über dem GUI das Programm zu steuern.
Die Sprache Java ist eine objektorientierte Programmiersprache. Objektorientiert bedeutet, dass Ausschnitte der realen Welt als Objekte aufgefasst und modelliert werden. Ein
Objekt kann Daten und Methoden beinhalten, wodurch Verhaltensweisen und Eigenschaften bzw. ein Zustand weitergehend spezifiziert wird. Gleichartige Objekte werden in Java durch Klassen dargestellt, ähnlich dem ER-Modell kann ein Objekt als Instanz einer
Klasse aufgefasst werden. Das Konzept der Kapselung wird mittels Klassen umgesetzt,
indem Implementierungsdetails der Datenstruktur außerhalb der Klasse verborgen bleiben. Die Kommunikation und der Zugriff der Objekte untereinander erfolgt über eine als
public“ definierte Schnittstelle. Integrierung und Modifizierung einzelner Komponenten
”
innerhalb größerer Projekte kann dadurch vorteilhaft umgesetzt werden. Innerhalb der Objekte kommt es zu Zustandsänderungen und Berechnungen, wobei die einzelnen Objekte
über Schnittstellen global gesehen untereinander interagieren.
2.4.2 JDBC
Datenbankzugriffe sind über verschiedene Anwendungsschnittstellen möglich [Bode2007]:
Direct Invocation: Dem DBMS werden DDL- und DML-Befehle über ein Terminal direkt
interaktiv zugeführt
Embedded SQL: Der Datenaustausch erfolgt hierbei über so genannte Host-Variablen
und SQL Parameter. Es werden dabei SQL-Deklarationen verwendet, die durch einen
Precompiler in die Hostsprache umgewandelt werden.
Module Language: Im Gegensatz zum Embedded SQL ist der SQL-Teil in Modulen zusammengefasst, welche vom Anwendungsprogramm wie Funktionen aufgerufen werden. Auf die Datensätze kann mit Hilfe von Cursor sequentiell zugegriffen werden.
Call-Level Interface (CLI): Es können über bereitgestellte Funktionen-API (Application
Programming Interface) Befehle an ein DBMS übermittelt werden. Die bekannteste
Datenbankschnittstelle ist hierbei ODBC (Open Database Connectivity)
Das CLI findet in der vorliegenden Diplomarbeit Anwendung. Von Interesse sind hierbei
die ODBC- und die JDBC-Schnittstelle, welche beide auf das Modell des CLI aufsetzten. ODBC ist eine von Microsoft entwickelte, einheitliche Datenbankschnittstelle, die für
den Zugriff auf Datenbanken genutzt wird. Sie ist heutzutage Standard und wird von diversen Softwareherstellern unterstützt. Eine zusätzliche JDBC-Schnittstelle ist nötig, um von
4
http://java.sun.com/j2se/1.4.2/docs/api/java/awt/event/ActionListener.html
17
2 Grundlagen aus der Informatik
einem Java-Programm auf ein DBMS zuzugreifen. JDBC ist ein geschützer Markenname
von Javasoft/Sun, der meist mit dem Begriff Java Database Connectivity“ in Verbindung
”
gebracht wird.
Es wird zwischen vier Typen von JDBC-Treibern unterschieden. Hier wird Typ 1 verwendet, die JDBC-ODBC-BRIDGE. Zur näheren Informationen über die anderen Typen
siehe [DatDar1998]. Diese wird benutzt, um keine spezifischen JDBC-Treiber zu benötigen,
sonder auf den standardmäßigen implementierten ODBC-Treiber zurückgreifen zu können.
Diese BRIDGE konvertiert die JDBC-Befehle in ODBC-Befehle, allerdings auf Kosten der
Effizienz.
In dieser Arbeit wird die aktuelle Version JDBC 3.0 API mit dem Paket java.sql verwendet. Zu den Hauptaufgaben zählen der Verbindungsaufbau zum DBMS, Anfragen in SQL
zu diesem weiterzuleiten, die Ergebnis-Datentypen in ein für Java akzeptierendes Format
zu konvertieren und Methoden zur Datenmanipulation zur Verfügung zu stellen.
2.4.3 Threads in Java
Bei der Kommunikation zwischen dem Programm, welches in der imperativen Programmiersprache Java implementiert ist, und dem DBMS, welches hier die deklarative Sprache
SQL verwendet, ist es wichtig auf eine richtige Synchronisation zu achten. Das bedeutet, dass Aufrufe vom Java-Programm an das DBMS genau abgestimmt werden müssen
und Befehle für die Datenverwaltung in der richtigen Reihenfolge dem DBMS zukommen
müssen um Inkonsistenzen zu vermeiden.
Um diese Herausforderung entsprechend bewerkstelligen zu können, bietet die JavaBibliothek u.a. Threads und die Spezifikation synchronized an. Eine Methode oder ein
Programmblock der mit synchronized deklariert ist, signalisiert der virtuellen Maschine,
dass die beinhalteten Anweisungen einheitlich und nicht nebenläufig auszuführen sind.
Threads sind Ausführungsstränge“ eines Programmcodes. Eine verzahnte Abarbeitung
”
mehrerer Threads vermittelt dabei die Illusion einer parallelen Ausführung. Durch spezifische Synchronisationsmechanismen wird dabei konfliktfrei auf einen gemeinsam genutzten
Speicherbereich zugegriffen. Ein einzelner Thread gibt eine sequenzielle Abarbeitungsreihenfolge der Anweisungen vor. Die Verwendung von Threads erlaubt hierbei dem Programmierer die Organisation von synchronisierten Programmabläufen. In Java wird ein Objekt
der Thread-Klasse angelegt um diese Funktionalität nutzen zu können und die Methode run() mit entsprechenden Anweisungen überschrieben. Die Instanz der Thread-Klasse
bzw. ihre Methode run() wird durch bspw. MeinThread.start() aufgerufen. Eine andere
Möglichkeit ist durch die Übergabe des Befehlsobjektes Runnable gegeben, die ebenfalls
die Methode run() implementiert.
18
2.4 Java
Der Befehl sleep(), der intern in einem Thread aufgerufen werden kann, gibt dem Programmierer die Möglichkeit, den Prozess warten zu lassen. In Verbindung mit einer while-Schleife kann dieser Prozess auch solange in den Schlaf“-Zustand versetzt werden, bis
”
eine spezifizierte Bedingung erfüllt ist. Dies ist nur eine von vielen nützlichen Optionen,
welche die Thread-Klasse bietet:
while(<Bedingung>)
try{ Thread.sleep(< Zeit in ms >);}
catch(InterruptedException e){ }
Da die Swing Komponente im Gegensatz zu AWT nicht Thread-sicher“ ist, muss von den
”
eigens dazu bestimmten Methoden invokeLater(Runnable) und invokeAndWait(Runnable)
der Aufruf erfolgen. Durch invokeLater wird der Thread in die Warteschlange der Prozessabarbeitung gelegt, ohne auf dessen vollständige Abarbeitung zu warten. Im Gegensatz
dazu wird bei invokeAndWait abgewartet, bis der Prozess vollständig einheitlich abgearbeitet ist.
19
2 Grundlagen aus der Informatik
20
3 Grundlagen zellulärer Automaten
Zelluläre Automaten sind diskrete Modelle, mit deren Hilfe man dynamische Systeme und
die Wechselwirkungen ihrer Teilkomponenten simulieren und untersuchen kann. Ein zellulärer Automat besteht dabei aus einer Anzahl identischer Zellen, für welche uniforme
Regeln gleichzeitig in diskreten Zeitschritten angewendet werden. Die Zustände der Zellen
werden in jedem Zeitschritt anhand von Regeln und ihrer wohldefinierten Nachbarschaft
neu berechnet. Heutzutage haben zelluläre Automaten ein breites Anwendungsspektrum.
Das Anwendungsspektrum dieser Automaten umfasst u.a. die Physik, Mathematik, Chemie, Geographie, Biologie und die Informatik. Sie gewinnen zunehmend an Bedeutung,
lassen eine Vielzahl von individuellen Möglichkeiten des Einsatzes erahnen und werden
uns in der Zukunft noch des öfteren begegnen.
2−dimensionaler zellulärer Automat [Weisstein]
21
3 Grundlagen zellulärer Automaten
3.1 Geschichte und wissenschaftlicher Kontext
Zelluläre Automaten wurden von dem Mathematiker John von Neumann, welcher
österreichisch-ungarischer Herkunft ist, und seinem damaligem polnischen Kollegen Stanislaw Marcin Ulam in den 40er Jahren am Los Alamos National Laboratory, entwickelt.
Ulam studierte seinerzeit das Wachstum von Kristallen und entwickelte für sein physikalisches Modell den Grundbaustein der zellulären Automaten. Von Neumann übernahm und
erweiterte diese mathematische Abstraktion für seine Studie über selbstreproduzierende
Automaten [von Neumann1966]. Hintergrund war die Idee, einen Automaten zu entwerfen,
der mit einer endlichen Anzahl von Elementen seinen Bauplan kopieren und sich selbst
konstruieren kann. Sein Antrieb war die Nachahmung von Leben und die Umsetzung eines
seiner möglichen Eigenschaften, nämlich das der Selbstreproduktion. Wechselwirkungen
einzelner Elemente untereinander wurden mit dem Modell eines zellulären Automaten
dargestellt. John von Neumann hat dabei Elemente in einem 2-dimensionalem Gitter angeordnet, in welchem die benachbart angeordneten Elemente untereinander nach festen
Regeln interagieren. Von Neumann erweiterte das Modell zu einem universellen Berechnungsmodell und ihm gelang der Beweis, dass sich bei bestimmten Anfangskonfigurationen
der entworfene Automat endlos kopiert.
Weitere Anwendungsmöglichkeiten erkannte der Computer-Pionier Konrad Zuse. 1967
veröffentlichte er seine bekannte Publikation Rechnender Raum“ [Zuse1967]. Darin wird
”
das Konzept eingeführt, das Universum in diskreten Werten zu unterteilen und räumliche
Beziehungen zu digitalisieren. Der Ausgangsgedanke hierbei ist, dass bei der Bestimmung einer Ordnung in dynamischen Systemen, die herkömmliche Physik gewissen Beschränkungen unterworfen ist. Die zellulären Automaten sollen sich hingegen auf diesem
Gebiet als äußerst hilfreich erweisen. Ordnung definiert sich hier durch stabile Konstellationen und spezifische Verhaltensweisen von Elementen untereinander. Dynamisch bedeutet
in diesem Fall zeitabhängig.
Die herkömmliche Physik nutzt meist komplexe (partielle) Differentialgleichungen um sich
den Verhaltensweisen dynamischer Systeme, wie sie in der Natur zu finden sind, möglichst
exakt anzunähern. Es wird dabei versucht, ausgehend vom gegenwärtigen Zustand die zeitlich folgenden Zustände zu ermitteln. Bei diesen physikalischen Modellen wird von kontinuierlichen Größen ausgegangen. Die Beschränkungen liegen nunmehr in der numerischen
Lösung und Berechnung dieser Modelle, da diese auf Grund der gegebenen Stellenkapazität
eines Computers mit diskreten Werten rechnen müssen. Hinzu kommt die Ungenauigkeit
bei Differenzengleichungen, womit sich den Differentialgleichungen angenähert wird. Hingegen gibt es bei den finiten Automaten nur eine endliche Zustandsmenge und somit auch
nur endlich viele diskrete Lösungen.
Bei der Betrachtung der Quantentheorie und der Heisenberg’schen Unschärferelation kommen weitere Faktoren hinzu. Die Heisenberg’sche Unschärferelation sagt aus, dass mit
beliebiger Genauigkeit gleichzeitig der Ort und Impuls eines Teilchens gemessen werden
22
3.1 Geschichte und wissenschaftlicher Kontext
kann. Dabei wird nicht auf diskrete Werte zurückgegriffen, sondern mit Wahrscheinlichkeiten gerechnet. Es zeigt sich, dass dieses Verfahren eine entstehende Ordnung in einem dynamischen System, durch die oben genannten Beschränkungen, nicht nachvollziehen kann.
Bei einer makroskopischen Betrachtungen von Interaktionen einzelner Objekten, kommt
es bei dieser Vorgehensweise zu einer Auflösung der Korrelation der lokalen Zustände bzw.
Beziehungen. Zuse verwendet als Beispiel den Fall von acht Teilchen in einem Raum, in
dem die Bahnen durch Stoßvorgänge genau senkrecht zu einer der Wände liegen (siehe
Abbildung 3.1). Die Teilchen beeinflussen sich dabei nicht gegenseitig.
Wir wissen nun, daß die moderne Physik dieses klassische Bild aufgelöst
”
hat. Die Stoßvorgänge der einzelnen Teilchen werden im Sinne der modernen
Physik nicht streng deterministisch angenommen. Es gelten lediglich Wahrscheinlichkeitsgesetzte, die im statistischen Durchschnitt den Gesetzen der
klassischen Mechanik entsprechen. Durch diesen Effekt tritt eine Streuung
ein, welche bewirkt, daß auch in theoretisch angenommenen Spezialfällen mit
der Zeit eine Auflösung der Ordnung eintritt und die Entropie des Systems
steigt.“[Zuse1967]
Entropie bedeutet der Informationsgehalt eines Systems. Die Entropie ist gegenläufig zu
einer Ordnung zu verstehen. Niedrige Entropie eines Systems zeugt von großer Ordnung,
welche mathematisch leichter modelliert werden kann, als wenn Chaos herrschen würde.
Grund dafür ist die beschriebene mangelnde Genauigkeit bei der computerbasierten Berechnung. Hingegen lässt sich dieses Modell mit seiner Ordnung durch zelluläre Automaten
nachvollziehen, da die diskrete Topologie des Modells selbst integraler Bestandteil von diesen Automaten ist.
Abbildung 3.1: Beispiel einer stabilen Ordnung von 8 in einem Quadrat mit
”
zurückwerfenden Kanten frei beweglichen Bällen. Ein analoges Modell
würde unendliche Genauigkeit erfordern. In einem digitalen Modell bleibt
die Stabilität erhalten. Die Stabilität gilt jedoch nur für diskrete Seitenlängen des Quadrats.“[Spektrum2007] Nach Zuse
In seiner Arbeit fasst Zuse jede einzelne Zelle als Kleinstautomat auf. Die Eingangs- und
Ausgangswerte sind die Informationen, welche die Zelle durch die Wechselwirkung mit ihren Nachbarn erhält. Er stellt die Frage ...ob beliebige unteilbare, also echt kontinuierli”
che Größen in der Natur überhaupt denkbar sind. Jedenfalls scheint die Automatentheorie
23
3 Grundlagen zellulärer Automaten
das richtige Werkzeug zu sein, wenn man die Frage nach der restlosen Quantisierung aller
physikalischen Größen stellt“. Das Universum als Computer oder als Rechenmaschine“
”
zu betrachten ist ein Aspekt, mit dem sich auch die heutige Wissenschaft vermehrt auseinander setzt.
Der Autor und Physiker Stephen Wolfram greift diese Idee in dem 1983 erschienenen
Buch A New Kind of Science“ [Wolfram1983] auf und bewirkt dadurch eine Wiederaufle”
bung und Vertiefung dieser Thematik. Wolfram spricht in seinem wissenschaftlichen Werk
von komplexen dynamischen Systemen. Ein System ist nach Stephen Wolfram komplex,
wenn seine Verhaltensweise unvorhersehbar ist, also eher wie zufällig“ erscheint, d.h. Re”
gelmäßigkeiten und daher die Möglichkeit der Komprimierung des Systems auf wesentliche
Grundzüge, nicht zu erkennen sind.
Die oben genannten Beschränkungen einer deduktiven Herangehensweise der herkömmlichen
Physik gelten dementsprechend für komplexe dynamische Systeme. Die Berechnung hängt
dabei sehr empfindlich von den gewählten Anfangswerten ab. Zur Verdeutlichung wäre hier
die geltende Aussage von Edward N. Lorenz zu nennen: Der Flügelschlag eines Schmet”
terlings im Amazonas-Urwald kann einen Orkan in Europa auslösen.“[Lorenz1963] Dieses
Verhalten ist auch als Schmetterlingseffekt bekannt geworden. Die Komplexität ergibt sich
aus einer Nichtlinearität dieser Systeme. Es handelt sich demnach also um komplexe nichtlineare dynamische Systeme. Das nichtlineare Verhalten wird durch die Wechselwirkungen
der Elemente eines Modells hervorgerufen, wobei dadurch keine langfristige Vorhersage
über die Entwicklung des Systems erfolgen kann.
Stephen Wolfram schlägt für diese komplexen Systeme eine induktive Herangehensweise vor. Dies bedeutet, dass man Systeme mit simplen“ Regeln verwendet, diese mittels
”
Simulation durchspielt und auf komplexe Verhaltensweisen überprüft. Arbeitsmittel der
Analyse ist ein zellulärer Automat. Jede Zelle verhält sich nach gleichen Regeln und interagiert mit den Zellen in ihrer wohldefinierten Nachbarschaft. Durch die Wechselwirkungen
der Zellen untereinander entsteht eine Eigendynamik, die von hoher Komplexität zeugen
kann.
Ein sehr interessanter Aspekt ist eben diese Bildung von komplexen Gruppierungen einzelner Zellen. Die Entstehung dieser Konstellationen, hervorgebracht durch die Interaktion
der einzelnen Zellen, bezeichnet man auch als Selbstorganisationsprozess. Prof. Dr. Klaus
Mainzer formuliert dies in seinem Manuskript [Mainzer2006] wie folgt:
Nichtlineare Dynamik führt jedoch nicht nur zu Chaos, sondern ermöglicht
”
auch Selbstorganisation von Ordnung in komplexen Systemen. Dabei kommt es
zu charakteristischen Rückkopplungen von Systemelementen, bei denen Wirkungen von Ursachen selber wieder zu Ursachen werden, um ihre Ursachen zu
beeinflussen. So entstehen makroskopische Strukturen, die nicht durch die Systemelemente vorgegeben sind, aber durch ihre Wechselwirkung bei geeigneten
24
3.1 Geschichte und wissenschaftlicher Kontext
Anfangs- und Nebenbedingungen (d.h. Einstellung von Kontrollparametern)
möglich werden. Man spricht dann auch von Emergenz von Ordnung.“
Das Thema der vorliegenden Diplomarbeit, das datenbankbasierte Monitoringsystem, zielt
auf die Überwachung und Auswertung solcher makroskopischer Strukturen ab.
Albert Einstein sagte einmal:“Gott würfelt nicht“, die Quantenphysik behauptet das
Gegenteil. Zuse fragt sich, was die Konsequenzen wären, wenn man die Naturgesetze
vollständig quantisieren würde und diese diskreten Werte auch einer vollständigen Quantisierung unterliegen würden. Prof. Jürgen Schmidthuber [Schmidthuber2007] gibt zu bedenken, dass es sich bei den Zufällen, die in der Quantenphysik erwähnt werden, um
Pseudozufälle“ handeln könnte, hervorgerufen durch die Wechselwirkungen kleinster Ele”
mente. Man könnte sich vorstellen, dass die makroskopischen Strukturen, die auftauchen,
diesen nicht vorhersagbaren Zufälle“ entsprechen. Bei einem zellulären Automaten gilt
”
nach Konrad Zuse: Die Größe einer solchen Zelle muss dabei so gewählt werden, dass
”
das Verhalten des Gesamtsystems durch die Beschreibung des Verhaltens einer einzelnen Zelle vollständig erklärt ist.“ Wenn es also ein deterministisches Universum geben
sollte und dieses einer vollständiger Quantisierung unterliegt, müsste man das Verhalten der kleinsten Elemente den Zellen eines zellulären Automaten zuordnen, um an die
Möglichkeit einer Berechnung zu gelangen. “Würfelt Gott doch nicht? Vielleicht erlebt das
deterministische Universum eine umfassende Renaissance“[Schmidthuber2007]. Was sich
als richtig herausstellen wird, sei dahin gestellt, es zeigt aber die immense Bedeutung und
Einsatzmöglichkeit der zellulären Automaten in der heutigen Wissenschaft.
Stephen Wolfram definiert vier Zielzustände von zellulären Automaten mit unterschiedlichen Regeln:
ˆ Klasse 1: Fast alle Initialzustände führen zu einem uniformen Gleichgewichtszustand.
ˆ Klasse 2: Konstante (periodische) Endzustände mit einfachen Mustern sind Möglich.
ˆ Klasse 3: Es wird kein stabiler Endzustand erreicht, zufällige Muster entstehen und
verschwinden auch wieder.
ˆ Klasse 4: Es entstehen räumlich voneinander getrennte stabile oder periodische komplexe Muster. Dabei können sich die Muster auch durch den Raum bewegen.
Zelluläre Automaten der Klasse 3 könnten als Erklärungmodell einer Evolution dienen.
Mit geeigneten Anfangbedingungen könnte man mit diesen Automaten auch einen universellen Computer erstellen. Die Klasse 4-Automaten bewirken noch komplexeres Verhalten,
die zu universellen Berechnungen fähig sind. Zelluläre Automaten dieser Klasse sind in der
Lage, Turing-Maschinen nachbilden zu können.
25
3 Grundlagen zellulärer Automaten
Nach diesem Einblick in die wissenschaftlich theoretische Betrachtung der zellulären Automaten werden nun pragmatische Anwendungsgebiete näher erleuchtet. In Simulating
”
Physics with Cellular Automata“ von G.,Y. Vichniac [Vichniac1984] können die Anwendungsgebiete in drei wesentliche Ansätze unterschieden werden:
ˆ Simulation diskreter dynamischer Systeme, die selbst integraler Bestandteil der Automaten sind
ˆ Verwendung von zellulären Automaten, als eigenständige Modelle für physikalische
Systeme, auch in Konkurrenz zu anderen bereits existierenden mathematischen Modellen
ˆ Zelluläre Automaten als reine Rechenwerkzeuge
Zellulären Automaten dienen zum Beispiel der Simulation von Verkehrsszenarien, um unter anderem Verkehrsstaus zu erkennen oder um Ampelschaltungen zu optimieren. In
einem makroskopischen Modell wird mit kollektivem Verhalten von Verkehrsdichten zu
bestimmten Zeiten und Lokalitäten gerechnet. Im Gegensatz dazu wird mit einem zellulären Automaten ein mikroskopisches Modell aufgestellt. Es wird ein probabilistischer
zellulärer Automat verwendet, um individuelles Verhalten der Verkehrsteilnehmer zu imitieren und somit jedes einzelne Fahrzeug simuliert werden kann. Dies führt zu einer hohen
Wirklichkeitsnähe. Dieses Prinzip wird auch, bei der Untersuchung des Kaufverhaltens von
Supermarktkunden oder einer Fluchtwege-Analyse bei Großveranstaltungen verfolgt. Die
zellulären Automaten kommen sodann bei Simulationen von Waldbränden, Verhalten von
Gasteilchen und zur Darstellung chemischer Oszillationen, u.s.w. zum Einsatz [Milbradt].
Neben den vorgestellten Anwendungen und Anwendungsgebieten spielen die zellulären
Automaten in dem Forschungsgebiet Artificial Life“ eine entscheidende Rolle . Die Ideen
”
der heutigen Forschung gehen dabei auf John von Neumann zurück, der wie zu Anfang
des Kapitels erwähnt, bei seiner Arbeit über die selbstreproduzierenden Automaten, die
Nachahmung von künstlichem Leben bzw. eines seiner Eigenschaften verfolgte. Künstliches
Leben und die damit verbundenen Eigenschaften sind nicht immer klar zu definieren. Es
lassen sich aber Grundcharakteristiken festlegen, auf die man sich weitestgehend geeinigt
hat: die Reproduktion, die Entscheidungsfreiheit im Verhalten, der Informationsaustausch
und die Evolution (Mutation und Selektion). Dieses Forschungsgebiet behandelt nicht die
Simulation von biologischen, physikalischen oder chemischen Prozessen, sondern das Studium von Evolution und künstlichen Objekten, die Eigenschaften des Lebens nachahmen.
Angestrebt wird die Erweiterung der Vorstellung vom Leben und des Evolutionsprozesses,
weg von unserem bekannten irdischen biologischen Leben, hin zu einer höheren Abstraktionsebene. Digitales Leben in einem Computer ist nicht nur wesentlich leichter zu beobachten, es lassen sich auch einfach Gesetzmäßigkeiten und Parameter variieren. Der Ablauf
der Evolution kann dabei wesentlich schneller als in der Natur erfolgen. Im gewissen Sinne
handelt es sich hierbei um eine Simulation der Evolution des Lebens. Zur näheren Information, worauf sich auch hier bezogen wurde siehe u. a. [Ray].
26
3.2 Formale Definition zellulärer Automaten
Wie oben erläutert, kann man an Hand verschiedener Gesetzmäßigkeiten die zellulären
Automaten spezifizieren und in die vier von Wolfram vorgeschlagenen Klassen einteilen.
Nicht alle Regeln bewirken eine Evolution von künstlichem Leben bzw. bringen einige von
deren Eigenschaften hervor. Das in dieser Diplomarbeit betrachtete Game of Life“ lässt
”
sich der Klasse 4 zuordnen. Durch die sorgsam ausgewählten Regeln und den Wechselwirkungen der Zellen untereinander, entsteht eine nicht vorhersehbare Entwicklung und
Interaktion. Das ”Game of Life”wird dabei auch als theoretisches Evolutionsmodell betrachtet.
Die hier erläuterten Themen sind nur ein Ausschnitt von dem, was mit zellulären Automaten in Verbindung gebracht wird. Zelluläre Automaten bilden ein weites Feld, siehe dazu
folgende Abbildung, mit einem entsprechenden statistischen Begriffsnetz (siehe Abb. 3.2).
3.2 Formale Definition zellulärer Automaten
Die diskrete Darstellung eines Raumes erfolgt durch Unterteilung in einzelne gleichmäßig
angeordnete Teilbereiche. Die Teilbereiche stehen für eine Anzahl identischer Zellen und
bilden dabei ein Gitter. Dabei können die Topologie und die Dimension des Raums von
Modell zu Modell unterschiedlich definiert sein. Siehe u. a. [Worsch2007].
Definition 3.1 (Raum eines zellulären Automaten). Der Raum R eines zellulären Automaten besteht aus einer gleichmäßigen Anordnung von identischen Zellen. d ∈ N/{0}
ist die Dimensionalität des Raums. Die einzelnen Zellen werden durch ihre kartesischen
Koordinaten identifiziert k = {k1 , k2 , ..., kd } ∈ N1 × .. × Nd , wobei N1 , ..., Nd ∈ N.
Zellen die sich am Rand des Raumes R befinden haben weniger angrenzende Zellen, als
die Zellen, welche sich in der Mitte von R befinden. Somit sind nicht alle Zellen identisch, was der allgemeinen Definition eines zellulären Automaten widerspricht. Es gibt
verschiedene Varianten von Randbedingung. Im Rahmen dieser Diplomarbeit werden alle Zellen außerhalb des Raumes R beständig als Zellen mit dem Zustand Q = 0 betrachtet..
Wie die Dimensionalität eines Raums bestimmt wird, kann auch die Form der Zellen in
unterschiedlichen Modellen variabel gewählt werden. Durch die Form wird die Anzahl angrenzender Nachbarn zu jeder einzelnen Zelle festgelegt (siehe Abbildung 3.3).
Jede Zelle nimmt dabei eine endliche Anzahl von Zuständen Q an. Bei der oben erwähnten
Publikation über selbstreproduzierende Automaten [von Neumann1966], haben die Zellen
zum Beispiel 29 verschiedene Zustände zugeordnet bekommen.
27
3 Grundlagen zellulärer Automaten
Abbildung 3.2: Statistisches Begriffsnetz: “zelluläre Automaten“ [BB2007]
28
3.2 Formale Definition zellulärer Automaten
Abbildung 3.3: Räume mit unterschiedlicher Dimensionalität
Definition 3.2 ((globale) Konfiguration). Man spricht von einer globalen Konfiguration,
wenn der Gesamtzustand der Zellen des Raums R gemeint ist, also eine Abbildung g :
R → Q oder auch g ∈ QR , die die Menge aller Abbildungen von R in Q ist. Es wird von
einer Konfiguration einer Zelle gesprochen wenn der Zustand einer Zelle z , z ∈ R mit der
Abbildung k : R → Q gemeint ist.
Definition 3.3 (Nachbarschaft einer Zelle z). Eine Nachbarschaft einer Zelle z ∈ R ist
eine endliche Menge Nz = {z1 , ...zk } ∈ R, bei denen die zj ∈ R, 1 ≤ j ≤ k mit ihren
Koordinatendifferenzen nur durch eine wohldefinierte Größe von den kartesischen Koordinaten der Zelle z abweichen.
Durch eine definierte Nachbarschaft wird bestimmt, welche Nachbarschaftszellen einer
Zelle bekannt“ bzw. bei der Anwendung der vorliegenden Regeln, von Bedeutung sind. Die
”
Konfigurationen der Zellen in der jeweiligen Umgebung einer Zelle haben Einfluss auf ihren
Folgezustand. Die Nachbarschaft kann beliebig gewählt werden, gilt dann jedoch für alle
Zellen identisch. Die bekanntesten Nachbarschaften sind die in folgenden beschriebenen:
Definition 3.4 (Moore-Nachbarschaft im 2-dimensionalem Raum). Für einen 2dimensionalen Raum R eines zellulären Automaten und einer Zelle z ∈ R mit den Koordinaten x und y, ist die Moore-Nachbarschaft Mzr wie folgt definiert: Sie beinhaltet z und
alle horizontalen, vertikalen und diagonalen angrenzenden Zellen von z, die in dem Radius
r liegen: (siehe Abbildung 3.4)
r
M(x,y)
=def {(k, l) ∈ R| (|k − x|) ≤ r ∧ (|l − y| ≤ r)} .
29
3 Grundlagen zellulärer Automaten
Abbildung 3.4: Moore-Nachbarschaft im 2-dimensionalem Raum
Definition 3.5 (von Neumann-Nachbarschaft im 2-dimensionalem Raum). Für einen 2dimensionale Raum R eines zellulären Automaten und einer Zelle z ∈ R mit den Koordinaten x und y, ist die von Neumann-Nachbarschaft V N rz mit dem Radius r (siehe
Abbildung 3.5) wie folgt definiert:
V N r(x,y) =def {(k, l) ∈ R| ((|k − x|) + (|l − y|)) ≤ r} .
Abbildung 3.5: von Neumann-Nachbarschaft im 2-dimensionalem Raum
Es ist ersichtlich, dass sich die beiden definierten Nachbarschaften im eindimensionalem
Raum nicht voneinander unterscheiden.
Definition 3.6 (lokale Konfiguration). Von einer lokalen Konfiguration spricht man, wenn
der Gesamtzustand der Nachbarschaft N einer Zelle gemeint ist. Also eine Abbildung
l : N → Q oder auch l ∈ QN , welche die Zustände in einer Nachbarschaft beschreibt. QN
ist dabei die Menge aller Abbildungen von N in Q.
Die Berechnung globaler Konfigurationen der zellulären Automaten und deren Folgezustände, werden in diskreten Zeitschritten berechnet. Es wird dabei in Analogie zum
biologischen Leben von Generationen gesprochen.
30
3.3 Game of Life
Definition 3.7 (lokale Überführungsfunktion). Der Zustand einer Zelle zum Zeitpunkt t
hängt von der lokalen Konfiguration der Zelle zum Zeitpunkt t − 1 ab (t > 1). Hiermit
ergibt sich eine lokale deterministische oder probabilistische Überführungsfunktion:
δ : QNz − > Q
Ausgehend von der Generation t wird t+1 berechnet:
δ(lr (t))− > k(r)(t + 1)
r ∈ R
Die uniformen Übergangsregeln werden bei einem zellulären Automaten in diskreten Zeitschritten für alle Zellen zeitgleich durchgeführt. Es lässt sich zusammenfassend festhalten:
Ein zellulärer Automat ZA = (R,Q,N,δ) ist bestimmt durch:
ˆ den Raum R
ˆ der endlichen Nachbarschaft N
ˆ der endlichen Zustandsmenge Q
ˆ und der lokalen Überführungsfunktion δ : QNz → Q. z ∈ R
Diese Definition ist das strukturelle Grundgerüst“ eines zellulären Automaten. Es gibt
”
unendlich viele Variationen die Details für beliebige Anwendungen zu spezifizieren. Die
bekannteste Spezifikation eines zellulären Automaten, welche in dieser Diplomarbeit benutzt wird, wird im folgenden Abschnitt vorgestellt.
3.3 Game of Life
Das Game of Life“ oder einfach nur Life“ wurde 1970 von dem Mathematiker John Hor”
”
ton Conway entwickelt und wurde in der Zeitschrift Scientific American“ [Gardner1970]
”
publiziert. Dieses Simulations-Spiel ist eines der populärsten Umsetzungen eines zellulären
Automaten und erlangte auch außerhalb der Gebiete der Mathematik und Informatik
Berühmtheit. Game of Life“ ist ein Automat mit universeller Rechenfähigkeit, also so
”
ausdrucksmächtig wie eine Turing-Maschine [Levy, S.75]. Es wird auch als große verein”
heitlichte Theorie des Universums“ betrachtet [Levy,S 69].
Conway wählte seine Regeln sorgfältig nach bestimmten Kriterien aus [Gardner1970]
ˆ Es sollte keine Anfangskonfiguration geben für die es ein leichtes ist zu beweisen,
dass sich die Zellen grenzenlos ausbreiten.
31
3 Grundlagen zellulärer Automaten
ˆ Es sollte Anfangskonfigurationen geben, die scheinbar ohne Grenzen wachsen
können.
ˆ Es sollte einfache Anfangskonfigurationen geben, wo die Population der Zellen erst
wächst und dann nach einer beträchtlichen Zeit zu einem Endzustand kommen indem:
– alle Zellen gestorben sind (durch Überfüllung oder einer zu spärlichen Besetzung),
– die Konstellation sich in einem stabilen Zustand eingefunden hat, sich somit
nicht mehr ändert oder in eine oszillierende Phase eingeht, wo die Muster sich
zyklisch wiederholen.
Durch die definierten Regeln und den Wechselwirkungen der Zellen untereinander, entsteht
eine nicht vorhersehbare Entwicklung und Evolution der Zellen. Dieser Prozess und die
im Laufe der Zeit entwickelten Formen sind beeinflusst durch die Größe des Raumes des
zellulären Automaten und bestimmt durch die ausgewählte Anfangskonfiguration lebender
Zellen. Es können sich dabei komplexe Muster, mit einem ebenso komplexen Verhalten,
entwickeln, die dem künstlichen Leben zugeordnet werden kann. Der Name dieses spezifischen zellulären Automaten und der Begriff der Zellen, wurde in Analogie zum realen
Leben gewählt, da das Game of Life“ als theoretisches Evolutionsmodell dienen kann.
”
3.3.1 Formale Definition des Game of Life“
”
Bei dem Game of Life“ können die Zellen nur zwei verschiedene Zustände annehmen, Q
”
= 0, wenn diese Zellen als tot und Q = 1, falls diese Zellen als lebend bezeichnet werden.
Somit ergibt sich die Zustandsmenge Q = {0,1}. Zu Beginn des Spiels sind alle Zellen
tot und dem Anwender“ kommt die Aufgabe zu, eine beliebige Anfangkonstellation von
”
lebenden Zellen zu bestimmen. Der Raum des zellulären Automaten des Game of Life“,
”
ist wie folgt definiert:
Definition 3.8 (Raum des zellulären Automaten beim Game of Life“). Ein 2”
dimensionaler Raum R eines zellulären Automaten A vom Game of Life“, im weiteren
”
als RA bezeichnet, besteht aus einer Menge identischer Zellen, die in Gitterquadraten angeordnet sind. Die Dimension des Raums R ist m ∗ n , m, n ∈ N .
Das Gitter besitzt somit m ∗ n Zellen. Die Parameter m und n, sind nicht vorgegeben und
können daher beliebig gewählt werden.
RA =def {(x, y)|x, y ∈ N, 0 ≤ x < m, 0 ≤ y < n}} .
32
3.3 Game of Life
Bei dem Game of Life“ wird die Moore-Nachbarschaft (siehe Definition 3.4) im 2”
dimensionalem Raum mit dem Radius 1 verwendet:
N(x,y) =def {(k, l) ∈ R | (|k − x| ≤ 1) ∧ (|l − y| ≤ 1 )}.
Beispiel 3.1 (Moore-Nachbarschaft einer lebenden Zelle beim Game of Life“). Die hier
”
verwendete Moore-Nachbarschaft der lebenden Zelle (2,2) ist :
N(2,2) = {(1, 1), (2, 1), (3, 1), (1, 2), (2, 2), (2, 3), (3, 1), (3, 2), (3, 3)} (siehe Abb. 3.6)
Abbildung 3.6: Moore-Nachbarschaft
Im weiteren Verlauf bezeichnen wir eine Zelle A, die sich in der Moore-Nachbarschaft,
mit dem Radius 1 einer Zelle B befindet, als Nachbarschaftszelle der Zelle B. Wenn von
einer Nachbarschaft die Rede ist, bezieht sich das in der folgenden Diplomarbeit auf die
erläuterte Moore-Nachbarschaft im 2-dimensionalem Raum.
Die lokale Überführungsfunktion beim Game of Life“ ist nach festen Regeln definiert,
”
welche sorgfältig nach den oben erwähnten Kriterien ausgewählt wurden.
Für lebende Zellen gilt:
ˆ Jede Zelle mit einem oder keinem Nachbarn, stirbt (an Vereinsamung).
ˆ Jede Zelle mit vier oder mehr Nachbarn stirbt (an Überpopulation).
ˆ Jede Zelle mit zwei oder drei Nachbarn überlebt.
33
3 Grundlagen zellulärer Automaten
Für tote Zellen gilt:
ˆ Jede Zelle mit drei lebenden Nachbarn wird geboren.
Somit ergibt sich die lokale Überführungsfunktion, wobei r ∈ RA , l die lokale Konfiguration und k die Konfiguration einer Zelle ist: (siehe z.B.[Berlekamp1985])


1
δ(l(r)) =
1

0
P
f alls l(r) = 3
P
f alls l(r) = 4 und k(r) = 1
sonst
Beispiel 3.2 (Zustandswechsel). In diskreten Zeitschritten kommt für jede Zelle die lokale
Überführungsfunktion zeitgleich zur Anwendung.
globaler Zustand zum Zeitpunkt t
(a) Berechnung der Zellen die
geboren werden
(b) Berechnung der Zellen
die sterben werden
Zeitgleiche Anwendung der lokalen Überführungsfunktion
globaler Zustand zum Zeitpunkt t
34
3.3 Game of Life
3.3.2 Komplexe Objekte und Anfangskonstellationen des Game of Life“
”
Bei der Simulation des GOL scheint es, als Laufe ein Film ab, bei dem einige Zellkonstellationen ein interessantes Verhalten zeigen. Konstellationen erscheinen dabei wie reale
Objekte mit individuellem Verhalten. Der Begriff Objekt, dem sich hierbei bedient wird,
ist jedoch nicht genau definiert, es handelt sich vielmehr um eine intuitive Bezeichnung
für Formen die kontinuierliche Eigenschaften aufweisen. Geprägt durch die spezifischen
Regeln des Game of Life“ gibt es bekannte Objekte mit charakteristischen Eigenschaf”
ten. Dem Entdecker“ von solchen Konstellationen wird die Ehre zuteil, sie benennen zu
”
dürfen. Es ist zu beachten, dass ein Objekt meist mehrere Zellkonstellationen besitzt, die
es in einem Zyklus durchläuft. Die charakteristischen Eigenschaften der einzelnen Objekte
werden dabei über mehrere Generationen, durch die oben genannten Überführungsregeln
und ihre Wechselwirkungen untereinander, hervorgerufen. Aufgrund der großen Anzahl
der Objekte und ihrer Entdecker, wird hier auf eine explizite Angabe verzichtet. Es wird
auf die Seiten von [Weisstein] und dem Life Lexicon“ von [Silver] verwiesen, Quellen der
”
beispielhaften Abbildungen.
Die Objekte, welche bei einem Zustandsübergang, ihren Ort und ihre Struktur beibehalten,
also ein stabiles Muster aufweisen, wurden von Conway still lifes“ genannt. Sie werden
”
im deutschen Sprachraum meistens als statische Objekte bezeichnet:
Die Objekte, welche wie die statischen Objekte ihren Ort nicht verlassen, aber bei denen
sich die Struktur nach einer gewissen Anzahl von Schritten periodisch wiederholt, werden
zur Klasse der Oszillatoren gezählt:
35
3 Grundlagen zellulärer Automaten
Würden sich die Oszillatoren zusätzlich noch durch den Zell-Raum bewegen, würden sie
zur Klasse der Gleiter (auch Raumschiffe genannt) gehören:
Der wohl bekannteste und einfachste Gleiter
(c)
LeightWeightSpaceship
(d)
MiddleWeightSpaceship
(e) HighWeightSpaceship
Es existieren auch weitaus kompliziertere Gleiter:
Mit Gleitern können Impulse einer Turingmaschine simuliert und somit Berechnungen
durchgeführt werden, mit welche die universelle Rechenleistung des Game of Life“ be”
wiesen werden kann [Berlekamp1985]. Bei diesem Beweis werden durch Kollisionen von
Gleitern, neue Gleiter produziert. Diese Streams von Gleitern werden als Bits aufgefasst
und logische Gatter und Speicher simuliert. The Seal“, mit einer der kompliziertesten
”
Gleiter wurde 2005 von N. Beluchenko entdeckt“. Dieser Gleiter wiederholt sich alle 6
”
Generationen:
36
3.3 Game of Life
Zur Klasse der Gleiter-Kanonen (engl. Glider-guns) gehören die Objekte, die Gleiter
generieren und die Population der Zellen unendlich anwachsen lassen können. Conway bot
demjenigen 50 Dollar [Gardner1970], der den Beweis erbringen könnte, dass es beim Game
”
of Life“ Konstellationen gibt, die unendlich viele Zellen produzieren. Die Gleiter-Kanonen
wären ein Beweis dafür.
Es gibt sogar bereits Gleiter-Kanonen, die selbst wieder Gleiter-Kanonen hervorbringen
können. Ebenso kann durch eine Kollision zweier Gleiter, eine Gleiter-Kanone entstehen,
die dann in Kombination mit Gleiter-Kanonen ein Beispiel für einen selbstreproduzierbaren Automaten wäre.
Es lassen sich in der Literatur noch viele weiter interessante Objekte finden, wie zum
Beispiel einen so genannten Gleiter-Fresser, der seine zyklisch wiederkehrende Struktur
beibehält und die eintreffenden Gleiter gewissermaßen löscht. Eine weitere Variante eines
Gleiters sind die so genannten Puffer. Sie hinterlassen beim Schweben“ durch den Raum
”
eine Spur von Zellen, die man mit Rauchwolken assoziieren könnte.
Abgesehen von Objekten sind beim Game of Life“ im besonderen verschiedene Anfang”
konfigurationen von Interesse. Das unscheinbare f-Pentomino (oder auch: r-Pentomino
genannt) (siehe Abbildung 3.7) welches sich explosionsartig chaotisch auszubreiten
scheint, wird auch als Methusalem-Figur bezeichnet, da es eine lange Entwicklungsphase
durchläuft. Erst ab der 1103. Generation stabilisiert sich die entwickelte Konstellation mit
einer Population zu diesem Zeitpunkt von 116 Zellen.
Abbildung 3.7: f-Pentomino
Erwähnenswert sind die zum Teil anmutigen Platzfüller (engl. spacefiller). Diese globalen Konfigurationen sind so angeordnet, dass sie sich, würde man sie lassen, unendlich
flächendeckend über den Zell-Raum ausbreiten.
37
3 Grundlagen zellulärer Automaten
Generation: 0 Zellen: 187
Generation: 23 , Zellen: 561
Platzfüller“ [Callahan]
”
Das GOL bietet eine große Anzahl an Facetten und Zuständen. Es wirkt faszinierend wie
sich partielle Populationen harmonisch scheinend ausbreiten bis sie auf andere treffen, eine chaotische“ Phase durchlaufen und sich die Zustände wieder langsam stabilisieren. Es
”
wird deutlich, welch vielschichtiges Spektrum Game of Life“ zur Beobachtung der Zellen
”
bietet.
Zusammenfassend bietet ein zellulärer Automat, im speziellen GOL als prototypische Umgebung für das datenbanbasierte Monitoringsystem, folgende Vorzüge:
ˆ Parameter sind leicht zu modifizieren
ˆ die Taktrate des Informationsflusses die dem Monitoringsystem bei jeder Generation
vorliegt lässt sich steuern (und gegebenfalls temporär anhalten)
ˆ große Bandbreite an differenzierbarem Verhalten, Komplexitätsgrad nach oben hin
offen
ˆ vergleichbare Herausforderungen/Datenbewältigung bei realem Einsatz
38
4 Datenbankentwurf und Konzeption von
Simulations- und Analyseprozessen
Im vorliegenden Kapitel werden der Entwurf der zugrunde liegenden Datenbank und die
Konzeption der Simulations- und Analyseverfahren diskutiert. Abschnitt 4.1 beschäftigt
sich mit dem Datenbankentwurf bezüglich der Objekte des Game of Life“ und den Objek”
ten des Monitoringsystems, welches das Monitoringsystem die interessant erscheinenden
Ereignisse dieses Spiels erfasst. Es wird zuerst konzeptuell, dann logisch modelliert. Die
Analyse von zusammenhängenden Konstellationen lebender Zellen, die als Cluster definiert werden, nimmt bei den Funktionen des Monitoringsystems eine Schlüsselrolle ein.
Kapitel 4.2 befasst sich u.a. mit dieser Analyse, in welcher die Konzeption des GOL und
des Monitoringsystems erläutert werden. In Abschnitt 4.3 werden der entwickelte Datenbankentwurf und das Konzept des Monitoringsystems um Visualisierungsaspekte ergänzt.
Diese Aspekte beinhalten die graphische Darstellung der erfassten Cluster und ihren Bewegungen und Expansionen über die Zeit.
Wird im Weiteren von einem Spiel gesprochen, dann sind damit zwei Teil-Prozesse gemeint. Im ersten Teil-Prozess bestimmt der Anwender die Anfangskonstellation der lebenden Zellen, welche der Datenbank übermittelt wird. Der zweite Teil ist die anschließende
Simulationsphase, bei dem nach den Regeln des Game of Life“ die Folgegenerationen
”
erzeugt werden. Ein Spiel ist zu Ende, wenn der Anwender es abbricht, eine neue Anfangskonstellation auswählt oder wenn alle Zellen tot sind.
4.1 Datenbankentwurf
Dieser Abschnitt beschäftigt sich mit den Aspekten des GOL und mit der Ereignisüberwachung des Monitoringsystems. Es ist eine Entscheidung zu treffen, welche Ereignisse in dem Spiel überhaupt von Interesse sind und durch das Monitoringsystem
überwacht werden sollen. Diese getroffenen Entscheidungen werden als (indirekte) Objekte entworfen und mit denen des GOL verknüpft.
4.1.1 Konzeptueller Datenbankentwurf
Die Anforderungen der Anwendung, zunächst unabhängig vom Zielsystem, können mit
verschiedenen Möglichkeiten in der konzeptuellen Ebene des Entwurfs dargestellt werden. Grundsätzlich muss entschieden werden, ob man einen Zustand eines Spiels, mit der
39
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
Darstellung eines Spielfeldes oder einen Prozess bzw. Historie eines oder mehrerer Spiele,
entwerfen möchte. Wird eine Historie eines Spiels modelliert, gibt es für jede einzelne Zelle
so viele Instanzen, wie es unterschiedliche Generationen gibt. Da es bei dem GOL eigentlich keine Historie gibt, wird zunächst die intuitive Vorgehensweise gewählt und nur das
Spielfeld, also der aktuelle Spielzustand, modelliert. Diese Implementierung hat im besonderen Speicherplatz- aber auch Performanzvorteile, welche in der folgenden Modellierung
deutlich werden. Die Analysen des Monitoringsystems, die ausgehend von der aktuellen
Generation, sich auf Zustände in vergangenen Generationen beziehen, werden an gegebener Stelle explizit erläutert. Der konzeptuelle Entwurf wird zunächst untergliedert. Es
wird sich in einem Teil mit dem GOL und in einem anderem mit den Aspekten des Monitoringsystems befasst.
Zunächst werden die direkten“ Objekte des GOL konzeptuell modelliert. Der Entity-Typ
”
Zelle gehört zu diesen Objekten, wobei sich jede Instanz dieses Typen disjunkt in eine lebende oder eine tote Zellen unterteilen lässt. Die Kennzeichnung dieser charackteristischen
Eigenschaft lässt sich unterschiedlich modellieren.
1. Unterteilung in Untertypen lebende und tote Zelle
2. Ein Entity-Typ Zelle mit einem Attribut für den aktuellen Zustand
ˆ Zellen werden implizit als tote Zellen angenommen, wenn kein Wert gesetzt ist
ˆ Mit dem Attribut wird explizit ein Zustand angegeben, ob eine Zelle lebend
oder tot ist
3. Ein Untertyp lebende Zelle wird modelliert und die Zellen die nicht zu diesem abgeleiteten Untertypen der Zelle gehören, werden als tote Zellen betrachtet
Die Variante 1, wobei die Untertypen ohne ergänzende Attribute von dem Obertyp Zelle
abgeleitet werden, hebt die Bedeutung dieser Untertypen bei dem konzeptuellen Entwurf
hervor. Es wird durch diese Konzeption die Möglichkeit gegeben, eine explizite Beziehung
zu einem der Untertypen darzustellen. Bei Vorschlag 2 steht die Zelle im Mittelpunkt der
Betrachtung und wird nur durch das ihr hinzugefügte Attribut näher gehend charakterisiert. Die Variante 3, die in diesem Entwurf umgesetzt wird, hat den Vorteil, dass die
Bedeutung der lebenden Zelle im Vergleich zu den toten Zellen für das GOL hervorgehoben wird. Weiterhin kann beim folgenden Entwurf, wie es bei Vorschlag 1 auch der Fall
ist, detaillierter dargestellter werden, dass andere Entity-Typen mit dem Untertyp der
lebenden Zelle in einer Beziehung stehen und nicht nur mit der Zelle, wie bei Vorschlag2.
Die Attribute vom Entity-Typ Zelle sind die x- und y- Koordinaten des Raumes RA .
Die einzige relevante Beziehung des GOL ist die direkte Nachbarschaft der Zellen untereinander. Diese ist definiert durch die Moore-Nachbarschaft (siehe Definition 3.4), in der
jede Zelle acht Nachbarschaftszellen besitzt. Sie wird durch den Relationship-Typ benachbart mit angegeben.
40
4.1 Datenbankentwurf
Nach der Modellierung des GOL, wird sich nun mit den ausgewählten Analysen des Monitoringsystems und ihrem konzeptuellen Entwurf beschäftigt. Das Hauptinteresse bei der
vorgestellten prototypischen Implementierung, liegt nicht bei der Betrachtung einzelner
Zellen des GOL, sondern auf den makroskopischen Strukturen und Verhaltensweisen, die
sie durch ihre Wechselwirkungen untereinander erzeugen. Einige Zellkonstellationen erscheinen bei der Betrachtung der Simulation über mehrere Generationen, in Analogie zum
realen Leben, als eigenständige Wesen mit individuellem Verhalten.
Um eine Abstraktionsebene zwischen einzelnen lebenden Zellen und einer globalen Konstellation (alle lebenden Zellen) einer Generation zu bringen, werden Zellkonstellationen
anhand ausgewählter Kriterien in Cluster geordnet. Zellkonstellationen, die bisher intuitiv
als Objekte bezeichnet wurden, sollen nun als Cluster definiert und erfasst werden. Die
Clusterbestimmung ist eine notwendig vorausgehende Phase für nähere Auswertungen. Mittels dieser Cluster können dann lokale Analysen des Monitoringsystems durchgeführt werden. Es gibt in der Literatur beim GOL keine vorgeschriebene Definition für
ein Cluster. Im Allgemeinen werden Zellkonstellationen die kontinuierliche Eigenschaften
vorweisen, intuitiv als Objekte bezeichnet. Im folgendem wird die für diese Diplomarbeit
relevante Definition eines Clusters eingeführt.
Ein Cluster wird hier als eine Konstellation von lebenden Zellen aufgefasst, wobei sich die
Zellen in einer Interaktion miteinander befinden und sich autonom, in Bezug zu den Regeln
des GOL, entwickeln. Diese Auffassung bedient sich keiner statischen Betrachtungsweise,
die nur auf geographische Aspekte abzielt. Hier wird sich vielmehr auf die autarke Entwicklung bzw. Wechselwirkung der Zellen untereinander, des Clusters über die Zeit, bezogen.
Diese Bedingungen sind wie folgt formal definiert:
Definition 4.1. N sei die Moore-Nachbarschaft des zellulären Automaten des GOL. Eine
lebende Zelle l1 ist Clusternachbar einer lebenden Zelle l2 gdw. ∃z : zNl1 ∧ zNl2
Mittels dieser Nachbarschaft werden die Cluster ermittelt.
41
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
Definition 4.2. Ein Zellenpfad ist eine Folge von lebenden Zellen z0 , z1 , . . . , zr (r ≥ 0),
wenn für alle i = 0, 1, . . . , r − 1 gilt: zi ist Clusternachbar von zi+1 .
Es wird von einem Zellenpfad der von z nach x führt gesprochen, wenn der Anfangsknoten
z0 = z und der Endknoten x ist. Die Länge des Pfades ist r.
Definition 4.3. Sei L ⊆ RA die Menge der aktuell lebenden Zellen. Eine Menge C ⊆ L
heißt Cluster, wobei la , lb L, gdw.
∀la , lb ∈ C : ∃ Pfad zwischen la und lb .
Konkret heißt das, dass zwei Zellen, getrennt von einer toten Zelle, zu einem Cluster
gehören, da sich ihr Einzugsgebiet der Interaktion nach den Regeln des GOL bereits
überschneidet und sie zur Berechnung der nächsten Generation miteinander interagieren
(siehe Abbildung 4.1), was ansonsten einer autonomen Darstellung widersprechen würde.
Durch die lebenden Zellen und ihrer direkten Nachbarschaft, ist der Raum für die Berechnung der nächsten Generation fest eingegrenzt. Würde man im Gegensatz zu der
vorgestellten Definition, eine Zellkonstellation als Cluster betrachteten, die nur durch ihre
unmittelbaren direkten Nachbarn bestimmt wird, könnte durch ein anderes angrenzendes
Cluster, eine Zelle geboren werden, ohne das es zu einem Kontakt gekommen ist. Um bei
der Analogie des realen Lebens zu bleiben, wäre dies eine unbefleckte Empfängnis“.
”
Abbildung 4.1: Lebende Zellen, die Cluster bilden
In der Literatur findet man teilweise Zellkonstellationen, die als Objekte bezeichnet werden, welche mit der obigen Definition eines Clusters bzw. Objektes nicht konform sind. Bei
der Gleiter-Kanone (siehe Kapitel 3.3.2) beispielsweise, handelt es sich um ein Objekt“,
”
das auf einer größeren räumlichen Distanz miteinander interagiert, d.h. per Definition
würde es hier nicht als Cluster bezeichnet werden. Die Gleiter-Kanone wird dennoch intuitiv als Objekt betrachtet, da sich die Zellkonstellationen nach einer gewissen Periode
wieder in ihrer Ausgangskonfiguration befinden und ein systematisches räumliches Verhalten zeigen. Es wird an diesem Beispiel deutlich, dass nicht nur die direkte geographische
42
4.1 Datenbankentwurf
Nachbarschaft bei der intuitiven Bezeichnung eines Objektes eine Rolle spielt. Der hier
eingeführte Begriff des Clusters umfasst jedoch die meisten in der Literatur behandelten
Objekte.
Ein Großteil der Cluster weisen ein nichtlineares Verhalten auf, welches durch die Wechselwirkungen der innehabenden Zellen hervorgerufen wird. Es sind auch Cluster erkennbar, die eine systematische Bewegung in einer Simulation vollziehen. Interessante Objekte
und Zell- Konstellationen des Game of Life“ wurden im Abschnitt 3.3 vorgestellt. Die
”
Verhaltensweisen werden erst durch die Simulation und der graphischen Darstellung der
aufeinander abfolgenden Generationen deutlich. Bei der Betrachtung einer Generation erkennt man hingegen nur die statische Konstellation der lebenden Zellen in dem Raum des
zellulären Automaten, ohne intuitiv auf irgendein Verhalten schließen zu können.
Die Cluster bilden vor allem eine Ordnung über die lebenden Zellen, welche sich für eine
Klassifizierung anbieten. Das Monitoringsystem wertet dabei die sich in diskreten Zeitschritten verändernden Daten mit beständigen Analyseprozessen aus. Cluster können dabei nach spezifischen Verhaltensweisen, in Klassen eingeordnet werden. Es wird bei den
Funktionen des Monitoringsystems von einer Ereignisüberwachung gesprochen, wenn es
nur auf die aktuelle Generation bezogen, zu einer Schlussfolgerung ausgehend vom Zustand
oder Klassifizierung von Zellkonstellation kommt. Der Begriff Prozessüberwachung
wird verwendet, wenn sich die Analyse auf über einen längeren Zeitraum bezieht, eine andauernde Entwicklung beobachtet wird und in jeder Generation die Ergebnisse der
Auswertung von Bedingungen inkrementell erweitert werden und, ohne die Daten nur auf
einen spezifischen Zustand hin zu überprüfen.
Hier werden beim konzeptuellen Entwurf die Cluster ihren Verhaltensweisen nach klassifiziert. Diese Unterteilung der Cluster verdeutlicht die verschiedenen Analyseverfahren des
Monitoringsystems, die zur Bestimmung der einzelnen Untergruppen notwendig sind. Umso feiner unterteilt wird, desto spezifischer sind die Analyseverfahren. Zunächst lassen sich
die Eigenschaften der Cluster disjunkt in zwei Kategorien, in statische und dynamische
Cluster unterteilen. Da diese als Entity-Typen, neben den geerbten Attributen des Obertyps Cluster keine weiteren Attribute besitzen, können sie vollständig von ihrem Obertyp
abgeleitet werden. Die statischen Cluster, von Conway auch Stillleben (engl. still life“)
genannt, werden auf Grund ihrer Eigenschaft, dass sie während der Simulation statisch
in ihrer Position und Konstellation verharren, nicht weiter spezifiziert bzw. unterteilt. Die
dynamischen Cluster hingegen sind alle anderen Cluster, bei denen die Zellkonstellation
während der Simulation variiert. Sie weisen daher weitere interessante Verhaltensweisen
auf und werden weiter zergliedert. Für die hier prototypische Realisierung werden die
dynamischen Clustern in Gleiter und Oszillatoren unterteilt. Die Gleiter und Oszillatoren kehren in periodischen Abständen zu ihrer Ausgangskonfiguration zurück. Der Gleiter
wandert indes noch durch den Raum des zellulären Automaten. Diese Klassifizierungen
eignen sich für die prototypischen Analysen, da die zugeordneten Objekte nicht unbegrenzt
43
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
anwachsen. Die Anzahl der innehabenden Zellen dieser Objekte können aber beliebig groß
sein und deren Eigenschaften sind nicht zu komplex. Es werden die einzelnen Klassen
durch eine is a-Beziehung dargestellt, da sie vom Obertyp dynamische Cluster abgeleitet
werden. Der Entity-Typ Gleiter bekommt zusätzlich das Attribut Richtung zugeordnet.
Ein weiterer Aspekt des implementierten Monitoringsystem ist die Analyse, mit welcher
Wahrscheinlichkeit eine Cluster-Kollision bevorsteht. Es handelt sich um eine ClusterKollision, wenn aus mindestens zwei Clustern zum Zeitpunkt t-1 ein Cluster zum Zeitpunkt
t entsteht. Bei der ermittelten Wahrscheinlichkeit wird nicht nur die Distanz der Cluster
untereinander betrachtet, sondern auch die Ermittlung und Einbeziehung der Gleiter und
ihrer Richtung in die sie sich bewegen. Durch die Betrachtung ihrer Richtung kann präziser
vorhergesagt werden, ob ein Gleiter mit anderen Clustern kollidieren wird. Bei den übrigen
Clustern hingegen ist eine Entscheidung für eine Richtung durch das nichtlineare Verhalten
der Zellen untereinander nicht zu treffen. Die Wahrscheinlichkeit einer Cluster-Kollision
wird durch die Beziehung bedroht von dargestellt mit dem Attribut Kollisionswahrscheinlichkeit. Somit ergibt sich der vorläufige konzeptuelle Entwurf mit der Betrachtung einer
aktuellen Generation (siehe Abbildung 4.2).
Abbildung 4.2: Vorläufiger konzeptueller Entwurf
44
4.1 Datenbankentwurf
Beim dem vorliegendem Entwurf wurde sich für die Darstellung eines Spielfeldes entschieden, die einen Zustand einer Generation wieder gibt. Im Hinblick auf das Verhalten
der Cluster und den dahingehenden Analysen des Monitoringsystems, welche sich über
mehrere Generationen erstrecken, muss die vorliegende Modellierung hinsichtlich des ZeitAspektes erweitert werden. Bei dem Entwurf des ER-Schemas ist eine Ergänzung um einen
zeitlichen Aspekte untypisch. Um sich nicht von der Modellierung eines Spielzustandes zu
entfernen, wird eine Beziehung gehört zu mit einem Zeitstempel -Attribut eingeführt, die
eine partielle Historie von den Clustern und ihren Zellen bildet. Wenn von einer partiellen
Historie gesprochen wird, so bedeutet das, dass nur die für die Analyse der aktuellen Generation notwendigen Informationen dargestellt werden. Es wird weiterhin keine vollständige
Historie aufgezeigt, sondern nur die vergangene Generation, um die Cluster von der vergangenen in die aktuelle Generation identifizieren zu können. Diese Entscheidung wird
bei der Entwicklung der Analyseverfahren des Monitoringsystems näher erörtert. Zu
Berücksichtigen ist, dass bei einer solchen Modellierung der Relationship-Typ gehört zu
nicht mehr mit dem Entity-Typ lebende Zelle verknüpft sein kann. Grund ist, dass nur die
aktuelle Generation von den lebenden Zellen gespeichert wird. Bei Veränderungen dieser
Population in einer Generation ist der Bezug von der gehört zu-Beziehung zu vergangenen
Cluster nicht mehr stimmig. Die lebenden Zellen vergangener Cluster können aber stets
hergeleitet werden, da Cluster sich nur aus lebenden Zellen zusammensetzen und gehört zu
durch diese charackterisiert ist. Es werden hierbei die Feinheiten deutlich, die man im Gegensatz zu herkömmlichen Datenbankanwendungen mit dem eingebrachten Aspekt eines
zeitlichen Bezuges beachten muss.
Abbildung 4.3: Modifizierung um einen zeitlichen Aspekt
4.1.2 Logischer Datenbankentwurf
Beim logischen Entwurf wird der oben angeführte konzeptionelle Entwurf in das relationale
Datenmodell überführt. In diesem Abschnitt wird sich auf die grundlegende Tabellenstruktur konzentriert. Davon abweichend kann es gegebenenfalls bei komplizierten Analysen des
Monitoringsystems zu weiteren Einführungen von notwendigen Tabellen (beispielsweise für
materialisierte Sichten) kommen. Die endgültige vollständige Tabellenstruktur kann erst
im physischen Entwurf, nach der Betrachtung der verschiedenen Algorithmen und ihrer datenbankbasierten Umsetzung, entschieden werden. Das Anlegen der Tabellenstruktur wird
45
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
nicht einfach naiv nach festen Regeln vollzogen, sondern im Hinblick auf weitestgehende
Redundanzfreiheit und die Möglichkeit priorisierte Daten durch performante Operationen
gewinnen zu können. Es wird sich an dem konzeptuellen Entwurf orientiert, es kann aber
auch zu spezifischen Abweichungen und Erweiterungen hinsichtlich einer späteren Realisierung kommen.
Es wird zuerst der konzeptuelle Entwurf der direkten“ Objekte des GOL für die Simu”
lationskomponente in die logische Ebene umgesetzt. Die Analysekomponenten des Monitoringsystems werden nachfolgend betrachtet. Die einzigen toten Zellen, die in einer
aktuellen Generation von Belang sind, sind die Nachbarschaftszellen der lebenden Zellen.
Diese können leicht von den lebenden Zellen hergeleitet und ihnen zugeordnet werden.
Somit werden nur die relevanten toten Nachbarschaftszellen zur Berechnung der nächsten
Generation betrachtet. Ein weiterer Vorteil dieser Implementierung ist, dass implizit die
lebenden Zellen und durch Abgrenzung dieser, auch die toten Zellen ohne Angabe eines
zusätzlichen Attributes erfassbar sind. Des Weiteren kann auf eine allgemeine Tabelle für
die Zellen verzichtet werden. Grundsätzlich lässt sich diese Beziehung als Tabelle mit den
Koordinaten der lebenden Zelle und ihrer Nachbarschaftszellen darstellen.
Nach der Modellierung der Objekte des GOL werden nun die Aspekte des Monitoringsystems betrachtet. Die Cluster stehen mit den Zellen in einer gehört zu-Beziehung, versehen
mit einem Zeitstempel, in der aus Speicherplatz- und Performanzgründen keine Historie
gespeichert wird. Die Cluster bestehen nur aus lebenden Zellen, wurden aber beim konzeptuellen Entwurf durch Einbringung eines zeitlichen Aspektes mit dem Typ Zelle verknüpft.
Tote Zellen bei den Analysen des Monitoringsystems spielen nur bei der Clusterbestimmung eine Rolle (da auch eine tote Zelle zwischen zwei Zellen eines Clusters existieren
kann). Sie werden hierbei auch nur in Bezug zu den lebenden Zellen betrachtet und aus
den gleichen Gründen wie bei dem Simulationsprozess nicht explizit gespeichert. Wie beim
konzeptuellen Entwurf erläutert werden nur die relevanten Daten zur Verfolgung der Cluster über einen Generationenwechsel dargestellt. Es erfolgt also eine explizite Speicherung
der aktuellen und der vergangenen Generation.
46
4.1 Datenbankentwurf
Durch diese Beziehung können die Cluster über einen beliebigen Zeitraum des Spiels verfolgt werden. Der Einfachheit halber, um Abfragen und komplizierte Aktualisierungen
zu vermeiden, werden die Cluster der beiden zu betrachtenden Generationen in unterschiedlichen Tabellen dargestellt, womit die jeweilige Differenz der Generationen implizit
ausgedrückt wird.
Da es die Funktionalität bei der Betrachtung der jeweiligen aktuellen Generation zulässt,
wird die Beziehung gehört zu in die Tabelle Cluster und in die Tabelle vorausgangene Cluster verteilt eingebettet. Es werden (da es nicht möglich ist) für die Anfangskonstellation keine vergangenen Cluster gespeichert. Bei einem Generationswechsel werden die
vorausgangenen Cluster mit den aktuellen Clustern der letzten Generation überschrieben.
Da nur die lebenden Zellen ein Cluster bilden, werden diese in der Tabelle angegeben und
es ist somit implizit klar, dass sie den Zustand Q=1 haben. Auf einen Fremdschlüssel muss
verzichtet werden, da nicht kaskadierend aktualisiert werden kann. Bei einem Generationswechel würde dieser temporär verletzt werden, da die Cluster erst wieder neu analysiert
und gespeichert werden müssen. Bei der Betrachtung der datenbankbasierten Umsetzung
bleibt bis zum physischem Entwurf abzuwarten, ob die vorläufig als Tabelle dargestellte
Beziehung benachbart von in die Cluster Tabelle eingebettet wird. Es ist nicht notwendig
zur Darstellung der Cluster, es ist gegebenfalls aber für verschiedene Analysen von Nutzen.
Zur Identifizierung, welche Cluster aus welchem Cluster in der vergangenen Generation
entstanden sind, muss noch eine zusätzliche Tabelle folgt aus angelegt werden. Benötigt
wird die ClusterID der vorausgegangenen und der zugehörigen ClusterID der aktuellen
Generation.
Beim konzeptuellen Entwurf sind die einzelnen Entity-Typen der Klassifikation in einer
is a Beziehung zu dem Cluster gesetzt, um die Unterschiede der Analyseverfahren dieser Instanzen hervorzuheben. Es wird in dynamische und statische Cluster unterschieden.
Beim Analyseverfahren des Monitoringsystems wird nicht explizit auf den Obertyp dynamische Cluster zugegriffen, dieser Entity-Typ dient lediglich der Unterteilung der AnalyseSpezifikationen gegenüber den statischen Cluster und kann beim logischem Entwurf vernachlässigt werden. Somit können die drei verschiedenen Typen, Oszillator, Gleiter und
statische Cluster als Tabelle, mit der Cluster−ID und dem Attribut der spezifischen Klassifizierung, erstellt werden. Bei den Gleitern kommt das Attribut der Richtung noch hinzu.
In der Tabelle für die Kollisionswahrscheinlichkeit soll eine Prognose eines Zusammentreffens von je zwei Clustern gespeichert werden. Zu diesem Zweck ist es notwendig zwei
ClusterIDs und einen Wert, der die Wahrscheinlichkeit einer Kollision ausdrückt, abzulegen. Dieser Wert kann ohne Beschränkung der Allgemeinheit ein numerischer Wert sein.
Da bei dieser Analyse und der Berechnung der Distanzen untereinander, als weiterer Faktor die Gleiter mit Einbeziehung ihrer Richtung hinzukommen, wird als drittes Attribut
nicht eine Distanz, sondern eine Kollisionswahrscheinlichkeit der Tabelle hinzugenommen.
47
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
Somit ergeben sich folgende Tabellen:
ˆ Für die direkten Objekte des GOL:
– LebendeZellen: {x, y}
– benachbart mit:{x, y, xNZ, yNZ}
ˆ Für die Aspekte des Monitoringsystems
– Cluster: {x, y, ClusterID(,xNZ, yNZ)}
– vorausgangene Cluster: {x, y, ClusterID, (xNZ, yNZ)}
– folgt aus: {alte ClusterID, aktuelle ClusterID}
– Kollisionswahrscheinlichkeit: {ClusterID1, ClusterID2, Kollisionswahrscheinlichkeit}
– Klassifizierung: {ClusterID,Klassifizierung(,Richtung)}
4.2 Konzeption von Simulations- und Analyseprozessen
4.2.1 Simulationsprozess
Game of Life“ ist ein Simulationsspiel. Das bedeutet, dass der Anwender nur zu Beginn
”
eine Anfangskonstellation auswählt und die Simulation startet. Dem Anwender obliegt es
also nicht interaktiv, während der Simulation in die erzeugten Zellkonstellationen einzugreifen und diese zu modifizieren. Er hat nur die Möglichkeit, die Taktrate der zu erzeugenden Generationen zu steuern (siehe Kapitel 5.3.1), sowie die Simulation zu beenden und ein
neues Spiel zu starten. Im Gegensatz dazu, wie es bei datenbankbasierten Anwendungen
in der Realität geläufig ist, werden die Daten bzw. hier die Population der lebenden Zellen je Generation nicht extern der Datenbank zugeführt, sondern intern datenbankbasiert
berechnet und bereitgestellt. In diesem Abschnitt wird der allgemein zugrunde liegende
Algorithmus zu diesem Prozess erläutert.
In diskreten Zeitabschnitten werden die nächsten Generationen erzeugt. Es wird die
Möglichkeit geboten, die Simulation zu verlangsamen oder auch temporär zu stoppen,
um notfalls den Abschluss aufwendiger Auswertungen zu ermöglichen. Diese Vorgehensweise und die dadurch entstehenden Möglichkeiten prägen den prototypischen Charakter
dieser Realisierung.
Im Rahmen der Initialisierung bestimmt der Anwender im graphisch bereitgestellten Raum
des zellulären Automaten (siehe Kapitel 5.3) die lebenden Zellen und startet die eigentliche Berechnung der Simulation. Das Zusammenspiel der einzelnen Komponenten des implementierten Systems wird in Kapitel 5 näher erläutert. Die aktuell vorliegende globale
Konstellation kann nach dieser Initialisierung erstmals vom Monitoringsystem ausgewertet
werden. Die einzelnen Analysen des Monitoringsystems werden hier außer acht gelassen
und dienen nur der zeitlichen Einordnung in Bezug zum Simulationsprozess.
48
4.2 Konzeption von Simulations- und Analyseprozessen
Die relevanten Zellen, die in der nachfolgenden Generation überhaupt leben könnten, sind
die Zellen der Moore-Nachbarschaft der aktuell lebenden Zellen. Nur in diesen Zellen
können aktuell lebende Zellen überleben oder tote Zellen geboren werden. Da die relevanten toten Zellen nur in diesem Umfeld gefunden werden, bietet es sich an, diese Kandidaten
anhand der lebenden Zellen herzuleiten. Für alle relevanten ermittelten Zellen, unter Einbezug der Anzahl der lebenden Zellen in ihrer Moore-Nachbarschaft, werden folgend die
Regeln des Game of Life“ angewendet.
”
Im Rahmen dieser Berechnungen müssen zwei Vorgehensweisen hinsichtlich ihrer Performanz erörtert werden. Da es bei der Betrachtung der Moore-Nachbarschaft einer toten und
einer lebenden Zelle Überschneidungen (siehe Überführungsfunktion (Abschnitt 3.3.1))
bezüglich der Regelanwendung gibt, ist zu evaluieren ob es sinnvoll ist beide Gruppen von
Zellen zusammen auszuwerten.
Abbildung 4.4: Das Spiel mit Hervorhebung des Simulationsprozesses
49
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
Da die Moore-Nachbarschaft einer Zelle, diese Zelle auch mit beinhaltet, gilt, dass eine
Zelle in der nächsten Generation lebt wenn 3 lebende Zellen in ihrer Moore-N. beinhaltet sind. Unabhängig davon ob diese Zelle aktuell lebt oder tot ist. Des Weiteren ist zu
untersuchen, ob sich der Schritt der Herleitung der Moore-Nachbarschaft sinnvoll nutzen
lässt, um die Anzahl der lebenden Nachbarn einer Zelle direkt mitzubestimmen. Durch
diese Erkenntnisse wird dann die Konfiguration jeder relevanten Zelle für die nächste Generation bestimmt. Diese globale Konfiguration ist dann wieder Ausgangspunkt für die
Berechnung weiterer Generation. Der Algorithmus (siehe Abbildung 4.4) ist beendet, falls
keine lebenden Zellen mehr gibt oder der Benutzer die Simulation abbricht. Die detaillierte
datenbankbasierte Umsetzung findet sich in Kapitel 6.1.
4.2.2 Analyseprozesse
Im folgenden Abschnitt wird der in der Abbildung 4.4 aufgeführte Monitoring-Prozess
diskutiert und die einzelnen Konzeptionen der Analyse erläutert. Abgesehen von einer
späteren datenbankbasierten Umsetzung, werden allgemeine Lösungsverfahren für die einzelnen Analysefunktionen des Monitoringsystems entwickelt. Der Monitoring-Prozess setzt
sich aus der Clusterbestimmung, der Klassifizierung und der Berechnung einer Kollisionswahrscheinlichkeit der Cluster zusammen. Diese Prozesse werden hier erläutert, zusätzlich
kommen im nächsten Abschnitt 4.3 die Funktionen der Visualiserungaspekte hinzu. Eine
Schlüsselrolle nimmt dabei die Clusterbestimmung ein, welche stets vor allen Analyseprozessen als erstes durchgeführt werden muss, da diese auf die Ergebnisse der Clusterbestimmung aufbauen. Zusätzlich muss vor der Berechnung einer Kollisionswahrscheinlichkeit die
Klassifizierung der Cluster erfolgen, da die Gleiter das Ergebnis beeinflussen können. Die
weiteren Analysen sind voneinander unabhängig und können in beliebiger Reihenfolge
durchgeführt werden. Die Rauten in der Abbildung 4.5 geben die Auswahl des Anwenders
wieder, ob eine Funktionen aktiviert wurden oder nicht.
Abbildung 4.5: Monitoring
50
4.2 Konzeption von Simulations- und Analyseprozessen
Clusterbestimmung
Vorliegend gibt es eine Anzahl von lebenden Zellen im Raum RA des zellulären Automaten, die nach Clustern zu kategorisieren sind (siehe Beispiel Abb. 4.1). Grundlegendes Ziel
dieser Ereignisüberwachung ist es, zu analysieren, welche Zellen mit welchen Zellen über
einen Zellenpfad zu erreichen sind. Es ließen sich dadurch Zusammenhangskomponenten
bilden, die nach obiger Definition einem Cluster entsprechen würden. Eine Möglichkeit
der Realisierung wäre die komplette Struktur des noch imaginären Graphen, also alle
möglichen Zellenpfade der Zellen untereinander zu berechnen, darzustellen und diese dann
mit bekannten Graphtraversierungs-Algorithmen zu durchlaufen und in Zusammenhangskomponenten bzw. in Cluster zu ordnen. Die Darstellung der kompletten Struktur ist aber
gar nicht notwendig.
Um den Aufwand zu minimieren, wird zunächst untersucht welche Berechnungen
überhaupt notwendig sind. Es gibt eine Möglichkeit, nur die notwendigsten Zellenpfade zu analysieren, redundante Berechnungen zu vermeiden und durch den Prozess der
Zellenpfad-Analyse direkt zu bestimmen, welche Zellen welches Cluster bilden. Ein Schritt
zu höherer Performanz ist es, im Gegensatz zur naiven Vorgehensweise, je Zelle nur einen
Zellenpfad zu analysieren. Die Idee ist, dass für alle Zellen der Zellenpfad hin zur kleins”
ten“ erreichbaren lebenden Zelle durchlaufen wird. Daraus ergibt sich der Vorteil, dass
Zellen die eine gleiche kleinste“ Zelle erreicht haben, auch zu einem gemeinsamen Cluster
”
gehören. Das folgt aus der simplen Tatsache, dass diese Zellen dann über einen Zellenpfad
zueinander zu erreichen sind. Was eine notwendige und hinreichende Bedingung bezüglich
eines gemeinsamen Clusters ist. Diese kleinste“ Zelle wird als Identifikations-Zelle eines
”
Clusters bezeichnet. Es wird für jede lebende Zelle nur ein Zellenpfad durchlaufen, die
Identifikationszelle zugeordnet und somit die lebenden Zellen in Cluster gruppiert.
Zur Umsetzung, welche lebende Zelle als kleinste“ zu betrachten ist und welche lebende
”
Zelle im ersten Schritt des Algorithmus welchem Clusternachbarn zuzuordnen ist, wird
folgende Ordnung verwendet. Die Ordnung bezieht sich dabei auf die kartesischen Koordinaten des Raums RA .
(x1 , y1 ) <Koord. (x2 , y2 ) ⇔ {y1 < y2 ∨ (y1 = y2 ∧ x1 < x2 )}
Wird im Weiteren von einer kleineren“ oder kleinsten“ Zelle gesprochen, dann ist dies
”
”
immer in Bezug zu dieser Ordnung über den Koordinatenpaaren zu verstehen. Bei diesem
Verfahren wird der Pfad für jede lebende Zelle hin zur kleinsten erreichbaren lebenden
Zelle durchlaufen“. Es muss nicht der ganze Pfad dargestellt werden, vielmehr ist es
”
ausreichend, nur die aktuell erreichte Zelle, der Zelle von der der Pfad durchlaufen wird,
zuzuordnen.
Um keine unnötigen Rechenoperationen durchzuführen, werden Pfad-Durchläufe nicht redundant für andere Zellen wiederholt. Das bedeutet konkret, dass eine Zelle A, die in einem
51
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
Schritt, eine Zelle B zugeordnet bekommt, nicht den Zellenpfad den die Zelle B schon
zurückgelegt“ hat nachvollziehen muss, sondern den aktuell erreichten Knoten der Zelle
”
B direkt zugeordnet bekommt. Das heißt, dass das kostenintensive Auffinden des kleinsten
Clusternachbarn einer Zelle nur zu Beginn einmal berechnet werden muss (siehe Abbildung 4.6). Die durch diese Zuordnung entstanden Zellenpfade der Länge 1 können dann
genutzt werden, um den Zellenpfad mittels transitiver Verknüpfungen, für die lebenden
Zellen zu durchlaufen.
Abbildung 4.6: Auffinden des kleinsten Clusternachbarn
Die wenigsten Zuweisungen wären möglich, wenn von den kleinsten Zellen hin zu den
größten Zellen eine Zuweisung stattfinden würde. Dann würden bei N Zellen, im worst case nur N sequentielle Zuweisungen nötig sein. Es bleibt aber die Frage offen, wie performant
so eine eher satzorientierte Realisierung hinsichtlich dieser Reihenfolge der Zuweisungsoperationen ist.
Eine andere Möglichkeit wäre, die Zellen parallel“ zu betrachten, also mengenorientiert in
”
einem Iterationsschritt den jeweiligen kleinsten Zellen zuzuweisen. Wenn also einer lebenden Zelle A, als kleinster Clusternachbar die lebende Zelle B zugeordnet wird und dieser
Zelle B, als kleinster Clusternachbar die lebende Zelle C, dann wird in der nächsten Iteration der Zelle A die Zelle C zugeordnet. Dies wird nur durchgeführt, wenn die Zelle A 6= B
ist. In derselben Iteration könnte die Zelle C eine weitere Zelle zugeordnet bekommen, die
der Zelle A in der übernächsten Iteration zugeordnet wird. Die Länge des Zellenpfades,
die die Zelle A pro Iteration zurücklegt, steigt bei einem parallelem Durchlauf exponentiell
an (1,2,4,8...). Die Iteration ist beendet, wenn die einzelnen Zellen keine kleineren Zellen
mehr zugewiesen bekommen können. Der worst case von Zuweisungen bei diesem Verfahp
√
ren wäre (N + 1) ∗ (N/2) und N Iterationen.
Grundsätzlich lässt sich festhalten, dass die Durchführung einer transitiven Verknüpfung
eine wesentlich performantere Vorgehensweise, als das wiederholende explizite Auffinden
eines kleinsten Clusternachbarn, ist. Dies ist relativ aufwendig, da für alle lebenden Zellen
8 Nachbarschaftszellen überprüft werden müssen, welche die jeweils zugehörige kleinste
Zelle ist, die mindestens eine dieser Nachbarschaftszellen teilt.
52
4.2 Konzeption von Simulations- und Analyseprozessen
Abbildung 4.7: Zwei Möglichkeiten einer Realisierung
Da nicht die vollständige Struktur dargestellt wird, ist hier aber auf eine Ausnahme zu
achten. Es kann Konstellationen geben, in denen der Pfad von Zellen zu einer anderen lokal
kleinsten Zelle führt, als zur eigentlichen Identifikations-Zelle des Clusters. Lokal bedeutet
hier, dass lebende Zellen zu einer Zelle in ihrer Clusternachbarschaft hin verknüpft werden,
die den Pfad zur eigentlichen Identifikations-Zelle des Clusters nicht mehr zulässt. Diese
Verknüpfung wird aber durchgeführt, da sie die aktuell kleinste Zelle in der Clusternachbarschaft ist. Bei dieser Ausnahme erreichen die Zellen in einem Cluster unterschiedliche
Zellen am Ende ihres Pfades, ein Cluster unterteilt sich dann in Teil-Cluster. Die Zellen,
die bei der Abbildung 4.8 der tatsächlich kleinsten Zelle, also der Identifikations-Zelle des
Clusters zugeordnet worden sind, sind blau dargestellt. In diesem Beispiel kommt es sogar
zu mehreren Teil-Clustern.
Abbildung 4.8: Ausnahmefall
Hat man den Zellenpfad bestimmt, so ist zu überprüfen ob jede Zelle im Vergleich zu ihren
Clusternachbarn auch die kleinste Zelle zugeordnet bekommen hat. Ist dies nicht der Fall
muss eine Ausnahmebehandlung durchgeführt werden. Sind sogar mehrere Teil-Cluster wie
in Abbildung 4.8 entstanden, so gibt es, wie bei dem Analyseprozess der Zellenpfade zwei
Möglichkeiten einer Umsetzung. Die Behandlung kann auf zwei Arten durchgeführt werden. Eine Option ist eine aufsteigende Zuweisung bei den Teil-Clustern beginnend, welche
53
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
den kleinsten Cluster als Nachbarn haben. Eine weitere Option ist die mengenorientierte und iterative Zuordnung der jeweiligen Teil-Cluster zu ihren individuellen kleinsten
Clusternachbarn. Falls keine Ausnahme eintritt oder die bestehende behoben ist, ist der
Algorithmus beendet. Die detaillierte datenbankbasierte Umsetzung des vollständigen Algorithmus (siehe Abbildung 4.9) wird in Kapitel 6.2 erläutert.
Abbildung 4.9: Algorithmus zur Clusterbestimmung
Dieses Verfahren hat die Voraussetzungen für eine optimale Umsetzung einer Clusterbestimmung. Die Berechnungen für das Auffinden eines kleinsten Clusternachbarn werden
auf ein Minimum reduziert. Es wird nur zu Beginn durchgeführt und bei eventuellen auftretenden Ausnahmen. Ein ausschlaggebender Faktor ist, dass nur die notwendigsten Zellenpfade bestimmt werden, die für die Definition eines Clusters notwendig sind. Im Gegensatz
zu einer naiven Vorgehensweise, bei der jeder Pfad analysiert wird (und möglicherweise
auch vollständig dargestellt wird). Die transitiven Verknüpfungen führen zu einem äußerst
performanten Pfad-Durchlauf, da redundante Berechnungen vermieden werden. Die Verknüpfung beginnend von der kleinsten Zelle aufsteigend hin zur größten Zelle bringt den
Vorteil, dass die wenigsten Zuweisungen stattfinden, dafür muss aber bei jeder dieser Operationen die Ordnung der sequentiellen Zuweisung umgesetzt werden. Bei einer parallelen
Betrachtung aller Zellen in einer Iteration, werden redundante Pfad-Durchläufe vermieden,
54
4.2 Konzeption von Simulations- und Analyseprozessen
durch den Verzicht auf eine ordnungsbezogenen Umsetzung werden jedoch mehr Zuweisungen benötigt. Es gilt das Optimalitätsprinzip von Bellmann: Die optimale Lösung für
ein Problem der Größe n setzt sich aus optimalen Teillösungen kleinerer Größen zusammen. Ein weiterer Vorteil dieses Verfahrens ist, dass durch die Pfad-Bestimmung direkt
die Cluster durch die kleinste Zelle (der Identifikationszelle) bestimmt werden. Desweiteren kann aus den Koordinaten dieser Zelle eine eindeutige ClusterID gebildet werden.
Bei der naiven Vorgehensweise müssten ansonsten nach der Pfad-Analyse, die Pfade noch
ausgewertet werden, worauf bei diesem Verfahren verzichtet werden kann.
Klassifizierung der Cluster
Die Verfahren der Klassifizierung der Cluster, welche zur Ereignisüberwachung des Monitoringsystem zählen, lassen sich mit zwei möglichen Varianten umsetzen. Ein Weg wäre,
die Cluster nach deren Eigenschaften hin zu untersuchen und mittels dieser Erkenntnisse
eine Entscheidung für eine Klassifizierung zu treffen. Eine andere Möglichkeit ist, die Cluster mit bereitgestellten Mustern abzugleichen und mittels einer Identifizierung die Cluster
einzuordnen.
Bei der Erfassung der statischen Cluster ist der ersten Idee, aufgrund der spezifischen
Eigenschaften, die diese Objekte aufweisen, der Vorzug zu geben. Dadurch, dass diese speziellen Cluster in jeder Generation, soweit sie nicht mit anderen kollidieren, in der gleichen
Konstellation und am gleichen Ort verharren, kann direkt nach Beginn der Analyse, in der
Folgegeneration, diese Klassifizierung erfolgen. Es ist dafür nur ein detaillierter Abgleich
jeder Zelle der Cluster in der aktuellen Generation t, mit den Clustern in der Generation
t − 1 durchzuführen.
Die Untersuchung der Cluster hinsichtlich einer Einordnung in die anderen beiden hier
berücksichtigten Klassen, den Gleitern und den Oszillatoren, erweist sich als komplizierter. Bei der Wahl, die Cluster nach spezifischen Eigenschaften zu untersuchen, ergibt sich
das Problem, dass bei den Oszillatoren und Gleitern erst nach einer gewissen Zeit erkennbar wird, ob diese Cluster wieder zu ihrer Ausgangskonstellation zurück finden. Was hier
mit einer gewissen Zeit gemeint ist, ist die Periode des Zyklus eines Clusters dieser Klassen. Es müsste also von allen Clustern die vergangenen Konstellationen verfolgt und bis zu
einer bestimmten Zeit-Differenz mit dem aktuellen Zustand der Cluster verglichen werden
(mit Berücksichtigung der Bewegung der Gleiter). Entscheidende Einschränkung für dieses Verfahren ist, dass Cluster mit einem großen Zyklus gar nicht erfasst werden können.
Weiterhin ist das Verfahren sehr aufwendig es würde erst nach einer gewissen Anlauf”
phase“ zu Ergebnissen kommen. Daher wird im Folgenden, gegensätzlich zur Analyse der
statischen Cluster, die zweite Variante des Klassifikationsprozesses gewählt. Allerdings ist
der Nachteil dieses Verfahrens, dass keine neuen unbekannten Objekte ausfindig gemacht
werden können, da nur mit bekannten Mustern verglichen wird.
55
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
Zum Prozess der Identifizierung der Cluster müssen diverse Muster bekannter Objekte
von den hier berücksichtigten Klassen gespeichert werden. Bei der Identifizierung eines
Clusters durch den Abgleich mit einem Muster, ist direkt die Klassifiierung gewährleistet,
ob es sich beispielsweise um einen Oszillator oder um einen Gleiter handelt. Um unnötige
Abgleichungen zu vermeiden, werden nur die Cluster mit den Mustern verglichen, die dieselbe Anzahl an lebenden Zellen besitzen. Das Hauptproblem einer Realisierung ist es
nunmehr, einen performanten Vergleich zu bewerkstelligen. Dieser Prozess geschieht im
Hinblick darauf, ob die Muster in verschiedenen Ausrichtungen gespeichert werden oder
ob dies bei der Prozedur der Identifizierung berücksichtigt werden muss.
Berechnung der Kollisionswahrscheinlichkeit
Die Richtung der Gleiter ist bei der Analyse der Kollisionswahrscheinlichkeit involviert. Zur Ermittlung der Richtung der einzelnen Gleiter werden hier zwei verschiedene
Möglichkeiten einer Realisierung vorgestellt. Die einfachste wäre, bei den Mustern der
Gleiter, mit denen sie bei der Klassifizierung identifiziert werden, die Bewegung anzugeben und zu übernehmen. Eine andere Möglichkeit wäre, die Bewegung über mehrere Generationen zu verfolgen und zu ermitteln. Da es sich um eine prototypische Realisierung
handelt, wird bei dieser Implementierung die zweite komplexere Auswertung vollzogen.
Damit kann evaluiert werden, inwieweit datenbankbasiert die Analyse eines Bewegungsablaufes eines Clusters und die Erstellung einer Prognose über seine Richtung, möglich ist.
Da sich die genaue Richtung erst nach mehreren diskreten Zeitschritten detailliert ermitteln lässt, ist es notwendig, in jeder Runde die aktuelle Richtung bzw. Ausbreitung des
Gleiters zu betrachten und über einen längeren Zeitraum die Ergebnisse inkrementell zu
optimieren. Um dies gewährleisten zu können, müssen die Gleiter über die Zeit hinweg
identifiziert und die aktuelle Bewegung stetig ermittelt werden.
Bei der Implementierung der Kollisionswahrscheinlichkeit müssen verschiedene Faktoren
betrachtet werden. Es stellt sich die Frage, wie genau die Wahrscheinlichkeit einer Kollision berechnet werden soll und welchen Aufwand man bereit ist dafür in Kauf zunehmen.
Die naive Vorgehensweise wäre im ersten Schritt, alle Zellen der Cluster mit allen Zellen
der anderen Cluster zu vergleichen und somit eine genaue Distanz zu ermitteln, was allerdings zu einer hohen Anzahl von numerischen Berechnungen führen würde. Eine andere
Möglichkeit wäre, nur die einfach zu extrahierenden Eckpunkte der Cluster zu betrachten und anhand dieser die Distanz zu den Eckpunkten der anderen Cluster zu berechnen.
Dies würde allerdings in spezifischen Situationen Ungenauigkeiten mit sich bringen, siehe
Abbildung 4.10. Eine weitere Idee ist die Betrachtung der Randpunkte“ eines Clusters,
”
womit die äußeren Zellen eines Clusters gemeint, was besonders bei größeren Objekten
sinnvoll erscheint. Die anfallenden Kosten dieser Umsetzung müssen bei einer Realisierung berücksichtigt werden.
56
4.2 Konzeption von Simulations- und Analyseprozessen
Abbildung 4.10: Hohe Kollisionsgefahr
Abbildung 4.11: Prozess der Kollisionswahrscheinlichkeit
Der Algorithmus (siehe Abbildung 4.11) der folgenden Umsetzung beruht darauf, die teilweise oben erwähnten Vorschläge miteinander zu verknüpfen. Es würde wahrscheinlich
zu einer erhöhten Performanz führen, zuerst die allgemeinen Cluster-Abstände durch Betrachtung der Eckpunkte zu ermittelt. Dies würde mit wenig Berechnungsaufwand zu
57
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
einer groben Extraktion der Cluster führen, die dann für eine detaillierte Analyse in Betracht kommen. Es ist wieder in Bezug zur einer späteren datenbankbasierten Umsetzung zu untersuchen, mit welchen Kosten so eine Vorauswahl verbunden wäre. Bei der
weiterführenden Analyse soll die Wahrscheinlichkeit einer Kollision mit hoher Präzision
berechnet werden. Es ist jedoch dabei immer abzuwägen, wie viele Zellen durchschnittlich
betrachtet werden, wie groß der zu überwachende Raum ist und wie viel Durchführungszeit
man für diese Operation aufwenden möchte. Die Entscheidung hätte dann auch anders ausfallen können. Bei dem Aspekt der detaillierten Analyse muss ebenso eine Evaluierung in
Bezug zu dem Berechnungsaufwand stattfinden, ob es performanter ist, die Randwerte
der Cluster zu ermitteln und mit diesen die weitere Analyse durchzuführen, oder mit den
gesamten Zellen eines Clusters. Der nächste Schritt in diesem Prozess ist die Ermittlung
der betreffenden Gleiter. Es wird im Hinblick auf ihre befindliche Richtung untersucht, ob
sie sich auf ein in der nähe befindliches Cluster zu oder von ihm weg bewegen, mit Einfluss
auf die vorher errechnete Distanz und damit die Prognose einer Kollision.
4.3 Erweiterung des Entwurfs um Visualisierungskonzepte
Das im Rahmen dieser Arbeit erstellte Monitoringsystem wird um weitere Komponenten
ergänzt, die graphisch verschiedene Analyseergebnisse widerspiegeln. Es wird zunächst das
Prinzip und die Umsetzung der Visualisierungskonzepte diskutiert und anschließend der
Datenbankentwurf um diese Aspekte erweitert.
4.3.1 Prinzip des Visualisierungaspektes
Bei der graphischen Darstellung verschiedener Analyseergebnisse im Raum des zellulären
Automaten müssen explizit neue Komponenten entwickelt werden. Es wird im Folgenden
das Prinzip der bounding box, der Trajektorie und der Evolutionsumgebung aufgezeigt.
Beim Prozess der Visualisierung, kann die Trajektorie und die Evolutionsumgebung selbst
unabhängig voneinander aktiviert werden (siehe Abbildung 4.12). Die bounding box hingegen ist abhängig von der Aktivierung der Clusterbestimmung und wird falls sie aktiviert
ist automatisch durchgeführt. Die Rauten bei der Abbildung 4.12 bedeuten somit, die Auswahl des Anwenders und für die bounding box ob die Clusterbestimmung durchgeführt
wurde.
Abbildung 4.12: Visualisierung
58
4.3 Erweiterung des Entwurfs um Visualisierungskonzepte
Ein Ergebnis der Analyse des Monitoringsystems ist die Gruppierung von einzelnen Zellen
zu Clustern. Dieser Zuordnung soll nun visuell durch eine Umrandung der Cluster Ausdruck verliehen werden. Eine Umrandung könnte die lebenden Zellen eines Clusters detailliert eingrenzen und als eine direkte Begrenzung ihrer Ausbreitung dargestellt werden.
Eine detaillierte Umrandung, mit der vorhergehenden Erfassung der Zellen, die sich am
Rande eines Clusters befinden, würde aber auch zu einer aufwendigeren Analyse führen.
Der Nutzen dadurch wäre begrenzt, da die detaillierte Ausbreitung eines Clusters auch so
ersichtlich ist. Es geht bei diesem Aspekt vielmehr darum, dem Anwender zu zeigen, welche Zellkonstellationen ein Cluster bilden und sich dadurch von anderen abgrenzen. In der
Computergraphik wird eine einfache rechteckige Form, die eine komplexe Form eingrenzt
als bounding box bezeichnet, welche auch hier verwendet und als Objekt eingeführt
wird. Die bounding boxes werden rötlich gefärbt, wenn die von Ihnen umrandeten Cluster
eine erhöhte Kollisionsgefahr aufweisen
Abbildung 4.13: bounding box
Eine weitere graphische Komponente ist die Trajektorie (siehe Abbildung 4.14), welche
den Weg eines Clusters über einen Zeitraum darstellt. Der Verlauf wird für jede Trajektorie in unterschiedlichen Farben dargestellt und zeichnet sich durch einen Pfad von Zellen
ab, die den Ort eines Clusters zu einer bestimmten Zeit markieren. Diese Zellen im Weiteren als charakteristische Zellen benannt, sind durch die Ermittlung des jeweiligen
Mittelpunktes eines Clusters bestimmt. Das Monitoringsystem ermittelt bei dieser Prozessüberwachung den Verlauf der einzelnen Cluster über die Generationen hinweg. Bei der
jeweilige Identifizierung der Cluster über Generationen, muss überprüft werden ob es zu
einer Aufspaltung oder Vereinheitlichung von Clustern gekommen ist, was dann zu neuen
Trajektorien führen würde.
59
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
Abbildung 4.14: Trajektorie
Beim Konzept der Trajektorie handelt es sich um eine lokal auf Cluster beschränkte Visualisierung von Bewegungen. Der folgende Aspekt der Konzeption hingegen ist eher globaler
Natur und zielt darauf ab, über die Zeit einen Raum einzugrenzen, in welchem sich einzelne Cluster ausgebreitet“ und mit anderen vereinigt haben. In Analogie zum realen Leben
”
könnte man sagen, es folgt die Ermittlung der Gebiete aus denen sich einzelne Stämme
vermischt, entwickelt und ausgebreitet haben. Der ermittelte Raum wird Evolutionsumgebung genannt. Dies bedeutet, in Bezug zu einem betrachteten zellulären Automaten,
dass die Räume der Vorfahren“ von Clustern ermittelt werden, bzw. von den Vorfahren
”
ausgehend, der Raum ihrer Ausbreitung. Diese Untersuchung findet in Zusammenhang zu
den ausgehenden Clustern bei der Aktivierung dieser Überwachung statt. Weiterführend
heißt das, wenn sich beispielsweise ein Cluster aufspaltet, bestimmen fortan beide Nach”
kommen“ mit ihren jeweiligen Grenzwerten der räumlichen Ausbreitung, die Erweiterung
der Evolutionsumgebung. Die Ausdehnung der Evolutionsumgebung kann dabei nur monoton wachsen. Es werden also partielle Räume des zellulären Automaten hervorgehoben,
die das Zusammenwirken und die Verflechtung einzelner Cluster visuell nachvollziehen.
Bei diesem Aspekt des Monitoringsystems handelt es sich um eine Prozessüberwachung,
da inkrementell über mehrere Generationen die Entwicklung nachvollzogen wird, ohne nur
auf einen spezifischen Zustand hin die Zellen zu überwachen (siehe Abbildung 4.15).
Folgend wird die Konzeption der erweiterten Aspekte betrachtet. Die bounding box kann
leicht durch eine Abfrage der größten und kleinsten x- und y-Koordinate der betreffenden
Cluster mit der Addition bzw. Subtraktion um eine Einheit realisiert werden. Die Realisierung der Trajektorie und der eingeführten Evolutionsumgebung ist hingegen komplizierter.
Um eine Betrachtung des Verlaufes der ausgewählten Cluster zu erreichen, ist zur Ermittlung der Trajektorie unabdingbar, eine Identifizierung der Cluster von einer Generation
zu der Folge-Generation zu gewährleisten. Nach dieser Identifizierung müssen die aktuellen
60
4.3 Erweiterung des Entwurfs um Visualisierungskonzepte
Abbildung 4.15: Evolutionsumgebungen
Cluster ihren Trajektorien zugewiesen werden. Bei der Durchführung dieser Analyse muss
ermittelt werden, ob sich ein Cluster aufgespalten hat oder es mit einem anderen kollidiert
ist. Beim Eintreten einer dieser Fälle wird eine neue Trajektorie initialisiert. Nach diesem
Schritt wird die charakteristische Zelle des aktuell zur Trajektorie zugehörigen Clusters
berechnet. Es wird dabei eine Historie der Trajektorien und ihren charakteristischen Zellen
angelegt. Bei einer Darstellung der Trajektorie werden dann die charakteristischen Zellen
extrahiert und je Instanz in unterschiedlichen Farben ausgegeben.
Bei der Aktivierung der Evolutionsumgebung werden alle bounding boxes der aktuellen
Cluster und ihre Ausbreitung ermittelt. Mit diesen Werten werden Evolutionsumgebungen
inititalisiert und diesen die bounding boxes zugeordnet. Um den Evolutionsumgebungen
die aktuellen Cluster zuzuordnen welche sie beeinflussen, muss wie bei der Trajektorie bei
jedem Generationswechsel verfolgt werden, welches Cluster aus welchem folgt. Bei dieser
globalen Komponente des Monitoringsystems werden alle Cluster betrachtet und nicht nur
ausgewählte. Nach den einzelnen Zuweisungen der aktuellen Cluster muss ermittelt werden, inwieweit die Evolutionsumgebung durch diese bounding boxes aktualisiert werden
muss. Es müssen die einzelnen Grenzwerte der Ausbreitung miteinander verglichen werden
und die größten bzw. kleinsten bestimmt werden. Darauf hin wird die Evolutionsumgebung gegebenenfalls aktualisiert bzw. erweitert. Im Gegensatz zur Trajektorie werden bei
einer Cluster-Aufspaltung keine neuen Evolutionsumgebungen initialisiert. Beim Wunsch
einer visuellen Darstellung, werden für jedes Cluster ausgehend von der Generation der
Aktivierung diese ermittelten Werte ausgegeben. Eine detaillierte datenbankbasierte Umsetzung findet sich in Kapitel 6.3.
61
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
4.3.2 Erweiterung des Datenbankentwurfs
Zunächst die Erweiterungen des konzeptuellen Datenbankentwurfs. Die bounding
box, die auch als Attribut dem Cluster zugeordnet werden könnte, wird zur Verdeutlichung und Abhebung der erweiterten Aspekte und zur weiteren Integration mit anderen
Entity-Typen als Entity-Typ dargestellt. Sie wird durch eine grenzt ein-Beziehung mit
dem Cluster verbunden. Es wird zur Visualisierung stets nur die aktuelle bounding box
betrachtet, somit genügt ein Relationship-Typ gehört zu ohne Zeitstempel. Die Instanzen
dieses Typs sind ausreichend durch die Eckpunkte (Minx, Maxx, Miny, Maxy) der Umrandung charakterisiert.
Die Trajektorie fällt in die Kategorie der Prozessüberwachung und bezieht sich auf
mehrere Generationen. Zur konzeptuellen Darstellung in dem Entwurf eines Spielzustandes wird eine Beziehung mit einem Zeitstempel benötigt. Diese Beziehung verbindet die
Entity-Typen Trajektorie und Cluster. Zusätzlich muss die charakteristische Zelle, die den
Verlauf kennzeichnet, integriert werden. Dazu wird diese Beziehung in der Rolle der charakteristischen Zelle mit dem Entity-Typ Zelle verknüpft. Durch den Umstand, dass sich
Trajektorien überschneiden können, ist es möglich, dass dieselben charakteristischen Zellen zu unterschiedlichen Clustern gehören. Es besteht somit eine N:M-Funktionalität. Bei
einer Aufspaltung eines Clusters oder der Vereinheitlichung zweier Cluster wird eine neue
Trajektorie initialisiert. Es kann aber höchstens eine dieser Zellen in Verbund mit einem
Cluster, einer Trajektorie angehören. Dadurch ergibt sich eine 1:N:M-Beziehung. Diese
Beziehung wird durch den Relationship-Typ liegt auf realisiert.
Zu diskutieren ist die Frage, welcher dieser Typen die charakteristische Zelle zugeordnet
bekommt. Es wird nicht dem Entity-Typ Cluster zugeordnet, da diese Zelle nicht für jedes Cluster berechnet wird. Es handelt sich vielmehr um eine spezifisch, die Trajektorie
definierende Berechnung, als um ein Attribut eines Clusters. Hinzu kommt, dass nicht die
Historie der Cluster dargestellt wird und somit die Beziehung auf die Cluster vergangener
Generationen und ihren charakteristischen Zellen nicht möglich ist. Des Weiteren wird diese Zelle nicht als Attribut der Trajektorie zugeordnet, da die Instanzen dieses Typs durch
mehrere charakteristische Zellen geprägt sind. Somit wird sich hier für die Zuordnung zu
der Beziehung liegt auf entschieden. Es bedingt daher, die relevanten Zellen über die Zeit
als log Eintrag in der liegt auf Beziehung darzustellen.
Die Evolutionsumgebung wird als Entity-Typ dargestellt, die in einer erweitert durchBeziehung mit der bounding box steht, wodurch angegeben wird, welche aktuellen Instanzen der bounding box die Evolutionsumgebungen beeinflussen. Wie die bounding box,
beinhaltet die Evolutionsumgebung als Attribut die Eckpunkte ihrer räumlichen Ausdehnung. In erweitert durch werden keine weiteren Attribute hinzugefügt, da die Werte der
Evolutionsumgebung in jeder Generation mittels der zugehörigen bounding box inkrementell modifiziert werden. Es ist im Gegensatz zur Modellierung der Trajektorie nicht nötig,
die Zuordnungen der Instanzen über die Zeit darzustellen. Es ist stets die aktuelle Evo-
62
4.3 Erweiterung des Entwurfs um Visualisierungskonzepte
Abbildung 4.16: Trajektorie als Entity-Typ
lutionsumgebung von Interesse. Bei dieser global betrachteten Analysefunktion wird auf
eine nähere Angabe, durch welche Cluster sie im einzelnen geprägt wurde verzichtet. In
diesem Fall handelt es sich um eine partielle Zuordnung, da es Evolutionsumgebungen
geben kann, die aktuell keinem Cluster mehr zugeordnet werden können, da diese Zellen
gestorben sind. Die Funktionalitäten sind N:M, da mehrere Cluster zu einer Evolutionsumgebung gehören können und umgekehrt.
Somit ergibt sich der vollständige konzeptuelle Entwurf mit den vorher eingeführten Objekten (siehe Abbildung 4.17)
Es folgt die Erweiterung des logischen Datenbankentwurfs. Zu der Tabelle, welche
die Trajektorie darstellt, gehört zunächst die ID der Trajektorie. Der Relationship-Typ
liegt auf des ER-Schemas kann entweder durch eine eigene Tabelle dargestellt werden,
oder wenn es die Funktionalitäten zulassen, in eine Tabelle eines Entity-Typen eingebettet werden. Da es sich um eine 1:N:N-Beziehung zwischen den Entity-Typen Trajektorie,
Cluster und Zelle handelt, es die Funktionalität also zulässt, wird sie in die Tabelle Trajektorie eingebettet. Zu der ID der Trajektorie kommen noch die Attribute ClusterID,
Generation und die Werte der charakteristischen Zelle hinzu. Es wird keine Historie der
Cluster gespeichert und somit kann auch nicht auf vergangene Cluster verwiesen werden.
Dies ist zur Darstellung der Trajektorie auch nicht nötig, da die relevanten Werte der
charakteristischen Zelle, welche die Trajektorie definieren, mit ihr gespeichert sind. Die
63
4 Datenbankentwurf und Konzeption von Simulations- und Analyseprozessen
ClusterID ist hierbei nur in der aktuellen Generation notwendig um die Cluster durch
die eingeführte folgt aus Tabelle über einen Generationswechsel zu identifizieren. Bei der
Relation der bounding box liegt eine 1:1-Beziehung mit dem Cluster vor, wodurch diese
Beziehung in die bounding box integriert werden kann. Die ClusterID wird der Einfachheit
halber und zur Vermeidung späterer unnötiger Verweise auch zur ID der bounding box.
Bei der Beziehung bestimmt durch liegt eine N:M-Funktionalität vor, somit wird diese Beziehung nicht in eine der beiden Tabellen eingebettet, sondern wird einzeln dargestellt,
ebenso die Evolutionsumgebung.
Abbildung 4.17: Vollständiger konzeptueller Entwurf
Es ergeben sich somit zusätzliche Tabellen:
Trajektorie:{TrajektorieID,aktuelle ClusterID,Generation,x,y}
bouding box:{ClusterID, Minx, Maxx, Miny, Maxy}
erweitert durch:{TrajektorieID,ClusterID}
Evolutionsumgebung: {EvolutionsumgebungID, Minx, Maxx, Miny, Maxy}
erweitert durch:{EvolutionsumgebungID,ClusterID}
64
5 Architektur und Funktionalität des
Life-Monitoringsystems
Dieses Kapitel der vorliegenden Diplomarbeit befasst sich mit dem Aufbau und den bereitgestellten Funktionalitäten des implementierten Systems. Das erstellte System der datenbankbasierten Umsetzung, dass auf der Grundlage eines zellulären Automaten operiert,
wird im folgendem einheitlich als Life-Monitoringsystem benannt. Es wird in Kapitel
5.1 die Architektur des Gesamtsystems und die innehabenden Komponenten erläutert.
Ein Augenmerk richtet sich auf die Komponente des Controllers und seiner internen Synchronisation. Im Kapitel 5.2 wird die Interaktion der globalen Komponenten des Systems
erläutert. Im letzten Abschnitt dieses Kapitels werden die graphische Benutzeroberfläche
und die interaktiven Zugriffsmöglichkeiten des Nutzers diskutiert.
5.1 Architektur des Gesamtsystems
Das implementierte Life-Monitoringsystem wird in drei verschiedenen Komponenten zergliedert (siehe Abbildung 5.1). Eine Komponente ist das Frontend und beinhaltet die
graphische Benutzeroberfläche (GUI, graphical user interface). Der Anwender hat die
Möglichkeit, über diese Benutzeroberfläche mit dem System zu interagieren. Die Komponente, die mit dem GUI in Verbindung steht, ist die Middelware, welche den Controller
des Life-Monitoringsystems darstellt. Dieser Controller steuert die Synchronisation zwischen dem Datenbanksystem (DBS), dem GUI und den internen Operationen. Über
die Schnittstelle JDBC wird auf das Datenbankmanagementsystem (DBMS) zugegriffen.
Beide Komponenten sind Teil des Programms, programmiert in der Sprache Java. Die
dritte Komponente, das Backend, besteht aus dem erwähnten DBS. Das DBS besteht aus
dem DBMS und den Sichten und Tabellen, auf die es zugreift. Da es sich bei diesem System um eine datenbankbasierte Realisierung handelt, werden im Backend weitestgehend
die notwendigen Operationen des Systems bereitgestellt und die Daten gespeichert. Das
detaillierte Datenbankschema wurde in Kapitel 4 eingehend erläutert. Der Aufbau und die
dargebotenen Funktionen des GUI werden in Kapitel 5.3 betrachtet. Es wird sich zunächst
mit dem internen Aufbau und Funktionen des Controllers beschäftigt. In 5.2 folgt dann
die Betrachtung der Interaktion der globalen Komponenten
65
5 Architektur und Funktionalität des Life-Monitoringsystems
Abbildung 5.1: Globale Architektur des Life-Monitoringsystems
Der Controller (siehe Abbildung 5.2) , der in der Position der Middleware zwischen dem
Frontend und dem Backend vermittelt, lässt sich in fünf Komponenten mit verschiedenen
Aufgabenbereichen unterteilen.
ˆ GUI-Manager: Interaktion mit dem GUI
ˆ Simulations-Manager: Simulation des Game of Life“
”
ˆ Analyse-Manager: Analyse des Spielgeschehens
ˆ Scheduler: Interne Synchronisation und Aufgabenverteilung des Systems
ˆ DB-Manager: Interaktion mit der DB
Der GUI-Manager ist zuständig für die Darstellung des GUI und mit dessen Kommunikation. Durch diesen Manager kann der Anwender mit dem System interagieren.
Dem Benutzer wird durch das GUI die Möglichkeit geboten, extern Einfluss auf das LifeMonitoringsystem zu nehmen und interaktiv zu steuern. Durch das dargestellte Spiel”
feld“, dem visualisierten Raum des zellulären Automaten, wird die Anfangskonstellation
bestimmt und die Ergebnisse werden präsentiert.
Der DB-Manager ist die Komponente, die über JDBC eine Verbindung mit dem DBS
herstellt. Es werden verschiedene Methoden angeboten um Befehle an das DBS abzusetzen. Siehe dazu Kapitel 5.2 .
Der Simulations-Manager übernimmt die Aufgabe, die Simulation und damit das eigentliche Simulations-Spiel des GOL zu steuern. Zu Beginn eines Spiels werden vom
Simulations-Manager über den GUI-Manager, die vom Anwender initialisierten lebenden
66
5.1 Architektur des Gesamtsystems
Abbildung 5.2: Interaktion der Komponenten des Controller
Zellen dem DBS zugeführt. Die weiterführenden Aufgaben, sind durch den DB-Manager
und der Kommunikation mit dem DBS, die nächsten Generationen berechnen zu lassen
und diese dem GUI-Manager zuzuführen. Der Anwender hat auch die Möglichkeit, mehrere Generationen simulieren zu lassen ohne dass zwischendurch eine graphische Darstellung
erfolgt. Diese Möglichkeit bietet eine höhere Perfomanz, im Gegensatz zu einer integrierten
Ausgabe einzelner Generationen. Die einzelnen Methoden dieser Klasse sind im Folgenden:
ˆ Initialisierung: Führt über den DB-Manager dem DBS die Anfangskonstellation zu.
ˆ Generationsberechnung: Steuert die datenbankbasierte Berechnung der nächsten Generation.
ˆ Visualisierung: Übergibt dem GUI-Manager die Ergebnisse.
Der Analyse-Manager ist für die Durchführung der Operationen des Monitoringsystems
verantwortlich. Die in Kapitel 4 betrachteten Analysefunktionen werden von dem Manager gesteuert und datenbankbasiert umgesetzt. Die Analysen werden anhand der aktuellen
Generation zwischen den Generationswechseln vollzogen. Die Methoden, die sich nur auf
eine aktuelle Generation beziehen, beinhalten die Ergebnis-Übergabe an den GUI-Manager
und werden auch nur bei einer erwünschten Ausgabe durchgeführt. Die in Kapitel 4 zur
erweiterten Konzeption zählenden Methoden beziehen sich auf mehrere Generationen, daher existiert eine explizite Methode zur Umsetzung einer graphischen Darstellung. Diese
Analysen müssen auch ausgeführt werden, falls keine Ausgabe je Generation erwünscht
wird.
Die interne Synchronisation des Controllers und den darin enthaltenen aufgeführten Komponenten wird durch den Scheduler bewerkstelligt. Dieser hat die Aufgabe, intern zwischen den einzelnen Ausführungen das Life-Monitoringsystem zu steuern und zu synchro-
67
5 Architektur und Funktionalität des Life-Monitoringsystems
nisieren. Es wird lokal der Simulations- und der Analyse-Manager sowie deren einzelne
Funktionen während einer Generation gesteuert. Zudem wird die Darstellung über den
GUI-Manager synchronisiert, wie auch auf einer höheren Ebene zwischen den drei Komponenten über die Generationen hinweg. Der Scheduler führt die Steuerung gemäß den
Anweisungen, die der Anwender dem System über das GUI zugeführt hat, aus. Die Steuerung bedient sich dabei der in Kapitel 2 erläuterten Threads.
Abbildung 5.3: Synchronisation des Controllers
5.2 Interaktion der globalen Komponenten
Es wurde bisher die interne Interaktion der Komponenten des Controllers betrachtet, nun
wird das Augenmerk auf die Interaktion der oben erwähnten Komponenten des globalen
Systems gerichtet.
Beim Aufruf der Klasse Start und der ihr innehabenden Methode main() wird ein Singleton (auch Einzelstück genannt) der GUI-Klasse erstellt, diese ist abgeleitet von der bereitgestellten Java-Klassenbibilothek der Basisklasse JFrame. In dieser werden die GUIElemente in einem JFrame erzeugt und dargestellt. Durch die Methode actionPerformed()
kann interaktiv vom Anwender das Programm gesteuert werden. Die Befehle werden durch
den Scheduler ausgeführt und an den Simulations- bzw. Analyse-Manager dirigiert. Diese wiederum leiten die Ergebnisse an den GUI-Manager. Die von Swing bereitgestellte
Methode invokeAndWait(), setzt den übergebenen Thread in die Warteschlange der Prozessabarbeitung und wartet den vollständigen Abschluss ab. Diese Vorgehensweise dient
der Synchronisation zwischen dem Controller und dem GUI. Nach Beendigung des Prozesses kann der Scheduler die nächste Operation in Auftrag geben.
68
5.2 Interaktion der globalen Komponenten
Abbildung 5.4: Interaktion zwischen dem GUI und dem Controller
Der DB-Manager stellt mit der Methode Connect() eine Verbindung zum DBMS her. Diese
Verbindung wird mittels JDBC gestaltet und ist wie folgt realisiert:
try{
Class.forName( sun.jdbc.odbc.JdbcOdbcDriver“);
//(1)
”
String url= gol.accdb
//(2)
con DriverManager.getConnection( jdbc:odbc:Driver={Microsoft Access Dri”
ver(*.mdb,*.accdb)}; DBQ= url;“);
//(3)
setConnection(con);
} catch(Execption e)
{
Fehlerbehandlung, falls eine Verbindung zum DBMS misslingt.
}
Der verwendete Treiber (1) der geladen wird, ist eine Datenbankschnittstelle zwischen
einem Java-Programm und einem DBMS, welches einen ODBC-Treiber integriert hat.
Durch die Übergabe des Pfades der Datenbank (2) wird die Verbindung hergestellt (3),
dabei bezeichnet jdbc“ das verwendete Protokoll und odbc“ den Treiber des DBMS.
”
”
Ist eine Verbindung mit dem DBMS erfolgt, können beliebige SQL-Befehle, die der DML
zugeordnet sind abgesetzt werden. Bei diesem Verfahren wird ein so genanntes Statement
kreiert:
69
5 Architektur und Funktionalität des Life-Monitoringsystems
Statement stmt = getConnection().createStatement();
Der Klasse Statement wird die Methode executeQuery(), zur Verwendung einer SELECT Abfrage oder einem Aufruf einer in der Datenbank gespeicherten Aktionquery, als Parameter übergeben. Zur Modifizierung der Daten mittels INSERT, DELETE und UPDATE
wird die Methode executeUpdate() verwendet. Bei einer Abfrage wird das Ergebnis als Objekt vom Typ ResultSet an den DB-Manager zurückgegeben. Die Anzahl der veränderten
Datensätze kann auf Wunsch mit dem absetzen eines Update-Befehls zurückgegeben werden. Das ResultSet und die beinhalteten einzelnen Datensätze des Ergebnisses können
mittels eines Cursors und einem Aufruf der next()-Methode durchlaufen werden und bieten damit die Möglichkeit auf einzelne Datensätze zuzugreifen.
Der DB-Manager stellt diverse Methoden zur Verfügung um die verschiedenen SQLStatements absetzen zu können. Es wird dabei differenziert, ob ein Ergebnis in Form
eines ResultSets zurückgegeben wird oder nicht. Die Methode doBatchStatement() beispielsweise sammelt eine Anzahl von Befehlen und sendet sie einheitlich an das DBMS.
Abbildung 5.5: Interaktion des Controllers mit dem DBS
70
5.3 Struktur und Funktionalität des GUI
5.3 Struktur und Funktionalität des GUI
Die graphische Benutzeroberfläche lässt sich in drei Komponenten einteilen:
ˆ Spielfeldfenster (1)
Zur visuellen Darstellung des zellulären Automaten und den Ergebnissen
der Analysen des Monitoringsystems
ˆ Simulationsleiste (2) Zur Steuerung der Simulation des GOL
ˆ Analysemenü (3) Zur Steuerung des Monitoringystems mit zusätzlichen
Ausgaben einzelner Ergebnisse
Abbildung 5.6: GUI-Screenshot
71
5 Architektur und Funktionalität des Life-Monitoringsystems
5.3.1 Simulationssteuerung
In dem Spielfeldfenster wird das gesamte Spielfeld mit den Ergebnissen der Analyse des
datenbankbasierten Monitoringsystems dargestellt. In diesem Fenster kann der Anwender
zu Beginn eines Spiels eine Anfangskonfiguration manuell durch anklicken der visuell dargestellten Zellen auswählen. Weiterhin besteht die Möglichkeit, in der Simulationsleiste
(siehe Abbildung 5.7) eine vorgegebene Anfangskonstellation auszusuchen (3). Mit den
dort befindlichen Buttons (1) wird dem Anwender die Möglichkeit geboten die Simulation
explizit steuern.
Abbildung 5.7: Simulationsleiste
Durch anklicken des ersten Buttons, dem Next-Step-Button, wird nur die nächste Generation berechnet und anschließend werden die vorher aktivierten Analysen durchgeführt.
Der Nutzer hat die Möglichkeit das Spielfeld länger zu betrachten oder weitere Analysefunktionen zu starten.
Der zweite Vorlauf -Button ermöglicht eine Berechnung von mehreren Generationen, ohne
zwischenzeitliche Ausgaben im Spielfeldfenster. Es muss hierbei in dem Textfeld (2) die
Anzahl der zu berechnenden Generationen eingegeben werden. Bei diesem Prozess werden
die aktivierten Ereignisüberwachungen, die sich nur auf die aktuelle Generation beziehen,
ausgesetzt. Hingegen bleibt die Prozessüberwachung, wie die Analyse der Trajektorie und
der Evolutionsumgebung, weiterhin aktiv. Durch den Verzicht einer graphischen Ausgabe und der aussetzenden Analysen wird im Gegensatz zum folgenden PLAY-Modus eine
erhöhte Performanz erreicht.
Der Play-Button, mit einer Eingabe der zu berechnenden Generationen, führt in einer
konstanten Taktrate die diskreten Zeitschritte der Simulation aus. Der Anwender kann
dabei zwischen drei Durchführungsgeschwindigkeiten (langsam, normal, schnell ) wählen
(4). Nach jeder Generationsberechnung folgen die Analysen. Dieser Modus ist die anschaulichste Variante zur Darstellung des GOL.
Dieser Play-Modus kann, durch das erneute klicken des dann angezeigten Pause-Buttons
gestoppt werden und setzt sich bei wiederholtem anklicken des Pause-Buttons wieder fort.
Mit dem Backward-Button hat der Nutzer die Möglichkeit die Vorgänger-Generation
nochmals zu betrachten. Der STOP-Button bricht das komplette Spiel des GOL ab und
versetzt das Spielfeld in den Anfangszustand, in welchem alle Zellen tot sind.
72
5.3 Struktur und Funktionalität des GUI
Bei jedem Modus folgt in einem Textfeld (2) die Ausgabe der aktuellen Generation und
der benötigten Zeit für den Durchlauf. Neben der Steuerung der Simulation hat der Anwender die Möglichkeit zwischen den Generationen oder Moden, Analyse-Komponenten
zu aktivieren oder zu deaktivieren. In Kapitel 6.1 wird die Implementierung des Simulationsprozesses ausführlich diskutiert.
5.3.2 Analyse-Steuerung
Im Analysemenü, markiert mit der (3) in Abbildung 5.6, befindet sich als oberste Option
der Clusterbestimmung (a), welche man dort aktivieren oder deaktivieren kann. Bei
der Clusterbestimmung werden die einzelnen Cluster auf dem Spielfeld durch eine bounding box graphisch hervorgehoben. Zusätzlich werden die jeweiligen ClusterIDs aufgelistet
. Durch Anklicken eines der aufgelisteten ClusterIDs werden die Zellen der Cluster farblich
gegenüber den anderen Clustern hervorgehoben. Bei der Auswahl dieser Analyse werden
in jeder Generation die bounding box und die angezeigten ClusterIDs aktualisiert.
Unter dem Menü-Punkt der Clusterbestimmung befindet sich der Teil des Menüs für die
Klassifikation der Cluster (b). Es sind die farblichen Nuancen angegeben, in welcher
die Cluster bei einer Klassifizierung dargestellt werden. Bei einer Anwahl dieser Funktion wird, falls dies durch den Benutzer nicht geschehen ist, auch die Clusterbestimmung
automatisch aktiviert. Zudem hat der Anwender die Möglichkeit, ohne eine Aktivierung
dieser Komponente, nur für die aktuelle Generation, eine Klassifizierung durchführen zu
lassen. Wie in Kapitel 4.2.1 erläutert sind vor einer Klassifizierung die Zellen in Cluster
zu gruppieren. Die graphische Umsetzung der Aktivierung dieser beiden Funktionen wird
in der folgenden beispielhaften Abbildung veranschaulicht:
73
5 Architektur und Funktionalität des Life-Monitoringsystems
Im Analysemenü befindet sich unter Punkt (c) die Funktion der Ermittlung der Kollisionsgefahr. Zur Anzeige der aktuellen Gefahr einer Kollision wird in drei Gefahrenstufen
(hoch, mittel, niedrig) unterschieden. Bei einer geringen Gefahr wird in grüner Farbe die
niedrige Stufe markiert. Bei einer etwas höheren Gefahr, wobei eine Kollision in frühestens
5 Generationen stattfinden würde, wird in Orange die mittlere Stufe markiert. Ist die Kollisionswahrscheinlichkeit frühestens in 3 Generationen zu erwarten, wird in roter Farbe die
höchste Stufe gekennzeichnet. Ist die höchste Stufe erreicht, werden die bounding boxes
der Cluster von denen die Gefahr ausgeht rot dargestellt. Bei Aktivierung dieser Funktion wird, falls nicht vorher vom Anwender durchgeführt, die Clusterbestimmung und die
Klassifizierung (da die Richtungen der Gleiter das Ergebnis beeinflussen) mit aktiviert.
Für die Ermittlung der Trajektorie müssen die zu beobachtenden Cluster in dem Fenster (a) ausgewählt werden und der Button Cluster selektieren“ für die Aufnahme der
”
Ermittlungen angeklickt werden. Die ausgewählten Cluster und ihre Nachkommen werden
in den weiteren Generationen individuell farblich gegenüber den anderen Clustern hervorgehoben. Ein Cluster wird dabei über mehrere Generationen hinweg mit derselben Farbe
dargestellt. Bei der Anwahl des Buttons Trajektorie anzeigen“ werden die Trajektorien
”
in derselben Farbe wie die zugehörigen Cluster angezeigt. Falls dieser Button nicht nochmals angeklickt wird, werden in jeder Generation die Trajektorien aktualisiert dargestellt,
ansonsten erst wieder beim betätigen dieses Buttons. Hierbei werden auch Trajektorien
gezeigt, deren ursprüngliche Cluster gestorben sind.
74
5.3 Struktur und Funktionalität des GUI
Bei einer Kollision zweier Cluster entsteht eine neue Trajektorie, erkennbar in dem hier
aufgeführten Beispiel, dargestellt durch das gelbe Cluster. Am Ende sterben hier alle
Zellen, zurück bleiben nur noch ihre Spuren in Form der Trajektorien. Am Ort des Zusammenpralls erkennt man verschieden farbige Zellen, die von einem Durcheinander von
Aufspaltung und Vereinheitlichung der Cluster bei der Kollision zeugen. Es wurden dabei
kurzzeitig für einzelne Generationen Cluster erzeugt, die wiederum neue Trajektorien initialisierten.
Die Evolutionsumgebung kann bei Menü-Punkt(d) aktiviert oder deaktiviert werden.
Im Gegensatz zur Trajektorie handelt es sich bei dieser Funktion nicht um eine auf lokale Cluster begrenzte Funktion, sondern um die Entwicklung der globalen Konstellation.
Daher wurde bei diesem Menü-Punkt auf eine Auswahl von Clustern verzichtet. Bei Aktivierung dieser Funktion werden alle aktuellen Cluster betrachtet und für jedes Cluster eine
Evolutionsumgebung initialisiert. Somit gehören alle nachfolgenden Cluster einer Evolutionsumgebung an. Bei dieser Analyse werden die Ergebnisse vollständig auf dem Spielfeld
ausgegeben und es wird durch die auf alle Cluster bezogene Darstellung der Evolutionsumgebung der charakteristische globale Aspekt deutlich.
75
5 Architektur und Funktionalität des Life-Monitoringsystems
Beim vorliegenden Beispiel der Evolutionsumgebung wird die ausgedehnte Ausbreitung
der in der Mitte des Feldes liegenden Cluster erkennbar. Es wird durch die rote und
orange angezeigte Umrandung, die Überschneidung der jeweiligen Evolutionsumgebung
deutlich. Bei den im Spielfeld rechts befindlichen Clustern, handelt es sich um ein statisches
Objekt und einen so genannten Blinker, die ihren Ort nicht verlassen. Die Realisierung
der Evolutionsumgebung wird in Kapitel 6.3 ausführlich behandelt.
76
6 Ausgewählte Aspekte der
Implementierung
Im Kapitel 4 wurden drei verschiedene Konzepte des Life-Monitoringsystems diskutiert.
Die Simulation, die Analysefunktionen des Monitoringsystems und die betrachteten Erweiterungen des Monitoringsystems um Visualisierungsaspekte. In diesem Kapitel wird
die datenbankbasierte Realisierung jeweils eines Aspektes der oben genannten Unterteilung besprochen. In 6.1 wird sich mit dem Simulationsprozess des Game of Life“
”
beschäftigt. In 6.2 wird das Analyseverfahren des Monitoringsystems entwickelt, welches
eine Schlüsselrolle in diesem System einnimmt, die Clusterbstimmung. Schließlich wird in
6.3 die Umsetzung eines Visualisierungskonzeptes diskutiert.
6.1 Realisierung der Simulation des GOL
Das Game of Life“ ist ein Simulationsspiel, bei dem der Anwender zu Beginn eine Anfangs”
konstellation auswählt und die Simulation startet. Bei dieser prototypischen Realisierung
werden die Zustände der aktuellen Generation, der Datenbank nicht extern zugeführt, sondern von dieser selbst in diskreten Zeitschritten berechnet. Die Berechnung der nächsten
Generation anhand der Regeln des GOL werden nun im folgenden entwickelt.
In Kapitel 5 wurde der Controller des Life-Monitoringsystems mit dem SimulationsManager vorgestellt, welcher über den DB-Manager die verschiedenen SimulationsKomponenten synchronisiert, Anweisungen an das DBMS übermittelt, gegebenenfalls notwendige Operationen, die das DBMS nicht leisten kann, durchführt und die Ergebnisse
an das GUI übergibt. Der im folgenden entwickelte Prozess wird in Synchronisation mit
anderen Prozessen des Systems in diskreten Zeitschritten vom Controller gesteuert. Es
wird hier hybrid mit zwei Sprachen programmiert, mit Java, in welchem der Controller programmiert wurde und SQL für die datenbankbasierten Operationen. Durch den
Simulationsmanager werden die SQL-Befehle an das DBMS abgesetzt oder in der Datenbank gespeicherte Queries direkt aufgerufen. Die zweite Variante wird im Falle eines
aufwändigeren SQL Code durchgeführt, damit dieser nicht erst durch das DBMS auf
syntaktische Korrektheit überprüft und in das Datenbank interne Format transformiert
werden muss.
Wie beim Entwurf der Datenbank erläutert, werden nur die lebenden Zellen gespeichert.
Die Entscheidung wurde nicht nur aus Speicherplatz-, sondern auch aus PerformanzGründen gefällt, damit nur die relevanten Daten betrachtet werden müssen. Ein weiterer
77
6 Ausgewählte Aspekte der Implementierung
Vorteil ist, dass das Spielfeld, also der Raum des zellulären Automaten, leichter erweiterbar
ist. Während der folgenden Entwicklung der datenbankbasierten Umsetzung wird dieser
Grund noch deutlicher werden.
Vorliegend sind die lebenden Zellen der aktuellen Generation, aus denen die nächste Generation anhand der Regeln des GOL (siehe Kapitel 3.3.1) berechnet werden soll. Die zwei
Arten von Zellen (tote und lebende) werden nach den spezifisch geltenden Regeln ausgewertet. Für die lebenden Zellen wird ermittelt ob sie sterben oder weiterleben, für die toten
Zellen, ob sie geboren werden. Bei beiden Arten der Zellen spielt jeweils die individuelle
Moore-Nachbarschaft und die darin vorkommenden lebenden Zellen eine entscheidende
Rolle. Die Nachbarschaft kann somit zunächst für beide nach gleichen Bedingungen ermittelt werden, worauf die Regeln folgend Anwendung finden. Das Verfahren kann ganz
unterschiedlich umgesetzt werden. Die Schwierigkeit liegt vielmehr darin, die performanteste Lösung zu finden. Es muss dabei evaluiert werden, inwieweit durchgeführte Analysen
zur Umsetzung einer Regel auch für andere Regeln zu nutzen sind, um dadurch redundante oder unnötige Berechnungen zu vermeiden. Bei dieser Analyse sind vor allem zwei
Aspekte von Interesse. Welche Zellen überhaupt als Kandidat in Betracht kommen in der
nächsten Generation zu leben und wie viele lebende Nachbarn sie haben. Festzustellen ist,
ob beide Aspekte direkt zusammen oder differenziert voneinander zu ermitteln sind.
Die Kandidaten sind alle Zellen in der Moore-Nachbarschaft der lebenden Zellen. Ausgehend von einer Speicherung des gesamten Spielfeldes müsste jede einzelne Zelle
(umständlich) überprüft werden, ob und wie viele lebende Zellen sich in ihrer Nachbarschaft befinden. Da die toten Zellen, die als Kandidaten in Betracht kommen, immer in
der Moore-Nachbarschaft einer lebenden Zelle liegen, ist es einfacher (und performanter),
diese direkt von den lebenden Zellen herzuleiten. Bei der Herleitung jeder einzelnen MooreNachbarschaft von den lebenden Zellen ergibt sich der Vorteil, dass direkt alle Kandidaten
aufgezeigt werden und durch die mehrfache Herleitung die Anzahl der lebenden Nachbarn
dieser Zellen ermittelt werden kann. Konkret heißt das, wenn eine Zelle beispielsweise dreimal erfasst wird, dass sich in ihrer Moore-Nachbarschaft drei lebende Zellen befinden. Es
werden also zunächst die Kandidaten (explizit mit Duplikaten der Nachbarschaftszellen)
von den lebenden Zellen hergeleitet, wobei die Ränder des Spielfeldes beachtet werden
müssen.
Für die Ermittlung der Kandidaten muss eine Sicht definiert werden, welche die Kandidaten anhand der Tabelle Lebende Zellen berechnet. Da SQL mengenbasiert operiert und die
hergeleiteten Daten in einer Tabellenform dargestellt werden, wird nicht sequentiell für jede einzelne Zelle die vollständigen Nachbarschaftszellen ermittelt. Für jede Position in der
Moore-Nachbarschaft wird einmal vollständig die Tabelle Lebende Zellen betrachtet und
diese Zellen hergeleitet. Diese Ergebnisse werden anschließend mit UNION vereinigt. Da
MS Access bei Verwendung des Vereinigungsoperators UNION die Duplikate eliminieren
würde, wird explizit für jede der hergeleiteten Zellen, die ausgehende lebende Zelle mit
78
6.1 Realisierung der Simulation des GOL
angegeben. Aus Performanzgründen wird sich dafür entschieden bei jeder Ermittlung einer
Nachbarschaftszelle direkt mit einer WHERE-Klausel die Zellen herauszufiltern, welche die
Grenzen des Raumes überschreiten. Es wäre auch möglich gewesen, zu einem späteren Zeitpunkten diese Integritätsbedingung umzusetzen. Der Vorteil bei dieser Implementierung
ist jedoch, dass spezifisch die jeweiligen Datensätze, die einzelne Bedingungen verletzen
könnten, auch nur dahingehend überprüft werden. Ansonsten hätte man alle Datensätze
auf vier Bedingungen zur Beachtung der Grenzen überprüfen müssen. Bei der hier prototypischen Realisierung besteht das Spielfeld aus 50 ∗ 50 Zellen. Folgende Sicht ermittelt
aus der Basistabelle lebende Zellen die Moore-Nachbarschaft:
CREATE VIEW Moore Nachbarschaft AS
SELECT x + 1 As xNZ ,y AS yNZ, x,y
FROM Lebende Zellen WHERE (x + 1 ≺ 50) AND ((x + 1) ≺ 50)
UNION
SELECT x − 1 As xNZ, y AS yNZ , x,y
FROM Lebende Zellen WHERE(x − 1 ≥ 0) AND ((x − 1) ≺ 49)
UNION
SELECT x − 1 As xNZ, y − 1 As yNZ , x,y
FROM Lebende Zellen WHERE ((x − 1)≥ 0) AND ((y − 1) ≥ 0)
UNION
SELECT x As xNZ, y − 1 As yNZ , x,y
FROM Lebende Zellen WHERE ((y − 1)≥ 0)
UNION
SELECT x As xNZ, y + 1 As yNZ , x,y
FROM Lebende Zellen WHERE ((y + 1)≺ 50)
UNION
SELECT x − 1 As xUZ ,y + 1 AS yNZ ,x,y
FROM Lebende Zellen WHERE (x − 1 ≥ 0) AND (y + 1 ≺ 50)
UNION
SELECT x + 1 As xNZ ,y − 1 As yNZ , x,y
FROM Lebende Zellen WHERE ((x + 1) ≺ 50) AND ((y − 1) ≥ 0)
UNION
SELECT x + 1 As xNZ, y + 1 As yNZ, x,y
FROM Lebende Zellen WHERE((x + 1) ≺ 50) AND ((y + 1) ≺ 50)
UNION
SELECT x AS xNZ,y AS yNZ ,x, y
FROM Lebende Zellen;
Es wird weiter in Bezug zu dem entworfenem Algorithmus in Kapitel 4.2.1 eine datenbankbasierte Umsetzung konzipiert. Die vorangegangene Analyse ist zumindest notwendig, um
die Zellen zu ermitteln die geboren werden. Es gibt zwei Möglichkeiten die Zellen zu ermitteln, die überleben werden. Entweder durch die Analyse, welche Zellen von den lebenden
Zellen sterben werden oder welche von diesen Zellen explizit überleben werden. Es wäre
von Vorteil die vorausgegangene notwendige Analyse auch zur Untersuchung der aktuell
lebenden Zellen nutzen zu können. Dann könnte auf eine explizite Analyse zur Umsetzung
der Regeln, die sich nur auf die lebenden Zellen beziehen, verzichtet werden. Nach den Regeln des GOL gilt, dass Zellen geboren werden, die drei lebende Nachbarn haben und es
überleben die Zellen, die zwei lebende Nachbarn haben. Da die Moore-Nachbarschaft einer
Zelle die selbige beinhaltet, bedeutet dies, dass alle Zellen die in ihrer Moore-Nachbarschaft
79
6 Ausgewählte Aspekte der Implementierung
3 lebende Zellen haben, auch in der nächsten Generation leben werden, unabhängig davon, ob sie aktuell leben oder tot sind. Die Analyse zur Ermittlung, welche Zellen geboren
werden, kann somit auch genutzt werden um performant zu analysieren, welche Zellen
teilweise überleben werden.
Zusätzlich müsste jedoch berücksichtigt werden, dass Zellen auch überleben, wenn sie
drei lebende Zellen in ihrer direkten Nachbarschaft haben, also vier in ihrer MooreNachbarschaft. Für diese Ermittlung kann ebenso auf die zuvor durchgeführte Herleitung
zugegriffen werden. Zusätzlich muss noch überprüft werden, ob es sich bei den Zellen, die
diese Bedingung erfüllen auch um lebende Zellen handelt. Die Durchsetzung der relevanten
Regeln, zur Ermittlung welche Zellen in der nächsten Generation leben werden, können
somit auf einer Herleitung basieren. Die Regel zur Bestimmung, welche Zellen sterben,
kann somit außer acht gelassen werden.
Die Sicht Moore-Nachbarschaft wird nun hinsichtlich des entwickelten Algortihmus in Bezug zur Ermittlung der Kandidaten weiter eingegrenzt. Die Tupel werden nach den Nachbarschaftszellen gruppiert, die jeweilige Anzahl der Duplikate berechnet und die irrelevanten Datensätze herausgefiltert. Bei den Zellen von denen es vier Duplikate gibt, muss
zusätzlich überprüft werden, ob diese Zellen in der aktuellen Generation leben. Man könnte
dies durch eine Unteranfrage mittels einer WHERE-Klausel und einer EXIST-Bedingung
durchführen. Diese korrelierten Unteranfragen erhöhen aber den Berechnungsaufwand, da
für jede einzelne Zelle ein Abgleich mit der Tabelle Lebende Zellen stattfinden würde. Es
ist sinnvoller, die existierende Sicht direkt durch einen JOIN mit den lebenden Zellen zu
verknüpfen und mit eine Abfrage nach einem existierenden JOIN-Partner zu ermitteln, ob
es sich um eine lebende Zelle handelt.
Der JOIN und die daraus entstehende virtuelle Tabelle fungiert dabei nur als Hilfe zur
Abfrage einer Bedingung. Bei einem INNER JOIN werden nur die Tupel hergeleitet, die
einen JOIN-Partner gefunden haben. Da bei der vorliegenden Abfrage nur für eine TeilRelation überprüft werden muss, ob es sich um lebende Zellen handelt, wird der LEFT
JOIN verwendet. Bei Verwendung des LEFT JOIN werden alle Datensätze der virtuellen
Tabelle Kandidaten betrachtet, ob sie einen JOIN-Partner gefunden haben oder nicht. Es
handelt sich bei dem LEFT JOIN bei Access-SQL nicht um einen (linken) SEMI-JOIN,
sondern um einen (linken) OUTER JOIN. Der Unterschied liegt darin, dass alle Tupel der
linken Tabelle des JOIN-Verbundes aufgenommen werden und die nicht-matchenden Tupel
mit NULL-Werten aufgefüllt werden. Hingegen bei einem linken oder rechten SEMI-JOIN
nur die rechten oder linken Tupel angezeigt werden, die einem JOIN-Partner zugeteilt
bekommen haben. Der LEFT (OUTER) JOIN ist hier notwendig, um Zellen die geboren
werden zu berücksichtigen. Durch die JOIN-Bedingung kommt es zu einer Zuordnung,
wobei die relevanten Tupel dann mit einer WHERE-Klausel herausgefiltert werden. Konkret wird mit der Abfrage WHERE Lebende Zellen.x IS NOT NULL“ überprüft ob ein
”
JOIN-Verbund mit einer lebenden Zelle vorliegt.
80
6.1 Realisierung der Simulation des GOL
CREATE VIEW nächste Gen Sicht AS
SELECT xNZ AS x, yNZ AS y
FROM (SELECT xNZ, yNZ, COUNT(xNZ) AS Anzahl
FROM Moore Nachbarschaft
GROUP BY xNZ, yNZ,
HAVING COUNT(xNZ) = 3 OR COUNT(xNZ) =4) AS Kandidaten
LEFT JOIN
Lebende Zellen
ON (Kandidaren.xNZ = Lebende Zellen.x)
AND (Kandidaten.yNZ = Lebende Zellen.y)
WHERE Anzahl = 3 OR Lebende Zellen.x IS NOT NULL;
Bei der Aggregierung mit Count() wird exemplarisch nur die x-Koordinate der Nachbarschaftszelle betrachtet, es hätte auch umgekehrt die y-Koordinate einer Zelle angegeben
werden können, da jede Zelle immer durch zwei Zell-Koordinaten charakterisiert ist. Im
vorliegenden SQL-Code werden mit HAVING frühzeitig Datensätze herausgefiltert, damit die Größe der virtuellen Tabelle nicht zu stark anwächst. Es wird der Nachteil einer
zusätzlichen durchzuführenden Abfrage in Kauf genommen. Eine andere Möglichkeit ist,
auf diesen inneren Filter zu verzichten und eine äußere WHERE-Klausel zu definieren:
...WHERE Anzahl = 3 OR ( Anzahl = 4 AND Lebende Zellen.x IS NOT NULL)“.
”
Die hier durchgeführte Variante bietet aber leichte Performanzvorteile bei einer hohen
Anzahl lebender Zellen.
Auf Grund der hohen Fluktuation der lebenden Zellen bei einem Generationswechsel ist
es nicht vorteilhaft, den Datenbestand der lebenden Zellen explizit zu aktualisieren. Es
müsste für jede lebende Zelle überprüft werden, ob sie überlebt oder stirbt. Zusätzlich
müssten die Zellen, die geboren werden eingefügt werden. Es ist performanter, diese Daten
direkt mit der definierten Sicht zu überschreiben. Da sich diese Sicht auf die Basistabelle Lebende Zellen bezieht und somit referentiell von ihr abhängig ist, muss sie zunächst
materialisiert werden. Bei MS Access werden keine materialisierten Sichten unterstützt,
daher muss dieser Vorgang simuliert werden. Im Datenbankschema wird dafür eine Tabelle nächste Generation angelegt. In dieser Tabelle kann eine temporäre Speicherung
81
6 Ausgewählte Aspekte der Implementierung
der Tupel erfolgen und somit die Sicht materialisieren. Es erfolgt eine Löschung der Datensätze der Tabelle Lebende Zellen und anschließend eine Einfugung der Tupel in die
nächste Generation-Tabelle.
INSERT INTO nächste Generation
SELECT * FROM nächste Gen Sicht
Es wurden auch Tests durchgeführt die Daten in jeder Generation inkrementell zu aktualisieren. Doch beim GOL und seinen schnell variierenden Konstellationen erwies sich
dieser Versuch um mehr als ein Drittel langsamer, als die hier vorgestellte Realisierung.
Im Gegensatz zu herkömmlichen Datenbank-Anwendungen, bei denen sich die Daten nur
gelegentlich und dann nur vereinzelt ändern, muss bei der Überwachung von dynamischen
Systemen, genau untersucht werden, wie die Daten in jedem diskretem Zeitschritt zu aktualisieren sind.
Bis auf die Synchronisation der einzelnen Aufrufe an das DMBS und der Darstellung der
Ergebnisse im GUI kann die Umsetzung der Simulation vollständig vom DBMS durchgeführt werden. Während der Analyse ist eine Extrahierung der Daten und eine Weitergabe an das Java-Programm nicht erforderlich, da es bei den Berechnungen keine Aufgaben
übernehmen muss. Es wird durch die interne Bearbeitung eine erstaunlich hohe Performanz erreicht. Um eine grobe Einschätzung von der Geschwindigkeit der Simulation zu
vermitteln, wird eine Simulation gestartet, in der 200 Generationen berechnet werden, mit
durchschnittlich 90 Zellen je Generation. Der Zeitaufwand für diese Berechnungen liegt im
Durchschnitt knapp unter 12 Sekunden, also für 10 Generationen 0,6 Sekunden.
6.2 Realisierung der Clusterbestimmung
Die Clusterbestimmung, im besonderen ihre performante Durchführung, ist ein Kernproblem dieser Diplomarbeit, da sich die weiteren Analysen des datenbankbasierten Monitoringsystems auf dieses Ergebnis beziehen. Damit ist die Durchführungsdauer der Clusterbestimmung integraler Bestandteil aller weiteren Analysen und bekommt somit eine
Schlüsselrolle zugewiesen, was die gesamte Performanz des datenbankbasierten Monitoringsystems angeht. Basierend auf das in Kapitel 4.2.2 entwickelte allgemeine Verfahren
und dem entwickelten Algorithmus zur Realisierung der Clusterbestimmung wird nun die
datenbankbasierte Umsetzung diskutiert.
Zunächst muss der allgemeine Algorithmus in Bezug zu den Stärken und Schwächen einer datenbankbasierten Realisierung modifiziert werden. Da sich die Cluster aus lebenden
Zellen zusammensetzen, ist es notwendig, diese Zellen in der Cluster-Tabelle abzulegen.
Zunächst muss entschieden werden, ob diesen Zellen in der Cluster-Tabelle eine temporäre
ClusterID zugeführt wird, die im Weiteren zur tatsächlichen ClusterID modifiziert wird
oder ob unabhängig von dieser Tabelle die Cluster bestimmt werden und den lebenden
82
6.2 Realisierung der Clusterbestimmung
Zellen nachträglich die ermittelte ClusterID zugeführt wird. Weiterhin wurde beim logischen Datenbankentwurf die Frage offen gelassen, ob die Beziehung benachbart mit in die
Tabelle der Cluster einzubetten ist oder nicht. Beide Fragen beziehen sich auf den gleichen
Kontext.
Ziel des Verfahrens der Clusterbestimmung ist, die lebenden Zellen hin zu ihrer kleinsten“
”
erreichbaren Zelle über die definierte Ordnung (siehe Kapitel 4.2.2) der Koordinaten-Paare
zu verknüpfen. Diese kleinsten“ Zellen wurden Identifikationszellen des Clusters genannt.
”
Zur Verknüpfung und Zuordnung der lebenden Zellen muss die Moore-Nachbarschatft
jeder dieser Zellen ermittelt werden, durch diese ist es dann auch möglich zwei Zellen,
die durch eine tote Zelle getrennt sind, demselben Cluster zuzuordnen. Da die Nachbarschaftszellen nur zur Ermittlung der Zellenpfade der lebenden Zellen dienen, muss diesen
jeweils auch die ausgehende lebende Zelle zugeordnet werden. Bevor der Vorteil und die
Entscheidung für eine bestimmte Umsetzung erläutert wird, ist es zunächst notwendig die
ZellID einzuführen. Bei der datenbankbasierten Analyse zur Nutzung dieser Ordnung, ist
es vorteilhaft jeder Zelle der Moore-Nachbarschaft anstatt den Koordinaten der lebenden
Zellen, zu Beginn der Analyse eine ZellID hinzuzufügen.
Definition 6.1 (ZellID). Sei l ∈ RA die aktuell lebenden Zellen, sei m * n ist die Dimension des Raumes (siehe Definition 3.8) und x−Koord.:l → N und y−Koord.:l → N die Zuordnung der Koordinaten zu den lebenden Zellen. Dann gilt die Abbildung: Zell−Id:l → N
mit
ZellID(l) =def (y − Koord.(l)) ∗ (min{10i |m ≺ 10i }) + (y − Koord.(l).
Bei der hier durchgeführten prototypischen Implementierung ist m gleich 50 gewählt und
somit min{10i |m < 10i } gleich 100. Die Größe wurde so gewählt, dass die ZellID eindeutig
ist und man intuitiv die y- und x-Koordinaten herauslesen kann. Durch die Abbildung
der Koordinaten-Paare auf die ZellID der lebenden Zellen werden bei datenbankbasierten
Zugriffen Join- und Gruppierungs-Operationen gespart. Es müsste sonst zusätzlich bei
der Auffindung bestimmter Cluster nach der y-Koordinate gruppiert und durch einen
JOIN die jeweilige x-Koordinate zugeordnet werden, um die kleinste erreichbare ZellID
zu ermitteln. Durch die ZellID wird die definierte Ordnung beibehalten und allein durch
die nummerische Größe der ID umgesetzt. Ein weiterer Vorteil ist, dass die ZellID der
Identifikationszelle, die ein Cluster eindeutig bestimmt, am Ende der Analyse als ClusterID
fungieren kann.
Definition 6.2 (ClusterID). Sei C ∈ RA eine Menge von ZellIDs von lebenden Zellen,
die ein Cluster bilden. Die ClusterID ist die ZellID mit dem kleinsten numerischen Wert
dieser Menge.
Um zur aufgeführten Frage zurückzukommen wird als erstes die oben erwähnte explizite
Darstellung der Moore-Nachbarschaft, mit der jeweiligen ZellID zu jeder Nachbarschaftszelle betrachtet. Die Möglichkeit wäre gegeben, nur diesen Nachbarschaftszellen die ZellID
83
6 Ausgewählte Aspekte der Implementierung
zuzuführen und mit der finalen ClusterID zu überschreiben. Es müsste jedoch anschließend
wieder analysiert werden, welche Nachbarschaftszelle zu welcher lebenden Zelle gehört. Da
dies bei der Analyse der Moore-Nachbarschaft aber direkt mitgeliefert wird, ja die Grundlage der Ermittlung ist, wird die Beziehung benachbart mit in die Cluster-Tabelle eingebettet. Ebenso könnte redundant die jeweiligen Zellkoordinaten mit angegeben werden,
es wird hier aber auf diese redundante Speicherung verzichtet. Zudem werden aus diesen
Tupel, bei der folgenden Implementierung nur die wenigen relevanten Werte (die Zellenpfade) extrahiert, so dass die erhöhte Anzahl der vorliegenden Tupel bei der Analyse nicht
einschränkend wirkt. Es bringt in diesen Fall nur einen kleinen Gewinn an Performanz,
führt aber auch in anderen Fällen zu Vorteilen, wie bei der Analyse, welche Cluster aus
welchen folgen.
Zu Beginn der Analyse werden den Zellen temporäre ClusterIDs mit dem Wert ihrer
ZellID zugewiesen, womit jede Zelle vorerst als eigenständiges Cluster betrachtet wird. Im
folgenden Verfahren gilt es nun die temporären ClusterIDs zu tatsächlichen ClusterIDs zu
modifizieren, so dass die Zellen nach der Definition 4.3 in Cluster geordnet werden. Wie im
Algorithmus Kapitel 4.2.2 erläutert, werden die einzelnen Zellenpfade aus dieser Tabelle
extrahiert und iterativ modifiziert. Die Tabelle beinhaltet als Spalten die ZellID und eine
temporäre ClusterID.
Cluster: {x, y, xNZ, yNZ, ClusterID}
Zellenpfade:{ZellID,temp ClusterID}
Abbildung 6.1: Unterteilung der Methode der Clusterbestimmung
84
6.2 Realisierung der Clusterbestimmung
Der DB-Manager steuert die Analysen des Monitoringsystems und übernimmt Aufgaben,
die das DBMS nicht bewerkstelligen kann. Die beinhaltete Methode Clusterbestimmung
wird zunächst in Bezug zu dem Algortihmus 4.9 in drei Komponenten eingeteilt. Es wird
unterschieden in den Preprocessor, der Zellenpfade-Bestimmung und der Ausnahmebehandlung, welche im folgenden detailliert betrachtet werden.
6.2.1 Preprocessor
Der Preprocessor beinhaltet zwei an den DB-Manager weitergeleitete Aufrufe. Der erste
Aufruf startet die in der Datenbank abgelegte Anfügeabfrage für die Initialisierung der
Cluster-Tabelle. Es wird hierbei die Moore-Nachbarschaft der lebenden Zellen, wie bei
der Simulationsberechnung, allerdings mit einer hinzugefügten ZellID ermittelt und in die
Cluster-Tabelle gespeichert und somit materialisiert.
CREATE VIEW Cluster Sicht AS
SELECT x, y, xNZ, yNZ, ClusterID
FROM (
SELECT x+1 As xNZ , y AS yNZ, x, y, (y ∗ 100 + x) AS ClusterID
FROM Lebende Zellen
WHERE (x+1 < 50) AND ((x+1) <> 50)
UNION
(SELECT x-1 As xNZ, y AS yNZ , x, y,(y ∗ 100 + x) AS ClusterID
FROM Lebende Zellen
WHERE( x-1 ≥0) AND ((x-1) <> 49))
UNION
...[vollständige Moore-Nachbarschaft mit der temporären ClusterID]
UNION
(SELECT x AS xNZ, y AS yNZ, x, y,(y ∗ 100 + x) AS ClusterID
FROM Lebende Zellen)
);
INSERT INTO Cluster
SELECT * FROM Cluster Sicht;
Die zweite Anweisung des Preprocessors an das DBMS ist das Auffinden und die Zuweisung des kleinsten Clusternachbarn einer Zelle (siehe Definition 4.1). Die relevanten Daten
werden als Zellenpfade der Länge ≤ 1 für die nächste Phase der Analyse durch eine Sicht
ermittelt. Bei der Pfad-Analyse werden die einzelnen Pfade nicht explizit dargestellt, sondern es wird den einzelnen Zellen nur die aktuell erreichte Zelle zugeordnet bzw. die bei
der Initialisierung zugeordnete temporäre ClusterID wird während des Durchlaufes aktualisiert. Folgend wird aus den Daten der Basistabelle Cluster für jede lebende Zelle die
kleinste“ ZellID in ihrer Moore-Nachbarschaft ermittelt und zugeordnet.
”
Für diese Zuweisung wird für die Tabelle Cluster mit sich selbst über die Nachbarschaftszellen gejoint (CN steht dabei für Clusternachbar). Für jede betrachtete Nachbarschaftszelle werden die jeweiligen kleineren ZellIDs dieser Zelle ermittelt. Nach jeder ZellID wird
dann gruppiert und die jeweils kleinste benachbarte ZellID aggregiert. Dies geschieht mit
85
6 Ausgewählte Aspekte der Implementierung
SQL mengenorientiert für alle Tupel. Da Update-Anweisungen nur bei aktualisierbaren
Ausdrücken erlaubt sind, ist es hier notwendig, die virtuelle Tabelle der zugewiesenen
Clusternachbarn zu materialisieren, so dass die Tupel im Folgenden weiter modifiziert
werden können.
CREATE VIEW Zellenpfade Sicht AS
SELECT Distinct ClusterID AS ZellID, Min(temp ID) AS temp ClusterID
FROM Cluster
INNER JOIN
(SELECT xNZ, yNZ, ClusterID AS temp ID
FROM Cluster) AS CN
ON (Cluster.yNZ=CN.yNZ) AND (Cluster.xNZ=CN.xNZ)
AND (Cluster.ClusterID>CN.temp ID)
GROUP BY ClusterID
INSERT INTO Zellenpfade
SELECT * FROM Zellenpfade Sicht;
Diese Initialisierung und die vollständige Clusterbestimmung werden aufgrund der hohen
Fluktuation der lebenden Zellen in jeder Generation neu berechnet. Es ist dadurch nicht
sinnvoll, die Tupel in jeder Generation inkrementell zu modifizieren. Dies ließe sich schon
bei der Simulation evaluieren.
6.2.2 Bestimmung der Zellenpfade
Wie im Abschnitt 4.2.2 erläutert kann ein paralleles bzw. mengenorientiertes oder sequentielles bzw. angenommenes satzorientiertes Verfahren zur Bestimmung der Zellenpfade
durchgeführt werden. Bevor sich für eine Umsetzung entschieden wird, muss zunächst
das datenbankbasierte Vorgehen einer transitiven Verknüpfung und einer anschließenden
Zuweisung bzw. Aktualisierung der ZellID detailliert erörtert werden. Im Standard-SQL
kann nur eine (virtuelle) Tabelle, die aktualisierbar ist, nach dem UPDATE-Befehl für die
Modifikation angeführt werden. Im FROM-Teil können weitere Objekte, die über einen
JOIN verbunden sein können, angegeben werden. Die zu aktualisierende Tabelle kann dort
ebenso angegeben werden. Es können somit komplexe Werte oder Werte über komplexe
Beziehungen für die Aktualisierung ermittelt werden. Im Rahmen einer Update-Anweisung
bei MS Access gibt es keinen FROM-Teil. Somit muss der gesamte Ausdruck nach dem
Update-Befehl folgen, welcher vollständig aktualisierbar sein muss.
86
6.2 Realisierung der Clusterbestimmung
Nach dem ANSI-Standard ist nur die Aktualisierung eines Objektes möglich. Die bei MS
Access möglichen aufgeführten gejointen Tabellen könnten dabei als eine virtuelle Tabelle bzw. ein Objekt verstanden werden, jedoch darf die nachfolgende Update-Anweisung
sich nur auf einen Objektbezeichner beziehen, was in Access nicht gilt. Es ist durchaus
möglich durch eine Update-Anweisung mehrere Tabellen zu modifizieren. Das lässt darauf
schließen, dass Access den gesamten Ausdruck nach dem UPDATE-Befehl als ein Objekt
erfasst. Das führt dazu, dass beispielsweise Sichten, bei denen eine Aggregatfunktion verwendet wird und eine Gruppierung stattfindet, vorher materialisiert werden müssen, da
die Tupel sonst nicht aktualisierbar sind. Eine Einschränkung von MS Access ist, dass bei
der SET- und WHERE-Klausel keine JOINS erlaubt sind.(Siehe u. a. [Auer2008])
Beim Standard-SQL sind keine Update-Operation erlaubt, wobei Tabellen mit sich selbst
transitiv über einen JOIN verknüpft und die Spalte(n) der JOIN-Bedingung modifiziert
werden. Dies würde auch die Zuordnung über die JOIN-Bedingung verletzen. Im StandardSQL müsste man zwei Sichten definieren, die diese Tabelle um zwei Attribute erweitert,
damit die Aktualisierung nicht die Spalten der Join-Bedingung betrifft. Wie der Showplan
von der MS Jet Datenbank-Engine ausgibt, wird von MS Access zuerst der JOIN durchgeführt und anschließend diese virtuelle Tabelle modifiziert, ohne das bei Veränderungen
der JOIN-Bedingung die Tupel neu geordnet werden.
Showplan:
01) Sort table ’Test’
02) Inner Join table ’Test’ to result of ’01)’
using temporary index
join expression ”T2.Spalte1=T1.Spalte2”
03) Update
Bei MS Access ist also eine transitive Verknüpfung einer Tabelle über einen JOIN mit
einer Update-Anweisung zulässig. Die virtuelle Tabelle bei dieser Anweisung, setzt sich
also aus einer Tabelle, die mit sich selbst gejoint ist, zusammen. Um in dieser Anweisung sinnvoll zuordnen zu können, bekommt die Tabelle zwei Alias-Namen T1 und T2
zugewiesen. Bei der Modifizierung eines Wertes von T1, ändert sich T2 ebenfalls, es kann
sich also für die virtuelle Tabelle mehrfach auswirken. Daher muss es eine Reihenfolge
geben, wonach die Update-Operationen durchgeführt werden, da diese Ordnung das Ergebnis maßgeblich beeinflusst. Es lies sich evaluieren (in dem Hilfsmenü wird noch nicht
mal der JOIN bei einer Update-Operation erwähnt), dass automatisch vom kleinsten Wert
der JOIN-Bedingung aufsteigend die Modifizierungen durchgeführt werden. Es gibt auch
die Möglichkeit diese Ordnung zu verändern und die Update-Reihenfolge zu beeinflussen. Das Bedeutet, dass es möglich ist ohne externe Steuerung durch beispielsweise einem
Java-Programm (und damit kostengünstig), die vorher angenommene satzorientierte bzw.
sequentielle Zuordnung SQL spezifisch mengenorientiert zu realisieren. Somit kann, wenn
der erläuterte Ausnahmefall nicht berücksichtigt wird, die Clusterbestimmung ohne externe Iteration durchgeführt werden. Es werden also von den kleinsten Zellen aufwärts die
87
6 Ausgewählte Aspekte der Implementierung
Zuweisungen durchgeführt, wodurch die nachfolgenden Zuweisungen von den vorangegangenen Schritten profitieren, was zu mehr Effizienz führt. Das Vorhgehen wird in einem
Beispiel verdeutlicht:
Die Umsetzung mit Berücksichtigung der Zellen, die ihre kleinste Zelle bereits erreicht
haben sieht wie folgt aus:
UPDATE Zellenpfade AS ZP1 INNER JOIN Zellenpfade AS ZP2
ON ZP1.temp ClusterID = ZP2.ZellID
SET ZP1.temp ClusterID = ZP2.temp ClusterID
WHERE ZP1.temp ClusterID <> ZP2.temp ClusterID;
MS Access verhält sich aber nicht einheitlich, wenn die virtuelle Tabelle wie beim obigen
Beispiel als Sicht dargestellt ist und es versucht wird, sie manuell zu editieren. Es kommt
die Fehlermeldung The recordset is not updateable“. Die spezielle Umsetzung der MS
”
Access JET-Engine im Gegensatz zum Standard-SQL ergibt für das hier vorliegende Verfahren eine sehr performante Durchführung.
Folgend werden die temporären ClusterIDs der einzelnen Zellen in der Cluster -Tabelle mit
den ermittelten ClusterIDs von den Zellenpfaden überschrieben.
UPDATE Cluster INNER JOIN Zellen Pfade
ON Cluster.ClusterID = Zellen Pfade.ZellID
SET Cluster.ClusterID = Zellen Pfade.temp ClusterID;
Die oben genannten Update-Anweisungen, werden dabei von dem Java-Programm an das
DBMS übermittelt (siehe Abbildung 6.2).
88
6.2 Realisierung der Clusterbestimmung
Abbildung 6.2: Zellenpfad-Bestimmung
6.2.3 Ausnahmebehandlung
Bei der Ausnahmebehandlung müssen nun die ClusterIDs ermittelt werden, die nicht die
tatsächliche ClusterID besitzen. Das betrifft die Cluster, bei denen sich in der Nachbarschaft mindestens einer Zelle, eine von ihr abweichende ClusterID befindet. Diese jeweilige
Menge von TeilClustern, die über eine Nachbarschaftszelle miteinander verbunden sind,
müssen nun die kleinste ClusterID dieser Menge annehmen.
Zunächst könnte man naiv die ClusterIDs und die zugehörigen kleineren ClusterIDs durch
eine Sicht herleiten und diese über eine transitive Verknüpfung updaten. Bei diesem Konzept treten allerdings zwei Probleme auf, das Erste ist, dass kein DISTINCT (zur Vermeidung von Duplikaten) verwendet werden darf, weil diese Sicht dann nicht mehr aktualisierbar wäre. Das führt dazu, dass es zu redundanten Verknüpfungen und Update-Operationen
kommt. Das zweite Problem ist, dass keine Gruppierung und Aggregierung erlaubt sind,
aus der selben Bedingung der Aktualisierbarkeit. Das führt unter besonderen Umständen
dazu, dass trotz Vorgabe einer spezifischen Reihenfolge der Update-Operationen der Ausnahmefall nicht vollständig behoben wird. Dieser Fall tritt ein, wenn ein Teil-Cluster sich
zwischen zwei anderen temporären Clustern mit kleinerer ClusterID befindet.
Es muss also eine Sicht, welche die betreffenden Werte ermittelt, materialisiert werden.
Um die Cluster einheitlich zu betrachten wird mit einer Gruppierung und einer Auswahl
des kleinsten Nachbarn ein Wert für die Aktualisierung bestimmt. Bei der Übergabe des
Befehls an das DBMS, kann im Gegenzug die Anzahl der eingefügten Tupel zurückgegeben
werden, womit überprüft werden kann, ob es zu einem Ausnahmefall gekommen ist.
89
6 Ausgewählte Aspekte der Implementierung
CREATE VIEW Ausnahme Sicht AS
SELECT DISTINCT M.ClusterID AS temp ClusterID,
Min(T.ClusterID) AS ClusterID
FROM Cluster AS M
INNER JOIN
(SELECT xNZ, yNZ, ClusterID FROM Cluster) AS T
ON (M.xNZ=T.xNZ) AND (M.yNZ=T.yNZ) AND (M.ClusterIDT.ClusterID)
GROUP BY M.ClusterID;
Es gibt wieder verschiedene Möglichkeiten einer auf diesen materialisierten Sichten basierenden Umsetzung. Eine ist, direkt mit diesen Werten einen JOIN mit der ClusterTabelle zu initiieren und die Werte entsprechend zu aktualisieren. Dadurch, dass dies
keine transitive Verknüpfung mit der Tabelle selber ist, werden allerdings immer nur die
angrenzenden Cluster vereinheitlicht. Es wäre also eine Iteration notwendig. Eine weiter
Alternative ist, nach dem Prinzip des Zellenpfad-Bestimmungs-Processors in Bezug
zu den Zellenpfaden, auf die gleiche Weise zunächst die materialisierte Sicht Ausnahme
vollständig nach den kleinsten vorliegenden ClusterIDs zu bestimmen und anschließend
die Teil-Cluster zu aktualisieren. Bei dieser Variante, der der Vorzug gegeben wird, kann
aber nicht ausgeschlossen werden, dass temporäre Cluster wieder zu temporären und nicht
zu den tatsächlichen kleinsten Cluster zugeordnet werden. Es kann also selbst bei dieser
Variante nicht auf eine Iteration verzichtet werden, allerdings wird sie auf ein Minimum
von Durchläufen beschränkt. Die Iteration wird nur mehrmals ausgeführt bei einem Ausnahmefall des erläuterten Ausnahmefalles (siehe Kapitel 4.2.2.).
Ms Access 2007 unterstützt keine ausreichende Iteration (bis zu einer bestimmten Abbruchbedingung) oder Rekursion, deswegen muss der deklarative datenbankbasierte Teil
durch einen imperativen Teil des Systems unterstützt werden. Nach der Inititalisierung
der Tabelle Ausnahme und der Übergabe des ResultSet mit der Anzahl der eingefügten
Tupel an den Controller, wird, falls dieser Wert größer 0 ist, die Iteration der Ausnahmebehandlung gestartet. In einer WHILE -Schleife des Java-Programms sind die Befehle an
das DBMS eingebettet. Die Schleife bricht ab, wenn keine Ausnahmen mehr vorliegen
.....
int ausnahme = 0;
ausnahme = Connect.doUpdate("INSERT INTO Ausnahme (temp ClusterID,"+
"ClusterID )"+
"SELECT * FROM Ausnahme Sicht;");
WHILE(ausnahme != 0)
{
Connect.doUpdate("UPDATE Ausnahme AS A1 INNER JOIN Ausnahme AS A2"+
"ON A1.ClusterID = = A2.tempClusterID"+
"SET A1.ClusterID = A2.ClusterID")
Connect.doUpdate("UPDATE Cluster INNER JOIN Ausnahme "+
"ON Cluster.ClusterID = Ausnahme.temp ClusterID"+
"SET Cluster.ClusterID = Ausnahme.ClusterID");
90
6.3 Realisierung der Evolutionsumgebung
//Bei nicht behobenen Ausnahmefällen werden weitere Tupel in die Tabelle
Ausnahme eingefügt
Connect.doUpdate("DELETE * FROM Ausnahme");
ausnahme = Connect.doUpdate("INSERT INTO Ausnahme (temp ClusterID,"+
"ClusterID)"+
"SELECT * FROM Ausnahme Sicht;";
}
Bei Beendigung der WHILE -Schleife werden die ClusterIDs ausgelesen.
ResultSet rsx = stmt.executeQuery("Select Distinct x,y,ClusterID "+
"From Moore-Nachbarschaft");
Um ungefähr die Geschwindigkeit der Clusterbestimmung zu vermitteln, obwohl diese
von mehreren Faktoren abhängt, wie groß beispielsweise die einzelnen Cluster sind, beansprucht die Clusterbestimmung von 50 Zellen (mehrere kleine und ein größeres Cluster)
100ms beansprucht. Es wurde bei diesem Beispiel die Struktur eines Monitoringsystems
deutlich. Bei einem traditionellen Umgang mit Datenbanken wird meist mit stabilen Daten
und sich verändernden Abfragen gearbeitet. Hingegen ein datenbankbasierten Monitoringsystem eher Verwendet wird, wenn sich die Daten ständig ändern und die Anfragen bzw.
die Analysen stabil bleiben. Wie beim Simulationsprozess ist es auch hier nicht sinnvoll
die Daten in jedem Zeitschritt inkrementell zu modifizieren, es hat sich als effizienter herausgestellt diese hier vollständig neu zu berechnen.
Es wurden die Umsetzung der Simulation des GOL und eines Analyseverfahren diskutiert,
folgend wird die Realisierung des dritten Aspektes, der Erweiterung um Visualisierungskonzepte (siehe Kapitel 4.3) des Life-Monitoringsystems besprochen.
6.3 Realisierung der Evolutionsumgebung
Bei der Betrachtung des Visualisierungskonzeptes wird sich im Folgenden exemplarisch
mit der Realisierung der Evolutionsumgebung und der damit einhergehenden Analyse
der räumlichen Ausbreitung der Cluster befasst. Wie in den Abschnitten zuvor fungiert
der Analyse-Manager des Controllers zur Synchronisation der einzelnen Anweisungen, zur
ergänzenden Unterstützung des datenbankbasierten Verfahrens und der Weiterleitung der
Ergebnisse und Aufrufe an das DBMS.
Bei der Initialisierung der Analysefunktion der Evolutionsumgebung werden die aktuell
zuvor ermittelten Cluster erfasst und mit der Ausbreitung ihrer zugehörigen bounding box
gespeichert. Die Evolutionsumgebung ist somit eine bounding box, welche über mehrere
Generationen ermittelt wird. Sie zeigt in einer einfachen geometrischen Figur die Ausbreitung von einer Menge von Clustern an. Als ID einer Evolutionsumgebung fungiert beim
Start der Analyse die eindeutige ID der vorliegenden bounding box, wodurch der jeweilige
Zusammenhang, mit der beginnenden bounding box verdeutlicht wird. Ein zusätzlicher
91
6 Ausgewählte Aspekte der Implementierung
Vorteil ist, dass im späteren Verlauf der Analyse die Anzahl der durchzuführenden Zuweisungen durch JOINs eingeschränkt wird.
INSERT INTO Evolutionsumgebung (EvolutionsID, Minx,Maxx,Miny,Maxy)
SELECT ClusterID,Minx,Maxx,Miny,Maxy
FROM boundingbox;
Es handelt sich bei dieser Überwachung um eine Prozessüberwachung, wobei eine Auswertung von sich ständig ändernden Daten durchgeführt wird. Zur Verfolgung einzelner
Objekte ist es notwendig, in jeder aufeinander folgenden Generation, die aktuellen Objekte
mit ihren Vorgängern zu identifizieren, um sie durchgehend verfolgen zu können. Konkret
heißt das hier, die Cluster, die einer Evolutionsumgebung zugeordnet sind, in der FolgeGeneration wieder zuerkennen und die Zuordnung zu wahren. In der Implementierung des
Life-Monitoringsystems wird keine Historie gespeichert, sondern nur zur Verfolgung der
Cluster über die Generationen hinweg, die aktuelle und die vorausgegangene Generation in Form der vergangenen und aktuellen Cluster. Es existiert somit keine Tabelle über
die Zeit hinweg, welche die zugehörigen Cluster mit Angabe der jeweiligen Generation
speichert. Selbst wenn es diese Speicherungen geben sollte, ist hier bei der Auswertung
über einen längeren Zeitraum die inkrementelle Modifizierung der Evolutionsumgebung
gegenüber einer naiven ständig wiederholenden neuen Berechnung im Vorteil. Um die aktuellen Clustern bzw. deren bounding box den Evolutionsumgebungen zuzuweisen, wurde
beim Datenbankentwurf die Tabelle erweitert durch eingeführt, mit dem Attribut der ID
der Evolutionsumgebung und der ClusterID. Da bei der Aktivierung alle aktuellen bounding boxes eine Evolutionsumgebung initialisieren, werden schließlich alle in diese Tabelle
eingefügt.
INSERT INTO erweitert durch (EvolutionsID,ClusterID)
SELECT ClusterID, ClusterID FROM bounding box;
Die beiden vorgestellten initialisierenden Anweisungen werden wie gewohnt von dem
Analyse-Manager, an den DB-Manager, hin zum DBMS weitergeleitet. Diese Initialisierung wird nur bei Aktivierung dieser Analysefunktion durchgeführt. Beim Generationswechsel beginnt die eigentliche Analyse der Evolutionsumgebung und ihrer Entwicklung
über die Zeit. Hier muss zunächst identifiziert werden, welche Cluster der aktuellen Generation aus denen der vorausgegangen Generation hervorgegangen sind. Bei dieser Ermittlung ist zu beachten, dass sich Cluster aufgespalten oder mit anderen vereinigt haben
können. Diese Phase der Analyse basiert auf einer vorangegangenen Clusterbestimmung.
Zur Ermittlung werden die eingeführten Tabelle Cluster und die Tabelle vorausgegangene Cluster, welche dieselbe Struktur aufweisen, benutzt. Mit Berücksichtigung der in
dieser Diplomarbeit spezifischen Definition eines Clusters, dass die innehabenden Zellen
auch durch eine tote Zelle von einander getrennt sein können, wird das Analyseverfahren
der Identifizierung entwickelt.
Zur Identifizierung genügt es zu überprüfen, welche Nachbarschaftszellen eines aktuellen
Clusters sich mit den lebenden Zellen eines vergangenen Clusters überschneiden. Umgekehrt wäre eine Überprüfung auch möglich, es müssen aber die Nachbarschaftszellen der
92
6.3 Realisierung der Evolutionsumgebung
Cluster einer Generation mit den Zellen einer anderen Generation überprüft werden, da es
ansonsten bei einem Ausnahmefall zu einem Fehler kommen könnte (siehe Abbildung 6.3).
Abbildung 6.3: Ausnahmefalle
Die Zuordnung wird mit Hilfe eines JOINS, mit der erläuterten JOIN-Bedingung, der
Überschneidung der genannten Zellen realisiert. Mit dem DISTINCT -Operator werden
die Duplikate eliminiert. Es müssen alle Zellen bei dieser Zuordnung betrachtet werden,
um eine Aufspaltung eines Cluster und/oder eine Vereinheitlichung zweier oder mehrerer
Cluster zu berücksichtigen. Da auf diese Ergebnisse des öfteren zugegriffen wird und sie
bei mehreren Analysen eine Rolle spielen, wird diese Sicht, um nicht redundant berechnet
werden zu müssen, materialisiert. Für diese Zwecke wurde die Tabelle folgt aus erstellt, in
denen die Hergeleiteten Daten der Sicht gespeichert werden.
CREATE VIEW folgt aus Sicht AS
SELECT DISTINCT vergangene Cluster.ClusterID AS vergangene ClusterID,
Cluster.ClusterID
FROM vergangene Cluster
INNER JOIN Cluster
ON (Cluster.yNZ =vergangene Cluster.y)
AND (Cluster.xNZ = vergangene Cluster.x);
INSERT INTO folgt aus (vergangene ClusterID,ClusterID}
SELECT * FROM folgt aus;
Die nächste Phase dieser Analyse ist, um den Evolutionsumgebungen die aktuellen Cluster
zuzuordnen, die erweitert durch Tabelle zu aktualisieren. Bei dieser Aktualisierung muss
berücksichtigt werden, dass Cluster sich aufgelöst, aufgespalten oder sich mit anderen
vereinigt haben könnten. Um diesen Fällen gerecht zu werden, müssten Tupel spezifisch
modifiziert, gelöscht und/oder eingefügt werden. Zur Vermeidung dieser aufwendigen Berechnungen wird die Tabelle erweitert durch einfach vollständig überschrieben. Da sich
allerdings die Sicht der Aktualisierung auf die Basistabelle selber bezieht und damit eine referenzielle Integrität vorliegt, muss diese Sicht vorerst in einer temporären Tabelle
gespeichert werden.
93
6 Ausgewählte Aspekte der Implementierung
CREATE VIEW erweitert durch Sicht
SELECT erweitert durch.EvolutionID, folgt aus.ClusterID
FROM erweitert durch INNER JOIN folgt aus
ON erweitert durch.ClusterID = folgt aus.vergangene ClusterID;
INSERT INTO erweitert durch (EvolutionID,ClusterID)
SELECT * FROM erweitert durch Sicht;
Nach der Ermittlung der Zuordnung müssen die Evolutionsumgebungen hinsichtlich der
räumlichen Ausbreitung der zugehörigen Cluster und ihrer bounding box aktualisiert werden. Da zu einer Evolutionsumgebung mehrere boxes gehören können, müssen mittels einer
Gruppierung und Aggregierung die Extremwerte der Ausbreitung ermittelt werden. Diese
Sicht ist für die notwendige Update-Anweisung nicht aktualisierbar und muss somit materialisiert werden. Um die einzelnen Evolutionsumgebungen zu aktualisieren, müssen die
Werte der aktuellen Ausdehnung mit denen der Evolutionsumgebung verglichen werden
und bei bestimmten zutreffenden Bedingungen aktualisiert werden. Diese Bedingungen
sind die folgenden: Falls die Minx- und Miny-Werte, der entsprechend ermittelten Ausdehnung, kleiner sind als die Minx- und Miny-Werte der Evolutionsumgebung, werden
diese angepasst. Umgekehrt verhält es sich bei den Maxx und Maxy-Werten.
Die MS-JET Engine von Access lässt bei Update-Operationen keine spezifischen WHEREKlauseln für einzelne SET-Anweisungen zu. Die WHERE-Klausel gilt für alle Aktualisierungen gleichermaßen. Um den Bedingungen gerecht zu werden, müssten also insgesamt
vier Update-Operationen, mit jeweils aufwändigen JOINS und den spezifischen Abfragen, für die Tupel folgen. Bei der Analyse der aktuellen Ausbreitung könnte man die
WHERE-Klauseln einsparen, indem gleich die aktuellen Werte der Evolutionsumgebung
mit in die Berechnung einbezogen werden. Es wären immer noch vier Update-Operationen
durchzuführen. Um dies zu vermeiden, wird stattdessen, mit Einbeziehung der Werte
der Evolutionsumgebungen, die aktuelle Ausbreitung berechnet und mit diesem Ergebnis
überschrieben. Hierbei wird die vorher durchgeführte Analyse der Zuordnung der Cluster
genutzt und mit UNION die Tupel zusammengefasst. Mittels der Gruppierung nach den
IDs der Evolutionsumgebung werden die kleinsten bzw. größten Werte ermittelt.
CREATE VIEW Evolutionsumgebung temp Sicht
SELECT EvolutionID, Min(Minx), Max(Maxx), Min(Miny),Max(Maxy)
FROM (
SELECT EvolutionID, Minx, Maxx, Miny, Maxy
FROM(
erweitert durch INNER JOIN bounding box
ON erweitert durch.ClusterID = bounding box.boxID
UNION
SELECT Evolutionsumgebung.EvolutionID,Min,Maxx,Miny,Maxy
FROM Evolutionsumgebung INNER JOIN erweitert durch
ON Evolutionsumgebung.EvolutionID = erweitert durch.ClusterID
) AS Ausdehnung
GROUP BY EvolutionID;
INSERT INTO Evolutionsumgebung temp
SELECT * FROM Evolutionsumgebung temp Sicht;
94
6.3 Realisierung der Evolutionsumgebung
Bei Anzeige der Evolutionsumgebung durch das GUI werden die charakteristischen Eckpunkte der Evolutionsumgebungen an dieses weitergeleitet und vervollständigt. Man
könnte bei der bounding box oder der Evolutionsumgebung auch die durchgehenden
räumlichen Grenzen aufnehmen. Das würde unnötige komplizierte Operationen mit sich
bringen und zu einer Verschlechterung der Performanz führen. Durch den GUI-Manager
lassen sich die durchgehenden Grenzen mittels einer Schleife schnell und unkompliziert
ergänzen. Im Gegensatz zu den beiden vorherigen Erläuterungen des Simulationsprozesses und der Clusterbestimmung werden die Werte der Evolutionsumgebung inkrementell
aktualisiert. Der Grund ist die Bestimmung und Beobachtung dieser Objekte der Prozessüberwachung über einen längeren Zeitraum. Es ist hierbei nicht sinnvoll die vorhergehenden Berechnungen die in jeder Generation stattgefunden haben zu wiederholen.
95
6 Ausgewählte Aspekte der Implementierung
96
7 Zusammenfassung und Ausblick
In dieser Diplomarbeit wurde das datenbankbasierte Monitoringsystem in der Testumgebung der zellulären Automaten erfolgreich implementiert. Die Testumgebung ist hier
die Simulation des Game of Life“ (GOL). In diskreten Zeitschritten werden vom Daten”
bankmanagementsystem die Generationen des GOL berechnet und vom Monitoringsystem
ausgewertet. Die entwickelte graphische Oberfläche dient dem Anwender dazu, mit dem
System in einfacher Weise zu interagieren und die Ergebnisse der Überwachung bzw. der
Analysen graphisch aufzuzeigen.
Kapitel 2 und 3 vermittelten die theoretischen Grundlagen dieser Arbeit in Bezug auf die
Informatik und den zellulären Automaten. Bei den zellulären Automaten steht im Besonderen das GOL im Mittelpunkt. Aufbauend auf diesen Grundlagen wurde in Kapitel 4 mit
dem vorgestellten Entity-Relationship-Modell der konzeptuelle Entwurf für die Objekte
des GOL und den datenbankbasierten Analysen durchgeführt, gefolgt vom logischen Entwurf anhand des relationalen Datenmodells. Weiterhin wurden die Algorithmen des Monitoringsystems diskutiert und erarbeitet, wie die Clusterbestimmung, die eine Schlüsselrolle
bei den Analysen einnimmt. Die Struktur des Gesamtsystems und die Interaktion und
Synchronisation der einzelnen Komponenten wurde in Kapitel 5 vorgestellt. Hier erfolgte
mit anschaulichen Beispielen die Umsetzung der Analysefunktionen des Monitoringsystems. Schließlich wurde in Kapitel 6 ausführlich die Realisierung von drei exemplarischen
datenbankbasierten Analysen entwickelt. Die Umsetzung erfolgte nach spezifischen Eigenschaften der Datenbanksprache SQL und des DMBS von MS Access 2007.
Eine Evaluierung, inwieweit das DBMS intern die SQL-Anweisung umsetzt, ist bei einzelnen Implementierungen wie der Clusterbestimmung wesentlich, um dies für die datenbankbasierte Lösung der Algortihmen performant umzusetzen. Die spezifischen internen
Abläufe, sind dabei ausschlaggebend für grundsätzliche Entscheidungen zur Realisierung
eines Algorithmus, welche bei anderen Anbietern von Datenbanksystemen anders ausgefallen wären. Der nicht immer offensichtliche Kosten-Nutzen-Faktor einzelner datenbankbasierter Anweisung muss genau untersucht werden, um eine möglichst leistungsstarke Lösung zu entwickeln. Von Microsoft und dem Hilfsmenü von MS Access erfährt
man indes keine große Unterstützung, sondern muss selbst in diesen Gebieten die interne
Abläufe und Möglichkeiten erforschen. Die Aufgaben des Systems konnten vom DBMS
von MS Access weitestgehend durchgeführt werden. Ausnahmen bildeten die Umsetzung
einer Rekursion und einer Iteration bis zu einer bestimmten Abbruchbedingung, welche
nur mit Unterstützung des Java-Programms umsetzbar waren. Java hat weitere Aufgaben übernommen wie die Synchronisation der einzelnen Anweisungen und die graphische
Darstellung der Ergebnisse der datenbankbasierten Berechnungen.
97
7 Zusammenfassung und Ausblick
Im Rahmen der Ereignisüberwachungen beim GOL stellte sich heraus, dass es aufgrund
der hohen Fluktuation der Daten effizienter ist, diese in jeder Generation vollständig
neu zu berechnen, anstatt sie inkrementell zu aktualisieren. Hingegen ist bei den Prozessüberwachungen die inkrementelle Aktualisierung der ermittelten Ergebnisse der vorangegangenen Generationen mit den aktuellen Schlüssen der effizienteste Weg. Wobei es
auch hier notwendig ist die aktuelle Generation neu auszuwerten. Die Entscheidung einer
Umsetzung ist immer abhängig vom jeweiligen Informationsfluss, die das Monitoringsystem beobachten muss und bedarf einer genauen Evaluierung.
Das konzipierte datenbankbasierte Monitoringsystem und die Realisiernug der Algorithmen mit SQL zeugen von einem effizienten Umgang mit großen strukturierten Datenmengen. Durch die definierten Sichten konnten die aktuell vorliegenden Tupel intern performant zugeordnet, verglichen und analysiert werden und stehen somit in ernsthafter
Konkurrenz zu herkömmlichen Software-Systemen bei Datenbankanwendungen.
In dieser prototypischen Implementierung wurde folgendes Realisiert,die Clusterbestimmung, die Klassifizierung in Gleiter, Oszillatoren und in statische Objekte, sowie die Darstellung der bounding box, die Berechnung einer Kollisionsgefahr, die Ermittlung der Evolutionsumgebung, die Trajektorie der Cluster und die Simulation des GOL.
Es werden nun weitere Konzepte vorgestellt, deren Realisierungen im Rahmen dieser Arbeit nicht mehr möglich waren. Eine optionale Ergänzung des Systems wäre es, den Raum
des zellulären Automaten sich dynamisch erweitern zu lassen, falls sich lebende Zellen den
Rändern nähern. Die graphische Darstellung bietet weitere Möglichkeiten, beispielsweise
wie Zoom-Optionen und Ausschnittsweise Betrachtung. Der flexible der Bewegung eines
Clusters folgende Raum, so dass dieses Cluster den dargestellten Raum nicht verlassen
würde, ist eine weitere Idee.
Die nächsten Vorschläge betreffen die Überwachung der globalen Konstellation. Es könnte
die Verteilung von lebenden Zellen statistisch ausgewertet werden, in welchen partiellen
Räumen, sich durchschnittlich wie viele Zellen befunden haben. Die Dichte der Population
in einem partiellen oder ganzen Raum und die Auswirkung auf die Entwicklung bzgl. der
nachfolgenden Generationen ist eine weitere Analyse-Option. Somit könnte der Wert einer
erfolgversprechenden Dichte für eine blühende Evolution berechnet werden.
Ein Vorschlag zur Entdeckung von neuen Objekten ist das Spielfeld dem Anwender
zunächst nur zur Bestimmung der Anfangkonstellation darzustellen und im Weiteren nur
die Objekte, die spezifische Kriterien erfüllen, unabhängig von ihrem aktuellen Ort.Die
aufwendige graphische Darstellung des gesamten Spielverlaufs wird vermieden und die
Größe des Raumes wäre nur durch den vorliegenden Speicherplatz beschränkt. Die Anfangskonfiguration könnte auch automatisch generiert werden.
98
Zusammenfassend lässt sich sagen, dass eine Umsetzung von komplexen Analysen bei
großen Datenmengen mittels Datenbanktechnologie performant möglich ist. In dieser Diplomarbeit ist ersichtlich, dass das datenbankbasierte Verfahren mehr als eine nennenswerte Konkurrenz zu etablierten prozeduralen Software-Systemen ist.
99
7 Zusammenfassung und Ausblick
100
Literaturverzeichnis
[Auer2008] Auer, Jürgen, Berlin: SQL Tutorial, 2008
http://www.sql-und-xml.de/sql-tutorial/update-aktualisieren-der-zeilen.html
[BB2007] Honegger, Döbeli: Beats Biblionetz
http://beat.doebe.li/bibliothek/w01401.html (Stand 12.07)
[Berlekamp1985] Berlekamp Elwyn ,Conway J.H. and Guy R.K.: Gewinnen.Strategien für
mathematische Spiele, Ausgabe 4. Vieweg Verlag, Braunschweig
[Bellman1957] Bellman, Richard: Dynamic Programming, Princeton University Press,
1957
[Bode2007] Bode, Thomas: Folien zur Vorlesung Relationale Datenbanken I und II.
Universität Bonn, Institut für Informatik III, SS 2006 - WS 2007
http://www.informatik.uni-bonn.de/ tb/Lehre/ss07/RDB/index.html
[Callahan] Callahan, Paul, Patterns, Programs, and Links for Conway’s Game of Life,
2001 http://www.radicaleye.com/lifepage/
[Chen1976] Chen, Peter: The Entity-Relationship Model - Toward a Unified View of Data.
In: ACM Transactions on Database Systems, Nr.1, 1976 S. 9-36
[Codd1970] Codd, Edgar F.: A Relational Model of Data Large Shared Data Banks. In:
Communications of the ACM. S. 377-387, 1970
[DatDar1998] Date, Chris J. ; Darwen, Hugh; SQL-Der Standard, Addison Wesley, 1998
[Gardner1970] Gardner, Martin: The fantastic combinations of John Conway’s new solitaire game life“. In: Scientific American, Mathematical Games, 1970, S. 120-123
”
[KemEik2004] Kemper, Alfons; Eickler, Andre: Datenbanksysteme: Eine Einführung, 4.
Auflage, Oldenburg Verlag 2004
[Levy1993] Levy, Steven KL-Künstliches Leben aus dem Computer,
Droemer Knaur Verlag, 1993
[Lorenz1963] Lorenz, Edward N.: Deterministic Nonperiodic Flow
In: Journal of the Atmosperic Sciences, Vol. 20, No. 2, S. 130-141,1963
[Mainzer2006] Mainzer, Klaus: Was sind komplexe Systeme.
Institut für Interdisziplinäre Informatik Universität Augsburg
http://www.integrative-wissenschaft.de/Themen/texte/mainzer-manuskript.pdf
[Manthey2004] Manthey, Rainer: Folien zur Vorlesung Informationssysteme. Universität
Bonn, Institut für Informatik III, WS 2003/2004
http://www.informatik.uni-bonn.de/ manthey/
101
Literaturverzeichnis
[Manthey2007] anthey, Rainer: Folien zur Vorlesung Database Techniques for Event Monitoring Systems Universität Bonn, Institut für Informatik III, SS2007
http://www.informatik.uni-bonn.de/ manthey/
[Milbradt] Milbradt, Peter: Theorie und Anwendung Zellulare Automaten
http://www.bauinf.uni-hannover.de/m̃ilbradt/Lehre/ModellSimul/7 zellulareAutomaten.pdf
[Moore1959] Moore, Edward F.: The shortest path through a maze In: Proceedings of the
International Symposium on the Theory of Switching, Harvard University Press,
1959, S.:285-292.
[NagSch1992] Nagel, Kai; Schreckenberg, Michael: A cellular automaton model for freeway
traffic“. In: J Physique I 2, S. 2221-2229, 1992
[Ray]
Ray, Tom: Künstliches Leben, 1997
http://www.heise.de/tp/r4/artikel/2/2158/1.html
[Schmidthuber2007] Schmidthuber: Alle berechenbaren Universen. In: Spektrum der Wissenschaft Spezial, Ist das Universum ein Computer,2007 S. 79
[Silver] Silver, Stephen: Life Lexicon
http://www.argentum.freeserve.co.uk/lex.htm
[Spektrum2007] Zuse, Konrad: Rechnender Raum In: Spektrum der Wissenschaft Spezial,
Ist das Universum ein Computer? S.8
[Türker2003] Türker, Can: SQL:1999 & SQL:2003- Objektrelationales SQL, SQLJ 6
SQL/XML. In: Dpunkt Verlag, 2003
[TürSaa2005] Türker, Can, Saake, Gunter; Objektrelationale Datenbanken - Ein Lehrbuch.
In: Dpunkt Verlag, 2005
[Ullenboom2007] Ullenboom, Christian: Datenbankmanagement mit JDBC In: Java ist
auch eine Insel, Galileo Computing, 2007
[Vichniac1984] Vichniac, Gérad Y.: Simulating Physics with Cellular Automata“. In: Physika 10 D, Elsevier Science B.V., S.96, 1984
[von Neumann1966] von Neumann, John: The Theory of Selfreproducing Automata A.
Burks, ed., Univ. of Illinois Press, Urbana, IL.,1966
[Weisstein] Weisstein, Eric: Enzyklopädie Life
http://www.ericweisstein.com/encyclopedias/life/
[Wolfram1983] Wolfram, Stephen: A New Kind of Science, Wolfram Media, Champaign,
IL, USA, 1983
[Worsch2007] Worsch, Thomas:Algortihmen in Zellularautomaten Universität Karlsruhe (TH), Sommersemester 2007 http://liinwww.ira.uka.de/courses/vl/algza/k01.pdf
[Zuse1967] Zuse, Konrad: Rechnender Raum In: Elektronische Datenverarbeitung, Vol. 8,
S. 336-344. ftp://ftp.idsia.ch/pub/juergen/zuse67scan.pdf
102