Methoden zum homogenen Zugriff und zur - Dr.

Methoden zum homogenen Zugriff und zur
Integration heterogener, biologischer Datenquellen
mittels beschränkter Zugriffsmuster
Dissertation
zur Erlangung der akademischen Grades
Doktoringenieur
(Dr.-Ing.)
angenommen durch die Fakultät für Informatik
der Otto-von-Guericke-Universität Magdeburg
von:
Dipl.-Inf. Matthias Lange
geb. am: 31.07.1973 in Magdeburg
Gutachter:
Prof. Dr. rer. nat. habil. Ralf Hofestädt
Prof. Dr. rer. nat. habil. Gunter Saake
Dr. rer. nat. Falk Schreiber
Magdeburg, den 30. März 2006
Lange, Matthias:
Methoden zum homogenen Zugriff und zur Integration heterogener,
biologischer Datenquellen mittels beschränkter Zugriffsmuster
216 Seiten
60 Abbildungen
10 Tabellen
Dissertation, Otto-von-Guericke-Universität Magdeburg, 2005.
Kurzfassung
Der Fortschritt in der Molekularbiologie, beginnend bei der experimentellen Datenakquisition zu einzelnen Genen und Proteinen über die post-genomics“-Technologien, wie
”
etwa DNA-Arrays“ oder Proteomics“ bis hin zur integrativen Bioinformatik mit dem
”
”
Ziel der Erfassung von Gesamtzusammenhängen ganzer biologischer Systeme, bedingt
steigende Erfordernisse an die elektronische Datenverarbeitung. Dabei werden gerade
das Internet und Web-Services“ als primäre Medien für die elektronische Veröffentli”
chung von Forschungsergebnissen genutzt.
Die vorliegende Arbeit ist dem Bereich der angewandten Informatik zuzuordnen.
Schwerpunkt ist die Identifizierung von Verfahren und Methoden aus dem Bereich der
Informationssysteme und Datenbanken, die zur Lösung bioinformatischer Fragestellungen aus dem Bereich Datenbankintegration anwendbar sind. Der Fokus der vorliegenden Arbeit wurde auf die Unterstützung eines integrativen und homogenen Zugriffs auf
molekularbiologische Datenquellen und deren möglichst nahtlose Einbettung in Frameworks zur Datenanalyse gelegt. Die Aufgabe besteht somit darin, die Gegebenheiten der
Bioinformatik zu nutzen und mit Techniken der Informatik zur Datenbankintegration
zu kombinieren, um eine in der Praxis anwendbare Lösung zu gewinnen.
Durch den gegebenen Umstand, daß unterschiedlichste Ansätze der Datenmodellierung, -speicherung und -zugriffe existieren, die Datenbanken aber derart zusammenhängen, daß erst mit der ganzheitlichen Betrachtung ein für die biologische Forschung
nutzbarer Kontext entsteht, ist die Bereitstellung von Methoden zur Überwindung der
damit verbundenen Datenverteilung und Heterogenität eine sehr wesentliche Aufgabenstellung. Dies erklärt wiederum die Bedeutung der Datenbankintegration in der
Bioinformatik.
Es werden charakterisierende Merkmale und Besonderheiten von molekularbiologischen Datenbanken ausgearbeitet und etablierte Datenformate sowie Schnittstellen vorgestellt. Eine wesentliche Eigenschaft ist dabei, daß der Zugriff auf die molekularbiologischen Datenbanken starken Beschränkungen auf der Ebene der Anfrage- oder Programmierschnittstelle unterliegt. Aus diesem Umstand heraus werden vom relationalen
Datenmodell und der relationalen Algebra abgeleitete Integrationsoperatoren vorgeschlagen, die zum einen die Anforderungen dieser beschränkten Zugriffsmuster erfüllen
und zum anderen den Ausgangspunkt für Abbildungsregeln von schwach strukturierten Datenformaten molekularbiologischer Datenquellen auf das relationale Datenmodell
bilden. Mit dem so abgeleiteten Datenmodell und den Integrationsoperatoren können
dann komplexe, hierarchische Datenanfragepläne erstellt werden, mit deren Hilfe eine
transparente Zerlegung einer globalen Datenanfrage in Unterabfragen und deren Verteilung auf notwendige Komponentendatenbanken erfolgt.
Das vorgestellte Konzept wurde in Form des Datenbankintegrationssystems BioDa”
taServer“ implementiert. Zur nahtlosen Nutzung durch Standardprogrammiersprachen
und existierende Software wurde eine TCP/IP- sowie eine JDBC/ODBC-Schnittstelle
umgesetzt. Die praktische, projektübergreifende Nutzbarkeit konnte anhand mehrerer
Anwendungen konkret demonstriert werden.
Vorwort und Danksagung
Die vorliegende Arbeit ist während meiner Tätigkeit an der Otto-von-Guericke-Universität Magdeburg und am Institut für Pflanzengenetik und Kulturpflanzenforschung
(IPK) Gatersleben entstanden. Die initiale Idee des Dissertationsthemas entstand während der Arbeit am DFG-Projekt Modellierung und Animation regulatorischer Gen”
wirknetze“ (MARG), das während der ersten Projekthälfte an der Otto-von-GuerickeUniversität Magdeburg in der Arbeitsgruppe Bioinformatik durchgeführt wurde. Nach
der Auflösung der Arbeitsgruppe und der Verlagerung des Projektes an die Universität Bielefeld, entstand die Möglichkeit, die Dissertation am IPK in verschiedenen
Bioinformatikprojekten fortzuführen und so eine direkte Verbindung zu biologischen
Forschungsbereichen aufzubauen. Durch diesen Umstand verstärkte sich der Fokus der
Arbeit auf die Erforschung und Implementierung einer praxistauglichen Datenbankintegrationslösung in der Bioinformatik.
Mein erster Dank gilt insbesondere Prof. Dr. Ralf Hofestädt als Betreuer der Dissertation sowie Prof. Dr. Georg Paul, Dr. habil. Patrick Schweizer und Dr. Uwe Scholz,
die mir durch ihre fördernde und kooperative Projekt- und Arbeitsgruppenleitung den
nötigen Freiraum zur kontinuierlichen Bearbeitung meiner Dissertation gewährten. Ein
besonderer Dank gilt weithin Prof. Dr. Gunter Saake, der als Koreferent die direkte
Betreuung an der Universität Magdeburg übernahm und Dr. Falk Schreiber, der als
Koreferent am IPK die Dissertation begleitete.
Das besonders freundschaftliche und kommunikative Wesen vieler ehemaliger Kollegen verdanke ich die Aufrechterhaltung einer virtuellen, über viele Orte und Projekte
verteilten Arbeitsgruppe, was mir insbesondere als herrvorangende Diskussions und Kooperationsplattform sowie nicht zuletzt als unerbitterlicher Antrieb diente. In diesem
Zusammenhang möchte ich mich bei Dr. Sören Balko, Dr. Andreas Freier, Dr. Jacob
Köhler, Roland Schnee, Dr. Uwe Scholz, Andreas Stephanik und Dr. Thoralf Töpel
bedanken.
Durch die Zusammenarbeit und Diskussion mit Wissenschaftlern des IPK in den
Bereichen Bioinformatik und Molekularbiologie wurden entscheidende Impulse zur Anwendung des in der Arbeit vorgestellten Datenbankintegrationssystems auf bioinformatischen Fragestellungen gegeben. Somit möchte ich mich insbesondere bei Prof. Dr.
Lothar Altschmied, Steffen Flemming, Dr. Ivo Grosse, Vasudev Kumanduri, Christian Künne, Christian Klukas, Dirk Koschützki, Dr. habil. Patrick Schweizer, Dr. Ralf
Sigmund, Dr. Nese Sreenivasulu und Stephan Weise für konstruktive Diskussionen und
Ideen bedanken. In diesem Zusammenhang geht insbesondere mein Dank an Thomas
Münch, Heiko Miehe, Steffen Thorhauer und Fred Kreuzmann für die technische und
organisatorische Unterstützung.
Die Realisierung eines großen Umfanges von Implementierungen wäre ohne die Arbeit
vieler Studenten und Diplomanden nicht möglich gewesen. So gilt mein Dank Lars Kägebein, Matthias Klapperstück, Thomas Krahmer, Stefanie Kreide, Michael Ortmann,
Marco Reinke, Karl Spies und Michael Soffner.
Darüber hinaus möchte ich mich bei der Deutschen Forschungsgemeinschaft (DFG),
beim Bundesministerium für Bildung und Forschung (BMBF), bei der Kurt-Eberhard-
Bode-Stiftung sowie beim Land Sachsen-Anhalt für die Förderung verschiedener Projekte bedanken.
Für das intensive und aufopferungsvolle Korrekturlesen und Kommentieren des Manuskripts gilt mein Dank Dr. Sören Balko, Birgit Lange, Roland Schnee, Dr. Uwe Scholz,
Andreas Stephanik und Dr. Thoralf Töpel. Erst durch diese Arbeit wurden teils unverständliche Absätze und Satzkonstruktionen lesbar und die Tippfehler erheblich reduziert.
Die positive Erfahrung eines herzlichen und freundschaftlichen Arbeitsklimas an der
Universität Magdeburg und am IPK möchte ich an dieser Stelle ganz besonders hervorheben. Somit möchte ich mich bei allen Mitarbeitern des Genomzentrums und des
Instituts für Technische und Betriebliche Informationssysteme für die vielen aufmunternden und persönlichen Gespräche und Gesten bedanken. Herausheben möchte ich
dabei auch die geduldige Einführung in Fragen der praktischen Biotechnologie durch
Bettina Brückner, Susanne König und Ines Walde.
Ein ganz besonderer Dank gilt meinen Eltern und Großeltern, die mir meinen Lebensweg ermöglichten, sowie meinem kleinen Bruder Dirk Lange, dessen Kraft und
Kreativität mir ein Vorbild sind.
Der größte Dank jedoch gebührt meinen drei Jungs, deren Energie, impulsive Lebensfreude und Individualität ein großes Geschenk sind sowie meiner einzigartigen Frau für
ihre Liebe, die Kinder und dafür, daß sie mir meine Ecken und Kanten läßt.
Matthias Lange
Magdeburg, November 2005.
Inhaltsverzeichnis
Abbildungsverzeichnis
vii
Tabellenverzeichnis
ix
Verzeichnis der Abkürzungen
xi
1 Einführung
1
1.1 Einordnung und Problembeschreibung . . . . . . . . . . . . . . . . . .
1
1.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Grundlagen
5
2.1 Molekulare Genetik . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1
DNA als Träger der genetischen Information . . . . . . . . . . .
5
2.1.2
Genexpression . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.3
Proteine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2 Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2.1
Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2.2
Datenmodellierung . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.2.3
Datenformate . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.2.4
Anfragesprachen . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.2.5
Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.3 Verteilte Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.3.1
Multidatenbanksysteme . . . . . . . . . . . . . . . . . . . . . .
28
2.3.2
Homogene Multidatenbanksysteme . . . . . . . . . . . . . . . .
29
2.3.3
Heterogene Multidatenbanksysteme . . . . . . . . . . . . . . . .
30
2.3.4
Integrationskonflikte . . . . . . . . . . . . . . . . . . . . . . . .
38
2.4 Resümee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
i
3 Datenbankintegration in der Bioinformatik
3.1
3.2
3.3
Datenbanken in der Molekularbiologie . . . . . . . . . . . . . . . . . . .
45
3.1.1
Charakterisierende Besonderheiten . . . . . . . . . . . . . . . .
45
3.1.2
Datenformate und Datenzugriff . . . . . . . . . . . . . . . . . .
49
3.1.3
Datenqualität . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
Integration molekularbiologischer Datenbanken . . . . . . . . . . . . . .
61
3.2.1
Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
3.2.2
Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . .
64
3.2.3
Sequence Retrieval System . . . . . . . . . . . . . . . . . . . . .
65
3.2.4
PEDANT/BioRS . . . . . . . . . . . . . . . . . . . . . . . . . .
66
3.2.5
DiscoveryLink . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
3.2.6
BioKleisli/K2 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
3.2.7
Andere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
Resümee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
4 Ansatz zur Integration molekularbiologischer Datenbanken
4.1
4.2
4.3
4.4
4.5
ii
45
75
Relationales Integrationsdatenmodell . . . . . . . . . . . . . . . . . . .
76
4.1.1
Basisdatenmodell . . . . . . . . . . . . . . . . . . . . . . . . . .
76
4.1.2
Schlüssel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
4.1.3
Abbildung auf das Relationenmodell . . . . . . . . . . . . . . .
80
Datenschemata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
4.2.1
Remote Export Schema (RES) . . . . . . . . . . . . . . . . . . .
83
4.2.2
Adapterschema (AS) . . . . . . . . . . . . . . . . . . . . . . . .
84
4.2.3
Integriertes Nutzerschema (IUS) . . . . . . . . . . . . . . . . . .
86
Integrationsoperatoren . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
4.3.1
Basisoperationen . . . . . . . . . . . . . . . . . . . . . . . . . .
89
4.3.2
Datenquellenanfragen . . . . . . . . . . . . . . . . . . . . . . . .
92
4.3.3
Anfragepläne . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
Verarbeitung von Datenfragen . . . . . . . . . . . . . . . . . . . . . . .
98
4.4.1
Abbildung relationaler Datenanfragen auf das IUS . . . . . . . .
99
4.4.2
Komposition von Anfrageplänen . . . . . . . . . . . . . . . . . . 101
4.4.3
Ausführung von Anfrageplänen . . . . . . . . . . . . . . . . . . 103
4.4.4
Relationale Auflösung der Anfrageresultate . . . . . . . . . . . . 109
Resümee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5 Datenbankintegrationssystem BioDataServer (BDS)
113
5.1 Architektur einer nutzerspezifischen Datenbankintegration . . . . . . . 114
5.1.1
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.1.2
Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.2 Mediatorsystem des BioDataServer . . . . . . . . . . . . . . . . . . . . 119
5.2.1
Nutzerspezifischen Datenschemata . . . . . . . . . . . . . . . . . 121
5.2.2
Schnittstelle des BioDataServer . . . . . . . . . . . . . . . . . . 123
5.2.3
TCP/IP-basierte BDS-Kommunikationsprotokoll . . . . . . . . . 126
5.2.4
SQL-Dialekt des BioDataServer . . . . . . . . . . . . . . . . . . 129
5.3 Implementierungsaspekte des Mediators . . . . . . . . . . . . . . . . . 134
5.3.1
JAVA Quellkode . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.3.2
SQL Implementierung des BioDataServer . . . . . . . . . . . . . 136
5.3.3
Implementierung von Verbundoperationen . . . . . . . . . . . . 137
5.3.4
Parallelisierung der Adapteranfragen . . . . . . . . . . . . . . . 138
5.4 Adapter für den BioDataServer . . . . . . . . . . . . . . . . . . . . . . 140
5.4.1
Angewandte Methoden zur Adaptererstellung . . . . . . . . . . 143
5.5 Resümee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6 Anwendungen des Integrationsdienstes
149
6.1 Datenimportwerkzeug Debbie . . . . . . . . . . . . . . . . . . . . . . . 150
6.2 Datenbankbrowser- und Explorationswerkzeug DBOra . . . . . . . . . 151
6.2.1
DBOra-Datenbrowser . . . . . . . . . . . . . . . . . . . . . . . . 153
6.2.2
Berechnung von Data Linkage Graphs . . . . . . . . . . . . . . 154
6.2.3
Funktionsklassifikationen mittels Data Linkage Graphs . . . . . 156
6.3 Anwendung in der Medizinischen Informatik . . . . . . . . . . . . . . . 157
6.4 Integrationsdatenbanken für Genwirknetze (iUDB) . . . . . . . . . . . 160
6.5 Semantische Metadatenbank (SEMEDA) . . . . . . . . . . . . . . . . . 161
6.6 Web-Anwendung zur Analyse von Stoffwechselwegen (phpMetatool) . . 163
6.7 Funktionale Annotationen von Pflanzen-ESTs im CR-EST-Informationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
6.8 Resümee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
7 Zusammenfassung und Ausblick
169
7.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
iii
7.2
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
7.3
Schlußbemerkung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
A Ausgewählte Schnittstellen und Datenformate
175
A.1 EMBL-flat-file Datensatz . . . . . . . . . . . . . . . . . . . . . . . . . . 175
A.2 GenBank-flat-file Datensatz . . . . . . . . . . . . . . . . . . . . . . . . 176
A.3 GenBank-ASN.1 Datensatz . . . . . . . . . . . . . . . . . . . . . . . . . 177
A.4 UniProt DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
A.5 BioPerl Beispiel zum Zugriff auf die GenBank . . . . . . . . . . . . . . 179
A.6 BioPython Beispiel zum Zugriff auf die GenBank . . . . . . . . . . . . 179
A.7 BioJava Beispiel zum Zugriff auf die GenBank . . . . . . . . . . . . . . 179
A.8 CORBA/JAVA Beispiel zum Zugriff auf EMBL . . . . . . . . . . . . . 180
A.9 SOAP/JAVA Beispiel zum Zugriff auf KEGG . . . . . . . . . . . . . . 181
B Ausgewählte Spezifikationen und Implementierungsbeispiele des BDS
183
B.1 BDS JAVA-Klassen für integrierte Nutzerschemata . . . . . . . . . . . 183
B.2 BDS JAVA-Interface für die Adapter . . . . . . . . . . . . . . . . . . . 186
B.3 Beispiel eines IUS-Nutzerschemas . . . . . . . . . . . . . . . . . . . . . 189
B.4 Ausgabe des BDS-Kommunikationsprotokolls zum KEGG-Adapterschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
B.5 Ausgabe des BDS-Kommunikationsprotokolls zum BRENDA-Adapterschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
B.6 Parameterdateien zur Generierung des KEGG-Adapters . . . . . . . . . 199
Literaturverzeichnis
iv
203
Abbildungsverzeichnis
1.1 Zukunft der Informationsverarbeitung in der Biotechnologie aus [3] . .
2
2.1 Anordnung und Verknüpfung der Nukleotide in der DNA-Doppelhelix
aus [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2 Schema der Expression des genetischen Materials bei Eukarioten . . . .
8
2.3 Schema der RNA-Synthese nach [8] . . . . . . . . . . . . . . . . . . . .
8
2.4 Abschnitt der Primärstruktur und eine gefaltete Polypeptidkette des Arginase-Proteins aus der PDB-Datenbank [13] . . . . . . . . . . . . . . .
10
2.5 Graphische Darstellung des Harnstoffzyklus und Metabolismus der Aminogruppen aus [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.6 Software-Architektur eines DBMS aus [15] . . . . . . . . . . . . . . . .
14
2.7 Drei-Ebenen-Schema-Architektur aus [15] . . . . . . . . . . . . . . . . .
16
2.8 Notation für Basiselemente eines E/R-Modells . . . . . . . . . . . . . .
18
2.9 Notation ausgewählter UML-Sprachelemente . . . . . . . . . . . . . . .
21
2.10 Veranschaulichung von Konzepten des Relationenmodells . . . . . . . .
24
2.11 Verteilte Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.12 Taxonomie von Multidatenbanksystemen aus [33] . . . . . . . . . . . .
29
2.13 Architektur eines homogenen Multidatenbanksystems aus [33] . . . . .
30
2.14 Allgemeine Struktur eines Föderierten Datenbanksystems aus [37] . . .
31
2.15 5-Ebenen-Schema-Architektur aus [38] . . . . . . . . . . . . . . . . . .
32
2.16 Schematischer Aufbau einer Mediator-Wrapper-Architektur nach [36] .
34
2.17 Mediatorhierarchie zur Modularisierung und Bündelung der Datenintegration nach [39] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.18 ETL-Prozeß eines Data Warehouses im Überblick aus [44]
35
. . . . . . .
37
2.19 Beispiel einer Partitionierung und Allokation . . . . . . . . . . . . . . .
40
3.1 Datenwachstum ausgewählter molekularbiologischer Datenbanken [59] .
46
v
3.2
Schematische Darstellung der Datenaustauschformatklassen molekularbiologischer Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3
Middleware-Architektur für etablierte Datenbankschnittstellen in der
Bioinformatik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4
49
57
Einordnung der Annotationsfehler für 398 Gene des Chlamydia trachomatis Genoms aus [105]
. . . . . . . . . . . . . . . . . . . . . . . . . .
61
3.5
Szenario der Datenbankintegration in der Bioinformatik aus [123] . . .
64
3.6
Systemarchitektur von BioRS aus [126] . . . . . . . . . . . . . . . . . .
67
3.7
Systemarchitektur von DiscoveryLink aus [127] . . . . . . . . . . . . . .
68
3.8
Systemarchitektur von BioKleisli aus [117] . . . . . . . . . . . . . . . .
70
4.1
3-Ebenen-Schemaarchitektur des Integrationsansatzes . . . . . . . . . .
83
4.2
Schematischer Prozeß von Datenanfragen auf Attributen aus dem IUS .
96
4.3
Graph von Anfrageabhängigkeiten von subgoals . . . . . . . . . . . . .
97
5.1
Schematische Darstellung der Systemarchitektur des BDS aus [136] . . 118
5.2
UML-Komponentendiagramm des BDS . . . . . . . . . . . . . . . . . . 120
5.3
UML-Klassendiagramm der Nutzerschemata . . . . . . . . . . . . . . . 122
5.4
Syntaxdiagramm der IUS-Nutzerschemata . . . . . . . . . . . . . . . . 123
5.5
Screenshot des IUS-Schemaeditors . . . . . . . . . . . . . . . . . . . . . 124
5.6
UML-Zustandsdiagramm der Kommunikationsschnittstelle des BDS . . 125
5.7
UML-Aktivitätsdiagramm der BDS Client-Server-Kommunikation . . . 125
5.8
Syntaxdiagramm der Kommandos des BDS-Kommunikationsprotokolls
5.9
UML-Sequenzdiagramm zur Abfrage des BDS-Serverstatus . . . . . . . 128
126
5.10 UML-Sequenzdiagramm zur Authentifizierung am BDS . . . . . . . . . 128
5.11 UML-Aktivitätsdiagramm einer Datenanfrage . . . . . . . . . . . . . . 129
5.12 Syntaxdiagramm des BDS-SQL-Dialekts aus [143] . . . . . . . . . . . . 131
5.13 Komponenten des JDBC-Frameworks . . . . . . . . . . . . . . . . . . . 133
5.14 Aktivitätsdiagramm einer JDBC-Datenquellenverbindung . . . . . . . . 134
5.15 Binärbaum zu einer Beispiel SQL-Selektionsbedingung . . . . . . . . . 137
5.16 Ausführungsschema von Adapteranfragen . . . . . . . . . . . . . . . . . 139
5.17 UML-Klassendiagramm der Adapter . . . . . . . . . . . . . . . . . . . 141
5.18 UML-Aktivitätsdiagramm einer Adapterdatenanfrage . . . . . . . . . . 143
6.1
vi
Screenshot des Datenbankimportwerkzeugs Debbie . . . . . . . . . . . . 152
6.2 Screenshot des DBOra-Datenbankbrowsers . . . . . . . . . . . . . . . . 153
6.3 Beispiel von Data Linkage Graphs“ aus DBOra . . . . . . . . . . . . . 155
”
6.4 Prozeß der metabolischen Klassifikation von EST-Sequenzen . . . . . . 156
6.5 Systemarchitektur des Genotyp-Phänotyp-Analysesystems aus [147] . . 158
6.6 Screenshots der webbasierten graphischen Nutzerschnittstelle des Genotyp-Phänotyp-Analysesystems aus [147] . . . . . . . . . . . . . . . . . . 160
6.7 Systemkomponenten des iUDB-Systems aus [156] . . . . . . . . . . . . 161
6.8 Screenshot des iUDB-Network-Designers aus [156] . . . . . . . . . . . . 162
6.9 Screenshot der SEMEDA Web-Oberfläche . . . . . . . . . . . . . . . . 164
6.10 Schematische Darstellung der Bedienschritte des phpMetatools aus [158] 165
6.11 Screenshots aus dem Informationssystem CR-EST . . . . . . . . . . . . 166
vii
Tabellenverzeichnis
2.1 Genetischer Code zur Übersetzung der mRNA in Aminosäuren aus [9] .
9
2.2 Datenmodelle und populäre Anfragesprachen . . . . . . . . . . . . . . .
23
2.3 Systemheterogenitäten ausgewählter Beispieldatenbanken . . . . . . . .
39
3.1 Genutzte Methoden für molekularbiologische Datenbanken nach [57] . .
47
3.2 Klassifizierung von Identifikatoren molekularbiologischer Datenbanken .
48
3.3 Klassifizierung von Datenschemata für molekularbiologische Datenbanken 54
3.4 Qualitätsskala für Annotationsreproduzierbarkeit in Datenbanken (TABS) 60
3.5 Klassifizierung von Integrationsansätzen . . . . . . . . . . . . . . . . .
62
5.1 Kommandos der BDS-Kommunikationsschnittstelle . . . . . . . . . . . 127
5.2 Kostenklassifikation der Adapterschemaerstellung . . . . . . . . . . . . 146
ix
Verzeichnis der Abkürzungen
API
AS
ASCII
ASN.1
BDS
BLOB
CAS
CGI
CORBA
CPL
CVS
DB
DBI
DBMS
DCOM
DDB
DDBMS
DDL
DHGP
DLG
DML
DNA
DNS
DTD
DW
DWDB
ER
EST
ETL
FDBS
FTP
GaV
GIF
GUI
HTML
IDL
IIOP
Application Programming Interface
Adapter Schema
American Standard Code for Information Interchange
Abstract Syntax Notation One
BioDataServer
Binary Large Object
Chemical Abstract Service
Common Gateway Interface
Common Object Request Broker Architecture
Collection Programming Language
Concurrent Versions System
Datenbank
Database Independent Interface for Perl
Datenbankmanagementsystem
Distributed Component Object Model
Distributed Databases
Distributed Databases Management System
Data Definition Language
Deutsches Humangenomprojekt
Data Linkage Graph
Data Manipulation Language
Deoxyribonucleic Acid
Desoxyribonukleinsäure
Data Type Definition
Data Warehouse
Data Warehouse Datenbank
Entity/Relationship
Expressed Sequence Tag
Extraktion-Transformation-Laden
Föderiertes Datenbanksystem
File Transfer Protocol
Global-as-View
Graphic Image Format
Graphical User Interface
Hyper Text Markup Language
Interface Definition Language
Internet Inter-ORB Protocol
xi
IP
IUS
JDBC
JDK
JSP
JVM
KDBS
LaV
MDBS
NCBI
NFS
NRC
ODBC
OLAP
OOM
OODBMS
ORDBMS
OQL
OWL
PHP
PS
PL/SQL
RDF
RDBMS
RES
RMI
RNA
RNS
RPC
SGML
SMILE
SOAP
SQL
SSH
UML
URL
WSDL
WML
WWW
XML
xii
Internet Protocol
Integrated User Schema
Java Database Connectivity
Java Development Kit
Java Server Page
JAVA Virtual Machine
Komponentendatenbanksystem
Local-as-View
Multidatenbanksystem
National Center for Biotechnology Information
Network File System
Nested Relational Calculus
Open Database Connectivity
On-Line Analytical Processing
Objektorientierte Modellierung
Objektorientiertes Datenbankmanagementsystem
Objektrelationales Datenbankmanagementsystem
Object Query Language
Web Ontology Language
PHP: Hypertext Preprocessor
Postscript
Procedural Language/Structured Query Language
Resource Description Framework
Relationales Datenbankmanagementsystem
Remote Export Schema
Remote Method Invocation
Ribonucleic Acid
Ribonukleinsäure
Remote Procedure Call
Standard Generalized Markup Language
Simplified Molecular Input Line Entry Specification
Simple Object Access Protocol
Structured Query Language
Secure Shell
Unified Modeling Language
Uniform Ressource Location
Web Service Description Language
Wireless Markup Language
World Wide Web
Extensible Markup Language
Kapitel 1
Einführung
Der Fortschritt in der Molekularbiologie, beginnend bei der experimentellen Datenakquisition zu einzelnen Genen und Proteinen, über die post-genomics“-Technologien,
”
wie etwa DNA-Arrays“ oder Proteomics“, bis hin zur integrativen Bioinformatik mit
”
”
dem Ziel der Erfassung von Gesamtzusammenhängen ganzer biologischer Systeme [1],
bedingt steigende Erfordernisse an die elektronische Datenverarbeitung. Daneben ist die
permanente Entwicklung und Akzeptanz der Internettechnologie essentiell für den Umgang mit diesen genomischen Informationen. Die Entwicklung geht von webbasierten
Systemen zum proprietären Datenzugriff über leistungsfähige Protokolle zum einfachen
und schnellen Datenaustausch bis hin zum verteilten Rechnen und verteilten Datenbanken. Diese Entwicklungen gehen einher mit dem Einsatz von Datenbank-ManagementSystemen (DBMS) zur Verwaltung von immer komplexer werdenden Datenstrukturen
sowie zur Abbildung stark vernetzter Genomics“- und Proteomics“-Daten, sowie de”
”
ren Analyse [2]. Aktuelle Arbeiten zur konsistenten Klassifizierung und eindeutigen
Definition der in den Datenbanken modellierten biologischen Objekte, u. a. mittels Ontologien, verbunden mit Methoden der Wissenverarbeitung, der Informationsextraktion
und des Data Mining“, bilden Schlüsselkonzepte für die zukünftige Biotechnologie und
”
somit auch für die Bioinformatik [3].
1.1 Einordnung und Problembeschreibung
Die vorliegende Arbeit ist dem Bereich der angewandten Informatik zuzuordnen. Dabei
werden Verfahren und Methoden aus dem Bereich der Informationssysteme und Datenbanken identifiziert, die zur Lösung bioinformatischer Fragestellungen aus dem Bereich
Datenbankintegration anwendbar sind. Der Fokus wurde auf die Unterstützung eines
integrativen und homogenen Zugriffs auf molekularbiologische Datenquellen und deren
möglichst nahtlose Einbettung in Frameworks zur Datenanalyse gelegt. Somit werden
bekannte Theorien aus dem Bereich der Informatik mit der Notwendigkeit konfrontiert,
bestehende Techniken der Datenhaltung und des Datenzugriffs nutzen zu müssen. Die
Aufgabe ist es, die Gegebenheiten der Bioinformatik zu nutzen, diese mit Techniken der
Informatik zur Datenbankintegration zu kombinieren, um eine in der Praxis einsetzbare
Lösung zu gewinnen.
Wie eingangs angedeutet, nehmen Datenbanken eine zentrale Rolle in der Biologie bzw. Molekularbiologie ein und sind Basis vieler Analysen mittels Methoden aus
1
Kapitel 1 Einführung
Abbildung 1.1: Zukunft der Informationsverarbeitung in der Biotechnologie aus [3]
der Bioinformatik. Durch den gegebenen Umstand, daß unterschiedlichste Ansätze der
Datenmodellierung, -speicherung und Datenanfragen existieren, die Datenbanken aber
derart zusammenhängen, daß erst mit der ganzheitlichen Betrachtung ein für biologische Forschungen nutzbarer Kontext ensteht, ist die Bereitstellung von Methoden
zur Überwindung der damit verbundenen Datenverteilung und Heterogenität eine sehr
wesentliche Aufgabenstellung. Dies erklärt wiederum die Bedeutung der Datenbankintegration in der Bioinformatik. Denn ohne geeignete computerunterstützte Methoden
kann das volle Potential des in Form von Daten erfaßten Wissens der biologischen
Grundlagenforschung nur durch immer größer werdenden zeitlichen Aufwand genutzt
werden. Es sollte prinzipiell dem Trend entgegen gewirkt werden, daß Wissenschaftler
einen nicht unwesentlichen Teil ihrer Zeit mit Aufgaben der manuellen Datenakquisition, Bereinigung, Konvertierung und Integration verbringen [4].
So werden gerade das Internet und Web-Services“ als primäre Medien für die elektro”
nische Veröffentlichung von Forschungsergebnissen genutzt [5]. Insbesondere die massive
Bereitstellung von Daten zu molekularbiologischen Forschungsergebnissen und die damit zu beobachtende, teils anarchische Vorgehensweise bezüglich der benutzten Technologien, Datenstrukturen und Zugriffsschnittstellen stellt eine besondere Herausforderung für die Informatik dar. Das Potential der im Web vorhandenen Daten muß
durch Methoden zur Wissensableitung genutzt werden. Ein wesentlicher Teil ist dabei
2
1.2 Aufbau der Arbeit
die Überwindung der Datenverteilung und der damit verbundenen Heterogenität, um
ganzheitliche Betrachtungen der Daten durchführen zu können.
Es werden in dieser Arbeit bekannte Theorien und Konzepte der Informatik auf die
Bioinformatik angewandt. Dabei besteht nicht der Anspruch, neue theoretische Ansätze
zur Datenbankintegration zu finden. Vielmehr wird ein anwendbares Softwaresystem
entwickelt und vorgestellt, das einige Kernprobleme der heterogenen Datenhaltung in
der Bioinformatik zu lösen versucht.
1.2 Aufbau der Arbeit
Nach diesen einleitenden Ausführungen werden im Kapitel 2 Grundlagen aus den Bereichen Molekularbiologie, Datenbanken sowie verteilter Datenbanken gelegt. Zum Verständnis der Besonderheiten molekularbiologischer Daten und deren notwendigen Abhängigkeiten untereinander werden, ausgehend vom Begriff des Gens, die Prozesse der
Translation und Transkription eingeführt, um auf die Rolle von Proteinen als ein wesentlicher Bestandteil komplexer biologischer Systeme, wie etwa dem Stoffwechsel, einzugehen.
Das Hauptaugenmerk wird im Grundlagenkapitel auf die Einführung von Begriffen
und Theorien aus dem Bereich der Datenbanken und der verteilten Datenbanken gelegt.
Dabei werden grundlegende Eigenschaften von Datenbanksystemen, Fragen der Datenmodellierung und -formate sowie Anfragesprachen und Schnittstellen soweit aufgearbeitet und vorgestellt, als daß sie als Grundlage und Vergleich für die in den folgenden
Kapiteln vorgestellten Lösungen maßgeblich sind. Die Ausarbeitungen zum Thema der
verteilten Datenbanken stellen zum einen Anforderungen und Probleme einer Datenbankintegration als auch eine Auswahl bekannter Architekturen vor, insofern diese auf
die erarbeiteten Lösungsstrategien der vorliegenden Arbeit Einfluß haben.
Im Kapitel 3 werden charakterisierende Merkmale und Besonderheiten von molekularbiologischen Datenbanken ausgearbeitet und etablierte Datenformate sowie Schnittstellen vorgestellt. Für die folgenden Kapitel wird hier empirisch die Begründung für
die notwendige Annahme gegeben, daß der Zugriff auf molekularbiologische Datenquellen beschränkten Zugriffsmustern unterliegt und gezeigt, um welche es sich handelt.
Weiterhin werden Ausführungen zu Aspekten der bewertbaren Datenqualität gemacht.
Anschließend erfolgt eine Vorstellung existierender Architekturen und im praktischen
Einsatz befindlicher Systeme zur Datenbankintegration in der Molekularbiologie.
Mit dem Kapitel 4 wird eine theoretische Lösung einer Datenbankintegration für
einen nur lesenden Zugriff auf molekularbiologische Datenquellen erarbeitet. Hierzu
werden vom relationalen Datenmodell und der relationalen Algebra abgeleitete Integrationsoperatoren vorgeschlagen, die zum einen die Anforderungen beschränkter Zugriffsmuster erfüllen und zum anderen den Ausgangspunkt für Abbildungsregeln von
schwach strukturierten Datenformaten molekularbiologischer Datenquellen auf das relationale Datenmodell bilden. Aus den eingeführten Integrationsoperatoren können dann
komplexe, hierarchische Datenanfragepläne erstellt werden, mit deren Hilfe eine transparente Zerlegung einer globalen Datenanfrage in Unterabfragen und deren Verteilung
3
Kapitel 1 Einführung
auf notwendige Komponentendatenbanken erfolgt. Die notwendigen Eigenschaften dieser Anfragepläne, Regeln zur Evaluierung von sogenannten Anfrageabhängigkeiten sowie deren Auflösung werden im Anschluß erläutert. Mit der Spezifikation von Regeln zur
Erstellung von integrierten, globalen Datenschemata wird dieses Kapitel abgeschlossen.
Auf Basis des Kapitels 4 wird im Kapitel 5 eine Client-Server-Softwarearchitektur entworfen, die zur Implementierung der zuvor vorgestellten Konzepte genutzt wird. Es folgt
die Erläuterung der konkreten, in Form des BioDataServers vorgenommenen Implementierung des Integrationssystems. Dazu werden die Implementierung des Integrationsalgorithmus zur Ausführung von statischen Anfrageplänen sowie die semiautomatische
Erstellung von Datenbankadaptern zur Umsetzung der Integrationsoperationen auf der
Ebene des Zugriffs auf die Komponentendatenbanken vorgestellt. Weiterhin wird auf
die im BioDataServer umgesetzte Cache-Strategie zum redundanzarmen Datenzugriff
eingegangen. Zur Nutzung des BioDataServers werden die entworfenen Zugriffsschnittstellen, die Spezifikation des implementierten “read only SQL Dialektes für Anfragen
”
eines integrierten Datenbestandes sowie die Möglichkeiten der entfernten Administration beschrieben.
Verschiedene Anwendungen des vorgestellten Datenbankintegrationsdienstes werden
im Kapitel 6 vorgestellt. Dabei stehen die direkte Nutzung von Datenabfragen über
integrierte molekularbiologische Datenbanken, die Anwendung des BioDataServers als
Datenimportwerkzeug für Data Warehouse Lösungen, die Einbindung in Analyse- und
Simulationsframeworks zu Fragestellungen im Zusammenhang mit biologischen Netzwerken sowie die Anwendung im Kontext einer semantischen Datenbankintegration im
Mittelpunkt.
Die Arbeit endet mit dem Kapitel 7, das die Ergebnisse der vorliegenden Arbeit zusammenfaßt und offene Fragestellungen überblicksartig diskutiert sowie einen Ausblick
auf weiterführende Untersuchungen gibt. Zu jedem der Inhaltskapitel 2 bis 6 wurde zur
Unterstützung der Gesamtlesbarkeit der Arbeit ein kurzes Resümee als Zusammenfassung des jeweiligen Kapitels angefügt.
Im abschließenden Anhang sind Beispiele zu Schnittstellen und Datenformaten zu
Kapitel 3 gegeben. Weiterhin sind hier, neben Beispielen zu Datenschemata und Adaptergrammatiken, Auflistungen von Spezifikationen zu den Kapiteln 4 und 5 zu finden.
4
Kapitel 2
Grundlagen
In diesem Kapitel sollen für das Verständnis der Arbeit grundlegende Erkenntnisse,
Techniken, Begriffe und Fragestellungen der Biologie, der Bioinformatik und der Informatik eingeführt werden. Da die vorliegende Arbeit interdisziplinär ausgerichtet ist,
d. h. die Informatik zur Lösung molekularbiologischer Fragestellungen genutzt wird, ist
dieses Kapitel dreigeteilt. Dabei liegt der Fokus auf der Informatik, insbesondere auf
dem Teilgebiet Informationssysteme und Datenbanken.
Im Abschnitt Molekulare Genetik werden Grundlagen aus dem Bereich der Molekularbiologie soweit eingeführt, wie sie für das Verständnis der Besonderheiten und Probleme
der Datenhaltung und -auswertung in diesem Wissenschaftsbereich wesentlich sind. Im
Abschnitt Datenbanken werden grundlegende Konzepte der Datenbanktheorie und etablierte Techniken erläutert, um im letzten Teil des Kapitels auf Aspekte der Verteilten
Datenbanken einzugehen.
2.1 Molekulare Genetik
Die Biologie und deren verwandte Teildisziplinen, wie etwa die Genetik1 , sind komplexe Wissenschaften. Diese Komplexität zeigt sich schon allein am Umfang biologischer
Prozesse, welche in den verschiedenen Organismen stattfinden. Dabei zeigen sich mikroskopische Regelkreise, die in ihrer Summe den Phänotyp, also Verhalten, Funktionen, Aussehen etc. eines Lebewesens bestimmen. Die Molekulargenetik oder auch die
Molekularbiologie befassen sich hierbei mit der Erforschung der biophysikalischen und
biochemischen Mechanismen von Lebewesen. Ein für diese Arbeit relevanter Überblick
über den aktuellen Forschungsstand der Molekularbiologie wird in diesem Abschnitt
soweit gegeben, wie dies für das weitere Verständnis der Arbeit notwendig erscheint.
Die folgenden Ausführungen stützen sich dabei auf die Lehrbücher [6, 7, 8, 9].
2.1.1 DNA als Träger der genetischen Information
Ausgangspunkt ist die Erkenntnis, daß die biologischen Vorgänge in einem Lebewesen ursprünglich von dessen Genen gesteuert bzw. bestimmt werden. Die Theorie einer
physischen Grundeinheit, dem Gen, das ein bestimmtes Merkmal eines Organismus bestimmt, existiert seit dem 19. Jahrhundert. Ab den 50er Jahren des 20. Jahrhunderts
1
Im ursprünglichen Sinne handelt es sich hier um die Vererbungslehre.
5
Kapitel 2 Grundlagen
war bekannt, daß die Desoxyribonukleinsäure (DNS/DNA)2 das eigentliche genetische
Material ist. Wie in Abbildung 2.1 veranschaulicht, existieren hierbei zwei, in Form einer Doppelhelix umeinander gewundene Polynukleotide [10]. Dabei handelt es sich bei
jedem Strang um eine Verkettung von genau vier biologischen Molekülen, die aufgrund
ihrer Phosphatgruppen zusammengehalten werden. Das sind die Nukleotide Adenin,
Thymin, Guanin und Cytosin. Aufgrund der chemischen Beschaffenheit der Basen dieser Moleküle können exakt zwei dieser Nukleotide, die sich über eine schwache Wasserstoffbrückenbindung verbinden können, ein Paar bilden. Auf diese Weise bilden Adenin
und Thymin sowie Guanin und Cytosin ein Basenpaar (abgekürzt bp). Die Folge ist,
daß sich zu einem DNA-Strang nur ein komplementärer Strang anlagern kann und so
die erwähnte Doppelhelix entsteht. Die Gesamtmenge der DNA eines Organismus bildet das Genom, welches somit alle genetischen Informationen eines jeden Lebewesens
kodiert.
Wird die dreidimensionale Struktur der DNA vernachlässigt, so genügt es, die DNA
durch einen Nukleotidstrang darzustellen. Abstrakt kann die DNA als Sequenz von vier
Buchstaben und deren Komplement dargestellt werden, die sich aus den Anfangsbuchstaben der erwähnten Nukleotide ergeben:
DNA-Strang:
DNA-Komplement:
AAGCTG
TTCGAC
Hierbei handelt es sich um eine schematische Schreibweise der Primärstruktur der DNA.
Ein Gen ist ein spezieller Abschnitt der DNA, der zwischen 75 bis 2.300.000 bp umfassen kann [7]. Die Nukleotidsequenz ist ein entscheidenes Merkmal eines Gens. Die
Anzahl der Gene in einem Organismus ist sehr unterschiedlich. So existieren bei der
Fruchtfliege ca. 13.000 Gene [11] und beim Menschen 25.000 bis 120.000 Gene [12].
Dabei ist aber die Anzahl der Gene kein Maß für die Komplexität eines Organismus.
Neben den genetischen Informationen bilden eine Vielzahl regulativer Mechanismen
ein komplexes Netzwerk, welches das Erscheinungsbild und die Funktionen in einem
Organismus bestimmt.
Außer der DNA existiert in den Zellen eines Organismus eine zweite Form von Polynukleotidketten, die Ribonukleinsäure (RNS/RNA)3 , welche den Hauptteil der Nukleinsäuren in den Zellen stellt. Ein wichtiges Unterscheidungsmerkmal zur DNA ist der
Austausch der Base Thymin durch Uracil (abgekürzt durch U), deren komplementäre
Base aber ebenfalls Adenin ist. Folglich kann ein RNA-Stück der Kopie eines komplementären DNA-Stückes entsprechen:
DNA-Strang:
RNA-Komplement:
AAGCTG
UUCGAC
Die meist als Einzelstränge vorliegenden RNA-Stücke (DNA-Kopien) nehmen bei der
Proteinsynthese (Translation) bestimmte Aufgaben wahr (siehe Abschnitt 2.1.2). In
2
Das korrekte deutsche Akronym ist DNS. In den folgenden Ausführungen wird auch die gebräuchliche, englische Abkürzung DNA (deoxyribonucleic acid) benutzt.
3
Ähnlich der DNA lautet das korrekte deutsche Akronym RNS. Es wird aber auch hier die englische
Abkürzung RNA (ribonucleic acid) benutzt.
6
2.1 Molekulare Genetik
Abbildung 2.1: Anordnung und Verknüpfung der Nukleotide in der DNA-Doppelhelix
aus [6]
diesem Zusammenhang werden nach ihren Aufgaben kategorisierte RNA-Arten in der
Zelle unterschieden.
2.1.2 Genexpression
Der als Genexpression bekannte Prozeß, der die Ausprägung der genetischen Information zu den Merkmalen beschreibt, so wie er durch Abbildung 2.2 illustriert wird, beginnt
mit der Herstellung einer RNA-Kopie eines Genabschnitts. Bei diesem als Transkription
bezeichneten Prozeß bindet sich ein Molekül eines speziellen Proteins, die RNA-Polymerase, an eine bestimmte DNA-Sequenz, den Promoter, der am Anfang eines Gens
steht. Dabei werden die beiden Stränge der DNA aufgewunden und die RNA-Polymerase bewegt sich auf der kodierenden Sequenz des Gens entlang. Die gelesene DNASequenz wird so zu einem komplementären mRNA-Strang synthetisiert (T durch U
ersetzt). Besondere Nukleotidsequenzen am Ende eines Gens signalisieren den Abbruch
7
mRNA
tRNA
Enzymprotein
Strukturprotein
Regulatorprotein
Rezeptorprotein
...
Merkmal
rRNA
Translation
DNA
Transkription
Kapitel 2 Grundlagen
Abbildung 2.2: Schema der Expression des genetischen Materials bei Eukarioten
der Transkription und sorgen für die Freisetzung der fertigen RNA und der anschließenden Neubildung der DNA-Doppelhelix. Abbildung 2.3 illustriert diesen Prozeß. Dabei
wachsender RNA− Strang
RNA− Polymerase
Syntheserichtung
neugebildete
DNA− Doppelhelix
originale
DNA− Doppelhelix
Bewegungsrichtung der RNA− Polymerase
Abbildung 2.3: Schema der RNA-Synthese nach [8]
spielen synthetische Teilstücke dieser RNA, die sogenannten Expressed Sequence Tags“
”
(ESTs), bei der Expressionsanalyse und funktionalen Annotation von Genen in der experimentellen Molekularbiologie eine wichtige Rolle, da über deren Konzentration in
der Zelle indirekt Rückschlüsse auf die Genaktivität möglich sind.
Bevor diese Transkriptionsprodukte ihre Funktionen für den nächsten Schritt der
Genexpression wahrnehmen können, müssen sie noch erhebliche molekulare Veränderungen durchlaufen, die sogenannte posttranskriptionale Prozessierung.
Die anschließenden, als Translation bezeichneten, Vorgänge setzen die Informationen
der mRNA in Aminosäuren um, von denen 22 verschiedene in Lebewesen vorkommen,
davon 20 im Menschen. Die Übersetzung der mRNA in Aminosäuren basiert auf Kodierungseinheiten. Genau drei Nukleotide bilden hierbei sogenannte Codons, die also 64
verschiedene Möglichkeiten der Nukleotidanordnung ermöglichen. Da direkte Abhängigkeiten zwischen Codons und den bei der Translation synthetisierten Aminosäuren
nachgewiesen wurden, kann eine Regel, der genetische Code, zur direkten Abbildung
8
2.1 Molekulare Genetik
1. Position
U
C
A
G
U
Phe (F)
Phe (F)
Leu (L)
Leu (L)
Leu (L)
Leu (L)
Leu (L)
Leu (L)
Ile (I)
Ile (I)
Ile (I)
Met (M)/Start
Val (V)
Val (V)
Val (V)
Val (V)
2. Position
C
A
Ser (S) Tyr (Y)
Ser (S) Tyr (Y)
Ser (S)
Stop
Ser (S)
Stop
Pro (P) His (H)
Pro (P) His (H)
Pro (P) Gln (Q)
Pro (P) Gln (Q)
Thr (T) Asn (N)
Thr (T) Asn (N)
Thr (T) Lys (K)
Thr (T) Lys (K)
Ala (A) Asp (D)
Ala (A) Asp (D)
Ala (A) Glu (E)
Ala (A) Glu (E)
G
Cys (C)
Cys (C)
Trp (W)/Stop
Trp (W)
Arg (R)
Arg (R)
Arg (R)
Arg (R)
Ser (S)
Ser (S)
Arg (R)
Arg (R)
Gly (G)
Gly (G)
Gly (G)
Gly (G)
3. Position
U
C
A
G
U
C
A
G
U
C
A
G
U
C
A
G
Tabelle 2.1: Genetischer Code zur Übersetzung der mRNA in Aminosäuren aus [9]
von Codons auf Aminosäuren4 mit der Tabelle 2.1 angegeben werden. Bis auf wenige
Ausnahmen gilt dieser Code universell für alle Lebewesen. Die Aminosäuren werden als
dreibuchstabige Abkürzung oder als einbuchstabiges Symbol wiedergegeben, das entsprechend in Klammern steht. Dabei kommt einigen Codons eine Sonderfunktion zu.
Sie bestimmen den Start- bzw. den Endpunkt des Ablesevorgangs der mRNA und sind
deshalb entsprechend bezeichnet. Um die Informationen der Codons in Aminosäuren
umzusetzen, binden die mit Aminosäuren beladenen tRNAs, beginnend am Startcodon,
an die mRNA Codons. Dies ist möglich, da die tRNA mit entsprechenden Anticodons
ausgestattet ist, bei denen es sich um Komplemente der Codons handelt. So können
die an der tRNA gebundenen Aminosäuren zu einer Sequenz geordnet werden, bis ein
Stopcodon erkannt wird.
2.1.3 Proteine
Die grundlegenden Funktionen und Eigenschaften eines Organismus werden durch Proteine bestimmt. Wie bei der DNA besteht ein Protein aus einer oder mehreren Molekülketten, den sogenannten Polypeptide. Der Grundbaustein sind hierbei Aminosäuren.
Die Abfolge der Aminosäuren und die räumliche Form der Polypeptide eines Proteins
4
In der zugrundeliegenden Quelle werden nur 20 Aminosäuren beachtet. Die Zeitschrift Science berichtete aber, daß im Mai 2002 die bisher unbekannte 22. Aminosäure Pyrrolysin entdeckt wurde.
Die 21. Aminosäure Selenocystein wurde bereits im Jahr 1986 entdeckt.
9
Kapitel 2 Grundlagen
bestimmen dessen biologische Funktion. Nach groben Schätzungen enthält z. B. der
menschliche Organismus 50.000 verschiedene Proteine [9], die häufig als Familien vorkommen aber sehr spezialisierte Funktionen besitzen. Abbildung 2.4 zeigt einen Ausschnitt der räumlichen Struktur und der Aminosäuresequenz eines Proteins.
gefaltetes Polypeptid
Aminosäuresequenz
mkpisiigvp mdlgqtrrgv dmgpsamrya gvierlerlh ydiedlgdip
igkaerlheq gdsrlrnlka vaeaneklaa avdqvvqrgr fplvlggdhs
iaigtlagva khyerlgviw ydahgdvnta etspsgnihg mplaaslgfg
hpaltqiggy spkikpehvv ligvrsldeg ekkfirekgi kiytmhevdr
lgmtrvmeet iaylkertdg vhlsldldgl dpsdapgvgt pviggltyre
shlamemlae aqiitsaefv evnpildern ktasvavalm gslfgeklm
Abbildung 2.4: Abschnitt der Primärstruktur und eine gefaltete Polypeptidkette des
Arginase-Proteins aus der PDB-Datenbank [13]
Zu den Aufgaben von Proteinen gehören Syntheseaktivitäten, wie sie z. B. für die
Bildung von DNA, RNA oder der Katalyse von biochemischen Reaktionen in den Zellen
notwendig sind. Diese speziellen Proteine werden als Enzyme bezeichnet. Auch diese
Syntheseaktivitäten werden wiederum durch Proteine reguliert. Proteine sorgen dafür,
daß Signale von Zelle zu Zelle übermittelt werden, transportieren schlecht wasserlösliche Stoffe, wie z. B. Sauerstoff, und leiten Ionen durch Zellmembranen. Außerdem
bilden Proteine viele Strukturbausteine, die Form und Beweglichkeit der Zellen und
Organismen bestimmen.
Zu den grundlegenden Vorgängen in einem Organismus, von denen dessen Erscheinungsbild und Funktion abhängen, gehören die biologischen Stoffwechselwege (engl.
Pathways). Hierbei werden drei Klassen unterschieden: (1) metabolische und biochemi-
10
2.1 Molekulare Genetik
sche, (2) Transkription, Genregulation, Proteinsynthese und (3) Signalwege. Alle drei
Arten haben eine Gemeinsamkeit: sie beschreiben funktionale Beziehungen zwischen
Molekülen. So beschreibt die 1. Klasse die Gesamtheit aller chemischen Umsetzungen
basierend auf komplexen biochemischen Reaktionen. Die beteiligten Stoffe werden als
Substrate bezeichnet. Bei enzymatisch katalysierten Reaktionen spielen eine Vielzahl
von Einflüssen eine Rolle, auf die in dieser Arbeit nicht weiter eingegangen wird. So
läßt sich die Enzymaktivität eines Enzyms (E) vereinfacht durch die Menge von Ausgangsstoffen (A) und Reaktionsprodukten (P) beschreiben. Es ist zu beachten, daß
eine Reaktion durchaus reversibel ablaufen kann, was durch die Richtung der Pfeile
symbolisiert wird:
E : A1 + ... + An ⇌ P1 + ... + Pm
So läßt sich zum Beispiel die vom Enzym Arginase (siehe Abbildung 2.4) katalysierte
biochemische Reaktion wie folgt schreiben:
EArginase : L − Arginine + H2 O ⇌ L − Ornithine + Urea
Diese biochemischen Reaktionen bilden einen wichtigen Bestandteil des biologischen
Gesamtsystems eines Organismus, den Stoffwechsel. In Abbildung 2.5 ist ein Stoffwechselweg dargestellt, der einem Teil des Gesamtstoffwechsels entspricht. Der Stoffwechsel
ist ein offenes, räumlich kompartimentiertes System komplexer chemischer Prozesse,
das ein Gleichgewicht zwischen den zu- und abfließenden Stoffen bildet.
Mit dieser Einführung in den Stoffwechsel und den weiteren, im vorliegenden Kapitel beschriebenen Begriffen und Erkenntnissen aus dem Bereich der Molekularbiologie
wurde die Grundlage für das Verständnis der folgenden Kapitel gelegt. Dabei ist hier
keinesfalls eine erschöpfende Ausarbeitung vorgenommen worden, da einige ebenso interessante aber für die vorliegende Arbeit nicht maßgebliche Aspekte, wie etwa die
Genregulation oder die Zellbiologie, nicht eingeführt wurden. Der Fokus liegt vielmehr
auf dem Aufbau eines Kontextes zu den folgenden Ausarbeitungen der spezifischen
Eigenschaften der Datenverwaltung und -integration in besonderer Beachtung der Biologie als Anwendung der Informatik. Für weitergehende Informationen zu dem Bereich
der Molekularbiologie wird auf die eingangs diesen Kapitels aufgeführte Literatur verwiesen.
11
Kapitel 2 Grundlagen
Abbildung 2.5: Graphische Darstellung des Harnstoffzyklus und Metabolismus der
Aminogruppen aus [14]
12
2.2 Datenbanken
2.2 Datenbanken
Bei der systematischen Erfassung von Forschungsergebnissen der Molekularbiologie
stellt die Nutzung von Datenbanken eine essentielle Komponente dar. Das stetig steigende Volumen von Daten erfordert entsprechende Methoden zur dauerhaften Speicherung
derselben. So umfaßt z. B. allein das Genom des Menschen etwa 3 ∗ 109 Basenpaare.
Würde hierbei jedes Nukleotid relativ großzügig durch ein Byte codiert, so müßten für
die Speicherung der vollständigen DNA-Primärstruktur des Menschen ca. 2,8 GByte
aufgebracht werden. Betrachtet man in Relation dazu die komplexen Strukturen und
Vorgänge in der Menge aller Organismen, so bekommt man einen Eindruck von dem
gesamten Datenaufkommen, das verwaltet werden muß. Daneben spielt die systematische und vor allem effiziente Verarbeitung gerade dieser Daten eine weitere wesentliche
Rolle. Es ist somit für eine praktikable Erforschung der molekularbiologischen Zusammenhänge unerläßlich, moderne Computertechnik und Informatikmethoden zu nutzen,
was die Teildisziplin Bioinformatik kennzeichnet.
Aus diesem Grund wird in diesem Abschnitt ein Überblick über die sich aktuell
bietenden Möglichkeiten und Techniken der Informatik, insbesondere der Datenbanksysteme gegeben. Darüber hinaus wird gezeigt, welche Datenbankmethoden zur Zeit
in der Bioinformatik Anwendung finden und diese anhand ausgewählter Datenbanken
und Informationssysteme erläutert.
2.2.1 Datenbanksysteme
Der Begriff Datenbank wird nicht nur in der Informatik vielfältig genutzt und meint im
allgemeinen eine Sammlung von zueinander in Beziehung stehender Daten [15]. Dabei
werden Daten in der gleichen Literaturquelle als im Rechner speicherbare Fakten mit
implizierter Bedeutung definiert. Daneben existieren restriktivere Definitionen, etwa
in [16]. Hierbei wird eine Datenbank als Sammlung von Daten definiert, die durch
ein Datenbank-Management-System (DBMS)5 verwaltet werden. In der vorliegenden
Arbeit wird das Wort Datenbank im Sinne von [15] benutzt. Dies macht vor allem in
Bezug auf die evolutionär gewachsenen molekularbiologischen Datenbestände Sinn, die
oftmals keineswegs Eigenschaften eines DBMS besitzen.
In der Praxis sollte davon ausgegangen werden, daß eine Datenbank weitere Eigenschaften besitzt, die sie von einfachen Datensammlungen“ unterscheidet. Die Daten
”
haben einen festen Bezug zu einem bestimmten Anwendungsszenario, sie stehen untereinander in bestimmten Beziehungen und werden hinsichtlich bekannter oder angenommener Anwendungs- bzw. Nutzeranforderungen bereitgestellt. Da der Zweck von
Datenbanken das Anlegen, die Pflege, die Verarbeitung und der Zugriff auf Daten ist,
wird somit eine Sammlung von Software notwendig, die das unterstützt und als Datenbank-Management-System bezeichnet wird.
Ein DBMS ist eine komplexe Software zur homogenen Verwaltung von Datenbanken.
Definitionen wie etwa in [15] bezeichnen ein DBMS als ein Mehrzweck-Softwaresystem,
5
An dieser Stelle wird aus Gründen der gebräuchlichen Terminologie auf eine Übersetzung in die
deutsche Sprache verzichtet.
13
Kapitel 2 Grundlagen
welches die Prozesse der Definition, Konstruktion und Manipulation von Datenbanken
für verschiedene Applikationen unterstützt. Einschränkendere Definitionen, so wie in
[16] bestimmt, fordern weiterhin, daß diese zu verwaltenden Datenbanken6 sowohl groß
als auch gemeinsam nutzbar sind, sowie deren Schutz und Zuverlässigkeit gewährleistet
werden. Der grundsätzliche Aufbau eines DBMS ist in Abbildung 2.6 illustriert.
Abbildung 2.6: Software-Architektur eines DBMS aus [15]
In [17] wurden neun allgemeine Anforderungen an ein DBMS formuliert, die zur
Definition des notwendigen Funktionsumfangs eines DBMS dienen. Diese sind:
1. Integration
Einheitliche Verwaltung aller benötigten Daten
2. Operationen
Bereitstellung von Operationen zum Einfügen, Ändern und Aufsuchen von Daten
3. Katalog
Zugriff auf Datenbeschreibungen
4. Benutzersichten
Funktionalität zur anwendungsspezifischen Bereitstellung von Datensichten
5. Konsistenzüberwachung
Gewährleistung der Korrektheit des Datenbankinhaltes und von Änderungsoperationen
6
Im englischen Text wird verallgemeinernd der Begriff Datensammlung benutzt.
14
2.2 Datenbanken
6. Datenschutz
Verhinderung eines unauthorisierten Datenzugriffs
7. Transaktionen
Zusammenfassung von Änderungsoperationen zu konsistent ausgeführten Einheiten
8. Synchronisation
Koordinierung konkurrierender Transaktionen
9. Datensicherung
Verhinderung von Datenverlusten nach Systemfehlern
Diese grundlegenden Eigenschaften eines DBMS sollten in einer konkreten Implementierung eines DBMS umgesetzt werden. Mittels Abstraktionen von der Gesamtfunktionalität zu Teilproblemen können entsprechend Teil-Architekturen entworfen werden,
durch die spezielle Aspekte des o. g. Anforderungskataloges modelliert werden und letztlich die Vorlage für Implementierungen bilden. Zwei Kernaspekte eines DBMS stellen
sicherlich die Konzepte der Datenschemata und Datenunabhängigkeit dar. Da insbesondere die Datenunabhängigkeit in der vorliegenden Arbeit von weiterer Bedeutung sein
wird, werden diese Prinzipien im folgenden anhand der Drei-Ebenen-Schemaarchitektur
eingeführt.
Drei-Ebenen-Schemaarchitektur
Das Ziel der Drei-Ebenen-Schemaarchitektur in Abbildung 2.7 ist es, die Datenbankanwendung des Nutzers von der physikalischen Datenbank, wie etwa eine Datei auf der
Festplatte eines Computers, zu trennen. In dieser Architektur werden drei Ebenen von
Schemata unterschieden:
1. Die interne Ebene beinhaltet das interne Schema und beschreibt die kompletten
Details der physischen Speicherung der Daten. Dazu zählen insbesondere Informationen, wie Dateistrukturen, Blockgrößen, Dateizugriffspfade und andere teils
betriebssystemabhängige Parameter.
2. Das konzeptuelle Schema dieser Ebene beschreibt in einem implementierungsunabhängigen Modell (siehe hierzu auch Abschnitt 2.2.2) die gesamte Datenbank.
Aspekte wie etwa Entitäten7 als Abbildung eines Realweltobjektes, Datentypen,
Beziehungen oder Konsistenzbedingungen sind so spezifizierbar.
3. Die externe Ebene enthält eine Anzahl von Nutzersichten auf die konzeptuelle
Ebene, die Sichten auf den Datenbestand festlegen. Dabei spielen anwendungsspezifische Erfordernisse eine Rolle, um etwa (Teil-)Entitäten zu verstecken oder
logisch neu zusammenzustellen. Das hier verwendete Modell muß dabei nicht dem
der 2. Ebene entsprechen.
7
Der Begriff Entität wird im Abschnitt 2.2.2 erläutert.
15
Kapitel 2 Grundlagen
Abbildung 2.7: Drei-Ebenen-Schema-Architektur aus [15]
Somit sind die Vorteile dieser Architektur, daß Anwendungen unabhängig von der physischen Speicherung der Daten implementiert werden können (physische Datenunabhängigkeit), was bestehende Anwendungen robust gegenüber Änderungen auf dieser
Ebene, wie z. B. Änderungen von Dateistruktur oder -format, der Veränderung von
Dateizugriffspfaden etc. macht. Positiv wirkt sich natürlich auch die somit hohe Abstraktionsstufe des Datenzugriffs aus, was sich u. a. in Portabilität, Wartbarkeit und
nicht zuletzt in Zeitersparnis bei der Implementierung von robusten Anwendungen bemerkbar macht.
Daneben wird die logische Datenunabhängigkeit gewährleistet, die Anwendungen unanfällig gegen Änderungen im konzeptionellen Schema macht. Das kann z. B. das Entfernen oder das Hinfügen von Attributen oder Konsistenzbedingungen einer Entität
sein, was dann gegebenenfalls Anpassungen am externen Schema notwendig macht.
Die Anwendung kann davon unberührt weiterarbeiten.
Um diese Architektur in eine konkreten Implementierung umzusetzen, sind Transformationen zwischen den drei Ebenen notwendig, um Datenoperationen von Anwendungen zu ermöglichen. Da diese sehr zeitintensiv sein können, wird bei einigen DBMS
mitunter auf die externe Ebene zugunsten der Geschwindigkeit verzichtet.
2.2.2 Datenmodellierung
In der vorliegenden Arbeit liegt in einigen Abschnitten der Schwerpunkt der Betrachtungen auf der Erfassung und Modellierung von Datenstrukturen, Abhängigkeiten etc.
Aus diesem Grund wird in diesem Abschnitt ein Exkurs in den Bereich der Datenmodellierung vorgenommen. Dies soll dem Leser eine Grundlage für die weiteren Kapitel
geben.
16
2.2 Datenbanken
Beim Entwurf eines Modells ist es eine sehr wichtige Aufgabe, eine geeignet abstrakte
Beschreibung der abzubildenden Wirklichkeit derart zu finden, daß nur die notwendigen
Fakten zur Beantwortung bekannter oder unbekannter Fragestellungen an das Modell
abgebildet werden. Dieser Anspruch ist sicherlich nicht zu erreichen, da zum Zeitpunkt
der Modellerstellung keine Aussagen über alle möglichen Fragestellungen an das Modell
möglich sind. Also werden mögliche Fragestellungen aufgrund zu erarbeitender Anforderungskataloge künstlich eingeschränkt. Bei der anschließenden Modellierung ist ein
geeignetes Optimum zwischen einem zu einfachen Modell, das nicht alle Fragestellungen
ermöglicht, und einem unnötig komplexen Modell zu finden.
Die Nutzung von Datenbanken zur strukturierten Speicherung von Daten geschieht
in der Regel mit einem bestimmten Ziel: der idealisierten Abbildung bzw. Erfassung
eines interessierenden Ausschnittes der Wirklichkeit (Diskursbereich, Universum) zur
Unterstützung von Wissensfindungen und Vorhersage bestimmter Eigenschaften. Dies
führt direkt zum Begriff des Modells. In [18] werden dazu verschiedene Arten von Modellen und deren Eigenschaften im Überblick genannt, die auch in der vorliegenden
Arbeit genutzt werden sollen.
Bei der Erstellung eines konzeptionellen Datenschemas eines Diskursbereiches sollte
darauf geachtet werden, daß jegliche Implementierungsaspekte und Aspekte der Aufbereitung für den Nutzer vollständig verborgen sind. Weiterhin müssen alle erlaubten
Zustände einer dem Modell entsprechenden Datenbank vorherbestimmt sein und jeder
gültige Zustand einem sinnvollen und möglichen Zustand des Diskursbereiches entsprechen. Somit ist zu folgern, daß die Datenmodellierung eine wesentliche Aufgabe ist, die
in der Praxis oftmals nicht hinreichend genug beachtet wird. Dies spiegelt sich mitunter in Inkonsistenzen der Daten oder einer nicht wiedergegebenen Umsetzbarkeit von
Fragestellungen des Diskursbereiches wider.
Ein semantisches Datenmodell [19] dient der Beschreibung eines konzeptionellen Modells in einer speziellen Sprache (Notation), die idealerweise kein Informatikwissen voraussetzt, aber auch mächtig genug ist, Aspekte des Diskursbereiches möglichst unmittelbar zu beschreiben. Dazu sind Wahrnehmungen aus dem Diskursbereich und
Beziehungen zwischen solchen Wahrnehmungen zu erfassen. Weitergehende Konzepte berücksichtigen auch dynamische und temporale Aspekte, was hier aber nicht weiter
betrachtet werden soll.
Im folgenden werden einige populäre Sprachen zur Datenmodellierung, die auch in
den nächsten Kapiteln genutzt werden, kurz beschrieben. Es kann hier nicht der volle
Umfang, insbesondere die Notationselemente und Sprachkonstrukte dargestellt werden.
Im Falle von UML werden einige Grundkonstrukte dieser Sprache eingeführt, da dies
die für die vorliegende Arbeit benutzte Modellierungssprache ist. Die Wahl fiel auf
UML, da sich während der Recherche zeigte, daß dies eine in der Bioinformatik weit
verbreitete Modellierungssprache ist, die zunehmend genutzt wird. Dies begründet sich
auch in dem Umstand, daß mit UML nicht nur Datenmodelle sondern auch andere
Arten von Modellen, wie etwa Prozessmodelle, entworfen werden können.
17
Kapitel 2 Grundlagen
Entity/Relationship-Modell
Das Entity/Relationship-Modell (E/R-Modell) [18] ist ein weit verbreitetes semantisches Datenmodell. Die Grundkonstrukte sind die Entitäten, die Attribute und die
Beziehungen.
1. Entitätstyp
Das Grundkonstrukt bei den E/R-Modellen ist die Entität, was einem Realweltkonzept entspricht, das in einer Datenbank abzubilden ist. Der Entitätstyp ist
dabei eine Abstraktion einzelner Entitäten.
2. Attributtyp
Eigenschaften von Entitäten werden durch Attribute näher beschrieben. Es können
pro Entität ein oder mehrere Attribute genutzt werden. Dabei können Attribute zu Attributtypen gruppiert werden, wie etwa rot“, gelb“, grün“ zu einem
”
”
”
Farbattribut.
3. Beziehungstyp
Da Entitäten im allgemeinen nicht voneinander isoliert sind, werden Beziehungen
zur Modellierung bereitgestellt. Auch hier wird ein abstrakter Typ, der Beziehungstyp, genutzt, um Beziehungen zu einer Aggregatbeziehung zu gruppieren,
wie etwa ist Blatt von“ oder ist Zellteil“. Einschränkungen der möglichen Enti”
”
täten, die an einer Beziehung teilnehmen, werden über Kardinalitäten vorgenommen.
Hierzu ist anzumerken, daß strikt zwischen den realen Ausprägungen (Instanzen, Exemplare) und den abstrakten Typen der genannten Konstrukte unterschieden wird. D. h.,
eine Entität ist z. B. eine Ausprägung eines Entitätstypes. Dies gilt analog für Attribute
und Beziehungen. In der Abbildung 2.8 ist die Notation für die genannten Basiskonzepte dargestellt. Es existieren zu diesen Basiskonzepten Erweiterungen, die zusätzliche
Modellierungskonstrukte unterstützen, wie etwa das erweiterte E/R-Modell.
Abbildung 2.8: Notation für Basiselemente eines E/R-Modells
18
2.2 Datenbanken
Unified Modeling Language
Bei der Unified Modeling Language (UML) [20] handelt es sich um eine universal einsetzbare Modellierungssprache und Notation, mit deren Hilfe sowohl statische Datenstrukturen als auch dynamische Abläufe beschrieben werden können. Dabei berücksichtigt UML die ganzheitliche Erfassung vieler Aspekte der Softwareentwicklung. Aus
dieser Motivation heraus wird die objektorientierte Modellierung (OOM) als Basis für
UML genutzt. Als Vorteile gegenüber der strukturierten Modellierung werden in [20]
folgende Argumente aufgeführt:
1. Ganzheitliche Arbeitsgegenstände
Verschmelzung von Daten und Operationen
2. Bessere Abstraktionsmöglichkeiten
Verschiebung der Modellierung vom Lösungs- zum Problembereich
3. Methodische Durchgängigkeit
alle Phasen der Softwareentwicklung arbeiten mit den selben Konzepten
4. Evolutionäre Entwicklung
Unterstützung einer evolutionären Entwicklung zur Weiterentwicklung und Verbesserung der Modelle
Dieser Argumentation folgend, wird auch in der vorliegenden Arbeit UML zur Modellierung eingesetzt. Zur Erhöhung der Lesbarkeit der folgenden Kapitel wird eine
überblicksartige Auflistung der wesentlichen Konstrukte von UML gegeben. Dabei wird
vorausgesetzt, daß der Leser mit den Ideen, die der OOM zugrunde liegen, vertraut ist.
Weitergehende Details können der angegebenen Literatur entnommen werden.
Ergebnisse einer UML-Modellierung sind Diagramme. Dabei werden in der vorliegenden Arbeit drei Diagrammtypen bzw. ausgewählte Subdiagramme genutzt. Diese
Auswahl aus den mit UML darstellbaren Diagrammen wird im folgenden kurz vorgestellt:
1. Klassendiagramm
Mittels folgender Konstrukte wird eine informale Definition der Semantik für eine
Menge von Objekten gegeben.
• Klassen
• Attribute
• Operationen
Analog zu Entitäten des E/R-Modells sind Objekte im System konkrete Ausprägungen (Instanzen, Exemplare) eines Entitätstypes, hier: einer Klasse. Attribute
sind (Daten-) Elemente, die gewisse Eigenschaftstypen von Klassen beschreiben.
Diese aus E/R-Modellen bekannten Konzepte werden durch Operationen erweitert.
19
Kapitel 2 Grundlagen
Klassen stehen untereinander in verschiedenen Beziehungen. Dabei werden nachfolgende Arten unterschieden:
• Generalisierung, Spezialisierung (Vererbung, Konkretisierung)
• Assoziation, Aggregation, Komposition (Objektverbindung, Abhängigkeiten)
2. Verhaltensdiagramm
Dient der Darstellung von dynamischen Modellsachverhalten; es werden folgende
Subdiagramme unterschieden:
a) Aktivitätsdiagramm
Darstellung von Aktivitäten, Objektzuständen, Zuständen, Zustandsübergängen und Ereignissen
b) Sequenzdiagramm
Beschreibt Objekte und ihre Beziehungen inklusive ihres zeitlich geordneten
Nachrichtenaustausches
c) Zustandsdiagramme
Darstellung von Zuständen, Zustandsübergängen und Ereignissen
3. Implementierungsdiagramm
Dient der Beschreibung der Implementierungsstruktur eines Softwareprojektes
a) Komponentendiagramm
Beschreibung der Beziehungen zwischen physischen Teilen eines Programmcodes
b) Verteilungsdiagramm
Darstellung der Topologie von auf Knoten verteilter Komponenten
Der hier gegebene Überblick zu UML und die in Abbildung 2.9 dargestellten Notationselemente sollen als Glossar dienen, um das Verständnis der in der vorliegenden Arbeit
entworfenen UML-Diagramme zu unterstützen.
Die Kombination von E/R-Modell und UML in den folgenden Kapiteln erfolgt u. a.
aus der Notwendigkeit, verschiedene Modellarten (relational, objektorientiert) beschreiben zu müssen. Dabei wurden die verschiedenen Vorteile, die das jeweilige Model bietet,
mit evolutionär und aus der Anwendungspraxis in der Bioinformatik entstandenen Gegebenheiten in Beziehung gesetzt. So wird bei der Datenschemamodellierung vorrangig
das E/R-Model eingesetzt. Wogegen für die Darstellung von Implementierungs- und
Verhaltensdiagrammen UML eingesetzt wird.
2.2.3 Datenformate
Die zuvor eingeführten Konzepte aus dem Gebiet der Datenmodellierung sind in dem
Sinne abstrakt, als daß hier noch keine implementierte Ausprägung des modellierten
20
2.2 Datenbanken
Abbildung 2.9: Notation ausgewählter UML-Sprachelemente
Sachverhaltes existiert. Vielmehr müssen die modellierten Datenschemata in eine durch
Computerprogramme verarbeitbare Form überführt werden. Die konkrete Anwendung
hierzu ist die Entwicklung von Strukturen zur persistenten Speicherung von Daten zu
einem konkreten Datenschema auf Sekundärspeichern, wie etwa auf Festplatten. Da in
der Praxis meist die Funktionalität eines Betriebssystems zum Zugriff und zur Verwaltung der Sekundärmedien genutzt wird, beziehen sich die genannten Speicherstrukturen
auf Dateien in einem Dateisystem. Somit kann folgende Definition gegeben werden:
Definition 2.1 (Datenformat) Ein Datenformat ist eine wohldefinierte Struktur zur
persistenten Speicherung von Daten in ein oder mehreren Dateien bzw. Dateiverbünden mit
dem Ziel der automatischen Verarbeitbarkeit durch ein Computerprogramm. Ferner sollte
sich ein Datenformat auf ein vorhandenes Datenschema beziehen, wobei alle modellierten
Konzepte durch die aufsetzenden Computerprogramme umsetzbar sein müssen.
2
21
Kapitel 2 Grundlagen
Der zweite Teil von Definition 2.1 ist absichtlich optional gelassen, da diese Forderung
nicht immer umgesetzt wird. Im Falle eines Direktzugriffes auf diese Dateien ohne die
Nutzung einer Middleware, wie etwa eines DBMS (siehe Abbildung 2.6), ist es notwendig, das Dateiformat zu kennen. Hierbei muß es möglich sein, ein Datenschema aus
dem jeweiligen Datenformat abzuleiten, was wiederum die Voraussetzung ist, damit
die in den Dateien abgelegten Daten von Anwendern und Softwareentwicklern verwendet werden können. Diesen Prozeß bezeichnet man als Reengineering. Der Grad der
Strukturierung des zugrundeliegenden Datenformates spielt dabei eine entscheidende
Rolle. In [21] werden dazu mehrere Klassen von Strukturierungskonzepten unterschieden. Die in folgender Aufzählung ausgewählten Konzepte treten in der Praxis durchaus
kombiniert oder hierarchisch geschachtelt auf:
1. Block
Hier werden logisch zusammenhängende Daten durch eindeutige Begrenzer (z. B.
Klammern oder Zeilenumbrüche) zusammengefaßt.
2. Liste
Dieses Konstrukt bildet ähnlich den Blöcken zusammenhängende Bereiche in einer Datei. Charakteristisch ist, daß die so separierten Bereiche als semantisch
gleichartig angesehen werden und so einem Attributtyp zugeordnet werden können.
3. Name-Wert-Paare
Ein weitverbreitetes Konstrukt zur starken Strukturierung sind Name-Wert-Paare. Hierbei werden Attributwerte (Daten) zu vorangestellten Attributnamen (Metadaten) zugeordnet.
4. Binäre Datensätze
Bei dieser Art der Strukturierung werden über einen sehr festen Bezug zur konkreten Implementierung Daten abgespeichert, so daß der Zugriff auf die einzelnen
Datensätze auf festen Positionsangaben in der Datei beruht. Dieses Format ist im
allgemeinen wenig für ein Reengineering geeignet.
5. Textuelle Datensätze
Im Gegensatz zu binären Datensätzen werden hier alle Variablentypen als ASCIIText gespeichert. Zum Unterscheiden der einzelnen Datensätze werden in der
Regel spezielle Trennzeichen eingesetzt.
6. Hypertexte und strukturierte Texte
Hier werden semantische Markups durch spezielle Schlüsselworte vorgenommen.
Dabei werden teilweise verschachtelte Blockstrukturen und Listen genutzt.
7. Schwache Strukturierung
Zahlreiche konkrete Formate kapseln wohlstrukturierte Daten in Freitext, was zu
einer Koexistenz von strukturierten und unstrukturierten Bestandteilen führt.
22
2.2 Datenbanken
Aus obiger Aufstellung sind in der Bioinformatik für den gezielten Datenaustausch vor
allem textuelle Datensätze als Listen von Name-Wert-Paare anzutreffen. Aber auch
der Einsatz von XML als eine Klasse der Hypertexte wird immer populärer. Im Gegensatz dazu sind die Ausgabeformate resultierend von direkten Datenanfragen über
eine Middleware oftmals der Klasse der schwach strukturierten Hypertexte zuzuordnen.
Weitergehende Ausführungen zu konkreten Datenformaten in der Bioinformatik sind
in Abschnitt 3.1.2 zu finden.
2.2.4 Anfragesprachen
Eine Grundforderung, um Daten gezielt nutzbar zu machen, ist die Bereitstellung
von Anfragemechanismen. Ähnlich den Anforderungen an die konzeptuelle Ebene der
DBMS-Architektur in Abschnitt 2.2.1 besteht hier die Forderung nach einer Abstraktion
vom Datenformat. Datenanfragen sollen also unabhängig vom genutzten physikalischen
Dateiformat sein und es ermöglichen, Daten nach zu spezifizierenden Kriterien zu extrahieren bzw. Operationen auf der Datenbank durchzuführen. Diese Forderung nach
Unterstützung von Datenbankoperationen wird durch Anfragesprachen umgesetzt. Diese basieren auf einem Datenmodell und leiten daraus ihre Ausdrucksstärke ab. Darüber
hinaus können zwei Typen von Anfragesprachen unterschieden werden: prozedurale und
deklarative. Im ersten Fall ist es notwendig, durch Schachtelung oder sequentielle Programmierung von Datenbankoperationen eine Anfrage umzusetzen. Im zweiten Fall ist
es ausreichend, die Resultatstruktur und die zu erfüllenden Eigenschaften zu definieren.
Das heißt, es wird spezifiziert, was“ abzufragen ist und nicht wie“. In diesem Kontext
”
”
wird eine Klassifizierung zu den in der Bioinformatik üblichen Datenmodellen und den
populärsten Anfragesprachen in Tabelle 2.2 gegeben. Ohne einen vollständigen ÜberDatenmodell
kein
hierarchisch
relational
objektrelational
objektorientiert
Anfragesprache
proprietär programmiert
XQL[22], XML-QL[23]
SQL[24]
SQL99[25]
OQL[26]
Typ
prozedural
deklarativ
deklarativ, prozedural
deklarativ, prozedural
deklarativ, prozedural
Tabelle 2.2: Datenmodelle und populäre Anfragesprachen
blick zu den einzelnen Anfragesprachen und der zugrundeliegenden formalen Semantik
geben zu wollen, werden nachfolgend kurz ausgewählte Beispiele von Anfragesprachen
vorgestellt.
Die Klasse der proprietären Anfragesprachen setzt sich im wesentlichen aus einfachen,
über Logikoperatoren verknüpfte Selektionsanfragen zusammen. Diese werden dann
auf indizierte Attribute A aus flachen Dateien, die in Form von Name-Wert-Paaren
strukturiert sind (siehe Abschnitt 2.2.3) oder unstrukturierten Textdateien abgesetzt:
σa=c | a ∈ A ∧ c ∈ Menge von jeweils zulässigen Textbausteinen
23
Kapitel 2 Grundlagen
Die Selektionsanfragen können boolsche Ausdrücke formen, wobei in der Regel die Operatoren ¬, ∧, ∨ unterstützt werden. Das heißt verallgemeinert, die Unterstützung einer
Teilmenge der Relationenalgebra mit eingeschränkten Selektions- und Projektionsprädikaten. Solche Anfragen richten sich nach keiner Standardsyntax, sondern werden häufig
mittels HTML-Formularen erfaßt und an die Datenbanken übermittelt (vergleiche hierzu auch Abschnitt 3.1). Ein Beispiel wäre etwa die Selektion aller Proteindaten zu den
Organismen Gerste oder Kartoffel:
σOrganism=’Barley’ ∨ σOrganism=’Potatoe’
In der Klasse der relationalen Anfragesprachen spielt sicherlich SQL die bedeutendste
Rolle und soll deshalb hier kurz eingeführt werden. SQL basiert auf dem relationalen
bzw. Tupelkalkül und somit auch auf der relationalen Algebra und auf dem relationalen
Datenmodell [27], das die Nutzung von tabellarischen Strukturen zur Datenverwaltung
formalisiert. Hier werden Entitäten der zu modellierenden Datenbankstruktur durch
Relationenschemata (Tabellen) beschrieben, die aus einer Menge von Attributen (Spalten) bestehen. Diesen werden Wertebereiche, sogenannte Domänen, zugeordnet. Eine
Relation ist nun eine Teilmenge des kartesischen Produktes über den Wertebereich aller Attribute eines Relationenschemas. Ein Element einer Relation heißt Tupel und
entspricht einer Tabellenzeile. Abbildung 2.10 soll dies veranschaulichen. Die Idee des
Abbildung 2.10: Veranschaulichung von Konzepten des Relationenmodells
relationalen Kalküls ist die Nutzung von tupelwertigen Variablen t, die jeweils an eine
Relation r gebunden sind. Dabei können die Komponenten der Tupel einzeln referenziert, d. h. mittels der Notation t.A benannt werden. Die Tupelbindung (rn ) an Relationen und für Tupelvariablen zu erfüllende Tupelbedingungen (ti ) werden in CON D
angegeben.
{t1 .A1 , . . . , tn .An | CON D(r1 (t1 ), . . . , rn (tn ), c1 , . . . ci )}
Bei der Spezifikation von mehreren Tupelbindungen in CON D wird das kartesische Produkt gebildet, das dann natürlich über entsprechende Tupelbedingungen eingeschränkt
werden kann. Die Tupelbedingungen sind dabei der Form:
c = ti .A op tj .B | op ∈ {=, >, ≥, <, ≤, 6=}
c = ti .A op k | k ist eine Konstante ∧ op ∈ {=, >, ≥, <, ≤, 6=}
24
2.2 Datenbanken
Diese können über die logischen Operationen ∧, ∨, ¬ miteinander zu boolschen Ausdrücken verbunden werden. Weitergehende Konstrukte, wie etwa Quantoren, werden
hier nicht weiter betrachtet.
Ein Beispielausdruck im relationalen Kalkül wäre z. B., alle Gennamen und Proteinnamen für alle Proteine zu ermittelt, die für einen bestimmten Organismus bekannt
sind:
r = {t.genname, t.proteinname | P rotein(t) ∧ t.organism = ’Barley’}
Die Anfragesprache SQL basiert auf dem relationalen Kalkül und stellt entsprechende
syntaktische Konstrukte zur Verfügung. Die allgemeine Struktur einer SQL-Anfrage ist:
select t1 .A1 , . . . , tn .An from t1 , . . . , tn where c1 . . . ci
Auf das obige Beispiel angewandt, lautet die entsprechende SQL-Anweisung:
select t.genname, t.proteinname from Protein as t
where t.organism = ’Barley’
Der Sprachumfang von SQL beschränkt sich aber nicht auf Datenanfragemöglichkeiten. Darüber hinaus existieren die Data Definition Language“ (DDL) und die Data
”
”
Manipulating Language“ (DML). Diese sind zur Manipulation und Definition von Relationenschemata bzw. für Datenänderungsoperationen auf Tupelebene einzusetzen.
2.2.5 Schnittstellen
Datenzugriffschnittstellen sind zur Kopplung zwischen Anwendungen und der Datenhaltungskomponente notwendig. Eine weitere Forderung an einen Datenzugriff besteht
also darin, daß die bereitgestellte Anfragesprache durch Programmiersprachen direkt
nutzbar ist. Es muß ein sogenanntes Application Programming Interface (API) bereitgestellt werden. Diese basieren auf den zugrundeliegenden Datenmodellen. Folgende Liste
bildet einen Auszug aus bekannten Kommunikationsschnittstellen zur Koppelung von
Anwendungen und Datenbanken.
• Lokaler Dateizugriff
Die wohl einfachste Technik um auf Daten zuzugreifen, ist die direkte Nutzung
von Dateien im lokalen Dateisystem eines Rechners. Hierzu zählen auch Netzwerkdateisysteme, wie etwa NFS, oder der Dateizugriff mittels Dateitransferprotokollen wie FTP oder RPC. Der Datenzugriff erfolgt durch das Parsen der gesamten
Dateien. Dabei ist das Datenformat bekannt, und so können Datenelemente extrahiert und in Datenstrukturen überführt werden. Hierzu existieren verschiedene,
vorgefertigte Parser, die durch APIs genutzt werden können, wie sie in Abschnitt
3.1.2 beschrieben sind.
• Remote Procedure Call (RPC)
Eine weitere Möglichkeit des Datenzugriffs ist der Aufruf von entfernten Methoden. Darüber hinaus bieten die nachfolgend aufgezählten Standards und Techniken erweiterte Funktionalitäten. Dies reicht von einfachen Methodenaufrufen bis
25
Kapitel 2 Grundlagen
hin zu verteilten Objektnetzwerken, Web-Services, Events- und Persistenzframeworks. Eine wesentliche Eigenschaft ist hier, daß eine Programmiersprachenunabhängigkeit besteht. Nachfolgend wird eine Auswahl der gängigsten Techniken
gegeben:
– CGI
– SOAP/XML-RPC [28]
– DCOM [29]
– .NET
– CORBA [30]
• DBMS-Anfrage-APIs
Natürlich handelt es sich bei DCOM, .NET und CORBA um Frameworks zur
Unterstützung der Arbeit mit verteilten Objekten. Die Reduzierung auf RPC
begründet sich in der praktischen Anwendung dieser Techniken im Kontext der
vorliegenden Arbeit. Im Kapitel 3 sind hierzu weitere Ausarbeitungen zu finden.
Die Nutzung von DBMS-Funktionalität zum entfernten Datenzugriff wird durch
eine Kombination aus Datenanfragesprache und APIs unterstützt. Zum einen
kann das durch die Einbettung von speziellen Datenbankzugriffsbefehlen in die
Programmiersprache oder zum anderen durch die Integration von Datenanfragesprache und Funktionsaufrufen in Form von APIs realisiert werden. Zu beobachten
ist hier eine direkte Bindung an eine Programmiersprache (Perl-DBI, PHP Datenbank-API). Auch sind DBMS-spezifische APIs nicht unüblich. Daneben existieren
vom DBMS abstrahierende Architekturen, wie etwa JDBC [31] oder ODBC [32].
26
2.3 Verteilte Datenbanken
2.3 Verteilte Datenbanken
Ein sehr interessanter Aspekt bei der Datenhaltung ist, neben dem zentralistischen Ansatz von DBMS aus Abschnitt 2.2.1, der der Verteilten Datenbanken. Da die vorliegende
Arbeit sich in den weiteren Kapiteln intensiv mit diesem Fakt aus der speziellen Sicht
der Bioinformatik befassen wird, wird hier eine allgemeine Problemspezifikation von
verteilter Datenhaltung gegeben.
Das Datenaufkommen in den verschiedenen Bereichen der Industrie, Verwaltung und
Wissenschaft wird durch unterschiedliche Techniken der Datenhaltung organisiert. Die
Vorstellung eines großen, zentralen DBMS, das von den verschiedensten Datenbankanwendungen, wie z. B. Datenbeschreibungs-, Manipulations- oder Anfragesprachen
genutzt wird, zeigt sich in der Bioinformatik als kaum realisierbar.
Vielmehr ist solch eine zentrale Instanz eines DBMS oftmals in kleinere, spezialisierte Komponenten-DBMS aufgeteilt. Eine derartige Verteilung der Daten, wie sie in
Abbildung 2.11 dargestellt wird, kann verschiedene Gründe haben. Das Datenvolumen,
administrative Aspekte, Optimierungsgesichtspunkte oder Sicherheitskriterien können
dabei eine Rolle spielen. Neben diesen technischen Aspekten, bei denen Lösungsstrategien denkbar sind, ist es auch bislang noch nicht umfänglich gelungen, ein einheitliches,
allgemein anerkanntes Datenschema für zumindest Teildisziplinen der Molekularbiologie zu schaffen, das letztendlich in einer zentralen Datenbank umgesetzt wird. Das hat
u. a. mit nationalen Förderungen der datenproduzierenden Forschungsprojekte oder
auch mit fehlender Koordinierung auf internationaler Ebene zu tun. Aber auch kommerzielle Interessen spielen zunehmend bei der absichtlich“ hervorgerufenen Daten”
bankheterogenität und -verteilung eine Rolle .
Literatur−
daten
Sequenz−
daten
Phänotyp−
daten
Expressions−
daten
Protein−
daten
Abbildung 2.11: Verteilte Datenhaltung
27
Kapitel 2 Grundlagen
Die so entstandene dezentrale Datenhaltung hat aber auch diverse Nachteile. So werden die Daten oft redundant gehalten, es existiert keine einheitliche Zugriffsschnittstelle
und die Struktur und das Datenschema zwischen den Datenbanken ist oft sehr divergent. Eine globale Zugriffsschnittstelle für die verteilten Datenbanken ist schon allein
aus diesen Gründen wünschenswert. Zu diesem Zweck wurden die Multidatenbanksysteme (MDBS) konzipiert. In diesem Kapitel wird eine Übersicht zu den verschiedenen
Architekturen und den Problemen von MDBS gegeben. Die folgenden Ausführungen
stützen sich dabei im wesentlichen auf [33, 34, 35].
2.3.1 Multidatenbanksysteme
Der Begriff Multidatenbanksystem (MDBS) kann als Oberbegriff für die Software zur
Organisation verteilter Datenbanken betrachtet werden. In [33] werden distributed databases (DDB) und distributed database management system (DDBMS) verwendet. Dabei
werden diese folgendermaßen definiert:
Definition 2.2 (DDB) Eine verteilte Datenbank kann als eine logisch integrierte Kollektion von gemeinsamen Daten definiert werden, die physikalisch über die Knoten eines
Computernetzwerkes verteilt sind.
2
Definition 2.3 (DDBMS) Ein verteiltes Datenbankmanagementsystem ist die Software, die nötig ist, um eine verteilte Datenbank derart zu verwalten, daß die Aspekte der
Verteilung transparent vor dem Nutzer sind.
2
In obigen Aussagen sind schon die grundsätzlichen Voraussetzungen enthalten, die ein
Multidatenbanksystem erfüllen muß, um als solches bezeichnet zu werden:
• die Daten sollten logisch zusammenhängen
• die Daten sind physikalisch in einem Netzwerk verteilt
• die Datenverteilung ist gegenüber den Anwendungen nicht sichtbar
Die an einem Multidatenbanksystem beteiligten Datenbanken werden dabei als lokale
Datenbanken oder auch als Komponentendatenbanken bezeichnet. Das Multidatenbanksystem an sich wird als globale Datenbank bezeichnet.
Es wurde schon an anderer Stelle erwähnt, daß verschiedene Architekturen für Multidatenbanksysteme existieren. Diese unterscheiden sich in der Realisierung der Verteilung und sind in zwei Klassen einzuteilen:
• homogen verteilte Daten
• heterogen verteilte Daten
28
2.3 Verteilte Datenbanken
In homogenen MDBS sind die lokalen Datenbanken in einem globalen Gesamtschema
eingeordnet, d. h. sie gehören logisch zusammen und sind physikalisch fragmentiert.
Dabei können mehrere Arten der Fragmentierung unterschieden werden. In diesem Fall
hat ein DDBMS die Aufgabe, diese Fragmentierung bei Datenzugriffen zu verbergen
und die Daten wieder geeignet zusammenzufügen. Einige weitere Ausführungen hierzu
werden im Abschnitt 2.3.2 gemacht.
Im Gegensatz dazu existiert bei heterogenen DDBMS kein globales Gesamtschema,
es muß explizit generiert werden. Die lokalen Datenbanken existieren unabhängig voneinander, und die Autonomie darf vom Multidatenbanksystem nicht angetastet werden.
Im Abschnitt 2.3.3 werden die damit verbundenen Probleme näher betrachtet.
Diese grobe Unterteilung läßt sich weiter verfeinern. In Abbildung 2.12 wird dazu
eine Übersicht zur Taxonomie der Multidatenbanksysteme gegeben, wie es in [33] vorgeschlagen wird. Auf die Charakteristika dieser Unterarten soll in dieser Arbeit nicht
Multidatenbanksysteme
homogen
autonom
heterogen
nicht−autonom
Integration mittles
DDBMS
komplette DBMS−Funktionalität
Integration mittels
Gateways
teilweise DBMS−Funktionalität
föderierte Systeme
lose Kopplung
nicht−föderierte Systeme
enge Kopplung
einzeln
mehrfach
Abbildung 2.12: Taxonomie von Multidatenbanksystemen aus [33]
weiter eingegangen werden.
2.3.2 Homogene Multidatenbanksysteme
Ein homogenes Multidatenbanksystem ist stark mit einem zentralen Datenbanksystem
verwandt. Der Unterschied besteht in dem physischen Speicherort, an dem die Daten
gespeichert werden. Wie der Name schon andeutet, geschieht dies bei einem zentralen
29
Kapitel 2 Grundlagen
DBMS an einer zentralen Stelle. Dagegen sind die Daten eines homogenen Multidatenbanksystems über verschiedene Rechner eines Netzwerkes verteilt gespeichert. Die
Eigenschaft homogen besagt, daß die Kontrolle der verschiedenen lokalen Datenbanken
allein dem MDBS obliegt. Der Zugriff erfolgt ebenso ausschließlich durch das MDBS.
Alle zugrundeliegenden lokalen Datenbeschreibungen werden aus diesem Grund in einem globalen Datenschema vereinigt. Es ist keine notwendige Voraussetzung lokaler
Datenbanken, daß ein DBMS oder ein explizites Schema lokal existiert. Auch diese
Punkte können vom MDBS übernommen werden. In Abbildung 2.13 ist die allgemeine
Architektur eines homogenen MDBS dargestellt.
Abbildung 2.13: Architektur eines homogenen Multidatenbanksystems aus [33]
2.3.3 Heterogene Multidatenbanksysteme
Die Klasse der heterogenen MDBS zeichnet sich im wesentlichen dadurch aus, daß
die beteiligten Komponentendatenbanksysteme (KDBS) zwar kooperieren, jedoch für
sich autonom sind. Die wohl wichtigste Eigenschaft solcher MDBS ist, daß neben der
globalen Nutzung der KDBS über ein MDBS auch der lokale Zugriff möglich ist. Dabei
darf aber die Autonomie der KDBS vom Multidatenbanksystem nicht verletzt werden.
Eine Unterart der heterogenen MDBS sind die Föderierten Datenbanksysteme (FDBS)
[34] sowie Datenbankmediatoren [36].
Im folgenden wird eine Einführung in die Problematik der Datenbankföderierung,
der Datenbankmediatoren und der Data Warehouses gegeben, da diese für das Szenario
eines molekularbiologischen Informationssystems von grundlegender Bedeutung sind.
30
2.3 Verteilte Datenbanken
Anwendungsbezogene Datenintegrationstechniken, wie etwa Frameworks zur Applikationsintegration bzw. Methodenintegration oder komponentenbasierte Frameworks
sollen an dieser Stelle nicht unerwähnt bleiben, werden aber ausschließlich im Kontext
des homogenen Datenzugriffs im Abschnitt 3.1.2 erwähnt. Darauf aufbauende Techniken, wie etwa Portale oder Workflowsysteme, spielen zwar in der Bioinformatik eine
wesentliche Rolle, haben aber zur Thematik der vorliegenden Arbeit einen nur indirekten Bezug.
Datenbankföderierung
In Abbildung 2.14 ist die grobe Struktur eines Föderierten Datenbanksystems dargestellt. Bei der Konzeption einer föderierten Datenbankstruktur und des FöderierungsGlobale
Anwendungen
Globale
Anwendungen
Föderierungsdienst
Lokale
Anwendungen
DBMS 1
...
DBMS n
DB 1
DB n
KomponentenDBS 1
KomponentenDBS n
Lokale
Anwendungen
Föderiertes Datenbanksystem
Abbildung 2.14: Allgemeine Struktur eines Föderierten Datenbanksystems aus [37]
dienstes stellen sich zuerst folgende Fragen:
• Wie werden Anfragen globaler Anwendungen auf die einzelnen Komponentensysteme aufgeteilt, von diesen bearbeitet, und wie werden die lokalen Anfrageergebnisse wieder zusammengesetzt?
• Dürfen globale Anwendungen Daten der an der Föderation beteiligten Komponentendatenbanksysteme ändern?
Entstehen dabei nicht Konflikte mit den lokalen Anwendungen?
Wie werden solche Konflikte vermieden oder aufgelöst?
• Welche Aufgaben hat der sogenannte Föderierungsdienst?
Darf er die Arbeit der Komponentendatenbanksysteme beeinflussen?
Wie kann er deren Arbeit zielgerichtet beeinflussen?
31
Kapitel 2 Grundlagen
Architektur Föderierter Datenbanksysteme
Im folgenden wird die 5-Ebenen-Schema-Architektur [38] vorgestellt. Die Besonderheit
dieses Architekturvorschlages ist, daß ein föderiertes Schema auf globaler, also übergeordneter Ebene, vorhanden ist. In dieser Architektur werden fünf verschiedene Arten
von Schemata unterschieden. In Abbildung 2.15 sind diese graphisch dargestellt.
externes Schema
externes Schema
föderiertes Schema
Exportschema
Exportschema
Komponentenschema
Komponentenschema
lokales Schema
lokales Schema
Datenbank
Datenbank
Abbildung 2.15: 5-Ebenen-Schema-Architektur aus [38]
Das lokale Schema beschreibt das konzeptionelle Schema eines Komponentendatenbanksystems. Hierbei handelt es sich um die implementierungsabhängige Beschreibung
aller Daten des Komponentensystems. Die lokalen Schemata liegen oftmals in unterschiedlichen Datenmodellen vor.
Um die Unterschiede in den Datenmodellen zu beseitigen, wird das lokale Schema in
ein einheitliches Datenmodell, das Komponentenschema, überführt. Dieses enthält die
gleichen Informationen wie die lokalen Schemata aber in einem einheitlichen Datenmodell.
Das Exportschema beschreibt einen Ausschnitt des Komponentenschemas, welcher
der Föderierung zur Verfügung gestellt wird. Um weitere Datenmodelltransformationen
zu vermeiden, wird auch hier das Datenmodell des Komponentenschemas genutzt.
Die Exportschemata aller Komponentensysteme werden zu einem globalen Schema,
dem föderierten Schema, zusammengefaßt. Diese Schemaintegration und die damit verbundenen Probleme werden im Abschnitt 2.3.4 näher beschrieben. Das föderierte Schema enthält die Beschreibung aller Daten, die durch die Exportschemata bereitgestellt
werden.
Beim externen Schema handelt es sich um eine, auf einzelne Benutzer oder Benutzergruppen zugeschnittene, Schnittstelle, welche die benötigten Daten in geeigneter Form
32
2.3 Verteilte Datenbanken
anbietet. Dafür können auch andere Datenmodelle als im föderierten Schema verwendet
werden.
Mediatoren
Im Gegensatz zur Datenbankföderierung wird bei der Mediator-Wrapper-Architektur,
die vor allem durch Wiederhold [36] populär wurde, nicht davon ausgegangen, daß die
zu integrierenden Komponentendatenbanksysteme kooperativ sind. Vielmehr wird hier
eine isolierende Autonomie der KDBS angenommen. Das heißt, die jeweilige KDBSInstanz wurde unabhängig als Einzellösung für spezielle Anwendungen entworfen und
implementiert. Eine kooperative Auslegung der KDBS zur Einbettung in ein Multidatenbanksystem ist dagegen nicht vorgesehen. Darüber hinaus ist davon auszugehen, daß
kein Exportschema vorliegt.
Bei der Mediator-Wrapper-Architektur werden die KDBS ohne verändernden Eingriff vollkommen autonom gelassen und somit ohne Unterstützung einer Integration,
wie etwa bei den FDBS, über Exportschema bzw. -schnittstellen integriert. Vielmehr
wird eine Vermittlerschicht, der sogenannte Mediator, eingesetzt, um eine integrierende
Sicht auf spezifische, interessierende Ausschnitte der KDBS bereitzustellen. Weiterhin
gilt hier erweitert, daß über KDBS im Sinne eines DBMS hinaus auch weitere Datenquellen, wie z. B. dynamische WWW-Seiten, Methodenaufrufe oder komplexe Informationssysteme, als Komponentensysteme bei dieser Architektur dienen können. Diese
Flexibilität erscheint insbesondere im Zusammenhang mit Web-Datenbanken, die ihren
Inhalt mittels HTML oder eigener XML-Formate präsentieren und über HTTP oder
weitere Protokolle zugreifbar sind, geeignet.
Ebenso wie im Falle von Föderierten Datenbanken ist bei der Mediator-WrapperArchitektur eine Schemahomogenisierung und -integration notwendig. Diese und weitere Aufgaben werden von Softwaremodulen, den Wrappern, übernommen, welche die
Datenquellen kapseln. Der Zugriff vom Mediator erfolgt somit nicht direkt auf die Datenquellen sondern indirekt mittels der Wrapper. Die beschriebene Architektur ist in
Abbildung 2.16 dargestellt.
Dabei übernimmt der Mediator [39, 35] folgende Aufgaben:
1. einheitliche, zentrale Sichten auf die Datenquellen
2. Selektion und Zugriff der für eine Datenanfrage relevanten Datenquellen
3. Filterung und Integration der gewonnenen Daten
4. Zusammenfassung und Strukturierung der Anfrageergebnisse
5. Auslieferung der Anfrageergebnisse an die Anwendung
Der Wrapper hat danach folgende Kernfunktionen zu erfüllen:
1. wrapperübergreifend homogenisierter Export von Schemainformationen
2. Bereitstellung homogener Datenanfrage und -zugriffsfunktionalität
33
Kapitel 2 Grundlagen
Abbildung 2.16: Schematischer Aufbau einer Mediator-Wrapper-Architektur nach [36]
3. Informationen zu den Wrapperfähigkeiten bzgl. Datenschema, -anfrage und Dateneigenschaften
Die Mediator-Wrapper-Architektur ist eine lose Datenbankintegrationsarchitektur,
bei der ein großes Maß an Flexibilität möglich ist. Vor allem hinsichtlich der vollkommenen Autonomie insbesondere dahingehend, daß die Datenquellen nicht zwingend die
Fähigkeiten eines DBMS aufweisen müssen, und daß die Anwendungen des Mediators
sehr robust gegenüber Änderungen des Datenschemas, der Schnittstelle oder der Anfragesprache auf der Seite der Datenquellen sind. Vor allem der Aspekt der zentralen
Sichten ist hier ein wesentlicher Vorteil. Bei Änderungen an einem oder mehreren Komponentendatenschemata müssen nur die betroffenen Views angepaßt werden. Dies kann
auch gegebenenfalls auf Mediator-Ebene erfolgen. So müssen nicht zwingend die Datenschemata der Datenquellen zu einem neuen Gesamtschema integriert werden, wie
das etwa bei einem FDBS denkbar wäre. Dies trifft ebenfalls für Änderungen der Anfragesprache oder der Schnittstelle von Datenquellen zu.
Hier zeigt sich aber auch der Nachteil dieser Architektur: Da Mediator und Wrapper
die zuvor aufgezählte Funktionalität bereitstellen, sind bei entsprechenden Änderungen bei den Datenquellen die zentralen Sichten und/oder die Wrapper anzupassen. Im
schlimmsten Fall ändert sich eine Datenquelle derart, daß der entsprechende Wrapper
34
2.3 Verteilte Datenbanken
neu implementiert werden muß. Aber hier kommt der Vorteil der starken Modularisierung zum Tragen, da eben nur die unmittelbar betroffenen Module gewartet bzw. angepaßt werden müssen, ohne daß weitere Module oder gar Anwendungen/Datenquellen
davon betroffen sind.
Eine weitere Eigenschaft von Mediatoren ist im Zusammenhang mit dem WWW
erkennbar. Dieses Medium erfreut sich großer Popularität zur Bereitstellung von Datenbankinhalten. Somit ist auch die Anzahl der möglicherweise zu integrierenden Datenbanken sehr hoch. Aktuelle Schätzungen kategorisieren etwa in der Bioinformatik
über 550 Datenbanken [40]. Somit wäre ein gesamtintegrierender Ansatz nicht sinnvoll,
da ein derart hochintegriertes Schema zu viele Konflikte zu lösen hätte und, wie die Erfahrung zeigt, relativ häufige Schemaänderungen bei WWW-Datenbanken vorhanden
sind. Weiterhin kann die Mediator-Wrapper-Architektur, wie in Abbildung 2.17 dargestellt, hierarchisch aufgebaut werden, um die Komponenten möglichst klein und somit
wartbar zu machen [39]. So sind z. B. datendomänenspezifische Mediatoren denkbar,
die nach Bedarf gekoppelt werden können aber getrennt wartbar sind.
Abbildung 2.17: Mediatorhierarchie zur Modularisierung und Bündelung der Datenintegration nach [39]
Somit lassen sich die Vorteile eines mediatorbasierten Ansatzes mit besonderer Beachtung der Gegebenheiten der Datenbanken in der Molekularbiologie wie folgt zusammenfassen:
1. Eine vollständige Schemaintegration in ein einheitliches globales Datenschema,
wie bei FDBS vorgeschlagen, ist bezüglich der aufgeführten Konflikte sehr komplex. Folglich wird die anwendungsgetriebene Schemaintegration ausgewählter
Schemateile der Komponentendatenbanken propagiert.
2. Die Menge der zu integrierenden Datenbanken ist derart dynamisch, daß dies
einen Ansatz verlangt, der gegenüber häufigen Änderungen der Exportschemata
35
Kapitel 2 Grundlagen
der Komponentendatenbanken robust ist. Ziel ist es, stabile globale Datenschemata zu gewährleisten.
3. Verschiedene Nutzerklassen haben eine unterschiedliche Sicht des zu modellierenden integrierten Schemas. So kann auch hier der Einsatz von verschiedenen
Sichten, die durchaus auf die gleichen Komponentenschemata Bezug nehmen, als
Vorteil gewertet werden. Dies entspricht einem expliziten Strukturkonflikt, wie er
in Abschnitt 2.3.4 beschrieben ist.
4. Die Komponentendatenbanken besitzen sehr divergente Mächtigkeiten bezüglich der unterstützen DBMS-Funktionalität. Diese reichen von voll unterstützten
DBMS bis hin zu einfachen flachen Dateien ohne unterstützte Anfragesprachen.
5. Die Strukturierung der Daten kann von unstrukturiert bis semistrukturiert reichen, was ebenfalls eine Integration durch ein FDBS verhindert. Vielmehr ist
gerade hier ein Sichtenkonzept in Verbindung mit flexibler Einbindung von divergentesten Datenquellen, wie sie ein Mediator bietet, vorteilhaft.
Mediatorsysteme lassen sich hinsichtlich der Korrespondenz zwischen den lokalen
Schemata der Datenquelle und dem globalen Mediatorschema in zwei Klassen unterscheiden: dem Global-as-View-Ansatz (GaV) und dem Local-as-View-Ansatz (LaV) [41].
Beim GaV-Ansatz wird das globale Schema als Sicht über den lokalen Schemata definiert. Dagegen wird beim LaV-Ansatz von einem globalen Schema ausgegangen, über
das die lokalen Schemata als Sichten definiert werden, die somit nur Ausschnitte des
Schemas sowie der Extensionen beinhalten.
Data Warehouses
Eine weitere Möglichkeit zur Datenbankintegration sind die Data Warehouses (DW).
Die ursprüngliche Entwicklung dieser Datenbankintegrationsarchitektur entstammt der
Unternehmens- oder Wirtschaftsinformatik. Die von der heutigen Anwendung in der
Bioinformatik abweichende ursprüngliche Zielsetzung dieser Architektur wurde mit dem
Ziel entworfen, als Entscheidungshilfe für eine Unternehmensführung zu dienen. Der
Begriff des Data Warehouses wurde zuerst in [42] charakterisiert. Dabei sollen die zu
integrierenden Daten:
• nicht anwendungsbezogen wie die operativen Daten sein,
• verschiedene Anwendungen und Datenbestände einbeziehen,
• die Zeit als bewertbare Bezugsgröße enthalten und
• über einen längeren Zeitraum bestehen
Gleichwohl sind die hier propagierten Eigenschaften in der Anwendung von Data
Warehouses in der Bioinformatik in dieser ursprünglichen Form weniger relevant. Vielmehr wird in [43] eine physikalisch materialisierte, integrierte Sicht auf verteilte Datenquellen als DW bezeichnet. Somit sind in der Bioinformatik die entscheidungsunterstützenden Elemente, der zeitliche Aspekt sowie der operative Charakter der integrierten
36
2.3 Verteilte Datenbanken
Daten weniger zwingend. Vielmehr wird von multidimensionalen bewertbaren Bezugsgrößen, die über die Zeit als ursprünglich einzige Dimension hinausgehen, ausgegangen.
Das heißt, daß in der Bioinformatik eher die Data Warehouse Datenbank (DWDB) in
direkter Verbindung mit der als Extraktion-Transformation-Laden“-Prozeß (ETL) um”
gesetzten Datenbankintegration gemeint ist. Eine solche Architektur ist in Abbildung
2.18 dargestellt und orientiert sich an dem ETL-Prozeß eines zentralen Data Warehouses, wie er in [44] im Überblick beschrieben wird. Der ETL-Prozeß gliedert sich dabei
Abbildung 2.18: ETL-Prozeß eines Data Warehouses im Überblick aus [44]
in vier Schritte:
1. Filterung
Im Rahmen der Filterung erfolgt znächst die Anbindung der unterschiedlichsten
internen und externen Datenquellen über entsprechende Schnittstellen, wie z. B.
ODBC oder JDBC. Darüber hinaus sollten Extraktions- und Transformationswerkzeuge auch flat-file-Formate und weitere Datenzugriffsschnittstellen unterstützen. Die Funktionalität ist hier mit Wrappern aus Abschnitt 2.3.3 vergleichbar. Im Zuge der Extraktion erfolgt die Selektion der Basisdaten in eine sogenannte Staging Area. Hier erfolgt eine temporäre Zwischenspeicherung der importierten
Rohdaten, um diese von systematischen Fehlern zu bereinigen. Diese Fehler fallen in die Klasse der Datenheterogenitäten, wie sie in Abschnitt 2.3.4 beschrieben
werden.
2. Harmonisierung
Hierzu gehört neben der Zusammenfassung der Daten aus den unterschiedlichen
37
Kapitel 2 Grundlagen
Datenquellen auch die einheitliche Kodierung von Attributen und die Abstimmung der Schlüsselbeziehungen. Somit kann dieser Schritt im Kontext der Datenbankintegration als Menge von Datenvereinigungsoperationen über datendomänen- und datentypspezifischen Join- sowie Union-Operationen aufgefaßt werden.
3. Verdichtung
Liegen die Daten in bereinigter und konsistenter Form vor, so werden in diesem
Schritt ausgewählte Daten mit dem Ziel der späteren Zuführung zu On-Line
”
Analytical Processing“ (OLAP) u. a. in Form von Aggregationen gruppiert. Dieser Schritt ist im Kontext der Verwendung des Data-Warehouse-Begriffes in der
Bioinformatik nicht zwingend notwendig.
4. Anreicherung
Analog zum vorherigen Schritt ist dieser im Kontext der Bioinformatik weniger
von praktischer Bedeutung. Hier werden Vorausberechnungen auf den in der Staging Area befindlichen Daten durchgeführt, um Kennzahlen für spätere OLAPAnwendungen zu gewinnen. Bei diesen Vorausberechnungen spielen vor allem
Performanceüberlegungen eine Rolle.
Im Bereich der Bioinformatik sind die Schwerpunkte des ETL-Prozesses auf der Ebene
der Extraktion und der Harmonisierung zu finden. Vor allem bei sehr umfangreichen
Operativdaten ist hier der Flaschenhals“ zu sehen, da notwendige Datenaktualisie”
rungen mit einem erneuten Extraktionsprozeß verbunden sind. So sind entsprechende
Varianten zur Datenaktualisierung zu wählen, wie etwa inkrementelle Mechanismen
oder Änderungsverfolgungen der Operativdaten.
2.3.4 Integrationskonflikte
Wie bereits angedeutet, existieren bei homogenen wie auch bei heterogenen MDBS
heterogene Komponentendatenbanken. Da diese zu einem globalen System zusammengeführt werden sollen, müssen die möglichen Heterogenitäten aufgelöst werden. Die
hierzu notwendige Integration der KDBS findet auf verschiedenen Ebenen statt:
1. System
2. Datenmodell
3. Partitionierung/Allokation
4. Daten
5. Schema
Nachfolgend werden die genannten Heterogenitäten überblicksweise charakterisiert. Dabei wird auf Schemaheterogenitäten verstärkt eingegangen, weil hier aufgrund der Problemkomplexität eine zusätzliche Unterteilung sinnvoll erscheint.
38
2.3 Verteilte Datenbanken
1. Systemheterogenitäten
Durch die Vielzahl von Software in den Bereichen
a) Netzwerkkommunikation,
b) Zugriff auf entfernte Dienste,
c) Datenbankmanagementsystem oder
d) Implementierungen von Datenzugriff oder -anfragesprachen
existieren je nach jeweiliger Projektanforderung oder anderer, teils evolutionär
vorhandener Gegebenheiten, verschiedenste Systeme auf KDBS-Seite. Dies wiederum propagiert sich zu Systemheterogenitäten und somit zu Konflikten bei der
Datenbankintegration. Ein einheitlicher Datenzugriff auf Systemebene ist in der
Praxis schwer zu realisieren. So unterscheidet sich beispielsweise der Zugriff auf
die in Tabelle 2.3 aufgeführten Datenbanken erheblich.
Datenbank Netzwerkprotokoll
KEGG [14]
HTTP
SWISSPROT [46]
HTTP
CR-EST
[49]
HTTP
SQLNET
native
Schnittstelle
DBGET
[45]
HTTPGET
JDBC,
ODBC
API
SOAP
SwissKnife
[47],
BioPerl [48]
keine
Datenhaltungsmethode
indizierte
flat-files
DBMS
DBMS
Schemainformationen
WSDL
HTMLDokumente
DBKatalog
Tabelle 2.3: Systemheterogenitäten ausgewählter Beispieldatenbanken
2. Datenmodellheterogenitäten
Wie in Abschnitt 2.2.2 eingeführt, existieren verschiedene Paradigmen, Methoden
und Sprachen zur semantischen Modellierung von Datenbanken. Das resultiert in
dementsprechend divergenten Umsetzungen von DBMS, die notwendigerweise an
ein zugrundeliegendes Datenmodell geknüpft sind. Im Einsatz befinden sich, insbesondere im Diskursbereich der Molekularbiologie, das objektorientierte, relationale sowie das hierarchische Modell. Dieser Umstand macht somit eine Abbildung
der verschiedenen Modelle aufeinander notwendig. Manche Konzepte der verschiedenen Modelle sind direkt nicht aufeinander abbildbar, wie etwa das Konzept der
Polymorphie bzw. im speziellen das Vererbungskonzept. Bestenfalls gelingt es,
indirekt Konzepte nachzubilden, wie etwa bei objektrelationalen Abbildungen.
Dabei ist es durchaus möglich, daß die im jeweiligen Modell implizit enthaltene
Semantik auf der Schemaebene und/oder der Datenebene/Anwendungsebene explizit nachgebildet werden muß. Das gilt so auch für die Datenbankintegration,
die Konvertierungen zwischen den Modellen vornehmen muß.
39
Kapitel 2 Grundlagen
3. Partition/Allokation
Da die Daten physikalisch über verschiedene Datenquellen verteilt sind, entstehen
in diesem Zusammenhang Heterogenitäten. Abbildung 2.19 zeigt eine mögliche
Datenverteilung über drei Datenserver in graphischer Form.
Abbildung 2.19: Beispiel einer Partitionierung und Allokation
Bei der Partitionierung ist eine globale Datenstruktur in Teilstrukturen zerlegt.
Die Partitionierung wird in zwei Klassen unterteilt:
Horizontale Partitionierung
Diese Klasse erzeugt aus der Menge von Daten, die in einer Datenstruktur vorliegen, Teilmengen. Die in Abbildung 2.19 dargestellte Beispieldatenstruktur beinhaltet in der ersten Hierarchiestufe eine Unterstruktur 4,
von der eine Menge von Instanzen existieren. Davon werden die ersten in
der Datenquelle 1, weitere Instanzen in Datenquelle 3 und die restlichen in
Datenquelle 4 gespeichert.
Vertikale Partitionierung
Hierbei handelt es sich um die Zerlegung der globalen Datenstruktur in Unterstrukturen. So kann z. B. eine Struktur mit fünf Elementen in zwei Teile
zerlegt werden, wobei der erste Teil die Elemente 1, 3 und 5 enthält und der
zweite Teil aus den Elementen 2 und 4 besteht.
40
2.3 Verteilte Datenbanken
Die Allokation legt den physischen Speicherort fest. Das heißt, die zuvor partitionierten Daten werden bestimmten Datenquellen zugewiesen. Es ist auch möglich,
daß auf dieser Ebene Überschneidungen der Daten entstehen, also die horizontale
Partitionierung in nicht-disjunkte Teilmengen zerlegt wird.
4. Datenheterogenitäten
Basierend auf Erfahrungen bei der Integration von Daten und theoretischen Betrachtungen wie in [50], ergeben sich Probleme bei der Integration von Daten.
Das heißt, die durch mehrere KDBS modellierten Sachverhalte und die hierzu
gespeicherten Daten können semantisch ähnlich sein. Nur folgt daraus keineswegs
in allen Fällen eine direkte Datengleichheit. Hier sind Methoden notwendig, um
beim Zusammenführen von Daten bei der Datenbankintegration, im einfachsten
Fall durch Mengenoperationen, semantisch gleiche Daten zu vereinigen. Es können
drei Fälle unterschieden werden:
a) direkt umrechenbare Daten
Zu dieser Kategorie zählen solche Daten, die trotz der Existenz von Datentypkonflikten (Integer vs. String), Dateneinheitskonflikten (Grad Fahrenheit vs. Grad Celsius) oder Präzisions-/Wertebereichs-/Zeichensatzkonflikte
(TRUE/FALSE vs. 0/1) aufeinander abbildbar sind.
b) semantisch äquivalente Daten
Im Falle von Daten, die einen Sachverhalt in semantisch äquivalenter Weise
erfassen, d. h. bedeutungsgleich sind, sind klassische Verfahren zur Datenzusammenführung in Form von Mengenoperationen nicht mehr möglich. Denn
es sollte davon ausgegangen werden, daß dazu die Daten interpretiert werden müssen. Hierzu ist Domänenwissen notwendig. Das heißt, die Bedeutung
muß eindeutig erfaßt und diese in Beziehung zueinander gesetzt werden. Da
es sich hierbei um eigene Forschungsbereiche handelt, nämlich die der semantischen Datenbankintegration und Ontologien, wird hier auf [51] verwiesen.
In dieser Dissertation werden zu diesem Thema detaillierte Ausführungen
gegeben.
Weiterhin kann davon ausgegangen werden, daß mitunter Redundanz durchaus gewollt bzw. notwendig ist. So existieren z. B. für ein und das selbe
Protein verschiedene Namen oder multilinguale Funktionsbeschreibungen,
die natürlich keine vollständig automatische Mengenvereinigung derart zulassen, daß nur noch der an einem Institut gebräuchlichste Proteinname und
die deutsche Funktionsbeschreibung im Resultat enthalten sind. Andererseits könnte argumentiert werden, daß ebensolches Verhalten von Nutzern
einer Datenbankintegration gewünscht wird und etwaige Integrationsprofi”
le“ zur Konfiguration der Datenbankintegration genutzt werden. Somit sind
Strategien notwendig, die hier angewandt werden können.
c) Falschdaten
Aufgrund von fehlerhaften oder überalterten Daten ist es schwer möglich,
41
Kapitel 2 Grundlagen
Datenäquivalenz festzustellen. Dies ist aber notwendig, um das Zusammenführen von gleichen Daten umzusetzen, denn auf keinen Fall sollten zueinander inkonsistente Daten als Alternativen im Sinne einer Mengenvereinigung
aufgefaßt werden. Vielmehr wären Mechanismen umzusetzen, die inkorrekte
von korrekten Daten unterscheiden und die inkorrekten als nicht vorhanden
auffassen.
5. Schemaheterogenitäten
Ein sehr wichtiger Punkt bei der Konzeption einer Datenbankintegration ist die
Zusammenführung der Datenbankschemata der Komponentensysteme und die damit verbundene Überwindung von Schemaheterogenitäten. In [52] wurden hierzu
drei Grundforderungen an ein integriertes Schema gestellt:
• Vollständigkeit
• Minimalität
• Verständlichkeit
Daß bei diesen Kriterien in späteren Betrachtungen der vorliegenden Arbeit Einschränkungen gemacht werden, ändert nichts an den wesentlichen Problemen der
Schemaintegration, die von einer Datenbankintegration gelöst werden müssen. So
werden nachfolgend einige wesentliche Aspekte hierzu aufgeführt, wie sie in der
Literatur, etwa in [34], erörtert worden.
Es können zwischen den in den lokalen Schemata modellierten Weltausschnitten
Überlappungen auftreten, da die Daten der Komponentensysteme untereinander
teilweise redundant gehalten werden oder in enger Beziehung zueinander stehen.
Dieser Umstand ist auch und vor allem in der Molekularbiologie zu beobachten.
So werden z. B. Genomdaten in Europa in der EMBL-Datenbank [53], in den
USA in der Genbank [54] und in Japan in der DDBJ-Datenbank [55] gehalten,
da es jeweils nationale (regionale) Genomprojekte gibt. Strukturell und inhaltlich unterscheiden sich diese drei Datenbanken nur nominal. Diese Redundanzen
müssen bei der Integration erkannt und aufgelöst werden.
Weiterhin können strukturelle und semantische Inkompatibilitäten auftreten, die
auf der Tatsache beruhen, daß die Komponentendatenbanken unabhängig oder
wenigstens sehr autonom voneinander entworfen und implementiert wurden. In
folgenden Unterabschnitten werden dazu einige Hauptprobleme und Aspekte heterogener Datenschemata in Bezug auf deren Integrierbarkeit aufgeführt:
• Semantische Konflikte
Hierbei sind die Realweltobjekte in den einzelnen Datenbanken unterschiedlich repräsentiert. So kann es z. B. in einem System Proteine geben und in
einem anderen nur Enzyme, wobei Enzyme spezielle Proteine sind.
• Beschreibungskonflikte
Es ist möglich, daß Realweltobjekte unterschiedlich modelliert werden. Mögliche Differenzen sind:
42
2.4 Resümee
–
–
–
–
–
–
unterschiedliche Attribute
Benennungskonflikte
Wertebereichskonflikte
Skalierungskonflikte
unterschiedliche Integritätsbedingungen
unterschiedliche Manipulationsoperationen
• Heterogenitätskonflikte
Oftmals liegen die zu integrierenden Schemata in unterschiedlichen Datenmodellen vor. Das ist der Fall, wenn ein relationales und ein objektorientiertes Schema integriert werden sollen. Dieser Konflikt impliziert üblicherweise
immer auch strukturelle Konflikte.
• Strukturelle Konflikte
Derselbe Sachverhalt aus der realen Welt kann oft durch Verwendung unterschiedlicher Modellierungskonzepte beschrieben werden. Dies ist vor allem
bei Datenmodellen der Fall, die viele Modellierungskonzepte unterstützen.
So hat der Datenbankarchitekt bei einem objektorientierten Datenmodell
oft die Wahl, ob er eine Eigenschaft einer bestimmten Klasse von Objekten
als wertbasiertes Attribut oder als Referenz auf ein eigenständiges Objekt
modelliert, das diesen Wert repräsentiert.
Diese Konflikte müssen bei der Schemaintegration durch menschlichen Eingriff
erkannt und behoben werden. Das dazu nötige Detailwissen muß durch eingehendes Studium der lokalen Schemata und Befragungen der Datenbankanbieter
gewonnen werden.
Obwohl die Integritätssicherung ebenfalls im engen Kontext zu den in diesem Abschnitt eingeführten Integrationskonflikten steht, wird dieses Thema an dieser Stelle
nicht weiter betrachtet. Vielmehr wird auf den Abschnitt 3.1.3 verwiesen, in dem allgemeine Aspekte der Datenqualität im besonderen Kontext einer Datenbankintegration
aufgearbeitet wurden.
2.4 Resümee
In diesem Kapitel wurden für die Arbeit wesentliche Aspekte der molekularen Genetik,
der Datenbanken und der verteilten Datenbanken aus Sicht der Informatik vorgestellt.
Es wurden Begriffe eingeführt und grundlegende Definitionen gegeben.
Im Abschnitt zu den Grundlagen der molekularen Genetik wurden die DNA als Träger der genetischen Informationen, die Genexpression als Umsetzung der genetischen
Informationen in Polypeptide und schließlich die Proteine und speziell die Enzyme und
deren Rolle in Stoffwechselwegen eingeführt.
Im folgenden ersten Informatikabschnitt wurden grundlegende Begriffe der Datenbanktheorie und der Modellierung erörtert. Anschließend wurden Basiselemente der
43
Kapitel 2 Grundlagen
E/R- und UML-Notation eingeführt, die auch in folgenden Kapiteln der Arbeit Verwendung finden werden. Die Abschnitte Datenformate, Anfragesprachen und Schnittstellen
informierten zu aktuellen Methoden und Techniken zum Zugriff auf Datenbanken.
Abgeschlossen wurde das Kapitel mit einer Ausarbeitung zu verteilten Datenbanken. Dabei wurden neben theoretischen Betrachtungen auch ausgewählte Ansätze zur
Datenbankintegration im Bereich heterogener Multidatenbanksysteme vorgestellt. Insbesondere datenbankzentrische Ansätze, wie Föderierte Datenbanksysteme, Mediatoren
und Data Warehouses wurden beschrieben.
44
Kapitel 3
Datenbankintegration in der
Bioinformatik
In diesem Kapitel werden Aspekte der angewandten Datenbankintegration in der Molekularbiologie erörtert. Insbesondere werden spezielle Eigenschaften von molekularbiologischen Datenbanken in Bezug auf deren Besonderheiten aufgezeigt. Weiterhin werden
existierende Systeme zur Datenbankintegration in der Molekularbiologie vorgestellt und
analysiert.
3.1 Datenbanken in der Molekularbiologie
Datenbanken spielen in der Molekularbiologie eine zentrale Rolle. Momentan existieren
zwischen 500 und 1000 publizierte Datenbanken. In diesem Zusammenhang existieren Erhebungen, welche einen gewissen Umfang dieser Datenbanken katalogisieren, wie
zum Beispiel DBcat [56] und The Molecular Biology Database Collection“ [40]. Ein
”
entscheidendes Merkmal dieser Datenbanken ist der Umstand, daß ein Großteil der Forschungsaktivitäten existentiell von der Nutzung von Datenbanken abhängt, und deshalb
etablierte Datenbanken notwendigerweise über das Internet zugänglich sein müssen. Ein
weiterer Aspekt ist die starke Vernetzung der Datenbanken, die in Form von expliziten
Querverweisen der Daten untereinander oder implizit durch überlappende Datenbestände in verschiedenen Datenbanken existiert.
3.1.1 Charakterisierende Besonderheiten
Die in der vorliegenden Arbeit als Ausgangspunkt und Basis der in den nachfolgenden
Kapiteln beschriebenen Datenbankintegration betrachteten Datenbanken entstammen
biologischen bzw. molekularbiologischen Forschungsprojekten. Daraus ergeben sich besondere Eigenschaften, die in diesem Abschnitt untersucht werden sollen. Nachfolgende
Betrachtungen stützen sich auf Ausarbeitungen zu diesem Thema aus [57, 58].
Molekularbiologische Datenbanken sind sehr heterogen in Bezug auf Zielsetzung,
Nutzbarkeit, Umfang oder die genutzte Softwaretechnologie. Dabei sind viele molekularbiologische Datenbanken sehr groß im Datenumfang. So enthält die GenBank [54],
als eine der Hauptressourcen für öffentlich verfügbare Nukleotidsequenzen, über 4 ∗ 107
45
Kapitel 3 Datenbankintegration in der Bioinformatik
Sequenzen mit ca. 4, 4 ∗ 1010 Basenpaaren1 . Hierbei handelt es sich um eine Momentaufnahme, denn das Wachstum des Datenbestandes der meisten Datenbanken ist exponential, wie Abbildung 3.1 zeigt.
Abbildung 3.1: Datenwachstum ausgewählter molekularbiologischer Datenbanken [59]
Viele molekularbiologische Datenbanken wurden unter Nutzung von ad hoc“Metho”
den zur Datenverwaltung entwickelt. Hierbei steht oftmals weniger eine umfangreiche,
gut strukturierte Datenmodellierung als eine anwendungsbezogene Datenerfassung im
Fokus der Datenbankentwickler. So sind Datenbanken häufig als einfache Sammlungen von indizierten flat-files implementiert. Eine vollständige Auflistung ist in Tabelle
3.1 zu finden. Dabei enthält die Klasse der flat-file“-Datenbanken die sogenannten
”
Web-Datenbanken. Diese können als eine Kombination einfacher, flacher Dateien und
formularbasierter Datenzugriffsschnittstellen aufgefaßt werden. Dabei wird in vielen
Fällen HTML als Datenformat genutzt. Weitere Betrachtungen zu Datenformaten und
Schnittstellen werden in Abschnitt 3.1.2 vorgenommen. Der Ursprung der Daten sind:
1. reformatierte Ausgaben von Analysewerkzeugen,
2. formularbasierte Datenerfassungswerkzeuge, wobei Probleme mit inkonsistenten
und oftmals Freitextdaten auftreten und
1
Stand Februar 2005: http://www.ncbi.nlm.nih.gov/Genbank/genbankstats.html
46
3.1 Datenbanken in der Molekularbiologie
Genutzte Methode
flat-file
RDBMS
OODBMS
ORDBMS
keine Aussage
Anteil
40%
37%
6%
3%
14%
Tabelle 3.1: Genutzte Methoden für molekularbiologische Datenbanken nach [57]
3. manuelle Datenakquisition aus der Literatur.
Somit sind Inkonsistenzen, Redundanzen und relativ viele Freitextdaten in den Datenbanken zu finden.
Eine weitere wesentliche Eigenschaft von molekularbiologischen Datenbanken ist deren reiche Verknüpfung untereinander. So wird in einer Untersuchung festgestellt, daß
87% der dort betrachteten Datenbanken Querweise zu weiteren Datenbanken enthalten
[57]. Die verbreiteste Methode ist hier die Anreicherung von Datenbanken mit HTMLHyperlinks zu in Beziehung stehenden Daten weiterer Datenbanken. Dabei wird in
der Regel auf die Web-Präsentation der jeweiligen Datenbank durch die Nutzung von
HTTP-GET-kompatiblen URLs zurückgegriffen.
Eine weitere, als zunehmender Trend in der Molekularbiologie zu beobachtende Eigenschaft ist die Nutzung einheitlicher Identifikatoren und kontrollierter Vokabularien.
Dies begünstigt Aufgaben der Schema- und Datenintegration, da so schon grundlegende
Konfliktklassen, wie in Abschnitt 2.3.4 aufgeführt, vermieden werden.
Auch und gerade auf der Ebene der semantischen Datenbankintegration im Bereich
der Molekularbiologie existieren einige Arbeiten, die molekularbiologische Datenbanken
auf Datenschema- und Datenebene semantisch anreichern. Dazu gehören TAMBIS [60],
SEMEDA [61] und auf Datenebene die Gene Ontology [62] oder Medical Subject Headings (MeSH) [63]. Verwandte Arbeiten aus dem Bereich Semantic Web [64], wie etwa
die Web Ontology Language (OWL) [65] oder WordNet [66] als lexikalische Datenbank
der englischen Sprache, haben ebenfalls Einfluß auf aktuelle Forschungsarbeiten in der
Bioinformatik.
In diesen Bereich der Besonderheiten molekularbiologischer Datenbanken fällt auch
die Verwendung einheitlicher Datenidentifikatoren bzw. Bezeichner. So existieren datendomänenspezifische Nomenklaturen. So gibt es Bestrebungen, etwa Gennamen beim
menschlichen und beim bakteriellen E.-coli-Genom oder auch Molekülbezeichnungen,
wie etwa bei Enzymen [67], einheitlich zu wählen.
Zur eindeutigen Identifizierung von Datenbankeinträgen im Kontext der Molekularbiologie sind datenbankübergreifende Mechanismen erkennbar. Diese beruhen auf
Standardisierungsbemühungen, um in einzelnen Domänen der Molekularbiologie eine
Systematik und Referenzierbarkeit der Daten umzusetzen.
Es können vier Arten von eindeutigen Bezeichnern klassifiziert werden. Die sich ergebenen Bezeichnerklassen und entsprechende Beispiele sind in Tabelle 3.2 zusammen-
47
Kapitel 3 Datenbankintegration in der Bioinformatik
gefaßt. Weitere Beispiele und Benennungsstandards sind in WWW-Dokumenten, wie
Identifikatorklasse
künstlich
Anwendung
Referenz
generierte Zeichenketten oder Zahlen
ohne implizite Semantik
systematisierend Dezimalzahlen geben
eine
hierarchische
Klassifizierung wider
Gene Ontology
[62]
akronymisierend natürlichsprachliche
Beschreibungen werden zu eindeutigen
Akronyme gebildet
hybrid
Kombination aus natürlichen Zahlen mit
Buchstabenkode zur
eindeutigen Identifizierung sowie impliziten Informationen
UniProt [69]
EC-Nummern
[68]
CR-EST [49]
Ausprägung/Bedeutung
GO:0008150
biological process“
”
EC 3.5.3.1
– Hydrolases
– Acting on Carbon-Nitrogen Bonds
– Linear Amidines
– Arginase
SKG1
Suppenkaspergen“
”
HO40A07S
– Bibliothek
– Platte
– Plattenadresse
– Primer
Tabelle 3.2: Klassifizierung von Identifikatoren molekularbiologischer Datenbanken
etwa unter der URL:
http://www.genome.ad.jp/kegg/kegg4.html
zu finden. Eine Auswahl bildet folgende Aufzählung:
• OMIM [70]
• ICD-10-Code [71]
• CAS-Nummern [72]
• SMILES [73]
Es kann nicht davon ausgegangen werden, daß die genannten Beispiele für eindeutige
Identifikatoren kontrolliert eingesetzt werden. Eine Datenintegration kann also nicht
unter der Annahme umgesetzt werden, daß gleiche Identifikatoren gleiche, hierzu funktional abhängige Daten bedingen. Dies ist nur für größere Verbundprojekte, wie etwa
die drei Sequenzdatenbanken EMBL [74], Genbank [54] und DDBJ [55], der Fall. Hier
werden datenbankübergreifend eindeutige Identifikatoren eingesetzt.
48
3.1 Datenbanken in der Molekularbiologie
3.1.2 Datenformate und Datenzugriff
Für den Austausch und die Präsentation von Daten in der Molekularbiologie ist die
Verwendung von dateibasierten Datenformaten weit verbreitet [75]. Es ist dabei zu
beobachten, daß eine Trennung von
1. Datenbackend, d. h. der eigentlichen DBMS-Komponente,
2. Datenpräsentation und
3. Datenaustausch
vorgenommen wird. Abbildung 3.2 zeigt eine schematische Darstellung der vorherrschenden Architektur von molekularbiologischen Datenbanken hinsichtlich der angebotenen Datenformate.
Abbildung 3.2: Schematische Darstellung der Datenaustauschformatklassen molekularbiologischer Datenbanken
Das Datenbackend ist, wie im Abschnitt 3.1.1 ausgeführt wurde, entweder ein DBMS
oder ein proprietäres, auf flat-file-Techniken basierendes Datenbanksystem. In beiden
Fällen ist eine Datenunabhängigkeit anzunehmen, so daß die hier verwendeten Datenformate nicht weiter betrachtet werden sollen.
Für die Datenpräsentation ist die Nutzung von HTML oder auch WML [76] als
Datenformate, die bekanntermaßen wiederum auf XML beruhen, verbreitet. Für den
Datenaustausch sind die gleichen Formate üblich, obgleich hier HTML eine eher untergeordnete Rolle spielt, aber in manchen Fällen aufgrund fehlender Alternativen, wie
etwa durch das Spiegeln der HTML-Datenpräsentationsschicht einer Web-Datenbank,
genutzt werden muß. Auch ist es möglich, durch Parser den Inhalt von HTML-Seiten zu
49
Kapitel 3 Datenbankintegration in der Bioinformatik
extrahieren. Da aber HTML als Präsentationsformat eingesetzt wird, sind hier strukturierende Elemente dieses Datenformates eher auf das visuelle Layout der Daten als
auf die Unterstützung einer maschinellen Verarbeitung ausgerichtet.
Daneben spielt die Verwendung von proprietären ASCII-flat-file-Strukturen eine
große Rolle. Populäre Datenbanken wie EMBL [74], als eine der drei internationalen
Hauptressourcen für Sequenzdaten, setzen ein solches Format um. Aber auch das sogenannte FASTA-Format [77], das für das gleichnamige Bioinformatikwerkzeug zum Sequenzvergleich entwickelt wurde, ist heute ein Quasistandardformat zum Austausch von
Sequenzdaten. Ein weiteres, populäres Format für flat-files ist das sogenannte Two-Letter-Code-Format für Datenbanken am European Bioinformatics Institute (EBI). Hierbei
wird das in Abschnitt 2.2.3 eingeführte Konstrukt von Name-Wert-Paaren genutzt. In
den Anhängen A.1 und A.2 sind entsprechende Beispiele eines formatierten Datensatzes
für den jeweils gleichen Eintrag einer DNA-Sequenz in der EMBL-Datenbank [74] und
GenBank-Datenbank [54] dargestellt.
Im Falle von flat-files ist eine Formatbeschreibung notwendig, die es ermöglicht, Parser zu entwickeln, die diese Formate verarbeiten können. Eine solche Beschreibung sollte
folgende Informationselemente enthalten:
1. zulässige lexikale Konstrukte
Hier werden alle zulässigen Wörter als Kombination von gültigen Zeichen spezifiziert.
2. Syntaxbeschreibung
Die Syntax beschreibt hier Regeln zur Konstruktion von gültigen Kombinationen,
Abfolgen und Strukturen lexikaler Konstrukte.
3. Datenschemasemantik
Hier werden Regeln zur Abbildung der Strukturen des Datenformates auf Datenschemaelemente und -beziehungen angegeben.
Im Falle von molekularbiologischen Datenbanken sind formale und informale Formatbeschreibungen für die Anforderungen 1 und 2 üblich. Dagegen ist Punkt 3 eher selten
erfüllt. Einige Beispiele existieren aber auch hier, wie etwa die UniProt-Datenbank
[69], die mittels eines XML-Schemas die Abbildung ihres XML-Formates in die hierarchischen Strukturen von XML-Datenbanken ermöglicht.
Informale Beschreibungen erlauben das manuelle Programmieren von Parsern. Sie
sind aber nicht bzw. nur bedingt für eine automatische Generierung von Parsern geeignet, da die so angegebenen Regeln manuell interpretiert werden müssen.
Dagegen ist für eine Automatisierung dieses Prozeßes eine formale, maschinell verarbeitbare Formatbeschreibung notwendig. Dies können Grammatiken, Datenstrukturspezifikationssprachen u. a. sein. Entsprechende Notationen sind in der Informatik bekannt und werden auch in der Bioinformatik eingesetzt. Dazu gehören Sprachen, wie
die Data Type Definition Language (DTD) für das XML-Datenformat oder Abstract
Syntax Notation One (ASN.1).
50
3.1 Datenbanken in der Molekularbiologie
Am National Center for Biotechnology Information (NCBI) z. B. wird zur Spezifikation von Datentypen ASN.1 eingesetzt. ASN.1 ist ein Standard2 , welcher einen
Formalismus zur Spezifikation von abstrakten Datentypen definiert. Ausgehend von
Basisdatentypen können komplexe Datenstrukturen inklusive Parametrisierungen und
Nebenbedingungen, d. h. Konsistenzbedingungen entwickelt werden, die wiederum als
Datenaustauschformat dienen. Durch die Unterstützung verschiedener Programmiersprachen, wie etwa JAVA, C++ oder C, sowie das Vorhandensein verschiedener Werkzeuge hat sich ASN.1 vor allem auch in anderen ingenieurtechnischen Bereichen als weit
genutzter Standard zur Datenmodellierung etabliert.
Das UniProt-Konsortium nutzt u. a. zur Formatierung ihrer flat-file-Daten
XML/DTD. Hier existiert eine in der DTD-Sprache formatierte Syntax für das auf
XML-basierende Austauschformat der UniProt-Datenbank. Im Anhang A.4 ist ein Auszug dieser DTD enthalten. Wie an diesem Beispiel zu erkennen ist, wird hier Forderung
3, einer Datenschemasemantik, aus der in diesem Abschnitt eingeführten Anforderungsliste an Formatbeschreibungen in Form von natürlichsprachlichen Kommentaren zur
Interpretation der Datenstrukturelemente erfüllt.
Da XML in der Bioinformatik insbesondere bei molekularbiologischen Datenbanken
eine zunehmend bedeutende Rolle in Bezug auf die Datenformatierung einnimmt, werden im folgenden einige Beispiele für XML-basierte Datenformate nach [75] gegeben.
Bioinformatic Sequence Markup Language
Die Bioinformatic Sequence Markup Language (BSML)3 spezifiziert eine DTD,
die Sequenzinformationen für die DNA, RNA und Proteine modelliert.
BIOpolymer Markup Language
Die BIOpolymer Markup Language (BioML)[78] wurde entwickelt, um die hierarchische Struktur eines lebenden Organismus abzubilden. Damit wird es möglich,
Informationen verschiedener Domänen untereinander in Verbindung zu setzen und
so Protein- und DNA-Sequenzen zu annotieren.
Chemical Markup Language
Die Chemical Markup Language (CML)[79] hat das Ziel, verschiedene chemische
Informationen (atomare, molekulare, kristallographische etc.) in Verbindung mit
zusätzlichen Informationen, wie etwa Veröffentlichungen etc., einheitlich zu verwalten.
KGML
Die KEGG Markup Language (http://kegg.genome.ad.jp/kegg/kegg3.html)
beinhaltet eine DTD für eine Stoffwechselwegdarstellung inklusive Metaboliten,
Enzymen und deren Verbindungen.
SBML
Die Systems Biology Markup Language (SBML) [80] ist eine allgemeine Sprache zur Repräsentation von biochemischen Modellen. SBML enthält Strukturen
2
3
ISO 8824-1 bis ISO 8825-2 / ITU-T X.680 bis ITU-T X.683, ITU-T X.690, ITU-T X.691
http://www.visualgenomics.com/products/index.html
51
Kapitel 3 Datenbankintegration in der Bioinformatik
zur Beschreibung von Zellkompartimenten, biochemischen Reaktionen, daran beteiligten chemischen Entitäten und globalen bzw. lokalen Parametern. Darüber
hinaus können optional abstrakte Einheiten für Quantitäten definiert, sowie mathematische Regeln spezifiziert werden.
Taxonomic Markup Language
Die Taxonomic Markup Language [81] beinhaltet eine DTD für die Beschreibung
von taxonomischen Beziehungen zwischen Organismen.
XEMBL
Die EMBL-Datenbank des European Bioinformatics Institute (EBI) ist traditionell in verschiedenen flat-file-Formaten erhältlich. Es wurde aber erkannt, daß die
Nutzung von XML als Datenaustauschformat für die EMBL-Daten vorteilhaft
ist. So wurde mit XEMBL [82] ein CORBA-basierter WWW-Dienst implementiert, der aus den EMBL-Daten XML-Dateien erzeugt. Dabei werden z. Zt. DTDs
von BSML4 und AGAVA5 (Architecture for Genomic Annotation, Visualization
and Exchange) von DoubleTwist, Inc. unterstützt. Der Zugriff erfolgt über SOAP
bzw. CGI-Aufrufe.
Die obige Aufzählung stellt eine Auswahl dar. Weitere Informationsquellen zu XMLbasierten Sprachen können folgender Auflistung entnommen werden:
• CellML (Cell Markup Language)
http://www.cellml.org
• PSI-MI (Proteomics Standards Initiative/Molecular Interaction)
http://psidev.sourceforge.net/mi/xml/doc/user
• PSI-MS (Proteomics Standards Initiative/Mass Spectrometry)
http://psidev.sourceforge.net/ms/index.html
• GEML (Gene Expression Markup Language)
http://www.geml.org
• MAGE-ML (MicroArray and Gene Expression Markup Elements)
http://www.mged.org/Workgroups/MAGE
• MSAML (XML for Multiple Sequence Alignments)
http://xml.coverpages.org/msaml.html
• BIOXML (a center of development for open source biological DTDs)
http://www.bioxml.org
Diese Auflistung von XML-basierten Datenformaten in der Molekularbiologie stellt
einen Ausschnitt dar und erhebt keinen Anspruch auf Vollständigkeit, zumal in diesem Gebiet eine starke Dynamik existiert.
4
5
http://www.visualgenomics.com
http://www.agavexml.org
52
3.1 Datenbanken in der Molekularbiologie
Schemainformationen
Die Bereitstellung und Verwaltung von Schemainformationen sind wesentliche Eigenschaften eines DBMS. Für die Nutzung der Daten einer Datenbank ist es unabdingbar,
Struktur und Beziehungen der Daten zu kennen. Somit ist der Zugriff auf Metadaten,
die ein Datenschema beschreiben, notwendig. Es besteht hier auch ein Zusammenhang
mit den Datenbankzugriffsschnittstellen, wie sie in Abschnitt 2.2.5 beschrieben wurden.
Somit ist der Zugriff auf ein Datenschema von einer direkten Schnittstelle zum DBMS
abhängig und setzt voraus, daß der direkte Zugriff auf das DBMS möglich ist. Das
kann im Fall von DBMS mittels etablierter APIs, wie etwa JDBC oder ODBC, erfolgen. Tatsächlich ist dies in den seltensten Fällen möglich. Vor allem Sicherheits- und
Stabilitätsforderungen der Datenbankanbieter sind Begründungen, um einen direkten
DBMS-Zugriff nicht zu unterstützen.
Vielmehr wird oftmals eine Middlewarelösung eingesetzt. Middlewarelösungen im
Umfeld der Bioinformatik zum Zugriff auf Datenbanken sind z. B. CORBA, SOAP
oder auch HTTP/CGI-Aufrufe. Hierbei wird im ersten Fall die Interface Definition
Language (IDL) bzw. Web Service Description Language (WSDL) zur Schnittstellendefinition eingesetzt. Dabei ist die Definition der Datenstruktur ebenfalls ein Teil dieses
Standards. Das zugrundeliegende Datenmodell ist hierbei objektorientiert. Bei diesen
Techniken ist es programmiersprachenübergreifend möglich, diese Datenschemaspezifikationen direkt in Datenstrukturen der Programmiersprachen zu übersetzen. Aus diesen
kann dann wiederum direkt ein objektorientiertes Datenschema in Form von Klassen
und verschiedenen Beziehungstypen generiert werden.
Im Gegensatz dazu ist im Fall von HTTP/CGI-Aufrufen kein direkter Zugriff auf ein
Datenschema möglich. Die aus dieser Technik resultierenden Möglichkeiten beschränken
sich auf einen einheitlichen Datenzugriff, weniger auf die allgemeine Bereitstellung von
Schemainformationen. Diese müssen dann restrukturierend durch geeignete Methoden
der Datenstruktur- und darauf aufbauend der Schemaerkennung aus flat-files ermittelt
werden. Hierbei handelt es sich vielfach um HTML-formatierte Dateien, so daß gewisse Strukturierungsmerkmale durch diese Sprache genutzt werden können. Ohne an
dieser Stelle das Problem der Datenschemaableitung aus flat-files vertiefend zu behandeln, werden in der Literatur Ansätze vorgeschlagen, die sich an folgender allgemeiner
Vorgehensweise orientieren [83]:
1. Identifizierung von atomaren lexikalen Elementen
2. Erfassung der Datenstruktur durch Syntaxbeschreibung
Solche Ansätze sind Gegenstand aktueller Forschungsarbeiten und werden u. a. im
Bereich der automatischen Generierung von Wrappern in der Bioinformatik eingesetzt.
In [84, 21] ist hierzu ein Überblick entsprechender Arbeiten nachzulesen.
Ebenso wie der HTTP/CGI-Zugriff auf Datenbanken ist der direkte Dateizugriff auf
in flat-files exportierte Daten mit dem Problem der notwendigen Restrukturierung des
Datenschemas verbunden. Es ist jedoch im Falle eines direkten Dateizugriffes, wie z. B.
über FTP, üblich, Dateien bereitzustellen, die mittels etablierter Auszeichnungsspra-
53
Kapitel 3 Datenbankintegration in der Bioinformatik
chen formatiert wurden. Diese enthalten dann automatisch verarbeitbare Datenstrukturen, so wie sie im vorherigen Abschnitt 3.1.2 zu Datenformaten eingeführt wurden.
Sind explizit keine datenstrukturbeschreibenden, maschinell verarbeitbaren Daten vorhanden, so muß auch hier eine Restrukturierung vorgenommen werden. In vielen Fällen
kann aber davon ausgegangen werden, daß keine Informationen zur direkten Abbildung
der erkannten Datenstruktur auf ein Datenschema vorhanden sind. Hierzu sind bestenfalls gute Dokumentationen der Datenstruktur in Form von mit Kommentaren angereicherten Datendateien oder natürlichsprachlichen Formatbeschreibungen vorhanden.
Eine Ausnahme ist hier aber das XML-Schema [85], das direkt in XML formatierte flatfiles auf ein Datenschema abbildet. So existieren Werkzeuge, um aus XML-Dateien und
den passenden XML-Schemata automatisiert eine objektrelationale Datenbankinstanz
zu erzeugen. Es ist aber im allgemeinen in der Klasse der flat-files davon auszugehen, daß eine manuelle oder gegebenenfalls durch Werkzeuge unterstützte Nach- bzw.
Neumodellierung des jeweiligen Datenschemas notwendig ist. In Tabelle 3.3 ist diese
Klassifizierung inklusive einiger Anwendungsbeispiele zusammengefaßt.
Datenschemaklasse
DBMS
Framework
Methode
Beispiel
JDBC
ODBC
CORBA
JAVA-API
C-API
IDL
SOAP
HTTP/CGI
WSDL
Restrukturierung
FTP/HTTP
Restrukturierung
GeneOntology [62]
GeneOntology
CORBA@EBI
[86, 82]
KEGG [14]
KEGG/DBGET
[45]
UNIPROT [69]
Middleware
flat file
Tabelle 3.3: Klassifizierung von Datenschemata für molekularbiologische Datenbanken
Schnittstellen
Das Internet ist ein populäres Medium für die Bereitstellung und den Austausch von
Daten sowie den Zugriff auf Methoden. Dabei kann das Internet das volle Potential eines verteilten Informationssystems nicht ausnutzen, da es keinen allgemeinen Standard
für eine gemeinsame Schnittstelle für die Bioinformatik zur Nutzung der angebotenen
Dienste gibt. Es gibt aber Bestrebungen, Vereinheitlichung zu schaffen, wie etwa BioJava [87], BioPython [88] oder BioPerl [47].
Hierbei handelt es sich um APIs und Datenstrukturen zum Zugriff auf Datenquellen im Sinne des Abschnittes 2.3.3, die mitunter auf den weiter unten beschriebenen
Schnittstellen aufsetzen. Bei den hier genannten APIs wird eine Menge von Funktionen
oder Objekten bereitgestellt, die proprietäre Anfragen zulassen. Das Ergebnis dieser
Funktions- oder Methodenaufrufe sind Datenstrukturen der jeweils unterstützten Programmiersprache. Neben dem Zugriff auf Datenquellen ist auch die Kapselung von Bio-
54
3.1 Datenbanken in der Molekularbiologie
informatikwerkzeugen ein Bestandteil dieser APIs. So wurde z. B. BioPerl populär, da
hier eine sehr umfangreiche API zum Ausführen von diversen Bioinformatikwerkzeugen,
wie etwa BLAST [89] zur Homologiesuche über Sequenzen, enthalten ist. Die Ergebnisse dieser in Programmiersprachen eingebetteten Programmaufrufe werden geparst, da
sie als Textausgabe vorliegen und in entsprechende Datenstrukturen überführt. Nachfolgend werden derartige Ansätze im Überblick dargestellt, wobei BioPerl die zur Zeit
umfangreichste API umfaßt:
BioPerl
BioPerl ist eine Kollektion von Perl-Modulen, welche die Entwicklung von Bioinformatikanwendungen mittels Perl unterstützen sollen. Das umfaßt u. a. die
Handhabung von Sequenzen, den Zugriff auf Datenbanken mit einer Vielzahl unterstützter Datenformate und das Ausführen und Parsen der Ausgaben verschiedenster Bioinformatiksoftware. Im Anhang A.5 ist die Nutzung von BioPerl am
Beispiel demonstriert.
BioPython
Das BioPython-Projekt ist eine Sammlung von Werkzeugen und Modulen für
Python für die Bioinformatik. Dabei ist die unterstützte Funktionalität ähnlich
zu BioPerl bzw. BioJava. Im Anhang A.6 ist die Nutzung von BioPython am
Beispiel demonstriert.
BioJava
BioJava ist ein Projekt zur Bereitstellung eines Java-Frameworks zur Verarbeitung biologischer Daten. Es beinhaltet u. a. Klassen zur Bearbeitung von Sequenzen, Parser für Dateiformate, Zugriff zu diversen Datenbanken sowie umfangreiche
Routinen zu statistischen Analysen. Im Anhang A.7 ist die Nutzung von BioJava
am Beispiel demonstriert.
Neben dieser Art der Schnittstellen existieren flexiblere Methoden, die auf teils standardisierten Frameworks bzw. Industriestandards aufsetzen. Analog zur Tabelle 3.3 des
Abschnittes 3.1.2 sind zu nennen:
• JDBC
• ODBC
• CORBA
• SOAP
• CGI
Ein direkter, lesender Datenbankzugriff über SQL, wie es bei JDBC/ODBC möglich
ist, sollte zwar als Möglichkeit erwähnt werden, zeigt sich aber in der Praxis als wenig
nutzbar. Obwohl etwa die Hälfte (ca. 47%) aller in der Molekularbiologie verfügbaren Datenbanken auf einem DBMS beruhen [57], existieren nur wenige Datenbanken,
55
Kapitel 3 Datenbankintegration in der Bioinformatik
bei denen eine JDBC/ODBC-Schnittstelle angeboten wird. Vielmehr werden entweder flat-files exportiert oder Middlewarelösungen angeboten, die dann die in diesem
Abschnitt beschriebenen Schnittstellen unterstützen. Es existieren dabei vielfältig motivierte Gründe für dieses Vorgehen. Das sind u. a. Sicherheitsaspekte (Hackerangriffe
aufgrund von Systemfehlern, DoS-Angriffe6 , Datenschutz etc.), Eigentumsschutz (Patente, Datenschema, private Daten) oder technische Erfordernisse (Abschirmung des
DBMS durch eine Firewall, Kapazitätsprobleme des Netzwerkes oder des DBMS-Rechners).
Diese somit teilweise künstlich erzeugten Beschränkungen der Datenbankzugriffsmöglichkeiten motivieren einen wesentlichen Aspekt der vorliegenden Arbeit, nämlich die
beschränkten Zugriffsmuster molekularbiologischer Datenbanken. Da, wie in den späteren Kapiteln erörtert wird, die in dieser Arbeit vorgestellte Datenbankintegrationslösung einen SQL-Zugriff unterstützen soll, muß diese Zugriffseinschränkung überwunden
werden.
Die Schnittstellen CORBA [90, 86, 91, 92, 93] und SOAP [94, 82, 95, 96] erfreuen
sich bei Middlewarelösungen starken Zuspruches. In beiden Fällen werden APIs vom
Datenbankanbieter in Form von Schnittstellenbeschreibungen bereitgestellt, die dann
programmiersprachenunabhängig genutzt werden können. Bei CORBA handelt es sich
um die Interface Definition Language (IDL) und bei SOAP ist es die Web Service
Definition Language (WSDL).
Im Falle von CORBA existiert ein CORBA-Server, der die API-Aufrufe eines Clients in Datenbankaufrufe umsetzt und die Ergebnisse in die bereitzustellenden Datenstrukturen überführt und mittels eines Frameworks an den Client ausliefert. Das
Kommunikationsprotokoll ist hier das Internet Inter-ORB Protocol (IIOP). Ein ähnliches Vorgehen erfolgt bei SOAP, wobei hier in den meisten Fällen das http-Protokoll7
zur Kommunikation mit dem SOAP-Server genutzt wird. Die notwendigen Schnittstellen werden durch IDL-Dateien (CORBA) bzw. WSDL-Dateien (SOAP) definiert. Diese
dienen dann als Basis zur Erzeugung von programmiersprachenabhängigen Clientkode.
Die so vorgegebenen Zugriffsmuster auf die Daten ähneln denen der zuvor beschriebenen
programmiersprachenabhängigen APIs. In den Anhängen A.8 und A.9 sind Beispiele
für JAVA-Clients auf CORBA- bzw. SOAP-Basis aufgeführt.
Als letzte hier betrachtete Schnittstelle dient CGI. Diese einfache, aber sehr verbreitete Weise, um Daten über RPC-Aufrufe abzufragen, basiert auf dem HTTP-Protokoll.
Hierzu werden Web-URLs nach dem Muster
http://<host>/<script>?<par_1=wert_1>&...&<par_n=wert_n>
gebildet. Die Rückgabe eines solchen Aufrufes sind verbreitete Dateiformate, so wie sie
in Abschnitt 3.1.2 beschrieben sind. Diese Art des Zugriffes auf entfernte Methoden ist
zwar programmiersprachenunabhängig, stellt aber erhöhten Aufwand für die Programmierung dar. Neben fehlender maschinenlesbarer Schnittstellenbeschreibungen sind kei6
7
Deny of Service – Vorsätzliche Erzeugung hoher Last auf dem DBMS
Da der SOAP-Standard unabhängig vom zu nutzenden Transportprotokoll definiert wurde, ist das
genutzte Protokoll implementierungsabhängig.
56
3.1 Datenbanken in der Molekularbiologie
ne Datenstrukturen für die Clientprogrammiersprache vorhanden. Vielmehr muß das
durch Parsen der Resultate nachgebildet werden.
In Abbildung 3.3 sind diese Schnittstellen zusammengefaßt dargestellt.
Abbildung 3.3: Middleware-Architektur für etablierte Datenbankschnittstellen in der
Bioinformatik
Datenextraktion
Wie bereits gezeigt wurde, besteht die Notwendigkeit, Daten aus flachen Dateien zu extrahieren. Unter der Voraussetzung, daß die Struktur solcher Dateien, wie in Abschnitt
3.1.2 gefordert, vorliegt und weiterhin die lexikalen Konstrukte sowie die Syntax bekannt sind, müssen Methoden zum Parsen angewandt werden. Im Falle von standardisierten Dateiformaten, wie XML oder auch HTML, existieren vorgefertigte Parser für
alle gängigen Programmiersprachen.
Für Nicht-Standard-Dateiformate existieren Ansätze, um Parser zu generieren [83],
die bei stark dynamischen Datenformaten sinnvoll sind. In der Literatur [97] sind aber
auch Gründe bezüglich des Programmieraufwandes zur oftmals notwendigen Nachbearbeitung generierter Parser genannt, die einen manuellen Ansatz unterstützen. Solche
57
Kapitel 3 Datenbankintegration in der Bioinformatik
Ansätze bedienen sich dann grammatikverarbeitender Werkzeuge, wie LEX/YACC [98]
oder JAVACC [99], die Parser aus einer lexikalen und syntaktischen Eingabesprache erzeugen. Aufarbeitungen zu Methoden der Datenextraktion sind auch in [100] enthalten.
Da für die etablierten Dateiformate vorgefertigte Parser existieren (siehe Abschnitt
3.1.2), sind nur für Einzelfälle Parser neu zu entwickeln. Eine Auswahl existierender
Parser für diverse Programmiersprachen wird in folgender Liste gegeben:
• SIR [101]
• Swissknife [48]
• SPEM/PrEMBL [102]
• Parsen mit Python [103]
3.1.3 Datenqualität
Die in der Literatur vorgeschlagene Taxonomie von Datenbankqualitätsproblemen umfaßt im Bereich der Informatik verschiedene Problemklassen. Dabei existieren verschiedene Definitionen dieser Problemklassen zu denen in [104] ein kurzer Überblick gegeben wurde. Auch wurden im Abschnitt 2.3.4 der vorliegenden Arbeit Ausführungen zu
Datenbankintegrationskonflikten gemacht, die als Datenqualitätsprobleme eingeordnet
werden können. Aus diesen beiden Quellen lassen sich folgende Klassen von Qualitätsproblemen nennen:
• Korrektheit der Daten (Maß für den Fehlergrad der Daten)
– syntaktische Korrektheit
– semantische Korrektheit
– Datenduplikation
• Komplettheit (Maß für unvollständig belegte Attributwerte)
– Datenschemakomplettheit
– Attributkomplettheit
– Referenzierungskomplettheit
• Datenaktualität (Maß für die Aktualität zeitvariabler Daten)
• Konsistenz (Maß für die Datenintegrität)
– Wertebereichskonsistenz
– Eindeutigkeit
– referenzielle Integrität
58
3.1 Datenbanken in der Molekularbiologie
Einige dieser Probleme lassen sich durch Mechanismen von DBMS automatisch erkennen. Die allgemeine, automatische Bewertung der Datenqualität, insbesondere im Szenario einer Datenbankintegration, ist Gegenstand aktueller Forschungsarbeiten. Dabei
ist u. a. die semantische Datenqualitätsbewertung sehr komplex und nicht vollständig
automatisierbar.
Gerade die Bewertung von semantischen Qualitätsproblemen stellt in der Bioinformatik eine besondere Herausforderung dar. So ist ein Schwerpunkt zur Bewertung der
Qualität von biologischen Datenbanken die Untersuchung von der Vertrauenswürdigkeit
von Annotationen. Dabei beschreibt eine Annotation die Bestimmung der Funktion, der
Struktur oder weiterer wesentlicher phänotypischer Merkmale zum untersuchten biologischen Material, wie etwa DNA/RNA-Sequenzen, Proteine oder gesamte Organismen.
Zu diesem Zweck wurde in [105] das Genom eines Bakteriums reannotiert, um die Qualität der ursprünglichen Annotation zu werten. Bei Annotationen sind zwei Arten zu
unterscheiden: die manuelle und die automatische.
Im Fall einer automatischen Annotation werden ausgehend von einer unbekannten
DNA- oder Aminosäuresequenz ähnlichkeitsbasierte Suchanfragen über entsprechende
Sequenzen in bereits annotierten Proteindatenbanken ausgeführt [89]. Die so gefundenen Treffer“ werden manuell weiter validiert. In diesem Schritt wird die Relevanz des
”
Treffers für die Eingabesequenz auf verschiedene Arten geprüft. Das Studium der für
den Treffer zugrundeliegenden Literatur und die Überprüfung verschiedener Merkmale
der gefundenen Ähnlichkeit etc. dienen als Entscheidungskriterien, ob und wie relevant
die gefundene Annotation für die Eingabesequenz ist. Letztendlich wird die Funktion
der unbekannten Eingabesequenz aus den gefundenen Daten abgeleitet.
Ist es jedoch nicht möglich, auf diese Weise eine Funktionszuordnung vorzunehmen,
so ist diese durch experimentelle Methoden im Labor zu bestimmen. Da der Prozeß der
manuellen Annotation natürlich sehr aufwendig ist und entsprechende Ressourcen an
Personal, Laborzeiten etc. verlangt, existieren Ansätze, die den genannten Prozeß automatisch durchführen [106, 107]. Die Ergebnisse solcher Funktionsvorhersagen fließen
auch in verfügbare Datenbanken ein, wie etwa Ensembl [108] oder TrEMBL [46]. Wie
wichtig Qualitätsaussagen zu eben solchen Daten sind, ist anhand folgender, in [105]
genannter Probleme bei Genomannotationen zu sehen:
1. inkonsistente Funktionsbeschreibungen in verschiedenen Datenbanken
2. falsche Funktionszuordnung
3. unbestätigte Funktionsvorhersagen
4. willkürliche, inkonsistente Terminologie
5. typographische Fehler
6. unzureichende Benchmarkmethoden für die Fehlerrate von Annotationsstrategien
(Stichwort: gold standard“)
”
59
Kapitel 3 Datenbankintegration in der Bioinformatik
Zur Lösung dieser Probleme wurde in [109] eine Skala von Punkten zwischen 7 (schlechteste Wertung) und 0 (beste Wertung) zur Bewertung der Reproduzierbarkeit von Annotationen vorgeschlagen. Diese Skala ist in Tabelle 3.4 abgebildet. Diese Bewertungs-
Punkte
7
Beschreibung
False positive
6
Over-prediction
5
Domain error
4
False negative
3
Under prediction
2
Undefined source
1
Typographical error
0
Total agreement
Kommentar
Originalannotation sagt eine Funktion ohne
Nachweis voraus
Originalannotation sagt eine spezielle
biochemische Funktion ohne ausreichenden
Nachweis voraus
Originalannotation übersieht verschiedenartige
Domainstrukturen des gesuchten und
referenzierten Proteins
Originalannotation vermißt eine vorhergesagte
Funktion, obwohl es ausreichende Funktionsdaten
gibt
Originalannotation sagt eine unspezifische
Funktion voraus, obwohl eine detailliertere
Vorhersage gemacht werden könnte
Originalannotation enthält undefinierte Begriffe,
nicht-homologie basierte Vorhersagen, etc.
Originalannotation enthält typographische Fehler,
die propagiert werden können
Originalannotation ist korrekt, wobei die
Annotationen nur semantisch identisch sein
müssen
Tabelle 3.4: Qualitätsskala für Annotationsreproduzierbarkeit in Datenbanken (TABS)
skala und weitere, wie etwa in [110], werden zur Zeit in den Datenbanken nur selten
unterstützt, so daß ein allgemeingültiger Qualitätsstandard noch nicht existiert. Wenn
man bedenkt, daß viele Datenbanken kaskadierend aufeinander aufbauen und sich so
fehlerhafte Daten schnell verbreiten können [110], wäre die Umsetzung dieser oder ähnlicher Bewertungsskalen als direkter Bestandteil in den Datenbanken sehr vorteilhaft.
Denn wie Abbildung 3.4 zeigt, existieren Annotationen von Genomen, bei denen nach
manueller Überprüfung der Originalannotation etwa 63% korrekte Einträge bestätigt
worden [105]. Es wurden Ansätze vorgeschlagen, diese Datenqualitätsskalen in Datenbanken zu berücksichtigen, wie etwa in Form des Attributes evidence“ in der DTD der
”
UniProt-Datenbank (siehe Anhang A.4).
60
3.2 Integration molekularbiologischer Datenbanken
Abbildung 3.4: Einordnung der Annotationsfehler für 398 Gene des Chlamydia trachomatis Genoms aus [105]
3.2 Integration molekularbiologischer Datenbanken
Aus der Motivation heraus, die weltweit verfügbaren Daten zu bündeln, um daraus gezielt Nutzen für die Erforschung von Zusammenhängen in der Molekularbiologie ziehen
zu können, ist es notwendig, existierende Datenbanken zu integrieren. Zur gezielten
Nutzung der vorhandenen Datenbanken ist eine Schnittstelle zu schaffen, die Heterogenitäten und Datenfragmentierungen überwindet. Eine so mögliche gesamtheitliche Sicht
wird durch verschiedenste Anforderungen und Visionen motiviert, wie sie etwa in [111]
oder [112] zu finden sind. Aus der Motivation der Arbeit und den zuvor vorgestellten
Eigenschaften molekularbiologischer Datenbanken ergibt sich ein spezieller Fokus, der
sich in folgenden Kernforderungen zusammenfassen läßt:
1. ausschließlich lesender Zugriff auf die Datenquellen
2. Schemaintegration auf globaler Schemaebene
3. für automatische, globale Datenanfragen geeignetes einheitliches Datenmodell
4. Unterstützung beschränkter Zugriffsmuster auf Datenquellenebene
Dabei ist zu beachten, daß hier von einer nur-lesenden“ Datenbankintegration aus”
gegangen wird. Das impliziert, daß Änderungsoperationen auf den Komponentendatenbanksystemen im Kontext des Zugriffes durch eine Datenbankintegrationssoftware
nicht zulässig sind. Somit müssen Probleme der Datenbankintegration aus Sicht der
neun Codd‘schen Regeln für Datenbankmanagementsysteme aus Abschnitt 2.2.1, wie
61
Kapitel 3 Datenbankintegration in der Bioinformatik
etwa die Behandlung von Transaktionen, Konsistenzwahrung, Dauerhaftigkeit von Datenänderungen oder Datensicherungen auf Integrationsebene nicht beachtet werden.
Folglich ist auch die Anzahl der zu unterstützenden Datenoperationen eingeschränkt.
Weiterhin sollen Datenquellen integriert werden können, die nur über sehr einfache
Schnittstellen verfügen, also beschränkte Zugriffsmöglichkeiten aufweisen. Dazu gehören
insbesondere die zuvor in Abschnitt 2.2.5 betrachteten Gegebenheiten molekularbiologischer Datenquellen.
In den folgenden Abschnitten werden in diesem Kontext Untersuchungen zu Ansätzen
der Datenbankintegration in der Bioinformatik gemacht.
3.2.1 Architekturen
Das Literaturstudium zu Architekturen und Techniken der Datenbankintegration zeigt
in den Gebieten Informatik und Bioinformatik, daß zum einen verschiedene Begriffe
und zum anderen unterschiedliche Merkmale zur Klassifizierung der Ansätze zur Datenbankintegration genutzt werden. Aus dieser Motivation heraus sollen am Anfang
dieses Abschnittes Einordnungen von Datenbankintegrationsarchitekturen und daraus
resultierende Techniken kurz eingeführt werden.
In [43] werden vier Integrationsansätze in der Bioinformatik beschrieben. Das Szenario einer Interaktion mit einer Menge heterogener molekularbiologischer Datenbanken
zum Sichten des Datenbestandes, zur Informationsgewinnung, zur Formulierung komplexer Anfragen oder zur Datenanalyse und Simulation stützt sich zur Zeit auf vier
technische Umsetzungen. In Tabelle 3.5 sind diese mit den äquivalenten Techniken aus
dem Bereich der Informatik und entsprechenden Beispielsystemen dargestellt.
Begriff Bioinformatik
Hypertextnavigation
Einordnung Informatik
Integration mittels Gateways
Data Warehouse
Staging Areas in Data
Warehouses
Multidatenbankanfragesprachen
Multidatenbankanfragesprachen
Mediatortechniken
Mediatoren
FDBS
FDBS
Beispielsystem
KEGG [113]
SRS [114]
PEDANT [115]
HUSAR [116]
BioKleisli/K2 [117]
OPM [118]
Multiagents [119]
BioMoby [120]
DAS
DiscoveryLink [121]
Tabelle 3.5: Klassifizierung von Integrationsansätzen
Neben den angesprochenen Integrationstechniken und der Einordnung in die Taxonomie der Multidatenbanksysteme in Abschnitt 2.3.1 lassen sich die Ansätze zur Datenbankintegration nach Klassifizierungsmerkmalen aus dem Bereich der Bioinformatik
einordnen, die sich als Hauptunterscheidungskriterien in der Praxis etabliert haben. Zu
62
3.2 Integration molekularbiologischer Datenbanken
beachten ist hierbei insbesondere, daß etablierte Kriterien aus der Informatik, wie etwa die neun Regeln aus Abschnitt 2.2.1 keine Praxisrelevanz haben. Eine Begründung
hierzu ist der Umstand, daß die Datenbankintegration von nicht änderbaren Komponentendatenbanken ausgeht, also nur lesend zugreift. Nach [122] sind das zwei Kriterien:
der Grad der Integration und die Materialisierung der Daten:
Grad der Integration
Der Grad der Integration beschreibt den Umfang von Integrationsaufgaben, die
gelöst wurden. Dazu zählen der Grad der Schemaintegration, der Datentransformationen, semantische Datenverbindungen etc. Auf dieser Grundlage werden
Integrationsansätze in lose und eng gekoppelte Varianten unterschieden.
Materialisierung der Daten
Diese Eigenschaft beschreibt den Grad der Datenmaterialisierung. Zum einen
kann eine physikalische (materialisierte) Kopie der Daten verwendet werden und
zum anderen verbleiben die zu integrierenden Daten physikalisch in den jeweiligen Datenbanksystemen. Im letzten Fall werden Datenanfragen von der Integrationssoftware in Teilanfragen verteilt und somit eine virtuelle integrierte nicht
materialisierte Sicht auf den zu integrierenden Datenbestand erzeugt.
Auf der Basis der eingeführten Klassifikationsmerkmale lassen sich die genannten Ansätze zur Integration molekularbiologischer Datenbanken anhand ihrer Eigenschaft im
Bezug zur Bioinformatik systematisieren. Dazu wurden in [58] detaillierte Betrachtungen vorgenommen, die in folgendem Kriterienkatalog zusammengefaßt wurden:
• Systemarchitektur
– FDBS
– Mediatoren
– Multidatenbankanfragesprachen
– Data Warehouses
• Technische Kriterien
– Grad der Integration
– Materialisierung der Daten
• Subjektive Bewertung
– Internetfähigkeit
– Programmiersprachenanbindung
– Ausgabeformate
– Flexibilität
– Unterstützung von Informationsfusion
63
Kapitel 3 Datenbankintegration in der Bioinformatik
In der zugrundeliegenden Arbeit wurden anhand obiger Kriterien existierende Integrationsansätze der Bioinformatik klassifiziert. Dieser Katalog soll zur Bewertung und
Einordnung von Datenbankintegrationssysteme dienen. Weitere Informationen zu diesem Bewertungssystem sind in der genannten Publikation zu finden.
3.2.2 Stand der Technik
Neben der, einem Datenbankintegrationssystem zugrundeliegenden, Architektur spielt
vor allem die Umsetzung in Form konkreter Systeme eine Rolle. Den Anforderungen,
die zu den jeweiligen Implementierungen führen, ist gemein, daß erstens eine möglichst
große Anzahl verschiedener Datenformate und Anfrageschnittstellen auf Seite der Datenquellen unterstützt werden sollte und zweitens ein breites Spektrum von unterstützten Klienten bzw. Anfragesprachen und -schnittstellen gewährleistet werden muß. Dies
trägt dem Grundgedanken Rechnung, daß eine Datenbankintegration für bestehende
Bioinformatikanwendungen entwickelt wird und nicht bestehende Software auf die Integrationslösung portiert werden muß. Das Konzept wird in Abbildung 3.5 verdeutlicht.
Die zuvor genannten Architekturen und Methoden zur Datenbankintegration in der
Abbildung 3.5: Szenario der Datenbankintegration in der Bioinformatik aus [123]
Bioinformatik werden durch verschiedene, im praktischen Einsatz befindliche System
umgesetzt. Dabei werden im folgenden vor allem Systeme vorgestellt, die in der Bioinformatik tatsächlich Anwendung finden und auch als Implementierung zur Verfügung
stehen. Folgende Erörterungen zu den einzelnen Systemen stellen einen Überblick und
weniger eine systematische Einordnung und Bewertung dar, da die Systeme oftmals
hybrider Natur sind und notwendige weitere Untersuchungen der Implementierungen
über die Zielstellung der vorliegenden Arbeit hinaus gehen würden. Vielmehr wird eine
64
3.2 Integration molekularbiologischer Datenbanken
Auswahl von Systemen als Repräsentanten vorherrschender Techniken dargeboten. Eine weitaus umfangreichere Aufarbeitung existierender Datenbankintegrationssysteme
im Umfeld der Bioinformatik ist etwa in [124] zu finden.
3.2.3 Sequence Retrieval System
Die sicherlich populärste und bekannteste Datenbankintegrationsplattform ist das kommerzielle Sequence Retrieval System (SRS) [114, 125] der Firma LION Bioscience AG.
Prinzipiell handelt es sich um mit Indexen angereicherte flat-files, die als Kopie im
Dateisystem des SRS-Servers vorliegen müssen und durch entsprechende Skripte aktualisiert werden, d. h. mittels FTP oder HTTP von der Originaldatenquelle kopiert
werden. Zur Indizierung existieren in der eigens entwickelten Sprache Icarus Parser, die
für jedes flat-file-Format implementiert werden müssen.
Die Attribute der so zu parsenden Datenbank werden durch das Icarus-Script spezifiziert und somit die Datenstruktur manuell nachgebildet. Aus den so für ein Attribut
extrahierten Attributwerten wird jeweils ein Index berechnet, der ebenfalls im Dateisystem des SRS-Servers abgelegt wird. Neben der Indizierung von flat-files existiert auch
die Option, relationale DBMS als Datenquelle anzubinden. Dabei werden die Indexe
aus dem DBMS abgeleitet.
Im nächsten Schritt werden zu den einzelnen, indizierten Datenbanken, ebenfalls
mittels der implementierten Icarus Scripte Querverweise, berechnet. Dabei werden zu
den bereits indizierten referenzierten Datenbanken Verweise eingefügt. Diese können
dann genutzt werden, um navigierend auf Attribute separater Datenbanken zuzugreifen.
Die Anfragemöglichkeiten vom SRS sind mit Multidatenbankanfragen zu vergleichen,
wobei die Möglichkeit von Joins nicht gegeben ist. Das heißt, es ist nur möglich, die
Komponentendatenbanken einzeln, nacheinander abzufragen. Für solche Anfragen
sind Projektions- und Selektionsanfragen mit dem Gleichheitprädikat zulässig, das
einen Vergleich eines Attributs mit einer Konstanten implementiert. Hierzu zulässige
Attribute sind nur diejenigen, für die ein Index angelegt wurde oder das virtuelle
Attribut alltext, was eine Volltextsuche über alle Attribute zuläßt. Beispielsweise
lautet eine Abfrage, die alle Autoren (aut) und die Publikationstitel (tit) der
UNIPROT-Datenbank extrahiert, wobei der Organismus Hordeum vulgare“ (Gerste)
”
ist:
getz -vf "aut tit" ’[UNIPROT_SWISSPROT-organism:Hordeum
vulgare]’
Darüber hinaus bietet SRS drei logische Operatoren AND, OR und BUTNOT zur
Kombination von Selektionsanfragen. Das folgende Beispiel ergänzt das vorige mit der
Alternative, daß der Organismus gleich Pisum sativum“ (Erbse) ist:
”
getz -vf "aut tit" ’[UNIPROT_SWISSPROT-organism:Hordeum
vulgare]OR[UNIPROT_SWISSPROT-organism:Pisum sativum]’
Die zuvor berechneten Querverweise sind die Basis für den link-Operator < bzw. >.
So berechnet der Operation A > B all die Datenbankeinträge aus der Datenbank
65
Kapitel 3 Datenbankintegration in der Bioinformatik
B, die in Datenbank A direkt oder indirekt referenziert werden. Indirekte Referenzen
werden durch transitive Verbindungen über mehrere Datenbanken gebildet, wobei ein
Datenbankeintrag ein Knoten in einem Netzwerk von Datenbanken bildet. Die dafür
genutzte Methode ist in der Literatur unzureichend beschrieben. So berechnet der
folgende Ausdruck alle Datenbankeinträge zu Hordeum vulgare“ aus der Datenbank
”
UNIPROT SWISSPROT, die zur Datenbank EMBLRELEASE Verbindungen haben:
getz ’[UNIPROT_SWISSPROT-organism:Hordeum vulgare] >
EMBLRELEASE’
Durch Konkatenation der Operatoren ist es auch möglich, Pfadausdrücke zur Suche
von Datenquerverbindungen anzugeben, um notwendigerweise zu besuchende Knoten
im Datenbanknetzwerk im Algorithmus zu definieren.
Neben dem in den Beispielen vorgestellten Kommandozeilenwerkzeug existiert eine
Web-Server-Implementierung, die formularbasierte Datenanfragen und deren Ergebnisse graphisch darstellt. Eine breite Unterstützung von Programmiersprachen ist ebenfalls
gegeben. Dazu zählen eine C-API, eine JAVA-API sowie eine CORBA-Schnittstelle [90].
3.2.4 PEDANT/BioRS
Im Kontext eines Frameworks zur Anwendungsintegration ist das PEDANT-System
[107], das zum Teil kommerziell von der Firma Biomax Informatics AG vermarktet
wird, zu nennen. Da hier zwar keine Datenbankintegration im Sinne der vorliegenden
Arbeit umgesetzt wird, aber es dennoch eine Integration von strukturell und funktionell
aufbereiteten Sequenzdaten verschiedener Organismen aus verschiedenen Datenquellen
ist, soll PEDANT an dieser Stelle kurz genannt werden. Das Ziel des Systems ist es,
eine Plattform zur funktionalen und strukturellen Analyse von Sequenzdaten bereit
zu stellen. Vorhandene Bioinformatikwerkzeuge werden angewandt, um zu analysierende Sequenzdaten auf funktionale und strukturelle Eigenschaften zu untersuchen. Dazu
gehören u. a. Homologiesuche in bereits annotierten Proteindatenbanken oder die Erkennung von Sequenzstrukturmustern, die eine Funktionsdomäne vermuten lassen. Die
Ergebnisse dieser und weiterer Analysen werden zum Teil manuell nachbearbeitet und
in einem RDBMS strukturiert für weitere Analysen gespeichert. Der Zugriff auf die
angesprochenen Werkzeuge erfolgt durch Wrapper, die mittels Parser die Ergebnisse
der Berechnungen extrahieren. Diese extrahierten Daten werden dann über eine Middleware anhand eines vorgefertigten relationalen Datenschemas strukturiert und in eine
entsprechende Datenbank gespeichert.
Im Zusammenhang mit PEDANT existiert ein kommerzielles Produkt namens BioRS
[126]. In den Produktinformationen im WWW wird von einem System zur Anfrage von
Daten aus öffentlichen, proprietären Datenbanken gesprochen, das neben flat-files auch
auf RDBMS zugreifen kann. Als Schnittstellen zum System sind neben einer interaktiven WWW-Oberfläche auch ein CORBA-Dienst und eine Anfragesprache vorhanden,
die auf einfachen Prädikaten und einer logischen Verknüpfung über AND, OR sowie
NOT beruht. Ähnlichkeiten zum SRS-System aus Abschnitt 3.2.3 sind vorhanden. Die
66
3.2 Integration molekularbiologischer Datenbanken
Systemarchitektur, so wie sie auf den WWW-Seiten des Unternehmens zu finden ist,
wird in Abbildung 3.6 dargestellt.
Abbildung 3.6: Systemarchitektur von BioRS aus [126]
3.2.5 DiscoveryLink
In einem von der Firma IBM unterstützten Forschungsprojekt wurde ein FDBS namens DiscoveryLink [121] entwickelt. Die grundlegende Architektur beruht auf einer
zentralen Föderierungsschicht, die über Wrapper auf Datenquellen zugreift. DiscoveryLink nutzt das relationale Datenmodell sowie die relationale Algebra. Somit wird SQL
als Anfragesprache unterstützt. Abbildung 3.7 zeigt die Systemarchitektur von DiscoveryLink. Das System ist in das RDBMS DB2 der Firma IBM eingebettet und bietet
somit den vollen Umfang von Anfragesprachen und Schnittstellen, sowie die bekannten
Standardfunktionen eines DBMS.
Eine SQL-Anfrage wird vom System bearbeitet, indem (1) relevante Datenquellen
ausgewählt werden, (2) ein optimaler Ausführungsplan generiert wird, die originale
Anfrage in Teilanfragen aufgebrochen wird, die zu den entsprechenden Datenquellen
weitergeleitet werden. Und (3) werden dem Anfrageplan notwendige Ergänzungen zugefügt, die von den Datenquellen nicht unterstützte relationale Operationen und Prädikate nachbilden.
67
Kapitel 3 Datenbankintegration in der Bioinformatik
WRAPPERS
SQL API
(JDBC/ODBC)
LIFE
SCIENCE
APPLICATION
DATABASE
MIDDLEWARE
ENGINE
CATALOG
DATA
SOURCE
DATA
DATA
SOURCE
DATA
DATA
Abbildung 3.7: Systemarchitektur von DiscoveryLink aus [127]
Die Kernaufgabe der Anbindung der Datenquellen fällt den Wrappern zu, die vier
Kernaufgaben in dieser Architektur zu erfüllen haben:
1. Überführung des Datenmodells der Datenquelle in das relationale Datenmodell
2. Informationen zu den, von der Datenquelle unterstützten Operationen und Prädikaten
3. Transformation der Teilanfragen in relationaler Algebra in die native Anfrageschnittstelle der Datenquelle
4. Ausführung und Kontrolle von Anfragen und die Resultatzusammenstellung
Die implementierten Wrapper liegen als C-Bibliotheken vor und werden über spezielle
SQL-DDL-Anweisungen am Integrationssystem angemeldet:
CREATE WRAPPER PROTEINDBWRAPPER LIBRARY ’libuniprot.a’;
Nachdem ein Wrapper so am System angemeldet ist, wird eine Datenquelle ebenfalls
über SQL-DDL erstellt:
CREATE SERVER PROTEINDB WRAPPER PROTEINDBWRAPPER
OPTIONS(NODE ’data.bigpharma.com’,
PORT ’2004’, VERSION ’3.2b’);
Über sogenannte NICKNAMES wird das Datenschema jeder Datenquelle erstellt. Dabei
ist eine Verwandtschaft zu der CREATE TABLE Anweisung von SQL festzustellen:
68
3.2 Integration molekularbiologischer Datenbanken
CREATE NICKNAME PROTEINS (
PROTEIN_ID VARCHAR(30) NOT NULL,
NAME VARCHAR(60),
FAMILY VARCHAR(256),
DISEASES VARCHAR(256)
) SERVER PROTEINDB;
Als Erweiterung ist es möglich, nutzerdefinierte Funktionen zur Nutzung spezieller, von
einer Datenquelle angebotene Funktionen, anzulegen.
Über die Spezifikation von Parametern zu einzelnen Wrappern kann der Umfang
der unterstützten Anfrageoperationen, wie z. B. Joins oder Prädikate, wie etwa <, >,
= zur Anfrageplangenerierung angegeben werden. Das mindestens zu unterstützende
Anfragefragment wird mit:
SELECT <projektionsliste> from <nickname>
angegeben. Fehlende Fähigkeiten eines Wrapper müssen dann vom Integrationssystem
nachgebildet werden.
Weiterhin wird ein Kostenmodell genutzt, das für jede Operation eines Wrappers
die zu erwartende Komplexität angibt. Komplexitätsmaße sind u. a. die CPU-Zeit als
relatives Maß zum DiscoveryLink-Server oder I/O-Operationen. Auf dieser Basis werden alle möglichen sowie gültigen alternativen Anfragepläne generiert und derjenige
ausgewählt, der die geringsten Gesamtkosten hat.
3.2.6 BioKleisli/K2
Das 1997 im Rahmen des Human Genome Project“ an der University of Pennsylvania
”
entwickelte Datenbankintegrationssystem BioKleisli [117] basiert auf einem Ansatz, der
auf Sichten beruht. Mittlerweile existiert ein auch kommerziell von der Firma geneticXchange vermarkteter Nachfolger namens K2/Kleisli [123, 128]. Beide Systeme basieren
auf der eigens entwickelten Anfragesprache Collection Programming Language“ (CPL)
”
in Kombination mit Datenbankwrappern, den sogenannten data driver“. Diese Treiber
”
sind individuell implementierte Wrapper, die zum einen Zugriffshomogenisierung der
anzukoppelnden Datenquellen besitzen und zum anderen die Datenformate der Anfrageergebnisse in die notwendige Datenstruktur von K2/Kleisli überführen. Somit sind
die Wrapper von den Zugriffsmöglichkeiten der Datenquellen abhängig. Die Gesamtarchitektur des Systems ist in Abbildung 3.8 dargestellt.
Im folgenden wird auf einige Komponenten aus der Systemarchitektur eingegangen.
Die Anfragesprache CPL beruht auf einem eigens entwickelten Datenmodell, das Mengen komplexer Werte in Form von Mengen, Listen, Multimengen typisiert und in den
intern verwendeten nested relational calculus“ (NRC) [129] überführt wird. Basisdaten”
typen sind bool, string und int. Mittels einer entsprechenden Modellierungssyntax
werden diese Typen für jede Datenanfrage in Form einer Sicht erstellt. Die Werte zu
den so dynamisch modellierten Datenstrukturen werden mittels Datenzugriffsfunktionen ermittelt. Diese Funktionen werden von den genannten data driver“ zur Verfügung
”
gestellt und durch den Driver Manager“ verwaltet.
”
69
Kapitel 3 Datenbankintegration in der Bioinformatik
CPL-Kleisli
Type
Module
Drivers
Driver
Manger
pipe
Net
Remote
Servers
Sybase
GSDB
ASN.1
CPL
NRC
Complex
Object
Library
OPM
shared
memory
Optimizer
GenBank
ACeDB
GDB
Primitiv
Manager
BLAST
NCBI-BLAST
Abbildung 3.8: Systemarchitektur von BioKleisli aus [117]
Eine Erweiterung zu BioKleisli ist K2. Ausgehend von CPL wird eine OQL-Anfragesprache angeboten, wobei die zuvor genannten Datenzugriffsfunktionen, vordefiniert
in OQL, eingebettet zur Verfügung stehen. Ebenso wie CPL wird OQL in den NRC
transformiert.
Die Datenbankzugriffsfunktionen werden mit einer Parameterliste aufgerufen und liefern die Resultate in Form von OQL-unterstützten Datentypen. Es existieren sowohl
eine Anzahl von Treibern für populäre molekularbiologische Datenbanken als auch zur
Anbindung von Bioinformatikwerkzeugen. Ein Beispiel ist der Treiber für die über das
Entrez-System zugänglichen Datenbanken (vergleiche hierzu Abschnitt 3.2.7). Hier existiert z. B. eine Funktion zur Abfrage von Daten der PubMed-Datenbank get-medline”
substances“:
define get.medline-substances(pmid) as
entrez("-g " ||pmid|| " -d m
-r Entrez.back.getmle.data.E.substance.E.name")
Der Aufruf dieser Funktion liefert eine Liste aller Substanzen aus der PubMed-Datenbank mittels des Entrez-Systems [130], die zu einer gegebenen PubMed-ID (pmid)
zugeordnet sind:
list("Heparin",
"Complement 3d",
...
"clusterin")
70
3.2 Integration molekularbiologischer Datenbanken
Auf diese Weise können OQL-Anfragen formuliert werden, die Informationen aus mehreren Datenquellen abfragen und zu einem Anfrageergebnis z. B. mittels Joins vereinigen. Es ist also notwendig, die Anfrageverteilung und Daten- bzw. Schemaintegration
in der Anfrage selbst zu spezifizieren. Dabei analysiert der Optimierer die OQL-Anfrage, schreibt Teile gegebenfalls um, die nicht direkt von den Treibern unterstützt
werden. Diese werden dann lokal vom Laufzeitsystem ausgeführt. Desweiteren werden vom Optimierer Ersetzungsregeln für Operationen, wie mehrfach nested loop“
”
für Joins, zusammengefaßt oder nicht benötigte Attribute erkannt und durch zusätzliche Projektionen entfernt. Ein Hauptziel ist die Reduzierung von Zwischenergebnissen.
Darüber hinaus ist es auch möglich, nutzerspezifische Sichten zu definieren, die somit
vorgefertigte Datenbankintegrationsanfragen umsetzen. Dazu wird die Sprache K2MDL
angeboten. Somit ähnelt Kleisli/K2 der Technik der Multidatenbankanfragesprachen.
Aussagen zu den unterstützten Schnittstellen konnten nur unzureichend in der Literatur gefunden werden. Es ist aber anzunehmen, daß die für OODBMS üblichen
Bindungen, wie CORBA oder entsprechende APIs, verfügbar sind.
Als aufgesetzte Data-Warehouse-Komponente zu Kleisli/K2 existiert eine Datenbank
namens Genomics Unified Schema“ (GUS). Das zentrale Dogma der Molekularbiologie
”
(DNA → RNA → Protein) wird hier in einem relationalen Schema von über 180 Tabellen modelliert. Die entsprechenden Daten werden inklusive Versions- und Quellinformationen mittels K2/Kleisli in ein RDBMS importiert. Über eine spezielle Updatestrategie
werden bei Änderungen oder Erweiterungen zu den im Data Warehouse importierten
Daten inkrementelle Imports durchgeführt.
3.2.7 Andere
An dieser Stelle sollen weitere bekannte Systeme zur Datenbankintegration vorgestellt
werden, die in den vorherigen Abschnitten nicht detailliert erörtert wurden, da sie
entweder nicht implementiert wurden oder technisch auf den vorgestellten Systemen
basieren oder wenig Eigenschaften eines Datenbankintegrationssystem besitzen. Die
Nutzung dieser Systeme ist nichtsdestotrotz in der Bioinformatik populär.
Ein Vertreter der materialisierten Datenbankintegration auf Grundlage von Indizierungen ist neben dem vorgestellten SRS-System aus Abschnitt 3.2.3 Entrez [130]. Das
vom National Center for Biotechnology Information (NCBI) in den USA genutzte System nutzt lokal gespeicherte flat-files, die indiziert werden und über eine WWW-basierte Schnittstelle angefragt werden können. Im System sind nur Datenquellen des
NCBI integriert. Verbindungen unter den flat-files existieren in Form von Datenbankquerverweisen. Datenanfragen sind über proprietäre Anfragesprachen, ähnlich der des
SRS-Systems zu spezifizieren. Eine Schemaintegration, selbst in Form von Views wie
bei SRS, findet nicht statt. Die Ausgabeformate reichen von HTML über ASN.1 bis zu
XML.
Vom Deutschen Krebsforschungszentrum in Heidelberg (DKFZ) wird ein System mit
dem Namen HUSAR (Heidelberg Unix Sequence Analysis Resources) angeboten. Im
ursprünglichen Sinne handelt es sich hier um ein Framework zur Anwendungsintegration. Eine Vielzahl von Datenquellen sind u. a. über eine lokal installierte SRS Instanz
71
Kapitel 3 Datenbankintegration in der Bioinformatik
den über 250 Bioinformatikanwendungen homogen zugänglich gemacht worden. Mittels einer graphischen X-Windows-Nutzeroberfläche [116] und einer WWW-Benutzerschnittstelle W2H [131] können die angebotenen Werkzeuge genutzt und miteinander
gekoppelt werden.
Eine im Zusammenhang mit dem Kleisli/K2-System populär gewordene Datenbankintegrationslösung ist TAMBIS (Transparent Access to Multiple Bioinformatics Information Sources) [60]. Auf der Datenbankintegrationskomponente K2/Kleisli wurde eine ontologiebasierte Datenschemaintegrations- und Anfrageformulierungskomponente
aufgesetzt. Im wesentlichen besteht das Gesamtsystem aus fünf Teilkomponenten: einer Ontologie biologischer Konzepte, die eine semantische Schemaintegration der über
Kleisli/K2 bereitgestellten Datenquellen umsetzen soll. Datenanfragen werden über graphische Nutzerschnittstellen in Form von JAVA-Applets über eine wissensbasierten Anfrageformulierungsschnittstelle gestellt. Somit soll der Nutzer von der notwendigen manuellen Datenschemaintegration in Form der Multidatenbankanfragesprache CLP des
Kleisli-Systems entkoppelt werden. Vielmehr bedient er sich einer explorativen Suche
in der angebotenen Ontologie nach gewünschten Konzepten, zu denen Daten aus den
hierzu in Beziehung stehenden Datenquellen automatisch über eine generierte CPLAnfrage angefragt werden.
Die zuvor vorgestellten Systeme zur Datenbankintegration wurden im Kontext der
Bioinformatik ausgewählt. Natürlich existieren weitere, nicht in der Bioinformatik motivierte Datenbankintegrationssysteme. Besonders auf dem Gebiet der sichtenbasierten
Integration bzw. der heterogenen Multidatenbanksysteme existieren einige Forschungsprojekte und auch kommerzielle Produkte.
Dazu gehört das Projekte TSIMMIS [132], welches Datenbankkonzepte und nichtprozedurale Spezifikationen nutzt, um eine Mediatoren-Wrapper Architektur zu implementieren. Das Projekt Pegasus [133] setzt ein FDBS-nahes System um. Dabei wird
ein eigenes Datenmodell und eine eigene Anfragesprache benutzt, welche ähnlich dem
K2/Kleisli-System aus Abschnitt 3.2.6 auf einem funktionalen Objektmodell basieren,
das eine große Flexibilität hinsichtlich der Modellierung und Anbindung von Datenquellen bietet.
Garlic [134, 127] wird als das erste Datenbankintegrationsprojekt bezeichnet, das
die volle Ausdrucksstärke und den Funktionsumfang von RDBMS offeriert. Basis ist
das von der Firma IBM entwickelte Datenbanksystem DB2. Zur Unterstützung einiger
objektorientierter Eigenschaften wurde die Anfragesprache erweitert. Die entwickelte
Wrapper-Architektur sowie die datenquellenübergreifenden Anfrageoptimierungen flossen direkt in Produkte von IBM ein. So wurde der DB2 DataJoiner als kommerzielles
Produkt entwickelt, der ein FDBS implementiert, das die Föderierung von relationalen
Komponentendatenbanksystemen realisiert. Garlic und der DataJoiner sind Vorläufer
für das IBM-Produkt DiscoveryLink, welches in Abschnitt 3.2.5 beschrieben wurde.
Das Konzept von Wrappern zur Einbettung von relationalen Komponentendatenbanksystemen in kommerzielle RDBMS wird auch von der Firma ORACLE mit dem
Produkt ORALE9i unterstützt. Hier werden über sogenannte Datenbank-Links Verknüpfungen zu über ODBC zugreifbare DBMS hergestellt. Dazu müssen Verbindungsaliase erstellt werden, die u. a. den ODBC-Treibernamen und die Verbindungsparameter
72
3.3 Resümee
enthalten. Darüber hinaus ist ein Zugriff auf tabellarische, im CSV-Format vorliegende
flat-files möglich. Mit der SQL-Schnittstelle von ORACLE9i kann dann auf die jeweiligen Datenbank-Links zugegriffen werden. Im folgenden Beispiel wird ein Link zu einer
entfernten Tabelle einer ORACLE9i-Datenbank als Datenbankobjekt angelegt und mittels SQL angefragt:
CREATE DATABASE LINK my_remote_schema
CONNECT TO remote_user
IDENTIFIED BY remote_password
USING ’remote_database’;
select * from remote_table@my_remote_schema;
Neben diesen genannten Integrationslösungen existieren weitere Systeme. Eine nützliche
Zusammenfassung und Bewertung der in der vorliegenden Arbeit vorgestellten und
weitere Systeme findet der interessierte Leser in [124, 58].
3.3 Resümee
In diesem Kapitel wurde eine Analyse von molekularbiologischen Datenbanken und
von existierenden Lösungen zur Datenbankintegration in der Bioinformatik durchgeführt. Dabei wurden im ersten Teil spezifische Gegebenheiten öffentlicher Datenbanken mit besonderem Fokus auf die angebotenen Schnittstellen und Datenformate sowie
die charakterisierenden Eigenschaften der so angebotenen Daten untersucht. So wurde
festgestellt, daß die Daten in Hinsicht auf datenbankübergreifende, eindeutige Identifikatoren, Qualitätskriterien und in der Vereinheitlichung befindliche Datendomänen ein
hohes Integrationspotential besitzen. Weiterhin wurden drei Typen von verfügbaren
Datenbankschnittstellen klassifiziert. Das Resultat war die Erkenntnis, daß für eine in
der Praxis anwendbare Datenbankintegrationslösung im allgemeinen keine Standardschnittstelle genutzt werden kann. Vielmehr existieren in Form der möglichen Zugriffsmuster teilweise starke Beschränkungen der angebotenen Funktionalität.
Im Mittelpunkt des zweiten Teils des Kapitels stand die Untersuchung von im Umfeld
der Bioinformatik vorgeschlagenen Methoden zur Datenbankintegration. Dabei wurde
der Bezug zu den zuvor erarbeiteten Anforderungen an praxistaugliche Datenbankintegrationssysteme hergestellt. Nach einer allgemeinen Klassifikation von Integrationsarchitekturen bezüglich ihrer Eigenschaften wurde der Stand der Technik anhand repräsentativer, in der Praxis eingesetzter Systeme vorgestellt. Insbesondere wurden die
jeweils genutzten Methoden zum Zugriff auf die Komponentendatenbanken und der
angebotene Funktionsumfang der Anfragesprachen betrachtet. Die Analyse dieser Systeme und die sich in der Anwendung ergebenen Probleme ergab die Motivation für
die Entscheidung, eine Mediatorarchitektur als Grundlage für das in der vorliegenden
Arbeit vorgeschlagene, konzipierte und implementierte Datenbankintegrationssystem
einzusetzen.
73
Kapitel 4
Ansatz zur Integration
molekularbiologischer Datenbanken
Motiviert durch die Erkenntnisse aus Kapitel 3 ist die Annahme zu treffen, daß der
Zugriff auf biologische Datenquellen in Form von Datenbanken oder unter der Nutzung
von Datenbankintegrationssystemen in vielen Fällen beschränkten Zugriffsmustern unterliegt. Dies macht eine Abstraktion über gegebene Anfragesprachen, Schnittstellen
und Datenmodelle notwendig. Das Ziel ist ein homogener Datenzugriff im Kontext limitierter Zugriffsschnittstellen und Anfragesprachen zur mediatorbasierten Datenbankintegration.
Neben der eher technischen Herausforderung der Homogenisierung von Schnittstellen ist die Homogenisierung von Anfragesprachen bzw. Anfrageoperationen eine Kernanforderung an die Datenbankintegration in der Bioinformatik. Eine entscheidende
Voraussetzung ist deshalb ein kanonisches Datenmodell verbunden mit, für alle Datenquellen gültigen, Operationen zum Datenzugriff. Ziel ist ein integrativer Zugriff
auf Datenquellen mit heterogenen Datenmodellen, Anfragesprachen und Schnittstellen. Da zur Akzeptanz und Verwendbarkeit eines Datenbankintegrationssystems durch
existierende Bioinformatikanwendungen die Unterstützung von komplexen, deklarativen Datenbankanfragesprachen wie SQL gehört, muß das gewählte Datenmodell auf
das relationale abbildbar sein. Somit ist ein Kompromiß zwischen den gegensätzlichen
Annahmen zu finden, so daß
(a) jede zu integrierende Datenquelle das relationale Datenmodell bzw. das relationale
Tupelkalkül durch nachträglich zugefügte Funktionalität, etwa durch Wrapper,
unterstützt und somit eine Homogenisierung auf Datenquellenebene stattfindet
oder
(b) die Schnittstelle der Datenquelle als gegeben betrachtet wird und somit nur ein
heterogener Zugriff möglich ist, der in einer Homogenisierung auf der Ebene des
Datenbankintegrationssystems resultiert.
Dieser Kompromiß wird im folgenden durch ein relationales Integrationsdatenmodell
und den darauf definierten Operationen vorgeschlagen.
Dazu wird im ersten Abschnitt ein Datenmodell eingeführt, daß eine Adaption des
relationalen Datenmodells darstellt. Dazu werden zu unterstützende Integrationsoperationen vorgestellt, sowie eine darauf aufbauende mögliche Anfragesprache beschrieben.
75
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
Abschließend werden Strategien zur Anfragebearbeitung und die damit verbundenen
Methoden zur Anfrageverteilung auf die Komponentensysteme behandelt.
4.1 Relationales Integrationsdatenmodell
Um die notwendigen Eigenschaften und Funktionen einer Datenbankintegration im Umfeld der Molekularbiologie, so wie sie in [58] beschrieben wurden, in ein Softwaresystem
zu überführen, wird es notwendig, formale Grundlagen zu erarbeiten. Diese dienen
der konkreten Algorithmisierung und anschließenden Implementierung einer Lösung
zur Datenbankintegration. Als Grundlage hierzu soll die Definition eines geeigneten
Datenmodells dienen, das auf Grundlage der Analyse existierender, zu integrierenden
Datenquellen erarbeitet wird. Ziel ist ein Datenmodell, auf das die existierenden Datenquellen abgebildet werden können. Angelehnt an das relationale Datenmodell wird
im folgenden das Relationale Integrationsdatenmodell (RIND) erarbeitet. Zuvor sollen
aber grundlegende Konzepte des relationalen Datenmodells eingeführt werden.
4.1.1 Basisdatenmodell
In der Molekularbiologie wird mit realen Objekten gearbeitet. Das heißt, diese werden,
wie in Naturwissenschaften üblich, empirisch beobachtet und gemessen. Die Ergebnisse
hieraus werden ausgewertet und genutzt, um Theorien zu beweisen oder zu widerlegen. Dabei handelt es sich um greifbare“, d. h. meßbare bzw. durch die menschlichen
”
Sinnesorgane erfaßbare Objekte. Weiterhin existieren durchaus Objekte, die ausschließlich auf der menschlichen Vorstellung beruhen. Somit kann folgende Definition gegeben
werden:
Definition 4.1 (Objekt) In der realen Welt der Molekularbiologie existieren Objekte, die
aus den Bereichen der Realität und der menschlichen Vorstellung resultieren. Diese Objekte
sind meßbar bzw. sprachlich klar zu beschreiben.
2
Beispiel 4.1 Anhand folgender Aufzählung von Objekten soll obige Definition illustriert werden: das Molekül Adenin, die Aminosäure L-Alanine, das Enzym Arginase,
der Stoffwechselweg der Glycolyse, die Stoffwechselkrankheit Arginemia.
2
Bei der Betrachtung des Beispiels fällt auf, daß Objekte keineswegs atomar sind. Vielmehr können die das Objekt charakterisierenden Eigenschaften komplexe Strukturen
bilden. Dabei kann nicht davon ausgegangen werden, daß ein Objekt nicht vollständig
über seine Eigenschaften definiert werden kann. Eine bijektive Beziehung zwischen einem Objekt und seinen Eigenschaften ist also nicht zwingend vorhanden. Das liegt zum
einen daran, daß nicht alle Eigenschaften zu einem Objekt erforscht wurden oder gar unbekannt sind. Zum anderen können Eigenschaften so allgemein sein, daß ein Schluß auf
ein bestimmtes Objekt nicht möglich ist. Das wiederum kann durchaus notwendig sein,
etwa um Objektklassen zu definieren. Um nun Objekte durch Computer verarbeiten zu
können, ist aber eine eigenschaftsbasierte Abstraktion von Objekten notwendig. D. h.,
76
4.1 Relationales Integrationsdatenmodell
Objekte werden durch ihre Eigenschaften im Computer repräsentiert. Dabei können
natürlich nur die Eigenschaften betrachtet werden, die im Computer erfaßbar sind.
Darüber hinaus ist festzustellen, daß biologische Objekte der realen Welt durchaus
dynamischen Veränderungen unterliegen oder auch polymorphen Charakter besitzen
können. Diese beiden Aspekte sollen für das hier vorgestellte Datenmodell keine Rolle spielen. Dies ergibt sich aus der Motivation der Arbeit und auch den in Kapitel 3
untersuchten Eigenschaften molekularbiologischer Daten. Somit kann aus dem hier eingeführten Begriff eines Objektes keine Analogie zu bekannten Methoden der objektorientierten Modellierung aus Abschnitt 2.2.2 hergestellt werden. Vielmehr ist eher eine
Verwandtschaft zu den im Abschnitt 2.2.2 eingeführten Konzepten des E/R-Modells
feststellbar.
Diese Betrachtungen führen somit zur Definition von Objekteigenschaften und Eigenschaftsdaten.
Definition 4.2 (Objekteigenschaft) Unter der Eigenschaft eines Objektes (Objekteigenschaft) Ej versteht man ein bekanntes, bezeichnendes Merkmal aus der Menge aller
möglichen Eigenschaften E = {E1 , . . . , Ej } für j ∈ N zu Objekten gemäß Definition 4.1.
2
Beispiel 4.2 Enzymen kann z. B. eine Menge von Eigenschaften zugeordnet werden.
Neben folgender Aufzählung existieren natürlich eine Vielzahl weiterer Eigenschaften,
die Enzyme charakterisieren:
• E1 = Name
• E2 = EC Nummer
• E3 = Organismus
• E4 = Genbezeichnung
2
Definition 4.3 (Domäne) Sind die Ausprägungen einer Eigenschaft durch einen Computer erfaßbar, so werden diese als Eigenschaftsdaten, kurz Daten, bezeichnet. Die Menge
D aller möglichen Daten über allen Eigenschaften läßt sich in Untermengen zerlegen, so
daß gilt:
n
[
D=
Di
für alle n ∈ N
i=1
Ein Di wird als Wertebereich bzw. die Domäne eines Ej bezeichnet. Es existiert eine surjektive Funktion dom : E → D, die jeder Eigenschaft Ej eine Domäne Dj zuweist.
2
77
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
Beispiel 4.3 Angenommen die Menge D besteht aus den Elementen:
{Arginase, Arginosuccinase, Argininosuccinate synthase, Ornithine carbamoyltransferase, 3.5.3.1, 4.3.2.1, 6.3.4.5, 2.1.3.3, Human, Homo sapiens, ARG1, ARG2, ASL, ASS,
OTC}
so erhält man nach Anwendung der Funktion dom:
dom(E1 ) = {Arginase, Arginosuccinase, Argininosuccinate synthase,
Ornithine carbamoyltransferase}
dom(E2 ) = {3.5.3.1, 4.3.2.1, 6.3.4.5, 2.1.3.3}
dom(E3 ) = {Human, Homo sapiens}
dom(E4 ) = {ARG1, ARG2, ASL, ASS, OTC}
2
Auf diese Weise lassen sich Eigenschaften Objekten zuordnen, so daß man in die Lage versetzt wird, von Objekten gemäß Definition 4.1 derart zu abstrahieren, daß diese
durch Computer erfaßbar werden. Da jeder Eigenschaft genau einer Domäne zugeordnet ist, umfassen die Objekteigenschaften die Menge aller möglichen Eigenschaftsdaten.
Es ist leicht einzusehen, daß durch die Auswahl spezieller Eigenschaftsdaten eine bestimmte Ausprägung eines Objektes erfaßt werden kann.
Definition 4.4 (Eigenschaftsschema) Eine Menge S ⊆ E definiert das Eigenschaftsschema OS eines Datenobjektes DO. Dabei sind die Elemente wohlgeordnet.
2
Beispiel 4.4 Um die eben eingeführte Defintion eines Eigenschaftsschemas transparent
darzustellen, wird das Beispiel 4.3 erweitert. Das Eigenschaftsschema ist also:
OSEnzyme = (Name, EC Nummer, Organismus, Genbezeichnung)
2
Die konkrete Ausprägung eines Eigenschaftsschemas kann nun über die Eigenschaftsdaten und die Abbildungsfunktion dom erfolgen:
Definition 4.5 (Eigenschaftsausprägung) Aus der Menge aller möglichen Eigenschaftsdaten zu einem gegebenen Eigenschaftsschema OS lassen sich jeweils Teilmengen
von Objektdaten bilden. So gebildete i-Tupel OA sind Eigenschaftsausprägungen zu OS.
Der Index von OA entspricht dem Index von OS:
OA = (oa1 , . . . , oai )
für alle oai ⊆ dom(osi ) ∧ si ∈ OS
Ein jedes Tupel aus OA ist also eine Objektausprägung für ein spezielles Eigenschaftsschema
osi . Die Menge aller Objektausprägungen aus OA zu einem Eigenschaftsschema aus OS
wird über die surjektive Funktion obj : OS → OA angegeben.
2
78
4.1 Relationales Integrationsdatenmodell
Beispiel 4.5 Mögliche Objektausprägungen können so aus Untermengen der jeweiligen
Eigenschaftsdomäne gebildet und dem Eigenschaftsschema OSEnzyme aus Beispiel 4.4
zugeordnet werden:
obj(Enzyme) =
n
{Arginase}, {3.5.3.1}, {Human, Homo sapiens}, {ARG1, ARG2} ,
{Arginosuccinase}, {4.3.2.1}, {Human, Homo sapiens}, {ASL} ,
{Argininosuccinate synthase}, {6.3.4.5}, {Human, Homo sapiens},
{ASS} ,
{Ornithine carbamoyltransferase}, {2.1.3.3}, {Human, Homo sapiens},
o
{OTC}
2
Betrachtet man nun ein Eigenschaftsschema und die Objektausprägungen, so sind Ähnlichkeiten zum Relationenmodell [27] erkennbar. Daß Objektausprägungen Tupel über
Mengen von Eigenschaftsdaten sind, widerspricht natürlich dem Atomaritätskriterium von Attributen in Relationen. Durch die Einführung des N F 2 -Modells durch [135]
wurde das Relationenmodell diesbezüglich erweitert. So können hier durch die Anwendung von Schachtelungs- bzw. Entschachtelungsoperationen geschachtelte Relationen
in flache Relationen überführt werden. Diese Methode ist auf das soeben eingeführte
Datenmodell nicht anwendbar.
Denn beim hier eingeführten RIND-Datenmodell handelt es sich bei den Eigenschaftswerten zu jeder Eigenschaft osi eines Eigenschaftsschemas OS um Mengen von Daten.
Dieses allgemeinere Konzept spiegelt die Gegebenheiten in molekularbiologischen Datenbanken wider, so wie sie in Abschnitt 3.1.1 eingeführt wurden. Somit müssen spezielle Regeln angewandt werden, um Relationen zu erzeugen (siehe Abschnitt 4.1.3).
Wie später gezeigt wird, sind die objektidentifizierenden Eigenschaften gesondert zu
behandeln. Auch im Bereich der Beziehungen zwischen Datenobjekten sind spezielle
Methoden notwendig, die in den folgenden Abschnitten beschrieben werden.
4.1.2 Schlüssel
Betrachtet man Objekausprägungen, so erscheint es sinnvoll, diese anhand spezieller
Eigenschaften eindeutig identifizieren zu können. Dazu kann das gesamte Eigenschaftschema derart genutzt werden, indem sich alle Elemente möglicher Objektausprägungen
aufgrund unterschiedlicher Eigenschaftsdaten unterscheiden.
Definition 4.6 (Objekteindeutigkeit) Die Definition einer Menge läßt sich nutzen,
um die Eigenschaft zu begründen, daß also ein Tupel aus der Menge O = obj(OS) diese
Objektausprägung eindeutig in O bestimmt:
∀x, y ∈ obj(OS) : x 6= y
für OS ⊆ E
2
79
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
Diese Eindeutigkeitseigenschaft von Objektausprägungen nutzt die gesamte Anzahl von
Objekteigenschaften in S. Eine sinnvollere Methode ist die Bildung einer Untermenge
der Form OS ǫ ⊆ OS derart, daß die Definition 4.6 mit OS ǫ erfüllt ist:
Definition 4.7 (Minimale Objekteindeutigkeit) Es existiert eine Untermenge OS ǫ ,
so daß gilt:
∀x, y ∈ obj(OS ǫ ) : x 6= y
für OS ǫ ⊆ OS
2
OS ǫ sind die Schlüsseleigenschaften aus OS und bestimmen die anderen Eigenschaften
OS γ = OS \ OS ǫ funktional. Diejenige Untermengen OSiǫ für die gilt:
∀OSiǫ ⊆ OS ǫ : |OSiǫ | ist minimal über alle OSiǫ
ǫ
ǫ
bezeichnen wir als OSmin
. Dabei muß OSmin
natürlich Defintion 4.7 erfüllen.
Beispiel 4.6 Um die eben eingeführten Schlüsseleigenschaften am Beispiel darzustellen, nutzen wir das bereits eingeführte Objekteigenschaftsschema OSEnzyme :
ǫ
OSEnzyme
1
γ
OSEnzyme
1
ǫ
OSEnzyme 2
γ
OSEnzyme
2
ǫ
OSEnzyme
min
γ
OSEnzyme min
=
=
=
=
=
=
(Name, EC Nummer, Organismus, Genbezeichnung)
()
(EC Nummer, Genbezeichnung)
(Name, Organismus)
(Genbezeichnung)
(Name, EC Nummer, Organismus)
2
4.1.3 Abbildung auf das Relationenmodell
Wie in Definition 4.5 bestimmt wurde, sind die Eigenschaftsausprägungen für eine Eigenschaft Mengen von Daten gemäß Definition 4.3. Mit dem Ziel der Abbildung auf
das relationale Datenmodell ist es notwendig, diese derart aufzulösen, daß atomare,
nicht mengenwertige Eigenschaftsausprägungen existieren. Mittels einer rekursiven Anwendung des Kreuzproduktes zweier Mengen lassen sich Objektausprägungen zu einer
Menge von Tupeln relational auflösen:
Definition 4.8 (Paarfunktion Tupel/Menge) Die Definition einer Paarmenge zweier Mengen läßt sich auf eine Kombination eines Tupels T und einer Menge M erweitern:
T = (te1 , . . . , ten )
M = {me1 , . . . , mem }
T × M = {(te1 . . . , ten , me1 ),
..
.
(te1 . . . , ten , mem )}
2
80
4.1 Relationales Integrationsdatenmodell
Definition 4.9 (Paarfunktion Relation/Menge) Da das Ergebnis der Operation ×
einer Relation entspricht, d. h. einer Menge von Tupeln, kann diese Operation auch auf die
Paarbildung einer Relation R und eines Tupels T ausgeweitet werden:
T = (te1 , . . . , ten )
R = (r1 , . . . , rm ) | rm ∈ T
R×T =
|R|
[
ri × T
| ri ∈ R
i=1
2
Mit der zuvor definierten Funktion × kann nun aus einer Objektausprägung OA zu
einem gegebenen Eigenschaftsschema OS gemäß den Definitionen 4.5 und 4.4 eine Relation ROA berechnet werden:
R0 = {()}
Ri = Ri−1 × oai
ROA = Rn
für alle oai ∈ OA ∧ 1 ≤ i ≤ n ∧ n = |OS|
Die Ergebnisrelation ROA hat somit n Attribute und eben soviel Tupel m wie das
Produkt der Größe aller Elemente aus OA:
Y
m=
|oai |
1≤i≤n
Beispiel 4.7 Bezugnehmend auf Beispiel 4.5 kann eine Objektausprägung wie folgt
rekursiv aufgelöst werden:
OA =
R0
R1
R2
R3
R4
ROA
n
{Arginase}, {3.5.3.1}, {Human, Homo sapiens}, {ARG1, ARG2}
{()}
{()} × {Arginase}
{(Arginase)} × {3.5.3.1}
{(Arginase, 3.5.3.1)} × {Human, Homo sapiens}
(Arginase, 3.5.3.1, Human),
=
× {ARG1, ARG2}
(Arginase, 3.5.3.1, Homo sapiens)


(Arginase, 3.5.3.1, Human, ARG1), 





(Arginase, 3.5.3.1, Human, ARG2),
=
(Arginase, 3.5.3.1, Homo sapiens, ARG1)




(Arginase, 3.5.3.1, Homo sapiens, ARG2)
=
=
=
=
Es ergeben sich somit n = 4 und m = 4.
2
81
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
Da die Menge O aller Objektausprägungen zu einem Eigenschaftsschema über die Funktion O = obj(OS) ermittelt werden kann, ist es möglich, die relationale Abbildung auf
jedes Element aus O anzuwenden und mittels der Mengenvereinigung eine Gesamtrelation R zu O auszurechnen:
|O|
[
R=
oi | o ∈ O
i=1
4.2 Datenschemata
Das zuvor vorgestellte Datenmodell dient als Basis zur konkreten Implementierung
einer Datenbankintegration mittels eines Mediators, dem im Kapitel 5 vorgestellten
BioDataServer. Dabei wird davon ausgegangen, daß kein homogenes Datenmodell in
allen Ebenen, die zu einem Mediator gehören, vorliegt. Vielmehr existieren die Anwendungsebene, die Datenquellenebene und die Vermittlerschicht. Diese Architektur wurde
bereits im Abschnitt 2.3.3 vorgestellt.
Dabei besteht die Notwendigkeit, die Datenmodelle derart auszuwählen, daß
1. komplexe Datenmodelle zur strukturierten und konsistenten Datenbereitstellung
mit Unterstützung deklarativer Anfragesprachen auf Anwenderebene, wie etwa
das relationale Modell und SQL, bereitgestellt werden, und andererseits
2. die eher einfachen Datenmodelle, wie etwa flache Dateistrukturen und die teilweise sehr beschränkten Datenanfragemöglichkeiten der Datenquellen, unterstützt
werden.
Diese beiden Ebenen sind durch den Mediator zusammenzuführen. Dabei sind folgende
Aspekte von der Schemaebene des Mediators zu berücksichtigen:
• Datenschemapartitionierung,
• Datenallokation und
• Datenschemaintegration.
Diese Aspekte fließen in die nachfolgend beschriebene 3-Ebenen-Schemaarchitektur
ein, deren Ebenen Elemente aus dem RIND-Datenmodell benutzen. Abbildung 4.1 zeigt
die drei Schemaebenen1 .
Das Remote Export Schema (RES) wird auf der Ebene der Datenquellen angewandt
und beschreibt die dortigen Datenschemata im nativen Datenmodell. Das Adapter Schema (AS) ist eine Abbildung des RES einer Datenquelle auf das in Abschnitt 4.1 eingeführte RIND-basierte Datenschema. Letztlich repräsentiert das Integrated User Schema
(IUS) partiell integrierte, mit Datenallokations- und Partitionselementen angereicherte,
relationale Sichten auf Adapterschemata.
1
Die Bezeichnungen der Schemaebenen sind aus Gründen der Konsistenz mit dem hierzu bereits in
[136] veröffentlichten Beitrag des Autors in englischer Sprache angegeben
82
4.2 Datenschemata
Abbildung 4.1: 3-Ebenen-Schemaarchitektur des Integrationsansatzes
4.2.1 Remote Export Schema (RES)
Die Schemaebene des Remote Export Schemas (RES) ist analog dem lokalen Schema
der 5-Ebenen Schemaarchitektur eines FDBS aufzufassen. Hier wird das konzeptionelle
Schema des jeweiligen KDBS beschrieben. Wie im Kapitel 3 bereits erläutert, ist die
Vielzahl der Datenbanken in der Molekularbiologie konzeptionell wohlmodelliert, können aber oftmals nicht direkt zur Schemaintegration genutzt werden. Der Umstand begründet sich vornehmlich im fehlenden Exportschema dieser Datenbanken. Die Hauptgründe liegen in Zugriffsbeschränkungen auf das zugrundeliegende backend“-DBMS,
”
wodurch keine Metadaten automatisch abgefragt werden können. Alternativen, wie die
Bereitstellung von expliziten Datenschemasichten gemäß den Darstellungen aus Abschnitt 3.1.2 können ebenso als Grund genannt werden.
Somit können zwei Arten von RES klassifiziert werden:
1. diejenigen, die direkt von der Datenquelle zur Nutzung in Applikationen mittels
APIs abgefragt werden können und
2. die Datenschemata, die durch manuelles oder semi-automatisches Nachmodellieren (re-engineering) erstellt werden müssen [100, 21, 84].
Beispiele von RES sind in den Anhängen A.1 bis A.4 zu finden.
Die notwendige Voraussetzung eines RES ist die Abbildbarkeit auf die im Abschnitt
4.1.1 vorgestellten Basiskonzepte eines kanonischen Datenmodells. Das ist die Voraussetzung zur Nutzung eines RES als Basis für ein Adapterschema, d. h. die Konzepte
• Objekteigenschaft
• Eigenschaftsschema
83
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
• Eigenschaftsausprägung
• Schlüsseleigenschaften
müssen aus den jeweiligen Modellen der RES abstrahiert werden können. Falls diese
Möglichkeit gegeben ist, kann für die jeweilige Datenquelle ein Adapter zur Nutzung
durch den Mediator implementiert werden.
4.2.2 Adapterschema (AS)
Mit Hilfe der Adapterschemata (AS) werden die Datenmodellheterogenitäten der RES
überwunden. Über die Abbildung des RES auf die Konzepte des Basisdatenmodells,
kann ein Adapterschema als direkte Instanz des RIND-Datenmodells implementiert
werden. Einem AS ist genau ein RES zugeordnet. Das trifft auch für den umgekehrten
Fall zu.
Somit erfüllt das AS folgende Basisanforderungen:
1. Alle wichtigen Basiskonzepte zur Bereitstellung einer relationalen Schnittstelle
über das IUS müssen abbildbar sein.
2. Es muß ausreichend semantisch arm sein, um möglichst viele RES auf AS abbilden
zu können.
Es werden hier also Eigenschaftsschemata OS gemäß Definition 4.4, Eigenschaftsausprägungen OA gemäß Definition 4.5 sowie daraus ableitbare Schlüsseleigenschaften OS ǫ
gemäß Definition 4.7 als Schemakonstrukte genutzt. Zusätzlich werden Metainformationen zu möglichen Zugriffspfaden, d. h. ob eine indexunterstützte Selektion über ein
Attribut unterstützt wird, abgelegt. Dies ist für die Anfrageverarbeitung, die in Abschnitt 4.3 vorgestellt wird, wichtig.
Ein Adapterschema ist also ein Exportschema einer Datenquelle in einem kanonischen Datenmodell und wird als Tabellen T , die Tupel von Attributen A umfassen2
beschrieben. Zu beachten ist hierbei, daß ein Attribut Gültigkeit für das gesamte Adapterschema besitzt, aber in verschiedenen Tabellen enthalten sein kann. Das bedeutet,
daß die Metainformationen, wie z. B. zur Indizierung, über alle Tabellen gültig sind.
Ein Adapterschema kann also wie folgt aufgeschrieben werden:
P
= {indexed, not indexed}
A = (name, typ, P )
T
= {a1 , . . . , an }
| name ∈ E ∧ typ = dom(name)
(Definitionen 4.2 und 4.3)
| an ∈ A
Um funktionale Abhängigkeiten von Attributen innerhalb einer Tabelle T zu bestimmen, existiert eine Funktion key, die sich aus Definition 4.7 ableitet:
key : T → T ǫ
2
ǫ
| T ≡ OS ∧ T ǫ ≡ OSmin
Es werden hier die Begriffe Tabelle und Attribut synonym für Eigenschaftsschemata OS bzw. Objekteigenschaften genutzt, da das Adapterschema als Basis für eine Abbildung auf das Relationenmodell genutzt wird.
84
4.2 Datenschemata
Somit ist ein Adapterschema eine Menge von Tabellen T :
AS = {T }
Beispiel 4.8 Für ein konkretes Beispiel werden zwei Datenquellen KEGG und BRENDA
betrachtet. In diesen Datenquellen sind Daten zu Enzymen und Stoffwechselwegen enthalten. Für das vorliegende Beispiel soll ein abstrakter Ausschnitt aus den realen Schemata der beiden Datenquellen betrachtet werden. Die vollständigen Adapterschemata,
so wie sie für den in Kapitel 5 beschriebenen BioDataServer genutzt werden, sind in den
Anhängen B.4 und B.5 zu finden. Das vorliegende Beispiel umfaßt für den KEGG-Adapter zwei Tabellen mit Daten zu enzymatisch katalysierten biochemischen Reaktionen
bzw. Stoffwechselwegen:
KEGG = {kr 1 , kr 2 }
Der BRENDA-Adapter wiederum liefert analog zum KEGG-Adapter in einer Tabelle
organismusspezifische Enzymdaten:
BRENDA = {br 1 }
Dabei werden die Attribute und Tabellen wie folgt definiert:
BRENDA:
b1
b2
b3
b4
=
=
=
=
(ec, string, {indexed})
(name, string, {not indexed})
(reaction, string, {not indexed})
(organism, string, {not indexed})
KEGG:
a1
a2
a3
a4
a5
=
=
=
=
=
(ec, string, {indexed})
(name, string, {indexed})
(reaction, string, {indexed})
(map, string, {indexed})
(pathwayname, string, {not indexed})
br 1 = {b1 , b2 , b3 , b4 }
kr 1 = {a1 , a2 , a3 }
kr 2 = {a1 , a4 , a5 }
keybr1 = (b1 )
keykr1 = (a1 )
keykr2 = (a1 )
85
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
2
Darüber hinaus bietet das Adapterschema die Möglichkeit, zusätzlicher Informationen, die es ermöglichen eine Klassifikation der jeweiligen Datenquelle hinsichtlich der
Zugriffskosten und der Datenqualität vorzunehmen, zu erfassen. Solche Informationen
werden für die Nutzung durch den Integrationsdienst BioDataServer konzipiert und
sind im UML-Klassendiagramm in Abbildung 5.17 spezifiziert. Dazu zählen u. a. Informationen zu:
• Datenformat
• Zugriffsschnittstelle
• Datenherkunft und Datenqualität
Da diese nur sekundäre Bestandteile der hier vorgestellten Adapterschemata sind, werden sie implementierungsabhängig verwaltet. Nähere Informationen sind deshalb in
Abschnitt 5.4 enthalten.
Der Mediator oder der Anwendungsentwickler kann auf dieser Grundlage Entscheidungen zu Anfrageoptimierungen oder Datenvereinigungsstrategien vornehmen. Zum
Beispiel können Datenquellen mit überschneidenen Datendomänen gemäß der Datenqualität priorisiert werden. So ist es vorstellbar, daß für statistische Analysen zur Ermittlung von Trends auch weniger vertrauenswürdige Daten herangezogen werden. Für
die gezielte Analyse einzelner Daten dagegen können restriktivere Qualitätskriterien
spezifiziert werden.
Im Falle der Anfrageoptimierung ist es durchaus nützlich, die einer Datenanfrage
zugrundeliegenden Protokolle und Extraktionstechniken zu werten. So ist etwa eine
Datenquelle über das FTP-Protokoll zugänglich, und die Datenextraktion geschieht
durch den Adapter mittels Parsen. Dagegen könnte eine andere Datenquelle der gleichen
Datendomäne über das JDBC-Protokoll mit SQL zugänglich sein. Somit kann die zweite
Datenquelle einen höheren Rang im Kontext von Anfrageplanbewertungen einnehmen.
4.2.3 Integriertes Nutzerschema (IUS)
Das IUS reflektiert die Intension einer engen Datenbankintegration im Sinne der im
Abschnitt 3.2.1 vorgestellten Integrationsmerkmale. Hierbei werden die Teile der Adapterschemata in Form von Views integriert und mit notwendigen Metadaten zur Anfrageverarbeitung angereichert (vergleiche hierzu Abschnitt 4.4). Wie in Abbildung 4.1
dargestellt, können mehrere, sich überlappende integrierte Nutzerschemata existieren,
welche unterschiedliche, nutzerspezifische Sichten auf die zu integrierenden Daten umsetzen. Jedes dieser IUS umfaßt so spezifisch modellierte, integrierte Datenbanken, wie
z. B. zu Enzymen oder Stoffwechselwegen.
Das genutzte Datenmodell basiert auf dem relationalen Datenmodell und besteht aus
Tabellen T , die eine Menge von Attributen A umfassen. Dabei hat jedes Attribut einen
Namen und einen Datentyp, welche mit den Konzepten aus Definitionen 4.2 und 4.3
86
4.2 Datenschemata
korrespondieren. Da es sich beim IUS um die direkte Schnittstelle zu den Applikationen handelt, sind für Datendomänen eines Attributes durchaus abstrakte Datentypen
wie etwa string, integer oder float möglich. Notwendige Typkonvertierungen zwischen
den einzelnen Schemaebenen sind hierzu durchzuführen. Weitere Konzepte, wie etwa
konsistenzunterstützende Konstrukte, wie Primärschlüssel oder Fremdschlüssel, werden
nicht unterstützt. Zusätzlich zu der primären Datenstruktur wird jedes Attribut mit
Metadaten zu den zugrundeliegenden Datenquellen, den Partitionierungs-, Allokationsmetadaten sowie Anfrageabhängigkeiten angereichert.
A = (name, typ) | name ∈ E ∧ typ ≡ dom(name) (Definitionen 4.2 und 4.3)
T = {a1 , . . . , an } | an ∈ A
Mit diesen Konstrukten ist es möglich, eine Datenstruktur zu beschreiben. Die notwendigen Metadaten zur Auflösung der Datenquellen eines Attributes müssen Partitionierungsdaten (Teil eines Datenschemas einer Datenquelle) und Allokationsdaten (zuständiger Wrapper/Adapter) enthalten. Dazu werden Elemente aus dem Adapterschema,
das im Abschnitt 4.2.2 beschrieben ist, referenziert. Ein Adapter Q umfaßt dabei eine Menge von Eigenschaftsschemata OS. Um die Partitionierung zu überwinden, sind
semantisch äquivalente Objekteigenschaften zu einem globalen Attribut aus dem IUS
abzubilden. Somit gilt es eine Funktion source zu definieren, die einem Attribut aus
dem IUS auf eine nicht leere Menge von Objekteigenschaften AQ der Datenquelle Q
aus bestimmten Eigenschaftschemata OS eines Adapters zuordnet:
source : AQ → A | AQ ∈ OS
(Definition 4.4)
In Abschnitt 4.4 werden notwendige Strategien zur Ausführung von Datenanfragen an
den hier vorgestellten Mediator erarbeitet. Die zur Berechnung der in diesem Abschnitt
beschriebenen Anfragepläne notwendigen Metadaten in Form von Ausführungsabhängigkeiten werden ebenfalls als Metadaten im IUS für jedes Attribut geführt. Dabei muß
eine Funktion retrieval dependency definiert werden, die zu jedem Element aus der Menge AQ eines Attributes A0 ein anfragebestimmendes Attribut A1 der gleichen Tabelle
T bestimmt:
retrieval dependency : A → AQ
| AQ ∈ OS
(Definition 4.4)
Diese Funktion kann auf Basis der in Abschnitt 4.2.2 erläuterten Abhängigkeiten auf
Datenquellenebene, den sogenannten subgoals, spezifiziert werden. Beim IUS sind aber
Anfrageabhängigkeiten auch zwischen verschiedenen Datenquellen zu spezifizieren, so
daß die innerhalb eines Adapterschemas geltenden Anfrageabhängigkeiten nicht automatisch genutzt werden können. Die Funktion source kann also nicht genutzt werden,
um die Funktion retrieval dependency zu bestimmen. Vielmehr dienen die subgoals den
Adapterschemata als Vorlage bzw. Modellierungshilfe für die IUS.
Beispiel 4.9 Anhand folgender integrierter Nutzerschemata sollen obige Konzepte veranschaulicht werden. Auf der Grundlage des Beispiels 4.8 kann eine Tabelle modelliert
87
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
werden, die Daten zu Enzymen und deren Rolle in Stoffwechselwegen beschreibt. Es ist
dabei zu beachten, daß nicht alle im IUS definierten Attribute in Tabellen enthalten
sein müssen. Das erklärt sich aus notwendigen Anfrageabhängigkeiten zu Attributen,
die aber nicht Bestandteil einer Tabelle sein sollen:
A1
A2
A3
A4
A5
=
=
=
=
=
(ec, string)
(name, string)
(reaktion, string)
(map, string)
(stoffwechselweg, string)
Tenzym = (A1 , A2 , A3 , A4 )
retrieval
retrieval
retrieval
retrieval
retrieval
retrieval
retrieval
retrieval
source(A1 )
source(A2 )
source(A3 )
source(A4 )
source(A5 )
=
=
=
=
=
{a1 , b1 }
{a2 , b2 }
{a3 , b3 }
{a4 }
{a5 }
dependency(a1 )
dependency(b1 )
dependency(a2 )
dependency(b2 )
dependency(a3 )
dependency(b3 )
dependency(a4 )
dependency(a5 )
=
=
=
=
=
=
=
=
{}
{}
{A1 }
{A1 }
{A1 }
{A1 }
{A1 }
{A4 }
2
Während der Integration, der von den Datenquellen angefragten Daten, wird die
Funktion source als eine Gleichheitsrelation für Adapterattribute genutzt. Es wird in
Abschnitt 4.4.3 beschrieben, wie auf dieser Basis eine Vereinigung der Anfrageresultate
verschiedener Datenquellen durchgeführt wird.
4.3 Integrationsoperatoren
Auf dem im vorigen Abschnitt eingeführten Datenmodell sind notwendigerweise gültige
Operationen zu definieren. Diese dienen zur Anfrageverarbeitung und müssen deshalb
88
4.3 Integrationsoperatoren
auf jeder Schemaebene ausgeführt werden können. Eine weitere Forderung ergibt sich
aus der Einleitung zu diesem Kapitel. Was für die Datenmodelle der zu nutzenden Datenquellen bezüglich der Minimalität gilt, ist auch auf den anzunehmenden Umfang
von Anfrageschnittstellen zu übertragen. Die Datenquellen unterliegen beschränkten
Zugriffsmustern derart, daß angenommen werden muß, daß nicht alle Operationen der
relationalen Algebra unterstützt werden. Dies folgt aus den Analysen des Abschnittes
3.1.2 und aus der Annahme heraus, daß diese Operationen ein relationales Datenmodell
bedingen. Somit sind Operationen auf dem eingeführten Datenmodell RIND zu definieren. Diese sind von den Datenquellen auszuführen und daher so zu definieren, daß die
Mehrzahl der Datenquellen die Operationen direkt ausführen können. Andernfalls sind
diese Operationen vom Adapter nachzubilden.
Die letzte Forderung ist, daß durch Kombination der zu definierenden Operationen
auf globaler Ebene komplexe Anfragesprachen realisiert werden können. Es muß möglich
sein, eine globale Anfragesprache mit wenigen zusätzlichen, über die Basisoperationen
hinausgehenden Operationen zu implementieren. Ein Beispiel ist der, für den im Kapitel
5 vorgestellten BioDataServer, implementierte SQL-Dialekt. Die auf dem Datenmodell
zu definierenden Operationen sollen einerseits minimal genug sein, um von den Datenquellen direkt ausgeführt werden zu können und andererseits genügend Funktionalität
besitzen, um als Basisoperationen für komplexe, globale Anfragesprachen zu dienen.
Das wird durch die Kombination dieser Operationen in Form von Anfrageplänen umgesetzt und in Abschnitt 4.3.2 erläutert. Zunächst werden eben diese Basisoperationen
eingeführt.
4.3.1 Basisoperationen
Die Definition von Basisoperationen erfolgt auf der Grundlage des relationalen Integrationsdatenmodells RIND in der konkreten Ausprägung als Adapterschema. Es werden
drei Operationen unterstützt, die von der relationalen Algebra abgeleitet werden. Diese
sind Projektion π, Selektion σ und der natürliche Verbund ⊲⊳. Die folgenden Definitionen dieser Operationen beziehen sich dabei auf das im Abschnitt 4.1 eingeführte
Datenmodell, das vom relationalen Datenmodell abgeleitet wurde.
Definition 4.10 (Projektion) Die Projektion π ist die Einschränkung der Funktion obj
auf einer Menge von Objektausprägungen O = obj(OS) aus Definition 4.5, wobei die als Parameter aufgezählten Objekteigenschaften (Attribute) als Einschränkung bzw. Untermenge
zu OS aufzufassen sind. Somit werden aus dem Eigenschaftsschema einer Objektausprägung gewisse Objekteigenschaften ausgewählt, wodurch die resultierende Objektausprägung
nur die jeweiligen Tupelelemente zu dieser Auswahl enthält:
πY (OS) = obj(Y ) | Y ⊆ OS
2
89
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
Beispiel 4.10 Als Grundlage für die Veranschaulichung der Projektion dient hier das
Beispiel 4.5. Dabei werden die Eigenschaften Name und Genbezeichnung aus dem
Eigenschaftschema Enzyme ausgewählt:
n
πName,Genbezeichnung (Enzyme) =
{Arginase}, {ARG1, ARG2} ,
{Arginosuccinase}, {ASL} ,
{Argininosuccinate synthase}, {ASS} ,
o
{Ornithine carbamoyltransferase}, {OTC}
2
Definition 4.11 (Selektion) Die Selektion σ wählt Objektausprägungen aus einer Menge von Objektausprägungen O = obj(OS) (Definition 4.5) aus. Als Parameter wird eine
Konstantenselektionsbedingung mit dem Mengengleichheitsoperator angegeben. Da Eigenschaftsausprägungen mengenwertig sind, muß die Konstante ebenfalls mengenwertig sein
und Elemente der Domäne der zu vergleichenden Eigenschaft (Definition 4.3) enthalten.
Das Ergebnis dieser Operation ist dann eine Untermenge von O, worin alle Elemente der
Selektionsbedingung genügen:
σe=c (OS) = O′ | O′ ⊆ O ∧ e ∈ OS ∧ c ∈ dom(e) ∧ ∀o′ ∈ O′ : o′ .e = c)
2
Beispiel 4.11 Als Grundlage für die Veranschaulichung der Selektion dient auch hier
das Beispiel 4.5. Es sollen alle die Objektausprägungen ermittelt werden, bei denen die
Eigenschaft EC_Nummer der einelementigen Menge {’3.5.3.1’} entspricht:
σEC Nummer={′ 3.5.3.1′ } (Enzyme) =
n
o
{Arginase}, {3.5.3.1}, {Human, Homo sapiens}, {ARG1, ARG2}
2
Definition 4.12 (natürlicher Verbund) Der natürliche Verbund ⊲⊳ verbindet zwei
Mengen von Objektausprägungen O1 = obj(OS1 ) und O2 = obj(OS2 ) derart miteinander, daß das Eigenschaftsschema der resultierenden Menge eine nicht leere Vereinigung der
beiden Ursprungseigenschaftsschemata (OS1 und OS2 ) ist und genau nur die Objektausprägungen enthalten sind, deren Projektion mit den Eigenschaftsschemata OS1 und OS2 in
O1 bzw. O2 enthalten sind:
O1 ⊲⊳ O2 = {o = obj(OS1 ∪ OS2 ) | OS1 ∩ OS2 6= ∅ ∧ πOS1 (o) ∈ O1 ∧ πOS2 (o) ∈ O2 }
2
90
4.3 Integrationsoperatoren
Laut Definition ist der klassische Verbund, wie er aus der relationalen Algebra bekannt
ist, eingeschränkt. So darf die Schnittmenge der zu vereinigenden Objekteigenschaftsschemata nicht leer sein. Die Begründung ist die spätere Nutzung in Anfrageplänen,
die exakt so konstruiert werden, daß ausschließlich dieser Fall eintritt. Die Motivation hierzu ergibt sich aus der zwingenden Notwendigkeit zur Erhaltung des Kontextes
der molekularbiologischen Daten. Der Kontext ergibt sich dabei über semantisch äquivalente Eigenschaften, die auf Schemaebene im IUS definiert werden. Somit ist etwa
der Fall eines kartesischen Produktes zweier Mengen von Objektausprägungen nicht
möglich, was in der relationalen Algebra gegeben wäre. Also können keine globalen Objektausprägungen gebildet werden, die nicht über semantisch äquivalente Eigenschaften
verbunden und so in einen ungültigen Bezug zueinander gesetzt worden sind. Die Konsequenz ist, daß nur konsistenzerhaltene Anfragepläne konstruierbar sind, die auf den
in Abschnitt 4.2.3 eingeführten source und retrieval dependency Funktionen beruhen.
Beispiel 4.12 In diesem Beispiel wird auf den Fall des natürlichen Verbundes eingegangen, wo die Schnittmenge von OS1 und OS2 nicht leer ist. Laut Definition ist nur
solch ein Verbund zulässig. Zur Veranschaulichung wird das in zwei Objekteigenschaften
zerlegte Beispiel 4.5 genutzt. Hierbei existiert ein Eigenschaftschema zu Enzymnamen:
OSEnzyme Names = (Name, EC Nummer)
n
{Arginase}, {3.5.3.1} ,
obj(Enzyme N ames) =
{Arginosuccinase}, {4.3.2.1} ,
{Argininosuccinate synthase}, {6.3.4.5} ,
o
{Ornithine carbamoyltransferase}, {2.1.3.3}
Weiterhin existiert ein Schema zu speziesspezifischen Genen:
OSEnzyme Genes = (EC Nummer, Organismus, Genbezeichnung)
n
obj(Enzyme Genes) =
{3.5.3.1}, {Human, Homo sapiens}, {ARG1, ARG2} ,
{4.3.2.1}, {Human, Homo sapiens}, {ASL} ,
{6.3.4.5}, {Human, Homo sapiens}, {ASS} ,
o
{2.1.3.3}, {Human, Homo sapiens}, {OTC}
Dabei wird die Bedingung erfüllt, daß die Schnittmenge der beiden Eigenschaftschemata
nicht leer ist:
OSEnzyme N ames ∩ OSEnzyme Genes = {EC Nummer}
Die Vereinigung von OSEnzyme N ames und OSEnzyme Genes ergibt somit:
(Name, EC Nummer, Organismus, Genbezeichnung)
91
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
Dazu existiert u. a. eine, laut Definition des natürlichen Verbundes gültige, Objektausprägung:
oa = {Arginase}, {3.5.3.1}, {Human, Homo sapiens}, {ARG1, ARG2}
Denn es gelten:
πName, EC Nummer (oa) ∈ obj(Enzyme N ames)
πEC Nummer, Organismus, Genbezeichnung (oa) ∈ obj(Enzyme Genes)
Würden bei obigen Eigenschaftsschemata im Gegensatz zur Definition auch kartesische Produkte zugelassen, so ist leicht einzusehen, daß inkonsistente Ergebnisse entstehen würden. Etwa die falsche Zuordnung von Genen zu Enzymen, falls die Eigenschaft EC_Nummer nicht in beiden Schemata enthalten wäre und ein Verbund ohne
sich schneidende Eigenschaftsschemata gebildet würde.
2
Die vorgestellten Operationen bilden nun die Basis für die Ausführung von Anfrageplänen auf Ebene der Adapterschemata und den Datenanfragen auf Ebene der Datenquellen. So wird der natürliche Verbund als Operation zum Zusammenfügen von
Anfrageergebnissen von Teilbäumen eingesetzt. Die Projektion und Selektion wird auf
der Ebene der Datenquellen bzw. der Wrapper für die Ausführung der im nächsten
Abschnitt vorgestellten subgoals benötigt.
4.3.2 Datenquellenanfragen
Für die konkrete Anfrage von Daten aus Datenquellen wird eine Methodik vorgeschlagen, die auf dem eingeführten Datenmodell RIND und den darauf definierten Operationen π, σ und ⊲⊳ beruht. Hierdurch wird die Kernidee der vorgeschlagenen Datenbankintegrationslösung aufgegriffen: Die Abstraktion gegebener Funktionalität aller
potentiell zu integrierenden Datenquellen zu minimal notwendigen Elementarfunktionen. Das bedeutet, daß für jede Datenquelle eine Schnittstelle in Form eines Adapters
implementiert sein muß, welche
1. das Adapterdatenschema gemäß der Vorgaben aus Abschnitt 4.2.2 beschreibt und
2. die Basisoperationen π, σ und ⊲⊳ aus Abschnitt 4.3.1 implementiert.
Diese Implementierung erfolgt mit Hilfe einer Adaption des aus der Literatur bekannten
Konzeptes der subgoals [137]. Hierbei wird davon ausgegangen, daß die o. g. Basisoperationen π und σ über konkrete Datenquellen in Form der folgenden, SQL-ähnlichen
Anfrage ausgeführt werden können.
select A1 , . . . , Ai from R where B1 = b1 and . . . and Bj = bj
Ziel ist es, sogenannte Anfrageabhängigkeiten oder auch retrieval dependencies ausdrücken zu können. Diese sind Gegebenheiten der existierenden Anfrageschnittstellen
92
4.3 Integrationsoperatoren
für die in der vorliegenden Arbeit untersuchten Datenquellen. So ist es etwa üblich, daß
Daten abhängig von gegebenen Bezeichnern angefragt werden können und somit verkettete Anfragesequenzen notwendig sind, um die interessierenden Daten abzufragen.
Auf diese Weise ist etwa die Anfrage aller Enzymnamen über alle Enzyme in nur zwei
Schritten mittels HTTP/CGI-Aufrufen möglich:
1. Abfrage aller Enzymnummern und Extraktion aus der resultierenden HTMLSeite:
http://kegg.genome.ad.jp/dbget-bin/get_htext?ECtable+D
2. Abfrage aller Enzymeigenschaften in Form einer HTML-Seite zu jeder Enzymnummer und Projektion auf die Enzymnamen mittels Parsern:
http://kegg. . . . .jp/dbget-bin/www_bget?enzyme:<ec_nummer>
In dem Konzept der subgoals stellt eine gültige Datenanfrage eine Kombination aus
Selektion und Projektion dar und kann in einer Funktion H, die ein subgoal auf eine
Datenquelle darstellt, aufgeschrieben werden:
H(B1 , . . . , Bj ; A1 , . . . , Ai ) = σB1 =b1 (σBj =bj (πA1 ,...,Aj (R))) | 0 ≤ j < n ∧ 1 ≤ i < n
Anders ausgedrückt: zu einer, möglicherweise leeren Menge von Attributen (B1 , . . . , Bj )
aus einer Tabelle R und ein daran gebundenes Tupel mit korrespondierenden Attributwerten (b1 , . . . , bj ) werden ungebundene, d. h. mit noch keinen Werten belegte Ausgabeattribute (A1 , . . . , Ai ) abgefragt. Dabei ist zu beachten, daß in der Regel A1 , . . . , Ai
und B1 , . . . , Bj disjunkt sind. Somit wird impliziert, daß die Selektionsbedingungen als
ein konjunktiver Ausdruck, also die logische Verknüpfung der einzelnen Selektionsoperationen mittels des logischen Operators ∧ evaluiert werden müssen. Das bedeutet, daß
die Datenquellen diese Konjunktion mehrerer Selektionsoperationen seitens der bereitgestellten Anfrageschnittstelle unterstützen müssen.
Wenn davon ausgegangen wird, daß die Anfragen auf Tabellen des Adapterschemas
keine aus mehreren Attributen zusammengesetzte Anfrageabhängigkeiten haben, wird
es nicht nötig, daß zwei oder mehr Attribute spezifiziert werden müssen, um eine Datenanfrage zu stellen. D. h. es existieren ausschließlich 1:n und keine m:n-Anfrageabhängigkeiten. Diese Annahme leitet sich aus den Gegebenheiten des WWW im Zusammenhang
mit der vorherrschenden Datenpräsentation mittels HTML ab, wo eben nur eine 1:nNavigation mittels Hyperlinks realisiert ist. D. h. es ist nicht möglich, eine Web-Seite
aufzurufen, die abhängig vom Zustand einer oder mehrerer weiterer Web-Seiten ist.
Dabei ist hier diese Anfrageabhängigkeitskardinalität nicht mit der Anzahl von Parametern für den Aufruf eines Web-Services zu verwechseln. Mehrere Parameter, etwa
für den Aufruf einer SOAP-Methode oder eines HTTP/GET-Aufrufes, stellen letztlich
einen einzigen, zusammengesetzten Parameter dar, der in genau ein Resultat mündet.
Diese zusammengesetzten Parameter werden per Definition von der Selektionsoperation unterstützt, da das genutzte Datenmodell RIND mit mengenwertigen Attributen
arbeitet.
93
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
Durch diese Vereinfachung des ursprünglichen Konzeptes der subgoals ist es möglich,
sogenannte Anfrageabhängigkeiten als gerichteten Baum aufzufassen, was in Abschnitt
4.3.3 zu Anfrageplänen weiter betrachtet wird. Dagegen soll an dieser Stelle darauf
hingewiesen werden, daß Selektionen nicht zum Filtern bzw. zur Datenanalyse sondern
zur Umsetzung von Anfrageabhängigkeiten auf der Ebene der subgoals Anwendung
finden. Für die Datenanalyse wird vielmehr die, auf dem integrierten Nutzerschema
aufsetzende, Schnittstelle genutzt, die etwa, wie im Fall der im Kapitel 5 beschriebenen Szenarien einer Datenbankintegration, als Kombination von Data Warehouses und
Datenquellenintegration mittels einer Untermenge von SQL umgesetzt wurde.
Aus dieser Motivation heraus wird eine Vereinfachung der subgoals vorgeschlagen,
wobei die Anzahl der gebundenen Attribute, d. h. die Selektionsoperationen für eine
Datenquellenanfrage nicht größer als eins sein darf.
Definition 4.13 (subgoal) Ein subgoal H ist eine Funktion, welche als eine geschachtelte Kombination von Selektion σ und Projektion π definiert ist. Dabei ist T eine Attributmenge im Kontext eines Adpterschemas als eine Instanz einer Objektausprägung OS aus
Definition 4.4:
H(B, A) = σB=b (πA1 ,...,Aj (T )) | A, B ⊆ T ∧ |B| ∈ {0, 1}
2
Anzumerken ist hierbei, daß die Reihenfolge zwischen Selektion und Projektion nicht
beliebig ist. Auf jeden Fall ist im ersten Schritt eine Selektion in Form einer Datenquellenanfrage und im zweiten Schritt eine Projektion in Form der Extraktion der
notwendigen Attributwerte aus den, im ersten Schritt ermittelten, Anfrageresultaten
durchzuführen. Diese Reihenfolge ergibt sich aus den vorliegenden Eigenschaften der
Anfrageschnittstelle, die in den meisten Fällen keine Projektion auf Datenquellenebene
unterstützen. Dies muß vielmehr in der Praxis auf Ebene der Datenquellenadapter etwa
durch Parsen umgesetzt werden.
Somit wären dann in SQL ausgedrückt ausschließlich folgende Typen von Anfragen
möglich:
1. select A1 , . . . , Ai from R where B1 = b1
2. select A1 , . . . , Ai from R
Beispiel 4.13 Diese subgoals können individuell durch verschiedene, existierende
Schnittstellen der Datenquellen implementiert werden. So können etwa aufbauend auf
dem Adapterschema aus Beispiel 4.8 sechs subgoals angegeben werden.
HKEGG,1 ( ; a1 )
HKEGG,4 ( ; a4 )
HKEGG,2 (a1 ; a2 , a3 )
HKEGG,5 (a4 ; a5 , a1 )
HKEGG,3 (a1 ; a4 )
HBRENDA,1 (b1 ; b2 , b3 , b4 )
Obige Beispielausprägungen von subgoals setzen dabei folgende Anfragen um. Die Subskripte geben dabei die Datenquelle an:
94
4.3 Integrationsoperatoren
• HKEGG,1 :
Abfrage aller Enzymnummern
• HKEGG,2 :
Abfrage von Enzymnamen und der katalysierten Reaktion zu einer gegebenen
Enzymnummer
• HKEGG,3 :
Abfrage von Stoffwechselwegbezeichnern zu einer gegebenen Enzymnummer
• HKEGG,4 :
Abfrage aller Stoffwechselwegbezeichner
• HKEGG,5 :
Abfrage von Stoffwechselwegnamen und von darin involvierten Enzymnummern
zu einem gegebenen Stoffwechselwegbezeichner
• HBRENDA,1 :
Abfrage von Enzymnamen, katalysierter Reaktionen und den Organismen, bei
denen das Enzym beschrieben wurde, bezüglich einer gegebenen Enzymnummer
Wie aus diesen subgoals ersichtlich, erlaubt die Datenquelle KEGG die Anfrage aller gespeicherten Enzymnummern. Dahingegegen unterstützt BRENDA dies im obigen
Szenario nicht. Daher hängt BRENDA-subgoal HBRENDA,1 direkt vom KEGG-subgoal
HKEGG,1 ab.
2
Im obigen Beispiel wurde u. a. deutlich, daß zwischen den subgoals Abhängigkeiten
bestehen. So sind manche subgoals eben von den Ergebnissen zuvor auszuführender
subgoals abhängig. Das wiederum motiviert die im folgenden Abschnitt erläuterten
Anfragepläne.
4.3.3 Anfragepläne
Zur Ausführung konkreter Datenanfragen auf Ebene eines integrierten Datenschemas
ist es notwendig, dies auf Adapterebene mittels der zuvor eingeführten subgoals umzusetzen. Wie bereits erläutert wurde, existieren Anfrageabhängigkeiten oder auch retrieval dependecies zwischen den subgoals und damit zwischen den Attributen im integrierten Nutzerschema (IUS). Diese werden deshalb dort spezifiziert (vergleiche hierzu
Abschnitt 4.2.3). Werden nun globale Attribute aus dem IUS angefragt, ergeben sich
Verkettungen von Anfragen auf die korrespondierenden Adapterattribute. Durch die
zuvor beschriebene Eigenschaft von subgoals, daß nur maximal ein gebundenes Attribut pro subgoal existiert, leitet sich die Eigenschaft ab, daß die Verkettung von globalen
Attributen über deren Anfrageabhängigkeiten und somit die Verkettung von subgoals
einen gerichteten Graphen ergibt. Die Verkettung erfolgt über die im IUS definierten
Abbildungsfunktionen source und retrieval dependency sowie mittels einer bislang nicht
eingeführten Funktion choose subgoal, die aus der Menge vorhandener subgoals eines
95
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
auswählt, das mindestens dieses Attribut aus einer Datenquelle abfragt und die modellierte Anfrageabhängigkeit erfüllt. Diese Funktion wird in Abschnitt 4.4 detailliert
beschrieben.
Ein Anfrageplan für IUS-Attribute ergibt sich also
1. aus der Anwendung der Funktion source zur Ermittlung der Adapterschemaattribute,
2. der Abbildung auf ein gültiges subgoal über die Funktion choose subgoal sowie
3. der Ermittlung der Anfrageabhängigkeit eines subgoals zu einem Attribut aus
dem IUS mittels der Funktion retrieval dependency.
Zur Veranschaulichung der Konstruktion eines Anfrageplanes ist ein solcher Prozeß der
Anfrageplanerstellung in Abbildung 4.2 dargestellt. Dieser modelliert eine Abfrage aller
IUS-Attribute aus Beispiel 4.9.
Abbildung 4.2: Schematischer Prozeß von Datenanfragen auf Attributen aus dem IUS
Im dargestellten Prozeß sind subgoals indirekt über IUS-Attribute verbunden. Diese
Attribute liefern notwendige Bindungen der Eingabeattribute der subgoals an Attributwerte. Aus der Definition der Funktion source geht hervor, daß für ein IUS-Attribut
mehr als ein Adapterattribut als Datenquelle dienen kann. Somit findet auf Ebene
der IUS-Attribute eine Vereinigung der über subgoals angefragten Attributwerte statt.
Dieser Schritt ist als Verarbeitungsschritt zur Datenintegration zu betrachten. Wird
nun der dargestellte Prozeß zur Datenanfrage um die Attribute reduziert, so kann ein
96
4.3 Integrationsoperatoren
Graph von subgoals gebildet werden, der Anfrageabhängigkeiten zwischen subgoals beschreibt. In Abbildung 4.3 ist der auf subgoals reduzierte Anfrageabhängigkeitsgraph
zu Abbildung 4.2 dargestellt.
Abbildung 4.3: Graph von Anfrageabhängigkeiten von subgoals
Wie im Abschnitt zur Anfrageverarbeitung ausgeführt werden wird, werden die im
Anfrageplan enthaltenen subgoals beginnend mit den subgoals ohne Eingabeattribute,
im Beispiel subgoal HKEGG,1 , verkettet ausgeführt. Da notwendigerweise die Ausführung eines Anfrageplanes, d. h. die Verkettung von subgoals, terminieren muß, ist die
Einschränkung auf azyklische Anfragepläne notwendig. Somit handelt es sich bei einem
Anfrageplan um einen azyklisch gerichteten Graphen:
Definition 4.14 (Anfrageplan) Ein Anfrageplan A ist ein gerichteter, azyklischer
Graph mit subgoals H als Knoten und Anfrageabhängigkeiten R als Kanten. Dabei werden
die Knoten, die subgoals ohne Eingabeattribute enthalten, als Startknoten bezeichnet. Ein
Anfrageplan ist somit:
A = (H, R) | R ⊆ {(u, v)} ∧ u, v ∈ H
Weiterhin wird gefordert, daß A azyklisch ist. Zur Definition dieser Eigenschaft werden Pfade
als Sequenz von benachbarten Knoten definiert, die in R enthalten sind:
P = (v1 , . . . , vn ) | ∀ 1 ≤ i < n ∃ (vi , vi+1 ) ∈ R
Zur Einschränkung auf azyklische Graphen wird nun gefordert, daß es keinen Pfad gibt, in
dem Knoten mehrfach vorkommen:
∀ (v1 , . . . , vn ) ∈ P : vi 6= vj ∧ 1 ≤ i, j ≤ n ∧ i 6= j
2
97
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
Beispiel 4.14 Der in Abbildung 4.3 dargestellte Graph kann auf Grundlage der gegebenen Definition wie folgt aufgeschrieben werden:
H = {HKEGG,1 , HKEGG,2 , HKEGG,3 , HKEGG,4 , HKEGG,5 , HBRENDA,1 }
R = {
(HKEGG,1 , HKEGG,2 ),
(HKEGG,1 , HKEGG,3 ),
(HKEGG,1 , HBRENDA,1 ),
(HKEGG,3 , HKEGG,5 )
}
p1 = (HKEGG,1 , HKEGG,3 , HKEGG,5 ) ∈ P
p2 = (HKEGG,1 , HBRENDA,1 ) ∈ P
p3 = (HKEGG,1 , HKEGG,5 ) ∈
/P
2
Die hier eingeführten Anfragepläne bilden die Basis für die Verarbeitung von Anfragen
auf das integrierte Nutzerschema. Dabei sind Redundanzen enthalten, wie beispielsweise
die unnötige Mehrfachausführung von gleichen subgoals mit der gleichen Wertbelegung,
wie etwa in Abbildung 4.3 im Falle der subgoals HKEGG,2 und HBRENDA,1 . Auf die Auflösung dieser Redundanz und weitere notwendige Strategien zur Anfrageverarbeitung
auf Basis von Anfrageplänen wird in den nächsten Abschnitten eingegangen.
4.4 Verarbeitung von Datenfragen
Im Sinne der in diesem Kapitel vorgestellten Datenanfragen ist unter diesem Ausdruck
die kombinierte Anwendung von verschiedenen Funktionen und Operationen auf Basis
des zuvor im Abschnitt 4.1 eingeführten Datenmodells RIND zu verstehen. Das Ziel ist
die Verarbeitung einer Datenanfrage über integrierten Nutzerschemata. Diese Datenanfragen werden mittels der vorgestellten Konzepte an Datenquellen verteilt und die
Ergebnisse zu einer Menge von Tupeln mengenwertiger Attribute integriert. Diese Anfrageresultate sind dann gemäß der Anforderungen an zu unterstützende Schnittstellen
und Anfragesprachen der in dieser Arbeit vorgestellten Datenbankintegrationslösung
auf Zieldatenmodelle abzubilden.
Im vorliegenden Anwendungsszenario und des auf dieser Basis entworfenen und implementierten Datenbankintegrationssystems aus Kapitel 5 wurde als Zieldatenmodell
das relationale Datenmodell gewählt. Somit wird letztlich das Resultat von Datenanfragen auf Ebene des integrierten Nutzerschemas (IUS) auf Relationen und auf die relationale Algebra abgebildet. Weitere Zieldatenmodelle, wie etwa das objektorientierte
Datenmodell sind ebenfalls von RIND abbildbar und wurden in [138, 139] beschrieben.
98
4.4 Verarbeitung von Datenfragen
Anfragen an ein IUS werden in mehreren Schritten umgesetzt. Im ersten Schritt wird
die Anfrage, die mittels des relationalen Tupelkalküls angegeben wird, auf Operationen,
die auf dem IUS ausgeführt werden können, abgebildet. Anschließend werden alle, für
jedes einzelne der angefragten Attribute gebildeten Anfragepläne, zu einem Gesamtanfrageplan zusammengefügt. Dieser wird ausgeführt und letztlich die resultierende Menge
von Resultattupeln relational aufgelöst. Schließlich werden die Selektionsbedingungen
der im ersten Schritt spezifizierten Anfrage auf die Ergebnisrelation angewandt. Diese
Schritte der Anfrageverarbeitung werden in folgenden Abschnitten behandelt.
4.4.1 Abbildung relationaler Datenanfragen auf das IUS
Wie im Abschnitt 2.2.4 des Grundlagenkapitels erläutert, basieren Anfragen im relationalen Tupelkalkül auf Tupelvariablen t, die jeweils an eine Relation r gebunden sind.
Die Tupelbindung (rn ) an Relationen und für Tupelvariablen zu erfüllende Tupelbedingungen (ci ) werden in CON D angegeben.
{t1 .A1 , . . . , tn .An | CON D(r1 (t1 ), . . . , rn (tn ), c1 , . . . ci )}
Ein Beispiel für einen relationalen Kalkülausdruck ist folgender, der Enzymnummern,
Enzymnamen und katalysierte Reaktionen für alle Enzyme ermittelt:
{t.ec, t.name, t.reaktion | enzyme(t) ∧ t.stoffwechselweg = ’Urea cycle’}
In SQL kann diese Anfrage wie folgt ausgedrückt werden:
select ec, name, reaktion
from enzyme
where stoffwechselweg = ’Urea cycle’
Eine solche Anfrage kann nun auf Operationen des RIND-Datenmodells abgebildet
werden. Dabei entspricht die Komponentenauswahl über der Tupelvariable t der Projektion π auf einer Tabelle T aus einem IUS. Weiterhin wurde die Tupelvariable t an
eben diese Tabelle T mittels der Funktion obj(T ) gebunden. Es gelten zwei wesentliche
Einschränkungen:
1. Eine Einschränkung ist die nicht gegebene Abbildbarkeit der Selektionsbedingung
im Kalkül auf entsprechende Operationen des IUS. Das motiviert sich aus der beschränkten Mächtigkeit der Anfrageschnittstellen auf Datenquellen und somit der
subgoals. Deshalb wurden in Definition 4.11 die zulässigen Selektionsbedingungen auf den Konstantenvergleich der Form An = c limitiert. Die Auflösung der im
Kalkül angegebenen Selektionsbedingungen ist daher im allgemeinen erst nach erfolgter relationaler Auflösung des Anfrageresultates möglich, welche in Abschnitt
4.4.4 erläutert wird. Die mit dieser Einschränkung verbundene Abfrage und Integration unnötiger“ Attributwerte ist somit zugunsten der direkten Nutzbarkeit
”
eingeschränkter Funktionalität von Datenquellenzugriffsschnittstellen unumgänglich.
99
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
Einen Spezialfall stellen die Selektionsbedingungen im Kalkül dar, die einer Konstantenselektion entsprechen. Hier ist eine direkte Abbildung in den Fällen möglich, wobei subgoals existieren, bei denen das gebundene Eingabeattribut dem
Attribut einer Konstantenselektion im Kalkül entspricht. So kann eine direkte
Belegung des entsprechenden Eingabeattributes mit der bzw. den Konstanten erfolgen, was die Ausführung von Vorgängersubgoals im Anfragegraphen erübrigt.
Ein Beispiel hierzu ist folgender Ausdruck:
{t.ec, t.name, t.reaktion | enzyme(t) ∧ (t.ec = ’3.5.3.1’ ∨ t.ec = ’4.3.2.1’)}
Unter der Annahme, daß ein Anfrageplan (HKEGG,1 , HBRENDA,1 ) existiert, könnte so auf das subgoal HKEGG,1 verzichtet und das Eingabeattribut des subgoals
HBRENDA,1 sofort mit beiden Werten belegt werden, weil in jedem Fall nur die
Enzymnummern ’3.5.3.1’ und ’4.3.2.1’ zulässig sind.
2. Die nächste Einschränkung ist die Vermeidung von mehr als einem Prädikat zur
Bindung der Tupelvariablen eines Kalküls an eine Relation. Somit ist nur die
Verwendung genau einer Tupelvariablen zulässig. Zwar existiert die Möglichkeit
eines Verbunds mehrerer Tabellen des IUS als kartesisches Produkt, darüber hinausgehende Verbundoperationen, wie etwa der natürliche Verbund im Sinne der
relationalen Algebra, sind nicht möglich. Die Begründung ergibt sich wiederum
aus der Beschränkung der Selektionsoperation auf Konstantenvergleiche mittels
der Gleichheitsrelation. Das Zulassen von mehreren Tabellen in einer Anfrage auf
das IUS würde die Kalkülauswertung komplizieren. Vielmehr wird die Berechnung
von Verbünden auf Ebene des IUS vermieden und nach der relationalen Auflösung des Anfrageergebnisses durchgeführt. Im Sinne von Anfrageoptimierungen
ist das ein denkbar ungünstiges Vorgehen, da zum Verbund erst alle beteiligten
Tabellen des IUS komplett von den Datenquellen abgefragt werden müssen, ehe
der Verbund vom Datenbankintegrationsdienst durchgeführt werden kann. Bei
Tabellen mit sehr vielen Tupeln ist ein solches Vorgehen nicht praktikabel. Dieses
Problem sollte in der Praxis nicht auftreten, da die Tabellen im IUS bereits eine
integrierende Sicht über die Adapterschemata, also die zu integrierenden Datenquellen, umsetzen und somit implizit über die zur Anfrage notwendigen Anfragepläne einzelne Attribute des AS zu globalen Sichten verbinden. Ausschließlich
aus dem Grund einer Unterstützung möglichst vieler SQL-Sprachelementen wird
ein Verbund unterstützt und sollte eher über syntaktische Einschränkungen der
bereitzustellenden SQL-basierten Anfragesprache vermieden werden.
Ein derart eingeschränktes relationales Tupelkalkül umfaßt somit die Bindung einer
Tupelvariablen t an eine Relation T ohne Selektionsprädikate und hat die Form:
{t.A1 , . . . , t.An | CON D(T (t))}
Eine gültige Abbildung eines so eingeschränkten Kalküls kann auf einen Term von
RIND-Operationen angegeben werden:
πA1 ,...,An (T ) ≡ {t.A1 , . . . , t.An | CON D(T (t))}
100
4.4 Verarbeitung von Datenfragen
Das zuvor gegebene Beispiel einer Anfrage im relationalen Tupelkalkül resultiert dann
in der folgenden Projektion:
πec,name,reaktion(enzyme)
Im Falle angefragter Verbünde über mehrere Tabellen ist für jede einzelne Tabelle eine
Anfrage nach obigem Muster zu bilden. Wie bereits angedeutet, sind weitere Verarbeitungsschritte zur Berechnung des endgültigen relationalen Anfrageresultates notwendig,
wie der Verbund und die Anwendung von Selektionsbedingungen. Zunächst ist es aber
notwendig, aus obiger Projektion mittels subgoals einen Anfrageplan zu bilden.
4.4.2 Komposition von Anfrageplänen
Die Umsetzung von Projektionsoperationen auf dem IUS stellt einen notwendigen
Schritt zur Ausführung von Datenanfragen auf Basis des in dieser Arbeit vorgestellten Ansatzes zur Datenbankintegration dar. Dabei wird über eine IUS-Tabelle eine
Menge von Tupel abgefragt. Die Tupelelemente bestimmen sich über die Projektionsliste, d. h. die Liste von Attributen der Projektion. Zu jedem dieser Attribute existiert
ein Graph über subgoals und Anfrageabhängigkeiten, um darüber die Attributwerte
aus dem Adapterschema abfragen zu können. Diese Graphen sind im IUS statisch vorgegeben. Die zu jedem Attribut der Projektionsoperation vorhandenen Einzelgraphen
sind zu Anfragegraphen gemäß Definition 4.14 zu kombinieren.
Zunächst wird eine Menge von Einzelanfragegraphen EA durch eine Vereinigung aller
Knoten und Kanten aller in EA enthaltenen Graphen zu einem Gesamtanfragegraphen
GA kombiniert:
GA =
|EA|
[
i=1
|EA|
eai .H,
[
i=1
eai .R | EA = {ea | ea ∈ A}
Hierbei können mehrere, untereinander unverbundene Teilgraphen entstehen. Die Konsequenz ist, daß nur innerhalb eines Teilbaumes eine funktionale Abhängigkeit der
Attribute existieren kann, denn es können nur die Attribute in Beziehung zueinander stehen, die durch einen Pfad verbunden sind. Dieses Kriterium ist aber nur die
notwendige Voraussetzung für die Erhaltung etwaiger funktionaler Abhängigkeiten im
IUS und stellt keineswegs ein hinreichendes Merkmal zur Bestimmung ebensolcher dar.
Vielmehr wird in den Tabellen des IUS nicht gefordert, daß Attribute andere Attribute
funktional bestimmen. Das wiederum ist die Begründung für die nicht ausgeschlossene Eigenschaft des Gesamtanfragegraphen, einer nicht vorhandenen Verbindung aller
Knoten über Pfade. Dies entspricht mögliche, voneinander unabhängige Anfragegraphen im Gesamtanfragegraphen. Die Konsequenz ist hier, daß so auch Attribute des
IUS voneinander unabhängig bei den Datenquellen angefragt werden und in solchen
Fällen nicht in Beziehung, etwa im Sinne funktionaler Abhängigkeiten, gesetzt werden
können. Im folgenden Beispiel wird aber ein verbundener Graph gegeben, d. h. zwischen
allen Knotenpaaren existiert ein Pfad.
101
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
Beispiel 4.15 Unter Vereinfachung des Beispiels 4.14 soll das Konzept der Vereinigung der Einzelanfragegraphen zu einem Gesamtanfragegraphen demonstriert werden.
Es wurde eine Anfrage spezifiziert, die alle Enzymnummern, Enzymnamen eines Stoffwechselweges ermittelt:
πec,name,stoffwechselweg(enzyme)
Die zur Attributwertanfrage notwendigen Einzelanfragegraphen sind:
Aec =
Aname1 =
Aname2 =
Astoffwechselweg =
({HKEGG,1 }, {})
({HKEGG,1 , HKEGG,2 }, {(HKEGG,1 , HKEGG,2 )})
({HKEGG,1 , HBRENDA,1 }, {(HKEGG,1 , HBRENDA,1 )})
({HKEGG,1 , HKEGG,3 , HKEGG,5 },
{(HKEGG,1 , HKEGG,3 ), (HKEGG,3 , HKEGG,5 )})
Die Vereinigung der Einzelgraphen ergibt also den folgenden Anfragegraphen:
GAec,name,stoffwechselweg = ({HKEGG,1 , HKEGG,2 , HBRENDA,1 , HKEGG,3 , HKEGG,5 },
{(HKEGG,1 , HKEGG,2 ), (HKEGG,1 , HBRENDA,1 ),
(HKEGG,1 , HKEGG,3 ), (HKEGG,3 , HKEGG,5 )})
Dies ist eben der Graph, der in Abbildung 4.3 dargestellt ist.
2
In den resultierenden Gesamtanfragegraphen existieren nun Knoten von subgoals, die
als Quellen für die in der Projektionsliste angegebenen IUS-Attribute dienen. Da ein
subgoal mehr als ein Ausgabeattribut enthalten kann, werden so möglicherweise Adapterattribute abgefragt, die für die zugrundeliegende Projektionsliste nicht notwendig
waren. Solche Adapterattribute sind zu ignorieren. So ermittelt im obigen Beispiel das
subgoal HBRENDA,1 die Adapterattribute b2 , b3 , b4 , d. h. den Enzymnamen, die katalysierte Reaktion und den Organismus. Im Sinne der Verwendung als Datenquelle für das
IUS-Attribut name sind die beiden letzten Adapterattribute also zu verwerfen.
Neben dieser Redundanz existiert eine weitere aus dem Umstand heraus, daß subgoals im Gesamtanfragegraph auftauchen, die zu keinem über die Projektionsliste der
Anfrage spezifizierten IUS-Attribute Datenquellattribute enthalten. Das ist im obigen
Beispiel beim Attribut a4 in subgoal HKEGG,5 der Fall. Keine der angefragten IUS-Attribute ec, name oder stoffwechselweg enthält ein abhängiges subgoal, das a4 liefern
soll. Trotzdem ist die implizite Anfrage dieses Adapterattributes und des IUS-Attributes map notwendig, da über diesen Knoten der Anfragepfad für den Stoffwechselweg
läuft, d. h. das subgoal HKEGG,5 zur Abfrage des IUS-Attributes stoffwechselweg
ist von der vorherigen Anfrage des Attributes a4 abhängig. Diese zur Konstruktion
eines gültigen Anfrageplanes notwendigen IUS- Hilfsattribute“ sind dann, wie im Ab”
schnitt 4.4.4 beschrieben, im Zuge der relationalen Auflösung des Anfrageresultates zu
eliminieren.
102
4.4 Verarbeitung von Datenfragen
4.4.3 Ausführung von Anfrageplänen
Die zuvor eingeführten Anfragepläne bilden die strukturelle Grundlage für Datenanfragen über integrierte Nutzerschemata in Form von Sichten integrierter Datenquellen.
Zu jeder Anfrage auf ein IUS wird ein Anfrageplan in Form eines Graphen gebildet,
der ausgeführt werden muß, um die angefragten IUS-Attribute mit Attributwerten aus
den Datenquellen zu belegen. Dazu werden die, über die Funktion source an die IUSAttribute gebundenen, subgoals von entsprechenden Adaptern, z. B. durch den Aufruf
einer URL, ausgeführt. Da für ein IUS-Attribut mehrere Adapterattribute als Datenquelle dienen, sind diese durch den Verbundoperator ⊲⊳ zu vereinigen. Die Reihenfolge
der Ausführung ist durch den Anfrageplan in Form eines Graphen derart gegeben, daß:
1. derjenige oder diejenigen Knoten bzw. subgoals zuerst ausgeführt werden, die
kein Eingabeattribut benötigen. Die Ergebnismenge von Adapterattributwerten
werden an das entsprechende IUS-Attribut über Vereinigung der Einzelresultate
der subgoals gebunden.
2. Von diesen Startknoten beginnend, werden dann alle Pfade entgegengesetzt der
durch die Funktion retrieval dependency vorgegebenen Richtung verfolgt und das
Eingabeattribut des auszuführenden subgoals mit jedem Element der zuvor berechneten Ergebnismenge des IUS-Attribut, der zuvor ausgeführten subgoals, gebunden.
3. Die an ein IUS-Attribut gebundenen Adapterattribute werden aus den entsprechenden, ausgeführten subgoals ausgewählt und zu einem mengenwertigen Attributwert vereinigt. Somit sind die Kanteneingänge in einen Knoten des Anfrageplanes als Verbundoperationen auszuführen.
Zu einer konkreten Datenanfrage im relationalen Tupelkalkül wird nun, wie zuvor beschrieben, eine Projektionsoperation π über einer Menge von IUS-Attributen I1 , . . . , Ii
und ein Gesamtanfrageplan GA berechnet. Das Ergebnis einer solchen Anfrage ist eine
Menge von Tupeln R zu einem Eigenschaftsschema I, das den in der Anfrage selektierten IUS-Attributen entspricht. Somit wird die Funktion obj aus Defintion 4.5 über die
Ausführung eines Anfrageplanes implementiert. Die Ausführung eines Anfrageplanes
kann wie folgt als rekursiver Algorithmus angegeben werden:
Execute-Query(I)
(1) berechne Anfrageplan GA zu I
(2) initialisiere ein leeres Resultat RESU LT AT := {}
(3) ermittele Menge aller IUS-Attribute start ⊆ I
zu Startknoten in GA
(4) initialisiere zu jedem si ∈ start eine leere Menge valuesi
(5) for each h mit h := (B, A) ∧ h ∈ GA.H ∧ |h.B| = 0
(6)
bestimme für subgoal h das an die Attributwerte valuesi
des IUS-Attributes si zu bindende Adapterattribut a ∈ h.A
103
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
(7)
führe subgoal h aus
(8)
valuesi ∪ h.a
(9) for each s ∈ start
(10) for each v ∈ valuesi
(11)
tupel := ({}I1 , . . . , {}Ii )
(12)
tupel.si := {v}
(13)
Execute-Dependent-subgoal(tupel, subgoals zu source(si ))
(14)
RESU LT AT ∪ tupel
(15) return RESU LT AT
Execute-Dependent-subgoal(tupel, H)
(16) if |H| = 0 then
(17) return
(18) DH := {}
(19) for each r ∈ R mit R := GA.R
(20) if r.u ∈ H then
(21)
h′ := r.v
(22)
ermittele IUS-Attribut b ∈ I zu Adapterattribut h′ .B
(23)
h′ .B := tupel.Ii
(24)
führe subgoal h′ aus
(25)
ermittele Menge aller gültigen Paare
I ′ = {(Ij , h′ .Ak ) | source(Ij ) = h′ .Ak }
(26)
for each i′ ∈ I ′
(27)
tupel.i′ .Ij ∪ i′ .Ak
(28)
DH ∪ h′
(29) Execute-Dependent-subgoal(tupel, DH)
(30) return
Die Erläuterung des Algorithmus zur Ausführung eines Anfrageplanes wird anhand
eines Beispieles durchgeführt. Dabei wird jeder Schritt des Algorithmus mit einer Beispielbelegung von Variablen illustriert.
Beispiel 4.16 Zur Veranschaulichung soll die im Beispiel 4.15 zur Demonstration benutzte Beispielprojektion πec,name,stoffwechselweg(enzyme) ausgeführt werden. Dazu wird
zu jedem Schritt des Algorithmus die Variablenbelegung am Beispiel angegeben, und die
Nummer eines etwaigen Schleifendurchlaufes ist in Klammern hinter dem Algorithmusschritt angegeben. Schleifendurchläufe geschachtelter Schleifen werden durch mehrere,
hintereinander stehende Klammern dargestellt. Auf eine vollständige, schrittweise Ausführung des Beispielanfrageplanes inklusive aller Variablenbelegungen wird verzichtet.
Mehrfachschleifendurchläufe oder rekursive Funktionsaufrufe werden verkürzt wiedergegeben:
Parameterübergabe Execute-Query(I):
Der übergebene Parameter ist die Menge von IUS-Attributen, die abgefragt werden
104
4.4 Verarbeitung von Datenfragen
sollen:
I := {ec, name, stoffwechselweg}
Schritt 1: Gemäß Abschnitt 4.4.2 wird aus allen zu den abgefragten IUS-Attributen existierenden Einzelanfrageplänen ein Gesamtanfrageplan gebildet:
GA := ({HKEGG,1 , HKEGG,2 , HBRENDA,1 , HKEGG,3 , HKEGG,5 },
{(HKEGG,1 , HKEGG,2 ), (HKEGG,1 , HBRENDA,1 ),
(HKEGG,1 , HKEGG,3 ), (HKEGG,3 , HKEGG,5 )})
Schritt 2: Erzeugung eines leeren Anfrageresultates:
RESU LT AT := {}
Schritt 3: Ermittlung aller IUS-Attribute, von denen auf die Startknoten des Gesamtanfrageplanes mittels der Funktion source eine Abbildung existiert:
start := {ec}
Schritt 4: Belegung der im vorherigem Schritt ermittelten IUS-Attribute (Startattribute)
mit einer leeren Menge von Attributwerten:
valuesec := {}
Schritt 5: Ermittlung aller Startknoten des Anfrageplanes:
h := HKEGG,1
Schritt 6: Ermittlung desjenigen Attributes aus den Ausgabeattributen des auszuführenden
subgoals des Startknotens, das einem IUS-Startattribut als Datenquelle dient:
a := a1
Schritt 7: Ausführung des entsprechenden subgoals – die Ergebnisse sind an die Ausgabeattribute gebundene Attributwerte:
n
o
h.A :=
{3.5.3.1} , {4.3.2.1} , {6.3.4.5} , {2.1.3.3}
Schritt 8: Bindung des entsprechenden IUS-Startattributs mit dem entsprechenden Ausgabeattribut des ausgeführten subgoals:
valuesec := {3.5.3.1, 4.3.2.1, 6.3.4.5, 2.1.3.3}
Schritt 9 (1): Iteration über alle IUS-Startattribute:
s := ec
Schritt 10 (1)(1): Iteration über alle Attributwerte des gewählten Startattributes:
v := {3.5.3.1}
Schritt 11 (1)(1): Berechnung einer Objektausprägung zu den angefragten IUS-Attributen
mit leeren Eigenschafts- bzw. Attributwerten:
tupel := ({}ec , {}name , {}stoffwechselweg)
105
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
Schritt 12 (1)(1): Belegung des IUS-Startattributes mit einem Startattributwert:
tupel := ({3.5.3.1}ec , {}name , {}stoffwechselweg)
Schritt 13 (1)(1): Ausführung aller vom zuvor ausgeführten subgoal abhängigen subgoals:
Execute-Dependent-subgoal(tupel, {HKEGG,1 })
Parameterübergabe Execute-Dependent-subgoal(tupel, H): Die übergebenen Parameter sind ein Ergebnistupel mit teilweise an IUS-Attribute gebundenen Attributwerten
sowie eine Menge von subgoals:
tupel := ({3.5.3.1}ec , {}name , {}stoffwechselweg), H := {HKEGG,1 }
Schritt 16: Überprüfung, ob der Subgoal-Parameter nicht leer ist:
(|H| = 0) ; false
Schritt 18: Wenn subgoals übergeben wurden, dann fahre mit diesem Schritt fort und initialisiere eine leere Menge von auszuführenden subgoals, welche sukzessive erweiter wird:
DH := {}
Schritt 19 (1): Iteration über alle Knoten des Anfrageplanes:
r := (HKEGG,1 , HKEGG,2 )
Schritt 20 (1): Überprüfung, ob das erste Tupelelement des Knotens r einem der Funktion
übergebenen subgoals entspricht:
(HKEGG,1 ∈ H) ; true
Schritt 21 (1): Wenn Schritt 20 erfüllt ist, so ergibt sich ein auszuführendes subgoal aus
dem zweiten Tupelelement, d. h. dem abhängigen Kind“-subgoal im Anfrageplan:
”
h′ := HKEGG,2
Schritt 22 (1): Ermittlung des IUS-Attributes aus dem Ergebnistupel, welches die Attributwerte enthält, die an das Eingabeattribut des zuvor ermittelten subgoals h′ zu binden
sind:
Ii := ec
Schritt 23 (1): Bindung der IUS-Attributwerte des aktuellen Ergebnistupels an das Eingabeattribut des auszuführenden subgoals:
h′ := ({3.5.3.1}; a2, a3)
Schritt 24 (1): Ausführung des subgoals – das Ergebnis sind an die Ausgabeattribute gebundene Attributwerte:
n
o
h′ .A :=
{Arginase}, {L-Arginine + H2O = L-Ornithine + Urea}
Schritt 25 (1): Berechnung der Menge aller IUS-Attribute, für die die ermittelten Ausgabeattributwerte als Datenquelle dienen:
I ′ = {(name, a2)}
106
4.4 Verarbeitung von Datenfragen
Schritt 26 (1)(1): Iteration über alle diese IUS-Attribute, die im vorherigen Schritt ermittelt worden:
i′ = (name, a2)
Schritt 27 (1)(1): Vereinigung des im Ergebnistupel enthaltenen Attributwertes eines IUSAttributes i′ mit dem entsprechenden Attributwert des ausgeführten subgoals:
tupel := {3.5.3.1}ec , {Arginase}name , {}stoffwechselweg
Schritt 28 (1): Übernahme des zuvor ausgeführte subgoals in die Menge der in diesem Funktionsaufruf ausgeführten subgoals DH = {HKEGG,2 }
Schritt 19 (2): Ermittlung des nächste subgoals im Anfragegraphen:
..
.
r := (HKEGG,1 , HBRENDA,1 )
Schritt 24 (2):
h′ .A :=
..
.
n
{Canavanese}, {L-Arginine + H2O = L-Ornithine + Urea},
o
{Human, Chicken}
Schritt 27 (2)(1): tupel := {3.5.3.1}ec , {Arginase, Canavanese}name , {}stoffwechselweg
Schritt 28 (2): DH = {HKEGG,2 , HBRENDA,1 }
Schritt 29: Rekursive Ausführung der Funktion Execute-Dependent-subgoal mit dem
momentanen Ergebnistupel und der Menge aller im aktuellen Funktionsaufruf ausgeführten subgoals:
..
.
Execute-Dependent-subgoal(tupel, DH)
Schritt 30: Beendigung des aktuell ausgeführten Funktionsaufrufes:
return
Schritt 14: (1)(1): Vereinigung der bislang abgefragten Objektausprägungen der angefragten IUS-Attribute mit dem Ergebnistupel des Schrittes 13:
n
o
RESU LT :=
{3.5.3.1}, {Arginase, Canavanese}, {Urea cycle}
Schritt 10 (1)(1): Iteration über alle Attributwerte des gewählten Startattributes:
..
.
v := {4.3.2.1}
Schritt 10 (1)(2): Iterieration über alle Attributwerte des gewählten Startattributes:
..
.
v := {6.3.4.5}
107
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
Schritt 10 (1)(3): Iterieration über alle Attributwerte des gewählten Startattributes:
..
.
v := {2.1.3.3}
Schritt 14 (1)(4): Vereinigung der bislang abgefragten Objektausprägungen der angefragten IUS-Attribute mit dem Ergebnistupel des vorherigen Schrittes:
RESU
LT :=
n
{3.5.3.1}, {Arginase, Canavanese}, {Urea cycle}
{4.3.2.1}, {Arginosuccinase, Argininosuccinate lyase}, {Urea cycle}
{6.3.4.5}, {Argininosuccinate synthase, citr.-aspartate ligase}, {Urea cycle}
o
{2.1.3.3}, {Ornithine carbamoyltransferase, citr. phosphorylase}, {Urea cycle}
Schritt 15: Ende der Anfrageausführung:
return RESU LT
2
Im Beispiel wird deutlich, daß die Anwendung der Mengenvereinigung als Datenintegrationsoperation zur Synthese eines IUS-Attributes aus mehreren Adapterattributen
von der Semantik des zugrundeliegenden Vergleichsoperators abhängt. Denn hier wird
bestimmt, welche Attributwerte gleich sind. Diese Gleichheit definiert sich über den Basisdatentyp, worauf eine Gleichheitsrelation im algebraischen Sinne definiert sein muß.
Dabei sind die Eigenschaften Reflexivität, Symmetrie und Transitivität einer Äquivalenzrelation zu gewährleisten. Da bei Adapter- bzw. IUS-Attributen die Datendomäne
bzw. der Datentyp aus dem Adapterschema bekannt sind, kann daraus der geeignete
Vergleichsoperator bestimmt werden. Voraussetzung dafür ist, daß keine Datentypkonflikte auftreten, wie sie in Abschnitt 2.3.4 beschrieben werden. In solchen Fällen sind
geeignete Datentypkonvertierungsmethoden oder Fehlerbehandlungen vorzusehen.
Weitere algebraische Operationen sind zwar im Kontext der Anfrageplanverarbeitung
nicht notwendig, spielen aber bei der Umsetzung von Anfragesprachen auf Basis der
hier vorgestellten Datenintegrationsmethode eine Rolle. So sollten etwa die algebraische
Relationen kleiner“ oder größer“ auf dem jeweiligen Datentyp definiert sein, da diese
”
”
etwa im Falle von SQL notwendige Sprachelemente darstellen.
Gerade im Anwendungsgebiet der Molekularbiologie stellt die Bereitstellung spezifischer Datentypen inklusive algebraischer Elemente, wie Operationen oder Relationen
ein Problem dar. So existieren z. B. verschiedene Schreibweisen, Synonyme, Homonyme,
die auf semantischer Ebene zu überprüfen sind. Wie in [140] vorgestellt, bietet sich hier
etwa der Einsatz von Thesauri oder Ontologien im Zusammenspiel mit hierarchischen
modellierten Datentypen an. Im Default“-Fall sollten Attribute als String-Datentyp
”
behandelt werden, was natürlich sehr restriktive Gleichheitseigenschaften zweier Attributwerte fordert, aber einfach zu implementieren ist. So werden etwa zwei Enzymnamen
108
4.4 Verarbeitung von Datenfragen
als Alternativnamen interpretiert, wenn die Anfangsbuchstaben entweder als Groß- oder
Kleinbuchstaben geschrieben werden. Alle anderen Datentypen sind Spezialisierungen
dieses Default“-Datentypes. Im so gebildeten Datentypbaum sind Datentypen derart
”
aufeinander abbildbar, daß bei Datentypkonflikten ein gemeinsamer Vaterknoten im
Baum gesucht wird, auf den dann jeweils die zuvor konfliktbehafteten Datentypen abgebildet werden.
Ein weiterer Aspekt der Anfrageverarbeitung ist die Unterstützung des relationalen
Datenmodells in Form der standardisierten Anfragesprache SQL. So ist das Anfrageergebnis relational aufzulösen.
4.4.4 Relationale Auflösung der Anfrageresultate
Das hier vorgestellte Datenmodell RIND stellt ein kanonisches Basismodell dar, das in
das jeweilige Zieldatenmodell der angebotenen Schnittstelle einer konkreten Implementierung transformiert werden muß. Wie eingangs erwähnt wurde, erfolgt die Umsetzung
des in diesem Kapitel vorgestellten Konzeptes in Form des Datenbankintegrationssystems BioDataServer. Als Zieldatenmodell wurde hierzu das relationale Datenmodell
gewählt. Deshalb soll in diesem Abschnitt auf die Transformation von RIND-Anfrageergebnissen, die in Form von Objekteigenschaftsausprägungen gemäß Definition 4.5
vorliegen, auf das relationale Modell eingegangen werden. Die relationalen Basisoperationen werden nicht direkt über die vorgestellen Operationen des Datenmodells RIND
umgesetzt. Vielmehr sind relationale Anfragen auf im Sinne von Abschnitt 4.4.1 gültige
IUS-Anfragen zu reduzieren. Das bedeutet, daß vor allem Selektions- und Verbundoperationen aus einer relationalen Anfrage entfernt werden müssen, um nachträglich auf
das zu einer Relation aufgelöste IUS-Anfrageergebnis angewandt zu werden.
Nachteilig sind hierbei augenscheinlich die somit fehlenden Möglichkeiten der Anfrageoptimierung. So ist es nicht möglich, hochselektive Selektionsbedingungen auf Ebene
der Datenquellen durchzuführen, um so die Menge der abzufragenden Tupel auf der
Ebene der Datenquellen zu reduzieren. Aus der Motivation des vorgeschlagenen Ansatzes heraus, insbesondere unter der Annahme beschränkter Zugriffsmuster auf Datenquellenebene, ergibt sich diese Einschränkung. Es kann somit zwar jede konkrete
Implementierung des vorliegenden Konzeptes den vollen Sprachumfang relationaler Anfragesprachen zur Verfügung stellen, ist aber weniger als sogenanntes read-only-OLTPSystem geeignet. Dieser Aspekt findet insbesondere im Kapitel 5 weitergehende Beachtung.
Eine Ausnahme bildet dabei der natürliche Verbund, der direkt bei den Datenanfragen an das IUS in Form des vorgestellen RIND-Operators ⊲⊳ umsetzbar ist. So sind also
relationale Anfragen der Form:
select A1 , . . . , An
from T1 natural join T2
möglich.
Diese Anfrage kann dann gemäß der im Abschnitt 4.2.3 eingeführten IUS-Tabellen T
109
Kapitel 4 Ansatz zur Integration molekularbiologischer Datenbanken
und den darauf gültigen Operationen der Projektion π und des natürlichen Verbundes
⊲⊳ aus den Definitionen 4.10 und 4.12 in die IUS-Anfrage
πA1 ,...,An (T1 ⊲⊳ T2 )
transformiert werden.
Das Ergebnis von IUS-Anfragen ist eine Eigenschaftsausprägung O = obj(T ), und ist
in eine Relationen R zu überführen. Dazu kann sich der Methodik zur Abbildung von
Eigenschaftsausprägungen auf das Relationenmodell aus Abschnitt 4.1.3 bedient werden. Der folgende Algorithmus löst so die Eigenschaftsausprägung O zu einer Relation
R auf:
(1)
(2)
(3)
(4)
(5)
(6)
R := {}
for each o ∈ O
r := {()}
for each a ∈ T
r := r × oa
R := R ∪ r
Beispiel 4.17 In Abschnitt 4.1.3 wurde bereits ein entsprechendes Beispiel zur Methode der relationalen Auflösung gegeben, so daß an dieser Stelle das Ergebnis der
relationalen Auflösung eines IUS-Anfrageergebnisses aus Beispiel 4.16 ohne die schrittweise Abarbeitung des angegebenen Algorithmus direkt angegeben werden kann:


(3.5.3.1,
Arginase,
Urea
cycle)








(3.5.3.1,
Canavanese,
Urea
cycle)








(4.3.2.1,
Arginosuccinase,
Urea
cycle)






(4.3.2.1, Argininosuccinate lyase, Urea cycle)
R =
(6.3.4.5, Argininosuccinate synthase, Urea cycle) 






(6.3.4.5, citrulline-aspartate ligase, Urea cycle) 








(2.1.3.3,
Ornithine
arbamoyltransferase,
Urea
cycle)






(2.1.3.3, citrulline phosphorylase, Urea cycle)
2
4.5 Resümee
Gegenstand dieses Kapitels war die Erarbeitung der theoretischen Grundlagen für eine mediatorbasierte Datenbankintegration unter Nutzung beschränkter Zugriffsmuster
der zu integrierenden Datenquellen. Zu diesem Zweck wurde auf der Grundlage des
110
4.5 Resümee
relationalen Datenmodells das relationale Integrationsdatenmodell (RIND) vorgeschlagen. Hier wurden relationale Konzepte auf mengenwertigen Objekteigenschaften angewendet. Darauf aufbauend wurden drei Ebenen von Datenschemata als notwendige
RIND-Instanzen in einer Integrationsarchitektur eingeführt. Die zur Ausführung der
Integrationprozesse notwendigen Operationen wurden für das RIND-Modell definiert.
Das beinhaltete die Einführung und Definition von Anfrageplänen, die auf dem Konzept
von subgoals basieren. Subgoals wiederum nutzen ausschließlich die RIND-Operationen.
Zur Ausführung dieser Anfragepläne wurde ein Algorithmus erarbeitet und vorgestellt.
Mit der Erläuterung eines Algorithmus zur relationalen Auflösung der Resultate von
Anfrageplanausführungen schloß dieses Kapitel.
111
Kapitel 5
Datenbankintegrationssystem
BioDataServer (BDS)
Aus den zuvor in Kapitel 3 aufgezeigten Vor- und Nachteilen der bestehenden Integrationsansätze wird deutlich, daß ein kombinierter Ansatz vorteilhaft ist, der die speziellen
Anforderungen und Gegebenheiten der Bioinformatik berücksichtigt. Auf Basis des zuvor entwickelten, relationalen Integrationsdatenmodells und der darauf aufbauenden
Methodik einer Datenbankintegration wurde ein Softwaresystem entworfen und durch
den BioDataServer (BDS) [141] als Mediator-Wrapper-Architektur unter Nutzung des
Global-as-View-Ansatzes implementiert.
Der Fokus des BioDataServers liegt in einer homogenen, integrierten Nutzung molekularbiologischer Datenquellen unter Offerierung standardisierter, plattformunabhängiger Schnittstellen. Aufbauend auf den Erfahrungen bei der Implementierung des BDS
und dessen Anwendung in verschiedenen Projekten, wie sie in Kapitel 6 vorgestellt werden, wird zu Beginn dieses Kapitels der Entwurf einer Datenbankintegrationssoftware
gegeben. Anschließend wird eine existierende Implementierung vorgestellt, die wesentliche Teile der konzipierten Softwarearchitektur umsetzt.
Um das gesamte Potential semantisch in Beziehung stehender aber physikalisch verteilter und strukturell heterogener molekularbiologischer Daten auszuschöpfen, müssen
alle relevanten Datenquellen als eine virtuelle, miteinander vernetzte, verteilte Datenbank nutzbar gemacht werden. Diese Datenquellen werden unter Nutzung verschiedenster Techniken und Methoden als isolierte Knoten eines globalen Datenbanknetzwerkes
aufgefaßt. Die Kanten dieses Netzwerkes sind basierend auf Methoden der Web-Technologie, wie etwa HTML-Hyperlinks, zu interpretieren. Hierbei wird zwar die Navigation
zwischen den Datenquellen unterstützt, die Möglichkeit komplexer Datenanfragen über
wohlstrukturierten Datenschemata ist nicht gegeben. So sind Anfragen über relational
modellierten und integrierten molekularbiologischen Datenquellen, wie z. B. Verbünden,
Gruppierungen oder indexunterstützten Ähnlichkeitsanfragen, als Voraussetzung von
Datenanalysen über isolierten, heterogenen Datenquellen, schwerlich möglich. Jedoch
hängen Bioinformatikanwendungen, die mit molekularbiologischen Daten arbeiten und
Aufgaben, wie data retrieval“, knowledge discovery“ oder Data Mining“ umsetzen,
”
”
”
von der Existenz eben solcher komplexen Anfragesprachen auf integrierten molekularbiologischen Datenquellen ab. Demzufolge erscheint eine Datenbankintegrationsmethode geeignet, die es ermöglicht, eben solche Anwendungen zu unterstützen, indem eine
113
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
virtuelle, nicht materialisierte Integration als Vorstufe zum Import in eine enge, materialisierte Integrationslösung mit der Unterstützung komplexer Anfragesprachen im
Kontext von Data Warehouses bereitgestellt wird.
Somit wird in diesem Kapitel ein Integrationssystem von in verschiedener Hinsicht
heterogenen, verteilten aber semantisch überlappenden Datenquellen vorgestellt, das
auf den im Kapitel 4 eingeführten Konzepten beruht und erstmals in [136] beschrieben
wurde.
5.1 Architektur einer nutzerspezifischen
Datenbankintegration
Auf Basis der in Kapitel 3 gewonnenen Erkenntnisse bezüglich der Eigenschaften molekularbiologischer Datenquellen und der Vor- und Nachteile existierender Techniken
und konkreter Systeme zur Datenbankintegration in der Bioinformatik, wird in diesem Abschnitt eine daraus abgeleitete Systemarchitektur vorgeschlagen. Diese soll die
besonderen Erfordernisse des Umfeldes der vorliegenden Arbeit, insbesondere im Anwendungskontext bioinformatischer Software, berücksichtigen und so als Basis für eine
implementierbare Datenbankintegrationslösung dienen.
5.1.1 Anforderungen
Mit den Eigenschaften der verteilten Datenquellen in der Bioinformatik, so wie sie in
Abschnitt 3.1 beschrieben wurden, muß ein Datenbankintegrationssystem in diesem
Anwendungskontext mit einem hohen Grad an Autonomie der Datenquellen umgehen.
Es ist darüber hinaus davon auszugehen, daß es nicht möglich ist, in die Datenquellen
bzw. die Remote Data Sources (RDS) hinsichtlich
1. der Autonomie der angebotenen Schnittstelle oder
2. der Autonomie des Exportdatenschemas
einzugreifen.
Insbesondere sind die vorhandenen, typischerweise beschränkten Zugriffsmuster auf
die RDS von dem Datenbankintegrationssystem als gegeben zu betrachten. Wie in den
vorhergehenden Kapiteln motiviert, sind die Zugriffsoperationen auf die RDS auf nur
lesende limitiert. Weitere Aspekte der existierenden Datenverteilung und -heterogenität,
die von dem Integrationsansatz zu beachten sind, sind:
3. Datenfragmentierung und -allokation,
4. kanonische Datenmodellierung sowie
5. Datenschemaintegration.
114
5.1 Architektur einer nutzerspezifischen Datenbankintegration
Diese Aspekte werden durch die im weiteren vorgestellte Systemarchitektur des Datenbankintegrationssystems BioDataServer behandelt. Diese fünf Anforderungen begründen die im folgenden vorgestellten Softwareentwurfsentscheidungen.
Beim Entwurf eines Datenbankintegrationssystems ist eine der im Umfeld der Bioinformatik vorgeschlagenen Systemarchitekturen (siehe hierzu Abschnitt 3.2.1) zu wählen, die entweder (a) materialisierte oder (b) eine sichtenbasierte Datenbankintegration
umsetzt.
Materialisierte Datenbankintegration
Vorteile
Bei diesem Typ der Datenbankintegration sind eine hohe Verfügbarkeit der
bereitzustellenden integrierten Datenbank mit kurzen Antwortzeiten, ausdrucksstarken Anfragesprachen zur Formulierung komplexer, deklarativer
Anfragen und Unabhängigkeit gegenüber Schemaänderungen der Datenquellen als Positivmerkmale zu nennen. Somit kann der Nutzer einer solchen
Integrationslösung das volle Potential aktueller, kommerzieller DBMS zur
Analyse integrierter molekularbiologischer Daten nutzen. Daraus ergibt sich
ein weiteres Argument, die Robustheit der Software. Da durch eine materialisierte Integration der Einsatz von kommerzieller DBMS-Software möglich wird, die, im Gegensatz zu akademischen Implementierungen, die nötige
Stabilität und Skalierbarkeit aufweist, kann diese Architektur im unternehmenskritschen Bereichen eingesetzt werden.
Nachteile
Demgegenüber stehen die Nachteile der Arbeit mit, von den Datenquellen
entkoppelter, offline“-Daten, die möglicherweise veraltet sind. Dazu kommen
”
zeit- und speicherkomplexe Update-Operationen, die darüber hinaus Probleme der Schemaevolution auf Datenquellenebenen und der damit notwendigen
Schematransformationen auf Integrationsebenen verursachen. Jedoch ist die
Bereitstellung von konsistenten, integrierten Datenbanken für Analysesoftware mit häufigen und komplexen Datenzugriffsoperationen unumgänglich.
Sichtenbasierte Datenbankintegration
Vorteile
Bei einer sichtenbasierten Integration autonomer Datenquellen ist die Vermeidung redundantem und ressourcenintensivem Kopierens ganzer Datenbanken. Auch wird so ein zu jedem Zeitpunkt ein aktueller integrierter Datenbestand gewährleistet.
Nachteile
Der Nachteil der Schemaevolution auf Datenquellenebene existiert auch hier.
Dieser wird jedoch auf die Anwendungsebene verlagert, da hier die notwendigen Änderungen im integrierten, globalen Datenschema adaptiert werden
müssen. Weiterhin birgt bei dieser Architektur die starke Abhängigkeit von
115
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
den Datenquellen weitere Probleme. Diese sind u. a. die teilweise stark eingeschränkte Mächtigkeit der Anfrageschnittstelle, Verfügbarkeitsprobleme,
etwa auf Netzwerkebene, starke Belastung des Netzwerkes und somit sehr
schlechtes Antwortverhalten.
Als Resultat dieser Betrachtungen fällt die erste Designentscheidung, für den hier
zu entwerfenden Datenbankintegrationsansatz, auf einen kombinierten Ansatz, der die
Vorteile der jeweiligen Lösungen zu einem anwendbaren System vereinigt. So wird hier,
ähnlich einem Data Warehouse, eine Systemarchitektur vorgeschlagen, die aus einer materialisierten Ebene besteht und durch eine sichtenbasierte Integrationslösung ergänzt
wird, die als homogene Importquelle dient.
Die zweite Designentscheidung ergibt sich somit in Form einer engen Datenbankintegration, die ein integriertes Datenbankschema über alle zu integrierenden Datenquellen legt und so ein homogenes, wohlstrukturiertes und semantisch integriertes
Datenschema bereitstellt, das die begrenzten Möglichkeiten disjunkter Datenschemata überwindet. So wird es möglich, daß Anwendungen auf globalen Schemata arbeiten
können und somit nicht länger an die individuelle Struktur jeder einzelnen Datenquelle
gebunden sind. Weiterhin können so in den integrierten Schemata semantische Beziehungen zwischen den ansonsten inkoherenten Datenbanken zentral modelliert und gewartet werden, was üblicherweise der Anwendungsprogrammierer in der Bioinformatik
für jedes Werkzeug selbst durchführen mußte. Somit wird in die Systemarchitektur ein
relationales DBMS eingebettet, welches alle aktuellen technischen Möglichkeiten zur
Datenanalyse anbieten kann und über Standardschnittstellen auf eine zu implementierende sichtenbasierte Integrationssoftware als Importschnittstelle zugreift.
Für die dritte Designentscheidung wurde beachtet, daß typischerweise seitens
der Anwender die Anforderung an eine Datenbankintegration existiert, daß eigene, sogenannte in-house“-Daten in die Integration mit einbezogen werden sollen. Somit müssen
”
die Anwenderdaten in das integrierte Schema bzw. in die Datenbank mit aufgenommen
werden, aber nur ausgewählten, die jeweiligen Datenschutzanforderungen erfüllenden
Anwenderkreisen zugänglich sein. Dementsprechend muß gewährleistet sein, daß in keinem Fall diese privaten Daten während der Anfrageverarbeitung über das öffentliche
Netzwerk, etwa zu öffentlichen Datenbanken, gelangen, um dort als z. B. Selektionskonstante zu dienen. Auf diese Weise dürfen keine privaten Daten außer Haus gelangen.
Somit ist eine materialisierte in-house“-Datenbankintegration zu bevorzugen.
”
Die vierte Designentscheidung geht davon aus, daß jede Anwendergruppe verschiedenste Anforderungen an den Inhalt der integrierten Datenbank hat, was bedeutet,
daß die vorzuschlagende Systemarchitektur adaptiv genug sein muß, um flexibel relevante Datenquellen zusammenzuführen und in die integrierte Datenbank aufzunehmen.
Es ist also eine Komponente nötig, die dem Integrationssystem flexibel Datenquellen
zugänglich macht. Dieses Konzept wird in Form von Adaptern bzw. Wrappern vorgeschlagen, die eine eindeutig definierte Schnittstelle implementieren, um der Importebene, die auf einer nicht-materialisierten Datenbankintegration basiert, als homogene
Kapselung der Datenquellen zu dienen. Eine weitere Begründung zur Nutzung von Adaptern ist das vielfache Interesse an eher übersichtlichen, spezialisierten integrierten
116
5.1 Architektur einer nutzerspezifischen Datenbankintegration
Datenbanken, was es überflüssig macht, gesamte Datenquellen in eine materialisierte
Datenbank zu importieren. Somit werden auch unnötige Ressourcennutzungen vermieden, was wiederum die Anwendbarkeit des Integrationssystems erhöht. Denn je kleiner
das zu importierende Datenspektrum hinsichtlich Datenschema und Datenvolumen ist,
umso besser ist das Gesamtsystem zu warten.
Somit können die Anforderungen wie folgt zusammengefaßt werden:
1. Schemaintegration
2. Materialisierung
3. Unterstützung von Datenquellen mit beschränkten Zugriffsmustern
4. Bereitstellung komplexer, deklarativer Anfragesprachen
5. Offerierung von Standard-APIs
6. Datenschutz
Diese Anforderungen führen zur im folgenden vorgestellten Systemarchitektur eines
Datenbankintegrationssystems in der Bioinformatik.
5.1.2 Systemarchitektur
Auf Basis der zuvor gemachten Betrachtungen wird in Abbildung 5.1 die Gesamtsystemarchitektur des Datenbankintegrationsansatzes im Umfeld der Bioinformatik schematisch vorgeschlagen.
Auf unterster Ebene sind die Datenquellen, die sogenannten remote data sources“
”
(RDS), die über das Internet oder als flat-files über Dateisysteme und diverse Schnittstellen zugänglich sind. Diese Datenquellen werden über die Adapter gekapselt, die
Datenextraktionsanfragen von der Integrationsschicht in Form der in Kapitel 4.3 eingeführten Integrationsopertoren umsetzen und im RIND-Modell die abgefragten Datenobjekte homogenisiert zurückliefern. Zum Zwecke des homogenen Zugriffs auf die
Funktionalität der Adapter ist eine einheitliche, funktionsbasierte Schnittstelle definiert. Eine detaillierte Beschreibung der Adapter wird im Abschnitt 5.4 gegeben.
Der Datenbankintegrationsdienst, der sogenannte BioDataServer, ist die zentrale
Komponente der Architektur und basiert wiederum auf einem Mediatoransatz. Die
Kernfunktionalitäten des BDS bestehen in der Anfragehomogenisierung und der Datenintegration, die Konzepte des RIND-Datenmodells und die darauf definierten Operationen umsetzen. Die als Dienst konzipierte Systemkomponente nimmt in einer SQLAdaption spezifizierte Datenanfragen entgegen, löst diese auf der Basis Integrierter Nutzerschemata (IUS) (vergleiche hierzu Abschnitt 4.2) zu Anfrageplänen auf und führt
diese aus. Die Datenanfragen werden gegen existierende, dem Integrationsdienst zur
Verfügung zu stellenden, integrierten Nutzerschemata gestellt. Dabei werden die dort im
Anfrageplan organisierten Datenextraktionsoperationen auf die funktionale Schnittstelle der jeweils angefragten Adapter abgebildet. Um redundante Extraktionsoperationen
117
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
Abbildung 5.1: Schematische Darstellung der Systemarchitektur des BDS aus [136]
auf den RDS zu vermeiden, werden bereits extrahierte Daten in einem Cache temporär
gepuffert. Während der laufenden Ausführung des Anfrageplanes werden bereits ermittelte Teilanfrageresultate, die in Form von Tupeln mengenbasierter Attribute vorliegen,
mittels Mengenvereinigung zusammengeführt und relational aufgelöst. Auf den so bereitgestellten relationalen Tupel mit atomaren Attributwerten werden in der Anfrage
formulierte relationale Operatoren ausgeführt, und das Ergebnis sukzessive über die
JDBC-Schnittstelle bereitgestellt, bis der Anfrageplan vollständig abgearbeitet wurde.
Da die an dieser Stelle skizzierte Funktionsweise des Datenbankintegrationsdienstes
BDS eine Kernfunktionalität der Gesamtarchitektur darstellt, wird auf diesen Dienst
im Abschnitt 5.2 detailliert eingegangen.
Die SQL-Anfragen an den Integrationsdienst werden hauptsächlich mit dem Zweck
eines Imports in ein DBMS zur Umsetzung einer materialisierten Datenbankintegrati-
118
5.2 Mediatorsystem des BioDataServer
on formuliert. Eine dazu alternative Nutzung des BDS als nicht-matarialisierte, onlineIntegration ist durch die offene Systemarchitektur möglich und kann in entsprechenden
Anwendungsszenarien, wie z. B. dem explorativen Arbeiten auf entfernten Datenquellen, von Bedeutung sein. Die eigentliche Bedeutung des BDS erschließt im Zusammenhang mit Datenimportwerkzeugen. Solches Werkzeuge importieren zyklisch aus dem
BDS integrierte öffentliche Daten und Daten aus in-house“-DBMS in ein Anwender”
DBMS mit vordefinierten, integrierten Datenschemata. Dieser Prozeß entspricht dem
Import in ein Data Warehouse, wobei durch die im BDS vorhandenen IUS-Schemata individuell und vor allem selektiv der zu integrierende Datenbestand spezifiziert
werden kann. So ist es nicht notwendig, öffentliche Datenbanken vollständig in einer
Staging Area zu materialisieren. Diese Ebene eines Data Warehouses ist bei der hier
vorgestellten Architektur somit nur im Falle zu archivierender oder zu versionisierender externer Daten notwendig. Ein Datenimportwerkzeug zur Kopplung von BDS und
Data Warehouse kann durch den Hersteller des Anwender-DBMS, durch kommerzielle
Datenextraktionssoftware [142] bereitgestellt werden oder mittels der, im Abschnitt 6.1
vorgestellten, DBMS-unabhängigen Eigenentwicklung Debbie genutzt werden.
Zusammenfassend bildet die Systemarchitektur einen hybriden Ansatz. Auf der einen
Seite nutzen die Bioinformatikanwendungen der Anwender ein materialisiert integriertes DBMS. Auf der anderen Seite dient eine sichtenbasierte Datenbankintegration als
homogene Importdatenquelle, die auf einer Mediator-Wrapper-Architektur beruht und
nutzerspezifische integrierte Datenschemata unterstützt.
5.2 Mediatorsystem des BioDataServer
Der Datenbankintegrationsdienst BioDataServer (BDS) ist im Anwendungskontext einer Client-Server-Architektur konzipiert worden. Dabei ist er als vollständig autonomer
Bestandteil in die Gesamtarchitektur der, in diesem Kapitel vorgeschlagenen, Datenbankintegrationsarchitektur eingebettet. Basierend auf dem Konzept einer MediatorWrapper-Architektur ist ein Softwaresystem entstanden, das aus sieben Komponenten besteht, die untereinander über definierte Schnittstellen interagieren. Das UMLKomponentendiagramm der Abbildung 5.2 stellt dies dar.
Ausgehend von der Anwenderschnittstelle, die als Bestandteil des BioDataServers
die Kommunikation mit den Clients übernimmt, soll das Gesamtsystem im folgenden
beschrieben werden. Die Anwenderschnittstelle übernimmt die Aufgabe der authentifizierten Kommunikation zwischen den verschiedenen Anwendern auf der Client-Seite,
die über mehrere parallele Sitzungen am System angemeldet sind und den Zugriff auf
serverseitigen Betriebselementen des Dienstes. Das sind (a) der Zugriff auf Nutzerschemata, (b) Weiterleitung von BDS-SQL-Anfragen (vergleiche hierzu Abschnitt 5.2.4) an
die Anfrageverarbeitung, (c) Bereitstellung von Funktionalitäten zur externen Überwachung und Kontrolle der Ausführung von Anfrageplänen sowie (d) das Ausliefern von
Anfrageergebnissen an den Client. Dabei wird über ein einfaches, proprietäres TCP/IPProtokoll, das in Abschnitt 5.2.3 vorgestellt wird, die Möglichkeit geboten, einen JDBCTreiber und ODBC-Treiber als API-Schnittstelle für Datenbankanwendungen bereitzu-
119
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
Abbildung 5.2: UML-Komponentendiagramm des BDS
stellen, so wie sie in Abschnitt 5.2.4 beschrieben werden. Für die externe Kontrolle
der Ausführung von Anfrageplänen und den Zugriff auf die Nutzerschemata ist keine
Unterstützung einer Standard-API vorgesehen.
Die Komponente Anfrageverarbeitung nimmt eine im BDS-SQL-Dialekt spezifizierte
Anfrage entgegen, zerlegt diese in relationale Operationen und bildet diese auf RINDOperationen ab. Unter der Verwendung genau eines Nutzerschemas wird zu den abgefragten Attributen ein Anfrageplan laut Definition 4.14 berechnet. Dieser wird dann an
eine Instanz der Anfrageplanausführung übergeben.
Ein der Komponente Anfrageplanausführung bereitgestellter Anfrageplan wird nun,
gemäß des in Abschnitt 4.4.3 angegebenen Algorithmus, ausgeführt. So werden also subgoals gemäß der bestehenden Abhängigkeiten ausgeführt, indem diese an die jeweiligen
Adapter übergeben werden. Falls für ein solches subgoal von der Cache-Komponente
ein Anfrageergebnis einer vorherigen Ausführung bereitgestellt werden kann, wird dieses anstelle einer Adapteranfrage gemäß vorgegebener Gültigkeitsbedingungen genutzt.
Verschiedene Anfragepläne zu verschiedenen Datenanfragen werden parallel ausgeführt.
120
5.2 Mediatorsystem des BioDataServer
Die Ausführung kann von priviligierten externen Anwendern überwacht und gegebenenfalls beeinflußt werden.
Die Adapterkomponente verwaltet alle verfügbaren Adapter des Mediators. Ein flexibler Mechanismus zum dynamischen An- und Abmelden von Adaptern für verschiedene Datenquellen wird hier umgesetzt. Der Zugriff erfolgt einheitlich über eine Funktionsschnittstelle. Dazu gehören die Ausführung von subgoals (vergleiche hierzu Abschnitt
4.3.2), Metainformationen zu den so angekoppelten Datenquellen, wie u. a. das Remote
Export Schema (RES).
Die durch die Ausführung eines Anfrageplanes ermittelten Attributwerte sind zu Tupeln zusammenzustellen und über die Komponente der Anwenderschnittstelle an den
Client zu übergeben. Diese Aufgabe wird von der Komponente Ergebnisauslieferung
umgesetzt. Dazu gehört auch die nachträgliche Anwendung relationaler Operationen
der eingehenden BDS-SQL-Anfrage, die vor der Transformation in die RIND-Operationen entfernt wurden. Dabei muß gewährleistet werden, daß die bereits vollständig
vorliegenden Tupel sukzessiv ausgeliefert werden können, soweit dies durch die BDSSQL-Anfrage möglich ist. Bei einem Join etwa, der hier nachgebildet werden muß, ist die
Auslieferung erst nach vollständiger Abarbeitung eines Anfrageplanes und dem anschließenden Verbund möglich. Darüber hinaus wird von dieser Komponente kontrollierend
auf die Ausführung von subgoals eingewirkt. So werden über time-out-Mechanismen
nicht abgearbeitete subgoals erkannt und das so fehlende Ergebnis auf einen Fehlerwert
gesetzt. So wird sichergestellt, daß eine Anfrage auch bei temporärer Nichtverfügbarkeit von Datenquellen nicht komplett zurückgewiesen werden muß, was insbesondere
bei längeren Datenimporten von Vorteil ist.
5.2.1 Nutzerspezifischen Datenschemata
Ein integraler Bestandteil des Mediators sind die Integrated User Schemata (IUS), wie
sie in Abschnitt 4.2.3 eingeführt wurden. Diese Datenschemata realisieren den Globalas-View-Ansatz (GaV) für den BDS-Mediator. Wie in Abschnitt 2.3.3 beschrieben wurde, hat der GaV-Ansatz den Vorteil einer einfachen Anfrageverarbeitung auf Grundlage
konstanter, globaler Schemata. Der mögliche Nachteil von Schemaänderungen auf Ebene der Datenquellenschemata, die vom IUS adaptiert werden müssen und somit globale
Schemata variabel werden, kann durch das Adapter Schema (AS) bis zu einem gewissen
Maße abgefangen werden. Betrachtet man das gesamte Spektrum molekularbiologischer
Datenquellen, so sind diese zwar einer Schemaevolution unterworfen, die sich aber zum
großen Teil auf das Zufügen neuer Attribute beschränkt. Weiterhin sind durch verschiedene Initiativen und Standards (vergleiche Abschnitt 3.1.1) stabile Datenschemata auf
Datenquellebene vorhanden. Auch sind die IUS als kleine, spezialisiert integrierte Datenschemata konzipiert, die einige wenige Attribute der Datenquellen integrieren und
so nur ein geringes Potential an Adaptionen erwarten lassen.
Die Anforderungen der Anwender bzw. Anwendungen an eine integrierte, globale
Sicht auf molekularbiologische Datenquellen lassen sich in Form von IUS spezifizieren.
Im Klassendiagramm aus Abbildung 5.3 sind die Komponenten der vom BioDataServer
genutzten IUS dargestellt. Ein IUS-Schema besteht also aus mehreren Tabellen, denen
121
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
Abbildung 5.3: UML-Klassendiagramm der Nutzerschemata
jeweils einer nicht leeren Menge von Objekten der Klasse Attribute zugeordnet ist.
Jedem Attribut ist ein oder sind mehrere Adapterschemaattribute in Form der Klasse SourceAttribute als Datenquelle zugeordnet. Weiterhin hat ein Attribut einen
bestimmten Datentyp, der die Attributwerte aufnimmt und auf dem zumindest die
Basisoperationenen <, > und = implementiert sind. Die Klasse SourceAttribute
identifiziert über entsprechende Attribute das Adapterattribut eindeutig, das als Datenquelle dient. Auch ist jeder Instanz der Klasse SourceAttribute ein Datentyp
zugeordnet. Die Datentypen der Klasse Attribut und der referenzierten Adapterschemaattribute können unterschiedlich sein. Eine notwendige Transformation bzw. Datentypkonvertierung wird vom Mediator vorgenommen.
Neben diesen, die Datenstruktur beschreibende Elemente, sind Daten zu den zuvor
eingeführten Anfrageabhängigkeiten zwischen den IUS-Attributen im Schema zu erfassen. Dazu dient die Klasse Dependency. Eine Instanz der Klasse SourceAttribute
ist somit einem oder keinem Objekt der Klasse Attribute zugeordnet. Diese Assoziationen werden vom Mediator genutzt, um Anfragepläne zu berechnen.
Das modellierte Klassendiagramm kann zur Basis genommen werden, um daraus die
Datenstruktur eines Nutzerschemas abzuleiten. Im Anhang B.1 sind die, auf dieser
Basis implementierten JAVA-Klassen, um die Funktionen reduziert, enthalten.
122
5.2 Mediatorsystem des BioDataServer
Zur persistenten Repräsentation der vorgestellten Klassenstruktur der IUS-Schemata
wurde ein Dateiformat spezifiziert, das alle notwendigen Attributwerte der JAVA-Klassen speichert und ohne weitere Werkzeuge editierbar ist. Aus der Basisimplementierung
des BioDataServers resultiert eine proprietäre Syntax des Dateiformats der IUS-Schemata. Die Syntax für ein IUS-Nutzerschema kann in erweiterter Backus-Naur-Form in
Abbildung 5.4 definiert werden. Eine Schemadatei besteht also aus einer Anzahl von
<scheme> :== ’scheme’ <ID> {<class>}+
<class> :== ’class’ <ID> ’{\n’ {<attribute>}+ ’}\n’
<attribute> :== <ID> ’:’ <data type> {<data source>}+ ’;\n’
<data source> :== <attribute source> [<retrieval dependency>]
<attribute source> :== ’<’ <ID> ’,’ <ID> ’,’ <ID> ’>’
<retrieval dependency> :== ’:’ <ID> ’->’ <ID>
<data type> :== ’string’|’integer’|’float’|’boolean’
Abbildung 5.4: Syntaxdiagramm der IUS-Nutzerschemata
Blöcken, die in geschweiften Klammern die Tabellen und ihre Attribute umschließen.
Die Attribute werden durch Zeilenendezeichen und einem ;“ voneinander getrennt
”
und bezeichnen durch ein oder mehrere in <“ und >“ eingeschlossene Tripel von Ad”
”
aptername, Adaptertabellenname und Adapterattributname die Datenquelle. Hinter
jeder Datenquelle ist mit der Zeichenkette ->“, die einen Pfeil andeutet, die Anfrage”
abhängigkeit zum nachfolgend notierten Attributnamen aus der gleichen IUS-Tabelle
vermerkt. Bei dieser Syntaxbeschreibung ist zu beachten, daß der Aufbau des Elementes
ID nicht weiter spezifiziert wird. Hier gelten die in Programmiersprachen üblichen Regeln für Bezeichner. Zur Illustration ist im Anhang B.3 ein in dieser Notation abgelegtes
IUS-Nutzerschema enthalten.
Zur Unterstützung der Schemaerstellung wurden Konzepte und Werkzeuge entwickelt, die es erlauben, unter Zuhilfenahme von Ontologien und eines Client-ServerZugriffes, auf die IUS-Schemata einer BDS-Installation eine komfortable Erstellung von
individuellen Nutzerschemata vorzunehmen. So nutzt das Softwaresystem SEMEDA,
ein System zur semantischen Datenbankintegration, das in Abschnitt 6.5 vorgestellt
wird, diese Möglichkeiten. Ferner ist ein GUI zum entfernten Editieren der IUS-Schemata implementiert worden, welches im Screenshot 5.5 dargestellt ist.
5.2.2 Schnittstelle des BioDataServer
Die Kommunikation zwischen dem BioDataServer und den Clients erfolgt über das
TCP/IP-Protokoll. Zur Umsetzung dieser Kommunikationsschnittstelle wurde ein auf
TCP/IP aufsetzendes, verbindungsorientiertes Protokoll spezifiziert. Dazu bindet sich
der BDS an ein Socket des Hosts und startet bei jeder Verbindungsanforderung einen
Leichtgewichtsprozeß (Thread), der die weitere Kommunikation mit dem Client übernimmt. Die Entscheidung, einen eigenen Mechanismus inklusive eines proprietären
Kommunikationsprotokolls als Schnittstelle zum BDS zu konzipieren, motiviert sich
123
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
Abbildung 5.5: Screenshot des IUS-Schemaeditors
aus der notwendigen Leichtgewichtigkeit des zu implementierenden Softwaresystems.
Es soll möglich sein, den Integrationsdienst mit einer schlanken, robusten und intuitiv
zu nutzenden Schnittstelle ohne Frameworks, wie etwa SOAP, CORBA oder RMI, zu
nutzen. Weiterhin sollte diese Schnittstelle funktional genug sein, um sogenannte highlevel-APIs, wie etwa JDBC oder ODBC darauf implementieren zu können.
Wie im Zustandsdiagramm in Abbildung 5.6 dargestellt wird, beruht der BDS auf
zwei Zuständen. Der Server wartet auf Verbindungsanforderungen und startet gegebenenfalls einen neuen Leichtgewichtsprozeß, der an den neuen Client-Server-Socket als
Ein- und Ausgabestream gebunden wird. Diese sogenannte dedizierte Client-ServerKommunikation, bei der jeder aufrufende Client einen dedizierten Prozeß zur Verarbeitung der Client-Kommandos zugewiesen bekommt, ist eine Möglichkeit, um eine
gleichmäßige Verteilung der Serverressourcennutzung zu gewährleisten. Die so aufgebaute TCP/IP-Verbindung ist bidirektional, wobei eine einzelne Client-Server-Verbindung entweder senden oder empfangen kann. So liegt eine synchrone Kommunikation,
ähnlich dem HTTP-Protokoll, vor.
Wie im Aktivitätsdiagramm 5.7 dargestellt, stehen nach einem erfolgreichen Verbindungsaufbau zum BDS drei Modi zur Verfügung:
124
5.2 Mediatorsystem des BioDataServer
Abbildung 5.6: UML-Zustandsdiagramm der Kommunikationsschnittstelle des BDS
1. Serverinformation
2. Serveradministration
3. Nutzermodus
Im Modus Serverinformation können ohne vorherige Authentifizierung Statusinformationen, wie z. B. angemeldete Nutzer, vorhandene Adapter abgefragt sowie Kommunikationstests durchgeführt werden. Die Serveradministration setzt eine erfolgreiche Authentifizierung voraus und bietet Funktionalitäten zur Steuerung und Verwaltung von
Datenanfragen aller am System angemeldeten Nutzer. Weiterhin ist es in diesem Modus
möglich, Servernutzer zu verwalten. Dazu gehören etwa das Anlegen und Entfernen von
Nutzern. Der Nutzermodus ist die primäre Betriebsart des BDS. Hier kann der Nutzer
nach erfolgreicher Authentifizierung auf Grundlage seines Datenschemas, das nur für
ihn sichtbar ist, SQL-Anfragen an integrierte Datenquellen stellen. Weiterhin können
im Nutzermodus IUS-Nutzerschemata verwaltet und die Adapterschemata abgefragt
werden. Die Verbindung zum Client wird geschlossen, sobald der Server das Resul-
Abbildung 5.7: UML-Aktivitätsdiagramm der BDS Client-Server-Kommunikation
tat ausgeliefert hat. Das bedeutet, jede Client-Server-Verbindung verarbeitet genau ein
125
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
Kommando. Details zum Kommunikationsprotokoll werden im folgenden Abschnitt erläutert.
5.2.3 TCP/IP-basierte BDS-Kommunikationsprotokoll
Das synchrone BDS-Kommunikationsprotokoll basiert auf im ASCII-Code übermittelten Zeichenketten. Dabei ist das newline-Zeichen \n“ der Kode für das Ende der Zei”
chenkette. Der Client setzt Kommandos in Form dieser ASCII-Zeichenketten ab und
empfängt im Kontext des Kommandos als Resultat vom Server ebenfalls eine Menge von Zeichenketten. Bei Antworten vom Server enthält dabei die erste Zeichenkette
die Quittierung des empfangenen Kommandos. Dies entfällt bei Parameterabfrage vom
Server zum gerade zu bearbeitenden Kommando. Der Prefix dieses Status ist entweder
(a) OK:“ für eine erfolgreiche Verarbeitung des Kommandos oder
”
(b) KO:“ für den Fall eines Problems
”
Hinter dem Prefix ist dann ein Text mit zusätzlicher Erläuterung der Statusmeldung
enthalten. Das kann z. B. eine Fehlermeldung sein. Das Syntaxdiagramm in erweiterter
Backus-Naur-Form der Abbildung 5.8 spezifiziert die gültigen Konstrukte der BDSKommandosprache. Das Element <CHAR>“ entspricht dabei einem gültigen ASCII”
Zeichen.
<command> :== <CMD> ’\n’
<CMD> :== ’admin’|’user’|’status low’|’status high’|’test’|
’create’|’delete’|’kill’|’list’|’getadapterscheme’|
’getinfo’|’getscheme’|’putscheme’|’sql’
<result> :== [<result_prefix>] <string> ’\n’ {<string>}* <EOF>
<result_prefix> :== ’KO: ’|’OK: ’
<string> :== {<CHAR>}*
Abbildung 5.8: Syntaxdiagramm der Kommandos des BDS-Kommunikationsprotokolls
Die Semantik der einzelnen Kommandos ist in Tabelle 5.1 dargestellt.
Serverinformations- und der Serveradministrationsmodus
Der Administrations- und Serverinformationsmodus wird bei jeder neuen Verbindung
zum BDS durchlaufen. Zum einen können Statusinformationen abgerufen werden. Hier
werden die am System angemeldeten Nutzer, der Fortschritt von Datenanfragen und
eine Liste der am System angemeldeten Adapter abgefragt. Die Sequenz von hierzu
notwendigen Kommandos ist in Abbildung 5.9 dargestellt.
Zum anderen wird hier die Authentifizierung der Nutzer vorgenommen. Durch das
entsprechende Kommando wird der gewünschte Modus ausgewählt (user, admin).
126
5.2 Mediatorsystem des BioDataServer
Systemzugang und Serverinformationen
admin
Authentifizierung zur Serveradministration
user
Authentifizierung zum Nutzermodus
status low
allgemeine Statusinformationen
status high
detaillierte Statusinformationen
test
Ausgabe von Zufallszeichen
Serveradministration
create
neuen Nutzer anlegen bzw. dessen Password ändern
delete
Nutzer löschen
kill
Sitzung eines beliebigen Nutzers abbrechen
list
listet alle vorhandenen Systemnutzer
Nutzer-Modus
getadapterscheme
Adapterschema zu einem Adapter abfragen
getinfo
Ausgabe von Versionsinformation
getscheme
Datenschema des aktuellen Nutzers abfragen
kill
Sitzung aller Nutzer mit gleicher Nutzerkennung abbrechen
putscheme
Datenschema für den aktuellen Nutzer dem Server
übermitteln
sql
SQL-Anfrage übermitteln
Tabelle 5.1: Kommandos der BDS-Kommunikationsschnittstelle
Anschließend wird vom Server das Kommando quittiert und nacheinander die Parameter Nutzername und Kennwort abgefragt. Wurden diese Authentifizierungstoken erfolgreich evaluiert, erfolgt nach entsprechender Quittierung der Wechsel in den angeforderten Modus. Im Sequenzdiagramm 5.10 wird dieses Vorgehen verdeutlicht.
Nach erfolgreicher Anmeldung dient der Serveradministrationsmodus zur Verwaltung
und Steuerung des BDS. Da es sich um einen priviliegierten Modus handelt, können
hier beliebige Nutzersitzungen abgebrochen bzw. die Kennwörter manipuliert werden.
Die Kommandosequenz beruht auf der Vorgehensweise der Authentifizierung: Ein Kommando wird dem Server übermittelt, vom Server kommt eine Quittierung und die Aufforderung, notwendige Parameter zu übergeben. Ist dies ohne Fehler geschehen, werden
die entsprechenden Daten an den Client übertragen. Aus Platzgründen wird hier auf
die Sequenzdiagramme zu allen Administrationskommandos verzichtet.
127
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
Abbildung 5.9: UML-Sequenzdiagramm zur Abfrage des BDS-Serverstatus
Abbildung 5.10: UML-Sequenzdiagramm zur Authentifizierung am BDS
Nutzermodus
Im Nutzermodus sind gewisse Verwaltungsfunktionen möglich, die allein den angemeldeten Nutzer betreffen. So kann das Nutzerschema herunter- bzw. hochgeladen, alle
Sitzungen des Nutzers abgebrochen und Adapterschemata abgefragt werden. Auch in
diesem Fall entspricht die Kommandosequenz der zuvor in diesem Unterabschnitt erläuterten BDS-Kommunikation. Somit wird auch hier auf die Angabe von Sequenzdiagrammen zu jedem Kommando verzichtet.
Die Hauptanwendung dieses Modus ist es, unter Nutzung des, dem angemeldeten
Nutzer entsprechenden, IUS-Datenschemas, Datenanfragen zu stellen. Dazu wird mit
dem Kommando sql dem Server mitgeteilt, daß eine SQL-Anfrage gestellt wird. Nach
der Quittierung mit der Meldung OK: SQLEngine is ready“ kann vom Nutzer
”
eine SQL-Anfrage spezifiziert werden. Diese wird dann auf syntaktische Korrektheit
überprüft und zur weiteren Verarbeitung der Anfrageverarbeitungskomponente des
BDS übergeben. Parallel dazu wird eine Instanz der Ergebnisausliefungskomponente
als Leichtgewichtsprozeß gestartet, die zyklisch berechnete Resultate des, in der Ausführung befindlichen, Anfrageplanes abruft. Auf die abgerufenen Tupel werden von der
128
5.2 Mediatorsystem des BioDataServer
Anfragealgebra nicht direkt umsetzbare SQL-Operationen tupelweise angewandt und
das Ergebnis an den Client als Stream ausgeliefert. Dabei wird überprüft, ob der Client noch vorhanden ist, ansonsten kann die aktuelle Anfrage abgebrochen werden. Bei
kompletter Abarbeitung des Anfrageplanes wird die Nutzersitzung geschlossen. Diese Vorgehensweise ist im Aktivitätsdiagramm 5.11 dargestellt. Ausführungen zum an-
Abbildung 5.11: UML-Aktivitätsdiagramm einer Datenanfrage
gebotenen SQL-Dialekt und dessen Interpretation durch den BDS sind im nächsten
Unterabschnitt zu finden.
5.2.4 SQL-Dialekt des BioDataServer
In Form der Anfrageschnittstelle wird den Anwendern die Möglichkeit geboten, SQLAnfragen zum Zugriff auf integrierte Datenbanken mit dem primären Hintergrund eines
Imports in ein Data Warehouse zu stellen. Es wird eine Anfragesprache angeboten, mit
deren Hilfe komplexe, deklarative Anfragen auf den integrierten Datenbanken durchgeführt werden können. Dazu wurde ein SQL-Dialekt implementiert, der die Basiskonstrukte von SQL umgesetzt. Die unterstützten Sprachkonstrukte sind:
• Projektionslisten
• Verbünde in Form eines kartesischen Produkts
• Selektionsbedingungen
– Konstanten-Selektion
– Attribut-Selektion
– zulässige Vergleichsoperatoren (=, 6=, <, ≤, >, ≥)
• Bool’sche Verknüpfungen ∧, ∨, ¬
129
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
Ausschließlich die in der vorherigen Aufzählung hervorgehobenen Konstrukte können
aufgrund der zuvor eingeführten Anfrageoperationen auf Basis der subgoals direkt als
Operationen in Anfragepläne umgesetzt werden. Die anderen Konstrukte sind vom
Mediator nachträglich auf die aus der Anfrageausführung resultierenden Tupel anzuwenden. Bei der Formulierung von SQL-Anfragen ist dem Rechnung zu tragen, indem
komplexe Konstrukte, wie etwa Verbünde, vermieden werden sollten. Das ist im Anwendungskontext des Mediators als Importkomponente für ein Data Warehouse wenig
einschränkend. Im Gegensatz dazu sind SQL-Anfragen zur Onlineanalyse oder Datenexploration somit weniger gut geeignet aber auf entsprechend kleinen IUS-Tabellen
mit wenigen Attributen und restriktiven Konstantenselektionsbedingungen unter Akzeptanz eines schlechten Antwortverhaltens durchaus möglich. Zur Unterstützung eines
solchen Anwendungsfalls würde bei einer Anfrage mit einer oder mehreren Konstantenselektionen auf dem Startattribut des Anfrageplanes, d. h. dem IUS-Attribut ohne
Anfrageabhängigkeit zu einem anderen IUS-Attribut, auf die Ausführung der zugrundeliegenden subgoals verzichtet. Vielmehr können die angegebenen Konstantenwerte als
Attributwerte ohne Datenquellenanfrage angenommen werden. Auf diese Weise können zu einer gegebenen Liste von Enzymnummern, die in Form einer Disjunktion von
Konstantenvergleichen in SQL ausgedrückt werden kann, direkt alle interessierenden
Attribute abgefragt werden, ohne alle Enzymnummern sequentiell von den Datenquellen abfragen zu müssen. Die Syntax des vom BDS unterstützen SQL-Dialektes ist in
Abbildung 5.12 angegeben.
Implementierte Client-API
Die möglichen Programmierschnittstellen für die den Mediator anfragenden Anwendungen wurden hinsichtlich folgender Kriterien untersucht:
(a) Unterstützung der Datenbankanfragesprache SQL
(b) intuitive Anwendbarkeit
(c) Akzeptanz bei Anwendungsentwicklern
(d) stabile Spezifikation
(e) Umfang des notwendigen Implementierungsaufwandes
Es wurden insbesondere die etablierten, im Abschnitt 3.1.2 erläuterten Datenbankschnittstellen im Umfeld der Bioinformatik betrachtet. Dabei können drei Klassen von
Schnittstellen gebildet werden:
1. Datenbankübergreifend, sowohl abstrakte als auch uniforme Funktionsschnittstellen (z. B. JDBC)
2. Dynamisch aus Daten- und Funktionsbeschreibungssprachen generierte Schnittstellen (z. B. CORBA)
130
5.2 Mediatorsystem des BioDataServer
select
SPACE
ROW
from
TABLE
;
SPACE
SPACE
ROW
:
:
TABLE
where
OPERATOR
SPACE
:
CONDITION
:
ID
=
ID
ROW
,
LETTER
>=
ROW
DIGIT
<=
SPACE
>
<
:
CONDITION
!=
:
LETTER
"A"-Z","a"-"z"
SPACE
TERM
SPACE
AND
CONDITION
DIGIT
:
OR
"0"-"9"
TERM
:
ID
!
SPACE
’
ID
OPERATOR
’
SPACE
ID
SPACE
’
ID
’
Abbildung 5.12: Syntaxdiagramm des BDS-SQL-Dialekts aus [143]
3. Properitäre, sich evolutionär entwickelnde Funktionsschnittstellen (z. B. BioJava)
Aus Gründen der gegebenen Akzeptanz, Verbreitung sowie der stabilen API-Spezifikation wurde sich für JDBC als API für JAVA-Anwendungen sowie für ODBC für CProgramme unter Microsoft Windows entschieden. Das entspricht der 1. Klasse aus
den zuvor genannten Schnittstellenklassen. Weiterhin wird hier SQL als Datenanfragesprache unterstützt. Skriptsprachen, wie etwa Perl, werden dagegen nicht unterstützt,
da hier die 3. Schnittstellenklasse, wie etwa in Form der BioPerl-API, verbreitet sind,
was aufgrund der gegebenen Dynamik dieser Schnittstelle ständige Anpassungen und
Wartungen notwendig macht. Auch werden hier keine Anfragesprachen wie SQL unterstützt. Auf der Basis dieser Entscheidung wird im folgenden die Implementierung der
JDBC-API vorgestellt. Da ODBC konzeptuell sehr ähnlich zu JDBC ist, wird auf eine Vorstellung dieser Schnittstellenimplementierung, die in Form eines ODBC-Treibers
vorgenommen wurde, verzichtet.
JDBC spezifiziert eine API, die Java-Programmen einen, vom DBMS abstrahierten,
Datenbankzugriff ermöglicht. Dazu gehören Operationen zum Suchen, Abfragen, Erzeugen und Verändern von Relationen. Für die Formulierung entsprechender Anweisungen
an das Datenbanksystem wird gewöhnlich die standardisierte Datenbanksprache SQL
verwendet. JDBC setzt damit auf einer recht tiefen sprachlichen Ebene an und hat
dementsprechend schlichte Fähigkeiten im Vergleich zu den meist sehr anspruchsvol-
131
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
len Datenbankentwicklungswerkzeugen. Deshalb wird JDBC auch als low-level“- oder
”
call level“-SQL-Schnittstelle für die Java-Plattform bezeichnet. JDBC besteht aus zwei
”
Komponenten:
1. aus Datenbanktreibern, die den Anschluß von Java-Anwendungen an Datenbanksysteme ermöglichen, und
2. aus dem Paket java.sql, bestehend aus einem Manager für diese Treiber, einem
Interfaces als Schnittstellen zu den Treibern sowie Hilfsklassen für Datum,
Uhrzeit und gültige JDBC-Typen.
Die Treiber sind datenbank- und herstellerabhängige Java-Klassen, die sich dem Anwender aber als einheitliche Implementierungen von JDBC-Interfaces präsentieren. Dieses
Konzept wurde genutzt, um Java-Programmen eine unabhängige Programmierschnittstelle für den BioDataServer anzubieten. Demgemäß ist der BDS-JDBC-Treiber eine Implementierung der Interfaces des Pakets java.sql (Connection, Statement,
ResultSet etc.).
Neben den Schnittstellenfestlegungen verfügt java.sql noch über einen Treibermanager, mit dem Treiberobjekte verwaltet werden können. Objekte von JDBC-konformen
Treiberklassen registrieren sich beim Treibermanager des Java-Programms stets selbst.
Jede JDBC-Applikation hat genau einen solchen Treibermanager. Der Treibermanager verwaltet lediglich die Treiberobjekte selbst, nicht deren Verbindungen zu Datenbanksystemen. Wird er verwendet, so werden über ihn zwar die Verbindungen zu den
Datenbanken hergestellt, die darauf folgenden Datenbankanfragen werden aber direkt
über die Treiber abgewickelt. Dabei werden im Falle des BioDataServer-JDBC-Treibers
die JDBC-Interfaces und nicht die vom Treiber bereitgestellten Klassen verwendet, also etwa ResultSet statt z. B. BDSSQLResultSet. Die Komponenten einer JDBCArchitektur sind in Abbildung 5.13 illustriert.
Die Vorgehensweise einer Anwendung zum Verbindungsaufbau zu einer Datenquelle
über einen JDBC-Treiber wird im Aktivitätsdiagramm der Abbildung 5.14 dargestellt.
Dazu sind folgende Schritte notwendig:
1. Laden der JAVA-Klasse eines JDBC-Treibers
2. Registrierung der Treiberinstanz beim Treibermanager
3. Anforderung eines datenquellenspezifischen Treibers durch die Anwendung
4. Verbindungsaufbau zur Datenquelle mittels des JDBC-Treibers
5. Abwicklung der Datenbankoperationen über den Treiber direkt, d. h. über das
Objekt vom Typ Connection, das bei der Verbindungsaufnahme erzeugt wurde
6. Verbindungsabbau und Freigabe des Treiberobjektes
Der implementierte JDBC-Treiber für den BioDataServer besteht aus 23 JAVA-Klassen,
die 150 abstrakte Funktionen aus dem JDBC-Framework der Version 2 implementieren.
132
5.2 Mediatorsystem des BioDataServer
Abbildung 5.13: Komponenten des JDBC-Frameworks
Alle anderen JDBC-Funktionen werden nicht unterstützt. Die Anfragefunktionalität
des BDS-JDBC-Treibers wurde auf Basis des zuvor im Abschnitt 5.2.2 vorgestellten
Kommunikationsprotokolls nach dem Muster von Consumer/Producer“-Threads auf
”
Basis von TCP/IP-Streams implementiert. Dabei empfängt der Producer“-Thread im
”
TCP-Stream die zu einer zuvor übermittelten Datenanfrage Resultattupel, parst diese
und überführt sie in die Datenstruktur des JDBC-Interfaces ResultSet. Der Zugriff
auf die in einem ResultSet strukturierten Anfrageergebnisse basiert auf dem CursorKonzept, wobei ein Cursor unidirektional, iterativ durch die Menge aller Resultattupel bewegt wird. Somit konsumiert“ das ResultSet die vom Producer-Thread in einem
”
Puffer bereitgestellten Daten. Bei Weiterbewegen des Cursors zum nächsten Tupel wird
das vorige Tupel aus dem Hauptspeicher entfernt. Dieses sogenannte Streaming“-Kon”
zept stellt sicher, daß auch große Resultate verarbeitet werden können und nicht durch
die Hauptspeichergröße limitiert werden.
Neben der so implementierten Standardfunktionalität des JDBC-Frameworks wurde
eine darauf aufsetzende JAVA-Klasse entwickelt, die JDBC-ResultSets automatisch in
XML umwandelt. Das ermöglicht eine nahtlose Integration in XML-basierende Frameworks, wie etwa XML-Datenbankanwendungen. Erweiterte Funktionalitäten, wie etwa
das Management von Datenanfragen an den BDS-Mediator oder administrative Aufgaben, so wie diese, die zur Funktionalität des BDS gehören, sind vom JDBC-Framework
nicht vorgesehen. Dazu wurde ein graphischer JAVA-Administrationsclient implementiert, welcher über das BDS-Protokoll auf entfernt laufende Instanzen des BDS-Mediators zugreift. Alle hier genannten Implementierungen sind als Open Source“ verfügbar
”
und sind als SourceForge-Projekt unter der URL
133
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
Abbildung 5.14: Aktivitätsdiagramm einer JDBC-Datenquellenverbindung
http://sourceforge.net/projects/biodataserver
veröffentlicht.
5.3 Implementierungsaspekte des Mediators
Die vorgestellte Konzeption des BioDataServers als Umsetzung einer Mediator-Wrapper-Architektur wurde unter der Maßgabe einer praktischen Umsetzung entworfen. Neben den theoretischen Arbeiten, die auf eine Realisierbarkeit und praktische Anwendbarkeit des zu enwickelnden Datenbankintegrationssystems fokussiert wurden, stellt die
Implementierung der Konzepte den zweiten Hauptteil der Arbeit dar. Dem gerecht werdend, wurde eine Implementierung des BioDataServers vorgenommen, um ein nutzbares
Werkzeug zur Datenbankintegration für die Bioinformatik bereitzustellen.
So konnte ein großer Teil der, für die vorliegende Arbeit zur Verfügung stehenden,
Ressourcen zur Programmierung folgender nach Implementierungsumfang geordneter
Software aufgewandt werden:
1. Mediator
2. Datenbankadapter
3. Treiber für den BioDataServer nutzende Applikationen
4. unterstützende Werkzeuge
Die Implementierungen der Datenbankadapter, der JDBC- und ODBC-Treiber und
der unterstützenden Werkzeuge wurde im Kontext der Abschnitte 5.4, 5.2.4 und 5.2.1
beschrieben. Die größte Implementierungsarbeit wurde für den Mediator notwendig.
Deshalb werden in diesem Abschnitt einige wesentliche Implementierungsaspekte des
Mediators erläutert. Dazu werden neben der gewählten Implementierungstechnologie,
die Klassen und Paketstruktur sowie für die Implementierung wesentliche Funktionsteile
des Mediators erläutert.
134
5.3 Implementierungsaspekte des Mediators
5.3.1 JAVA Quellkode
Der Mediator und die JDBC-Treiber sind als Open Source“ implementiert und im
”
SourceForge-Projekt unter der URL
http://sourceforge.net/projects/biodataserver
veröffentlicht. Als Programmiersprache wurde JAVA gewählt. Die Entscheidung dazu
motivierte sich aus der Plattformunabhängigkeit, der Objektorientierung, dem umfangreichen Funktionsumfang der frei verfügbaren Klassenbibliotheken, den in der Sprache
eingebetteten Konstrukten zur Synchronisation von Leichtgewichtsprozessen sowie der
in der JAVA Virtual Machine (JVM) integrierten Speicherverwaltung. Die Implementierung wurde mit dem Funktionsumfang des Java Development Kit (JDK) der Version
1.2 vorgenommen. Außer der im JDK enthaltenen API wurden Funktionalitäten des
HSQL-Projektes [144] genutzt. Hierbei handelt es sich um ein in JAVA programmiertes
und in JAVA-Anwendungen direkt einbettbares relationales DBMS, das für die CacheFunktionen des BioDataServers genutzt wird.
Die auf dieser Grundlage entwickelte Software wurde in Pakete strukturiert, die jeweils aus einer Anzahl von Klassen bestehen. Folgende Softwarepakete wurden entwickelt:
• adapter“ (16 Klassen)
”
Dieses Paket umfaßt Klassen und Interfaces zur Implementierung von Adaptern.
Dazu gehören Dienstklassen zum Scheduling der Adapteranfragen, zum zwischenspeichern von Anfrageergebnissen und zur Überwachung der subgoal-Ausführung
durch Threads.
• admin“ (1 Klasse)
”
Durch eine Klasse wurden alle Administratorfunktionalitäten implementiert.
• bionet“ (9 Klassen)
”
In diesem Paket werden Klassen zur Realisierung des Netzwerkprotokolls, zur
Kommunikation mit dem BioDataServer, der Verwaltung von Clientverbindungen, der Aktivitäts- und Fehlerprotokollierung und der Serverlaufzeitüberwachung
implementiert. Weiterhin sind in der Klasse Defines“ global gültige Parameter
”
für den Server definiert. Diese sind in folgenden Klassen von Parametern organisiert:
– Netzwerk- und Clientverbindungsparameter
– Threadprioritäten
– Pfade zu den Dateien
– Grenzwerte für time out“ und Cacheüberalterungen, Anzahl von Anfrage”
attributen und parallelen Threads
– Kommandos und Schlüsselwörter des BDS-Kommunikationsprotokolls (vergleiche hierzu auch Tabelle 5.1)
135
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
• integration“ (3 Klassen)
”
Durch dieses Paket werden Klassen mit Funktionalität zur Anfrageplanabarbeitung und zur relationalen Auflösung von Ergebnistupeln bereitgestellt. Dabei
wurden in der Klasse QueryData“ ein Großteil in dieser Arbeit vorgestellten
”
Algorithmen implementiert.
• profile“ (19 Klassen)
”
Hier sind Klassen zur Nutzer- und IUS-Datenschemaverwaltung implementiert.
Die Klassen zum Parsen der Schema- und Kennwortdateien wurden mittels des
JAVACC Parsergenerators [99] erzeugt.
• sql“ (14 Klassen)
”
Das Paket enthält Klassen zum Parsen, Interpretieren und Ausführen von SQLAnfragen, die an den BioDataServer gestellt werden. Die Klassen zum Parsen von
SQL wurden auch hier mittels JAVACC generiert.
• util“ (6 Klassen)
”
Dieses Paket enthält zentrale Hilfsklassen, wie z. B. eine Erweiterung der JAVAKlasse Vector oder einen HTML-Parser.
Es wurden somit 68 Klassen in 7 Paketen mit 521 Funktionen implementiert. An dieser
Stelle soll auf eine komplette Darstellung des, sich über die implementierten Klassen
ergebenen, Klassenschemas verzichtet werden. Eine zum Verständnis notwendige Detailbeschreibung der Klassen und eine Dokumentation des Quellkodes wird hier nicht
gegeben. Die Klassenstruktur ergibt sich aus dem verfügbaren, im SourceForge-Projekt
veröffentlichten Quellkode.
5.3.2 SQL Implementierung des BioDataServer
Für die SQL-Schnittstelle waren drei Kernfunktionalitäten zu implementieren, die nicht
bereits von den RIND-Operationen bereitgestellt werden:
1. SQL-Parser
2. Auswertung der WHERE-Klausel
3. Ausführen von Verbundoperationen
Der SQL-Parser, der mit Hilfe einer JAVACC-Grammatik generiert wurde, bildet
die in Abschnitt 5.2.4 definierten, vom BioDataServer unterstützten SQL-Elemente auf
RIND-Datenanfragen ab. Diejenigen Konstrukte, die nicht direkt von RIND-Operationen unterstützt werden, wie z. B. zum Gleichheitsprädikat ergänzende Bool’sche
Prädikate für Attributvergleiche in der WHERE-Klausel, müssen auf SQL-Ebene des
BDS implementiert werden.
Die vollständige Umsetzung der WHERE-Klausel kann nicht direkt von RINDOperationen durchgeführt werden. Deshalb ist dies für alle relational aufgelösten
136
5.3 Implementierungsaspekte des Mediators
Resultattupel von der SQL-Implementierung durchzuführen. Für eine WHEREKlausel werden Bool’sche Funktionen verwandt, die entweder Negationen von Attributvergleichen oder logische Verknüpfungen mittels AND und OR sind. So ist z. B.
folgender Term eine gültige Bedingung einer WHERE-Klausel:
(((ec = ’3.5.3.1’ OR ec = ’4.3.2.1’) AND (name =
’Arginase’))) OR (not (gen = ’ARG1) OR ec = ’6.3.4.5’)
Dieser ist graphisch als binärer Baum in Abbildung 5.15 dargestellt. Die Knoten
sind dabei als binäre Bool’sche Funktionen zu verstehen, deren Parameter sich im
Fall der inneren Knoten aus den beiden Kindknoten oder bei den Blattknoten aus
dem Attributnamen und der Konstante bestimmen. Alle Knoten/Bool’sche Funk-
Abbildung 5.15: Binärbaum zu einer Beispiel SQL-Selektionsbedingung
tionen werden beginnend mit den Blättern ausgewertet, indem unter Nutzung der
rekursiven Methode der Tiefensuche der Baum traversiert wird. Die Auswertung bzw.
das Funktionsresultat des Wurzelknotens ist dann der Wahrheitswert des gesamten
Ausdrucks.
5.3.3 Implementierung von Verbundoperationen
Als einzige zur Zeit implementierte Art der Verbundoperation wird das kartesische
Produkt zwischen Relationen unterstützt. Dieser Verbund nutzt die RIND-Operation
⊲⊳. Diese Operation ist aber nicht auf Datenquellenabfragen anwendbar. Hier sind in
Form der subgoals ausschließlich die Projektion π sowie die Selektion σ aus den in
Abschnitt 4.3.2 genannten Gründen zulässig. Die Konsequenz ist, daß sich die Ausführung von Verbundoperationen bei der momentan verfügbaren Implementierung des
BioDataServers auf das kartesische Produkt unter Anwendung der, in der WHEREKlausel formulierten, Selektionsbedingungen beschränkt. Auf dieser Basis sind weitere
Verbundoperationen, wie z. B. der natürliche oder auch der äußere Verbund, durchführbar. Eine direkte Implementierung unter Anwendung bekannter Algorithmen, wie der
Hash- oder Merge-Join zur Verbundberechnung, ist zur Zeit nicht vorgesehen. Mit dem
Hinweis auf den Entwurf des Mediators als Importwerkzeug für Datenbanken bedeutet
das aber eine wenig maßgebliche Einschränkung. Die Voraussetzung zur Berechnung des
137
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
kartesischen Produktes mehrerer Relationen ist, daß alle Tupel der zu verbindenden Relationen bzw. Objektausprägungen im RIND-Modell vollständig abgefragt worden und
dem BioDataServer vorliegen. Diese sind dann durch, je nach Anzahl der zu verbindenden Relationen, verschachtelte Schleifen nach Definition des Kreuzproduktes zu einer
Relation zusammenzufügen. Die Implementierung benutzt ausschließlich den Primärspeicher (RAM) und ist somit gerade für große Relationen nicht anwendbar. Durch diese offensichtlichen Negativmerkmale der Verbundimplementierung ist diese Operation
nur aus Vollständigkeitsgründen zum SQL-Dialekt des BioDataServers aufgenommen
worden und bietet somit eine Vorlage für weitergehende Implementierungen.
5.3.4 Parallelisierung der Adapteranfragen
Kernfunktionalität der Mediatorimplementierung ist die parallelisierte subgoal-Ausführung. Wie bereits erläutert, werden subgoals von Adaptern ausgeführt. Da die subgoals
im Ausführungsplan über die Eingabe- und Ausgabeattribute voneinander abhängen,
unterliegen auch die auszuführenden Adapteranfragen dieser Anfrageabhängigkeit. Um
einen möglichst guten Datendurchsatz bei Datenanfragen an den Mediator zu gewährleisten, werden Adapteranfragen parallel als Leichtgewichtsprozesse, sogenannte Threads,
ausgeführt. Das hat gegenüber einer sequentiellen Implementierung des in Abschnitt
4.4.3 vorgeschlagenen Algorithmus zur Anfrageplanausführung den Vorteil, daß Wartesituationen einzelner Adapteranfragen, die z. B. aus einer hohen Netzwerk- oder Middlewareauslastung bei den entfernten Datenquellen resultieren können, durch Anfragen
an andere, zum Anfragezeitpunkt weniger ausgelastete Datenquellen ergänzt werden
können. Da die Auslastung der genannten Ressourcen entfernter Datenquellen während der Anfrageplanabarbeitung schwankt, kann durch diese Idee der Parallelisierung
von subgoal-Ausführungen eine gute Gesamtleistung erzielt werden.
Um nun die Anfrageabhängigkeiten bei der Parallelisierung zu gewährleisten, wurde
eine Implementierung umgesetzt, die auf anfrageabhängiger Ausführungssynchronisation von Adapteranfrage-Threads mit gekoppelter Consumer/Producer“ Strategie ba”
siert. Mit Hilfe des Beispieles aus Abbildung 5.16 wird diese Implementierung erläutert.
Im Beispiel existieren fünf Adapter, die zur Ausführung von subgoals benötigt werden. Jeder Adapter hat einen Pufferspeicher, worin die Anfrageergebnisse abgelegt werden. Diese Puffer werden zu einer zweidimensionalen Matrix mit festen Zeilen und
Spaltenadressen zusammengefügt. Unter den Adaptern bestehen, gemäß der Anfrageabhängigkeiten, Abhängigkeiten zwischen den Pufferspeichern. Diese sind in der Abbildung 5.16 durch Pfeile dargestellt. Jedem subgoal wird nun ein Platz in dem jeweiligen
Adapterpufferspeicher und somit eine eindeutige Matrixadresse zugewiesen. In der Abbildung sind bereits durch Anfrageergebnisse belegte Zellen durch geometrische Objekte
veranschaulicht. Ist eine Zeile über alle Puffer mit Resultatobjekten belegt, so wird diese
Zeile als Ergebnistupel abgerufen und diese Zeile aus allen Puffern entfernt (im Beispiel:
Ergebnistupel 1 und 3). Auf diese Weise und durch eine maximale Anzahl von Threads
pro Adapter wird sichergestellt, daß kein Speicherüberlauf auftritt.
Ein subgoal wird als Thread ausgeführt und besitzt drei Zustände:
138
5.3 Implementierungsaspekte des Mediators
Abbildung 5.16: Ausführungsschema von Adapteranfragen
1. wartet“
”
Das notwendige Eingabeattribut des subgoals ist noch nicht an ein Attributwert
gebunden (subgoals zu Ergebnistupeln 2 und 5).
2.
geplant“
”
Das subgoal ist bereit zur Ausführung und wird nach Maßgabe des Schedulers
einem Thread zugewiesen (subgoals zu Ergebnistupel 7).
3. arbeitet“
”
Das subgoal wird ausgeführt (subgoals zu Ergebnistupel 4 und 6).
Ein Thread ändert seinen Zustand immer von wartet“ über geplant“ zu arbeitet“.
”
”
”
Um Blockierungen von einem nicht beendeten Thread zu vermeiden, werden arbeitende
Threads nach einem time out“-Kriterium abgebrochen. Nach einer bestimmten Anzahl
”
von erfolglosen Wiederholungen eines subgoals wird ein Fehlerresultat erzeugt, so daß
nur ein Tupel ungültig wird, aber die Anfrage nicht abgebrochen werden muß. Eine
Datenanfrage ist vollständig abgearbeitet, wenn Adapter A, d. h. der Startknoten im
Anfrageplan, keine ausstehenden subgoals mehr auszuführen hat und alle Zeilen komplett ausgeliefert werden konnten.
139
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
5.4 Adapter für den BioDataServer
Zur Umsetzung der zur Abarbeitung von Anfrageplänen notwendigen subgoals (vergleiche hierzu Abschnitt 4.3.2) wurden in der Systemarchitektur des BioDataServers
Adapterkomponenten vorgesehen. Diese setzen die Funktionalität der aus der Literatur
bekannten Wrapper im Kontext von Mediatorsystemen um. Gemäß den im Grundlagenkapitel eingeführten Mediator-Wrapper-Architekturen stellen Wrapper das Datenschema der gekapselten Datenquelle bereit, offerieren Funktionalität für Datenanfragen und
geben Informationen zu Datenquelleneigenschaften. Da der Mediator in JAVA implementiert wurde, wird zur homogenen Einbettung von Adaptern ein JAVA-Interface
definiert, das von allen Adaptern zu implementieren ist. Dieses Interface basiert auf
[143] und ist im Anhang B.2 enthalten. Dabei wurden einige der folgenden Konzepte,
insbesondere die Metadaten zu Datenquellen und der Abfrage aller ungebundenen subgoal-Attribute mit einem Adapteraufruf, aus Gründen einer zeitnahen Umsetzbarkeit
und Wartbarkeit nicht berücksichtigt. Durch die in JAVA gebotene Möglichkeit des
dynamischen Ladens von Klassenimplementierungen werden Adapter zur Laufzeit am
BioDataServer angemeldet.
Im Falle des BioDataServers sind speziell die subgoals und Methoden zum Zugriff auf
die Adapterschemata von den Adaptern zu implementieren. Ergänzend zum Adapterschema gehören auch weitergehende Informationen zu den jeweils gekapselten Datenquellen:
• Metadaten zur Datenquelle
– Name und IP-Adresse der Datenquelle
– Vertrauenswürdigkeit der Daten (subjektive Noten zwischen 1: sehr gut“
”
und 6: fragwürdig“)
”
– Herkunft der Daten (manuell gepflegte Experimentdaten, aus der Literatur
oder berechnet)
• Schnittstellentyp der Datenquelle
– lokales Dateisystem
– lokale API
– diverse Netzwerkprotokolle
– API für entfernten Zugriff
• Datenformat
– unstandardisiertes flat-file
– Datenaustauschformat, wie z. B. XML
– Datenpräsentationsformat, wie z. B. HTML
– von Dateien unabhängiges Datenformat, wie etwa beim DBMS
140
5.4 Adapter für den BioDataServer
• Version des Adapters
Diese Metadaten ermöglichen eine statische Klassifikation von Datenquellen gemäß
zu erwartender Zugriffskosten und können vom Mediator zur Priorisierung von subgoalAusführungen genutzt werden. In diesem Zusammenhang sind Informationen zum Datenformat, zur genutzten Schnittstelle und zu vorhandenen Indexen nützlich. Dadurch
und mittels anfragestatistikbasierter, dynamischer Anfragekostenabschätzungen wäre
es möglich, ein besseres Antwortverhalten für ein exploratives Arbeiten zu erreichen.
Wie eingangs diesen Kapitels erläutert, ist dies nicht der primäre Anwendungsfall des
BioDataServers und stellt vielmehr eine Möglichkeit für aufbauende Arbeiten dar. Weiterhin sind durch die vorgesehenen Datenqualitätsinformationen hinsichtlich der, vom
Nutzer gewünschten, Anforderungen an die Vertrauenswürdigkeit oder der Datenherkunft Möglichkeiten gegeben, je nach Anwendungsfall, etwa für statistische Analysen,
auf einem umfassenden Datenbestand oder explorativ auf weniger aber dafür qualitativ
hochwertigeren Daten zu arbeiten.
Basierend auf diesen Überlegungen und den im vorhergehenden Kapitel eingeführten
Datenstrukturen und Datenanfragekonzepten wurde ein Klassendiagramm konzipiert,
das in Abbildung 5.17 dargestellt ist.
Abbildung 5.17: UML-Klassendiagramm der Adapter
141
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
Datenanfragen mittels Adapter
Die Ausführung der im Anfrageplan ausgeführten subgoals wird durch Adapter umgesetzt. Eine Datenquelle wird derart von einem Adapter gekapselt, so daß die auf dieser
Datenquelle definierten subgoals über eine homogene Funktionsschnittstelle vom Mediator ausgeführt werden können. Diese homogene Funktionsschnittstelle wird in Form
des bereits genannten JAVA-Interfaces realisiert. Die Ausführung von Adapteranfragen
geschieht wie folgt.
Dem auszuführenden subgoal liegen entweder kein oder ein gebundenes Adapterattribut und eine Menge von ungebundenen Adapterattributen zugrunde. Ein gebundenes
Attribut besitzt einen Wert, der für die Konstruktion der Datenanfrage notwendig ist.
Da die subgoals und somit die Datenanfragen auf den in Abschnitt 4.3.1 eingeführten
Basisoperationen aufbauen, wird ein vorhandenes gebundenes Attribut als Selektion
über den Datenbestand der Datenquelle aufgefaßt. Für den Fall, daß kein gebundenes
Attribut im auszuführenden subgoal existiert, werden alle Datentupel abgefragt.
Auf dieser Basis wird unter Nutzung vorhandener Schnittstellen der Datenquelle
eine entsprechende Anfrage generiert. Für einfache CGI-Schnittstellen kann das z. B.
folgende URL zur Abfrage alle Enzymattribute aus der KEGG-Datenbank sein:
http://kegg. ... .jp/dbget-bin/www_bget?enzyme:3.5.3.1
Hier wäre das Adapterattribut enzyme mit dem Wert 3.5.3.1“ gebunden. Ein weiteres
”
Beispiel ist die Abfrage aller Gene eines Stoffwechselweges unter Nutzung der SOAPSchnittstelle von KEGG (siehe Anhang A.9), wobei der Stoffwechselweg das gebundene
Attribut darstellt. Das Ziel der Ausführung der Datenanfragen ist die Ermittlung von
Werten für die ungebundenen Attribute eines subgoals.
Die Ausführung der Datenanfragen unter Nutzung der jeweiligen Schnittstelle kann
im Falle von Verfügbarkeitsproblemen der Datenquelle, insbesondere bei Netzwerkproblemen, wiederholt ausgeführt werden. Gerade bei umfangreichen Datenimportanfragen, wie etwa dem Abfragen eines gesamten Datenbestandes, können solche Probleme
auftreten. Kann eine Anfrage trotz Wiederholung nicht abgearbeitet werden oder treten
weitere schwerwiegende Fehler auf, so wird die gesamte Ausführung des subgoals mit
einem Fehler abgebrochen.
Zur Bindung der freien Attribute muß gemäß der Definition von subgoals eine Projektion auf den so abgefragten Daten vorgenommen werden. Kann diese Operation
nicht direkt von der Datenquellenschnittstelle durchgeführt werden, da keine DBMSFunktionalität vorliegt, muß vom Adapter eine Methode zur Datenextraktion für die
ungebundenen Attribute implementiert werden. So kann z. B. eine Datenanfrage in
einem flat-file resultieren, dessen Format bekannt ist. Anschließend kann auf dieser
Datenstruktur mit einem Parser eine Datenextraktion durchgeführt werden. Die Projektionsoperation ist in solchen Fällen also über Parser implementiert, was nicht selten
zu Fehlern führt, da sich z. B. das Format eines flat-files oder die lexikale Struktur der
Datenformatelemente ändern können.
Der gesamte Ablauf der Anfrageausführung ist im Aktivitätsdiagramm der Abbildung
5.18 dargestellt.
142
5.4 Adapter für den BioDataServer
Abbildung 5.18: UML-Aktivitätsdiagramm einer Adapterdatenanfrage
5.4.1 Angewandte Methoden zur Adaptererstellung
Die Verfügbarkeit von konkreten Adaptern ist eine existentielle Voraussetzung zur Anwendbarkeit des BioDataServer. Durch die einfach gehaltene Schnittstelle, die aus wenigen zu implementierenden Funktionen besteht und auf die explizite Beschränkung auf
rudimentäre Datenanfragefunktionalitäten in Form der vorgeschlagenen subgoals aufbaut, wurde auf die Möglichkeit einer ad-hoc Realisierung von Adaptern hingearbeitet.
Auf der Grundlage immer funktionsreicher werdender APIs zum Datenzugriff können
so mit überschaubarem“ Aufwand Adapter manuell implementiert werden, d. h. je
”
nach Erfahrungsstand des Softwareentwicklers konnten Adapterimplementierungen unter Nutzung von geeigneten APIs innerhalb von wenigen Tagen neu entwickelt werden.
Sind hingegen keine APIs für eine Datenquelle nutzbar, so zeigt die Erfahrung, daß für
die Adapterentwicklung einige Wochen veranschlagt werden müssen.
Aber auch generative Ansätze zur Erzeugung von Adapterimplementierungen sind
wegen der einfachen Adapterfunktionen nutzbar, da sich der zu erzeugende Kode im
wesentlichen auf die Datenextraktion beschränkt. Die Konstruktion von spezifischen
Datenquellenanfragen zur Ausführung von subgoals ist weniger aufwendig und kann
durch statisch vorgegebene Abbildungen, etwa auf CGI oder API-Funktionsaufrufe, erfolgen. Die weitaus aufwendigste Aufgabe ist die Ableitung bzw. Erstellung der Adapterschemata. Diese sind die Basis für die integrierten Nutzerschemata des BioDataServers und müssen die Attribute und Strukturen enthalten, die auch durch Datenanfragen
mit Werten belegt werden können. Auf der Basis existierender Arbeiten aus [100] und
mit dem Ziel der Anwendbarkeit für den implementierten Datenbankintegrationsdienst
werden in folgenden Unterabschnitten sowohl generative als auch manuelle Methoden
zur Implementierung dieser Adapterfunktionsgruppen vorgestellt. Die Anwendung weitergehender Ansätze, wie sie im Abschnitt 3.1.2 genannt worden, erscheint hinsichtlich
143
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
der bereits existierenden APIs zum Datenzugriff im Rahmen der vorliegenden Arbeit
als wenig nutzbringend.
Erstellung des Adapterschemas
Das von einem Adapter bereitzustellende Datenschema umfaßt Attribute, den Datentyp
und deren Gruppierung aufgrund funktionaler Abhängigkeiten zu Tabellen.
Die elementarste Dateneinheit ist somit das Attribut, was ein nicht weiter zerlegbares
Eigenschaftmerkmal eines Datenobjektes gemäß Definition 4.2 darstellt. Als Empfehlung für die Ableitung von Attributen aus Datenquellen soll hier auf die Einhaltung der
ersten Normalform, wie sie für das relationale Datenmodell definiert ist, hingewiesen
werden. Zwar ist dies keine notwendige Eigenschaft eines Adapterschemaattributes,
stellt aber eine wesentliche Voraussetzung zur Anwendbarkeit der über die Adapter
extrahierten Daten dar. Betrachtet man etwa den Extremfall eines nicht-atomaren, akkumulierten Attributes, das etwa alle Daten zu einem biologischen Objekt als Text
zusammenfaßt, so ist offensichtlich eine darauf aufbauende Modellbildung oder Datenanalyse nur eingeschränkt möglich.
Der Datentyp eines Attributes definiert die auf einem Attribut anwendbaren Operationen und ermöglicht weiterhin einfache, statische Konsistenzüberprüfungen. Im Adapterschema können Datentypen frei definiert werden, wobei eine Spezialisierungshierarchie von Datentypen in Abschnitt 4.2 vorgeschlagen wurde. Ausgehend vom allgemeinen Datentyp string können so diverse Datentypen definiert werden, wobei dazu die
Basisoperationen und Relationen im BioDataServer implementiert werden müssen. Der
BioDataServer unterstützt in der vorliegenden Implementierung daneben die Basisdatentypen integer, float und boolean. Die Ermittlung des Datentypes eines Attributes
geht einher mit der Ableitung der Attributsemantik, wozu in der Regel Expertenwissen
oder daraus abgeleitete Regeln notwendig sind.
Die Gruppierung der Attribute zu Tabellen ist das zu wählende Mittel, um Beziehungen zwischen den Attributen zu modellieren. Da ein Adapterschema nicht als Basis zur
physikalischen Datenorganisation dient, sondern vielmehr eine Sicht auf das Exportschema einer Datenquelle ist, können Attribute durchaus redundant in verschiedenen
Tabellen auftauchen, die jeweils verschiedene funktionale Aspekte ein und desselben
Datenobjektes modellieren. So kann etwa das Ausführen von teuren Verbundoperationen bei Datenanfragen vermieden oder verschiedene Nutzersichten auf das gleiche
Datenobjekt definiert werden.
Die Aufgabe der Ermittlung dieser drei Datenschemaelemente besteht nun darin,
vorhandene Datenschemata der Datenquelle mit vorhandenen Zugriffsmustern, d. h.
von der Datenquelle bereitgestellte Funktionen zur Umsetzung von subgoals, derart zu
kombinieren, daß alle Attribute eines Adapterschemas durch subgoals angefragt werden
können. Kommt ein im Adapterschema modelliertes Attribut in keinem subgoal vor,
so muß vom Adapter ein entsprechendes subgoal explizit implementiert werden. So
können etwa auch künstliche, z. B. berechnete Attribute, die in einer Datenquelle nicht
enthalten sind, vom Adapter angeboten werden. Die Berechnung dieser Attribute kann
durchaus von der jeweiligen Datenquelle explizit unterstützt werden. Das können z. B.
144
5.4 Adapter für den BioDataServer
komplexe Aggregat- und Statistikfunktionen eines DBMS oder API-Funktionen sein.
Im Gegensatz zu künstlichen Attributen können natürliche Attribute einer Datenquelle
in subgoals enthalten sein, müssen aber nicht in das Adapterschema aufgenommen
werden.
Im einfachsten Fall kann ein explizit vorhandenes Datenschema einer Datenquelle,
das Exportschema, als Adapterschema übernommen werden. Das kann z. B. bei einem
direkten Zugriff auf ein DBMS erfolgen, wobei das Datenschema aus dem Datenbankkatalog abgefragt werden kann und zu jedem Attribut eine Zugriffsfunktion, z. B. in
Form von SQL, besteht. Der Aufwand zur Kapselung eines solchen Datenquellentyps
durch einen Adapter ist somit gering.
Beim Vorhandensein von API-Funktionen zum Zugriff auf Attributwerte einer Datenquelle, z. B. mittels BioJava, können diese Attribute direkt in ein Adapterschema
aufgenommen werden. Umfaßt die Datenquelle aber Attribute, die nicht über die API
angefragt werden können, so sind hierzu explizit vom Adapter zusätzlich entsprechende
subgoals zu implementieren. Das wiederum bedeutet einen hohen Entwicklungs- und
Wartungsaufwand für solche Adapter.
Im ungünstigsten Fall existiert keine API oder DBMS-Funktionalität für eine Datenquelle. Das ist z. B. bei flat-files der Fall, zu denen keine Parser existieren. Die Folge ist,
daß zum einen ein explizites Datenschema nicht vorhanden ist und somit ein Reengi”
neering“ durchgeführt werden muß. Wie bereits in Abschnitt 3.1.2 des Grundlagenkapitels erwähnt, befassen sich hiermit verschiedene Forschungsprojekte, die automatische
und semi-automatische Methoden zur Datenschemableitung aus flat-files vorschlagen.
Diese können bezüglich der Extraktion von Attributen angewandt werden. Zur Ableitung von Tabellen als funktionale Gruppierung ist Expertenwissen zu den funktionalen
Beziehungen und der Attributsemantik notwendig. Es kann also gefolgert werden, daß
eine vollständige Automatisierung einer Adapterschemaableitung aus flat-files ohne explizit vorhandene Strukturbeschreibung nicht möglich ist. Desweiteren sind für den, in
diesem Absatz beschriebenen Typ von Datenquellen alle subgoals durch den Adapter
zu implementieren, sobald sie aus dem zugrundeliegenden flat-file-Attributen abgeleitet
worden sind. Intuitiv kann dies über Parser in Kombination mit einer Indizierung des
flat-files umgesetzt werden. Diese Methode findet z. B. beim im Abschnitt 3.2.3 vorgestellten Sequence Retrieval System“ (SRS) Anwendung. Dabei ist zu erkennen, daß
”
der Aufwand der Parserimplementierung und -pflege gerade bei den sich evolutionär
entwickelnden Dateiformaten erheblich ist.
Zusammenfassend werden in Tabelle 5.4.1 die Arten der Adapterschemamodellierung in Bezug zu den Kosten einer Schemableitung und zur Anfragemächtigkeit einer
durch einen Adapter zu kapselnden Datenquelle klassifiziert. Zur weiteren Veranschaulichung ist ein aus der KEGG-Datenbank abgeleitetes Adapterschema im Anhang B.4
enthalten. Mögliche, dazu passende subgoal-Implementierungen wurden in Beispiel 4.13
vorgestellt.
145
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
Adapterschemamodellierung
Kosten der
Schemaableitung
DBMS API flat-file
atomare Attribute
gering
mittel hoch
künstliche Attribute
gering
hoch
hoch
kein
hoch
kein
kein
kein
gering
gering
akkumulierte
Attribute
subgoalImplementierungskosten
Datenquelle Adapter
gering
hoch
hoch
gering
Tabelle 5.2: Kostenklassifikation der Adapterschemaerstellung
Datenextraktion
Zur Zuweisung von Attributwerten zu den im Adapterschema modellierten Attributen
ist die Extraktion von Daten aus den zugrundeliegenden Datenquellen notwendig. In
diesem Schritt werden aus den Ergebnissen einer Datenanfrageausführung die Attributwerte extrahiert. Ähnlich der subgoal-Implementierung für die Datenanfrage zu einem
Adapterschemaattribut bestimmt der Typ der Datenquelle die Methode der Datenextraktion. Durch die Adapter ist entsprechend der verfügbaren Schnittstelle entweder ein
direkter Zugriff auf die Attributwerte eines Anfrageresultates oder eine nachträgliche
Datenextraktion aus dem Anfrageergebnis, z. B. aus einem flat-file, umzusetzen. Für
Datenquellen, die über eine JDBC-Schnittstelle verfügen, kann der Adapter automatisch generiert werden. Dagegen ist bei proprietären APIs oder bei nicht selbstbeschreibenden flat-files der Adapter manuell zu entwickeln. Eine weitere Möglichkeit bilden in
XML-formatierte flat-files, die über eine DTD oder ein XML-Schema verfügen. Auch
hier wäre eine automatische Adaptergenerierung möglich. Bei den zur Zeit verfügbaren
Adaptern des BioDataServers wurden bislang drei Adaptertypen unterschieden:
1. JDBC-basiert
2. Parser-basiert
3. Manuell
In der Klasse der JDBC-Adapter wird, ausgehend von einer existierenden JDBCSchnittstelle, der Adapter automatisch generiert. Grundlage hierzu bilden Arbeiten aus
[100]. Es werden bei diesem Ansatz allein die Datenbankverbindungsparameter, die
Datenquelleninformationen, wie der Adaptername etc. und ein zuvor erstelltes Adapterschema einem Adaptergenerierungswerkzeug bereitgestellt. Dieses Werkzeug erzeugt
aus diesen Parametern JAVA-Kode, der das definierte Adapter-JAVA-Interface aus Anhang B.2 implementiert.
Adapter, die flat-files aus Datenquellen abfragen, müssen diese parsen, um Attributwerte zu extrahieren. Hier kommt ein semi-automatischer Ansatz, ebenfalls aus [100],
146
5.4 Adapter für den BioDataServer
zum Einsatz. Basierend auf einer vom Adapterentwickler zu spezifizierenden Grammatik und einem zuvor erstellten Adapterschema wird mittels des Parsergenerators
JAVACC [99] ein Parser für alle zu extrahierenden Attributwerte generiert. Dieser
wird automatisch mit zusätzlichem JAVA-Kode angereichert, um das Adapter-JAVAInterface zu implementieren. Die Spezifikation der JAVACC-Grammatik stellt hierbei
die Hauptkosten der Adapterentwicklung dar. Im Anhang B.6 sind Auszüge von JAVACC-Grammatiken und das dazu manuell erstellte Adapterschema dargestellt. Im
Anhang sind drei Dateien wiedergegeben, die als Eingabe für den Adaptergenerator
zur Erzeugung des KEGG-Adapters dienen, der subgoals zur Anfrage von Enzymdaten umsetzt. Der KEGG-Adapter soll mehrere subgoals implementieren: eines ermittelt
alle Enzymnummern: HKEGG,1 ( ; ec nr), die anderen ermitteln zu einer gegebenen Enzymnummer jeweils die Werte zu einem Attribut aus KEGG. Das kann etwa subgoal
HKEGG,2 (ec nr; name) sein. Bei der ersten Datei handelt es sich um eine Datenquellenbeschreibungsdatei, die neben Datenquellen beschreibende Elemente, die Zugriffspfade
zu der Datenquellenschnittstelle und das Adapterschema in einer proprietären Syntax spezifiziert. Allen subgoals des Adapters liegen zwei URLs zugrunde, die als CGISchnittstelle zur Middleware von KEGG dienen. Die erste URL ( keysurl“) dient
”
dem Zugriff auf alle Enzymnummern und implementiert damit HKEGG,1 . Auf Basis der
zweiten URL ( url“) werden alle weiteren subgoals umgesetzt, da hier alle Attribute
”
des KEGG-Adapters zum Eingabeattribut ec nr abgefragt werden können. Im Anschluß an das Adapterschema, am Ende dieser Beschreibungsdatei, sind Verweise auf
die Dateien, welche die Grammatiken zum Parsen und somit zur Datenextraktion der
einzelnen Attribute enthalten: datagramma und keygramma. Weitere Erläuterungen
zur Methode der kurz skizzierten Adaptergenerierung sind in [100] nachzulesen.
Alle Adapterimplementierungen sind manuell vorzunehmen und nutzen vorhandene
APIs oder andere in Abschnitt 3.1.2 vorgestelle Schnittstellen. Da hierbei alle Änderungen direkt im JAVA-Kode vorgenommen werden müssen, ist dieser Adaptertyp
mit hohen Wartungskosten verbunden. Im Vergleich zur Erstellung einer Grammatik
für den Parser-basierten Adaptertyp ist die Entwicklungszeit durchaus geringer. Eine
Vorlage zur manuellen Adapterimplementierung ist im SourceForge-CVS-Verzeichnis
des BioDataServers verfügbar:
cvs/biodataserver/BDS/mediator/adapter/Test.java
Aus den hier vorgestellten Methoden zur Adaptererstellung resultieren ca. 25, sich
bezüglich der so an den BioDataServer angekoppelten Datenquellen überschneidenden
Adapter, die als Teil des BioDataServers SourceForge-Projekt unter der URL
http://sourceforge.net/projects/biodataserver
verfügbar sind.
147
Kapitel 5 Datenbankintegrationssystem BioDataServer (BDS)
5.5 Resümee
Zur Umsetzung der im Kapitel 4 erarbeiteten Konzepte zur Datenbankintegration in
der Molekularbiologie wurden in diesem Kapitel die Systemarchitektur, Spezifikationen und Implementierungsaspekte des Datenbankintegrationssystems BioDataServer
(BDS) vorgestellt. Da in der Bioinformatik die Fusion von Daten und Methoden, d. h.
die Informationsgewinnung durch die Analyse integrierter Datenbanken durch Bioinformatikalgorithmen, eine entscheidende Rolle einnimmt, wurde zu Beginn des Kapitels
eine entsprechend fokussierte Anforderungsanalyse eines Datenbankintegrationssystems
durchgeführt. In der resultierenden Systemarchitektur wurde der BDS als Importkomponente eingesetzt, kann aber auch als eigenständiger Mediator in einer Client-ServerArchitektur genutzt werden.
Die Spezifikation des Mediators erfolgte im zweiten Teil des Kapitels. Neben Klassendiagrammen und Syntaxbeschreibungen der Datenschemata als Kernkomponente des
Mediators zur Schemaintegration stand die Spezifikation der BDS-Schnittstelle im Vordergrund. Insbesondere das TCP/IP-basierte Protokoll, die Kommandosprache und die
Implementierung des SQL-Dialektes des BDS wurden detailliert mittels entsprechender
UML-Diagramme als Voraussetzung zur Implementierung von Anwendungen auf dem
BDS dokumentiert.
Die Implementierung des BDS erfolgte als Open Source“-Projekt und ist im Source”
Forge-Projekt verfügbar. Einige ausgewählte Implementierungsaspekte wurden im dritten Teil des Kapitels vorgestellt. Dabei wurden sowohl die Organisation des Quellkodes
als auch ausgewählte Implementierungen vorgestellt. Dazu zählten die Erläuterung der
parallelisierten Ausführung von Anfrageplänen, der Auflösung von SQL-Anfragen und
der Umsetzung von Verbundoperationen.
Das Kapitel schloss mit einem Überblick zur Erstellung von Adaptern, welche die
vom BDS zu nutzenden Datenquellen kapseln, um subgoals und ein Adapterschema bereitzustellen. Dazu konnte zum großen Teil auf bestehende Arbeiten verwiesen werden.
Neben der Klassifikation von Ansätzen zur Generierung bzw. zur manuellen Erstellung
von Adaptern wurde die Modellierung von Klassen- und Aktivitätsdiagrammen als
Spezifikation des von Adaptern zu implementierenden JAVA-Interfaces und der Ausführungsreihenfolge von Adapteranfragen dokumentiert. Abschließend wurden aus der
Erfahrung des Autors resultierende Abschätzungen und Empfehlungen zu Kosten und
der Praktikabilität von Techniken der Adapterimplementierung angegeben.
148
Kapitel 6
Anwendungen des Integrationsdienstes
Aus dem zuvor erarbeiteten Konzept einer Datenbankintegration für molekularbiologische Datenquellen mit beschränkten Zugriffsmustern und der Umsetzung in Form
des Mediator-Wrapper-Datenbankintegrationsdienstes BioDataServer (BDS) entstanden Applikationen, welche die Anwendbarkeit des in dieser Arbeit vorgeschlagenen Ansatzes zur Datenbankintegration demonstrieren. Weiterhin werden Forschungsergebnisse aus dem Bereich der funktionalen Genetik vorgestellt, die in einem hohen Maße von
der Existenz von Datenbankintegrationssystemen, wie dem BioDataServer, abhängen.
Als Importwerkzeug betrachtet, ist ein Szenario von flexiblen Data Warehouses umsetzbar, so wie es in Form des DBOra“-Systems demonstriert wurde [145]. Dazu wurde
”
ein Datenbankkopierwerkzeug Debbie“ entwickelt, das verschiedene JDBC-zugängliche
”
Datenbanken, unter besonderer Beachtung des BioDataServer, in Ziel-DBMS kopiert.
Somit kann Debbie insbesondere als Datenladewerkzeug für Data Warehouses genutzt
werden.
Als autonomer Mediator betrachtet, wird Bioinformatikanwendungen die Möglichkeit geboten, gemäß individueller Anforderungen auf nicht materialisierte, integrierte
Datenquellen zuzugreifen. Als Beispiel hierzu werden
• das Informationssystem CR-EST“ [49] zu Pflanzen-ESTs,
”
• ein Informationssystem zu metabolischen Krankheiten und Patienten ( RAME”
DIS“) [146],
• ein Softwaresystem zur klinischen Analyse von Genotyp-Phänotyp-Korrelation
[147] und
• das Bioinformatikwerkzeug METATOOL“ [148] zur Analyse metabolischer Netze
”
mit integrierten molekularbiologischen Daten versorgt.
Darüber hinaus ermöglicht der als eigenständig, über das Internet erreichbare Dienst
mit der zugehörigen JDBC- und ODBC-API eine nahtlose Einbindung in Datenbankintegrationssysteme verschiedener Projekte, wie etwa
• das Projekt zur Modellierung und Animation regulatorischer Genwirknetze
( MARGBench“) [149],
”
• dem objektorientierten System zur Modellierung, Integration und Analyse genkontrollierter metabolischer Netzwerke ( iUDB“) [138, 139] oder
”
149
Kapitel 6 Anwendungen des Integrationsdienstes
• dem semantischen Datenbankintegrationssystem SEMEDA“ [61, 51].
”
Insbesondere die Projektanforderungen des MARGBench-Projektes waren für die
Entwicklung des BioDataServers richtungsweisend. Vom damaligen Prototypen, zu dem
unter der URL
http://www.genophen.de
einige Demonstrationsanwendungen verfügbar sind, wurde die heutige Gesamtarchitektur und Implementierung abgeleitet. In den folgenden Abschnitten werden diese
Anwendungen des BioDataServer vorgestellt.
6.1 Datenimportwerkzeug Debbie
Der Export oder der Import von Daten aus bzw. in verschiedene DBMS zum Zwecke
ihrer Analyse oder Integration mit weiteren Daten ist eine häufig anzutreffende Anwendung von DBMS in der Bioinformatik. Beispiele sind die verschiedenen flat-files, die aus
DBMS exportiert werden, um als Eingabe für dateibasierte Analysewerkzeuge zu dienen. Ein prominentes Beispiel hierzu ist das FASTA-Format für das BLAST-Werkzeug
zur Berechnung lokaler Alignments von Sequenzen [89]. Zur Erzeugung dieser Dateien werden verschiedene, proprietäre Funktionen angewandt, die von SQL-Skripten für
DBMS bis zu API-Funktionsaufrufen, wie z. B. in BioJava, reichen.
Ein weiteres Ziel der Datenimporte sind in vielen Fällen relationale DBMS. So werden
spezielle Data Warehouses aufgebaut, die für bestimmte Anwendungsfälle entwickelt
wurden. Beispiele sind etwa COLUMBA [150], eine integrierte relationale Datenbank
zur Analyse von Proteinfunktionen, GeneKeyDB [151], die relational integrierte Daten zu Genen zur Unterstützung von Data Mining enthält, oder Atlas [152], ein Data Warehouse für integrative Bioinformatik. Diese Systeme basieren auf relationalen
DBMS. Zum Zweck des Datenimportes wurden proprietäre Skripte eingesetzt. Im Falle
kommerzieller DBMS existieren zu Datenimportzwecken vorgefertigte, auf das jeweilige DBMS zugeschnittene Lösungen. Ein guter Überblick zu kommerziellen und frei
verfügbaren Datenimportwerkzeugen inklusive deren Bewertung ist in [142] zu finden.
Um ein allgemein anwendbares Werkzeug für den Datentransfer zwischen relationalen DBMS unter Einbeziehung des BioDataServers als Importquelle zur Verfügung zu
stellen, wurde das Datenimportwerkzeug Debbie“ im Rahmen einer Praktikumsarbeit
”
umgesetzt. Um eine breite Anwendbarkeit zu gewährleisten, ist Debbie plattformunabhängig in JAVA implementiert. Es können diejenigen DBMS über Debbie zum Datenimport und -export genutzt werden, die einen JDBC-Treiber zur Verfügung stellen. Zu
jedem so zu nutzenden DBMS muß ein Plugin implementiert werden, das die Datenbankoperationen zum Anlegen und Löschen von Tabellen, die Konvertierung von DBMSspezifischen Datentypen sowie den Datentransfer übernimmt. Zur Zeit existieren diese
Plugins für ORACLE, PostgreSQL, MySQL sowie für den BioDataServer.
Debbie unterstützt einen interaktiven und einen Batch-Modus. Im interaktiven Modus werden die zu kopierenden Tabellen und Attribute ausgewählt und das Ziel-DBMS
spezifiziert. Das resultiert in einem sogenannten Transfer-Job, der entweder in der GUI
150
6.2 Datenbankbrowser- und Explorationswerkzeug DBOra
oder in der Kommandozeile als Stapelverarbeitungsprozeß gestartet werden kann. In
diesem Fall kann Debbie mit vorher spezifizierten Jobs zyklisch ausgeführt werden,
um etwa wöchentlich neue Daten in ein Ziel-DBMS zu importieren. Für einen Import
existieren zwei Modi:
Überschreiben
Hier werden im Zieldatenschema zu importierende Tabellen neu angelegt, wenn
diese noch nicht existieren. Falls bereits Tabellen existieren, werden diese zuvor
entfernt. Anschließend werden die Tupel in die Zieltabellen eingefügt.
Anhängen
Wird dieser Modus gewählt, so werden die zu importiernden Daten an bestehende
Tabellen angehängt. Ist dies aufgrund von Konsistenzbedingungen nicht möglich,
so wird das entsprechende Tupel ignoriert.
Die zum Anlegen von Tabellen im Zieldatenbankschema notwendigen DDL-Operationen beschränken sich auf das Übertragen von Tabellendefinitionen inklusive Attributen
und notwendigen Typkonvertierungen. Integritätsregeln, wie etwa Fremdschlüssel, werden nicht berücksichtigt. Es können so entweder 1:1 die Tabellendefinitionen in das
Zielschema übertragen werden oder Umbenennungen der Tabellen oder Attribute festgelegt werden.
Darüber hinaus bietet Debbie die Möglichkeit, verschiedene Parameter für den Datentransfer zu setzen:
• Anzahl gleichzeitig zu transferierender Tupel ( fetchsize“)
”
• Puffergröße für Binary Large Objects (BLOB)
• Tunnelung und Verschlüsselung über das SSH-Protokoll
Diese Parameter und die genannten Regeln für die DDL-Operationen werden als Importskript für Debbie in einer XML-Datei pro Job zusammengefaßt.
Der Screenshot in Abbildung 6.1 zeigt die graphische Nutzeroberfläche des Werkzeuges. Eingesetzt wird Debbie u. a. für die im Abschnitt 6.2 beschriebene integrierte
Proteomics-Datenbank DBOra“ sowie für diverse interne Projekte am IPK Gatersle”
ben. Da das Werkzeug unter dem Schutz eines Betriebsgeheimnisses steht, ist es nicht
frei verfügbar.
6.2 DBOra: Das Browser- und Explorationswerkzeug
für materialisiert integrierte Datenbanken
Bei DBOra“ [145] handelt es sich um ein webbasiertes, graphisches Werkzeug zum
”
Suchen und Navigieren in Proteomicsdaten. Darüber hinaus werden transitive Beziehungen in den Daten berechnet, die sogenannten Data Linkage Graphs“ (DLG) [153]
”
bilden und als Basis für funktionale Klassifikationen von EST-Sequenzen dienen. Die
151
Kapitel 6 Anwendungen des Integrationsdienstes
Abbildung 6.1: Screenshot des Datenbankimportwerkzeugs Debbie
Grundlage bildet eine integrierte, relationale Datenbank, in der, mit Hilfe des BioDataServers und proprietärer Skripte, Daten aus öffentlichen Datenquellen importiert wurden. Die Technologieplattform bildet dabei ORACLE in Verbindung mit einem PHPInterpreter. DBOra enthält Protein-, Stoffwechselweg- und Krankheitsdaten aus öffentlichen Quellen (UniProt, OMIM, BRENDA, GeneOntology und KEGG). Mittels des
in Abschnitt 6.1 vorgestellten Werkzeuges Debbie werden in ein zuvor modelliertes Datenschema die Daten in die jeweiligen Tabellen importiert. Nach dem Import von ca. 5
GB 1 relevanten Daten aus den genannten Datenbanken verteilen sich ca. 16 ∗ 106 Tupel
auf 98 Tabellen. Die auf diese Weise strukturierten Daten aus dem Proteomicsbereich
sind die Grundlage für die zwei Funktionsmodule von DBOra: die manuelle, sukzessive Datenexploration und die automatische Datenbeziehungsexploration. Ziel war es,
eine vom Datenschema unabhängige Lösung zu schaffen, die als Framework für weitere
relationale, auf ORACLE-basierten Datenbanken dient. So ist es möglich, weitere Datenschemata zu konzipieren, diese mit öffentlichen oder privaten Daten zu belegen und
dann ad-hoc über die Funktionalität von DBOra dem Anwenderkreis zur Verfügung
zu stellen. Die entwickelten Softwaremodule wurden im Rahmen eines IPK-internen
Projektes entwickelt und stehen als Betriebsgeheimnis nicht frei zur Verfügung.
1
Stand November 2005
152
6.2 Datenbankbrowser- und Explorationswerkzeug DBOra
6.2.1 DBOra-Datenbrowser
Die Browserkomponente wurde als generische Web-Oberfläche zum Suchen und explorativen Navigieren im integrierten Datenbestand umgesetzt. Die Flexibilität dieser
Lösung beruht auf SQL-Skripten, welche die jeweilige integrierte Datenbank automatisch aufbereiten, was somit die Austauschbarkeit der zugrundeliegenden Datenbank
ohne Anpassung der Browserkomponente ermöglicht.
Zur Bereitstellung der HTML-Benutzeroberfläche wurde ein generisches PHP-Skript
implementiert, das auf die zuvor aufbereitete Datenbank aufsetzt. Die Relationen sind
über Fremdschlüssel untereinander verknüpft und durch Indexe so aufbereitet, daß eine
ähnlichkeitsbasierte Freitextsuche möglich ist. Ähnlichkeitsoptionen, wie Wortstamm, Phonetik- oder Wortnachbarschaftssuche, sind spezifizierbar. Anschließend ist eine
Navigation über die mit Fremdschlüsseln angedeuteten Beziehungen bzw. eine erneute Suche nach, zu dem aktuell angezeigten Datensatz ähnlichen, Datenbankeinträgen
möglich. Weiterhin wird durch die Ankopplung des BLAST-Werkzeuges [89] eine Homologiesuche über den in der Datenbank enthaltenen Aminosäurensequenzen bzw. Nukleotidsäurensequenzen ermöglicht. In der Abbildung 6.2 ist ein Screenshot der Suchoptionen der DBOra-Anwendung dargestellt. Neben der bereits integrierten Datenbank
Abbildung 6.2: Screenshot des DBOra-Datenbankbrowsers
ist es möglich, Projektdatenbanken automatisch so aufzubereiten, daß hier die zuvor
153
Kapitel 6 Anwendungen des Integrationsdienstes
beschriebenen Anwendungsfunktionen mittels dieser Web-Oberfläche dem Anwender
ad-hoc zur Verfügung stehen.
6.2.2 Berechnung von Data Linkage Graphs
Die in der Datenbank definierten Fremdschlüssel können neben ihrer eigentlichen Bedeutung für die Konsistenzerhaltung auch als Beziehungen zwischen Tabellen betrachtet
werden. So ist es möglich, neben der eigentlichen Beziehung von Attributen innerhalb
einer Tabelle, Attribute über Fremdschlüssel in Beziehung zu setzen. Da ein Attribut
der Datenbank über den Attributnamen A und den Tabellennamen T eindeutig identifiziert wird, kann so eine Menge S von Schlüssel- bzw. Fremdschlüsselattributen gebildet
werden: S = (T, A). Dabei ist A entweder ein Schlüssel- oder ein Fremdschlüsselattribut. Auf dieser Basis läßt sich diejenige Untermenge R ⊆ S × S aller möglichen
Beziehungen zwischen Schlüsseln definieren:
Rs
Rf
Rt
R
=
=
=
=
{(s, f ) | s, f ∈ S ∧ f ist Fremdschlüssel von s}
{(f, s) | f, s ∈ S ∧ s ist Primärschlüssel von f }
{(s1 , s2 ) | s1 , s2 ∈ S ∧ s1 .T = s2 .T }
Rs ∪ Rf ∪ Rt
Zieht man nun noch die Attributwerte hinzu, so ist es möglich, Paare von Attributwerten zu finden, die zueinander in Beziehung stehen. So wird das Paar S mit einem
Attributwert W zu einem Tripel SW erweitert. Die Konzepte der relationalen Algebra
nutzend, bestimmt sich der Attributwert W als ein Element der Domäne des Schlüsselattributes: SW = (T, A, W ) | W ∈ dom(T, A). Unter Nutzung der Operationen
der relationalen Algebra kann eine Relation ⇋ gebildet werden, die definiert, ob zwei
Attributwerte in Beziehung zueinander stehen:
sw1 ⇋ sw2 ↔ t1 = sw1 .T ∧ a1 = sw1 .A ∧ w1 = sw1 .W ∧
t = sw2 .T ∧ a2 = sw2 .A ∧ w2 = sw2 .W ∧
2
(Bed. 1)
(Bed. 2)
((t1 , a1 ), (t2 , a2 )) ∈ (Rs ∪ Rf ) ∧ πa1 (σa2 =w2 (t2 )) = πa2 (σa1 =w1 (t1 ))
∨
((t1 , a1 ), (t2 , a2 )) ∈ Rt ∧ σa1 =w1 (t1 ) = σa2 =w2 (t2 )
Umgangssprachlich ausgedrückt stehen zwei Attributwerte in Beziehung zueinander,
1. wenn sich die entsprechenden Attribute in einer Fremdschlüsselbeziehung zueinander befinden, also Element der Menge Rs oder Rf sind und die Attributwerte
in beiden Tabellen gleich sind oder
154
6.2 Datenbankbrowser- und Explorationswerkzeug DBOra
2. wenn sich die entsprechenden Attribute in ein und derselben Tabelle befinden,
also Element der Menge Rt sind und die Attributwerte in den gleichen Tupeln
(Zeilen) sind.
Auf der Grundlage der transitiven Anwendung dieser Relation ⇋ können Graphen
G = (SW, E) gebildet werden. Dabei sind die Knoten S die Attributwerte und E die
Kanten:
E = (sw1 , sw2 ) | sw1 , sw2 ∈ SW
Weiterhin muß folgende Bedingung gelten:
E ⊆ SW × SW ∧ ∀(sw1 , sw2 ) ∈ E : sw1 ⇋ sw2
In Abbildung 6.3 sind zwei Beispielgraphen dargestellt, die jeweils einen Pfad zwischen
einem Eintrag der EMBL-Datenbank, d. h. einer Nukleotidsequenz, und einem Eintrag
aus der KEGG-Datenbank, z. B. einem Stoffwechselweg, bilden. Im Beispiel werden
Abbildung 6.3: Beispiel von Data Linkage Graphs“ aus DBOra
”
die verschiedenen Attributbeziehungen deutlich. In der Tabelle ENZYME findet so die
Beziehung Rt und zwischen den anderen Tabellen finden die Beziehungen Rs und Rf
Anwendung. Die Tabelle ENZYME ist somit eine Koppeltabelle“, die etwa bei der Mo”
dellierung von m:n-Beziehungen eingesetzt werden kann.
Die Berechnung dieser Graphen bildet die Grundlage für die Bestimmung von transitiven Beziehungen zwischen Attributwerten in integrierten Datenbanken. Diese Funktionalität kann durch den relationalen Verbundoperator berechnet werden. Da die Berechnung eines solchen Verbundes über mehrere Tabellen, gerade im Falle des DBOraDatenbankschemas mit 98 Tabellen, aufgrund der Implementierung über Merge-Joins“
”
erhebliche Kosten an RAM-Speicher und CPU verursacht, wurde eine eigene Implementierung der Graphenberechnung in Form einer modifizierten Tiefensuche eingesetzt
[153].
Aus den berechneten Graphen können verschiedene Anwendungen abgeleitet werden, wie z. B. die Berechnung der transitiven Hülle eines Attributwertes, um indirekte
funktionale Beziehungen zwischen Daten in integrierten molekularbiologischen Datenbanken aufzudecken. Im Fall der DBOra-Datenbank ist es so möglich, Proteine und
155
Kapitel 6 Anwendungen des Integrationsdienstes
Gene mittels transitiver Beziehungen in den integrierten Datenbanken funktional zu
klassifizieren. So kann z. B. ein Gen transitiv einer enzymatischen Funktion zugeordnet
werden.
6.2.3 Funktionsklassifikationen mittels Data Linkage Graphs
Viele biologische Fragestellungen, insbesondere aus der Expressionsanalyse zu Genen,
beschäftigen sich mit der funktionalen Zuordnung von biologischen Makromolekülen
bzw. deren abstrakter Repräsentation, wie etwa EST’s. Über eine funktionale Annotation zu EST-Sequenzen, die mittels einer Sequenzhomologiesuche in öffentlichen Datenbanken, etwa durch das Werkzeug BLAST [89], durchgeführt werden kann, ist es z. B.
möglich, Schlüsselattribute und -werte zu ermitteln, die in DBOra vorhanden sind.
Mit Hilfe der vorberechneten Data Linkage Graphs können transitive Attributbeziehungen zu dem über BLAST gefundenen Attributwert bestimmt werden. So kann z. B.
ermittelt werden, ob zum gegebenen Attributwert, und damit zu einer EST-Sequenz,
Daten zu einer bestimmten Funktionsklasse, wie etwa Stoffwechselwege, in Beziehung
stehen. Dieser Klassifikationsprozeß ist beispielhaft in Abbildung 6.4 dargestellt. Hier
wird eine Sequenz über BLAST mit öffentlichen Sequenzdatenbanken verglichen. Aus
dem resultierenden Ergebnis werden die in der Abbildung markierten Schlüsselwerte
extrahiert und als Eingabe für eine Suche nach möglichen transitiven Beziehungen zu
Stoffwechselwegen genutzt.
Abbildung 6.4: Prozeß der metabolischen Klassifikation von EST-Sequenzen
Die dazu notwendige Anfrage auf die Data Linkage Graphs wird über relationale
Speicherung der Graphen und unter Nutzung von rekursiven SQL-Sprachkonstrukten
zur Abfrage von hierarchischen Tabellen umgesetzt. Der Vorteil einer relationalen Speicherung von Graphen besteht in der Möglichkeit, sehr gut skalierende DBMS-Implementierungen, wie z. B. ORACLE, zu nutzen, was für einfache Graphanfragen, wie
etwa einer Suche von transitiven Beziehungen, zu gutem Antwortverhalten, gerade bei
großen Datenmengen, führt. So konnten auf diese Weise die ca. 225.000 EST-Sequen-
156
6.3 Anwendung in der Medizinischen Informatik
zen und 44.500 Konsensussequenzen2 mit insgesamt 2.3 ∗ 106 BLAST-Resultaten der, in
Abschnitt 6.7 vorgestellten, EST-Datenbank in ca. 60 Minuten automatisch funktional
klassifiziert werden. Das geschah auf Basis der metabolischen Funktion aus KEGG [14]
sowie der Funktionsklassen aus der Gene Ontology [62].
Als nachteilig bei der Umsetzung von Graphanfragen auf der Basis des relationalen Datenmodells stellt sich das Fehlen von Pfadausdrücken heraus. So ist es durchaus
sinnvoll, nur bestimmte Pfade zur Ermittlung von transitiven Beziehungen zuzulassen,
die über bestimmte Knoten, d. h. Attribute, laufen, die vom jeweiligen Anwender als
vertauenswürdig eingestuft wurden. Für solche Fälle wird in [154] eine Kombination
aus relationalen und hierarchischen Anfragesprachen vorgeschlagen, um eine performante und funktionale DLG-Anfragebasis zum späteren Einsatz für ein Data Mining
auf integrierten molekularbiologischen Datenquellen bereitzustellen.
6.3 Anwendung in der Medizinischen Informatik
An den Universitäten Magdeburg und Bielefeld wird in Zusammenarbeit mit dem Kinderkrankenhaus Reutlingen ein System zur Erkennung von angeborenen Stoffwechseldefekten entwickelt [146, 147]. Mit Methoden des fallbasierten Schließens in Verbindung mit integrierten öffentlichen Datenbanken und einer, von der gleichen Gruppe
umgesetzten, Datenbank zu metabolischen Krankheiten und Patienten ( RAMEDIS“)
”
[155] wird ein Werkzeug implementiert, das im Rahmen des DHGP in der klinischen
Forschung eingesetzt werden soll. Mit den in der RAMEDIS-Datenbank gesammelten
Krankheitsfällen und den dazu gespeicherten Attributen, wie verschiedene Laborwerte,
Fallbeschreibungen, Diagnosen und Referenzen, wurde eine Wissensbasis für ein medizinisches Informationssystem zur Analyse von Stoffwechselerkrankungen geschaffen.
Die Analyse metabolischer Prozesse und die Genexpression als miteinander verbundene dynamische Netzwerke bildet den Grundansatz dieses Systems. Zur spezifischen
Anwendung der Algorithmen des fallbasierten Schließens auf integrierten Datenbanken
werden neben den Standarddatentypen, wie String, Integer etc., erweiterte Datentypen
eingeführt. Dazu gehören z. B. der Datentyp Biochemical Reaction. Diese Datentypen
werden mit einem Konzept abstrakter Datendomänen verbunden und bilden das Basiskonzept einer Genotyp-Phänotyp-Analyse. Ausgehend von vorhandenen Datenbanken
werden ausgewählte Datensätze unter der Nutzung des BioDataServers gemäß eines
vorgegebenen Datenschemas integriert und in eine relationale Datenbank importiert.
Auf den so fusionierten Daten werden Algorithmen des fallbasierten Schließens angewandt, die über eine Web-basierte Nutzerschnittstelle initiiert werden können. Die
graphische Darstellung der Ergebnisse erfolgt ebenfalls durch diese Oberfläche. Diese
Vorgehensweise ist in Abbildung 6.5 veranschaulicht.
2
Hierbei handelt es sich um ein Repräsentationsmittel, um das Resultat multibler (EST-)Sequenzalignements darzustellen. Auf diese Weise können ähnliche Sequenzen zu einer Gesamt- bzw. Konsensussequenz vereinigt werden.
157
Kapitel 6 Anwendungen des Integrationsdienstes
Existierende
Analysewerkzeuge
Nutzer
Genotyp-PhänotypAnalyse
Domänendatenverwaltung
Lokale
Speicherung
Replikationssteuerung
Datenintegration
Integrierte Analyseumgebung
Datenquellen
Abbildung 6.5: Systemarchitektur des Genotyp-Phänotyp-Analysesystems aus [147]
Die dargestellte Systemarchitektur stellt verschiedene DBMS-Standardschnittstellen
für Endanwender und für Analysewerkzeuge bereit. Die Teilkomponenten der Architektur werden im folgenden kurz vorgestellt.
Datenintegration
Ausgehend von der anwendungsbezogenen Analyse der verbreiteten medizinischen
und molekularbiologischen Datenbanken wurde eine Menge dieser Systeme zur
Integration ausgewählt. Dazu gehören die Datenbanken BRENDA, TRANSFAC,
TRANSPATH, OMIM, SwissProt und EMBL. Zur Integration von ausgewählten
Ausschnitten dieser Datenbanken wurde der BioDataServer herangezogen.
Lokale Speicherung
Die materialisierte Speicherung der integrierten Datenbanken ist die Voraussetzung zur Anwendung der Analysemethoden des Genotyp-Phänotyp-Analysesystems. Hierzu werden die, durch die Integrationskomponente gewonnen, Daten in
ein ORACLE-DBMS repliziert.
158
6.3 Anwendung in der Medizinischen Informatik
Replikationssteuerung
Die zur Replikation notwendigen Methoden sind Bestandteil dieser Komponente.
Hier wurden Mechanismen zur Steuerung eines zyklischen Datenimports über die
Datenintegrationskomponente implementiert.
Domänendatenverwaltung
Die Teilkomponente Domänendatenverwaltung innerhalb der Integrierten Analyseumgebung ermöglicht es dem Nutzer, individuelle Anforderungen an den Inhalt
und die Präsentation des integrierten Datenbestandes zu definieren. Außerdem
bildet sie die Grundlage für eine Untersuchung von Genotyp-Phänotyp-Korrelationen in der Teilkomponente Genotyp-Phänotyp-Analyse und stellt für diese
Aufgabe zusätzlich benötigte semantische Daten über den integrierten Datenbestand bereit. Dazu werden verschiedene nutzerspezifische Datendomänen in Form
von Sichten angelegt. Bestandteil einer solchen Sicht sind die Definition verschiedener Attribute für Suchoperationen und die Festlegung der Repräsentation über
die graphische Nutzerschnittstelle. Die Beziehungen zwischen Sichten werden außerdem durch abstrakte Konzepte, wie Generalisierung oder Spezialisierung, beschrieben.
Genotyp-Phänotyp-Analyse
Ziel dieser Teilkomponente ist die Bereitstellung von Methoden zur Unterstützung des Nutzers bei der Suche und Verwaltung von Zusammenhängen auf Basis
einer Genotyp-Phänotyp-Korrelation innerhalb des integrierten Datenbestandes.
Dabei werden dem Anwender über eine graphische Nutzerschnittstelle geeignete
Werkzeuge bereitgestellt, die eine Navigation innerhalb und zwischen den Informationsdomänen erlauben.
Die als Prototyp implementierte und in Abbildung 6.6 als Screenshot dargestellte
Web-Anwendung dieses Systems bildet die zentrale Schnittstelle zur Pflege und Eingabe
von Krankheitsfällen sowie deren Analyse mittels Methoden des fallbasierten Schließens.
Dabei sind die folgenden GUI-Ausschnitte des Prototypen dargestellt:
(a) Anfragemaske mit vordefinierten Informationsdomänen
(b) Beispiel eines vom Nutzer ausgewählten Pfades vom Genotyp (Sequenz) zum
Phänotyp (Patient)
(c) Darstellung von Datensätzen der Originalrelation in Tabellenform
(d) Auswahlmöglichkeit zwischen verschiedenen Fremdschlüsselbeziehungen innerhalb des integrierten Datenbestandes ausgehend von einem bestimmten Attribut
Das vorgestellte System wird momentan in der Arbeitsgruppe Bioinformatik/Medizinische Informatik der Universität Bielefeld in Zusammenarbeit mit dem Kinderkrankenhaus Reutlingen weiterentwickelt und stellt dort eine zentrale Ressource bei
der Erforschung von Stoffwechselkrankheiten dar.
159
Kapitel 6 Anwendungen des Integrationsdienstes
a
b
d
c
Abbildung 6.6: Screenshots der webbasierten graphischen Nutzerschnittstelle des Genotyp-Phänotyp-Analysesystems aus [147]
6.4 Integrationsdatenbanken für Genwirknetze (iUDB)
In [138, 139] wurde ein Softwaresystem namens iUDB“ vorgestellt, das mit dem Ziel
”
entwickelt wurde, komplexe biologische Systeme zu modellieren und zu analysieren.
Der Einsatz von objektorientierten Konzepten zur Abbildung von Netzwerken biologischer Entitäten und deren Beziehung und Interaktionen stellt ein Schlüsselkonzept
bei diesem Ansatz dar. So wird für den Aufbau dieser biologischen Netzwerke eine Abbildung auf Objektnetzwerke vorgenommen. Diese Abbildung geschieht mit Hilfe von,
in öffentlichen Datenquellen verfügbaren und über JDBC-Datenquellen bzw. über den
BioDataServer importierte, Daten. Dazu wurden Methoden zur relational-objektorientierten Abbildung dieser relationalen Daten in ein objektorientiertes DBMS implementiert. Nach diesem Datenimport werden auf Grundlage von in IDL-Dateien spezifizierten Klassenstrukturen automatisch Objektnetzwerke aufgebaut. Auf diese Weise ist es
weiterhin möglich, nutzerspezifische Netzwerke zu modellieren und diese als verschiedene Projekte zu verwalten. Durch eine, für jedes Projekt automatisch erzeugte und
für Client-Anwendungen bereitgestellte, CORBA-Schnittstelle besteht die Möglichkeit,
160
6.5 Semantische Metadatenbank (SEMEDA)
plattform- und programmiersprachenunabhängig auf die objektorientierten Netzwerke
zuzugreifen. Die Systemkomponenten des iUDB-Systems sind in Abbildung 6.7 dargestellt.
Abbildung 6.7: Systemkomponenten des iUDB-Systems aus [156]
Der anwendungsbezogene Fokus des iUDB-Systems liegt auf der Simulation und
strukturellen Analyse von Pathwaydaten. Insbesondere Stoffwechsel- und Signalwege
innerhalb geschlossener Systeme, wie z. B. einer Zelle, wurden modelliert. Die vom
iUDB-System bereitgestellten Methoden zur Analyse und Simulation von Objektnetzwerken sind teils über die CORBA-API und teils über eine GUI zugänglich. Gerade die
komplexen Möglichkeiten, die etwa der Einsatz von OQL auf objektorientierten DBMS
bietet, unterstützt ein exploratives Arbeiten mit den biologischen Netzwerken. Darüber
hinaus ist eine Kernfunktionalität die diskrete Simulation von Stoffwechselprozessen auf
Grundlage von Regeln, die teilweise automatisch aus den Objektnetzwerken abgeleitet
werden. Eine Regel v besteht dabei aus Eingabeobjekten IN , Ausgabeobjekten OU T ,
Einflüssen IN F und Lokalitätsobjekten LOC: v = (IN, OU T, IN F, LOC). Durch die
Simulation von Regelnetzwerken können so z. B. Vorhersagen über das Verhalten von
Stoffwechselwegen unter bestimmten externen Einflüssen, wie z. B. das Ausschalten von
Genen oder eine Konzentrationserhöhung von externen Metaboliten, gemacht werden.
Zur Veranschaulichung der komplexen Funktionalität der iUDB-GUI ist in Abbildung
6.8 ein Screenshot des Netzwerkdesigners dargestellt. Das iUDB-System wurde in der
Programmiersprache JAVA unter Nutzung des objektorientierten DBMS Versant Ob”
ject Database“ implementiert und ist unter folgender URL verfügbar:
http://tunicata.techfak.uni-bielefeld.de
6.5 Semantische Metadatenbank (SEMEDA)
Die semantische Metadatenbank (SEMEDA) [61, 51] ist ein Softwaresystem zur semantischen Unterstützung einer Datenbankintegration in der Bioinformatik. Insbesondere
161
Kapitel 6 Anwendungen des Integrationsdienstes
Abbildung 6.8: Screenshot des iUDB-Network-Designers aus [156]
bei der Integration von Datenschemata, einer Voraussetzung zur Datenbankintegration, existieren Konflikte, wie sie in Abschnitt 2.3.4 eingeführt wurden. Im Mittelpunkt
von SEMEDA stehen die Überwindung einiger wesentlicher Aspekte von Datenschemakonflikten sowie Aspekte der semantischen Anfrageformulierung. Die Schemata, mit
denen SEMEDA arbeitet, sind die Adapterschemata des BioDataServer. So wurde mit
dem BioDataServer als Datenbankintegrationsdienst ein Softwaresystem konzipiert, das
mittels Ontologien über ein einheitliches Vokabular von Attribut- und Tabellenbezeichenungen die folgenden Probleme bei der Datenbankintegration löst. Dabei ist ein
kontrolliertes Vokabular CV eine Menge von Konzepten c, die vereinfacht ein Tupel
aus einem Term t und dessen natürlichsprachliche Definition d sind: CV = {c} und
c = (t, d). Eine Ontologie wird dabei als ein azyklischer Graph über alle c definiert,
wobei die Kanten zwischen den Konzepten den Typ einer Spezialisierungsbeziehung
( is-a“) haben.
”
Die Auflösung von Homonymen und Synonymen über alle Adapterschemata erfolgt
für Attribute und Tabellen über deren Abbildung auf Konzepte. Es werden also alle
Attribute und Tabellen des Adapterschemas auf Konzepte abgebildet. Werden so mehrere Attribute auf ein Konzept abgebildet, so handelt es sich um Synonyme. Weil jedes
162
6.6 Web-Anwendung zur Analyse von Stoffwechselwegen (phpMetatool)
Konzept eindeutig definiert ist, wird somit auch die Semantik des Schemaelementes
bestimmt. Mit der Nutzung dieses Konzeptes wird es auch möglich, Attribute verschiedener Adapterschemata semantisch als sogenannte cross-references“ aufeinander
”
abzubilden, was eine Voraussetzung einer semantischen Datenschemaintegration ist.
Die Ontologie als Graphstruktur wird zur Anfragegenerierung eingesetzt. Durch die
gebildete Spezialisierungshierarchie wird dem Anwender die Möglichkeit gegeben, ohne die Kenntnis der Adapterschemata und deren Interpretation, ad-hoc Datenanfragen
über, mit dem BioDataServer integrierte, Datenbanken zu stellen. Durch den in SEMEDA integrierten Ontologiebrowser kann ein Anwender interessierende Konzepte, also
Attributsemantiken, auswählen, die wie erläutert auf Adapterschemaattribute abgebildet sind. So werden alle die Attribute ausgewählt, die für die Anfrage integriert werden
müssen. Weiterhin wird ein IUS-Datenschema erzeugt, worüber eine ebenfalls automatisch generierte SQL-Anfrage ausgeführt wird. Auf diese Weise wird ein exploratives
Arbeiten unterstützt und eine semantische SQL-Anfrageerzeugung realisiert.
SEMEDA wurde als Web-Anwendung unter Nutzung der Java-Server-Page-Technologie (JSP) entwickelt und ist unter folgender URL verfügbar:
http://www-bm.ipk-gatersleben.de/semeda
JDBC-Treiber dienen als einheitliche Anfrageschnittstelle zu den einzelnen zu integrierenden Datenquellen, inklusive des BioDataServer. Die Anwendung gliedert sich in den
Ontologiebrowser, in das Administratorwerkzeug und in die Komponente zur semantischen Datenanfrageformulierung. In Abbildung 6.9 ist ein Screenshot des Administratorwerkzeuges zur IUS-Schemagenerierung abgebildet.
6.6 Web-Anwendung zur Analyse von
Stoffwechselwegen (phpMetatool)
Aus Forschungsarbeiten auf dem Gebiet der Rekonstruktion und Analyse von Stoffwechselwegen entstand das Werkzeug METATOOL“ [148, 157]. METATOOL ist eine
”
Software zur Analyse und Vorhersage metabolischer Stoffwechselwege. Es berechnet aus
elementaren chemischen Reaktionsketten zusammenhängende Stoffwechselwege. Diejenigen elementaren Reaktionsketten, welche nicht weiter zerlegt werden können, werden
als Elementarmodi bezeichnet. Aus diesen Elementarmodi können Rückschlüsse auf die
Metabolitflüsse in Stoffwechselwegen und deren Topologie gezogen werden. Dies dient
als analytische Basis für etwaige künstliche Restrukturierungen nur teilweise bekannter
Stoffwechselwege.
Das Werkzeug zur Berechnung dieser Elementarmodi ist in der Programmiersprache
C++ geschrieben. Es benötigt eine flat-file-Eingabedatei, die in Form stöchiometrischer
Gleichungen die biochemischen Reaktionen, die beteiligten Metabolite als Reaktionsausgangsstoffe bzw. als Produkte, die Enzyme als Katalysatoren und die Reaktionsrichtung beschreibt. Die Ausgabe ist ebenfalls ein flat-file. Auf Basis dieser Ein- und
Ausgabeschnittstelle wurde im Rahmen eines Laborpraktikums die Web-Anwendung
phpMetatool“ [158] geschaffen, welche die Eingabedateien halbautomatisch aus den
”
163
Kapitel 6 Anwendungen des Integrationsdienstes
Abbildung 6.9: Screenshot der SEMEDA Web-Oberfläche
Daten einer vorhandenen Datenbank erzeugt, die als Produkt einer Datenbankintegration von Stoffwechsel- und Enzymdatenbanken durch den BioDataServer entstand.
Die entwickelte Web-Anwendung erzeugt aus diesem integrierten Datenbestand Eingabedateien für das METATOOL. Die erzeugten Eingabedateien können bei Bedarf
vor der Verarbeitung editiert werden. Der Zugriff auf einen bestehenden Datenbestand
ermöglicht das Erzeugen von parametrisierten Vorlagen für diese Eingabedateien. Es
können über Kriterien, wie Stoffwechselwegname und Organismus, spezifisch für eine
Fragestellung interessierende Daten vorausgewählt werden. So ist es etwa möglich, aus
allen, zu einer bestimmten Spezies bekannten, biochemischen Reaktionen und Metaboliten des Stoffwechselweges Glykolyse“ automatisch eine entsprechende Eingabedatei
”
zu generieren. Diese dient als Basis für eine manuelle Verfeinerung und Korrekturen. Es
ist vorstellbar, daß diese Unterstützung einen erheblichen zeitlichen Vorteil gegenüber
einer ausschließlich manuellen Datenakquisition darstellt. In der Abbildung 6.10 ist der
eben skizzierte Prozeß schematisch dargestellt.
Die Implementierung erfolgte mittels der Skriptsprache PHP, die für die Entwicklung
leichtgewichtiger Web-Anwendungen weit verbreitet ist. Das so umgesetzte phpMeta”
tool“ ist unter folgender URL verfügbar:
164
6.7 Funktionale Annotationen von Pflanzen-ESTs im CR-EST-Informationssystem
Abbildung 6.10: Schematische Darstellung der Bedienschritte des phpMetatools aus
[158]
http://www-bm.ipk-gatersleben.de/tools/phpMetatool/
6.7 Funktionale Annotationen von Pflanzen-ESTs im
CR-EST-Informationssystem
Zur Verwaltung und Analyse von EST-Sequenzen, d. h. die elektronische Repräsentation der im Laufe der Genexpression in Zellen synthetisierten RNA (vergleiche hierzu
Abschnitt 2.1.2), wurde am Institut für Pflanzengenetik und Kulturpflanzenforschung
(IPK) in Gatersleben das Informationssystem CR-EST“ [49] implementiert, das diese
”
Daten für die am IPK untersuchten Nutzpflanzen verwaltet. Die hier enthaltenen Daten sind zur Unterstützung verschiedenster Analyseverfahren im experimentellen und
Genkontext organisiert.
So existieren Gruppen von Sequenzen, die sogenannten EST-Bibliotheken zugeordnet
werden. Dabei wurden alle ESTs einer Bibliothek im gleichen experimentellen Kontext
gemessen. Dieser kann z. B. das Gewebe einer Pflanze als Lokalitätskontext, ein Entwicklungsstadium als zeitlicher Kontext oder ein Streßkontext (Pilzbefall oder Wassermangel) sein.
Im genetischen Kontext werden die ESTs, die letztlich translatierte Teilsequenzen
eines Gens darstellen, derart untereinander aligniert, so daß alle von einem Gen während der Genexpression translatierten ESTs einen sogenannten Cluster bilden. Diese als
165
Kapitel 6 Anwendungen des Integrationsdienstes
EST-Clustering“ bekannte EST-Analyse wird für alle ESTs der CR-EST-Datenbank
”
durchgeführt und resultiert neben den EST-Gruppen bzw. Clustern in sogenannten
Konsensussequenzen, die als eine künstliche Vereinigung aller sich überlagernden Teilsequenzen eines Gens zu einer Gesamtsequenz interpretiert werden können.
Neben diesen sequenzzentrischen Daten in CR-EST werden Daten zur funktionalen
Bedeutung der Sequenzen in der Datenbank erfaßt. Dazu werden über den BioDataServer öffentliche Datenquellen aus dem Bereich der funktionalen Genetik integriert und
so Proteindaten und weitere spezielle funktionale Genannotationen in die CR-ESTDatenbank importiert. Auf dieser Datenbasis erfolgt dann, unter Nutzung existierender Verfahren zur Sequenzähnlichkeitssuche, die funktionale Klassifikation der ESTSequenzen im Informationssystem CR-EST.
Zur Veranschaulichung der in CR-EST enthaltenen Daten und Funktionalitäten ist im
rechten Teil des Screenshots aus Abbildung 6.11 die funktionale Klassifikation von ausgewählten ESTs in Form eines GeneOntology-Klassifikationsbaumes dargestellt. Diese
Abbildung 6.11: Screenshots aus dem Informationssystem CR-EST
typische Art der, dem Data Mining“ zugrundeliegenden, Methodik des Gruppierens
”
und Klassifizierens, stammt aus dem in Abschnitt 6.2 beschriebenen Ansatz der Data
”
166
6.8 Resümee
Linkage Graphs“ und basiert so wiederum auf den, durch den BioDataServer integrierten, öffentlichen Datenbanken.
Aktuelle, auf diesem Konzept aufbauende Forschungsarbeiten am IPK im Bereich der
Funktionsannotation im besonderen Kontext von Genexpressionsstudien nutzen multidimensionale Data Mining“-Techniken zu in-silico-Expressionsdaten. Diese Expres”
sionsdaten lassen sich z. B. indirekt aus Gruppierungen bzw. Clustern aller zu einem
Gen expremierter RNA-Stränge bzw. deren Repräsentation in Form von ESTs ableiten.
Hier werden auf Grundlage von EST-Sequenzclustern bibliotheksspezifisch3 expremierte
Gene unter Nutzung statistischer Verfahren vorhergesagt. Dazu wurden ebenfalls mittels des BioDataServers öffentliche EST-Clusterdatenbanken, wie z. B. NCBI-UniGene
[159], in ein relationales DBMS importiert und mit den zuvor genannten Genfunktionsannotationen verknüpft. Auf diese Weise können alle Gene vorhergesagt werden,
die während eines bestimmten Entwicklungsstadiums einer Pflanzenspezies eine hohe
Expressionsaktivität zeigen. So wurden in noch unveröffentlichten Analyseergebnissen
Transkriptionsfaktoren und deren Expressionsprofile ermittelt, die bei der Samenentwicklung bei Gerste eine Schlüsselrolle einnehmen.
6.8 Resümee
Mit dem Ziel der Demonstration der praktischen Anwendbarkeit des BioDataServer,
wurden in diesem Kapitel Projekte vorgestellt, die den BDS als Komponente zum homogenen Zugriff und zur Integration molekularbiologischer Daten nutzen. Diese unterscheiden sich nach der Art der Einbettung des BDS und der Verarbeitung der Datenanfrageergebnisse. Es wurden somit Anwendungen vorgestellt, die den BDS
1. als Importwerkzeug zur Materialisierung von integrierten Daten in ein DBMS
verwenden oder
2. in einer Client-Server-Architektur für integrative, explorative Datenfragen nutzen.
Im ersten Fall, der die Mehrzahl der Anwendungsfälle darstellt und der explizit für die
im Kapitel 5 vorgestellte Datenbankintegrationsarchitektur zugrunde gelegt wird, wird
eine sogenannte offline“-Analyse von integrierten Datenbanken vogenommen. Der sel”
tenere Anwendungsfall einer Datenexploration auf virtuell über Sichten integrierte Datenbanken, wobei der BDS-Mediator als eigenständiges Datenbankintegrationssystem
Verwendung findet, wird als online“-Datenzugriff bezeichnet.
”
Neben den zu Beginn dieses Kapitels genannten Demonstrationsanwendungen zum
online-Datenzugriff, nutzt SEMEDA als System zur semantischen Datenbankintegration den BioDataServer zur sichtenbasierten Integration von molekularbiologischen Datenbanken. Die geringe Anwendung für online-Anwendungen begründet sich aus dem
3
ESTs werden in sogenannte EST-Bibliotheken gruppiert, die den experimentellen Kontext der RNAProbenentnahme beschreiben. Das sind z. B. Entwicklungsstadien der Pflanze, das Gewebe, Streßsituation etc.
167
Kapitel 6 Anwendungen des Integrationsdienstes
beschränkten Sprachumfang des SQL-Dialektes des BioDataServer, was die Konsequenz
der allgemein beschränkten Zugriffsmuster molekularbiologischer Datenquellen ist.
Als Beispiel für offline-Nutzung des BDS wurde ein universelles JAVA-Importwerkzeug namens Debbie vorgestellt, was u. a. für das ebenfalls in diesem Kapitel beschriebene Datenbankintegrations- und Analysesystem DBOra verwendet wird. Auf der Basis
von DBOra wurden Konzepte und Methoden entwickelt, um die, am IPK Gatersleben
erhobenen, Sequenz- und Genexpressionsdaten funktional zu charakterisieren. Weitere
vorgestellte offline-Anwendungen des BDS waren das Softwaresystem zur klinischen
Analyse von Genotyp-Phänotyp-Korrelationdas, das iUDB-System zur Analyse von
Genwirknetzen, das phpMetatool als Web-Anwendung zur strukturellen Analyse von
Pathways und das Pflanzeninformationssystem CR-EST als IPK-Resource zur Verwaltung und Analyse von Nutzpflanzen ESTs.
168
Kapitel 7
Zusammenfassung und Ausblick
Der überwiegende Teil des molekularbiologischen Wissens wird teils in öffentlichen,
teils in kommerziellen Datenbanken gepflegt. Die Anwendung von Bioinformatik als
Wissenschaft zur Verarbeitung und Analyse dieser Datenbanken ist ein wesentlicher
Faktor zum Verständnis der Zusammenhänge zwischen den genetischen Erbinformationen, den dynamischen Vorgängen in Organismen bis hin zu verschiedensten Aspekten
phänotypischer Diversität, wie etwa Krankheiten, Streßresistenzen oder Ernteerträgen.
Die vorliegende Arbeit ist mit dem Ziel der Schaffung einer Komponente zur Verbindung von statischem, in Datenbanken gespeichertem Wissen mit Bioinformatikmethoden zur Wissensableitung angefertigt wurden. Die Integration und der homogene
Zugriff auf molekularbiologische Datenbanken ist eine Voraussetzung zur Nutzung ihres gesamten Potentials. Unter diesen Gesichtspunkten bildet die Aussage
Das Ganze ist mehr als die Summe seiner Teile“
”
die zentrale Motivation des entworfenen Konzeptes zur Datenbankintegration in der
Bioinformatik und der darauf beruhenden Implementierung des Datenbankintegrationssystems BioDataServer.
In diesem Kapitel wird eine Zusammenfassung der erarbeiteten Konzepte und Methoden zur Integration molekularbiologischer Datenquellen unter Nutzung beschränkter
Zugriffsmuster gegeben. Anschließend wird ein Ausblick auf einige, in diesem Kontext
interessante, weiterführende Aspekte erörtert, die im Rahmen der vorliegenden Arbeit
nicht behandelt werden konnten.
7.1 Zusammenfassung
In der Informatik, respektive im Forschungsbereich der Informationssysteme und Datenbanken, gehört die Erforschung der Probleme und Herausforderungen der Datenbankintegration zu den bereits durch umfangreiche Forschungsergebnisse etablierten
Gebieten. Dazu existieren im Informatikkontext der vorliegenden Arbeit anerkannte
Methoden zur Lösung verschiedener Probleme, wie z. B. die Datenschemaintegration, die Transaktionsverwaltung, Datenbankintegrationsarchitekturen, Anfragesprachen
oder Optimierungsstrategien für Anfragepläne über verteilte Datenbanken, veröffentlicht.
169
Kapitel 7 Zusammenfassung und Ausblick
Aufgabe war die Adaption bestehender Methoden zur Datenbankintegration auf die
konkreten Gegebenheiten in der Bioinformatik, insbesondere der molekularbiologischen
Datenbanken. Eben diese Gegebenheiten stellen spezielle Anforderungen an eine in
der bioinformatischen Praxis realisierbare Lösung, die über akademisch, theoretische
Lösungsstrategien hinausgehen. Gerade der Zugriff auf die Datenquellen mittels beschränkter Zugriffsmuster als Basis für ein Datenbankintegrationssystem mit umfangreichen Funktionalitäten zur Datenschemaintegration und Anfragefunktionalität sind
zwei konträre Bedingungen, die es zu kombinieren galt. Eben diese Kombination wurde
durch das in dieser Arbeit vorgestelle Datenbankintegrationsmodell RIND und dessen
Umsetzung durch das Datenbankintegrationssystem BioDataServer realisiert.
Dazu wurden im Kapitel 2 Grundlagen elementarer Konzepte der Molekularbiologie insoweit vorgestellt, wie sie zur Einordnung der Arbeit und zum Verständnis der
vorgeschlagenen Strategien notwendig waren. Weiterhin wurden wichtige Begriffe und
Methoden aus der Datenbanktheorie insbesondere der Datenmodellierung, Schnittstellen und Anfragesprachen zusammengefaßt. Der dritte Inhaltsschwerpunkt des Grundlagenkapitels war die Aufarbeitung von Informatikkonzepten zu verteilten Datenbanken.
Im Mittelpunkt stand die klassifizierende Aufarbeitung der verschiedenen Arten von
Multidatenbanksystemen in besonderem Hinblick auf die genutzten Lösungsstrategien.
In diesem Zusammenhang wurde abschließend eine Charakterisierung von Datenbankintegrationskonflikten erarbeitet. Aus diesen Analysen bestehender Methodiken der
Datenbankintegration motiviert sich die Erkenntnis, daß eine hybride Lösungsstrategie
für eine Datenbankintegration in der Bioinformatik notwendig ist, die Komponenten
von Data Warehouses mit Aspekten von Mediatoren kombiniert.
Die Analyse, Nutzung und Adaption bewährter Methoden und Erkenntnisse sollte vor
der Erarbeitung einer Lösung für ein wissenschaftliches Problem stehen. Die Möglichkeit
aus bestehenden Ansätzen zu lernen und daraus für die Zielsetzung der vorliegenden
Arbeit geeignete Lösung abzuleiten, war Kernaufgabe des Kapitels 3. Dazu waren Vorund Nachteile einzelner existierender Ansätze hinsichtlich der zu entwickelnden Datenbankintegrationslösung abzuwägen, um so eine neue, erweiterte Lösung zu finden.
Die Erfassung und Analyse der Eigenschaften molekularbiologischer Datenbanken und
existierender Datenbankintegrationssysteme in der Bioinformatik stellte deshalb den
ersten Schwerpunkt diesen Kapitels dar. Es wurden charakterisierende Besonderheiten
molekularbiologischer Datenbanken und deren Schnittstellen sowie Datenqualitätskriterien untersucht. Dem folgte die Vorstellung ausgewählter, populärer und bezüglich
der verschiedenen Lösungsansätze und Datenbankintegrationsarchitekturen repräsentativer Systeme. So wurden vier Vertreter bioinformatischer Datenbankintegrationssysteme hinsichtlich der zuvor vorgestellten Klassifikationsmerkmale, wie z. B. dem Grad
der Schemaintegration und der Datenmaterialisierung, detailliert analysiert. Weitere
in der Literatur oft referenzierte Systeme wurden kurz beschrieben, um einen groben
Überblick zu bestehenden, nicht ausschließlich der Bioinformatik zuzuordnenden Datenbankintegrationslösungen anzugeben.
Ein Kern der Arbeit bildet das Kapitel 4, in dem das aus dem relationalen Datenmodell abgeleitete Integrationsdatenmodell RIND erarbeitet wurde. Gegenstand
war die Bereitstellung einer theoretischen Grundlage zur Umsetzung der eingangs er-
170
7.1 Zusammenfassung
wähnten Kombination von beschränkten Zugriffsmustern molekularbiologischer Datenquellen mit ausdrucksstarken, integrierenden Datenanfragen. Zunächst wurden die Basiselemente von RIND vorgeschlagen sowie Abbildungsregeln auf das Relationenmodell
vorgestellt. Darauf aufbauend erfolgte die Ableitung von Datenschemata, welche die
Basis zur Schemaintegration sind. Die drei Schemaebenen sind die Exportschemata,
die Adapterschemata und die integrierten Nutzerschemata. Um die so bereitgestellten Datenstrukturen für Datenanfragen nutzen zu können, wurden im dritten Teil des
Kapitels auf dem RIND-Modell definierte Integrationsoperatoren eingeführt. Anschließend wurde beschrieben, wie ausschließlich aus der Kombination des Selektions- und
Projektionsoperators Datenquellenanfragen gebildet werden können. So wurde das aus
Publikationen bekannte Konzept der subgoals derart umgesetzt, daß gerade auch Datenquellen mit beschränkten Zugriffsmustern auf der Ebene der Adapterschemata in
eine Datenbankintegration eingebettet werden können. Weiterhin wurde anhand von
Anfrageplänen demonstriert, wie die drei RIND-Operationen Projektion, Selektion und
Verbund zu ausführbaren Anfragepläne kombiniert werden können, um auf diese Weise Datenanfragen an die integrierten Nutzerschemata umzusetzen. Das Kapitel wurde
mit Ausführungen der Regeln und Algorithmen zur Komposition und Ausführung von
Anfrageplänen sowie der relationalen Auflösung der resultierenden mengenwertigen Anfrageresultate abgeschlossen.
Ein weiteres Kernkapitel ist die Demonstration der Anwendbarkeit der zuvor vorgestellten theoretischen Konzepte im Kapitel 5. Dazu wurde zunächst ein Datenbankintegrationssystem konzipiert und spezifiziert. Eine entsprechende Anforderungsanalyse
wurde durchgeführt. Auf deren Grundlage wurde eine Systemarchitektur vorgestellt,
in der eine Kombination aus Data Warehouse und Mediatorkonzepten vorgeschlagen
wurde. Als Importkomponente wurde der BioDataServer (BDS) als ein Datenbankmediator zur sichtenbasierten Integration von molekularbiologischen Datenquellen entworfen. Bei dem als Open Source“-Projekt implementierten und so öffentlich verfügbaren
”
BDS wurde die meiste Programmierarbeit geleistet, denn eines der erklärten Ziele war
die Bereitstellung einer funktionstüchtigen und anwendbaren Datenbankintegrationslösung. Der BDS wurde in JAVA als Server implementiert, der über ein TCP/IP-basiertes Netzwerkprotokoll einem breiten Spektrum von Anwendungen zugänglich ist.
Auf der Basis einer in diesem Kapitel spezifizierten SQL-Schnittstelle wurden JDBCund ODBC-Treiber implementiert, die eine nahtlose Anbindung von Datenbankanbindungen an den BDS ermöglichen. Einige für die Implementierung des BDS entwickelten
Algorithmen und weitere Implementierungsaspekte wurden im dritten Teil des Kapitels
vorgestellt. Das Kapitel endete mit Ausführungen zur manuellen und automatischen Erstellung von Adaptern, die vom BioDataServer zu integrierende Datenquellen kapseln
und so die zur Ausführung von Anfrageplänen notwendigen subgoals implementieren.
Weil die Anwendbarkeit der in der vorliegenden Arbeit vorgeschlagenen und implementierten Lösung zur Datenbankintegration eine wesentliche Vorgabe war, wurden
im Kapitel 6 konkrete Applikationen beschrieben, die den BDS als Komponente zum
integrativen Zugriff auf molekularbiologische Datenquellen nutzen. Es wurden sieben
Systeme vorgestellt, die den BDS teils für einen Datenimport und teils für explorative Datenanfragen verwenden. Neben Werkzeugen zur Abfrage, Exploration und zum
171
Kapitel 7 Zusammenfassung und Ausblick
Import von integrierten Datenbanken, wie Debbie“, DBOra“ oder SEMEDA“, wur”
”
”
den diverse Bioinformatikfragestellungen in Form von Analysewerkzeugen bearbeitet.
Die Applikationen zur bioinformatischen Datenanalyse beruhen auf individuell entworfenen integrierten Datenschemata und darüber in DBMS importierte Datenbanken.
Ergebnisse dieser Analysen sind funktionale Klassifikationen von EST-Sequenzen, die
Rekonstruktion und Simulation von Stoffwechselwegen bis hin zur Unterstützung medizinischer Diagnosen von Erbkrankheiten. Mit dem BioDataServer wurde somit ein
universell einsetbares Datenbankintegrationssystem umgesetzt, das im Bereich der Bioinformatik Anwendung findet.
7.2 Ausblick
Aktuelle Entwicklungen auf dem Gebiet der Bioinformatik, Informatik und Erfahrungen
bei der Nutzung des BioDataServers zeigen interessante Möglichkeiten zur Erweiterung
und Verbesserung der in dieser Arbeit vorgestellten Konzepte und Methoden zur Datenbankintegration in der Bioinformatik. Diese wurden teilweise in den jeweiligen Kapiteln
und Abschnitten angesprochen und sollen an dieser Stelle zusammengefaßt werden.
Die Existenz einer Vielzahl von Adaptern zur Anbindung einer möglichst umfangreichen Anzahl von molekularbiologischen Datenquellen an den BioDataServer ist eine
wichtige Voraussetzung zur Anwendbarkeit und somit der Akzeptanz. Die verfügbaren
Adapter resultieren aus einem semi-automatischen Ansatz, der in vielen Fällen die manuelle Erstellung von Grammatiken zum Parsen von Dateien notwendig macht. Diese
Grammatiken wurden nur für einige Datenbanken erstellt. Auch ist eine häufige Anpassung der Grammatiken notwendig, da sich die Dateiformate und der Attributumfang in
vielen Fällen ändern. Aus diesem Grund erscheint es naheliegend, bestehende Wrapper
bzw. Adapter anderer Systeme, wie z. B. dem SRS-System, zu nutzen oder aktuelle
Ansätze zur Adaptergenerierung auf ihre Anwendbarkeit für die Erstellung von BDSAdaptern zu untersuchen.
Interessante Möglichkeiten bietet eine Unterstützung von verschiedenen, hierarchisch
strukturierten Datentypen mit entsprechenden Operationen, wie es im Abschnitt 4.2
vorgeschlagen wurde. Gerade das breite Spektrum von molekularbiologischen Daten
macht die Erweiterung der zur Zeit unterstützten Datentypen wie string oder
integer sinnvoll. Da die Konzeption des BDS dies explizit unterstützt, sind z. B.
Datentypen für Sequenzen oder Proteinstrukturen denkbar, für die neben den Standardoperationen auch Ähnlichkeitsvergleiche möglich sind.
Das Gebiet der Anfrageoptimierung wurde in der vorliegenden Arbeit nicht behandelt. Auch hier ergeben sich Möglichkeiten, aktuelle Forschungsergebnisse im Bereich
von verteilten Datenanfragen zur automatischen Optimierung von Anfrageplänen mit
einzubeziehen. So wären hier etwa kosten- oder regelbasierte Modelle denkbar.
Neben der Veröffentlichung des BDS-Quellkodes sind zur Erhöhung der Akzeptanz
die Einbettung in bestehende Bioinformatik-APIs von Bedeutung. So könnten etwa
Funktionen in der BioJava- oder BioPerl-API zum Zugriff auf den BDS implementiert
werden. Auch die Unterstützung weiterer SQL-Sprachkonstrukte oder anderer Daten-
172
7.3 Schlußbemerkung
anfragesprachen, wie z. B. OQL sind Erweiterungsmöglichkeiten der BDS-Implementierung.
7.3 Schlußbemerkung
Die in dieser Arbeit vorgestellten Konzepte und Methoden zur Datenbankintegration in
der Bioinformatik resultieren aus verschiedenen Forschungsprojekten. Dabei wurden im
ersten Teil des DFG-Projekts Modellierung und Animation regulatorischer Genwirk”
netze“ (MARG), das an der Universität Magdeburg durchgeführt wurde, Grundlagen
gelegt. Die Verfeinerung und praktische Umsetzung der Konzepte wurde am Institut
für Pflanzengenetik und Kulturpflanzenforschung (IPK) in Gatersleben erarbeitet. Dabei wurden während eines BMBF-Bioinformatikprojektes im Rahmen der InnoPlantaInitiative angewandte Forschung mit dem Ziel einer Kommerzialisierung betrieben. Abschließende Arbeiten wurden als projektunabhängige Forschung direkt am IPK durchgeführt.
Die entstandenen Lösungen und Konzepte fließen direkt in weitere Forschungsprojekte ein. Dazu gehören Projektteile der BMBF-Initiative Bioinformatics Center Ga”
tersleben-Halle“ (BIC-GH) und ein Teilprojekt des BMBF-Verbundprojektes Cellu”
lar Eukaryotic proteome-Code deciphering Technology“ (CELLECT). Weiterhin flossen
Ergebnisse in die bereits beendete zweite Projektphase des bereits erwähnten DFGProjektes MARG ein.
173
Anhang A
Ausgewählte Schnittstellen und
Datenformate molekularbiologischer
Datenbanken
A.1 EMBL-flat-file Datensatz
ID
AF093062
standard; genomic DNA; INV; 2795 BP.
XX
AC
AF093062;
XX
SV
AF093062.2
XX
....
DE
Leishmania major polyadenylate-binding protein 1 (PAB1) gene, ....
XX
....
FT
CDS
263..1945
FT
/codon_start=1
FT
/db_xref="GOA:O96606"
FT
/db_xref="TrEMBL:O96606"
FT
/note="polyA-binding protein"
FT
/gene="PAB1"
175
Anhang A Ausgewählte Schnittstellen und Datenformate
FT
/product="polyadenylate-binding protein 1"
FT
/protein_id="AAC64372.2"
FT
/translation="MAAAVQEAAAPVAHQPQMDKPIEIASIY....
....
A.2 GenBank-flat-file Datensatz
LOCUS
AF093062
2795 bp
DNA
INV
12-OCT-1999
DEFINITION
Leishmania major polyadenylate-binding protein 1 (PAB1) gene,
complete cds.
ACCESSION
AF093062
VERSION
AF093062.2
GI:6019463
....
CDS
263..1945
/gene="PAB1"
/note="polyA-binding protein"
/codon_start=1
/product="polyadenylate-binding protein 1"
/protein_id="AAC64372.2"
/db_xref="GI:6019464"
/translation="MAAAVQEAAAPVAHQPQMDKPIEIASIY....
176
A.3 GenBank-ASN.1 Datensatz
A.3 GenBank-ASN.1 Datensatz
seq {
id {
genbank {
name "AF093062" ,
accession "AF093062" ,
version 2 } ,
gi 6019463 } ,
....
seq {
id {
genbank {
accession "AAC64372" ,
version 2 } ,
gi 6019464 } ,
....
177
Anhang A Ausgewählte Schnittstellen und Datenformate
A.4 UniProt DTD
<?xml version="1.0" encoding="UTF-8"?>
....

<!ELEMENT uniprot (entry+, copyright)>
<!ATTLIST uniprot
xmlns CDATA #FIXED "http://uniprot.org/uniprot"
xmlns:xsi CDATA #IMPLIED
xsi:schemaLocation CDATA #IMPLIED
>

<!ELEMENT entry (accession+, name+, protein, gene*, organism+, ....>
<!ATTLIST entry
dataset CDATA #REQUIRED
created CDATA #REQUIRED
updated CDATA #REQUIRED
>
<!ELEMENT copyright (#PCDATA)>
<!ELEMENT accession (#PCDATA)>

<!ELEMENT name (#PCDATA)>
<!ATTLIST name
evidence CDATA #IMPLIED
type (common | full | scientific | synonym | abbreviation) #IMPLIED
>
<!--The protein element stores all the information found in the DE ....
<!ELEMENT protein (name+, domain*, component*)>
<!--evidence: This contains all evidences that are connected to ....
<!--ref: This is referring to a possible EC number ....
<!ATTLIST protein
type NMTOKEN #IMPLIED
evidence CDATA #IMPLIED
ref CDATA #IMPLIED
>
....
178
A.5 BioPerl Beispiel zum Zugriff auf die GenBank
A.5 BioPerl Beispiel zum Zugriff auf die GenBank
$gb = new Bio::DB::GenBank();
$seq1 = $gb->get_Seq_by_id(’MUSIGHBA1’);
$seq2 = $gb->get_Seq_by_acc(’AF303112’);
$seqio = $gb->get_Stream_by_id(["J00522","AF303112"]);
A.6 BioPython Beispiel zum Zugriff auf die GenBank
>>>from Bio import GenBank
>>>gi_list = GenBank.search_for("Opuntia AND rpl16")
>>>ncbi_dict = GenBank.NCBIDictionary()
>>>gb_record = ncbi_dict[gi_list[0]]
>>>print gb_seqrecord
A.7 BioJava Beispiel zum Zugriff auf die GenBank
import
import
import
import
import
org.biojava.bio.seq.*;
org.biojava.bio.seq.io.*;
java.io.*;
org.biojava.bio.*;
java.util.*;
public class ReadGB {
public static void main(String[] args) {
BufferedReader br = null;
try {
br = new BufferedReader(new FileReader(args[0]));
}
catch (FileNotFoundException ex) {
ex.printStackTrace();
System.exit(-1);
}
SequenceIterator sequences = SeqIOTools.readGenbank(br);
while(sequences.hasNext()){
try {
Sequence seq = sequences.nextSequence();
179
Anhang A Ausgewählte Schnittstellen und Datenformate
}
catch (BioException ex) {
ex.printStackTrace();
}catch (NoSuchElementException ex) {
ex.printStackTrace();
}
}
}
}
A.8 CORBA/JAVA Beispiel zum Zugriff auf EMBL
package embl.ebi.emblclient.jitka;
import embl.ebi.tools.*;
import java.util.*;
public class TextViewer {
/* generated class from IDL */
DataAccess dac = new DataAccessImpl();
String[] accNos = {"J00522","AF303112"};
/* generated class from IDL */
DataContents data;
for (int i = 0; i < accNos.length; i++) {
try {
data = dac.getDataContents (accNos[i]);
System.out.println ("Accession number: " + accNos[i]);
System.out.println ("\Molecule:" + data.molType);
System.out.println ("tLength: " + data.length());
System.out.println ("Sequence: " + data.nucSeq);
} catch (NonAvailableData e) {
System.err.println ("Error: " + e.getMessage());
} catch (UnknownData e) {
System.err.println ("Error: " + e.getMessage());
}
}
}
180
A.9 SOAP/JAVA Beispiel zum Zugriff auf KEGG
A.9 SOAP/JAVA Beispiel zum Zugriff auf KEGG
import keggapi.*;
class GetGenesByPathway {
public static void main(String[] args) throws Exception {
/* aus der WSDL generiert*/
KEGGLocator locator = new KEGGLocator();
/* aus der WSDL generiert*/
KEGGPortType serv
= locator.getKEGGPort();
String
query
= args[0];
String[] results = serv.get_genes_by_pathway(query);
for (int i = 0; i < results.length; i++) {
System.out.println(results[i]);
}
}
}
181
Anhang B
Ausgewählte Spezifikationen und
Implementierungsbeispiele des BDS
B.1 BDS JAVA-Klassen für integrierte Nutzerschemata
public class Scheme{
/**
* Name des Schemas
*/
private String name;
/**
* Klassen dieses Schemas vom Typ SchemeTable
*/
private Vector Table = new Vector();
}
public class SchemeTable {
/**
* Zugehoeriges Schema
*/
private Scheme scheme;
/**
* Name der Tabelle
*/
private String name;
/**
* Attribute der Klasse vom Typ SchemeAttribute
*/
private Vector attributes = new Vector();
/**
183
Anhang B Ausgewählte Spezifikationen und Implementierungsbeispiele des BDS
* alle Anfrageabhaengigkeiten der Klasse
*/
private AttributeDepends dependings = new AttributeDepends();
}
public class AttributeDepends {
/**
* vom IUS-Attribut attribut anfrageabhaengige
* IUS-Attribute vom Type AttribteDepends
*/
private Vector depend = new Vector();
/**
* IUS-Attribut
*/
private SchemeAttribute attribute;
}
public class SchemeAttribute
{
/**
* Datentypidentifikatoren
*/
public static final int TYPE_INT = -1;
public static final int TYPE_STRING = -2;
public static final int TYPE_DECIMAL = -3;
public static final int TYPE_BOOLEAN = -4;
/**
* Datentyp des IUS-Attributs
*/
private int _type;
/**
* Name des IUS-Attributs
*/
private String _name;
/**
* Verweis auf die Tabelle dieses IUS-Attributs
*/
private SchemeTable table;
184
B.1 BDS JAVA-Klassen für integrierte Nutzerschemata
/**
* Menge von Adapterattributen vom Typ Source
*/
private Vector SourceAttribute;
}
public class Source {
/**
* Name des Adapters
*/
public String Adapter;
/**
* Name der Adaptertabelle
*/
public String AdapterTable;
/**
* Name des Adapterattributs
*/
public String AdapterAttribute;
}
185
Anhang B Ausgewählte Spezifikationen und Implementierungsbeispiele des BDS
B.2 BDS JAVA-Interface für die Adapter
public interface PhysicalAdapter {
/**
* Ausfuehrung subgoal ohne gebundenens Attribut
*/
public void getPureAttribute(SelectQuery query, Vector result)
throws PhysicalAdapterException;
/**
* Ausfuehrung subgoal mit gebundenem Attribut
*/
public void getSelectedAttribute(SelectQuery query,
String CompareValue,
Vector result)
throws PhysicalAdapterException;
/**
* Abfrage des Adapterschemas
/
*
public AdapterScheme getAdapterScheme();
/**
* Abfrage der Adapterversion
*/
public String getVersion();
/**
* Abfrage des Datenquellennamens
*/
public String getName();
/**
* Abfrage des Adapterherstellers
*/
public String getManufacturer();
}
public class SelectQuery {
/**
* Adaptertabelle
/
*
public String Class;
186
B.2 BDS JAVA-Interface für die Adapter
/**
* Adapterattribut
*/
public String Attribute;
/**
* ungebundenes subgoal-Attribut
*/
public String SelectAttribute;
/**
* gebundenes subgoal-Attribut
/
*
public String WhereAttribute;
}
public class AdapterScheme {
/**
* Adaptertabellen
*/
private AdapterClass classes[];
}
public class AdapterClass {
/**
* Adapterattribute
/
*
private AdapterAttribute attributes[];
/**
* Name der Adaptertabelle
/
*
private String name;
}
public class AdapterAttribute {
/**
* Name des Adapterattributes
*/
187
Anhang B Ausgewählte Spezifikationen und Implementierungsbeispiele des BDS
private String name;
/**
* Datentyp
*/
private String type;
/**
* Freitextbeschreibung
*/
private String description;
/**
* Attribut ist indiziert oder nicht indiziert
*/
private boolean isKey;
}
188
B.3 Beispiel eines IUS-Nutzerschemas
B.3 Beispiel eines IUS-Nutzerschemas
scheme demo
class Enzyme {
ec:string<GeneratedKeggAdapter,Enzyme,ec_nr>;
name:string<GeneratedKeggAdapter,Names,name>:ec->ec_nr;
enzymeclass:string<GeneratedKeggAdapter,Classes,eclass>:ec->ec_nr;
reaction:string<GeneratedKeggAdapter,Reactions,reaction>:ec->ec_nr;
product:string<GeneratedKeggAdapter,Productes,product>:ec->ec_nr;
substrate:string<GeneratedKeggAdapter,Substrates,substrate>:ec->ec_nr;
comment:string<GeneratedKeggAdapter,Comment,comment>:ec->ec_nr;
pathway:string<GeneratedKeggAdapter,Pathway,pathway>:ec->ec_nr;
gene:string<GeneratedKeggAdapter,Gene,gene>:ec->ec_nr;
}
class KeggReactionEnzyme {
map:string<GeneratedKeggReactionAdapter,Pathway,map_nr>;
ec:string<GeneratedKeggReactionAdapter,Reaction,ec_nr>:map->map_nr;
mapec:string<GeneratedKeggReactionAdapter,Reaction,mapec>:map->map_nr;
}
class Disease {
mim:string<GeneratedMDDBAdapter,DISEASES,MIM>;
name:string<GeneratedMDDBAdapter,DISEASES,NAME>:mim->MIM;
age_unit:string<GeneratedMDDBAdapter,DISEASES,AGE_UNIT>:mim->MIM;
FREQUENCY:string<GeneratedMDDBAdapter,DISEASES,FREQUENCY>:mim->MIM;
DESCRIPTION:string<GeneratedMDDBAdapter,DISEASES,DESCRIPTION>:mim->MIM;
}
189
Anhang B Ausgewählte Spezifikationen und Implementierungsbeispiele des BDS
B.4 Ausgabe des BDS-Kommunikationsprotokolls zum
KEGG-Adapterschema
class "Enzyme" {
name: "ec_nr" type: "string"
description: "" isKey: "true"
}
class "Names" {
name: "ec_nr" type: "string"
description: " foreign key references
name: "name" type: "string"
description: "" isKey: "false"
}
class "Classes" {
name: "ec_nr" type: "string"
description: " foreign key references
name: "eclass" type: "string"
description: "" isKey: "false"
}
class "Sysnames" {
name: "ec_nr" type: "string"
description: " foreign key references
name: "sysname" type: "string"
description: "" isKey: "false"
}
class "Reactions" {
name: "ec_nr" type: "string"
description: " foreign key references
name: "reaction" type: "string"
description: "" isKey: "false"
}
class "Substrates" {
name: "ec_nr" type: "string"
description: " foreign key references
name: "substrate" type: "string"
description: "" isKey: "false"
}
class "Productes" {
name: "ec_nr" type: "string"
description: " foreign key references
name: "product" type: "string"
description: "" isKey: "false"
}
class "Inhibitors" {
name: "ec_nr" type: "string"
description: " foreign key references
190
Enzyme(ec_nr)" isKey: "true"
Enzyme(ec_nr)" isKey: "true"
Enzyme(ec_nr)" isKey: "true"
Enzyme(ec_nr)" isKey: "true"
Enzyme(ec_nr)" isKey: "true"
Enzyme(ec_nr)" isKey: "true"
Enzyme(ec_nr)" isKey: "true"
B.4 Ausgabe des BDS-Kommunikationsprotokolls zum KEGG-Adapterschema
name: "inhibitor" type: "string"
description: "" isKey: "false"
}
class "Cofactors" {
name: "ec_nr" type: "string"
description: " foreign key references
name: "cofactor" type: "string"
description: "" isKey: "false"
}
class "Comment" {
name: "ec_nr" type: "string"
description: " foreign key references
name: "comment" type: "string"
description: "" isKey: "false"
}
class "Pathway" {
name: "ec_nr" type: "string"
description: " foreign key references
name: "pathway" type: "string"
description: "" isKey: "false"
}
class "Gene" {
name: "ec_nr" type: "string"
description: " foreign key references
name: "gene" type: "string"
description: "" isKey: "false"
name: "genename" type: "string"
description: "" isKey: "false"
}
class "Disease" {
name: "ec_nr" type: "string"
description: " foreign key references
name: "disease" type: "string"
description: "" isKey: "false"
}
Enzyme(ec_nr)" isKey: "true"
Enzyme(ec_nr)" isKey: "true"
Enzyme(ec_nr)" isKey: "true"
Enzyme(ec_nr)" isKey: "true"
Enzyme(ec_nr)" isKey: "true"
191
Anhang B Ausgewählte Spezifikationen und Implementierungsbeispiele des BDS
B.5 Ausgabe des BDS-Kommunikationsprotokolls zum
BRENDA-Adapterschema
class "Enzyme" {
name: "ec_nr" type: "string"
description: ""
isKey: "true"
}
class "Organism" {
name: "ec_nr" type: "string"
description: " foreign key references
isKey: "true"
name: "organismid" type: "string"
description: ""
isKey: "false"
}
class "Organismname" {
name: "organismid" type: "string"
description: " foreign key references
isKey: "true"
name: "organismname" type: "string"
description: ""
isKey: "false"
}
class "Other_names" {
name: "organismid" type: "string"
description: " foreign key references
isKey: "true"
name: "other_name" type: "string"
description: ""
isKey: "false"
}
class "Cas_reg_nrs" {
name: "organismid" type: "string"
description: " foreign key references
isKey: "true"
name: "cas_reg_nr" type: "string"
description: ""
isKey: "false"
}
class "Reactions" {
name: "organismid" type: "string"
description: " foreign key references
isKey: "true"
name: "reaction" type: "string"
description: ""
192
Enzyme(ec_nr)"
Organism(organismid)"
Organism(organismid)"
Organism(organismid)"
Organism(organismid)"
B.5 Ausgabe des BDS-Kommunikationsprotokolls zum BRENDA-Adapterschema
isKey: "false"
}
class "Reaction_types" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "reaction_type" type: "string"
description: ""
isKey: "false"
}
class "Substrates" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "substrate" type: "string"
description: ""
isKey: "false"
}
class "Products" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "product" type: "string"
description: ""
isKey: "false"
}
class "Natural_Substrates" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "natural_substrate" type: "string"
description: ""
isKey: "false"
}
class "Turnover_numbers" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "turnover_number" type: "string"
description: ""
isKey: "false"
}
class "Specific_activities" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
193
Anhang B Ausgewählte Spezifikationen und Implementierungsbeispiele des BDS
name: "specific_activity" type: "string"
description: ""
isKey: "false"
}
class "Km_values" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "km_value" type: "string"
description: ""
isKey: "false"
}
class "Ph_optimums" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "ph_optimum" type: "string"
description: ""
isKey: "false"
}
class "Ph_ranges" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "ph_range" type: "string"
description: ""
isKey: "false"
}
class "Temperatur_optimums" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "temperatur_optimum" type: "string"
description: ""
isKey: "false"
}
class "Temperatur_ranges" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "temperatur_range" type: "string"
description: ""
isKey: "false"
}
class "Cofactors" {
name: "organismid" type: "string"
194
B.5 Ausgabe des BDS-Kommunikationsprotokolls zum BRENDA-Adapterschema
description: " foreign key references
isKey: "true"
name: "cofactor" type: "string"
description: ""
isKey: "false"
}
class "Metal_ions" {
name: "organismid" type: "string"
description: " foreign key references
isKey: "true"
name: "metal_ion" type: "string"
description: ""
isKey: "false"
}
class "Inhibitors" {
name: "organismid" type: "string"
description: " foreign key references
isKey: "true"
name: "inhibitor" type: "string"
description: ""
isKey: "false"
}
class "Tissues" {
name: "organismid" type: "string"
description: " foreign key references
isKey: "true"
name: "tissue" type: "string"
description: ""
isKey: "false"
}
class "Sources" {
name: "organismid" type: "string"
description: " foreign key references
isKey: "true"
name: "source" type: "string"
description: ""
isKey: "false"
}
class "Localizations" {
name: "organismid" type: "string"
description: " foreign key references
isKey: "true"
name: "localization" type: "string"
description: ""
isKey: "false"
}
Organism(organismid)"
Organism(organismid)"
Organism(organismid)"
Organism(organismid)"
Organism(organismid)"
Organism(organismid)"
195
Anhang B Ausgewählte Spezifikationen und Implementierungsbeispiele des BDS
class "Purifications" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "purification" type: "boolean"
description: ""
isKey: "false"
}
class "Crystallizations" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "crystallization" type: "boolean"
description: ""
isKey: "false"
}
class "Molecular_weights" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "molecular_weight" type: "string"
description: ""
isKey: "false"
}
class "Subunits" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "subunit" type: "string"
description: ""
isKey: "false"
}
class "Posttransmods" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "posttransmod" type: "string"
description: ""
isKey: "false"
}
class "Cloneds" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "cloned" type: "boolean"
description: ""
196
B.5 Ausgabe des BDS-Kommunikationsprotokolls zum BRENDA-Adapterschema
isKey: "false"
}
class "Ph_stabilities" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "ph_stability" type: "string"
description: ""
isKey: "false"
}
class "Temperatur_stabilities" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "temperatur_stability" type: "string"
description: ""
isKey: "false"
}
class "Organic_solvent_stabilities" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "organic_solvent_stabilitiy" type: "string"
description: ""
isKey: "false"
}
class "Oxidation_stabilities" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "oxidation_stability" type: "string"
description: ""
isKey: "false"
}
class "General_stabilities" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "general_stability" type: "string"
description: ""
isKey: "false"
}
class "Storage_stabilities" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
197
Anhang B Ausgewählte Spezifikationen und Implementierungsbeispiele des BDS
name: "storage_stability" type: "string"
description: ""
isKey: "false"
}
class "Renaturateds" {
name: "organismid" type: "string"
description: " foreign key references Organism(organismid)"
isKey: "true"
name: "renaturated" type: "boolean"
description: ""
isKey: "false"
}
198
B.6 Parameterdateien zur Generierung des KEGG-Adapters
B.6 Parameterdateien zur Generierung des
KEGG-Adapters
----------------- Datei "keggbeschreibung.txt" ------------------adaptertype: USER_DEFINED_GRAMMA
adaptername: GeneratedKeggAdapter
manufacturer: "Matthias Lange, mail: [email protected] "
version: 1.2
url: http://kegg.genome.ad.jp/dbget-bin/www_bget?enzyme:
urlextension: "+-s"
keysurl: http://kegg.genome.ad.jp/dbget-bin/get_htext?ECtable+D
scheme: KEGG
table Enzyme (ec_nr string primary key)
table Names (ec_nr string foreign key references Enzyme(ec_nr),
name string);
table Classes (ec_nr string foreign key references Enzyme(ec_nr),
eclass string);
table Sysnames (ec_nr string foreign key references Enzyme(ec_nr),
sysname string);
table Reactions (ec_nr string foreign key references Enzyme(ec_nr),
reaction string);
table Substrates (ec_nr string foreign key references Enzyme(ec_nr),
substrate string);
table Productes (ec_nr string foreign key references Enzyme(ec_nr),
product string);
table Inhibitors (ec_nr string foreign key references Enzyme(ec_nr),
inhibitor string);
table Cofactors (ec_nr string foreign key references Enzyme(ec_nr),
cofactor string);
table Comment (ec_nr string foreign key references Enzyme(ec_nr),
comment string);
table Pathway (ec_nr string foreign key references Enzyme(ec_nr),
pathway string);
table Gene (ec_nr string foreign key references Enzyme(ec_nr),
gene string,
genename string);
table Disease (ec_nr string foreign key references Enzyme(ec_nr),
disease string);
datagramma: keggdatagramma.txt
keygramma: keggkeygramma.txt
----------------- Datei "keggdatagramma.txt" ------------------TOKEN : {
<NAME:
<ECLASS:
<SYSNAME:
<REACTION:
"\nNAME"
>|
"\nCLASS"
>|
"\nSYSNAME"
>|
"\n"<HTMLTAG>"REACTION"<ENDTAG>
>|
199
Anhang B Ausgewählte Spezifikationen und Implementierungsbeispiele des BDS
<SUBSTRATE: "\nSUBSTRATE"
>|
<PRODUCT:
"\nPRODUCT"
>|
<INHIBITOR: "\nINHIBITOR"
>|
<COFACTOR:
"\nCOFACTOR"
>|
<COMMENT:
"\nCOMMENT"
>|
<REFERENCE:
"\nREFERENCE"
>|
<PATHWAY:
"\nPATHWAY"
>|
<ORTHOLOG:
"\nORTHOLOG"
>|
<GENE:
"\nGENES"
>|
<DISEASE:
"\nDISEASE"
>|
<HTMLTAG:
("<A HREF=" (<ID>)+ ">") >|
<ENDTAG:
"</A>"
>|
<WSP:
[" ", "\t"]
>|
<NL:
["\n", "\r"]
>|
<IDSPACE:
(<ID> (<ID> | " ")*)
>|
<IDSPACEEQUAL:(<ID> (<ID> | " " | "=")*)
<IDGENE:(<ID> ("+") <ID>)
>|
<ANY:
~[]
>|
>|
/* Hilfstoken */
<#ID: ["0"-"9", "%",":", "+", "-", "(", ")", ",",";", "$", "A"-"Z",
"a"-"z", "_", "?", "/", "\’", ".", "[", "]"]>
}
void parse() :
{Token t = null; StringBuffer sb = new StringBuffer();}
{
(<ANY> | <IDSPACE> | <IDSPACEEQUAL> | <HTMLTAG> | <ENDTAG> |
<WSP> | <NL>)*
(<NAME> ((<WSP>)+
t=<IDSPACE> {data.name.addElement(t.image);} (<NL>)?)+)?
(<ECLASS> ((<WSP>)+
t=<IDSPACE> {data.eclass.addElement(t.image);} (<NL>)? )+)?
(<SYSNAME> ((<WSP>)+
t=<IDSPACE> {data.sysname.addElement(t.image);} (<NL>)? )+)?
(<REACTION> ((<WSP>)+
((t=<IDSPACEEQUAL> {if(sb.length()!=0) {
data.reaction.addElement(sb.toString());
}
sb = new StringBuffer(t.image);}) |
(t=<IDSPACE> {sb.append(" ");sb.append(t.image);}))
(<NL>)?)+ {data.reaction.addElement(sb.toString());})?
(<SUBSTRATE> ((<WSP>)+ (<HTMLTAG>)?
t=<IDSPACE> {data.substrate.addElement(t.image);}
(<ENDTAG>)? (<NL>)? )+)?
200
B.6 Parameterdateien zur Generierung des KEGG-Adapters
(<PRODUCT> ((<WSP>)+ (<HTMLTAG>)?
t=<IDSPACE> {data.product.addElement(t.image);}
(<ENDTAG>)? (<NL>)? )+)?
(<INHIBITOR> ((<WSP>)+ (<HTMLTAG>)?
t=<IDSPACE> {data.inhibitor.addElement(t.image);}
(<ENDTAG>)? (<NL>)? )+)?
(<COFACTOR> ((<WSP>)+ (<HTMLTAG>)?
t=<IDSPACE> {data.cofactor.addElement(t.image);}
(<ENDTAG>)? (<NL>)? )+)?
{sb = new StringBuffer();}
(<COMMENT> ((<WSP>)+ ( (t=<IDSPACE> {sb.append(t.image);}) |
(<HTMLTAG> t=<IDSPACE> {sb.append(t.image+" ");} <ENDTAG>)
(<WSP>)*)+ (<NL>)? )+)?
{data.comment.addElement(sb.toString());}
(<REFERENCE> ((<WSP>)+
t=<IDSPACE> (<HTMLTAG><IDSPACE><ENDTAG><IDSPACE>)?(<NL>)?)+)?
( <PATHWAY> ((<WSP>)+ <IDSPACE> (<HTMLTAG>)?
t=<IDSPACE> {data.pathway.addElement
(t.image.substring(t.image.indexOf(’P’)+1,t.image.length()));}
(<ENDTAG>)? (<WSP>)+ <IDSPACE> (<NL>)? )+)?
(<ORTHOLOG> ((<WSP>)+ <IDSPACE> (<HTMLTAG>)?
t=<IDSPACE> (<ENDTAG>)? (<WSP>)+ <IDSPACE> (<NL>)? )+)?
(<GENE> ( (<WSP>)+ (<IDSPACE>)? (t = <HTMLTAG>
{data.gene.addElement(t.image.substring
(t.image.indexOf("?")+1,t.image.indexOf(">")));}
<IDSPACE> <ENDTAG> (<WSP>)* (<IDSPACE>)?)+ (<NL>)? )+)?
(<DISEASE> ( (<WSP>)+ (<IDSPACE>)? (t = <HTMLTAG> {
data.disease.addElement(t.image.substring
(t.image.indexOf(’+’)+1,t.image.indexOf(">")));}
<IDSPACE> <ENDTAG> (<WSP>)* (<IDSPACE>
(<NL> (<WSP>)* <IDSPACE>)*)? )+ (<NL>)? )+)?
{return;}
}
----------------- Datei "keggkeygramma.txt" ------------------TOKEN : {
<ANY: ~[] >|
<EC_NR: ((<DIGIT>)+ <DOT> (<DIGIT>)+ <DOT> (<DIGIT>)+ <DOT> (<DIGIT>)+)>|
<ENZYMEPREFIX: "<A HREF=/dbget-bin/www_bget?ligand+">|
<#DOT: ["."]>|
<#DIGIT: ["0"-"9"] >
}
201
Anhang B Ausgewählte Spezifikationen und Implementierungsbeispiele des BDS
void parse(Vector ret) :
{String s = null; Token t=null; int i = 0;}
{
((<ENZYMEPREFIX> t = <EC_NR> {ret.addElement(t.image);} )
| <EC_NR> | <ANY> )* <EOF>
}
202
Literaturverzeichnis
[1] Kitano, H.: Systems Biology: A Brief Overview. Science, 295:1662–1664, 2002.
[2] Stephens, S. M., J. Y. Chen, M. G. Davidson, S. Thomas und B. M. Trute: Oracle Database 10g: a platform for BLAST search and Regular Expression
pattern matching in life sciences. Nucleid Acids Ressearch, 33(suppl 1):D675–679,
2005.
[3] Valencia, Alfonso: Search and retrieve: Large-scale data generation is becoming increasingly important in biological research. But how good are the tools to
make sense of the data? EMBO Reports, 3(5):396–400, 2002.
[4] Stevens, R., C. Goble, P. Baker und A. Brass: A classification of tasks in
bioinformatics. Bioinformatics, 17(2):180–188, 2001.
[5] Stein, L.: Creating a bioinformatics nation. Nature, 417:119–120, 2002.
[6] Berg, P. und M. Singer: Die Sprache der Gene: Grundlagen der Molekulargenetik. Heidelberg: Spektrum Akademischer Verlag, 1993.
[7] Brown, T. A.: Moderne Genetik. Heidelberg: Spektrum Akademischer Verlag,
1999.
[8] Knippers, R.: Molekulare Genetik. Stuttgart, New York: Georg Thieme Verlag,
7. Auflage, 1997.
[9] Löffler, G. und P. E. Petrides: Biochemie und Pathobiochemie. Berlin et
al.: Springer, 6 Auflage, 1998. Gebundene Ausgabe.
[10] Watson, J. D. und F. H. C. Crick: Genetical Implications of the Structure
of Deoxyribonucleid Acid. Nature, 171(4361):964–967, 1953.
[11] Adams, M. D., S. E. Celniker, R. A. Holt, C. A. Evans, J. D. Gocayne,
P. G. Amanatides, S. E. Scherer, P. W. Li, R. A. Hoskins, R. F. Galle,
R. A. George, S. E. Lewis, S. Richards, M. Ashburner, S. N. Henderson, G. G. Sutton, J. R. Wortman, M. D. Yandell, Q. Zhang, L. X.
Chen, R. C. Brandon, Y.-H. C. Rogers, R. G. Blazej, M. Champe, B. D.
Pfeiffer, K. H. Wan, C. Doyle, E. G. Baxter, G. Helt, C. R. Nelson,
George L. Gabor M., J. F. Abril, A. Agbayani, H.-J. An, C. AndrewsPfannkoch, D. Baldwin, R. M. Ballew, A. Basu, J. Baxendale, L. Bayraktaroglu, E. M. Beasley, K. Y. Beeson, P. V. Benos, B. P. Berman,
203
Literaturverzeichnis
D. Bhandari, S. Bolshakov, D. Borkova, M. R. Botchan, J. Bouck,
P. Brokstein, P. Brottier, K. C. Burtis, D. A. Busam, H. Butler,
E. Cadieu, A. Center, I. Chandra, J. M. Cherry, S. Cawley, C. Dahlke, L. B. Davenport, P. Davies, B. de Pablos, A. Delcher, Z. Deng,
A. D. Mays, I. Dew, S. M. Dietz, K. Dodson, L. E. Doup, M. Downes,
S. Dugan-Rocha, B. C. Dunkov, P. Dunn, K. J. Durbin, C. C. Evangelista, C. Ferraz, S. Ferriera, W. Fleischmann, C. Fosler, A. E. Gabrielian, N. S. Garg, W. M. Gelbart, K. Glasser, A. Glodek, F. Gong,
J. H. Gorrell, Z. Gu, P. Guan, M. Harris, N. L. Harris, D. Harvey,
T. J. Heiman, J. R. Hernandez, J. Houck, D. Hostin, K. A. Houston,
T. J. Howland, M.-H. Wei, C. Ibegwam, M. Jalali, F. Kalush, G. H.
Karpen, Z. Ke, J. A. Kennison, K. A. Ketchum, B. E. Kimmel, C. D.
Kodira, C. Kraft, S. Kravitz, D. Kulp, Z. Lai, P. Lasko, Y. Lei, A. A.
Levitsky, J. Li, Z. Li, Y. Liang, X. Lin, X. Liu, B. Mattei, T. C. McIntosh, M. P. McLeod, D. McPherson, G. Merkulov, N. V. Milshina,
C. Mobarry, J. Morris, A. Moshrefi, S. M. Mount, M. Moy, B. Murphy, L. Murphy, D. M. Muzny, D. L. Nelson, D. R. Nelson, K. A.
Nelson, K. Nixon, D. R. Nusskern, J. M. Pacleb, M. Palazzolo, Gjange S. Pittman, S. Pan, J. Pollard, V. Puri, M. G. Reese, K. Reinert,
K. Remington, R. D. C. Saunders, F. Scheeler, H. Shen, B. C. Shue,
I. Sid-Kiamos, M. Simpson, M. P. Skupski, T. Smith, E. Spier, A. C.
Spradling, M. Stapleton, R. Strong, E. Sun, R. Svirskas, C. Tector,
R. Turner, E. Venter, A. H. Wang, X. Wang, Z.-Y. Wang, D. A. Wassarman, G. M. Weinstock, J. Weissenbach, S. M. Williams, T. Woodage, K. C. Worley, D. Wu, S. Yang, Q. A. Yao, J. Ye, R.-F. Yeh, J. S.
Zaveri, M. Zhan, G. Zhang, Q. Zhao, L. Zheng, X. H. Zheng, F. N.
Zhong, W. Zhong, X. Zhou, S. Zhu, X. Zhu, H. O. Smith, R. A. Gibbs,
E. W. Myers, G. M. Rubin und J. C. Venter: The Genome Sequence of
Drosophila melanogaster. Science, 287(5461):2185–2195, 2000.
[12] Pennisi, E.: A Low Number Wins the GeneSweep Pool. Science, 300:1484, 2003.
[13] Westbrook, J., Z. Feng, S. Jain, T. N. Bhat, N. Thanki, V. Ravichandran, G. L. Gilliland, W. Bluhm, H. Weissig, D. S. Greer, P. E.
Bourne und H. M. Berman: The Protein Data Bank: unifying the archive.
Nucleic Acids Research, 30(1):245–248, 2002.
[14] Kanehisa, M., S. Goto, S. Kawashima und A. Nakaya:
The
KEGG database at GenomeNet. Nucleic Acids Research, 30(1):42–46, 2002.
http://www.genome.ad.jp/kegg/.
[15] Elmasri, N. und S. B. Navathe: Fundamentals of database systems. Reading,
Mass. et al.: Addison-Wesley, 3rd international edition Auflage, 2000.
[16] Atzeni, P., S. Ceri, S. Paraboschi und R. Torlone: Database Systems
concepts, languages and architectures. London: McGraw-Hill, 1999.
204
Literaturverzeichnis
[17] Codd, E. F.: Relational Database: A Practical Foundation for Productivity.
Communications of the ACM, 25(2):109–117, Februar 1982.
[18] Habermann, H.-J. und F. Leymann: Repository — Eine Einführung. R. Oldenbourg Verlag, München, 1993.
[19] Peckham, J. und F. Maryanski: Semantic Data Models. ACM Computing
Surveys, 20(3):153–189, September 1988.
[20] Oestereich, B.: Objektorientierte Softwareentwicklung - Analyse und Design
mit der Unified Modeling Language (4. aktualisierte Auflage). München et al.:
Oldenbourg, 1998.
[21] Höding, M.: Methoden und Werkzeuge zur systematischen Integration von Dateien in Föderierte Datenbanksysteme. Shaker Verlag, Aachen, 2000.
[22] World Wide Web Consortium (W3C): XML Query Language (XQL).
http://www.w3.org/TandS/QL/QL98/pp/xql.html.
[23] Deutsch, A., M. Fernandez, D. Florescu, A. Levy und D. Suciu: A Query Language for XML. http://www8.org/w8-papers/1c-xml/query/query.html.
[24] International Organization for Standardization (ISO): Database Language SQL. Document ISO/IEC 9075:1992, 1992.
[25] International Organization for Standardization (ISO): Database Language SQL. Document ISO/IEC 9075:1999, 1999.
[26] Cattell, R.: The Object Database Standard: ODMG-2.0. San Fransisco: Morgan Kaufmann, 1997.
[27] Codd, E. F.: A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, 13(6):377–387, Juni 1970.
[28] SOAP 1.2.
http://www.w3.org/TR/2002/CR-soap12-part1-20021219
http://www.w3.org/TR/2002/CR-soap12-part2-20021219.
&
[29] Brockschmidt, K.: Inside OLE, 2nd edition. Redmond, Wash.: Microsoft
Press, 1995.
[30] Siegel, J.: CORBA Fundamentals and Programming. New York: Wiley, 1996.
[31] Siple, M. D.: The complete guide to Java database programming with JDBC.
McGraw-Hill, 1998.
[32] Geiger, K.: Inside ODBC : [Der Entwicklerleitfaden zum Industriestandard
fuer Datenbank-Schnittstellen]. Unterschleissheim : Microsoft Press, 1995.
205
Literaturverzeichnis
[33] Bell, D. und J. Grimson: Distributed database systems. Wokingham et al.:
Addison-Wesley, 1992.
[34] Conrad, S.: Föderierte Datenbanksysteme: Konzepte der Datenintegration.
Springer-Verlag, Berlin/Heidelberg, 1997.
[35] Özsu, M. T. und P. Valduriez: Principles of Distributed Database Systems.
Prentice Hall, 1999.
[36] Wiederhold, G.: Mediators in the Architecture of Future Information Systems.
IEEE Computer, 25(3):38–49, März 1992.
[37] Höding, M., C. Türker, S. Janssen, K.-U. Sattler, S. Conrad, G. Saake und I. Schmitt: Föderierte Datenbanksysteme — Grundlagen und Ziele des
Projektes SIGMAF DB . Preprint 12, Fakultät für Informatik, Universität Magdeburg, 1995.
[38] Sheth, A. P. und J. A. Larson: Federated Database Systems for Managing
Distributed, Heterogeneous, and Autonomous Databases. ACM Computing Surveys, 22(3):183–236, September 1990.
[39] Wiederhold, G.: Modeling and System Maintenance. In: Papazoglou, M.
(Herausgeber): OOER’95: Object-Oriented and Entity-Relationship Modeling,
Proc. of the 14th Int. Conf., Gold Coast, Australia, December 1995, Band 1021
der Reihe Lecture Notes in Computer Science, Seiten 1–20, Berlin, 1995. SpringerVerlag.
[40] Galperin, M. Y.: The Molecular Biology Database Collection: 2005 update.
Nucleic Acids Research, 33(1):D5–D24, 2005.
[41] Halevy, A. Y.: Answering Queries using Views: A Survey. The VLDB Journal,
10(4):270–294, 2001.
[42] Inmon, W. H.: Building the Data Warehouse,3rd Edition. John Wiley & Sons,
Inc., New York, NY, USA, 2002.
[43] Karp, P. D.: A Strategy for Database Interoperation. Journal of Computational
Biology, 2(4):573–586, 1995.
[44] Schinzer, H., C. Bange und H. Mertens: Data Warehouse und Data Mining.
Verlag Franz Vahlen, 1999. München.
[45] Fujibuchi, W., S. Goto, H. Migimatsu, I. Uchiyama, A. Ogiwara,
Y. Akiyama und M. Kanehisa: DBGET/LinkDB: an Integrated Database
Retrieval System. In: 3rd Pacific Symposium on Biocomputing, Seiten 683–694,
1997.
206
Literaturverzeichnis
[46] Boeckmann, B., A. Bairoch, R. Apweiler, M.-C. Blatter, A. Estreicher, E. Gasteiger, M. J. Martin, K. Michoud, C. O’Donovan, I. Phan,
S. Pilbout und M. Schneider: The SWISS-PROT protein knowledgebase and
its supplement TrEMBL in 2003. Nucleic Acids Research, 31(1):365–370, 2003.
[47] Stajich, J. E., D. Block, K. Boulez, S. E. Brenner, S. A. Chervitz,
C. Dagdigian, G. Fuellen, J. G. R. Gilbert, I. Korf, H. Lapp, H. Lehväslaiho, C. Matsalla, C. J. Mungall, B. I. Osborne, M. R. Pocock,
P. Schattner, M. Senger, L. D. Stein, E. Stupka, M. D. Wilkinson und
E. Birney: The Bioperl Toolkit: Perl Modules for the Life Sciences. Genome
Research, 12(10):1611–1618, 2002.
[48] Hermjakob, H., W. Fleischmann und R. Apweiler: Swissknife – ’lazy
parsing’ of SWISS-PROT entries. Bioinformatics, 15(9):771–772, 1999.
[49] Künne, C., M. Lange, T. Funke, H. Miehe, I. Grosse und U. Scholz:
CR–EST: a resource for crop ESTs. Nucleic Acids Research, 33(suppl 1):D619–
621, 2005.
[50] Kim, W. und J. Seo: Classifying Schematic and Data Heterogeneity in Multidatabase Systems. IEEE Computer, 24(12):12–18, 1991.
[51] Köhler, J.: SEMEDA (Semantic Meta-Database): Ontology Based Semantic
Integration of Biological Databases. Dissertation, Universität Bielefeld, Technische
Fakultät, 2003. http://bieson.ub.uni-bielefeld.de/volltexte/2003/349/.
[52] Batini, C., M. Lenzerini und S. B. Navathe: A Comparative Analysis
of Methodologies for Database Schema Integration. ACM Computing Surveys,
18(4):323–364, Dezember 1986.
[53] Stoesser, G., W. Baker, A. van den Broek, E. Camon, M. GarciaPastor, C. Kanz, T. Kulikova, R. Leinonen, Q. Lin, V. Lombard, R. Lopez, T. Redaschi, P. Stoehr, M. A. Tuli, K. Tzouvara und R. Vaughan:
The EMBL Nucleotide Sequence Database. Nucleic Acids Research, 30(1):21–26,
2002.
[54] Benson, D. A., I. Karsch-Mizrachi, D. J. Lipman, J. Ostell und D. L.
Wheeler: GenBank. Nucleic Acids Research, 33(suppl 1):D34–38, 2005.
[55] Tateno, Y., N. Saitou, K. Okubo, H. Sugawara und T. Gojobori: DDBJ in collaboration with mass-sequencing teams on annotation. Nucleic Acids
Research, 33(suppl 1):D25–28, 2005.
[56] Discala, C., X. Benigni, E. Barillot und G. Vaysseix: DBcat: a catalog
of 500 biological databases. Nucleic Acids Research, 28(1):8–9, 2000.
207
Literaturverzeichnis
[57] Bry, F. und P. Kröger: A Computational Biology Database Digest: Data, Data
Analysis, and Data Management. Distributed and Parallel Databases, 13(1):7–42,
2003.
[58] Scholz, U.: FRIDAQ – Ein Framework zur Integration molekularbiologischer
Datenbestände. Dissertation, Otto-von-Guericke-Universität Magdeburg, Fakultät für Informatik, Institut für Technische und Betriebliche Informationssysteme,
2002.
[59] Center, Kyoto University Bioinformatics: Growth of the Sequence and
3D Structure Databases. http://www.genome.ad.jp/dbget/db growth.html.
[60] Stevens, R., P. Baker, S. Bechhofer, G. Ng, A. Jacoby, N. W. Paton, C. A. Goble und A. Brass: TAMBIS: Transparent Access to Multible
Bioinformatics Information Sources. Bioinformatics, 16(4):184–185, 2000.
[61] Köhler, J., S. Philippi und M. Lange: SEMEDA: ontology based semantic
integration of biological databases. Bioinformatics, 19(18):2420–2427, 2003.
[62] Ashburner, M., C. A. Ball, J. A. Blake, D. Botstein, H. Butler,
J. M. Cherry, A. P. Davis, K. Dolinski, S. S. Dwight, J. T. Eppig,
M. A. Harris, D. P. Hill, L. Issel-Tarver, A. Kasarskis, S. Lewis, J. C.
Matese, J. E. Richardson, M. Ringwald, Rubin G. M. und G. Sherlock:
Gene Ontology: tool for the unification of biology. Nature Genetics, 25:25–29,
2000.
[63] National
Library
of
Medicine:
http://www.nlm.nih.gov/mesh/.
[64] World
Wide
Web
Consortium
http://www.w3.org/2001/sw/.
Medical
(W3C):
Subject
Headings.
Semantic
Web.
[65] World Wide Web Consortium (W3C): OWL Web Ontology Language Overview - W3C Recommendation 10 February 2004. http://www.w3.org/TR/owlfeatures/.
[66] Cognitive Science Laboratory at Princeton University: WordNet – a
lexical database for the english language. http://www.cogsci.princeton.edu/ wn/.
[67] Roberts, R. J., M. Belfort, T. Bestor, A. S. Bhagwat, T.A. Bickle,
J. Bitinaite, R. M. Blumenthal, S. K. Degtyarev, D. T. F. Dryden,
K. Dybvig, K. Firman, E. S. Gromova, R. I. Gumport, S. E. Halford,
S. Hattman, J. Heitman, D. P. Hornby, A. Janulaitis, A. Jeltsch,
J. Josephsen, A. Kiss, T. R. Klaenhammer, I. Kobayashi, H. Kong,
D. H. Kruger, S. Lacks, M. G. Marinus, M. Miyahara, R. D. Morgan,
N. E. Murray, V. Nagaraja, A. Piekarowicz, A. Pingoud, E. Raleigh,
D. N. Rao, N. Reich, V. E. Repin, E. U. Selker, P.-C. Shaw, D. C.
208
Literaturverzeichnis
Stein, B. L. Stoddard, W. Szybalski, T. A. Trautner, J. L. Van Etten, J. M. B. Vitor, G. G. Wilson und S.-Y. Xu: A nomenclature for
restriction enzymes, DNA methyltransferases, homing endonucleases and their
genes . Nucleic Acids Research, 31(7):1813–1820, 2003.
[68] Nomenclature Committee of the International Union of Biochemistry and Molecular Biology (NC-IUBMB): MRecommendations of the
Nomenclature Committee of the International Union of Biochemistry and Molecular Biology on the Nomenclature and Classification of Enzyme-Catalysed Reactions. http://www.chem.qmul.ac.uk/iubmb/enzyme/.
[69] Bairoch, A., R. Apweiler, C. H. Wu, W. C. Barker, B. Boeckmann,
S. Ferro, E. Gasteiger, H. Huang, R. Lopez, M. Magrane, M. J. Martin, D. A. Natale, C. O’Donovan, N. Redaschi und L. L. Yeh: The Universal Protein Resource (UniProt). Nucleic Acids Research, 33(suppl 1):D154–
159, 2005.
[70] Hamosh, A., A. F. Scott, J. Amberger, C. Bocchini, D. Valle und V. A.
McKusick: Online Mendelian Inheritance in Man (OMIM), a knowledgebase of
human genes and genetic disorders. Nucleic Acids Research, 30(1):52–55, 2002.
[71] National Center for Health Statistics: International Classification of Diseases, Tenth Revision, Clinical Modification (ICD-10-CM).
http://www.cdc.gov/nchs/about/otheract/icd9/icd10cm.htm.
[72] Chemical Abstract Service: CAS Registry Numbers. http://www.cas.org/.
[73] Daylight
Chemical
http://www.daylight.com.
Information
Systems,
Inc.:
SMILES.
[74] Kanz, C., P. Aldebert, N. Althorpe, W. Baker, A. Baldwin, K. Bates, P. Browne, A. van den Broek, M. Castro, G. Cochrane, K. Duggan, R. Eberhardt, N. Faruque, J. Gamble, F. G. Diez, N. Harte,
T. Kulikova, Q. Lin, V. Lombard, R. Lopez, R. Mancuso, M. McHale, F. Nardone, V. Silventoinen, S. Sobhany, P. Stoehr, M. A. Tuli,
K. Tzouvara, R. Vaughan, D. Wu, W. Zhu und R. Apweiler: The EMBL Nucleotide Sequence Database. Nucleic Acids Research, 33(suppl 1):D29–33,
2005.
[75] Achard, F., G. Vaysseix und E. Barillot: XML, bioinformatics and data
integration. Bioinformatics, 17(2):115–125, 2001.
[76] Riikonen, P., J. Boberg, T. Salakoski und M. Vihinen: BioWAP, mobile
Internet service for bioinformatics. Bioinformatics, 17(9):855–856, 2001.
[77] Pearson, W. und D. Lipman: Improved tools for biological sequence comparison. Proceedings of the National Academie of Science, USA, 85:2444–2448, 1988.
209
Literaturverzeichnis
[78] Fenyö, D: The biopolymer markup language. Bioinformatics, 15(4):339–340,
1999. http://www.proteometrics.com/BIOML/.
[79] Murray-Rust, P. und H.S. Rzepa: Chemical markup, XML, and the Worldwide Web. 1. Basic principles. Journal of Chemical Information and Computer
Sciences, 39(6):928–946, 1999. http://www.xml-cml.org.
[80] Hucka, M., A. Finney, H. M. Sauro, H. Bolouri, J. C. Doyle und H. Kitano: The systems biology markup language (SBML): a medium for representation and exchange of biochemical network models. Bioinformatics, 19(4):524–531,
2003. http://www.sbw-sbml.org/sbml/docs/.
[81] Gilmour, R.: Taxonomic markup language: applying XML to systematic data.
Bioinformatics, 16(4):406–407, 2000. http://www.albany.edu/∼gilmr/pubxml/.
[82] Lichun, W., J.-J. Riethoven und A. Robinson: XEMBL: distributing EMBL data in XML format. Bioinformatics, 18(8):1147–1148, 2002.
[83] Ashish, N. und C. A. Knoblock: Semi-Automatic Wrapper Generation for
Internet Information Sources. In: Proceedings of the Second IFCIS International
Conference on Cooperative Information Systems, Seiten 160–169. Publisher IEEE
Computer Society, 1997.
[84] Lacroix, Z.: Biological Data Integration: Wrapping Data and Tools. IEEE Transactions on Information Technology in Biomedicine, 6(2):123–128, 2002.
[85] World
Wide
Web
Consortium
http://www.w3.org/XML/Schema.
(W3C):
XML
Schema.
[86] Helgesen, C. und N. Redaschi: EMBL Nucleotide Sequence Database Object Model. Technischer Bericht, The European Bioinformatics Institute, 1998.
http://corba.ebi.ac.uk/models/emblom doc.html.
[87] BioJava Project Team: The BioJava Project. http://www.biojava.org.
[88] BioPython
Project
http://www.biopython.org.
Team:
The
BioPython
Project.
[89] Altschul, S. F., T. L. Madden, A. A. Schaffer, J. Zhang, Z. Zhang,
W. Miller und D. J. Lipman: Gapped BLAST and PSI-BLAST: a new generation of protein database search programs. Nucleic Acids Research, 25(17):3389–
3402, 1997.
[90] Coupaye, T.: Wrapping SRS with CORBA: from textual data to distributed
objects. Bioinformatics, 15(4):333–338, 1999.
[91] Parsons, J. D. und Rodriguez-Tomé: JESAM: CORBA software components to create and publish EST alignments and clusters. Bioinformatics,
16(4):313–325, 2000.
210
Literaturverzeichnis
[92] Campagne, F.: Clustalnet: the joining of Clustal and CORBA. Bioinformatics,
16(7):606–612, 2000.
[93] Kemp, G. J. L., C. J. Robertson und P. M. D. Gray: Efficient access to
biological databases using CORBA. CCP11 Newsletter, 3.1(7), 1999.
[94] Casstevens, T. M. und E. S. Buckler: GDPC: connecting researchers with
multiple integrated data sources. Bioinformatics, Seite bth277, 2004.
[95] Kawashima, S., T. Katayama, S. Sato und M. Kanehisa: KEGG API: A
Web Service Using SOAP/WSDL to Access the KEGG System. Genome Informatics, 14:673–674, 2003.
[96] Pillai, S., V. Silventoinen, K. Kallio, M. Senger, S. Sobhany, J. Tate,
S. Velankar, A. Golovin, K. Henrick, P. Rice, P. Stoehr und R. Lopez:
SOAP-based services provided by the European Bioinformatics Institute. Nucleid
Acids Ressearch, 33(suppl 2):W25–28, 2005.
[97] Florescu, D., A. Levy, I. Manolescu und D. Suciu: Query Optimization in the Presence of Limited Access Patterns. In: Delis, A., C. Faloutsos
und S. Ghandeharizadeh (Herausgeber): SIGMOD 1999, Proceedings ACM
SIGMOD International Conference on Management of Data, June 1-3, 1999,
Philadelphia, Pennsylvania, USA, Seiten 311–322. ACM Press, 1999.
[98] Johnson, S. C.: Yacc: Yet another compiler compiler. Technical Report CSTR
32, AT&T, 1978.
[99] java.net: JavaCC: the Java Compiler Compiler. https://javacc.dev.java.net.
[100] Stephanik, A.: Reengineering von Datenbankadaptern im BioBench-Projekt.
Diplomarbeit, Otto-von-Guericke-Universität Magdeburg, Fakultät für Informatik, Institut für Technische und Betriebliche Informationssysteme, May 1999.
[101] Ramu, C.: SIR: a simple indexing and retrieval system for biological flat file
databases. Bioinformatics, 17(8):756–758, 2001.
[102] Pocock, M. R., T. Hubbard und E. Birney: SPEM: a parser for EMBL
style flat file database entries. Bioinformatics, 14(9):823–824, 1998.
[103] Ramu, C., C. Gemünd und T. J. Gibson: Object-oriented parsing of biological
databases with Python. Bioinformatics, 16(7):628–638, 2000.
[104] Scannapieco, M., P. Missier und C. Batini: Data Quality at a Glance.
Datenbank-Spektrum, 14:6–14, 2005.
[105] Iliopoulos, I., S. Tsoka, M. A. Andrade, A. J. Enright, M. Carroll,
P. Poullet, V. Promponas, T. Liakopoulos, G. Palaios, C. Pasquier,
S. Hamodrakas, J. Tamames, A. T. Yagnik, A. Tramontano, D. Devos,
211
Literaturverzeichnis
C. Blaschke, A. Valencia, D. Brett, D. Martin, C. Leroy, I. Rigoutsos, C. Sander und C. A. Ouzounis: Evaluation of annotation strategies using
an entire genome sequence. Bioinformatics, 19(6):717–726, 2003.
[106] Andrade, M. A., N. P. Brown, C. Leroy, S. Hoersch, A. de Daruvar,
C. Reich, A. Franchini, J. Tamames, A. Valencia, C. Ouzounis und
C. Sander: Automated genome sequence analysis and annotation. Bioinformatics, 15(5):391–412, 1999.
[107] Frishman, D., K. Albermann, J. Hani, K. Heumann, A. Metanomski,
A. Zollner und H.-W. Mewes: Functional and structural genomics using
PEDANT. Bioinformatics, 17(1):44–57, 2001.
[108] Hubbard, T., D. Barker, E. Birney, G. Cameron, Y. Chen, L. Clark,
T. Cox, J. Cuff, V. Curwen, T. Down, R. Durbin, E. Eyras, J. Gilbert, M. Hammond, L. Huminiecki, A. Kasprzyk, H. Lehvaslaiho, P. Lijnzaad, C. Melsopp, E. Mongin, P. Pettett, M. Pocock, S. Potter,
R. Rust, E. Schmidt, S. Searle, G. Slater, J. Smith, W. Spooner,
A. Stabenau, J. Stalker, E. Stupka, A. Ureta-Vidal, I. Vastrik und
M. Clamp: The Ensembl genome database project. Nucleic Acids Research,
30(1):38–41, 2002.
[109] Ouzounis, C. A. und P. D. Karp: The past, present and future of genome-wide
re-annotation. Genome Biology, 3(2):comment2001.1–2001.6, 2001.
[110] Karp, P., S. Paley und J. Zhu: Database verification studies of SWISS–PROT
and GenBank. Bioinformatics, 17(6):526–532, 2001.
[111] Leser, Ulf und Peter Rieger: Integration molekularbiologischer Daten.
Datenbank-Spektrum, 3(6):56–66, 2003.
[112] Köhler, J.: Integration of Life Science Databases. BioSilico, 2004.
[113] Kanehisa, M. und S. Goto:
KEGG: Kyoto Encyclopedia of
Genes and Genomes.
Nucleic Acids Research, 28(1):27–30, 2000.
http://www.genome.ad.jp/kegg/.
[114] Etzold, T., A. Ulyanow und P. Argos: SRS: Information Retrieval System
for Molecular Biology Data Banks. Methods in Enzymology, 266:114–128, 1996.
[115] Frishman, D. und H. W. Mewes: PEDANTic genome analysis. Trends in
Genetics, 13(10):415–416, 1997.
[116] Senger, M., K.-H. Glatting, O. Ritter und S. Suhai: X-Husar, an Xbased graphical interface for the analysis of genomic sequences. Computer Methods and Programs in Biomedicine, 46(2):131–142, 1995.
212
Literaturverzeichnis
[117] Davidson, S. B., C. Overton, V. Tannen und L. Wong: BioKleisli: a digital
library for biomedical researchers. International Journal on Digital Libraries, 1:36–
53, 1997.
[118] Topaloglou, T., A. Kosky und V. Markowitz: Seamless Integration
of Biological Applications within a Database Framework. In: Lengauer, T.,
R. Schneider, D. Boork, D. Brutlag, J. Glasgow, H.-W. Mewes und
R. Zimmer (Herausgeber): The Seventh International Conference on Intelligent
Systems for Molecular Biology (ISMB ’99), Heidelberg, Germany, August 6-10,
Seiten 272–281, 1999.
[119] Matsuda, H., T. Imai, M. Nakanishi und A. Hashimoto: Querying Molekular Biology Databases by Integration Using Multiagents. IEICE TRANS. INF.
& SYST., E82-D(1):199–207, 1999.
[120] Wilkinson, M. D. und M. Links: BioMOBY: An open source biological web
services proposal. Briefings in Bioinformatics, 3(4):331–341, 2002.
[121] Haas, L. M., P. M. Schwarz, P. Kodali, E. Kotlar, J. E. Rice und
W. C. Swope: DiscoveryLink: A system for integrated access to life sciences
data sources. IBM Systems Journal, 40(2):489–511, 2001.
[122] Davidson, S. B., C. Overton und P. Buneman: Challenges in Integrating
Biological Data Sources. Journal of Computational Biology, 2(4):557–572, 1995.
[123] Davidson, S. B., J. Crabtree, B. P. Brunk, J. Schug, V. Tannen, G. C.
Overton und Jr. C. J. Stoeckert: K2/Kleisli and GUS: Experiments in
integrated access to genomic data sources. IBM Systems Journal, 40(2):512–531,
2001.
[124] Lacroix, Z. und T. Critchlow: Bioinformatics: Managing Scientific Data.
Morgan Kaufmann Publishers, 2003.
[125] Etzold, T., H. Harris und S. Beaulah: SRS: An Integration Platform for
Databanks and Analysis Tools in Bioinformatics, Kapitel 5, Seiten 109–145. Bioinformatics: Managing Scientific Data. Morgan Kaufmann Publishers, 2003.
[126] Biomax Informatics AG: BioRS. http://www.biomax.de/products.
[127] Haas, L. M., P. Kodali, J. E. Rice, P. M. Schwarz und W. C. Swope:
Integrating Life Sciences Data – With a Little Garlic. In: BIBE 2000: IEEE International Symposium on Bio-Informatic & Biomedical Engineering, Washington,
D.C., U.S.A., November 8-10, Seiten 5–12. IEEE Computer Society, 2000.
[128] Tannen, V., S. B. Davidson und S. Harker: The Information Integration
System K2, Kapitel 8, Seiten 225–248. Bioinformatics: Managing Scientific Data.
Morgan Kaufmann Publishers, 2003.
213
Literaturverzeichnis
[129] Buneman, P., S. Naquiv, V. Tannen und W. Limsoon: Principles of
programming with complex objects and collection types. Theoretical Computer
Science, 149:3–48, 1995.
[130] Schuler, G.D., J.A. Epstein, H. Ohkawa und J.A. Kans: Entrez: Molecular Biology Database and Retrieval System. Methods in Enzymology, 266:141–161,
1996.
[131] Senger, M., T. Flores, K.-H. Glatting, P. Ernst, A. HotzWagenblatt und S. Suhai: W2H: WWW interface to the GCG sequence
analysis package. Bioinformatics, 14(5):452–457, 1998.
[132] Chawathe, S. S., H. Garcia-Molina, J. Hammer, K. Ireland, Y. Papakonstantinou, J. D. Ullman und J. Widom: The TSIMMIS Project: Integration of Heteregenous Information Sources. In: Proc. of IPSI Conf., 1994.
[133] Shan, M.-C.: Pegasus Architecture and Design Principles. In: Buneman, P.
und S. Jajodia (Herausgeber): Proc. of the 1993 ACM SIGMOD Int. Conf.
on Management of Data, Washington, D.C., Band 22 der Reihe ACM SIGMOD
Record, Seiten 422–425. ACM Press, Juni 1993.
[134] Tork Roth, M., M. Arya, L. M. Haas, M. J. Carey, W. Cody, R. Fagin, P. M. Schwarz, J. Thomas und E. L. Wimmers: The Garlic Project. In:
Jagadish, H. V. und I. S. Mumick (Herausgeber): Proc. of the 1996 ACM SIGMOD Int. Conf. on Management of Data, Montreal, Quebec, Canada, Band 25
der Reihe ACM SIGMOD Record. ACM Press, Juni 1996.
[135] Schek, H.-J. und M. H. Scholl: The Relational Model with Relation-Valued
Attributes. Information Systems, 11(2):137–147, 1986.
[136] Balko, S., M. Lange, R. Schnee und U. Scholz: BioDataServer: An Applied Molecular Biological Data Integration Service. In: Istrail, S., P. Pevzner
und M. Waterman (Herausgeber): Data Integration in the Life Sciences, Band
2994 der Reihe Lecture Notes in Bioinformatics, Seiten 140–155. Berlin et al:
Springer, 2004.
[137] Prestwich, Steven und Stéphane Bressan: A SAT Approach to Query
Optimization in Mediator Systems. In: Proceedings of the Fifth International
Symposium on the Theory and Applications of Satisfiability Testing (SAT 2002),
Cincinnati, Ohio, USA, Seiten 252–259, 2002.
[138] Freier, A., R. Hofestädt und M. Lange: iUDB: An Object-Oriented System
for Modelling, Integration and Analysis of Gene Controlled Metabolic Networks.
In Silico Biology, 3:215–227, 2003.
[139] Freier, A.: Integrative Modellierung metabolischer Netzwerke. Dissertation, Universität Bielefeld, Technische Fakultät, 2005.
214
Literaturverzeichnis
[140] Lange, M., J. Köhler und P. Schweizer: Algebraic Concepts for Data Domains in Life Science. In: Lengauer, T., H.-P. Lenhof und R. Christmann
(Herausgeber): Poster Abstracts of the European Conference on Computational
Biology 2002, Saarbrücken, October 6–9, Seiten 134–135, 2002. Poster.
[141] Freier, A., R. Hofestädt, M. Lange, U. Scholz und A. Stephanik: BioDataServer: A SQL-based service for the online integration
of life science data.
In Silico Biology, 2(0005), 2002. Online Journal:
http://www.bioinfo.de/isb/2002/02/0005/.
[142] Barateiro, J. und H. Galhardas: A survey of data quality tools. DatenbankSpektrum, 14:15–21, 2005.
[143] Lange, M.: Integration heterogener WWW- und dateibasierter Informationsquellen sowie heterogener Datenbanksysteme in molekularbiologischen Informationssystemen – Methoden und Werkzeuge. Diplomarbeit, Otto-von-GuerickeUniversität Magdeburg, Fakultät für Informatik, Institut für Technische und Betriebliche Informationssysteme, Februar 1999.
[144] HSQLDB Development Group: HSQLDB - Lightweight 100% Java SQL Database Engine. http://www.hsql.org.
[145] Lange, M., V. Kumanduri, T. Münch, R. Schnee, U. Scholz und
P. Schweizer: DBOra: An Integrated Database for Context Based Search and
Browsing in Protein Data. In: Poster Abstracts of the European Conference on
Computational Biology 2003, Paris, September 27–30, 2003. Poster.
[146] Hofestädt, R. und T. Töpel: Case-based Support of Information Retrieval
and Analysis of Molecular Data. In: Proceedings of The 15th IEEE Symposium
on Computer-Based Medical Systems (CBMS 2002), Maribor, Slovenia, June 4-7,
Seiten 129–133, 2002.
[147] Töpel, T.: Untersuchung von Life-Science-Datenbeständen zur Identifikation
von Genotyp-Phänotyp-Korrelationen. Doktorarbeit, Universität Bielefeld, Technische Fakultät, 2004.
[148] Pfeiffer, T., I. Sánches-Valdenebro, J. C. Nuño, F. Montero und
S. Schuster: METATOOL: for studying metabolic networks. Bioinformatics,
15(3):251–257, 1999.
[149] Freier, A., R. Hofestädt, M. Lange und U. Scholz: Information Fusion
of Molecular Data Sources for Analysis of Metabolic Networks. In: ColladoVides, J. und R. Hofestädt (Herausgeber): Gene Regulation and Metabolism,
Seiten 49–84. MIT Press, 2002.
[150] Trißl, S., K. Rother, H. Müller, T. Steinke, I. Koch, R. Preissner,
C. Frommel und U. Leser: Columba: an integrated database of proteins, structures, and annotations. BMC Bioinformatics, 6(1):81, 2005.
215
Literaturverzeichnis
[151] Kirov, S. A., X. Peng, E. Baker, D. Schmoyer, B. Zhang und J. Snoddy: GeneKeyDB: A lightweight, gene-centric, relational database to support data
mining environments. BMC Bioinformatics, 6(1):72, 2005.
[152] Shah, S., Y. Huang, T. Xu, M. Yuen, J. Ling und B. F. F. Ouellette:
Atlas - a data warehouse for integrative bioinformatics. BMC Bioinformatics,
6(1):34, 2005.
[153] Lange, M., N. Sreenivasulu, A. Stephanik und U. Scholz: Data relationship mining in life science databases. In: Hofestädt, R. (Herausgeber):
Abstracts of the International Workshop Integrative Bioinformatics 2005, Bielefeld, July 4–5, Seiten 9–12, 2005.
[154] Soffner, M.: Offline Werkzeug zum Graphmining auf integrierten molekularbiologischen Datenbanken. Diplomarbeit, Otto-von-Guericke-Universität Magdeburg, Fakultät für Informatik, Institut für Technische und Betriebliche Informationssysteme, September 2005.
[155] Mischke, U., U. Scholz, T. Töpel, D. Scheible, R. Hofestädt und F. K.
Trefz: RAMEDIS – Rare Metabolic Diseases Publishing Tool for GenotypePhenotype Correlation. In: MedInfo 2001: Proceedings of the 10th World Congress
on Health and Medical Informatics, London, September 2 – 5, 2001, Seiten 970–
974. Amsterdam: IOS Press, 2001.
[156] Freier, A., R. Hofestädt und M. Lange: iUDB: An Object-Oriented
System for Modelling, Integration and Analysis of Gene Controlled Metabolic Networks.
In Silico Biology, 3(0019), 2003.
Online Journal:
http://www.bioinfo.de/isb/2003/03/0019/.
[157] Moldenhauer, F., M. Lange, R. Hofestädt und S. Schuster: METATOOL: Eine Software zur Analyse und Vorhersage metabolischer Stoffwechselwege. In: Hofestädt, R., K. Lautenbach und M. Lange (Herausgeber):
Modellierung und Simulation Metabolischer Netzwerke: DFG-Workshop im Rahmen des DFG-Schwerpunktes Informatikmethoden zur Analyse und Interpretation
großer genomischer Datenmengen, Magdeburg, 19. – 20. Mai 2000, Preprint Nr.
10, Seiten 96–102. Fakultät für Informatik, Universität Magdeburg, 2000.
[158] Höpfner, H. und M. Lange: phpMetatool - eine WWW-Schnittstelle für
das METATOOL. Laborpraktikumsbericht, Fakultät für Informatik, Universität Magdeburg, 2000. http://www-bm.ipk-gatersleben.de/tools/phpMetatool/.
[159] Wheeler, D. L., D. M. Church, S. Federhen, A. E. Lash, T. L. Madden, J. U. Pontius, G. D. Schuler, L. M. Schriml, E. Sequeira, T. A.
Tatusova und L. Wagner: Database resources of the National Center for
Biotechnology. Nucleic Acids Research, 31(1):28–33, 2003.
216
Werdegang
Ausbildung
09/1980 - 08/1990 Polytechnische Oberschule Johannes-R.-Becher in Magdeburg
09/1990 - 08/1992 Abitur am Cracauer Gymnasium in Magdeburg
10/1992 - 09/1993 Grundwehrdienst im 4./PzGrenBtl 401 Hagenow
10/1993 - 02/1999 Studium an der Otto-von-Guericke-Universität Magdeburg, Fachrichtung Informatik
in der Vertiefungsrichtung Datenbanksysteme
und Rechnerunterstützte Ingenieursysteme
mit dem Abschluß als Diplom-Informatiker
Berufspraxis
02/1999 - 10/2001 Drittmittelstellen als wissenschaftlicher Mitarbeiter an der Otto-von-Guericke-Universität Magdeburg, Institut für Technische Informationssysteme in den Projekten:
• Ein wissensbasierter Ansatz zur Diag”
nose von Stoffwechselwegerkrankungen“
(Kurt-Eberhard-Bode-Stiftung)
• Modellierung von genregulatorischen
”
Netzwerken“ (BMBF)
• Modellierung und Animation regulato”
rischer Genwirknetze“ (DFG)
11/2001 - 01/2002 wissenschaftlicher Mitarbeiter an der Ottovon-Guericke-Universität Magdeburg, Institut für Technische und Betriebliche Informationssysteme in der Arbeitsgruppe Rechnerunterstützte Ingenieursysteme
(Fortsetzung auf der nächsten Seite)
217
(Fortsetzung von der vorigen Seite)
02/2002 - 08/2003 Drittmittelstelle als wissenschaftlicher Mitarbeiter am IPK Gatersleben, Abteilung Cytogenetik in der Arbeitsgruppe Transkriptomanalyse im Projekt Elektronische In”
frastruktur für die Pflanzenbiotechnologie“
(BMBF)
seit 09/2003
tätig als Bioinformatiker am IPK Gatersleben, Abteilung Molekulare Genetik in der Arbeitsguppe Bioinformatik
218