Embed Size (px)
Citation preview
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
Studio di fattibilità
Raccolta e analisidei requisiti
Progettazionedei dati
Realizzazione
Validazione ecollaudo
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 ecollaudo
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
Progettazioneconcettuale
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
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 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
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
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
Progettazioneconcettuale
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)
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
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(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)
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
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
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)
