Un’altra regola d’oro da tenere in considerazione nella progettazione delle tabelle di un database è questa: Un certo tipo di dato dovrebbe comparire una ed una sola volta in tutto il DB. Questa regola appartiene alla cosiddetta “normalizzazione” di un database. Oltre alle ragioni di gusto strettamente informatico, ciò che è interessante notare dal punto di vista di noi utenti è che se viene rispettata questa regola, non avremo mai risultati incoerenti e soprattutto dubbi su come e dove effettuare le ricerche e gli inserimenti. Facciamo un esempio: In quante tabelle e quante volte, nel nostro DB, avremo bisogno di reperire/inserire il campo “città”? Dove sei nato? Dove risiedi? Dove risiede la tua ditta? dov’è nato l’autore? e la casa editrice dove si trova? una o più città?
Ecco, un mucchio di volte avremo bisogno di recuperare il nome di una città. A questo punto non vi sorge il dubbio, pur da incompetenti, che sarebbe tanto di guadagnato fare riferimento sempre e comunque ad un unico elenco di città? Se risponderete “si”, allora siete sulla strada giusta. In una tabella “comuni” mettiamo l’intero compendio delle città italiane, scritte come si deve a prova d’errore, magari completa di dati strettamente correlati al comune (CAP generico, regione, codice Istat…). Qui potrete scaricare un esempio, purtroppo parzialmente incompleto, della tabella comuni. Dunque ora resta da spiegare un trucco tanto semplice quanto difficile da memorizzare per i principianti, su come praticamente fare riferimento a quest’unico contenitore di dati. Lo stratagemma è semplicissimo e consiste nel creare una “relazione” tra due tabelle. La ragione per cui vi ho esortati, nella lezione precedente, a non dimenticare mai di inserire in ogni tabella un ID_ contatore-chiave primaria è presto detto: L’ID, se vogliamo, può rappresentare bene l’intera riga (record) di dati, identificandola univocamente. Se il riferirsi alla “quarta riga” può creare nel tempo qualche dubbio (e se avessimo cancellato la terza riga in una certa occasione?), riferirsi all’ID_ numero 4 non può dare adito a dubbi: Se esiste è certamente quello giusto e porterà con sé, implicitamente, tutti i dati di quella riga.
Se in un’ipotetica tabella clienti Mario Rossi è l’ID_cliente numero 4, insomma, e se il nome ed il cognome sono il secondo ed il terzo campo della tabella clienti, dire “ID_cliente =4” è molto più rapido di “nome=mario, cognome=rossi, nato a… il.. codice fiscale…).
Dunque se vogliamo recuperare il cognome di Mario Rossi, nel nostro esempio basterà dire: “Tabella clienti, Terza colonna, ID_cliente=4“.
Insomma, abbiamo scoperto l’acqua calda di una procedura di “indicizzazione“. Orbene, questa apparentemente innocua banalità è in realtà la chiave di volta per comprendere le relazioni e vi aprirà un mondo insospettabilmente ricco e complesso nel quale bisogna imparare a destreggiarsi con una certa attenzione e, perché no, eleganza. Se torniamo all’esempio dei comuni fatto in precedenza, possiamo applicare ciò che abbiamo detto a proposito di Mario Rossi id_cliente=4 anche ai comuni! Il comune di Abbiategrasso, nel database comuni (Scaricatelo dalla sezione LAB-Download, 02), è indiscutibilmente il numero 58 (id_comune=58) come è facile vedere nell’immagine alla vostra sinistra (cliccate per ingrandire l’immagine). Non solo: possiamo notare che la seconda colonna è denominata codice_catastale e che solo la terza colonna comune contiene, appunto, la denominazione completa del comune.
A questo punto possiamo capire che se Mario Rossi (id_cliente=4) abitasse ad Abbiategrasso, potremmo tranquillamente riferirci al comune “id_comune=58” piuttosto che direttamente ad Abbiategrasso. Se poi dovessimo inserire manualmente ogni occorrenza di comune senza utilizzare questo sistema, chiedetevi:
- Quante volte scriveremmo Abiategraso, abiategrasso, ABBIATEGRASSSO….?
- Quanto spazio ci vorrebbe per memorizzare in formato testo (e non con un semplice numero), in ogni tabella ove il dato fosse necessario, ogni volta l’intero nome della città?
Qualcuno, sveglio, obietterà: “Ma è scomodo!”.
Non avrebbe torto: difficile ed alquanto scomodo dover risalire ogni volta al nome del comune partendo dal suo id_comune. Niente paura! Abbiamo un computer e un programma ben fatto. Attraverso un’operazione denominata “lookup” Access vi mostrerà il nome del comune (od altra informazione voi riteniate utile) come se, invece del numero 58, nel campo fosse scritto “Abbiategrasso”. Un’operazione di Lookup, altrove, potrebbe mostrarvi “nome e cognome insieme” come se, in luogo dell’ID_cliente, voi aveste a disposizione un unico campo “nome e cognome”.
Da qui, l’efficienza di Access. E siamo ancora all’inizio..