Progettazione Concettuale e Progettazione Logica

Progettazione di basi di dati: 

Progettazione Concettuale e 

Progettazione Logica

Progettazione di basi di dati 

• È una delle attività del processo di sviluppo 

dei sistemi informativi 

• va quindi inquadrata in un contesto più 

generale: 

• il ciclo di vita dei sistemi informativi: 

• Insieme e sequenzializzazione delle attività 

svolte da analisti, progettisti, utenti, nello 

sviluppo e nell’uso dei sistemi informativi 

• attività iterativa, quindi ciclo 

03/04/2006 2

Studio di fattibilità 

Raccolta e analisi 

dei requisiti 

Progettazione 

Realizzazione 

Validazione e 

collaudo 

Funzionamento 

03/04/2006 3

Fasi (tecniche) del ciclo di vita 

• Studio di fattibilità: definizione costi e priorità 

• Raccolta e analisi dei requisiti: studio delle 

proprietà del sistema 

• Progettazione: di dati e funzioni 

• Realizzazione 

• Validazione e collaudo: sperimentazione 

• Funzionamento: il sistema diventa operativo 

03/04/2006 4

La progettazione di un sistema informativo riguarda due 

aspetti: 

progettazione dei dati 

progettazione delle applicazioni 

Ma: 

i dati hanno un ruolo centrale 

• i dati sono più stabili 

03/04/2006 5



dei requisiti 


dei dati 

Realizzazione 

Validazione e 

collaudo 

Funzionamento 

03/04/2006 6

• Per garantire prodotti di buona qualità è 

opportuno seguire una 

• metodologia di progetto, con: 

• articolazione delle attività in fasi 

• criteri di scelta 

• modelli di rappresentazione 

• generalità e facilità d'uso 

03/04/2006 7



dei requisiti 


dei dati 

Realizzazione 

Validazione e 

collaudo 

Funzionamento 

03/04/2006 8


concettuale 

“COME”: 

progettazione 

Requisiti della base di dati 

Schema concettuale 


logica 

Schema logico 


fisica 

“CHE COSA”: 

analisi 

Schema fisico 

03/04/2006 9

I prodotti della varie fasi sono 

schemi di alcuni modelli di dati: 

• Schema concettuale 

• Schema logico 

• Schema fisico 

03/04/2006 10

Modello dei dati 

• insieme di costrutti utilizzati per organizzare i 

dati di interesse e descriverne la dinamica 

• componente fondamentale: meccanismi di 

strutturazione (o costruttori di tipo) 

• come nei linguaggi di programmazione 

esistono meccanismi che permettono di 

definire nuovi tipi, così ogni modello dei dati 

prevede alcuni costruttori 

• ad esempio, il modello relazionale prevede il 

costruttore relazione, che permette di definire 

insiemi di record omogenei 

03/04/2006 11

Schemi e istanze 

• In ogni base di dati esistono: 

• lo schema, sostanzialmente invariante nel tempo, 

che ne descrive la struttura (aspetto intensionale) 

• nel modello relazionale, le intestazioni delle 

tabelle 

• l’istanza, i valori attuali, che possono cambiare 

anche molto rapidamente (aspetto estensionale) 

• nel modello relazionale, il “corpo” di ciascuna 

tabella 

03/04/2006 12

Due tipi (principali)) di modelli 

• modelli logici: utilizzati nei DBMS esistenti per 

l’organizzazione dei dati 

• utilizzati dai programmi 

• indipendenti dalle strutture fisiche 

esempi: relazionale, reticolare, gerarchico, a oggetti 

• modelli concettuali: permettono di rappresentare i 

dati in modo indipendente da ogni sistema 

• cercano di descrivere i concetti del mondo reale 

• sono utilizzati nelle fasi preliminari di 

progettazione 

il più noto è il modello Entity-Relationship 

03/04/2006 13

Modelli concettuali, perché 

• Proviamo a modellare una applicazione 

definendo direttamente lo schema logico della 

base di dati: 

• da dove cominciamo 

• rischiamo di perderci subito nei dettagli 

• dobbiamo pensare subito a come 

correlare le varie tabelle (chiavi etc.) 

• i modelli logici sono rigidi 

03/04/2006 14

Modelli concettuali, perché 

• servono per ragionare sulla realtà di 

interesse, indipendentemente dagli aspetti 

realizzativi 

• permettono di rappresentare le classi di dati 

di interesse e le loro correlazioni 

• prevedono efficaci rappresentazioni grafiche 

(utili anche per documentazione e 

comunicazione) 

03/04/2006 15

Architettura (semplificata)) di un DBMS 

utente 

Schema logico 

Schema interno 

BD 

03/04/2006 16


concettuale 


logica 


fisica 

03/04/2006 17

Progettazione Concettuale 

03/04/2006 18

Modello Entity-Relationship 

(Entità-Relazione) 

• Il più diffuso modello concettuale 

• Ne esistono molte versioni, 

• (più o meno) diverse l’una dall’altra 

03/04/2006 19

I costrutti del modello E-RE 

• Entità 

• Relationship 

• Attributo 

• Identificatore 

• Generalizzazione 

• …. 

03/04/2006 20

Entità 

• Classe di oggetti (fatti, persone, cose) della 

applicazione di interesse con proprietà 

comuni e con esistenza “autonoma” 

• Esempi: 

• impiegato, città, conto corrente, ordine, 

fattura 

03/04/2006 21

Relationship 

• Legame logico fra due o più entità, rilevante 

nell’applicazione di interesse 

• Esempi: 

• Residenza (fra persona e città) 

• Esame (fra studente e corso) 

03/04/2006 22

Uno schema E-R, E 

graficamente 

Studente 

Esame 

Corso 

03/04/2006 23

Entità: : schema e istanza 

• Entità: 

• classe di oggetti, persone, … "omogenei" 

• Occorrenza (o istanza) di entità: 

• elemento della classe (l'oggetto, la 

persona, …, non i dati) 

• nello schema concettuale rappresentiamo le 

entità, non le singole istanze (“astrazione”) 

03/04/2006 24

Rappresentazione grafica di entità 

Impiegato 

Dipartimento 

Città 

Vendita 

03/04/2006 25

Entità, , commenti 

• Ogni entità ha un nome che la identifica 

univocamente nello schema: 

• nomi espressivi 

• opportune convenzioni 

• singolare 

03/04/2006 26

Relationship 

• Legame logico fra due o più entità, rilevante 

nell’applicazione di interesse 

• Esempi: 

• Residenza (fra persona e città) 

• Esame (fra studente e corso) 

• Chiamata anche: 

• relazione, correlazione, associazione 

03/04/2006 27

Rappresentazione grafica 

di relationship 

Studente 

Esame 

Corso 

Impiegato 

Residenza 

Città 

03/04/2006 28

Relationship, , commenti 

• Ogni relationship ha un nome che la identifica 

univocamente nello schema: 

• nomi espressivi 

• opportune convenzioni 

• singolare 

• sostantivi invece che verbi (se 

possibile) 

03/04/2006 29

Esempi di occorrenze 

E1 

S3 

S1 

S2 

E2 

E3 

C1 

C2 

S4 

E4 

C3 

Studente 

Corso 

03/04/2006 30

Relationship, , occorrenze 

• Una occorrenza di una relationship binaria è 

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 

03/04/2006 31

Relationship corrette 

Studente 

Esame 

Corso 

Paziente 

Visita 

Medico 

03/04/2006 32

Due relationship sulle stesse entità 

Sede di 

lavoro 

Impiegato 

Residenza 

Città 

03/04/2006 33

Relationship n-aria 

Fornitore 

Fornitura 

Prodotto 

Dipartimento 

03/04/2006 34

Relationship ricorsiva: 

coinvolge “due volte” la stessa entità 

Conoscenza 

Persona 

03/04/2006 35

Relationship ricorsiva con “ruoli” 

Successione 

Successore 

Sovrano 

Predecessore 

03/04/2006 36

Relationship ternaria ricorsiva 

Superficie 

Migliore 

Confronto 

Peggiore 

Tennista 

03/04/2006 37

Attributo 

• Proprietà elementare di un’entità o di una 

relationship, di interesse ai fini 

dell’applicazione 

• Associa ad ogni occorrenza di entità o 

relationship un valore appartenente a un 

insieme detto dominio dell’attributo 

03/04/2006 38

Attributi, rappresentazione grafica 

Cognome 

Nome 

Data 

Voto 

Titolo 

Studente 

Esame 

Corso 

Matricola 

Codice 

03/04/2006 39

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 

03/04/2006 40


Cognome 

Impiegato 

Età 

Indirizzo 

Via 

Numero 

CAP 

03/04/2006 41

Cognome 

Impiegato 

Codice 

Partecipazione 

Direzione 

Afferenza 

Data 

Telefono 

Dipartimento 

Nome 

Composizione 

Sede 

Progetto 

Via 

Budget Nome 

CAP 

Indirizzo Città 

03/04/2006 42

Altri costrutti del modello E-RE 

• Cardinalità 

• di relationship 

• di attributo 

• Identificatore 

• interno 

• esterno 

• Generalizzazione 

03/04/2006 43

Cardinalità di relationship 

• Coppia di valori associati a ogni entità che 

partecipa a una relationship 

• specificano il numero minimo e massimo di 

occorrenze delle relationship cui ciascuna 

occorrenza di una entità può partecipare 

03/04/2006 44

Esempio di cardinalità 

Impiegato 

(1,5) (0,50) 

Assegnamento 

Incarico 

03/04/2006 45

• per semplicità usiamo solo tre simboli: 

• 0 e 1 per la cardinalità minima: 

• 0 = “partecipazione opzionale” 

• 1 = “partecipazione obbligatoria” 

• 1 e “N” per la massima: 

• “N” non pone alcun limite 

03/04/2006 46

Occorrenze di Residenza 

S1 

R1 

C1 

S3 

S2 

R2 

C2 

S4 

Studente 

R3 

R4 

C4 

C3 

Città 

03/04/2006 47

Cardinalità di Residenza 

Studente 

(1,1) (0,N) 

Residenza 

Città 

03/04/2006 48

Tipi di relationship 

• Con riferimento alle cardinalità massime, 

abbiamo relationship: 

• uno a uno 

• uno a molti 

• molti a molti 

03/04/2006 49

Due avvertenze 

• Attenzione al "verso" nelle relationship uno a 

molti 

• le relationship obbligatorie-obbligatorie sono 

molto rare 

03/04/2006 50

Relationship “molti a molti” 

Studente 

(0,N) 

Esame 

(0,N) 

Corso 

Montagna 

(0,N) 

Scalata 

(1,N) 

Alpinista 

Macchinista 

(1,N) 

Abilitazione 

(1,N) 

Locomotore 

03/04/2006 51

Relationship “uno a molti” 

(0,1) (0,N) 

Persona 

Impiego 

Azienda 

Cinema 

(1,1) (0,N) 

Ubicazione 

Località 

Comune 

(1,1) (1,N) 

Ubicazione 

Provincia 

03/04/2006 52

Relationship “uno a uno” 

(0,1) (0,1) 

Professore 

Titolarità 

Cattedra 

Professore 

di ruolo 

(1,1) (0,1) 

Titolarità 

Cattedra 

Professore 

di ruolo 

(1,1) (1,1) 

Titolarità 

Cattedra 

coperta 

03/04/2006 53

Cardinalità di attributi 

• E’ possibile associare delle cardinalità anche 

agli attributi, con due scopi: 

• indicare opzionalità ("informazione 

incompleta") 

• indicare attributi multivalore 

03/04/2006 54


(0,N) 

Telefono 

Impiegato 

Nome 

(0,1) 

Numero patente 

03/04/2006 55

Identificatore di una entità 

• “strumento” per l’identificazione univoca 

delle occorrenze di un’entità 

• costituito da: 

• attributi dell’entità 

• identificatore interno 

• (attributi +) entità esterne attraverso 

relationship 

• identificatore esterno 

03/04/2006 56

Identificatori interni 

Targa 

Automobile 

Modello 

Data Nascita 

Persona 

Indirizzo 

Cognome 

Nome 

03/04/2006 57

Identificatore esterno 

Cognome Matricola 

Nome 

Studente 

(1,1) (0,N) 

Iscrizione 

Università 

Anno di corso 

Indirizzo 

03/04/2006 58

Alcune osservazioni 

• ogni entità deve possedere almeno un 

identificatore, ma può averne in generale più 

di uno 

• una identificazione esterna è possibile solo 

attraverso una relationship a cui l’entità da 

identificare partecipa con cardinalità (1,1) 

• perché non parliamo degli identificatori delle 

relationship 

03/04/2006 59

Cognome 

(0,1) 

Direzione 

(1,1) 

Telefono 

(1,N) 

Codice 

Impiegato 

(0,N) 


(1,N) 

(0,1) (0,N) 

Afferenza 

(0,1) 

Data 

Dipartimento 

(1,1) 

Composizione 

(1,N) 

Nome 

Progetto 

Via 

Budget Nome 

CAP 

Sede 


03/04/2006 60

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 (o 

sottotipi) di E 

03/04/2006 61


Dipendente 

Impiegato Funzionario Dirigente 

03/04/2006 62

Proprietà delle generalizzazioni 

Se E (genitore) è generalizzazione di E1, E2, 

..., En (figlie): 

• ogni proprietà di E è significativa per E1, 

E2, ..., En 

• ogni occorrenza di E1, E2, ..., En è 

occorrenza anche di E 

03/04/2006 63

Città 

(0,N) 

Nascita 

(1,1) 

Persona 

Codice 

fiscale 

Nome 

Stipendio 

Età 

Lavoratore 

Studente 

03/04/2006 64

Ereditarietà 

• tutte le proprietà (attributi, relationship, altre 

generalizzazioni) dell’entità genitore vengono 

ereditate dalle entità figlie e non 

rappresentate esplicitamente 

03/04/2006 65

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) 

03/04/2006 66

CF 

Cognome 

Persona 

Stipendio 

Età 

Matr. 

Uomo 

Donna 

Impiegato 

Studente 

Militare 

Segretario Direttore Progettista 

Responsabile 

03/04/2006 67

Documentazione associata agli schemi 

concettuali 

• dizionario dei dati 

• entità 

• relationship 

• vincoli non esprimibili 

03/04/2006 68

Cognome 

(0,1) 

Direzione 

(1,1) 

Telefono 

(1,N) 

Codice 

Impiegato 

(0,N) 


(1,N) 

(0,1) (0,N) 

Afferenza 

(0,1) 

Data 

Dipartimento 

(1,1) 

Composizione 

(1,N) 

Nome 

Progetto 

Via 

Budget Nome 

CAP 

Sede 


03/04/2006 69

Dizionario dei dati (entità) 

Entità Descrizione Attributi Identificatore 

Impiegato Dipendente Codice, Codice 

dell'azienda Cognome, 

Stipendio 

Progetto Progetti Nome, Nome 

aziendali Budget 

Dipartimento Struttura Nome, Nome, 

Sede 

aziendale 

Sede 

dell'azienda 

Telefono 

Città, 

Indirizzo 

Sede 

Città 

03/04/2006 70

Dizionario dei dati (relationship( 

relationship) 

Relazioni Descrizione Componenti Attributi 

Direzione Direzione di un 

dipartimento 

Impiegato, 

Dipartimento 

Afferenza Afferenza a un Impiegato, Data 

dipartimento Dipartimento 

Partecipazione Partecipazione 

a un progetto 

Impiegato, 

Progetto 

Composizione Composizione 

dell'azienda 

Dipartimento, 

Sede 

03/04/2006 71

Vincoli non esprimibili 

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 

03/04/2006 72

Progettazione Logica 

03/04/2006 73


concettuale 

Requisiti della base di dati 

Schema concettuale 


logica 

Schema logico 


fisica 

Schema fisico 

03/04/2006 74

Obiettivo della 

progettazione logica 

"tradurre" lo schema concettuale in uno 

schema logico che rappresenti gli stessi dati 

in maniera corretta ed efficiente 

D’ora in poi. Per semplificare non ci occuperemo dell’efficienza 

03/04/2006 75

Dati di ingresso e uscita 

• Ingresso: 

• schema concettuale 

• Uscita: 

• schema logico 

• documentazione associata 

03/04/2006 76

Non si tratta di una pura e semplice 

traduzione 

• alcuni aspetti non sono direttamente 

rappresentabili 

03/04/2006 77

Schema E-R 

Traduzione nel 

modello logico 

Schema 

logico 

03/04/2006 78

Cognome 

(0,1) 

Direzione 

(1,1) 

Telefono 

(1,N) 

Codice 

Impiegato 

(0,N) 


(1,N) 

(0,1) (1,N) 

Afferenza 

(0,1) 

Data 

Dipartimento 

(1,1) 

Composizione 

(1,N) 

Nome 

Progetto 

Via 

Budget Nome 

CAP 

Sede 


03/04/2006 79

Attività di Traduzione 

• Analisi delle ridondanze 

• Eliminazione delle generalizzazioni 

• Partizionamento/accorpamento di 

entità e relationship 

• Scelta degli identificatori primari 

03/04/2006 80

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 

03/04/2006 81

Tre possibilità 

1. accorpamento delle figlie della 

generalizzazione nel genitore 

2. accorpamento del genitore della 

generalizzazione nelle figlie 

3. sostituzione della generalizzazione con 

relazioni 

03/04/2006 82

A01 

A02 

E0 

R1 

E3 

E1 

E2 

R2 

A11 

A21 

E4 

03/04/2006 83

A11 

A21 

(0,1) 

(0,1) 

A01 

E0 

A02 

R1 

E3 

TIPO 

(0,..) 

R2 

E4 

03/04/2006 84

A01 

A02 

E0 

R1 

E3 

E1 

E2 

R2 

A11 

A21 

E4 

03/04/2006 85

R11 

R12 

E3 

E1 

E2 

R2 

A01 A11 A02 A01 A21 A02 

E4 

03/04/2006 86

A01 

A02 

E0 

R1 

E3 

E1 

E2 

R2 

A11 

A21 

E4 

03/04/2006 87

A01 

A02 

E0 

R1 

E3 

RG1 

(0,1) 

(1,1) 

(0,1) 

(1,1) 

RG2 

E1 

E2 

R2 

A11 

A21 

E4 

03/04/2006 88

Attività di Traduzione 



• Partizionamento/accorpamento di 

entità e relazioni 


03/04/2006 89

Ristrutturazioni, casi principali 

• partizionamento verticale di entità 

• partizionamento orizzontale di 

relationship 

• eliminazione di attributi multivalore 

• accorpamento di entità/ relationship 

03/04/2006 90

Cognome 

Indirizzo 

Data 

nascita 

Codice 

Impiegato 

Livello 

Stipendio 

Ritenute 

03/04/2006 91

Cognome 

Codice 

Stipendio 

Livello 

Dati 

anagrafici 

(1,1) (1,1) 

R 

Dati 

lavorativi 

Indirizzo 

Data 

nascita 

Ritenute 

03/04/2006 92

Nome 

Indirizzo 

Agenzia 

(1,N) 

Città 

Telefono 

03/04/2006 93

Città 

Nome 

Numero 

Agenzia 

(1,N) (1,1) 

Utenza 

Telefono 

Indirizzo 

03/04/2006 94

Cognome 

Codice 

fiscale 

Interno 

Indirizzo 

Persona 

(0,1) (1,1) 

Intestazione 

Appartamento 

Indirizzo 

Data 

nascita 

03/04/2006 95

Cognome 

Indirizzo 

Data 

nascita 

Codice 

fiscale 

Persona 

Interno 

(0,1) 

Indirizzo 

(0,1) 

03/04/2006 96

Ruolo 

Cognome 

Città 

Nome 

Giocatore 

(1,N) 

(1,N) 

Composizione 

Squadra 

Data 

acquisto 

(0,1) 

Data 

cessione 

03/04/2006 97

Ruolo 

Data 

acquisto 

(1,1) Comp. (1,N) 

attuale 

Nome 

Giocatore 

Squadra 

Cognome 

(1,N) 

Comp. 

passata 

(1,N) 

Città 

Data 

acquisto 

Data 

cessione 

03/04/2006 98

Attività della ristrutturazione 



• Partizionamento/accorpamento di entità 

e relazioni 


03/04/2006 99

Scelta degli identificatori principali 

• operazione indispensabile per la traduzione 

nel modello relazionale 

• Criteri 

• assenza di opzionalità 

• semplicità 

03/04/2006 100

Se nessuno degli identificatori soddisfa i 

requisiti visti 

Si introducono nuovi attributi (codici) contenenti 

valori speciali generati appositamente per 

questo scopo 

03/04/2006 101

Traduzione verso il 

modello relazionale 

• idea di base: 

• le entità diventano relazioni sugli stessi 

attributi 

• le associazioni (ovvero le relazioni E-R) 

diventano relazioni sugli identificatori 

delle entità coinvolte (più gli attributi 

propri) 

03/04/2006 102

Entità e relationship molti a molti 

Cognome 

Matricola 

Data inizio 

Codice 

Nome 

(0,N) 

(1,N) 

Impiegato 


Progetto 

Stipendio 

Budget 

Impiegato(Matricola, Cognome, Stipendio) 

Progetto(Codice, Nome, Budget) 

Partecipazione(Matricola, Codice, DataInizio) 

03/04/2006 103

Entità e relationship molti a molti 




• con vincoli di integrità referenziale fra 

• Matricola in Partecipazione e (la chiave di) 

Impiegato 

• Codice in Partecipazione e (la chiave di) Progetto 

03/04/2006 104

Nomi più espressivi per gli attributi 

della chiave della relazione che 

rappresenta la relationship 




Partecipazione(Impiegato, Progetto, DataInizio) 

03/04/2006 105

Relationship ricorsive 

(0,N) 

Composizione 

Quantità 

(0,N) 

Composto 

Prodotto 

Componente 

Costo Nome Codice 

Prodotto(Codice, Nome, Costo) 

Composizione(Composto, Componente, Quantità) 

03/04/2006 106

Nome 

Relationship n-arie 

Partita IVA Quantità Genere Codice 

Fornitore 

(0,N) 

Fornitura 

(1,N) 

Prodotto 

(1,N) 

Dipartimento 

Nome 

Telefono 

Fornitore(PartitaIVA, Nome) 

Prodotto(Codice, Genere) 

Dipartimento(Nome, Telefono) 

Fornitura(Fornitore, Prodotto, Dipartimento, Quantità) 

03/04/2006 107

Relationship uno a molti 

Cognome Data 

Ingaggio 

nascita Città Nome 

(1,1) (0,N) 

Giocatore Contratto 

Squadra 

Ruolo 

Colori sociali 

Giocatore(Cognome, DataNascita, Ruolo) 

Contratto(CognGiocatore, DataNascG, Squadra, Ingaggio) 

Squadra(Nome, Città, ColoriSociali) 

• corretto 

03/04/2006 108

Soluzione più compatta 

Giocatore(Cognome, DataNascita, Ruolo) 

Contratto(CognGiocatore, DataNascG, Squadra, Ingaggio) 


Giocatore(Cognome, DataNasc, Ruolo, Squadra, Ingaggio) 


• con vincolo di integrità referenziale fra Squadra in 

Giocatore e la chiave di Squadra 

• se la cardinalità minima della relationship è 0, allora 

Squadra in Giocatore deve ammettere valore nullo 

03/04/2006 109

Entità con identificazione esterna 

Cognome 

Matricola 

Nome 

Città 

Studente 

(1,1) (1,N) 

Iscrizione 

Università 

AnnoDiCorso 

Indirizzo 

Studente(Matricola, Università, Cognome, AnnoDiCorso) 

Università(Nome, Città, Indirizzo) 

• con vincolo … 

03/04/2006 110

Relationship uno a uno 

Data inizio 

Cognome Codice Sede Nome 

(1,1) (1,1) 

Direttore 

Direzione 

Dipartimento 

Stipendio 

Telefono 

• varie possibilità: 

• fondere da una parte o dall'altra 

• fondere tutto 

03/04/2006 111

Una possibilità privilegiata 

Data inizio 


(0,1) (1,1) 

Direttore 

Direzione 

Dipartimento 

Stipendio 

Telefono 

Impiegato (Codice, Cognome, Stipendio) 

Dipartimento (Nome, Sede, Telefono, Direttore, InizioD) 

• con vincolo di integrità referenziale, senza valori nulli 

03/04/2006 112

Un altro caso 

Data inizio 


(0,1) (0,1) 

Direttore 

Direzione 

Dipartimento 

Stipendio 

Telefono 

03/04/2006 113

Cognome 

(0,1) 

Direzione 

(1,1) 

Telefono 

Codice 

Impiegato 

(0,N) 


(1,N) 

(0,1) (1,N) 

Afferenza 

(0,1) 

Data 

Dipartimento 

(1,1) 

Composizione 

(1,N) 

Nome 

Progetto 

Via 

Budget Nome 

CAP 

Sede 


03/04/2006 114

Schema finale 

Impiegato(Codice, Cognome, Dipartimento*, Data*) 

Dipartimento(Nome, Città, Telefono, Direttore) 

Sede(Città, Via, CAP) 

Progetto(Nome, Budget) 

Partecipazione(Impiegato, Progetto) 

03/04/2006 115

Progettazione Concettuale e Progettazione Logica

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?