Se si è in possesso di un libro di testo «semplice», è probabile avervi trovato, nel caso delle associazioni «uno a uno», una regola di derivazione diversa da quella che verrà descritta in queste pagine. Nei libri si potrebbe trovare una regola che dice di fondere le due entità collegate dall'associazione uno ad uno in un'unica relazione (che dà luogo ad un'unica tabella).
Escludendo il caso banale in cui una delle due entità fosse costituita da un solo attributo, ci si dovrebbe domandare a cosa sia servita l'analisi concettuale del problema e l'individuazione delle due entità, concettualmente diverse, se poi si deve di nuovo fonderle in un'unica relazione. In risposta a questa domanda si può affermare che è conveniente continuare a mantenere separate le due tabelle, soprattutto se queste sono destinate a contenere dati di diverse categorie. Per contro, questo costringe a seguire una regola leggermente più complessa, ma che ha come vantaggio un utilizzo più efficiente dello spazio sui dispositivi di memoria.
Questa regola si divide in tre casi, essendo l'unica che distingue anche se l'associazione è obbligatoria o meno.
Prerequisito per affrontare questa regola sono: la Regola per associazioni uno a molti, la Regola per associazioni molti a molti e l'esempio Le unioni dei cittadini
Avvertimento
La derivazione di associazioni molti a molti in relazioni, era stata ottenuta consentendo di ripetere più volte il valore di una chiave esterna. Per ottenere associazioni uno ad uno, quindi, si dovrebbe impedire questa possibilità, aggiungendo un particolare tipo di vincolo alla relazione, ma tali vincoli saranno studiati solo nel prossimo capitolo.Dopo aver derivato le entità e gli attributi delle entità, per le associazioni uno a uno a cui entrambe le entità non partecipano obbligatoriamente, si procede come segue:
Importante
Regola 6 (prima parte): ogni associazione uno ad uno non obbligatoria viene derivata come se fosse un'associazione molti a molti. La stessa regola vale per gli eventuali attributi dell'associazione.Esempio 3.11. Derivazione dell'associazione unione
L'entità «cittadino» diventa la relazione «cittadini» con i suoi attributi, inoltre, applicando la regola appena vista, si aggiunge una la relazione «unioni»; che dovrà contenere due chiavi esterne. Poichè l'associazione «unione» collega due volte il cittadino, come se fossero due entità distinte, ci sarà una chiave esterna (codice fiscale) per cittadino-maschio e un'altra per cittadino-femmina, che chiameremo cf-maschio e cf-femmina.
cittadini (cf, cognome, nome, datadinascita)
unioni (cf-maschio, cf-femmina)
Tabella 3.14. cittadini
| cf | cognome | nome | datadinascita |
|---|---|---|---|
| RSSMRA | Rossi | Mario | 1950-12-25 |
| VRDGPP | Verdi | Giuseppe | 1950-12-31 |
| BNCNNA | Bianchi | Anna | 1960-02-28 |
| RSSMRC | Rossi | Marco | 1960-02-02 |
| NRENRC | Neri | Enrico | 1962-01-01 |
| GLLGNN | Gialli | Gianna | 1930-03-30 |
Dopo aver derivato le entità e gli attributi delle entità, per le associazioni uno a uno parzialmente obbligatorie si procede come segue:
Importante
Regola 6 (seconda parte): ogni associazione uno ad uno in cui una sola entità partecipa obbligatoriamente viene derivata come se fosse un'associazione uno a molti, immaginando che l'entità che vi partecipa obbligatoriamente sia quella con molteplicità maggiore di uno.
Alla relazione ottenuta da quest'ultima entità va aggiunta la chiave esterna. Anche gli eventuali attributi dell'associazione uno ad uno vanno nella relazione che contiene la chiave esterna.Esempio 3.12. Derivazione dell'associazione occupazione
Si desidera realizzare per un albergo un database che raccolga le informazioni sulle camere e sull'ospite che la occupa in quel momento. Quando si libera la camera i dati del cliente vengono eliminati dal database. Anche nel caso di camere con più ospiti si segnano sempre solo i dati di un solo cliente. Si vogliono registrare i dati anagrafici del cliente e le caratteristiche della camera (numero camera, numero letti, superificie). Aggiungere le eventuali ipotesi necessarie. E` richiesto di realizzare lo schema ER, le regole di lettura, lo schema sintetico delle relazioni e le tabelle di prova (testing).
Si suggerisce di leggere la soluzione solo dopo aver provato a risolvere l'esercizio (anche parzialmente) e di ripetere ogni volta l'esercizio a partire dal punto in cui si sono trovate le eventuali differenze nello svolgimento.
Le due categorie individuate sono due entità, legate tra di loro da un'associazione uno ad uno parzialmente obbligatoria, perchè ci possono essere stanze libere, ma non clienti senza una stanza, perchè i clienti che lasciano l'albergo vengono anche eliminati dal database.
ogni cliente deve occupare una camera
ogni camera può essere occupata da un cliente
Le entità «cliente» e «camera» diventano due relazioni: «clienti» e «camere». Alla relazione derivata dall'entità a partecipazione obbligatoria («camere») si aggiunge la chiave esterna collegata all'associazione derivata dall'entità a partecipazione opzionale («clienti»).
camere (numero, superficie, num_letti)clienti (cf, cognome, nome,numero-camera)
Avvertimento
Si potrebbe obiettare che utilizzando questo schema sarebbe teoricamente possibile far occupare la stessa camera a due clienti diversi, violando così l'associazione uno ad uno. Questo tipo di vincolo non può essere aggiunto a questo livello di studio e verrà affrontato nel prossimo capitolo.Nota
Solo le effettive occupazioni vengono registrate, e nonostante l'associazione non sia completamente obbligatoria, nelle due precedenti tabelle non si trova una sola cella vuota: si può quindi affermare che questo è il metodo più efficiente per memorizzare come vengono occupate le camere dai clienti!Rispondere alla seguente domanda facendo un esempio: si sarebbe ottenuto un database ugualmente efficiente utilizzando una regola di derivazione diversa?
Dopo aver derivato le entità e gli attributi delle entità, per le associazioni uno a uno completamente obbligatorie si procede come segue:
Importante
Regola 6 (terza parte): ogni associazione uno a uno completamente obbligatoria, viene trasformata come se fosse un'associazione uno a molti; in questo caso la chiave esterna può essere messa indifferentemente in una qualsiasi delle relazioni ottenute. Gli eventuali attributi dell'associazione uno a uno vanno nella stessa relazione che contiene la chiave esterna.Questa volta non c'è nessuna partecipazione opzionale e non c'è la possibilità che nelle tabelle si abbiano delle celle vuote, perciò ovunque venga collocata la chiave esterna si otterrà sempre un database efficiente. Per coloro che si domandano se fosse possibile costruire un'unica relazione con gli attributi di entrambe le entità, la risposta è quasi sempre negativa. E' sempre meglio mantenere separate le due categorie, anche dopo la derivazione delle entità in relazioni, perchè esse rappresentano sempre due concetti distinti che il progettista ha individuato nella fase di progetto concettuale. Rimettere insieme due concetti che erano stati faticosamente individuati e separati, sarebbe considerare inutile il lavoro precedente.