Progettazione concettuale: il modello entità-relazione

Prima di creare tabelle bisogna capire che cosa si vuole rappresentare: quali oggetti, quali legami, quali regole. La progettazione concettuale produce uno schema indipendente dal sistema che lo ospiterà, comprensibile anche a chi non è informatico. Il modello più usato è il modello entità-relazione (E-R), proposto da Peter Chen nel 1976. In questa lezione vediamo entità, attributi e identificatori, le relazioni e le loro cardinalità, le generalizzazioni, un esempio completo, e le regole per tradurre lo schema in tabelle, con la dimostrazione del perché le relazioni molti a molti richiedono una tabella propria.

Entità e attributi

Un’entità è una classe di oggetti con esistenza autonoma e proprietà comuni: gli studenti, i corsi, i docenti. Ogni oggetto concreto è un’istanza. Le proprietà sono gli attributi: matricola, nome, data di nascita. Un identificatore è un insieme di attributi che distingue ogni istanza da tutte le altre: per lo studente la matricola. Negli schemi le entità si disegnano come rettangoli, gli attributi come piccoli cerchi, pieni se fanno parte dell’identificatore.

Le relazioni e le cardinalità

Una relazione (o associazione) è un legame tra entità: uno studente sostiene un esame di un corso. Anche le relazioni possono avere attributi: il voto e la data appartengono al legame tra quello studente e quel corso, non all’uno o all’altro.

Le cardinalità dicono quante volte un’istanza partecipa alla relazione, al minimo e al massimo. (0,N) per lo studente nella relazione con i corsi vuol dire che può non aver ancora sostenuto esami e può sostenerne molti; (1,1) per un’automobile nella relazione con il proprio proprietario vuol dire che ne ha esattamente uno. Guardando i massimi, le relazioni binarie si classificano in uno a uno, uno a molti e molti a molti. Le cardinalità sono regole del mondo reale, e vanno chieste a chi lo conosce: “un ordine può contenere prodotti di più fornitori?” cambia lo schema.

Le generalizzazioni

Quando alcune entità sono casi particolari di un’altra si usa una generalizzazione: docenti e studenti sono persone, con attributi comuni (nome, codice fiscale) ereditati dall’entità padre e attributi propri (la matricola per lo studente, il settore per il docente). Una generalizzazione può essere totale (ogni persona è docente o studente) o parziale, esclusiva (non si può essere entrambi) o sovrapposta.

Un esempio

La segreteria di un corso di laurea. Entità: Studente (matricola, nome, cognome, data di nascita), Corso (codice, titolo, crediti), Docente (codice, nome, cognome). Relazioni: Esame tra Studente (0,N) e Corso (0,N), con attributi voto e data; Titolarità tra Docente (0,N) e Corso (1,1), perché ogni corso ha esattamente un titolare. Le regole che lo schema non esprime, come “il voto è tra 18 e 30” o “uno studente non può sostenere due volte lo stesso esame superato”, si scrivono a parte come vincoli d’integrità.

Dalla concezione alle tabelle

La progettazione logica traduce lo schema E-R in tabelle del modello relazionale (lezione sul modello relazionale). Le regole principali:

• ogni entità diventa una tabella, con l’identificatore come chiave primaria;
• una relazione uno a molti non diventa una tabella: si aggiunge alla tabella del lato “molti” una chiave esterna che riferisce la chiave dell’altro lato. Corso riceve la colonna con il codice del titolare;
• una relazione uno a uno si traduce allo stesso modo, mettendo la chiave esterna dal lato a partecipazione obbligatoria;
• una relazione molti a molti diventa una tabella propria, con le chiavi delle due entità e gli attributi della relazione: Esame(matricola, codice_corso, voto, data);
• le generalizzazioni si traducono con una tabella unica con un campo che indica il tipo, o con tabelle separate per le entità figlie.

Teorema. Una relazione molti a molti non si può rappresentare con una chiave esterna in una delle due tabelle delle entità senza ripetere dati o violare la regola di un valore per cella.

Dimostrazione. Si supponga di mettere in Studente una colonna con il codice del corso. Uno studente legato a due corsi richiederebbe due valori nella stessa cella, vietati nel modello relazionale (ogni cella contiene un valore atomico), oppure due righe per lo stesso studente, che ripeterebbero nome, cognome e data di nascita e farebbero perdere alla matricola il ruolo di chiave. Lo stesso accade mettendo la colonna in Corso, per un corso con più studenti. Poiché nella relazione molti a molti entrambi i lati possono avere più partner, nessuna delle due collocazioni evita il problema: serve una tabella in cui ogni riga rappresenti un singolo legame. ∎

La progettazione concettuale fatta bene evita gran parte dei problemi di ridondanza che la normalizzazione (lezione dedicata) dovrebbe poi correggere.