Nota: questa parte è in fase di revisione. È stata scritta solo per tentare di organizzare in qualche modo alcune idee sulla creazione di tabelle in SQL.

Si ringrazia per la collaborazione il prof. Stefano Saccani.

Si è visto che la progettazione di un database segue diversi livelli di astrazione:

1. nello schema E-R si collegano entità e associazioni
2. applicando le regole di derivazione le entità e le associazioni diventano relazioni.
3. le relazioni si possono rappresentare come tabelle
4. le tabelle sono create nel DBMS con il linguaggio SQL.

Ogni livello di astrazione utilizza un diverso modello e non sempre questi modelli sono compatibili tra di loro. A volte, quindi, può capitare di dover fermare il progetto.

Nelle regole di lettura di uno schema E-R si sono visti diversi modi in cui l'entità partecipa all'associazione. L'entità può partecipare all'associazione oppure deve partecipare. Questa caratteristica viene chiamata opzionalità dell'entità e nel primo caso è facoltativa, mentre nel secondo caso è obbligatoria . L'opzionalità non si riferisce solo all'entità ma anche all'associazione che le collega.

Si è visto che esistono tre tipi di associazioni:

1. completamente obbligatorie
2. completamente facoltative
3. oppure miste (obbligatorie in un verso e facoltative nell'altro verso di percorrenza)

Inoltre le associazioni possono essere classificate anche come: “uno a molti”, “molti a molti” e “uno ad uno”. Di solito dalle associazioni si ottengono delle relazioni, ma non è sempre possibile.

associazione	obbligatoria	facoltativa	mista
uno a molti	impossibile	possibile	possibile*
molti a molti	impossibile	possibile	impossibile
uno a uno	possibile	possibile	possibile

*possibile solo se obbligatoria dalla parte a molti

Nel caso di associazioni “buone”, cioè da cui è “possibile” ottenere relazioni, bisogna comunque aggiungere uno o più vincoli intrarelazionali (UNIQUE oppure NOT NULL) sulle chiavi esterne. Il vincolo può essere aggiunto su ogni singola chiave esterna della tabella (vincolo semplice) oppure contemporaneamente su tutte le chiavi esterne della tabella (vincolo composto).

• vincolo semplice: si applica su una solo colonna della tabella
• vincolo composto: si applica contemporaneamente su più colonne

In SQL

• il vincolo UNIQUE può essere sia semplice che composto
• il vincolo NOT NULL può essere solo semplice

Le seguenti tabelle, oltre a ripetere quali siano le associazioni “buone”, specificano anche quali vincoli bisogna aggiungere sulle chiavi esterne (NOT NULL, UNIQUE, semplice oppure composto). Ogni caso verrà dettagliatamente spiegato con un esempio nei paragrafi che seguiranno.

*possibile solo se obbligatoria dalla parte a molti

L'associazione uno a molti, secondo le regole di derivazione, si realizza nello schema logico aggiungendo una chiave esterna (un vincolo extrarelazionale). Come visto nell'esempio “alunni e classi”, dopo aver aggiunto una chiave esterna, le due relazioni (tabelle) risultano collegate ed è obbligatorio inserire prima i dati nella tabella “classi” e dopo in quella “alunni”. L'associazione può diventare veramente obbligatoria per almeno una delle due entità?

Ogni alunno deve appartenere ad una classe

Nel caso in cui l'associazione fosse obbligatoria per l'entità “alunno” significherebbe che non ci può essere un alunno senza classe, quindi basta aggiungere il vincolo di obbligatorietà (NOT NULL) sulla chiave esterna:

CREATE TABLE scuola.alunni (
	idalunno NUMERIC(4,0) PRIMARY KEY,
	nome CHAR(32),
	cognome CHAR(32),
	idclasse NUMERIC(4,0) NOT NULL REFERENCES scuola.classi(codice)
);

Ad ogni classe devono appartenere uno o più alunni

Nel caso in cui l'associazione fosse obbligatoria per l'entità “classe” significherebbe che non ci può essere una classe senza nemmeno un alunno. In precedenza si è ricordato che, dopo aver collegato le due relazioni con la chiave esterna, è necessario inserire i dati nella tabella “classi” prima che in “alunni” e per questo motivo le classi vengono sempre inserite prive di alunni. Se si rendesse obbligatoria la presenza degli alunni si impedirebbe anche la creazione delle classi: il problema non può essere risolto.

Riassumendo, quindi, l'associazione “uno a molti” obbligatoria è impossibile da realizzare, perché è impossibile rendere obbligatoria la presenza dell'entità che partecipa “a uno” (classe). È invece possibile rendere obbligatoria la presenza dell'entità che partecipa “a molti” (alunno) si deve aggiungere il vincolo NOT NULL sulla chiave esterna.

Nell'associazione molti a molti, la regola di derivazione chiede di creare una nuova relazione (tabella) che contenga le chiavi esterne delle altre relazioni (tabelle). Questa nuova relazione sarà l'ultima ad essere riempita con i dati perché è quella che contiene le chiavi esterne. La regola di derivazione non solo chiede di creare le chiavi esterne, ma stabilisce anche che le chiavi esterne siano una chiave primaria composta.

CREATE TABLE auto.proprieta (
	cf CHAR(16) REFERENCES auto.proprietari(cf),
	targa CHAR(9) REFERENCES auto.autoveicoli(targa),
	PRIMARY KEY (cf,targa)
);

Si può rendere veramente obbligatoria la presenza di almeno una delle due entità nell'associazione molti a molti? Risposta… Come visto nel precedente esempio alunno/classe, se si rendesse obbligatoria la presenza delle entità, si impedirebbe all'utente di inserire un nuovo elemento: il problema non può essere risolto nemmeno in questo caso. Nell'associazione molti a molti, quindi, è impossibile rendere obbligatoria la presenza anche solo di una delle entità che vi partecipano. È possibile creare relazioni solo a partire da associazioni “molti a molti” facoltative.

Secondo le regole di derivazione, questo tipo di associazione può essere vista come un caso particolare della uno a molti oppure della molti a molti. In entrambi i casi, però, bisogna ricordare che, trattandosi di associazione uno ad uno, è necessario evitare di ripetere ogni chiave esterna aggiungendo il vincolo UNIQUE su ognuna di esse.

Siccome l'associazione “uno ad uno” (facoltativa) è un caso particolare della “molti a molti” (facoltativa), valgono anche le stesse regole viste per quella associazione e si aggiunge anche NOT NULL sulle singole chiavi esterne.

Siccome l'associazione uno ad uno (mista) è un caso particolare della uno a molti (mista), valgono anche le stesse regole viste per quella associazione e si aggiunge anche NOT NULL sulla chiave esterna.

Siccome l'associazione uno ad uno (obbligatoria) è un caso particolare della uno a molti (obbligatoria), vale la stessa regola: è impossibile da realizzare. In quest'ultimo caso, però, si potrebbe realizzare un'unica tabella che contiene gli attributi di entrambe le entità e rendere obbligatorio l'inserimento di una chiave primaria usando PRIMARY KEY e dell'altra chiave primaria usando una combinazione di UNIQUE insieme a NOT NULL.

<showif mayedit>

aggiungo alcune osservazioni.

1. Quello che hai scritto è sostanzialmente corretto: non tutte le tipologie di associazioni possono essere implementate nel modello relazionale. E lo hai dimostrato in modo convincente. 2. Riscriverei il paragrafo sulle associazioni 1:1 (vedi il commento corrispondente) 3. Tu, giustamente, fai notare che certe associazioni sono casi particolari di altre e che quindi possano essere implementate con gli stessi schemi e princìpi. Io penso, non so se tu sia d'accordo, che tutte le associazioni in linea di principio possano essere viste come casi particolari delle associazioni molti a molti. In modo analogo a quello che avviene in matematica in cui il concetto più generale di corrispondenza tra insiemi(leggi: relazione matematica definita come sottoinsieme del prodotto cartesiano degli insiemi) assorbe tutte le corrispondenze particolari (iniettive, surriettive, etc.) Quindi in linea di principio penso che tutte le associazioni possano essere implementate con delle tabelle aggiuntive a quelle che implementano le sole entità e giocando sui vincoli relazionali (intra e inter) si possano rendere alcuni vincoli delle associazioni.

</showif>