Diplomarbeit: Effiziente Überprüfung von

Technische Universität Ilmenau
Fakultät für Informatik und Automatisierung
Institut für Praktische Informatik und
Medieninformatik
FG Datenbanken und Informationssysteme
Effiziente Überprüfung von
Ausgabebedingungen in einem
Multimedia - Datenbanksystem
Diplomarbeit zur Erlangung des
akademischen Grades Diplominformatiker
Thomas Schröder
Betreuer:
Dipl.-Inf. Thomas Heimrich
Verantwortlicher Hochschullehrer: Prof. Dr.-Ing. Kai-Uwe Sattler
Die Diplomarbeit wurde am 20.05.2005 bei der Fakultät für Informatik
und Automatisierung der Technischen Universität Ilmenau eingereicht.
Inventarisierungsnummer: 2005-05-23/052/IN98/2254
Zusammenfassung
Der äußere Aufbau und die zeitliche Abfolge eines Medienprojektes können über
Ausgabebedingungen definiert werden. Es existieren Beschreibungsmöglichkeiten,
die auf Konsistenz geprüft werden können und eine Berechnung des Ausgabeschedule aufgrund relativer Zeitabstände ermöglichen. Bei großen Projekten ist kein
effizienter Algorithmus für die Überprüfung bekannt. Des Weiteren sind die in Datenbanksystemen vorhandenen herkömmlichen Mechanismen zur Integritätssicherung der Bedingungen unzureichend. Eine Verwaltung der Objekte und Bedingungen an einer zentralen Stelle ist aber wünschenswert, um anwendungsunabhängig
die Konsistenz zu gewährleisten.
Die vorliegende Arbeit stellt Algorithmen zur effizienten Überprüfung der Ausgabebedingungen und zur Berechnung des Ausgabeschedule vor. Die in einem Datenbankmanagementsystem realisierten vorgestellten Methoden werden anschließend hinsichtlich des praktischen Gebrauchswertes bewertet. Die Messergebnisse
zeigen, dass mit den Algorithmen auch große Projekte effizient verwaltet werden
können.
Inv.-Nr.: 2005-05-23/052/IN98/2254
Inhaltsverzeichnis
1 Einführung und Motivation
9
2 Grundlagen und Related Work
2.1 Multimedia-Datenbanksysteme . . . . . . . . . . . . . . . .
2.2 Integritätsbedingungen . . . . . . . . . . . . . . . . . . . . .
2.3 Architekturen zur Integritätssicherung . . . . . . . . . . . .
2.3.1 Integritätssicherung durch Anwendung . . . . . . . .
2.3.2 Integritätssicherung durch DBMS . . . . . . . . . . .
2.3.3 Integritätssicherung durch Kapselung . . . . . . . .
2.4 Aktive Datenbanksysteme und Trigger . . . . . . . . . . . .
2.5 Modellierung von Ausgabebedingungen . . . . . . . . . . .
2.5.1 Allen-Relationen . . . . . . . . . . . . . . . . . . . .
2.5.2 Difference Constraints . . . . . . . . . . . . . . . . .
2.5.3 Bellman und Ford . . . . . . . . . . . . . . . . . . .
2.5.4 Eingabe der Bedingungen - Der Constraint Manager
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
14
14
15
15
16
17
19
20
21
21
23
3 Überprüfung mit Bellman - Ford
3.1 Beschränkungen und Beispiele . . . .
3.2 Klassifizierung der Allen-Relationen
3.3 Optimierungen . . . . . . . . . . . .
3.4 Änderung der Objektdauer . . . . .
3.5 Reduzierung der Kantenanzahl . . .
3.6 Weitere Laufzeitoptimierungen . . .
3.7 Realisierung im DBMS . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
30
34
38
41
41
42
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Numerische Konsistenzprüfung
43
4.1 Erzeugen der Ungleichungen . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Änderung einer Relation . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Umsetzung durch Trigger/Constraints . . . . . . . . . . . . . . . . . 48
5 Berechnung des Ausgabeschedule
5.1 Ausgabeschedule . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Berechnung am Beispiel . . . . . . . . . . . . . . . . . . . . .
5.3 Optimierungen . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Änderung einer Bedingung am Ende eines Stranges . .
5.3.2 Änderung einer Bedingung am Anfang eines Stranges
5.3.3 Änderung einer Bedingung in der Mitte eines Stranges
5.4 Änderung der Objektdauer . . . . . . . . . . . . . . . . . . .
5.5 Graphen mit mehreren Strängen . . . . . . . . . . . . . . . .
Inv.-Nr.: 2005-05-23/052/IN98/2254
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
51
52
54
55
57
62
64
66
6
INHALTSVERZEICHNIS
5.6
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6 Evaluierung
6.1 Testprojekte und Messmethode . . . . . . . . . . .
6.2 Optimierung des graphischen Konsistenzcheck . . .
6.2.1 Überprüfung von Änderungen als Teilgraph
6.2.2 Reduzierung der Kantenanzahl . . . . . . .
6.3 Numerische Konsistenzprüfung . . . . . . . . . . .
6.4 Scheduleberechnung . . . . . . . . . . . . . . . . .
6.5 Zwischenstand . . . . . . . . . . . . . . . . . . . .
6.6 Umsetzung im DBMS . . . . . . . . . . . . . . . .
6.6.1 Speichern des Graphen in der Datenbank .
6.6.2 Manipulation von Bedingungen . . . . . . .
6.6.3 Zusammenfassung . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
81
81
84
84
86
87
88
91
92
92
95
99
7 Zusammenfassung und Ausblick
101
7.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
A Erweiterte Allen-Relationen
103
A.1 Übersicht der Relationen . . . . . . . . . . . . . . . . . . . . . . . . . 103
A.2 Numerische Bedingungen der Relationen . . . . . . . . . . . . . . . . 103
Literaturverzeichnis
107
Thesen
109
Eidesstattliche Erklärung
111
Inv.-Nr.: 2005-05-23/052/IN98/2254
Abkürzungsverzeichnis
AR . . . . . . . . . . . . . . . Allen-Relationen
DBMS . . . . . . . . . . . . Datenbankmanagementsystem
DBS . . . . . . . . . . . . . . Datenbanksystem
DDL . . . . . . . . . . . . . Datendefinitionssprache
DML . . . . . . . . . . . . . Datenmanipulationssprache
ECA . . . . . . . . . . . . . Event Condition Action
MMDBS . . . . . . . . . . Multimedia-Datenbanksystem
SMIL . . . . . . . . . . . . . Synchronized Multimedia Integration Language
WFS . . . . . . . . . . . . . Wellenfeldsynthese
ZE . . . . . . . . . . . . . . . Zeiteinheit
Inv.-Nr.: 2005-05-23/052/IN98/2254
Kapitel 1
Einführung und Motivation
Multimediadaten spielen in der heutigen Zeit eine zunehmend größere Rolle in vielen Bereichen des alltäglichen Lebens. Es gibt kaum einen Computer, der nicht auf
irgendeine Art und Weise Multimediadaten verarbeiten kann. Der Begriff Multimedia entsteht durch Komposition der beiden Teile Multi (viel, vielfach) und
media (Medium). Medien definieren sich laut Brockhaus Enzyklopädie als: Ver”
mittlungssysteme für Informationen aller Art, ihre Funktion ist der Transport von
Inhalten“ [Lex91]. Sie speichern bzw. stellen Informationen in Form von Texten, Bildern, Graphiken, Sprache oder Musik dar. Im Allgemeinen spricht man von Multimedia, wenn viele Medien“ gemeinsam verwendet werden, sie aber ein bestimmtes
”
Ziel verfolgen [Lex89]. In dieser Arbeit werden ausschließlich digitale Medien betrachtet, also Videos, Audiosamples, Bilder oder Texte, die in elektronischer Form
für den Computer lesbar vorliegen.
Multimediadaten alleine stellen noch keinen großen Informationswert dar. Durch
die Komposition verschiedener Medien entsteht (meistens) für den Nutzer ein Mehrwert gegenüber einzelnen Medien. Eine einfache Form ist z. B. der Hypertext. Neben der Darstellung von verknüpften Text lassen sich auch Bilder, Videos oder
Sprachmitteilungen einbinden. In diesem Zusammenhang spricht man auch von
Hypermedia [Lex92]. Des Weiteren existiert inzwischen eine Vielzahl von multimedialen Präsentationen, die es dem Anwender erlauben, den Ablauf interaktiv zu
gestalten. Sie werden häufig bei Vorträgen oder Schulungen eingesetzt.
Eine große Rolle spielen Multimediadaten in der Filmproduktion: angefangen
vom Home-User, der seine privaten Filmaufnahmen digital nachbearbeitet oder neu
zusammenstellt, bis hin zu Kinofilmen, die komplett digital erstellt werden und sich
letztendlich nur aus einzelnen Medienobjekten zusammensetzen.
Mit den Fortschritten in der PC-Technik steigen sowohl die Möglichkeiten als
auch die Anforderungen an Multimediaprojekte. Das bedeutet, dass die Qualität
und auch die Quantität der Multimediadaten zunehmen. Mit steigender Komplexität von Multimediaprojekten wächst auch die Zahl der zu verwaltenden Einzel(medien)objekte. Um die Verwaltung der Datenmassen möglichst effizient zu
gestalten, ist es sinnvoll, sie an einer zentralen Stelle zu speichern: vorzugsweise
in einer Datenbank. Das gilt sowohl für Daten im herkömmlichen Sinne (Zahlen,
Wörter, Text, Flags) als auch für Multimediadaten. Da es sich hierbei nicht um
einfache“ Daten im Sinne von alphanumerischen Zeichenfolgen handelt, werden sie
”
in Multimedia-Datenbanksystemen (MMDBS) gespeichert.
Neben der Speicherung der Objekte ist auch der Zeitpunkt ihrer Ausgabe von
Inv.-Nr.: 2005-05-23/052/IN98/2254
10
KAPITEL 1. EINFÜHRUNG UND MOTIVATION
o3
o1
0
o2
15 17
27
42 47
Zeit
Abbildung 1.1: Absolute Ausgabezeiten von Medienbjekten
t3
t2
o3
t1
o1
0
o2
Zeit
Abbildung 1.2: Verknüpfung von Medienobjekten über relative Zeitabstände
Bedeutung. Eine lose Ansammlung von Medienobjekten in einer Datenbank ergibt noch keinen Film oder Musikstück. Möchte man einen Kuchen backen und
alle Zutaten liegen schon bereit, fehlt noch die Beschreibung, wie welche Zutaten
verarbeitet werden müssen: das Rezept. Ähnlich verhält es sich mit Medienobjekten. In der Regel wir für jedes Medienobjekt ein definiertes absolutes Intervall, die
Ausgabezeit, angegeben (Abbildung 1.1). Ändert sich die Dauer eines Objektes,
muss auch das Intervall entsprechend der Änderung angepasst werden. Aus diesem
Grund ist es wichtig, Bedingungen für die Ausgabe zu formulieren, auf deren Basis
die Ausgabezeiten automatisch berechnet werden können.
Eine Besonderheit der Ausgabebedingungen ist, dass man nicht die konkreten
absoluten Zeiten angibt, zu denen die Objekte ausgegeben werden sollen, sondern
relative Zeitabstände. Die Zeiten t1 , t2 und t3 in Abbildung 1.2 bedeuten, dass
Objekt o1 genau t1 Zeiteinheiten (ZE) nach Objekt o2 kommen soll, Objekt o3
eine Dauer von genau t3 ZE haben muss und erst t2 ZE nach dem Start von o2
ausgegeben werden soll. Ändert man die Dauer eines Objektes, z. B. von o1 , ergeben
sich die Ausgabezeiten aufgrund der Bedingungen bzw. der Dauer der Objekte und
können automatisch berechnet werden. Es existiert jedoch noch keine effiziente
Methode, eine größere Anzahl von Ausgabebedingungen auf Konsistent zu prüfen
und anschließend den Ausgabeschedule zu bestimmen. Ein praktischer Gebraucht
ist momentan nur für kleine Projekte gegeben.
Das Ändern von Bedingungen kann zu Inkonsistenzen führen, wenn zwei oder
mehr Bedingungen im Widerspruch zueinander stehen. Für einfache Daten (Text,
Zahlen usw.) lassen sich beim Erstellen einer Tabelle Bedingungen definieren, so
genannte Constraints. Beim Speichern prüft das DBMS, ob die Daten mit diesen
Bedingungen konform gehen, also konsistent sind. Da es sich bei Ausgabebeding-
Inv.-Nr.: 2005-05-23/052/IN98/2254
11
ungen um komplexe Zusammenhänge handelt, sind die in Datenbanken vorhandenen herkömmlichen Mechanismen der Überprüfung nicht ausreichend. Aus diesem
Grund müssen andere Wege gefunden werden, um die Bedingungen effizient zu
überprüfen und konsistent zu halten.
Fasst man beide Ziele zusammen, die zentrale Speicherung von Medienobjekten
in einem Multimedia-Datenbanksystem und die effiziente, automatische Überprüfung der Bedingungen, stellt sich die Aufgabe, beides in einem DBMS zu zentralisieren. Das ist das Ziel dieser Diplomarbeit. Es müssen Wege gefunden werden,
die Problemstellung auf bekannte Strukturen und Methoden in einem DBMS abzubilden. Des Weiteren stellt sich die Frage nach der Kosten-Nutzen-Rechnung.
Die Abbildung der Aufgabenstellung auf bekannte Probleme, also der Weg von der
Erstellung der Ausgabebedingungen bis zur internen Darstellung in der Datenbank
und der Überprüfung verursacht Kosten. Es muss bewertet werden, ob der Nutzwert die zusätzlichen Kosten rechtfertigen. Im Idealfall soll die Speicherung der
Daten und der Bedingungen unabhängig von einem Anwendungsprogramm über
SQL-Befehle erfolgen. Der anschließende Konsistenzcheck muss sehr effizient sein,
damit ein praktischer Gebrauchswert für den Nutzer gegeben ist.
Ein konkretes Anwendungsbeispiel ist die Modulation von Audiosignalen mittels Wellenfeldsynthese (WFS) [BV94]. Sie beruht auf dem Huygen‘schen Prinzip
[GS26] und ermöglicht mit Hilfe eines Lautsprecherarrys eine exakte Erzeugung eines beliebigen Schallfeldes, das hinsichtlich Ort, Ausrichtung, Bewegung und räumlicher Umgebung physikalisch korrekt dargestellt wird [TWR02]. Als Ergebnis erhält man ein natürliches und räumliches Klangfeld an jeder Stelle des Wiedergaberaumes. Dem Hörer wird der Eindruck vermittelt, dass die Tonquellen nicht die
Lautsprecher sind, sondern sich z. B. mitten im Raum oder auch hinter der Kinoleinwand befinden. Im Gegensatz zum 5.1-Sourroundsoundsystem befindet sich der
sogenannte Sweet-Point“ (Punkt der optimalen Klangwahrnehmung) nicht an einer
”
bestimmten Stelle im Raum, sondern erstreckt sich über den gesamten Hörbereich.
Auf diese Weise ist es möglich, in einem kleinen Raum die Akkustik jedes einzelnen
Instrumentes eines in einem Konzertsaal spielenden Orchesters exakt nachzubilden.
Um diese Effekte zu erzeugen, müssen mehrere Samples in zeitlicher Abhängigkeit moduliert und im Präsentationsraum ausgegeben werden. Solche Szenen können in einer Datenbank abgespeichert und anschließend ausgegeben werden. Angewendet wird diese Methode bereits im IOSONO-System, welches am FraunhoferInstitut entwickelt [FG04] und kommerziell genutzt werden soll [FI04a]. In [HSRG04]
wird gezeigt, wie Ausgabebedingungen für die Datenmodellierung und korrekte
Ausgabe der Medienobjekte zur Wellenfeldsynthese genutzt werden können. Aufbauend auf dieser Quelle beschäftigt sich diese Arbeit hauptsächlich mit der effizienten Überprüfung der Bedingungen und anschließend mit der Integration in ein
Multimedia-Datenbanksystem.
Aufbau der Diplomarbeit
In Kapitel 2 wird auf alle erforderlichen Grundlagen und bisherige Arbeiten und
Artikel zu diesem Thema eingegangen und der Weg von der Modellierung der Bedingungen bis zur Speicherung in der Datenbank besprochen. Anschließend werden
in den Kapiteln 3 und 4 zwei Methoden zur effizienten Überprüfung der Bedingungen vorgestellt. Neben der Konsistenz der Daten ist letztendlich auch deren
korrekte zeitliche Ausgabe wichtig. Kapitel 5 beschäftigt sich mit der effizienten
Berechnung des Ausgabeschedule. Kapitel 6 bewertet anschließend die vorgestell-
Inv.-Nr.: 2005-05-23/052/IN98/2254
12
KAPITEL 1. EINFÜHRUNG UND MOTIVATION
ten Algorithmen und Methoden.
Inv.-Nr.: 2005-05-23/052/IN98/2254
Kapitel 2
Grundlagen und Related
Work
Dieses Kapitel geht auf alle nötigen Begriffe und Methoden ein, die sich mit dem
Thema der Definition von Ausgabebedingungen, Konsistenzüberprüfung und Ausgabeschedule beschäftigen. Ebenso werden Mechanismen und Architekturen zur
Konsistenz- bzw. Integritätsüberprüfung in einem DBMS vorgestellt. Aufbauend
auf den Grundlagen, wird der Weg von der Formulierung der Bedingungen bis zum
Konsistenzcheck und Speicherung in der Daten in einer Datenbank erläutert.
2.1
Multimedia-Datenbanksysteme
Für Multimedia-Datenbanksysteme oder kurz MMDBS existiert bisher keine feste Definition. Im Allgemeinen werden Datenbankmanagementsysteme
(DBMS) als Multimedia-Datenbank bezeichnet, die eine Speicherung von Multimedia-Daten ermöglichen. Multimedia-Daten setzen sich aus zwei Komponenten zusammen. Zum einen aus Medienobjekten (Videos, Audiosamples, Bilder oder
Texte) und zum anderen aus Multimedia-Objekten, die eine Komposition aus Medien-Objekten verschiedener Medien darstellen, wie zum Beispiel ein Bild kombiniert mit einem Audio-Sample.
Da das Datenaufkommen von Multimediadaten im Allgemeinen größer ist als
das normaler“ alphanumerischer Daten, müssen MMDBS zusätzlichen Anforde”
rungen gegenüber DBMS gerecht werden. Khoshafian und Baker [KB95] formulieren folgende notwendige Funktionalitäten (vgl. [HSS03]):
• Unterstützung für Bild- und Mediendatentypen,
• Fähigkeiten, zur Verwaltung einer großen Anzahl von Medien-Objekten,
• effiziente Speicherverwaltung,
• Datenbankfunktionalität,
• Information-Retrieval-Funktionalität.
Die Speicherung von Multimedia-Daten erfolgt entweder über allgemeine Datenbanktypen oder spezielle Medien-Objekttypen. Heutige relationale oder objektrelationale Datenbankmanagementsysteme bieten die Datentypen BLOB (Binary
Inv.-Nr.: 2005-05-23/052/IN98/2254
14
KAPITEL 2. GRUNDLAGEN UND RELATED WORK
Large Objekt) oder CLOB (Character Large Objekt) zur Speicherung der Medieninhalte an. Das objekt-relationale DBMS Oracle der gleichnamigen Firma stellt
darüber hinaus spezielle Medien-Datentypen zur Verfügung. Zum Speichern eines
Bildes nutzt man den Typ Image, welcher neben den eigentlichen Bilddaten zusätzliche Attribute, wie zum Beispiel Größe oder Auflösung des Bildes zur Verfügung
stellt.
Solche Medien-Datentypen wurden als Erweiterungen von SQL:1999 definiert.
Da die Speicherung der Multimedia-Daten in dieser Diplomarbeit keine direkte
Rolle spielt, wird auf diese speziellen Datentypen nicht näher eingegangen. Die implementierten Algorithmen gehen stets von Multimedia-Objekten aus, die intern
aber nur über einen Bezeichner angesprochen werden. Die eigentlichen Daten sind
für die Definition, Überprüfung der Bedingungen und Berechnung der Ausgabezeiten nebensächlich.
In dieser Arbeit werden Datenbanksysteme als MMDBS bzw. DBMS verstanden, die eine Speicherung von Multimediadaten ermöglichen [ABH97] und aktiv
auf definierbare Ereignisse reagieren können (siehe Abschnitt 2.4).
2.2
Integritätsbedingungen
Neben der Speicherung von Daten, gehört zu den Aufgaben eines DBMS auch die
Gewährleistung der Integrität und Konsistenz der Daten. Dazu zählen neben dem
Schutz der Daten bei Mehrbenutzerzugriff auch die so genannten semantischen
Integritätsbedingungen. Diese ergeben sich aus dem Modell, mit dem das abzubildende Problem beschrieben wird (vgl. [KE01]). Wenn zum Beispiel ein Name
in einer Tabellenspalte nicht mehrfach vorkommen darf, kann man diese Bedingung (Primärschlüssel) in Form eines SQL-Befehls bei der Erzeugung der Tabelle
angeben.
Datenbanksysteme bieten standardmäßig diverse Möglichkeiten, die Integrität
der Daten durch sogenannte Constraints zu gewährleisten. So ist es zum Beispiel
möglich, für eine Spalte einen bestimmten Datentyp und Wertebereich anzugeben.
Versucht man einen Wert außerhalb dieses Bereiches einzutragen, wird die Insertoder Update-Operation abgebrochen. Auf diese Art wird die Konsistenz der Daten
in den Tabellen gewährleistet.
Die Integrität der Daten in der Datenbank muss nicht zwingend zu jedem Zeitpunkt gegeben sein. In diesem Zusammenhang spielt der Begriff der Transaktion
eine große Rolle. Eine Transaktion ist eine Folge von Anweisungen zur Manipulation
von Daten, die als Einheit betrachtet wird. Das Ende einer Transaktion wird durch
den commit-Befehl signalisiert. Nach erfolgreicher Abarbeitung der Befehlsfolge
auf einem konsistenten Datenbestand ist die Datenbank wieder in einem zulässigen
Zustand (vgl. [HS00]). Jede Transaktion muss die so genannten ACID - Eigenschaften erfüllen. ACID steht für: Atomicity (Atomarität), Consistency (Konsistenz),
Isolation und Durabiltity (Dauerhaftigkeit).
2.3
Architekturen zur Integritätssicherung
Die Integritäts- oder Konsistenzprüfung von Grunddatentypen ist gut erforscht und
in allen heutigen Datenbankmanagementsystemen implementiert. Zur Überprüfung
von Ausgabebedingungen im Sinne der Aufgabenstellung reichen diese Möglichkeiten aber nicht aus. Durch die im Vergleich zu einfachen Datentypen kompliziertere
Inv.-Nr.: 2005-05-23/052/IN98/2254
2.3. ARCHITEKTUREN ZUR INTEGRITÄTSSICHERUNG
Anwendung 1
Routinen
15
Anwendung n
Routinen
DBMS
Datenbank
Abbildung 2.1: Integritätssicherung durch Routinen in den Anwendungen
Datenstruktur und größeren funktionellen Zusammenhänge, ist auch die Konsistenzprüfung bzw. -sicherung aufwendiger.
Für die Integrität der Daten spielt es keine Rolle, an welcher Stelle der Datenbank-Anwendungsstruktur die Überprüfung erfolgt. Nachfolgend werden drei
Architekturvarianten vorgestellt, die an unterschiedlichen Punkten die Integritätsbedingungen verwirklichen (vgl. [HS00]).
2.3.1
Integritätssicherung durch Anwendung
Die Integritätssicherung ist eine von vielen Forderungen an ein Datenbankmanagementsystem. Sie muss bzw. kann aber nicht immer zwingend in vollem Umfang
durch das DBMS erfolgen. Stellt es unzureichende Integritätsbedingungen zur Verfügung, wird die Überprüfung durch die Applikation, welche auf die Datenbank
zugreift, selbst vorgenommen (Abbildung 2.1). Die Bedingungen können flexibel
in der von der Anwendung verwendeten Programmiersprache implementiert und
auf diesem Wege Unzulänglichkeiten der Integritätssicherung des DBMS beseitigt
werden. Man spricht hier von operativen Bedingungen, im Gegensatz zu deklarativen, die Bestandteil der Datendefinitions- (DDL) bzw. Datenmanipulationssprache
(DML) des DBMS sind.
Der Nachteil dieser Methode besteht in der dezentralen Überprüfung und der
daraus resultierenden Mehrfachimplementierung der Bedingungen. Dadurch können vermehrt Fehler auftauchen, bzw. die Korrektheit muss mehrfach nachgewiesen
werden. Außerdem kann es zu Inkonsistenzen nach partiellen Änderungen kommen
(Problem der verteilten Systeme).
2.3.2
Integritätssicherung durch DBMS
Eine übliche Form der Integritätssicherung für einfache Datentypen ist die Überprüfung durch einen Integritätsmonitor (Abbildung 2.2). Er ist Teil des DBMS und
Inv.-Nr.: 2005-05-23/052/IN98/2254
16
KAPITEL 2. GRUNDLAGEN UND RELATED WORK
Anwendung 1
Anwendung n
DBMS
Monitor
Datenbank
Abbildung 2.2: Integritätssicherung durch Integritätsmonitor
somit unabhängig von der jeweiligen Applikation. Die Integritätsbedingungen sind
Teil der Datendefinitions- bzw. Datenmanipulationssprache und werden über diese
deklariert. Durch die Integration der Überprüfung in das DBMS werden Redundanz
und Fehlerquellen vermieden, da die Integritätsüberwachung nur an einer zentralen
Stelle implementiert ist. Der Nachteil dieser Methode ist, dass bis heute nur sehr
einfache Bedingungen definiert werden können bzw. vom DBMS zur Verfügung
gestellt werden.
Die Integritätsbedingungen von SQL lassen sich grob unterteilen in modellinherente und tabellenübergreifende Bedingungen, welche explizit angegeben werden.
Erstere ergeben sich implizit aus der Struktur des Datenbankmodells, wie zum
Beispiel definierte Datentypen, Wertebereiche von Attributen oder Primär- und
Fremdschlüssel. Für die Überprüfung von Ausgabebedingungen von Medienobjekten sind die heute vorhandenen Möglichkeiten der modellinherenten Bedingungen
nicht geeignet.
Das Konzept der tabellenübergreifenden Integritätsregeln hat sich nicht vollständig in Datenbanksprachen durchsetzen können. Heutige Systeme unterstützen
eine simplere Version solcher Regeln: sogenannte Trigger. Sie bieten zusätzlich zu
den deklarativen Bedingungen auch die Möglichkeit zur Beschreibung von operativen Bedingungen. Durch Verwendung einer Programmiersprache, im Allgemeinen
PL/SQL oder Java, können nahezu beliebige Integritätsbedingungen definiert und
direkt durch das DBMS überprüft werden. Trigger und aktive Datenbanksysteme
werden in Abschnitt 2.4 ausführlicher besprochen.
2.3.3
Integritätssicherung durch Kapselung
Die Nachteile der bisher vorgestellen Methoden, Redundanz bei Integritätssicherung durch die Anwendung und unzureichende Bedingungen von Integritätsmonitoren, sollen durch eine dritte Architektur vermieden werden: Integritätssicherung
durch Einkapselung (Abbildung 2.3). Die Integritätsüberprüfung wird durch ei-
Inv.-Nr.: 2005-05-23/052/IN98/2254
2.4. AKTIVE DATENBANKSYSTEME UND TRIGGER
Anwendung 1
17
Anwendung n
Kapselung
DBMS
Datenbank
Abbildung 2.3: Integritätssicherung durch Kapselung
ne Zwischenschicht ausgeführt. Die Anwendungen greifen ausschließlich über diese
Schicht auf die Daten zu, ein direkter Zugriff auf die Datenbank per SQL-DDL ist
grundsätzlich nicht erlaubt. Durch die zwar vorgelagerte, aber zentrale Überprüfung wird Redundanz vermieden und das volle Spektrum der Integritätssicherung
durch operative Bedingungen in einer beliebigen Programmiersprache zur Verfügung gestellt.
2.4
Aktive Datenbanksysteme und Trigger
DBMS legen in Allgemeinen ein passives Verhalten an den Tag. Das heisst, Operationen auf den Daten werden expizit vom Nutzer ausgelöst. Wird ein reaktives
Verhalten gewünscht, also eine der Situation angepasste Reaktion auf ein Ereignis,
muss dies bisher oft aufwendig im Anwendungsprogramm implementiert werden.
Mit herkömmlichen DBMS kann solch ein reaktives Verhalten auf zwei Wege realisiert werden. Zum einen durch Polling, also regelmäßiges Abfragen der Datenbank.
Da man nicht immer abschätzen kann, wann das gewünschte Ereignis eintritt, kann
das Polling zu oft erfolgen und damit wertvolle Ressourcen belegen, oder zu selten,
und das Ereignis könnte verpasst werden. Zum anderen lässt sich diese Aufgabe in
das Anwendungsprogramm verlegen. Hier treffen aber wieder die gleichen Nachteile
wie bei der Integritätssicherung durch die Anwendung auf (vgl. Abschnitt 2.3.1).
Analog zur Integritätssicherung liegt es auch hier nahe, das Erkennen solcher
Situationen, die ein reaktives Verhalten erfordern, in das DBMS selbst zu verlegen.
Man spricht von so genannten aktiven Datenbanksystemen (aktive DBS). Eine
Definition solcher Systeme findet sich in [DG00]:
Ein Datenbanksystem heisst aktiv, wenn es zusätzlich zu den üblichen DBS-Fähigkeiten in der Lage ist, definierbare Situationen in der
Inv.-Nr.: 2005-05-23/052/IN98/2254
18
KAPITEL 2. GRUNDLAGEN UND RELATED WORK
Datenbank (und wenn möglich darüber hinaus) zu erkennen und in der
Folge davon bestimmte (ebenfalls definierbare) Reaktionen auszulösen.
Im Gegensatz zu konventionellen DBMS bieten aktive DBS zusätzliche Funktionalitäten. Zum einen muss die interessierende Situation definierbar sein und erkannt
werden können, und zum anderen muss sich eine Reaktion definieren lassen und
diese beim Erkennen der Situation automatisch ausgeführt werden. Die Aufgaben
herkömmlicher DBS sollen unabhängig von diesen neuen Funktionen in aktiven
Systemen nebenbei weiter laufen. Durch die Erweiterung um einen aktiven Teil
eines DBS basierend auf einem konventionellen System, spricht man zum Beispiel
von aktiven relationalen oder aktiven objekt-relationalen DBS.
ECA-Regel
Die interessierende Situation, auf die eine Reaktion erfolgen soll, muss in geeigneter Weise im DBMS beschrieben und auch erkannt werden. Alle Vorgänge in einem DBMS werden durch Operationen ausgelöst. Soll zum Beispiel der Wert eines
Integer-Tabellenfeldes eine bestimmte Grenze nicht überschreiten, wird überprüft,
ob dieses Feld geändert wurde (Operation) und danach mit der Grenze verglichen.
Die interessierende Situation setzt sich also allgemein aus einem Ereignis und einer
Bedingung zusammen.
Ein Ereignis ist ein Vorgang, der zu einem festen Zeitpunkt auftritt. Es wird
durch ein WAS und WANN charakterisiert. Die Bedingung gibt an, welche Voraussetzungen erfüllt sein müssen, damit zusätzlich zum Ereignis eine interessierende
Situation vorherrscht. Dazu können die Daten und der aktuelle Zustand des DBMS
genutzt werden. Eine Aktion gibt an, wie das DBMS auf eine bestimmte Situation
reagieren soll. Tritt ein Ereignis ein und ist die Auswertung der Bedingung positiv,
kann anschließend die gewünschte Aktion erfolgen. Fasst man die drei Teile (Ereignis, Bedingung, Aktion) zu einem Tripel zusammen, spricht man von Regeln, bzw.
von ECA-Regeln (event/condition/action).
Über solche Regeln wird der Zusammenhang zwischen der interessierenden Situation und der Reaktion hergestellt. Trigger sind eine eingeschränkte Version von
ECA-Regeln, werden aber häufig als Synonym für diese verwendet. Wird ein Trigger im DBMS definiert, wird das Eintreten relevanter Ereignisse überprüft. Ist dies
der Fall, wird der Trigger ausgelöst. Man sagt auch: er wird gefeuert. Anschließend wird die Bedingung auf Richtigkeit überprüft und im positiven Fall die Aktion
ausgeführt.
ECA-Regeln sind wie folgt aufgebaut:
DEFINE RULE rule name
ON event clause
IF cond clause
DO action clause
execution constraints
Das Ereignis (event clause) legt fest, WAS zum Zeitpunkt WANN geschehen
muss, um den Trigger zu feuern“. Es müssen nicht zwingend immer beide Teile
”
(WANN und WAS) angegeben werden. Spezifiziert man nur einen Zeitpunkt, stellt
der gleichzeitig auch das WAS dar. Ereignisse lassen sich in Klassen zusammenfassen, wenn sie einen ähnlichen Kontext aufweisen. Des Weiteren ist es möglich,
Inv.-Nr.: 2005-05-23/052/IN98/2254
2.5. MODELLIERUNG VON AUSGABEBEDINGUNGEN
19
unterschiedliche Ereignisse zu verknüpfen. Man spricht hier von zusammengesetzten Ereignissen.
Registriert das DBMS ein spezifiziertes Ereignis, wird der Trigger gefeuert. Anschließend wird die Bedingungsregel (cond clause) ausgewertet. Gibt sie ein true
zurück, wird die eigentliche Aktion action clause ausgeführt. Als Operationen sind
beliebige DDL-/DML-Konstrukte oder auch der Aufruf einer in der Datenbank
gespeicherten Prozedur (stored procedures) möglich.
Stored Procedures
Stored Procedures sind Programme, die direkt im Kernel des DBMS aufgeführt
werden. Man spricht hierbei von serverseitiger Programmierung. Das DBMS der
Firma Oracle unterstützt seit Version 8i neben PL/SQL auch Java-Programme als
gespeicherte Prozeduren [BS02]. Dazu wird der Bytecode in die Datenbank geladen
und kann anschließend durch die im Kernel der Datenbank integrierte Java Virtual
Machine (JVM) ausgeführt werden. Die Klassen des Java Development Kit (JDK)
liegen in einer nativ kompilierten Version vor, was eine Geschwindigkeitssteigerung
in der Ausführung der gespeicherten Prozeduren zur Folge hat.
Durch die Verwendung von Java ist es möglich, komplexere Vorgänge, im speziellen Fall Integritätsbedingungen, im DBMS abzubilden und zu integrieren. Wurden
Integritätsregeln in einem externen Java-Programm implementiert, können diese
mit wenigen Anpassungen in die Datenbank verlagert werden. Die Ausführung von
Programmen in der serverseitigen JVM bringt aber auch Nachteile. Zunächst muss
der Einstiegspunkt der gespeicherten Java-Prozedur eine statische Methode sein.
Nur statische Attribute und Methoden von Klassen können im Data Dictionary
von Oracle publiziert werden. Des Weiteren ist es nicht möglich, Instanzen von
GUI-Objekten zu erzeugen, was aber angesichts der fehlenden graphischen Ausgabemöglichkeiten des Datenbank-Kern nicht notwendig ist.
Die größte Einschränkung ist die fehlende Unterstützung für Multithreading.
Es ist prinzipiell möglich, Programme mit mehreren Threads zu implementieren.
Vorhandener Quellcode muss nicht verändert werden. Die Threads laufen im Kernel des DBMS nacheinander ab, im Gegensatz zum gleichzeitigen Ablauf in einer
normalen JVM. Man sagt dazu auch präemptives Multithreading. Benötigt ein
Thread den Prozessor für sich alleine, werden alle anderen Threads für diese Zeit
blockiert. Es ist sinnvoll auf Threads zu verzichten, da kein Performancegewinn
durch Multithreading zu erwarten ist.
Nachdem alle nötigen Mechanismen des DBMS vorgestellt wurden, beschäftigt
sich der nächste Abschnitt mit der Modellierung, Speicherung und Überprüfung
der eigentlichen Ausgabebedingungen.
2.5
Modellierung von Ausgabebedingungen
Um Ausgabebedingungen auf ihre Konsistenz zu prüfen, muss als erstes eine geeignete Form zur Beschreibung der funktionalen Zusammenhänge gefunden werden.
Es existieren bereits diverse Möglichkeiten, zeitliche oder räumliche Abfolgen von
Medienobjekten zu definieren. Die Synchronized Multimedia Integration Language,
kurz SMIL ([Roi98], [HL01], [Mi05]), ermöglicht eine allgemeine Definition die Dokumentenstruktur für Mediendaten. Es kann für die Positionierung, Synchronisation und Präsentation von Medoenobjekten genutzt werden. Der RealPlayer der
Inv.-Nr.: 2005-05-23/052/IN98/2254
20
KAPITEL 2. GRUNDLAGEN UND RELATED WORK
Firma RealNetworks oder Quicktime von Apple unterstützen zum Beispiel dieses
Format.
In [Ra04] werden bestehende Beschreibungsmöglichkeiten bewertet und eine
neue Form zur Beschreibung von Ausgabebedingungen in einer Multimedia-Datenbank konzipiert. Als Ergebnis wird eine Kombination von Allen-Relationen und
Difference Constraints vorgeschlagen, um auf einfache und verständliche Art
räumliche und zeitliche Bedingungen zu definieren. In den Abschnitten 2.5.1 und
2.5.2 werden die Grundlagen der Allen-Relationen und Difference Constraints vorgestellt. Durch die Transformation der Allen - Relationen in Difference Constraints
ist ein Konsistenzcheck auf gund eines Constraint Graphen mittels des Algorithmus von Bellman und Ford (Abschnitt 2.5.3) möglich, also die Überprüfung
der Ausgabebedingungen.
[He04] nutzt die Ergebnisse von [Ra04] und definiert eine Schnittstelle, die es
dem Nutzer ermöglicht, aus einer Auswahl von Allen Relationen räumliche und
zeitliche Bedingungen zu definieren.
Aufbauend auf diesem Artikel ist im Rahmen einer Studienarbeit das Programm ConstraintManager entstanden [Ha04], welches Ausgabebedingungen aus
einer XML-Datei ausliest, auf Konsistenz prüft und in der Datenbank speichert.
Die in diesem Programm definierten Tabellenstrukturen und Klassen werden in der
vorliegenden Arbeit verwendet und erweitert.
Die folgenden Abschnitte beschreiben die Transformation der Bedingungen, von
der Formulierung bis zur Speicherung in der Datenbank. Der eigentliche Konistenzcheck erfolgt zunächst durch ein externes Programm. Die Integritätsicherung
entspricht der in Abschnitt 2.3.1 vorgestellten Architektur. Anschließend wird der
Konsistenzcheck in das DBMS in Form eines Integritätsmonitors (vgl. Abschnitt
2.3.2) implementiert und hinsichtlich der Effizienz und praktischem Nutzen bewertet (Kapitel 6).
2.5.1
Allen-Relationen
Allen-Relationen [Al83] sind Konstrukte, mit denen feste Zeitintervalle (Objekte
mit einer definierten Dauer) zeitlich angeordnet werden können. Der große Vorteil
gegenüber anderen Beschreibungsmöglichkeiten (siehe nächster Abschnitt) liegt in
der einfachen Verständlichkeit für den Nutzer. Viele andere Modelle bauen auf
den Allen-Relationen auf, um eine zeitliche Strukturierung zu realisieren [DK95].
Nachteilig ist, dass keine funktionalen Zusammenhänge definiert werden können.
Eine Allen-Relation kann zum Beispiel lauten: A before B. Es kann nicht definiert werden, wie viele Zeiteinheiten A vor B kommen soll. Durch Veränderung der
Intervalle von A und B kann die Relation in ein meets, overlaps oder finishes-invers
verwandelt werden. Das ist hinsichtlich der Verständlichkeit beim Nutzer ein weiterer Nachteil. Welche Allen-Relationen es gibt und was sie im einzelnen bedeuten,
ist in [Ra04] ausführlich beschrieben.
Die Überprüfung der Konsistenz von Allen-Relationen erweist sich ebenfalls
als schwierig. Sie ist nur mit erheblichen Aufwand durchzuführen, da es sich um
ein NP-vollständiges Problem handelt. Durch diese Einschränkung sind die AllenRelationen zunächst nicht für die Beschreibung von Ausgabebedingungen brauchbar.
Inv.-Nr.: 2005-05-23/052/IN98/2254
2.5. MODELLIERUNG VON AUSGABEBEDINGUNGEN
2.5.2
21
Difference Constraints
Die Nachteile der Allen-Relationen sind bei Difference Constraints nicht vorhanden
([CLS00],[CPS96]). Mit ihnen ist es möglich, sowohl zeitliche als auch räumliche Zusammenhänge zwischen Objekten zu definieren. Dieser Vorteil lässt sich nutzen, da
Allen-Relationen in Difference Constraints transformiert werden können. Folgender
Difference Constraint entspricht der Allen-Relation A before B:
end(A) − st(B) ≤ c1 ,
c1 < 0.
Die Konstante c1 beschreibt den zeitlichen Mindestabstand zwischen den Endzeitpunkt von Objekt A und dem Startzeitpunkt von Objekt B. Es ist auch möglich,
außer Mindestabständen variable oder feste Intervalle zwischen zwei Objekten zu
definieren.
Neben den zeitlichen Bedingungen gibt es zusätzlich noch einen Duration-Constraint, welcher die Dauer eines Medienobjektes definiert:
end(O) − st(O) ≤ cDauer ,
st(O) − end(O) ≤ −cDauer , cDauer > 0
und diverse Constraints zur räumlichen Anordnung von Objekten. Eine Übersicht ist [Ra04] zu entnehmen.
Die Menge aller Bedingungen wird als ein System von Difference Constraints <
V,C > bezeichnet. Die Konsistenzprüfung dieses Systems mit Hilfe des Algorithmus
von Bellman und Ford wird im folgenden Abschnitt beschrieben.
Difference Constraints stellen eine Möglichkeit dar, alle gewünschten Informationen und Forderungen als Ausgabebedingungen abzubilden. Sie sind aber für
den Nutzer schwer verständlich. Das Manko der fehlenden funktionalen Zusammenhänge von Allen-Relationen wird in [He04] durch Erweiterung der Relationen
mit Parametern gelöst. Bei der Umwandlung der Allen - Relationen in Difference
Constraints bilden diese Parameter die Konstanten der einzelnen Ungleichungen.
Auf diese Art und Weise wird dem Nutzer eine Lösung zur Verfügung gestellt, die
sowohl leicht verständlich ist, als auch alle gewünschten Anforderungen zur Definition von Ausgabebedingungen erfüllt. Eine Übersicht der zur Verfügung stehenden
erweiteretn Allen-Relationen befindet sich im Anhang A.1.
2.5.3
Bellman und Ford
Die effiziente Überprüfung der Bedingungen (Konsistenzcheck) stellt das Hauptproblem der Thematik dar. Zunächst müssen die Difference Constraints, welche
die Ausgabebedingungen repräsentieren, in eine geeignete Form transformiert werden. Aus der Menge der Difference Constraints wird ein gerichteter und gewichteter
Graph gebildet, der die Bedingungen repräsentiert und auf Konsistenz geprüft werden kann.
Der Vorgang der Konsistenzprüfung lässt sich auf die Suche nach kürzesten
Wegen in gerichteten Graphen von einem Knoten aus reduzieren. Kann von einem
definierten (Start-) Knoten aus zu jedem anderen Knoten im Graphen ein kürzester
Weg gefunden werden, ist der Graph konsistent. Lässt sich kein kürzester Weg zu
diesem Knoten bestimmen, existiert ein negativer Zyklus auf dem Weg zu diesem
Knoten. Dieser Zyklus wird bei der Suche nach demm kürzesten Pfad immer wieder
durchlaufen, so dass es einen immer noch kürzeren Weg gibt. Das bedeutet eine
Inv.-Nr.: 2005-05-23/052/IN98/2254
22
KAPITEL 2. GRUNDLAGEN UND RELATED WORK
Inkonsistenz. Die Konsistenz des Graphen ist also direkt davon abhängig, ob ein
negativer Zyklus von einem Startknoten existiert, bzw. ob sich die kürzesten Wege
bestimmen lassen. Die Weglängen sind gleichzeitig Grundlage zur Berechnung der
Ausgabezeiten.
Zur Berechnung von kürzesten Pfaden in gerichteten Graphen von einem Knoten aus existieren diverse Algorithmen. Einer der bekanntesten
Algorithmen ist von
2
Dijkstra [Di59]. Er hat eine Zeitschranke von O |V | und ist für Graphen mit positiven Kantengewichten definiert (vgl. [Br94]). Die aus den Difference Constraints
erstellten Graphen besitzen aber auch negative Kantengewichte, für die der Algorithmus von Dijkstra nicht verwendet werden kann. Aus diesem Grund muss auf
den Algorithmus von Bellman und Ford [Be59] zurückgegriffen werden. Er ist für
gerichtete Graphen mit negativen Kantengewichten definiert, hat aber im Vergleich
zu Dijkstra die schlechtere Zeitschranke O (|V | · |E|).
Die Vorgehensweise der Umwandlung der Difference Constraints wurde schon
in [Ra04] beschrieben, wird hier aber noch einmal erwähnt, da sie eine zentrale
Rolle beim Konsistenzcheck einnimmt.
Die Menge der Difference Constraints wird als System von Difference Constraints < V,C > bezeichnet. Es besteht aus einer Menge V von Variablen und einer
Menge C von linearen Ungleichungen der Form:
xi − xj ≤ ck , 1 ≤ i, j ≤ n, 1 ≤ k ≤ m,
xi , xj ∈ V, ck = const.
(2.1)
Zur Überprüfung der Bedingungen mittels Bellman und Ford wird ein Constraint Graph erstellt. Jede Ungleichung wird durch je 2 Knoten (die Unbekannten)
repräsentiert, welche durch eine gerichtete und gewichtete Kante verbunden sind.
Das Gewicht der Kante entspricht dem Wert der Konstante ck . Der entsprechende
Constraint Graph ist ein gerichteter und gewichteter Graph G =< V, E >:
V = {v0 , v1 , v2 , ..., vn } ,
E = {(vj , vi ) : xi − xj ≤ ck } ∪ {(v0 , v1 ), (v0 , v2 ), ..., (v0 , vn )} ,
Kantengewichte : w(vj , vi ) = ck , i, j 6= 0, w(v0 , vi ) = 0, n < 0.
(2.2)
Der Graph kann je nach Zusammensetzung der Bedingungen ein zusammenhängender Graph sein oder aus Teilgraphen bestehen. Durch das Hinzufügen des
Startknotens v0 und den von ihm ausgehenden Kanten zu jedem anderen Knoten
wird sichergestellt, dass alle Knoten erreichbar sind und somit ein zusammenhängender Graph existiert.
Der Algorithmus von Bellman und Ford berechnet die kürzesten Pfade von einem definierten Startknoten zu jedem anderen Knoten im Graphen, falls dieser
erreichbar ist. Im Falle eines negativen Zyklus würde es immer einen noch kürzeren
Weg geben. In diesem Fall bricht der Algorithmus ab und liefert ein f alse zurück.
Die Bedingungen hätten somit den Konsistenzcheck nicht bestanden. Gibt der Algorithmus ein true aus, ist das System von Difference Constraints konsistent und
der Schedule kann anhand der kürzesten Pfade berechnet werden. Die Berechnung
der Ausgabezeiten wird in Kapitel 5 erläutert.
Die Zeitschranke O (|V | · |E|) des Algorithmus von Bellman und Ford ist abhängig von der Komplexität des Graphen. Je mehr Kanten und Knoten der Graph
besitzt, um so aufwendiger und kostenintensiver ist der Konsistenzcheck. Durch die
Inv.-Nr.: 2005-05-23/052/IN98/2254
2.5. MODELLIERUNG VON AUSGABEBEDINGUNGEN
23
expotentielle Laufzeit kann man sich sehr leicht beim Aufwand verschätzen. Um
ein Beispiel zu nennen: Ein PC mit 3 GHz benötigt für einen kompletten Check
eines Graphen mit 2000 Knoten und ca. 6000 Kanten ca. 19 Minuten. Für diesen Test wird die Testschleife des Algorithmus etwa 12 Millionen mal durchlaufen.
Der selbe PC braucht für einen Graphen mit 10.000 Knoten und 30000 Kanten
(Faktor 5) jedoch 101 Stunden (Faktor 300). Dies entspricht ca. 300 Milliarden
Schleifendurchläufe. Ein Konsistenzcheck muss bei jeder einzelnen Änderung einer
Bedingung durchgeführt werden. Dies ist bei großen Graphen nicht praktikabel.
Mit der Optimierung des Konsistenzcheck mittels Bellman und Ford beschäftigt sich das nächste Kapitel. Dort werden auch Beispiele für Constraint Graphen
aufgeführt.
2.5.4
Eingabe der Bedingungen - Der Constraint Manager
Nachdem gezeigt wurde, dass sich Difference Constraints zur Beschreibung von
räumlichen und zeitlichen Bedingungen eignen, müssen diese in eine Datenbank
eingegeben werden. Da sie nicht so leicht verständlich sind wie Allen-Relationen
ist es sinnvoll, dem Nutzer eine einfachere Möglichkeit zur Verfügung zu stellen.
Wie schon erwähnt, wurden in [He04] Vorschläge gemacht und eine Auswahl an
erweiterten Allen-Relationen für die Definition von Bedingungen zur Verfügung
gestellt.
Hauptsächlich auf diese Quelle aufbauend ist im Rahmen einer Studienarbeit
([Ha04]) das Programm ConstraintManager entstanden. Die Bedingungen werden
als Datei im XML-Format zur Verfügung gestellt. Sie beinhaltet alle zu einem
Projekt gehörenden erweiterten Allen Relationen und Duration Constraints.
Diese Form der Dateneingabe ist nicht sehr benutzerfreundlich. Wünschenswert
wäre ein Programm, in dem der Nutzer die Ausgabebedingungen über eine graphische Benutzeroberfläche erstellen kann und anschließend die XML-Datei automatisch generiert wird. Für Testzwecke ist der ConstraintManager aber ausreichend,
da nicht jeder einzelne Difference Constraint mühsam erstellt und von Hand“ in
”
die Datenbank eingegeben werden muss. Die XML-Dateien der in im Kapitel 6
vorgestellten Beispielprojekte wurden automatisch generiert.
Der ConstraintManager liest die Daten aus einer XML - Datei ein, konvertiert
sie in Difference Constraints und erstellt daraus einen Constraint Graph. Nach
erfolgreichem Konsistenzcheck mittels Bellman und Ford werden der Graph und
Informationen über die verwendeten Difference Constraints in einer Datenbank
gespeichert.
Die Speicherung erfolgt in zwei Tabellen (Tabellen 2.1 und 2.2). In Constraint Graphs wird der Constraint Graph gespeichert. Dazu werden alle Kanten
des Graphen mit Start-, Endknoten und Kantengewicht abgelegt. Eine Zeile entspricht einer Kante bzw. einem Difference Constraints. Aus den drei Einzeldaten
einer Kante (Start-, Endknoten und Kantengewicht) kann man durch Vertauschen
der Werte für Start- und Endknoten den entsprechenden Difference Constraint generieren und umgekehrt.
Definiert man die Relation A before(2) B, ergibt sich daraus folgender Difference
Constraint:
end(A) − st(B) ≤ −2
(2.3)
Jede Ungleichung entspricht einer Kante im Graphen. Die Knoten ergeben sich
Inv.-Nr.: 2005-05-23/052/IN98/2254
24
KAPITEL 2. GRUNDLAGEN UND RELATED WORK
Spaltenname
ID
Projekt
Startknoten
Endknoten
Gewicht
C ID
Bedeutung
Lfd. Nummer aller Kanten des Projektgraphen
Projektname
Startknoten der Kante
Endknoten der Kante
Gewicht der Kante
Nummer der Constraints
Tabelle 2.1: Tabelle Constraint Graphs
Spaltenname
ID
Projekt
C ID
Vorgaenger
Nachfolger
R ID
Bedeutung
Lfd. Nummer aller Constraints des Projektes
Projektname
Nummer der Constraints
Endknoten der Kante
Gewicht der Kante
Typ des Constraints
Tabelle 2.2: Tabelle Constraint Orders
implizit daraus. Die beim Parsen der XML-Datei enstandenen Difference Constraints (Ungleichungen) werden in SQL-Befehle konvertiert und somit in der Datenbank gespeichert. Die aus der Ungleichung 2.3 entstandene resultierende Kante
ist in Tabelle 2.3 zu sehen.
Für den klassischen Konsistenzcheck und die Berechnung des Ausgabeschedule reichen die gespeicherten Daten in der Tabelle Constraint Graphs aus. Für die
Optimierungen, welche in den folgenden Kapiteln beschrieben werden, sind aber zusätzliche Informationen notwendig. Die Tabelle Constraint Orders beinhaltet den
Typ und die beiden in Beziehung stehenden Objekte jedes Constraints. Der entsprechende Eintrag in der Tabelle zur before - Relation ist in Tabelle 2.4 dargestellt.
Inv.-Nr.: 2005-05-23/052/IN98/2254
2.5. MODELLIERUNG VON AUSGABEBEDINGUNGEN
ID
1
Projekt
Bsp1
Startknoten
st(B)
Endknoten
end(A)
Gewicht
-2
25
C ID
1
Tabelle 2.3: Beispiel Tabelleneintrag Constraint Graphs
ID
1
Projekt
Bsp1
C ID
1
Vorgaenger
A
Nachfolger
B
R ID
5
Tabelle 2.4: Beispiel Tabelleneintrag Constraint Orders
Inv.-Nr.: 2005-05-23/052/IN98/2254
26
KAPITEL 2. GRUNDLAGEN UND RELATED WORK
Inv.-Nr.: 2005-05-23/052/IN98/2254
Kapitel 3
Überprüfung mit Bellman Ford
Dieses Kapitel beschäftigt sich mit der Überprüfung von Ausgabebedingungen anhand eines Constraint Graphen durch den Algorithmus von Bellman-Ford. Ziel ist
es, den Konsistenzcheck anhand des Constraint Graphen so effektiv wie möglich
zu gestalten. Eine Optimierung ist erforderlich, da der Algorithmus von Bellman Ford eine Laufzeit von O(n ∗ m) besitzt. Die Testzeiten betragen bei sehr großen
Projekten mehrere Minuten bis Tage und sind somit nicht für den praktischen Gebrauch geeignet. Mit Hilfe von Optimierungen soll es möglich sein, auch größere
Projekte in einer vertretbaren Zeit auf Konsistenz zu überprüfen.
3.1
Beschränkungen und Beispiele
Der Konsistenzcheck ist gleichbedeutend mit der Suche nach negativen Zyklen.
Zur effizienteren Überprüfung sind einige Einschränkungen in der Graphstruktur
notwendig.
Negative Zyklen können auf zwei Arten entstehen. Zum einen gibt es lokale
negative Zyklen, die zwischen den Knoten zweier benachbarter Medienobjekten
existieren, falls die verknüpfende Bedingung nicht erfüllt ist. Zum anderen sind
auch globale negative Zyklen möglich. Sie können entstehen, wenn mehrere Objekte
transitiv miteinander in Beziehung stehen, zum Beispiel das erste und letzte Objekt
eines Projektes.
Die Problematik soll anhand eines Beispielprojektes verdeutlicht werden. Es
besteht aus vier Medienobjekten mit einer definierten Dauer (Tabelle 3.1) und drei
Allen-Relationen (Tabelle 3.2). Zum besseren Verständnis und Überblick über das
Beispielprojekt wird der Beziehungsgraph eingeführt.
Der Beziehungsgraph basiert auf den Allen-Relationen. Jedes Medienobjekt
wird durch einen Knoten repräsentiert und jede Allen-Relation durch eine gerichtete
Kante zwischen den betreffenden Objekten bzw. Knoten. Die Duration-Constraints
spielen im Beziehungsgraph keine Rolle, da sie keine Beziehungen zwischen Objekten abbilden. Der Startknoten v0 1 ist notwendig, ähnlich wie beim Constraint
1 Ein Startobjekt bzw. -knoten v existiert sowohl im Beziehungs- als auch im Constraint Gra0
phen und hat durch die ausgehenden Kanten die Aufgabe, einen zusammenhängenden Graphen
zu bilden.
Inv.-Nr.: 2005-05-23/052/IN98/2254
28
KAPITEL 3. ÜBERPRÜFUNG MIT BELLMAN - FORD
Objekt
o1
o2
o3
o4
Dauer
15
25
20
10
Bedingung
o1 duration(15)
o2 duration(25)
o3 duration(20)
o3 duration(10)
Tabelle 3.1: Beispielprojekt: Objektdauer
Bezeichnung
AR1
AR2
AR3
Allen - Relation
o1 before(2) o2
o2 overlaps(3,5) o3
o3 before(5) o4
Tabelle 3.2: Beispielprojekt: Allen-Relationen mit Parametern
Graphen, um einen zusammenhängenden Graphen zu bilden.
Die Abbildungen 3.1 und 3.2 zeigen den Beziehungsgraph bzw. den zugehörigen
Constraint Graph, die aus den Bedingungen des Beispielprojektes erzeugt wurden.
In diesem Beispiel sind nur lokale negative Zyklen möglich, denn es existieren
nur Beziehungen zwischen direkt benachbarten Objekten (siehe Beziehungsgraph).
Fügt man eine vierte Allen-Relation AR4 hinzu, zum Beispiel o1 before(20) o3 ,
wäre eine Kante zwischen den Objekten o1 und o3 (Abbildung 3.3, gestrichelte
Kante) und ein globaler negativer Zyklus grundsätzlich denkbar.
Beschränkt man die Erstellung von Bedingungen, können globale Zyklen von
Anfang an verhindert werden. Dies ist ein wichtiger Punkt zur Optimierung des
Konsistenzchecks. Folgende Regeln für den Beziehungsgraphen bzw. die Projektdefinition sind notwendig:
• es existiert genau ein Startobjekt v0 mit der Dauer t = 0 ohne Vorgänger
• alle Medienobjekte haben genau einen Vorgänger und beliebig viele Nachfolger
• alle Medienobjekte haben eine definierte Dauer t ≥ 0
Bei einem Blick auf diese Einschränkungen wird klar, dass es sich beim Beziehungsgraphen um einen Baum mit v0 als Wurzel handeln muss. Dank dieser Vorgabe können keine globale Zyklen entstehen und der Konsistenzcheck kann auf das
Suchen von lokalen negativen Zyklen beschränkt werden. Die nächsten Abschnitte
beziehen sich ausschließlich auf lokale negative Zyklen.
Die Forderung nach einer fest definierten Intervalldauer der Medienobjekte ist
nicht zwingend notwendig. Grundsätzlich lassen sich, analog zu Allen-Relationen,
auch variable Intervalle definieren. Aus Sicht der Optimierungen würde dies den
Konsistenzcheck aber erschweren und keinen zusätzlichen Erkenntnisgewinn bringen.
v0
o1
AR1
o2
AR2
o3
AR3
o4
Abbildung 3.1: Beziehungsgraph
Inv.-Nr.: 2005-05-23/052/IN98/2254
3.1. BESCHRÄNKUNGEN UND BEISPIELE
0
0
end(o1)
29
0
end(o2)
end(o4)
end(o3)
-5
0
v0
15
-15
25
-2
-1
-25
20
-20
-5
10
-10
0
-3
st(o1)
0
st(o2)
0
st(o4)
st(o3)
0
Abbildung 3.2: Constraint Graph
v0
o1
AR1
o2
AR2
o3
AR3
AR4
Abbildung 3.3: Beziehungsgraph mit globalem Zyklus
Inv.-Nr.: 2005-05-23/052/IN98/2254
o4
30
KAPITEL 3. ÜBERPRÜFUNG MIT BELLMAN - FORD
ID
1
2
3
4
5
6
7
8
9
10
11
12
13
Projekt
Bsp1
Bsp1
Bsp1
Bsp1
Bsp1
Bsp1
Bsp1
Bsp1
Bsp1
Bsp1
Bsp1
Bsp1
Bsp1
Startknoten
st(o1 )
end(o1 )
st(o2 )
end(o2 )
st(o3 )
end(o3 )
st(o4 )
end(o4 )
st(o2 )
end(o3 )
st(o3 )
end(o2 )
st(o4 )
Endknoten
end(o1 )
st(o1 )
end(o2 )
st(o2 )
end(o3 )
st(o3 )
end(o4 )
st(o4 )
end(o1 )
end(o2 )
st(o2 )
st(o3 )
end(o3 )
Gewicht
15
-15
25
-25
20
-20
10
-10
-2
-5
-3
-1
-5
C ID
1
1
2
2
3
3
4
4
5
6
6
6
7
Tabelle 3.3: Komplette Constraint Graphs - Tabelle für Beispielprojekt
ID
1
2
3
4
5
6
7
Projekt
Bsp1
Bsp1
Bsp1
Bsp1
Bsp1
Bsp1
Bsp1
C ID
1
2
3
4
5
6
7
Vorgaenger
o1
o2
o3
o4
o1
o2
o3
Nachfolger
o2
o3
o4
R ID
1
1
1
1
5
7
5
Tabelle 3.4: Komplette Constraint Orders - Tabelle für Beispielprojekt
Die Einschränkungen zur Definition von Projekten bzw. des Beziehungsgraphen
erscheinen zunächst gravierend. Die Möglichkeit jedes Objekt mit einem beliebig
anderen in Beziehung zu setzen und somit keine Beschränkungen vorzugeben, ist
aus Sicht des Nutzers zunächst sinnvoll und erwünscht. Für den logischen Aufbau ist aber es besser, nur direkt nachfolgende Objekte zu verknüpfen. Andernfalls
können in größeren Projekten unübersichtliche Strukturen entstehen, die bei Änderungen negative Zyklen wahrscheinlicher machen. Die Problematik der Szenenbeschreibung zur Wellenfeldsynthese können mit diesen Einschränkungen problemlos
erfüllt werden.
Das Beispielprojekt wird als XML-Datei erzeugt und mit Hilfe des ConstraintManager in der Datenbank gespeichert. Die entsprechenden Tabellen Constraint
Graphs und Constraint Orders sind in 3.3 und 3.4 zu sehen. Die Tabelle Constraint Orders dient hauptsächlich zur Erstellung des Beziehungsgraphen, bzw. um
Zusammenhänge zwischen den Relationen zu extrahieren und um den Typ einer
Relation festzustellen.
3.2
Klassifizierung der Allen-Relationen
Eine Klassifizierung der Allen-Relationen ist sinnvoll, da nicht aus jeder Relation
ein negativer Zyklus hervorgehen kann. Alle Allen-Relationen haben als Graph das
selbe Grundgerüst (Abbildung 3.4). Zu einem Medienobjekt (v1 bzw. v2 ) im Bezie-
Inv.-Nr.: 2005-05-23/052/IN98/2254
3.2. KLASSIFIZIERUNG DER ALLEN-RELATIONEN
31
hungsgraph existieren je zwei Knoten im Constraint Graph: der Start- (v11 bzw.
v21 ) und Endknoten (v12 bzw. v22 ). In allen Abbildungen sind sie jeweils untereinander dargestellt, um die Zugehörigkeit zu verdeutlichen. Wird im Folgenden
von den Knoten eines Objektes (v1 ) im (Constraint) Graphen gesprochen, sind die
zugehörigen Start- und Endknoten (v11 und v12 ) gemeint.
Es wird stets davon ausgegangen, dass die Allen-Relationen sowohl korrekt erzeugt als auch korrekt in Difference Constraints transformiert wurden. Insbesonders bei erweiterten Allen-Relationen sind nur nichtnegative Werte als Parameter
erlaubt. Mit Hilfe der Parameter wird ein festes oder variables Intervall [a,b] mit
a ≤ b zwischen zwei Zeitpunkten definiert. Verwendet man negative Werte, würde
ein Intervall [a,b] mit a > b generiert und hätte eine Inkonsistenz bzw. negativen Zyklus zur Folge. Werden die Bedingungen falsch modelliert oder fehlerhaft
in Difference Constraints umgewandelt, können theoretisch an vielen Stellen negative Zyklen entstehen, z. B. durch die beiden Kanten zwischen v11 und v21 . Am
Ende dieses Abschnittes wird ein Beispiel eines negativen Zyklus durch eine unerlaubte Definition einer Relation gezeigt. Durch Ausschließen solcher Fehlerquellen
lässt sich die Anzahl potentieller negativer Zyklen stark reduzieren. Im Folgenden
werden nur solche negative Zyklen betrachtet, die allein durch Inkonsistenzen der
Bedingungen entstehen, also potentiell negative Zyklen.
Zwischen den Start- und Endknoten eines Objektes existieren je zwei Kanten,
welche die Dauer t der Objekte repräsentieren (Abbildung 3.4, durchgezogene Kanten). Diese Kanten können bei korrekter Modellierung der Allen-Relationen und
Transformation in Difference Constraints alleine keinen negativen Zyklus bilden.
Sie heben sich gegenseitig auf, da eine fest definierte Dauer der Objekte gefordert
ist. Im Falle eines negativen Zyklus sind sie aber zwingend an diesem beteiligt.
Die Kanten zwischen den Knoten der jeweiligen Objekte (Abbildung 3.4, gestrichelte Kanten), resultierend aus den Difference Constraints, sind essentiell für eine
Inkonsistenz. Abhängig von der Relation können eine oder mehrere dieser Kanten in
Teilgraphen vorkommen. Der Startknoten v0 muss in diesem Zusammenhang nicht
betrachtet werden. Da seine ausgehenden Kanten jeweils das Gewicht Null haben,
spielen sie bei der Suche nach negativen Zyklen innerhalb einer Allen-Relation keine
Rolle.
Der Graph G =< V, E > einer Allen-Relation (vgl. Gleichung 2.1) mit den zwei
verknüpften Objekten lässt sich allgemein wie folgt beschreiben:
V = V1 ∪ V2 , V1 = {v11 , v12 } , V2 = {v21 , v22 } ,
E = E1 ∪ E2 ,
E1 = {(v11 , v12 ), (v12 , v11 ), (v21 , v22 ), (v22 , v21 )} ,
E2 = {(vkl , vij ) : xij − xkl ≤ ck } ∩ E1 ,
Kantengewichte : w(vkl , vij ) = ck , i, j, k, l 6= 0.
(3.1)
Die Menge der Knoten setzt sich aus den beiden Untermengen der jeweils zwei
Objektknoten zusammen. Die Menge E1 repräsentiert die Kanten zwischen den
jeweiligen Knoten der Mengen V1 und V2 , welche die Objektdauer angeben (Abbildung 3.4, durchgezogene Kanten). Die restlichen Kanten der Menge E2 verlaufen
zwischen den Objektknoten (Abbildung 3.4, gestrichelte Kanten). Wie bereits erwähnt, sind die Knoten der Menge E1 zunächst neutral hinsichtlich der Entstehung
eines Kreises. Die notwendige Bedingung für einen potentiellen negativen Zyklus
Inv.-Nr.: 2005-05-23/052/IN98/2254
32
KAPITEL 3. ÜBERPRÜFUNG MIT BELLMAN - FORD
v12
t1
-t1
v11
v22
t2
-t2
v21
Abbildung 3.4: Vollvermaschter Graph mit vier Knoten
lautet:
∃k1 ∈ V1 :∃k2 ∈ V2 : (k1 , k2 ) ∩ E2 6= ∅ ∧ (k2 , k1 ) ∩ E2 6= ∅
(3.2)
Ein zu überprüfender Zyklus entsteht immer zwischen den Knoten der Mengen
V1 und V2 , zwischen den Knotenmengen beider Objekte. Also muss die Menge
E2 mindestens zwei Kanten enthalten, die entgegen gerichtet sind ((k1 , k2 ) und
(k2 , k1 )). Sind diese Bedingungen erfüllt, ist ein negativer Zyklus grundsätzlich
möglich. Durch Summierung der Kantengewichte kann numerisch bestimmt werden,
ob ein Kreis negativ ist oder nicht.
Die theoretisch vorkommenden Kanten sind im vollvermaschten Graphen sind
in Abbildung 3.4 zu sehen. Da die Menge der zugrunde liegenden Allen-Relationen
aber begrenzt ist, werden nicht alle Kanten in der Praxis vorkommen. Die Kanten
zwischen v11 und v22 sind daher theoretischer Natur. Abbildung 3.5 zeigt die Kanten, die aus den zugrunde liegenden Relationen resultieren. Anhand dieser Kanten
lassen sich alle Zyklen identifizieren, die durch Inkonsistenzen der Bedingungen
negativ werden können:
z1
z2
z3
z4
z5
z6
: (v11 , v21 ), (v21 , v22 ), (v22 , v12 ), (v12 , v11 ),
: (v11 , v12 ), (v12 , v22 ), (v22 , v21 ), (v21 , v11 ),
: (v21 , v22 ), (v22 , v12 ), (v12 , v21 ),
: (v21 , v11 ), (v11 , v12 ), (v12 , v21 ),
: (v21 , v12 ), (v12 , v22 ), (v22 , v21 ),
: (v21 , v12 ),(v12 , v11 ), (v11 , v21 ).
(3.3)
Inv.-Nr.: 2005-05-23/052/IN98/2254
3.2. KLASSIFIZIERUNG DER ALLEN-RELATIONEN
v12
t1
-t1
v11
33
v22
t2
-t2
v21
Abbildung 3.5: Grundgerüst aller verwendeten Allen - Relationen
Sichere Allen - Relationen
A before B
A meets B
Unsichere Allen - Relationen
A overlaps B
A finishes B
A starts B
A during B
A equals B
Tabelle 3.5: Klassifizierung: Sichere und unsichere Allen - Relationen
Durch Summierung der Kantengewichte eines Zyklus lässt sich feststellen, ob er
negativ ist, also eine Inkonsistenz darstellt. Bellman-Ford tut dies über die Suche
nach den kürzesten Pfaden. Hier ist es nicht erforderlich, die potentiellen Zyklen
einer Allen-Relation vorher zu identifizieren.
Anhand der Kriterien für potentielle Zyklen lassen sich alle verwendeten AllenRelationen in zwei Kategorien einteilen: Erstens die sicheren Allen-Relationen ohne
potentiellen negativen Zyklus und zweitens die Unsicheren. Diese enthalten einen
Kreis zwischen Knoten unterschiedlicher Objekte, der durch die Kombination der
Bedingungen und der Dauer der Medienobjekte negativ werden kann. Tabelle 3.5
zeigt die Klassifizierung.
Im Beispielprojekt sind sowohl sichere als auch unsichere Relationen vorhanden.
Betrachtet man die before-Relation (AR1) als Teilgraph, existiert nur eine Kante
zwischen beiden Objekten (Abbildung 3.6). Ist man einmal bei Objekt o1 angelangt,
führt kein Pfad zurück zu Objekt o2 . Die Kanten der Objektdauer bilden zwar einen
Kreis, heben sich aber bei korrekter Modellierung gegenseitig auf.
Im Gegensatz dazu ist die overlaps-Relation (AR2) unsicher. Es besteht u. a.
ein potentieller Zyklus zwischen end(o3 ), end(o2 ) und st(o3 ) (Abbildung 3.7, gestrichelte Kanten), der abhängig von den Kantengewichten, negativ werden kann.
Die im Beispiel gewählten Werte führen nicht zu einem negativen Zyklus: -5 -1 +
Inv.-Nr.: 2005-05-23/052/IN98/2254
34
KAPITEL 3. ÜBERPRÜFUNG MIT BELLMAN - FORD
end(o1)
15
-15
st(o1)
end(o2)
-2
25
-25
st(o2)
Abbildung 3.6: Sichere Relation: before
20 = 16 und somit größer als 0.
Wie bereits erwähnt, kann es durch inkorrekte Erzeugung der Difference Constraints zu Inkonsistenzen kommen. Des Dadurch sind auch negative Zyklen ohne
Beteiligung der Kanten der Menge E1 möglich, was anhand der bef orev (c1 , l)Relation verdeutlicht werden sollen. Es existiert ein Zyklus zwischen den Knoten
end(o1 ) und st(o2 ) (Abbildung 3.8, gestrichelten Kanten).
Die Kantengewichte werden durch die Parameter c1 und l der Relation bestimmt. Im Normalfall sind beide Werte nichtnegativ und somit auch der Kreis:
− c1 + c1 + l = l, l ≥ 0.
Die Paramenter repräsentieren ein Intervall von [c1 ,c1 +l] mit c1 < c1 +l. Wählt
man einen negativen Wert für l, resultiert daraus ein negativer Zyklus:
− c1 + c1 + l = l, l < 0.
Das Intervall [c1 ,c1 + l] wäre mit c1 < c1 + l nicht erlaubt und stellt somit eine
Inkonsistenz dar. Da aber stets davon ausgegangen wird, dass die Erzeugung der
Constraints und die Definitionen der Intervalle korrekt sind, können solche negative
Kreise ausgeschlossen werden. Nur die Zyklen der Auflistung 3.3 sind relevant für
die Konsistenzprüfung.
3.3
Optimierungen
Ein Konsistenzcheck ist generell nur notwendig, wenn Relationen verändert oder
neu hinzugefügt werden. Existiert ein konsistenter Graph und werden Bedingungen (Kanten, Knoten) gelöscht, ist kein Check nötig. Die Bedingungen werden in
diesem Fall weicher gemacht: durch das Löschen einer Kante oder Knoten kann
kein neuer Zyklus entstehen. Im Gegensatz dazu ist aber ein Konsistenzcheck erforderlich, wenn Bedingungen hinzugefügt werden oder sich Kantengewichte ändern
Inv.-Nr.: 2005-05-23/052/IN98/2254
3.3. OPTIMIERUNGEN
35
end(o2)
end(o3)
-5
25
-1
-25
20
-20
-3
st(o2)
st(o3)
Abbildung 3.7: Unsichere Relation: overlaps
end(o1)
15
-15
end(o2)
-c1
st(o1)
c1+l
25
-25
st(o2)
Abbildung 3.8: Mögliche Inkonsistenz bei beforev
Inv.-Nr.: 2005-05-23/052/IN98/2254
36
KAPITEL 3. ÜBERPRÜFUNG MIT BELLMAN - FORD
Sichere Operationen
Löschen einer Kante oder eines
Knoten
Hinzufügen einer ungefährlichen
Relation
Vergrößern eines Kantengewichtes
Unsichere Operationen
Hinzufügen einer gefährlichen
Relation
Verkleinern eines Kantengewichtes
Tabelle 3.6: Sichere und unsichere Operationen
(Änderung einer Bedingung). Im letzteren Fall spielt es aber auch eine Rolle, ob
die Gewichte vergrößert oder verkleinert werden (vgl. [Ra04]).
Analog zur der Klassifizierung der Allen-Relationen, kann man zwischen sicheren und unsicheren Operationen unterscheiden (Tabelle 3.6).
Nach der Löschung von Kanten oder Knoten bzw. einer Bedingung ist es notwendig, den Ausgabeschedule wegen möglicher veränderter Zeiten neu zu bestimmen.
In Kapitel 5 werden Berechnung und mögliche Optimierungen erläutert.
Die Änderung eines Kantengewichtes betrifft auch Änderungen der Objektdauer. Dieser Fall wird im nächsten Abschnitt betrachtet. Zunächst wird von Änderungen einzelner Allen-Relationen ausgegangen.
Der Konsistenzcheck erfolgt mit Hilfe des Algorithmus von Bellman und Ford.
Die Laufzeit dieses Tests ist, wie erwähnt, abhängig von der Anzahl der Kanten
und Knoten des zu prüfenden Constraint Graph. Zur Reduzierung der Kosten muss
der zu testende Graph verkleinert werden.
Hier erweist sich die Beschränkung des Beziehungsgraphen auf eine Baumstruktur als sehr vorteilhaft. Durch die besondere Struktur des Graphen schliesst man
das Entstehen von globalen Zyklen im Constraint Graph aus. Demzufolge sind nur
noch lokale negative Zyklen möglich. Und zwar nur an den Stellen, die seit dem
letzten Konsistenzcheck verändert wurden.
Wird eine Allen-Relation verändert, müssen nur diese Relation und die beteiligten Objekte überprüft werden. Aus diesem Grund wird ein Teilgraph auf Basis
des Constraint Graph erstellt. Der Algorithmus zur Erzeugung dieses Graphen aufgrund der Änderung einer einzelnen Bedingung ist in Abbildung 3.9 dargestellt. Der
Input des Algorithmus ist eine condition. Der Begriff ist weit gefasst. Es kann sich
um eine komplette Allen-Relation handeln, um einen einzelnen Difference Constraint als Teil einer Relation (im Falle einer Änderung) oder um einen Duration
Constraint, welcher letztendlich wieder aus zwei Difference Constraints besteht.
Zuerst wird geprüft, ob die veränderte Bedingung eine Allen-Relation (1) oder
eine Objektdauer (11) betrifft. Der Teilalgorithmus für die Änderung der Dauer
wird im Abschnitt 3.4 erläutert.
Handelt es sich um eine unsichere Allen-Relation (2) muss festgestellt werden,
ob die betreffende Relation schon im Constraint Graph vorhanden ist (3). Ist dies
der Fall und wurde ein Kantengewicht verkleinert(5), wird die komplette Relation mit den Knoten der beteiligten Objekte zum Teilgraph hinzugefügt (6). Beim
Hinzufügen der Bedingung wird ebenfalls der Teilgraph um die komplette Relation
ergänzt (8). Zum Schluss wird der Startknoten v0 hinzugefügt (19), um anschließend den Konsistenzcheck mittels Bellman und Ford zu starten.
Im Beispiel sieht das folgendermaßen aus: die Relation AR2 (o2 overlaps(3,5)
o3 ) wird geändert in o2 overlaps(5,5) o3 . Die Relation bzw. Bedingung ist schon
im Graph vorhanden, das Kantengewicht von st(o3 ) nach st(o2 ) wurde von −3 auf
−5 verkleinert. Der Teilgraph besteht demzufolge zunächst aus den vier betref-
Inv.-Nr.: 2005-05-23/052/IN98/2254
3.3. OPTIMIERUNGEN
Algorithm:
buildP artialGraph(INPUT condition, OUTPUT partialGraph)
Input:
Condition condition
Output:
Graph partialGraph
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
if condition is AllenRelation {
if condition is UnsafeRelation {
if condition is PartOfConstraintGraph {
oldCondition = getConditionFromGraph(condition.id)
if condition.value < oldCondition.value
addToPartialGraph(condition)
}
else addToPartialGraph(condition)
}
}
else if condition is Duration{
for all relations do{
if condition is related to relations {
allenRelation = relations.id
addToPartialGraph(allenRelation)
}
}
}
addToPartialGraph(startN ode)
return partialGraph
Abbildung 3.9: Algorithmus zur Teilgrapherzeugung
Inv.-Nr.: 2005-05-23/052/IN98/2254
37
38
KAPITEL 3. ÜBERPRÜFUNG MIT BELLMAN - FORD
end(o2)
0
end(o3)
-5
0
V0
25
-1
-25
20
-20
0
-5
st(o2)
st(o3)
0
Abbildung 3.10: Teilgraph nach Änderung einer Allen - Relation
fenden Knoten und Kanten. Danach wird der Startknoten v0 mit seinen Kanten
erzeugt und der Algorithmus von Bellman und Ford ausgeführt, welcher true zurück gibt. Der erzeugte Teilgraph ist in Abbildung 3.10 dargestellt. Die Kosten
für den Konsistenzcheck des Teilgraph gegenüber den gesamten Constraint Graph
sind geringer, da die Anzahl der Knoten und Kanten verkleinert wurde.
3.4
Änderung der Objektdauer
Bei der Konsistenzprüfung muss zwischen Änderungen von normalen“ Bedingun”
gen und Änderungen der Dauer unterschieden werden. Die Überprüfung lässt sich
zwar auch hier auf einen lokalen Test beschränken, aber es können in diesem Fall
mehr als zwei Medienobjekte beteiligt sein.
Allen-Relationen verknüpfen immer nur zwei Medienobjekte. Im Gegensatz dazu kann aber ein Medienobjekt in beliebig vielen Beziehungen vorkommen. Bei
Änderung der Dauer müssen alle Beziehungen, die dieses Medienobjekt betreffen,
und alle Medienobjekte, welche zu diesen Relationen gehören, getestet werden.
Erkennt der Algorithmus aus Abbildung 3.9, dass es sich bei einer geänderten
Bedingung um ein Duration Constraint handelt (11), werden alle im Constraint
Graph vorhandenen Relationen (12) überprüft, ob das geänderte Objekt beteiligt
ist (13). In diesem Fall werden alle beteiligten Relationen (14) und zugehörige
Objekte zum Teilgraphen hinzugefügt (15), ebenso der Startknoten. Der fertige
Teilgraph ist nun bereit für den Konsistenzcheck.
Erhöht man zum Beispiel die Dauer von Objekt o3 von 20 auf 30 Zeiteinheiten
(ZE), wird damit ein Kantengewicht verkleinert. Gleichzeitig muss natürlich die
positive Kante um den entsprechenden Wert erhöht werden, damit die Forderung
einer fest definierten Dauer erfüllt ist. Im Beziehungsgraphen des Beispiels (Abbildung 3.1) kann man gut erkennen, dass das Objekt o3 an den Relationen AR2 und
AR3 beteiligt ist. Also müssen die Relationen AR2 und AR3 und die involvierten
Objekte o2 , o3 und o4 für den Konsistenzcheck berücksichtigt werden. Der erzeugte
Teilgraph ist in Abbildung 3.11 zu sehen.
Inv.-Nr.: 2005-05-23/052/IN98/2254
3.4. ÄNDERUNG DER OBJEKTDAUER
39
0
end(o2)
0
end(o3)
end(o4)
-5
0
V0
25
-1
-25
30
-30
-5
10
-10
0
-3
st(o2)
st(o3)
0
st(o4)
0
Abbildung 3.11: Teilgraph nach Änderung eines Duration Constraint
v0
Abbildung 3.12: Idealer Beziehungsgraph
Auch hier ist der zu testende Graph kleiner als der ursprüngliche Constraint
Graph. Allerdings sind jetzt mehr Objekte beteiligt sind als bei einer Änderung einer Allen-Relation. Die Anzahl ist abhängig von der Art und Weise, wie die Objekte
untereinander verknüpft wurden und ist gut an der Struktur des Beziehungsgraphen erkennbar.
Für die Laufzeit des Konsistenzcheck ist es vorteilhaft, wenn alle Medienobjekte
der Reihe nach miteinander verknüpft sind. Jeder Knoten im Beziehungsgraphen
hat genau einen Vorgänger und genau einen Nachfolger (Abbildung 3.12). Bei einer
Änderung der Dauer müssten nur drei Objekte und zwei Relationen geprüft werden,
unabhängig davon, wie viele Objekte im Gesamtgraphen vorkommen.
Im Gegensatz dazu vergrößert sich der Aufwand, wenn es ein Hauptobjekt gibt,
mit dem alle anderen Medienobjekte in Beziehung stehen (Abbildung 3.13). Ändert
man die Dauer des Hauptpbjektes, wäre in diesem Worst-Case-Graph der Teilgraph
identisch mit dem Gesamtgraphen. Der Zeitaufwand wäre hier sogar noch größer,
weil der zu überprüfende Teilgraph erst gesucht und erstellt werden muss. Dieser
Fall ist in der Praxis allerdings sehr unwahrscheinlich. In der Regel wird der Beziehungsgraph einen Hauptstrang, einen Roter Faden“, besitzen, von dem aus andere
”
Teilbäume abzweigen (Abbildung 3.14).
Wendet man bei der Überprüfung der Objektdauer die Optimierungen konsequent an, kann man den Teilgraph weiter verkleinern. Der im Beispiel erstellte
Teilgraph um Objekt o3 umfasst drei Objekte: o2 , o3 und o4 . In Abschnitt 3.2 wurden alle Allen-Relationen in sichere und unsichere klassifiziert (Tabelle 3.5). Da es
sich bei der Relation zwischen o3 und o4 um eine sichere before-Relation handelt,
kann diese weggelassen werden. Der zu testende Teilgraph umfasst nur noch zwei
Objekte (o2 und o3 ) und der Test läuft entsprechend schneller ab. Dieser Optimie-
Inv.-Nr.: 2005-05-23/052/IN98/2254
40
KAPITEL 3. ÜBERPRÜFUNG MIT BELLMAN - FORD
v0
Abbildung 3.13: Worst Case Beziehungsgraph
v0
Abbildung 3.14: Beziehungsgraph mit Rotem Faden“
”
Inv.-Nr.: 2005-05-23/052/IN98/2254
3.5. REDUZIERUNG DER KANTENANZAHL
41
rungsschritt wird jedoch im Algorithmus (Abbildung 3.9) nicht berücksichtigt, da
auf diesem Weg falsche Pfade für den Ausgabeschedule berechnet werden. Es wird
davon ausgegangen, dass nach einer Überprüfung mit Bellman-Ford stets die Weglängen im gesamten Graphen angepasst werden (siehe Kapitel 5). Nutzt man den
Optimierungsschritt mit dem kleineren Teilgraph, ist der Konsistenzcheck schneller. Zur Berechnung der korrekten Pfade für den Ausgabeschedule muss jedoch der
vollständige Teilgraph überprüft werden. Das hat insgesamt eine größere Laufzeit
zur Folge.
3.5
Reduzierung der Kantenanzahl
Nachdem die zu überprüfende Knotenanzahl verkleinert werden konnte, stellt sich
jetzt die Aufgabe, die Kantenanzahl des Teilgraphen zu reduzieren. Ansatzpunkt
ist wieder der Startknoten v0 bzw. dessen ausgehende Kanten. Diese Kanten gehen
zu jedem anderen Knoten im Graphen. Da definiert wurde, dass ein Medienobjekt
nur eine Dauer t ≥ 0 haben darf, weiss man, dass die kürzesten Pfade zu den
Knoten eines Objektes immer zuerst über den Endknoten verlaufen und danach
über den Startknoten. Es kann also nie passieren, dass ein kürzester Pfad über eine
Kante vom Startknoten v0 zu einem Startknoten eines Objektes verläuft. Demzufolge kann man alle diese Kanten weglassen. Der resultierende Graph ist durch die
Kanten der Duration-Constraints noch immer zusammenhängend. Das ist eine der
Hauptaufgaben des Startknoten bzw. dessen Kanten.
Diese Optimierung kann so weit getrieben werden, bis nur noch die Kanten vom
Startknoten v0 zu den Endknoten der Objekte vorhanden sind, die zu den zuletzt
zu präsentierenden Objekten gehen, da über diese sämtliche kürzesten Pfade verlaufen. Ein Zeitgewinn ist aber hier nicht in jedem Falle zu erwarten. Die Struktur
des Projektes und die verwendeten Relationen haben wiederum direkten Einfluss
auf die Laufzeit dieser Methode. Es lassen sich zum Beispiel worst case Projekte
erstellen, bei denen keine Verbesserung der Laufzeit mit dieser Methode erreicht
wird. Besteht das Projekt nur aus Objekten, welche mit der equals - Relation verknüpft sind, dürfen keine Kanten vom Startknoten v0 weggelassen werden. Alle
Objekte werden zeitgleich präsentiert, d. h. alle kürzesten Pfade verlaufen über die
Kanten vom Startknoten v0 zum jeweiligen Endknoten aller Objekte.
Die Kanten zu den Startknoten der Objekte können aber gefahrlos weggelassen
werden. Wie viel Zeit dadurch bzw. durch die in den vorherigen Abschnitten vorgestellten Optimierungsverfahren eingespart werden kann, wird in Abschnitt 6.2.2
evaluiert.
3.6
Weitere Laufzeitoptimierungen
Bei der Erstellung des Teilgraphen und anschließenden Überprüfung durch Bellman-Ford sind weitere Optimierungen bei Sonderfällen möglich. Der Teilgraph bzw.
die Knoten- und Kantenanzahl kann noch weiter verkleinert werden. Ansatzpunkt
ist der Startknoten v0 . Er wird benötigt, um einen zusammenhängenden Graphen
zu erhalten. Nicht zusammenhängende Graphen enstehen, wenn mehrere Relationen verändert wurden, diese aber nicht direkt in Beziehung zueinander stehen.
Wird nur eine Relation verändert, kann der Startknoten v0 weggelassen werden.
Der zu testende Teilgraph besteht danach nur noch aus 4 statt 5 Knoten, von denen beliebig einer als neuer Startknoten v0 ausgewählt werden kann. Es muss ein
Inv.-Nr.: 2005-05-23/052/IN98/2254
42
KAPITEL 3. ÜBERPRÜFUNG MIT BELLMAN - FORD
Startknoten festgelegt werden, da der Algorithmus von Bellman-Ford die kürzesten Pfade zu diesem berechnet. Die berechneten Pfade dürfen aber nicht für den
Ausgabeschedule verwendet werden, weil sie nicht den kürzesten Weg im gesamten
Graph entsprechen. Dazu mehr in Kapitel 5.
Werden mehrere Relationen geändert und diese anschließend gemeinsam getestet, kann v0 weggelassen werden, wenn alle geänderten Relationen direkt oder
transitiv miteinander in Verbindung stehen, also ein zusammenhängender Teilgraph
existiert. Ob der Zeitgewinn durch Weglassen des Startknotens größer ist als der
Test auf einen zusammenhängenden Teilgraphen, muss noch nachgewiesen werden.
Auch hier dürfen die berechneten Pfade nicht für die Scheduleberechnung genutzt
werden.
3.7
Realisierung im DBMS
Die Implementierung der Konsistenzprüfung in einem DBMS entspricht der Architektur aus Abschnitt 2.3.2: Integritätssicherung durch DBMS. Werden Bedingungen in der Datenbank gespeichert, übernimmt eine im Kernel der Datenbank
gespeicherte Java-Prozedur die Überprüfung. Dies kann vollautomatisch über Trigger realisiert werden. Registriert der Trigger Veränderungen in den Tabellen, wird
das gespeicherte Projekt mit der neuen Bedingung auf Konsistenz geprüft. Ist sie
gewährleistet, werden die neuen Daten in der Datenbank dauerhaft gespeichert
und die Transaktion abgeschlossen. Wird eine Inkonsistenz festgestellt, werden die
Änderungen verworfen und der ursprünglich konsistente Zustand der Datenbank
wieder hergestellt.
Eine Bedingung besteht in der Regel aus mehreren Difference Constraints bzw.
Tabelleneinträgen. Wird z. B. eine neue overlaps-Relation in der Datenbank gespeichert, muss nicht nach jeder Insert-Operation der Trigger ausgeführt werden.
Es reicht, wenn nach der letzten Einfügeoperation ein Konsistenzcheck stattfindet.
Um die Integrität der Daten in der Datenbank zu gewährleisten, werden sämtliche
Operationen zum Speichern einer Bedingung zu einer Transaktion zusammengefasst. Wird der commit-Befehl zum Abschliessen der Transaktion an das DBMS
gesendet, wird der Trigger zur Überprüfung der Konsistenz ausführt.
Im Konzept der aktiven Datenbanksysteme sind zwei Befehle zum Festlegen des
Überprüfungszeitpunktes vorgesehen. Wird ein Trigger mit der Option immediate
erzeugt, erfolgt die Prüfung sofort bei jeder relevanten Datenbankänderung unabhängig davon, ob eine Transaktion beendet wurde oder nicht. Im Gegensatz dazu
kann die Überprüfung durch die deferred-Option (aufgeschoben) an das Ende einer
Transaktion verlagert werden. Das ist im vorliegenden Fall erwünscht.
Kommt es zum Abschluss einer Transaktion durch den commit-Befehl, überprüft der Trigger anhand der neuen Werte die Konsistenz. Im Falle einer Inkonsistenz erfolgt ein Rollback, d. h. die Änderungen werden verworfen und die ursprüngliche Konsistenz der Daten ist wieder hergestellt.
Wird der Constraint Graph bzw. das Projekt das erste Mal in der Datenbank
gespeichert, ist es sinnvoll sein, mehrere Bedingungen zu einer Transaktion zusammenzufassen. Dieser Punkt wird in Abschnitt 6.6 näher betrachtet.
Inv.-Nr.: 2005-05-23/052/IN98/2254
Kapitel 4
Numerische
Konsistenzprüfung
Ein anderer Ansatz zur Prüfung der Konsistenz erfolgt über das Erstellen von
numerischen Ungleichungen. Diese Ungleichungen werden für jedes Medienobjekt
gesondert angegeben und repräsentieren die Bedingungen entsprechend der AllenRelationen und der aktuellen Objektdauer. Sie ergeben sich aus dem Constraint
Graph bzw. den Difference Constraints und können anschaulich abgeleitet werden.
Anschließend werden jedem Medienobjekt Bedingungen für die minimale bzw. maximale Dauer zugewiesen. Liegt die Dauer der Objekte innererhalb des angegebenen
Intervall, sind die Bedingungen bzw. der Graph konsistent.
4.1
Erzeugen der Ungleichungen
Die Konsistenzprüfung ist auch hier äquivalent mit der Suche nach negativen Zyklen. In Abschnitt 3.2 wurden alle potentiell negativen Zyklen aufgelistet. Liegt
eine Allen-Relation und die Dauer der beiden verknüpften Objekte als Difference
Constraints bzw. Constraint Graph vor, wird überprüft, ob einer oder mehrere
relevante Zyklen aus Aufzählung 3.3 vorkommen. Existieren alle Kanten eines Zyklus im Graph der Allen-Relation, muss er anhand der Kantengewichte überprüft
werden. Ist die Aufsummierung der Werte kleiner als 0, ist der Kreis negativ.
Eine Inkonsistenz resultiert aus Widersprüchen der definierten Ausgabebedingungen und der aktuellen Dauer eines Objektes. Kanten der Menge E2 (Ausgabebedingungen) und Kanten der Menge E1 (vgl. Definition 3.1) sind immer an einem
relevanten Zyklus beteiligt1 . Sind die Medienobjekte als ein von der Datenbank
unterstützter Medien-Typ gespeichert, liegt die Dauer als Attribut vor und kann
auf diesem Wege gewonnen werden. Bei der Erzeugung des Graphen werden die
Werte ausgelesen und die entsprechenden Kanten im Graphen erzeugt. Liegen die
Medienojekte nicht real in der Datenbank vor, wird stattdessen pro Objekt ein
Duration-Constraint erzeugt. Die Dauer eines Objektes A (A duration(tA )) wird
durch folgende Difference Constraints repräsentiert:
1 Auch hier gilt die Voraussetzung, dass alle Allen-Relationen bzw. Difference Constraints korrekt erzeugt werden.
Inv.-Nr.: 2005-05-23/052/IN98/2254
44
KAPITEL 4. NUMERISCHE KONSISTENZPRÜFUNG
end(A) − st(A) ≤ tA ,
st(A) − end(A) ≤ −tA .
Wurde ein potentieller negativer Zyklus gefunden, das heisst alle relevanten
Kanten existieren im Teilgraph der Relation, werden die Kantengewichte ausgewertet.
In der Regel werden sich die Ausgabebedingungen häufig bei der Erstellung des
Projektes ändern und danach über einen längeren Zeitraum konstant bleiben. Das
heisst, nach der Speicherung in der Datenbank werden hauptsächlich die Medienobjekte bearbeitet. Die relevante Größe ist hierbei die Dauer.
Wie bereits erwähnt, bestehen die Kanten eines potentiellen negativen Zyklus
aus den Kanten der Ausgabebedingungen (E2 ) und der Objektdauer (E1 ) zusammen. Geht man von einer Konstanz der Bedingungen bzw. Kanten der Menge E2
aus, lassen sich Minimum- oder Maximumbedingungen für die Dauer jedes verwendeten Medienobjektes formulieren.
Die Aufsummierung der Kantengewichte eines Zyklus muss größer Null sein, es
wird also eine Ungleichung aufgestellt. Durch Umformung der Ungleichungen nach
dem Kantengewicht der Menge E1 erhält man eine Bedingung für die Dauer eines
Objektes. Je nach Allen-Relation kann es sich dabei um eine oder mehrere Ungleichungen handeln, die eine Minimum- oder Maximumbedingung für die Objektdauer
repräsentieren.
Zwei Beispiele sollen den Sachverhalt verdeutlichen. Als erstes Beispiel zur Erstellung der Ungleichungen dient die overlaps-Relation. Die allgemeine Notation
lautet A overlaps(c1 ,c2 ) B, wobei A und B Medienobjekte sind und die Konstanten c1 und c2 Mindestabstände zwischen den Start- bzw. Endzeitpunkten der beiden
Objekte angeben. Die daraus resultierenden Difference Constraints lauten:
st(A) − st(B) ≤ −c1 ,
end(A) − end(B) ≤ −c2 ,
st(B) − end(A) ≤ −1.
Der dazu gehörende Constraint Graph ist in Abbildung 4.1 zu sehen. |tA | bzw.
|tB | steht für die Dauer der Objekte. Die Kanten im Graphen resultieren aus je
einem Duration-Constraint und den daraus generierten folgenden Difference Constraints:
end(A) − st(A) ≤ tA ,
st(A) − end(A) ≤ −tA ,
end(B) − st(B) ≤ tB ,
st(B) − end(B) ≤ −tB .
Im Graph existieren zwei Zyklen, die negativ werden können: zum einen von
Inv.-Nr.: 2005-05-23/052/IN98/2254
4.1. ERZEUGEN DER UNGLEICHUNGEN
45
end(A)
end(B)
-c2
| tA | -|tA|
-1
|tB| -|tB|
-c1
st(A)
st(B)
Abbildung 4.1: Unsichere Relation: overlaps
st(B) über end(B) nach end(A) und zum anderen von st(B) über st(A) nach
end(A). Sie entsprechen den Zyklen z3 und z4 der Aufzählung 3.3. Da diese Zyklen
bzw. Pfade nichtnegativ sein müssen, lässt sich durch Summierung der Kantengewichte pro Zyklus eine Ungleichung formulieren:
|tB | − c2 − 1 ≤ 0,
−c1 + |tA | − 1 ≤ 0.
Durch Umformen der Ungleichungen nach |tA | bzw. |tB |, erhält man folgende
Bedingungen für die Dauer der beiden Medienobjekte:
c1 + 1 ≤ |tA | (M inimum),
c2 + 1 ≤ |tB | (M inimum).
Sind diese Ungleichungen erfüllt, sind die beiden Zyklen nichtnegativ und die
Allen-Relation konsistent.
Abhängig von der verwendeten Allen-Relation können auch mehrere Minimumoder Maximumbedingungen für die Objektdauer resultieren. Als zweites Beispiel
dient die Relation A overlapsvse (c1 , l, c2 , m) B. Sie definiert eine Überlappung der
beiden Medienobjekte mit jeweils einem Intervall zwischen den Start- und den
Endzeitpunkten ([c1 , l] und [c2 , m]) (Abbildung 4.2).
Ein Blick auf den Constrained Graph für diese Relation zeigt, dass sie vier
Zyklen der Aufzählung 3.3 enthält: z1 , z2 , z3 , z4 . Zu den beiden aus der overlapsRelation kommen zwei Zyklen hinzu, die einmal links- und einmal rechtsherum alle
vier Objekte enthalten. Hieraus ergeben sich folgende vier Ungleichungen:
Inv.-Nr.: 2005-05-23/052/IN98/2254
46
KAPITEL 4. NUMERISCHE KONSISTENZPRÜFUNG
end(A)
c2 + m
end(B)
-c2
|tA| -|tA|
-1
| tB | -| tB |
c1 + l
st(A)
-c1
st(B)
Abbildung 4.2: Unsichere Relation: overlapsvse
|tA | − 1 − c1 ≥ 0,
− |tA | + c1 + l + |tB | − c2 ≥ 0,
|tB | − c2 − 1 ≥ 0,
|tA | + c2 + m − |tB | − c1 ≥ 0.
Stellt man beide Ungleichungen jeweils nach |tA | und |tB | um, erhält man Ungleichungen, welche die neuen Zyklen berücksichtigen und härtere Eigenschaften
gemäß den Bedingungen für die Dauer der Medienobjekte A und B angeben:
c1 + 1 ≤ |tA | (M inimum),
|tB | + c1 − c2 − m ≤ |tA | (M inimum),
|tB | + c1 + l − c2 ≥ |tA | (M aximum),
c2 + 1 ≤ |tB | (M inimum),
|tA | − c1 − l + c2 ≤ |tB | (M inimum),
|tA | − c1 + c2 + m ≥ |tB | (M aximum).
Sämtliche Allen-Relationen lassen sich so auf negative Zyklen überprüfen. Abhängig von der verwendeten Relationen, können eine oder mehrere Bedingungen
zutreffen. Eine Übersicht der numerischen Bedingungen bzw. der Minimum- / Maximumbedingungen für alle betrachteten unsicheren Allen-Relationen befindet sich
im Anhang A.2.
Inv.-Nr.: 2005-05-23/052/IN98/2254
4.2. ÄNDERUNG EINER RELATION
4.2
47
Änderung einer Relation
Analog zur Konsistenzprüfung mit Bellman-Ford, ist auch bei der numerischen
Methode die Überprüfung auf globale Zyklen nicht erforderlich, da sie durch die
Beschränkungen des Beziehungsgraphen ausgeschlossen werden.
Zur Identifizierung der Ungleichungen wird ein Teilgraph mit allen relevanten Knoten und Kanten erstellt2 . Die Konstruktion des Teilgraphen erfolgt analog
zur Methode von Bellman-Ford. Es wird auch hier zwischen der Änderung einer
Relation und der Medienobjektdauer unterschieden. Wird eine Allen-Relation verändert, müssen nur die entsprechenden numerischen Bedingungen der beteiligten
Medienobjekte überprüft werden. Bei der Vergrößerung oder Verkleinerung einer
Objektdauer werden zunächst alle beteiligten Relationen und die dazugehörigen
Medienobjekte identifiziert. Dies erfolgt wahlweise über den Beziehungsgraphen
oder durch Auswertung der numerischen Bedingungen. Falls die Dauer des geänderten Objektes A in der Bedingung des Objektes B vorkommt, stehen beide in
Beziehung und die Relation muss zum Teilgraph hinzugefügt werden. Anschließend
erfolgt die Überprüfung durch die Erstellung der Ungleichungen und Vergleich mit
der Objektdauer. Falls es hier zu einem Widerspruch kommt, ist die betreffende
Allen-Relation und demzufolge der gesamte Graph inkonsistent.
Neben der Beschränkung auf Teilgraphtests können auch hier analog zum Konsistenzcheck aus dem letzten Kapitel Operationen in sichere und unsichere eingestuft werden. Da die Konsistenzbedingungen unabhängig von der Art der Überprüfung sind, wird die Klassifizierung der Allen-Relationen aus Abschnitt 3.2 bzw.
der Operationen aus Abschnitt 3.3 verwendet. Die before-Relation z. B. ist sicher,
muss also nicht getestet werden.
Der Algorithmus zum Überprüfen der Konsistenz mit numerischen Ungleichungen ist in Abbildung 4.3 dargestellt. Als Input erhält er die geänderte Bedingung.
Zunächst wird der zu testende Teilgraph laut Algorithmus Abbildung 3.9 gebildet (1). Anschließend wird überprüft, ob potentielle negative Zyklen im Graphen
vorhanden sind (2). Grundlage dafür sind die Bedingungen der Aufzählung 3.3.
Sind die relevanten Kanten im Teilgraph vorhanden, werden alle gefundenen Zyklen durch Auswertung der Ungleichung überprüft (2-4). Ist mindestens einer davon
negativ, gibt der Algorithmus ein f alse aus (7). Sind alle Ungleichungen wahr, ist
der Teilgraph konsistent und der Algorithmus gibt ein true zurück.
Wie bei der Überprüfung mit Bellman-Ford können mehrere Änderungen ge”
sammelt“ und anschliessend gemeinsam überprüft werden. Bei der Input-Condition
kann es sich sowohl um eine Allen-Relation als auch um ein Duration-Constraint
handeln.
Ob und in welchem Maße diese Methode zur Überprüfung der Konsistenz gegenüber Bellman-Ford schneller ist, wird in Kapitel 6 betrachtet. Im Gegensatz
zur Methode mit Bellman-Ford eignen sich die Ergebnisse der numerischen Ungleichungen nicht zur Berechnung der Ausgabezeiten. Dies erfordert stets die korrekten
kürzesten Pfade im aktuellen Constraint Graph (vgl. Kapitel 5).
2 Der Teilgraph steht stellvertretend für die Menge der Difference Constraints, die für den
Konsistenzcheck relevant sind.
Inv.-Nr.: 2005-05-23/052/IN98/2254
48
KAPITEL 4. NUMERISCHE KONSISTENZPRÜFUNG
Algorithm:
numericCheck(INPUT condition, OUTPUT check)
Input:
Condition condition
Output:
Boolean check
1
2
2
3
4
5
6
7
partialGraph = buildPartialGraph(condition)
cycles = checkCycleConditions(partialGraph)
for all cycles do {
if cycle is negative {
check = f alse
}
}
return check
Abbildung 4.3: Algorithmus zur numerischen Konsistenzüberprüfung
4.3
Umsetzung durch Trigger/Constraints
Die Realisierung im DBMS kann analog zur in Abschnitt 3.7 beschriebenen Vorgehensweise erfolgen. Statt der Überprüfung mit Bellman-Ford wird eine gespeicherte
Prozedur erstellt, welche die Bedingungen durch numerische Ungleichungen überprüft. Es ist aber auch ein Konsistenzcheck ohne eine Java-Prozedur möglich.
Wie bereits erwähnt, wird sich in der Regel die Objektdauer öfters ändern als die
eigentlichen Ausgabebedingungen. Aus diesem Grund ist es vorteilhaft, die Bedingungen statisch als numerische Gleichungen zu definieren und Minimum- und/oder
Maximumbedingungen (Intervallgrenzen) für die Dauer jedes Objekts in der Datenbank abzulegen. Bei einer anschließenden Änderung der Objektdauer werden die
numerischen Gleichungen nicht neu erstellt, sondern liegen bereits vor und können
effizient ausgewertet werden.
Um diesen Vorgang zu automatisieren, kann die Überprüfung durch Trigger erfolgen. Bei der Speicherung der Bedingungen in der Datenbank werden für jedes
Objekt die Minimum- und/oder Maximumbedingungen erstellt. Anschließend wird
pro Objekt ein oder mehrere Trigger erzeugt. Die Trigger beinhalten eine PS/SQLProzedur, welche die Ungleichungen bzw. Intervallgrenzen auswerten. Die Intervalle
können statisch mit konkreten Werten aufgrund der aktuellen Bedingungen erzeugt
oder dynamisch durch Auslesen der Kantengewichte des in der Datenbank gespeicherten Graphen bestimmt werden. Werden im ersten Fall die Paramenter oder
der Typ der Bedingung geändert, müssen die entsprechenden Trigger neu generiert werden. Im zweiten Fall ist eine Neuerstellung nur bei der Typänderung einer
Relation erforderlich.
Bei der Änderung einer Objektdauer wird der Trigger gefeuert. Ist die Auswertung der Bedingungen positiv, wird das geänderte Objekt bzw. Objektdauer
in der Datenbank gespeichert. Im Falle einer Inkonsistenz verwirft der Trigger die
Änderungen, um die Konsistenz das Projektes in der Datenbank sicher zu stellen.
Pro Allen-Relation wird ein Trigger je beteiligtem Objekt erzeugt. Diese enthalten alle Minimum- und/oder Maximumbedingungen, die aus der Relation hervorgehen. Pro Objekt existiert mindestens ein Trigger, da es mit mindestens einem
Inv.-Nr.: 2005-05-23/052/IN98/2254
4.3. UMSETZUNG DURCH TRIGGER/CONSTRAINTS
49
anderen Objekt in Beziehung steht. Ist ein Medienobjekt mit n anderen Objekten
über Allen-Relationen verknüpft, werden n Trigger für dieses Objekt generiert. Bei
Änderung der Objektdauer kommt es zum Aufruf aller n Trigger und der betreffende Teilgraph respektive die relevanten Difference Constraints werden hinsichtlich
ihrer Konsistenz bewertet.
Die Erzeugung der Trigger zur Überprüfung der Intervallgrenzen kann automatisch erfolgen. Dazu wird ein zusätzlicher Trigger definiert, der bei jeder Änderung
der Constraints die Trigger zur Intervallüberprüfung erzeugt oder gegebenenfalls
ändert.
Alternativ ist auch eine Umsetzung über herkömmliche Constraints denkbar.
Wird die Dauer eines Objektes in einer Tabelle gespeichert, kann anhand der vorher
erstellten Intervallgrenzen ein Vergleich mit der realen Dauer stattfinden. Wird eine
Relation geändert, müssen auch hier die Constraints der Tabelle angepasst werden.
Inv.-Nr.: 2005-05-23/052/IN98/2254
50
KAPITEL 4. NUMERISCHE KONSISTENZPRÜFUNG
Inv.-Nr.: 2005-05-23/052/IN98/2254
Kapitel 5
Berechnung des
Ausgabeschedule
Neben der Überprüfung der Konsistenz der Ausgabebedingungen spielt der Schedule eine zentrale Rolle. Anhand der relativen Beziehungen zwischen den Objekten wird implizit festgelegt, zu welchen Zeitpunkten eine Ausgabe erfolgen soll. In
diesem Kapitel wird die Berechnung der Ausgabezeiten aufgrund der Constraints
erläutert und effektive Möglichkeiten vorgestellt, den Ausgabeschedule nach Änderungen von Bedingungen zu berechnen, ohne den Algorithmus von Bellman und
Ford auf den gesamten Constraint Graphen anzuwenden.
5.1
Ausgabeschedule
Die Berechnung des Ausgabeschedule aufgrund der kürzesten Pfade wird am Beispielgraphen aus Abschnitt 3.1 erläutert. Voraussetzung ist ein Constraint Graph,
auf dem Bellman und Ford einmal gelaufen ist und ein true zurück gab. Das bedeutet der Graph bzw. die Bedingungen sind konsistent und es wurden die kürzesten
Pfad von jedem Knoten zum Startknoten v0 berechnet. Die Werte entsprechen
im Übrigen der Lösung für die Unbekannten vom System < V,C > der Difference Constraints. Voraussetzung für die Berechnung des Ausgabeschedule ist ein
konsistenter Constraint Graph, bei dem die kürzesten Pfade vom Startknoten v0
berechnet wurden.
Alle Knoten haben einen Wert (kürzesten Pfad) kleiner oder gleich 0. Das liegt
an den Kanten mit dem Gewicht c = 0, welche vom Startknoten v0 zu jedem
anderen Knoten gehen. Die den Knoten zugewiesenen Gewichte bilden im gewissen
Sinne schon einen Ausgabeschedule. Um sie für den Anwender verständlicher zu
machen, erfolgt noch eine Anpassung. Die Ausgabezeiten sind danach alle größer
0.
Zuerst wird der kleinste Wert der Lösungen für die Unbekannten gesucht, d. h.
das kleinste Knotengewicht. Dieser Wert ist ein Korrekturwert k für alle anderen
Lösungen L. Die positive Lösung L0 für den Ausgabeschedule für alle Unbekannten
berechnet sich wie folgt:
L0 = L − (k).
Inv.-Nr.: 2005-05-23/052/IN98/2254
(5.1)
52
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
0
0
end(o1)
0
end(o2)
end(o4)
end(o3)
-5
0
v0
15
-15
25
-2
-1
-25
20
-20
-5
10
-10
0
-3
st(o1)
0
st(o2)
0
st(o3)
st(o4)
0
Abbildung 5.1: Constraint Graph des Beispielprojektes
Im folgenden Abschnitt wird der Ausgabeschedule an einem konkreten Beispiel
erzeugt.
5.2
Berechnung am Beispiel
Auf dem Constraint Graph aus Abbildung 5.1 wird der Konsistenzcheck ausgeführt.
Die Konsistenz ist in diesem Zusammenhang essentiell (ein Schedule von einem
inkonsistenten Graphen ist falsch) aber nur ein Teilziel. Der Constraint Graph
nach Bellman-Ford ist in Abbildung 5.2 zu sehen. Mit den Knotengewichten kann
die eigentliche Berechnung erfolgen.
Das zur Berechnung der Ausgabezeiten benötigte kleinste Knotengewicht beträgt k = −62 (Knoten st(o1 )). Dieser Wert wird laut Gleichung 5.1 von allen
Knotengewichten subtrahiert und man erhält die jeweiligen Start- und Endpräsentationszeitpunkte. Der Ausgabeschedule für die vier Objekte im Beispiel lautet:
st(o1 ) = 0, end(o1 ) = 15,
st(o2 ) = 17, end(o2 ) = 42,
st(o3 ) = 27, end(o3 ) = 47,
st(o4 ) = 52, end(o4 ) = 62.
Abbildung 5.3 zeigt den Ausgabeschedule mit den Objekten grafisch. Hier ist
zu sehen, wie die kürzesten Pfade der Knoten mit den eigentlichen Ausgabezeiten zusammenhängen. Die absoluten Zeiten erhält man, wenn man die kürzesten
Pfade auf der Zeitachse abträgt und den Nullpunkt um den Wert des kleinstes
Knotengewichtes verschiebt. Zum besseren Verständnis sind auch in den folgenden Abbildungen sowohl die absoluten Ausgabezeiten als auch die kürzesten Pfade
angegeben.
Die Tatsache, dass eine Konsistenzprüfung mit Bellman-Ford die Grundlage für
die Scheduleberechnung bildet, indem sie die benötigten kürzesten Pfade liefert,
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.2. BERECHNUNG AM BEISPIEL
53
0
0
0
end(o1)
end(o4)
end(o3)
end(o2)
-47
-5
-20
0
-15
0
v0
15
-15
25
-2
-1
-25
-20
20
-5
10
-10
0
-62
-3
-45
st(o1)
st(o2)
0
0
-35
-10
st(o3)
st(o4)
0
Abbildung 5.2: Constraint Graph nach Bellman-Ford mit kürzesten Pfaden
o3
o1
o2
o4
0
15 17
27
42 47 52
62
-62
-47 -45
-35
-20 -15 -10
0
Zeit
Knotengewichte
Abbildung 5.3: Ausgabeschedule
Inv.-Nr.: 2005-05-23/052/IN98/2254
54
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
kann schon für Optimierungen genutzt werden. Werden Änderungen an den Bedingungen vorgenommen und danach der gesamte Constraint Graph mit Bellman-Ford
geprüft, liegen die erforderlichen Werte schon vor und eine erneute Berechnung der
kürzesten Pfade ist überflüssig.
Bei der Berechnung des Schedule ist von Bedeutung, dass man zwischen den
kürzesten Pfaden und den eigentlichen Ausgabezeiten unterscheidet. Beide Werte
drücken prinzipiell den gleichen Sachverhalt aus und werden ja nach Kontext verwendet. Das negative Knotengewicht von st(o1 ) mit dem Wert −62 repräsentiert
die Ausgabezeit 0, das Knotengewicht von end(o1 ): −47 die Ausgabezeit 15 usw..
Ändern sich die Knotengewichte, müssen sich nicht zwangsläufig auch die Ausgabezeiten ändern. Erhöht man zum Beispiel die Dauer von Objekt o1 von 15 auf
25 Zeiteinheiten (ZE), betragen die resultierenden Knotengewichte von st(o1 ) −72
und von end(o1 ) −47. Die eigentliche Ausgabezeit des Startknotens bleibt aber
gleich, da dieser wiederum das kleinste Knotengewicht im Graphen besitzt. Die
Erhöhung der Dauer von Objekt o1 wird also implizit durch die Anpassung des
kleinsten Knotengewichtes ausgeglichen. Die Zeiten der anderen Objekte ändern
sich dadurch entsprechend.
5.3
Optimierungen
Die Einschränkungen im Beziehungsgraph (Abschnitt 3.1) bieten wie bei allen vorherigen Methoden Möglichkeiten zur Laufzeitoptimierung. Globale Zyklen sind ausgeschlossen, also müssen nur lokale Zyklen überprüft werden. Ausgangspunkt ist
wieder ein konstistenter Constraint Graph, dessen kürzeste Pfade für alle Knoten
berechnet wurden.
Die Optimierungen bei Änderung einer Allen-Relation bzw. der Dauer eines Objektes müssen auch hier gesondert betrachtet werden. Wie in allen anderen Fällen
der Optimierung wird zunächst nur ein Teilgraph des gesamten Constraint Graph
betrachtet. Zum Verständnis der Optimierungen ist es notwendig zu wissen, wie
der Algorithmus von Bellman und Ford die kürzesten Pfade aufgrund der Graphstruktur berechnet.
Betrachtet man den getesteten Constraint Graphen aus dem verwendeten Beispiel (Abbildung 5.2) fällt auf, dass die Knotengewichte in Richtung des Startknoten v0 kleiner werden. Und zwar in dem Maße, wie es die Bedingungen bzw. die
Objektdauer erlauben. Die Ausgabezeiten bzw. die kürzesten Pfade verlaufen also
von hinten nach vorne im Graphen. Das liegt zum einen an der Darstellungsform
des Graphen, zum anderen aber hauptsächlich an der Forderung, dass Objekte nur
einen Vorgänger haben. In der Praxis bedeutet das, dass die Objekte grundsätzlich
in der Reihenfolge miteinander verknüpft werden, wie sie später ausgegeben werden sollen. Es kann also nicht vorkommen, dass dass ein Objekt, welches näher am
Startknoten v0 liegt, vor einem Objekt ausgegeben wird, dass weiter entfernt im
selben Strang 1 liegt. Es gibt aber einen Sonderfall. Direkt benachbarte Objekte
können zeitgleich präsentiert werden, falls die equals - Relation verwendet wird.
Die Tatsache dieser strikten zeitlichen Reihenfolge trifft nur zu, wenn keine inversen Relation verwendet werden. Inverse Relationen wurden in [Ra04] erwähnt
und die zugehörigen Difference Constraints zur Verfügung gestellt. Zum Beispiel
ist die Allen Relation after invers zu before: B after A und A before B drücken
1 Der Begriff Strang wird im folgenden Abschnitt eingeführt. Zur Vereinfachung werden vorerst
nur Beispiele mit einer einfachen Struktur, d. h. nur einem Strang betrachtet.
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.3. OPTIMIERUNGEN
v0
o1
55
AR1
o2
AR2
o3
AR3
o4
Abbildung 5.4: Beziehungsgraph des Beispielprojektes
den selben Sachverhalt aus und repräsentieren die selben Difference Constraints.
Daneben gibt es weitere inverse Relationen, wie z. B. meets-invers, overlaps-invers
oder during-invers. Da sie grundsätzlich die Verknüpfungsmöglichkeiten von Objekten funktionell nicht erweitern, werden sie sowohl in dieser Diplomarbeit als
auch im ConstraintManager nicht betrachtet. Des Weiteren sind die vorgestellten
Optimierungen nicht für inverse Relationen gültig.
Die folgenden Abschnitte erläutern Schritt für Schritt die Optimierungsmöglichkeiten zur korrekten und effizienten Berechnung der kürzesten Pfade, ohne BellmanFord auf dem gesamten Constraint Graph auszuführen.
5.3.1
Änderung einer Bedingung am Ende eines Stranges
Beginnend mit der Änderung einer Bedingung werden zur Veranschaulichung drei
Fälle erläutert. Als Grundlage dient das Beispielprojekt aus Abschnitt 3.1. Zuerst
wird die Relation AR3 zwischen den Objekten o3 und o4 verändert (siehe Tabelle
3.2). Der Abstand wird von 5 auf 8 Sekunden erhöht: o3 before(8) o4 . Objekt o4
soll also später präsentiert werden.
Die beiden Objekte befinden sich am Ende eines Stranges“, welcher vom Start”
knoten v0 ausgeht. Als Strang wird eine Menge von Relationen und Objekten
bezeichnet, die horizontal in einer Ebene im Beziehungsgraphen liegen. Der Beziehungsgraph des Beispiels ist in Abbildung 5.4 zu sehen. Dort ist der Strang gut
erkennenbar. Er verläuft vom Startknoten aus und umfasst alle Relationen und Objekte. Analog dazu ist er auch im Constraint Graph (Abbildung 5.1) zu erkennen
mit mehr Knoten und Kanten.
Der in Abbildung 3.14 vorgestellte komplexere Beziehungsgraph besteht aus
mehreren Strängen bzw. Teilbäumen, die von einem Objekt abzweigen. In Abschnitt
5.5 wird auf Optimierungen bei Graphen mit mehreren Strängen eingegangen. Im
hier verwendeten Beispiel aus Abschnitt 3.1, an welchem die Berechnung der Ausgabezeiten gezeigt wird, bildet ein Strang den gesamten Constraint Graphen.
Der zu testende Teilgraph wird analog zu Abschnitt 3.3 gebildet und besteht
aus dem Startknoten v0 , den betreffenden den Start- und Endknoten der Objekte
o3 und o4 und den dazugehörigen Kanten (Abbildung 5.5). Durch die veränderte
Bedingung sind die Knotengewichte nicht mehr korrekt 2 und werden durch den
Algorithmus von Bellman und Ford neu berechnet.
Im korrigierten Teilgraph (Abbildung 5.6) sieht man die Gewichtsänderung der
Knoten von Objekt o3 . Mit Hilfe der alten und neuen Werte lässt sich ein Korrekturwert berechnen. Dieser Korrekturwert gibt an, um wie viele Zeiteinheiten
der Ausgabeschedule dieses Teilgraphen verändert wurde. Zunächst müssen die
Objektknoten gefunden werden, die die kleinsten Knotengewichte besitzen. In der
Regel wird es das Objekt sein, welches im Beziehungsgraphen näher am Startknoten v0 liegt. Der Korrekturwert ergibt sich aus der Differenz der neuen und der
alten Knotengewichte. Die Differenzen der Start- bzw. Endknoten müssen gleich
2 Die
betreffende Kante und Knoten sind in der Abbildung gestrichelt.
Inv.-Nr.: 2005-05-23/052/IN98/2254
56
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
end(o3)
end(o4)
0
0
-15
0
v0
20
-20
-8
-10
10
0
-35
-10
st(o3)
st(o4)
0
Abbildung 5.5: Teilgraph Strangende vor Bellman-Ford
end(o3)
end(o4)
0
0
-18
0
v0
20
-20
-8
10
-10
0
-10
-38
st(o3)
0
st(o4)
Abbildung 5.6: Teilgraph Strangende nach Bellman-Ford
sein, da sich die Objektdauer nicht geändert hat. Wichtig ist, dass man die Knoten
des Objektes mit den kleineren Knotengewichten wählt, da nur hier die Differenz
berechnet werden kann. Die Knotengewichte des anderen Objektes bleiben in der
Regel unverändert und hätte das Gewicht Null zur Folge. In diesem Beispiel dienen die neuen und alten Knotengewichte des Startknoten von o3 als Grundlage der
Berechnung: −38 − (−35) = −3. Alternativ können auch die Endknoten verwendet
werden: −18 − (−15) = −3.
Im vorigen Abschnitt wurde gezeigt, dass sich die Knotengewichte bzw. die Ausgabezeiten der Medienobjekte in Richtung v0 im Strang bzw. Teilbaum aufbauen.
Die Zeiten von früher auszugebenden Objekten berechnen sich auf Grund der Zeiten
der Nachfolger3 . Um die kürzesten Pfade der vorherigen Objekte an die Änderung
anzupassen, muss der Korrekturwert ab der Stelle der Änderung an die Vorgänge3 Hier sind wieder zwei Sichten möglich: Die kürzesten Pfade bzw. die Ausgabezeiten bauen
aufeinander auf.
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.3. OPTIMIERUNGEN
v0
o1
57
AR1
o2
AR2
o3
AR3
o4
Abbildung 5.7: Durchreichen“ des Korrekturwertes
”
robjekte bis zum Startknoten v0 weitergegeben werden. D. h., alle Knotengewichte
(pro Objekte ein Start- und Endknoten) vor dem geänderten Objekt o3 werden um
den Wert 3 verkleinert. Der Startknoten v0 zählt nicht als zu korrigierendes Objekt. Die betroffenden Medienobjekte können leicht anhand des Beziehungsgraphen
identifiziert werden (Abbildung 5.7). Der Korrekturwert wird über den Vorgänger
Objekt o2 bis einschliesslich Objekt o1 nach vorne in Richtung v0 durchgereicht4 .
Die Abbildung 5.7 zeigt zum besseren Verständnis den Beziehungsgraphen. Die
Anpassung der Knotengewichte wird am Constraint Graph vorgenommen, wobei
von jedem betroffenden Objekt das Gewicht der Start- und Endknoten angepasst
werden.
Der Schedule kann jetzt mit den korrigierten Knotengewichten des Constraint
Graph (Abbildung 5.8) berechnet werden. Das neue kleinste Knotengewicht befindet sich unverändert bei Objekt o1 (Knoten st(o1 )) und beträgt -65. Da die Werte
von Objekt o1 , o2 und o3 mit den Korrekturwert angepasst wurden, ändern sich
ihre Ausgabezeiten nicht. Nur Objekt o4 ist, wie erwartet, betroffen. Die neuen
Zeiten lauten:
st(o1 ) = 0, end(o1 ) = 15,
st(o2 ) = 17, end(o2 ) = 42,
st(o3 ) = 27, end(o3 ) = 47,
st(o4 ) = 55, end(o4 ) = 65.
Der komplette Schedule mit dem um 3 Sekunden nach hinten verschobenen
Objekt o4 ist in Abbildung 5.9 grafisch dargestellt.
5.3.2
Änderung einer Bedingung am Anfang eines Stranges
Ausgehend vom ursprünglichen Beispiel aus Abschnitt 3.1, wird im zweiten Fall
die Relation AR1 verändert. Der Abstand wird von 3 auf 5 Zeiteinheiten erhöht:
o1 before(5) o2 . Da sich die Beziehung am Anfang vom Strang befindet, müssen
nach der Berechnung von Bellman - Ford keine weiteren Knotengewichte angepasst
werden. Die Berechnung der korrekten Ausgabezeiten nach dieser Änderung erfolgt anschließend durch Bestimmung des kleinsten Knotengewichtes im gesamten
Graphen.
Zunächst wird der zu überprüfende Teilgraph nach dem gleichen Schema wie im
vorherigen Abschnitt erstellt. Er besteht aus dem Startknoten v0 , den betreffenden
den Start- und Endknoten der Objekte o1 und o2 und den dazugehörigen Kanten.
Nach Bellman-Ford (Abbildung 5.10) ist das kleinste Knotengewicht wieder bei
4 Die gestrichelten Pfeile in der Abbildung sollen den Weg der Anpassung darstellen und sind
keine neuen Allen-Relationen.
Inv.-Nr.: 2005-05-23/052/IN98/2254
58
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
0
0
0
end(o1)
end(o4)
end(o3)
end(o2)
-50
-5
-23
0
-18
0
v0
-15
15
-1
-25
25
-2
-20
20
-8
10
-10
0
-65
-48
st(o1)
st(o2)
0
-3
0
-38
-10
st(o3)
st(o4)
0
Abbildung 5.8: Constraint Graph nach Bellman - Ford
o3
o1
o2
o4
0
15 17
27
42 47
55
65
-65
-50 -48
-38
-23 -18
-10
0
Zeit
Knotengewichte
Abbildung 5.9: Ausgabeschedule
end(o1)
0
end(o2)
-30
0
0
v0
15
-15
-5
25
-25
0
-45
st(o1)
-25
0
st(o2)
Abbildung 5.10: Teilgraph ohne angepasste Kantengewichte nach Bellman - Ford
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.3. OPTIMIERUNGEN
59
o3
o1
o4
o2
0
10 15 20
30 35
45
-45
-35 -30 -25
-15 -10
0
Zeit
Knotengewichte
Abbildung 5.11: Inkorrekter Ausgabeschedule
st(o1 ) mit dem Wert -45 zu finden und es ergeben sich folgende Ausgabezeiten:
st(o1 ) = 0, end(o1 ) = 15,
st(o2 ) = 20, end(o2 ) = 45,
st(o3 ) = 7, end(o3 ) = 27,
st(o4 ) = 35, end(o4 ) = 45.
Abbildung 5.11 zeigt den Ausgabeschedule in grafischer Darstellung. Während
die Werte der Objekte o1 und o2 korrekt sind, wurden Knotengewichte von o3 und
o4 falsch berechnet. Der Grund liegt in der Erstellung eines Teilgraphen. In Abschnitt 5.3 wurde gezeigt, dass sich die kürzesten Pfade von hinten nach vorne in
einem Strang aufbauen. Diese Eigenschaft wurde im Teilgraph aber nicht berücksichtigt. Da die Kantengewichte im Teilgraph vom Startknoten v0 zu allen anderen
Knoten jeweils das Gewicht 0 haben, zählt Objekt o2 als letztes auszugebendes
Objekt. Die Objekte o3 und o4 werden nicht berücksichtigt.
Nimmt man Objekte aus dem Constraint Graphen heraus, um gesondert die
kürzesten Pfade zu berechnen, muss eine Umgebung geschaffen werden, die den gesamten Graphen simuliert. Dies erreicht man durch Anpassen der Kantengewichte
vom Startknoten v0 zu den einzelnen Objektknoten. Im Constraint Graph stellt
v0 eine Art Start(-zeit-)punkt da. Die ausgehenden Kanten mit dem Gewicht 0,
repräsentieren genau diesen Startpunkt zum Zeitpunkt 0. Verringert man die Kantengewichte, verschieben sich alle Objekte im Ausgabeschedule genau um diese
Differenz.
Das Gewicht der ausgehenden Kanten vom Startknoten v0 bestimmt also den
Startzeitpunkt der Objekte des Graphen. Mit Hilfe dieser Kanten kann man festlegen, zu welchem Zeitpunkt der Teilgraph starten soll. Mit den richtigen Kantengewichten ist es somit möglich, für den Teilgraph die Umgebung des gesamten
Graphen, bzw. den richtigen Einstiegszeitpunkt zu simulieren.
Betrachtet man den gesamten Constraint Graphen aus Abbildung 5.2, ist festzustellen, dass die Kantengewichte vom Startknoten v0 zu allen anderen Knoten
mit dem Gewicht des Endknotens end(o4 ) des im Beziehungsgraphen von v0 entferntesten Objektes übereinstimmen. Sie haben jeweils den Wert 0. Das stimmt mit
der Tatsache überein, dass bedingt durch die Einschränkungen im Beziehungsgraphen sich die kürzesten Pfade von hinten nach vorne in Richtung des Startknotens
Inv.-Nr.: 2005-05-23/052/IN98/2254
60
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
end(o1)
0
end(o2)
-47
-20
0
v0
15
-15
-5
25
-25
0
-62
st(o1)
-45
0
st(o2)
Abbildung 5.12: Teilgraph Stranganfang vor Bellman - Ford
v0 über die Endknoten der Objekte aufbauen. Des Weiteren stellt das Gewicht von
end(o4 ) (gleich den Gewichten der ausgehenden Kanten von v0 ) das größte Knotengewicht im gesamten Graphen dar. Also liegt es nahe, im Teilgraph das größte
Gewicht zu suchen und die ausgehenden Kanten von v0 auf diesen Wert zu setzen.
Im Beispiel ist dies der Knoten end(o2 ) mit dem Gewicht -20 (Abbildung 5.12,
originaler Teilgraph).
Mit den angepassten Kantengewichten vom Startknoten v0 aus wird der korrekte Teilgraph erstellt (Abbildung 5.13, gestrichelte Kanten) und mittels Bellman
- Ford die kürzesten Pfade berechnet (Abbildung 5.14). Es ist nicht zwingend notwendig, alle Kantengewichte mit dem neuen Wert zu ersetzen. Theoretisch reicht
es, die Kante anzupassen, die zum Knoten mit dem größten Gewicht verläuft. Beide
Wege haben den gleichen Aufwand und bringen bei der Erstellung des Teilgraphen
keine Vor- oder Nachteile. Durch Weglassen nicht benötigter Kanten verringert sich
jedoch die Laufzeit von Bellman-Ford auf den Teilgraphen (siehe Abschnitt 3.5).
Eine Anpassung der restlichen Knotengewichte des Stranges im Constraint
Graph ist nicht notwendig, da es sich beim nächst vorherigen Objekt um den
Startknoten v0 handelt. Wie bereits erwähnt, stehen die kürzesten Pfade und die
absoluten Ausgabezeiten im direkten Zusammenhang. Indem das kleinste Knotengewicht von den Knotengewichten subtrahiert wird, erfolgt eine Verschiebung des
Nullpunktes der Zeitachse auf den Startzeitpunkt des ersten Objektes. Da die Knotengewichte und insbesondere das kleinste Knotengewicht durch den Korrekturwert
angepasst wurden, kann nun die Berechnung der korrekten positiven Ausgabezeiten
erfolgen. Der Korrekturwert wird somit implizit auch auf die Objekte angewendet,
deren Knotengewichte unverändert geblieben sind. Um diesen Sachverhalt zu verdeutlichen, zeigt Abbildung 5.16 sowohl die aktuellen Ausgabezeiten und neuen
Knotengewichte als auch die alten Knotengewichte. Die Zeiten aufgrund des aktu-
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.3. OPTIMIERUNGEN
61
end(o1)
-20
end(o2)
-47
-20
-20
v0
15
-15
-5
25
-25
-20
-62
st(o1)
-45
-20
st(o2)
Abbildung 5.13: Angepasster Teilgraph Stranganfang vor Bellman - Ford
end(o1)
-20
end(o2)
-50
-20
-20
v0
15
-15
-5
25
-25
-20
-65
-45
st(o1)
st(o2)
-20
Abbildung 5.14: Angepasster Teilgraph Stranganfang nach Bellman - Ford
Inv.-Nr.: 2005-05-23/052/IN98/2254
62
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
0
0
0
end(o1)
end(o4)
end(o3)
end(o2)
-50
-5
-20
0
-15
0
v0
15
-15
-1
-25
25
-5
-20
20
-5
10
-10
0
-65
-3
-45
st(o1)
st(o2)
0
0
-35
-10
st(o3)
st(o4)
0
Abbildung 5.15: Constraint Graph nach Bellman - Ford
o3
o1
o2
o4
0
15 20
30
45 50 55
65
-65
-50 -45
-35
-20 -15 -10
0
Knotengewichte neu
-35
-20 -15 -10
0
Knotengewichte alt
-62
-47 -45
Zeit
Abbildung 5.16: Ausgabeschedule
ellen Constraint Graph (Abbildung 5.15) lauten wie folgt:
st(o1 ) = 0, end(o1 ) = 15,
st(o2 ) = 20, end(o2 ) = 45,
st(o3 ) = 30, end(o3 ) = 50,
st(o4 ) = 55, end(o4 ) = 65.
5.3.3
Änderung einer Bedingung in der Mitte eines Stranges
Im dritten Fall wird wieder vom ursprünglichen Beispielgraphen ausgegangen. Die
geänderte Relation AR2 befindet sich in der Mitte vom Strang: o2 overlaps(15,5)
o3 (vorher: o2 overlaps(3,5) o3 ). Es werden die Vorgehensweisen aus den beiden
letzten Abschnitten miteinander kombiniert.
Der Teilgraph wird aus dem Startknoten v0 und den Knoten der Objekte o2 und
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.3. OPTIMIERUNGEN
63
end(o2)
-15
end(o3)
-5
-20
-15
-15
v0
25
-1
-25
20
-20
-15
-15
-45
st(o2)
-35
st(o3)
-15
Abbildung 5.17: Teilgraph Strangmitte vor Bellman - Ford
end(o2)
-15
end(o3)
-5
-25
-15
-15
v0
25
-1
-25
20
-20
-15
-15
-50
st(o2)
-15
-35
st(o3)
Abbildung 5.18: Teilgraph Strangmitte nach Bellman - Ford
o3 mit den betreffenden Kanten gebildet (Abbildung 5.17). Die Gewichte der Kanten ausgehend vom Startknoten v0 werden mit dem Wert −15 von Knoten end(o3 )
angepasst, da es das größte Knotengewicht im Teilgraph ist. Die angepassten Kanten sind in der Abbildung wieder gestrichelt dargestellt. Das Kantengewicht der
Kante zwischen st(o3 ) und st(o2 ) resultiert aus der geänderten Bedingung.
Nach der Ausführung von Bellman - Ford (Abbildung 5.18) erfolgt im Constraint Graph die Weitergabe des Korrekturwertes von −5 zum Vorgängerobjekt in
Richtung v0 . Er ergibt sich aus der Differenz der neuen und alten Knotengewichte
von Objekt o2 . Anschließend kann die Berechnung des Gesamtschedule anhand des
korrigierten gesamten Graphen (Abbildung 5.18) erfolgen. Die gültigen Zeiten sind:
Inv.-Nr.: 2005-05-23/052/IN98/2254
64
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
0
0
0
end(o1)
end(o4)
end(o3)
end(o2)
-52
-5
-25
0
-15
0
v0
15
-15
-2
25
-1
-25
-20
20
-5
10
-10
0
-67
-15
-50
st(o1)
st(o2)
0
0
-35
-10
st(o3)
st(o4)
0
Abbildung 5.19: Constraint Graph nach Bellman - Ford
o3
o1
o2
o4
0
15 17
32
42
52 57
-67
-52 -50
-35
-25
-15 -10
67 Zeit
0 Knotengewichte
Abbildung 5.20: Ausgabeschedule
st(o1 ) = 0, end(o1 ) = 15,
st(o2 ) = 17, end(o2 ) = 42,
st(o3 ) = 32, end(o3 ) = 52,
st(o4 ) = 57, end(o4 ) = 67.
Wie erwartet haben sich nur die Werte der Objekte o3 und o4 verändert (Abbildung 5.20).
5.4
Änderung der Objektdauer
Die Scheduleberechnung nach einer Änderung der Dauer eines Objektes ist weniger
aufwendig als bei normalen“ Allen-Relationen. Da nur ein Objekt betroffen ist,
”
muss nur ein einzelnes überprüft werden. Wie bei der Änderung einer Bedingung
ist es auch bei der Dauer wichtig, an welcher Position sich das betreffende Objekt im
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.4. ÄNDERUNG DER OBJEKTDAUER
65
0
0
0
end(o1)
end(o4)
end(o3)
end(o2)
-57
-5
-30
0
-15
0
v0
15
-15
-1
-25
25
-2
30
-30
-5
10
-10
0
-72
-3
-55
st(o1)
st(o2)
0
0
-45
-10
st(o3)
st(o4)
0
Abbildung 5.21: Constraint Graph nach Bellman - Ford
o3
o1
o2
o4
0
15 17
27
42
-72
-57 -55
-45
-30
57 62
-15 -10
72 Zeit
0
Knotengewichte
Abbildung 5.22: Ausgabeschedule
Graph befindet. Die restlichen Objekte des gesamten Graphen werden anschließend
wieder explizit durch den Korrekturwert oder implizit durch die Berechnung der
Ausgabezeiten mit dem kleinsten Knotengewicht im gesamten Graphen angepasst.
Zur Veranschaulichung wird die Dauer von Objekt o3 von 20 auf 30 Zeiteinheiten
vergrößert.
Die Erstellung eines Teilgraphen ist nicht erforderlich, da der Korrekturwert
(-10) aus der Differenz zwischen der neuen und der alten Objektdauer berechnet
werden kann. Mit diesem Wert werden alle Knotengewichte bis zum Startknoten
v0 angepasst. Der so erhaltene korrekte Constraint Graph ist in Abbildung 5.21 zu
sehen. Der Ausgabeschedule (Abbildung 5.22) lautet wie folgt :
st(o1 ) = 0, end(o1 ) = 15,
st(o2 ) = 17, end(o2 ) = 42,
st(o3 ) = 27, end(o3 ) = 57,
st(o4 ) = 62, end(o4 ) = 72.
Diese einfache Methode der Scheduleanpassung kann nur verwendet werden,
Inv.-Nr.: 2005-05-23/052/IN98/2254
66
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
o5
AR4
v0
o1
AR1
o2
AR2
o3
AR3
o4
Abbildung 5.23: Beziehungsgraph mit zwei Strängen
wenn das betroffene Objekt nicht mit einer inversen Relation in Beziehung steht.
Die Einschränkung, dass die Optimierungen nicht in Verbindung mit inversen Relationen angewendet werden dürfen, wurde schon in Abschnitt 5.3 festgestellt.
5.5
Graphen mit mehreren Strängen
Die bisher vorgestellten Optimierungen bei der Scheduleberechnung gehen von einer
einfachen Struktur des Beziehungsgraphen aus. Neben der Forderung eines Baumes wurde davon ausgegangen, dass es sich beim gesamten Projekt nur um einen
Strang handelt (siehe Abbildung 3.12). Ist der Beziehungsgraph verzweigt (Abbildungen 3.13 oder 3.14), besteht also aus mehreren Strängen bzw. Teilbäumen, ist
das einfache Anpassen der Knotengewichte in Richtung des Startknotens v0 nicht
mehr ausreichend.
Zur Veranschaulichung wird das Beispielprojekt zunächst um ein Objekt und
eine Bedingung erweitert. Objekt o5 mit einer Dauer von 30 Zeiteinheiten (o5 duration(30)) soll 10 Zeiteinheiten nach Objekt o1 erscheinen. Die Allen - Relation
AR4 lautet wie folgt: o1 before(10) o5 .
Es handelt sich um eine als sicher klassifizierte Allen-Relation, ein Konsistenzcheck ist nicht notwendig. Der zugehörige Beziehungsgraph (Abbildung 5.23) besteht jetzt aus einem langen (3 Objekte) und einem kurzen (1 Objekt) Strang,
welche jeweils das Objekt o1 als Wurzel haben.
Der so entstandene Constraint Graph (Abbildung 5.24) ist zwar konsistent, aber
zur Berechnung des Schedule unvollständig. Voraussetzung für die Berechnung ist
ein Graph, bei dem für alle Knoten die kürzesten Pfade berechnet sind. Da für
das neue Objekt o5 kein Check mit Bellman - Ford ausgeführt wurde, müssen die
fehlenden kürzesten Pfade nachträglich noch bestimmt werden.
Dies geschieht mit einem Teilgraph. Objekt o5 und Allen-Relation AR4 wurden
hinzugefügt, zählen also als Veränderung. Der Teilgraph wird somit aus Objekt
o1 , o5 und AR4 gebildet. Abbildung 5.25 zeigt den Teilgraph nach Bellman-Ford.
Durch die hinzugefügten Relationen stimmen die Knotengewichte von Objekt o1
mit den ursprünglichen Werten nicht mehr überein.
Die alten Werte für den Start- und Endknoten von Objekt o1 (-62 bzw. -47,
Abbildung 5.2) wurden unter Berücksichtigung des längeren Stranges berechnet,
die neuen (-55 und -40, Abbildung 5.25) aber nur mit dem hinzugefügten kürzeren
Strang. Der Wert des Endknoten gibt indirekt die relative Zeit an, welche die
nachfolgenden Objekte benötigen um ausgegeben zu werden. Das Knotengewicht
von -40 von end(o1 ) für den kürzeren Strang ergibt sich aus dem Knotengewicht
von st(o5 ) (-30) und der before - Relation (-10, Kante von st(o5 ) nach end(o1 )),
insgesamt also 40 ZE. Respektive ergeben sich 47 ZE für den längeren Strang
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.5. GRAPHEN MIT MEHREREN STRÄNGEN
67
end(o5)
-30
30
0
0
st(o5)
-10
0
0
end(o1)
0
end(o4)
end(o3)
end(o2)
-47
-5
-20
0
-15
0
v0
-15
15
-1
-25
25
-2
-20
20
-5
10
-10
0
-62
st(o1)
-3
-45
st(o2)
0
0
-35
-10
st(o3)
st(o4)
0
Abbildung 5.24: Constraint Graph mit zwei Strängen
end(o1)
0
end(o5)
-40
0
0
v0
15
-15
-10
30
-30
0
-55
st(o1)
-30
0
st(o5)
Abbildung 5.25: Teilgraph des neuen Stranges
Inv.-Nr.: 2005-05-23/052/IN98/2254
68
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
o5
o2
o1
0
-55
o3
10 15 20 25
o4
35 40 45
55
-45 -40 -35 -30 -20 -15 -10
0
Zeit
Knotengewichte
Abbildung 5.26: Falsch berechneter Schedule
kurzer Strang
o1
langer Strang
0
15
-62
-47
55
-7
62
0
Zeit
Knotengewichte
Abbildung 5.27: Zeitbedarf der beiden Stränge
(Objekte o2 , o3 , o4 ) durch die Summe von st(o2 ) (-45) und der before - Relation
zwischen o1 und o2 (-2).
Nimmt man die größeren Knotengewichte (entspricht der kleineren Strangdauer, da der Betrag gebildet wird) als Basis für die Scheduleberechnung, erhält man
einen inkorrekten Schedule (Abbildung 5.26). Der von der before - Relation zwischen Objekt o1 und o5 geforderter Abstand von 10 ZE ist noch korrekt, da bei
der Berechnung die Werte für diesen (kürzeren) Strang benutzt wurden. Jedoch
befindet sich Objekt o2 nicht mehr die geforderten mindestens 10 ZE nach Objekt
o1 .
Abbildung 5.27 zeigt den Zeitbedarf beider Stränge im Diagramm. Der kürzere, rezessive Strang benötigt 40 ZE, der längere 47 ZE. Voraussetzung für die
Berechnung sind die korrekt berechneten kürzesten Pfade und die Bestimmung des
kleinsten Knotengewichtes. Ein Strang mit einem kürzeren Pfad hat einen höheren
Zeitbedarf zur Folge und umgekehrt. Nimmt man die Knotengewichte des kürzeren
Stranges, sind die kürzesten Pfade zu den Objektknoten von o1 falsch, da über
den längeren Strang mit kleineren Knotengewichten kürzere Pfade gefunden werden können. Also sind die Knotengewichte von Objekt o1 unter Berücksichtigung
des längeren, dominanten Stranges mit den kleineren Knotengewichten die richtige
Wahl.
Der komplette Constraint Graph mit korrekten Knotengewichten ist in Abbil-
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.5. GRAPHEN MIT MEHREREN STRÄNGEN
69
end(o5)
0
30
-30
0
-30
0
st(o5)
-10
0
0
end(o1)
0
end(o4)
end(o3)
end(o2)
-47
-5
-20
0
-15
0
v0
15
-15
25
-2
-1
-25
20
-20
-5
10
-10
0
-62
st(o1)
-3
-45
st(o2)
0
0
-35
-10
st(o3)
st(o4)
0
Abbildung 5.28: Constraint Graph nach Bellman - Ford
dung 5.28 zu sehen, die graphische Darstellung des Schedule in Abbildung 5.29.
Die berechneten Ausgabezeiten lauten:
st(o1 ) = 0, end(o1 ) = 15,
st(o2 ) = 17, end(o2 ) = 42,
st(o3 ) = 27, end(o3 ) = 47,
st(o4 ) = 52, end(o4 ) = 62,
st(o5 ) = 32, end(o5 ) = 62.
Der Constraint Graph dient nun als Ausgangspunkt für die folgenden Erklärungen zur Berechnung der Ausgabezeiten. Zur Veranschaulichung der Scheduleberechnung in Constraint Graphen mit mehreren Strängen wird die Dauer von Objekt
o2 von 25 auf 30 erhöht. Der Korrekturwert, berechnet aus der Differenz der neuen
und alten Dauer, ist -5 und wird nach dem im vorherigen Abschnitt vorgestellten
Schema an Objekt o1 weitergeben.
o1 ist die Wurzel beider Stränge. Es muss erneut geprüft werden, welcher Strang
der längere ist, um die entsprechenden Knotengewiche zu bestimmen. Die Dauer
Inv.-Nr.: 2005-05-23/052/IN98/2254
70
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
o5
o3
o1
o2
o4
0
15 17
27 32
42 47 52
62
-62
-47 -45
-35 -30
-20 -15 -10
0
Zeit
Knotengewichte
Abbildung 5.29: Korrekter Ausgabeschedule
des eben kürzeren Stranges hat sich nicht geändert. Der ursprünglich längere Strang
ist durch die Änderung der Bedingung länger geworden und er bleibt dominant.
Der korrekte Constraint Graph ist in Abbildung 5.30 zu sehen. Die dazugehörigen
Ausgabezeiten lauten:
st(o1 ) = 0, end(o1 ) = 15,
st(o2 ) = 17, end(o2 ) = 47,
st(o3 ) = 32, end(o3 ) = 52,
st(o4 ) = 57, end(o4 ) = 67,
st(o5 ) = 37, end(o5 ) = 67.
Die Knotengewichte von Objekt o5 bleiben unverändert. Die Ausgabezeit wird
durch das veränderte kleinste Knotenewicht im Graphen angepasst (Abbildung
5.31). Eine Änderung der Knotengewichte von Objekt o1 hat also keine direkten
Auswirkungen auf die Knotengewichte von Objekt o5 . Das hängt damit zusammen, dass es durch die before - Relation keine Kante von Objekt o1 , der Wurzel
des Stranges, nach o5 gibt. Existiert eine solche Kante und ist der betreffende
Teilstrang kürzer, müssen Änderungen der Knotengewichte in Form eines neuen
Korrekturwertes weitergegeben werden.
Zur Veranschaulichung wird die hinzugefügte before - Relation in ein overlaps
geändert. Die Relation lautet: o1 overlaps(5,10) o5 . Da es sich jetzt um eine als
unsicher klassifizierte Relation handelt, wird ein Teilgraph aus Objekt o1 und o5
für einen Konsistenzcheck gebildet. Bellman-Ford liefert ein mögliches Ergebnis
der Knotengewichte für Objekt o1 (Abbildung 5.32). Da aber diese Werte (-20,
-32) größer sind als die des längeren Stranges (-47, -62), dieser Strang also eine
kleinere Dauer hat, werden die Werte des längeren Stranges der Objekte o2 bis o4
genommen.
Die Knoten von Objekt o1 erhalten die entsprechenden Gewichte (-47, -62).
Zusätzlich werden beide Kanten vom Startknoten v0 zu o1 mit den jeweiligen Gewichten der Knoten gesetzt. Der Teilgraph verhält sich jetzt so, als wäre der andere,
dominante Strang vorhanden.
Im Unterschied zum vorherigen Beispiel der before - Relation, existiert jetzt
eine Kante zwischen den Objekten o1 und o5 : von end(o1 ) nach st(o5 ) (Abbildung
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.5. GRAPHEN MIT MEHREREN STRÄNGEN
71
end(o5)
0
-30
30
0
-30
0
st(o5)
-10
0
0
end(o1)
0
end(o4)
end(o3)
end(o2)
-52
-5
-20
0
-15
0
v0
15
-15
-1
-30
30
-2
20
-20
-5
10
-10
0
-67
st(o1)
-3
-50
st(o2)
0
0
-35
-10
st(o3)
st(o4)
0
Abbildung 5.30: Constraint Graph nach Bellman - Ford
o5
o3
o1
o2
o4
0
15 17
32 37
47 52 57
-67
-52 -50
-35 -30
-20 -15 -10
67 Zeit
0 Knotengewichte
Abbildung 5.31: Korrekter Ausgabeschedule
Inv.-Nr.: 2005-05-23/052/IN98/2254
72
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
end(o1)
-20
0
end(o5)
-10
0
0
v0
15
-15
-1
30
-30
0
-35
-5
-30
st(o1)
0
st(o5)
Abbildung 5.32: Teilgraph des neuen Stranges
end(o1)
-47
0
end(o5)
-10
-18
-47
v0
15
-15
-1
30
-30
-62
-62
-5
-48
st(o1)
0
st(o5)
Abbildung 5.33: Teilgraph des neuen Stranges mit angepassten Kantengewichten
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.5. GRAPHEN MIT MEHREREN STRÄNGEN
73
end(o5)
-18
30
-30
0
-10
-48
0
st(o5)
-1
0
0
end(o1)
0
end(o4)
end(o3)
end(o2)
-47
-5
-20
0
-15
-5
0
v0
15
-15
25
-2
-1
-25
20
-20
-5
10
-10
0
-62
st(o1)
-3
-45
st(o2)
0
0
-35
-10
st(o3)
st(o4)
0
Abbildung 5.34: Constraint Graph mit zwei Strängen nach Bellman - Ford
5.34). Durch diese Kante und den angepassten Kanten von v0 zu den o1 -Knoten
verläuft der Weg der kürzesten Pfade zu den Knoten von Objekt o5 jetzt nicht
mehr von v0 direkt zu o5 , sondern über das Objekt o1 . Bellman-Ford führt jetzt zu
korrekten Ergebnissen (Abbildung 5.33) und die Dauer des kürzeren Stranges bzw.
Objekt o5 wurde angepasst.
Durch die Rückkante können kürzere Pfade zu den Knoten von Objekt o5 gefunden werden, falls sich die Werte für Objekt o1 ändern. Dadurch kann ein kurzer
Strang zu einem längeren werden und umgekehrt. Ein Beispiel dazu folgt weiter
unten. Der komplette Constraint Graph (Abbildung 5.34) liefert folgenden Ausgabeschedule (Abbildung 5.35):
st(o1 ) = 0, end(o1 ) = 15,
st(o2 ) = 17, end(o2 ) = 42,
st(o3 ) = 27, end(o3 ) = 47,
st(o4 ) = 52, end(o4 ) = 62,
st(o5 ) = 14, end(o5 ) = 44.
Inv.-Nr.: 2005-05-23/052/IN98/2254
74
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
o5
o3
o1
o2
o4
0
15 17
14
27 32
42 47 52
44
62
-62
-47 -45
-48
-35 -30
-20 -15 -10
-18
0
Zeit
Knotengewichte
Abbildung 5.35: Ausgabeschedule
o5
AR4
v0
o1
AR1
o2
AR2
o3
AR3
o4
Abbildung 5.36: Anpassung der Kantengewichte durch den Korrekturwert
Werden Bedingungen oder Objektdauer geändert, müssen die Korrekturwerte
über die Vorgängerobjekte in Richtung der Wurzel eines Stranges weitergegeben
und die Knotengewichte eines kürzeren Stranges von dieser Wurzel aus angepasst
werden. Diese Weitergabe an den Teilbaum ist aber nur notwendig, wenn eine Kante
vom einen Wurzelknoten in die entsprechende Richtung existiert.
Ist dies der Fall, bekommen die Knoten des Wurzelobjektes die entsprechenden
Gewichte des längsteren Stranges. Anhand der neuen und alten Knotengewichte
wird ein neuer Korrekturwert berechnet, der bis zum Ende des Stranges bzw. Teilbaum weiter gegeben wird. Abbildung 5.36 zeigt noch einmal den Beziehungsgraph
des Beispiels und welche Objekte angepasst wurden. Die gestrichelten Pfeile zeigen
das Weitergeben des Korrekturwertes zur Strangwurzel von o2 zu o1 und an den
anderen Strang über die Rückkante der overlaps - Relation von o1 zu o5 .
Durch Veränderung von Bedingungen oder Objektdauer ist es möglich, dass ein
rezessiver (kürzer) Strang dominant (länger) wird und umgekehrt. Wird zum Beispiel die Dauer von Objekt o5 auf 90 Zeiteinheiten erhöht, besitzt dieser ehemals
rezessive Strang von Objekt o1 aus gesehen eine Länge von 95 ZE (Knotengewicht
st(o1 )=-95, siehe Abbildung 5.37) und wird zum dominanten Strang. Der nun rezessive Strang der Objekte o2 bis o4 hat eine Länge von 62 ZE (Knotengewicht
st(o1 )=-62, siehe Abbildung 5.34). Im Teilgraph werden Objekt o1 die entsprechenden Knotengewichte zugewiesen (-80, -92). Die Gewichte der Kanten ausgehend von
v0 müssen nicht angepasst werden, da die geänderte Bedingung nicht in einem rezessiven Strang liegt und in diesem Schritt kein Korrekturwert an Nachfolgeobjekte
weitergegeben wird.
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.5. GRAPHEN MIT MEHREREN STRÄNGEN
end(o1)
0
75
end(o5)
-10
0
-1
100 -100
-95
-5
-100
st(o1)
0
st(o5)
-80
0
v0
15
-15
0
Abbildung 5.37: Teilgraph des dominanten Stranges mit angepassten Knotengewichten
Da in der before - Relation von o1 zu o2 keine Rückkante existiert, ist eine Anpassung der Knotengewichte des rezessiven Stranges nicht erforderlich. Abbildung
5.38 zeigt den kompletten Constraint Graph. Der Ausgabeschedule (Abbildung
5.39) lautet wie folgt:
st(o1 ) = 0, end(o1 ) = 15,
st(o2 ) = 50, end(o2 ) = 75,
st(o3 ) = 60, end(o3 ) = 80,
st(o4 ) = 85, end(o4 ) = 95,
st(o5 ) = 5, end(o5 ) = 95.
Die Weitergabe bzw. Anpassung der kürzesten Pfade an einem Strang ausgehend von der Wurzel kann zu Knotengewichten c > 0 führen. Solche Werte stehen
im Widerspruch zu den mit Null gewichteten Kanten, die im Constraint Graphen
vom Startknoten v0 aus zu jeden anderen Knoten gehen. Um diesen Widerspruch
aufzulösen, müssen am Ende alle Knotengewichte im gesamten Graphen überprüft
werden. Existieren ein oder mehrere Gewichte c > 0, wird der größte Wert festgestellt und von allen Knotengewichten subtrahiert. Mit diesem Test ist ein korrekter
Schedule gewährleistet.
Die Methode zum Anpassen der Knotengewichte zur Strangwurzel bzw. an einen
abzweigenden Strang muss auch auf komplexere Projekte angewendet werden. Verändert man die Dauer eines Objektes aus dem Beispiel-Beziehungsgraphen aus
Abbildung 3.14 (gestricheltes Objekt in Abbildung 5.40), müssen abhängig von
der Graphstruktur große Teile des Graphen angepasst werden. Das Weitergeben
der Korrekturwerte und die Bewertung, ob ein Strang rezessiv oder dominant ist,
muss rekursiv bis zur Wurzel des gesamten Teilbaumes erfolgen. Hier ist darauf zu
achten, dass bereits besuchte Stränge nicht mehrfach durchlaufen werden.
Der zweite Strang in Abbildung 5.40, welcher vom Startknoten v0 nach rechts
unten abzweigt, ist von den Änderungen nicht betroffen. Im Gegensatz zu den vorangegangenen Beispielen hat er als Wurzel kein Medienobjekt, sondern den Startknoten v0 . Er bildet ein Art Unterprojekt, weil kein Objekt aus diesem Strang mit
Inv.-Nr.: 2005-05-23/052/IN98/2254
76
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
end(o5)
0
100 -100
0
-10
-90
0
st(o5)
-1
0
0
end(o1)
0
end(o4)
end(o3)
end(o2)
-80
-5
-20
0
-15
-5
0
v0
-15
15
-1
-25
25
-2
-20
20
-5
10
-10
0
-95
st(o1)
-3
-45
st(o2)
0
0
-35
-10
st(o3)
st(o4)
0
Abbildung 5.38: Constraint Graph nach Bellman - Ford
o5
o3
o1
0
5
-95 -90
o2
15
-80
o4
50
60
75 80 85
-45
-35
-20 -15 -10
95 Zeit
0
Knotengewichte
Abbildung 5.39: Korrekter Ausgabeschedule
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.6. ZUSAMMENFASSUNG
77
v0
Abbildung 5.40: Beziehungsgraph mit mehreren Strängen
einem Objekt des anderen Stranges in Beziehung steht. Die Scheduleberechnung
ist somit unabhängig und kann auch einzeln erfolgen.
In der Abbildung ist auch erkennbar, dass der Aufwand zur Anpassung der
Knotengewichte direkt von der Lage des zu änderten Objektes bzw. der Relation
im Graphen abhängt. Ein im Schedule bzw. im Graphen weiter hinten liegendes
Objekt ist aufwendiger, als zum Beispiel ein Startobjekt am Anfang eines Projektes.
Neben der Position der Änderung im Graphen hat auch die Graphstruktur Einfluss auf die Laufzeit der Scheduleberechnung. Ein Projekt mit 10 Einzelsträngen,
die jeweils vom Startknoten v0 ausgehen, lässt sich schneller berechnen, als wenn
die Stränge ein gemeinsames Medienobjekt als Startpunkt hätten. In Abschnitt 6.4
werden die Unterschiede verdeutlicht.
5.6
Zusammenfassung
Die Berechnung des Ausgabeschedule erweist sich als schwieriger als die Konsistenzprüfung von Bedingungen. Das liegt zum einen daran, dass einzelne Änderungen
Auswirkungen auf den gesamten Schedule haben können. Beim Konsistenzcheck
waren die Auswirkungen lokaler Änderungen auch nur auf diesen einen lokalen
Bereich beschränkt.
Ein weiterer Unterschied ist, dass veränderte Objekte oder Relationen für einen
Konsistenzcheck gesammelt“ werden können. Anschließend wird aus dieser Menge
”
ein Teilgraph gebildet und mit Bellman - Ford geprüft. Die Schedulebrechnung geht
aber stets von einen konsistenten Constraint Graph mit korrekten Knotengewichten
aus. D. h. nach jeder Änderung müssen die Knotengewichte entsprechend angepasst
werden, damit für alle Knoten die kürzesten Pfade vorliegen.
Der Algorithmus zum Anpassen der kürzesten Pfade bei Änderung einer Bedingung ist in Abbildung 5.41 dargestellt. Als erstes wird ein Teilgraph nach den
Algorithmus der Abbildung 3.9 erstellt (1). Durch das Anpassen der Knotengewichte von v0 wird der gesamte Constraint Graph für den Teilgraphen simuliert
(2). Dazu wird das größte Knotengewicht bestimmt (2.1, Abbildung 5.42) und die
Gewichte aller ausgehenden Kanten von v0 auf diesen Wert gesetzt (2.2 - 2.3). Auf
dem angepassten Teilgraphen wird Bellman-Ford ausgeführt und man erhält einen
neuen Teilgraph mit den korrekten kürzesten Pfaden (3). Anhand des alten und
neuen Graphen wird der Korrekturwert der Weglängen bestimmt (4). Dieser Wert
ist die Differenz aus dem kleinsten Knotengewicht des ursprünglichen Teilgraphen
(4.1, Abbildung 5.43) und dem Knotengewicht des entsprechenden Knotens im
Inv.-Nr.: 2005-05-23/052/IN98/2254
78
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
neuen Teilgraph (4.2 - 4.4). Der Korrekturwert wird nun an die Vorgängerobjekte
weiter gegeben. Die Identifizierung erfolgt über den Beziehungsgraphen (5).
Handelt es sich bei dem Vorgängerobjekt um eine Wurzel des aktuellen Strang
bzw. Teilbaum (6), werden die Knotengewichte des Wurzelobjektes neu bestimmt
(Abbildung 5.44). Für die Überprüfung werden Teilgraphen erstellt. Sie bestehen
jeweils aus dem Wurzelobjekt und dem direkten Nachfolger (7.1 - 7.2). Auf diese
Art kann jeder abzweigende Strang betrachtet werden. Durch die Anpassung der
Kantengewichte von v0 (7.3) ist sichergestellt, dass die korrekten Knotengewichte
mit Bellman-Ford berechnet werden (7.4). Nun wird der Strang mit der längsten
Dauer festgestellt, also der Teilgraph mit den kleinsten Knotengewichten bzw. Pfaden (7.5 - 7.6). Anhand dieser Werte wird ein neuer Korrekturwert bestimmt und
das Nachfolgeobjekt dient als neue Wurzel (7.7. - 7.8). Nun wird geprüft, ob der
längste Teilbaum in diesem Durchlauf zur Scheduleberechnung noch nicht angepasst wurde5 (7.11). Ist dies der Fall, besitzt er schon die korrekten Knotengewichte, der Korrekturwert wäre 0. Falls nicht, werden die Knotengewichte der alten und
neuen Wurzel angepasst (7.12 - 7.13) und der Korrekturwert an alle Objekte des
Teilgraphen bzw. Stranges weitergegeben6 (7.14 - 7.15).
Hat es sich beim Vorgängerobjekt nicht um ein Wurzelobjekt gehandelt (9),
werden dessen Knotengewichte mit den ursprünglichen Korrekturwert angepasst
und das Objekt als besucht markiert (10 - 11). Auf diese Weise werden alle Objektknoten bis zum Startknoten v0 abgearbeitet (14). Zum Schluss wird das größte
Knotengewicht im gesamten Constraint Graphen gesucht (15). Ist es größer als 0,
wird dieser Wert von allen Knotengewichten subtrahiert, um die Konsistenz der
kürzesten Pfade wieder herzustellen (16 - 18).
Die Implementierung im DBMS erfolgt analog zur in Abschnitt 3.7 vorgestellten Methode. Die konkrete Realisierung wurde nicht in einem Datenbanksystem
durchgeführt, sondern durch ein Java-Programm, was lokal auf einem PC die Berechnungen ausführt. Das folgende Kapitel bewertet die in diesem und in Kapiteln
3 und 4 vorgestellten Algorithmen.
5 Ein expliziter Test, ob eine Rückkante vom alten zum neuen Wurzelobjekt existiert (Abschnitt 5.5) ist nicht erforderlich, da dies durch die Erstellung der einzelnen Teilgraphen schon
berücksichtigt ist.
6 Falls sich dieser Teilgraph bzw. Strang weiter aufteilt, erfolgt keine Neuberechnung des Korrekturwertes an den erreichten Wurzelobjekten.
Inv.-Nr.: 2005-05-23/052/IN98/2254
5.6. ZUSAMMENFASSUNG
79
Algorithm:
shortestP ath(INPUT condition)
Input:
Condition condition
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
partialGraph = buildPartialGraph(condition)
partialGraph = correctEdgeValues(partialGraph)
partialGraphN ew = bellmanFord(partialGraph)
dif f = getDiffValue(partialGraph, partialGraphN ew)
repeat parentObject = RelationGraph.getParentObject(partialGraph) do {
if parentObject = rootOfTree(RelationGraph) {
correctTree(parentObject, dif f )
}
else {
correctNodeWeight(parentObject, dif f )
parentObject.setV isited
}
}
until parentObject = startNodeV0
value = getLargestNodeWeight(constraintGraph)
if value > 0 {
for all constraintGraph.nodes do{
node.value = node.value - value
}
}
Abbildung 5.41: Algorithmus zur Berechnung der kürzesten Pfade bei Änderung
einer Bedingung
Algorithm:
correctEdgeV alues(INPUT partialGraph, OUTPUT partialGraph)
Input:
Graph partialGraph
Output:
Graph partialGraph
2.1
2.2
2.3
2.4
2.5
value = getLargestNodeWeight(partialGraph)
for all startN ode.outgoingEgdes do{
Edge.value = value
}
return partialGraph
Abbildung 5.42: Algorithmus zum Anpassen der Kantengewichte der ausgehenden
Kanten vom Startknoten v0
Inv.-Nr.: 2005-05-23/052/IN98/2254
80
KAPITEL 5. BERECHNUNG DES AUSGABESCHEDULE
Algorithm:
getDiffValue(INPUT partialGraph, partialGraphN ew, OUTPUT dif f )
Input:
Graph partialGraph
Graph partialGraphN ew
Output:
Integer dif f
4.1
4.2
4.3
4.4
4.5
valueOld = getSmallestNodeWeight(partialGraph)
node = getNode(partialGraph, valueOld)
valueN ew = getNodeWeight(partialGraphN ew, node)
dif f = valueOld - valueN ew
return dif f
Abbildung 5.43: Algorithmus zur Berechnung des Korrekturwertes vom Teilgraph
Algorithm:
correctTree(INPUT parentObject)
Input:
Node parentObject
7.1 for all parentObject.Childs do{
7.2
partialGraphT emp = buildPartialGraph(
RelationGraph.getConditionBetween(parentObject, parentObject.Child)
7.3
correctEdgeValues(partialGraphT emp)
7.4
partialGraphT empN ew = bellmanFord(partialGraphT emp)
7.5
if getSmallestNodeWeight(partialGraphT empN ew) < lowestN odeW eight {
7.6
lowestN odeW eight = getSmallestNodeWeight(partialGraphT empN ew)
7.7
newP arentObject = getNode(partialGraph, lowestN odeW eight)
7.8
dif f = getDiffValue(partialGraphT emp, partialGraphT empN ew)
7.9
}
7.10 }
7.11 if newP arentObject is not visited{
7.12
correctNodeWeight(P arentObject, dif f )
7.13
correctNodeWeight(newP arentObject, dif f )
7.14
for all childObject = RelationGraph.getChildObject(newP arentObject) do {
7.15
correctNodeWeight(childObject, dif f )
7.16
}
7.17 }
Abbildung 5.44: Algorithmus zur Berechnung der kürzesten Pfade in Teilbäumen
Inv.-Nr.: 2005-05-23/052/IN98/2254
Kapitel 6
Evaluierung
6.1
Testprojekte und Messmethode
Um die Effizienz des Optimierungsalgorithmus zu bewerten, wurden einige Testprojekte erzeugt (Tabelle 6.1). Sie bestehen aus einer bestimmten Anzahl von Medienobjekten, welche mit zufällig gewählten Allen-Relationen in Beziehung stehen.
Die Duration-Constraints der Objekte zählen als Relation.
Jedes Projekt wird durch eine XML-Datei repräsentiert. Sie beinhaltet pro Objekt jeweils ein Duration-Constraint und zufällig gewählte Allen-Relationen, welche
die Medienobjekte in Beziehung setzen. Das Verhältnis sichere zu unsichere Relationen liegt bei allen Projekten bei ca. 50 %. Die Struktur des (Beziehungs-) Graphen
wurde nicht zufällig gewählt. Die Testprojekte bestehen aus mehreren Strängen
gleicher Länge, die parallel verlaufen und vom Startknoten v0 ausgehen (Abbildung 6.1). Das Projekt P1 mit 50 Objekten beinhaltet zum Beispiel 5 Stränge mit
je 10 Objekten.
Alle Projekte mit dem Zusatz a enthalten gegenüber den ursprünglichen Projekten ein zusätzliches Objekt. Es befindet sich direkt nach dem Startknoten und
steht mit allen Teilsträngen in Beziehung (Abbildung 6.2). Die Projekte bestehen
somit nicht mehr aus unabhängigen Strängen, sondern besitzen ein Hauptobjekt,
auf dem alle anderen Relationen und Objekte aufbauen. Durch diese Erweiterung
Projektname
P1
P2
P3
P4
P5
P1a
P2a
P3a
P4a
P5a
Medienobjekte
50
100
250
500
1000
51
101
251
501
1001
Anzahl
Relationen
95
190
490
980
1975
101
201
501
1001
2001
Knoten
101
201
501
1001
2001
103
203
503
1003
2003
Tabelle 6.1: Testprojekte
Inv.-Nr.: 2005-05-23/052/IN98/2254
Kanten
291
580
1480
2960
5951
304
604
1504
3004
6006
82
KAPITEL 6. EVALUIERUNG
v0
Abbildung 6.1: Struktur der Testprojekte Px
soll die Abhängigkeit der Laufzeit der Scheduleberechnung von der Projekt- bzw.
Graphstruktur gezeigt werden.
Die Anzahl der Knoten |V | pro Projekt ergibt sich aus der Objektanzahl n
(jeweils ein Start- und ein Endknoten) und dem Startknoten v0 :
|V | = 2n + 1
(6.1)
Die Kantenanzahl ist abhängig von den verwendeten Bedingungen. Sie entspricht in etwa dem Dreifachen der Knotenanzahl. Das Produkt beider Werte kann
als Maßstab für die Laufzeit für den Konsistenzcheck gesehen werden, da der Algorithmus von Bellman-Ford eine Komplexität von O (|V | · |E|) besitzt.
Die XML-Dateien der Testprojekte werden mit dem ConstraintManager eingelesen. Das Programm erstellt den dazu gehörigen kompletten Constraint Graph und
führt einen Konsistenzcheck durch. Die Zeit für diesen Test mittels Bellman-Ford
auf dem gesamten Graphen dient als Vergleichswert zur Bewertung der Optimierungen. Anschließend erfolgt die eigentliche Abspeicherung in einer Oracle-Datenbank.
Die Tabellenstrukuren wurden in Abschnitt 2.5.4 besprochen.
An den nun in der Datenbank vorliegenden Projekten werden zufällig Bedingungen ausgewählt und manipuliert. Die Duration-Constraints zählen auch zu den
veränderbaren Bedingungen. Die Anzahl der Änderungen betragen 1, 25, 50 und
100, um Auswirkungen auf die Laufzeit zu untersuchen.
Die Manipulationen werden gesammelt und anschließend in einem Teilgraph gemeinsam überprüft. Bei der Erzeugung des Teilgraphen wird davon ausgegangen,
dass die geänderten Bedingungen bekannt sind und nicht erst durch einen Vergleich
Inv.-Nr.: 2005-05-23/052/IN98/2254
6.1. TESTPROJEKTE UND MESSMETHODE
83
v0
Abbildung 6.2: Struktur der Testprojekte Pxa
mit dem Originalgraphen extrahiert werden müssen. Die in den Diagrammen ersichtlichen Zeiten zum Finden des Teilgraphen“ sagen aus, wie lange es gedauert
”
hat, alle relevanten Objekte und Relationen ausfindig zu machen, die mit der geänderten Relation direkt in Beziehung stehen und demzufolge auf Konsistenz geprüft
werden müssen. Da die geänderte Bedingung bekannt ist, sind diese Zeiten gleichbedeutend mit der Erstellung des zu testenden Teilgraphen.
Der Konsistenzcheck erfolgt noch nicht im DBMS. Analog zur in Abschnitt 2.3.1
vorgestellten Architektur der Integritätssicherung durch die Anwendung wurde ein
Java-Programm erstellt. Die Bedingungen werden aus der Datenbank geladen und
lokal auf einem PC auf Konsistenz überprüft. Ein lokaler Konsistenzcheck ist zur
Bewertung der Algorithmen sinnvoll, da auf diesem Wege die Laufzeit genauer
bestimmt werden kann. Verzögerungen durch die Übertragung der Daten an die
Datenbank können somit ausgeschlossen werden. Abschnitt 6.6 geht auf die Realisierung der Algorithmen direkt im DBMS ein. Dort wird auf die Problematik der
Übertragungszeit zur Speicherung der Bedingungen in der Datenbank eingegangen.
Die kleinste zu messende Zeiteinheit auf dem PC, auf dem die Messungen durchgeführt werden, liegt bei 1 ms. Da sich die gemessenen Zeiten für einzelne Tests
teilweise weit darunter bewegen, werden sie n mal hintereinander ausgeführt. Der
Faktor n bewegt sich abhängig von der Größe des Graphen bzw. des Projektes
zwischen 1 und 10.000.000. Um die Spannweite der Werte visualisieren zu können, sind die Zeiten in den Diagrammen in logarithmischer Darstellung abgebildet.
Des Weiteren werden die Messungen mehrfach hintereinander ausgeführt, um Messungenauigkeiten zu minimieren. Die in den nächsten Abschnitten angegebenen
Messergebnisse wurden normiert und beziehen sich jeweils auf einen Durchlauf, um
einen direkten Vergleich zu ermöglichen.
Die Messungen wurden auf einem PC mit 3 GHz Intel Pentium 4 Prozessor,
Inv.-Nr.: 2005-05-23/052/IN98/2254
84
KAPITEL 6. EVALUIERUNG
1 GB RAM, Suse Linux 9.0 und Java 1.4.2 durchgeführt. Es konnte nicht sicher
gestellt werden, dass der PC exklusiv für die Berechnungen zur Verfügung stand.
Rechenintensive Prozesse liefen aber nicht parallel zu den Messungen. Mögliche
Störfaktoren sind Standard-Tasks des Betriebsystems oder Remote-Logins bzw.
Prozesse von anderen Benutzern. Die Auswirkungen auf die Messung sollten durch
die Durchschnittsbildung minimal sein.
6.2
6.2.1
Optimierung des graphischen Konsistenzcheck
Überprüfung von Änderungen als Teilgraph
Erwartungen
In Kapitel 3 wurde eine Möglichkeit vorgestellt, den Konsistenzcheck mittels Bellman - Ford effizienter zu gestalten. Der angegebene Algorithmus zur Teilgrapherstellung wurde implementiert und an den in Abschnitt 6.1 vorgestellten Projekten
P1 bis P5 getestet.
Durch die zum Teil enorme Verkleinerung des zu testenden Graphen, ist auch
eine dementsprechende Verbesserung der Laufzeit zu erwarten. Interessant ist in
diesem Zusammenhang auch, wie viel Zeit zum Suchen bzw. zur Erstellung des
Teilgraphen benötigt wird. Da der Algorithmus zur Teilgrapherstellung nur von der
Anzahl der Kanten im Beziehungsgraphen anhängig ist und eine lineare Laufzeit
von (O(|E|)) hat, im Gegensatz zu O (|V | · |E|) von Bellman-Ford, ist zu erwarten,
dass diese Zeit wesentlich kleiner ist als der eigentliche Konsistenzcheck.
Ergebnisse
Die Ergebnisse der Messreihen bestätigen die Erwartungen. Abbildung 6.3 zeigt die
gemessenen Zeiten in einem Diagramm mit logarithmischer Darstellung. Um Werte
kleiner Eins zu vermeiden, wurden alle gemessenen Zeiten mit dem Faktor 1000
multipliziert, die Zeiten der Y-Achse sind in ns angegeben. Zu jedem Testprojekt
gibt es 5 Säulen. Die jeweils letzte (schwarz) repräsentiert die benötigte Zeit für
Bellman-Ford auf den gesamten Graphen. Diese Säule gilt als Referenzwert und
ist in den meisten Diagrammen mit angegeben, um die Effizienz der vorgestellten
Algorithmen zu verdeutlichen. Die Säulen 1-4 jedes Projektes zeigen den Zeitbedarf
für 1, 25, 50 und 100 Änderungen bei Anwendung der optimierten Methode aus den
Abschnitten 3.3 und 3.4. Dabei ist jede Säule noch einmal unterteilt in die Zeit für
das Finden bzw. Erstellen des Teilgraphen (dunkelgrau) und den anschließenden
Konsistenzcheck (hellgrau).
Abbildung 6.3 zeigt, dass bei jedem Projekt, unabhängig von der Anzahl der
veränderten Bedingungen, der Test des Teilgraphen einen enormen Laufzeitgewinn
zur Folge hat. Die Kosten zur Erstellung des Teilgraphen sind weitaus geringer als
der eigentliche Test des Graphen. Sie wachsen mit größer werdenden Projekten,
da mehr Bedingungen durchsucht werden müssen. Der Anstieg ist aber linear im
Gegensatz zur expotentiellen Steigerung des Tests mit Bellman - Ford. In Anbetracht der riesigen Unterschiede der beiden Zeiten (Faktor 103 bis 109 ), können die
Kosten zur Erstellung des Teilgraphen vernachlässigt werden.
Durch die logarithmische Darstellung ist der Zeitgewinn auf den ersten Blick
nicht deutlich sichtbar. Der im Diagramm geringe Unterschied bei Projekt P1 zwischen der Säule für den kompletten Graphen und 100 Änderungen“ bedeutet, dass
”
Inv.-Nr.: 2005-05-23/052/IN98/2254
6.2. OPTIMIERUNG DES GRAPHISCHEN KONSISTENZCHECK
Zeit [ns]
85
Test Teilgraph mit je
1/25/50/100 Manipulationen
Finden des Teilgraphen
1010
Test gesamter Graph
108
106
104
102
0
P1
P2
P3
P4
P5
Abbildung 6.3: Zeiten für Teilgrapherstellung und Konsistenzcheck durch BellmanFord
Projektname
P1
P2
P3
P4
P5
Anzahl der Änderungen
1
25
50
2 ∗ 104
20
3,6
2 ∗ 105
85
8,2
3 ∗ 106
103
194
2 ∗ 107
104
103
10
7
6 ∗ 10
2 ∗ 10
3 ∗ 106
100
0,6
5,5
31
196
4 ∗ 105
Tabelle 6.2: Faktor, um der die optimierte Methode schneller ist
die optimierte Methode ca. 40 % schneller ist. Zum besseren Verständniss ist in
Tabelle 6.2 der Faktor dargestellt, um den der optimierte Algorithmus gegenüber
dem Check des gesamten Graphen schneller ist.
Die Messergebnisse der Projekte P1a bis P5a liegen im selben Bereich und
unterscheiden sich nur um 2 - 6% von den ursprünglichen Projekten P1 bis P5.
Um die enormen Laufzeiten bei größeren Projekten zu verdeutlichen, wurde ein
Projekt mit 5000 Objekten generiert. Der Konsistenzcheck des gesamten Graphen
mit Bellman-Ford benötigt über 100 Stunden. Wie kann diese Überprüfung auf eine
annehmbare Zeit reduziert werden?
Wie alle anderen Projekte besteht es aus einer bestimmten Anzahl von Strängen, die vom Startknoten v0 ausgehen. Bei diesem Projekt sind es 50 Stränge mit
jeweils 100 Objekten. Die einzelnen Stränge kann man als Unterprojekte betrachten, da sie nicht in Beziehung zueinander stehen. Diese Tatsache ist nicht unbedingt
erforderlich, es bietet sich aber an, das Projekt in diese Unterprojekte zu zerlegen.
Inv.-Nr.: 2005-05-23/052/IN98/2254
86
KAPITEL 6. EVALUIERUNG
Anschließend fügt man jedes Unterprojekt zum gesamten Projekt bzw. Constraint
Graphen hinzu und testet nur die Änderungen auf Konsistenz.
Da es sich um Projekte mit 100 Objekten handelt, werden als Näherung die
Zeiten von Projekt P2 verwendet. Ein Konsistenzcheck für dieses Projekt beträgt
ca. 1 s. Die summierte Zeit für alle 50 Unterprojekte beläuft sich auf 50 s. Das
bedeutet eine enorme Steigerung gegenüber der ursprünglichen Methode. Bei der
Speicherung des Projektes in einer Datenbank und gleichzeitiger Konsistenzprüfung
wird ein realer Wert von ca. 525 s erreicht. Dies ist noch immer um den Faktor 685
schneller als der Test des gesamten Graphen.
Anhand dieser Vorgehensweise kann man bereits vorhandene Projekte zeitsparend in der Datenbank speichern bzw. auf Konsistenz prüfen. An welchen Stellen
die Aufspaltung vorgenommen und in wie viele Stücke das Projekt unterteilt wird,
spielt keine Rolle in Hinblick auf die Konsistenz. Jedes Objekt bzw. Bedingung einzeln hinzuzufügen ist allerdings unvorteilhaft, da der Verbindungsaufbau zur Datenbank, die Übertragung und Speicherung zu viel Zeit in Anspruch nimmt. Diese
Kosten wurden in den Messungen bisher nicht betrachtet. Abschnitt 6.6 bewertet
des Konsistenzcheck in der Datenbank inklusive der Übertragungszeiten.
6.2.2
Reduzierung der Kantenanzahl
Erwartungen
Bei der in Abschnitt 3.5 vorgestellte Methode zur Reduzierung der Kantenanzahl
des zu testenden Teilgraphen sind geringere Laufzeitgewinne zu erwarten. Die Knotenanzahl bleibt gleich, d.h. die Komplexität des Graphen wird nicht in den Größenordnungen verringert, wie beim Test des Teilgraphen.
Mit Hilfe der Gleichung 6.1 läßt sich die Kantenanzahl der reduzierten Projektgraphen abschätzen. Bei den ursprünglichen Projekten entspricht die Kantenanzahl
|E| etwa dem Dreifachen der Anzahl n der Objekte:
|Er | = (2n + 1) ∗ 3 = 6n + 3.
(6.2)
Durch die Optimierung werden genau n Kanten weggelassen, jeweils eine vom
Startknoten v0 zu den Startknoten eines Objektes:
|E| = 6n + 3 − n = 5n + 3.
(6.3)
Die Kantenanzahl ist bei den Testprojekten um ca. 17 % geringer. In dieser
Grössenordnung sind auch die Laufzeitersparnisse zu erwarten. Tabelle 6.3 zeigt
die Kennwerte der Projekte mit reduzierter Kantenanzahl.
Ergebnisse
Um die Vorteile dieser Methode zum Ausdruck zu bringen, wurden die Laufzeiten
von Bellman-Ford auf den gesamten Graphen gemessen. Im Vergleich zu den ursprünglichen Projekten lässt sich eine Verbesserung von 20 bis 30 % feststellen. In
Tabelle 6.4 sind die konkreten Werte aufgelistet.
Inv.-Nr.: 2005-05-23/052/IN98/2254
6.3. NUMERISCHE KONSISTENZPRÜFUNG
Projektname
P1r
P2r
P3r
P4r
P5r
Anzahl
Medienobjekte
50
100
250
500
1000
Anzahl
Knoten
101
201
501
1001
2001
87
Anzahl
Kanten
241
480
1230
2460
4951
Kantenersparnis
17,2 %
17,2 %
16,9 %
16,9 %
16,8 %
Tabelle 6.3: Testprojekte mit reduzierter Kantenanzahl
Projektname
P1
P2
P3
P4
P5
Zeit ohne
Optimierung
138
1.215
19593
158.719
1.276.156
Zeit mit
Optimierung
107
866
13.614
111.086
910.576
Zeitgewinn
19,9
27,3
29,3
29,5
28,5
%
%
%
%
%
Tabelle 6.4: Laufzeit [ms] Bellman-Ford bei reduzierter Kantenanzahl
Messungen zur Berechnung des Teilgraphen nach unterschiedlich vielen Manipulationen wurden hier nicht gesondert durchgeführt. Die Ergebnisse sind aber mit
Werten der ursprünglichen Projekte vergleichbar, da der zu testende Teilgraph bei
50 Änderungen in etwa der Größe von Projekt P1 entspricht. Da die relativen Zeitgewinne unabhängig von der Graphgröße kaum voneinander abweichen, sind beim
Test des Teilgraphen ebenfalls 20 bis 30 % Zeitersparnis durch Anwenden dieser
Methode zu erwarten.
6.3
Numerische Konsistenzprüfung
Die Messungen der Laufzeiten des numerischen Konsistenzcheck erfolgen nach dem
Algorithmus aus Abschnitt 4.2. Die Projekte werden zunächst komplett eingelesen
und anschließend alle Bedingungen überprüft.
Erwartungen
Bei der zweiten vorgestellten Möglichkeit zur Überprüfung von Ausgabebedingungen werden generell geringere Laufzeiten als beim Test mit Bellman-Ford erwartet.
Da zu jeder Bedingung maximal drei Ungleichungen pro Objekt erstellt werden, ist
nur mit einer linear steigenden Laufzeit zu rechnen. Getestet wird sowohl der Check
des gesamten Graphen als auch die Erstellung mit anschließender Überprüfung des
Teilgraphen bei 1, 25, 50 und 100 Manipulationen.
Ergebnisse
Sämtliche Tests mittels numerischer Ungleichungen sind schneller als Bellman-Ford.
Die Werte der Tabelle 6.5 entsprechen der Gesamtzeit des Konsistenzcheck inklusive der Suche des Teilgraphen. Im Gegensatz zur graphischen Testmethode bleibt
die benötigte Zeit pro geänderter Bedingung relativ konstant und nimmt nicht mit
Inv.-Nr.: 2005-05-23/052/IN98/2254
88
KAPITEL 6. EVALUIERUNG
Projektname
P1
P2
P3
P4
P5
Anzahl
1
0,0024
0,0026
0,0023
0,0025
0,0026
der Änderungen
25
50 100
0,06 0,12 0,28
0,09 0,21 0,32
0,09 0,21 0,55
0,05 0,22 0,68
0,11 0,28 0,74
Tabelle 6.5: Laufzeit [ms] numerischer Konsistenzcheck
Zeit [ns]
Test gesamter Graph mit
numerischen Ungleichungen
Test gesamter Graph mit
Bellman-Ford
1010
108
106
104
102
0
P1
P2
P3
P4
P5
Abbildung 6.4: Vergleich numerische Methode – Bellman-Ford
größer werdenden Teilgraph zu. Abbildung 6.4 zeigt einen Vergleich beider Methoden bei Anwendung auf den gesamten Graphen, Abbildung 6.5 bei unterschiedlich
vielen Manipulationen.
Die Zeit zum Erstellen bzw. Finden des zu testenden Teilgraphen war bei
Bellman-Ford gegenüber der Gesamtzeit vernachlässigbar. Jetzt liegt sie aber im
Bereich der Laufzeit des numerischen Tests. Bei nur einer Manipulation ist sie sogar
um den Faktor 36 größer als der eigentliche Test des Teilgraphen, weil dieser sehr
effizient ist. In Tabelle 6.6 sind beide Zeiten für Projekt P1 aufgelistet.
6.4
Scheduleberechnung
Erwartungen
Die Laufzeiten der Berechnung der Ausgabezeiten (vgl. Kapitel 5) wird sehr stark
abhängig sein von der Struktur des Graphen und von der Position der geänderten
Inv.-Nr.: 2005-05-23/052/IN98/2254
6.4. SCHEDULEBERECHNUNG
Zeit [ns]
89
Test Teilgraph mit je
1/25/50/100 Manipulationen
Finden des Teilgraphen
1010
Test gesamter Graph
108
106
104
102
0
P1
P2
P3
P4
P5
Abbildung 6.5: Vergleich numerische Methode mit Bellman-Ford bei unterschiedlich
vielen Manipulationen
Projektname
P1
P1
P1
P1
Anzahl der
Änderungen
1
25
50
100
Zeit Teilgrapherstellung
0,0023
0,0067
0,0088
0,0109
Zeit Konsistenzcheck
0,00006
0,05682
0,14727
0,26872
Tabelle 6.6: Zeit [ms] für Teilgrapherstellung und numerischen Konsistenzcheck
Inv.-Nr.: 2005-05-23/052/IN98/2254
90
KAPITEL 6. EVALUIERUNG
Zeit [ns]
Scheduleberechnung nach
1/25/50/100 Manipulationen
Konsistenzcheck Teilgraph
1010
Test gesamter Graph mit
Bellman-Ford
108
106
104
102
0
P1
P2
P3
P4
P5
Abbildung 6.6: Scheduleberechnung bei unterschiedlich vielen Manipulationen
Bedingung im Graphen. Da die geänderten Constraints zufällig ausgewählt werden,
hat die Testmethode keinen Einfluss auf deren Position. Um die Auswirkungen
der Graphstruktur zu verdeutlichen, werden zum Vergleich zusätzlich die Projekte
P1a bis P5a getestet. Dort sollten die Zeiten zum Teil deutlich über denen der
ursprünglichen Projekten P1 bis P5 liegen.
Grundlage zur Berechnung des Schedule ist ein Constraint Graph, der vorher
mittels Bellman-Ford auf Konsistenz geprüft wurde. Die Überprüfung mit numerischen Ungleichungen wird nicht betrachtet, da sie nicht die benötigten kürzesten
Pfade zur Berechnung der Ausgabezeiten liefert.
Ergebnisse
Die Zeiten für die Scheduleberechnung der Projekte P1 bis P5 liegen wieder unterhalb der Werte für Bellman-Ford auf den gesamten Graphen. Einzig bei Projekt P1
mit 100 Manipulationen ist die Berechnung etwas langsamer. Abbildung 6.6 zeigt
den Vergleich bei einer unterschiedlichen Anzahl von Manipulationen. Dadurch,
dass die Änderungen nicht wie beim Teilgraphtest gesammelt und zum Schluss
auf einmal gecheckt werden können, sondern nach jeder Änderung sofort auf den
Graphen angewendet werden müssen, liegen die Zeiten zur Berechnung der Ausgabezeiten zum Teil deutlich über denen des Teilgraphchecks.
Der Einfluss der Graphstruktur wird deutlich, wenn die Messergebnisse der
Projekte P1a bis P5a betrachtet werden. Die Zeiten zum Testen des Teilgraphen
liegen im selben Bereich. Für die Scheduleberechnung wird aber ein Vielfaches der
Zeit benötigt. Abbildung 6.7 zeigt die Unterschiede im Diagramm, in Tabelle 6.7
sind die konkreten Werte für Projekte P1 und P1a aufgelistet. Die Abstände werden
Inv.-Nr.: 2005-05-23/052/IN98/2254
6.5. ZWISCHENSTAND
Zeit [ns]
91
Scheduleberechnung nach 1/25/50/100
Manipulationen Projekte Pxa
Scheduleberechnung nach 1/25/50/100
Manipulationen Projekte Px
Test gesamter Graph mit
Bellman-Ford
1010
108
106
104
102
0
P1
P2
P3
P4
P5
Abbildung 6.7: Vergleich Projekte Px mit Pxa
Anzahl der
Änderungen
1
25
50
100
Zeit Scheduleberechnung P1
0,03
11,2
30,5
73,7
Zeit Scheduleberechnung P1a
2,3
117
326
763
Tabelle 6.7: Laufzeit [ms] für Scheduleberechnung bei unterschiedlichen Graphstrukturen
mit Zunahme der Projektgröße entsprechend größer.
6.5
Zwischenstand
Die Messungen haben ergeben, dass die Überprüfung der Konsistenz durch die
vorgestellten Methoden sehr effizient ist. Die einzelnen Vorgehensweisen eignen
sich dabei für verschiedene Anwendungsszenarien. Sollen die Bedingungen nur auf
Konsistenz geprüft werden, ist die Überprüfung durch numerische Ungleichungen
ausreichend. Eine Berechnung des Ausgabeschedule kann zu einem späteren Zeitpunkt erfolgen. Sollen die korrekten Ausgabezeiten jederzeit verfügbar sein, so ist
die optimierte Methode durch Bellman-Ford in Verbindung mit der optimierten
Berechnung des Ausgabeschedule anzuwenden.
Inv.-Nr.: 2005-05-23/052/IN98/2254
92
6.6
KAPITEL 6. EVALUIERUNG
Umsetzung im DBMS
Nachdem die vorgestellten Algorithmen hinsichtlich ihrer Laufzeit untersucht wurden, werden sie nun im DBMS implementiert, um ihren praktischen Gebrauchswert
zu bewerten. Beim verwendeten Datenbanksystem handelt es sich um Oracle 9.2.
Die Eingabe bzw. Speicherung der Bedingungen erfolgt über den Constraint Manager. Das Programm parst die Allen-Relationen und speichert den Graph in den
in Abschnitt 2.5.4 beschriebenen Tabellen. Der Konsistenzcheck wird anschließend
über deine gespeicherte Java-Prozedur entsprechend der Architektur aus Abschnitt
2.3.2 (Integritätssicherung durch DBMS) ausgeführt. Die Prozedur nutzt die Methoden des in Abschnitt 6.1 verwendeten Programm. Zunächst wird das Speichern
eines Projektes bzw. Graphen in der Datenbank bei gleichzeitigem Konsistenzcheck
betrachtet.
6.6.1
Speichern des Graphen in der Datenbank
Das initiale Speichern eines Projektes in der Datenbank und anschließende Änderungen von Bedingungen erfordern unterschiedliche Strategien. Die Messungen aus
Abschnitt 6.2.1 haben ergeben, dass durch eine Aufteilung des Constraint Graphen in Teilgraphen zum Teil enorme Laufzeitgewinne zu erreichend sind. Diese
Erkenntnis verhilft zu einer effizienten initialen Speicherung und Überprüfung des
Graphen.
Die Übertragung der Bedingungen besteht zunächst aus zwei Schritten. Zum
einen muss der eigentliche Graph in der Tabelle Constraint Graphs gespeichert
werden und zum anderen die Daten der Constraint Orders - Tabelle, die einen
Überblick über die verwendeten Relationen gibt. Zuerst werden die Daten der
Duration-Constraints in den beiden Tabellen gesichert. Ein Konsistenzcheck ist
an dieser Stelle noch nicht nötig. Wie anfangs schon erwähnt, werden keine realen Medienobjekte in der Datenbank gespeichert. Die Duration-Constraints stehen
stellvertretend für die Objekte und geben ihre Dauer an. Werden reale Medienobjekte in einem Multimedia-Datenbanksystem abgespeichert, kann deren Dauer
anhand von speziellen Objektattributen abgerufen werden.
Sind alle Objektdauer gespeichert, wird eine Transaktion zur Übertragung einer
Bedingung in die Datenbank gestartet: Zuerst die Daten der Constraint GraphsTabelle, danach Constraint Orders. Der Constraint Graph besteht jetzt aus mindestens zwei Objekten, die miteinander verknüpft sind. Nach Anschluss der Transaktion wird der Konsistenzcheck gestartet. Ist er erfolgreich, werden die Änderungen in
der Datenbank dauerhaft gespeichert. Andernfalls werden sie verworfen. In jedem
Fall ist nach Abschluss der Transaktion die Datenbank bzw. die Bedingungen in
einem konsistenten Zustand.
Der reale Zeitbedarf zum Speichern und gleichzeitigen Konsistenzcheck für die
Projekte P1a bis P5a wird im Folgenden betrachtet.
Erwartungen
In Abschnitt 6.2 wurde die Laufzeit des Konsistenzcheck komplett ohne Datenbankzugriffe gemessen. Um den praktischen Gebrauchswert bewerten zu können,
müssen aber auch diese Zeiten betrachtet werden. Der Zeitaufwand zum alleinigen
Speichern des Graphen in der Datenbank ohne Konsistenzcheck ist in Tabelle 6.8
dargestellt.
Inv.-Nr.: 2005-05-23/052/IN98/2254
6.6. UMSETZUNG IM DBMS
Projektname
P1a
P2a
P3a
P4a
P5a
93
Zeit [s]
1,1
1,9
3,1
5,5
13,6
Tabelle 6.8: Zeit zum Speichern der Projekte in der Datenbank
Die Zeiten liegen bei den kleineren Testprojekten deutlich über der Laufzeit
der Überprüfung mit Bellman-Ford. Die Latenzzeiten zum Verbindungsauf- und
Abbau und der Zeitbedarf der Übertragung der Daten spielen eine nicht unwesentliche Rolle. Um die Dauer der Zugriffszeiten über das Netzwerk gering zu halten,
ist es sinnvoll, nicht nach jeder gespeicherten Bedingung einen Konsistenzcheck
auszuführen, sondern die Überprüfung erst nach einer gewissen Anzahl von Übertragungen zu starten. Da die Laufzeit von Bellman-Ford expotentiell mit der Größe
des Graphen zunimmt, wird eine relativ kleine Anzahl von Bedingungen als optimaler Wert erwartet. Bei zu großen Werten wird die Laufzeit des Konsistenzcheck
den Zeitbedarf der Datenübertragung übersteigen.
Um den optimalen Wert für die Überprüfung mit Bellman-Ford zu finden, werden Messungen durchgeführt, wobei unterschiedlich viele Bedingungen auf einmal
in der Datenbank gespeichert werden. Die Anzahl n der nacheinander gespeicherten Bedingungen sind: 5, 10, 12, 15, 17, 20, 30 und 50. Nachdem n Bedingungen
übertragen wurden, erfolgt der Konsistenzcheck wie oben beschrieben durch Aufruf
der stored Procedure. Anschließend werden die nächsten n Bedingungen übertragen
und getestet. Das wird solange wiederholt, bis der gesamte Graph in der Datenbank gespeichert ist. Die Laufzeit wird gemessen ab dem ersten Speichervorgang
in der Datenbank, dazu zählen auch die Duration-Constrains, bis zum Abschluss
des letzten Konsistenzchecks.
Analog zur Überprüfung mit Bellman-Ford wurde der numerische Konistenzcheck als gespeicherte Java-Prozedur im DBMS implementiert. Da hier die Zeiten
laut den Messungen aus Abschnitt 6.3 linear mit der Graphgröße ansteigen, wird an
dieser Stelle kein Laufzeitgewinn durch Aufspalten des Graphen erwartet. Das Projekt wird in die Datenbank übertragen und anschließend komplett auf Konsistenz
überprüft.
Ergebnisse
Die gemessenen Zeiten bei Bellman-Ford betragen in etwa das Zwei- bis Dreifache
der Zeiten zum alleinigen Speichern des Graphen. Durch die optimierte Methode
wächst die Laufzeit nicht mehr expotentiell mit der Graphgröße. Damit können
auch größere Projekte in annehmbarer Zeit in der Datenbank gespeichert und auf
Konsistenz überprüft werden.
Als optimaler Wert für die Stückelung der Projekte hat sich 15 erwiesen. Nachdem 15 Bedingungen in die Datenbank übertragen wurden, wird ein Konsistenzcheck ausgeführt. Abbildung 6.8 zeigt die Messergebnisse graphisch. Dargestellt ist
die benötigte Zeit pro Objekt, um die Werte zu normieren. Die Werte deuten bei
sämtlichen Projekten auf ein Minimum bei den Wert 15 hin. Tabelle 6.9 zeigt die
Gesamtzeit zum Speichern und Überprüfen der kompletten Projekte mit BellmanFord.
Inv.-Nr.: 2005-05-23/052/IN98/2254
KAPITEL 6. EVALUIERUNG
Zeit [ms]
94
90
Projekt P1a
Projekt P2a
Projekt P3a
80
Projekt P4a
Projekt P5a
70
60
50
40
30
20
10
0
5
10
12
15
17
20
50
Anzahl Manipulationen
Abbildung 6.8: Durchschnittliche Zeit pro Objekt für Konsistenzcheck mit BellmanFord
Projektname
P1a
P2a
P3a
P4a
P5a
Zeit [s]
2,2
3,9
9,6
20,4
54,2
Tabelle 6.9: Zeit zum Speichern und Überprüfen mit Bellman-Ford
Inv.-Nr.: 2005-05-23/052/IN98/2254
6.6. UMSETZUNG IM DBMS
Projektname
P1a
P2a
P3a
P4a
P5a
95
Zeit in s
1,3
2,1
4,4
9,9
27,8
Tabelle 6.10: Gesamtzeit [s] zum Speichern und Überprüfen mit numerischen Ungleichungen
Der numerische Konsistenzcheck wird, wie erwartet, schneller ausgeführt. Die
Zeiten sind in Tabelle 6.10 dargestellt. Sie sind bei kleineren Projekten kaum größer
als die benötigte Zeit zum Speichern der Daten in der Datenbank, steigen aber bis
auf ca. das Doppelte beim größten Projekt an. Insgesamt liegen sie aber immer
unterhalb der Werte von Bellman-Ford. Abbildung 6.9 zeigt den Vergleich der drei
Werte im Diagramm. Im Gegensatz zu den Diagrammen in den Abschnitten 6.2
bis 6.4 ist die Darstellung der Y-Achse nicht logarithmisch, sondern die Gesamtzeit
wird in Sekunden angegeben.
Bei Zeitvorgaben für das Speichern und Durchführen des Konsistenzcheck lassen sich anhand der Messreihen Näherungswerte berechnen, wie groß das Projekt
maximal sein darf. Bei einer Grenze von 5 s liegt die maximale Projektgröße bei
der Überprüfung mittels Bellman-Ford bei 130 Medienobjekten, respektive 285 bei
Verwendung des numerischen Konsistenzcheck.
Die Messergebnisse unterlagen teilweise Schwankungen von bis zu 150%. Die
Ursachen dafür konnten nicht identifiziert werden. Es wird vermutet, dass eine
kurzzeitige hohe Auslastung des Netzwerkes der Universität oder intensive I/OProzesse auf dem Datenbankserver dafür verantwortlich waren. Der optimale Wert
zur Überprüfung des Teilgraphen mit 15 Bedingungen kann abhängig von der verwendeten Hard-, Software und Netzwerkanbindung variieren.
6.6.2
Manipulation von Bedingungen
Das Projekt bzw. der Graph befindet sich nun in der Datenbank und in einem konsistenten Zustand. Jetzt werden, analog zu den Abschnitten 6.2 und 6.3, 1, 25, 50
und 100 Manipulationen an den Projekten P1a bis P5a vorgenommen und anschließend durch die gespeicherte Prozedur auf Konsistenz geprüft. Die Manipulationen
betreffen sowohl Duration-Constraints als auch Allen-Relationen.
Erwartungen
Da die Änderungen zunächst komplett an die Datenbank übertragen werden, spielt
die Qualität der Netzwerkanbindung eine untergeordnete Rolle. Die Laufzeiten sollten deswegen generell schneller sein, als bei der Speicherung der Projekte und anschließender Konsistenzprüfung in der Datenbank.
Ergebnisse
In Tabelle 6.11 bzw. Abbildung 6.10 sind die Messwerte für Bellman-Ford abgebildet. Die Zeiten sind bei wenigen Manipulationen vergleichbar mit den Messwerten
Inv.-Nr.: 2005-05-23/052/IN98/2254
96
KAPITEL 6. EVALUIERUNG
Zeit [s]
60
Speichern ohne Konsistenzprüfung
Test mit Numerischen Ungleichungen
Test mit Bellman-Ford
50
40
30
20
10
0
P1a
P2a
P3a
P4a
P5a
Abbildung 6.9: Laufzeiten: Speicherung, Check mitels numerischer Ungleichungen
und Bellman-Ford
Inv.-Nr.: 2005-05-23/052/IN98/2254
6.6. UMSETZUNG IM DBMS
Projektname
P1a
P2a
P3a
P4a
P5a
97
Anzahl der Änderungen
1 25 50
100
0,2 0,5 1,3
2,8
0,2 0,6 1,6
6,2
0,2 0,6 2,4
11,8
0,3 0,7 3,8
14,4
0,3 1,1 4,0
17,1
Tabelle 6.11: Laufzeit [s] des Konsistenzcheck mit Bellman-Ford im DBMS
Zeit [s]
20
Test mit Bellman-Ford nach
1/25/50/100 Manipulationen
15
10
5
0
P1a
P2a
P3a
P4a
P5a
Abbildung 6.10: Laufzeit des Konsistenzcheck mit Bellman-Ford im DBMS
zur Speicherung des Graphen. Bei 100 Manipulationen ist eine deutliche Verbesserung der Laufzeit erkennbar.
Die gemessenen Zeiten der numerischen Überprüfung liegen bei allen Manipulationen unterhalb der Zeiten zum Speichern des Graphen. Die Ergebnisse sind in
Tabelle 6.12 und Abbildung 6.11 dargestellt.
Zusätzlich zur Manipulation von Bedingungen wurde die Laufzeit bei Veränderung der Dauer der Medienobjekte gemessen. Dazu wird 1, 25, 50 und 100 mal die
Dauer von Objekten geändert und anschließend auf Konsistenz überprüft. Die Ergebnisse sind mit den Laufzeiten der gemischten Manipulationen vergleichbar und
unterscheiden sich in den meisten Fällen nur minimal (Tabellen 6.13 und 6.14).
Existieren Zeitgrenzen zum Durchführen des Konsistenzcheck, lassen sich auch
hier anhand der Messreihen abhängig von der Projektgröße Näherungswerte berechnen, wie viel Änderungen der Objektdauer innerhalb einer Zeitschranke ausgeführt
werden können. Bei Projekt P4 mit 500 Objekten können bis zu 100 Änderungen
innerhalb von 2 s überprüft werden.
Inv.-Nr.: 2005-05-23/052/IN98/2254
98
KAPITEL 6. EVALUIERUNG
Projektname
P1a
P2a
P3a
P4a
P5a
Anzahl der Änderungen
1 25 50
100
0,1 0,3 0,6
0,7
0,3 0,4 0,6
1,0
0,4 0,5 0,8
1,4
0,5 0,6 1,2
1,9
0,6 1,2 1,5
2,8
Tabelle 6.12: Laufzeit [s] des Konsistenzcheck durch numerische Ungleichungen im
DBMS
Zeit [s]
Test mit numerischen Ungleichungen
nach 1/25/50/100 Manipulationen
3
2
1
0
P1a
P2a
P3a
P4a
P5a
Abbildung 6.11: Laufzeit des Konsistenzcheck durch numerische Ungleichungen im
DBMS
Projektname
P1a
P2a
P3a
P4a
P5a
Anzahl der Änderungen
1 25 50
100
0,2 0,6 1,6
3,3
0,2 0,6 1,8
5,2
0,2 0,7 2,8
12,2
0,3 0,8 3,6
15,8
0,4 1,4 4,7
23,7
Tabelle 6.13: Laufzeit [s] des Konsistenzcheck mit Bellman-Ford im DBMS bei
Änderung der Objektdauer
Inv.-Nr.: 2005-05-23/052/IN98/2254
6.6. UMSETZUNG IM DBMS
Projektname
P1a
P2a
P3a
P4a
P5a
99
Anzahl der Änderungen
1 25 50
100
0,2 0,3 0,4
0,5
0,3 0,3 0,6
0,8
0,3 0,5 0,8
1,4
0,4 0,7 1,1
2,0
0,6 1,1 1,6
2,8
Tabelle 6.14: Laufzeit [s] des Konsistenzcheck durch numerische Ungleichungen im
DBMS bei Änderung der Objektdauer
6.6.3
Zusammenfassung
Eine Integration der effizienten Konsistenzprüfung in ein DBMS ist möglich. Durch
Verwendung der optimierten Methoden können auch größere Projekte in einer praktikablen Zeit überprüft werden. Neben der Verknüpfungsstruktur der Projekte hat
auch die Qualität der Netzwerkanbindung einen direkten Einfluss auf die Laufzeit.
Inv.-Nr.: 2005-05-23/052/IN98/2254
100
KAPITEL 6. EVALUIERUNG
Inv.-Nr.: 2005-05-23/052/IN98/2254
Kapitel 7
Zusammenfassung und
Ausblick
7.1
Zusammenfassung
Das Ziel der vorliegenden Arbeit besteht darin, auf effizientem Wege Ausgabebedingungen in einem Multimedia-Datenbanksystem auf Konsistenz zu überprüfen.
Die Bedingungen können für Medienobjekte mittels Allen-Relationen und Angabe
zusätzlicher Parameter definiert werden. Durch anschließende Transformation der
Relationen in Difference Constraints und in einen Constraint Graphen können die
Bedingungen mit den Algorithmus von Bellman und Ford auf Konsistenz überprüft
werden. Durch die expotentielle Laufzeit des Algorithmus ist ein Konsistenzcheck
und die Berechnung eines Ausgebeschedule bei größeren Projekten nicht praktikabel. Eine Überprüfung in einem Multimedia-Datenbanksystem war bisher nicht
möglich, da heutige DBMS keine speziellen Methoden zur Integritätssicherung von
Ausgabebedingungen zur Verfügung stellen.
Durch Einschränkung der Verknüpfungsmöglichkeiten der Medienobjekte wurden in dieser Arbeit Algorithmen entwickelt, die eine sehr effiziente Überprüfung
der Bedingungen ermöglichen. Der Test eines Teilgraphen bei Einschränkungen in
der Graphstruktur ist hinreichend für die Konsistenz des gesamten Projektes. Neben der Möglichkeit der Konsistenzprüfung durch den Algorithmus von Bellman
und Ford ist eine Überprüfung durch Auswerten von numerischen Ungleichungen
realisierbar. Des Weiteren wurde eine Methode vorgestellt, die eine effiziente Berechnung des Ausgabeschedule erlaubt. Trotz Einschränkungen der Verknüpfungsstruktur können komplexe Projekte beschrieben werden. So auch Audioszenen, die
anschließend mittels Wellenfeldsynthese ausgegeben werden sollen.
Die Implementierung der Konsistenzprüfung in einem Multimedia-Datenbanksystem hat gezeigt, dass Ausgabebedingungen in der Datenbank gespeichert und
sehr effektiv überprüft werden können. Die Qualität der Netzwerkanbindung hat
dabei direkten Einfluss auf die Laufzeit.
Alle vorgestellten Algorithmen und Methoden sind auch bei umfangreichen Projekten praktikabel und erlauben eine effiziente Verwaltung einer großen Anzahl
von Medienobjekten und Allen-Relationen. Das Ziel der Aufgabenstellung wurde
erreicht.
Inv.-Nr.: 2005-05-23/052/IN98/2254
102
7.2
KAPITEL 7. ZUSAMMENFASSUNG UND AUSBLICK
Ausblick
Die in Abschnitt 3.7 vorgestellte Realisierung des Konsistenzcheck durch aufgeschobene Trigger konnte nicht implementiert werden. Das verwendete DBMS der
Firma Oracle unterstützt das Konzept der verschobenen Ausführung nur bei herkömmlichen Constraints aber nicht bei Triggern. Aus diesem Grund musste ein
Workarround über eine temporäre Tabelle geschaffen werden. Die Verwendung von
deferred Trigger kann weitere Laufzeitvorteile bringen und empfiehlt sich für weitere
Untersuchungen. Das objekt-relationale DBMS PostgreSQL der Berkley Universität z. B. unterstützt das Konzept der aufgeschobenen Trigger.
Des Weiteren kann die Möglichkeit der automatisch generierten Trigger bzw.
Constraints und Überprüfung der Konsistenz durch numerische Ungleichungen
(Abschnitt 4.3) auf ihren praktischen Gebrauchswert untersucht werden. Auch hier
sind geringere Laufzeit zu erwarten, da keine gespeicherte Java-Prozedur gestartet
werden muss.
Weitere Laufzeitoptimierungen sind durch Verwendung von Heuristiken gegeben. Da nur eine definierte Menge von Allen-Relationen verwendet wird, lassen
sich z. B. für jede Relation spezielle Ungleichungen formulieren, die für die Konsistenz hinreichend sind (vgl. Abschnitt 4.1). Die Identifizierung einzelner potentieller
negativer Zyklen ist dadurch nicht erforderlich, weil sie durch die Ungleichungen
schon gegeben sind.
Ein nächster Schritt wäre die Implementierung der Methoden unter Verwendung von realen Medienobjekten. Dabei stellt sich die Frage, ob der Datendurchsatz der Datenbank für einzelne Anwendungsgebiete ausreichend ist. Besonders
Videos haben eine hohe Bitrate und benötigen performante Systeme. Aber auch
bei der gleichzeitigen Ausgabe von sehr vielen Audiodateien kann der physikalisch
begrenzte Datendurchsatz eines DBMS ein beschränkender Faktor sein.
Neben zeitlichen Bedingungen, die ausschließlich in dieser Arbeit betrachtet
wurden, lassen sich auch räumliche oder räumlich-zeitliche Zusammenhänge zwischen Medienobjekten definieren. In [He04] werden räumliche Constraints für die
Lage eines Objektes im Präsentationsraum genannt. Die Überprüfung erfolgt analog
zu den zeitlichen Bedingungen über Difference Constraints bzw. einen Constraint
Graph. Die X- und Y-Koordinaten der jeweiligen Punkte werden durch einen Constraint Graph repräsentiert und gesondert auf Konsistenz geprüft.
Bei der Beschreibung von Bewegungen bzw. räumlich-zeitlicher Zusammenhänge ist der Aufwand größer. Zur Modellierung muss für jeden Zeitpunkt ein Graph
für die X- bzw. die Y-Koordinaten anlegt werden. Abhängig von der Genauigkeit
der Zeitschritte ist der Aufwand entsprechend groß. Bei 25 Einzelschritten pro Sekunde beläuft sich die Anzahl der Graphen bei 1 min Gesamtdauer bereits auf
1500.
Durch die Möglichkeit der effizienten Überprüfung von Ausgabebedingungen
werden sich in Zukunft weitere Anwendungsgebiete erschliessen.
Inv.-Nr.: 2005-05-23/052/IN98/2254
Anhang A
Erweiterte Allen-Relationen
A.1
Übersicht der Relationen
Name
duration
meets
f inishes
equals
bef ore
bef orev
overlaps
overlapsvs
overlapsve
overlapsvse
during
duringvs
duringve
duringvse
A.2
Syntax
A duration(tA )
A meets B
A f inishes B
A equals B
A bef ore B
A bef orev (c1 ,c2 ) B
A overlaps(c1 ,c2 ) B
A overlapsvs (c1 , l, c2 ) B
A overlapsve (c1 , c2 , m) B
A overlapsvse (c1 , l, c2 , m) B
A during(c1 , c2 ) B
A duringvs (c1 , l, c2 ) B
A duringve (c1 , c2 , m) B
A duringvse (c1 , l, c2 , m) B
Numerische Bedingungen der Relationen
Relation equals:
|tA | = |tB | .
Relation f inishes:
|tB | − 1 ≥ |tA | (M aximum),
|tA | + 1 ≤ |tB | (M inimum).
Inv.-Nr.: 2005-05-23/052/IN98/2254
104
ANHANG A. ERWEITERTE ALLEN-RELATIONEN
Relation overlaps(c1 ,c2 ):
c1 + 1 ≤ |tA | (M inimum),
c2 + 1 ≤ |tB | (M inimum).
Relation overlapsvs (c1 , l, c2 ):
c1 + 1 ≤ |tA | (M inimum),
|tB | + c1 + l − c2 ≥ |tA | (M aximum),
c2 + 1 ≤ |tB | (M inimum),
|tA | − c1 − l + c2 ≤ |tB | (M inimum).
Relation overlapsve (c1 , c2 , m):
c1 + 1 ≤ |tA | (M inimum),
|tB | + c1 − c2 − m ≤ |tA | (M inimum),
c2 + 1 ≤ |tB | (M inimum),
|tA | − c1 + c2 + m ≥ |tB | (M aximum).
Relation overlapsvse (c1 , l, c2 , m):
c1 + 1 ≤ |tA | (M inimum),
|tB | + c1 − c2 − m ≤ |tA | (M inimum),
|tB | + c1 + l − c2 ≥ |tA | (M aximum),
c2 + 1 ≤ |tB | (M inimum),
|tA | − c1 − l + c2 ≤ |tB | (M inimum),
|tA | − c1 + c2 + m ≥ |tB | (M aximum).
Relation during(c1 , c2 ):
|tB | − c1 − c2 ≥ |tA | (M aximum),
|tA | + c1 + c2 ≤ |tB | (M inimum).
Inv.-Nr.: 2005-05-23/052/IN98/2254
A.2. NUMERISCHE BEDINGUNGEN DER RELATIONEN
Relation duringvs (c1 , l, c2 ):
|tB | − c1 − c2 ≥ |tA | (M aximum),
|tA | + c1 + c2 ≤ |tB | (M inimum).
Relation duringve (c1 , c2 , m):
|tB | − c1 − c2 ≥ |tA | (M aximum),
|tA | + c1 + c2 ≤ |tB | (M inimum).
Relation duringvse (c1 , l, c2 , m):
|tB | − c1 − c2 ≥ |tA | (M aximum),
|tA | + c1 + c2 ≤ |tB | (M inimum).
Inv.-Nr.: 2005-05-23/052/IN98/2254
105
106
ANHANG A. ERWEITERTE ALLEN-RELATIONEN
Inv.-Nr.: 2005-05-23/052/IN98/2254
Literaturverzeichnis
[ABH97]
Apers, P. M. G. ; Blanken, M. H. ; Houtsma, M. A. W.: Multimedia
databases in perspective.. Springer, London, 1997.
[Al83]
Allen, J. F.: Maintaining Knowledge about Temporal Intervals. Communications of the ACM 26. Nr. 11, S. 832 - 843, 1983.
[Be59]
Bellman, R. E.: On a Routing Problem. Quart. Appl. Math.. Nr. 16,
S. 87 - 90, 1958.
[Br94]
Brandstädt, A.: Graphen und Algorithmen. B. G. Teubner, Stuttgart,
1994.
[BS02]
Bonazzi, E.; Stokol, G.: Oracle und Java. Markt + Technik, München,
2002.
[BV94]
Boone, M.; Verheijen, E.: The Wave Field Synthesis Concept Applied
to Sound Reproduction. AES Con Convention Paper presented at the
96th AES Convention Februar 1994, Amsterdam, 1994.
[CLS00]
Candan, K. S.; Lamar, E.; Subrahmanian, V. S.: View management in
multimedia databases. The VLDB Journal 9. Nr. 2, S. 131 - 153, 2000.
[CPS96]
Candan, K.; Prabhakaran, B.; Subrahmanian, V.S.: CHIMP: A Framework for Supporting Distributed Multimedia Document Authoring and
Presentation. Proceedings of the ACM Multimedia. S. 329 - 339, 1996.
[DG00]
Dittrich, K. R; Gatziu, S.: Aktive Datenbanksysteme. dpunkt Verlag,
Heidelberg, 2000.
[Di59]
Dijkstra, E. W.; A node on two problems in connexion with graphs,
Numerische Mathematik 1. S. 269 - 271, 1959.
[DK95]
Duda, A.; Keramane, C.: Structured Temporal Composition of Multimedia Data. Proceedings of the International Workshop on MultiMedia Database Management Systems (IW-MMDBMS). S. 136 - 142,
1995.
[FG04]
Fraunhofer-Gesellschaft: IOSONO - Wellenfeldsynthese-System. 2004.
http://www.iosono-sound.de/ (abgerufen am 12.05.2005)
[FI04a]
Fraunhofer-Institut für Digitale Medientechnologie IDMT: IOSONO.
2004.
http://www.idmt.fraunhofer.de/projekte themen/index.htm?iosono
(abgerufen am 15.05.2005)
Inv.-Nr.: 2005-05-23/052/IN98/2254
108
LITERATURVERZEICHNIS
[GS26]
Geiger, H.; Scheel, K.: Handbuch der Physik, Band VIII. Verlag Julius
Springer, Berlin, 1926.
[Ha04]
Hartung, M.: Transformation einer XML-Struktur (Allen - Relationen)
für Ausgabebedingungen in einen Constraint Graph. Ilmenau, 2004.
[He04]
Heimrich, T.: Modeling and Checking of Output Constraints in Multimedia Database Systems. Ilmenau, 2004.
[HL01]
Hunter, J.; Little, S.: Building and Indexing a Distributed Multimedia Presentation Archive Using SMIL. Solvberg, P. Constantopoulos,
ECDL 2001, LNCS 2163. S. 415 - 428, Springer-Verlag, Heidelberg,
2001.
[HSRG04]
Heimrich, T.; Sattler, K.; Reichelt, K.; Gatzsche, G.: Verwaltung
spatio-temporaler Audiodaten für die Wellenfeldsynthese. Ilmenau,
2004.
[HSS03]
Heuer, A.; Saake, G.; Sattler, K.: Datenbanken kompakt. mitp-Verlag,
Bonn, 2003.
[HS00]
Heuer, A.; Saake, G.: Datenbanken: Konzepte und Sprachen. S. 498 502, mitp-Verlag, Bonn, 2000.
[KB95]
Khoshafian, S.; Baker, A. B.: Multimedia and Imaging Databases. Morgan Kaufmann Publishers, San Francisco, CA, 1995.
[KE01]
Kemper, A.; Eickler, A.: Datenbanksysteme. Oldenbourg, München,
2001.
[Lex89]
Lexikon, dtv Brockhaus Lexikon Band 12. F.A. Brockhaus GmbH
Deutscher Taschenbuch Verlag GmbH & Co. KG, München, 1989.
[Lex91]
Lexikon, Brockhausenzyklopädie. F.A. Brockhaus GmbH, Mannheim,
1991.
[Lex92]
Lexikon, CBT- / Multimedia Lexikon. CBT Verlag, München, 1992.
[Mi05]
Michel, T.: W3C Synchronized Multimedia Home page. W3C, 2003,
http://www.w3.org/AudioVideo/ (abgerufen am 28.04.2005)
[Ra04]
Ramm, S.: Konzeption einer Präsentationsbeschreibung für Multimedia - Datenbanken. Ilmenau, 2004.
[Roi98]
Roisin, C.: Authoring Structured Multimedia Documents. Rovan, Branislav: SOFSEM ’98, LNCS 1521. S. 222 - 239, Springer-Verlag, Heidelberg, 1998.
[TWR02]
Theile, G.; Wittek, H.; Reisinger, M.: Wellenfeldsynthese-Verfahren:
Ein Weg für neue Möglichkeiten der räumlichen Tongestaltung. Institut für Rundfunktechnik GmbH, München, 2002.
Inv.-Nr.: 2005-05-23/052/IN98/2254
Thesen
1. Ausgabebedingungen für Medienobjekte lassen sich mittels Allen-Relationen
und der Angabe von zusätzlichen Paramentern definieren. Durch Transformation der Allen-Relationen in Difference Constraint können diese auf Konsistenz geprüft werden. Gegenwärtig existierende Konzepte sind bei einer großen
Anzahl von Bedingungen für den praktischen Einsatz nicht geeignet.
2. Entspricht die Anordnung der mit Allen-Relationen verknüpften Ausgabeobjekte einer Baumstruktur, ist eine sehr effiziente Konsistenzüberprüfung der
generierten Menge an Difference Constraints durch die vorgestellten Algorithmen auch bei großen Projekten möglich.
3. Als Difference Constraints formulierte Ausgabebedingungen können in einen
Constraint Graph transformiert werden. Die Bestimmung aller kürzesten Pfade von einem definierten Startknoten zu jeden anderen Knoten im Graphen
kann durch den Algorithmus von Bellman-Ford effizient erfolgen.
4. Wurden alle kürzesten Pfade im Graphen berechnet und entspricht die Anordnung der mit Allen-Relationen verknüpften Ausgabeobjekte einer Baumstruktur, lassen sich bei Änderung von Bedingungen oder Objektdauer die
neuen kürzesten Pfade und somit die Ausgabezeiten effizient berechnen.
5. Die effiziente Konsistenzprüfung und die Berechnung der Ausgabezeiten können in einem Multimedia-Datenbankmanagementsystem implementiert werden und haben auch bei großen Projekten eine akzeptable Laufzeit.
Ilmenau, den 20.05.2005
Thomas Schröder
Inv.-Nr.: 2005-05-23/052/IN98/2254
Eidesstattliche Erklärung
Hiermit erkläre ich an Eides statt, diese Diplomarbeit eigenhändig und selbständig verfasst, keine anderen als die angegebenen Hilfsmittel oder Quellen verwendet
und direkt oder indirekt übernommene Gedanken als solche gekennzeichnet zu haben.
Diese Arbeit wurde bisher in dieser oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt oder anderweitig veröffentlicht.
Ilmenau, den 20.05.2005
Thomas Schröder
Inv.-Nr.: 2005-05-23/052/IN98/2254