Tesi di Lamuraglia Federica

Sommario
Sommario .......................................................................................................................... 1
CAPITOLO 1: DBMS ....................................................................................................... 2
Introduzione ...................................................................................................................... 2
1.1 DBMS ...................................................................................................................... 4
1.2 Il modello relazionale ............................................................................................... 5
1.3 Il modello non relazionale ........................................................................................ 8
1.3.1 Classificazione dei database non relazionali ..................................................... 13
1.3.2 Vantaggi e svantaggi dei db non relazionali ...................................................... 15
1.4 Dbms relazionali e non: elementi a confronto ........................................................ 17
CAPITOLO 2: MYSQL E MONGODB ........................................................................ 19
2.1 MySql ..................................................................................................................... 19
2.1.1 Caratteristiche.................................................................................................. 19
2.2 Mongo DB ............................................................................................................. 24
2.2.1 La nuova filosofia di MongoDB ...................................................................... 28
2.3 Comparazione tra MongoDB e MySQL ................................................................. 30
CAPITOLO 3: CASO STUDIO EFFICIENTOMETRO ............................................... 32
Introduzione .................................................................................................................... 32
3.1 Database dell’efficientometro ................................................................................. 33
3.2 Principi di progettazione ........................................................................................ 34
3.3 Siope ...................................................................................................................... 37
3.4 Megafile ................................................................................................................. 38
3.5 Aggregazione dei dati ............................................................................................. 39
3.6 Piattaforma Web .................................................................................................... 40
3.7 Ulteriore sviluppo .................................................................................................. 41
Conclusioni...................................................................................................................... 42
BIBLIOGRAFIA ............................................................................................................ 43
SITOGRAFIA................................................................................................................. 44
1
CAPITOLO 1: DBMS
Introduzione
L'affermarsi e il dispiegarsi della diffusione della tecnologia digitale ci ha proiettati in
una nuova era: quella dell'informazione veloce e del capitalismo informazionale. Si tratta di
una nuova forma di organizzazione produttiva e sociale legata all'economia delle reti digitali
e dei flussi informazionali.
E' la New Economy che porta a definire quella attuale come l’era dell’informazione: il
mondo economico si rende sempre più conto che vince sul mercato globale chi meglio sa
accumulare e gestire l’informazione.
La società dell'informazione trova la sua origine in quella di "società post-industriale"
ed è stata usata per la prima volta nel 1973 da Daniel Bell, ordinario di sociologia a Harvard,
che sta ad indicare una società moderna che, giunta al culmine del processo di
industrializzazione, deve, per continuare a crescere, concentrare i propri sforzi verso la
produzione non più di beni materiali bensì di servizi immateriali. Servizi immateriali che si
identificano maggiormente nelle tecnologie informatiche che hanno cambiato sia il mondo
della produzione che quello dei consumi dando luogo ad un nuovo mercato
dell'informazione. Il carattere fondamentale del progresso scientifico-tecnologico non sta
solo nell'aver accesso alle informazioni e nel consultarle, selezionarle ed estrarle, ma
soprattutto nel saperle mettere in relazione tra loro ed elaborarle in maniera creativa per
restituire un prodotto innovativo. Tutto ciò fa dell'informazione una merce pregiata, una
risorsa strategica capace di incidere pesantemente sullo sviluppo e sugli assetti socioeconomici di ogni Paese.
Di conseguenza il valore dell’azienda non è più determinato solo dagli asset fisici ma
soprattutto dalle informazioni che possiede. I progressi della tecnologia informatica ed in
particolare dei database hanno permesso di gestire grandi quantità di dati da cui ottenere
sempre maggiori informazioni.
L'obiettivo del presente lavoro è la definizione di un sistema informatico costituito da
un modello di dati (DBMS) e da una piattaforma web, focalizzando sia le questioni teoriche
sia gli aspetti operativi.
La presente trattazione ha origine dall’esperienza professionale nel campo
dell’Information Technology e dalla collaborazione con SER and Practices Srl nella
2
realizzazione di un sistema informatico, “l’Efficientometro”. Si tratta di un sistema che ha
l’obiettivo di mettere in evidenza entrate e uscite degli enti pubblici. Uno strumento che ora
tocca soprattutto ai cittadini imparare ad utilizzare per giungere ad una cultura del controllo
diffuso sull’utilizzo del denaro pubblico. Ovviamente occorre ancora lavorare per rendere
l’efficientometro più efficace.
Nel presente lavoro si è partiti da una descrizione approfondita dei DBMS per mettere
in luce le caratteristiche fondamentali di questi strumenti di archiviazione dati. In particolare
sono stati messi a confronto il modello relazionale e non relazionale in quanto modelli
utilizzati nel progetto svolto in azienda. Successivamente si è passati all’analisi del caso
studio, l’Efficientometro, dove sono stati messi in luce gli elementi che compongono questo
sistema informatico: database e piattaforma web.
Ho cercato di unire le mie consolidate conoscenze di teoria e pratica dei Database e
del Project Management acquisite durante l'esecuzione del master, con le nuove conoscenze
acquisite in azienda riguardo definizione, reperimento, aggregazione e strutturazione dati ma
anche competenze riguardanti la sfera organizzativa; quindi organizzazione del lavoro,
rispetto delle scadenze e tutto ciò che serve per rispettarle.
3
1.1 DBMS
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. Urge
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à:
-
Un database è concepito per modellare un qualche aspetto del mondo reale,
che alcuni autori chiamano miniworld. Modifiche al miniworld sono
rispecchiate nel database;
-
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;
-
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.
4
1.2 Il modello relazionale
Il modello 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 (1970)1 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, numerate da 0 a 12:
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,
Edgar F. Codd nacque a Portland su un’isola nella contea del Dorset in Inghilterra e studiò matematica e
chimica all’Exeter College dell’Università di Oxford. Nel 1948 si trasferì a New York per lavorare per l’IBM
come programmatore matematico. Negli anni ’60-’70, mentre lavorava per IBM, creò il modello relazionale per
la gestione delle basi di dati, pubblicando “A Relational Model of Data for Large Shared Data Banks”, nel 1970.
1
5
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 (a) ha una sintassi lineare; (b) può
essere utilizzato sia interattivamente che all’interno di programmi; (c) 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
6
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 verranno trattati in questo elaborato (tra questi, 9 funzioni strutturali, 3 funzioni di
integrità e 18 funzioni di manipolazione).
7
1.3 Il modello 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 orizzontalmente2.
Molti di questi nuovi sistemi sono chiamati NoSQL data stores. 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:

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
Con il termine scalabilità orizzontale si intende l’abilità di distribuire i dati e il carico di queste semplici
operazioni su molti server, senza RAM o dischi di archiviazione condivisi.
2
8
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;

Abilità di replicare e distribuire i dati su più server;

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à;

Un uso efficiente di indici distribuiti e RAM per la memorizzazione dei dati;

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 Voldemort4 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.
Cassandra è un database management system non relazionale rilasciato con licenza open source e ottimizzato
per la gestione di grandi quantità di dati.
4
Project Voldemort ha come suo punto di forza la propensione allo scaling orizzontale in modo semplice,
veloce e performante. Questo database prevede anche la distribuzione di server in diversi data center dislocati
in qualsiasi parte del globo.
5
SimpleDB è un database presentato da Amazon, basato su servizi web a disposizione di chiunque voglia creare
siti dinamici di (relativamente) piccole dimensioni.
6
Apache CouchDB è scritto in Erlang ed è opensource, usa json per definire la struttura di un elemento, ed è
pensato per ridurre il gap tra database document oriented e database relazionali grazie alla creazione dinamica
di view in Javascript che permettono di visualizzare e manipolare dati in una classica struttura a tabelle.
3
9
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
Seth Gilbert and Nancy Lynch, “Brewer's conjecture and the feasibility of consistent, available, partition
tolerant web services”, ACM SIGACT News, Volume 33 Issue 2 (2002), pagg. 51-59.
7
10
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 nel 2007 pubblicò un WhitePaper8, 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 Vogels9 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
Dynamo: Amazon’s Highly Available Key-value Store, SOSP 2007, October 14-17, 2007, Stevenson,
Washington, USA.
9
Werner Hans Peter Vogels è il Chief Tecnology Officer e vice presidente di Amazon.com incaricato di
guidare l’innovazione tecnologica all’interno della società.
8
11
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.
12
1.3.1 Classificazione dei database non relazionali
I database NoSQL possono essere implementati seguendo differenti approcci a
seconda delle strutture dati con cui si rappresentano i record di dato.
Le principali categorie sono le seguenti quattro:
-
Column-oriented database: le informazioni sono memorizzate in colonne. Non c'è
bisogno di definire subito le colonne. Tipicamente sono usati nell’ambito della
memorizzazione distribuita dei dati;
-
Key/Values store: in questo caso i dati vengono immagazzinati in un elemento
che contiene una chiave assieme ai dati veri e propri. É quindi del tutto analogo
ad una Hash Table10. Questo metodo è il più semplice da implementare, ma
anche il più inefficiente se la maggior parte delle operazioni riguardano soltanto
una parte di un elemento;
-
Document store: è l’evoluzione del metodo key/value, rispetto ai normali
database relazionali invece che immagazzinare i dati in tabelle con dei campi
fissi, questi vengono messi in un documento (rappresentato in XML, JSON o
-
BSON) che può contenere illimitati campi di illimitata lunghezza, così se ad
esempio di una persona conosciamo solo nome e cognome, ma magari di
un’altra persona anche indirizzo, data di nascita e codice fiscale, si evita che per
il primo nominativo ci siano campi inutilizzati che occupano inutilmente
spazio;
-
Graph database: i dati vengono immagazzinati sotto forma di strutture a grafi,
rendendo più performante l’accesso a questi da applicativi orientati agli oggetti.
Tipicamente si usa nei social network.
I principali database non relazionali sviluppatisi in questi anni sono riportati nella figura
1, specificandone la categoria.
10
Una Hash table è una struttura dati usata per mettere in corrispondenza una data chiave con un dato valore.
13
Persistent
key/value
Volatile
Key/value
Graph
Column
Documents
neo4j
BigTable
(Google)
MongoDB
(BigTable)
Dynamo
(Amazon)
Memcached
FlockDB
(Twitter)
Hbase
(BigTable)
CouchDB
Voldemort
(Dynamo)
Hazelcast
InfiniteGraph
Cassandra
(Dynamo +
BigTable)
Ryak (Dynamo)
Redis
Hypertable
(BigTable)
Membase
(Memcached)
SimpleDB
(AmazonAWS)
Tokyo Cabinet
Figura 1: I principali database non relazionali suddivisi per categoria
14
1.3.2 Vantaggi e svantaggi dei db non relazionali
I database non relazionali, pur non essendo una novità assoluta, hanno registrato una
crescita esponenziale nel loro sviluppo e utilizzo negli ultimi mesi grazie al sempre più
crescente bisogno di scalare in orizzontale, dove i classici RDBMS (database relazionali)
presentano diverse limitazioni. Si pensi infatti ai sempre più in voga sistemi cloud dove i nodi
possono diventare veramente molti, gestire un RDBMS in un ambiente del genere risulta
complicato e la potenza computazionale non viene sfruttata in modo ottimale11.
Viste le problematiche di cui sopra, i giganti del web, che si trovano a dover gestire
database di dimensioni veramente imponenti, hanno sviluppato (o contribuito allo sviluppo)
vari NRDBMS (database non relazionali) con approcci leggermente diversi, ma tutti con gli
stessi principi di base, si raggruppano infatti sotto la dicitura di movimento NoSQL (Not
Only SQL).
Come in ogni nuovo modello nei database NoSQL si sono riscontrati sia dei vantaggi
che dei svantaggi. Tra i vantaggi si notano sicuramente le performance più alte per i tempi di
risposta, infatti nei database non relazionali un elemento contiene tutte le informazioni
necessarie e dunque non serve usare i dispendiosi “join” come invece avviene per i database
relazionali.
Inoltre la semplicità di questi database è uno degli elementi fondamentali, è proprio
questo che permette di scalare in orizzontale in maniera così efficiente, molti NRDBMS,
infatti, permettono di aggiungere nodi a caldo in maniera impercettibile dall’utente finale.
Infine scegliendo un database adatto alla mappatura più diretta alle object classes del
proprio applicativo si possono ridurre di molto i tempi dedicati allo sviluppo del metodo di
scambio dati tra il database e l’applicativo stesso (il cosiddetto object-relational mapping che
è invece necessario in presenza di database relazionali).
La semplicità di questi database comporta però anche degli svantaggi: mancando i
controlli fondamentali sull’integrità dei dati, il compito ricade quindi totalmente
sull’applicativo che dialoga con il database che ovviamente dovrebbe essere testato in modo
molto approfondito prima di essere messo in produzione. Per fare un esempio, se avessimo
un database dei clienti coi relativi ordini effettuati immagazzinati in elementi diversi, anche
Si pensi per esempio alla replicazione con MySQL dove il log binario costituisce già di per sé un enorme
calo prestazionale.
11
15
se è possibile definire una relazione attraverso le chiavi, in un database non relazionale alla
cancellazione di un cliente tutti gli ordini resterebbero comunque nel database, è quindi
l’applicativo che una volta impartito il comando di cancellazione dell’utente X deve anche
andare a cancellare tutti i relativi ordini, cosa che invece in un database relazionale è gestita
direttamente dal database stesso.
Altra pecca è la mancanza di uno standard universale, come può essere l’SQL. Ogni
database ha infatti le proprie API e il suo metodo di storing e di accesso ai dati. Pertanto il
passaggio da un database ad un altro non è sicuramente immediato, ma richiederebbe alcuni
cambi più o meno radicali da apportare all’applicativo; è quindi necessario tenere in
considerazione la cosa al momento del brainstorming iniziale.
Nonostante ciò, i database non relazionali, seppur non essendo la soluzione definitiva
al problema del salvataggio e recupero dei dati, visto l'avvento di Social Network e del cloud,
risultano la miglior soluzione in questi contesti dove ogni giorno bisogna salvare un numero
elevatissimo di dati e solo grazie alla scalabilità orizzontale dei database No-SQL e quindi
all'aggiunta di server facili da gestire, è possibile ottenere delle performance soddisfacenti,
molto migliori rispetto ai soliti database relazionali. Esempi di applicazioni che utilizzano
questo modello sono infatti Twitter, Facebook e Amazon.
16
1.4 Dbms relazionali e non: elementi a confronto
La conoscenza degli elementi di base di un database relazionale fa parte della cultura
tecnica di buona parte degli sviluppatori ed amministratori di sistema. Riepilogando
brevemente, tutto ruota attorno al concetto di tabella. Ne esisterà una per ogni tipo di
informazione da trattare, ed ognuna sarà costituita da colonne, una per ogni aspetto dei dati.
Una tabella dovrebbe avere una o più colonne che svolgono il ruolo di chiave primaria,
una sorta di indice che permette di riconoscere univocamente quella riga rispetto a tutte le
altre. Tra le tabelle di un database relazionale, inoltre, possono esistere alcune relazioni. Una
riga di una tabella A può fare riferimento ad un’altra riga di un’altra tabella B, e ciò può essere
espresso inserendo la chiave primaria della riga di B tra i dati di quella di B.
Il linguaggio fondamentale usato per impartire comandi ad un DBMS relazionale è
SQL ed una delle operazioni più comuni nonché più onerose in termini di risorse è il
cosiddetto JOIN, un incrocio di tabelle in relazione tra loro che permette di offrire un set di
dati unico con le informazioni complete.
Alla base di un database relazionale, c’è la progettazione della struttura interna, fatta di
tabelle e relazioni. Questo lavoro concettuale iniziale condizionerà lo svolgimento di ogni
operazione sui DB, dall’inserimento dei dati all’interrogazione, alla definizione dei JOIN.
La strutturazione rigida dei contenuti, tipica dei database relazionali fin qui descritti, è
un elemento assente nei database NoSQL, e proprio tale assenza è uno degli aspetti che
maggiormente ne hanno permesso il successo.
Le informazioni non troveranno più posto in righe elencate in tabelle, ma in oggetti
completamente diversi e non necessariamente strutturati, come ad esempio documenti
archiviati in collezioni. Su MongoDB, un database NoSQL basato sui documenti, il formato
del documento è una delle caratteristiche più rilevanti. Si tratta di BSON (Binary JSON), una
variante di JSON che include diversi tipi di dati.
Se, ad esempio, dovessimo inserire le informazioni di una persona (nome, cognome,
età) in un database relazionale, creeremmo una tabella con tre colonne. In JSON, gli stessi
dati verrebbero resi in un formato testuale come il seguente:
{“cognome”:”Rossi”, “nome”:”Carlo”, “età”:25}
17
Più oggetti JSON racchiusi tra parentesi quadre costituiscono invece una lista di
oggetti. Un oggetto JSON, complesso e articolato come vogliamo, rappresenta un
documento da inserire nel database. Non esisteranno più tabelle, ma collezioni di documenti.
La chiave primaria del documento è un campo denominato _id che, se non viene
fornito in fase di inserimento, verrà aggiunto automaticamente dal DBMS.
Nei DBMS NoSQL a documenti, è significativa l’assenza delle relazioni. I meccanismi
con cui vengono collegate le informazioni sono infatti due:
o Embedding: significa annidare un oggetto JSON all’interno di un altro. Questa
tecnica sostituisce molto spesso le relazioni 1-a-1 e 1-a-molti. È tuttavia
sconsigliabile utilizzarla quando i documenti (quello annidato e quello che lo
contiene) crescono di dimensione in maniera sproporzionata tra loro, oppure
se la frequenza di accesso ad uno dei due è molto minore di quella dell’altro;
o Referencing: somiglia molto alle relazioni dei RDBMS, e consiste nel fare in
modo che un documento contenga, tra i suoi dati, l’id di un altro documento.
Molto utile per realizzare strutture complesse, relazioni molti-a-molti oppure
casistiche non rientranti tra quelle consigliate per l’embedding al punto
precedente.
18
CAPITOLO 2: MYSQL E MONGODB
2.1 MySql
Mysql è un relational database management system (RDBMS) composto da un client
a riga di comando e un server. MySQL permette di creare, modificare e usare un database
sul tuo server. E' un software libero, rilasciato a doppia licenza compresa la GNU General
Public License ed è sviluppato per essere il più possibile conforme agli standard ANSI SQL
e ODBC SQL.
2.1.1 Caratteristiche
Scalabilità e flessibilità
MySQL è la soluzione più avanzata a livello di scalabilità, grazie alla sua capacità di
integrarsi con applicazioni le cui dimensioni non devono superare pochi MB, fino ad enormi
data warehouse contenenti terabyte di informazioni. La flessibilità di piattaforma è una
funzionalità chiave di MySQL, che è in grado di supportare Linux, UNIX e Windows.
Ovviamente, la natura open source di MySQL consente inoltre una personalizzazione totale
per chi desidera aggiungere requisiti unici al server database.
Prestazioni elevate
L’eccezionale architettura storage-engine12 consente di configurare il server di MySQL
per applicazioni specifiche, ottenendo prestazioni finali incredibili. Sia che l’applicazione sia
un sistema di elaborazione transazionale ad alta velocità o un sito web che gestisce miliardi
di interrogazioni al giorno, MySQL è in grado di soddisfare le aspettative di qualsiasi sistema
a livello di prestazioni. Grazie alle utility di caricamento dati ad alta velocità, le cache
specializzate, gli indici full text ed altri meccanismi di aumento delle prestazioni, MySQL
offre gli strumenti giusti per i moderni sistemi aziendali di importanza critica.
12
Separa il query processing dai task di memorizzazione e ricerca dati.
19
Alta disponibilità
L’assoluta affidabilità e la costante disponibilità sono i punti di forza di MySQL e i
clienti si affidano a MySQL per garantire l’operatività 24 ore su 24. MySQL offre una varietà
di opzioni ad alta disponibilità, dalle configurazioni di replicazione master/slave ad alta
velocità, ai server cluster specializzati con failover istantaneo, alle soluzioni ad alta
disponibilità di terze parti per il server di database MySQL.
Solido supporto delle transazioni
MySQL offre uno dei motori database transazionali più potenti disponibili sul mercato.
Le funzionalità includono il supporto completo per transazioni ACID13, lock a livello di riga,
gestione delle transazioni distribuite e supporto per transazioni multi versione in cui chi legge
non blocca mai chi scrive e viceversa. La completa integrità dei dati è garantita anche
dall’integrità referenziale controllata dal server, dai livelli di isolamento delle transazioni
specializzati e dall’individuazione istantanea dei deadlock.
Punti di forza per Web e Data Warehouse
MySQL è lo standard di fatto per i siti web con volumi di traffico elevati, grazie al suo
query engine ad alte prestazioni, alla capacità di inserimento dei dati estremamente veloce e
al supporto delle funzioni web specializzate, come ad esempio le ricerche full text rapide.
Questi stessi punti di forza valgono anche per gli ambienti di data warehousing in cui MySQL
deve gestire terabyte di dati per singoli server o per architetture di scale-out. Altre
caratteristiche, come le tabelle in memoria principale, gli indici B-tree, gli indici hash e le
tabelle di archivio compresse, che riducono le necessità di memorizzazione fino all’80%,
rendono MySQL una soluzione unica, sia per le applicazioni web, sia per le applicazioni di
business intelligence.
13
Atomic, Consistent, Isolated, Durable.
20
Elevata protezione dei dati
La protezione dei dati aziendali rappresenta la priorità numero uno dei responsabili dei
database, quindi MySQL offre eccezionali caratteristiche per la sicurezza, che garantiscono
la totale protezione dei dati. Per ciò che riguarda l’autenticazione del database, MySQL offre
potenti meccanismi per assicurare che soltanto gli utenti autorizzati possano accedere al
server di database, con la possibilità di bloccare gli utenti fino al livello della macchina client.
Oltre a ciò, il supporto SSH e SSL garantisce che le connessioni siano sicure. Un sistema
granulare di gestione dei privilegi permette agli utenti di vedere solo i dati per i quali sono
autorizzati, mentre le potenti funzioni di crittografia e decifratura dei dati garantisce che i
dati sensibili siano protetti e non possano essere visualizzati da coloro che non sono
autorizzati. Per finire, le utility di backup e ripristino fornite da MySQL e da software di terze
parti consentono di eseguire il backup fisico e logico completo, così come il ripristino
completo e point-in-time.
Sviluppo completo di applicazioni
Uno dei motivi per cui MySQL è il database open source più diffuso al mondo è che
fornisce supporto completo per le esigenze di sviluppo di tutte le applicazioni. All’interno
del database è possibile trovare supporto per stored procedure, trigger, funzioni, viste,
cursori, standard SQL ANSI e altro ancora. Per le applicazioni integrate sono disponibili
librerie plug-in per espandere l'utilizzo del database MySQL a pressoché tutte le applicazioni.
MySQL fornisce inoltre connettori e driver (ODBC, JDBC, ecc.) che consentono a tutti i tipi
di applicazioni di utilizzare MySQL quale server di gestione dei dati. Non importa che si tratti
di PHP, Perl, Java, Visual Basic o .NET: MySQL offre agli sviluppatori di applicazioni tutto
ciò di cui hanno bisogno per realizzare sistemi informativi basati su database.
Facilità di gestione
I tempi necessari per iniziare a usare MySQL sono incredibilmente ridotti; il tempo
medio che trascorre dal download del software al completamento dell’installazione è inferiore
ai 15 minuti. Ciò vale per qualsiasi piattaforma, sia essa Microsoft Windows, Linux,
21
Macintosh o UNIX. Una volta installato, funzionalità indipendenti come l’espansione
automatica dello spazio, il riavvio automatico e le modifiche di configurazione dinamiche
facilitano il lavoro degli amministratori di database. MySQL offre inoltre una suite completa
di strumenti di migrazione e gestione grafici, che consente ai DBA di gestire, risolvere e
controllare le operazioni di più server MySQL da una singola stazione di lavoro. Sono inoltre
disponibili molti strumenti software di terze parti per MySQL, per gestire attività che vanno
dalla progettazione dei dati e l’ETL, alla completa amministrazione del database, alla gestione
dei job, al monitoraggio delle prestazioni.
La libertà dell'open source e il supporto 24x7
Molte aziende esitano ad adottare solo software open source perché credono di non
poter ricevere il tipo di supporto o di servizi professionali offerti dal software di tipo
proprietario, per garantire il successo delle loro applicazioni di importanza chiave. Un altro
aspetto riguarda la questione degli indennizzi. Queste preoccupazioni possono essere
ignorate grazie a MySQL, che attraverso MySQL Enterprise offre indennizzi e supporto
completo 24 ore su 24. MySQL non è un progetto open source tipico, poiché tutto il software
è di proprietà di Oracle ed è supportato da Oracle; è quindi disponibile un modello di costi
e supporto in grado di offrire una combinazione unica di libertà open source e software
supportato.
Costo totale di proprietà più basso
Migrando le attuali applicazioni basate su database a MySQL, oppure utilizzando
MySQL per i nuovi progetti di sviluppo, le grandi aziende stanno ottenendo risparmi enormi.
Grazie all’uso del server di database MySQL e delle architetture distribuite, che utilizzano
hardware di largo consumo a basso costo, le aziende scoprono di poter raggiungere
incredibili livelli di scalabilità e prestazioni, il tutto ad un costo estremamente inferiore a
quello dei software scale-up di tipo proprietario. Inoltre, l’affidabilità e la gestibilità di MySQL
consentono agli amministratori di database di non sprecare tempo nella risoluzione di
22
problemi legati alle prestazioni e ai tempi di fermo, ma di concentrarsi invece su attività di
livello più strategico che interessano gli aspetti che danno più valore al business.
MySQL è diventato il database open source più conosciuto al mondo grazie a
prestazioni veloci, elevata affidabilità e facilità d'uso. È utilizzato in ogni continente, anche in
Antartide, da singoli sviluppatori Web e da molte delle aziende più grandi e in più rapida
espansione del mondo, tra cui leader di settore come Yahoo!, Google, Alcatel-Lucent, Nokia,
YouTube e Zappos.com, per risparmiare tempo e denaro potenziando siti Web con volumi
d'accesso elevatissimi, sistemi business-critical e pacchetti di soluzioni software.
MySQL non è soltanto il database open source più famoso al mondo. È diventato
anche il database utilizzato per una nuova generazione di applicazioni basate sullo stack
LAMP (Linux, Apache, MySQL, PHP / Perl / Python).
23
2.2 Mongo DB
MongoDB14 è un database sviluppato in C++, open-source, document-oriented,
scalabile e altamente performante. Esso è stato realizzato in maniera tale da avere alte
prestazioni in lettura e scrittura. Le letture più consistenti infatti possono essere distribuite
in più server replicati, le interrogazioni sono più semplici e veloci grazie all'assenza di join e
l'approccio ai documenti rende possibile la rappresentazione di relazioni gerarchiche
complesse attraverso documenti nidificati e array.
Ecco le sua caratteristiche distintive:
 Database document-oriented: i dati vengono archiviati sotto forma di
documenti in stile JSON con schema dinamici, secondo una struttura molto
semplice e potente;
 Supporto completo agli indici: indicizzazione di qualsiasi attributo;
 Replicazione: facilità nella replicazione dei dati attraverso la rete e alta
scalabilità;
 Sharding: scalabilità orizzontale senza compromettere nessuna funzionalità;
 Query document-based.
Database document-oriented
Questo modello di database eredita il meccanismo di storage dal paradigma docoriented che consiste nel memorizzare ogni record come documento che possiede
caratteristiche predeterminate. Si può aggiungere un numero qualsiasi di campi con una
qualsiasi lunghezza.
Nei doc-oriented si segue una metodologia differente rispetto al modello relazionale:
si accorpano quanto più possibile gli oggetti, creando delle macro entità dal massimo
contenuto informativo. Questi oggetti incorporano tutte le notizie di cui necessitano per una
determinata semantica.
Pertanto MongoDB non possiede uno schema e ogni documento non è strutturato, ha
solo una chiave obbligatoria: _id, la quale serve per identificare univocamente il documento;
Deriva da “humongous”, un termine slang con il significato di enorme, immenso. Si riferisce alla capacità di
immagazzinare una grande mole di dati.
14
24
essa è comparabile, semanticamente, alla chiave primaria dei database relazionali.
Supporto completo agli indici
MongoDB utilizza le tecniche di indicizzazione; solitamente il campo _id è indicizzato
automaticamente, inoltre conviene indicizzare anche quei campi dove è tipico eseguire
ricerche o sui quali sono definiti ordinamenti. MongoDB, proprio per favorire
l'indicizzazione, fornisce strumenti in grado di suggerire su quali campi sia opportuno
definire indici.
Per usarli con buoni risultati conviene privilegiare applicazioni read- intensitive, ovvero
collezioni con un alto rapporto letture/scritture per incrementare le letture rispetto alle
scritture.
Nonostante siano molto utili vanno utilizzati solo se il campo è realmente selettivo in
quanto indicizzare dei campi comporta sicuramente dei costi. Il tempo di scrittura infatti
aumenta con l'aumentare degli indici utilizzati, questo perché una modifica o un'aggiunta di
dati può comportare la modifica di molti indici.
Dunque affinché l'uso degli indici risulti veramente performante è importare fare una
scelta ragionata considerando il tipo di interrogazioni che verranno effettuate sul sistema e
quanto spesso quei dati verranno modificato o subiranno delle aggiunte.
In poche parole un indice è una struttura dati che cataloga le informazioni dei campi
specificati nei documenti di una collezione. Attraverso questi indici risulta più facile e meno
dispendioso ordinare i dati di una query e grazie ad essi si velocizzano i tempi di risposta in
quanto per certe ricerche mirate non vengono più scannerizzati tutti i documenti ma si salta
direttamente ai documenti che rispettano la clausola della query.
La maggior parte degli indici seguono la struttura ad albero, B-Tree, grazie alla quale
con un semplice confronto del nodo padre si sceglie se considerare il braccio destro e sinistro
scartando ogni volta un numero consistente di confronti.
Una volta definito un indice su uno o più campi sarà il sistema stesso a mantenere
aggiornato l’indice.
E' possibile definire diverse tipologie di chiavi:
 Chiavi semplici: indicizzano un solo campo di una collezione (insieme di
documenti con le stesse caratteristiche o simili, una sorta di tabella dei database
relazionali);
25
 Chiavi composte: indicizzano due o più campi di una collezione;
 Chiavi documento: considerano come campo dell'indice un campo che
contiene oggetti (utili per query che non richiedono interrogazioni ordinate);
 Chiavi array: considerano come campo dell'indice un campo che contiene un
array.
E’ possibile inoltre definire un indice sparso su un determinato campo, così facendo
nell’indice saranno compresi solo gli oggetti che presentano il campo indicato, mentre quelli
che non lo presentano verranno filtrati.
Caratteristica peculiare di MongoDB è la possibilità di utilizzare indici geospaziali
bidimensionali i quali ci permettono di interrogare il sistema con query basate sulla posizione.
Replicazione
La replicazione è utilizzata per rimediare e prevenire malfunzionamenti. Essa infatti
comporta ad una ridondanza dei documenti, la quale ritorna molto utile in caso di perdita
dei dati. In poche parole consiste nel salvare più copie dei documenti in server diversi in
modo tale di avere dei dati sicuri anche se accorrono degli errori in uno o più server.
Essenzialmente ci sono due tipi di replicazione: la Master-slave semplice e la ReplicaSet. La prima, come suggerito dal nome, presenta un’unità centrale master che è sempre
aggiornata, la quale periodicamente sincronizza tutti gli altri nodi (slave), che risultano quindi
dipendenti ad essa. In questo modo in ambito distribuito si assicura una consistenza assoluta
sul master ed una consistenza relativa sullo slave, nel senso che prima o poi lo slave risulterà
sincronizzato con il master. In caso di malfunzionamento di un nodo, il ripristino deve essere
eseguito manualmente.
La tecnica Replica-Set o insieme di replicazione è una elaborazione del modello MasterSlave che aggiunge il ripristino automatico dopo un malfunzionamento ed il supporto di
cluster di server con membri primari (master) e secondari (slave).
Sharding
Lo sharding è la tecnica usata per partizionare orizzontalmente un database. Mentre
nel partizionamento verticale, chiamato normalizzazione si punta a separare ed isolare
26
semantiche omogenee splittando una tabella in più tabelle dividendo i campi della tabella
stessa, nel partizionamento orizzontale lo split è realizzato in modo da ottenere due o più
insiemi di tuple da sistemare in due o più tabelle.
In MongoDB le tecniche di Sharding estendono proprio il partizionamento orizzontale
permettendo agli shard, cioè alle partizioni ottenute dal database di partenza, di essere slegati
completamente gli uni dagli altri. Questa separazione è possibile in quanto ogni shard può
vivere in una istanza dello schema logico totalmente separato e può essere ospitato da un
server fisico diverso da quello degli altri shard. Pure il data center può essere uno qualsiasi,
addirittura trovarsi in un altro continente. In poche parole ogni shard non dipende dal sistema
logico e fisico sottostante.
Questa tecnica comporta ovviamente dei vantaggi: essendo ridotto il numero di righe
di ogni tabella coinvolta e dunque pure le dimensioni degli indici risultano ridotte, le ricerche
sono più veloci e più efficienti. Si ottengono performance superiori grazie anche al
parallelismo reso possibile dalla possibilità di posizionare ogni shard su hardware differenti.
Inoltre la segmentazione dei dati può seguire in maniera più naturale gli aspetti del mondo
reale che possono coinvolgere spazi completamente separati.
MongoDB prevede un servizio automatico di sharding, grazie al quale una volta
impostata la chiave sulla quale eseguire il partizionamento orizzontale, il sistema segmenta
automaticamente la collezione. Le collezioni che vengono così a crearsi sono strutturalmente
identiche: le dimensioni in termini di oggetti e occupazione di spazio sono bilanciate. Si
generano delle shard key ovvero delle chiavi di frammentazione, partendo dai chunk creati
dai cluster che contengono i dati.
Tutti i metadati si memorizzano in un server di configurazione e si creano dei nodi
router che propagano le richieste ai nodi. Quando ci sarà una richiesta si interroga un nodo
che possiede una tabella con una mappa del sistema per sapere a quali shard rivolgersi per
ottenere gli oggetti richiesti.
Query document-based
Una delle più importanti caratteristiche di MongoDB è la sua capacità di supportare
query dinamiche ad hoc, le quali, essendo caratteristiche dei database relazionali, ci
permettono con facilità di migrare dati da un database relazionale verso un database di MongoDB trasformando in pochi passaggi query SQL in query del linguaggio document-based.
27
Per recuperare i dati in MongoDB esistono varie query-object che rispecchiano i
costrutti principali delle query SQL.
Tra i principali ricordiamo:
o
Il selettore di campo, corrispondente allo SELECT in SQL, il quale recupera un
sottoinsieme dei campi della nostra collezione. (In MongoDB, differentemente a quando
accade in SQL, il campo _id è sempre ritornato.);
o
La selezione, corrispondente alla WHERE in SQL, la quale indica attraverso
dei criteri quali documenti recuperare in una collezione. Come in SQL vengono utilizzati
operatori condizionali (and, or, nor, in, nin, all, exists, mod, size, type, ne), espressioni
regolari, valori in array, valore negli oggetti embedded, meta operatori (not) e l'operato- re di
aggregazione (group). Il processo di selezione potrebbe causare un overhead per la ricerca di
documenti nel database, per questo viene utilizzata la funzione “Map- Reduce”: prima di
tutto per ogni elemento viene invocata la funzione “Map”, che produce delle coppie chiavevalore da passare alla successiva funzione e in seguito viene eseguita la funzione “Reduce”,
che aggrega i risultati ricevuti e restituisce la nuova collezione;
o
Gli ordinamenti, i quali, in maniera analoga alla clausola ORDER BY in SQL,
specificando su quale campo eseguire l'ordinamento, ritornano risultati ordinati in maniera
crescente o decrescente;
o
Skipe limit, i quali permettono una paginazione dei risultati.
E' importante sottolineare come i risultati di una query vengano gestiti: MongoDB usa
tecniche di cursori, i quali sono usati per recuperare iterativamente tutti i documenti ritornati
dalla query eseguita.
2.2.1 La nuova filosofia di MongoDB
Come possiamo ben capire dalle sue caratteristiche, MongoDB, essendo un database
NoSQL, non si preoccupa tanto di soddisfare le proprietà ACID tipiche dei database
relazionali, piuttosto si concentra su aspetti più performanti per quanto riguarda la velocità,
la flessibilità e la facilità d'uso del database.
Esso, organizzando i dati in documenti schemaless, riesce a rispondere alle
interrogazioni con tempi molto inferiori rispetto ai database relazionali dove i dati sono
separati in tabelle multiple e necessitano quindi di join per raggruppare i risultati.
Senz'altro anche l'approccio alla scalabilità orizzontale attraverso lo sharding è un altro
28
punto a favore per la velocità e le prestazioni del database. Lo sharding consente infatti di
gestire più carico di lavoro senza richiedere l'utilizzo di macchine potenti più grandi e quindi
più costose e riesce ad aumentare la capacità senza tempi di inattività, sfaccettatura molto
importante nel web che, a causa dell'aumento di carico dei dati, può essere costretto a
disattivare il servizio per lunghi periodi di manutenzione.
Per quanto riguarda la flessibilità, essa è data dal tipo di formato utilizzato nei
documenti: JSON. Formato che si adatta perfettamente ai vari linguaggi di programmazione
e non avendo uno schema fisso permette di modificare e ampliare il modello di dati in
maniera molto semplice e veloce.
Infine MongoDB punta alla semplicità: è facile da installare, configurare, mantenere e
usare. A tal fine, fornisce poche opzioni di configurazione e cerca automaticamente, quando
possibile, di fare la “cosa giusta” permettendo agli sviluppatori di concentrarsi sulla creazione
dell’applicazione piuttosto che perdere tempo in oscure configurazioni di sistema.
29
2.3 Comparazione tra MongoDB e MySQL
In questo paragrafo, si fornisce una comparazione tra MongoDB e il database
relazionale MySQL. Vengono analizzate le prestazioni di inserimento e interrogazione dei
due database per fornire una serie di risultati che andranno a svelare eventuali punti di forza
e debolezza di entrambi. L’analisi è stata estratta da una tesi di laurea dell’Università di
Padova: “Analisi delle performance dei database non relazionali”15.
L’analisi di benchmarking è stata condotta esaminando, prima di tutto, le prestazioni
di inserimento attraverso diversi metodi di inserimento: ad esempio, utilizzando i prepared
statement per MySQL o i bulk insert per MongoDB. In secondo luogo, si sono testate le
prestazioni dei due metodi interrogazione. In particolare, si sono testate le prestazioni del
map-reduce di MongoDB e poi è stata scritta l’interrogazione speculare in SQL da essere
applicata a MySQL.
NOTA. La macchina su cui sono stati eseguiti i test è un portatile da 4 Giga di RAM
con processore Duo 2 Core.
Su un pc a 32 bit, ecco i tempi di risposta delle query di inserimento su MongoDB e
MySQL, a parità di dati.
Dati inseriti
Query MongoDB
100
78 ms
500
187 ms
1.000
280 ms
5.000
1.19 sec
10.000
2.28 sec
50.000
11.23 sec
100.000
22.35 sec
200.000
45.97 sec
Query MySql
0.05 sec
0.08 sec
0.22 sec
0.91 sec
1.75 sec
35.46 sec
1 min 42.01 sec
3 min 12.33 sec
Su un pc a 64 bit, ecco i tempi di risposta delle query di inserimento su MongoDB e
MySql, a parità di dati.
15
Tesi di laurea a cura di Merelli Luca, Padova 21 settembre 2012, www.tesi.cab.unipd.it.
30
Dati inseriti
Query MongoDB
Query MySql
100
109 ms
0.06 sec
500
202 ms
0.09 sec
1.000
374 ms
0.12 sec
5.000
1.79 sec
0.23 sec
10.000
3.48 sec
0.41 sec
50.000
17.52 sec
2.01 sec
100.000
34.30 sec
9.73 sec
200.000
58.12 sec
14.76 sec
300.000
1 min 43.12 sec
32.23 sec
500.000
2 min 49.53 sec
2 min 16.33 sec
1.000.000
5 min 51.56 sec
5 min 21.05 sec
2.000.000 13 min 56.06 sec
21 min 10.33 sec
3.000.000 19 min 54.55 sec 1 h 2 min 23.69 sec
Dai risultati ottenuti evince che MongoDB è sicuramente più performante di MySQL
per l’inserimento e l’interrogazione di grosse quantità di dati. Su piccole quantità di dati,
presenta una latenza trascurabile, guadagnando esponenzialmente nei tempi quando si
interrogano milioni di documenti/record.
Tuttavia, si nota anche che al crescere dei dati, le operazioni di lettura e inserimento di
MongoDB subiscono un notevole peggioramento delle prestazioni.
Si può concludere che MongoDB risulta essere una valida alternativa ai database
relazionali grazie all’innovativo modello dei dati basato sui documenti che fornisce una
maggiore interazione con i linguaggi di programmazione orientati agli oggetti, all’agile e
semplice linguaggio di interrogazione e alla possibilità di essere facilmente scalabile.
MongoDB è, inoltre, in grado di fornire ottime prestazioni in scrittura e in lettura
addirittura migliori rispetto ai database relazionali.
31
CAPITOLO 3: CASO STUDIO EFFICIENTOMETRO
Introduzione
Finora abbiamo analizzato i concetti teorici inerenti allo studio dei database. Ora
passiamo al caso pratico inerente al lavoro di stage svolto presso la società Software
Engineering Research & Practices (in sigla SER&Practices) Spin-off dell’Università degli
Studi di Bari “Aldo Moro”.
Il lavoro ha previsto un'attività tecnico-scientifica volta alla produzione di un sistema
informatico utilizzabile come supporto al processo di efficientamento della spesa pubblica,
in grado di reperire, aggregare e rendere fruibili via web i dati finanziari open degli enti
pubblici in maniera chiara e user-friendly; di dotare i cittadini di strumenti partecipativi al
fine di incoraggiarli al controllo civico e alla collaborazione diretta nella vita amministrativa
di comuni, province, ecc.
Tale sistema si compone di due elementi: database e piattaforma web.
Per quanto riguarda il database, il sistema si basa su due macro categorie di dati:
o
SIOPE (la fonte è rappresentata da Siope, sistema informativo delle
operazioni degli enti pubblici di proprietà della Banca d'Italia16);
o
MEGAFILE (le fonti da cui sono prelevati i dati sono Istat, Finanza e
controllo, Contoannuale e Finanza locale17).
Per quanto riguarda la piattaforma, il sistema è stato pensato per due macrocategorie
di sistemi:
16
17

Desktop;

Smartphone e tablet.
www.siope.it
www.istat.it; www.finanzalocale.interno.it; www.contoannuale.tesoro.it;
32
3.1 Database dell’efficientometro
Per il popolamento dei database (MongoDB e MySql) sono stati realizzati dei web
crawler in grado di recuperare automaticamente i dati necessari per popolare il database del
sistema Efficientometro. Più in particolare è stato realizzato il crawler per il sito
MagellanoPA18. Tale crawler è servito per recuperare in riferimento a comuni e province, i
link alle sezioni:
o
Amministrazione trasparente;
o
Enti controllati;
o
Società partecipate;
o
Rappresentazione grafica.
E' stato poi necessario realizzare un web scraping da Finanza Locale19 per recuperare
il debito a lungo termine.
Per le altre tipologie di dati è stata effettuata una procedura di import dei dati.
Come accennato sopra, l’Efficientometro ha visto la compresenza di due database,
SIOPE e MEGAFILE. Per quanto riguarda Siope, è stato creato un database non relazionale,
per la precisione MONGODB, in grado di gestire non solo le enormi quantità di dati ma di
replicarli su più macchine per ottemperare al problema della memoria e per ottenere una
maggiore velocità di lettura/scrittura.
Per quanto riguarda Megafile, è stato creato un database relazionale (MYSQL) in grado
di organizzare i dati in insiemi di record a struttura fissa, in modo da creare dei sistemi
semplici ed efficienti per rappresentare e manipolare dati.
18
19
www.magellanopa.it
www.finanzalocale.interno.it
33
3.2 Principi di progettazione
La progettazione di un database è un processo nel quale viene scelta la migliore
rappresentazione della realtà che si vuole descrivere, della natura dei dati e dei requisiti che
l’applicazione deve soddisfare.
I principi di progettazione di un database relazionale sono ben stabiliti e seguono una
serie di regole ben precise. Il modello relazionale si basa su due concetti, relazione e tabella,
di natura diversa ma facilmente riconducibili l’uno all’altro. La nozione di relazione proviene
dalla matematica, in particolare dalla teoria degli insiemi, mentre il concetto di tabella è
semplice e intuitivo. Le tabelle risultano naturali e comprensibili anche per gli utenti finali,
d’altra parte la disponibilità di una formalizzazione semplice e precisa ha permesso anche
uno sviluppo teorico a supporto del modello.
Inoltre la progettazione di una base di dati segue un determinato procedimento in
modo da garantire principalmente la generalità rispetto alle applicazioni e ai sistemi, la qualità
del prodotto in termini di correttezza, completezza e efficienza rispetto alle risorse impiegate
e la facilità d’uso dei modelli di riferimento.
Nell’ambito delle basi di dati relazionali si è consolidata negli anni una metodologia di
progetto che ha dato prova di soddisfare le proprietà descritte. Tale metodologia è articolata
in tre fasi: la progettazione concettuale, il cui scopo è di rappresentare le specifiche informali
della realtà di interesse; la progettazione logica, che consiste nella traduzione dello schema
concettuale ottenuto dalla fase precedente nel modello di rappresentazione dei dati adottato
dal sistema di gestione di base di dati; la progettazione fisica nella quale lo schema logico
viene completato con la specifica dei parametri fisici di memorizzazione.
Invece MongoDB manca di regole per la progettazione, in quanto non applica alle
collezioni e ai documenti nessun tipo di schema in quanto utilizza prevalentemente uno
schema libero. Pertanto la progettazione di uno schema con MongoDB è spesso il risultato
di una profonda conoscenza del database che si sta utilizzando, dei requisiti database che si
sta utilizzando, dei requisiti che l’applicazione deve soddisfare, del tipo di dati che si andranno
a memorizzare e delle operazioni e aggiornamenti che si dovranno applicare ai dati
memorizzati. Da questo si evince che in MongoDB lo schema non è solo in funzione dei dati
che si andranno a memorizzare ma bisogna anche focalizzare l’attenzione su come i dati
verranno utilizzati dalle applicazioni.
Nonostante la mancanza di regole precise ci sono delle linee guida che possono servire
34
allo scopo di progettare uno schema che soddisfi le nostre esigenze.
Il primo aspetto da considerare è la struttura di un documento di una collezione.
In MongoDB non c’è una specifica dichiarazione dei campi all’interno dei documenti
di una collezione, in quanto MongoDB non richiede che i documenti abbiano la stessa
struttura. Tuttavia nella pratica la maggior parte delle collezioni sono omogenee in modo da
facilitarne l’utilizzo sia da parte di progettisti e programmatori ma anche da parte di utenti
casuali.
Una domanda chiave che ci si deve porre quando si progetta uno schema con
MongoDB è quando incorporare documenti all’interno di altri, embed, e quando collegare i
documenti, link. L’incorporamento è l’annidamento di oggetti e array all’interno di un
documento BSON. I link sono riferimenti tra documenti. Le operazioni all’interno di un
documento sono facili da eseguire e avvengono sul lato server, invece i riferimenti devono
essere trattati sul lato client e l’applicazione effettua operazioni su documenti riferiti
emettendo interrogazioni dopo che il documento è stato ritornato dal server.
In generale c’è una semplice regola che funziona per la maggior parte degli schemi ma
che non deve essere presa come assoluta: incorporare quando gli oggetti figli appaiono
sempre nel contesto del genitore, in caso contrario memorizzare gli oggetti figli in una
collezione separata.
Prendiamo come esempio un’applicazione che debba memorizzare dei post pubblicati
su un sito web e i relativi commenti ai post. La scelta tra incorporare o linkare dipende
dall’applicazione. Se i commenti appaiono sempre all’interno di un post e non c’è bisogno di
ordinarli in un modo arbitrario, come ad esempio per data o per importanza, incorporare i
commenti all’interno di un documento post magari sotto forma di un array di documenti è
un’opzione valida in quanto fornisce prestazioni migliori in lettura. Se invece l’applicazione
deve essere in grado di mostrare i commenti dal più recente senza considerare su che post i
commenti appaiano, allora è meglio usare i riferimenti e memorizzare i commenti in una
collezione separata.
Altro aspetto da considerare sono le operazioni atomiche che l’applicazione deve
eseguire, l’aspetto chiave in termini di progettazione di schema è che il campo di applicazione
delle proprietà atomiche è il documento, pertanto dobbiamo assicurare che tutti i campi
rilevanti per le operazioni atomiche siano nello stesso documento.
Di seguito viene presentato un elenco delle opportune regole da seguire durante la
progettazione di uno schema:

Gli oggetti che sono di livello superiore come importanza in genere hanno la
35
loro collezione;

Relazioni molti a molti generalmente sono rappresentate con collegamenti;

Collezioni che contengono pochi oggetti possono tranquillamente esistere
come collezioni distinte, in quanto l’intera collezione è rapidamente memorizzata nella cache
del server dell’applicazione. E’ più difficile ottenere un livello di visualizzazione per
documenti incorporati, per ottenere un’operazione del genere si deve utilizzare il map-reduce;

Se le performance sono un problema, incorporare.
36
3.3 Siope
Siope è un database non relazionale in grado di scalare orizzontalmente semplici
operazioni su più server, replicare e distribuire i dati su più server; non è basato sulle proprietà
ACID, è quindi in grado di ottenere prestazioni elevate e maggiore scalabilità;
Inoltre grazie ad esso è possibile usare in modo efficiente gli indici distribuiti e la RAM
per la memorizzazione dei dati. Infine, ulteriore vantaggio, è quello di aggiungere
dinamicamente nuovi attributi ai record di dati.
Sono stati raccolti i dati relativi alle entrate e uscite degli enti pubblici20, per il periodo
temporale 2009–2014.
Al fine di raggrupparli sono stati realizzati i seguenti indicatori:
1.
Spesa complessiva
o Gestione corrente;
o Mutui;
o Investimenti;
o Principali esborsi.
2.
Totale entrate
o Tasse;
o Servizi, fitti e multe;
o Sovvenzioni da Stato;
o Entrate una tantum;
o Principali entroiti.
E’ stato inoltre realizzato un sistema automatico dei dati presenti in Siope. In tal modo
nella versione successiva alla prima sarà possibile aggiornare i dati Siope senza che sia
necessario l’intervento umano e a scadenze prestabilite21.
20
21
In particolare per Comuni, Province; lavori in corso per le Regioni.
Ad esempio 10 gennaio, 30 gennaio, 2 mesi, ecc.
37
3.4 Megafile
Megafile è un database relazionale, dove i dati sono organizzati tramite relazioni.
Informalmente ogni relazione è rappresentata da una tabella. Si tratta quindi di database
relazionale in grado di organizzare i dati in insiemi di record a struttura fissa, in modo da
creare dei sistemi semplici ed efficienti per rappresentare e manipolare dati.
Per questa tipologia di database sono stati raccolti dati relativi a dipendenti pubblici e
altri indicatori quali debito a lungo termine, redditi e raccolta differenziata, per gli anni 20092014.
Sono stati realizzati pertanto i seguenti indicatori:
1.
Dipendenti pubblici:
o Abitanti per dipendenti;
o Impiegati per dirigente;
o Paga impiegati;
o Paga dirigenti;
o Assenze per malattia.
2.
Altri indicatori:
o Debito a lungo termine;
o Reddito per dichiarante;
o Reddito per abitante;
o Raccolta differenziata.
38
3.5 Aggregazione dei dati
I dati sono stati aggregati per voci di mastro per facilitare la lettura e l’interpretazione
degli stessi affinchè i cittadini potessero essere più consapevoli dei meccanismi alla base del
funzionamento della pubblica amministrazione e dei suoi costi.
Obiettivo ultimo è appunto quello di rafforzare di trasparenza, partecipazione e
accountability al fine di contribuire al miglioramento della società.
39
3.6 Piattaforma Web
Il sistema è stato pensato per due macrocategorie di sistemi:
 Desktop;
 Smartphone e Tablet.
E' stato dapprima realizzato un sistema web responsive ovvero un sistema in grado di
adattare la presentazione dei dati ai differenti dispositivi utilizzabili in modo automatico. La
memoria e la potenza di calcolo di questi dispositivi è limitata e pertanto la realizzazione di
una applicazione per questi dispositivi richiede maggiori tempi di realizzo.
Per ogni sistema il layout assume connotati diversi per efficientare l'usabilità dei sistemi
e la fruitabilità delle informazioni.
Il sistema software descritto è in fase di aggiornamento e di completamento.
La seguente figura mostra il layout del sistema web descritto.
40
3.7 Ulteriore sviluppo
Un passo successivo ha riguardato lo studio delle Regioni e in particolare lo studio
degli indicatori che potessero rappresentare al meglio la situazione delle stesse. Partendo
dall'analisi fatta per comuni e province, si è proceduto con lo studio delle voci di spesa di
due regioni italiane: la Puglia e la Sicilia. Due realtà molto diverse non solo perché
caratterizzate da statuti diversi (rispettivamente ordinario e speciale22) ma anche per i
differenti motivi di spesa.
E' stato quindi utilizzato un metodo di ricerca induttivo, procedimento logico che
ci ha permesso di ricavare dall'osservazione puntuale dei dati dei principi generali in essi
impliciti, fino ad arrivare alla costruzione di uno schema generale che potesse essere utile
alla costruzione e importazione dei dati sul database non relazionale.
Lo scopo principale è quello di rimodellare i dati grezzi degli attributi, organizzarli
ed aggregarli al fine di ottenere una presentazione comprensibile anche dall’utente non
tecnico.
Di seguito uno stralcio di intestazione dello schema.
ID VOCE BUROCRATICA IMPORTO ID MASTRO MASTRO ID MASTRONE
Spese per organi
1101istituzionali
286.538,42
201
Retribuzioni
101
Competenze fisse per il
personale a tempo
1211indeterminato
71.111.285,82
201
Retribuzioni
101
Come si evince dallo schema, gli attributi sono stati organizzati in una tassonomia
a tre livelli di aggregazione (mastro, mastrone e mastronissimo) allo scopo di analisi di
dati e astrazione.
La differenza deriva dalla natura e dal contenuto dell’atto: lo statuto speciale è una legge costituzionale e
definisce le forme e condizioni di autonomia speciale, mentre per le altre regioni le forme e le condizioni di
autonomia sono stabilite dalla Costituzione e lo Statuto ordinario delle stesse viene approvato con legge
regionale statutaria.
22
41
Conclusioni
In questa tesi si sono voluti studiare i database relazionali e non. Si è partiti con una
trattazione generale degli aspetti principali che hanno portato al loro sviluppo e alle
caratteristiche che li accomunano, andando più nello specifico presentando una panoramica
dei database più rappresentativi.
Come caso studio si è preso in esame il sistema informatico Efficientometro. Sono stati
identificati e censiti i dati da utilizzare per il sistema informatico descritto; sono stati
attentamente analizzati ed aggregati per poterli presentare all'utente finale in maniera chiara
e trasparente. E' stata definita una prima versione del progetto da cui si partirà per realizzare
la sezione regioni del sistema Efficientometro.
L’attività svolta mi ha dato la possibilità di interfacciarmi con un mondo nuovo, dove
i lavori sono ben organizzati e le scadenze è necessario rispettarle per non restare indietro e
per essere sempre in linea con gli obiettivi da raggiungere. Ho visto, quindi, come si
impongono delle scadenze, cosa occorre fare e come si lavora per rispettarle.
Oltre a queste nozioni che riguardano principalmente la sfera organizzativa, ho avuto
la possibilità di lavorare all'interno di un centro di ricerca all'avanguardia, “al servizio
dell'industria per ideare nuove e innovative soluzioni”. Si tratta di un nucleo operativo
costutuito da docenti, ricercatori e professionisti che da quasi 40 anni si occupa di ingegneria
del software. Ho potuto applicare alcune delle tecniche, delle metodologie e delle competenze
acquisite durante l'esecuzione del master con particolare riferimento agli ambiti di project
management e produzione database.
In definitiva l’efficientometro è utilizzabile come supporto al processo di
efficientamento della spesa pubblica, in grado di reperire, aggregare e rendere fruibili via web
i dati finanziari open degli enti pubblici in maniera chiara e user-friendly; di dotare i cittadini
di strumenti partecipativi al fine di incoraggiarli al controllo civico e alla collaborazione
diretta nella vita amministrativa di comuni, province, ecc.
Da un lato la piattaforma ha il dovere di assumere un ruolo proattivo di divulgazione
del patrimonio informativo; dall’altro il cittadino, in virtù del principio costituzionale di
sussidiarietà orizzontale, ha il diritto/dovere di informarsi e interrogare chi lo amministra
pretendendone la rendicontazione delle attività.
Si intende quindi promuovere l'accessibilità dei cittadini alla vita politicoamministrativa, ostacolata da un analfabetismo digitale ancora diffuso.
42
BIBLIOGRAFIA
A. Silberschatz, H. F. Korth, S. Sudarshan. Database System Concepts (6th Edition),
McGraw-Hill, 2010.
A. Albano, G. Ghelli, R. Orsini. Fondamenti di basi di dati. Zanichelli, Bologna 2005.
Atzeni P., Ceri S., Paraboschi S,Torlone R. (1999), Basi di dati, Mc Graw–Hill;
C. J. Date. An Introduction to Databases Systems (7th Edition), Addison-Wesley, 2000.
J.D. Ullman. Principle of Database and Knowledge Base Systems I-II.Computer Science
Press, Rockville, Maryland, 1989. (Trad. it. Basi di dati e di conoscenza. Gruppo Editoriale
Jackson, Milano, 1991.).
L. Welling, L. Thomson. MySQL Tutorial, Pearson Education Inc., 2004.
R. Elmasri, Navate S. B. (1994), Fundamentals of Database Systems, Addison Wesley.
R. Torlone: Fondamenti di Teoria delle Basi di Dati, Parte 1.
S.Abiteboul, R.Hull, V. Vianu. Foundations of Databases, Addison-Wesley, 1995.
S. Gilbert, N. Lynch, “Brewer's conjecture and the feasibility of consistent, available,
partition tolerant web services”, ACM SIGACT News, Volume 33 Issue 2 (2002), pagg. 5159.
43
SITOGRAFIA
www.amazon.com
www.contoannualetesoro.it
www.finanzalocale.interno.it
www.hostingtalk.it
www.magellanopa.it
www.mongodb.org
www.siope.it
www.tesi.cab.unipd.it
www.wikipedia.org
44