La fase di progettazione di un database ha lo scopo di individuare quali tipi di informazioni dovranno essere gestite e le relazioni tra loro intercorrenti. Il modello di rappresentazione per strutturare un insieme di informazioni all’interno di un database è un modello relazionale, che richiede di strutturare le informazioni in tabelle a loro volta composte da campi. Il modello relazionale ha però un difetto, è troppo semplice per rappresentare delle informazioni che possono risultare essenziali in fase di progettazione. In pratica un modello relazionale può essere utilizzato per rappresentare le informazioni all’interno di un DBMS, ma non è adatto per essere utilizzato in fase di progettazione perché non è in grado di rappresentare esplicitamente le relazioni esistenti fra due o più tabelle. Per questi motivi durante la fase di progettazione di un database si preferisce utilizzare un modello di rappresentazione più completo denominato modello entità-relazioni ( E-R). In questo modello le relazioni fra le tabelle sono indicate in modo preciso ed esplicitamente e rappresentate graficamente all’interno di un diagramma.
Nel modello entità-relazioni esistono tre elementi fondamentali:
- le entità rappresentate graficamente come rettangoli
- le relazioni rappresentate da rombi
- gli attributi molto simili ai campi di un database
 |
| Rappresentazione grafica di una relazione tra due entità |
Al termine della fase di progettazione le varie entità e relazioni definite dovranno essere oppurtunamente trasformate in tabelle. La maggior parte degli strumenti che consentono di progettare la struttura di un database consentono di effettuare questa operazione automaticamente.
Le prime due regole elementari sono: ogni entità diventa una tabella ed ogni attributo semplice diventa un campo. La conversione delle relazioni può essere fatta considerando un’unica regola: per ogni relazione 1:1 o 1:N viene aggiunta una chiave straniera ( ad esempio il codice del cliente all’interno della tabella ordini per risalire al cliente che ha effettuato l’ordine ) all’interno di una delle due tabelle coinvolte.
Non tutte le relazioni sono però così semplici da rappresentare, infatti la prima eccezione è costituita dalla cardinalità della relazione, quelle molti a molti, facciamo un esempio pratico. Consideriamo le entità Clienti e Venditori, supponendo che ogni venditore serva più clienti e che ogni cliente possa essere servito da più venditori; in questo caso occorre ricorrere a questa regola: per ogni relazione N:M viene definita una tabella di appoggio, contenente le chiavi primarie delle tabelle coinvolte, più eventuali attributi aggiuntivi. Nel nostro caso, un attributo aggiuntivo potrebbe essere utilizzato per indicare l’intervallo di tempo in cui un determinato cliente è stato assegnato ad un dato venditore.
Un secondo caso particolare è costituito dalle relazioni ricorsive, in questo caso occorre applicare un nuovo accorgimento alle regole già viste: per ogni relazione ricorsiva si procede come nei casi precedenti aggiungendo una chiave straniera alla stessa tabella se la cardinalità della relazione è 1:1 o 1:N, altrimenti definendo una tabella di appoggio alle relazioni N:M.
La maggior parte delle relazioni che vengono definite in un diagramma E-R sono di tipo binario, certe volte però dobbiamo anche coinvolgere più entità ed in questi casi la regola da seguire è questa: per ogni relazione N-aria viene definita una tabella di appoggio contenente le chiavi primarie delle tabelle coinvolte.
Un altro caso particolare è quello degli attributi speciali, ci sono almeno due casi da considerare, quello degli attributi composti, il cui valore è dato da un insieme di valori più semplici e quello degli attributi multivalore. Nel primo caso si segue questa regola: per ogni attributo composto viene creato un insieme di campi. Nel secondo caso vale la regola: per ogni attributo multivalore viene creata una tabella di appoggio contenente la chiave primaria della tabella ed un campo corrispondente all’attributo.
L’ultimo caso che prendiamo in considerazione è quello dell’ereditarietà, ad esempio le entità Persona ed Impiegato. Ogni impiegato è anche una persona ed è quindi dotato di un nome e cognome, in più l’impiegato dispone di alcune caratteristiche specifiche come il numero di matricola o il salario. In questo caso dobbiamo seguire questa regola: per ogni relazione di ereditarietà si definisce una tabella per il supertipo ed una per ognuno dei sottotipi. Al supertipo vanno aggiunti i campi comuni ed un campo tipo che ci permetterà di sapere se un supertipo è anche un sottotipo.
Il modello Entità-Relazioni ( E-R ) è molto comodo in fase di progettazione, ma occorre prestare attenzione al tipo di conversione affinché vengano preservate nello schema risultante le intenzioni del progettista del database.
