Home » 2021 » Aprile

Monthly Archives: Aprile 2021

Installazione MongoDB su Windows 10

Dal sito: https://www.mongodb.com/try/download/enterprise, e in particolare alla finestra posta sulla destra della pagina, selezionare la versione (attualmente è la 4.4.5), la piattaforma sulla quale installare il database MongoDB (valore di default: Windows) e il tipo di pacchetto (valore di default: msi).

Cliccare su Download. .

Il file scaricato è mongodb-windows-x86_64-enterprise-4.4.5-signed.msi.

Procedere all’installazione cliccando (o doppio click) sul file scaricato.

Compilare i campi con i vostri dati (email, nome, cognome e attività di riferimento) e cliccare sempre su Next e alla tipologia del database e infine cliccare su Complete.
L’installazione dura qualche minuto!!!

Mongodb verrà installato (salvo diversa impostazione) nella cartella del vostro PC predisposto per il software installato e più precisamente nella cartella C, sottocartella Programmi, sottocartella MongoDB, sottocartella Server, sottocartella 4.5, sottocartella Bin. Questo percorso (C:\Program Files\MongoDB\Server\4.5\bin) dovrà essere riportato nel path.

A questo punto predisporre il path per la corretta esecuzione del database MongoDB:

Nello spazio in basso a sinistra alla voce Scrivi qui per eseguire a ricerca, scrivere

Pannello di Controllo e cliccando sull’app appare la finestra nella quale va selezionata la voce Sistema e Sicurezza e in successione Sistema. Nella nuova pagina aperta cliccare sul lato sinistro la voce Impostazioni di sistema avanzate. A questo punto apparirà una finestra più piccola titolata Proprietà del sistema. In fondo a questa pagina cliccare su Variabili d’ambiente e apparirà un’altra finestra che contiene le Variabili d’utente per l’account (esempio user o guest oppure nome-account) e le Variabili di sistema. In corrispondenza delle variabili di sistema, portare il mouse sulla voce Path e cliccare il bottone Modifica. Apparirà una finestra titolata Modifica variabili d’ambiente e cliccando su Nuovo si incollerà (qualora sia stato copiato) il percorso indicato in rosso!

Una volta completata la procedura cliccare su OK su tutte le finestre che man mano verranno chiuse.

Non è finita.

A questo punto creare una cartella in uno spazio che desiderate denominata ad esempio DB_Mongo che conterrà i database di tipo MongoDB (ad esempio se viene creata sul vostro desktop), il percorso corretto sarà: C:\Users\user\Desktop\DB_Mongo.

(Nota: Users è l’accont con il quale vi siete collegati)

Se si vuole creare un collegamento sul vostro desktop per avviare il database MongoDB, procedete nel seguente modo:

Tasto destro sul desktop cliccate su Nuovo e successivamente su Collegamento.

Nello spazio si scriverà:

%comspec% /k mongod –dbpath c:\Users\userDesktop\DB_Mongo

Confermate, con il nome mongod, e se volete, potete associare a questo link l’icona di mongodb rappresentata da una foglia.

Siamo quasi arrivati al termine:

Creare un nuovo collegamento con le stesse modalità e questa volta nello spazio si scriverà:

%comspec% /k mongo

a cui si darà il nome mongo, e anche in questo caso, potrò associare il simbolo della foglia attraverso l’icona di mongodb.

Cliccando (o doppio click) prima sul link mongod, apparirà una finestra con scritte bianche e fondo nero sulla quale non si dovrà effettuare nessuna operazione (Server aperto).

In modo sequenziale cliccare sul link mongo e si aprirà finalmente l’ambiente nel quale si potrà procedere alla progettazione di database a documenti!!!!

Esercitazione

Consideriamo la collection esiti con i seguenti documenti:

Progettare un database denominato arte non relazionale a documenti (mongodb).

La collection esiti ha come sub-collection prove (relazione 1 a molti tra esiti e prove).

Modellazione dei dati

Quando si utilizza MongoDB, o in generale la maggioranza dei database NoSQL, la modellazione dei dati è una fase molto delicata dello sviluppo di una soluzione software. Infatti, a differenza di database relazionali, per cui esiste una vasta letteratura e molti strumenti software per la modellazione dei dati, qui esistono principalmente delle best practice, che derivano dal buon senso e da considerazioni che riguardano non tanto la struttura stessa dei dati, quanto piuttosto il loro utilizzo. Questo significa che a guidare la modellazione dei dati con MongoDB non è tanto la logica insita nei dati stessi, bensì soprattutto il modo in cui le applicazioni li useranno.

Vediamo ora la struttura di un documento: poiché MongoDB è un database schema-less, per definizione non c’è alcuno schema fisso per ogni documento; anzi, ogni documento ha uno schema a sé e le collezioni possono avere dati molto diversi fra loro.

Questo significa che non dobbiamo fare delle scelte a priori su una collection, ma ogni volta che dobbiamo salvare un documento in MongoDB dobbiamo fare delle scelte. La scelta più importante, considerando che in MongoDB non esistono vincoli di integrità referenziale tra i documenti, è come modellare le relazioni tra i documenti. Ci sono due possibilità, ognuna con i suoi pro e contro: documenti incorporati e documenti referenziati.

Documenti incorporati

Questa struttura prevede di incorporare un documento collegato in un campo del documento che lo referenzia. Ad esempio:

{

    titolo: ‘La commedia’,

    autori: [{ nome: ‘Dante’, cognome: ‘Alighieri’ }],

    edizioni: [

        { isbn: ‘xxxxxxx’, anno: 2014, casaEditrice: ‘Edizioni X’, prezzo: 35.50, ultima: true },

        { isbn: ‘yyyyyyy’, anno: 2013, casaEditrice: ‘Edizioni X’, prezzo: 33.20 }

    ]

}

In questo documento abbiamo incorporato ben due altri documenti: autori ed edizioni. Il primo ha una relazione di molti-a-molti, il secondo ha una relazione uno-a-molti.

Vantaggi: atomicità e letture

Il vantaggio principale dell’incorporazione è la gestione dell’atomicità. Infatti per MongoDB le uniche operazioni atomiche sono quelle che coinvolgono un singolo documento: in altre parole, non è possibile effettuare transazioni che coinvolgono due o più documenti. Quindi, salvando tutto il documento, avremo la garanzia che la nostra modifica è effettivamente avvenuta senza il rischio che salvataggi concorrenti abbiano messo il nostro database in uno stato non coerente. Ad esempio abbiamo la garanzia che, anche in caso di letture/scritture concorrenti, ci sarà una sola edizione con il campo ultima impostato a true.

Un altro vantaggio è il numero di letture: per avere le informazioni necessarie su un elemento del nostro database ci basterà una sola lettura, il che è comodo soprattutto in caso di sharding, ossia quando avremo suddiviso le nostre collezioni e distribuite in diversi nodi di MongoDB. In tal caso, infatti, non dovremo interrogare diversi nodi per mettere insieme le informazioni su un’entità della nostra applicazione. Ciò è particolarmente apprezzato quando si sviluppa con paradigmi come DDD (Domain Driven Design) e CQRS (Command and Query Responsibility Segregation).

Svantaggi: relazioni molti-a-molti

Lo svantaggio più grande riguarda invece la ridondanza, principalmente nel caso di relazioni molti-a-molti. Se ad esempio volessimo inserire un’altra opera dello stesso autore nel database, dovremmo replicare tutte le informazioni sull’autore. Se tali informazioni sono poche, il danno è minimo; se invece sono tante potremmo far crescere rapidamente il nostro database. Inoltre, se volessimo aggiornare uno dei dati di un autore dovremmo effettuare un aggiornamento massivo su tutti i documenti che incorporano l’autore da aggiornare. Ad esempio:

db.opere.update(

                             { “autori.cognome”: “Alighieri” },

                             { $set: { “autori.0.natoA”: “Firenze” }},

                             { multi: true}

                           );

Anche qui, se il database ha dimensioni contenute, l’aggiornamento sarà rapido; altrimenti, esso potrà richiedere diverso tempo. Inoltre non c’è nessun meccanismo che garantisca che lo stesso autore incorporato in due documenti diversi contenga esattamente gli stessi dati.

Documenti referenziati

Le relazioni tra documenti possono essere rappresentate anche tramite l’indicazione di una chiave o un identificativo che permette di collegarli. Ciò significa che avremo più documenti che condividono dei riferimenti tra loro. L’esempio precedente viene quindi spezzato in quattro documenti:

{

    titolo: ‘La commedia’,

    autori: [ ‘dante’ ],

    edizioni: [ ‘xxxxxxx’, ‘yyyyyyy’ ]

}

{ _id: ‘dante’, nome: ‘Dante’, cognome: ‘Alighieri’ }

{ _id: ‘xxxxxxx’, anno: 2014, casaEditrice: ‘Edizioni X’, prezzo: 35.50, ultima: true },

{ _id: ‘yyyyyyy’, anno: 2013, casaEditrice: ‘Edizioni X’, prezzo: 33.20 }

Ovviamente ha senso suddividere questi documenti in tre collezioni: opere, autori, edizioni.

Svantaggi: numero di letture e consistenza

Lo svantaggio maggiore è nel numero di letture: infatti per ricostruire i dati di un documento coinvolto in una relazione dobbiamo effettuare tante letture quanti sono i documenti referenziati.

Dobbiamo anche notare che nei campi edizioni ed autori abbiamo semplicemente un array di valori: MongoDB non è affatto consapevole del fatto che essi si riferiscano a documenti effettivamente esistenti in altre collezioni. Ciò perché non esiste il concetto di relazione ed integrità referenziale

Riepilogando, non è possibile fornire una regola generale di modellazione dei dati, ma bisogna valutare caso per caso, in base all’utilizzo che si farà del database ed alle esigenze delle applicazioni. Però si può dire che:

  •  l’utilizzo di documenti incorporati è più indicato in caso di relazioni uno-a-molti;
  •  l’utilizzo di documenti referenziati è più indicato in caso di relazioni molti-a-molti.

MySQL vs. MongoDB

Si supponga di avere il database relazionale BLOG costituito dalle tabelle AUTORI, ARTICOLI, COMMENTI e CATEGORIE. Definiamo le seguenti relazioni:

  AUTORI -> ARTICOLI
(1 a molti)  
Un autore può scrivere più articolo, ma un articolo è scritto da un solo autore
  ARTICOLI -> COMMENTI
(1 a molti)
Un articolo contiene più commenti, ma un commento riguarda un solo articolo
  ARTICOLI -> CATEGORIE
(molti a molti)
Un articolo può appartenere a più categorie e ad una categoria possono appartenere più articoli

Pertanto avremo:

Mentre lo schema relazionale sarà il seguente:

AUTORI(autore_ID, username, password)

ARTICOLI(articolo_ID, titolo, testo, data, autore_ID)

COMMENTI(commento_id, nome, testo, email, articolo_ID)

CATEGORIE(categoria_ID, descrizione)

ART_CATEG(articolo_ID, categoria_ID)

In grassetto la chiave primaria e la sottolineatura per la chiave esterna!!!

Per visualizzare la pagina di un articolo con tutte le sue informazioni avremo bisogno dell’accesso all’articolo, al nome dell’autore, ai commenti e alle categorie di appartenenza con il coinvolgimento della tabella ART_TAG, quindi avrò bisogno di tutte e cinque le tabelle.

Ora vediamo come lo stesso database viene gestito nel database orientato a documenti con particolare riferimento a mongodb. Avremo bisogno di una collection siffatta:

Collection ARTICOLI

{  titolo:”Il database noSQL”,  
testo:”Il database NoSQL sono appositamente realizzati per modelli di
dati specifici e hanno schemi flessibili per creare applicazioni
moderne. …”,  
data: Date(),  
autore:”Rossi Mario”,  
commenti:       
[{nome:”Bianchi Ada”,
     testo:”Un articolo davvero interessante. Complimenti”,           
email:”adabianchi@blaisepascal.it”},
   {nome:”Neri Aldo”,           
testo:”Trovo l’articolo privo di documentazione adegua”,           
email:”aldoneri@blaisepascal.it”}       
],  
categorie:[“database”, “nosql”, “mongodb”]
}          

e di un’altra collection

Collection AUTORI

{

 _id:”Rossi Mario,

 username:”mariorossi”,

 password:”issoroiram” }

Ci chiediamo a quante collection dovrò accedere per la visualizzazione di una pagina di un singolo articolo?

La risposta è una sola collection!

Dunque come abbiamo visto mancano le join e le transaction.

Attraverso la figura seguente osserviamo la definizione di transaction e le operazioni di commit e rollback

Vediamo in questa slide come cambia il modo di pensare da un modello di database relazionale a un modello di database orientato a documenti.

Esempio di applicazione

Supponiamo che il database relazionale sia costituito dalle seguenti tabelle con i relativi attributi e relazione.

Schema relazionale del database SANREMO
Cantanti (nome, info)
Canzoni (titolo, edizione, posto, nomecantante)

Supponiamo inoltre che la tabella Cantanti contenga le seguenti informazioni:

nomeinfo
Domenico Modugnocantautore, chitarrista, attore, regista e politico italiano
Loredana Bertècantautrice e attrice italiana, sorella minore di Mia Martini

 e la tabella Canzoni

titoloedizionepostonomecantante
Nel blu dipinto di blu91Domenico Modugno
Piove101Domenico Modugno
Addio… addio131Domenico Modugno
Cosa ti aspetti da me694Loredana Bertè
Re379Loredana Bertè
Io3916Loredana Bertè
In questa città4216Loredana Bertè
Amici non ne ho4513Loredana Bertè

Al prompt digiteremo: use sanremo

Volendo inserire le canzoni di Domenico Modugno si digiterà il seguente comando:

db.cantanti.insert

(

 {

nome:”Domenico Modugno”,

info:”cantautore, chitarrista, attore, regista e politico italiano”,

canzoni:

[

 {titolo:”Nel blu dipinto di blu”, edizione:”9″, posto:”1″},

 {titolo:”Piove”, edizione:”10″, posto:”1″},

 {titolo:”Addio … addio”, edizione:”13″, posto:”1″}

]

 }

)

Questa operazione di includere le canzoni all’interno del cantante si chiama embedding e rappresenta una vera e propria join detta anche pre-join.

Mentre il linguaggio con cui scriviamo le istruzioni è chiamato JSON (Java Script Object Notation).

Per visualizzare il dato inserito si scriverà il seguente comando:

db.cantanti.find()

il cui effetto è la seguente schermata

Come si può notare alla collection cantanti è stato aggiunto in automatico id. Se vogliamo una scrittura più leggibile si utilizza il comando: db.cantanti.find().pretty()

Supponiamo di voler aggiungere la data di nascita al cantante Domenico Modugno, utilizzando JSON si utilizza una variabile

var cantante=db.cantanti.findOne({nome:”Domenico Modugno”})

seguito dai seguenti comandi

cantante.datanascita=”09/01/1928″

db.cantanti.save(cantante)

Ridigitando il comando:db.cantanti.find().pretty()

Breviario di MongoDB per Windows

Questo breviario base vuol essere un primo approccio didattico all’utilizzo del database NoSQL orientato a documenti (documents-oriented).

Dopo aver installato mongoDB sul proprio PC e aver creato una cartella in cui inserire il database ad esempio in una cartella sul desktop denominato db_mongo, si accede al prompt e alla richiesta si abilita l’utilizzo del database attraverso il seguente comando:

mongod –path c:\users\user\desktop\db_mongo

Schermata n. 1

All’invio del comando apparirà una schermata con una serie di informazioni:

Schermata n. 2

Lasciando aperta questa finestra, aprite un’altra app del prompt dei comandi e digitare mongo . Apparirà la seguente finestra:

Il prompt MongoDB Enterprise > consente di inserire i comandi del database (shell).

Il primo comando è quello di mostrare i database presenti nella cartella prescelta:

show dbs

Per l’utilizzo di un database specifico o per creare un nuovo database utilizzo il comando:

use nome-database

La collection è equiparata alla tabella di un database relazionale, ma con delle caratteristiche più ampie. Potremo fare un’analogia con l’oggetto nella programmazione orientata ad oggetti.

show collections

Permette di visualizzare le collection del database.

Archivi

Aprile: 2021
L M M G V S D
 1234
567891011
12131415161718
19202122232425
2627282930