Paper - Institut für Informatik

OPM Object-Protocol Model
Daniel Konrad
Seminararbeit im Rahmen des Seminars
„Datenintegration am Beispiel der Bioinformatik“
Institut für Informatik
Humboldt Universität zu Berlin
Februar 2003
Inhalt
1 Einführung
2 Das Object-Protocol Model
2.1 Objektklassen und Attribute
2.2 Die Protokollklasse
2.3 Die OPM Anfragesprache OPM_QL
2.4 Die OPM Data Management Tool
2.5 Der OPM Schema Translator
3 Das OPM Multidatenbank System
3.1 Motivation
3.2 Die OPM Multidatenbank Anfragesprache OPM*QL
3.3 Die OPM Multidatenbank Anfrage Strategie
3.4 Das Multidatenbank Verzeichnis
4 Ein Beispiel
4.1 Das GDB-GSDB Multidatenbank System
4.2 Beziehungen zwischen GDB und GSDB
4.3 Typische Anfragen über GDB und GSDB
3
4
4
5
5
5
7
8
8
9
9
11
12
12
12
12
5 Zusammenfassung
14
6 Anhang
15
7 Referenzen
16
1 Einführung
Die enormen Datenmengen die von wissenschaftlichen Experimenten und Simulationen
generiert werden, benötigen Datenbank Management Systeme (DBMS). Wissenschaftler
verwenden hierfür oft kommerzielle Systeme die sich im Einsatz bewährt haben und dies sind
im allgemeinen relationale DBMS. Gerade die molekularbiologischen Datenbanken greifen
auf diese DBMS zurück um ihre Daten zu organisieren. Als Beispiel seien hier die Genome
Data Base (GDB) an der John Hopkins School of Medicine, die Genome Sequence Data Base
(GSDB) am National Center for Genome Resources und die Protein Data Bank (PDB) am
Brookhaven National Laboratory genannt, welche alle unter Verwendung des Sybase DBMS
entwickelt wurden.
Die relationalen Datenbanksprachen, welche den relationalen DBMS zugrunde liegen,
eigenen sich nicht um komplexe wissenschaftliche Experimente zu modellieren. Die Daten
dieser Experimente werden meist über unzusammenhängende Tupel, welche darüber hinaus
noch über mehrere Tabellen verstreut sind repräsentiert. Dies macht Beschreibung,
Entwicklung und Wartung dieser Datenbanken sehr aufwendig und fehleranfällig.
Objektorientierte DBMS sind besser geeignet, um Objekt Strukturen darzustellen, welche von
wissenschaftlichen Experimenten erzeugt werden. Die von ihnen bereitgestellten Konstrukte
wie Objekte, Attribute und Vererbung werden auch häufig von Wissenschaftlern verwendet
um ihre Experimente und die daraus entstandenen Daten zu beschreiben. Kommerzielle
objektorientierte DBMS sind dennoch sehr aufwendig bei der Entwicklung und stellen meist
nur unzureichende Mechanismen zur Generierung von Anfragen bereit. Weiterhin sind sie
nicht geeignet um verschieden Sichten auf ein und dieselbe Anwendung (Experiment) zu
ermöglichen und auch die Modellierung solcher Experimente ist meist nur unzureichend
möglich.
Das Object-Protocol Model (OPM) ist ein Ansatz um die Unzulänglichkeiten dieser bisher
existierenden Datenmodelle zu beheben.
Um die Probleme bei der Integration heterogener Datenbestände zu bewältigen wurde
weiterhin ein auf OPM basierendes Multidatenbank Anfrage System entwickelt. Dieses
Object-Protocol Model Multidatabase Query System (OPM*QS) wird im Abschnitt 3
ausführlich besprochen.
2 Das Object-Protocol Model
Das Object-Protocol Model (OPM) ist eine objektorientiertes Datenmodel und unterstützt
spezielle objektorientierte Konstrukte wie Objekte und Vererbung. Auf die einzelnen
Konstrukte und ihr Darstellung im OPM wird im folgenden eingegangen.
2.1 Objektklassen und Attribute
Objekte im OPM werden eindeutig identifiziert über object identifiers (oids). Sie werden mit
Hilfe eines oder mehrerer Attribute beschrieben und sind in Klassen unterteilt. Eine
Teilmenge der Attribute einer Klasse repräsentiert den externen object identifier (ID) dieser
Klasse. Eine Klasse kann weiterhin als Spezialisierung (Unterklasse) einer anderen Klasse
definiert werden, wobei die Subklasse die Attribute der Superklasse vererbt bekommt.
Attribute haben einen Namen und besitzen einen Wert. Sie könne einfach sein oder aus einem
Tupel von mehreren Attributen bestehen. Die Adresse einer Person kann z.B. als Tupel
Adresse modelliert werden, welches aus den einfachen Attributen Straße, Stadt und
Postleitzahl besteht. Ein Attribute kann einen einzelnen Wert haben, eine Liste von Werten
oder einen Satz/Set von Werten. Diese Werten können primitiv, d.h. von einem vom System
bereitgestellten Datentyp (integer, char, ...) sein oder abstrakt wenn sie mit einer anderen
Objektklasse verbunden sind. Ein Beispiel für den Aufbau eines OPM Schemas kann man im
Anhang sehen.
Die Attribute einer Objektklasse können weiterhin in versionierte und nicht-versionierte
Attribute unterteilt werden. Nicht-versionierte Attribute repräsentieren unveränderbare
Objekteigenschaften, z.B. das Geburtsdatum einer Person, während versionierte Attribute
veränderliche Eigenschaften darstellen, z.B. die Adresse einer Person.
Weiterhin unterstützt OPM die Beschreibung von abgeleiteten Attributen. Abgeleitete
Attribute sind einfache Attribute deren Werten von Werten anderer Attribute abgeleitet
wurden und zwar mit Hilfe folgende Möglichkeiten: arithmetische Ausdrücke,
Aggregatfunktionen (min, max, sum, avg, count) und Attributzusammensetzungen.
Die Struktur einer Instanz eines Objekts ist folgendermaßen definiert (nach [1]):
Sei Oi eine Objektklasse und x eine Instanz dieser Klasse (x∈ Oi). Dann wird x dargestellt als
x = (oid(x), val(x)), wobei oid(x) der object identifier und val(x) der Wert von x ist. val(x) hat
die folgende Form: A1:A1(x), ..., An:An(x) , Aj ist der Name des Attributs und Aj(x) der
jeweilige Wert. Der Definition des Wertes sieht folgendermaßen aus.
1. wenn Aj eine einfaches Attribut mit einem primitiven Wert ist, dann besteht Aj(x)
aus einem Element, aus einer Liste oder aus einem Satz von Elementen
2. wenn Aj ein einfaches abstraktes Attribut mit Werten der Objektklasse O1 oder ...
oder Om ist, dann besteht Aj(x) aus einem Element, aus einer Liste oder aus einem
Set von Elementen von {oid(y) | y∈ Ok , 1 ≤ k ≤ m}
3. wenn Aj = (Aj1, ..., Ajn), dann besteht Aj(x) aus einem Tupel, aus einer Liste oder
aus einem Set von Tupeln der Form Aj1:Aj1(x), ..., Ajn:Ajn(x), wobei jede
Komponente Ajk(x), 1 ≤ k ≤ m aus einem Element besteht welches in Punkt 1 oder
2 definiert wurde
2.2 Die Protokollklasse
Um wissenschaftliche Experimente besser modellieren zu können, besitzt OPM
Protokollklassen. Diese Klassen sind ähnlich wie Objekte definiert, d.h. sie besitzen einen
Namen, eine Beschreibung, einen identifier und Attribute. Diese Protokollklassen können
ebenfalls mit den in 2.1 genannten Attributen spezifiziert werden. Darüber hinaus werden
auch sogenannte input und output Attribute unterstützt, mit deren Hilfe man die Eingabebzw. Ausgabedaten der entsprechenden Experimente repräsentieren kann. Es ergeben sich
hierbei auch Verbindungen zwischen einzelnen Protokollen (Experimenten): die output
Attribute eines Protokolls sind (zum Teil) die input Attribute eines anderen.
2.3 Die OPM Anfragesprache OPM_QL
Die OPM Anfragesprache hat eine an SQL angelehnte Struktur. Sie unterstützt spezielle
objektorientierte Konstrukte wie vererbte Klassen und abgeleitete Attribute. Es werden
grundsätzlich nur Anfragen über eine Klasse unterstützt, doch lässt sich dies durch die
Verwendung abstrakten Attributen oder abgeleiteten Klasse umgehen. Um die Komplexität
bei der Implementierung von OPM auf einem relationalen DBMS so gering wie möglich zu
halten, wurde auf weiterführende objektorientierte Konstrukte in OPM_QL verzichtet.
OPM_QL unterstützt vier Befehle zur Datenmanipulation: SELECT, INSERT, DELETE und
UPDATE, wobei im folgenden nur SELECT Statements erörtert werden.
Eine einfache OPM Anfrage könnte wie folgt aussehen (Quelle [2]):
Die Klasse Chromosome hat ein Attribut number und die Klasse Gene hat die
Attribute name und chromosome, wobei das Attribut chromosome Werte von der
Klasse Chromosome nimmt.
Die folgende Anfrage liefert alle Gene die auf Chromosom 13 liegen:
SELECT
FROM
WHERE
name
gene
chromosome.number = „13“;
2.4 Die OPM Data Management Tools
Um das erstellen, warten und arbeiten mit OPM bzw. den zugehörigen relationalen DBSM zu
erleichtern haben die Entwickler von OPM eine Reihe von OPM Data Management Tools zur
Verfügung gestellt, die hier im einzelnen erläutert werden sollen.
OPM wird zur Zeit nur auf relationale DBMS „aufgesetzt“, d.h. die Datenbanken selbst
werden mit einem herkömmlichen DBMS wie Sybase oder Oracle erstellt. OPM bietet dann
eine objektorientierte Sicht auf die Daten. Das OPM Schema muss somit auf das DBMS
spezifische relationale Schema gemappt werden. Dies geschieht mit Hilfe des OPM Schema
Translators, der in 2.5 näher erläutert wird.
Um ein solches OPM Schema zu erstellen, bieten sich mit den Data Management Tools zwei
Möglichkeiten:
Mit dem „relational to OPM schema conversion tool“ (Rel2OPM) kann eine
OPM Sicht (view) auf die Daten generiert werden. Die speziellen
objektorientierten Konstrukte von OPM werden hierbei natürlich nicht
berücksichtigt. Man kann mit dem „OPM Schema Editor“ diese Sicht aber ggf.
anpassen.
-
Alternativ kann erst ein OPM Schema erzeugt werden und dann entsprechend
auf die relationalen Konstrukte gemappt werden (OPM Schema Translator)
Die weiteren Data Management Tools sind in Abbildung 1 dargestellt:
OPM Schema
Editor
OPM Browsing
& Querying
OPM Schema
OPM Data
Rel2OPM
Database
Definition
Database
Procedures
OPM Schema
Translator
OPM-DBMS
Mapping File
Add Ref
Construct
SQL
Convert
Data
SQL Queries /
Transactions
SQL
Query Result
Exec
SQL
relationales DBMS
Abbildung 1: OPM Data Management Tools (Quelle [1])
2.5 Der OPM Schema Translator
Der OPM Schema Translator besteht im wesentlichen aus vier Teilen (Abbildung 2).
1. Überprüfung der Korrektheit des OPM Schemas
2. OPM Systemklassen und werden generiert und dem OPM Schema hinzugefügt
3. Mapping des OPM Schemas in eine abstraktes, DBMS unabhängiges relationales
Schema
4. Mapping des abstrakten Schema in eine DBMS spezifisches Schema
OPM Schema
Generierung von
System Attributen
OPM Schema mit
System Attributen
opm_to_rel
Mapping
Dictionary
Abstraktes
relationales Schema
to_sybase
to_oracle
to_...
Sybase Database
Defintions & Procedures
Oracle Database
Defintions & Procedures
... Database
Defintions & Procedures
Abbildung 2: Die Struktur des OPM Schema Translators (Quelle [5])
Eine kurze Übersicht über die Abfolge der einzelnen Schritte während des Mapping Vorgangs
soll im folgenden gegeben werden.
Bevor das eigentliche Mapping stattfindet, müssen noch einige Voraussetzungen geschaffen
werden. Zum einen müssen die Meta- und Systemklassen erzeugt werden. Zu diesen Klassen
gehört eine Klasse DATABASE mit drei Attributen: eine Identifikation _dbid, eine
Beschreibung _dbDescr und eine Name _dbName. Des weiteren wird ein Metaklasse
CLASSES erzeugt, in welcher alle Klassen u.a. mit einem Namen, einem Typ und einer ID
spezifiziert werden. Die Abhängigkeitsbeziehungen zwischen den Klasse und Protokollen
bezüglich Vererbung werden in den Metaklassen SCLASSES und SPROTOCOLS
gespeichert. Weitere Preprocessing Schritte sind u.a. die Festlegung der Reihenfolge in
welcher die einzelnen Objekte in relationale Konstrukte gemappt werden und spezielle
Verfahrensweisen für versionierte Attribute.
Beim eigentlichen Mapping werden alle Instanzen der Objekte durch eine sogenannte
Primärrelation Rp dargestellt. In dieser Primärrelation sind alle Attribute der Objektinstanz
gespeichert sowie die Objekt ID oid, welche zugleich der Primärschlüssel der Relation ist.
Falls es sich bei dieser Instanz um eine Unterklasse eines anderen Objekts handelt, ist die
Objekt ID ein Fremdschlüssel zu diesem Objekt. Auf dieselbe Art werden abstrakte Attribute
ebenfalls als Fremdschlüssel zum jeweiligen Objekt modelliert. Die versionierten Attribute
werden in einer eigenen Relation Rv gespeichert, die eine ähnliche Struktur wie Rp aufweist.
Um Attribute die als Liste oder Set modelliert sind darzustellen, benötigt man eine weitere
Relation Ra. Falls diese Attribute zusätzlich noch versioniert sind, werden sie über eine
Relation Rav gespeichert. Eine ausführlichere Beschreibung des gesamten Vorgangs und
Einzelheiten in Bezug auf die Modellierung der spezifischen objektorientierten Konstrukte
findet man in [4].
Das folgende kurze Beispiel soll den Prozeß veranschaulichen.
Im OPM Schema (angelehnt an GDB) soll die Klasse Chromosome als Unterklasse von
GenomicSegment modelliert sein. Des weiteren besitzt Chromosome ein abstraktes Attribut
cellularCompartment welches von der Klasse CompartmentDict abgeleitet ist.
OBJECT CLASS
ATTRIBUTE
Chromosome isa* GenomicSegment
cellularCompartement: [1,1] CompartmentDict
Das Mapping sieht dann wie folgt aus: Eine Primärrelation Rp mit dem Name Chromosome
und dem Primärschlüssel oid und dem Attribut cellularCompartment wird erzeugt. Da
Chromosome eine Unterklasse von GenomicSegment ist, ist das Attribut oid eine
Fremdschlüssel zu GenomicSegment. Das abstrakte Attribut cellularCompartment wird
ebenfalls als Fremdschlüssel auf CompartmentDict modelliert.
Chromosome (oid, cellularCompartment)
FOREIGN KEY (oid) TO GenomicSegment NOT NULL
FOREIGN KEY (cellularCompartment) TO CompartmentDict NOT NULL
3 Das OPM Multidatenbank System
3.1 Motivation
Molekularbiologische Daten sind meist über eine Vielzahl heterogener Datenbanken verteilt.
Diese Heterogenität äußert sich in mehreren Aspekte, welche hier nicht näher erläutert
werden.
Es stellt sich hierbei eines der größten Probleme für die Bioinformatik: die Datenintegration.
Die Strategien um dieses Problem zu lösen kann man in zwei Kategorien einteilen (nach [7]):
Konsolidierung:
o die einzelnen heterogenen Datenbanken werden in eine homogene Datenbank
integriert und durch diese ersetzt
o die einzelnen heterogenen Datenbanken werden mit einer gemeinsamen DDL
(Data Definition Language) oder DBMS reorganisiert
Föderation: es wird Zugriff auf mehrere heterogen Datenbanken ermöglicht, wobei
die einzelnen Datenbanken ihre Autonomie (Definition, Anwendung, ...) behalten
o Datenbanken werden mit Referenzen (Links) auf andere Datenbanken
erweitert
o Data Warehouses
o Datenbanken werden in einem Multidatenbank System organisiert
OPM verfolgt die Strategie der Multidatenbank Systeme und versucht mit den in 2.4
vorgestellten Tools das Arbeiten mit diesen Systemen zu erleichtern. Vor allem die
semantischen Probleme bei der Generierung von Schemen, Sichten und bei der Suche nach
Daten sollen somit teilweise gelöst werden.
3.2 Die OPM Multidatenbank Anfragesprache OPM*QL
OPM*QL ist ähnlich aufgebaut wie OPM_QL (siehe Abschnitt 2.3), verfügt aber nur über den
SELECT Befehl. Die weitere Unterstützung von INSERT, DELETE und UPDATE Befehlen
würde erheblich mehr Informationen über die einzelnen Datenbanken voraussetzen und somit
auch die Implementierung erschweren. Um die Funktionalität auch beim Zugriff auf mehrere
Datenbanken zu gewährleisten ist OPM*QL mit einigen Erweiterungen (im Vergleich zu
OPM_QL) versehen. Diese Erweiterungen ermöglichen Anfragen über mehrere Klassen von
verschiedene Datenbanken, erlauben die Navigation zwischen Klassen aus mehreren
Datenbanken und die Umbenennung von Anfragevariablen um mögliche Namenskonflikte zu
vermeiden.
Eine einfache OPM Anfrage könnte wie folgt aussehen (nach [2]):
SELECT
FROM
WHERE
AND
ID = GSDB:Gene, GSDBRef = GSDB.Gene.gdb_xref
GSDB:Gene
GSDB:Gene.gdb_xref IS NOT NULL
GSDb:Gene.name = „ACHE“;
GSDB:Gene bezieht sich hierbei auf die Klasse Gene aus der Datenbank GSDB. Wenn ein
Klassenname einzigartig ist, d.h. nur einmal und auch nur ein einer Datenbank vorkommt,
kann man die Bestimmung der Datenbank weglassen (z.B. nur Gene statt GSDB:Gene)
Im Multidatenbank System kann eine ähnliche Anfrage gestellt werden, diesmal aber unter
Einbeziehung einer zweiten Datenbank. Eventuell benötigte Bedingungen können im
Multidatenbank System auch Klassen aus verschiedene Datenbanken umfassen, wie folgendes
Beispiel zeigt (aus [2]).
SELECT
FROM
WHERE
AND
Name = GSDB:Gene.nem, Reason = HGD:Gene.reason,
Annotation = HGD:Gene.annotation
GSDB:Gene, HGD:Gene
HGD:Gene.accessionID = GSDB.Gene.gdb_xref
GSDB.Gene.name = „ACHE“
Der Join der beiden Gen Klassen von HGD und GSDB erfordert in der Praxis noch einfache
Stringmatching Operationen.
3.3 Die Multidatenbank Anfrage Strategie
Die Multidatenbank Anfrage Strategie besteht aus zwei Schritten (siehe auch Abbildung 3):
1. die Multidatenbank Anfrage wird in einzelne Anfragen für die entsprechenden
Datenbanken im Multidatenbanksystem zerlegt, wobei die einzelnen Anfragen mit
Hilfe des OPM Query Translators ausgewertet werden [3]
2. aus den Ergebnisse der einzelnen Anfragen wird das Ergebnis der Multidatenbank
Anfrage zusammengesetzt
OPM Multidatabase Query
Multidatabase
Directory
OPM Multidatabase
Query Processor
Single Database
Queries
Single Database
Queries
OPM Query
Translator
OPM Query
Translator
Database X
Database Y
Abbildung 3: Abarbeitung einer Multidatenbank Anfrage
In der aktuellen Version 4.1 wird die Multidatenbank Anfrage nach einem einfachem Schema
ausgewertet: die einzelnen Anfragen werden parallel abgearbeitet und die einzelnen
Ergebnisse werden lokal zusammengefasst (join). Dies ist im Hinblick auf die
Geschwindigkeit mit der die Anfrage abgearbeitet wird (Performance) natürlich äußerst
ineffizient. Deshalb haben die Entwickler eine alternativen Ansatz beschrieben. Die einzelnen
Anfragen werden hierbei sequentiell, d.h. nacheinander ausgeführt, wobei die Ergebnisse
jeder Anfrage die jeweils nächste Anfrage in der Sequenz beschränken. Dies kann je nach Art
der Anfrage viel effizienter sein.
Dieser Ansatz ist aber viel schwerer zu implementieren, da er z.B. einen bidirektionalen
Datenfluss zwischen dem OPM Multidatenbank System und den enthaltenen Datenbanken
beinhalten müsste und somit auch mehr Kooperation von den einzelnen Datenbaken erfordert.
Dies ist nötig um z.B. die Größe einzelner Tabellen (Relationen) in den jeweiligen
Datenbanken zu bestimmen und somit die beste Abarbeitungssequenz für die Anfragen zu
generieren.
Eine weitere Methode um die Performance zu erhöhen ist die Erweiterung des Query
Processors, also des Moduls welche die einzelnen Anfragen erstellt und die Ergebnisse
zusammensetzt. Der bisherige Query Processor kann nur Joins und einfache Bedingungen
(größer, kleiner, ...) auswerten. Er kann jedoch erweitert werden und somit auch Projektionen
(projections), komplexere Bedingungen und Aggregatfunktionen unterstützen.
Als letztes sei hier noch die Möglichkeit genannt sogenannte „distributed-join tools“ zu
verwenden, also Software Module die Multidatenbank SQL Anfragen über mehrere
relationale DBMS ermöglichen (Sybase Enterprise CONNECT). Dies gelingt natürlich nur
wenn die einzelnen Datenbanken homogen zueinander sind, d.h. im Idealfall alle mit
demselben DBMS erstellt. Diese Module können als Ergänzung zum aktuellen OPM
Multidatenbank Anfrage System gesehen werden. Da sie speziell auf ein bestimmtes DBMS
optimiert sind, können Anfragen hiermit erheblich schneller ausgewertet werden.
Eine OPM*QL Anfrage müsste dann nur noch in eine Multidatenbank SQL Anfrage übersetzt
und das Ergebnis wieder zurück in das OPM Datenformat konvertiert werden.
3.4 Das Multidatenbank Verzeichnis
Um eine heterogene Datenbank in eine OPM Multidatenbank System zu integrieren werden
diverse Informationen über diese Datenbank benötigt. Sie werden im Multidatenbank
Verzeichnis (Multidatabase Directory) gespeichert, welches aus folgenden drei Teilen besteht:
1. Allgemeine Informationen
o Name und Beschreibung der einzelnen Datenbank
o Ort und Geschichte der Datenbank
o Informationen über die DDL und die Implementierung
o Kontaktinformationen
o Zugangsinformationen
o Stichwörter (meist Klassennamen)
2. Schema Bibliothek (Schema Library)
o semantische Beschreibung der von der Datenbank dargestellten Konzepte
o Motivationen für bestimmte Designentscheidungen
o Synonyme und Stichwörter um Unterschiede in den einzelnen Datenbanken zu
erkennen
o Beispieldaten
o Mapping Verzeichnis OPM-DBMS
3. Link Bibliothek (Link Library)
o Informationen über bekannte Links zwischen Klassen in unterschiedlichen
Datenbanken, darunter Beschreibung der Semantik, Art des Zusammenhangs
(surjektiv, bijektiv, ...) und evtl. Informationen über Stringmatching
Operationen die ausgeführt werden müssen um den Link zu verfolgen
DATABASE GSDB
DESCRIPTION: „GSDB 2.0“
SERVER: GSDB
USERID: (user id)
PASSWORD: (password)
USERDB: gsdb
METADATAFILE: gsdb.so
CLASSES:
Feature
Gene
Product
...
DATABASE HGD
DESCRIPTION: „GDB 6.0 HGD“
SERVER: gdb60
USERID: (user id)
PASSWORD: (password)
USERDB: hgd
METADATAFILE: hgd.so
CLASSES:
Amplimer
Chromosome
Gene
...
LINK GSD-GDB-GENES
DESCRIPTION: „External reference from GSDB.Gene to HGD.Gene“
FROM: GSDB.Gene
TO: HGD.Gene
CODE: HGD:Gene.accessionID = GSDB:Gene.gdb_xref;
Abbildung 4: vereinfachtes Beispiel für den Inhalt eines Multidatenbank Verzeichnisses
(Quelle [2])
4 Ein Beispiel
4.1 Das GDB-GSDB Multidatenbank System
Die Genome Database (GDB) ist eine Molekulardatenbank für Gen-Mapping Daten an der
John Hopkins School of Medicine, Baltimore. Die Version 6.0 wurde mit einem Sybase
DBMS unter Verwendung des OPM Toolkits entwickelt. GDB besteht aus drei
unterschiedlichen Datenbanken: der Human Genome Database (HGD), der Citation Database
und der Registry Database.
Ein Überblick über die wichtigsten Klassen findet man im Anhang
Die Genome Sequence Database (GSDB) ist eine Datenbank für Gensequenz Daten und wird
am National Center for Genome Resources betrieben. Sie wurde ebenfalls mit einem Sybase
DBMS entwickelt, aber diesmal ohne Zuhilfenahme des OPM Toolkits. Um den Zugriff über
OPM zu ermöglichen, wurde nachträglich eine OPM Sicht generiert.
4.2 Beziehungen zwischen GDB und GSDB
Bei Betrachtung des OPM Schemas beider Datenbanken finden sich einige Gemeinsamkeiten
als auch Unterschiede in der Art wie bestimmte Daten modelliert werden. Dies soll am
Beispiel der Klasse Gene erläutert werden.
Beide Datenbanken haben eine Klasse Gene. In GDB ist die Klasse Gene eine Unterklasse
von GenomicSegment. Informationen über das jeweilige Gen enthalten u.a. eine Begründung
warum diese Genregion als Gen angesehen wird (Gene.evidence) und Links zu Gen-Familien
denen dieses Gen angehört (Gene.families). Ein Gen in GDB kann über seine GDB accession
ID auch von externen Datenbanken referenziert werden.
In GSDB sind Gene ein Feature einer Gensequenz, wobei hierbei nicht von einer
Spezialisierung gesprochen werden kann, da ein Gen in mehreren Features erwähnt sein kann.
Weiterhin wird der Name des Gens und Referenzen auf externe Datenbanken über z.b.
gdb_xref oder mousedb_xref gespeichert.
Weitere Informationen über Beziehungen zwischen GDB und GSDB finden sich in [2].
4.3 Typische Anfragen über GDB und GSDB
Die folgenden Anfragen stammen aus [3].
Anfrage 1: Finde Gene auf Chromosom X die für die Produktion des Proteins kinase sorgen.
Um solche Gene zu finden, müssen zuerst in der Klasse GSDB:Feature.products
entsprechende Produkte (Proteine) dieses Namens gesucht werden um dann Gene zu finden
die mit demselben Produkt assoziiert sind. Auf das entsprechende Gen in der GDB Human
Genome Database (HGD) kann dann über gdb_xref zugegriffen werden. (Eventuell sind
dabei noch einfache Stringmatching Operationen durchzuführen). Letztlich wird dann in HGD
getestet, ob das entsprechende Gen auf dem Chromosom X liegt.
SELECT
FROM
WHERE
AND
AND
HGD:Gene.displayName, HGD:Gene.accessionID
GSDB:Feature, HGD:Gene
Feature.products.name MATCH „%kinase%“
Feature.genes.gdb_xref = HGD:Gene.accessionID
HGD:Gene.mapElements.map.chromosome.displayName = „X“;
Diese OPM*QL Anfrage generiert folgende OPM_QL Anfrage an HGD
SELECT
FROM
WHERE
displayName, accessionID, mapElements.map.chromosome.displayName
Gene
mapElements.map.chromosome.displayName = „X“;
... und an GSDB
SELECT
FROM
WHERE
products.name, genes.gdb_xref
Feature
products.name MATCH „%kinase%“;
Die Bedingung Feature.genes.gdb_xref = HGD:Gene.accessionID wird lokal überprüft.
Anfrage 2: Finde sequenzierte Regionen auf Chromosom 17 mit einer Läge größer als 10000.
Über die Klasse MapElement werden Elemente auf Chromosom 17 gesucht. Links zwischen
diese Elementen und GSDB werden über die HGD Klasse SequenceLink gefunden. In GSDB
wird dann getestet ob die Sequenz länger als 10000 ist.
SELECT
FROM
WHERE
AND
AND
AND
AND
Entry.accession_number, Entry.sequence.length
HGD:MapElement, HGD:SequenceLink, GSDB:Entry
MapElement.map.chromosome = „17“
SequenceLink.dBObject = MapElement.segment
SequenceLink.externalDB.displayName = „GSDB“
SequenceLink.accessionID = Entry.accession_number
Entry.sequences.length > 10000;
Diese OPM*QL Anfrage generiert folgende OPM_QL Anfragen an HGD
SELECT
FROM
WHERE
map.chromosome, segment
MapElement
map.chromosome = „17“;
Und
SELECT
FROM
WHERE
dBObject, externalDB.displayName, accessionID
SequenceLink
externalDB.displayName = „GSDB“;
... sowie ein Anfrage an GSDB
SELECT
FROM
WHERE
accession_number, sequences.length
Entry
sequences.length > 10000;
Bei dieser zweiten Anfrage wird ein großes Problem von OPM deutlich: die ineffiziente
Abarbeitung und Auswertung von Anfragen. Die Aufspaltung einer Anfrage an HGD in Zwei
mag zunächst nicht sehr aufwendig erscheinen, doch wenn man das anschließende Joinen der
Ergebnisse hinzunimmt kann sich dies schnell ändern. Des weiteren ist zu bedenken, dass es
sich hierbei um eine sehr einfache Anfrage handelt: in der Praxis sind Anfragen mit mehreren
hundert Bedingungen keine Seltenheit und wenn dann die Auswertung auf ähnliche Art und
Weise erfolgt, steht man sehr schnell vor einem großen Performance Problem.
5 Abschließende Bemerkungen
OPM bietet mit seinen objektorientierten Konstrukten und den Data Management Tools sehr
praxisnahe und effiziente Möglichkeiten zur Modellierung und Speicherung
wissenschaftlicher Experimente und Daten. In der Praxis hat sich OPM bis auf die
Verwendung in einigen wenigen Datenbanken allerdings nicht durchgesetzt. Vor allem die
Geschwindigkeit mit welcher die einzelnen Anfragen abgearbeitet werden, ist im Vergleich
mit anderen (relationalen) DBMS zu langsam. Interessante Ideen wie z.B. die sequenzielle
Abarbeitung der Anfragen, die Verwendung von Inter-Database Links und ein erweiterter
Query Processor wurden leider nicht umgesetzt. Auch die Protokollklasse, eigentlich als
Arbeitserleichterung bei der Modellierung von Experimenten gedacht, wurde in der Praxis
kaum verwendet und selbst von den OPM Entwicklern wurde dieses Konzept in späteren
Veröffentlichungen nicht mehr erwähnt.
Abschließend gesehen war OPM ein, wenn auch gescheiterter, Versuch die Vorzüge von
objektorientierten Datenmodellen bei der Lösung der Problematik der Datenintegration zum
Tragen kommen zu lasen.
Nach einem DBMS welches genauso effizient ist wie herkömmliche relationale DBMS
,darüber hinaus noch eine praxisnähere Modellierung der Daten (z.B. objektorientiert) erlaubt
und (wenigstens teilweise) die Probleme der Datenintegration löst, muss also weiterhin
geforscht werden.
6 Anhang
Teil des GDB OPM Schemas (aus [2])
OBJECT CLASS Amplimer isa* GenomicSegment
ATTRIBUTE isExpressed: [1,1] YesNoUnknown_UnkDict
ATTRIBUTE sequence: list-of [0,] VARCHAR(255)
OBJECT CLASS Chromosome isa* GenomicSegment
ATTRIBUTE cellularCompartment: [1,1] CompartmentDict
OBJECT CLASS CitationLink isa* ExternalLink
ATTRIBUTE dBObjects: set-of [1,] DBObject
OBJECT CLASS DBObjects
ID: accessionID
ATTRIBUTE accessionID: [1,1] VARCHAR(50)
ATTRIBUTE displayName: [1,1] VARCHAR(255)
ATTRIBUTE objectClass: [1,1] VARCHAR(30)
ATTRIBUTE searchName: [1,1] VARCHAR(255)
OBJECT CLASS ExternalLink
ATTRIBUTE displayName: [1,1] VARCHAR(255)
ATTRIBUTE searchName: [1,1] VARCHAR(255)
ATTRIBUTE objectClass: [1,1] VARCHAR(255)
ATTRIBUTE externalDB: [1,1] ExternalDB
ATTRIBUTE accessionID: [1,1] VARCHAR(255)
ATTRIBUTE externalVersion: [0,1] VARCHAR(20)
OBJECT CLASS Gene isa* GenomicSegment
ATTRIBUTE evidence (reason, annotation): set-of [1,]
([1,1] GeneEvidenceDict, [1,1] VARCHAR(255))
ATTRIBUTE families
DERIVATION: ! genes [GeneFamily]
OBJECT CLASS GeneProduct isa* BiologicalObject
ATTRIBUTE sequences
DERIVATION: ! dBObject [SequenceLink]
ATTRIBUTE genes (gene, subunit, nCopies): set-of [0,]
([1,1] Gene, [0,1] VARCHAR(20), [0,1] SMALLINT)
OBJECT CLASS GenomicSegment isa* MappingObject
ATTRIBUTE mapsOf
DERIVATION: ! mapOf [Map]
ATTRIBUTE sequences
DERIVATION: ! dBObject [SequenceLink]
OBJECT CLASS Map isa* MappingObject
ATTRIBUTE chromosome: [1,1] Chromosome
OBJECT CLASS MapElement isa* MappingObject
ATTRIBUTE segment: [1,1] GenomicSegment
ATTRIBUTE map: [1,1] Map
OBJECT CLASS Organism isa* BiologicalObject
ATTRIBUTE taxonomicDescriptions (externalDB, externalAccessionID,
externalVersion): set-of [0,]
([0,1] ExternalDB, [0,1] VARCHAR(255), [0,1] VARCHAR(20))
7 Referenzen
[1]
Chen, I.A. and Markowitz, V.M., An Overview of the Object-Protocol Model (OPM)
and the OPM ata Management Tools. Information Systems, 20(5), pp. 393-418, 1995
[2]
Chen, I.A.; Kosky, A., Markowitz, V.M. and Szeto E., OPM*QS: The Object-Protocol
Model Multidatabase Query System, Technical Report LBL-38181, 1996
[3]
Chen, I.A.; Kosky, A., Markowitz, V.M. and Szeto E., The OPM Query Translator,
Technical Report LBL-38180, 1996
[4]
Chen, I.A. and Markowitz, V.M., Mapping Object-Protocol Schema into Relational
Database Scheams and Queries, Technical Report LBL-33048, 1996
[5]
Chen, I.A. and Markowitz, V.M., OPM Schema Translator 4.1,Technical Report LBL35582, 1996
[6]
Chen, I.A.; Kosky, A., Markowitz, V.M. and Szeto E., Constructing and Maintaining
Scientific Database Views in the Framework of the Object-Protocol Model, Technical
Report LBL-358359, 1997
[7]
Chen, I.A.; Kosky, A. and Markowitz, V.M., Exploring Heterogeneous Molecular
Biology Databases in the Context of the Object-Protocol Model, Theoretical and
Computational Genome Research, Plenum, 1996