Microsoft's Internet Explorer browser has no built-in vector graphics machinery required for "loss-free" gradient background themes.

Please upgrade to a better browser such as Firefox, Opera, Safari or others with built-in vector graphics machinery and much more. (Learn more or post questions or comments at the Slide Show (S9) project site. Thanks!)

R-DBMS - Introduzione ai database relazionali liberi

La progettazione logica - Diagramma relazionale

Master "Tecnologie OpenSource"

Argomenti della lezione

  • La modellazione logica: il diagramma relazionale
  • Mappatura tra diagramma ER e diagramma Relazionale
  • Linee guida per la progettazione
  • Anomalie di funzionamento
  • Normalizzazione
  • Dipendenza funzionale
  • 1NF, 2NF, 3NF e BCNF
  • Altre forme normali

Modellazione logica

La modellazione logica tende a tradurre il modello concettuale in un DDL (Data Definition Language), interpretabile dal DBMS

Nei database relazionali la modellazione logica si basa sul modello relazionale, che fu introdotto nel 1970 da Edgard F. Codd nei laboratori IBM, e incontrò subito grandi attenzioni per la sua semplicità e per le basi matematiche su cui si basa (relazioni matematiche, teoria degli insiemi, logica dei predicati).

In questo modello il database è rappresentato come una collezione di relazioni o tabelle di valori. Ogni riga della tabella (tupla) corrisponde ad un insieme di dati correlati.

Nota: il passaggio da modello concettuale a logico può essere realizzato in forma algoritmica.

Diagramma relazionale

Il diagramma relazionale è tra le più note e utilizzate metodologie per la modellazione logica di un database relazionale.

Il diagramma relazionale è una rappresentazione schematica dei seguenti elementi:

Conversione da ER a diagramma relazionale

Il passaggio dal modello concettuale (diagramma ER) al modello logico (diagramma relazionale) è un’operazione ben definita e chiusa.

Tale mappatura è caratterizzata dalle seguenti proprietà:

Algoritmo di mappatura: step 1

Mappatura dei tipi di entità regolari (strong)

Per ciascun tipo di entità regolare nel diagramma ER occorre creare una relazione nel diagramma relazionale.

Questa relazione dovrà essere caratterizzata da:

Una volta creata in questo modo una relazione, occorre scegliere uno degli attributi chiave della relazione (o un gruppo di attributi), e indicarlo come chiave primaria

Es.: AUTOMOBILE (N° telaio, Marca, Modello, Colore)

Algoritmo di mappatura: step 2

Mappatura dei tipi di entità deboli (weak)

Per ogni tipo di entità debole W del diagramma ER, che dipende dal tipo di entità regolare E, occorre creare una relazione R che contenga:

La chiave primaria di una siffatta relazione sarà la combinazione della chiave esterna e della chiave parziale di R.

Es.: AUTOMOBILE (N° telaio, Marca, Modello, Colore), FOGLIO_IMMATRICOLAZIONE (N° telaio, Protocollo, Data)

Algoritmo di mappatura: step 3

Mappatura di relazioni binarie 1:1

Siano W e V i due tipi di entità che partecipano nella relazione 1-1 R. Siano S e T le relazioni (nel modello relazionale) che derivano da W e V.

Per mappare la relazione 1:1 è sufficiente scegliere (in modo arbitrario) una delle relazioni (ad esempio S) ed aggiungervi una chiave esterna che punti alla chiave primaria dell’altra relazione coinvolta (nel nostro caso T)

Nota: un metodo alternativo per mappare una relazione 1:1 è unire le due relazioni S e T in un’unica nuova relazione che contenga tutti gli attributi di S e di T. Questa metodologia è particolarmente indicata in casi di relazioni di partecipazione totale da entrambi i lati.

Es.: REPARTO (Nome, Dislocazione), DIPENDENTE (CF, Nome, Cognome)

Algoritmo di mappatura: step 4

Mappatura di relazioni binarie 1:N

Siano S e T le due relazioni derivanti dai tipi di entità W e V. Per mappare una relazione con molteplicità 1:N occorre individuare l’entity type che partecipa alla relazione dal lato N ed aggiungere alla relazione corrispondente (ad es. T) una chiave esterna che punti alla chiave primaria della relazione sul lato con molteplicità 1. La giustificazione di tale mappatura sta nel fatto che ad ogni tupla di S possono corrisponere una o più istanze di T.

Nota: se la relazione (nel diagramma ER) presenta degli attributi essi vanno aggiunti alla relazione (nel diagramma relazionane) sul lato N.

Es.: PERSONA (CF, Nome, Cognome, Data di nascita), PATENTE (N° documento, Tipo, Data emissione)

Algoritmo di mappatura: step 5

Mappatura di relazioni binarie N:M

Per ogni relazione R tra W e V con molteplicità N:M (nel modello ER), occorre creare una nuova relazione S (nel modello relazionale) che la rappresenti. Questa relazione sarà caratterizzata da:

Nota: la chiave primaria di S è costituita dalla composizione delle due foreign keys

Es.: AUTORE (CF, Nome, Cognome), SCRIVE (Data), LIBRO (ISBN, Titolo, Costo)

Algoritmo di mappatura: step 6

Mappatura di attributi multipli

Per mappare un attributo multiplo occorre trattarlo come una relazione con molteplicità 1:N. È pertanto sufficiente creare una relazione R che rappresenti l’attributo, con una chiave esterna che punta alla chiave primaria del tipo di entità che possiede tale attributo.

Es. PERSONA (CF, Nome, Cognome), N_TELEFONO (Tipo, Numero)

Algoritmo di mappatura: step 7

Mappatura di relazioni n-arie

Siano W1, W2, …, Wn n tipi di entità coinvolti nella relazione n-aria R. Per mappare R nel modello relazionale occorre definire una nuova relazione S tale che:

Nota: la chiave primaria di S è data dalla concatenazione di tutte le foreign keys

Es.: AUTORE (CF, Nome, Cognome), LIBRO (ISBN, Titolo), CASA_EDITRICE (Nome, Città)

Algoritmo di mappatura: step 8

Mappatura di specializzazioni/generalizzazioni

La mappatura di una specializzazione/generalizzazione può avvenire in 4 modi differenti:

Algoritmo di mappatura: step 9

Mappatura di unioni/categorie

La mappatura di una categoria consiste nella creazione di una nuova relazione che abbia come attributi:

Es. NUCLEO (Coordinate, Altimetria, Abitanti), COMUNE (Superficie, Abitanti), PROVINCIA (Superficie, Abitanti), LOCALITA () → TOPONIMO (Nome, Anno)

Linee guida per la progettazione

Nella progettazione di un buon DB relazionale occorre tenere presente quattro linee guida informali:

Anomalie di funzionamento

Le anomalie di funzionamento possono essere raggruppate in tre categorie:

Normalizzazione

La normalizzazione è un processo volto all’eliminazione della ridondanza e del rischio di incoerenza dal database. Esistono vari livelli di normalizzazione (forme normali) che certificano la qualità dello schema del database.

In altre parole la normalizzazione è un modo per assicurare in maniera sistematica che il database risulti ben progettato, adatto a qualsiasi tipo di interrogazioni successive, e non presenti caratteristiche poco desiderabili quali:

La normalizzazione è stata formalizzata dallo stesso inventore del modello relazionale (E. Codd) tra gli anni 1970 e 1974.

Dipendenze funzionali (1/2)

La dipendenza funzionale è il concetto principale su cui si fonda tutta la teoria dei database relazionali. Essa è, in parole semplici, un vincolo tra due insiemi di attributi del database

Formalmente possiamo definirla nel seguente modo:

Si ha una dipendenfa funzionale X→Y se t1[X] = t2[X] => t1[Y] = t2[Y]

In altri termini si ha una dipendenza funzionale quando un gruppo di attributi dipende da un altro gruppo di attributi. Ad es, per la relazione PERSONA (CF, Nome, Cognome, Data_nascita, Altezza) si ha CF→{Nome, Cognome, Data_nascita}

Dipendenze funzionali (2/2)

Le dipendenze funzionali non sono caratteristiche intrinseche di un particolare modello relazionale, ma, essendo dei vincoli su gruppi di attributi, devono essere definite da chi progetta la base dati.

Per come è definito il modello relazionale (ogni entity set non può contenere due tuple uguali), per ciascuna relazione esiste sempre almeno una dipendenza funzionale tra la chiave primaria e ciascun attributo che non ne faccia parte.

La normalizzazione è un processo basato sulla divisione di grosse relazioni in relazioni più piccole, in cui non ci siano dipendenze funzionali tra gruppi di attributi non chiave.

Prima forma normale

Una base di dati si dice in prima forma normale se tutte le sue relazioni sono in 1NF. Una relazione è in 1NF se:

  • tutti gli attributi sono atomici (non presenta attributi che si ripetono)
  • esiste ed è definita una chiave primaria

Nota: la 1NF fu introdotta inizialmente da Codd per scongiurare l’uso di attributi non atomici; è stata successivamente inglobata nella definizione stessa di modello relazionale. Tutti i modelli relazionali ottenuti con l’algoritmo dedscritto in precedenza sono in 1NF.

Seconda forma normale

Una base dati è invece in 2NF (seconda forma normale) quando è in 1NF e per ogni tabella tutti i campi non chiave dipendono funzionalmente dall’intera chiave primaria e non da una parte di essa.

Es.: supponiamo di avere una tabella con gli esami sostenuti dagli studenti universitari. I campi di interesse potrebbero quindi essere cod_corso_laurea, cod_esame, matricola, data e voto, con i primi tre chiave primaria (composta).

Una tabella così modellata è in 2NF, infatti se un attributo non chiave dipendesse da un sottoinsieme della chiave primaria, si perderebbero informazioni…

Terza forma normale

Definizione: Una base dati è in 3NF (terza forma normale) se è in 2NF e per ogni dipendenza funzionale X→Y è vera una delle seguenti condizioni:

Nota: esiste un teorema che garantisce l’esistenza di una terza forma normale per ciascun modello relazionale

Forma normale di Boyce-Codd

Una relazione R è in forma normale di Boyce e Codd (BCNF) se e solo se è in 1NF e, per ogni dipendenza funzionale X→Y, X è una superchiave per R.

Dato un insieme di relazioni, non è possibile garantire sempre il raggiungimento della BCNF; in particolare il mancato raggiungimento di questo obiettivo è indice che la base dati è affetta da un’anomalia di cancellazione (ossia è possibile perdere dati a seguito di un’operazione di cancellazione).

Nota: la BCNF fu introdotta nel 1974 da Boyde e Codd, come semplificazione della 3NF. In seguito si dimostrò che tale forma normale era in realtà più restrittiva della 3NF.

Processo di normalizzazione

La forme normali presentate sono dette, per come sono definite, “basate sulla chiave primaria”. Segue una tabella riassuntiva dei test per verificare se una relazione sia o meno in 1°, 2° e 3° NF e gli eventuali riarrangiamenti da applicare alla relazione in esame:

NF Test Rimedio
Una relazione non dovrebbe avere attributi non atomici Definire una nuova relazione per ogni attributo non atomico
In una relazione con chiave primaria non atomica, ogni attributo non chiave non dovrebbe dipendere da una parte della chiave primaria Decomporre la relazione in sottorelazioni ciascuna con chiave parziale e attributi da essa funzionalmente dipendenti
Una relazione non dovrebbe avere un attributo non chiave funzionalmente dipendente da un altro attributo non chiave Creare una nuova relazione che includa l’attributo non chiave che determina il valore di altri attributi

Quarta e quinta forma normale

Negli anni sono state introdotte altre due forme normali: la quarta e la quinta (anche in questo caso si tratta di processi di modifica delle relazioni incrementali)

Tuttavia queste normalizzazioni, nonostante il loro valore teorico, nella pratica vengono utilizzate raramente, in quanto ad un incremento di rigore nell’eliminazione della ridondanza corrisponde un degrado delle prestazioni (query di selezione o, peggio, modifica dei dati, richiedono molto più tempo per l’esecuzione).

Case study: DB aziendale

Determinare il modello relazionale corrispondente al seguente diagramma ER:

Copyright (C) 2008 - Alca Societa' Cooperativa

http://alca.le.it - info@alca.le.it

released under CreativeCommons 2.5 by-nc-sa

NOTA: le immagini dei software e dei device contenuti
nella presentazione sono proprieta' dei relativi detentori
del copyright e sono state riprodotte a scopo esclusivamente didattico.