Sistemi di Elaborazione delle Informazioni Mod.I

Sistemi di Elaborazione delle Informazioni Mod.I

Corso di Sistemi di Elaborazione delle Informazioni '05 Mod.I Ing. L.Testa

DB relazionali

• Basati su un modello fondato sulla teoria matematica delle relazioni tra insiemi

• Si usa un modello matematico dei dati -> si possono usare linguaggi e metodologie formali per l’accesso ai dati

• Es. metodologie, su cui si basano i linguaggi, per l’accesso ad un DB relazionale: algebra relazionale, calcolo relazionale


Modello relazionale

• Nel modello logico relazionale i dati vengono rappresentati basandosi sul concetto di relazione.

• Relazione algebrica, no mod concettuale


Relazione algebrica

• Dati n insiemi di valori finiti D1..Dn, una relazione R tra questi insiemi è un insieme di n-uple <d1,d2..dn> : (d1 appartiene D1 etc.)

Dove:

D1..Dn = domini

nomi D1..Dn = attributi

n = grado della relazione


tabelle

Per comodità di rappresentazione -> relazione in forma tabellare

I concetti precedenti si traducono in:

Tabelle, righe, colonne

Quindi:

1. In una tabella non possono esistere 2 righe uguali

2. L’ordine tra righe non è significativo


tabelle

1. -> servono un insieme di attributi in base ai quali identificare le singole righe : chiave primaria


Dallo schema concettuale allo schema logico

• Entità -> tabelle

• Relazioni -> chiavi esterne





Esempio schema logico




Normalizzazione

• Una forma normale è una proprietà di una base di dati relazionale che ne garantisce la “qualità”, cioè l'assenza di determinati difetti

• Quando una relazione non è normalizzata: – presenta ridondanze,– si presta a comportamenti poco desiderabili durante

gli aggiornamenti

• Le forme normali sono di solito definite sul modello relazionale, ma hanno senso in altri contesti, ad esempio il modello E-R


Normalizzazione

• Procedura che permette di trasformare schemi non normalizzati in schemi che soddisfano una forma normale

• La normalizzazione va utilizzata come tecnica di verifica dei risultati della progettazione di una base di dati

• Non costituisce una metodologia di progettazione


Una relazione con anomalie

Impiegato Stipendio Progetto Bilancio Funzione

Rossi 20 Marte 2 tecnicoVerdi 35 Giove 15 progettistaVerdi 35 Venere 15 progettistaNeri 55 Venere 15 direttoreNeri 55 Giove 15 consulenteNeri 55 Marte 2 consulenteMori 48 Marte 2 direttoreMori 48 Venere 15 progettista

Bianchi 48 Venere 15 progettistaBianchi 48 Giove 15 direttore


Anomalie• Lo stipendio di ciascun impiegato è ripetuto in tutte le

ennuple relative– ridondanza

• Se lo stipendio di un impiegato varia, è necessario andarne a modificare il valore in diverse ennuple – anomalia di aggiornamento

• Se un impiegato interrompe la partecipazione a tutti i progetti, dobbiamo cancellarlo– anomalia di cancellazione

• Un nuovo impiegato senza progetto non può essere inserito– anomalia di inserimento


Perché questi fenomeni indesiderabili?

• abbiamo usato un'unica relazione per rappresentare informazioni eterogenee

– gli impiegati con i relativi stipendi– i progetti con i relativi bilanci – le partecipazioni degli impiegati ai progetti

con le relative funzioni


Prima FN

• Una colonna non può contenere una struttura vettoriale

->vanno create tante righe quanti sono i valori della struttura vettoriale


Seconda FN

• Per chiavi primarie con più attributi, tutte le colonne relative agli altri attributi devono dipendere dall’intera chiave primaria

->si introducono nuove tabelle che soddisfino la condizione sopra indicata


Seconda FN


Terza FN

• Non devono esistere dipendenze tra le colonne di una tabella se non basate sulla chiave primaria

->si introducono nuove tabelle che soddisfino la condizione sopra indicata


Terza FN

Documents

Sistemi di Elaborazione delle Informazioni Mod.I