Nell’ambito della progettazione delle basi di dati il modello entity-relationship (spesso denominato semplicemente modello ER, oppure modello entità-relazione) è un modello per la rappresentazione concettuale della struttura di una base di dati ad un alto livello di astrazione. Il modello entity-relationship è stato sviluppato dal professor Peter Chen nel 1976 e da allora è diventato il modello di riferimento nella progettazione dei database. In concomitanza con la definizione del modello ER lo stesso Chen ha presentato anche una notazione grafica per la rappresentazione di questi modelli, denominata diagramma ER o (ERD), divenuta anch’essa standard de facto.

La progettazione “ingegneristica” delle basi di dati prevede l’esecuzione di tre fasi sequenziali:

  1. Progettazione concettuale, fase in cui viene sviluppato il diagramma ER connesso all’applicazione;
  2. Progettazione logica, fase in cui viene sviluppato un modello maggiormente dipendente dal modello logico scelto;
  3. Progettazione fisica, fase in cui si procede all’implementazione fisica dell’applicativo.

La fase di progettazione concettuale permette di rimandare molte delle scelte progettuali (tipi di dato, chiavi esterne, indici, eccetera) e di concentrarsi sui soli aspetti importanti: quali elementi devono essere rappresentati e come devono essere posti in relazione.

Costrutti fondamentali

I costrutti fondamentali del modello ER sono pochi è possono essere così riassunti:

  • Entità (Entity), rappresentano concetti complessi e di rilievo che descrivono classi di oggetti con esistenza autonoma. “Persona” o “Cliente” sono due esempi piuttosto comuni di entità;
  • Attributi dell’entità, ogni entità può disporre di uno o più attributi rilevanti per l’applicazione corrente. Un attributo non esiste se considerato individualmente, tuttavia esiste se associato ad una entità o ad una relazione. “Nome”, “Cognome” e “Codice Fiscale” sono tre esempi di attributi piuttosto comuni per l’entità “Persona”. Gli attributi possono essere classificati in diverse categorie:
    • Semplici, se prevedono l’utilizzo di un semplice valore atomico. Alcuni esempi di attributi semplici sono il nome di una persona, il voto assegnato ad uno studente ad un certo esame e così via;
    • Multi-valore (o multipli), se prevedono l’utilizzo di valori multipli. Un esempio di attributo multi-valore potrebbe essere il campo “contatto telefonico” all’interno del quale possono essere inseriti diversi valori;
    • Composti, se possono essere scomposti in più sotto elementi. Un esempio di attributo composto è l’indirizzo di residenza di un soggetto, il quale può essere scomposto in diversi sotto-attributi, tra cui: indirizzo, numero civico, CAP e città;
    • Opzionali, se possono non essere definiti per tutte le entità.
  • Relazione (Relationship), legami logici, significativi per la realtà modellata, tra due o più entità. Data l’entità “Mario Rossi” (Persona) e l’entità “Google” (Azienda) possiamo definire una relazione, denominata “Lavora presso”, in grado di collegare tra loro le due entità. In tal modo esprimiamo la relazione “Mario Rossi lavora presso Google”. Ogni relazione viene identificata, proprio come accade per ogni entità, mediante un nome univoco;
  • Attributi della relazione, per certi aspetti simili agli attributi dell’entità, questi attributi hanno però senso solo se considerati assieme alla relazione a cui sono collegati. Consideriamo ad esempio l’attributo “Durata del contratto” della precedente relazione “Lavora presso”, esso non assume un significato chiaro se considerato come parte dell’entità “Mario Rossi” o dell’entità “Google”, tuttavia il suo significato diventa chiaro se viene considerato parte della relazione “Mario Rossi lavora presso Google”.