Progettazione di basi di dati: Metodologie e modelli -...

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



Progettazione

Realizzazione


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



Progettazione

Realizzazione


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


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?


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


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


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


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”


(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


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


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

Progettazione di basi di dati: Metodologie e modelli -...

Documents

Transcript of Progettazione di basi di dati: Metodologie e modelli -...