Lezione basi di dati 26 gennaio NORMALIZZAZIONE

Transcript

1 Lezione basi di dati 26 gennaio NORMALIZZAZIONE Serve perché nelle tabelle possono verificarsi delle anomalie (come delle ridondanze ad esempio) Immaginiamo questa tabella: 1 La chiave non può contenere nulli 2 Se vado ad aggiornare un impiegato modificando ad esempio la tariffa oraria (ANOMALIA DI AGGIORNAMENTO) Immaginiamo che ci sia un altra riga dove ci sia il titolo di studio di un impiegato: se il mio impiegato ha preso la laurea specialistica devo modificare tutta la tabella, quindi mi conviene creare una tabella a parte per evitare ridondanze e ottimizzare il mio progetto. 3 Se voglio cancellare un impiegato dal mio DB ho degli effetti di bordo (ANOMALIA DI CANCELLAZIONE) Ad esempio voglio cancellare il signor Bernardi, ma perdo come informazione importante il numero di or svolte da quella persona per quel progetto, e quindi se volessi sapere in totale quante ore ho fatto complessivamente con tutti gli impiegati non posso. 4 Se volessi aggiungere un impiegato senza avergli ancora assegnato un progetto, devo necessariamente creare una tabella di dumping (temporanea) perché altrimenti mi creerebbe incongruenze nella tabella principale (ANOMALIA DI INSERIMENTO) Se ho una tabella con tutte le righe PIENE (e se abbiamo eliminato il problema dei gruppi ripetitivi) viene detta Tabelle in forma normale TIPOOGIE DI NORMALIZZAZIONI: - Prima forma normale: se non vi sono gruppi ripetitivi di attributi all interno della struttura dati - Seconda forma normale: se ogni attributo dipende pienamente dalla chiave - Terza forma normale: se ogni attributo non dipende dagli altri attributi

2 Con questo schema ho degli attributi che dipendono tra loro. Questa tabella non è in seconda forma normale, quindi un organizzazione più appropriata di questa tabella risulta esser la seguente, con la divisione della prima tabella in tre tabelle: Impiegato, Progetto ed Assegnazione.

3 Questo problema potrebbe presentarsi se ad esempio nel modello concettuale avevamo messo una relazione molti a molti errata. NB: Nella tabella Impiegato non ci sono ridondanze, ma soltanto se la Funzione è unica per ogni impiegato, che non po svolgere più funzioni contemporaneamente all interno dello stesso progetto. Osservazione: in effetti la Tariffa Oraria può dipendere da Funzione, quindi per eliminare anche questa dipendenza (per mettere cioè tutta la tabella in terza forma normale, priva di dipendenze tra attributi), posso scomporre la tabella in altre due tabelle, la prima con Cod. Impiegato, Nome e Codice lavoro, mentre la seconda con Codice Lavoro, Funzione, Tariffa. Spesso però scomporre troppo le tabelle non è necessario, perché la seconda tabella ottenuta potrebbe non darmi alcuna informazione utile, mentre in altri casi se devo aggiornare una tariffa oraria per una funzione mi conviene utilizzarla piuttosto che aggiornare tutte le righe avendo uno spreco di tempo notevole. Dipende tutto da cosa voglio progettare.

4 La terza forma normale e questa forma sono equivalenti. In particolare questa forma si presenta se nel progetto abbiamo chiavi composte o comunque più chiavi all interno di una stessa tabella. Esempio di tabella non in forma di Boyce Codd: Se ad esempio infatti ho un area di 2000 acri so di certo che sto parlando della contea B, stessa cosa per 50 acri che mi riconduce alla contea B.

5 Per migliorare questa forma basta agire in questo modo: Alcune tabelle non sono ricomponibili in forma di Boyce Codd. Esempio: Abbiamo un azienda con diverse sedi, con dei dirigenti (ciascuno in una sola sede), ed un dirigente dirige un progetto che però può avere diverse localizzazioni DIRIGENTE PROGETTO SEDE ROSSI ALFA ROMA VERDI BETA CATANIA VERDI ALFA CATANIA NERI GAMMA CATANIA NERI DELTA CATANIA Come risolvo il problema? Non posso eliminare la ridondanza perché se decomponessi la tabella ulteriormente non riuscirei a mantenermi tutte le dipendenza. Quando divido le tabelle in definitiva devo sempre controllare di poter tornare indietro con una ricongiunzione della tabella, verificando che non si creino delle righe spurie.

6 (esempio _10.ppt) IMPIEGATO PROGETTO SEDE ROSSI MARTE ROMA VERDI GIOVE MILANO VERDI VENERE MILANO NERI SATURNO MILANO NERI VENERE MILANO Potrei dividerla in: IMPIEGATO SEDE PROGETTO SEDE ROSSI ROMA MARTE ROMA VERDI MILANO GIOVE MILANO NERI MILANO SATURNO MILANO VENERE MILANO Se volessi ricostruire la tabella originale troverò più righe (provare la join) DECOMPOSIZIONE SENZA PERDITA: (rivedere) Riepilogo: quando ho una chiave normale non ho problemi, mentre se ne ho una composta se al massimo non riuscissi a ricondurmi ad una forma Boyce Codd posso sempre arrivare ad una terza forma normale. Nella pratica dobbiamo sempre accertarci di essere in forma normale, verificando che tornando indietro i risultati della join restituiranno la tabella originale. DENORMALIZZAZIONE Si utilizzano in questi casi: - Quando all aumentare della normalizzazione aumenta il numero di tabelle nel database. - Quando fare il join rallenta il sistema. A volte si opta per un certo grado di denormalizzazione.

7 CONSIGLI UTILI PER L ESAME A cosa fare attenzione per il compito: - Semantica degli attributi utili - Ridurre i valori ridondanti (link attributi derivati: mi conviene calcolarlo un attributo o averlo già?) - Riduzione del numero di valori nulli (soprattutto per le generalizzazioni) - Non decomporre in modo esagerato arrivando a generare tuple spurie Altri consigli: - Evitare relazioni che corrispondono a miscugli di più entità - Gli schemi di relazione devono essere tali da evitare anomalie di inserimento, cancellazione o modifica - Non mettere attributi il cui valori nulli - Non mettere. che non siano chiavi La qualità del progetto si basa su: - Correttezza - Completezza - Leggibilità - Minimalità (controllare il numero i cicli nel progetto) - Stima sul volume dei dati e sul numero delle transazioni - Ottimizzazione Schema del compito: - Descrizione - Modello concettuale - Tabelle (modello logico) - Normalizzazione (ci può dare una tabella e chiederci se è in forma normale)

8 ESERCIZIO AGENZIA IMMOBILIARE - gli immobili oggetto degli affitti. Di tali immobili interessa ricordare: l indirizzo, prezzo richiesto dal proprietario per la vendita o per l affitto annuo, i metri quadri. Gli immobili possono essere di due tipi: abitazioni ed uffici. Per le abitazioni si vuole anche memorizzare il numero di vani. - Coloro che prendono in affitto gli immobili, che possono essere persone fisiche o società/enti. Di questi si vogliono memorizzare informazioni sul codice fiscale, la partita IVA (se applicabile), nome, cognome se persone fisiche, o la denominazione societaria (se società/enti). - Coloro che danno in affitto gli immobili. Anche questi possono essere persone fisiche o società (stessa impostazione i chi le affitta) - I contrati di affitto. Dati, numero registrazione, nome e cognome del notaio che ha stipulato, prezzo di vendita dell immobile (se venduto) o di affitto (se affittato) Possiamo vedere anche se conviene in realtà dividere il contratto in contratto di vendita e contratto di affitto. E ancora da completare in tutti gli attributi, ed è u progetto solo guida, non è necessariamente l unica soluzione possibile, ma appare comunque tra le migliori. Completare l esercizio anche con le tabelle per descrivere la vendita.

9 POSSIBILE SOLUZIONE LOGICA Soluzione 1: - Creare 2 tabelle: Proprietari e Affittuari - Hanno struttura identica - Alcuni clienti possono trovarsi in entrambe le tabelle - Può essere immediato fare alcuni tipi di query (Es: genera la lista degli immobili) Soluzione 2: - Oppure crearne una sola Clienti - Si può aggiungere un campo che indica se quel cliente è anche un proprietario - E ridondante però facilitare la query (altrimenti si dovrebbe fare una join con la tabella degli immobili sul campo ID Proprietario) Soluzione 1 -> Se si fanno poche query con le join Soluzione 2 -> Se si fanno con frequenza maggiore le query su chi è il proprietario o l affittuario, ma si dovrebbe fare comunque una join con la tabella degli immobili. Dall associazione interna nasce la tabella dei contratti: - Contratto (id affittuario, id immobile, data inizio locazione, id proprietario, data fine, canone, notaio, data firma contratto) Notaio è superfluo, provare in modo diverso ad organizzare il progetto logico. In realtà id immobile determina il proprietario, ma conviene metterlo se voglio generare efficientemente informazioni complete sui contratti. NB: Questa tabella però non è del tutto normalizzata perché ci sono molti legami tra attributi. Se metto un attributo disponibile per immobile, è ridondante perché posso sempre creare una procedura per ricavare questo dato, ma è comunque più conveniente perché consuma meno prestazioni.

10 ESERCIZIO 2 Pagina 9 compito 26 marzo 2001 (fare per casa) Appunti presi da Alessio Regalbuto per appuntiunict.rv89.com