progettazione di basi di dati: metodologie e modelli -...
TRANSCRIPT
Basi di dati
Progettazione di basi di dati: Metodologie e modelli
2
Perché preoccuparci?
• 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.) • il modello relazionale è “rigido”
3
Progettazione 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
4
Studio di fattibilità
Raccolta e analisi dei requisiti
Progettazione
Realizzazione
Validazione e collaudo
Funzionamento
Il ciclo di vita
5
Fasi (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
6
! i dati hanno un ruolo centrale
• i dati sono più stabili
La progettazione di un sistema informativo riguarda due aspetti:
! progettazione dei dati ! progettazione delle applicazioni
Ma:
Progettazione
7
Studio di fattibilità
Raccolta e analisi dei requisiti
Progettazione
Realizzazione
Validazione e collaudo
Funzionamento
Analisi & Progettazione
8
Metodologia di progetto
• 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
9
Studio di fattibilità
Raccolta e analisi dei requisiti
Progettazione
Realizzazione
Validazione e collaudo
Funzionamento
10
Progettazione fisica
Schema concettuale
Requisiti della base di dati
Progettazione concettuale
Progettazione logica
Schema logico
Schema fisico
“CHE COSA”: analisi
“COME”: progettazione
Analisi & Progettazione: dettagli
11
• Schema concettuale
• Schema logico
• Schema fisico
I prodotti della varie fasi sono schemi di alcuni modelli di dati:
Modelli di dati: concettuale, logico e fisico
12
Modello 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
13
Schemi e istanze
• 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
14
Due tipi (principali) di modelli
• 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 progettazione
il più noto è il modello Entity-Relationship
15
Modelli 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
16
Modelli concettuali, perché?
• servono per ragionare sulla realtà di interesse, indipendentemente dagli aspetti realizzativi
• permettono di rappresentare le classi di oggetti di interesse e le loro correlazioni
• prevedono efficaci rappresentazioni grafiche (utili anche per documentazione e comunicazione)
17
BD
Schema logico
Schema interno
utente
Architettura (semplificata) di un DBMS
18
Progettazione concettuale
Progettazione logica
Progettazione fisica
Progettazione: evoluzione
19
Modello Entity-Relationship (Entità-Relazione)
• Il più diffuso modello concettuale
• Ne esistono molte versioni, • (più o meno) diverse l’una dall’altra
20
I costrutti del modello E-R
• Entità • Relationship • Attributo • Identificatore • Generalizzazione • ….
21
Entità
• Classe di oggetti (fatti, persone, cose) della realtà di interesse con proprietà comuni e con esistenza “autonoma”
• Esempi: • impiegato, città, conto corrente, ordine, fattura
22
Relationship
• Legame logico fra due o più entità, rilevante nell’applicazione di interesse
• Esempi: • Residenza (fra persona e città) • Esame (fra studente e corso)
23
Uno schema E-R, graficamente
Esame Studente Corso
24
Entità (2)
• Classe di oggetti (fatti, persone, cose) della realtà di interesse con proprietà comuni e con esistenza “autonoma”
• Esempi: • impiegato, città, conto corrente, ordine, fattura
25
Entità: 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”)
26
Rappresentazione grafica di entità
Impiegato Dipartimento
Città Vendita
27
Entità, commenti
• Ogni entità ha un nome che la identifica univocamente nello schema:
• nomi espressivi
• opportune convenzioni
• singolare
28
Relationship (2)
• 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
29
Rappresentazione grafica di relationship
Esame Studente Corso
Residenza Impiegato Città
30
Relationship, commenti
• Ogni relationship ha un nome che la identifica univocamente nello schema: • nomi espressivi • opportune convenzioni
• singolare • sostantivi invece che verbi (se possibile)
31
Esempi di occorrenze
S1
S2
S4
S3
Studente
C1
C2
C3
Corso
E1
E2
E3
E4
Esame
32
Relationship, 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
33
Relationship corrette?
Esame Studente Corso
Visita Paziente Medico
34
Attenzione
S1
S2
S4
S3
Studente
C1
C2
C3
Corso
E1
E2
E3
E4
Esame
E5
35
"Promuoviamo" la relationship
Studente Corso Esame
Esame Studente Corso
La relazione Esame non è in grado di descrivere che uno Studente abbia sostenuto più volte lo stesso esame relativo a quel Corso
La soluzione sta nel rappresentare Esame come entità, collegata mediante relazioni a Studente e Corso
36
Con l’entità Esame
S1
S2
S4
S3
Studente
C1
C2
C3
Corso Esame
E5
E1
37
Due relationship sulle stesse entità
Residenza Impiegato Città
Sede di lavoro
38
Relationship n-aria
Fornitore Prodotto
Dipartimento
Fornitura
39
Esempi di occorrenze
F1 F2
F4 F3
Fornitore
P1 P2
P3
Prodotto
f1
f2
Fornitura
Dipartimento
D3 D2
D1
f3
f4
40
Relationship ricorsiva: coinvolge “due volte” la stessa entità
Conoscenza
Persona
41
Relationship ricorsiva con “ruoli”
Successione
Successore Predecessore Ministro
42
Esempi di occorrenze (2)
S2
S1 S3
Successore Predecessore
successore:S1,predecessore: S2
successore:S2,predecessore: S3
43
Confronto
Tennista
Superficie
Relationship ternaria ricorsiva
Migliore Peggiore
44
Esempi di occorrenze (3)
T1
T3
T2
S1 S2
T1 è migliore di T2 su S2
T2 è migliore di T1 su S1 T3 è migliore di T2 su S1
45
Attributo
• Proprietà elementare di un’entità o di una relationship, di interesse ai fini dell’applicazione
• Associa ad ogni occorrenza di entità o relationship un valore appartenente a un insieme detto dominio dell’attributo
46
Attributi, rappresentazione grafica
Esame
Cognome Nome
Matricola
Data Titolo
Codice
Voto
Studente Corso
47
Esempi di occorrenze (4)
S1
S2
Studente
C1
C2
Corso
E1
E2
Esame
Cognome: Rossi Nome: Mario
Matricola: 34567
Cognome: Neri Nome: Piero
Matricola: 46742
Titolo: Basi di dati Codice: Inf205
Voto: 26 Data: 25/07/2004
48
Attributi 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
49
Rappresentazione grafica
Cognome
Età Via
Numero
CAP
Indirizzo
Impiegato
50
Composizione Partecipazione
Progetto
Nome Budget
Codice
Cognome Telefono
Nome
Data
Città Indirizzo
Sede Via
CAP
Impiegato Dipartimento
Afferenza
Direzione
51
Altri costrutti del modello E-R
• Cardinalità • di relationship • di attributo
• Identificatore • interno • esterno
• Generalizzazione
52
Cardinalità di relationship
• 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
53
Esempio di cardinalità
Assegnamento Impiegato Incarico
(1,5) (0,50)
• Ad un Impiegato deve essere assegnato almeno 1 incarico ma non più di 5
• Ogni Incarico può non essere assegnato a nessuno (0) oppure può essere assegnato a un numero inferiore o uguale a 50 impiegati
54
• 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
Cardinalità
55
Occorrenze di Residenza
S1
S2
S4
S3
Studente
C1
C2
C3
Città
R3
R4
R2
R1
C4
56
Cardinalità di Residenza
Residenza Studente Città
(1,1) (0,N)
57
Tipi di relationship
• Con riferimento alle cardinalità massime, abbiamo relationship: • uno a uno • uno a molti • molti a molti
58
Relationship “molti a molti”
Esame Studente Corso
(0,N) (0,N)
Scalata Montagna Alpinista (0,N) (1,N)
Abilitazione Macchinista Locomotore (1,N) (1,N)
59
Relationship “uno a molti”
Impiego Persona Azienda
(0,1) (0,N)
Ubicazione Cinema Località (1,1) (0,N)
Ubicazione Comune Provincia (1,1) (1,N)
60
Due avvertenze
• Attenzione al "verso" nelle relationship uno a molti
• le relationship obbligatorie-obbligatorie sono molto rare
61
Relationship “uno a uno”
Titolarità Professore Cattedra
(0,1) (0,1)
Titolarità Professore
di ruolo Cattedra (1,1) (0,1)
Titolarità Professore
di ruolo Cattedra coperta
(1,1) (1,1)
62
Cardinalità di attributi
• E’ possibile associare delle cardinalità anche agli attributi, con due scopi:
• indicare opzionalità ("informazione incompleta") • indicare attributi multivalore
63
Rappresentazione grafica
Telefono
Nome
Numero patente
(0,N)
(0,1)
Impiegato
64
Identificatore 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
65
Identificatori interni (1)
Targa
Modello Automobile
L’attributo Targa è identificatore interno dell’entità Automobile in quanto non posso esistere due automobili con la stessa targa
66
L’insieme degli attributi: Nome, Cognome e Data di nascita costituiscono l’identificatore interno dell’entità Persona in quanto non possono esistere (nel nostro caso) due persone aventi nome, cognome e data di nascita identici
Data Nascita
Cognome
Nome Indirizzo
Persona
Identificatori interni (2)
67
Identificatore esterno
Cognome Matricola
Anno di corso
Nome
Indirizzo
(1,1) (0,N)
Iscrizione Studente Università
L’attributo Matricola e l’entità Università rappresentano l’identificatore esterno in quanto possiamo avere studenti con lo stesso numero di matricola, ma appartententi ad università diverse
68
Alcune 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é è opportuno privilegiare l’inserimento di attributi nelle entità piuttosto che nelle relationship
• Perché non parliamo degli identificatori delle relationship?
69
(0,1) (0,1)
(0,N) (1,1)
(0,1) (1,1)
(1,N)
(0,N)
(1,N)
(1,N)
Città
Telefono
Nome
Nome
Cognome
Budget
Data
Via
CAP
Codice
Dipartimento
Composizione
Sede
Direzione
Afferenza
Impiegato
Progetto
Partecipazione
Indirizzo
70
Attenzione
• Differenze apparentemente piccole in cardinalità e identificatori possono cambiare di molto il significato …
71
(0,1) (0,1)
(0,N) (1,1)
(0,1) (0,N)
(1,N)
(1,N)
Città
Telefono
Nome
Nome
Cognome
Budget
Data
Via
CAP
Codice
Dipartimento
Composizione
Sede
Direzione
Afferenza
Impiegato
Progetto
Partecipazione
Indirizzo
(1,1)
(1,N)
72
(0,1) (0,1)
(0,N) (1,1)
(0,1) (1,N)
(1,1)
(0,N)
(1,N)
(1,N)
Città
Telefono
Nome
Nome
Cognome
Budget
Data
Via
CAP
Codice
Dipartimento
Composizione
Sede
Direzione
Afferenza
Impiegato
Progetto
Partecipazione
Indirizzo
73
Identificatori esterni e cardinalità
• Nel primo schema E-R (slide 71) viene assegnato ad ogni Dipartimento una ed una sola Sede: possiamo avere quindi anche dipartimenti con lo stesso Nome, l’importante è che la Città dove ha sede il dipartimento sia diversa
• Viceversa nel secondo schema E-R (slide 72) viene assegnato ad ogni Sede uno ed un solo Dipartimento: quindi possiamo avere nella stessa Città più dipartimenti ma con Nome diverso
74
Generalizzazione
• mette in relazione una o più entità E1, E2, ..., En con una entità E, che le comprende come casi particolari
• E è generalizzazione di E1, E2, ..., En • E1, E2, ..., En sono specializzazioni (o
sottotipi) di E
75
Rappresentazione grafica
Dipendente
Impiegato Funzionario Dirigente
76
Proprietà delle 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
77
Codice fiscale
Nome
Età
Città
Nascita (0,N)
(1,1)
Stipendio
Persona
Lavoratore Studente
Proprietà delle generalizzazioni: esempio
78
Ereditarietà
• tutte le proprietà (attributi, relationship, altre generalizzazioni) dell’entità genitore vengono ereditate dalle entità figlie e non rappresentate esplicitamente
79
Tipi di generalizzazioni
• totale se ogni occorrenza dell'entità genitore è occorrenza di almeno una delle entità figlie, altrimenti è parziale
• esclusiva se ogni occorrenza dell'entità genitore è occorrenza di al più una delle entità figlie, altrimenti è sovrapposta
• consideriamo (senza perdita di generalità) solo generalizzazioni esclusive e distinguiamo fra totali e parziali
80
Persona
Disoccupato Lavoratore
Generalizzazione esclusiva parziale
81
Persona
Uomo Donna Uomo Donna
Generalizzazione esclusiva totale
82
Altre proprietà
• possono esistere gerarchie a più livelli e multiple generalizzazioni allo stesso livello
• un'entità può essere inclusa in più gerarchie, come genitore e/o come figlia
• se una generalizzazione ha solo un’entità figlia si parla di sottoinsieme
• alcune configurazioni non hanno senso • il genitore di una generalizzazione totale può non
avere identificatore, purché …
83
Esercizio
• 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)
84
Direttore Segretario
Responsabile
Persona CF
Cognome Età
Donna
Militare
Stipendio Matr.
Impiegato Studente
Progettista
Uomo
Schema concettuale
85
Documentazione associata agli schemi concettuali
• dizionario dei dati • entità • relationship
• vincoli non esprimibili
86
(1,1) (0,1)
(0,N) (0,1)
(0,1) (1,1)
(1,N)
(0,N)
(1,N)
(1,N)
Città
Telefono
Partecipazione
Nome
Nome
Cognome
Budget
Data
Via
CAP
Codice
Indirizzo
Dipartimento
Composizione
Sede
Direzione
Afferenza
Impiegato
Progetto
Schema concettuale (2)
87
Dizionario 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à
88
Dizionario dei dati (relationship)
Relazioni Descrizione Componenti Attributi Direzione Direzione di un
dipartimento Impiegato, Dipartimento
Afferenza Afferenza a un dipartimento
Impiegato, Dipartimento
Data
Partecipazione Partecipazione a un progetto
Impiegato, Progetto
Composizione Composizione dell'azienda
Dipartimento, Sede
89
Vincoli 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 quale afferisce
(3) Un dipartimento con sede a Roma deve essere diretto da un impiegato con più di dieci anni di anzianità
(4) Un impiegato che non afferisce a nessun dipartimento non deve partecipare a nessun un progetto
Modellazione dei dati in UML
• UML viene talvolta utilizzato in alternativa al modello ER per la rappresentazione concettuale dei dati
• Si fa uso dei diagrammi delle classi • Cambia la rappresentazione diagrammatica ma
non l’approccio alla progettazione • Vediamo come sia possibile rappresentare
schemi concettuali con UML
90
Codice Cognome Stipendio Età
Impiegato
Nome Budget Data consegna
Progetto
Classi
91
Esame
Residenza
Matricola Anno Iscrizione
Studente Nome Anno corso
Corso
Cognome Stipendio Età
Impiegato
Nome Numero abitanti
Città
Sede di lavoro
Associazioni
92
Matricola Anno Iscrizione
Studente Nome Anno corso
Corso
Data Voto
Esame
Classe di associazione
93
La classe Esame è una classe di associazione che usiamo per rappresentare gli attributi Voto e Data dell’associazione tra la classe Studente e la classe Corso
Denominazione Indirizzo
Fornitore Codice Prezzo
Prodotto
Nome Telefono
Dipartimento
Quantità
Fornitura
Associazione ternaria
94
E’ rappresentata da un rombo con le classi che vi partecipano (Fornitore, Dipartimento e Prodotto), facendo uso di una classe di associazione (Fornitura) per assegnare attributi all’associazione tra queste classi
Denominazione Indirizzo
Fornitore Codice Prezzo
Prodotto
Nome Telefono
Dipartimento
Quantità
Fornitura
Reificazione di associazione
95
Le associazioni n-arie sono poco usate nei diagrammi delle classi e, per questo, le reifichiamo ovvero trasformiamo l’associazione (Fornitura) in una classe legata alle classi originarie con associazioni binarie
Team Tecnico
Azienda Filiale
Aggregazione e composizione
96
• Un Tecnico fa parte di un Team. Esso può essere rappresentato indipendentemente dal Team di cui fa parte (aggregazione semplice)
• Una Filiale è parte di un’Azienda. Essa non può essere rappresentata indipendentemente dall’Azienda (composizione)
Ordine Fattura Vendita 1 0..1
Persona Città Residenza *
Turista Viaggio Prenotazione * 1..*
Associazioni con molteplicità
97
• Un Ordine può avere 0 o al massimo 1 Fattura di vendita associata. Viceversa una Fattura ha 1 solo Ordine di vendita
• L’assenza di molteplicità sottintende 1..1, quindi una Persona può essere residente in una ed una sola Città. Viceversa una Città può avere 0 o al massimo N persone residenti
• Un Turista può prenotare 1 o al massimo N viaggi. Viceversa un Viaggio può essere prenotato da 0 o al massimo N turisti
Targa {id} Modello Colore
Automobile Data Nascita {id} Cognome {id} Nome {id} Indirizzo
Persona
Identificatori
98
• Targa è identificatore della classe Automobile
• L’insieme di attributi Data Nascita, Cognome e Nome costituiscono l’identificatore per la classe Persona
Matricola {id} Anno Iscrizione Cognome
Studente Nome {id} Città Indirizzo
Università Iscrizione
<<identificante>> 1 1..*
Identificatore esterno
99
• Lo stereotipo <<identificante>> serve ad indicare che l’associazione tra Studente e Università è appunto identificante in quanto insieme all’attributo Matricola identifica uno studente
Codice Fiscale {id} Cognome Età
Persona
Donna Situazione Militare
Uomo
Specializzazione
Dottore Avvocato
Partita IVA {id} Indirizzo
Professionista
Ingegnere
{parziale, esclusiva}
Generalizzazioni
100
Esclusiva Totale
Esclusiva Parziale
Codice {id} Cognome Stipendio Età
Impiegato
Nome {id} Telefono 1..*
Dipartimento
Città {id} Indirizzo
Sede Nome {id} Budget Data consegna 0..1
Progetto
Data afferenza
Afferenza
Data inizio
Partecipazione
Direzione
Composizione
1
1
0..1
0..1 1..*
1..* 1..*
*
<<identificante>>
Progetti aziendali nei quali lavorano gli impiegati
Uno schema concettuale in UML
101