Come si modella la realtà con lo schema E/R - Esempio Festival Musicale Estivo
Un caso di studio completo per passare dal testo in linguaggio naturale allo schema E/R: entità, associazioni, attributi, molteplicità e regole di lettura.
- Trasformare un testo discorsivo in entità e associazioni.
- Riconoscere quando un concetto è entità e non attributo.
- Assegnare correttamente molteplicità (0,n) (1,n) (1,1) (0,1).
- Gestire ipotesi aggiuntive e attributi non espliciti.
- Leggere lo schema ad alta voce per validarlo.
1. Scenario in linguaggio naturale
Un comune organizza ogni estate un Festival Musicale che dura due settimane. L'organizzazione vuole gestire la programmazione dei concerti e la vendita dei biglietti.
Per ogni ARTISTA si vuole conoscere il nome d'arte e il genere musicale. Ogni artista partecipa ad almeno un evento durante il festival, ma può esibirsi in più serate.
Il festival dispone di alcuni PALCHI. Ogni palco ha un nome identificativo (es. Main Stage) e una capienza massima di pubblico. Un palco ospita più eventi durante il festival, ma un evento si svolge su un unico palco.
Ogni EVENTO è identificato da un codice evento e si caratterizza per data, ora inizio e ora fine. In uno stesso giorno possono esserci più eventi su palchi diversi.
I BIGLIETTI sono emessi per i singoli eventi. Ogni biglietto ha un codice univoco, un prezzo e una tipologia (Intero, Ridotto, VIP). Un biglietto è valido per un solo evento, ma un evento può avere migliaia di biglietti emessi, anche di tipologie diverse.
Gli SPETTATORI acquistano i biglietti. Di uno spettatore interessano nome, cognome, email. Uno spettatore può acquistare più biglietti, anche per eventi diversi, ma un biglietto è acquistato da un solo spettatore. Al momento dell'acquisto si registra data e ora di acquisto.
Infine, un gruppo di TECNICI audio/luci assicura il funzionamento dei palchi. Ogni tecnico ha matricola, specializzazione (Audio, Luci, Video) e telefono. Un tecnico è assegnato a un solo palco per tutta la durata del festival, mentre un palco può avere più tecnici assegnati. Si vuole tenere traccia del ruolo svolto (Fonico, Elettricista, Operatore).
Lo scenario non dice esplicitamente: cosa succede se un artista salta? Un palco può rimanere vuoto un giorno? Un biglietto può restare invenduto? Sono ipotesi che devi esplicitare tu per giustificare le molteplicità.
2. Analisi preliminare - i sostantivi e i verbi
Sostantivi candidati entità: ARTISTA, PALCO, EVENTO, BIGLIETTO, SPETTATORE, TECNICO. Tutti hanno esistenza autonoma e attributi propri.
Verbi candidati associazioni: esibisce (ARTISTA-EVENTO), ospita (PALCO-EVENTO), valido_per (BIGLIETTO-EVENTO), acquista (SPETTATORE-BIGLIETTO), assegnato_a (TECNICO-PALCO).
1) Ha un identificatore? 2) Ha almeno 2 attributi propri? 3) Ha una vita autonoma? 4) Partecipa ad almeno una associazione? Se sì a 3 su 4 → è entità. BIGLIETTO supera tutti i filtri, non è un attributo di EVENTO.
3. Le entità e gli identificatori
| Entità | Identificatore | Attributi principali | Note / Ipotesi |
|---|---|---|---|
| ARTISTA | id_artista | nome_arte, genere | nome_arte non univoco |
| PALCO | id_palco | nome, capienza | capienza >0 |
| EVENTO | cod_evento | data, ora_inizio, ora_fine | ora_fine > ora_inizio |
| BIGLIETTO | cod_biglietto | prezzo, tipologia {Intero,Ridotto,VIP} | tipologia dominio chiuso |
| SPETTATORE | id_spettatore | nome, cognome, email | email può essere identificatore alternativo |
| TECNICO | matricola | specializzazione, telefono | specializzazione {Audio,Luci,Video} |
4. Le associazioni individuate
| Associazione | Tra | Significato |
|---|---|---|
| ESIBIZIONE | ARTISTA - EVENTO | Quale artista si esibisce in quale evento |
| OSPITA | PALCO - EVENTO | Quale palco ospita l'evento |
| VALIDO_PER | BIGLIETTO - EVENTO | Per quale evento è valido il biglietto |
| ACQUISTO | SPETTATORE - BIGLIETTO | Chi acquista il biglietto, con data_ora_acquisto |
| ASSEGNAZIONE | TECNICO - PALCO | Quale tecnico è assegnato a quale palco, con ruolo |
ACQUISTO e VALIDO_PER sembrano ridondanti ma non lo sono: un biglietto esiste anche invenduto, quindi deve essere legato a EVENTO indipendentemente da SPETTATORE. Se unissi tutto in SPETTATORE-EVENTO perderesti prezzo e tipologia.
5. Attributi delle entità e delle associazioni
Alcuni attributi non erano espliciti nello scenario e vanno ipotizzati:
- ESIBIZIONE: cachet (compenso artista per quell'evento) - opzionale, ma utile.
- ACQUISTO: data_ora_acquisto - è l'unico attributo che descrive l'evento di acquisto, non può stare in SPETTATORE né in BIGLIETTO.
- ASSEGNAZIONE: ruolo_svolto {Fonico, Elettricista, Operatore} - attributo dell'assegnazione, non del tecnico (un tecnico può fare ruoli diversi su palchi diversi? Ipotesi: no, nel festival è fisso).
Mettere data_ora_acquisto in SPETTATORE: se uno spettatore compra 3 biglietti in momenti diversi, dove metti le 3 date? Deve stare sull'associazione ACQUISTO.
6. Molteplicità e cardinalità - il cuore del modello
Qui si decide la semantica. Dichiara sempre le ipotesi:
| Associazione | Lato A | Lato B | Ipotesi giustificata |
|---|---|---|---|
| ESIBIZIONE | ARTISTA (1,n) - (1,n) EVENTO | M:N | Ipotesi: un artista deve avere almeno 1 evento (1,n), un evento ha almeno 1 artista (1,n). Se un evento potesse essere annullato → (0,n) lato ARTISTA? Noi scegliamo (1,n) perché festival pubblicato. |
| OSPITA | PALCO (0,n) - (1,1) EVENTO | 1:N | Un palco può rimanere libero un giorno (0,n), un evento deve avere esattamente 1 palco (1,1). |
| VALIDO_PER | BIGLIETTO (1,1) - (0,n) EVENTO | 1:N | Ogni biglietto deve riferirsi a 1 evento (1,1), un evento può avere 0 biglietti emessi all'inizio (0,n) poi migliaia. |
| ACQUISTO | SPETTATORE (0,n) - (0,1) BIGLIETTO | 1:N | Spettatore registrato può non aver ancora acquistato (0,n). Biglietto può rimanere invenduto (0,1) prima della vendita. Dopo vendita diventa (1,1) ma modelliamo 0,1 per gestire invenduto. |
| ASSEGNAZIONE | TECNICO (1,1) - (0,n) PALCO | 1:N | Ogni tecnico assegnato a esattamente 1 palco (1,1). Un palco può avere 0 tecnici? No, ipotesi festival: almeno 1, ma per sicurezza modelliamo (0,n) per permettere palco appena creato senza tecnici. Meglio (1,n) se vincolo stretto. Qui scegliamo (1,n) per realtà: vedi nota sotto. |
Ho scritto (0,n) per PALCO ma in una versione più restrittiva potresti mettere (1,n): ogni palco deve avere almeno un tecnico. Entrambe sono accettabili SE giustifichi. In verifica scrivi: Ipotizzo che un palco possa esistere senza tecnici solo in fase di allestimento iniziale, quindi (0,n), altrimenti (1,n).
Correzione finale scelta: Per coerenza con testo "un palco può avere più tecnici assegnati" e non dice obbligatorio, ma per sicurezza festival manteniamo PALCO (1,n) - TECNICO (1,1). Così un tecnico ha un palco, un palco ha almeno un tecnico. Biglietto invenduto giustifica (0,1).
Quindi tabella finale pulita per disegno:
- ARTISTA (1,n) - (1,n) EVENTO
- PALCO (1,n) - (1,1) EVENTO [ogni evento 1 palco, ogni palco almeno 1 evento]
- EVENTO (0,n) - (1,1) BIGLIETTO [ogni biglietto 1 evento]
- SPETTATORE (0,n) - (0,1) BIGLIETTO [biglietto può essere invenduto]
- PALCO (1,n) - (1,1) TECNICO [tecnico 1 palco]
7. Regole di lettura e vincoli
- Un artista si esibisce in uno o più eventi, un evento prevede uno o più artisti.
- Un palco ospita uno o più eventi, ogni evento è ospitato da un solo palco.
- Un evento ha zero o più biglietti, ogni biglietto è valido per un solo evento.
- Uno spettatore acquista zero o più biglietti, ogni biglietto è acquistato da zero o uno spettatore (invenduto ammesso).
- Un palco impiega uno o più tecnici, ogni tecnico è assegnato a un solo palco.
- ora_fine > ora_inizio
- capienza palco >= numero biglietti emessi per evento su quel palco (vincolo da verificare a livello applicativo)
- email spettatore formato valido
- data_ora_acquisto <= data evento
- tipologia biglietto dominio {Intero,Ridotto,VIP}
8. Schema E/R finale
Lo schema deve contenere tutte le entità con identificatore, attributi e le 5 associazioni con molteplicità indicate sul lato entità.
ENTITA' rettangoli con PK evidenziata, attributi nominati
ASSOCIAZIONI rombi con nome e molteplicità (min,max) sul lato entità
ATTRIBUTI DI ASSOCIAZIONE collegati al rombo
9. Errori comuni e checklist finale
1. BIGLIETTO come attributo di EVENTO → perdi prezzo, tipologia e storico invenduto
2. ACQUISTO come associazione M:N SPETTATORE-EVENTO → non puoi distinguere due biglietti diversi dello stesso spettatore per stesso evento
3. TECNICO senza associazione a PALCO → viola "assegnato a un solo palco"
4. ESIBIZIONE 1:N invece di M:N → un evento può avere più artisti e un artista più eventi
5. data_ora_acquisto in SPETTATORE o BIGLIETTO → non gestisci più acquisti in momenti diversi
| Check | Domanda | Se NO, cosa fare |
|---|---|---|
| Entità | Ogni entità ha identificatore? | Aggiungi id_artista, cod_evento, ecc. |
| Biglietto invenduto | Posso avere biglietto con (0,1)? | Metti (0,1) lato BIGLIETTO in ACQUISTO |
| Attributi associazione | data_acquisto sta su ACQUISTO? | Sposta da entità ad associazione |
| Molteplicità | Ho almeno un (0,n) un (1,n) un (1,1) e un (0,1)? | Rivedi ipotesi palchi vuoti / biglietti invenduti |
| Vincoli | Ho scritto vincoli extra? | Aggiungi ora_fine>ora_inizio ecc. |
| Lettura | Riesco a leggere ad alta voce? | Se inciampi, correggi molteplicità |
In verifica non guardo solo il disegno. Voglio: 1) ipotesi scritte, 2) molteplicità giustificate, 3) attributi di associazione visibili, 4) regole di lettura, 5) identificatori. Se manca ipotesi su biglietto invenduto o palco senza tecnici, anche se il disegno è bello, non è da 10.