Progettazione Logica 1
Progettazione logica
I. Analisi delle prestazioni su schemi E-R
II. Ristrutturazione di schemi E-R
III. Traduzione verso il modello relazionale
requisiti delSistema informativo
progettazione concettuale
progettazione logica
progettazione fisica
SCHEMA LOGICO
SCHEMA CONCETTUALE
SCHEMA FISICO
Progettazione Logica 3
Obiettivo dellaprogettazione 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 4
Dati di ingresso e uscita
Ingresso: schema concettuale informazioni sul carico applicativo modello logico
Uscita: schema logico documentazione associata
Progettazione Logica 5
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
Non si tratta di una pura e semplice traduzione
Schema E-Rristrutturato
Modellologico
Traduzione nelmodello logico
Schema logico
Fase 2
Ristrutturazione dello schema E-R
Schema E-RCarico
applicativo
Fase 1
Progettazione Logica 7
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 8
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
Per ottimizzare il risultato abbiamo bisogno di analizzare le prestazioni a questo livello
Analisi delle prestazioni su schemi E-R
Progettazione Logica 9
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 10
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 schemanumero di occorrenze di ogni relationship dello schemadimensioni 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)
CittàIndirizzo
Telefono
Dipartimento
Composizione
Sede
Direzione
Afferenza
Impiegato
Progetto
Partecipazione
Nome
Nome
Cognome
Budget
Data
Via
CAP
(1,1)(0,1)
(1,N)(0,1)
(0,1)
(1,1)
(1,N)
(0,N)
(1,N)
(1,N)
Codice
Schema di riferimento
12
Tavola dei volumi
Concetto Tipo Volume Sede E 10
Dipartimento E 80 Impiegato E 2000 Progetto E 500
Composizione R 80 Afferenza R 1900 Direzione R 80
Partecipazione R 6000
vi sono riportati i concetti dello schema col volume previsto a regime
Progettazione Logica 13
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 14
Esempio di valutazione di costo delle operazioni
Operazione:1. assegna un impiegato a un progetto2. trova tutti i dati di un impiegato, del dipartimento nel
quale lavora e dei progetti ai quali partecipa3. trova i dati di tutti gli impiegati di un certo
dipartimento4. per ogni sede trova i suoi dipartimenti con il cognome
del direttore e l’elenco degli impiegati del dipartimento
Progettazione Logica 15
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 16
Tavola delle operazioni
Operazione Tipo Frequenza Op.1 I 50 al giorno Op.2 I 100 al giorno Op.3 I 10 al giorno Op.4 B 2 a sett.
Progettazione Logica 17
Regola 80-20: l’80% del carico è generato dal 20% delle operazioniDunque 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)
Regola 80-20
Telefono
Nome
Data
(1,N)(0,1)
(0,1)
(1,1)
(1,N)
Dipartimento
Afferenza
NomeBudget
(1,N)
Progetto
Partecipazione
Cognome
(0,N)Codice
Impiegato
schema di navigazione
Operazione 2: trova tutti i dati di un impiegato, del dipartimento nel quale lavora e dei progetti ai quali partecipa
Progettazione Logica 19
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 20
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 21
Attività della ristrutturazione
Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e
relationship Scelta degli identificatori primari
Progettazione Logica 22
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 23
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 24
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 25
Attributo derivabile
Fattura
Importo netto
IVA
Importo lordo
Progettazione Logica 26
Attributo derivabile da altra entità
Importo totale
ComposizioneAcquisto Prodotto
Prezzo
(1,N) (1,N)
Importo totale è ottenibile con operazioni di aggregazione
Corso
Studente
Frequenza
(0,N)
(1,N)
Professore
Insegnamento
(1,1)
(1,1)
Docenza
(0,N)
(1,N)
Ridondanza dovuta a ciclo
Progettazione Logica 28
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 29
Analisi di una ridondanza
ResidenzaPersona Città
Numero abitanti
(1,1) (1,N)
L’attributo numero abitanti è derivabile da una operazione di conteggio delle istanze di persona residenti in una città
Progettazione Logica 30
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 di abitanti) (2 volte al giorno)
Concetto Tipo Volume Città E 200
Persona E 1000000 Residenza R 1000000
tavola dei volumi
Progettazione Logica 31
Presenza di ridondanza
Concetto Costrutto Accessi Tipo Persona Entità 1 S
Residenza Relazione 1 S Città Entità 1 L Città Entità 1 S
Concetto Costrutto Accessi TipoCittà Entità 1 L
Operazione 1
Operazione 2
Progettazione Logica 32
Assenza di ridondanza
Concetto Costrutto Accessi TipoPersona Entità 1 S
Residenza Relazione 1 S
Concetto Costrutto Accessi Tipo Città Entità 1 L
Residenza Relazione 5000 L
Operazione 1
Operazione 2
n.persone/n.città = media accessi per calcolare il numero di abitanti di una città
Progettazione Logica 33
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 34
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 35
Ristrutturazione dello schema E-R
Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e
relazioni Scelta degli identificatori primari
Progettazione Logica 36
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 37
Tre possibilità
1. accorpamento delle figlie della generalizzazione nel genitore
2. accorpamento del genitore della generalizzazione nelle figlie
3. sostituzione della generalizzazione con relazioni
E0 R1
A01 A02
E3
R2
E4
E2E1
A11 A21
Schema generale
Progettazione Logica 39
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
A11
A21
TIPO
(0,1)
(0,1)
(0,..)
E0
A01 A02
R1 E3
R2
E4
Collasso verso l’alto
Studente
Laureando Diplomando
Matr.Nome
Tit.StageTit.Tesi
MatrRelatore
Denom.Azienda
(1,1) (1,1)
(p,e)
(1,n)(1,n)
Dom(Tipo)= {L,D,N}
Denom.
StudenteMatr.Nome
Tit.Stage (0,1)
Tit.Tesi (0,1)
MatrRelatore Azienda
(0,1) (0,1)
Tipo
(1,n) (1,n)
Esempio
Progettazione Logica 42
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
E0 R1
A01 A02
E3
R2
E4
E2E1
A11 A21
totale
44
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 distinzioni tra tali entità
E3
R2
E4
E2E1
A11 A21
R12
R11
A01 A02 A01 A02
Collasso verso il basso
Esempio
Dipendente
Impiegato Operaio
CFNome
macchinecapacità
(t,e)
Dirigenten_sottoposti
SindacatoContribuisce0,1 1,n
0,1
1,n
1,n1,n
Dirige
Impiegato Operaio
macchinecapacitàDirigente
n_sottoposti
SindacatoContr_I
0,1
0,n
0,1
1,n
1,n
CF Nome
0,n
Contr_D
0,1
Contr_O
0,10,1
0,n
0,n Dir_DDir_ODir_I
CF NomeCF Nome
0,n 0,n
Progettazione Logica 47
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 48
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 E2Nota 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
RG2RG1
(1,1)
(0,1)
(1,1)
(0,1)
E0
A01 A02
E2E1 R2
E4A11 A21
R1 E3
Progetto
Prog_sw Prog_hw
CodDesc
N_schede
Mesiuomo
Comp_hw
usa
1,n
0,n
Esempio
Progetto
Prog_sw Prog_hw
CodDesc
N_schedeMesiuomo
Comp_hw
usa
1,n
0,n
0,1 0,1
1,11,1
Progettazione Logica 51
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 52
Attività della ristrutturazione
Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e
relazioni Scelta degli identificatori primari
Progettazione Logica 53
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 54
Ristrutturazioni, casi principali
partizionamento orizzontale/verticale di entità
eliminazione di attributi multivalore
accorpamento di entità/ relationship
Progettazione Logica 55
Impiegato
Livello
Stipendio
Ritenute
Cognome
Indirizzo
Datanascita
Codice
Partizionamento verticale
di entità
Progettazione Logica 56
LivelloStipendio
Ritenute
Cognome
Indirizzo Datanascita
Codice
Dati ImpiegatoDati
anagraficiDati
lavorativi
(1,1) (1,1)
Si separano gli attributi in gruppi omogenei
Progettazione Logica 57
Agenzia
Indirizzo
Città
Telefono
Nome
(1,N)
Eliminazione di attributi multivalore
Progettazione Logica 58
Numero
Indirizzo
Nome
UtenzaAgenzia Telefono
(1,N) (1,1)
Città
Si introduce una entità le cui istanze sono identificatedai valori dell’attributo
L’associazione può essere uno a molti o molti a molti
Progettazione Logica 59
Agenzia
Indirizzo
Città
Telefono
Nome
(1,3)
Se la cardinalità massima K è nota: è possibile prevedere K repliche degli attributi
Tel2Tel1 Tel3
Nome
Agenzia
Indirizzo Città
Eliminazione di attributi multivalore
Progettazione Logica 60
IndirizzoInternoCognome
Indirizzo Datanascita
Codicefiscale
IntestazionePersona Appartamento
(0,1) (1,1)
Accorpamento di Entità
Progettazione Logica 61
Persona
Interno
Indirizzo
Cognome
Indirizzo
Datanascita
Codicefiscale
(0,1)
(0,1)
(0,1)
Cognome
ComposizioneGiocatore Squadra
(1,N) (1,N)
RuoloNomeCittà
Data acquisto Data cessione
Cognome
Comp.passata
Giocatore Squadra
(0,N) (1,N)
Ruolo Nome
CittàData acquisto Data cessione
Comp.attuale
Data acquisto(1,1) (1,N)
Partizionamento orizzontale di associazioni
Progettazione Logica 63
Attività della ristrutturazione
Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e
relationship Scelta degli identificatori primari
Progettazione Logica 64
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 65
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 66
Se nessuno degli identificatori soddisfa i requisiti visti?
Si introducono nuovi attributi (codici) contenenti valori speciali generati appositamente per questo scopo
ES. Contatori, Sigle
67
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
Interno
Indirizzo
Cognome
Indirizzo
Data nascita
Codice fiscale
(0,1)
(0,1)Codice SSN
Persona
Progettazione Logica 68
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 69
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
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
Persona indirizzo
via
cittàn.civico (0,1)
CAP
nomecognome
cod_fiscale
Persona(CF, Cognome, Nome, Via, NCivico*,Città,CAP)
Progettazione Logica 71
Impiegato(Matricola, Cognome, Stipendio)
Progetto(Codice, Nome, Budget)
Partecipazione(Matricola, Codice, DataInizio)
Partecipazione
(0,N) (1,N)
Cognome
Stipendio
Matricola
Impiegato
NomeCodice
Budget
Progetto
Data inizio
Entità e relationship molti a molti
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(Matricola, Codice, DataInizio)
Progettazione Logica 73
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 74
Composizione
ProdottoComposto Componente
Costo Nome Codice
(0,N) (0,N)
Prodotto(Codice, Nome, Costo)
Composizione(Composto, Componente, Quantità)
Relationship ricorsive
Quantità
75
Nome
Fornitore Prodotto
Dipartimento
Fornitura
Partita IVA Genere CodiceQuantità
Nome
Telefono
(0,N) (1,N)
(1,N)
Relationship n-arie
Fornitore(PartitaIVA, Nome)Prodotto(Codice, Genere)
Dipartimento(Nome, Telefono)Fornitura(Fornitore, Prodotto, Dipartimento, Quantità)
Progettazione Logica 76
Cognome
Giocatore SquadraContratto
Datanascita Città Nome
Ingaggio
(1,1) (0,N)
Ruolo Colori sociali
Relationship uno a molti
Giocatore(Cognome, DataNascita, Ruolo)Squadra(Nome, Città, ColoriSociali)
Contratto(CognGiocatore, DataNascG, Squadra, Ingaggio)
Progettazione Logica 77
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 78
Cognome
Giocatore SquadraContratto
Datanascita Città Nome
Ingaggio
(0,1) (0,N)
Ruolo Colori sociali
Osservazione
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)
79
Associazioni ricorsive uno a molti
In questo caso è possibile operare una traduzione con 1 o 2 relazioni
1 relazione:
Impiegato(Codice, Nome, Qualifica, Responsabile*) FK: Responsabile REFERENCES Impiegato
2 relazioni:
Impiegato(Codice, Nome, Qualifica)Dipendenza(Dipendente, Responsabile)FK: Dipendente REFERENCES Impiegato FK: Responsabile REFERENCES Impiegato
Responsabile Dipendente
Qualifica Nome Codice
(0,N) (0,1)Dipendenza
Impiegato
80
IscrizioneStudente Università
Cognome Matricola
AnnoDiCorso
Nome
Indirizzo
(1,1) (1,N)
Città
Entità con identificazione esterna
Studente(Matricola, Università, Cognome, AnnoDiCorso)
Università(Nome, Città, Indirizzo)
Nel caso di entità identificata esternamente, si “importa” l’identificatore della/e entità identificante/i.
L’associazione relativa risulta automaticamente tradotta
81
Direttore DipartimentoDirezione
Cognome Codice Sede NomeData inizio
(1,1) (1,1)
Stipendio Telefono
Relationship uno a uno (1,1) – (1,1)
Direttore (Codice, Cognome, Stipendio)
Dipartimento (Nome, Sede, Telefono, Direttore, InizioD)
Direttore (Codice, Cognome, Stipendio, InizioD, Dipartimento)
Dipartimento (Nome, Sede, Telefono)
Progettazione Logica 82
Impiegato DipartimentoDirezione
Cognome Codice Sede NomeData inizio
(0,1) (1,1)
Stipendio Telefono
Relationship uno a uno (0,1) – (1,1)
tradurre l’associazione Direzione inglobandola in Impiegatonon è in generale una buona scelta (dipende dai volumi dei dati in gioco): troppi valori nulli!
Progettazione Logica 83
Relationship uno a uno (0,1) – (1,1)
Impiegato(Codice, Cognome, Stipendio, Dipartimento*, DataInizio*)
Dipartimento(Nome, Sede, Telefono)
Impiegato DipartimentoDirezione
Cognome Codice Sede NomeData inizio
(0,1) (1,1)
Stipendio Telefono
Progettazione Logica 84
Soluzione:
Impiegato (Codice, Cognome, Stipendio)
Dipartimento (Nome, Sede, Telefono, Direttore, InizioD)
• con vincolo di integrità referenziale, senza valori nulli
85
Impiegato DipartimentoDirezione
Cognome Codice Sede NomeData inizio
(0,1) (0,1)
Stipendio Telefono
Relationship uno a uno (0,1) – (0,1)
Per evitare la presenza di valori nulli nelle chiavi esterne:
Impiegato (Codice, Cognome, Stipendio)
Dipartimento (Nome, Sede, Telefono, Direttore)
Direzione (Direttore, Dipartimento, DataInizio)
Progettazione Logica 86
2 relazioni:Persona(CF, Nome)Matrimonio(Marito, Moglie)
Marito Moglie
Nome CF
(0,1) (0,1)Matrimonio
Persona
Un esempio particolare
(1,1)(0,1)
(1,N)(0,1)
(0,1)
(1,1)
(1,N)
(0,N)
(1,N)
CittàIndirizzo
Telefono
Dipartimento
Composizione
Sede
Direzione
Afferenza
Impiegato
Progetto
Partecipazione
Nome
Nome
Cognome
Budget
Data
Via
CAP
Codice
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*)
Progettazione Logica89
Esercizio 1
Corso_AA Docenteresponsabilitànomecognomedata_nascita
(0,n)(1,1)
cod_doc
AA ciclo
Corso
attivato
(1,1)
(0,n)cod_corso
nome
data
FA_VISITA
(1, 1)
(0, N)
IN_VISITA
(0, N)
(1, 1)
MEDICO
VISITA
PAZIENTE
esito
nomecognometelefonocod_med
nomecognomedata_nascitacod_paziente
Progettazione Logica 90
Esercizio 2
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)
Trovare lo schema ER che dà luogo al seguente schema relazionale: