Modulo 8 I data base Unità 4 Modello Relazionale

Transcript

1 Modulo 8 I data base Unità 4 Modello Relazionale Prof. Antonio Scanu

2 1 La progettazione concettuale Il passo successivo nella progettazione di una base di dati è la progettazione logica relazionale, che consiste nel trasformare la rappresentazione ancora astratta e indipendente del diagramma ER in una rappresentazione più efficiente (ma comunque indipendente da un particolare DBMS) detta schema logico relazionale. La progettazione logica relazionale consiste quindi nel mapping, cioè nella conversione del diagramma ER in un insieme di tabelle detto schema logico relazionale e nella definizione delle operazioni da compiere su di esso. Il modello relazionale dei dati, introdotto fin dal 1970 da E.F. Codd, prevede un unico e semplice meccanismo di strutturazione dei dati, basato sul concetto matematico di relazione fra insiemi. Una relazione R su una sequenza di insiemi D1, D2,..., Dn (non necessariamente distinti) è un sottoinsieme finito del prodotto cartesiano D1 x D2... x Dn, che possiamo esprimere con: R D1 x D2... x Dn dove: gli insiemi D sono detti domini della relazione e ciascuno di essi si rifà a un tipo di dato elementare (carattere, intero, reale, booleano e così via). A ogni dominio è associato un nome, detto attributo, che lo distingue dagli altri all interno della relazione; n (n 1) è detto grado della relazione ed è indicato con Grado(R). Due domini possono quindi avere lo stesso tipo ma nomi diversi (ad esempio, gli attributi Peso e Altezza possono essere di tipo reale). Chiameremo schema di una relazione il suo nome e la lista dei suoi attributi racchiusi tra parentesi tonde e separati da virgole. Lo schema di una relazione indica il significato intensionale di quest ultima. Utilizzeremo la seguente sintassi per rappresentarlo: # <NOMERELAZIONE>(<Attributo1>[:<Tipo1>],, <AttributoN>[:<TipoN>]) dove <Tipo1>,..., <TipoN> sono i tipi degli attributi, che spesso ometteremo per maggiore concisione. Il tipo può essere intero, reale, stringa, booleano e data. Consideriamo il seguente schema della relazione Persona per rappresentare le caratteristiche peculiari di un essere umano: # PERSONA(Cognome: STRINGA, Nome: STRINGA, Età: INTERO, Sesso: BOOLEANO) o più brevemente: # PERSONA(Cognome, Nome, Età, Sesso), oppure 2

3 Nella rappresentazione insiemistica si usa un ellisse all interno della quale inserire l insieme delle t-uple. Per chiarezza espositiva, negli esempi che seguiranno per l attributo Sesso identificheremo Femmina con Falso e Maschio con Vero. Gli elementi di R sono detti n-uple o t-uple e vengono indicati con: (d1, d2,..., dn) dove d1 D1, d2 D2,..., dn Dn. (elementi vengono scritti in minuscolo e gli insiemi in maiuscolo). Nota che, coerentemente con la definizione di insieme, una relazione non può contenere t-uple uguali. Chiameremo istanza di una relazione R l insieme delle sue t-uple in un determinato istante di tempo. L istanza rappresenta il significato estensionale della relazione. A differenza delle relazioni matematiche, le relazioni del modello relazionale sono variabili nel tempo: le t-uple possono essere inserite, cancellate, aggiornate. Il numero m di t-uple presenti in un dato istante in una relazione R viene detto cardinalità (corrente) della relazione e indicato con Card(R). Una relazione (come accade per le relazioni matematiche) può essere rappresentata anche nei seguenti modi: per elencazione; in forma tabellare; in forma insiemistica. Consideriamo la relazione Persona precedentemente definita. Con la rappresentazione per elencazione possiamo rappresentare un istanza di Persona elencando tutte le sue t-uple come faremmo per gli elementi di un insieme. Nella rappresentazione tabellare, invece, utilizziamo una tabella di n righe per m colonne, dove n rappresenta il grado e m la cardinalità, cioè: ogni riga rappresenta una t-upla; ogni colonna rappresenta la sequenza dei valori assunti dal corrispondente attributo. 3

4 Nella rappresentazione insiemistica si usa un ellisse all interno della quale inserire l insieme delle t-uple. 2 Chiavi, schemi e occorrenze 2.1 Le chiavi di una relazione Lo schema di una base di dati deve esprimere la struttura dei dati e gli eventuali vincoli espliciti di integrità dei dati. Abbiamo appena visto che la struttura dei dati è quella delle relazioni in senso matematico. Per quanto riguarda i vincoli, invece, tutte le definizioni del modello relazionale prevedono di specificare la presenza di una chiave per ciascuna relazione. Esattamente come per il modello ER, si dice chiave candidata o superchiave di una relazione R un insieme non vuoto K di attributi di R attraverso i quali è possibile individuare univocamente una t-upla per ogni possibile istanza della relazione R. Utilizzando i valori degli attributi presenti in K è possibile identificare un unica t-upla. Nota che una chiave candidata esiste sempre, al limite è costituita da tutti gli attributi di R poi - ché, come abbiamo già osservato, non possono esistere t-uple uguali. In generale, una relazione può ammettere diverse chiavi candidate. Fra queste ne viene scelta una con il minor numero di attributi (cioè una superchiave minimale) che viene designata come chiave primaria. Nello schema di una relazione, esattamente come nello schema ER, gli attributi che compongono la chiave sono sottolineati. Consideriamo i dati personali dei clienti di un albergo trascritti su un registro, che può essere assimilato a una relazione avente il seguente schema: # OSPITE(NumProgressivo, Nome, DataNascita, LuogoNascita, TipoDocumento, NumDocumento) Sono chiavi candidate: 1. (NumProgressivo); 2. (Nome, DataNascita, LuogoNascita); 3. (TipoDocumento, NumDocumento). Fra le chiavi candidate è stata scelta come chiave primaria (NumProgressivo), perché contiene il minor numero di attributi. 4

5 2.2 Schema e occorrenza di una base di dati Si definisce schema di una base di dati relazionale l insieme di tutti gli schemi di relazione. Si definisce occorrenza di una base di dati relazionale l insieme delle istanze degli schemi di relazione. È quindi possibile rappresentare la base di dati con un insieme di schemi di relazione. Se consideriamo una base di dati in un determinato momento, avremo una particolare occorrenza di quella base di dati, così come rappresentato nello schema della seguente figura: I legami tra tali relazioni si realizzano utilizzando le loro chiavi. Vedremo a breve come rappresentare nel modello relazionale tali legami (che corrispondono alle associazioni del modello ER). Prima, però, occorre introdurre il concetto di vincolo anche nel modello relazionale, così come abbiamo già fatto nel modello concettuale. 2.3 I vincoli di integrità Possiamo classificare i vincoli di integrità del modello relazionale in: vincoli intrarelazionali o interni, che sono definiti all interno di una singola relazione. Possono essere suddivisi in: vincoli su singola ennupla, che esprimono una condizione: sul dominio degli attributi: sono i vincoli che coinvolgono un solo attributo, il cui soddisfacimento può essere verificato facendo riferimento a un singolo valore alla volta; su più attributi: sono i vincoli che coinvolgono più attributi, ma sempre di ciascuna ennupla, indipendentemente dalle altre; vincoli su più ennuple, che coinvolgono i valori di più ennuple; rientrano in questa categoria i vincoli di chiave primaria (le t-uple presenti in una relazione devono essere tutte diverse tra loro); vincoli interrelazionali o esterni, che sono definiti tra più relazioni; rientrano in questa categoria i vincoli referenziali. È evidente che abbiamo considerato tutti i vincoli impliciti ed espliciti già visti per il modello concettuale. Consideriamo la relazione Dipendente, il cui schema è: # DIPENDENTE(Matricola, StipendioLordo, Trattenute, DataAssunzione, DataNascita) Possiamo individuare i seguenti vincoli intrarelazionali su singola ennupla: 5

6 1. StipendioLordo > 0 2. DataAssunzione > DataNascita 3. Trattenute > 0 Un istanza della relazione soddisfa questo vincolo solo quando tutte le t-uple lo soddisfano. In particolare, i vincoli 1 e 3 sono vincoli di dominio (come lo era Età > 0 per la relazione Studente). Il vincolo 2, invece, è un vincolo su più attributi. Un esempio di vincolo intrarelazionale su più ennuple è stato visto in precedenza: uno studente non può avere lo stesso numero di matricola di un altro studente. Questo è un vincolo di chiave primaria. Per rappresentare vincoli di chiave primaria sottolineiamo i relativi attributi (così come abbiamo fatto nel diagramma ER). Per rappresentare gli altri vincoli ricorriamo anche qui, come già fatto per il diagramma ER, al nostro pseudolinguaggio o al linguaggio naturale. Per rappresentare i vincoli intrarelazionali utilizziamo la seguente sintassi: # V<NumProgressivo>(<NomeRelazione>): <Espressione> dove: <NumProgressivo> è il numero progressivo del vincolo relativo alla relazione <NomeRelazione>; <Espressione> è una qualsiasi espressione in pseudolinguaggio o linguaggio naturale che serve per specificare il vincolo. Ad esempio, i vincoli sulla relazione Dipendente, vista in precedenza, possono essere i seguenti: V1(DIPENDENTE): StipendioLordo > 0 V2(DIPENDENTE): DataAssunzione > DataNascita V3(DIPENDENTE): Trattenute > 0 Gli altri tipi di vincoli potranno essere espressi nel linguaggio naturale. 3 Derivazione delle relazioni dal modello ER Il modello relazionale mette a disposizione del progettista solo le relazioni, per modellare i vari aspetti della realtà. Partendo dal diagramma ER, il progettista deve quindi effettuare un mapping delle entità e delle associazioni trasformandole in relazioni del modello relazionale. Lo schema relazionale si ricava dal diagramma ER applicando alcune semplici regole di derivazione per rappresentare: entità e attributi; associazioni di tipo 1:1; associazioni di tipo 1:N; associazioni di tipo N:N; gerarchie di classi. Esaminiamo in dettaglio ognuna di queste regole. 6

7 3.1 Rappresentazione delle entità e degli attributi Un entità E con attributi elementari A1, A2,..., An è immediatamente rappresentata attraverso una relazione: dove: Ad esempio: R(A1, A2,..., An) ogni tipo di entità diventa una relazione, rappresentabile mediante una tabella; ogni attributo del tipo entità diventa un attributo della relazione, rappresentato mediante una colonna della tabella; l attributo chiave dell entità diventa attributo chiave della relazione. 3.2 Rappresentazione delle associazioni binarie 1:N Un associazione R di tipo 1:N tra i due tipi di entità A e B, a cui corrispondono le relazioni RA e RB, è mappata aggiungendo alla relazione RB gli attributi chiave primaria KA di RA. Gli attributi chiave primaria di RA presenti in RB costituiscono una cosiddetta chiave esterna per la relazione RB. Il valore di una chiave esterna in una t-upla funge da puntatore logico alla t-upla dell altra relazione con la quale è in associazione. Sebbene nella nuova relazione sia possibile utilizzare nomi qualsiasi per gli attributi chiavi esterne, utilizzeremo quando possibile lo stesso nome dell attributo relativo alla chiave primaria. Le chiavi esterne non devono essere sottolineate, poiché non fanno parte della chiave della relazione. Nel diagramma ER precedente abbiamo rappresentato l associazione con linee tratteggiate: ciò significa che sia l associazione diretta, sia quella inversa sono parziali (per diretta intendiamo l associazione da B verso A. Per trasformare un diagramma ER con associazione diretta totale (linea continua da B al rombo dell associazione), occorre specificare un vincolo di integrità referenziale che forzi l esistenza nella relazione RA di una chiave primaria uguale alla chiave esterna KA. Solo in 7

8 questo modo, infatti, a ogni chiave esterna di B deve corrispondere necessariamente una chiave primaria di A. Ricordiamo che non si può cancellare una t-upla la cui chiave primaria compaia come chiave esterna in almeno una t-upla di altre relazioni. Consideriamo il seguente diagramma ER: Nella relazione Studente l attributo CodScuola è una chiave esterna che viene utilizzata per rappresentare l associazione 1:N esistente tra Studente e Scuola. In questo esempio, sia l associazione diretta che l inversa sono totali: infatti non possiamo inserire un alunno senza specificare la scuola a cui appartiene, così come non possiamo cancellare una scuola senza cancellare tutti gli alunni che ne fanno parte. Il meccanismo delle chiavi esterne comporta inevitabilmente una duplicazione di informazioni, in quanto la chiave esterna deve essere presente nella relazione. Se lo spazio richiesto in memoria per la rappresentazione degli attributi che compongono tale chiave è elevato, lo spreco di memoria può essere considerevole. In questi casi conviene introdurre una chiave artificiale formata da un unico attributo aggiunto alla relazione esterna (della quale diventa la nuova chiave primaria). Un esempio di chiave artificiale è un codice progressivo. Per rappresentare associazioni 1:N parziali, basta specificare come indefinito il valore della chiave esterna nelle t-uple di RB non associate ad alcuna t-upla di RA (si può ricorrere al valore speciale null). 3.3 Rappresentazione delle associazioni binarie 1:1 Le associazioni binarie 1:1 sono un caso particolare delle associazioni 1:N e seguono, quindi, le stesse regole viste in precedenza. In particolare: se entrambe le associazioni sono totali, si mappano i due tipi di entità in associazione 1:1 in un unica relazione avente tutti gli attributi dell uno e dell altro; è anche consentito conservare le due entità separate aggiungendo la chiave esterna a una qualunque delle due relazioni; se esistono associazioni con partecipazione facoltativa, si opta per la realizzazione di due relazioni distinte, aggiungendo la chiave esterna alla relazione rispetto a cui l associazione è totale, perché potrebbero esserci valori nulli per l entità con partecipazione opzionale; se entrambe le entità hanno partecipazione facoltativa, si prevedono solo relazioni separate e mai la relazione unica. Se l associazione ha degli attributi, questi vanno aggiunti alla relazione a cui si aggiunge la chiave esterna 8

9 3.4 Rappresentazione delle associazioni N:N Un associazione S di tipo N:N tra i due tipi di entità A a B, a cui corrispondono le relazioni RA e RB, è mappata creando una relazione RS avente almeno gli attributi chiave primaria KA di RA e gli attributi chiave primaria KB di RB (quindi RS ha come minimo due attributi). Ogni t-upla di RS rappresenta una coppia dell associazione binaria S. Da notare che le chiavi esterne KA e KB della relazione RS sono sottolineate, in quanto costituiscono la chiave interna della relazione RS (non sempre bastano). Il metodo appena descritto può essere facilmente generalizzato sia per rappresentare attributi dell associazione (basta aggiungerli alla relazione RS), sia per rappresentare associazioni non binarie (ad esempio ternarie di tipo N:M:P): basta introdurre le chiavi esterne in numero pari al grado dell associazione. Inoltre, anche le associazioni 1:N possono essere rappresentate come un caso particolare delle associazioni N:N, seguendo quindi le regole appena viste. 3.5 Rappresentazione di associazioni su una stessa entità Un caso particolare di associazioni 1:N o N:N è quello in cui l entità di partenza coincide con quella di arrivo. Consideriamo il seguente diagramma ER relativo a un associazione N:N su uno stesso tipo di entità: Per rappresentare tale associazione nel modello relazionale si opera allo stesso modo visto per le associazioni su più entità. Dipende quindi dal tipo di associazione. In questo caso, essendo N:N, avremo: RA(<KA>, <Attributi di A>) RR(<K1A>, <K2A>, <Attributi di R>) 9

10 La chiave <KA> comparirà in due colonne <K1A>, <K2A> della tabella che rappresenta l associazione R. Consideriamo il seguente diagramma ER relativo ai condomini di un condominio: 3.6 Rappresentazione di associazioni non binarie Supponiamo di avere il seguente diagramma ER relativo a un associazione totale su tre entità: Per rappresentare tale associazione nel modello relazionale, si opera come abbiamo visto per le associazioni binarie; dipende quindi dal tipo di associazione. Consideriamo il seguente diagramma ER relativo a un supermercato in cui i clienti possono acquistare più prodotti e pagarli in casse diverse: 10

11 3.7 Rappresentazione delle gerarchie Sono date un entità padre X con attributi AX e chiave primaria KX e due entità figlie disgiunte Y con attributi propri AY e Z con attributi propri Az (con attributi propri si intende non ereditati). Rappresentiamo questa situazione con un formalismo generico al fine di evitare di riferirci a una specifica gerarchia trattata nelle precedenti unità: Esistono tre modi diversi per rappresentare questa situazione: 1. Relazione unica. Si definisce un unica relazione composta dagli attributi dell entità padre e da quelli delle entità figlie. Si ha, quindi, una situazione simile: R(AX, AY, AZ, B) dove l attributo B è utilizzato per indicare l entità più specifica a cui appartiene l' elemento. Gli attributi AY, AZ possono anche avere valore nullo. 2. Partizionamento verticale. Si definiscono tre relazioni: RX(AX), RY(kA,AY), RZ(kA,AZ) La relazione RX è composta da tutti gli elementi dell entità padre A, anche se tali elementi sono presenti in qualche entità figlia, mentre le relazioni RY ed RZ sono composte dagli attributi propri e dalla chiave esterna ka che consente di reperire nella relazione RX il valore degli altri attributi. 3. Partizionamento orizzontale. Si definiscono tre relazioni: RX(AX), RY(AX,AY), RZ(AX,AZ) La relazione RX è composta dai soli elementi dell entità padre A che non sono pre senti in nessuna delle entità figlie, mentre le relazioni RY ed RZ sono composte da tutti gli elementi di Y e Z. È ovvio che, se le entità figlie creano una copertura, la re lazione RX(AX) non viene definita poiché sarebbe sempre vuota. 11

12 Consideriamo la seguente gerarchia, in cui le entità figlie costituiscono una partizione dell entità padre: Utilizzando le tre modalità descritte otterremo le seguenti relazioni: Relazione unica Si definisce, appunto, una sola relazione: STUDENTE(Codice, Cognome, Nome, CodInformatica, CodAbacus, Corso) Gli attributi CodInformatica e CodAbacus sono opzionali e Corso è un attributo discriminatore che indica quale corso è frequentato dallo studente. Partizionamento verticale Si definiscono tre relazioni nel seguente modo: STUDENTE(Codice, Cognome, Nome) CORSOABACUS(Codice, CodAbacus) CORSOINFORMATICA(Codice, CodInformatica) Partizionamento orizzontale Si definiscono tre relazioni nel seguente modo: STUDENTE(Codice, Cognome, Nome) CORSOABACUS(Codice, Cognome, Nome, CodAbacus) CORSOINFORMATICA(Codice, Cognome, Nome, CodInformatica) In questo caso, considerato che le entità figlie non soddisfano il vincolo di copertura, avremo che nella relazione STUDENTE saranno memorizzati gli studenti che non frequentano né il corso Abacus né il corso Informatica, nella relazione CORSOABACUS saranno memorizzate solo le informazioni degli studenti del corso Abacus e nella relazione CORSOINFOR- MATICA saranno memorizzate solo le informazioni degli studenti del corso Informatica. 12

13 4 Integrità referenziale Il concetto di integrità applicato a un database fa riferimento a un obiettivo che è essenziale raggiungere per mantenere in buono stato i dati presenti nel database in questione. Il concetto di integrità si traduce nel tenere sotto controllo la consistenza e la precisione dei dati. È necessario assicurarsi che un campo possa accettare un determinato insieme di valori (integrità di dominio), che ogni tabella abbia un insieme di campi che fungano da indentificatore univoco di ogni riga (integrità di entità) e che le relazioni definite tra le tabelle non possano essere violate (integrità referenziale). Fra i vincoli interrelazionali, i vincoli di integrità referenziale, o semplicemente vincoli referenziali, rivestono, pertanto, particolare importanza. Abbiamo visto che per stabilire un legame tra due (o più) relazioni utilizziamo le chiavi primarie delle due relazioni (creando altre relazioni che contengono i valori di queste chiavi), le quali prendono il nome di chiavi esterne. La chiave esterna soddisfa tre regole: Una chiave esterna di una t-upla in R1 fa riferimento a una chiave di una t-upla in R2; Gli attributi presenti nella chiave esterna hanno gli stessi domini degli attributi della chiave primaria a cui fanno riferimento. Un valore di chiave esterna di una t-upla in R1 o è presente a un valore di una t-upla in R2 o non esiste quindi è nullo. Nel primo caso si dice che la t-upla t1 riferisce o fa riferimento alla t-upla t2. Se questa condizione esiste si dice che sussiste un vincolo di integrità referenziale e, in questo caso, R1 è detta relazione referenziante (che fa riferimento), mentre R2 è detta relazione riferita (o referenziata, ossia alla quale si fa riferimento). Più in generale possiamo affermare che: I vincoli di integrità referenziale riguardano i valori assunti dalle chiavi esterne nelle relazioni. Poiché una chiave esterna è utilizzata per stabilire un legame tra relazioni, il suo valore deve essere tenuto in stretto controllo per le operazioni di inserimento, modifica e cancellazione. Mantenere l integrità referenziale significa quindi impedire agli utenti del database di interrompere accidentalmente le associazioni tra le tabelle correlate. Consideriamo le relazioni Articolo e Fornitore per stabilire un legame tra esse, al fine di conoscere gli articoli forniti da un certo fornitore, sapendo che un articolo può essere fornito da più fornitori e un fornitore fornisce più articoli. Per questo dobbiamo creare una nuova relazione che chiameremo Fornisce, utilizzando le chiavi primarie delle due relazioni Articolo e Fornitore, che diventano chiavi esterne (e primarie) della nuova relazione. Scriveremo quindi: 13

14 Un esempio di inconsistenza dei dati si ha se dalla relazione Fornitore si cancella il fornitore con chiave F03. Nella relazione Fornisce infatti avremo la chiave esterna F03 alla quale non corrisponde alcun fornitore. Stesso discorso se si cancella un articolo. Per assicurare l integrità referenziale, prima di cancellare una t-upla occorre verificare che non ci siano t-uple in altre relazioni che facciano riferimento alla t-upla da cancellare. Più in generale, le regole pratiche per l integrità referenziale sono le seguenti: non è possibile immettere un valore nella chiave esterna della tabella associata, se tale valore non esiste tra le chiavi della tabella primaria; non è possibile eliminare una t-upla dalla tabella primaria, se esistono righe legate ad essa attraverso la chiave esterna nella tabella correlata; non si può modificare il valore alla chiave nella tabella primaria, se ad essa corrispondono righe nella tabella correlata. L integrità referenziale è assicurata direttamente dal DBMS, che prevede la possibilità di dichiarare le regole di validazione attraverso appositi linguaggi dichiarativi. Tali regole vengono mantenute su speciali archivi detti cataloghi delle regole. 14

15 5 Normalizzazione Se lo schema della base di dati non è costruito correttamente, può accadere che si abbiano delle anomalie nel database, come, ad esempio, quelle derivanti dalla ripetizione dei dati, che portano a spreco di tempo (per l inserimento e l aggiornamento dei dati) e di spazio (memoria). Ciò può compromettere la congruenza dei dati contenuti nella base di dati durante le operazioni di inserimento, aggiornamento e modifica. Facciamo un esempio. Consideriamo la seguente relazione Atipica. Valutiamo, ora, le anomalie. Anomalia in inserimento: per inserire un nuovo cliente è necessario inserire contestualmente un articolo ordinato. Allo stesso modo, non è possibile inserire un nuovo articolo senza specificare un acquirente (ciò perché la chiave primaria della relazione è CodCliente, CodArticolo e non può mai essere nulla); Anomalia in cancellazione: se si cancella una t-upla relativa a un acquisto, si corre il rischio di cancellare anche dati relativi al cliente. Ad esempio, cancellando la t-upla (Rossi, Art1) non si cancella l indirizzo del cliente che continua a rimanere grazie alle t-uple (Rossi, Art2) e (Rossi, Art7). Se, invece, si cancella la t-upla (Neri, Art5) si perdono irrimediabilmente anche i dati del cliente. Analoghe considerazioni possono essere fatte per l articolo. Anomalia in aggiornamento: se occorre variare l indirizzo di un cliente, occorrerà aggiornare ogni t-upla in cui compare quel cliente. Queste anomalie, in particolare quelle in cancellazione e in aggiornamento, sono una diretta conseguenza della ridondanza, ossia della presenza di dati ripetuti inutilmente, cioè senza l apporto di nuova informazione. Lo scopo della teoria della normalizzazione è quello di fornire un metodo per progettare basi di dati senza anomalie, ossia per creare tabelle corrette. La normalizzazione è un procedimento di tipo graduale, che realizza un ottimizzazione progressiva a partire da relazioni non normalizzate fino a raggiungere un certo livello di normalizzazione. In particolare, consente di verificare se la definizione dello schema corrisponde ai canoni standard di correttezza della base di dati e, in caso, avvalendosi di un preciso insieme di regole, di riportare le tabelle in quelle che sono definite le forme normali delle tabelle relazionali. Una forma normale è una proprietà di uno schema relazionale che ne garantisce la qualità, cioè l assenza di determinati difetti. Nella teoria delle basi di dati relazionali esistono diverse forme normali (prima, seconda, terza, forma normale di Boyce-Codd, quarta e quinta). Nella nostra trattazione giungeremo sino alla terza forma normale, lasciando la trattazione delle altre studi superiori. 15

16 La normalizzazione va utilizzata come tecnica di verifica dei risultati della progettazione di una base di dati. Non costituisce, quindi, una metodologia di progettazione. 5.1 La prima forma normale (1FN) Partiamo dalla definizione: Una relazione si dice in prima forma normale (1FN), chiamata anche forma atomica, se: esiste una chiave primaria (un insieme di attributi che identifica in modo univoco ogni t- upla della relazione); ogni attributo è definito su un dominio di valori atomici (deve essere cioè un campo semplice, quindi non composto e non multiplo). La 1NF è di norma implicita: ogni informazione deve essere atomica, cioè un campo deve contenere una e una sola informazione. Diciamo che è implicita perché i campi contengono sempre un tipo di dato semplice (stringa, intero, reale...) e mai aggregazioni (vettori, record...). Le date potrebbero contravvenire a questo principio, perché in una data ci sono il giorno, il mese e l anno che potrebbero essere visti come entità separate e separabili, ma di solito si tralascia questa scomposizione considerando una data come un tutt uno. Qualsiasi intervento di scomposizione va sempre fatto nei limiti del buon senso. Per esempio, un indirizzo Via Santa Maria 80 Bari, dovrebbe essere scomposto in parti come Topotassia, Toponimia, Civico, Città vale a dire ( Via, Santa Maria, 80, Bari ), ma di solito, non si arriva così in dettaglio, a meno che non vi sia un esigenza particolare. Un esempio potrebbe essere quello legato a una realtà che si occupa delle spedizioni postali divise per città; in questo caso l indirizzo andrebbe disaggregato in maniera profonda. In tutti gli altri casi è sufficiente avere Indirizzo e Città. In generale, quindi, quando si incontrano campi che contengono più valori, questi campi devono essere suddivisi in modo che contengano un unico valore su ogni record. In alcuni 16

17 casi la suddivisione è semplice e naturale, in altri è molto più complessa. Come al solito, un esempio vale molto più di tante parole e, a tal proposito, riprendiamo proprio il caso di un indirizzo. Analizziamo la seguente relazione Persone. La tabella ha una chiave primaria, quindi la prima regola è confermata. Il campo Indirizzo, però, contiene più valori: la via con il numero civico e la città. Per normalizzare la relazione si suddivide il campo Indirizzo in modo che ogni informazione sia rappresentata con un apposito attributo. Osserviamo che Indirizzo, ora, contiene più informazioni, la via e il numero civico, ma risulta comunque di tipo stringa, che è un tipo semplice. Se queste informazioni devono essere utilizzate solo per la memorizzazione, la scrittura e la lettura, possono essere lasciate in questa forma, ma se ad esempio si volessero effettuare delle ricerche in base alla via, l algoritmo di ricerca potrebbe risultare più complicato e certamente più lento, perché occorrerebbe estrarre dal campo le parti di testo che corrispondono al nome della via. In questi casi può essere utile scomporre ulteriormente l attributo. Un altro caso di relazione non normalizzata è quello in cui sono presenti attributi multipli. Ricordiamo che un attributo è multiplo se può essere una sequenza di valori tutti dello stesso tipo. Ad esempio, per una persona l attributo NumeriDiTelefono, può essere multiplo poiché una persona può avere più recapiti telefonici. 17

18 In un certo senso è come se a 1 persona corrispondessero N numeri di telefono. Per avere uno schema in 1FN si sostituisce la relazione non normalizzata con due relazioni: una simile a quella di origine, ma senza l attributo multiplo, l altra contenente la chiave primaria della prima relazione e un attributo semplice che contiene ogni singolo valore della sequenza originale. La chiave primaria di quest ultima relazione è data dall unione della chiave primaria della relazione iniziale e dell attributo. Nel nostro esempio avremmo: 5.2 La seconda forma normale (2FN) Posto che i dati devono essere tutti semplici, in questo secondo livello normativo si va ad affrontare il vero e proprio aspetto logico della struttura. Partiamo da qualche concetto. Sia R una relazione che contiene almeno due attributi X e Y. Se il valore di Y varia al variare del valore di X, si dice che Y ha una dipendenza funzionale da X e si indica con X Y (si dice anche che X determina Y, o che X è un determinante per Y). Lo stesso vale se, invece di singoli attributi, si considerano insiemi di attributi. Ciò significa che, per ogni insieme di ennuple che possono esistere in R, non possono esistere due ennuple che hanno lo stesso valore di X e valori diversi di Y. Questo concetto è molto importante. Se il valore di un campo può variare al variare di qualsiasi parte della chiave primaria, possiamo dire che quel campo dipende dall intera chiave, mentre se può variare alla variazione di una sola parte della chiave, allora quel campo non dipende dalla chiave intera, ma solo da una parte di essa. Dalla definizione si evidenzia chiaramente che una chiave primaria è determinante per ogni attributo della relazione. Diciamo, dunque, che: Una relazione R è in seconda forma normale (2FN) se è in prima forma normale e ogni attributo non chiave dipende funzionalmente e completamente (cioè non parzialmente) dalla chiave primaria. Tutti i campi diversi dalla chiave primaria, pertanto, devono dipendere dall intera chiave primaria e non da una sua parte. Prendiamo in considerazione il seguente schema di relazione: ORDINI(CodOrdine, CodCliente, CodProdotto, DataOrdine, Quantità, PrezzoUnit, Descrizione) Questa relazione non è in seconda forma normale perché al suo interno sono memorizzate informazioni riguardanti più di un oggetto, cioè più elementi distinti: 18

19 gli ordini, i prodotti, i prodotti ordinati in ciascun ordine. Supponiamo che le informazioni sugli ordini e sui prodotti non siano presenti in altri schemi. Per questi motivi lo schema presenta delle anomalie: anomalia in inserimento: non è possibile inserire un nuovo articolo in magazzino sino a quando non è ordinato (ciò perché la chiave primaria della relazione è CodOrdine e CodProdotto e non può mai essere nulla); anomalia in cancellazione: se si cancellano la seconda o la terza o la quarta tupla, si perdono informazioni sugli articoli che compaiono in esse; anomalia in aggiornamento: se varia il prezzo unitario di un articolo, occorre aggiornare tutte le t-uple in cui compare, con i relativi totali. Verifichiamo le dipendenze funzionali dalla chiave primaria, composta dagli attributi CodOrdine e CodProdotto: CodOrdine CodCliente CodOrdine, CodProdotto DataOrdine, Quantità CodProdotto PrezzoUnit, Descrizione L attributo CodCliente dipende solo da CodOrdine e non dal prodotto ordinato, così come DataOrdine. Quantità, invece, dipende sia dall ordine che dal prodotto, infatti, nello stesso ordine ci sono articoli con quantità diverse; lo stesso articolo compare in ordini diversi con quantità differenti. Questo significa che, se si indica l ordine di codice 1, non si ottiene una sola quantità, ma più d una (25, 120, 100); analogamente, se si indica l articolo A023 si ottengono le quantità 25 e 120. Se, invece, si indicano l ordine 1 e l articolo A023, si ottiene solo la quantità 25. PrezzoUnit e Descrizione dipendono solo da CodProdotto. Per risolvere questi problemi, si deve scomporre la relazione in relazioni più semplici, ciascuna relativa a una data categoria: gli ordini, i prodotti e i prodotti ordinati. Le relazioni devono essere collegate tramite le chiavi primarie. Il nuovo schema relazionale che soddisfa la seconda forma normale è, pertanto, il seguente: PRODOTTIORDINATI(CodOrdine, CodProdotto, Quantità) PRODOTTI(CodProdotto, PrezzoUnit, Descrizione) ORDINI(CodOrdine, DataOrdine, CodCliente) È facile verificare che ora le anomalie non sono più presenti e che, attraverso le chiavi primarie è possibile reperire tutte le informazioni. In generale, quindi, si deve fare in modo che tutti gli attributi non chiave in uno schema di relazione dipendano funzionalmente dall intera chiave primaria. Per normalizzare si procede in questo modo: nello schema originario rimangono la chiave primaria e tutti gli attributi non chiave, se ci sono, che dipendono completamente da essa; 19

20 si crea un nuovo schema di relazione per ogni parte di chiave primaria da cui dipendono completamente altri attributi non chiave. Per consolidare le conoscenze e applicare i precedenti punti, facciamo un esempio generico. Consideriamo lo schema di relazione: R(A, B, C, D, E) con le seguenti dipendenze funzionali: A, B C A D B E Gli attributi D ed E non dipendono dall intera chiave, pertanto la relazione non è in 2FN. Decomponiamo cominciando dalla dipendenza A D. Dobbiamo costruire due nuove relazioni: una prima relazione R1 che comprende tutti gli attributi presenti nella dipendenza funzionale che viola la 2FN. In questa relazione il determinante della dipendenza funzionale diventa, così, la chiave della nuova relazione; una seconda relazione R2 composta dagli attributi di R1 privati dell attributo che dipende parzialmente dalla chiave. Otteniamo, quindi: R1(A, D) R2(A, B, C, E) Il processo non può terminare poiché è presente l altra dipendenza funzionale B E. Applicando ancora il procedimento di decomposizione otteniamo: R3(B, E) R4(A, B, C) Le relazioni R1, R3 e R4 rappresentano la decomposizione di R(A, B, C, D, E) in 2FN. 5.3 La terza forma normale (3FN) Una relazione R è in terza forma normale (3FN) se è in 2FN e ogni attributo non chiave dipende direttamente dalla chiave. In altri termini, la relazione R non deve possedere attributi non chiave che dipendano funzionalmente da altri attributi non chiave. La 3FN elimina la dipendenza transitiva degli attributi dalla chiave. Diamo una definizione di dipendenza transitiva in modo da ben comprendere questa nuovaforma normale: Data una relazione con attributi A, B e C e con chiave primaria A: se C dipende funzionalmente dal determinante B, a sua volta funzionalmente dipendente da A; se il determinante B non è una chiave candidata della relazione, alternativa ad A; allora C ha una dipendenza funzionale transitiva da A. Riprendiamo lo schema di relazione visto nella lezione precedente e aggiungiamo alla relazione ORDINI la ragione sociale del cliente: ORDINI(CodOrdine, CodCliente, RagSociale) 20

21 Possiamo osservare che anche in questo caso ci sono delle anomalie: anomalia in inserimento: non è possibile inserire la ragione sociale relativa a un cliente sino a quando quest ultimo non compare in un ordine (ciò perché la chiave primaria della relazione è CodOrdine e non può mai essere nulla); anomalia in cancellazione: se si cancella, ad esempio, la quarta t-upla si perde l informazione che il cliente di codice C3 ha ragione sociale Accessori per tutti; anomalia in aggiornamento: se varia la ragione sociale di un certo cliente, occorre aggiornare tutte le t-uple interessate. Questi problemi sono dovuti al fatto che la ragione sociale, in effetti, è indipendente dal codice dell ordine e dipende solo dal codice del cliente: CodCliente RagSociale Siamo quindi di fronte al caso in cui un attributo non chiave (RagSociale) dipende da un altro attributo non chiave (CodCliente). Lo schema deve essere, pertanto, trasformato nel seguente: ORDINI(CodOrdine, CodCliente) CLIENTI(CodCliente, RagSociale) In generale si deve fare in modo che, in uno schema di relazione, tutti gli attributi non chiave dipendano direttamente (non transitivamente) dall intera chiave primaria. Per normalizzare si procede in questo modo: nello schema originario rimangono la chiave primaria e tutti gli attributi non chiave che dipendono direttamente da essa; si crea un nuovo schema di relazione per ogni attributo da cui dipendono altri attributi non chiave. Per consolidare le conoscenze e applicare i precedenti punti, facciamo un esempio generico. Consideriamo il seguente schema di relazione: con le seguenti dipendenze funzionali: R(A, B, C, D, E) A B A E B C B D Si evince facilmente che A C e A D transitivamente. Questa relazione, quindi, non è in 3FN: procediamo alla decomposizione. Consideriamo la dipendenza funzionale B C; otteniamo le due seguenti relazioni: R1(B, C) R2(A, B, D, E) Il processo non può terminare poiché è presente l altra dipendenza funzionale B D. Applicando ancora il procedimento di decomposizione otteniamo: R3(B, D) R4(A, B, E) Le relazioni R1, R3 e R4 rappresentano la decomposizione di R(A, B, C, D, E) in 3FN. 21