Nella fase di progettazione di una base di dati è possibile compiere numerosi errori la cui presenza può dar luogo a varie problematiche, tra cui per esempio:
- il rallentamento delle prestazioni;
- la ridondanza dei dati dovuta ad inutili duplicazioni;
- l'ambiguità nelle informazioni gestite;
- il malfunzionamenti nei meccanismi di relazione tra le tabelle;
- la scarsa affidabilità dovuta alla poca accuratezza dei dati:
- la scarsa protezione dell’integrità dei dati;
- la difficoltà nella lettura dei dati e della struttura delle tabelle.
Esistono fortunatamente degli accorgimenti che permettono di rendere più semplice ed efficace il lavoro di progettazione, in questo modo sarà possibile limitare i problemi e le lungaggini derivanti dalle necessità di aggiornamenti e correzioni.
Nel corso di questa breve trattazione verranno analizzati alcuni di questi accorgimenti sottolineandone le implicazioni pratiche.
Relazioni e quantità di tabelle e campi
La logica alla base dei database relazionali si fonda sul concetto che qualsiasi elemento debba rappresentare un’entità "atomica", quindi non ulteriormente scomponibile in altre entità, questa caratteristica è necessaria perché, nel momento in cui si fa riferimento ad un determinato dato, non deve sussistere alcun pericolo di ambiguità; ogni elemento di una relazione deve essere quindi distinguibile e riferito ad un unico oggetto, sia esso una chiave primaria, il nome di una tabella, il nome di un campo etc.
Ora, uno dei concetti più controversi tra quelli che regolano la progettazione di una base di dati, riguarda il fatto che risparmiando sul numero delle tabelle si ottengono sistemi di relazione meno complesse; in realtà, se da una parte un database meno articolato può risultare nell’immediato più leggibile, l’utilizzo di un’unica tabella può rendere la digitazione delle istruzioni SQL molto più complessa.
Quanto appena esposto si ricollega con il concetto di "normalizzazione", una insieme di metodi che permettono di suddividere le tabelle nei loro componenti univoci, in modo che ogni tabella rappresenti un unico elemento e i campi che la compongono riproducano, tramite attributi, la descrizione dell’elemento rappresentato dalla tabella.
A livello di linguaggio, la normalizzazione non rappresenta un limite, in un’istruzione SQL SELECT è infatti sempre presente una clausola FROM per indicare la tabella interessata da una query a cui è possibile associare una JOIN per relazionarsi ad una seconda tabella o a più tabelle. Vediamo, nella prossima pagina, un esempio.
Si ipotizzi di avere a disposizione una tabella sul modello della seguente:
| Id_cliente | Nome_cliente | Fattura1 | Fattura2 | Fattura3 | Fattura4 |
|---|---|---|---|---|---|
| 1 | Mattia Rossi | 212.50 | 314.70 | 430,65 | 524.89 |
| 2 | Paolo Bianchi | 577.44 |
Basta una prima osservazione per capire che ci si trova davanti ad una tabella mal strutturata; anche ammettendo che non si preveda di staccare più di quattro fatture per ogni cliente (cosa nella pratica molto improbabile), che senso avrebbe creare un campo per ogni fattura per non voler utilizzare più di una tabella? Inoltre, plausibilmente un buon numero di clienti saranno destinatari di meno di quattro fatture, in alcuni casi una sola, la tabella potrebbe quindi riempirsi velocemente di valori nulli.
Perché quindi non ricorrere a due tabelle separate, una destinata alla fatturazione e una ai clienti? Qui entra in gioco la normalizzazione, "clienti" e "fatturazione" sono infatti due entità in grado di rappresentare due concetti non ulteriormente scomponibili ma dotati di caratteristiche proprie; in ogni caso, le due tabelle potranno essere utilizzate per stabilire delle relazioni attraverso una chiave, come per esempio il campo Id_cliente, presente in entrambe le tabelle presentate di seguito.
Per cui potremmo normalizzare la tabella proposta in precedenza suddividendola in due nuove tabelle:
| Id_cliente | Nome_cliente |
|---|---|
| 1 | Mattia Rossi |
| 2 | Paolo Bianchi |
| Id_fattura | Id_cliente | Pagamento |
|---|---|---|
| 1 | 1 | 212.50 |
| 2 | 1 | 314.70 |
| 3 | 2 | 577.44 |
| 4 | 1 | 524.89 |
| 5 | 1 | 524.89 |
Lo stesso tipo di procedura potrà essere adottata per migliorare la struttura dei campi all’interno di una tabella; riprendendo la tabella "clienti" proposta in precedenza, è facile notare come in essa sia presente un campo denominato Nome_cliente, ora si ipotizzi di voler estrarre tutti i record in cui il cognome del clienti è Rossi, per far questo sarà necessario utilizzare un’interrogazione basata sul comando LIKE:
SELECT Nome_cliente FROM clienti WHERE Nome_cliente LIKE ‘%Rossi’;In linea generale è però possibile affermare che, per ottenere lo stesso risultato, un Database manager impiega meno tempo ad eseguire una query SELECT basata sulla clausola WHERE che una basata sulle ricerche con LIKE, questo perché nel primo caso viene effettuato un semplice confronto, mentre nel secondo il DBMS affronta il parsing di più valori.
Per cui la tabella clienti potrà essere riproposta nel modo seguente:
| Id_cliente | Nome_cliente | Cognome_cliente |
|---|---|---|
| 2 | Mattia | Rossi |
E la ricerca sulla base del cognome potrà essere effettuata sul modello della seguente:
SELECT Nome_cliente, Cognome_cliente FROM clienti WHERE Cognome_cliente = ‘Rossi';In alcuni casi, può essere utile il processo contrario rispetto a quello della normalizzazione, chiamato appunto "denormalizzazione", da utilizzare con particolare cautela per evitare accuratamente i problemi legati alla ridondanza; essa consiste nell’accorpare attributi appartenenti a diverse relazioni in una sola relazione, come nel caso della creazione di attributi che includono i dati ottenuti da relazioni esterne.
Si pensi ad una tabella dedicata all’editoria in cui è presente un campo che prevede il totale dei libri scritti per ogni autore, questo conteggio potrà essere ottenuto anche sommando tutti i record relativi ad un autore in una tabella dedicata ai titoli dei libri; quale soluzione scegliere? In entrambi i casi abbiamo svantaggi e svantaggi:
- una tabella normalizzata non metterà immediatamente a disposizione il dato relativo al conteggio dei titoli per ogni autore, ma eviterà la produzione di ridondanza;
- una tabella denormalizzata richiederà un aggiornamento a carico dello stesso dato (e quindi una gestione più complessa) ma offrirà informazioni immediatamente leggibili.
Accorgimenti per la progettazione
Non è semplice stabilire a priori quale sia la regola più affidabile per la progettazione di un database, in linea generale è però possibile dire che una base di dati ben strutturata si caratterizza per il fatto di non necessitare di continui aggiornamenti e correzioni sia in fase di sviluppo che in fase di produzione.
A questo scopo, può essere buona norma non passare immediatamente alla strutturazione delle tabelle, ma far precedere questo passaggio alla realizzazione di un semplice progetto da disegnare su carta o attraverso un apposito programma, i vantaggi di questo modo di procedere sono indiscutibili:
- permette di risolvere gran parte dei problemi legati alla struttura e intervenire su eventuali anomalie senza dover agire direttamente su di essa coinvolgendo i dati gestiti;
- può essere velocemente condiviso con altri amministratori per la valutazione del progetto;
- consente di stimare i costi, i benefici e gli eventuali tempi di realizzazione necessari per una determinata base di dati e per l’applicazione che dovrà interagire con essa.
Durante la fase di progettazione sarà inoltre importante tenere presenti alcuni obiettivi fondamentali per la strutturazione di un database, esso infatti:
- deve essere semplice da modificare;
- deve essere facile da utilizzare;
- deve essere pensato tenendo a mente le esigenze di coloro che dovranno utilizzarlo;
- deve aiutare a risolvere problemi, non crearne di nuovi in fase di gestione.
Un buon metodo per progettare un database è quello di isolare tutti gli oggetti che potrebbero entrare a far parte della struttura di un database, ad esempio:
Clienti
Prodotti
Ordini
….
Gli oggetti non sono altro che i nomi delle tabelle che faranno parte della base di dati, per cui sarà necessario eliminare tutte le voci non necessarie per l’applicazione che dovrà interagire con essa; a questo punto, una volta scelti gli oggetti da utilizzare, sarà utile associare ad ognuno di essi delle caratteristiche fondamentali (attributi), esse verranno successivamente convertite in nomi di campi:
| Tabelle | Campi |
|---|---|
| Clienti | nome, cognome, telefono, indirizzo, email.. |
| Prodotti | nome, codice, modello, prezzo.. |
| Ordini | quantità, cliente, sconto, modalità di spedizione.. |
Dalla tabella proposta si nota come con questo tipo di procedura sia possibile isolare i fattori di relazione, si noti infatti come la voce “cliente” sia un degli attributi della tabella “Ordini”, permettendo di relazionare ogni ordine con il rispettivo cliente che l’ha effettuato.
A questo punto sarà possibile associare ad ogni campo un tipo di dato e passare alla fase di strutturazione.
Conclusioni
In questa breve trattazione, dedicata in particolare agli utenti alle prime armi, è stato affrontato l’argomento relativo agli accorgimenti necessari per limitare al minimo gli errori durante la progettazione delle basi di dati.
Per far questo sono state esposte alcune cattive pratiche, con relative correzioni, e alcune buone pratiche in grado di rendere il lavoro di progettazione e strutturazione più agevole ed efficace.
