Quando progettiamo un’applicazione che, per funzionare, ha la necessità di interagire con dei dati, quasi certamente dovremo includere tra i nostri strumenti un database.
Quale tipo di database scegliere sarà oggetto di un altro articolo; supponiamo ora che la nostra soluzione richieda una base dati canonica, associabile al tipo di database più comune: un database relazionale.
Quali sono gli strumenti che possono aiutarci quando abbiamo la necessità di modellare i dati per il nostro database?
La letteratura disponibile sull’argomento è talmente vasta e articolata da non poter essere resa in maniera esauriente in un articolo di questo tipo, che mira a parlare più degli strumenti che della teoria che sta loro dietro.
Ci limiteremo quindi a una breve introduzione che spieghi di che cosa si tratta e, soprattutto, a che cosa serve.
Per funzionare in maniera efficiente e, al contempo, garantirci un livello di manutenibilità accettabile, una base dati relazionale deve contenere dati strutturati sia in modo da evitare ridondanze ma anche imprecisioni.
Quindi dovremo individuare quali attributi faranno parte di una certa entità e quale devono finire in un’altra. Le entità diventeranno tabelle e gli attributi saranno i campi del nostro database.
La prima fase di individuazione consiste appunto nel raggruppare gli attributi e associarli all’entità corretta. Supponiamo di dover gestire un preventivo: data e numero finiranno nell’entità Preventivi, mentre ragione sociale sarà un dato di Clienti.
La seconda fase è la gestione delle ridondanze. Un esempio molto semplice, sempre restando in tema di preventivazione, sono le voci: visto che un preventivo può essere composto da più righe, se dovessimo mantenere tutto nella tabella Preventivi dovremmo creare una serie di campi articolo 1, articolo 2 e via dicendo.
Oltre all’inefficienza di una soluzione del genere, ci troveremmo in difficoltà a gestire casi in cui il numero di righe eccede il numero di campi previsti in anticipo.
La soluzione, in breve, è di spostare queste informazioni in una tabella dedicata Righe preventivi.
La terza fase è un po’ più sottile e riguarda il modo in cui vogliamo strutturare il dato.
Supponiamo di voler considerare il nostro preventivo come un’opportunità di vendita. Quindi, oltre a presentare un’offerta a un potenziale cliente, il nostro documento dovrà essere monitorato: abbiamo contattato il cliente dopo qualche tempo per sapere che ne pensa? L’offerta è stata accettata, respinta, abbandonata?
Se decideremo di riportare queste informazioni in un campo note, avremo un quadro della situazione solo a patto di entrare nell’offerta e leggere tutta la cronistoria.
Non potremo avere un promemoria che ci avvisi di ricontattare il cliente, perché anche se il dato è presente, è affogato in un mare di altri dati non strutturati.
Allo stesso modo non potremo avere un resoconto trasversale di tutte le offerte e la relativa situazione, a meno di non riportare una parte delle informazioni presenti nel campo note in un altro campo, ad esempio stato offerta. Facile? Sicuramente. Efficiente? Decisamente no.
Tutte queste operazioni, e molte altre, vengono solitamente raccolte sotto la definizione di normalizzazione. Quando procediamo a modellare i nostri dati per un database relazionale è buona norma tenere conto di questi precetti di base indicati dalle regole di normalizzazione.
Ma vediamo quali sono gli strumenti più indicati per metterli in pratica.
Non ci stiamo riferendo al (poco) glorioso software che accompagna Windows da sempre, ma al suo progenitore: il bloc notes cartaceo.
In una prima fase della progettazione, quando ancora stiamo ragionando su come ripartire le nostre informazioni, partire da un foglio di carta aiuta a mettere a fuoco i processi e ad avere un’evidenza di che cosa appartiene a un’entità e che cosa a un’altra.
Non è essenziale, in questa fase preliminare, scendere troppo nel dettaglio: possiamo partire elencando le tabelle che abbiamo identificato durante l’analisi preliminare.
Messe su carta queste entità, possiamo indicare sommariamente le relazioni principali e le chiavi utilizzate.
Una volta che avremo il quadro generale, possiamo passare alla fase successiva.
Questa fase solitamente si rende necessaria soltanto per i modelli dati più complessi, che richiedono una mappa visuale dettagliata di tutta la struttura di tabelle, relazioni e chiavi del sistema.
In casi del genere, partiremo riportando lo schema cartaceo all’interno del software.
Dopodiché inizieremo a definire le chiavi primarie, le chiavi esterne, la cardinalità delle relazioni - ovvero utilizzeremo diversi elementi grafici per indicare se, ad esempio, una relazione è uno a molti, se richiede che sia presente o meno un record correlato e via dicendo.
Oltre a ciò cui potremo aggiungere eventuali indicazioni per le condizioni di integrità referenziale (“se elimino un preventivo, che cosa deve succedere alle sue righe?”), definire i predicati delle relazioni stesse (“che chiavi usa la relazione tra preventivi e righe? E quali operatori?”), via via fino a definire indici, sequenze e tanto altro.
Un’attività di questo tipo è utile a prescindere, perché ci costringe a mettere a fuoco molti aspetti del nostro sistema molto prima di metterlo in piedi. Tuttavia, in casi poco complessi si può passare direttamente dal foglio di carta allo strumento di gestione del nostro database.
Un approccio alternativo, specialmente se non intendiamo servirci di uno strumento in grado di generare la base dati per conto nostro, è di utilizzare un software pensato come sostituto del blocco note.
Strumenti del genere, nati solitamente come idea processor, possono rimpiazzare in maniera abbastanza soddisfacente l’accoppiata blocco di carta/ERD, purché dispongano di un set di stencil in grado di rappresentare Entità e Relazioni.Proprio perché sono pensati per rappresentare dei flussi, questi strumenti sono solitamente abbastanza amichevoli e informali da consentirci di fare prove, abbozzi e correzioni in maniera rapida e, spesso, non fanno rimpiangere il foglio di carta.
Una volta completato lo schema della nostra base dati, potremo riprodurre lo schema qui definito tramite lo strumento di gestione del database che abbiamo deciso di utilizzare.
Ora che disponiamo di un documento progettuale per la nostra base dati, è il momento di costruirla.
Chiaramente vale il concetto: “Più lavori prima, meno lavori dopo”.
Se il nostro strumento è FileMaker, non ci sono procedure che consentano di creare una base dati direttamente da un ERD; per contro la creazione di campi e tabelle è talmente rapida che con un modello dettagliato sotto gli occhi probabilmente l’intera operazione prenderà comunque poco tempo.
Anche la definizione delle relazioni è un’operazione molto rapida.
Una nota a margine: l’indicazione della cardinalità - la zampa di gallina che appare da Clienti a Preventivi o da Preventivi a Righe - è legata alle condizioni di univocità definite per i campi chiave: se la chiave esterna non è definita come valore univoco (e nella stragrande maggioranza non lo è), FileMaker rappresenterà la relazione come uno a molti, altrimenti la relazione sarà uno a uno.
Se invece lavoriamo con una base dati SQL, dipende dall’ERD utilizzato: molti software di questo tipo consentono di esportare degli script che, dati in pasto allo strumento di gestione del database sono in grado di ricostruire il database da zero.
Anche servendoci dell’ausilio di strumenti del genere, però, è molto probabile che dovremo rimettere mano alla struttura, specialmente se nel nostro sistema abbiamo definito relazioni lato database che non siano naturali, ovvero relazioni non basate sul canonico rapporto chiave primaria > chiave esterna.
Per progettare correttamente una base dati lo strumento più importante resta comunque il nostro cervello: potremo dotarci degli strumenti migliori presenti sul mercato, ma se le nostre competenze non raggiungono un livello adeguato, il nostro modello dati risulterà poco efficiente.
Naturalmente non serve portare i precetti della normalizzazione ai loro estremi. La cosa importante è di conoscere le regole principali e le motivazioni che le rendono importanti: in questo modo potremo decidere se e quando è il caso di ignorarle.
Le risorse per farsi una cultura sull’argomento non mancano: quindi daremo solo qualche spunto.
Per chi ama leggere, in italiano suggeriamo Basi di Dati (Atzeni, Ceri, Fraternali, Paraboschi e Torlone, edito da McGraw-Hill) e in inglese Database Design for Mere Mortals, di Michael Hernandez.
Acquisite le basi, a chi volesse passare direttamente a uno strumento software, suggeriamo di provare a lavorare con Whimsical. Anche Lucid ha svariate frecce nel proprio arco e merita un test.
Ma, prima di scegliere un software, vi invitiamo a non sottovalutare l’efficacia del bloc notes, specialmente se accompagnato da una buona dotazione di gomme da cancellare.