diplomarbeit ”anpassung von blast fur genom-datenbanken”¨ · kapitel 2 biologische grundlagen...

Diplomarbeit”Anpassung von BLAST fur Genom-Datenbanken”

eingereicht am Institut fur Informatikder Humboldt-Universitat zu Berlin

von Matthias Wehgeb. am 5. Januar 1976in BerlinMatrikelnummer 134764

Betreuer: Chokri Ben Necib

eingereicht am: 19. Februar 2002

Inhaltsverzeichnis

1 Einleitung 3

2 Biologische Grundlagen 42.1 Typen von Biosequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Zusammenhang von DNA, RNA und Proteinen . . . . . . . . . . . . . . . . 6

3 Sequenzvergleiche 93.1 Bedeutung von Sequenzvergleichen . . . . . . . . . . . . . . . . . . . . . . . 93.2 Bewertungsschemata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Alignierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.4 Algorithmen zur Bestimmung der optimalen Alignierung . . . . . . . . . . . 123.5 Approximative Alignierungsalgorithmen . . . . . . . . . . . . . . . . . . . . 13

4 Analyse des BLAST-Programmcodes 194.1 Das NCBI-Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Die Module des Programms BLAST . . . . . . . . . . . . . . . . . . . . . . 204.3 Die ”Datenbank”-Schnittstelle von BLAST . . . . . . . . . . . . . . . . . . 224.4 Der Ablauf von blastall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5 Analyse des multithreading in BLAST . . . . . . . . . . . . . . . . . . . . . 334.6 Die Datenstruktur SeqAlign . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 Verwendete Datenbankkonzepte 425.1 Datenmodellierung der Biosequenzen . . . . . . . . . . . . . . . . . . . . . . 425.2 Anwendungsprogrammierung mit DB2 . . . . . . . . . . . . . . . . . . . . . 435.3 Benutzerdefinierte Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6 Anpassung von BLAST 546.1 Implementation der Datenbankschnittstelle von BLAST . . . . . . . . . . . 546.2 BLAST als benutzerdefinierte Funktion . . . . . . . . . . . . . . . . . . . . 68

7 Ausblick 82

A blastall-Kommandozeilenoptionen 84A.1 Genetische Codetabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

1

INHALTSVERZEICHNIS

B Aufbau der BLAST-Reportdateien 88B.1 Das FASTA-Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88B.2 FormatDB -Ausgabedateien . . . . . . . . . . . . . . . . . . . . . . . . . . . 88B.3 BLAST-Reportdateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

C UDF-Entwurfsdetails 95C.1 Typen von Alignierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95C.2 DenseDiag-Alignierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95C.3 DenseSeg-Alignierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96C.4 Weitere Anpassungen der UDF . . . . . . . . . . . . . . . . . . . . . . . . . 97

D Relationales Datenmodell 99

Literaturverzeichnis 102

2

Kapitel 1

Einleitung

Seit Ende der 1980er Jahre wird systematisch der Aufbau der gesamten Erbinformationlebender Organismen experimentell ermittelt und erfasst. Der ”Bauplan” eines jeden Le-bewesens kann dabei durch eine Sequenz von Basenpaaren, die DNA, beschrieben werden.Die funktionale Auspragung der Erbinformation, die Proteine, sind ebenfalls als Sequenzvon chemischen Bestandteilen, den Aminosauren, beschreibbar.

Die Auswertung und Interpretation der Sequenzen ist Aufgabe der Bioinformatik. Sieist eine sehr junge Forschungsrichtung, die die Disziplinen Molekularbiologie und Infor-mationstechnik zusammenfuhrt. Die Bioinformatik muss mehrere Aufgaben mit Hilfe derSequenzanalyse losen:

• Auswertung von Sequenz-RohdatenDie bei der Sequenzierung gewonnenen Rohdaten werden auf ihre Korrektheit uber-pruft.

• Vorhersage von GenenDie fur Proteine kodierenden Abschnitte der DNA mussen von den weniger relevantenAbschnitten getrennt werden. Sie sind Voraussetzung fur die Proteintranslation.

• Vorhersage der Proteinstruktur und -funktionDie dreidimensionale Struktur der Proteine determiniert die Wirkungsweise von Pro-teinen. Diese ist Voraussetzung fur das Verstandnis biologischer Prozesse.

• Aufklarung der evolutionaren Verwandtschaft von SequenzenDie Biosequenzen heute analysierter Organismen werden in Beziehung zueinandergesetzt, um Auskunft uber die Verwandtschaft der Organismen zu erhalten.

Zur Bewaltigung dieser Aufgaben werden hauptsachlich Algorithmen zum Vergleich undzur Alignierung von Sequenzen verwendet. Ein popularer Vertreter dieser Methoden istdas Basic Local Alignment Search Tool (BLAST).

Gegenstand dieser Arbeit ist die Integration von BLAST in ein relationales Daten-banksystem. Relationale Datenbanken bieten fur die Genomforschung die Moglichkeit, dieBiosequenzen in ein Modell einzubetten, das verschiedene biologische Informationen in Be-ziehung setzt. Die Biosequenzen konnen dann unter verschiedenen Gesichtspunkten mitHilfe relationaler Anfragesprachen analysiert werden.

3

Kapitel 2

Biologische Grundlagen

2.1 Typen von Biosequenzen

Gegenstand dieser Diplomarbeit ist die Anpassung des Alignierungsalgorithmus BLASTzur Anwendung in einem objektrelationalen Datenbanksystem. Dieser Algorithmus stammtaus dem Bereich der Genanalyse. Deshalb sollen im Folgenden die wichtigsten Begriffe ausder Genanalyse erlautert werden.

DNA (Deoxyribonucleic Acid, Desoxyribonukleinsaure) und RNA (Ribonucleic Acid,Ribonukleinsaure) sind das Erbmaterial lebender Materie. Sie bilden das Genom, die Ge-samtheit aller in einer Zelle vorhandenen Erbanlagen. Die Vererbung besteht in der Spei-cherung, Weitergabe, Rekombination und Realisierung der Erbinformation (des genetischenMaterials). Trager der DNA sind die Chromosomen. Auf die Weitergabe der Erbinforma-tion wird in [23] eingegangen.

DNA und RNA sind makromolekulare Nukleinsauren, die in Form einer Kette — einemPolynukleotid — aufgebaut sind. Die Bausteine der Ketten sind die Nukleotide, die ausZuckern, Basen und Phosphatresten bestehen. Anhand der Basen lassen sich funf Nukleo-tide unterscheiden: Adenin, Cytosin, Guanin, Thymin und Uracil. Deren hauptsachlichesVorkommen kann Tabelle 2.1 entnommen werden. In Abhangigkeit von der Nukleinsauresind jeweils vier Nukleotide zu unterscheiden. Der grundlegende Unterschied zwischen DNAund RNA ist der enthaltene Zucker: im Fall der DNA ist es Desoxyribose, im Fall der RNARibose. Desoxyribose und Ribose kommen nie gleichzeitig im selben Polynukleotid vor.

Die DNA ist als Doppelstrang zweier sich gegenuberliegender Nukleotidketten aufge-baut. In diesem von James D. Watson und Francis Crick 1953 vorgeschlagenen (undbereits auf seine Richtigkeit uberpruften) Strukturmodell bilden die Paare Adenin undThymin sowie Cytosin und Guanin Wasserstoffbrucken aus, wobei eine der Basen auf demeinen Strang, die andere auf dem anderen Strang liegt. Folglich kann aus einer der beidenKetten die komplementare Kette bestimmt werden, was unter anderem fur die Replikationder Erbinformation von Bedeutung ist. Die Ketten der DNA sind in einer rechtsdrehendenDoppelspirale (Helix ) angeordnet.

Im Gegensatz dazu ist die RNA aus nur einer Kette aufgebaut. Deren Besonderheitbesteht darin, dass die Nukleotide des Strangs untereinander Basenpaare ausbilden konnen(Adenin mit Uracil, Cytosin mit Guanin), was die Sekundarstruktur von RNA komplizierterals die von DNA macht. Der genaue Aufbau der RNA hangt von ihrer Funktion ab undwird hier nicht weiter vertieft (siehe dazu [24]).

4

KAPITEL 2. BIOLOGISCHE GRUNDLAGEN

Nukleotid Symbol Vorkommen KomplementAdenin A DNA / RNA T/UCytosin C DNA / RNA GGuanin G DNA / RNA CThymin T DNA AUracil U RNA A

Tabelle 2.1: Alphabet der Nukleotide

Symbol Bedeutung KomplementA Adenin TC Cytosin GM A oder C KG Guanin CR A oder G YS C oder G SV A oder C oder G BT Thymin/Uracil AW A oder T WY C oder T RH A oder C oder T DK G oder T MD A oder G oder T HB C oder G oder T V

N/X A oder C oder G oder T N/X

Tabelle 2.2: Alphabet der Nukleotide mit Mehrdeutigkeiten. Die komplementaren Residuenergeben sich, wenn man die komplementaren Elementarresiduen verknupft.

Die Anordnung der Stickstoffbasen auf den Ketten wird als Sequenz bezeichnet. Mitder Darstellung eines Nukleotids durch den Buchstaben seiner Stickstoffbase kann eine Se-quenz als Zeichenkette reprasentiert werden. Damit konnen DNA- und RNA-Sequenzeninformationstechnisch verarbeitet werden. Zur Vereinheitlichung von RNA und DNA undzur Darstellung sogenannter ”Mehrdeutigkeitsresiduen” (ambiguity residues) wird das Al-phabet aus Tabelle 2.2 verwendet, das von Cornish-Bowden [10] eingefuhrt wurde. Die viereindeutigen Residuen werden im Folgenden als Elementarresiduen bezeichnet, DNA- undRNA-Sequenzen werden zum Begriff NA-Sequenzen zusammengefasst.

Die dritte Art der hier behandelten Sequenzen sind die Aminosaure- oder Proteinse-quenzen. Ein Protein ist ein aus Aminosauren zusammengesetztes Makromolekul. Proteinesind die funktionale Realisierung der Erbinformation und werden aus der DNA syntheti-siert. Obwohl heute uber 100 Aminosauren bekannt sind, bilden nur 20 von Ihnen denBausatz zur Bildung von Proteinen. Zur Darstellung dieser proteinogenen Aminosaur-en wird das in [20] eingefuhrte Alphabet verwendet. Tabelle 2.3 zahlt die Aminosaurenauf. Die Aminosauren in einem Protein sind, wie die Nukleotide der DNA, als Sequenz(Polypeptidkette) angeordnet. Die Sequenz bildet die Primarstruktur. Die Sekundar- undTertiarstruktur ergibt sich, wenn man die Wechselwirkung der Aminosauren innerhalb ei-nes Proteins betrachtet. Diese dreidimensionale Struktur ist maßgebend fur die Funktion

5


Einbuchstabencode Dreibuchstabencode AminosaureA Ala AlaninC Cys CysteinD Asp AsparaginsaureE Glu GlutaminsaureF Phe PhenylalaninG Gly GlycinH His HistidinI Ile IsoleucinK Lys LysinL Leu LeucinM Met MethioninN Asn AsparaginP Pro ProlinQ Gln GlutaminR Arg ArgininS Ser SerinT Thr ThreoninV Val ValinW Trp TryptophanY Tyr Tyrosin

Tabelle 2.3: Alphabet der Aminosauren

des Proteins und deshalb von besonderem Interesse. Es ist bekannt, dass der dreidimensio-nale Aufbau durch die Sequenz determiniert ist, allerdings ist bisher nicht geklart, welcheInformation den Prozess der Proteinfaltung (d.h. der Ausbildung der 3D-Struktur) steuert.

2.2 Zusammenhang von DNA, RNA und Proteinen

Die im vorangegangenen Abschnitt behandelten Biosequenzen stehen in einem biologischenZusammenhang. Die DNA ist, wie bereits erwahnt, Trager des Erbguts eines Organismus.Jedem Gen, der kleinsten vererbbaren Einheit auf einem DNA-Molekul, kann eine Pep-tidkette (also eine Aminosauresequenz) zugeordnet werden. In Experimenten wurde dieErkenntnis gewonnen, dass die Gene auf der DNA in einer linearen Sequenz angeordnetsind. Sie uberlappen sich normalerweise nicht, die Ausnahme bildet das Erbgut einigerViren. Da ein Gen demnach als Sequenz von Nukleotiden beschreibbar ist, folgt, dass dieAminosauresequenz eines Peptids mittels eines eindeutigen Codes aus dem Gen ermittelbarist. Dieser wird als genetischer Code (Tabelle 2.4) bezeichnet. Die kleinste Informations-einheit ist dabei eine Gruppe aus drei Basen (Basentriplett), die als Codon bezeichnetwird. Eine Abbildung von drei aufeinanderfolgenden Nukleotiden auf eine Aminosaure istvollstandig, da mit drei Nukleotiden 43 = 64 verschiedene Kombinationen moglich sind.Mit zwei Nukleotiden konnten nicht alle 20 Aminosauren abgebildet werden (42 = 16).

Das in Abbildung 2.1 dargestellte zentrale Dogma der Molekularbiologie veranschaulichtden Zusammenhang der hier betrachteten Sequenzen und die Vorgange, an denen diesebeteiligt sind. Im zentralen Dogma wird der Vorgang der Informationsubertragung nurvon der DNA zum Protein dargestellt, nicht umgekehrt. Es sei hier erwahnt, dass bei

6


1. Position 2. Position 3. PositionU (A) C (G) A (T) G (C)Phe Ser Tyr Cys U (A)Phe Ser Tyr Cys C (G)U (A)Leu Ser Stop Stop A (T)Leu Ser Stop Trp G (C)Leu Pro His Arg U (A)Leu Pro His Arg C (G)C (G)Leu Pro Gln Arg A (T)Leu Pro Gln Arg G (C)Ile Thr Asn Ser U (A)Ile Thr Asn Ser C (G)A (T)Ile Thr Lys Arg A (T)

Met Thr Lys Arg G (C)Val Ala Asp Gly U (A)Val Ala Asp Gly C (G)G (C)Val Ala Glu Gly A (T)Val Ala Glu Gly G (C)

Tabelle 2.4: Der genetische Code. Die Nukleotidsymbole bezeichnen Residuen der trans-kribierten mRNA, in Klammern sind die entsprechenden Basen der DNA angegeben.

Abbildung 2.1: Zentrales Dogma der Molekularbiologie

7


bestimmten Viren, den Retroviren, die Synthese der DNA aus der RNA moglich ist.Die Ubersetzung der DNA in Proteine (Proteinbiosynthese), also die Anwendung des

genetischen Codes, erfolgt in zwei Schritten:

1. TranskriptionFur die Proteinbiosynthese werden nur Einzelteile des DNA-Strangs benotigt, dieals RNA-Molekul kopiert werden. Dazu wird der DNA-Doppelstrang enzymatischgetrennt und einer der Strange komplementar auf die RNA kopiert:

• Adenin in der DNA entspricht Uracil in der RNA• Cytosin entspricht Guanin• Guanin entspricht Cytosin• Thymin entspricht Adenin

Das Produkt dieses ersten Transkriptionsschritts wird in einem zweiten Schritt wei-ter modifiziert. Die wichtigsten Veranderungen sind die Verkurzung der Sequenz aneinem Ende (untranslatierte Region) sowie die Entfernung nicht kodierender Teilse-quenzen aus der RNA. Die nichtkodierenden Sequenzen (Introns) werden aus derRNA entfernt, die dazwischen liegenden Sequenzen (Exons) werden verbunden (ver-spleißt). Das Vorkommen nichtkodierender Sequenzen wurde entdeckt, weil bei derLokalisierung der Gene in der DNA deren diskontinuierliche Verteilung aufgefallenwar. Das Ergebnis ist die Messenger RNA (mRNA), die zur Translation benotigtwird.

2. TranslationDer zweite Schritt der Proteinbiosynthese sorgt fur die Ubersetzung der mRNA inein Protein. Mit Hilfe des genetischen Codes (Tabelle 2.4) wird aus den ersten dreiNukleotiden der Sequenz eine Aminosaure synthetisiert, aus den nachsten drei Nu-kleotiden die zweite und so fort. Die Translationsprodukte hintereinander liegendermRNA-Basentripletts liegen im entstehenden Protein ebenfalls hintereinander. DerTranslationsvorgang wird beendet, wenn eines der Stoppcodons gefunden wird. In derPraxis liegt meist nur ein mRNA-Fragment vor, bei dem das Startcodon nicht mitSicherheit bestimmbar ist. Folglich gibt es drei verschiedene Leseraster zum Startender Translation (Beginn an den ersten drei Basen), die unterschiedliche Aminosaure-sequenzen ergeben.

Zwei Eigenschaften des genetischen Codes sind in diesem Zusammenhang von Bedeutung:

1. UniversalitatDer genetische Code ist fur fast alle Spezies gleich. Die Ausnahme bilden Organismenmit sehr kleinen Genomen, die nur wenige Proteine kodieren.

2. DegeneriertheitDer genetische Code ist nicht eineindeutig, d.h. einer Aminosaure kann meistens keinkodierendes Basentriplett zugeordnet werden, da fast alle Aminosauren mindestenszwei Basentripletts besitzen. Deshalb darf bei einer relativen Unahnlichkeit zweierDNA-Sequenzen nicht gefolgert werden, dass die kodierten Proteine keine Ahnlichkeitbesitzen.

8

Kapitel 3

Sequenzvergleiche

3.1 Bedeutung von Sequenzvergleichen

Nachdem im letzten Kapitel der Begriff Sequenz im biologischen Kontext geklart wurde, solles hier um die Bewertung von Ahnlichkeiten und Unterschieden von Biosequenzen gehen.Ziel dieser Betrachtungen ist die Moglichkeit, Beziehungen zwischen den Sequenzen undden dazugehorigen Organismen abzuleiten:

• strukturelle BeziehungenDa die 3D-Struktur durch die Primarstruktur (die Sequenz) determiniert ist, ist diestarke Ahnlichkeit von bestimmten Bereichen zweier Sequenzen ein Hinweis auf eineahnliche raumliche Struktur der dazugehorigen Proteine.

• funktionale BeziehungenWenn sich die 3D-Struktur zweier Proteine in Teilen stark ahnelt, so liegt derenfunktionale Verwandtschaft nahe. In Kombination mit obiger Implikation ist damitdie Funktion eines Proteins aus dessen Sequenz ableitbar, sofern bereits die Funktioneines Vergleichsproteins auf experimentellem Wege ermittelt wurde.

• evolutionare BeziehungenEin drittes Ziel von Sequenzvergleichen ist der Nachweis der Homologie. Zwei Se-quenzen sind homolog, falls sie einen gemeinsamen evolutionaren Ursprung, d.h. diegleiche Sequenz als Vorfahren haben [22]. Homologie kann in zwei Formen auftreten:

1. Orthologie: Die betrachteten Sequenzen haben eine ahnliche Funktion, stammenaber aus verschiedenen Spezies. Homologe Sequenzen dieser Art zeigen deshalbdie Differenzierung und Verwandtschaft von Spezies an.

2. Paralogie: Die betrachteten Sequenzen haben unterschiedliche, aber verwand-te Funktionen innerhalb desselben Organismus. Paraloge Sequenzen entstehendurch Gen-Duplikation. Sie geben Hinweise auf die Entwicklung des Genomseiner einzelnen Spezies.

Da die Vorfahren-Sequenz, d.h. der gemeinsame evolutionare Ursprung der Sequenzen,oft nicht bekannt ist, wird versucht, mittels Sequenzvergleichen die Homologie nach-zuweisen. Ziel ist es, die Ahnlichkeit von Sequenzen bewertbar zu machen. Anhand

9

KAPITEL 3. SEQUENZVERGLEICHE

der Bewertung ist man dann in der Lage, Ahnlichkeiten zu vergleichen. Homologiewird geschlussfolgert, wenn das Ahnlichkeitsmaß der zu untersuchenden Sequenzensignifikant hoher als das zweier zufalliger Sequenzen ist. Die umgekehrte Implikationgilt dagegen nicht: bestimmte Sequenzpaare sind zwar homolog, zeigen jedoch keinesignifikante Verwandtschaft auf Sequenzniveau.

3.2 Bewertungsschemata

Sequenzvergleichsalgorithmen verarbeiten Zeichenketten (strings) und berechnen bewerteteAlignierungen. Eine Alignierung (engl.: to align – ausrichten, in Ubereinstimmung brin-gen) zweier Zeichenketten ist eine Ausrichtung der Zeichen des einen strings zu denen desanderen. Eine solche Anordnung kann numerisch bewertet werden. Bevor auf konkreteAlignierungsalgorithmen eingegangen wird, fuhrt dieser Abschnitt den Begriff des Bewer-tungsschemas ein.

Die Berechnung der Ahnlichkeit zweier Sequenzen wird in den hier vorgestellten Algo-rithmen auf die Substitution einzelner Zeichen reduziert. Die Zuordnung eines Werts s(a, b)zu einem Zeichenpaar (a, b) kann als Maß fur die Ahnlichkeit der beiden Zeichen gelten: jehoher der Wert, desto ahnlicher die Zeichen. s wird als Bewertungs- oder scoring-Schema(engl.: to score – benoten, Punkte vergeben) bezeichnet. Ist das Alphabet, auf dem dieBewertung definiert wird, endlich, so kann das Schema als Matrix M dargestellt werden.Dabei gilt fur jedes Matrixelement ma,b:

ma,b = s(a, b)

Die Aufgabe von Alignierungsalgorithmen besteht darin, eine Alignierung mit moglichsthoher Bewertung zu ermitteln. Deshalb kann es notig sein, dass einige Zeichen des einenstrings zu Lucken (engl.: gaps oder indels) im anderen string zugeordnet werden, falls da-durch eine hoch bewertete Alignierung gebildet werden kann. Im Alphabet Σ ist deshalboft eines der Zeichen ε, ∗ oder - zur Reprasentation einer Lucke enthalten. Folglich mussenauch Bewertungen der Form s(a, ε) bzw. s(ε, b) Teil des Bewertungsschemas sein. Bewer-tungsmatrizen werden auch als Substitutionsmatrizen bezeichnet, da die Zuordnung zweierZeichen auch als Ersetzung des einen Zeichens durch das andere interpretiert werden kann.

Da Protein- und NA-Sequenzen Zeichenketten auf endlichen Alphabeten sind, werdenzu ihrer Alignierung Bewertungsmatrizen verwendet. Die Bewertungsmatrix hat eine her-ausragende Bedeutung, weil sie als einziges Element des Alignierungsalgorithmus Wissenaus der Anwendungsdomane in den Algorithmus ubertragt. Unterschiedliche Anwendun-gen benotigen dabei verschiedene Bewertungsschemata. Einen Uberblick uber die wich-tigsten Schemata gibt Barton [4]. In der Praxis werden fur Proteinsequenzen meistensdie Substitutionsmatrizen der PAM - (point-accepted mutations, [11]) und der BLOSUM -Familie (BLOCKS substitution matrix, [13]) verwendet, bei NA-Sequenzen wird haufig nurzwischen matches (engl.: match – Ebenbild, Gegenstuck) und mismatches unterschieden,d.h. Paaren identischer bzw. nicht-identischer Residuen.

3.3 Alignierungen

Das Ziel von Vergleichsalgorithmen ist die Bestimmung der Ahnlichkeit von Sequenzen. Diehier betrachteten Verfahren untersuchen nur jeweils zwei Sequenzen, eine Erweiterung auf

10


S1 C A B A C D B – CS2 D A B – B D B D C

Score −4 +5 +5 −3 −4 +5 +5 −3 +5S′(S1, S2)

∑= 11

Abbildung 3.1: Bewertung einer Beispielalignierung der Zeichenketten CABACDBC undDABBDBDC. Das Zeichen ”-” steht fur eine Lucke.

mehrere gleichzeitig anzuordnende Sequenzen (engl.: multiple alignment) ist aber moglich.Die Bestimmung der Ahnlichkeit besteht darin, eine moglichst hoch bewertete Alignierungder Sequenzen, oder Teilen davon, zu erreichen. Die einzelnen Zeichen einer Sequenz behal-ten nach der Ausrichtung zur anderen Sequenz ihre Reihenfolge. Zeichen der ersten Sequenzkonnen dabei zu Zeichen der anderen Sequenz oder zu Lucken in dieser Sequenz zugeordnetwerden. Der umgekehrte Fall gilt entsprechend. Abbildung 3.1 stellt eine mogliche Alignie-rung der Zeichenketten CABACDBC und DABBDBDC dar. Die zugeordneten Paare von Zeichenwerden zur Veranschaulichung nach einem einfachen Schema bewertet: +5 fur matches,−4 fur mismatches und −3 fur Zeichen-Lucken-Zuordnungen. Der Wert einer Alignierungergibt sich als Summe der Werte der Zeichenpaare. Seien

• x und y zwei Zeichenketten,

• xi und yi daraus durch Luckeneinfugen entstandene Sequenzen,

• a[j] das Zeichen an der j-ten Position einer Sequenz a,

• ni die Lange der Alignierung von xi und yi,

dann berechnet folgende Formel den Wert der Alignierung:

S′(xi, yi) =ni∑

j=1

s(xi[j], yi[j]) (3.1)

Uber die Ahnlichkeit der beiden Sequenzen x und y kann erst dann eine Aussage ge-troffen werden, wenn alle moglichen Alignierungen gebildet und bewertet werden. Diebestbewertete Alignierung ist dann ein Maß fur die Ahnlichkeit der beiden Sequenzen. DerWert S(x, y) einer solchen optimalen Alignierung wird deshalb als Maximum uber die Wertealler moglichen Alignierungen (Formel 3.1) definiert:

S(x, y) = maxi

S′(xi, yi) (3.2)

Alignierungen konnen unter verschiedenen Gesichtspunkten klassifiziert werden. Die ge-brauchlichste Klassifizierung unterscheidet zwischen globaler und lokaler Alignierung. Obi-ges Beispiel ist eine globale Alignierung, weil die gesamten Zeichenketten zur Anordnungherangezogen werden. Lokale Alignierung bedeutet die Anordnung zweier Sequenzaus-schnitte. Es mussen alle Subsequenzen fur eine Alignierung gepruft werden. Die optimalelokale Alignierung ist unter allen moglichen diejenige mit der hochsten Bewertung.

Eine zweite Klassifikation unterscheidet zwischen luckenbehafteten (gapped) Alignie-rungen und solchen ohne Lucken (ungapped). Obiges Beispiel ist eine luckenbehaftete Ali-gnierung. Es ist einsichtig, dass eine globale Alignierung luckenbehaftet sein muss, weil

11


es sonst nur eine Moglichkeit gabe, die beiden Sequenzen anzuordnen. Fur alle anderenKombinationen gibt es entsprechende Algorithmen.

Die Bestimmung globaler Alignierungen dient unter anderem dazu, die evolutionareEntwicklung einer Proteinfamilie zu rekonstruieren, wenn bekannt ist, dass beide Sequenzenzu dieser Familie gehoren. Die haufigere Problemstellung ist jedoch die lokale Alignierung.Sie findet bei der Identifikation von Genen in langen DNA-Sequenzen Anwendung. AuchProteine sind aus strukturellen und funktionalen Untereinheiten aufgebaut, deren Positionin der Sequenz nur durch lokale Alignierung bestimmt werden kann, wenn eine Sequenz miteiner verwandten Funktion zum Sequenzvergleich zur Verfugung steht.

3.4 Algorithmen zur Bestimmung der optimalen Alignierung

Sowohl fur die globale als auch die lokale Alignierung existieren Algorithmen, die die op-timale Ausrichtung und damit das Maß fur die Ahnlichkeit zweier Sequenzen finden. Siesollen hier kurz vorgestellt werden, da sie den Ausgangspunkt fur die approximativen Al-gorithmen bilden.

3.4.1 Der Algorithmus von Needleman und Wunsch

Zur optimalen globalen Alignierung zweier Sequenzen wird der Algorithmus von Needle-man und Wunsch [25] verwendet. Der Algorithmus ist ein Beispiel fur die Technik derdynamischen Programmierung [5], bei der Teilergebnisse so in ihrer zeitlichen Reihenfol-ge berechnet werden, dass sie zum benotigten Zeitpunkt vorliegen. Die Berechnung jedesTeilergebnisses greift auf eine konstante Anzahl bereits berechneter Teilergebnisse zuruck.Ausgenommen sind die Initialwerte, die sich unabhangig von anderen Werten berechnenlassen. Seien:

• x und y zwei Sequenzen der Langen |x| = n und |y| = m,

• Si,j = S(x[1, i], y[1, j]) der Wert der besten Anordnung der entsprechenden Prafixevon x und y mit

• x[p1, p2] als Teilsequenz von x, die bei Position p1 beginnt und bei p2 endet; analogesgilt fur y

Die Felder Si,j werden wie folgt berechnet, Sn,m ist dann der Wert der optimalen Alignierungder Sequenzen x und y:

S0,0 = 0 (3.3)S0,j = S0,j−1 + s(ε, y[j]) fur 1 ≤ j ≤ m (3.4)Si,0 = Si−1,0 + s(x[i], ε) fur 1 ≤ i ≤ n (3.5)

Si,j = max

Si−1,j + s(ε ,y[j]),Si−1,j−1 + s(x[i],y[j]),Si,j−1 + s(x[i],ε )

fur i, j 6= 0 (3.6)

Die Optimalitat des Ausdrucks wird induktiv bewiesen. Der Induktionsschritt besteht inder Uberlegung, dass die Alignierung der Sequenzen x[1, i] und y[1, j] auf drei Arten endenkann:

12


Fall 1 Fall 2 Fall 3x[1,i] . . . x[i] . . . x[i] . . . εy[1,j] . . . ε . . . y[j] . . . y[j]

Folglich greift die Berechnung des Zwischenergebnisses Si,j auf die Teilergebnisse Si−1,j ,Si−1,j−1 und Si,j−1 zuruck, und der Algorithmus sorgt dafur, dass diese vor Si,j berechnetwerden.

Zur Ermittlung der optimalen Alignierung aus der S-Matrix muss vom Element Sn,m

der Berechnungsweg des jeweils maximalen Werts zuruckgegangen werden. Die Berechnungeines jeden Elements der Matrix besteht aus konstant vielen Schritten. Da sie aus n · mElementen besteht, hat der Algorithmus eine Komplexitat von O(n · m). Die Zeilen derMatrix konnen als Reprasentanten fur die Prafixe der Sequenz x betrachtet werden, dieSpalten als Reprasentanten fur die Prafixe von y.

Eine von Gotoh [12] eingefuhrte und haufig verwendete Variation des Algorithmus un-terscheidet zwischen dem Einfugen und der Verlangerung einer Lucke. Der Wert eineralignierten Lucke ist dabei eine affine Funktion, die von der Lange abhangt. Die Komple-xitat dieses modifizierten Algorithmus betragt O(n ·m · (n + m)).

3.4.2 Der Algorithmus von Smith und Waterman

Fur die lokale Sequenzalignierung existiert ebenfalls ein optimaler Algorithmus, der vonSmith und Waterman [28] entwickelt wurde. Dieser kann vom Needleman-Wunsch-Algo-rithmus hergeleitet werden. Voraussetzung fur diese Modifikation ist ein Bewertungssche-ma, das Ahnlichkeit positiv und Unahnlichkeit negativ bewertet. Ist ein solches Schemagegeben, sorgt der Algorithmus dafur, dass die optimale lokale Alignierung nicht mit ne-gativen Werten beginnen oder enden kann. Eine Alignierung ist nicht optimal, wenn nochpositive Werte an einem der beiden Enden zu einem hoheren Wert fuhren wurden. DieBerechnung sogenannter ”affiner Lucken” geschieht, wie bei Needleman-Wunsch, durch dieModifikation von Gotoh [12].

3.5 Approximative Alignierungsalgorithmen

Der Algorithmus von Smith und Waterman bestimmt die optimale lokale Alignierung zwei-er Sequenzen. Dieser Eigenschaft steht ein Berechnungsaufwand von O(n2) bzw. O(n3)gegenuber. Zum Durchsuchen von Sequenz-Datensammlungen ist dieser Aufwand zu groß.Fur diesen mittlerweile sehr haufig vorkommenden Anwendungsfall bedient man sich heu-ristischer Verfahren zur Approximation des Smith-Waterman-Algorithmus. Durch Heuri-stiken wird der Losungsraum, der durch dynamische Programmierung bearbeitet werdenmuss, begrenzt und dadurch die Laufzeit verbessert.

Die wichtigsten approximativen Methoden fur den paarweisen Sequenzvergleich sind dieAlgorithmen der FASTA- und BLAST -Programmpakete. Das von Pearson und Lipmanentwickelte FASTA [26, 27] war der erste wichtige Ansatz zur naherungsweisen Losung deroptimalen lokalen Alignierung. Schwerpunkt dieser Arbeit ist jedoch BLAST.

3.5.1 BLAST

BLAST (Basic Local Alignment Search Tool) [1, 2, 30] wurde von Altschul et al. am NCBI(National Center for Biotechnology Information) entwickelt. Der Algorithmus zeichnet

13


sich gegenuber FASTA durch eine geringere Laufzeit bei gleicher Sensitivitat aus. Von demursprunglichen Algorithmus gibt es eine Vielzahl von Erweiterungen, von denen hier einigevorgestellt werden.

BLAST ist als Web-Applikation beim NCBI unter http://www.ncbi.nlm.nih.gov ver-fugbar. Dort kann jedes BLAST-Programm mit eigenen Anfragesequenzen gegen eine Viel-zahl von Datensammlungen getestet werden.

3.5.2 Grundidee des Algorithmus

BLAST ist fur den Vergleich einer Anfragesequenz Anfragesequenz Q mit einer Sequenz-Datensammlung ausgelegt. Die Grundidee des Algorithmus besteht darin, in den Daten-sammlungssequenzen (im Folgenden Vergleichssequenzen) nach Teilstucken zu suchen, die”gute Kandidaten” (Hits) fur Alignierungen mit Teilstucken der Anfragesequenz sind. DieHits werden dann zu Alignierungen expandiert, die bewertet werden. Vor dem Algorithmuswird die Anfragesequenz gefiltert, d.h. es werden Regionen geringer Komplexitat maskiert.Fur Nukleotidsequenzen wird zur Filterung DUST1, fur Aminosauresequenzen SEG [29]verwendet. Der BLAST-Algorithmus selbst fuhrt auf jeder Vergleichssequenz D die folgen-den drei Schritte aus:

1. Lokalisierung der Hits.In der Vergleichssequenz werden Teilworter der Lange w gesucht, die mit gleich langenTeilwortern der Anfragesequenz eine Alignierung mit einem Wert großer T bilden.Eine derartige Alignierung wird Hit genannt.

2. Expansion eines Hits.Ein Hit wird zu einer großeren luckenfreien Alignierung expandiert. Dazu wird diejeweils aktuelle Alignierung schrittweise nach links bzw. rechts um ein Zeichen erwei-tert. Die Erweiterung wird solange vorangetrieben, bis die entstehende Alignierungum einen festgelegten Wert X vom erweiterungslokalen Maximum abfallt. X wird alsdropoff -Wert bezeichnet (engl.: to drop off – nachlassen, zuruckgehen). Dann stelltdas lokale Maximum das Ergebnis dar und wird mit HSP (High-scoring SegmentPair) bezeichnet.

3. Ausgabe der HSPs.Hat ein HSP einen Wert großer als S, wird er als lokale Alignierung ausgegeben.BLAST hat damit die Moglichkeit, mehrere lokale Alignierungen zu berechnen undauszugeben.

Die Schritte beschreiben bereits die von BLAST benutzten Parameter, die unterschiedli-che Auswirkungen auf Selektivitat und Sensitivitat des Algorithmus haben. Sensitivitatist die Fahigkeit des Algorithmus, tatsachlich verwandte Sequenzen zu finden und hoch zubewerten. Selektivitat beschreibt die Fahigkeit, nicht verwandte Sequenz niedrig zu bewer-ten und damit nicht zu betrachten. Folgende BLAST-Parameter dienen der Steuerung desAlgorithmus:

1Der Algorithmus wurde von Roman L. Tatusov und David J. Lipman am NCBI entwickelt. Zu DUSTgibt es keine Veroffentlichungen.

14


• w ist die Wortlange eines Hits. Von den BLAST-Autoren empfohlene Werte sind 2oder 3 fur Proteinvergleiche und 11 fur DNA-Vergleiche. Eine Erhohung des Wertsgeht mit der Erhohung der Selektivitat einher.

• T ist der Schwellwert fur die Entscheidung, welche Alignierung des ersten Schrittsein Hit ist, also im zweiten Schritt weiterverarbeitet wird. Beim Festlegen diesesParameters ist zu beachten, dass ein niedriger Wert mehr Hits produziert und damitein hoheres Potenzial fur erfolgreiche Alignierungen bietet (hohere Sensitivitat), dabeiallerdings auch mehr Rechenzeit aufgewendet wird.

• X ist der sogenannte dropoff -Parameter, der bestimmt, ob eine Expansion abge-brochen oder weiterverfolgt wird. Ein hoherer Wert geht mit einer Erhohnung derSensitivitat einher.

• S entscheidet daruber, ob ein HSP als Ergebnis von BLAST ausgegeben wird. Je nied-riger der Wert, desto mehr Ergebnis-Alignierungen (hohere Sensitivitat). Heutzutagewird diese Entscheidung allerdings anhand abgeleiteter Variablen gefallt. Aus demhier definierten Wert einer Alignierung, dem nominalen Wert, wird ein normalisierterWert berechnet, der die Charakteristika des jeweiligen Bewertungsschemas sowie dieGroße des Suchraums mit einbezieht [21]. Mit Hilfe des normalisierten Werts konnenverschiedene BLAST-Suchlaufe mit unterschiedlichen Bewertungsschemata unterein-ander verglichen werden. Aus dem normalisierten Wert wird ein Erwartungswert be-rechnet, der Auskunft daruber gibt, wieviele Sequenzalignierungen mit dem gleichenoder einem besseren normalisierten Wert im entsprechenden Suchraum zu erwartensind, ohne den Inhalt in Betracht zu ziehen. Je niedriger der Erwartungswert derAlignierung, desto signifikanter ist die Ahnlichkeit der alignierten Sequenzen. DieAusgabe von HSPs wird in den zuletzt entwickelten BLAST-Programmvarianten mitdem Erwartungswert gesteuert.

Die Lokalisierung selbst besteht aus zwei Teilen:

1. Es werden alle Worter der Lange w bestimmt, die mit einem Teilwort der Anfrage-sequenz das T -Kriterium erfullen. Diese Worter werden als w-mere (engl.: w-mers)bezeichnet. Dieser Schritt ist unabhangig von den Vergleichssequenzen und wird des-halb nur einmal vor der gesamten BLAST-Suche durchgefuhrt. Die Worter werdenzusammen mit der Teilwort-Position aus der Anfragesequenz in einer Liste gespei-chert.

2. Die jeweilige Vergleichssequenz wird nach den Wortern in der Liste durchsucht.

Im ersten Schritt ist zu beachten, dass alle moglichen Wortkombinationen fur jedes der Teil-worter durchsucht werden mussen (bei w = 3 und einer Protein-Anfragesequenz mussendemzufolge 203 = 8000 Worter gepruft werden). Der Algorithmus fur DNA-Sequenzen istdahingehend einfacher, dass der erste Schritt der Hit-Lokalisierung wegfallt. Die Liste derw-mere besteht dort einfach aus allen Teilwortern der Anfragesequenz selbst, also genau|Q| − w + 1 Elementen.

Durch die Beschreibung des Expansionsschritts wird deutlich, dass BLAST ohne Luckenaligniert. Dieses Vorgehen leistet einen gewissen Beitrag zur Geschwindigkeitssteigerung

15


gegenuber einem rigorosen Algorithmus. Es kann allerdings festgehalten werden, dass dereigentliche Vorteil von BLAST in der Anwendung zweier Heuristiken liegt:

1. Suche von Hits als KandidatenDie Chance einer gut bewerteten Alignierung ist an Stellen hoher, an denen bereitsein Teilwort-Paar mit einem hohen Wert zu finden ist. Anschaulich werden durch denersten BLAST-Schritt Elemente des Suchraums vorgeben, durch den eine Alignierunglaufen muss. Dieser Vorteil hat allerdings nur dann Bestand, wenn sich nicht zu vieleAlignierungen unterschiedlicher Hits uberlappen, weil dann bestimmte Zeichenpaaremehrfach untersucht werden. Die Heuristik kann durch den Parameter T gesteuertwerden.

2. Abbruchbedingung fur die alignment-ExpansionDie Idee der Abbruchbedingung bei der Expansion ist, dass ein langer Abschnittschlecht bewerteter Residuenpaare selten durch einen daran anschließenden Abschnitthoher Ahnlichkeit wieder ausgeglichen wird. Deshalb wird die Alignierung abgebro-chen. Die Heuristik kann durch den Parameter X gesteuert werden.

3.5.3 Erweiterungen des ursprunglichen Algorithmus

Die im vorigen Abschnitt beschriebene ursprungliche Variante von BLAST hat einige Un-zulanglichkeiten, die zu Erweiterungen des Algorithmus gefuhrt haben:

• Oftmals werden mehrere Hits gefunden, die bei der Expansion die gleichen Residuen-paare bearbeiten und letztlich fast dieselben Alignierungen finden. Diese ”Doppelar-beit” vergroßert den Rechenaufwand ohne positiven Effekt auf das Ergebnis.

• Zur Berechnung vernunftiger Ergebnisse mussen die Parameter so eingestellt werden,dass der Algorithmus viele Hits findet und jeden von ihnen expandieren muss. Dader Erweiterungsschritt den großten Teil der Rechenzeit konsumiert, liegt es nahe,die Zahl der Expansionen ohne Beeintrachtigung der Sensitivitat zu reduzieren.

• Der Algorithmus aligniert Sequenzen ohne Lucken. Oftmals konnten signifikantereAlignierungen gebildet werden, wenn zwei oder mehr herkommliche Alignierungendurch Einfugen von Lucken vereinigt wurden.

Zur Losung dieser Probleme wurden zwei Erweiterungen von BLAST entwickelt [2]:

1. Fur das Problem der mehrfachen Betrachtung gleicher Teilsequenzpaare und zur Re-duktion der Expansionen wird die Zwei-Hit-Methode vorgeschlagen. Sie besteht da-rin, nur diejenigen Hits zu erweitern, die in ihrer Nachbarschaft einen weiteren, nichtuberlappenden Hit haben. Der Abstand der Hits ist auf beiden Sequenzen gleich unddarf einen festgelegten Wert nicht uberschreiten. Um eine vergleichbare Sensitivitatzu erreichen, muss der T -Parameter gegenuber dem Originalalgorithmus verringertwerden. Das fuhrt zwar zu mehr Hits, aber zu weniger Expansionen. Die Methodedient hauptsachlich der Geschwindigkeitsverbesserung.

2. Zur luckenbehafteten Alignierung wird zunachst der normale Algorithmus ausgefuhrt.Nach der Expansion wird der Wert eines HSP mit einem Schwellwert verglichen.

16


Liegt das HSP uber der Schwelle, so wird eine luckenbehaftete Alignierung mittelsdynamischer Programmierung angestoßen. Der Unterschied zum Smith-Waterman-Algorithmus ist, dass ein Residuenpaar durch das HSP festgelegt wird, durch das dieAlignierung laufen muss. Damit wird nicht der gesamte Suchraum betrachtet. Au-ßerdem wird auch hier ein dropoff -Wert zum Abbruch der luckenbehafteten Alignie-rung verwendet. Dieses Gapped BLAST genannte Verfahren dient im Gegensatz zurZwei-Hit-Methode nicht dazu, die Geschwindigkeit zu steigern, sondern signifikanteAlignierungen zu detektieren, die dem ursprunglichen BLAST verborgen gebliebenwaren.

3.5.4 Programmvarianten von BLAST

BLAST ist sowohl fur den Vergleich von sowohl Protein- als auch DNA-Sequenzen geeignet.Deshalb wurden mehrere Programmvarianten entwickelt:

• blastpDiese Variante vergleicht eine Protein-Anfragesequenz mit Sequenzen einer Protein-datensammlung. Alle Erweiterungen des Algorithmus sind anwendbar.

• blastnblastn vergleicht eine DNA-Anfragesequenz mit Sequenzen einer DNA-Datensamm-lung. Eine DNA-Sequenz besitzt zwei Leserichtungen (strands): die normale Sequenzsowie die umgekehrte Reihenfolge der Residuen der Komplementarsequenz (vergleicheAbschnitt 2.1). Es kann eingestellt werden, welche der Leserichtungen der Anfrage-sequenz analysiert werden sollen. Auch fur diese Variante sind alle Erweiterungenvon BLAST anwendbar.

• blastxDieses BLAST-Programm vergleicht alle Ubersetzungen einer DNA-Anfragesequenzmit allen Sequenzen einer Proteindatensammlung. Dabei wird die DNA-Sequenz inalle sechs moglichen Proteinsequenzkodierungen (Leseraster, engl.: reading frames)ubersetzt. Jede dieser Kodierungen stellt eine Protein-Anfragesequenz im oben ge-nannten Sinne dar. Die Anzahl der verschiedenen Leseraster ergibt sich aus der Kom-bination der drei Ubersetzungsraster einer Sequenz bei der Translation (vergleicheAbschnitt 2.2) mit den beiden Leserichtungen einer DNA-Sequenz. Als zusatzlicherParameter fur diese BLAST-Variante ist der zu verwendende genetische Code fur dieTranslation anzugeben. Alle Erweiterungen von BLAST sind anwendbar.

• tblastntblastn vergleicht eine Protein-Anfragesequenz mit den Leserastern aller Sequenzeneiner DNA-Datensammlung. Es stellt die Umkehrung von blastx dar. Auch hierist der genetische Code fur die DNA-Sequenzen anzugeben. Alle Erweiterungen vonBLAST sind anwendbar.

• tblastxDieses Programm vergleicht alle Leseraster einer DNA-Anfragesequenz mit den Le-serastern aller Sequenzen einer DNA-Datensammlung und fasst damit blastx undtblastn zusammen. Durch die Leseraster von sowohl Anfrage- als auch Vergleichs-sequenz sind hier 6 · 6 = 36 BLAST-Durchlaufe pro Sequenzpaar durchzufuhren.

17


Deshalb wird die Anwendung dieser Variante nur fur spezielle Problemstellungenempfohlen. Fur die Anfrage- und die Vergleichssequenz(en) muss jeweils der geneti-sche Code ubergeben werden. Die luckenbehaftete Alignierung wird fur tblastx nichtunterstutzt.

3.5.5 PSI-BLAST

Altschul et al. [2] haben eine Erweiterung von BLAST entwickelt, die zur Detektion schwa-cher Homologien entwickelt wurde. Diese PSI-BLAST (Position-Specific Iterated BLAST )genannte Erweiterung erzeugt eine positionsspezifische Bewertungsmatrix (PSSM, Position-Specific Scoring-Matrix ) aus einem BLAST-Lauf, um mit deren Hilfe weitere BLAST-Laufezu starten und weitere verwandte Sequenzen zu entdecken.

Ausgangspunkt fur eine Anwendung von PSI-BLAST ist ein normaler BLAST-Lauf.Das Ergebnis, eine nach aufsteigendem Erwartungswert geordnete Liste von alignierten Se-quenzen, wird zur Bildung einer PSSM herangezogen. Eine solche Matrix unterscheidet sichvon einer herkommlichen Bewertungsmatrix dadurch, dass die Elemente der Matrix nichtBewertungen von Residuenpaaren, sondern Residuum-Position-Paaren sind. Folglich wer-den darin Werte der Form s(Residuum,Position in der Query Q) gespeichert. Die PSSMhat die Dimension 20× |Q|. Zur Bildung der Matrix sei auf [2] verwiesen.

3.5.6 PHI-BLAST

Proteinfamilien werden oft uber spezielle Sequenzmuster charakterisiert. Ein Beispiel istdie PROSITE -Datenbank [3], bei deren Aufbau das Ziel bestand, diejenigen Muster zuspeichern, die fur die Funktion einer Proteinfamilie relevant sind. Solche Muster oder Si-gnaturen konnen als regulare Ausdrucke notiert werden [6] und stellen damit eine Art Gram-matik fur Segmente aus den Proteinsequenzen der entsprechenden Familie dar. Hauptzielist es, mit einer Signatur moglichst alle Proteine der Familie darstellen zu konnen und keineSequenzen mit vollig anderer Funktion abzubilden.

Eine Weiterentwicklung von BLAST, PHI-BLAST (Pattern-Hit Initiated BLAST ) [30],basiert auf der Idee solcher Muster (engl.: patterns). Dabei wird dem Programm zusatzlichzu einer Anfragesequenz ein Muster ubergeben, das in dieser Sequenz enthalten sein muss.Der PHI-BLAST-Algorithmus sucht dann in den Vergleichssequenzen nach dem Muster.Alle Sequenzen, die das Muster enthalten, werden mit dessen Hilfe zur Anfragesequenzaligniert. Die Alignierung kann nun als HSP im Sinne von Gapped BLAST betrachtetwerden, bildet also den Ausgangspunkt fur eine luckenbehaftete Alignierung.

18

Kapitel 4

Analyse desBLAST-Programmcodes

Fur die Integration von BLAST in ein objektrelationales Datenbanksystem ist es notwendig,dessen Quelltext zu analysieren. Dabei werden speziell die Module betrachtet, die furdie Integration modifiziert werden mussen. Die Anpassung von BLAST umfasst die inAbschnitt 3.5.4 vorgestellten Varianten.

4.1 Das NCBI-Toolkit

Die Algorithmen von BLAST werden in mehreren Programmen und Softwarewerkzeugenbenutzt, die zum NCBI Software Development Toolkit gehoren. Im Rahmen dieser Diplom-arbeit wird die Version 2.1.2 des Toolkits verwendet. Die darin enthaltenen Werkzeuge die-nen der Analyse verschiedener biologischer Daten. Sie sind in der Programmiersprache Cgeschrieben und basieren auf der Funktionsbibliothek NCBI CoreLib, die es erlaubt, platt-formunabhangig Software zu entwickeln. Folgende Funktionsgruppen werden in CoreLibimplementiert:

• Funktionen zum Setzen und Auslesen von Programmparametern und Umgebungsva-riablen

• Funktionen fur graphische Benutzeroberflachen

• Funktionen zur Verwaltung von Konfigurationsdateien

• Fehlerbehandlungsfunktionen

• Dateisystemfunktionen

• Speicherverwaltungsfunktionen

• Zeichenkettenfunktionen

• Mathematische Funktionen

• Funktionen zur Verwaltung von Prozessen und Threads

19

KAPITEL 4. ANALYSE DES BLAST-PROGRAMMCODES

Abbildung 4.1: Die von BLAST verwendeten Dateien

Einige der hier aufgefuhrten Funktionen bilden lediglich die entsprechenden ANSI-C -Funk-tionen ab.

Im Rahmen des Toolkits wird ein Datenmodell fur biotechnologisch relevante Daten ver-wendet, das in der Sprache ASN.1 (Abstract Syntax Notation, [19]) spezifiziert ist. ASN.1-Dokumente beschreiben konkrete Datensatze und konnen zum Datenaustausch benutztwerden. Zum Einlesen und Speichern von ASN.1-Spezifikationen stellt die Toolbox dieFunktionsbibliothek AsnLib zur Verfugung, die aus den Spezifikationen Parse-Baume er-stellt. Mit ihrer Hilfe lassen sich Daten in ASN.1 kodieren und dekodieren. Im Kontext vonBLAST kann die Vergleichssequenzdatei das ASN.1-Format haben, außerdem konnen dieErgebnisalignierungen als ASN.1-Datei ausgegeben werden. Im Normalfall wird fur die Se-quenzdatensammlung das FASTA-Format verwendet, und die Ergebnisse werden in Formdes BLAST-Reports ausgegeben. Deshalb soll hier nicht naher auf ASN.1 eingegangenwerden.

Das Toolkit verwendet eine Setup-Datei namens .ncbirc (Unix) bzw. ncbi.ini (Win-dows). Sie spezifiziert einen Verzeichnispfad, der unter anderem die Bewertungsmatrix-Dateien beherbergt. Die Setup-Datei muss sich im Arbeitsverzeichnis desjenigen Benutzersbefinden, der ein Werkzeug aus dem Toolkit aufruft.

4.2 Die Module des Programms BLAST

Die BLAST-Varianten blastp, blastn, blastx, tblastn und tblastx sind im Werkzeug blastallzusammengefasst. blastall ist ein Kommandozeilenprogramm, das mit Hilfe von Aufrufpa-rametern (siehe Anhang A) gesteuert wird. Als Eingabe verwendet das Programm zweiDateien, die Anfragesequenzdatei und die Datensammlungs-Datei. blastall produziert alsAusgabe eine Report-Datei, die die Alignierungen enthalt. Abbildung 4.1 stellt das Zusam-menspiel der verschiedenen Dateien dar.

Zur Anpassung des Programms wird zunachst auf die Kern-Dateien von BLAST einge-gangen:

20


• blastall.cDiese Datei enthalt die Main()-Funktion des Programms. Sie wird von der eigentli-chen main()-Funktion der CoreLib-Bibliothek aufgerufen, die eine genormte Schnitt-stelle fur verschiedene Programme und deren Parameterverarbeitung darstellt.

• blast.c fasst die Funktionen fur den BLAST-Algorithmus zusammen. Dazu gehorenFunktionen zur Initialisierung von BLAST-Datenstrukturen sowie zur Ausfuhrungder einzelnen Algorithmusschritte.

• blastkar.cIn dieser Datei sind Funktionen zur Bewertung von Alignierungen und zur Berechnungvon Entscheidungsvariablen enthalten. Unter anderem wird damit die Relevanz vonAlignierungen bewertet.

• In blastutl.c befinden sich Hilfsfunktionen zur Reservierung und Freigabe von BLAST-Datenstrukturen sowie zur Auswertung der Programmparameter. Die Funktionenbilden das Gerust fur den BLAST-Algorithmus und werden deshalb nicht nur vonblastall, sondern auch von anderen Werkzeugen verwendet.

• blastool.c umfasst mehrere Funktionsgruppen. Zunachst enthalt es Funktionen zumSetzen von Standardwerten fur die Eingabeparameter und fur statistische Parame-ter von BLAST. Das Modul ist außerdem fur die Formatierung des BLAST-Reportsverantwortlich.

• gapxdrop.cDieses Modul enthalt die Implementation fur die luckenbehaftete Alignierung und furderen Darstellung im BLAST-Report.

• Die Funktionen des Moduls lookup.c implementieren den BLAST-Vorverarbeitungs-schritt der w-mer-Bildung. Sie erzeugen und verwalten eine Indexstruktur fur diew-mere, mit deren Hilfe die Hits in den Vergleichssequenzen gesucht werden.

• readdb.cDas Modul readdb ist die ”Datenbank”-Schnittstelle zu den Sequenzdateien. Da esmaßgeblicher Gegenstand der BLAST-Anpassung an eine relationale Datenbank ist,wird sein Aufbau im folgenden Abschnitt 4.3.3 detailliert erlautert.

• dust.cGegenstand dieses Moduls ist der Filteralgorithmus DUST, der fur die Filterung derNukleotid-Anfragesequenz verwendet wird.

• seg.cDieses Modul behandelt den Filteralgorithmus SEG [29], der fur die Filterung derAminosaure-Anfragesequenz verwendet wird. SEG wurde als eigenstandiges Pro-gramm entwickelt und ist mittlerweile Bestandteil des Toolkits.

• tofasta.c dient der Bearbeitung von Dateien im FASTA-Format (siehe Anhang B.1).

Die Aufzahlung beinhaltet ausschließlich Dateien, die unmittelbar fur den Ablauf vonBLAST benotigt werden.

21


4.3 Die ”Datenbank”-Schnittstelle von BLAST

4.3.1 BLAST-Datensammlungen

Bei einer BLAST-Sequenzdatensammlung handelt es sich um eine Datei im FASTA-Format,in der Sequenzen und deren Kennungen gespeichert sind. Damit BLAST diese Daten-sammlung verwenden kann, wird sie vom Werkzeug FormatDB, das Bestandteil des NCBI-Toolkits ist, formatiert. Der Dateiname <Datensammlungsname>.nt deutet auf eine Nukleo-tid-Datensammlung hin, und <Datensammlungsname>.aa steht fur eine Aminosaure-Daten-sammlung. Nach der Formatierung durch FormatDB entstehen aus den FASTA-Dateienfolgende Dateien (als Beispiel dient hier die Datensammlung ecoli.aa):

• ecoli.aa.phr enthalt die Kennungen der Vergleichssequenzen. Fur Nukleotid-Daten-sammlungen ist die Dateiendung .nhr.

• ecoli.aa.psq enthalt die eigentlichen Sequenzen. Diese sind nicht im ASCII-Formatder ursprunglichen FASTA-Datei abgelegt, sondern werden kodiert gespeichert. DieDateiendung fur Nukleotid-Datensammlungen ist .nsq.

• In ecoli.aa.pin sind allgemeine Kennwerte der Datensammlung sowie mehrere In-dizes abgelegt. Die Indizes verweisen auf die Positionen der Sequenzkennungen undder Sequenzen in den anderen beiden Dateien. Die Dateiendung fur Nukleotid-Datensammlungen ist .nin.

Die konkreten Dateiformate beschreibt Anhang B.2. Diese Dateien dienen als Eingabe furblastall (Abbildung 4.1). Dabei gibt es mehrere Moglichkeiten, dem Programm mitzuteilen,welche Sequenzen fur den Vergleich mit einer Anfragesequenz benutzt werden sollen:

1. Auf der Kommandozeile werden mit der blastall -Option -d eine oder mehrere Daten-sammlungsnamen angegeben. Die Namen entsprechen denen der FASTA-Dateien,obwohl BLAST nur die daraus formatierten Dateien verwendet. Das Konzept zumUmgang mit mehreren Datensammlungen besteht darin, alle Sequenzen der uberge-benen Datensammlungen zu nummerieren, beginnend beim Wert 0. Die Ordnung derSequenzen entspricht der in den Datensammlungsdateien, die Ordnung der Daten-sammlungsdateien entspricht der Reihenfolge bei der Kommandozeilenoption -d.

2. Zur Erzeugung einer virtuellen Datensammlung kann eine Alias-Datei erzeugt werden,die mehrere reale Datensammlungen unter einem Namen zusammenfasst. Der Nameder Datei ist <Aliasname>.nal fur Nukleotid- bzw. <Aliasname>.pal fur Proteinda-tensammlungen. Die Angabe von <Aliasname> bei der Option -d ist gleichbedeutendmit der Angabe der darin enthaltenen realen Datensammlungsnamen. Alias-Dateienkonnen außerdem zwei spezielle Abschnitte enthalten:

(a) Die Angabe einer Liste von Ordnungszahlen (OIDList) schrankt die BLAST-Suche auf die Vergleichssequenzen mit den entsprechenden Ordnungszahlen ein.

(b) Die Angabe einer Liste von GenInfo-Kennungen (GI-IDs) schrankt die BLAST-Suche auf die Vergleichssequenzen mit den entsprechenden Kennungen ein. Aufdie GI-IDs wird im folgenden Absatz eingegangen.

22


3. Mit der Option -l wird eine Datei angegeben, die eine Liste von GenInfo-IDs umfasst(GI-Datei). Die BLAST-Suche beschrankt sich dann auf die Vergleichssequenzen mitden entsprechenden GI-IDs.

Die Angabe mehrerer Datensammlungen kann auf mehreren Ebenen erfolgen, d.h. Real-und Alias-Datensammlungen konnen gemischt bei -d angegeben werden. Außerdem konnenAliasdateien andere Aliasdatensammlungen enthalten.

Die GenInfo-IDs entstammen einer Datenbank am NCBI, der ”ID”-Datenbank. Siewird immer dann aktualisiert, wenn beim NCBI eine neue Sequenz von einer der großenSequenzdatenbanken (z.B. PIR, SWISSPROT ) registriert wird. Diese Sequenzen besitzengemaß einer Nomenklatur eine Kennung, die unter anderem ihre Datenbank-Herkunft an-gibt. Die GenInfo-Kennungen (GI-IDs) des NCBI dienen dazu, auf alle Sequenzen uber eineeinheitliche Nummerierung zuzugreifen. Der Aufbau einer GI-Kennung ist der folgende:

gi|<ID in der ID-Datenbank>

Die Kennung einer Sequenz in einer FASTA-Datei ist meist eine Aneinanderkettung derGI-ID und der Kennung, die vom ”Erzeuger” der Sequenz (z.B. PIR) vergeben wurde.

4.3.2 Die interne Kodierung von Sequenzen

Sowohl die Anfragesequenz als auch die Vergleichssequenzen werden fur die Benutzung imBLAST-Algorithmus kodiert. Da die Kodierung von Aminosaure- und Nukleotidsequenzenunterschiedlich ist, werden sie in getrennten Unterabschnitten behandelt.

4.3.2.1 Die Kodierung von Nukleotidsequenzen

Nukleotid-Sequenzen werden in einer FASTA-Datei ebenfalls mit einem Buchstaben (sieheTabelle 2.2) pro Nukleotid dargestellt. Fur diese Sequenzen werden zwei Kodierungenverwendet. Die erste Kodierung orientiert sich an der Uberlegung, dass fast alle Residuenin einer Sequenz Elementarresiduen sind. Die meisten Sequenzen enthalten demnach nurdie eindeutigen Nukleotide A, C, G und T. Fur solche Sequenzen genugt die NCBI2na-Kodierung (Tabelle 4.1). Die Kodierung verwendet 2 bit pro Residuum, somit konnen vierResiduen in einem Byte kodiert werden. Die Residuen aus der Sequenz werden zuerst inden signifikantesten Bits gespeichert, d.h. das erste Residuum einer Sequenz wird in denBits 7 und 8 des ersten Bytes abgelegt und so fort. Fur das Ende der Sequenz werden zweiFalle unterschieden:

1. Falls das letzte Byte vollstandig belegt wird, bedeutet dies, dass die Lange der ur-sprunglichen Sequenz ein Vielfaches von vier ist. In diesem Fall wird ein Null-Bytean die kodierte Sequenz angehangt.

2. Falls das letzte Byte unvollstandig belegt wird, bedeutet dies, dass die Lange der ur-sprunglichen Sequenz nicht durch vier teilbar ist. Weiterhin hat das die Auswirkung,dass die Bits 1 und 0 des letzten Byte in jedem Fall unbelegt sind. In diesen Bits wirddeshalb die Anzahl der Residuen in dem Byte eingetragen, also der Rest der Divisi-on der Lange durch vier (ein Wert zwischen 1 und 3). Damit kann die tatsachliche

23


Symbol NCBI2na-Code NameA 0 AdeninC 1 CytosinG 2 GuaninT 3 Thymin/Uracil

Tabelle 4.1: NCBI2na-Kodierung von Nukleotiden

Symbol NCBI4na-Code BLASTna-Code- 0 15A 1 0C 2 1M 3 6G 4 2R 5 4S 6 9V 7 13T 8 3W 9 8Y 10 5H 11 12K 12 7D 13 11B 14 10

N/X 15 14

Tabelle 4.2: Mehrdeutigkeitskodierungen NCBI4na und BLASTna von Nukleotiden

Lange der Sequenz aus diesem Byte und der Lange der kodierten Sequenz determiniertwerden.

Da die meisten Sequenzen nur Elementarresiduen enthalten, konnen sie mit einem Vierteldes ursprunglichen Speicherbedarfs gespeichert werden. Der BLAST-Algorithmus ist aufdiese Kodierung abgestimmt, benotigt also weniger Zeit als ein vergleichbarer Algorithmusauf der Basis von ”Ein-Residuum-Bytes”.

Die NCBI2na-Kodierung hat allerdings den Nachteil, dass Mehrdeutigkeitsresiduennicht eindeutig dargestellt werden konnen. Sie werden durch Zufallswerte im Bereich{0, . . . , 3} reprasentiert. Sequenzen mit Mehrdeutigkeitsresiduen mussen deshalb eine zu-satzliche Kodierung erfahren. Bei dieser zweiten Kodierung werden zusammenhangende,gleichartige Residuen (also Ketten gleicher Buchstaben) gemeinsam in einem 4-Byte-Blockkodiert. Die einzelnen Bits haben folgende Bedeutung:

31 · · · 28 27 · · · 24 23 · · · 0Code Anzahl Position in der Sequenz

Als Code fur die entsprechenden Mehrdeutigkeitsresiduen wird NCBI4na aus Tabelle 4.2verwendet. Die beiden Sequenzen werden im BLAST-Algorithmus nacheinander verwendet:Zunachst wird mittels der NCBI2na-Kodierung aligniert, im Fall von Mehrdeutigkeitenwird die Alignierung mittels NCBI4na und BLASTna neu berechnet (”reevaluiert”).

24


Symbol Wert Name- 0 LuckeA 1 AlaninB 2 Asparaginsaure oder AsparaginC 3 CysteinD 4 AsparaginsaureE 5 GlutaminsaureF 6 PhenylalaninG 7 GlycinH 8 HistidinI 9 IsoleucinK 10 LysinL 11 LeucinM 12 MethioninN 13 AsparaginP 14 ProlinQ 15 GlutaminR 16 ArgininS 17 SerinT 18 ThreoninV 19 ValinW 20 TryptophanX 21 nicht festgelegtes oder atypisches ResiduumY 22 TyrosinZ 23 Glutaminsaure oder GlutaminU 24 Selenocystein1

* 25 Ende einer Sequenz

Tabelle 4.3: NCBIstdaa-Kodierung von Aminosauren

4.3.2.2 Die Kodierung von Proteinsequenzen

Proteinsequenzen sind im FASTA-Format als Buchstabenfolgen gespeichert. Wurde manmittels des dort verwendeten Alphabets (siehe Tabelle 2.3) den Wert eines Residuenpaaresberechnen, musste man als Indizes fur die Substitutionsmatrix die ASCII-Werte der bei-den Symbole verwenden. Zur Verkleinerung der Matrix und zur Vereinfachung von derenInitialisierung wurde die NCBIstdaa-Kodierung (Tabelle 4.3) eingefuhrt, die jedem Symboleinen Wert im Bereich {0, . . . , 25} zuordnet. Der Speicherbedarf einer Sequenz bleibt durchdie Kodierung unverandert, da jedes Residuum auch nach der Kodierung ein Byte belegt.

4.3.3 Dateischnittstellenfunktionen

Das Modul readdb wurde bereits als Dateischnittstelle von BLAST identifiziert. In die-sem Abschnitt werden vor allem diejenigen Funktionen beleuchtet, die im Rahmen einerAnpassung an relationale Datenbanken modifiziert werden mussen.

Grundlage des Moduls ist die Datenstruktur ReadDBFILE. Sie speichert alle relevan-ten Informationen einer BLAST-Datensammlung. Falls mehrere Datensammlungen von

1Selenocystein ist im ursprunglichen Alphabet nicht enthalten. Es wird in seltenen Fallen aus demBasentriplett UGA kodiert, das eigentlich ein Stoppcodon ist [24].

25


blastall durchsucht werden, so wird jede von ihnen durch eine eigene ReadDBFILE-Strukturreprasentiert. Die Strukturen werden als verkettete Liste gespeichert.

In readdb wird das Konzept von Hauptspeicherdateien (memory-mapped files, im Fol-genden kurz MMFs) verwendet. Der Zugriff auf Hauptspeicherdateien ist analog zu demauf normale Dateien. Intern werden die Dateizugriffsfunktionen allerdings auf Zeigerope-rationen im Hauptspeicher abgebildet. In readdb werden folgende Funktionen zum Zugriffauf MMFs zur Verfugung gestellt

• Offnen (NlmOpenMFILE()) eines MMF

• Schließen (NlmCloseMFILE()) des MMF

• Lesen (NlmReadMFILE()) von Daten aus dem MMF und gleichzeitiges Verschiebendes Dateizeigers

• Abfragen des Dateizeigers (NlmTellMFile())

• Setzen des Dateizeigers (NlmSeekInMFile())

Das Schreiben in MMFs ist nicht implementiert, da es nicht benotigt wird. Alle dreiDateien (Sequenz-, Kennungs- und Indexdatei) einer BLAST-Datensammlung werden alsMMF verwendet. Die Sequenz- und die Kennungsdatei werden dabei ausschließlich uberdie Funktionen NlmReadMFile() und NlmTellMFile() angesteuert. Die Index-Datei wirdhingegen ausgelesen und die in ihr enthaltenen Kennwerte in ReadDBFILE-Variablen gespei-chert, ebenso die Index-Positionen im Hauptspeicher. Im Zusammenhang mit den MMFsmussen noch die Funktionen

• ReadDBOpenMHdrAndSeqFiles() und

• ReadDBCloseMHdrAndSeqFiles()

erwahnt werden. Diese Funktionen offnen bzw. schließen die Kennungs- und die Sequenz-datei durch Aufruf obiger MMF-Funktionen.

Im Rahmen einer BLAST-Anpassung sollten die hier aufgefuhrten Funktionen nichtaufgerufen werden, da die entsprechenden Dateien durch die relationale Datenbank ersetztwerden. Die folgenden Funktionen rufen die bisher genannten Funktionen auf oder greifenauf die Indizes zu. Sie sind deshalb Kandidaten fur eine Modifikation im Kontext derblastall -Anpassung:

• readdb_new_internal() ist die zentrale Initialisierungsfunktion fur die ReadDBFILE-Struktur. Unter anderem offnet sie die Datensammlungsdateien und liest Kennwerteund Indizes aus.

• readdb_attach() dient der Vervielfaltigung der ReadDBFILE-Datenstruktur. Unteranderem werden dabei die Verwaltungsstrukturen fur die MMFs kopiert.

• readdb_get_link() erhalt als Argument die Ordnungszahl einer Sequenz. Die Funk-tion hat die Aufgabe, in der verketteten Liste der ReadDBFILE-Strukturen nach demje-nigen Element (derjenigen Datensammlung) zu suchen, das die Sequenz mit der uber-gebenen Ordnungszahl enthalt.

26


• readdb_destruct_element() gibt Speicherbereiche, die von ReadDBFILE-Elementenbelegt werden, wieder frei. Dabei werden auch die MMFs geschlossen.

• readdb_destruct() fuhrt zunachst ReadDBCloseMHdrAndSeqFiles() aus und ruftdann fur jedes Element der ReadDBFILE-Liste readdb_destruct_element() auf.

• readdb_get_sequence() wird mit der Ordnungszahl einer Sequenz aufgerufen undgibt die (kodierte) Sequenz und deren unkodierte Lange zuruck. Zur Ruckgabe derSequenz und zur Bestimmung von deren Lange wird auf den Index und das entspre-chende MMF zugegriffen. Nukleotidsequenzen werden in der 2bit-Kodierung zuruck-gegeben.

• readdb_get_sequence_length() erhalt als Parameter die Ordnungszahl einer Se-quenz. Die Funktion gibt die unkodierte Lange der Sequenz zuruck. Dabei wird aufden Sequenz-Index zugegriffen.

• readdb_get_ambchar() gibt die 4-Byte-Kodierung der Mehrdeutigkeitsresiduen einerSequenz zuruck. Zur Identifikation der Sequenz wird deren Ordnungszahl ubergeben.Die Funktion wird nur fur Nukleotidsequenzen verwendet. Besitzt die Sequenz keineMehrdeutigkeitsresiduen, wird NULL zuruckgegeben.

• readdb_ambchar_present() wird mit der Ordnungszahl einer Sequenz aufgerufenund gibt Auskunft daruber, ob eine Sequenz Mehrdeutigkeitsresiduen enthalt. Indiesem Fall gibt sie TRUE zuruck, im negativen Fall FALSE.

• Die Funktion readdb_get_defline_ex() gibt die Kennung der Sequenz zuruck, derenOrdnungszahl ubergeben wird. Dazu wird auf den Kennungsindex zugegriffen.

• readdb_get_header() hat eine ahnliche Funktion wie readdb_get_defline_ex().Sie wird im Kontext von Alias-Dateien bzw. GI-Dateien (Option -l) verwendet undist deshalb fur die BLAST-Anpassung unkritisch, da im Rahmen einer relationalenDatenbank keine Alias-Datensammlungsdateien bzw. GI-Dateien verwendet werden.

• ReadOIDList() und OIDListFree() werden im Fall einer Alias-Datensammlung ver-wendet. Die Funktionen sind deshalb unkritisch fur die BLAST-Anpassung.

• GetGisFromFile() (Modul blast.c) ruft die ReadDBOpen/CloseMHdrAndSeqFiles()-Funktionen auf. GetGisFromFile() wird nur im Zusammenhang mit einer GI-Dateiverwendet und ist deshalb bei der Anpassung nicht von Interesse.

• do_the_blast_run() und BLASTSetUpSearchWithReadDbInternal() aus blast.c ru-fen ebenfalls ReadDBOpen/CloseMHdrAndSeqFiles() auf.

Eine Reihe von readdb-Funktionen liest Kennwerte einer Datensammlung bzw. aller betei-ligten Datensammlungen aus den Elementen der ReadDBFILE-Struktur. Diese Funktionensind unkritisch, da die entsprechenden Variablen durch readdb_new_internal() gesetztwerden. Der Vollstandigkeit halber werden die Kennwerte-Funktionen im Anhang B.2 auf-gelistet.

readdb-Funktionen, die in diesem Abschnitt nicht erwahnt werden, sind bei der Anpas-sung von blastall unkritisch in Bezug auf den MMF-Zugriff.

27


4.4 Der Ablauf von blastall

Die Verwendung der Dateischnittstelle ist in den Ablauf des gesamten Programms ein-gebettet. Dieser Abschnitt analysiert die wichtigsten Funktionen von blastall und gehtder Fragestellung nach, in welcher Weise die Funktionen die Dateischnittstelle nutzen undwelche Auswirkungen das auf die Anpassung von BLAST hat. Die dafur verwendeten Ab-laufschemata einiger Funktionen sind in einem an die Sprache C angelehnten Pseudocodebeschrieben.

4.4.1 Die Main()-Funktion

Die Einstiegsfunktion des Programms blastall ist die Funktion Main(). Sie fuhrt schema-tisch die folgenden Schritte aus:

1. Lesen der Aufrufparameter, Initialisierung einiger BLAST_OptionsBlk-Elemente

2. Offnen der Eingabe- (Anfragesequenz) und der Ausgabe-Datei (BLAST-Report)

3. Initialisierung weiterer BLAST_OptionsBlk-Elemente mit Aufrufparameterwerten

4. Lesen und Dekodieren der Anfragesequenz

5. Ausgabe allgemeiner Informationen und Datensammlungskennwerte in die Report-Datei

6. Aufruf der BLAST-Hauptroutine BioseqBlastEngine() (Modul blastutl.c)

7. Ausgabe des BLAST-Reports (siehe Anhang B.3) in die Ausgabedatei

8. Freigabe dynamischer Variablen

Zur Speicherung der Programmparameter sowie davon abgeleiteter Variablen wird eineDatenstruktur vom Typ BLAST_OptionsBlk verwendet. Sie dient zur Initialisierung derFunktion BioseqBlastEngine(), die den Einstiegspunkt in die konkrete BLAST-Imple-mentierung bildet.

4.4.2 Die Funktion BioseqBlastEngineByLocEx()

Die Funktion BioseqBlastEngineByLocEx() wird mittels folgender Aufrufkette erreicht:

BioseqBlastEngine()↓

BioseqBlastEngineByLoc()↓

BioseqBlastEngineByLocEx()

BioseqBlastEngineByLocEx() hat folgenden schematischen Ablauf:

1. Validierung der BLAST_OptionsBlk-Struktur. BLASTOptionValidateEx() uberpruft,ob die Werte von Programmparametern und davon abgeleitete Werte gultig sind undzur verwendeten Programmvariante passen.

28


BioseqBlastEngineCore(searchBlk, optionsBlk)

{

if (PSI-BLAST)

[...]

[...]

do_the_blast_run(searchBlk);

if (BLASTN && GAPPED) {

[...]

for(i = 0; i < #hits; ++i) {

length = readdb_get_sequence_ex(...,&sequence,...)

seqalign = SumBlastGetGappedAlignmentWithTraceback(searchBlk,i,...,

sequence,length);

[...]

}

[seqaligns zu Liste verketten]

}

else if (GAPPED) {

[...]

for(i = 0; i < #hits; ++i) {

seqalign = BlastGetGapAlgnTbckWithReaddb(search, index, ...);

}

[seqaligns zu Liste verketten]

}

else {

if (PSI-BLAST)

[...]

else seqalign = GetSeqAlignForResultHitList(searchBlk,...);

}

return seqalign;

}

Abbildung 4.2: schematischer Ablauf von BioseqBlastEngineCore()

2. Initialisierung der BlastSearchBlk-Struktur. Diese Datenstruktur wird mit Hil-fe der Funktion BLASTSetUpSearchByLocWithReadDbEx() vorbereitet. Zur Initia-lisierung gehoren unter anderem der Aufruf von readdb_new_internal() sowie derBLAST-Vorberechnungsschritt zur Bestimmung der w-mere. Die w-mer-Bildung wirdfur Protein-Anfragesequenzen mit der Funktion BlastFindWords(), fur Nukleotid-Anfragesequenzen mit BlastNtFindWords() durchgefuhrt.

3. Ausfuhrung des eigentlichen Algorithmus. Die dafur verantwortliche Funktion istBioseqBlastEngineCore() (siehe folgender Abschnitt).

Die Datenstruktur BlastSearchBlk umfasst samtliche Parameter, die fur den Algorithmusbenotigt werden. In der Struktur werden auch die Ergebnisse zwischengespeichert.

4.4.3 Die Funktion BioseqBlastEngineCore()

Die Funktion BioseqBlastEngineCore() umfasst die Aufrufe all jener Funktionen, dieden eigentlichen Algorithmus ausfuhren. Der im Kontext von blastall relevante Teil der

29


Funktion ist in Abbildung 4.2 dargestellt. Der Ablauf besteht aus den folgenden Schritten:

1. Die Routine do_the_blast_run() fuhrt den Schritt der luckenfreien Alignierung derAnfragesequenz mit allen Vergleichssequenzen durch. Die Funktion nutzt die Fahig-keit des multithreading zur parallelen Ausfuhrung des Algorithmus auf mehreren Se-quenzen. Der Aufbau von do_the_blast_run() wird im Abschnitt 4.5 im Detailerlautert.

2. Nach dem Aufruf von do_the_blast_run() sind die HSPs der luckenfreien Alignie-rungen in der BlastSearchBlk-Struktur abgelegt. Wurde das Programm als GappedBLAST gestartet (Programmparameter -g), so wird an dieser Stelle fur jedes HSPeine der folgenden Funktionen zur Bildung einer luckenbehafteten Alignierung aufge-rufen:

• SumBlastGetGappedAlignmentWithTraceback() fur die Variante blastn

• BlastGetGapAlgnTbckWithReaddb() fur alle anderen Programmvarianten

Das Ergebnis beider Funktion ist eine verkettete Liste von SeqAlign-Elementen.

3. Ohne Angabe der -g-Option wird GetSeqAlignForResultHitList() aufgerufen, dasdie Zwischenergebnisse aus der BlastSearchBlk-Struktur in eine verkettete Liste vonSeqAlign-Elementen konvertiert.

Die Datenstruktur SeqAlign dient der Speicherung von Alignierungen jeden Typs. Da siebei der Anpassung von Bedeutung ist, wird sie im Abschnitt 4.6 detailliert beschrieben.

4.4.4 Die Funktion do blast search()

Zur Funktion do_blast_search() gelangt man mittels folgender Aufrufkette:

BioseqBlastEngineCore()↓

do_the_blast_run()↓

do_blast_search()

do_blast_search() wird entweder direkt oder durch den Start eines threads aufgerufen.Die Funktion ermittelt luckenfreie Alignierungen der Anfragesequenz mit den Vergleichs-sequenzen. Zum schematischen Ablauf der Funktion (siehe Abbildung 4.3) gibt es diefolgenden Bemerkungen:

• Die Funktion BlastGetDbChunk() liefert den von der Funktion do_blast_search()zu bearbeitenden Bereich der Datensammlung. startID ist die Ordnungszahl derersten zu bearbeitenden Sequenz, und stopID zeigt hinter die letzte zu bearbeitendeSequenz. Die Bedeutung dieser Funktion liegt in der Verteilung von Datensammlungs-chunks (engl.: chunk – Stuck, Klotz) fur den Fall, dass mehrere threads verwendetwerden. Im Normalfall gibt BlastGetDbChunk() die gesamte Datensammlung alsBereich zuruck.

30


do_blast_search(searchBlk)

{

while(BlastGetDbChunk(searchBlk, &startID, &stopID))

{

[...]

for(index = startID; index < stopID; ++index)

{

BLASTPerformSearchWithReadDb(searchBlk, index);

[...]

BlastReapHitListByEvalue(searchBlk);

BlastReevaluateWithAmbiguities(searchBlk, index);

BlastSaveCurrentHitlist(searchBlk);

}

}

[...]

}

Abbildung 4.3: schematischer Ablauf von do blast search()

• Die for-Schleife iteriert uber alle Sequenzen im durch startID und stopID festgeleg-ten Bereich. Folglich werden immer zusammenhangende Stucke der Datensammlungbearbeitet.

• Die Funktion BLASTPerformSearchWithReadDb() liest die Sequenz mit der Ord-nungszahl i ein und fuhrt den BLAST-Algorithmus aus.

• BlastReapHitListByEvalue() entfernt Alignierungen zwischen Vergleichs- und An-fragesequenz aus der Ergebnisstruktur, falls deren berechneter Erwartungswert großerist als der dem Programm ubergebene Schwellwert (Programmparameter -e).

• Die Funktion BlastReevaluateWithAmbiguities() betrachtet noch einmal jene Se-quenzen gesondert, die Mehrdeutigkeitsresiduen enthalten, da deren Alignierungenwegen der Zufallskodierung in NCBI2na moglicherweise fehlerhafte Werte liefern. DieFunktion ist nur fur Nukleotidsequenzen relevant.

• BlastSaveCurrentHitlist() integriert die aus der Sequenz gewonnene Liste vonAlignierungen (hitlist) in die HSP-Liste aller Sequenzen. Die hitlist ist eine Zwi-schenstruktur und darf nicht mit der Datenstruktur SeqAlign verwechselt werden.

Das Pendant von do_blast_search() ist do_gapped_blast_search(). Diese Funktionwird auf die gleiche Art und Weise aufgerufen. Sie fuhrt keine luckenbehaftete Alignie-rung durch (obwohl der Name das suggeriert), sondern bildet lediglich die HSPs fur eineanschließende Ausrichtung mit Lucken.

Die Funktionen do_blast_search() und do_gapped_blast_search() haben einen ahn-lichen Aufbau. Deswegen wird letztere nicht gesondert erlautert. In den folgenden Ab-schnitten werden diese Funktionen unter dem Namen ..._blast_search() gemeinsambetrachtet, sofern nicht nur eine von ihnen gemeint ist.

31


BLASTPerformSearchWithReadDb(searchBlk,seqNum)

{

length = readdb_get_sequence(searchBlk->rdfp, seqNum, &seq);

[...]

BLASTPerformSearch(searchBlk, length, seq);

}

Abbildung 4.4: schematischer Ablauf von BLASTPerformSearchWithReadDb()

BlastReevaluateWithAmbiguities(searchBlk,seqNum)

{

if (searchBlk->prog_number == {BLASTP || BLASTX} )

exit;

if (GAPPED BLAST)

exit;

if (! HITS FOUND)

exit;

if (readdb_ambchar_present(searchBlk->rdfp, seqNum)) == FALSE)

exit;

[...]

bsp = readdb_get_bioseq(searchBlk->rdfp, seqNum);

[Reevaluation...]

}

Abbildung 4.5: schematischer Ablauf von BlastReevaluateWithAmbiguities()

4.4.5 Die Funktion BLASTPerformSearchWithReadDb()

Von ..._blast_search() wird die Funktion BLASTPerformSearchWithReadDb() auf-gerufen. Diese liest mit Hilfe von readdb_get_sequence() die Sequenz mit der uberge-benen Ordnungszahl und ubergibt diese der Funktion BLASTPerformSearch(), die die Se-quenz mit der Anfragesequenz aligniert. Das Ergebnis wird in BlastSearchBlk-Variablengespeichert. Abbildung 4.4 stellt den schematischen Aufbau der Funktion dar.

4.4.6 Die Funktion BlastReevaluateWithAmbiguities()

BlastReevaluateWithAmbiguities() ist fur die Alignierung von Nukleotidsequenzen vonBedeutung, die Mehrdeutigkeitsresiduen enthalten. In Abschnitt 4.3.2.1 wurde bereits dar-auf hingewiesen, dass Mehrdeutigkeiten durch die NCBI2na-Kodierung einen Zufallswerterhalten. Aus diesem Grund werden Sequenzen mit Mehrdeutigkeiten durch die FunktionBlastReevaluateWithAmbiguities() neu aligniert.

32


Abbildung 4.5 zeigt das Ablaufschema von BlastReevaluateWithAmbiguities(). Nachdem Test auf Mehrdeutigkeitsresiduen in der Sequenz (readdb_ambchar_present()) wirddie Funktion readdb_get_bioseq() ausgefuhrt, die wiederum zu den folgenden readdb-Funktionen verzweigt:

• readdb_get_descriptor()

• readdb_get_sequence()

• readdb_get_ambchar()

Die sich anschließende Reevaluation ruft keine weiteren Funktionen der Dateischnittstelleauf.

Eine Besonderheit der Reevaluation ist, dass das Nukleotid-Bewertungsschema, das nurzwischen matches und mismatches unterscheidet, hier nicht angewendet werden kann. Daein Mehrdeutigkeitsresiduum fur mehrere Elementarresiduen stehen kann, muss eine Substi-tutionsmatrix verwendet werden. Die Substitutionsmatrix wird wahrend der Initialisierungaus den Werten fur match und mismatch berechnet. Fur die Indizierung der Matrix wird dieKodierung BLASTna (siehe Tabelle 4.2) verwendet. Deshalb stellt das Programm die Kon-vertierungsfunktionen ncbi4na_to_blastna[] und blastna_to_ncbi4na[] zur Verfugung,die die beiden Kodierungen NCBI4na und BLASTna ineinander umwandeln. Die Konver-tierungsfunktionen sind als Feldvariablen realisiert.

4.5 Analyse des multithreading in BLAST

Das Programm blastall unterstutzt sogenanntes multithreading. Das bedeutet, dass mehrereInstanzen der gleichen Funktion (threads) parallel zueinander abgearbeitet werden konnen.Damit kann das Vorhandensein mehrerer Prozessoren auf einer SMP -Maschine (SymmetricMultiprocessing) ausgenutzt werden. Die Verwendung von mehr als einem Prozessor wirdbei blastall durch den Programmparameter -a eingestellt. Die Anzahl der Prozessoren wirdin diesem Abschnitt mit n bezeichnet.

Grundlage der Parallelisierung ist die Funktion do_the_blast_run(). Die Funktionfuhrt folgende Schritte aus (siehe Abbildung 4.6):

1. Zur Verwendung gemeinsamer Ressourcen durch die threads werden Mutexe initia-lisiert (NlmMutexInit()). Auf das Mutex-Konzept wird im folgenden Absatz nahereingegangen.

2. Zur Initialisierung des multithreading wird die BlastSearchBlk-Struktur n − 1 maldupliziert (BlastSearchBlkDuplicate()). Jeder thread arbeitet damit auf seinereigenen Struktur. Beim Kopieren der Struktur werden die Zeiger auf die Indizes unddie MMFs mit kopiert. Die Indizes und die MMFs stellen somit geteilte Ressourcendar, die durch Mutexe verwaltet werden.

3. Die Funktion NlmThreadCreateEx() erzeugt jeweils einen thread, dem eine der bei-den ..._blast_search()-Funktionen und eine BlastSearchBlk-Struktur zugeord-net wird. Die ..._blast_search()-Funktion wird dann im Kontext des threadsmit der BlastSearchBlk-Struktur als Parameter aufgerufen. Der thread ist beendet,

33


wenn die ihm zugeordnete Funktion beendet ist. Die threads laufen parallel sowohlzueinander als auch zur Funktion do_the_blast_run().

4. NlmThreadJoin() ist die Synchronisationsfunktion fur die threads. Die Funktionkehrt erst zu do_the_blast_run() zuruck, wenn alle threads beendet sind.

5. Die am Anfang initialisierten Mutex-Variablen werden wieder freigegeben.

In der Aufzahlung wurde bereits das Mutex-Konzept erwahnt. Mutexe sind Synchronisa-tionsobjekte. Sie dienen zur Zugriffssteuerung auf Ressourcen, die von mehreren threadsgemeinsam genutzt werden. Der Einsatz von Mutexen verhindert den gleichzeitigen Zugriffzweier threads auf die gleiche Ressource. Mutexe haben folgende Eigenschaften:

1. Ein Mutex ist nicht an eine Ressource gebunden, sondern wird uber Anweisungen anbeliebiger Stelle im Quelltext reserviert (lock) und freigegeben (unlock). Die Logikder Mutex-Reservierung und -Freigabe obliegt dem thread und nicht einem zentralenMechanismus.

2. Ein thread erhalt eine Mutex-Reservierung, wenn kein anderer thread den Mutexreserviert hat.

3. Schafft ein thread es, einen Mutex zu reservieren, bleibt dieser solange reserviert, bisder gleiche thread ihn wieder freigibt. Zwischen den Anweisungen fur Reservierungund Freigabe sollten die Anweisungen zur Bearbeitung der zugriffskritischen Ressour-ce stehen.

4. Versucht thread 1, einen Mutex zu reservieren, der durch thread 2 reserviert ist, sowartet thread 1 solange mit seiner Ausfuhrung, bis er den Mutex selbst reserviert hat.

Die von BLAST verwendeten Mutexe gehoren zum BlastSearchBlk-Element thr_info,das eine Struktur zur Verwaltung der multithreading-relevanten Daten bereithalt. FolgendeMutexvariablen werden mit thr_info verwaltet:

• db_mutexDieser Mutex verwaltet die Zuteilung der Datensammlungsabschnitte. Bei der Be-schreibung der Funktion do_blast_search() wurde bereits BlastGetDbChunk() er-lautert. Diese Funktion teilt die Datensammlung auf und weist jedem thread einenBereich zum Bearbeiten zu. BlastGetDbChunk() fuhrt in einer allen threads gemein-samen Variable thr_info->db_chunk_last Buch daruber, welcher Datensammlungs-bereich als nachstes berechnet werden muss. Der Zugriff auf diese Variable wird mitdem Mutex gesteuert.

• results_mutexDie Funktion BlastSaveCurrentHitlist() verwendet diesen Mutex, um die Ali-gnierungen verschiedener Vergleichssequenzen in einer gemeinsamen Datenstruktur(searchBlk->result_struct) abzulegen.

• ambiguities_mutexBlastReevaluateWithAmbiguities() benotigt diesen Mutex zum Zugriff auf dieMehrdeutigkeitskodierungen der Sequenzen.

34


do_the_blast_run(searchBlk)

{

[...]

if (NlmThreadsAvailable() && searchBlk->pbp->process_num > 1) {

/*** 1. Fall: mehrere Threads ***/

[...]

/*** INITIALISIERUNG Mutexe ***/

NlmMutexInit(searchBlk->thr_info->db_mutex);

[ ...thr_info->results_mutex, ...thr_info->ambiguities_mutex ]

/*** DUPLIKATION der SearchBlk-Struktur ***/

array = malloc((searchBlk->pbp->process_num)*sizeof(BlastSearchBlkPtr));

array[0] = searchBlk;

for (index=1; index<searchBlk->pbp->process_num; index++)

array[index] = BlastSearchBlkDuplicate(searchBlk);

/*** ERZEUGEN von n Threads ***/

thread_array = malloc((searchBlk->pbp->process_num)*sizeof(TNlmThread));

for (index=0; index<searchBlk->pbp->process_num; index++) {

if (GAPPED BLAST)

thread_array[index] = NlmThreadCreateEx(do_gapped_blast_search,

array[index], [...] );

else

thread_array[index] = NlmThreadCreateEx(do_blast_search,

array[index], [...] );

}

/*** WARTEN, bis alle Threads beendet sind ***/

for (index=0; index<searchBlk->pbp->process_num; index++)

NlmThreadJoin(thread_array[index], [...] );

for (index=1; index<searchBlk->pbp->process_num; index++) {

[SAMMELN statistischer Werte aus den verschiedenen SearchBlk-Variablen...]

array[index] = BlastSearchBlkDestruct(array[index]);

}

free(array); free(thread_array);

NlmMutexDestroy(searchBlk->thr_info->db_mutex);

[ ...thr_info->results_mutex, ...thr_info->ambiguities_mutex ]

}

else /*** 2. Fall: EIN Thread ***/

if (GAPPED BLAST)

do_gapped_blast_search(searchBlk);

else

do_blast_search(searchBlk);

[...]

}

Abbildung 4.6: Schematischer Ablauf von do the blast run(). Die Variable array ist einFeld von SearchBlk-Variablen, thread array ist ein Feld von threads.

35


typedef struct seqalign {

char type,

segtype;

short int dim;

Score *score;

void *segs;

struct seqalign *next;

SeqLoc *bounds;

SeqId *master;

SeqAlignIndex *saip;

GatherIndex idx;

short int alignID;

}

SeqAlign, *SeqAlignPtr;

Abbildung 4.7: Aufbau der Datenstruktur SeqAlign

4.6 Die Datenstruktur SeqAlign

Im bisherigen Verlauf der Analyse wurde bereits der Datentyp SeqAlign angefuhrt. MitSeqAlign werden verschiedene Alignierungsarten einheitlich dargestellt. Abbildung 4.7zeigt den Aufbau des Datentyps als C-Struktur. Im Hinblick auf die Anpassung von BLASTsind die folgenden Elemente von Interesse:

• nextDie Alignierungen der Sequenzen sind in einer verketteten Liste gespeichert. DieVariable next zeigt auf das nachfolgende Element der Kette.

• typeMan unterscheidet vier Grundtypen von SeqAlign’s, wovon im Rahmen von blastallzwei von Interesse sind:

1. Im Fall type == 2 (SAT_DIAGS) sind alle Alignierungen einer Vergleichssequenzin einem einzigen SeqAlign-Element abgelegt. Die Alignierungen sind in einerListe gespeichert, die mit dem Element segs beginnt.

2. Der Wert type == 3 (SAT_PARTIAL) steht dafur, dass ein SeqAlign-Elementgenau eine Alignierung enthalt. Weitere Alignierungen der Vergleichssequenzfindet man in den nachfolgenden SeqAlign-Elementen.

• segtype, segsEs werden sechs Moglichkeiten zur Speicherung von Alignierungen unterschieden. Imblastall -Kontext sind davon drei von Interesse. Der Wert der Variablen segtypebestimmt dabei, von welchem Datentyp das Element segs ist:

1. Im Fall segtype == 1 (SAS_DENDIAG) zeigt das Element segs auf eine Strukturvom Typ DenseDiag. Dieser Typ von Alignierung wird von den luckenfreienVarianten von blastn und blastp verwendet.

2. Der Fall segtype == 2 (SAS_DENSEG) wird von den luckenbehafteten Variantenvon blastn und blastp verwendet. segs zeigt dabei auf eine DenseSeg-Variable.

36


typedef struct stdseg {

short int dim;

SeqId *ids;

SeqLoc *loc;

Score *scores;

struct stdseg *next;

}

StdSeg, *StdSegPtr;

Abbildung 4.8: Aufbau der Datenstruktur StdSeg

3. Die BLAST-Translationsvarianten blastx, tblastn und tblastx verwenden denFall segtype == 3 (SAS_STD). segs ist hier ein Zeiger auf eine StdSeg-Variable.

• dimDieses Element enthalt die Anzahl der alignierten Sequenzen. BLAST bildet immerAlignierungen von jeweils zwei Sequenzen (dim == 2).

• scoreFur den Fall type == 3 ist in dieser Variablen die Bewertung der Alignierung gespei-chert.

4.6.1 StdSeg-Alignierungen

Die Datenstruktur StdSeg ist unter den oben genannten diejenige mit der großten Kom-plexitat. Deshalb wird sie hier stellvertretend fur die anderen beiden Alignierungstypen imDetail erlautert.

Der Alignierungstyp StdSeg wird von den BLAST-Varianten blastx, tblastn und tblastxfur die Speicherung von sowohl luckenfreien als auch luckenbehafteten Alignierungen ver-wendet. Der Aufbau von StdSeg kann Abbildung 4.8 entnommen werden. Die Bedeutungeiniger Elemente von StdSeg hangt davon ab, welchen Wert die type-Variable des zugehori-gen SeqAlign-Elements hat. Im Fall type == SAT_DIAGS speichert StdSeg eine luckenfreieAlignierung der beteiligten Sequenzen. Die Elemente haben dann folgende Bedeutung:

• dimDas Element dim hat die gleiche Bedeutung wie das gleichnamige SeqAlign-Element.Im Fall von BLAST hat es immer den Wert 2. Die Bedeutung von dim ist unabhangigvom type-Wert.

• scoresDieses Element beinhaltet die Bewertung der Alignierung.

• locDie Variable ist ein Zeiger auf eine Liste mit zwei Elementen vom Typ SeqLoc. Diebeiden Elemente beschreiben die Alignierung. Die Bedeutung der SeqLoc-Strukturwird nach der type-Fallunterscheidung im Detail erlautert.

• nextDer next-Zeiger verweist auf die nachste Alignierung der gleichen Sequenz.

37


Abbildung 4.9: Die beiden Moglichkeiten, StdSeg-Alignierungen zu speichern. Der obereFall stellt die Verknupfungsstruktur fur luckenfreie Alignierungen dar, die untere Abbil-dung die fur luckenbehaftete Alignierungen. Zu beachten ist dabei, an welcher Stelle dieBewertung der Alignierung jeweils abgelegt ist.

Liegt der Fall type == SAT_PARTIAL vor, so speichert StdSeg nur ein Segment einer lucken-behafteten Alignierung. Dabei andert sich auch die Bedeutung der Elemente scores, locund next:

• Das Element scores wird in diesem Fall nicht benutzt, da die Bewertung der Ali-gnierung im SeqAlign-Element score zu finden ist.

• loc ist auch in diesem Fall eine Liste zweier SeqLoc-Elemente, allerdings speichernsie hier ein Segment einer luckenbehafteten Alignierung.

• next zeigt auf das nachste Segment der Alignierung.

Fur den Fall der luckenbehafteten Alignierung muss der Begriff Segment einer Alignierunggeklart werden. Ein Segment ist ein zusammenhangender Bereich von Residuenpaaren oderResiduum-Lucken-Paaren mit genau einer der folgenden Eigenschaften:

1. Beide Sequenzen besitzen ausschließlich Residuen in dem Bereich.

38


typedef struct seqint {

long int from,

to;

char strand;

SeqId *id;

IntFuzz *if_from,

*if_to;

}

SeqInt, PNTR SeqIntPtr;

typedef int (*Nlm_FnPtr)(void);

typedef union dataval {

void *ptrvalue;

long int *intvalue;

double *realvalue;

short int *boolvalue;

Nlm_FnPtr funcvalue;

long long *bigintvalue;

}

DataVal, *DataValPtr;

typedef struct seqloc {

char choice;

char extended;

DataVal data;

struct seqloc *next;

}

SeqLoc, PNTR SeqLocPtr;

Abbildung 4.10: Aufbau der Datenstrukturen SeqInt, DataVal und SeqLoc

2. Die Anfragesequenz (Sequenz 0) enthalt eine Lucke uber den gesamten Bereich.

3. Die Vergleichssequenz (Sequenz 1) enthalt eine Lucke uber den gesamten Bereich.

Der Unterschied zwischen den beiden type-Fallen wird in Abbildung 4.9 am Beispiel desAlignierungstyps StdSeg dargestellt.

Zur Speicherung eines Segments bzw. einer luckenfreien Alignierung wird der loc-Zeigerverwendet. Er zeigt auf das erste von zwei Variablen vom Typ SeqLoc. Der Aufbau derDatenstruktur ist in Abbildung 4.10 dargestellt. Die Elemente von SeqLoc haben folgendeBedeutung:

• Mit Hilfe des next-Zeigers verweist das erste Element der Liste auf das zweite Ele-ment. Fur das zweite Element ist dieser Wert nicht gesetzt. Die beiden Elementereprasentieren das Segment bzw. die Alignierung fur die Anfrage- und die Vergleichs-sequenz. Folgende Darstellung soll dies verdeutlichen:

StdSeg.loc → Anfragesequenz-SeqLoc .next → Vergleichssequenz-SeqLoc

• Die Elemente choice und data dienen der Speicherung von Daten dynamischer Da-

39


typedef struct score {

ObjectId *id;

char choice;

DataVal value;

struct score *next;

}

Score, *ScorePtr;

Abbildung 4.11: Aufbau der Datenstruktur Score

tentypen. choice legt dabei fest, welche Art von Daten in data gespeichert werden.Fur die Speicherung von Alignierungen werden zwei choice’s unterschieden:

1. choice == SEQLOC_INT bedeutet, dass data.ptrvalue auf eine Variable vomTyp SeqInt zeigt.

2. choice == SEQLOC_EMPTY steht dafur, dass die entsprechende Sequenz im aktu-ellen Segment eine Lucke hat. Die Lange der Lucke muss der anderen Sequenzentnommen werden. Dieser Fall tritt nur bei luckenbehafteten Alignierungenauf.

Die SeqInt-Struktur beinhaltet die konkreten Informationen, die eine Sequenz zu einerAlignierung oder einem Segment beisteuert. Von Interesse sind in diesem Zusammenhangdie folgenden Elemente:

• from und to bezeichnen den Anfangs- und End-Offset der Alignierung in der Sequenz.

• strand bezeichnet die Leserichtung der Sequenz. Bei Proteinsequenzen steht hierimmer eine 0, fur Nukleotidsequenzen existieren zwei Leserichtungen. Bei luckenbe-hafteten Alignierungen mussen nur die Werte der SeqLoc’s der ersten StdSeg-Strukturbetrachtet werden, da die Leserichtung der Sequenzen zwischen den Segmenten nichtwechselt.

Es sei erwahnt, dass mit Hilfe dieser Struktur die Alignierungen aller BLAST-Variantendargestellt werden konnen. Die Programme blastn und blastp nutzen allerdings die ein-facher strukturierten Typen DenseDiag und DenseSeg. Deren Aufbau kann Anhang C.1entnommen werden.

4.6.2 Die Speicherung von Alignment-Bewertungen

In den Strukturen SeqAlign und StdSeg ist neben den Alignierungen auch deren Be-wertung gespeichert. Da eine Alignierung mehrere Bewertungsmaße haben kann, mussendiese in einer dynamischen Struktur abgelegt werden. Die Elemente score bzw. scores deroben genannten Strukturen zeigen auf eine verkettete Liste verschiedener Bewertungsmaße,die jede in einer Score-Datenstruktur abgelegt sind. Deren Aufbau kann Abbildung 4.11entnommen werden. Die Elemente haben folgende Bedeutung:

• Das Element id ist vom Typ ObjectId, das ein Datenelement str enthalt. Diesesspeichert den Namen der Bewertung.

40


• Die Elemente choice und value stehen im gleichen Zusammenhang wie choice unddata in der SeqLoc-Datenstruktur. Im Zusammenhang mit Bewertungen gibt es zweisinnvolle choice-Werte. Hat choice den Wert 1, so ist in value der Ganzzahlwert(long int) gesetzt, im Fall choice == 2 beinhaltet value einen Fließkommawert(double).

• Der next-Zeiger verweist auf weitere Bewertungsmaße.

41

Kapitel 5

Verwendete Datenbankkonzepte

Ziel dieser Arbeit ist es, BLAST im Rahmen eines relationalen Datenbanksystems zu ver-wenden. Voraussetzung dafur ist eine relational modellierte Genomdatenbank.

Die Verknupfung von BLAST mit einer relationalen Datenbank wird mit dem Daten-banksystem DB2 UDB realisiert. DB2 UDB (Universal Database) ist ein objektrelationa-les Datenbanksystem und wurde vom Unternehmen IBM entwickelt. Die im Kontext dieserDiplomarbeit verwendete Version des Datenbanksystems ist DB2 Version 7.1 EnterpriseExtended Edition fur das Betriebssystem Solaris.

Das Kapitel fasst die Konzepte zusammen, die aus Datenbanksicht fur die Anpassungvon BLAST benotigt werden.

5.1 Datenmodellierung der Biosequenzen

Ein relationales Datenbanksystem zeichnet sich dadurch aus, dass die darin zu speicherndenDaten relational modelliert [9] werden mussen. Dieser Abschnitt geht auf den Teil desDatenmodells ein, der die Biosequenzen beschreibt. Das Modell (Abbildung 5.1) verwendetdafur die folgenden funf Relationen:

1. Die Relation BioSequence fasst alle Sequenzen zusammen. Jede in der Datenbankgespeicherte Sequenz erhalt eine Kennung. Die Kennungen der Sequenzen sind imAttribut BIOSEQID vom Typ BIGINT abgelegt.

2. NASequence fasst alle Nukleotidsequenzen zusammen. Die Relation umfasst die At-tribute NASEQID vom Typ BIGINT und SEQTEXT vom Typ LONG VARCHAR. NASEQIDist zugleich Fremdschlussel auf das Attribut BIOSEQID aus der Relation BioSequence.SEQTEXT enthalt die Sequenzen als Zeichenketten. Die Zeichenketten verwenden dasNukleotid-Alphabet [10].

3. Protein umfasst die Aminosauresequenzen. Die Relation besteht aus den Attribu-ten PROTEINID vom Typ BIGINT und SEQTEXT vom Typ LONG VARCHAR. PROTEINIDist zugleich Fremdschlussel auf das Attribut BIOSEQID aus BioSequence. SEQTEXTenthalt die Aminosauresequenzen als Zeichenketten. Die Zeichenketten verwendendas Alphabet der Aminosauren [20].

42

KAPITEL 5. VERWENDETE DATENBANKKONZEPTE

Abbildung 5.1: Ausschnitt des Genom-Datenmodells. Die unterstrichenen Attribute sindPrimarschlussel, die kursiv gesetzten sind Fremdschlussel.

4. In der Relation DNA sind die DNA-Sequenzen abgelegt. Sie werden uber das einzigeAttribut DNASEQID vom Typ BIGINT identifiziert. Dieses ist zugleich Fremdschlusselauf das Attribut NASEQID der Relation NASequence.

5. In RNA werden die RNA-Sequenzen modelliert. Das Schlusselattribut ist RNASEQIDvom Typ BIGINT, das zugleich Fremdschlussel auf das Attribut NASEQID aus NASe-quence ist. Zwei weitere Fremdschlusselattribute bilden die Beziehungen des zentra-len Dogmas (vergleiche Abbildung 2.1) ab: DNASEQID ist ein Fremdschlussel auf dasgleichnamige Attribut der Relation DNA und enthalt fur ein Tupel die Kennung derDNA-Sequenz, aus der die RNA-Sequenz erzeugt wurde. PROTEINID ist ein Fremd-schlussel auf das gleichnamige Protein-Attribut und verweist auf die Aminosaurese-quenz, in die die RNA-Sequenz ubersetzt wurde.

Im Rahmen von BLAST sind die Relationen NASequence und Protein von besonderemInteresse, da sie die Zeichenketten der Sequenzen enthalten.

Das gesamte Datenmodell der verwendeten Datenbank befindet sich in Anhang D. Dortist zu ersehen, welche Verknupfungen zu anderen biologischen Informationen bestehen.

5.2 Anwendungsprogrammierung mit DB2

Anfragen an relationale Datenbanken erfolgen heutzutage uberwiegend mit der Anfrage-sprache SQL (Structured Query Language). Sie ist aus der Sprache SEQUEL [8] entstan-den. SQL ist ein ISO-Standard [17] und wird von vielen Herstellern von Datenbankmanage-mentsystemen (DBMSen) implementiert. Deshalb sind auf SQL basierende Anwendungenrelativ portabel.

Ursprunglich wurde SQL als interaktive Anfragesprache entwickelt. Die Benutzer kom-munizieren dabei direkt mit dem Datenbanksystem, indem sie eine SQL-Anfrage formulie-ren und die Antwort sofort bekommen, wenn die Anfrage vollstandig verarbeitet wurde.

43


Bei dieser Benutzung muss nicht extra ein Programm geschrieben werden, vielmehr gibtes verschiedene Werkzeuge, die interaktiv SQL verarbeiten, wie z.B. der Kommandozeilen-prozessor (Command Line Processor, CLP) von DB2.

Haufig jedoch kommen Datenbanksysteme auch in Bereichen zur Anwendung, in denendie meisten Anwender kein SQL formulieren konnen, sondern auf andere Moglichkeiten derEingabe zuruckgreifen, wie zum Beispiel grafische Formulare und Eingabefelder. Fur dieseZwecke werden von Datenbanksystemen Schnittstellen definiert, um die Programmierungsolcher Anwendungssysteme zu ermoglichen. In den folgenden Unterkapiteln werden zweiSchnittstellen vorgestellt, die DB2 zur Verfugung stellt: Embedded SQL sowie das Call LevelInterface.

5.2.1 Eingebettetes SQL

Die erste Moglichkeit, SQL in Anwendungsprogrammen zu verarbeiten, besteht in der Ein-bettung der SQL-Anweisungen in den Quelltext der Anwendung. Diese Moglichkeit kannin Programmen verwendet werden, die in den ”Wirtssprachen” C, C++, FORTRAN undCOBOL. Programme dieser Art mussen zunachst von einem SQL-Precompiler verarbeitetwerden, der die eingebetteten (embedded) SQL-Anweisungen durch Aufrufe von Laufzeit-routinen ersetzt. Das Ergebnis sind Programme, die von normalen Compilern ubersetztwerden konnen.

Im Fall der Sprache C mussen einer eingebetteten SQL-Anweisung die Worter EXEC SQLvorangestellt werden, damit der Precompiler die Anweisung erkennt. Um Variablen des Pro-gramms innerhalb einer SQL-Anweisung zu benutzen, mussen sie in einem vom Precom-piler erkennbaren Teil des Programms deklariert werden (BEGIN/END DECLARE SECTION).Die Variablen konnen dann in SQL-Anweisungen benutzt werden, indem ihnen ein Dop-pelpunkt vorangestellt wird. Zum Auslesen der Tupel einer SELECT-Anweisung wird einePositionsmarke (engl.: cursor) deklariert, die jedes Tupel mittels einer EXEC SQL FETCH-Anweisung ausliest. Die Attribute des Tupels werden dann in vorher deklarierte Variablengeschrieben, die im Anwendungsprogramm weiter verarbeitet werden konnen. Nach demLesen eines Tupels wird der cursor auf das nachste zu lesende Tupel ”gesetzt”.

Der hier angedeutete Mechanismus erzeugt sogenanntes statisches SQL. Dieses zeich-net sich dadurch aus, dass die SQL-Anweisungen vom Anwendungsentwickler selbst in dasProgramm hineingeschrieben werden. Das hat den Vorteil, dass wahrend der Precompiler-Phase der Anfrage-Optimierer des DBMS einen Zugriffsplan in der Datenbank ablegt, sodass diese Phase der Anfrageoptimierung wahrend der Laufzeit entfallt. Falls das Programmdynamisch SQL-Anweisungen erzeugen soll, so kann das nicht mehr mit den Mitteln von sta-tischem SQL bewerkstelligt werden. Zu diesem Zweck existieren andere EXEC SQL-Befehle.Sie konnen string-Variablen verarbeiten, die die eigentlichen SQL-Befehle enthalten. DieseZeichenketten konnen wahrend der Laufzeit erzeugt werden. Deshalb spricht man hier voneingebettetem dynamischem SQL.

Eingebettetes SQL ist im Detail in [7] beschrieben. Hier soll nicht naher darauf einge-gangen werden, da die BLAST-Anpassung mit dem Call Level Interface realisiert wird.

5.2.2 Das Call Level Interface

Die Verwendung von eingebettetem SQL hat den Nachteil, dass ein Precompiler bemuhtwerden muss, bevor das Programm mit dem eigentlichen Compiler erzeugt werden kann.

44


Das so genannte Call Level Interface (CLI, engl.; etwa: Schnittstelle auf der Ebenevon Funktionsaufrufen) geht einen anderen Weg. Hierbei werden die SQL-Anweisungen alsZeichenkettenvariablen abgelegt. Dies kann wahrend der Laufzeit oder bereits durch denEntwickler passieren. Mittels einer standardisierten Schnittstelle von Funktionsaufrufenkonnen diese SQL-Anweisungen vorbereitet und ausgefuhrt werden. Im Folgenden wer-den die wesentlichen CLI-Funktionen und der schematische Ablauf eines CLI-Programmsvorgestellt.

Ein Vorteil der Benutzung von CLI liegt, wie bereits erwahnt, in der Vermeidung eineszusatzlichen Precompiler-Aufrufs. Durch die Trennung der SQL-Anweisungen (in Funk-tionsaufrufen) von den Anweisungen in der eigentlichen Programmiersprache ist auch dieFehlersuche einfacher. CLI erlaubt es uberdies, portable Datenbankanwendungen zu schrei-ben, da es auf den Standards SQL Call Level Interface (SQL/CLI ) [18] und Open DatabaseConnectivity (ODBC ) basiert. Ein Nachteil von CLI ist, dass es nur in den Sprachen Cund C++ verwendet werden kann.

5.2.2.1 Handles

Im CLI wird das Konzept von Handles (hier: Kennungen) verwendet. Kennungen sindC-Variablen, die dazu dienen, Zustande von Objekten zu reprasentieren. Folgende Typenvon Kennungen werden unterschieden:

1. Eine Umgebungskennung beschreibt den Zustand der Anwendung. Zu Beginn einesProgramms wird eine Umgebungsvariable reserviert und am Ende wieder freigegeben.Ein Programm sollte nur eine einzige Umgebungskennung besitzen.

2. Eine Verbindungskennung reprasentiert die Verbindung des Programms zu einer Da-tenbank. Diese Kennung wird zum Auf- und Abbau der Datenbankverbindung ver-wendet. Vor dem Aufbau der Verbindung sollte die Kennung reserviert und nach demAbbau wieder freigegeben werden. Eine Anwendung kann Verbindungen zu mehrerenDatenbanken unterhalten; fur jede von Ihnen ist eine eigene Kennung notwendig.

3. Anweisungskennungen dienen zur Verwaltung des Status von SQL-Anweisungen. Ineinem Programm konnen mehrere Anweisungskennungen verwendet werden. Mittelseiner solchen Kennung wird eine SQL-Anweisung vorbereitet und ausgefuhrt.

4. Deskriptorkennungen dienen dazu, bestimmte Informationen uber die Ruckgabeattri-bute einer SQL-Anweisung oder die in einer Anweisung verwendeten Parametermar-ker zu erhalten. Diese Informationen sind zum Teil auch uber Anweisungskennungenzuganglich, weshalb Deskriptorvariablen relativ selten verwendet werden.

Die folgenden beiden Funktionen dienen der Reservierung und Freigabe von Kennungsva-riablen:

• SQLAllocHandle() reserviert eine Kennung. Zusatzlich zur Kennung werden nochihr Typ und ihre Kontextkennung ubergeben. Die Kontextkennungen konnen Tabelle5.1 entnommen werden. Die Kontextkennung selbst muss bereits reserviert sein.

• SQLFreeHandle() gibt eine Kennungsvariable wieder frei. Auch hier wird der Typder Kennung ubergeben.

45


Kennung KontextkennungUmgebung —Verbindung UmgebungAnweisung VerbindungDeskriptor Verbindung

Tabelle 5.1: CLI-Kennungen und ihre Kontexte

5.2.2.2 Die Verbindung mit der Datenbank

Nach der Reservierung von Umgebungs- und Verbindungskennung wird die Verbindungmit der Datenbank hergestellt. Dazu dient hauptsachlich die Funktion SQLConnect(), derdie Verbindungskennung, der Name der Datenbank, der Benutzername und das Benutzer-Kennwort ubergeben werden. Werden Benutzername und Kennwort freigelassen, so ver-wendet SQLConnect() die Zugangsdaten desjenigen Benutzers, der das Programm ausfuhrt.Zum Abbau der Verbindung wird die Funktion SQLDisconnect() benutzt, die als Parame-ter die Verbindungskennung erhalt.

5.2.2.3 Ausfuhrung von SQL-Anweisungen

Vor der Ausfuhrung von SQL-Anweisungen mussen Anweisungshandles mit der FunktionSQLAllocHandle() reserviert werden. Im Fall von BLAST genugen SELECT-Anweisungen,deren zuruckgegebene Tupel nacheinander ausgelesen und verarbeitet werden. Fur diesenAnwendungsfall wird die folgende Abfolge von Funktionsaufrufen verwendet:

1. SQLPrepare() bereitet eine SQL-Anweisung vor. Die Anweisung wird als Zeichenket-te an die Funktion ubergeben. Das DBMS erzeugt in der Datenbank einen Zugriffs-plan fur die Anweisung.

2. SQLBindParameter()Bei der Ausfuhrung einer SQL-Anweisung ist es moglich, Variablenwerte des An-wendungsprogramms in der Anweisung zu verwenden. Dies geschieht durch Para-metermarker, die als Fragezeichen in der SQL-Anweisung reprasentiert werden. Mitder Funktion SQLBindParameter() werden diesen Markern Variablen des Programmszugeordnet. Fur jeden Marker ist ein Aufruf erforderlich.

3. SQLExecute() fuhrt die SQL-Anweisung aus. Im Fall von Parametermarkern werdendie Werte aus den Programmvariablen gelesen und in die Anweisung eingefugt.

4. SQLBindCol()Die Ausfuhrung einer SELECT- oder VALUES-Anweisung liefert null oder mehr Ergeb-nistupel. Fur jedes in einer SELECT- oder VALUES-Anweisung angegebene Attributmuss eine Variable festgelegt werden, die die Attributwerte der Ergebnistupel auf-nimmt. Die Zuordnung einer Programmvariablen zu einem Attribut erfolgt mit Hilfeder Funktion SQLBindCol(). Die Funktion erhalt die Anweisungskennung, die At-tributnummer (zu deren Identifikation), den Typ der Programmvariablen und derenLange (bei Zeichenketten). Außerdem kann eine NULL-Indikator-Variable angegeben

46


werden. Sie gibt Auskunft daruber, ob der Attributwert im aktuellen Tupel NULList.

5. SQLFetch() liest das nachste Tupel der Ergebnismenge und schreibt die Werte dereinzelnen Attribute in die Variablen, die mittels SQLBindCol() deklariert wurden.Intern ist dieses Vorgehen als cursor wie bei eingebettetem SQL implementiert.

An dieser Stelle sei darauf hingewiesen, dass die Funktionsfolge

SQLPrepare()↓

SQLBindParameter()↓

SQLExecute()

durch die Folge

SQLBindParameter()↓

SQLExecDirect()

ersetzt werden kann. Die Zeichenkette mit der SQL-Anweisung wird in diesem Fall anSQLExecDirect() ubergeben. Die erste Funktionsfolge ist dann zu bevorzugen, wenn dieAnweisung mit unterschiedlichen Variablenwerten mehrmals ausgefuhrt werden soll. DerZugriffsplan wird in diesem Fall genau einmal mit SQLPrepare() erzeugt, die FunktionenSQLBindParameter() und SQLExecute() konnen danach beliebig oft aufgerufen werden.Wird die Anweisung nur einmal ausgefuhrt, sind die beiden Funktionsfolgen gleichberech-tigt.

Zur Ausfuhrung und zur Analyse von SQL-Anweisungen existieren noch weitere CLI-Funktionen [7, 15], etwa zum Zurucksetzen eines cursors oder zum Transaktionsmana-gement. Die hier vorgestellten Funktionen genugen jedoch, die im Rahmen von BLASTnotwendigen Anpassungen durchzufuhren.

5.2.2.4 CLI-Ruckgabewerte

Fast alle CLI-Funktionen geben einen Wert zuruck, der Auskunft uber den Erfolg derFunktionsausfuhrung gibt. Die folgende Aufzahlung beschreibt nur die wichtigsten SQL-Ruckgabewerte:

• SQL_SUCCESS zeigt an, dass die Funktion erfolgreich war.

• SQL_SUCCESS_WITH_INFO zeigt ebenfalls den Erfolg der Funktion an. Die Funktionliefert aber gleichzeitig eine Warnung oder eine andere Information. Durch den Aufrufder Funktion SQLGetDiagRec() kann diese Information ausgewertet werden.

• SQL_INVALID_HANDLE deutet auf eine nicht initialisierte Kennung hin.

• SQL_ERROR bedeutet, dass die Funktion nicht erfolgreich ausgefuhrt wurde. MittelsSQLGetDiagRec() kann der Grund fur den Fehler in Erfahrung gebracht werden.

47


• SQL_NO_DATA_FOUND ist ein Ruckgabewert von SQLFetch(). Er gibt an, dass dercursor hinter dem letzten Tupel der Ergebnismenge positioniert ist. Folglich sindkeine weiteren SQLFetch()-Aufrufe zur Verarbeitung der Ergebnisse notwendig.

Das Auslesen der Ergebnismenge einer SELECT- oder VALUES-Anweisung kann in Cso implementiert werden, dass eine Schleife so lange SQLFetch() aufruft und dieErgebnisse verarbeitet, bis die Funktion den Wert SQL_NO_DATA_FOUND zuruckliefert.

5.3 Benutzerdefinierte Funktionen

In SQL-Anweisungen werden haufig Funktionen verwendet. Die Anweisung

SELECT count(attribut2) FROM tabelle1

ruft beispielsweise die Funktion count auf, die die Anzahl der Tupel der tabelle1 -Relationzuruckgibt. DB2 unterscheidet vier Typen von Funktionen [16]:

1. Skalare FunktionenSkalare Funktionen bilden eine Argumentliste skalarer Werte auf einen skalaren Ruck-gabewert (auch NULL) ab. Eine solche Funktion kann uberall dort verwendet wer-den, wo ein Ausdruck stehen kann, etwa in der SELECT- oder WHERE-Klausel einerSQL-Anweisung. Ein Beispiel fur eine skalare Funktion ist LN, die den naturlichenLogarithmus des ubergebenen Arguments berechnet.

2. SpaltenfunktionenDas Argument einer Spaltenfunktion ist eine Menge gleicher skalarer Werte. Betrach-tet man eine Relation als Tabelle, so nimmt eine Spaltenfunktion eine Spalte als Gan-zes entgegen und berechnet daraus einen skalaren Wert. Spaltenfunktionen konnenuberall dort verwendet werden, wo ein Ausdruck stehen kann. Ein Beispiel fur eineSpaltenfunktion ist MAX, die den großten Wert der ubergebenen Spalte zuruckgibt.

3. ZeilenfunktionenEine Zeilenfunktion nimmt einen strukturierten Typ als Argument entgegen und lie-fert ein Tupel von vordefinierten Typen zuruck. Zeilenfunktionen dienen lediglich alsTransformationsfunktionen fur strukturierte Typen.

4. TabellenfunktionenTabellenfunktionen bilden eine Liste skalarer Werte auf eine Tabelle ab. Diese Funk-tionen liefern also eine Menge von Tupeln vordefinierter Struktur. Sie konnen nurin der FROM-Klausel einer SQL-Anweisung stehen. Die einzige vordefinierte Tabellen-funktion von DB2 ist SQLCACHE_SNAPSHOT.

Neben der Verwendung bereits vordefinierter Funktionen ist es Benutzern von DB2 mog-lich, selbst Funktionen zu erstellen. Diese werden als benutzerdefinierte Funktionen (engl.:user-defined functions, UDF ) bezeichnet. UDFs [14] konnen wie folgt klassifiziert werden:

1. Quellenbasierte FunktionenDB2 implementiert das Konzept einzigartiger Typen. Diese zeichnen sich dadurchaus, dass sie von einem vordefinierten Typ mittels einer 1:1-Abbildung abgeleitet

48


werden und einen eigenen Namen erhalten. Der Name dient dazu, die Semantikdes Datentyps hervorzuheben. Als Beispiel kann ein Typ WINKEL zur Darstellunggeometrischer Winkel definiert werden, der von DOUBLE abgeleitet ist.

Um Funktionen, die auf Argumenten vom Typ DOUBLE definiert sind, im Kontextvon WINKEL zu verwenden, mussen sie als quellenbasierte Funktionen vom jeweiligenOriginal abgeleitet werden. Beispielsweise kann eine Funktion SIN definiert werden,die Werte vom Typ WINKEL als Argumente entgegennimmt und die gleiche Semantikhat wie die SIN-Funktion fur DOUBLE-Werte.

2. Externe skalare FunktionenEine externe skalare Funktion ist eine skalare Funktion, die von einem Benutzer ineiner Programmiersprache geschrieben wurde. Externe skalare Funktionen konnen inC, C++ oder Java implementiert werden. Der Programmcode wird dem Datenbank-system in einer kompilierten Funktionsbibliothek zur Verfugung gestellt. Externeskalare Funktionen durfen kein SQL enthalten und konnen deshalb nicht auf die Da-tenbank zugreifen.

3. Externe TabellenfunktionenEine externe Tabellenfunktion ist eine Tabellenfunktion, die von einem Benutzer ineiner der Programmiersprachen C, C++ oder Java implementiert ist. Auch hier ist esnicht erlaubt, SQL in der Funktion zu verwenden. Da eine Tabellenfunktion mehrereTupel als Ergebnis liefern kann, wird sie intern mehrmals aufgerufen.

Benutzerdefinierte Funktionen werden genauso verwendet wie die vordefinierten. Es geltendie gleichen Einschrankungen. Fur die Anpassung von BLAST ist die Verwendung einerexternen Tabellenfunktion von besonderem Interesse. Deswegen wird auf deren Aufbaunaher eingegangen.

5.3.1 Deklaration einer externen Tabellenfunktion

Ausgangspunkt fur die Behandlung von Tabellenfunktionen ist deren Deklaration. Diesgeschieht mit der SQL-Anweisung CREATE FUNCTION. Sie hat den folgenden Aufbau:

CREATE FUNCTION <Funktionsname> (<Parameterliste>)

RETURNS TABLE (<Liste der Ergebnisattribute>)

EXTERNAL NAME <Dateiname>!<externer Funktionsname>

LANGUAGE <Implementationssprache>

FENCED | NOT FENCED

EXTERNAL ACTION | NO EXTERNAL ACTION

FINAL CALL | NO FINAL CALL

SCRATCHPAD | NO SCRATCHPAD

RETURNS NULL ON NULL INPUT | CALL ON NULL INPUT

NO SQL

DISALLOW PARALLEL

<weitere Optionen>

Die Anweisungsoptionen haben folgende Bedeutung:

• Die Funktion wird in SQL-Anweisungen mit dem <Funktionsname>n aufgerufen.

49


• <Parameterliste> enthalt die Typen der Funktionsparameter. Die Parameter kon-nen optional einen Namen erhalten.

• Die komma-separierte <Liste der Ergebnisattribute> enthalt Eintrage der Form<Attributname> <Datentyp>.Der Attributname kann in der SELECT-Klausel verwendet werden.

• <Dateiname> ist der Name der Funktionsbibliotheksdatei, die den Code der UDFenthalt. Bei der Ausfuhrung der CREATE FUNCTION-Anweisung muss die Datei nichtvorhanden sein. Die Funktion in der Bibliothek wird erst bei der Ausfuhrung derUDF in einer SELECT- oder VALUES-Anweisung aufgerufen.

• <externer Funktionsname> ist der Name der UDF in der Funktionsbibliothek.

• Die <Implementationssprache> ist C, JAVA oder OLE. OLE bedeutet, dass diebenutzerdefinierte Funktion eine Methode eines OLE Automationsobjekts ist. DieseMoglichkeit kann nur in den 32-Bit-Versionen des Betriebssystems Windows verwen-det werden.

• Bei der Option FENCED wird die Funktion in einem eigenen Prozess ausgefuhrt. DasGegenstuck ist NOT FENCED, bei dem die aufgerufene Funktion im gleichen Prozesswie das DBMS lauft.

FENCED hat den Vorteil, dass bei schweren Fehlern (Speicherschutz- oder Zugriffs-fehlern) die Funktion abnormal beendet wird, ohne das DBMS zu beeintrachtigen.Ein derartiger Fehler in einer NOT FENCED-Funktion fuhrt im schlimmsten Fall zurBeendigung des DBMS-Prozesses. Dadurch wurden alle Verbindungen zu den vomDBMS verwalteten Datenbanken beendet. Der Vorteil von NOT FENCED liegt in derschnelleren Ausfuhrung einer Funktion gegenuber ihrem FENCED-Pendant.

• EXTERNAL ACTION wird angegeben, wenn die Funktion externe Ressourcen verwendet,wie z.B. das Dateisystem oder Geratetreiber.

• Der Aufruf einer Tabellenfunktion stellt sich fur den Benutzer von SQL so dar, dassfur jede Kombination von Aufrufargumenten die UDF einmal aufgerufen wird. In-tern wird die Funktion fur das Liefern jedes Ergebnistupels separat aufgerufen. Istdie Option FINAL CALL gesetzt, unterscheidet die UDF funf Aufruftypen, im FallNO FINAL CALL drei. Die Aufruftypen werden im nachsten Abschnitt detaillierterlautert.

• Da eine UDF mehrmals aufgerufen wird, kann es notig sein, bestimmte Variablenwerteund Datenstrukturen zwischen den verschiedenen Aufrufen zu erhalten. Zu diesemZweck wird das scratchpad -Konzept (engl.; Notizzettel) verwendet. Im scratchpadkonnen Referenzen (Zeiger) auf Speicherbereiche gespeichert werden, die zwischen denverschiedenen Aufrufen einer UDF konstant bleiben sollen. Die Option SCRATCHPADstellt einen solchen Bereich zur Verfugung.

• Oftmals ist es sinnvoll, eine UDF nicht aufzurufen, wenn ihr NULL-Werte ubergebenwerden. Dieses Verhalten kann mit der Option RETURNS NULL ON NULL INPUT ein-gestellt werden. In diesem Fall wird vom DBMS auch NULL zuruckgegeben. Dabei

50


genugt es, wenn nur eines der ubergebenen Argumente NULL ist. Soll die Funktionin jedem Fall aufgerufen werden, so ist die Option CALL ON NULL INPUT anzugeben.

• Die Optionen NO SQL und DISALLOW PARALLEL sind in jedem Fall anzugeben. NO SQLbedeutet, dass die Funktion nicht mittels eingebettetem SQL oder CLI auf die Da-tenbank zugreifen darf. DISALLOW PARALLEL bedeutet, dass der Aufruf der Funktionnicht parallelisiert werden kann.

5.3.2 Aufbau einer externen Tabellenfunktion

Tabellenfunktionen konnen in JAVA oder C implementiert werden. In diesem Abschnittsoll der Aufbau einer C-Tabellenfunktion beschrieben werden. Schematisch sieht der Kopfeiner solchen Funktion wie folgt aus:

void SQL_API_FN <Funktionsname>(

<Eingabeparameter>, /* IN */

<Rueckgabevariablen>, /* OUT */

<NULL-Indikatoren der Eingabeparameter>, /* IN */

<NULL-Indikatoren der Rueckgabewerte>, /* OUT */

SQLSTATE, /* OUT */

SQL-Funktionsname, /* IN */

spezifischer Name, /* IN */

Fehlermeldungsvariable, /* OUT */

Notizzettel-Variable, /* IN */

Aufruftyp, /* IN */

DBInfo-Struktur /* IN */

)

Die Eingabeparametervariablen entsprechen der ”Parameterliste” aus der Funktionsdekla-ration. Die Ruckgabevariablen entsprechen der ”Liste der Ergebnisattribute”. Jedem Ein-gabeparameter wird zusatzlich ein NULL-Indikator zur Seite gestellt. Die Ruckgabevaria-blen besitzen ebenfalls NULL-Indikatoren, die von der Funktion gesetzt werden konnen.

Die SQLSTATE-Variable wird von der Funktion gesetzt und zeigt den Ruckgabestatus derFunktion an. Die Variable ist eine Zeichenkette der Lange 5, die eine Zahl reprasentiert.Folgende Werte konnen dabei zuruckgegeben werden:

• ”00000” zeigt den Erfolg der Funktion an.

• Werte im Bereich ”38600” bis ”38999” deuten auf Fehler bei der Ausfuhrung hin. DieFunktion kann dann in der Zeichenkette Fehlermeldungsvariable eine Fehlermel-dung eintragen, die von der SQL-Benutzerschnittstelle ausgegeben wird.

• Der Wert ”02000” kann nur bei einem Aufruf vom Typ FETCH zuruckgegeben werdenund zeigt an, dass keine Ergebnistupel mehr folgen.

Andere Werte sollten nicht verwendet werden, da sie dem DBMS vorbehalten sind.Die anderen Parameter haben die folgende Bedeutung:

1. SQL-Funktionsname ist der Name der UDF in SQL.

2. spezifischer Name ist ein Name, den DB2 bei der Funktionsdeklaration vergibt.

51


3. Die Notizzettel-Variable ist ein Speicherbereich, dessen Inhalt zwischen den Auf-rufen der Funktion bestehen bleibt.

4. Die DBInfo-Struktur enthalt einige weiterfuhrende Informationen des Funktionsauf-rufs, wie z.B. die aktuelle Datenbank oder die Benutzerkennung.

Die Notizzettel- und die DBInfo-Struktur sind nur vorhanden, falls die entsprechendenOptionen bei der Deklaration gesetzt wurden.

Eine UDF wird innerhalb einer SQL-Anweisung mehrfach intern aufgerufen. Dabeiwerden die folgenden Aufruftypen unterschieden:

1. FIRSTDer FIRST call (erster Aufruf) der Funktion wird durchgefuhrt, falls die OptionFINAL CALL bei der Deklaration der Funktion gesetzt wurde. Die Funktion wirdnur einmal pro SQL-Anweisung mit dem Typ FIRST aufgerufen. Der Aufruf dientdazu, Ressourcen und ahnliches zu initialisieren, die fur alle weiteren Aufrufe benotigtwerden. Der FIRST-Aufruf sollte kein Ergebnistupel zuruckgeben. Ist die Notizzettel-Variable vorhanden, wird deren Inhalt vor dem Aufruf mit Nullen initialisiert. Im Falleines Fehlers im FIRST-Aufruf werden keine weiteren Aufrufe der Funktion getatigt.

2. OPENDer OPEN-Aufruf wird fur jede Parameterkombination der UDF einmal aufgerufen.Er dient dazu, Initialisierungen und Berechnungen fur diese Parameterkombinationdurchzufuhren. Auch bei OPEN sollte kein Ergebnistupel zuruckgegeben werden. Istein Notizzettel vorhanden und wurde FINAL CALL nicht deklariert, initialisiert derOPEN-Aufruf den Notizzettel-Speicherbereich. Falls der OPEN-Aufruf einen Fehlermeldet, wird danach nur der FINAL-Aufruf der Funktion ausgefuhrt.

3. FETCHDer FETCH-Aufruf dient der Ruckgabe eines Ergebnistupels. Es gibt zwei Moglich-keiten zur Ausfuhrung der Funktion:

(a) Falls intern Ergebnistupel vorliegen, mussen die entsprechenden Ruckgabevaria-blen gesetzt werden. Die Funktion muss dann die Variable SQLSTATE auf denWert ”00000” setzen.

(b) Falls keine Ergebnistupel mehr zuruckgegeben werden konnen, muss die Varia-ble SQLSTATE auf den Wert ”02000” gesetzt werden. Damit wird dem DBMSangezeigt, dass keine weiteren Ergebnistupel folgen.

Im Falle eines Fehlers bei FETCH werden nur noch CLOSE und FINAL aufgerufenund keine weiteren FETCH’es.

4. CLOSEJedem OPEN-Aufruf entspricht ein CLOSE-Aufruf, der Initialisierungen wieder frei-gibt, die im OPEN-Aufruf vorgenommen wurden. Der CLOSE-Aufruf folgt demjeni-gen FETCH-Aufruf, der den Wert ”02000” in SQLSTATE zuruckgegeben hat, odereinem fehlerhaften FETCH-Aufruf.

52


5. FINALJedem FIRST-Aufruf entspricht ein FINAL-Aufruf. Hier werden Initialisierungenwieder zuruckgesetzt, die fur alle Funktionsaufrufe benotigt wurden. Ein FINAL-Aufruf erfolgt nur, falls FINAL CALL bei der SQL-Deklaration der Funktion gesetztwurde.

53

Kapitel 6

Anpassung von BLAST

Dieses Kapitel fuhrt die Erkenntnisse der letzten beiden Kapitel zusammen. In den folgen-den Abschnitten wird das Programm blastall in der Form modifiziert, dass es im Kontexteiner relationalen Datenbank eingesetzt werden kann. Zu diesem Zweck werden zwei ver-schiedene Wege beschritten.

Die erste Anpassungsvariante von BLAST basiert auf der Programmierschnittstelle CallLevel Interface von DB2. Bei dieser Modifikation geht es vor allem darum, Zugriffe aufblastall -Datensammlungsdateien durch entsprechende SQL-Anweisungen zu ersetzen.

Die zweite Anpassung besteht in der Implementation von blastall als benutzerdefinierteFunktion. Das Augenmerk bei dieser Umwandlung liegt darauf, den Ablauf des Programmsgeeignet auf den einer UDF abzubilden.

6.1 Implementation der Datenbankschnittstelle von BLAST

Bei der Anpassung von blastall mit Hilfe des CLI besteht die Hauptaufgabe in der Mo-difikation der Datenbankschnittstelle. Dabei werden die Datensammlungsdateien, die dieVergleichssequenzen enthalten, durch die Anbindung an eine relationale Datenbank ersetzt(Abbildung 6.1). Die Anfragesequenz und der BLAST-Reports werden auch nach der An-passung in Dateien abgelegt.

Das modifizierte Programm wird mit db2blast bezeichnet, um es von blastall abzuheben.

6.1.1 Initialisierung der Datenbankschnittstelle

Vor der Nutzung der Datenbankschnittstelle steht deren Initialisierung. Fur die grund-legenden Initialisierungen wird die Funktion db2init() implementiert, die die folgendenSchritte ausfuhrt:

1. Allokation der Umgebungskennung mittels SQLAllocHandle()

2. Allokation der Datenbank-Verbindungskennung mittels SQLAllocHandle()

3. Aufbau der Datenbank-Verbindung mittels SQLConnect()

4. Allokation der Anweisungskennungen fur die verwendeten SQL-Anweisungen mittelsSQLAllocHandle()

54

KAPITEL 6. ANPASSUNG VON BLAST

Abbildung 6.1: Integration von BLAST in eine relationale Datenbank. Es ist zu beachten,dass das Format der Anfragesequenz- und der Reportdatei unverandert bleibt.

Die Kennungen sind globale Variablen, da sie in anderen Funktionen verwendet werdenmussen.

db2init() wird ein Zeichenketten-Parameter ubergeben, der den Datenbanknamenenthalt. Legt man den schematischen Ablauf der Main()-Funktion zugrunde (siehe Ab-schnitt 4.4.1), so wird db2init() vor dem Einlesen der Anfragesequenz-Datei ausgefuhrt.

Das Gegenstuck von db2init() ist db2destruct(). Diese Funktion gibt die Allokatio-nen wieder frei und baut die Datenbankverbindung ab:

1. Freigabe des Sequenz-SpeicherbereichDieser Speicherbereich wird nicht von db2init() ermittelt, sondern erst in einerdanach aufgerufenen Funktion reserviert.

2. Freigabe der Anweisungskennungen mittels SQLFreeHandle()

3. Abbau der Datenbank-Verbindung mittels SQLDisconnect()

4. Freigabe der Datenbank-Verbindungskennung mittels SQLFreeHandle()

5. Freigabe der Umgebungskennung mittels SQLFreeHandle()

db2destruct() wird am Ende der Main()-Funktion ausgefuhrt.Im weiteren Verlauf werden die von BLAST benotigten SQL-Anweisungen vorbereitet

und teilweise ausgefuhrt. Zu diesem Zweck werden zwei weitere Funktionen implementiert:

• db2prepareStatements() bereitet die SQL-Anweisungen vor (SQLPrepare()). Dieverwendeten SQL-Anweisungen sind abhangig von der BLAST-Variante, da die ent-sprechenden Sequenzen entweder in der NASequence- (blastn, tblastn, tblastx) oderder Protein-Relation (blastp, blastx) zu finden sind.

55


• db2executeAndBindConstStatements() fuhrt die Anweisungen aus (SQLExecute()),die keine Parametermarker enthalten und nicht mehrfach ausgefuhrt werden. DiesenAnweisungen werden auch die Ergebnisvariablen zugewiesen (SQLBindCol()). DieSQLBindCol()-Variablen sind global, weil ihre Werte in BLAST-Funktionen verwen-det werden.

Einige der SQL-Anweisungen geben nur ein Ergebnistupel zuruck. Dieses wird andieser Stelle gleich in die Programmvariablen geschrieben (SQLFetch()).

Uber die tatsachlich benotigten SQL-Anweisungen geben die folgenden Abschnitte Aus-kunft.

Folgt man dem Schema der Main()-Funktion, so werden die beiden eben beschriebenenFunktionen vor dem Lesen der Anfragesequenz ausgefuhrt. Ihnen geht der Aufruf derFunktion BlastGetTypes() voraus. Sie bestimmt anhand der BLAST-Programmvariante,von welchem Typ Anfragesequenz und Vergleichssequenzen sind.

6.1.2 Initialisierung des Moduls readdb

Die Funktion readdb_new_internal() ist die zentrale Initialisierungsfunktion des Modulsreaddb. Sie fuhrt schematisch die folgenden Schritte aus:

1. Suche nach dem Pfad der Index-Datei der BLAST-Datensammlung

2. Erzeugen der ReadDBFILE-Datenstruktur

3. Offnen der FormatDB -Dateien

4. Lesen der Kennwerte aus der Index-Datei und Speicherung in ReadDBFILE

5. Reservierung des Speicherbereichs fur die zu lesenden Sequenzen

6. Setzen von Zeigern auf die Hauptspeicherdateien (MMF)

7. Suche nach speziellen Index-Dateien (deren Erzeugung bei FormatDB mit angegebenwerden kann)

Die Schritte 1, 3, 6 und 7 werden in der Anpassung nicht verwendet, da die entsprechen-den Dateien nicht vorhanden sind. Die Vergleichssequenzen kommen stattdessen aus derrelationalen Datenbank.

Die Kennwerte aus Schritt 4 werden im Folgenden aufgezahlt. In Klammern stehen dieElemente von ReadDBFILE, die die Werte speichern:

• Versionsnummer von FormatDB (formatdb_ver)

• Titel der Datensammlung (title; kann bei FormatDB mit angegeben werden)

• Erstellungszeitpunkt der Datensammlungsdateien durch FormatDB (date)

• Lange der langsten Vergleichssequenz (maxlen)

• Anzahl der Vergleichssequenzen (num_seqs)

56


• Summe uber die Langen aller Vergleichssequenzen (totlen)

Um db2blast mit blastall zu vergleichen, mussen beim angepassten Programm entsprechen-de Kennwerte in ReadDBFILE abgelegt werden. Die Elemente dieser Struktur werden imRahmen von db2blast wie folgt belegt:

• formatdb_ver erhalt den Wert 3, da das die Versionsnummer des verwendeten For-matDB -Dateiformats ist.

• title wird auf den Wert ”PROTEIN” gesetzt, wenn die Protein-Relation verwendetwird (Proteinsuche), und auf ”DNA”, wenn die NASequence-Relation verwendet wird.

• date wird im db2blast-Kontext das Erstellungsdatum der jeweiligen Tabelle uberge-ben. Fur den Fall einer Proteinsuche wird dazu folgende SQL-Anweisung ausgefuhrt:

SELECT create_time FROM syscat.tables WHERE tabname=’PROTEIN’

Nach der Ausfuhrung der Anweisung wird das Ergebnis in die Variable db2date vomCLI-Typ TIMESTAMP_STRUCT gespeichert. Erst in readdb_new_internal() gelangtder Wert in das date-Element.

• Die Elemente maxlen, num_seqs und totlen werden gemeinsam ermittelt. Dazu wirdfolgende SQL-Anweisung ausgefuhrt:

SELECT MAX(LENGTH(seqtext)), COUNT(*), SUM(LENGTH(seqtext))FROM sequences.protein

Die drei Attribute werden beim Holen des Tupels in die globalen Variablen db2maxlen,db2count und db2totlen gespeichert und gelangen erst in readdb_new_internal()in die entsprechenden ReadDBFILE-Elemente.

db2blast fuhrt zusatzlich die folgenden neuen ReadDBFILE-Elemente ein, die ebenfalls inreaddb_new_internal() initialisiert werden:

• currSeq enthalt die unkodierte, aktuell bearbeitete Sequenz.

• currSeqNum speichert die Kennung der aktuellen Sequenz.

• In seqLength ist die Lange der aktuellen Sequenz abgelegt.

• isAmb hat den Wert TRUE, falls die aktuell bearbeitete Sequenz Mehrdeutigkeitsre-siduen beinhaltet.

• Die Mehrdeutigkeitskodierung der aktuellen Sequenz ist in ambchars gespeichert.

Die Bedeutung dieser Elemente wird in den folgenden Abschnitten deutlich, wenn es umdie Modifizierung von bestehenden BLAST-Funktionen geht.

Das Gegenstuck von readdb_new_internal() ist die Funktion readdb_destruct().Sie ruft ReadDBCloseMHdrAndSeqFiles() auf, was im Fall von db2blast unterbunden wer-den muss. Außerdem wird readdb_destruct_element() fur jedes ReadDBFILE-Listenele-ment aufgerufen. Diese Funktion hat folgenden Aufbau:

57


1. Freigabe der Speicherbereiche der ReadDBFILE-Zeichenketten-Elemente

2. Freigabe der Speicherbereiche fur die verschiedenen Indizes auf die MMFs

3. Schließen der MMFs, falls diese noch offen sind

Der erste Schritt wird in db2blast dahingehend erweitert, dass auch die neu hinzugekomme-nen ReadDBFILE-Elemente freigegeben werden. Die anderen beiden Schritte werden nichtausgefuhrt, da die entsprechenden FormatDB -Dateien nicht existieren.

Die neuen Elemente von ReadDBFILE haben auch Auswirkung auf die ”Initialisierungs-funktion” readdb_attach() (im Kontext von C++ wurde man von copy constructor spre-chen). Bei der Duplikation der ReadDBFILE-Struktur mussen die neu eingefuhrten Elementeebenfalls initialisiert werden.

6.1.3 Der Zugriff auf die Datenbankschnittstelle durch BLAST

Nach der Initialisierung wird die Datenbankschnittstelle im gesamten Ablauf von blastallverwendet. Folgende readdb-Funktionen wurden bei der Analyse (Abschnitt 4.3.3) als kri-tisch bewertet:

• readdb_new_internal()

• readdb_attach()

• readdb_destruct()

• readdb_destruct_element()

• readdb_get_link()

• readdb_get_defline_ex()

• readdb_get_sequence()

• readdb_ambchar_present()

• readdb_get_ambchar()

• readdb_get_sequence_length()

Von diesen Funktionen wurden die ersten vier bereits im letzten Abschnitt modifiziert. Dierestlichen Funktionen haben die Eigenschaft gemeinsam, dass sie auf genau einer Vergleichs-sequenz operieren. Zur Identifikation der Sequenz wird deren Ordnungszahl ubergeben.

readdb_get_link() ist im Vergleich relativ einfach anzupassen: Im Fall von db2blastgibt es nur eine einzige ReadDBFILE-Struktur. Folglich wird ein Zeiger auf diese zuruckge-geben.

Die anderen funf Funktionen werden im Folgenden als die Menge der kritischen Funk-tionen bezeichnet. Im Fall von readdb_get_defline_ex() besteht das Problem darin,dass keine Kennungen wie in blastall ’s FASTA-Dateien zur Verfugung stehen. Die anderenvier Funktionen mussen ihre Informationen aus dem Attribut SEQTEXT der entsprechendenDatenbank-Sequenz generieren. Die Anpassung der kritischen Funktion hangt davon ab,wie der Ordnungszahl-Parameter im db2blast-Kontext interpretiert wird:

58


1. Wird den Funktionen die tatsachliche ID aus der Relation ubergeben, konnten dieFunktionen das in die SQL-Anweisung

SELECT seqtext FROM sequences.protein WHERE proteinid=?

ubersetzen (am Beispiel der Proteinsuche). Die IDs mussten dazu vorher bekanntsein. Bei der initialen BLAST-Suche, wie sie in den Funktionen ..._blast_search()durchgefuhrt wird, ist dies nicht der Fall.

2. Wird die tatsachliche Ordnungszahl der Sequenz ubergeben (etwa in einer Schleifeuber alle Sequenzen), musste das in eine SQL-Anweisung der Art ”Ermittle Infor-mationen zur i-ten Sequenz” transformiert werden. Im Rahmen einer relationalenDatenbank sind solche Ordnungszahlen allerdings nicht gegeben. Auch die entspre-chenden ID-Attribute (NASeqID und ProteinID) bilden keine zusammenhangendeZahlenreihe, weshalb sie nicht zu Ordnungszahlen uminterpretiert werden konnen.

Bei den kritischen Funktionen muss also der Zusammenhang untersucht werden, indemsie aufgerufen werden. Zur Losung dieses Problems wird der Begriff des Aufrufkontextseingefuhrt. Dabei werden die Aufrufe dieser speziellen readdb-Funktionen zueinander inBeziehung gesetzt. Eine kritische Funktion kann in drei Aufrufkontexten stehen:

1. ”nachste Sequenz”-KontextIn einer Schleife uber alle Vergleichssequenzen wird die Funktion als erste der kriti-schen Funktionen aufgerufen. Sie muss also die neue oder nachste Sequenz holen unddiese auswerten. Da die Schleife uber alle Vergleichssequenzen iteriert, kann in derFunktion das nachste Tupel der SQL-Anweisung (Beispiel Proteinsuche)

SELECT proteinid,seqtext FROM sequences.protein

geholt werden (SQLFetch()). Die Sequenz wird ausgewertet. Sie und die ID wer-den zwischengespeichert.

Bei der Implementation dieses Kontexts ist es wichtig, dass die betroffene Schleifenach dem Aufruf der kritischen Funktion die ID uberall dort verwendet, wo vorherdie Ordnungszahl (die Schleifenvariable) benutzt wurde. Die ID von db2blast ersetztdie Ordnungszahl von blastall. Dies ist fur die anderen Kontexte von Bedeutung.

2. wahlfreier KontextDie Funktion wird nach der uber alle Sequenzen laufenden Schleife aufgerufen. Dadie Schleife den Ordnungszahlen-Bezug durch einen ID-Bezug ersetzt hat, ist sicher-gestellt, dass die ubergebene Zahl eine ID der Datenbank-Relation ist. Deshalb kanndiese Funktion die SQL-Anweisung


ausfuhren und aus der Sequenz die notigen Informationen generieren. Die Sequenzwird zwischengespeichert.

59


3. ”aktuelle Sequenz”-KontextDie Funktion wird in einem Kontext aufgerufen, in dem bereits eine andere kritischeFunktion auf die gleiche Sequenz zugegriffen hat. Dabei ist es unerheblich, ob dieandere Funktion im wahlfreien oder im ”nachste Sequenz”-Kontext steht. Die andereFunktion hat bereits die Sequenz aus der Datenbank geholt. Somit kann die aktuelleFunktion auf die zwischengespeicherte Sequenz zuruckgreifen.

Die Analyse von blastall (Abschnitt 4.4) wird nun zur Bestimmung der Aufrufkontexte derkritischen Funktionen herangezogen:

• readdb_get_sequence()-Aufrufe:

1. BLASTPerformSearchWithReaddb() steht am Anfang der for-Schleife der Funk-tion ..._blast_search(). → ”nachste Sequenz”-Kontext

2. readdb_get_bioseq_ex() wird von BlastReevaluateWithAmbiguities() auf-gerufen, das in der for-Schleife steht. → ”aktuelle Sequenz”-Kontext

3. readdb_get_sequence_ex() wird von BioseqBlastEngineCore() aufgerufen.Die Schleife uber alle Sequenzen ist an dieser Stelle bereits beendet. → wahlfreierKontext

4. BlastGetGapAlgnTbckWithReaddb() wird von BioseqBlastEngineCore() nachBeendigung der Schleife aufgerufen. → wahlfreier Kontext

• readdb_ambchar_present() wird von BlastReevaluateWithAmbiguities() aufge-rufen, das bereits dem ”aktuelle Sequenz”-Kontext zugeordnet wurde.

• readdb_get_ambchar()-Aufrufe:

1. readdb_get_bioseq_ex() wurde bereits dem ”aktuelle Sequenz”-Kontext zuge-ordnet.

2. readdb_get_sequence_ex() ruft zuerst readdb_get_sequence() fur dieselbeSequenz auf. Damit steht der Aufruf im ”aktuelle Sequenz”-Kontext.

• readdb_get_sequence_length()-Aufrufe:

1. GetSeqAlignForResultHitList() wird von BioseqBlastEngineCore() nachBeendigung der Schleife aufgerufen. Der Aufruf steht im wahlfreien Kontext.

2. FillInStdSegInfo() wird von GetSeqAlignForResultHitList() aufgerufen.Deshalb steht auch dieser Aufruf im wahlfreien Kontext.

• Fur den Aufruf von readdb_get_defline_ex() ist nur relevant, ob die ubergebe-ne Zahl eine gultige ID der Datenbankrelation ist. Im wahlfreien und im ”aktuelleSequenz”-Kontext ist die Bedingung erfullt. Keiner der readdb_get_defline_ex()-Aufrufe steht im ”nachste Sequenz”-Kontext, weil nur die ..._blast_search()-Funktionen Schleifen uber alle Sequenzen enthalten. Dort steht allerdings schon derreaddb_get_sequence()-Aufruf im ”nachste Sequenz”-Kontext. Keine zweite Funk-tion kann zusatzlich in diesem Kontext stehen.

Nach der Identifikation der Funktionskontexte beschreiben die folgenden Unterabschnittedie Implementation der kritischen Funktionen.

60


6.1.3.1 Die Modifikation von readdb get sequence()

readdb_get_sequence()-Aufrufe stehen in allen drei Kontexten. Deshalb muss die Imple-mentation zweigeteilt werden:

• Fur den ”nachste Sequenz”-Kontext wird die Funktion db2_get_sequence() neueingefuhrt.

• readdb_get_sequence() wird fur die Verwendung im wahlfreien und im ”aktuelleSequenz”-Kontext angepasst.

Die Funktion db2_get_sequence() holt bei jedem Aufruf das nachste Tupel der SQL-Anweisung (Beispiel Proteinsuche)

SELECT proteinid,seqtext FROM sequences.protein .

Die Attributwerte werden in die globalen Variablen db2rawseq (Sequenz) und db2seqNum(ID) geschrieben.

Die Sequenzen in der Datenbank sind Worter auf dem Nukleotid- bzw. dem Aminosaure-Alphabet. Da die blastall -Sequenzen kodiert vorliegen, mussen auch die relationalen Da-tenbanksequenzen kodiert werden. Dafur ist db2convertSeqToNCBIFormat() verantwort-lich. Die Funktion wird von db2blast neu eingefuhrt. Sie pruft unter anderem auch, ob eineubergebene Nukleotidsequenz Mehrdeutigkeitsresiduen enthalt. Die folgenden ReadDBFILE-Element werden beschrieben:

• buffer speichert die kodierte Sequenz.

• currSeq speichert die unkodierte Sequenz.

• In seqLength wird die Lange der Sequenz abgelegt.

• Falls die Sequenz eine Nukleotidsequenz ist und Mehrdeutigkeiten enthalt, wird dasElement isAmb auf TRUE gesetzt. Im anderen Fall erhalt es den Wert FALSE.

db2_get_sequence() wird von db2BLASTPerformSearch() aufgerufen. Diese Funktionist eine Modifikation von BLASTPerformSearchWithReaddb(). Die Funktion hat in denwesentlichen Punkten den gleichen Aufbau (vergleiche Abbildung 6.2) wie das Original. Sieunterscheiden sich darin, dass die neue Funktion die von SQLFetch() gewonnene Sequenz-ID an die aufrufende Funktion ..._blast_search() zuruckgibt.

Die ursprungliche Funktion readdb_get_sequence() muss die beiden anderen Kontexteabdecken. Um den ”aktuelle Sequenz”-Kontext vom wahlfreien zu unterscheiden, ermitteltein Test, ob die ubergebene ID der zwischengespeicherten entspricht. Ist dies der Fall, liegtder ”aktuelle Sequenz”-Kontext vor. Dann wird die Sequenz aus dem ReadDBFILE-Elementbuffer genommen, die Lange aus seqLength.

Im anderen Fall liegt der wahlfreie Kontext vor. Fur diesen wird die SQL-Anweisung(Beispiel Proteinsuche)


61


db2BLASTPerformSearch(searchBlk,*pSeqNum)

{

/*** den DB-Mutex setzen, falls Multithreading ***/

NlmMutexLock(searchBlk->thr_info->db_mutex);

db2_retval = <RUECKGABEWERT der letzten SQLFetch()-Operation>

if (db2_retval INDICATES SUCCESS) {

/*** Kopieren der SequenzID in ***/

*pSeqNum = search->rdfp->currSeqNum = db2seqNum;

/*** mit BLASTPerformSearchWithReadDb identischer Teil ***/

length = db2_get_sequence(searchBlk->rdfp,

searchBlk->thr_info->db_mutex, &seq);

[...]

BLASTPerformSearch(searchBlk, length, seq);

}

else {

/*** Mutex bei Fehler freigeben ***/

NlmMutexUnlock(searchBlk->thr_info->db_mutex);

}

/*** RUECKGABEWERT = SQLFetch-RUECKGABE ***/

return db2_retval;

}

Abbildung 6.2: schematischer Ablauf von db2BLASTPerformSearch(). Die Abbildung stehtin Beziehung mit Abbildung 4.4.

benotigt. Die dafur erforderliche Funktionsfolge

SQLBindParameter() → SQLExecute() → SQLBindCol()

sowie der SQLFetch()-Aufruf werden in readdb_get_sequence() ausgefuhrt. Die Sequenzwird hier ebenfalls mittels db2convertSeqToNCBIFormat() kodiert. Außerdem werden dieZwischenergebnisse wie bei db2_get_sequence() in den ReadDBFILE-Elementen gespei-chert.

Der Aufbau von db2convertSeqToNCBIFormat() wird hier nicht vertieft. Die Funktionbildet lediglich die Sequenzkodierung als Programmcode ab (Abschnitt 4.3.2).

6.1.3.2 Die Modifikation von readdb ambchar present()

readdb_ambchar_present() wird ausschließlich im ”aktuelle Sequenz”-Kontext aufgeru-fen. Die Modifikation der Funktion besteht lediglich darin, den Wert der Variablen isAmbder ReadDBFILE-Struktur zuruckzugeben.

6.1.3.3 Die Modifikation von readdb get ambchar()

readdb_get_ambchar() wird ebenfalls ausschließlich im ”aktuelle Sequenz”-Kontext auf-gerufen, kann also auf Zwischenergebnisse zuruckgreifen. Falls isAmb aus der ReadDBFILE-Struktur auf Mehrdeutigkeiten hinweist, ruft readdb_get_ambchar() die von db2blast neu

62


eingefuhrte Funktion db2ConstructAmbInfo() auf. Diese liefert zu einer unkodierten Se-quenz die Mehrdeutigkeitskodierung (siehe Abschnitt 4.3.2), die im ReadDBFILE-ElementambChars gespeichert wird.

6.1.3.4 Die Modifikation von readdb get sequence length()

readdb_get_sequence_length()-Aufrufe stehen ausschließlich im wahlfreien Kontext. DieFunktion verwendet folgende SQL-Anweisung (Beispiel Proteinsuche):

SELECT length(seqtext) FROM sequences.protein WHERE proteinid=?

Die dafur notige Funktionsfolge

SQLBindParameter() → SQLExecute() → SQLBindCol() → SQLFetch()

wird in readdb_get_sequence_length() ausgefuhrt. Das Ergebnis wird in der Variablendb2seqlen gespeichert.

6.1.3.5 Die Modifikation von readdb get defline ex()

Die Funktion gibt in blastall die Kennungszeile einer Sequenz zuruck. Im Rahmen vondb2blast muss eine solche Kennungszeile so gut wie moglich simuliert werden, um die Er-gebnisse von blastall und db2blast vergleichbar zu machen. Der Vergleich geschieht mitHilfe des BLAST-Reports, wo den Vergleichssequenzkennungen die Alignierungen zugeord-net werden. Bei der Konstruktion einer Kennungszeile mussen zwei Dinge beachtet werden:

1. Um db2blast und blastall zu vergleichen, mussen sie auf denselben Vergleichssequenzenarbeiten. Zu diesem Zweck wird die Datenbankrelation als Datei exportiert und indas FASTA-Format (Anhang B.1) konvertiert. Zur Identifikation der Sequenzen wirddie spezielle Kennung ”lcl” (die soviel wie ”lokale Sequenz” bedeutet) verwendet.Die Sequenz mit der ID x (NASeqID bzw. ProteinID) erhalt dann folgende FASTA-Kennung: lcl|x .

2. Wahrend der Formatierung dieser FASTA-Datensammlung durch FormatDB werdendie Kennungen modifiziert. Diese Modifikation schlagt sich in der ID-Datei nieder.Die Kennung sieht danach wie folgt aus:

gnl|BL_ORD_ID|y lcl|x

y ist hier die Ordnungszahl der Sequenz, beginnend bei 0. Diese Ordnungszahl wirdintern von BLAST verwendet und erscheint nicht im BLAST-Report.

Damit die Kennungen der alignierten Sequenzen eines blastall - und eines db2blast-Lauf ver-gleichbar sind, wird die Kennung bei db2blast wie folgt konstruiert:

gnl|BL_ORD_ID|x lcl|x

Das x steht in beiden Teilkennungen fur die ID in der jeweiligen Datenbankrelation. DieID wird der Funktion als Parameter ubergeben. Da der gnl-Teil der Kennung im BLAST-Report nicht verwendet wird, sind die Reports von blastall und db2blast vergleichbar.

63


do_blast_search(searchBlk)

{

do

{

db2_retval = db2BLASTPerformSearch(searchBlk,&seq_num);

if (db2_retval INDICATES SUCCESS)

{

BlastReapHitListByEvalue(searchBlk);

BlastReevaluateWithAmbiguities(searchBlk, seq_num);

BlastSaveCurrentHitlist(searchBlk);

}

} while (db2_retval INDICATES SUCCESS);

[...]

}

Abbildung 6.3: Schematischer Ablauf von do blast search() im Kontext der db2blast-Anpassung. Die Abbildung steht in Beziehung zu Abbildung 4.3.

6.1.4 Anpassungen der BLAST-Hauptroutine

Im vorangegangenen Abschnitt wurde darauf hingewiesen, dass eine uber alle Vergleichs-sequenzen laufende Schleife im Rahmen der Anpassung ebenfalls modifiziert werden muss.Dies ist notwendig, damit die Aufrufkontexte der kritischen readdb-Funktionen gultig sind.Die ..._blast_search()-Funktionen enthalten eine solche for-Schleife.

Fur db2blast wird die for-Schleife durch eine do-while-Schleife ersetzt. Die Funktio-nen, die in der Schleife nach dem db2BLASTPerformSearch()-Aufruf folgen, erhalten die IDder Sequenz anstatt ihrer Ordnungszahl, welche im blastall -Original durch die Schleifenva-riable reprasentiert wird. Der Aufbau der modifizierten do_blast_search-Funktion kannAbbildung 6.3 entnommen werden. Der Wegfall des BlastGetDbChunk()-Funktionsaufrufsist deshalb sinnvoll, weil in der Datenbankrelation keine Abschnitte einem einzelnen threadzugewiesen werden konnen.

Die restlichen db2blast-Modifikationen ruhren daher, dass zwei Funktionen des Modulsblast.c die MMF-Funktion ReadDBCloseMHdrAndSeqFiles() aufrufen:

• BLASTSetUpSearchWithReadDbInternal()

• do_the_blast_run()

Der Aufruf von ReadDBCloseMHdrAndSeqFiles() kann in beiden Fallen einfach weggelassenwerden, da die entsprechenden Dateien nicht existieren.

6.1.5 Parallelverarbeitung in db2blast

Durch das Entfernen des BlastGetDbChunk()-Aufrufs in den ..._blast_search()-Funk-tionen ist dem Programm die Verwaltungsstelle des Datenbank-Mutex und damit die Mog-lichkeit zum multithreading ”genommen”. Dieser Abschnitt analysiert, wie multithreadingim Rahmen von db2blast realisiert werden kann.

db2blast hat, wie das Originalprogramm, eine geteilte Ressource, und zwar die Daten-bankschnittstelle. Konkret ist es die folgende SQL-Anweisung:

64


SELECT proteinid,seqtext FROM sequences.protein

Im Fall der Ausfuhrung mehrerer threads wird die Anweisung von den Instanzen der Funk-tion db2_get_sequence() verwendet. Diese wiederum werden von einer konkreten Instanzvon ..._blast_search() gerufen. Bei jedem SQLFetch()-Aufruf in db2_get_sequence()werden die gleichen globalen Variablen beschrieben. Der Zugriff auf diese Variablen mussdeshalb mittels eines Mutex serialisiert werden. Der dafur in Frage kommende Mutex istthrinfo->db_mutex aus der BlastSearchBlk-Struktur. Dieser kann verwendet werden,da die ursprungliche Verwaltungsfunktion BlastGetDbChunk() in db2blast nicht mehr ver-wendet wird.

Der Mutex wird in db2BLASTPerformSearch() gesetzt. Nach dem SQLFetch()-Aufrufund dem Kopieren der Ergebnisattribute in thread -lokale Variablen wird der Mutex indb2_get_sequence() wieder freigegeben. Die thread -lokalen Variablen sind die Elementevon ReadDBFILE, da jeder thread eine eigene Instanz dieser Struktur besitzt.

Im Parallelbetrieb arbeiten nur die ..._blast_search()-Funktionen. In diesen Funk-tionen wird nur die obige SQL-Anweisung benotigt. Deshalb sind die anderen SQL-Anwei-sungen vom multithreading nicht betroffen.

6.1.6 Die praktische Umsetzung von db2blast

Dieser Abschnitt gibt einen kurzen Uberblick daruber, wie die in den vorangegangenenAbschnitten beschriebenen Modifikationen praktisch umgesetzt werden. Ausgangspunktsind zwei neue Quelltextdateien, die die neuen Funktionen beherbergen:

1. db2conn.c enthalt zunachst die globalen Variablen sowie die Initialisierungs- und Frei-gaberoutinen:

• db2init()

• db2prepareStatements()

• db2executeAndBindConstStatements()

• db2destruct()

Außerdem sind db2_get_sequence() und db2BLASTPerformSearch() enthalten.

2. db2seqHandl.c enthalt von der Datenbankverbindung unabhangige Funktionen zumUmgang mit Sequenzen:

• db2convertSeqToNCBIFormat()

• db2ConstructAmbInfo()

Die Funktionen in db2seqHandl.c werden, im Gegensatz zu denen in db2conn.c, auchin der zweiten Anpassung verwendet.

Die Funktionsschnittstellen und die globalen Variablendeklarationen werden durch die Dateidb2conn.h exportiert. Aus diesem Grund muss diese Datei per #include in die Dateienblast.c und readdb.c eingebunden sein.

Die in den vorangegangenen Abschnitten beschriebenen Modifikationen am BLAST-Quelltext werden wie folgt integriert:

65


• Wird neuer Programmcode in den Quelltext eingefugt, so geschieht dies mittels einerPraprozessor-Definitionsabfrage namens DB2BLAST. Programmcode, der zwischen denPraprozessor-Direktiven #ifdef DB2BLAST und dem dazugehorigen #endif steht, isteine Modifikation von db2blast.

• Wird alter Programmcode im Quelltext durch neuen ersetzt, so wird nach dem neuenProgrammcode ein #else eingefugt. Der neue Programmcode endet vor der #else-Direktive, der alte Programmcode endet vor der #endif-Direktive.

Mit diesem Schema ist es moglich, sowohl das Original-Programm als auch db2blast zu er-zeugen. Beim zweiten Fall wird als Compiler-Option die Praprozessor-Definition DB2BLASTangegeben. Außerdem muss in diesem Fall die Bibliothek db2 mit eingebunden werden,damit eine CLI-Anwendung erzeugt werden kann.

6.1.7 Vergleich des Laufzeitverhaltens von blastall und db2blast

Zum Abschluss der CLI-Anpassung soll die Laufzeit von blastall und db2blast verglichenwerden. Dazu werden verschiedene Sequenzen (Anfragesequenzen) mit den Sequenzen derTestdatenbank aligniert.

Der erste Test fuhrt die Programmvariante blastp aus, die die Sequenzen aus der Rela-tion PROTEIN aus dem Datenbankschema (siehe Abbildung 5.1) als Vergleichssequenzenverwendet. Die PROTEIN-Relation umfasst 261440 Sequenzen. Daraus werden vier Se-quenzen verschiedener Lange ausgewahlt, die als Anfragesequenzen verwendet werden.

Um die Sequenzen auch im Kontext von blastall verwenden zu konnen, mussen sieaus der Relation in eine Datei exportiert und dort in’s FASTA-Format gebracht werden.Diese Datei wird dann mittels formatdb bearbeitet, damit BLAST die Vergleichssequenzenverwenden kann.

Fur den Vergleich der beiden Programme wurden nur die Optionen -p, -d, -i und -o(vergleiche Anhang A) verwendet, es wird also standardmaßig eine luckenbehaftete Ali-gnierung durchgefuhrt. Folgende Tabelle zeigt den Vergleich von blastall und db2blast amBeispiel eines blastp-Laufs mit einem Prozessor (Langen in Bytes, Laufzeiten in Sekunden):

Lange der Anfragesequenz Laufzeit blastall Laufzeit db2blast3419 231 2792065 69 121778 33 84240 18 73

Der Unterschied zwischen den Laufzeiten von blastall und db2blast kommt dadurchzustande, dass das modifizierte Programm zum Lesen der Sequenzen auf die relationaleDatenbank zugreift. Außerdem mussen die Sequenzen kodiert werden. Die Laufzeitdiffe-renz liegt bei den betrachteten Sequenzen zwischen 48 und 55 Sekunden. Die Variabilitatdes Werts ruhrt daher, dass wahrend der luckenbehafteten Nachbearbeitung noch einmaldiejenigen Sequenzen per SQL-Anweisung geholt werden, welche HSPs enthalten. Die An-zahl der betroffenen Sequenzen hangt von der Anfragesequenz ab.

blastall und db2blast haben die Fahigkeit, im multithreading-Betrieb ausgefuhrt zu wer-den. In beiden Programmen wird dazu die luckenfreie Alignierung parallel ausgefuhrt. Diefolgende Tabelle zeigt den Vergleich der Programme unter Verwendung von acht Prozesso-ren (Langen in Bytes, Laufzeiten in Sekunden):

66


Lange der Anfragesequenz Laufzeit blastall Laufzeit db2blast3419 85 1322065 10 58778 6 57240 5 60

Da der Zugriff auf die Datenbank serialisiert werden muss, ist der Laufzeitunterschiedder beiden Programme fast identisch mit dem im Ein-Prozessor-Fall. Im Mehrprozessorfallist der Unterschied etwas geringer. Das kann damit erklart werden, dass ein Teil derBerechnungszeit der luckenfreien Alignierung sowie die Kodierung der Sequenzen parallelzum Datenbankzugriff anderer Sequenzen ausgefuhrt werden.

Der zweite Test ist ein blastn-Lauf, der vier Anfragesequenzen unterschiedlicher Langemit den DNA-Sequenzen der Datenbank vergleicht. Die Sequenzen sind als Tupel in derRelation NASEQUENCE gespeichert, und uber einen Join mit der DNA-Relation werdendie DNA-Sequenzen ermittelt:

SELECT SeqText,NASeqID FROM sequences.nasequence,sequences.dnaWHERE naseqid=dnaseqid;

Die Relation NASEQUENCE enthalt 70398 DNA-Sequenzen. Fur den Vergleich von blastallund db2blast mussen auch die DNA-Sequenzen als BLAST-Datensammlung gespeichert undformatiert werden. Fur den blastn-Lauf wurden außer den notwendigen Parametern -p, -d,-i und -o keine weiteren Optionen gesetzt. Standardmaßig wird also eine luckenbehafteteAlignierung durchgefuhrt.

Folgende Tabelle zeigt den Vergleich von blastall und db2blast am Beispiel eines blastp-Laufs mit einem Prozessor (Langen in Bytes, Laufzeiten in Sekunden):

Lange der Anfragesequenz Laufzeit blastall Laufzeit db2blast8152 3.98 39.412566 2.61 37.94734 1.81 36.56162 1.87 36.90

Interpretiert man den Laufzeitunterschied zwischen den beiden Programmen als Zu-griffszeit auf die relationale Datenbank, so betragt die Ausfuhrungszeit aller Datenbankan-weisungen und die Kodierung der Sequenzen rund 35 Sekunden. Fur die langste Sequenzergibt das eine Verzehnfachung der Ausfuhrungszeit, fur kurzere Sequenzen liegt der Faktornoch hoher. Die Berechnungszeit des Algorithmus ist deutlich kleiner als bei blastp, wasprimar zwei Grunde hat:

1. Die Kodierung der Residuen als 2bit-Werte fuhrt zu einer kompakteren Speicherungder Nukleotidsequenzen. Da der Algorithmus darauf eingestellt ist, ist auch dessenLaufzeit entsprechend niedriger.

2. Bei der Alignierung der Proteinsequenzen wird eine Bewertungsmatrix, wie z.B. BLO-SUM oder PAM, verwendet. Das erfordert zweidimensionale Indexzugriffe. Im Fallvon Nukleotidsequenz-Vergleichen wird nur zwischen Ubereinstimmungen (matches)und Unterschieden (mismatches) differenziert. Letzteres erfordert nur einfache Ver-gleichsoperationen, was die Laufzeit ebenfalls gunstig beeinflusst.

67


Fur blastn wird ebenfalls der Multiprozessorvergleich mit acht Prozessoren durchgefuhrt.Folgende Tabelle zeigt die Laufzeiten (in Sekunden, Langen der Sequenzen in Bytes):

Lange der Anfragesequenz Laufzeit blastall Laufzeit db2blast8152 0.97 26.442566 0.62 26.22734 0.46 26.02162 0.67 26.30

Auffallend ist hier, dass die Laufzeitdifferenz zwischen den beiden Versionen erheblichkleiner ist als im Einprozessorfall. Der Grund liegt darin, dass nur der Zugriff auf dieDatenbank serialisiert wird (mittels db_mutex), die Kodierung der Sequenzen aber nicht.Die Kodierung in einem thread lauft also parallel zum Datenbankzugriff in einem anderenthread. Der Aufwand fur die Kodierung der Nukleotidsequenzen betragt also ca. 10 Sekun-den. Es ist plausibel, dass der Kodierungsaufwand fur eine Nukleotidsequenz hoher ist alsder fur eine gleich lange Proteinsequenz, da im ersteren Fall einzelne Bits belegt und beiMehrdeutigkeiten zwei Kodierungen durchgefuhrt werden mussen.

Zusammenfassend lasst sich sagen, dass fur die BLAST-Varianten blastp und blastn, diedie Hauptanwendungen darstellen, der Aufwand fur den Datenbankzugriff die Laufzeit vonBLAST erheblich erhoht. Im Fall von blastp fallt dieser Aufwand weniger in’s Gewicht, dader Aufwand fur die Kodierung relativ gering ist und der Protein-Algorithmus eine relativhohe Laufzeit hat. Bei blastn fuhren die Datenbankzugriffe zu deutlich mehr Laufzeit, wasan der komplizierteren Kodierung der Nukleotidsequenzen und der niedrigeren Laufzeit desAlgorithmus selbst liegt.

6.2 BLAST als benutzerdefinierte Funktion

Die Umwandlung von blastall zu einer Call Level Interface-Anwendung ermoglicht es einemBenutzer, BLAST wie bisher als eigenstandiges Programm auszufuhren. Der Nutzungskon-text bleibt gleich. Folgende Einschrankungen mussen dabei gemacht werden:

1. db2blast kann nur verwendet werden, wenn das Programm fur die entsprechende Nut-zungsumgebung, also die Kombination aus Betriebssystem und Datenbank-Manage-mentsystem, ubersetzt worden ist.

2. Die Anwendung von BLAST ist auf ein Datenmodell zugeschnitten. Modifikationenam Datenmodell mussen sich in Anderungen der im Programm enthaltenen SQL-Anweisungen niederschlagen.

3. Die Anwendung des Programms ist auf die Falle beschrankt, die im Programm vor-gesehen sind. Sollen beispielsweise nur die RNA-Sequenzen aus der Datenbank unter-sucht werden, die zu einem bestimmten Organismus gehoren, so musste der BLAST-Report manuell untersucht werden.

Die Verwendung von db2blast schopft also die Moglichkeiten nicht aus, die SQL-Anfragenbieten. Aus diesem Grund beschreibt dieser Abschnitt die Umsetzung von BLAST alsbenutzerdefinierte Funktion (UDF ). Auf diesem Weg wird BLAST starker in die Datenbank

68


UDF-Parameter SQL-Datentyp blastall -OptionprogType VARCHAR(10) -pfilterQuery INTEGER -FgappedBlast INTEGER -gexpectValue DOUBLE -enuclMismatchScore INTEGER -qnuclMatchScore INTEGER -rmatrixName VARCHAR(30) -MwordSize INTEGER -Whits_n_passes INTEGER -PqueryStrands INTEGER -SgapOpenCost INTEGER -GgapExtCost INTEGER -EdropoffExt DOUBLE -ydropoffGapped INTEGER -XdropoffGappedFinal INTEGER -ZexpandThresh INTEGER -fqueryGenCode INTEGER -QsubjGenCode INTEGER -D

Tabelle 6.1: udfblast-Parameter, die sich direkt aus blastall -Optionen ergeben

integriert. Das entstehende ”Produkt” wird im Folgenden mit udfblast bezeichnet, um esvon blastall und db2blast zu unterscheiden.

Zunachst geht es darum, BLAST als externe Tabellenfunktion zu modellieren. Daeine externe UDF nicht auf die Datenbank zugreifen darf, mussen alle Parameter beimAufruf oder mittels Dateien ubergeben werden. Die Funktion wird so konzipiert, dass jeder(externe) Aufruf der UDF genau eine Vergleichssequenz bearbeitet. Zur Analyse einerkompletten Relation durch BLAST muss eine entsprechende SQL-Anweisung formuliertwerden. Darauf wird am Ende des Kapitels eingegangen.

Eine Tabellenfunktion eignet sich fur die Implementation von BLAST aus dem Grund,dass eine Vergleichssequenz mit der Anfragesequenz mehrere Alignierungen bilden kann,die alle gleichartig strukturiert sind. Eine derartige Struktur kann durch die Attribute(Ruckgabespalten) der Funktion abgebildet werden.

6.2.1 Eingabeparameter von udfblast

Ausgangspunkt fur die Frage nach den Parametern von udfblast sind die Optionen, dieblastall auf der Kommandozeile ubergeben werden. Die im Anhang A zu findende Optio-nenliste muss moglichst vollstandig in udfblast ubernommen werden. Es werden lediglich dieOptionen ausgespart, die im Zusammenhang mit udfblast keine Bedeutung haben. Tabelle6.1 beinhaltet die Parameter, die sich direkt aus blastall -Optionen abbilden lassen.

Die Anfrage- und die Vergleichssequenz werden ebenfalls als Parameter ubergeben. Dadie Datenbank die Vergleichssequenzen als LONG VARCHAR speichert, wird dieser Datentypauch fur die UDF-Parameter verwendet. Die Parameter werden mit querySequence undsubjSequence bezeichnet.

blastall und db2blast verwenden eine Setup-Datei, die im Arbeitsverzeichnis des Benut-zers steht. In dieser Datei ist der Verzeichnis-Pfad der Bewertungsmatrix-Datei abgelegt.

69


Die Setup-Datei kann im UDF-Kontext nicht verwendet werden, da die UDF unter einerBenutzerkennung lauft, die vom DBMS reserviert ist. Um dennoch auf die Matrix-Dateizugreifen zu konnen, wird der Verzeichnispfad als weiterer UDF-Parameter ubergeben. Erwird mit matrixFilePath bezeichnet und ist vom Typ VARCHAR(255).

Bei der Analyse von blastall als auch bei db2blast werden einige Kennwerte erwahnt,die entweder aus der Index-Datei (blastall) bzw. mittels einer SQL-Anweisung (db2blast)ermittelt werden:

1. Anzahl der Vergleichssequenzen

2. Summe der Langen aller Vergleichssequenzen

3. Lange der langsten Vergleichssequenz

Die ersten beiden dienen der Berechnung normalisierter Alignierungsbewertungen. Der drit-te Wert wird zur Reservierung von Speicherbereichen benotigt, die die Vergleichssequenzenaufnehmen. Insbesondere die ersten beiden Kennwerte sind notwendig, um die Ergebnissevon udfblast mit db2blast vergleichbar zu machen. Folglich werden diese drei Kennwerteebenfalls als Parameter an die benutzerdefinierte Funktion ubergeben. Sie heißen count,totlen und maxlen (in der gleichen Reihenfolge wie in obiger Aufzahlung) und sind vomSQL-Typ INTEGER.

6.2.2 Ruckgabewerte von udfblast

Das Ergebnis eines BLAST-Vergleichs von Anfrage- und Vergleichssequenz ist im allgemei-nen Fall eine Liste mehrerer Alignierungen. Jede Alignierung ist dabei auf die gleiche Artund Weise strukturiert. Die Struktur einer Alignierung wird im Folgenden als Menge vonAttributen mit entsprechenden SQL-Datentypen zu modelliert. Ausgangspunkt ist der imAnhang B.3 beschriebene BLAST-Report, dessen wichtigste Informationen hier ubernom-men werden.

Da ein Ergebnistupel der UDF eine Alignierung darstellt, werden nur die einer Alignie-rung zuordenbaren Informationen ausgewertet. Tabelle 6.2 enthalt die Ruckgabeattributeder UDF. Zu den Attributen muss Folgendes angemerkt werden:

1. Bei den Lucken (gaps) werden im Original-BLAST zwei Falle unterschieden. Wurdemit blastp oder blastn luckenbehaftet aligniert, so werden die Lucken sowohl in derAnfrage- als auch der Vergleichssequenz gezahlt. Bei den Varianten blastx und tblastnwerden nur die Lucken in der Anfragesequenz gezahlt. Dieses Verhalten wird beiudfblast beibehalten, da die Ergebnisse mit blastall vergleichbar sein sollen.

2. blastn gibt im BLAST-Report die Leserichtung von Anfrage- und Vergleichssequenzzuruck. Bei der UDF werden entsprechende Werte in queryFrame und subjectFramezuruckgegeben. Der Wert 1 steht dabei fur die positive Leserichtung und -1 fur dienegative.

3. Die BLAST-Varianten blastx, tblastn und tblastx geben das Leseraster von Anfrage-und Vergleichssequenz zuruck. Bei der UDF werden die entsprechenden Werte in denAttributen queryFrame und subjectFrame zuruckgegeben.

70


UDF-Attribut SQL-Datentyp BeschreibungbitScore DOUBLE normalisierter Wert der Alignierungscore INTEGER nominaler Wert der AlignierungexpectValue DOUBLE Erwartungswert der AlignmentbewertungalignLength INTEGER Lange der Alignierung (Residuen)queryOffset INTEGER Startposition der Alignierung in der AnfragesequenzsubjectOffset INTEGER Startposition der Alignierung in der VergleichssequenzqueryLength INTEGER Lange der Alignierung in der AnfragesequenzsubjectLength INTEGER Lange der Alignierung in der VergleichssequenzqueryFrame SMALLINT Leserichtung (blastn) bzw. Leseraster (blastx, tblastx) der

AnfragesequenzsubjectFrame SMALLINT Leserichtung (blastn) bzw. Leseraster (tblastn, tblastx) der

VergleichssequenzidentPairs INTEGER Anzahl von Paaren identischer ResiduenpositivePairs INTEGER Anzahl Residuenpaare mit positiver Bewertunggaps INTEGER Anzahl LuckenqueryString LONG VARCHAR alignierter Bereich der AnfragesequenztransitString LONG VARCHAR Ahnlichkeitssequenz der alignierten SequenzensubjectString LONG VARCHAR alignierter Bereich der Vergleichssequenz

Tabelle 6.2: udfblast-Parameter, die sich direkt aus blastall -Optionen ergeben

4. transitString stellt eine Art ”Vergleichszeichenkette” dar. Aus ihr kann ersehenwerden, welche Residuen der beiden Sequenzen identisch zugeordnet wurden undwelche mit positiver Bewertung.

6.2.3 SQL-Deklaration der UDF

Die letzten beiden Abschnitte haben die Ein- und Ausgabeparameter beschrieben, die zurDeklaration der benutzerdefinierten Funktion BLAST benotigt werden. Folgende SQL-Anweisung deklariert die UDF:

CREATE FUNCTION sequences.blast(<Eingabeparameter>)

RETURNS TABLE (<Rueckgabewerte>)

EXTERNAL NAME ’udfblast!UDF_blast’

LANGUAGE C

PARAMETER STYLE DB2SQL

NOT DETERMINISTIC

FENCED

NULL CALL

NO SQL

EXTERNAL ACTION

SCRATCHPAD

FINAL CALL

DISALLOW PARALLEL

NO DBINFO

Die Eingabeparameter und die Ruckgabewerte wurden in den letzten beiden Abschnittenaufgezahlt. Zu den Optionen gibt es folgende Anmerkungen zu machen:

• Die Option NULL CALL wird gesetzt, damit die Funktion auch dann aufgerufen wird,wenn einige der Parameter NULL sind. Das Design der Funktion ist von der Art, dass

71


einige Parameter NULL sein konnen und die Funktion trotzdem vernunftige Resultateliefert.

• EXTERNAL ACTION wird angegeben, weil die Funktion auf die Bewertungsmatrix-Dateizugreift (matrixName und matrixFilePath).

• Das SCRATCHPAD wird verwendet, um zwischen den verschiedenen Aufruftypen derUDF bestimmte Informationen zu konservieren.

• FINAL CALL wird in der Implementationsbeschreibung motiviert. Im Wesentlichenwerden die Funktionsaufrufe FIRST und FINAL dazu verwendet, einen BLAST-Laufals Ganzen zu verwalten.

6.2.4 Implementation der UDF

Fur die Implementation von BLAST als UDF wird zunachst der Ablauf von blastall grobschematisiert. Das Ablaufschema lasst sich wie folgt beschreiben:

1. InitialisierungDer Schritt der Initialisierung wird dadurch charakterisiert, dass Datenstrukturen re-serviert und initialisiert werden. In diesem Schritt werden keine Aktionen ausgefuhrt,die von konkreten Vergleichssequenzen abhangen. Der Schritt der Initialisierungreicht vom Anfang der Main()-Funktion bis zum Aufruf von ..._blast_search()in der Funktion do_the_blast_run(). Die ..._blast_search()-Funktionen selbstkonnen nicht mehr zur Initialisierung gezahlt werden, da in ihnen BLAST auf denVergleichssequenzen ausgefuhrt wird.

2. BLAST-AlignmentsucheDer Schritt der BLAST-Alignmentsuche ist dadurch gekennzeichnet, dass alle Ver-gleichssequenzen nach luckenfreien Alignierungen durchsucht werden. Der Schrittumfasst nur die Funktion do_blast_search() bzw. do_gapped_blast_search(). Indiesen wird eine Schleife uber alle Sequenzen ausgefuhrt, in der nach den Alignierun-gen gesucht wird.

3. NachbearbeitungDie Nachbearbeitung konvertiert die in der BlastSearchBlk-Struktur gespeichertenluckenfreien Alignierungen in eine SeqAlign-Liste. Falls blastall luckenbehaftete Ali-gnierungen bilden soll, werden die luckenfreien HSPs dabei entsprechend erweitert.Dieser Schritt erstreckt sich uber den Teil der Funktion BioseqBlastEngineCore(),der nach dessen Aufruf von do_the_blast_run() folgt.

4. Ausgabe der Ergebnisse und Freigabe von DatenstrukturenDieser Schritt dient dazu, die SeqAlign-Liste fur den BLAST-Report aufzubereitenund diesen auszugeben. Gleichzeitig werden die im Programm reservierten und initia-lisierten Datenstrukturen wieder freigegeben. Dieser Schritt beginnt nach Beendigungvon BioseqBlastEngineCore() und reicht bis zum Ende der Main()-Funktion.

Zur Implementation dieses Schemas als UDF mussen die einzelnen Schritte den UDF-Aufruftypen zugeordnet werden. Dabei muss analysiert werden, welche Informationen zwi-schen den Schritten kommuniziert werden mussen. Die dazu erforderlichen Datenstrukturen

72


Abbildung 6.4: Anderung des Ablaufschemas zur Implementation von BLAST als UDF.

konnen mittels des schon erwahnten scratchpads verwaltet werden. Folgender (Abbildung6.4) Ablauf wird fur die UDF vorgeschlagen:

1. Fur den FIRST -Aufruf der UDF eignet sich der Initialisierungsschritt, da dieser vonden konkreten Sequenzen unabhangig ist und Initialisierungen fur alle Vergleichsse-quenzen vornimmt. Beim FIRST-Aufruf werden der UDF diejenigen Parameter uber-geben, die der ersten Parameter-Kombination in der SQL-Anweisung entsprechen.Der Aufruf initialisiert die BLAST_OptionsBlk- und die BlastSearchBlk-Struktur.Beide werden in den nachfolgenden Aufrufen benotigt.

2. Die UDF ist so konzipiert, dass nur jeweils eine Vergleichssequenz ubergeben wird.Soll ein BLAST-Lauf uber mehrere Vergleichssequenzen gehen, muss eine entsprechen-de SQL-Anweisung formuliert werden. Fur jede Vergleichssequenz wird dann genaueinmal ein OPEN -Aufruf gestartet. Es bietet sich an, die BLAST-Alignmentsuchevon genau einer Sequenz im OPEN-Aufruf laufen zu lassen. Dafur muss der Inhalt derSchleife aus ..._blast_search() fur die Sequenz ausgefuhrt werden. Die Nachbear-beitung erfolgt bei blastall nach der Schleife. Dieser Schritt wird ebenfalls in OPENausgefuhrt. Es muss dafur gesorgt werden, dass er nur auf einer Sequenz lauft. DieSeqAlign-Liste wird in den nachfolgenden FETCH -Aufrufen ausgewertet.

3. Das Ergebnis der Nachbearbeitung ist die Kette von SeqAlign-Elementen. Im UDF-Kontext darf diese Kette nur Alignierungen einer einzigen Vergleichssequenz mit derAnfragesequenz enthalten. Das Traversieren der einzelnen Alignierungen erfolgt imFETCH -Aufruf. Dabei wertet jeder FETCH-Aufruf eine Alignierung aus, formatiertdiese und gibt die Alignierung als Ergebnistupel zuruck. Der folgende FETCH-Aufrufwertet die nachste Alignierung der gleichen Sequenz aus und so fort. Enthalt dieSeqAlign-Liste keine unausgewerteten Elemente mehr, gibt die Funktion den Spezi-alstatus ”keine weiteren Zeilen” (SQLSTATE ”02000”) zuruck. Der blastall -Schritt”Ausgabe der Ergebnisse” wird hier nicht ausgefuhrt, da er fur die Formatierung des

73


BLAST-Reports konzipiert ist. Stattdessen wird eine eigene SeqAlign-Auswertungimplementiert.

4. Da der Schritt der Nachbearbeitung in der UDF fur jede Sequenz einzeln vollzogenwird, mussen entsprechende Datenstrukturen wieder freigegeben werden. Der nachsteOPEN-Aufruf reserviert die Strukturen erneut. Zur Freigabe dieser Ressourcen bietetsich der CLOSE -Aufruf an.

5. Die Freigabe von Datenstrukturen ist sinnvollerweise Gegenstand des FINAL-Aufrufs,da erst hier sicher ist, dass in der aktuellen SQL-Anweisung keine weiteren Aufrufemehr kommen, die die Datenstrukturen eventuell noch benotigen konnten.

6.2.4.1 Der FIRST -Aufruf von udfblast

Der FIRST-Aufruf enthalt den Initialisierungsteil von BLAST. Die UDF muss so verwen-det werden, dass subjSequence (die Vergleichssequenz) der einzige sich andernde Para-meter zwischen zwei OPEN-Aufrufen ist. Die anderen Parameter konnen bereits beimFIRST-Aufruf ausgewertet werden. Die meisten von ihnen durfen einen NULL-Wert uber-geben. Ausgenommen sind folgende Parameter (es werden die Bezeichner aus der SQL-Funktionsdeklaration verwendet):

• progType — die Programmvariante

• querySequence — die Anfragesequenz

• count — Kennwert fur die gesamte BLAST-Suche

• totLen — Kennwert fur die gesamte BLAST-Suche

• maxLen — Kennwert fur die gesamte BLAST-Suche

• matrixFilePath — Verzeichnispfad zur Bewertungsmatrix-Datei

Wird fur einen dieser Parameter NULL ubergeben, so gibt die benutzerdefinierte Funktioneinen Fehler in SQLSTATE und eine entsprechende Fehlermeldung zuruck. Die Angabe vonNULL fur einen der anderen Parameter bedeutet, dass fur diesen der jeweilige Standardwert(default) von udfblast verwendet wird. Dies ist aquivalent mit dem Verhalten von blastall,wenn der Parameter nicht gesetzt wird.

An die Prufung der Eingabeparameter schließt sich der Initialisierungsteil von BLASTan. Um ihn mit wenig Aufwand aus blastall zu ubernehmen, werden die zum Initialisie-rungsteil gehorenden Anweisungen in den FIRST-Code ubernommen. Davon sind diejeni-gen Funktionen betroffen, die nur zum Teil zur Initialisierung beitragen:

1. Main() aus blastall.c

2. BioseqBlastEngine()

3. BioseqBlastEngineByLoc()

4. BioseqBlastEngineByLocEx()

5. BioseqBlastEngineCore()

74


6. do_the_blast_run()

Beim Kopieren des Codes in die UDF mussen einige Anderungen vorgenommen werden:

• Es werden drei globale Variablen db2count, db2maxlen und db2totlen eingefuhrt,die die Werte der UDF-Parameter count, maxLen und totLen aufnehmen. Sie werdenvon readdb_new_internal() zur Initialisierung der ReadDBFILE-Struktur verwendet.

• Die Ein- und Ausgabedateien (Anfragesequenz und BLAST-Report) mussen hier nichtgeoffnet werden (wie in Main()), da die entsprechenden Informationen uber die UDF-Schnittstelle ”ubertragen” werden.

• Der Test auf die Gultigkeit bestimmter Parameterkombinationen (Main()) kann ent-fallen, wenn die Parameter nicht Teil der UDF sind.

• Im Fall eines Fehlers in einer der BLAST-Funktionen muss die SQLSTATE-Variablegesetzt und eine Fehlermeldung formuliert werden.

• Die Einfuhrung des neuen Parameters matrixFilePath zieht ein gleichnamiges Ele-ment in der BLAST_OptionsBlk-Struktur nach sich.

• In der Main()-Funktion wird mit Hilfe der Funktion FastaToSeqEntryEx() die An-fragesequenz aus der Datei gelesen und verarbeitet. Dies ist im UDF-Kontext nichtmoglich. Deshalb wird das Programm so modifiziert, dass die Anfragesequenz ausdem Hauptspeicher gelesen und danach verarbeitet wird.

• Bei bestimmten Fallunterscheidungen in Unterfunktionen von Main() werden nurdie Teile des Programmcodes ubernommen, die ausgefuhrt werden, wenn blastall dieentsprechenden Funktionen aufrufen wurde.

• Vom Programmcode von do_the_blast_run() wird nur der Teil ubernommen, derim Ein-thread -Betrieb verwendet wurde. Das multithreading von blastall arbeitetauf der Basis mehrerer Sequenzen. Die Bearbeitung nur einer Sequenz kann nichtparallelisiert werden. Deshalb ist der multithreading-Programmcode in der UDF nichtanwendbar.

6.2.4.2 Der OPEN -Aufruf von udfblast

Im OPEN -Aufruf werden die BLAST-Alignmentsuche sowie die Nachbearbeitung vereinigt.Der Aufruf setzt sich aus folgenden Schritten zusammen:

1. Zunachst wird gepruft, ob subjSequence keinen NULL-Wert ubergeben hat.

2. Es wird die neue Funktion calcBlast() aufgerufen, die die BLAST-Alignmentsucheund die Nachbearbeitung vereinigt. Der Ruckgabewert der Funktion ist ein Zeiger aufdie SeqAlign-Liste.

3. Ist die SeqAlign-Liste nicht leer, wird eine udfblast-eigene Nachbearbeitung durch-gefuhrt. Um in den nachfolgenden FETCH-Aufrufen die Alignierungstupel zu er-zeugen, mussen die Anfrage- und die Vergleichssequenz vorliegen, und zwar in al-len Leserastern. Fur die Anfragesequenz existieren Leseraster-Sequenzen in Unter-strukturen der BlastSearchBlk-Struktur. Fur die entsprechende Vergleichssequenz

75


calcBlast(searchBlk,optionsBlk,sequence,seqLength)

{

[ angepasster Code aus db2_get_sequence() ]

[ angepasster Code aus db2BlastPerformSearch() ]

if (GAPPED && !BLASTN)

[ angepasster Code aus do_gapped_blast_search() ]

else

[ angepasster Code aus do_blast_search() ]

[ angepasster Code aus BioseqBlastEngineCore,

nach dem do_the_blast_run()-Aufruf ]

}

Abbildung 6.5: Schematisierter Ablauf von calcBlast()

mussen diese gebildet werden. Die ubersetzten Sequenzen werden in einem Feldele-ment namens subjSeqsTransl[] des scratchpads abgelegt, weil sie in den nachfol-genden FETCH-Aufrufen benotigt werden. Je nach BLAST-Programmvariante wirddie Ubersetzung wie folgt durchgefuhrt:

• Bei blastp und blastx zeigt das 1. Element des subjSeqsTransl[]-Felds auf dasReadDBFILE-Element buffer, da es die kodierte Sequenz enthalt. Bei diesenProgrammvarianten werden keine Ubersetzungen der Vergleichssequenz durch-gefuhrt.

• Im Fall von blastn werden die ersten beiden Elemente des subjSeqsTransl[]-Felds mit den beiden Leserichtungen der Vergleichssequenz beschrieben. Furdie positive Leserichtung wird der UDF-Parameter subjSequence herangezo-gen und byteweise in das BLASTna-Format kodiert. Die negative Leserichtungder Sequenz wird, am hinteren Ende beginnend, mit den komplementaren Re-siduen beschrieben. Dazu wird ein Konvertierungsfeld namens NAcompl_tab[]verwendet, dass zu jedem BLASTna-Wert (als Feldindex) den BLASTna-Wertdes komplementaren Residuums verwendet.

• tblastn und tblastx mussen die Vergleichssequenz in die sechs Leseraster uber-setzen. Dazu wird die Funktion BlastTranslateUnambiguousSequence() ausdem Modul blastutl.c verwendet.

Der schematische Aufbau der Funktion calcBlast() kann Abbildung 6.5 entnommen wer-den. Dazu seien einige Bemerkungen gemacht:

• Der angepasste db2_get_sequence()-Code unterscheidet sich vom Original im We-sentlichen darin, dass hier die CLI-Funktionsaufrufe und deren Behandlung weggelas-sen werden. Die Mutex-Funktionen werden ebenfalls nicht aufgerufen.

• Die db2BlastPerformSearch()-Modifikation besteht darin, die Mutex-Funktionsauf-rufe und die Prufung von CLI-Funktionsergebnissen zu entfernen. Außerdem wird dieFunktion db2_get_sequence() nicht aufgerufen, da deren aquivalenter Code bereitsvorher abgearbeitet wurde.

76


UDF_blast([...])

{

[...]

switch(UDF_CALLTYPE) {

[...]

case FETCH:

if (ALIGNMENT AVAILABLE?)

{

switch(SeqAlign.segtype) {

case SAS_DENDIAG:

getScoresFromSeqAlign(...);

getAlignScalarsFromDD(...);

getAuxAlignStringsFromDD(...);

compileResidueStatsAndTransStr(...);

[TRAVERSIEREN der SeqAlign-Kette]

case SAS_DENSEG:

[...]

case SAS_STDSEG:

[...]

}

strcpy(SQLSTATE,"00000");

}

else

strcpy(SQLSTATE,"02000");

break;

[...]

}

}

Abbildung 6.6: Ablauf des FETCH-Aufrufs am Beispiel von DenseDiag-Alignierungen. Furdie anderen Alignierungstypen werden gleichartige Funktionen aufgerufen.

• Aus den Funktionen ..._blast_search() wird nur derjenige Teil des Quelltextsubernommen, der bei einem Aufruf durch blastall ausgefuhrt wurde. Die Abarbeitungvon db2BLASTPerformSearch() wird aus der Anpassung herausgenommen, da dessenaquivalenter Code bereits vor der Fallunterscheidung abgearbeitet wurde.

• Der BioseqBlastEngineCore()-Code, der nach dem do_the_blast_run()-Aufrufausgefuhrt wird, andert sich bei der Anpassung dahingehend, dass die Falle, die furblastall nicht relevant gewesen waren, hier ebenfalls wegfallen.

6.2.4.3 Der FETCH -Aufruf von udfblast

Der FETCH-Aufruf dient dazu, die SeqAlign-Liste auszuwerten und bei jedem Aufruf einAlignierungstupel zu liefern. Der Aufbau der SeqAlign-Struktur wurde bereits ausfuhrlichim Abschnitt 4.6 erlautert. Deshalb werden an dieser Stelle lediglich die neu eingefuhrtenFunktionen und ihr Zusammenspiel im FETCH-Aufruf (Abbildung 6.6) beleuchtet. Dieaufgerufenen Funktionen haben folgende Aufgaben:

• getScoresFromSeqAlign() ist eine vom Alignmenttyp unabhangige Funktion, dieaus einer Score-Struktur die verschiedenen alignment-Bewertungen ausliest. Ergeb-

77


nis dieses Aufrufs ist die Belegung der UDF-Ruckgabewerte score, bitScore undexpectValue.

• getAlignScalarsFromDD() ermittelt die folgenden UDF-Ruckgabewerte aus einerDenseDiag-Alignierung:

1. alignLength

2. queryOffset und subjectOffset

3. queryLength und subjectLength

4. queryFrame und subjectFrame

Fur die Alignmenttypen DenseSeg und StdSeg werden entsprechende Funktionenimplementiert (getAlignScalarsFromDS() und getAlignScalarsFromSS()).

• getAuxAlignStringsFromDD() ermittelt fur den Typ DenseDiag die Zeichenkettenfur Anfrage- und Vergleichssequenz, die an der Alignierung beteiligt sind. Die Ergeb-nisse sind allerdings noch kodiert, da sie in der nachfolgenden Funktion zur Berech-nung weiterer Werte verwendet werden. Fur DenseSeg und StdSeg werden entspre-chende Funktion implementiert.

• compileResidueStatsAndTransStr() berechnet aus den kodierten Zeichenketten diefolgenden UDF-Ruckgabewerte:

1. queryString und subjectString

2. transitString

3. identPairs, positivePairs und gaps

Der Ablauf ist fur alle Alignierungstypen gleich mit dem Unterschied, dass die jeweilszum Datentyp passenden Funktionen aufgerufen werden. Die Traversierung zur nachstenAlignierung hangt von den Elementen type und segtype des aktuellen SeqAlign-Listenele-ments ab. Zeiger auf das erste und das aktuelle Element der SeqAlign-Liste sind Teil desscratchpads, da sie die Information von einem FETCH-Aufruf zum nachsten weitergeben.

6.2.4.4 Der CLOSE-Aufruf von udfblast

Im CLOSE-Aufruf werden diejenigen Ressourcen wieder freigegeben bzw. zuruckgesetzt,die bei OPEN reserviert und initialisiert wurden. CLOSE besteht aus folgenden Schritten:

1. Rucksetzen des Elements result_struct aus der BlastSearchBlk-StrukturWahrend des Ausfuhrung der ..._blast_search()-Funktionen wird diese Variablezur Zwischenspeicherung von Alignierungen verwendet. Da calcblast() fur jede Se-quenz neu aufgerufen wird, mussen die Speicherbereiche jedesmal freigegeben werden.

2. Freigabe der Ubersetzungen der VergleichssequenzDie Feldelemente der Variablen subjSeqsTransl geben ihren Speicherplatz frei.

3. Freigabe aller Elemente der SeqAlign-ListeDa der Nachbearbeitungsschritt fur jede Vergleichssequenz erneut aufgerufen wird,muss die SeqAlign-Listenstruktur an dieser Stelle freigegeben werden.

78


6.2.4.5 Der FINAL-Aufruf von udfblast

Der FINAL-Aufruf dient der Freigabe von Ressourcen, die in allen Zwischenaufrufen derUDF verwendet wurden. Im wesentlichen sind dies die Strukturen BlastSearchBlk undBLAST_OptionsBlk. Nach dem FINAL-Aufruf werden von der UDF oder dem scratchpadkeine Ressourcen mehr verwaltet.

6.2.5 Die konkrete Umsetzung von udfblast

Neben den hier beschriebenen Anderungen zur Anpassung enthalt Anhang C.4 noch weitereDetails, die zur Lauffahigkeit der UDF notwendig sind.

Basis der udfblast-Implementation ist die Quelltextdatei udfblast.c, die die neuen Funk-tionen beherbergt:

• calcBlast()

• getScoresFromSeqAlign()

• compileResidueStatsAndTransStr()

• getAlignScalarsFromDD()

• getAuxAlignStringsFromDD()

• getAlignScalarsFromDS()

• getAuxAlignStringsFromDS()

• getAlignScalarsFromSS()

• getAuxAlignStringsFromSS()

• die UDF UDF_blast()

Die Funktionsschnittstellen und die globalen Variablendeklarationen werden durch die Dateiudfblast.h exportiert. Aus diesem Grund muss diese Datei per #include in die Dateienblast.c und readdb.c eingebunden sein.

In den vorangegangenen Abschnitten wurden einige Modifikationen an BLAST-Funk-tionen vorgenommen. Mit dem Programmcode wird wie folgt verfahren:

• Wird neuer Programmcode in den Quelltext eingefugt, so geschieht dies mittels einerPraprozessor-Definitionsabfrage namens UDFBLAST. Programmcode, welcher zwischeneiner der Praprozessor-Direktiven #ifdef UDFBLAST oder #ifdef DB2BLAST und demdazugehorigen #endif steht, gehort zu udfblast.

• Wird alter Programmcode im Quelltext durch neuen ersetzt, so wird nach dem neuenProgrammcode ein #else eingefugt. Der neue Programmcode endet vor der #else-Direktive, der alte Programmcode vor der #endif-Direktive.

Um UDFs verwenden zu konnen, mussen sie Teil einer dynamischen Funktionsbibliothek(shared library) sein. Diese wird im Verzeichnis der DB2-Instanz im Unterverzeichnis/sqllib/function/ abgelegt. Am Beispiel des cc-Compilers von SUN sollen die Optionenerlautert werden, die zur Erzeugung von udfblast benotigt werden:

79


1. Zur Ubersetzung von Quelltextdateien fur eine dynamische Bibliothek muss beim cc-Compiler die Option -Kpic angegeben werden. Diese sorgt fur die Erzeugung vonpositionsunabhangigem Code. Damit kann dieser von einer beliebigen Anwendungdynamisch gebunden und aufgerufen werden. Die Anzahl Funktionen, die mit derOption -Kpic ubersetzt werden kann, ist allerdings begrenzt (in der verwendetenUmgebung 2048). udfblast enthalt insgesamt uber 7000 Funktionen. Es genugt,diejenige Datei mit -Kpic zu ubersetzen, die die benutzerdefinierte Funktion enthalt,also udfblast.c.

2. Es mussen zwei Praprozessordefinitionen gesetzt werden:-DDB2BLAST-DUDFBLAST

3. Fur das Binden der ubersetzten Objektdateien zu einer dynamischen Bibliothek mussdie Option -G verwendet werden.

4. Um die Anzahl der globalen Symbole zu reduzieren, wird die Option -M <mapfile>gesetzt. <mapfile> ist eine Datei, die angibt, welche Funktionen in der globalenSymboltabelle stehen sollen. Im vorliegenden Fall betrifft dies nur die FunktionUDF_blast(), die als UDF verwendet werden soll.

5. Es mussen die Bibliotheken db2 und db2apie als Optionen ubergeben werden, umeine UDF-Bibliothek zu erzeugen.

6.2.6 Verwendung von udfblast

In diesem Abschnitt wird ein Beispiel fur den Einsatz von udfblast gegeben. Zu beach-ten ist, dass der einzige variable UDF-Parameter innerhalb der SELECT-Anweisung dieVergleichssequenz subjSequence sein darf. Desweiteren werden bei der Initialisierung derUDF einige Kennwerte ubergeben, die vorher ermittelt werden mussen.

Folgendes SQL-Skript demonstriert die Anwendung der UDF:

DECLARE GLOBAL TEMPORARY TABLE seq_stats

(count INTEGER, totLen INTEGER, maxLen INTEGER)

NOT LOGGED

IN usertemptabspace

ON COMMIT PRESERVE ROWS

WITH REPLACE;

INSERT INTO session.seq_stats

SELECT COUNT(*), SUM(LENGTH(seqtext)), MAX(LENGTH(seqtext))

FROM sequences.protein;

SELECT SeqT.proteinid,

<all attributes from FctT>

FROM sequences.protein as SeqT,

session.seq_stats as StatT,

table( sequences.blast(

’blastp’,

<query sequence>

<further blast options>

80


StatT.count,

StatT.totLen,

StatT.maxLen,

SeqT.seqtext

) ) as FctT;

Dazu mussen einige Bemerkungen gemacht werden:

1. Die Kennwerte der BLAST-Suche werden vor dem ersten Aufruf bestimmt und ineiner temporaren Tabelle abgespeichert. Eine solche Tabelle muss in einem benutzer-definierten, temporaren Tabellenbereiche (USER TEMPORARY SPACE ) abgelegtwerden. Dieser wird zweckmaßigerweise bei der Initialisierung der Datenbank ange-legt. Das Schema einer solchen Tabelle ist, sofern nicht anders angegeben, session.

2. Die Kennwerte der BLAST-Suche erhalt man mittels der Anweisung

SELECT COUNT(*), SUM(LENGTH(seqtext)), MAX(LENGTH(seqtext)) FROM ...

Dabei ist zu beachten, dass genau der gleiche Suchraum benutzt wird wie in dernachfolgenden SQL-Anweisung mit UDF-Aufruf. Das Ergebnis dieser Anweisung istgenau ein Tupel, das in der temporaren Tabelle abgelegt wird (INSERT INTO).

3. Die SELECT-Anweisung sollte neben allen Attributen der Tabellenfunktion auch dieID der jeweiligen Vergleichssequenz zuruckgeben, damit jede Alignierung einer Se-quenz zuordenbar ist.

4. Die Tabellenfunktion wird extern fur jede Vergleichssequenz einmal aufgerufen, da dietemporare Tabelle session.seq_stats nur ein Tupel besitzt. Damit ist die Bedin-gung erfullt, dass der Parameter subjSequence der einzig variable wahrend der SQL-Anweisung ist. Jeder dieser Aufrufe liefert eine Tabelle von Alignierungen zuruck, dievon der Anweisung zu einer gemeinsamen Tabellen vereinigt werden.

5. Die Parameter <query sequence> und <further blast options> mussen konstantsein und durfen von keiner der anderen beiden Tabellen in der FROM-Klausel abhangen.

Das Ergebnis der letzten Anweisung ist eine Liste aller Alignierungen der ubergebenenAnfragesequenz mit allen Vergleichssequenzen. Mittels einer WHERE-Bedingung oder einerverschachtelten SQL-Anweisung konnten weitere Einschrankungen des Suchraums gemachtwerden. Dabei ist zu beachten, dass die gleichen Einschrankungen bei der Ermittlung derdrei Kennwerte count, totLen und maxLen gemacht werden. Ist das SQL-Skript beendet,wird auch die temporare Tabelle wieder freigegeben. Die temporare Tabelle ist sitzungslo-kal, wird also von anderen Anwendungen oder Skripten nicht ”gesehen”.

81

Kapitel 7

Ausblick

BLAST ist ein approximativer Algorithmus zur Bestimmung von Alignierungen jeweilszweier Sequenzen. Dazu wird eine Anfragesequenz mit einer Menge von Vergleichssequenzenaligniert. Die Vergleichssequenzen sind als Datei gespeichert.

Im Rahmen dieser Diplomarbeit wurden zwei Anpassung vorgestellt, die den Algorith-mus in ein relationales Datenbanksystem integriert. Die erste Anpassung hat die Integrationmittels der Programmierschnittstelle Call Level Interface implementiert. Folgende Erwei-terungen werden fur die CLI-Modifikation vorgeschlagen:

1. Im Originalprogramm blastall sind die Sequenzen mit Kennungen gespeichert, dieAuskunft uber die Herkunft der Sequenzen gibt. Im Datenmodell der Genomdaten-bank (siehe Anhang D) sind ebenfalls Informationen gespeichert, die die Sequenzher-kunft festlegen. Diese Informationen konnten durch spezielle SQL-Anweisungen eben-falls ausgewertet werden, so dass sie im BLAST-Report dargestellt werden konnen.

2. Im Programm db2blast mussen die Vergleichssequenzen bei jedem Aufruf des Pro-gramms kodiert werden, da sie in den Datenbankrelationen ”im Klartext” abgelegtsind. Um die Kodierung nicht in jedem BLAST-Lauf durchfuhren zu mussen, bietetes sich an, die Sequenzen aus den Relationen PROTEIN und NASEQUENCE nur einmalzu kodieren und die so modifizierten Sequenzen in speziellen Relationen abzulegen.Fur die Kodierung konnte eine externe skalare UDF implementiert werden.

3. Die Laufzeiten von db2blast bestehen zu einem wesentlichen Teil aus der Datenbank-zugriffszeit. Zu dessen Minimierung konnen Konzepte zum Zugriff auf die entspre-chenden Relationen verwendet werden, wie z.B. die Partitionierung der Datenbank.

4. db2blast hat keine hohere Flexibilitat als blastall. Wie das Original durchsucht auchdb2blast alle Vergleichssequenzen. Dazu werden fest implementierte SQL-Anweisun-gen verwendet. Das Programm konnte eine hohere Flexibilitat erfahren, indem ihmbeispielsweise eine WHERE-Klausel als Parameter ubergeben wird. Die WHERE-Klausel wurde dazu dienen, den Suchraum einzuschranken.

Die zweite Anpassung bestand in der Implementation von blastall als benutzerdefinierteFunktion. Fur die UDF werden folgende Erweiterungen vorgeschlagen:

82

KAPITEL 7. AUSBLICK

1. Das Paradigma der verschiedenen Aufruftypen sorgt dafur, dass bei jedem Aufruf ei-ner UDF die gleichen Parameter ubergeben werden. Bei udfblast werden die BLAST-Parameter nur fur den FIRST-Aufruf benotigt. Die OPEN-Aufrufe benotigen ledig-lich die jeweilige Vergleichssequenzen. Zur Verbesserung der Ausfuhrungsgeschwin-digkeit bote sich deshalb die Implementation von BLAST mit Hilfe von drei UDFsan. Die Funktionen implementieren folgende Schritte von BLAST:

• Die erste Funktion (”init”) fuhrt die Initialisierung von BLAST aus. DieseFunktion wurde den FIRST-Aufruf der ursprunglichen Funktion ersetzen. Siebenotigt die BLAST-Parameter und liefert eine Referenz auf die Initialisierungs-strukturen zuruck.

• Die Referenz der ersten Funktion wird der zweiten Funktion (”calc”) ubergeben.Diese Funktion erhalt zusatzlich die jeweilige Vergleichssequenz. Sie implemen-tiert die Schritte OPEN, FETCH und CLOSE der ursprunglichen UDF und hatdie Alignierungen als Ruckgabewerte.

• Die dritte Funktion (”destruct”) erhalt ebenfalls die Ruckgabereferenz der erstenFunktion und implementiert den FINAL-Schritt der ursprunglichen UDF.

Die Implementation dient dazu, die Laufzeit eines BLAST-Laufs dadurch zu ver-bessern, dass nicht bei jedem Aufruf die gesamte Menge der Parameter ubergebenwird. Voraussetzung ist, dass die drei Funktionen als NOT FENCED deklariert werden,damit sie im Betriebssystem-Prozess ausgefuhrt werden und damit die Datenstruktur-Referenz zwischen den Aufrufen gultig bleibt.

2. Einige Parameter der UDF konnten direkter ubergeben werden. Folgende Parametersind davon betroffen:

• Die Parameter matrixFilePath und matrixName spezifizieren eine Datei, diedie Bewertungsmatrix enthalt. Um die UDF enger in das Datenbanksystemzu integrieren, konnte das Datenmodell dahingehend erweitert werden, dass dieBewertungsmatrizen in einer speziellen Relation als Large Objects (LOBs) ge-speichert werden. Sie konnen dann auch der UDf als LOBs ubergeben werden.

• Die Parameter fur die genetischen Codes sind Zahlen, die einen bestimmten Codereprasentieren (vergleiche Anhang A.1). Fur die genetischen Codes existiertim Datenmodell bereits eine Relation. Deshalb konnten diese direkt an dasProgramm ubergeben werden.

Die beiden Anpassungen stellen zwei Extreme der Anpassung dar: In einem Fall werdenuber einfachste SQL-Anweisungen die Vergleichssequenzen aus der Datenbank entnom-men, um sie in einem vollstandig externen Programm zu verwenden. Im zweiten Fall wirddas komplette Programm als eine benutzerdefinierte Funktion implementiert, die jeweilseine Anfrage- mit einer Vergleichssequenz aligniert. Beide Varianten belassen die BLAST-Schritte in ihrem funktionalen Zusammenhang. Als Erweiterung ware es allerdings denk-bar, die einzelnen Schritte von BLAST getrennt, d.h. in eigenen UDFs, zu implementieren,und diese dann uber SQL-Anweisungen zu verknupfen. Dies bietet dem Datenbankmana-gementsystem die Moglichkeit, mehr Einfluss auf den den Ablauf auszuuben und diesendamit aus Datenbanksicht zu optimieren.

83

Anhang A

blastall-Kommandozeilenoptionen

Parameter Name Typ Bedeutung-p Programmvariante string mogliche Werte sind:

blastpblastnblastxtblastntblastx

-d Datenbankname string Name der Datenbankdatei(en) (z.B. ecoli.aa).Hier konnen auch Aliasdatenbanken angegebenwerden.

-i Anfragesequenzdatei string Dateiname der AnfragesequenzStandard : stdin

-o BLAST-Report-Datei string Dateiname des BLAST-ReportsStandard : stdout

-e Erwartungswert double Fur den Nominalwert jedes Sequenzalignmentswird ein Erwartungswert berechnet. Sequenzen,deren ”beste” Alignierung einen kleineren Erwar-tungswert hat als der hier angegebene Wert, wer-den mit ihren Alignierungen im BLAST-Reportausgegeben.Standard : 10.0

-F Anfrage filtern T/F Soll die Anfragesequenz gefiltert werden?blastn = DUST (T = ja, F = nein)andere = SEG Standard : T

-g gapped alignments T/F Sollen luckenbehaftete Alignierungen gebildetwerden? (nicht fur tblastx)(T = ja, F = nein)Standard : T

-q Nukleotid-mismatch int Kosten fur alignierte, nicht-identische Residuen(nur blastn)Standard : -3

-r Nukleotid-match int Wert fur alignierte, identische Residuen (nurblastn)Standard : 1

-M Matrix string Bewertungsmatrix fur ProteinalignierungenStandard : BLOSUM62

84

ANHANG A. BLASTALL-KOMMANDOZEILENOPTIONEN

-G Wert Lucke-Offnen int Kosten, im Alignment eine Lucke zu offnen (0 be-deutet Standardverhalten). Standard : 0

-E Wert Lucke-Erweitern int Kosten, im Alignment eine Lucke zu erweitern (0bedeutet Standardverhalten). Standard : 0

-W Wortgroße int Vor der Expansion werden Hits dieser Lange inder Vergleichssequenz gesucht (0 bedeutet Stan-dardverhalten). Standard : 0

-f Hit-Expansionsschwelle int Ein w-mer der Lange -W hat mindestens diesenWert mit einem Teilwort der Anfragesequenz. (0bedeutet Standardverhalten)Standard : 0

-Q gen.Code Anfrage int Genetischer Code fur die Ubersetzung der An-fragesequenz (nur blastx und tblastx). Uber diemoglichen Werte gibt der nachste Abschnitt Aus-kunft. Standard : 1

-D gen.Code DB int Genetischer Code, der fur die Ubersetzung jederVergleichssequenz wird (nur tblastn und tblastx).Die moglichen Werte konnen dem folgenden Ab-schnitt entnommen werden.Standard : 1

-P int 0 = 1-Pass, mehrere benachbarte Hits fur Expan-sion benotigt (Standard)1 = 1-Pass, ein Hit fur Expansion genugt2 = 2-Pass

-S Leserichtungen Anfrage int Leserichtungen der Anfragesequenz, die bearbei-tet werden sollen (nur blastn, blastx und tblastx).1 = positive Leserichtung2 = negative Leserichtung3 = beide (Standard)

-y dropoff double Wert, um den die aktuelle Erweiterung kleinerist als der wahrend dieser Erweiterung gefundenemaximale Wert (0.0 bedeutet Standardverhalten).Standard : 0.0

-X dropoff gapped int wie -y, fur angehangte luckenbehaftete Alignie-rungen (0 bedeutet Standardverhalten).Standard : 0

-Z dropoff gapped final int wie -y, allerdings wahrend der luckenbehafte-ten Alignierung (0 bedeutet Standardverhalten).Standard : 0

-U Kleinbuchstabenfilter T/F Ist diese Option gesetzt (T), dann werden Klein-buchstaben in der Anfragesequenz als Regio-nen geringer Komplexitat betrachtet und entspre-chend vom Vorfilter (SEG) behandelt. Sie konnenals keine Hits bilden, werden in der spateren Ex-pansion aber wieder als normale Residuen be-trachtet. Standard : F

-z Effektive DB-Lange int Gibt die effektive Große der Datenbank als AnzahlResiduen an. 0 bedeutet die tatsachliche Große.Standard : 0

85


-Y Effektive Suchraumgroße int Gibt die effektive Große des Suchraums als AnzahlResiduen an. 0 bedeutet die tatsachliche Große.Standard : 0

-K culling int Anzahl der besten hits einer Region, die als Ergeb-nis bleiben. Falls mehr als -K HSPs einen Hit inder gleichen Region haben, werden die ”schlech-teren” aus dem Ergebnis genommen. Falls derParameter verwendet werden soll, wird 100 emp-fohlen. 0 bedeutet, daß der Parameter nicht ver-wendet wird.Standard : 0 (bedeutet AUS)

-I GI’s im BLAST-Report string Die Kennung einer Sequenz besteht aus mehrerenKomponenten. Eine ist meist die GI-ID. Wenndiese im BLAST-Report neben den anderen IDserscheinen soll, muß hier T ubergeben werden,sonst F. Standard : F

-l GI-Datei string Dieser Parameter zeigt auf eine Datei, in der proZeile eine GI-ID steht. In BLAST werden dannnur die Vergleichssequenzen mit diesen GI-IDsverwendet.

-m BLAST-Report-Ausgabe int Darstellung der Alignierungen im BLAST-Report.Standard : 0 (paarweise Darstellung)

-v #DB-Seq.-Beschreibung int Anzahl Vergleichssequenzen, fur die deren Ali-gnmentbewertung im BLAST-Report ausgegebenwerden. Standard : 500

-b #DB-Seq.-Alignments int Anzahl Vergleichssequenzen, fur die die konkretenAlignments im BLAST-Report ausgegeben wer-den. Standard : 250

-T HTML-Ausgabe T/F Ist die Option gesetzt (T), wird ein BLAST-HTML-Report erstellt. Standard : F

-J korrekte Anfragekennung T/F Ist die Option gesetzt, so wird die Kennung derAnfragesequenz, die in der FASTA-Datei steht, alskorrekte Kennung anerkannt. Diese Option ist furdie folgende Option von Bedeutung. Standard : F

-O SeqAlign-Datei string Die Alignierungen konnen ASN.1-kodiert in eineDatei geschrieben werden. Dazu muß die Option-J auf ”T” gesetzt sein.

-a Anzahl Prozessoren int Da BLAST multithreadingfahig ist, kann hier dieAnzahl zu verwendender Prozessoren ubergebenwerden. Standard : 1

86


A.1 Genetische Codetabellen

Folgende Tabelle stellt die verschiedenen genetischen Codes dar. Die Nummer wird bei denblastall -Optionen -Q und -D angegeben.

Nummer Name1 Standard2 Vertebrate Mitochondrial3 Yeast Mitochondrial4 Mold Mitochondrial, Protozoan Mitochondrial, Coelenterate Mitochondrial,

Mycoplasma, Spiroplasma5 Invertebrate Mitochondrial6 Ciliate Nuclear, Dasycladacean Nuclear, Hexamita Nuclear9 Echinoderm Mitochondrial

10 Euplotid Nuclear11 Bacterial12 Alternative Yeast13 Ascidian Mitochondrial14 Flatworm Mitochondrial15 Blepharisma Macronuclear16 Chlorophycean Mitochondrial21 Trematode Mitochondrial22 TAG-Leu, TCA-Stop23 Thraustochytrium mitochondrial code

87

Anhang B

Aufbau der BLAST-Reportdateien

Sowohl im ursprunglichen BLAST -Programm als auch in der modifizierten Version werdeneinige Dateiformate verwendet, deren Aufbau Gegenstand dieses Anhangs sein soll.

B.1 Das FASTA-Format

Das FASTA-Dateiformat wurde vom Alignment-Algorithmus FASTA [27] eingefuhrt undetabliert. Im BLAST-Kontext wird es von ”Datenbank”-Dateien verwendet und dientBLAST als Eingabeformat, welches vom Programm FormatDB gelesen und fur die Be-nutzung durch BLAST formatiert wird.

Das FASTA-Format ist ASCII-lesbar und wird zeilenweise bearbeitet. Jeweils zwei auf-einanderfolgende Zeilen spezifizieren eine Biosequenz. In der ersten Zeile steht die Kennungder Sequenz, in der zweiten die Sequenz selbst. Eine FASTA-Datei hat demnach folgendesAussehen:

1. Zeile: >[Kennung von Sequenz 1]

2. Zeile: [Sequenz 1]

3. Zeile: >[Kennung von Sequenz 2]

4. Zeile: [Sequenz 2]

usf.

Die Sequenzen sind Buchstabenfolgen, d.h. es werden die Alphabete der Tabellen 2.2fur Nukleinsaure-Residuen und 2.3 fur Aminosaure-Residuen verwendet. Fur Nukleinsaurenist zu beachten, daß das Zeichen ”X” fur das entsprechende Mehrdeutigkeitsresiduum nichterlaubt ist, hier muß stattdessen ”N” benutzt werden, ansonsten werden die ”X”e aus denSequenzen geloscht.

B.2 FormatDB-Ausgabedateien

Nach der Formatierung einer FASTA-Datenbank-Datei mit FormatDB entstehen drei Da-teien, die die Eingabe fur BLAST bilden. Die folgenden Unterabschnitte beschreiben dieseDateitypen.

88

ANHANG B. AUFBAU DER BLAST-REPORTDATEIEN

Abbildung B.1: Zusammenhang der von FormatDB formatierten Dateien

B.2.1 Die FormatDB-Kennungendatei

In dieser Datei werden die Kennungen der Sequenzen aus der FASTA-Datei abgelegt. JederEintrag bezieht sich auf eine Sequenz. Sei y die Kennunge der x. Sequenz (wobei x bei 0beginnt), so ist der Kennungseintrag dieser Sequenz

gnl|BL_ORD_ID|x y.

Die Eintrage stehen hintereinander in der Datei, es gibt keine Trennungszeichen und keineZeilenumbruche. Um einen Eintrag zu lesen, muß zuvor auf die entsprechende Index-Dateizugegriffen werden (siehe dazu Abschnitt B.2.3). Die Reihenfolge der Kennungseintrage indieser Datei entspricht der Sequenz-Reihenfolge in der FASTA-Datei.

B.2.2 Die FormatDB-Sequenzdatei

In dieser Datei werden die Sequenzen aus der FASTA-Datei abgelegt. Die Sequenzen sindallerdings nicht im ASCII-Format abgelegt, sondern werden vor der Speicherung in dieseDatei kodiert. Zur Kodierung sei auf Abschnitt 4.3.1 verwiesen. Die kodierten Sequen-zen stehen hintereinander und sind nicht durch spezielle Trennungszeichen oder Zeilenum-bruche separiert. Um einen Eintrag zu lesen, muß zuvor auf die entsprechende Index-Dateizugegriffen werden (siehe dazu folgenden Abschnitt). Die Reihenfolge der Sequenzeintrageentspricht der Sequenz-Reihenfolge in der FASTA-Datei.

89


B.2.3 Die FormatDB-Indexdatei

Diese Datei enthalt Datenbankkennwerte sowie Dateizeiger-Indizes auf die Kennungs- unddie Sequenz-Dateien (Abbildung B.1). Wie diese beiden Dateien ist auch die Index-Datei ei-ne Binardatei. Die folgende Tabelle zahlt zunachst die Kennwerte und ihren Speicherbedarfin der Datei auf. Die Kennwerte stehen in ebendieser Reihenfolge in der Datei.

Lange Datentyp Beschreibung4 Bytes Integer FormatDB-Versionsnummer4 Bytes Integer Art der Sequenzen

(0 = Nukleotid, 1 = Protein)4 Bytes Integer Lange des Titels (n)n Bytes String Titel der Datenbank4 Bytes Integer Lange des Erstellungsdatums (m)

m Bytes String Erstellungszeitpunkt der Datenbank durch FormatDB4 Bytes Integer Anzahl Sequenzen (k)4 Bytes Integer Lange der Datenbank (Anzahl Residuen)4 Bytes Integer Lange der langsten Sequenz

Darauf folgen k + 1 Dateizeigereintrage in die zugehorige Kennungsdatei (im FolgendenIDZeiger). Die ersten k Eintrage zeigen auf die Kennungen der k Sequenzen, der (k + 1)-te Eintrag zeigt hinter die Kennung der letzten Sequenz. Die Lange der Kennung der i-tenSequenz kann demnach mit der Formel IDZeiger[i + 1] − IDZeiger[i] berechnet werden.Jeder Zeiger-Eintrag ist ein Integerwert von vier Byte Große.

Auf die Zeiger in die Kennungsdatei folgen die Dateizeigereintrage in die Sequenz-Datei(im Folgenden SeqZeiger). Dies sind ebenfalls k + 1 Eintrage, welche auf die Sequenzenselbst zeigen. Der (k + 1)-te Eintrag zeigt hinter die letzte Sequenz. Die Lange der (ko-dierten) Sequenz kann somit nach der Formel SeqZeiger[i + 1] − SeqZeiger[i] berechnetwerden. Jeder Zeiger-Eintrag ist ein Integerwert von vier Byte Große.

Falls in der ”Datenbank” Nukleotid-Sequenzen gespeichert sind, folgt ein weiterer Blockvon Dateizeigereintragen, welche ebenfalls in die Sequenz-Datei zeigen (AmbZeiger). Sol-che Sequenzen konnen sogenannte Mehrdeutigkeitsresiduen enthalten, also solche, die furmehrere Elementarresiduen (vergleiche Tabelle 2.2) stehen konnen. Eine Nukleotid-Sequenzist daher zweigeteilt kodiert. Diese Kodierungen sind in Abschnitt 4.3.2 erklart. Der zweiteTeil, die Mehrdeutigkeitskodierung, wird mit diesen AmbZeigern referenziert. Auch hiergibt es k + 1 Eintrage. Mit der Formel SeqZeiger[i + 1] − AmbZeiger[i] kann die Langeder Mehrdeutigkeitskodierung der Sequenz i bestimmt werden; ist diese 0, dann besitzt dieSequenz nur eindeutige Residuen. Jeder Zeiger-Eintrag ist ein Integerwert von vier Byte.

An dieser Stelle sei darauf hingewiesen, daß die Integerwerte in dieser Datei als BigEndian gespeichert sind. Das bedeutet, daß das hochstwertige Byte zuerst gespeichert istund das niedrigstwertige zuletzt. Liest man, wie hier notig, einen 4-Byte-Wert aus einerDatei, so wird normalerweise das erste gelesene Byte als niedrigstwertiges und das vierteByte als hochstwertiges Byte interpretiert (Little Endian). Folglich muß jeder 4-Byte-Wertnach dem Lesen byteweise gedreht werden.

90


B.2.4 readdb-Kennwertefunktionen

Die Dateien der vorangegangenen Unterabschnitte werden von readdb_new_internal()gelesen. Insbesondere die Indexdatei-Kennwerte dienen der ReadDBFILE-Initialisierung. Diefolgenden readdb-Funktionen liefern die Kennwerte fur eine oder mehrere Datenbank(en):

• readdb_get_dblen() – Gesamtlange aller Sequenzen (Anzahl Residuen)

• readdb_get_totals_ex() – liefert Gesamtlange aller Sequenzen und deren Anzahl

• readdb_get_totals() – wie readdb_get_totals_ex(), berucksichtigt keine Alias-Datenbanken

• readdb_get_num_entries_total() – Anzahl der Sequenzen aller Datenbanken inder verketteten ReadDBFILE-Liste

• readdb_get_num_entries_total_real() – wie readdb_get_num_entries_total(),berucksichtigt keine virtuellen Datenbanken

• readdb_get_num_entries() – Anzahl der Sequenzen der Datenbank, welche zurubergebenen ReadDBFILE-Struktur gehort

• readdb_get_maxlen() – Lange der langsten Sequenz

• readdb_get_filename() – Dateiname der Datenbank

• readdb_get_title() – Titel der Datenbank

• readdb_get_date() – Erstellungsdatum der Datenbank-Datei

• readdb_is_prot() – TRUE, falls Datenbank Proteinsequenzen enthalt, FALSE, sonst

• readdb_get_formatdb_version() – Versionsnummer von FormatDB, welches dieDatenbankdatei formatiert hat

B.3 BLAST-Reportdateien

Dieser Abschnitt beschreibt das Aussehen des BLAST-Reports, wenn blastall mit derStandard-Ausgabeoption -m 0 aufgerufen wird. Ein BLAST-Report (Abbildung B.2) be-steht aus drei Arten von Informationen:

1. einer Vergleichssequenz zuordenbare Informationen

2. einer Alignierung zuordenbare Informationen

3. dem BLAST-Lauf zuordenbare Informationen

Die einer Vergleichssequenz zuordenbaren Informationen stellen eine Zusammenfassung derAlignierungen dar. Jede Sequenz, die relevante Alignierungen gebilet hat, wird in einerListe dargestellt. Die Reihenfolge der Sequenzen wird dabei durch den Erwartungswertvon deren jeweils ”bester” Alignierung bestimmt: je kleiner der Erwartungswert, desto

91


[...]

Query= TestProtein

(8192 letters)

Database: DNA

1407 sequences; 1,551,788 total letters

Score E

Sequences producing significant alignments: (bits) Value

[... ERSTER TEIL ...]

lcl|480001170 43 4e-004

[... ZWEITER TEIL ...]

>lcl|480001170

Length = 3524

Score = 32.1 bits (71), Expect = 0.90

Identities = 20/84 (23%), Positives = 43/84 (50%), Gaps = 7/84 (8%)

Frame = +3

Query: 7521 QQKANEVEQMIRDLEASIARYKEEYAVLISEAQAIKADLAAVEAKV--NRSTA-----LL 7573

++ +N + + I++LE+ + K + L++E +K LA + + + S+A +

Sbjct: 75 KENSNTLSEQIKNLESELNSSKIKNESLLNERNLLKEMLATSRSSILSHNSSAGNIDDKM 254

Query: 7574 KSLSAERERWEKTSETFKNQMSTI 7597

KS+ EK E ++N+M+ I

Sbjct: 255 KSIDESTRELEKNYEVYRNEMTAI 326

[... DRITTER TEIL ...]

Database: DNA

Posted date: 20.1.2002, 18:24:28

Number of letters in database: 1,551,788

Number of sequences in database: 1407

Lambda K H

0.319 0.135 0.392

Gapped

Lambda K H

0.270 0.0470 0.230

Matrix: BLOSUM62

Gap Penalties: Existence: 11, Extension: 1

Number of Hits to DB: 13760138

[...]

Abbildung B.2: Aufbau der einzelnen Abschnitte des BLAST-Reports am Beispiel einesluckenbehafteten tblastn-Laufs

92


weiter oben in der Liste. Jede Zeile der Liste enthalt die Kennung einer Sequenz, dennormalisierten Wert und den Erwartungswert von deren ”bester” Alignierung.

Daran schließen sich die Alignierungsinformationen an. Der Liste der Alignierungengehen die Zeilen

>xLength = y

voraus, die die Kennung (x) und die Lange (y) der Vergleichssequenz enthalten. JedeAlignierung wird dabei durch die folgenden Informationen beschrieben:

1. Der mit ”Score” bezeichnete Wert mit der Einheit ”bits” ist die normalisierte Bewer-tung der Alignierung dar.

2. Hinter dem ”bits”-Wert steht in Klammern der nominale Wert der Alignierung.

3. ”Expect” ist die Anzahl der zufallig zu erwartenden Alignierungen mit dem angege-benen normalisierten Wert oder einem besseren.

4. Bei ”Identities: x/y” ist x die Anzahl von identischen Residuenpaaren und y dieLange der Alignierung.

5. Das x in ”Positives: x/y” (wird nicht von blastn verwendet) ist die Anzahl der Resi-duenpaare, die einen positiven Zuordnungswert haben.

6. Bei ”Gaps: x/y” ist x die Anzahl der Lucken in der Alignment. Dieser Wert stehtnur in Reports von luckenbehafteten BLAST-Laufen. Bei blastn und blastp werdendie Lucken in beiden beteiligten Sequenzen gezahlt, bei blastx und tblastn zahlen nurdie Lucken in der Anfragesequenz.

7. Die Angabe von ”Frame: x” steht bei blastx fur das Leseraster der Anfragesequenzund bei tblastn fur das der Vergleichssequenz.

8. Bei tblastx gibt es Angabe ”Frame: x/y”. Sie steht fur die Leseraster der betei-ligten Sequenzen. x steht fur das Leseraster der Anfragesequenz und y fur das derVergleichssequenz.

9. Bei blastn wird die Angabe ”Strands: x/y” gemacht. Sie steht fur die Leserichtungender Sequenzen. x ist die Leserichtung der Anfragesequenz in dieser Alignierung, ydie der Vergleichssequenz. ”Plus” steht fur die positive und ”Minus” fur die negativeLeserichtung.

10. Eine Alignierung, deren Lange mehr als 60 Zeichen betragt, wird zur besseren Les-barkeit im BLAST-Report umgebrochen. Wurde man die einzelnen Stucke wiederzusammenfugen, erhielte man die Alignierung. Die oberste Zeichenkette ist der ali-gnierte Teil der Anfragesequenz, die unterste Zeichenkette der der Vergleichssequenz.Dazwischen steht eine ”Ahnlichkeitszeichenkette”, die Auskunft uber die einzelnenalignierten Zeichen gibt. Steht in diesem string ein Buchstabe, so ist das Residuumin den beiden Sequenz identisch, steht hier ein Plus, so wird das Residuenpaar vonder Bewertungsmatrix positiv bewertet. In blastn wird nur zwischen Leerzeichen und”|” unterschieden. Letzteres steht dort fur identische Residuen.

93


11. Vor und hinter jeder Zeile (maximal 60 Zeichen) der Alignierung stehen Zahlen, dieauf die Position der Alignierung innerhalb der Sequenzen hinweist. Von vorn nachhinten sind die Zahlen aufsteigend, wenn blastp oder in den anderen Varianten einepositive Leserichtung vorliegt, und absteigend, falls die Leserichtung (und damit beiden translatierten Versionen auch das Leseraster) negativ sind.

Nach den Alignierungen folgt der dritte Teil des BLAST-Reports. Dieser gibt einen stati-stischen Uberblick uber den gesamten BLAST-Laufs.

94

Anhang C

UDF-Entwurfsdetails

Dieser Anhang behandelt Details, die bei Entwurf und Implementation der benutzerdefi-nierten Funktion verwendet wurden. Er komplettiert damit sowohl die Analyse als auchdie Umsetzung der UDF-Anpassung.

C.1 Typen von Alignierungen

Im Abschnitt 4.6 wurde der Datentyp StdSeg erlautert, weil er unter den Alignierungstypenderjenige mit der großten Komplexitat ist. Dieser Abschnitt komplettiert lediglich dieAnalyse, indem die beiden anderen Alignierungstypen dargestellt werden.

C.2 DenseDiag-Alignierungen

DenseDiag-Elemente sind die einfachste Form, Alignments zu speichern. Die Strukturhat den in Abbildung C.1 dargestellten Aufbau.

• dim hat die gleiche Bedeutung wie das gleichnamige SeqAlign-Element.

• Das Feld starts besteht aus dim Elementen (hier 2) und enthalt die Start-Offsetsder Alignierung der beiden Sequenzen. Der erste Wert bezeichnet den Offset in derAnfragesequenz, der zweite Wert den in der Datenbank-Vergleichssequenz.

typedef struct dendiag {

short int dim;

SeqId *id;

long int *starts;

long int len;

char *strands;

Score *scores;

struct dendiag *next;

}

DenseDiag, *DenseDiagPtr;

Abbildung C.1: Aufbau der Datenstruktur DenseDiag

95

ANHANG C. UDF-ENTWURFSDETAILS

typedef struct denseg {

short int dim,

numseg;

SeqId *ids;

long int *starts;

long int *lens;

char *strands;

Score *scores;

}

DenseSeg, *DenseSegPtr;

Abbildung C.2: Aufbau der Datenstruktur DenseSeg

• Die Lange der Alignierung ist im Element len gespeichert. Hier genugt fur beidebeteiligten Sequenzen ein gemeinsamer Wert, da DenseDiag nur luckenfreie Alignie-rungen verwendet wird. Folglich haben die beiden Subsequenzen die gleiche Lange inder Alignierung.

• strands ist wie starts ein Feld mit dim Elementen, das die Leserichtungen derbeiden Sequenzen in Alignierung enthalt. Fur blastp sind diese Werte 0. Fur blastnsei auf den Abschnitt ist ein Element 1, falls die positive Leserichtung vorliegt, und2 fur die negative Leserichtung.

• Die Variable scores zeigt auf eine verkettete Score-Liste. Der Aufbau von Scorewird im Abschnitt 4.6.2 erlautert.

Die Verwendung von DenseDiag geht bei BLAST immer mit dem Wert type = 2 ausSeqAlign einher. Deshalb stehen die Alignments einer Sequenz in einer gemeinsamenDenseDiag-Liste. Der hier vorhandene next-Zeiger zeigt auf die nachste Alignierung derVergleichssequenz. Ist keine weitere Alignierung vorhanden, hat next den Wert NULL.

C.3 DenseSeg-Alignierungen

Die Datenstruktur DenseSeg dient der Speicherung luckenbehafteter Alignierungen undwird von blastn und blastp verwendet. Ihr Aufbau ist in Abbildung C.2 dargestellt. dimhat die gleiche Bedeutung wie bei DenseDiag. numseg enthalt die Anzahl der Segmente derAlignierung. Zum Begriff des Segments sei auf den Abschnitt 4.6.1 verwiesen. Die anderenElemente haben folgende Bedeutung:

• starts ist ein Feld mit 2 · numseg Elementen. starts[2*k] ist der Offset des Seg-ments k in der Anfragesequenz, starts[2*k+1] der Offset in der Vergleichssequenz.Besteht fur eine der beiden Sequenzen das Segment aus einer Lucke, so ist der Wertdes entsprechenden start-Feldelements −1.

• len ist ein Feld von numseg Elementen und enthalt die Langen der Segmente.

• strands enthalt wie starts ebenfalls 2 · numseg Elemente. Jedes Segment konntealso pro Sequenz eine eigene Leserichtung besitzen. In der Praxis ist das nicht der

96


Fall. Folglich kann die Leserichtung der beiden Sequenzen aus den Feldelementenstrands[0] und strands[1] ermittelt werden. Zu den Werten dieser Elemente seiauf den vorigen Abschnitt verwiesen.

• Das Feld scores ist hier nicht von Interesse, da der Alignmenttyp DenseSeg beiBLAST immer zusammen mit dem SeqAlign-Elementwert type = 3 auftritt unddeshalb der Score in der SeqAlign-Struktur selbst zu finden ist.

Die weiteren Alignierungen der Vergleichssequenz konnen durch Traversieren der SeqAlign-Liste erreicht werden.

C.4 Weitere Anpassungen der UDF

Damit UDFBLAST einsetzbar ist, mussen neben den im Abschnitt 6.2.4 beschriebenenModifikationen noch weitere Anderungen vorgenommen werden:

1. Einige Funktionen von BLAST sind als static deklariert. Diese sind nur von anderenFunktionen verwendbar, die im gleichen Modul definiert sind. Durch die Ubernah-me von BLAST-Code in den FIRST- oder OPEN-Aufruf werden diese Funktionennun von ”außerhalb” aufgerufen, und durch ihre Deklaration nicht mehr gefunden.Deshalb muss fur folgende Funktionen die Deklaration geandert werden:

• FastaReadSequenceInternalEx()

• BlastReevaluateWithAmbiguities()

• BLASTResultFreeHsp()

2. Einige der von db2blast eingefuhrten Praprozessordirektiven der Art #ifdef DB2BLASTmussen modifiziert werden, da der dort enthaltene Code auf CLI-Typen und -Funk-tionen zuruckgreift. Auch wenn der Code niemals im Rahmen der UDF ausgefuhrtwurde, darf dieser nicht kompiliert werden, weil die CLI-Typen und -Funktionen nichtbekannt sind. Die Direktiven andern sich zu#if defined(DB2BLAST) && !defined(UDFBLAST)

3. In BLASTSetUpSearchWithReadDbInternal() wird die Variable matrixFilePath vonder BLAST_OptionsBlk-Struktur in eine Unterstruktur von BlastSearchBlk kopiert.

4. Die Funktion BlastSaveCurrentHitlist(), welche im Rahmen der BLAST-Alig-nierung ausgefuhrt wird, fugt die Alignierungen einer Vergleichssequenz in das Feldresult_struct->results ein, welches ein Element der BlastSearchBlk-Strukturist. In diesem Feld stehen die Alignierungen der bisher betrachteten Vergleichsse-quenzen. Dieses Feld ist immer nach der Bewertung der Alignments sortiert. Da dieUDF nur eine Vergleichssequenz zu verarbeiten hat, wird die Suche nach dem Ort derEinsortierung in das Feld nicht ausgefuhrt, stattdessen wird immer der Index 0 furdas Feld gesetzt.

5. Die Funktion BlastScoreBlkMatFill() wird dazu verwendet, die Matrix-Datei aus-zulesen. Der Verzeichnispfad, der sich in matrixFilePath befindet, muß vorn an denDateinamen angehangt werden.

97


6. Wahrend der Anpassung von db2blast werden einige Funktionen als kritisch betrach-tet, die auf die Index-Dateien von blastall zugreifen. Diese Funktionen konnten inRahmen von udfblast ebenfalls als kritisch gelten, wenn sie im ”nachste Sequenz”-Kontext oder im ”wahlfreien”-Kontext stehen wurden. Die einzigen Funktionsaufru-fe, die dafur in Frage kommen, sind der von readdb_get_sequence() am Anfang derFunktionen ..._blast_search() sowie der von readdb_get_sequence_length().Der erste Aufruf wird ersetzt durch die explizite Sequenzverarbeitung in calcBlast,und die Verwendung von readdb_get_sequence_length() kann sich nur auf dieaktuelle Sequenz beziehen, da nur diese verarbeitet wird. Die Funktion wird des-halb so modifiziert, dass sie bei udfblast immer den Wert des ReadDBFILE-ElementsseqLength zuruckgibt.

98

Anhang D

Relationales Datenmodell

99

Literaturverzeichnis

[1] Altschul, S. F., W. Gish, W. Miller, E. W. Myers und D. J. Lipman: BasicLocal Alignment Search Tool. Journal of Molecular Biology, 215:403–410, 1990.

[2] Altschul, S. F., T. L. Madden, A. A. Schaffer, J. Zhang, Z. Zhang, W. Mil-ler und D. J. Lipman: Gapped BLAST and PSI-BLAST: a new generation of proteindatabase search programs. Nucleic Acids Research, 25(17):3389–3402, 1997.

[3] Bairoch, A.: The PROSITE dictionary of sites and patterns, its current status.Nucleic Acids Research, 21(13):3097–3103, Juli 1993.

[4] Barton, G. J.: Protein Sequence Alignment and Database Scanning. erschienen in:M. J. E. Sternberg (Hrsg.): Protein Structure Prediction — a practical approach, 1997.

[5] Bellman, R. E.: Dynamic Programming. Princeton University Press, Princeton,N.J., 1957.

[6] Bucher, P. und A. Bairoch: A generalized profile syntax for biomolecular sequencemotifs and its function in automatic sequence interpretation. In: Proceedings of the 2ndInternational Conference on Intelligent Systems for Molecular Biology, Seiten 53–61,Menlo Park, CA, 1994. AAAI Press.

[7] Chamberlin, D. D.: A Complete Guide to DB2 Universal Database. Morgan Kauf-mann Publishers, Inc., San Francisco, California, 1998.

[8] Chamberlin, D. D. und R. F. Boyce: SEQUEL: A Structured English Query Lan-guage. In: Proceedings of the ACM SIGFIDET Workshop on Data Description, Access,and Control, Seiten 249–264, Ann Arbor, MI, Mai 1974. ACM.

[9] Codd, E. F.: A Relational Model of Data for Large Shared Data Banks. Communi-cations of the ACM, 13(6):377–387, Juni 1970.

[10] Cornish-Bowden, A.: Nomenclature for incompletely specified bases in nucleic acidsequences: recommendations 1984. Nucleic Acids Research, 13(9):3021–3030, Mai1985.

[11] Dayhoff, M. O., R. M. Schwartz und B. C. Orcutt: A Model of EvolutionaryChange in Proteins. Atlas of Protein Sequence and Structure, 5(3):345–352, 1978.

[12] Gotoh, O.: An improved algorithm for matching biological sequences. Journal ofMolecular Biology, 162(3):705–708, 1982.

100

LITERATURVERZEICHNIS

[13] Henikoff, S. und J. G. Henikoff: Amino acid substitution matrices from proteinblocks. In: Proceedings of the National Academy of Sciences of the USA, Band 89,Seiten 10915–10919, November 1992.

[14] International Business Machines: IBM DB2 Universal Database: ApplicationDevelopment Guide, 2000.

[15] International Business Machines: IBM DB2 Universal Database: Call LevelInterface Guide And Reference, 2000.

[16] International Business Machines: IBM DB2 Universal Database: SQL Refe-rence, 2000.

[17] International Organization for Standardization: ISO/IEC 9075:1992/: In-formation Technology — Database Language SQL. International Organization for Stan-dardization, Genf, 1992.

[18] International Organization for Standardization: ISO/IEC 9075-3:1995/:Information Technology — Database Languages — SQL — Part3: Call Level Interface(SQL/CLI). International Organization for Standardization, Genf, 1995.

[19] International Organization for Standardization: ISO/IEC 8824-1:1998/:Information Technology — Abstract Syntax Notation One (ASN.1) — Specificationof basic notation. International Organization for Standardization, Genf, Zweite Auf-lage, 1998.

[20] IUPAC-IUB Commission On Biochemical Nomenclature: A one-letter nota-tion for amino-acid sequences, tentative rules. Journal of Biological Chemistry,243:3557–3559, 1968.

[21] Karlin, S. und S. F. Altschul: Methods for assessing the statistical significance ofmolecular sequence features by using general scoring schemes. In: Proceedings of theNational Academy of Sciences of the USA, Band 87, Seiten 2264–2268, 1990.

[22] Lackie, J. M. und J. Dow (Herausgeber): The Dictionary of Cell & MolecularBiology. Academic Press, London, Dritte Auflage, 1999.

[23] Lewin, B.: Genes. Oxford University Press, Oxford, Funfte Auflage, 1994.

[24] Loffler, G. und P. E. Petrides: Biochemie und Pathobiochemie. Springer-Verlag,Berlin Heidelberg New York, Funfte Auflage, 1999.

[25] Needleman, S. B. und C. D. Wunsch: A general method applicable to the search forsimilarities in the amino acid sequence of two proteins. Journal of Molecular Biology,48:443–453, 1970.

[26] Pearson, W. R. und D. J. Lipman: Rapid and sensitive protein similarity searches.Science, 22:1435–1441, Marz 1985.

[27] Pearson, W. R. und D. J. Lipman: Improved tools for biological sequence compari-son. In: Proceedings of the National Academy of Sciences of the USA, Band 85, Seiten2444–2448, 1988.

101

LITERATURVERZEICHNIS

[28] Smith, T. F. und M. S. Waterman: Identification of common molecular subse-quences. Journal of Molecular Biology, 147:195–197, 1981.

[29] Wootton, J. C. und S. Federhen: Statistics of local complexity in amino acidsequences and sequence databases. Computers and Chemistry, 17(2):149–163, 1993.

[30] Zhang, Z., A. A. Schaffer, W. Miller, T. L. Madden, D. J. Lipman, E. V.Koonin und S. F. Altschul: Protein sequence similarity searches using patterns asseeds. Nucleic Acids Research, 26(17):3986–3990, 1998.

102

Danksagungen

Bei der Anfertigung dieser Arbeit haben mir viele Leute mit Rat und Tat zur Seite gestan-den. Zuallererst danke ich Prof. Johann-Christoph Freytag fur die Zuweisung des Themasund wichtige Anregungen und Hinweise. Ferner mochte ich mich bei Chokri Ben Necib furdie Betreuung und die Diskussionen bedanken. Peter Rieger hat mir mit seinen Hinweisenzu benutzerdefinierten Funktionen viel Zeit und Frust bei der Fehlersuche erspart.

Jeannine Rettschlag danke ich fur ihre Einfuhrung in die Biochemie und die Beantwor-tung diesbezuglicher Fragen. Sebastian Marek hat meine drangenden LATEX-Probleme oftmit einer Antwort oder einem \usepackage aus der Welt geschafft. Oliver Bierwagen hatmir ein paar wichtige Tips fur die Prasentation gegeben.

Nicht zuletzt mochte ich meinen Eltern fur die Hinweise, die Stil und Gesamtbild meinerArbeit betreffen, danken.

103

Ich erklare, diese Diplomarbeit selbstandig und nur unter Verwen-dung der angegebenen Literatur und Hilfsmittel angefertigt zu haben.Ich bin mit der Auslage der Arbeit in der Bibliothek der Humboldt-Universitat zu Berlin einverstanden.

Berlin, den 19. Februar 2002

104

diplomarbeit ”anpassung von blast fur genom-datenbanken”¨ · kapitel 2 biologische grundlagen...

Documents