Diplomarbeit

Otto-von-Guericke-Universität Magdeburg
Fakultät für Informatik
Institut für Technische und Betriebliche Informationssysteme
Diplomarbeit
Konzept und Entwicklung eines Offline-Tools zum
Graphmining auf integrierten molekularbiologischen
Daten
Verfasser:
Michael Soffner
7. September 2005
Betreuer:
Dipl.-Inf Matthias Lange
Prof. Dr.-Ing. habil. Georg Paul
Universität Magdeburg
Fakultät für Informatik
Postfach 4120, D–39016 Magdeburg
Germany

Soffner, Michael:
Konzept und Entwicklung eines Offline-Tools
zum Graphmining auf integrierten molekularbiologischen
Daten
Diplomarbeit, Otto von Guericke Universität
Magdeburg, 2005.

Danksagung
An dieser Stelle möchte ich meinen Betreuern danken. Zum einen meinem Betreuer an
der Otto-von-Guericke Universität in Magdeburg, Prof. Dr.-Ing. habil. Georg Paul, und
andererseits meinem Betreuer am Institut für Pflanzengenetik und Kulturpflanzenforschung,
Matthias Lange.
i

INHALTSVERZEICHNIS iii
Inhaltsverzeichnis
Abbildungsverzeichnis viii
Tabellenverzeichnis ix
Listingverzeichnis xii
Verzeichnis der Abkürzungen xiii
1 Einleitung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Technische Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Extended Backus-Naur Form (EBNF) der XML Spezifikation des
W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Grundlagen 9
2.1 Biologische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Aufbau der Proteomics-DB . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Datenbankmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Relationale Datenbanken . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Objektdatenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 XML - hierarsche Datenstrukturen . . . . . . . . . . . . . . . . . . . . . 22

iv INHALTSVERZEICHNIS
2.4.1 XML-Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Grundlagen in der Graphentheorie . . . . . . . . . . . . . . . . . . . . . . 27
3 Anfragetechnologien über Graphenstrukturen 29
3.1 Aktueller Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Konstruktion eines Referenzbeispiels . . . . . . . . . . . . . . . . . . . . 30
3.3 Anfragesprachen auf relationalen Datenbanken . . . . . . . . . . . . . . . 33
3.3.1 Anwendung des relationalen Konzepts . . . . . . . . . . . . . . . 36
3.4 XML-basierte Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.1 Anwendung des XML-basierten Konzepts . . . . . . . . . . . . . . 42
3.5 Objektorientiertes Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.1 Anwendung des Konzepts von ODBMS . . . . . . . . . . . . . . . 49
3.6 Gesamtbewertung und resultierendes Konzept . . . . . . . . . . . . . . . 51
4 Entwurf des Offlinewerkzeugs 53
4.1 Problemdefinition und Anforderungsanalyse . . . . . . . . . . . . . . . . 53
4.2 Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.1 Plugin-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.2 Interne Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.3 Generierung der Relation-Attribut Informationen . . . . . . . . . 60
4.2.4 Komprimierung des Datenpools . . . . . . . . . . . . . . . . . . . 61
4.3 Entwurf und Implementation . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.1 Relationenmodell der internen Daten . . . . . . . . . . . . . . . . 63
4.3.2 Plugin-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.3 Das Paket GraphExportParser . . . . . . . . . . . . . . . . . . . . 73
4.3.4 Import der RelationAttribut-Wertepaare und Graphinformationen 74
5 Zusammenfassung und Ausblick 79
A Screenshots vom OfflineTool BioDataPathQuery 83
A.1 Allgemeine Bestandteile . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.2 Beispiel eines Eingabeplugins . . . . . . . . . . . . . . . . . . . . . . . . 86

INHALTSVERZEICHNIS v
B XML-Schema 89
Literaturverzeichnis 93

vi INHALTSVERZEICHNIS

ABBILDUNGSVERZEICHNIS vii
Abbildungsverzeichnis
1.1 Beschreibung des Vorgehens eines Biologen bei der Suche einer Annotation 3
1.2 Notation des Aktivitätsdiagramms [Dum00] . . . . . . . . . . . . . . . . 8
2.1 Ausschnitt aus dem Datenbankschema der Proteomics-DB . . . . . . . . 12
2.2 Graphische Notation eines Relationenschmas [HS00] . . . . . . . . . . . . 16
2.3 Schematische Darstellung des Aufbaus eines wohlgeformten XML-
Dokuments [ABK + 00] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 aktueller Ablauf einer Anfrage . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Graph G1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Graph G2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 JAXB Überblick [OM03] . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1 Drei grundlegenden Anwendungsfälle im Umfeld des Tools . . . . . . . . 55
4.2 Teilaufgabe der Datenbereitstellung . . . . . . . . . . . . . . . . . . . . . 56
4.3 Aktivitätsdiagramm zur Beschreibung der Datenbeschaffung . . . . . . . 57
4.4 Komponentendiagramm der Plugin-Struktur . . . . . . . . . . . . . . . . 58
4.5 Aktivitätsdiagramm zur Darstellung der Aktivitäten bei der Benutzung
des Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6 ER-Schema der internen, temporären Daten . . . . . . . . . . . . . . . . 60
4.7 Generierung der Einschränkungsteils für das XML Schema und die Text-
datei zum Import der RelationAttribut Werte . . . . . . . . . . . . . . . 61
4.8 Datenfluss der Pfaddaten vom DBS zum OfflineTool . . . . . . . . . . . . 62
4.9 Aktivitätsdiagramm zur Funktionsweise des Komprimierungstool . . . . . 63

viii ABBILDUNGSVERZEICHNIS
4.10 Klassendiagramm zum Packet datapathquery.inputPlugin . . . . . . . . . 67
4.11 Klassendiagramm zum Packet datapathquery.inputPlugin - Dialog zur De-
finition der regulären Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . 68
4.12 Klassendiagramm zum Packet datapathquery.outputPlugin . . . . . . . . 69
4.13 Klassendiagramm zum Packet datapathquery.queryModule (Teil 1 - Stan-
dardQueryModule) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.14 Klassendiagramm zum Packet datapathquery.queryModule (Teil 2 - Gra-
phfilter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.15 Klassendiagramm zum Packet datapathquery.queryModule (Teil 3 - Reg-
ExpAnalyser) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.16 Klassendiagramm zum Packet datapathquery.queryModule (Teil 4) . . . . 73
4.17 Paketübersicht der Subpakete des Pakets datapathquery.graphExportParser 74
4.18 Klassendiagramm zum Packet datapathquery.graphExportParser . . . . . 75
4.19 Klassendiagramm zum Packet importGenerator . . . . . . . . . . . . . . 76
A.1 Einträge des Menüs Options . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.2 Preference Dialogfenster . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.3 Menü Plugin, dessen Einträge die regristrierten Plugins sind . . . . . . . 85
A.4 Das Eingabeplugin BlastXInputPlugin . . . . . . . . . . . . . . . . . . . 86
A.5 Das Eingabeplugin BlastXInputPlugin - Auswahl der Zuordnugnsdatei der
Token der regulären Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . 87
A.6 Der Dialog zum Erstellen eines regulären Ausdrucks . . . . . . . . . . . . 88

TABELLENVERZEICHNIS ix
Tabellenverzeichnis
2.1 Gegenüberstellung von Fragestellungen in der Proteomik und den zuge-
örigen Verfahrenstechniken zur Informationsgewinnung [Wik] . . . . . . . 10
3.1 Liste der zu betrachtenden Berwertungskriterien . . . . . . . . . . . . . . 29
3.2 Graph G1 im RGraph (die Spaltennamen wurden zwecks Platzersparnis
verkürzt geschrieben) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Ausgabe zu den Anfrage der Listings 3.2,3.3 . . . . . . . . . . . . . . . . 39
3.4 Bewertung der Anfragetechnologien . . . . . . . . . . . . . . . . . . . . . 51
4.1 Abbildung eines ER-Schemas auf ein relationales Schema [HS00] . . . . . 64

x TABELLENVERZEICHNIS

LISTINGS xi
Listings
1.1 Produktionsregel zur Definition eines neuen Symbols . . . . . . . . . . . 6
2.1 Rohdaten ohne Marken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Daten aus Listing 2.1 als XML . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Beispiel für XML DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Beispiel für XML-Schema Instanz . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Einbettung des im Listing 2.4 entworfenen Dokumenttyps . . . . . . . . . 26
3.1 Start-Ziel Anfrage ohne konkrete Pfadinformationen . . . . . . . . . . . . 37
3.2 Selbstverbund über der Relation RGraph . . . . . . . . . . . . . . . . . . . 38
3.3 Pfadausgabe mittel CONNECT BY-Klausel (nur Oracle) . . . . . . . . . 39
3.4 Definition eines Lokalisierungsschritts nach [CD99] . . . . . . . . . . . . . 41
3.5 Ausschnitt der Definition der Achsenbeschreibung und des Knotentests
nach [CD99] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6 XML-Schema Datei zur Definition der XML-Struktur für Graphen . . . . 43
3.7 Ausschnitt der XML-Dokumenteninstanz des Dokumententyps aus Listing
3.6 über der Graphenmengen G . . . . . . . . . . . . . . . . . . . . . . . 45
3.8 Pfadanfragen über Graphen als XPath Ausdrücke . . . . . . . . . . . . . 46
3.9 XPath Ausdrücke mit Pfadauswertung . . . . . . . . . . . . . . . . . . . 47
3.10 Ausschnitt aus der ODL Grammatik [CBB + 97] . . . . . . . . . . . . . . 48
3.11 Ausschnitt der OQL Grammatik aus [CBB + 00] . . . . . . . . . . . . . . 49
3.12 Darstellung der Graphen durch ODL . . . . . . . . . . . . . . . . . . . . 50
3.13 OQL Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 Beispiel einer Link-Datei für die Klasse RegularExpressionVocabularyLinker 73

xii LISTINGS
4.2 Anweisung zur Generierung des Javaklassen entsprechend der Schema-
Datei durch JAXB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B.1 XML-Schema Datei der Graphstruktur . . . . . . . . . . . . . . . . . . . 89
B.2 Auszug des XML-Schema Teils für die Knotenbeschreibungen . . . . . . . 90

Verzeichnis der Abkürzungen
ANU The Australian National University
BLAST Basic Local Alignment Search Tool
DBMS Datenbankmanagementsystem
DDL Data Definition Language
DML Data Manipulation Language
DNS Desoxyribonukleinsäure
DOM Document Object Model
EBI European Bioinforamtics Institute
EBNF Extended Backus-Naur Form
EMBL European Molecular Biology Laboratory
GenBank Archivierungsdatenbank für Gensequenzen der NCBI
HMM Hidden Markov Models
HUPO Human Proteome Organization
IUBMB International Union of Biochemistry and Molecular Biology
NCBI National Center for Biotechnology Information
ODBMS objektorientiertes Datenbankmanagementsystem
ODL Object Definition Language
ODMG Object Data Management Group
OID Objektidentifikator
OML Object Manipulation Language
OQL Object Query Language
PDB Protein Data Bank, Archiv über dreidimensionale
Strukturen biologischer Makromoleküle
PIR Protein Information Resource
RDBMS relationales Datenbankmanagementsystem
SAX Simple API for XML
SGD Saccharomyces Genome Database
SGML Standard Generalized Markup Language
SIB Swiss Institute of Bioinformatics
TIGR The Institute for Genomic Research
UniProt Universal Protein Resource
W3C World Wide Web Consortium
XML Extensible Markup Language
xiii

xiv
ZFIN The Zebrafisch Information Network

Kapitel 1. Einleitung 1
Kapitel 1
Einleitung
Anliegen dieses Kapitels ist es, dem Leser den Inhalt dieser Arbeit motivierend zu beschreiben.
Der Leser soll einen Einblick in die Problematik der bestehenden Aufgabe
bekommen, um sich ein besseres Bild über die Vorgehensweise bei der Entwicklung und
Entwicklungstendenzen im Allgemeinen machen zu können.
1.1 Motivation
Viele Projekte wurden seit den Anfängen der Molekularbiologie gestartet und wachsende
technologische Möglichkeiten waren und sind Ursache für die Ansammlung riesiger Datenbestände.
Damit diese Datenbanken nicht zu einen Datenfriedhof werden, muss die
Möglichkeit der Informationsextraktion gewährleistet sein. Meist treten zunächst Fragestellungen
der folgenden Art auf: Gegegeben sei eine Sequenz oder ein Sequenzbruchstück.
Gibt es in der Datenbank weitere ähnliche Sequenzen bezüglich dieser Sequenz?
Dies ist in der Bioinformatik eine zentrale Fragestellung. Für dieses Problem gibt es
derzeit schon effiziente Lösungen. Diese sind unter dem Namen BLAST bekannt. BLAST
ist ein Akronym und steht für Basic Local Alignment Search Tool. Es sucht homologe
Sequenzen zur Eingabesequenz. Homologien sind Ähnlichkeiten, die auf einen gemeinsamen
Vorfahren zurückzuführen sind. Es ist also möglich, daß zwei DNS-Sequenzen sehr
ähnlich sind jedoch nicht homolog, weil die Ähnlichkeit nicht auf einen Vorfahren beider
Spezies zurückführbar war.
Es existieren verschiedene BLAST Varianten, die durch die Art der Eingabedaten und
der Art der Daten, in denen gesucht wird, unterschieden werden. Die folgende Auflistung
zeigt die einzelnen BLAST-Typen.
• Blastn : DNA- Anfrage/ DNA- Datensammlung
• Blastp : Protein- Anfrage/ Protein- Datensammlung
• Blastx : translatierte DNA- Anfrage/ Protein- Daten

2 1.1. Motivation
• Tblastn : Protein- Anfrage/ translatierte DNA- Daten
• Tblastx: translatierte DNA- Anfrage/ DNA- Daten
Wieso wurde BLAST an dieser Stelle erwähnt? Um diese Frage zu beantworten, muss
ein klein wenig ausgeholt werden. Zunächst ist es wichtig, den Begriff der funktionalen
Annotation zu verstehen. Die Annotationen sind gerade die Informationen, die für den
praktischen Gebrauch von Bedeutung sind. Sie beschreiben welche Funktion dem jeweiligen
Objekt zuzuordnen ist. Beispielsweise die aktuelle Sequenz ist Bestandteil der
codierenden Sequenz eines bestimmten Proteins, welches bei Gerste eine Resistenz gegen
eine betimmten Schädling bewirkt. Dieser Zusammenhang könnte direkt bei einer Beobachtung
von eigens veränderten Proben erkannt werden. Ganz einfach aus dem Grund,
weil die entsprechend auf molekularer Ebene veränderten Pflanzen keinem Befall des
Schädlings unterlagen. Hingegen die nicht-veränderten Pflanzen angegriffen wurden. Somit
ist klar, daß die Änderung der DNS diesen Unterschied hervorgebracht hat und die
entsprechenden Sequenz dieser Resistenz zugeschrieben werden kann.
Solche Informationen wurden bereits in vielen Projekten gewonnen. Dieses Wissen
kann sich zu Nutze gemacht werden, wenn bei Sequenzierarbeiten neue, unbekannte Sequenzen
erschlossen werden und es daraufhin unweigerlich zu der Frage kommt, welche
Aufgabe diese Sequenz haben wird. Genau hier findet das BLAST seine Anwendung im
ersten Schritt der funktionalen Annotation einer noch nicht annotierten Sequenz. Durch
BLAST-Anfragen werden homologe Sequenzen gefunden. Die Ergebnisse können aus Experimenten
aus Projekten mit molekularem Material verschiedenster Spezies stammen.
Einige Treffer sind unbrauchbar, andere lassen jedoch Vermutungen erahnen. Werden
unter den Ergebnissen gerade solche gefunden, die auf Objekte der gleichen Gattung
verweisen, so ist es aufgrund der Homologie recht wahrscheinlich, daß die Ursprungssequenz
der BLAST-Anfrage ebenfalls die gleiche Funktion hat, wie die des Treffers des
BLAST-Vorgangs. Somit kann die nachfolgende Arbeit zielgerichtet organisiert werden.
Um sich eine Vorstellung von dem Aufwand zu machen, der für das Finden der
gewünschten Information nötig ist, soll jetzt der Suchvorgang eines Biologen erläutert
werden. Im Aktivitätsdiagramm in Abbildung 1.1 wird das Vorgehen dargestellt. Allein
die Struktur läßt hier schon den Aufwand erkennen. Nur mit etwas Glück kann die
Suche recht schnell zum Ziel führen. Angenommen es wird gleich beim ersten auffälligen
BLAST-Resultat die gewünschte Information gefunden und es werden keine weiteren
Informationen benötigt, ist das Ende der Suche erreicht. Eher wahrscheinlich ist aber,
daß der zuerst gewählte Eintrag nicht direkt die Information beinhaltet. Dann eröffnen
sich zwei weitere Möglichkeiten:
1. es wird zurück zum BLAST-Resultat gegangen und dort ein weiterer Eintrag ausgewählt,
oder
2. es wird nach Verbindungen innerhalb des aktuellen Eintrags gesucht.
Die zweite Variante beschreibt den Fall, in dem die nächste Rekursionsstufe erreicht wird.
Wird auch hier die gewünschte Information nicht gefunden, bestehen auch wieder die

Kapitel 1. Einleitung 3
eben genannten Möglichkeiten für diesen Eintrag mit einem Unterschied. Der Rückschritt
zum vorherigen Eintrag ist nun kein direktes Resultat der BLAST-Anfrage, sondern
der Eintrag auf der letzte Rekursionsstufe. Der Suchprozess beschreibt letztlich eine
Tiefensuche.
+ 0
! + /
0# # +
$ %
! " #
$
%
$ 2
! " #
1
$ %
$
$ %
, %
+'! 0 &
%
$
$ %
&
'
( ) %
$
* +'!
%
$ %
- , &
.
Abbildung 1.1: Beschreibung des Vorgehens eines Biologen bei der Suche einer Annotation
Mit etwas Erfahrung ist es sicher möglich eine geeignete Auswahl der Einträge zu
treffen, jedoch besteht dabei immer eine Gefahr. Der Biologe setzt vorraus, daß wenn
er bei seiner Auswahl, die normalerweise zum Ziel führt, die Information nicht erhält,
darausfolgend auch kein Zusammenhang mit der von ihm vermuteten Funktion seines
Objekts bestehen kann. Aber es ist durchaus vorstellbar, daß über einen anderen Pfad

4 1.2. Zielstellung
der gerade ausgeschlossene Zusammenhang doch belegt werden könnte. So wäre dem
Biologen die Information verloren gegangen. Durch die Beschreibung des Vorgangs ist
sicherlich klar, daß das Problem recht zeitaufwendig und durchaus ein größeres Maß
an Komplexität annehmen kann. Aus diesem Grund ist die manuelle Suche auf den
Daten ein eher unbefriedigendes Unterfangen. Es wäre sinnvoll und wünschenswert eine
automatisierte Suche über den Daten zu entwickeln, die zum Einen effizient und mit
ausreichender Tiefe operiert.
Beim Lesen des Vorgehens eines Biologen auf der Suche nach den Informationen die
er wünscht, stellt sich eventuell die Frage, warum keine einheitliche, integrierte Datenbanklösung
entwickelt wurde. Zum Einen sind die Daten nicht auf einmal entstanden.
Es war ein langwieriger Prozess bis die heutige Datenmenge erforscht war. Somit hatte
jedes Projekt zunächst seine eigene Datenmengen. Deshalb ist es nur nachvollziehbar,
dass die einzelnen Datenbestände stark heterogen sind und es daher, wenn überhaupt,
nur sehr schwer möglich ist, eine gesamt-integrierte Lösung zu finden. Aus diesem Grund
gibt es viele Web-Portale, die die Daten zu den entsprechenden Experimenten zur Verfügung
stellen und über Hyperlinks auf andere Datenbestände verweisen. Durch diese
Verzweigung ist es möglich neue Informationen zu gewinnen, da jede Referenz zusätzliche
Informationen zum ursprünglichen Datensatz liefert. Auf diese Art und Weise ist die
Struktur der Proteomics-Datenbank entstanden. Aus exportierten flachen Dateien des
Uni-Prot Datensystems ging vor allem die Struktur der Proteomics-Datenbank hervor.
Zusätzliche Daten zu einzelnen Teilbereichen wurden dann aus weiteren Datenquellen
gewonnen und in den Datenbestand der Proteomicsdatenbank integriert.
Die Proteomics-Datenbank wurde dann zur Generierung von Graphen verwendet.
Dabei wurde eine Tiefensuche über den Fremdschlüsselattributen durchgeführt. Das Resultat
ist eine Menge von Graphen. Genau diese Graphen spiegeln das Suchen der Biologen
im Netz wieder. Auf der Basis dieser Graphen ist es nun möglich den Suchprozess
zu automatisieren und somit das versteckte Wissen der Verzweigungsstruktur nutzbar
zu machen.
Die eben gelieferte Motivation sollte einerseits zeigen welchen biologischen Wert bzw.
Hintergrund dieses Tool hat und auf der anderen Seite wie die Datenstruktur zur Bewältigung
der automatisierten Verarbeitung dieser Vorgänge entstand. Im nachfolgenden
Abschnitt wird zunächst kurz Zielstellung dieser Arbeit eingegangen.
1.2 Zielstellung
Das Ziel dieser Arbeit ist ein Konzept zur Anfrageverarbeitung auf Basis einer Menge
von bereits vorberechneten Graphen. Diese Graphen basieren auf Verlinkungen zwischen
den Web-Portalen von Datenbestände, wie im vorherigen Abschnitt beschrieben. Dabei
soll bei der Anfrage analysiert werden, ob, ausgehend von einer Menge von Startwerten,
Zusammenhänge mit einer gewünschten Zielwertmenge bestehen. Ausserdem soll es
möglich sein Pfade zu charakterisieren, um Zusammenhänge verwerfen zu können, die
über semantisch unrelevanten Pfaden entstanden sind.

Kapitel 1. Einleitung 5
Nachdem die Zielstellung erläutert wurde, soll jetzt eine Beschreibung der Gliederung
der Arbeit erfolgen.
1.3 Gliederung der Arbeit
Im folgenden Abschnitt wird die Gliederung der Arbeit kurz erläutert. Dazu werden eine
paar beschreibende Worte, wie der Name der Kapitelüberschrift sowie eine Zusammenfassung
des wesentlichen Inhalts, zu jedem Kapitel formuliert.
Einleitung gibt einen Einblick in die Problematik. Sie beschreibt motivierend welche
Hilfestellung das Konzept und letzten Endes auch das Tool leisten soll.
Gundlagen In dieser Arbeit werden verschiedene Anfragesprachen-Technologien angesprochen.
Um einen Einblick in diese Technologien zu bekommen, werden in diesem
Kapitel u.a. die Technologien und Konzepte erläutert auf denen diese Anfragesprachen
arbeiten. Im wesentlichen werden dies Datenbankmodelle und Dokumentenstrukturen
sein. Ausserdem soll in diesem Kapitel grundlegend der Biologische
Hintergrund erläutert werden, um die zu verarbeitetenden Daten besser zu verstehen.
Anfragetechnologien über Graphenstrukturen Dieses Kapitel wird die untersuchten
Anfragekonzepte erläutern und sie hinsichtlich verschiedener Kriterien bewerten.
Entwurf des Offlinewerkzeugs Der Kern dieses Kapitel ist die Beschreibung des Entwicklungsprozesses
des Offlinewerkzeugs. Dazu wird sich dem Softwarelebenzyklus
bedient, um kurz die einzelnen Phasen der Entstehung des Softwaretools zu beschreiben.
Zusammenfassung und Ausblick Hierbei wird noch einmal die gesamte Arbeit resümiert
und ein kleiner Ausblick gegeben.
Nachdem jetzt die Gliederung der Arbeit gegeben wurde, wird jetzt auf die in dieser
Arbeit verwendeten stilistischen Mittel eingegangen.
1.4 Technische Hinweise
1.4.1 Extended Backus-Naur Form (EBNF) der XML Spezifikation
des W3C
Die Extended Backus-Naur Form wird im Kapitel 3 verwendet. Sie wird in der W3C
Recommendation zur Extensible Markup Language [BPSM + 04] definiert. Dort wird die

6 1.4. Technische Hinweise
vollständige Definition gegeben. Diese Grammatik besteht aus einer Menge von Regeln
der Form:
symbol ::= e x p r e s s i o n
Listing 1.1: Produktionsregel zur Definition eines neuen Symbols
Jede Regel definiert eine neues Symbol. Symbole beginnen mit einem Großbuchstaben,
wenn sie Startsymbole eines regulären Ausdrucks sind, ansonsten werden sie
kleingeschrieben. Strings werden quotiert.
Die folgenden Ausdrücke dienen zum Vergleich von Zeichketten mindestens der Länge
eins:
#xN wobei N eine hexadezimaler Wert ist. Der Ausdruck entspricht dem Zeichen, dessen
(code point) im IS0/IEC 10646 Standard N entspricht. Anführende Null-Ziffern
werden nicht beachtet.
[a-zA-Z], [#xN-#xN] entspricht jedem Zeichen, dessen Wert im angegeben Bereich
liegt.
[abc], [#xN#xN#xN] entspricht jedem Zeichen, dessen Wert in der Aufzählung vorkommt.
Aufzählungen und Bereichsangaben können zusammen innerhalb eines
Klammerpaares verwendet werden.
[^a-z], [^#xN-#xN] entspricht jedem Zeichen, dessen Wert keinem der Wert entspricht,
die durch die Bereichsangabe beschrieben werden.
[^abc], [^#xN#xN#xN] entspricht jedem Zeichen, dessen Wert keinem der angegeben
Werte entspricht. Aufzählungen und Bereichsangaben von verbotenen Werten
können zusammen innerhalb eines Klammerpaares verwendet werden.
”string” entspricht einem String, der innerhalb der Gänsefüßchen angegeben wurde.
’string’ entspricht einem String, der innerhalb der Hochkommas angegeben wurde.
Symbole können wie folgt zu komplexen Pattern zusammengesetzt werden, dabei sind A
und B einfache Ausdrücke:
(expression) expression wird als Einheit aufgefasst und kann wie hier beschrieben verwendet
werden.
A? entspricht A oder nichts; Optionalität.
A B entspricht der Folge von A und B. Diese Operation ist stärder bindend als die
oder-Verknüpfung; somit ist A B | C D identisch mit (A B) | (C D).
A | B entspricht A oder B.

Kapitel 1. Einleitung 7
A - B entspricht jedem String der A entspricht und nicht B entspricht.
A+ entspricht einem oder beliebig vielen A. Die Konkatenation ist stärker bindend als
die oder-Verknüpfung; somit ist A+ | B+ identisch zu (A+) | (B+).
A* entspricht keinem oder beliebig vielen A. Die Konkatenation ist stärker bindend als
die oder-Verknüpfung; somit ist A* | B* identisch zu (A*) | (B*).
Weiter Notationen die in den Produktionsregeln auftreten sind:
/* . . . */ Kommentar.
[wfc: . . . ] die Wohlgeformtheitsbedingung; well-formedness constraint; this identifies by
name a constraint on well-formed documents associated with a production.
[vc: . . . ] die Gültigkeitsbedingung; validity constraint; this identifies by name a constraint
on valid documents associated with a production.
1.4.2 UML
Dieser Abschnitt erklärt kurz die in den folgenden Kapiteln verwendeten Diagrammarten.
Begonnen wird mit dem Aktivitätsdiagramm.
Aktivitätsdiagramm
Das Aktivitätsdiagramm dient zur Beschreibung von Aktivitätsabläufen. Dabei unterstützt
es parallele Abläufe und bietet eine verzweigte Prozessstruktur. Die Abbildung 1.2
beschreibt die Notation des Aktivitätsdiagramms. Mit einer Splittung wird eine parallele
Auführung gestartet. Und die Synchronisation synchronisiert parallele Abläufe. Die
Synchronisation entspricht einem logischen UND. Verzweigungen verhalten sich sich wie
if-then-else Konstrukte und steuern somit den Prozessfluss. Die Zusammenführung stellt
Semantisch ein logisches ODER dar. Wird midnestens ein Eingangspfeil durchlaufen so
wird auch der Ausgangspfeil durchlaufen.
Die gestichelten Pfeile werden im Dumke als Zustandserzeugung bezeichnet. Diese
können als Objektfluss interpretiert werden. Zunächst wird ein gewisses Objekt aus einer
Aktion heraus erzeugt und dann an anderer Stelle verwendet. Neben den eigentlichen
Aktivitäten kennzeichnet das Aktivitätsdiagramm auch einen zeitlichen Verlauf. Da es
eine Folge von zeitlich aufeinanderfolgenden Aktivitäten beschhreibt.
Nach diesem Einblick in die Problematik und die Gliederung der Arbeit wird im Weiteren
die in der Entwicklung entstandenen Lösungen vorgestellt. Dabei wird im nächsten
Kaptitel auf die notwendigen Grundlagen eingegangen.

8 1.4. Technische Hinweise
Abbildung 1.2: Notation des Aktivitätsdiagramms [Dum00]
!
!

Kapitel 2. Grundlagen 9
Kapitel 2
Grundlagen
Im Kapitel Grundlagen werden verschiedene Themengebiete einführend beschrieben. Es
werden Begriffe eingeführt die zum Verständnis notwendig sind. Zu Beginn werden allgemeine
biologische Begriffe erklärt. Diese sind für das Verständnis der Informationen der
Proteomics-Datenbank nötig. Daraufhin wird die Struktur der Proteomics-Datenbank
selbst erläutert und deren Komponenten mit kurzen inhaltlichen Erläuterungen versehen.
Anschließend daran werden Datenbankmodell beschrieben, die später die Grundlage
für die Analyse der Anfragetechnologien bilden. Zusätzlich zu den Datenbankmodellen
wird der Aspekt der Dokumentenverarbeitung durch Markup Sprachen erläutert. Abschließend
werden einige grundlegende Begriffe der Graphentheorie beschrieben.
2.1 Biologische Grundlagen
Auf der Basis der Desoxyribosenukleinsäure (kurz DNS) arbeitet der Zweig der Molekularbiologie
bzw. der Genetik. Was ist unter diesem Objekt zu vestehen? Aus chemischer
Sicht handelt es sich bei der DNS um ein riesiges Kettenmolekül. Wie der Name schon
verrät, ist es also eine Kette von Molekülen. Die charakteristische Eigenschaft einer Kette
ist, daß sie aus Gliedern besteht. Die Glieder der DNS sind die Nukleotide. Dabei
besteht jedes Nukleotid aus drei Bestandteilen:
• Base (Adenin, Thymin, Guanin, Cytosin)
• Desoxyribose-Zucker
• Phosphat
Neben der DNS gibt es eine weitere Nucleinsäure die sogenannte RNS. Sie ist vom
Aufbau her einem DNS-Einzelstrang sehr ähnlich. Prinzipiell sogar identisch, jedoch gibt
es zwei wesentliche Unterschiede. Erstens, das Zuckermolekül ist Ribose, nicht wie bei der
DNS die Desoxyribose. Zweitens, aus Thymin wird Urazil. Die RNS spielt eine wichtige
Rolle bei der Genexpression.

10 2.2. Aufbau der Proteomics-DB
Es stellt sich nun die Frage, was unter Genexpression zu verstehen ist. Kurz und bündig
gesagt, ist es ein Prozess, der aus zwei Teilprozessen besteht. Diese Teilschritte sind
unter dem Namen Transkription und Translation bekannt. Sie laufen in der genannten
Reihenfolge ab und, zusammenfassend gesagt, werden dabei unter Verwendung des genetischen
Codes Proteine erzeugt. Was genau dahinter steckt soll an dieser Stelle nicht so
wichtig sein. Wichtig zu wissen ist jedoch, daß aus Nukleotidsequenzen Proteine erzeugt
werden.
Viele Aufgaben und Steuerungen werden von den Proteinen bewältigt und organisiert.
Aus diesem Grund ist es von Interesse, welche Proteinen in einem Organismus
vorliegen. Dies führt uns zum Begriff der Proteomik. Die Proteomik (englisch: proteomics)
umfasst die Erforschung des Proteoms, d.h. der Gesamtheit aller in einer Zelle oder
einem Lebewesen exprimierten Proteine.[Wik]
In der Tabelle 2.1 wird eine Übersicht über Fragestellungen und Methoden der Informationsgewinnung
gegeben. Die Methoden sollen hier nicht weiter genau aufgeführt
werden. Der interessante Teil der Tabelle ist der der Proteinexpression. Daran läßt sich
erkennen, daß der Begriff der 2D-Page als ein Synonym für die Gelelektrophorese anzusehen
ist.
Fragestellung Technik
Proteinsequenzierung Edman-Sequenzierung
Proteinidentifikation Massenspektrometrie (MALDI-TOF,
ESI-MS/MS, LC-MS/MS)
3-D-Struktur Röntgenbeugungsanalyse (XRD), NMR
Proteinexpression Gelelektrophorese (2D-PAGE),
Proteinarrays
Proteinfunktion/ Yeast-2-Hybrid-Systeme
Protein-Protein-Interaktion
Tabelle 2.1: Gegenüberstellung von Fragestellungen in der Proteomik und den zugeörigen
Verfahrenstechniken zur Informationsgewinnung [Wik]
2.2 Aufbau der Proteomics-DB
Die Proteomics-Datenbank ist die Grundlage für die Anfragen. Sie enthält die Daten,
die Ableitung zu bestimmten Fragestellungen hinsichtlich der Annotation von EST-
Sequenzen und den mit diesen in Verbingung stehenden Proteinen ermöglicht. Die Herkunft
der Daten ist weit gefächert. Weltweit gibt es diverse Projekte, die sich mit der
Analyse von Proteomen beschäfftigen und ihre Forschungsdaten auf Webseiten zur Verfügung
stellen.
Dort ist es möglich die frei verfügbaren Daten herunterzuladen. Auf diesem Sachverhalt
basiert der Datenbestand der Proteomics-Datenbank. Es wurden Datendateien vom

Kapitel 2. Grundlagen 11
Uni-Prot System heruntergeladen und mittels eines Parser ausgelesen. Dabei entstand
die Struktur der Proteomics-Datenbank.
Die Abbildung 2.1 stellt einen Ausschnitt aus dem kompletten Datenbankschema dar.
Das vollständige Schema besteht aus 84 Tabellen. Dieses Schema unterliegt Veränderungen.
Es können neue Tabellen hinzugefügt werden oder eventuell vorhandene Tabellen
gelöscht werden.
Im Folgenden werden die im aktuell vorliegenden Datenbankschema aufzufindenden
Relationenschemata aufgelistet und bezüglich ihres Inhalts kurz erläutert. Diese Auflistung
erhebt keinen Anspruch der Vollständigkeit. Ihre Aufgabe soll hierbei nur zur
Beschreibung der für diese Arbeit grundlegenden Daten dienen.
MaizeDB http://www.maizegdb.org/ Maize Genetics/Genomics Database project;
allgemeine biologische Informationen über Mais
Tuberculist-Link http://genolist.pasteur.fr/TubercuList/; Daten rund um die
Analyse des Tuberkelbazilus; dieses Projekt umfasst Informationen zu DNS-
Strängen und Proteinsequenzen gewonnen aus dem Beispielbakterienstamm (paradigm
strain??) M. tuberculosis H37Rv (M. –> Mycobacterium).
Listi-Link http://genolist.pasteur.fr/ListiList/; hervorgegangen aus The Listeria
Monocytogenes and Listeria innocua genomes sequencing project; enthält
Daten entstanden bei der Analyse des Erregers Listeria monocytogenes und seines
nicht-krankheitserregenden Verwandten Listeria innocua
Subti-Link http://genolist.pasteur.fr/SubtiList/; hervorgegangen aus The Bacillus
subtilis genome sequencing project; enthält Daten entstanden aus der Analyse
des Genoms des Bacillus subtilis
MypuList-Link http://genolist.pasteur.fr/MypuList/help/about.html; hervorgegangen
aus The Mycoplasma pulmonis genome sequencing project; enthält
Daten entstanden aus der Analyse des Genoms vom Mycoplasma pulmonis
Leproma-Link http://genolist.pasteur.fr/Leproma/; hervorgegangen aus dem
The Mycobacterium leprae genome sequencing project; enthält Daten die aus der
Analyse des Lepra verursachenden Bazillus Mycobacterium leprae
SGD-Link Bestandteil von Forschungen an der Stanford University (Stanford Genomic
Resources); SGD steht für Saccharomyces Genome Database; sie beinhaltet molekularbiologischen
und -genetische Daten über Hefe (saccharomyces cerevisiae), die
übliche Hefe zum Backen
SagaList-Link http://genolist.pasteur.fr/SagaList/; original Daten stammen
aus dem The Streptococcus agalactiae genome sequencing project; Datenbank die
Daten enthält, die aus der Analyse des Genoms des Erregers Streptococcus agalactiae
(durch Nahrung übertragen)

12 2.2. Aufbau der Proteomics-DB
Abbildung 2.1: Ausschnitt aus dem Datenbankschema der Proteomics-DB

Kapitel 2. Grundlagen 13
PIR-Link http://pir.georgetown.edu/home.shtml; bereits seit 1984 laufendes Projekt,
welches eine Datenbank PSD oder auch PIR-PSD (Protein Sequence Database)
pflegt um funktionale Annotationen bereitzustellen; aktuell ist es integriert in
der UniProt Wissenbasis
PROSITE-Link
Swiss2DPage-Link
Hamap-Link http://www.expasy.org/sprot/hamap/; Teil vom ExPASy; beinhaltet
Daten zu Proteinfamilien, -profilen und -alignments; steht in Verbindung mit Swiss-
Prot und TrEMBL
Interpro-Link http://www.ebi.ac.uk/interpro/; Bestandteil des EMBL-EBI ; eine
Datenbank über Daten von Proteinfamilien, -domänen und functional sites
ProDom-Link http://protein.toulouse.inra.fr/prodom/current/html/home.
php; automatisch Generierte Menge von Proteindomänfamilien aus der Swiss-
PROT und TrEMBL Datenbank.
TIGR-Link http://www.tigr.org/; eine Ansammlung von mehreren Datenbanken
entstanden aus den Genom Projekten TIGR’s; gegründet 1992; diverse Daten
von Proteinensequenzen, DNA-sequenzen, Taxonomiedaten, Genexpressionsdaten,
Proteinfamilien etc...
TIGRFams-Link http://www.tigr.org/TIGRFAMs/; eine der TIGR-Datenbanken;
enthält Proteinfamilien entsprechend den Hidden Markov Models (HMM)
PRINTS-Link http://umber.sbs.man.ac.uk/dbbrowser/PRINTS/; ist eine übersicht
an Protein ”Fingerabdrücken”; Ein Fingerabdruck ist dabei eine Menge von
Motiven, die eine bestimmte Protein-Familie charakterisieren
PDB-Link Datenbank über 3D Abbildungen von Makromolekülen
EMBL-Link http://www.embl.org/; EMBL (European Molecular Biology Laboratory)
ist ein wissenschaftliches Institute gefördert durch seine 17 Migliedsstaaten;
es besteht aus 5 Einheite: dem Hauptsitz in Heidelberg und den0 Aussenstelle in
Hixton (EBI), Grenoble, Hamburg und Monterotondo (bei Rom); in der EMBL-
Datenbank werden Nukleotidsequnzen gespeichert, die in einer internationalen Zusammenarbeit
mit der GenBank(USA) und der DNA Database of Japan (DDBJ)
produziert wurde
EcoGene-Link http://bmb.med.miami.edu/EcoGene/EcoWeb/; eine Ansammlung
von Genen, Proteinen zum E.coli K-12 Genom and Proteom, welche aus sequenzierungsanalysen

14 2.2. Aufbau der Proteomics-DB
ZFIN-Link http://zfin.org/cgi-bin/webdriver?MIval=aa-ZDB_home.apg; The
Zebrafish Information Network; ein Fisch der in der Genforschung von Wirbeltieren
als Modell Organismus genutzt wird; enthält? wahrscheinlich
WormPep-Link http://www.sanger.ac.uk/Projects/C_elegans/; enhält Proteininformationen,
die aus dem Caenorhabditis elegans genome sequencing project
hervorgehen
Genew-Link http://nar.oupjournals.org/cgi/content/full/30/1/169; the Human
Gene Nomenclature Database; Daten über Gene des Menschen
Rebase-Link http://rebase.neb.com/rebase/rebase.html; The Restriction Enzyme
Database; Daten über Restriktionsenzymen
siena2Dpage-Link http://www.bio-mol.unisi.it/2d/2d.html; Two-dimensional
polyacrylamide gel electrophoresis database; University of Siena, Italy; Gelelektrophoresis
Abbildungen von menschlichen Genen
PHCI-2Dpage-Link http://www.gram.au.dk/ Department of Medical Microbioloy
and Immunology, University of Aarhus, Denmark; Gelelektrophoresebilder von Proteinen
des Parasits Chlamydia trachomatis, Chlamydia pneumoniae und Proteinen
von HeLa cell; Chlamydien sind Paraiten die den Uretaltrakt infizieren (Eileiter
schädigen und zur Unfähigkeit des Kinder kriegens führen)
Merops-Link http://merops.sanger.ac.uk/; Informationen zu Peptidasen und Proteinen
die diese in ihrer Wirkungsweise hemmen; Peptidasen sind Protein- und
Peptidspaltende Enzyme
ANU-2D-Link http://semele.anu.edu.au/2d/2d.html; Proteininformationen von
Reis (Oryzita sativa) und zur Medicago truncatula, einer im Mittelmeer beheimateten
Verwandten der Luzerne und Modellpflanze für Genomforschung an Leguminosen
(=Hülsenfrüchtler)
GlycosuiteDB-Link https://tmat.proteomesystems.com/glycosuite/; Informationen
über Polysaccharide (Kohlenhydrate) wie Typ, Verbindung, anormerische
konfiguration, Masse; erstellt Querverweise zur Swiss-Prot/TrEMBL und PubMed
DictyDB-Link http://www-biology.ucsd.edu/others/dsmith/dictydb.html#C;
Informationen zur Amöbe Dictyostelium discoideum (z.B. Gene, Gene Ontology
Terms, Gen Produkte); jetzt DictyBase http://dictybase.org/
StyGene-Link http://www.expasy.org/cgi-bin/get-entries?DR=StyGene; Salmonella
typhimurium LT2 genome database; eine Salmonellenart die Thyphus
verursacht; Thyphus ist eine fieberhafte Infektionskrankeit begleitet durch
Durchfall; Salmonellen sind eine Art der Enterobakterien (Darmbakterien)

Kapitel 2. Grundlagen 15
CompluYeast-2D-Link http://babbage.csc.ucm.es/2d/2d.html; Projekt an der
Universidad complutense Madrid, Spanien; Gelelektorphoresebilder von Genen des
Hefepilzes (Candida albicans) und der Backhefe (Saccharomyces cerevisiae)
Gramene-Link http://www.gramene.org/; A Resource for Comparative Grass Genomics;
Aufgrund von ähnlichkeiten können Aussagen getroffen werden, die für mehrere
Getreidearten (Roggen(rye),Gerste(barley),Mais(maize)) gelten; Basis dafür
ist das Reis Genom; diese Wissen soll genutzt werden um einerseits eine Identifikation
und andererseits ein Verständnis für Gene, Enzymatische Wege und Phenotypen
in Feldfrüchten zu entwickeln
HSC-2DPage-Link http://www.doc.ic.ac.uk/vip/hsc-2dpage/index.html; Proteininformationen
aus den Ventrikeln des Herzes vom Menschen, Hunden und Ratten,
sowie den in den Blustbahnen des Menschen befindlichen Zellen endothelial
cells
Pfam-Link http://www.expasy.org/cgi-bin/dbxref?Pfam; Protein families database
of alignments and HMMs;
Phossite-Link http://ca.expasy.org/cgi-bin/dbxref?PhosSite; Proteine von
Prokaryotischen Organismen, welche eine sogenannte kovalente Phosphorylation
an ihren hydroxyl Randketten der Serin-, Threonin- und/oder Thyrosin-Reste
FlyBase http://flybase.bio.indiana.edu/; Daten über die Drosophila melanogaster
2.3 Datenbankmodelle
2.3.1 Relationale Datenbanken
Das Relationenmodell wurde 1970 von Codd eingeführt. Im wesentlichen werden Relationschemata
definiert. Jedes Relationsschema umfaßt eine bestimmt Menge von Attributen.
Diesen Attributen werden bestimmte Wertebereiche (integer, string, etc.) zugeordnet.
Bisher ist es eine Beschreibung der Daten. Die Daten selber werden durch die
Relationen beschrieben. Eine Relation ist eine Teilmenge des Kreuzprodukts der Wertebereiche
der Attribute des Relationenschemas, über welchem die Relation gebildet wird.
Jedes Element einer Relation wird als Tupel bezeichnet. Ein Datenbankschema ist eine
Menge von Relationenschemata. Es ist also die Beschreibung einer Datenbank. Die
Datenbank selbst, ist die Instanz des Datenbankschemas [HS00].
Um sich Relationenschemata und Relation besser vorstellen zu können, kann man
sich diese Begriffe als Tabelle veranschaulichen, wobei deren Tabellenkopf dem Relationenschmema
der Relation entspricht. In Abbildung 2.2 wird eine Relation in ihrer
tabellarischen Form dargestellt.

16 2.3. Datenbankmodelle
Attribute
Sei U eine nichtleere, endliche Menge, das Universum der Attribute. Ein Element A ɛ U
heißt Attribut. Sei D = {D1, . . . , Dm} eine Menge endlicher, nicht-leerer Mengen mit
m ɛ N . Jedes Di wird Wertebereich oder Domäne genannt. Es existiert eine total
definierte Funktion dom: U → D. dom(A) heißt Wertebereich von A. Ein w ɛ dom(A)
wird Attributwert für A genannt. [HS00]
Relationenschemata und Relationen
Eine Menge R ⊆ U heißt Relationenschema. Eine Relation r über R = {A1, . . . , An}
(kurz r(R)) mit n ɛ N ist eine endliche Menge von Abbildung
m
t : R −→ Di
i=1
die Tupel genannt werden, wobei t(A) ɛ dom(A) gilt. t(A) ist dabei die Restriktion der
Abbildung t auf A ɛ R . Für X ⊆ R heißt die Einschränkung der Abbildung t auf X
(bezeichnet mit t|X oder ebenfalls vereinfachend mit t(X )) X -Wert von t. [HS00]
Datenbankschema und Datenbank
Eine Menge von Relationschemata S := {R1, . . . , Rp} mit p ɛ N heißt Datenbankschema.
Ein Datenbankwert (kurz: Datenbank) über einem Datenbankschema S ist eine Menge
von Relationen
d := {r1, . . . , rp},
wobei ri(Ri) für alle i ɛ {1, . . . , p} gilt. Eine Datenbank d über S wird mit d(S) bezeichnet,
eine Relatioin r ɛ d heißt Basisrelation. [HS00]
Integritätsbedingungen
Beim Relationenmodell ist es möglich identifizierende Attributmengen für ein Relationenschema
anzugeben. Sind die Attributmengen beüglich der Teilmengeninklusion ⊆
Relationname Attribute
R A1 … An
…
… Relation
… Tupel
Relationenschema
Abbildung 2.2: Graphische Notation eines Relationenschmas [HS00]

Kapitel 2. Grundlagen 17
minimal, werden sie als Schlüssel für das Relationenschema bezeichnet. Ferner sei ein Primärschlüssel,
ein von einem Datenbankadministrator speziell ausgezeichneter Schlüssel.
[HS00] Eine identifizierende Attributmenge für ein Relationenschema R ist eine Menge
K := {B1, . . . , Bk} ⊆ R, so das für jede Relation r(R) gilt [HS00]:
Lokale Integritätsbedingung
∀t1, t2 ∈ r[ t1 = t2 =⇒ ∃B ɛ K : t1(B) = t2(B) ].
Durch die lokalen Integritätsbedingungen werden alle Relationen zu einem Relationenschema
auf true oder false abgebildet. Es existieren somit Relationen, die die Bedingungen
erfüllen und solche die sie nicht erfüllen. Lokale Integritätsbedingungen für ein
Relationenschema R sind Abbildungen b ɛ B
b : {r|r(R)} → {true, false}
von der Menge aller Relationen über R auf die Wahrheitswerte. [HS00]
Fremdschlüssel
Ein Fremdschlüssel ist eine Attributliste X in einem Relationenschema R1, wenn in einem
Relationenschema R2 eine kompatible Attributliste Y Primärschlüssel ist und die
Attributwerte zu X in der Relation r1(R1) auch in den entsprechenden Spalten Y der
Relation r2(R2) enthalten sind. Wir haben von Attributlisten anstelle von Attributmengen
gesprochen, um deutlich zu machen, daß eine eindeutige Zuordnung zwischen den
beteiligen Attributen existieren muß.
Eine Fremdschlüsselbedingung für eine Relation r1(R1) ist ein Ausdruck
X(R1) −→ Y (R2)
mit X ⊆ R1, Y ⊆ R2. X nennt man dann Fremdschlüssel für R1 bezüglich Y in R2.
[HS00]
2.3.2 Objektdatenbanken
Objektdatenbankmodell basieren auf Objektdatenbankmodellen. Diese Objektdatenbankmodelle
beinhalten grundlegende objektorientierte Konzepte. In diesem Abschnitt
werden diese Grundkonzepte kurz erläutert.
Der Zentrale Begriff im Umfeld der Objektorientierung ist der Begriff des Objekts.
Ein Objekt ist eine Modellierungseinheit, die eine eingekapselten Zustand (die aktuelle
Attributwertmenge) hat und ausserdem Operationen (Methoden) besitzt bzw. bereitstellt.
Objekte können miteinander kooperieren, indem sie Botschaften austauschen. Dabei
greift der Sender einer Boschaft auf Dienste des Empfängers zu. Die Dienste sind
gerade die Methoden bzw. Operationen die der Empfänger der Botschaft bereitstellt.

18 2.3. Datenbankmodelle
Die vom Sender aufgerufene Operation kann Veränderungen im Zustand des aufgerufenen
Objekt hervorrufen. Weiterhin besteht die Möglichkeit ein Ergebnisse an den Sender,
der die Botschaft geschickt hat, zurückzuschicken. [STS97]
Neben dieser allgemeinen Definition eines Objekts ist ein weiterer Aspekt, insbesondere
für die Modellierung eines bestimmten Sachverhalts, von Bedeutung. In den meisten
objektorientierten Systemen wird eine Trennung zwischen den Begriffen Objekt und Wert
getroffen. Soll nun ein Sachverhalt als Objekt oder Wert modelliert werden? Um dies zu
entscheiden sind die folgenden Unterscheidungsmerkmale zwischen Werten und Objekten
hilfreich führen jedoch nicht immer zu einer eindeutigen Entscheidung [STS97]:
• Objekte
• Werte
– haben einen veränderbaren Zustand
– besizten zustandsunabhängige Identitäten
– werden explizit bei der Modellierung eines bestimmten Problembereichs entworfen
– haben einen unveränderbaren Zustand
– werden durch sich selbst identifizert
– sind in der Regel von Typsystem vorgegeben
Wie schon im ersten Absatz dieses Abschnitts definiert sich ein Objekt über seinem
Zustand und seinem Verhalten. In den folgenden Absätzen wird auf die Möglichkeiten
der Definitionen von Attributen eingegangen, denn die Attribute definieren den Zustand
eines Objekts. Weiterhin wird Objektverhalten anhand der Methoden bzw. Operationen
des Objektes erläutert.
Attribute und Datentypen
Attribute eines Objekts sind Modellierungsmittel, mit deren Hilfe bestimmte Objekteigenschaften
ausgedrückt werden. Beim Entwurf eines Objektes wird eine Menge von
Attributnamen festgelegt, wobei jedem Attributnamen eine Datentyp zugeordnet wird.
Zur Laufzeit werden den Attributen des Objekts Werte zugewiesen. Diese Wertemenge
wird dabei vom Datentyp festgelegt. Der Datentyp bestimmt ausserdem welche Operationen
auf dessen Werte ausgeführt werden können. Anders formuliert ergibt sich der
Zustand eines Objekts in einem bestimmten Zeitpunkt aus den momentan angegebenen
Werten aller Attribute der Attributmenge des Objekts.
Ein objektorientes System stellt eine Menge von vordefinierten Datentypen bereit
und erlaubt durch Typkonstruktoren neue Datentypen zu definieren. Vor allem dies
unterscheidet ODBMS von RDBMS. In relationalen Datenbanksystemen verwirklichen

Kapitel 2. Grundlagen 19
das Relationenmodell, welches nur den Datentyp Relation erlaubt 2.3.1. Also eine Menge
von Tupel, die wiederum eine Menge von Attributen sind die einem atomaren Datentyp
zugeordnet werden.
Im objektorientierten System gibt es neben den elementaren Datentypen, meist integer,
boolean, char etc., sogenannte parametrisierbare Datentypen (auch Typkonstruktoren
genannt). Diese arbeiten auf der Basis der elementaren Datentypen und und sind
beliebig miteinander verschachtelbar. In einem objektorientierten System werden dabei
üblicherweise eine Menge von Standardtypkonstruktoren vordefiniert. Dazu gehören die
Typkonstruktoren Tupel, Set, Bag, List und Array. Für eine nähere Erläuterung der
einzelnen Typkonstruktoren wird auf Buch [STS97] verwiesen. Eine Sonderrolle nimmt
der Aufzählungsdatentyp ein. Durch die explizite Angabe aller möglichen Werte wird
dieser Typ definiert. Er definiert weder einen neuen Datentyp, noch ist er vom System
vordefiniert.
Methoden
Die Einheit aus Zustand und Verhalten beschreibt ein Objekt. Zuvor wurde erläutert
wie sich der Zustand eines Objekts definiert. Nun soll das Verhalten dargestellt werden.
Unter dem Verhalten eines Objekts ist die Gesamt der Funkionalität des Objekts zu
verstehen. Ausgedrückt wird diese Funktionalität durch das Definieren von Methoden.
Methoden sind Programmiersprachenkonstrukte die in der Regel folgende Bestandteile
besitzen:
Methodenname dient zur Idenfikation der Methode
Übergabeparameter sind Variablen, denen beim Aufruf der Methode Werte zugewiesen
werden und Einfluß auf die Abarbeitung der Methode nehmen
Rückgabeparameter dient zur Rückgabe von Werten an den Aufrufer der Methode
Methodenrumpf hier wird die Funktionalität der Methode beschrieben
Der Methodenname, die Übergabeparameter und der Rückgabeparameter wird zusammen
auch als Methodensignatur bezeichnet.
Objektidentität
Der Begriff Objektidentität beschäfftigt sich mit dem Sachverhalt, daß es möglich sein
muss Objekte eindeutig identifiziert zu können. Wird diese Problematik mit relationalen
Datenbanksystemen verglichen, so ist das Konzept hierbei die Definition von Primärschlüsseln
zur Identfikation der Tupel einer Relation 2.3.1.
Nach Khoshafian und Copeland [KC86] ist Objektidentität die Eigenschaft eines Objektes,
die es von allen anderen Objekten unterscheidet. Identität wird somit für Objekte
betrachtet. Werte hingegen besitzen keine Identität. Sie definieren sich durch sich selbst.

20 2.3. Datenbankmodelle
Somit gibt es keine Zustandsänderung in Bezug auf Werte, so wie es bei Objekten der Fall
wäre. Bei Werte wird vom Übergang von einem Wert zu einem anderen Wert gesprochen.
Im Zusammenhang zur Objektidentität entsteht der Begriff des Objektidentifikators
(kurz OID). Da die Objektidentität nichts Konkretes darüber aussagt, wie die Objekte
unterschieden werden. Dafür verwenden objectorientierte Systeme Objektidentifikatoren.
Diese werden selbstständig vom System und unabhängig vom Nutzer verwaltet
und vergeben. Dabei werden gewisse Anforderungen an einen Objektidentfikator gestellt.
[STS97]
Diese Anforderungen sind an der Zahl vier:
1. Ein Objektidentifikator muß vom System vergeben werden.
2. Objektidentifikatoren müssen Objekte räumlich eindeutig identifizieren.
3. Objektidentifikatoren müssen Objekte zeitlich eindeutig identifizieren.
4. Der Wert eines Objektidentifikators darf nur dem System bekannt sein.
Unter räumlicher und zeitlich Eindeutigkeit ist im wesentlichen zuverstehen, daß
der Objektidentifikator in einem bestimmten Geltungsbereich bzw. innerhalb eines bestimmten
Zeitrahmens eindeutig sein muss. Eine nähere Beschreibung wird im [STS97]
gegeben.
Klassen und Beziehungen
Bisher war immer die Rede von einzelnen Objekten und deren Indentifikation über die
OID. In ODBMS ist es jedoch in der Regel der Fall, daß das System eine sich dynamisch
entwickelnde Anzahl von Objekten verwalten muss. Aus diesem Sachverhalt ergibt sich
der Begriff der Klasse. In objektorientierten Systemen wird bei einer Klasse von einer
Guppe von Objekten mit gleichen Merkmalen und gleichen Verhalten gesprochen.
Klassen entstehen durch Anwendung eines Abstraktionsprozesses, wobei versucht wird
Objekte in Klassen zu gruppieren. Im Kontekt der Abstraktion werden zwei Aspekte,
die unter dem Namen Intension und Extension einer Klasse bekannt sind. Die Intension
einer Klasse ist die Beschreibung der Merkmale und das Verhalten ihrer Objekte zu
verstehen. Es wird auch von der Festlegung des Objekttyps gesprochen, sprich der Attribute
und Methoden eines Objekts. Die Extension einer Klasse ist die Menge der aktuell
existierenden Objekte dieser KLasse. Bei den Objekten einer Klasse ist auch häufig die
Rede von Instanzen dieser Klasse. Eine Regel für Objekte ist das sie jederzeit mindestens
zu einer Klasse zugehörig sein muss. Die Zuordnung eines Objektes kann auf explizite
Weise (Instantiierung, Objektmigration, Rollen) oder implizite Weise, durch Prädikate
über dem Objektzustand, erfolgen.
Neben Objekt und Klassen ist es absolut notwendig Beziehungen zwischen den Objekten
einzubeziehen. Diese Beziehungen werden auf Ebene der Klassen abstrahiert und

Kapitel 2. Grundlagen 21
werden dann als Klassenbeziehung bezeichnet. Im Zusammenhang mit Klassenbeziehungen
fallen Begriffen wie Stelligkeit, Kardinalität, Beziehungsattribute, gerichtete Beziehungen
und inverse Referenzen. An dieser Stelle soll nur auf den Punkt der gerichteten
Beziehungen und inversen Referenzen kurz eingegangen werden. Diese zwei Aspekte behandeln
die Situation, daß in Entwurfsmodellen normalerweise symmetrische Beziehungen
angegeben werden, aber in Implementierungsmodellen Beziehungen in bestimmten
Richtungen definiert werden. Es wäre durchaus möglich eine symmetrische Beziehung im
Implementierungsmodell durch zwei gerichtete Beziehungen zu formulieren (einmal von
Objekt1 nach Objekt2 und zurück). Problem ist dann nur, daß die eigentliche Beziehung
durch zwei Beziehungen beschrieben wird und damit Redundanzen erzeugt werden. Um
das zu vermeiden, bieten Implementierungsmodelle inverse Referenzen an, indem die Definition
der Beziehung auf beiden Seiten (Objekt1 und Objekt2) durch die Angabe der
inversen Beziehung erweitert wird. Werden vom Implementierungsmodell keine inverse
Referenzen angeboten, so besteht die Möglichkeit die betreffenden Attribute innerhalb
von Methodenimplementierungen berechnen zu lassen.
Referentielle Integrität
Referentielle Integrität im Umfeld des Objektparadigmas fordert, daß beim Navigieren
über Referenzattributen immer nur gültige Objekte zurückgeliefert werden. Referenzattribute
können drei Zustände annehmen:
1. bei optionalen Referenzattributen kann ein NULL Wert zugeordnet werden, d.h.
eine nicht vorhandene Referenz liegt vor
2. eine Referenz zu einem vorhandenen Objekt
3. eine Referenz auf ein gelöschtes Objekt; stellt eine ungültige Referenz dar
Es gibt verschiedene Strategien ungültige Referenzen zu vermeiden. Eine ist solche
zu verbieten. In diesem Fall muss der Anwendungsprogrammierer dafür sorgen, daß es
zur Einhaltung dieser Forderung kommt. Eine weitere Strategie ist das Verhindern von
ungültigen Referenzen. Hierbei bietet das Implementierungsmodell eigene Methoden zur
Einhaltung der referentiellen Integrität. Eine letzte Variante ist das automatische Entdecken
und Löschen von ungültigen Referenzen. Hier ist das Stichwort ”garbage collection”
zu nennen. Es werden automatisch alle Objekte gelöscht auf denen keine Referenzen
mehr verweisen.
Neben der Objektidentität, der Referentiellen Integrität, den Begriffen Klassen, Beziehungen
und Objekts gibt es noch weitere Eigenschaften die im Objektparadigma mit
den Begriffen Polymorphie, Spezialisierung- und Generalisierungsbeziehung, Aggregation.

22 2.4. XML - hierarsche Datenstrukturen
2.4 XML - hierarsche Datenstrukturen
Die eXtensible Markup Language (XML) entwickelte sich aus der Standard Generalized
Markup Language (SGML). Generell verfolgen beide Ansätze den gleichen Kerngedanken.
Dieser umfasst das Definieren einer Markup Language oder auch Auszeichnungssprache.
Eine solche Sprache besteht aus einer Menge vom Einheiten, die dem eigentlichen
Text Meta-Informationen hinzugefügt. Diese Einheiten sind unter dem Begriff TAGS
bekannt. Die TAGS vereinen im wesentlichen zwei Funktionen, das Begrenzen und das
Beschreiben der Daten.
SGML ist eine sehr mächtige Sprache und es ist aufgrund dessen sehr schwierig einen
Parser zu entwerfen, der entsprechende Dateien verarbeiten kann. Aus diesem Grund begann
das World Wide Web Consortium (W3C) die XML zu entwerfen, mit dem Ziel die
Flexibiliät und Erweiterbarkeit von SGML zu erhalten und eine Akzeptanz vergleichbar
zur Akzeptanz von HTML zu erreichen. XML und SGML werden auch als Metasprache
bezeichnet. Dies resultiert aus der Eigenschaft von XML beliebig erweitert werden zu
können. Es ist durch XML möglich, für spezielle Anwendungsbereiche und -fälle spezifische
Sprachen zur Beschreibung der Dokumenteninformationen zu definieren. So wurde
zum Beispiel HTML durch XML definiert, auch bekannt als XHTML. Das Definieren
neuer Sprachen wird in der Literatur auch als Definition von XML-Vokabularen bezeichnet.
XHTML ist ein Vertreter aus der Menge der Vokabularen, die durch XML erzeugt
werden können.
Neben der Erweiterbarkeit besitzt XML noch weiter grundlegende Eigenschaften, die
im Folgenden kurz angesprochen werden.
Selbstbeschreibend
Ein XML-Dokument hat einen selbstbeschreibenden Charakter. In einem XML-
Dokument werden TAGS genutzt, um Elemente dieses Dokuments zu markieren. Jedes
TAG bzw. hat einen bestimmten Namen bzw. eine bestimmte Bezeichnung, die struktureller
aber auch semantischer Art sein kann. Dazu kann sich folgendes Beispiel forgestellt
werden: Im Listing 2.1 werden einfach mehrere Zahlen präsentiert, deren Semantik aus
dieser Darstellung nicht direkt erkannt werden kann.
10 10 97 10 10 "Motorwerk Haupttor "
11 10 97 06 00 " Flughafen B e r l i n Tegel "
Listing 2.1: Rohdaten ohne Marken
Im Listing 2.2 werden, durch das Setzen von Markierungen, die Daten für den Leser
interpretierbar, ohne weitere Informationen, wie zum Beipiel die Herkunft der Daten.
Das Dokument selbst enthält die Information um die Daten interpretieren zu können.

Kapitel 2. Grundlagen 23
10
10
97
10
10
Motorwerk Hauptor
Listing 2.2: Daten aus Listing 2.1 als XML
Trennung von Präsentation und Inhalt
Eine weitere Eigenschaft von XML ergibt sich direkt aus der Eigenschaft der Erweiterbarkeit.
Es ist möglich XML-Vokabulare 2.4 zu definieren, die es erlauben, Dokumente
sowohl inhaltlich wie auf die Präsentation bezogen auszuzeichnen, ohne die beiden
Ebenen zu vermengen. Dadurch ist es möglich, denselben Inhalt unterschiedlich zu
präsentieren.[WK03]
Wohlgeformtheit und Gültigkeit
Ein weiterer Begriff, der die Thematik XML begleitet, ist die Wohlgeformtheit von
XML-Dokumenten (engl. well-formed xml). Die Wohlgeformtheit besagt, daß jedes
XML-Dokument den Empfehlungen der XML 1.0 Spezifikation des W3C Folge leisten
muss. Die Wohlgeformtheit ist die Minimalanforderung an ein XML-Dokument.
Zusätzlich dazu kann einem XML-Dokument ein Dokumenttyp zugeordnet werde, was
den Gültigkeitsbegriff begründet. Ein Dokument ist genau dann gültig, wenn es den in
der Dokumenttypen-Beschreibung festgelegten Kriterien einhält. Die Definition solcher
Dokumenttyp-Beschreibung wird durch weitere W3C Standards wie DTD und XML
Schema. XML Schema wird im Abschnitt 2.4.1 genauer betrachtet.
Ein wohlgeformtes XML-Dokument besteht aus drei Teilen:
• einem optionalen Prolog
• dem Dokumentenkörper (engl. body), dieser enthält ein Element, welches der Wurzelknoten
eines hierarischen Baums von Elementen
• einem optionalen Epilog

24 2.4. XML - hierarsche Datenstrukturen
Die Abbildung 2.3 zeigt den Aufbau noch einmal schematisch. Der Body eines XML-
Dokuments besteht aus Blockstrukturen, den Elementen. Jedes Element hat einen Namen,
welcher in spitzen Klammern eingeklammert wird. Jedes Element hat eine Startund
End-Marke. Ein Element ist ein Sammelbehälter, der weitere Elemente, Text und
andere Auszeichnungen (wie Kommentare, Procession Instructions(PI), etc.) enthalten
kann.
Eine vollständig Defintion eines wohlgeformten Dokuments wird, wie schon erwähnt,
in der XML 1.0 Recommendation des W3C (http://www.w3.org/XML/Core/
#Publications) gegeben. Im folgenden Abschnitt 2.4.1 wird auf die Definition eines
Dokumenttyps durch die XML-Schema Technologie genauer betrachtet.
Abbildung 2.3: Schematische Darstellung des Aufbaus eines wohlgeformten XML-
Dokuments [ABK + 00]
2.4.1 XML-Schema
Validierende Parser benötigen Dokumenttypdefinition, um die Gültigkeit eines XML-
Dokumentes zu bestimmen. In der XML 1.0 Recommendation des W3C wird der Auf-

Kapitel 2. Grundlagen 25
bau einer XML DTD festgelegt. Jedoch bringen XML DTD’s einige Probleme mit sich
[ABK + 00]:
• sie sind nicht erweiterbar
• sie unterstützen keine Namespaces
• sie unterstützen keine Vererbung
• es gibt keine Unterstützung von Datentypen
Diese Probleme veranlaßten das W3C eine neue Variante zur Definition eines Dokumententyps
zu entwerfen. Dieses Vorhaben resultierte in der XML-Schema Spezifikation.
Diese Spezifikation teilt sich in zwei Teile auf:
XML-Schema Part 1: Structures behandelt die Defintion von Elementen und Attributen.
XML-Schema Part 2: Datatypes definiert eine Standardmengen von Datentypen
und Regeln um aus dieser Standardmenge neue Datentypen zu generieren.
Der Unterschied zwischen XML DTD und XML Schema wird am besten in einem
Beispiel deutlich. Im Listing 2.3 wird XML DTD verwendet um den Dokumenttyp ”name”
zu definieren. Im Listing 2.4 wird der gleiche Dokumenttyp definiet unter Anwendung
von XML-Schema. Das dritte Listing 2.5 zeigt, wie das ein in XML-Schema definierter
Dokumenttyp an ein XML-Dokument gebunden wird.
]
>
Martin
Andrea
Müller
Listing 2.3: Beispiel für XML DTD

26 2.4. XML - hierarsche Datenstrukturen
Ein Name besteht dabei mindestens aus einem Vor- und Nachnamen. Optional kann
vor dem Vornamen ein Titel, zwischen Vor- und Zunamen ein Mittelname und hinter
dem Nachnamen ein Suffix angegeben werden.
Listing 2.4: Beispiel für XML-Schema Instanz
Martin
Andrea
Müller

Kapitel 2. Grundlagen 27
Listing 2.5: Einbettung des im Listing 2.4 entworfenen Dokumenttyps
2.5 Grundlagen in der Graphentheorie
Um überhaupt Aussagen und Anfragen stellen zu können, müssen Begriffe, wie Graphen,
Kantenzug, Kreise und andere, näher erläut werden.
Der Begriff des Graphen wird in der Mathematik wie folgt definiert. Ein Graph G
ist ein Tupel G = (V, E), wobei V eine endliche Menge und E ⊆ V
2
eine Teilmenge
der zweielementigen Teilmengen von V ist. Die Elemente v ∈ V heißen die Knoten, die
Elemente aus e ∈ E die Kanten von G. Ein besonderer Reiz der Graphentheorie ist, daß
sich ihre Objekte leicht graphisch veranschaulichen lassen. Die Anzahl der Knoten eines
Grpahen G wird als die Ordnung von G beziechnet, die durchweg mit n := n(G) := |V |
notiert wird. Die Anzahl seiner Kanten, in Zeichen m := M(G) := |E|, heißt auch die
Größe von G. Ein Graph heißt gerade bzw. ungerade je nach Parität seiner Knotenmenge.
Für eine Kante {u, v} ∈ E werden die Knoten u und v ihre Endpunkte genannt. Das
Komplement (V,
V
\ E) eines Graphen wird notiert mit G. Ein Graph (V, ∅) ohne
2
Kanten heißt auch leer oder trivial. Sein Komplement, der Graph Kn := (V,
V
), heißt
2
vollständig; bei n Knoten hat er m =
n
Kanten. [EWHK 2
+ 96]
Ein Knoten v ∈ V und eine Kante e ∈ E in einem Graphen G = (V, E) inzidieren
oder überdecken einander, falls v ∈ e. Zwei Knoten u, v ∈ V heißen adjazent, verbunden
oder benachbart, falls {ucv} ∈ E. Die Nachbarschaft eines Knotens v ∈ V ist die Menge
Γ(v) := {u ∈ V |{ucv} ∈ E} der Nachbarn von v. Der Grad d(v) := |Γ(v)| enes Knotens
v ∈ V zählt die Kanten, die in dem Graphen mit v inzidieren. Mit dG(v) wird betont,
das sich der Grad auf einen Graphen G bezieht. [EWHK + 96]

28 2.5. Grundlagen in der Graphentheorie

Kapitel 3. Anfragetechnologien über Graphenstrukturen 29
Kapitel 3
Anfragetechnologien über
Graphenstrukturen
Im Kontext der integrierten Daten ist nun eine effiziente Möglichkeit für die Suche über
den bereits vorliegenden Graphen wünschenswert. Um dynamisch Anfragen generieren
zu können, muss es möglich sein, diese in Form von Suchanfragen auf den Graphen zu
stellen. Die Techniken werden dabei nach den folgenden Kriterien untersucht:
Bewertungskriterien
Technische Realisierbarkeit
Erläuterung
widmet sich der Frage nach der Technischen Umsetzbarkeit
auf Basis der momentan angebotenen Technologien
zur Anfrageverarbeitung in den bestimmten Konzepten
Integrationsgrad umfasst den Aspekt, wie gut das Konzept als selbständig,
integrierte Lösung im Rahmen des Tools genutzt
werden kann
Kompatibilität bewertet die Möglichkeiten an Schnittstellen zur Pro-
zu Java grammiersprache Java
Effizienz die Leistungsfähigkeit der Anfragetechnologie besonders
unter dem Aspekt des hohen Datenvolumens und
der Zuwachs der Daten durch Zusatzinformationen, die
Anwendbarkeit
auf Problematik
durch das Konzept benötigt werden
inwiefern die Anfragetechnologie zur Zielstellung passt
und damit auch die gewünschte Funktionalität umsetzen
läßt
Tabelle 3.1: Liste der zu betrachtenden Berwertungskriterien

30 3.1. Aktueller Ansatz
3.1 Aktueller Ansatz
Der momentan vorliegende Lösungsansatz besteht aus folgenden Teilen:
• Proteomics-DB Schema
• aus der Proteomics-DB ausgelesenen Graphen
• statische SQL-Anfragen auf der Menge dieser zuvor erwähnten Graphen
Der schematischen Ablauf einer solchen Anfrage wird in der Abbildung 3.1 in Form
eines Aktivitätsdiagramms dargestellt. Ein Mitglied der biologischen Abteilung hat eine
bestimmt Frage bezüglich einer Menge von EST-Sequenzen. Er übermittelt mit dieser
Anfrage implizit 2 Informationen. Einerseits natürlich die EST-Sequenzen und zum
anderen die Zielinformation, die letztendlich analysiert werden soll. Die anschließende
Vorgehensweise besteht prinzipiell aus zwei Gedanken. Zunächst werden aus den Eingabedaten
die zugehörige Accession-Nummer und Tabellen-Namen aus der Proteomics
Datenbank bestimmt. Sind die Werte bekannt, werden zwei SQL-Anfragen gestartet. Wobei
die Reihenfolgen dieser Anfragen unerheblich ist. Zu Beginn kann beipielsweise die
SQL-Anfrage gestellt werden, die alle Pfade identifiziert, die den Tabellen-Namen und
die Accession-ID der aus den EST-Sequenzen hervorgehenden Eingabewerte. Daraufhin
muss dann die zweite SQL-Anfrage ausführen, die alle Pfade identifiziert, deren Knoten
mit Elementen aus der Menge der Zieldatentabelle und deren Werte übereinstimmt.
Nun liegen zwei Mengen von Pfad-Identifikatoren vor. Jetzt werden diese zwei Mengen
auf übereinstimmenden Pfad-Identifikatoren geprüft. Mit anderen Worten, es wird die
Schnittmenge der beiden Mengen gebildet. Ergibt diese Prüfung eine nichtleere Menge
von Identifikatoren, so gibt es Kantenzüge zwischen den Eingabewerten und den Zieldaten.
Damit kann nun die Frage beantwortet werden, die der Ausgangspunkt gestellt
wurde.
3.2 Konstruktion eines Referenzbeispiels
Um die im Folgenden aufgeführten Technologien vergleichen zu können, soll an dieser
Stelle ein einfaches Beispiel konstruiert werden, welches vom Grundsatz her einem tatsächlichen
Anwendungsfall entsprechen könnte. Dabei soll folgende Zielstellung verfolgt
werden:
An welchen Stoffwechselwegen sind die angegebenen EST-Sequenzen beteiligt?
Die Menge der EST-Sequenzen besteht aus drei Sequenzen, die der Einfachheit halber
mit A,B bezeichnet werden. Weiterhin existiert eine binäre Relation (B) der Form:
xBy ⇐⇒ eine EST − Sequenz x ∈ X mit

Kapitel 3. Anfragetechnologien über Graphenstrukturen 31
&
, &&
% && ! ) &
*&
' $
% &&
% &&
!
! " #
% && & ( &
$$ % &&
'
Abbildung 3.1: aktueller Ablauf einer Anfrage
'
$ + $
) *

32 3.2. Konstruktion eines Referenzbeispiels
einem Knoten y ∈ Y des Graphen in Zusammenhang steht
MB = {(A, a.4.1), (A, r.15.2), (B, a.4.3)}
wobei X die Menge der EST-Sequenzen ist und Y die Menge der Knoten des Graphen.
Jeder Knoten hat eine Beschreibung, bestehend aus einem Relationennamen und einem
Attributnamen, und einen Wert. Ausserdem sei eine Menge G von Graphen, bestehend
aus zwei Graphen G1, G2 (siehe Abb. 3.2 und 3.3), gegeben. Neben diesen Informations
ist ebenfalls das Ziel des Interesses bekannt. In diesem Beispiel werden alle Knoten mit
der Beschreibung h.6 unabhängig vom Wert gesucht. Zusätzlich sind nur die Pfade von
Bedeutung, die keine Knoten mit der Beschreibung o.13 enthalten bzw. bei denen keiner
solcher Knoten durchlaufen werden.
Abbildung 3.2: Graph G1
Abbildung 3.3: Graph G2

Kapitel 3. Anfragetechnologien über Graphenstrukturen 33
3.3 Anfragesprachen auf relationalen Datenbanken
Auf dem Gebiet der relationalen Datenbanken hat sich die Anfragesprache Structured
Query Language (kurz: SQL) durchgesetzt und ist als Standard anzusehen. SQL basiert
dabei auf der Relationenalgebra und dem Relationenkalkül namens Tupelkalkül, welche
im Folgenden erläutert werden.
Relationenalgebra
Das Konzept der Algebra besteht darin, daß eine Menge von Werten vorliegt auf deren
Basis Operationen definiert werden, die entsprechende Werte der Wertemenge als
Eingabe erhält. Die Relationenalgebra ist nun eine Algebra basierend auf dem Relationenmodell.
Somit entspricht die Wertemenge der Relationenalgebra einer Menge von
Relationen. Desweiteren wird bei der Relationenalgebra von einer einsortigen Algebra
gesprochen. Dies bedeutet, daß alle Operationen der Relationenalgebra nur Relationen
als Eingabevariablen erhalten und ausschließlich Relationen zurückliefern.
Die Menge der Operationen einer Relationenalgebra nach [HS00] besteht aus den
Elementen Selektion, Projektion, Verbund, Vereinigung, Differenz und Umbenennung.
Selektion:
Die Syntax der Selektion
Die Semantik wirk erklärt durch
σ[bedingung](relation)
σF (r) := {t | t ∈ r ∧ F (t) = true}
wobei die Formel F eine bedingung darstellt und folgende Form annehmen kann:
1. F ist eine Konstanten-Selektion der Form
Attribut Θ Konstante
mit Θ ∈ {=, =, ≤, , ≥}. Es wird für jedes Tupel der Wert eines Attributs mit
einer angegebenen Konstante verglichen.
2. F kann eine Attribut-Selektion der Form
Attribut1 Θ Attribute2
wobei für jedes Tupel zwei Attributwerte verglichen werden.
3. F kann eine logische Verknüpfung mehrere Konstanten- oder Attribut-Selektionen
mit ∨, ∧ oder = sein.

34 3.3. Anfragesprachen auf relationalen Datenbanken
Projektion:
Die Syntax der Projektion ist
Die Semantik wirk erklärt durch
π[attributmenge](relation)
πX(r) := {t(X) | t ∈ r}
für eine Relation r(R) und X ⊆ R Attributmenge in R. Wichtig ist dabei das das
Ergebnis immer eine Tupelmenge wird in der doppelte Einträge eliminiert werden, da in
der Definition einer Relation Multimengen ausgeschlossen werden.
Verbund:
Die Syntax des (natürlichen) Verbunds ist:
Die Semantik wirk erklärt durch
Relation1 ✶ Relation2
r1 ✶ r2 := {t | t(R1 ∪ R2) ∧ [∀i ∈ {1, 2} ∃ti ∈ ri : ti = t(Ri)]}
Die Formel bedeutet, daß genau diejenigen Tupel t ins Ergebnis aufgenommmen werden,
für die es passende Gegenstücke t1 und t2 in r1 ud r2 gibt. Der Verbund verknüpft somit
Tabellen über gleichbenannten Spalten bei gleichen Attributwerten. Gibt es Tupel die
keinen Partner in der gemeinsamen Spalte haben, so werden diese eliminert und tauchen
in der resultierenden Relation nicht auf. Ein Sonderfall ist, wenn es keine gemeinsamen
Attributnamen gibt, dann gilt:
R1 ∩ R2 = ∅ =⇒ r1 ✶ r2 = r1 × r2
Der Verbund entartet zum kartesischen Produkt.
Umbenennung:
Die Syntax der Umbenennung ist
β[neu ← alt](relation)
In der Ausgangsrelation relation wird der Attributename alt in neu geändert. Die Semantik
der Umbennenung ist folgendermaßen:
Vereinigung:
βB←A(r) := {t ′ | ∃t ∈ r : t ′ (R − A) = t(R − A) ∧ t ′ (B) = t(A)}

Kapitel 3. Anfragetechnologien über Graphenstrukturen 35
Die Syntax der Vereinigung ist
Die Semantik der Vereinigung lautet:
relation1 ∪ relation2
r1 ∪ r2 := {t | t ∈ r1 ∨ t ∈ r2}
wobei r1(R), r2(R), sprich beide Relationen über dem gleichen Schema gebildet werden.
Differenz:
Die Syntax der Differenz ist
relation1 − relation2
Die Semantik der Differenz definiert sich folgendermaßen:
r1 − r2 := {t | t ∈ r1 ∧ t /∈ r2}
Genau wie bei der Vereinigung, so muss auch hier gelten: r1(R), r2(R).
Relationenkalküle
Allgemein basieren die Kalküle auf einer formalen Sprache zur Formulierung von Aussagen.
Es lehnt sich an der expliziten Definition von Mengen in der Mathematik. Wird
diese Semantik auf Datenbankobjekte angewandt kommt es zu folgendem Ansatz.
{f(¯x) = p(¯x)}
wobei die Bestandteile folgendermaßen aussehen:
• ¯x ist eine Menge freier Variablen ¯x = {x1 : D1, . . . , xn : Dn}; Di ist der Wertebereich
an den xi gebunden ist.
• Die Funktion f bezeichnet eine Ergebnisfunktion über den freien Variablen.
• p ist ein Selektionsprädikat über den freien Variablen. Diese bestehen aus:
– Termen zu den Wertebereichen (Konstanten, Variablen und Funktionsanwendungen)
– atomare Formeln gebildet aus den Prädikaten der Datentypen
– Datenbankprädikate, die den Bezug zu Datenbank herstellen, zum Beispiel
der Relationenname im Relationenmodell als Prädikatensymbol
– Formeln, die aus einer Zusammensetzung von atomaren Formeln durch prädikatenlogischen
Operatoren ∧, ∨, ¬, ∀, ∃ enstehen

36 3.3. Anfragesprachen auf relationalen Datenbanken
Im Bereich des Relationenmodells sind zwei Kalküle verbreitet das Bereichs- und das
Tupelkalkül.
• Bereichskalkül ist der Ansatz, indem den freien Variablen Werte elementarer Datentypen
zugewiesen werden. Es wird oft auch als Domänen-Kalkül bezeichnet.
• im Tupelkalkül wird davon ausgegangen, daß über Variablen als Tupelwerte aufgefasst
werden
Nähere Erläuterungen zum Tupelkalkül und Bereichskalkül werden im [HS00] gegeben.
Wie zu Beginn dieses Abschnitts gesagt, sind das Tupelkalkül und die Relationenalgebra
die Konzepte, die von der Anfragesprache SQL abgedeckt werden. Der Kern der
SQL-Anfragesprache ist der SFW-Block. SFW steht dabei für Select-F rom-W here.
Mit der Select-Klausel wird eine Projektionliste gegeben und es ist an dieser Stelle
möglich arithmetische Operationen und Aggregatfunktionen zu verwenden. Die From-
Klausel spezifiziert die Relationen, die dann mittels kartesischen Produkts verknüpft
werden. Ausserdem können hier Umbenennungen vorgenommen, oder anders formuliert
Tupelvariablen definiert werden, wie es im Tupelkalkül möglich ist. Die Where-Klausel
bietet die Möglichkeit Selektionsbedingungen zu formulieren oder Verbundbedingungen
zu definieren.
Es gibt zusätzlich zum diesen drei Klauseln auch noch die Group- und Having-Klausel,
die Gruppierungen innerhalb ein Relation ermöglichen bzw. Selektionbedingungen auf
diesen Gruppen. Eine genauere Beschreibung aller Klauseln wird im [HS00] gegeben.
Nachdem nun die Anfragesprache skizziert wurde, soll nun das relationale Konzept auf
Tauglichkeit zu dem vorliegenden Problem geprüft werden.
3.3.1 Anwendung des relationalen Konzepts
Dieser Abschnitt wird sich mit den Möglichkeiten, die das relationale Konzept ermöglicht,
auseinandersetzen und bewerten inwiefern das Konzept auf das Problem anwendbar ist
oder nicht anwendbar ist und welche Möglichkeiten die aktuellen Systeme bieten. Dabei
wird der im Abschnitt 3.2 eingeführte Anwendungsfall verwendet.
Da als Programmiersprache Java gewählt wurde ist zunächst die Frage, wie gut relationale
Datenbanken mit Java genutzt werden können. Die Schnittstelle JDBC stellt eine
einfache Variante dar, um mit relationalen Datenbanken zu kommunizieren. Was genau
an Funktionalität angeboten wird, hängt vom verwendeten JDBC-Treiber des jeweiligen
DBMS ab. Einheitlich ist jedoch, daß jeder Treiber eine gewissen Konformität mit
SQL-Standards aufweist. Ausserdem gibt es eine Reihe freier relationaler Datenbankmanagementsysteme
wie MySQL, PostgreSQL oder MaxDB. Weiterhin gibt es kommerzielle
DBMS wie Oracle oder DB2. Ein weiteres frei verfügbares DBMS ist HSQLDB. Es ist in
Java geschrieben und kann problemlos in das Tool integriert werden. Dazu muss lediglich
ein JAR-Archiv mitgeführt und in den Java-Classpath aufgenommen werden. Somit ist
auf einfache Weise gewährleistet, daß das Tool auf jeder Plattform funktioniert, ohne

Kapitel 3. Anfragetechnologien über Graphenstrukturen 37
ein externes DBMS installieren zu müssen. Durch die JDBC Schnittstelle besteht zusätzlich
die Möglichkeit andere DBMS mit dem Tool zu verwenden. Es muss dann der
entsprechende JDBC-Treiber geladen werden. Das relationale Konzept ist somit in puncto
technische Realisierbarkeit, Kompatibilität mit Java und im Integrationsgrad speziell
durch HSQLDB sehr gut geeignet. Nach der Betrachtung der rein technischen Aspekte ist
es nun von Interesse inwiefern das relationale Konzept für die Problemstellung ausreicht.
Speicherung und Anfrage
Im IPK werden die Graphdata bereits vorberechnet und in einer Relation r(RGraph) der
folgenden Form abgelegt.
RGraph = {pathid, depth, parent_tablename, parent_columnname,
child_tablename, child_columnname, parent_value, child_value}
pathid depth p_tname p_col c_tname c_col p_val c_val
0 0 a 4 1
0 1 a 4 b 4 1 1
0 2 b 4 c 4 1 2
0 2 b 4 d 4 1 3
0 2 b 4 e 2 1 4
0 3 c 4 f 5 2 2
0 3 c 4 g 4 2 2
0 3 c 4 h 6 2 2
0 3 d 4 i 7 3 3
0 3 e 2 j 5 4 4
0 3 e 2 k 2 4 4
Tabelle 3.2: Graph G1 im RGraph (die Spaltennamen wurden zwecks Platzersparnis verkürzt
geschrieben)
Wie sieht nun eine Anfrage aus, die ermitteln kann, ob ein bestimmter Pfad in diesem
Graphen existiert. Dazu wird zunächst eine Verbund über dieser Relation mit sich selbst
ausgeführt. In dem skizzierten Anwendungsfall wird nach Pfaden gesucht, die als Ziel
Knoten mit der Beschreibung h.6 haben und unabhängig vom Wert sind. Wird Enzyme
A zunächst betrachtet, ergibt sich die Menge von Startknoten {a.4.1, r.15.2}. Die Anfrage
die einem die Werte des Attributs pathid ausgibt, würde folgendermaßen aussehen:
SELECT DISTINCT pathid
FROM Graph source , Graph dest
WHERE source . pathid = dest . pathid and

38 3.3. Anfragesprachen auf relationalen Datenbanken
source . child_tablename l i k e "a" and source . child_columnname =
»4
and source . child_value = 1 and dest . child_tablename l i k e "h"
»and
dest . child_columnname = 6 ;
Listing 3.1: Start-Ziel Anfrage ohne konkrete Pfadinformationen
Diese Anfrage klärt somit die Frage, ob es einen Pfad vom Start zum Ziel gibt. Jedoch
wird der Pfad nicht genauer spezifiziert. Genau das ist aber notwendig, wenn die bisher
unangetastete Anforderung, das Pfade nur dann gültg sind, wenn keine Knoten mit der
Beschreibung o.13 passiert werden, hinzugenommen wird. Theoretisch möglich wäre es,
wenn man die Relation RGraph mehrmals eine Verbund mit sich selbst durchführt.
SELECT ’ / ’ | | source . child_tablename | | ’ . ’ | | source . child_columnname
» | | ’ . ’ | | source . child_value | | ’ / ’ | | zw1 . child_tablename | | ’ . ’ | | zw1 .
»child_columnname | | ’ . ’ | | zw1 . child_value | | ’ / ’ | | zw2 . child_tablename
» | | ’ . ’ | | zw2 . child_columnname | | ’ . ’ | | zw2 . child_value | | ’ / ’ | | dest .
»child_tablename | | ’ . ’ | | dest . child_columnname | | ’ . ’ | | dest .
»child_value as Path
FROM Graph source , Graph zw1 , Graph zw2 , Graph dest
WHERE source . pathid = dest . pathid and source . pathid = zw1 . pathid and
source . child_tablename = zw1 . parent_tablename and source .
»child_columnname = zw1 . parent_columnname and source .
»child_value = zw1 . parent_value and
zw1 . child_tablename = zw2 . parent_tablename and zw1 .
»child_columnname = zw2 . parent_columnname and zw1 .
»child_value = zw2 . parent_value and
zw2 . child_tablename = dest . parent_tablename and zw2 .
»child_columnname = dest . parent_columnname and zw2 .
»child_value = dest . parent_value and
source . child_tablename like ’ a ’ and source . child_columnname =
»4
and source . child_value = 1 and
not ( ( zw1 . child_tablename like ’ o ’ and
zw1 . child_columnname = 13) or
( zw2 . child_tablename like ’ o ’ and
zw2 . child_columnname = 13) ) and
dest . child_tablename l ike ’h ’ and
dest . child_columnname = 6 ;
Listing 3.2: Selbstverbund über der Relation RGraph
Die Ausgabe dieser Anfrage wird in Tabelle 3.3 dargestellt. Diese Variante würde zwar
zum Ziel führen, ist aber, wie unschwer zu erkennen, ineffektiv und sehr kompliziert. Für
Pfade der Länge x, wäre es notwendig genau x-mal einen Verbund über der Relation
RGraph durchzuführen. Dabei ist zu bedenken, daß es im vorraus keine Informationen

Kapitel 3. Anfragetechnologien über Graphenstrukturen 39
über die tatsächliche Länge eines Pfades gibt. Wie beispielsweise im Graph G2 3.3 zu
erkennen ist, gibt es Pfade unterschiedlicher Länge. Dies erschwert die Suche zusätzlich.
Im folgenden wird gezeigt, daß es im DBMS Oracle eine Möglichkeit gibt, hierarische
Anfrage zu formulieren. Dazu wird die CONNECT BY -Klausel verwendet. Jedoch ist
es dabei nicht möglich eine Einschränkung bezüglich der durchlaufenen Knoten zu formulieren.
Es ist nur möglich die Pfade generieren zu lassen, die vom Startknoten zum
Zielknoten führen. Eine Analyse der ”inneren” Knoten müsste andersweitig durchgeführt
werden.
s e l e c t
sys_connect_by_path ( child_tablename | | ’ . ’ | | child_columnname | | ’ . ’ | |
»child_value , ’ / ’ ) as path
from Graph
where child_tablename l i k e ’h ’ and child_columnname = 6
s t a r t with child_tablename l i k e ’ a ’ and child_columnname = 4
and child_value = 1
connect by p r i o r child_tablename = parent_tablename and
p r i o r child_columnname = parent_columnname and
p r i o r child_value = parent_value ;
Listing 3.3: Pfadausgabe mittel CONNECT BY-Klausel (nur Oracle)
PATH
/a.4.1/b.4.1/c.4.2/h.6.2
Tabelle 3.3: Ausgabe zu den Anfrage der Listings 3.2,3.3
Fazit zu den relationalen Konzept ist, daß es technisch gesehen ein sehr ausgereiftes
und stabiles Konzept ist, welches sich einer breiten Akzeptanz erfreut. Dadurch bedingt
auch viele Datenbankmanagementsysteme vorliegen, mit denen durch die Schnittstelle
JDBC auf einfache Weise kommuniziert werden kann. Eine Start-Ziel Suche, bei der die
Pfadinformationen nicht erfasst werden, kann im relationalen Konzept effizient durchgeführt
werden. Die Grenze dieses Konzept liegt beim Erschließen der vollständigen
Beschreibung des Pfads ausgehend von einem Startknoten bis zu einem spezifizierten
Zielknoten.
3.4 XML-basierte Lösungen
Diese Idee basiert auf der Möglichkeit von XML, Strukturen zu definieren. Damit werden
die Daten in einem XML-Dokument abgelegt. Auf diesem Dokuments können jetzt die im
Bereich von XML anzutreffenden Anfragesprachen angewendet werden. Die wichtigsten
sind XQuery 1.0, XPath 2.0 und XPath 1.0. Zwischen diesen drei Anfragetechnologien

40 3.4. XML-basierte Lösungen
besteht folgender Zusammenhang:
XP ath 1.0 ⊂ XP ath 2.0 ⊂ XQuery1.0
Sowohl XPath 2.0 und XPath 1.0 arbeiten auf ein nicht XML-konformen Syntax. Mit
diesen Sprachen wird das Ziel verfolgt, Bestandteile eines XML-Baum gezielt und standardisiert
zu adressieren. XQuery 1.0 wurde entwurfen um den Anforderungen gerecht
zu werden, die durch die W3C XML Query Workung Group [CFMR] und durch Anwendungsfälle
[CFM + ] definiert werden. Allgemein hat XQuery wiederum eine nicht XMLkonforme
Anfrage Syntax. XQuery ist ableitet von der XML Anfrage Sprache QUILT
[RFC00] und bietet dank ihrer Felxibilität die Möglichkeit an verschiedene XML Informationsquellen,
wie beispielsweise Datenbanken und Dokumente, Anfragen zu stellen.
Da XQuery eine sehr neue Technologie ist, gibt es bisher keine schlanke und ausgereifte
Möglichkeit, um sie in das zu entwickelnde System einzubinden. Das ist auch nicht
weiter problematisch, denn schon XPath 1.0 bietet die Funktionalität an, Pfadausdrücke
auf der Hierarchie eines XML-Dokuments zu formulieren. Zudem gibt es durch JXPath
[PM] eine einfache Möglichkeit XPath in Java einzubinden, doch dazu später. Zuerst
wird eine kurze Beschreibung des Aufbaus von XPath gegeben.
XPath
Wie bereits erwähnt, ist es mit XPath möglich, durch die Struktur von XML-Dokumenten
zu navigieren. Das allgemeinser grammatikalische Konstrukt wird Ausdruck genannt. Ein
solcher Ausdruck gibt nach seiner Auswertung ein Objekt zurück, welches von einem der
Basistypen ist:
• node-set (eine ungeordnete Menge von Knoten ohne Dubkikate)
• boolean
• number (Fließkommazahl)
• string
Die Auswertung eines Ausdrucks erfolgt immer in Bezug auf einen Kontext. Dieser
Kontext besteht dabei aus:
• einem Knoten (der Kontextknoten
• ein Paar Integer-Werten ungleich 0 (die Kontextposition und die Kontextgröße)
• eine Menge von gebundenen Variablen
• einer Funktionsbibliothek
• eine Menge von Namensraumdeklarationen im Rahmen des Ausdrucks

Kapitel 3. Anfragetechnologien über Graphenstrukturen 41
Gebunden Variablen bedeutet, daß die Variablennamen auf Werte abgebildet werden.
Die Werte können vom Typ einem der Basistyper für die Rückgabewerte eines
Ausdrucks entsprechen. Die Namensraumdeklarationen sind Abbildungen von Präfixen
auf Namensraum URI. Die gebundenen Variablen, die Funktionsbibliotheken und Namensraumdeklarationen
werden für alle Sub-Ausdrücke und dem Ausdruck, in dem sie
definiert werden verwendet und verändern sich nicht. Der Kontextknoten, die Kontextposition
und die Kontextgröße können durch Prädikate verändert werden. Wird nichts
über die drei Bestandteile ausgesagt, bleiben sie für Sub-Ausdrücke unverändert.
An dieser Stelle soll nicht die komplette Vielfalt von mögliche Ausdrücken erklärt
werden, wer daran interessiert ist, findet diese unter [CD99]. Lediglich ein besonderer
Typ soll im folgenden genauer beschrieben werden. Dieser Ausdrückstyp wird Lokalisierungspfad
genannt. Es existieren zwei Arten von Lokalisierungspfaden zum einmal die
absoluten und zum anderen die relativen Lokalisierungspfade. Im wesentlichen bestehen
diese Ausdrücke auf einer Folge von Lokalisierungsschritten, die durch das Zeichen ”/”
abgetrennt werden. Jeder Lokalisierungsschritt selektiert eine Menge von Knoten aus
dem XML-Baum ausgehend von seinem Kontextknoten. Jeder Knoten dieser Menge ist
wiederum Kontextknoten für den nächsten Lokalisierungsschritt.
Ein absolut Lokalisierungspfad besteht aus dem ”/” gefolgt von einem optionalen
relativen Lokalisierungspfad. Der absolute Lokalisierungspfad ”/” selektiert den Wurzelknoten
des XML-Dokuments.
[ 4 ] Step ::= A x i s S p e c i f i e r NodeTest P r e d i c a t e ∗
| AbbreviatedStep
Listing 3.4: Definition eines Lokalisierungsschritts nach [CD99]
Die Notation im Listing 3.4 entspricht einer erweiterten Backus-Naur Form, die im
Abschnitt 1.4.1 erläutert wird. Wie im Listing 3.4 beschrieben, besteht ein Lokalisierungsschritt
aus einer Achsenbeschreibung, gefolgt von einem Knotentest und keinem
oder beliebig vielen Prädikaten. Alternativ kann auch eine Kurzform eines Lokalisierungsschritts
verwendet werden.
[ 5 ] A x i s S p e c i f i e r ::= AxisName ’ : : ’
| A b b r e v i a t e d A x i s S p e c i f i e r
[ 6 ] AxisName ::= ’ ancestor ’
| ’ ancestor −or−s e l f ’
| ’ a t t r i b u t e ’
| ’ c h i l d ’
| ’ descendant ’
| ’ descendant−or−s e l f ’
| ’ f o l l o w i n g ’
| ’ f o l l o w i n g −s i b l i n g ’
| ’ namespace ’

42 3.4. XML-basierte Lösungen
| ’ parent ’
| ’ preceding ’
| ’ preceding −s i b l i n g ’
| ’ s e l f ’
[ 7 ] NodeTest ::= NameTest
| NodeType ’ ( ’ ’ ) ’
| ’ p r o c e s s i n g −i n s t r u c t i o n ’ ’ ( ’ L i t e r a l ’ ) ’
Listing 3.5: Ausschnitt der Definition der Achsenbeschreibung und des Knotentests nach
[CD99]
Die Kombination aus Achsenbeschreibung und Knoten-Test selektiert eine initiale
Menge von Knoten ausgehend vom Kontextknoten. Die Achsenbeschreibung besteht aus
einem Achsennamen (siehe 3.5) gefolgt von zwei Doppelpunkten ”::”. Beispielsweise bedeutet
child :: adresse, daß ausgehend vom aktuellen Kontextknoten alle Kinderknoten,
die dem address-Elementtyp entsprechen, gewählt werden. In diesem Fall wurde ein Namentest
als Knotentest gewählt. Es hätte nun auch noch ein Prädikat folgen können,
welches die selektierte Menge von Knoten zusätlich hätte filtern können. Im nächsten
Abschnitt wird der in Abschnitt 3.2 skizzierte Anwendungsfall herangezogen, um dieses
Konzept bewerten zu können.
3.4.1 Anwendung des XML-basierten Konzepts
Zunächst stellt sich die Frage, wie aus Java heraus auf XML Daten zugegriffen werden
kann. In diesem Zusammenhang fallen normalerweise die Technologien Document
Object Model (DOM) und Simple API for XML (SAX). Beides sind Implementationen
eines XML-Parsers. Eine etwas andere Technik ist unter dem Begriff Java Architecture
for XML Binding (JAXB) bekannt. Die Abbildung 3.4 zeigt einen Überblick über diese
Technologie. Das Konzept ist recht einfach. Der JAXB Binding Compiler erhält als
Input ein XML Schema und produziert ein Java Package, bestehend aus Klassen und
Schnittstellen, welche den im XML Schema definierten Bestandteilen entsprechen. Die
Klassen and Schnittstellen werden kompiliert und werden zusammen mit einer Menge
von allgemeinen JAXB packages als JAXB binding framework bereitgestellt. Das JAXB
binding framework ermöglicht es Vor allem durch JAXB ist eine sehr gute Kompatibilität
zu Java gewährleistet. JAXB ist Bestandteil des Java Web Services Developer Pack,
welches aktuell in der Version 1.6 angeboten wird. Daraus geht hervor, daß JAXB ausgereift
ist. Somit ist das integrieren von XML-Informationen in Java und somit auch in
das Tool technisch realisierbar.
Der Compilierungsprozesses wird einmal extern ausgeführt. Das daraus entstandene
JAXB binding framework wird dann in den Klassenpfad des Projekts aufgenommen
und die entsprechende Java Objekte können wie normale Objekt verwendet werden. Das
JAXB binding framework enthält alle Daten, die benötigt werden, um die erzeugten
Klassen und Schnittstellen zu nutzen. Es muss nicht weiter installiert werden. Somit läßt

Kapitel 3. Anfragetechnologien über Graphenstrukturen 43
sich diese Technologie sehr gut in das Werkzeug integrieren.
Abbildung 3.4: JAXB Überblick [OM03]
Um mit den im JAXB binding framework arbeiten zu können, wird ein Package mit
Namen JXPath verwendet. Es ermöglicht XPath Ausdrücke unter anderem auf Java-
Beans auszuführen. Somit ist auch die Anbindung von XPath gegeben. Die Effiziens
bezüglich XPath ist fraglich, denn in der Spezifikation von XPath 1.0 [CD99] ist keine
Anfrage-Optimierung vorgesehen. Es liegt beim Anwendungsprogrammierer die optimale
Variante zu finden.
Ein weiteres Problem ist das Datenvolumen. Durch das Begrenzen der Rohdaten mit
Tags, steigt das Datenvolumen. Dies ist sehr schön im Listing 3.7 zu beobachten. Bei
der riesigen Menge an Rohdaten, die im Umfeld des zu entwickelnden Werkzeugs gegeben
ist, ist das ein schwerwiegender Nachteil. Es ist bei den Endanwendern, deren
Arbeitsplatzrechner die Zielplattform darstellen, nicht davon auszugehen, daß eine unbeschränkt
hohe Speicherkapazität vorliegt. Deswegen muss es das Bestreben sein, die
Datenmenge so gering wie möglich zu halten. Aus diesem Grund ist XML zum Speichern
der kompletten Graphinformationen eher ungeeignet.
Betrachten wir zunächst wie die Daten unseres Anwendungsfalls aus Abschnitt 3.2
in einer XML Struktur abgelegt weden können. Dazu wird zunächst eine XML Schema
(Listing 3.6) definiert, welches die Graphenstruktur abbildet.

44 3.4. XML-basierte Lösungen

Kapitel 3. Anfragetechnologien über Graphenstrukturen 45
Listing 3.6: XML-Schema Datei zur Definition der XML-Struktur für Graphen
Das folgende Listing 3.7 ist eine Dokumenteninstanz des Dokumenttyps, der im XML
Schema des Listings 3.6 definiert wurde.
a.4
1
b.4
1
e .2
4
j .5
4
k.2
4
d.4
3

46 3.4. XML-basierte Lösungen
. . .
i .7
3
c .4
2
f .5
2
g.4
2
h.6
2
Listing 3.7: Ausschnitt der XML-Dokumenteninstanz des Dokumententyps aus Listing
3.6 über der Graphenmengen G
Jetzt ist die XML-Strukur definiert, in der die Graphen vorliegen. Wie sehen nun
Pfadanfragen unter Anwendung der XPath Technologie aus? Im Listing 3.8 werden zwei
Anfragen formuliert. Auch hier werden wiederum die Pfade vom Start zum Zielknoten
zurückgeliefert. Die geordnete Menge der Vorgängerknoten bilden den Pfad, der bis zum
Endknoten durchlaufen wurde. Dies zeigt das es recht einfach ist, die Pfadinformationen
zu erlangen.
// node [ c h i l d : : nodeDesc = ’ a . 4 ’ and c h i l d : : nodeValue = ’ 1 ’ ] /
»descendant : : node [ c h i l d : : nodeDesc = ’ h . 6 ’ ] / ancestor −or−s e l f : : node
// node [ c h i l d : : nodeDsc = ’ r . 1 5 ’ and c h i l d : : nodeValue = ’ 2 ’ ] /
»descendant : : node [ c h i l d : : nodeDesc = ’ h . 6 ’ ] / ancestor −or−s e l f : : node
Listing 3.8: Pfadanfragen über Graphen als XPath Ausdrücke

Kapitel 3. Anfragetechnologien über Graphenstrukturen 47
Jedoch wurden die Pfade bisher nicht weiter eingeschränkt. Eine Möglichkeit ist die
Analyse von Einschränkungen von XPath zu entkoppeln. Dazu wird einfach die Vorgängermenge
zurückgegeben. Wichtig zu wissen ist, daß durch den ancestor-or-self Achennamen
eine geordnete Knotenmengen in umgekehrter Dokumentenordnung geliefert wird.
Das heißt, daß sich der Startknoten am Ende der geordneten Mengen befindet. Eine
andere Variante wäre im XPath-Ausdruck direkt eine Funktion zu nutzen, die den Pfad
auf die Beschränkungen hin untersucht.
Das Listing 3.9 zeigt, wie eine Funktion als Ausdruck verwendet werden kann. Die
Funktion checkPath hat zwei Argumente. Einmal die geordnete Menge von Vorgängerknoten
des Kontextknotens und drei Variablen sourceDesc, sourceValue, pattern.
sourceDesc die Beschreibung des Startknotens
sourceValue der Wert des Startknotens
pattern ein regulärer Ausdruck der ein Pattern für gültige Pfade beschreibt
Der Rückgabewert dieser Methode muss ein Wahrheitswert sein. Die Funktion muss für
jeden Knoten, der über einen gültigen Pfad erreicht wurde, den Wahrheitswert wahr
zurückgeben. Dann wird dieser Knoten node in die resultierende Knotenmenge aufgenommen.
// node [ c h i l d : : nodeDesc = ’ a . 4 ’ and c h i l d : : nodeValue = ’ 1 ’ ] /
»descendant : : node [ c h i l d : : nodeDesc = ’ h . 6 ’ ] [ checkPath ( a n c e s t o r : :
»node , $sourceDesc , $sourceValue , $pattern ) ]
Listing 3.9: XPath Ausdrücke mit Pfadauswertung
Zusammenfassend läßt sich sagen, daß durch XPath die Anfrage von Pfaden realisieren
läßt. Das Problem der XML-Technologie ist, daß durch die Begrenzer (TAGS) ein
zusätzlicher Datenzuwachs entsteht, der nicht erwünscht ist. Somit ist das Konzept der
hierarischen Verarbeitung auf Basis von wohlgeformten XML-Dokumente als alleinige
Lösung nicht optimal.
3.5 Objektorientiertes Konzept
Als letzte Technologie wurden Objektdatendaten betrachtet. Diese Datenbanken basieren
auf der Idee das Objektparadigma auf Datenbanksysteme anzuwenden. Die Object Data
Management Group (ODMG) hatte zum Ziel einen Standard wie SQL für OODBMS
zu entwickeln. Zur Definition eines Datenschema entwickelte die ODMG eine datenbankunabhängige
Datendefinitionssprache, die Objekt Definition Language (ODL). Dabei
handelt es sich um eine Definitionssprache (DDL) für Objekte. Im Listing 3.10 ist ein
Ausschnitt aus der ODL Grammatik dargestellt. Im ODMG-Standard gibt es keine extra
Object Manipulation Language (OML). Diese Operationen müssen im Objekt selbst
definiert werden und können dann in OQL genutzt werden.

48 3.5. Objektorientiertes Konzept
( 1 ) ::=
|
(2∗) ::= ;
| ;
| ;
| ;
| ;
| ;
(2 a ) ::= { }
(2 b ) ::= c l a s s
[ extends ]
[ ]
[ ]
(2 c ) ::= ( [ ] [ ] )
Listing 3.10: Ausschnitt aus der ODL Grammatik [CBB + 97]
ODL dient zur programmiersprachenunabhängigen Definition der Objekte. Jede
Objektdefinition kann dann in mehreren Programmiersprachen implementiert werden.
Zu diesem Zweck gibt es verschiedene Anbindung zu den Programmiersprachen
C++,Smalltalk und Java. Dabei werden die Datentypen aufeinander abgebildet und
es werden neue Interface für die Kollektionstypen wie set,bag,list definiert. Un es wird
zustäzlich ein Properties File erstellt, in dem festgehalten wird welche Attribute eines
Objekts persistent sind oder welche eine Referenz zu anderen Objekt darstellen.
Wurde eine Menge von Objekten gebildet, ist nun die Frage, wie auf die persistent, abgelegten
Informationen zugegriffen werden kann. Die Anfragesprache, die von der ODMG
enwickelt wurde, nennt sich Object Query Language (OQL). Sie arbeitet auf dem Objektmodell
welches von der ODMG enwickelt wurde. Ihre Syntax lehnt sich stark an den
SQL-92 Standard. Dieser wird um objektorientierte Belange erweitert, wie komplexe
Objekte, Objektidentität, Pfadausdrücke, Polymorphismus, Operationsaufrufe und dynamisches
Binden. OQL kann von einer Programmiersprache aus aufgerufen werden und
kann ebenfalls Operationen bzw. Funktionen, die in der Programmiersprache definiert
wurden, ausführen. OQL selbst definiert keine Update Operationen. Dazu werden die
Operationen genutzt, die auf Seiten der Programmiersprache definiert werden. Ausserdem
bietet OQL einen deskriptiven Zugriff auf Objekte und ermöglicht auf dieser Basis
eine Optimierung der Anfragen. [CBB + 97]
Interessant ist der Begriff Pfadausdruck. Er beschreibt wörtlich das, was im vorliegenden
Anwendugsfall gesucht wird. Jedoch wird hier mit Pfadausdruck die Möglichkeit
beschrieben, mittels einer Punktnotation in die Sturktur von komplexen Objekten oder
über einfache Beziehungen zu navigieren, beispielsweise p.spouse.address. city .name. Das
liefert uns den Namen der Stadt, in der der Ehepartner der Person p lebt. [CBB + 97]
Es soll an dieser Stelle nicht die komplette Sprache-Definition erläutert werden. Dazu
wird auf die letzte Version v3.0 [CBB + 00] verwiesen. Es wird folgend das wichtigste
Konstrukt der OQL auschnittweise präsentiert. Dieses Konstrukt ist der SFW-Block der

Kapitel 3. Anfragetechnologien über Graphenstrukturen 49
auch schon in SQL verwendet wurde. Hier wird die Anlehnung an SQL-92 deutlich.
query ::= s e l e c t E x p r
| expr
s e l e c t E x p r ::= s e l e c t [ d i s t i n c t ] p r o j e c t i o n A t t r i b u t e s
fromclause
[ whereClause ]
[ groupClause ]
[ orderClause ]
p r o j e c t i o n A t t r i b u t e s ::= p r o j e c t i o n L i s t
| ∗
p r o j e c t i o n L i s t ::= p r o j e c t i o n { , p r o j e c t i o n }
p r o j e c t i o n ::= f i e l d
| expr [ as i d e n t i f i e r ]
fromClause ::= from i t e r a t o r D e f { , i t e r a t o r D e f }
i t e r a t o r D e f ::= expr [ [ as ] i d e n t i f i e r ]
| i d e n t i f i e r in expr
whereClause ::= where expr
havingClause ::= having expr
orderClause ::= order by s o r t C r i t e r i a
s o r t C r i t e r i a ::= s o r t C r i t e r i o n { , s o r t C r i t e r i o n }
s o r t C r i t e r i o n ::= expr [ ( asc | desc ) ]
Listing 3.11: Ausschnitt der OQL Grammatik aus [CBB + 00]
Generell ist es möglich durch das Java Binding den ODMG Standard zu verwenden.
Ein Problem welches momentan ist, daß die frei verfügbaren embedded Lösungen von
ODBMS den ODMG Standard eher spärlich unterstützen. Sie verwenden meist eigene
Konzepte, die nicht die Möglichkeiten haben, wie es der ODMG Standard hat.
3.5.1 Anwendung des Konzepts von ODBMS
Die erste Frage die sich stellt ist, wie sollen die Graphinformationen gespeichert werden.
Es gibt in der Informatik im wesentlichen drei Ansätze um Graphen zu speichern,
die Inzidenzmatrix, die Adjazenzmatrix und die Adjazenzliste. Die Adjazensliste ist am
ehesten geeignet, da bei der Adjazenzmatrix aufgrund dessen das es sich um ungerichtete
Graphen handelt unnötig Platz verschwendet wird. Die Inzidenzmatrix verwendet
neben Knoten auch Kanten. Jedoch Kanteninformationen abzulegen würde wieder eine
erhöhung des Datenvolumens bedeuten.
Somit muss ein Graphobjekt gebildet werden, welches die Struktur einer Adjazenzliste
beschreibt. Die Bestandteile einer Adjazenzliste sind Listen oder Arrays über Knoten.
Also muss es noch ein Objekt Knoten geben. Dabei besteht jeder Knoten aus einer Beschreibung
und einem Wert. Aus der Kombination der Bestandteile ergibt sich die Ein-

50 3.5. Objektorientiertes Konzept
deutigkeit eines Knotens. Die Knotenbeschreibung selbst kann auch als eigenes Objekt
existieren. Sie setzt sich aus einem Tabellennamen und einem Attributnamen zusammen.
class Graph
( extent Graphs )
{
attribute dictionary a d j a z e n s l i s t e ;
relationship set nodes
inverse Node : : is_included_by ;
boolean checkPathFor ( in Node sourc , in Node dest , in string
»pattern )
} ;
class Node
( extent Nodes )
{
attribute string value ;
}
relationship D e s c r i p t i o n d e s c r i p t i o n
inverse D e s c r i p t i o n : : d e s c r i b e s ;
relationship set included_by
inverse Graph : : nodes ;
class D e s c r i p t i o n
( extent D e s c r i p t i o n s )
{
attribute string tablename ;
attribute string columnname ;
}
relationship set d e s c r i b e s
inverse Node : : has_description ;
Listing 3.12: Darstellung der Graphen durch ODL
OQL ist vom Wesen her ähnlich wie SQL. Jedoch kann es aufgrund der Objekttypen
wesentlich komplexere typen behandeln. Ausserdem wird durch die Möglichkeit
Operationen aufzurufen, die Möglichkeit komplexere Operationen quasi nachzuladen. So
könnte das Problem des prüfens, ob ein Pfad vom Start zum Zielknoten existiert und
dieser einem Bestimmten Pattern entspricht, in einer Operation vereint werden. Diese
Funktion wurde im Listing 3.12 mit checkPathFor(. . . ) bezeichnet. Diese Funktion müsste
dann, mittels der im Graphen aufgeführten Adjazenzliste, die Pfade bestimmen und

Kapitel 3. Anfragetechnologien über Graphenstrukturen 51
gegen das Pattern prüfen.
Das folgende Listing zeigt eine mögliche OQL-Anfrage, um eine Menge von Knoten
zu bestimmen, die über Pfade, entsprechend dem Pattern pattern ausgehende vom Startknoten
source und zum entsprechenden Ziel führen, erreicht werden. In diesem Fall wurde
genau ein Knoten als Ziel festgelegt. Somit ist das Ergebnis eine leere oder einelementige
Menge. Genausogut könnten Knoten das Ziel sein, die einer bestimmten Beschreibung
entsprechen. Dann könnte die resultierende Menge eine beliebige Anzahl zutreffender
Knoten enthalten. Ist das Resultat eine leere Menge, so gibt es keine solche Zielknoten.
define provePath ( source , dest , pattern ) as
select distinct n
from Graphs g , g . nodes n
where g . checkPathFor ( source , n , pattern ) and n = dest ;
Listing 3.13: OQL Anfrage
3.6 Gesamtbewertung und resultierendes Konzept
Zum Abschluss dieses Kapitels, wird noch einmal ein zusammenfassender Überblick über
die analysierten Konzepte und deren Bewertung gegeben. Die Tabelle 3.4 zeigt im Überblick
die einzelnen Bewertungskriterien zusammen mit den untersuchten Konzepten.
Bewertungskriterium relationale hierarische Dokumenten- objektorientierte
DBMS struktur (XML) DBMS
Technische Realisierbarkeit
↑ ↑ ←
Integrationsgrad ↑ ↑ ←
Kompatibilität zur Java ↑ ↑ ↖
Effiziens ↑ ↙ ↖
Anwendbarkeit auf die
Problematik
← ↖ ↑
Tabelle 3.4: Bewertung der Anfragetechnologien
Zusammenfassend läßt sich sagen, daß momentan noch kein Konzept allein das Problem
lösen kann. Potential hat sicherlich die objektorientierte Variante, ist jedoch momentan
vor allem im embedded Bereich der frei verfügbaren Datenbanken bezüglich
des ODMG-Standards eingeschränkt. Relationale DBMS unterliegen Beschränkungen
aufgrund ihres einfachen Konzepts. Dies äußerst sich vor allem in der Extraktion der
Pfadinformationen. Allein Oracle bietet eine Möglichkeit dieses Problem zu lösen. Vorteil
der relationalen DBMS ist ihr theoretisch gut durchdrungenes Konzept, speziell die
Relationenalgebra. Auf deren Basis eine effiziente Optimierung der Anfragen möglich ist,
was natürlich auch auf das einfache Konzept der Relationen zurückzuführen ist.

52 3.6. Gesamtbewertung und resultierendes Konzept
Die dokumentenbasierte Variante auf Basis der Sprache XML, ist in Bezug auf der
Extraktion von Pfadinformationen sehr gut geeignet. Die Anfragesprache XPath bietet,
mit dem Konzept der Lokalisierungsschritte, eine einfach und effiziente Möglichkeit Pfade
zu bestimmen und zu untersuchen. Der schwerwiegende Nachteil entsteht durch die
Forderung des Wohlgeformtheitskriteriums, welches besagt, daß die Informationen mit
Start- und Endmarkierungen versehen werden müssen. Dies führt zu einem hohen Maß
an Datenzuwachs. Deswegen schneidet dieses Konzept bei der Effiziens schlechter ab.
Das resultierende Konzept wird die Vorteile des relationalen Konzepts und das Konzept
der hierarischen Dokumentenstrukturen vereinen. Zum einen wird durch RDBMS
eine Vorfilterung durchgeführt, bei der aus der großen Menge an Graphen nur die selektiert
werden, die für die aktuelle Anfrage wichtig sind. Diese gefilterte Menge wird dann
in eine XML-Struktur überführt, auf derer daraufhin die Pfadanalyse bewerktstelligt
wird.
Im nächsten Kapitel wird die Entwicklung des Tools entsprechend des Software-
Lebenszykluses beschrieben. Bei der Entwicklung wird nun das hier als resultierend
beschriebene Konzept umgesetzt.

Kapitel 4. Entwurf des Offlinewerkzeugs 53
Kapitel 4
Entwurf des Offlinewerkzeugs
In diesem Kapitel stellt den praktischen Teil der Arbeit dar. Am Ende soll eine Software
entstehen, die das Konzept, welches im Kapitel 3 ermittelt wurde, implementiert. Der
Entstehungsprozess einer Software wird durch den Softwarelebenszyklus beschrieben. Dabei
werden die einzelnen Lebenzyklusphasen in der Entwicklung durchlaufen. Begonnen
wird bei der Problemdefinition und Anforderungsanalyse. Gefolgt von der Spezifikation,
der Entwurfs- und Implementationsphase. Zum Ende folgt dann die Erprobung und
Auslieferung.
4.1 Problemdefinition und Anforderungsanalyse
Die Problemdefintion ist die Phase in der die Anforderungen, die an das Softwareprodukt
gestellt werden, herausgearbeitet werden müssen. [Dum00] Die Aufgabenstellung
definiert einen Großteil der Anforderungen. Alle weiteren müssen durch Gespräche mit
den jeweiligen Mitarbeitern herausgearbeitet werden. Die extrahierten Anforderungen
werden beginnend bei den funktionalen Anforderungen im Folgenden aufgelistet:
• funktionale Anforderungen
– offline Werkzeug, welches eine Beziehung zwischen den Eingangsdaten und
den Zieldaten auf der Basis von tabellarischen Exporten der DLGs herstellt
– die Eingabedaten sollen entweder Sequenzdaten oder Ausgaben von darauf
angewandten Analysenwerkzeugen sein
– Zieldaten sind individuell vom Nutzer gewählte Sekundärdaten, wie Stoffwechselwege
oder Enzyme
– das Werkzeug greift auf lokal gespeicherte, tabellarischen Exporte dieser
DLG’s sowie auf exportierte Abschnitte aus der integrierten Proteomicsdatenbank
(Zieldaten)

54 4.1. Problemdefinition und Anforderungsanalyse
– die Anbindung der Analysewerkzeuge bzw. der Ausgaben, die in Abhängigkeit
der Art der Zieldaten unterschiedlich ausfallen können, soll in einem Plugin-
Konzept realisiert werden
• qualitätsbezogene Anforderungen
– Datenbankunabhängigkeit bez. eines DBMS
– Erweiterbarkeit (bez. verschiedener Ausgaben von Analysewerkzeugen)
– möglichst schnelle Verarbeitung der Anfragen soll erreicht werden
– geeignete Nutzerobfläche
– Suchen des Verbindungsgraphen in den DLGs sollte mit logarithmischer Komplexität
erfolgen
– geeignete Daten- und Indexstrukturen sind beim Umgang mit den lokal gespeicherten
Export-Dateien zu verwenden
• systembezogene Anforderungen
– als Programmiersprache ist Java zu verwenden
– Verwendbarkeit auf verschiedenen Betriebssystemen
– Anwendung auf Desktop-PC’s
• prozesspezifische Anforderungen
– Entwicklungzeitraum wurde auf 5 Monate angesetzt
– für die Entwicklung ist ein Entwickler vorgesehen
Diese Anforderungen sind korrekt und konsistent forumliert. Ausserdem existieren
keine unverträglichen Anforderungen. Sie gingen aus Interviews mit Mitgliedern der
Arbeitsgruppe Bioinformatik der Abteilung Molekulare Marker. Die erste funktionale
Anforderung kann durch das im Kapitel 3 ermittelte Konzept realisiert werden. Die Datenbankunabhängigkeit
wird durch das Verwenden von JDBC gewährleistet. Die Plugin-
Struktur, die im weiteren noch näher erläutert wird, führt zur Erweiterbarkeit des Tools.
Mittels Java wird die Verwendbarkeit des Tool auf verschiedenen Plattformen gesichert.
Um eine geeignete Nutzeroberfläche zu erstellen, wird das Java Swing Packet verwendet.
Dies stellt sicher, daß das Erscheinungsbild auch auf allen Plattformen identisch
ist, was wiederum den Aspekt der Plattformunabhängigkeit berücksichtigt. Der Schwerpunkt
der Entwicklung liegt in Leistungsfähigkeit der Anfragen und der Flexibilität des
Tools bezüglich der Eingabe und Ausgabe.

Kapitel 4. Entwurf des Offlinewerkzeugs 55
4.2 Spezifikation
Nach der Analyse und Defintion der Anforderungen an die Software soll nun die eigentliche
Entwicklung des Softwareprodukts begonnen werden. In dieser Phase des Projekts
soll eine konzeptuelle Beschreibung des Software-Tools erreicht werden. [Dum00] Der
prinzipielle Aufbau des Tools soll einem Plugin-Konzept entsprechen. Die Abbildung 4.4
stellt die Struktur des Tools in Form eines Komponentendiagramms.
Die Nutzung des Tools umfasst im wesentlichen drei Anwendungsfälle. Zunächst muss
ein IT-Experte alle Daten, die für den Betrieb des Tools nötig sind, auf einem Server
zum Download bereitstellen. Ergeben sich Änderungen so müssen die Daten aktualisiert
werden. Der zweite nennenswerte Anwendungsfall ist, daß der Nutzer die auf den Server
angebotenen Daten auf sein lokales System herunterlädt. Diese Daten werden dann in das
Tool importiert. Diese beiden Anwendungsfälle sind nicht direkt Bestandteil des Funktionumfangs
des Tools, aber dennoch grundlegend für seine korrekte Arbeitsweise. Der
Letzte Anwendungsfall beschreibt nun die Aufgabe der Datenanalyse unter Verwendung
der zuvor geladenen Informationen. Die Verwendung des Tools verläuft dabei prinzipiell,
wie es in Abbildung 4.5 dargestellt wird. Das Anwendungsfalldiagramm in Abbildung
4.1 stellt die gerade beschriebenen Anwendungsfälle graphisch dar.
( *
$%
" (
Abbildung 4.1: Drei grundlegenden Anwendungsfälle im Umfeld des Tools
Die Datenbereitstellung teilt sich in verschiedene Teilaufgaben auf. In Abbildung
4.2 werde diese Aufgaben in einem Aktivitätsdiagramm dargestellt. Das Bereitstellen
von Zusatzinformationen bedeutet, daß zu den spezifischen Anfragen Informationen verwendet
werden, die zusätzlich zu den Graphinformationen genutzt werden. Die Pfade

56 4.2. Spezifikation
beinhalten ausschließlich Schlüsselattributwerte, die normalerweise nicht aussagekräfig
sind. Aus diesem Grund werden die Zusatzinformationen entsprechend dem Einzelfall
heruntergeladen, um somit eine geeignete Ausgabe am Ende einer Anfrage generieren zu
können.
Abbildung 4.2: Teilaufgabe der Datenbereitstellung
Neben den Zusatzinformationen müssen die Plugins entwickelt und bereitgestellt werden.
Diese Aufgabe kann von einer beliebigen Person bearbeitet werden, die sich in die
Pluginstruktur eingearbeitet hat. Es muss nicht die Person, die die Daten bereitstellt,
sein. Bei der Bereitstellung der Pfaddaten erfolgt zuvor ein Komprimierungsprozess, der
die Daten die in der Datenbank abgelegt wurden, speicherrelevant optimiert. Weitere
Informationen zu diesem Thema werden weiter unten gegeben.
Bevor der Nutzer das Tool zum ersten mal nutzen kann, muss er alle notwendigen
Daten vom Server herunterladen. Die Datenbeschaffung besteht zunächst aus dem
Herunterladen aller Informationen. Dazu gehören die Dateien, die aus dem Komprimierungsprozess
(siehe 4.9) hervorgehen, die Datei mit den RelationAttribut-Wertepaaren
(inklusive deren Index), die Plugins und die für die spezifische Frage nötigen Zusatzinformationen.
Wurden alle diese Daten heruntergeladen, muss die Einbettung der Pfaddaten,
der RelationAttribut-Wertepaaren und der Plugins erfolgen. Die Nutzung der Zusatzinformationen
erfolgt dann bei der Ausführung des Plugins. Das Aktivitätsdiagramm in
Abbildung 4.3 präsentiert den Datenbeschaffungsanwendungsfall noch einmal in graphischer
Form.

Kapitel 4. Entwurf des Offlinewerkzeugs 57
Abbildung 4.3: Aktivitätsdiagramm zur Beschreibung der Datenbeschaffung
4.2.1 Plugin-Struktur
Die Plugin-Struktur ist eine Komposition aus den Eingabe-Plugins, den Ausgabe-PlugIns
und den AnfrageAnalyse-Modul. Die Aufgabe der Eingabe-Plugins besteht darin sich
an die einzelnen Anwendungsfälle der Eingabemöglichkeiten zu widmen. Beispielweise
können externe Tools aus den eingegebenen Daten erst die Menge der Daten erzeugen,
die für den Anfrage benötigt werden. Dann ist bei der Ausgabe dieser Tools oder auch
generell davon auszugehen, daß die Eingangsdaten in flachen Dateien vorliegen. Diese
müssen zunächste mittels eines entsprechend angepaßten Parsers extrahiert werden. Das
wäre eine Aufgabe, welche von den Eingabeplugins realisert werden muss.
Ein weiterer Aspekt ist, daß die Semantik der verarbeiteten Infomationen zugänglich
gemacht werden muss. Diese Information ist für den Ausgabe Plugins wichtig, um die
Daten in entsprechender Form darzustellen. Demzufolge muss ein Eingabe-Plugin eine
Möglichkeit anbieten, diese Informationen abrufbar zu machen. In gleicher Weise muss
auch ein Ausgabe-Plugin Informationen darüber geben, welche Daten es darstellen kann.
Dann wäre es auch von Seiten der Eingabe-Plugins möglich, die Ausgabe-Plugins zu
ermitteln, die zu ihnen kompatibel sind.
Das Anfrage-Anlayse Modul ist der Teil des Tool, indem das ermittelte Konzept des
vorherigen Kapitels Anwendung findet. Dabei erhält es Eingangsdaten von den Eingabe-
Plugins und generiert daraus die Menge der Daten, die einerseits den gewünschten Zielinformationen
entsprechen und andererseits vom jeweiligen Startpunkt aus erreichbar

58 4.2. Spezifikation
Abbildung 4.4: Komponentendiagramm der Plugin-Struktur
sind.
Am Ende des Anfrageprozess, soll die Ausgabe der gefunden Zusammenhänge durch
Ausgabe-Plugins dargestellt werden. Das setzt vorraus, daß die Informationen zwischenzeitlich
gespeichert werden. Angefangen bei den Primärdaten, den Daten die am Anfang
der Informationskette stehen, bis hin zu den Zielinformationen. Im Abschnitt 4.2.2 wird
die Datenstruktur in Form eines ER-Modells beschrieben.
Die Benutzung des Tool wird wie in Abbildung 4.5 verstanden. Zu Beginn muss nachgesehen
werden ob ein Plugin registiert ist, welches dem Anwendungsfall entspricht. Ist
dies nicht der Fall, so muss zunächst ein solches im Tool registriert werden. Zum Anderen
müssen die Zusatzdaten zu den Ursprungsdaten und den Zieldaten heruntergeladen
werden. Sind alle Informationen bereits heruntergeladen wurden, dann wird einfach das
Plugin gestartet und alle seine Optionen eingestellt. Schließlich wird eine Eingabe getätigt,
überlicherweise das Drücken eines Buttons, die den Anfrageprozess startet.
4.2.2 Interne Datenstruktur
Wie weiter oben erwähnt, fallen Informationen zur Laufzeit des Tools an. Diese müssen
zur späteren Darstellung gespeichert werden. In der Abbildung 4.6 wird ein ER-Schema
definiert, welches die Struktur der zu speichernden Daten abbildet. Die Entities des RelationAttributes
Entity-Typs bilden eine Ausnahme. Sie werden unabhängig von den
eigentlichen temporären Daten zu Beginn einmalig eingespielt. Solange sich keine Ände-

Kapitel 4. Entwurf des Offlinewerkzeugs 59
! " # $
! #
Abbildung 4.5: Aktivitätsdiagramm zur Darstellung der Aktivitäten bei der Benutzung
des Tools

60 4.2. Spezifikation
rungen an der Struktur der Datenbank ergeben (z.B. Proteomics-DB 2.2), bleiben die
Daten unverändert. Sollte ein Änderung eintreten, so müssen diese Werte neu importiert
werden.
! ! !
!
!
!
!
"
Abbildung 4.6: ER-Schema der internen, temporären Daten
4.2.3 Generierung der Relation-Attribut Informationen
Wie im voherigen Abschnitt angedeutet, werden die Informationen der Relationen und
Attribute seperat aus der darunterliegenden Datenbank ausgelesen. Dabei wird sich eines
anderen Tool bediehnt, welches das ein relationales Datenbankschema verarbeitet und
als Ergebnis einen Datei erzeugt. Diese Datei ist eine XML konforme Datei vom Typ
.graphml. Das Tool erkennt alle Relationenschema und deren Attribute und erzeugt für
jedes Paar einen Knoten in der graphml Datei. Dabei werden der Relationenname und
der jeweilige Attributname mit einem Punkt verknüpft. Genau das sind die Werte, die
in der Relation RelationAttributes enthalten sind.
Diese Kombinationen werden zusätzlich noch an einer anderen Stelle gebraucht. Dies
betrifft das XML Schema, welches den XML Dokumenttyp für die Graphinformationen
festlegt. Die Daten werden zur Einschränkung der zulässigen Werte für die Knotenbeschreibungen
der einzelnen Knoten verwendet. Dazu jedoch in Entwurfabschnitt . . . mehr.
!

Kapitel 4. Entwurf des Offlinewerkzeugs 61
Diese zwei ”Formate” müssen aus der graphml Datei erzeugt werden. Da diese Datei
eine wohlgeformtes XML Dokument ist, kann sich der XSL Transformations Technologie
bedient werden. Diese Technologie erlaubt es, XML Dokumente in andere XML
Dokumente zu transformieren. Alternativ ist es auch möglich Ausgaben anderer Art zu
Erzeugen. In unserem Fall nutzen wir die Möglichkeit reine Textdateien generieren zu
können. Diese werden dann für den Import der Informationen in das Relationenschema
RelationAttribute genutzt. In Abbildung 4.7 wird das Zusammenspiel der einzelnen
Informationseinheiten dargestellt.
' ( #&
' ( #&
!
" # "$ % "&
Abbildung 4.7: Generierung der Einschränkungsteils für das XML Schema und die Textdatei
zum Import der RelationAttribut Werte
4.2.4 Komprimierung des Datenpools
Die Daten auf denen das zu entwickelnde Tool arbeiten wird, durchlaufen eine Sequenz
von Teilschritten bis sie letztenendes vom Tool verwendet werden. In Abbildung 4.8 wird
diese Sequenz dargestellt.
Wie bereits erwähnt, arbeitet das Offline-Tool auf einer bereits vorhandenen Menge
von Daten. Insgesamt enthält die Proteomics-DB alle Daten, die vom Tool verwendet
werden. Durch Anwendung eines anderen Tool , welches im IPK Gatersleben entwickelt
wurde, entstehen die Graphen. Dabei wird eine Tiefensuche auf der Proteomics-
Datenbank ausgeführt. Diese durchläuft alle Referenzen (Fremdschlüssel), die von jedem
Eintrag erreicht werden können. In diesem Zusammenhang kommt es jedoch zu einem
Problem. Die Fülle an Daten ist immens.
Momentan liegen die Informationen zu den Graphen in Form einer Relation in einer
Datenbank vor und können in einer CSV Exportdatei heruntergeladen werden. Diese Da-

62 4.2. Spezifikation
" #
Abbildung 4.8: Datenfluss der Pfaddaten vom DBS zum OfflineTool
tei würde vom Nutzer des Tools heruntergeladen werden müssen. Im Augenblick hat diese
Datei ein Volumen von ca. 8GB. Diese Größe ist im Normalfall sowohl nicht zeiteffizient
als auch nicht speicherfreundlich handhabbar. Aus diesem Grund muss eine Form der
Komprimierung angewendet werden, um diesen Datenbestand so zu reduzieren, sodaß
dessen Benutzbarkeit ein annehmbares Level erreicht.
Grundlegende Idee der Komprimierung
Nach einer Analyse des Daten war deutlich zu erkennen, daß ein hoher Grad an Redundanz
in der Relation, die die Daten der Graphen umfasst, vorliegt. Diese wird durch das
Verwenden eines Index über den Relationennamen und Attributnamen behoben. Dabei
werden die beiden Attribute zusammengefasst, was nochmals Speicher spart, da noch
weniger Felder pro Tupel notwendig sind.
Der Einfachheit soll über den diversen Attributwerten ein Index gelegt werden und
dieser wiederum in einer zweiten Datei abgelegt werden.
!

Kapitel 4. Entwurf des Offlinewerkzeugs 63
!"#
$ % # &
Abbildung 4.9: Aktivitätsdiagramm zur Funktionsweise des Komprimierungstool
4.3 Entwurf und Implementation
In dieser Phase der Softwareentwicklung werden die funktional beschriebenen Aspekte
des konzeptuellen Schemas in eine Form überführt, die die systemebezogenen und qualitativen
Aspekte berücksichtigt. Wie in den Anforderungen angegeben, wird als Programmiersprache
Java verwendet.
4.3.1 Relationenmodell der internen Daten
In diesem Abschnitt wird die Überführung des ER-Schemas 4.6 in ein Datenbankschema
beschrieben. Die Abbildung des ER-Modells auf ein Relationenmodell orientiert sich an
folgenden Grundprinzipien ([HS00]):
• Entity-Typen und Beziehungstypen werden auf Relationenschemata abgebildet.
Die Attribute werden zu Attributen des Relationenschemas, die Schlüssel werden
übernommen.
• Die verschiedenen Kardinalitäten der Beziehungen werden durch Wahl der Schlüssel
bei dem zugehörigen Relationenschema ausgedrückt.
• In einigen Fällen können Relationenschemata von Entity- und Beziehungstypen
miteinander verschmolzen werden.
• Zwischen den verbleibenden Relationenschemata werden diverse Fremdschlüsselbedingungen
eingeführt.

64 4.3. Entwurf und Implementation
Die Angaben in Tabelle 4.1 für die Entscheidung, welches der Primärschlüsselattribute
der Entity-Typen Primärschlüssel der Beziehung bzw. Relation wird, werden in Form
des Standard-ER-Modells angegeben.
ER-Konzept wird abgebildet auf relationales Konzept
Entity-Typ Ei Relationenschema Ri
Attribute von Ei Attribute von Ri
Primärschlüssel Pi Primärschlüssel Pi
Beziehungstyp Relationenschema
Attribute: P1, P2
dessen Attribute weitere Attribute
1:n P2 wird Primärschlüssel der Beziehung
1:1 P1 und P2 werden Schlüssel der Beziehung
m:n P1 ∪ P2 wird Primärschlüssel der Beziehung
Tabelle 4.1: Abbildung eines ER-Schemas auf ein relationales Schema [HS00]
Bezeichnungen:
E1, E2: an Beziehung beteiligte Entity-Typen
P1, P2: deren Primärschlüssel
bei 1:n-Beziehung: E2 ist die n-Seite
Das resultierende Datenbankschema DinterneDaten soll nun anschließend definiert werden.
Die Basis der Transformation ist das Entity-Relationship-Schema, welches in Abbdildung
4.6 dargestellt wird.
DinterneDaten = {RP rimaryData, RQueryInputData, RQueryOutputData, RRelationAttributes}
Die einzelnen Relationenschemata sind folgendermaßen aufgebaut.
RP rimaryData = {id, value}
KP rimaryData = {id}
RQueryInputData = {id, value, raid, pid}
KQueryInputData = {id}

Kapitel 4. Entwurf des Offlinewerkzeugs 65
RQueryOutputData = {id, value, raid, qinid}
KQueryOutputData = {id}
RRelationAttributes = {id, tableAttributeNames}
KRelationAttributes = {id}
RQueryInputData raid(RQueryInputData) → id(RRelationAttributes)
pid(RQueryInputData) → id(RP rimaryData)
RQueryOutputData raid(RQueryOutputData) → id(RRelationAttributes)
qinid(RQueryOutputData) → id(RQueryInputData)
Dieses Datenbankschema wird durch entsprechende DDL Konstrukte der Sprache
SQL über die Schnittstelle JDBC generiert.
4.3.2 Plugin-Struktur
Die Plugin Struktur, die in der Spezifikation konzeptuell beschrieben wurde, wird als Vorlage
für die Implementation genutzt. Die einzelnen Komponenten lassen sich auf Pakete
abbilden. Es existiert somit jeweils ein Paket inputPlugins, outputPlugins, queryModule.
Zusätzlich gibt es ein Basispaket, welches allgemeine Klassen, die eben genannten Pakete
und weitere Pakete beinhaltet. Es wird mit dataPathQuery bezeichnet.
Das Paket dataPathQuery.inputPlugins
Das Paket inputPlugins enthält alle Grundlagen zur Definition neuer Eingabeplugins.
Ein Eingabeplugin muss alle grundlegenden Bestandteile, die die Schnittstelle Input-
PluginInterface definiert, implementieren. Wie in Abbildung 4.10 dargestellt, erbt die
Schnittstelle InputpluginInterface von den beiden Schnittstellen ExchangeableInterface
und RegExpInterface. Dies bedeutet das jedes Eingabeplugin in der Lage sein muss mit
ExchangeData-Objekten und regulären Ausdrücken umzugehen bzw. diese Eigenschaften
vorweisen muss. Zusätzlich erweitert das InputpluginInterface diese Schnittstellen um die
Funktionen der Pluginformationen, die notwendig sind, um die semantischen Informationen
an die Ausgabeplugins zu übermitteln, wie bereits im Abschnitt 4.2.1 erwähnt
wurde.
Die Klasse StandardInputPlugin ist eine abstrakte Klasse, die als Basis für die Entwicklung
neuer Eingabeplugins fungieren soll. Sie implementiert Standardfunktionen,
die in jedem Eingabeplugin benötigt werden. Die neuen Eingabeplugins werden für spezielle
Anwendungfälle definiert. Dabei sind vor allem die graphische Nutzeroberfläche

66 4.3. Entwurf und Implementation
und natürlich die Art der Datenbeschaffung neu zu organisieren. Ein Beispiel für ein
Eingabeplugin wird im Anhang in der Abbildung A.4 gegeben. In diesem Fall gibt es
als Ausgangsbasis ein Ausgabedatei eines externen Tools. Aus dieser Datei werden die
Informationen gewonnen, die als Eingabe für die Pfadanfragen genutzt werden. Es gilt
also einen Parser zu finden oder selbst zu entwickeln. In diesem Beispiel gibt es bereits
einen Parser, der Teil des BioJava Pakets [DHH + 05] ist. Insgesamt werden werden im
Beispielplugin vier Teilaktivitäten gefordert. Zunächst die Eingabedatei in der die Informationen
enthalten sind, die für die Anfrage als Eingabe benötigt werden. Dannach
muss der Pfad, der zwischen Start und Zielknoten durchlaufen werden soll, beschrieben
werden. Der dritte Punkt ist die Festlegung der Zieldaten. Abschließend muss ein Ausgabeplugin
ausgewählt werden, welches die gefundenen Zusammenhänge präsentieren
kann. Optional kann im Menü Options (Abb. A.5) die Datei für die Abbildung der externen
Bezeichner auf die intern verwendeten Bezeichner der Knoten ausgewählt werden.
Wird dies nicht getan, wird eine Standardabbildung verwendet. Wurden alle Einstellungen
vorgenommen, wird der Anfrageprozess durch Betätigung des Schalters Start Query
gestartet.
Die Abbildung 4.11 zeigt die Klasse RegularExpressionComposerDialog. Es handelt
sich um ein Dialogfenster, welches aus den Eingabeplugins aufgerufen werden
kann, um reguläre Ausdrücke zu definieren. Dieser Dialog wird in der Abbildung
A.6 dargestellt. Der reguläre Ausdruck in dieser Abbildung beschreibt alle
Pfade vom Start zum Ziel, in denen kein Knoten mit der Beschreibung AAR-
HUS_GHENT_2DPAGE_LINK.SECONDARY_ID und einem beliebigen Wert durchlaufen
wird. Durch das Voran- und Nachstellen des Knotens [ANY] im Zusammenhang
mit dem ⋆-Quantor, wird ein beliebig langer Pfad beschrieben und gleichzeit der Ausnahmefall
an eine beliebige Position im Pfad gesetzt. Es ist somit eine beliebige, eventuell
leere Menge von Knoten vor und nach dem konkreten Ausschlußkriterium möglich.
Das Paket dataPathQuery.outputPlugin
Dieser Abschnitt wird die Bestandteile des Pakets outputPlugin beschreiben. Im aktuellen
Stadium des Tool wurde noch kein Plugin zur Ausgabe des Anfrageergebnisses entworfen.
Aus diesem Grund beschränkt sich das Paket auf die Definition eines Interfaces,
welches zwei Sachen sicherstellen soll. Einerseits muss jedes Ausgabeplugin die Funktion
haben seine Semantik bezüglich der von ihm präsentierten Daten. Zusäztlich muss
es mit den internen Daten den Exchange-Daten umgehen können. Aus diesem Grund
besteht eine Spezialisierungsbeziehung zur Schnittstelle ExchangeableDateInterface. In
Abbildung 4.12 wird der Zusammenhang in Form eines Klassendiagramms dargestellt.
Das Paket dataPathQuery.queryModule
Das Paket queryModule beinhaltet die Klassen, die die Anfrageverarbeitung realisieren.
Es umfasst mehrere Klassen, die der Übersicht wegen auf vier Klassendiagramme verteilt
werden. Das erste Diagramm zeigt zum einen die Schnittstelle queryModuleInterface, die

Kapitel 4. Entwurf des Offlinewerkzeugs 67
dataPathQuery.queryModule.RegularExpression
PluginInfo
description: String
inputData: Vector
outputData: Vector
PluginInfo()
«interface»
RegExpInterface
regularExpression
getRegularExpression()
«import»
«instantiate»
«import»
«import»
«interface»
InputPluginInterface
getPluginInfo()
StandardInputPlugin
primaryData: String
targetData: String
StandardInputPlugin()
StandardInputPlugin()
StandardInputPlugin()
StandardInputPlugin()
StandardInputPlugin()
StandardInputPlugin()
defineLayout()
getExchangeData()
getNextPublicDBData()
getNextPublicDBName()
getPluginInfo()
getnextDBpublicID()
setExchangeData()
setGenerellParameter()
setPublicDBData()
setQueryInputData()
dataPathQuery.ExchangeData
«interface»
ExchangeableDataInterface
exchangeData
getExchangeData()
«import»
Abbildung 4.10: Klassendiagramm zum Packet datapathquery.inputPlugin

68 4.3. Entwurf und Implementation
RegularExpressionComposerDialog
RegularExpressionComposerDialog()
RegularExpressionComposerDialog()
RegularExpressionComposerDialog()
RegularExpressionComposerDialog()
RegularExpressionComposerDialog()
RegularExpressionComposerDialog()
RegularExpressionComposerDialog()
RegularExpressionComposerDialog()
RegularExpressionComposerDialog()
RegularExpressionComposerDialog()
RegularExpressionComposerDialog()
actionPerformed()
TokenPanel()
keyPressed()
keyReleased()
keyTyped()
mouseClicked()
mouseEntered()
mouseExited()
mousePressed()
mouseReleased()
valueChanged()
TokenPanel
TokenPanelButton
parentPanel: TokenPanel
TokenPanelButton()
TokenPanelButton()
TokenPanelButton()
TokenPanelButton()
TokenPanelButton()
«import»
«instantiate»
dataPathQuery.queryModule.RegularExpression
destinationNode: String
expression: String
sourceNode: String
RegularExpression()
RegularExpression()
«import»
«interface»
RegExpInterface
regularExpression
getRegularExpression()
Abbildung 4.11: Klassendiagramm zum Packet datapathquery.inputPlugin - Dialog zur
Definition der regulären Ausdrücke

Kapitel 4. Entwurf des Offlinewerkzeugs 69
«interface»
dataPathQuery.inputPlugIns.ExchangeableDataInterface
getExchangeData()
setExchangeData()
«interface»
OutputPluginInterface
getPluginInfo()
«import»
dataPathQuery.inputPlugIns.PluginInfo
description: String
inputData: Vector
outputData: Vector
PluginInfo()
getDescription()
getInputData()
getOutputData()
setDescription()
setInputData()
setOutputData()
Abbildung 4.12: Klassendiagramm zum Packet datapathquery.outputPlugin
zum einem von der Schnittstelle ExchangeableDataInterface abgeleitet wird und eine
Methode executeQuery definiert. Diese Methode soll den konkreten Anfragealgorithmus
umsetzen. In unserem Fall wäre dies das im vorherigen Kapitel ermittelte Konzept. Die
Standard Implementation, die nun das ermittelte Konzept realisieren soll, soll in der
Klasse StandardQueryModule protoypisch realisert werden.
Die Abbildung 4.14 stellt die Zusammenhänge der Klasse Graphfilter dar. Diese Klasse
ist die Implementation der ersten Phase des Konzepts. Hier wird aufgrund der Startund
Zielinformation eine Filterung der Graphen durchgeführt. Um diese Aufgabe zu bewältigen,
werden zwei Dinge benötigt. Es muss möglich sein mit den internen Daten zu
kommunizieren. Dazu wird ein Exchange-Objekt beim Erzeugen des Graphfilter-Objekts
an dieses übergeben. Da bei der Definition des Regulären Ausdrucks im jeweiligen Eingabeplugin
die konkreten Bezeichner für die RelationAttribut-Wertepaare angegeben werden,
müssen zuvor diese Werte in die Entsprechende Indizes übersetzt werden. Daher
wird ein RegularExpressionVocabulary-Objekt initiiert.
Nach dem die Graphfilter-Phase durchlaufen wurde, existiert nun eine Menge von
potentiell möglichen Treffergraphen. Eben solche, die den erweiterten Anforderungen gerecht
werden. Diese Anforderungen werden durch das Einschränken der Pfade mittels des
Patterns bestimmt. Das Patter beschreibt einen regulären Ausdruck, der festlegt welche
Pfade akzeptiert werden und welche aus dem Raster fallen. Die Analyse basierend auf
dem Pattern wird in der Klasse RegExpAnalyser durchgeführt. Die Eingangsmenge der

70 4.3. Entwurf und Implementation
«interface»
QueryModuleInterface
executeQuery()
StandardQueryModule
StandardQueryModule()
executeQuery()
getExchangeData()
setExchangeData()
«import»
«interface»
dataPathQuery.inputPlugIns.ExchangeableDataInterface
getExchangeData()
setExchangeData()
«interface»
dataPathQuery.inputPlugIns.InputPluginInterface
getPluginInfo()
Abbildung 4.13: Klassendiagramm zum Packet datapathquery.queryModule (Teil 1 - StandardQueryModule)
Graphen für die Klasse sind genau die Graphen, welche als Resultat aus der Graphfilter-
Phase hervorgehen. Wie das Konzept besagt, wird die Analyse unter Verwendung der
hierarischen Technologie XML durchgeführt. Die Abbildung 4.15 stellt die an der Analyse
beteiligten Klassen dar. Die Klasse RegExpAnalyser organisiert die Analyse und
initiiert ein Objekt der Klasse GraphDataConverter in der nun konkret die einzelnen
notwendigen Funktionen implementiert werden. Die Schnittstelle GraphList ist Teil der
Menge von Schnittstellen und Klassen, die aus dem JAXB Binding Prozess hervorgegangen
sind. Diese Menge wird zum Paket GraphExportParser gebündelt. Im Abschnitt
4.3.3 wird mehr zu diesem Paket gesagt.
Die letzte Abbildung 4.16 zum Paket queryModule zeigt die drei Klassen Regular-
Expression, RegularExpressionVocabularyLinker und RegularExpressionVocabulary. Die
Klasse RegularExpression speichert den im Eingabeplugin formulierten regulären Ausdruck.
Wobei der Start und Zielknoten gesondert behandelt wird, da ihnen zunächst in
der Graphfilter-Phase eine gesonderte Rolle zukommt. Erst in der Analyse-Phase wird
dann die Einschränkung der Pfade mit einbezogen. Die Klasse RegularExpressionVocabulary
dient zur effizienteren Verarbeitung der RelationAttribut-Kombinationen. Es
ist eine Hashtabelle, die die Indezes aufschlüsseln kann. Der Schlüssel der Hashtabelle
ist direkt der Wert des Index und mit get(Index) wird die entsprechende Kombination
zurückgeliefert. Die letzte Klasse RegularExpressionVocabularyLinker widmet sich dem
Problem, das es zwischen den internen Bezeichnern und den Bezeichnern , die auf der
Seite der einzelnen Datenbanken vorliegen, Abweichungen gibt. Zum Beispiel ist bei einer
Datenbank mit emb und dem nachfolgenden Identifikator die Accession Nummer eines
Datenbankeintrags aus der EMBL Datenbank des EBI gemeint. Bei den internen Daten
wird dies jedoch mit dem Bezeichner embl_link.accession in Verbindung gebracht. Somit
muss eine Abbildung zwischen emb und embl_link.accession erfolgen. Diese Abbildung

Kapitel 4. Entwurf des Offlinewerkzeugs 71
dataPathQuery.ExchangeData
scheme: DataScheme
ExchangeData()
ExchangeData()
closeData()
getPrimaryData()
getPrimaryDataID()
getQueryInputDataID()
getQueryOutputDataID()
getRelationAttributesID()
getScheme()
setPrimaryData()
setPrimaryData()
setQueryInputData()
setQueryOutputData()
setRelationAttributes()
setScheme()
GraphFilter
GraphFilter()
getPotentialGraphs()
«import» «instantiate»
RegularExpressionVocabulary
RegularExpressionVocabulary()
RegularExpressionVocabulary()
setVocabulary()
setVocabulary()
Abbildung 4.14: Klassendiagramm zum Packet datapathquery.queryModule (Teil 2 - Graphfilter)

72 4.3. Entwurf und Implementation
«interface»
dataPathQuery.graphExportParser.graphContentModel.GraphList
RegExAnalyser
checkGraphsForRegularExpression()
setRegularExpression()
dataPathQuery.graphExportParser.GraphDataConverter
GraphDataConverter()
getGraphList()
getGraphListandWriteXMLFile()
getPaths()
«import»
«instantiate»
«import»
Abbildung 4.15: Klassendiagramm zum Packet datapathquery.queryModule (Teil 3 - Reg-
ExpAnalyser)

Kapitel 4. Entwurf des Offlinewerkzeugs 73
muss vom Nutzer angegeben werden. Die Klasse RegularExpressionVocabularyLinker
nutzt dafür eine Datei, die je Zeile eine Abbildung beschreibt (siehe Listing 4.1). Es ist
möglich für verschiedene Quellen verscheidene Abbildungen zu definieren. Es ist dann
nur nötig die Datei in der korrekten Syntax zu definieren und dann der Klasse Regular-
ExpressionVocabularyLinker zu übergeben.
emb=embl_link . secondary_id
p i r=p i r _ l i n k . primary_id
Listing 4.1: Beispiel einer Link-Datei für die Klasse RegularExpressionVocabularyLinker
RegularExpressionVocabulary
RegularExpressionVocabulary()
RegularExpressionVocabulary()
setVocabulary()
setVocabulary()
RegularExpressionVocabularyLinker
RegularExpressionVocabularyLinker()
RegularExpressionVocabularyLinker()
RegularExpressionVocabularyLinker()
RegularExpression
destinationNode: String
expression: String
sourceNode: String
RegularExpression()
RegularExpression()
getDestinationNode()
getExpression()
getSourceNode()
setDestinationNode()
setExpression()
setSourceNode()
Abbildung 4.16: Klassendiagramm zum Packet datapathquery.queryModule (Teil 4)
4.3.3 Das Paket GraphExportParser
Das Paket dataPathQuery.GraphExportParser ist das Resultat des JAXB Binding Prozesses.
Die Anweisung, die für die Ausführung dieses Vorgangs verwendet wird, wird im
Listing 4.2 dargestellt. Das Ergebnis dieses Befehls ist eine Paketstruktur, die alle Elemente
der XML-Schema Datei (siehe Listing B.1 und B.2) als Java Bean enthält. Diese
Pakete werden in Abbildung 4.17 dargestellt.
x j c −d t a r g e t D i r e c t o r y −p dataPathQuery . graphExportParser graphList .
»xsd

74 4.3. Entwurf und Implementation
Listing 4.2: Anweisung zur Generierung des Javaklassen entsprechend der Schema-Datei
durch JAXB
Das Paket dataPathQuery.graphExportParser.graphContentModel enthält die
Schnittstellen GraphList, GraphListType, GraphType, Node und NodeType. Weiterhin
enthält es die Klasse ObjectFactory, die das Erstellen von Objekte entsprechend der
Schnittstellen ermöglicht. Durch jeweilige Methoden der Form createSchnittstellenname()
werden die Objekte erzeugt.
Neben diesen Klassen und Schnittstellen wurde eine weitere Klasse definiert. Sie trägt
den Namen GraphDataConverter. In Abbdildung 4.18 werden ihre wichtigsten Abhängigkeiten
verdeutlicht. Die Klasse wird im Anfragemodul verwendet. Mit ihr wird die
Transformation der Daten aus der Relation in XML-Dokumentenstruktur vollzogen. Die
Methode getGraphList() liefert ein GraphList-Objekt zurück, welches das Wurzelelement
der konkreten Dokumenteninstanz darstellt. Bei der Methode getGraphListAndWriteXmlFile()
wird neben der Rückgabe des GraphList-Objekts zusätzlich dessen Inhalt in ein
XML-Dokument geschrieben. Dazu wird der Marshalling-Prozess des Java XML Binding
verwendet. Dies soll zur Erläuterung des GraphExportParser-Pakets genügen. Im nächsten
Abschnitt wird auf die Komponenten eingegangen, die denen die Funktionen des
Imports der Informationen in die Datenbasis des Tools verwirklicht werden.
Abbildung 4.17: Paketübersicht der Subpakete des Pakets datapathquery.graphExportParser
4.3.4 Import der RelationAttribut-Wertepaare und Graphinformationen
Dieser Abschnitt beschäfftigt sich mit den Bestandteilen des Pakets dataPathQuery.importGenerator.
Im wesentlichen umfassen die Klassen die Funktion, die Graphinformationen
zu komprimieren und dannach wieder in das Tool zu integrieren. Die
Kompression ist unabhängig vom Nutzer des Tools. Die Klasse GraphCompression liest
die Daten aus der Relation aus. Die Relation entspricht der Relation RGraph, wie sie im
Abschnitt 3.3.1 definiert wurde. Die prinzipielle Funktionweise der Klasse GraphCompression
wurde im Abschnitt 4.2.4 erläutert. Es ist eine Komponente, die als Kommandozeilentool
ausgelegt ist und serverseitig aufgerufen werden muss. Es generiert eine Datei,
die als Bytestream geschrieben wird. Sie enthält die Indizes und den Wert des Attributs
pathid ∈ RGraph von jedem Tupel. Dadurch werden einerseits Whitespace-Chararcter

Kapitel 4. Entwurf des Offlinewerkzeugs 75
org.apache.commons.jxpath.JXPathContext
GraphDataConverter
GraphDataConverter()
getGraphList()
getGraphListandWriteXMLFile()
getPaths()
graphContentModel.ObjectFactory
ObjectFactory()
createGraphList()
createGraphListType()
createGraphType()
createNode()
createNodeType()
getProperty()
newInstance()
setProperty()
«access»
«instantiate»
«import»
«interface»
javax.xml.bind.Marshaller
Abbildung 4.18: Klassendiagramm zum Packet datapathquery.graphExportParser

76 4.3. Entwurf und Implementation
RelationAttributeValueException
RelationAttributeValueException()
RelationAttributeValueException()
CompressedGraphDataImporter
CompressedGraphDataImporter()
CompressedGraphDataImporter()
readCompressedData()
RelationAttributeDataImporter
RelationAttributeDataImporter()
«access»
CompressionProperties
«access» «access»
GraphCompression
GraphCompression()
GraphCompression()
GraphCompression()
Abbildung 4.19: Klassendiagramm zum Packet importGenerator
eingespart und ebenfalls der Zeilenvorschub. Es ist möglich direkt byteweise einzulesen,
weil genau festgelegt wurde, welches Byte welche Informationen enthält. Die ersten 4
Bytes entsprechen dem Integer-Wert des Attributs pathid und die nächsten vier Bytes
sind zwei Short-Werte, die dem Index der RelationAttribut-Wertepaaren entsprechen.
Die zweite Datei wird als Characterstream im ISO-8859-1 Encoding geschrieben.
Sie enthält die Tiefeninformation sowie die Werte des Vater- und Kindknotens. Dabei
werden die String-Werte mit Hochkommas begrenzt. Zusätzlich dient das Komma
als Whitespace-Character für die einzelnen Felder. Mittels eines StreamTokenizers, eine
Standardklasse aus dem Standardpaket java.io, können diese Felder ausgelesen werden.
Die dritte Datei ist die Indexdatei, die die Indizes der RelationAttribut-Wertepaare enthält.
Diese muss bereits vor der Ausführung der Komponente GraphCompression vorliegen,
da sie für die Aufschlüsselung der Indizes im Komprimierungsprozess benötigt wird.
Sie aber auch gleichzeitig eine Ausgabedatei, da sie zur rückwärtigen Aufschlüsselung
der Indizes zu den RelationAttribut-Wertepaare benötigt wird.
Die Klasse CompressionProperties legt verschiedene Werte fest die von mehreren
Komponenten genutzt werden. Sie dient zur Vereinfachung und Zentralisierung der Einstellungen.
Somit wird sichergestellt das wichtige Einstellungen von allen beteiligten
Komponenten identisch sind.
Die beiden Importer für die RelationAttribut-Wertepaare und für die komprimierten
Graphdaten, werden auf der Seite des Nutzers ausgeführt. Sie sind als als Bestandteil des
OfflineTool zu verstehen. Deswegen werden diese Komponenten in die Nutzeroberfläche
des Tools eingebunden. Wie diese Komponenten eingebunden werden, wird im Screenshot

Kapitel 4. Entwurf des Offlinewerkzeugs 77
A.1 ersichtlich. Die entsprechenden Einträge im Menü Options starten jeweils eine Folge
von Dateidialogfenster, bei denen die notwendigen Dateien abgefragt werden.
An dieser Stelle ist das Ende diese Kapitels erreicht. Im nächsten Kapitel wird nun
eine Zusammenfassung der und ein Ausblick für die Arbeit gegeben.

78 4.3. Entwurf und Implementation

Kapitel 5. Zusammenfassung und Ausblick 79
Kapitel 5
Zusammenfassung und Ausblick
Die vorliegende Arbeit beschäfftigt sich mit der Idee flexible Anfrage auf einer Graphstruktur
zu formulieren. Zu Beginn der Arbeit wurde eine Motivation geliefert, die
vermitteln sollte, inwiefern dieses Ziel auf praktischer Ebene erwünscht ist. Außerdem
sollte sie zeigen, welche Absicht bezüglich des informationstechnischen Gedankens als
Grundlage für weitere Analyse im Umfeld des Datamining auf dieser Grundlage arbeiten
werden. Weiterhin zeigte sie, welche Gründe zur Verwendung von Graphstrukturen bei
der Analyse Daten von Vorteil sind. Zudem wurde die Zielstellung der Arbeit in knappen
Worten zusammengefasst. Am Ende der Einleitung wurden einige Technische Mittel
erläutert die in späteren Kapiteln ihre Anwendung finden.
Im Anschluß an die Einleitung wurden die Grundlagen formuliert, die als Basis für
die analytische Arbeit zur Ermittlung des Anfragekonzepts dienen. Zunächste wurden
die biologischen Grundlagen aufgeführt. Dies umfasste einerseits die Erläuterung einiger
Begriffe, die für das Verständnis der biologischen Daten von Bedeutung sind. Desweiteren
wurden die Datenbasis, auf der die Entwicklung des resultierunden Werkzeugs aufbaut,
ausführlicher betrachtet, um eine Vorstellung von den enthaltenen Daten zu entwickeln.
Dem biologischen Abschnitt folgt die Darstellung von Datenbankmodellen. In diesem Abschnitt
werden die grundlegenden Ideen zum relationalen Datenbankkonzept und zum
objektorientierten Datenbankkonzept dargestellt. Bei den relationalen Datenbankmangementsystemen
werden die Daten gemäß des Relationenmodells abgelegt. Relationen
sind Tabellen mit einem Tabellenkopf und atomaren Werten in den einzelnen Spalten.
Jede Zeile dieser Tabelle ist ein Datensatz, was im Relationenmodell als Tupel bezeichnet
wird. Im Objektdatenbankmanagementsystemen dient der objektorientierte Ansatz
bzw. das Objektparadigma als Gundlage. Im gegensatz zu den RDBMS werden hier Objekte
gespeichert. Objekte definieren sich über ihrer Struktur und ihrem Verhalten und
werden durch Typkonstruktoren gebildet. Aus strukureller Sicht sind Objekte mächtiger
als Relationen. Alternativ formuliert sind Relationen Objekt eines speziellen Typs, der
durch den Set und Tupelkonstruktor erzeugt wird.
Nachdem die Datenbankmodelle beschrieben wurden, wurde der dokumentenbasierende
Ansatz in seinen Grundlagen betrachtet. Die Technologie auf dem dieser Ansatz

80
basiert ist die Sprache XML. Es wurden ihre Eigenschaften der Selbstbeschreibung, der
Trennung von Präsentation und Inhalt und Wohlgeformtheit und Gültigkeit beschrieben.
Weiterhin wurde der XML Schema Dokumenttypdefinitionsansatz erläutert, der
die Struktur eines XML Dokuments festlegt. Am Ende des Grundlagenkapitels wurden
grundlegende Begriffe der Graphentheorie definiert, um noch einmal die Begriffe des
Graphentheorie ins Gedächtnis zurückzurufen.
Das nächste Kapitel beschäfftigt sich mit der Analyse der aktuellen Anfragetechnologien
in den Bereichen Relationale Datenbanksysteme, Objektdatenbanken und XML-
Anfragesprachen. Im Bereich relationale Datenbanken ist die Sprache SQL als Standard
anzusehen. Sie basiert auf theoretisch sehr ausgereiften und gut durchdrungenen Konzepten,
wie der Relationenalgebra und dem Tupelkalkül. Aus diesem Grund existiert auch
eine genaue formale Beschreibung der möglichen Operationen. Bei den Anfragesprachen
in Objektdatenbanken gibt es durch die ODMG einen Versuch einen ähnlichen Standard
für Objektdatenbanken zu finden und zu definieren. Das Ergebnis dieser Bemühungen ist
die Sprache OQL. Sie ist konzipiert als eine Obermenge des SQL-92 Standards. Jedoch
umfaßt sie keine Manipulationskonstrukte, wie es in Bezug auf SQL durch die sogenannte
DML Konstrukte der Fall ist. Stattdessen wird die Manipulation der Objekte auf die
Anbindung von Programmiersprachen und der dortigen Definition von Methoden für einzelne
Objekte verlagert. Im Gegensatz zu SQL gibt es für OQL keine formale Algebra als
Grundlage. Ihre Bedeutung wird durch Beschreibungen und Beispiele erläutert. Demzufolge
wurde in den entsprechenden Abschnitte keine formalen Beschreibung der Operationen
der Sprache OQL gegeben. Als Resultat der Analyse wurde SQL in Bezug auf die
Problematik als geringfügig günstig befunden, da sie von Natur aus nicht auf hierischen
oder pfadähnlichen Strukturen arbeitet, sondern auf einer Mengensemantik basiert. Das
Erzeugen von längeren und komplexeren hierischen Zusammenhängen in SQL ist nur
mit erheblichem Aufwand bzw. nur theoretisch möglich. Lediglich das RDBMS Oracle
bietet durch die CONNECT BY-Klausel eine Möglichkeit hierarische Informationen auszulesen.
Jedoch ist der relationale Ansatz für eine einfache Start-Ziel-Suche sehr gut
geeignet, durch Ausführen eines einfache Verbunds. Somit können in diesem einfachen
Fall die positiven Eigenschaften des relationalen Konzepts genutzt werden. Denn durch
den deskriptiven Charakter der Sprache und durch das einfache Modell der Relationen
können die Anfragen in SQL sehr gut optimiert werden.
OQL unterliegt im wesentlichen einer ähnlichen Einschränkung wie SQL, denn sie
arbeitet auf einer Menge von Objekten. Jedoch ist möglich durch die Definition von
komplexen Strukturen und Methoden in den Objekten selbst, die Graphinformationen in
einer günstigen Form abzulegen. Zusätzlich werden dann Methoden formuliert, die dann
das eigentliche Prüfen der Pfade im Graphen realisieren. Durch die Möglichkeit in OQL
diese Methoden aufzurufen, können dann Anfrage gestellt werden, die dann auch entsprechende,
komplexere Pfade zurückgeliefern. Ein entscheidenes Problem, mit dem der
Standardisierungversuch der ODMG zu kämpfen hat, ist das im Bereich der integrierten,
frei verfügbaren DBMS im Moment nahezu keine Anwendung findet. Stattdessen werden
eigene Ansäzte in diesen Datenbanksystemen verwendet.

Kapitel 5. Zusammenfassung und Ausblick 81
Im Anschluss an die Anfragetechnologien für Datenbankmodelle wurden die Anfragesprachen
bezüglich der Sprache XML analysiert. In diesem Gebiet wurde die Anfragesprache
XPath geeignete Anfragesprache herausgearbeitet. Ihre Eigentschaft, ausgehend
von einem Kontextknoten, Knotenmengen zu selektieren, ermöglicht das auslesen komplexer,
und beliebig langer Pfade. Was die Anfragesprache in Bezug auf die Problematik
als geeignet angesehen werden kann. Jedoch hat die Technologie ein Problem. Bevor
XPath verwendet werden kann, müssen die Graphinformationen in ein XML-Dokument
überführt werden. Diese Transformation hat eine entscheidene negativate Auswirkung.
Das ohnehin schon beachtliche Datenvolumen wird durch das Hinzufügen von Markierungen
erheblich erhöht. Da die Graphdaten lokal auf dem jeweiligen Rechner zu speichern
sind, muss es das Bestreben sein, das Datenvolumen so gering wie möglich zu halten.
Deswegen bietet sich die Speicherung der Daten in wohlgeformten XML-Dokumenten
nicht an.
Die resultierende Entscheidung war eine Lösung zu verwenden, die sowohl aktuell
umsetzbar ist und die Vorteile der einzelnen Konzepte nutzt. Deswegen wird zunächst
eine Filterung der Graphdaten in einer relationalen, integrierten Datenbanklösung
durchgeführt. Die daraus resultierende Menge von Graphen wird dann in eine
XML-Dokumentenstruktur überführt, auf deren Basis durch XPath die Pfade ermittelt
werden. Diese können entweder direkt in XPath geprüft werden oder zunächst in
Stringform zurückgegeben und daraufhin ausgewertet werden. In beiden Fällen wird die
Auswertung durch reguläre Ausdrücke realisiert. Diese definieren ein Muster, welches
die zu akzeptierenden Pfade beschreibt. Insgesamt gesehen steckt im objektorientierten
Ansatz ein gewisses Potential, welches jedoch in Abhängigkeit von der Unterstützung
durch entsprechnde Datenbanksysteme ist.
Das letzte Kapitel beschäfftigt sich mit dem Entwurf des Softwaretools. Dazu wird
der Softwareentwicklungsprozess durch den Softwarelebenzyklus beschrieben. Zunächst
wurden die Problemdefinition und die Anforderungen analysiert. Nachdem die Anforderungen
definiert wurden, wurde das Softwaretool in der Spezifikation konzeptuell beschrieben.
Als grundlegendes Konzept für die Struktur des Softwaretool wird ein Pluginkonzept
verwendet. Prinzipiell wird die Software aus Eingabe, Ausgabeplugins und
Anfragemodulen bestehen. Weiterhin wurde die interne Datenstruktur konzeptuell in
einem ER-Schema definiert. Außerdem wurden Anwendungsfälle für das Tool ausgearbeitet,
die es später umzusetzen galt. Neben der eigentlich Funktion des zu entwickelnden
Softwaretool kristalisierten sich noch zwei Aspekte. Zum einen war es für das Herunterladen
der Daten unbedingt erforderlich die Datenmengen zu reduzieren. Dazu wurden das
Datenvolumen der Graphinformation durch Eliminierung von Redundanzen und durch
byteweise speichern reduziert. Der zweite Aspekt ist Generierung der Werte für die Knotenbeschreibungen,
die sich aus Relation- und Attributnamen zusammensetzen. Diese
werden an zwei Positionen verwendet. Einmal bei der internen Datenstruktur und einmal
bei der XML-Schema Datei für den XML Binding Prozess.
Nachdem dieses konzeptuelle Modell erstellt wurden, mussten nun diese Ansätze in
konkrete Formen gebracht werden. Es wurden entsprechen der Pluginstruktur Pakete

82
gebildet. Diese enthalten Klassen, die durch Klassendiagramme visualisiert wurden und
die zuvor ermittelten Funktionen und Konzepte implementieren. Gegenwärtig existiert
noch keine vollständig abgeschlossene Version des Softwaretools. Einzelne Bestandteile
wurden erfolgreich implementiert. Es ist bereits gelungen auf einer Testmenge von
Daten Anfragen zu formulieren, die zutreffende Pfade zurücklieferten. Weiterhin wurde
die Möglichkeit, reguläre Ausdrücke in einem Dialog zu definieren, erfolgreich implementiert.
Ausserdem wurden ein Testplugin entworfen, welches diesen Dialog aufrufen
kann und bis auf die Festlegung des Ausgabeplugins alle notwendigen Informationen ermittelt.
Auch das Registrieren von Plugins wurde grundlegend im Prototypen erfolgreich
realisiert. Es gilt jedoch noch Unterscheidungen bezüglich der Eingabe und Ausgabeplugins
bei der Registrierung zu treffen. Die interne Datenstruktur ist erfolgreich in einem
Datenbankschema über die JDBC-Schnittstelle integriert. Vorbereitet wurde auch die
Implementation der Ausgabeplugins und die Übergabe der semantischen Informationen
zwischen diesen und den Eingabeplugins. Was fehlt, ist die Zusammensetzung der einzelnen
Bestandteile und das Einbinden der Zusatzinformationen bei der Darstellung der
Anfrageergebnisse. Mit dem Abschnitt Entwurf und Implementation ist das Ende dieser
Arbeit erreicht.

Anhang A. Screenshots vom OfflineTool BioDataPathQuery 83
Anhang A
Screenshots vom OfflineTool
BioDataPathQuery
A.1 Allgemeine Bestandteile
Abbildung A.1: Einträge des Menüs Options

84 A.1. Allgemeine Bestandteile
Abbildung A.2: Preference Dialogfenster

Anhang A. Screenshots vom OfflineTool BioDataPathQuery 85
Abbildung A.3: Menü Plugin, dessen Einträge die regristrierten Plugins sind

86 A.2. Beispiel eines Eingabeplugins
A.2 Beispiel eines Eingabeplugins
Abbildung A.4: Das Eingabeplugin BlastXInputPlugin

Anhang A. Screenshots vom OfflineTool BioDataPathQuery 87
Abbildung A.5: Das Eingabeplugin BlastXInputPlugin - Auswahl der Zuordnugnsdatei
der Token der regulären Ausdrücke

88 A.2. Beispiel eines Eingabeplugins
Abbildung A.6: Der Dialog zum Erstellen eines regulären Ausdrucks

Anhang B. XML-Schema 89
Anhang B
XML-Schema

90
maxOccurs="unbounded" />
Listing B.1: XML-Schema Datei der Graphstruktur

Anhang B. XML-Schema 91
. . .
. . .

92
. . .
Listing B.2: Auszug des XML-Schema Teils für die Knotenbeschreibungen

LITERATURVERZEICHNIS 93
Literaturverzeichnis
[ABK + 00] Anderson, R.; Birbeck, M.; Kay, M.; Livingstone, S.; Loesgen, B.; Martin,
D.; Mohr, S.; Ozu, N.; aPeat, B.; Pinnock, J.; STark, P.; Williams, K.:
Professional XML. Wrox Press Ltd, 2000.
[BPSM + 04] Bray, T.; Paoli, J.; Sperberg-McQueen, C. M.; Maler, E.; Yergeau, F.: Extensible
Markup Language (XML) 1.0 (Third Edition) - W3C Recommendation.
online: http://www.w3.org/TR/2004/REC-xml-20040204/, February
2004.
[CBB + 97] Cattell, R. G. G.; Barry, D. K.; Bartels, D.; Berler, M.; Eastman, J.; Gamerman,
S.; Jordan, D.; Springer, A.; Strickland, H.; Wade, D.: The Object
Database Standard: ODMG 2.0. Morgan Kaufmann Publishers, Inc., 1997.
[CBB + 00] Cattell, R. G. G.; Barry, D. K.; Berler, M.; Eastman, J.; Jordan, D.; Russel,
C.; Schadow, O.; Stanienda, T.; Velez, F.: The Object Database Standard:
ODMG 3.0. Morgan Kaufmann Publishers, Inc., 2000.
[CD99] Clark, J.; DeRose, S.: XML Path Language (XPath) Version 1.0 - W3C Recommendation.
online Spezifikation: http://www.w3.org/TR/xpath, November
1999.
[CFM + ] Chamberlin, D.; Frankhauser, P.; Marchiori, M.; Robie, J.; Florescu, D.:
XML Query Use Cases. Online Spezifikation: http://www.w3.org/TR/
xquery-use-cases/.
[CFMR] Chamberlin, D.; Frankhauser, P.; Marchiori, M.; Robie, J.: XML Query
(XQuery) Requirements. Online Spezifikation: http://www.w3.org/TR/
xquery-requirements/.
[DHH + 05] Down, T.; Heuer, M.; Huen, D.; Pocock, M.; Schreiber, M.: Biojava, September
2005. Online: http://www.biojava.org/.
[Dum00] Dumke, R.: Software Engineering. Friedrich Vieweg & Sohn Verlagsgesellschaft
mbH, Braunschweig, Wiesbaden, 2. Auflage, 2000.

94 LITERATURVERZEICHNIS
[EWHK + 96] Emden-Weinert, T.; Hougardy, S.; Kreuter, B.; Prömel, H. J.; Steger,
A.: Einführung in graphen und algorithmen. Institut für Informatik,
Humboldt-Universität zu Berlin, 1996. http://www.informatik.
hu-berlin.de/Institut/struktur/algorithmen/ga/.
[HS00] Heuer, A.; Saake, G.: Datenbanken — Konzepte und Sprachen . MITP-
Verlag, Bonn, 2. Auflage, 2000.
[KC86] Khoshafian, S.; Copeland, G. P.: Object identity. In Meyrowitz, N. (Hrsg.):
Proc. of the 1st Int. Conf. on Object Oriented Programming Systems, Languages
and Applications (OOPSLA’86), Portland, Oregon, SIGPLAN NO-
TICES 21(11), S. 406–416. ACM Press, November 1986.
[OM03] Ort, E.; Mehta, B.: Java Architecture for XML Binding (JAXB). online:
http://java.sun.com/developer/technicalArticles/WebServices/
jaxb/index.html, March 2003.
[PM] Plotnikov, D.; McClanahan, C.: JXPath - Package. Homepage: http:
//jakarta.apache.org/commons/jxpath/.
[RFC00] Robie, J.; Florescu, D.; Chamberlin, D.: Quilt: an XML Query Language for
Heterogeneous Data Sources. Lecture Notes in Computer Science, December
2000. siehe http://www.almaden.ibm.com/cs/people/chamberlin/
quilt.html.
[STS97] Saake, G.; Türker, C.; Schmitt, I.: Objektdatenbanken. International Thomson
Publishing, 1. Auflage, 1997.
[Wik] Wikipedia, die freie enzeklopädie. http://de.wikipedia.org/wiki/
Hauptseite.
[WK03] Wittenbrink, H.; Köhler, W.: XML. TEIA Lehrbuch Verlag, 2003.

Selbständigkeitserklärung
Hiermit erkläre ich, daß ich die vorliegende Arbeit selbständig und nur mit erlaubten
Hilfsmitteln angefertigt habe.
Magdeburg, den 7. September 2005
95
Michael Soffner