Basi di dati Progettazione di basi ... - Politecnico di...

Basi di datiProgettazione di basi di dati

Elena BaralisPolitecnico di Torino

2

Progettazione di basi di dati

• La progettazione di una base di dati è una delle attività del processo di sviluppo di un sistema informativo!va inquadrata nel contesto più ampio di ciclo

di vita di un sistema informativo

Basi di dati

Modello E-R -Elena BaralisPolitecnico di Torino

3

Ciclo di vita di un sistema informativoBasi di dati


Studio di fattibilità

Raccolta dei requisiti e analisi

Progettazione

Prototipazione Implementazione

Validazione e testing

Funzionamento

4

Ciclo di vita di un sistema informativo

Studio di fattibilità: determinazione dei costi delle diverse alternative e delle priorità di realizzazione delle componenti del sistema

Raccolta e analisi dei requisiti:definizione delle proprietà e delle funzionalità del sistema informativo– richiede interazione con l’utente– produce una descrizione completa, ma

informale del sistema da realizzare

Basi di dati


5


Progettazione: suddivisa in progettazione dei dati e delle applicazioni.– produce descrizioni formali

Prototipazione: realizzazione rapida di una versione semplificata del sistema per valutarne le caratteristiche. – può portare a modifica dei requisiti o

revisione del progetto

Basi di dati


6


Implementazione: realizzazione del sistema informativo secondo le caratteristiche definite nella fase di progettazione

Validazione e testing: verifica del corretto funzionamento e della qualità del sistema informativo

Funzionamento: operatività del sistema– richiede operazioni di gestione e

manutenzione

Basi di dati


7

Progettazione di una base di dati

• La base di dati costituisce un componente importante del sistema complessivo!metodologia di progettazione basata sui dati:

–la progettazione della base di dati precede la progettazione delle applicazioni che la utilizzano

–attenzione maggiore alla fase di progettazione rispetto alle altre fasi

Basi di dati


8

Metodologia di progettazione

• Una metodologia di progettazione consiste in– decomposizione dell’attività di progetto in

passi successivi indipendenti tra loro– strategie da seguire nei vari passi e criteri per

la scelta delle strategie– modelli di riferimento per descrivere i dati

d’ingresso e di uscita delle varie fasi

Basi di dati


9

Progettazione basata sui dati

• Per le basi di dati, metodologia basata sulla separazione delle decisioni– cosa rappresentare nella base di dati

!progettazione concettuale– come rappresentarlo

!progettazione logica e fisica

Basi di dati


10

Fasi della progettazione di basi di datiBasi di dati


Requisiti applicazione

Progettazioneconcettuale

Progettazionelogica

Progettazionefisica

Schema concettuale

Schema logico

Schema fisico

11

Progettazione concettuale

• Rappresentazione delle specifiche informali sotto forma di schema concettuale– descrizione formale e completa, che fa

riferimento ad un modello concettuale– indipendenza dagli aspetti implementativi

(modello dei dati)– obiettivo è la rappresentazione del contenuto

informativo della base di dati

Basi di dati


12

Progettazione logica

• Traduzione dello schema concettuale nello schema logico– fa riferimento al modello logico dei dati

prescelto– si usano criteri di ottimizzazione delle

operazioni da fare sui dati– qualità dello schema verificata mediante

tecniche formali (normalizzazione)

Basi di dati


13

Progettazione fisica

• Specifica dei parametri fisici di memorizzazione dei dati (organizzazione dei file e degli indici)– produce un modello fisico, che dipende dal

DBMS prescelto

Basi di dati


14

Il modello E-R (Entity-Relationship)

• E` il modello concettuale più diffuso• Fornisce costrutti per descrivere le specifiche

sulla struttura dei dati– in modo semplice e comprensibile– con un formalismo grafico– in modo indipendente dal modello dei dati,

che può essere scelto in seguito• Ne esistono numerose varianti

Basi di dati


15

Costrutti principali del modello E-R

• Entità• Relationship• Attributi• Identificatori• Generalizzazioni e sottoinsiemi

Basi di dati


16

Entità

• Rappresenta classi di oggetti del mondo reale (persone, cose, eventi, ...), che hanno– proprietà comuni– esistenza autonoma

• Esempi: dipendente, vendita, articolo• Un’occorrenza di un’entità è un oggetto della

classe che l’entità rappresenta

Basi di dati


Nome entità

17

Relationship

• Rappresenta un legame logico tra due o più entità

• Esempi: esame tra studente e corso, residenza tra persona e città

• Da non confondere con la relazione del modello relazionale– a volte tradotto con il termine associazione

Basi di dati


Nome relationship

18

Esempi di relationshipBasi di dati


EsameStudente Corso

ResidenzaPersona Comune

Nascita

19

Occorrenze di relationship• Un’occorrenza di una relationship è una n-upla

(coppia nel caso di relazione binaria) costituita da occorrenze di entità, una per ciascuna delle entità coinvolte

• Non vi possono essere n-uple identiche

Basi di dati


s2 s3

s1

e1

c1c2

c3c4

e2

e3

e4

e5

!Non è possibile che uno studente sostenga due volte lo stesso esame

Studente Corso

20

Relationship ternariaBasi di dati


EsameStudente Corso

Tempo

• Uno studente può ripetere lo stesso esame in tempi diversi

• Esempio di istanza di esames1 c1 t1s1 c1 t2

...

21

Occorrenze di relationship ternariaBasi di dati


Studente Corsos1

e1

c1

c2

e2e3

e4

s2

t1

t2Tempo

22

Relationship ricorsivaBasi di dati


• Relationship di un’entità con se stessa• Se la relationship non è simmetrica, occorre

definire i due ruoli dell’entità

Genitore

Persona

Incrocio

Via FiglioPadre

23

Attributo

• Descrive una proprietà elementare di un’entità o di una relazione

• Esempi: – cognome, nome, matricola sono attributi che

descrivono l’entità studente– voto è un attributo che descrive la relationship

esame• Ogni attributo è caratterizzato dal dominio,

l’insieme dei valori ammissibili per l’attributo

Basi di dati


Nome attributo

24

Esempi di attributiBasi di dati



Nascita

Nome

Cognome

Codice Fiscale

Nome

Provincia

Data Nascita

Data Trasferimento

Cognome

EsameStudente Corso

Tempo

Nome

Matricola

Data

Voto

Codice

Nome

Nome Docente

25

Attributo composto

• Raggruppamento di attributi affini per significato o per uso

• Esempio

Basi di dati


Nome attr.composto

Nome attr. 1

Nome attr. 2

Nome attr. i

Indirizzo

Via

Numero Civico

CAP

26

Cardinalità delle relationship

• Sono specificate per ogni entità che partecipa ad una relationship

• Descrivono numero minimo e massimo di occorrenze di una relationship a cui può partecipare una occorrenza di un’entità– minimo assume i valori 0 (partecipazione

opzionale) o 1 (partecipazione obbligatoria)– massimo varia tra 1 (al più una occorrenza) e

N (numero arbitrario di occorrenze)

Basi di dati


27


• Corrispondenza 1 a 1

Basi di dati


RettoreProfessore Università

(0,1) (1,1)

p4

p1

r1

u1

p2

u2

p3

r2Professore Università

28


• Corrispondenza 1 a N

Basi di dati



(1,1) (1,N)

p4

p1

r1

c1

p2

c2

p3

r2

r3

r4

Persona Comune

29


• Corrispondenza molti a molti

Basi di dati


Esame SuperatoStudente Corso(0,N) (0,N)

s4

s1

e1

c1

s2

c3

s3

e2

e3

e4

c2

Studente Corso

30

Relationship ternariaBasi di dati


EsameStudente Corso

Tempo

(0,N)(1,N)

(0,N)

31

Osservazioni

• Le cardinalità minime raramente sono 1 per tutte le entità coinvolte in una relationship

• Le cardinalità massime di una relationship n-aria sono (praticamente) sempre N!se la partecipazione di un’entità E ha

cardinalità massima 1, è possibile eliminare la relationship n-aria e legare l’entità E con le altre mediante relationship binarie

Basi di dati


32

Cardinalità di un attributo

• Può essere specificata per gli attributi di entità o relationship

• Descrive numero minimo e massimo di valori dell’attributo associati ad una occorrenza di un’entità o di una relationship– se è omessa corrisponde ad (1,1)– minima 0 corrisponde ad attributo che

ammette il valore nullo– massima N corrisponde ad attributo che può

assumere più di un valore per la stessa occorrenza (attributo multivalore)

Basi di dati


33

Cardinalità di un attributoBasi di dati


PersonaNome

Cognome

Codice Fiscale

Titolo Studio(0,N)

Professione(0,1)

34

Identificatore

• E` specificato per ogni entità• Descrive i concetti (attributi e/o entità) dello

schema che permettono di individuare in modo univoco le occorrenze delle entità– ogni entità deve avere almeno un

identificatore– può esistere più di un identificatore

appropriato per un’entità

Basi di dati


35

Identificatore interno

• Semplice: costituito da un solo attributo

Basi di dati


PersonaNome

Cognome

Codice Fiscale

• Composto: costituito da più attributi

PersonaNome

Cognome

Data Nascita

Professione

36

Identificatore esternoBasi di dati


• L’entità che non dispone internamente di attributi sufficienti per definire un identificatore è denominata entità debole

• L’entità debole deve partecipare con cardinalità (1,1) in ognuna delle relationship che forniscono parte dell’identificatore

Nome

Cognome IscrizioneStudente Università(1,1) (0,N)

Matricola

Nome Città

37

Identificatore esternoBasi di dati


• E` possibile rappresentare nello stesso ordine più linee ordine per lo stesso prodotto?

Numero

Data Ordine Prodotto

(1,1)

Descrizione

Quantità

CodiceProdotto

Linea Ordine(1,1)

(0,N)

PerIn

(0,N)Prezzo

38

OsservazioniBasi di dati


• Un identificatore esterno può coinvolgere un’entità a sua volta identificata esternamente!non si devono generare cicli di identificazione

• Le relationship non hanno identificatori

39

Generalizzazione

• Descrive un collegamento logico tra un’entità E, e una o più entità E1, E2,…, En, in cui E comprende come caso particolare E1, E2,…, En

– E, detta entità padre, è una generalizzazione di E1, E2,…, En

– E1, E2,…, En , dette entità figlie, sono una specializzazione di E

Basi di dati


E

E1 E2 En...

40

Generalizzazione: esempioBasi di dati


PersonaNome

Cognome

Codice Fiscale

Uomo DonnaSituazioneMilitare

Persona Uomo

Donna

41



SportivoNome

Cognome

Numero Tessera

Sciatore VelistaSpecialitàRuolo

SportivoSciatore

Velista

sia sciatore, sia velistané sciatore,

né velista

42

Generalizzazione: proprietà

• Ogni occorrenza di un’entità figlia è anche un’occorrenza dell’entità padre

• Ogni proprietà dell’entità padre (attributi, identificatori, relationship, altre generalizzazioni) è anche una proprietà di ogni entità figlia!proprietà nota come ereditarietà

• Un’entità può essere coinvolta in più generalizzazioni diverse

Basi di dati


43

Generalizzazione: esempio non correttoBasi di dati


PersonaNome

Cognome

Codice Fiscale

Uomo Donna

SituazioneMilitare (0,1)

Cognome

44

Generalizzazione: proprietà

• Caratteristiche ortogonali:– generalizzazione totale se ogni occorrenza

dell’entità padre è un’occorrenza di almeno una delle entità figlie, parziale altrimenti

– esclusiva se ogni occorrenza dell’entità padre è al più un’occorrenza di una delle entità figlie, sovrapposta altrimenti

Basi di dati


45



PersonaNome

Cognome

Codice Fiscale

Uomo DonnaSituazioneMilitare

Persona Uomo

Donna

(t,e)

46



SportivoSciatore

Velista

sia sciatore, sia velistané sciatore,

né velista

SportivoNome

Cognome

Numero Tessera

Sciatore VelistaSpecialitàRuolo

(p,s)

47

Sottoinsieme

• Caso particolare di generalizzazione con una sola entità figlia– la generalizzazione è sempre parziale e

esclusiva

Basi di dati


Dipendente

A Termine Data Fine Contratto

48

Documentazione di schemi E-R

• Dizionario dei dati: permette di arricchire lo schema E-R con descrizioni in linguaggio naturale di entità, relationship ed attributi

• Vincoli d’integrità sui dati: non sempre possono essere indicati esplicitamente in uno schema E-R; possono essere descritti in linguaggio naturale

• Regole di derivazione dei dati: permettono di esplicitare che un concetto dello schema può essere ottenuto (mediante inferenza o calcolo aritmetico) da altri concetti dello schema

Basi di dati


49

Fasi della progettazione di basi di datiBasi di dati


Requisiti applicazione

Progettazioneconcettuale

Progettazionelogica

Progettazionefisica

Schema concettuale

Schema logico

Schema fisico

50

Raccolta e analisi dei requisiti

Raccolta dei requisiti: individuazione di • problemi che l’applicazione dovrà risolvere • caratteristiche statiche e dinamiche

dell’applicazioneAnalisi dei requisiti: chiarimento ed organizzazione

delle specifiche

!Attività interconnesse e difficilmente standardizzabili

Basi di dati


51

Fonti di requisiti

• Utenti dell’applicazione– interviste– documentazione scritta

• Documentazione esistente– normative, regolamenti interni– moduli

• Realizzazioni preesistenti– applicazioni da sostituire o con cui è

necessario interagire

Basi di dati


52

Raccolta dei requisiti

• Gli utenti del sistema hanno un ruolo importante– gli utenti di alto livello hanno una visione più

generale, ma non conoscono i dettagli– utenti diversi possono fornire informazioni

diverse (complementari o contradditorie)

Basi di dati


53

Raccolta dei requisiti

• Regole pratiche– effettuare verifiche di comprensione e

consistenza delle informazioni raccolte– verificare anche per mezzo di esempi

(generali e relativi a casi limite)– richiedere definizioni e classificazioni– individuare gli aspetti essenziali rispetto a

quelli marginali– procedere per raffinamenti successivi

Basi di dati


54

Analisi dei requisiti

• Regole pratiche– scegliere il livello di astrazione corretto– standardizzare la struttura delle frasi– evitare frasi contorte– individuare sinonimi/omonimi e unificare i

termini– rendere esplicito il riferimento tra termini– costruire un glossario dei termini

Basi di dati


55

Progettazione concettuale

• Sono state proposte varie strategie di progetto• La più efficace è una strategia ibrida

– si individuano i concetti fondamentali (entità e relazioni importanti)

– si raffina progressivamente il progetto iniziale, aggiungendo attributi, cardinalità delle relazioni, gerarchie, altre entità e relazioni

• Se il problema è molto complesso, può essere suddiviso in sottoproblemi, risolti separatamente ed integrati in seguito

Basi di dati


56

Progettazione concettuale: criteri generali

• Se un concetto ha proprietà significative o de-scrive classi di oggetti con esistenza autonoma!entità

• Se un concetto ha struttura semplice e non possiede proprietà rilevanti!attributo (eventualmente multivalore)

• Se due o più concetti sono correlati!relationship

• Se un concetto è caso particolare di un altro!gerarchia

Basi di dati


57

Qualità di uno schema concettuale

Correttezza: uso appropriato dei costrutti del modello!verificare errori sintattici e semantici

Completezza: rappresentazione di tutti i concetti di interesse

LeggibilitàMinimalità: tutte le specifiche sono rappresentate

una volta sola nello schema!verifica e documentazione di eventuali

ridondanze

Basi di dati


58

Esempio di progettazione

Si vogliono rappresentare le informazioni relative al reparto maternità di un ospedale.

Per ogni madre si conosce il nome, l’età, il tipo di parto effettuato (cesareo o naturale), il numero di letto e di stanza, eventuali malattie. Per ogni neonato, si conosce il nome, la madre, il numero di lettino, la dieta (quantità di latte al giorno).

Inoltre si rappresentano le informazioni relative al personale: nome e numero di matricola. Il perso-nale è suddiviso in medici, ostetriche e infermie-re. I medici possono essere ginecologi o pediatri.

Basi di dati


59


Per ogni componente del personale, si conosce il turno (per ogni giorno della settimana, la fascia oraria di presenza e le stanze assegnate).

Inoltre, per i medici si conoscono i pazienti di cui si occupano, che possono anche essere indipendenti dalle stanze assegnate. Per ogni ostetrica si conoscono le mamme che ha assistito durante il parto.

Basi di dati


60


• Analisi del testo volta ad individuare i concetti più importanti!le entità principali del diagramma E-R!eventuali collegamenti tra entità

Basi di dati


61





Basi di dati


62




Basi di dati


63


• Concetti principali– paziente (mamma, neonato)– membro del personale (medico, …)– turno

Basi di dati


Turno

Paziente Personale

DiTurno

Assiste

64


• Raffinamento dei concetti – introduzione delle gerarchie– definizione degli attributi– caratterizzazione delle relazioni mediante la

cardinalità

Basi di dati


65





Basi di dati


66

Esempio di progettazioneBasi di dati


Medico Ostetrica Infermiera

Paziente

Madre Neonato

(t,e)

(t,e)

Personale

67





Basi di dati


68




Nascita

Nome

PazienteLetto

Malattia(0,N)

Madre

DataNascita

TipoParto

Neonato

Dieta

(t,e)

(t,e)

PersonaleNumStanza

(0,1)

69





Basi di dati


70




Nascita

Nome

PazienteLetto

Malattia(0,N)

Madre

DataNascita

TipoParto

Neonato

Dieta

(t,e)

(t,e)Specializz.

Personale

Matricola Nome

NumStanza

(0,1)

71




Basi di dati


72




Turno

Nascita

Nome

PazienteLetto

Malattia(0,N)

Madre

DataNascita

TipoParto

Neonato

Dieta

(t,e)

(t,e)Specializz.

Personale

Matricola Nome

OraInizio

OraFine

Data

CodT

DiTurnoNumStanza

(0,1)

73



StanzaInclude


Turno

Nascita

Nome

PazienteLetto

Malattia(0,N)

Madre

DataNascita

TipoParto

Neonato

Dieta

(t,e)

(t,e)Specializz.

In Personale

Matricola Nome

Numero

OraInizio

OraFine

Data

CodT

DiTurno

(0,1)

74




Basi di dati


75



StanzaInclude


Turno

Nascita

Nome

PazienteLetto

Malattia(0,N)

Madre

DataNascita

TipoParto

Neonato

Dieta

(t,e)

(t,e)Specializz.

In

Assiste Cura

Personale

Matricola Nome

Numero

OraInizio

OraFine

Data

CodT

DiTurno

(0,1)

76



StanzaInclude


Turno

Nascita

Nome

PazienteLetto

Malattia(0,N)

Madre

DataNascita

TipoParto

Neonato

Dieta

(0,N) (1,1)

(t,e)

(t,e)Specializz.

(0,N)(0,N)

(0,1)

(0,N)

(1,1)

(0,N)

In

Assiste Cura

Personale

Matricola Nome

Numero

OraInizio

OraFine

Data

CodT

DiTurno(0,N)

(1,N)

(1,N) (1,N)

(0,1)

Date post:	25-Feb-2019
Category:	Documents
Upload:	trinhtruc
View:	247 times
Download:	2 times

Basi di dati Progettazione di basi ... - Politecnico di...

Documents