Caratteristiche e Differenza tra database relazionale e non relazionale

Gestione dei database

Nello svolgimento di qualunque attività, sono fondamentali la disponibilità di informazioni e la capacità di gestirle in modo efficace. Ed è proprio con questo scopo che la tecnologia dei database è oggi largamente utilizzata. Nel corso degli ultimi 40 anni l’utilizzo dei database ha avuto uno sviluppo esponenziale. Si è passati dal suo uso in grandi computer limitato ad un impiego da parte di poche persone molto specializzate alla situazione attuale che vede installato su ogni PC Workstation un qualche applicativo che si basa su database. Persino navigare in Internet significa sempre più avere a che fare con siti Web che spesso basano il loro funzionamento su di un database. Gli stessi motori di ricerca non sono altro che enormi database di catalogazione di pagine web.
Il termine database è perciò diventato di largo utilizzo, alle volte impropriamente. E’ importante pertanto, prima di iniziare a parlarne nei dettagli, una sua definizione. Un database è una collezione di dati associati tra loro, conservati in modo persistente in file. I dati sono rappresentazioni di fatti registrabili che hanno un significato implicito.

La precedente definizione è alquanto generale e permetterebbe di considerare anche questo stesso testo, essendo un insieme di dati collegati tra loro, come un database. Solitamente però il termine database ha un significato più ristretto. Implicitamente il concetto di database porta con sé le seguenti proprietà:

1. Un database è concepito per modellare un qualche aspetto del mondo reale, che alcuni autori chiamano miniworld. Modifiche al miniworld sono rispecchiate nel database;
2. L’insieme dei dati che compone un database è logicamente coerente e possiede un significato. Un assortimento casuale di dati non può essere considerato un database;
3. Un database è disegnato, costruito e popolato di dati per uno scopo ben definito. Un gruppo di utilizzatori è designato al suo uso, essi sono interessati alle applicazioni per le quali il database è stato concepito.

I meccanismi e i dettagli operativi necessari alla registrazione fisica dei dati sono astratti dagli utenti tramite un DBMS (database management system) che è un insieme di programmi che permette di creare, mantenere e modificare un database. Esistono diverse modalità tramite le quali un DBMS può implementare queste funzionalità ma, negli anni, la tipologia che è risultata di gran lunga più popolare è quella che si basa sul modello dati relazionale.

Database relazionale

Il modello relazionale (o database relazionale) organizza i dati in un database tramite una collezione di relazioni. Informalmente ogni relazione è rappresentata da una tabella. Formalmente, una relazione è un insieme di definizioni di predicati, come per esempio “Michele è di Bari”, dove “Michele” è il soggetto e “è di Bari” è il predicato. I dati “Michele” e “Bari” sono collegati tra loro da una relazione (nel senso che un dato è relativo all’altro).
Il modello relazionale fu definito per la prima volta da E. F. Codd (anno 1970) e successivamente esteso da altri autori. Lo scopo di Codd fu di superare le limitazioni dei modelli dell’epoca che non permettevano di realizzare la proprietà di indipendenza tra le strutture fisiche dei dati e la loro descrizione logica.
Il modello relazionale è basato sul concetto di relazione, che ha solide fondamenta nella teoria degli insiemi. Tuttavia, nonostante derivi da una formalizzazione molto precisa e apparentemente complessa, è ricondotto ad alcuni concetti di natura più semplice ed intuitiva che ne hanno decretato il successo.

Nel definire il modello relazionale, Codd fornì 13 regole per la visualizzazione della relazione nella forma di tabella:

1. Perché un sistema si possa qualificare come un database relazionale esso deve usare le sue funzioni relazionali per gestire il database;
2. Regola dell’informazione: tutta l’informazione nel database deve essere rappresentata in un unico modo, nominalmente, da valori posizionati in colonne nelle righe delle tabelle;
3. Regola della garanzia di accesso: ogni valore memorizzato in un DataBase relazionale deve essere accessibile indicando il nome della tabella in cui si trova, il nome della colonna e il valore della chiave primaria che definisce la riga in cui è memorizzato;
4. Gestione sistematica dei valori nulli (NULL): il DBMS (il sistema di gestione del database) deve supportare una rappresentazione dei valori mancanti e delle informazioni inapplicabili che sia sistematica, distinta da altri valori regolari e indipendente dal tipo di dato (Codd pensava a due distinte rappresentazioni, token, per i valori mancanti e le informazioni inapplicabili, mentre poi l’Sql le ha unificate);
5. Dizionario basato sul modello relazionale: la descrizione logica del DataBase relazionale deve essere rappresentata allo stesso modo di un dato ordinario, in modo che gli strumenti del sistema di gestione del DataBase relazionale si possano usare per gestire la descrizione stessa del DataBase;
6. Linguaggio dei dati: un sistema di gestione di DataBase relazionale può offrire molti tipi di linguaggi di descrizione dei dati e di accesso al database; comunque ci deve essere almeno un linguaggio che:
   • ha una sintassi lineare;
   • può essere utilizzato sia interattivamente che all’interno di programmi;
   • supporta la definizione dei dati e delle viste, la loro manipolazione, i vincoli di integrità dei dati, la gestione delle informazioni riguardanti le autorizzazioni e le operazioni di gestione delle transazioni;
7. Aggiornamento delle viste: deve essere possibile al sistema di gestione del database aggiornare qualunque vista che possa essere definita usando combinazioni di tabelle base che, in teoria sono aggiornabili a loro volta (l’aggiornamento delle viste è un problema complesso);
8. Inserimento, Aggiornamento e Cancellazione: qualunque operando che descriva il risultato di una singola operazione di lettura deve poter essere applicato ad una singola operazione di inserzione, aggiornamento o cancellazione;
9. Indipendenza fisica dei dati: le modifiche che vengono apportati alla struttura fisica di memorizzazione e ai meccanismi di accesso non devono comportare cambiamenti nei programmi applicativi;
10. Indipendenza logica dei dati: i cambiamenti effettuati sulle tabelle che non modificano nessuno dei dati già memorizzati non devono comportare cambiamenti ai programmi applicativi;
11. Regole di Integrità: le regole che si applicano all’ integrità di entità e all’ integrità referenziale devono essere esprimibili nel linguaggio dei dati implementato dal sistema di gestione del database e non con i comandi codificati nei programmi applicativi;
12. Distribuzione del database: il linguaggio dei dati implementato dal sistema di gestione del database deve offrire la possibilità di distribuire il database senza richiedere modifiche ai programmi applicativi. Questa opportunità deve essere fornita indipendentemente dalla capacità del DBMS di supportare i database distribuiti;
13. Non-sovversione: se il sistema di gestione del database offre strumenti che consentano ai programmi applicativi di operare sulle tabelle una riga alla volta, ad un programma applicativo che usa questo tipo di accesso al database deve essere impedito di infrangere le regole di integrità di entità o integrità referenziale definite per quello stesso database.

La lista appena riportata identifica le 13 regole originarie, che nella seconda versione del modello relazionale divennero ben 333. Codd specificò, inoltre, altri elementi necessari, che non riporto in questo articolo tra questi ci sono, 9 funzioni strutturali, 3 funzioni di integrità e 18 funzioni di manipolazione.

Database non relazionale

I sistemi di gestione di basi di dati relazionali oggi sono la tecnologia predominante per la memorizzare di dati strutturati per applicazioni web e aziendali. Da quando Codds pubblicò l’articolo “A relational model of data for large shared data banks” del 1970, questo metodo di archiviazione di dati è stato ampiamente adottato ed è stato spesso considerato come la migliore alternativa per la memorizzazione di dati.

Negli ultimi anni una serie di nuovi sistemi sono stati progettati per fornire una buona scalabilità orizzontale al fine di ottenere elevate prestazioni nelle operazioni di scrittura/lettura su database distribuiti su più server, in contrasto con i database tradizionali che hanno poche possibilità di essere scalabili orizzontalmente.

Molti di questi nuovi sistemi sono chiamati NoSQL data stores (o database non relazionale). La definizione di NoSQL, che sta per “Not Only SQL” o “Not Relational”, fu usata per la prima volta nel 1998 per una base di dati relazionale open source che non usava un’interfaccia SQL. Il termine fu reintrodotto nel 2009 dall’impiegato di Rackspace, Eric Evans, quando Johan Oskarsson di Last.fm volle organizzare un evento per discutere di basi di dati distribuite open source. Il nome fu un tentativo per descrivere l’emergere di un numero consistente di sistemi di archiviazione dati distribuiti non relazionali che spesso non tentano di fornire le classiche garanzie ACID riferendosi a sistemi come MySQL, MS SQL e PostgreSQL.

NO-SQL è un movimento che negli ultimi anni si è molto affermato, producendo dei risultati soddisfacenti con la creazione di progetti e iniziative utilizzate anche su larga scala. Tale movimento vuole “rompere” la storica linea dei database relazionali e definire delle nuove linee guida per l’implementazione di database che non utilizzano il linguaggio di interrogazione SQL e non siano strettamente legati ad una definizione “rigida” dello schema dati.

Generalmente i sistemi NoSQL hanno delle caratteristiche in comune che possono essere riassunte nei seguenti punti:

1. Abilità di scalare orizzontalmente semplici operazioni su più server, con il vantaggio di supportare un gran numero di semplici operazioni in lettura/scrittura, questo metodo di elaborazione dati è chiamato OLTP, Online Transaction Processing, che ha lo scopo di supportare un gran numero di piccole transazioni on-line, con un’elevata velocità nell’elaborazione delle interrogazioni, mantenendo l’integrità dei dati in ambienti multiaccesso e l’efficacia di esecuzione di un gran numero di transazioni al secondo;
2. Abilità di replicare e distribuire i dati su più server;
3. Un modello di concorrenza delle transazioni non basato sulle proprietà ACID della maggior parte dei database relazionali. Alcuni suggeriscono l’acronimo BASE (Basically, Available, Soft state, Enetually consistent). L’idea è che rinunciando ai vincoli ACID si possano ottenere prestazioni elevate e maggiore scalabilità;
4. Un uso efficiente di indici distribuiti e RAM per la memorizzazione dei dati;
5. Abilità di aggiungere dinamicamente nuovi attributi ai record di dati.

Negli ultimi due anni il movimento NoSQL ha attirato un gran numero di imprese e aziende, che sono passate dai database relazionali agli archivi di dati non relazionali. Alcuni esempi sono Cassandra3 originariamente sviluppato all’interno di Facebook e oggi usato anche da Twitter e Digg, Project Voldemort sviluppato e usato da Linkedln, servizi di cloud come il database NoSQL di Amazon SimpleDB5, il servizio di memorizzazione e sincronizzazione Cloud Ubuntu One basato sul database non relazione CouchDB6.
La maggior parte dei database NoSQL hanno adottato le idee di Bigtable di Google e Dynamo di Amazon, che hanno fornito una serie di concetti che hanno ispirato molti degli attuali data stores.
Come si può vedere i pionieri del movimento NoSQL sono grandi compagnie web o imprese che gestiscono importanti siti web come Google, Facebook e Amazon e altri che in questo campo hanno adottato queste idee per venire incontro alle loro esigenze e requisiti.
Perciò una delle principali motivazioni per l’uso di tali database è la necessità di sviluppare nuove applicazioni che non possono essere affrontate con il tradizionale approccio relazionale.

La ricerca di alternative ai database relazionali può essere spiegata da due principali esigenze:

• La continua crescita del volume di dati da memorizzare;
• La necessità di elaborare grandi quantità di dati in poco tempo.

Queste nuove necessità sono dovute a molti fattori come l’aumento esponenziale del numero di utenti della rete, la diffusione sempre maggiore dell’OpenID, lo sviluppo di sinergie tra le varie community e i fornitori di servizi, ma anche la crescente disponibilità di dispositivi con accesso ad Internet come smartphone, tablet e altri dispositivi portatili.
Per far fronte alla necessità di gestire quantità di dati sempre maggiori e a velocità sempre più elevate i nuovi sistemi di memorizzazione si sono evoluti per essere più flessibili, utilizzando modelli di dati meno complessi, cercando di aggirare il rigido modello relazionale e per aumentare il livello delle prestazioni nella gestione e interrogazione dei dati.
Queste nuove esigenze si connettono al mondo dei sistemi distribuiti. Più precisamente verso la metà degli anni 90, con l’avvento dei grandi sistemi basati su Internet, si iniziò a considerare la disponibilità di servizio da parte di un sistema come un requisito importante. Fino a quel momento infatti, la cosa che più contava era la coerenza e la sicurezza dei dati.

Eric Brewer in un KeyNote alla conferenza “Principle of Distributed Computing” del 2000 presentò il Teorema del CAP7. Il teorema, si basa sulle tre lettere che formano la parola CAP, ed ogni lettera è una caratteristica del sistema distribuito su cui si sta lavorando:

• Consistency (Coerenza): dopo una modifica tutti i nodi del sistema distribuito riflettono la modifica;
• Availability (Disponibilità): ad una richiesta, il sistema è sempre in grado di dare una risposta, in altre parole, il sistema è sempre disponibile;
• Partition Tollerance (Tolleranza al Partizionamento): se le comunicazioni si interrompono tra due punti del sistema, il sistema non fallisce ma continua ad essere disponibile.

Il Teorema enuncia l’impossibilità di avere tutte e tre le caratteristiche nello stesso momento, perciò se ne possono implementare due a discapito della terza.
Pertanto se si sceglie di non avere una tolleranza al partizionamento avremo problemi sulla scalabilità verticale, proprietà spiegata in seguito, che è sicuramente più costosa.

Se si rinuncia alla disponibilità dobbiamo attendere che vengano risolte alcune richieste a discapito delle prestazioni. Se si rinuncia alla coerenza si avrà per un periodo un disallineamento dei dati sui nodi. Questi ultimi due problemi sono quelli più noti e permettono di superare il problema della scalabilità. Per scalabilità orizzontale si intende la capacità di un’applicazione di crescere e decrescere in base alle necessità richieste dagli utenti, introducendo o togliendo dei nodi al sistema senza compromettere il suo funzionamento. In una qualche maniera si riesce dunque a parallelizzare il carico del lavoro.

Grazie a questo approccio, avendo più nodi, l’errore in un nodo non pregiudica il funzionamento dell’intero database e quindi il sistema risulta più sicuro. Un altro vantaggio è sicuramente il costo, in quanto con un’applicazione scalabile si possono creare più nodi a basso costo. Gli unici svantaggi di questa scelta risiedono però nella progettazione dell’applicazione, che deve rispecchiare questa struttura scalabile e non comportare troppi problemi nell’installazione.

Con il passare del tempo, oltre alla disponibilità di un sistema un’altra caratteristica divenne fondamentale, ovvero la capacità di crescere e decrescere in base alle necessità richieste dagli utenti del sistema, più propriamente chiamata scalabilità orizzontale.
La scalabilità orizzontale si ha se l’aumento delle risorse si riferisce all’aumento dei nodi nel sistema, cioè il sistema riesce a parallelizzare il carico di lavoro. Il vantaggio più importante dato da questo tipo di scalabilità è il costo: infatti, con un’applicazione perfettamente scalabile, si potrebbero impiegare molti nodi a basso costo, ottenendo anche una maggiore prevedibilità del costo marginale. Un altro vantaggio è la maggior tolleranza ai guasti: l’errore in un nodo non pregiudica totalmente il funzionamento dell’applicazione. Gli svantaggi risiedono nei maggiori sforzi in fase di progettazione perché l’applicazione deve innanzitutto supportare questo modello di scalabilità; inoltre l’applicazione deve essere facile da amministrare, per ridurre i costi d’installazione.
Importante è il caso di Amazon, che nell’anno 2007 pubblicò un WhitePaper, nel quale si spiegava il motivo della nascita ed il funzionamento di Dynamo, un Key/Value Store ad alta disponibilità.

Leggendo il WhitePaper, e soprattutto il blog di Werner Vogels si capisce come il modello relazionale non soddisfaceva le sfide che stava affrontando Amazon, o meglio, si sarebbe potuto adattare il modello relazionale ad Amazon, ma questo avrebbe significato creare una soluzione inefficiente soprattutto dal punto di vista economico.

Tradizionalmente infatti, i sistemi di produzione immagazzinano il loro stato in database relazionali. Ma la maggior parte di questi sistemi immagazzina e legge dati partendo da un’unica chiave primaria e di conseguenza non richiedono tutta la complessità di interrogazione che un database relazionale può essere in grado di fornire, producendo uno spreco di risorse.

La soluzione relazionale è quindi in questo caso sconveniente, ma lo diventa ancora di più quando una compagnia come Amazon deve scalare il proprio sistema, infatti, nonostante i passi in avanti fatti negli ultimi anni, resta complicato aggiungere o togliere un nodo ad un database relazionale distribuito, e questa complessità difficile da abbattere è figlia della potenza che il database relazionale garantisce nella gestione dei dati, dalla sincronizzazione spesso non implementata in modo efficiente che richiede protocolli costosi come il commit a due o tre fasi e cosa più importante dal fatto che i database relazionali inizialmente furono realizzati per applicazioni centralizzate.