Il modello relazionale ha un

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.