MongoDB è un database NoSQL, che fornisce un nuovo approccio nell’organizzazione e gestione dei dati.
Ad oggi, MongoDB è in grado di coprire la quasi totalità delle esigenze svolte dai database relazionali ( MySQL, Oracle ecc… ) garantendo migliori performance, una maggiore scalabilità ed un’attività di sviluppo più veloce ed agile rispetto ai database tradizionali.

Sempre di più, durante la fase di avvicinamento a questo nuovo modo di organizzare grandi volumi di dati, i database NoSQL si integrano in soluzioni miste per facilitare un graduale passaggio dalle soluzioni relazionali a questo tipo di database.

L’obiettivo di questo post, senza entrare troppo nel dettaglio, è quello di evidenziare alcune delle differenze tra i database tradizionali e MongoDB

Infatti, sviluppare applicativi con database relazionali significa ( vedi figura seguente ) dover gestire tre fasi distinte di sviluppo quali:
– Sviluppo degli schemi relazionali del database
– Creazione di file di configurazione per la mappatura delle tabelle in oggetti. Molti linguaggi di programmazione ad oggi forniscono librerie in grado di svolgere automaticamente questa attività ma che comunque introducono gli elementi indicati in figura.
– Sviluppo del codice applicativo

sviluppo_db_relazionali-1024x620

Viceversa, con MongoDB, gli utenti possono concentrarsi nello sviluppo del codice applicativo e nel modellare collezioni e documenti json che automaticamente saranno convertiti in oggetti da tutti i linguaggi di programmazione. Infatti, con MongoDB, vengono eliminate le parti di organizzazione dai dati in modo strutturato e l’operazione di mapping tra database ed oggetti dell’applicativo: questa è già una prima importante differenza in termini di agilità di sviluppo rispetto ai database relazionali.

sviluppo_db_NoSQL

Comprendere come usare MongoDB non è difficile ma richiede un nuovo modo di pensare al concetto di database . L’obiettivo di questo post è proprio quello di dare una primissima visione di schema design in MongoDB partendo dai fondamentali dei database relazionali e confrontando lo schema con i documenti MongoDB.

La differenza fondamentale tra un database relazionale e MongoDB è relativo alla modellazione dei dati.
Infatti, un database relazionale organizza le informazioni in tabelle e righe con strutture molto rigide mentre MongoDB permette di strutturare i dati in collezioni e documenti JSON.

Un documento JSON è un formato dati auto descrittivo e comprensibile dalle persone in modo naturale cosa che, come vedremo, diventa spesso complicata con i database relazionali qualora vi siano chiavi e riferimenti di dipendenza tra le tabelle.

Il formato JSON era nato in origine per favorire lo scambio di informazioni tra browser e server ma ora è usato in molti altri tipi di applicazioni come lo scambio di informazioni tra Server ed App, creazione di servizi di interfaccia e realizzazione di semplici file di configurazione a supporto degli script.

Ultimamente i documenti JSON si stanno dimostrando molto utili anche per la gestione dei dati infatti, attraverso la loro struttura chiave-valore, permettono di “trasferire” facilmente documenti tra database ed applicazioni senza la perdita di significato delle informazioni.

I documenti JSON permettono di gestire anche diverse tiplogie di dati come booleani, numeri, stringe e strutture dati come array e documenti innestati.

Tornando al database relazionale, possiamo dire che risulta essere ben progettato quando è in forma normale. Semplificando la definizione, un database si dice normalizzato se non presenta informazioni duplicate e l’aggiornamento dei dati avviene senza perderne l’integrità.
Per esempio, se volessimo rappresentare le auto di un’azienda automobilistica e le rispettive categorie di appartenenza, dovremmo strutturare le informazioni in questo modo:

Tabella dei veicoli di un’azienda:
tab_veicoli_azienda_01
Tabella delle categorie dei veicoli:
tab_categorie_02
Tabella delle aziende produttrici:
tab_azienda_03
Tabella delle categorie dei veicoli:
tab_veicolo_categoria_04
mentre in MongoDB si può creare una collezione con all’interno oggetti JSON di questo tipo:

{
“_id” : ObjectId(“012kt3399438025drt2567”),
“manufacturer” : “FIAT”,
“name” : “500”,
“categories” : [
“Utilitaria”,
“Vettura Compact”,
“Sport”
] }

I vantaggi si apprezzano soprattutto a livello di sviluppo in quanto, il fatto di poter disporre di un oggetto JSON (la conversione in JSON avviene tramite i driver MongoDB disponibili per i vari linguaggi di programmazione), permette una rapida manipolazione delle informazioni vista la notevole disponibilità di librerie per questo scopo.

Con questo post abbiamo cercato di incuriosire e muovere i primi passi verso un nuovo modo di organizzare i dati rispetto alle strutture rigide utilizzate con i database relazionali.

Il prossimo passo da fare è iniziare ad adottare MongoDB nei progetti aziendali per scoprire le potenzialità offerte e … attendere nuove sorprese dalla collaborazione tra zero12 e MongoDB.

Sei interessato A MongoDB? Partecipa al nostro Lab pratico per la progettazione di soluzioni MongoDB in ambito Internet of Things e Big Data! 

Festival_ICT_banner

Showing 5 comments
  • Michele
    Reply

    Salve, alcune domande da neofita di NoSQL.
    Nell’esempio si passa da un un insieme di tabelle relazionate tra loro ad un oggetto unico che contiene tutte le informazioni necessarie, ma ancora mi sfugge il passaggio da DB relazionali a un NoSQL come MongoDB. Prendiamo l’esempio dell’articolo, l’oggetto disegnato non si presta a ridondanza dei dati?
    Mettiamo che la tabella aziende produttrici abbia oltre al campo “produttore” un campo “descrizione”, “logo”, “indirizzo”, “sito” ecc.
    Nell’oggetto creato per MondoDB dovrei replicare tutte queste informazioni all’interno di ogni record?
    Ma anche rimanendo nell’esempio dato, se inserisco in modo ridondante il termine “FIAT” in ogni record nel momento che dovessi cambiare il valore ad esempio da FIAT a FCA dovrei cambiarlo in ogni record inserito anziché nella sola tabella produttori.
    Oppure ancora se volessi avere in backend un pannello di gestione delle anagrafiche dei produttori dovrei scorrermi tutti i record per capire quanti e quali produttori abbia inserito.
    Ho detto delle sciocchezze? Mi sta sfuggendo qualcosa?

    • s.dindo
      Reply

      Le sue osservazioni sono corrette e corrispondo ai dubbi tipici che affliggono tutti al passaggio da un database relazionale ad uno NoSQL.
      Sui database NoSQL è tipico un approccio basato sulla ridondanza delle informazioni perchè il costo di storage è sempre più basso quindi posso decidere, a seconda di come strutturo il mio applicativo, quali performance voglio ottenere e se il mio scopo è permettere l’accesso rapido a contenuti conviene replicare anche le informazioni.

      In un contesto come quello dell’esempio le possibili risposte alle sue domande sull’inserimento del produttore possono essere:

      1) Replico il campo produttore su tutti i documenti perchè a livello di workflow dell’applicativo devo disporre di tutte le informazioni rapidamente nel momento in cui interrogo un documento
      2) Posso creare una collection con l’insieme dei produttori, così da ottenere un object_id per produttore e poi referenziare tutti i documenti in cui uso il produttore FIAT così da ficiliare le operazioni di update

      Oppure posso usare usare anche altre soluzioni di schema design… tutto dipende dalla risposta di alcune domande che tipicamente ci si pone durante la fase di progettazione del software e l’attività di schema design come:
      1) Quali performance voglio ottenere in lettura e scrittura?
      2) Quante operazioni di update faccio nel produttore ? Devo garantire maggiori performance in scrittura e/o lettura perchè ne faccio diverse mentre le operazioni di update sono più rare e quindi posso permettermi di penalizzarle le performance di tale operazione?

      Sicuramente la replica dei dati può spaventare durante la fase di avvicinamento ai database NoSQL ma una volta scoperti i benefici della replica del dato ed imparato a gestirli in modo efficiente diventa tutto naturale

  • Marco
    Reply

    Ciao s.dindo,
    io mi trovo davanti allo stesso problema di Michele e ho bisogno di eliminare le rindondanze, vorrei creare una collection con l’insieme dei produttori e utilizzarme gli id come reference in tutti i documenti. Ma cè un processo automatico per fare questo? In particolare cè un modo automatico di sostituire a tutte le ripetizioni all’interno dei documenti il relativo id?

  • Stefano Dindo
    Reply

    Buongiorno Marco,
    mi scuso per il ritardo ma si tratta di un periodo veramente intenso in zero12 con molte scadenze.
    Per quanto riguarda la sua domanda è possibile usare il Map & Reduce di MongoDB per eliminare la ridondanza oppure l’aggregation framework mediante il quale è possibile fare un raggruppamento per chiave. L’aggregation framework in più offre, dalla 2.6, anche l’operatore $out che permette di mandare l’output su una nuova collection.
    Per quanto riguarda l’autonomia può crearsi uno script shell da gestire come vuole.

    Saluti

  • Ash
    Reply

    Io non userei mai degli id numerici. La trova una degenerazione del modello relazionale. Le chiavi dovrebbero essere sempre “parlanti”.
    In questo bellissimo articolo (che non ho scritto io) è spiegato il perché
    http://www.soft-land.org/documenti/pk
    Per quanto mi riguarda, il modello relazionale è decisamente avanti rispetto al paradigma ad oggetti quando si tratta di organizzare i dati nella giusta maniera. Penso che anche Ruby on Rails usa un approccio simile a MongoDB. Non ho mai usato Rails (invece sono un estimatore di Ruby) ma lo scetticismo resta.

Leave a Comment