Questa è la definizione del problema, cioè dell’archivio che si intende creare, da sola non è sufficiente per capire come lavorare con Access o con un altro DBMS, come è stato spiegato nei capitoli precedenti, si deve fare l’analisi dei requisiti. Trattandosi dei libri di casa, l’analisi dei requisiti consiste nello scrivere, anche solo con carta e penna, una lista di requisiti, cioè di oggetti da rappresentare considerando tutte le caratteristiche, è importante fare con accuratezza questa lista, senza saltare niente, altrimenti la realizzazione della base di dati risulterebbe sbagliata. Se si trattasse di un archivio più complesso, per esempio richiesto da un cliente, il procedimento sarebbe più lungo (si dovrebbe interrogare il cliente stesso).

ANALISI DEI REQUISITI

Cosa siamo interessati a rappresentare:
Si vogliono memorizzare i libri di casa, i dati che interessano sono il titolo, l’autore, la casa editrice, la categoria (per esempio narrativa, informatica, medicina), prezzo d’acquisto e posizione (in quale mobile è sistemato).
Siamo interessati anche a memorizzare alcune informazioni sugli autori, quali il cognome, il nome, eventualmente il nome vero se sono conosciuti con uno pseudonimo, l’anno di nascita (se conosciuto), l’eventuale anno di morte (se conosciuto), il luogo di nascita e la nazionalità.
I mobili nei quali sono disposti i libri sono due, il primo ha 4 scaffali, il secondo ha 4 ripiani. Pensiamo che non cambieremo questi mobili per lungo tempo.
Per la casa editrice si vuole memorizzare anche l’indirizzo internet e il numero di telefono (se conosciuti).

Dati che non possono mancare:
Un libro è caratterizzato per sua natura dal titolo e dall’autore, questo significa che non potrà esistere sulla tabella che rappresenta i libri un record senza titolo e autore, non avrebbe nessun significato. Si desidera inoltre che ogni libro sia memorizzato con la casa editrice e la categoria.
Per gli autori gli unici dati importanti sono il cognome e il nome, gli altri dati possono mancare (questo non andrebbe bene se l’archivio fosse quello di una biblioteca o di una libreria).

Altre caratteristiche (in seguito le chiameremo integrità referenziali):
Quando eliminiamo (o aggiorniamo) una casa editrice, tutti i libri corrispondenti devono essere eliminati.
Quando eliminiamo (o aggiorniamo) un autore, tutti i libri corrispondenti devono essere eliminati.

Ancora una volta si sottolinea il fatto che l’analisi dei requisiti è strettamente personale, ognuno di noi potrebbe pensarla in modo completamente differente. Quella utilizzata in questo capitolo non è un’analisi dei requisiti completa, mancano alcuni argomenti che non sono ancora stati trattati, si vedranno in seguito direttamente con Access.

PROGETTAZIONE

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
   

CONCLUSIONI

Con questo capitolo si intende mostrare un modo di lavorare, ne esistono molti altri, migliori o peggiori, lo scopo è solo quello di dare l’idea di cosa si deve fare prima di creare il database con Access o con qualsiasi DBMS. Il prossimo capitolo consiste in un altro esempio.