Il modello Entity-Relationship
impiegato
datore
lavoro
Ente
persona
Il modello Entity-Relationship
1
Modello Entity-Relationship
(Entità-Relazione)
Proposto da Peter S. Chen nel 1976,
rappresenta uno “standard de facto” per la
progettazione concettuale di una base dati
Ha una rappresentazione grafica
Esistono molti dialetti E/R, che spesso si
differenziano solo per la notazione grafica
adottata (es. modello EER = enhanced E/R)
Il modello Entity-Relationship
2
I costrutti del modello E-R






Entità
Relationship (relazione, o associazione)
Attributo
Identificatore
Generalizzazione
….
Il modello Entity-Relationship
3
Entità
 Classe di oggetti (fatti, persone, cose) dell’applicazione di
interesse con proprietà comuni e con esistenza “autonoma”
ai fini dell’applicazione
 Ha una esistenza indipendente dalle proprietà ad essa
associate
 Esempi:
 impiegato, città, conto corrente, ordine, fattura
 Ogni entità ha un nome che la identifica univocamente nello
schema:
• nomi espressivi
• opportune convenzioni (es. singolare)
Il modello Entity-Relationship
4
 Es. La classe dei computer
Il modello Entity-Relationship
5
Entità: schema e istanza
 Una occorrenza (o istanza) di entità è un
elemento della classe (l'oggetto stesso, la
persona stessa, …, non un valore che questo
può assumere)
 nello schema concettuale rappresentiamo le
entità, non le singole istanze
Il modello Entity-Relationship
6
Rappresentazione grafica di
entità
Impiegato
Dipartimento
Città
Vendita
Il modello Entity-Relationship
7
Relationship (Associazione)
 Legame logico fra due o più entità, rilevante
nell’applicazione di interesse
 Esempi:


Residenza (fra le entità Persona e Città)
Esame (fra Studente e Corso)
 In inglese relationship, viene tradotto con
associazione o relazione (da non confondere con la
relazione, da relation, nel modello relazionale)
Il modello Entity-Relationship
8
impiegato
datore
lavora in
Ente
persona
Il modello Entity-Relationship
9
Rappresentazione grafica
di relationship
Studente
Esame
Corso
Impiegato
Residenza
Città
Il modello Entity-Relationship
10
Relationship, commenti
 Ogni relationship ha un nome che la
identifica univocamente nello schema:


nomi espressivi
opportune convenzioni
singolare
 sostantivi invece che verbi (se possibile)

Il modello Entity-Relationship
11
Relationship, occorrenze
 Una occorrenza di una relationship binaria è una
coppia di occorrenze di entità, una per ciascuna
entità coinvolta
 Una occorrenza di una relationship n-aria è una nupla di occorrenze di entità, una per ciascuna entità
coinvolta
 Nell'ambito di una relationship non ci possono
essere occorrenze (coppie, ennuple) ripetute
Il modello Entity-Relationship
12
entità E1
istanza di E1
entità E2
associazione
A tra E1 ed E2
occorrenza di A
Il modello Entity-Relationship
13
Relationship corrette
Studente
Esame
Corso
Paziente
Visita
Medico
Il modello Entity-Relationship
14
Esempi di occorrenze
E1
Rossi
E2
Algebra
E3
Verdi
Bianchi
Fisica
E4
Pepi
Studente
Il modello Entity-Relationship
Analisi
Corso
15
 Per definizione l’insieme delle istanze di un'associazione è
un sottoinsieme del prodotto Cartesiano degli insiemi delle
istanze di entità che partecipano all’associazione
 Ne segue che non possono esservi istanze ripetute
nell’associazione
Studente
Esame
Corso
 Se s è uno Studente e c un Corso, la coppia (s,c) può
comparire un’unica volta nell'insieme delle istanze di Esame
Il modello Entity-Relationship
16
Grado di una relazione
 È il numero di istanze di entità che sono coinvolte in
un’istanza dell’associazione
 associazione binaria: grado = 2
Persona
Lavoro
Città
 associazione ternaria: grado = 3
Impiegato
Assegnazione
Progetto
Sede
Il modello Entity-Relationship
17
Due relationship sulle stesse
entità
Sede di
lavoro
Impiegato
Residenza
Il modello Entity-Relationship
Città
18
Relationship ricorsiva:
coinvolge “due volte” la stessa entità
Conoscenza
Persona
Il modello Entity-Relationship
19
Relationship ricorsiva con
“ruoli”
Successione
Successore
Sovrano
Predecessore
Il modello Entity-Relationship
20
Relationship ternaria ricorsiva
È
possibile avere anelli anche in relazioni n-arie
generiche (n > 2)
dirige
Direzione
Dipendente
Progetto
diretto
Il
significato di una occorrenza (d1,d2,p) è:
il dipendente d1 dirige il dipendente d2 all’interno del
progetto p
Il modello Entity-Relationship
21
Un database sul sistema universitario
Studente
esame
Corso
base
propedeutico
avanz
frequenza
commissione docente
Professore
iscrizione
offerta
CorsodiLaurea
Attributo
 Proprietà elementare di un’entità o di una
associazione, di interesse ai fini
dell’applicazione
 Associa ad ogni occorrenza di entità o
relationship un valore appartenente a un
insieme detto dominio dell’attributo
(contiene i valori ammissibili per l’attributo)
Il modello Entity-Relationship
23
Attributi, rappresentazione
grafica
Cognome
Nome Data
Studente
Matricola
Voto
Esame
Titolo
Corso
Codice
data e voto non sono proprietà né di uno Studente né di
un Corso, ma del legame Studente-Corso che si crea in
occasione di un esame
24
Attributi composti
 Raggruppano attributi di una medesima
entità o relationship che presentano affinità
nel loro significato o uso
 Esempio:

Via, Numero civico e CAP formano un Indirizzo
Il modello Entity-Relationship
28
Rappresentazione grafica
Cognome
Impiegato
Età
Indirizzo
Via
Numero
CAP
Il modello Entity-Relationship
29
Cognome
Telefono
Direzione
Impiegato
Dipartimento
Afferenza
Codice
Nome
Composizione
Partecipazione
Data
Progetto
Budget
Nome
Sede
Via
Indirizzo
CAP
Città
nome
nome ciclo
telefono
matricola
Studente
data
esame
voto
base
Corso
propedeutico
avanz
indirizzo
via
segue
commissione
docente
città
Professore
nome
cognome
data_nascita
cod_id
offre
nome
iscritto
CorsodiLaurea
In ogni schema E/R sono presenti dei vincoli
Alcuni sono impliciti, in quanto dipendono dalla
semantica stessa dei costrutti del modello:
ogni occorrenza di associazione deve riferirsi a
istanze di entità
occorrenze diverse della stessa associazione devono
riferirsi a differenti combinazioni di occorrenze delle
entità partecipanti all'associazione
Altri vincoli sono espliciti, e vengono definiti da chi
progetta lo schema E/R sulla base della conoscenza
della realtà che si sta modellando
vincoli di cardinalità (per associazioni e attributi)
vincoli di identificazione
Altri costrutti del modello E-R
 Cardinalità


di relationship
di attributo
 Identificatore


interno
esterno
 Generalizzazione
Il modello Entity-Relationship
33
Cardinalità di relationship
 Coppia di valori (x,y) associati a ogni entità
che partecipa a una relationship
 Per ogni entità E che partecipa a una
relazione R i numeri (x,y) specificano il
numero minimo e massimo di occorrenze di
R cui ciascuna occorrenza di E può
partecipare
Il modello Entity-Relationship
34
Esempio di cardinalità
(1,5)
Impiegato
(0,50)
Assegnamento
Il modello Entity-Relationship
Incarico
35
 per semplicità usiamo solo tre simboli:

0 e 1 per la cardinalità minima:
0 = “partecipazione opzionale”
 1 = “partecipazione obbligatoria”


1 e “N” per la cardinalità massima:

“N” non pone alcun limite
Il modello Entity-Relationship
36
(1,1)
Studente
(0,N)
Residenza
Città
Cardinalità di Residenza
Il modello Entity-Relationship
37
Occorrenze di Residenza
S1
R1
S2
R2
S3
C1
C2
R3
S4
C3
R4
Studente
Il modello Entity-Relationship
C4
Città
38
Tipi di relationship
 Le relationship si distinguono con
riferimento alle cardinalità massime;
abbiamo relationship:



uno a uno
uno a molti
molti a molti
(x,1) — (x,1);
(x,1) — (x,N);
(x,N) — (x,N),
dove x può valere 0 oppure 1
Il modello Entity-Relationship
39
m
n
Relationship “molti a molti”
(0,N)
Studente
(0,N)
Corso
Esame
(0,N)
Montagna
(1,N)
Scalata
Alpinista
(1,N)
Macchinista
(1,N)
Abilitazione
Locomotore
Relationship “uno a molti”
(0,1)
Persona
C1
C2
(0,N)
Impiego
Azienda
(1,1)
Cinema
(0,N)
Ubicazione
Località
(1,1)
Comune
(1,N)
Ubicazione
Provincia
Relationship “uno a uno”
C1
Professore
di ruolo
Professore
di ruolo
(1,1)
C2
(0,1)
Corso
Titolarità
(1,1)
(1,1)
Titolarità
Cattedra
Cardinalità: altri esempi
Persona
(1,1)
Studente
(1,1)
Persona
(0,n)
Studente
(0,n)
Persone
(0,n)
Risiede
Risiede
Lavora
Esame
Ha
(1,n)
(0,n)
(0,n)
(0,n)
(1,n)
Città
Città
Città
Corso
Telefono
Cardinalità di attributi
 E’ possibile associare delle cardinalità anche agli
attributi, con due scopi:


indicare opzionalità ("informazione incompleta")
indicare attributi multivalore
Il modello Entity-Relationship
44
Rappresentazione grafica
(0,N)
Telefono
Nome
Impiegato
(0,1)
Numero patente
Il modello Entity-Relationship
45
Il modello Entity-Relationship
46
Attributi ripetuti e composti
Nel caso di presenza di più attributi multivalore, la
creazione di un attributo composto può rendersi
necessaria per evitare ambiguità
Ad esempio, se una persona ha più indirizzi…
Persona
(1,n)
indirizzo
…non si può rappresentarlo così!
Persona
via
n.civico
città
CAP
via (1,n)
n.civico (1,n)
città (1,n)
CAP (1,n)
47
Identificatore di una entità
 “strumento” per l’identificazione univoca
delle occorrenze di un’entità
 “minimale”: nessun sottoinsieme proprio
dell’identificatore deve a sua volta essere
identificatore
 costituito da:


attributi dell’entità: identificatore interno
(attributi dell’entità +) entità esterne attraverso
relationship: identificatore esterno
Il modello Entity-Relationship
48
Identificatori interni: si usano uno o
più attributi dell’entità
Targa
Automobile
Modello
Proprietario
Persona
Indirizzo
Data Nascita
Cognome
Nome
49
Cognome Matricola
Nome
(1,1)
Studente
Anno di corso
(0,N)
Iscrizione
Università
Indirizzo
Identificatore esterno: l’entità è identificata da una o più entità
collegate a essa da associazioni, più eventuali attributi dell’entutà
stessa
Il modello Entity-Relationship
50
Alcune osservazioni
 ogni entità deve possedere almeno un identificatore, ma
può averne in generale più di uno
 un identificatore può coinvolgere uno o più attributi,
ognuno dei quali deve avere cardinalità (1,1)
 una identificazione esterna è possibile solo attraverso una
associazione a cui l’entità da identificare partecipa con
cardinalità (1,1)
Modello
Nome
AUTOMOBILE
CASA COSTR.
COSTR.
(1,1)
(1,N)
Il modello Entity-Relationship
51
Identificatori: esempi da non seguire
Errore !!
A1
B1
E1
E2
R
(1,1)
(1,N)
Titolo
FILM
Nome
(1,N)
ATTORE
RECITA
(1,N)
Errore !!
Attenzione al formalismo grafico
usato per gli identificatori esterni.
Non si può usare l’entità ATTORE per
identificare l’entità FILM: la cardinalità
card(FILM, RECITA) dovrebbe essere
(1,1), ma ciò è in netto contrasto con la
semantica del problema.
Il modello Entity-Relationship
52
Note sugli attributi di una
associazione (1)
 È importante fare attenzione all’uso di attributi in un’associazione!
R
A
a1
a2
...
an
r1, r2, ...,rs
b1
b2
...
bm
B
d
 Ogni istanza rk dell’associazione R è dotata di un proprio valore per
l’attributo d; d’altro canto la semantica dell’E/R impedisce di usare
d per identificare le istanze di R.
Il modello Entity-Relationship
53
Note sugli attributi di una
associazione (2)
(0, N)
(0, N)
UOMO
MATRIM.
DONNA
Non possono esservi due istanze
dell’associazione (Ui,Dj,d1) e
(Ui,Dj,d2), dunque un uomo e una
donna non possono risposarsi.
DONNA
Un uomo può risposare la stessa
donna più volte
data
(0, N)
(0, N)
UOMO
MATRIM.
(1, N)
data
Il modello Entity-Relationship
54
Note sugli attributi di una
associazione (3)
Se gli attributi sono più di uno e ripetuti, la soluzione più elegante
consiste nell’introduzione di una nuova entità.
MEDICO
MEDICO
(0, N)
(0, N)
esito
esito
VISITA
(0, N)
(1, N)
VISITA
(1, N)
(0, N)
data
data
PAZIENTE
PAZIENTE
un medico può visitare una
sola volta un paziente:
ASSURDO !
ERRATO: non è possibile
associare l’esito della visita alla
data in cui è stata effettuata
Il modello Entity-Relationship
55
Note sugli attributi di una
associazione (4)
MEDICO
MEDICO
(0, N)
(0, N)
FA_VISITA
(1, 1)
VISITA
(1, N)
(0, N)
VISITA
esito
esito
data
(1, 1)
IN_VISITA
PAZIENTE
data
(0, N)
PAZIENTE
CORRETTO
ma poco leggibile
Il modello Entity-Relationship
56
(0,1)
Cognome
(1,1)
Telefono
Direzione
Impiegato
(0,N)
(0,1)
(0,N)
Codice
Partecipazione
(1,N)
Progetto
(1,N)
Afferenza
(0,1)
Data
Dipartimento
(1,1)
Composizione
(1,N)
Sede
Via
Indirizzo
Budget
Nome
Nome
CAP
Città
Generalizzazione
 mette in relazione una o più entità E1, E2, ..., En con
una entità E, che le comprende come caso
particolare
 E è generalizzazione di E1, E2, ..., En
 E1, E2, ..., En sono specializzazioni di E
E
E1
E2
…
Il modello Entity-Relationship
En
58
Rappresentazione grafica
Dipendente
Impiegato
Funzionario
Il modello Entity-Relationship
Dirigente
59
Proprietà delle generalizzazioni
Se E (genitore) è generalizzazione di E1, E2, ..., En (figlie)

ogni proprietà (attributi, identificatori, associazioni)
dell’entità padre E è proprietà anche delle entità figlie
E1, E2, ..., En

ogni occorrenza di un’entità figlia E1, E2, ..., En è
occorrenza anche dell’entità padre E
Il modello Entity-Relationship
60
Città
(0,N)
Nascita
(1,1)
Persona
Codice
fiscale
Nome
Età
Stipendio
Lavoratore
Studente
Ereditarietà
 tutte le proprietà (attributi, relationship, altre
generalizzazioni) dell’entità genitore vengono
ereditate dalle entità figlie e non rappresentate
esplicitamente
 naturalmente le entità figlie possono avere alcune
proprietà in più rispetto all'entità genitore, e queste
devono essere rappresentate
Il modello Entity-Relationship
62
Tipi di generalizzazioni
 totale se ogni occorrenza dell'entità genitore è
occorrenza di almeno una delle entità figlie,
altrimenti è parziale
 esclusiva se ogni occorrenza dell'entità genitore è
occorrenza di al più una delle entità figlie,
altrimenti è sovrapposta
 consideriamo (senza perdita di generalità) solo
generalizzazioni esclusive e distinguiamo fra totali
e parziali
Il modello Entity-Relationship
63
Persona
Generalizzazione parziale
esclusiva
Disoccupato
Lavoratore
Il modello Entity-Relationship
64
Persona
Generalizzazione totale
esclusiva
Uomo
Il modello Entity-Relationship
Donna
65
Altre proprietà
 possono esistere gerarchie a più livelli e
multiple generalizzazioni allo stesso livello
 un'entità può essere inclusa in più gerarchie,
come genitore e/o come figlia
Il modello Entity-Relationship
66
Gerarchie a più livelli
PERSONA
esistono anche altri ruoli
(t,e)
UOMO
(p,e)
DONNA
MANAGER
IMPIEGATO
(t,s)
MANAGER
TECNICO
(p,s)
MANAGER
AMMINISTR.
alcuni manager possono
ricoprire entrambi i ruoli
TECNICO
COMMERC.
AMMINISTR
esistono anche altri tipi di impiegati; alcuni
impiegati possono avere più mansioni
Il modello Entity-Relationship
67
Sottoinsieme
È un caso particolare di gerarchia in cui si
evidenzia una sola classe specializzata
nome
Persona
data_nascita
matricola
 Studente eredita le
proprietà di Persona e in
più ha la matricola
ogni Studente è anche
una Persona
Studente
Il modello Entity-Relationship
68
Esercizio
Le persone hanno CF, cognome ed età; gli uomini anche
la posizione militare; gli impiegati hanno lo stipendio e
possono essere segretari, direttori o progettisti (un
progettista può essere anche responsabile di progetto);
gli studenti (che non possono essere impiegati) un
numero di matricola; esistono persone che non sono né
impiegati né studenti (ma i dettagli non ci interessano);
per ogni studente si vuole conoscere l’università alla
quale è iscritto, l’anno di iscrizione e la sede di tale
università. Per ogni persona si rappresenta anche la città
in cui vive, la provincia e il CAP di tale città.
Il modello Entity-Relationship
69
Ereditarietà delle proprietà
 Gli attributi comuni lungo una gerarchia vanno
riferiti all’entità più generica in cui sono presenti
 Analogamente per le associazioni, quindi questo
schema non è corretto
CdL
(0,n)
Iscritta
(0,1)
matricola (0,1)
Persona
dipartimento (0,1)
(t,e)
nome
Studente
Il modello Entity-Relationship
Professore
nome
70
Ereditarietà delle proprietà
 Gli attributi comuni lungo una gerarchia vanno
riferiti all’entità più generica in cui sono presenti
obbligatoriamente
 Questo è lo schema corretto
CdL
(0,n)
Iscritta
(0,1)
Persona
nome
(t,e)
dipartimento
matricola
Studente
Il modello Entity-Relationship
Professore
71
Osservazioni (1)
Nell’ambito della progettazione concettuale E/R le gerarchie di
generalizzazione non sono normalmente impiegate per modellare
aspetti dinamici della realtà di interesse.
Nome
PERSONA
Data di nascita
(t,e)
Nome
Data di nascita
UOMO
UOMO
(0, N)
CONTRAE_D
Nome moglie
(1, 1)
UOMO SPOSATO
MATRIMONIO
Data nasc. moglie
data_matrimonio
(1, 1)
data di matrim.
CONTRAE_U
(0, N)
DONNA
72
Osservazioni (2)
Attenzione a non confondere entità con istanze di entità
tentando di modellare attraverso gerarchie la conoscenza di
specifiche istanze.
Esempio: ... un campeggio è diviso in tre aree (spiaggia,
centrale, ingresso) ognuna delle quali è caratterizzata da
una certa tariffa ...
AREA
AREA
Tipo Area
Tariffa
SPIAGGIA
Tariffa
spiaggia
CENTRALE
INGRESSO
Tariffa centrale
Tariffa ingresso
73
Osservazioni (3)
 Attenzione a non modellare attraverso gerarchie i ruoli che un’entità
assume in diversi periodi temporali o in relazione ad altre entità:
Esempio: ...un circolo di tennis organizza periodicamente alcuni tornei
riservati ai soci... gli arbitri delle partite sono soci che non partecipano
al torneo...
Tessera
Nome
SOCIO
(t,e)
GIOCATORE
Data
ARBITRO
arbitra
(0,N)
Tessera
Nome
SOCIO
arbitra
PARTITA
(1,1)
Data
PARTITA
Il modello Entity-Relationship
Il ruolo di ARBITRO è
temporaneo (in un altro
torneo lo stesso SOCIO
potrebbe partecipare
come GIOCATORE). Il
vincolo che gli arbitri
delle partite di un torneo
non partecipino al torneo
stesso va modellato
dinamicamente.
74
Note sulle ternarie (1)
 Quando in un’associazione ternaria esistono dipendenze funzionali tra le entità
in gioco è preferibile sostituire la ternaria con una coppia di binarie (che
modellano esplicitamente i vincoli del problema).
CORSO
CORSO
(1, 3)
DI
(1, 3)
SI TIENE
(0, 40)
preferibile
AULA
(1, 1)
LEZIONE
orario
(1, 1)
(0, N)
SI TIENE
(0, 40)
ORARIO
AULA
Per gestire il seguente vincolo:
in un certo ORARIO della settimana si può tenere solo una lezione (in una specifica
AULA) di un CORSO, ovvero:
CORSO, ORARIO  AULA
Il modello Entity-Relationship
75
Note sulle ternarie (2)
Il modello Entity-Relationship
76
Note sull’effetto del tempo
Fotografia dei corsi attivati in un anno accademico
nome ciclo
cod_corso
Corso
data_nascita
(1,1)
responsabilità
(0,n)
Docente
nome
cognome
cod_doc
Il modello Entity-Relationship
77
Note sull’effetto del tempo
La storia considerando più anni accademici
AA
ciclo
(1,1)
Corso_AA
responsabilità
(0,n)
Docente
nome
cognome
data_nascita
cod_doc
(1,1)
attivato
(0,n)
Corso
cod_corso
nome
Il modello Entity-Relationship
78
Riassunto della notazione grafica
o Entità
o Associazione
o Attributo
o Attributo composto
o Identificatore
o Gerarchia di
generalizzazione
o Sottoinsieme
o Vincoli di cardinalità
(min-card,max-card)
Errori comuni in schemi E-R
 In tutti i casi visti si può dire che il problema nasceva da
un’analisi poco accurata, che portava a soluzioni intuitive ma
non adeguate
 I nomi di entità e associazioni alle volte traggono in inganno: è
bene quindi, nel caso si presentino situazioni poco chiare,
provare a ragionare anche in termini di istanze (cosa “contiene”
effettivamente questa entità/associazione?)
 Quando, come praticamente sempre accade, interviene la
variabile “tempo” è bene chiedersi quali sono gli aspetti che si
vogliono modellare che sono indipendenti dal tempo e quali
viceversa variano dinamicamente
Il modello Entity-Relationship
80
Utilità del modello E/R
Uno schema E/R è più espressivo di uno schema relazionale, inoltre
può essere utilizzato con successo per alcuni compiti diversi dalla
progettazione, ad esempio:
 Documentazione: la simbologia grafica del modello E/R può
essere facilmente compresa anche dai non “addetti ai lavori”
 Reverse engineering: a partire da un DB esistente si può fornirne
una descrizione in termini E/R allo scopo di migliorare l’analisi
del contesto applicativo ed eventualmente procedere a
un’operazione di riprogettazione
 Integrazione di sistemi: essendo indipendente dal modello logico
dei dati, è possibile usare il modello E/R come “linguaggio
comune” in cui rappresentare DB eterogenei (es. relazionale,
gerarchico, a oggetti), allo scopo di costruire un DB integrato
Il modello Entity-Relationship
81
Documentazione associata agli
schemi concettuali
Uno schema E-R non è quasi mai sufficiente da solo a
rappresentare nel dettaglio tutti gli aspetti di della realtà di
interesse:
1. I nomi dei vari concetti possono non essere sufficienti per
comprenderne il significato;
2. I costrutti del modello non esprimono direttamente tutte le
proprietà dei dati rappresentati né alcuni vincoli, es.
•
•
“per sostenere un esame è necessario avere sostenuto tutti gli
esami propedeutici”
“un laureando deve aver sostenuto almeno tutti gli esami dei primi
anni”
 In fase di progettazione bisogna quindi fornire un’ulteriore
documentazione appropriata a corredo dello schema
Il modello Entity-Relationship
82
Documentazione associata agli
schemi concettuali
Il modello Entity-Relationship
83
Documentazione associata agli
schemi concettuali
Risulta necessario corredare ogni schema E-R con
una documentazione di supporto
 dizionario dei dati per le entità e per le relationship;
 documentazione dei vincoli non esprimibili.
 NOTA: vincoli e derivazioni sono esprimibili nei
modelli logico e fisico, attraverso opportune
clausole SQL oppure procedure di un linguaggio di
programmazione
Il modello Entity-Relationship
84
(0,1)
Cognome
(1,1)
Telefono
Direzione
Impiegato
Codice
(0,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à
Dizionario dei dati (entità)
Entità
Impiegato
Progetto
Descrizione
Dipendente
dell'azienda
Progetti
aziendali
Dipartimento Struttura
aziendale
Sede
Sede
dell'azienda
Attributi
Codice,
Cognome,
Stipendio
Nome,
Budget
Nome,
Telefono
Città,
Indirizzo
Il modello Entity-Relationship
Identificatore
Codice
Nome
Nome,
Sede
Città
86
Dizionario dei dati (relationship)
Relazioni
Direzione
Descrizione
Direzione di un
dipartimento
Afferenza
Afferenza a un
dipartimento
Partecipazione Partecipazione
a un progetto
Composizione Composizione
dell'azienda
Componenti Attributi
Impiegato,
Dipartimento
Impiegato,
Data
Dipartimento
Impiegato,
Progetto
Dipartimento,
Sede
Il modello Entity-Relationship
87
Vincoli non esprimibili
(regole aziendali)
Vincoli di integrità sui dati
(1) Il direttore di un dipartimento deve a afferire a tale
dipartimento
(2) Un impiegato non deve avere uno stipendio
maggiore del direttore del dipartimento al quale
afferisce
(3) Un dipartimento con sede a Roma deve essere
diretto da un impiegato con più di dieci anni di
anzianità
(4) Un impiegato che non afferisce a nessun
dipartimento non deve partecipare a nessun un
progetto
88
Regole aziendali
 Una regola aziendale può essere:



La descrizione di un concetto rilevante per
l'applicazione (entità, attributo, associazione);
Un vincolo di integrità sui dati dell'applicazione;
Una derivazione: un concetto che può essere
ottenuto attraverso un'inferenza o un calcolo
aritmetico, da altri concetti dello schema
(ES. costo=netto+tasse)
Il modello Entity-Relationship
89
Modellazione dati in UML
 UML = Unified Modeling Language, formalismo
per la modellazione completa di applicazioni
software:



dati
operazioni
processi
secondo il paradigma della programmazione a
oggetti
 Fornisce nuove tipologie di diagrammi
Il modello Entity-Relationship
90
Esercizi
Rappresentare le seguenti realtà utilizzando i costrutti del modello
E-R e introducendo solo le informazioni specificate:
1.
In un giardino zoologico ci sono degli animali appartenenti a
una specie e aventi una certa età; ogni specie è localizzata in un
settore (avente un nome, una locazione e un codice
identificativo) dello zoo. Gli animali dello zoo possono essere
nati all’interno dello zoo, oppure essere stati acquistati; nel
primo caso si vuol sapere il nome dei genitori dell’animale, nel
secondo caso interessa il paese di provenienza.
2.
Una casa discografica produce dischi aventi un codice, un titolo
e un numero di tracce; ogni disco è inciso da uno o più cantanti,
ognuno dei quali ha un nome, data di nascita, indirizzo e,
qualcuno, un nome d'arte.
Il modello Entity-Relationship
91
3. Gli impiegati di una azienda sono dirigenti,
programmatori, analisti, capi progetto e
segretari. Ci sono analisti che sono anche
programmatori. I capi progetto devono
essere dirigenti. Gli impegati hanno un
codice, un nome, e un cognome. Ogni
categoria di impiegato ha un proprio
stipendio base. Ogni impegato, tranne i
dirigenti, ha un proprio orario di lavoro.
Il modello Entity-Relationship
92