Lezione del 16-10

IL LIVELLO LOGICO – Introduzione all’algebra relazionale
Lezione di BASI DI DATI I del 16/10/2009 – PRIMA PARTE
Come visto nelle lezioni precedenti, la progettazione di un database avviene su tre livelli
denominati LIVELLO CONCETTUALE, LIVELLO LOGICO e LIVELLO FISICO.
Per ogni livello si costruisce un MODELLO che contiene le informazioni da rappresentare e che è
rivolto agli attori che partecipa alla progettazione. Nello specifico, si ha che il MODELLO
CONCETTUALE, data la sua essenza molto “vicina all’utente”, è rivolto al COMMITTENTE, il
MODELLO LOGICO è rivolto agli IMPLEMENTATORI e, infine, il MODELLO FISICO è una
RAPPRESENTAZIONE 1:1 della realizzazione finale.
Il Diagramma E/R (Entità/Relazioni) è una prima rappresentazione del livello concettuale e
permette di disegnare in maniera semplice delle strutture dati anche molto complesse, come ad
esempio quelle ricorsive (che permettono di rappresentare semplicemente costrutti come la
SEQUENZA, l’ALBERO e la FORESTA, che con un linguaggio di programmazione richiederebbero
molte righe di codice).
La rappresentazione del livello logico, invece, si basa su una teoria nota come ALGEBRA
RELAZIONALE; tale tipo di algebra permette di definire delle “espressioni” che vanno a
rappresentare le INTERROGAZIONI che è possibile effettuare su un database, ossia le operazioni
che consentono di estrarre da un database determinate informazioni di interesse e che vanno poi
tradotte in SQL, il linguaggio di programmazione che opera sui database.
Innanzitutto, secondo la teoria dell’algebra relazionale, un database è un insieme di RELAZIONI e
VINCOLI, e si può rappresentare formalmente come:
DB = {R,V}
Una RELAZIONE può essere pensata in prima istanza come una tabella le cui righe non sono
ordinate, o insieme non ordinato di tuple, dove ogni tupla è una riga della tabella. Ogni elemento
della tabella prende il nome di ATTRIBUTO.
Per esempio, la relazione "Studente" si può rappresentare come:
STUDENTE
SSN
Nome
Cognome Indirizzo
Questa rappresentazione si chiama “INTENSIONALE”, ed è in contrapposizione alla cosiddetta
forma “tabellare estesa” che è invece una rappresentazione “ESTENSIONALE”.
STUDENTE
SSN
123
456
…
Nome
Franco
Mario
…
Cognome
Quarta
Rossi
…
Indirizzo
Piazza Mazzini, 13
Piazza S. Oronzo, 23
…
Nel modello relazionale ogni attributo è definito su un DOMINIO; per esempio il dominio di
definizione dell’attributo “Nome” è l’insieme di tutti i nomi validi nel contesto all’interno del quale
il database deve operare.
Il dominio si può rappresentare formalmente come:
dom(NOME) = {Insieme dei nomi validi nel CONTESTO in cui bisogna operare}
Tale insieme è di dimensione FINITA e a valori DISCRETI, come ogni oggetto rappresentabile
nella TEORIA DELL’INFORMAZIONE.
In corrispondenza ad ogni dominio vengono anche definiti un DATA-TYPE e un DATA-FORMAT,
che rappresentano rispettivamente il concetto di “tipo di dato” (Intero, Stringa, Data, ecc) e la
validità sintattica del dominio: ad esempio il CODICE FISCALE è stringa (a livello di DATA
TYPE) e deve avere la forma “LLLLLLNNLNNLNNNL” dove “L” indica una lettera e “N” un
numero (quest’ultimo è il suo DATA-FORMAT).
In generale il dominio, il data-type e il data-format definiscono completamente l’insieme dei valori
possibili per ogni attributo.
Si passa quindi a definire l’insieme degli STATI VALIDI di un database (detto anche “INSIEME
POTENZA”) che può essere rappresentato come il prodotto cartesiano dei domini di definizione di
ogni attributo, ad esempio per lo studente si ha:
INSIEME_POTENZA = {dom(SSN) X dom(NOME) X dom(COGNOME) X dom(INDIRIZZO)}
Per avere un database ben formato, ogni riga valida della rappresentazione estensionale deve
appartenere all’insieme potenza.
L’insieme dei valori possibili per ogni attributo deve essere esteso con un valore speciale, chiamato
“NULL”, che rappresenta una MANCANZA DI INFORMAZIONE in riferimento ad uno specifico
attributo: tale mancanza può presentarsi per svariati motivi, da errori in fase di memorizzazione nel
database ad omissione volontaria da parte dell’utente nella compilazione di moduli i cui dati
finiscono quindi per essere riversati in forma elettronica nel database stesso.
I valori “NULL” rappresentano un grosso problema all’interno della teoria delle Basi Di Dati,
poiché la loro presenza può dare luogo ad incoerenze logiche nei risultati delle interrogazioni e
devono quindi essere opportunamente gestiti.
Il concetto di valore “NULL” permette a sua volta di introdurre il concetto di VINCOLO: un
vincolo è una condizione che il database deve soddisfare per essere corretto formalmente e ben
definito.
Si passa quindi ad elencare un insieme di vincoli (“CONSTRAINTS”) che ogni database deve
soddisfare:
1) RELATION INTEGRITY – “PRIMARY KEY IS NOT NULL”
Qualsiasi attributo di un database può assumere valore NULL, ma non la chiave primaria.
2) PRIMARY KEY - “PRIMARY KEY MUST BE UNIQUE AND NOT NULL”
Il concetto di chiave primaria stesso è a sua volta un vincolo: considerando una relazione
R = {A1,A2,…,An}
si definisce una SUPER-KEY (“superchiave”) come l’insieme di tutti gli attributi che
identificano univocamente ogni tupla. In generale, all’interno di una relazione, esistono
molte superchiavi, ad esempio l’insieme stesso di tutti gli attributi (una singola riga) è una
superchiave; alcune di queste superchiavi sono caratterizzate dal fatto di essere MINIMALI,
cioè sono tali che non è possibile togliere un attributo e mantenere la condizione di chiave
(cioè l’univocità). Siccome in una relazione è possibile avere più chiavi, bisogna introdurre
il concetto di CANDIDATE KEY (“chiave candidata”), cioè le chiavi minimali fra le quali
bisogna scegliere una e una sola chiave primaria.
Ad esempio, si può considerare la relazione “CAR” e l’insieme delle sue superchiavi e
chiavi minimali:
CAR
Targa
Num. Telaio
Cilindrata
Tipo
Marca
SUPERKEY
SUPERKEY
MINIMAL KEY <=> CANDIDATE KEY
Adottando la simbologia insiemistica si ha che:
SUPERKEY ‫ כ‬MINIMAL KEY = CANDIDATE KEY
In generale risulta che il vincolo di “Chiave Primaria” è più forte del vincolo di “Relation
Integrity”.
3) EXTERNAL KEY – REFERENTIAL INTEGRITY
Avendo nel modello concettuale un tipo di relazione R, si dice che Ri è una coppia (aj,bk) e
la relazione R è l’insieme delle istanze Ri della relazione. Questo insieme può esistere
solamente a condizione che esistano sia aj che bk e si può fare l’esempio “STUDENTEFREQUENTA-FACOLTA’”:
STUDENTE
SSN
Nome Cognome Indirizzo
FACOLTA’
Nome
Indirizzo
FREQUENTA
SSN_Studente NOME_Facoltà
STUDENTE
FREQUENTA
FACOLTA’
Si definisce quindi il concetto di “FOREIGN KEY” (“chiave esterna”) e “REFERENTIAL
INTEGRITY” (“Integrità referenziale”) imponendo che la chiave esterna sia un riferimento
valido alla chiave primaria di un tipo di entità. Nell’esempio di cui sopra, la relazione è
correttamente definita se SSN_Studente e NOME_Facoltà fanno riferimento a studenti e
facoltà esistenti all’interno del database.
Più in generale, date due relazioni A e B, si dice che si ha un vincolo di integrità
referenziale su un attributo chiave esterna (FK) di una relazione poiché esso può assumere
soltanto valori permessi ed esistenti per una chiave primaria di un’altra relazione.
Quindi FK può assumere tutti e soli valori assunti da attributo A1 della relazione A;
schematicamente si può rappresentare la condizione di integrità referenziale come:
A
A1
A2
… An
B
B1
B2
… Bk
FK
4) SEMANTIC CONSTRAINTS
Si tratta di vincoli SEMANTICI, che in contrapposizione ai vincoli SINTATTICI già visti,
hanno a che fare con il significato di ciò che è contenuto nel database. Tali vincoli si
dividono in due categorie:

DI STATO
Siccome i database sono delle macchine a stati, si ha che la macchina può passare da
uno stato valido all’altro solo attraverso delle transizioni valide. I vincoli sullo stato
riguardano uno stato specifico (ad esempio: “non può esistere una facoltà con meno
di 1000 iscritti”) e riguardano uno specifico istante della vita del database.

DI TRANSIZIONE
Un esempio di vincolo sulla transizione può essere: “Non è possibile creare una riga
se non sono soddisfatte determinate condizioni sulle altre righe”.
In generale, mentre i vincoli sintattici possono essere verificati direttamente dalla macchina,
poiché riguardano la forma degli attributi o delle relazioni, i vincoli di stato e di transizione
riguardano la semantica, ovvero il significato di attributi e relazioni, e per gestirli è
necessario definire all’interno del DBMS dei TRIGGER, cioè dei gestori di eventi che
attivano determinate procedure al verificarsi di particolari eventi e condizioni.
DATABASE LIFECYCLE
Il “CICLO DI VITA” di un database è legato al ciclo di vita delle sue relazioni e dei suoi vincoli e
di solito viene sintetizzato con l’acronimo CRUD, che comprende le iniziali delle quattro operazioni
fondamentali che è possibile definire su un database: Create, Read, Update, Delete.
Si ha quindi che, mentre i vincoli sono definiti staticamente, le relazioni possono evolvere nel
tempo a seconda dell’esecuzione delle operazioni appena elencate: può succedere quindi che
effettuando una operazione questa porti a delle violazioni dei vincoli sulla forma e il significato dei
dati del database. Le possibili violazioni dovute ad ogni operazione possono essere riassunte in uno
schema del tipo:
OPERAZIONI
Create
Read
Update
(Delete/Create)
SI’
NO
NO
SI’
NO
SI’
NO
NO
SI’
NO
SI’
NO
SI’
SI’
SI’
SI’
NO
SI’
SI’
SI’
VINCOLI
RELATION
INTEGRITY
UNIQUE
PRIMARY
KEY
REFERENTIAL
INTEGRITY
SEMANTIC
CONSTRAINTS
Delete
In generale, quando effettua una qualsiasi operazione, il DBMS deve avvertire l’utente ed evitare la
violazione dei vincoli.
Un caso particolare è quello dell’operazione di UPDATE, che può essere vista come la sequenza di
un’operazione di cancellazione e di un inserimento, e che quindi deve essere gestita come la somma
di tali operazioni per ciò che concerne il rispetto dei vincoli.
Per quanto riguarda il vincolo di “Integrità referenziale”, si hanno tre possibili modi di gestire le
situazioni di cancellazione:
 CASCADE – Cancellando un oggetto vengono cancellati automaticamente anche gli
oggetti ad esso collegati.
 REJECT – Prima di poter cancellare un oggetto è necessario cancellare gli oggetti
collegati, altrimenti la cancellazione non può avvenire.
 CHANGE – Quando viene cancellato un oggetto, gli oggetti ad esso collegati sono
assegnati ad un oggetto impostato di default.
Le violazioni dei vincoli semantici, invece si gestiscono come già detto attraverso l’impostazione di
determinati Trigger.
Autore:
MANCO MASSIMO ([email protected])