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 dato, indica una associazione di una istanza della tabella A con una istanza della tabella B. Siccome esiste una ed una sola chiave primaria in una tabella, possiamo usarla come attributo speciale, che chiameremo chiave esterna, nella tabella associata per identificare in modo univoco la relazione.

Ad esempio l’album “The Wall” dei Pink Floyd potremmo identificarlo con chiave primaria Id=1. Questa chiave la useremo come attributo chiave esterna con etichetta “AlbumId” per associare l’istanza della canzone “Wish you were here”. Siccome esiste solo un album con con Id corrispondete ad AlbumId, garantiamo che l’associazione sia univoca.

Qui un esempio che mostra graficamente la relazione tra due tabelle. Vedremo fra poco come rappresentare la relazione in uno schema logico.

Cardinalità

Le relazioni 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 quando può esistere una associazione tra ogni istanza di A ed una istanza di B, e viceversa. Di norma le relazioni sono opzionali.

Nel modello relazionale non è possibile creare direttamente una associazione tra due tabelle N:N. E’ necessario creare una tabella C detta “di relazione” che associa una chiave esterna con A ed un’altra chiave esterna con B, e con le sue istanze memorizza la relazione (indiretta) tra una istanza di A ed una istanza di B.

Si può osservare che il nome della tabella può essere chiamato per comodità con il nome delle due tabelle separati da un underscore _:

Esempio

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.