Modello relazionale

Premessa

Portale di appartenenza: Basi di dati.

Cosa troverai in questa nota:

• Il modello relazionale, dalle origini concettuali di Codd fino ad arrivare alla definizione formale di base di dati.
• I vari tipi di vincoli di integrità, compresi il vincolo locale di chiave primaria e il vincolo globale di integrità referenziale.

Prerequisiti: per comprendere pienamente il contenuto di questa nota, oltre le conoscenze minime che do per scontato che tu sappia già, ti consiglio di aver letto in precedenza queste altre note:

• Basi di dati.

Buona lettura! ☝️🤓

---

Definizione: modello relazionale

Il modello relazionale è un modello logico per l’organizzazione e la gestione dei dati nei database, basato sulla teoria degli insiemi e sulla logica matematica proposto da Edgar F. Codd nel 1970.

I DBMS basati sul modello relazionale vengono detti RDBMS.

Definizione: RDBMS

Il RDBMS (Relational DataBase Management System) è un particolare tipo di DBMS basato sul modello relazionale.

1 - Introduzione di Codd sul modello relazionale

Edgar F. Codd, nel suo articolo scientifico in cui ha introdotto le basi del modello relazionale (e che puoi trovare integralmente qui, o tradotto in italiano qui) pubblicato nel 1970, spiega i motivi che lo hanno portato allo sviluppo di questo modello come alternativa al modello reticolare o al modello a grafo molto diffusi in quel periodo. In particolare, i vantaggi del modello relazionale introdotto da Codd sono:

• Indipendenza (logica e fisica) dei dati: nei modelli precedenti, la struttura fisica dei dati influenzava direttamente il modo in cui essi venivano interrogati e manipolati, mentre nel modello relazionale i dati sono organizzati in tabelle e possono essere modificati senza impattare le applicazioni che li usano.
• Semplicità concettuale: le relazioni sono intuitive e basate su concetti matematici solidi (come la teoria degli insiemi e l’algebra relazionale), mentre i modelli gerarchico e reticolare richiedevano una gestione complessa dei puntatori e dei percorsi di accesso ai dati.
• Eliminazione della ridondanza e maggiore integrità dei dati: il modello relazionale introduce il concetto di normalizzazione che aiuta a ridurre la ridondanza e i problemi di inconsistenza dei dati, mentre nei modelli precedenti la duplicazione dei dati era comune e poteva causare incongruenze.
• Facilità di manutenzione ed evoluzione: l’architettura relazionale permette di modificare la struttura dei dati senza riscrivere il codice delle applicazioni, mentre nei modelli precedenti ogni modifica poteva richiedere una riscrittura significativa del software.

2 - Introduzione alle relazioni e alle tabelle

Il modello relazionale si basa su due concetti fondamentali: relazione e tabella, che, pur essendo diversi nella loro natura, sono strettamente collegati. La relazione deriva dalla matematica, in particolare dalla teoria degli insiemi e dal concetto di relazione $n$-aria, e rappresenta un oggetto matematico definito come un sottoinsieme del prodotto cartesiano di una famiglia di insiemi, ognuno dei quali viene detto dominio del prodotto.

Ad esempio, dati gli insiemi (domini) $A=\{1,2,4\}$ e $B=\{a,b\}$, il prodotto cartesiano $A\times B$ è l’insieme di tutte le coppie possibili in cui il primo elemento appartiene ad $A$ e il secondo a $B$. Poiché $A$ ha tre elementi e $B$ ne ha due, abbiamo sei coppie:

$$\{(1,a),(1,b),(2,a),(2,b),(4,a),(4,b)\}$$

Una tabella, al contempo, è una particolare rappresentazione di una relazione in forma matriciale, in cui ogni riga corrisponde a un elemento della relazione e ogni colonna a un dominio del prodotto. Per esempio, riprendendo la relazione $A\times B=\{1,2,4\}\times \{a,b\}$, una sua rappresentazione tabellare è la seguente:

$$\begin{array}{cc}1& a\\ 1& b\\ 2& a\\ 2& b\\ 4& a\\ 4& b\end{array}$$

Si può notare come ogni riga contenga un elemento (es. nella prima riga c’è l’elemento $(1,a)$, nella seconda $(1,b)$ e così via), mentre in ognuna delle due colonne c’è ognuno dei due domini $A$ e $B$ che compongono il prodotto cartesiano.

2.1 - Relazioni per la rappresentazione di dati

Le relazioni (e le loro corrispondenti tabelle) possono essere usate per rappresentare dati schematicamente.

Per esempio, la seguente tabella contiene i risultati di un insieme di partite di calcio:

$$\begin{array}{cccc}\text{Real Madrid}& \text{Liverpool}& 3& 1\\ \text{Liverpool}& \text{Milan}& 2& 0\\ \text{Torino}& \text{Juventus}& 1& 1\\ \text{Roma}& \text{Milan}& 0& 1\end{array}$$

Ogni riga rappresenta una partita di calcio in cui la squadra nella prima colonna ha segnato il numero di gol nella terza colonna e la squadra nella seconda colonna il numero di gol nella quarta. Ad esempio, la prima riga $(\text{Real Madrid},\text{Liverpool},3,1)$ indica che la partita Real Madrid - Liverpool si è conclusa con un 3 a 1 per il Real Madrid. Possiamo notare come i dati in questa tabella (relazione) appartengano a due domini: quello delle stringhe e quello dei numeri interi. Infatti questa relazione è un sottoinsieme del prodotto cartesiano:

$$\text{Stringhe}\times \text{Stringhe}\times \text{Interi}\times \text{Interi}$$

Ricordiamo che le relazioni sono formate da tuple ordinate, cioè in una $n$-upla $⟨v_1,v_2,\dots ,v_n⟩$ ogni elemento $v_i$ appartiene al suo corrispondente dominio $D_i$, per ogni $i$ compreso tra $1$ ed $n$ (estremi inclusi). Inoltre, una relazione è un insieme, e quindi:

• Non esiste un ordine definito tra le tuple: nelle tabelle che le rappresentano c’è ovviamente un ordine di “presentazione”, ma esso è irrilevante, poiché due tabelle con le stesse righe, ma in ordine diverso, rappresentano la stessa relazione.
• Le tuple di una relazione sono tutte distinte: in un insieme non possono esistere due elementi identici, quindi una tabella può rappresentare una relazione solo se le sue righe sono tutte diverse tra loro.

Possiamo anche notare come l’importanza dell’ordine degli elementi nelle tuple si può anche evincere dalla tabella precedente: se scambiassimo di posto le ultime due colonne, pur essendo entrambe rappresentate dal dominio dei numeri interi, falseremmo i risultati delle partite. Questo ordinamento tra i domini di una relazione corrisponde in realtà a una caratteristica insoddisfacente del concetto di relazione, così come è definito in matematica, per quanto riguarda la possibilità di organizzare e utilizzare i dati. Infatti, in informatica si tende a preferire notazioni non posizionali a quelle posizionali:

• Le notazioni non posizionali permettono di fare riferimento agli elementi di una tupla mediante nomi simbolici.
• Le notazioni posizionali, invece, fanno riferimento ai campi attraverso il loro ordine, e dovrebbero essere utilizzate solo quando l’ordinamento corrisponde a una caratteristica intrinseca, come accade, ad esempio, nei problemi di analisi numerica, dove gli array offrono una rappresentazione ovvia e diretta di vettori e matrici.

Per questo motivo, introduciamo una notazione non posizionale, associando nomi ai domini di una relazione, detti attributi, che descrivono i “ruoli” svolti dai domini stessi. Ad esempio, per la relazione relativa alle partite, possiamo usare nomi come $\text{SquadraInCasa}$, $\text{SquadraOspite}$, $\text{GoalInCasa}$, $\text{GoalOspiti}$. Nella rappresentazione tabellare, gli attributi possono essere utilizzati come intestazioni delle colonne:

$\text{SquadraInCasa}$	$\text{SquadraOspite}$	$\text{GoalInCasa}$	$\text{GoalOspiti}$
$\text{Real Madrid}$	$\text{Liverpool}$	$3$	$1$
$\text{Liverpool}$	$\text{Milan}$	$2$	$0$
$\text{Torino}$	$\text{Juventus}$	$1$	$1$
$\text{Roma}$	$\text{Milan}$	$0$	$1$

Dato che è necessario identificare in modo univoco le componenti, gli attributi di una relazione (e quindi le intestazioni delle colonne) devono essere tutti diversi tra loro.

Modificando la definizione di relazione con l’introduzione degli attributi, e ancora prima di fornire una definizione formale, possiamo osservare che l’ordinamento degli attributi (e quindi delle colonne nella rappresentazione tabellare) è irrilevante: non è più necessario parlare di primo dominio, secondo dominio, e così via; è sufficiente fare riferimento agli attributi stessi. Ad esempio, la seguente rappresentazione tabellare della relazione è equivalente alla precedente, con gli attributi (e quindi le colonne) in un ordine diverso, seguendo lo stile americano, in cui la squadra di casa viene mostrata dopo la squadra ospite.

$\text{SquadraOspite}$	$\text{SquadraInCasa}$	$\text{GoalOspiti}$	$\text{GoalInCasa}$
$\text{Liverpool}$	$\text{Real Madrid}$	$1$	$3$
$\text{Milan}$	$\text{Liverpool}$	$0$	$2$
$\text{Juventus}$	$\text{Torino}$	$1$	$1$
$\text{Milan}$	$\text{Roma}$	$1$	$0$

3 - Definizione formale di relazione

Dopo aver introdotto informalmente i concetti riguardanti il modello relazionale, ora ci tocca introdurli da un punto di vista formale, rigoroso e matematico.

3.1 - Definizione di tipi di dati, attributi e schemi

Per arrivare a definire il concetto di relazione, dobbiamo partire dalle fondamenta del modello relazionale, definendo formalmente cosa sono i tipi dei dati e i relativi attributi.

Definizione: tipo di dato

Un tipo di dato (o semplicemente tipo) $T$ è un insieme di valori possibili che un dato può assumere.

Definiamo quindi i tipi di dato classici che si possono trovare solitamente all’interno dei RDBMS.

Definizione: tipo di dato $\text{Int}$

$\text{Int}$ è un tipo di dato rappresentante l’insieme dei numeri interi $\mathbb{Z}$ nei RDBMS:

$$\text{Int}=\{0,1,-1,2,-2,\dots \}$$

Definizione: tipo di dato $\text{Float}$

$\text{Float}$ è un tipo di dato rappresentante l’insieme dei numeri reali $\mathbb{R}$ nei RDBMS:

$$\text{Float}=\{0,1.3,3.14159,-741.57,\dots \}$$

Definizione: tipo di dato $\text{String}$

$\text{String}$ è un tipo di dato rappresentante l’insieme delle stringhe nei RDBMS:

$$\text{String}=\{\text{"Ciao"},\text{"str1ng4!"},\text{"stringa composta da piuˋ parole"},\dots \}$$

Definizione: tipo di dato $\text{Char}$

$\text{Char}$ è un tipo di dato rappresentante l’insieme delle stringhe di lunghezza $1$ (cioè i singoli caratteri) nei RDBMS:

$$\text{Char}=\{\text{’N’},\text{’1’},\text{’g’},\text{’\_’},\dots \}$$

Definizione: tipo di dato $\text{Date}$

$\text{Date}$ è un tipo di dato rappresentante l’insieme delle date nei RDBMS:

$$\text{Date}=\{\text{2025-07-02},\text{2004-06-22},\dots \}$$

Definizione: tipo di dato $\text{Bool}$

$\text{Bool}$ è un tipo di dato rappresentante l’insieme dei due valori booleani $\text{True}$ e $\text{False}$ nei RDBMS:

$$\text{Bool}=\{\text{True},\text{False}\}$$

I tipi dei dati vengono utilizzati all’interno degli attributi di una relazione.

Definizione: attributo

Un attributo $A$ è un sottoinsieme di un tipo di dato $T$ e si dice che $A$ è di tipo $T$:

$$A\subseteq T$$

Esempi di attributi

Esempi di attributi potrebbero essere:

• Un attributo $\text{Nome}$ di tipo $\text{String}$ che può avere come valori associati tutti i possibili nomi validi, come $\text{Alice}$, $\text{Marco}$, $\text{Giulia}$, e così via: $$\text{Nome}=\{\text{Alice},\text{Marco},\text{Giulia},\dots \}\subseteq \text{String}$$
• Un attributo $\text{Etaˋ}$ di tipo $\text{Int}$ che può avere come valori associati tutti i numeri interi da $0$ fino a un massimo accettabile (come $120$): $$\text{Etaˋ}=\{0,1,2,\dots ,120\}\subseteq \text{Int}$$

Notazione: unione di attributi

Dati due attributi $A$ e $B$, la notazione $AB$ rappresenta l’unione insiemistica $A\cup B$.

Cosa succede se, nel momento in cui devo inserire un dato, non ne conosco il suo valore? È possibile inserire dei valori “mancanti” in una relazione? La risposta è che ci sono diversi modi per farlo:

• Usando un particolare valore appartenente a quel tipo di dato, in modo tale che quel valore sia convenzionalmente interpretato come un segnaposto e privandolo del suo valore effettivo.

Esempio di valore segnaposto

In un attributo $\text{Etaˋ}$ di tipo $\text{Int}$ in cui vanno inserite le età di diverse persone, posso scegliere per esempio di assegnare il valore $0$ a quelle persone di cui non conosco l’età, ma ciò mi rende impossibile allora usare il valore $0$ nel suo significato concreto, per esempio non posso assegnarlo come valore all’età di un neonato. Un’alternativa potrebbe essere usare un valore che sicuramente non mi servirebbe assegnare a nessuno, come $200$ o $-1$.

• Usando un valore creato ad hoc, ossia un valore nullo usato specificatamente per questo ruolo.

Definizione: valore nullo

Il valore nullo, denotato con $\text{null}$, è un elemento presente in ogni tipo di dato che rappresenta un valore sconosciuto nell’attributo.

Gli attributi sono raggruppati in schemi.

Definizione: schema di una relazione

Uno schema di una relazione (o semplicemente schema) $A$ è un insieme di attributi $\{A_1,A_2,\dots ,A_n\}$:

$$A=\{A_1,A_2,\dots ,A_n\}$$

Esempio di schema

Un esempio di schema potrebbe essere l’insieme di attributi che identificano gli studenti di un’università:

$$A=\{\text{Matricola},\text{Cognome},\text{Nome},\text{DataDiNascita},\text{CorsoDiLaurea}\}$$

dove:

• $\text{Matricola}$ è un attributi di tipo $\text{String}$ che rappresenta un identificatore univoco per lo studente.
• $\text{Cognome}$ è un attributo di tipo $\text{String}$ che rappresenta il cognome dello studente.
• $\text{Nome}$ è un attributo di tipo $\text{String}$ che rappresenta il nome dello studente.
• $\text{DataDiNascita}$ è un attributo di tipo $\text{Date}$ che rappresenta la data di nascita dello studente.
• $\text{CorsoDiLaurea}$ è un attributo di tipo $\text{String}$ che indica il corso di laurea a cui è iscritto lo studente.

Rappresentazione di uno schema in D2

Tramite il linguaggio dichiarativo D2, progettato per la creazione di diagrammi in modo semplice e leggibile, è possibile avere una rappresentazione di uno schema facilmente consultabile, con la lista degli attributi e i loro relativi tipi.

Per esempio, consideriamo lo schema dell’esempio precedente. Tramite D2, si può ottenere la seguente rappresentazione:

Il codice per ottenerlo è il seguente (puoi testarlo sul D2 Playground):

A: {
  shape: sql_table
  Matricola: string
  Cognome: string
  Nome: string
  DataDiNascita: date
  CorsoDiLaurea: string
}
 

Possiamo fare alcune osservazioni sulla definizione di schema.

Osservazione: duplicati e ordine in uno schema

Uno schema, essendo un insieme, per definizione non ammette duplicati: ciò significa che non possono esserci all’interno di uno stesso schema due attributi con lo stesso nome.

Ovviamente, però, ciò non vieta l’esistenza di due attributi con nomi diversi ma stesso tipo di dato (es. $\text{Cognome}$ e $\text{Nome}$ sono entrambi di tipo $\text{String}$).

Allo stesso modo, ricordiamo che in un insieme anche l’ordine non conta, quindi gli schemi

$$A=\{\text{Matricola},\text{Cognome},\text{Nome},\text{DataDiNascita},\text{CorsoDiLaurea}\}$$

e

$$A^{\prime }=\{\text{Matricola},\text{CorsoDiLaurea},\text{Nome},\text{Cognome},\text{DataDiNascita}\}$$

sono equivalenti:

$$A=A^{\prime }$$

3.2 - Definizione di record e istanze

Una volta che abbiamo introdotto la definizione di schema, possiamo ora introdurre quelle definizioni che ci servono per arrivare al concetto di relazione.

Definizione: record

Dato uno schema $A$, un record $t$ è una $n$-upla $⟨v_1,v_2,\dots ,v_n⟩$ (e per questo viene anche chiamato tupla) della relazione $n$-aria $A_1\times A_2\times \dots \times A_n$, in cui ogni $v_i$ è un valore dell’attributo $A_i$.

Notazione: valori di un record

Per indicare il valore di un record $t=⟨v_1,v_2,\dots ,v_n⟩$ in corrispondenza di un attributo $A_i$ di uno schema $A$, si utilizza la notazione:

$$v_i=t[A_i]$$

Per indicare invece i valori di un record $t=⟨v_1,v_2,\dots ,v_n⟩$ in corrispondenza di multipli attributi $A_i,A_j,A_k$ di uno schema $A$, si utilizza la notazione:

$$⟨v_i,v_j,v_k⟩=t[A_i,A_j,A_k]$$

Esempio di record

Dato uno schema $A=\{\text{Matricola},\text{Cognome},\text{Nome},\text{DataDiNascita},\text{CorsoDiLaurea}\}$, possibili record sono:

• $t_1=⟨1298309,\text{Rossi},\text{Mario},14/03/2001,\text{Informatica}⟩$ e

• $t_2=⟨7521238,\text{Verdi},\text{Sofia},30/01/2004,\text{Psicologia}⟩$

con

• $t_1[\text{Nome}]=\text{Mario}$ e

• $t_2[\text{Matricola},\text{DataDiNascita},\text{CorsoDiLaurea}]=⟨7521238,30/01/2004,\text{Psicologia}⟩$.

Osservazione: record come funzione

Ogni record $t=⟨v_1,v_2,\dots ,v_n⟩$ può essere rappresentato come una funzione che fa corrispondere a ogni attributo $A_i$ di uno schema $A$ il corrispettivo valore $v_i$:

$$t:A_i\mapsto v_i$$

Definizione: istanza di una relazione

Dato uno schema $A$, un’istanza di una relazione (o semplicemente istanza, anche detta stato) $R$ è l’insieme di tutti i record $t_1,t_2,\dots ,t_n$ dove ogni $t_i\in R$ è compatibile con $A$:

$$A=\{t_1,t_2,\dots ,t_n\}$$

Notazione: valori di una tupla in corrispondenza di un insieme di attributi

Data un’istanza $R$ e una tupla $t=⟨v_1,v_2,\dots ,v_n⟩\in R$, se si vogliono ottenere i valori $⟨v_i,v_j,\dots ,v_k⟩$ di $t$ in corrispondenza degli attributi $A_i,A_j,\dots ,A_k$ dello schema $A$ si può usare la seguente notazione:

$$⟨v_i,v_j,\dots ,v_k⟩=t[A_i,A_j,\dots ,A_k]$$

Così come per gli schemi, anche per le istanze non bisogna tenere conto di elementi duplicati e dell’ordine degli elementi.

Osservazione: duplicati e ordine in un'istanza

Un’istanza, essendo un insieme, per definizione non ammette duplicati: ciò significa che non possono esserci all’interno di una stessa istanza due record uguali.

Allo stesso modo, ricordiamo che in un insieme anche l’ordine non conta, quindi le istanze

$$R=\{⟨a_1,a_2⟩,⟨b_1,b_2⟩\}$$

e

$$R^{\prime }=\{⟨b_1,b_2⟩,⟨a_1,a_2⟩\}$$

sono equivalenti:

$$R=R^{\prime }$$

Osservazione: istanza come insieme di funzioni

Dato che ogni record può essere rappresentato come una funzione, l’istanza può essere intesa come un insieme di funzioni tutte distinte tra loro (sempre perché in un insieme gli elementi sono unici e, essendo l’istanza un insieme per definizione, non può contenere record duplicati).

3.2.1 - Compatibilità di un record

Per capire se un record appartiene a un dato schema, dobbiamo verificarne la compatibilità.

Definizione: compatibilità di un record in uno schema

Un record $t=⟨v_1,v_2,\dots ,v_n⟩$ si dice compatibile con uno schema $A$ se ogni valore $v_i$ del record $t$ appartiene al relativo attributo $A_i$, ossia se il record $t$ è una funzione totale sullo schema $A$ (come visto nell’osservazione precedente).

Esempio di compatibilità di record

Dato uno schema

$$A=\{\text{Matricola},\text{Cognome},\text{Nome},\text{DataDiNascita},\text{CorsoDiLaurea}\}$$

un possibile record compatibile è

$$t_1=⟨1298309,\text{Rossi},\text{Mario},14/03/2001,\text{Informatica}⟩$$

Al contrario, il record

$$t_2=⟨\text{Verdi},\text{Sofia},7521238,30/01/2004,\text{Psicologia}⟩$$

non è compatibile in quanto ogni valore $v_i$ di $t_2$ non appartiene al relativo attributo $A_i$.

Similmente, il record

$$t_3=⟨1298309,\text{Rossi},\text{Informatica},14/03/2001,\text{Mario}⟩$$

non è compatibile perché, pur essendo il terzo e l’ultimo valore entrambi dello stesso tipo $\text{String}$, gli attributi sono diversi. Infatti, il terzo valore dovrebbe essere un nome proprio di persona e appartenere all’attributo $\text{Nome}$, mentre l’ultimo valore dovrebbe essere l’elenco dei corsi di laurea dell’università appartenere all’attributo $\text{CorsoDiLaurea}$:

$$\begin{array}{c}\text{Nome}=\{\text{Mario},\text{Sofia}\text{Giulio},\text{Rebecca},\dots \}\\ \text{CorsoDiLaurea}=\{\text{Informatica},\text{Psicologia},\text{Biologia},\dots \}\end{array}$$

3.3 - Definizione di relazione

Ora che abbiamo sputato sangue per definire cosa sono uno schema e un’istanza, possiamo finalmente definire cos’è una relazione.

Definizione: relazione

Una relazione $R(A)$ (o anche semplicemente $R$) è un’istanza $R$ associata a uno schema $A$ in cui ogni record $t_i\in R$ è compatibile con $A$.

Esempio di relazione

Un esempio di relazione potrebbe essere l’istanza

$$\begin{array}{rl}R=\{& ⟨1298309,\text{Rossi},\text{Mario},14/03/2001,\text{Informatica}⟩,\\ & ⟨7521238,\text{Verdi},\text{Sofia},30/01/2004,\text{Psicologia}⟩\}\end{array}$$

associata allo schema

$$A=\{\text{Matricola},\text{Cognome},\text{Nome},\text{DataDiNascita},\text{CorsoDiLaurea}\}$$

che dà origine alla relazione $R(A)$, in cui entrambe le tuple di $R$ sono compatibili con $A$.

Osservazione: differenza tra relazione matematica e relazione di Codd

In matematica, una relazione $n$-aria $A\times B$ è diversa da $B\times A$ perché non vale la proprietà commutativa del prodotto cartesiano, ovvero le relazioni $n$-arie sono strettamente legate all’ordine degli insiemi.

Nel modello relazionale di Codd, invece, l’ordine degli attributi $A_1,A_2,\dots ,A_n$ di uno schema $A$ è irrilevante (e ciò deriva dal fatto che lo schema è un insieme che, per definizione, non è ordinato), quindi le relazioni

$$R(A_1,A_2,\dots ,A_n)$$

e

$$R^{\prime }(A_n,\dots ,A_2,A_1)$$

sono equivalenti:

$$R=R^{\prime }$$

Come già visto nell’introduzione di questa pagina, una relazione si può rappresentare in forma tabellare.

Notazione: rappresentazione tabellare di una relazione

Una relazione $R(A)$ può essere rappresentata in forma tabellare, dove:

• Le colonne rappresentano gli attributi $A_1,A_2,\dots ,A_n$ dello schema $A$.
• Le righe rappresentano i record dell’istanza $R$.

Esempio di rappresentazione tabellare di una relazione

Una relazione $R(\text{Matricola},\text{Cognome},\text{Nome},\text{DataDiNascita},\text{CorsoDiLaurea})$ con istanza

$$\begin{array}{rl}R=\{& ⟨1298309,\text{Rossi},\text{Mario},14/03/2001,\text{Informatica}⟩,\\ & ⟨7521238,\text{Verdi},\text{Sofia},30/01/2004,\text{Psicologia}⟩\}\end{array}$$

può essere rappresentata come la tabella

$\text{Matricola}$	$\text{Cognome}$	$\text{Nome}$	$\text{DataDiNascita}$	$\text{CorsoDiLaurea}$
$1298309$	$\text{Rossi}$	$\text{Mario}$	$14/03/2001$	$\text{Informatica}$
$7521238$	$\text{Verdi}$	$\text{Sofia}$	$30/01/2004$	$\text{Psicologia}$

Definizione: grado di una relazione

Data una relazione $R(A)$, il suo grado $|A|$ è la cardinalità del suo schema $A$, ossia il numero dei suoi attributi.

Osservazione: grado di una relazione sempre $\ge 1$

In una relazione $R(A)$, l’insieme degli attributi $A_1,A_2,\dots ,A_n$ è sempre non vuoto, quindi il suo grado $|A|$ è sempre $\ge 1$.

Definizione: cardinalità di una relazione

Data una relazione $R(A)$, la sua cardinalità $|R|$ è la cardinalità della sua istanza $R$, ossia il numero dei suoi record.

Osservazione: cardinalità di una relazione sempre $\ge 0$

Contrariamente a quanto accade per lo schema, in una relazione $R(A)$ la sua istanza $R$ può essere un insieme vuoto (cioè può non contenere alcun record), quindi la sua cardinalità $|R|$ è sempre $\ge 0$ (perché può assumere il valore $0$ nel caso dell’insieme vuoto).

3.4 - Definizione di basi di dati

Potremmo quindi definire una base di dati nel modello relazionale come un insieme di relazioni.

Definizione: base di dati

Una base di dati $DB$ è un insieme di relazioni $R_1(A),R_2(B),\dots ,R_n(Z)$:

$$DB=\{R_1(A),R_2(B),\dots ,R_n(Z)\}$$

Consiglio: criterio per l'assegnazione di nomi agli attributi

Per la costruzione di una buona base di dati $DB=\{R_1(A),R_2(B),\dots ,R_n(Z)\}$, un criterio da tenere a mente durante la progettazione degli schemi $A,B,\dots ,Z$ è quello che, in caso di attributi omonimi in diverse relazioni, il concetto che esprimono deve essere lo stesso e il tipo deve essere lo stesso.

Quindi:

• Evitare omonimie, ossia l’uso di stessi nomi per concetti diversi (es. un attributo denominato $\text{Nome}$ sia per indicare il nome proprio di una persona che per il nome di un prodotto).
• Evitare sinonimie, ossia nomi diversi per stessi concetti (es. due attributi denominati $\text{Corso}$ e $\text{Insegnamento}$ per indicare un’unità didattica).

4 - Vincoli di integrità e chiavi

Fondamentale nel modello relazionale è l’uso dei vincoli di integrità per assicurarsi della correttezza dei dati. Essi possono essere di due tipi: locali o globali.

4.1 - Vincoli locali

Definizione: vincolo locale

Un vincolo locale (o vincolo intrarelazionale) è un vincolo posto sui valori possibili dei record di una relazione in modo che tali valori rispettino (non siano in contrasto con) la realtà che si vuole rappresentare.

Definizione: vincolo locale di dominio

Data una relazione $R(A)$, il vincolo locale di dominio stabilisce che per ogni attributo $A_1,A_2,\dots ,A_n\in A$ esiste un insieme ben definito (anche infinito) di valori possibili che ognuno di essi può assumere, detto appunto dominio.

Esempio di vincolo locale di dominio

Data una relazione $\text{STUDENTI}(\text{Matricola},\text{Cognome},\text{Nome},\text{DataDiNascita},\text{CorsoDiLaurea},\text{MediaVoti})$, possibili vincoli locali di dominio potrebbero essere:

• L’attributo $\text{Matricola}$ deve essere un numero intero positivo.
• Gli attributi $\text{Cognome}$ e $\text{Nome}$ devono essere stringhe di testo (es. massimo 50 caratteri).
• L’attributo $\text{DataDiNascita}$ deve essere una data valida nel formato YYYY-MM-DD.
• L’attributo $\text{CorsoDiLaurea}$ può assumere solo un valore tra un insieme predefinito di corsi validi (es. Informatica, Medicina, Psicologia, Ingegneria, ecc.).
• L’attributo $\text{MediaVoti}$ deve essere un numero reale compreso tra $18$ e $30$ (valori ammessi per la media dei voti universitari in Italia).

Definizione: vincolo locale sui valori nulli

Data una relazione $R(A)$, il vincolo locale sui valori nulli su un determinato attributo $A_i\in A$ stabilisce che, per ogni record $t\in R$, il valore $t[A_i]$ non deve essere il valore nullo.

4.2 - Vincoli globali

Per poter definire in maniera formale i vincoli globali, dobbiamo introdurre prima le nozioni di superchiave, utile a descrivere la connessione tra le varie relazioni di una base di dati.

4.2.1 - Superchiavi

Definizione: superchiave

Data una relazione $R(A)$, un sottoinsieme di attributi $sk\subseteq A$ è una superchiave di $R(A)$ se, quando due record $t_i,t_j\in R$ assumono gli stessi valori per tutti gli attributi di $sk$, allora sono in realtà lo stesso record:

$$\forall t_i,t_j\in R(t_i[sk]=t_j[sk])⟹t_i[A]=t_j[A]$$

Ossia, una superchiave è un insieme di attributi che identifica univocamente ogni record della relazione.

Esempio di superchiave

Sia $\text{STUDENTI}(\text{Matricola},\text{Cognome},\text{Nome},\text{DataDiNascita},\text{CorsoDiLaurea})$ la seguente relazione.

$\text{Matricola}$	$\text{Cognome}$	$\text{Nome}$	$\text{DataDiNascita}$	$\text{CorsoDiLaurea}$
$1298309$	$\text{Rossi}$	$\text{Mario}$	$14/03/2001$	$\text{Informatica}$
$7521238$	$\text{Verdi}$	$\text{Sofia}$	$30/01/2004$	$\text{Psicologia}$
$1239002$	$\text{Rossi}$	$\text{Francesco}$	$04/20/2003$	$\text{Informatica}$

Possiamo notare come l’insieme degli attributi $\{\text{Matricola},\text{Cognome},\text{CorsoDiLaurea}\}$ forma una superchiave, in quanto le triple di valori associati a questi attributi non sono duplicate:

$\text{Matricola}$	$\text{Cognome}$	$\text{CorsoDiLaurea}$
$1298309$	$\text{Rossi}$	$\text{Informatica}$
$7521238$	$\text{Verdi}$	$\text{Psicologia}$
$1239002$	$\text{Rossi}$	$\text{Informatica}$

Al contrario, l’insieme $\{\text{Cognome},\text{CorsoDiLaurea}\}$ non può rappresentare una superchiave perché i valori $⟨\text{Rossi},\text{Informatica}⟩$ sono duplicati:

$\text{Cognome}$	$\text{CorsoDiLaurea}$
$\text{Rossi}$	$\text{Informatica}$
$\text{Verdi}$	$\text{Psicologia}$
$\text{Rossi}$	$\text{Informatica}$

Proprietà: monotonicità delle superchiavi

Data una relazione $R(A)$, se un sottoinsieme di attributi $sk\subseteq A$ è una superchiave di $R(A)$, allora ogni insieme $w$ che la contiene (ossia $sk\subseteq w\subseteq A$) è a sua volta una superchiave.

Osservazione: lo schema è una superchiave

Data una relazione $R(A)$, come conseguenza della proprietà di monotonicità delle superchiavi, otteniamo che anche lo schema $A$ stesso è una superchiave di $R(A)$.

4.2.1 - Chiavi candidate

Definizione: chiave candidata

Data una relazione $R(A)$, un sottoinsieme di attributi $k\subseteq A$ è una chiave candidata se:

1. $k$ è una superchiave di $R(A)$.
2. $k$ è minimale, ossia ogni sottoinsieme proprio $k^{\prime }⊊k$ non deve essere a sua volta una superchiave.

Esempio di chiave candidata

Sia $\text{STUDENTI}(\text{Matricola},\text{Cognome},\text{Nome},\text{DataDiNascita},\text{CorsoDiLaurea})$ la seguente relazione.

$\text{Matricola}$	$\text{Cognome}$	$\text{Nome}$	$\text{DataDiNascita}$	$\text{CorsoDiLaurea}$
$1298309$	$\text{Rossi}$	$\text{Mario}$	$14/03/2001$	$\text{Informatica}$
$7521238$	$\text{Verdi}$	$\text{Sofia}$	$30/01/2004$	$\text{Psicologia}$
$1239002$	$\text{Rossi}$	$\text{Francesco}$	$04/20/2003$	$\text{Informatica}$

Delle chiavi candidate di questa relazione potrebbero essere gli attributi $\text{Matricola}$ e $\text{DataDiNascita}$, oppure l’insieme $\{\text{Cognome},\text{CorsoDiLaurea}\}$ che al suo interno non contiene altre superchiavi.

Al contrario, l’insieme $\{\text{Cognome},\text{Nome}\}$ non può essere una chiave candidata perché l’attributo $\text{Nome}$ è a sua volta una superchiave.

Osservazione: esistenza di una chiave candidata nella relazione

Data una relazione $R(A)$, essendo lo schema $A$ una superchiave, la relazione conterrà sempre almeno una chiave candidata (che, al più, sarà lo schema stesso della relazione).

4.2.2 - Chiavi primarie

Il progettista deve sempre scegliere tra le chiavi candidate una chiave primaria che permetterà a ogni record di poter essere identificato univocamente.

Definizione: chiave primaria

Data una relazione $R(A)$, una chiave primaria $\underline{PK}$ (anche detta chiave principale) è una particolare chiave candidata $\underline{PK}\subseteq A$ scelta che rispetta il vincolo locale sui valori nulli in ogni suo attributo.

Esempio di chiave primaria

Sia $\text{STUDENTI}(\text{Matricola},\text{Cognome},\text{Nome},\text{DataDiNascita},\text{CorsoDiLaurea})$ la seguente relazione.

$\text{Matricola}$	$\text{Cognome}$	$\text{Nome}$	$\text{DataDiNascita}$	$\text{CorsoDiLaurea}$
$1298309$	$\text{Rossi}$	$\text{Mario}$	$14/03/2001$	$\text{Informatica}$
$7521238$	$\text{Verdi}$	$\text{Sofia}$	$30/01/2004$	$\text{Psicologia}$
$1239002$	$\text{null}$	$\text{Francesco}$	$04/20/2003$	$\text{Informatica}$

Una chiave primaria di questa relazione potrebbe essere l’attributo $\text{Matricola}$, mentre non può esserlo l’attributo $\text{Cognome}$ perché il terzo record ha un valore nullo.

Osservazione: nesso tra chiave primaria, chiave candidata e superchiave

Una chiave primaria, per definizione, è una chiave candidata che rispetta il vincolo locale sui valori nulli in ogni suo attributo. A sua volta, una chiave candidata è per definizione una superchiave (un insieme di attributi che identifica univocamente ogni record della relazione) minimale.

Queste tre definizioni sono collegate da relazioni di inclusione stretta:

$$\text{Chiavi primarie}⊊\text{Chiavi candidate}⊊\text{Superchiavi}$$

Ciò significa che una chiave primaria è automaticamente una superchiave, ma non è necessariamente vero il contrario.

Se consideriamo inoltre una relazione $R(A)$, possiamo quindi dire che i requisiti che un insieme di attributi $\underline{PK}\subseteq A$ deve rispettare per essere considerato una chiave primaria sono tre:

1. Ogni record della relazione deve essere identificato univocamente da $\underline{PK}$ (requisito della superchiave).
2. $\underline{PK}$ deve essere minimale (requisito della chiave candidata).
3. $\underline{PK}$ deve rispettare il vincolo locale sui valori nulli in ogni suo attributo (requisito della chiave primaria).

Esercizio

Si consideri la seguente relazione $\text{EPISODI}$:

$\text{ID}$	$\text{Serie}$	$\text{NumStagione}$	$\text{NumEpisodio}$	$\text{TitoloEpisodio}$
$1$	$\text{Breaking Bad}$	$1$	$1$	$\text{Pilot}$
$2$	$\text{Breaking Bad}$	$1$	$2$	$\text{Cat’s in the bag…}$
$3$	$\text{Breaking Bad}$	$2$	$1$	$\text{Seven thirty-seven}$
$4$	$\text{Better Call Saul}$	$1$	$1$	$\text{Pilot}$
$5$	$\text{Better Call Saul}$	$1$	$\text{NULL}$	$\text{NULL}$

Quali dei seguenti insiemi di attributi possono essere scelti come chiave primaria di $\text{EPISODI}$? Scegli una o più alternative:

1. $\{\text{Serie},\text{NumStagione},\text{NumEpisodio}\}$

2. $\{\text{ID}\}$

3. $\{\text{ID},\text{Serie}\}$

4. $\{\text{ID},\text{Serie},\text{NumStagione},\text{NumEpisodio}\}$

Soluzione

Per stabilire se ogni opzione è una potenziale chiave primaria di $\text{EPISODI}$, verifichiamo se rispetta i tre requisiti.

Partendo dal primo requisito, quello della superchiave, possiamo scartare gli insiemi di attributi che non identificano univocamente la relazione. Abbiamo che tutte le opzioni rispettano questo requisito, quindi passiamo avanti.

Per il secondo requisito, quello della chiave candidata, possiamo scartare gli insiemi di attributi che non sono minimali. Abbiamo che l’opzione 3 non è minimale perché l’attributo $\text{ID}$ da solo è una superchiave e l’opzione 4 non è minimale perché contiene la superchiave $\{\text{ID},\text{Serie}\}$ (che, tra l’altro, corrisponde all’opzione 3):

1. $\{\text{Serie},\text{NumStagione},\text{NumEpisodio}\}$
2. $\{\text{ID}\}$
3. $\xcancel{\{\text{ID},\text{Serie}\}}$
4. $\xcancel{\{\text{ID},\text{Serie},\text{NumStagione},\text{NumEpisodio}\}}$

Per il terzo requisito, quello della chiave primaria, possiamo scartare gli insiemi di attributi che non rispettano il vincolo locale sui valori nulli in ogni suo attributo (requisito della chiave primaria). Abbiamo che l’opzione 1 contiene l’attributo $\text{NumEpisodio}$ che non rispetta il vincolo locale sui valori nulli:

1. $\xcancel{\{\text{Serie},\text{NumStagione},\text{NumEpisodio}\}}$
2. $\{\text{ID}\}$
3. $\xcancel{\{\text{ID},\text{Serie}\}}$
4. $\xcancel{\{\text{ID},\text{Serie},\text{NumStagione},\text{NumEpisodio}\}}$

L’unica opzione accettabile, quindi, è la 2.

Rappresentazione di una chiave primaria in D2

In D2 è possibile specificare qual è la chiave primaria di una relazione aggiungendo il vincolo locale di chiave primaria all’attributo in questione.

Per esempio, consideriamo la relazione $\text{STUDENTI}$ dell’esempio della chiave primaria. Tramite D2, si può ottenere la seguente rappresentazione:

Il codice per ottenerlo è il seguente (puoi testarlo sul D2 Playground):

STUDENTI: {
  shape: sql_table
  Matricola: string {constraint: primary_key}
  Cognome: string
  Nome: string
  DataDiNascita: date
  CorsoDiLaurea: string
}
 

4.3 - Vincoli globali

Definizione: vincolo globale

Un vincolo globale (o vincolo interrelazionale) è un vincolo posto sui valori possibili dei record delle relazioni di una base di dati in modo che tali valori rispettino (non siano in contrasto con) la realtà che si vuole rappresentare.

Ora possiamo definire in particolare quali sono i vincoli globali.

Definizione: vincolo globale di integrità referenziale

Il vincolo globale di integrità referenziale (o di chiave esterna) stabilisce che, date due relazioni $R(\underline{PK},\dots )$ (dove $\underline{PK}$ è la chiave primaria di $R$) e $S(\dots ,FK,\dots )$ (dove $FK\subseteq S$ è detto chiave esterna), per ogni record $t_i\in S$ esiste almeno un record $t_j\in R$ tale che il valore degli attributi $FK$ corrisponde al valore della chiave primaria $\underline{PK}$ in $t_j$:

$$\forall t_i\in S,\exists t_j\in R(t_i[FK]=t_j[\underline{PK}])$$

Esempio di vincolo globale di integrità referenziale

Sia $\text{PAZIENTI}$ la seguente relazione.

$\underline{\text{Codice}}$	$\text{Cognome}$	$\text{Nome}$	$\text{Residenza}$	$\text{AnnoNascita}$
$\text{A102}$	$\text{Necchi}$	$\text{Luca}$	$\text{TO}$	$1950$
$\text{B372}$	$\text{Rossigni}$	$\text{Piero}$	$\text{NO}$	$1940$
$\text{B543}$	$\text{Missoni}$	$\text{Nadia}$	$\text{TO}$	$1960$
$\text{B444}$	$\text{Missoni}$	$\text{Luigi}$	$\text{VC}$	$2000$
$\text{S555}$	$\text{Rossetti}$	$\text{Gino}$	$\text{AT}$	$2010$

Sia $\text{RICOVERI}$ la seguente relazione.

$\underline{\text{Paziente}}$	$\underline{\text{Inizio}}$	$\text{Fine}$	$\text{Reparto}$
$\text{A102}$	$\text{02/05/2014}$	$\text{19/05/2014}$	$\text{A}$
$\text{A102}$	$\text{02/12/2004}$	$\text{22/01/2005}$	$\text{A}$
$\text{S555}$	$\text{05/10/2014}$	$\text{03/12/2014}$	$\text{B}$
$\text{B444}$	$\text{11/12/2004}$	$\text{02/01/2005}$	$\text{B}$
$\text{S555}$	$\text{16/09/2015}$	$\text{21/11/2015}$	$\text{A}$

In questa situazione, l’attributo $\underline{\text{Paziente}}$ in $\text{RICOVERI}$ funge da chiave esterna che fa riferimento alla chiave primaria $\underline{\text{Codice}}$ in $\text{PAZIENTI}$: infatti, per ogni valore di $\text{Paziente}$ in $\text{RICOVERI}$ si trova un corrispondente in $\text{Codice}$ in $\text{PAZIENTI}$.

Osservazione: condizioni necessarie per il vincolo globale di integrità referenziale

Per far sì che il vincolo globale di integrità referenziale possa valere, i valori degli attributi in $\underline{PK}$ devono essere gli stessi valori degli attributi in $FK$.

Rappresentazione di una chiave esterna in D2

In D2 è possibile specificare qual è la chiave esterna di una relazione aggiungendo il vincolo globale di integrità referenziale all’attributo in questione.

Per esempio, consideriamo l’esempio di vincolo di integrità referenziale precedente. Tramite D2, si può ottenere la seguente rappresentazione:

Il codice per ottenerlo è il seguente (puoi testarlo sul D2 Playground):

PAZIENTI: {
  shape: sql_table
  Codice: string {constraint: primary_key}
  Cognome: string
  Nome: string
  Residenza: string
  AnnoNascita: int
}
 
RICOVERI: {
  shape: sql_table
  Paziente: string {constraint: [primary_key; foreign_key]}
  Inizio: time_stamp {constraint: primary_key}
  Fine: time_stamp
  Reparto: string
}
 
RICOVERI.Paziente -> PAZIENTI.Codice
 

4.4 - Correttezza dei dati

Il rispetto dei vincoli assicura la correttezza della relazione e, in generale, di tutta la base di dati.

Definizione: correttezza di una relazione

Una relazione $R(A)$ è detta corretta se sono soddisfatti tutti i vincoli locali.

Definizione: correttezza di una base di dati

Una base di dati $DB=\{R_1(A),R_2(B),\dots ,R_n(Z)\}$ è detta corretta se ogni relazione $R_1(A),R_2(B),\dots ,R_n(Z)\in DB$ è corretta e se sono soddisfatti tutti i vincoli globali.

---

Approfondimento

Fonti:

• 🏫 Lezioni e slide del Prof. Pensa Ruggero Gaetano del corso di Basi di Dati (canale B), Corso di Laurea in Informatica presso l’Università di Torino, A.A. 2024-25:
  • 2. Il modello relazionale.
  • Quiz sul modello relazionale
• 🏫 Appunti di Luca Barra del corso di Basi di Dati, Corso di Laurea in Informatica presso l’Università di Torino, A.A. 2022-23 (caricati sul repository GitHub del Team Studentesco Informatica).