Basi di dati
Progetto Logico
per il
Modello Relazionale
(E. Baralis, Politecnico di Torino)
Trasformazione da schema E-R a
modello relazionale
Risultato: schema relazionale nella forma
normale opportuna.
SCHEMA E-R
passo A: ristrutturazione
A
Schema E-R
ristrutturato
passo B: traduzione
B
Set di relazioni
(modello relazionale)
2
Passo A:
ristrutturazione dello schema E-R
E’ una fase di riorganizzazione dello schema
E-R sulla base del carico applicativo
previsto.
Il carico applicativo consiste di:
1) Volumi dei dati (memoria d’occupazione);
2) Caratteristiche delle operazioni (piu’
rilevanti).
3
Carico applicativo
1) Volumi dei dati:
valutati come N*O, dove
N è il numero di occorrenze di ogni entità
e/o relazione;
O è l’occupazione in bytes di ogni
occorrenza.
2) Caratteristiche delle operazioni:
- tipo (interattivo o batch);
- frequenza (numero medio di operazioni
in una certa unità di tempo);
- volumi di dati coinvolti.
4
Indici di prestazioni
• Lo scopo del passo di ristrutturazione è di
ottimizzare i seguenti indici di prestazione:
– costo di una operazione:
valutato come numero di accessi ad
occorrenze di entità e/o relazione visitati
per rispondere a una operazione;
– occupazione di memoria
5
Esempio
codice nome
stipendio
età
impiegato
N_progetti
(0,1)
(0,n)
afferenza
(1,n)
dipartimento
data_afferenza
partecipazione
telefono nome
(1,n)
data_inizio
(1,n)
progetto
nome
budget data_consegna
6
Tavola dei volumi
• Dipende dalla cardinalità delle entità e dalla
cardinalità media di partecipazione di una
occorrenza di entità ad una relazione:
Concetto
Tipo
Volume (n. occ)
Impiegato
entità
2000
Dipartimento
entità
80
Progetto
entità
500
Partecipazione
relazione
6000
Afferenza
relazione
1900
• Ipotesi: se un impiegato partecipa in media a
3 progetti, la relazione partecipazione ha in
media 2000*3 occorrenze; invece afferenza
ha cardinalità di poco inferiore a impiegato
7
Tavola delle operazioni
• Operazione 1: assegna un impiegato
ad un progetto.
• Operazione 2: trova tutti i dati di un
impiegato (con i dati del suo
dipartimento e l’elenco dei progetti ai
quali lavora).
• Operazione 3: trova tutti i dati di un
dipartimento (con l’elenco dei suoi
dipendenti).
Operazione
Tipo
Frequenza
Operazione 1
interattiva
50 volte al giorno
Operazione 2
interattiva
100 volte al giorno
Operazione 3
batch
1 volta alla settimana
8
Costo dell’Operazione 1:
“assegna un impiegato ad un progetto”
• Schema dell’operazione
codice nome
età
stipendio
impiegato
N_progetti
(0,n)
+1
partecipazione
data_inizio
(1,n)
progetto
nome
budget data_consegna
9
Tavola degli accessi
Concetto
Tipo
N accessi
Lettura/Scrittura
Impiegato
entità
1
S
Partecipazione
relazione
1
S
• Costo:
2 operazioni di scrittura * 50 volte al
giorno
10
Passo A:
ristrutturazione dello schema E-R
E’ costituito da una sequenza di passi:
1) Analisi delle ridondanze;
2) Eliminazione delle gerarchie di generalizzazione;
3) Partizionamento/accorpamento di entità;
4) Scelta degli identificatori.
11
Analisi delle ridondanze
• Conviene mantenere l’attributo ridondante
N_progetti in impiegato?
• Costo in volumi di dati per l’attributo
N_progetti:
2000 impiegati * 2 byte= 4Kbyte.
• Costo in aggiornamento (Op.1):
1 accesso in scrittura per 50 volte al giorno.
• Costo in lettura (Op.2):
1 accesso in lettura per 100 volte al giorno.
• Se supponiamo che un’operazione di scrittura
costi il doppio rispetto ad una di lettura si
hanno 200 accessi al giorno.
12
Eliminazione attributo N_progetti
• Alternativamente potrei contare il numero di
occorrenze della relazione partecipazione
che si riferiscono ad un certo impiegato.
• Costo in volumi di dati:
nullo.
• Costo di mantenimento:
nullo.
• Costo di lettura:
in media 3 operazioni di lettura per 100 volte
al giorno: 300 accessi al giorno.
13
Eliminazione delle gerarchie di
generalizzazione
Vi sono alcune possibilità:
1) Collassamento delle sottoclassi nella
superclasse:
– gli attributi delle sottoclassi sono uniti a
quelli dell’entità superiore
– si aggiunge un attributo discriminante
2) Eliminazione della superclasse:
– propagazione degli attributi della
superclasse in tutte sottoclassi
3) Mantenimento di tutte le entità,
correlate da relazioni che
rappresentano la generalizzazione.
14
Esempio
TUTORE
GRADO(a.d.,(0,1))
TITOLO_TESI (0,1)
C_FISC
NOME
CORSO_DI_STUDI
STUDENTE
C_FISC
NOME
CORSO_DI_
STUDI
STUDENTE
(p,e)
LAUREANDO
(1,1)
HA_
RELATORE
(1,n)
FACOLTA`
UNIVERSITARIO
(0,1)
TITOLO_
TESI
TUTORE
SOCIO_
DI
(1,n)
ASSOCIAZIONE_
STUDENTESCA
(0,1)
(0,1)
HA_
RELATORE
(1,n)
FACOLTA`
SOCIO_
DI
(1,n)
ASSOCIAZIONE_
STUDENTESCA
15
Scelta 1
Svantaggi:
Incremento di occupazione di memoria
(presenza di valori nulli per gli attributi non
significativi).
Vantaggi:
Conviene quando le operazioni non fanno
distinzione rispetto all’appartenenza di una
occorrenza a una sottoclasse: numero minore
di accessi perché le occorrenze di interesse
sono tutte concentrate in una stessa entità.
16
Esempio
C_FISC
NOME
IMPIEGATO
(0,1)
PAGA_
CONTR
(1,1)
CONTRIBUTI
(0,1)
(t,e)
SEGRETARIO
DIRETTORE
MANAGER
INGEGNERE
(1,n)
(0,m)
SPECIALIZZAZIONE
NUM_SOTTOPOSTI
CAPACITA`
(1,n)
USA
(0,n)
WORD_PROCESSOR
Rappresentazione di gerarchie
di generalizzazione
mediante sottoclassi
17
(0,1)
(0,1)
CONTR_1
CONTR_2
CONTRIBUTI
(0,1)
(0,1)
NUM_SOTTOPOSTI
(0,1)
C_FISC
C_FISC
NOME
CONOSC
SEGRETARIO
NOME
C_FISC
INGEGNERE
NOME
CONTR_3
MANAGER
(0,1)
(1,n)
(0,m)
SPECIALIZ
(1,n)
(1,1)
DIRETT_1
(1,n)
DIRETT_3
USA
(0,n)
(0,1)
(1,1)
DIRETT_2
(1,n)
WORD_PROCESSOR
18
Scelta 2
Svantaggi:
E’ possibile solo se la generalizzazione è totale,
altrimenti le occorrenze della sopraclasse non
sarebbero rappresentate. Occorre duplicare il
numero di relazioni per ciascuna sottoclasse.
Vantaggi:
Conviene se le operazioni fanno accesso solo ad
occorrenze di una o delle altre sottoclassi. Si
risparmia in memoria perché si eliminano i valori nulli
degli attributi. Si riducono gli accessi rispetto alla
scelta 3 perché per accedere ad un’occorrenza di
una sottoclasse non si deve passare per la
sopraclasse.
19
Esempio
NUM_PROG
NOME_PROG
PROGETTO
(1,m)
(1,n)
HA
MEMBRI_
PROGETTO
BUDGET
(p,o)
PROGETTO_
SW
PROGETTO_
HW
(1,n)
SOTTOCONTRATTO
NUM_
SCHEDE
CONTRAENTE_
PRINCIPALE
MESI_UOMO
USA
(0,m)
COMPONENTI_HW
Rappresentazione di gerarchie di
generalizzazione tramite relazioni
20
NUM_PROG
NOME_PROG
PROGETTO
(1,m)
HA
(1,n)
MEMBRI_
PROGETTO
BUDGET
(0,1)
(0,1)
(0,1)
TIPO_SW
(1,1)
PROGETTO_
SW
TIPO_HW
TIPO_
SOTTOCONTR
(1,1)
(1,1)
PROGETTO_
HW
(1,n)
MESI_UOMO
SOTTOCONTRATTO
NUM_
SCHEDE
CONTRAENTE_
PRINCIPALE
USA
(0,m)
COMPONENTI_HW
21
Scelta 3
Svantaggi
Si incrementa il numero di accessi per le occorrenze
delle sottoclassi. Se la generalizzazione è totale ed
esclusiva, occorre aggiungere dei vincoli: una
occorrenza della sopraclasse deve partecipare ad
una ed una sola relazione con una delle sottoclassi.
Vantaggi
Conviene quando la generalizzazione non è totale, e le
operazioni fanno accesso o ad occorrenze della
sopraclasse, o di sottoclassi. Si risparmia memoria e
ciò può aumentare il numero di dati che si recuperano
con l’accesso ad un singolo buffer di disco.
22
Partizionamento di entità
(e relazioni)
• Il partizionamento d’entità (relazioni) corrisponde a
separare i concetti che vengono acceduti da
operazioni diverse.
Si può decomporre:
• verticalmente selezionando gli attributi (tramite
proiezione). Ha il vantaggio che generano entità
semplici, con pochi attributi.
• orizzontalmente (selezionando le occorrenze sulla
base dei valori degli attributi). Ciò può anche essere
visto come l’introduzione di una nuova
generalizzazione a livello logico. Ha lo svantaggio
che si duplicano le relazioni per le due nuove entità.
23
Esempio:
partizionamento verticale di entità
cognome
livello
indirizzo
stipendio
impiegato
Data_nascita
ritenute
codice
livello
cognome
(1,1)
indirizzo
Dati anagrafici
(1,1)
Dati_impiegato
Dati lavorativi
stipendio
ritenute
Data_
nascita
codice
24
Partizionamento di relazione
nome
cognome
(1,n)
ruolo
Giocatore
Data_
acquisto
Squadra
città
Data_
cessione (0,1)
nome
cognome
ruolo
(1,n)
composizione
(1,1)
(1,n)
Composizione
attuale
Giocatore
Squadra
città
Data_
acquisto
(0,n) Composizione
(1,n)
precedente
Data_acquisto
Data_cessione
25
Accorpamento di entità
• L’accorpamento d’entità corrisponde a
raggruppare i concetti che vengono acceduti
insieme dalle stesse operazioni. Ciò ad esempio
permette di ridurre il numero di join tra entità.
Uno svantaggio però consiste nel fatto che
potrebbero essere introdotti attributi con valori
nulli. Inoltre si introduce una certa ridondanza, il
che è equivalente ad una operazione di denormalizzazione. Perciò viene utilizzata dove
sussistono relazioni 1:1 o 0:1 tra le entità da
accorpare, e raramente se le relazioni sono
1:molti.
26
Esempio
indirizzo
cognome
(1,1)
(0,1)
indirizzo
Persona
intestazione
appartamento
interno
Data_
nascita
CF
cognome
Indirizzo (0,1)
indirizzo
Persona
Interno (0,1)
Data_
nascita
CF
27
Eliminazione di attributi composti
Due possibilità:
a) considerare l’attributo composto come
insieme di attributi singoli
Problema: si perde la nozione di
collegamento tra gli attributi
b) eliminare le componenti individuali
considerando solo i valori aggregati
Problema: il singolo attributo deve poi
essere scisso dall’applicazione per
individuare i valori separati
28
Esempio
COGNOME
PERSONA
ETA`
SESSO
VIA
INDIRIZZO
CITTA`
STATO
(a) Schema con un attributo composto
PERSONA
COGNOME
ETA`
SESSO
VIA
CITTA`
PERSONA
COGNOME
ETA`
SESSO
INDIRIZZO
STATO
(b) Attributo composto ridotto nelle
sue componenti
(c) Attributo composto considerato come
attributo singolo
29
Eliminazione degli attributi
multivalore dalle entità
• Ogni attributo a molti valori è
rappresentato da un'entità, in cui può
essere rappresentato come attributo a
singolo valore.
• La nuova entità contiene l’attributo a
molti valori più l’identificatore
dell’entità di origine.
• L’identificatore della nuova entità è
l’insieme di tutti gli attributi.
30
Attributi multivalore di entità
E1
A
B (1,n)
A
R
E1
A
E1
EAM
EAM
B
A
B
31
Esempio
CODICE_PRODOTTO
PRODOTTO
CODICE_MATERIALE (1,n)
DESCRIZIONE
PREZZO
PRODOTTO
CODICE_PRODOTTO
DESCRIZIONE
PREZZO
PRODOTTO_MATERIALE
CODICE_PRODOTTO
CODICE_MATERIALE
32
Eliminazione degli attributi
multivalore dalle relazioni
• Attributo a molti valori appartiene alla
relazione R tra le entità E1 e E2
nuova entità NE che include 1 o 2 attributi
presi da E1 o E2 (o entrambi) in funzione del
tipo di relazione:
– relazione 1 a 1: NE richiede 1 degli identificatori di
E1 o E2
– relazione 1 a molti: NE comprende l’identificatore
di E2 (E2 nel lato “molti”)
– relazione molti a molti: NE comprende gli
identificatori provenienti da E1 ed E2
33
Eliminazione degli attributi
multivalore dalle relazioni
• La chiave primaria di NE è costituita
da:
–tutti gli attributi di NE provenienti
da E1 ed E2
–l’attributo multi valore
• Gli attributi non multivalore di R
rimangono a R.
34
Attributi a molti valori di relazioni
C
E1
E1
C
R
(0,n)
A
B (1,n)
R
E2
(0,m)
E2
A
D
D
Attrib
B
B
C
D
35
Esempio
CF_INSEGNANTE
INSEGNANTE
DIPARTIMENTO
TELEFONO
(0,m)
TIENE
MAX_NUM_STUD
SEMESTRE (1,n)
(1,n)
CORSO
NUM_CORSO
36
eliminazione di attributo multivalore
da una relazione tramite creazione
di entità separate
CF_INSEGNANTE
INSEGNANTE
DIPARTIMENTO
TELEFONO
(0,m)
TIENE
MAX_NUM_STUD
(1,n)
CORSO
OFFERTA_
CORSI
NUM_CORSO
CF_INSEGNANTE
NUM_CORSO
SEMESTRE
37
Scelta degli identificatori
• Un attributo che ammette valori nulli non può
essere un identificatore.
• La scelta tra due identificatori alternativi avviene
in base alla semplicità.
• Occorre considerare anche la presenza di
eventuali identificatori esterni.
• Conviene preferire gli identificatori che vengono
utilizzati dal maggior numero di operazioni.
• In alcuni casi, può convenire creare “ad arte” un
codice che serva da identificatore. Questo
potrebbe essere creato automaticamente dal
DBMS o sarà l’applicazione a dover gestire la
creazione e l’unicità del codice.
38
Eliminazione di identificatori esterni
Gli identificatori esterni sono trasformati
in identificatori interni.
ID
E1
A
E1
B
E2
B
A
(1,1)
R
(1,n)
E2
B
39
Esempio
CODICE UNIVERSITÀ
UNIVERSITÀ
NOME
CITTÀ
ISCRIVE
MATRICOLA_STUDENTE
STUDENTE
COGNOME
ETÀ
(a) Schema iniziale
40
Esempio
CODICE UNIVERSITÀ
UNIVERSITÀ
NOME
CITTÀ
+
STUDENTE
CODICE UNIVERSITÀ
MATRICOLA_STUDENTE
COGNOME
ETÀ
(b) Schema finale
41
Eliminazione di identificatori esterni
A
E1
R1
E2
A
E1
ID1
B
E2
A
B
E3
A
B
C
R2
E3
C
ID2
42
Passo B:
traduzione nel modello relazionale
1) Traduzione di ogni entità in una tabella
2) Traduzione delle relazioni:
– le relazioni 1:1, 1:molti, molti:1 sono modellate
aggiungendo attributi a tabelle esistenti
– le relazioni molti:molti richiedono sempre la
creazione di una nuova tabella
43
Traduzione di entità
Entità = Tabella
Esempio:
IMPIEGATO
CF
NOME
COGNOME
STIPENDIO
IMPIEGATO (CF, NOME, COGNOME, STIPENDIO)
44
Riassunto
• Associazione binaria molti a molti
E1
A11
A12
(X,n)
R
AR
• E1(A11,A12)
• E2(A21,A22)
• R(A11,A21,AR)
(X,n)
E2
A21
A22
45
Riassunto
• Associazione ternaria molti a molti
E1
(X,n)
(X,n)
E3
R
A11
•
A12
•
•
AR •
E1(A11,A12)
E2(A21,A22)
E3(A31,A32)
R(A11,A21,A31,AR)
(X,n)
A31 A32
E2
A21
A22
46
Riassunto
• Associazione uno a molti con
partecipazione obbligatoria
E1
A11
A12
(1,1)
R
AR
• E1(A11,A12,A21,AR)
• E2(A21,A22)
(X,n)
E2
A21
A22
47
Riassunto
• Associazione uno a molti con
partecipazione opzionale
E1
A11
A12
(0,1)
R
AR
(X,n)
E2
A21
A22
• E1(A11,A12,A21*,AR*)
• E2(A21,A22)
Oppure
• E1(A11,A12)
• E2(A21,A22)
• R(A11,A21,AR)
48
Riassunto
• Associazione con identificatore esterno
E1
A12
A11
R
AR
(1,1)
• E1(A11,A21,A12,AR)
• E2(A21,A22)
(X,Y)
E2
A21
A22
49
Riassunto
• Associazione uno a uno con partecipazione
obbligatoria per entrambe le entita`
E1
A11
A12
(1,1)
R
AR
(1,1)
E2
A21
• E1(A11,A12,A21,AR)
• E2(A21,A22)
Oppure
• E1(A11,A12)
• E2(A21,A22,A11,AR)
A22
50
Riassunto
• Associazione uno a uno con partecipazione
opzionale per una sola entita`
E1
A11
A12
(1,1)
R
AR
• E1(A11,A12,A21,AR)
• E2(A21,A22)
(0,1)
E2
A21
A22
51
Riassunto
• Associazione uno a uno con partecipazione
opzionale per entrambe le entita`
E1
A11
A12
(0,1)
R
AR
(0,1)
E2
A21
A22
• E1(A11,A12,A21*,AR*)
• E2(A21,A22)
Oppure
• E1(A11,A12)
• E2(A21,A22,A11*,AR*)
Oppure
• E1(A11,A12)
• E2(A21,A22)
52
• R(A11,A21,AR)
Esercizio 1
•
Si vuole realizzare una base di dati per una societa’ che eroga corsi, di
cui vogliamo rappresentare i dati dei partecipanti ai corsi e dei docenti.
Per i partecipanti (circa 5000), identificati da un codice, si vuole
memorizzare il codice fiscale, il cognome, l’eta’, il sesso, il luogo di
nascita, il nome dei loro attuali datori di lavoro, i posti dove hanno
lavorato in precedenza insieme al periodo, l’indirizzo e il numero
telefonico, i corsi che hanno frequentato (i corsi sono in tutto 200) e il
giudizio finale. Si vuole rappresentare anche i seminari che stanno
attualmente frequentando, e per ogni giorno, i luoghi e le ore dove sono
tenute le varie lezioni.
I corsi hanno un codice, un titolo e possono avere varie edizioni, con le
date di inizio e fine, e numero dei partecipanti.
Se gli studenti sono liberi professionisti, vogliamo conoscere l’area di
interesse e, se lo possiedono, il titolo. Per coloro che lavorano alle
dipendenze di altri, vogliamo conoscere il livello ricoperto e la
posizione.
Per gli insegnanti (circa 300) rappresentiamo il cognome, l’eta’ il posto
dove sono nati, il nome del corso che insegnano e di quelli che hanno
gia’ insegnato e che possono insegnare. Rappresentiamo anche tutti i
loro recapiti telefonici. Inoltre, i docenti possono essere dipendenti
interni della societa’ o collaboratori esterni.
53
Operazioni
1.
2.
3.
4.
5.
6.
7.
8.
inserisci un nuovo partecipante: 40 volte al giorno
assegna un partecipante ad una edizione di corso: 50
volte al giorno
inserisci un nuovo docente e i corsi che puo’ insegnare: 2
volte al giorno
assegna un docente abilitato ad una edizione di corso: 15
volte al giorno
stampa le informazioni su una edizione di corso passata,
con gli orari delle lezioni e numero dei partecipanti: 10
volte al giorno
stampa tutti i corsi offerti, con i relativi docenti abilitati: 20
volte al giorno
per ogni docente, trova tutti i partecipanti ai corsi da lui
insegnati: 5 volta alla settimana
effettua una statistica sulla votazione riportata dai
partecipanti a una edizione di corso: 10 volte al mese 54
(batch).
Tavole dei volumi
•
•
•
•
•
•
•
•
•
•
Lezione: 8000
Edizione corso: 1000
Corso: 200
Docente: 300
Collaboratore: 250
Interno: 50
Partecipante: 5000
Dipendente: 4000
Professionista: 1000
Datore: 8000
•
•
•
•
•
•
•
•
•
•
Part passata: 10000
Part corrente: 500
Composizione: 8000
Appartenenza: 1000
Collaboratore: 250
Doc passata: 900
Doc corrente: 100
Abilitazione: 500
Impiego corrente: 4000
Impiego passato: 1000
55
Schema concettuale: corso
lezione
n_partecip (1,1)
partecipante
partecipazione_
corrente
(0,n)
(0,n)
(0,n)
(0,n)
giorno
aula
orario
composizione
(1,n)
edizione_corso
(1,1)
data_
fine
data_
inizio
appartenenza
votazione partecipazione_
passata
(0,n)
corso
codice
titolo
56
Schema concettuale: partecipante
cognome
CF
sesso
codice
eta’ citta’_nascita
partecipante
(p,e)
dipendente
posizione livello
professionista
area titolo_professionale
57
Schema concettuale:
datore di lavoro
indirizzo
nome telefono
data_inizio
occupazione_
attuale
(0,n)
datore_di_lavoro
(0,n)
partecipante
(0,n)
occupazione_
passata
(p,e)
data_inizio
data_fine
(1,1)
dipendente
professionista
58
Schema concettuale: docente
edizione_corso
(1,1)
(0,1)
appartenenza
(0,1)
docenza_
corrente
(0,n)
corso
(1,n)
(1,n)
abilitazione
docenza_
passata
(0,1)
(0,n)
docente
(t,e)
collaboratore
CF
cognome
tel (0,n)
eta’
citta’_nascita
interno
59
Mantenere attributo derivato n_partecip?
• Tra le operazioni specificate, solo le
prestazioni delle operazioni 2 e 5
vengono influenzate da n_partecip.
• Non conviene tenerlo perche’ in questo
caso ci sono svantaggi:
– nell’occupazione aggiuntiva (4Kb)
– stesso numero di accessi (490) che in
assenza di dato derivato
60
Calcolo accessi con n_partecip presente
• Op 2 (50 volte al giorno)
tipo
concetto n. accessi
lettura partecipante
1
lettura ed_corso
1
scrittura ed_corso
1x 2
scrittura partecip_
corrente
1x2
Totale: 300 accessi
al giorno
61
Calcolo accessi con n_partecip presente
• Op 5 (10 volte al giorno)
tipo
concetto
n. accessi
lettura ed_corso
1
lettura appartenenza
1
lettura
corso
1
lettura composizione
8
lettura
8
lezione
Totale: 190 accessi
al giorno
62
Calcolo accessi con n_partecip assente
• Op 2 (50 volte al giorno)
tipo
concetto n. accessi
lettura partecipante
1
lettura ed_corso
scrittura partecip_
corrente
1
Totale: 200 accessi
al giorno
1x2
63
Calcolo accessi con n_partecip assente
• Op 5 (10 volte al giorno)
tipo
concetto
lettura ed_corso
lettura appartenenza
lettura
corso
n. accessi
1
1
1
lettura composizione
8
lettura
8
lezione
lettura partecip_
corrente
Totale: 290 accessi
al giorno
10
64
Eliminazione delle gerarchie
• Conviene eliminare la gerarchia dei docenti
(le operazioni non fanno distinzione e le
classi figlie non hanno attributi aggiuntivi)
• Conviene mantenere le sottoclassi della
gerarchia sui partecipanti (ci sono molti
attributi aggiuntivi che diverrebbero valori null
nella classe padre, anche se le operazioni 1,
2 e 8 non fanno differenza tra le occorrenze
dei partecipanti): introduciamo due relazioni
dati_dipendente e dati_professionista.
65
Partizionamento di concetti
• Partizionare edizione_corso in passato
e corrente? (operazione 5 considera
solo le edizioni passate)
– Non conviene perche’ si dovrebbero
duplicare le relazioni composizione e
appartenenza;
– Inoltre, le operazioni 7 e 8 non fanno
distinzione tra le edizioni di corso correnti e
passate.
66
Accorpamento di concetti
• Accorpare docenza_passata e docenza_corrente?
(e analogamente partecipazione_passata e
corrente?)
– Conviene perche’ le operazioni 7 e 8 non fanno
differenza tra le occorrenze passate e correnti
– Inoltre, non si dovrebbero spostare le occorrenze di
docenza e partecipazione correnti in quelle passate una
volta terminata l’edizione del corso.
– C’e’ pero’ lo svantaggio che c’e’ uno spreco di memoria
per rappresentare l’attributo votazione anche per le
partecipazioni correnti. Tuttavia, la frazione del numero
totale di occorrenze di partecipazioni correnti e’ piccola
rispetto a quelle passate (1/20, e si sprecano solo 2 Kb
nell’ipotesi di allocare 4 bytes per ciascuna votazione).
67
Scelta degli identificatori principali
• Scegliamo il codice interno per identificare i
partecipanti.
• Invece assegnamo un codice ad-hoc per
identificare l’edizione corsi invece di usare la
coppia (data_inizio,codice_corso) che
rappresenta un identificatore troppo “pesante”
(e viene usato per rappresentare anche le
relazioni partecipazione e docenza).
68
Schema ER ristrutturato: corso
lezione
giorno
aula
orario
(1,1)
composizione
partecipante
partecipazione
(0,n)
(0,n)
(1,n)
edizione_corso
(1,1)
votazione (0,1)
data_fine
data_inizio
codice
appartenenza
(0,n)
corso
codice
titolo
69
Schema ER ristrutturato: partecipante
cognome
CF
sesso
codice
eta’ citta’_nascita
partecipante
(0,1)
dati_dip
(1,1)
dipendente
posizione livello
(0,1)
dati_prof
(1,1)
professionista
area titolo_professionale
70
Schema ER ristrutturato: docente
telef_docente
edizione_corso
(0,1)
(1,1)
appartenenza
intestazione telefono
docenza
(0,n)
(0,n)
corso
(1,1)
(1,n)
(1,n)
abilitazione
(0,n)
CF
cognome
tel (0,n)
eta’
citta’_nascita
docente
tipo
71
indirizzo
nome telefono
Schema ER ristrutturato: datore
data_inizio
(0,n)
occupazione_
datore_di_lavoro
attuale
cognome codice
CF sesso
eta’ citta’_nascita
(0,n)
partecipante
(0,1)
dati_dip
(1,1)
(1,1)
dipendente
posizione livello
occupazione_
(0,n) passata
(0,1)
dati_prof
(1,1)
professionista
data_fine
data_inizio
area titolo_professionale
72
Traduzione nel modello relazionale
•
•
•
•
•
•
•
•
•
•
•
•
Edizione_corso(codice, data_inizio, data_fine, corso, docente)
Lezione(ora, aula, giorno, edizione_corso)
Docente(CF, cognome, eta’, citta’_nascita, tipo)
Telefono(numero, docente)
Corso(codice, nome)
Abilitazione(corso, docente)
Partecipante(codice, CF, cognome, eta’, citta’_nascita, sesso)
Partecipazione(partecipante, edizione_corso, votazione*)
Datore(nome, telefono, indirizzo)
Occupazione_passata(partecipante, datore, data_inizio, data_fine)
Professionista(partecipante, area, titolo*)
Dipendente(partecipante, livello, posizione, datore, data_inizio)
73
Schema relazionale della
societa’ di formazione
•
•
•
•
•
•
•
•
•
•
•
•
Edizione_corso(codice, data_inizio, data_fine, corso, docente)
Lezione(ora, aula, giorno, edizione_corso)
Docente(CF, cognome, eta’, citta’_nascita, tipo)
Telefono(numero, docente)
Corso(codice, nome)
Abilitazione(corso, docente)
Partecipante(codice, CF, cognome, eta’, citta’_nascita, sesso)
Partecipazione(partecipante, edizione_corso, votazione*)
Datore(nome, telefono, indirizzo)
Occupazione_passata(partecipante, datore, data_inizio, data_fine)
Professionista(partecipante, area, titolo*)
Dipendente(partecipante, livello, posizione, datore, data_inizio)
74