Dal concetto all’implementazione — i tre livelli di progettazione
Nella lezione precedente abbiamo visto cos’è un database e perché i DBMS hanno rivoluzionato la gestione dei dati. In questa lezione affrontiamo la progettazione: come si passa da un problema reale a uno schema di database funzionante e corretto.
La progettazione di una base di dati non avviene in un unico passo. Si articola in tre livelli progressivi, ognuno con il proprio linguaggio e il proprio scopo:
LIVELLO CONCETTUALE — Schema E/R
Rappresenta la realtà di interesse in modo indipendente da qualsiasi tecnologia. Usa entità, attributi e relazioni. È il linguaggio del progettista e dell’utente.
↓
LIVELLO LOGICO — Schema Relazionale
Traduce il modello E/R in tabelle, colonne e chiavi secondo le regole del modello relazionale. Indipendente dal DBMS specifico, ma già vicino all’implementazione.
↓
LIVELLO FISICO — Implementazione SQL
Crea effettivamente le tabelle nel DBMS scelto (MySQL, PostgreSQL, SQLite…). Dipende dal sistema specifico, dai tipi di dato disponibili e dalle ottimizzazioni.
In questa lezione ci concentriamo sui primi due livelli. Il livello fisico (SQL) sarà il tema del Modulo 3.
Il Modello Relazionale
Il modello relazionale è stato proposto da Edgar F. Codd nel 1970 nel paper “A Relational Model of Data for Large Shared Data Banks”. È il modello teorico alla base di tutti i database SQL — MySQL, PostgreSQL, Oracle, SQL Server. L’idea centrale è rivoluzionariamente semplice: tutti i dati sono rappresentati come tabelle, e le relazioni tra dati diversi vengono espresse tramite valori condivisi nelle tabelle, non tramite puntatori fisici.
Terminologia fondamentale
Il lessico del modello relazionale — termini formali e corrispondenti pratici
Termine formale
Equivalente pratico
Definizione
Relazione
Tabella
Insieme di tuple con gli stessi attributi — struttura bidimensionale righe/colonne
Tupla
Riga / Record
Un singolo elemento della relazione — rappresenta un’occorrenza del dato (es. un singolo studente)
Attributo
Colonna / Campo
Una proprietà della relazione con un nome e un dominio di valori ammessi (es. Nome: stringhe)
Dominio
Tipo di dato
L’insieme dei valori ammissibili per un attributo (es. INTEGER, VARCHAR(50), DATE)
Grado
Numero di colonne
Il numero di attributi di una relazione — una tabella con 5 colonne ha grado 5
Visualizziamo concretamente questi concetti con una tabella di esempio:
Un concetto fondamentale nel modello relazionale è la chiave: un attributo (o insieme di attributi) che identifica univocamente ogni tupla nella relazione. Senza chiavi non è possibile distinguere un record da un altro, né collegare tabelle diverse in modo affidabile.
🔑 Chiave Candidata
Un attributo (o combinazione minima) che identifica univocamente ogni tupla. Una relazione può averne più di una.
Es. per STUDENTE: sia Matricola che CodiceFiscale sono chiavi candidate
🗝️ Chiave Primaria (PK)
La chiave candidata scelta dal progettista come identificatore principale. Non può contenere valori NULL e deve essere unica per ogni tupla.
Es: si sceglie Matricola come PK perché è sempre presente e numerica
🔗 Chiave Esterna (FK)
Un attributo che fa riferimento alla chiave primaria di un’altra tabella. Permette di collegare relazioni diverse rispettando l’integrità referenziale.
Es: CodClasse in STUDENTE riferisce la PK di CLASSE
Vincoli di integrità
Il modello relazionale definisce regole precise che i dati devono rispettare. Queste regole si chiamano vincoli di integrità e sono garantite automaticamente dal DBMS:
Integrità di entità
La chiave primaria non può mai contenere valori NULL. Ogni tupla deve essere identificabile in modo univoco — una riga senza identità è priva di significato nel modello relazionale.
Integrità referenziale
Il valore di una chiave esterna deve corrispondere a un valore esistente nella chiave primaria della tabella referenziata — oppure essere NULL. Non possono esistere “riferimenti pendenti” a righe che non esistono.
Vincoli di dominio
Ogni valore di un attributo deve appartenere al dominio dichiarato. Non si può inserire una stringa in un campo INTEGER, né una data futura in un campo che richiede date passate.
📌 Cosa succede quando si viola l’integrità referenziale?
Immagina di avere uno studente con CodClasse = '4AI' e di eliminare la classe ‘4AI’ dalla tabella CLASSE. Lo studente farebbe riferimento a una riga inesistente. Il DBMS impedisce questa situazione automaticamente — l’operazione di cancellazione viene rifiutata, oppure si propaga a cascata (ON DELETE CASCADE) eliminando anche gli studenti di quella classe.
Il Modello Entità/Relazione (E/R)
Il modello Entità/Relazione (Entity-Relationship, proposto da Peter Chen nel 1976) è il linguaggio visuale usato nella progettazione concettuale. Non è direttamente implementabile in un DBMS — è uno strumento di comunicazione tra progettista e committente, un modo per catturare la realtà di interesse in modo preciso prima di sporcarsi le mani con SQL.
I componenti del diagramma E/R
▭ Entità
Rappresenta una classe di oggetti del mondo reale con esistenza autonoma e distinguibile. Si rappresenta con un rettangolo. Il nome è sempre al singolare e in maiuscolo.
✅ Esempi validi: STUDENTE, CORSO, PROFESSORE, PRODOTTO
❌ Non sono entità: “iscrizione” (è una relazione), “nome” (è un attributo)
STUDENTE
◯ Attributi
Le proprietà che descrivono un’entità. Si rappresentano con ellissi collegate all’entità. L’attributo che identifica univocamente ogni occorrenza è la chiave — si sottolinea nel diagramma.
Semplice: un solo valore (Nome, Cognome)
Composto: più sotto-attributi (Indirizzo → Via, Città, CAP)
Multivalore: più valori possibili (NumeriTelefono)
Derivato: calcolabile da altri (Età da DataNascita)
◇ Relazione (Association)
Rappresenta un legame logico tra due o più entità. Si disegna con un rombo collegato alle entità partecipanti. Anche le relazioni possono avere attributi propri.
ISCRIZIONE
collegata tra STUDENTE e CORSO
Entità Debole
Un’entità che non ha chiave propria e dipende da un’entità forte per la propria identificazione. Si rappresenta con un doppio rettangolo. La relazione di dipendenza usa un doppio rombo.
Es: EDIFICIO debole rispetto a UNIVERSITÀ — il numero dell’edificio è unico solo all’interno di un campus specifico
La Cardinalità — quante occorrenze partecipano?
La cardinalità è la specifica più importante di una relazione E/R: indica quante occorrenze di un’entità possono essere associate a occorrenze dell’altra entità. È la regola del gioco del mondo reale che stiamo modellando.
I tre tipi di cardinalità
1:1
uno a uno
Ad ogni occorrenza di A corrisponde al massimo una occorrenza di B, e viceversa.
[PERSONA] ——1—— ◇POSSIEDE◇ ——1—— [PASSAPORTO]
Una persona ha al massimo un passaporto. Un passaporto appartiene a esattamente una persona.
1:N
uno a molti
Ad ogni occorrenza di A corrispondono più occorrenze di B, ma ogni B è associata a una sola A. La cardinalità più comune nei database reali.
[CLASSE] ——1—— ◇CONTIENE◇ ——N—— [STUDENTE]
Una classe contiene molti studenti. Uno studente appartiene a una sola classe.
N:M
molti a molti
Ad ogni occorrenza di A corrispondono più occorrenze di B, e viceversa. Nel modello relazionale si risolve sempre con una tabella di congiunzione.
[STUDENTE] ——N—— ◇FREQUENTA◇ ——M—— [CORSO]
Uno studente frequenta molti corsi. Un corso è frequentato da molti studenti.
Partecipazione obbligatoria e opzionale
Oltre alla cardinalità massima, il diagramma E/R specifica anche la partecipazione minima: un’entità partecipa in modo obbligatorio alla relazione (almeno una volta) o opzionale (può non partecipare)? Si indica con la notazione (min, max):
(1,1) — Obbligatoria esattamente una
L’entità deve partecipare alla relazione con esattamente un’occorrenza. Es: ogni STUDENTE deve appartenere a esattamente una CLASSE.
(0,1) — Opzionale al massimo una
L’entità può o meno partecipare alla relazione. Es: una PERSONA può avere zero o un PASSAPORTO.
(1,N) — Obbligatoria, molte
Deve partecipare almeno una volta, può partecipare molte volte. Es: una CLASSE deve avere almeno uno STUDENTE.
(0,N) — Opzionale, molte
Può non partecipare o partecipare molte volte. Es: un PROFESSORE può essere assegnato a zero o più CORSI.
Un diagramma E/R completo — caso studio: la scuola
Progettiamo insieme un database per gestire la realtà scolastica. Partendo dalle specifiche informali, costruiamo il diagramma E/R passo per passo.
📋 Specifiche informali
La scuola vuole gestire studenti, classi e materie. Ogni studente appartiene a una sola classe. Ogni classe ha un nome (es. “4AI”) e un anno di corso. Ogni materia ha un nome e un monte ore annuale. Un professore insegna una o più materie, ma ogni materia in ogni classe è insegnata da un solo professore. Gli studenti vengono valutati con voti per ciascuna materia.
Schema E/R — Gestione Scolastica
Matricola (PK)
Nome · Cognome
DataNascita
CodClasse (PK)
AnnoCorso
Matricola (PK)
Nome · Cognome
Email
STUDENTE
N
APPART.
1
CLASSE
N
INSEGNA
M
PROF.
N
VALUTA Voto, Data
M
MATERIA
STUDENTE —N— APPARTIENE —1— CLASSE (1:N)
CLASSE —N— INSEGNA —M— PROFESSORE (N:M con MATERIA)
STUDENTE —N— VALUTA —M— MATERIA (N:M con attributo Voto)
La relazione VALUTA ha un attributo proprio: il Voto e la Data della valutazione
Dal modello E/R al modello Relazionale
Una volta completato il diagramma E/R, si applica una serie di regole di traduzione sistematiche per ottenere lo schema relazionale. Ogni componente E/R ha una regola precisa.
Regola 1 — Entità → Tabella
Ogni entità diventa una tabella. Gli attributi dell’entità diventano le colonne. La chiave dell’entità diventa la chiave primaria della tabella.
La chiave primaria dell’entità lato “1” viene inserita come attributo (chiave esterna) nella tabella dell’entità lato “N”. Non si crea una tabella separata per la relazione.
CLASSE —1— APPARTIENE —N— STUDENTE
→ STUDENTE(Matricola, Nome, Cognome, CodClasse_FK)
Regola 3 — Relazione N:M → Tabella di giunzione
Si crea una nuova tabella con la chiave primaria composta dalle chiavi esterne delle due entità collegate. Gli eventuali attributi della relazione diventano colonne di questa tabella.
Regola 4 — Relazione 1:1 → Fusione o chiave esterna
Due opzioni: si fondono le due entità in un’unica tabella (se la partecipazione è obbligatoria da entrambi i lati), oppure si aggiunge la FK all’entità con partecipazione opzionale.
PERSONA —1— POSSIEDE —(0,1)— PASSAPORTO
→ PASSAPORTO(NumeroPassaporto, DataScadenza, CodFiscale_FK)
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 il nome come PK. I nomi cambiano, si duplicano e non sono sempre noti. La PK deve essere stabile e sempre presente — preferire matricole o ID numerici autogenerati.
❌ Relazione N:M senza tabella di giunzione
Tentare di gestire una relazione molti-a-molti aggiungendo colonne ripetute. Porta a dati duplicati e anomalie di aggiornamento impossibili da gestire.
❌ Confondere relazione ed entità
Modellare “Iscrizione” come entità quando è una relazione N:M tra STUDENTE e CORSO. Regola pratica: se ha senso da sola senza le due entità che collega, è un’entità; altrimenti è una relazione.
📌 Riepilogo — Punti chiave
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 la consistenza dei dati
Chiave primaria: identifica univocamente ogni tupla, mai NULL. Chiave esterna: riferisce la PK di un’altra tabella, garantisce l’integrità referenziale
Nel diagramma E/R: entità (rettangolo), attributi (ellissi, chiave sottolineata), relazioni (rombo). Le cardinalità 1:1, 1:N, N:M descrivono quante occorrenze partecipano alla relazione
Traduzione E/R → relazionale: ogni entità → tabella; relazione 1:N → FK nel lato N; relazione N:M → nuova tabella di giunzione con PK composta; gli attributi di relazione finiscono nella tabella di giunzione
Questo sito Web utilizza i cookie per migliorare la tua esperienza.Supponiamo che tu stia bene con questo, ma puoi rinunciare se lo desideri.
Read More
I cookie sono piccoli file di testo che possono essere utilizzati dai siti Web per rendere più efficiente l'esperienza dell'utente.La legge afferma che possiamo archiviare i cookie sul tuo dispositivo se sono rigorosamente necessari per il funzionamento di questo sito.Per tutti gli altri tipi di cookie, abbiamo bisogno del tuo permesso.Questo sito utilizza diversi tipi di cookie.Alcuni cookie sono collocati da servizi di terze parti che appaiono nelle nostre pagine.
I cookie necessari aiutano a rendere utilizzabile un sito Web consentendo funzioni di base come la navigazione di pagina e l\'accesso alle aree sicure del sito Web.Il sito Web non può funzionare correttamente senza questi cookie.
I cookie di marketing vengono utilizzati per tenere traccia dei visitatori sui siti Web.L\'intenzione è quella di visualizzare annunci pertinenti e coinvolgenti per il singolo utente e quindi più preziosi per gli editori e gli inserzionisti di terze parti.
I cookie di analisi aiutano i proprietari di siti Web a capire come i visitatori interagiscono con i siti Web raccogliendo e segnalando informazioni in modo anonimo.
I cookie di preferenza consentono a un sito Web di ricordare le informazioni che cambiano il modo in cui il sito Web si comporta o sembra, come la tua lingua preferita o la regione in cui ti trovi.
I cookie non classificati sono cookie che stiamo classificando, insieme ai fornitori di singoli cookie.
Cookie Settings
Gestisci Consenso
Per fornire le migliori esperienze, utilizziamo tecnologie come i cookie per memorizzare e/o accedere alle informazioni del dispositivo. Il consenso a queste tecnologie ci permetterà di elaborare dati come il comportamento di navigazione o ID unici su questo sito. Non acconsentire o ritirare il consenso può influire negativamente su alcune caratteristiche e funzioni.
Funzionale
Sempre attivo
L'archiviazione tecnica o l'accesso sono strettamente necessari al fine legittimo di consentire l'uso di un servizio specifico esplicitamente richiesto dall'abbonato o dall'utente, o al solo scopo di effettuare la trasmissione di una comunicazione su una rete di comunicazione elettronica.
Preferenze
L'archiviazione tecnica o l'accesso sono necessari per lo scopo legittimo di memorizzare le preferenze che non sono richieste dall'abbonato o dall'utente.
Statistiche
L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici.L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici anonimi. Senza un mandato di comparizione, una conformità volontaria da parte del vostro Fornitore di Servizi Internet, o ulteriori registrazioni da parte di terzi, le informazioni memorizzate o recuperate per questo scopo da sole non possono di solito essere utilizzate per l'identificazione.
Marketing
L'archiviazione tecnica o l'accesso sono necessari per creare profili di utenti per inviare pubblicità, o per tracciare l'utente su un sito web o su diversi siti web per scopi di marketing simili.