Il modello di database relazionale

Come è noto, i database sono componenti fondamentali di qualsiasi sistema informatico. Infatti ogni programma utilizza dati o genera informazioni che devono essere memorizzate in modo affidabile e permanente. Ciò viene fatto in database strutturati (DB) che sono gestiti dai cosiddetti database management system (DBMS), ovvero sistemi di gestione del database, applicazioni software che interagiscono con gli utenti finali o altri programmi e forniscono loro un sottoinsieme di dati memorizzati nel database.

Ad oggi la gestione elettronica dei dati è dominata dai modelli di database relazionale. Questo è un elenco in ordine alfabetico dei sistemi di gestione di database relazionali (RDBMS) più utilizzati:

  • Db2: Db2 è un sistema relazionale di gestione del database proprietario di casa IBM, a disposizione dell’utente con licenza commerciale.
     
  • Microsoft SQL Server: questo sistema di gestione del database di Microsoft è disponibile con licenza a pagamento Microsoft per l’utente finale.
     
  • MySQL: MySQL è uno degli RDBMS open source più utilizzati del mondo. Da quando è stato acquisito da Oracle, MySQL è sul mercato con un doppio sistema di licenze: la comunità di sviluppatori originale continua il progetto con il nome MariaDB.
     
  • PostgreSQL: con PostgreSQL gli utenti hanno a disposizione un sistema di gestione di database relazionale a oggetti (ORDBMS) gratuito. La community open source si occupa anche di proseguirne lo sviluppo.
     
  • Oracle Database: il sistema di database relazionale dell’omonima azienda Oracle è commercializzato come software proprietario a pagamento.
     
  • SQLite: SQLite è una libreria di dominio pubblico contenente un sistema di gestione del database relazionale.

Tutti i sistemi nominati si basano su un’organizzazione tabulare di informazione. Ma cosa significa? Vi presentiamo alcuni principi di base della progettazione dei database relazionali, introduciamo i database relazionali con esempi e vi spieghiamo le differenze che intercorrono con altri modelli.

Cosa sono i database relazionali?

Come è prevedibile, il termine centrale nei modelli di database relazionali è quello di relazione. Un concetto che risale al matematico e teorico dei database britannico Edgar F. Codd. Secondo Codd una relazione rappresenta un insieme di entità con le stesse proprietà: ogni relazione consiste in una serie di dati (le cosiddette tuple), i cui valori sono associati a determinati attributi.

Si definisce quali siano gli attributi compresi da una relazione e quali tipi di dati corrispondano ai valori assegnati agli attributi utilizzando uno schema di relazione secondo la seguente sintassi:

R = (A1 : Tipo1, A2 : Tipo2 ,… , An : Tipon)

Lo schema di relazione (R) comprende gli attributi da A1a An. A ciascun attributo è assegnato un tipo di dato (Tipo1, Tipo2ecc.). Questo schema di relazione può essere illustrato da un esempio concreto.

Lo schema seguente specifica gli attributi della relazione “collaboratore”:

collaboratore = (c_id: integer, 
cognome : string, 
nome : string, 
cf : string, 
ind : string, 
cap : string,
luogo : string  )

Questo schema di esempio tocca gli attributi ID del collaboratore (c_id), cognome, nome, codice fiscale (cf), indirizzo (ind), codice di avviamento postale (cap) e luogo e potrebbe per esempio servire alla gestione interna aziendale dei dati personali. A ogni attributo viene assegnata una tipologia di dato (ad esempio string o integer), indicando che in questa relazione ci sono attributi che concepiscono come valori una stringa di segni, mentre altre non accettano che numeri interi.

Una relazione con lo schema appena definito potrebbe contenere la seguente tupla:

(1, Bianchi, Maria, BNCMRA18E47R230W, via Roma 1, 11111 Roma)

Per poter rappresentare l’attribuzione di singoli valori di una tupla agli attributi definiti nello schema di relazioni, nel modello di database relazionale viene utilizzato uno dei concetti classici dell’organizzazione delle informazioni: la tabella. Un database relazionale perciò non è altro che un insieme di tabelle correlate.

Le tabelle sono schemi di ordinamento di righe orizzontali e colonne verticali che consentono di raccogliere le informazioni e presentarle in formo ordinato. Ogni riga di una tabella di database corrisponde a una tupla. I valori delle tuple elencate vengono assegnati tramite le colonne della tabella agli attributi definiti nello schema delle relazioni.

Nell’esempio seguente potete vedere come una tabella di database possa rappresentare lo schema dei collaboratori sopra illustrato:

c_id Cognome Nome cf Ind CAP Luogo
1 Bianchi Maria BNCMRA55F59F500S Via Roma 1 11111 Roma
2 Rossi Giada RSSGDI97G54B243L Via Matteotti 1 22222 Genova
3 Padovan Gianluca PDVGLC55M21L424T Via F.lli Cervi 1 33333 Gela
4 Terragna Elisabetta TRRLBT32R56C352Z Via Quasimodo 1 44444 Novara

La tabella di esempio serve all’archiviazione dei dati personali e consta di quattro record. Ognuno di essi contiene informazioni su un collaboratore preciso.

N.B.

Il termine “relazione” viene utilizzato da Edgar F. Codd come sinonimo di “tabella”, però nella pratica questa parola viene utilizzata in modi differenti, per esempio per indicare relazioni tra diverse tabelle (relationships). Per non incorrere in equivoci, eviteremo il concetto di “relazione” e parleremo da ora in poi di “tabelle” quando ci riferiamo a tabelle di database in un database relazionale.

Come funzionano i database relazionali?

Il database di un sistema di database relazionale costituisce la base di dati tabulare strutturata. La sua struttura di dati viene definita dal sistema di gestione del database, che è anche responsabile della gestione degli accessi in lettura e scrittura. Gli utenti interagiscono con il sistema di gestione del database utilizzando un linguaggio di database. Ogni sistema di gestione di database relazionali supporta almeno un linguaggio formale che può essere utilizzato per eseguire le seguenti operazioni di database:

  • Definire la struttura di dati: nell’ambito della definizione dei dati viene archiviata una descrizione della struttura dei dati attraverso i metadati nel data dictionary del sistema di database. Se ad esempio un utente crea una nuova tabella, viene archiviato uno schema di relazione corrispondente nel dizionario dei dati. Il vocabolario di un linguaggio di database utilizzato per la definizione dei dati, viene chiamato Data Definition Language (DDL).
     
  • Definire le autorizzazioni: ogni linguaggio del database fornisce una sintassi che consente di concedere o revocare le autorizzazioni. In questo caso si parla di Data Control Language (DCL), una parte del vocabolario del linguaggio del database.
     
  • Definire i vincoli: i vincoli sono i requisiti per lo stato di un database. Definiti i criteri per l’integrità, il database assicura che vengano soddisfatti in ogni momento e per questo si parla di “stato coerente”. Ad esempio un vincolo di base di integrità nei sistemi di database relazionali è che ogni record (tupla) può essere identificato in modo univoco.
     
  • Definire le transazioni: quando un database viene spostato da uno stato consistente ad un altro, si parla di transazione. Le transazioni contengono una serie di istruzioni e devono essere sempre portate a termine, perché se una transazione viene interrotta, il database viene ripristinato nello stato iniziale (rollback). Ogni transazione inizia con l’indicazione di connettersi al database. A questo seguono comandi che avviano l’effettiva operazione nonché un commit che garantisce l’integrità del database. Le operazioni pericolose per l’integrità non vengono eseguite (scritte permanentemente nel database). Infine viene chiusa la connessione al database. Il vocabolario del linguaggio di database che soggiace alla manipolazione dei dati viene chiamato Data Manipulation Language (DML).
     
  • Definire le view: una view è una vista virtuale dei dati selezionati. Il sistema di gestione del database crea una tabella virtuale (relazione logica) basata su tabelle fisiche. Con queste view gli utenti possono applicare le stesse operazioni del database come se si trattasse di una tabella fisica. Esistono diversi tipi di visualizzazione dei dati a seconda della funzione, le più comuni sono le view che filtrano determinate righe (vista selezione) o colonne (vista proiezione) da una tabella selezionata, nonché view che collegano insieme tabelle diverse (vista composita).

Normalmente l’interfaccia standard per le operazioni di database illustrate sopra nei modelli di database relazionali è quella basata su SQL (Structured Query Language), un linguaggio di database basato sull’algebra relazionale.

Le operazioni del database come le query, la creazione, l’aggiornamento o l’eliminazione di dati vengono eseguite utilizzando le cosiddette SQL statements, una combinazione di comandi SQL selezionati. Essi sono basati semanticamente sulla lingua inglese e sono perciò di ovvio significato. La seguente tabella contiene i termini chiave del modello di dati relazionali e il loro equivalente nella terminologia SQL.

Modello di dati relazionale SQL
Relazione Table (tabella)
Attributo Column (colonna)
Tupla Row (riga)

Una semplice query di dati scelti si può implementare per esempio con SQL secondo il seguente schema:

SELECT colonna FROM tabella WHERE colonna = valore;

Inizialmente usiamo il comando SELECT, per assegnare all’RDBMS la richiesta dei dati. In seguito definiamo quali dati vogliamo richiedere, inserendo la tabella e la colonna desiderata. Inoltre utilizziamo “WHERE” per inserire un vincolo nello statement SQL. Non vogliamo richiamare tutto l’insieme di valori degli attributi contenuti nella colonna, ma soltanto il valore di un particolare record. Con riferimento alla nostra tabella di esempio “collaboratori” un simile SQL statement può apparire come segue:

SELECT cf FROM collaboratori WHERE c_id = 3;

Lo statement SQL chiede al RDBMS di richiamare dalla tabella “collaboratori” un valore dalla colonna cf. Come vincolo abbiamo definito che il valore debba essere estrapolato dal record il cui valore nella colonna c_id è 3.

Come risultato il database ci riporta “PDVGLC55M21L424T”, ovvero il codice fiscale di Gianluca Padovan, il collaboratore con l’ID numero 3.

Consiglio

Il nostro tutorial MySQL per principianti fornisce una descrizione esauriente delle operazioni di database soggiacenti basandosi sul linguaggio SQL.

Normalizzazione

Quando si lavora con database relazionali, gli utenti raramente devono gestire singole tabelle. Di norma vengono utilizzate strutture nelle quali i dati vengono ordinati in base al loro significato e memorizzati in tabelle separate. Questo concetto, che si basa sul modello di database relazionale, implica la necessità di collegare tabelle di dati, ad esempio quando si interrogano dati memorizzati in tabelle diverse.

In linea di principio si possono anche riunire tutte le informazioni di un database relazionale in una tabella generale, con il vantaggio che si risparmia il collegamento tra le tabelle del database e la complessa sintassi associata alla query su più tabelle. Ma questa è la forza del modello di database relazionale: la divisione delle informazioni su più tabelle serve a ridurre le voci duplicate (le cosiddette anomalie) e si chiama normalizzazione. Il grado di normalizzazione può essere determinato utilizzando forme normali (Normal form) predefinite. Le comuni forme normali per le tabelle di database relazionali sono:

  1. Normalform (1NF)
  2. Normalform (2NF)
  3. Normalform (3NF)

Boyce-Codd Normalform (BCNF)

  1. Normalform (4NF)
  2. Normalform (5NF)

Nel nostro articolo sulle basi della normalizzazione approfondiamo quali siano i requisiti per le forme normali elencate e come convertire un database da una forma normale a un’altra.

Le relazioni tra diverse tabelle di database vengono chiamate relationship nei modelli di database relazionale e sono ottenute utilizzando chiavi che collegano le tabelle tra di loro e sono la base per le query o per modificare i dati di diverse tabelle con la stessa istruzione.

La chiavi

Le tabelle del database, come la tabella dei collaboratori dell’esempio, consentono approcci diversi per recuperare singoli valori o interi record. L’attenzione si concentra sulle cosiddette chiavi: nel modello di database relazionale, una chiave è intesa come un insieme di attributi che sono adatti per identificare un record in modo univoco. Riguardo alla tabella di esempio sopra riportata, la seguente chiave consente l’identificazione univoca di una tupla:

{c_id, cognome, nome, cf}

Una chiave del genere con i valori

(c_id = '3', cognome = 'Padovan', nome = 'Gianluca', cf = 'PDVGLC55M21L424T') 

Sarebbe perciò idonea a identificare il record appartenente al dipendente Gianluca Padovan in modo incontrovertibile. A riguardo di questo tipo di chiavi si parla di superchiavi, anche se le superchiavi hanno nella pratica soltanto un significato limitato. Uno dei motivi è che le superchiavi spesso contengono più attributi di quelli che sarebbero necessari per l’identificazione. In altre parole: non sono per nulla minimali.

Nei database relazionali si lavora perciò con i più piccoli sottoinsiemi possibili (i cosiddetti candidati chiave) di una ipotetica superchiave. Una tabella può avere diversi candidati chiave con i quali i record si possono identificare in modo univoco.

Già l’esempio al paragrafo precedente ha mostrato che i record della tabella “collaboratori” si possono identificare in modo univoco e incontrovertibile semplicemente con l’ID del collaboratore. Un ulteriore candidato chiave nella tabella di esempio è il codice fiscale, essendo unico. Una chiave che si basa sul nome e/o il cognome, invece, non è un candidato idoneo, perché questi dati, anche in combinazione, possono non essere ascrivibili in modo preciso ad un solo candidato. Infatti in un’azienda possono lavorare più dipendenti con il nome Gianluca Padovan. Invece è escluso che due persone abbiano lo stesso codice fiscale o lo stesso ID collaboratore.

Per la tabella di esempio illustrata sopra si possono perciò stabilire i seguenti candidati chiave:

{c_id} 
{cf}

Le tabelle dei database relazionali sono solitamente strutturate in modo che uno dei possibili candidati chiave della serie di record specifichi l’ordine dei record. Questo candidato chiave è nominato chiave primaria (primary key). In pratica le chiavi primarie sono solitamente gli ID progressivi, come accade anche nella tabella dei collaboratori sopra.

Poiché le chiavi identificano in modo univoco i record nelle tabelle di database relazionali, sono perfettamente adatte a collegare tra loro diverse tabelle di un database. Per fare ciò si prende una chiave primaria di una tabella e la si usa come chiave esterna (foreign key) in un’altra tabella.

La seguente tabella contiene dati che un’azienda potrebbe registrare per la propria flotta. La chiave primaria della tabella “auto” è un ID progressivo.

ID auto Marca Modello Targa Anno di costruzione revisione
1 VW Caddy B KH 778 2016 43452
2 Opel Astra B PO 654 2010 43689
3 BMW X6 B MW 780 2017 43344

Per avere sott’occhio quale macchina sia usata da quale collaboratore, occorre collegare la tabella “auto” con quella “collaboratori”, ad esempio integrando la chiave primaria della tabella delle auto (ID auto) come chiave esterna della tabella dei collaboratori.

c_id Cognome Nome Cf Ind Nr CAP Luogo ID_auto
1 Bianchi Maria BNCMRA55F59F500S Via Roma 1 11111 Roma 3
2 Rossi Giada RSSGDI97G54B243L Via Matteotti 1 22222 Genova 1
3 Padovan Gianluca PDVGLC55M21L424T Via F.lli Cervi 1 33333 Gela 1
4 Terragna Elisabetta TRRLBT32R56C352Z Via Quasimodo 1 44444 Novara 2

Dalla tabella dei collaboratori ora si può stabilire che l’impiegata Bianchi sta utilizzando una vettura aziendale con il numero di identificazione 3, mentre Terragna viaggia con la numero 2; infine Rossi e Padovan condividono la numero 1.

Se si desidera capire quale dipendente deve far revisionare l’auto aziendale, occorre interrogare la tabella “collaboratore” insieme alla tabella “auto”, ma siccome entrambe le tabelle sono collegate attraverso una chiave esterna, si può fare con una sola query. Le operazioni del database che si estendono su più tabelle vengono implementate nel modello di database relazionale utilizzando un JOIN.

JOIN

Un JOIN (in italiano: interconnessione) è un’operazione di database che consente query su più tabelle di database contemporaneamente. I dati delle tabelle selezionate vengono riepilogati in un set di risultati e l’output viene filtrato in base alle condizioni definite dall’utente.

Le basi matematiche di SQL JOIN sono due operazioni dell’algebra relazionale: il prodotto cartesiano e la selezione. Sono gli utenti, attraverso la scelta del tipo di JOIN e utilizzando una condizione di selezione, a stabilire quali dati delle tabelle interrogate saranno inclusi nel set dei risultati.

Tra i tipi di JOIN più rilevanti rientrano:

  • INNER JOIN
  • OUTER JOIN
  • SELF JOIN

Indipendentemente da questo bisogna poi distinguere tra EQUI JOIN e NON EQUI JOIN.

Nel nostro articolo su SQL JOIN illustriamo come funzionano i JOIN SQL con le tabelle di database relazionali e a cosa bisogna prestare attenzione nella scelta del tipo di JOIN.

Differenziazione con altri modelli di database

Occorre distinguere i database relazionali basati su SQL dai concetti che rompono la rigida struttura della tabella e perseguono approcci alternativi alla strutturazione dei dati. I concetti più importanti di questo tipo includono database di oggetti e sistemi basati sui documenti.

Alla fine degli anni 80 i database degli oggetti venivano usati per creare un nuovo modello di database che riprendeva i concetti della programmazione orientata agli oggetti e abilitava la memorizzazione dei dati sotto forma di oggetti. Anche se questo approccio ha avuto poco successo fino ai giorni nostri, il concetto di orientamento agli oggetti è stato proficuamente incorporato nello sviluppo dei sistemi di database relazionali. Il risultato sono prodotti con estensioni relazionali che consentono l’archiviazione di tipi di dati astratti nel modello di database relazionale.

Con l’avvento del web 2.0 e i cambiamenti avvenuti nell’utilizzo di Internet, il modello di database relazionale è tornato al centro dell’attenzione: nell’ambito del movimento NoSQL (abbreviazione per not only SQL, che in italiano significa non solo SQL), sono stati sviluppati modelli alternativi come i database orientati ai documenti. Lo scopo di questo movimento era sviluppare potenti concetti di database per applicazioni ad alta intensità di dati.

I database degli oggetti si differenziano dai modelli di database relazionale e dai database orientati ai documenti soprattutto per il modo in cui i record vengono archiviati e per il modo in cui si accede ai dati archiviati.

Database orientati agli oggetti

Il modello di database orientato all’oggetto prevede l’archiviazione dei dati come oggetti. La modulazione degli oggetti rassomiglia alla programmazione orientata agli oggetti. Un oggetto definisce un’entità e contiene:

  • Le proprietà necessarie a descrivere l’entità (attributi)
  • Il rinvio ad altri oggetti (relazione)
  • Le funzioni che consentono l’accesso ai dati archiviati (metodi)

In questo modo un oggetto è una combinazione di dati; nei quali viene definita anche l’interfaccia tramite la quale si accede a questi dati. Gli oggetti sono contati tra i tipi di dati astratti.

Il sistema di gestione del database orientato agli oggetti (ODBMS) assegna un ID ad ogni oggetto, consentendo di identificare univocamente l’oggetto e di interrogarlo attraverso formule. Questo ID dell’oggetto è indipendente dallo stato, cioè non accoppiato ai valori dell’oggetto. In questo modo è possibile dare a due oggetti con gli stessi dati (cioè con lo stesso stato) due ID diversi. Il modello di database orientato agli oggetti è chiaramente diverso dal modello relazionale in cui ciascuna tupla può essere identificata dai suoi dati (ad esempio, da una chiave primaria).

Un’altra caratteristica del modello di database orientato agli oggetti è l’incapsulamento dei dati. È possibile accedere ai dati memorizzati solo tramite i metodi precedentemente definiti. I dati incapsulati nell’oggetto sono perciò protetti contro le modifiche tramite interfacce non definite.

Le strutture del database sono definite nel modello di database orientato agli oggetti tramite un sistema di classi gerarchico. Una classe nella programmazione orientata agli oggetti è un insieme di oggetti che hanno le stesse caratteristiche. Ogni classe di oggetti è basata su una definizione di classe. Questo schema specifica gli attributi e i metodi di tutti gli oggetti della classe e così determina in che modo vengono generati e modificati.

Gli utenti interagiscono con l’ODMBS con un linguaggio di query basato su SQL per i database degli oggetti: l’Object Query Language (OQL); il risultato di una query OQL non e un set di risultati come con SQL, ma un elenco di oggetti che soddisfano le condizioni dello statement OQL.

Implementazioni note del modello di database orientato agli oggetti sono Realm, ZODB e Perst.

I database orientati agli oggetti sono stati sviluppati come soluzione a un problema nello sviluppo di applicazioni indicato come object-relational impedence mismatch (in italiano si può tradurre come “incompatibilità oggetto relazione” che fondamentalmente implica l’incompatibilità tra un sistema di gestione del database relazionale e una o piò applicazioni scritte in un linguaggio di programmazione orientato all’oggetto).

Se gli oggetti scritti in un linguaggio di programmazione orientato all’oggetto (come ad esempio C#, C++ o Java) vengono salvati in un database relazionale, infatti, ciò porta immancabilmente a incompatibilità che affondano nelle diversità di base tra i due paradigmi di programmazione:

  • i database relazionali non supportano i concetti orientati all’oggetto, come classi ed ereditarietà;
  • nel modello di database relazionale non si può effettuare l’identificazione dell’oggetto indipendentemente dallo stato;
  • nel modello di database relazionale non è disponibile il meccanismo di protezione dell’incapsulamento dei dati.

Un approccio per evitare i menzionati problemi di incompatibilità è quello di evitare i database relazionali e di collocare la programmazione di applicazioni orientate agli oggetti su un database di oggetti; un approccio che ha però l’inevitabile svantaggio che i dati incapsulati negli oggetti non sono disponibili indipendentemente dall’applicazione associata. A ciò si aggiunge la bassa distribuzione dei database a oggetto: la maggior parte degli strumenti e delle interfacce per l’analisi di dati sono ancora basate su database relazionali e non supportano il modello orientato agli oggetti.

Gli sviluppatori di applicazioni che non vogliono rinunciare ai vantaggi dell’archiviazione dei dati relazionali hanno la possibilità di compensare le incompatibilità utilizzando il mapper relazionale a oggetti (O/R mapper). Le funzionalità per l’object-relational mapping (ORM, in italiano mappatura relazionale a oggetti) sono implementate tramite le librerie, che creano un livello un livello di astrazione tra l’applicazione orientata agli oggetti e i dati memorizzati nelle tabelle.

Molti produttori di sistemi di database relazionali forniscono i propri prodotti con funzionalità che compensano anche le incompatibilità di programmazione orientata agli oggetti. I sistemi di database di questo tipo sono chiamati “relazionali a oggetto”.

I database orientati all’oggetto trasferiscono i principi di base dell’orientamento agli oggetti alle tecnologie di database e sono quindi particolarmente adatti per la programmazione di applicazioni orientate agli oggetti. I sistemi di database corrispondenti, tuttavia, sono scarsi e in alcuni casi non ancora pronti per il mercato.

Database relazionali a oggetti

Un sistema di database relazionale orientato agli oggetti è un sistema di database relazionale ampliato con concetti propri dell’orientamento agli oggetti. I principi comprovati del modello di database relazionale verranno estesi a tipi di dati astratti come gli oggetti.

Per consentire la gestione di dati astratti, i database relazionali a oggetti ampliano il modello di database relazionale a:

  • tipi di dati complessi definiti dall’utente;
  • type constructors (nella teoria dei tipi, un “costruttore di tipi” è una caratteristica di un linguaggio formale tipizzato che costituisce nuovi tipi da quelli vecchi);
  • funzioni e metodi.

Mentre i database relazionali sono essenzialmente limitati a tipi di dati alfanumerici, con i tipi di dati definiti dall’utente si possono gestire anche file multimediali strutturati in modo complesso. I type constructor consentono di costituire nuovi tipi di dati a partire dai dati di base forniti. Poiché il linguaggio di database SQL non offre la possibilità di generare funzioni, i sistemi di database relazionali a oggetti devono fornire estensioni che definiscono le modalità di accesso e di elaborazione per tipi di dati complessi.

A partire dal nuovo millennio le estensioni relazionali a oggetti come i tipi strutturati sono state incluse nelle versioni più recenti dello standard SQL. Tuttavia, questi non sono supportati da tutti i DBMS. I sistemi di database noti che forniscono tali estensioni sono IBM Db2, Oracle Database e Microsoft SQL Server.

Database orientati ai documenti

Mentre l’archiviazione dei dati del database relazionale viene eseguita nelle tabelle del database, il modello di database incentrato sui documenti si basa su un database eterogeneo di singoli documenti. Questi possono essere documenti strutturati come file JSON, YAML o XML, ma anche file non strutturati come Binary Large Objects (BLOB), file immagine, video o audio.

Se sono disponibili documenti strutturati, i dati vengono memorizzati sotto forma di coppie chiave/valore e ad ogni chiave viene assegnato un valore specifico. Va specificato che in questo contesto il termine chiave è utilizzato come sinonimo di attributo e non ha niente a che fare con le chiavi nei sistemi di database relazionali. I valori possono riguardare qualsiasi informazione: anche gli elenchi e gli array con dati annidati sono valori possibili.

Di seguito vi mostriamo il possibile aspetto di un documento in formato JSON (JavaScript Object Notation) per l’archiviazione dei dati dei dipendenti:

Bianchi

Maria

BNCMRA55F59F500S

Via Roma

1

11111

Roma

3

{
  "id" : 1,
  "cognome" : "Bianchi",
  "nome" : "Maria",
  "cf" : "BNCMRA55F59F500S",
  "ind" : "via Roma 1",
  "cap" : "11111",
  "luogo" : "Roma",
  "id_auto" : [1, 4]
}

Diversi documenti possono essere raggruppati in raccolte di documenti (le cosiddette collection). Ad esempio, il documento del dipendente mostrato potrebbe essere insieme ad altre parti della collection “collaboratore”.

Le query vengono implementate utilizzando le funzioni, ad esempio tramite JavaScript. Anche i sistemi di gestione dei database che lavorano in modo orientato ai documenti assegnano ad ogni documento un ID univoco. A differenza del modello di database relazionale non esiste tuttavia uno schema di database che copra l’intero database: i documenti di un database basato su documenti non devono conformarsi a un modulo normale, né esistono determinate caratteristiche strutturali che devono essere applicate a tutti i documenti. In linea di principio ciascun documento può essere strutturato in modo diverso, anche se nel contesto dello sviluppo di applicazioni è consigliabile produrre documenti in uno schema appropriato al fine di creare i prerequisiti per le query mirate.

Con i database orientati ai documenti non si possono implementare relazioni come il collegamento di tabelle di database. Sebbene sia possibile inserire manualmente l’ID di un documento come riferimento in un altro documento, i sistemi di gestione dei database orientati al documento non offrono JOIN. Le opzioni di query corrispondenti devono perciò essere programmate autonomamente.

I sistemi di database orientati ai documenti sono particolarmente adatti per l’elaborazione di grandi quantità di dati con una struttura eterogenea e una bassa connettività di rete. Pertanto, questo modello di gestione dei dati ha senso soprattutto negli scenari che hanno a che fare con big data.

I sistemi di database relazionali garantiscono che le condizioni specificate nelle definizioni delle tabelle siano soddisfatte in ogni momento. Ciò porta ad una velocità di scrittura relativamente bassa durante l’elaborazione di grandi quantità di dati. I sistemi di database NoSQL non hanno requisiti di coerenza dei dati così rigidi e sono quindi adatti per architetture di grandi dimensioni in cui molte istanze di database vengono utilizzate in parallelo.

Anche le applicazioni web ricorrono sempre più a database orientati ai documenti. Tuttavia, se è richiesta una rete forte, l’archiviazione dei dati basata su documenti richiede più tempo. Gli utenti dovrebbero utilizzare in questi casi sistemi di database relazionali.

Esempi di database orientati ai documenti sono BaseX, CouchDB, eXist, MongoDB e RavenDB.

Vantaggi dei database relazionali

I database relazionali hanno buoni motivi per essersi affermati come lo standard nell’elaborazione elettronica dei dati:

  • Modello di dati semplice: i database relazionali si basano su un modello di dati relativamente semplice da implementare e gestire. Grazie ai modelli di database relazionale risulta facile mappare le numerose informazioni, come i dati dei clienti, le liste di ordini o le movimentazioni dei conti, che le aziende archiviano nel lungo periodo.
     
  • Ridotta ridondanza dei dati: il modello di database relazionale utilizza i vari moduli normali per fornire regole ben definite per l’eliminazione della ridondanza. Se i requisiti per la normalizzazione vengono implementati in modo coerente, i sistemi di database relazionali consentono una memorizzazione dei dati quasi priva di ridondanze. Questo facilita soprattutto il mantenimento e la cura delle scorte di dati, poiché le modifiche devono essere effettuate in un unico luogo.
     
  • Elevata coerenza dei dati: i database relazionali normalizzati consentono un’archiviazione dei dati senza contraddizioni, contribuendo alla coerenza dei dati. I sistemi di database relazionali forniscono anche funzionalità che definiscono e verificano automaticamente i vincoli di integrità. Le transazioni che mettono a repentaglio la coerenza dei dati vengono escluse.
     
  • Elaborazione dei dati orientata alla quantità: il sistema di database relazionale si basa sull’elaborazione dei dati orientata alla quantità, in cui ogni entità è suddivisa in valori atomici. Ciò consente il collegamento di varie entità attraverso il contenuto, nonché query di database complesse come JOIN.
     
  • Lingua unificata per le query: per le query sui database relazionali è stato stabilito un SQL standardizzato per la lingua del database attraverso gli organi di ISO e IEC; il fine di questa standardizzazione è di consentire lo sviluppo e l’esecuzione delle applicazioni indipendentemente dal sistema di gestione del database soggiacente. Tuttavia fino ad ora il supporto di SQL varia a seconda del DBMS.

Svantaggi dei database relazionali

A seconda dello scenario in cui vengono utilizzati i sistemi di database relazionali, alcuni dei vantaggi menzionati quali la semplicità del modello di dati basato su tabelle e la distribuzione dei dati tra più tabelle collegate possono rivelarsi svantaggi. Inoltre le caratteristiche chiave del modello di dati relazionali sono difficili da conciliare con i moderni requisiti di programmazione delle applicazioni (come orientamento degli oggetti, multimedia e big data).

  • Mappatura tabellare dei dati: non tutti i tipi di dati possono essere espressi in uno schema rigido di tabelle bidimensionali interconnessi (Impedance Mismatch). I tipi di dati astratti e i dati non strutturatiassociati alle applicazioni multimediali e alle soluzioni big data non possono essere mappati nel modello di database relazionale.
     
  • Mancanza di uno schema di database gerarchico: i database relazionali, a differenza dei database di oggetti, non offrono la possibilità di implementare schemi di database con classi strutturate gerarchicamente. Concetti come quelli delle “entità figlio” che ereditano le proprietà dalle “entità padre” non possono essere utilizzati. Ad esempio non è possibile utilizzarli per creare sottotuple. Tutte le tuple di un database relazionale si trovano sullo stesso piano gerarchico.
     
  • Segmentazione dei dati: il principio di base dei sistemi di database relazionali, che consiste nella suddivisione delle informazioni su tabelle separate (normalizzazione), porta necessariamente ad una segmentazione dei dati: i dati correlati non sono necessariamente memorizzati insieme. Questo design del database genera query complesse su più tabelle a livello di applicazione. Il conseguente maggior numero di segmenti interrogati di solito ha anche un impatto negativo sulle prestazioni.
     
  • Performance peggiori rispetto ai database NoSQL: il modello di database relazionale ha requisiti molto rigidi in termini di coerenza dei dati che nelle transazioni vanno a discapito della velocità di scrittura.

Conclusioni

Il modello di database relazionale è chiaro, matematicamente valido e ha alle spalle più di 40 anni di utilizzo pratico. Eppure l’archiviazione dei dati in tabelle strutturate non soddisfa tutti i requisiti della moderna tecnologia informatica.

I limiti dei classici sistemi relazionali sono messi in evidenza soprattutto dall’amministrazione di grandi quantità di dati nel contesto dell’analisi di big data e dall’archiviazione di tipi di dati astratti, dove si distinguono invece sistemi specializzati come i database a oggetto o i concetti sviluppati nell’ambito del movimento NoSQL. Tuttavia non è possibile lasciarsi completamente alle spalle il modello di database relazionale, che tuttora offre molti vantaggi, specialmente negli ambiti in cui l’elaborazione dei dati delle transazioni è di primaria importanza.

I dati sulle azioni dei clienti o sulle misure di marketing si possono idealmente rappresentare nei sistemi tabulari. Inoltre gli utenti beneficiano di una sintassi che, nonostante la propria semplicità, consente query complesse.


Un momento! Prima di lasciarci scopri
la nostra offerta per il rientro dalle ferie:
dominio .it a 1 € per il primo anno!

Primo anno a 1 € IVA escl.,
poi 10 €/anno IVA escl.

Inserisci il dominio desiderato nella barra di ricerca per verificarne la disponibilità.