Risorse scientifiche ad accesso aperto: banche dati digitali

LIVELLO BASE

Un open access o OA è un insieme di principi e una serie di pratiche attraverso le quali i risultati della ricerca sono distribuiti online, senza costi o altre barriere di accesso.

Sommario

 

Risorse scientifiche ad accesso aperto

Introduzione alle risorse «Open Access»

Un open access o OA è un insieme di principi e una serie di pratiche attraverso le quali i risultati della ricerca sono distribuiti online, senza costi o altre barriere di accesso. Con l’accesso aperto in senso stretto (secondo la definizione del 2001), o libre open access, le barriere alla copia o al riutilizzo sono anche ridotte o rimosse applicando una licenza aperta per il copyright.

L’obiettivo principale del movimento dell’accesso aperto è la “letteratura di ricerca peer-reviewed”. Storicamente, questo si è concentrato principalmente sulle riviste accademiche a stampa. Mentre le riviste convenzionali (non ad accesso aperto) coprono i costi di pubblicazione attraverso pedaggi di accesso, come abbonamenti, licenze di sito o tariffe pay-per-view, le riviste ad accesso aperto sono caratterizzate da modelli di finanziamento che non richiedono al lettore di pagare per leggere i contenuti della rivista. L’accesso aperto può essere applicato a tutte le forme di risultati di ricerca pubblicati, compresi gli articoli di riviste accademiche peer-reviewed e non peer-reviewed, articoli di conferenze, tesi, capitoli di libri, monografie e immagini.

Tuttavia, quando si tratta di definire l’accesso “free”, si deve distinguere “gratis” da “libre”.

Al fine di riflettere le differenze del mondo reale nel grado di accesso aperto, la distinzione tra accesso aperto gratuito e accesso aperto libre è stata aggiunta nel 2006 da Peter Suber e Stevan Harnad, due dei co-designer della definizione originale di Budapest Open Access Initiative (BOAI) di pubblicazione ad accesso aperto. Gratis open access si riferisce all’open accesso gratuito e open access libre si riferisce all’accesso online gratuito più alcuni diritti di riutilizzo aggiuntivi. L’open access libre è equivalente alla definizione di accesso aperto nel BOAI, la Dichiarazione di Bethesda sulla pubblicazione ad accesso aperto e la Dichiarazione di Berlino sull’accesso aperto alla conoscenza nelle scienze e negli studi umanistici. I diritti di riutilizzo del libre OA sono spesso specificati da varie licenze Creative Commons specifiche; queste richiedono quasi tutte l’attribuzione della paternità agli autori originali.

Il documento rilasciato nel febbraio 2002 dal BOAI contiene la seguente definizione molto usata:

– Con “open access” a questa letteratura, intendiamo la sua libera disponibilità su Internet pubblica, permettendo a qualsiasi utente di leggere, scaricare, copiare, distribuire, stampare, cercare o collegare i testi completi di questi articoli, strisciarli per l’indicizzazione, passarli come dati al software, o usarli per qualsiasi altro scopo legale, senza barriere finanziarie, legali o tecniche diverse da quelle inseparabili dall’accesso a Internet stesso. L’unico vincolo alla riproduzione e alla distribuzione e l’unico ruolo del diritto d’autore in questo campo, dovrebbe essere quello di dare agli autori il controllo dell’integrità del loro lavoro e il diritto di essere adeguatamente riconosciuti e citati.

Alla luce delle informazioni di cui sopra, l’uso di risorse scientifiche open source deve seguire le regole comunemente adottate. La pubblicazione di risorse scientifiche open source deve anche menzionare chiaramente se sono libre o gratuite e devono essere attribuite all’autore originale.

Introduzione ai dati (livello base)

Cosa sono i “dati”

Secondo il dizionario Merriam-Webster, ci sono tre diverse definizioni di dati:

  1. Informazioni fattuali, come misurazioni o statistiche, utilizzate come base per il ragionamento, la discussione o il calcolo
  2. Informazioni in forma digitale che possono essere trasmesse o elaborate
  3. L’output di informazioni da parte di un dispositivo o di un organo di rilevamento che include informazioni utili e irrilevanti o ridondanti e deve essere elaborato per essere significativo

In questo documento copriremo la maggior parte delle tre definizioni.

Breve storia dei dati

Da quando gli esseri umani hanno iniziato a comunicare, hanno sperimentato la necessità di conservare le informazioni a lungo termine. Conservare le informazioni era necessario ai nostri antenati per garantire la loro sopravvivenza. Trasmettere informazioni attraverso le generazioni permetteva loro di tenere traccia dei potenziali pericoli, ma anche di avere un inventario dei posti migliori per raccogliere il cibo, i punti migliori per la pesca, gli animali più interessanti da cacciare e dove trovare i migliori rifugi. Tutte queste informazioni venivano trasmesse oralmente. Con l’evoluzione della conoscenza e l’invenzione della scrittura, hanno cominciato a memorizzare le informazioni su supporti indelebili.

Senza entrare nel dettaglio dell’evoluzione della rappresentazione delle informazioni, verranno forniti alcuni esempi significativi che hanno aiutato nella strutturazione del pensiero, che hanno portato alla scoperta degli strumenti informatici che usiamo quotidianamente.

Dati prima dell’invenzione dei computer

Man mano che le società umane emergevano, le motivazioni collettive per lo sviluppo della scrittura erano guidate da esigenze pragmatiche. Questi includono società di organizzazione e di governo attraverso la formazione di sistemi giuridici, contratti, atti di proprietà, tassazione, accordi commerciali, trattati, registri censuari, conservazione della storia, mantenimento della cultura, tenere traccia scoperte scientifiche, codificando le conoscenze attraverso curricula ed elenchi di testi che sono artisticamente eccezionale o ritenuto contenere fondamento conoscenza, e molte altre esigenze.

Figura 1: Scrittura cuneiforme

Ad esempio, intorno al 4 ° millennio a.C., la complessità del commercio e dell’amministrazione in Mesopotamia ha superato la memoria umana, e la scrittura è diventata un metodo più affidabile per registrare e presentare le transazioni in una forma permanente.

Il cuneiforme fu uno dei primi sistemi di scrittura, inventato dai Sumeri nell’antica Mesopotamia. Si distingue per i suoi segni a forma di cuneo su tavolette di argilla, realizzati per mezzo di una ape smussata per uno stilo, come dimostrato in Fig. 1.

Nel corso del tempo, lo sviluppo della conoscenza, la moltiplicazione delle informazioni, la limitazione della memoria umana, la necessità di scrivere e tenere traccia di enormi quantità di informazioni è diventato essenziale. Tuttavia, nonostante abbia tenuto traccia di quasi tutti i tipi di informazioni o dati su vari supporti, è diventato sempre più complesso recuperarli in modo semplice. Bisognava leggere decine di rapporti e libri per poter sintetizzare su un argomento.

Dati nell’era moderna

Oggi, la quantità di dati prodotti ogni anno e conservati digitalmente, ad esempio, liste di cose da fare, ricette, promemoria, giornali di bordo, mappe, foto, e-mail, dati scientifici, rapporti politici, video, ecc. è così esponenziale da creare la necessità di strutturare il modo in cui possiamo recuperare queste quantità fenomenali.

I computer hanno guadagnato popolarità e sono diventati convenienti da usare per gli individui e le aziende private nei primi anni ’80. Tuttavia, gli anni 60 possono essere considerati come la nuova era nel campo dei database. L’introduzione del termine “database” coincise con la disponibilità dello stoccaggio ad accesso diretto o DAS, dalla metà degli anni 60 in poi. Questa nuova tecnologia rappresentava un contrasto con le passate schede perforate e i sistemi basati su nastro, permettendo un uso interattivo condiviso piuttosto che l’elaborazione quotidiana in batch. Furono sviluppati due modelli di dati principali – il modello di rete “CODASYL” (Conference on Data System Language) e il modello gerarchico “IMS” (Information Management System).

La prima generazione di sistemi di database era “navigazionale, in opposizione all’accesso sequenziale dovuto alle precedenti tecnologie usate per memorizzare i dati, cioè nastri e schede perforate. Le applicazioni tipicamente accedevano ai dati seguendo i puntatori da un record all’altro. I dettagli di memorizzazione dipendevano dal tipo di dati da memorizzare.

L’aggiunta di un campo extra a un database richiedeva la riscrittura dello schema di accesso/modifica sottostante. L’enfasi era sui record da elaborare, non sulla struttura generale del sistema. Un utente avrebbe bisogno di conoscere la struttura fisica del database per interrogare le informazioni. Un database che si dimostrò essere un successo commerciale fu il sistema “SABRE” che fu usato da IBM per aiutare American Airlines a gestire i suoi dati di prenotazione. Questo sistema è ancora utilizzato dai maggiori servizi di viaggio per i loro sistemi di prenotazione.

Nella moderna tecnologia dell’informazione, c’è sempre stata confusione tra gli utenti tra i database e i motori di ricerca web a cui si accede tramite browser. Un database di solito contiene dati strutturati, in contrasto con il World Wide Web (www), che di solito contiene dati non strutturati. Anche se il recupero di informazioni da entrambi i database e “www” sono senza soluzione di continuità e sembrano simili, il contenuto e il modo in cui le query sono affrontate sono completamente diversi. I dati strutturati e non strutturati saranno spiegati più avanti in questo documento.

Comprendere il vocabolario di base

Terminologia

Come ogni altra scienza, l’informatica ha un proprio linguaggio. Per comprendere appieno le informazioni che verranno fornite in questo documento, è essenziale acquisire familiarità con il vocabolario relativo a questo argomento.
Inoltre, la comunicazione con un DBA (Database Administrator) sarà facilitata. Quando un Biochimico dovrà esprimere le sue esigenze in termini di strutturazione o gestione dei dati in un Database, sarà tentato di usare il suo linguaggio tecnico. Allora il DBA dovrà capire la richiesta e trasformarla in un linguaggio informatico, che sarà comprensibile ai biochimici.

Cosa sono i “Dati” nell’era del computer

Figura 2:Un bit può essere 0 o 1

Come menzionato nella sezione 2.1, a seconda del dominio a cui ci si riferisce, i dati possono avere significati diversi. Nel caso dell’informatica e dei database, i dati sono definiti come qualsiasi sequenza di uno o più simboli. I dati richiedono un’interpretazione per diventare informazioni. Nell’informatica il “bit” è la più piccola quantità di dati. Un bit è binario. I numeri binari sono una rappresentazione dei numeri che usa solo due cifre, 0 e 1 (Fig. 2). È un sistema numerico in base 2, cioè:

  • 0 0 0 1 = valore numerico 20
  • 0 0 1 0 = valore numerico 21
  • 0 1 0 0 = valore numerico 22
  • 1 0 0 0 = valore numerico 23

Tabella 1

Una sequenza di “bit” costituisce un “Byte”. I byte sono composti da un multiplo di 4 bit (un byte di 4 bit è chiamato Nibble) come nell’esempio precedente. Oggi, il byte è un’unità di informazione digitale che consiste più comunemente in otto bit. Storicamente, il byte era il numero di bit usato per codificare un singolo carattere di testo in un computer. Con un byte di otto bit il numero decimale massimo è 256. Storicamente, il byte è anche l’unità di informazione del computer o la capacità di immagazzinamento dati usata per misurare la quantità di dati (Tabella 1).

Tabella 2: ASCII Tabella

Un esempio di utilizzo è la tabella ASCII (American Standard Code for Information Interchange) dei caratteri comunemente utilizzati per i caratteri alfabetici (Tabella 2). I primi 32 caratteri sono denominati caratteri di controllo. Inizialmente, essi non erano progettati per rappresentare informazioni stampabili, ma per controllare i dispositivi che utilizzano codice ASCII, ad esempio le stampanti, o per fornire meta-informazioni sui flussi di dati, ad esempio quelli memorizzati su nastro magnetico.

Che cos’è “Metadati”

Figura 3: Foto scattata in Grecia

I metadati, o, in parole povere, le meta-informazioni, servono a referenziare i dati sui dati. Avere dei dati non è sufficiente per metterli semplicemente online. I dati non sono utilizzabili finché non possono essere spiegati in un modo che sia l’uomo che il computer possono elaborare.

I metadati possono essere impliciti, specificati o forniti. Esso comprende data relativi a eventi fisici, o processi, e avrà anche una componente temporale. In quasi tutti i casi questa componente temporale è implicita. esso Può essere leggermente difficile capire, tuttavia Di seguito sono riportato i seguenti esempio fornirà una spiegazione più chiara di questo termine.

Figura 4:
Metadati dell’immagine

Immaginate di essere in viaggio con il vostro smartphone preferito in qualche isola paradisiaca. Iniziate a scattare delle foto (Fig. 3) per conservare un bel ricordo del vostro viaggio. Una settimana dopo, il vostro viaggio arriva alla fine e dovete tornare a casa.

Tornato a casa, inviti i tuoi migliori amici per una festa e vuoi condividere con loro le bellezze che hai visto durante il tuo viaggio. Iniziate a mostrare le foto, ma non riuscite a ricordare quale giorno, a che ora e dove sono state scattate alcune di esse. È qui che i metadati delle foto possono aiutare. In poche parole, è la descrizione dei dati. In questo esempio, l’immagine è il dato e la descrizione dell’immagine è il metadato (Fig. 4).

Nella biotecnologia, bisogna capire che i metadati sono di gran lunga più importanti dei dati. È molto semplice capire il motivo per cui i metadati sono un componente cruciale direttamente correlata ai dati. Immaginate un esperimento che porterà a un risultato specifico. Questo esperimento, per essere valido, deve essere documentato. Questa documentazione deve includere tutte le condizioni in cui è stato condotto l’esperimento.  Ciò potrebbe includere la descrizione del tipo di materia prima utilizzata, la sua fonte, in quali condizioni è stata raccolta, i tipi di macchine per elaborare l’esperimento, la temperatura, la data, l’ora, ecc. Affinché il risultato di questo esperimento sia paragonabile ad altri risultati di esperimenti simili, tutte le condizioni devono essere simili. I dati grezzi senza metadati sono inutili.

La sfida più grande nel Biotech, e in qualsiasi altra scienza, è standardizzare i metadati. Nella maggior parte delle banche dati biotech, questo non è rispettato. Bisogna essere assolutamente consapevoli di questo fenomeno e rispettare pienamente le norme.

Che cos’è un “Database”

Figura 5: Struttura parziale del database

In generale, un database è definito come una collezione di dati, come elenchi telefonici, liste di prezzi, liste di inventario, indirizzi di clienti, ecc. Tuttavia, in termini tecnici, un database è definito come “una collezione auto-descrittiva di record integrati”. Implica una tecnologia informatica, completata da un linguaggio informatico specifico, come SQL (Structured Query Language).

Un database è composto da più tabelle (Fig. 5) e da dati e metadati. I metadati sono i dati che descrivono la struttura dei dati all’interno di un database. Se sapete come sono disposti i vostri dati, allora potete recuperarli. Dato che il database contiene una descrizione della propria struttura, viene definito auto-descrittivo. Il database è integrato perché include non solo i dati ma anche le relazioni tra di essi.

Il database memorizza i metadati in un’area chiamata dizionario dei dati, che descrive le tabelle, le colonne, gli indici, i vincoli e altri elementi che compongono il database.

Poiché un sistema di file piatto, cioè “Spreadsheet”, non ha metadati, le applicazioni scritte per lavorare con i file piatti devono contenere l’equivalente dei metadati come parte del programma dell’applicazione.

Cosa sono le “Tabelle” in un database

Una tabella è una raccolta di dati correlati in un formato di tabella composto da colonne e righe all’interno di un database. Assomiglia a un foglio di calcolo (Fig. 6).

Cosa sono le “Colonne” in un database

Figura 6: Tabella con righe e colonne

Una colonna è un insieme di valori di dati, tutti di un unico tipo, in una tabella. Le colonne definiscono i dati in una tabella. La maggior parte dei database permette alle colonne di contenere dati complessi come immagini, interi documenti o anche video clip. Quindi, una colonna che permette valori di dati di un solo tipo non significa necessariamente che abbia solo valori di testo semplici. Alcuni database vanno anche oltre e permettono ai dati di essere memorizzati come file sul sistema operativo, mentre i dati della colonna contengono solo un puntatore o un link al file effettivo. Questo è fatto allo scopo di mantenere la dimensione complessiva del database gestibile – una dimensione minore del database significa meno tempo per i backup e meno tempo richiesto per cercare i dati all’interno del database.

In una tabella a ogni colonna vengono in genere assegnati un tipo di dati e altri vincoli, che determinano il tipo di valore che può essere archiviato in tale colonna. Ad esempio, una colonna potrebbe accettare indirizzi di posta elettronica e un’altra potrebbe accettare numeri di telefono con un vincolo di 10 cifre.

Che cos’è un “Record”

Un record è una rappresentazione di un oggetto fisico o concettuale. Diciamo, per esempio, che si vuole tenere traccia dei clienti di un’azienda. Si assegna un record per ogni cliente. Ogni record ha più attributi, come nome, indirizzo e numero di telefono. I singoli nomi, indirizzi e così via sono i dati.

Che cosa sono gli “Indici”

Figura 7: Esempio di indice

I dati strutturati sono memorizzati sotto forma di record in un database. Ogni record ha un campo chiave, che lo aiuta ad essere riconosciuto in modo univoco, cioè l’ID di un paziente. Nessun altro paziente può avere lo stesso numero ID, ma un altro paziente può avere lo stesso nome e cognome.

L’indicizzazione di un database è una tecnica per recuperare in modo efficiente i record dai file del database, sulla base di alcuni attributi sui quali è stata eseguita l’indicizzazione. Per farla semplice, l’indicizzazione nei sistemi di database è simile a quella che vediamo di solito nei libri. All’inizio o alla fine di un libro, si può trovare un indice (che è diverso da un indice), che fornisce tutti i numeri di pagina per un argomento specifico. Per esempio, un atlante può essere diviso in capitoli contenenti mappe, capitoli contenenti dati sulla popolazione e capitoli dedicati alla produzione dei paesi o ai dati agricoli. Se state cercando un paese specifico e volete avere una visione d’insieme di tutti i dati riguardanti questo paese specifico, l’indice potrebbe essere molto utile perché vi mostrerà la pagina relativa a quel paese in ogni capitolo (Fig. 7).

Che cos’è un “oggetto”

In informatica, un oggetto può essere una variabile, una struttura di dati, una funzione o un metodo e, come tale, è un valore in memoria referenziato da un identificatore. Nel modello relazionale di gestione dei database, un oggetto può essere una tabella o una colonna, o un’associazione tra i dati e un’entità del database, come la relazione tra l’età di una persona e una persona specifica.

Structured data

Figura 8: Dati strutturati

Secondo la SNIA (Storage Networking Industry association), i dati strutturati sono definiti come:

“I dati che sono organizzati e formattati in un modo noto e fisso.

Il formato e l’organizzazione sono solitamente definiti in uno schema. Il termine dati strutturati è di solito inteso come dati generati e mantenuti da database e applicazioni aziendali”.

Tre condizioni sono necessarie per descrivere i dati come strutturati:

Devono essere conformi a un modello di dati,

Deve avere una struttura ben definita,

Deve seguire un ordine coerente e può essere facilmente accessibile e utilizzato da una persona o da un programma informatico.

I dati strutturati sono di solito memorizzati in schemi ben definiti come i database. È generalmente tabulare con colonne e righe che definiscono chiaramente i suoi attributi (Fig. 8).

SQL (Structured Query language) è spesso usato per gestire i dati strutturati memorizzati nei database.

Dati destrutturati

Figura 9: Estrazione di un file PDF

Le informazioni che non sono organizzate in un modello predefinito sono chiamate dati non strutturati o informazioni non strutturate. In informatica, file come file di testo, foto, file video, file audio e presentazioni sono considerati file non strutturati. Tipicamente, un file PDF contiene dati non strutturati (Fig. 9).

Si stima che l’80-90% del totale dei dati dematerializzati nel mondo sia non strutturato. I soliti algoritmi di interrogazione non sono in grado di estrarre in modo semplice ed efficiente le informazioni richieste da un file non strutturato, come nell’esempio della Fig. 9. Le stesse informazioni contenute nella Fig. 9 possono essere facilmente recuperate con una query. Tuttavia, oggi sono disponibili strumenti di analisi dei dati non strutturati alimentati dall’intelligenza artificiale (AI), che sono stati creati appositamente per accedere alle intuizioni disponibili dai dati non strutturati (vedi 3.1.12 Analytics).

Big data

Secondo SNIA (Storage Networking Industry association), i big data sono definiti come:

“Una caratterizzazione di set di dati troppo grandi per essere elaborati in modo efficiente nella loro interezza dalle piattaforme computazionali standard più potenti disponibili.”

In altre parole, i Big Data si riferiscono a enormi quantità di dati strutturati o non strutturati che non possono essere elaborati dal solito software come linguaggio di query di database tradizionale o qualsiasi altro tipo di motore di recupero.

Esiste confusione sull’uso corrente dei termini Big Data e Analytics. I Big Data sono le informazioni, mentre Analytics è il modo per estrarre le informazioni desiderate da enormi quantità di informazioni disponibili.

Analytics

Nella tecnologia informatica, Analytics è un metodo per estrarre valore dai grandi dati.

Nel campo dell’assistenza sanitaria, Big Data Analytics ha portato a molti miglioramenti fornendo medicina personalizzata e analisi predittiva. Poiché il volume dei dati sta aumentando drammaticamente, i database tradizionali e i motori di ricerca non sono in grado di gestire e recuperare informazioni specifiche. I dati dei pazienti sono generati da risonanze magnetiche, raggi X, macchine per gli esami del sangue, sensori di monitoraggio e molte altre fonti di dati complessi da elaborare. Molte informazioni nell’assistenza sanitaria sono ora in forma elettronica; si inserisce sotto l’ombrello dei big data in quanto la maggior parte di esse non è strutturata e difficile da usare.

I big data nella ricerca sanitaria sono particolarmente promettenti in termini di ricerca biomedica esplorativa, poiché l’analisi guidata dai dati può procedere più rapidamente della ricerca guidata dalle ipotesi. Successivamente, le tendenze viste nell’analisi dei dati possono essere testate nella ricerca biologica tradizionale, guidata da ipotesi, ed eventualmente nella ricerca clinica.

Archivio

Un archivio di dati o data warehouse è un luogo centralizzato per memorizzare e mantenere i dati. Un repository di dati può consistere in uno o più file di dati strutturati, come database o file di dati non strutturati, che possono essere distribuiti su una rete e conservati a lungo termine.

Struttura di base di una banca dati

Questa sezione è dedicata alla panoramica dei principali elementi costitutivi di una banca dati.

Introduzione

Dall’invenzione dei computer, la quantità di dati immagazzinati e gestiti elettronicamente è aumentata drasticamente. Si stima che la quantità di dati raggiungerà 175 zettabyte (1021 Bytes) entro il 2025, crescendo da pochi petabyte (1015 Bytes) nell’anno 2000. Un modo comune per semplificare la vita degli utenti e sfruttare al massimo le loro risorse è quello di immagazzinarle e recuperarle in modo più efficiente. Per esempio, mentre un file piatto funziona benissimo per memorizzare i dati personali, come una rubrica o alcune ricette, non è altrettanto adatto per memorizzare un elenco telefonico di una città o, più precisamente, i dati genomici nel campo delle biotecnologie. Inoltre, se si desidera memorizzare diverse specie genomiche di dati, è molto difficile cercare e recuperare i dati da un file piatto. I database offrono una soluzione a questo problema, rendendo l’archiviazione, la gestione e il recupero dei dati molto più semplice.

Il software usato per gestire un database è chiamato sistema di gestione di un database (DBMS). Questo software specializzato funge da intermediario per aiutare gli utenti finali ad accedere al database. Di solito, gli utenti non interagiscono direttamente con un database perché questo può portare alla sua disorganizzazione. Invece, usano un DBMS che legge i dati da o scrive i dati nel database.

La crescente complessità di grandi quantità di dati ha richiesto ad alcune aziende di utilizzare strumenti di gestione dei dati basati sul modello relazionale, come il classico RDBMS. RDBMS sta per Relational Database Management System. Tuttavia, le principali società di Internet, come Google, Yahoo e Amazon, o tutti i popolari Social Media, hanno affrontato la sfida di gestire enormi quantità di dati in tempo reale, qualcosa che le soluzioni RDBMS convenzionali non potevano affrontare. Questo spiega l’impennata di popolarità dei sistemi di database NoSQL che sono sorti a fianco.

I sistemi NoSQL sono database distribuiti, non relazionali, progettati per l’immagazzinamento di dati su larga scala e per l’elaborazione di dati massicciamente parallela e ad alte prestazioni su un gran numero di server di base. Sono nati da un bisogno di agilità, performance e scala, e possono supportare un’ampia serie di casi d’uso, tra cui l’analisi esplorativa e predittiva in tempo reale. Costruiti dalle migliori compagnie internet per tenere il passo con il diluvio di dati, i database NoSQL scalano orizzontalmente e sono progettati per scalare fino a centinaia di milioni e persino miliardi di utenti che eseguono sia aggiornamenti che letture.

Alcune delle applicazioni comuni dei database NoSQL sono i social media, i fornitori di e-mail su larga scala e i sistemi sanitari governativi.

Di solito, un’applicazione sociale può passare da zero a milioni di utenti in poche settimane e per gestire al meglio questa crescita, si ha bisogno di un DB che possa gestire un numero enorme di utenti e di dati, ma che possa anche scalare facilmente in modo orizzontale.

In questo corso, ci concentreremo solo su DBMS e RDBMS. Questi sono i due tipi di database comunemente usati nel mondo delle biotecnologie fino ad oggi.

Panoramica di un’architettura di database

Figura 10: Architettura hardware per un database

I database possono memorizzare tutti i tipi di informazioni, da numeri e testo, a e-mail, contenuti web, registri telefonici, dati biologici, geografici, ecc. I database sono ufficialmente classificati secondo il modo in cui immagazzinano questi dati. I database relazionali memorizzano i dati in tabelle. I database orientati agli oggetti memorizzano i dati in classi e sottoclassi di oggetti. Ci concentreremo sui database relazionali, poiché sono i più comunemente usati. Tuttavia, la maggior parte delle topologie di base dei database hanno bisogno di avere server di backend per ospitare il sistema di gestione del database, un sistema di archiviazione collegato ai server per memorizzare la struttura e i dati del database e, naturalmente, computer, laptop, desktop o terminali come interfaccia per consentire agli utenti di accedere al database, al suo sistema di gestione e al suo contenuto. È necessaria anche una rete per lo scambio tra tutti i componenti hardware e un attacco Cloud per permettere agli utenti remoti di accedere al database. La Fig. 10 riassume in modo semplice il minimo richiesto per far funzionare un database.

Un altro modo basilare per descriverlo, è mostrare l’architettura a tre livelli di un database.

È una visione virtuale dei livelli necessari per far funzionare correttamente un database. La Fig. 11 mostra l’architettura a tre livelli. Si chiama modello ANSI-SPARC. Tuttavia, nonostante il fatto che questo modello non sia mai diventato uno standard formale, presenta l’idea di indipendenza logica dei dati che è stata ampiamente adottata.

Le informazioni memorizzate all’interno di un database relazionale sono contenute nelle tabelle. Queste tabelle sono composto di righe di dati e ogni riga contiene campi o colonne. In una definizione di database ben progettata, chiamata schema, solo dati simili vengono archiviati all’interno di ogni tabella e la duplicazione delle colonne viene mantenuta al minimo. Gli sviluppatori possono connettere o unire dati da due tabelle per collegare tra loro diversi tipi di informazioni.

Figura 11: Architettura a tre livelli

Gli indici possono essere creati sui campi nella tabella del database per rendere più facile per il DBMS recuperare i dati. Gli indici sono di solito configurati per colonne ricercate frequentemente, come il nome di una persona o un valore di data. Lo svantaggio di usare gli indici è che occupano spazio su disco e possono rallentare le cose, se ne vengono mantenuti troppi, perché ogni volta che una riga del database viene aggiornata, anche l’indice deve essere aggiornato.

La maggior parte dei database supporta lo Structured Query Language (SQL), un linguaggio standard per interagire con le informazioni contenute in un database. SQL permette agli utenti e alle applicazioni di interagire con specifici sottoinsiemi di dati da una o più tabelle usando diverse istruzioni come SELECT, INSERT, UPDATE e DELETE.

I database relazionali forniscono anche un approccio stratificato alla memorizzazione, permettendo la definizione di quali oggetti del database risiedono in specifici file di dati e dove questi file di dati sono collocati all’interno della struttura dei file del sistema operativo. Oltre a gestire la posizione fisica di memorizzazione degli oggetti del database, molti sistemi di database danno un certo controllo su come i dati sono memorizzati all’interno dei file di dati.

Termini comuni del database

Alcuni termini del database derivano da modi in cui i database automatizzano le azioni di scrittura. Gli sviluppatori di database spesso automatizzano la scrittura in determinati campi o altre tabelle, ad esempio la scrittura di una copia della riga da inserire, insieme a un timestamp o un nome utente, in una cronologia o in una tabella di controllo. La maggior parte dei sistemi DBMS offre diversi modi per gestire automaticamente le azioni di scrittura del database.

I trigger di database sono il metodo più comune per intervenire sui dati durante la scritta nel database. I trigger sono in genere associati a una particolare tabella e configurati per l’esecuzione in un determinato punto durante un’azione di scrittura specifica, ad esempio prima o dopo un aggiornamento o dopo l’inserita di una riga. I trigger possono essere utilizzati per formattare i dati, popolare una colonna con dati derivati da informazioni esistenti o persino scrivere in un’altra tabella in base alla riga da inserire o aggiornare.

Una stored procedure è un altro modo di interagire con un database relazionale. Le stored procedure sono più complesse dei trigger e non sono legate a una singola tabella specifica. In genere creati da uno sviluppatore, utilizzano una combinazione di SQL e un linguaggio di programmazione, ad esempio Java o SQL (a seconda della piattaforma di database). Le stored procedure offrono agli sviluppatori un grande controllo sul modo in cui i dati vengono convalidati o massaggiati da un’applicazione. Una stored procedure può essere utilizzata per gestire il modo in cui un utente accede a un’applicazione. La procedura potrebbe prima convalidare il nome utente e la password, quindi registrare l’esito positivo o negativo del tentativo in un’altra tabella, insieme ad altre informazioni, tra cui il nome del computer e un timestamp. Un avviso potrebbe anche essere inviato all’utente informandolo che la sua password è scaduta e deve essere modificata.

Le funzioni sono più semplici della stored procedure e talvolta possono anche essere utilizzate dall’interno delle query SQL. Le funzioni vengono in genere utilizzate in un database per eseguire un insieme di azioni che restituiscono uno o più valori, ad esempio il calcolo della somma di una colonna per le righe che corrispondono a una determinata condizione. Sebbene queste azioni possano essere eseguite utilizzando SQL, la loro creazione in una funzione può rendere ilm più facile da usare in altro codice. Sia le funzioni che le stored procedure possono eseguire azioni comuni in modo semplificato e coerente, facilitando il carico di lavoro per gli amministratori e gli sviluppatori di database.

Qual è la differenza tra i principali sistemi DBMS?

Il DBMS è generalmente guidato da ciò che le applicazioni utente devono supportare. Detto questo, ecco un breve confronto delle tre piattaforme più utilizzate.

Microsoft SQL Server è ampiamente utilizzato nelle applicazioni aziendali e si integra facilmente con altri strumenti Microsoft. Microsoft SQL Server 2019 Express è la versione più recente dell’offerta gratuita di Microsoft ed è spesso in bundle con le applicazioni che utilizzano SQL Server.

MySQL è stato uno dei preferiti dagli sviluppatori open source per la maggior parte dei due decenni. Spesso utilizzato come back-end per blog open source o sistemi di gestione dei contenuti, MySQL ha una base installata massiccia in tutto il mondo. Nel 2008, MySQL AB è stata acquisita da Sun Microsystems, che è stata a sua volta acquisita da Oracle Corp. Tuttavia, MySQL Community Edition rimane gratuito ed è ben supportato dalla community. MySQL è disponibile per numerosi sistemi operativi, tra cui Linux, UNIX, Mac OS X e Windows.

Oracle Database è considerato da molti lo standard nelle piattaforme di database a livello aziendale e supporta numerose applicazioni aziendali. Oracle Database Express Edition è disponibile gratuitamente ed è anche gratuito da distribuire (anche se non è tecnicamente software gratuito), rendendolo un’altra opzione popolare per sviluppatori o hobbisti su Windows o Linux.

Ora che hai imparato i termini e i concetti fondamentali del database, sei molto più vicino a parlare la stessa lingua degli sviluppatori di database dell’organizzazione.

Banche dati in termini scientifici

Questa parte si occupa delle basi di database utilizzate nel mondo scientifico

Introduzione alle banche dati esistenti dedicate alla scienza

Questa sezione è dedicata alla panoramica dei database di accesso aperto più comuni utilizzati nella scienza.

I continui sviluppi nei settori della biotecnologia e delle tecnologie dell’informazione hanno portato alla crescita esponenziale dei dati. Studi condotti da ricercatori dell’Istituto Europeo di Bioinformatica (EMBL-EBI) hanno dimostrato che questa crescita delle informazioni raddoppia all’incirca ogni anno. Queste ampie quantità di dati sono memorizzate, organizzate e costantemente aggiornate in banche dati scientifiche, dove sono prontamente disponibili per gli scienziati, compresi biologi e bio-informatici, da utilizzare a fini di ricerca. Le informazioni disponibili nelle banche dati biologiche sono ottenute da una serie di campi scientifici, tra cui la metabolomica, l’espressione genica dei microarray e la proteomica. Oltre a memorizzare, organizzare e condividere enormi volumi di dati, l’obiettivo principale dei database biologici è quello di offrire interfacce di programmazione delle applicazioni Web (API) per i computer per lo scambio e l’integrazione di dati da molte risorse di database diverse tramite un metodo automatizzato.

Figura 12: Esempi di nomi di basi di dati biotecnologiche

I database biologici possono essere definiti come collezioni di dati, che sono strutturati in modo tale da rendere il loro contenuto facile da esplorare, gestire e aggiornare. Esempi di tali database sono presentati in Fig. 12. Nel 1972, è stato creato il primo database sulla struttura delle proteine, conosciuto come Protein Data Bank (PDB). Questo database conteneva originariamente solo 10 voci, che ora si è espanso fino a contenere più di 10.000 voci, a significare la rapida crescita dei dati biologici. Un database biologico può contenere diversi tipi di dati, tra cui sequenze di proteine, descrizioni testuali, attributi e dati tabulari. In generale, possono essere divisi in database primari, secondari e compositi. I database primari includono dati relativi alla sola sequenza o struttura, mentre i database secondari includono dati provenienti dal database primario. I dati, come la sequenza conservata e i residui del sito attivo delle famiglie di proteine, possono essere trovati nei database di struttura secondaria. Inoltre, le voci del PDB, che è un database primario, possono essere trovate in database di struttura secondaria, memorizzati in modo organizzato.

In generale, i database biologici possono essere classificati in database di sequenza, struttura e pathway:

  • Database di sequenza: I database biologici più comunemente usati. Questi includono database di sequenze proteiche e nucleotidiche, che contengono risultati di laboratorio grezzi e sono la fonte principale per i risultati sperimentali. GenBank ed EMBL sono esempi di database di sequenza.
  • Database della struttura: Questi database contengono informazioni riguardanti la struttura proteica e le interazioni molecolari. PDB è un esempio di database di struttura.
  • Database dei pathway: Queste basi di dati si basano su dati derivati dallo studio comparativo delle vie metaboliche. La Kyoto Encyclopedia of Genes and Genomes (KEGG) e il Biocyc sono due database indicativi dei percorsi.

Una ricerca tipica in una banca dati di sequenza nucleotidica può, ad esempio, generare dati riguardanti il nome scientifico dell’organismo di origine da cui è stato isolato, il nome del contatto, la sequenza di input con i dettagli del tipo di molecola e, frequentemente, le citazioni bibliografiche relative alla sequenza.

Sono stati sviluppati alcuni strumenti per facilitare gli scienziati nell’elaborazione dei dati e nel recupero dalle banche dati biologiche. Questi strumenti, che sono definiti strumenti bioinformatici, sono programmi software creati per l’estrazione di dati significativi dal vasto numero di database biologici e per condurre analisi sequenziali o strutturali. Gli strumenti di bioinformatica vengono utilizzati per ottenere dati da database di sequenze genomiche e per la visualizzazione, l’analisi e il recupero della data da database proteomici. Questi strumenti sono in gran parte suddivisi in:

  • Strumenti di omologia e somiglianza: Questi strumenti sono utilizzati per il rilevamento di somiglianze tra le sequenze di sequenze strutturali e funzionali sconosciute, la cui funzione e struttura sono già note.
  • Strumenti di analisi della funzione proteica: Programmi applicati per il confronto di una sequenza proteica con una proteina secondaria (o derivata), che consentono la stima della funzione biochimica di una proteina interrogata.
  • Strumenti di analisi strutturale: Questi strumenti consentono il confronto delle strutture con le banche dati delle strutture note e la creazione della struttura 2D/3D di una proteina.
  • Strumenti di analisi delle sequenze: Programmi utilizzati per la valutazione aggiuntiva e più completa di una sequenza interrogata, che coinvolge l’analisi evolutiva e l’identificazione delle mutazioni.

Le banche dati biologiche possono anche essere classificate, in base all’ambito di copertura dei dati, in:

  • Banche dati complete: queste basi di dati comprendono vari tipi di dati provenienti da un certo numero di specie. Esempi di database completi sono GenBank ed EMBL.
  • Banche dati specializzate: Queste basi di dati includono particolari tipi di dati o dati provenienti da organismi particolari. Un esempio di database specializzati è WormBase, che contiene informazioni sulla biologia dei nematodi e sulla genomica.

In relazione al livello di biocurazione, che è definito come l’attività di organizzare, dimostrare e rendere le informazioni biologiche prontamente disponibili sia agli esseri umani che ai computer, i database biologici sono classificati come database primari e secondari o derivati. I database primari consistono in dati grezzi come deposito d’archivio, mentre i database secondari o derivati consistono in informazioni curate come valore aggiunto. Per quanto riguarda il metodo impiegato per curare i dati, i database biologici possono essere ulteriormente classificati come database curati da esperti o database curati dalla comunità, che sono curati in modo cooperativo da numerosi ricercatori.

Ulteriori categorizzazioni delle banche dati biologiche possono anche essere effettuate in base al tipo di dati. I tipi di dati che di conseguenza classificano i database includono DNA, RNA, proteina, espressione, percorso, malattia, nomenclatura, letteratura e standard e ontologia. Alcuni dei database biologici più importanti e ampiamente utilizzati sono i seguenti: GenBank, UCSC Genome Browser e Ensembl, che sono database/portali di sequenza; WormBase e The Arabidopsis Information Resource (TAIR), che sono database di organismi modello; e il PDB, Online Mendelian Inheritance in Man (OMIM), MetaCyc e KEGG, che sono caratterizzati come database nonincentrati sulla sequenza.

La manipolazione dei dati è una parte essenziale del processo sperimentale di tutti gli studi, indipendentemente dalla loro scala. La disponibilità online di dati biologici combinata con la diminuzione dei costi dei sequenziatori automatici del genoma ha permesso ai piccoli laboratori di biologia di diventare generatori di big data. Anche se un laboratorio non è dotato di tali strumenti, può comunque diventare un utente di big data ottenendo l’accesso a repository pubblici contenenti dati biologici, come il National Center for Biotechnology Information degli Stati Uniti a Bethesda. Gran parte della costruzione in biologia dei big data è virtuale, basata sul cloud computing, in cui dati e software si trovano in enormi centri fuori sede a cui è possibile accedere su richiesta. Pertanto, non è necessario che gli utenti acquistino il proprio hardware. Il sistema di cloud computing consente ai potenziali utenti di creare spazi virtuali per dati, software e risultati liberamente accessibili da tutti, o di mantenere gli spazi bloccati dietro un firewall consentendo l’accesso a un gruppo scelto di collaboratori.

L’uso di banche dati biologiche può essere vantaggioso in diversi settori di ricerca. Ad esempio, le basi di dati possono aiutare la progettazione sperimentale consentendo l’analisi automatica e la facile elaborazione dei dati sperimentali e rendendo semplice e rapido l’esame dei risultati sperimentali. La scoperta di farmaci è un’altra area che può essere semplificata utilizzando i database.  In questo settore specifico, le banche dati possono essere scansionate al fine di trovare nuovi candidati per i farmaci formando un classificatore su un set di dati in cui sono stati identificati farmaci funzionanti e non funzionanti. Inoltre, le tecniche di machine learning possono essere applicate a test virtuali di progettazione in grado di identificare nuovi farmaci promettenti, che possono essere successivamente analizzati in laboratorio. (RIF. 4) E, soprattutto, è possibile effettuare nuovi esperimenti scientifici e generare nuovi risultati analizzando i set di dati esistenti.

Senza l’esistenza di basi di dati, la condivisione e l’integrazione di grandi quantità di dati sarebbe praticamente impossibile. Sebbene molti scienziati della vita abbiano competenze computazionali avanzate, una grande percentuale non ha familiarità con lo sviluppo o l’adattamento del software pertinente. Tuttavia, il coinvolgimento degli scienziati della vita in questo processo è fondamentale, poiché possono fornire feedback agli specialisti di informatica concentrandosi su diverse esigenze e approcci alla scienza. La possibilità di avere accesso ai set di dati effettivi originariamente utilizzati in uno studio specifico offre ai ricercatori l’opportunità di riprodurre ed espandere tale studio. Ecco perché è importante che i dati diventino liberamente disponibili per gli scienziati in qualsiasi momento senza restrizioni, un concetto supportato da Open Science e numerose iniziative correlate. Una di queste iniziative è nota come ELIXIR, un progetto progettato per aiutare gli scienziati di tutta Europa a salvaguardare e condividere i loro dati e a rafforzare le risorse attuali, comprese le banche dati e le strutture informatiche, nei singoli paesi.

Sebbene la creazione di banche dati biologiche abbia portato molti benefici, come la promozione di una produzione scientifica di qualità abilitata dalla creazione di reti, esse richiedono comunque miglioramenti in termini di ottimizzazione delle conoscenze. È fondamentale gestire le conoscenze transdisciplinari in modo tale da portare ad un aumento della sua qualità e quantità. L’eterogeneità dei dati è un altro problema comune affrontato nell’integrazione dei dati biologici. Nel campo della biologia, esistono diversi metodi per la rappresentazione di dati simili. Ciò complica l’integrazione e l’elaborazione dei dati, il che, a sua volta, rende più difficile acquisire visualizzazioni unificate di tali dati. Un esempio di questo problema è l’uso di vari nomi alternativi quando si fa riferimento ai geni, indipendentemente dall’esistenza di linee guida complete emanate nel 1979 che propongono l’adozione di standard di nomenclatura genica, portando a difficoltà nella condivisione dei dati. L’attuazione di standard consente il riutilizzo dei dati, tuttavia, la loro assenza causa una significativa perdita di produttività e contribuisce a una diminuzione dei dati accessibili dai ricercatori. Pertanto, è imperativo trovare una soluzione a questo problema al fine di eliminare le sfide affrontate dagli scienziati quando utilizzano banche dati biologiche per condurre le loro ricerche.

Pensiero finale

Trattare i dati implica una drastica disciplina per mantenere l’accesso a lungo termine alle informazioni memorizzate. La tecnologia si evolve, il che significa che l’hardware e il software utilizzati oggi non sono lo standard di domani. Ciò significa che per poter leggere tutti i dati scritti oggi dovremo eseguire due diversi tipi di migrazioni. Una migrazione logica e una migrazione tecnologica. La migrazione logica è correlata al tipo di formato in cui vengono archiviati i dati. La migrazione tecnologica è legata al tipo di hardware utilizzato. Ad esempio, se si tenta di aprire un file di Word scritto nel 1993 con Word versione 6 con la versione più recente di Word 2019, non funzionerà. In questo esempio viene illustrata una mancanza di compatibilità logica. Per evitare questo problema e mantenere una compatibilità crescente, il file avrebbe dovuto essere migrato per l’ora alla versione più recente per mantenerlo aggiornato e leggibile con le ultime versioni del software.

Lo stesso vale per l’hardware, cioè server, archiviazione, reti, ecc… Un altro esempio potrebbe essere il tipo di server e sistema operativo utilizzato per eseguire un database. Nel caso in cui si decida di modificare l’hardware e di eseguire la migrazione da, ad esempio,Windows  a UNIX, sarà necessario un diverso tipo di hardware per eseguire  UNIX e una versione diversa del database da eseguire su  UNIX. Windows viene eseguito su piattaforme basate su Intel (e intel like) e Unix viene eseguito su piattaforme basate su SPARC, il che significa che sarà necessario eseguire la migrazione a una versione compatibile UNIX – SPARC del database.

Tenere presente questa costante evoluzione di hardware, sistemi operativi, software e formati, eseguire le migrazioni logiche e tecnologiche appropriate in tempo potrebbe farti risparmiare molto tempo e problemi.

Ultimo ma non meno importante, è importante continuare a eseguire il backup dei dati. Una volta ogni tre o sei mesi, eseguire un test di ripristino per verificare se si è in grado di recuperare i backup. Ciò è fondamentale per due motivi:

  • Ti terrà aggiornato su come ripristinare i tuoi dati

È il miglior metodo di test per vedere se i tuoi dati sono stati correttamente sottoposti a backup

Test: LO5 Livello di base

Referenze

  • Baxevanis AD, Bateman A. 2015. The importance of biological databases in biological discovery. Curr Protoc Bioinformatics., 50(1):1.1.1-1.1.8.
  • Benson DA, Clark K, Karsch-Mizrachi I, Lipman DJ, Ostell J, Sayers EW. 2014. GenBank. Nucleic Acids Res., 42:D32–D37.
  • Brooksbank C, Bergman MT, Apweiler R, Birney E, Thornton J. 2014. The European Bioinformatics Institute’s data resources 2014. Nucleic Acids Res., 42:D18–D25.
  • Caspi R, Billington R, Ferrer L, Foerster H, Fulcher CA, Keseler IM, et al. 2016. The MetaCyc database of metabolic pathways and enzymes and the BioCyc collection of pathway/genome databases. Nucleic Acids Res., 44(D1):D471-80.
  • Figueiredo MSN, Pereira AM. 2017. Managing knowledge – the importance of databases in the scientific production. Procedia Manuf., 12:166–73.
  • Harris TW, Baran J, Bieri T, Cabunoc A, Chan J, Chen WJ. 2014. WormBase 2014: new views of curated biology. Nucleic Acids Res., 42:D789–D793.
  • Howe D, Costanzo M, Fey P, Gojobori T, Hannick L, Hide W, et al. 2008. Big data: The future of biocuration: Big data. Nature., 455(7209):47–50.
  • Kanehisa M, Furumichi M, Sato Y, Ishiguro-Watanabe M, Tanabe M. 2021. KEGG: integrating viruses and cellular organisms. Nucleic Acids Res., 49(D1): D545–51.
  • Karp PD, Billington R, Caspi R, Fulcher CA, Latendresse M, Kothari A, et al. 2019. The BioCyc collection of microbial genomes and metabolic pathways. Brief Bioinform., 20(4):1085–93.
  • Kent WJ, Sugnet CW, Furey TS, Roskin KM, Pringle TH, Zahler AM, Haussler D. 2002. The human genome browser at UCSC. Genome Res., 12(6):996-1006.
  • Lapatas V, Stefanidakis M, Jimenez RC, Via A, Schneider MV. Data integration in biological research: an overview. J Biol Res (Thessalon). 2015;22(1):9.
  • Marx V. 2013. Biology: The big challenges of big data: Biology. Nature., 498(7453):255–60.
  • Nature Structural Biology 10, 980. 2003; doi: 10.1038/nsb1203-980
  • Oliveira AL. 2019. Biotechnology, big data and artificial intelligence. Biotechnol J., 14(8):e1800613.
  • Razvi SRH, Rampogu S. 2016. Bioinformatics in the present day. MOJ proteom bioinform [Internet]., 3(1):11–2. Available from: http://dx.doi.org/10.15406/mojpb.2016.03.00073
  • Toomula N, Kumar A, Kumar D S, Bheemidi VS. 2012. Biological databases- integration of life science data. J Comput Sci Syst Biol., 04(05):087-092. Available from: http://dx.doi.org/10.4172/jcsb.1000081
  • Yates AD, Achuthan P, Akanni W, Allen J, Allen J, Alvarez-Jarreta J, et al. 2020. Ensembl 2020. Nucleic Acids Res., 48(D1): D682–8.
  • Zou D, Ma L, Yu J, Zhang Z. 2015. Biological databases for human research. Genomics Proteomics Bioinformatics., 13(1):55–63.
  • Baxevanis AD, Bateman A. 2015. The importance of biological databases in biological discovery. Curr Protoc Bioinformatics., 50(1):1.1.1-1.1.8.
  • Benson DA, Clark K, Karsch-Mizrachi I, Lipman DJ, Ostell J, Sayers EW. 2014. GenBank. Nucleic Acids Res., 42:D32–D37.
  • Brooksbank C, Bergman MT, Apweiler R, Birney E, Thornton J. 2014. The European Bioinformatics Institute’s data resources 2014. Nucleic Acids Res., 42:D18–D25.
  • Caspi R, Billington R, Ferrer L, Foerster H, Fulcher CA, Keseler IM, et al. 2016. The MetaCyc database of metabolic pathways and enzymes and the BioCyc collection of pathway/genome databases. Nucleic Acids Res., 44(D1):D471-80.
  • Figueiredo MSN, Pereira AM. 2017. Managing knowledge – the importance of databases in the scientific production. Procedia Manuf., 12:166–73.
  • Harris TW, Baran J, Bieri T, Cabunoc A, Chan J, Chen WJ. 2014. WormBase 2014: new views of curated biology. Nucleic Acids Res., 42:D789–D793.
  • Howe D, Costanzo M, Fey P, Gojobori T, Hannick L, Hide W, et al. 2008. Big data: The future of biocuration: Big data. Nature., 455(7209):47–50.
  • Kanehisa M, Furumichi M, Sato Y, Ishiguro-Watanabe M, Tanabe M. 2021. KEGG: integrating viruses and cellular organisms. Nucleic Acids Res., 49(D1): D545–51.
  • Karp PD, Billington R, Caspi R, Fulcher CA, Latendresse M, Kothari A, et al. 2019. The BioCyc collection of microbial genomes and metabolic pathways. Brief Bioinform., 20(4):1085–93.
  • Kent WJ, Sugnet CW, Furey TS, Roskin KM, Pringle TH, Zahler AM, Haussler D. 2002. The human genome browser at UCSC. Genome Res., 12(6):996-1006.
  • Lapatas V, Stefanidakis M, Jimenez RC, Via A, Schneider MV. Data integration in biological research: an overview. J Biol Res (Thessalon). 2015;22(1):9.
  • Marx V. 2013. Biology: The big challenges of big data: Biology. Nature., 498(7453):255–60.
  • Nature Structural Biology 10, 980. 2003; doi: 10.1038/nsb1203-980
  • Oliveira AL. 2019. Biotechnology, big data and artificial intelligence. Biotechnol J., 14(8):e1800613.
  • Razvi SRH, Rampogu S. 2016. Bioinformatics in the present day. MOJ proteom bioinform [Internet]., 3(1):11–2. Available from: http://dx.doi.org/10.15406/mojpb.2016.03.00073
  • Toomula N, Kumar A, Kumar D S, Bheemidi VS. 2012. Biological databases- integration of life science data. J Comput Sci Syst Biol., 04(05):087-092. Available from: http://dx.doi.org/10.4172/jcsb.1000081
  • Yates AD, Achuthan P, Akanni W, Allen J, Allen J, Alvarez-Jarreta J, et al. 2020. Ensembl 2020. Nucleic Acids Res., 48(D1): D682–8.
  • Zou D, Ma L, Yu J, Zhang Z. 2015. Biological databases for human research. Genomics Proteomics Bioinformatics., 13(1):55–63.

Risorse scientifiche ad accesso aperto: database digitali

LIVELLO AVANZATO

Questa parte si occupa della progettazione avanzata di un database. Viene spiegata la struttura di un database e come creare relazioni tra tabelle di database.

Sommario

 

Struttura avanzata di una banca dati

Questa parte si occupa della progettazione avanzata di un database. Viene spiegata la struttura di un database e come creare relazioni tra tabelle di database. Presenta inoltre il linguaggio specifico utilizzato per creare query (SQL) per recuperare dati da un database.

Sistemi di gestione dei database

Un database moderno può essere definito come una raccolta strutturata di informazioni (dati) rappresentativa del mondo reale. I sistemi di gestione dei database (DBMS) vengono utilizzati per la creazione, la gestione e la query di database. Attualmente, i sistemi di gestione delle database relazionali (RDBMS) sono i sistemi di database più maturi e ampiamente gestiti in produzione. Quasi tutte le transazioni online e la maggior parte dei sistemi di gestione dei contenuti online (ad esempio blog e social network) si basano su questi tipi di sistemi di database, che sono fondamentali per l’infrastruttura applicativa mondiale.  Il punto focale di un DBMS è la compilazione di servizi che offrono la persistenza dei dati nel database e la funzionalità per garantire che i dati siano corretti e coerenti e che le transazioni seguano le proprietà ACID. ACID si riferisce a quattro proprietà essenziali di una transazione:

  • Atomicità
  • Consistenza
  • Isolamento
  • Durabilità

Lingue dei modelli di database

Tutti i modelli di database hanno un linguaggio per la specifica della struttura e del contenuto del database. La specifica è nota come progettazione dello schema e rappresenta la visualizzazione logica delle informazioni che verranno gestite da un determinato DBMS. Questo linguaggio di specifica del database deve essere flessibile in modo da essere utile e duraturo. L’elemento più visibile di un database, identificabile dai professionisti del database e dagli sviluppatori di applicazioni, è il linguaggio di manipolazione dei dati. Può mostrare molte forme, con la più comune è un’interfaccia di programmazione simile a un linguaggio. Oggi, i linguaggi testuali e procedurali, tra cui SQL (Structured Query Language) e Object Query Language (OQL), rimangono le forme più diffuse di linguaggio di manipolazione dei dati.

Caratteristiche del database

Un database può essere caratterizzato come coerente, logico e consistente internamente. Può anche essere caratterizzato come auto-descrittivo, poiché include metadati, che definiscono e descrivono i dati e le relazioni tra le tabelle nel database. È progettato per contenere dati per uno scopo specifico. Ogni dato è memorizzato in un campo; una combinazione di campi è chiamata tabella. Un certo numero di tabelle può esistere in un database.

In contrasto con il sistema basato su file, nei sistemi di database la struttura dei dati è memorizzata nel catalogo del sistema e non nei programmi applicativi. Questa separazione tra i programmi e i dati è chiamata indipendenza programma-dati.

L’architettura di un sistema di database è composta da un insieme di servizi che sono costruiti sopra i servizi di base del sistema operativo, i servizi di archiviazione dei file di sistema e i servizi di gestione del buffer della memoria primaria. Questo insieme di servizi è composto dai seguenti: gestione del catalogo, gestione dell’integrità, gestione delle transazioni, controllo della concorrenza, gestione dei blocchi, gestione dei deadlock, gestione del recupero, gestione della sicurezza, elaborazione delle query, gestione delle comunicazioni e gestione dei log.

Tipi di modello di database

I modelli di dati possono essere suddivisi in due tipi:

  • Modelli di dati concettuali di alto livello
  • Modelli di dati logici basati su record

I modelli di dati concettuali di alto livello propongono concetti per la presentazione dei dati in modi simili al modo in cui le persone percepiscono i dati. Un esempio di questo modello di dati è il modello ER (Entity-Relationship), basato su concetti quali entità, attributi e relazioni. Un’entità corrisponde a un oggetto del mondo reale, gli attributi rappresentano le proprietà dell’entità e una relazione indica un’associazione tra entità.

I modelli di dati logici basati su record propongono concetti che gli utenti possono comprendere, ma sono simili al modo in cui i dati vengono archiviati nel computer. I modelli di dati relazionali, i modelli di dati di rete e i modelli di dati gerarchici sono tre dei modelli di dati logici basati su record più diffusi.

  • Nel modello relazionale, i dati sono rappresentati sotto forma di relazioni o tabelle.
  • Nel modello di rete, i dati sono rappresentati come tipi di record. Rappresentato anche da questo modello è un tipo di insieme, definito come un tipo limitato di relazione uno-a-molti.
  • Nel modello gerarchico, i dati sono rappresentati come una struttura gerarchica ad albero, ogni ramo del quale è rappresentativo di un certo numero di record correlati.

Fasi di progettazione del database

La modellazione dei dati costituisce il primo passo della progettazione del database. Questo passaggio è a volte anche se una fase di progettazione astratta e di alto livello, nota come progettazione concettuale. Questa fase si propone di descrivere quanto segue:

  • I dati presenti nel database
  • Le relazioni tra gli elementi di dati
  • I vincoli sui dati

In questa fase iniziale del processo di progettazione del database, l’analisi dei requisiti informativi è essenziale. È la fase più importante perché l’efficacia complessiva del sistema si basa sulla precisione con cui i requisiti di informazione e le visualizzazioni utente sono specificati all’inizio. Le specifiche sui requisiti di informazione formulate in questa fase influiscono sulla forma finale e sul contenuto del sistema di database.

Dopo che le specifiche sono state determinate e sviluppate, devono essere strutturate in un sistema integrato e coeso, una procedura chiamata progettazione logica. La progettazione logica include i passaggi seguenti:

  1. Sviluppo di un modello di dati per ogni visualizzazione utente
  2. Integrazione delle entità, degli attributi e delle relazioni in uno schema logico composito che descrive il database per tale modulo in termini non correlati al pacchetto software utilizzato
  3. Trasformazione dello schema logico in uno schema software espresso nella lingua del pacchetto di gestione del database scelto

La fase finale della progettazione di un database è la progettazione fisica. Questo passaggio è necessario per modificare lo schema software in un modulo che può essere implementato con l’hardware specifico, il sistema operativo e il sistema di gestione del database di un’organizzazione. Nella progettazione fisica è coinvolta l’implementazione di requisiti di integrità e sicurezza e la progettazione di percorsi di navigazione

Grado di astrazione

L’astrazione dei dati significa l’occultamento di alcuni dettagli sul modo in cui i dati vengono archiviati e mantenuti. In termini di grado di astrazione, i modelli di database possono essere suddivisi in tre livelli, che sono:

  • Livello esterno o di visualizzazione, che è il più alto livello di astrazione e rappresenta solo una parte dell’intero database
  • Il livello logico, che descrive quali dati sono memorizzati nell’intero database
  • Il livello fisico, che è il livello più basso di astrazione e descrive come i dati vengono memorizzati nel database

Schemi di database

Lo schema del database può essere definito come la descrizione iniziale del database che non dovrebbe cambiare frequentemente. In un sistema di database esistono numerosi schemi. L’architettura del database è costituita da tre livelli di schemi.

Livello esterno

Questo è il livello più alto di schemi. La visualizzazione dati a livello esterno è concentrata su applicazioni specifiche per l’elaborazione dei dati o visualizzazioni utente. Contiene diverse visualizzazioni e rappresenta un frammento del database effettivo. Ogni visualizzazione viene offerta per un utente o un gruppo di utenti in modo che contribuisca a semplificare l’interazione tra l’utente e il sistema.

Livello concettuale

Questo livello descrive la struttura logica dell’intero database, che a sua volta è descritta da semplici concetti logici, inclusi gli oggetti, le loro proprietà o relazioni. Pertanto, la complessità dei dettagli di implementazione dei dati non sarà visibile dagli utenti. Nel database viene mantenuta una sola visualizzazione a livello concettuale. Affinché le entità o gli attributi possano essere indicati nel sistema di database, è necessario prima di tutto definire nella visualizzazione a livello concettuale, formalmente descritta come schema logico. Questa visione di livello deve essere altamente stabile, poiché considerata la base per lo sviluppo di opinioni a livello esterno e interno.

Livello interno

Il modo in cui i dati vengono archiviati e il modo di accedere ai dati sono descritti in questo schema. Il livello interno rappresenta lo stato interno o fisico del database. Il suo obiettivo è aumentare l’efficienza del sistema di database, soddisfacendo al contempo le esigenze richieste.

Indipendenza dei dati

L’indipendenza dei dati si riferisce alla capacità delle applicazioni utente di rimanere inalterate dalle modifiche apportate nella definizione e nell’organizzazione dei dati. Esistono due tipi di indipendenza dei dati: logica e fisica.

L’indipendenza logica dei dati è la possibilità di modificare lo schema logico (concettuale) senza influire sullo schema esterno o sulla visualizzazione utente. Le regolazioni dello schema logico, ad esempio le modifiche alla struttura del database come l’aggiunta di tabelle, non devono avere un effetto sulla funzione dell’applicazione (visualizzazioni esterne).

L’indipendenza fisica dei dati è la capacità dello schema a livello concettuale di rimanere inalterata dalle modifiche apportate allo schema interno. Le modifiche all’organizzazione dei file o alle strutture di archiviazione, ai dispositivi di archiviazione o alla strategia di indicizzazione non apportano cambiamenti a livello concettuale.

Il modello di dati relazionali

Il modello di dati relazionali è stato sviluppato dal Dr. Edgar F. Codd nel 1970. Rappresenta i dati in una forma tabellare, che è un modo familiare a molte persone di rappresentare i dati. La semplicità logica delle strutture di file piatte viene mantenuta in questo modello. Il modello relazionale si basa su una teoria degli insiemi, che fornisce le basi per molte delle operazioni eseguite sulle relazioni. Offre l’accesso più flessibile ai dati e, pertanto, è utile in ambienti decisionali dinamici.

SQL è un linguaggio di trasformazione relazionale; offre modi per formare relazioni e manipolare i dati. Il risultato di un’operazione di trasformazione è sempre un’altra relazione, che può contenere una sola riga e colonna.

Elementi di base di un modello di dati relazionali

La tabella 1.  Componenti di base di un modello di dati relazionali.

Componente del database Descrizione
Tavolo include colonne e righe; un sottoinsieme del prodotto cartesiano di una lista di domini caratterizzati da un nome
Colonne principali unità di stoccaggio; contengono gli elementi di base dei dati in cui il contenuto può essere suddiviso
Righe contengono colonne associate; insieme alle colonne costituiscono la base di tutti i database
Dominio un insieme di valori accettabili che possono essere inclusi in una colonna
Grado numero di colonne presenti in una tabella

Una relazione, chiamata anche tabella o file, può essere caratterizzata come una tabella bidimensionale costituita da dati relativi a una classe di entità o alle relazioni tra classi di entità. In ogni riga di una tabella vengono inclusi i dati che fanno riferimento a un’entità specifica e, in ogni colonna, viene incluso un attributo specifico. Le righe, o record, di una relazione possono essere denominate tuple. Un record all’interno di una tabella rappresenta un’istanza di un’entità. Il numero di righe in una relazione è indicativo della sua cardinalità. Il numero di colonne, note anche come campi o attributi, in una relazione corrisponde al grado della relazione.  Gli elementi di base di un modello di dati relazionali sono descritti nella tabella 1. Una relazione unaria è costituita da un solo attributo; una relazione binaria è costituita da soli due attributi; una relazione ternaria è costituita da soli tre attributi.

Caratteristiche di una tabella

  • Ogni tabella di un database ha un nome univoco
  • Non esistono righe duplicate; ogni riga è diversa
  • Ogni riga ha un nome diverso
  • La sequenza di righe e colonne non è importante
  • Le voci delle colonne derivano dallo stesso dominio in base al tipo di dati, tra cui: data, logico (true/false), carattere (stringa) e numero (numerico, intero, float, …)

Caratteristiche differenzianti del modello di database relazionale

Essenzialità: una struttura di dati è considerata essenziale se comporta una perdita di informazioni nel database, quando viene rimossa.

Regole di integrità: queste assicurano che il contenuto del database rimanga accurato e coerente. Esistono due tipi di integrità:

  1. Integrità dell’entità: consente l’identificazione univoca di ogni entità nel database relazionale. Questa capacità garantisce l’accesso a tutti i dati. Richiede che nessuna chiave primaria abbia un valore nullo.
  2. Integrità referenziale: consente il riferimento delle tuple utilizzando chiavi esterne. Richiede che i valori assunti da una chiave estranea corrispondano a una chiave primaria presente nel database o siano completamente nulli.

Manipolazione dei dati: un metodo per manipolare i dati; approccio principale per la creazione di informazioni per il processo decisionale.

Modello entità-relazione

Il modello di dati ER (Entity-Relationship) è disponibile da oltre 35 anni. È relativamente astratto e facile da spiegare. I modelli ER sono facilmente tradotti in relazioni e rappresentati da diagrammi ER. Relazioni ed entità sono i fondamenti di questo modello. Un’entità può essere un oggetto che esiste fisicamente o ha un’esistenza concettuale. Se le sue tabelle dipendono dall’esistenza, un’entità è caratterizzata come debole. Al contrario, se può esistere separatamente da tutte le entità associate, un’entità viene definita forte.

Esistono diversi tipi di entità:

  • Entità o kernel indipendenti: gli elementi costitutivi del database. Sono entità forti. La chiave primaria non è una chiave estera e può essere semplice o composita. I diversi tipi di chiavi sono descritti nella tabella 2.
  • Entità dipendenti o derivate: dipendono dall’esistenza da due o più tabelle. Sono usati per riunire due kernel e possono includere altri attributi. Ogni tabella correlata è identificata dalla chiave estera. Sono disponibili tre opzioni per la chiave primaria: i) utilizzare un composto di chiavi esterne di tabelle correlate, se univoche, ii) utilizzare un composito di chiavi esterne e una colonna qualificante, o iii) creare una nuova semplice chiave primaria.
  • Entità caratteristiche: queste entità offrono informazioni aggiuntive su un’altra tabella. Descrivono altre entità e sono rappresentativi di attributi multivariati. La chiave estera viene utilizzata per un’ulteriore identificazione della tabella caratterizzata.  Sono disponibili due opzioni per la chiave primaria: i) utilizzare un composito di chiavi esterne e una colonna qualificante, o ii) creare una nuova semplice chiave primaria.

La tabella 2.  Tipi di chiavi.

Tipi di chiavi Descrizione
Chiave candidata chiave semplice o composita unica, perché non due righe in una tabella possono avere lo stesso valore in qualsiasi momento e minime, poiché ogni colonna è necessaria per ottenere unicità
Chiave composita deve essere minimo; composto da due o più attributi
Chiave primaria chiave candidata scelta dal progettista del database per l’utilizzo come meccanismo di identificazione per l’intero set di entità; deve identificare in modo univoco le tuple in una tabella e non essere nullo; indicato nel modello ER sottolineando l’attributo
Chiave secondaria attributo rigorosamente utilizzato a fini di recupero; può essere composito
Chiave alternativa tutte le chiavi candidate non selezionate come chiave primaria
Chiave estera in una tabella che fa riferimento alla chiave primaria in un’altra tabella OPPURE può essere nulla

Valori nulli: diversi da zero o valori vuoti; non dipendono dal tipo di dati. Un valore nullo indica che il valore effettivo è sconosciuto o che l’attributo non è applicabile.

Esempi di tipi di entità e relazioni nelle banche dati biologiche

Un tipo di entità descrive le caratteristiche che sono condivise da un insieme di entità in un dominio. Per esempio, Protein può essere considerato come un tipo di entità, con attributi che includono sequenza, nome, peso molecolare, specie e numero di adesione. Un singolo tipo di entità avrà probabilmente diverse istanze, ognuna delle quali fornisce valori agli attributi che sono specificati nel tipo corrispondente. Per esempio, i nomi di due istanze del tipo di entità Protein sono α-emoglobina umana e mioglobina di balena. I valori dei loro attributi specie sarebbero rispettivamente umano e balena.

Le relazioni indicano che due o più tipi di entità sono associati. Per esempio, una proteina può interagire con molte altre proteine, o può essere un membro di una famiglia. Diverse categorie di relazioni possono descrivere la natura della relazione. Per esempio, un tipo di entità potrebbe essere rappresentato come una parte di un’altra (ad esempio, un filamento Beta è parte di un Foglio nella struttura secondaria di una Proteina) o come un tipo di un altro (ad esempio, un Enzima è un tipo di Proteina).

Modifica delle anomalie

Errori involontari possono verificarsi in un database durante i processi di inserimento, cancellazione o modifica dei dati. Se l’errore è il risultato della progettazione del database, questa è chiamata anomalia di modifica.

Esistono tre tipi di anomalie di modifica:

  1. Anomalia di eliminazione: rimozione di un’entità logica che porta alla perdita di informazioni su un’entità logica non correlata
  2. Anomalia di inserimento: l’inserimento di dati su un’entità logica che richiede l’inserimento di dati su un’entità logica non correlata
  3. Anomalia di aggiornamento: l’alterazione delle informazioni per un’entità logica che richiede più di un’alterazione di una relazione.

Definizioni chiave

Sistema centralizzato di database: i dati di questo sistema sono memorizzati in un unico sito

Sistema distribuito di database: database e software DBMS sono distribuiti in diversi siti connessi da una rete di computer.

Database: raccolta condivisa di dati associati da utilizzare per sostenere le attività delle organizzazioni.

DDL (Data Definition Language): utilizzato per definire gli schemi concettuali e interni

Database Management System (DBMS): programmi per computer utilizzati per la creazione, la gestione e la query di database

Modello di dati: raccolta di concetti utilizzati per la descrizione della struttura del database

Ridondanza dei dati: memorizzazione della stessa parte di dati in due o più posizioni nel sistema di database

Normalizzazione: un metodo che struttura i dati in modo tale da diminuire o evitare problemi

Ripristino: procedura di utilizzo di log e copie di backup per ricreare un database danneggiato

SQL (Structured Query Language)

SQL sta per Structured Query Language, un linguaggio informatico per l’archiviazione, la manipolazione e il recupero dei dati archiviati in un database relazionale. È il linguaggio di database più utilizzato. Offre modi per costruire relazioni e manipolare i dati. SQL è il linguaggio standard per i sistemi di database relazionali. Tutti i sistemi RDMS (Relational Database Management Systems), ad esempio MySQL, MS Access, Oracle, Sybase, Informix, Postgres e SQL Server, utilizzano SQL come linguaggio di database standard, sebbene utilizzino “dialetti” diversi:

  • MS SQL Server utilizza T-SQL
  • Oracle utilizza PL/SQL
  • MS Access utilizza una versione di SQL denominata JET SQL (formato nativo) e così via.

Elenco comandi SQL

Segue un elenco di comandi SQL che copre tutte le azioni necessarie con i database SQL. Tuttavia, come accennato in precedenza, potrebbero esserci alcune differenze tra diversi tipi di database, incluso l’uso di diversi “dialetti”. Ogni comando SQL viene fornito con la sua sintassi e descrizione.
I comandi in SQL sono denominati Query e sono di due tipi:
1.Query definizione dati: le istruzioni che definiscono la struttura di un database, creano tabelle, specificano le chiavi, gli indici e così via,
2.Query di manipolazione dei dati: queste sono le query che possono essere modificate.

Elenco comandi SQL1:

Comando Sintassi Descrizione
ALTER table ALTER TABLE table_name ADD column_name datatype; Viene utilizzato per aggiungere colonne a una tabella in un database
AND SELECT column_name(s)FROM table_nameWHERE column_1 = value_1 AND column_2 = value_2; È un operatore che viene utilizzato per combinare due condizioni
AS SELECT column_name AS ‘Alias’FROM table_name; È una parola chiave in SQL utilizzata per rinominare una colonna o una tabella utilizzando un nome alias
AVG SELECT AVG(column_name)FROM table_name; Viene utilizzato per aggregare una colonna numerica e restituire la sua media
BETWEEN all candidate keys not selected as the primary key È un operatore utilizzato per filtrare il risultato entro un certo intervallo
CASE attribute in a table that references the primary key in another table OR it can be null Si tratta di un’istruzione utilizzata per creare output diversi all’interno di un’istruzione SELEZIONA
COUNT all candidate keys not selected as the primary key È una funzione che prende il nome di una colonna come argomento e conta il numero di righe quando la colonna non è NULLA
Create TABLE attribute in a table that references the primary key in another table OR it can be null Viene utilizzato per creare una nuova tabella in un database e specificare il nome della tabella e delle colonne al suo interno
DELETE all candidate keys not selected as the primary key Viene utilizzato per rimuovere le righe da una tabella
GROUP BY attribute in a table that references the primary key in another table OR it can be null È una clausola in SQL utilizzata per le funzioni aggregate in collaborazione con l’istruzione SELEZIONA
HAVING all candidate keys not selected as the primary key Viene utilizzato in SQL perché la parola chiave DOVE non può essere utilizzata nell’aggregazione delle funzioni
INNER JOIN attribute in a table that references the primary key in another table OR it can be null Viene utilizzato per combinare righe di tabelle diverse se la condizione UNISCI diventa VERA
INSERT all candidate keys not selected as the primary key Viene utilizzato per aggiungere nuove righe a una tabella
IS NULL/ IS NOT NULL attribute in a table that references the primary key in another table OR it can be null È un operatore utilizzato con la clausola DOVE per verificare la presenza dei valori vuoti
LIKE all candidate keys not selected as the primary key È un operatore speciale utilizzato con la clausola DOVE per cercare un modello specifico in una colonna
LIMIT attribute in a table that references the primary key in another table OR it can be null È una clausola per specificare il numero massimo di righe che il set di risultati deve avere
MAX all candidate keys not selected as the primary key È una funzione che prende il numero di colonne come argomento e restituisce il valore più grande tra loro
MIN attribute in a table that references the primary key in another table OR it can be null È una funzione che prende il numero di colonne come argomento e restituisce il valore più piccolo tra di esse
OR primary key Si tratta di un operatore utilizzato per filtrare il set di risultati in modo da contenere solo le righe in cui una delle due condizioni è VERO
ORDER BY attribute in a table that references the primary key in another table OR it can be null È una clausola utilizzata per ordinare il set di risultati in base a una particolare colonna numericamente o alfabeticamente
OUTER JOIN all candidate keys not selected as the primary key Viene utilizzato per combinare righe di tabelle diverse anche se la condizione NON È VERA
ROUND attribute in a table that references the primary key in another table OR it can be null È una funzione che accetta il nome della colonna e un numero intero come argomento e arrotonda i valori di una colonna al numero di cifre decimali specificato da un numero intero
SELECT all candidate keys not selected as the primary key Si tratta di un’istruzione utilizzata per recuperare dati da un database
SELECT DISTINCT attribute in a table that references the primary key in another table OR it can be null Viene utilizzato per specificare che l’istruzione è una query che restituisce valori univoci in colonne specificate
SUM all candidate keys not selected as the primary key È funzione utilizzata per restituire la somma dei valori da una particolare colonna
UPDATE attribute in a table that references the primary key in another table OR it can be null Viene utilizzato per modificare le righe di una tabella
WHERE all candidate keys not selected as the primary key Si tratta di una clausola utilizzata per filtrare il set di risultati in modo da includere le righe in cui la condizione DOVE è VERO
WITH WITH temporary_name AS (SELECT *FROM table_name)SELECT *FROM temporary_nameWHERE column_name operator value; Viene utilizzato per memorizzare il risultato di una particolare query in una tabella temporanea utilizzando un alias

Comandi e sintassi per l’esecuzione di query sui dati da una singola tabella o da più tabelle2:

Tabella singola Tabella multipla
SELECT c1 FROM t
Per selezionare i dati della colonna c1 dalla tabella t
SELECT c1, c2
FROM t1
INNER JOIN t2 su conditionSeleziona le colonne c1 e c2 dalla tabella t1 ed esegui un inner join tra t1 e t2
SELECT * FROM t
Per selezionare tutte le righe e le colonne della tabella t
SELECT c1, c2
FROM t1
LEFT JOIN t2 su condizione
Seleziona la colonna c1 e c2 dalla tabella t1 ed effettua una join sinistra tra t1 e t2
SELECT c1 FROM t
WHERE c1 = ‘test’
Per selezionare i dati nella colonna c1 dalla tabella t, dove c1=test
SELECT c1, c2
FROM t1
RIGHT JOIN t2 u condizione
Seleziona la colonna c1 e c2 dalla tabella t1 ed effettua una join a destra tra t1 e t2
SELECT c1 FROM t
ORDER BY c1 ASC (DESC)
To select data in column c1 from table t either in ascending or descending order
SELECT c1, c2
FROM t1
FULL OUTER JOIN t2 su condizione
Seleziona la colonna c1 e c2 dalla tabella t1 ed effettua una full outer join tra t1 e t2
SELECT c1 FROM t
ORDER BY c1LIMIT n OFFSET offset
Per selezionare i dati nella colonna c1 dalla tabella t in ordine crescente o decrescente
SELECT c1, c2
FROM t1
CROSS JOIN t2
Selezionare la colonna c1 e c2 dalla tabella t1 e produrre un prodotto cartesiano di righe in una tabella
SELECT c1, aggregate(c2)
FROM t
GROUP BY c1
Per saltare l’offset delle righe e restituire le n righe successive
SELECT c1, c2
FROM t1, t2 Seleziona la colonna c1 e c2 dalla tabella t1 e produce un prodotto cartesiano di righe in una tabella
SELECT c1, aggregate(c2)
FROM t
GROUP BY c1HAVING Per raggruppare le righe usando una funzione aggregata
SELECT c1, c2
FROM t1 A
INNER JOIN t2 B su condizione
Selezionare la colonna c1 e c2 dalla tabella t1 e unirla a se stessa utilizzando la clausola INNER JOIN

Database commerciali e gratuiti utilizzati nel mondo reale

Figura 1: Elenco non esaustivo delle basi di dati disponibili

Questa parte si occupa delle basi di dati comuni presenti sul mercato, siano esse libere o proprietarie. Tuttavia, ci sono così tante banche dati disponibili (Figura 1) che non possiamo menzionarle tutte. Una scelta doveva essere fatta e quelli presentati di seguito sono i “più popolari” o i “più utilizzati”.

Database commerciali

Dal gran numero di banche dati disponibili sul mercato, abbiamo scelto di presentare tre banche dati commerciali comunemente utilizzate dalle principali aziende e organizzazioni.

SAP HANA

Questa banca dati è stata progettata dalla società europea SAP SE, fondata in Germania. SAP HANA è un motore di database orientato alle colonne e in grado di gestire dati SAP e non SAP. Il motore è progettato per salvare e recuperare dati da applicazioni e altre fonti su più livelli di archiviazione. SAP HANA può essere distribuito in locale o nel cloud da diversi provider di servizi cloud. Questo database viene in genere scelto da organizzazioni che estraggono dati dalle applicazioni e non hanno un budget terribilmente limitato.

Le sue caratteristiche principali sono:

  • Supporta SQL, OLTP e OLAP.
  • Il motore riduce i requisiti di risorse attraverso la compressione.
  • I dati vengono memorizzati in memoria, riducendo significativamente i tempi di accesso, in alcuni casi.
  • Sono disponibili report in tempo reale e gestione dell’inventario.
  • Può interfacciarsi con una serie di altre applicazioni.

A partire da gennaio 2021, le piattaforme hardware attualmente supportate per SAP HANA sono3:

  • Piattaforme hardware basate su Intel
  • IBM Power Systems

A partire da gennaio 2021, i sistemi operativi attualmente supportati per SAP HANA sono4:

  • Linux SUSE
  • Linux Red Hat

Database IBM Db2

Il database IBM Db2 affonda le sue radici all’inizio degli anni ’70 quando Edgar F. Codd, un ricercatore che lavorava per l’azienda, descrisse la teoria dei database relazionali e nel giugno 1970 pubblicò il modello per la manipolazione dei dati. Oggi è un motore di database che ha funzionalità NoSQL e può leggere file JSON e XML5,6.

L’attuale versione di DB2 è LUW 11.1, che offre una varietà di miglioramenti. Uno, in particolare, è stato un miglioramento di BLU Acceleration (BLink Ultra o Big Data, Lightning fast e Ultra-easy), progettato per far funzionare più velocemente questo motore di database attraverso la tecnologia di salto dei dati. Il salto dei dati è progettato per migliorare la velocità dei sistemi con più dati di quelli che possono adattarsi alla memoria. L’ultima versione di Db2 offre anche funzioni di ripristino di emergenza migliorate, compatibilità e analisi.

Le sue caratteristiche principali sono:

  • BLU Acceleration può sfruttare al meglio le risorse disponibili per enormi database.
  • Può essere ospitato dal cloud, da un server fisico o entrambi contemporaneamente.
  • È possibile eseguire più processi contemporaneamente utilizzando l’Utilità di pianificazione.
  • I codici di errore e i codici di uscita possono determinare quali processi vengono eseguiti tramite l’Utilità di pianificazione.

Le piattaforme hardware attualmente supportate a partire da gennaio 2021 per IBM Db2 sono7:

  • Mainframe IBM z/Architecture
  • Piattaforme hardware basate su Intel

I sistemi operativi attualmente supportati a partire da gennaio 2021 per IBM Db2 sono:

  • z/OS
  • Unix
  • Linux
  • finestre

Oracle Database

Oracle Database è comunemente utilizzato per eseguire l’elaborazione delle transazioni online (OLTP) o il data warehousing (DW). Può anche mixare i carichi di lavoro del database OLTP e DW. Oracle Database è disponibile in locale, on-cloud o come installazione cloud ibrida. Può essere eseguito su server di terze parti, nonché su hardware Oracle Exadata in locale, su Oracle Cloud o su un Cloud privato presso la sede del cliente.

La prima versione fu rilasciata nel 1979 e il suo sviluppo fu influenzato dalla ricerca di Edgar F. Codd sulla progettazione di database relazionali.

Le sue caratteristiche principali sono:

  • È un database multipiattaforma. Può essere eseguito su vari hardware tra sistemi operativi, tra cui Windows Server, Unix e varie distribuzioni di GNU/Linux.
  • Ha il suo stack di rete che consente alle applicazioni di una piattaforma diversa di comunicare senza problemi con il database Oracle, ad esempio le applicazioni in esecuzione su Windows possono connettersi al database Oracle in esecuzione su Unix.
  • È un database compatibile con ACID che aiuta a mantenere l’integrità e l’affidabilità dei dati.

Le piattaforme hardware attualmente supportate sono:

  • Accessorio database Oracle proprietario
  • Sparc
  • IBM Power Systems
  • Piattaforme hardware basate su X64

I sistemi operativi attualmente supportati sono8:

  • Unix
  • Linux
  • Windows

Database gratuiti9

Se un database è gratuito, ciò non significa necessariamente che non vengono addebitate commissioni all’utente. È vero per alcuni dei seguenti database, tuttavia, alcuni sviluppatori scelgono di limitare determinate funzionalità e addebitare una commissione per essere in grado di sbloccare tali funzionalità (fare riferimento alla prima unità del livello di base).

MySQL

MySQL è un database relazionale open source, che gira su una serie di piattaforme diverse, tra cui Windows, Linux, macOS, ecc. Una versione cloud. MySQL può essere utilizzato per software confezionato, sistemi business-critical e siti Web ad alto volume.

Le sue caratteristiche principali sono:

  • Offre scalabilità e flessibilità
  • Lo strumento ha punti di forza del web e del data warehouse
  • Offre alte prestazioni
  • Ha un solido supporto transazionale

PostgreSQL

PostgreSQL è un sistema di gestione di database open source di classe enterprise. Supporta sia SQL per le query relazionali che JSON per le query non relazionali. È supportato da una comunità esperta di sviluppatori che hanno dato un enorme contributo per renderlo un software di gestione dei database altamente affidabile. Funziona su tre diverse piattaforme, vale a dire Windows, Linux e macOS. Una versione cloud non è disponibile. PostgreSQL consente la creazione di tipi di dati personalizzati e di un intervallo di metodi di query. Una stored procedure può essere eseguita in diversi linguaggi di programmazione.

Le sue caratteristiche principali sono:

  • È compatibile con varie piattaforme che utilizzano tutte le principali lingue e middleware
  • Server di standby e disponibilità elevata
  • Lo strumento ha funzionalità di programmazione lato server mature
  • SSL di replica basato su log e trigger
  • Offre un meccanismo di bloccaggio più sofisticato
  • Supporto per il controllo della concorrenza multiversione
  • Fornisce supporto per l’architettura di rete client-server
  • Lo strumento è orientato agli oggetti e compatibile con ANSI-SQL2008
  • PostgreSQL consente il collegamento con altri archivi di dati come NoSQL, che fungono da hub federato per database poliglotta.

Microsoft SQL

SQL Server è un RDBMS sviluppato da Microsoft. Supporta ANSI SQL, che è il linguaggio SQL (Structured Query Language) standard. SQL Server, tuttavia, viene fornito con l’implementazione del linguaggio SQL T-SQL (Transact-SQL). Funziona su Docker Engine, Ubuntu, SUSE Linux Enterprise Server e Red Hat Enterprise Linux. È disponibile una versione cloud.

Le sue caratteristiche principali sono:

  • Fornisce l’integrazione di dati strutturati e non strutturati con la potenza di SQL Server e Spark.
  • Lo strumento offre scalabilità, prestazioni e disponibilità per applicazioni mission-critical e intelligenti, data warehouse e data lake.
  • Offre funzionalità di sicurezza avanzate per proteggere i tuoi dati.
  • Accesso a report Power BI ricchi e interattivi, per prendere una decisione migliore e veloce.

MariaDB

MariaDB è un fork del sistema di gestione dei database MySQL. È stato creato dai suoi sviluppatori originali. Questo strumento DBMS offre funzionalità di elaborazione dei dati sia per le attività di piccole dimensioni che per le attività aziendali. Funziona su tre piattaforme, vale a dire Windows, Linux e macOS. È disponibile una versione cloud. MariaDB è un software alternativo a MySQL. Offre un’elevata scalabilità grazie a una facile integrazione.

Le sue caratteristiche principali sono:

  • Opera sotto licenze GPL, BSD o LGPL.
  • Viene fornito con molti motori di archiviazione, compresi quelli ad alte prestazioni che possono essere integrati con altri sistemi di gestione dei database relazionali.
  • Fornisce la tecnologia dell’ammasso Galera.
  • MariaDB può funzionare su diversi sistemi operativi e supporta numerosi linguaggi di programmazione.

Oracle

Oracle è un database auto-riparante, autoprotezione e guida autonoma progettato per eliminare la gestione manuale dei dati. È un database intelligente, sicuro e altamente disponibile nel cloud che aiuta le aziende a crescere. Funziona su due piattaforme, vale a dire Windows e Linux. È disponibile anche una versione cloud.

Le sue caratteristiche principali sono:

  • Oracle Cloud è ottimizzato per carichi di lavoro di database ad alte prestazioni, carichi di lavoro di streaming e big data iperscala.
  • Puoi facilmente eseguire la migrazione al cloud.
  • Fornisce i servizi in base al modo in cui ti piace operare, al fine di eseguire Oracle Cloud nel tuo data center.

Firebirdsql

Firebird è un RDBMS SQL open source che gira su Microsoft Windows, macOS, Linux e diverse piattaforme Unix, tra cui HP-UX, Solaris e AIX. È disponibile una versione cloud. Firebird ha un supporto linguistico adatto allo sviluppo, stored procedure e trigger.

Le sue caratteristiche principali sono:

  • Firebird ti consente di creare una versione personalizzata.
  • È gratuito scaricare, registrare e distribuire.
  • Lo strumento ha migliorato RDBMS multipiattaforma.
  • Fornisce una serie di opzioni di finanziamento, dalle iscrizioni firebird agli impegni di sponsorizzazione.

Database nel mondo scientifico modulo avanzato

Questa sezione è dedicata all’ulteriore esplorazione delle basi di dati ad accesso aperto utilizzate nella scienza e su come utilizzare e trarre vantaggio dalle conoscenze esistenti.

Panoramica delle banche dati nel mondo scientifico

Banche dati esistenti dedicate alla scienza e come utilizzarle

Come accennato in precedenza, la condivisione, l’integrazione e l’annotazione dei dati è una parte cruciale della ricerca biologica in quanto consente ai ricercatori di riprodurre l’esame e l’interpretazione dei risultati sperimentali. Sebbene si pensa che i bioinformatici e gli informatici siano responsabili di queste azioni, gli scienziati della vita hanno un ruolo uguale nel promuovere l’integrazione dei dati, poiché sono quelli che generano questi tipi di dati e sono di solito gli utenti finali.

L’integrazione dei dati è definita come il processo di combinazione di dati provenienti da fonti diverse al fine di offrire agli utenti una visione unificata di tali dati. Nelle scienze computazionali sono stati classificati i quadri teorici per l’integrazione dei dati, sulla base del metodo utilizzato per integrare i dati, in “desiderosi” e “pigri”. Secondo il metodo eager, noto anche come magazzino, i dati vengono copiati in uno schema globale e archiviati in un data warehouse centrale. Il termine “schema” si riferisce a un approccio   organizzato e “interrogabile” per la memorizzazione dei dati. Nel metodo pigro, i dati si trovano in origini distribuite e sono integrati su richiesta in conformità con uno schema globale utilizzato per mappare i dati tra le origini. Il volume di dati, il proprietario dei dati e l’infrastruttura esistente sono i principali fattori che determinano in ultima analisi quale dei due metodi verrà utilizzato per l’integrazione dei dati. Inoltre, nelle scienze biologiche, questi metodi possono essere applicati in vari modi diversi e utilizzati a una serie di livelli. Di conseguenza, sono stati formulati sei schemi distinti e ampiamente utilizzati per l’integrazione dei dati:

  • Centralizzazione dei dati: i dati risiedono in risorse centralizzate. UniProt e GenBank sono due esempi di database che seguono questo metodo.
  • Data warehousing: data da una varietà di fonti risiedono in un repository centrale. Pathway commons è un database che segue questo approccio per integrare i dati.
  • Integrazione dei set di dati: i flussi di lavoro internamente accedono ai database distribuiti e scaricano i dati in un repository locale.
  • Collegamenti ipertestuali: questo approccio consente agli utenti di accedere a database e strumenti in diversi campi delle scienze della vita, promuovendo così l’interoperabilità. ExPASy è un esempio indicativo di un portale basato su questa metodologia di integrazione dei dati.
  • Database federati: è necessario un livello trascizionale per integrare i dati tra database eterogenei. Ciò significa che i dati del database vengono trasformati in un formato comunemente accettato in modo tale da poter essere interpretati allo stesso modo da un servizio di mapping. Il Distributed Annotation System (DAS), che è un sistema client-server, è un esempio indicativo.
  • Dati collegati: una rete di dati interconnessi accessibili online. Interfacce utente grafiche (GUI) che consistono in collegamenti ipertestuali, che collegano i dati associati da numerosi provider di dati e, quindi, formano un ampio sistema di dati collegati. BIO2RDF è un esempio indicativo di una banca dati che utilizza questo approccio come base per l’integrazione dei dati.

La centralizzazione dei dati, il data warehousing e l’integrazione dei set di dati si basano sul framework teorico “eager”, mentre i collegamenti ipertestuali, i database federati e i dati collegati si basano sul quadro teorico “pigro” relativo al modo selezionato per l’integrazione dei dati.

I formati di dati sono descritti come un modo organizzato per la dimostrazione di dati e metadati in un file. Gli scienziati hanno iniziato a memorizzare dati biologici in file formattati perché la crescita esponenziale dei dati ha creato la necessità di analizzarli utilizzando sistemi informatici e database. Un problema che è sorto in relazione alla formattazione dei file è l’emergere di vari formati, anche per la rappresentazione dello stesso tipo di dati. In alcuni casi, è stato osservato che più di una classe di formato può essere utilizzata per rappresentare i dati e i metadati in un singolo file. Inoltre, la ricerca ha dimostrato che le classi di formato più utilizzate sono: i) tabelle, ii) simili a FASTA, iii) strutturate con tag e iv) simili a GenBank. La soluzione ideale a questo problema sarebbe che gli scienziati concordano sull’utilizzo di un numero limitato di formati specifici in modo da semplificare il processo di integrazione dei dati. Anche la progettazione di convertitori che hanno la capacità di tradurre tutte le diverse classi di formati fornirebbe una soluzione utile.

Attualmente sono in uso oltre 1.700 banche dati tra cui dati di interesse biologico, secondo l’elenco non esaustivo curato dalla rivista Nucleic Acids Research. Per essere ritenuti preziosi per uno scopo specifico, tutti i set di dati presenti in un database devono essere integrati e strutturati. Le banche dati biologiche esistenti sono composte da informazioni su una vasta gamma di argomenti di ricerca sulla biologia, come la genomica non vertebrata, la sequenza proteica, i geni e le malattie umane, la sequenza nucleotidica del DNA, la biologia cellulare, l’immunologia, le vie metaboliche e di segnalazione, la proteomica, ecc.

Come accennato in precedenza nel livello di base, la classificazione delle banche dati biologiche dipende da diversi fattori, tra cui l’ambito di copertura dei dati e il livello di biocurazione. Tuttavia, la loro classificazione in base al tipo di dati è uno dei modi più semplici e completi per classificare le banche dati biologiche. Pertanto, nella sezione seguente, questi saranno descritti come database di DNA, RNA, proteine, malattie, espressione e percorso.

Database del DNA

I database del DNA si concentrano sulla gestione dei dati del DNA provenienti da numerose o poche specie particolari. Lo scopo principale delle banche dati del DNA umano è quello di stabilire il genoma di riferimento, condurre la profilazione della variazione genetica umana, associare il genotipo al fenotipo e identificare i metagenomi microbioma umani. Un esempio di database del DNA è GenBank, una raccolta pubblicamente disponibile di tutte le sequenze di DNA studiate. A febbraio 2021, oltre 776 miliardi di basi nucleotidiche in oltre 226 milioni di sequenze sono disponibili in GenBank (http://www.ncbi.nlm.nih.gov/genbank/statistics).

Database dell’RNA

Questi database includono informazioni sugli RNA non codificanti (ncRNA), come i microRNA e gli RNA lunghi non codificanti (lncRNA), che non codificano le proteine. Lo scopo dei database dell’RNA è decodificare gli ncRNA, di cui gli lncRNA sono i più comunemente studiati, e descrivere le loro funzioni e interazioni. Un esempio di database RNA è RNAcentral, che consiste in una vista unificata dei dati della sequenza ncRNA derivati da un certo numero di database, alcuni dei quali sono Rfam, miRBase e lncRNAdb.

Database proteici

Sono stati sviluppati database proteici al fine di creare una vasta raccolta di proteine universali, identificare famiglie e domini proteici, ricostruire alberi filogenetici e condurre il profilo delle strutture proteiche. Il PDB, che consiste di migliaia di strutture di macromolecole biologiche, è un esempio indicativo di database proteici.

Banche dati sulla malattia

Per definizione, le banche dati sulle malattie includono informazioni sui diversi tipi di malattie, ma si concentrano principalmente sulla fornitura di dati relativi a vari tipi di cancro. Uno dei più importanti progetti sul cancro che è stato sviluppato è The Cancer Genome Atlas (TCGA), il cui obiettivo è quello di raccogliere una vasta gamma di dati omici, come mRNA, SNP e metilazione, per oltre venti diverse forme di cancro umano.

Database delle espressioni

I database delle espressioni possono essere utilizzati per una serie di attività, come lo studio dell’espressione e della regolazione genica specifica dei tessuti, la memorizzazione dei dati di espressione, il rilevamento dell’espressione differenziale e di base e l’esame e la revisione delle informazioni sull’espressione ottenute dai dati sull’RNA e sulle proteine. Come database di espressioni, l’Atlante delle proteine umane incorpora profili di espressione per una percentuale significativa di geni codificanti proteine umane derivati da dati sull’RNA e sulle proteine.

Database dei percorsi

I database dei percorsi includono dati sulle vie biologiche che possono essere utilizzati dai ricercatori per l’analisi delle vie metaboliche, normative  e  di segnalazione. Un esempio caratteristico di database di percorsi è KEGG PATHWAY, che contiene informazioni riguardanti le reti di interazione molecolare e reazione.

Il National Center for Biotechnology Information (NCBI), parte della National Library of Medicine degli Stati Uniti presso il National Institute of Health, ha sviluppato un sistema integrato di recupero dei database, che offre l’accesso a 34 diverse banche dati contenenti collettivamente 3,0 miliardi di record, chiamati Entrez. La pagina di ricerca globale di Entrez

(https://www.ncbi.nlm.nih.gov/search/)

fornisce collegamenti al portale Web per ciascuno dei 34 database. Il sistema Entrez è facile da usare perché consente agli utenti di scaricare dati in una varietà di formati e di eseguire ricerche di testo utilizzando semplici query booleane.  I record sono collegati tra database in base a relazioni affermate; questi record possono essere rappresentati in vari formati. Inoltre, gli utenti di Entrez hanno la possibilità di scaricare singoli record o lotti di record. Alcuni dei 34 database che fanno parte di Entrez sono i seguenti: PubMed (https://pubmed.ncbi.nlm.nih.gov), che contiene abstract / citazioni scientifiche e mediche; BioSample (https://www.ncbi.nlm.nih.gov/biosample), che comprende descrizioni di materiali di origine biologica; Geo Profiles (https://www.ncbi.nlm.nih.gov/geoprofiles), che include l’espressione genica e i profili di abbondanza molecolare; e, dbVar (https://www.ncbi.nlm.nih.gov/dbvar), che contiene dati provenienti da studi di variazione strutturale del genoma.

I dati presentati all’NCBI provengono da tre fonti: i) direttamente dai ricercatori, ii) partenariati o accordi nazionali e internazionali con fornitori di dati e consorzi di ricerca e iii) sforzi interni di cura. Da segnalare, NCBI è responsabile della gestione della banca dati GenBank e dei partakes nell’International Nucleotide Sequence Database Collaboration (INSDC) in collaborazione con l’ARCHIVIO Nucleotide Europeo EMBL-EBI (ENA) e la DNA Data Bank of Japan (DDBJ).

Poiché le banche dati si sono dimostrate uno strumento utile in molti campi scientifici, il loro utilizzo sta guadagnando costantemente terreno nel settore sanitario. Al giorno d’oggi, i progressi tecnologici nel campo della data science hanno permesso agli operatori sanitari di compilare, elaborare e analizzare dati relativi alla salute, portando al miglioramento non solo dell’erogazione delle cure, ma anche della sicurezza dei pazienti e dei consumatori. Affinché tali miglioramenti si apportare, i dati pertinenti devono essere raccolti, archiviati e analizzati in modo efficiente e sicuro e scambiati tra i diversi livelli di servizio presenti in un sistema sanitario. Ciò ha portato allo sviluppo di cartelle cliniche elettroniche (EHR), database che memorizzano i dati dei pazienti a cui è possibile accedere e utilizzare gli operatori sanitari.

Gli EHR possono essere definiti come database medici che offrono agli utenti, che in questo caso sono operatori sanitari e personale amministrativo, l’accesso alle cartelle cliniche. I tipi più distinti di EHR sono la cartella clinica elettronica (EMR) e la cartella clinica personale (PHR). Gli ENF sono costituiti da informazioni, che vengono presentate da un singolo reparto ospedaliero, da un intero ospedale o da parti dell’ospedale. Possono anche contenere informazioni provenienti da un certo numero di ospedali. Le informazioni a questo tipo di EHR vengono normalmente aggiunte solo dal personale ospedaliero. Al contrario, i PHR sono gestiti dai pazienti, che sono in grado di inserire informazioni. I PHR sono descritti come applicazioni elettroniche che forniscono una piattaforma sicura per i pazienti per controllare e condividere i loro dati sanitari. La principale differenza tra i due tipi di sistemi EHR è che, nei PHR, le cartelle cliniche devono essere presentate in modo comprensibile per il paziente, mentre, negli EHR, il modo in cui vengono presentate le cartelle cliniche assomiglia alle cartelle cliniche sui documenti, poiché sono accessibili solo dagli operatori sanitari.

Il primo sistema EHR divenne disponibile negli anni ’60 principalmente a causa dell’accumulo di informazioni sui pazienti non strutturate e inutilizzate per un periodo di diversi decenni. Le grandi organizzazioni hanno iniziato a creare sistemi di database per archiviare e strutturare i dati in repository centrali. Questi database hanno permesso l’organizzazione e la raccolta di dati da molte fonti diverse, tra cui farmacie, laboratori, studi clinici e costituenti delle cure cliniche, come le cartelle cliniche dei farmaci. Attualmente, l’implementazione dei sistemi EHR è osservata principalmente nei paesi ad alto reddito. Ad esempio, lo Health Information Technology for Economic and Clinical Health Act (HITECH Act del 2009) ha portato alla digitalizzazione del sistema di erogazione sanitaria negli Stati Uniti e al successivo sviluppo dei programmi di incentivazione Medicare e Medicaid EHR.

Lo scopo principale per la creazione di EHR era la necessità di archiviare e strutturare i registri dei pazienti. In seguito sono stati designati per motivi di fatturazione e miglioramento della qualità. Con i progressi tecnologici, nel corso degli anni gli EHR sono diventati più inclusivi, dinamici e interconnessi. Tuttavia, rispetto ad altri settori, i bigdata non sono stati utilizzati al meglio nel settore medico. Ciò è avvenuto principalmente a causa della scarsa qualità dei dati raccolti e dei set di dati scarsamente strutturati. Prima dello sviluppo degli EHR, la ricerca medica si basava su registri delle malattie o sistemi di gestione delle malattie croniche (CDMS). Questi repository hanno limitazioni significative, poiché consistono in raccolte di dati che sono spesso correlati a una sola malattia particolare. Inoltre, non possono eseguire la traduzione dei dati o delle conclusioni ad altre malattie e possono includere informazioni da un gruppo di pazienti in una specifica area geografica. D’altra parte, i dati dell’EHR sono in gran parte vari, facilitando così l’analisi di interazioni e decisioni cliniche complesse.

I componenti degli EHR sono diversi tipi di dati medici, che vanno dalle cartelle cliniche ai dati sensoriali grezzi. I dati medici possono essere classificati in dati sensibili o non sensibili. I dati sensibili includono informazioni sul paziente o possono essere associati a un paziente. I dati non sensibili includono dati sensoriali, che sono anche chiamati dati di misurazione a causa del fatto che sono costituiti solo da campioni di sensori, come campioni di una misurazione EEG. I dati memorizzati in un database medico vengono indicati come metadati. Il tipo più comune di database utilizzato per l’archiviazione dei dati medici è il database relazionale, che presenta dati sotto forma di tabelle composte da righe e un numero prestabilito di colonne. Alcuni database possono includere informazioni sui pazienti, come la storia medica di un paziente, o dati anonimizzati che possono essere utilizzati negli studi.

I dati medici possono essere suddivisi in diverse categorie come descritto di seguito:

  • Dati medici e di laboratorio: Gli operatori sanitari possono inviare ordini per farmaci o studi di laboratorio in un sistema di ingresso all’ordine medico, che vengono successivamente eseguiti da personale di laboratorio o infermieristico. Esempi di questa categoria di dati sono le prescrizioni per i farmaci e i risultati della microbiologia.
  • Dati di fatturazione: questa categoria di dati medici è costituita da codici utilizzati dagli ospedali per presentare i sinistri ai loro fornitori di assicurazioni. La classificazione internazionale delle malattie, costruitadall’OMS, e l’attuale terminologia procedurale, sostenuta dall’American Medical Association, sono i sistemi di codifica più popolari.
  • Immagini: Queste possono essere immagini radiografiche risultanti da raggi X, ecocardiogrammi e scansioni di tomografia computerizzata (CT).
  • Note e rapporti: Questi possono essere associati allo stato di avanzamento dei pazienti. Anche le sintesi degli scarichi appartengono a questa categoria. I risultati degli studi di imaging sono solitamente descritti nei rapporti operativi. Le note devono essere parzialmente strutturate utilizzando un sistema di modelli.
  • Dati fisiologici: Questa categoria di dati medici contiene segni vitali, come frequenza cardiaca e pressione sanguigna, nonché forme d’onda ECG ed EEG.

I database relazionali sono utilizzati più frequentemente per la gestione e l’archiviazione dei dati medici. Possono essere indicati come una raccolta di tabelle connesse da chiavi condivise. Uno schema di database determina la struttura delle tabelle e le relazioni. Un semplice database medico può contenere quattro tabelle:

  • Tabella 1: elenco dei pazienti
  • Tabella 2: registro dei ricoveri ospedalieri
  • Tabella 3: elenco con misurazioni vitali dei segni
  • Tabella 4: un dizionario di codici segno vitali ed etichette associate

Le chiavi primarie ed esterne possono essere utilizzate per collegare le quattro tabelle.

La preponderanza delle banche dati sanitarie fornisce un accesso limitato ai dati per vari motivi, tra cui problemi di privacy e piani per monetizzare i dati. Tuttavia, sono disponibili per uso pubblico una serie di banche dati sanitarie ad accesso aperto, alcune delle quali sono descritte di seguito.

The preponderance of healthcare databases provides limited access to data for various reasons, including privacy concerns and plans to monetise the data. Nonetheless, a number of open access health databases are available for public use, some of which are described below.

Il database Medical Information Mart for Intensive Care (MIMIC)

Il database MIMIC (http://mimic.physionet.org) è stato creato nel 2003 come risultato di una collaborazione tra MIT, Philips Medical Systems e Beth Israel Deaconess Medical Center (BIDMC). I dati inseriti in questo database provengono da pazienti medici e chirurgici ricoverati in tutte le Unità di Terapia Intensiva di BIDMC. Consiste in informazioni provenienti da oltre quarantamila pazienti, dati fisiologici e clinici dettagliati, ed è de-identificato e apertamente accessibile ai ricercatori. In questo database sono presenti due tipi di dati: i dati clinici derivati dagli EHR, che sono memorizzati in un database relazionale composto da circa 50 tabelle, e le forme d’onda del monitor comodino memorizzate in file binari piatti.  L’obiettivo di questa collaborazione è produrre e valutare sistemi avanzati di monitoraggio e supporto decisionale dei pazienti in terapia intensiva che alla fine renderanno il processo decisionale nelle cure critiche più efficiente, veloce e accurato.

PCORnet

PCORnet, la Rete nazionale di ricerca clinica incentrata sul paziente, è un’iniziativa iniziata nel 2013 con l’obiettivo di integrare i dati provenienti da diverse reti di ricerca sui dati clinici e reti di ricerca basate sui pazienti. Contiene 29 reti che faciliteranno l’accesso a grandi quantità di ricerca. Raccoglie dati da visite di routine dei pazienti e dati condivisi da singoli pazienti tramite cartelle cliniche personali o reti comunitarie con altri pazienti.

Open NHS

Il National Health Services (NHS England) mantiene uno dei più grandi repository al mondo contenente dati relativi alla salute delle persone. Open NHS<sup>10</sup>  è un database open source che fornisce l’accesso alle informazioni rese disponibili al pubblico dal governo o da altri enti pubblici. Questo progetto è stato istituito al fine di aumentare la trasparenza e monitorare l’efficienza del settore sanitario britannico. I pazienti, gli operatori sanitari e i commissari hanno l’opportunità di confrontare la qualità dell’assistenza in varie località del paese semplicemente accedendo ai dati disponibili nel database appositamente progettato.

De-identificazione del database

Uno dei passaggi principali per la creazione di un database EHR è la de-identificazione. Prima che una banca dati diventi disponibile per l’uso da parte di ricercatori e applicazioni, è essenziale adottare misure per garantire che le politiche e le normative sulla privacy siano seguite. Per i dati strutturati, ad esempio le colonne di una tabella, la de-identificazione si basa sulla categorizzazione dei dati e sulla successiva eliminazione o crittografia di quelli contrassegnati come protetti. Per i dati non strutturati, come i riepiloghi di scarica, vengono utilizzate diverse tecniche di elaborazione del linguaggio naturale, dalle semplici espressioni regolari alle reti neurali complesse, che cercano di trovare tutte le informazioni protette in tutto il testo libero al fine di eseguire la cancellazione o la crittografia.

L’applicazione della blockchain nella salute digitale

La tecnologia Blockchain si basa sul concetto di avere un sistema decentralizzato per l’archiviazione dei dati, dove una copia del libro mastro delle transazioni eseguite sarà fornita ad ogni partecipante/nodo. Questo renderà impossibile che qualcuno possa modificare i dati senza che gli altri partecipanti ne siano informati. Le entità fortemente centralizzate beneficerebbero dell’applicazione di blockchain. Le applicazioni della salute digitale dipendono molto dai sistemi centralizzati. Pertanto, blockchain ha il potenziale per trasformare la salute digitale modificando il modo in cui i dati vengono memorizzati e protetti. Sono stati proposti vari settori per la sua applicazione, tra cui le catene di approvvigionamento, la verifica dei farmaci, il rimborso delle richieste, il controllo degli accessi e gli studi clinici.

I dati medici sono stati trovati come i dati più apprezzati dagli hacker, poiché studi recenti hanno stimato che una singola cartella clinica può costare fino a 400 USD. Ciò significa che mantenere i dati al sicuro nei database medici è della massima importanza. Blockchain può fornire una soluzione a questo problema garantendo la privacy, l’integrità, l’autenticazione e l’autorizzazione dei dati. I dati blockchain sono crittografati e se qualcuno deve cancellare o rendere inutili i propri dati, gli viene data tale capacità applicando un meccanismo di distruzione della chiave, in cui la chiave originariamente utilizzata per la crittografia del messaggio verrà distrutta o resa inutile. Successivamente, i dati memorizzati nella blockchain non saranno accessibili alla lettura.

Blockchain è in grado di soddisfare due esigenze essenziali in materia di condivisione dei dati: integrità e non ripudio. Integrità significa che la query e i dati recuperati non possono essere modificati, una volta eseguita l’operazione di recupero. Il non ripudio significa che il servizio di recupero delle conoscenze non possiede la capacità di negare che i dati specifici siano stati forniti dal servizio come risposta a una determinata query in un determinato momento. Blockchain può essere definito come un sistema di gestione delle transazioni distribuite che non può essere danneggiato. Può essere applicato per l’integrazione, la condivisione e il controllo degli accessi EHR, la conservazione e la gestione.

Un servizio teorico di notaio di query basato su blockchain può essere composto da tre livelli computazionali:

  • un front-end consumer di dati
  • un’interfaccia per comunicare con le interfacce di database biomediche, e
  • il motore del contratto, che organizza la query e restituisce i risultati recuperati al consumatore, esegue e prepara le transazioni e gestisce i contratti e i relativi metadati

Due diversi schemi possono essere impiegati per applicare il servizio notarile: lo schema di base e lo schema di versioning. Lo schema di base applica un libro mastro di query-risposta con il quale l’utente riceve una prova sigillata che verifica che in un momento specifico una particolare query è stata inserita in un database biomedico, che ha restituito risultati specifici. Questo schema può essere impiegato per assicurare l’integrità e il non ripudio di una richiesta, quando un compito biomedico vitale si basa sulla specifica richiesta. Lo schema di versioning permette il versioning non affidabile dei dati recuperati da un database biomedico in evoluzione dinamica in numerose occasioni nel tempo, sempre utilizzando la stessa query. Questo schema può essere applicato per confermare diverse versioni di prove mediche che cambiano come recuperate da un database biomedico con contenuti che vengono aggiornati frequentemente.

L’incorporazione della tecnologia blockchain nelle applicazioni farmaceutiche o delle scienze della vita ha la capacità di decentralizzare l’interfaccia e la condivisione dei dati, portando a una maggiore efficienza, velocità più elevate e scalabilità illimitata. Blockchain rende i dati immutabili, il che sarebbe utile negli studi clinici per garantire che i dati clinici non possano essere manipolati dai ricercatori in un secondo momento. Può anche essere utilizzata nel processo di identificazione, tracciamento e verifica dei farmaci. Ci sono alcuni rischi associati all’implementazione di blockchain, come i problemi di privacy, le transazioni fuori catena e i dubbi su questa tecnologia a causa della mancanza di adozione. Tuttavia, i benefici della tecnologia blockchain superano di gran lunga i possibili svantaggi e potrebbero avere un ruolo significativo nel limitare i metodi utilizzati per le attività illegali.

Test: LO5 Livello avanzato

Referenze

  • Agha-Mir-Salim L, Sarmiento RF. 2020. Health information technology as premise for data science in global health: A discussion of opportunities and challenges. In: Leveraging Data Science for Global Health. Cham: Springer International Publishing, 3–15.
  • Amid C, Alako BTF, Balavenkataraman Kadhirvelu V, Burdett T, Burgin J, Fan J, Harrison PW, Holt S, Hussein A, Ivanov E et al. 2020. The European nucleotide archive in 2019. Nucleic Acids Res., 48:D70–76.
  • Apweiler R, Bairoch A, Wu CH, Barker WC, Boeckmann B, Ferro S, et al. 2004. Uniprot: the universal protein knowledgebase. Nucleic Acids Res., 32 (Suppl 1):115–9. doi: 10.1093/nar/gkh131.
  • Artimo P, Jonnalagedda M, Arnold K, Baratin D, Csardi G, de Castro E, et al. 2012. ExPASy: SIB bioinformatics resource portal. Nucleic Acids Res., 40(Web Server issue):597–603. doi: 10.1093/nar/gks400.
  • Belleau F, Nolin MA, Tourigny N, Rigault P, Morissette J. 2008. Bio2RDF: towards a mashup to build bioinformatics knowledge systems. J Biomed Inform., 41(5):706–16.
  • Benson DA, Clark K, Karsch-Mizrachi I, Lipman DJ, Ostell J, Sayers EW. 2014. GenBank. Nucleic Acids Res., 42:D32–D37.
  • Benson DA, Clark K, Karsch-Mizrachi I, Lipman DJ, Ostell J, Sayers EW. 2014. GenBank. Nucleic Acids Res., 42:D32–D37.
  • Benson DA, Clark K, Karsch-Mizrachi I, Lipman DJ, Ostell J, Sayers EW. 2014. GenBank. Nucleic Acids Res., 42:D32–D37.
  • Bornberg-Bauer E, Paton NW. 2002. Conceptual data modelling for bioinformatics. Brief Bioinform., 3(2):166–80.
  • Bulgarelli L, Núñez-Reiz A, Deliberato RO. 2020. Building electronic health record databases for research. In: Leveraging Data Science for Global Health. Cham: Springer International Publishing, 55–64.
  • Burge SW, Daub J, Eberhardt R , Tate J, Barquist L, Nawrocki EP, et al. 2013. Rfam 11.0: 10 years of RNA families, Nucleic Acids Res., 41: D226-232.
  • Cancer Genome Atlas Research Network, Weinstein JN, Collisson EA, Mills GB, Shaw KR, Ozenberger BA, et al. 2013. The Cancer Genome Atlas Pan-Cancer analysis project, Nat Genet., 45: 1113-1120.
  • Cerami EG, Gross BE, Demir E, Rodchenkov I, Babur O, Anwar N, et al. 2011. Pathway Commons, a web resource for biological pathway data. Nucleic Acids Res.; 39(Database issue): 685–90.
  • Chavali LN, Prashanti NL, Sujatha K, Rajasheker G, Kavi Kishor PB. 2018. The Emergence of Blockchain Technology and its Impact in Biotechnology, Pharmacy and Life Sciences. Current Trends in Biotechnology and Pharmacy., 12(3):304–10.
  • Courtney JF, Paradice DB, Brewer KL, Graham JC. 2010. Database Systems for Management. 3rd edition. The Global Text Project.
  • Dowell RD, Jokerst RM, Day A, Eddy SR, Stein L. 2001. The distributed annotation system. BMC Bioinformatics., 2:7.
  • Edgar F. Codd https://en.wikipedia.org/wiki/Edgar_F._Codd
  • Fleurence RL, Curtis LH, Califf RM, Platt R, Selby JV, Brown JS. 2014. Launching PCORnet, a national patient-centered clinical research network. J Am Med Inform Assoc JAMIA., 21(4):578–582.
  • Fortier PJ, Michel HE. 2003. Computer Data Processing Hardware Architecture. In: Computer Systems Performance Evaluation and Prediction. Elsevier, p. 39–106.
  • Hellerstein JM, Stonebraker M, Hamilton J. 2007. Architecture of a database system. Found Tren Databases., 1(2):141–259.
  • Johnson A, Pollard T, Shen L et al. 2016. MIMIC-III, a freely accessible critical care database. Sci Data 3., 160035.
  • Karsch-Mizrachi I, Takagi T, Cochrane G. 2018. International Nucleotide Sequence Database, C The international nucleotide sequence database collaboration. Nucleic Acids Res., 46:D48–51.
  • Kleinaki A-S, Mytis-Gkometh P, Drosatos G, Efraimidis PS, Kaldoudi E. 2018. A blockchain-based notarization service for biomedical knowledge retrieval. Comput Struct Biotechnol J., 16:288–97.
  • Kozomara A, Griffiths-Jones S. 2014. MiRBase: annotating high confidence microRNAs using deep sequencing data, Nucleic Acids Res., 42: D68-73.
  • Lapatas V, Stefanidakis M, Jimenez RC, Via A, Schneider MV. 2015. Data integration in biological research: an overview. J Biol Res (Thessalon)., 22(1):9.
  • Lastdrager E. 2011. Securing Patient Information in Medical Databases [Internet]. University of Twente;. Available from: https://essay.utwente.nl/61035/1/MSc_E_Lastdrager_DIES_CTIT.pdf
  • Marshall J, Chahin A, Rush B. 2016. Review of clinical databases. In: Secondary Analysis of Electronic Health Records. Cham: Springer International Publishing;, 9–16.
  • Nguyen KA. Database System Concepts. OpenStax CNX; 2009 [cited 2021 Jan 29]. Available from: http://cnx.org/contents/b57b8760-6898-469d-a0f7-06e0537f6817@1
  • Ogasawara O, Kodama Y, Mashima J, Kosuge T, Fujisawa T. 2020. DDBJ database updates and computational infrastructure enhancement. Nucleic Acids Res., 48:D45–50.
  • Okuda S, Yamada T, Hamajima M, Itoh M, Katayama T, Bork P, et al. 2008. KEGG Atlas mapping for global analysis of metabolic pathways, Nucleic Acids Res., 36: W423-426.
  • Oliveira AL. 2019. Biotechnology, big data and artificial intelligence. Biotechnol J., 14(8):e1800613.
  • Pollard T, Dernoncourt F, Finlayson S, Velasquez A. 2016. Data Preparation. In: Secondary Analysis of Electronic Health Records. Cham: Springer International Publishing;, 101–14.
  • Ponten F, Schwenk JM, Asplund A, Edqvist PH. 2011. The Human Protein Atlas as a proteomic resource for biomarker discovery, J Intern Med., 270: 428-446.
  • Quek XC, Thomson DW, Maag JL, Bartonicek N, Signal B, Clark MB, et al. 2015. lncRNAdb v2.0: expanding the reference database for functional long noncoding RNAs, Nucleic Acids Res., 43, D168-173.
  • Rose PW, Beran B, Bi C, Bluhm WF, Dimitropoulos D, Goodsell DS, et al. 2011. The RCSB Protein Data Bank: redesigned web site and web services, Nucleic Acids Res., 39: D392-401.
  • Sayers EW, Beck J, Bolton EE, Bourexis D, Brister JR, Canese K, et al. 2021. Database resources of the National Center for Biotechnology Information. Nucleic Acids Res., 49(D1):D10–7.
  • Schuler G.D., Epstein J.A., Ohkawa H., Kans J.A. 1996. Entrez: molecular biology database and retrieval system. Methods Enzymol., 266:141–162.
  • The RNAcentral Consortium, RNAcentral: an international database of ncRNA sequences. 2015. Nucleic Acids Res., 43: D123-129.
  • Watt A, Eng N. Types of Data Models. In: Watt A, Eng N, editors. Database Design – 2nd edition. BCcampus; 2014 [cited 2021 Jan 29]. Available from: https://opentextbc.ca/dbdesign01
  • Watt A. Characteristics and Benefits of a Database. In: Watt A, Eng N, editors. Database Design – 2nd edition. BCcampus; 2014 [cited 2021 Jan 29]. Available from: https://opentextbc.ca/dbdesign01/
  • Watt A. Data Modelling. In: Watt A, Eng N, editors. Database Design – 2nd edition. BCcampus; 2014 [cited 2021 Jan 29]. Available from: https://opentextbc.ca/dbdesign01
  • Watt A. The Entity Relationship Data Model. In: Watt A, Eng N, editors. Database Design – 2nd edition. BCcampus; 2014 [cited 2021 Jan 29]. Available from: https://opentextbc.ca/dbdesign01
  • Watt A. The Relational Data Model. In: Watt A, Nelson E, editors. Database Design – 2nd edition. BCcampus; 2014 [cited 2021 Jan 29]. Available from: https://opentextbc.ca/dbdesign01
  • Zou D, Ma L, Yu J, Zhang Z. 2015. Biological databases for human research. Genomics Proteomics Bioinformatics., 13(1):55–63.
  • Zuniga PCC, Zuniga RAC, Mendoza MJ-A, Cariaga AA, Sarmiento RF, Marcelo AB. 2020. Workshop on Blockchain Use Cases in Digital Health. In: Leveraging Data Science for Global Health. Cham: Springer International Publishing;, 99–107.
  • Agha-Mir-Salim L, Sarmiento RF. 2020. Health information technology as premise for data science in global health: A discussion of opportunities and challenges. In: Leveraging Data Science for Global Health. Cham: Springer International Publishing, 3–15.
  • Amid C, Alako BTF, Balavenkataraman Kadhirvelu V, Burdett T, Burgin J, Fan J, Harrison PW, Holt S, Hussein A, Ivanov E et al. 2020. The European nucleotide archive in 2019. Nucleic Acids Res., 48:D70–76.
  • Apweiler R, Bairoch A, Wu CH, Barker WC, Boeckmann B, Ferro S, et al. 2004. Uniprot: the universal protein knowledgebase. Nucleic Acids Res., 32 (Suppl 1):115–9. doi: 10.1093/nar/gkh131.
  • Artimo P, Jonnalagedda M, Arnold K, Baratin D, Csardi G, de Castro E, et al. 2012. ExPASy: SIB bioinformatics resource portal. Nucleic Acids Res., 40(Web Server issue):597–603. doi: 10.1093/nar/gks400.
  • Belleau F, Nolin MA, Tourigny N, Rigault P, Morissette J. 2008. Bio2RDF: towards a mashup to build bioinformatics knowledge systems. J Biomed Inform., 41(5):706–16.
  • Benson DA, Clark K, Karsch-Mizrachi I, Lipman DJ, Ostell J, Sayers EW. 2014. GenBank. Nucleic Acids Res., 42:D32–D37.
  • Benson DA, Clark K, Karsch-Mizrachi I, Lipman DJ, Ostell J, Sayers EW. 2014. GenBank. Nucleic Acids Res., 42:D32–D37.
  • Benson DA, Clark K, Karsch-Mizrachi I, Lipman DJ, Ostell J, Sayers EW. 2014. GenBank. Nucleic Acids Res., 42:D32–D37.
  • Bornberg-Bauer E, Paton NW. 2002. Conceptual data modelling for bioinformatics. Brief Bioinform., 3(2):166–80.
  • Bulgarelli L, Núñez-Reiz A, Deliberato RO. 2020. Building electronic health record databases for research. In: Leveraging Data Science for Global Health. Cham: Springer International Publishing, 55–64.
  • Burge SW, Daub J, Eberhardt R , Tate J, Barquist L, Nawrocki EP, et al. 2013. Rfam 11.0: 10 years of RNA families, Nucleic Acids Res., 41: D226-232.
  • Cancer Genome Atlas Research Network, Weinstein JN, Collisson EA, Mills GB, Shaw KR, Ozenberger BA, et al. 2013. The Cancer Genome Atlas Pan-Cancer analysis project, Nat Genet., 45: 1113-1120.
  • Cerami EG, Gross BE, Demir E, Rodchenkov I, Babur O, Anwar N, et al. 2011. Pathway Commons, a web resource for biological pathway data. Nucleic Acids Res.; 39(Database issue): 685–90.
  • Chavali LN, Prashanti NL, Sujatha K, Rajasheker G, Kavi Kishor PB. 2018. The Emergence of Blockchain Technology and its Impact in Biotechnology, Pharmacy and Life Sciences. Current Trends in Biotechnology and Pharmacy., 12(3):304–10.
  • Courtney JF, Paradice DB, Brewer KL, Graham JC. 2010. Database Systems for Management. 3rd edition. The Global Text Project.
  • Dowell RD, Jokerst RM, Day A, Eddy SR, Stein L. 2001. The distributed annotation system. BMC Bioinformatics., 2:7.
  • Edgar F. Codd https://en.wikipedia.org/wiki/Edgar_F._Codd
  • Fleurence RL, Curtis LH, Califf RM, Platt R, Selby JV, Brown JS. 2014. Launching PCORnet, a national patient-centered clinical research network. J Am Med Inform Assoc JAMIA., 21(4):578–582.
  • Fortier PJ, Michel HE. 2003. Computer Data Processing Hardware Architecture. In: Computer Systems Performance Evaluation and Prediction. Elsevier, p. 39–106.
  • Hellerstein JM, Stonebraker M, Hamilton J. 2007. Architecture of a database system. Found Tren Databases., 1(2):141–259.
  • Johnson A, Pollard T, Shen L et al. 2016. MIMIC-III, a freely accessible critical care database. Sci Data 3., 160035.
  • Karsch-Mizrachi I, Takagi T, Cochrane G. 2018. International Nucleotide Sequence Database, C The international nucleotide sequence database collaboration. Nucleic Acids Res., 46:D48–51.
  • Kleinaki A-S, Mytis-Gkometh P, Drosatos G, Efraimidis PS, Kaldoudi E. 2018. A blockchain-based notarization service for biomedical knowledge retrieval. Comput Struct Biotechnol J., 16:288–97.
  • Kozomara A, Griffiths-Jones S. 2014. MiRBase: annotating high confidence microRNAs using deep sequencing data, Nucleic Acids Res., 42: D68-73.
  • Lapatas V, Stefanidakis M, Jimenez RC, Via A, Schneider MV. 2015. Data integration in biological research: an overview. J Biol Res (Thessalon)., 22(1):9.
  • Lastdrager E. 2011. Securing Patient Information in Medical Databases [Internet]. University of Twente;. Available from: https://essay.utwente.nl/61035/1/MSc_E_Lastdrager_DIES_CTIT.pdf
  • Marshall J, Chahin A, Rush B. 2016. Review of clinical databases. In: Secondary Analysis of Electronic Health Records. Cham: Springer International Publishing;, 9–16.
  • Nguyen KA. Database System Concepts. OpenStax CNX; 2009 [cited 2021 Jan 29]. Available from: http://cnx.org/contents/b57b8760-6898-469d-a0f7-06e0537f6817@1
  • Ogasawara O, Kodama Y, Mashima J, Kosuge T, Fujisawa T. 2020. DDBJ database updates and computational infrastructure enhancement. Nucleic Acids Res., 48:D45–50.
  • Okuda S, Yamada T, Hamajima M, Itoh M, Katayama T, Bork P, et al. 2008. KEGG Atlas mapping for global analysis of metabolic pathways, Nucleic Acids Res., 36: W423-426.
  • Oliveira AL. 2019. Biotechnology, big data and artificial intelligence. Biotechnol J., 14(8):e1800613.
  • Pollard T, Dernoncourt F, Finlayson S, Velasquez A. 2016. Data Preparation. In: Secondary Analysis of Electronic Health Records. Cham: Springer International Publishing;, 101–14.
  • Ponten F, Schwenk JM, Asplund A, Edqvist PH. 2011. The Human Protein Atlas as a proteomic resource for biomarker discovery, J Intern Med., 270: 428-446.
  • Quek XC, Thomson DW, Maag JL, Bartonicek N, Signal B, Clark MB, et al. 2015. lncRNAdb v2.0: expanding the reference database for functional long noncoding RNAs, Nucleic Acids Res., 43, D168-173.
  • Rose PW, Beran B, Bi C, Bluhm WF, Dimitropoulos D, Goodsell DS, et al. 2011. The RCSB Protein Data Bank: redesigned web site and web services, Nucleic Acids Res., 39: D392-401.
  • Sayers EW, Beck J, Bolton EE, Bourexis D, Brister JR, Canese K, et al. 2021. Database resources of the National Center for Biotechnology Information. Nucleic Acids Res., 49(D1):D10–7.
  • Schuler G.D., Epstein J.A., Ohkawa H., Kans J.A. 1996. Entrez: molecular biology database and retrieval system. Methods Enzymol., 266:141–162.
  • The RNAcentral Consortium, RNAcentral: an international database of ncRNA sequences. 2015. Nucleic Acids Res., 43: D123-129.
  • Watt A, Eng N. Types of Data Models. In: Watt A, Eng N, editors. Database Design – 2nd edition. BCcampus; 2014 [cited 2021 Jan 29]. Available from: https://opentextbc.ca/dbdesign01
  • Watt A. Characteristics and Benefits of a Database. In: Watt A, Eng N, editors. Database Design – 2nd edition. BCcampus; 2014 [cited 2021 Jan 29]. Available from: https://opentextbc.ca/dbdesign01/
  • Watt A. Data Modelling. In: Watt A, Eng N, editors. Database Design – 2nd edition. BCcampus; 2014 [cited 2021 Jan 29]. Available from: https://opentextbc.ca/dbdesign01
  • Watt A. The Entity Relationship Data Model. In: Watt A, Eng N, editors. Database Design – 2nd edition. BCcampus; 2014 [cited 2021 Jan 29]. Available from: https://opentextbc.ca/dbdesign01
  • Watt A. The Relational Data Model. In: Watt A, Nelson E, editors. Database Design – 2nd edition. BCcampus; 2014 [cited 2021 Jan 29]. Available from: https://opentextbc.ca/dbdesign01
  • Zou D, Ma L, Yu J, Zhang Z. 2015. Biological databases for human research. Genomics Proteomics Bioinformatics., 13(1):55–63.
  • Zuniga PCC, Zuniga RAC, Mendoza MJ-A, Cariaga AA, Sarmiento RF, Marcelo AB. 2020. Workshop on Blockchain Use Cases in Digital Health. In: Leveraging Data Science for Global Health. Cham: Springer International Publishing;, 99–107.

1 Fonte https://intellipaat.com/blog/tutorial/sql-tutorial/sql-commands-cheat-sheet/

2 Fonte https://intellipaat.com/blog/tutorial/sql-tutorial/sql-commands-cheat-sheet/

3 Fonte SAP SE https://help.sap.com/viewer/eb3777d5495d46c5b2fa773206bbfb46/2.0.01/en-US/d3d1cf20bb5710149b57fd794c827a4e.html

4 per più informazioni sui sistemi operativi supportati per SAP HANA, see SAP Note 2235581 – SAP HANA: https://service.sap.com/sap/support/notes/2235581

5 JavaScript Object Notation è un Aprire file standard format come XML ed è considerato come dati non strutturati.

6 XML è un standard aperto file format come JSON ed è considerato come dati non strutturati.

7 Fonte supporto IBM Support https://www.ibm.com/support/pages/system-requirements-ibm-db2-linux-unix-and-windows#1155S

8 Fonte https://support.oracle.com/knowledge/Oracle%20Database%20Products/1369107_1.html

9 Fonte https://www.guru99.com/free-database-software.html updated on 2021

10 Dati aperti presso il SSN. Disponibile presso: http://www.england.nhs.uk/ourwork/tsd/data-info/open-data/