In questa fase, partendo dall’analisi dei requisiti, si devono definire le tabelle, stabilire i campi di ogni tabella e le caratteristiche di ogni campo. Infine si devono definire le relazioni esistenti tra le tabelle.

Iniziamo con la definizione delle tabelle.
Dall’analisi dei requisiti risulta che ci sono 4 oggetti da rappresentare: libri, autori, case editrici e mobili. Ogni oggetto corrisponde ad una tabella. Per le prime tabelle non ci sono problemi, mentre per i mobili si può fare una considerazione: per quanto detto nell’analisi dei requisiti, avremo sempre 4 scaffali e 4 ripiani, che possono essere memorizzati direttamente all’interno della tabella libri (si vedrà in seguito come). Quindi, si riduce a tre il numero di tabelle.
Un altro problema riguarda le categorie: il numero delle categorie potrebbe essere grande e variare continuamente (per nuovi libri acquistati), conviene considerare le categorie come un oggetto separato, memorizzato in una tabella a parte. Si passa di nuovo a quattro tabelle.

Per ogni tabella si devono definire i campi e le caratteristiche dei campi.
Si può procedere creando uno schema su un foglio di carta per ogni tabella, simile ai seguenti, rappresentati nelle figure 7.01 – 7.04.
 

 
FIG. 7.01
 

La proprietà richiesto significa che non può esistere, sul database, un libro senza un valore in quel campo, la proprietà indicizzato verrà spiegata in seguito.
Le dimensioni dei campi dovrebbero risultare dall’analisi dei requisiti, si dovrebbe accertare quanto lunghi possono essere, al massimo, i valori da inserire.
 

 
FIG. 7.02
 

 
FIG. 7.03
 

 
FIG. 7.04
 

Dopo aver definito le tabelle, con tutte le proprietà dei campi, si passa alla definizione delle relazioni.
Si considera una tabella per volta e si cerca di capire se ci sono collegamenti con altre tabelle.
Un libro può avere più autori, un autore può aver scritto più libri. La relazione sarebbe molti a molti, ma, per come è stata definita l’analisi dei requisiti (per semplificare), la relazione è uno a molti: si è detto nell’analisi “se un libro ha più autori, si memorizza solo il primo”. Quindi, per noi e solo per noi, un libro ha un unico autore, un autore può avere più libri, la relazione è uno a molti. Il lato uno è la tabella Autori, il lato molti è la tabella Libri.
Un libro ha una sola casa editrice, una casa editrice ha più libri. La relazione è uno a molti, la tabella case editrici rappresenta il lato uno, la tabella libri il lato molti. Non può esistere un libro con due case editrici, infatti questo significherebbe che si possiedono due copie della stessa opera, per esempio Divina commedia di Alighieri dante, di due case editrici. Queste due copie sono due oggetti (o meglio record) separati, memorizzati in due righe diverse. È importante capire cosa si memorizza nell’archivio: noi vogliamo memorizzare il testo “fisico”, cioè il libro che abbiamo acquistato, non l’opera per sé stessa.
Un libro corrisponde ad una categoria, una categoria corrisponde a più libri. La relazione è uno a molti, la tabella libri è il lato molti, la tabella categoria è il lato uno.
Conviene tracciare uno schema grafico, simile a quello della figura 7.05.
 

 
FIG. 7.05
 

Non è ancora finita, si deve procedere con la normalizzazione delle tabelle.
Come si è visto nel capitolo 6, si devono verificare tutte le regole, una alla volta.
La prima regola dice che ogni tabella deve avere una chiave primaria.
Nello schema fatto sopra non sono state definite le chiavi primarie delle tabelle (sarebbe stato meglio farlo subito, ma come primo esempio è più utile vedere gli errori possibili e le soluzioni).
La tabella libri non possiede chiavi candidate, infatti l’unico che sembrerebbe adatto è il campo titolo. Due opere non dovrebbero avere lo stesso titolo (non è proprio così), ma il database non memorizza le opere (come detto sopra), ma memorizza il libro acquistato, quindi potrebbero coesistere nell’archivio più libri con lo stesso titolo. Si deve aggiungere un campo che chiameremo IdLibro (identificativo del libro), come tipo di dato sarà un numero (in seguito vedremo che si chiamerà contatore).
La tabella autori non ha chiavi candidate, quindi anche in questo caso si deve aggiungere un campo, che chiameremo IdAutore, sempre numerico.
La tabella case editrici ha un campo candidato, che è il nome della casa editrice, non possono esistere due ditte con lo stesso nome. Il campo chiave primaria della tabella case editrici è in relazione con il campo chiave esterna della tabella libri, quindi si deve riportare ogni volta il nome della casa editrice. Questo è uno spreco di memoria (come si vedrà quando saranno trattati i tipi di dati in Access), quindi conviene aggiungere un nuovo campo chiave primaria di tipo numerico (che occupa meno memoria, meno byte) che chiameremo IdCasaEditrice.
Lo stesso ragionamento vale anche per la tabella Categorie, che avrà quindi un nuovo campo IdCategorie, chiave primaria.

Le altre regole (ogni campo deve contenere un solo valore, i campi di una tabella non devono dipendere da altri campi, evitare le ripetizioni e la ridondanza dei dati) sono tutte rispettate.

Ridisegnamo gli schemi delle tabelle, con le nuove caratteristiche, figure 7.06 – 7.09), mentre quello delle relazioni rimane tale e quale.
 

 
FIG. 7.06
 

 
FIG. 7.07
 

 
FIG. 7.08
 
 

 
FIG. 7.09