FIG. 4.01
 

La figura 4.01 rappresenta lo schema della tabella, quello che abbiamo chiamato METADATI, la tabella vera e propria si avrà solo dopo la realizzazione del database, con l’inserimento delle informazioni. Per il momento si stanno analizzando le caratteristiche principali, in seguito si studieranno in dettaglio tutti i tipi di dati e le relative proprietà.
Le informazioni riguardanti gli studenti saranno memorizzate sulle RIGHE della tabella. Ogni riga contiene un unico elemento o soggetto: ogni studente sarà registrato su una sola riga, se due righe memorizzano le stesse informazioni (stesso nome, cognome, data di nascita, ecc.), quelle due righe rappresentano, per l’archivio, due persone diverse. I dati memorizzati in una riga, che rappresentano un elemento della tabella, si chiamano RECORD. Un record può essere per esempio uno studente, un libro, un cliente. È possibile che ci siano informazioni mancanti in alcuni campi di un record, per esempio uno studente potrebbe non avere il numero di telefono.
La figura 4.02 visualizza un esempio di tabella con record.
 

 
FIG. 4.02
 

La scelta dei campi e delle relative proprietà dipende dalla base di dati che deve essere realizzata. La stessa tabella, con lo stesso nome e che rappresenta lo stesso tipo di elementi, in database diversi potrebbe essere caratterizzata da campi diversi.

ESEMPIO.
Di seguito sono visualizzate diverse possibili tabelle per rappresentare le persone, in ambiti differenti. I campi, per problemi di spazio, sono rappresentati sulle righe.
La figura 4.03 visualizza una tabella che memorizza un elenco di iscritti ad un corso.
 

 
FIG. 4.03
 

La figura 4.04 visualizza una tabella che memorizza un elenco di dipendenti di un’azienda.
 

 
FIG. 4.04
 

La figura 4.05 visualizza una tabella che memorizza un elenco di clienti.
 

 
FIG. 4.05
 

Tutte queste tabelle hanno come “soggetto” persone, ma i campi di interesse sono completamente diversi. Senza un’analisi dei requisiti accurata, la realizzazione della tabella dipendenti potrebbe essere completamente diversa, a seconda di chi realizza l’archivio. È solo attraverso l’analisi dei requisiti che si può stabilire esattamente quali campi deve avere una tabella e quali proprietà devono avere i campi stessi.

CHIAVE PRIMARIA

Il modello relazionale ha un “difetto”: i record di una tabella possono essere ripetuti. Non esiste un sistema, semplice e pratico, per controllare che lo stesso record non sia digitato due volte, su due righe diverse della stessa tabella. Questo può comportare gravi errori nel lavoro del database, si rischia di ottenere risultati sbagliati.

ESEMPIO.
Le tabelle utilizzate sono state semplificate.
SI utilizza un archivio per registrare gli iscritti ai corsi di informatica, il database è composto da più tabelle (questa situazione non è reale). La figura 4.06 visualizza la tabella dei partecipanti.
 

 
FIG. 4.06
 

Come si vede, l’impiegato che ha registrato le iscrizioni ha commesso un errore: ha ripetuto due volte il signor Rossi Mario. La figura 4.07 visualizza la tabella dei corsi, con i relativi iscritti.
 

 
FIG. 4.07
 

Il problema, che il database non può risolvere, è: l’iscritto al corso di Access Rossi Mario, corrisponde al primo record della tabella 4.06 o al quarto?

Ogni volta che si verifica una situazione di questo tipo, il database “va in crash”, o comunque non si comporta correttamente. Per evitare questo problema, è necessario definire, in ogni tabella, una chiave primaria.
Ogni tabella di un database relazionale (e in particolare di Access) dovrebbe avere una chiave primaria. La CHIAVE PRIMARIA è un campo della tabella, scelto dal realizzatore, che identifica in modo univoco ogni record della tabella stessa. In ogni tabella si deve trovare un campo i cui valori non siano mai ripetuti nelle righe dell’intera tabella, esempi di valori simili possono essere la partita IVA, il codice fiscale, la targa e il numero di serie.
Se non esiste un campo con tali caratteristiche, si deve aggiungerne uno: di solito si usa un identificatore, per esempio IdPersona, IdCliente, IdProdotto.
Nella fase di progettazione, dopo aver definito le tabelle e i relativi campi, si deve scegliere una chiave primaria per ogni tabella. Può succedere di incontrare tabelle senza chiave primaria, ma è una situazione anomala e rarissima.
La chiave primaria non risolve completamente il problema dell’esempio precedente, ma solo una parte.

ESEMPIO. Chiave primaria.
La figura 4.08 visualizza la stessa tabella dei partecipanti dell’esempio precedente, con l’aggiunta di una chiave primaria (codice).
 

 
FIG. 4.08
 

La figura 4.09 visualizza la tabella degli iscritti.
 

 
FIG. 4.09
 

In questo caso è ovvio che il numero 1 nella tabella 4.09 corrisponde alla prima riga della tabella 4.08, non alla quarta. La chiave primaria garantisce che i dati della tabella 4.09 siano sempre coerenti con i dati della tabella 4.08.
Il problema che rimane, e che non può essere risolto con mezzi semplici, è che per errore si potrebbe iscrivere Rossi Mario, con numero 4, al corso di Excel, invece di Rossi Mario, con numero 1. Questo non genera errori gravissimi, come nel caso precedente, ma comunque si possono generare situazioni anomale. Si supponga di stampare un elenco delle persone e dei corsi da loro frequentati, il risultato sarebbe quello visualizzato nella figura 4.10.
 

 
FIG. 4.10
 

Mentre Bianchi e Verdi risultano iscritti a due corsi, Rossi Mario, numero 1, risulta iscritto ad un solo corso. Non ha importanza che ci sia un altro record con gli stessi dati (valori), numero 4, infatti, ogni record corrisponde ad una persona diversa.
 

In una tabella ci possono essere più campi candidati ad essere la chiave primaria: CHIAVI CANDIDATE. In termini più semplici, possono esistere nella stessa tabella più colonne i cui valori non sono mai ripetuti, ognuna di queste potrebbe diventare la chiave primaria. Spetta a chi progetta la base di dati stabilire quale campo deve essere definito chiave primaria, la scelta non dipende solo dalle caratteristiche del campo stesso, ma anche dalle “funzioni” del database.

ESEMPIO. Codice fiscale.
Il campo codice fiscale è potenzialmente valido come chiave primaria, in quanto non possono esistere due persone con lo stesso valore di codice. Non è detto però che si possa o si debba necessariamente definire il codice fiscale come la chiave primaria di una tabella. Come si è visto negli esempi precedenti, il valore della chiave primaria viene riportato anche su altre tabelle, con il codice fiscale risulterebbe un’operazione onerosa in termini di tempo. L’impiegato addetto ad inserire i dati dovrebbe ricordare i codici fiscali di centinaia o migliaia di persone diverse, in caso contrario dovrebbe consultare la lista e copiare il codice. Sarebbe molto più semplice ricordare un numero o una sigla (molto più corti del codice fiscale). Si può anche incontrare il problema di iscritti stranieri, provenienti da una nazione senza il codice fiscale, in quel caso il campo dovrebbe rimanere vuoto. Ma, proprio perché per definizione la chiave primaria non può avere ripetizioni, non è permesso saltare il valore del campo chiave primaria, si deve inserire per forza un valore.
 

È possibile definire più campi insieme come chiave primaria, ma di solito non si usa, perché, come si è visto poco fa, i valori della chiave primaria sono ripetuti anche su altre tabelle, con grande spreco di memoria e tempo per inserire i dati ripetuti.

ESEMPIO.
Si definisce una tabella Persone con i seguenti campi: Cognome, Nome, Indirizzo, Cap, Città, Data di nascita, Numero di telefono e Indirizzo Internet. Si vuole definire la chiave primaria, ma nessuno dei campi può essere considerato chiave candidata, in quanto tutti possono avere ripetizioni. Si potrebbero definire come chiave primaria i campi Cognome, Nome, Data di nascita e Città contemporaneamente, cioè tutti insieme, è molto difficile avere ripetizioni, considerando i valori di questi quattro campi insieme. Questo è possibile e corretto per un database, ma, come detto sopra, comporta grossi sprechi se si devono indicare le persone in altre tabelle (per esempio quella delle iscrizioni), in quanto si devono riportare tutti quattro i campi.

CONCLUSIONI

Si parte dal risultato dell’analisi dei requisiti e si stabiliscono i “soggetti” della base di dati, per ogni soggetto si crea una tabella.
Si analizza ogni tabella e, sempre basandosi sul risultato dell’analisi dei requisiti, si definiscono i campi e le relative proprietà.
Infine si deve scegliere una chiave primaria per ogni tabella. Se non esistono chiavi candidate, o se quelle presenti non sono “comode”, si aggiunge un campo con tali caratteristiche.
Non è sufficiente che un campo abbia le caratteristiche per essere la chiave primaria, in Access (anche negli altri programmi) si deve utilizzare un comando per indicare ad Access tale proprietà.