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

Database commerciali e gratuiti utilizzati nel mondo reale

Database nel mondo scientifico modulo avanzato

Test: LO5 Levello Avanzato

Referenze

Struttura avanzata di una banca dati

Database commerciali e gratuiti utilizzati nel mondo reale

Database nel mondo scientifico modulo avanzato

Test: LO5 Levello Avanzato

Referenze

 

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/