Il modello di database re­la­zio­na­le

Come è noto, i database sono com­po­nen­ti fon­da­men­ta­li di qualsiasi sistema in­for­ma­ti­co. Infatti ogni programma utilizza dati o genera in­for­ma­zio­ni che devono essere me­mo­riz­za­te in modo af­fi­da­bi­le e per­ma­nen­te. Ciò viene fatto in database strut­tu­ra­ti (DB) che sono gestiti dai co­sid­det­ti database ma­na­ge­ment system (DBMS), ovvero sistemi di gestione del database, ap­pli­ca­zio­ni software che in­te­ra­gi­sco­no con gli utenti finali o altri programmi e for­ni­sco­no loro un sot­toin­sie­me di dati me­mo­riz­za­ti nel database.

Ad oggi la gestione elet­tro­ni­ca dei dati è dominata dai modelli di database re­la­zio­na­le. Questo è un elenco in ordine al­fa­be­ti­co dei sistemi di gestione di database re­la­zio­na­li (RDBMS) più uti­liz­za­ti:

• Db2: Db2 è un sistema re­la­zio­na­le di gestione del database pro­prie­ta­rio di casa IBM, a di­spo­si­zio­ne dell’utente con licenza com­mer­cia­le.
   
• Microsoft SQL Server: questo sistema di gestione del database di Microsoft è di­spo­ni­bi­le con licenza a pagamento Microsoft per l’utente finale.
   
• MySQL: MySQL è uno degli RDBMS open source più uti­liz­za­ti del mondo. Da quando è stato acquisito da Oracle, MySQL è sul mercato con un doppio sistema di licenze: la comunità di svi­lup­pa­to­ri originale continua il progetto con il nome MariaDB.
   
• Post­gre­SQL: con Post­gre­SQL gli utenti hanno a di­spo­si­zio­ne un sistema di gestione di database re­la­zio­na­le a oggetti (ORDBMS) gratuito. La community open source si occupa anche di pro­se­guir­ne lo sviluppo.
   
• Oracle Database: il sistema di database re­la­zio­na­le dell’omonima azienda Oracle è com­mer­cia­liz­za­to come software pro­prie­ta­rio a pagamento.
   
• SQLite: SQLite è una libreria di dominio pubblico con­te­nen­te un sistema di gestione del database re­la­zio­na­le.

Tutti i sistemi nominati si basano su un’or­ga­niz­za­zio­ne tabulare di in­for­ma­zio­ne. Ma cosa significa? Vi pre­sen­tia­mo alcuni principi di base della pro­get­ta­zio­ne dei database re­la­zio­na­li, in­tro­du­cia­mo i database re­la­zio­na­li con esempi e vi spie­ghia­mo le dif­fe­ren­ze che in­ter­cor­ro­no con altri modelli.

Come è pre­ve­di­bi­le, il termine centrale nei modelli di database re­la­zio­na­li è quello di relazione. Un concetto che risale al ma­te­ma­ti­co e teorico dei database bri­tan­ni­co Edgar F. Codd. Secondo Codd una relazione rap­pre­sen­ta un insieme di entità con le stesse proprietà: ogni relazione consiste in una serie di dati (le co­sid­det­te tuple), i cui valori sono associati a de­ter­mi­na­ti attributi.

Si definisce quali siano gli attributi compresi da una relazione e quali tipi di dati cor­ri­spon­da­no ai valori assegnati agli attributi uti­liz­zan­do uno schema di relazione secondo la seguente sintassi:

R = (A₁ : Tipo₁, A₂ : Tipo₂ , … , A_n : Tipo_n)

Lo schema di relazione (R) comprende gli attributi da A₁ a A_n. A ciascun attributo è assegnato un tipo di dato (Tipo_1, Tipo₂ ecc.). Questo schema di relazione può essere il­lu­stra­to da un esempio concreto.

Lo schema seguente specifica gli attributi della relazione “col­la­bo­ra­to­re”:

Questo schema di esempio tocca gli attributi ID del col­la­bo­ra­to­re (c_id), cognome, nome, codice fiscale (cf), indirizzo (ind), codice di av­via­men­to 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 con­ce­pi­sco­no 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:

La tabella di esempio serve all’ar­chi­via­zio­ne dei dati personali e consta di quattro record. Ognuno di essi contiene in­for­ma­zio­ni su un col­la­bo­ra­to­re preciso.

Il database di un sistema di database re­la­zio­na­le co­sti­tui­sce la base di dati tabulare strut­tu­ra­ta. La sua struttura di dati viene definita dal sistema di gestione del database, che è anche re­spon­sa­bi­le della gestione degli accessi in lettura e scrittura. Gli utenti in­te­ra­gi­sco­no con il sistema di gestione del database uti­liz­zan­do un lin­guag­gio di database. Ogni sistema di gestione di database re­la­zio­na­li supporta almeno un lin­guag­gio formale che può essere uti­liz­za­to per eseguire le seguenti ope­ra­zio­ni di database:

• Definire la struttura di dati: nell’ambito della de­fi­ni­zio­ne dei dati viene ar­chi­via­ta una de­scri­zio­ne della struttura dei dati at­tra­ver­so i metadati nel data dic­tio­na­ry del sistema di database. Se ad esempio un utente crea una nuova tabella, viene ar­chi­via­to uno schema di relazione cor­ri­spon­den­te nel di­zio­na­rio dei dati. Il vo­ca­bo­la­rio di un lin­guag­gio di database uti­liz­za­to per la de­fi­ni­zio­ne dei dati, viene chiamato Data De­fi­ni­tion Language (DDL).
   
• Definire le au­to­riz­za­zio­ni: ogni lin­guag­gio del database fornisce una sintassi che consente di concedere o revocare le au­to­riz­za­zio­ni. In questo caso si parla di Data Control Language (DCL), una parte del vo­ca­bo­la­rio del lin­guag­gio 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 sod­di­sfat­ti in ogni momento e per questo si parla di “stato coerente”. Ad esempio un vincolo di base di integrità nei sistemi di database re­la­zio­na­li è che ogni record (tupla) può essere iden­ti­fi­ca­to in modo univoco.
   
• Definire le tran­sa­zio­ni: quando un database viene spostato da uno stato con­si­sten­te ad un altro, si parla di tran­sa­zio­ne. Le tran­sa­zio­ni con­ten­go­no una serie di istru­zio­ni e devono essere sempre portate a termine, perché se una tran­sa­zio­ne viene in­ter­rot­ta, il database viene ri­pri­sti­na­to nello stato iniziale (rollback). Ogni tran­sa­zio­ne inizia con l’in­di­ca­zio­ne di con­net­ter­si al database. A questo seguono comandi che avviano l’effettiva ope­ra­zio­ne nonché un commit che ga­ran­ti­sce l’integrità del database. Le ope­ra­zio­ni pe­ri­co­lo­se per l’integrità non vengono eseguite (scritte per­ma­nen­te­men­te nel database). Infine viene chiusa la con­nes­sio­ne al database. Il vo­ca­bo­la­rio del lin­guag­gio di database che soggiace alla ma­ni­po­la­zio­ne dei dati viene chiamato Data Ma­ni­pu­la­tion Language (DML).
   
• Definire le view: una view è una vista virtuale dei dati se­le­zio­na­ti. 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 ope­ra­zio­ni del database come se si trattasse di una tabella fisica. Esistono diversi tipi di vi­sua­liz­za­zio­ne dei dati a seconda della funzione, le più comuni sono le view che filtrano de­ter­mi­na­te righe (vista selezione) o colonne (vista pro­ie­zio­ne) da una tabella se­le­zio­na­ta, nonché view che collegano insieme tabelle diverse (vista composita).

Nor­mal­men­te l’in­ter­fac­cia standard per le ope­ra­zio­ni di database il­lu­stra­te sopra nei modelli di database re­la­zio­na­li è quella basata su SQL (Struc­tu­red Query Language), un lin­guag­gio di database basato sull’algebra re­la­zio­na­le.

Le ope­ra­zio­ni del database come le query, la creazione, l’ag­gior­na­men­to o l’eli­mi­na­zio­ne di dati vengono eseguite uti­liz­zan­do le co­sid­det­te SQL sta­te­men­ts, una com­bi­na­zio­ne di comandi SQL se­le­zio­na­ti. Essi sono basati se­man­ti­ca­men­te sulla lingua inglese e sono perciò di ovvio si­gni­fi­ca­to. La seguente tabella contiene i termini chiave del modello di dati re­la­zio­na­li e il loro equi­va­len­te nella ter­mi­no­lo­gia SQL.

Una semplice query di dati scelti si può im­ple­men­ta­re per esempio con SQL secondo il seguente schema:

Ini­zial­men­te usiamo il comando SELECT, per assegnare all’RDBMS la richiesta dei dati. In seguito definiamo quali dati vogliamo ri­chie­de­re, inserendo la tabella e la colonna de­si­de­ra­ta. Inoltre uti­liz­zia­mo “WHERE” per inserire un vincolo nello statement SQL. Non vogliamo ri­chia­ma­re tutto l’insieme di valori degli attributi contenuti nella colonna, ma soltanto il valore di un par­ti­co­la­re record. Con ri­fe­ri­men­to alla nostra tabella di esempio “col­la­bo­ra­to­ri” un simile SQL statement può apparire come segue:

Lo statement SQL chiede al RDBMS di ri­chia­ma­re dalla tabella “col­la­bo­ra­to­ri” un valore dalla colonna cf. Come vincolo abbiamo definito che il valore debba essere estra­po­la­to 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 col­la­bo­ra­to­re con l’ID numero 3.

Una chiave del genere con i valori

Sarebbe perciò idonea a iden­ti­fi­ca­re il record ap­par­te­nen­te al di­pen­den­te Gianluca Padovan in modo in­con­tro­ver­ti­bi­le. A riguardo di questo tipo di chiavi si parla di su­per­chia­vi, anche se le su­per­chia­vi hanno nella pratica soltanto un si­gni­fi­ca­to limitato. Uno dei motivi è che le su­per­chia­vi spesso con­ten­go­no più attributi di quelli che sarebbero necessari per l’iden­ti­fi­ca­zio­ne. In altre parole: non sono per nulla minimali.

Nei database re­la­zio­na­li si lavora perciò con i più piccoli sot­toin­sie­mi possibili (i co­sid­det­ti candidati chiave) di una ipotetica su­per­chia­ve. Una tabella può avere diversi candidati chiave con i quali i record si possono iden­ti­fi­ca­re in modo univoco.

Già l’esempio al paragrafo pre­ce­den­te ha mostrato che i record della tabella “col­la­bo­ra­to­ri” si possono iden­ti­fi­ca­re in modo univoco e in­con­tro­ver­ti­bi­le sem­pli­ce­men­te con l’ID del col­la­bo­ra­to­re. 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 com­bi­na­zio­ne, possono non essere ascri­vi­bi­li in modo preciso ad un solo candidato. Infatti in un’azienda possono lavorare più di­pen­den­ti con il nome Gianluca Padovan. Invece è escluso che due persone abbiano lo stesso codice fiscale o lo stesso ID col­la­bo­ra­to­re.

Per la tabella di esempio il­lu­stra­ta sopra si possono perciò stabilire i seguenti candidati chiave:

Le tabelle dei database re­la­zio­na­li sono so­li­ta­men­te strut­tu­ra­te in modo che uno dei possibili candidati chiave della serie di record spe­ci­fi­chi l’ordine dei record. Questo candidato chiave è nominato chiave primaria (primary key). In pratica le chiavi primarie sono so­li­ta­men­te gli ID pro­gres­si­vi, come accade anche nella tabella dei col­la­bo­ra­to­ri sopra.

Poiché le chiavi iden­ti­fi­ca­no in modo univoco i record nelle tabelle di database re­la­zio­na­li, sono per­fet­ta­men­te 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 re­gi­stra­re per la propria flotta. La chiave primaria della tabella “auto” è un ID pro­gres­si­vo.

Per avere sott’occhio quale macchina sia usata da quale col­la­bo­ra­to­re, occorre collegare la tabella “auto” con quella “col­la­bo­ra­to­ri”, ad esempio in­te­gran­do la chiave primaria della tabella delle auto (ID auto) come chiave esterna della tabella dei col­la­bo­ra­to­ri.

Dalla tabella dei col­la­bo­ra­to­ri ora si può stabilire che l’impiegata Bianchi sta uti­liz­zan­do una vettura aziendale con il numero di iden­ti­fi­ca­zio­ne 3, mentre Terragna viaggia con la numero 2; infine Rossi e Padovan con­di­vi­do­no la numero 1.

Se si desidera capire quale di­pen­den­te deve far re­vi­sio­na­re l’auto aziendale, occorre in­ter­ro­ga­re la tabella “col­la­bo­ra­to­re” insieme alla tabella “auto”, ma siccome entrambe le tabelle sono collegate at­tra­ver­so una chiave esterna, si può fare con una sola query. Le ope­ra­zio­ni del database che si estendono su più tabelle vengono im­ple­men­ta­te nel modello di database re­la­zio­na­le uti­liz­zan­do un JOIN.

Un JOIN (in italiano: in­ter­con­nes­sio­ne) è un’ope­ra­zio­ne di database che consente query su più tabelle di database con­tem­po­ra­nea­men­te. I dati delle tabelle se­le­zio­na­te vengono rie­pi­lo­ga­ti in un set di risultati e l’output viene filtrato in base alle con­di­zio­ni definite dall’utente.

Le basi ma­te­ma­ti­che di SQL JOIN sono due ope­ra­zio­ni dell’algebra re­la­zio­na­le: il prodotto car­te­sia­no e la selezione. Sono gli utenti, at­tra­ver­so la scelta del tipo di JOIN e uti­liz­zan­do una con­di­zio­ne di selezione, a stabilire quali dati delle tabelle in­ter­ro­ga­te saranno inclusi nel set dei risultati.

Tra i tipi di JOIN più rilevanti rientrano:

• INNER JOIN
• OUTER JOIN
• SELF JOIN

In­di­pen­den­te­men­te da questo bisogna poi di­stin­gue­re tra EQUI JOIN e NON EQUI JOIN.

Nel nostro articolo su SQL JOIN il­lu­stria­mo come fun­zio­na­no i JOIN SQL con le tabelle di database re­la­zio­na­li e a cosa bisogna prestare at­ten­zio­ne nella scelta del tipo di JOIN.

Occorre di­stin­gue­re i database re­la­zio­na­li basati su SQL dai concetti che rompono la rigida struttura della tabella e per­se­guo­no approcci al­ter­na­ti­vi alla strut­tu­ra­zio­ne dei dati. I concetti più im­por­tan­ti 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 ri­pren­de­va i concetti della pro­gram­ma­zio­ne orientata agli oggetti e abilitava la me­mo­riz­za­zio­ne dei dati sotto forma di oggetti. Anche se questo approccio ha avuto poco successo fino ai giorni nostri, il concetto di orien­ta­men­to agli oggetti è stato pro­fi­cua­men­te in­cor­po­ra­to nello sviluppo dei sistemi di database re­la­zio­na­li. Il risultato sono prodotti con esten­sio­ni re­la­zio­na­li che con­sen­to­no l’ar­chi­via­zio­ne di tipi di dati astratti nel modello di database re­la­zio­na­le.

Con l’avvento del web 2.0 e i cam­bia­men­ti avvenuti nell’utilizzo di Internet, il modello di database re­la­zio­na­le è tornato al centro dell’at­ten­zio­ne: nell’ambito del movimento NoSQL (ab­bre­via­zio­ne per not only SQL, che in italiano significa non solo SQL), sono stati svi­lup­pa­ti modelli al­ter­na­ti­vi come i database orientati ai documenti. Lo scopo di questo movimento era svi­lup­pa­re potenti concetti di database per ap­pli­ca­zio­ni ad alta intensità di dati.

I database degli oggetti si dif­fe­ren­zia­no dai modelli di database re­la­zio­na­le e dai database orientati ai documenti so­prat­tut­to per il modo in cui i record vengono ar­chi­via­ti e per il modo in cui si accede ai dati ar­chi­via­ti.

Il modello di database orientato all’oggetto prevede l’ar­chi­via­zio­ne dei dati come oggetti. La mo­du­la­zio­ne degli oggetti ras­so­mi­glia alla pro­gram­ma­zio­ne orientata agli oggetti. Un oggetto definisce un’entità e contiene:

• Le proprietà ne­ces­sa­rie a de­scri­ve­re l’entità (attributi)
• Il rinvio ad altri oggetti (relazione)
• Le funzioni che con­sen­to­no l’accesso ai dati ar­chi­via­ti (metodi)

In questo modo un oggetto è una com­bi­na­zio­ne di dati; nei quali viene definita anche l’in­ter­fac­cia 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, con­sen­ten­do di iden­ti­fi­ca­re uni­vo­ca­men­te l’oggetto e di in­ter­ro­gar­lo at­tra­ver­so formule. Questo ID dell’oggetto è in­di­pen­den­te dallo stato, cioè non ac­cop­pia­to 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 è chia­ra­men­te diverso dal modello re­la­zio­na­le in cui ciascuna tupla può essere iden­ti­fi­ca­ta dai suoi dati (ad esempio, da una chiave primaria).

Un’altra ca­rat­te­ri­sti­ca del modello di database orientato agli oggetti è l’in­cap­su­la­men­to dei dati. È possibile accedere ai dati me­mo­riz­za­ti solo tramite i metodi pre­ce­den­te­men­te definiti. I dati in­cap­su­la­ti nell’oggetto sono perciò protetti contro le modifiche tramite in­ter­fac­ce non definite.

Le strutture del database sono definite nel modello di database orientato agli oggetti tramite un sistema di classi ge­rar­chi­co. Una classe nella pro­gram­ma­zio­ne orientata agli oggetti è un insieme di oggetti che hanno le stesse ca­rat­te­ri­sti­che. Ogni classe di oggetti è basata su una de­fi­ni­zio­ne 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 mo­di­fi­ca­ti.

Gli utenti in­te­ra­gi­sco­no con l’ODMBS con un lin­guag­gio 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 sod­di­sfa­no le con­di­zio­ni dello statement OQL.

Im­ple­men­ta­zio­ni note del modello di database orientato agli oggetti sono Realm, ZODB e Perst.

I database orientati agli oggetti sono stati svi­lup­pa­ti come soluzione a un problema nello sviluppo di ap­pli­ca­zio­ni indicato come object-re­la­tio­nal impedence mismatch (in italiano si può tradurre come “in­com­pa­ti­bi­li­tà oggetto relazione” che fon­da­men­tal­men­te implica l’in­com­pa­ti­bi­li­tà tra un sistema di gestione del database re­la­zio­na­le e una o piò ap­pli­ca­zio­ni scritte in un lin­guag­gio di pro­gram­ma­zio­ne orientato all’oggetto).

Se gli oggetti scritti in un lin­guag­gio di pro­gram­ma­zio­ne orientato all’oggetto (come ad esempio C#, C++ o Java) vengono salvati in un database re­la­zio­na­le, infatti, ciò porta im­man­ca­bil­men­te a in­com­pa­ti­bi­li­tà che affondano nelle diversità di base tra i due paradigmi di pro­gram­ma­zio­ne:

• i database re­la­zio­na­li non sup­por­ta­no i concetti orientati all’oggetto, come classi ed ere­di­ta­rie­tà;
• nel modello di database re­la­zio­na­le non si può ef­fet­tua­re l’iden­ti­fi­ca­zio­ne dell’oggetto in­di­pen­den­te­men­te dallo stato;
• nel modello di database re­la­zio­na­le non è di­spo­ni­bi­le il mec­ca­ni­smo di pro­te­zio­ne dell’in­cap­su­la­men­to dei dati.

Un approccio per evitare i men­zio­na­ti problemi di in­com­pa­ti­bi­li­tà è quello di evitare i database re­la­zio­na­li e di collocare la pro­gram­ma­zio­ne di ap­pli­ca­zio­ni orientate agli oggetti su un database di oggetti; un approccio che ha però l’ine­vi­ta­bi­le svan­tag­gio che i dati in­cap­su­la­ti negli oggetti non sono di­spo­ni­bi­li in­di­pen­den­te­men­te dall’ap­pli­ca­zio­ne associata. A ciò si aggiunge la bassa di­stri­bu­zio­ne dei database a oggetto: la maggior parte degli strumenti e delle in­ter­fac­ce per l’analisi di dati sono ancora basate su database re­la­zio­na­li e non sup­por­ta­no il modello orientato agli oggetti.

Gli svi­lup­pa­to­ri di ap­pli­ca­zio­ni che non vogliono ri­nun­cia­re ai vantaggi dell’ar­chi­via­zio­ne dei dati re­la­zio­na­li hanno la pos­si­bi­li­tà di com­pen­sa­re le in­com­pa­ti­bi­li­tà uti­liz­zan­do il mapper re­la­zio­na­le a oggetti (O/R mapper). Le fun­zio­na­li­tà per l’object-re­la­tio­nal mapping (ORM, in italiano mappatura re­la­zio­na­le a oggetti) sono im­ple­men­ta­te tramite le librerie, che creano un livello un livello di astra­zio­ne tra l’ap­pli­ca­zio­ne orientata agli oggetti e i dati me­mo­riz­za­ti nelle tabelle.

Molti pro­dut­to­ri di sistemi di database re­la­zio­na­li for­ni­sco­no i propri prodotti con fun­zio­na­li­tà che com­pen­sa­no anche le in­com­pa­ti­bi­li­tà di pro­gram­ma­zio­ne orientata agli oggetti. I sistemi di database di questo tipo sono chiamati “re­la­zio­na­li a oggetto”.

I database orientati all’oggetto tra­sfe­ri­sco­no i principi di base dell’orien­ta­men­to agli oggetti alle tec­no­lo­gie di database e sono quindi par­ti­co­lar­men­te adatti per la pro­gram­ma­zio­ne di ap­pli­ca­zio­ni orientate agli oggetti. I sistemi di database cor­ri­spon­den­ti, tuttavia, sono scarsi e in alcuni casi non ancora pronti per il mercato.

Un sistema di database re­la­zio­na­le orientato agli oggetti è un sistema di database re­la­zio­na­le ampliato con concetti propri dell’orien­ta­men­to agli oggetti. I principi com­pro­va­ti del modello di database re­la­zio­na­le verranno estesi a tipi di dati astratti come gli oggetti.

Per con­sen­ti­re la gestione di dati astratti, i database re­la­zio­na­li a oggetti ampliano il modello di database re­la­zio­na­le a:

• tipi di dati complessi definiti dall’utente;
• type con­struc­tors (nella teoria dei tipi, un “co­strut­to­re di tipi” è una ca­rat­te­ri­sti­ca di un lin­guag­gio formale tipizzato che co­sti­tui­sce nuovi tipi da quelli vecchi);
• funzioni e metodi.

Mentre i database re­la­zio­na­li sono es­sen­zial­men­te limitati a tipi di dati al­fa­nu­me­ri­ci, con i tipi di dati definiti dall’utente si possono gestire anche file mul­ti­me­dia­li strut­tu­ra­ti in modo complesso. I type con­struc­tor con­sen­to­no di co­sti­tui­re nuovi tipi di dati a partire dai dati di base forniti. Poiché il lin­guag­gio di database SQL non offre la pos­si­bi­li­tà di generare funzioni, i sistemi di database re­la­zio­na­li a oggetti devono fornire esten­sio­ni che de­fi­ni­sco­no le modalità di accesso e di ela­bo­ra­zio­ne per tipi di dati complessi.

A partire dal nuovo millennio le esten­sio­ni re­la­zio­na­li a oggetti come i tipi strut­tu­ra­ti sono state incluse nelle versioni più recenti dello standard SQL. Tuttavia, questi non sono sup­por­ta­ti da tutti i DBMS. I sistemi di database noti che for­ni­sco­no tali esten­sio­ni sono IBM Db2, Oracle Database e Microsoft SQL Server.

Mentre l’ar­chi­via­zio­ne dei dati del database re­la­zio­na­le viene eseguita nelle tabelle del database, il modello di database in­cen­tra­to sui documenti si basa su un database ete­ro­ge­neo di singoli documenti. Questi possono essere documenti strut­tu­ra­ti come file JSON, YAML o XML, ma anche file non strut­tu­ra­ti come Binary Large Objects (BLOB), file immagine, video o audio.

Se sono di­spo­ni­bi­li documenti strut­tu­ra­ti, i dati vengono me­mo­riz­za­ti sotto forma di coppie chiave/valore e ad ogni chiave viene assegnato un valore specifico. Va spe­ci­fi­ca­to che in questo contesto il termine chiave è uti­liz­za­to come sinonimo di attributo e non ha niente a che fare con le chiavi nei sistemi di database re­la­zio­na­li. I valori possono ri­guar­da­re qualsiasi in­for­ma­zio­ne: 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 (Ja­va­Script Object Notation) per l’ar­chi­via­zio­ne dei dati dei di­pen­den­ti:

Diversi documenti possono essere rag­grup­pa­ti in raccolte di documenti (le co­sid­det­te col­lec­tion). Ad esempio, il documento del di­pen­den­te mostrato potrebbe essere insieme ad altre parti della col­lec­tion “col­la­bo­ra­to­re”.

Le query vengono im­ple­men­ta­te uti­liz­zan­do le funzioni, ad esempio tramite Ja­va­Script. Anche i sistemi di gestione dei database che lavorano in modo orientato ai documenti assegnano ad ogni documento un ID univoco. A dif­fe­ren­za del modello di database re­la­zio­na­le non esiste tuttavia uno schema di database che copra l’intero database: i documenti di un database basato su documenti non devono con­for­mar­si a un modulo normale, né esistono de­ter­mi­na­te ca­rat­te­ri­sti­che strut­tu­ra­li che devono essere applicate a tutti i documenti. In linea di principio ciascun documento può essere strut­tu­ra­to in modo diverso, anche se nel contesto dello sviluppo di ap­pli­ca­zio­ni è con­si­glia­bi­le produrre documenti in uno schema ap­pro­pria­to al fine di creare i pre­re­qui­si­ti per le query mirate.

Con i database orientati ai documenti non si possono im­ple­men­ta­re relazioni come il col­le­ga­men­to di tabelle di database. Sebbene sia possibile inserire ma­nual­men­te l’ID di un documento come ri­fe­ri­men­to in un altro documento, i sistemi di gestione dei database orientati al documento non offrono JOIN. Le opzioni di query cor­ri­spon­den­ti devono perciò essere pro­gram­ma­te au­to­no­ma­men­te.

I sistemi di database orientati ai documenti sono par­ti­co­lar­men­te adatti per l’ela­bo­ra­zio­ne di grandi quantità di dati con una struttura ete­ro­ge­nea e una bassa con­net­ti­vi­tà di rete. Pertanto, questo modello di gestione dei dati ha senso so­prat­tut­to negli scenari che hanno a che fare con big data.

I sistemi di database re­la­zio­na­li ga­ran­ti­sco­no che le con­di­zio­ni spe­ci­fi­ca­te nelle de­fi­ni­zio­ni delle tabelle siano sod­di­sfat­te in ogni momento. Ciò porta ad una velocità di scrittura re­la­ti­va­men­te bassa durante l’ela­bo­ra­zio­ne di grandi quantità di dati. I sistemi di database NoSQL non hanno requisiti di coerenza dei dati così rigidi e sono quindi adatti per ar­chi­tet­tu­re di grandi di­men­sio­ni in cui molte istanze di database vengono uti­liz­za­te in parallelo.

Anche le ap­pli­ca­zio­ni web ricorrono sempre più a database orientati ai documenti. Tuttavia, se è richiesta una rete forte, l’ar­chi­via­zio­ne dei dati basata su documenti richiede più tempo. Gli utenti do­vreb­be­ro uti­liz­za­re in questi casi sistemi di database re­la­zio­na­li.

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

I database re­la­zio­na­li hanno buoni motivi per essersi affermati come lo standard nell’ela­bo­ra­zio­ne elet­tro­ni­ca dei dati:

• Modello di dati semplice: i database re­la­zio­na­li si basano su un modello di dati re­la­ti­va­men­te semplice da im­ple­men­ta­re e gestire. Grazie ai modelli di database re­la­zio­na­le risulta facile mappare le numerose in­for­ma­zio­ni, come i dati dei clienti, le liste di ordini o le mo­vi­men­ta­zio­ni dei conti, che le aziende ar­chi­via­no nel lungo periodo.
   
• Ridotta ri­don­dan­za dei dati: il modello di database re­la­zio­na­le utilizza i vari moduli normali per fornire regole ben definite per l’eli­mi­na­zio­ne della ri­don­dan­za. Se i requisiti per la nor­ma­liz­za­zio­ne vengono im­ple­men­ta­ti in modo coerente, i sistemi di database re­la­zio­na­li con­sen­to­no una me­mo­riz­za­zio­ne dei dati quasi priva di ri­don­dan­ze. Questo facilita so­prat­tut­to il man­te­ni­men­to e la cura delle scorte di dati, poiché le modifiche devono essere ef­fet­tua­te in un unico luogo.
   
• Elevata coerenza dei dati: i database re­la­zio­na­li nor­ma­liz­za­ti con­sen­to­no un’ar­chi­via­zio­ne dei dati senza con­trad­di­zio­ni, con­tri­buen­do alla coerenza dei dati. I sistemi di database re­la­zio­na­li for­ni­sco­no anche fun­zio­na­li­tà che de­fi­ni­sco­no e ve­ri­fi­ca­no au­to­ma­ti­ca­men­te i vincoli di integrità. Le tran­sa­zio­ni che mettono a re­pen­ta­glio la coerenza dei dati vengono escluse.
   
• Ela­bo­ra­zio­ne dei dati orientata alla quantità: il sistema di database re­la­zio­na­le si basa sull’ela­bo­ra­zio­ne dei dati orientata alla quantità, in cui ogni entità è suddivisa in valori atomici. Ciò consente il col­le­ga­men­to di varie entità at­tra­ver­so il contenuto, nonché query di database complesse come JOIN.
   
• Lingua unificata per le query: per le query sui database re­la­zio­na­li è stato stabilito un SQL stan­dar­diz­za­to per la lingua del database at­tra­ver­so gli organi di ISO e IEC; il fine di questa stan­dar­diz­za­zio­ne è di con­sen­ti­re lo sviluppo e l’ese­cu­zio­ne delle ap­pli­ca­zio­ni in­di­pen­den­te­men­te dal sistema di gestione del database sog­gia­cen­te. Tuttavia fino ad ora il supporto di SQL varia a seconda del DBMS.

A seconda dello scenario in cui vengono uti­liz­za­ti i sistemi di database re­la­zio­na­li, alcuni dei vantaggi men­zio­na­ti quali la sem­pli­ci­tà del modello di dati basato su tabelle e la di­stri­bu­zio­ne dei dati tra più tabelle collegate possono rivelarsi svantaggi. Inoltre le ca­rat­te­ri­sti­che chiave del modello di dati re­la­zio­na­li sono difficili da con­ci­lia­re con i moderni requisiti di pro­gram­ma­zio­ne delle ap­pli­ca­zio­ni (come orien­ta­men­to degli oggetti, mul­ti­me­dia e big data).

• Mappatura tabellare dei dati: non tutti i tipi di dati possono essere espressi in uno schema rigido di tabelle bi­di­men­sio­na­li in­ter­con­nes­si (Impedance Mismatch). I tipi di dati astratti e i dati non strut­tu­ra­ti associati alle ap­pli­ca­zio­ni mul­ti­me­dia­li e alle soluzioni big data non possono essere mappati nel modello di database re­la­zio­na­le.
   
• Mancanza di uno schema di database ge­rar­chi­co: i database re­la­zio­na­li, a dif­fe­ren­za dei database di oggetti, non offrono la pos­si­bi­li­tà di im­ple­men­ta­re schemi di database con classi strut­tu­ra­te ge­rar­chi­ca­men­te. Concetti come quelli delle “entità figlio” che ereditano le proprietà dalle “entità padre” non possono essere uti­liz­za­ti. Ad esempio non è possibile uti­liz­zar­li per creare sot­to­tu­ple. Tutte le tuple di un database re­la­zio­na­le si trovano sullo stesso piano ge­rar­chi­co.
   
• Seg­men­ta­zio­ne dei dati: il principio di base dei sistemi di database re­la­zio­na­li, che consiste nella sud­di­vi­sio­ne delle in­for­ma­zio­ni su tabelle separate (nor­ma­liz­za­zio­ne), porta ne­ces­sa­ria­men­te ad una seg­men­ta­zio­ne dei dati: i dati correlati non sono ne­ces­sa­ria­men­te me­mo­riz­za­ti insieme. Questo design del database genera query complesse su più tabelle a livello di ap­pli­ca­zio­ne. Il con­se­guen­te maggior numero di segmenti in­ter­ro­ga­ti di solito ha anche un impatto negativo sulle pre­sta­zio­ni.
   
• Per­for­man­ce peggiori rispetto ai database NoSQL: il modello di database re­la­zio­na­le ha requisiti molto rigidi in termini di coerenza dei dati che nelle tran­sa­zio­ni vanno a discapito della velocità di scrittura.

Il modello di database re­la­zio­na­le è chiaro, ma­te­ma­ti­ca­men­te valido e ha alle spalle più di 40 anni di utilizzo pratico. Eppure l’ar­chi­via­zio­ne dei dati in tabelle strut­tu­ra­te non soddisfa tutti i requisiti della moderna tec­no­lo­gia in­for­ma­ti­ca.

I limiti dei classici sistemi re­la­zio­na­li sono messi in evidenza so­prat­tut­to dall’am­mi­ni­stra­zio­ne di grandi quantità di dati nel contesto dell’analisi di big data e dall’ar­chi­via­zio­ne di tipi di dati astratti, dove si di­stin­guo­no invece sistemi spe­cia­liz­za­ti come i database a oggetto o i concetti svi­lup­pa­ti nell’ambito del movimento NoSQL. Tuttavia non è possibile lasciarsi com­ple­ta­men­te alle spalle il modello di database re­la­zio­na­le, che tuttora offre molti vantaggi, spe­cial­men­te negli ambiti in cui l’ela­bo­ra­zio­ne dei dati delle tran­sa­zio­ni è di primaria im­por­tan­za.

I dati sulle azioni dei clienti o sulle misure di marketing si possono ideal­men­te rap­pre­sen­ta­re nei sistemi tabulari. Inoltre gli utenti be­ne­fi­cia­no di una sintassi che, no­no­stan­te la propria sem­pli­ci­tà, consente query complesse.