Dopo aver creato un modello concettuale, con un diagramma E/R, è possibile passare alla fase, successiva, ovvero il modello logico relazionale. Scopo di questo modello è quello di creare una rappresentazione del modello concettuale in una forma che sia rappresentabile con una determinata tecnologia di database, quella relazionale. Il suo obiettivo è quindi quello di tradurre le rappresentazioni concettuali in modelli logici direttamente rappresentabili in uno specifico sistema di RDBMS.

Negli RDBMS le entità sono costituite da tabelle, dove le colonne sono gli attributi, e le righe, chiamate record, sono le istanze. Le tabelle sono in relazione tra loro utilizzando attributi speciali, detti chiavi, che consentono di associare una istanza di una entità (tabella) con una istanza di un’altra entità (tabella).

Lo schema logico relazionale va, in conclusione, ad aggiungere tre fondamentali elementi di progettazione non presenti nello schema E/R di Chen:

• la forma degli attributi (il tipo di dato) ed i vincoli
• le chiavi
• le associazioni

Forma e vincoli degli attributi

Un attributo di una entità deve essere identificato sia da un nome (label) sia da un tipo di dato. I dati presenti di norma in un database hanno i seguenti tipi:

Famiglia	Tipo	Valori
Numerico	INT/INTEGER, SMALLINT, BIGINT	Rappresentano valori interi, con diversa precisione in bit.
Numerico	DECIMAL	Rappresentano valori in virgola fissa, per evitare errori di arrotondamento (usati
Numerico	FLOAT, DOUBLE	Rappresentano valori in virgola mobile, con diversa precisione in bit
Stringa	VARCHAR, TEXT	Rappresentano stringhe a lunghezza variabile (VARCHAR con lunghezza max dipendente dal tipo di RDBMS, TEXT per testi lunghi
Data	DATE, TIME, DATETIME	Servono per indicare date, ore o una loro combinazione.
Booleano	BIT	Rappresenta un valore booleano (true/false)
Binario	BLOB, JSON, XML	Rappresentano dati binari (BLOB) o file di testo contenenti dati JSON o XML.

Un attributo, inoltre:

• può essere obbligatorio, con indicazione NOT NULL: ad esempio un album deve avere un titolo, altrimenti l’istanza è priva di senso.
• può avere un valore di default, che viene valorizzato in automatico salvo inserimento esplicito.

Chiave primaria

E’ necessario definire, per ciascuna tabella, una chiave primaria, ovvero deve esistere un attributo con il ruolo di identificare univocamente l’intero record, e da cui logicamente dipendono gli altri attributi. La chiave primaria è quindi sia un elemento di informazione essenziale:

• serve ad identificare in modo univoco di ogni record della tabella;
• serve a di distinguere due record senza controllare ogni valore di ogni attributo, e per gestire infine due record con gli stessi dati, ma che dal punto di vista informativo sono due istanze differenti.
• serve a stabilire una relazione di dipendenza logica tra l’attributo chiave e gli altri attributi.

In questa lezione useremo sempre, come attributo chiave primaria, un valore intero. Ogni istanza della tabella avrà quindi un valore intero differente. Torneremo su questo argomento nella prossima lezione.

Associazioni

Chiave esterna

Una relazione, a livello di dati, indica una associazione di un record della tabella A con un record della tabella B. Nello schema logico useremo un attributo speciale in una delle due tabelle (ad esempio la tabella A), che deve corrispondere alla chiave primaria dell’altra tabella (la tabella B). Questo attributo, che chiameremo chiave esterna (Foreign Key) serve per identificare univocamente il record della tabella A al corrispondente della tabella B.

Questo è garantito dal fatto che nella tabella B la chiave primaria è unica, e quindi se un record di un’altra tabella ha un attributo chiave esterna che corrisponde alla chiave primaria della tabella A, viene garantita la corrispondenza dei due record.

Ad esempio nella Tabella Album, il record relativo all’album “The Wall” ha chiave primaria Id=1. Per associare la canzone “Wish you were here” (record della tabella Canzone) all’album, metteremo come chiave esterna “AlbumId” il valore 1. Siccome esiste solo un album con con Id=1, garantiamo che l’associazione sia univoca.

Qui un esempio che mostra graficamente la relazione tra due tabelle.

Cardinalità

Le relazioni come abbiamo visto hanno una cardinalità che può essere uno-a-uno, uno-a-molti, molti-a-molti.

Uno-a-molti

In una associazione 1:N per ogni istanza della classe A, esistono molte istanze di B. Nell’associazione 1:0..N possono esistere molte istanze di B. Le associazioni uno a molti sono utilizzate quando ad una istanza

Ad esempio, ad una istanza di Album (tabella A), corrispondono N istanze di Canzone (tabella B).

In questo scenario la chiave esterna è memorizzata nella tabella B. E’ l’esempio che abbiamo già, visto, ad una canzone corrisponde un album, quindi la chiave primaria dell’album sarà identificata come chiave esterna per ogni istanza di canzone.

Qui un esempio:

Ci possono essere anche situazioni in cui l’associazione è parziale, cioè dove ad una istanza di A può corrispondere 0 o più istanze di B. Potrebbe essere il caso di una nuova casa discografica che non ha ancora pubblicato album:

Uno-a-uno

In una associazione 1:1 per ogni istanza della classe A esiste una sola istanza della classe B. Nell’associazione 1:0..1 la corrispondenza è parziale, ovvero l’esistenza dell’istanza della classe B non è obbligatoria.

In questo scenario la chiave primaria di una delle due entità è usata come chiave esterna dell’altra. Non serve, è ridondante e perfino rischioso fare una doppia chiave reciproca (dove sia A che B hanno una chiave esterna dell’altra entità): si crea un problema di ridondanza di dati. Il problema progettuale da risolvere è: quale delle due entità deve contenere la chiave esterna?

La risposta è semplice: quella che semanticamente dipende dall’altra dal punto di vista informativo.

Ad esempio nel progetto Album, abbiamo una relazione 1:1 tra Album e Booklet. E’ evidente però che l’Album è una entità di primaria importanza, il Booklet una entità che dal punto di vista informativo, rappresenta un accessorio. Sarà questa a contenere la chiave esterna. Nel caso 1:0..1 semplicemente non esiste una istanza di Booklet corrispondente ad una istanza di Album.

Qui un esempio:

Quando la corrispondenza 1:1, cioè quando ad ogni istanza di A corrisponde sempre una istanza di B, allora lo schema è questo:

Molti-a-molti

In una associazione N:N può esistere una relazione tra ogni record della tabella A con ogni record della tabella B, e viceversa.

Una soluzione “banale” potrebbe essere quella di ipotizzare un attributo di tipo lista che elenca, come chiave esterna, tutte le chiavi primarie associate a quel record. Tuttavia questa soluzione non è mai stata adottata in nessun database relazionale, perché ha prestazioni non ottimali. Infatti una eventuale interrogazione che voglia cercare il collegamento tra due record, dovrebbe analizzare singolarmente per ogni record la lista delle chiavi esterne, un procedimento estremamente lento perché non può sfruttare l’indicizzazione dei valori delle chiavi.

La soluzione adottata è invece quella di creare una tabella C detta “di relazione”, che ha:

• un attributo che si associa alla chiave primaria di A
• un attributo che si associa alla chiave primaria di B

In questo modo elenchiamo una ad una le associazioni tra singoli record di A e di B.

Ad esempio Album e Supporto usano la tabella Supporto_Album come tabella di relazione.

Per capire il meccanismo di associazione poniamo di voler indicare che The Wall (Id=1 nella tabella Album) è memorizzato su Vinile (id=3 su Supporto). Per farlo creiamo un record nella tabella Supporto_Album con AlbumId=1 e SupportoId=3. Siccome le relazioni sono indipendenti nulla ci vieta di associare un album a diversi supporti, o viceversa un supporto a diversi album, come si vede nell’esempio qui sotto:

Riprendiamo quindi il diagramma E/R della lezione sul modello concettuale:

Lo possiamo tradurre in modello logico-relazionale:

Conclusioni

Il modello logico-relazionale è una rappresentazione del modello concettuale pensata per realizzare database relazionali (RDBMS). Esso permette di:

• definire il tipo degli attributi su un sistema dati;
• definire la chiave primaria che identifica univocamente gli attributi;
• inserire le relazioni 1:1 e 1:N tramite opportuni connettori e l’utilizzo di chiavi esterne:
• inserire le relazioni N:N tramite tabelle speciali, dette di relazione.

Con questo schema è ora possibile passare al modello fisico, cioè alla realizzazione del sistema vero e proprio.