Progettazione di basi di dati -...

1

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 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 3

Studio di fattibilità

Raccolta e analisi dei requisiti

Progettazione

Realizzazione

Validazione e collaudo

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

2

03/04/2006 5

�i dati hanno un ruolo centrale

• i dati sono più stabili

La progettazione di un sistema informativo riguarda due aspetti:

�progettazione dei datiprogettazione delle applicazioni

Ma:

03/04/2006 6


Raccolta e analisidei requisiti

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


Raccolta e analisidei requisiti

Progettazionedei dati

Realizzazione


Funzionamento

3

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 sono schemi di alcuni modelli di dati:

03/04/2006 11

Modello dei datiModello 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 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

4

03/04/2006 13

Due tipiDue tipi ((principaliprincipali) di ) di modellimodelli

• 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

progettazioneil più noto è il modello Entity-Relationship

03/04/2006 14

Modelli concettuali, perchModelli 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 15

Modelli concettuali, perchModelli 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 16

BD

Schema logico

Schema interno

utente

ArchitetturaArchitettura ((semplificatasemplificata) di ) di unun DBMSDBMS

5

03/04/2006 17


Progettazione logica

Progettazionefisica

03/04/2006 18

Progettazione ConcettualeProgettazione Concettuale

03/04/2006 19

Modello Modello EntityEntity--Relationship Relationship (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• ….

6

03/04/2006 21

EntitEntitàà

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

RelationshipRelationship

• 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 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 le entità, non le singole istanze (“astrazione”)

7

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 identifica univocamente nello schema:• nomi espressivi• opportune convenzioni

• singolare

03/04/2006 27

RelationshipRelationship

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

Rappresentazione grafica Rappresentazione grafica di di relationshiprelationship

EsameStudente Corso

ResidenzaImpiegato Città

8

03/04/2006 29

RelationshipRelationship, commenti, 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 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 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 32

Relationship Relationship corrette?corrette?

EsameStudente Corso

VisitaPaziente Medico

9

03/04/2006 33

Due Due relationship relationship sulle stesse entitsulle stesse entitàà

ResidenzaImpiegato Città

Sede dilavoro

03/04/2006 34

Relationship Relationship nn--ariaaria

Fornitore Prodotto

Dipartimento

Fornitura

03/04/2006 35

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

Persona

Conoscenza

03/04/2006 36

Relationship ricorsiva Relationship ricorsiva con con ““ruoliruoli””

Successione

SovranoSuccessore Predecessore

10

03/04/2006 37

Confronto

Tennista

Superficie

RelationshipRelationship ternaria ternaria ricorsivaricorsiva

Migliore Peggiore

03/04/2006 38

AttributoAttributo

• Proprietà elementare di un’entità o di unarelationship, 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 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 loro significato o uso

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

Indirizzo

11

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àà di di relationshiprelationship

• 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

12

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)

13

03/04/2006 49

Tipi di Tipi 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 a molti

• le relationship obbligatorie-obbligatorie sono molto 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)

14

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à anche agli attributi, con due scopi:

• indicare opzionalità ("informazione incompleta")

• 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 univoca delle occorrenze di un’entità

• costituito da:• attributi dell’entità

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

relationship • identificatore esterno

15

03/04/2006 57

Identificatori interniIdentificatori interni

Persona

Data Nascita

Cognome

Nome

Automobile

Targa

Modello

Indirizzo03/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 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 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

16

03/04/2006 61

GeneralizzazioneGeneralizzazione

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

Codice fiscale

Nome

Età

Città

Nascita(0,N)

(1,1)

Lavoratore Studente

Stipendio

17

03/04/2006 65

EreditarietEreditarietàà

• tutte le proprietà (attributi, relationship, altre generalizzazioni) dell’entità genitore vengono ereditate dalle entità figlie e non rappresentate 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) un numero 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 schemi Documentazione associata agli schemi concettualiconcettuali

• dizionario dei dati • entità• relationship

• vincoli non esprimibili

18

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

19

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 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 76

Dati di ingresso e uscitaDati di ingresso e uscita

• Ingresso:• schema concettuale

• Uscita:• schema logico• documentazione associata

20

03/04/2006 77

• alcuni aspetti non sono direttamente rappresentabili

Non si tratta di una pura e semplice Non si tratta di una pura e semplice traduzionetraduzione

03/04/2006 78

Traduzione nelmodello logico

Schema E-R

Schema logico

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

21

03/04/2006 81

Eliminazione delle gerarchieEliminazione 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 82

Tre possibilitTre 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 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

22

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

23

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)

24

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)

25

03/04/2006 97

Cognome

ComposizioneGiocatore Squadra

(1,N) (1,N)

Ruolo NomeCittà

Data acquisto

Data cessione

(0,1)

03/04/2006 98

Cognome

Comp.passata

Giocatore Squadra

(1,N) (1,N)

Ruolo Nome

Città

Data acquisto

Data cessione

Comp.attuale

Data acquisto

(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 degli Scelta degli identificatoriidentificatori principaliprincipali

• operazione indispensabile per la traduzione nel modello relazionale

• Criteri• assenza di opzionalità• semplicità

26

03/04/2006 101

Se nessuno degli identificatori soddisfa i Se nessuno degli identificatori soddisfa i requisiti visti?requisiti visti?

Si introducono nuovi attributi (codici) contenenti Si introducono nuovi attributi (codici) contenenti valori speciali generati appositamente per valori speciali generati appositamente per

questo scopoquesto scopo

03/04/2006 102

Traduzione verso il Traduzione verso il modello relazionalemodello 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 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

27

03/04/2006 105

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)

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)

Relationship Relationship 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

Relationship Relationship uno a moltiuno a molti

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

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

28

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

Relationship Relationship 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

29

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 -...

Documents

Transcript of Progettazione di basi di dati -...