PROGETTO DEL SISTEMA

In questa fase si definisce lo schema della base di dati. A partire dal risultato dell’analisi dei requisiti, si deve strutturare l’archivio, definendo gli insiemi omogenei di dati (tabelle), i “campi di interesse” di ogni insieme (colonne delle tabelle), le caratteristiche di ogni campo (si tratta di un testo, di una data, di un numero, ecc.) e le relazioni tra gli insiemi (i collegamenti tra le tabelle).
Il risultato di questa fase è lo schema della base di dati, “redatto” con carta e penna. Questo schema è indipendente dal DBMS che poi sarà utilizzato per realizzare il database.

ESEMPIO. Semplice progetto.
Una società che propone corsi di informatica vuole creare una base di dati per memorizzare gli iscritti e i corsi frequentati. L’analisi dei requisiti seguente non è reale, è stata creata appositamente per rendere semplice l’esempio, altrimenti lo schema risultante sarebbe troppo complesso da capire con i pochi concetti introdotti. Sono stati appositamente ridotti i requisiti dell’archivio, per arrivare ad avere esattamente due tabelle.
ANALISI DEI REQUISITI
La nostra società organizza corsi di informatica aperti a chiunque. Ogni corso prevede un nome del corso, un insegnante, un’aula, un orario di inizio e di termine delle lezioni, i giorni della settimana in cui le lezioni sono proposte e un prezzo. Degli iscritti siamo interessati a memorizzare il cognome, il nome, l’indirizzo, il numero di telefono e il corso a cui si iscrivono.
Questa analisi non è completa, come detto sopra, ma per semplicità teniamo conto delle seguenti considerazioni, valide solo per l’esempio, ma improponibili nella realtà:

punto elenco Una persona si può iscrivere ad un solo corso alla volta, se si iscrive a più corsi si procede come se fosse un nuovo iscritto, cioè un’altra persona.
punto elenco Non si tiene conto dei pagamenti.
punto elenco Non sono considerati gli insegnanti, che nella realtà dovrebbero essere memorizzati con i loro campi di interesse.
punto elenco Non si tiene conto del calendario, cioè numero del giorno, mese e anno delle lezioni.

Analizzando la pseudo analisi dei requisiti si individuano subito due insiemi di dati omogenei: i corsi e gli iscritti. Questi due insiemi li rappresentiamo con due tabelle distinte, una delle quali si chiamerà TabellaCorsi, l’altra TabellaIscritti. Per ogni tabella si deve stabilire quali sono i campi di interesse, cioè le colonne che compongono la tabella. La figura 3.02 visualizza le rispettive tabelle.
 

 
FIG. 3.02
 

Nello “schema” iniziale, i nomi delle colonne sono messi nelle righe, per risparmiare spazio, in modo da vedere insieme tutte le tabelle (nell’esempio sono solo 2, ma potrebbero essere molte di più in una situazione reale).
Si devono poi stabilire le relazioni tra le tabelle. Si vede che le due tabelle hanno un oggetto comune: NomeCorso, questo significa che un dato accomuna le due tabelle, cioè le mette in relazione. Le relazioni verranno trattate dettagliatamente più avanti, per ora accenniamo solo che si deve fare un ragionamento simile al seguente: per come è stata stilata l’analisi dei requisiti, una persona può iscriversi ad un solo corso, un corso può avere più iscritti. Si dice che esiste una relazione uno a molti tra le tabelle Corsi e iscritti.
Per ogni colonna si deve stabilire un nome e un “tipo di dati”, cioè se si tratta di testo, numeri o altro, figura 3.03.
 

 
FIG. 3.03
 

Dopo aver definito le tabelle, i campi e le relazioni tra le tabelle, si deve fare la NORMALIZZAZIONE delle tabelle. Questo argomento verrà trattato dettagliatamente in seguito, perché sono necessari alcuni concetti che ancora non abbiamo definito. Per il momento si può dire che, per la normalizzazione, si parte dallo schema delle tabelle e relazioni appena costruito e si controlla se questo corrisponde a dei canoni “standard” di correttezza delle tabelle. Se gli insiemi definiti non corrispondono a questi canoni, si devono modificare le tabelle, con le regole che verranno spiegate nel capitolo 6.