Progettazione a documenti: un esempio

In questa lezione vedremo un esempio pratico di progettazione di un database NoSQL su MongoDB. Dovremo gestire il parco collaboratori di un'azienda informatica che archivia, per ognuno di essi, un set di tre competenze settoriali che viene valutato con un voto compreso tra 4 e 10. Oltre ai collaboratori, l'azienda tiene nota dei progetti avviati, e ad ognuno di essi associa un elenco di collaboratori che ne compongono il team.

Progettazione passo passo

Scegliamo di risolvere il problema mediante un database "a documenti". Ci troviamo infatti nella tipica situazione in cui molte informazioni possono essere aggregate in oggetti più complessi (i documenti), ed essendo questi rappresentazioni di un numero limitato di entità, verrà spontaneo organizzarli in collection. Queste ultime potranno quindi essere navigabili trasversalmente grazie a relazioni e oggetti embedded. Ci muoveremo a passi come abbiamo visto nella lezione precedente:

• individuazione delle possibili entità
• struttura interna dei documenti guida a MongoDB RoboMongo
  Figura 1. Documenti collaboratore (click per ingrandire)
  
  
  
• scelta dei documenti da annidare progetto collaboratore collection
  Ciò risulta comodo per vari motivi. Innanzitutto, sono gli elementi protagonisti del nostro problema, che consiste essenzialmente nel creare team di programmatori per portare a termine dei progetti. Inoltre, si tratta di insiemi piuttosto mobili, in quanto i collaboratori possono sempre essere aggiunti o rimossi dall'elenco ed i progetti vengono generati in continuazione. Tra progetti e collaboratori verrà stabilito pertanto un collegamento dinamico che equivarrà ad associare un collaboratore ad un lavoro, o mutare le risorse assegnate ad una data attività per accelerarne il completamento entro i termini di scadenza. Quelli che appaiono assolutamente idonei ad essere annidati all'interno di altri sono quelli che rappresentano le competenze del collaboratore e, come presumibile, saranno proprio innestati in un documento di quest'ultimo tipo, come era già visibile nella figura precedente. Dei vantaggi e svantaggi della realizzazione di oggetti embedded, si è già discusso nella guida a MongoDB
• realizzazione delle relazioni e navigazione ObjectId Progetto ObjectId
  Figura 2. Riferimenti tramite ObjectID (click per ingrandire)
  
  
  

  Mediante gli ObjectId navigabilità ObjectId

Note sulla flessibilità del NoSQL

I documenti contenenti le competenze ci offrono un altro spunto di riflessione: le proprietà al loro interno cambiano molto da documento a documento. Una struttura interna variabile in termini di nomi e numero delle proprietà non ci preoccupa, dal momento che in MongoDB non dobbiamo fissarla all'inizio. Ciò rappresenta un eviidente vantaggio rispetto ai database relazionali.
I progettisti di questi ultimi infatti rischiavano di essere messi in crisi da casi simili: un numero di proprietà variabile per un record si sarebbe tradotto o nella necessità di predisporre più campi dei quali usarne solo alcuni o, più comunemente, nella creazione di relazioni molti-a-molti (pensiamo per fare un parallelo a due tabelle contenenti, rispettivamente, l'elenco dei collaboratori e
delle proprietà possedute). Nell'uso pratico, essi richiederebbero l'uso di JOIN piuttosto penalizzanti in termini di prestazioni. Questa flessibilità di struttura è uno dei vantaggi di MongoDB e altre realtà NoSQL, ed è quello che in casi del genere renderebbe questi strumenti più adatti rispetto alle alternative del mondo relazionale.