Plasmid Database

Plasmid Database
Plasmid Database
Diplomarbeit
DA_21_0607
Diplomanden:
Chantal Isler
Carla Santoro
Auftraggeber:
Dr. Frederic J. Hoerndli
Dr. Bernhard M. Kohli
Betreuender Dozent:
Prof. Bernhard C. Wyss
Januar 2007
Muttenz
Fachhochschule Nordwestschweiz
Hochschule für Technik
Studiengang Informatik
Hofackerstrasse 73
CH-4132 Muttenz
T: +41 61 467 44 44
F: +41 61 467 44 62
www.fhnw.ch
Abstract
Diese Dokumentation fasst die Erkenntnisse aus der Diplomarbeit "Plasmid Database"
zusammen. Das Ziel der von uns entwickelten Software ist die Vereinfachung der Arbeit mit
Plasmiden.
Plasmide sind ringförmige DNA-Sequenzen, welche in der Forschung verwendet werden.
Die Zeit für Neukonstruktion, Überprüfung oder Suche nach Plasmiden soll durch diese
Software eingespart werden.
User können ihre elektronischen Sequenzinformationen zusammen mit ihrer Email-Adresse
in einer Datenbank abspeichern. Sie haben die Möglichkeit, Eigenschaften oder Sequenzen
zu suchen und eine Anfrage an die betreffenden Autoren, welche für den User aus
Datenschutzgründen unbekannt bleiben, zu senden.
Auf der Clientseite wurde eine GUI (Graphical User Interface) in Form einer Webpage
programmiert, mit der man die verschiedensten Funktionalitäten ausführen kann.
Die Plasmidinformationen können mittels Formular manuell wie auch automatisch
eingegeben werden. Die Sequenz wird als Texteingabe oder als Datei der Datenbank
übergeben. Anhand verschiedener Kriterien (Feature, Name, Sequenz etc.) kann nach den
Plasmiden gesucht werden. Die Suchkriterien können mittels Konjunktion und Disjunktion
verknüpft werden. Zudem kann auch mittels eines Algorithmus (BLAST) aus der
Bioinformatik nach Sequenzen gesucht werden.
Liegt ein erfolgreiches Ergebnis vor, kann das Plasmid mit einer automatischen Anfrage an
den Lieferanten bestellt werden. Um die Plasmide gut beurteilen zu können, muss ein
Besteller in jedem Fall ein Feedback ausfüllen.
Um den Usern die Arbeit zu erleichtern, können die Detailinformationen als PDF-Dokument
ausgedruckt werden. Zu jeder Seite steht ein Hilfedokument zur Verfügung.
Auf der Serverseite wurden verschiedene Dienste implementiert, welche automatisch oder
nach Eingaben des Users aufgerufen werden.
Bei einem Upload mehrerer Dateien läuft nach dem Absenden des Formulars im
Hintergrund ein Programm, welches die Features zu den soeben hochgeladenen
Plasmiden erkennt und in die Datenbank einträgt.
Ein Cronjob ermittelt täglich die Features der Plasmide und trägt diese in die Datenbank
ein. Ein weiterer Cronjob erinnert den Besteller nach zwei Monaten ab Bestelldatum ans
Ausfüllen des Feedbacks.
Die Suche mit dem BLAST-Algorithmus erfolgt mit Hilfe von Shell-Skripten. Damit ein
Lieferant sein Plasmid nicht mehrmals versenden muss, werden die Lieferanten
automatisch aus der Tabelle „Bestellung“ generiert, so dass Plasmide maximal fünf Mal von
derselben Person verschickt werden müssen.
Nebst diesen Diensten ist auf der Serverseite auch die MySQL-Open-Source-Datenbank
ein wichtiger Bestandteil. Das Datenbankdesign wurde so erstellt, dass keine überflüssigen
Abfragen entstehen, die Tabellen keine redundante Felder aufweisen und die Performance
gut ist. Die Datenbank enthält alle notwendigen Informationen.
Danksagung
Wir möchten zuerst Herrn Prof. Bernhard C. Wyss für die hervorragende Betreuung
während der Diplomarbeit danken. Er schenkte unserer Arbeit grosses Interesse und viel
Zeit. Er war immer verfügbar, wenn wir uns mit Problemen konfrontiert sahen und stand
uns mit Rat und Tat zur Seite.
Auch unseren Auftraggebern und Experten Dr. Frederic J. Hoerndli und Dr. Bernhard M.
Kohli sind wir dankbar. Sie ermöglichten uns mit ihrem Auftrag eine interessante
Diplomarbeit und haben uns mit ihrem Engagement immer wieder von Neuem angespornt.
Weiter möchten wir uns bei unseren Freunden und Familien für das Verständnis bedanken,
das sie uns während des gesamten Studiums, besonders aber in den letzten Wochen,
entgegengebracht haben.
Im Speziellen möchten wir uns bei Dominik, Boris, Laurent, Marc, Martin, Natascha, Tobias
und Patrick für die tatkräftige Unterstützung bedanken.
Inhalt
1
EINLEITUNG .......................................................................................9
2
DEFINITIONSPHASE ........................................................................10
2.1
Auftraggeber ................................................................................................................10
2.2
Begleitender Dozent....................................................................................................10
2.3 Ausgangslage ..............................................................................................................10
2.3.1 Biologie ...................................................................................................................10
2.3.2 Bioinformatik...........................................................................................................11
2.3.3 DNA ........................................................................................................................11
2.3.4 Plasmide.................................................................................................................11
2.3.4.1 Anwendungsbeispiele.....................................................................................12
2.3.4.2 Features ..........................................................................................................12
2.3.4.3 Herstellung ......................................................................................................12
2.4
Auftrag ..........................................................................................................................13
2.5 Anforderungen.............................................................................................................15
2.5.1 Plasmidverwaltung.................................................................................................15
2.5.2 Design.....................................................................................................................15
2.6
Anwendungsfalldiagramm .........................................................................................16
2.7
Beschreibung der Aktoren.........................................................................................17
2.8
Beschreibung der einzelnen Use Cases ..................................................................17
2.9
Ziel .................................................................................................................................24
2.10
Projektplan .................................................................................................................24
3
KONZEPTPHASE..............................................................................29
3.1 Technologien ...............................................................................................................29
3.1.1 Bedarfsanalyse ......................................................................................................29
3.1.1.1 MySQL versus PostgreSQL ...........................................................................29
3.1.1.2 MySQL ............................................................................................................31
3.1.1.3 Vergleich zwischen MyISAM und InnoDB .....................................................33
3.1.1.4 InnoDB ............................................................................................................34
3.1.1.5 PHP4 versus PHP5 ........................................................................................34
3.1.1.6 PhpMyAdmin...................................................................................................34
3.1.2 PHPUnit..................................................................................................................35
3.1.3 Entscheidungen .....................................................................................................35
3.2 Softwaredesign............................................................................................................35
3.2.1 ER-Modell...............................................................................................................36
3.2.2 Workflow.................................................................................................................39
3.3
Homepagedesign ........................................................................................................41
3.4 Iterationsphasen der Use Cases ...............................................................................41
3.4.1 Iterationsphase 1....................................................................................................42
3.4.1.1 Use Case 1: Login ..........................................................................................42
3.4.1.2 Use Case 2: Registrierung .............................................................................43
3.4.1.3 Use Case 3: Registrierung löschen ...............................................................43
3.4.1.4 Use Case 4: Forschungsgruppe anmelden...................................................43
3.4.1.5 Use Case 5: EULA..........................................................................................43
3.4.1.6 Use Case 6: Passwort vergessen..................................................................43
3.4.1.7 Use Case 7: Passwort ändern .......................................................................43
3.4.1.8 Use Case 8: Home .........................................................................................44
3.4.1.9 Use Case 9: Logout........................................................................................44
3.4.2 Iterationsphase 2....................................................................................................44
3.4.2.1 Use Case 10: Manuelle Eingabe ...................................................................44
3.4.2.2 Use Case 11: Search .....................................................................................44
3.4.2.3 Use Case 12: Search Result Form ................................................................44
3.4.3 Iterationsphase 3....................................................................................................45
3.4.3.1 Use Case 13: Plasmid Detail Form................................................................45
3.4.3.2 Use Case 14: Bestellung Plasmid..................................................................45
3.4.3.3 Use Case 15: Login für Feedback .................................................................45
3.4.3.4 Use Case 16: Feedback.................................................................................45
3.4.4 Iterationsphase 4....................................................................................................46
3.4.4.1 Use Case 17: Enter Automatic.......................................................................46
3.4.4.2 Use Case 18: Change Plasmid......................................................................46
3.4.4.3 Use Case 19: Copyright .................................................................................46
3.4.4.4 Use Case 20: Help..........................................................................................46
3.4.4.5 Use Case 21: FAQ..........................................................................................46
3.4.5 Iterationsphase 5....................................................................................................47
3.4.5.1 Use Case 22: Blast.........................................................................................47
4
REALISIERUNGSPHASE .................................................................48
4.1
Softwaredesign............................................................................................................48
4.2
Programmierrichtlinien...............................................................................................49
4.3 Implementation ............................................................................................................50
4.3.1 Iterationsphase 1....................................................................................................50
4.3.1.1 Use Case 1: Login ..........................................................................................50
4.3.1.2 Use Case 2: Registrierung .............................................................................50
4.3.1.3 Use Case 3: Registrierung löschen ...............................................................50
4.3.1.4 Use Case 4: Forschungsgruppe anmelden...................................................50
4.3.1.5 Use Case 5: EULA..........................................................................................50
4.3.1.6 Use Case 6: Passwort vergessen..................................................................51
4.3.1.7 Use Case 7: Passwort ändern .......................................................................51
4.3.1.8 Use Case 8: Home .........................................................................................51
4.3.1.9 Use Case 9: Logout........................................................................................51
4.3.2 Iterationsphase 2....................................................................................................51
4.3.2.1 Use Case 10: Manuelle Eingabe ...................................................................51
4.3.2.2 Use Case 11: Search .....................................................................................52
4.3.2.3 Use Case 12: Search Result Form ................................................................53
4.3.3 Iterationsphase 3....................................................................................................53
4.3.3.1 Use Case 13: Plasmid Detail Form................................................................53
4.3.3.2 Use Case 14: Bestellung Plasmid..................................................................54
4.3.3.3 Use Case 15: Login für Feedback .................................................................54
4.3.3.4 Use Case 16: Feedback.................................................................................55
4.3.4 Iterationsphase 4....................................................................................................55
4.3.4.1 Use Case 17: Enter Automatic.......................................................................55
4.3.4.2 Use Case 18: Change Plasmid......................................................................56
4.3.4.3 Use Case 19: Copyright .................................................................................56
4.3.4.4 Use Case 20: Help..........................................................................................56
4.3.4.5 Use Case 21: FAQ..........................................................................................56
4.3.5 Iterationsphase 5....................................................................................................57
4.3.5.1 Use Case 22: BLAST .....................................................................................57
4.3.6 Crontab ...................................................................................................................58
4.4
Sicherheit......................................................................................................................58
4.5
Refactoring...................................................................................................................58
4.6 BLAST ...........................................................................................................................58
4.6.1 Programme.............................................................................................................59
4.6.2 Vorbereitung...........................................................................................................59
4.6.3 BLAST Algorithmus................................................................................................60
4.6.4 Alternativen zu BLAST...........................................................................................60
4.6.5 Performance und Tuning der Datenbank..............................................................62
4.6.5.1 Query-Performance ........................................................................................62
4.6.5.2 Tuning .............................................................................................................63
4.7
Server FGCZ.................................................................................................................63
4.8 Backup ..........................................................................................................................64
4.8.1 Grundlegende Begriffe...........................................................................................64
4.8.1.1 Disaster Recovery ..........................................................................................64
4.8.1.2 Auditierung ......................................................................................................64
4.8.2 Art und Weise.........................................................................................................64
4.8.2.1 Dump...............................................................................................................64
4.8.2.2 Binlog ..............................................................................................................64
4.8.2.3 Roh-Backup ....................................................................................................65
4.8.2.4 Online / Offline ................................................................................................65
4.8.3 Techniken ...............................................................................................................65
4.8.3.1 Online / mysqldump........................................................................................65
4.8.3.2 Offline / Binär-Backup aller Dateien erstellen ...............................................66
4.8.4 Testen.....................................................................................................................66
4.9 Testphase .....................................................................................................................67
4.9.1 Testfälle ..................................................................................................................67
4.9.2 Lasttest ...................................................................................................................67
4.9.3 Testergebnis...........................................................................................................68
4.10 Herausforderungen...................................................................................................68
4.10.1 BLAST ..................................................................................................................68
4.10.2 Datenbank ............................................................................................................68
4.11
5
Probleme ....................................................................................................................68
FAZIT UND AUSBLICK.....................................................................70
5.1 Weiterführung durch das FGCZ ................................................................................70
5.1.1 Forum .....................................................................................................................70
5.1.2 R-Tree-Indizes........................................................................................................70
5.1.3 Die Storage Engine................................................................................................71
5.1.4 Alignment................................................................................................................71
6
QUELLENVERZEICHNIS..................................................................72
6.1 Abbildungsverzeichnis...............................................................................................72
6.1.1 Grafiken ..................................................................................................................72
6.1.2
6.2
Tabellen..................................................................................................................72
Bibliographie................................................................................................................73
7
GLOSSAR .........................................................................................74
8
ANHANG ...........................................................................................78
8.1
Auftrag ..........................................................................................................................78
8.2
Benutzerhandbuch......................................................................................................78
8.3
Lizenz ............................................................................................................................78
8.4
Pflichtenheft .................................................................................................................78
8.5
Dokumente der Testphase .........................................................................................78
8.6
Protokolle der Sitzungen............................................................................................78
8.7
Wochenberichte...........................................................................................................78
8.8
Zeitplan .........................................................................................................................78
8.9
CD-ROM mit Source-Code .........................................................................................78
1
Einleitung
Diese Dokumentation behandelt die Bereiche, mit denen wir uns während der Diplomarbeit
auseinander gesetzt haben.
Kapitel 2 dieses Berichts fasst die Definitionsphase zusammen und zeigt auf, was die
Ausgangslage war, welchen Auftrag wir erhalten haben und was das Ziel unserer
Diplomarbeit war.
Kapitel 3 geht detailliert auf die Konzeptphase ein, welche mittels verschiedenen
Diagrammen dargestellt werden.
Kapitel 4 beschreibt die Realisierungsphase mit den Ergebnissen, Herausforderungen und
Problemen.
Die nachfolgenden Kapitel enthalten Fazit und Ausblick, Quellenverzeichnis, Glossar und
einen umfassenden Anhang.
Diese Dokumentation beinhaltet wenig Quellcode. Wir haben uns darauf beschränkt, die für
uns wichtigen Stellen herauszugreifen und den gesamten Quellcode auf der beigefügten
CD im Anhang zur Verfügung zu stellen.
FHNW
Plasmid Database
9
2
Definitionsphase
2.1
Auftraggeber
Auftraggeber für unsere Diplomarbeit waren Dr. Frederic J. Hoerndli und Dr. Bernhard M.
Kohli. Dr. Hoerndli fokussiert sich in Kollaboration mit dem Zoologischen Institut der
Universität Zürich auf die Gedächtnisforschung und Dr. Kohli arbeitet im ManagementBeratungsunternehmen Bain & Company.
2.2
Begleitender Dozent
Als begleitender Dozent stand uns Herr Prof. Bernhard C. Wyss vom Studiengang
Informatik der Fachhochschule Nordwestschweiz zur Seite. Er hält die Vorlesungen
„Database System“ und „Database Engineering“.
2.3
Ausgangslage
Bis heute gibt es noch keinen Prozess, Plasmid-Sequenzen von Grund auf herzustellen.
Um die Ausgangslage genauer zu beschreiben, erfolgt ein Einblick in die Biologie.
2.3.1
Biologie
Die Biologie wird als die Lehre vom Leben zusammengefasst. Sie umschreibt sowohl die
Wechselwirkungen zwischen einzelnen Spezies und Populationen, wie auch Funktionen
von Organen und Zellen in Organismen. Um diese „Geheimnisse des Lebens“1 zu
verstehen, sammeln Biologen jede Menge Daten. Die technischen Möglichkeiten im Labor
sind heute so gut, dass mehr Daten gewonnen, als ausgewertet werden können.
Eine der Herausforderungen eines Biologen besteht darin, herauszufinden, welche
Abschnitte der DNA für die chemischen Prozesse in einem Organismus zuständig sind.
Weitere Informationen zur DNA und ihren Aufbau finden sie in Kapitel 2.3.3.
1
Zitat: Cynthia Gibas & Per Jambeck, „Biologie im Computerzeitalter“, S. 3, Einführung in die praktische
Bioinformatik, 2002, O’Reilly.
FHNW
Plasmid Database
10
2.3.2
Bioinformatik
Die Bioinformatik ist eine Wissenschaft, die mit informatischen und mathematischen
Konzepten versucht, die Biologie zu erklären. Die angewandte Bioinformatik befasst sich
mit der Anwendung dieser Konzepte, um biologische Forschung zu beschleunigen und zu
verbessern. Wichtige Bereiche sind die Molekularbiologie, Biochemie, Medizin und Chemie.
Die theoretische Bioinformatik verwendet Datenbanken, Algorithmen und Programme um
die grossen Mengen biologischer Daten schneller zu verarbeiten. Die Informatik stellt dabei
den Kerninhalt dar.
2.3.3
DNA
Die Desoxyribonukleinsäure (DNS oder englisch DNA) ist der Träger der Erbinformation.
Die funktionellen Informationen eines Organismus sind in ihr, der RNA und in Proteinen
gespeichert. Diese drei Bestandteile bestehen aus langen Ketten, die aus kleinen
Molekülen aufgebaut sind.
Die DNA besteht aus vier Makromolekülen, den Desoxyribonukleotiden. Nukleotide sind
aus drei Bestandteilen aufgebaut: einer Phosphorsäure, einem Zucker (Monosaccharid)
und einer der vier Nukleobasen (Adenin, Guanin, Cytosin und Thymin).
Die DNA besitzt eine leiterartige Struktur in der jeweils zwei gegenläufige Nukleotidstränge
miteinander kombinieren. Dabei sind die Basen so zueinander orientiert, dass
Wasserstoffbrückenbindungen gebildet werden. Zwei Bindungen entstehen zwischen der
Paarung A – T und drei Bindungen zwischen G – C. Die beiden Stränge sind
dementsprechend komplementär und liegen als eine gedrehte Doppelhelix vor. Um sich
einen Eindruck der Grösse zu machen folgen ein paar Kennzahlen2:
Der Durchmesser der Doppelhelix beträgt 2 nm. Entlang der Doppelhelix sind
gegenüberliegenden Basen 0.34 nm voneinander entfernt und in einem Winkel von 36°
zueinander gedreht. Die helikale Struktur wiederholt sich alle 3,4 nm, was 10 Basenpaaren
entspricht.
2.3.4
Plasmide3
Plasmide sind geschlossene DNA-Stränge, die unabhängig vom normalen Erbgut einer
Zelle vervielfältigt und unterhalten werden können. Die Sequenzinformationen können
Protein-Baupläne kodieren, die von der Zelle „abgelesen“ und in Proteine umgesetzt
werden können. Sie definiert jedoch auch andere Eigenschaften von Plasmiden, zum
Beispiel wie oft sie innerhalb einer Zelle kopiert werden oder in welchen Zellen und Spezies
letztlich die enthaltenen Baupläne umgesetzt werden.
Kennzahlen stammen aus: Dr. Paul M. Selzer, Richard J. Marhöfer und Dr. Andreas Rohwer, „Die biologischen
Grundlagen der Bioinformatik“, S. 35, Angewandte Bioinformatik, 2004, Springer-Verlag
3
2.3.4 wurde zusammengefasst und geht aus einer Beschreibung von Dr. Bernhard Kohli, Auftraggeber der
Plasmid Database, hervor
2
FHNW
Plasmid Database
11
2.3.4.1 Anwendungsbeispiele
Da Plasmide unabhängig vom Erbgut der untersuchten Zellen sind, kann man sie dazu
verwenden, Proteine mit veränderten Eigenschaften oder aus anderen Organismen in einer
Zelle zu untersuchen.
Zum Beispiel könnte man genau beobachten, wie sich eine Nervenzelle verhält, wenn man
ihr ein Protein verabreicht, das bei der Alzheimerschen Krankheit eine Rolle spielt, oder in
einer Krebszelle den Einfluss eines Proteins untersuchen, welches das Wachstum von
Zellen kontrolliert. Neuerdings kann man spezielle Plasmide auch dazu verwenden, die
Funktion von Proteinen zu hemmen, womit man herausfinden kann, wofür ein Protein in
einer Zelle unter normalen Umständen verantwortlich ist. Plasmide werden jedoch nicht nur
in der reinen Forschung angewandt, denn man kann auch Bakterien oder Hefe dazu
bringen, wie eine Fabrik ein bestimmtes Protein herzustellen. Auf diese Art kann
beispielsweise Insulin gentechnisch hergestellt werden, nachdem es früher aufwendig aus
den Bauchspeicheldrüsen von Tieren gewonnen werden musste.
2.3.4.2 Features
Damit Plasmide praktisch genutzt werden können, enthalten sie neben dem Hauptelement
(Bauplan für ein Protein) zusätzliche Sequenzen, die man als Features bezeichnen kann.
Eine Datenbank wird nie sämtliche Features vollständig abbilden können, doch einige sind
sehr häufig und fallen in folgende Bereiche:
•
regulatorische Elemente: diese Sequenzen definieren, unter welchen Bedingungen
und in welchen Zellen das Hauptprotein produziert wird, oder wie oft ein Plasmid in
einem Bakterium vervielfältigt wird (High Copy Number).
•
Fluoreszenz-Tags: diese Sequenzen wurden ursprünglich aus leuchtenden Quallen
isoliert. Sie dienen dazu, an Proteine ein kleines leuchtendes Protein anzuhängen,
was es unter dem Mikroskop sichtbar macht. Ohne diese Fluoreszenz wären
Proteine viel zu klein, um sichtbar zu sein. Somit kann man beispielsweise
beobachten, wo sich ein Protein innerhalb der Zelle ansammelt, zum Beispiel im
Zellkern.
•
Aufreinigungs-Tags: diese kurzen Proteinfragmente besitzen besondere chemische
Eigenschaften, die es ermöglichen, das Hauptprotein aus einer Mischung von vielen
Proteinen heraus aufzureinigen. Insulin aus Bakterien muss man beispielsweise
zuerst sehr gut aufreinigen, bis man es für Patienten verwenden kann.
•
Rekombinations-Sequenzen: solche Sequenzen ermöglichen die technische
Verknüpfung von verschiedensten Plasmiden, um solche mit neuen Eigenschaften
zu entwickeln.
2.3.4.3 Herstellung
Wie bereits oben erwähnt, gibt es bis heute noch keinen Prozess, der eine PlasmidSequenz von Grund auf herstellen kann, weil dazu eine unglaublich komplexe chemische
Synthese notwendig wäre. Man stückelt deshalb Plasmide aus bestehenden zusammen.
Die konventionelle Herstellung kann in mehrere Schritte unterteilt werden:
FHNW
Plasmid Database
12
•
Design: Mittels spezieller Software werden zuerst kompatible Fragmente definiert,
die, miteinander verknüpft, das richtige Plasmid ergeben.
•
Fragmente: Spezielle Enzyme (sog. Restriktionsenzyme) werden verwendet, um
aus verschiedenen Plasmiden oder DNA-Strängen anderer Herkunft die
notwendigen Fragmente herauszuschneiden.
•
Aufreinigung: Spezielle Gele (eine Art Sieb) werden verwendet, um die
entstandenen Fragmente der Grösse nach aufzutrennen und aufzureinigen.
•
Ligation: Mit einer weiteren biochemischen Reaktion verknüpfen Enzyme die
gewonnenen Fragmente wieder zusammen.
•
Produktion und Qualitätssicherung: Nach der Vervielfältigung von Plasmiden in
Bakterien müssen die Produkte mittels modernen analytischen Verfahren, die Tage
dauern, noch auf Fehlerfreiheit überprüft werden.
Der gesamte Prozess ist teuer, kann Wochen dauern und man ist sich dabei nie sicher,
dass nicht eine andere Forschungsgruppe etwas sehr ähnliches bereits gemacht hat.
2.4
Auftrag
Der Auftrag wird hier in zusammengefasster Form wiedergegeben, das Lastenheft ist in
Form eines Blueprints im Anhang eingegliedert.
Die Idee von Dr. Hoerndli und Dr. Kohli bestand darin, eine Datenbank zu entwickeln, in der
die Forscher ihre elektronischen Sequenzinformationen zusammen mit ihrer Email-Adresse
ablegen können. User können nach Eigenschaften oder nach Sequenzen suchen und
jenen Forschern eine Anfrage senden, die ein entsprechendes Plasmid haben. Die
Forscher bleiben aus Datenschutzgründen für den User unbekannt.
Für die Plasmide sollen folgende Informationen in der Datenbank abgespeichert werden:
•
Plasmidname
•
Volltextsequenz des Plasmids
•
reverse-komplementäre Sequenz
•
Features
•
Spezies des Hauptelementes
•
High Copy Number
•
Anzahl ausgefüllter Feedbacks
•
durchschnittliche Bewertung (Rating) der Nützlichkeit und Qualität
•
Zitierungen in Publikationen
•
Kommentare
FHNW
Plasmid Database
13
•
Email-Adresse der Person
•
Forschungsgruppe
Das Webinterface soll folgende Funktionalitäten enthalten:
•
Login
•
Registrierung (User und neue Forschungsgruppe)
•
EULA (End User License Agreement)
•
manuelle Eingabe
•
automatische Eingabe
•
Plasmidsuche
•
Such-Resultatmaske
•
Detailansicht
•
Bestellung Plasmid
•
Plasmideigenschaften editieren
•
Feedbackformular
•
Lizenz
Funktionalitäten im Hintergrund:
•
automatische Feedbackerinnerung
•
Durchschnittsberechnungen für Feedbackeinträge beim Plasmid
•
automatische Featureerkennung
Zusätzliche Punkte:
•
Optik des Webauftritts ist zweitrangig
•
Erweiterbarkeit der Feature- und User-Listen
•
keine Anforderungen an Suchalgorithmen
•
Implementation des BLASTN Algorithmus wird aus Sicht der Auftraggeber und des
FGCZ als kaum realisierbar in den zehn Wochen angesehen
FHNW
Plasmid Database
14
2.5
Anforderungen
In diesem Kapitel werden die Anforderungen und der Umfang der Arbeit genauer
abgesteckt.
2.5.1
Plasmidverwaltung
Die Forscher sollen zur Mitarbeit aufgefordert werden und ihre Plasmide den anderen
Usern zur Verfügung stellen. Sie profitieren gegenseitig von einander und sollten mit dieser
Software ein kostenloses Tool für ihre Forschung verwenden können. Die Eingaben sollen
mittels eines Webformulars getätigt werden. Die Daten werden in einer Datenbank
abgespeichert.
2.5.2
Design
Das Design soll ansprechend, aber nicht überladen sein. Die Bedienungsoberfläche ist auf
Mausbedienung ausgelegt. Ergonomische Grundsätze sollen beim Layout berücksichtigt
werden. Die Bedienung erfolgt über ein Webinterface.
Es werden die drei Benutzerrollen User, Autor und Administrator unterschieden. Der User
soll möglichst wenige Werte eingeben müssen. Die meisten Angaben erfolgen via
Auswahllisten (Dropdown Menu). Die Hauptnavigationsseite befindet sich auf allen Seiten,
die nichts mit Login, Passwort oder Registrierung zu tun haben, am linken Rand. Via
Menubutton können die einzelnen Hauptmasken aufgerufen werden.
Bestätigungsseiten und Fehlermeldungen erscheinen auf einer Extraseite. Die
Useroberfläche soll selbsterklärend aufgebaut sein.
FHNW
Plasmid Database
15
2.6
Anwendungsfalldiagramm
Das Anwendungsfalldiagramm stellt die Anwendungen mit den dazugehörigen Akteuren
dar. Es zeigt die Applikation aus Sicht des Anwenders.
Plasmid Database
Login
User löschen
Registrierung User
vergessenes
Passwort erneuert
User
Forschungsgruppe
anmelden
Suche
Bestellung Plasmid
Administrator
Feedback erteilen
Suche mit BLAST
Plasmidänderung
Autor
automatische
Eingabe von Plasmiden
manuelle Eingabe
von Plasmiden
Grafik 1: Anwendungsfalldiagramm
FHNW
Plasmid Database
16
2.7
Beschreibung der Aktoren
Die drei beteiligten Akteure sind:
Akteur
Beschreibung
Der User ist ein Akteur, welcher vor allem Plasmide sucht, diese
bestellt und ein Feedback abgibt. Er hat keine Berechtigung
Eigenschaften der Plasmide oder die Homepage zu verändern. Er ist
nur Konsument. Die einzige Ausnahme ist das Feedback, mit
welchem er Einfluss auf die Bewertung des Plasmids nimmt.
User
Der Autor ist ein spezieller User. Er kann dieselben Aktionen
durchführen wie der User. Zudem kann er Plasmiddaten erfassen und
mutieren. Der Autor stellt die Daten für den User zur Verfügung.
Wenn der User ein Feedback abgibt, bekommt der Autor dieses
automatisch zugesendet.
Autor
Der Administrator ist für die Verwaltung der Forschungsgruppen
zuständig. Er kann auch Plasmide löschen.
Administrator
Tabelle 1: Beschreibung der Aktoren
2.8
Beschreibung der einzelnen Use Cases
U01
Use Case
Login
Ziel
Login ist erfolgt
Vorbedingung
User ist auf http://fgcz-plasmiddb.unizh.ch
Nachbedingung Erfolg
User ist registriert
Nachbedingung Fehlschlag
User muss sich registrieren
Akteure
User
Auslösendes Ereignis
-
Beschreibung
Eingabe der Logindaten mit Passwort
FHNW
Plasmid Database
17
U02
Use Case
Registrierung
Ziel
Registrierung ist erfolgt
Vorbedingung
User ist auf http://fgcz-plasmiddb.unizh.ch und hat noch kein
Passwort
Nachbedingung Erfolg
User gehört Forschungsgruppe an
Nachbedingung Fehlschlag
User muss Forschungsgruppe anmelden, EULA nicht gelesen
Akteure
User
Auslösendes Ereignis
Login fehlgeschlagen, da User nicht registriert
Beschreibung
User gibt nach dem Akzeptieren der EULA Email-Adresse,
Forschungsgruppe und Passwort an und wird so automatisch
registriert
U03
Use Case
Registrierung löschen
Ziel
Der User kann sich selber löschen. Die Daten der Bestellung
werden gleichzeitig aus Datenschutzgründen auch gelöscht.
Die Daten des Plasmids bleiben jedoch erhalten.
Vorbedingung
User ist auf http://fgcz-plasmiddb.unizh.ch
Nachbedingung Erfolg
User hat sich richtig registriert und den Delete-RegistrationButton auf der delete.php-Seite gedrückt.
Nachbedingung Fehlschlag
User hat das Löschen auf der delete.php-Seite nicht bestätigt
Akteure
User
Auslösendes Ereignis
Delete-Registration-Button auf login.php gedrückt
Beschreibung
Der User möchte seine Registrierungsdaten und Bestelldaten
löschen. Auf der login.php-Seite registriert er sich und drückt
den Delete-Registration-Button. Danach bestätigt er das
Löschen auf der delete.php-Seite.
U04
Use Case
Forschungsgruppe anmelden
Ziel
Neue Forschungsgruppe wird zur Liste der Forschungsgruppen
hinzugefügt
Vorbedingung
Forschungsgruppe ist noch nicht registriert
Nachbedingung Erfolg
Administrator heisst Forschungsgruppe gut
Nachbedingung Fehlschlag
Administrator lehnt Forschungsgruppe ab
Akteure
User, Administrator
Auslösendes Ereignis
Registrierung fehlgeschlagen, da Forschungsgruppe nicht
vorhanden
Beschreibung
User schreibt Email an Administrator, damit dieser die
Forschungsgruppe zur Liste hinzufügt und der User sich
registrieren kann
FHNW
Plasmid Database
18
U05
Use Case
EULA
Ziel
EULA-Text aufzeigen
Vorbedingung
„EULA“-Button wurde gedrückt
Nachbedingung Erfolg
Seite wird angezeigt, wenn richtig auf sie weitergeleitet wurde
Nachbedingung Fehlschlag
Seite kann nicht richtig angezeigt werden
Akteure
User
Auslösendes Ereignis
„EULA“-Button wurde gedrückt
Beschreibung
Nachdem der „EULA“-Button geklickt wurde, wird der EULAText angezeigt. Bei der Registrierung handelt es sich um den
gleichen Text, er ist jedoch mit einem „agree“-Button versehen
U06
Use Case
Passwort vergessen
Ziel
User erhält neues Passwort
Vorbedingung
Login schlägt aufgrund des nicht vorhandenen oder falschen
Passwortes fehl
Nachbedingung Erfolg
neues Passwort wird generiert
Nachbedingung Fehlschlag
Passwortanfrage schlägt fehl
Akteure
User
Auslösendes Ereignis
Login fehlgeschlagen, da Passwort nicht vorhanden
Beschreibung
User hat Passwort vergessen und gibt seine Email an. Er
bekommt automatisch ein Passwort zugesendet.
U07
Use Case
Passwort ändern
Ziel
User ändert Passwort
Vorbedingung
User ist richtig eingeloggt
Nachbedingung Erfolg
User hat neues Passwort eingegeben
Nachbedingung Fehlschlag
User hat kein neues Passwort eingegeben
Akteure
User
Auslösendes Ereignis
User hat „Change Password“ angeklickt
Beschreibung
User möchte sein Passwort ändern. Der User muss dazu
nochmals sein altes Passwort und das neue zwei Mal
eingeben.
FHNW
Plasmid Database
19
U08
Use Case
Home-Seite
Ziel
die Seite wird angezeigt
Vorbedingung
Login des Users
Nachbedingung Erfolg
Login war erfolgreich
Nachbedingung Fehlschlag
Login ist fehlgeschlagen
Akteure
User
Auslösendes Ereignis
„submit“-Button bei Login geklickt
Beschreibung
User erhält Informationen zur Homepage, sowie alle Links zu
den nachfolgenden Seiten
U09
Use Case
Logout
Ziel
User meldet sich ab und Session wird gelöscht
Vorbedingung
User hat „logout“-Button geklickt
Nachbedingung Erfolg
Session wurde gelöscht
Nachbedingung Fehlschlag
Session wurde nicht gelöscht, falsche Weiterleitung
Akteure
User
Auslösendes Ereignis
User hat „logout“-Button geklickt
Beschreibung
Nachdem User den „logout“-Button geklickt hat, gelangt er auf
die „index“.php-Seite. Session ist gelöscht.
U10
Use Case
Manuelle Eingabe von Plasmiden
Ziel
Ablegen von Plasmiden in der DB
Vorbedingung
User muss registriert sein
Nachbedingung Erfolg
Felder „Plasmid Name“, „full text sequence“, „species of the
main element“ müssen ausgefüllt sein (feature nicht nötig) und
in „full text sequence“ keine anderen Buchstaben als A, C, T, G
oder Plasmid als Datei
Nachbedingung Fehlschlag
Felder falsch ausgefüllt
Akteure
Autor
Auslösendes Ereignis
„enter manual“ angeklickt
Beschreibung
Autor will Plasmid-Sequenz in die DB laden, Felder werden
richtig ausgefüllt, die Daten können auch als Datei via „browse“
geladen werden, „submit“-Button gedrückt und Sequenz wird in
DB aufgenommen
FHNW
Plasmid Database
20
U11-U13
Use Case
Plasmidabfrage (Plasmidsuche)
Ziel
Der User kann mit Hilfe der „search“.php-Seite ein Plasmid
suchen und erhält die Ergebnisse in der „search result form“.
Detailinformationen erhält er auf „detail“.php.
Vorbedingung
User muss registriert sein und auf „interna“.php den „search“Button angeklickt haben.
Nachbedingung Erfolg
Plasmid in DB enthalten und gefunden worden.
Nachbedingung Fehlschlag
Plasmid in DB nicht enthalten, „search“.php falsch ausgefüllt.
Akteure
User
Auslösendes Ereignis
„Search“-Button auf „interna“.php angeklickt
Beschreibung
User kann über die „plasmid search form“ seine
Suchbedingungen eingeben, danach wird das „search result
form“ mit den Ergebnissen angezeigt. Falls die Suchanfrage
eingeschränkt werden soll, wird darauf hingewiesen und die
ersten 20 Ergebnisse werden angezeigt. Detailinformationen
sind im „plasmid result form“ auf „detail“.php angezeigt,
welches durch klicken auf den Plasmidnamen im „search result
form“ angezeigt werden können. Es besteht auch die
Möglichkeit nur nach den eigenen Plasmiden zu suchen
(„search my plasmids only“).
U14
Use Case
Bestellung Plasmid
Ziel
Email an Autor wird versendet um Bestellung zu ermöglichen.
„Email versendet“ wird auf der Bestätigungsseite angezeigt
Vorbedingung
Plasmidabfrage muss erfolgreich gewesen sein.
Nachbedingung Erfolg
Email an Autor wurde erfolgreich versendet.
Nachbedingung Fehlschlag
„send inquiry to author“ wurde nicht gedrückt oder Email konnte
nicht versendet werden
Akteure
User
Auslösendes Ereignis
„send inquiry to author“-Button
Beschreibung
Der User bestellt ein Plasmid in dem eine Email direkt an den
Autor gesendet wird, der User drückt nur den „send inquiry to
author“-Button. Die Bestellung ist mit dem Email
abgeschlossen.
FHNW
Plasmid Database
21
U15
Use Case
Login für Feedback
Ziel
Login erfolgreich und User gelangt auf Feedback-Formular
Vorbedingung
Bestellung muss vorangegangen sein
Nachbedingung Erfolg
User erfolgreich angemeldet
Nachbedingung Fehlschlag
Login schlägt fehl
Akteure
User
Auslösendes Ereignis
Mail an User
Beschreibung
User muss spätestens nach der dritten Erinnerung das
Feedbackformular ausfüllen und erhält dann nochmals zwei
Wochen Zeit. User kann direkt in der Email auf den Link klicken
und gelangt so zum Login für das Feedbackformular.
U16
Use Case
Feedback erteilen
Ziel
Feedbackformular ausgefüllt, rating in DB aufgenommen und
an Autor gesandt
Vorbedingung
Bestellung muss vorangegangen sein
Nachbedingung Erfolg
Feedbackformular richtig ausgefüllt und submit-Button gedrückt
Nachbedingung Fehlschlag
Submit-Button nicht gedrückt
Akteure
User, Autor
Auslösendes Ereignis
User hat „feedback“-Button geklickt oder User gelangt per Link
in Mail über Login auf „feedback“.php
Beschreibung
Informationen aus dem Feedback werden in DB eingetragen
und per Mail an Autor gesendet.
U17
Use Case
automatische Eingabe von Plasmiden
Ziel
Plasmidinformationen aus Dateien hochladen
Vorbedingung
Autor muss registriert sein
Nachbedingung Erfolg
„species of the main element“ muss ausgefüllt werden und
Datei muss angegeben sein, submit-Button gedrückt
Nachbedingung Fehlschlag
Felder falsch ausgefüllt, submit-Button nicht gedrückt, Datei
fehlerhaft
Akteure
Autor
Auslösendes Ereignis
„enter automatic“ angeklickt
Beschreibung
Autor will Plasmid-Sequenz automatisch in die DB laden,
Felder werden richtig ausgefüllt, die Daten können auch via
„browse“ geladen werden, submit-Button gedrückt und
Sequenz wird in DB aufgenommen
FHNW
Plasmid Database
22
U18
Use Case
Plasmidänderungen durch Autor
Ziel
Der Autor kann Eigenschaften seiner Plasmide manuell
nachträglich verändern
Vorbedingung
Autor hat sich richtig registriert, Plasmid wurde gefunden und
Autor wurde als Autor des Plasmids erkannt
Nachbedingung Erfolg
Autor hat Plasmidänderungen richtig eingetragen
Nachbedingung Fehlschlag
Plasmidänderungen sind falsch
Akteure
Autor
Auslösendes Ereignis
Change-Button gedrückt auf „plasmid result form“
Beschreibung
Der Autor eines Plasmids kann Änderungen an seinen hinauf
geladenen Plasmiden vornehmen. Dazu muss er das Plasmid
nochmals suchen und auf dem „plasmid result form“ den
change-Button drücken.
U19
Use Case
Copyright
Ziel
Anzeigen der Seite
Vorbedingung
„Copyright“-Button wurde geklickt
Nachbedingung Erfolg
Seite wird angezeigt, wenn richtig auf sie weitergeleitet wurde
Nachbedingung Fehlschlag
Seite kann nicht richtig angezeigt werden
Akteure
User
Auslösendes Ereignis
„Copyright“-Button wurde geklickt
Beschreibung
Text des Copyrights wird angezeigt
U20
Use Case
Help
Ziel
Anzeigen der Seite und PDF-Dokument
Vorbedingung
„Help“-Button wurde geklickt
Nachbedingung Erfolg
Seite wird angezeigt, wenn richtig auf sie weitergeleitet wurde
Nachbedingung Fehlschlag
Seite kann nicht richtig angezeigt werden
Akteure
User
Auslösendes Ereignis
„Help“-Button wurde geklickt
Beschreibung
Help ist in html oder pdf-Format auf jeder Seite
FHNW
Plasmid Database
23
U21
Use Case
FAQ
Ziel
Anzeigen der Seite
Vorbedingung
„FAQ“-Button wurde geklickt
Nachbedingung Erfolg
Seite wird angezeigt, wenn richtig auf sie weitergeleitet wurde
Nachbedingung Fehlschlag
Seite kann nicht richtig angezeigt werden
Akteure
User
Auslösendes Ereignis
„FAQ“-Button wurde geklickt
Beschreibung
Häufig gestellte Fragen mit Antworten werden angezeigt.
U22
2.9
Use Case
BLAST
Ziel
Suche mit BLAST, Ergebnisse in „search result form“,
Detailinformationen auf „detail“.php
Vorbedingung
„Search with BLAST“-Button geklickt
Nachbedingung Erfolg
Plasmid in Flatfile-DB enthalten und gefunden
Nachbedingung Fehlschlag
Plasmid in Flatfile-DB nicht enthalten, „searchblast“.php falsch
ausgefüllt
Akteure
User
Auslösendes Ereignis
„Search with BLAST“-Button geklickt
Beschreibung
User kann Sequenz als Volltext eingeben. Wenn Suche mit
BLAST erfolgreich, durch klicken auf Plasmidname erscheint
Detailansicht.
Ziel
Das Ziel ist es, den Forschern eine funktionierende Software zur Verfügung zu stellen,
welche sie im Labor unterstützt. Die Webseite soll übersichtlich gestaltet, selbsterklärend
und einfach zu bedienen sein.
Das Zielprodukt soll nach der Diplomarbeit unter http://fgcz-plasmiddb.unizh.ch produktiv
eingesetzt werden.
2.10
Projektplan
Die folgenden Grafiken 2-5 enthalten den Projektplan (MS Project), welchen wir zu Beginn
erstellt haben. Er enthält die geplante Dauer, sowie die benötigte Zeit.
Im Anhang befindet sich der ausführliche Plan.
FHNW
Plasmid Database
24
FHNW
Plasmid Database
25
FHNW
Plasmid Database
26
FHNW
Plasmid Database
27
FHNW
Plasmid Database
28
3
Konzeptphase
3.1
Technologien
Die verwendeten Technologien sind für den Webbereich HTML, CSS, Java-Script, ShellSkript, PHP 5.2 (erschienen am 2. November 2006) und für die Datenbank MySQL 5.0.26.
In Betracht gekommen wäre auch PostgreSQL.
3.1.1
Bedarfsanalyse
Die verwendeten Technologien sind Open Source Produkte und plattformunabhängig.
Zudem gewährleisten sie eine sehr gute Performance. Die Zeitschrift c't (c't 2006, Heft 13)
hat im Jahr 2006 einen Datenbank-Wettbewerb durchgeführt. Dieser hat gezeigt, dass die
Kombination von Linux, MySQL 5 und PHP 5 im Vergleich zu diversen anderen
Datenbanken und Programmiersprachen die beste Performance bietet. Im Wettbewerb
wurde ein DVD-Shop simuliert.
3.1.1.1 MySQL versus PostgreSQL
PostgreSQL ist in der Bioinformatik weit verbreitet. Aus diesem Grund wurde ein Vergleich
zwischen MySQL und PostgreSQL gezogen.
Folgend werden die beiden Datenbankverwaltungssysteme vorgestellt und miteinander
verglichen.
3.1.1.1.1 MySQL4
MySQL ist ein SQL-Datenbank-Managementsystem (SQL: Structured Query Language),
welches als Open Source Software für verschiedene Betriebssysteme (Unix, Linux,
Windows) zur Verfügung steht. Die aktuelle Version ist 5.0.28.
Die MySQL-Software unterliegt einer Doppellizenz. Diese kann frei im Sinne der GNU
(General Public License) oder als kommerzielle Lizenz verwendet werden.
MySQL ist ein relationales Datenbank-Managementsystem. In einer relationalen Datenbank
werden Daten in separaten Tabellen und nicht in einem einzig grossen Speicherraum
gespeichert. Dies ermöglicht hohe Geschwindigkeiten und Flexibilität. Die Tabellen werden
durch Beziehungen (Relationen) miteinander verbunden, um die Daten zu kombinieren.
4
Literaturhinweis: Diese Informationen wurden aus dem MySQL-Referenzhandbuch entnommen, zu finden unter www.mysql.de
Sie wurden nicht im Wortlaut übernommen und sind stark zusammengefasst.
FHNW
Plasmid Database
29
MySQL erlaubt unter anderem die Verwendung verschiedener Tabellentypen (z. Bsp.
MyISAM, InnoDB), auf welche wir später eingehen werden. Dies ermöglicht eine
Anpassung an die jeweiligen Anforderungsprofile.
3.1.1.1.2PostgreSQL5
PostgreSQL ist ein objektrelationales Datenbank-Managementsystem, welches auch als
Open Source Programm frei verfügbar ist. Die Entwicklung des Systems hat als
universitäres Projekt an der University of California at Berkley begonnen. Wie bei Open
Source Systemen üblich wurde der Code von vielen Entwicklern weiterverarbeitet und
bekam 1996 den Namen PostgreSQL.
PostgreSQL unterstützt wie auch schon MySQL den SQL92 und den SQL99 Standard.
Verschiedene Erweiterungen werden von beiden Datenbank-Managementsystemen
angeboten.
5
Die hier verwendeten Angaben wurden der Seite www.postgresql.de entnommen und sind zusammengefasst
FHNW
Plasmid Database
30
3.1.1.1.3 Vergleich zwischen MySQL und PostgreSQL6
Funktionalität
MySQL 5.0
PostgreSQL 8.0
gängiste Betriebssysteme
Linux, Windows, MacOS X
Linux, Windows, MacOS X
ANSI SQL
SQL92, SQL99
SQL92; SQL99
Subselects
ja
ja
Transaktionen
ja (nur InnoDB)
ja
Fremdschlüssel
ja (nur InnoDB)
ja
Views
ja
ja
Trigger
ja
ja
Unions
ja
ja
Full Joins
ja (5.1)
ja
Constraints
ja (5.1)
ja
Tabellentypen
MyISAM, InnoDB, HEAP und
weitere Tabellentypen
keine alternativen
Tabellentypen
Cursors
beschränkt ja
ja
Prozedurale Sprachen
ja
ja
ODBC
ja
ja
JDBC
ja
ja
API
fast alle Sprachen
fast alle Sprachen
Tabelle 2: MySQL vs. PostgreSQL
3.1.1.1.4 Schlussfolgerung: Verwendung MySQL
Wie oben ersichtlich ist, unterscheiden sich die beiden Datenbank-Managementsysteme
nur geringfügig.
MySQL ist im Webbereich sehr etabliert und bietet gute Dokumentationen. Dies waren die
massgebenden Gründe für den Entscheid, MySQL zu verwenden.
3.1.1.2 MySQL7
In MySQL gibt es verschiedene Tabellentypen, die man Storage-Engines nennt. Es sind
diese MyISAM, InnoDB, HEAP, Merge, BDB und NDB. Nachfolgend werden der Standard
MyISAM und die transaktionsfähige InnoDB verglichen. Die anderen Tabellentypen
kommen für unsere Arbeit nicht in Betracht.
6
Der Vergleich wurde aus dem Artikel „MySQL vs. PostgreSQL“ von Maciej Glowiak entnommen, vom Englischen ins Deutsche übersetzt und
stark zusammengefasst
7
Literaturhinweis: Die Informationen dieses Kapitels finden sich in „High Performance MySQL: Optimierung, Datensicherung, Replikation &
Lastverteilung“ von Jeremy D. Zawodny und Derek J. Balling
FHNW
Plasmid Database
31
3.1.1.2.1 Begriffserklärung8
Zu Beginn werden einige Begriffe erläutert, die für das Verständnis hilfreich sind.
3.1.1.2.2 Fremdschlüssel
Ein Fremdschlüssel zeigt die Beziehung zu einer anderen Tabelle. Er verweist immer auf
den korrespondierenden Primärschlüssel. Ein Fremdschlüssel kann keine oder mehrere
Werte haben, beispielsweise können mehrere Plasmide das gleiche Feature haben.
3.1.1.2.3 Referenzielle Integrität
Referenzielle Integrität steht für das Sicherstellen der Beziehungen. Beispielsweise wenn
ein User zu einer Gruppe gehören muss. Fremdschlüssel ist der Mechanismus, der diese
Referenzielle Integrität unterstützt. Es wird die Korrektheit zwischen Attribut und Erhaltung
der Eindeutigkeit ihrer Schlüssel gewährleistet.
3.1.1.2.4 Transaktion
Eine Transaktion ist eine Gruppe von SQL-Abfragen, die als atomar (zusammengehörig)
betrachtet werden. Während einer Transaktion besteht eine Schreibsperre.
3.1.1.2.5 Isolationsebenen
Definiert, welche Änderungen innerhalb und ausserhalb einer Transaktion sichtbar sind
oder nicht. Es gibt Read Uncommitted, Read Committed, Repeatable Read und
Serializable.
3.1.1.2.6 Query-Cache
Select-Abfragen können gehasht werden, mit dem Hash-Wert wird dann der Cache geprüft.
Häufig verwendete Abfragen sind so schnell abrufbar.
3.1.1.2.7 Tree-Indizes
B-Tree-Indizes werden sortiert abgelegt (Baumstruktur).
R-Tree-Indizes sind für die räumliche oder N-dimensionale Ablage von Daten.
ISAM = Index Sequential Access Method
MVCC = Multi-Version Concurrency Control
8
SQL Language Reference Manual von Dwight Cheu (Oracle 1988)
FHNW
Plasmid Database
32
3.1.1.3 Vergleich zwischen MyISAM und InnoDB
Funktionalität
MyISAM
InnoDB
Fremdschlüssel
nein
ja
Isolationsebenen
keine
alle
Transaktionen
nein
ja
Referenzielle
Integrität
nein
ja
Volltextindexierung
ja
nein
Speicherung
in getrennten Dateien
in Tablespaces
Datensätze im Cache
festhalten
Tree-Indizes
nein
ja
R-Tree-Indizes
B-Tree-Indizes
Spezielles
wurde entwickelt in der Annahme,
dass 90% der Abfragen
Leseoperationen sind, d.h. ist
geeignet, wenn hauptsächlich gelesen
wird
Zeilenorientiertes Locking, erlaubt
nicht-sperrende Leseoperationen
und sperrt gleichzeitig alle
notwendigen Schreiboperationen
kennt die Anzahl der Zeilen
(interessant bei Abfragen wie "select
count (*) from mytable")
ist nach einem Absturz schneller
wiederhergestellt
bei Index erfolgen zwei Abfragen, eine
für den Index selbst und eine für die
Tabelle
geclusterte Indizes, Verweis direkt
auf den fraglichen Datensatz
Tabelle 3: MyISAM vs. InnoDB
3.1.1.3.1 MyISAM und InnoDB
Es besteht die Möglichkeit, Tabellen anzulegen, die zum Teil vom Typ MyISAM und zum
Teil vom Typ InnoDB sind, wobei die Fremdschlüsselbeziehungen nicht von einem Typ
zum anderen funktionieren.
Die Volltextindexierung von MyISAM kann auch nachteilig sein, da der Query-Optimizer von
MySQL den Volltextindex immer vorzieht, egal wie viele Zeilen tatsächlich aus dem
Ergebnis eliminiert werden. Zudem wird für Volltextindizierung mehr Speicherplatz benötigt.
MyISAM bietet verzögertes Schreiben von Indexdaten, was aber bei einem Absturz zu
schlimmen Folgen führen kann.
3.1.1.3.2 Verwendung MyISAM oder InnoDB
Da InnoDB mehr Vorteile hat, wurde dieser Tabellentyp gewählt. Eine Volltextindizierung ist
bei einer Sequenz von 20'000 Basen, die aus 4 verschiedenen Buchstaben besteht, nicht
sinnvoll. Zudem erstellt der BLAST-Algorithmus eigene Indizes, so dass eine
Volltextindizierung dazu nicht notwendig ist.
FHNW
Plasmid Database
33
3.1.1.4 InnoDB
InnoDB ist eine transaktionssichere Storage-Engine. Dies ist einer der wichtigen Punkte.
Sie unterstützt alle vier Transaktionsebenen des SQL-Standards. READ UNCOMMITTED,
READ COMMITTED, REPEATABLE READ und SERIALIZABLE. Die
Standardisolationsebene ist REPEATABLE READ.
Zudem ist InnoDB geeignet für eine hohe Schreib-/Lese-Parallelität und garantiert
referenzielle Integrität bei Fremdschlüsseln.
Bei InnoDB können alle Schreiboperationen rückgängig gemacht werden (rollback).
Wiederholte Lesezugriffe innerhalb einer Transaktion sind von Schreibzugriffen anderer
Transaktionen nicht beeinflusst (Isolation aus ACID). Schreibzugriffe in einer Transaktion
bewirken eine Schreibsperre der betroffenen Datensätze für alle anderen Transaktionen
(row level locking).
Durch die geclusterten Indizes entsteht für InnoDB ein Performancevorteil, da Verweise
direkt auf den fraglichen Datensatz gehen und nicht wie bei MyISAM zwei Abfragen nötig
sind.
InnoDB erkennt automatisch einen Deadlock (gegenseitige Blockierung zweier Prozesse)
von Transaktionen und rollt eine oder mehrere Transaktionen zurück, um den Deadlock
aufzulösen.
3.1.1.5 PHP4 versus PHP5
Neuerungen bei PHP5:
Die neue Engine liefert ein neues Objektmodell, das PHP zu einer Sprache mit einem
schnellen und erstklassigen Objektsystem macht.
Kapselung der Daten (z. B. private Variablen), Destruktoren und Fehlerbehandlung per
Exceptions sind erst in PHP 5 hinzugekommen.
Objekt-Variablen sind in PHP 5, wie bei den meisten Sprachen, nur noch eine Referenz auf
das Objekt und nicht wie in PHP 3 und 4 das Objekt selbst.
ab PHP 5.2; schnellere und effizientere Speicherverwaltung
3.1.1.6 PhpMyAdmin
PhpMyAdmin ist ein geeignetes Tool für die Datenbankadministration. Es ist sehr einfach
zu handhaben.
FHNW
Plasmid Database
34
3.1.2
PHPUnit
PHPUnit ist ein geeignetes Tool um den Code auf Fehler zu testen. Da PHPUnit aber
immer parallel zum Programmcode angepasst werden muss und dies enorme Zeit in
Anspruch nimmt, wurde darauf verzichtet. Anstatt dessen, wurde eine ausführliche
Testphase mit einer Testgruppe durchgeführt. Der Quellcode wurde seit Beginn fortlaufend
getestet und es wurden jeweils die einzelnen Use Cases getestet. Die Testfälle werden im
Kapitel 4.10 „Testphase“ ausführlicher besprochen.
3.1.3
Entscheidungen
Als Programmiersprache wurde auch Python in Betracht gezogen. Da dies jedoch keinen
merklichen Performancegewinn gebracht hätte, wurde hauptsächlich PHP verwendet. Die
Kombination von PHP und MySQL ist überzeugend.
3.2
Softwaredesign
Im Kapitel „Softwaredesign“ werden das Datenbankmodell und das Workflow abgebildet.
Weitere Informationen befinden sich im Pflichtenheft im Anhang.
FHNW
Plasmid Database
35
PK
PK
PK
UNIVERSIT IES1
nam e: VARCHAR( 40) no t nu ll UNIQUE
G_ID: INT (11 ) no t n ull aut o_in cr eme nt
G RO UP1
nam e: VARCHAR(40) no t n ull UNIQUE
S_ ID: INT( 11) no t nu ll au to _inc rem en t
SPECIES1
en din g: VARCHAR( 40) no t nu ll UNIQUE
EU_ ID: INT (11) no t n ull a uto _in cre men t
PK
F EAT URE1
PLASMID1
nam e: VARCHAR( 40) no t nu ll UNIQUE
sequ en ce: VARCHAR( 900) no t n ull
highcop y: TINYINT( 4) n ull
F_ID: INT(1 1) n ot nu ll au to_ incr em ent
PK
S_ID: INT(1 1) n ot nul l FK t o S_ID
n ame : VARCHAR(4 0) n ot nu ll UNIQUE
f ull: VARCHAR(200 00) not nu ll
r ever se : VARCHAR(2 0000) no t n ull
b uild tim e: DAT ET IME no t n ull (JJJ J-MM -DD HH:MM :SS)
fd etection : DAT ETIME nu ll (JJJJ-M M-DD HH:MM :SS)
au thor : INT( 11) n ull FK to U_ ID
hig hcopy: F INYINT(1 ) nu l
nu mber lfb: INT (11) null
r ating: DOUBLE nu l
inte grity: DOUBLE nu l
citat io n: VARCHAR(20 0) nu ll
com men t: VARCHAR( 200 ) null
P_ID: INT(1 1) n ot nul l aut o_i ncr em ent
PK
G_ID: INT(1 1) n ot nu ll FK t o G_ ID
em ail: VARCHAR(40) no t n ull UNIQUE
pa sswo rd : VARCHAR(4 0) n ot nul l
U_ID: I NT (11 ) n ot n ull aut o_in cr em ent
USER1
Author
Lief erant
Bestell er
PK
cu sto me r: INT(1 1) n ot nu ll UNIQUE( cus tom er , P_ID) F K to U_ID
P_ID: INT(1 1) n ot nul l
su pp lier : INT (11) no t n ull F K to U_ID
in qu iry : DATETIM E not nu ll (J JJ-M M-DD HH:M M:SS)
d ema nd : DATETIM E not nu ll (J JJJ- MM- DD HH: MM: SS)
r em ind : DATETIM E not nu ll (J JJJ- MM- DD HH: MM: SS)
d ead line: DATETIM E n ot nu ll (J JJJ- MM- DD HH: MM: SS)
d elet e: DATET IME no t n ull ( JJJJ -MM -DD HH:MM :SS)
fb made : DAT ET IME nu l ( JJJJ-MM -DD HH:MM :SS)
I_ ID: INT( 11) no t nu ll au to _inc rem en t
INQUIRY1
F_I D: INT( 11) not nu ll UNIQUE(F_ ID, P_ID)
P_ ID: INT (11) no t n ull
FEAPLA1
3.2.1
ER-Modell
GRAFIK 2: ER-MODELL
FHNW
Plasmid Database
36
Bei der Erstellung des Entity-Relationship Modell wurde darauf geachtet, dass die dritte
Normalform eingehalten ist. Es ist kein Sekundärattribut von einem Schlüsselkandidaten
transitiv abhängig. Für jede Tabelle wurde ein Primärschlüssel als Integer-Wert definiert. So
können Datensätze schnell und eindeutig selektiert werden. Der Tabellentyp ist InnoDB.
Plasmid:
In der Tabelle „Plasmid“ werden die Daten des Plasmids und der ausgefüllten Feedbacks
gespeichert. Sobald ein weiteres Feedback ausgefüllt wird, berechnet das System einen
neuen Durchschnitt, so dass in der „Result Form“ eines Plasmids dieser Durchschnitt
angezeigt wird. Zudem wird in dieser Tabelle das Datum der Erstellung eines Plasmids
eingetragen. Ein weiteres Datums-Feld ist für den Cronjob, der anhand dieses Datums
erkennt, ob die automatische Featureerkennung bereits stattgefunden hat. Wenn nicht, wird
sie durchgeführt und das Datum wird eingetragen. Wenn das Plasmid ein Feature hat,
welches "High Copy Number *" ist, wird ein Flag gesetzt.
Inquiry:
In der Tabelle „Bestellung“ erfährt man, wer, bei welchem User, wann, welches Plasmid
bestellt hat und ob ein Feedback dazu ausgefüllt wurde. Der Cronjob kann anhand der
eingetragenen Daten erkennen, ob eine Email an den User gesandet werden muss, um ihn
an das Feedback zu erinnern. Wurde das Feedback bereits ausgefüllt, wird keine Email
gesandt. Die Erinnerung wird drei Mal versendet, bevor der User aus der Datenbank
gelöscht wird.
Feature:
In der Tabelle „Feature“ sind Name und Sequenz der Features abgelegt. Zudem wird ein
Flag gesetzt, wenn das Feature "High Copy Number *" ist.
User:
Hier werden Email und Passwort eingetragen.
Group:
In der Tabelle „Group“ sind die Namen der Forschungsgruppen enthalten.
Species:
In dieser Tabelle sind die Namen der Spezies abgelegt.
Feapla:
Die Tabelle „Feapla“ ist eine ID-Tabelle. Sie ist durch die "many-to-many"-Beziehung
zwischen Plasmid und Feature entstanden. In dieser Tabelle werden die Plasmid-ID und
die dazugehörigen Feature-ID's abgespeichert.
Universities:
In der Tabelle „Universities“ werden die Email-Endungen abgespeichert. Dies, da sich nur
User registrieren können, die eine Email-Adresse der eingetragenen Universitäten haben.
FHNW
Plasmid Database
37
Werte:
Die Felder, welche mit "not null" bezeichnet sind, müssen einen Wert enthalten. Ist dies
nicht der Fall, kann kein Eintrag erstellt werden. Die Felder, welche mit "null" bezeichnet
sind, können einen oder keinen Wert enthalten. Felder die mit "UNIQUE" bezeichnet sind,
müssen in den in Klammern angegebenen Feldern, einen Wert besitzen, deren
Kombination kein zweites Mal in der Datenbank vorkommt. Sie sind eindeutig. Ein Eintrag
mit denselben Werten ist nicht möglich.
Fremdschlüssel:
Es wurden diverse Fremdschlüssel definiert, welche auf einen Primärschlüssel einer
anderen Tabelle verweisen. Die Fremdschlüssel zeigen an, welche Felder einer Tabelle mit
Feldern einer anderen Tabelle in Verbindung stehen.
Symbolerklärung:
many-to-many, wird auch als „Gabel-Symbol“ dargestellt
----------
eine „kann“-Beziehung
______
eine „muss“-Beziehung
Beziehungen:
Plasmid
Feature
Plasmide können mehrere Features haben. Mehrere Features können in Plasmiden
vorkommen.
Die Beziehung wird aufgelöst, es entsteht die ID-Tabelle "feapla".
Plasmid
Spezies
Ein Plasmid muss von einer Spezies sein. Eine Spezies kann mehrere Plasmide beschreiben.
Plasmid
User
Plasmide können einem User zugewiesen sein. Ein User kann Plasmide besitzen.
Plasmid
Bestellung
Ein Plasmid kann mehrere Bestellungen haben. Eine Bestellung muss aus einem Plasmid
bestehen.
User
Gruppe
User müssen zu einer Gruppe gehören. Eine Gruppe kann User beinhalten.
Besteller
Bestellung
Ein Besteller (User) kann Bestellungen aufgeben. Bestellungen müssen von einem Besteller
aufgegeben worden sein.
Lieferant
Bestellung
Ein Lieferant (User) kann bestellte Plasmide liefern. Bestellte Plasmide müssen von einem
Lieferanten geliefert worden sein.
Tabelle 4: Beziehungen ER-Modell
FHNW
Plasmid Database
38
3.2.2
Workflow
U01: Login
login .php
User bekommt
generiertes
Passwort per Email
zugesendet
neuer User ?
U02: Registrierung
register .php
ja
nein
Passwort
vergessen ?
Email an
Administrator
um neue
Forschungs gruppe zu
registrieren .
F-gruppe nicht
vorhanden ?
ja
U06: Email
angeben
vergessen . php
Email
angegeben ?
Bestätigung
vergessenok . php
U04: Email
senden
ja
Fehlermeldung
registerok .php
nein
nein
EULA nicht
akzeptiert ?
Fehlermeldung
vergessenok .php
nein
nein
U08: Home
interna . php
ja
ja
User muss
Bestätigung
registerok . php
Eintrag in DB
User löschen ?
U03: Löschen
loeschen . php
ja
nein
Passwort
ändern
ja
U07: neues
Passwort
angeben
passwort .php
Passwort
angegeben ?
ja
Bestätigung
passwortok .php
fehlgeschlagen ?
ja
Fehlermeldung
loeschenok .php
nein
nein
Fehlermeldung
passwortok . php
nein
manuelle
Eingabe ?
Bestätigung
loeschenok . php
U10: Manuelle
Eingabe
manual .php
ja
nein
automatische
Eingabe ?
ja
U17:
Automatische
Eingabe
automatic . php
fehl geschlagen ?
ja
Fehlermeldung
manualok .php
nein
fehlgeschlagen ?
ja
Fehlermeldung
automaticok .php
Bestätigung
manualok .php
Eintrag in DB
nein
nein
Bestätigung
automaticok . php
Feature -Erkennung
Eintrag in DB
FHNW
Plasmid Database
39
Suche ?
ja
U11: Suche
search . php
nein
fehl geschlagen ?
Eula ?
ja
U05: Eula
eula .php
ja
Fehlermeldung
searchok .php
ja
Meldung
searchok .php
nein
Kontrolle
searchok . php
nein
FAQ ?
ja
U21: FAQ
faq. php
nicht
gefunden ?
nein
nein
Copyright ?
ja
U19: Copyright
copyright . php
U12: Resultat
Formular
searchok . php
Mehr als
20 Resultate ?
20 Resultate +
Meldung „Suche
eingränzen“
searchok . php
ja
nein
U13: Detail
Formular
detail .php
Nur möglich wenn
User = Author
Änderung ?
ja
U18: Change
change .php
nein
Das Feedback wird als
Email an den Autor
gesandt
fehl geschlagen ?
nein
ja
Fehlermeldung
changeok . php
nein
U16: Feedback Formular
feedback .php
Bestellung ?
ja
U14: Email
senden
Bestätigung
changeok .php
Nach zwei Monaten :
Erinnerungsmail betreffend
Feedback . User wird
gelöscht falls nach
sechseinhalb Monaten kein
Feedback erfolgt ist .
U09: Logout
logout. php
Grafik 6: Workflow
FHNW
Plasmid Database
40
3.3
Homepagedesign
Um einen Eindruck des Designs zu vermitteln, wird hier die Home-Seite angezeigt. Weitere
Screenshots befinden sich im Pflichtenheft im Anhang.
Grafik 7: Home-Seite
Iterationsphasen der Use Cases
Iterationsphase 1
Iterationsphase
Administrative Punkte
3.4
Use Case
Beschreibung
U01
Login
U02
Registrierung
U03
Registrierung löschen
U04
Forschungsgruppe anmelden
U05
EULA
U06
Passwort vergessen
U07
Passwort ändern
U08
Home-Seite
U09
Logout
FHNW
Plasmid Database
41
It. 2
Iterationsphase 4
Iterationsphase 3
Eingabeund
Suchfunktionen
nachgelagerte
Prozese
Eingabe- und
Änderungsfunktionen
Blast It. 5
U10
Manuelle Eingabe
U11
Search (Plasmidsuche)
U12
Search Result Form (Auflistung der Suchergebnisse)
U13
Detail Form (Detail des Plasmids)
U14
Bestellung Plasmid
U15
Login für Feedback
U16
Feedback
U17
Automatische Eingabe
U18
Change Plasmid (Plasmidänderungen des Autors)
U19
Copyright
U20
Help
U21
FAQ
U22
Blast
Tabelle 5: Iterationsphasen
3.4.1
Iterationsphase 1
3.4.1.1 Use Case 1: Login
Standard-Login-Seite, inklusive Registrierungs-Option. Username ist die Email-Adresse,
das Passwort wird dem User nach der Registrierung zugesendet. Passwörter können auf
einer Zusatzseite geändert werden. Die Daten werden aus der Datenbank ausgelesen und
überprüft. Sind die Daten korrekt, gelangt der User auf die Home-Seite. Hat ein User sein
Passwort vergessen, kann er sich ein Neues zukommen lassen, in dem er seine EmailAdresse auf „pwdforget.php“ einträgt. Wenn ein User seine Registrierung löschen möchte,
gelangt er über einen Button auf die entsprechende Seite.
Der User kann seine Registrierung erst auf der Home-Seite mit dem Button „Delete
Registration“ löschen. Die Login-Seite dient nur der Anmeldung und hat Buttons für
Registrierung und Passwort vergessen.
FHNW
Plasmid Database
42
3.4.1.2 Use Case 2: Registrierung
Ein neuer User kann sich über die Registrierung neu anmelden. Dazu muss er eine EmailAdresse angeben. Der User muss über eine Dropdown-Box die Email-Endung und die
Forschungsgruppe angeben, welche aus der Datenbank ausgelesen werden. Diese Listen
können nur durch den Administrator erweitert werden. Das Passwort wird dem User per
Mail zugesendet. Wenn die Checkbox für die EULA aktiviert wurde und die EULA geöffnet
worden ist, kann der User das Formular absenden. Stimmt die Email-Adresse nicht oder
wurde die EULA nicht gelesen, wird eine Fehlermeldung angezeigt und der User kann über
einen Zurück-Button zur vorherigen Seite gelangen. Wenn alles in Ordnung ist, werden die
Daten in die Datenbank geschrieben. Der User erhält dann eine Bestätigung und kann
fortfahren. Der User hat die Möglichkeit, über einen Button per Email die Registrierung
einer neuen Forschungsgruppe zu beantragen.
3.4.1.3 Use Case 3: Registrierung löschen
Der Benutzer soll sich selber löschen können. Die Daten der Bestellungen werden dann
auch gelöscht (Datenschutz). Die Daten vom Plasmid sollen jedoch erhalten bleiben, auch
wenn sich ein Autor löscht (wird in der EULA erwähnt). Da ein Autor sein Plasmid nur fünf
Mal versenden muss und dann der jeweilig älteste Besteller fünf Mal, bleibt die
Verfügbarkeit erhalten, auch wenn sich ein User löscht.
3.4.1.4 Use Case 4: Forschungsgruppe anmelden
Der Benutzer soll die Möglichkeit haben, eine neue Forschungsgruppe anzumelden. Dazu
kann er eine Email an den Administrator senden.
3.4.1.5 Use Case 5: EULA
Die End User License Agreement muss geöffnet und akzeptiert werden, bevor sich ein
Benutzer registrieren kann.
3.4.1.6 Use Case 6: Passwort vergessen
Sollte ein Benutzer sein Passwort vergessen, muss er die Möglichkeit haben, ein neues
Passwort zu verlangen.
3.4.1.7 Use Case 7: Passwort ändern
Da das generierte Passwort schlecht zu merken ist, hat der Benutzer die Möglichkeit, dies
zu ändern.
FHNW
Plasmid Database
43
3.4.1.8 Use Case 8: Home
Auf der Home-Seite sind die Links zu allen weiteren Seiten und eine Information über die
Diplomarbeit.
3.4.1.9 Use Case 9: Logout
Das Logout ist für das Verlassen der Homepage. Es löscht die Session.
3.4.2
Iterationsphase 2
3.4.2.1 Use Case 10: Manuelle Eingabe
Der User muss einen Plasmidnamen eingeben und die Spezies aus einer Dropdown-Liste
auswählen. Die Check-Box „High Copy Number“ ist optional. Die Features, welche
zusätzlich eingetragen werden können, werden über eine Listbox ausgewählt. Der User
wird darauf hingewiesen, dass er nur neun Features zum Plasmid hinzufügen darf. Die
Sequenz kann als Volltext eingegeben oder als Datei geladen werden.
3.4.2.2 Use Case 11: Search
Für die Suche hat der User die Möglichkeit, drei Features, die Spezies, den Plasmidnamen,
den Autor, die Forschungsgruppe und die Sequenz in ein Textfeld einzutragen. Die
Kriterien können AND- oder OR-verknüpft werden. Zudem kann der User auch nur nach
seinen eigenen Plasmiden suchen. Wenn das Formular gesendet wird und die Angaben
nicht korrekt sind, erscheint eine Fehlermeldung und der User kann über einen ZurückButton zur vorherigen Seite gelangen. Wird kein passendes Plasmid gefunden, erscheint
eine Meldung und der User kann fortfahren. Werden ein oder mehrere Plasmide gefunden,
erscheint das Resultat-Formular.
3.4.2.3 Use Case 12: Search Result Form
Wenn mehrere Plasmide gefunden wurden, werden sie nach bestimmten Kriterien sortiert.
Es werden maximal 20 Plasmide angezeigt, falls mehr als 20 Plasmide gefunden wurden,
erscheint eine Meldung, worin der User aufgefordert wird, die Suche einzuschränken. Jede
Zeile der aufgelisteten Plasmide hat einen Button für eine Detailansicht.
FHNW
Plasmid Database
44
3.4.3
Iterationsphase 3
3.4.3.1 Use Case 13: Plasmid Detail Form
Detail Formular:
Der User hat auf dieser Seite die Möglichkeit, über einen Button dem Autor eine Anfrage für
das Plasmid per Email zu senden. Der Besteller sieht nicht, an wen die Anfrage gesendet
wird. Im Hintergrund wird eine Liste geführt, so dass jeder Besitzer des Plasmids, dieses
nur fünf Mal versenden muss. Nach zwei Monaten erhält der User eine Email mit einer
Erinnerung, das Feedback-Formular auszufüllen, auch wenn er kein Plasmid erhalten hat.
In der detaillierten Ansicht hat der User, sofern er Autor des Plasmids ist, die Möglichkeit,
die Angaben zu ändern. Er gelangt über einen Button zur Seite „change“.php. Der Button
erscheint nur, wenn der User auch Autor ist.
3.4.3.2 Use Case 14: Bestellung Plasmid
Durch Klicken des Bestell-Buttons wird im Hintergrund der Lieferant ermittelt und ihm eine
Email gesandt mit den entsprechenden Daten.
3.4.3.3 Use Case 15: Login für Feedback
Die Benutzer, die eine Bestellung abgegeben haben, werden nach bestimmten
Zeitabständen per Email daran erinnert, das Feedback auszufüllen. Sie erhalten einen Link
zum Login für das Feedback. Die Plasmid-ID wird dabei auch mitgegeben, so dass diese
direkt im Formular steht.
3.4.3.4 Use Case 16: Feedback
Ein User, der ein Plasmid bestellt hat, muss ein Feedback-Formular ausfüllen und angeben
ob er zufrieden war, das Plasmid verwenden konnte, und wenn ja, wann er es publiziert
hat. Auch hier werden die Daten in die Datenbank geschrieben und zusätzlich wird eine
Email an den Autor gesandt. Der User wird drei Mal, also insgesamt über sechs Monate,
daran erinnert, das Feedback-Formular auszufüllen, bevor seine Registrierung nach
weiteren zwei Wochen gelöscht wird. Das Feedback-Formular muss auch ausgefüllt
werden, wenn das Plasmid nie angekommen ist. Dies sollte im Kommentarfeld eintragen
werden.
FHNW
Plasmid Database
45
3.4.4
Iterationsphase 4
3.4.4.1 Use Case 17: Enter Automatic
Der User kann 20 Files gleichzeitig hochladen. Auf jeder Zeile ist eine Dropdown-Box
vorhanden für die Spezies des Hauptelements. Über den Browse-Button kann das File
eingetragen werden. Sind die Felder ausgefüllt (pro Zeile), kann der User das Formular
absenden. Es wird geprüft, ob die Files ein gültiges Format besitzen. Ist dies nicht der Fall,
oder wurde für ein File keine Spezies gewählt, erscheint eine Fehlermeldung und der User
kann über einen Zurück-Button zur vorherigen Seite gelangen. Ist alles in Ordnung, wir im
Hintergrund über eine Suchfunktion jeweils nach den Features zu den Plasmiden gesucht
und die Daten werden in die Datenbank geschrieben. Der User erhält dann eine
Bestätigung und kann fortfahren.
3.4.4.2 Use Case 18: Change Plasmid
Der User hat die Möglichkeit, den Plasmid-Namen und die Spezies zu ändern. Zudem kann
er weitere Features hinzufügen. Die Sequenz kann nicht geändert werden, da der Lieferant
nicht unbedingt dem Autor entspricht, und so Inkonsistenzen entstehen könnten.
3.4.4.3 Use Case 19: Copyright
Für die Software wurde ein Copyright zusammengestellt, das der Benutzer auf dieser Seite
nachlesen kann.
3.4.4.4 Use Case 20: Help
Auf jeder Seite kann man eine Help in PDF- oder HTML-Format öffnen. Bei PDF durch
klicken auf den Titel direkt zum gewünschten Text.
3.4.4.5 Use Case 21: FAQ
Bei den Frequently Asked Questions hat der Benutzer die Möglichkeit, eine Antwort auf
eine Frage zu erhalten, die häufig gestellt wurde und aus diesem Grund schriftlich
festgehalten wurde.
FHNW
Plasmid Database
46
3.4.5
Iterationsphase 5
3.4.5.1 Use Case 22: Blast
Der User hat die Möglichkeit, mit Hilfe des BLAST-Algorithmus auf der Plasmid Database
nach ähnlichen Sequenzen zu suchen. Dafür sind zwei temporäre Dateien notwendig und
ein Shell-Skript, welches den BLAST ausführt. Zudem werden alle hochgeladenen
Sequenzen bei der manuellen und automatischen Eingabe in eine Flatfile-Datenbank
geschrieben. Aus dieser werden fünf Indexfiles erstellt, die der BLAST für seine Suche
benötigt.
FHNW
Plasmid Database
47
4
Realisierungsphase
4.1
Softwaredesign
Login
index .php
Login aus dem Mail für Feedback
indexfb .php
Registrierung
Ein neuer Benutzer muss die Eula
öffnen und ihr zustimmen , um sich registrieren
zu können . Das generierte Passwort wird
ihm per Email zugesendet . Die Email muss
eine der vorgegebenen Endungen haben .
Registrierung
register .php
Eula
eula .php
registerok .php
Passwort vergessen
pwdforget .php
pwdforget .php
Passwort vergessen
Hat ein Benutzer sein Passwort
vergessen , wird ihm per Email
ein neues zugesandt .
checklogin .php
checkfb .php
Home
interna .php
Registrierung löschen
Registrierung löschen
delete .php
Passwort ändern
pwdchange .php
deleteok .php
Wenn ein Benutzer seine Registrierung
löscht , werden die Benutzer - und Bestell daten gelöscht . Hochgeladene Plasmide
bleiben bestehen .
pwdchangeok .php
Feedback
Ein Feedback kann nur auf ein bestelltes
Plasmid abgegeben werden . Bei der
Eingabe werden diverse Berechnungen
getätigt , welche für die Detailansicht von
Bedeutung sind . Zudem werden die
Angaben als Email an den Autor gesandt
EULA
eulainterna .php
.
Logout
logout .php
Manuelle Eingabe
Manuelle Eingabe
manual .php
manualok .php
Der Benutzer hat die Möglickeit , ein Plasmid als
Volltext oder als Datei hochzuladen und die
passenden Features hinzuzufügen . Zusätzlich
wird der Plasmidname und die Sequenz in die
Flatfile -DB eingetragen und per Shell -Skript
wird formatdb gestartet , welches aus der
Flatfile -DB fünf Indexfiles erstellt .
Suche
Suche
search .php
Feedback
feedback .php
searchok .php
feedbackok .php
Es kann anhand ver schiedener Kriterien
nach einem Plasmid
gesucht werden . Die
Resultate enthalten
Verweise , die direkt zur
Detailansicht führen .
Feedback
feedbackmail .php
FHNW
Plasmid Database
48
Detailansicht
Aus der Detailansicht kann ein PDF
erstellt oder eine Bestellung getätigt
werden . Bei einer Bestellung wird eine
Email an den Lieferanten gesendet .
Ein Lieferant muss ein eigenes , oder
ein bestelltes Plasmid max . fünf mal
versenden . Dann wird der nächst
älteste Besteller als Lieferant ermittelt .
Zudem gelangt man über die Detail ansicht zur Änderungsseite , sofern
der aktuelle Benutzer Autor des
Plasmids ist .
Detailansicht
detail .php
Bestellung
detailok .php
PDF
pdf .php
Änderung
change .php
Automatische Eingabe
automatic .php
changeok .php
automaticok .php
Featureerkennung
autofeature .php
Automatische Eingabe
Der Benutzer hat die Möglichkeit ,
bis zu 20 Plasmide gleichzeitig
hoch zu laden . Im Hintergrund
läuft ein Programm , welches die
passenden Features zu den hoch geladenen Plasmiden findet .
Zusätzlich wird der Plamidname
und die Sequenz in die Flatfile DB eingetragen und per Shell Skript wird formatdb gestartet .
Copyright
copyright .php
FAQ
faq .php
Suche mit BLAST
Suche mit BLAST
searchblast .php
searchblastok .php
Hilfe
Hilfe
help .php
Das Help in PDF und HTML -Format
ist auf jeder Seite .
Funktionen
layout .php
Layout
layout .css
Die Plasmide werden jeweils gleichzeitig in die
Datenbank und in eine Flatfile -DB geschrieben .
Aus der Flatfile -DB werden fünf Indexfiles generiert .
Bei der Suche wird aus der zu suchenden Sequenz
eine temporäre Input -Datei (tmpin +U_ID. txt ) erstellt,
anhand der gesucht wird . Der Blast , welcher per
Shell -Skript gestartet wird , erstellt eine Output Datei (tmpout + U_ID .txt ). Diese wird ausgelesen
und dargestellt . Die Resultate enthalten Verweise ,
die direkt zur Detailansicht führen (wie bei der
normalen Suche ).
Cronjob
kronfeedback .php
Cronjob
kronallf .php
Funktionen
Cronjob
Cronjob
Diese Seite wird auf praktisch
jeder Seite aufgerufen . Sie be inhaltet die Funktionen für die
Datenbank und das Layout .
Der Cronjob läuft täglich um
Mitternacht und versendet
Emails zur Erinnerung ans
Feedback .
Der Cronjob läuft täglich um
Mitternacht und sucht alle
passenden Features zu allen
Plasmiden .
Grafik 8: UML-Diagramm
4.2
Programmierrichtlinien
Programmierrichtlinien sollen den Code lesbar machen. Jede Zeile im Code enthält
höchstens eine Anweisung. Wenn eine Zeile zu lang ist, wird sie auf zwei Zeilen aufgeteilt.
Bei Tabellen, Schlaufen und Abfragen sind Beginn und Ende klar ersichtlich und auf
gleicher Höhe. Die Einrückungstiefe beträgt einen Tabulatorschritt. Kommentare sind in
Deutsch und beginnen mit zwei Schrägstrichen.
FHNW
Plasmid Database
49
4.3
Implementation
In diesem Kapitel wird näher auf die Realisierung der einzelnen Use Cases eingegangen.
4.3.1
Iterationsphase 1
4.3.1.1 Use Case 1: Login
Nach Eingabe der Daten wird überprüft, ob ein Name (Email-Teil vor dem @), eine EmailEndung und ein Passwort eingegeben wurde. Die Endung wird anhand einer ID aus der
Datenbank ausgelesen und die Email-Adresse wird zusammengesetzt. Wenn die EmailAdresse mit dem Passwort übereinstimmt (Daten aus der DB) gelangt der User auf die
Home-Seite.
4.3.1.2 Use Case 2: Registrierung
Wenn der "accept"-Button in der EULA geklickt wurde, gelangt der User zurück auf die
Registrierungs-Seite und die Checkbox für die EULA wird aktiviert. Es werden wieder alle
Felder auf Vollständigkeit geprüft und in der Datenbank kontrolliert, ob die Email bereits
vorhanden ist. Wenn alles in Ordnung ist, wird ein Passwort generiert und zusammen mit
den anderen Daten in die Datenbank geschrieben. Das Passwort wird per Email an die
angegebene Adresse gesandt, mit dem Hinweis, das Passwort gleich zu ändern und einem
Link auf die Homepage.
4.3.1.3 Use Case 3: Registrierung löschen
Nach Prüfung aller Felder und Kontrolle in der Datenbank, ob Passwort zur jeweiligen
Email gehört, werden die User- und Bestell-Daten aus der Datenbank gelöscht.
4.3.1.4 Use Case 4: Forschungsgruppe anmelden
Die Email-Adresse des Administrators unterliegt nicht der Geheimhaltung, so dass ein User
auf der Registrierungs-Seite auf den Email-Button klicken kann. Es öffnet sich dann das
aktuelle Email-Programm des Users mit der Adresse des Administrators im "An"-Feld.
4.3.1.5 Use Case 5: EULA
Die End User License Agreement ist bei der Registrierung mit einem "agree"-Button
ausgestattet. Sie kann auch aus der Link-Liste aufgerufen werden. Dort besteht sie nur aus
Text und enthält keinen "agree"-Button.
FHNW
Plasmid Database
50
4.3.1.6 Use Case 6: Passwort vergessen
Nach Prüfung auf Vollständigkeit der Felder wird ein neues Passwort generiert, in die
Datenbank geschrieben und dem User per Email zugesandt, mit dem Vermerk, dieses
gleich zu ändern und einem Link auf die Homepage.
4.3.1.7 Use Case 7: Passwort ändern
Nach Prüfung aller Felder auf Vollständigkeit, wird in der Datenbank überprüft, ob das
Passwort zur Email stimmt und ob die beiden neu eingetragenen Passwörter
übereinstimmen. Trifft dies zu, wird das neue Passwort in die Datenbank eingetragen.
4.3.1.8 Use Case 8: Home
Auf der Home-Seite ist keine spezielle Funktionalität. Hauptsächlich Text und die Link-Liste,
welche auch auf jeder nachfolgenden Seite vorhanden ist.
4.3.1.9 Use Case 9: Logout
Im Logout wird nach session_start explizit die Session der U_ID zurückgesetzt, da anhand
dieser auf jeder Seite abgefragt wird, ob der User noch eingeloggt ist. Zusätzlich werden
alle Sessions gelöscht.
4.3.2
Iterationsphase 2
4.3.2.1 Use Case 10: Manuelle Eingabe
Für die Feature-Liste bei der manuellen Eingabe wurde Java Script verwendet. Mit der
Funktion "Eintraghinzufuegen" wird ein neues Feature in die Auswahlliste hinzugefügt und
mit der Funktion "EintragLoeschen" kann ein bereits ausgewähltes Feature wieder aus der
Liste gelöscht werden.
Wenn ein Feature bereits ausgewählt wurde und der User versucht, das Gleiche nochmals
zu wählen, erhält er eine Fehlermeldung, dass das Feature bereits selektiert wurde.
Sind neun Features ausgewählt, erhält der User ebenfalls eine Fehlermeldung, wenn er
versucht, ein Zehntes auszuwählen.
Beim "submit" werden alles Features selektiert und an die nächste Seite gesandt.
Wenn eine Datei angehängt wurde, wird diese mit file_get_contens ausgelesen. Dies hat
einen kleinen Performance-Vorteil, da man nicht explizit fopen angeben muss. Die
ausgelesenen Daten werden aufgesplittet und in Variablen gefüllt. Der Plasmidname wird
temporär in Grossbuchstaben umgewandelt und mit den bereits vorhandenen
Plasmidnamen in der Datenbank, die auch temporär in Grossbuchstaben umgewandelt
werden, verglichen. Die Sequenz wird auf Leerzeichen überprüft, welche entfernt werden.
FHNW
Plasmid Database
51
Danach wird die Sequenz in Grossbuchstaben umgewandelt und auf fehlerhafte Zeichen
überprüft, Leerzeichen werden entfernt. Dann wird die komplementäre, inverse Sequenz
erstellt. Die Daten werden in die Datenbank eingetragen und anhand der Plasmid-ID
werden die Features in die entsprechende Tabelle in der Datenbank eingetragen. Zudem
werden die Daten in die Flatfile-Datenbank geschrieben und per Shell-Skript wird formatdb
ausgeführt. Dies führt dazu, dass aus der Flatfile-Datenbank fünf Indexfiles erstellt werden,
welche für die Suche mit BLAST notwendig sind.
4.3.2.2 Use Case 11: Search
Die Suche kann anhand verschiedener Kriterien erfolgen. Diese können "and" oder "or"
verknüpft werden. Im Code wird hierzu eine Variable verwendet, um das ganze Query nicht
zweimal schreiben zu müssen. Wird eine Suche mit Volltext gestartet, so wird der Volltext
in der Sequenz und in der komplementären, inversen Sequenz gesucht. Diese sind der
Logik wegen immer "or"-verknüpft. Die für die Suche relevanten Felder wurden in eine View
zusammengefasst. Dazu wurden zuerst verschiedene Fälle definiert und die Zeiten
gemessen, die eine Abfrage mit View und ohne View benötigen. Sobald die Abfrage über
mehrere Tabellen geht, ist die View schneller. Wenn jedoch die Datenbank im Verlauf der
Zeit immer grösser wird, könnte die View langsamer werden. Aus diesem Grund, wurde
eine Version des Codes auskommentiert in der entsprechenden Datei stehen gelassen.
Dieser Code zeigt eine alternative Variante mit JOIN's über alle Tabellen.
Nachfolgend ist ein Auszug mit Verwendung der View aufgezeigt.
$query1="SELECT DISTINCT P_ID, pname, prating, pintegrity, pnumberfb FROM
`plasearchview` p WHERE ";
if (!$G_ID == "")
{
$query1.=" G_ID LIKE '";
$query1.=$G_ID;
$query1.="'";
$query1.=$tuk;
}
Die Kriterien werden nur an das Query gehängt, wenn Sie ausgewählt wurden.
Es besteht die Möglichkeit, bis zu drei Features auszuwählen. Wenn diese "and"-verknüpft
werden, muss eine Division gemacht werden, da ein Feld nicht mehrere Werte haben kann.
Die Division ist das Gegenstück der Addition. Die doppelte Verneinung der abzufragenden
Datensätze hebt sich auf, und es werden die gewünschten Resultate erzielt.
$query1 = "SELECT DISTINCT P_ID, pname, prating, pintegrity, pnumberfb FROM
`plasearchview` p WHERE "; ...
$query1.=" NOT EXISTS (SELECT 1 FROM `feature` f WHERE F_ID IN (";
$query1.=$qtmp;
$query1.=") AND NOT EXISTS (SELECT 1 FROM `feapla` fp WHERE f.F_ID = fp.F_ID
AND p.P_ID = fp.P_ID))";
FHNW
Plasmid Database
52
$qtmp steht für die ausgewählten Features. Die beiden Queries werden mit "AND"
aneinander gehängt.
Wenn der User nur seine eigenen Plasmide suchen möchte, wird anhand seiner User-ID
nach den Plasmiden gesucht. Wird in das Feld des Autors eine Email eingetragen, wird die
zugehörige ID aus der Datenbank ausgelesen.
Wurde eine Sequenz eingegeben, wird diese auf fehlerhafte Zeichen und Leerzeichen
überprüft und Leerzeichen werden entfernt.
Am Ende wird das letzte "or" oder "and" wieder entfernt und das Query wird abgesetzt.
4.3.2.3 Use Case 12: Search Result Form
Das Anzeigen der Resultate erfolgt im gleichen File wie die Überprüfung. (searchok.php).
Es werden maximal 20 Resultate angezeigt. Sollte es mehr haben, werden die ersten 20
Resultate angezeigt, mit einer Meldung, der User solle die Suche eingrenzen.
Der User kann auf den Plasmidnamen klicken und gelangt zur Detailansicht.
4.3.3
Iterationsphase 3
4.3.3.1 Use Case 13: Plasmid Detail Form
In der Detailansicht erhält man nähere Informationen zu einem Plasmid. Unter anderem die
Daten, die bei allfälligen Feedbacks eingegeben wurden. Wenn der User das angezeigte
Plasmid selbst eingetragen hat, wird ein "change"-Button angezeigt, durch dessen klicken,
er auf die nächste Seite gelangt. Dort hat der User die Möglichkeit, den Namen und die
Spezies zu ändern, sowie weitere Features hinzuzufügen. Es werden maximal neun
Features zu einem Plasmid eingetragen.
Aus der Detailansicht kann ein PDF-Dokument erstellt werden, um die Informationen zum
Plasmid auszuducken oder zu speichern.
Nachfolgend ein Auszug aus dem Code für die Erstellung des PDF-Dokumentes.
$pdf->SetFont('Arial','',11);
$this_var = $_SESSION['pdffeature'];
$pdf->MultiCell(180, 6, "$this_var");
$pdf->Ln();
Die Informationen werden mittels Sessions übergeben, und können so direkt verarbeitet
und im PDF dargestellt werden.
FHNW
Plasmid Database
53
4.3.3.2 Use Case 14: Bestellung Plasmid
Aus der Detailansicht kann der User eine Bestellung abgeben. Um den Lieferanten zu
ermitteln, wurde eine Art Liste generiert. Wenn noch niemand das Plasmid bestellt hat,
muss der Autor das Plasmid bis maximal fünf Mal versenden. Danach wird der älteste
Besteller ermittelt, der wiederum das Plasmid maximal fünf Mal versenden muss. Danach
folgt der nächst älteste Besteller und so weiter.
Im Programm wurde dies wie folgt gelöst. Wenn noch kein Lieferant zu dem Plasmid in der
Datenbank steht, ist der Autor Lieferant. Wenn ein Lieferant eingetragen ist, wird überprüft,
ob dieser bereits fünf Mal als Lieferant eingetragen ist. Wenn ja, wird anhand der I_ID nach
dem nächst ältesten Besteller gesucht.
Nachfolgend ein Auszug aus dem Code für die Suche nach den Lieferanten.
// Lieferant suchen, wenn noch nicht 5x versendet
$query3="SELECT supplier FROM `inquiry` WHERE P_ID LIKE'";
$query3.=$P_ID;
$query3.="' GROUP BY supplier HAVING COUNT(*) < 5";
...
// Lieferant suchen, wenn schon 5x versendet, nächsten nehmen
if ($supplier == "")
{
$query4="SELECT U_ID FROM `inquiry` WHERE U_ID NOT IN (SELECT supplier FROM
`inquiry` WHERE P_ID LIKE '";
$query4.=$P_ID;
$query4.="') AND P_ID LIKE '";
$query4.=$P_ID;
$query4.="' ORDER BY I_ID";
Wurde eine Bestellung abgegeben, werden verschiedene Datums-Daten in die Tabelle
eingetragen, um mittels Cronjob dem User eine Email senden zu können, in der er an das
Ausfüllen des Feedbacks erinnert wird. Zudem wird eine Email an den ermittelten
Lieferanten gesandt.
Die Suche nach dem Lieferanten wurde ursprünglich mit PHP in verschiedenen Schlaufen
und Abfragen programmiert. Die Lösung mit SQL-Abfragen ist jedoch eleganter und bietet
die bessere Performance.
4.3.3.3 Use Case 15: Login für Feedback
Erhält ein User eine Erinnerung an das Feedback, kann er auf dem im Email angegebenen
Link klicken. So gelangt er auf die Login-Seite für das Feedback. Im Link ist auch die
Plasmid_ID enthalten. Diese wird dann bis zum Feedback weitergegeben und direkt
eingetragen. Das heisst, es wird anhand der ID in der Datenbank nach dem Plasmidnamen
gesucht. Dieser Plasmidname wird dann in einer Dropdown-Liste zusammen mit allfälligen
weiteren bestellten Plasmiden des Users angezeigt. Alles andere ist wie beim normalen
Login, ausser dass auf dieser Seite keine Links zu Registrierung und Passwort vergessen
sind.
FHNW
Plasmid Database
54
4.3.3.4 Use Case 16: Feedback
Da die Sessions für die User_ID und die Plasmid_ID bei dem Feedback, welches aus dem
Link im Email erfolgt, anders ausgelesen werden, als auf der Home-Seite, wurden zwei
Seiten für das Feedback erstellt. Die Verarbeitungsseite ist jedoch dieselbe. Da bereits auf
der Formular-Seite nur diejenigen Plasmide in der Dropdown-Liste erscheinen, die der User
bestellt hat, muss nicht mehr kontrolliert werden, ob der User das Plasmid auch wirklich
bestellt hat. Wenn alles in Ordnung ist, werden einige Berechnungen ausgeführt und die
Daten in die Datenbank geschrieben. Zudem wird eine Email mit diesen Daten an den
Autor gesandt.
Mittels Cronjob wird nächtlich ein Programm gestartet, welches anhand der eingetragenen
Daten in der Tabelle "Inquiry" erkennt, ob ein User ein Feedback nicht in der nötigen Frist
ausgefüllt hat. Ist dies der Fall, wird eine Erinnerung an das Feedback per Email an die
User gesendet.
4.3.4
Iterationsphase 4
4.3.4.1 Use Case 17: Enter Automatic
Bei der automatischen Eingabe können bis zu 20 Dateien gleichzeitig eingefügt werden.
Eine Schleife erledigt dies für jede Datei.
$i=0;
while($i<20)
{
$upload[$i]=$_FILES['upload']['tmp_name'][$i];
...
Nach diversen Kontrollen wird eine Datei ausgelesen. Dies ist fast gleich wie bei der
manuellen Eingabe. Die Daten werden ausgelesen und aufgesplittet. Leerzeichen in der
Sequenz werden entfernt.
Nachfolgend ein Auszug aus dem Code für das Auslesen der Dateien.
...
$filedata[$i] = file_get_contents($upload[$i]);
$vorarbeit[$i] = preg_replace("/>/", "", $filedata[$i]);
$einzeln[$i] = preg_split("/\n/", $vorarbeit[$i]);
$tmpname[$i] = $einzeln[$i][0];
$tmpname[$i] = preg_split("/ /", $tmpname[$i]);
$pname[$i] = $tmpname[$i][0];
for ($f = 1; $f < filesize($upload[$i]); $f++)
{
$full[$i].=$einzeln[$i][$f];
}
$clearStrings[$i] = array("\n", "\r");
foreach($clearStrings[$i] as $clearString[$i])
{
$full[$i] = str_replace($clearString[$i], "", $full[$i]);
}
FHNW
Plasmid Database
55
Danach wird die Sequenz in Grossbuchstaben umgewandelt und auf fehlerhafte Zeichen
überprüft.
Auch hier wird die komplementäre, inverse Sequenz erzeugt. Die Daten werden in die
Datenbank und in die Flatfile-Datenbank eingetragen und per Shell-Skript wird formatdb
ausgeführt. Um nicht jeden Eintrag einzeln zu senden, werden sie am Ende gebündelt
übertragen. Dies wurde mit array_push und array_pop realisiert. Zudem werden die Daten
gebündelt an ein Programm gesandt, welches im Hintergrund läuft und die passenden
Features zu den Plasmiden sucht. Diese automatische Featureerkennung wurde auch mit
Shell-Skript programmiert, welche als Alternative verwendet werden könnte.
Für die automatische Featureerkennung wurde ein weiteres Programm geschrieben,
welches mittels Cronjob einmal nächtlich läuft und eine automatische Featureerkennung
durchführt. Bei den Plasmiden, für die eine Suche durchgeführt wurde, trägt das Programm
ein Datum ein. So muss es jeweils nur diejenigen Plasmide für die Featureerkennung
verwenden, welche noch kein Datum in diesem Feld haben.
Es wird immer überprüft, ob bereits neun Features zu einem Plasmid eingetragen sind.
4.3.4.2 Use Case 18: Change Plasmid
Nach Prüfung aller Felder werden die Daten in die Datenbank geschrieben. Es wird geprüft,
ob bereits neun Features zu dem Plasmid vorhanden sind.
4.3.4.3 Use Case 19: Copyright
Wie in der Konzeptphase erwähnt, steht hier nur Text.
4.3.4.4 Use Case 20: Help
Die PDF-Version des Help wurde mit Latex erstellt.
Die HTML-Version besteht nur aus Text.
4.3.4.5 Use Case 21: FAQ
Auch bei den Frequently Asked Questions steht nur Text.
FHNW
Plasmid Database
56
4.3.5
Iterationsphase 5
4.3.5.1 Use Case 22: BLAST
Für die Suche mit dem BLAST-Algorithmus werden zwei temporäre Dateien erstellt, die am
Ende wieder gelöscht werden. Um keine Verwechslungen zu riskieren, wird jeweils die
User-ID an die Datei gehängt.
Nachfolgend ein Auszug aus dem Code für die Suche mit BLAST.
$infile = "/srv/plasmiddb/blast-2.2.15/bin/tmpin" . $U_ID . ".txt";
$inhandle = fopen($infile, "w");
$input = ">" . $pname . "\n" . $full . "\n";
fputs($inhandle, $input);
fclose($inhandle);
$command = "/srv/plasmiddb/blast.sh $U_ID";
exec($command);
$outfile = "/srv/plasmiddb/blast-2.2.15/bin/tmpout" . $U_ID . ".txt";
$outhandle = fopen($outfile, "r");
for ($f = 0; $f < 41; $f++)
{
$line[$f] = fgets($outhandle);
}
Der User gibt eine Sequenz ein, aus der ein Input-File erstellt wird. Dann wird ein ShellSkript gestartet, welches den BLAST ausführt. Dieser erstellt ein Output-File, aus welchem
die Plasmid_ID, der Plasmidname und der E-Value zur Anzeige ausgelesen werden. Auch
hier werden nur die ersten 20 Resultate angezeigt.
Da der E-Value am Ende der Zeile steht und somit auch am Ende des Arrays wird rekursiv
nach dem Value gesucht und ausgelesen.
Nachfolgend ein Auszug aus dem Code für das Auslesen des Values.
while (($i < 41) and (!preg_match("/>/", $line[$i])))
{
$zeile[$i] = preg_split("/(\.)|( )/", $line[$i]);
$P_ID[$i] = $zeile[$i][0];
$pname[$i] = $zeile[$i][1];
$zeile2[$i] = preg_split("/ /", $line[$i]);
$h = 0;
for ($z = sizeof($zeile2[$i]); $z > 0, $h < 2; $z--)
{
if ((!$zeile2[$i][$z] == "") and ($h < 2))
{
$value[$i] = $zeile2[$i][$z];
$h++;
}
} ...
$i++;
}
Der User kann auch hier auf den Plasmidnamen klicken und gelangt zur Detailansicht.
FHNW
Plasmid Database
57
4.3.6
Crontab
Für die Cronjobs, die automatische Feedback-Erinnerung und die automatische
Featureerkennung, wurden zwei Einträge im Crontab erstellt:
0 0 * * * /usr/bin/php /srv/plasmiddb/kronfeedback.php
0 0 * * * /usr/bin/php /srv/plasmiddb/kronallf.php
Die erste "0" steht für Minute (zur vollen Stunde), die zweite "0" steht für Stunde
(Mitternacht), das erste "*" steht für Tag des Monats (täglich), das zweite "*" steht für Monat
(monatlich) und das dritte "*" steht für Wochentag (täglich).
Die beiden Programme laufen somit täglich um Mitternacht.
4.4
Sicherheit
Die Funktion strip_tags entfernt HTML- und PHP-Tags aus einem String, so dass keine
Code-Injection stattfinden kann. Jede Variable die aus einem Textfeld erfolgt, wurde so
codiert.
Auf jeder Seite wird nach der Session U_ID abgefragt. Wenn sich ein User ausgeloggt hat,
kann man die Seite höchstens noch ansehen, aber nicht mehr absenden. Je nach Browser
wird die Seite nicht angezeigt. Zudem kann man nicht im Adressfeld den Namen einer Seite
eingeben, also zum Beispiel: http://fgcz-plasmiddb.unizh.ch/search.php. Wird dies versucht,
gelangt man automatisch zum Login. Somit ist auch keine SQL-Injection möglich.
Da die User eine Email der angegebenen Institutionen haben müssen, und das Passwort
nicht vom User selbst gesetzt wird, sondern per Email gesandt wird, kann sich nicht
jedermann anmelden.
Email-Adressen die auf einer Homepage ersichtlich sind, können anhand eines Programms
ausgelesen und für Spam missbraucht werden. Damit dies nicht geschieht, wurden die
Email-Adressen mit Java-Script geschrieben und vom "@"-Zeichen gelöst.
4.5
Refactoring
Der Code wurde fortlaufend überprüft. Das heisst, die Struktur wurde verbessert, damit die
Wartbarkeit und Erweiterbarkeit leichter fällt. Zudem wurde der Code wo immer möglich
gekürzt und wenn nötig wurden Variablennamen geändert, damit sie ihrer Funktionalität
entsprechen.
4.6
BLAST9
BLAST steht für Basic Local Alignment Search Tool. Es ist eines der wichtigsten Tools in
der Bioinformatik. Mittlerweile gibt es verschiedene Versionen des BLAST. Die am meisten
verbreiteten sind der NCBI-BLAST und der WU-BLAST.
9
Zusammengefasst aus: Ian Korf, Mark Yandall & Joseph Bedell, "BLAST", 2003, O'Reilly
FHNW
Plasmid Database
58
Wir haben für unsere Datenbank den BLAST vom NCBI (National Center for Biotechnology
Information) verwendet. WU steht für Washington University in St. Louis.
4.6.1
Programme
Es gibt fünf verschiedene BLAST Programme.
•
BLASTN für Nukleotid-Datenbanken, Nukleotid-Suche
•
BLASTP für Protein-Datenbanken, Protein-Suche
•
BLASTX für Protein-Datenbanken, Nukleotide in Proteine übersetzte Suche
•
TBLASTN für Nukleotide in Proteine übersetzte Datenbanken, Protein-Suche
•
TBLASTX für Nukleotide in Proteine übersetzte Datenbanken, Nukleotide in
Proteine übersetzte Suche.
Es gäbe noch verschiedene andere BLAST Derivate und BLAST Programme die auf eine
spezielle Art und Weise funktionieren. Auf diese Programme einzugehen würde den
Rahmen dieser Dokumentation sprengen.
4.6.2
Vorbereitung
Das NCBI bietet verschiedene Pakete für zahlreiche Betriebssysteme an. Nach dem
Download führt man einen Test mit einer Testdatenbank und einem Testfile aus. Zuerst
muss das Programm „formatdb“ ausgeführt werden. Dieses Programm erstellt sieben
Indexfiles. Dann kann das Programm „blastall“ ausgeführt werden, welches ein Output-File
erstellt.
Die Testdatenbank ist eine Flatfile-Datenbank. Verwendet man formatdb für seine eigene
Datenbank, muss die Syntax in dieser Flatfile-Datenbank leicht geändert werden. Das TestFile besteht aus der zu suchenden Sequenz. Dieses File muss in FASTA-Format sein. Je
nachdem mit welchen Parametern man formatdb startet, werden sieben oder fünf Indexfiles
erstellt. Für die Plasmid Database reicht es aus, fünf Indexfiles zu erstellen. Anhand dieser,
kann nun der BLAST seine Suche starten. Dafür wird BLASTN aus dem Paket blastall
verwendet. Im Output-File stehen die gefundenen Plasmid_ID's, Plasmidnamen, die ScoreWerte und die E-Values. Zusätzlich wird aufgezeigt, an welchen Stellen sich die Sequenzen
unterscheiden.
FHNW
Plasmid Database
59
Auszug aus dem Code für blastall;
#!/bin/sh
cd /srv/plasmiddb/blast-2.2.15/bin/
./blastall -p blastn -d dbforblast -i tmpin${1}.txt -o tmpout${1}.txt
4.6.3
BLAST Algorithmus
Der Suchalgorithmus besteht aus drei einzelnen Schritten.
1. Indexsuche:
Zuerst wird aus der Suchsequenz ein Index mit einer bestimmten Länge erstellt. Mit diesem
werden die Sequenzen in den Indexfiles durchsucht. BLAST definiert einen Hit als einen
Treffer mit einem Score, welcher über einem bestimmten Schwellwert liegt. Bei Proteinen
sind Hits auch ähnliche Positionen, bei Nukleotiden wird nur nach identischen Positionen
gesucht.
2. Suche nach dem zweiten Hit:
Findet BLAST einen Hit, so muss sich in direkter Nachbarschaft ein zweiter Hit befinden.
Nur wenn ein zweiter Hit vorhanden ist, werden beide im weiteren Verlauf der Suche
berücksichtigt.
3. Gapped Alignment:
Gibt es einen zweiten Hit, werden beide solange bidirektional ausgedehnt, bis sich der
Score nicht mehr erhöhen lässt.
Je kleiner der E-Value ist, desto ähnlicher ist die Sequenz. Ist der E-Value sehr hoch,
handelt es sich um einen Zufallstreffer.
4.6.4
Alternativen zu BLAST9
FASTA:
Pearson and Lipman haben 1988 den FASTA-Algorithmus entwickelt. FASTA ist hier nicht
zu verwechseln mit dem FASTA-Format, welches eine bestimmte Syntax eines Files
beschreibt. Der Algorithmus sucht nach Sequenzähnlichkeiten zwischen einer Sequenz und
einer Gruppe anderer Sequenzen vom gleichen Typ. FASTA erstellt einen Index von der
Suchsequenz und vergleicht die Indexeinträge mit den Sequenzen in der Datenbank.
Identische Einträge werden im weiteren Verlauf verknüpft und die besten Alignments mit
dem Smith & Waterman Algorithmus neu berechnet. Ziel des BLAST war es, auf Basis des
FASTA die Datenbankabfrage zu beschleunigen.
9
Zusammengefasst aus: Andrea Hansen, "Bioinformatik", 2004, Birkhäuser
FHNW
Plasmid Database
60
SSAHA:
SSAHA steht für Sequence Search and Alignment by Hashing Algorithm und wurde von
Herrn Ning und Kollegen am Sanger Center entwickelt. Grundsätzlich unterscheidet sich
SSAHA vom BLAST dadurch, dass statt eines Index aus der Suchsequenz ein Index aus
der Datenbank erzeugt wird. Dieser Index wird in einer Hash-Tabelle gespeichert. In der
Hash-Tabelle stehen die Positionen der Kombination von Basen und wie oft diese
vorkommen.
SSAHA wird verwendet für die Suche nach sehr ähnlichen Sequenzen. SSAHA ist sehr
schnell, man benötigt aber einen leistungsstarken Computer, da die komplette Datenbank
in den Hauptspeicher geladen werden muss.
Needelmann & Wunsch (1970):
Der Needelmann & Wunsch Algorithmus ist nur für eng verwandte Sequenzen. Er ist einer
der ersten Algorithmen zur Berechnung eines paarweisen Alignments. Der Algorithmus
erstellt als erstes eine zweidimensionale Matrix mit den zu vergleichenden Sequenzen.
Jedes Alignment der Sequenz lässt sich als Pfad durch diese Matrix beschreiben, in der die
Paare aus dem Alignment jeweils eine Zelle repräsentieren. Sie versuchen die Sequenzen
über ihre gesamte Länge zu vergleichen. Von allen möglichen Wegen durch die Matrix
wählt man dabei den Weg mit der höchsten Endsumme. Die Summe ergibt sich aus der
Addition der Werte in jeder einzelnen Substitutionsmatrix. Es wird auch mitgerechnet, ob
ein Gap beim Weg durch die Matrix entsteht.
Smith & Waterman (1981):
Der Smith & Waterman Algorithmus verfolgt eine andere Strategie als Needelman &
Wunsch. Ziel ist es, den längsten gemeinsamen Bereich von zwei Sequenzen mit der
grössten Ähnlichkeit zu finden. Dieser Algorithmus liefert immer ein Resultat.
Bio Perl:
Bio Perl ist ein Tool, welches in der Bioinformatik häufig verwendet wird. Mit Bio Perl kann
man beispielsweise Sequenzen im FASTA-Format erzeugen.
my $out = Bio::SeqIO->new(-file => '>testseq.fsa', -format => 'Fasta');
$out->write_seq($seq);
Mit dem "STRECHER" kann man das beste globale Alignment zwischen zwei Sequenzen
finden.
Mit BioPerl db kann man Sequenz-Informationen in einer BioSQL-Datenbank speichern.
EMBOSS ist ein ähnliches Tool, in C++ programmiert und Bio-Python ist, wie der Name
sagt, in Python programmiert.
FHNW
Plasmid Database
61
4.6.5
Performance und Tuning der Datenbank10
In diesem Kapitel werden Möglichkeiten aufgezeigt, mit welchen die Datenbank optimiert
werden kann. Diese konnten aus zeitlichen Gründen nur teilweise realisiert werden.
4.6.5.1 Query-Performance
4.6.5.1.1Query-Cache
Wenn der Query-Cache aktiviert wurde, versucht MySQL die Ergebnisse einer SELECTQuery zuerst aus dem Query-Cache abzurufen. MySQL nimmt exakt den Query-Text, den
es empfängt, das heisst, MySQL unterscheidet zwischen Gross- und Kleinschreibung im
Query.
Das Caching funktioniert nur bei SELECT-Queries, weil es nur bei diesen sinnvoll ist.
MySQL prüft nur die ersten drei Zeichen der Query auf SEL.
Wenn ein Query zum Beispiel nur einmal täglich ausgeführt wird, ist ein Caching unnötig.
Man kann den Query-Cache auch umgehen, indem man SELECT SQL_NO_CACHE
schreibt.
4.6.5.1.2 Parsing
Queries die nicht im Cache liegen, müssen in deren einzelne Komponenten zerlegt werden.
Das nennt man Parsing. Die Query wird überprüft und MySQL sammelt einige
Informationen. Dann wird mit Hilfe des Query-Optimizers entschieden, was getan werden
soll. Der Query-Optimizer versucht anhand der Informationen die effizienteste Ausführung
zu ermöglichen.
4.6.5.1.3 EXPLAIN
Mit dem EXPLAIN-Befehl kann man herausfinden, wie MySQL vorgeht, wenn es ein Query
ausführt. Auf diese Weise sieht man, wie das Hinzufügen eines Indizes oder die einfache
Umformulierung einer Query, einen vorhandenen Index besser nutzen und die Performance
stark verbessern kann.
4.6.5.1.4Query-Tricks
Manchmal optimiert MySQL, scheinbar einfache Queries, nicht in der erwarteten Art und
Weise. Um die Performance zu verbessern, kann es sein, dass man mit Hilfe einer
temporären Variablen, das Query in zwei Queries aufteilen sollte.
10
ZAWODNY JEREMY & BALLING DEREK, HIGH PERFORMANCE MYSQL, 2005, O’REILLY
FHNW
Plasmid Database
62
4.6.5.2 Tuning
4.6.5.2.1 Benchmarking
Ursprünglich kommt der Begriff Benchmark aus der Landvermessung und bezeichnet einen
fixen Punkt in der Landschaft. Mit Benchmarking ist in diesem Zusammengang das
Orientieren an diesem Punkt gemeint. Im Falle der Datenbank-Systeme werden die
Ergebnisse des Benchmarking eingesetzt, um die einzelnen Softwareprodukte in eine
standardisierte Leistungsskala einordnen zu können. Das Ergebnis des Benchmarking
ergibt für jedes getestete Produkt einen sogenannten Benchmark-Wert, der an einer
imaginären Messlatte, z.B. dem Wert des auf dem Markt führenden Softwareprodukts,
gemessen werden kann. Je nach Höhe des ermittelten Benchmark-Werts kann nun erkannt
werden, ob das getestete Datenbank-System höher, niedriger oder gleichhoch wie die zu
vergleichende Messlatte in die Leistungsskala eingeordnet werden kann.
MySQL bietet verschiedene Benchmarking-Tools an.
4.6.5.2.2I/O-Flaschenhälse
Festplatten-(I/O-)Flaschenhälse sind das am häufigsten vorkommende PerformanceProblem bei MySQL. Sie werden üblicherweise durch ineffektive Queries verursacht - was
bedeutet, dass MySQL zu viele Zeilen einlesen muss, um die von Ihnen gewünschten
Informationen zu ermitteln. In der Regel bedeutet dies, dass Ihre Queries keinen Index
verwenden, oder dass mit einem Index gearbeitet wird, der für diese besondere Query nicht
besonders effektiv ist.
4.7
Server FGCZ
Für die Plasmid Database wurde ein Platz auf dem Server des Functional Genomics Center
Zurich eingerichtet. Der Linux-Debian-Server läuft mit dem Web-Server Apache 2.0.
Mit der Version 2.0 liefert Apache vorgefertigte Multi-Processing-Module (MPMs) mit. Der
Standard bei Unix-Plattformen ist "prefork". Das heisst, ein Eltern-Prozess erzeugt immer
einen Vorrat von Kind-Prozessen für die eingehenden HTTP-Anfragen. Da jeder Prozess
genau eine Anfrage gleichzeitig bearbeitet, kann durch einen Fehler in einem solchen
Prozess auch nur eine Verbindung mit dem Server verloren gehen. Das ist ein Vorteil bei
dynamisch generierten Seiten.
Für Thread-Unterstützung gäbe es das MPM "worker". Auf dem Server des FGCZ ist
"prefork" installiert.
FHNW
Plasmid Database
63
4.8
Backup
4.8.1
Grundlegende Begriffe
4.8.1.1 Disaster Recovery
Disaster Recovery ist die Wiederherstellung nach einem schwerwiegenden Fehler. Dies
sind beispielsweise Hardware- oder Software-Fehler, versehentliches Löschen von Daten
oder wenn der Server beschädigt oder entwendet wurde.
Ein solcher Fall tritt zwar selten ein, aber die Folgen können verheerend sein. Die Backups
sollten an einem anderen Ort als im Serverraum aufbewahrt werden.
4.8.1.2 Auditierung
Verfügt man über ältere Backups, gelangt man relativ einfach an ältere Daten, indem man
die Backups auf einen Testserver einspielt und einige Queries ausführt. Dies ist zum
Beispiel interessant für die Suche nach beschädigten Daten, zum Berechnen der
Wachstumsraten der Datenbank oder um neu entdeckte Fehler nachträglich zu korrigieren.
4.8.2
Art und Weise
4.8.2.1 Dump
Ein Dump ist ein logisches Backup. Das heisst, das Ergebnis sind eine oder mehrere
Dateien, welche die SQL-Anweisungen enthalten, die notwendig sind, um die Daten
wiederherzustellen. Die Datei kann mit einem Editor geöffnet und bearbeitet werden, wenn
man zum Beispiel nur einen Teil der Records wiederherstellen möchte. Die Dumps können
mit mysqldump erzeugt werden. Beim Wiederherstellen muss die Datei nur an das
Kommandozeilen-Tool mysql übergeben werden.
Ein Nachteil bei Dumps ist, dass die Datei wesentlich mehr Speicherplatz als die Tabelle
selbst benötigt. Da aber in den InnoDB-Datendateien häufig viel Speicher ungenutzt bleibt,
braucht ein Backup bei InnoDB-Tabellen weit weniger Platz.
4.8.2.2 Binlog
Binlog hat eine ähnliche Strategie wie Dumps. Es ist ein physisches Backup und der SQLServer muss im Binärmodus gestartet werden.
FHNW
Plasmid Database
64
4.8.2.3 Roh-Backup
Roh-Backups werden häufig genutzt, um einen aktiven Server zu sichern. Es ist eine
direkte Kopie der Datendateien, wie sie auf der Platte vorliegen. Dazu müssen die Tabellen
gesperrt werden.
Für MyISAM sind es die Tools mysqlhotcopy und mysqlsnapshot.
Für InnoDB geht das nur mit dem InnoDB Hot-Backup-Tool, welches relativ kostengünstig
gekauft werden kann.
4.8.2.4 Online / Offline
Die Frage ob man online- oder offline-Backups macht, erübrigt sich, wenn man das InnoDB
Hot-Backup-Tool nicht kaufen möchte. Dann ist nur ein offline-Backup möglich. Das hat den
Vorteil, dass man sich um die Konsistenz der Daten keine Sorgen machen muss.
Eine Möglichkeit bestände darin, einen Slave-Server zu konfigurieren und dort ein Backup
durchzuführen.
4.8.3
Techniken
4.8.3.1 Online / mysqldump
Mysqldump ist ein Kommandozeilen-Werkzeug. Folgender Befehl erzeugt eine DumpDatei, in der alle nötigen Informationen sind, um die Datenbank plasmiddb
wiederherzustellen.
mysqldump --single-transaction -u plasmiddb -pPassword -x --databases plasmiddb >
dump.sql
Die Wiederherstellung funktioniert wie folgt:
mysql --single-transaction -u plasmiddb -pPassword < dump.sql
--single-transaction verwendet eine konsistente Leseoperation und gewährleistet, dass die
von mysqldump erkannten Daten nicht geändert werden.
FHNW
Plasmid Database
65
4.8.3.2 Offline / Binär-Backup aller Dateien erstellen
•
MySQL-Server herunterfahren
•
Datendateien (ibdata-Dateien und .ibd-Dateien) an einen sicheren Ort
kopieren
•
alle ib_logfile-Dateien an einen sicheren Ort kopieren
•
my.cnf-Konfigurationsdatei(en) an einen sicheren Ort kopieren
•
.frm-Dateien für InnoDB-Tabellen an einen sicheren Ort kopieren
Der MySQL-Server muss im Binärmodus betrieben werden, dann kann das binlog auf die
Datenbanksicherung übertragen werden:
mysqlbinlog yourhostname-bin.123 | mysql
Um den MySQL-Server nach einem Absturz wiederherzustellen, muss man ihn lediglich
neu starten. InnoDB sucht automatisch die Logs und versetzt die Datenbank wieder in den
aktuellen Zustand. InnoDB rollt unbestätigte Transaktionen automatisch zurück, die zum
Zeitpunkt des Absturzes anhängig waren.
Nach der Wiederherstellung der Sicherungsdateien aus dem Backup muss man mit
mysqlbinlog und mysql die Änderungen aus den binlogs anwenden, die nach dem Backup
eingetreten sind.
4.8.4
Testen
Um unliebsame Überraschungen zu vermeiden, ist nach der erstmaligen Erstellung das
Backup selbst zu testen. Das heisst, das Backup ist auch wirklich nach Erstellung auf einer
anderen Adresse (anderem Datenbank-Namen) zurückzuspielen. Es reicht nicht, einfach
das Backup-Log auf korrekte Jobdurchführung zu überprüfen. Eventuell werden Daten
trotzdem nicht sichergestellt, oder das Recovery selbst könnte fehlerhaft sein.
Das Backup einer Datenbank fällt in den Aufgabenbereich des Administrators.
FHNW
Plasmid Database
66
4.9
Testphase
Für die Testphase wurde ein ausführlicher Testplan erstellt, welcher im Anhang
eingegliedert ist. Die Testphase wird hier in zusammengefasster Form wiedergegeben.
4.9.1
Testfälle
Testfälle lassen sich in positive und negative Testfälle unterscheiden. Dies ist abhängig
vom gültigen oder ungültigen Vorbedingungen und Eingaben. Negativ-Tests, so genannte
Robustheitstests, überprüfen das Verhalten des Testobjektes in Folge ungültiger
Vorbedingungen oder Eingaben.
Die Testfälle wurden anhand der Iterationsphasen und ihren Use Cases erstellt.
Selbstverständlich wurde der Quellcode auch fortlaufend getestet.
Fehler wurden, wo möglich, sogleich behoben und die jeweiligen Use Cases nochmals
getestet. Nach den Retestings wurde nochmals vor der Alpha- und Beta-Testphase ein
Komplett-Test durchgeführt.
Der Alpha-Testprozess wurde weitergeführt, bis das ausgelieferte System eine gute
Implementierung der Systemanforderungen darstellte.
Der Beta-Test wurde durch eine Testgruppe durchgeführt. Dafür wurden Fragebogen
erstellt und am Ende der Testphase ausgewertet.
4.9.2
Lasttest
Es gibt verschiedene Open Source Tools, die man für einen Lasttest verwenden könnte.
Beispielsweise den Proxy-Sniffer, JMeter oder Selenium. Diese Tools sind meist
Plattformabhängig, sehr zeitintensiv in der Implementierung und da sie kostenlos sind,
werden zum Teil nicht alle Ergebnisse angezeigt. Aus diesem Grund wurde ein eigener
kleiner Lasttest realisiert. Mit einem eigens geschriebenen Programm wurden 80 FASTAFiles generiert. Auf vier verschiedenen Computern wurden je 20 Files auf der Seite des
"Automatic Entry" eingetragen und exakt gleichzeitig hochgeladen.
Ergebnis: 0.01 Sekunden bei Mac und XP
0.03 Sekunden bei Win 98
Bei einem zweiten kleinen Lasttest wurde die Zeit inklusive der automatischen
Featureerkennung gerechnet. Es wurden wieder 80 FASTA-Files gleichzeitig hochgeladen,
die jeweils drei zu erkennende Features beinhalteten. Zu diesem Zeitpunkt waren 37
Features in der Datenbank.
Ergebnis: 0.50 Sekunden bei Mac
0.46 Sekunden bei Win XP SP1
0.45 Sekunden bei Win XP SP2
FHNW
Plasmid Database
67
4.9.3
Testergebnis
Durch die umfangreiche Testphase konnten bereits nach dem Alpha-Testprozess alle
ersichtlichen Mängel behoben werden. In der Beta-Testphase wurde dann nur festgestellt,
dass das FASTA-Format der Dateien nicht immer nach Standard erfüllt war. Dies führte
dazu, dass durch Codeänderungen nun auch Leerzeichen und Leerzeilen in den
Sequenzen akzeptiert, beziehungsweise entfernt werden. Dies entspricht zwar nicht dem
erwähnten Standard, ist jedoch für einen reibungslosen Ablauf erforderlich.
Die detaillierten Ergebnisse sind im Anhang ersichtlich.
4.10
Herausforderungen
4.10.1 BLAST
Den BLAST-Algorithmus einzubinden war insofern eine Herausforderung, als dass es kaum
Vergleichsmöglichkeiten gibt. Verschiedene Datenbank-Systeme, zum Beispiel BLASTgres
von PostgreSQL, Alkahest NuclearBLAST in MySQL, The BLAST MySQL Database und
Sequence Matching and Alignment in Oracle©, bieten erweiterte Funktionen oder
Datentypen für Sequenzinformationen und Middleware für dynamischen Zugriff auf Dienste
wie der BLAST.
Die in Plasmid Database implementierte Lösung verfolgt einen anderen Ansatz.
4.10.2 Datenbank
Die Suche nach Plasmiden kann je nach Auswahl der Kriterien über mehrere Tabellen
stattfinden und eine Division beinhalten. Die dazu erstellte View und die Division bedurften
einiger Überlegung.
4.11
Probleme
Die Plasmid Database wurde zuerst auf "localhost" implementiert. Da PHP eine serverseitig
interpretierte Sprache ist, lohnt es sich den Apache Webserver auf dem eigenen Computer
einzurichten. So muss man die Files nicht erst auf einem entfernten Server hochladen, um
Fehler zu erkennen. Dies führte jedoch zu einigen wenigen Problemen bei der
Implementierung auf dem Server. Gewisse Fehler umgeht "localhost", zum Beispiel, dass
vor der Anweisung "header (location: ...)" keine Ausgabe sein darf.
Da nur der Administrator Zugriff auf die Konfigurationsdatei von PHP hat, mussten einige
Änderungen an den Einstellungen jedes Mal gemeldet werden.
Bei der Installation von MySQL wurde vom Administrator kein root-Passwort gesetzt. Wir
haben das Passwort gesetzt, doch nach der Installation von phpMyAdmin wurde es vom
Administrator wieder überschrieben und wir mussten es nochmals ändern.
Der Zugriff auf den Server muss per SSH stattfinden, die Verbindung wird jedoch nach
kurzer, inaktiver Zeit geschlossen.
FHNW
Plasmid Database
68
Ein weiteres Problem stellte das Format der hochzuladenden Dateien dar. Es gibt zwar
eine offizielle Beschreibung des FASTA-Formats, doch wurde gewünscht, dieses nicht zu
streng zu befolgen. Das heisst, es sollten Leerzeichen und Leerzeilen ignoriert werden.
FHNW
Plasmid Database
69
5
Fazit und Ausblick
Anhand dieses praxisorientierten Auftrages konnten wir gemeinsam in der uns zur
Verfügung gestellten Zeit ein Informatikprojekt über alle Phasen durchführen und aus
unserer Sicht erfolgreich zur Produktionsreife bringen. Dazu bedurfte es vieler
gemeinsamer Diskussionen, Aufgabenaufteilungen nach Stärken und Neigungen,
Konsensfindungen und Abstimmungsarbeiten.
Während der uns zur Verfügung gestellten zehn Wochen konnten wir uns in Teamarbeit
weiterentwickeln, vieles in den drei Jahren der Fachhochschule Gelernte anwenden, Neues
erlernen und etwelche Erkenntnisse fachlicher wie persönlicher Natur dazu gewinnen.
Diese Diplomarbeit war inhaltlich sehr interessant und zeitintensiv, und auch die Freude an
der Teamarbeit kam nicht zu kurz.
5.1
Weiterführung durch das FGCZ
Es wurde ein Benutzerhandbuch geschrieben, in dem vor allem auf die
Datenbankadministration eingegangen wird. Das Benutzerhandbuch ist im Anhang
eingegliedert.
5.1.1
Forum
Als Plattform für die Kommunikation der User untereinander, könnte ein Forum
implementiert werden.
5.1.2
R-Tree-Indizes
R-Tree-Indizes werden für räumliche oder N-dimensionale Daten genutzt. Die erwähnten
Suchalgorithmen verwenden meistens Matrizen. Wenn man nun die Sequenz bereits so in
der Datenbank ablegt, kann man sich einige Teile des Algorithmus sparen.
FHNW
Plasmid Database
70
5.1.3
Die Storage Engine
Mit MySQL 5.1 hat die Firma MySQL AB eine Architektur für eine Pluggable Storage
Engine eingeführt. Dadurch ist es jetzt möglich, neue Speicher-Engines zu erstellen und
einem laufenden MySQL Server hinzuzufügen, ohne den Server selbst neu kompilieren zu
müssen.
Der einfachste Weg zur Implementierung einer neuen Speicher-Engine besteht darin, die
EXAMPLE-Engine zu kopieren und zu modifizieren.
Eine Kombination aus InnoDB und R-Tree-Indizes wäre für eine Suche nach ähnlichen
Sequenzen eventuell ganz sinnvoll.
Ein weiterer Ansatz ist die Storage Engine NDB von MySQL. Dies ist eine geclusterte
Speicher-Engine und ist geeignet für eine Cluster-Lösung.
5.1.4
Alignment
Das Vergleichen von Sequenzen könnte man auch in PHP programmieren. Eine
dynamische Programmierung ist möglich und die Performance bei PHP könnte eine
Konkurrenz darstellen.
FHNW
Plasmid Database
71
6
Quellenverzeichnis
6.1
Abbildungsverzeichnis
6.1.1
Grafiken
6.1.2
Grafik 1:
Anwendungsfalldiagramm
16
Grafik 2-5:
Zeitplan MS Project
Grafik 6:
Workflow
40
Grafik 7:
Home-Seite
41
Grafik 8:
UML-Diagramm
25 - 28
48 - 49
Tabellen
Tabelle 1:
Beschreibung der Aktoren
17
Tabelle 2:
MySQL vs. PostgreSQL
31
Tabelle 3:
MyISAM vs. InnoDB
33
Tabelle 4:
Beziehungen ER-Modell
38
Tabelle 5:
Iterationsphasen
42
FHNW
Plasmid Database
72
6.2
Bibliographie
Selzer Paul, Marhöfer Riachard, Rohwer Andreas: "Angewandte Bioinformatik", Springer
(2004)
Steger Gerhard: "Bioinformatik, Methoden zur Vorhersage von RNA- und
Proteinstrukturen", Birkhäuser (2003)
Hansen Andrea: "Bioinformatik, Ein Leitfaden für Naturwissenschaftler", Birkhäuser (2004)
Sommerville Ian: "Software Engineering", Addison-Wesley (2001)
Lubkowitz Mark: "Webseiten programmieren und gestalten", Galileo Press (2005)
Zawodny Jeremy & Balling Derek: "High Performance MySQL", O'Reilly (2005)
Gibas Cynthia & Jambeck Per: "Einführung in die praktische Bioinformatik", O'Reilly (2002)
Korf Ian, Yandell Mark & Bedell Joseph: "BLAST", O'Reilly (2003)
Krause Jörg: "PHP 5, Grundlagen und Profiwissen", Hanser (2004)
Hudson Paul: "PHP in a Nutshell", O'Reilly (2006)
Yank Kevin: "Php und MySQL", Dpunkt.Verlag (2005)
FHNW
Plasmid Database
73
7
Glossar
A, C, G, T
Adenin, Guanin, Cytosin, Thymin; Basen der
Desoxyribonukleinsäure (DNA)
ACID
Atomizität, Konsistenz, Isolation und Zuverlässigkeit
Alignment
Zwei oder mehr Sequenzen auf Ähnlichkeit hin untersuchen
Backup
Datensicherung der vorhandenen Daten auf ein
Speichermedium
BDB
Berkley DB-(BDB-)Tabellen, Storage-Engine mit
Transaktionen und Page-Locking
BLAST
Basic Local Alignment Search Tool; Software-Paket für
Bioinformatik, Programm zum Vergleichen von Sequenzen
Button
Knopf
B-Tree
Baumstruktur, Knoten werden sortiert abgelegt
Code-Injection
Einschleusen von fremdem Programmcode zur Ausführung
Cronjob
Programm, welches wiederkehrende Aufgaben erledigt
Crontab
In dieses File werden die Cronjobs eingetragen
DB
Datenbank
DNA
Desoxyribonukleinsäure
Dump
Speicherauszug, logisches Backup
Dynamische Programmierung
Zwischenergebnisse werden abgespeichert und müssen nicht
neu berechnet werden
EULA
End User License Agreement
FASTA
Textbasiertes Format zur Darstellung und Speicherung von
Sequenzen
Feature
Eigenschaft des Plasmids
Fremdschlüssel
Zeigt die Beziehung zu einer anderen Tabelle
Geclusterte Indizes
Primärschlüssel und Datensatz selbst sind zusammengefasst
Heap
Ermöglicht schnellen Zugriff auf Daten, die sich nie ändern
oder einen Neustart nicht überstehen müssen
FHNW
Plasmid Database
74
High Copy Number
Eigenschaft, die beschreibt, wie oft ein Plasmid in einem
Bakterium vervielfältigt wird
Hint
Hinweise
Hit
Ähnliche Position
HTML
Hypertext Markup Language, zur Darstellung von Webseiten
HW
Hardware
Index
besteht aus einer Ansammlung von Verweisen
InnoDB
Tabellentyp bei MySQL
Inquiry
Bestellung
Isolationsebene
Definiert, welche Änderungen innerhalb und ausserhalb einer
Transaktion sichtbar sind
Link
Verbindung
many-to-many
Mehrfach-zu-mehrfach Beziehung im Datenbank-Modell
Merge
Kombination aus mehreren ähnlichen Tabellen zu einer
virtuellen Tabelle
MySQL
Datenbankverwaltungssystem
NDB
Hochverfügbare speicherresidente Speicher-Engine mit
Fähigkeit für Datenpersistenz
PHP
Hypertext Preprocessor Programmiersprache zur
dynamischen Erstellung von Webseiten
Page-Locking
Lock auf eine Teil der Tabelle, der als Page bezeichnet wird
Parsing
Zerlegen des Queries in einzelne Komponenten
Plasmid
in Bakterien vorkommende kleine (bis 20'000 Basen)
ringförmige DNA-Moleküle
Primärschlüssel
Damit ist der Datensatz eindeutig identifizierbar
Query
Abfrage (Datenbank-Abfrage)
Refactoring
Strukturverbesserung von Quelltext
Referenzielle Integrität
Sicherstellung der Beziehungen durch Fremdschlüssel
R-Tree-Indizes
Räumliche oder N-dimensionale Indizierung
Transaktion
Gruppen von SQL-Abfragen die zusammengehören
(Schreibsprerre)
FHNW
Plasmid Database
75
Session
Die Daten, die dem Server während dem Verweilen eines
Benutzers auf einer Homepage bekannt sind, werden als
Session bezeichnet.
SQL-Injection
Manipulieren von SQL-Abfragen
SSAHA
Sequence Search and Alignment by Hashing Algorithm
Storage Engine
Tabellentypen
Spezies
Lieferant des Hauptelementes (z. Bsp. Mensch, Maus)
SW
Software
UML
Unified Modeling Language
User
Benutzer
Workflow
Arbeitsablauf
FHNW
Plasmid Database
76
Ehrlichkeitserklärung
Hiermit bestätigen die unterzeichnenden Autoren dieses Berichts, dass alle nicht klar
gekennzeichneten Stellen von Ihnen selbst erarbeitet und verfasst wurden.
Muttenz, 10. Januar 2007
Chantal Isler
Carla Santoro
FHNW
Plasmid Database
77
8
Anhang
8.1
Auftrag
8.2
Benutzerhandbuch
8.3
Lizenz
8.4
Pflichtenheft
8.5
Dokumente der Testphase
8.6
Protokolle der Sitzungen
8.7
Wochenberichte
8.8
Zeitplan
8.9
CD-ROM mit Source-Code
FHNW
Plasmid Database
78
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement