Teoria Informatica
Database · Modello E-R · Modello Logico
1 Introduzione Database
Esempio concreto: il valore 100, da solo, è un dato. Se gli si associa un contesto (voto in decimi, euro, centimetri, …) diventa un’informazione.
2 I Database
- Consistenza/coerenza (non esistono dati che si contraddicono).
- Riservatezza/autenticazione (accesso ai dati consentito solo alle persone autorizzate).
- Permanenza dei dati (operazioni di backup e ripristino che garantiscono la conservazione dei dati nonostante eventi distruttivi, interni o esterni al sistema).
- Efficienza (utilizzo ottimale delle risorse e ottimizzazione delle tempistiche di uso del database).
Le 4 fasi di creazione di un database
La creazione di un database prevede 4 fasi, nello stesso ordine del disegno: analisi dei requisiti, progettazione concettuale, progettazione logica, progettazione fisica. Il risultato di una fase è il punto di partenza della fase successiva.
- Analisi dei requisiti: il progettista studia le richieste del committente. È il materiale di partenza della fase successiva; nel disegno compare come titolo, non come riquadro.
- Progettazione concettuale: il progettista astrae e generalizza i concetti del minimondo (la porzione di realtà di cui si vogliono memorizzare i dati) e li disegna in uno schema grafico. Questo schema è il modello concettuale; nel disegno è chiamato schema concettuale. Sono lo stesso risultato. Non dipende ancora dal tipo di database che si userà. Di solito, a fine fase, il progettista lo mostra al committente.
- Progettazione logica (traduzione del modello concettuale nel modello logico): il progettista riscrive il modello concettuale con le strutture previste dal tipo di database scelto. Il risultato è il modello logico; nel disegno è chiamato schema logico. Non dipende ancora da come i dati saranno memorizzati sui dispositivi: questa scelta arriva solo nella fase successiva.
- Progettazione fisica (creazione del modello fisico): il progettista stabilisce come memorizzare i dati nelle memorie di massa. È l’implementazione fisica del database e produce lo schema fisico.
3 E-R — Modello Concettuale
Il modello concettuale che usiamo è il modello E-R (Entity-Relationship). Entity significa entità. Relationship si traduce «relazione», ma in questo manuale il legame tra entità si chiama associazione: per questo si parla anche di modello entità-associazione. Questa associazione non è la «relazione» del modello logico, che è una tabella: sono due parole dello stesso ambito, con due significati diversi. Il modello E-R si basa su 4 costrutti:
- Entità: una categoria di oggetti della realtà che hanno caratteristiche comuni (gli attributi). Il nome è un sostantivo singolare e, nel diagramma, inizia con la maiuscola: Studente, non studenti. Ha un’esistenza autonoma, cioè se ne può parlare senza dover citare un’altra entità.
- Attributo: una caratteristica dell’entità. Di ogni attributo si indicano:
- il nome;
- il tipo (numerico, stringa, data/ora);
- la dimensione (quanti caratteri o quante cifre);
- l’opzionalità: se il valore è obbligatorio oppure può mancare.
- Associazione: il legame logico tra entità. Ha un nome e può avere attributi propri.
- Identificatore: l’attributo, o il gruppo di attributi, che distingue ogni istanza dell’entità da tutte le altre.
Esempi di entità: Studente, Classe, Docente, Auto, Libro.
Convenzioni grafiche
- L’entità si indica con un rettangolo al cui interno vi è il nome dell’entità.
- L’associazione tra due entità si indica con un rombo al cui interno vi è il nome dell’associazione, collegato alle entità che lega tramite segmenti.
- Un attributo di un’entità si indica mediante un segmento che ha inizio dal rettangolo che rappresenta l’entità e che termina con un pallino e con il nome dell’attributo.
- L’attributo (o l’insieme degli attributi) che identifica univocamente un’istanza dell’entità si chiama identificatore e graficamente viene identificato con un pallino pieno.
- Se l’identificatore è formato da più attributi (identificatore composto), i componenti hanno pallino vuoto, sono collegati da una barra orizzontale e all’estremità della barra si trova un unico pallino pieno (es. Presidente: Nome + Cognome).
- Per le entità deboli, l’identificatore si disegna con un pallino pieno unito da un segmento all’associazione identificante. Quell’identificatore non sta tutto sull’entità debole: è l’identificatore dell’entità forte più uno o più attributi dell’entità debole. Questi ultimi si chiamano chiave parziale.
Entità deboli
Generalizzazione e specializzazione
Se alcuni attributi di un’entità sono valorizzabili solo per una parte delle sue istanze mentre per le altre resterebbero vuoti, conviene allora raccogliere quelle istanze in una sottoentità. L’entità più generale si chiama generalizzazione (o entità padre); ogni sottoentità si chiama specializzazione (o entità figlia).
Le entità figlie ereditano tutti gli attributi dell’entità padre (compreso l’identificatore) e le relative associazioni, ma hanno attributi propri e possono avere associazioni proprie.
- Il primo elemento riguarda le istanze del padre.
- totale (t): ogni istanza del padre sta in almeno una figlia. Nel circolo, ogni socio è tennista, calciatore, o entrambi.
- parziale (p): qualche istanza del padre non sta in nessuna figlia. Nel modello E-R seguente esiste uno studente che non è né DSA, né Trinity, né con permesso.
- Il secondo elemento riguarda le istanze che stanno in più figlie.
- esclusiva (e): nessuna istanza sta in due figlie. Ad esempio, se la copertura del circolo fosse esclusiva, nessun socio sarebbe sia calciatore sia tennista.
- sovrapposta (s): qualche istanza sta in più figlie. Nel modello E-R seguente uno studente può essere, per esempio, sia DSA sia Trinity, oppure DSA e con permesso.
Altro esempio di generalizzazione:
Associazione ricorsiva
L’associazione ricorsiva collega istanze della stessa entità. Si usa quando quelle istanze sono in gerarchia: una persona è padre di un’altra persona, un dipendente è capo di un altro dipendente.
Associazioni binarie, ternarie e n-arie
Un’associazione è binaria se collega due entità, ternaria se ne collega tre, n-aria se ne collega n.
Esempio di associazione binaria:
Cardinalità delle associazioni binarie
Le cardinalità di un’associazione binaria sono due coppie (min, max), una accanto a ciascuna entità. La coppia scritta accanto a un’entità non conta le istanze di quell’entità: conta quante istanze dell’altra entità possono essere collegate a una sua istanza. Il primo numero è il numero minimo di istanze dell’altra entità collegate a una sua istanza, il secondo numero è il numero massimo di istanze dell’altra entità collegate a una sua istanza.
Da questi massimi si ricava il tipo di associazione:
1) Uno a uno (si scrive 1:1)
Il massimo è 1 da entrambi i lati: ogni istanza di ciascuna entità è collegata a non più di un’istanza dell’altra. Il minimo, nella stessa coppia, dice se il legame è obbligatorio (1) o può mancare (0). Nell’esempio, accanto a Stato c’è (0,1) e accanto a Presidente c’è (1,1): i due massimi valgono 1, quindi l’associazione è 1:1; lo 0 dice che uno stato può non avere un presidente.
Altro esempio:
2) Uno a molti (si scrive 1:n)
Un lato ha massimo 1, l’altro ha massimo n. Si legge sempre la coppia accanto all’entità, e quella coppia parla dell’altra entità. Nell’esempio:
- accanto a Studente c’è (1,1): ogni studente è iscritto a esattamente una classe;
- accanto a Classe c’è (1,n): ogni classe raccoglie uno o più studenti.
I «molti» sono gli studenti che condividono la stessa classe, non il numero scritto accanto alla classe. In traduzione (Regola 2, Caso 1) la chiave esterna va nell’entità che ha il massimo 1 accanto a sé, qui Studente.
3) Molti a molti (si scrive n:n)
Il massimo è n da entrambi i lati. Nell’esempio, accanto ad Autore e accanto a Libro c’è (1,n): un autore scrive uno o più libri e un libro ha uno o più autori. Non c’è un lato con massimo 1, quindi in traduzione non basta una chiave esterna in una delle due tabelle: serve una tabella nuova (Regola 2, Caso 2).
Attributi composti e multivalore
La cardinalità di un attributo è la coppia (minimo, massimo) di valori che quell’attributo può avere per una stessa istanza. Se l’attributo è singolo, cioè non multivalore, la coppia di solito non si disegna: l’opzionalità dice già se il valore è obbligatorio o può mancare. La coppia si scrive quando l’attributo è multivalore, come (0,n) accanto a Patente nel disegno seguente: una persona può non avere patenti oppure averne diverse.
Il dominio
4 Il Modello Logico
Il modello logico non è un disegno: è uno schema scritto con le strutture del tipo di database scelto. Qui usiamo il database relazionale, ideato nel 1970 da E. F. Codd (IBM) a partire dal concetto matematico di relazione. Lo schema che ne risulta si chiama modello logico relazionale. In questo modello la relazione è ciò che poi si scrive come tabella: non va confusa con l’associazione del modello E-R.
D1 = {FIAT, FORD, OPEL} D2 = {TIPO, PUMA, CORSA}
Il prodotto D1 × D2 contiene tutte e 9 le coppie possibili: (FIAT, TIPO), (FIAT, PUMA), (FIAT, CORSA), (FORD, TIPO), (FORD, PUMA), (FORD, CORSA), (OPEL, TIPO), (OPEL, PUMA), (OPEL, CORSA).
La relazione R tiene solo le coppie in cui il secondo valore è un modello del primo: R = {(FIAT, TIPO), (FORD, PUMA), (OPEL, CORSA)}. (FIAT, PUMA) sta nel prodotto cartesiano, ma non in R.
Le relazioni spesso vengono scritte in forma tabellare.
| Marca (D1) | Modello (D2) |
|---|---|
| Fiat | Tipo |
| Ford | Puma |
| Opel | Corsa |
In una tabella, un attributo è l’intestazione di una colonna. L’ordine delle colonne e l’ordine delle righe non contano. I valori di una stessa colonna sono tutti dello stesso tipo. Non esistono due righe uguali: per questo l’insieme di tutti gli attributi basta a distinguere una riga da tutte le altre.
Chiave esterna
Nell’esempio sotto, nomeClasse nella tabella Studente è una chiave esterna perché fa riferimento alla chiave primaria nomeClasse della tabella Classe.
| Matricola (PK) | Nome | Cognome | nomeClasse (FK) |
|---|---|---|---|
| M103 | Mario | Rossi | 3D |
| M104 | Giulia | Bianchi | 4H |
| M105 | Lino | Lini | 3D |
| M106 | Anna | Rosi | 5F |
| M107 | Mino | Mei | 3T |
| nomeClasse (PK) | numeroAula | NumeroAlunni |
|---|---|---|
| 3D | 5 | 20 |
| 5F | 8 | 12 |
| 4H | 12 | 18 |
I valori della chiave primaria non si ripetono nella stessa tabella. I valori della chiave esterna si possono ripetere (più studenti nella stessa classe), ma ognuno di essi deve già comparire nella chiave primaria della tabella collegata. Nell’esempio 3T, valore della chiave esterna della tabella Studente non è tra i valori della chiave primaria della tabella Classe. Questo porta a chi legge la tabella a dubitare che ci sia stato un errore di inserimento e che Mino Mei faccia un’altra classe e non la classe 3T (oppure dubitare che effettivamente Mino Mei faccia la classe 3T di cui in questo caso però non abbiamo nessuna informazione).
Il vincolo di integrità referenziale evita proprio il problema perché impedisce di inserire il valore di una chiave esterna che non esiste tra i valori della chiave primaria collegata; quindi ad esempio se ci fosse stato il vincolo di integrità referenziale non avrei potuto inserire il valore «3T» nella riga dell’alunno Mino Mei.
La tabella che contiene la chiave esterna si chiama tabella referenziante. Nel manuale è chiamata anche tabella referenziale o slave: è la tabella che punta all’altra. La tabella la cui chiave primaria viene citata si chiama tabella referenziata (o master). «Referenziale» è un sinonimo di referenziante, non di referenziata.
Vincoli
Esistono due tipi di vincolo:
- Vincolo interrelazionale: coinvolge più tabelle. L’integrità referenziale è di questo tipo, perché confronta la chiave esterna di una tabella con la chiave primaria di un’altra.
- Vincolo intrarelazionale: riguarda una sola tabella. Può essere:
- di dominio, se controlla un solo attributo (per esempio i valori ammessi per Voto);
- di tupla, se controlla insieme due o più attributi della stessa riga (per esempio Voto e Lode).
| IdEsame (PK) | Data | Voto | Lode | NumeroEsame | Matricola (FK) |
|---|---|---|---|---|---|
| E104 | 10/11/2023 | 26 | No | 3 | M105 |
| E106 | 10/04/2024 | 25 | No | 4 | M105 |
| E107 | 10/11/2024 | 30 | Sì | 2 | M106 |
| E108 | 10/10/2023 | 32 | No | 6 | M104 |
| E109 | 20/09/2022 | 28 | Sì | 5 | M104 |
| E110 | 23/12/2023 | 26 | No | 72 | M103 |
Nella tabella Esame tre celle rosse violano un vincolo. Il numero di riga è quello dei dati, senza contare l’intestazione.
Il vincolo di dominio Voto>=18 AND Voto<=30 blocca l’Errore 1: guarda solo la colonna Voto.
Il vincolo di tupla Lode="No" OR Voto=30 blocca l’Errore 2: è soddisfatto se la lode è «No», oppure se il voto è 30. Guarda insieme Voto e Lode.
Il vincolo di dominio NumeroEsame>0 AND NumeroEsame<31 blocca l’Errore 3: guarda solo la colonna NumeroEsame.
Notazione del modello logico relazionale
Nel modello logico relazionale le tabelle vengono scritte nella forma:
Esame (IdEsame(PK), data, voto, lode, numeroEsame, Matricola(FK))
dove PK è la chiave primaria e FK è la chiave esterna. Se la chiave è composta da più attributi, i nomi stanno dentro la parentesi: PK(Matricola, IdEsame), FK(CodiceL, Inventario). L’ordine degli attributi è fisso: prima la PK, poi gli attributi propri della tabella, per ultime le FK. Se le FK sono più di una, restano in coda nello stesso ordine in cui compaiono. Nell’esempio, IdEsame è la PK; data, voto, lode e numeroEsame sono attributi propri; Matricola è la FK ed è l’ultimo nome. La stessa notazione è usata nella teoria e negli esercizi.
Procedimento di traduzione dal modello E-R al modello logico
La traduzione dal modello E-R al modello logico avviene in 3 passi ordinati. L’ordine è importante: prima si ristruttura (applicando la Regola 1), poi si traducono entità e associazioni (applicando la Regola 2).
- Passo 1 — Ristrutturazione (Regola 1): si eliminano i costrutti che il modello logico non rappresenta: attributo composto, attributo multivalore, generalizzazione e associazione ricorsiva (che si scioglie sdoppiando l’entità nei suoi due ruoli). Si ottiene il modello E-R ristrutturato.
- Passo 2 — Traduzione delle entità: ogni entità del modello ristrutturato diventa una tabella. Gli attributi dell’entità diventano colonne; l’identificatore diventa la chiave primaria (PK).
- Passo 3 — Traduzione delle associazioni (Regola 2): nel modello logico non esiste il rombo e ogni associazione va tradotta in tabelle e/o chiavi esterne.
Regola 1 — Eliminazione dei costrutti del modello E-R non presenti nel modello logico
Si eliminano quattro costrutti, che il modello logico non rappresenta: attributo composto, attributo multivalore, generalizzazione, associazione ricorsiva.
Il modello E-R che resta si chiama modello E-R ristrutturato. In questa stessa fase si cerca anche di ridurre lo spazio occupato, la ridondanza e il tempo di accesso: è lo stesso lavoro di ristrutturazione, non una fase in più.
Eliminazione dell’attributo composto
L’attributo composto si cancella e al suo posto restano gli attributi atomici che lo componevano. Il nome dell’attributo composto non diventa una colonna: nel disegno, Indirizzo scompare e restano Via, NumeroCivico e Città.
Eliminazione dell’attributo multivalore
L’attributo multivalore diventa un’entità nuova, collegata all’entità di partenza. L’associazione è 1:n oppure n:n, e la scelta si legge sui due esempi di questa sezione:
- 1:n, se lo stesso valore appartiene a una sola istanza. Un numero di telefono è di un solo dipendente: Telefono ha Numero come identificatore e, accanto a Telefono, il massimo verso Dipendente è 1.
- n:n, se lo stesso valore è condiviso da più istanze. La stessa lingua è parlata da più persone: Lingua è un’entità a sé (identificatore Nome) e l’associazione Parla ha massimo n da entrambi i lati.
Eliminazione delle generalizzazioni
Le generalizzazioni si eliminano durante la ristrutturazione, non mentre si disegna il modello E-R di partenza. I metodi sono tre e sono alternativi. La scelta usa, in quest’ordine, informazioni già presenti nello schema: la copertura (t/p, e/s), poi gli attributi e le associazioni proprie delle figlie, poi il prezzo che si accetta di pagare (valori vuoti, tabelle in più, associazioni duplicate). La tavola in fondo a questa sezione riassume la stessa scelta.
Metodo 1 — Eliminazione dell’entità padre. Il padre si cancella. Ogni figlia riceve gli attributi del padre, identificatore compreso, e anche le associazioni del padre, ripetute una volta per figlia.
- Si può usare solo se la copertura è totale: ogni istanza del padre sta in almeno una figlia. Se fosse parziale, le istanze dell’entità padre che non appartengono a nessuna delle entità figlie non avrebbero più una tabella in cui stare.
- È la scelta migliore se la copertura è anche esclusiva (nessuna istanza in due figlie: altrimenti la stessa istanza andrebbe copiata in due tabelle) e se le figlie hanno molti attributi propri.
- In cambio lo schema si allunga. Per elencare tutte le istanze dell’entità padre — tutti i soci, tennisti e calciatori insieme — i dati vanno raccolti dalle tabelle delle figlie.
Metodo 2 — Eliminazione delle entità figlie. Le figlie si cancellano e i loro attributi si spostano sul padre. Resta una sola entità, quindi poi una sola tabella.
- Si può usare in tutti i casi tranne uno: se un’associazione riguarda una sola figlia. In quel caso il Metodo 2 è sbagliato, perché l’associazione finirebbe sul padre e non varrebbe più «solo per quella figlia».
- Conviene quando la copertura è parziale (esistono istanze dell’entità padre che non appartengono a nessuna delle entità figlie), quando è sovrapposta, oppure quando le figlie sono «povere»: pochi attributi specifici e nessuna associazione propria.
- Gli attributi di una figlia restano vuoti sulle istanze delle altre: aumentano i dati nulli.
- Conviene aggiungere un attributo di controllo (tipo, razza) che dica a quale figlia appartiene l’istanza.
Metodo 3 — Sostituzione con associazioni 1:1. Il padre resta. Ogni figlia resta. Al posto della freccia di generalizzazione si disegna un’associazione 1:1 tra il padre e quella figlia. Il metodo è sempre possibile.
- Conviene quando una figlia ha associazioni proprie che non si vogliono spostare sul padre (solo i medici seguono i ricoveri), oppure quando si vogliono evitare insieme i valori vuoti del Metodo 2 e le associazioni duplicate del Metodo 1.
- Con copertura parziale, chi non appartiene a nessuna figlia resta solo nel padre. Con copertura sovrapposta, la stessa istanza può avere due associazioni 1:1, una per figlia.
- In cambio le tabelle sono di più. Per leggere una figlia completa bisogna affiancare la riga del padre e la riga della figlia.
- Nelle figlie del modello ristrutturato va messo l’identificatore (lo stesso del padre), ma non si ripetono gli altri attributi del padre: si ricavano seguendo l’associazione Is... fino alla riga del padre.
Stesso metodo, con un’associazione che resta sul padre: Iscrizione verso CircoloSportivo non si sposta sulle figlie; dopo la ristrutturazione la generalizzazione è sostituita solo da Is_T e Is_C.
| Metodo | Sceglilo quando… | In cambio accetti… |
|---|---|---|
| 1 — Elimina il padre | Copertura totale (obbligo). Meglio se anche esclusiva. Figlie con molti attributi propri. | Associazioni del padre duplicate verso ogni figlia; per elencare tutte le istanze dell’entità padre bisogna leggere le tabelle delle figlie. |
| 2 — Elimina le figlie | Sempre possibile, salvo associazioni che riguardano una sola figlia (in quel caso il Metodo 2 è sbagliato). Meglio se copertura parziale e/o sovrapposta, o figlie senza associazioni proprie. | Molti NULL e un attributo di controllo (tipo, razza). |
| 3 — Associazioni 1:1 | Sempre possibile. Figlie con associazioni proprie da non mescolare; vuoi evitare sia i nulli sia le duplicazioni. | Più tabelle; per rileggere una figlia insieme al padre bisogna collegare più tabelle fra loro. |
Eliminazione dell’associazione ricorsiva (sdoppiamento dell’entità)
Il modello logico non ha il rombo. Un’associazione, lì, è solo una chiave esterna fra due tabelle, oppure una tabella di collegamento.
Un’associazione ricorsiva è un rombo con due ruoli sulla stessa entità. Va quindi sostituita già in ristrutturazione, prima della traduzione. L’entità si disegna due volte, una copia per ruolo: «padre di» e «figlio di» nell’esempio. Non nasce un’entità nuova. Le due copie hanno gli stessi attributi e lo stesso identificatore. Il rombo, tra le due copie, è ormai un’associazione binaria, e le cardinalità sono quelle che prima stavano sui ruoli.
Come questa associazione binaria diventa tabelle e chiavi è il Caso 4 della Regola 2.
Regola 2 — Rappresentazione delle associazioni nel modello logico
Qui il rombo scompare e diventa tabelle e chiavi. I primi tre casi valgono per due entità diverse. Il quarto è l’associazione ricorsiva, che dopo la Regola 1 è già un’associazione fra due copie della stessa entità e quindi si traduce con uno dei primi tre.
Caso 1: Associazione 1:n
Si creano due tabelle, una per entità. L’associazione diventa una chiave esterna messa nella tabella dell’entità che ha il massimo uguale a 1 scritto accanto a sé. Quella è la tabella referenziante.
Esempio — Studente (1,1) — Iscrizione — (1,n) Classe. Accanto a Studente c’è (1,1), quindi ogni studente è collegato al massimo a una classe e la FK nomeClasse va in Studente. Accanto a Classe c’è (1,n): una classe ha molti studenti, e Classe è la tabella referenziata, quella che contiene la PK nomeClasse. Il minimo 1 accanto a Studente dice che la FK ha sempre un valore; se il minimo fosse 0, la FK potrebbe restare vuota.
-- Il modello logico associato al modello E-R soprastante: Studente (Matricola(PK), Nome, Cognome, nomeClasse(FK)) Classe (nomeClasse(PK), numeroAula)
Se l’associazione ha attributi propri, stanno in Studente, prima della FK, che resta l’ultimo attributo.
-- Data è attributo di Iscrizione: sta in Studente, prima della FK Studente (Matricola(PK), Nome, Cognome, Data, nomeClasse(FK)) Classe (nomeClasse(PK), numeroAula)
Caso 2: Associazioni n:n
Si crea una nuova tabella, con il nome dell’associazione. Le due entità restano due tabelle, senza FK aggiunte.
La tabella nuova è formata da:
- la PK, formata dalla coppia delle chiavi primarie delle due entità. Gli attributi dell’associazione non entrano nella PK;
- gli attributi dell’associazione, se ci sono (nell’esempio, Voto e Data);
- Due chiavi esterne che sono le due chiavi primarie delle due entità collegate.
Studente (Matricola(PK), Nome) Esame (IdEsame(PK), Nome) Svolgimento (PK(Matricola, IdEsame), Voto, Data, Matricola(FK), IdEsame(FK))
Caso 3: Associazione 1:1
La scelta dipende dai minimi delle due cardinalità. Tre casi:
Prima strategia — (1,1) da entrambi i lati: una sola tabella. Si fondono le due entità in un’unica tabella con gli attributi di entrambe e una sola chiave primaria. Nessun valore resta mai vuoto: è la soluzione migliore.
-- usando la prima strategia: Persona (CodFiscale(PK), Nome, Cognome, Numero, DataScadenza)
Seconda strategia — (1,1) da un solo lato: per ognuna delle 2 entità una tabella e chiave esterna nella tabella relativa all’entità con cardinalità (1,1).
-- usando la seconda strategia: perché con la prima si avrebbero molte righe con valori nulli Stato (Nome(PK), NumAbitanti) Presidente (PK(Nome, Cognome), NomeStato(FK))
Terza strategia — (0,1) da entrambi i lati: tabella separata. Se da entrambi i lati il legame può mancare, la chiave esterna resterebbe vuota in molte righe, da qualunque parte la si metta. Si crea allora una terza tabella con il nome dell’associazione: la sua chiave primaria è una delle due chiavi esterne. Così le due tabelle restano pulite e solo i legami esistenti occupano una riga.
-- usando la terza strategia (esempio: Docente (0,1) — Tutor — (0,1) Studente): Docente (IdDocente(PK), Nome) Studente (Matricola(PK), Nome) Tutor (IdDocente(PK), IdDocente(FK), Matricola(FK))
Caso 4: Associazione ricorsiva (associazione fra due entità con lo stesso nome)
Dopo la ristrutturazione l’associazione ricorsiva collega due copie della stessa entità, distinte solo dal ruolo. La traduzione ha due momenti, in quest’ordine:
- Le due copie diventano una sola tabella. Hanno gli stessi attributi e lo stesso identificatore, quindi non si creano due tabelle Persona.
- L’associazione si traduce con il caso già visto, scelto dalle cardinalità: Caso 1 se è 1:n, Caso 2 se è n:n, Caso 3 se è 1:1.
La tabella citata dalle FK è la tabella stessa. Nel Caso 1 la FK sta nella tabella unica e punta alla sua PK (auto-referenza). Nel Caso 2 nasce la tabella dell’associazione, con due FK verso quella stessa tabella.
Esempio — Caso 1 (1:n). In anagrafe, Persona ha CodFiscale e Nome, e l’associazione ricorsiva Genitore ha i ruoli «padre di» (0,n) e «figlio di» (0,1). È lo stesso esempio della Regola 1, dove ci sono il modello E-R e il modello ristrutturato. Le due copie sono la stessa entità, quindi la tabella è una sola. Il rombo, tra le copie, è 1:n: la FK va dal lato del ruolo con massimo 1, cioè «figlio di» (ogni persona ha al più un genitore). La colonna si chiama CodPadre perché contiene il codice del padre, e punta a CodFiscale della stessa tabella.
-- Passo 1: sdoppiamento dei ruoli · Passo 3 (Caso 1): FK auto-referenziante Persona (CodFiscale(PK), Nome, CodPadre(FK)) -- CodPadre → Persona.CodFiscale
Due controlli, letti sulle cardinalità dei ruoli. Il ruolo «padre di» ha massimo n: lo stesso padre può comparire su più figli, quindi la FK CodPadre può ripetersi (nel modello fisico non avrà il vincolo di unicità; lo avrebbe solo se anche quel ruolo avesse massimo 1, cioè se l’associazione fosse 1:1). Il minimo 0 del ruolo «figlio di» dice che qualche persona non ha il genitore nel database (il capostipite): per quelle righe CodPadre resta vuoto (nel modello fisico: valore NULL).
Esempio — Caso 2 (n:n). I follower di un social. L’entità è Utente (IdUtente, Nickname). L’associazione ricorsiva Segue ha i ruoli «segue» (0,n) — un utente segue più utenti — e «è seguito da» (0,n) — un utente è seguito da più utenti. Chi segue e chi è seguito sono entrambi utenti: è la stessa entità nei due ruoli.
Le due copie di Utente sono la stessa entità, quindi la tabella degli utenti è una sola, con IdUtente e Nickname. Nessuno dei due ruoli ha massimo 1, quindi nessuna delle due copie può ospitare una sola FK: si applica il Caso 2. Nasce la tabella Segue. La sua PK è la coppia dei due ruoli; le due colonne prendono il nome dal ruolo, IdFollower per «segue» e IdSeguito per «è seguito da»; le stesse due colonne sono ripetute in coda come FK verso Utente. Una riga significa «il primo utente segue il secondo».
-- Passo 3 (Caso 2): tabella dell’associazione, due FK verso la stessa tabella Utente (IdUtente(PK), Nickname) Segue (PK(IdFollower, IdSeguito), IdFollower(FK), IdSeguito(FK)) -- entrambe le FK → Utente.IdUtente
5 Esercizi — Dal modello E-R al modello logico
Regola 1 · Ristrutturazione del modello E-R + Regola 2 · Associazioni nel modello logico
Gli esercizi seguenti sono raggruppati per tipo e, dentro ogni gruppo, disposti in ordine di difficoltà crescente. Per ognuno sono forniti il testo, il modello E-R (disegnato seguendo le convenzioni grafiche del manuale: entità come rettangoli, associazioni come rombi, attributi con pallino, identificatore con pallino pieno, cardinalità come coppie), lo svolgimento commentato e la soluzione in notazione modello logico con PK per le chiavi primarie e FK per le chiavi esterne. Prova a risolvere l’esercizio prima di aprire la soluzione.
| Passo 1 — Ristrutturazione (Regola 1): si elimina ciò che il modello logico non rappresenta | ||
|---|---|---|
| Attributo composto | Scompare come nome unico; restano le sue parti come attributi semplici dell’entità. | Indirizzo → Via, NumeroCivico, Città. |
| Attributo multivalore | Diventa una nuova entità con il proprio identificatore, collegata alla vecchia da un’associazione 1:n. | Telefono multivalore di Dipendente → entità Telefono (Numero). |
| Generalizzazione | Si elimina con uno dei 3 metodi: Metodo 1 (resta solo ogni figlia), Metodo 2 (resta solo il padre + attributo di controllo tipo...), Metodo 3 (padre e figlie collegati da associazioni 1:1 Is...). | Socio → Tennista/Calciatore con Metodo 2 + tipoSocio. |
| Associazione ricorsiva | Si sdoppia l’entità nei suoi due ruoli: si disegna due volte la stessa entità, una per ruolo. Non nasce nessuna entità nuova. | Persona padre di Persona → due copie: ruolo «padre di», ruolo «figlio di». |
| Passo 2 — Traduzione delle entità: ogni entità diventa una tabella | ||
| Entità forte | Una tabella con il nome dell’entità; gli attributi diventano colonne; l’identificatore diventa la chiave primaria (PK). | Studente (Matricola, Nome) → Studente (Matricola(PK), Nome). |
| Entità debole | Una tabella come sopra, ma la PK è composta: prima la chiave dell’entità forte, poi la chiave parziale. Al Passo 2 la debole resta momentaneamente senza PK: la PK si completa al Passo 3 con la FK dell’identificante. | Ricovero debole di Paziente → PK(CodPaziente, NumRicovero). |
| Passo 3 — Traduzione delle associazioni (Regola 2): il rombo scompare, restano tabelle e chiavi esterne (FK) | ||
| Associazione 1:n | Due tabelle; la FK va nella tabella con cardinalità (1,1) o (0,1), cioè dal lato con massimo 1. | Studente (1,1) — Classe (1,n) → FK nomeClasse in Studente. |
| Associazione n:n | Terza tabella col nome dell’associazione; PK = coppia delle PK; due FK, una per entità. | Svolgimento → PK(Matricola, IdEsame) + 2 FK. |
| Associazione 1:1, prima strategia | (1,1) da entrambi i lati: una sola tabella con gli attributi di entrambe e una sola PK. | Persona–Tessera → un’unica tabella. |
| Associazione 1:1, seconda strategia | (1,1) da un solo lato: due tabelle; FK nella tabella con cardinalità (1,1). | Stato (0,1) — Presidente (1,1) → FK NomeStato in Presidente. |
| Associazione 1:1, terza strategia | (0,1) da entrambi i lati: terza tabella col nome dell’associazione; la PK è una delle due FK. | Tutor → Tutor (IdDocente(PK), IdDocente(FK), Matricola(FK)). |
| Associazione identificante | La FK si scrive in coda come in un 1:n normale e, in più, entra a far parte della PK composta dell’entità debole (chiave del forte per prima). Non nasce nessuna tabella aggiuntiva. | Via debole di Città → Via (PK(CAP, nome), lunghezza, CAP(FK)). |
| Associazione ricorsiva | Le due copie diventano una sola tabella; l’associazione si traduce col caso 1:n, n:n o 1:1 secondo le cardinalità dei ruoli. | CodPadre(FK) in Persona; Segue(PK(IdFollower, IdSeguito)). |
Gruppo 1 — Associazioni fra due entità (Regola 2)
Nessuna ristrutturazione: si applica solo la Regola 2 (Casi 1, 2 e 3): due tabelle e la chiave esterna dal lato con massimo 1.
Esercizio 1 — Associazione 1:n Facile
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): niente da eliminare: non ci sono attributi composti, multivalore né generalizzazioni. Il modello è già ristrutturato.
Passo 2 — Traduzione delle entità: ogni entità diventa una tabella (ancora senza le FK delle associazioni, che si aggiungono al Passo 3):
-- Passo 2: tabelle delle entità, senza FK da associazioni Paziente (Codice(PK), Nome, Cognome) Referto (Numero(PK), Data)
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): nel modello logico l’associazione Riferito 1:n viene rappresentata con una FK aggiunta nella tabella referenziante Referto. Accanto a Referto c’è (1,1): ogni referto punta a un solo paziente, quindi la FK sta in Referto. Il minimo 1 della stessa coppia dice che la FK ha sempre un valore e non può restare vuota.
-- Passo 1: nulla da ristrutturare; Passo 2: 2 tabelle; Passo 3: 1:n → FK in Referto Paziente (Codice(PK), Nome, Cognome) Referto (Numero(PK), Data, codPaziente(FK))
Esercizio 2 — Associazione 1:n con attributo dell’associazione Facile
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): niente da eliminare: nessun composto, multivalore o generalizzazione. Il modello è già ristrutturato.
Passo 2 — Traduzione delle entità: Libro e Copia diventano tabelle (ancora senza FK né attributi di associazione):
-- Passo 2: senza FK da associazioni Libro (ISBN(PK), Titolo) Copia (Inventario(PK))
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): nel modello logico l’associazione Appartenenza 1:n viene rappresentata con una FK aggiunta nella tabella referenziante Copia ((1,1) verso Libro); l’attributo dell’associazione Condizione viene rappresentato nella stessa tabella, prima della FK (che resta l’ultimo attributo).
-- Passo 1: nulla da ristrutturare; Passo 3: 1:n → FK + attributo in Copia Libro (ISBN(PK), Titolo) Copia (Inventario(PK), Condizione, ISBN(FK))
Esercizio 3 — Associazione n:n Medio
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): niente da eliminare. Il modello è già ristrutturato.
Passo 2 — Traduzione delle entità: Utente e Film diventano tabelle (la tabella dell’associazione nasce solo al Passo 3):
-- Passo 2: senza tabella Guarda Utente (IdUtente(PK), Username) Film (IdFilm(PK), Titolo)
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): nel modello logico l’associazione Guarda n:n viene rappresentata con una nuova tabella col nome dell’associazione, con PK formata dalla coppia delle PK (che sono anche due FK) più l’attributo Data. Una sola FK non basterebbe perché un utente guarda molti film e viceversa.
-- Passo 3: n:n → nuova tabella con PK(IdUtente, IdFilm) Utente (IdUtente(PK), Username) Film (IdFilm(PK), Titolo) Guarda (PK(IdUtente, IdFilm), Data, IdUtente(FK), IdFilm(FK))
Esercizio 4 — Associazione 1:1 Medio
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): niente da eliminare. Il modello è già ristrutturato.
Passo 2 — Traduzione delle entità: Persona e Patente diventano tabelle (ancora senza la FK di Rilascio):
-- Passo 2: senza FK di Rilascio Persona (CodFiscale(PK), Nome, Cognome) Patente (Numero(PK), DataScadenza)
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): Rilascio è 1:1 ed è seconda strategia — (1,1) da un solo lato: accanto a Persona c’è (0,1), accanto a Patente c’è (1,1). Si tengono due tabelle e la FK va nella tabella con cardinalità (1,1), cioè Patente (ogni patente ha sempre una persona; molte persone non hanno patente).
-- Passo 3: 1:1 seconda strategia → FK in Patente (cardinalità (1,1)) Persona (CodFiscale(PK), Nome, Cognome) Patente (Numero(PK), DataScadenza, codFiscale(FK))
Gruppo 2 — Attributo multivalore (Regola 1)
Prima si trasforma l'attributo in entità con la Regola 1, poi si traduce la 1:n come nel Gruppo 1.
Esercizio 5 — Attributo multivalore (Regola 1) Medio
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): si elimina l’attributo multivalore telefono (1,n) trasformandolo nell’entità Telefono (PK Numero) collegata a Dipendente dall’associazione 1:n Possiede ((1,n) verso Dipendente, (1,1) verso Telefono).
Passo 2 — Traduzione delle entità: le entità ristrutturate diventano tabelle (ancora senza la FK di Possiede):
-- Passo 2: senza FK di Possiede Dipendente (Matricola(PK), Nome, Cognome) Telefono (Numero(PK))
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): l’associazione Possiede è 1:n, quindi la FK va nella tabella che ha massimo 1 accanto a sé, cioè Telefono. Rendere quella FK obbligatoria direbbe solo che ogni telefono appartiene a un dipendente. Il vincolo «ogni dipendente ha almeno un telefono» sta sull’altro lato, accanto a Dipendente, e si controlla a parte, con una procedura.
-- Passo 1: multivalore → entità Telefono + Possiede 1:n; Passo 3: 1:n → FK in Telefono Dipendente (Matricola(PK), Nome, Cognome) Telefono (Numero(PK), matricola(FK))
Gruppo 3 — Entità debole e associazione identificante
La FK dell'identificante si scrive in coda e entra nella PK composta: chiave del forte + chiave parziale.
Esercizio 6 — Entità debole Medio-alto
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): niente da eliminare (l’entità debole non si elimina con la Regola 1). Via resta debole con chiave parziale nome.
Passo 2 — Traduzione delle entità: le entità diventano tabelle (la debole Via è ancora senza la FK identificante, che completa la PK solo al Passo 3):
-- Passo 2: Via senza FK di Contiene (PK incompleta) Città (CAP(PK), nome) Via (nome, lunghezza)
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): nel modello logico l’associazione identificante Contiene 1:n viene rappresentata con la FK aggiunta CAP in Via: la PK diventa così PK(CAP, nome) = PK forte + chiave parziale. Non serve una tabella in più.
-- Passo 2: debole → PK(CAP, nome); Passo 3: Contiene già nella FK Città (CAP(PK), nome) Via (PK(CAP, nome), lunghezza, CAP(FK))
Gruppo 4 — Generalizzazione: la scelta del metodo
Per ogni generalizzazione scegli il Metodo 1, 2 o 3, motiva la scelta in una riga, poi ristruttura e traduci.
Esercizio 7 — Generalizzazione (Regola 1) Medio-alto
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): l’ipotesi «solo cani e gatti, mai entrambi» dà copertura totale ed esclusiva (t,e) → Metodo 1, eliminazione del padre Animale. Gli attributi comuni (codice, nome, razza) vengono ripetuti nelle figlie con identificatori rinominati (CodiceC, CodiceG); l’associazione Riceve viene duplicata in RiceveC e RiceveG. Il Metodo 2 mescolerebbe in una sola tabella pesoMedio e coloreOcchi (tanti nulli) e costringerebbe a un attributo di controllo accanto a Razza.
Passo 2 — Traduzione delle entità: Opera, Copia e Utente diventano tabelle (Copia è debole, quindi la sua PK nasce al Passo 3 incrociando la chiave dell’opera con la chiave parziale):
-- Passo 2: padre con tipoOpera, copia debole, utente Opera (Codice(PK), Titolo, Anno, NumPagine, Genere, Periodicita, Editore, tipoOpera) Utente (Tessera(PK), Nome) Copia (Inventario, Stato)
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): l’associazione identificante Raccoglie completa la PK di Copia: PK(Codice, Inventario). L’associazione Prende è n:n: nasce un’unica tabella con PK(Tessera, Codice, Inventario); la chiave esterna verso la copia è composta (il solo Inventario non la identifica).
-- Passo 1: Metodo 2 (identificante sul padre) → una sola Opera, una sola Copia; Passo 3: identificante in PK, una sola n:n Opera (Codice(PK), Titolo, Anno, NumPagine, Genere, Periodicita, Editore, tipoOpera) Utente (Tessera(PK), Nome) Copia (PK(Codice, Inventario), Stato, Codice(FK)) Prende (PK(Tessera, Codice, Inventario), Tessera(FK), FK(Codice, Inventario))
Esercizio 8 — Generalizzazione: meglio il Metodo 2 Medio-alto
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): la copertura è (p,e), quindi il Metodo 1 è vietato: eliminando Socio si perderebbero i soci che praticano solo la palestra. Il Metodo 3 sarebbe lecito ma inutile, perché Tennista e Nuotatore non hanno associazioni proprie da conservare. Le figlie hanno pochissimi attributi specifici (ranking, stile) e i soci «solo palestra» restano nel padre: la scelta guidata è il Metodo 2, figlie incorporate in Socio con l’attributo di controllo TipoFiglia.
Passo 2 — Traduzione delle entità: le due entità diventano tabelle:
-- Passo 2: tabelle delle entità Istruttore (Codice(PK), Nome, Qualifica) Socio (Tessera(PK), Nome, Cognome, Ranking, Stile, TipoFiglia)
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): l’associazione Allena 1:n mette la FK in Socio, la tabella dal lato con massimo 1 (accanto a Socio c’è (1,1)). La generalizzazione non produce altre tabelle.
-- Passo 1: Metodo 2 (p,e, figlie povere) → una sola tabella per i soci; Passo 3: 1:n → FK in Socio Istruttore (Codice(PK), Nome, Qualifica) Socio (Tessera(PK), Nome, Cognome, Ranking, Stile, TipoFiglia, Codice(FK))
Esercizio 9 — Generalizzazione con associazione identificante (Metodo 2) Medio-alto
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): la copertura è totale ed esclusiva (t,e), quindi ogni opera è un libro o una rivista e nessuna è entrambe. Il più semplice è il Metodo 2: resta la sola entità Opera con tutti gli attributi (NumPagine, Genere, Periodicita, Editore) e con l’attributo di controllo tipoOpera (libro oppure rivista); Copia resta un’unica entità debole di Opera. Il Metodo 1 sarebbe lecito, ma costringerebbe a sdoppiare Copia e a duplicare Raccoglie e Prende. Il Metodo 3 sarebbe corretto (vedi la nota qui sotto), ma con due tabelle in più per le figlie.
Passo 2 — Traduzione delle entità: Opera, Copia e Utente diventano tabelle (Copia è debole, quindi la sua PK nasce al Passo 3 incrociando la chiave dell’opera con la chiave parziale):
-- Passo 2: padre con tipoOpera, copia debole, utente Opera (Codice(PK), Titolo, Anno, NumPagine, Genere, Periodicita, Editore, tipoOpera) Utente (Tessera(PK), Nome) Copia (Inventario, Stato)
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): l’associazione identificante Raccoglie completa la PK di Copia: PK(Codice, Inventario). L’associazione Prende è n:n: nasce un’unica tabella con PK(Tessera, Codice, Inventario); la chiave esterna verso la copia è composta (il solo Inventario non la identifica).
-- Passo 1: Metodo 2 (identificante sul padre) → una sola Opera, una sola Copia; Passo 3: identificante in PK, una sola n:n Opera (Codice(PK), Titolo, Anno, NumPagine, Genere, Periodicita, Editore, tipoOpera) Utente (Tessera(PK), Nome) Copia (PK(Codice, Inventario), Stato, Codice(FK)) Prende (PK(Tessera, Codice, Inventario), Tessera(FK), FK(Codice, Inventario))
Esercizio 10 — Generalizzazione: meglio il Metodo 3 Difficile
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): la copertura è (p,e), quindi il Metodo 1 è vietato (perderesti i furgoni). Il Metodo 2 è sbagliato: porterebbe in Mezzo l’associazione Noleggio, che riguarda solo le autovetture (un furgone non può essere noleggiato, un motociclo nemmeno). La scelta guidata è il Metodo 3: Mezzo resta, e ogni figlia ha come PK la PK del padre, che è anche FK verso il padre.
Passo 2 — Traduzione delle entità: il padre e le due figlie diventano tre tabelle; le figlie hanno come chiave primaria la chiave del padre, che è anche chiave esterna:
-- Passo 2: padre + figlie con PK = FK verso il padre Mezzo (Targa(PK), Marca, Modello) Autovettura (Targa(PK), NumPosti, Targa(FK)) Motociclo (Targa(PK), Cilindrata, Targa(FK)) Cliente (PartitaIVA(PK), RagioneSociale)
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): le due 1:1 sono già rappresentate dalla PK-FK delle figlie. L’associazione Noleggio è n:n fra Cliente e Autovettura: nasce una nuova tabella con PK = coppia delle PK (che sono anche due FK).
-- Passo 1: Metodo 3 (figlia con associazione propria); Passo 3: n:n → nuova tabella Mezzo (Targa(PK), Marca, Modello) Autovettura (Targa(PK), NumPosti, Targa(FK)) Motociclo (Targa(PK), Cilindrata, Targa(FK)) Cliente (PartitaIVA(PK), RagioneSociale) Noleggio (PK(PartitaIVA, Targa), PartitaIVA(FK), Targa(FK))
Gruppo 5 — Associazioni ricorsive
L'entità ricorsiva si sdoppia nei due ruoli (Regola 1), poi il rombo si traduce con i Casi del Gruppo 1 (Regola 2).
Esercizio 11 — Associazione ricorsiva 1:n (Regola 1 + Regola 2) Medio-alto
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): l’entità ricorsiva va sostituita: il modello logico non ha il rombo ricorsivo, quindi Dipendente si sdoppia nei due ruoli, cioè si disegna due volte la stessa entità, una col ruolo «capo di» e una col ruolo «dipende da» (stessi attributi, stesso identificatore Matricola; non nasce nessuna entità nuova). Coordina diventa un’associazione binaria 1:n ((0,n) verso il ruolo «capo di», (0,1) verso il ruolo «dipende da»).
Passo 2 — Traduzione delle entità: i due ruoli hanno gli stessi attributi e lo stesso identificatore, quindi non diventano due tabelle: sono una sola tabella (il raddoppio della tabella duplicherebbe ogni dipendente e servirebbe un collegamento in più per risalire al capo).
-- Passo 2: i due ruoli coincidono → una sola tabella Dipendente (Matricola(PK), Nome, Cognome)
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): Coordina è ormai un’associazione binaria 1:n: la FK va nel ruolo con massimo 1 («dipende da»), cioè in Dipendente. Non esiste una seconda tabella verso cui puntare, quindi la FK punta alla PK della stessa tabella (FK auto-referenziante).
-- Passo 1: sdoppiamento dei ruoli; Passo 3: 1:n → FK auto-referenziante Dipendente (Matricola(PK), Nome, Cognome, MatricolaCapo(FK)) -- MatricolaCapo → Dipendente.Matricola
Esercizio 12 — Associazione ricorsiva n:n Difficile
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): l’entità ricorsiva Insegnamento si sdoppia nei due ruoli: si disegna due volte la stessa entità, una col ruolo «precede» e una col ruolo «segue» (stessi attributi, stesso identificatore Codice; non nasce nessuna entità nuova), e Propedeuticità diventa un’associazione binaria n:n. I nomi dei ruoli serviranno solo a nominare le due colonne della tabella dell’associazione (CodicePrecedente, CodiceSuccessivo).
Passo 2 — Traduzione delle entità: i due ruoli sono due viste della stessa entità: la tabella è una sola, quella dell’entità Insegnamento.
-- Passo 2: i due ruoli sono due viste della stessa entità → una sola tabella Insegnamento (Codice(PK), Denominazione)
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): l’associazione è n:n, quindi serve una nuova tabella (Caso 2) con PK formata dalla coppia dei ruoli e con due FK che puntano entrambe alla stessa tabella, una per ruolo.
-- Passo 3: n:n → nuova tabella, PK coppia dei ruoli, due FK sulla stessa tabella Insegnamento (Codice(PK), Denominazione) Propedeuticita (PK(CodicePrecedente, CodiceSuccessivo), CodicePrecedente(FK), CodiceSuccessivo(FK)) -- entrambe le FK → Insegnamento.Codice
Gruppo 6 — Associazione ternaria (approfondimento)
Costrutto fuori programma per l'ITT: la ternaria si riconduce al Caso 2 con la PK formata dalle tre chiavi.
Esercizio 13 — Caso complesso: associazione ternaria + attributo multivalore Difficile
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): si elimina il multivalore telefono (1,n) trasformandolo nell’entità Telefono collegata a Dipartimento dall’associazione 1:n Possiede.
Passo 2 — Traduzione delle entità: le entità ristrutturate diventano tabelle (ancora senza FK da associazioni; le tabelle Fornitura e Possiede non esistono ancora):
-- Passo 2: senza FK, senza Fornitura Dipartimento (NomeDip(PK), Piano) Prodotto (IdProdotto(PK), Descrizione) Venditore (PIVA(PK), RagioneSociale) Telefono (Numero(PK))
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): nel modello logico l’associazione ternaria Fornitura viene rappresentata con una nuova tabella con PK formata dalla terna delle PK più Quantita; l’associazione Possiede 1:n viene rappresentata con una FK aggiunta in Telefono.
-- Passo 1: telefono → Telefono + Possiede; Passo 3: ternaria → nuova tabella terna Dipartimento (NomeDip(PK), Piano) Prodotto (IdProdotto(PK), Descrizione) Venditore (PIVA(PK), RagioneSociale) Fornitura (PK(NomeDip, IdProdotto, PIVA), Quantita, NomeDip(FK), IdProdotto(FK), PIVA(FK)) Telefono (Numero(PK), nomeDip(FK))
Gruppo 7 — Esercizi riepilogativi: più costrutti insieme
Regola 1 e Regola 2 nello stesso esercizio, come in una verifica completa.
Esercizio 14 — Attributo composto, multivalore, 1:n e n:n insieme Difficile
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): Indirizzo composto → colonne Via, NumeroCivico, Citta; telefono multivalore (1,n) → entità Telefono + associazione 1:n Possiede. Nessuna generalizzazione.
Passo 2 — Traduzione delle entità: le entità ristrutturate diventano tabelle (ancora senza FK; le tabelle Sostiene e le FK di Tiene/Possiede nascono al Passo 3):
-- Passo 2: senza FK, senza Sostiene Studente (Matricola(PK), Nome, Cognome, Via, NumeroCivico, Citta) Telefono (Numero(PK)) Docente (IdDocente(PK), Nome) Corso (IdCorso(PK), Titolo)
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): nel modello logico Tiene 1:n viene rappresentata con una FK aggiunta idDocente in Corso; Sostiene n:n viene rappresentata con una nuova tabella con PK(Matricola, IdCorso) più Voto, Data; Possiede 1:n viene rappresentata con FK aggiunta in Telefono.
-- Passo 1: composto → colonne, multivalore → Telefono; Passo 3: 1:n → FK, n:n → nuova tabella Studente (Matricola(PK), Nome, Cognome, Via, NumeroCivico, Citta) Telefono (Numero(PK), matricola(FK)) Docente (IdDocente(PK), Nome) Corso (IdCorso(PK), Titolo, idDocente(FK)) Sostiene (PK(Matricola, IdCorso), Voto, Data, Matricola(FK), IdCorso(FK))
Esercizio 15 — Generalizzazione, entità debole, composito e 1:n insieme Molto difficile
Mostra svolgimento e soluzione
Passo 1 — Ristrutturazione (applicando la Regola 1): Indirizzo composto → colonne Via, NumeroCivico, Citta; generalizzazione Personale con copertura (p,e) → il Metodo 1 è vietato (perderesti tecnici e amministrativi, che stanno solo nel padre). Resta da scegliere tra Metodo 2 e Metodo 3, ma vale la regola della teoria: il Metodo 2 non si può usare quando un’associazione riguarda una sola figlia — e qui Segue riguarda solo Medico. Si applica quindi il Metodo 3: Personale resta, Medico e Infermiere hanno PK = FK verso il padre e Segue resta collegata a Medico. Ricovero resta debole.
Passo 2 — Traduzione delle entità: le entità ristrutturate diventano tabelle (la debole Ricovero è ancora senza le FK identificante e di Segue, che completano la tabella al Passo 3):
-- Passo 2: senza FK di Effettua/Segue Paziente (CodSanitario(PK), Nome, Cognome, Via, NumeroCivico, Citta) Personale (CF(PK), Nome, Cognome, Telefono) Medico (CF(PK), Specializzazione, CF(FK)) Infermiere (CF(PK), Piano, CF(FK)) Ricovero (NumRicovero, DataIngresso, DataDimissione)
Passo 3 — Traduzione delle associazioni (applicando la Regola 2): nel modello logico l’associazione identificante Effettua viene rappresentata con la FK aggiunta CodPaziente in Ricovero (la PK diventa PK(CodPaziente, NumRicovero): il numero da solo non basta, perché due pazienti possono avere entrambi il ricovero n. 1); l’associazione Segue 1:n viene rappresentata con una FK aggiunta CFMedico in Ricovero, che punta a Medico.CF e non a Personale: solo i medici possono seguire un ricovero.
-- Passo 1: composto → colonne, Metodo 3; Passo 3: Effettua in PK, Segue → FK verso Medico Paziente (CodSanitario(PK), Nome, Cognome, Via, NumeroCivico, Citta) Personale (CF(PK), Nome, Cognome, Telefono) Medico (CF(PK), Specializzazione, CF(FK)) Infermiere (CF(PK), Piano, CF(FK)) Ricovero (PK(CodPaziente, NumRicovero), DataIngresso, DataDimissione, CodPaziente(FK), CFMedico(FK))