Progettazione database relazionali

PROGETTAZIONE
DATABASE
1
ROBERTO BELMONTE
LinkedIn:
https://it.linkedin.com/in/robertobelmonte

Progettazione e modernizzazione database in ambiente "DB2 for i" – Contenuti:
 Progettazione del Modello Concettuale di una Base Dati con l’utilizzo del
metodo Entity-Relationship model (E/R).
 Progettazione del Modello Logico di una Base Dati a partire dal Modello
Concettuale.
 Normalizzazione in Terza Forma Normale del modello Relazione di una Base
Dati.
 Modernizzazione di una Base Dati in ambiente IBM i e "DB2 for i" .
2
PROGETTAZIONE DATABASE
Fasi e Metodologia
Roberto Belmonte - LinkedIn:

Progettazione Basi Dati - Ciclo di Vita di un Sistema Informativo :
Studio di fattibilità
Raccolta e analisi
dei requisiti
Realizzazione
Validazione e
collaudo
Funzionamento
Progettazione
dei dati
La Progettazione delle Base di Dati
é una delle attività del processo di
sviluppo dei Sistemi Informativi (SI),
va quindi inquadrata in un contesto
più generale del ‘Ciclo di Vita dei
Sistemi Informativi’ che sono:
• Insieme delle attività svolte da
analisti, progettisti, manager,
nello sviluppo e nell’uso dei
sistemi informativi.
• Attività iterativa, quindi Ciclo.
3
Fasi e Metodologia

requisiti del
Sistema informativo
progettazione concettuale
progettazione logica
progettazione fisica
SCHEMA LOGICO
SCHEMA CONCETTUALE
SCHEMA FISICO
applicazioniutenti
interattivi
DBMS
Base Dati
La metodologia introdotta prevede 3 fasi:
Progettazione concettuale
Progettazione logica
Progettazione fisica
La fase di raccolta e analisi dei requisiti in pratica
viene ad essere svolta congiuntamente a quella di
progettazione concettuale
Ognuna delle fasi si basa su un modello, che
permette di generare una rappresentazione
formale (schema) della base di dati ad un dato
livello di astrazione (concettuale, logico e fisico):
Schema concettuale
Schema logico
Schema fisico
4
Fasi e Metodologia

 È la fase in cui si raccolgono e analizzano le specifiche informali ed eterogenee che i vari utenti danno
delle procedure da automatizzare mediante un DBMS
 requisitiinformativi: caratteristiche dei dati
 requisiti sui processi: operazioni sui dati
 requisiti sui vincoli di integrità: proprietà dei dati e delle operazioni
 Attività principali:
 Costruzione glossario dei termini
 Eliminazione delle ambiguità (sinonimi, omonimi)
 Raggruppamento dei requisiti “omogenei”
 Fase solo apparentemente semplice, nella realtà è spesso la più complessa perché è difficilmente
standardizzabile il processo che porta a
capire cosa gli utenti vogliono!
5
Fase di raccolta e analisi dei requisiti

 A partire dai requisiti informativi viene creato uno schema concettuale, cioè una descrizione
formalizzata e integrata delle esigenze aziendali, espressa in modo indipendente dal DBMS adottato
 A tale scopo si adotta un modello concettuale, che permette di fornire descrizioni ad alto livello
indipendenti dall'implementazione
 Lo schema concettuale è indipendente anche dal tipo di DBMS che sarà utilizzato (relazionale, gerarchico,
ecc.)
6
Fase di progettazione concettuale

 Consiste nella traduzione dello schema concettuale nel modello dei dati del DBMS
 Il risultato è uno schema logico, espresso nel DDL del DBMS
 In questa fase si considerano anche aspetti legati a:
 integrità e consistenza (vincoli)
 efficienza
 La progettazione logica si articola in due sotto-fasi:
 ristrutturazione dello schema concettuale
 traduzione verso il modello logico
7
Fase di progettazione logica

 In questa ultima fase si operano scelte spesso strettamente dipendenti dallo specifico DBMS utilizzato
 Ad esempio, lo stesso schema logico può essere fisicamente rappresentato in modo diverso in DB2 e in
Oracle, al fine di meglio sfruttare le caratteristiche dei due DBMS
 Il risultato è lo schema fisico, che descrive le strutture di memorizzazione e accesso ai dati (tablespace,
clustering, indici, ecc.)
8
Fase di progettazione fisica

Un modello dei dati è una collezione di concetti che vengono utilizzati per descrivere i dati, le loro
associazioni, e i vincoli che questi devono rispettare.
Un ruolo di primaria importanza nella definizione di un modello dei dati è svolto dai meccanismi che possono essere usati
per strutturare i dati.
 Modelli Logici: utilizzati nei DBMS esistenti per l’organizzazione dei dati utilizzati dai programmi, indipendenti dalle
strutture fisiche.
 Modelli Concettuali: permettono di rappresentare i dati in modo
indipendente da ogni sistema.
 cercano di descrivere i concetti del mondo reale
 sono utilizzati nelle fasi preliminari di progettazione
I l p i ù n o t o m o d e l l o C o n c e t t u a l e è :
E n t i t y - R e l a t i o n s h i p m o d e l ( E / R ) ( C h e n 1 9 7 6 )
9
Modelli dei dati: logici vs concettuali

 La progettazione di un sistema informativo è guidata dai dati, e si avvale di una metodologia che consta di
diverse fasi
 Ogni fase produce uno schema, facendo uso di uno specifico modello
 Per la progettazione concettuale si fa uso di un modello concettuale che, astraendo da aspetti
specifici dei DBMS e dalla rappresentazione concreta dei dati, costituisce un valido compromesso tra ciò che
si dovrà realizzare e la realtà che si deve modellare
10
Riassumiamo

 Cerchiamo quindi un livello di astrazione “intermedio” tra sistema e utenti,
che sia al tempo stesso:
 Flessibile
 Intuitivo
 Espressivo
… tutte caratteristiche che mancano ai modelli logici
 I modelli concettuali prevedono tipicamente una
rappresentazione grafica, che risulta anche utile come
strumento di documentazione e comunicazione
Modello
Schema
11
Creare il Modello Concettuale dei Dati

 Uno “standard de facto” per la progettazione concettuale
 Ha una rappresentazione grafica
 Concetti fondamentali:
 Entità (entity)
 Associazione (relationship)
 Attributo
 Vincolo di cardinalità
 Identificatore
 Gerarchia
12
Il Modello Entity-Relationship

Quando ragioniamo su un problema usiamo sempre, in funzione del tipo di problema da risolvere, dei procedimentali mentali
di un certo tipo per arrivare alla soluzione, ovvero astraiamo dal caso specifico per ricondurci a un “pattern” più generale che
conosciamo.
Quindi l’Astrazione é il procedimento mentale che si adotta quando si concentra l’attenzione su alcune caratteristiche,
trascurando le altre giudicate non rilevanti.
Nel nostro caso i meccanismi fondamentali di astrazione sono:
 Classificazione: identifica classi di oggetti del mondo reale aventi proprietà comuni
 Aggregazione: definisce un nuovo concetto a partire da concetti componenti
 Generalizzazione: definisce una classe astraendo dalle differenze esistenti tra due o più classi
13
Meccanismi di astrazione

 Insieme (classe) di oggetti della realtà di interesse che possiedono caratteristiche comuni (es. persone,
automobili, …) e che hanno esistenza “autonoma”
 L’istanza (elemento) di un’entità è uno specifico oggetto appartenente a quella entità (es. io, la mia auto, …)
 Graficamente un’entità si rappresenta con un rettangolo
Persone Automobili Impiegati
14
Modello E/R: Entità

 Data un’Entità, in prima approssimazione possiamo considerarla “equivalente” a una Relazione , di cui però
non sappiamo ancora definire lo Schema:
Studenti
…. …. …. …. …. …. …. ….
…. …. …. …. …. …. …. ….
Studenti
https://it.wikipedia.org/wiki/Relazione_(matematica)
15
Entità e Relazioni

 Definizione di un concetto (classe) a partire da un insieme di concetti componenti
Studenti
 La Matricola è una parte (part of) dello Studente
 È la tipica astrazione che viene utilizzata quando si definiscono dei record (tuple)
Matricola Cognome Email
16
Astrazione di aggregazione

 Un caso particolarmente interessante è quando i concetti che vengono aggregati sono delle classi che
rappresentiamo come delle entità
Esami
Studenti Corsi
Lezioni
Aule Corsi Orari
17
Aggregazione di classi

 Rappresenta un legame logico tra entità, rilevante nella realtà che si sta considerando
 Istanza di associazione: combinazione (aggregazione) di istanze delle entità che prendono parte
all’associazione
 Graficamente un’associazione si rappresenta con un rombo:
Persone Risiedono Città
 Se ‘p’ è un’istanza di Persone e ‘c’ un’istanza di Città, la coppia (p, c) è un’istanza dell’associazione Risiedono
18
Modello E/R: Associazione

 Un atttributo è una proprietà elementare di un’entità o di un’associazione, graficamente :
Persone
nome
cognome
cod_fiscale
 nome, cognome, cod_fiscale sono tutti Attributi di Persone
 Ogni attributo è definito su un dominio di valori
 Quindi un attributo associa ad ogni istanza di entità o associazione un valore del corrispondente dominio
19
Attributi

 Ancora in modo approssimato, un entità con attributi possiamo considerarla “equivalente” a una Relazione,
di cui ora possiamo definire lo schema :
Matricola Cognome Nome DataNascita Email
29323 Bianchi Giorgio 21/06/1978 gbianchi@alma.unibo.it
Studenti
nome
cognome
data_nascita
matricola
email
35467 Rossi Anna 13/04/1978 anna.rossi@yahoo.it
39654 Verdi Marco 20/09/1979 mverdi@mv.com
Studenti
20
Entità con attributi e relazioni

 È importante fare attenzione a dove si specificano gli attributi!
Studenti Esami
 data e voto non sono proprietà né di uno studente né di un corso, ma del legame Studenti-Corsi che si crea
in occasione di un esame
voto data
Corsi
21
Attributi: dell’entità o dell’associazione?

 Osserviamo che CodCorso è la sola chiave di Corsi, e
quindi anche chiave primaria, e che Matricola è la
chiave primaria di Studenti.
 Possiamo pertanto dire, senza perdita di informazioni,
che :
“Lo studente con numero di matricola 29323 ha superato
con voto 28 il 12 Giugno 2003 l’esame del corso con
codice 483” .
e quindi per l’associazione di fatto dobbiamo
rappresentare solo:
Studenti Esami
voto data
Corsi
matricola codcorso
Matricola Voto Data CodCorso
29323 28 12/06/2003 483
35467 30 15/07/2003 729
39654 26 12/06/2003 913
22
Rappresentare un’associazione

 min-card(Automobili,Proprietà) = 0: esistono automobili non possedute da alcuna persona
 max-card(Automobili,Proprietà) = 1: ogni automobile può avere al più un proprietario
 min-card(Persone,Proprietà) = 0: esistono persone che non posseggono alcuna automobile
 max-card(Persone,Proprietà) = n: ogni persona può essere proprietaria di un numero arbitrario di automobili
Si noti che i vincoli si possono stabilire correttamente solo se è ben chiaro cosa rappresentano le diverse entità (analisi della
realtà!)
Persone Proprietà Automobili
(0,n) (0,1)
23
Vincoli di cardinalità: un esempio

Nella realtà presa in esame da rappresentare ci sono le
consulenze che fanno i professionisti con le aziende, il
sistema dovrà rilevare il numero di consulenze
effettuate dal professionista per ogni azienda con
relativo costo totale.
24
Esercizio di creazione di un modello E/R

Professionista Consulenza Azienda
(0,n) (0,n)
Costo Tot.Numero
Nome Qualifica Indirizzo Nome
25
Soluzione Esercizio di creazione di un modello E/R

Requisiti del
Sistema
Informativo
Progettazione
Concettuale
Schema Concettuale
Schema Logico
Progettazione Logica
Progettazione Fisica
Schema Fisico
Cosa si rappresenta
Come lo si rappresenta
26

 Obiettivo della fase di Progettazione Logica è pervenire, a partire dallo Schema Concettuale, a
uno Schema Logico che lo rappresenti in modo fedele e che sia, al tempo stesso, “efficiente”
 L’efficienza è legata alle prestazioni, ma poiché queste non sono valutabili precisamente a Livello
Concettuale e Logico si deve far ricorso a degli indicatori semplificati per poter confrontare tra loro
diverse alternative di traduzione
 Per quanto detto dividiamo il lavoro in due parti:
 Progettazione Logica “fedele”
 Progettazione Logica “efficiente”
 In ogni caso, a Livello Logico non introduciamo nuova informazione, con la possibile eccezione di
qualche ridondanza (ma questa non è informazione “nuova”)
27

 Si consideri il seguente schema E/R:
Persone Proprietà Automobili
(0,n) (0,1)
Data AcquistoCF Targa
 e lo Schema Relazionale:
Persone(CF)
Auto(Targa)
Proprieta(CF,Targa,DataAcquisto)
FK: CF REFERENCES Persone
FK: Targa REFERENCES Auto
 La traduzione preserva l’informazione, ma ….
CF Targa Data Acquisto
BLGSTR71B22 CT 001 MJ 12/08/2004
Proprietà
FDLNNR66M45 CT 001 MJ 15/07/2003
CF
BLGSTR71B22
FDLNNR66M45
Persone
BSZNTN82L27
28
Problemi nella Progettazione Logica

 La definizione data di equivalenza non è “operativa”, in quanto non dice nulla su come debba essere fatta una traduzione
che garantisca l’equivalenza degli schemi.
 Tuttavia può essere usata “localmente”:
In pratica, la traduzione avviene operando una sequenza di trasformazioni/traduzioni semplici, per ognuna delle quali è
altrettanto semplice dare delle Regole che garantiscono l’equivalenza.
 Per quanto visto, possiamo dividere queste Regole in:
 Regole che preservano l’informazione: Regole sulla Struttura.
 Regole aggiuntive che garantiscono l’equivalenza: Regole sui Vincoli.
 Vedremo che l’equivalenza può solo essere in parte garantita dal DDL di SQL, e quindi c’è bisogno di altro…
29
Progettazione Logica in Pratica

 Consideriamo il caso più semplice in cui:
 Abbiamo entità e associazioni.
 Ogni entità ha un singolo identificatore, ed è interno.
 Non abbiamo attributi ripetuti.
Studenti Esami
voto data
Corsi
matricola
codcorso
cognome
nome
email
titolo anno
(0,n) (0,n)
DocenzeProfessori
(1,1)
(1,n)
dipartimento
Num_ord
cognome
nome
30
Traduzione di schemi E/R semplici

Matricola Cognome Nome DataNascita Email*
29323 Bianchi Giorgio 21/06/1978 gbianchi@alma.unibo.it
Studenti
35467 Rossi Anna 13/04/1978
39654 Verdi Marco 20/09/1979 mverdi@mv.com
Codice Titolo Anno
483 Analisi 1
Corsi
729 Analisi 1
815 Elettronica 2
913 Sistemi Inf. 3
Dip Num_ord Cognome Nome
DEIS 12 Bolzano Bernhard
Professori
DEIS 15 Codd Ted
DIE 12 Marconi Guglielmo
 Ogni entità è tradotta con una relazione con gli stessi attributi
 La chiave primaria coincide con l’identificatore dell’entità
 Se un attributo è opzionale permettiamo la presenza di valori nulli, e usiamo l’asterisco (*) per indicare
tale possibilità
31
Traduzione di base: entità

Codice Dip Num_ord
483 DEIS 12
Docenze
729 DEIS 12
815 DIE 12
913 DEIS 15
Matricola Codice Voto Data
29323 483 28 12/06/2003
Esami
39654 729 30 15/07/2003
29323 913 30 20/09/2004
 Ogni associazione è tradotta con una relazione con gli stessi attributi, cui si aggiungono gli identificatori di tutte
le entità che essa collega.
 gli identificatori delle entità collegate costituiscono una superchiave.
 la chiave primaria dipende dalle cardinalità massime delle entità nell’associazione
32
Traduzione di base: associazioni

 La chiave primaria coincide con l’unione degli identificatori delle entità collegate:
Esami(Matricola,CodCorso,Voto,Data)
FK: Matricola REFERENCES Studenti
FK: CodCorso REFERENCES Corsi
 Per le associazioni molti a molti la traduzione presentata, ovvero con una relazione a sé, è la sola alternativa
ragionevole.
33
Associazioni molti a molti

 La chiave primaria coincide con l’identificatore dell’entità che partecipa con cardinalità massima 1 :
Docenze(CodCorso,Dip,Num_ordine)
FK: CodCorso REFERENCES Corsi
FK: (Dip,Num_ordine) REFERENCES Professori
 Perché?
 Poiché ogni corso c ha al massimo 1 docente, allora c può comparire al massimo una volta in Docenze.
34
Associazioni uno a molti

 La chiave primaria è uno dei due identificatori, l’altro diventa una chiave alternativa
Rettori R_U Università
cognome nome
(1,1)
cittànome
cf
data_inizio
R_U(CF,NomeUniversita,DataInizio)
FK: CF REFERENCES Rettori
FK: NomeUniversita REFERENCES Universita
Unique(NomeUniversita)
35
Associazioni uno a uno

 Valgono le considerazioni già fatte, ad esempio:
Fornitori Forniture Prodotti
Dipartimenti
(0,n)
(1,n)
(1,n)
nome Partita IVA Quantità
Genere Codice
nome
Telefono
Fornitori(PartitaIVA, Nome)
Prodotti (Codice, Genere)
Dipartimenti (Nome, Telefono)
Forniture (Fornitore, Prodotto, Dipartimento, Quantità)
FK: …
36
Associazioni n-arie

Una Forma Normale è una proprietà di una Base di Dati Relazionale che ne garantisce la Qualità.
Prima Forma Normale
 Si dice che una base dati è in 1NF (prima forma normale) se vale la seguente relazione:
 per ogni relazione contenuta nella base dati, una relazione è in 1NF se e solo se:
1. Ciascun attributo è definito su un dominio con valori atomici (indivisibili).
2. Ogni attributo contiene un singolo valore da quel dominio.
 Violazioni della 1NF (atomicità dei valori)
 Il seguente esempio viola la 1NF, perché pur esistendo una chiave primaria ({Matricola,Materia}),
l'attributo Voto non è definito su un dominio con valori atomici:
Matricola Studente Materia Voto
0000-000-01 Pietro Basi di Dati 1 sem, B ; 2 sem, F
0000-000-02 Pietro Basi di Dati 1 sem, A ; 2 sem, A
0000-000-03 Sara Basi di Dati 1 sem, B ; 2 sem, A
Voti
37
Normalizzazione Base Dati Relazionale: Database in Prima Forma Normale

È necessario ristrutturare la relazione come segue:
Voti Matricola Studente Materia Semestre Voto
0000-000-01 Pietro Basi di Dati 1 B
0000-000-01 Pietro Basi di Dati 2 F
0000-000-02 Pietro Basi di Dati 1 A
0000-000-02 Pietro Basi di Dati 2 A
0000-000-03 Sara Basi di Dati 1 B
0000-000-03 Sara Basi di Dati 2 A
38
Normalizzazione Base dati Relazionale – 1FN

Seconda Forma Normale
Una base dati è invece in 2NF (seconda forma normale) quando è in 1NF e per ogni relazione tutti gli attributi non-chiave
dipendono funzionalmente dall'intera chiave composta (ovvero la relazione non ha attributi che dipendono funzionalmente da
una parte della chiave).
Come esempio supponiamo di avere una tabella con gli esami sostenuti dagli studenti universitari per diversi corsi di laurea. I
campi di interesse potrebbero quindi essere i seguenti:
"Codice corso di laurea"
"Codice esame"
"Matricola studente"
"Voto conseguito"
"Data superamento"
La tabella avrà quindi la seguente intestazione
Id_corso Id_esame Id_studente voto Data
39

La chiave candidata (tale terminologia è riservata alle superchiavi minimali, anche dette semplicemente chiavi) è rappresentata dalla tripla
evidenziata, ossia da:
"Codice corso di laurea"
"Codice esame"
"Matricola studente"
Essa infatti risulta essere l'insieme di chiavi minimale per poter identificare in modo univoco le tuple (i record) della tabella.
I campi "Voto conseguito" e "Data superamento", invece, sono campi non chiave, e fanno riferimento all'intera superchiave.
Difatti, se dipendessero solo da:
"Codice corso di laurea" non potrebbero essere inseriti o reperiti i valori legati a diversi studenti per diversi esami superati
"Codice esame" non potrebbero essere inseriti o reperiti i valori legati agli studenti ed al/ai corso di laurea
"Matricola studente" non potrebbero essere inseriti o reperiti i valori legati ai diversi esame superati e ai corsi di laurea a cui gli studenti sono
iscritti.
"Codice corso di laurea", "Codice esame" non potrebbero essere inseriti o reperiti i valori legati ai diversi studenti che hanno superato l'esame
per quel corso di laurea.
"Codice corso di laurea", "Matricola studente" non potrebbero essere inseriti o reperiti i valori legati ai diversi esami superati da uno studente
iscritto ad un corso di laurea.
"Matricola studente", "Codice esame" non potrebbero essere inseriti o reperiti i valori legati ai diversi Corsi di Laurea sostenuti dagli studenti cui
quell'esame può appartenere.
40

Terza Forma Normale
Una base dati è in 3NF (terza forma normale) se è in 2NF e se tutti gli attributi non-chiave dipendono dalla chiave soltanto,
ossia non esistono attributi non-chiave che dipendono da altri attributi non-chiave. Tale normalizzazione elimina la dipendenza
transitiva degli attributi dalla chiave.
NomeImp Reparto TelefReparto
Impiegato
Chiave : NomeImp
TelefReparto dipende da Reparto, oltre che da NomeImp (si ha dipendenza transitiva dalla chiave).
Problemi :
 telefono del Reparto ripetuto per ogni Impiegato di quel Reparto
 se il telefono cambia, occorre modificare molte righe
 con errori di aggiornamento, si avrebbero telefoni differenti
 se un Reparto non ha impiegati, non si può conoscere il suo telefono.
41

Terza Forma Normale
Soluzione : relazioni in 3FN:
NomeImp Reparto
Impiegato
Reparto TelefReparto
Reparto
42

Questa presentazione è stata elaborata da :
http://www-db.deis.unibo.it/courses/SIL-B/
Questo materiale è principalmente tratto dal corso universitario di UniBo al seguente Link:
Roberto Belmonte
ASP.NET and Angular Developer
LinkedIn: https://it.linkedin.com/in/robertobelmonte
43
Crediti

Progettazione database relazionali

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Progettazione database relazionali

Semelhante a Progettazione database relazionali (20)

Progettazione database relazionali