Non esistono soluzioni valide universalmente per la progettazione di un database, l'organizzazione di una banca dati è infatti una procedura dipendente dal tipo di applicazione che si desidera realizzare. Vi sono delle semplici regole che è possibile seguire al fine di strutturare basi di dati che consentano di archiviare e manipolare dati in modo semplice ed efficiente.
Nella progettazione di un database è fondamentale tenere presente alcune caratteristiche basilari:
- il numero delle tabelle che verranno coinvolte dalle interrogazioni lanciate tramite le applicazioni;
- il numero e il tipo di campi che verranno da creare all'interno delle tabelle;
- le relazioni interne ed esterne tra i campi.
Le relazioni sono il punto saliente della fase di progettazione, maggiore sarà il numero di relazioni che si sarà in grado di stabilire, più efficiente sarà la struttura del database, più breve sarà il codice da digitare per le applicazioni e inferiore sarà l'esigenza di generare nuovi campi o di memorizzare più volte gli stesso dati.
La logica della progettazione
Progettare un database, in particolare nel caso dei database relazioni come quelli gestiti da un DBMS MySQL, significa definirne la struttura, le caratteristiche e i contenuti gestiti cercando di prevedere quelle che saranno le esigenze dell'applicazione che avrà accesso ai dati; già da questa prima affermazione è possibile introdurre una regola di valore generale: è buona norma progettare il database prima dell'applicazione e non il contrario, la motivazione di questa affermazione è semplice: l'applicazione andrà a gestire i dati contenuti nella base di dati, quindi, migliore sarà la struttura della banca dati più efficiente sarà l'applicazione.
In pratica, progettare un database consiste nella costruzione di un modello di realtà, una base di dati non è altro che un archivio a cui è possibile inviare, attraverso un DBMS, delle interrogazioni sotto forma di query; le query non sono altro che delle "domande", un database dotato di una struttura lineare sarà in grado di rispondere in modo semplice a domande semplici, a livello tecnico la possibilità di inviare semplici domande ottenendo il massimo risultato significa creare applicazioni dotate di codici meno complessi.
La fase di progettazione di un database non può naturalmente prescindere dal tipo di applicazione che si desidera realizzare, le applicazioni vengono scritte per degli scopi (ad esempio: un database manager che gestisca i post di un sito Web), quindi anche i database a cui esse si interfacciano dovranno perseguire gli stessi scopi (conservare i dati relativi alle news); gli scopi per cui si progetta un database possono essere suddivisi in due categorie:
- scopi correlati ad esigenze operative: archiviare, mantenere e amministrare informazioni su entità animate (individui accomunati da specifiche caratteristiche), inanimate (oggetti, come dei prodotti) o astratte (ad esempio i prezzi dei prodotti);
- scopi correlati ad esigenze decisionali: le decisioni possono essere prese esclusivamente sulla base delle informazioni disponibili, migliore sarà la struttura del database più immediato sarà l'accesso alle informazioni.
La progettazione di una base di dati necessita generalmente di più fasi la cui finalità è quella di generare un modello (o astrazione) in grado di fornire la rappresentazione delle informazioni gestite e delle relazioni esistenti tra di esse.
Le fasi della progettazione
La progettazione di un database relazione si basa su un modello chiamato ER (EntitàRelazione), dove con il termine di entità si identificano delle persone, degli oggetti (anche astratti) o eventi dotati di determinati attributi; gli attributi hanno il compito di definire quelle che sono le proprietà delle entità mentre le relazioni non sono altro che le correlazioni esistenti tra le entità. In un modello di rappresentazione della realtà sotto forma di database, le entità saranno indicate da tabelle e gli attributi da campi, i record (cioè le informazioni gestite) consentiranno di stabilire le relazioni esistenti sulla base di valori.
Con la prima fase della progettazione di un database secondo il modello ER, si ha la cosiddetta "analisi dei requisiti", i requisiti possono essere distinti in quattro categorie:
- analisi delle caratteristiche dei dati;
- analisi delle operazioni da effettuare sui dati;
- analisi degli eventi che possono influenzare i dati;
- analisi dei vincoli d'integrità, cioè delle proprietà relative a informazioni ed eventi.
Alla fase descritta deve seguire quella più attinente al modello ER che consiste nell'elaborazione di una struttura che sia in grado di fornire una rappresentazione della realtà di cui il database sarà modello; le informazioni relative ai dati, alle entità, ai loro attributi e agli eventi che le coinvolgono saranno già state raccolte nella fase precedente, la seconda fase impone di porre in relazione quanto analizzato.
A questo punto sarà possibile passare alla fase in cui sarà cioè necessario definire quali tabelle dovranno essere create, quali relazioni dovranno sussistere tra di esse e internamente ad esse e a quali vincoli saranno sottoposte le relazioni.
Fatto questo, si passerà alla fase della realizzazione del database attraverso il DBMS, i comandi inviati durante questa fase dipenderanno fondamentalmente dalle decisioni prese durante le fasi precedenti.
L'unico modo possibile per mettere in relazione delle entità differenti è quello di stabilire la presenza in essi di specifici elementi, si ha così un riferimento a quelle che sono le "regole di integrità" che sanciscono l'obbligo di prevedere elementi comuni in entità distinte; si pensi per esempio al Campionato di Calcio di Seria A, tutti i giocatori che vi partecipano sono calciatori di prima divisione, è però possibile suddividerli in gruppi sulla base di una relazione dovuta alla squadra di appartenenza.
Inoltre, sempre secondo le regole di integrità, deve essere possibile l'accesso ai dati senza ambiguità, quindi ogni singolo valore deve essere indirizzabile specificando il nome della relativa tabella, della colonna e della "chiave primaria" del record corrispondente; una chiave primaria non è altro che l'attributo di un'entità, in grado di identificare in modo univoco un elemento appartenete all'entità stessa. La targa attribuita ad un veicolo dalla motorizzazione civile è per esempio un identificativo univoco grazie al quale distinguere un'auto dal resto del parco macchine nazionale.
Esempio pratico di progettazione basata sul modello relazione
Fondamentalmente il modello ER prevede tre tipi di relazioni:
- uno ad uno: ad esempio il codice fiscale che identifica univocamente un cittadino rispetto all'Agenzia delle Entrate;
- uno a molti: una stessa azienda emette più fatture per diversi clienti;
- molti a molti: il calendario di un campionato di Calcio prevede che tutte le squadre giochino tra di loro.
Un possibile esempio di relazioni tra entità è quello della costruzione di un database per gestire i prestiti in una biblioteca, l'analisi dei requisiti farà emergere l'esigenza di creare un sistema che permetta la gestione di entità (libri, iscritti e prestiti) sulla base di eventi; il riferimento al modello ER consentirà di stabilire una struttura in cui per i diversi libri posseduti sia definibile una relazione interna (tutti i libri in prestito sono in relazione così come lo sono quelli ancora disponibili) ed esterna (quella tra i libri e gli iscritti che li hanno presi in prestito o restituiti).
La prima tabella da creare sarà quindi quella relativa ai libri posseduti:
| id_libro | titolo | autore | stato |
|---|---|---|---|
| 1 | L'amore del bandito | Massimo Carlotto | Buono |
| 2 | Il lupo e il filosofo | Mark Rowlands | Ottimo |
L'identificativo univoco è quindi quello relativo al valore del campo "id_libro" che non potrà essere ripetuto, ma all'interno della tabella esistono anche altre relazioni: sarà possibile ricercare i libri relativi ad un determinato autore così come tutti quelli che sono conservati nello stesso stato.
Si passi ora alla tabella degli iscritti:
| id_iscritto | nome | cognome | indirizzo | |
|---|---|---|---|---|
| 1 | Giuseppe | Garibaldi | Via Teano | g.garibaldi@imille.it |
| 2 | Linus | Torvalds | Via Kernel | tor@valds.it |
Anche in questo caso i record relativi agli iscritti potranno essere distinti in modo univoco grazie al relativo identificativo, in questo modo sarà possibile evitare ambiguità dovute ad eventuali omonimie.
Si passi ora alla tabella relativa ai prestiti e alle restituzioni:
| id_prestito | Id_libro | id_iscritto | data_prestito | data_restituzione | reso |
|---|---|---|---|---|---|
| 1 | 2 | 2 | 2009-09-08 | 2009-09-28 | 0 |
| 2 | 1 | 1 | 2009-09-05 | 2009-09-25 | 1 |
Essa permette di mettere in relazione i diversi libri con gli iscritti che li hanno presi in prestito, consente quindi di stabilire una relazione tra i record presenti nella tabella dei libri con quelli della tabella degli iscritti; inoltre essa consente di stabilire delle relazioni interne, sarà infatti possibile selezionare e contare:
- tutti i libri prestati ad un determinato iscritto;
- tutti gli iscritti che hanno preso in prestito un determinato libro o soltanto quelli che lo hanno restituito o solo quelli che non lo hanno ancora riportato;
- tutti i libri prestati o restituiti in una determinata data;
- tutti i libri in prestito così come quelli disponibili.
Quelli proposti sono soltanto alcuni esempi di relazioni concepibili nella progettazione di un database, la struttura di una banca dati può naturalmente essere implementata o semplificata sulla base dell'applicazione che si desidera realizzare.
Conclusioni
La progettazione di un database non è di per sé una procedura particolarmente complessa, ma può variare molto a seconda dei progetti del programmatore e delle esigenze del software che si dovrà interfacciare al DBMS per la manipolazione dei dati; in questa breve trattazione sono state esposte alcune regole di base per realizzare una banca dati con attenzione a quelle che sono le indicazioni del modello relazionale.
