Come forse già saprai, i database utilizzano le tabelle per organizzare le informazioni. (Se non si ha una familiarità di base con i concetti del database, leggere Che cos'è un database?) Ogni tabella è composta da un numero di righe, ognuna delle quali corrisponde a un singolo record del database. Quindi, come fanno i database a mantenere tutti questi record dritti? È attraverso l'uso delle chiavi.
Chiavi primarie
Il primo tipo di chiave di cui discuteremo è la chiave primaria. Ogni tabella di database dovrebbe avere una o più colonne designate come chiave primaria. Il valore che detiene questa chiave dovrebbe essere univoco per ogni record nel database.
Ad esempio, supponiamo di avere una tabella chiamata Dipendenti che contiene informazioni sul personale per ogni dipendente nella nostra azienda. Dovremmo selezionare una chiave primaria appropriata che identifichi univocamente ciascun dipendente. Il tuo primo pensiero potrebbe essere quello di utilizzare il nome del dipendente. Questo non funzionerebbe molto bene perché è ipotizzabile che assumeste due impiegati con lo stesso nome. Una scelta migliore potrebbe essere quella di utilizzare un numero identificativo univoco del dipendente che si assegna a ciascun dipendente al momento dell'assunzione. Alcune organizzazioni scelgono di utilizzare i numeri di previdenza sociale (o identificatori governativi simili) per questa attività perché ogni dipendente ne ha già uno e sono garantiti come unici. Tuttavia, l'uso dei numeri di previdenza sociale a questo scopo è altamente controverso a causa di problemi di privacy. (Se lavori per un'organizzazione governativa, l'uso di un numero di previdenza sociale potrebbe anche essere illegale ai sensi del Privacy Act del 1974.) Per questo motivo, la maggior parte delle organizzazioni ha spostato l'uso di identificatori univoci (ID dipendente, ID studente, ecc. .) che non condividono questi dubbi sulla privacy.
Una volta che si decide su una chiave primaria e si imposta il database, il sistema di gestione del database impone l'unicità della chiave. Se si tenta di inserire un record in una tabella con una chiave primaria che duplica un record esistente, l'inserimento avrà esito negativo.
La maggior parte dei database è anche in grado di generare le proprie chiavi primarie. Microsoft Access, ad esempio, potrebbe essere configurato per utilizzare il tipo di dati Contatore per assegnare un ID univoco a ciascun record nella tabella. Sebbene sia efficace, questa è una cattiva pratica di progettazione perché ti lascia con un valore privo di significato in ogni record nella tabella. Perché non usare quello spazio per archiviare qualcosa di utile?
Chiavi esterne
L'altro tipo è la chiave esterna, che viene utilizzata per creare relazioni tra tabelle. Esistono relazioni naturali tra tabelle nella maggior parte delle strutture di database. Tornando al nostro database dei dipendenti, immagina di voler aggiungere una tabella contenente informazioni dipartimentali al database. Questa nuova tabella potrebbe essere chiamata dipartimenti e conterrebbe una grande quantità di informazioni sul reparto nel suo complesso. Vorremmo anche includere informazioni sui dipendenti nel reparto, ma sarebbe ridondante avere le stesse informazioni in due tabelle (Dipendenti e Dipartimenti). Invece, possiamo creare una relazione tra le due tabelle.
Supponiamo che la tabella Departments utilizzi la colonna Nome reparto come chiave primaria. Per creare una relazione tra le due tabelle, aggiungiamo una nuova colonna alla tabella Impiegati chiamata Reparto. Quindi, inseriamo il nome del dipartimento al quale appartiene ciascun dipendente. Informiamo anche il sistema di gestione del database che la colonna Dipartimento nella tabella Dipendenti è una chiave esterna che fa riferimento alla tabella Departments. Il database applicherà quindi l'integrità referenziale garantendo che tutti i valori nella colonna Reparti della tabella Impiegati abbiano voci corrispondenti nella tabella Reparti.
Si noti che non esiste un vincolo di unicità per una chiave esterna. Potremmo (e molto probabilmente lo faremo) avere più di un dipendente che appartiene a un singolo dipartimento. Allo stesso modo, non è necessario che una voce nella tabella Departments abbia una voce corrispondente nella tabella Employees. È possibile che avremmo un reparto senza dipendenti.
Per ulteriori informazioni su questo argomento, leggi Creazione di chiavi esterne.
