Lo schema E-R che abbiamo introdotto qui ben aiuta a descrivere la realtà di interesse, ma è ancora lontano da come è organizzato un DBMS relazionale.

Mapping relazionale

Riferendosi dunque ai DBMS ancora oggi maggiormente diffusi, ovvero ai cosiddetti DBMS relazionali, è necessario ristrutturare lo schema E-R, effettuando una operazione detta mapping verso il cosiddetto modello relazionale. Lo schema relazionale prevede di predisporre delle tabelle, in relazione fra di loro, che corrisponderanno alle tabelle effettivamente disponibili nel DBMS.

Tabelle, campi e record

Una tabella è formata da un numero fisso di colonne (dette attributi o campi) ed un numero variabile di righe (dette tuple o record); i valori di una riga descrivono una istanza di relazione; i valori in ciascuna colonna sono tratti da uno stesso insieme predefinito di valori, detto dominio. Su una tabella o su una base di dati si possono definire dei vincoli; vi possono essere vincoli di tupla (non possono esserci due record con la stessa chiave), oppure vincoli di dominio (ad es. una persona non può essere nata nel 2050, questo valore è al di fuori del dominio).

Esempi

Con riferimento ai tre esempi visti nell’articolo sul modello E-R, si può procedere al mapping degli schemi E-R secondo il modello relazionale appena descritto:

ESEMPIO 1. 

Lo schema E-R era

Schema secondo il modello E-R (esempio 1)

Esempio 1 – modello E-R

Lo schema logico relativo al modello E-R è:

tabella PERSONA (codicefiscale,cognome,nome,residenza)

tabella CITTA (nomecitta, regione)

 Note: la chiave per “persona” è “codicefiscale” in quanto attributo che identifica univocamente una istanza dell’entità (ovvero una persona); la chiave per “citta” è “nomecitta” (non esistendo in Italia capoluoghi di provincia con lo stesso toponimo); il campo “residenza” nella tabella “persona” ha un vincolo: può contenere esclusivamente valori esistenti nella colonna “nomecitta” della tabella “citta”; si noti che vengono eliminati i caratteri speciali nel nome degli oggetti e degli attributi (ad es. “città” diventa “citta”); non è possibile avere una sola tabella, in quanto nella definizione della realtà di interesse è indicato che la tabella “citta” deve contenere tutte le città italiane.

ESEMPIO 2

Lo schema E-R era:

Esempio 2 - modello E-R

Esempio 2 – modello E-R

Lo schema logico relativo al modello E-R del secondo esempio è:

 AUTORE (cod-aut,nome)

LIBRO (titolo,argomento,data)

SCRIVE (cod-aut,titolo)

Note: nella realtà descritta, per definizione, non possono esistere due libri con lo stesso titolo (ma sarebbe meglio introdurre  un codice anche per i libri, tipo l’ISBN, e non utilizzare titolo come chiave); la tabella “autore” ha come chiave “cod-aut”, la tabella “libro” ha come chiave “titolo”, la tabella “scrive” ha come chiave l’insieme dei due attributi “cod-aut” e “titolo”; esiste un vincolo per la tabella “scrive”: entrambi i campi non possono contenere valori per cui non esista la corrispondenza nelle rispettive tabelle “autore” e “libro”; la data è stata spostata dalla tabella “scrive” ed è stata inserita come attributo della tabella “libro”.

ESEMPIO 3

Lo schema E-R era

Esempio 3 - modello E-R

Esempio 3 – modello E-R

Lo schema logico relativo al modello E-R del terzo esempio è:

 FORNITORE (partitaiva,ditta)

PRODOTTO (codice,genere)

MAGAZZINO (nome,telefono)

FORNITURA (partitaiva,codice,nome,data)

 Note: oltre alle tre tabelle “fornitore”, “prodotto” e “magazzino” relative alle entità, viene mappata sotto forma di tabella anche la relazione (tabella “fornitura”), dove la chiave è formata dall’insieme dei tre attributi chiave nelle tre tabelle citate, più l’attributo “data”; ovviamente esiste il vincolo per cui i primi tre campi devono avere un valore corrispondente esistente anche nelle prime tre tabelle.

Foto di Canva Studio da Pexels