Come progettare un database

La progettazione di un database è un aspetto cruciale nello sviluppo di una qualsiasi attività informatica, sia se strettamente legato ad un progetto di analisi dei dati, sia se più in generale correlato allo sviluppo di un software o di un sito web.  È prassi suddividere il processo di ideazione e creazione di un database in tre stadi:

• progettazione concettuale
• progettazione logica
• progettazione fisica

All’interno di queste fasi standard avviene un continuo processo di raffinamento, man mano che le specifiche del business e le soluzioni tecnologiche da utilizzare diventano più chiare: questo processo di miglioramento tecnico e funzionale può prendere il nome di normalizzazione o de-normalizzazione.  Nel primo caso vengono favorite le operazioni di aggiornamento e scrittura del database, nel secondo caso le scelte sono orientate a delle performance migliori in fase di lettura e analisi dei dati.

La progettazione concettuale

La progettazione concettuale consiste nell’identificazione delle entità di business che devono essere rappresentate all’interno del database. L’output di questa prima fase è rappresentabile su un foglio di carta, nel senso che il lavoro non dipende dallo specifico software informatico che sarà scelto e utilizzato nella fase successiva (progettazione logica) per implementare concretamente il database.

La progettazione concettuale segue generalmente uno di questi due approcci:

• progettazione E-R (entità – relazione): ci si chiede quali siano le entità presenti nel business e che vogliono essere rappresentate, quali attributi le descrivono e quali sono le relazioni tra esse.
• star schema: ci si chiede quali sono i fatti che avvengono all’interno di un business, da quali dimensioni sono descritti e da quali valori sono misurati.

La progettazione logica

Analizzando l’output finale della progettazione concettuale sarà possibile scegliere la tipologia di database più idonea ad implementare concretamente gli oggetti individuati. Molto spesso la scelta è orientata verso i database relazionali (a questo link https://www.oracle.com/it/database/what-is-a-relational-database/ trovi un approfondimento), quelli cioè dove i dati sono organizzati e strutturati in tabelle. Sono possibili, tuttavia, anche altre scelte come database documentali, dove i dati sono organizzati in documenti Json, o graph database.

Una volta decisa la tipologia di database, occorrerà scegliere il particolare DBMS (Database Management System) da utilizzare. Tra i database relazionali le scelte più famose sono MySql, Oracle, Sql Server o PostgreSql, mentre tra i database non relazionali sono scelte comuni MongoDb o Neo4j.

In ogni caso occorrerà tradurre gli oggetti della progettazione concettuale in oggetti del database tramite il relativo linguaggio di programmazione. Nel caso più comune dei database relazionali tradurremo le entità in tabelle e gli attributi in colonne tramite il linguaggio SQL (Structured Query Language). Più delicata è la questione sulle relazioni: esse possono essere convertite a volte in tabelle a volte in colonne in base alle loro caratteristiche.

A questo link trovi un corso per approfondire la conoscenza dell’SQL per interrogare e progettare un database relazionale https://www.yimp.it/corso-introduzione-sql-database-relazionali/.

La progettazione fisica

L’ultimo stadio nel processo di creazione di un database è la progettazione fisica. Si tratta di una parte molto delicata in quanto si agisce sulla struttura interna dei database per migliorarne le performance, generalmente tramite la creazione di indici (a questo link trovi un approfondimento sugli indici https://www.hostingtalk.it/indici-sql-cosa-sono-come-funzionano/).

Come accennato in precedenza, non esiste una ricetta già pronta per questa fase.  Ogni attività potrebbe da un lato migliorare le performance delle operazioni di lettura, dall’altro peggiorare i tempi di caricamento e aggiornamento del database.

Diventa dunque fondamentale seguire le best practice raccomandate dagli esperti del settore, effettuare un numero sufficiente di test in ambiente di sviluppo prima del passaggio in produzione e poi monitorare costantemente le performance per individuare colli di bottiglia e aree di miglioramento. Possiamo dire dunque che la progettazione fisica è un processo vivo e dinamico, da testare e migliorare continuamente.