1 Il modello Entity-Relationship per il progetto delle basi di dati Massimo Paolucci ([email protected]) DIST – Università di Genova 2 Le metodologie di progettazione delle Basi di Dati Una metodologia di progettazione consiste generalmente in: • Generare una decomposizione in passi successivi e indipendenti dell'intera attività di progetto. • Stabilire una serie di strategie da seguire nei vari passi. • Stabilire alcuni modelli di riferimento, per descrivere i dati in ingresso e in uscita dalle varie fasi.
• Generare una decomposizione in passi successivi e indipendenti dell'intera attività di progetto.
• Stabilire una serie di strategie da seguire nei vari passi.
• Stabilire alcuni modelli di riferimento, per descrivere i dati in ingresso e in uscita dalle varie fasi.
3
Ciclo di vita di un S.I.
Studio di fattibilità
Raccolta ed analisi dei requisiti
Funzionamento
Validazione e collaudo
Implementazione
Progettazione
4
Le tre fasi in cui si deve articolare un progetto di database sono:
La progettazione concettuale.Rappresentare le specifiche con una descrizione formale e completasenza preoccuparsi né della modalità con cui queste informazioniverranno definite in un sistema reale.
La progettazione logica.Traduzione dello schema concettuale in termini del modello di datiproprio del tipo di DBMS a disposizione. In questa fase si tiene contoanche dei criteri di ottimizzazione delle rappresentazioni, in base alleoperazioni da effettuare sui dati.
La progettazione fisica.Lo schema logico è completato con la specifica dei parametri dimemorizzazione dei dati.
5
Requisiti dellabase di dati
Progettazione di basi di datiProgettazione concettuale
Progettazione logica
Progettazione fisica
SCHEMA CONCETTUALE
SCHEMA LOGICO
SCHEMA FISICO
6
I diagrammi Entità-Relazione (ER Diagram)
Sono uno strumento per la progettazione concettuale diDB.
Da essi può essere agevolmente ricavato lo schema fisicodi DB relazionali.
Sono utilizzati in strumenti di progettazione assistita(CASE)
La sintassi utilizzata è semplice ed intuitiva.
7
I diagrammi Entità-Relazione (ER Diagram) (cont.)
La specifica del DB definita è composta da:
Un insieme di diagrammi ERRappresentano i dati operativi che devono esserestrutturati nel SI
Un insieme di dizionari dei dati associati ai diagrammi ER
Descrivono verbalmente i diagrammi per mezzo ditabelle riassuntive
Un insieme di vincoli di integrità sui dati
Specificano condizioni particolari che non possonoessere desunte dai diagrammi.
8
Entità:
Classi/insiemi di oggetti riguardo i quali si ha interesse a raccogliere informazioni.
Le componenti dei diagrammi ER
Entità
Impiegato
Esempi
Città
Fornitore
9
Relazione:
Legame logico tra entità riguardo il quale si ha interesseraccogliere informazioni.
ResidenzaPersona
Esempio
Città
Le componenti dei diagrammi ER (cont.)
Relazione
10
ResidenzaPersona
Esempi di relazione
Città
Sede lavoro
Due relazioni binarietra le stesse entità
Parte
Componente
main sub
Una relazione ricorsiva
FornituraFornitore Prodotto
Dipartimento
Una relazione ternaria
11
Attributi:
Specificano le informazioni che devono essere raccolteriguardo entità e relazioni.
Le componenti dei diagrammi ER (cont.)
EsameStudente Corso
Entità
Attributo 1Attributo 2...
Relazione
Attributo 1...
Esempio
MatricolaNome
NomeAnno di corso
VotoData esame
identificatore
12
Gli attributi possono anche essere composti.
Le componenti dei diagrammi ER (cont.)
Attributo 1Attributo Composto [Comp1,
Comp2,...]...
Entità
C.FNomeIndirizzo [Via, CAP, Città]....
Persona
Esempio
13
Gli attributi possono essere obbligatori oppure opzionali.
NotaGli attributi che possiedono una molteplicità il più dellevolte rappresentano entità.
Le componenti dei diagrammi ER (cont.)
C.FNomeTarga auto (0, N)
PersonaEsempio
PossessoPersona Auto
Targa autoC.FNome
15
Un esempio di diagramma ER
AfferenzaImpiegato Dipartimento
Direzione
Partecipazione Composizione
Progetto Sede
codicecognomestipendioetà
nomebudgetdata consegna
nometelefono
cittàindirizzo [civico, via, CAP]
data afferenza
data inizio
Nota: esempi di notazioni alternative
Sedecittà
indirizzocivicoviaCAP
PossessoPersona Auto
16
Cardinalità delle relazione:
Specifica il numero minimo e massimo delle occorrenzedelle entità nelle relazioni.
Le componenti dei diagrammi ER (cont.)
Relaz. REntità 1 Entità 2
(min1, max1) (min2, max2)
min1: il numero minimo di volte in cui Entità 1 partecipa alla Relaz. Rmax1: il numero massimo di volte in cui Entità 1 partecipa alla Relaz.
R
min può valere: • 0 la relazione è opzionale per l’entità• 1 la relazione è obbligatoria per l’entitàmax può valere: • 1 l’entità può partecipare una sola volta alla relazione• N l’entità può partecipare più volte alla relazione
17
Esempio di cardinalità
AssegnamentoImpiegato Incarico(1, N) (0, N)
Significato:
ad un impiegato viene sempre assegnato un incaricoad un impiegato possono essere assegnati più incarichiun incarico può anche non essere (ancora) assegnato ad un impiegatouno stesso incarico può essere assegnato a tanti impiegati
18
Tipi di cardinalità delle relazione:
Sono possibili tre tipi di relazioni in funzione della cardinalitàmassima:
Relazioni 1-1 “uno a uno”Relazioni 1-N (oppure N-1) “uno a molti”Relazioni N-N “molti a molti”
Le componenti dei diagrammi ER (cont.)
Esempi
VenditaOrdine Fattura(0, 1) (1, 1)
Relazione 1-1
ResidenzaPersona Città(1, 1) (0, N)
Relazione 1-N
PrenotazioneTurista Viaggio(1, N) (0, N)
Relazione N-N
19
Identificatori:
Sono attributi che individuano univocamente un’entità.L’identificatore può essere:
IscrizioneStudente Università
EntitàAttributo 1Attributo 2...
MatricolaNome
NomeCittà
identificatore
Le componenti dei diagrammi ER (cont.)
Singolo
Multiplo (composto)
Esterno
EntitàAttributo 1Attributo 2Attributo 3...
identificatori
(1, 1) (0, N)
identificatori
20
Un esempio di diagramma ER (cont.)
AfferenzaImpiegato Dipartimento
Direzione
Partecipazione Composizione
Progetto Sede
codicecognomestipendioetà
nomebudgetdata consegna
nometelefono
cittàindirizzo [civico, via, CAP]
data afferenza
data inizio
(1, 1)
(0, N)
(0, 1)
(0, 1) (1, N)
(1, N) (1, N)
(1, 1)
21
Gerarchie:
Specificano legami gerarchici tra entità, ossiageneralizzazioni (bottom-up) o specializzazioni (top-down).
Le componenti dei diagrammi ER (cont.)
Per mezzo delle gerarchie si esprimono:
Generalizzazioni totali
Generalizzazioni parziali
Sottinsiemi
Persona
Uomo Donna
Professionista
Avvocato Ingegnere
Persona
Studente
22
Gli attibuti nelle gerarchie vengono ereditati dalle entitàsuperiori a quelle inferiori.
Le componenti dei diagrammi ER (cont.)
Persona
Uomo Donna
EsempiCFcognomeetà
situazione militare
Persona
Uomo Donna
CFcognomeetà
situazione militare
Impiegato Studente
Direttore ProgettistaSegretario
Responsabiledi progetto
stipendio matricola
orario
23
Il dizionario del dati:
E’ composto da due tabelle:
Le componenti dei diagrammi ER (cont.)
Tabella delle Entità
Tabella delle Relazioni
Entità Descrizione Attributi Identificatore
Relazione Descrizione Entità coinvolte Attributi
24
Il vincoli di integrità sui dati dati:
Corrisponde all’insieme delle regole che non sonodeducibili dal diagramma.
Esempio
Le componenti dei diagrammi ER (cont.)
AfferenzaImpiegato Dipartimento
Direzione
Partecipazione Composizione
Progetto Sede
codicecognomestipendioetà
nomebudgetdata consegna
nometelefono
cittàindirizzo [civico, via, CAP]
data afferenza
data inizio
• un impiegato può dirigere solo un dipartimento alla volta• un impiegato non può avere un salario maggiore del direttore• il budget di un progetto deve essere maggiore della somma degli stipendi
degli impiegati coinvolti
(1, 1)
(0, N)
(0, 1)
(0, 1) (1, N)
(1, N) (1, N)
(1, 1)
25
Modellazione dei dati con UML
Unified Modeling Language
• Un linguaggio (e notazione) universale, per rappresentare sistemi software
• Uno standard OMG (Object Management Group)
• Autori:
Grady Booch
Ivar Jacobson
Jim Rumbaugh
• Co-proponenti: Microsoft, IBM, Oracle, HP, Platinum, Sterling, Unysis (e tanti altri)
26
Modellazione dei dati con UMLIl diagramma delle classi• Le componenti principali nei diagrammi delle classi sono le
classi e le associazioni che corrispondono sostanzialmente alle entità e alle relazioni del modello
• Le classi vengono rappresentate da rettangoli contenenti, in alto, il nome della classe e, al loro interno, gli attributi ad essa associati
• Le associazioni binarie si presentano con delle linee che congiungono le classi coinvolte nell’associazione, mentre per leassociazioni n-arie, la notazione grafica e’ la stessa del modello E-R
• Gli attributi di una associazione vengono indicati attraverso leclassi di associazione che descrivono appunto le relative proprietà
• La relazione di aggregazione è un’associazione speciale che aggrega uno o più concetti che in un singolo concetto composito
• Le generalizzazioni, in modo similare ai diagrammi E-R, sono indicate con opportune frecce, linee continue che terminano in un triangolo vuoto, che collegano i concetti figli al padre
27
Modellazione dei dati con UML
Codice {id}CognomeStipendioEta
Impiegato
Nome {id}[1]Telefono[1..*]
Dipartimento
Nome {id}BudgetData Consegna
Progetto
-Data Afferenza
Afferenza
1..* 0..1
Data Inizio
Partecipazione1..*
*
Citta' {id}Indirizzo
Sede
1..*
1
10..1
Direzione
<<identificante>>
28
Modellazione dei dati con UML
Codice fiscale {id}CognomeEta'
Persona
Situazione militare
Uomo Donna
-Partita IVA {id}-Indirizzo
Professionista
Avvocato Ingegnere
Specializzazione
Dottore
29
La progettazione concettuale
La raccolta dei requisiti
Le principali fonti per d’informazione per l’acquisizione delle specifiche sono:
• Gli utenti delle applicazioni
• La documentazione esistente
• Eventuali realizzazioni preesistenti
Strumenti
• Uso del linguaggio naturale
• Interviste con il cliente e gli utenti finali
• Questionari
• Workshop
30
La progettazione concettuale
La raccolta dei requisiti
L’attività di specifica è atta a formalizzare un documento illustrante le informazioni raccolte
• Scegliere il corretto livello di astrazione
• Standardizzare la struttura delle frasi
• Evitare frasi contorte
• Unificare i termini (possibilmente evitando sinonimi)
• Rendere esplicito il contesto di riferimento
• Costruire un glossario dei termini
31
La progettazione concettuale
Criteri di rappresentazione• Un concetto che ha proprietà significative atte a
descrivere classi di oggetti deve essere rappresentato con una entità
• Un concetto senza caratteristiche proprie rilevanti e avente struttura semplice verrà rappresentato come attributo di un concetto cui si riferisce
• L’associazione tra due o più concetti del dominio applicativo è rappresentata con una relazione tra le rispettive entità
• Entità aventi caratteristiche comuni possono essere associate facendo uso della struttura di generalizzazione
32
La progettazione concettualeStrategie di progetto• Top-down - Lo schema concettuale è il frutto di una
serie di raffinamenti successivi a partire da uno schema generale in cui sono presenti pochi concetti ad un alto livello di astrazione
• Bottom-up - Lo schema concettuale è costruito attraverso una serie di fusioni successive a partire da un insieme di schemi elementari in cui vengono rappresentati singoli frammenti della realtà di interesse
• Inside-out - Si basa sulla strategia bottom-up avendo però come base di partenza gli schemi dei concetti più rilevanti nel dominio applicativo
• Mista - Lo scheletro dello schema viene costruito con una strategia bottom-up che mantiene però un alto livello di astrazione dei concetti rappresentati. Lo schema risultante è poi raffinato con strategia top-down
33La progettazione logica: dai diagrammiER alla struttura del DB relazionale
Il modello ER viene sviluppato dall’analisi dei requisiti procedendo generalmente in modo top-down.
La progettazione logica consiste nel definire la struttura del DB relazionale partendo dal modello relazionale.
Prima della traduzione il diagramma ER va riorganizzato:Eliminare le ridondanzeEliminare le generalizzazioniPartizionare/accorpare entità e/o associazioniScegliere gli identificatori primari
Questo passaggio da struttura concettuale a struttura logica non è necessario con modelli object-oriented.
34
Ristrutturazione dei diagrammi ER
Eliminazione delle ridondanze
Le ridondanze sono causate da dati derivabili (che dovrebbero essere aggiornati).
L’eliminazione può essere fatta valutando i singoli casi.
Esempi:
FatturaImporto nettoIVAImporto lordo
ComposizioneAcquisto Prodottoimporto totale prezzo(1, N) (1, N)
35
Ristrutturazione dei diagrammi ER (cont.)
Eliminazione delle generalizzazioni
Tre possibilità:
1. Accorpamento delle entità figlie con l’entità madre
E0
E1 E2
A01A02
A11 A21
R1
(x, y)R2
E3
E4
E0A01A02A11A21Tipo
R1
(0, y)R2
E3
E4
36
2. Suddivisione delle caratteristiche dell’entità madre nelle entità figlie
Ristrutturazione dei diagrammi ER (cont.)
E1 E2
R12
(x, y)R2
E3
E4
R11
A01A02A11
A01A02A21
3. Sostituzione delle generalizzazioni con associazioni.
E0
E1 E2
A01A02
A11 A21
R1
(x, y)R2
E3
E4
Rg1 Rg2
(1,1) (1,1)
(0,1) (0,1)
37
Ristrutturazione dei diagrammi ER (cont.)
Partizionare/accorpare entità o associazioni
Questo significa:
a. Suddividere in più entità distinte gruppi di dati che sonousati separatamente da diverse procedure.
Traduzione dei diagrammi ER nelmodello relazionale
Le regole di traduzione
1. Entità:
diventano tabelle ed i loro identificatori chiavi primarie.
2. Associazioni N-N:
diventano tabelle con chiave primaria formata dall’unione delle chiavi delle entità coinvolte.
3. Associazioni 1-N:
gli attributi dell’associazione e la chiave primaria della tabella relativa all’entità dal lato “N” sono inclusi nella tabella relativa all’entità dal lato “1”.
Definire le tabelle specificando le chiavi primarie ed esterne.
42
Traduzione dei diagrammi ER nel modellorelazionale (cont.)
Le regole di traduzione
4. Entità con identificatori esterni:
si procede come per le associazioni 1-N ma la chiave primaria risulta composta.
5. Associazioni 1-1:
se obbligatorie si procede come per le 1-N scegliendo il lato in cui includere gli attributi e la chiave esterna;
se una opzionale si includono gli attributi e la chiave esterna sul lato “obbligatorio”;
se entrambe opzionali si costruisce una tabella autonoma come per il caso N-N.
43
Traduzione dei diagrammi ER nel modellorelazionale (cont.)
Esempi di regole di traduzione: associazioni molti a molti
