Entwicklung einer Bioinformatik-Datenbank für die Erforschung von Disulfidbindungen

Die Bioinformatik-Datenbank Protein Data Bank (PDB) ist die weltweit größte Sammlung experimentell ermittelter Strukturen von Proteinen, Nukleinsäuren und komplexen Anordnungen. Alle Daten werden mit experimentellen Methoden wie Röntgen, Spektroskopie, Kristallographie, NMR usw. gesammelt.

In diesem Artikel wird erläutert, wie Sie Daten aus der PDB extrahieren, filtern und bereinigen. Dies wiederum ermöglicht die Art der Analyse, die im Artikel Occurrence of Protein Disulfide Bonds in Different Domains of Life: A Comparison of Proteins from the Protein Data Bank, erschienen in Protein Engineering, Design and Selection , Volume 27, Issue 3, erläutert wird. 1. März 2014, S. 65–72.

Die PDB hat viele sich wiederholende Strukturen mit unterschiedlichen Auflösungen, Methoden, Mutationen usw. Ein Experiment mit denselben oder ähnlichen Proteinen kann bei jeder Gruppenanalyse zu Verzerrungen führen, daher müssen wir die richtige Struktur aus einem beliebigen Satz von Duplikaten auswählen . Zu diesem Zweck müssen wir einen nicht-redundanten (NR) Satz von Proteinen verwenden.

Zum Zweck der Normalisierung empfehle ich, das Wörterbuch für chemische Verbindungen herunterzuladen, um Atomnamen in eine Datenbank zu importieren, die 3NF verwendet oder ein Sternschema und dimensionale Modellierung verwendet. (Ich habe auch DSSP verwendet, um problematische Strukturen zu beseitigen. Ich werde das in diesem Artikel nicht behandeln, aber beachten Sie, dass ich keine anderen DSSP-Funktionen verwendet habe.)

Die in dieser Forschung verwendeten Daten enthalten Single-Unit-Proteine, die mindestens eine Disulfidbindung enthalten, die von verschiedenen Arten stammt. Um eine Analyse durchzuführen, werden zunächst alle Disulfidbindungen nach Domäne (Archaeen, Prokaryoten, Viren, Eukaryoten oder andere) und auch nach Länge als aufeinanderfolgend oder nicht aufeinanderfolgend klassifiziert.

Ausgabe

Um für die Eingabe in R, SPSS oder ein anderes Tool bereit zu sein, benötigt ein Analyst die Daten in einer Datenbanktabelle mit dieser Struktur:

Materialen und Methoden

Um dieses Ziel zu erreichen, besteht der erste Schritt darin, Daten von rcsb.org zu sammeln. Diese Seite enthält herunterladbare PDB-Strukturen von Experimenten in verschiedenen Formaten.

Obwohl Daten in mehreren Formaten gespeichert werden, wird in diesem Beispiel nur das formatierte, durch feste Leerzeichen getrennte Textformat (PDB) verwendet. Eine Alternative zum PDB-Textformat ist die XML-Version PDBML, die jedoch manchmal falsch formatierte Einträge zur Benennung von Atompositionen enthält, die Probleme bei der Datenanalyse verursachen können. Die älteren mmCIF- und andere Formate sind möglicherweise ebenfalls verfügbar, werden jedoch in diesem Artikel nicht erläutert.

Das PDB-Format

Das PDB-Format ist ein fragmentiertes Textformat mit fester Breite, das beispielsweise einfach von SQL-Abfragen, Java-Plugins oder Perl-Modulen geparst werden kann. Jeder Datentyp im Dateicontainer wird als Zeile dargestellt, die mit dem entsprechenden Tag beginnt – wir werden jeden Tag-Typ in den folgenden Unterabschnitten durchgehen. Die Zeilenlänge ist kleiner oder gleich 80 Zeichen, wobei ein Tag sechs oder weniger Zeichen plus ein oder mehrere Leerzeichen benötigt, die zusammen acht Bytes einnehmen. Es gibt auch Fälle ohne Leerzeichen zwischen Tags und Daten, normalerweise für CONECT Tags.

TITLE

Das TITLE -Tag markiert eine Zeile als (Teil des) Titels des Experiments, die den Molekülnamen und andere relevante Daten wie die Insertion, Mutation oder Deletion einer bestimmten Aminosäure enthält.

 12345678901234567890123456789012345678901234567890123456789012345678901234567890 TITLE A TWO DISULFIDE DERIVATIVE OF CHARYBDOTOXIN WITH DISULFIDE TITLE 2 13-33 REPLACED BY TWO ALPHA-AMINOBUTYRIC ACIDS, NMR, 30 TITLE 3 STRUCTURES

Falls es mehrere Zeilen zu einem TITLE -Datensatz gibt, muss der Titel verkettet werden, geordnet nach einer Fortsetzungsnummer, die rechtsbündig auf den Bytes 9 und 10 platziert wird (abhängig von der Anzahl dieser Zeilen).

ATOM

Die in ATOM -Zeilen gespeicherten Daten sind Koordinatendaten für jedes Atom in einem Experiment. Manchmal weist ein Experiment Einfügungen, Mutationen, alternative Orte oder mehrere Modelle auf. Dies führt dazu, dass dasselbe Atom mehrmals wiederholt wird. Die Auswahl der richtigen Atome wird später erklärt.

 12345678901234567890123456789012345678901234567890123456789012345678901234567890 ATOM 390 N GLY A 26 -1.120 -2.842 4.624 1.00 0.00 N ATOM 391 CA GLY A 26 -0.334 -2.509 3.469 1.00 0.00 C ATOM 392 C GLY A 26 0.682 -1.548 3.972 1.00 0.00 C ATOM 393 O GLY A 26 0.420 -0.786 4.898 1.00 0.00 O ATOM 394 H GLY A 26 -0.832 -2.438 5.489 1.00 0.00 H ATOM 395 HA2 GLY A 26 0.163 -3.399 3.111 1.00 0.00 H ATOM 396 HA3 GLY A 26 -0.955 -2.006 2.739 1.00 0.00 H

Das obige Beispiel ist dem Experiment 1BAH . Die erste Spalte kennzeichnet die Art des Datensatzes und die zweite Spalte die Seriennummer des Atoms. Jedes Atom in einer Struktur hat seine eigene Seriennummer.

Neben der Seriennummer befindet sich das Atompositionslabel, das vier Bytes belegt. Aus dieser Atomposition ist es möglich, das chemische Symbol des Elements zu extrahieren, das in den Aufzeichnungsdaten nicht immer in einer eigenen separaten Spalte vorhanden ist.

Nach dem Atomnamen steht ein aus drei Buchstaben bestehender Restcode. Bei Proteinen entspricht dieser Rest einer Aminosäure. Als nächstes wird die Kette mit einem Buchstaben codiert. Mit Kette meinen wir eine einzelne Kette von Aminosäuren, mit oder ohne Lücken, obwohl manchmal Liganden einer Kette zugeordnet werden können; dieser Fall ist durch sehr große Lücken in einer Aminosäuresequenz nachweisbar, die in der nächsten Spalte steht. Manchmal kann dieselbe Struktur mit eingeschlossenen Mutationen gescannt werden, in diesem Fall ist der Insertionscode in einer zusätzlichen Spalte nach der Sequenzspalte verfügbar. Der Einfügungscode enthält einen Buchstaben, um zu unterscheiden, welcher Rest betroffen ist.

Die nächsten drei Spalten sind die räumlichen Koordinaten jedes Atoms, gemessen in Angström (Å). Neben diesen Koordinaten befindet sich die Besetzungsspalte, die auf der üblichen Skala von null bis eins angibt, wie wahrscheinlich es ist, dass sich das Atom an diesem Ort befindet.

Die vorletzte Spalte ist der Temperaturfaktor, der Auskunft über die Unordnung im Kristall gibt, gemessen in Ų. Ein Wert über 60 Ų bedeutet Unordnung, ein Wert unter 30 Ų Vertrauen. Es ist nicht immer in PDB-Dateien vorhanden, da es von der experimentellen Methode abhängt.

Die nächsten Spalten – Symbol und Ladung – fehlen normalerweise. Das chemische Symbol kann, wie oben erwähnt, aus der Atompositionsspalte entnommen werden. Wenn die Ladung vorhanden ist, wird sie als ganze Zahl gefolgt von + oder - an das Symbol angehängt, z. B. N1+ .

TER

Dies markiert das Ende der Kette. Auch ohne diese Linie ist es leicht zu erkennen, wo eine Kette endet. Daher fehlt oft die TER -Linie.

MODEL und ENDMDL

Eine MODEL -Zeile markiert, wo das Modell einer Struktur beginnt, und sie enthält die Seriennummer des Modells.

Nach allen atomaren Linien in diesem Modell endet es mit einer ENDMDL -Linie.

SSBOND

Diese Linien enthalten Disulfidbindungen zwischen Cystein-Aminosäuren. Disulfidbindungen können in anderen Resttypen vorhanden sein, aber in diesem Artikel werden nur Aminosäuren analysiert, daher ist nur Cystein enthalten. Das folgende Beispiel stammt aus dem Experiment mit Code 132L :

 12345678901234567890123456789012345678901234567890123456789012345678901234567890 SSBOND 1 CYS A 6 CYS A 127 1555 1555 2.01 SSBOND 2 CYS A 30 CYS A 115 1555 1555 2.05 SSBOND 3 CYS A 64 CYS A 80 1555 1555 2.02 SSBOND 4 CYS A 76 CYS A 94 1555 1555 2.02

In diesem Beispiel gibt es vier Disulfidbindungen, die in der Datei mit ihrer Sequenznummer in der zweiten Spalte markiert sind. Alle diese Bindungen verwenden Cystein (Spalten 3 und 6), und alle sind in Kette A vorhanden (Spalten 4 und 7). Nach jeder Kette gibt es eine Restsequenznummer, die die Position der Bindung in der Peptidkette angibt. Insertionscodes befinden sich neben jeder Restsequenz, aber in diesem Beispiel sind sie nicht vorhanden, da in dieser Region keine Aminosäure eingefügt wurde. Die zwei Spalten vor der letzten sind für Symmetrieoperationen reserviert, und die letzte Spalte ist der Abstand zwischen Schwefelatomen, gemessen in Å.

Nehmen wir uns einen Moment Zeit, um diesen Daten einen Kontext zu geben.

Die folgenden Bilder, die mit dem NGL-Viewer von rcsb.org aufgenommen wurden, zeigen die Struktur von Experiment 132L . Insbesondere zeigen sie ein Protein ohne Liganden. Das erste Bild verwendet eine Stabdarstellung, wobei die CPK-Färbung Schwefel und ihre Bindungen in Gelb zeigt. V-förmige Schwefelverbindungen stellen Methioninverbindungen dar, während die Z-förmigen Verbindungen Disulfidbindungen zwischen Cysteinen sind.

Im nächsten Bild ist eine vereinfachte Methode der Proteinvisualisierung namens Backbone-Visualisierung dargestellt, die durch Aminosäuren gefärbt ist, wobei Cysteine ​​gelb sind. Es stellt dasselbe Protein dar, ohne seine Seitenkette und nur mit einem Teil seiner Peptidgruppe – in diesem Fall dem Proteinrückgrat. Es besteht aus drei Atomen: N-terminal, C-alpha und C-terminal. Dieses Bild zeigt keine Disulfidbindungen, aber es ist vereinfacht, um die räumliche Anordnung des Proteins zu zeigen:

Pipes entstehen durch die Verbindung von Peptid-gebundenen Atomen mit einem C-Alpha-Atom. Die Farbe von Cystein ist die gleiche wie die Farbe von Schwefel in der CPK-Färbemethode. Wenn Cystene nahe genug kommen, bilden ihre Schwefel Disulfidbindungen, und das stärkt die Struktur. Andernfalls würde dieses Protein zu viel binden und seine Struktur wäre bei höheren Temperaturen weniger stabil.

CONECT

Diese Aufzeichnungen werden zum Markieren von Verbindungen zwischen Atomen verwendet. Manchmal sind diese Tags überhaupt nicht vorhanden, während manchmal alle Daten ausgefüllt sind. Bei der Analyse von Disulfidbindungen kann dieser Teil nützlich sein, ist aber nicht notwendig. Das liegt daran, dass in diesem Projekt nicht getaggte Bindungen durch Messen von Entfernungen hinzugefügt werden, was Overhead wäre und auch überprüft werden muss.

SOURCE

Diese Aufzeichnungen enthalten Informationen über den Ursprungsorganismus, aus dem das Molekül extrahiert wurde. Sie enthalten Unterdatensätze zum leichteren Auffinden in der Taxonomie und haben dieselbe mehrzeilige Struktur, die wir bei Titeldatensätzen gesehen haben.

 SOURCE MOL_ID: 1; SOURCE 2 ORGANISM_SCIENTIFIC: ANOPHELES GAMBIAE; SOURCE 3 ORGANISM_COMMON: AFRICAN MALARIA MOSQUITO; SOURCE 4 ORGANISM_TAXID: 7165; SOURCE 5 GENE: GST1-6; SOURCE 6 EXPRESSION_SYSTEM: ESCHERICHIA COLI; SOURCE 7 EXPRESSION_SYSTEM_TAXID: 562; SOURCE 8 EXPRESSION_SYSTEM_STRAIN: BL21(DE3)PLYSS; SOURCE 9 EXPRESSION_SYSTEM_VECTOR_TYPE: PLASMID; SOURCE 10 EXPRESSION_SYSTEM_PLASMID: PXAGGST1-6

NR-Format

Dies ist eine Liste von nicht-redundanten (NR) Ketten-PDB-Sätzen. Seine Schnappschüsse finden Sie unter ftp.ncbi.nih.gov/mmdb/nrtable/. Sein Zweck ist es, unnötige Verzerrungen zu vermeiden, die durch Proteinähnlichkeit verursacht werden. NR hat drei Sätze mit unterschiedlichen Identitäts-p-Wert-Niveaus, die durch Vergleich aller PDB-Strukturen erstellt wurden. Das Ergebnis wird Textdateien hinzugefügt, die später erklärt werden. Für dieses Projekt werden nicht alle Spalten benötigt, daher werden nur die wichtigen erklärt.

Die ersten beiden Spalten enthalten den eindeutigen PDB-Experimentcode und die Kettenkennung, wie oben für ATOM -Datensätze erläutert. Die Spalten 6, 9 und C enthalten Informationen zur Repräsentativität des p-Werts, d. h. dem Grad der Ähnlichkeit von Sequenzen, der von BLAST berechnet wurde. Wenn dieser Wert Null ist, wird er nicht als Teil einer Menge akzeptiert; wenn der Wert 1 ist, dann ist es. Die erwähnten Spalten stellen die Akzeptanz von Sätzen mit p-Wert-Grenzwerten von 10e-7, 10e-40 bzw. 10e-80 dar. Für die Analyse werden nur Sätze mit einem p-Wert-Grenzwert von 10e-7 verwendet.

Die letzte Spalte enthält Informationen über die Akzeptanz einer Struktur, wobei a akzeptabel ist und n nicht.

 #--------------------------------------------------------------------------------------------------------------------------- # 1 2 3 4 5 6 7 8 9 ABCDEFGHIJKLMNOPQ #--------------------------------------------------------------------------------------------------------------------------- 3F8V A 69715 1 1 1 1 1 1 1 1 1 9427 1 1 0.00 0.00 0.00 0.00 1.08 1 6 5 164 X a 3DKE X 68132 1 2 0 1 2 0 1 2 0 39139 1 1 0.00 0.00 0.00 0.00 1.25 1 11 7 164 X a 3HH3 A 77317 1 3 0 1 3 0 1 3 0 90 1 0 0.00 0.00 0.00 0.00 1.25 1 5 4 164 X a 3HH5 A 77319 1 4 0 1 4 0 1 4 0 90 2 0 0.00 0.00 0.00 0.00 1.25 1 4 4 164 X a

Datenbankaufbau und Parsing von Daten

Nun, da wir eine Vorstellung davon haben, womit wir es zu tun haben und was wir tun müssen, fangen wir an.

Herunterladen von Daten

Alle Daten für diese Analyse finden Sie unter diesen drei Adressen:

• ftp.wwpdb.org/pub/pdb/data/structures/divided/pdb/
• ftp.ncbi.nih.gov/mmdb/nrtable/
• ftp.ncbi.nih.gov/pub/taxonomy/taxdmp.zip

Die ersten beiden Links enthalten eine Liste von Archiven. Es sollte jeweils das neueste Archiv verwendet werden, um Probleme aufgrund mangelnder Auflösung oder Qualität zu vermeiden. Der dritte Link enthält direkt das neueste Taxonomie-Archiv.

Analysieren von Daten

Normalerweise wird das Parsen von PDB-Dateien von Plugins oder Modulen in Java, Perl oder Python durchgeführt. Im Fall dieser Forschung habe ich eine benutzerdefinierte Perl-Anwendung geschrieben, ohne ein vorgefertigtes PDB-Parsing-Modul zu verwenden. Der Grund dafür ist, dass beim Analysieren einer großen Datenmenge meiner Erfahrung nach das häufigste Problem bei der Verwendung experimenteller Daten Fehler in den Daten sind. Manchmal gibt es Fehler bei Koordinaten, Entfernungen, Linienlängen, Kommentaren an Stellen, wo sie nicht sein sollten, etc.

Der effektivste Weg, damit umzugehen, besteht darin, zunächst alles als Rohtext in der Datenbank zu speichern. Übliche Parser sind so geschrieben, dass sie mit idealen Daten umgehen, die vollständig den Spezifikationen entsprechen. Aber in der Praxis sind Daten nicht ideal, und das wird im Filterabschnitt erklärt, wo Sie das Perl-Importskript finden.

Datenbankaufbau

Beachten Sie beim Erstellen der Datenbank, dass diese Datenbank für die Verarbeitung von Daten erstellt wird. Die spätere Analyse erfolgt in SPSS oder R. Für unsere Zwecke hier wird empfohlen, PostgreSQL mit mindestens Version 8.4 zu verwenden.

Die Tabellenstruktur wird mit nur wenigen kleinen Änderungen direkt aus den heruntergeladenen Dateien kopiert. In diesem Fall ist die Anzahl der Datensätze viel zu gering, als dass es sich lohnt, unsere Zeit für die Normalisierung aufzuwenden. Wie bereits erwähnt, ist diese Datenbank nur für den einmaligen Gebrauch bestimmt: Diese Tabellen sind nicht dafür ausgelegt, auf einer Website bereitgestellt zu werden – sie dienen lediglich der Verarbeitung von Daten. Sobald dies abgeschlossen ist, können sie gelöscht oder als zusätzliche Daten gesichert werden, vielleicht um den Vorgang von einem anderen Forscher zu wiederholen.

In diesem Fall ist das Endergebnis eine Tabelle, die dann in eine Datei exportiert werden kann, um sie mit einem statistischen Tool wie SPSS oder R zu verwenden.

Tische

Die Datenextraktion aus ATOM -Datensätzen muss mit HEADER oder TITLE Datensätzen verbunden werden. Die Datenhierarchie wird im Bild unten erklärt.

Da dieses Bild eine vereinfachte Darstellung einer Datenbank in der dritten Normalform (3NF) ist, enthält es für unsere Zwecke zu viel Overhead. Der Grund: Um den Abstand zwischen Atomen für die Erkennung von Disulfidbindungen zu berechnen, müssten wir Joins durchführen. In diesem Fall wäre eine Tabelle zweimal mit sich selbst verbunden und außerdem jeweils zweimal mit einer sekundären und einer primären Struktur verbunden, was ein sehr langsamer Prozess ist. Da nicht jede Analyse Sekundärstrukturinformationen benötigt, wird ein anderes Schema vorgeschlagen, falls Sie Daten wiederverwenden oder größere Mengen an Disulfidbindungen analysieren müssen:

Disulfidbindungen sind nicht so häufig wie andere kovalente Bindungen, daher ist ein Warehouse-Modell nicht erforderlich, obwohl es verwendet werden könnte. Die Entwicklung des Sternschemas und der dimensionalen Modellierung unten nimmt zu viel Zeit in Anspruch und macht Abfragen komplexer:

In Fällen, in denen alle Anleihen verarbeitet werden müssen, empfehle ich das Sternschema.

(Andernfalls wird es nicht benötigt, da Disulfidbindungen nicht so häufig sind wie andere Bindungen. Im Fall dieser Arbeit liegt die Anzahl der Disulfidbindungen bei fast 30.000, was in 3NF schnell genug sein kann, aber ich habe mich entschieden, es zu verarbeiten über eine nicht normalisierte Tabelle, daher ist sie hier nicht abgebildet.)

Die erwartete Gesamtzahl aller kovalenten Bindungen ist mindestens doppelt so groß wie die Anzahl der Atome in der Tertiärstruktur, und in diesem Fall wäre 3NF sehr langsam, sodass eine Denormalisierung unter Verwendung der Sternschemaform erforderlich ist. In diesem Schema haben einige Tabellen zwei Fremdschlüsselprüfungen, und das liegt daran, dass eine Bindung zwischen zwei Atomen erstellt wird, sodass jedes Atom seine eigene primary_structure_id , atom_name_id und residue_id haben muss.

Es gibt zwei Möglichkeiten, die Dimensionstabelle d_atom_name zu füllen: aus Daten und aus einer anderen Quelle, dem Wörterbuch der chemischen Komponenten, das ich zuvor erwähnt habe. Sein Format ähnelt dem PDB-Format: Nur RESIDUE und CONECT Zeilen sind nützlich. Dies liegt daran, dass die erste Spalte von RESIDUE einen aus drei Buchstaben bestehenden Restcode enthält und CONECT den Namen des Atoms und seiner Verbindungen enthält, die ebenfalls Atomnamen sind. Aus dieser Datei können wir also alle Atomnamen parsen und sie in unsere Datenbank aufnehmen, obwohl ich Ihnen empfehle, die Möglichkeit zu berücksichtigen, dass die Datenbank nicht aufgeführte Atomnamen enthält.

 RESIDUE PRO 17 CONECT N 3 CA CD H CONECT CA 4 NC CB HA CONECT C 3 CA O OXT CONECT O 1 C CONECT CB 4 CA CG HB2 HB3 CONECT CG 4 CB CD HG2 HG3 CONECT CD 4 N CG HD2 HD3 CONECT OXT 2 C HXT CONECT H 1 N CONECT HA 1 CA CONECT HB2 1 CB CONECT HB3 1 CB CONECT HG2 1 CG CONECT HG3 1 CG CONECT HD2 1 CD CONECT HD3 1 CD CONECT HXT 1 OXT END HET PRO 17 HETNAM PRO PROLINE FORMUL PRO C5 H9 N1 O2

In diesem Projekt ist die Codierungsgeschwindigkeit relevanter als die Ausführungsgeschwindigkeit und der Speicherverbrauch. Ich habe mich entschieden, nicht zu normalisieren – schließlich ist unser Ziel, eine Tabelle mit den im Intro erwähnten Spalten zu generieren.

In diesem Teil werden nur die wichtigsten Tabellen erklärt.

Die Haupttabellen sind:

• proteins : Tabelle mit Versuchsnamen und Codes.
• ps : Primäre Strukturtabelle, die sequence , chain_id -ID und code .
• ts : Tabelle mit Tertiär-/Quartärstruktur, die aus Rohdaten extrahiert und in das ATOM -Datensatzformat umgewandelt wurde. Diese wird als Staging-Tabelle verwendet und kann nach der Extraktion gelöscht werden. Liganden sind ausgeschlossen.
• sources : Die Liste der Organismen, von denen Versuchsdaten stammen.
• tax_names , taxonomy_path , taxonomy_paths : Linneanische Taxonomienamen aus der NCBI-Taxonomiedatenbank, die verwendet werden, um Taxonomiepfade von Organismen zu erhalten, die in den sources aufgelistet sind.
• nr : Liste von nicht-redundanten NCBI-Proteinen, die aus dem NR-Satz extrahiert wurden.
• pdb_ssbond : Liste von Disulfidbindungen in einer gegebenen PDB-Datei.

Daten filtern und verarbeiten

Daten werden aus Snapshots aus dem RCSB PDB-Repository abgerufen.

Jede Datei wird mithilfe eines Perl-Skripts in eine einzelne Tabelle raw_pdb in unserer PostgreSQL-Datenbank importiert. Das Skript verwendet Transaktionen mit 10.000 Einfügungen pro Chunk.

Die Struktur von raw_pdb ist folgende:

Das Importskript sieht folgendermaßen aus:

 #!/usr/bin/perl -w use FindBin '$Bin'; use DBI; $dbName = 'bioinf'; $dbLogin = 'ezop'; $dbPass = 'XYZ'; $conn = DBI->connect("DBI:Pg:database=$dbName;host=localhost", "$dbLogin", "$dbPass", {'RaiseError' => 1, 'AutoCommit' => 0}); die "./pdb_lines_unos.pl <table> <file>" if not defined($ARGV[0]); $recordCount = 0; $table = $ARGV[0]; $fName = $ARGV[1]; open F, "zcat $fName|"; while (<F>) { chomp; $linija = $_; $recordCount += 1; $sql = "insert into $table (code, line_num, line_cont) values (?, ?, ?)"; $conn->do($sql, undef, $fName, $recordCount, $linija); $conn->commit() if ($recordCount%10000 == 0); } close F; $conn->commit(); 1;

Nachdem Zeilen importiert wurden, werden sie mit Funktionen geparst, die wir unten definieren werden.

Aus raw_pdb -Daten generieren wir die Tabellen ts , ps , proteins ​​, sources , sources_organela und ss_bond durch Parsen der entsprechenden Datensätze.

Die ps -Tabelle hat drei wichtige Spalten: chain , length und sequence . Die Proteinsequenz wird unter Verwendung von C-Alpha-Atomen für jede Kette und für jeden Rest, geordnet nach Restsequenz, erzeugt, wobei nur die erste Insertion und die erste alternative Position genommen werden. chain wird der Spalte TS.chain entnommen, und length ist einfach die vorberechnete Länge der sequence . Da dieser Artikel nur einzelne Ketten und Verbindungen innerhalb der Kette analysieren soll, werden mehrkettige Proteine ​​in unserer Analyse hier übersprungen.

Innerhalb SSBOND Datensätzen werden alle Disulfidbindungen in der Tabelle pdb_ssbond gespeichert, die von der Tabelle pdb_ssbond_extended erbt. pdb_ssbond sieht so aus:

Ich habe auch diese Indizes hinzugefügt:

 "pdb_ssbond_pkey" PRIMARY KEY, btree (id) "ndxcode1" btree (code, chain_id1, res_seq1) "ndxcode2" btree (code, chain_id2, res_seq2)

Es wird angenommen, dass die Verteilung der Disulfidbindungen vor dem Cutoff eine Gaußsche Verteilung ist (ohne Testen mit z. B. KS-Test), daher wurden Standardabweichungen für jeden Abstand zwischen Cysteinen im gleichen Protein berechnet, um den Bereich zulässiger Bindungslängen zu entdecken und sie zu vergleichen zum Abbruch. Der Grenzwert war derselbe wie der berechnete Mittelwert plus-minus drei Standardabweichungen. Wir haben den Bereich erweitert, um mehr mögliche Disulfidbindungen einzuführen, die nicht in der PDB-Datei in SSBOND Zeilen eingetragen waren, die wir aber selbst eingefügt haben, indem wir die Abstände zwischen ATOM -Datensätzen berechnet haben. Der gewählte Bereich für ssbonds liegt zwischen 1,6175344456264 und 2,48801947642267 Å, ​​was dem Mittelwert (2,05) plus-minus vier Standardabweichungen entspricht:

 select count(1) as cnt , stddev(dist) as std_dev , avg(dist) as avg_val , -stddev(dist) + avg(dist) as left1 , stddev(dist) + avg(dist) as right1 , -2 * stddev(dist) + avg(dist) as left2 , 2 * stddev(dist) + avg(dist) as right2 , -3 * stddev(dist) + avg(dist) as left3 , 3 * stddev(dist) + avg(dist) as right3 , -4 * stddev(dist) + avg(dist) as left4 , 4 * stddev(dist) + avg(dist) as right4 , min(dist) , max(dist) from pdb_ssbond_tmp where dist > 0 and dist < 20;

Die TS -Tabelle enthält die Koordinaten aller Atome, aber es werden nur Cysteine ​​verwendet, deren Schwefel mit " SG " wird. Daher wird eine weitere Staging-Tabelle nur mit " SG " -Schwefelatomen erstellt, um den Prozess zu beschleunigen, indem die Anzahl der zu durchsuchenden Datensätze reduziert wird. Wenn nur Schwefel ausgewählt werden, ist die Anzahl der Kombinationen viel geringer als im Fall aller Atome – 194.574 der ersteren gegenüber 122.761.100 der letzteren. Innerhalb dieser Tabelle, die mit sich selbst verbunden ist, werden Entfernungen unter Verwendung der euklidischen Entfernung berechnet, und Ergebnisse werden in die Tabelle pdb_ssbond importiert, aber nur dort, wo die Entfernung zwischen den zuvor berechneten definierten Längen liegt. Der Grund für diese Beschleunigung besteht darin, die Zeitdauer für die erneute Ausführung des gesamten Prozesses zu Prüfzwecken zu verkürzen und ihn innerhalb eines Tages zu halten.

Um Disulfidbindungen zu reinigen, verwenden wir den folgenden Algorithmus:

• Löschen, wenn beide Seiten der Verbindung auf dieselbe Aminosäure zeigen
• Löschen Sie Bindungen, deren Länge nicht zwischen 1,6175344456264 und 2,48801947642267 liegt
• Einfügungen entfernen
• Entfernen Sie Bindungen, die durch alternative Atompositionen verursacht werden, aber lassen Sie die erste Position

Der Code dafür (mit der pdb_ssbond Tabelle als erstes Argument) lautet:

 CREATE OR REPLACE FUNCTION pdb_ssbond_clean2( clean_icodes boolean, clean_altloc boolean, mark_reactive boolean, mark_consecutive boolean) RETURNS void AS $$ declare _res integer; BEGIN delete from pdb_ssbond b where exists ( select a.id from pdb_ssbond a where a.code = b.code and a.id > b.id and ( ( a.chain_id1 = b.chain_id1 and a.res_seq1 = b.res_seq1 and a.chain_id2 = b.chain_id2 and a.res_seq2 = b.res_seq2) or ( a.chain_id1 = b.chain_id2 and a.res_seq1 = b.res_seq2 and a.chain_id2 = b.chain_id1 and a.res_seq2 = b.res_seq1) ) ) ; delete from pdb_ssbond where chain_id1 = chain_id2 and res_seq1 = res_seq2 and i_code1 = i_code2; update pdb_ssbond set is_consecutive = true , is_reactive = false; delete from pdb_ssbond where not dist between 1.6175344456264 and 2.48801947642267; if clean_icodes then delete from pdb_ssbond where i_code1 not in ('', ' ', 'A') or i_code2 not in ('', ' ', 'A') ; end if; if clean_altloc then delete from pdb_ssbond a where exists ( select 1 from pdb_ssbond b where b.code = a.code and b.chain_id1 = a.chain_id1 and b.res_seq1 = a.res_seq1 and b.i_code1 = a.i_code1 and b.ser_num < a.ser_num ) ; delete from pdb_ssbond a where exists ( select 1 from pdb_ssbond b where b.code = a.code and b.chain_id2 = a.chain_id2 and b.res_seq2 = a.res_seq2 and b.i_code2 = a.i_code2 and b.ser_num < a.ser_num ) ; end if; if mark_reactive then update pdb_ssbond set is_reactive = false ; update pdb_ssbond set is_reactive = true where exists ( select 1 from pdb_ssbond b where b.code = pdb_ssbond.code and b.chain_id1 = pdb_ssbond.chain_id1 and b.res_seq1 = pdb_ssbond.res_seq1 and b.i_code1 = pdb_ssbond.i_code1 and b.ser_num < pdb_ssbond.ser_num ) ; update pdb_ssbond set is_reactive = true where exists ( select 1 from pdb_ssbond b where b.code = pdb_ssbond.code and b.chain_id2 = pdb_ssbond.chain_id2 and b.res_seq2 = pdb_ssbond.res_seq2 and b.i_code2 = pdb_ssbond.i_code2 and b.ser_num < pdb_ssbond.ser_num ) ; update pdb_ssbond set is_reactive = true where (code, chain_id1, res_seq1, i_code1) in ( select code, chain_id1 as c, res_seq1 as r, i_code1 as i from pdb_ssbond intersect select code, chain_id2 as c, res_seq2 as r, i_code2 as i from pdb_ssbond ) ; update pdb_ssbond set is_reactive = true where (code, chain_id2, res_seq2, i_code2) in ( select code, chain_id1 as c, res_seq1 as r, i_code1 as i from pdb_ssbond intersect select code, chain_id2 as c, res_seq2 as r, i_code2 as i from pdb_ssbond ); end if; if mark_consecutive then update pdb_ssbond set is_consecutive = false; update pdb_ssbond set is_consecutive = true where not exists ( select 1 from pdb_ssbond a where a.code = pdb_ssbond.code and ( (a.chain_id1 = pdb_ssbond.chain_id1 and a.chain_id2 = pdb_ssbond.chain_id2) or (a.chain_id1 = pdb_ssbond.chain_id2 and a.chain_id2 = pdb_ssbond.chain_id1) ) and ( (a.res_seq1 between pdb_ssbond.res_seq1 and pdb_ssbond.res_seq2) or (a.res_seq2 between pdb_ssbond.res_seq1 and pdb_ssbond.res_seq2) or (pdb_ssbond.res_seq1 between a.res_seq1 and a.res_seq2) or (pdb_ssbond.res_seq2 between a.res_seq1 and a.res_seq2) ) and not ( a.code = pdb_ssbond.code and a.chain_id1 = pdb_ssbond.chain_id1 and a.chain_id2 = pdb_ssbond.chain_id2 and a.res_seq1 = pdb_ssbond.res_seq1 and a.res_seq2 = pdb_ssbond.res_seq2 ) ); end if; END; $$ LANGUAGE plpgsql;

Damit wird der nicht-redundante Satz von Proteinen in die Tabelle nr importiert, die mit den Tabellen ps und proteins verknüpft ist, und Sätze werden markiert ( set7 , set40 und set80 ). Am Ende wird je nach Proteinmenge nur ein Satz analysiert. Nicht übereinstimmende Ketten zwischen PDB und NR werden aus der Analyse entfernt.

Proteine ​​ohne Disulfidbindungen werden von der Forschung ausgeschlossen, ebenso wie Proteine, die zu keiner Gruppe gehören. Daten werden mit DSSP verarbeitet, und diese Dateien, die Probleme mit der Auflösung oder zu vielen zu verarbeitenden Atomen hatten, werden ebenfalls ausgeschlossen. Als Ergebnis für die Analyse werden nur Proteine ​​mit Einzelketten verwendet, da Verbindungen zwischen den Ketten nicht beibehalten wurden, obwohl sie leicht aus der ssbond Tabelle berechnet werden können, indem die Anzahl der Verbindungen mit unterschiedlichen Ketten gezählt wird.

Für die verbleibenden Proteine ​​wird eine Aktualisierung für die Gesamtzahl der Bindungen und die Anzahl der überlappenden Bindungen durchgeführt, und dies wird für jeden der Sätze durchgeführt.

Der Quellorganismus wird aus SOURCE -Aufzeichnungen extrahiert. In Fällen, in denen es unbekannt, synthetisch, entworfen, künstlich oder hybrid ist, wird es aus der Forschung verworfen. Proteine ​​mit niedriger Auflösung werden ebenfalls nur dann ausgeschlossen, wenn ihre Seitenkette nicht sichtbar ist.

SOURCE Datensätze werden in der sources -Tabelle gespeichert, die Taxonomiezeilen enthält. In einigen Fällen fehlt die Taxonomie oder ist falsch. In diesen Fällen ist die manuelle Korrektur durch Experten erforderlich.

Aus der vom NCBI heruntergeladenen Quelle und Taxonomie wird die Klasse jeder Primärstruktur zugewiesen. Falls eine Klasse nicht zugeordnet werden kann, wird das Protein aus der Analyseliste entfernt. In dem Wissen, dass biologische Datenbanken verwendet werden, wird empfohlen, eine zusätzliche Überprüfung aller Quelldatensätze und NCBI-Taxonomieklassen durch einen Biologen durchzuführen, da es sonst zu Problemen bei der Klassifizierung zwischen verschiedenen Domänen kommen kann. Um Quellzellenstandorte mit Taxonomie-IDs abzugleichen, werden Daten aus der Quelltabelle in die Tabelle sources_organela extrahiert, wo alle Daten als Code, Tag und Wert geschrieben werden. Sein Format ist unten dargestellt:

 select * from sources_organela where code = '1rav';

Das Taxonomie-Archiv, das wir verwenden möchten, ist eine ZIP-Datei mit sieben Dump-Dateien. Unter diesen Dateien sind zwei der wichtigsten names.dmp und merged.dmp . Beide Dateien sind durch Tabulatoren getrennte CSV-Dateien, wie in der Dokumentation beschrieben:

• Die Datei merged.dmp enthält eine Liste früherer Taxonomie-IDs und die aktuellen Taxonomie-IDs, mit denen jede zusammengeführt wurde.
• names.dmp enthält diese wichtigen Spalten in dieser Reihenfolge:
  • tax_id : Die Taxonomie-ID
  • name_txt : Der Name der Art und ggf. der eindeutige Name (wo Arten mit mehreren Namen gefunden werden können, hilft dies bei der Unterscheidung)
• division.dmp enthält die Namen der Top-Level-Domains, die wir als unsere Klassen verwenden werden.
• nodes.dmp ist die Tabelle, die eine hierarchische Struktur von Organismen enthält, die Taxonomie-IDs verwenden.
  • Es enthält eine übergeordnete Taxonomie-ID, einen Fremdschlüssel, der in names.dmp zu finden ist.
  • Es enthält auch eine Bereichs-ID, die für uns wichtig ist, um die relevanten Top-Domain-Daten korrekt zu speichern.

Mit all diesen Daten und manuellen Korrekturen (Einstellung der richtigen Lebensbereiche) konnten wir die Struktur der taxonomy_path -Tabelle erstellen. Eine Stichprobe von Daten sieht wie folgt aus:

 select * from taxonomy_path order by length(path) limit 20 offset 2000;

Before any analysis, to avoid biases, sequences have to be checked for their level of identity. Although the NR set contains sequences which are already compared between each other, an extra check is always recommended.

For each disulfide bond's prior statistical analysis, data is marked if it is reactive or overlapping. After marking overlaps, that information automatically reveals how many consecutive and non-consecutive bonds are inside each protein, and that data is stored in the proteins table from which all protein complexes are excluded in final result.

Each disulfide bond is marked also for its association to sets, by checking both bond sides to see if they belong to the same NR set. Where that is not the case, the disulfide bond is skipped for that set analysis.

To analyze the quantity of bonds by their variance, each length has to be put in a specific class. In this case, only five classes are chosen as written in the function below.

 CREATE OR REPLACE FUNCTION len2class(len integer) RETURNS integer AS $BODY$ BEGIN return case when len <= 100 then 1 when len > 100 and len <= 200 then 2 when len > 200 and len <= 300 then 3 when len > 300 and len <= 400 then 4 else 5 end; END; $BODY$ LANGUAGE plpgsql VOLATILE COST 100;

Most of the protein sizes are less than 400 amino acids, so length classification is done by splitting lengths into five ranges, each taking 100 amino acids, except the last one which takes the rest. Below you can see how to use this function to extract data for analysis:

 SELECT p.code, p.title, p.ss_bonds, p.ssbonds_overlap, p.intra_count, p.sci_name_src, p.len, p.tax_path, p.pfam_families, p.src_class, ( SELECT s.id FROM src_classes s WHERE s.src_class::text = p.src_class::text) AS src_class_id, p.len_class7, ( SELECT s.val FROM sources_organela s WHERE s.code = p.code::bpchar AND s.tag::text = 'EXPRESSION_SYSTEM_CELLULAR_LOCATION'::text) AS expression_system_cellular_location, ( SELECT s.val FROM sources_organela s WHERE s.code = p.code::bpchar AND s.tag::text = 'CELLULAR_LOCATION'::text) AS cellular_location, ps.sequence, ps.uniprot_code, ps.accession_code, ps.cc, ps.seq_uniprot, ps.chain_id FROM proteins p JOIN nr n ON n.code::text = p.code::text AND n.rep7 = true JOIN ps ps ON ps.code::text = n.code::text AND ps.chain_id = n.chain_id AND ps.het = false WHERE p.is_excluded = false AND p.chain_cnt = 1 AND p.is_set7 = true AND p.reactive_cnt7 = 0 ORDER BY p.code;

An example result with corrected titles and some manually added columns is shown below.

PostgreSQL als Verarbeitungsvermittler

In dieser Arbeit haben wir gezeigt, wie Daten verarbeitet werden, vom Abrufen bis zur Analyse. Bei der Arbeit mit wissenschaftlichen Daten ist manchmal eine Normalisierung erforderlich, manchmal nicht. Wenn Sie mit kleinen Datenmengen arbeiten, die nicht für eine weitere Analyse wiederverwendet werden, reicht es aus, sie denormalisiert zu lassen, wenn die Verarbeitung schnell genug ist.

Der Grund, warum dies alles in einer Bioinformatik-Datenbank durchgeführt wurde, ist, dass PostgreSQL viele Sprachen integrieren kann. Dazu gehört R, das statistische Analysen direkt in der Datenbank durchführen kann – das Thema eines zukünftigen Artikels über Bioinformatik-Tools.

Ein besonderer Dank gilt den Toptal-Kollegen Stefan Fuchs und Aldo Zelen für ihre wertvolle Beratung.