I nuovi modelli dei dati

Come evidenziato nell’introduzione, fino ai primi anni 2000 il modello relazionale dei dati era il principale e sostanzialmente unico modello per la descrizione e gestione di dati strutturati. E’ bene ricordare come negli anni 70 e 80 del secolo scorso le tecnologie hardware e di rete non erano neanche lontanamente assimilabili a quelle attuali, e, di conseguenza, i requisiti applicativi erano profondamente diversi.

Basti ricordare che il termine “computer per uso personale” (personal computer o PC) è una invenzione dei primi anni 80 del secolo scorso, mentre all’epoca di Codd gli hard disk (inizialmente chiamati anche tamburi) erano come quelli mostrati in Figura 2, ed erano in grado di memorizzare solo 250 Mbytes (milioni di byte, un byte permette di memorizzare, ad esempio, un carattere alfabetico), ovvero l’equivalente di poco meno di 50 foto di un comune telefono cellulare, ad un costo di svariate decine di migliaia di dollari!

100

(tratta da https://it.wikipedia.org/wiki/Memoria_a_tamburo)

È chiaro come di fronte a uno spazio di memorizzazione così costoso, uno degli elementi fondamentali di successo del modello relazionale è la unicità nella rappresentazione del dato, ovvero la proprietà consistente nel memorizzare una sola volta nella base di dati un determinato dato digitale. Inoltre, questa caratteristica consente una migliore gestione della qualità del dato; se devo aggiornare un dato, ad esempio la città di residenza di uno studente, lo devo fare una sola volta, mentre in presenza di numerose copie devo aggiornare tutte le copie dello stesso dato, e posso generare inconsistenze se mi scordo di aggiornane qualcuna. Tratteremo il tema della qualità dei dati nel prossimo Capitolo 5. Per apprezzare a pieno la grande novità del modello relazionale nel momento in cui fu lanciato, occorre ricordare che negli anni 60 l’ingegneria del software, la disciplina che studia il ciclo di vita del software, dalla definizione dei requisiti alla progettazione e codifica di una applicazione software, era ai suoi albori, e il linguaggio di programmazione con cui si codificavano i programmi era il Cobol, linguaggio citato nel prologo di questo libro. Nel linguaggio Cobol i dati erano descritti da una Data Division, ed erano locali ai programmi; ogni programma aveva i suoi dati. Inoltre per esprimere una interrogazione, era necessario produrre un programma apposito, con istruzioni molto verbose e poco potenti. È importante tenere a mente queste caratteristiche, che hanno reso il modello relazionale e il linguaggio di interrogazione dei dati, l’ SQL, di cui abbiamo mostrato un esempio nel Capitolo 3, molto popolari fino ai giorni nostri.

Le nuove applicazioni informatiche nate a seguito dell’avvento di Internet e del Web (social network, videogiochi on line, ecc.) male si adattano a essere realizzati usando il modello relazionale e le sue tecnologie software. Da un lato il modello ha delle rigidità modellistiche, in quanto tutti i dati devono essere rappresentati nello stesso modo, mediante tabelle, e dall’altro la tecnologia utilizzata, seppur evoluta nel corso degli anni, non ha mai abbandonato alcune caratteristiche fondamentali del linguaggio SQL. I moderni linguaggi di programmazione prevedono un paradigma di gestione di dati (detto a oggetti) diverso da quello del linguaggio SQL; di conseguenza per scrivere dei programmi con i moderni linguaggi di programmazione che interagiscono con una base di dati relazionale, è necessario prevedere la realizzazione di software chiamato middleware, in grado di far dialogare l’applicazione software con la base di dati, che in genere è molto complesso. La riduzione progressiva del tempo di vita sul mercato delle applicazioni, si pensi a videogiochi che vivono per meno di una stagione, ha imposto una forte spinta a ridurre il tempo di produzione del relativo software applicativo.

Questi due fattori (i vincoli modellistici e i limiti tecnologici delle basi di dati relazionali) hanno dato impulso alla ricerca di nuovi modelli di rappresentazione dei dati. Il termine NoSQL1 (not only SQL) fa riferimento ai nuovi modelli di gestione dei dati che vanno oltre il modello relazionale e il suo linguaggio di interrogazione SQL.

1 Il termine NoSQL è stato introdotto per la prima volta nel 1989 dall’italiano Carlo Strozzi come nome di un insieme di interfacce programmabili (API) per accedere a una base di dati relazionale non usando il linguaggio SQL. L’acronimo indicava inizialmente la volontà di NON usare il linguaggio SQL. Oggi si fa riferimento alla sigla NoSQL con il significato di “non solo SQL”.

101

A causa del proliferare di questi nuovi modelli, si è scelto di presentarli secondo un ordine che parte dal modello più semplice di gestione dei dati, il modello Chiave-valore, per arrivare a modelli sempre più sofisticati per la gestione di dati complessi.

5.1. Modello Chiave-valore

Nel modello chiave-valore si associa ad una chiave, ovvero un valore univoco nell’insieme dei dati (dataset nel seguito), un valore. Ad esempio, se vogliamo rappresentare il cognome di un insieme di persone, possiamo usare come chiave il codice fiscale, e come valore il cognome. Il valore può essere non solo un tipo di dato semplice come una stringa di caratteri o un numero intero, ma anche un oggetto più complesso, come un video o una immagine o un frammento di una pagina Web. Questo modello è molto semplice, ed è utile nei contesti applicativi in cui è necessario accedere ad un valore nota la chiave.

Le basi di dati chiave-valore sono molto usate per le applicazioni che richiedono di gestire in memoria centrale una grande quantità di dati. Occorre ricordare che la memoria di un elaboratore è strutturata in diversi strati di memoria, tra cui possiamo distinguere una memoria centrale, “vicina” alla unità di calcolo dove vengono eseguiti i programmi, e una memoria secondaria, realizzata mediante dischi magnetici e, nelle versioni più recenti, mediante tecnologie a stato solido. Con il termine “vicina” intendiamo il fatto che per trasferire un dato da memoria centrale alla unità di calcolo occorrono 10^-8 / 10^-9 secondi; invece, per trasferire un dato da memoria secondaria alla unità di calcolo occorrono nel caso di memoria realizzata a dischi circa 10^-2 secondi. La memoria centrale ha limiti di capacità, per cui in genere le basi di dati vengono memorizzate permanentemente in memoria secondaria.

Si pensi allora al carrello della spesa di una applicazione di e-commerce. Esso può essere modellato come una coppia chiave-valore dove la chiave è l’identificativo dell’utente e il valore è l’intero contenuto del carrello. L’accesso alla memoria centrale rispetto a quella secondaria consente un risparmio di tempo molto significativo. Per tale motivo, i grossi venditori on line come Amazon o le piattaforme di giochi on line usano massicciamente questo modello, perchè consente l’accesso a tutti i dati di un cliente in maniera molto veloce.

Essendo un modello molto semplice e utilizzato usualmente su memorie non persistenti, che cioè non garantiscono che a causa di un improvviso calo di tensione o guasto al sistema i dati non si perdano, il modello chiave-valore ha un raggio di applicazioni ben specifico; certamente, le capacità tecnologiche delle soluzioni disponibili sul mercato per il modello lo rendono ideale per gestire in modo efficace una memoria centrale dinamica.

5.2. Modello Wide Column

Come detto precedentemente, il modello chiave-valore è molto semplice ed efficace in diversi contesti applicativi. È possibile far evolvere il modello chiave-valore arricchendo la semantica del campo valore. Nel modello wide column è possibile ad esempio strutturare ogni singolo valore di attributo, nella terminologia del modello relazionale, in un insieme di campi che possono assumere significati e valori diversi.

102

il modello wide column si avvicina per alcuni aspetti al modello relazionale, in quanto riprende il concetto di relazione con attributi. Le più importanti differenze rispetto al modello relazionale sono  la mancanza di uno schema rigido (si parla anche di modello schemaless, senza schema) e  la presenza di una chiave identificativa di solito definita dal sistema e non definibile dall’utente. Per quanto riguarda gli aspetti legati alla flessibilità dello schema, si vede nella Figura 3 come uno stesso dataset che descrive le informazioni gestite da un negozio virtuale di eCommerce può rappresentare nella prima riga un libro, con un identificatore (una coppia di attributi costituta da un codice prodotto e, nella prima riga, un identificatore del libro), il titolo, l’autore e l’anno di pubblicazione, mentre la riga successiva, che si riferisce a un album musicale, contiene oltre all’identificatore solo il titolo e l’autore. Successivamente, abbiamo una terza riga con il titolo di una traccia (si veda come anche l’identificatore cambia); ancora diversa è l’ultima riga, in cui è presente un film descritto dall’identificatore, il titolo, la tipologia e l’autore.

Figura 3 – Un dataset nel modello wide-column (tratta da https://aws.amazon.com/it/nosql/key-value/)

È importante sottolineare come nel modello wide column la flessibilità dello schema è giustificata dalle necessità applicative dei moderni sistemi informativi, che devono gestire piattaforme tecnologiche a rete, complesse e che si modificano dinamicamente nel tempo; pensiamo al sistema informativo di Amazon, che gestisce una rete di utenti e fornitori distribuita a livello mondiale con cui intrattiene relazioni di business che si modificano nel tempo.

Questi sistemi informativi richiedono estrema flessibilità dei requisiti e, di conseguenza, nella progettazione o nella manutenzione evolutiva di applicazioni software. Lo sviluppo di applicazioni basate su basi di dati tradizionali prevede una lunga fase iniziale di strutturazione dello schema della base di dati, e solo successivamente lo sviluppo del codice. Nel caso in cui sia stato necessario durante lo sviluppo modificare lo schema della base di dati, è necessario fermare lo sviluppo e ricominciare dalla attività di progettazione della base di dati; questo processo di produzione, certamente efficace per applicazioni complesse e relativamente stabili nel tempo, è oggi troppo oneroso per i vincoli di rapidità e di flessibilità nello sviluppo software descritti in precedenza. Grazie alla flessibilità dello schema, è possibile durante lo sviluppo dell’applicativo, o successivamente al rilascio di esso, modificare lo schema

103

adattandolo ai nuovi dati da inserire. È evidente comunque che questa flessibilità debba essere ben governata per non generare problemi di qualità nei dati, derivanti dalle continue modifiche ai requisiti. Il modello wide column è stato implementato da numerosi “giganti” delle tecnologie come Google, Amazon e Facebook con i loro prodotti denominati Big Table, Dynamo e Cassandra. Va notato che, in assenza di una standardizzazione, ognuno di loro ha sviluppato non solo diverse soluzioni per la scalabilità ma soprattutto diversi linguaggi di interrogazioni che comunque si ispirano in misura diversa al linguaggio SQL.

Nella Figura 4 troviamo un altro esempio che mostra la flessibilità del modello wide column rispetto al modello relazionale. Supponiamo di voler costruire una anagrafica dei clienti di una banca; è possibile che non tutti i clienti abbiano definiti gli stessi attributi, ovvero che per qualche attributo non sia noto il loro valore. Nel modello relazionale questo è risolvibile utilizzando il valore Null. Nel modello wide column è possibile invece semplicemente non assegnare i valori.

Figura 4 – Un frammento di una anagrafica dei clienti nel modello wide-column (tratta da https://database.guide/what-is-a-column-store-database/

Dal punto di vista teorico, è possibile affermare che mentre il modello relazionale si basa sulla ipotesi di mondo chiuso (closed world assumption, tutte le informazioni note sono memorizzate nel dataset, e se non sono memorizzate non esistono), tutti i modelli NoSQL, e dunque anche il modello wide column, si basano sulla ipotesi di mondo aperto: su tutto ciò che non è rappresentato nella base dati non si può dire nulla, né che esista, né che non esista.

Va infine ricordato come il modello wide column non prevede nativamente di collegare logicamente dati fra di loro, come è possibile fare con il modello relazionale; si tratta di un elemento importante nella corretta scelta del modello. Facendo riferimento ai concetti del modello Entità Relazione, nel modello wide column le relazioni tra i dati sono solo di tipo uno a uno.

104

È possibile arricchire il modello precedentemente mostrato, consentendo a ogni singolo attributo di essere non solo un attributo di tipo semplice avente come valori, ad esempio, stringhe di caratteri come in un cognome, ma anche un attributo di tipo composto caratterizzato da un insieme di valori, composti a loro volta da coppie chiave-valore, e così via. Il modello documentale, che descriviamo in questo paragrafo, può essere dunque visto come una struttura complessa nidificata, che descrive relazioni uno a molti.

Uno dei possibili linguaggi per rappresentare il modello documentale è Json. In Json un documento è formato da una chiave (rappresentata come una stringa) e un valore. Ogni valore può essere un tipo semplice ovvero un array di valori, cioè una colonna di n valori, associati alle posizioni 1, 2, .., ovvero un oggetto strutturato, cioè un insieme di coppie chiave-valore. Tutte queste possibilità modellistiche consentono un esteso utilizzo del modello documentale in molti ambiti applicativi.

Il modello documentale è dunque almeno dal punto di vista concettuale, più ricco di quello relazionale, tuttavia dal punto di vista tecnico la sua diffusione seppure vasta non è ancora paragonabile a quella del modello relazionale, per la mancanza di standard e per la presenza di applicazioni software e soluzioni tecnologiche cosiddette legacy, cioè ereditate dal passato, che difficilmente possono essere abbandonate dalle aziende.

Vediamo ora due diverse soluzioni modellistiche per rappresentare dati logicamente in relazione tra loro, chiamate referencing e embedding. Si assuma di voler modellare un sistema per la gestione dei biglietti da visita dei dipendenti di una azienda. La relazione che lega un dipendente ai suoi indirizzi, ad esempio l’indirizzo della sede della azienda e l’indirizzo di casa, ha una natura uno a molti, un dipendente può avere molti indirizzi associati. Nel modello relazionale e anche nel modello documentale si può modellare la relazione mediante due tabelle, una per il dipendente e una per gli indirizzi, come mostrato in Figura 5. Questa soluzione modellistica è chiamata referencing.

Figura 5 – Dipendenti e indirizzi mediante referencing

Figura 6 – Dipendenti e indirizzi mediante embedding

Contact Name Company Title Phone Address Street City State Zip_code Contact Name Company Address Title Phone Street City ….

105

È possibile modellare lo stesso insieme di dati attraverso embedding. In questo caso, vedi Figura 6, è possibile inglobare le informazioni sugli indirizzi come una ulteriore specificazione delle informazioni del cliente. Va notato come sia possibile anche in questo caso che un cliente abbia diversi indirizzi a cui possa essere raggiunto; questo tipo di soluzione consente un più semplice inserimento dei dati, in quanto tutta l’informazione è riportata in un unico documento che a sua volta contiene uno o più documenti. Anche il ritrovamento dell’intera informazione è semplificato, in quanto, una volta individuato il contatto da cercare, tutta la informazione collegata logicamente si trova in un unico documento.

È peraltro evidente che la soluzione mediante embedding provoca una replicazione nelle informazioni dell’indirizzo, poiché l’indirizzo della azienda sarà replicato per tutti i dipendenti. Non va tuttavia dimenticato che i costi della memoria si sono ridotti significativamente negli ultimi 50 anni (un gigabyte “affittato” su una piattaforma cloud può costare qualche centesimo di euro l’anno). Resta invece ancora critico in questa soluzione dal punto di vista applicativo il problema della corretta gestione delle modifiche, ad esempio, dell’indirizzo della azienda, che dovranno essere effettuate su tutte le sue copie. La scelta tra le due rappresentazioni dipende dal cosiddetto carico applicativo; se è più frequente cercare il contatto e poi, nel caso, l’indirizzo, allora la soluzione embedding sarà quella preferita. Se invece vi sono frequenti accessi direttamente agli indirizzi, sarà preferibile la soluzione referencing. In conclusione, le due soluzioni in Figura 5 e Figura 6 sono equivalenti come potere descrittivo, tuttavia possono dar luogo a prestazioni molto diverse in funzione del carico applicativo. I prodotti più popolari che utilizzano il modello documentale sono MongoDB e CouchDB.

2.4 Modelli a grafo

I modelli a grafo sono stati introdotti nel Capitolo 3, mettendo in enfasi in particolare la loro capacità di rappresentare nel Web insiemi di dati che possono essere condivisi e collegati; li riprendiamo qui per confrontarli con i modelli introdotti in precedenza nel capitolo. Un ulteriore approfondimento sarà fatto nel Capitolo 7. Dal punto di vista modellistico, un grafo è formato da nodi che rappresentano concetti del mondo reale e da relazioni che li collegano. Va notato come la teoria dei grafi sia molto antecedente l’apparizione dell’Informatica, e tutti i contributi teorici e metodologici relativi alla teoria dei grafi possono portare enormi interessi applicativi, e non solo nel campo delle basi di dati a grafo. Numerosi sono i possibili campi di applicazione delle basi di dati a grafo: i social network, i sistemi informativi geografici, i sistemi per la logistica, la bioinformatica sono solo alcuni degli esempi possibili di applicazioni.

106

Figura 7 – Un esempio di grafo con tipi e proprietà

È possibile associare ai nodi e agli archi di un grafo dei tipi e proprietà come mostrato nel Capitolo 3 e ripreso nella Figura 7. Anche nei modelli a grafo, come nei precedenti modelli descritti in questo capitolo, ogni singolo nodo è indipendente dagli altri e può avere attributi diversi.

Di fatto nel modello a grafo, così come negli altri, scompare la tradizionale divisione fra descrizione intensionale, lo schema, ed estensionale, i valori, presente nel modello relazionale. Inoltre, in un grafo come quello riportato in Figura 7, il collegamento fra concetti è realizzato dagli archi, questa caratteristica rende il modello a grafo facilmente visualizzabile, anche se all’aumentare del numero di oggetto esistono significativi problemi di visualizzazione di grafi fortemente connessi. Affronteremo questi aspetti nel Capitolo 12 sulle astrazioni, in cui mostreremo come si possa rappresentare un grafo a diversi livelli di dettaglio.

Cosi come per gli altri modelli NoSQL, e come abbiamo già osservato nel Capitolo 3 quando abbiamo introdotto i property graph, non esiste per i grafi un unico modello di interrogazione. Ogni modello a grafo ha il suo proprio linguaggio di interrogazione, tuttavia negli ultimi anni stanno emergendo due linguaggi che possono diventare standard condivisi. Il primo è il linguaggio Cypher ideato dal Neo4J, produttore dell’omonimo modello a grafo; si tratta di un linguaggio concettualmente vicino al linguaggio SQL. Il linguaggio Gremlin proposto da Facebook ha un approccio diverso; il linguaggio esprime interrogazioni sul grafo per via esplorativa, immaginando di accedere a tutti i nodi, percorrendo per ciascuno i cammini costituiti da archi che soddisfano determinate condizioni, e così via fino al completamento dell’interrogazione.

2.5 Confronto fra modelli

Dopo aver presentato i vari modelli NoSQL, è necessario comprendere in quali contesti applicativi una soluzione sia preferibile ad un'altra. Come è naturale, non esiste una soluzione che vada bene sempre; per lo stesso problema applicativo, contesti diversi in termini, ad esempio, di volume (vedi Figura 8) di dati, possono richiedere soluzioni diverse.

107

Figura 8 – I modello NoSQL confrontati in termini di volume dei dati e complessità Nella Figura 8 sono riportati i modelli NoSql illustrati in questa sezione e il posizionamento fra:  la dimensione dei dati che i sistemi di gestione basati sui modelli sono in grado di gestire e  il livello di complessità del mondo reale che il modello può rappresentare.

Appare evidente come il modello chiave-valore sia il più semplice, e, allo stesso tempo, anche quello in grado di gestire una quantità di dati maggiore degli altri. Dalla parte opposta, abbiamo il modello a grafo, che è in grado di modellare realtà molto complesse ma, anche a causa di tale complessità non è in grado di gestire efficacemente quantità di dati paragonabili a quelle gestibili con tecnologie chiave-valore.

Al giorno di oggi non è infrequente usare diversi modelli dati per lo stesso contesto applicativo, in quanto le necessità applicative necessitano spesso di modelli diversi. Nella Figura 9 rappresentiamo lo stesso frammento di basi di dati su attori, registi e film nel modello relazionale e in un modello a grafo. Appare immediata la differenza nella leggibilità dei dati descritti, intesa come capacità dei dati di esprimere il significato, senza necessità di documentazione aggiuntiva, così come è semplice verificare quale sia il modello più adatto per capire in quali film l’attore Tom Hanks sia stato insieme regista e