progettazione di basi di dati: progettazione concettuale e...

Progettazione di basi di dati:Progettazione di basi di dati:

Progettazione Concettuale eProgettazione Concettuale eProgettazione LogicaProgettazione Logica

03/04/2006 2

Progettazione di basi di datiProgettazione di basi di dati

• È una delle attività del processo di sviluppodei 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, nellosviluppo e nell’uso dei sistemi informativi

• attività iterativa, quindi ciclo

03/04/2006 3

Studio di fattibilità

Raccolta e analisidei requisiti

Progettazione

Realizzazione

Validazione ecollaudo

Funzionamento

03/04/2006 4

Fasi (tecniche) del ciclo di vitaFasi (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 5

�i dati hanno un ruolo centrale

• i dati sono più stabili

La progettazione di un sistema informativo riguarda dueaspetti:

�progettazione dei datiprogettazione delle applicazioni

Ma:

03/04/2006 6



Progettazionedei dati

Realizzazione


Funzionamento

03/04/2006 7

• 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 8



Progettazionedei dati

Realizzazione


Funzionamento

03/04/2006 9

Progettazionefisica

Schema concettuale

Requisiti della base di dati

Progettazioneconcettuale

Progettazionelogica

Schema logico

Schema fisico

“CHE COSA”:analisi

“COME”:progettazione

03/04/2006 10

• Schema concettuale

• Schema logico

• Schema fisico

I prodotti della varie fasi sonoschemi di alcuni modelli di dati:

03/04/2006 11

Modello dei datiModello dei dati

• insieme di costrutti utilizzati per organizzare idati di interesse e descriverne la dinamica

• componente fondamentale: meccanismi distrutturazione (o costruttori di tipo)

• come nei linguaggi di programmazioneesistono meccanismi che permettono didefinire nuovi tipi, così ogni modello dei datiprevede alcuni costruttori

• ad esempio, il modello relazionale prevede ilcostruttore relazione, che permette di definireinsiemi di record omogenei

03/04/2006 12

SchemiSchemi ee istanzeistanze

• 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 13

Due tipiDue tipi ((principaliprincipali) di) di modellimodelli

• modelli logici: utilizzati nei DBMS esistenti perl’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

progettazioneil più noto è il modello Entity-Relationship

03/04/2006 14

Modelli concettuali, perchModelli concettuali, perchéé??

• Proviamo a modellare una applicazionedefinendo direttamente lo schema logico dellabase 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 15

Modelli concettuali, perchModelli concettuali, perchéé??

• servono per ragionare sulla realtà diinteresse, indipendentemente dagli aspettirealizzativi

• permettono di rappresentare le classi di datidi interesse e le loro correlazioni

• prevedono efficaci rappresentazioni grafiche(utili anche per documentazione ecomunicazione)

03/04/2006 16

BD

Schema logico

Schema interno

utente

ArchitetturaArchitettura ((semplificatasemplificata) di) di unun DBMSDBMS

03/04/2006 17


Progettazionelogica

Progettazionefisica

03/04/2006 18

Progettazione ConcettualeProgettazione Concettuale

03/04/2006 19

ModelloModello EntityEntity--RelationshipRelationship(Entit(Entitàà--Relazione)Relazione)

• Il più diffuso modello concettuale

• Ne esistono molte versioni,• (più o meno) diverse l’una dall’altra

03/04/2006 20

I costrutti del modello EI costrutti del modello E--RR

• Entità• Relationship• Attributo• Identificatore• Generalizzazione• ….

03/04/2006 21

EntitEntitàà

• Classe di oggetti (fatti, persone, cose) dellaapplicazione di interesse con proprietàcomuni e con esistenza “autonoma”

• Esempi:• impiegato, città, conto corrente, ordine,

fattura

03/04/2006 22

RelationshipRelationship

• Legame logico fra due o più entità, rilevantenell’applicazione di interesse

• Esempi:• Residenza (fra persona e città)• Esame (fra studente e corso)

03/04/2006 23

Uno schema EUno schema E--R, graficamenteR, graficamente

EsameStudente Corso

03/04/2006 24

EntitEntitàà: schema e istanza: 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 leentità, non le singole istanze (“astrazione”)

03/04/2006 25

Rappresentazione grafica di entitRappresentazione grafica di entitàà

Impiegato Dipartimento

Città Vendita

03/04/2006 26

EntitEntitàà, commenti, commenti

• Ogni entità ha un nome che la identificaunivocamente nello schema:• nomi espressivi• opportune convenzioni

• singolare

03/04/2006 27

RelationshipRelationship

• Legame logico fra due o più entità, rilevantenell’applicazione di interesse

• Esempi:• Residenza (fra persona e città)• Esame (fra studente e corso)

• Chiamata anche:• relazione, correlazione, associazione

03/04/2006 28

Rappresentazione graficaRappresentazione graficadidi relationshiprelationship

EsameStudente Corso

ResidenzaImpiegato Città

03/04/2006 29

RelationshipRelationship, commenti, commenti

• Ogni relationship ha un nome che la identificaunivocamente nello schema:• nomi espressivi• opportune convenzioni

• singolare• sostantivi invece che verbi (se

possibile)

03/04/2006 30

Esempi di occorrenzeEsempi di occorrenze

S1

S2

S4

S3

Studente

C1

C2

C3

Corso

E1

E2

E3

E4

03/04/2006 31

RelationshipRelationship, occorrenze, occorrenze

• Una occorrenza di una relationship binaria ècoppia di occorrenze di entità, una perciascuna entità coinvolta

• Una occorrenza di una relationship n-aria èuna n-upla di occorrenze di entità, una perciascuna entità coinvolta

• Nell'ambito di una relationship non cipossono essere occorrenze (coppie, ennuple)ripetute

03/04/2006 32

RelationshipRelationship corrette?corrette?

EsameStudente Corso

VisitaPaziente Medico

03/04/2006 33

DueDue relationshiprelationship sulle stesse entitsulle stesse entitàà

ResidenzaImpiegato Città

Sede dilavoro

03/04/2006 34

RelationshipRelationship nn--ariaaria

Fornitore Prodotto

Dipartimento

Fornitura

03/04/2006 35

Relationship ricorsivaRelationship ricorsiva::coinvolgecoinvolge ““due voltedue volte”” la stessa entitla stessa entitàà

Persona

Conoscenza

03/04/2006 36

Relationship ricorsivaRelationship ricorsiva concon ““ruoliruoli””

Successione

SovranoSuccessore Predecessore

03/04/2006 37

Confronto

Tennista

Superficie

RelationshipRelationship ternariaternaria ricorsivaricorsiva

Migliore Peggiore

03/04/2006 38

AttributoAttributo

• Proprietà elementare di un’entità o di unarelationship, di interesse ai finidell’applicazione

• Associa ad ogni occorrenza di entità orelationship un valore appartenente a uninsieme detto dominio dell’attributo

03/04/2006 39

Attributi, rappresentazione graficaAttributi, rappresentazione grafica

EsameStudente Corso

Cognome Nome

Matricola

Data Titolo

Codice

Voto

03/04/2006 40

Attributi compostiAttributi composti

• Raggruppano attributi di una medesima entitào relationship che presentano affinità nel lorosignificato o uso

• Esempio:• Via, Numero civico e CAP formano un

Indirizzo

03/04/2006 41

Rappresentazione graficaRappresentazione grafica

Impiegato

Cognome

Età Via

Indirizzo Numero

CAP

03/04/2006 42

ComposizionePartecipazione

Progetto

NomeBudget

Impiegato

Codice

Cognome Telefono

Dipartimento

NomeAfferenza

Data

Direzione

CittàIndirizzo

SedeVia

CAP

03/04/2006 43

Altri costrutti del modello EAltri costrutti del modello E--RR

• Cardinalità• di relationship• di attributo

• Identificatore• interno• esterno

• Generalizzazione

03/04/2006 44

CardinalitCardinalitàà didi relationshiprelationship

• Coppia di valori associati a ogni entità chepartecipa a una relationship

• specificano il numero minimo e massimo dioccorrenze delle relationship cui ciascunaoccorrenza di una entità può partecipare

03/04/2006 45

Esempio di cardinalitEsempio di cardinalitàà

AssegnamentoImpiegato Incarico

(1,5) (0,50)

03/04/2006 46

• 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 47

Occorrenze di ResidenzaOccorrenze di Residenza

S1

S2

S4

S3

Studente

C1

C2

C3

Città

R3

R4

R2

R1

C4

03/04/2006 48

CardinalitCardinalitàà di Residenzadi Residenza

ResidenzaStudente Città

(1,1) (0,N)

03/04/2006 49

Tipi diTipi di relationshiprelationship

• Con riferimento alle cardinalità massime,abbiamo relationship:• uno a uno• uno a molti• molti a molti

03/04/2006 50

Due avvertenzeDue avvertenze

• Attenzione al "verso" nelle relationship uno amolti

• le relationship obbligatorie-obbligatorie sonomolto rare

03/04/2006 51

RelationshipRelationship ““molti a moltimolti a molti””

EsameStudente Corso(0,N) (0,N)

ScalataMontagna Alpinista(0,N) (1,N)

AbilitazioneMacchinista Locomotore(1,N) (1,N)

03/04/2006 52

RelationshipRelationship ““uno a moltiuno a molti””

ImpiegoPersona Azienda(0,1) (0,N)

UbicazioneCinema Località(1,1) (0,N)

UbicazioneComune Provincia(1,1) (1,N)

03/04/2006 53

RelationshipRelationship ““uno a unouno a uno””

TitolaritàProfessore Cattedra(0,1) (0,1)

TitolaritàProfessore

di ruolo Cattedra(1,1) (0,1)

TitolaritàProfessore

di ruoloCattedracoperta

(1,1) (1,1)

03/04/2006 54

CardinalitCardinalitàà di attributidi attributi

• E’ possibile associare delle cardinalità ancheagli attributi, con due scopi:

• indicare opzionalità ("informazioneincompleta")

• indicare attributi multivalore

03/04/2006 55


Impiegato

Telefono

Nome

Numero patente

(0,N)

(0,1)

03/04/2006 56

Identificatore di una entitIdentificatore di una entitàà

• “strumento” per l’identificazione univocadelle occorrenze di un’entità

• costituito da:• attributi dell’entità

• identificatore interno• (attributi +) entità esterne attraverso

relationship• identificatore esterno

03/04/2006 57

Identificatori interniIdentificatori interni

Persona

Data Nascita

Cognome

Nome

Automobile

Targa

Modello

Indirizzo

03/04/2006 58

Identificatore esternoIdentificatore esterno

IscrizioneStudente Università

Cognome Matricola

Anno di corso

Nome

Indirizzo

(1,1) (0,N)

03/04/2006 59

Alcune osservazioniAlcune osservazioni

• ogni entità deve possedere almeno unidentificatore, ma può averne in generale piùdi uno

• una identificazione esterna è possibile soloattraverso una relationship a cui l’entità daidentificare partecipa con cardinalità (1,1)

• perché non parliamo degli identificatori dellerelationship?

03/04/2006 60

(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

03/04/2006 61

GeneralizzazioneGeneralizzazione

• mette in relazione una o più entità E1, E2, ...,En con una entità E, che le comprende comecaso particolare

• E è generalizzazione di E1, E2, ..., En• E1, E2, ..., En sono specializzazioni (o

sottotipi) di E

03/04/2006 62


Dipendente

Impiegato Funzionario Dirigente

03/04/2006 63

ProprietProprietàà delle generalizzazionidelle 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 64

Persona

Codicefiscale

Nome

Età

Città

Nascita(0,N)

(1,1)

Lavoratore Studente

Stipendio

03/04/2006 65

EreditarietEreditarietàà

• tutte le proprietà (attributi, relationship, altregeneralizzazioni) dell’entità genitore vengonoereditate dalle entità figlie e nonrappresentate esplicitamente

03/04/2006 66

EsercizioEsercizio

• 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) unnumero di matricola;

• esistono persone che non sono né impiegati néstudenti (ma i dettagli non ci interessano)

03/04/2006 67

Segretario Direttore Progettista

Responsabile

PersonaCF

Cognome

Età

Uomo Donna

Militare

Impiegato Studente

Stipendio Matr.

03/04/2006 68

Documentazione associata agli schemiDocumentazione associata agli schemiconcettualiconcettuali

• dizionario dei dati• entità• relationship

• vincoli non esprimibili

03/04/2006 69

(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

03/04/2006 70

Dizionario dei dati (entitDizionario 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à

03/04/2006 71

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 (Dizionario dei dati (relationshiprelationship))

03/04/2006 72

Vincoli non esprimibiliVincoli 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 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

03/04/2006 73

Progettazione LogicaProgettazione Logica

03/04/2006 74

Progettazionefisica

Schema concettuale

Requisiti della base di dati

Progettazionelogica

Schema logico

Schema fisico


03/04/2006 75

Obiettivo dellaObiettivo dellaprogettazione logicaprogettazione logica

"tradurre" lo schema concettuale in unoschema 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 76

Dati di ingresso e uscitaDati di ingresso e uscita

• Ingresso:• schema concettuale

• Uscita:• schema logico• documentazione associata

03/04/2006 77

• alcuni aspetti non sono direttamenterappresentabili

Non si tratta di una pura e sempliceNon si tratta di una pura e semplicetraduzionetraduzione

03/04/2006 78

Traduzione nelmodello logico

Schema E-R

Schemalogico

03/04/2006 79

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

03/04/2006 80

AttivitAttivitàà di Traduzionedi Traduzione

• Analisi delle ridondanze• Eliminazione delle generalizzazioni• Partizionamento/accorpamento di

entità e relationship• Scelta degli identificatori primari

03/04/2006 81

Eliminazione delle gerarchieEliminazione delle gerarchie

• il modello relazionale non può rappresentaredirettamente le generalizzazioni

• entità e relazioni sono invece direttamenterappresentabili

• si eliminano perciò le gerarchie, sostituendolecon entità e relazioni

03/04/2006 82

Tre possibilitTre possibilitàà

1. accorpamento delle figlie dellageneralizzazione nel genitore

2. accorpamento del genitore dellageneralizzazione nelle figlie

3. sostituzione della generalizzazione conrelazioni

03/04/2006 83

E0 R1

A01 A02

E3

R2

E4

E2E1

A11 A21

03/04/2006 84

A11A21

TIPO

(0,1)

(0,1)

(0,..)

E0

A01 A02

R1 E3

R2

E4

03/04/2006 85

E0 R1

A01 A02

E3

R2

E4

E2E1

A11 A21

03/04/2006 86

E3

R2

E4

E2E1

A11 A21

R12

R11

A01 A02 A01 A02

03/04/2006 87

E0 R1

A01 A02

E3

R2

E4

E2E1

A11 A21

03/04/2006 88

RG2RG1(1,1)

(0,1)

(1,1)

(0,1)

E0

A01 A02

E2E1 R2

E4A11 A21

R1 E3

03/04/2006 89

AttivitAttivitàà di Traduzionedi Traduzione

• Analisi delle ridondanze• Eliminazione delle generalizzazioni• Partizionamento/accorpamento di

entità e relazioni• Scelta degli identificatori primari

03/04/2006 90

Ristrutturazioni, casi principaliRistrutturazioni, casi principali

• partizionamento verticale di entità• partizionamento orizzontale di

relationship• eliminazione di attributi multivalore• accorpamento di entità/ relationship

03/04/2006 91

Impiegato

Livello

Stipendio

Ritenute

Cognome

Indirizzo

Datanascita

Codice

03/04/2006 92

LivelloStipendio

Ritenute

Cognome

Indirizzo Datanascita

Codice

RDati

anagraficiDati

lavorativi

(1,1) (1,1)

03/04/2006 93

Agenzia

Indirizzo

Città

Telefono

Nome

(1,N)

03/04/2006 94

Numero

Indirizzo

Nome

UtenzaAgenzia Telefono

(1,N) (1,1)

Città

03/04/2006 95

IndirizzoInternoCognome

Indirizzo Datanascita

Codicefiscale

IntestazionePersona Appartamento

(0,1) (1,1)

03/04/2006 96

Persona

Interno

Indirizzo

Cognome

Indirizzo

Datanascita

Codicefiscale

(0,1)

(0,1)

03/04/2006 97

Cognome

ComposizioneGiocatore Squadra

(1,N) (1,N)

Ruolo NomeCittà

Dataacquisto

Datacessione

(0,1)

03/04/2006 98

Cognome

Comp.passata

Giocatore Squadra

(1,N) (1,N)

Ruolo Nome

Città

Dataacquisto

Datacessione

Comp.attuale

Dataacquisto

(1,1) (1,N)

03/04/2006 99

AttivitAttivitàà della ristrutturazionedella ristrutturazione

• Analisi delle ridondanze• Eliminazione delle generalizzazioni• Partizionamento/accorpamento di entità

e relazioni• Scelta degli identificatori primari

03/04/2006 100

Scelta degliScelta degli identificatoriidentificatori principaliprincipali

• operazione indispensabile per la traduzionenel modello relazionale

• Criteri• assenza di opzionalità• semplicità

03/04/2006 101

Se nessuno degli identificatori soddisfa iSe nessuno degli identificatori soddisfa irequisiti visti?requisiti visti?

Si introducono nuovi attributi (codici) contenentiSi introducono nuovi attributi (codici) contenentivalori speciali generati appositamente pervalori speciali generati appositamente per

questo scopoquesto scopo

03/04/2006 102

Traduzione verso ilTraduzione verso ilmodello relazionalemodello relazionale

• idea di base:• le entità diventano relazioni sugli stessi

attributi• le associazioni (ovvero le relazioni E-R)

diventano relazioni sugli identificatoridelle entità coinvolte (più gli attributipropri)

03/04/2006 103

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

EntitEntitàà ee relationshiprelationship molti a moltimolti a molti

03/04/2006 104

EntitEntitàà ee relationshiprelationship molti a moltimolti a molti

Impiegato(Matricola, Cognome, Stipendio)Progetto(Codice, Nome, Budget)


• 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 105

Nomi più espressivi per gli attributidella chiave della relazione che

rappresenta la relationship

Impiegato(Matricola, Cognome, Stipendio)

Progetto(Codice, Nome, Budget)


Partecipazione(Impiegato, Progetto, DataInizio)

03/04/2006 106

Composizione

ProdottoComposto Componente

Costo Nome Codice

(0,N) (0,N)

Prodotto(Codice, Nome, Costo)

Composizione(Composto, Componente, Quantità)

Relationship ricorsiveRelationship ricorsiveQuantità

03/04/2006 107

Nome

Fornitore Prodotto

Dipartimento

Fornitura

Partita IVA Genere CodiceQuantità

Nome

Telefono

(0,N) (1,N)

(1,N)

RelationshipRelationship nn--ariearie

Fornitore(PartitaIVA, Nome)Prodotto(Codice, Genere)

Dipartimento(Nome, Telefono)Fornitura(Fornitore, Prodotto, Dipartimento, Quantità)

03/04/2006 108

Cognome

Giocatore SquadraContratto

Datanascita Città NomeIngaggio

(1,1) (0,N)

Ruolo Colori sociali

RelationshipRelationship uno a moltiuno a molti

Giocatore(Cognome, DataNascita, Ruolo)Contratto(CognGiocatore, DataNascG, Squadra, Ingaggio)

Squadra(Nome, Città, ColoriSociali)• corretto?

03/04/2006 109

Soluzione piSoluzione piùù compattacompatta

Giocatore(Cognome, DataNascita, Ruolo)Contratto(CognGiocatore, DataNascG, Squadra, Ingaggio)

Squadra(Nome, Città, ColoriSociali)

Giocatore(Cognome, DataNasc, Ruolo, Squadra, Ingaggio)Squadra(Nome, Città, ColoriSociali)

• con vincolo di integrità referenziale fra Squadra inGiocatore e la chiave di Squadra

• se la cardinalità minima della relationship è 0, alloraSquadra in Giocatore deve ammettere valore nullo

03/04/2006 110

IscrizioneStudente Università

Cognome Matricola

AnnoDiCorso

Nome

Indirizzo

(1,1) (1,N)

Città

EntitEntitàà con identificazione esternacon identificazione esterna

Studente(Matricola, Università, Cognome, AnnoDiCorso)Università(Nome, Città, Indirizzo)

• con vincolo …

03/04/2006 111

Direttore DipartimentoDirezione

Cognome Codice Sede NomeData inizio

(1,1) (1,1)

Stipendio Telefono

RelationshipRelationship uno a unouno a uno

• varie possibilità:• fondere da una parte o dall'altra• fondere tutto?

03/04/2006 112



(0,1) (1,1)

Stipendio Telefono

Una possibilitUna possibilitàà privilegiataprivilegiata

Impiegato (Codice, Cognome, Stipendio)

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

• con vincolo di integrità referenziale, senza valori nulli

03/04/2006 113



(0,1) (0,1)

Stipendio Telefono

Un altro casoUn altro caso

03/04/2006 114

(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

03/04/2006 115

Schema finaleSchema finale

Dipartimento(Nome, Città, Telefono, Direttore)

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

Partecipazione(Impiegato, Progetto)

Progetto(Nome, Budget)

Sede(Città, Via, CAP)

progettazione di basi di dati: progettazione concettuale e...

Documents