Introduzione alla teoria dei database relazionali

Introduzione alla teoria dei
database relazionali
Come progettare un database
La struttura delle relazioni
Dopo la prima fase di individuazione concettuale delle entità e degli
attributi è necessario passare alla fase di strutturazione delle relazioni
Se una prima verifica delle entità e dei loro attributi era stata affrontata
al momento della realizzazione del modello dei dati, ora in questa fase
dobbiamo prestare ancora maggior attenzione a quei problemi che possono
pregiudicare il funzionamento della nostra base dati
Si tratterà in questa sezione dei problemi da evitare e delle regole che
permettono di strutturare efficaci relazioni (tabelle)
La ridondanza dei dati
Uno degli aspetti da evitare scrupolosamente è la ridondanza dei
dati
Attributo entità venditore
Attributo entità cliente
?
Tenendo conto che non ci troviamo davanti al risultato di una query
possiamo notare che alcuni dati sono in più
Il prezzo oltre ad essere attributo dell’entità libro, è anche presente nell’entità
vendita poiché, mentre il listino può variare nel tempo, il prezzo della vendita
rimane sempre fissato nel tempo (uno specifico libro in quella transazione è
stato venduto a quel prezzo)
La ridondanza dei dati
Oltre alla ridondanza di attributi non pertinenti, che implica uno spreco di
risorse e problemi per i recupero ed il mantenimento dei dati, esiste anche
un altro tipo di ridondanza:
La ridondanza di dati all’interno di un unico attributo
In questo caso (siamo ai limiti della violazione del modello stesso di database
relazionale) abbiamo inserito all’interno di un solo attributo una serie di dati
eterogenei tanto che un recupero dei dati solo tramite SQL è impossibile, ma
è necessario intervenire con la scrittura di istruzioni VBA
La ridondanza dei dati
Infine esiste la ridondanza di attributi aventi tutti lo stesso dominio
In questo caso le votazioni degli esami sono distribuite in un numero fisso
di campi
Questo fatto può creare due tipi di problemi:
Impossibilità di gestire uno studente che ha fatto più esami del dovuto
senza rivoluzionare l’intero database (l’aggiunta di un campo ad una tabella
non si risolve semplicemente poiché ogni tabella è associata ad altre tabelle,
query, maschere, stringe di comando ecc.)
Difficoltà di recupero e manipolazione dati, qualunque richiesta in merito alle
votazioni di uno studente deve essere posta a tutti i campi esame
La normalizzazione delle relazioni
Principi di base
Per normalizzazione si intende l’attenersi a regole precise di strutturazione
delle relazioni, in modo da avere una base dati il più possibile immune da
anomalie di gestione dei dati
Possiamo definire la normalizzazione una condizione necessaria ma non sufficiente
per avere un database funzionale
Il modello relazionale permette alle relazioni di associarsi tra loro tramite il
collegamento di attributi, permettendo di eliminare le ridondanze
Questo è il principio della scomposizione senza perdite
La normalizzazione delle relazioni
Principi di base
Una relazione è un insieme non ordinato di zero o più tuple, e
ciascun membro di questo insieme è univoco
Deve esistere cioè per ogni tupla un insieme di attributi che la identifichi
univocamente.
Questo insieme di uno o più attributi si definisce chiave candidata
In ogni relazione possono esistere anche più di una chiave candidata, ma ogni
chiave candidata deve individuare una sola tupla, non solo in uno specifico
insieme, ma anche in ogni insieme di tuple (cioè relazioni ottenute da query)
E’ vero anche il contrario, cioè: date due tuple che presentano la
medesima chiave candidata (si intende i medesimi dati contenuti nei
campi chiave) devono far riferimento alla stessa entità
La normalizzazione delle relazioni
Principi di base
Se una chiave candidata è formata da un unico attributo si definisce
chiave semplice, se è formata da più attributi si definisce chiave composta
L’importante è che una chiave sia anche irriducibile, che non sia così
possibile eliminare dall’insieme degli attributi che la compongono
un singolo attributo senza che la chiave perda di validità
Più semplicemente se un attributo non è necessario per il
mantenimento della funzionalità della chiave non deve essere incluso
Il termine chiave primaria indica solamente una delle chiavi candidate
La normalizzazione delle relazioni
Prima forma normale
Una relazione è in prima forma normale se i domini su cui sono definiti gli
attributi sono scalari, cioè contengono un solo valore
La prima forma normale implica l’eliminazione delle ridondanze di
dati e di attributi duplicati
La ridondanza di dati all’interno di un singolo dominio non è un
concetto assoluto (indipendente), ma viene influenzato da come i dati
dovranno essere manipolati all’interno del database
Un semplice campo Data/Ora talvolta può essere utile per indicare una data,
ma se il programma deve spesso manipolare e variare solo alcuni aspetti della
data può essere più comodo memorizzare i dati singolarmente
Ipotizziamo il caso di un attributo che deve memorizzare il momento di una vendita
utilizzeremo la funzione Now() che restituisce data e ora, questi dati non
saranno immediatamente confrontabili con un valore solo data se non utilizzando
funzioni di estrazione data da un valore data/ora
20/02/01 03:30:15 PM diverso da 20/02/01
La normalizzazione delle relazioni
Seconda forma normale
Una relazione è in seconda forma normale se è in prima forma normale e se
tutti gli attributi sono dipendenti dall’intera chiave candidata
Non solo gli attributi non pertinenti devono essere eliminati da questa relazione
ma spesso è necessaria la creazione di una nuova relazione per mantenere i dati
all’interno del database e altrettanto spesso la relazione incriminata deve subire
una riprogettazione
La normalizzazione delle relazioni
Terza forma normale
Una relazione è in terza forma normale se è in seconda forma normale e se
tutti gli attributi che non sono chiavi candidate sono mutualmente
indipendenti
In questo caso è molto evidente che esiste un legame di dipendenza tra la regione
in cui opera il rappresentante e la capitale della regione, se il capoluogo è importante
per la nostra struttura dei dati un procedimento corretto eliminarla da questa
relazione ed implementare una nuova relazione (Regione-Capoluogo)
Altri esempi possono essere: città-CAP; Nazione-valuta ecc
Si può affermare che quando all’interno della nostra struttura dei dati si ha
una dipendenza tra attributi è utile creare una relazione che la espliciti
sia per risparmiare lavoro nell’immissione dati che per mantenerne l’integrità