Se ognuno di voi fosse in grado di comprendere fino in fondo l’importanza della frase che segue, probabilmente una buona parte dei problemi (e dei drop-out) sarebbe risolto.
Dire che le Tabelle, in Access come in qualunque
DBRMS, sono “meri contenitori di dati strutturati” significa fondalmentalmente questo: DIMENTICATE ciò che avete imparato a fare con Excel, Calc o qualunque foglio elettronico e pensate alle tabelle nella foro forma più semplice: contenitori di dati che non fanno altro che controllare che il dato che andiamo ad immettere sia coerente con ciò che è previsto e null’altro.
Ci vuole fiducia. Lo so. Nel tentativo di “abbreviare i tempi” molti di voi si ritroveranno presto con un bel “e’ tutto da rifare” davanti.
Lo dico non per scoraggiarvi, anzi. Per incoraggiarvi ad andare avanti ma sulla strada giusta, per evitare di girare in tondo.
Non spenderò altre parole a riguardo. Spero che abbiate capito. Se avete capito davvero allora leggete il resto.
Le tabelle sono contenitori di dati organizzati in righe e colonne: due dimensioni. Ogni riga si chiama record, ogni colonna si chiama campo. Quando create una tabella in Access, i campi vengono rappresentati temporaneamente in orizzontale (vedi immagine più avanti), offendovi una grande quantità di possibili opzioni. Queste opzioni servono ad effettuare un primo controllo, accurato ma “elementare”, sul contenuto di ogni singolo campo. In questo modo avremo la certezza che in un campo data non potrà andarci a finire un codice fiscale. Se inseriremo un numero negativo in un campo numerico dove sono previsti solo numeri maggiori di 10, il numero negativo non sarà accettato.
Nell’ottica del “trash-in, trash-out” questo tipo di controlli sono certamente i benvenuti. Essi sono in tabella semplicemente perché è giusto che sia così: A pensarci bene, Excel non rende un buon servizio tentando di “interpretare” i nostri bisogni: Nelle mani di una persona distratta una tabella excel può diventare in breve tempo un vero e proprio colabrodo…Questo non vuol dire che io ne sconsigli l’utilizzo: E’ uno strumento eccezionale per alcune operazioni e per la stampa di diagrammi di ogni genere. Viceversa NON è lo strumento giusto per costruire/gestire un database.
Le tabelle dunque svolgono un “lavoro” ignoto alla maggior parte degli utenti, anche ad una buona parte degli “addetti ai lavori” che non si occupano di database. Una tabella è sempre vista come un contenitore multifunzionale e totipotente: Dobbiamo dimenticare questa impostazione concettuale riducendola moltissimo. Preferisco sempre esagerare piuttosto che lasciare margini passibili di interpretazioni eccessivamente personalizzabili: limitatevi il più possibile ad utilizzarle come contenitori di dati. Evitate di scriverci direttamente e soprattutto di visualizzarle direttamente. Di queste funzionalità si occuperanno le query e le maschere.
I dati in tabella devono essere omogenei e coerenti. Questo concetto è complicatissimo e sarà il vostro scoglio principale. A ben vedere, però, non è così difficile entrare nel corretto ordine di idee: In una tabella destinata a contenere le anagrafiche dei clienti, ad esempio, che campi prevedereste di utilizzare?
Innanzi tutto, regola importantissima, un ID_cliente, settato come contatore/chiave primaria. Un campo contatore è davvero speciale: Si incrementa da solo e non torna “sui suoi passi”: se cancelliamo lo IC_cliente numero 5, per una qualunque ragione, non potrà mai più esistere un ID_cliente numero 5. Col tempo apprezzerete questo comportamento e ne capirete il senso. Per ora, fidatevi: deve funzionare così. Altri tipi di numerazioni e conteggi andranno, semplicemente, affrontati e realizzati diversamente. Spesso i neofiti tentano di ottenere i risultati che vogliono raggiungere ostinandosi ad utilizzare il modo sbagliato, anche se gli è stato detto e ne sono perfettamente consapevoli. Disimparare, è proprio vero, è molto più difficile che imparare…
Andiamo avanti… In secondo luogo utilizzeremo i campi testuali per il nome ed il cognome. Sbagliato sarebbe utilizzare un solo campo per nome e cognome “insieme”. Nome e cognome sono concettualmente diversi. Se poi bisognerà rappresentarli insieme, lo si farà tramite un’apposita query. Dunque la logica è relativamente semplice: mettiamo in una tabella tutti quei campi che sono correlabili univocamente con tutto il resto della tabella: La città di nascita e/o di residenza, la data di nascita ed il codice fiscale. Numero di telefono? email? Ecco: qui bisogna fermarsi a riflettere. Se il numero di telefono fosse solo e sempre uno ed uno solo per tutti i clienti, andrebbe benissimo prevedere il campo “telefono_cliente” (mi raccomando, testuale, non numerico! Non esistono numeri interi con lo zero davanti! dunque il “numero” 080555555 diventerà, per la tabella, 80555555, un CAP 00100 si trasformerà in “100” e così via). Se vogliamo però badare alla realtà delle cose, converrà prendere atto della necessità di convogliare i dati di contatto (email, telefoni, cellulari, URL e quant’altro) in una tabella separata che chiameremo, ad esempio, “contatti_clienti”. In alternativa, come ho visto fare nei peggiori DB, il genio della lampada di turno ha pensato che fosse ragionevole creare un mucchio di campi contenenti lo stesso tipo di dato: “telefono1, telefono2, cellularecasa, fax…”: questo approccio è errato! Dati omogenei devono essere ricercabili con una singola operazione. Se cerco un numero di telefono per sapere a chi appartiene come posso sapere in quale campo cercarlo? Stesso ragionamento se pensiamo ad un archivio di libri ed agli autori. Se l’autore, in tutti i libri, fosse sempre e solo uno, avrebbe senso creare una tabella “libri” e prevedere il campo “autore_libro”. Talvolta però, gli autori sono più d’uno. In questo caso bisogna agire diversamente e vi insegnerò come farlo. Inutile dirvi che soluzioni geniali come mettere insieme, in un unico campo, uno o più autori è davvero una stupidaggine: un campo, un dato (a parte pochissime e notevoli eccezioni che per il momento non sono alla vostra portata…)
La potenza di un Database relazionale è proprio questa: Lavorare agilmente ed agevolmente su più tabelle contemporaneamente, ognuna delle quali sarà strutturata con dati omogenei e strettamente coerenti.
Dunque la vostra mente dovrà “aprirsi” cercando di immaginare un sistema molto diverso da quello bidimensionale a cui excel vi ha abituati. Per così dire, se vogliamo utilizzare una metafora affascinante e spero non preoccupante, è come se il mondo a due dimensioni si trasformasse, con Access, in un mondo ad n- dimensioni. Proseguendo con la sperimentazione vi accorgerete che questo approccio è di gran lunga migliore, più aderente alla realtà. Arriverete, forse, a non poterne più fare a meno. A me è accaduto così.