0Pricing
SQL Interview Prep · Lezione

Modellazione ER e cardinalità delle relazioni

Traduzione dei requisiti in entità, relazioni e tabelle di giunzione.

Modellazione ER e cardinalità delle relazioni è una lezione SQL Interview Prep gratuita su CoddyKit. Questa è la lezione 2 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento SQL Interview Prep, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso SQL Interview Prep include 4 lezioni in totale.

Perché la modellazione ER compare nei colloqui

Dopo la normalizzazione, gli intervistatori verificano se sa trasformare i requisiti in uno schema. La traccia è solitamente aperta: "Progetti un database per un’app di ride-sharing" oppure "Modelli un sistema bibliotecario".

Si tratta di un esercizio di modellazione entità-relazioni (ER). Gli intervistatori osservano come individua entità, attributi e relazioni tra loro, inclusa la cardinalità.

La competenza consiste nel trasformare i sostantivi e i verbi del linguaggio naturale in tabelle e chiavi esterne.

Entità, attributi e relazioni

Ogni modello ER si basa su tre elementi fondamentali:

  • Entità: un elemento di cui si memorizzano i dati (Cliente, Ordine, Prodotto). Di solito diventa una tabella.
  • Attributo: una proprietà di un’entità (nome, prezzo, created_at). Di solito diventa una colonna.
  • Relazione: il modo in cui le entità sono collegate (un Cliente effettua un Ordine). Viene implementata con chiavi esterne o tabelle di giunzione.

Un suggerimento per interpretare la traccia: i sostantivi diventano entità o attributi, i verbi diventano relazioni.

Cardinalità: il concetto fondamentale

La cardinalità descrive quante istanze di un’entità sono associate a un’altra. Le tre categorie sono:

  • Uno a uno (1:1): una riga da una parte corrisponde al massimo a una riga dall’altra.
  • Uno a molti (1:N): una riga da una parte corrisponde a molte righe dall’altra (è il caso più comune).
  • Molti a molti (M:N): le righe di entrambe le parti corrispondono a molte righe dell’altra parte.

Determinare correttamente la cardinalità stabilisce dove collocare le chiavi esterne e se sia necessaria una tabella di giunzione.

Implementare una relazione uno a molti

Una relazione uno a molti si implementa collocando la chiave esterna sul lato "molti". Un cliente ha molti ordini, quindi ogni riga dell’ordine contiene customer_id.

Durante un colloquio, indichi sempre esplicitamente la direzione: "Da un cliente a molti ordini, quindi la FK si trova in orders."

CREATE TABLE customers (
  customer_id INT PRIMARY KEY,
  name        VARCHAR(100)
);

CREATE TABLE orders (
  order_id    INT PRIMARY KEY,
  customer_id INT NOT NULL,
  order_date  DATE,
  FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

Implementare una relazione molti a molti

Un database relazionale non può memorizzare direttamente una relazione M:N. La soluzione che gli intervistatori si aspettano è una tabella di giunzione (chiamata anche tabella ponte, di collegamento o associativa).

Gli studenti si iscrivono a molti corsi e ogni corso ha molti studenti. Crei una tabella enrollments la cui chiave combina entrambe le chiavi esterne. In questo modo la relazione M:N viene risolta in due relazioni 1:N.

CREATE TABLE students (
  student_id INT PRIMARY KEY,
  name       VARCHAR(100)
);

CREATE TABLE courses (
  course_id  INT PRIMARY KEY,
  title      VARCHAR(100)
);

CREATE TABLE enrollments (
  student_id INT,
  course_id  INT,
  enrolled_at DATE,
  PRIMARY KEY (student_id, course_id),
  FOREIGN KEY (student_id) REFERENCES students(student_id),
  FOREIGN KEY (course_id)  REFERENCES courses(course_id)
);

La tabella di giunzione può contenere dati

Una domanda frequente è: "Dove si memorizza il voto ottenuto da uno studente in un corso?"

Il voto appartiene alla relazione, non allo studente o al corso considerati singolarmente. Perciò va inserito nella tabella di giunzione. È proprio questo il concetto che gli intervistatori vogliono verificare: gli attributi di una relazione M:N risiedono nella tabella ponte.

Esempi: data di iscrizione, voto, quantità in una riga d’ordine, ruolo nell’appartenenza a un progetto.

ALTER TABLE enrollments
  ADD COLUMN grade CHAR(2);
-- grade describes THIS student in THIS course,
-- so it belongs on the junction table

Implementare una relazione uno a uno

Le relazioni 1:1 sono meno comuni. Si implementano assegnando alla tabella dipendente una chiave esterna che sia anche una chiave univoca (spesso la chiave primaria stessa).

Ad esempio, si possono avere un user e un user_profile con dettagli estesi e facoltativi. Rendere user_id la chiave primaria della tabella dei profili impone al massimo un profilo per utente.

CREATE TABLE users (
  user_id INT PRIMARY KEY,
  email   VARCHAR(255)
);

CREATE TABLE user_profiles (
  user_id INT PRIMARY KEY,           -- 1:1 enforced here
  bio     TEXT,
  avatar_url VARCHAR(255),
  FOREIGN KEY (user_id) REFERENCES users(user_id)
);

Opzionalità e partecipazione

La cardinalità ha una seconda dimensione molto importante nei colloqui: l’opzionalità (chiamata anche partecipazione).

  • Obbligatoria: ogni ordine deve avere un cliente, quindi customer_id è NOT NULL.
  • Facoltativa: un utente può avere o non avere un profilo, quindi la relazione può essere assente.

La partecipazione obbligatoria si esprime con NOT NULL sulla chiave esterna. Menzionare la possibilità di NULL dimostra che considera i vincoli reali, non solo le strutture.

Relazioni autoriferenti

Alcune relazioni collegano un’entità a sé stessa. Un dipendente ha un responsabile che è anch’esso un dipendente; una categoria ha una categoria padre.

Si modella questa situazione con una chiave esterna che fa riferimento alla stessa tabella. Gli intervistatori se lo aspettano per gli organigrammi e le strutture ad albero, e questa soluzione si abbina naturalmente ai self-join e alle CTE ricorsive.

CREATE TABLE employees (
  employee_id INT PRIMARY KEY,
  name        VARCHAR(100),
  manager_id  INT NULL,
  FOREIGN KEY (manager_id) REFERENCES employees(employee_id)
);
-- manager_id NULL = top of the hierarchy (e.g. CEO)

Un breve esempio di modellazione

Si eserciti con il metodo verbo-relazione. Traccia: "I clienti effettuano ordini; ogni ordine contiene molti prodotti; i prodotti appartengono ai fornitori."

  • Cliente 1:N Ordine (FK customer_id in orders).
  • Ordine M:N Prodotto -> tabella di giunzione order_items (con quantity).
  • Fornitore 1:N Prodotto (FK supplier_id in products).

Indichi ogni cardinalità e dove viene collocata la chiave. È proprio questa spiegazione a fare la differenza nel colloquio.

Domande di chiarimento da porre

Gli intervistatori apprezzano i candidati che fanno domande prima di progettare. Ecco alcune buone domande di chiarimento:

  • "Un prodotto può appartenere a più di un fornitore?" (determina 1:N o M:N).
  • "Ogni ordine deve contenere almeno un articolo?" (partecipazione).
  • "Ci serve la cronologia o solo lo stato attuale?" (determina la necessità di tabelle aggiuntive).

Le risposte modificano la cardinalità e il numero di tabelle, quindi non dia nulla per scontato. Fare domande è un segnale di seniority.

Verifica rapida

Sta modellando studenti e corsi, dove ogni studente può frequentare molti corsi e ogni corso può avere molti studenti.

Riepilogo: modellazione ER e cardinalità

Ora è in grado di affrontare una domanda aperta sulla progettazione di uno schema:

  • Trasformi i sostantivi in entità/attributi e i verbi in relazioni.
  • 1:N: chiave esterna sul lato molti.
  • M:N: tabella di giunzione contenente entrambe le chiavi esterne, oltre agli eventuali attributi della relazione.
  • 1:1: chiave condivisa/univoca nella tabella dipendente.
  • Usi NOT NULL per esprimere la partecipazione obbligatoria e chiavi esterne autoriferite per le gerarchie.
  • Ponga domande di chiarimento prima di stabilire la cardinalità.

Domande Frequenti

La lezione «Modellazione ER e cardinalità delle relazioni» è gratuita?

Sì — il testo completo di «Modellazione ER e cardinalità delle relazioni» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso SQL Interview Prep, passa a CoddyKit PRO. Il corso SQL Interview Prep include 4 lezioni in totale.

Cosa imparerò in «Modellazione ER e cardinalità delle relazioni»?

Traduzione dei requisiti in entità, relazioni e tabelle di giunzione. Eserciti SQL Interview Prep con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare SQL Interview Prep?

Non è richiesta alcuna esperienza precedente. SQL Interview Prep su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 2 di 4.

Quanto tempo richiede la lezione «Modellazione ER e cardinalità delle relazioni»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione SQL Interview Prep?

Sì. Ogni lezione SQL Interview Prep include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Normalizzazione fino alla 3NF
  2. Modellazione ER e cardinalità delle relazioni
  3. Schema a stella e progettazione del data warehouse
  4. Serie completa di problemi per una simulazione di colloquio
← Torna a SQL Interview Prep