Come si modella la realtà con lo schema E/R - Esempio noleggio e-bike e monopattini
Dal testo discorsivo allo schema concettuale: gestiamo mezzi elettrici, clienti privati e aziende, fornitori unici per modello, noleggi come eventi storici e listino tariffe con validità temporale.
1. Lo scenario: cosa ci chiede il problema
Progettare un DB per gestione noleggio e-bike e monopattini elettrici: ogni mezzo ha codice univoco, modello, marca, elettrico sì/no, pieghevole sì/no, categoria {City, Cargo, Mountain}, clienti (codice cliente, privati con nome+cognome+indirizzo+patente, aziende con p.iva+ragione sociale+indirizzo+referente), fornitori (codice, nome, p.iva, indirizzo, fornisce più modelli ma stesso modello sempre dallo stesso fornitore), noleggi (data inizio, data fine prevista ed effettiva, km percorsi, mezzo noleggiato), listino tariffe storico per modello con validità.
L'obiettivo è allenarti a riconoscere pattern, non a memorizzare entità.
Sottolinea subito con 3 colori: BLU i sostantivi che diventano entità, GIALLO gli aggettivi che diventano attributi, VERDE i verbi che diventano associazioni. Se un verbo ha attributi tipo data, km, importo -> è entità evento. Te lo chiedo sempre.
2. Analisi preliminare: i 5 aspetti da gestire
Prima di disegnare, scriviamo le 5 aree funzionali:
Mezzi elettrici
modello, marca, codice, caratteristiche stabili tipo pieghevole
Clienti + Fornitori
Privato vs Azienda, specializzazione totale/esclusiva
Noleggi
Evento storico: cliente + mezzo + date + km + importo
Tariffe
Listino variabile nel tempo, non attributo di MEZZO
Stabili vs variabili
Codici stabili, tariffe variabili: servono entità diverse
8 passi concettuali
Entità → Associazioni → Attributi → Molteplicità → Verifica
Pensa al negozio di e-bike: ha la bici esposta (MEZZO), chi te la vende (FORNITORE), te che la noleggi per il weekend (CLIENTE), il contratto (NOLEGGIO) e il cartellino prezzo giornaliero che cambia in estate (TARIFFA). Se lo racconti a voce, lo sai modellare.
3. Individuazione dei vincoli + ipotesi aggiuntive
A. Vincoli mezzo
- Codice mezzo univoco identificativo
- Marca + modello obbligatori
- elettrico boolean, pieghevole boolean
- categoria: {City, Cargo, Mountain} - ipotesi: ogni mezzo ha UNA sola categoria
Mettere "city" e "mountain" come due booleani separati. Così un mezzo potrebbe essere City E Mountain E né City né Mountain. Usa attributo singolo categoria con dominio {City, Cargo, Mountain}.
B. Vincoli clienti
- Codice cliente univoco, comune a privati e aziende
- PRIVATO: nome, cognome, indirizzo, numero patente
- AZIENDA: ragione sociale, indirizzo, p.iva, nominativo referente
CLIENTE come generalizzazione totale ed esclusiva: ogni cliente DEVE essere privato O azienda, non può essere entrambi, non può essere nessuno. Scrivi sempre "T,E" vicino al cerchio. Se lo ometti, modello incompleto.
C. Vincoli fornitori - il vincolo chiave
"Lo stesso modello è fornito sempre dallo stesso fornitore" → significa FORNITORE (0,n) --- (1,1) MODELLO. È un 1:N, NON N:M. Se sbagli questo, sbagli tutto.
D. Noleggi
Ogni noleggio: un cliente, un mezzo, data inizio, data fine prevista, data fine effettiva (nullable), km percorsi, importo applicato.
E. Listino tariffe
Tariffa giornaliera NON in MEZZO. Serve entità TARIFFA con data_inizio, data_fine (nullable), importo giornaliero, tipo {giornaliera, oraria}.
Ipotesi aggiuntive (dichiarate!)
| Ipotesi | Perché la introduco | Alternativa |
|---|---|---|
| codice_noleggio in NOLEGGIO | Cliente+data+mezzo non è chiave: stesso cliente può noleggiare stesso mezzo 2 volte lo stesso giorno | Chiave composta rischiosa e non stabile |
| importo_applicato in NOLEGGIO | Per storicizzare prezzo reale se tariffa cambia dopo restituzione | Non obbligatorio ma consigliato |
| codice_tariffa in TARIFFA | Identifica versioni temporali della tariffa | Alternativa: (codice_mezzo, data_inizio) come chiave |
| nome, indirizzo in CLIENTE | Attributi comuni a privati e aziende, evitano duplicazione | Mettere tutto nei sottotipi = ridondanza |
Univocità: codici unici
Esistenza: noleggio → cliente e mezzo esistenti
Coerenza temporale: data_fine_prevista ≥ data_inizio, data_fine_effettiva ≥ data_inizio
No sovrapposizioni: per stesso mezzo non due tariffe valide nello stesso periodo
Coerenza sottotipo: un cliente = un solo sottotipo
km ≥0, importo >0
4. Le entità: perché Noleggio e Tariffa sono entità
Schema finale: 5 entità principali + 2 sottotipi:
MEZZO
Esempi: E-Bike City 250W, Monopattino Pro. Attributi identificativi + booleani + categoria
CLIENTE (gen.)
Generalizzazione. Partecipa a EFFETTUA. Totale Esclusiva → PRIVATO, AZIENDA
FORNITORE
Codice, ragione sociale, p.iva, indirizzo. Fornisce N modelli.
NOLEGGIO
Perché è entità? Ha attributi propri (date, km, importo) ed è evento storico. Se fosse solo associazione tra CLIENTE e MEZZO non potresti avere stesso cliente+mezzo in date diverse.
TARIFFA
Perché è entità? Un attributo prezzo in MEZZO terrebbe solo prezzo corrente. Qui: City 25€ dal 1/6 al 31/8, 18€ resto anno... storico.
PRIVATO / AZIENDA
Ereditano codice_cliente. PRIVATO aggiunge patente, AZIENDA aggiunge p.iva e referente. Non creare associazioni separate per noleggi.
"Prof, NOLEGGIO non è un'associazione?" Risposta che voglio: "No, perché ha attributi propri e deve esistere come oggetto storico distinguibile, con identificatore proprio. Altrimenti non potrei registrare due noleggi identici in giorni diversi." Scrivetelo così.
5. Associazioni e specializzazione
Quattro associazioni + una specializzazione:
Molti disegnano FORNITORE - MEZZO come N:M "perché un fornitore fornisce più mezzi e un mezzo può essere fornito da più fornitori". Ma la traccia dice ESPLICITAMENTE il contrario: stesso modello SEMPRE dallo stesso fornitore. È 1:N. Leggete il vincolo.
6. Attributi: cosa mettere dove (e cosa NON duplicare)
MEZZO
Identificatore {PK}: codice_mezzo (non modello! Modello non è univoco). Altri: marca, modello, elettrico {Sì/No}, pieghevole {Sì/No}, categoria {City, Cargo, Mountain}
CLIENTE (soluzione compatta che preferisco)
Identificatore {PK}: codice_cliente, indirizzo → comuni. PRIVATO: nome, cognome, patente. AZIENDA: ragione_sociale, p.iva, referente. Così eviti duplicazione.
Variante ammessa: mettere indirizzo solo nei sottotipi. È corretta ma ridondante. Io premio la soluzione compatta perché dimostra che hai capito l'ereditarietà.
FORNITORE
Identificatore {PK}: codice_fornitore, nome, p.iva, indirizzo.
NOLEGGIO
Identificatore {PK}: codice_noleggio, data_inizio, data_fine_prevista, data_fine_effettiva, km_percorsi, importo_applicato. Non usare come chiave (cliente+data+mezzo): fallisce se noleggi due volte stesso mezzo lo stesso giorno.
Non creare NOLEGGIO_PRIVATO e NOLEGGIO_AZIENDA. I noleggi sono legati a CLIENTE generale. La specializzazione eredita già l'associazione. Doppia associazione = schema sporco.
TARIFFA
Identificatore {PK}: codice_tariffa, importo_giornaliero, data_inizio_validita, data_fine_validita (NULL se ancora valido), tipo_tariffa {Oraria, Giornaliera}.
Km NON è attributo di EFFETTUA, è di NOLEGGIO. Importo NON è attributo di APPARTENERE, è di TARIFFA.
7. Molteplicità e cardinalità con regole di lettura
Uso notazione (min,max): (0,1) facoltativo al max 1, (1,1) obbligatorio esattamente 1, (0,n) facoltativo n, (1,n) obbligatorio almeno 1.
| Associazione | Molteplicità | Cardinalità | Perché min=0 o 1? |
|---|---|---|---|
| FORNIRE FORNITORE-MEZZO | FORNITORE (0,n) — (1,1) MEZZO | 1:N | Fornitore (0,n): appena inserito può non avere mezzi. Mezzo (1,1): ogni mezzo deve avere fornitore. |
| EFFETTUARE CLIENTE-NOLEGGIO | CLIENTE (0,n) — (1,1) NOLEGGIO | 1:N | Cliente può non aver ancora noleggiato. Noleggio non esiste senza cliente. |
| RIGUARDARE NOLEGGIO-MEZZO | NOLEGGIO (1,1) — (0,n) MEZZO | N:1 | Noleggio riguarda 1 mezzo. Mezzo può non essere mai stato noleggiato. |
| APPARTENERE MEZZO-TARIFFA | MEZZO (0,n) — (1,1) TARIFFA | 1:N | Mezzo inserito prima di avere tariffa. Tariffa deve appartenere a 1 mezzo. |
Totale: ogni cliente è privato o azienda. Esclusiva: non può essere entrambi. Deriva da ipotesi che categorie siano alternative ed esaustive nel testo.
Molti disegnano FORNITORE - MEZZO come N:M "perché un fornitore fornisce più mezzi e un mezzo può essere fornito da più fornitori". Ma la traccia dice ESPLICITAMENTE il contrario: stesso modello SEMPRE dallo stesso fornitore. È 1:N. Leggete il vincolo, non inventate.
Regole di lettura (le voglio così in verifica!)
Se in verifica scrivete solo "1:N" senza min e max, per me è incompleto. Voglio vedere (0,N) vs (1,1) con motivazione del minimo. Il minimo racconta se l'entità può esistere senza l'altra.
8. Schema E/R finale
TUTTE LE ENTITA' rettangoli con nome all'interno, {PK} con attributi collegati e nominati
TUTTE LE ASSOCIAZIONI rombi con molteplicità indicate sul collegamento ENTITA'-ASSOCIAZIONE lato entità
TUTTE LE SPECIALIZZAZIONI con doppio segmento verso cerchio all'interno del quale si indica T/E → specializzazione (rettangolo come entità) collegata al cerchio da un segmento
9. Errori comuni e checklist finale (da stampare)
1. Tariffa in MEZZO → perdi storico
2. NOLEGGIO come associazione N:M tra CLIENTE e MEZZO → non puoi registrare 2 noleggi uguali in giorni diversi
3. FORNIRE N:M → viola vincolo "stesso modello sempre stesso fornitore"
4. Due entità PRIVATO e AZIENDA separate senza generalizzazione → duplichi associazioni
5. Km come attributo di CLIENTE o di MEZZO → non descrive l'evento noleggio
| Check | Domanda | Se NO, cosa fare |
|---|---|---|
| Entità | Ogni entità ha identificatore? | Aggiungi codice_noleggio, codice_tariffa |
| Specializzazione | Ho dichiarato T,E? | Scrivi "Totale Esclusiva" |
| Fornitore | MEZZO ha (1,1) verso FORNITORE? | Correggi molteplicità |
| Storico | Posso avere più tariffe per stesso mezzo? | Se no, hai messo tariffa in MEZZO |
| Sovrapposizioni | Ho previsto vincolo no-overlap date tariffa? | Annota nei vincoli di integrità |
| Lettura | Riesco a leggere schema ad alta voce? | Se inciampi, lo schema è sbagliato |
In verifica non guardo solo il disegno. Voglio: 1) vincoli scritti, 2) ipotesi dichiarate, 3) molteplicità con min/max, 4) regole di lettura, 5) identificatori visibili. Se manca uno di questi, anche se il disegno è bello, non è da 10.