|
Descriviamo
ora una caratteristica molto importante delle Basi di Dati
Relazionali: le relazioni fra tabelle.
Prima
di questo servono alcune definizioni molto importanti.
Si dice
Chiave di una tabella quel campo (o insieme di campi) che
individua univocamente le righe della tabella. Questo vuol dire che
per ogni riga della tabella il valore del campo Chiave dovrà sempre
essere diverso.
Es:
Sia la tabella Software
| Matricola |
Prodotto |
Costo |
| 2346 |
Gestione Clienti |
1.000.000 |
| 2145 |
Gestione Bilancio |
5.000.000 |
| 2128 |
Fax |
1.000.000 |
| 2367 |
Inventario |
3.500.000 |
Il
campo Matricola è chiave per la tabella, mentre il campo Costo no.
I campi
chiave sono molto importanti perché permettono non solo di ritrovare
facilmente dati all'interno delle tabelle, ma soprattutto di collegare
tra loro tabelle diverse. La necessità di scrivere informazioni su più
tabelle collegate nasce da due esigenze fondamentali: la prima
riguarda lo spreco di spazio all'interno di una tabella (ridondanza
delle informazioni), la seconda riguarda la coerenza tra le
informazioni ridondanti.
Es:
Sia la tabella Elezioni:
| Lista |
Candidato |
Preferenze |
| Tutti per uno e uno per tutti |
Aramis |
5 |
| Siamo forti |
Superman |
7 |
| Tutti per uno e uno per tutti |
Athos |
8 |
| Tutti per uno e uno per tutti |
Portos |
2 |
| Ce la possiamo fare |
Paperino |
1 |
| Siamo forti |
Mazinga Z |
7 |
Si
vede subito che la prima colonna contiene informazioni ripetute, ed
anche se questo spreco ci sembra di poca importanza, consideriamo
che la colonna Lista contiene 129 caratteri, mentre la seconda 42 e
la terza 6. Quindi su un totale di 129+42+6=177 caratteri circa il
73% è occupato dalla prima colonna (questi calcoli non hanno
nessuno scopo formale, ma servono solo per spiegare il concetto che
è alla base dell'esempio).
Se invece avessimo due tabelle:
1 - Lista
in cui il campo Num_lista è chiave per la tabella
| Num_lista |
Nome Lista |
| 1 |
Tutti per uno e uno per tutti |
| 2 |
Siamo forti |
| 3 |
Ce la possiamo fare |
2 - Preferenze
in cui il campo Candidato è chiave per la tabella
| Num_lista |
Candidato |
Preferenze |
| 1 |
Aramis |
5 |
| 2 |
Superman |
7 |
| 1 |
Athos |
8 |
| 1 |
Portos |
2 |
| 2 |
Paperino |
1 |
| 2 |
Mazinga Z |
7 |
Le
informazioni occupate dalla prima colonna scenderebbero a 6
caratteri, quindi sul totale di 6+42+6=54 caratteri il campo
Num_lista occupa l' 11% dello spazio occupato dalla tabella. (In
queste righe non si è tenuto conto della nuova tabella Lista come
influisce lo spazio occupato da questa tabella? E' sempre
conveniente spezzare?)
Ovviamente abbiamo fatto un esempio in cui la tabella Preferenze è
molto piccola, e quindi correggendo alcuni conti il risparmio
potrebbe non essere evidente, ma si pensi che una base dati di un
certo interesse ha almeno alcune migliaia di righe per ogni tabella.
Il Campo Num_lista della tabella Preferenze viene
detto Chiave Esterna per tale tabella, perché è il campo
che permette di collegare le informazioni qui contenute con
quelle contenute nella tabella Liste.
Un'ultima
considerazione: mettiamo che il nome della lista numero 2 invece di
"Siamo forti" sia "Siamo molto forti", e che
questa correzione debba essere fatta a tabella Preferenze già
riempita: nel caso a tabella unica le righe da correggere sono due,
mentre nel caso a tabelle separate bisogna solo correggere la tabella
Liste, senza dover toccare la tabella Preferenze, cosa che ha un
numero ampio di aspetti postivi, tra cui uno dei più importanti è
che non si possono creare situazioni "ibride" in cui qualche
record è stato aggiornato e altri no.
A chi
interessano le problematiche relative a questo procedimento consiglio
di guardare qualche pubblicazione nei capitoli che parlano di
Normalizzazioni e Forme Normali di Boice-Codd.
|
Guidainlinea.com come homepage
Aggiungi questa pagina ai preferiti