Una volta che abbiamo le tabelle e non possiamo lavorarci che si fa con i dati? “Li interroghiamo!” è la risposta che un qualunque esperto di DB (quale io NON sono) vi risponderebbe. Per meglio dire: se le tabelle sono contenute e controllate da un motore di database (RDBMS), interrogare le tabelle è in assoluto l’operazione più “naturale ed ovvia” che si possa pensare. Certo, se nessuno ci spiega come stanno le cose, tutta questa ovvietà non si sa bene dove sia. Allora tento di spiegarvi in maniera molto informale (e scorretta, non me ne abbiano i puristi) come stanno le cose. Microsoft access altro non è che un “front end” grafico intelligente che interroga il “back end” costituito dal motore del database (denominato “Jet”). Non vi è chiaro? (che domande!) Dunque è come se le tabelle fossero ospitate e manipolate da una scatola nera, il motore del database, all’interno della quale non possiamo metterci le mani. Possiamo però dialogare con la scatola nera, con uno specifico linguaggio, relativamente semplice, denominato SQL (leggete si kiu el o, se volete, es kiu el, il secondo è più formale del precedente). Dunque per parlare con la black box (il motore del DB) abbiamo capito che dobbiamo imparare un linguaggio. La black box si impossessa delle nostre tabelle, le digerisce e non ce le restituisce se non dietro nostra esplicita richiesta SQL. Quanto detto vale indistintamente per TUTTI (che io sappia) i database. Gli RDBMS, infatti, sono nati per soddisfare anche centinaia di migliaia di richieste al secondo da parte di tantissimi utenti “contemporaneamente”. Ora, non è questo il caso di Jet-Access. Però sappiate, e da qualche parte l’ho scritto, che Access è l’unico programma della suite Office capace di condividere in tempo reale le informazioni tra più utenti contemporaneamente. Dunque è un vero e proprio DB, anche se ne è sconsigliato l’utilizzo quando si superano i sei accessi contemporanei
(il che significa che può funzionare benino in gruppi di lavoro anche di 20-30 utenti)
Ma allora Access che fa? Access ci aiuta. Dire che Access è un “front end” significa che ci consente di parlare con jet in maniera “informale e semplice”, utilizzando strumenti grafici e mille benedettissimi strumenti senza conoscere una cippa del linguaggio SQL. Se in questo momento vi potrà sembrare poco vi assicuro che se mai avrete a che fare con database più grandi (se lavorate sui siti web avrete senz’altro battuto la testa contro il muro MySQL (gasp!)
capirete in pochi secondo quanta distanza possa esserci tra frontend tipo “phpmyadmin” e Microsoft Access! Se avete un amico competente fatevelo mostrare!
Riperendendo dunque il filo del discorso, il significato di “query” piano piano inizia a diventare più chiaro. “To Query” è un verbo della lingua inglese che significa domandare, nel senso di interrogare, in un’accezione forte al limite del dubbio. Dunque l’utente fa una domanda al database, una query ed il database risponde con un risultato. La domanda dovrà essere pertinente: il db deve disporre dei dati necessari (=tabelle) per fare le sue ricerche. Una domanda “tipica” potrebbe essere: “selezionami tutti i comuni della tabella comuni aventi nella colonna provincia il valore “RM” e mostrameli ordinando in ordine crescente il campo comuni“.
In sostanza il primo “scoglio logico” da superare è questo: Siamo abituati a lavorare con tabelle contenenti quantità di dati sovrabbondanti sia nel senso delle colonne, i cosiddetti campi (codice comune, comune, provincia, regione, codice istat, cap…) sia nel senso dei dati veri e propri, i cosiddetti record (ottomila e passa comuni in tutta italia) ed a cavarcela da soli nel selezionare visivamente ciò che ci interessa sapere. Siamo diventati agili nel farlo. Forse un poco infastiditi qualche volta… ma la verità è che ci siamo proprio abituati e, salvo casi specifici, non ci sogneremmo mai di “perdere tempo” a chiedere al computer di visualizzarci i soli dati di cui necessitiamo. Peraltro, spesso, non sapremmo come farlo. Vedo da sempre persone lavorare così, immersi in enormi spreadsheets (fogli di calcolo) a scovare il dato che a loro interessa, segnandolo col dito sul monitor, prendendo appunti e inventando formule al volo per tirare fuori il risultato di cui necessitano.
Ecco, l’approccio al DB, dal punto di vista di chi lo programma per chi lo consulterà, è affatto diverso: si fa una bella domanda, una query, e il DB risponde con i risultati. Sperando di aver posto bene la domanda. Da un “tutto” selezioniamo un sottoinsieme e vediamo solo quello. E’ un approccio diverso, più rigoroso ma anche a prova d’errore. Attraverso una query il DB seleziona tutto ciò che serve e solo ciò che serve.
Se tutto quello che ho detto fin qui vi è chiaro, possiamo andare avanti.