Progettazione logica
I.
Analisi delle prestazioni su schemi E-R
II. Ristrutturazione di schemi E-R
III. Traduzione verso il modello relazionale
Progettazione Logica
1
requisiti del
Sistema informativo
progettazione concettuale
SCHEMA CONCETTUALE
progettazione logica
SCHEMA LOGICO
progettazione fisica
SCHEMA FISICO
Obiettivo della
progettazione logica
“Tradurre" lo schema concettuale (schema E-R)
in uno schema logico (modello relazionale) che
rappresenti gli stessi dati in maniera corretta ed
efficiente
Progettazione Logica
3
Dati di ingresso e uscita
 Ingresso:



schema concettuale
informazioni sul carico applicativo
modello logico
 Uscita:


schema logico
documentazione associata
Progettazione Logica
4
Non si tratta di una pura e
semplice traduzione
 Lo schema E-R va ristrutturato:
Semplificazione della traduzione: alcuni
aspetti dello schema concettuale non sono
direttamente rappresentabili nel modello
logico
 Ottimizzazione del progetto: è necessario
considerare le prestazioni

Progettazione Logica
5
Carico
applicativo
Fase 1
Ristrutturazione dello
schema E-R
Modello
logico
Fase 2
Schema E-R
Schema E-R
ristrutturato
Traduzione nel
modello logico
Schema
logico
Fase 1: Ristrutturazione schema
E-R
 E' indipendente dal modello logico scelto e si
basa sui due principi di:


semplificazione
ottimizzazione
 Osservazione:
uno schema E-R ristrutturato non è (più)
uno schema concettuale nel senso stretto
del termine
Progettazione Logica
7
Analisi delle prestazioni su
schemi E-R
Per ottimizzare il risultato abbiamo bisogno di
analizzare le prestazioni a questo livello
Le prestazioni non sono valutabili con precisione su uno
schema concettuale, dato che dipendono anche da parametri
fisici:
- dal sistema per la gestione di basi di dati utilizzato
- dalle strutture dati utilizzate per memorizzare le tabelle
- dai vari modi in cui si possono realizzare le operazioni in SQL
Progettazione Logica
8
Consideriamo degli "indici di prestazione" dei
parametri che regolano le prestazioni di uno
schema E-R:
 occupazione di memoria (spazio): spazio di
memoria necessario per memorizzare i dati descritti
dallo schema

dipende dal numero di occorrenze di entità e relazioni
previste
 costo di una operazione (tempo): numero di
occorrenze (di entità e relationship) visitate per
rispondere a un’operazione sulla base di dati
Progettazione Logica
9
Informazioni necessarie per
l’analisi delle prestazioni
 Per studiare questi parametri abbiamo bisogno di
conoscere, oltre allo schema, le seguenti informazioni
 volume dei dati:
numero di occorrenze di ogni entità dello schema
 numero di occorrenze di ogni relationship dello schema
 dimensioni di ciascun attributo (di entità o relationship)


caratteristiche delle operazioni:
tipo di operazione (interattiva o batch)
 frequenza dell’esecuzione
 dati coinvolti (entità e/o relationship)

Progettazione Logica
10
Schema di riferimento
(0,1)
Cognome
(1,1)
Telefono
Direzione
Impiegato
Codice
(1,N)
(0,1)
(0,N)
Partecipazione
Afferenza
(0,1)
Data
(1,N)
Progetto
Budget
Nome
(1,N)
Dipartimento
Nome
(1,1)
Composizione
(1,N)
Sede
Via
Indirizzo
CAP
Città
Tavola dei volumi
vi sono riportati i concetti dello schema col volume
previsto a regime
Concetto
Sede
Dipartimento
Impiegato
Progetto
Composizione
Afferenza
Direzione
Partecipazione
Tipo
E
E
E
E
R
R
R
R
Volume
10
80
2000
500
80
1900
80
6000
12
Occorrenze di una relationship
 Il numero delle occorrenze di una relationship dipende da:
Numero di occorrenze delle entità coinvolte nella relationship
 Numero medio di partecipazioni di una occorrenza di entità
all’occorrenza della relationship
 Esempio:
 Volume Composizione = Volume Dipartimento
 Volume Afferenza  Volume Impiegato
 Volume Direzione = Volume Dipartimento
 Volume Partecipazione = 3  Volume Impiegato

Progettazione Logica
13
Esempio di valutazione di costo
delle operazioni
 Operazione:
1.
2.
3.
4.
assegna un impiegato a un progetto
trova tutti i dati di un impiegato, del dipartimento
nel quale lavora e dei progetti ai quali partecipa
trova i dati di tutti gli impiegati di un certo
dipartimento
per ogni sede trova i suoi dipartimenti con il
cognome del direttore e l’elenco degli impiegati
del dipartimento
Progettazione Logica
14
Descrizione delle operazioni
 L’analisi delle operazioni principali richiede la
codifica di:



tipo dell’operazione : Interattiva (I) o Batch (B)
frequenza: numero medio di esecuzioni in un certo
periodo di tempo
schema di navigazione: frammento dello schema E/R
interessato dall’operazione sul quale viene disegnato
(con delle frecce) il “cammino logico” da percorrere per
accedere alle informazioni di interesse
Progettazione Logica
15
Tavola delle operazioni
Operazione
Op.1
Op.2
Op.3
Op.4
Tipo
I
I
I
B
Progettazione Logica
Frequenza
50 al giorno
100 al giorno
10 al giorno
2 a sett.
16
Regola 80-20
 Regola 80-20: l’80% del carico è generato
dal 20% delle operazioni
Dunque il carico si può valutare accuratamente
basandoci sulle principali operazioni previste
 Per ogni operazione significativa si costruisce uno
schema di navigazione (frammento di di schema
E-R interessato all’operazione)
Progettazione Logica
17
Operazione 2: trova tutti i dati di un impiegato, del
dipartimento nel quale lavora e dei progetti ai quali partecipa
Telefono
Cognome
(1,N)
Impiegato
Codice
(0,N)
Partecipazione
(1,N)
Progetto
Budget
(1,N)
(0,1)
Nome
Afferenza
Dipartimento
(1,1)
Nome
(0,1)
Data
schema di navigazione
Tavola degli accessi
 Per ogni operazione significativa si costruisce una
tavola degli accessi basata sullo schema di
navigazione



il campo costrutto specifica il tipo di concetto (entità o
associazione)
nel campo accessi si conta il numero degli accessi
necessario per eseguire una volta l’operazione
il campo tipo è riferito al tipo di operazione: le
operazioni di scrittura (S) sono più onerose di quelle di
lettura (L)
il peso degli accessi in scrittura è in genere considerato
doppio di quello delle
letture
Progettazione Logica
19
Tavola degli accessi
Concetto
Costrutto Accessi Tipo
Impiegato
Entità
1
L
Afferenza
Relazione
1
L
Dipartimento
Entità
1
L
Partecipazione Relazione
3
L
Progetto
Entità
3
L
Un accesso può essere di tipo L (lettura) o S (scrittura)
Il numero delle istanze si ricava dalla tavola dei
volumi mediante semplici operazioni
es: in media ogni impiegato partecipa a 6000/2000 = 3 progetti
Progettazione Logica
20
Attività della ristrutturazione
Analisi delle ridondanze
 Eliminazione delle generalizzazioni
 Partizionamento/accorpamento di entità e
relationship
 Scelta degli identificatori primari

Progettazione Logica
21
1. Analisi delle ridondanze
 Una ridondanza in uno schema E-R è una
informazione significativa ma derivabile da
altri dati
 in questa fase si decide se eliminare le
ridondanze eventualmente presenti o
mantenerle
Progettazione Logica
22
Ridondanze
 Vantaggi


semplificazione delle interrogazioni
riduzione del numero degli accessi necessari per
calcolare il dato derivato
 Svantaggi


appesantimento degli aggiornamenti
maggiore occupazione di spazio
Progettazione Logica
23
Forme di ridondanza in
uno schema E-R
 attributi derivabili:
 da altri attributi della stessa entità (o
relazione)
 da attributi di altre entità (o relazioni)
 relazioni derivabili dalla composizione di
altre relazioni in presenza di cicli
Progettazione Logica
24
Attributo derivabile
Importo netto
Fattura
IVA
Importo lordo
Progettazione Logica
25
Attributo derivabile da
altra entità
Importo totale
Prezzo
(1,N)
Acquisto
(1,N)
Composizione
Prodotto
Importo totale è ottenibile con operazioni di
aggregazione
Progettazione Logica
26
Studente
(0,N)
Ridondanza
dovuta a ciclo
Frequenza
(1,N)
Corso
(1,1)
Insegnamento
(1,1)
Professore
(0,N)
Docenza
(1,N)
Mantenere o meno la
ridondanza?
La decisione di mantenere o eliminare una
ridondanza va presa confrontando il costo di una
esecuzione delle operazioni che coinvolgono il dato
ridondante e l’occupazione di memoria, nei casi di
presenza e assenza della ridondanza
Progettazione Logica
28
Analisi di una ridondanza
Numero abitanti
(1,1)
Persona
(1,N)
Residenza
Città
L’attributo numero abitanti è derivabile da una operazione
di conteggio delle istanze di persona residenti in una città
Progettazione Logica
29
tavola dei volumi
Concetto
Tipo
Città
E
Persona
E
Residenza
R
Volume
200
1000000
1000000
 Operazione 1: memorizza una nuova persona con
la relativa città di residenza (500 volte al giorno)
 Operazione 2: stampa tutti i dati di una città
(incluso il numero Progettazione
di abitanti)
(2 volte al giorno)
Logica
30
Presenza di ridondanza
Operazione 1
Concetto Costrutto Accessi Tipo
Persona
Entità
1
S
Residenza Relazione
1
S
Città
Entità
1
L
Città
Entità
1
S
Operazione 2
Concetto Costrutto Accessi Tipo
Città
Entità
1
L
Progettazione Logica
31
Assenza di ridondanza
Operazione 1
Concetto Costrutto Accessi Tipo
Persona
Entità
1
S
Residenza Relazione
1
S
Operazione 2
Concetto Costrutto Accessi Tipo
Città
Entità
1
L
Residenza Relazione 5000
L
n.persone/n.città = media accessi per calcolare il numero
di abitanti di una città Progettazione Logica
32
Presenza di ridondanza
 Costi:


Operazione 1: 1500 accessi in scrittura e 500
accessi in lettura al giorno
Operazione 2: trascurabile.
 Contiamo doppi gli accessi in scrittura
 Totale di 3500 accessi al giorno
Progettazione Logica
33
Assenza di ridondanza
 Costi:


Operazione 1: 1000 accessi in scrittura
Operazione 2: 10000 accessi in lettura al
giorno
 Contiamo doppi gli accessi in scrittura
 Totale di 12000 accessi al giorno
Conviene dunque mantenere il dato ridondante
Progettazione Logica
34
Ristrutturazione
dello schema E-R
Analisi delle ridondanze
 Eliminazione delle generalizzazioni
 Partizionamento/accorpamento di entità e
relazioni
 Scelta degli identificatori primari

Progettazione Logica
35
2. Eliminazione delle gerarchie
 il modello relazionale non può rappresentare
direttamente le generalizzazioni
 entità e relazioni sono invece direttamente
rappresentabili
si eliminano perciò le gerarchie,
sostituendole con entità e relazioni
Progettazione Logica
36
Tre possibilità
1. accorpamento delle figlie della generalizzazione
nel genitore
2. accorpamento del genitore della generalizzazione
nelle figlie
3. sostituzione della generalizzazione con relazioni
Progettazione Logica
37
A01
A02
E0
R1
E1
E2
A11
A21
Schema generale
E3
R2
E4
Accorpamento delle figlie della
generalizzazione nel genitore
 E1 e E2 sono eliminate e le loro proprietà vengono
aggiunte al padre E0
 A E0 viene aggiunto anche un nuovo attributo, TIPO,
che serve a distinguere le occorrenze di E1 da quelle
di E2
 Gli attributi A11 e A21 possono assumere anche
valori nulli su E0
Progettazione Logica
39
Collasso verso l’alto
A01
A02
(0,1)
A11
A21
E0
E3
R1
(0,1)
TIPO
(0,..)
R2
E4
Esempio
Dom(Tipo)= {L,D,N}
Studente
Tipo
Matr.
Nome
Tit.Tesi (0,1)
(p,e)
Studente
Tit.Stage
Tit.Tesi
Laureando
(1,1)
Tit.Stage (0,1)
Diplomando
(1,1)
(0,1)
Matr
(1,n)
Relatore
Matr.
Nome
(0,1)
(1,n)
Azienda
Denom.
Matr
(1,n)
Relatore
(1,n)
Azienda
Denom.
Osservazioni
 Conveniente quando le operazioni sulla base
di dati non fanno molta distinzione tra le
occorrenze e tra gli attributi di E0, E1, E2
 Vantaggi: numero minore di accessi
 Svantaggi: spreco di memoria per la presenza
di valori nulli
Progettazione Logica
42
A01
A02
E0
R1
E3
totale
E1
E2
A11
A21
R2
E4
Accorpamento del genitore della
generalizzazione nelle figlie
 E0 viene eliminato, i suoi attributi e identificatore
vengono assegnati alle figlie
 R11 e R12 sono le restrizioni di R1 alle occorrenze di
E1 e E2
Nota Bene


tale trasformazione è possibile solo se la
generalizzazione è totale, altrimenti le occorrenze
di E0 - (E1 U E2) non sarebbero rappresentate
Conviene quando ci sono operazioni che si
riferiscono solo a occorrenze di E1, o di E2 e fanno
44
distinzioni tra tali entità
Collasso verso il basso
R11
R12
E3
E1
E2
R2
A01 A11 A02
A01 A21 A02
E4
Esempio
CF
Nome
1,n
Dipendente
Sindacato
0,1
(t,e)
Dirige
1,n
macchine
capacità
Impiegato
1,n
Contribuisce
0,1
Operaio
1,n
n_sottoposti
Dirigente
0,n
Contr_I
0,n
0,1
1,n
Contr_O
Dir_I
0,1
capacità
Impiegato
CF
Nome
0,1
0,1
macchine
Operaio
CF
Dir_D
0,n
Dir_O
0,1
0,n
0,n
Nome
1,n
Sindacato
Contr_D
0,n
n_sottoposti
Dirigente
CF
Nome
 Quando conviene utilizzare questa alternativa?


Quando ci sono operazioni che si riferiscono solo a
occorrenze di E1 oppure di E2, e fanno distinzioni
tra le 2 entità
Gli attributi non assumono mai valori nulli
Progettazione Logica
47
Sostituzione della generalizzazione
con relationship
 La generalizzazione si trasforma in due associazioni
uno a uno che legano l’entità padre E0 con E1 e E2
 Si pongono dei vincoli per impedire che una
occorrenza di E0 partecipi sia a E1 che a E2
Nota bene
-conviene se gli accessi alle entità figlie sono separati
dagli accessi al padre
-è sempre possibile indipendentemente dalla copertura
e conserva tutte le entità
-le entità vengono mantenute e sono identificate
esternamente
Progettazione Logica
48
A01
A02
E0
(0,1)
R1
E3
(0,1)
RG1
RG2
(1,1)
(1,1)
E1
E2
A11
A21
R2
E4
Esempio
Cod
Desc
Cod
Desc
Progetto
Progetto
0,1
0,1
N_schede
1,1
Prog_sw
Mesi
uomo
Prog_hw
Prog_sw
1,n
usa
0,n
Comp_hw
Mesi
uomo
1,1
Prog_hw
1,n
N_schede
usa
0,n
Comp_hw
 Quando conviene usare questa alternativa?


quando la generalizzazione non è totale,
quando ci sono operazioni che si riferiscono solo
a occorrenze di E1, E2 oppure E0,
 Risparmio di memoria rispetto alla scelta (1):
non si introducono valori nulli
 Aumento degli accessi per mantenere la
consistenza delle occorrenze
Progettazione Logica
51
Attività della ristrutturazione
Analisi delle ridondanze
 Eliminazione delle generalizzazioni
 Partizionamento/accorpamento di entità e
relazioni
 Scelta degli identificatori primari

Progettazione Logica
52
 entità e associazioni in uno schema E-R
possono essere partizionati o accorpati per
rendere più efficienti le operazioni, in base a
un semplice principio:
 gli accessi si riducono:


separando attributi di un concetto che vengono
acceduti separatamente;
raggruppando attributi di concetti diversi acceduti
insieme;
Progettazione Logica
53
Ristrutturazioni, casi principali
 partizionamento orizzontale/verticale di entità
 eliminazione di attributi multivalore
 accorpamento di entità/ relationship
Progettazione Logica
54
Partizionamento verticale
di entità
Cognome
Codice
Livello
Indirizzo
Impiegato
Data
nascita
Stipendio
Ritenute
Progettazione Logica
55
Si separano gli attributi in gruppi omogenei
Stipendio
Cognome Codice
(1,1)
Dati
anagrafici
Indirizzo
Data
nascita
Livello
(1,1)
Dati Impiegato
Dati
lavorativi
Ritenute
Progettazione Logica
56
Eliminazione di attributi
multivalore
Nome
Indirizzo
Città
Agenzia
(1,N)
Telefono
Progettazione Logica
57
Si
introduce una entità le cui istanze sono identificate
dai valori dell’attributo
L’associazione
Città
può essere uno a molti o molti a molti
Nome
Numero
(1,N)
(1,1)
Agenzia
Utenza
Indirizzo
Progettazione Logica
Telefono
58
Eliminazione di attributi multivalore
Nome
Se la cardinalità massima K è
nota: è possibile prevedere K
repliche degli attributi
Indirizzo Città Nome
Indirizzo
Agenzia
Città
(1,3)
Telefono
Agenzia
Tel1
Tel2
Tel3
Progettazione Logica
59
Accorpamento di Entità
Cognome
Codice
fiscale
Interno Indirizzo
(0,1)
Persona
Indirizzo
(1,1)
Intestazione
Appartamento
Data
nascita
Progettazione Logica
60
Cognome
Codice
fiscale
Interno
(0,1)
Indirizzo
Persona
Data
nascita
Indirizzo
(0,1)
Progettazione Logica
61
Partizionamento orizzontale di associazioni
Cognome
Città
Nome
Ruolo
(1,N)
Giocatore
(1,N)
Squadra
Composizione
Data acquisto
(0,1)
Data cessione
Data acquisto
Ruolo
(1,1)
Comp.
attuale
(1,N)
Giocatore
Nome
Squadra
(0,N)
Comp.
passata
Cognome
Data acquisto
(1,N)
Città
Data cessione
Attività della ristrutturazione
Analisi delle ridondanze
 Eliminazione delle generalizzazioni
 Partizionamento/accorpamento di entità e
relationship
 Scelta degli identificatori primari

Progettazione Logica
63
Scelta degli identificatori
principali
 operazione indispensabile per la traduzione nel
modello relazionale perché


nel modello relazionale le chiavi vengono usate per
stabilire legami tra dati in relazioni diverse;
i DBMS richiedono di specificare una chiave primaria;
 si deve decidere quale degli identificatori utilizzare
come chiave principale
Progettazione Logica
64
 Criteri


Gli attributi con valori nulli non possono essere
identificatori principali
Gli identificatori con uno o pochi attributi sono preferibili




vantaggio in termini di risparmio di memoria nella realizzazione dei
legami logici tra le varie relazioni
facilita le operazioni di join
Un identificatore interno è preferibile
Un identificatore utilizzato nelle operazioni più frequenti o
importanti è preferibile
Progettazione Logica
65
Se nessuno degli identificatori
soddisfa i requisiti visti?
Si introducono nuovi attributi (codici) contenenti
valori speciali generati appositamente per questo
scopo
ES. Contatori, Sigle
Progettazione Logica
66
 L’identificatore {Interno, Indirizzo} è opzionale, quindi non
può essere scelto
 Tra Codice fiscale e Codice SSN la scelta dipende da quale è più
frequentemente usato per accedere a una persona
Codice fiscale
Cognome
Interno
(0,1)
Indirizzo
Persona
Data nascita
Codice SSN
Indirizzo
(0,1)
67
Fase 2: Traduzione verso il
modello relazionale
 Input:


schema concettuale
modello logico
 Output:

schema logico
 Sono possibili altre fasi:


Verifiche sulla qualità dello schema
Normalizzazione dello schema prodotto
Progettazione Logica
68
Traduzione verso il relazionale
 idea di base:


le entità diventano relazioni sugli stessi attributi
e la chiave è l’identificatore principale
le relationship (o associazioni) diventano
relazioni i cui attributi sono gli identificatori
delle entità coinvolte e gli attributi propri
dell’associazione
Progettazione Logica
69
 Ogni entità è tradotta con una relazione con gli stessi
attributi
 La chiave primaria coincide con l’identificatore
principale dell’entità
 Gli attributi composti vengono ricorsivamente
suddivisi nelle loro componenti, oppure si mappano in
un singolo attributo della relazione, il cui dominio va
opportunamente definito
 Per brevità, usiamo l’asterisco (*) per indicare la
possibilità di valori nulli
nome
cognome
cod_fiscale
Persona
indirizzo
via
n.civico (0,1)
città
CAP
Persona(CF, Cognome, Nome, Via, NCivico*,Città,CAP)
Entità e relationship molti a
molti
Cognome Matricola
Data inizio
(0,N)
Impiegato
Codice
Nome
(1,N)
Partecipazione
Progetto
Stipendio
Budget
Impiegato(Matricola, Cognome, Stipendio)
Progetto(Codice, Nome, Budget)
Partecipazione(Matricola, Codice, DataInizio)
Progettazione Logica
71
Nomi più espressivi per gli attributi della
chiave della relazione che rappresenta la
relationship
Impiegato(Matricola, Cognome, Stipendio)
Progetto(Codice, Nome, Budget)
Partecipazione(Matricola, Codice, DataInizio)
Progettazione Logica
72
Nomi più espressivi per gli attributi della
chiave della relazione che rappresenta la
relationship
Impiegato(Matricola, Cognome, Stipendio)
Progetto(Codice, Nome, Budget)
Partecipazione(Impiegato, Progetto, DataInizio)
Progettazione Logica
73
Relationship ricorsive
Quantità
(0,N)
Composizione
Composto
Costo
Prodotto
Nome
(0,N)
Componente
Codice
Prodotto(Codice, Nome, Costo)
Composizione(Composto, Componente, Quantità)
Progettazione Logica
74
Relationship n-arie
Nome
Quantità
Partita IVA
(0,N)
Fornitore
Genere
Codice
(1,N)
Fornitura
Prodotto
(1,N)
Nome
Dipartimento
Telefono
Fornitore(PartitaIVA, Nome)
Prodotto(Codice, Genere)
Dipartimento(Nome, Telefono)
Fornitura(Fornitore, Prodotto, Dipartimento, Quantità) 75
Relationship uno a molti
Cognome
Data
nascita
(1,1)
Giocatore
Ingaggio
Città
Nome
(0,N)
Contratto
Ruolo
Squadra
Colori sociali
Giocatore(Cognome, DataNascita, Ruolo)
Squadra(Nome, Città, ColoriSociali)
Contratto(CognGiocatore, DataNascG, Squadra, Ingaggio)
Progettazione Logica
76
Soluzione più compatta
Giocatore(Cognome, DataNascita, Ruolo)
Contratto(CognGiocatore, DataNascG, Squadra, Ingaggio)
Squadra(Nome, Città, ColoriSociali)
 Giocatore e Contratto hanno la stessa chiave:
possiamo fonderle in un’unica relazione
Giocatore(Cognome, DataNasc, Ruolo, Squadra, Ingaggio)
Squadra(Nome, Città, ColoriSociali)
 con vincolo di integrità referenziale fra Squadra in Giocatore e la
chiave di Squadra
Progettazione Logica
77
Osservazione
Cognome
Data
nascita
(0,1)
Giocatore
Ingaggio
Città
Nome
(0,N)
Contratto
Ruolo
Squadra
Colori sociali
se la cardinalità minima della relationship è 0, allora Squadra e
Ingaggio in Giocatore devono ammettere valore nullo
Giocatore(Cognome, DataNasc, Ruolo, Squadra*, Ingaggio*)
Squadra(Nome, Città, ColoriSociali)
Progettazione Logica
78
Associazioni ricorsive uno a
molti
(0,N)
 In questo caso è possibile
operare una traduzione con 1
o 2 relazioni
Responsabile
Dipendenza
Impiegato
(0,1)
Dipendente
1 relazione:
Qualifica
Nome
Impiegato(Codice, Nome, Qualifica, Responsabile*)
Codice
FK: Responsabile REFERENCES Impiegato
2 relazioni:
Impiegato(Codice, Nome, Qualifica)
Dipendenza(Dipendente, Responsabile)
FK: Dipendente REFERENCES Impiegato
FK: Responsabile REFERENCES Impiegato
79
Entità con identificazione
esterna
Nel
caso di entità identificata esternamente, si “importa”
l’identificatore della/e entità identificante/i.
L’associazione
Cognome
relativa risulta automaticamente tradotta
Matricola
Nome
(1,1)
Studente
AnnoDiCorso
Iscrizione
Città
(1,N)
Università
Indirizzo
Studente(Matricola, Università, Cognome, AnnoDiCorso)
Università(Nome, Città, Indirizzo)
80
Relationship uno a uno (1,1) – (1,1)
Data inizio
Cognome
Sede
Codice
(1,1)
Direttore
Nome
(1,1)
Direzione
Stipendio
Direttore (Codice, Cognome, Stipendio)
Dipartimento
Telefono
Dipartimento (Nome, Sede, Telefono, Direttore, InizioD)
Direttore (Codice, Cognome, Stipendio, InizioD, Dipartimento)
Dipartimento (Nome, Sede, Telefono)
81
Relationship uno a uno (0,1) – (1,1)
Data inizio
Cognome
Sede
Codice
(0,1)
Impiegato
Nome
(1,1)
Direzione
Stipendio
Dipartimento
Telefono
tradurre l’associazione Direzione inglobandola in Impiegato
non è in generale una buona scelta (dipende dai volumi
dei dati in gioco): troppi valori nulli!
Progettazione Logica
82
Relationship uno a uno (0,1) – (1,1)
Data inizio
Cognome
Sede
Codice
(0,1)
Impiegato
Nome
(1,1)
Direzione
Stipendio
Dipartimento
Telefono
Impiegato(Codice, Cognome, Stipendio, Dipartimento*, DataInizio*)
Dipartimento(Nome, Sede, Telefono)
Progettazione Logica
83
Soluzione:
Impiegato (Codice, Cognome, Stipendio)
Dipartimento (Nome, Sede, Telefono, Direttore,
InizioD)
• con vincolo di integrità referenziale, senza valori
nulli
Progettazione Logica
84
Relationship uno a uno (0,1) – (0,1)
Data inizio
Cognome
Sede
Codice
(0,1)
Impiegato
Nome
(0,1)
Direzione
Dipartimento
Stipendio
Telefono
Per evitare la presenza di valori nulli nelle chiavi esterne:
Impiegato (Codice, Cognome, Stipendio)
Dipartimento (Nome, Sede, Telefono, Direttore)
Direzione (Direttore, Dipartimento, DataInizio)
85
Un esempio particolare
(0,1)
Marito
Matrimonio
Persona
Nome
(0,1)
Moglie
CF
2 relazioni:
Persona(CF, Nome)
Matrimonio(Marito, Moglie)
Progettazione Logica
86
(0,1)
Cognome
(1,1)
Telefono
Direzione
Impiegato
Codice
(1,N)
(0,1)
(0,N)
Partecipazione
Afferenza
(0,1)
Data
(1,N)
Progetto
Budget
Nome
Dipartimento
Nome
(1,1)
Composizione
(1,N)
Sede
Via
Indirizzo
CAP
Città
Per
le entità E che partecipano ad associazioni sempre con
max-card(E,R) = n la traduzione è immediata:
Sede(Città, Via, CAP)
Progetto(Nome, Budget)
Anche
l’associazione Partecipazione si traduce immediatamente:
Partecipazione(Impiegato, Progetto)
L’entità
Dipartimento si traduce importando l’identificatore di Sede e
inglobando l’associazione Direzione
Dipartimento(Nome, Città, Telefono, Direttore)
Per
tradurre l’associazione Afferenza, assumendo che siano pochi gli
impiegati che non afferiscono a nessun dipartimento, si opta per una
rappresentazione compatta
Impiegato(Codice, Cognome, Dipart*,CittàDip* Data*)
AA
Esercizio 1
ciclo
(1,1)
Corso_AA
responsabilità
(0,n)
Docente
nome
cognome
data_nascita
cod_doc
(1,1)
attivato
(0,n)
Corso
MEDICO
cod_corso
nome
nome
cognome
telefono
cod_med
(0, N)
FA_VISITA
(1, 1)
VISITA
esito
data
(1, 1)
IN_VISITA
(0, N)
PAZIENTE
Progettazione Logica
nome
cognome
data_nascita
cod_paziente
89
Esercizio 2
Trovare lo schema ER che dà luogo al seguente schema
relazionale:
GIOCATORI(n_giocatore, cognome, iniziali, data_nascita, sesso, iscritto_dal,
indirizzo, numero, cap, citta, telefono, n_socio)
SQUADRE(n_squadra, n_giocatore, categoria)
PARTITE(n_partita, n_squadra, n_giocatore, vittorie, sconfitte)
PENALITA(n_pagamento, n_giocatore, data_pagamento, importo)
MEMBRI_COMMISSIONE(n_giocatore, data_inizio, data_fine, carica)
Progettazione Logica
90