Document

Informazioni e database
L'importanza di informarsi (e di farlo bene) anche nel contesto delle Biotecnologie.
Viviamo in un periodo in cui l'interconnessione tra le persone, tra queste e le fonti di informazione, è
sempre più presente e importante. Apparentemente, quindi, risulta facile ottenere le informazioni
d'interesse.
Esistono però dei limiti, il primo dei quali è il crescente "rumore di fondo", generato da
informazioni irrilevanti, secondarie e molto spesso ampiamente ridondanti. Probabilmente,
ciascuno di noi ha incontrato più di una volta questo problema "lanciando" semplici ricerche con
Google e ricevendo come risultato decine o centinaia di pagine ridondanti di fonti secondarie,
terziarie..., relative a domande sul tema (magari prive di risposta, o con risposte poco serie o errate)
ecc. Tale rumore di fondo, amplificato dalla prassi del "rilancio" di notizie, commenti e documenti, in
pratica relega l'informazione utile in posizione poco consultabile (ad esempio tra gli ultimi risultati),
impedendo a chi ha fatto la richiesta di individuarla come l'ago nel pagliaio, sebbene l'informazione
stessa fosse stata estratta dal motore di ricerca. Estratta, e poi ri-sepolta dal rumore di fondo.
Un secondo limite è riconducibile alla disinformazione: che si tratti di scienza, sport, politica,
economia, nelle ricerche in rete si incontrano spesso fonti per nulla o scarsamente attendibili che,
per l'assenza di adeguati meccanismi di controllo e feedback, riportano informazioni totalmente o
parzialmente infondate, o distorte. La diffusione di informazioni false, diffamatorie o tendenziose, i
"polveroni" di informazioni fuorvianti e contraddittorie sollevati ad arte per sviare e svilire inchieste e
l'insabbiamento di informazioni veritiere attraverso il gran risalto dato a uno o più eventi secondari
contemporanei o generati proprio per seppellire la notizia scomoda in un trafiletto in pagine
secondarie sono ben note tecniche di manipolazione delle informazioni a fini di lotta politica. Ci si
attende, tuttavia, che le informazioni nel (e dal) mondo "non politico" siano decisamente meno
contaminate e quindi più affidabili. In realtà, invece, in ogni campo bisogna essere prudenti: "voci" e
"rumors" infondati ma diffusi ad hoc possono influenzare le borse, la quotazione di un'azienda e
perfino la solidità del bilancio di uno stato, mettere fuori strada la concorrenza, favorire o sminuire il
successo commerciale di un prodotto, di un albergo ..... tutto ciò, però, è ancora una volta
riconducibile a "disinformazione intenzionale" e si immagina che questo non avvenga almeno nel
campo della ricerca scientifica. E' una presunzione d'innocenza un po' ingenua, soprattutto quando ci
sono in ballo tanti, tanti soldi, come nel caso di prodotti pharma-biotech strategici. Ma il motivo per
cui spesso si incontrano informazioni errate, infondate o distorte è che gran parte delle stesse non è
prodotta intenzionalmente, ma in buona fede.... ovvero, chi rilascia tali informazioni in rete è convinto
di fornire un servizio utile alla comunità, rilasciando informazioni che "crede" essere giuste....
producendo invece "disinformazione involontaria"! Un esempio è rappresentato dalle erronee
informazioni che possono essere (talora, non sempre!) tratte da Wikipedia. Molti la considerano una
fonte affidabile e infatti, oltre ad essere utile, spesso riporta anche informazioni di una certa
completezza e correttezza. Tuttavia, bisogna essere consapevoli della sua gestione open: chiunque
puo' creare e modificare le schede. Schede che, certamente, potranno successivamente essere
controllate da altri e corrette, ma nell'intertempo tra immissione dell'informazione errata (o distorta) e
correzione della stessa, tutti coloro che avranno consultato la scheda, ne avranno tratto una o più
informazioni errate. Purtroppo, per la natura di Wikipedia che non ha dei revisori professionali - e
generando e pubblicando schede in qualunque campo, neppure potrebbe permetterseli - più è specifica
e di settore l'informazione errata, tanto più sarà lenta e improbabile la correzione: insomma, se si
inseriscono errori nella scheda wiki dedicata a un personaggio pubblico o un evento famoso, o si
altera la strofa di una canzone nota in tutto il mondo, verosimilmente la scheda sarà corretta quasi in
tempo reale... ma se si crea o modifica, inserendo errori, la scheda wiki di un gene poco caratterizzato,
il rischio che l'errore resti in rete molto a lungo è concreto. Morale: va bene cercare in Wikipedia
informazioni generiche su un gruppo musicale, una città o una squadra di calcio, ma per informazioni
scientifiche, soprattutto in campi specifici, meglio cercare, o almeno poi controllare, utilizzando fonti
qualificate. Un'altro esempio è fornito dalle Yahoo anwers. Si trovano in rete domande su qualsiasi
cosa e quindi anche su "fatti di scienza". Il problema sono le risposte.... a volte è presente una singola
risposta e non sempre chi risponde ha la capacità di tacere (o in questo caso, non scrivere) quando
dovrebbe..... per non parlare del sistema che individua nella "risposta migliore" quella con il maggior
punteggio: tuttavia spesso una risposta è riportata come "migliore" solo perchè la domanda ha
ricevuto... UNA risposta. Mai prendere sul serio il migliore, se non aveva avversari.... Ma anche
quando le risposte sono molteplici, chi ne valuta l'adeguatezza è a sua volta qualificato come giudice?
Ulteriori esempi di informazioni potenzialmente fuorvianti sono quelle tratte da documenti (ppt, pdf,
doc ecc.) ottenuti con Google o altri motori di ricerca e corrispondenti ad elaborati e presentazioni
per esami, tesi di laurea e dottorato: potrebbe trattarsi del lavoro d'ottima qualità, prodotto dal più
brillante tra gli studenti d'ogni tempo, quanto il risultato confuso e pieno di errori del lavoro di un
azzeccagarbugli...... E' importante insomma, "sapersi muovere" tra le informazioni, utilizzando solo
fonti affidabili, ovvero generate e/o referenziate da esperti qualificati nel campo specifico e
comunque validate da robusti sistemi di controllo della qualità.
Un terzo limite è la scarsa consapevolezza dell'utilità delle informazioni disponibili e, soprattutto,
della fondamentale necessità di reperirle e tenersi aggiornati frequentemente: in molti casi si inizia
a lavorare a un progetto senza essere adeguatamente informati su "cosa è stato già scoperto" nel
campo e "cosa stanno facendo gli altri". Cio' porta abbastanza spesso a trovarsi "bruciati" nella
competizione per un brevetto o una pubblicazione, o in casi meno gravi comportare comunque tanto
lavoro inutile in una tesi o un dottorato.... Se da una parte un certo rischio esiste sempre, soprattutto
nei settori più competitivi, ove team fortissimi lavorano in gran segreto, rischiare di perder tempo,
danaro e forse tutto il lavoro fatto solo perchè non abbiamo cercato, o saputo individuare, preziose e
necessarie informazioni pubblicamente disponibili, ha minori giustificazioni...
Informatica per le Biotecnologie, quindi, deve innanzitutto aiutarci a trovare e gestire informazioni!
Differenza tra servers, database e tools di ricerca e analisi.
Attualmente, le principali risorse bioinformatiche sono accessibili gratuitamente, presso istituzioni di
tipo accademico/pubblico, o a pagamento, presso grandi ditte con team bioinformatici, attraverso
internet. Si definisce postazione client il computer con cui si accede via internet alle risorse di un
server remoto, che può essere sulla stessa scrivania, nello stesso edificio o a migliaia di km di
distanza. Il computer locale o remoto può consentire l'uso di software (o tools) bioinformatici e la
gestione ed interrogazione di database.
Requisiti fondamentali di un database
Alla domanda "cos'è un database?" molti si scoprono in difficoltà, immaginando una risposta
complicata ... Niente di più semplice in realtà! I primi database erano cartacei; basti pensare agli
schedari ed alle cassettiere; l’avvento dei computer ha reso possibile “dematerializzare”, ovvero
immagazzinare i dati in formato digitale, trasformando i database da insiemi di fogli di carta a files.
Tuttavia il concetto non cambia: si tratta di insiemi di dati. Ciò che accomuna database cartacei
“vintage”e database informatici e li differenzia da un insieme disordinato e/o disomogeneo di dati è la
necessità di “ordine ed omogeneità”: un database non solo è una semplice collezione di dati, poiché i
dati devono essere depositati e mantenuti secondo un certo ordine strutturale, che comporta
omogeneità di organizzazione, pur nella differenza dei dati contenuti. Inoltre è fondamentale (e
reso estremamente facile dal formato digitale) che i database siano conservati in copie multiple (backup), per evitare la perdita irreversibile nel caso siano depositati in un solo computer. Per i grandi
database, la distruzione di hard disk o computer rappresenta una perdita minima rispetto all'immenso
valore dei dati, cosicchè è fondamentale garantire che copie multiple siano salvate su più supporti e
server. La distribuzione multi-server ha anche un altro scopo: facilita e velocizza l’accesso,
garantendo contimuità del servizio agli utenti remoti mediante reindirizzamento ai mirror sites: la
modalità di mirroring è particolarmenta utile quando un server molto utilizzato è offline per problemi,
manutenzione o ha un accesso rallentato da troppe utenze contemporanee.
Elementi cruciali dei database: schede, campi e valori.
La figura a destra esemplifica un piccolissimo database:
Si tratta di testo non formattato, ovvero salvato con un editor di testo, che non aggiunge i tag di
formattazione tipici dei word processor (come Microsoft Office o LibreOffice) che appesantiscono il
file: anche un semplice file testo (flat file) può essere un database! Il flat file è un file sequenziale, il
cui testo cioè viene scritto (e letto) in sequenza. I rimandi a capo spesso sono inseriti per consentire
una rappresentazione grafica in pagine, meglio interpretabile dall'occhio umano e più adatta ai mezzi
di visualizzazione (monitor, pagine a stampa ecc.).
Si nota un certo ordine nella disposizione dei dati, distribuiti in 4 gruppi, ciascuno dei quali contiene
cinque tipi di informazioni. Il tutto è intervallato, "scandito" da un sistema ordinato di caratteri.
Ciascuno dei quattro gruppi rappresenta nel mini-database un'unità chiamata entry o record (in
italiano, scheda). L'entry è in pratica una parte di database, che racchiude l'informazione relativa ad
un certo oggetto. Nell’esempio, ciascun record coincide con una persona, di cui descrive numero,
nome, sesso, età ed altezza. Tali caratteristiche, definite fields (in italiano, campi), sono associati a
valori variabili (non necessariamente numerici). Coerentemente con l'ordine e l'omogeneità strutturale
che devono contraddistinguere qualsiasi database, tutte le entries/schede del database devono avere lo
stesso numero, ordine e tipo di campi. Non importa che alcune riportino più informazioni (disponibili
per tutti o quasi tutti i campi) ed altre meno (ovvero manchi l'informazione per alcuni campi): se si
decide di inserire un tipo di informazione creando un campo ad hoc, questo dovrà essere presente in
tutte le entries/schede, anche quando l'informazione/valore non è (ancora...) disponibile. Bisogna
infatti ricordare che i database sono continuamente aggiornati e che, quindi, i valori saranno
progressivamente aggiunti, non appena noti.
In un database flatfile l'organizzazione deve rendere distinguibili record, campi e valori. Nell’esempio
"-----" funge da separatore di record, i due punti delimitino i campi dai rispettivi valori ed i caratteri
di "a capo"(o nuova riga) separano le varie coppie campo-valore:
Il campo chiave o primary key è speciale, poiché non può assumere un valore già appartenente ad un
altro record in quanto deve consentire l'identificazione univoca del record, rendendolo distinguibile
da tutti gli altri. Nell'esempio, i record sono pochi e mostrano valori differenti, ma è intuibile
l'importanza del campo chiave in un database di centinaia o migliaia di records. In tal caso, molti
record possono presentare valori uguali in uno o più campi (stesso sesso, o nome, altezza....) e solo la
numerazione progressiva del campo chiave "numero" consente di distinguere con certezza ciascun
record. Torniamo all’esempio: già con solo 4 record, il campo “sesso” non consente identificazione
univoca, poiché tre soggetti sono maschi. Centriamo ora l’attenzione sul nome, ad esempio Maria. In
Italia è il nome femminile più comune (frequenza pari a circa 7.6%) e nel mini-database di sole 4
persone compare una sola volta. Ampliandosi progressivamente le dimensioni del database, il nome
Maria potrà identificare univocamente una persona solo se associato ad un altro indicatore, ad
esempio l’altezza o l’età, ma prima o poi l’estensione del database determinerà la presenza di persone
uguali per nome, sesso, età e altezza:
Dunque, solo il campo chiave, ovvero un numero progressivo nell’esempio, potrà mantenere
l’identificazione univoca indipendentemente dalle dimensioni del database. Il campo chiave nei
database bioinformatici ha spesso un altro nome e assume valori alfanumerici (numeri e lettere), non
necessariamente progressivi, sebbene unici. La numerazione semplice, infatti, può creare problemi
nelle ricerche, poiché se tutti i database bioinformatici adottassero come chiave primaria i numeri
naturali, a ciascun numero corrisponderebbero i record di più database. Per evitare ciò, nel creare un
nuovo database si ricorre a un sistema di alfa-numerazione tale da evitare sovrapposizioni con quanto
già esistente. Ciò, in fondo, accade anche per i database non bioinformatici: gli identificativi dei codici
fiscali, ad esempio, sono differenti da quelli delle targhe, a loro volta basati su sistemi che consentono
di distinguere la targa di un paese da quella di un altro ecc.
Che i dati in un database siano relativi a persone, merci o biosequenze, la logica di compilazione non
cambia. La figura che segue mostra una porzione della banca dati di proteine Uniprot (curata dal
centro bioinformatico europeo, EBI), nella quale sono visibili un'intera entry e l'inizio della
successiva, marcato dalla sequenza di caratteri "//" che fa da separatrice di record:
I nomi dei campi, rappresentati con due lettere maiuscole ad inizio riga, sono seguiti dai
corrispondenti valori. Le sigle a inizio riga servono anche a far capire che alcuni campi occupano più
righe consecutive (man mano che giungono nuove informazioni grazie al lavoro sperimentale, in molti
casi diventa impossibile contenere tutti i dati in una sola riga di testo). E' possibile ottenere indicazioni
complete sul formato Uniprot (per formato si intende la strutturazione ordinata dei caratteri, non la
presenza di formattazioni. Si tratta sempre di testo semplice) attraverso la sua guida in linea; qui di
seguito, invece, si forniscono indicazioni sui campi principali.
I campi Identification (ID) ed Accession Number (AC) riportano codici identificativi creati dai
gestori del database. Il campo ID solitamente occupa la prima riga di un'entry ed include elementi
descrittivi: nome abbreviato della sequenza, lunghezza, organismo ecc. Invece il campo chiave AC è
un codice alfanumerico, per definizione univoco e stabile rispetto agli aggiornamenti del database.
Mentre l'ID può cambiare (anzi, deve) in conseguenza del miglioramento dell'annotazione - ad es. nel
passaggio da generata automaticamente (preliminary ID) a revisionata manualmente (standard ID) l'AC non cambia ed è preservato. In caso di fusione tra record, ad esempio, tutti gli Accession Number
sono mantenuti e distinti in un AC primario ed uno o più AC secondari. Poiché gli AC sono indicati
in molte pubblicazioni, è molto importante che siano mantenuti: ad esempio, se in un articolo del 2008
ad un gene è associato un certo AC, è possibile giungere alle informazioni più recenti di una nuova
scheda del gene, se all’AC primario della scheda recente è associato l’AC secondario “vecchio”. E'
vero anche il contrario: partendo da un AC più recente si ritrovano gli AC "vecchi" che sono utili
anche per informazioni, associate alle schede originarie, non sempre pubblicate. I database utilizzano
differenti codifiche di AC, per garantire l'identificazione univoca anche tra record di database diversi.
E' quindi opportuno far riferimento all'AC di una sequenza come suo identificativo unico. Esso
permetterà di risalire direttamente e senza incertezze alla entry di interesse in un certo database e, con
buona probabilità, anche in diversi altri.
Accordi tra i principali istituti bioinformatici mondiali favoriscono - attraverso lo scambio reciproco e
periodico delle sequenze depositate - l'aggiornamento delle banche dati, nelle quali sono riportati
come cross references i codici d'accesso relativi ai record equivalenti degli altri database. Uno degli
attuali problemi della bioinformatica è la dispersione dei dati in un numero eccessivo di database: tale
"torre di Babele" elettronica può confondere le interrogazioni e generare false piste. Un aspetto
positivo nello sviluppo dei nuovi database è però la proposizione di nuovi e più efficienti sistemi di
catalogazione, ovvero una continua revisione della struttura con cui le entry sono compilate e dalla
quale dipende la possibilità di interrogazione del database. Talora le organizzazioni che gestiscono i
database più importanti possono trarre suggerimenti da sistemi più efficienti di catalogazione ed
interrogazione associati a database minori. Struttura e contenuto di una entry Uniprot sono riassunte in
una tabella tratta dalla già citata guida in linea.
L'annotazione di una entry dipende da tipologia e numero di campi; la sua qualità non dipende solo
dal numero di caratteristiche riportate, ma soprattutto da quanto correttamente sono immesse in
ciascuna scheda e verificate. La descrizione dei campi può essere più o meno esplicita, in funzione di
sigle o nomi; in tempi recenti si sta diffondendo l'utile abitudine di associare alla sigla o nome del
campo un "link" che rimanda ad una pagina web con le spiegazioni sul campo stesso. Nella scheda
Uniprot, come nelle schede di altri database di biosequenze, rivestono fondamentale importanza, oltre
ovviamente al campo che riporta la sequenza (SQ), i campi relativi alle informazioni tassonomiche
(campi OS , OC ed OX), al nome del gene codificante (Gene Name, GN), alle informazioni
bibliografiche, che riportano la prima pubblicazione inerente la sequenza, ma spesso anche le
successive, alle date (DT) di deposito ed aggiornamento della sequenza. Infine, la differenza in
termini di ricchezza di annotazione tra record in un database e tra database, è da cercare tra le
caratteristiche o proprietà (FEATURES o FT) associate alla sequenza, quali ad esempio attività
biochimica, presenza di domini o motivi ecc. Un riferimento per la ricerca rapida di sequenze
associabili ad un certo argomento o ad una funzione è quanto indicato nel campo delle parole chiave
(KEYWORDS o KW).
Per evitare malintesi è fondamentale conoscere le convenzioni usate dai curatori di un database.
Sapere che parole come "Potential", "Probable" e "By similarity" indicano un'informazione non
supportata da evidenze sperimentali è certamente non marginale...
Si passa ora ad un esempio di database flat file, un formato di dati estremamente diffuso, per
rinsaldare il concetto principale: un database è necessariamente la combinazione di un contenuto e
di un suo ordine strutturale, che nel caso dei file di testo si traduce in una determinata
organizzazione di caratteri. L'entry presentata nella figura precedente è mostrata in differente formato,
in testa ad altre tre che la seguono, nella figura che segue:
Il simbolo ">" segna l'inizio di un record ed è seguito da testo descrittivo, che nell'esempio racchiude
il valore del campo ENTRY_NAME (riga ID del formato Uniprot) e, separati da uno spazio ed in
successione, l'AC delimitato da parentesi tonde ed il valore del campo description (DE). La fine di
questa prima riga coincide con un carattere di "a capo", al quale segue la sequenza aminoacidica
distribuita in righe da 80 caratteri. Si tratta del formato FASTA, estremamente sintetico e snello
(pochi campi rappresentati direttamente dai loro valori), nonché di semplice struttura e per questo il
più usato come formato d'input dagli algoritmi di analisi di sequenza.
Anche in questo caso si deve pensare alle dimensioni dei database: per uno strumento d’analisi
“scorrere” lungo il flatfile contenente le informazioni complete del record standard o quelle ridotte
della sua versione FASTA non fa molta differenza. Quando però deve cercare la sequenza di ciascun
record di un database con decine o centinaia di migliaia di record, la differenza di tempo si sente....
allo stesso tempo, per l'interpretazione rapida, è importante associare alla sequenza non solo l'AC (che
poi rimanda univocamente alla scheda completa) ma anche l'ID (che con la descrizione consente di
farsi velocemente una prima idea dell'oggetto).
L'indicizzazione ed i limiti dei flat file
Le figure appena mostrate sono solo porzioni di due database (UniprotKB/Swiss-Prot, in formato
Uniprot e fasta) che contengono centinaia di migliaia di entries. Va quindi considerata l'enormità di
tali file, che, per quanto contenenti solo semplice testo, rimangono comunque scomodi per ricerche e
modifiche mirate. Un ausilio è sicuramente fornito dall'indicizzazione, ossia dalla creazione di indici
che associano, per il/i principale/i campo/i, i valori assunti alla loro posizione nel file. Esattamente
come gli indici analitici dei libri, questi nuovi file, sicuramente più piccoli e "leggeri", permettono di
raggiungere direttamente una parola all'interno del testo, a vantaggio della velocità di ricerca.
Tuttavia, se dal libro togliamo una pagina, gli indici devono essere riscritti... così come rimane
impossibile operare dirette modifiche "puntuali" senza dover "reimpaginare" tutto... Si può
comprendere come il problema sia costante per database enormi, corrispondenti a un libro con
migliaia o milioni di pagine, in cui ogni giorno fluiscono dati che fanno slittare diverse pagine! In
questi casi una differente organizzazione è assolutamente necessaria.
Database relazionali e DBMS
Questi limiti portano a introdurre l'altro principale tipo di banche dati, i database relazionali ed i
sistemi preposti alla loro gestione, i database managment system (DBMS), che offrono enormi
poteri d'intervento. L'organizzazione dei dati è concettualmente semplice; l'informazione è infatti
strutturata in tabelle, nelle quali ogni riga è un record e ogni colonna un campo:
In pratica, un determinato campo di una specifica entry corrisponde ad una cella e i cambiamenti
nell'informazione in essa contenuta (valore) non determineranno lo spostamento della cella, che avrà
sempre le stesse coordinate. Ciò consente un'indicizzazione stabile e velocizza i sistemi di ricerca,
poichè quando si seleziona un campo, in database flatfile si scorre sequenzialmente nel testo delle
entries, mentre in database tabellari si scorrere nella sola colonna del campo selezionato.
I DBMS permettono di definire, selezionare e manipolare i dati. L'utente può infatti formulare
richieste al DBMS, che provvede ad eseguirle sul database, in un linguaggio specifico o structured
query language (SQL), che non fa uso di codici o simboli algebrici e quindi risulta lineare ed
espressivo, molto vicino ad un elementare inglese tecnico. Le richieste (queries) formulabili possono
essere molto complesse e mirate, grazie alle possibili combinazioni (da qui l'appellativo "structured")
ed all'uso di clausole specifiche. Per quanto le queries possano essere complesse, il DBMS
provvederà a tradurle operativamente. Anche per l'indicizzazione tutto diventa più semplice: una volta
creati gli indici per i campi desiderati, sarà il DBMS a gestirne l'aggiornamento nel tempo. Questo
tipo di rapporto "client-server", molto frequente in informatica, è schematizzato nella figura che
segue; una richiesta formulata in linguaggio SQL è inoltrata al DBMS - tra i più diffusi Oracle,
MySQL e PostgreSQL - che la esegue sul database, restituendo i risultati:
Tutto ciò può, ma non necessariamente deve, verificarsi interamente sul computer locale:
È anche possibile infatti che il database si trovi fisicamente su un altro computer (remoto) più o meno
lontano e collegato in rete al computer locale (figura a sinistra) o che anche il DBMS non sia installato
sul computer locale (figura a destra):
Anche quest'ultimo è un caso di relazione client-server, in cui il computer locale (client) inoltra
richieste ad un secondo computer (server), in cui risiede il DBMS, che provvede alle operazioni sul
database (eventualmente presente su un ulteriore terza macchina...) e restituisce risultati. Solitamente
gli utenti occasionali si collegano come client a server che contengono tutto (DBMS e database, ma
quando sono da svolgere ricerche intensive, non è possibile lavorare on line in modo proficuo. I
server, infatti, adottano due strategie principali per impedire a un singolo client di eseguire migliaia di
richieste: escludono il client, inviando un warning message di attività non consentita, oppure accettano
la sua prima richiesta (ad es. analisi relativa alla prima sequenza), ma mettono la seconda in coda a
tutte le prime richieste degli altri client, la terza in coda a tutte le seconde e così via.... In tal caso, è
necessario dotarsi di DBMS locale e scaricare sul proprio computer i database da consultare (essendo
pubblici, sono liberamente scaricabili dai server bioinformatici insieme a numerosi tools d’analisi).
La trasmissione delle richieste che il client invia al server ed i corrispondenti risultati, possono essere
ulteriormente mediati da interfacce grafiche di facile uso, che permettono di inserire i parametri della
ricerca o più in generale della richiesta e si occupano di trasmetterli al server ed incorporarli nelle
queries. Analogamente, elaborano graficamente i risultati ottenuti dalle interrogazioni. Tale sistema è
comunissimo e chiunque ne avrà fatto esperienza più o meno consapevole navigando il web:
La figura che segue è un esempio di come il risultato di un interrogazione possa essere presentato
attraverso interfaccia grafica. L'esempio non è casuale, perchè raffigura una porzione dell'entry
presentata in precedenza. Si può notare come il suo contenuto sia equivalente:
Un link in fondo alla scheda rimanda alla sequenza in formato fasta, ossia al file di testo:
Si chiude il cerchio... la stessa informazione può essere fornita in maniera semplice (testo non
formattato, ma ben ordinato) o conservata in formato tabellare da programmi gestori appositi, infine
estratta e presentata in vario modo (interfacce web). Tuttavia i concetti di fondo non cambiano e
siamo pronti a riconoscere i dati sotto qualsiasi forma.
Si deve sottolineare il fatto che i database relazionali rappresentano il sistema elettivo per le ricerche,
ovvero meglio si adattano ai comandi dei DBMS. Tuttavia i database sono quasi sempre organizzati
sia in forma tabellare che sequenziale, in modo che la prima possa essere utile per le ricerche veloci e
specifiche e la seconda possa rappresentare l'interfaccia più adatta alla consultazione umana. In
pratica, quando l'entry viene rintracciata, "cliccando" sul link alla stessa (spesso consistente nell'AC),
il sistema non richiama la tabella bensì si collega all'entry in forma flatfile, visualizzata come "pagina"
e quindi più adatta alla lettura da parte dell'essere umano.
Nei database non sempre le informazioni sono interpretabili mediante lettura e talora sono necessari
tools di traduzione grafica. Si confronti ad esempio la figura che segue le entry testuali UniProt:
Niente di nuovo, se non per il diverso contenuto di informazioni! Si comprende che dati in tale
formato possono non essere interpretabili “ad occhio” in assenza di adeguati programmi in grado di
far corrispondere un’immagine alle coordinate atomiche (molecular viewers). In tal modo pagine di
numeri e caratteri sono convertiti a video in immagini come questa:
Invece di dati di sequenza, c'è qualcosa che deriva dalla sequenza, ad un livello successivo di
complessità: la struttura tridimensionale di una proteina, ossia le sue coordinate atomiche nello spazio.
In particolare, in figura é riportata parzialmente una scheda del principale database di strutture, il
ProteinDataBank (PDB): semplice testo che, ben ordinato, racchiude le informazioni di interesse,
raffigurabili poi graficamente con appositi viewers.
Banche dati primarie e secondarie
Mentre le banche dati primarie riportano le informazioni basilari (di fatto le sequenze in sè e le
principali informazioni necessarie ad accompagnarle), le banche dati secondarie aggiungono dalle
prime elementi che, come detto, derivano dalle sequenze. Oltre all'esempio delle coordinate atomiche
(che dipendono dal fold), si possono citare esempi di dati non necessariamente concreti, ma
eventualmente virtuali, che registrano la ricorrenza di elementi regolari all'interno delle sequenze
oppure riportano informazioni peculiari specifiche. Tali informazioni trascendono dalla sequenza,
perchè sono in essa contenuti, ma non appaiaono immediatamente visibili. In pratica, i dati possono
essere “biologicamente” secondari (ad esempio sequenze proteiche dedotte, “secondarie” in quanto
derivanti dalla traduzione con il codice genetico delle sequenze primarie di DNA) o
“informaticamente” secondari (ad esempio, sequenze consenso ottenute per confronto di sequenze
reali). Come si vedrà durante il corso, il passaggio da dati primari a dati secondari non è banale,
perchè segna il passaggio della bioinformatica da mero sistema di gestione di biosequenze a strumento
di dissezione funzionale di elementi biologici. Delle banche dati secondarie si parlerà estesamente
lungo il prosieguo del corso. Nella figura che segue sono riportate le principali banche dati primarie
mondiali:
Organizzazioni internazionali e principali database. Risorse NCBI ed EBI.
Con lo sviluppo delle tecniche di sequenziamento massivo la genomica ha acquisito miliardi di
sequenze, rendendo la quantità di dati da analizzare e gestire enorme. In poche parole, anche la
biologia è divenuta “big science” e il deposito dei dati, ma soprattutto la loro analisi, richiedono
risorse informatiche ingenti e cluster di migliaia di processori:
I piccoli team hanno ancora un ruolo, soprattutto nella creazione e gestione di database
iperspecializzati; tuttavia spesso i loro servizi hanno vita breve perchè l’ideatore o il principale
curatore, spesso un brillante dottorando o post-doc, per motivi di carriera deve lasciare il gruppo e
non sempre è rimpiazzato:
In Europa, molti istituti sono associati alla rete EMBnet (European Molecular Biology network),
strutturata su una serie di "nodi" nazionali, alcuni dei quali hanno caratteristiche particolari. Tanto in
Europa quanto negli USA sono state anche istituite organizzazioni in grado di gestire le grandi
quantità di dati associabili ai database "globali" (preposti a catalogare e annotare massivamente i dati
di sequenza del DNA e delle proteine) ed a numerosi database "specializzati" ma particolarmente
ricchi in sequenze o strutture e relative informazioni. Negli Stati Uniti la più importante
organizzazione bioinformatica è l'NCBI (National Center for Biotechnology Information), sorta in
collaborazione tra la NLM (National Library of Medicine) dell'NIH (National Institute of Health) e
l'agenzia governativa per la ricerca. I database dell’NCBI sono collegati per favorire l’accesso al
maggior numero possibile di informazioni:
In Europa l'EMBL (European Molecular Biology Laboratory, la più importante organizzazione
transnazionale per la ricerca biomolecolare) ha dato origine all'EBI (European Bioinformatics
Institute), che gestisce le banche dati europee. Un altro centro europeo importante è il SIB (Swiss
Institute of Bioinformatics), che per anni ha gestito la miglior banca dati mondiale di sequenze
proteiche (Swiss-Prot) ed attualmente collabora con l'EBI alla gestione ed annotazione delle
sequenze di Swiss-Prot e TrEMBL. Tra i più grandi centri bioinformatici internazionali si possono
citare anche il DKFZ, il CEPH, il SANGER center, ma ve ne sono numerosi altri. La più importante
banca dati giapponese è la DNA Data Bank of Japan o DDBJ, che collabora con EBI e NCBI.
Genbank, EMBL e DDBJ fanno parte della International Nucleotide Sequence Database
Collaboration (INSDC) e scambiano informazioni su base giornaliera.
Tale politica di scambio totale ed accesso libero alle informazioni prevede standard condivisi per la
formattazione delle entries e per la presentazione dei dati. Tuttavia non possono essere esclusi
problemi di interscambio e, considerate anche alcune differenze nell’organizzazione dei campi e
nella definizione dei valori (ad es., uso di nomi alternativi di geni e proteine), quando si effettuano
ricerche su un database è errato dare per certo che le informazioni reperibili siano identiche a quelle
che possono essere ottenute considerando i database collegati.
L'importanza di un database è relativa alle ricerche che un gruppo svolge in un dato momento,
cosicché un database specialistico può essere fondamentale per alcuni e risultare ignoto ad altri. Se
per importanza si intende la completezza dei dati relativi a classi di molecole, progetti genomici,
strutture, organismi modello, allora su tutti spiccano in particolare alcuni database, prevalentemente
europei e americani. E’ difficile separare la realtà di un database da quella del sistema di
interrogazione, poichè gli stessi sono sempre più integrati. Ha più senso, pertanto, fare riferimento a
"poli" bioinformatici, che allocano risorse su più server dedicati ed interconnessi:
- risorse del server EBI: oltre al database EMBL, prima banca dati al mondo di sequenze
nucleotidiche, l'insieme di database gestito dall'EBI comprende anche il database di sequenze
proteiche UniProtKB, nel cui acronimo “KB” sta per “knowledgebase”, ovvero database di
conoscenza, in quanto integra il miglior database mondiale di sequenze proteiche annotate, SwissProt gestito dal SIB, con il più vasto TrEMBL (compilato grazie alla traduzione dinamica delle
sequenze codificanti) e con PIR. L'EMBL database, che include ulteriori risorse, è definito "virtual
library" ed è organizzato in sezioni; ciò è particolarmente utile in quanto consente interrogazioni
limitate a tali sezioni ed a sottosezioni, garantendo ricerche più specifiche e veloci. Ad esempio, la
sottosezione "new" contiene solo le sequenze di più recente immissione nel database; ciò favorisce la
ricerca sistematica poichè, una volta effettuata una ricerca sul database completo, essa potrà essere
aggiornata limitandosi alla sottosezione new, estraendo le ultime sequenze di interesse depositate,
senza perdere tempo a cercarle nell'intero database.
- Genbank: è la più importante banca dati americana, gestita dal l'NCBI e strutturata due anni dopo la
creazione dell'EMBL library. Le schede di Genbank sono organizzate in modo leggermente diverso
rispetto a quelle di EMBL. Sebbene esista un accordo con l'EBI, finalizzato allo scambio reciproco
dei dati, per essere sicuri di reperire il massimo in termini di informazioni, converrà cercare le
sequenze di DNA e proteine sia nei database europei che in quelli americani. In tal caso, si
estraggono molte sequenze ridondanti, ma si identificano anche sequenze presenti in solo uno dei
database o si rilevano differenti predizioni delle sequenze codificanti.
- Ensembl: dedicato alla genomica, integra database e sistema di interrogazione. Nato dalla
collaborazione tra EMBL-EBI e Sanger Institute, è finanziato principalmente da Wellcome Trust.
Gli organismi i cui genomi sono analizzabili presso il sito Ensembl sono molti, a vari livalli di
completezza ed annotazione, tra i quali uomo, topo, ratto, cane, Drosophila e zanzara, C. intestinalis,
C. elegans, lievito ecc.
Oltre ai server “generalisti”, ve ne sono numerosi che sono indirizzati a specifiche comunità di
studiosi. Si possono così distinguere server “organism-based”, sui quali sono allocati i database
nucleotidici e proteici relativi a organismi modello assieme ad informazioni utili per lo studio degli
stessi (pubblicazioni, collezioni di mutanti, link a laboratori ecc.), altri indirizzati a chi opera nel
campo della genetica biomedica, database “molecule-based” (ad esempio relativi ad anticorpi,
kinasi, CD antigens ecc..), “function-based” (raccolte di motif, profili, domini, signatures ecc..),
tassonomici dedicati a studi di filogenesi ecc. Quelli che seguono sono solo alcuni tra numerosi
esempi; NON saranno oggetto di domande specifiche d'esame, ma sono riportati - e si consiglia
comunque la lettura - per utilità di informazione:
- OMIM: il database OMIM (Online Mendelian Inheritance in Man) è dedicato a geni e fenotipi
umani con ereditarietà mendeliana. Chiunque lavori nel campo delle malattie genetiche e della
biomedicina si ritrova costantemente a contatto con informazioni relative ad OMIM.
- GENEATLAS: come OMIM, contiene informazioni utili a chi studia i geni umani ed opera nel
campo della biomedicina e delle malattie genetiche.
- MIPS yeast genome database: il genoma di Saccharomyces cerevisiae ha rappresentato il primo
successo in un progetto di sequenziamento di un intero genoma eucariotico ed il database che ne
contiene la sequenza di DNA è tuttora prezioso per analisi evoluzionistiche e funzionali.
- TAIR (The Arabidopsis Information Resource): Arabidopsis thaliana rappresenta la pianta modello
nella sperimentazione genomica, biomolecolare, evoluzionistica ed agrobiotecnologica, in quanto
sono disponibili ampie collezioni di mutanti ed il suo è stato il primo genoma vegetale sequenziato.
Il sito contiene un database annotato con sequenze genomiche, trascritti e sequenze proteiche di
Arabidopsis, nonchè link a risorse correlate (stock di semi, collezioni di mutanti ecc.).
- ACEDB (A Caenorhabditis Elegans Data Base): è l'equivalente dei database appena illustrati per il
nematode modello genomico e di sviluppo C. elegans; recentemente ha incluso anche dati relativi a
Brachidanio rerio (zebrafish).
- PDB: è un'importantissima risorsa per accedere a strutture proteiche, molto ben organizzata e che
fornisce anche la possibilità di ottenere gratuitamente, via ftp, i software necessari per la
visualizzazione delle strutture.
- PROSITE: rappresenta il più noto esempio di database funzionale (sarà trattato in seguito), ovvero
contenente sequenze associabili a funzioni quali motivi e pattern conservati.
- Pfam: banca dati specializzata nella catalogazione dei domini proteici; sarà trattata più ampiamente
in seguito.
- InterPro: uno dei più recenti "sistemi integrati" per l'analisi delle proteine. Dalla home page di
InterPro si può accedere a numerosi database dedicati.
Non può essere infine dimenticato PubMed, gestita ed aggiornata dall'NCBI, contiene un enorme
numero di referenze bibliografiche e riveste enorme importanza negli studi biomolecolari,
biotecnologici ed anche bioinformatici.
L'elenco potrebbe continuare su molte pagine con numerosi database più o meno "importanti", ma
ciò non è necessario in quanto sistemi di ricerca e server bioinformatici sono interconnessi
dall’ampio uso di "link" all'interno dei campi di ciascuna entry e sulle pagine e sottopagine dei siti.
Interrogazioni semplici e complesse. SRS, Entrez, PubMed/Medline.
La possibilità di reperire informazioni biologiche dipende tanto dai sistemi di interrogazione quanto
dalla struttura che hanno i database. La struttura delle banche dati è variabile ma, indipendentemente
da numero e tipo dei campi presenti nelle entries, o dal numero di queste ultime, le possibilità di
interrogazione dipendono anche dal formato che ha il database. Il formato più semplice (flatfile)
consente la lettura di tutte le informazioni contenute tanto al sistema di elaborazione informatica
quanto, direttamente, all'occhio umano ed il suo formato descrittivo (e sequenziale) si presta bene
alla compilazione rapida ed efficace di database di biosequenze. Tuttavia, le banche dati che
richiedono sistemi di interrogazione più complesse, quali quelle genomiche o alcune banche dati che
riportano dati strutturali, topologici o di network d'interazione adottano sistemi relazionali (tabellari)
o anche object oriented (che possono essere paragonati a scatole cinesi, dal momento che
consistono in oggetti o superclassi che contengono altri oggetti o sottoclassi). I sistemi che
interrogano questi database non procedono in modo sequenziale e si spostano secondo le direttrici
indicate dalle scelte di interrogazione, che orientano le ricerche su specifici oggetti.
I motori di ricerca più utilizzati nella ricerca di sequenze, strutture ed altre informazioni biologiche
sono quelli gestiti dall'NCBI e dall'EBI. Entrambi i motori di ricerca consentono sia l’accesso a
banche dati bibliografiche, in particolare a Medline, che a database di sequenze. Nel tempo le
ricerche bibliografiche con PubMed, motorizzate da Entrez, sono divenute uno standard ed ormai ha
poco senso utilizzare i sistemi alternativi.
La home page di Entrez solitamente è preimpostata per ricerche su PubMed, ma il motore di ricerca
può essere reindirizzato ad un'altra sezione attraverso presente nel menu a tendina. Entrez consente
interrogazioni semplici, nelle quali il termine indicato è cercato in tutti i campi, senza specificità: si
seleziona la sezione di interessa (ref. bibliografiche, sequenze nucleotidiche, proteiche ecc.), poi si
inseriscono nella finestra d’interrogazione una o più parole (in inglese, o in latino per i nomi di
specie), che il sistema di ricerca collega automaticamente con l'operatore booleano "AND". Entrez
può estrarre in tempi brevi molte entries, presentate 20 per pagina, salvo diversa indicazione (da 5 a
500 / pagina) da parte dell'utente. Anche l'ordine di presentazione può essere modificato. La
modalità di presentazione (Display) dell'elenco delle entries è preimpostato su "Summary", ma
l'elenco può presentare anche altri formati, ad esempio per ciascuna entry può essere mostrata la
sequenza in formato FASTA. La scheda completa di ciascuna entry è richiamata "cliccando" sul
relativo accession number:
Negli anni passati Entrez consentiva ricerche abbastanza evolute in tutte le sezioni e ciò permetteva
di limitare abbastanza - anche se non del tutto - il numero di falsi positivi. Progressivamente la
politica di gestione del browser americano ha preferito l’abbondanza di informazioni alla specificità
di estrazione; oggi è ancora possibile rendere le ricerchè più specifiche, ma il sistema non è
particolarmente evoluto:
La politica del motore di ricerca europeo si è indirizzata per molti anni verso ricerche molto più
specifiche, talora perdendo ricchezza d’informazione. La competizione ha portato a due perdenti e
nessun vincitore, poiché ricerche di qualità devono essere sia complete che specifiche; si spera
quindi che una maggiore collaborazioni porti all’integrazione delle risorse.
Nelle interrogazioni semplici è importante tenere a mente regole altrettanto semplici:
- l’uso o l’aggiunta di parole “generiche” come “protein” o “gene” non rende le ricerche specifiche,
poichè queste parole sono estremamente condivise dalle schede
- quando un nome può essere indicato anche come sigla (ad es. protein tyrosine kinase = PTK) è
opportuno svolgere la ricerca in modo non alternativo e non combinatoriale, poichè in alcune schede
potrebbe esserci solo il nome per esteso, in altre solo la sigla ed in altri ancora entrambi.
- per estrarre tutte queste schede si deve usare l’operatore logico “OR”, che cerca il nome esteso o la
sigla indipendentementa dalla presenza dell’altro elemento.
Il motore SRS presso il sito dell'EBI ha consentito fino a febbraio 2013 ricerche molto precise e
sofisticate. Questo motore di ricerca è stato poi acquisito da una ditta e, a partire da marzo 2013, le
banche dati EBI sono state progressivamente rimosse da SRS. Ora sulla home page dell'EBI è
direttamente disponibile un'interfacia di quick search, purtroppo molto più simile a quella di Entrez
che non a quella di SRS, quindi non particolarmente specifica:
sono indicati i nuovi motori di ricerca da utilizzare per ricerche nei singoli database. Alle bance dati
nucleotidiche si può accedere ora attraverso l’interfaccia dell’European Nucleotide Archive (ENA),
che consente interrogazioni, non molto articolate, per testo e per sequenza:
UniprotKB aveva già un suo motore di ricerca, che consente ricerche avanzate ma non quanto quelle
di SRS. In particolare, con il motore di UniprotKB è possibile aggiungere una chiave di ricerca
associandola con uno degli operatori booleani AND, OR o NOT ad un campo specifico. Ciò è
particolarmente utile per eliminare falsi positivi, ad esempio specificando l'organismo da cercare nel
campo OS (organism source) oppure l'attività biochimica nel campo DE (definition). In attesa che
sia sviluppato da EBI un nuovo motore di ricerca integrato evoluto quanto SRS, a scopo didattico si
presentano comunque le caratteristiche di SRS come sistema per le interrogazioni complesse, dal
momento che questo motore di ricerca esiste ancora (è ad esempio reperibile, con più di 1000
libraries consultabili, presso il server DFKZ ad Heidelberg) e soprattutto perchè i meccanismi di
interrogazione che esso utilizza sono di significato generale.
L'interfaccia dell'SRS presenta la possibilità di operare - come Entrez - interrogazioni semplici (in
modalità Quick Text Search); tuttavia SRS è utilizzato al meglio per interrogazioni complesse. In tal
caso il primo passo è la selezione del/dei database in cui effettuare la ricerca, che si effettua nella
Library Page, nella quale compaiono sezioni di database, alcune delle quali sono mostrate già
aperte. La selezione iniziale di uno o più database è il primo passaggio che rende più specifica (e
veloce) l'interrogazione (query), evitando di estrarre positivi da database che non interessano e
risparmiando il tempo di consultarli inutilmente. Sono disponibili informazioni rapide (pop up) o più
approfondite (cliccando il link) su ciascun database disponibile:
Una volta selezionati i database, si passa alla pagina di interrogazione (Query Form), che mette a
disposizione un'interrogazione complessa rendendo compilabili fino a quattro campi (Fields), con
termini di ricerca (search terms) combinati mediante i classici operatori booleani AND, OR e BUT
NOT.
Nella Query Form standard le 4 finestre di ricerca sono preimpostate in modalità di ricerca "AllText"
(ovvero in tutti i campi): ciò richiama il massimo numero di entries ma porta a risultati meno
specifici e ad un elevato rumore di fondo. Inoltre è preimpostata l'opzione "append wildcards to
words", che estrae anche le parole che "contengono" la query. In generale, tale opzione è utile
quando si vuole che non pesi il plurale/singolare (ad esempio, digitando "exon" saranno estratti
anche i record contenenti la parola "exons") ma è da deselezionare quando rischia di far perdere
specificità; ad esempio, in modalità senza wildcard l’interrogazione con "transducin" (nome di una
proteina) è specifica, mentre l’aggiunta della wildcard comporta l’estrazione di numerosi falsi
positivi contenenti la parola "transducing". Numero e tipo di campi in cui effettuare le ricerche
dipendono dal database selezionato; pertanto, se nella library page si sono selezionati più database,
la ricerca può essere effettuata solo nei campi condivisi (ciò non vale solo per SRS, ma per qualsiasi
sistema di ricerca integrato). Ad esempio, se l'interrogazione cercherà sia in EMBL che in
UniProtKB, saranno selezionabili solo i campi condivisi dai due database ma non quelli specifici
dell’uno o dell’altro.
Effettuare ricerche in campi specifici anzichè in modalità All Text rende le interrogazioni più
specifiche e veloci. Ad esempio, con una Quick Search human calcium channel il sistema cercherà
le tre parole in tutti i campi, indipendentemente da ordine ed associazione e saranno quindi estratte
anche schede che non riguardano canali del calcio umani (falsi positivi). Gli esempi possibili sono
numerosi: human channel (nel campo description) per i quali la parola calcium può comparire in
altri campi (regulated by a calcium-dependent protein kinase; interacting with a calcium-binding
protein ecc.), oppure canali del calcio di altri organismi che mostrano similarità con quelli umani
(mouse calcium channel, similar to human....) oppure proteine umane che regolano canali del
calcio (human calcium-dependent protein kinase regulating potassium channel...) ecc.
Per rendere più specifica la ricerca, si potrà sostituire "AllText" con "Description" nella prima
opzione di interrogazione (inserendo nuovamente le parole "calcium channel", che quindi saranno
cercate nel solo campo description e non in tutta l'entry) e con "Organism" nella seconda (inserendo
il nome di specie "Homo sapiens").
Sui siti dedicati a database di tipo genomico può essere seguito un sistema di interrogazione che
prevede una serie di passaggi progressivi, da pagine principali a sottopagine. Ad esempio, Ensembl
media l'accesso a pagine dedicate ai genomi di numerosi organismi modello, anche l'EBI ha una
sezione dedicata alla genomica, ove i genomi sono raggruppati e selezionabili per grandi gruppi
tassonomici.
Ovviamente è improponibile illustrare tutti i motori di ricerca disponibili e si può concludere
ricordando che ne esistono molti, dedicati alla raccolta di informazioni tassonomiche, genomiche,
proteomiche, strutturali, alcuni dei quali possono essere "generali" ed altri molto specializzati,
ovvero con set notevolmente ristretto, sia relativamente aglii oggetti molecolari trattati (ad es., solo
fattori di trascrizione) che alle specie (ad es., solo mammiferi).
© Francesco Filippini e Sandro Vivona, 2007-2018