Questo è il primo esempio, che porteremo avanti per tutto il manuale,
di progettazione e realizzazione di una base di dati. Tutte le scelte
sono attuate per semplificare al massimo la realizzazione del primo database,
lo scopo è quello di fornire un’idea e un metodo (semplice) per
risolvere anche problemi più complessi di quelli analizzati.
Si inizia con la caratterizzazione del “problema” da risolvere.
PROBLEMA
Siamo interessati a memorizzare i libri di casa, sia quelli scolastici
sia quelli di narrativa, sia tutti gli altri generi. I libri possono essere
di diverse case editrici e autori (se un libro ha più autori, si
memorizza solo il primo). Sono sistemati in due mobili diversi, uno con
degli scaffali, l’altro con dei ripiani.
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.