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à: ne scegliamo subito tre, ossia il collaboratore, il set di competenze di un collaboratore ed il progetto. Senza ancora scendere al livello di collegamento "materiale" tra documenti, possiamo individuare già, su un piano più concettuale, delle relazioni funzionali come quella che intercorre tra l'entità-collaboratore e l'entità-competenze, nonchè quella tra le entità collaboratore e progetto;
- struttura interna dei documenti: anche se - come abbiamo ribadito più volte - non dobbiamo decidere a priori una struttura generale degli oggetti, sarebbe bene comunque avere un'idea di massima delle proprietà che essi devono contenere, cosa che risulta utile in fase di progettazione del software che utilizza il database. Per il collaboratore, decidiamo di inserirne quattro (nome, cognome, luogo e data di nascita). I documenti-competenza conterranno una forma più variegata: esisteranno tante proprietà quante sono le competenze, ognuna delle quali sarà valorizzata con un numero intero compreso tra 4 e 10. Ogni progetto sarà costituito da un documento in cui verrà inserito il nome attribuitogli, una data di inizio ed un flag booleano che determinerà se è ancora in corso o meno. Per le operazioni pratiche di inserimento e modifica dei dati, si può fare riferimento alla guida a MongoDB di HTML.it, facendo eventualmente uso del client visuale RoboMongo, da cui è tratta l'immagine seguente.
Figura 1. Documenti collaboratore (click per ingrandire)
- scelta dei documenti da annidare: finora, abbiamo deciso le proprietà interne dei documenti, ma ancora non abbiamo scelto se li immaginiamo annidati in altri o "indipendenti". Decidiamo di rendere indipendenti i documenti di tipo progetto e collaboratore; prevediamo, inoltre, due collection all'interno del database, in cui custodirli scissi per tipo.
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: le relazioni più dinamiche - quelle in grado di agganciare gli oggetti che abbiamo scelto di lasciare "indipendenti" - vengono realizzate tramite
ObjectId. Ad esempio, all'interno dei documenti di tipo Progetto avremo un array diObjectIdrelativi ai collaboratori che vi prenderanno parte. L'immagine seguente mostra tali legami su RoboMongo:Figura 2. Riferimenti tramite ObjectID (click per ingrandire)
Mediante gli
ObjectId, devono essere curati anche gli aspetti relativi alla navigabilità. Potremmo ad esempio porci ulteriori domande per decidere se un collaboratore può partecipare ad un solo progetto alla volta o a più di uno, e se vogliamo conservare anche all'interno del documento relativo al collaboratore gliObjectIddei progetti in cui è stato coinvolto. Da un punto di vista tecnico, il tutto si potrà risolvere aggiungendo ulteriori proprietà ai documenti, scegliendo di organizzarle singolarmente o strutturate in array. Da un punto di vista pratico, spesso tali dubbi trovano risposta nelle policy aziendali delle realtà che stiamo modellando, nonchè nelle specifiche soluzioni software che utilizzeranno il database vero e proprio.
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.