Progettazione di database: aspetti teorici
Modello basato su valori: come si legano più tabelle
Si tratta di un concetto di fondamentale importanza. Nel modello relazionale, utilizzato dai moderni DBMS, il legame tra tabelle diverse si basa sul valore.
Analizziamo un esempio pratico in modo da chiarificare le idee:
Tabella IMPIEGATI:
Cod_fiscale | Cognome | Nome | Data_nascita |
BNC PRI 56D08 D612O | Bianchi | Piero | 08/04/1956 |
RSS NTN 66R15 G702T | Rossi | Antonio | 15/10/1966 |
CSR GLI 37S24 H501C | Cesare | Giulio | 24/11/1937 |
BNP GPP 80D20 L219D | Bonaparte | Giuseppe | 20/04/1980 |
VRD MRA 76H63 C352W | Verdi | Maria | 23/06/1976 |
Tabella PROGETTI:
Sigla | Titolo | Descrizione |
AF123 | Sviluppo di un software per la gestione magazzino | Il progetto consiste nello sviluppo di... |
AA824 | Sviluppo di sistema per l'acquisizione di dati da dispositivi TWAIN | Il progetto consiste nel realizzare... |
MP777 | Algoritmo di compressione MPEG-5 :) | Il progetto consiste nell'implementare... |
Tabella PARTECIPAZIONE:
Impiegato | Progetto | Data |
RSS NTN 66R15 G702T | MP777 | 01/04/2003 |
BNP GPP 80D20 L219D | MP777 | 20/02/2003 |
VRD MRA 76H63 C352W | AF123 | 18/01/2003 |
BNP GPP 80D20 L219D | AA824 | 24/02/2003 |
BNC PRI 56D08 D612O | AA824 | 05/03/2003 |
E' immediato notare come - tra le tre tabelle - intercorra un legale basato sui valori in esse "memorizzati". E' facile rendersi conto di come il dominio Progetto (contenuto nella tabella Partecipazione) sia in relazione con il dominio Sigla (contenuto nella tabella Progetti). Inoltre, il dominio Impiegato (contenuto nella tabella Partecipazione) sembra essere in relazione con il dominio Impiegato (contenuto nella tabella Progetti).
Analizzeremo e caratterizzeremo meglio, tra poco, i legali che intercorrono tra le varie tabelle.
Prima di procedere è bene però fare luce su un punto cruciale: la mancanza di informazione.
Quando si ha a che fare con informazioni incomplete: soluzioni
Abbiamo detto poco fa che il dato può essere definito come "la registrazione, tramite uno speciale codice, di un aspetto della realtà". Talvolta, durante la creazione di una base di dati, è possibile imbattersi in un problema non di poco conto: l'informazione incompleta.
Come fare quando, per esempio, non si conosce un dato? Nel nostro ultimo esempio supponiamo di non conoscere (o comunque, di non avere a disposizione) la data di inizio partecipazione ad un determinato progetto. Com'è possibile risolvere il problema? Quale valore dobbiamo inserire?
In passato programmatori poco "attenti" usavano utilizzare valori come 0, 99 (e simili) per "marcare" tutti i dati sconosciuti. Si tratta, però, di una pratica del tutto sconsigliabile: alcuni dei valori inseriti potrebbero infatti risultare, in talune circostanze, significativi; potrebbero non esistere valori "non utilizzati"; in fase di utilizzo della base di dati sarebbe necessario ogni volta tenere conto del significato di tali valori.
Per risolvere il problema i moderni DBMS adottano lo speciale valore NULL. Esso non fa parte di alcun dominio: si tratta di un "valore indefinito" che può essere adottato nel caso si abbia a che fare con valori sconosciuti, inesistenti o senza informazione.
Tabella PARTECIPAZIONE:
Impiegato | Progetto | Data |
RSS NTN 66R15 G702T | MP777 | 01/04/2003 |
BNP GPP 80D20 L219D | MP777 | 20/02/2003 |
VRD MRA 76H63 C352W | AF123 | 18/01/2003 |
BNP GPP 80D20 L219D | AA824 | 24/02/2003 |
BNC PRI 56D08 D612O | AA824 | NULL |
In questo caso, per esempio, non conosciamo la data di inizio partecipazione al progetto siglato AA824 per l'impiegato cui è associato il codice fiscale BNC PRI 56D08 D612O.
Va sottolineato, comunque, che i valori NULL debbono essere impiegati con estrema cura e cautela. Utilizzandoli senza alcun criterio rischieremmo, infatti, di "deteriorare" la nostra base di dati:
Tabella PARTECIPAZIONE:
Impiegato | Progetto | Data |
RSS NTN 66R15 G702T | MP777 | 01/04/2003 |
NULL | MP777 | 20/02/2003 |
VRD MRA 76H63 C352W | NULL | 18/01/2003 |
NULL | NULL | 24/02/2003 |
Nell'esempio è chiaro come la tabella Partecipazione (e quindi la nostra base dati) risulti deteriorata a causa del "selvaggio" utilizzo dei valori NULL: nella seconda riga non si ha alcuna informazione sull'impiegato; nella terza è sconosciuto il nome del progetto; nell'ultima non si conosce né impiegato né relativo progetto (informazione assolutamente inutile).
Questo tipo di situazioni va, quindi, evitato mediante un utilizzo "intelligente" e limitato dei NULL.
Utilizzo di vincoli: chiavi
In tutti i database è possibile far uso dei cosiddetti vincoli di integrità: essi permettono di "vigilare" sulla qualità dei dati inseriti; permettono di descrivere la realtà in modo più accurato; sono utili nella progettazione e vengono usati anche dai DBMS nella esecuzioni di interrogazioni (query) sui dati.
Il vincolo più importante a livello di singola tabella si chiama chiave: si dice "vincolo intrarelazionale" perché vale all'interno di una singola singola.
La chiave permette di identificare, in modo univoco, le righe di una tabella.
Nell'esempio precedente, l'attributo Cod_fiscale è chiave per la tabella Impiegati: esso infatti consente di identificare, in modo univoco, ogni singola riga (si chiamano anche n-uple) che compone la tabella.
Nella tabella Progetti, utilizziamo l'attributo Sigla come chiave.
Nella tabella Partecipazione, invece, la chiave è costituita da due attributi: Impiegato e Progetto.
Le chiavi primarie, ricorrenti in tutti i DBMS, sono chiavi che non ammettono la presenza di valori nulli (NULL). Le chiavi che abbiamo citato sono tutte chiavi primarie.
Per indicare una chiave primaria suggeriamo di utilizzare una notazione basata sulla sottolineatura:
Impiegati(Cod_fiscale, Cognome, Nome, Data_nascita)
Progetti(Sigla, Titolo, Descrizione)
Partecipazione(Impiegato, Progetto, Data)
Vincoli di integrità referenziale
Le chiavi sono vincoli di tipo "intrarelazionale" perché valgono a livello di una singola tabella. Ma come è possibile, a questo punto, correlare le informazioni che memorizziamo in tabelle diverse?
E' possibile stabilire un legame stretto tra le varie tabelle che compongono il nostro database mediante i valori assunti dalle chiavi primarie.
Nel nostro esempio diremo che esitono i vincoli di integrità referenziale seguenti:
- Tabella PARTECIPAZIONE: vincoli di integrità referenziale fra Progetto e la relazione PROGETTI e fra Impiegato e la relazione IMPIEGATI
E' importante sottolineare i vincoli di integrità referenziale (foreign key) sussistono tra gli attributi X di una tabella T1 ed un'altra tabella T2. Ciò significa che il vincolo di integrità referenziale impone ai valori dell'attributo X (contenuto nella tabella T1) di comparire come valori della chiave primaria della tabella T2.
Quando si tenta di eliminare delle righe di una tabella (n-uple) sottoposte a vincoli, i DBMS rispondono con azioni compensative: è possibile rifiutare l'operazione di cancellazione; effettuare eliminazioni in cascata (ad esempio delle n-uple correlate in altre tabelle); introdurre valori nulli. Vedremo nel seguito le varie possibilità.
- Nella prossima lezione analizzeremo la progettazione di database in pratica servendoci dei cosiddetti modelli concettuali (essi permettono di descrivere in modo succinto - e senza perdersi in inutili dettagli - i concetti del mondo reale che si desiderano gestire mediante la propria base di dati). Passeremo quindi all'implementazione di una base dati in Microsoft Access.