View
221
Download
0
Category
Preview:
Citation preview
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
Studio di fattibilità
Raccolta e analisidei requisiti
Progettazionedei dati
Realizzazione
Validazione e collaudo
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
Studio di fattibilità
Raccolta e analisidei requisiti
Progettazionedei dati
Realizzazione
Validazione e collaudo
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
Progettazioneconcettuale
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
Rappresentazione graficaRappresentazione grafica
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
Rappresentazione graficaRappresentazione grafica
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
Progettazioneconcettuale
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)
Partecipazione(Matricola, Codice, DataInizio)
• 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(Matricola, Codice, DataInizio)
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
Direttore DipartimentoDirezione
Cognome Codice Sede NomeData inizio
(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
Direttore DipartimentoDirezione
Cognome Codice Sede NomeData inizio
(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)
Recommended