Data Base relazionale
Supponiamo di voler costruire un DB per un negozio di vini. Per ogni vino in negozio abbiamo una tabella di questo tipo:
Numero | Vino | Regione | Produttore | Fornitore | Bottiglie | Prezzo |
---|---|---|---|---|---|---|
1 |
Lambrusco dolce |
Emilia |
Lamb & Lamb |
Luigi Bartoletti |
44 |
2.20 |
2 |
Lambrusco secco |
Emilia |
Lamb & Lamb |
Luigi Bartoletti |
53 |
2.20 |
3 |
Barbera |
Piemonte |
Cantine Ass. |
Mario Rossi |
14 |
3.45 |
4 |
Barbera |
Piemonte |
Conti |
Aldo Bianchi |
28 |
3.10 |
Poichè sarà necessario contattare frequentemente ogni fornitore per effettuare nuovi ordini, per ogni fornitore abbiamo bisogno di conoscere l'indirizzo, il numero di telefono e di fax. La soluzione di aggiungere altri 3 campi alla nostra tabella non è pratica poichè:
- bisognerebbe ripetere molte volte le stesse informazioni
- se un fornitore dovesse modificare i propri dati, sarebbe necessario cambiare i valori in tutti i record associati
- dovendo ripetere molte volte l'inserimento degli stessi dati, è facile commettere errori
E' sicuramente meglio creare una seconda tabella con l'elenco dei fornitori:
Numero | Fornitore | Indirizzo | Tel | Fax |
---|---|---|---|---|
1 | Luigi Bartoletti | via delle Pigne 11, Bologna | 051 776543 | 051 776582 |
2 | Mario Rossi | via Draghi 32, Tornino | 011 445566 | 011 445567 |
Le nostre tabelle però sono fra loro indipendenti e scollegate. P.es. per trovare l'indirizzo di un certo fornitore, bisognerebbe prima individuarne il nome nella tabella dei vini e poi cercarlo nella tabella dei fornitori. Stesso procedimento, ma al contrario, bisognerebbe seguire per individuare tutti i vini venduti da un certo fornitore.
Inoltre il nostro DB non sarebbe a prova di errore, poichè un errore di battitura potrebbe portare all'inserimento di un nome di fornitore non valido (es. Bartoletto invece di Bartoletti); oppure l'operatore potrebbe inserire il nome di un nuovo fornitore nella tabella dei vini dimenticandosi di inserirlo anche nella tabella dei fornitori; oppure sarebbe possibile cancellare il nome di un fornitore dalla tabella dei fornitori senza cancellarlo anche dalla tabella dei vini. Quelli elencati precedentemente sono tutti problemi di integrità e di congruenza del DB.
Osserviamo che per ogni record nella tabella dei vini dev'esserci sempre uno e un solo record nella tabella dei fornitori. Viceversa ogni fornitore può essere associato a uno o a molti vini (e in alcuni casi anche a nessuno: per esempio quando si inserisce per la prima volta il nome del fornitore in tabella, senza aver ancora inserito nessun vino a lui associato). Questo tipo di relazione fra tabelle è detta uno a molti e può essere rappresentata schematicamente nel seguente modo:
Le due tabelle sono collegate fra loro dal campo Fornitore che risulta comune a entrambe. Tuttavia tale campo ha un ruolo diverso nelle due tabelle:
- nella tabella dei fornitori il campo Fornitore è il campo principale, quello cioè che identifica in modo univoco e senza ambiguità un record nella tabella. In altre parole: non ci possono essere due (o più) record nella tabella con lo stesso Fornitore. Il campo Fornitore viene detto chiave primaria della tabella dei fornitori.
- nella tabella dei vini il campo Fornitore non ha alcun ruolo particolare, salvo il fatto che è il campo attraverso il quale viene effettuata la relazione fra le due tabelle (chiave esterna).
La chiave primaria dev'essere sempre presente in ogni tabella, in quanto serve per evitare la duplicazione dei record (ogni record deve avere una chiave primaria differente). Quando non risulta semplice individuare una chiave primaria in una tabella, si usa come chiave primaria il numero progressivo che identifica ogni record in tabella.
Se aggiungiamo al nostro DB una nuova tabella degli ordini, la relazione fra le diverse tabelle è quella qui mostrata:
Abbiamo in questo modo creato un semplice Data Base Relazionale (DBR). Un DBR è costituito da più tabelle poste in relazione fra loro attraverso chiavi primarie e chiavi esterne. Il DBR viene realizzato per mezzo di un DBMS, cioè di un opportuno programma per la realizzazione di DBR (es. Microsoft Access). Il DBMS garantisce l'integrità del DBR p.es impedendo di indicare il nome di un nuovo Fornitore nella tabella dei vini prima di averne registrato i dati nella tabella di fornitori oppure di eliminare un vino per il quale vi siano ancora degli ordini in sospeso.
Sito realizzato in base al template offerto da
http://www.graphixmania.it