Come fare la progettazione di un database

Principi di progettazione

In informatica, la progettazione di un database è un processo nel quale viene scelta la migliore rappresentazione della realtà che si vuole descrivere, della natura dei dati e dei requisiti che l’applicazione deve soddisfare.
I principi di progettazione di un database relazionale sono ben stabiliti e seguono una serie di regole ben precise. Il modello relazionale si basa su due concetti, relazione e tabella, di natura diversa ma facilmente riconducibili l’uno all’altro. La nozione di relazione proviene dalla matematica, in particolare dalla teoria degli insiemi, mentre il concetto di tabella è semplice e intuitivo. Le tabelle risultano naturali e comprensibili anche per gli utenti finali, d’altra parte la disponibilità di una formalizzazione semplice e precisa ha permesso anche uno sviluppo teorico a supporto del modello.

Inoltre la progettazione di una base di dati segue un determinato procedimento in modo da garantire principalmente la generalità rispetto alle applicazioni e ai sistemi, la qualità del prodotto in termini di correttezza, completezza e efficienza rispetto alle risorse impiegate e la facilità d’uso dei modelli di riferimento.

Nell’ambito delle basi di dati relazionali, ad esempio MySQL, si è consolidata negli anni una metodologia di progetto che ha dato prova di soddisfare le proprietà descritte. Tale metodologia è articolata in tre fasi: la progettazione concettuale, il cui scopo è di rappresentare le specifiche informali della realtà di interesse; la progettazione logica, che consiste nella traduzione dello schema concettuale ottenuto dalla fase precedente nel modello di rappresentazione dei dati adottato dal sistema di gestione di base di dati; la progettazione fisica nella quale lo schema logico viene completato con la specifica dei parametri fisici di memorizzazione.

Invece MongoDB manca di regole per la progettazione, in quanto non applica alle collezioni e ai documenti nessun tipo di schema in quanto utilizza prevalentemente uno schema libero. Pertanto la progettazione di uno schema con MongoDB è spesso il risultato di una profonda conoscenza del database che si sta utilizzando, dei requisiti database che si sta utilizzando, dei requisiti che l’applicazione deve soddisfare, del tipo di dati che si andranno a memorizzare e delle operazioni e aggiornamenti che si dovranno applicare ai dati memorizzati. Da questo si evince che in MongoDB lo schema non è solo in funzione dei dati che si andranno a memorizzare ma bisogna anche focalizzare l’attenzione su come i dati verranno utilizzati dalle applicazioni.
Nonostante la mancanza di regole precise ci sono delle linee guida che possono servire allo scopo di progettare uno schema che soddisfi le nostre esigenze. Il primo aspetto da considerare è proprio la struttura di un documento di una collezione.

In MongoDB non c’è una specifica dichiarazione dei campi all’interno dei documenti di una collezione, in quanto MongoDB non richiede che i documenti abbiano la stessa struttura. Tuttavia nella pratica la maggior parte delle collezioni sono omogenee in modo da facilitarne l’utilizzo sia da parte di progettisti e programmatori ma anche da parte di utenti casuali.
Una domanda chiave che ci si deve porre quando si progetta uno schema con MongoDB è quando incorporare documenti all’interno di altri, embed, e quando collegare i documenti, link. L’incorporamento è l’annidamento di oggetti e array all’interno di un documento BSON. I link sono riferimenti tra documenti. Le operazioni all’interno di un documento sono facili da eseguire e avvengono sul lato server, invece i riferimenti devono essere trattati sul lato client e l’applicazione effettua operazioni su documenti riferiti emettendo interrogazioni dopo che il documento è stato ritornato dal server.

In generale c’è una semplice regola che funziona per la maggior parte degli schemi ma che non deve essere presa come assoluta: incorporare quando gli oggetti figli appaiono sempre nel contesto del genitore, in caso contrario memorizzare gli oggetti figli in una collezione separata.
Prendiamo come esempio un’applicazione che debba memorizzare dei post pubblicati su un sito web e i relativi commenti ai post. La scelta tra incorporare o linkare dipende dall’applicazione. Se i commenti appaiono sempre all’interno di un post e non c’è bisogno di ordinarli in un modo arbitrario, come ad esempio per data o per importanza, incorporare i commenti all’interno di un documento post magari sotto forma di un array di documenti è un’opzione valida in quanto fornisce prestazioni migliori in lettura. Se invece l’applicazione deve essere in grado di mostrare i commenti dal più recente senza considerare su che post i commenti appaiano, allora è meglio usare i riferimenti e memorizzare i commenti in una collezione separata.

Altro aspetto da considerare sono le operazioni atomiche che l’applicazione deve eseguire, l’aspetto chiave in termini di progettazione di schema è che il campo di applicazione delle proprietà atomiche è il documento, pertanto dobbiamo assicurare che tutti i campi rilevanti per le operazioni atomiche siano nello stesso documento.

Di seguito viene presentato un elenco delle opportune regole da seguire durante la progettazione di uno schema:

1. Gli oggetti che sono di livello superiore come importanza in genere hanno la loro collezione;
2. Relazioni molti a molti generalmente sono rappresentate con collegamenti;
3. Collezioni che contengono pochi oggetti possono tranquillamente esistere come collezioni distinte, in quanto l’intera collezione è rapidamente memorizzata nella cache del server dell’applicazione. E’ più difficile ottenere un livello di visualizzazione per documenti incorporati, per ottenere un’operazione del genere si deve utilizzare il map-reduce;
4. Se le performance sono un problema, incorporare.