Articolo Pubblicazioni

Progettazione concettuale di una base di dati: il modello Entità-Relazione con esempi

di · Pubblicato il 5 aprile 2002 - Aggiornato il 14 novembre 2026 · Tratto da «Il design dei Database»

Abstract

L’articolo riprende il seminario «Il design dei Database» del 5 aprile 2002 e la lezione «Entity-Relationship» del 2009. Colloca la progettazione della base di dati nel ciclo di vita del sistema informativo, distingue le fasi concettuale, logica e fisica e descrive i costrutti del modello Entità-Relazione con le cardinalità, gli identificatori e le generalizzazioni. Segue la raccolta dei requisiti con l’esempio di una società di formazione, le strategie top-down, bottom-up, inside-out e mista e i criteri di qualità di uno schema.

Vincenzo Calabrò | Progettazione concettuale di una base di dati: il modello Entità-Relazione con esempi
SCARICA LE SLIDE: «Il design dei Database» Calabrò V., 2002, PDF di 85 pagine
 

La base di dati nel ciclo di vita del sistema informativo

Progettare un database significa definirne struttura, caratteristiche e contenuti. È una delle fasi del ciclo di vita di un sistema informativo, che comprende:
  • lo studio di fattibilità, che confronta i costi delle soluzioni possibili e fissa le priorità;
  • la raccolta e l’analisi dei requisiti, svolta insieme ai futuri utenti;
  • la progettazione, divisa fra il design dei dati e quello delle applicazioni;
  • l’implementazione, in cui si crea e si popola il database e si scrivono i programmi;
  • la validazione e il collaudo;
  • il funzionamento, che richiede soprattutto manutenzione.
Le fasi raramente procedono in sequenza, perché un problema emerso in una fase obbliga spesso a rivedere quelle precedenti. A volte si aggiunge la prototipazione, cioè la realizzazione rapida di versioni semplificate per verificare alcune funzioni. I dati però durano più delle applicazioni che li usano, e per questo la progettazione della base di dati richiede un’attenzione particolare.

Cosa rappresentare e come farlo

La metodologia consolidata nella ricerca sui database separa le decisioni su che cosa rappresentare da quelle su come rappresentarlo. Ne derivano tre fasi:
  • la progettazione concettuale, che descrive i dati a un alto livello di astrazione e produce uno schema concettuale;
  • la progettazione logica, che traduce lo schema concettuale nel modello logico supportato dal DBMS scelto;
  • la progettazione fisica, che completa lo schema logico con i dettagli di memorizzazione propri di quel DBMS.
I requisiti dei dati riguardano il contenuto del database, quelli operazionali il modo in cui utenti e programmi lo useranno. Nella fase concettuale contano i primi, mentre i secondi servono a verificare che lo schema sia completo. Nelle fasi logica e fisica i requisiti operazionali guidano le scelte per rendere efficienti le operazioni.

I costrutti del modello Entità-Relazione

Il modello Entità-Relazione (E-R) è un modello concettuale. Offre costrutti per descrivere i dati di un’applicazione senza dipendere dal modo in cui un sistema li organizzerà, e a ogni costrutto corrisponde un simbolo grafico.

Entità, relazioni e attributi

Un’entità rappresenta un insieme di oggetti con proprietà comuni e un’esistenza autonoma, come Studente, Impiegato o Città, e si disegna come un rettangolo. Un’occorrenza è l’oggetto stesso, per esempio la città di Roma, distinto dal valore che lo identifica.
Una relazione è un legame logico fra due o più entità, disegnato come un rombo. Esame lega Studente e Corso, Residenza lega Impiegato e Città. Le relazioni ricorsive collegano un’entità a sé stessa e, quando i ruoli sono asimmetrici, vanno etichettati. In Successione, fra i sovrani, servono i ruoli predecessore e successore. Esistono anche relazioni fra più di due entità, come una Fornitura che lega fornitore, prodotto e dipartimento.
Gli attributi descrivono le proprietà elementari di entità e relazioni e prendono valori da un dominio. Più attributi strettamente legati possono formare un attributo composto, come un indirizzo fatto di via, numero civico e codice postale.

Cardinalità

Per ogni entità che partecipa a una relazione si indicano una cardinalità minima e una massima, cioè il numero minimo e massimo di occorrenze della relazione a cui ogni istanza partecipa. Se un impiegato può avere da uno a cinque compiti e un compito può essere assegnato a un numero di impiegati fra zero e cinquanta, le cardinalità sono (1,5) e (0,50). Nella pratica bastano quasi sempre tre valori, cioè zero, uno e N.
  • Una minima pari a zero indica partecipazione opzionale, pari a uno partecipazione obbligatoria.
  • Guardando le massime, una relazione binaria è uno a uno, uno a molti o molti a molti.
  • Anche gli attributi hanno cardinalità. Un attributo con minima zero è opzionale, uno con massima N è multivalore e si può sostituire con una nuova entità e una relazione.

Identificatori e generalizzazioni

Ogni entità deve avere almeno un identificatore. È interno, cioè una chiave, se è formato da attributi dell’entità, come la targa di un’automobile. È esterno se usa un’altra entità collegata da una relazione in cui la prima partecipa con cardinalità (1,1). Uno studente, per esempio, si può identificare con la matricola insieme all’università presso cui è iscritto.
Una generalizzazione lega un’entità padre a una o più entità figlie, che ne ereditano tutte le proprietà. È totale se ogni occorrenza del padre appartiene a una figlia, altrimenti parziale. È esclusiva se ogni occorrenza appartiene al massimo a una figlia, altrimenti sovrapposta. Con una sola figlia si parla di sottoinsieme.

La raccolta dei requisiti

I requisiti si raccolgono dagli utenti, dalla documentazione e dalle eventuali versioni precedenti dell’applicazione, quasi sempre in linguaggio naturale. Il testo va quindi ripulito da ambiguità e imprecisioni. Il seminario indicava alcune regole:
  • scegliere il giusto livello di astrazione, scrivendo per esempio «votazione in decimi» al posto di «giudizio»;
  • usare frasi con una struttura standard, come «per i partecipanti rappresentiamo…»;
  • evitare le frasi contorte;
  • unificare sinonimi e omonimi, come «docente» e «insegnante»;
  • rendere espliciti i riferimenti fra i termini;
  • costruire un glossario con descrizione, sinonimi e collegamenti di ogni termine.

L’esempio della società di formazione

L’esempio del seminario era una società che eroga corsi. Per circa 5.000 partecipanti si registrano codice fiscale, dati anagrafici, datori di lavoro attuali e passati, corsi frequentati e votazione. Per circa 200 corsi si registrano le edizioni, con date, aule e orari. Per circa 300 docenti, interni o esterni, si registrano dati, recapiti e corsi insegnati o che possono insegnare. I partecipanti possono essere dipendenti, con livello e posizione, oppure liberi professionisti, con area di interesse e titolo professionale.
Ai requisiti dei dati si affiancano quelli operazionali, con la frequenza stimata di ogni operazione. L’inserimento di un nuovo partecipante avviene in media 40 volte al giorno, l’assegnazione di un partecipante a un’edizione 50 volte, la statistica sui partecipanti a un corso 10 volte al mese. Questi numeri non cambiano lo schema concettuale e diventano decisivi nella progettazione logica.

Le strategie di progettazione

  • Top-down. Si parte da uno schema molto astratto e lo si raffina per passi. Si mantiene una visione d’insieme, che però nei progetti complessi raramente è disponibile all’inizio.
  • Bottom-up. Si scompongono le specifiche in frammenti elementari, se ne disegnano gli schemi e poi li si fonde. Si presta al lavoro in gruppo, ma l’integrazione degli schemi può essere difficile.
  • Inside-out. Si parte da pochi concetti centrali e si procede a macchia d’olio verso quelli collegati. Non richiede integrazioni, ma obbliga a rileggere ogni volta tutte le specifiche.
  • Mista. Si disegna uno schema scheletro con i concetti principali e poi si procede con la tecnica più adatta a ogni parte. È la strategia che si adatta meglio ai casi reali.

La qualità di uno schema

Uno schema concettuale si valuta su quattro proprietà:
  • correttezza, cioè l’uso appropriato dei costrutti, senza errori sintattici o semantici;
  • completezza, cioè la presenza di tutti i dati di interesse e la possibilità di eseguire tutte le operazioni;
  • leggibilità, con nomi significativi, linee perpendicolari e poco intrecciate, entità padri sopra le figlie;
  • minimalità, cioè l’assenza di ridondanze.
La metodologia generale proposta nel seminario metteva insieme tutti questi elementi. Si parte dal glossario e dall’analisi dei requisiti, si disegna lo schema scheletro, si raffina ogni parte, si integrano i sottoschemi e si chiude con l’analisi di qualità. Anche quando il database finale non sarà relazionale, chiarire che cosa rappresentare prima di decidere come farlo evita molti errori di progetto.
 
Vedi anche: la lezione del 2009 Entity-Relationship, con slide e registrazione video.
 
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.
Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn