Dal modello concettuale al modello logico
Dalle associazioni del diagramma E/R a tabelle, chiavi e vincoli: il modello logico con cui lavorano i database relazionali. Prodotto cartesiano, relazioni, chiavi, integrità referenziale e regole di traduzione 1:N e N:M.
Nel modello relazionale una tabella non è un foglio di calcolo: è una relazione, cioè un insieme di tuple che rispetta uno schema e specifici vincoli. Le chiavi fanno sì che i collegamenti fra tabelle restino coerenti.
Nella lezione precedente abbiamo usato il diagramma E/R per capire quali oggetti esistono e quali associazioni li collegano. Ora compiamo un passo diverso: descriviamo quei dati con una struttura precisa, fatta di tabelle. È il modello logico relazionale, proposto da Edgar F. Codd nel 1970.
1. Relazioni tra insiemi
Dati due insiemi A₁ e A₂, il prodotto cartesiano è l’insieme di tutte le coppie ordinate possibili: A₁ × A₂ = { (a₁, a₂) | a₁ ∈ A₁, a₂ ∈ A₂ }. Una relazione R su A₁ e A₂ è un sottoinsieme del prodotto cartesiano: R ⊆ A₁ × A₂. Non tutte le combinazioni hanno senso: la relazione seleziona solo quelle significative.
Esempio didattico: prendiamo A₁ = Città = {Roma, Milano, Torino, Monaco, Berlino}, A₂ = Nazione = {Italia, Germania}. Il prodotto cartesiano contiene 10 coppie. La relazione utile SI_TROVA_IN ⊆ Città × Nazione ne contiene solo 5.
1.2 Dagli insiemi alle tabelle
Nel modello relazionale, prodotto cartesiano e relazione diventano tabelle. La differenza è cruciale: il prodotto cartesiano contiene rumore, la relazione contiene informazione.
Il prodotto cartesiano Città × Nazione genera anche coppie false. Memorizzare il prodotto significherebbe salvare rumore. La relazione SI_TROVA_IN salva solo le 5 coppie vere. |A₁ × A₂| = 5·2 = 10, |R| = 5 ≤ 10, R ⊆ A₁×A₂.
2. Dal modello E/R al modello logico
MODELLO CONCETTUALE: Rappresenta la realtà: LIBRO, AUTORE, scrive. Indipendente dal DBMS.
MODELLO LOGICO RELAZIONALE: Rappresenta dati organizzati: LIBRI, AUTORI, RUOLI, con chiavi e vincoli.
3. Relazioni, tuple, attributi e domini
Una relazione R su domini D₁, D₂, …, Dₙ è un insieme di n-uple. In pratica, ogni colonna prende valori da un proprio dominio e ogni riga è una tupla. R ⊆ D₁ × D₂ × … × Dₙ
4. Proprietà di una relazione
Le tuple sono tutte distinte
Gli attributi hanno nomi distinti
In ogni cella compare un valore atomico del dominio
Nella teoria relazionale classica non si parla di “riga numero 3”: l’ordine non identifica un record. Per identificare una tupla servono le chiavi.
5. Chiavi: come identificare una tupla
| Concetto | Definizione | Esempio in STUDENTI |
|---|---|---|
| Superchiave | Insieme di attributi che identifica univocamente ogni tupla | {matricola}; anche {matricola, nome} |
| Chiave candidata | Superchiave minimale | {matricola}, {codice_fiscale} |
| Chiave primaria (PK) | Una chiave candidata scelta come identificatore principale | matricola |
6. Chiavi esterne e integrità referenziale
Si definisce chiave esterna e si indica con {FK} (Foreign Key) un attributo o un insieme di attributi che identificano univocamente una riga in un’altra tabella.
7. Tradurre un diagramma E/R – le regole di derivazione
La traduzione dal modello concettuale al logico segue regole precise e meccaniche. Imparandole, sai tradurre qualsiasi diagramma ER in uno schema relazionale corretto.
Ogni entità diventa una tabella. ER: Entità STUDENTE {matricola, nome, cognome, data_nascita} → STUDENTE(matricola, nome, cognome, data_nascita)
Ogni attributo di un’entità diventa una colonna della tabella.
L’identificatore univoco dell’entità diventa la chiave primaria (PK) della tabella. ER: STUDENTE {matricola, nome...} → STUDENTE(matricola,...)
Associazione 1:1 diventa un’unica tabella salvo casi in cui si mette FK nella tabella dipendente o che ha più senso semanticamente. Spesso è la tabella che non può esistere senza l’altra. ER: PERSONA (1) —possiede— (1) PASSAPORTO → PERSONA(id_pers, nome) + PASSAPORTO(num_pass, data_rilascio, FK:id_pers)
La PK del lato 1 viene aggiunta come FK nel lato N. ER: DIPARTIMENTO (1) —ha— (N) DIPENDENTE → DIPARTIMENTO(id_dip, nome, sede) + DIPENDENTE(id_dipendente, nome, stipendio, FK:id_dip)
Se entità ha attributo multivalore (es. persona con più telefoni), non si mettono nella stessa riga. Si crea tabella separata. ER: PERSONA con {telefoni} → PERSONA(id_pers, nome) + TELEFONO(id_tel, numero, tipo, FK:id_pers)
Si crea nuova tabella con le FK di entrambe le entità. PK è coppia delle due FK (chiave composta). Attributi di relazione finiscono qui. ER: STUDENTE (N) —frequenta— (M) CORSO [voto_finale] → STUDENTE(matricola...), CORSO(id_corso...), FREQUENTA(FK:matricola, FK:id_corso, voto_finale)
Regole 1-3 = entità: entità→tabella, attributo→colonna, id→PK. Regole 4-7 = associazioni: 1:1 → unica tabella o FK in dipendente, 1:N → FK lato N (la più usata!), multivalore → tabella separata, N:M → tabella giunzione con PK composta. Se ricordate 5 e 7, avete già 80% dei casi reali.
8. Caso studio completo: LIBRO e AUTORE + schema scuola
9. Errori comuni nella progettazione
Attributi multivalore non risolti: Inserire Telefoni: "320-1234567, 348-9876543" in una colonna. Viola la prima forma normale — ogni cella deve contenere un valore atomico.
Chiave primaria su attributo non stabile: Usare nome come PK. I nomi cambiano, si duplicano. PK deve essere stabile e sempre presente — preferire matricole o ID numerici autogenerati.
Relazione N:M senza tabella di giunzione: Tentare di gestire N:M aggiungendo colonne ripetute. Porta a dati duplicati e anomalie di aggiornamento impossibili.
Confondere relazione ed entità: Modellare “Iscrizione” come entità quando è una relazione N:M tra STUDENTE e CORSO. Regola: se ha senso da sola senza le due entità che collega, è entità; altrimenti è relazione.
La progettazione si articola in tre livelli: concettuale (E/R — indipendente dalla tecnologia), logico (schema relazionale — indipendente dal DBMS), fisico (SQL — dipendente dal sistema scelto). Nel modello relazionale: relazione = tabella, tupla = riga, attributo = colonna, dominio = tipo di dato. I vincoli di integrità (entità, referenziale, dominio) garantiscono consistenza. Chiave primaria: identifica univocamente ogni tupla, mai NULL. Chiave esterna: riferisce PK di altra tabella, garantisce integrità referenziale. Nel diagramma E/R: entità (rettangolo), attributi (ellissi, chiave sottolineata), relazioni (rombo). Cardinalità 1:1, 1:N, N:M. Traduzione E/R → relazionale: ogni entità → tabella; 1:N → FK lato N; N:M → nuova tabella di giunzione con PK composta; attributi di relazione finiscono nella tabella di giunzione.
Vuoi passare all'azione? Accedi alla repository ufficiale GitHub del corso per scaricare i file del laboratorio pratico in formato .md.
Vuoi consultare la sezione dedicata ai laboratori sul sito? Accedi cliccando il pulsante qui sotto.
🛠️ Sezione dedicata ai Laboratori📚 Prossimo passo - SQL DDL
Nella prossima lezione traduciamo questo schema logico in SQL vero: CREATE TABLE, PRIMARY KEY, FOREIGN KEY, vincoli CHECK, UNIQUE, NOT NULL. Se le regole 1-7 di oggi sono chiare, scrivere CREATE TABLE sarà meccanico. Portate questo schema scuola: lo creeremo in MySQL.