Come si modella la realtà con lo schema E/R - esempio prenotazioni esami medici ASL
Dalla prenotazione al laboratorio: modelliamo ospedali, reparti, laboratori, esami e pazienti con identificatori composti, entità deboli e vincoli temporali. Uno dei casi tra i più completi che uso in classe.
1. Lo scenario ASL: cosa ci chiede la traccia
PAZIENTE: codice tessera sanitaria {PK}, cognome, nome, indirizzo, data e luogo nascita
ESAME: codice_esame {PK} numerico, descrizione (es. radiografia)
OSPEDALE: codice numerico {PK}, nome, indirizzo
LABORATORIO: codice univoco all'interno di un ospedale, nome_lab, piano, numero_stanza
PRENOTAZIONE: data esame, ora esame, laboratorio presso cui è eseguito, costo ticket, urgente sì/no
REPARTO: codice numerico univoco dentro ospedale, nome reparto, telefono
PERSONALE: codice_fiscale {PK}, nome, cognome, indirizzo
Vincoli: paziente più prenotazioni stesso esame in date diverse, ma NON stesso esame stesso giorno stesso paziente.
Questa è una delle tracce che uso sempre al compito in classe: sembra facile ma ci sono due entità deboli e una ternaria. Se le sbagli, perdi tutta la parte logica.
Quando leggi "codice univoco all'interno di..." → sottolinea DUE volte. È il segnale di entità debole. Non è un codice assoluto, ha bisogno del padre. Te lo chiedo sempre: "Di chi è figlio LABORATORIO?" Risposta giusta: di OSPEDALE.
2. Analisi preliminare: le 7 aree da gestire
PAZIENTE
Tessera sanitaria {PK} stabile, no duplicati
ESAME
Catalogo prestazioni, non istanza
OSPEDALE
Entità forte, padre di lab e reparto
LABORATORIO
Debole: id = {cod_lab + cod_ospedale}. Nome, piano, stanza
REPARTO
Debole: id = {cod_reparto + cod_ospedale}. Nome, telefono
PERSONALE
CF {PK}, afferisce a un reparto
PRENOTAZIONE
Ternaria + attributi: data, ora, ticket, urgente
8 passi
Come sempre: entità → ass. → attributi → ass. attrib. → (0,n) → lettura
3. Vincoli e ipotesi aggiuntive
A. Vincoli strutturali
- PAZIENTE identificato da codice_tessera_sanitaria {PK}
- ESAME identificato da codice_esame {PK}
- OSPEDALE identificato da codice_ospedale {PK}
- LABORATORIO identificato da {codice_lab, codice_ospedale} {PK} → debole
- REPARTO identificato da {codice_reparto, codice_ospedale} {PK} → debole
- PERSONALE identificato da codice_fiscale {PK}
B. Vincoli sulle prenotazioni - i più importanti
Ogni paziente può effettuare più prenotazioni dello stesso esame in date diverse, MA lo stesso esame non può essere ripetuto nello stesso giorno dallo stesso paziente. È un vincolo di unicità su (paziente, esame, data). Lo gestiamo in E/R come regola e poi nel logico come UNIQUE.
C. Ipotesi aggiuntive che dichiaro (come faccio in classe)
| Ipotesi | Perché | Alternativa |
|---|---|---|
| codice_prenotazione {PK} in PRENOTAZIONE | Data+ora non bastano: stesso paziente potrebbe prenotare due esami diversi stessa data/ora in lab diversi | Chiave composta (paziente, esame, lab, data, ora) troppo pesante |
| LABORATORIO entità debole | Testo: codice univoco dentro ospedale | Se fosse forte, codice dovrebbe essere globale |
| REPARTO entità debole | Stessa dicitura di lab | Idem |
| PERSONALE afferisce a 1 REPARTO | Testo dice "personale del reparto" → 1 reparto per persona, più realistico per ASL | Alternativa N:M se persona lavora in più reparti, ma non richiesto |
| PRENOTAZIONE entità associativa | Ha attributi propri: data, ora, ticket, urgente + lega 3 entità | Non può essere solo associazione binaria |
Univocità: tessera, codice_esame, cod_ospedale, CF unici. Identificazione esterna: lab e reparto senza ospedale non esistono. Esistenza: prenotazione deve avere paziente, esame, laboratorio esistenti. Temporale: data_esame ≥ data_prenotazione (se aggiungi data prenotazione). Unicità giornaliera: (cod_tessera, cod_esame, data_esame) unique. Quantità: ticket ≥0. Coerenza lab: lab deve appartenere ad ospedale della ASL.
4. Le entità e le entità deboli
PAZIENTE
codice_tessera_sanitaria {PK}, cognome, nome, indirizzo, data_nascita, luogo_nascita. Esempio: Mario Rossi TS123
ESAME
codice_esame {PK} numerico, descrizione. Es: 101 radiografia torace
OSPEDALE
codice_ospedale {PK} numerico, nome, indirizzo. Padre di lab e reparto
LABORATORIO
{codice_lab, codice_ospedale} {PK}, nome_lab, piano, numero_stanza. Es: LAB02 dell'ospedale 1 al 2° piano stanza 12
REPARTO
{codice_reparto, codice_ospedale} {PK}, nome_reparto, telefono. Es: reparto 3 cardiologia ospedale 1
PERSONALE
codice_fiscale {PK}, nome, cognome, indirizzo. Afferisce a reparto
PRENOTAZIONE
codice_prenotazione {PK}, data_esame, ora_esame, costo_ticket, urgente {Sì/No}. Lega PAZIENTE+ESAME+LABORATORIO
Disegna LABORATORIO e REPARTO con rettangolo doppio! E ricorda: la loro {PK} è composta. Se scrivi solo codice_lab {PK} è ERRORE. In verifica scrivo sempre: "Dove prende l'identità?" La risposta: dall'OSPEDALE tramite associazione di identificazione.
Molti fanno LABORATORIO con codice_lab {PK} unico globale. Ma la traccia dice "codice univoco all'interno di un ospedale". Significa che LAB01 può esistere sia in ospedale 1 che in ospedale 2. Se lo rendi forte, violi la traccia. Deve essere debole con identificazione esterna.
5. Le associazioni
Perché il diagramma si legge come frase: "OSPEDALE CONTENERE LABORATORIO". Se metti "contiene" o "ha" poi nella relazione inversa non torna. All'infinito è neutro e professionale.
Se fai solo PAZIENTE - ESAME con attributi data/ora/lab, perdi il laboratorio come entità autonoma e non puoi controllare che il lab appartenga a un ospedale. PRENOTAZIONE deve essere entità che lega 3 entità, non attributo di una binaria.
6. Attributi e identificatori {PK}
PAZIENTE
codice_tessera_sanitaria {PK}, cognome, nome, indirizzo, data_nascita, luogo_nascita. Tessera è stabile, mai duplicata.
ESAME
codice_esame {PK} numerico, descrizione. Es: 001 emocromo, 002 radiografia.
OSPEDALE
codice_ospedale {PK} numerico, nome, indirizzo. Es: 10 Ospedale di Varese.
LABORATORIO (debole)
{codice_lab, codice_ospedale} {PK}, nome_lab, piano, numero_stanza. Piano può essere 0,1,2. Stanza numerica. Attenzione: codice_lab da solo NON è {PK}.
REPARTO (debole)
{codice_reparto, codice_ospedale} {PK}, nome_reparto, telefono. Telefono del reparto, non del personale.
PERSONALE
codice_fiscale {PK}, nome, cognome, indirizzo. CF univoco per persona.
PRENOTAZIONE
codice_prenotazione {PK} (ipotesi mia), data_esame, ora_esame, costo_ticket, urgente {Sì/No} boolean. Data+ora separate per facilitare query. Urgente influenza priorità.
Senza codice, dovresti usare chiave composta (tessera, codice_esame, codice_lab, data, ora) enorme e fragile. Inoltre stesso paziente potrebbe prenotare due esami diversi stessa data/ora in lab diversi → chiave composta ambigua. Codice singolo è pulito e lo chiedo sempre in verifica per entità associative.
Se scrivi LABORATORIO: codice_lab {PK} è sbagliato. Devi scrivere {codice_lab, codice_ospedale} {PK} e collegarlo con associazione identificante a OSPEDALE.
7. Molteplicità (0,n) e regole di lettura
Notazione: minuscola (0,n), (1,n), (1,1), (0,1).
| Associazione | Molteplicità | Cardinalità | Lettura e perché min=0 o 1 |
|---|---|---|---|
| CONTENERE_LAB OSPEDALE-LAB | OSPEDALE (1,n) — (1,1) LAB | 1:n debole | Un ospedale deve contenere almeno 1 lab (1,n) altrimenti che ospedale è? Ogni lab (1,1) deve avere ospedale, altrimenti non esiste. |
| CONTENERE_REPARTO OSPEDALE-REPARTO | OSPEDALE (1,n) — (1,1) REPARTO | 1:n debole | Stesso ragionamento di lab. Ospedale senza reparti non ha senso gestionale. |
| AFFERIRE REPARTO-PERSONALE | REPARTO (0,n) — (1,1) PERSONALE | 1:n | Reparto può essere appena creato con 0 persone (0,n). Persona deve afferire a 1 reparto (1,1), altrimenti è fuori organico. |
| EFFETTUARE PAZIENTE-PRENOTAZIONE | PAZIENTE (0,n) — (1,1) PRENOTAZIONE | 1:n | Paziente può esistere senza prenotazioni (0,n). Prenotazione senza paziente non esiste (1,1). |
| RIGUARDARE ESAME-PRENOTAZIONE | ESAME (0,n) — (1,1) PRENOTAZIONE | 1:n | Esame in catalogo può non essere mai prenotato (0,n). Prenotazione riguarda 1 esame (1,1). |
| SVOLGERE LAB-PRENOTAZIONE | LAB (0,n) — (1,1) PRENOTAZIONE | 1:n | Lab può avere 0 prenotazioni (appena aperto). Prenotazione si svolge in 1 lab (1,1). |
Regole di lettura complete (come le voglio in verifica)
8. Schema E/R finale
TUTTE LE ENTITA'FORTI rettangoli con nome all'interno, {PK} con terminale pieno + attributi con terminale vuoto collegati al rettangolo e nominati
TUTTE LE ASSOCIAZIONI molteplicità indicate sul collegamento ENTITA'- ASSOCIAZIONE lato entità
TUTTE LE ENTITA' DEBOLI con doppio rettangolo e stesse regole di rappresentazione attributi, PK, molteplicità
9. Errori comuni e checklist finale
1. LABORATORIO e REPARTO come entità forti con {PK} singolo → perdi identificazione esterna, codice non più univoco solo dentro ospedale
2. PRENOTAZIONE come associazione N:M tra PAZIENTE ed ESAME → perdi laboratorio e attributi costo/urgente
3. OSPEDALE-LABORATORIO N:M → un lab non può appartenere a due ospedali diversi, è 1:n debole
4. PERSONALE senza collegamento a REPARTO → il testo dice "personale del reparto", deve afferire
5. Dimenticare vincolo "stesso esame stesso giorno stesso paziente" → manca UNIQUE, schema incompleto
| Check | Domanda | Se NO, cosa fare |
|---|---|---|
| Deboli | LAB e REPARTO hanno {PK} composta + doppio rettangolo? | Aggiungi codice_ospedale in PK e associazione identificante |
| Ternaria | PRENOTAZIONE lega 3 entità? | Se lega solo 2, rifai |
| Vincolo giorno | Annotato UNIQUE su (paziente, esame, data)? | Scrivi nei vincoli |
| Lettura | Riesco a leggere ad alta voce? | Se inciampi, rifai associazioni |
Questa traccia vale 10 se: 1) individui le due deboli, 2) fai PRENOTAZIONE come entità con {PK}, 3) scrivi regole di lettura complete, 4) annoti vincolo UNIQUE giornaliero. Se manca anche solo uno, non è da 10. Allenatevi a consegnare tutto, non solo il disegnino.