5
Database
Introduzione
La necessità di conservare nel tempo archivi di dati per poterli consultare e aggiornare è stata sentita sin dalle civiltà più antiche. Per
memorizzare i dati sui raccolti agricoli, i fenomeni atmosferici, gli
eventi astrali e gli interscambi commerciali sono stati utilizzati i supporti più vari: dalle tavolette di argilla dei Sumeri, ai nodi dei quipus
degli Incas, alle immense cataste di carta dei tempi più recenti. Oggi,
grazie alle memorie permanenti dei computer e soprattutto al software dedicato all’organizzazione e alla gestione dei dati, si sono
aperte innumerevoli nuove possibilità e tutto è diventato più semplice non solo per i professionisti dell’informatica ma anche per gli
utenti finali, che con poco sforzo possono navigare tra i dati e trovare rapidamente le informazioni di cui hanno necessità. Ed è proprio
in questo senso che siamo interessati al primo approccio del problema posto da Edward F. Codd nella citazione riportata nel riquadro
di pagina seguente: mettere l’utente finale in contatto diretto con le
informazioni memorizzate sui computer.
In questo capitolo introdurremo i concetti fondamentali del mondo
delle basi di dati, vedremo come creare e modificare tabelle e relazioni tra tabelle, effettuare ricerche, manipolare i risultati, definire
maschere e report su un’insieme di dati strutturato. Allo scopo, utilizzeremo l’applicazione Microsoft Access 2002, anch’essa facente
parte di alcune versioni della suite di programmi Office XP.
Supporti per la memoria
Le prime generazioni di computer avevano come punto di forza la
velocità di calcolo, mentre erano povere dal punto di vista della memorizzazione, tanto che i dati dovevano essere caricati su schede
194
CAPITOLO 5
In collegamento diretto con le informazioni
“È ben noto che la crescita della domanda di nuove applicazioni da parte degli utenti finali sta largamente superando la capacità delle divisioni
progetti informatici di realizzare i corrispondenti programmi applicativi. Vi sono due approcci
complementari per affrontare questo problema
(ed entrambi gli approcci sono necessari): uno
consiste nel mettere gli utenti finali in collegamento diretto con le informazioni memorizzate
sui computer, l’altro è quello di incrementare la
produttività dei professionisti nello sviluppo di
programmi applicativi. È meno noto [nel 1980,
N.d.T.] che una sola tecnologia, la gestione delle
basi di dati relazionali, fornisce un fondamento
pratico per entrambi questi approcci.”
(Edward F. Codd, Relational Database: A Practical
Foundation for Productivity, 1981. E.F. Codd è considerato, insieme a C.J. Date, il fondatore e il principale promotore del modello relazionale, che negli ultimi decenni è stato il punto di riferimento per i
sistemi di gestione delle basi di dati.)
perforate ogni volta che si desiderava una nuova elaborazione. Solo
con l’arrivo delle memorie magnetiche i computer iniziano a memorizzare archivi di dati; attualmente la maggior parte delle applicazioni, anche quelle residenti sui personal computer, lavorano su archivi di dati. Si pensi per esempio alla gestione dei conti correnti
bancari: mentre le applicazioni che li movimentano o, in altri termini, le principali operazioni da compiere sono relativamente semplici e ripetitive (si tratta essenzialmente di versare e prelevare denaro), la memoria permanente necessaria alla loro archiviazione è enorme, perché devono essere conservati per anni tutti i dati relativi a
ogni operazione eseguita da ogni singolo cliente. L’aspetto critico
della gestione dei conti correnti è dunque la memoria e la sua affidabilità, nonché la velocità nel reperire i dati: la banca non può certo permettersi di far attendere i clienti in fila allo sportello per minuti od ore.
Dati, occupazione di memoria, persistenza, affidabilità e velocità di
reperimento costituiscono il cuore di innumerevoli applicazioni in
ogni settore, dall’anagrafe dei Comuni alla prenotazione e vendita
dei biglietti aerei, dalla gestione di articoli, prezzi e scontrini della
grande distribuzione a quella aziendale di contabilità, magazzino e
produzione.
Abbiamo già accennato al fatto che gli elaboratori lavorano in codice
binario, cioè con sequenze di 0 e di 1. Attraverso codici come l’ASCII,
con un insieme di otto cifre binarie – il byte – vengono rappresentati
(codificati) nella memoria dei computer le lettere dell’alfabeto, le
cifre e i caratteri speciali, come quelli della punteggiatura. Ebbene,
tale codifica è mantenuta in ogni memoria del computer: nella memoria centrale, di dimensioni limitate, dove vengono ospitati tempo-
DATABASE
195
raneamente parti delle applicazioni e dei dati nel momento in cui
sono utilizzati, e nelle memorie secondarie o periferiche (dischi o nastri), dove risiedono e possono permanere, anche a computer spento, le applicazioni e gli archivi di dati.
Le basi di dati
ECDL
5.1.1.1
Soffermiamoci con un esempio su un concetto già introdotto: la differenza tra dato e informazione. Una sequenza di numeri, quale
890133, rappresenta un dato: può essere un numero di conto corrente o di una carta di credito, un numero di telefono, la matricola di
uno studente, il codice del Bancomat. Diviene informazione solo se
inserita in un contesto che ci mette in grado di decodificarla: se appare cioè in un documento inviatoci dalla nostra banca dopo la sigla CC, sul frontespizio del libretto universitario, nella colonna più
a destra della nostra rubrica in corrispondenza della riga dove appare il nome di un conoscente e via dicendo.
Inizialmente i sistemi per la gestione degli archivi avevano il compito
di scrivere e leggere i dati in quanto tali, mentre la loro interpretazione era affidata ai programmi applicativi secondo lo schema di Figura 5.1.
Il limite di questo approccio è la necessità di accoppiamento tra dati
e programmi per ottenere delle informazioni, per cui se cambia la
struttura di un archivio – per esempio se si decide di aggiungere
alla rubrica, per ogni conoscente, lo spazio per memorizzare il numero del cellulare – è necessario modificare tutte le applicazioni che
accedono a quell’archivio. Inoltre, l’accesso alle informazioni può
avvenire soltanto grazie a programmi realizzati da specialisti. Per
Figura 5.1
In passato
le applicazioni
accedevano
direttamente
agli archivi di dati
196
CAPITOLO 5
superare questo limite i sistemi di gestioni di archivi si sono evoluti
in gestori di basi di dati (DBMS, DataBase Management Systems), secondo lo schema di Figura 5.2.
Una base di dati – è comunissimo anche il termine inglese database
(DB) – è costituita da un insieme di archivi, inerenti uno stesso argomento o più argomenti tra di loro correlati. La base di dati non contiene solo i dati in senso stretto ma anche la loro rappresentazione,
cioè la loro struttura e le relazioni che li legano. Un gestore di basi di
dati (DBMS) si preoccupa di effettuare correttamente sul database le
operazioni che gli vengono richieste liberando chi ne fa uso (applicazioni e utenti esperti), come vedremo, da questo tedioso compito.
In particolare, i DBMS rendono disponibili gli strumenti per:
1. definire gli archivi, specificando i dati, il loro tipo (numerico, testo, immagine ecc.), le loro relazioni e le regole per il
loro utilizzo;
2. inserire, modificare o cancellarle dati;
3. effettuare ricerche di differente natura per reperire rapidamente i dati di interesse;
4. utilizzare un altro vasto insieme di funzioni, fra cui la visualizzazione o la stampa dei dati.
Inoltre i DBMS professionali, soprattutto quelli utilizzati nelle grandi organizzazioni, devono prevedere almeno di:
5. consentire l’accesso ai dati a un elevato numero di utenti,
gestendo i differenti diritti di accesso e la concorrenza nella
modifica e nell’inserimento dei dati stessi;
6. offrire prestazioni accettabili anche in presenza di un numero molto elevato di utenti;
7. realizzare copie di salvataggio per motivi di sicurezza su richiesta e/o in base a schedulazione temporale pianificata a
priori.
Figura 5.2
Applicazioni e utenti
accedono ai dati
attraverso un gestore
di basi di dati (DBMS)
DATABASE
197
Sono davvero indispensabili i DBMS?
Affrontando gli argomenti “word processor” e
“fogli elettronici” si ha immediatamente la percezione della utilità e praticità di tali strumenti,
mentre il lettore che si avvicini per la prima volta
al tema basi di dati potrebbe rimanere smarrito.
Si deve tenere conto, a questo proposito, che l’uso
dei DBMS comincia ad avere senso solo quando
il numero di informazioni, con le relazioni che
tra esse intercorrono, supera una certa soglia. Per
esempio, per trattare la nostra rubrica telefonica
possiamo usare un programma di videoscrittura, o meglio un foglio elettronico, senza particolari problemi. Probabilmente potremmo fare lo
stesso anche per la nostra agenda, anche se questo compito non sarebbe certo altrettanto semplice. Fra le altre cose, infatti, c’è da considerare
che i suoi dati devono essere relazionati con la rubrica. Se abbiamo un appuntamento a casa di
Giovanni lunedì 22 alle h.15, leggendo questo
promemoria sull’agenda dobbiamo poter reperire facilmente indirizzo e numero di telefono di
Giovanni (non per niente le agende cartacee sono
dotate di rubrica). Si badi bene che sarebbe scorretto riscrivere questi dati nello spazio dedicato
alle ore 15 di lunedì 22 – come fanno a volte sull’agenda cartacea gli autori di questo libro –, in
quanto se Giovanni cambiasse numero di telefono non dovremmo solo modificarlo nella rubrica, ma ricercarlo ed eventualmente modificarlo
in tutta l’agenda, e la duplicazione del dato potrebbe portare a incongruenze dovute a un aggiornamento solo parziale.
Qualsiasi sia lo strumento informatico scelto,
dobbiamo dunque fare in modo di legare, o meglio relazionare, il punto in cui abbiamo memorizzato l’appuntamento con quello in cui abbiamo memorizzato i dati di Giovanni. Per esempio, in Excel questo può essere realizzato facendo in modo di visualizzare in una cella il contenuto di un’altra.
Le capacità degli spreadsheet diventano però nettamente insufficienti non appena si vuole creare
il modello di un frammento di realtà che superi
queste dimensioni “personali” e questo livello di
complessità. L’uso di un gestore di basi di dati è
infatti assolutamente indispensabile già in situazioni quali la gestione della contabilità e del magazzino di un’azienda di dimensioni medio-piccole, del catalogo del prestito di una biblioteca di
facoltà o, in ambiente scientifico, l’archiviazione
e l’analisi dei dati di rilevazioni statistiche o di
esperimenti di laboratorio.
Nelle grandi organizzazioni i DBMS risiedono normalmente su computer potenti come i mainframe, che permettono la gestione efficiente di centinaia o anche migliaia di utenti contemporanei, o su
più server in rete locale o geografica, in genere macchine con a bordo sistemi operativi Unix o Windows 2000/XP/2003 (si veda il Capitolo 2). Tra i DBMS più diffusi troviamo Oracle, Sybase, Informix,
Ingres e DB2, quest’ultimo della IBM.
Tabelle e relazioni
ECDL
5.1.1.2
I moderni sistemi per la gestione delle basi di dati che fanno riferimento a un modello detto modello relazionale – proseguendo nella
lettura sarà chiara la ragione – gestiscono e rendono disponibili le
informazioni in una forma semplice e intuitiva: le tabelle.
198
CAPITOLO 5
In Figura 5.3 abbiamo un esempio simile a quello visto nel Capitolo
4 con l’uso di un foglio elettronico; in questo caso righe e colonne
non sono identificate da un’intestazione sequenziale (1,2,3… per le
righe e A, B, C… per le colonne). Una riga (row) di dati viene spesso
detta record (registrazione), mentre una colonna (column) viene anche
detta attributo.
La forma tabellare si adatta a rappresentare la realtà attraverso categorie ed elementi delle singole categorie. La tabella è una categoria,
e ogni riga contiene le informazioni relative a uno dei suoi elementi.
In Figura 5.3, nella tabella Componenti (che chiamiamo così in funzione dell’esemplificazione che andremo a sviluppare), una riga è
relativa a uno studente, che risiede in una città, ha un indirizzo e gli
è stato assegnato un valore in base al contributo che ha apportato a
un gruppo di lavoro cui appartiene. Una riga della tabella è per esempio quella che ha per valori:
Amedeo Arias, Milano, Via Caldera 5, 66
Le colonne rappresentano le informazioni che in questo contesto sono
significative per gli elementi della categoria, nell’esempio degli studenti: Nome, Città, Indirizzo e Contributo. L’incrocio tra una riga
e una colonna viene definito campo (field) ed è adibito a contenere
un valore. Il campo Contributo di Amedeo Arias ha per esempio
valore 66.
La tabella è una struttura di immediata e naturale applicazione in
numerose situazioni quotidiane come l’elenco telefonico, il listino
dei prezzi, gli orari di treni e aerei. Nel caso di Figura 4.2 del CapitoFigura 5.3
La tabella Componenti
DATABASE
199
lo 4 la parte che andrebbe a comporre una tabella è costituita dai
valori del venduto di ogni prodotto nei vari mesi e non i totali; normalmente, infatti, il database memorizza i dati fondamentali e non i
valori calcolati che possono essere ricavati dai precedenti.
In Figura 5.4 abbiamo la tabella Cap, contenente i nomi delle città
con i corrispondenti codici di avviamento postale.
ECDL
5.1.1.5
Figura 5.4
La tabella Cap
contenente i CAP
di alcune città italiane
Figura 5.5
Relazione tra le tabelle
Componenti e Cap,
ottenuta grazie a
una colonna comune
Per spedire una lettera alle persone della tabella in Figura 5.3 sarebbe bene conoscere il CAP della loro città; per ottenere questa informazione possiamo correlare tale tabella con quella di Figura 5.4,
correlazione resa possibile dal fatto che entrambe contengono una
colonna comune (Figura 5.5).
Oltre alla grande semplicità, la rappresentazione tabellare offre infatti la possibilità di collegare tra di loro dati contenuti in tabelle
diverse tramite colonne comuni, che contengono cioè lo stesso tipo
di dati; in questo caso si tratta delle colonne Città in Componenti e
in Cap. Per spedire una lettera a Amedeo Arias scorreremo la tabella
Componenti fino a reperire la riga dove il campo Nome ha valore Amedeo
Arias; sulla stessa riga troveremo l’indirizzo – Via Caldera, 5 – e la
città di residenza – Milano –. Quest’ultimo dato ci servirà dunque
per scorrere la tabella Cap fino a reperire la riga dove appunto il
campo Città ha valore Milano: sulla stessa riga troveremo il CAP –
200
CAPITOLO 5
20100 – e potremmo spedire la nostra missiva. Questo tipo di lega-
me è chiamato relazione. Con la stessa logica possiamo creare legami
a più livelli ed espandere a piacere il modello fino a rappresentare
la parte di realtà che ci interessa.
Vediamo adesso in Figura 5.6 la tabella Aree che contiene i dati relativi a tre aree di ricerca in ambito universitario e ai relativi coordinatori nazionali.
Supponiamo per esempio che la tabella Componenti di Figura 5.3 si
riferisca a studenti universitari che pur vivendo e frequentando l’Università in parti diverse del territorio nazionale collaborino a un particolare progetto relativo al filosofo e scienziato francese Blaise Pascal (1623-1662), progetto che è stato diviso per aree di ricerca, a
ognuna delle quali corrisponde un diverso coordinatore nazionale
(tabella Aree di Figura 5.6). Le due tabelle non hanno colonne che
permettano di metterle in relazione e, in ogni caso, da esse non possiamo dedurre a chi devono far riferimento gli studenti. Nel modello tabellare, per dare questa informazione dobbiamo implementare
una relazione aggiungendo di proposito una nuova colonna a una
delle due tabelle. Ipotizzando che ogni studente possa far parte di
una sola area di ricerca aggiungiamo la colonna Area alla tabella
degli studenti (Figura 5.7).
Si noti che non sarebbe corretto aggiungere il nome degli studenti
alla tabella Aree, poiché a una stessa area di ricerca fanno capo più
studenti.
Questo esempio ci fornisce l’occasione per far rilevare come spesso
si tenda a codificare alcune informazioni rilevanti della base di dati:
in questo caso potremmo non utilizzare direttamente il valore dell’area (matematica, filosofica, storica), come abbiamo fatto nell’esempio della relazione Componenti/Cap, bensì associare un codice all’area, il quale abbia con essa una corrispondenza biunivoca, e
aggiungerlo alla tabella Aree. A questo punto la colonna che andremo ad aggiungere alla tabella Componenti per esprimere la relazione tra studente e area di ricerca di appartenenza conterrà anch’essa
solo il codice dell’area, come mostrato in Figura 5.8.
Figura 5.6
La tabella Aree
contenente le aree di
ricerca e i rispettivi
coordinatori nazionali
DATABASE
201
Figura 5.7
La relazione tra
Componenti e Aree
ottenuta grazie
all’aggiunta di una
colonna comune
Figura 5.8
La relazione tra
Componenti e Aree,
dove è stato associato
un codice univoco a
ogni area di ricerca
Grazie alla relazione espressa dalle Figure 5.7 o 5.8 si evince rapidamente a quale coordinatore faccia riferimento ogni studente. Per
esempio, per sapere quale coordinatore segue il lavoro di Maria Teresa Tropini consideriamo la Figura 5.8 e procediamo in questo modo:
dalla tabella Componenti deduciamo che Maria Teresa segue l’area
202
CAPITOLO 5
di codice 001 e dalla tabella Aree che l’area con codice 001 è quella
Matematica, il cui coordinatore è il professor Emilio Franchi.
Se, al contrario di quanto ipotizzato, uno studente potesse far parte
di più aree di ricerca, allora il modello delle Figure 5.7 e 5.8 non
sarebbe valido, e si dovrebbe aggiungere una tabella in più proprio
allo scopo di memorizzare i legami tra gli studenti e le differenti
aree di ricerca. Tale tabella, che chiameremo ComponentiAree, conterrà una riga per ogni associazione studente/area di ricerca. Potremmo utilizzare direttamente i nomi degli studenti ma, analogamente a quanto abbiamo fatto precedentemente per le aree, assegneremo un codice univoco a ogni studente, o meglio a ogni riga
della tabella Componenti (Figura 5.9): in questo modo non ci saranno ambiguità anche nel caso di più studenti con lo stesso nome e
indirizzo.
Grazie alla tabella ComponentiAree, che implementa la relazione fra
studenti e aree di ricerca, possiamo facilmente dedurre in quali aree
è coinvolto ogni studente. L’esempio di Figura 5.9 viene così riassunto dalla Tabella 5.1.
Modelli di database
In ogni determinato istante di tempo una base di
dati non è altro che una fotografia della parte di
realtà che ci interessa rappresentare. Le regole con
cui possiamo effettuare questa rappresentazione ne costituiscono il cosiddetto modello logico.
Quello che abbiamo introdotto è detto modello relazionale in quanto esclusivamente basato su tabelle che da un punto di vista matematico possono essere interpretate come relazioni fra insiemi (in termini noiosamente tecnici una tabella
non è altro che il sottoinsieme di un prodotto
cartesiano, cioè una relazione). In passato sono
stati ampiamente utilizzati anche il modello gerarchico, basato su strutture ad albero in qualche
modo analoghe a quella più volte esaminata con
cui sono organizzate fra loro le cartelle, e il modello reticolare, basato invece su strutture a grafo o reticolo.
I DBMS relazionali o RDBMS (Relational DataBase Management System) concretizzano, seppure parzialmente, il modello relazionale sviluppato da Edward Codd nel 1970, il primo completamente basato su un modello matematico for-
male. Essi esprimono i dati in forma di tabelle
e hanno l’obiettivo di gestire e rendere semplici collegamenti come quelli che stiamo esaminando.
Il modello relazionale è tuttora un punto di riferimento imprescindibile, anche se si stanno diffondendo modelli orientati agli oggetti e modelli
ibridi relazionali a oggetti. Questi modelli, decisamente meno semplici e intuitivi, risultano talvolta
più adatti per rappresentare alcuni aspetti della
realtà. Per fare due esempi: una struttura gerarchica come l’albero genealogico di una famiglia
e la profondità storica, cioè la memorizzazione e
la gestione dell’evoluzione del dato nel tempo
(quando viene sostituito il prezzo di un articolo
nel listino, il vecchio prezzo non viene perduto
ma conservato, associato al periodo di tempo per
il quale è rimasto in vigore). Entrambe queste situazioni possono essere rappresentate con un
modello puramente relazionale solo in una forma poco intuitiva, tanto che la gestione che ne
consegue è assai complessa e risultano preferibili altri modelli.
DATABASE
Figura 5.9
La relazione tra
Componenti e Aree
ottenuta grazie alla
tabella di connessione
ComponentiAree
Tabella 5.1
Studenti e aree
di lavoro come dedotte
dalla Figura 5.9
Componenti
Aree
Gualfetti Silvia
Butera Gennaro
Graiff Roberto
Arias Amedeo
Tropini Maria Teresa
Pogliani Stefania
Plicato Claudio
Storica e Filosofica
Filosofica
Storica e Filosofica
Matematica, Storica e Filosofica
Matematica e Filosofica
Filosofica
Filosofica
203
204
CAPITOLO 5
Il valore numerico riportato nella colonna Contributo che rileva il
contributo apportato dallo studente fino a questo momento al lavoro in una certa area non può essere più riportato nella riga dello
studente, in quanto uno studente, in questa seconda situazione, può
lavorare in più aree. Poiché il contributo è legato in modo biunivoco
alla coppia studente/area, deve essere riportato nella tabella che
esprime questa relazione.
Chiavi e relazioni
ECDL
5.1.1.3
Nel modello relazionale non è significativo l’ordine delle righe di
una tabella e non devono inoltre esistere due righe perfettamente
uguali. In ogni tabella è quindi possibile individuare un insieme di
attributi o colonne (al limite tutte le colonne) in base al quale viene
identificata univocamente una riga; questo insieme è detto chiave
primaria (primary key). Sono esempi di chiave primaria CodArea di
Aree e CodStud di Componenti. L’aggiunta di quest’ultima è giustificata, come detto, dall’impossibilità di escludere a priori che esistano due studenti con lo stesso nome e indirizzo. La tabella ComponentiAree ha invece come chiave primaria la combinazione di CodStud e CodArea. Ponendo un po’ d’attenzione, possiamo osservare
come in Figura 5.9 tutte e tre le tabelle siano ordinate per chiave
primaria.
La chiave esterna (foreign key) di una tabella è invece un insieme di
attributi che corrisponde alla chiave primaria di un’altra tabella e
che stabilisce dunque un riferimento tra le righe delle due tabelle.
Per comprendere meglio questo concetto riprendiamo gli esempi
fatti nel precedente paragrafo. Nella tabella Componenti di Figura
5.8 abbiamo aggiunto l’attributo CodArea, la chiave primaria di Aree,
esprimendo in questo modo la relazione che sussiste tra Componenti e Aree. CodArea è quindi una chiave esterna di Componenti. In
Figura 5.9 abbiamo invece creato la tabella ComponentiAree con l’attributo CodStud, chiave primaria di Componenti, per far riferimento
alle righe della tabella Componenti, e l’attributo CodArea, chiave primaria di Aree, per far riferimento ad Aree. CodStud e CodArea sono
dunque chiavi esterne di ComponentiAree.
Quando due tabelle vengono messe in relazione mediante il valore
di una colonna, come nel caso di Componenti e ComponentiAree, si
parla di join (congiunzione).
DATABASE
205
Tipi di relazioni
E C D L Nelle ipotesi di Figura 5.8, a ogni area di
5.1.1.6 ricerca possono corrispondere più studenti ma uno studente lavora in una
sola area di ricerca; si dice quindi che tra Aree
e Componenti esiste una relazione uno a molti
ovvero, con terminologia matematica, di tipo
1:N. Sono tipici esempi di relazioni 1:N quelle
che sussistono tra proprietari e veicoli (un veicolo appartiene a un unico proprietario ma un
proprietario può avere più veicoli), tra clienti
e ordini, tra madri e figli. Per esprimere una
relazione 1:N basterà quindi aggiungere come
chiave esterna alla seconda tabella gli attributi
che costituiscono la chiave interna della prima
tabella.
Nel caso di Figura 5.9 abbiamo invece ipotizzato
che non solo a una stessa area di ricerca possano
corrispondere più studenti, ma anche che uno
studente possa collaborare a più aree di ricerca.
In questo caso si dice quindi che tra Componenti
e Aree esiste una relazione molti a molti ovvero di
tipo N:N. Sono tipici esempi di relazioni N:N
quelle che esistono tra corsi e studenti (uno studente frequenta più corsi e un corso è di solito
seguito da più studenti), tra autori e libri, tra in-
Figura 5.10
Esempio dei due
modi alternativi
per esprimere
la relazione 1:1
gredienti e ricette. Per esprimere una relazione
N:N non è possibile aggiungere semplicemente
una colonna a una delle due tabelle in quanto
non è noto a priori il numero di elementi dell’altra tabella che gli corrispondono. Come è stato
fatto in Figura 5.9, è quindi necessario creare una
terza tabella i cui attributi sono quelli che compongono le chiavi interne delle due tabelle. I singoli elementi di questa terza tabella saranno poi
costituiti da tutte le possibili coppie di elementi
in relazione fra loro.
Esistono infine anche le relazioni uno a uno,
ovvero 1:1: non sono altro che le relazioni biunivoche come quelle che sussistono tra nazioni e capitali o tra marito e moglie se, come nei
paesi occidentali, non è permessa la poligamia. Due tabelle i cui elementi sono in relazione 1:1 possono essere collegate aggiungendo come chiave esterna alla prima tabella gli
attributi che costituiscono la chiave primaria
della seconda o, indifferentemente, aggiungendo come chiave esterna alla seconda tabella gli
attributi che costituiscono la chiave primaria
della prima. Le due possibilità sono mostrate
in Figura 5.10.
206
CAPITOLO 5
Avvio (di Microsoft Access)
Proseguiamo ora l’introduzione alle basi di dati appoggiandoci come
anticipato alla versione 2002 di Access, il DBMS di Microsoft. Access è installato su moltissimi personal computer ed è quindi estremamente probabile che sia già presente anche sulla nostra macchina, soprattutto se questa lavora in ambiente Windows. Le funzionalità che stiamo per esaminare sono disponibili sulla totalità dei gestori di basi di dati, anche se le modalità di uso possono essere alquanto diverse; si registrano variazioni significative perfino tra le
differenti versioni dello stesso Access, anche se in quest’ultimo caso
è relativamente semplice individuarne le differenze.
Inizieremo il nostro lavoro con la creazione/definizione di alcune
tabelle, proseguiremo con l’inserimento, la modifica, la cancellazione dei dati e mostreremo le operazioni di ricerca. Vedremo quindi
come realizzare maschere per l’inserimento semplificato dei dati e
concluderemo con i report di stampa. Ancor più che per gli altri software che abbiamo presentato nei precedenti capitoli, consigliamo
caldamente il lettore di ripetere passo passo sulla macchina le operazioni che veniamo illustrando.
ECDL
5.1.2.1
Figura 5.11
L’icona di Access e
quella di un file creato
con questo software
Come al solito, l’attivazione del programma avviene dal menu Start
di Windows oppure facendo un doppio clic sulla prima delle icone
di Figura 5.11, di solito presente sul desktop. Nel momento in cui
attiviamo Access si apre la schermata di Figura 5.12, in cui possiamo scegliere se aprire con le solite tecniche un file già esistente o se
creare un nuovo database, magari seguendo i modelli predefiniti di
Access. In questo secondo caso basta fare clic su Modelli generali, posto nella parte centrale del Riquadro attività, e seguire le indicazioni che verranno fornite via via da Access. Con pochissimi sforzi potremo in questo modo creare una vasta gamma di database, a partire da quello per la gestione dei contatti professionali selezionato in
figura sino a tutti gli altri mostrati nella stessa finestra.
Microsoft Access
Microsoft Access è un DBMS di fascia bassa che
offre un ambiente grafico di interazione con
l’utente allo stesso tempo semplice e sufficientemente completo per poter lavorare egregiamente su basi di dati personali. Delle sette caratteristiche illustrate in questo capitolo come qualificanti i DBMS, Access possiede le prime quattro
ma non le ulteriori tre, che caratterizzano invece
i DBMS di livello professionale più alto. In questo capitolo utilizzeremo Access nella modalità
schematizzata dall’ultima freccia in basso di Figura 5.2, che rappresenta una connessione diretta tra utente e DBMS. Naturalmente è anche possibile colloquiare con Access attraverso applicazioni predisposte nei più diversi linguaggi di programmazione.