Nel suo libro (SQL Programming Style (The Morgan Kaufmann Series in Data Management Systems), Joe Celko, insiste molto su

alcuni punti che vengono spesso disattesi.

La scelta di una buona chiave primara è uno di questi. Secondo Celko una chiave deve avere alcune priorietà:

1. Unicità
   la chiave non deve avere duplicati

2. Stabilità
   all’interno dello schema e nel tempo

3. Familiarità
   il significato deve essere immediatamente interpretabile

4. Validazione
   deve essere possibile comprendere subito la validità del dato

5. Verificabilità
   deve esistere un metodo per verificare la chiave

6. Semplicità
   una chiave deve essere il più semplice possibile, ma non più semplice
   

Si capisce bene come la tipica chiave id autoincrementale sia quanto di peggio uno possa scegliere al momento di progettare un database. D’altra parte non è sempre facile trovarne una che rispetti tutte le proprietà, o almeno la maggior parte.

[ad#ad-articolo-1]

Un esempio può chiarire meglio: una tabella che debba contenere gli elementi chimici, può usare il suo simbolo (massimo due lettere) come chiave primaria. E’ unico, stabile (al massimo vengono aggiunti elementi), familiare (i più comuni sono universalmente conosciuti anche senza aver studiato chimica), può essere convalidata (una chiave sbagliata non corrisponde ad alcun elemento), è verificabile (basta consultare la tabella degli elementi), è semplice.

Di recente ho avuto la necessità di raggruppare per regione alcuni dati, che vengono forniti suddivisi per comune.

L’approccio più naturale alla questione è quello di usare tre tabelle: una per i comuni, una per le province, una per le regioni. Esistono su Internet liste di tutte e tre queste entità a cui poter attingere per popolare le tabelle.

Ma quale chiave usare? Per le province il problema è già risolto dallo Stato Italiano: è sufficiente usare la sigla di ogni provincia che, per legge, deve rispettare tutte le proprietà summenzionate.

Per quanto riguarda le regioni invece ho pensato di usare l’abbreviazione di tre lettere come da regolamento (appendice A) del Nic italiano per i domini geografici. Quindi Tos sarà la Toscana, Pdm il Piemonte, Abr l’Abruzzo, e così via. Oltre alla regione Trentino-Alto Adige, ho scelto di includere anche tra le regioni  le province autonome di Bolzano e Trento, usando per loro la sigla della provincia, poiché anche i dati sono così suddivisi.

E per i comuni? Esiste in effetti una codifica decisa dall’Agenzia del Territorio: il cosiddetto codice catastale. Sono i quattro caratteri, una lettera e tre numeri, che compaiono nel codice fiscale di ognuno a indicare il comune di nascita. Ogni comune ne ha uno assegnato e sebbene non sia immediatamente identificabile è sempre meglio di un numero incrementale.

A tale proposito ho trovato il progetto CPComuni, che per la parte relativa al database pensavo avrebbe potuto fare al caso mio, almeno fino a che non ho dato un’occhiata all’SQL. Un disastro.

Per i comuni vengono usate chiave numeriche incrementali scelte arbitrariamente: neanche in ordine alfabetico, ma in ordine alfabetico per provincia. Non esiste una tabella per le province. Sono invece inserite in quella denominata ‘regioni’, che rappresenta il vero e proprio problema di questa struttura.

Le regioni sono raggruppate per area geografica, che viene ripetuta insieme alla regione stessa tante volte quante sono le province

che contiene. Inoltre la chiave della tabella ‘regioni’ è… il codice (numerico) della provincia!

Non sono usate foreign keys che quindi non hanno alcun costraint. Che succede se aggiungo una provincia?

Questo implica che il database non rispetti neanche la prima forma di normalizzazione. La tabella delle regioni andrebbe perlomeno divisa in tre: province, regioni, aree geografiche (se proprio devono essere mantenute…).

L’unico aspetto positivo di questo schema è che può essere portato a esempio di come non progettare un database, peraltro semplice (tre tabelle!).

Infine, l’ultimo aggiornamento è del 2006 e pertanto non sono incluse le province di recente entrate in vigore.

Ho pensato quindi di mettere a disposizione di chi ne avesse bisogno la struttura di quello che ho creato rispettando quanto detto sopra.

Ho usato l’elenco prelevato dal sito dell’Agenzia del Territorio, escluso ogni duplicato (i vecchi nomi dei comuni non mi servivano), collegato le tre tabelle.

E’ un file SQL realizzato per MySQL, ma non dovrebbe essere difficile adattarlo ad altri database. Lo trovate qui.