Il modello Entity-Relationship1 persona Ente lavoro impiegatodatore.
-
Upload
angelo-lorusso -
Category
Documents
-
view
215 -
download
0
Transcript of Il modello Entity-Relationship1 persona Ente lavoro impiegatodatore.
Il modello Entity-Relationship 1
Il modello Entity-Relationship
persona Ente
lavoro
impiegato datore
Il modello Entity-Relationship 2
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 graficaEsistono molti dialetti E/R, che spesso si
differenziano solo per la notazione grafica adottata (es. modello EER = enhanced E/R)
Il modello Entity-Relationship 3
I costrutti del modello E-R
Entità Relationship (relazione, o associazione) Attributo Identificatore Generalizzazione ….
Il modello Entity-Relationship 4
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 5
Es. La classe dei computer
Il modello Entity-Relationship 6
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 7
Rappresentazione grafica di entità
Impiegato Dipartimento
Città Vendita
Il modello Entity-Relationship 8
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 9
persona Ente
lavora in
impiegato datore
Il modello Entity-Relationship 10
Rappresentazione grafica di relationship
EsameStudente Corso
ResidenzaImpiegato Città
Il modello Entity-Relationship 11
Relationship, commenti
Ogni relationship ha un nome che la identifica univocamente nello schema: nomi espressivi opportune convenzioni
singolaresostantivi invece che verbi (se possibile)
Il modello Entity-Relationship 12
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 n-upla 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 13
entità E1
entità E2
istanza di E1
associazione A tra E1 ed E2
occorrenza di A
Il modello Entity-Relationship 14
Relationship corrette
EsameStudente Corso
VisitaPaziente Medico
Il modello Entity-Relationship 15
Esempi di occorrenze
Rossi
Verdi
Pepi
Bianchi
Studente
Algebra
Fisica
Analisi
Corso
E1
E2
E3
E4
Il modello Entity-Relationship 16
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
Se s è uno Studente e c un Corso, la coppia (s,c) può comparire un’unica volta nell'insieme delle istanze di Esame
Studente Esame Corso
Il modello Entity-Relationship 17
Grado di una relazione
È il numero di istanze di entità che sono coinvolte in un’istanza dell’associazione
associazione binaria: grado = 2
associazione ternaria: grado = 3
Persona Lavoro Città
Impiegato Assegnazione Progetto
Sede
Il modello Entity-Relationship 18
Due relationship sulle stesse entità
ResidenzaImpiegato Città
Sede dilavoro
Il modello Entity-Relationship 19
Relationship ricorsiva: coinvolge “due volte” la stessa entità
Persona
Conoscenza
Il modello Entity-Relationship 20
Relationship ricorsiva con “ruoli”
Successione
SovranoSuccessore Predecessore
Il modello Entity-Relationship 21
Relationship ternaria ricorsiva
È possibile avere anelli anche in relazioni n-arie generiche (n > 2)
Il significato di una occorrenza (d1,d2,p) è:
il dipendente d1 dirige il dipendente d2 all’interno del
progetto p
Dipendente Direzione
dirige
diretto
Progetto
Studente Corso
Professore
CorsodiLaurea
esame
commissione
iscrizione
offerta
frequenza docente
basepropedeutico
avanz
Un database sul sistema universitario
Il modello Entity-Relationship 23
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)
24
Attributi, rappresentazione grafica
EsameStudente Corso
Cognome Nome
Matricola
Data Titolo
Codice
Voto
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
Il modello Entity-Relationship 28
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 29
Rappresentazione grafica
Impiegato
Cognome
Età Via
Indirizzo Numero
CAP
ComposizionePartecipazione
Progetto
NomeBudget
Impiegato
Codice
Cognome Telefono
Dipartimento
NomeAfferenza
Data
Direzione
CittàIndirizzo
SedeVia
CAP
Studente Corso
Professore
CorsodiLaurea
esame
segue commissione docente
offre
iscritto
propedeutico
base
avanz
nomecognomedata_nascita
nome
nome ciclo
data voto
nome telefono
matricola
indirizzo
via città
cod_id
In ogni schema E/R sono presenti dei vincoliAlcuni 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
Il modello Entity-Relationship 33
Altri costrutti del modello E-R
Cardinalità di relationship di attributo
Identificatore interno esterno
Generalizzazione
Il modello Entity-Relationship 34
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 35
Esempio di cardinalità
AssegnamentoImpiegato Incarico
(1,5) (0,50)
Il modello Entity-Relationship 36
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 37
Cardinalità di Residenza
ResidenzaStudente Città
(1,1) (0,N)
Il modello Entity-Relationship 38
Occorrenze di Residenza
S1
S2
S4
S3
Studente
C1
C2
C3
Città
R3
R4
R2
C4
R1
Il modello Entity-Relationship 39
Tipi di relationship
Le relationship si distinguono con riferimento alle cardinalità massime; abbiamo relationship: uno a uno (x,1) — (x,1); uno a molti (x,1) — (x,N); molti a molti (x,N) — (x,N),
dove x può valere 0 oppure 1
Relationship “molti a molti”
EsameStudente Corso
(0,N) (0,N)
ScalataMontagna Alpinista
(0,N) (1,N)
AbilitazioneMacchinista Locomotore
(1,N) (1,N)
m n
Relationship “uno a molti”
ImpiegoPersona Azienda
(0,1) (0,N)
UbicazioneCinema Località
(1,1) (0,N)
UbicazioneComune Provincia
(1,1) (1,N)
C1 C2
Relationship “uno a uno”
TitolaritàProfessore
di ruoloCorso
(1,1) (0,1)
TitolaritàProfessore
di ruoloCattedra
(1,1) (1,1)
C1 C2
Cardinalità: altri esempi
Persona Risiede Città(1,1) (1,n)
Studente Risiede Città(1,1) (0,n)
Persona Lavora Città(0,n) (0,n)
Studente Esame Corso(0,n) (0,n)
Persone Ha Telefono(0,n) (1,n)
Il modello Entity-Relationship 44
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 45
Rappresentazione grafica
Impiegato
Telefono
Nome
Numero patente
(0,N)
(0,1)
Il modello Entity-Relationship 46
47
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…
…non si può rappresentarlo così!
Persona indirizzo
via
cittàn.civico
CAP
(1,n)
Persona
via (1,n)
città (1,n)
n.civico (1,n)
CAP (1,n)
Il modello Entity-Relationship 48
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
49
Identificatori interni: si usano uno o più attributi dell’entità
Persona
Data Nascita
Cognome
NomeIndirizzo
Automobile
Targa
Modello
Proprietario
Il modello Entity-Relationship 50
IscrizioneStudente Università
Cognome Matricola
Anno di corso
Nome
Indirizzo
(1,1) (0,N)
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 51
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)
COSTR.AUTOMOBILE CASA COSTR.
ModelloNome
(1,N)(1,1)
Il modello Entity-Relationship 52
Identificatori: esempi da non seguire
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.
R
A1
(1,N)(1,1)
B1
E2E1
RECITAFILM ATTORE
Titolo Nome
(1,N)
(1,N)
Errore !!
Errore !!
Il modello Entity-Relationship 53
Note sugli attributi di una associazione (1)
È importante fare attenzione all’uso di attributi in un’associazione!
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.
A B
Ra1 a2
...an
b1 b2
...bm
r1, r2, ...,rs
d
Il modello Entity-Relationship 54
Note sugli attributi di una associazione (2)
MATRIM.
data
UOMO DONNA(0, N)
(0, N)
MATRIM.
data
UOMO DONNA(0, N)
(0, N)
(1, N)
Non possono esservi due istanze dell’associazione (Ui,Dj,d1) e (Ui,Dj,d2), dunque un uomo e una donna non possono risposarsi.
Un uomo può risposare la stessa donna più volte
Il modello Entity-Relationship 55
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à.
data
MEDICO
PAZIENTE
(0, N)
VISITA
(0, N)esito
data
MEDICO
PAZIENTE
(0, N)
VISITA
(0, N)esito
(1, N)
(1, N)
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 56
Note sugli attributi di una associazione (4)
data
MEDICO
PAZIENTE
(0, N)
VISITA
(0, N)
esito
(1, N)
CORRETTOma poco leggibile
data
FA_VISITA
(1, 1)
(0, N)
IN_VISITA
(0, N)
(1, 1)
MEDICO
VISITA
PAZIENTE
esito
(1,1)(0,1)
(0,N)(0,1)
(0,1)
(1,1)
(1,N)
(0,N)
(1,N)
(1,N)
CittàIndirizzo
Telefono
Dipartimento
Composizione
Sede
Direzione
Afferenza
Impiegato
Progetto
Partecipazione
Nome
Nome
Cognome
Budget
Data
Via
CAP
Codice
Il modello Entity-Relationship 58
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 EE
E1 E2 En…
Il modello Entity-Relationship 59
Rappresentazione grafica
Dipendente
Impiegato Funzionario Dirigente
Il modello Entity-Relationship 60
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
Persona
Codice fiscale
Nome
Età
Città
Nascita
(0,N)
(1,1)
Lavoratore Studente
Stipendio
Il modello Entity-Relationship 62
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 63
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 64
Disoccupato Lavoratore
Persona
Generalizzazione parziale esclusiva
Il modello Entity-Relationship 65
Persona
Uomo DonnaUomo Donna
Generalizzazione totale esclusiva
Il modello Entity-Relationship 66
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 67
Gerarchie a più livelli
esistono anche altri ruoli
(t,e)
PERSONA
DONNAUOMO MANAGER IMPIEGATO
(p,e)
MANAGER AMMINISTR.
MANAGER TECNICO
(t,s)
TECNICO AMMINISTRCOMMERC.
(p,s)
alcuni manager possono ricoprire entrambi i ruoli
esistono anche altri tipi di impiegati; alcuni impiegati possono avere più mansioni
Il modello Entity-Relationship 68
Sottoinsieme
È un caso particolare di gerarchia in cui si evidenzia una sola classe specializzata
Persona
Studentematricola
data_nascita
nome Studente eredita le proprietà di Persona e in più ha la matricolaogni Studente è anche una Persona
Il modello Entity-Relationship 69
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 70
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
Persona
Studente Professore
(t,e)
matricola (0,1)
nomenome
Iscritta(0,1)(0,n)
CdL dipartimento (0,1)
Il modello Entity-Relationship 71
Ereditarietà delle proprietà
Gli attributi comuni lungo una gerarchia vanno riferiti all’entità più generica in cui sono presenti obbligatoriamente
Questo è lo schema corretto
Persona
Studente Professore
(t,e)
matricola
nomeIscritta(0,1)(0,n)
CdL
dipartimento
72
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.
(t,e)
Nome PERSONAData di nascita
data_matrimonio
UOMO
DONNA
CONTRAE_D
(1, 1)
MATRIMONIO
(0, N)
CONTRAE_U
(0, N)
(1, 1)
Nome UOMO
UOMO SPOSATO
Data di nascita
Nome moglie
data di matrim.
Data nasc. moglie
73
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
SPIAGGIA INGRESSOCENTRALE
Tariffa spiaggia
Tariffa ingressoTariffa centrale
AREATariffa
Tipo Area
Il modello Entity-Relationship 74
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...
(t,e)
TesseraSOCIO
Nome
GIOCATORE ARBITROarbitra
PARTITAData
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.
TesseraSOCIO
Nome arbitraPARTITA
Data(0,N) (1,1)
Il modello Entity-Relationship 75
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
ORARIO
(0, N)
SI TIENE
(1, 3)
AULA(0, 40)
orario
DI
(1, 1)
(1, 3)
SI TIENE
(0, 40)
(1, 1)
CORSO
LEZIONE
AULA
preferibile
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 76
Note sulle ternarie (2)
Il modello Entity-Relationship 77
Note sull’effetto del tempo
cod_corso
Corso Docenteresponsabilitànomecognome
data_nascita
(0,n)(1,1)
cod_doc
nome ciclo
Fotografia dei corsi attivati in un anno accademico
Il modello Entity-Relationship 78
Note sull’effetto del tempo
La storia considerando più anni accademici
Corso_AA Docenteresponsabilitànomecognomedata_nascita
(0,n)(1,1)
cod_doc
AA ciclo
Corso
attivato
(1,1)
(0,n)cod_corso
nome
Riassunto della notazione graficao Entità
o Associazione
o Attributo
o Attributo composto
o Identificatore
o Gerarchia di generalizzazione
o Sottoinsieme
o Vincoli di cardinalità
(min-card,max-card)
Il modello Entity-Relationship 80
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 81
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 82
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
Documentazione associata agli schemi concettuali
Il modello Entity-Relationship 83
Il modello Entity-Relationship 84
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
(1,1)(0,1)
(0,N)(0,1)
(0,1)
(1,1)
(1,N)
(0,N)
(1,N)
(1,N)
CittàIndirizzo
Telefono
Dipartimento
Composizione
Sede
Direzione
Afferenza
Impiegato
Progetto
Partecipazione
Nome
Nome
Cognome
Budget
Data
Via
CAP
Codice
Il modello Entity-Relationship 86
Dizionario dei dati (entità)
Entità Descrizione Attributi IdentificatoreImpiegato Dipendente
dell'aziendaCodice,Cognome,Stipendio
Codice
Progetto Progettiaziendali
Nome,Budget
Nome
Dipartimento Strutturaaziendale
Nome,Telefono
Nome,Sede
Sede Sededell'azienda
Città,Indirizzo
Città
Il modello Entity-Relationship 87
Relazioni Descrizione Componenti AttributiDirezione Direzione di un
dipartimentoImpiegato,Dipartimento
Afferenza Afferenza a undipartimento
Impiegato,Dipartimento
Data
Partecipazione Partecipazionea un progetto
Impiegato,Progetto
Composizione Composizionedell'azienda
Dipartimento,Sede
Dizionario dei dati (relationship)
88
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 qualeafferisce
(3) Un dipartimento con sede a Roma deve esserediretto da un impiegato con più di dieci anni dianzianità
(4) Un impiegato che non afferisce a nessundipartimento non deve partecipare a nessun unprogetto
Il modello Entity-Relationship 89
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 90
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 91
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 92
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.