Design und Implementierung einer Datenbank für das Projekt ALPiC

Technische Fakultät
Universität Bielefeld
Design und Implementierung
einer Datenbank
für das Projekt ALPiC
Projektleiter: Prof. Dr. Karsten Niehaus
Betreuer: Dr. Dieter Kapp
Dr.-Ing. Frank Zöllner
Dipl. Inform. Marko Tscherepanow
Bachelorarbeit von Sebastian Janowski
15. Juli 2005
Zusammenfassung
Die Bachelorarbeit behandelt das Thema Design und Implementierung einer
”
Datenbank für das Projekt ALPiC“. Die in dieser Bachelorarbeit entwickelte
Datenbank soll in das Laborinformationssystem des Projektes ALPiC integriert werden und die Experimentdaten der Laborversuche verwalten und organisieren. Das Projekt ALPiC ist ein interdisziplinäres Forschungsprojekt,
dessen Ziel es ist, eine automatische Lokalisation von Proteinen in lebenden
Zellen durchzuführen.
In dieser Arbeit wird auf das Projekt ALPiC, sowie auf den Aufbau des
Laborinformationssystems und die dafür entwickelte Datenbank eingegangen. Bei der Implementierung der Datenbank werden die Anforderungen,
das Datenbankdesign, die verwendete Datenbank, sowie der physische Datenbankentwurf und dessen Implementierung vorgestellt.
Neben der Datenbank wurden in dieser Bachelorarbeit Anwendungsprogramme entwickelt, welche eine automatische Datenbankimplementierung
und eine Experimentsuche durchführen. Mit diesen Programmen soll den
Anwendern eine schnelle und mühelose Datenbankimplementierung und Datensuche ermöglicht werden. Weiterhin wurde ein Modul entwickelt, welches
den Laborgeräten und Laborprogrammen zur Kommunikation mit der Datenbank verhilft.
In dieser Arbeit soll der Prozess des Datenbankentwurfs und die dafür
implementierten Programme vorgestellt und erläutert werden.
Inhaltsverzeichnis
1 Einführung
1.1 Das Projekt ALPiC . . . . . . . . . . . . . . . . . . . . . . .
1.2 Ziel der Bachelorarbeit . . . . . . . . . . . . . . . . . . . . . .
1
1
3
2 Laborinformationssysteme
2.1 Grundlegender Aufbau eines Laborinformationssystems . . . .
2.2 Das ALPiC -Laborinformationssystem . . . . . . . . . . . . . .
5
5
7
3 Datenbanken & Datenbankentwurf
9
3.1 Einführung in Datenbanken . . . . . . . . . . . . . . . . . . . 9
3.2 Motivation für eine Datenbank . . . . . . . . . . . . . . . . . . 10
3.3 Datenbankentwurf . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Implementierung einer Datenbank
4.1 Anforderungen . . . . . . . . . .
4.2 Datenbankdesign . . . . . . . . .
4.3 Auswahl einer Datenbank . . . .
4.4 Physischer Datenbankentwurf . .
4.5 Datenbankschnittstellen . . . . .
4.5.1 LabVIEW . . . . . . . . .
4.5.2 DatabaseContentCreator .
4.5.3 ExperimentSearcher . . . .
für das
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Projekt ALPiC
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
5 Zusammenfassung und Ausblick
A Anhang
A.1 ER-Diagramm des Datenbankmodells . . . . . . . . . . . . .
A.2 DDL-Statements für die Datenbankimplementierung . . . . .
A.3 Einbindung von C-Funktionen in LabVIEW . . . . . . . . .
A.4 Technische Details über die Programme ExperimentSearcher
und DatabaseCreator . . . . . . . . . . . . . . . . . . . . . .
Literatur
13
13
14
19
20
22
23
24
25
30
31
. 31
. 32
. 35
. 35
37
1
Einführung
In der Einführung wird das Projekt ALPiC vorgestellt. Neben den Zielen
dieses Forschungsprojektes werden die Methoden für eine Proteinlokalisation
erklärt und erläutert. Im Anschluss werden die Ziele dieser Bachelorarbeit
präsentiert.
1.1
Das Projekt ALPiC
Das Projekt ALPiC Automatic Localisation of the Proteom in Living Cells“
”
ist ein interdisziplinäres Forschungsprojekt der Arbeitsgruppe Angewand”
te Informatik“, Lehrstuhl für Genetik und der Firma Olympus BioSystems
[3]. Ziel dieses Projektes ist die automatische Lokalisation von unbekannten
Proteinen in lebenden Zellen sowie die Entwicklung von Algorithmen und
Methoden zur qualitativen Analyse.
Die Proteinlokalisation spielt eine wichtige Rolle in der Aufklärung der
Proteinfunktion und deren Einordnung in das metabolische System der Zelle.
Es ist im weitesten Sinne nicht möglich, alleine von der DNA-Sequenz auf
die Funktion der Proteine zu schließen. Auch die Proteinstruktur gibt keine
genaue Aussage über die Funktion des Proteins. Das Wissen um die Funktion
eines Proteins, kann wichtige Fragestellungen in der Medizin und Biologie
klären. Die Erkenntnisse können einen wesentlichen Beitrag zur Entwicklung
von neuen Wirkstoffen gegen Krankheiten leisten.
Die Proteomanalytik der Forschungsgruppe ALPiC wird im Labor der
Universität Bielefeld durchgeführt. Die Proteinlokalisation ist ein komplizierter Prozess, der von vielen Faktoren abhängt. Zum Gelingen eines Versuchs,
sind diverse Versuchsschritte notwendig, die exakt auf einander abgestimmt
sein müssen. Im folgenden Abschnitt wird das Prinzip der Proteinlokalisation
beschrieben (siehe Abb. 1).
Durch den Einsatz von Reporterproteinen, konnten Proteinwirkungen
und -wechselwirkungen in ihrem Funktionsumfang eingegrenzt werden. Dabei
werden die Gene der Reporterproteine mit den zu untersuchenden Proteingenen fusioniert. Die Fluoreszenz von Reporterproteinen, wie z.B. dem GFP
(Green Fluorescent Protein), ergab die Möglichkeit, in vivo Untersuchungen
durchzuführen und eine Lokalisation im natürlichen Lebensraum der Zelle.
Abbildung 2 zeigt eine Zelle mit injizierten Fusionsproteinen und die von
den Reporterproteinen ausgehende Fluoreszenz.
Das Einschleusen der zu untersuchenden Proteine und der Reporterproteine, wird mit Hilfe eines Konstrukts realisiert. Bei einem Konstrukt handelt
es sich um einen Vektor (kleiner DNA-Ring), welcher die zu untersuchende DNA gekoppelt mit Reporterproteingenen enthält. Ein Vektor ist ein so
1
Abbildung 1: Eine grafische Darstellung eines typischen Versuchablaufs im
Labor. Die Versuchsdarstellung zeigt die Art und Weise, wie die zu untersuchenden Proteine mit Reporterproteinen fusioniert und in die Zelle transferiert werden. Ergebnis des Versuchs ist die von den Fusionsproteinen ausgehende Fluoreszenz, die unter dem Mikroskop wahrgenommen werden kann.
genanntes Transportvehikel zur Übertragung fremder Nukleinsäure in eine
Empfängerzelle. Durch den Einbau eines fremden Gens in den Vektor wird
ein rekombinantes DNA-Molekül erzeugt, welches sich autonom in der Wirtszelle replizieren kann [2].
Das Einschleusen des Konstrukts in die Wirtszelle kann mit diversen
Methoden durchgeführt werden. In den meisten Fällen ist die Transfektionsmethode der Wahl die Lipofektion [11]. Bei der Lipofektion bilden sich
Lipid-DNA-Komplexe mit denen die Wirtszellen transfiziert werden. Die exprimierten Fusionsproteine können dann anhand der Fluoreszenz lokalisiert
werden.
Zusätzlich kann die Anfärbung von Zellorganellen mit Fluoreszenzfarbstoffen ermöglicht werden. Fluoreszenzfarbstoffe färben spezifisch Organellen an und ermöglichen den Informationsgewinn über Form, Größe, Verteilung und Volumenanteil in dem verwendeten Zellsystem. In Verbindung mit
den Fusionsproteinen, ermöglicht die Anfärbung eine Kolokalisation von angefärbten Organellen und dem zu untersuchenden Fusionsprotein.
Falls nötig oder gewünscht, werden Wirkstoffe in die Zelle injiziert, welche
Einfluss auf die Proteinfunktionen nehmen. Auch das Sichtbarmachen der
Proteine mit Hilfe von Antikörpern, ist ein mögliches Szenario, das nur selten
im Labor praktiziert wird.
2
Abbildung 2: Die Abbildung zeigt eine Zelle mit injizierten Fusionsproteinen.
Anhand der Fluoreszenz kann das zu untersuchende Protein bei der Membran
gefunden werden. Mit dieser Erkenntnis kann die Funktion des Proteins näher
charakterisiert werden.
Die Grundlage für die Proteinlokalisation bilden Zelllinien des asiatischen
Falters Spodoptera frugiperda (SF9). Die Zellen sind wegen ihres optimalen Wachstums, der hohen Transfektionsfähigkeit und Proteinexpression ausgewählt worden.
Eine Automatisierung der Proteomanalytik ist aufgrund des Untersuchungsumfangs im Hinblick auf die Größe einer Genombibliothek unumgänglich. Eine Genombibilothek umfasst zu viele zu untersuchende Proteine, als
dass sie in vollem Umfang ohne automatische Unterstützung untersucht werden könnten. Es ist daher geplant, eine vollautomatisierbare Screeningplattform einzurichten, welche die Proteinlokalisation im Hochdurchsatz durchführt. Dementsprechend steigt im Hochdurchsatz die Anzahl der Experimentdaten und Mikroskopbilder. Zur Verwaltung und Organisation dieser Daten,
ist geplant, eine Datenbank in den Laborbetrieb zu integrieren.
1.2
Ziel der Bachelorarbeit
Das Ziel dieser Arbeit ist die Integration einer Datenbank in den Laborbetrieb. Die Datenbank soll die Verwaltung und Organisation der Experimentdaten unterstützen. Die im Labor entstandenen Experimentdaten sollen in
der Datenbank auf strukturierte Weise gespeichert werden.
Weiterhin war die Implementierung von Algorithmen zur Kommunikation
mit der Datenbank Teil dieser Arbeit. Mit Hilfe dieser Algorithmen, sollen die
in dem Labor benutzten Geräte (Kamera, Mikroskop) ihre anfallenden Expe3
rimentdaten in der Datenbank speichern. Auch die vom Benutzer definierten
Versuchseinstellungen sollen in Verbindung mit den Laborgeräteeinstellungen in dieser gespeichert werden.
Zusätzlich wurde im Rahmen dieser Arbeit ein Benutzerprogramm implementiert, das den Zugriff auf die Experimentdaten ermöglicht. Über die
Programmoberfläche ist dem Benutzer die Möglichkeit gegeben, nach Experimenten in der Datenbank zu suchen. Die Visualisierung eines Experiments
erfolgt über eine grafische Oberfläche. Diese stellt alle relevanten Informationen bezüglich des Experiments und die dazugehörigen Mikroskopbilder
dar.
4
2
Laborinformationssysteme
Im Labor der Forschungsgruppe ALPiC wird für die Proteomanalyse ein Laborinformationssystem eingesetzt, welches die Wissenschaftler bei der Arbeit
unterstützt. Das folgende Kapitel erklärt allgemein, wie ein Laborinformationssystem aufgebaut ist. Im Anschluss wird das Laborinformationssytsem
der ALPiC -Forschungsgruppe und die Komponenten, die in das Laborinformationssystem integriert werden sollen, vorgestellt.
2.1
Grundlegender Aufbau eines Laborinformationssystems
Unter einem Laborinformationssystem (LIM: laboratory information management system) ist ein EDV-System zu verstehen, das die Verwaltung und
Organisation des Laborbetriebs unterstützt. Da die Arbeitsabläufe in jedem
Labor unterschiedlich sein können, kann von vorneherein nicht gesagt werden, welche Aufgaben ein solches System erfüllen muss. Aus diesem Grund
ist auch eine Standardsoftware-Lösung in den meisten Fällen nicht geeignet.
Eine exakte Abbildung des Laborbetriebs kann nur durch eine Individualentwicklung erreicht werden.
Trotz diverser Unterschiede im Aufbau eines solchen Systems, gibt es
einen LIM-Kernbereich, der in den meisten Fällen gleich aussieht (siehe
Abb. 3). Als erstes werden die zu untersuchenden Komponenten ausgewählt.
In einer Experimentplanung wird festgelegt, mit welchen Methoden diese
Komponenten bestimmt und untersucht werden. Im Weiteren werden die
jeweiligen Analyseverfahren den Komponenten zugewiesen. Bei der Untersuchung der Komponenten, unterlaufen diese diversen Analyseschritten. Am
Ende der Untersuchungen, werden die Ergebnisse zusammengefasst und freigegeben.
Neben den oben genannten Aufgaben, können auch Verwaltungsaufgaben in ein LIM integriert werden, wie z.B. die Verwaltung der Laborgeräte
(Kalibrierung, Wartung) oder die Verwaltung der Mitarbeiterdaten.
Um die Effektivität eines LIMs zu steigern, sollte es in der Lage sein, Daten mit anderen EDV-Systemen oder Laborgeräten auf elektronische Weise
auszutauschen. Dieses betrifft z.B. die automatische Datenübernahme von
Analysegeräten, Mikroskopen oder Kameras. Weiterhin ist es von Vorteil,
wenn eine Koppelung mit bestehenden Informationssystemen möglich ist.
LIMs wie die von der Universität Wien, Heidelberg und Stuttgart arbeiten
nach einem bestimmten Grundprinzip. Fast immer ist ein mehrbenutzerfähiges LIM im Einsatz, das mehreren Benutzern ermöglicht, von verschiedenen
Arbeitsplätzen mit dem System zu arbeiten. Weiterhin muss eine jederzeitige
5
Abbildung 3: Trotz Unterschiede im Aufbau eines Laborinformationssystems,
ist das Grundprinzip fast immer gleich. Am Anfang wird ein Experimentplan definiert. Die zu untersuchenden Komponenten werden festgelegt. Anschließend werden den Komponenten Analyseverfahren zugeordnet. Nach der
Durchführung der notwendigen Analyseschritte, werden die Ergebnisse zusammengefasst und freigegeben.
Verfügbarkeit und Sicherheit der Daten gewährleistet werden. Diese Anforderungen legen den Einsatz von Client-Server-Systemen und die Datenverwaltung mittels einer Datenbank nahe.
Ein Client-Server-System besteht aus einem Client, der eine Verbindung
mit einem Server aufbaut. Der Client bietet die Benutzeroberfläche oder die
Benutzerschnittstelle der Anwendung an. Der Server stellt die Funktionalität zur Verfügung. Vorteil eines solchen Systems ist die bessere Nutzung
der Hardware und vor allem, dass auf diese Weise mehrere Benutzer mit
denselben Datenbeständen arbeiten können. Die Datenspeicherung erfolgt
auf dem Server mittels einer Datenbank.
Ein existierendes System, welches die Anforderungen des jetzigen Laborbetriebs in der ALPiC -Forschungsgruppe im weitesten Sinne erfüllt, ist das
Projekt Open Microscopy Enviroment (OME) [9]. Ergebnis des Projekts ist
ein Programmpaket, welches im Zusammenhang mit einer Datenbank, die
Verwaltung und Analyse von Mikroskopbildern und Experimentdaten übernimmt. Ziel dieses Projekts ist es, multidimensionale Mikroskopbilder zu
speichern und zu analysieren. Die Analyse beinhaltet eine Zelllokalisation,
wie auch eine phenotypische Lokalisation. Über die OME-Programme kann
der Benutzer seine Experimente definieren, das Mikroskop entsprechend der
Versuche konfigurieren und anfallende Daten verwalten.
6
Die Architektur basiert auf einem Client-Server-Modell. Die Daten und
Metadaten werden in einer Datenbank auf einem Server gespeichert. Der
Zugriff auf die Daten erfolgt über eine Benutzeroberfläche auf einem Client.
Die Integration dieses Systems in den jetzigen Laborbetrieb hat sich
durchaus schwierig gestaltet. Aufgrund von Portierungsproblemen war es
nicht möglich, die Programmpakete mit dem jetzigen System zu verbinden.
Dementsprechend wurde beschlossen, das momentan eingesetzte Laborinformationssystem durch eine Individualentwicklung zu erweitern.
2.2
Das ALPiC -Laborinformationssystem
Das zurzeit eingesetzte Laborinformationssystem besteht aus einem Mikroskop, gekoppelt mit einer Kamera. Gesteuert werden die Laborgeräte durch
einen zentralen PC, welcher mit Hilfe eines LabVIEW 1 -Programms die Steuerung ermöglicht. Die resultierenden Mikroskopbilder werden in Form von
TIFF-Dateien lokal auf der Festplatte des zentralen PCs gespeichert.
Geplant ist, das jetzige Laborinformationssystem um eine Datenbank und
Pumpe zu erweitern (Abb. 4 zeigt grafisch das geplante Laborinformationssystem). Das Laborinformationssystem soll mehrbenutzerfähig werden und den
permanenten Zugriff auf die Experimentdaten ermöglichen. Für die Erfüllung
dieser Anforderungen ist der Aufbau eines Client-Server-Systems in Verbindung mit einer Datenbank geplant.
In dem erweiterten System sollen alle Laborgeräte durch einen zentralen
PC gesteuert und angesprochen werden. Das LabVIEW -Programm soll neben der Ansteuerung der Laborgeräte dem Benutzer die Möglichkeit geben,
biologische Experimente zu definieren und festzulegen [7]. Zur Definition der
Experimente gehört die Wahl der Einstellungen der Laborgeräte, die Wahl
der im Experiment benutzten biologischen Komponenten und der zeitliche
Ablauf eines Experiments. Diese Einstellungen sollen über das in LabVIEW
geschriebene Anwendungsprogramm vorgenommen werden.
Neben der Kamera und dem Mikroskop soll zusätzlich eine Pumpe in das
Laborinformationssystem integriert werden. Die Aufgabe der Pumpe ist es,
die biologischen Komponenten in den vorgesehenen Volumen in eine Mikrotiterplatte zu pipettieren.
In dem erweiterten System sollen die Funktionen und Aufgaben der Kamera und des Mikroskops unverändert bleiben. Die Kamera soll weiterhin mit
Hilfe des Mikroskops die Expression der Fusionsproteine in der Mikrotiterplatte dokumentieren. Die entstandenen Bilder sollen anschließend in Form
1
LabVIEW ist eine graphische Programmiersprache, die für die Steuerung von technischen Geräten entwickelt wurde [6].
7
Abbildung 4: Eine grafische Darstellung des geplanten ALPiC Laborinformationssystems und der Datenfluß zwischen den einzelnen
Komponenten.
von TIFF-Dateien zurück zum zentralen PC gesendet werden, wo sie lokal
auf der Festplatte gespeichert werden.
Nach Beendigung eines Experiments, soll das LabVIEW -Programm die
Versuchseinstellungen und Laborgeräteeinstellungen in die Datenbank schreiben. Die Bilder sollen durch das LabVIEW -Programm in einen geschützten Bereich der Festplatte verlegt werden, wo sie vor unberechtigtem Zugriff
geschützt sind.
Bei Experimenten soll das LabVIEW -Programm die Planung unterstützen, indem es dem Benutzer Laborgeräteeinstellungen oder Versuchseinstellungen vorschlägt, die in der Datenbank vorhanden sind. Entsprechen
diese Vorschläge den neuen Experimentdefinitionen, sollen diese aus der Datenbank geladen und für ein neues Experiment verwendet werden. Gibt es
keine gespeicherten Einträge, welche für ein neues Experiment benutzt werden können, muss der Benutzer seine Experimentplanung per Hand in der
LabVIEW -Anwenderoberfläche anlegen.
Der Zugriff, die Visualisierung und die Suche von Experimentdaten soll
mittels des Programms ExperimentSearcher auf einem Client geschehen. Der
Zugriff auf die Mikroskopbilder soll mit Hilfe der in der Datenbank gespeicherten Informationen ermöglicht werden. Diese Informationen lassen die
Generierung des Pfades für jedes einzelne Mikroskopbild zu. Somit können
jedem Experiment die passenden Mikroskopbilder zugeordnet werden. Der
Aufruf der Bilder soll über den direkten Pfadzugriff erfolgen.
8
3
Datenbanken & Datenbankentwurf
In diesem Kapitel werden die Vorteile und Motivationen für den Einsatz einer Datenbank beschrieben. Vorab wird erwähnt, was genau eine Datenbank
ausmacht und wie diese arbeitet. Anhand der Anforderungen des ALPiC Laborinformationssystems wird dargestellt, in welchen Bereichen eine Datenbank den Laborbetrieb unterstützen kann. Der grundlegende Datenbankentwurfsprozess wird detailliert am Ende dieses Kapitels beschrieben und
erläutert.
3.1
Einführung in Datenbanken
Datenbanken sind im übertragenen Sinn Aufbewahrungsorte für Informationen. Eine Datenbank hat die Aufgabe, Informationen langfristig und sicher
aufzubewahren. Dabei sollen die Daten in strukturierter Weise gespeichert
werden.
Datenbanken laufen für den Benutzer unsichtbar im Hintergrund. Wenn
Anwender Daten integrieren oder auslesen wollen, geschieht das über ein
Benutzerprogramm, über das der Anwender die Daten eingibt bzw. angezeigt bekommt. Dieses Programm sendet die Daten zur Speicherung an die
Datenbank am Server bzw. holt sie dort ab. Der interne Ablauf einer Datenintegration bleibt dem Anwender verborgen. Die Integration oder das
Herauslesen von Daten kann auch direkt über eine Schnittstelle geschehen.
Meistens benutzen technische Geräte oder Anwendungsprogramme solch eine
Schnittstelle, um ihre Daten in der Datenbank zu speichern oder aus dieser
herauszulesen.
Jede Datenbank verwendet Basisfunktionalitäten, welche die einheitliche
Verwaltung aller Daten, eine Integritätssicherung und eine Datensicherung
garantieren (Basisfunktionalitäten basieren auf den Cood´schen Regeln [1]).
Auch der Zugriff auf die Daten durch mehrere Personen zum selben Zeitpunkt
wird von einem Datenbankmanagementsystem ermöglicht. Wenn gewünscht,
kann der Zugriff auf die gespeicherten Informationen verwehrt und somit
irrtümlicher Veränderung, Zerstörung oder unberechtigtem Zugriff vorgebeugt werden.
Der Zugriff auf die Daten kann durch verschiedene Arten von Programmen geschehen. Dementsprechend werden die Daten in einem Format gespeichert, dass für viele Zugriffsarten offen ist. Die am weitesten verbreitete
Speicherform, ist die Speicherung in Tabellenformen in SQL-Datenbanken.
Die am häufigsten eingesetzten Datenbanken arbeiten nach dem relationalem Modell und stellen für den Zugriff auf die Daten die genormte Sprache
SQL zur Verfügung. Einige bekannte Anbieter relationaler Datenbanksyste9
me sind IBM (Produktname: DB2), Oracle, Microsoft (Produktname: SQL
Server), Sybase (Produktname: SQL Anywhere) und MySQL.
In relationalen Datenbanken werden die Informationen in Form von Tabellen und Relationen gespeichert. Das relationale System unterstützt die
gängigen Datenformate, wie Zahlen und Zeichenketten. Jedoch kann das System keine Multimediadateien effizient speichern und verwalten. Multimediadateien sind komplexe Objekte, die nur von der Anwendung interpretiert
werden können, die diese Dateien auch nutzt. Im relationalen System kann
der Pfad der Datei gespeichert oder aus den gespeicherten Informationen
der Pfad erstellt werden, um eine Verwaltung von komplexen Objekten zu
ermöglichen.
Im Hinblick auf das Problem der Speicherung von Multimediadaten wurden objektrelationale bzw. objektorientierte Datenbanken entwickelt. Diese sind in der Lage komplexe Multimediadaten effizient zu verwalten, ohne
selbst den Inhalt interpretieren zu müssen.
3.2
Motivation für eine Datenbank
Es ist geplant, die Proteomanalyse im Hochdurchsatz durchzuführen. Dementsprechend entstehen viel mehr Daten, als dass es jetzt der Fall ist. Zudem
sollen auch die Einstellungen der Laborgeräte und die Versuchsdurchführung
dokumentiert werden. Diese Daten in Verbindung mit den Mikroskopbildern
müssen sicher und strukturiert gespeichert und verwaltet werden. Die Integration einer Datenbank ist angesichts der geplanten Hochdurchsatzanalyse
und der Anzahl neuer Daten unumgänglich. Es wäre möglich, die Daten weiterhin lokal auf der Festplatte zu speichern. Jedoch wäre die Verwaltung und
Organisation dieser Daten sehr aufwendig. Allein die Suche nach bestimmten
Experimenten würde angesichts der hohen Datenanzahl schwierig ausfallen.
Ein weiteres Problem wäre die Datenredundanz. Die Geräte- und Versuchseinstellungen werden sich nach einer gewissen Zeit wiederholen. Wenn diese
für jedes Experiment mitgespeichert werden, entsteht eine hohe Anzahl von
redundanten Datenbeständen. Mit Hilfe einer Datenbank können bestehende
Einstellungen immer wieder verwendet werden und müssen nicht jedes Mal
neu gespeichert werden.
Weiterhin ist geplant, ein mehrbenutzerfähiges LIM aufzubauen. Ohne
eine Datenbank wäre ein solches Projekt nicht möglich. Der gleichzeitige
Zugriff durch mehrere Benutzer auf gleiche Datenbestände kann sich durchaus schwierig gestalten. Jeder Benutzer müsste sich alle Daten lokal auf die
Festplatte speichern, um auf den gleichen Datenbeständen arbeiten und auf
diese zugreifen zu können. Bei einer Datenbank ermöglicht das Transaktionsmanagement des Datenbankmanagementsystems (DBMS) den Zugriff durch
10
mehrere Benutzer auf die Datenbestände.
3.3
Datenbankentwurf
Der Datenbankentwurfsprozess besteht aus mehreren Phasen (siehe Abb. 5,
[4]). In der ersten Phase werden die Erwartungen der Benutzer sowie die beabsichtigten Nutzungsarten der Datenbank definiert und analysiert. Die Anforderungen jeder Komponente, die mit der Datenbank interagieren soll, muss
in dem Analysevorgang erfasst und analysiert werden. Die Analyse beinhaltet die Transaktionsarten und deren Häufigkeit sowie den Informationsfluss
innerhalb des Systems. Auch die Ein- und Ausgabedaten für die Transaktionen werden spezifiziert. Das Ergebnis dieser Phase ist eine ausführliche und
vollständige Beschreibung der Benutzeranforderungen.
Abbildung 5: In der Abbildung werden die einzelnen Phasen in einem Datenbankentwurfsprozess dargestellt.
In der zweiten Phase wird ein konzeptueller Datenbankentwurf angefertigt. Das Ziel dieser Phase ist die Erstellung eines konzeptuellen Schemas für
die Datenbank, welches unabhängig von einem bestimmten Datenbankmodell
ist. Meistens wird das Schema mit einem ER-Modell (Entity-RelationshipModell) beschrieben. Das ER-Modell beschreibt das konzeptuelle Schema in
Form eines Diagramms. Es ist eine kompakte Beschreibung der Datenanforderungen und beinhaltet ausführliche Beschreibungen der Entitätstypen, Beziehungen und Einschränkungen. Dieses Konzept enthält keine Implementierungsdetails und ist somit leicht zu verstehen. Für die Beschreibung des konzeptuellen Datenbankschemas der ALPiC -Datenbank, wurde ein ER-Modell
aufgestellt.
In der dritten Phase geht es um die Auswahl eines Datenbankmanagementsystems. Die Wahl eines DBMS hängt von mehreren Faktoren ab. Auf
der einen Seite spielen technische Faktoren eine Rolle und auf der anderen
wirtschaftliche.
11
Als erstes muss geprüft werden, ob das ausgewählte DBMS für die Aufgaben geeignet ist. Bei der Wahl des DBMS, sollte entschieden werden, welcher
Datenbanktyp am geeignetsten für die Speicherung der anfallenden Daten ist
(relational, objektrelational oder andere). Auch die verfügbaren Benutzerund Programmierschnittstellen können Einfluss auf die Wahl haben. Weiterhin ist zu prüfen, ob das DBMS einen Client-Server-Betrieb unterstützt und
ob eine Einbindung in andere DBMS möglich ist.
Die wirtschaftlichen Faktoren betreffen z.B. die Software- und Hardwarebeschaffungskosten, sowie Wartungskosten.
In der vierten Phase wird das konzeptuelle Schema aus Phase zwei auf
das Datenbankmodell des gewählten DBMS abgebildet. Das Resultat dieser
Phase sollten DDL-Statements (Data-Definition-Language) in der Sprache
des gewählten DBMS sein.
In der fünften Phase werden die spezifischen Speicherstrukturen und Zugriffspfade für die Datenbank gewählt. Jedes DBMS bietet eine Vielzahl
von Optionen für die Dateiorganisation und Zugriffspfade an. Mit Hilfe dieser Optionen kann Einfluss auf die Reaktionszeit, Speicherplatznutzung und
den Transaktionsdurchsatz genommen werden. Die Optionen beinhalten verschiedene Arten der Indexierung, des Clusterings zusammenhängender Datensätze, wie auch die Verknüpfung zusammenhängender Datensätze über
Zeiger und verschiedene Hashing-Methoden. Das Resultat dieser Phase ist
eine erste Festlegung der Speicherstrukturen und Zugriffspfade auf die Datenbank.
In der letzten Phase wird die Datenbank implementiert, getestet und
schließlich für die Anwendung installiert. Hierbei werden alle Transaktionen
und Anwendungen getestet. Falls es nötig ist, kann in dieser Phase eine Änderung am physischen Datenbankentwurf und der Indexierung durchgeführt
werden.
12
4
Implementierung einer Datenbank für das
Projekt ALPiC
Dieses Kapitel behandelt den Datenbankentwurf und die Implementierung
einer Datenbank für das Projekt ALPiC. Die einzelnen Phasen des Datenbankentwurfs wurden in Kapitel 3 erläutert und erklärt. Im folgenden Kapitel
wird beschrieben, wie der Datenbankentwurf und die Implementierung der
verwendeten Datenbank aussehen.
4.1
Anforderungen
Die Datenbank soll alle relevanten Experimentdaten beinhalten. Zu den relevanten Daten zählen biologische Einstellungen und Komponenten, die technischen Einstellungen der Laborgeräte, der zeitliche Ablauf eines Experiments
und die Resultate in Form von Bildern.
Die Erfassung und Analyse der Anforderungen wurde mittels der jetzigen und geplanten Laborversuche durchgeführt. In der Datenbank sollen alle
biologischen Komponenten, die im Versuch gebraucht wurden gespeichert
werden. Dieses betrifft:
• die InsertDNA in Verbindung mit Accessionnummer, Länge und Herkunftsorganismus
• die benutzten Reportergene
• den Vektor
• das benutzte Konstrukt
• den Versuchsorganismus mit Namen und Stamm
• die benutzte Transfektionsmethode, mit genauem Ablauf, eventuellen
Abweichungen und den genauen Volumina für die verwendeten Komponenten
• eventuelle Zusätze, wie z.B. Farbstoffe, Wirkstoffe oder primäre und
sekundäre Antikörper. Zusätzlich muss für jeden einzelnen Zusatz angegeben werden, in welchen Volumen und wie lange es verwendet wurde.
Bei der Speicherung in die Datenbank, müssen auch die Zusammenhänge
der Komponenten untereinander berücksichtigt werden. So muss vermerkt
werden, wie genau das benutzte Konstrukt aufgebaut ist.
13
Ein Konstrukt besteht aus einem Vektor und einem bzw. mehreren Reportergenen, die mit der InsertDNA fusioniert wurden. Bei der Fusion von
Reportergenen und der InsertDNA wird meistens ein Spacer (kurze funktionslose DNA-Sequenz) zwischen die beiden Komponenten gelegt, damit das
Reportergen die Funktion des zu untersuchenden Proteins nicht beeinflusst.
Diese Informationen müssen für jedes Experiment gespeichert werden.
Zusätzlich sollen der Experimentator, das Datum, die Ziele und die Erkenntnisse gespeichert werden. Falls es einen Folgeversuch gibt, soll dieser in
dem Experiment vermerkt werden.
Neben den biologischen Details eines Experiments, spielen auch die technischen Einstellungen der Kamera und des Mikroskops eine wichtige Rolle.
Bei dem Mikroskop ist die Wahl der richtigen Anregungsfilter, Sperrfilter und
der Objektive für das Gelingen eines qualitativen Bildes ausschlaggebend. Zudem kommen noch die Einstellungen der Lichtquelle. Auch die Kameraeinstellungen, wie z.B. die Belichtungszeit oder das binning 2 sollen gespeichert
werden.
Weiter wird von der Datenbank gefordert, dass sie eine C- und JAVASchnittstelle zur Verfügung stellt. Diese Schnittstellen sollen es anderen Programmen und technischen Geräten ermöglichen, in die Datenbank zu schreiben und aus ihr zu lesen.
4.2
Datenbankdesign
Nachdem die Erfassung und Analyse der Anforderungen abgeschlossen war,
konnte ein erstes Datenmodell erstellt werden. Für die Beschreibung des
Datenmodells wurde ein Entity-Relationship-Model (ER-Modell) aufgestellt.
Das Er-Modell beschreibt das konzeptuelle Schema der Datenbank in Form
eines Diagramms, in dem alle relevanten Informationen als Entitys dargestellt
werden (für das bessere Verständnis des ER-Modells wird anstatt des englischen Begriffs Entity“ der Begriff Objekt“ benutzt). Weiterhin zeigt das
”
”
ER-Modell die Beziehung zwischen den Objekten und deren Eigenschaften.
Folgend wird das Datenbankmodell anhand des ER-Diagramms beschrieben
(das komplette ER-Modell ist im Anhang (A.1) abgebildet).
Das zentrale Objekt im konzeptuellen Schema der Datenbank, ist das
Objekt Versuch“. Das Objekt besitzt die Attribute Datum, Zeit, Ziel und
”
Erkenntnisse. Diese Daten werden mit einem eindeutigen Schlüssel für jedes
Experiment angelegt.
Das Objekt Versuch“ verweist auf weitere Objekte, die das Experiment
”
2
Das Attribut binning legt fest, aus wie vielen Pixel ein Bildpunkt besteht. Diese Einstellung spielt bei der Analyse der Bilddaten eine Rolle.
14
in allen Zügen wiederspiegeln. Abbildung 6 zeigt den grundlegenden Aufbau des Datenbankmodells. Jeder Versuch beinhaltet Daten für die Laborgeräteeinstellungen, die Experimenteinstellungen und eventuell auch Daten
für biologische Zusätze. Wenn nach einem Experiment Folgeversuche durchgeführt werden, verweist das Objekt auf sich selber. Der Folgeversuch wird
als ein normales Experiment in der Datenbank hinterlegt und die Versuchsnummer (ein eindeutiger Schlüssel für das Experiment) wird in dem vorangegangenen Versuch gespeichert. Jedes Experiment kann maximal einen
Folgeversuch haben.
Abbildung 6: Dieses ER-Modell zeigt den grundlegenden Aufbau des Datenbankmodells. Jeder Versuch beinhaltet Informationen über die benutzten
Laboreinstellungen, Experimenteinstellungen, sowie Komponenten und eventuell auch Informationen über biologische Experimentzusätze.
Die Objekte, die die technischen Details wiederspiegeln, sind in Abbildung 7 dargestellt. Im Modell von oben nach unten betrachtet, ist das Objekt
Bildart“ das erste Objekt, auf das Versuch“ verweist. In dem Objekt sind
”
”
alle möglichen Bildarten hinterlegt, welche die Kamera verwenden kann. Zum
Beispiel können das ganz normale Einzelbilder, z-Stapelbilder, Zeitreihenbilder oder andere Bildarten sein. Das Objekt Versuch“ speichert nicht die
”
Bezeichnung des Bildes, sondern immer nur den eindeutigen Schlüssel bil”
dID“, welcher auf die Bezeichnung verweist. Falls kein passender Wert für
das Experiment in dem Objekt hinterlegt ist, muss ein neuer in dem Objekt
angelegt werden.
Für ein Experiment ist immer nur eine Bildart erlaubt. Theoretisch können
die Bildarten während eines Experiments variieren und miteinander kombi15
niert werden. Doch nach Gesprächen mit den biologischen Experten aus der
Forschungsgruppe, konnte dieser Fall ausgeschlossen werden; dieses Szenario
findet im Laborbetrieb nicht statt. Die Bildart wird für jedes Experiment am
Anfang festgelegt, um alle biologischen Reaktionen mit diesen Einstellungen
zu dokumentieren.
Als nächstes verweist das Objekt Versuch“ auf das Objekt Mikrotiter”
”
platte“. Die Referenz auf dieses Objekt zeigt, welche Art von Mikrotiterplatten in diesem Experiment benutzt wurde. Hierbei gilt das gleiche Prinzip
wie bei dem Objekt Bildart“. Es wird lediglich der Schlüssel plattenID“
”
”
gespeichert und nicht die Bezeichnung oder das Format. Da pro Versuch immer nur eine Mikrotiterplatte benutzt wird, gilt die Verbindung auch nur für
eine Referenz.
Die nächste Referenz vom Objekt Versuch“ bezieht sich auf die Einstel”
lungen der Laborgeräte. Von diesem Objekt aus, sind die Objekte Kame”
raeinstellungen“ und Mikroskopeinstellungen“ zu erreichen. Die Verweise
”
auf beide Objekte werden in dem zentralen Objekt Einstellungen“ hinter”
legt. Dieses hat den Vorteil, dass das Objekt Versuch“ nur einen einzigen
”
Schlüssel für das Objekt Einstellungen“ benutzen muss, um auf alle relevan”
ten Einstellungen zugreifen zu können. Anderenfalls müsste in dem Objekt
Versuch“, jeweils ein Schlüssel für das Objekt Kameraeinstellungen“ und
”
”
für das Objekt Mikroskopeinstellungen“ hinterlegt werden.
”
Die Attribute des Objektes Kameraeinstellungen“ beziehen sich auf die
”
Belichtungszeit der Kamera und auf das binning.
In einem Experiment benutzt das Mikroskop verschiedene Anregungsfilter, Sperrfilter und Objektive. Diese Attribute sind in dem Objekt Filter“
”
hinterlegt. In jeder Mikroskopeinstellung kann jeweils von jedem Attribut
nur eins benutzt werden. Eine weitere Referenz von dem Objekt Mikrosko”
peinstellungen“ weist auf das Objekt Lichtquelle“. Hierbei können mehrere
”
Lichtquellen in einem Experiment verwendet werden. Für jede Lichtquelle
muss die Lichtart und die Lichtintensität angegeben werden. Die Referenz
zeigt weiterhin, dass mehr als nur eine Lichtquelle für einen Versuch benutzt
werden darf. Üblich sind max. zwei Lichtquellen. Da aber nicht abzusehen
ist, inwieweit sich die Mikroskoptechnik ändert, gibt es im Datenbankmodell
keine Beschränkungen für die Anzahl der Lichtquellen.
Die Abbildung 7 zeigt auch, dass für jedes Experiment ein Experimentator
mit Namen und Titel angegeben werden muss.
Die biologischen Details werden in Abbildung 8 dargestellt. Die Abbildung zeigt, dass jeder Versuch auf einem bestimmten Organismus ausgeführt
wird. Aus der Referenz wird ersichtlich, aus welcher Familie dieser Organismus stammt und wie dieser bezeichnet wird. Die Referenz zum Objekt
Transfektion“ enthält alle relevanten Informationen zu den benutzten Kom”
16
Abbildung 7: Dieses ER-Modell zeigt, wie und wo die technischen Einstellungen für die Laborgeräte hinterlegt werden.
ponenten und dem Transfektionsablauf. Für den Transfektionsablauf wurde
ein eigenes Objekt angelegt. In dem Objekt Transfektionsmethode“ werden
”
alle durchgeführten Transfektionsmethoden notiert. Die genaue Bezeichnung,
der genaue Versuchsablauf und eventuelle Abweichungen sind in diesem Objekt enthalten. Mit Hilfe des eindeutigem Schlüssels methodenID“ kann für
”
jedes Experiment festgelegt werden, welche Methode in diesem Experiment
verwendet wurde. Falls diese Methode noch nicht in der Datenbank vorhanden ist, muss diese neu angelegt werden.
Bei einer Transfektion wird ein Konstrukt in die Zelle injiziert. Dieser
Sachverhalt wird durch die Referenz vom Objekt Transfektion“ zum Objekt
”
Konstrukt“ verdeutlicht. Das Konstrukt beinhaltet alle nötigen Informatio”
nen zur Beschreibung des eingesetzten Konstrukts. Es verweist zum Vektor,
zu den Reportergenen und zur InsertDNA. Jedes Konstrukt darf nur aus
einem Vektor bestehen.
Ein Konstrukt enthält mindestens ein Reportergen. Es kann aber auch
mehrere enthalten. In der Regel werden aber maximal zwei Reportergene eingesetzt. Eine wichtige Referenz ist die vom Objekt Reportergen“ zum Ob”
jekt InsertDNA“. Diese Verbindung besagt, auf welche Weise das Reporter”
gen mit der InsertDNA fusioniert wurde. Es kann auf drei verschiedene Arten
fusioniert sein. Es ist entweder N- oder C-terminal mit der InsertDNA fusio17
niert, oder es liegt in der InsertDNA. Zudem ist auch die Anzahl der Spacer
wichtig, die zwischen dem Reportergen und der InsertDNA liegen. All diese
Informationen werden mit Hilfe dieser Abhängigkeit angegeben. Als letztes
verweist das Konstrukt auf die InsertDNA. Durch diese Referenz wird für jeden Versuch definiert, welche InsertDNA in diesem Versuch benutzt wurde.
Es muss die Accessionnummer und die Länge des Inserts angegeben werden
und aus welchem Organismus die zu untersuchende DNA stammt.
Abbildung 8: Dieses ER-Modell zeigt die Objekte, die die biologischen Experimentinformationen enthalten.
Der dritte und letzte große Abschnitt auf den das Objekt Versuch verweisen kann, bezieht sich auf die Experimentzusätze (siehe Abb. 9). Ein Versuch
kann biologische Zusätze enthalten. Falls es Zusätze enthält, beziehen sich die
Referenzen entweder auf das Objekt Farbstoffe“, das Objekt Wirkstoffe“
”
”
oder auf das Objekt Antikörper“. In der Erfassung der Anforderungen wur”
de beschlossen, dass bei einem Versuch nur ein Farbstoff verwendet werden
darf. Bei dem Farbstoff muss angegeben werden, in welchem Volumen dieser eingesetzt wurde und wie lange dieser in der Zelle aktiv war. Dieses gilt
auch für die Wirkstoffe. Zusätzlich können die zu untersuchenden Proteine mit Antikörpern detektiert werden. Für diesen Fall wurde das Objekt
primäre Antikörper“ angelegt. Wenn eine Referenz vom Objekt Versuch“
”
”
auf das Objekt primäre Antikörper“ besteht, muss angegeben werden, in
”
18
welchem Volumen es eingesetzt wurde. Auch die Wirkungsdauer muss angegeben werden. Weil eine Antikörperdetektion nicht ohne sekundäre Antikörper funktioniert, verweist das Objekt primäre Antikörper“ auf das Ob”
jekt sekundäre Antikörper“. Diese Abhängigkeit zeigt, dass durchaus mehre”
re sekundäre Antikörper mit dem primären Antikörper interagieren können.
Eigentlich müssten noch die Signalmoleküle mit angegeben werden, welche
mit den sekundären Antikörpern gekoppelt sind. Jedoch wurde in der Analyse
der Anforderung beschlossen, kein zusätzliches Objekt für die Signalmoleküle
anzulegen. Aus der Bezeichnung des sekundären Antikörpers kann auf das
Signalmolekül geschlossen werden.
Abbildung 9: Dieses ER-Modell zeigt alle Objekte, die die biologischen
Zusätze betreffen.
4.3
Auswahl einer Datenbank
Als Datenbankmanagementsystem wurde MySQL gewählt. Es ist geplant,
ein mehrbenutzerfähiges LIM mittels eines Client-Server-Modells aufzubauen. MySQL unterstützt dieses Modell und bietet mehreren Benutzern die
Möglichkeit, auf gleichen Datenbeständen zu arbeiten. Es kann auf verschiedenen Arten von Plattformen eingesetzt werden, wie z.B. Windows, Linux
und Solaris. MySQL kann laut Herstellerangabe [8] eine hohe Anzahl von
Datenbeständen verwalten. Für den Hochdurchsatz im Labor, ist dies eines
der wichtigsten Kriterien. Das MySQL-DBMS bietet für jede unterstützte
Programmiersprache Schnittstellen an, mit denen es möglich ist, mit der Datenbank zu kommunizieren. Somit kann LabVIEW mittels der in dieser Ar19
beit entwickelten Algorithmen eine Verbindung zur Datenbank aufbauen. Das
Benutzerprogramm ExperimentSearcher für die Experimentsuche kann dieses mittels der JDBC-Schnittstelle tun. Ein weiterer Grund für die Wahl des
MySQL-Programmpackets, ist die freie Verfügbarkeit dieser Software. MySQL ist ein kostenloses und stabiles Open-Source-Programm. Es ist leicht
zu verstehen und für die Integration des Systems in das LIM, muss keine
zusätzliche Hardware beschafft werden.
MySQL ist ein relationales System. In dem Kapitel Einführung in Daten”
banken“ wurde erwähnt, dass relationale Datenbanken nur normale Datentypen wie Zahlen und Zeichenketten verwalten können. Komplexe Objekte,
wie die im Labor aufgenommen Bilder, stellen ein Problem dar. Diese können
in der Datenbank nicht verwaltet werden. Dieses Problem wird gelöst, indem
der Zugriff und Aufruf der Bilder auf andere Weise realisiert wird. Anhand
von Experimentinformationen in der Datenbank wird ein Pfad für das Verzeichnis generiert, in dem die Bilder liegen. Anwenderprogramme können
dann mittels des Pfades auf die Bilder zugreifen.
Die Bilder werden in einem geschützten Bereich der Festplatte gespeichert, wo sie vor unberechtigtem Zugriff geschützt sind. Die Speicherung
erfolgt mittels einer Baumstruktur. Der oberste Knoten dieses Baumes ist
das Jahr. Folgend kommen der Monat, der Tag und der Experimentator. Als
letzter Knoten wird ein Verzeichnis mit dem eindeutigen Schlüssel für das
Experiment angelegt. Jedes Experimentbild wird in dieser Baumstruktur gespeichert.
Ein Versuch soll mit Datum, Experimentator und vielen weiteren Informationen in der Datenbank gespeichert werden. Während der Speicherung
wird jedem Versuch ein eindeutiger Schlüssel zugewiesen. Diese Informationen ermöglichen die Rekonstruktion der Bildpfade. Somit können jedem Experiment die richtigen Bilder zugeordnet werden.
4.4
Physischer Datenbankentwurf
Nachdem ein konzeptuelles Datenbankschema aufgebaut wurde, konnte der
Datenbankentwurf mittels Tabellen und Abhängigkeiten realisiert werden.
Die Tabellen für das relationale Schema wurden nach den folgenden vier
Richtlinien entworfen [4].
1. Ein Relationsschema ist so zu entwerfen, dass sich seine Bedeutung
leicht erklären lässt. Es sollen keine Attribute aus mehreren Entitätstypen und Relationstypen kombiniert werden.
2. Ein Relationsschema ist so zu entwerfen, dass in den Relationen keine
Einfügungs-, Lösch- oder Modifikationsanomalien auftreten.
20
3. Es sollten so weit wie möglich, null-Werte in den Relationen vermieden
werden. Um null-Werte in den Relationen zu vermeiden, wurden z. B.
die Farbstoffe aus der Tabelle Versuch“ entfernt. Da nur in unter 7%
”
der Versuche Farbstoffe einem Experiment zugefügt werden, wurde eine
zusätzliche Tabelle angelegt. Diese gibt Auskunft über die Farbstoffzugabe. Somit wird vermieden, dass bei 93% der Versuche ein null-Wert
gespeichert wird. Dieser Sachverhalt gilt auch für die primären Antikörper und Folgeversuche.
4. Es dürfen durch Verbundoperationen keine unechten Tupel entstehen.
Die entstandenen Tabellen wurden mit Hilfe einer Normalisierung verfeinert. Ziel einer Normalisierung ist die Vermeidung von Redundanzen durch
Aufspalten der Relationsschemata. Bei der Normalisierung dürfen keine semantischen Informationen verloren gehen.
In der ersten Normalform wurden für alle nicht atomaren und mehrwertigen Attribute eigene Tabellen angelegt. Nicht atomare Attribute sind mehrere Tupel in einer Tabelle. Dies betrifft z. B. die Tabelle primäre Antikörper“.
”
Primäre Antikörper können mit mehreren sekundären Antikörpern gekoppelt
sein. Dementsprechend können in der Tabelle primäre Antikörper“ mehre”
re Tupel für sekundäre Antikörper vorhanden sein. Durch eine zusätzliche
Tabelle für die primären und sekundären Antikörper, wird dieses Problem
gelöst.
Mit Hilfe der zweiten Normalform wurden partielle Abhängigkeiten zwischen Schlüsseln des Relationsschemas und weiteren Attributen verhindert.
Mittels der dritten Normalform wurden die transitiven Normalformen
eliminiert. So wurde z.B. in der Tabelle Wirkstoffe“ die Proportionierung
”
in ein neues Relationsschema verlagert und der Schlüssel propID“ in die
”
Tabelle Wirkstoffe kopiert. Eigentlich müssten die transitiv abhängigen Attribute aus der Tabelle Mikroskopeinstellungen auch in eine eigene Tabelle
verlagert werden. Jedoch ist die mögliche Anzahl von Mikroskopeinstellungen begrenzt. Es lohnt sich nicht, aus der Tabelle drei einzelne zu erstellen.
Die Verbundoperationen für das Zusammenfügen der Einstellungen würden
mehr Aufwand bereiten, als das Beibehalten dieser Tabelle.
Theoretisch könnten die Relationsschemata noch weiter normalisiert werden. Jedoch wird in der Regel nach der dritten Normalform aufgehört, um
viele kleine Tabellen zu vermeiden. Deshalb wurde auch in diesem Fall auf
die Normalisierung mittels der vierten Normalform verzichtet.
Nachdem die Relationsschemata erstellt wurden, konnten DDLs-Statements (Data-Definition-Language) für das MySQL System aufgestellt werden
[10]. DDL-Statements beschreiben, wie genau ein Relationsschema aufgebaut
21
ist und welche Besonderheiten es aufweist. Alle Tabellen wurden analysiert
und entsprechend deren Anforderungen, spezifische DDL-Statements erstellt.
Als Beispiel wird die DLL für das Relationsschema Wirkstoffe“ beschrie”
ben und erklärt.
• create table Wirkstoffe(wirkID int unsigned not null auto increment,
primary key (wirkID), bezeichnung varchar(30) not null,propID int unsigned not null, foreign key (propID) references Proportionierung (propID);
Jedes mal, wenn ein neuer Wirkstoff in das Relationsschema integriert
wird, wird dieser mit einem eindeutigen Schlüssel versehen. Der Schlüssel
wird automatisch durch MySQL verliehen und darf nicht fehlen. Bei der Bezeichnung der Wirkstoffe, wird ein Speicher für 30 Zeichen zur Verfügung
gestellt. Weiterhin wird gefordert, dass ein Wirkstoff eine Bezeichnung zugewiesen bekommt. Dieses Tupel darf nicht leer sein. Als letztes Tupel muss
die Proportionierung für den Wirkstoff angegeben werden. Dabei wird auf
die Tabelle Proportionierung“ verwiesen. Mittels dem Fremdschlüssel pro”
”
pID“ kann in der Tabelle Proportionierung“ auf die richtigen Volumina zu”
gegriffen werden. Bei jedem Tupel in der Tabelle wird festgelegt, aus was
für Datentypen dieser bestehen soll. Zum Beispiel sind beim Tupel für den
eindeutigen Schlüssel propID“ nur positive Zahlen erlaubt.
”
Jedes Relationsschema hat seine eigenen Anforderungen und Besonderheiten, mit denen die Integration von falschen Werten verhindert werden soll.
Alle benutzten DDL-Statements sind im Anhang (A.2) aufgelistet.
Im nächsten Schritt sollten die Datenbankimplementierung und das Datenbank-Tuning stattfinden. Leider konnte diese Phase während der Bachelorarbeit aus zeitlichen Gründen nicht mehr ausgeführt werden. Sie wird jedoch
nach der Bachelorarbeit ausgeführt.
4.5
Datenbankschnittstellen
Zur Implementierung von Anwendungen, verfügen Datenbanken im Allgemeinen über mindestens eine Programmierschnittstelle, die als eine Bibliothek von Datenstrukturen und Funktionen zur Verfügung gestellt wird. Diese
Funktionen ermöglichen die Kommunikation mit dem Datenbanksystem, die
Definition und Ausführung von Anfragen, sowie die Verarbeitung von Ergebnissen.
Die MySQL-Datenbank bietet für jede unterstützte Programmiersprache Bibliotheken an, die die Kommunikation mit der Datenbank ermöglichen. Für die in dieser Bachelorarbeit implementierten Programme, waren
22
die Schnittstellen für die Programmiersprache C und Java von Relevanz.
Das LabVIEW -Programm soll mittels der C-Schnittstelle und die Programme, für die Implementierung der Datenbank und für die Experimentsuche,
mittels der JAVA-Schnittstelle (JDBC) mit der Datenbank kommunizieren.
4.5.1
LabVIEW
Der SQL/CLI-Standard definiert eine Datenbankschnittstelle für verschiedene Programmiersprachen, so u.a. auch für die Programmiersprache C. In C
wurden Funktionen geschrieben, welches LabVIEW den Zugriff auf die Datenbank ermöglicht. Die in LabVIEW geschriebene Benutzeroberfläche für
die Experimentplanung kann mittels dieser Funktionen, Daten in die Datenbank schreiben oder herauslesen. Das Modul stellt folgenden Funktionen zur
Verfügung:
1. void init connect();
2. char* query(char *tupel, char *table, char *join);
3. void insert(char *table, char *attributes, char *column);
4. void update(char *update table, char *attrib to change, char *new value,
char *term attrib, char *term attrib value);
5. void disconnect();
Die erste Funktion ermöglicht den Aufbau einer Verbindung zur Datenbank. Der Name der Datenbank, des Anwenders und dessen Passwort,
werden intern in der Funktion festgelegt. Um eine Verbindung mit der Datenbank herzustellen, muss LabVIEW lediglich diese Funktion aufrufen. Die
Verbindung wird mittels der im Quellcode gesetzten Attribute und den SQLConnect-Funktionen hergestellt.
Die zweite Funktion ermöglicht das Herauslesen von Daten aus der Datenbank. Als erstes Argument muss das Tupel angegeben werden, welches
herausgelesen werden soll. Bei dem ersten Argument können mehrere Werte in Form des Datentyps String übergeben werden. Diese müssen lediglich
durch ein Komma getrennt sein. Als zweites Argument muss die Tabelle angegeben werden, welche das Tupel beinhaltet. Mit dem dritten und letzten
Argument wird festgelegt, welche zwei Tabellen miteinander verbunden werden sollen. Das dritte Argument muss eine Verbundoperation in Form von
einer Zeichenkette sein. Der Verbund einer Tabelle hat den Vorteil, dass alle
gewünschten Attribute aus einer Tabelle gelesen werden können, anstatt sie
23
aus mehreren Tabellen zu generieren. Somit muss die Funktion nur einmal
aufgerufen werden. Das Resultat wird als Datentyp String zurückgegeben.
Die dritte Funktion ermöglicht die Integration von Daten in die Datenbank. Bei der Nutzung dieser Funktion muss als erstes die Tabelle angegeben
werden, in welche die Daten integriert werden sollen. Das zweite Attribut erwartet die zu integrierenden Daten. Es kann aus einem oder auch mehreren
Werten bestehen. Wenn es mehrere Werte sind, die integriert werden sollen,
müssen diese jeweils durch ein Komma getrennt sein. Für das dritte und letzte Argument muss die Spalte, bzw. die Spalten angegeben werden, in welche
die Attribute integriert werden sollen.
Die vierte Funktion ermöglicht die Aktualisierung von Attributen in der
Datenbank. Für die Aktualisierung eines Attributes sind mehrere Argumente
nötig. Das erste Argument legt die Tabelle fest, in der das Attribut aktualisiert werden soll. Das zweite und dritte Argument legen die Spalte und
dessen neuen Inhalt fest. Die Bedingung für die Aktualisierung wird durch
das vierte und fünfte Argument festgelegt. Für alle Tupel in der gewählten
Tabelle, die die Bedingung erfüllen, werden die neuen Werte gesetzt.
Die fünfte und letzte Funktion schließt die Verbindung zur Datenbank.
Bei allen Funktionen ist eine Fehlerabfrage eingebaut. Falls aus unersichtlichen Gründen eine Funktion nicht korrekt ausgeführt wird, wird der Fehler
aufgefangen und in Form von einer SQL-Fehlermeldung wiedergeben. Diese Fehlermeldung gibt den genauen Grund für die misslungene Ausführung
wieder. Die Fehlerabfrage ermöglicht eine erfolgreiche Transaktion oder einen
erfolgreichen Abbruch. Ein erfolgreicher Abbruch sollte die Eigenschaft besitzen, dass keine Spuren von misslungenen Transaktionen in der Datenbank
hinterlassen werden.
Informationen und Anleitungen zur Anbindung der C-Funktionen in LabVIEW sind dem Anhang (A.3) zu entnehmen.
4.5.2
DatabaseContentCreator
Mit Hilfe des Programms DatabaseContentCreator (DCC) wird die in dieser
Bachelorarbeit entwickelte Datenbank implementiert. Für eine erfolgreiche
Implementierung ist es notwendig, dass auf dem vorgesehenen Server mindestens eine MySQL-Version 4.1 installiert ist.
Das Programm stellt eine grafische Oberfläche zur Verfügung, die dem Benutzer ermöglicht, die Datenbank mit dem entwickelten konzeptuellen Schema auf einen beliebigen Server anzulegen. Jedoch muss der Benutzer die
nötigen Rechte besitzen, um die Datenbank in MySQL anlegen zu dürfen.
Der Benutzer muss sich mit Namen und Passwort anmelden. Zusätzlich
muss er den Ort angeben (host), wo die Datenbank implementiert werden soll.
24
Sind diese Angaben korrekt, kann der Benutzer mit dem von ihm gewählten
Datenbanknamen die Datenbank anlegen. Falls Probleme während der Implementierung auftreten, werden die Fehler auf der grafischen Oberfläche dargestellt. Bei der Fehlerwidergabe des Programms wird die SQL-Fehlermeldung
dargestellt.
Nach erfolgreicher Implementierung der Datenbank können Benutzer angelegt werden. Für das Anlegen eines Benutzers muss dessen Name, sein
Passwort und der Ort (host) angegeben werden, von dem aus er auf die Datenbank zugreifen will. Bei der Rechtevergabe können zwei Optionen gewählt
werden. Entweder der Benutzer kriegt alle zur Verfügung stehenden Rechte (MySQL-Anweisung: grant all ) oder nur Leserechte (MySQL-Anweisung:
grant select). Zumindest ein Benutzer sollte alle Rechte erlangen. Falls nötig,
können mit dem Zugang dieses Benutzers Modifikationen an der Datenbank
ausgeführt werden.
Informationen über technischen Details sind dem Anhang (A.4) zu entnehmen.
4.5.3
ExperimentSearcher
Für die Suche von Experimentdaten in der Datenbank wurde das Programm
ExperimentSearcher entwickelt. Das Anwendungsprogramm bietet dem Benutzer die Möglichkeit, über eine grafische Oberfläche nach Experimenten
zu suchen und diese darzustellen. Bei der Suche nach Experimenten in der
Datenbank kann der Benutzer seine Suche spezifizieren, indem er Kriterien
angibt, welche das Experiment erfüllen muss. Zum Beispiel kann der Benutzer angeben, dass nur die Experimente angezeigt werden sollen, welche vom
Experimentator Karsten Niehaus“ getätigt und auf dem Versuchsorganis”
mus E. coli“ durchgeführt wurden. Bei der Angabe der Kriterien, die das
”
Experiment erfüllen muss, hilft das Programm dem Benutzer einen korrekten
Wert für das Suchkriterium auszuwählen. Beim Starten des Programms werden für jedes Suchkriterium alle vorkommenden Werte aus der Datenbank
gelesen. So werden z.B. für das Suchkriterium Experimentator“ alle Expe”
rimentatoren aus der Datenbank gelesen, die ein Experiment durchgeführt
haben. Während des Eintippens des Experimentatorennamens durchsucht
das Programm jeden aus der Datenbank gelesenen Experimentatorennamen
auf das Vorkommen der bisher eingetippten Zeichenkette. Wird diese Zeichenkette in einem Namen gefunden, wird dieser als Vorschlag angezeigt.
Falls einer der Vorschläge dem vorgesehenen Namen entspricht, kann dieser
mit der Maus oder der Tastatur ausgewählt werden. Wird ein Wert eingetippt, der mit keinem Wert aus der Datenbank übereinstimmt, wird das Feld
rot markiert. Eine Suche kann erst dann wieder erfolgen, wenn dieses Feld
25
einen korrekten Wert enthält. Dadurch wird verhindert, dass vom Anwender
Werte eingetragen werden, die auf kein Experiment zutreffen können.
Anspruchsvollere Suchanfragen können mit Hilfe des QueryCreators durchgeführt werden. Das Aufrufen des QueryCreators erfolgt durch die Funktionstaste F1. Dabei muss der Eingabezeiger der Tastatur in dem Textfeld
sein, auf welches sich der QueryCreator beziehen soll. Ist der Eingabezeiger
in dem Textfeld Reportergene“ und die Funktionstaste F1 wird betätigt,
”
öffnet sich der QueryCreator für das Suchkriterium Reportergene“. In dem
”
QueryCreator können die Werte mit den boolschen Operatoren AND, NOT
und OR beliebig verknüpft werden. Zum Beispiel kann der Benutzer angeben, dass nur Experimente angezeigt werden sollen, welche das Reportergen
GFP oder YFP benutzt haben.
Für jedes Suchkriterium werden nur die boolschen Operatoren zur Verfügung gestellt, welche auch Sinn machen. Für das Kriterium Reporterpro”
teine“ werden die boolschen Operatoren AND, NOT und OR angeboten. Ein
Versuch kann ein oder mehrere Reporterproteine verwenden. Deswegen steht
auch der AND-Operator zur Verfügung. Beim Suchkriterium Experimen”
tator“ ist das nicht der Fall. Ein Experiment kann immer nur durch einen
Experimentator durchgeführt werden, weshalb auch der AND-Operator hier
keinen Sinn macht.
Das Feld Versuch/e“ ermöglicht den Zugriff auf ein Experiment mittels
”
seines eindeutigen Schlüssels. Falls der Versuch 23 gesehen werden möchte,
muss in diesem Feld die 23 eingetippt werden. Bei dem Zugriff auf mehrere
Experimente, müssen die Schlüssel durch ein Komma getrennt sein.
Wenn alle Suchkriterien festgelegt wurden, generiert das Programm anhand der eingegeben Suchkriterien eine komplexe SQL-Anfrage, welche die
passenden Experimente in der Datenbank sucht. Bei der SQL-Anfrage handelt es sich um eine verschachtelte Anfrage mit Mengenvergleichen [10]. Es
wird lediglich eine Anfrage getätigt, die alle Suchkriterien beinhaltet. Die
SQL-Anfrage besteht, abhängig von den Suchkriterien, aus einer gewissen
Anzahl von SubQuerys, die von innen nach außen abgearbeitet werden. Wenn
eine SubQuery bzw. die Query keine entsprechenden Werte findet, wird die
SQL-Anfrage beendet.
Experimente, welche den Suchkriterien entsprechen, werden in Form einer
Liste dargestellt. In dieser Liste sind alle wichtigen Informationen zum Experiment enthalten. Dem Benutzer ist an dieser Stelle die Möglichkeit gegeben,
bis zu maximal 17 Experimente darzustellen. Mittels des select all“-Knopfs
”
können alle Experimente ausgewählt werden. Einzelne Experimente können
mit Hilfe der Maus und der Funktionstaste STRG“ ausgewählt werden. Falls
”
keins der Experimente den Erwartungen entspricht, kann auf die Suchmaske
zurückgekehrt werden, um die Suchkriterien zu verändern.
26
Bei der Visualisierung der Experimentdaten, werden alle Informationen
aus der Datenbank gelesen. Diese Informationen werden auf vier Feldern dargestellt (siehe Abb. 10). Auf dem ersten Feld sind die biologischen Details
dargestellt. Hier stehen die benutzten Komponenten, die Transfektionsmethode, die Ziele, Erkenntnisse und weitere Details. Die Erkenntnisse kann
der Benutzer eintragen oder aktualisieren, indem er die Funktionstaste F1
betätigt. Es erscheint ein Textfeld, in dem der Benutzer seine Erkenntnisse eintragen bzw. verändern kann. Tut er dies, werden die Daten sofort zur
Datenbank gesendet, wo der Eintrag aktualisiert wird.
Im zweiten Feld sind die technischen Details abgebildet. Hier werden die
Informationen über die benutzten Laborgeräteeinstellungen dargestellt.
Im dritten Feld, wird das eingesetzte Konstrukt grafisch dargestellt. Für
die Darstellung des Bildes, werden die Informationen über die InsertDNA,
die Reportergene, Spacer und den Vektor verwendet. Eine JAVA-Klasse baut
mit Hilfe dieser Informationen eine Grafik auf. Die Grafik zeigt, wie genau
das Konstrukt aufgebaut ist. Es stellt die Fusionsart der zu untersuchenden
Proteingene mit den Reportergenen und Spacern dar, sowie deren Position
im Vektor.
Das vierte Feld visualisiert die im Versuch gemachten Bilder. Mit Hilfe
des JAI-Packets (Java Advanced Imaging) ist Java in der Lage, TIFF-Bilder
zu öffnen und zu visualisieren. Die im Feld dargestellten Bilder sind nur eine
Vorschau auf das eigentliche Bild. Die Bilder sind soweit runterskaliert, dass
sie in dem Feld abgebildet werden können. Mit einem Mausklick auf den
increase“-Knopf, wird das Bild in Originalgröße und Auflösung dargestellt.
”
Bei mehreren Bildern für ein Experiment, können durch das Betätigen der
next“- und previous“-Knöpfe diese angezeigt werden.
”
”
Die Bilder werden aus dem geschützten Verzeichnis geladen. Dabei generiert das Programm den Pfad des Verzeichnisses, wo die Bilder zum angewählten Experiment liegen. Die Generierung des Pfades erfolgt durch das
Datum, den Experimentator und den eindeutigen Schlüssel des Experiments.
Die Bilder werden durch das LabVIEW -Programm anhand einer Baumstruktur in dem Verzeichnis gespeichert. Der oberste Knoten dieser Baumstruktur ist das Jahr, eine Ebene tiefer folgt der Monat. Eine weitere Ebene
tiefer, folgt der Tag. Auf diese Ebene folgt der Experimentator und als letztes
der Schlüssel des Experiments. In dem Verzeichnis sind alle Bilder hinterlegt,
welche in dem jeweiligen Experiment aufgenommen wurden.
Mit Hilfe des save“-Knopfs kann der Experimentator die Bilder und eine
”
Textdatei mit allen Informationen zum Experiment an einem beliebigen Ort
seiner Wahl speichern. Die Textdatei wird von einer JAVA-Klasse erstellt,
welche alle Informationen aus der Datenbank liest und diese als .txt-Datei
speichert. Der Name der Textdatei ist immer der Schlüssel des Experiments.
27
Abbildung 10: Diese Abbildung zeigt die Experimentdarstellung im Programm ExperimentSearcher. Wenn mehrere Experimente dargestellt werden,
sind die in Form von so genannten Tabs organisiert. Tabs sind übereinanderliegende Ebenen, die durch Reiter angewählt werden können. Auf der
obersten Leiste der grafischen Oberfläche sind vier Knöpfe angelegt. Jeder
Knopf ermöglicht die Darstellung bestimmter Experimentinformationen. In
dieser Darstellung ist der Knopf Bilder“ angewählt. Auf dieser Ebene werden
”
die im Experiment gemachten Bilder skaliert dargestellt. Mittels der Knöpfe
next“ und previous“ können alle Bilder betrachtet werden. Mit dem in”
”
”
crease“-Knopf werden die Bilder in Orginalgröße dargestellt. Mit dem sa”
ve“-Knopf können die Experimentinformationen und Bilder an einem Ort
der Wahl gespeichert werden. Der back“-Knopf ermöglicht die Rückkehr
”
zur Experimentauswahl. Der new search“-Knopf stellt die Oberfläche für
”
die Experimentsuche dar. Der quit“-Knopf beendet das Programm und die
”
Verbindung mit der Datenbank.
28
Informationen über technischen Details sind dem Anhang (A.4) zu entnehmen.
29
5
Zusammenfassung und Ausblick
Die Grundlagen für die Integration einer Datenbank in das Laborinformationssystem wurden in dieser Bachelorabeit geschaffen. Im nächsten Schritt
gilt es die Datenbank im Labor ausführlich zu testen und eventuelle Modifikationen an der Datenbank auszuführen. Das erweiterte LIM muss ausführlichen Tests unterzogen werden, um die Qualität der Daten zu gewährleisten.
Bei allen Komponenten, die mit der Datenbank kommunizieren, muss der
Datenfluss analysiert und untersucht werden.
Bei dem Anwendungsprogramm ExperimentSearcher handelt es sich um
eine erste Testversion. Diese kann noch beliebig erweitert werden. Zum Beispiel wäre es möglich, die Bilddarstellung für mehrere TIFF-Bilder zu realisieren, die als eine TIFF-Datei gespeichert sind. Bis jetzt liest das Programm immer nur das erste TIFF-Bild aus so einer Datei. Zudem könnte
das Programm die Hardwarebeschleunigung der Grafikkarte ausnutzen, um
eine schnellere Darstellung der Bilder zu ermöglichen. Auch die Anbindung
an das Internet wäre vorstellbar.
Für die bessere Konfiguration des Programms könnte ein so genanntes
Setup-Fenster eingebaut werden, welches dem Benutzer über eine grafische
Oberfläche ermöglicht, die Datenbankverbindung zu konfigurieren.
30
A
A.1
Anhang
ER-Diagramm des Datenbankmodells
31
A.2
DDL-Statements für die Datenbankimplementierung
• create table Proportionierung (propID int unsigned not null auto increment, primary key (propID), volumen int unsigned not null, dauer
int unsigned not null);
• create table PrimAntikoerper(primAntiID int unsigned not null auto increment, primary key (primAntiID), bezeichnung varchar(30) not
null, propID int unsigned not null, foreign key (propID) references Proportionierung (propID));
• create table SekAntikoerper(sekAntiID int unsigned not null auto increment, primary key (sekAntiID), bezeichnung varchar(30) not null,
propID int unsigned not null, foreign key (propID) references Proportionierung (propID));
• create table PrimSekAntikoerper(primAntiID int unsigned not null, sekAntiID int unsigned not null, foreign key (primAntiID) references PrimAntikoerper (primAntiID), foreign key (sekAntiID) references SekAntikoerper(sekAntiID));
• create table Farbstoffe(farbID int unsigned not null auto increment,
primary key (farbID), bezeichnung varchar(30) not null,propID int unsigned not null, foreign key (propID) references Proportionierung (propID));
• create table Wirkstoffe(wirkID int unsigned not null auto increment,
primary key (wirkID), bezeichnung varchar(30) not null,propID int unsigned not null, foreign key (propID) references Proportionierung (propID);
• create table Transfektionsmethode(methodenID int unsigned not null
auto increment, primary key (methodenID), bezeichnung varchar(30)
not null, Ablauf mediumblob, Abweichungen blob);
• create table Vector(vecID int unsigned not null auto increment, primary key (vecID), bezeichnung varchar(30) not null);
• create table Reportergen(repID int unsigned not null auto increment,
primary key (repID), bezeichnung varchar(30) not null);
• create table Organismus(orgID int unsigned not null auto increment,
primary key (orgID), name varchar(30) not null);
32
• create table InsertDNA(insertID int unsigned not null auto increment,
primary key (insertID), accessionnr varchar(30) not null, laenge int
unsigned not null, orgID int unsigned not null, foreign key (orgID)
references Organismus (orgID));
• create table Fusionsart(fusID int unsigned not null auto increment, primary key (fusID), position enum(’n-terminal’,’c-terminal’,’inside’) not
null, spacer int);
• create table Konstrukt( KonstruktID int unsigned not null auto increment, primary key (KonstruktID), bezeichnung varchar(30) not null,
vecID int unsigned not null, insertID int unsigned not null, foreign
key (vecID) references Vector (vecID), foreign key (insertID) references
InsertDNA (insertID));
• create table KonstruktReportergen(KonstruktID int unsigned not null,
repID int unsigned not null, position int unsigned not null, fusID int unsigned not null, foreign key (KonstruktID) references Konstrukt (KonstruktID), foreign key (fusID) references Fusionsart (fusID), foreign key
(repID) references Reportergen (repID));
• create table Mikrotiterplatte(plattenID int unsigned not null auto increment, primary key (plattenID), format varchar(30) not null, bezeichnung varchar(30) not null);
• create table Kameraeinstellungen(kameraID int unsigned not null auto increment, primary key (kameraID), belichtungszeit int unsigned not
null, binning int unsigned not null);
• create table Mikroskopeinstellungen( mikroskopID int unsigned not
null auto increment, primary key (mikroskopID), objektiv varchar(30)
not null,anregungsfilter varchar(30) not null, sperrfilter varchar(30) not
null);
• create table Lichtquelle(lichtquelleID int unsigned not null auto increment, primary key (lichtquelleID), lichtintensitaet int unsigned not
null, lichtart varchar(30) not null);
• create table MikroskopLicht(mikroskopID int unsigned not null, lichtquelleID int unsigned not null, foreign key (mikroskopID) references
Mikroskopeinstellungen (mikroskopID), foreign key (lichtquelleID) references Lichtquellen(lichtquelleID));
33
• create table status(statusID int unsigned not null auto increment, primary key (statusID), titel varchar(30) not null);
• create table experimentator(expID int unsigned not null auto increment,
primary key (expID), name varchar(30) not null, statusID int unsigned
not null, foreign key (statusID) references status (statusID));
• create table bilder(bildID int unsigned not null auto increment, primary key (bildID), bezeichnung varchar(30) not null);
• create table versuch(versuchID int unsigned not null auto increment,
primary key (versuchID), Datum DATE not null, Zeit TIME not null,
ziel blob, erkenntnisse mediumblob, expID int unsigned not null, foreign
key (expID) references experimentator (expID));
• create table Versuchbiomittel(versuchID int unsigned not null, foreign
key (versuchid) references versuch (versuchid), wirkID int unsigned,
foreign key (wirkid) references wirkstoffe (wirkid), konstruktID int unsigned not null, foreign key (konstruktid) references konstrukt (konstruktid), orgID int unsigned not null, foreign key (orgid) references
organismus (orgid), methodenID int unsigned not null, foreign key (methodenid) references transfektionsmethode (methodenid));
• create table Versuchseinstellungen(versuchID int unsigned not null, foreign key (versuchid) references versuch (versuchid), bildID int unsigned
not null , foreign key (bildId) references bilder (bildid), plattenID int
unsigned not null, foreign key (plattenid) references Mikrotiterplatte
(plattenid), kameraID int unsigned not null, foreign key (kameraid)
references Kameraeinstellungen (kameraid), mikroskopID int unsigned
not null, foreign key (mikroskopid) references Mikroskopeinstellungen
(mikroskopid));
• create table FolgeVersuch(versuchID int unsigned not null, folgeversuchID int unsigned not null, foreign key (versuchID) references versuch
(versuchID), foreign key (folgeversuchID) references versuch(versuchID));
• create table VersuchAntikoerper( versuchID int unsigned not null, primAntiID int unsigned not null, foreign key (primAntiID) references
PrimAntikoerper (primAntiID), foreign key (versuchID) references versuch(versuchID));
• create table VersuchFarbstoffe(versuchID int unsigned not null, farbID
int unsigned not null, foreign key (farbID) references farbstoffe (farbID), foreign key (versuchID) references versuch(versuchID));
34
A.3
Einbindung von C-Funktionen in LabVIEW
Für die Einbindung von C-Funktionen in LabVIEW muss der Quellcode als
DLL (Dynamic Link Library) kompiliert werden. Für das Erstellen einer
DLL-Datei, muss der zu kompilierende Code als C++ Datei gespeichert werden. Beim kompilieren wird aus diesen Dateien ein Objekt erstellt, welches
mit dem LabVIEW-Programm interagieren kann. Zum Kompilieren wurde
das Programm Borland C++ Version 5.02 benutzt. Die Wahl fiel auf diesen
Compiler, weil dieser empfohlen wurde [5] und zudem frei verfügbar ist.
Vor jeder Funktion im Quellcode muß die Deklaration extern C declspec
”
(dllexport)“ gesetzt werden. Diese Deklarationen teilen LabVIEW mit, dass
die Funktionen aus einer externen Quelle Daten erhalten. Die externe Quelle
ist in diesem Fall die MySQL Datenbank.
Für die Kommunikation mit der Datenbank muss zusätzlich die Bibliothek libmysql.lib eingebunden werden. Alle externen Bibliotheken müssen mit
genauem Pfad angegeben werden. Weiterhin muss der Pfad für die Bibliotheken CINTOOLS in LabVIEW eingebunden werden. Mit dieser Bibliothek
kann der Compiler eine DLL erzeugen, die in LabVIEW genutzt werden kann.
Wurde eine DLL-Datei erfolgreich erzeugt, kann diese in LabVIEW eingebunden und die Funktionen genutzt werden.
A.4
Technische Details über die Programme ExperimentSearcher und DatabaseCreator
Beide Programme wurden in der Programmiersprache Java entwickelt und
sind theoretisch systemunabhängig. Sie können von jeder Plattform aus als
.jar-Datei ausgeführt werden, soweit die JAVA-Virtual-Machine auf dieser
installiert ist. Für den Zugriff auf die Datenbank benutzen die Programme
die Java JDBC“-Schnittstelle (Java Database Connectivity).
”
35
Danksagung
Hiermit möchte ich mich bei allen bedanken, die mich während meiner Bachelorarbeit betreut haben. Ich möchte Prof. Dr. Karsten Niehaus, Dr. Dieter
Kapp, Dr.-Ing. Frank Zöllner und Dipl. Inform. Marko Tscherepanow für die
Anregungen zu dieser Arbeit und für die wissenschaftliche Beratung während
ihrer Entstehung aufrichtig danken.
Auch meinem Freund Maik Tiemann ist zu danken, mit dem ich über
wichtige Themen der Bachelorarbeit diskutieren konnte und welcher das
Büroleben um einiges angenehmer gemacht hat.
Vor allem möchte ich meiner Mutter danken, die mich während der Bachelorarbeit rundum versorgt hat. Weiterhin danke ich ganz herzlich meiner
Freundin Irene Braun und meinen sehr guten Freunden Nils Rasche und Ferdi
Ünal, für die professionelle und ausdauernde Korrektur meiner Arbeit.
Eidesstattliche Erklärung
Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit selbständig
verfasst und keine anderen Quellen und Hilfsmittel als die angegebenen benutzt habe.
Sebastian Janowski
15. Juli 2005
36
Literatur
[1] Andreas Heuer, Gunter Saake, Kai-Uwe Sattler. Datenbanken Kompakt.
mitp-Verlag Bonn, 2. Auflage 2003
[2] Bruce Alberts, Alexander Johnson [et al.]. Molecular Biology of the Cell.
Garland Science, 4. Auflage 2002
[3] Das Projekt ALPiC ( Automatic Localisation of the Proteom in Living
”
Cells“) http://www.techfak.uni-bielefeld.de/ags/ai/projects/ALPiC/
[4] Elmasri Navathe. Grundlagen von Datenbanksystemen.
Pearson Studium, 3. Auflage 2002
[5] Judith Stevens-Lemoine. C von A bis Z.
Galileo Press GmbH, 1. Auflage 2003
[6] LabVIEW Homepage
http://www.ni.com/LabVIEW/d/
[7] Maik Tiemann. Bachelorarbeit Thema: Erstellung eines digitalen Experimentplans zur Analyse von Fluoreszenz-Mikroskopiebilder.
Universität Bielefeld, voraussichtliche Abgabe: 15.7.2005
[8] MySQL Homepage http://www.mysql.de/
[9] Open Microscopy Environment (OME)
http://www.openmicroscopy.org/
[10] Paul DuBois. MySQL.
New Riders, 2. Auflage 2003
[11] Robert-André Roszik. Diplomarbeit Thema: Etablierung eines
Mikroskopie-Systems zur automatisierten Lokalisierung von Zellstrukturen.
Universität Bielefeld, Januar 2005
37