L’analisi Entity - Relatioship, descritta nel capitolo precedente, fornisce un modello dei dati dell’intera applicazione.

Nella fase di progettazione bisogna tradurre questo modello in uno schema di database relazionale.

La traduzione delle varie entità in tabelle è semplicissima, anzi si può dire che l’analisi E-R ci consegna già pronta la lista delle tabelle e dei loro attributi, nonchè una indicazione di tutte le possibili chiavi per ogni tabella.

Più delicata è la traduzione delle relazioni dell’analisi E-R in attributi o tabelle del database. Questa dipenderà infatti da due fattori: la cardinalità della relazione e la tollerabilità di valori nulli.

Se la relazione è del tipo 1:N, bisogna creare un nuovo attributo nell’entità E1 (quella dal lato 1) che contenga una delle chiavi di E2 (quella da lato N). La chiave aggiunta nell’entità è detta chiave esterna (foreign key).

Per esempio, se un ordine è un relazione 1:N con i clienti, nel senso che ogni ordine contiene al più un cliente e per ogni cliente possono esserci N ordini, dovremo creare un attributo COD_CLIENTE all’interno della tabella degli ordini.

Questo metodo è il più naturale, tanto che sembrerebbe l’unico applicabile. In realtà può nascere un problema di occupazione di spazio fisico e difficoltà di gestione dei dati quando ci si aspetta che la relazione sia applicata per un numero piccolo di tuple.

Nell’esempio dell’ordine è obbligatorio che ad ogni ordine si legato un cliente, quindi per ogni tupla di ORDINI troveremo un valore per il campo aggiunto COD_CLIENTE; ma prendiamo un archivio di libri di una biblioteca e pensiamo di aggiungere un campo in ogni libro per indicare a chi è stato prestato.

Ora tutti i libri che non sono prestati, cioè che sono in deposito presso la biblioteca, hanno un campo il cui contenuto non è significativo. Se questi campi sono una grossa parte del database ci ritroviamo con un inutile spreco di spazio su disco e una pesantezza delle applicazioni che sono costrette nelle operazioni di selezione a scorrere grandi parti di archivio vuote.

In questo caso conviene introdurre una nuova tabella PRESTITI con la coppia di chiavi COD_LIBRO dalla tabella LIBRI e COD_SOCIO dalla tabella SOCI che ricostruisce la situazione dei prestiti.

La via della nuova tabella è obbligatoria per realizzare le relazioni N:M.

Una relazione con questa cardinalità non può essere risolta inserendo un nuovo campo in una delle due tabelle coinvolte nella relazione.

Se aggiungessimo un campo nella prima, diventerebbe di tipo 1:N perchè non è possibile inserire più di un valore in un campo, se lo aggiungessimo nella seconda per lo stesso motivo avremmo ridotto la relazione ad una N:1.

In questo caso possiamo introdurre nella nuova tabella anche tutti gli attributi della relazione.