SlideShare a Scribd company logo
1 of 44
Download to read offline
Università degli Studi di Salerno 
Sistemi Informatici e Tecnologie del Software 
NOSQL DATABASE 
! 
Basi di Dati II 
Anno 2013/2014 
Prof.ssa G.Tortora Prof. G.Polese 
Branca Carlo 
Grano Giovanni 
Merola Matteo 
Scalabrino Simone 
Overview, classificazione e utilizzi pratici
Introduzione Caratteristiche 
Classificazione Mercato
Introduzione
WHY RDBMS?
RDBMS - Motivazioni
RDBMS - Motivazioni 
• Schema predefinito per lo storage di dati strutturati 
• Struttura BCNF già familiare 
• Strong consistency 
• Transazioni 
• Maturi e accuratamente testati (la maggior parte) 
• Facile adozione/integrazione 
• Basati sulle proprietà ACID 
• Data Retrieval: Standard Query Language (SQL) - versatile e potente 
• Scalabilità verticale: se volessimo rendere un DB SQL scalabile, l’unica 
alternativa sarebbe quella di potenziare l’hardware sul quale il DBMS è installato
WHY NOSQL?
Introduzione - BIG USERS
Introduzione - BIG USERS 
Un gran numero di utenti combinato con la una natura fortemente dinamica dei pattern di 
gestione dei dati sta guidando il bisogno di nuove database scalabili. Con le tecnologie 
relazionali, molti sviluppatori trovano difficile raggiungere la scalabilità dinamica richiesta 
dalle applicazioni per garantire il livello di performance richiesto dagli utenti… 
… molti si stanno rivolgendo ai NoSQL!
Introduzione - BIG DATA
Introduzione - BIG DATA 
L’ammontare dei dati è in rapida crescita e la natura di questi dati dati sta cambiando in 
conseguenza all’utilizzo che gli sviluppatori fanno di nuovi tipi di dati (per la maggior parte 
non strutturati o semi strutturati) nelle loro applicazioni
Introduzione - The Internet of Things
Introduzione - The Internet of Things 
THE INTERNET OF THINGS 
! 
• Ci sono 14 milioni di “cose” connesse ad Internet. Si tratta di fabbriche, aziende 
agricole, ospedali e warehouses. Ci si connette da casa o dall’auto. Ci si 
connette dallo smarthphone e dal tablet. Si ricevono continuamente dati su 
ambiente, posizioni geografiche, spostamenti, temperature, meteo da oltre 50 
bilioni di sensori 
• La chiave è l’accesso globale real-time! 
• I dati relativi alle telemetrie sono di piccole dimensioni, semi-strutturati e continui. 
Si tratta di una grossa sfida per i database relazionali i quali richiedono dati 
strutturati e con uno schema rigido 
• I NoSQL raccolgono questa sfida! Sempre più aziende innovative si affidano a 
questi database richiedendo una tecnologia per sia in grado di scalare con le 
milioni di “cose” connesse ad Internet
Caratteristiche
Caratteristiche
Caratteristiche 
NOSQL KEYWORD 
• Non relazionali: l’approccio rigido dei db relazionali non permette di 
memorizzare dati fortemente dinamici. I db NoSQL sono “schemaless” e 
consentono di memorizzare “on the fly” attributi, anche senza averli definiti a 
priori 
• Distribuiti: la flessibilità nella clusterizzazione e nella replicazione dei dati 
permette di distribuire su più nodi lo storage, in modo da realizzare potenti 
sistemi “fault tollerance” 
• Scalabili orizzontalmente: in contrapposizione alla scalabilità verticale, abbiamo 
architetture enormemente scalabili, che consentono di memorizzare e gestire una 
grande quantità di informazioni 
• Open-source: filosofia alla base del movimento NoSQL
Caratteristiche
• Grossi volumi di dati 
• Goodbye DBAs: un sistema RDBMS di 
alto livello può essere mantenuto 
s o l ame n t e c o n l ’ a s s i s t e n z a d i 
amministratori altamente esperti (e 
costosi). I Database NoSQL sono 
generalmente ideati per richiede una 
minore manutenzione. 
• Velocità di risposta alle query! 
• BASE - le proprietà ACID non sono 
richieste 
• CAP Theorem 
Caratteristiche
Transazioni BASE 
Caratteristiche 
I NoSQL si basano su un modello più morbido e flessibile. Il modello BASE si sposa 
con la flessibilità offerta dai NoSQL e da approcci similari per il management dei 
dati non strutturati 
• Basically Available: l’approccio dei database NoSQL si basa sul garantire la 
disponibilità dei dati anche in presenza di fallimenti multipli. Questo obiettivo è 
raggiunto attraverso un approccio fortemente distribuito 
• Soft state: i database BASE abbandonano il requisito della consistenza dei 
modelli ACID quasi completamente. La consistenza dei dati è un problema dello 
sviluppatore e non deve essere gestita dal database. 
• Eventually Consistent: l’unico requisito riguardante la consistenza è garantire 
che in un certo punto nel futuro i dati possano convergere ad uno stato 
consistente
Caratteristiche
Caratteristiche 
Brewer’s CAP Theorem 
Un sistema distribuito è in grado di supportare 
solamente due tra le seguenti caratteristiche: 
• Consistency: tutti i nodi vedono lo stesso dato 
allo stesso tempo 
• Availability: ogni operazione deve sempre 
ricevere una risposta 
• Partition Tolerance: capacità di un sistema di 
essere tollerante ad una aggiunta, una rimozione 
di un nodo nel sistema distribuito o alla non 
disponibilità di un componente singolo
Caratteristiche - Challenges
Caratteristiche - Challenges 
Troppo entusiasmo…? 
• Maturità: i sistemi RDBMS sono in esercizio da tanto tempo. Per i sostenitori del 
movimento NoSQL questo è un segno della loro obsolescenza; per molti CIO 
invece, la maturità di un RDBMS è rassicurate 
• Supporto: tutte le aziende che sviluppato e vendono RDBMS forniscono un alto 
livello di supporto alle aziende. I sistemi NoSQL invece sono spesso progetti 
open source 
• Business Intelligence: la business intelligence è un elemento chiave per le 
aziende IT; spesso i tools per la BI non supportano connettività con i database 
NoSQL 
• Amministrazione: un obiettivo di design per i database NoSQL è quello di non 
necessitare di gran supporto amministrativo ma la realtà è che al giorno d’oggi 
sono necessarie grosse competenze per la loro installazione e manutenzione 
• Expertise: è più semplice trovare un esperto amministrazione RDBMS che non 
un espero in NoSQL
Classificazione
Classificazione
Classificazione 
KEY-VALUE DATA STORE 
! 
• Utilizza un associative array (chiave-valore) 
come modello fondamentale per lo storage 
• Storage, update e ricerca basato sulle chiavi 
• Tipi di dati primitivi familiari ai programmatori 
• Semplice 
• Veloce recupero dei dati 
• Grandi moli di dati
Classificazione
Classificazione 
DOCUMENT DATA STORE 
! 
• Utilizzando dati non strutturati 
• Supporto a diversi tipi di documento 
• Un documento è identificato da una chiave 
primaria 
• Schema-less 
• Scalabilità orizzontale 
!
Classificazione
Classificazione 
COLUMN-ORIENTED DATA 
STORE 
! 
• I dati sono nelle colonne anziché nelle righe 
• Un gruppo di colonne è chiamato famiglia ed vi è 
un’analogia con le tabelle di un database relazionale 
• Le colonne possono essere facilmente distribuite 
• Scalabile 
• Performante 
• Fault-tollerance 
!
Classificazione
Classificazione 
GRAPH-BASED DATA STORE 
! 
• Utilizza nodi (entità), proprietà (attributi) e archi 
(relazioni) 
• Modello logico semplice e intuitivo 
• Ogni elemento contiene un puntatore 
all’elemento adiacente 
• Attraversamento del grafo per trovare i dati 
• Efficiente per la rappresentazione di reti sociali o 
dati sparsi 
• Relazioni tra i dati centrali
Classificazione
Classificazione 
Operational complexity: all’aumentare della complessità nella struttura dati 
diminuisce la capacità di memorizzazione dei dati stessi (parametro size)
Ranking
Ranking
Ranking 
DB-Engines elenca 221 tipi differenti di database management systems, ognuno 
classificato secondo un modello differente. 
Questo chart mostra il numero di sistemi per ogni categoria. Alcuni sistemi possono 
appartenere a più di una categoria.
Ranking
Ranking 
Questo chart-diagram mostra la popolarità di ogni categoria. È calcolato utilizzando 
la popolarità (lo score nel ranking) di ogni sistema per categoria. 
La somma dei ranking rappresenta il 100%
Ranking
Ranking 
Questo diagramma mostra il trend storico della popolarità per ogni categoria. Ogni 
mese, i primi tre sistemi per categoria sono scelti e la media del loro ranking score 
è calcolata. Per permettere delle comparazioni, il valore iniziale è normalizzato a 
100.
Scarica questa presentazione 
http://goo.gl/NHIC8k 
Giovanni Grano 
granogiovanni90@gmail.com 
Università degli Studi di Salerno

More Related Content

Similar to No Sql Intro

Netflix: cos'è, come funziona
Netflix: cos'è, come funzionaNetflix: cos'è, come funziona
Netflix: cos'è, come funzionaFloriana Benedetti
 
Logical Data Lake: polifunzionale e decentralizzato per l'analisi dei dati
Logical Data Lake: polifunzionale e decentralizzato per l'analisi dei datiLogical Data Lake: polifunzionale e decentralizzato per l'analisi dei dati
Logical Data Lake: polifunzionale e decentralizzato per l'analisi dei datiDenodo
 
Polyglot Persistence e Big Data: tra innovazione e difficoltà su casi reali -...
Polyglot Persistence e Big Data: tra innovazione e difficoltà su casi reali -...Polyglot Persistence e Big Data: tra innovazione e difficoltà su casi reali -...
Polyglot Persistence e Big Data: tra innovazione e difficoltà su casi reali -...Data Driven Innovation
 
Dynamic Schema e Schemaless Tables
Dynamic Schema e Schemaless TablesDynamic Schema e Schemaless Tables
Dynamic Schema e Schemaless TablesDavide Mauri
 
Archeo foss 2012 slides 1
Archeo foss 2012 slides 1Archeo foss 2012 slides 1
Archeo foss 2012 slides 1CSP Scarl
 
Multitenancy con SQL Server e Azure SQL Database
Multitenancy con SQL Server e Azure SQL DatabaseMultitenancy con SQL Server e Azure SQL Database
Multitenancy con SQL Server e Azure SQL DatabaseGianluca Hotz
 
Power B: Cleaning data
Power B: Cleaning dataPower B: Cleaning data
Power B: Cleaning dataMarco Pozzan
 
Big data stack tecnologico
Big data stack tecnologicoBig data stack tecnologico
Big data stack tecnologicoMassimo Romano
 
Azure Synapse: data lake & modern data warehouse dalla A alla Z
Azure Synapse: data lake &  modern data warehouse dalla A alla ZAzure Synapse: data lake &  modern data warehouse dalla A alla Z
Azure Synapse: data lake & modern data warehouse dalla A alla ZRoberto Messora
 
La Trasformazione Digitale con MongoDB
La Trasformazione Digitale con MongoDB La Trasformazione Digitale con MongoDB
La Trasformazione Digitale con MongoDB MongoDB
 
MySQL Day Milano 2017 - Dalla replica a InnoDB Cluster: l’HA secondo MySQL
MySQL Day Milano 2017 - Dalla replica a InnoDB Cluster: l’HA secondo MySQLMySQL Day Milano 2017 - Dalla replica a InnoDB Cluster: l’HA secondo MySQL
MySQL Day Milano 2017 - Dalla replica a InnoDB Cluster: l’HA secondo MySQLPar-Tec S.p.A.
 
JBoss Data Grid Tech Lab
JBoss Data Grid Tech LabJBoss Data Grid Tech Lab
JBoss Data Grid Tech LabUgo Landini
 
Infinispan codemotion - Codemotion Rome 2015
Infinispan codemotion - Codemotion Rome 2015Infinispan codemotion - Codemotion Rome 2015
Infinispan codemotion - Codemotion Rome 2015Codemotion
 
Big data - stack tecnologico
Big data -  stack tecnologicoBig data -  stack tecnologico
Big data - stack tecnologicoConsulthinkspa
 
20160402_mlraviol_mariadb_TorinoWordCamp
20160402_mlraviol_mariadb_TorinoWordCamp20160402_mlraviol_mariadb_TorinoWordCamp
20160402_mlraviol_mariadb_TorinoWordCampmlraviol
 
Zurich Italia - IT Knowledge Base (Italian)
Zurich Italia - IT Knowledge Base (Italian)Zurich Italia - IT Knowledge Base (Italian)
Zurich Italia - IT Knowledge Base (Italian)Neo4j
 
[AxonIQ Italia Community] Architetture distribuite a eventi: sono adatte al m...
[AxonIQ Italia Community] Architetture distribuite a eventi: sono adatte al m...[AxonIQ Italia Community] Architetture distribuite a eventi: sono adatte al m...
[AxonIQ Italia Community] Architetture distribuite a eventi: sono adatte al m...Corrado Musumeci
 

Similar to No Sql Intro (20)

Netflix: cos'è, come funziona
Netflix: cos'è, come funzionaNetflix: cos'è, come funziona
Netflix: cos'è, come funziona
 
Logical Data Lake: polifunzionale e decentralizzato per l'analisi dei dati
Logical Data Lake: polifunzionale e decentralizzato per l'analisi dei datiLogical Data Lake: polifunzionale e decentralizzato per l'analisi dei dati
Logical Data Lake: polifunzionale e decentralizzato per l'analisi dei dati
 
Polyglot Persistence e Big Data: tra innovazione e difficoltà su casi reali -...
Polyglot Persistence e Big Data: tra innovazione e difficoltà su casi reali -...Polyglot Persistence e Big Data: tra innovazione e difficoltà su casi reali -...
Polyglot Persistence e Big Data: tra innovazione e difficoltà su casi reali -...
 
Dynamic Schema e Schemaless Tables
Dynamic Schema e Schemaless TablesDynamic Schema e Schemaless Tables
Dynamic Schema e Schemaless Tables
 
Archeo foss 2012 slides 1
Archeo foss 2012 slides 1Archeo foss 2012 slides 1
Archeo foss 2012 slides 1
 
Multitenancy con SQL Server e Azure SQL Database
Multitenancy con SQL Server e Azure SQL DatabaseMultitenancy con SQL Server e Azure SQL Database
Multitenancy con SQL Server e Azure SQL Database
 
Power B: Cleaning data
Power B: Cleaning dataPower B: Cleaning data
Power B: Cleaning data
 
Data flow
Data flowData flow
Data flow
 
Big data stack tecnologico
Big data stack tecnologicoBig data stack tecnologico
Big data stack tecnologico
 
Azure Synapse: data lake & modern data warehouse dalla A alla Z
Azure Synapse: data lake &  modern data warehouse dalla A alla ZAzure Synapse: data lake &  modern data warehouse dalla A alla Z
Azure Synapse: data lake & modern data warehouse dalla A alla Z
 
La Trasformazione Digitale con MongoDB
La Trasformazione Digitale con MongoDB La Trasformazione Digitale con MongoDB
La Trasformazione Digitale con MongoDB
 
MySQL Day Milano 2017 - Dalla replica a InnoDB Cluster: l’HA secondo MySQL
MySQL Day Milano 2017 - Dalla replica a InnoDB Cluster: l’HA secondo MySQLMySQL Day Milano 2017 - Dalla replica a InnoDB Cluster: l’HA secondo MySQL
MySQL Day Milano 2017 - Dalla replica a InnoDB Cluster: l’HA secondo MySQL
 
JBoss Data Grid Tech Lab
JBoss Data Grid Tech LabJBoss Data Grid Tech Lab
JBoss Data Grid Tech Lab
 
Infinispan codemotion - Codemotion Rome 2015
Infinispan codemotion - Codemotion Rome 2015Infinispan codemotion - Codemotion Rome 2015
Infinispan codemotion - Codemotion Rome 2015
 
Big data - stack tecnologico
Big data -  stack tecnologicoBig data -  stack tecnologico
Big data - stack tecnologico
 
Datawarehouse
DatawarehouseDatawarehouse
Datawarehouse
 
Datamart.pdf
Datamart.pdfDatamart.pdf
Datamart.pdf
 
20160402_mlraviol_mariadb_TorinoWordCamp
20160402_mlraviol_mariadb_TorinoWordCamp20160402_mlraviol_mariadb_TorinoWordCamp
20160402_mlraviol_mariadb_TorinoWordCamp
 
Zurich Italia - IT Knowledge Base (Italian)
Zurich Italia - IT Knowledge Base (Italian)Zurich Italia - IT Knowledge Base (Italian)
Zurich Italia - IT Knowledge Base (Italian)
 
[AxonIQ Italia Community] Architetture distribuite a eventi: sono adatte al m...
[AxonIQ Italia Community] Architetture distribuite a eventi: sono adatte al m...[AxonIQ Italia Community] Architetture distribuite a eventi: sono adatte al m...
[AxonIQ Italia Community] Architetture distribuite a eventi: sono adatte al m...
 

No Sql Intro

  • 1. Università degli Studi di Salerno Sistemi Informatici e Tecnologie del Software NOSQL DATABASE ! Basi di Dati II Anno 2013/2014 Prof.ssa G.Tortora Prof. G.Polese Branca Carlo Grano Giovanni Merola Matteo Scalabrino Simone Overview, classificazione e utilizzi pratici
  • 2.
  • 7. RDBMS - Motivazioni • Schema predefinito per lo storage di dati strutturati • Struttura BCNF già familiare • Strong consistency • Transazioni • Maturi e accuratamente testati (la maggior parte) • Facile adozione/integrazione • Basati sulle proprietà ACID • Data Retrieval: Standard Query Language (SQL) - versatile e potente • Scalabilità verticale: se volessimo rendere un DB SQL scalabile, l’unica alternativa sarebbe quella di potenziare l’hardware sul quale il DBMS è installato
  • 10. Introduzione - BIG USERS Un gran numero di utenti combinato con la una natura fortemente dinamica dei pattern di gestione dei dati sta guidando il bisogno di nuove database scalabili. Con le tecnologie relazionali, molti sviluppatori trovano difficile raggiungere la scalabilità dinamica richiesta dalle applicazioni per garantire il livello di performance richiesto dagli utenti… … molti si stanno rivolgendo ai NoSQL!
  • 12. Introduzione - BIG DATA L’ammontare dei dati è in rapida crescita e la natura di questi dati dati sta cambiando in conseguenza all’utilizzo che gli sviluppatori fanno di nuovi tipi di dati (per la maggior parte non strutturati o semi strutturati) nelle loro applicazioni
  • 13. Introduzione - The Internet of Things
  • 14. Introduzione - The Internet of Things THE INTERNET OF THINGS ! • Ci sono 14 milioni di “cose” connesse ad Internet. Si tratta di fabbriche, aziende agricole, ospedali e warehouses. Ci si connette da casa o dall’auto. Ci si connette dallo smarthphone e dal tablet. Si ricevono continuamente dati su ambiente, posizioni geografiche, spostamenti, temperature, meteo da oltre 50 bilioni di sensori • La chiave è l’accesso globale real-time! • I dati relativi alle telemetrie sono di piccole dimensioni, semi-strutturati e continui. Si tratta di una grossa sfida per i database relazionali i quali richiedono dati strutturati e con uno schema rigido • I NoSQL raccolgono questa sfida! Sempre più aziende innovative si affidano a questi database richiedendo una tecnologia per sia in grado di scalare con le milioni di “cose” connesse ad Internet
  • 17. Caratteristiche NOSQL KEYWORD • Non relazionali: l’approccio rigido dei db relazionali non permette di memorizzare dati fortemente dinamici. I db NoSQL sono “schemaless” e consentono di memorizzare “on the fly” attributi, anche senza averli definiti a priori • Distribuiti: la flessibilità nella clusterizzazione e nella replicazione dei dati permette di distribuire su più nodi lo storage, in modo da realizzare potenti sistemi “fault tollerance” • Scalabili orizzontalmente: in contrapposizione alla scalabilità verticale, abbiamo architetture enormemente scalabili, che consentono di memorizzare e gestire una grande quantità di informazioni • Open-source: filosofia alla base del movimento NoSQL
  • 19. • Grossi volumi di dati • Goodbye DBAs: un sistema RDBMS di alto livello può essere mantenuto s o l ame n t e c o n l ’ a s s i s t e n z a d i amministratori altamente esperti (e costosi). I Database NoSQL sono generalmente ideati per richiede una minore manutenzione. • Velocità di risposta alle query! • BASE - le proprietà ACID non sono richieste • CAP Theorem Caratteristiche
  • 20. Transazioni BASE Caratteristiche I NoSQL si basano su un modello più morbido e flessibile. Il modello BASE si sposa con la flessibilità offerta dai NoSQL e da approcci similari per il management dei dati non strutturati • Basically Available: l’approccio dei database NoSQL si basa sul garantire la disponibilità dei dati anche in presenza di fallimenti multipli. Questo obiettivo è raggiunto attraverso un approccio fortemente distribuito • Soft state: i database BASE abbandonano il requisito della consistenza dei modelli ACID quasi completamente. La consistenza dei dati è un problema dello sviluppatore e non deve essere gestita dal database. • Eventually Consistent: l’unico requisito riguardante la consistenza è garantire che in un certo punto nel futuro i dati possano convergere ad uno stato consistente
  • 22. Caratteristiche Brewer’s CAP Theorem Un sistema distribuito è in grado di supportare solamente due tra le seguenti caratteristiche: • Consistency: tutti i nodi vedono lo stesso dato allo stesso tempo • Availability: ogni operazione deve sempre ricevere una risposta • Partition Tolerance: capacità di un sistema di essere tollerante ad una aggiunta, una rimozione di un nodo nel sistema distribuito o alla non disponibilità di un componente singolo
  • 24. Caratteristiche - Challenges Troppo entusiasmo…? • Maturità: i sistemi RDBMS sono in esercizio da tanto tempo. Per i sostenitori del movimento NoSQL questo è un segno della loro obsolescenza; per molti CIO invece, la maturità di un RDBMS è rassicurate • Supporto: tutte le aziende che sviluppato e vendono RDBMS forniscono un alto livello di supporto alle aziende. I sistemi NoSQL invece sono spesso progetti open source • Business Intelligence: la business intelligence è un elemento chiave per le aziende IT; spesso i tools per la BI non supportano connettività con i database NoSQL • Amministrazione: un obiettivo di design per i database NoSQL è quello di non necessitare di gran supporto amministrativo ma la realtà è che al giorno d’oggi sono necessarie grosse competenze per la loro installazione e manutenzione • Expertise: è più semplice trovare un esperto amministrazione RDBMS che non un espero in NoSQL
  • 27. Classificazione KEY-VALUE DATA STORE ! • Utilizza un associative array (chiave-valore) come modello fondamentale per lo storage • Storage, update e ricerca basato sulle chiavi • Tipi di dati primitivi familiari ai programmatori • Semplice • Veloce recupero dei dati • Grandi moli di dati
  • 29. Classificazione DOCUMENT DATA STORE ! • Utilizzando dati non strutturati • Supporto a diversi tipi di documento • Un documento è identificato da una chiave primaria • Schema-less • Scalabilità orizzontale !
  • 31. Classificazione COLUMN-ORIENTED DATA STORE ! • I dati sono nelle colonne anziché nelle righe • Un gruppo di colonne è chiamato famiglia ed vi è un’analogia con le tabelle di un database relazionale • Le colonne possono essere facilmente distribuite • Scalabile • Performante • Fault-tollerance !
  • 33. Classificazione GRAPH-BASED DATA STORE ! • Utilizza nodi (entità), proprietà (attributi) e archi (relazioni) • Modello logico semplice e intuitivo • Ogni elemento contiene un puntatore all’elemento adiacente • Attraversamento del grafo per trovare i dati • Efficiente per la rappresentazione di reti sociali o dati sparsi • Relazioni tra i dati centrali
  • 35. Classificazione Operational complexity: all’aumentare della complessità nella struttura dati diminuisce la capacità di memorizzazione dei dati stessi (parametro size)
  • 38. Ranking DB-Engines elenca 221 tipi differenti di database management systems, ognuno classificato secondo un modello differente. Questo chart mostra il numero di sistemi per ogni categoria. Alcuni sistemi possono appartenere a più di una categoria.
  • 40. Ranking Questo chart-diagram mostra la popolarità di ogni categoria. È calcolato utilizzando la popolarità (lo score nel ranking) di ogni sistema per categoria. La somma dei ranking rappresenta il 100%
  • 42. Ranking Questo diagramma mostra il trend storico della popolarità per ogni categoria. Ogni mese, i primi tre sistemi per categoria sono scelti e la media del loro ranking score è calcolata. Per permettere delle comparazioni, il valore iniziale è normalizzato a 100.
  • 43.
  • 44. Scarica questa presentazione http://goo.gl/NHIC8k Giovanni Grano granogiovanni90@gmail.com Università degli Studi di Salerno