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à