Progettazione Concettuale
Dai requisiti al diagramma Entità-Associazione
Nessuno progetta una base di dati partendo dalle tabelle. Se ci provi, ti perdi subito nei dettagli: quante tabelle servono, quali chiavi, quali vincoli, come si collegano. Il modello relazionale è rigido e ti costringe a decidere troppo presto.
La progettazione concettuale serve a rispondere prima alla domanda «che cosa devo rappresentare», lasciando il «come» alla fase successiva. Lo strumento è il modello Entità-Associazione (E-R): un linguaggio grafico indipendente da qualsiasi DBMS, abbastanza semplice da poter essere discusso con chi il database lo userà e non sa cosa sia una chiave esterna.
Progettare una base di dati
Il ciclo di vita di un sistema informativo
La progettazione non nasce dal nulla: è una fase di un processo più ampio, che si ripete ciclicamente perché ogni fase può rimettere in discussione la precedente.
| Fase | Cosa si decide |
|---|---|
| Studio di fattibilità | costi, priorità, se il progetto s'ha da fare |
| Raccolta e analisi dei requisiti | quali proprietà deve avere il sistema |
| Progettazione | dati e funzioni: è qui che nasce lo schema |
| Realizzazione | implementazione su un DBMS concreto |
| Validazione e collaudo | verifica sperimentale su dati veri |
| Funzionamento | il sistema entra in produzione |
I tre livelli di astrazione
La progettazione dei dati si svolge su tre livelli, ognuno con un proprio prodotto:
Raccolta e analisi dei requisiti
Come si acquisiscono
I requisiti si raccolgono da due fonti: le persone (interviste, questionari) e i documenti (normative, regolamenti interni, procedure, sistemi già esistenti). È l'attività meno standardizzabile dell'intero processo, e quella dove si commettono gli errori più costosi.
I problemi tipici sono sempre gli stessi: utenti diversi raccontano versioni diverse della stessa realtà; chi sta in alto ha una visione ampia ma vaga, chi opera conosce i dettagli ma non il quadro; e quasi nessuno distingue ciò che è essenziale da ciò che è accessorio. Rimedi pratici:
- verificare spesso di aver capito, riformulando con parole proprie;
- chiedere esempi, soprattutto sui casi limite («e se un paziente cambia medico a metà terapia?»);
- farsi dare definizioni e classificazioni esplicite;
- chiedere un ranking: cosa serve davvero e cosa sarebbe solo comodo.
Glossario e riscrittura delle frasi
Prima di disegnare qualsiasi cosa, i requisiti vanno riscritti in una forma trattabile. Tre operazioni, nell'ordine:
1. Costruire un glossario dei termini. Serve a stanare i sinonimi (partecipante/studente) e gli omonimi (due significati diversi della stessa parola).
| Termine | Descrizione | Sinonimi | Collegamenti |
|---|---|---|---|
| Partecipante | Persona che frequenta i corsi | Studente | Corso, Datore di lavoro |
| Docente | Chi tiene un corso; può essere esterno | Insegnante | Corso |
| Corso | Corso erogato, con più edizioni | Materia | Docente, Partecipante |
2. Standardizzare le frasi. Stessa struttura per concetti simili, riferimenti espliciti («il numero di telefono del datore di lavoro» invece di «il numero di telefono»), niente pronomi ambigui.
3. Raggruppare per concetto. Le frasi si riorganizzano in blocchi omogenei: frasi generali, frasi sui partecipanti, frasi sui corsi, frasi sui docenti. Ogni blocco diventerà una porzione dello schema, e questo rende possibile lavorare per raffinamenti successivi senza perdere pezzi.
Separa sempre le frasi sui dati da quelle sulle operazioni. «Di ogni paziente registriamo il codice fiscale» descrive i dati; «ogni mattina si stampa l'elenco delle visite del giorno» descrive un'operazione, e servirà nella progettazione logica per valutare le prestazioni.
I costrutti di base del modello E-R
Entità
Un'entità è una classe di oggetti della realtà di interesse con proprietà comuni ed esistenza autonoma: impiegato, città, fattura, visita. Si disegna come un rettangolo con un nome, singolare ed espressivo.
Attenzione alla distinzione fra entità e istanza: l'entità Impiegato è la classe, «Mario Rossi» è una sua occorrenza. Nel diagramma compaiono solo le classi: i dati non si disegnano.
Associazioni
Un'associazione (relationship) è un legame logico fra due o più entità, rilevante per l'applicazione. Si disegna come un rombo. A differenza dell'entità non ha esistenza autonoma: l'associazione Afferenza esiste solo se esistono un impiegato e un dipartimento da collegare.
Due entità possono essere collegate da più associazioni diverse (un impiegato risiede in una città e lavora in un'altra), e un'associazione può collegare un'entità con sé stessa: in quel caso si chiama ricorsiva e i due rami vanno etichettati con i ruoli, altrimenti il verso si perde.
Attributi
Un attributo è una proprietà elementare di un'entità o di un'associazione, e associa a ogni occorrenza un valore preso da un dominio. Si disegna come un pallino collegato al costrutto.
Il punto interessante è che anche le associazioni hanno attributi: il voto di un esame non è una proprietà dello studente né del corso, ma proprio del legame fra i due.
Quando più attributi hanno un significato affine si possono raggruppare in un attributo composto: Via, Numero civico e CAP formano Indirizzo. È solo una comodità di lettura: nella traduzione verso il modello relazionale il gruppo si scioglie nei suoi componenti.
Il modello E-R esteso
I tre costrutti di base non bastano a dire tutto. Guardando il diagramma di prima non sappiamo se un impiegato può afferire a più dipartimenti, se un dipartimento può esistere senza impiegati, cosa identifica un'occorrenza. Per questo il modello si estende con cardinalità, identificatori e generalizzazioni.
Attributi opzionali e multivalore
Anche un attributo ha una cardinalità, cioè un numero minimo e massimo di valori per ogni occorrenza:
- (0,1) opzionale: può mancare. Nel modello relazionale diventerà un attributo che ammette NULL.
- (1,1): il caso normale, e per questo non si scrive.
- (1,N) multivalore: più valori per la stessa occorrenza, per esempio i numeri di telefono di un'agenzia.
Gli attributi multivalore sono comodi nel concettuale e impossibili nel relazionale: una colonna contiene un valore solo. Verranno eliminati nella ristrutturazione, tipicamente diventando una nuova entità. Usarli nel diagramma è corretto, dimenticarsi di eliminarli dopo no.
Identificatori
Un identificatore è ciò che distingue un'occorrenza dalle altre. Nella forma più comune è interno: uno o più attributi dell'entità stessa (la targa per l'automobile; cognome, nome e data di nascita per una persona, se non si vuole usare il codice fiscale).
Regole da rispettare:
- ogni entità deve avere almeno un identificatore, e può averne più d'uno;
- un identificatore non può contenere attributi opzionali né multivalore;
- si cerca il sottoinsieme minimo di attributi che funziona per tutte le occorrenze possibili, non solo per i dati di esempio che hai sottomano.
Cardinalità delle associazioni
A ogni entità che partecipa a un'associazione si associa una coppia di numeri: quante volte, al minimo e al massimo, un'occorrenza di quell'entità può comparire nell'associazione. Per semplicità si usano solo tre valori: 0 e 1 per il minimo, 1 e N per il massimo.
| Valore | Posizione | Significato |
|---|---|---|
| 0 | minimo | partecipazione opzionale: può non partecipare |
| 1 | minimo | partecipazione obbligatoria: deve partecipare |
| 1 | massimo | al più una volta |
| N | massimo | nessun limite |
La cardinalità si legge partendo dall'entità vicina: in Impiegato —(1,1)— Residenza —(0,N)— Città, il (1,1) sta dal lato dell'impiegato e dice «ogni impiegato risiede in esattamente una città»; il (0,N) dice «una città può avere zero o molti residenti». Scambiare i due lati è l'errore più frequente nei compiti, e cambia completamente lo schema tradotto.
Uno a uno, uno a molti, molti a molti
Guardando solo le cardinalità massime si ottengono tre famiglie, che nella progettazione logica si tradurranno in modi diversi.
Identificatore esterno ed entità deboli
A volte gli attributi di un'entità non bastano a identificarla: serve anche l'identificatore di un'altra entità collegata. È il caso dello studente identificato dalla matricola all'interno della sua università: due atenei diversi possono avere la stessa matricola. Si parla di identificatore esterno e l'entità si dice debole.
Si può sempre trasformare un'entità debole in una forte aggiungendo un identificatore artificiale (un codice progressivo). Ma così si perde il vincolo originario: bisogna aggiungerlo a mano nella documentazione, altrimenti il database accetterà due studenti con la stessa matricola nella stessa università.
Generalizzazioni
Una generalizzazione mette in relazione un'entità padre con una o più entità figlie che ne sono casi particolari. Vale il principio di ereditarietà: ogni proprietà del padre (attributi, associazioni, altre generalizzazioni) appartiene automaticamente alle figlie e non va ridisegnata.
| Proprietà | Definizione | Esempio |
|---|---|---|
| Totale | ogni occorrenza del padre è occorrenza di almeno una figlia | Persona → Uomo, Donna |
| Parziale | esistono occorrenze del padre che non sono di nessuna figlia | Persona → Studente, Lavoratore (esistono pensionati) |
| Esclusiva | ogni occorrenza del padre appartiene ad al più una figlia | Uomo / Donna |
| Sovrapposta | un'occorrenza può appartenere a più figlie | Persona → Studente, Lavoratore (studenti lavoratori) |
Entità, attributo o associazione?
I criteri di scelta
Davanti a un concetto delle specifiche, la domanda è sempre: quale costrutto uso? I criteri derivano direttamente dalle definizioni.
| Se il concetto… | Allora è… | Esempio |
|---|---|---|
| ha proprietà significative e un'esistenza autonoma | entità | Medico, Paziente |
| è semplice e non ha proprie proprietà | attributo | Parcella, Città |
| correla due o più concetti | associazione | Afferenza, Esame |
| è un caso particolare di un altro | generalizzazione | Dirigente rispetto a Impiegato |
Il caso ambiguo per eccellenza è Città: attributo di Persona se serve solo il nome, entità se la città ha proprietà proprie (numero di abitanti, provincia) o se altre entità devono collegarsi a essa. La domanda risolutiva è: «devo dire qualcosa sulla città?» Se sì, è un'entità.
Dizionario dei dati e regole aziendali
Un diagramma non basta mai da solo: molti vincoli non sono esprimibili graficamente. Lo schema va quindi accompagnato da:
- Dizionario dei dati: una tabella per le entità (nome, descrizione, attributi, identificatore) e una per le associazioni (nome, descrizione, entità coinvolte, attributi).
- Regole di vincolo: condizioni che i dati devono rispettare. «Il direttore di un dipartimento deve afferire a quel dipartimento»; «un impiegato non può guadagnare più del direttore del suo dipartimento».
- Regole di derivazione: come si ottiene un dato da altri. «Il numero di impiegati di un dipartimento si ottiene contando le afferenze».
Le regole di derivazione segnalano le ridondanze, che nella progettazione logica andranno valutate: tenerle costa spazio e aggiornamenti, toglierle costa letture.
Strategie di progetto
Top-down, bottom-up, inside-out
Top-down
Si parte da uno schema molto astratto e lo si raffina: un'entità diventa due entità associate, un'associazione diventa un'entità con due associazioni, si aggiungono attributi e generalizzazioni.
Pro: visione d'insieme sempre coerente. Contro: difficile se i requisiti sono molti e disomogenei.
Bottom-up
Si spezzano le specifiche in parti minime, si disegna lo schema di ciascuna e poi si fondono i pezzi risolvendo sinonimi e conflitti.
Pro: ogni pezzo è semplice. Contro: l'integrazione finale è la parte difficile.
La strategia inside-out è una variante bottom-up: si parte dai concetti più importanti e si procede "a macchia d'olio" verso quelli collegati. Nella pratica si usa un approccio misto: schema scheletro con i concetti principali, poi raffinamento per blocchi.
Una metodologia pratica
- Analizza i requisiti: elimina le ambiguità, costruisci il glossario, raggruppa le frasi.
- Passo base: individua i concetti più citati o dichiarati cruciali e disegna lo schema scheletro.
- Passo iterativo: raffina i concetti presenti, aggiungi quelli mancanti, un blocco di frasi alla volta.
- Analisi di qualità: verifica correttezza, completezza, minimalità e leggibilità; correggi e ripeti.
Caso di studio: la clinica
La traccia
Si vuole progettare la base di dati di una clinica privata. Di ogni medico interessano matricola, cognome, nome, la specializzazione, la parcella e la città in cui opera. Di ogni paziente interessano codice fiscale, cognome, nome, sesso, città, data di nascita ed eventualmente il reddito, che non sempre è noto. La clinica registra le visite: ogni visita riguarda un medico e un paziente, avviene in una certa data e può essere mutuata oppure no. Lo stesso medico può visitare più volte lo stesso paziente, ma non più di una volta al giorno. Medici e infermieri sono entrambi personale della clinica, con matricola e data di assunzione; degli infermieri interessa anche il reparto.
Lo schema, un passo alla volta
Segui la costruzione: si parte dallo scheletro, si aggiungono le proprietà, si mettono le cardinalità e infine si corregge l'errore che quasi tutti commettono su questa traccia.
Perché il passaggio 4 è quello che fa la differenza. Se lasci Visita come associazione molti a molti, nella traduzione otterrai una tabella con chiave (Medico, Paziente): il database rifiuterà la seconda visita dello stesso medico allo stesso paziente. Con l'entità debole la chiave diventa (Medico, Paziente, Data), che è esattamente lo schema usato nel modulo SQL. Ogni volta che leggi «più volte», «ogni volta che», «lo storico», chiediti se all'identificatore manca un pezzo.
La documentazione che accompagna lo schema
Dizionario delle entità
| Entità | Descrizione | Attributi | Identificatore |
|---|---|---|---|
| Personale | Chi lavora nella clinica | Matricola, DataAssunzione | Matricola |
| Medico | Personale che effettua visite | Cognome, Nome, Specializzazione, Parcella, Citta | Matricola (ereditato) |
| Infermiere | Personale di reparto | Reparto | Matricola (ereditato) |
| Paziente | Persona assistita dalla clinica | CodFiscale, Cognome, Nome, Sesso, Citta, DataNascita, Reddito (0,1) | CodFiscale |
| Visita | Singolo incontro fra un medico e un paziente | Data, Mutuata | esterno: Medico + Paziente + Data |
Regole di vincolo
- La data di una visita non può precedere la data di assunzione del medico che la effettua.
- Un medico non può effettuare più di una visita allo stesso paziente nella stessa data (garantito dall'identificatore).
- Se una visita è mutuata, il ticket dipende dal reddito del paziente; se il reddito non è noto si applica la fascia massima.
Il vincolo 1 non è disegnabile nel diagramma: è una business rule e verrà implementata con un trigger. Il 2 invece è già garantito dalla struttura: è il segno che il raffinamento del passo 4 era quello giusto.
Qualità dello schema
Uno schema concettuale si valuta su quattro proprietà. Vale la pena ripassarle prima di consegnare un compito.
| Proprietà | Domanda di verifica |
|---|---|
| Correttezza | Ho usato i costrutti secondo le loro definizioni? Nessun attributo con proprietà proprie, nessuna entità senza identificatore? |
| Completezza | Ogni frase dei requisiti è rappresentata? Ogni operazione richiesta è eseguibile sullo schema? |
| Minimalità | Ci sono concetti derivabili da altri (cicli di associazioni, attributi calcolabili)? Se li tengo, li ho documentati come ridondanze? |
| Leggibilità | Il diagramma si capisce senza spiegazioni? Nomi espressivi, pochi incroci fra le linee, entità principali al centro? |
Errori tipici
| Errore | Come riconoscerlo | Correzione |
|---|---|---|
| Cardinalità invertite | la lettura «ogni X partecipa…» non torna con il testo | rileggere sempre partendo dall'entità vicina al numero |
| Attributo che dovrebbe essere entità | si vogliono registrare proprietà di quel valore | promuoverlo a entità e collegarlo con un'associazione |
| Attributi ripetuti nelle figlie | lo stesso attributo compare nel padre e nelle figlie | toglierlo dalle figlie: l'ereditarietà è implicita |
| Storico impossibile | la traccia parla di «più volte» ma l'identificatore non contiene la data | entità debole o attributo aggiuntivo nell'identificatore |
| Associazione senza senso autonomo | il rombo si potrebbe sostituire con un attributo | semplificare: meno costrutti, più leggibilità |
| Entità isolata | un rettangolo non collegato a nulla | o manca un'associazione, o quel concetto non serve |
Esercizi svolti
Biblioteca
Traccia. Una biblioteca possiede più copie dello stesso libro. Di ogni libro interessano ISBN, titolo, anno e gli autori (che possono essere più di uno); di ogni copia interessa un numero d'inventario progressivo all'interno del libro e lo stato di conservazione. Gli utenti, identificati da una tessera, prendono in prestito le copie: di ogni prestito interessano la data di inizio e la data di restituzione, che manca finché il libro non è stato reso. Un utente può prendere in prestito più volte la stessa copia in momenti diversi.
Soluzione ragionata
Entità. Libro (ISBN identificatore, Titolo, Anno) e Autore (che ha proprietà proprie: nome, nazionalità) collegati da un'associazione molti a molti Scrittura. Se degli autori interessasse solo il nome si potrebbe usare un attributo multivalore su Libro, ma un'entità è più pulita e prepara meglio la traduzione.
Copia è un'entità debole: il numero d'inventario è progressivo dentro il libro, quindi da solo non identifica; l'identificatore è esterno, dato da Libro + Numero. Copia partecipa con (1,1) all'associazione con Libro.
Prestito. Lo stesso utente può prendere la stessa copia più volte: come per la visita della clinica, un'associazione molti a molti Utente–Copia non basterebbe. Prestito diventa un'entità debole identificata da Utente, Copia e DataInizio, con l'attributo opzionale DataRestituzione.
Torneo sportivo
Traccia. Si vuole gestire un torneo di calcio. Di ogni squadra interessano nome (unico), città e allenatore. Di ogni giocatore interessano codice, cognome, ruolo e la squadra in cui milita attualmente; un giocatore appartiene a una sola squadra, ma si vuole tenere traccia anche delle squadre in cui ha militato in passato, con data di acquisto e di cessione. Ogni partita mette di fronte due squadre, una in casa e una in trasferta, si gioca in una certa data e ha un risultato.
Soluzione ragionata
Il punto delicato è "attuale vs passato". Se si usasse una sola associazione Militanza molti a molti con le date, per sapere la squadra attuale bisognerebbe cercare quella con data di cessione mancante: scomodo e fragile. La soluzione elegante è partizionare l'associazione: Milita (attuale, (1,1) dal lato del giocatore) e Militanza passata (storico, molti a molti, con DataAcquisto e DataCessione).
La partita è un'associazione ricorsiva su Squadra, con i ruoli casa e trasferta. Ma poiché due squadre possono incontrarsi più volte (andata e ritorno), la data deve entrare nell'identificatore: di nuovo un'entità debole Partita, identificata dalle due squadre e dalla data, con attributo Risultato.
Questo esercizio contiene due dei tre schemi ricorrenti nei compiti: storico e ricorsione con ruoli. Il terzo è la generalizzazione.
Prossimo passo. Lo schema concettuale non si può dare in pasto a un DBMS. Nella progettazione logica lo si ristruttura (via generalizzazioni, ridondanze da valutare, attributi multivalore) e lo si traduce in tabelle: è lì che lo schema della clinica diventa le tre tabelle che hai usato in SQL.