Dezvoltarea unei baze de date bioinformatice pentru cercetarea legaturilor disulfurice

Baza de date bioinformatică Protein Data Bank (PDB) este cel mai mare depozit din lume de structuri determinate experimental de proteine, acizi nucleici și ansambluri complexe. Toate datele sunt colectate folosind metode experimentale, cum ar fi raze X, spectroscopie, cristalografie, RMN etc.

Acest articol explică cum să extrageți, să filtrați și să curățați datele din PDB. Acest lucru, la rândul său, permite tipul de analiză explicat în articolul Apariția legăturilor disulfurice proteice în diferite domenii ale vieții: o comparație a proteinelor din Protein Data Bank, publicat în Protein Engineering, Design and Selection , Volumul 27, Numărul 3, 1 martie 2014, p. 65–72.

PDB are o mulțime de structuri repetate cu rezoluții, metode, mutații diferite etc. Efectuarea unui experiment cu aceleași proteine ​​sau similare poate produce părtinire în orice analiză de grup, așa că va trebui să alegem structura corectă dintre orice set de duplicate. . În acest scop, trebuie să folosim un set neredundant (NR) de proteine.

În scopul normalizării, recomand să descărcați dicționarul de compuși chimici pentru importarea numelor de atom într-o bază de date care utilizează 3NF sau utilizează o schemă stea și modelare dimensională. (De asemenea, am folosit DSSP pentru a ajuta la eliminarea structurilor problematice. Nu voi acoperi asta în acest articol, dar rețineți că nu am folosit alte caracteristici DSSP.)

Datele utilizate în această cercetare conțin proteine ​​cu o singură unitate care conțin cel puțin o legătură disulfurică luată de la diferite specii. Pentru a efectua o analiză, toate legăturile disulfurice sunt mai întâi clasificate ca consecutive sau neconsecutive, după domeniu (arheea, procariotă, virală, eucariotă sau altele) și, de asemenea, după lungime.

Ieșire

Pentru a fi pregătit pentru introducerea în R, SPSS sau în alt instrument, un analist va avea nevoie ca datele să fie într-un tabel de bază de date cu această structură:

Materiale si metode

Pentru a atinge acest obiectiv, primul pas este adunarea datelor de pe rcsb.org. Acest site conține structuri PDB descărcabile ale experimentelor în diferite formate.

Deși datele sunt stocate în mai multe formate, în acest exemplu, va fi utilizat doar formatul textual delimitat cu spațiu fix (PDB) formatat. O alternativă la formatul textual PDB este versiunea sa XML, PDBML, dar uneori conține intrări de denumire a poziției atomului incorecte, ceea ce poate cauza probleme la analiza datelor. Este posibil ca mmCIF mai vechi și alte formate să fie, de asemenea, disponibile, dar nu vor fi explicate în acest articol.

Formatul PDB

Formatul PDB este un format textual fragmentat cu lățime fixă ​​care poate fi analizat cu ușurință prin interogări SQL, pluginuri Java sau module Perl, de exemplu. Fiecare tip de date din containerul de fișiere este reprezentat ca o linie care începe cu eticheta corespunzătoare; vom analiza fiecare tip de etichetă în următoarele subsecțiuni. Lungimea liniei este mai mică sau egală cu 80 de caractere, unde o etichetă are șase sau mai puține caractere plus unul sau mai multe spații care împreună ocupă opt octeți. Există, de asemenea, cazuri fără spații între etichete și date, de obicei pentru etichetele CONECT .

TITLE

Eticheta TITLE marchează o linie ca fiind (parte a) titlului experimentului, care conține numele moleculei și alte date relevante, cum ar fi inserția, mutația sau ștergerea unui anumit aminoacid.

 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

În cazul în care există mai multe linii la o înregistrare TITLE , atunci titlul trebuie concatenat, ordonat după un număr de continuare, care este plasat, aliniat la dreapta, pe octeții 9 și 10 (în funcție de numărul acestor linii).

ATOM

Datele stocate în liniile ATOM sunt date de coordonate pentru fiecare atom dintr-un experiment. Uneori, un experiment are inserții, mutații, locații alternative sau modele multiple. Acest lucru are ca rezultat repetarea aceluiași atom de mai multe ori. Alegerea atomilor potriviți va fi explicată mai târziu.

 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

Exemplul de mai sus este preluat din experimentul 1BAH . Prima coloană marchează tipul de înregistrare, iar a doua coloană este numărul de serie al atomului. Fiecare atom dintr-o structură are propriul său număr de serie.

Lângă numărul de serie se află eticheta de poziție a atomului, care are patru octeți. Din acea poziție atomică, este posibil să se extragă simbolul chimic al elementului, care nu este întotdeauna prezent în datele de înregistrare în propria sa coloană separată.

După numele atomului există un cod rezidual de trei litere. În cazul proteinelor, acel reziduu corespunde unui aminoacid. În continuare, lanțul este codificat cu o literă. Prin lanț înțelegem un singur lanț de aminoacizi, cu sau fără goluri, deși uneori liganzii pot fi alocați unui lanț; acest caz este detectabil prin goluri foarte mari într-o secvență de aminoacizi, care se află în coloana următoare. Uneori, aceeași structură poate fi scanată cu mutații incluse, caz în care codul de inserție este disponibil într-o coloană suplimentară după coloana secvență. Codul de inserare conține o literă pentru a ajuta la distingerea reziduurilor afectate.

Următoarele trei coloane sunt coordonatele spațiale ale fiecărui atom, măsurate în Angstroms (Å). Lângă aceste coordonate se află coloana de ocupare, care spune care este probabilitatea ca atomul să se afle în acel loc, pe scara obișnuită de la zero la unu.

A doua coloană este factorul de temperatură, care poartă informații despre tulburarea din cristal, măsurată în Ų. O valoare mai mare de 60 Ų semnifică tulburare, în timp ce una mai mică de 30 Ų înseamnă încredere. Nu este întotdeauna prezent în fișierele PDB deoarece depinde de metoda experimentală.

Următoarele coloane - simbol și încărcare - lipsesc de obicei. Simbolul chimic poate fi adunat din coloana poziției atomului, așa cum am menționat mai sus. Când sarcina este prezentă, este sufixată simbolului ca un număr întreg urmat de + sau - , de exemplu N1+ .

TER

Aceasta marchează sfârșitul lanțului. Chiar și fără această linie, este ușor să distingem unde se termină un lanț. Astfel, de multe ori linia TER lipsește.

MODEL și ENDMDL

O linie MODEL marchează locul unde începe modelul unei structuri și conține numărul de serie al modelului.

După toate liniile atomice din acel model, se termină cu o linie ENDMDL .

SSBOND

Aceste linii conțin legături disulfurice între aminoacizii cisteinei. Legăturile disulfură pot fi prezente în alte tipuri de reziduuri, dar în acest articol vor fi analizați doar aminoacizii, deci este inclusă doar cisteina. Următorul exemplu este din experimentul cu codul 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

În acest exemplu, există patru legături disulfurice etichetate în fișier cu numărul lor de secvență în a doua coloană. Toate aceste legături folosesc cisteină (coloanele 3 și 6) și toate sunt prezente în lanțul A (coloanele 4 și 7). După fiecare lanț există un număr de secvență de reziduuri care indică poziția legăturii în lanțul peptidic. Codurile de inserție sunt lângă fiecare secvență de reziduuri, dar în acest exemplu ele nu sunt prezente deoarece nu a fost inserat niciun aminoacid în acea regiune. Cele două coloane dinaintea ultimei sunt rezervate operațiilor de simetrie, iar ultima coloană este distanța dintre atomii de sulf, măsurată în Å.

Să luăm un moment pentru a da un context acestor date.

Imaginile de mai jos, realizate cu ajutorul vizualizatorului NGL rcsb.org, arată structura experimentului 132L . În special, ele prezintă o proteină fără liganzi. Prima imagine folosește o reprezentare tip stick, cu colorarea CPK arătând sulfuri și legăturile lor în galben. Conexiunile de sulf în formă de V reprezintă conexiuni de metionină, în timp ce conexiunile în formă de Z sunt legături disulfurice între cisteine.

În imaginea următoare, o metodă simplificată de vizualizare a proteinelor numită vizualizare a coloanei vertebrale este prezentată colorată de aminoacizi, unde cisteinele sunt galbene. Reprezintă aceeași proteină, cu lanțul său lateral exclus și doar o parte din grupul său peptidic inclus - în acest caz, coloana vertebrală a proteinei. Este format din trei atomi: N-terminal, C-alfa și C-terminal. Această imagine nu arată legături disulfurice, dar este simplificată pentru a arăta aranjamentul spațial al proteinei:

Conductele sunt create prin unirea atomilor legați de peptide cu un atom C-alfa. Culoarea cisteinei este aceeași cu culoarea sulfului în metoda de colorare CPK. Când cistenele se apropie suficient de mult, sulful lor creează legături disulfurice, iar asta întărește structura. Altfel, această proteină s-ar lega prea mult, iar structura ei ar fi mai puțin stabilă la temperaturi mai ridicate.

CONECT

Aceste înregistrări sunt folosite pentru marcarea conexiunilor dintre atomi. Uneori, aceste etichete nu sunt prezente deloc, în timp ce alteori toate datele sunt completate. În cazul analizării legăturilor disulfurice, această parte poate fi utilă, dar nu este necesară. Acest lucru se datorează faptului că, în acest proiect, legăturile neetichetate sunt adăugate prin măsurarea distanțelor, astfel încât acest lucru ar fi deasupra capului și, de asemenea, trebuie verificat.

SOURCE

Aceste înregistrări conțin informații despre organismul sursă din care a fost extrasă molecula. Acestea conțin subînregistrări pentru o localizare mai ușoară în taxonomie și au aceeași structură pe mai multe linii pe care am văzut-o cu înregistrările de titlu.

 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

Format NR

Aceasta este o listă de seturi PDB în lanț non-redundante (NR). Instantaneele sale pot fi găsite la ftp.ncbi.nih.gov/mmdb/nrtable/. Scopul său este de a evita părtinirile inutile cauzate de asemănarea proteinelor. NR are trei seturi cu niveluri diferite de valoare p de identitate create prin compararea tuturor structurilor PDB. Rezultatul este adăugat la fișierele textuale care vor fi explicate mai târziu. Nu toate coloanele sunt necesare pentru acest proiect, așa că vor fi explicate doar cele importante.

Primele două coloane conțin codul unic de experiment PDB și identificatorul de lanț, așa cum s-a explicat mai sus pentru înregistrările ATOM . Coloanele 6, 9 și C conțin informații despre reprezentativitatea valorii p, care este nivelul de similaritate al secvențelor calculate de BLAST. Dacă acea valoare este zero, atunci nu este acceptată să facă parte dintr-un set; dacă valoarea este 1, atunci este. Coloanele menționate reprezintă acceptarea mulțimilor cu limite de valori p de 10e-7, 10e-40 și, respectiv, 10e-80. Pentru analiză vor fi folosite doar seturile cu o limită a valorii p de 10e-7.

Ultima coloană conține informații despre acceptabilitatea unei structuri, unde a este acceptabil și n nu.

 #--------------------------------------------------------------------------------------------------------------------------- # 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

Construcția bazei de date și analizarea datelor

Acum că avem o idee despre cu ce avem de-a face și despre ce trebuie să facem, să începem.

Descărcarea datelor

Toate datele pentru această analiză pot fi găsite la aceste trei adrese:

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

Primele două link-uri conțin o listă de arhive. Arhiva cea mai recentă din fiecare ar trebui să fie utilizată pentru a evita problemele care decurg din lipsa rezoluției sau a calității. Al treilea link conține direct cea mai nouă arhivă de taxonomie.

Analizarea datelor

De obicei, analiza fișierelor PDB se face prin pluginuri sau module în Java, Perl sau Python. În cazul acestei cercetări, am scris o aplicație Perl personalizată fără a utiliza un modul de analiză PDB pre-scris. Motivul pentru care este analizarea unei cantități mari de date, din experiența mea, cea mai frecventă problemă cu utilizarea datelor experimentale este erorile în date. Uneori apar erori cu coordonatele, distanțele, lungimile liniilor, comentariile în locuri unde nu ar trebui să fie etc.

Cel mai eficient mod de a rezolva acest lucru este de a stoca inițial totul în baza de date ca text brut. Analizatoarele obișnuite sunt scrise pentru a trata datele ideale care se conformează complet specificațiilor. Dar, în practică, datele nu sunt ideale și asta va fi explicat în secțiunea de filtrare, unde veți găsi scriptul de import Perl.

Construcția bazei de date

Când construiți baza de date, rețineți că această bază de date este construită pentru procesarea datelor. Analiza ulterioară se va face în SPSS sau R. Pentru scopurile noastre aici este recomandat să folosiți PostgreSQL cu cel puțin versiunea 8.4.

Structura tabelului este copiată direct din fișierele descărcate cu doar câteva mici modificări. În acest caz, numărul de înregistrări este mult prea mic pentru ca să merite să ne petrecem timpul pe normalizare. După cum sa menționat, această bază de date este de unică folosință: aceste tabele nu sunt create pentru a fi difuzate pe un site web, ci doar pentru procesarea datelor. Odată ce s-a terminat, ele pot fi abandonate sau salvate ca date suplimentare, poate pentru repetarea procesului de către alt cercetător.

În acest caz, rezultatul final va fi un tabel care poate fi apoi exportat într-un fișier pentru a fi utilizat cu un instrument statistic precum SPSS sau R.

Mese

Extragerea datelor din înregistrările ATOM trebuie conectată la înregistrările HEADER sau TITLE . Ierarhia datelor este explicată în imaginea de mai jos.

Deoarece această imagine este o reprezentare simplificată a unei baze de date în a treia formă normală (3NF), pentru scopurile noastre, conține prea multă suprasarcină. Motivul: pentru a calcula distanța dintre atomi pentru detectarea legăturii disulfurice, ar trebui să facem îmbinări. În acest caz, am avea un tabel alăturat la sine de două ori și, de asemenea, unit la o structură secundară și primară de două ori fiecare, ceea ce este un proces foarte lent. Deoarece nu orice analiză are nevoie de informații de structură secundară, se propune o altă schemă în cazul în care trebuie să reutilizați datele sau să analizați cantități mai mari de legături disulfură:

Legăturile disulfură nu sunt atât de frecvente ca și alte legături covalente, așa că nu este necesar un model de depozit, deși ar putea fi folosit. Schema stea și modelarea dimensională de mai jos vor dura prea mult timp pentru a se dezvolta și vor face interogările mai complexe:

În cazurile în care toate obligațiunile trebuie procesate, atunci recomand schema stea.

(În caz contrar, nu este necesar, deoarece legăturile disulfură nu sunt la fel de comune ca și alte legături. În cazul acestei lucrări, numărul de legături disulfură este aproape de 30.000, ceea ce poate fi suficient de rapid în 3NF, dar am decis să o procesez prin intermediul un tabel nenormalizat, deci nu este ilustrat aici.)

Numărul total așteptat al tuturor legăturilor covalente este de cel puțin dublul numărului de atomi din structura terțiară și, în acest caz, 3NF ar fi foarte lent, deci este necesară denormalizarea folosind forma de schemă stea. În această schemă, unele tabele au două verificări ale cheilor străine, și asta pentru că se creează o legătură între doi atomi, astfel încât fiecare atom trebuie să aibă propriul său primary_structure_id , atom_name_id și residue_id .

Există două moduri de a completa tabelul de dimensiuni d_atom_name : din date și din altă sursă, dicționarul de componente chimice pe care l-am menționat mai devreme. Formatul său este similar cu formatul PDB: sunt utile numai liniile RESIDUE și CONECT . Acest lucru se datorează faptului că prima coloană a lui RESIDUE conține un cod rezidual din trei litere, iar CONECT conține numele atomului și conexiunile acestuia, care sunt, de asemenea, nume de atom. Deci, din acest fișier, putem analiza toate numele atomilor și le putem include în baza noastră de date, deși vă recomand să permiteți posibilitatea ca baza de date să conțină nume de atom nelistate.

 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

În acest proiect, viteza de codificare este mai relevantă decât viteza de execuție și consumul de stocare. Am decis să nu mă normalizez - la urma urmei, scopul nostru este să generăm un tabel cu coloanele menționate în introducere.

În această parte, vor fi explicate doar cele mai importante tabele.

Tabelele principale sunt:

• proteins ​​: tabel cu nume și coduri de experiment.
• ps : Tabelul de structură primară care va conține sequence , chain_id și code .
• ts : Tabel care conține structura terțiară/cuaternară extrasă din datele brute și transformată în format de înregistrare ATOM . Acesta va fi folosit ca masă de punere în scenă și poate fi abandonat după extracție. Liganzii sunt excluși.
• sources : Lista organismelor din care au fost derivate datele experimentale.
• tax_names , taxonomy_path , taxonomy_paths : nume de taxonomie linneene din baza de date de taxonomie NCBI, utilizate pentru a obține căi de taxonomie de la organismele listate în sources .
• nr : Lista proteinelor neredundante NCBI extrase din setul NR.
• pdb_ssbond : Lista legăturilor disulfurice dintr-un fișier PDB dat.

Filtrarea și prelucrarea datelor

Datele sunt preluate din instantanee din depozitul RCSB PDB.

Fiecare fișier este importat într-un singur tabel raw_pdb în baza noastră de date PostgreSQL folosind un script Perl. Scriptul folosește tranzacții de 10.000 de inserții pe bucată.

Structura lui raw_pdb este următoarea:

Scriptul de import arată astfel:

 #!/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;

După ce liniile sunt importate, acestea sunt analizate folosind funcțiile pe care le vom defini mai jos.

Din datele raw_pdb , generăm tabelele ts , ps , proteins , sources , sources_organela și ss_bond prin analizarea înregistrărilor corespunzătoare.

Tabelul ps are trei coloane importante: chain , length și sequence . Secvența de proteine ​​este generată folosind atomi C-alfa pentru fiecare lanț și pentru fiecare reziduu ordonat după secvența de reziduuri, luând doar prima inserție și prima locație alternativă. chain este luat din coloana TS.chain , iar length este pur și simplu lungimea precalculată a șirului de sequence . Deoarece acest articol este menit să analizeze numai lanțuri unice și conexiuni intralanțuri, proteinele cu lanțuri multiple sunt omise în analiza noastră aici.

În înregistrările SSBOND , toate legăturile disulfură sunt stocate în tabelul pdb_ssbond , care moștenește din tabelul pdb_ssbond_extended . pdb_ssbond arată astfel:

Am adăugat și acești indecși:

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

Se presupune că distribuția legăturilor disulfurice înainte de limitare este gaussiană (fără testare cu, de exemplu, testul KS), astfel încât abaterile standard au fost calculate pe fiecare distanță dintre cisteine ​​din aceeași proteină pentru a descoperi intervalul de lungimi permise de legături și a le compara. până la tăietură. Limita a fost aceeași cu media calculată plus-minus trei abateri standard. Am extins intervalul pentru a introduce mai multe posibile legături disulfurice care nu au fost înscrise în fișierul PDB în rândurile SSBOND , dar pe care le-am introdus singuri prin calcularea distanțelor dintre înregistrările ATOM . Intervalul ales pentru ssbonds este între 1,6175344456264 și 2,48801947642267 Å, ​​care este media (2,05) plus-minus patru abateri standard:

 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;

Tabelul TS conține coordonatele tuturor atomilor, dar vor fi folosite doar cisteinele, cu sulful lor numit " SG " . Așadar, este creat un alt tabel de pregătire cu atomi de sulf " SG " pentru a accelera procesul prin reducerea numărului de înregistrări de căutat. Atunci când se selectează numai sulfuri, numărul de combinații este mult mai mic decât în ​​cazul tuturor atomilor - 194.574 dintre primii, comparativ cu 122.761.100 dintre cei din urmă. În cadrul acestui tabel unit cu el însuși, distanțele sunt calculate folosind distanța euclidiană, iar rezultatele sunt importate în tabelul pdb_ssbond , dar numai acolo unde distanța este între lungimile definite calculate mai devreme. Motivul pentru care faceți această accelerare este reducerea timpului de rulare din nou a întregului proces - în scopuri de verificare - păstrându-l într-o zi.

Pentru a curăța legăturile disulfurice, folosim următorul algoritm:

• Ștergeți când ambele părți ale conexiunii indică același aminoacid
• Ștergeți obligațiunile a căror lungime nu este între 1,6175344456264 și 2,48801947642267
• Eliminați inserțiile
• Îndepărtați legăturile cauzate de locații alternative ale atomilor, dar părăsind prima locație

Codul pentru aceasta (luând tabelul pdb_ssbond ca prim argument) este:

 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;

Cu aceasta, setul neredundant de proteine ​​este importat în tabelul nr , care este alăturat tabelelor ps și proteins , și seturile sunt marcate ( set7 , set40 și set80 ). La final, în funcție de cantitatea de proteine, va fi analizat un singur set. Lanțurile nepotrivite dintre PDB și NR sunt eliminate din analiză.

Proteinele fără legături disulfurice sunt excluse din cercetare, împreună cu proteinele care nu aparțin niciunui set. Datele sunt procesate cu DSSP, iar aceste fișiere care au avut probleme de rezoluție sau prea mulți atomi pentru a fi procesați sunt de asemenea excluse. Numai proteinele cu lanțuri simple sunt utilizate ca rezultat pentru analiză, deoarece conexiunile interchain nu au fost păstrate, deși sunt ușor de calculat din tabelul ssbond prin numărarea numărului de conexiuni care au lanțuri diferite.

Pentru proteinele rămase, se face o actualizare pentru numărul total de legături și numărul de legături care se suprapun, iar acest lucru se face pentru fiecare dintre seturi.

Organismul sursă este extras din înregistrările SOURCE . În cazurile în care este necunoscut, sintetic, proiectat, artificial sau hibrid, este eliminat din cercetare. Proteinele cu rezoluție scăzută sunt, de asemenea, excluse numai atunci când lanțul lor lateral nu este vizibil.

Înregistrările SOURCE sunt stocate în tabelul sources , care conține rânduri de taxonomie. În unele cazuri, taxonomia lipsește sau este incorectă. În aceste cazuri, este necesară corectarea manuală a experților.

Din sursa și taxonomia descărcate din NCBI, clasa este atribuită fiecărei structuri primare. În cazul în care o clasă nu poate fi atribuită, proteina este eliminată din lista de analiză. Știind că sunt utilizate bazele de date biologice, se recomandă efectuarea unei verificări suplimentare a tuturor înregistrărilor sursă și a claselor de taxonomie NCBI de către un biolog, altfel ar putea apărea probleme cu clasificările între diferite domenii. Pentru a potrivi locațiile celulare sursă cu ID-urile taxonomiei, datele din tabelul sursă sunt extrase în tabelul sources_organela , unde toate datele sunt scrise ca cod, etichetă și valoare. Formatul acestuia este prezentat mai jos:

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

Arhiva de taxonomie pe care dorim să o folosim este un fișier ZIP care conține șapte fișiere dump. Dintre aceste fișiere, două dintre cele mai importante sunt names.dmp și merged.dmp . Ambele fișiere sunt fișiere CSV delimitate cu tab-uri, așa cum este detaliat în documentație:

• Fișierul merged.dmp conține o listă cu ID-urile taxonomiilor anterioare și ID-urile taxonomiei curente în care fiecare a fost îmbinat.
• names.dmp conține aceste coloane importante în această ordine:
  • tax_id : ID-ul taxonomiei
  • name_txt : numele speciei și, dacă este cazul, numele unic (în cazul în care speciile pot fi găsite cu mai multe nume, acest lucru ajută la dezambiguizare)
• division.dmp conține numele domeniilor de nivel superior pe care le vom folosi ca clase.
• nodes.dmp este tabelul care conține o structură ierarhică a organismelor folosind ID-uri de taxonomie.
  • Conține un ID de taxonomie părinte, o cheie străină care poate fi găsită în names.dmp .
  • De asemenea, conține un ID de divizie care este important pentru noi să stocăm corect datele relevante ale domeniului de top.

Cu toate aceste date și corecții manuale (setarea domeniilor corecte de viață) am reușit să creăm structura tabelului taxonomy_path . O eșantionare de date arată astfel:

 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 ca intermediar de procesare

În această lucrare, am arătat cum să procesăm datele, de la preluare la analiză. Când lucrați cu date științifice, uneori este necesară normalizarea, iar alteori nu. Când lucrați cu cantități mici de date care nu vor fi reutilizate pentru o altă analiză, atunci este suficient să le lăsați denormalizate acolo unde procesarea este suficient de rapidă.

Motivul pentru care acest lucru a fost făcut într-o bază de date bioinformatică este că PostgreSQL este capabil să integreze mai multe limbi. Aceasta include R, care poate face analize statistice direct în baza de date - subiectul unui articol viitor despre instrumentele bioinformatice.

Mulțumiri speciale colegilor Toptal, Stefan Fuchs și Aldo Zelen, pentru consultațiile lor neprețuite.