PROGETTAZIONE DI BASI DI DATI: METODOLOGIE E MODELLI

Transcript

PROGETTAZIONE DI BASI DI DATI:
METODOLOGIE E MODELLI
Basi di dati | Modello E-R
5{0
Progettazione di basi di dati
e una delle attivita del processo di sviluppo dei sistemi
informatici
va quindi inquadrata in un contesto piu generale:
il ciclo di vita dei sistemi informatici:
{ Insieme e sequenzializzazione delle attivita svolte da analisti,
progettisti, utenti, nello sviluppo e nell'utilizzazione dei
sistemi informatici.
{ Si tratta di una attivita iterativa (percio \ciclo")
5{1
Fasi del ciclo di vita
una possibile articolazione
Attivita preliminari
Analisi
Progettazione
Realizzazione
Installazione, transizione, gestione, manutenzione
Al termine (e non solo) di ciascuna fase, deve essere svolta una
attivita di verica (validazione) della qualita dei prodotti.
Anche in caso di adamento all'esterno delle attivita di sviluppo,
buona parte delle fasi del ciclo di vita rimangono di interesse.
5{2
Analisi
Attivita volta alla individuazione dei requisiti dell'applicazione, in
tutti i dettagli signicativi. Le informazioni vengono acquisite
attraverso
interazione con gli utenti (a diversi livelli)
studio delle realizzazioni esistenti
studio della normativa
5{3
Progettazione
Attivita volta alla individuazione delle modalita secondo cui
l'applicazione rispondera ai requisiti. In questa fase vengono
deniti
i dati di ingresso e uscita e la loro organizzazione
l'architettura hardware e software
la organizzazione dei moduli software
5{4
Analisi e progettazione
Analisi denizione di un problema;
\che cosa"
esame delle procedure aziendali
scopo dell'analisi e la modellazione, la costruzione di un
modello preciso, ma astratto rispetto alle realizzazioni
Progettazione risoluzione di un problema;
\come"
automatizzazione delle procedure
5{5
prodotti fondamentali della fase di analisi sono le
rappresentazioni del sistema secondo opportuni formalismi
poiche in un sistema abbiamo processi (funzioni) e dati,
l'analisi deve riguardare entrambi gli aspetti
{ analisi dei dati
{ analisi delle funzioni
l'analisi delle funzioni puo apparire piu \naturale" perche fa
riferimento alle attivita che vengono svolte
l'analisi dei dati e pero essenziale per studiare i ussi
informativi (soprattutto interprocesso) ed e per certi aspetti
piu semplice perche i dati sono piu stabili e piu facilmente
analizzabili in dettaglio
5{6
lo studio di metodologie complete per lo sviluppo di sistemi
informativi (e informatici) e oltre gli obiettivi di un corso di
basi di dati
il ruolo centrale dei dati (e quindi delle basi di dati) giustica
uno studio autonomo della progettazione di basi di dati
5{7
Metodologia
articolazione delle attivita in fasi, con input e prodotti
strategie per i vari passi e criteri di scelta
modelli per la rappresentazione dei prodotti delle varie fasi
Proprieta:
generalita (rispetto alle applicazioni e ai sistemi)
qualita del prodotto (correttezza, completezza, ecienza, ...)
facilita d'uso
5{8
Fasi del processo
di progettazione di basi di dati
Analisi dei requisiti e progettazione concettuale:
raccolta ed esame delle speciche;
costruzione di uno schema concettuale (descrizione dei dati
in un modello astratto) e di un glossario
Progettazione logica: denizione dello schema logico della base
di dati (descrizione utilizzata dagli utenti e dai programmi)
Progettazione sica: denizione dei parametri realizzativi di
livello piu basso
La progettazione di basi di dati segue l'articolazione in livelli dei
sistemi, aggiungendo anzi un livello piu astratto
5{9
il prodotto fondamentale della prima fase (analisi e
progettazione concettuale) e lo schema concettuale (con la
documentazione associata), cioe uno schema dei dati secondo
un modello concettuale
i modelli concettuali vengono spesso utilizzati n dall'inizio
dell'ativita di analisi e sono molto utili anche per la
comunicazione fra specialisti e non specialisti (analisti e
committenti)
vediamo in dettaglio un modello concettuale
5{10
Modello dei dati
costrutti utilizzati per organizzare i dati di interesse
componente fondamentale: meccanismi di strutturazione (o
costruttori di tipo)
ad esempio, il modello relazionale prevede il costruttore
relazione, che permette di denire insiemi di record omogenei
5{11
Le relazioni possono essere rappresentate per mezzo di tabelle
docenza
Corso
Docente
Basi di dati Rossi
Impianti
Neri
Linguaggi Verdi
:::
:::
manifesto CdL Materia Anno
II Basi di dati 5
II
Impianti
5
II Linguaggi
4
IE Linguaggi
5
IE Impianti
5
:::
:::
:::
5{12
In ogni base di dati esistono:
lo schema, sostanzialmente invariante nel tempo, che ne
descrive la struttura (aspetto intensionale);
nell'esempio, le intestazioni delle tabelle
l'istanza, costituita dai valori attuali, che possono cambiare
molto e molto rapidamente (aspetto estensionale);
5{13
Due tipi (principali) di modelli:
modelli logici: utilizzati nei DBMS esistenti per
l'organizzazione dei dati; ad essi fanno riferimento i
programmi; sono indipendenti dalle strutture siche;
modelli concettuali: peremettono di rappresentare i dati in
modo indipendente da ogni sistema, cercando di descrivere i
concetti del mondo reale; sono utilizzati nelle fasi preliminari di
progettazione;
il piu noto e il modello Entity-Relationship
i modelli concettuali vengono spesso utilizzati n dall'inizio
dell'attivita di analisi e sono molto utili anche per la
comunicazione fra specialisti e non specialisti (analisti e
committenti)
i modelli concettuali sono stati introdotti per ovviare al
limitato potere espressivo e alla \rigidita" dei modelli logici
5{14
5{15
in un modello concettuale (come in ogni modello dei dati),
i dati possono essere descritti a due livelli:
estensionale, relativo ai dati veri e propri, fortemente variabile
nel tempo
intensionale, o dello schema relativo alla struttura dei dati,
molto piu stabile
in sede di progettazione, interessa (solo) lo schema, in quanto
astrazione del livello estensionale
5{16
lo schema concettuale e una rappresentazione delle classi dei
dati di interesse e delle loro correlazioni, in modo indipendente
da ogni aspetto realizzativo (poi, la realizzazione sara basata
sullo schema concettuale, ma non viceversa)
si utilizzano rappresentazioni grache degli schemi concettuali
(che hanno un signicato ben preciso, non solo \scatole e
frecce")
5{17
Il modello E-R (Entity-Relationship)
il piu diuso modello concettuale
attenzione: ne esistono molte versioni, (piu o meno) diverse
l'una dall'altra
5{18
I costrutti del modello E-R
entita
relationship
attributi
identicatori
generalizzazioni e sottoinsiemi
5{19
entita: classe di oggetti (fatti, persone) del frammento di interesse
del mondo reale, con proprieta omogenee e con esistenza
\autonoma"; es. persone, citta, aziende, fatture, ordini
relationship: legame logico fra due o piu entita, di interesse per
l'applicazione; classe di fatti di interesse
5{20
entita: la classe di oggetti omogenei (e il loro tipo)
occorrenza (o istanza) di entita: ciascun elemento della classe
nello schema concettuale rappresentiamo le entita, non le
singole istanze (\astrazione")
5{21
ogni entita ha un nome che la identica univocamente nello
schema
{ nomi espressivi
{ opportune convenzioni (ad esempio, sempre singolare)
5{22
Entita: rappresentazione graca
Impiegato
Citta
Regione
Azienda
5{23
relationship legame logico fra due o piu entita, di interesse per
l'applicazione; classe di fatti di interesse
spesso non tradotto per evitare la confusione con relazione
(traduzione di relation)
anche tradotto con correlazione o associazione
5{24
occorrenza (o istanza) di relationship:
n-upla (coppia, terna, ...) di istanze di entita,
una per ciascuna entita coinvolta
relationship: insieme di n-uple omogenee per
tipo (entita di provenienza)
signicato (rispetto all'applicazione)
5{25
Relationship:
rappresentazione graca
Studente
HHHH
HH Esame HH
HHH H
Corso
Persona
HHHH
HH Residenza HH
HHH H
Citta
5{26
due entita possono essere coinvolte in piu relationship
HHHH
HH Nascita HH
HHH H
Persona
HHH
HH ResidenzaHHH
HHH H
Citta
5{27
un dettaglio formale:
le istanze di una relationship formano un insieme:
non ci possono essere elementi ripetuti
si tratta di una relazione nel senso matematico del termine:
(sottoinsieme del prodotto cartesiano degli insiemi di istanze
coinvolte)
Paziente
HHH
H
HHH Visita HH
HHH
Medico
?
5{28
le relationship possono coinvolgere piu di due entita
Dipartimento
HHHH
H
HHH FornituraHH
HHH H
Prodotto
Venditore
A fornisce stampanti al
B
\
fotocopiatrici \
A
\
calcolatori \
C
\
calcolatori \
Dip
\
\
\
Personale
Personale
Ricerca
Personale
5{29
una relationship puo coinvolgere \due volte" la stessa entita
(relationship ricorsiva)
puo essere necessario distinguere \ruoli"
H
HHHH
HHConoscenzaH
HHH H
HH
HHH Successore
Predecessore
H
HHSuccessione
H
HH H
Sovrano
Persona
5{30
possono esistere relationship ternarie ricorsive
Supercie
H
Peggiore HHHHHMigliore
HHHConfronto
HHH
Migliore
Peggiore Supercie
Sanchez Navratilova
Terra
Navratilova Sanchez
Erba
Graf
Sanchez
Erba
Tennista
5{31
attributo: proprieta elementare di un'entita o una relationship, di
interesse ai ni dell'applicazione
un attributo associa un valore a ciascuna occorrenza dell'entita
(o relationship) su cui e denito
Voto
e
Matricola ee
Nome
Studente
HHHH
HH Esame HHH
HHH
HH
Codice
Denominazione
eProfessore
e
Corso
e
5{32
Uno schema E-R
Codice
DIREZIONE
Cognome
Stipendio
Telefono
IMPIEGATO
AFFERENZA
Nome
Età
Data afferenza
PARTECIPAZIONE
Nome
Budget
DIPARTIMENTO
COM POSIZIONE
Data inizio
PROGETTO
Città
SEDE
Numero civico
Indirizzo
Data consegna
Via
CAP
5{33
Altri costrutti e dettagli del modello:
cardinalita delle relationship
identicatori
gerarchie
5{34
Cardinalita delle relationship
permettono di specicare il numero minimo e massimo di
occorrenze della relationship cui ciascuna occorrenza di una
entita deve/puo partecipare
per semplicita usiamo:
{ 0 e 1 per la cardinalita minima:
0 = \e opzionale"; 1 = \e obbligatoria"
{ 1 e \N" per la massima:
\N" non pone alcun limite
con riferimento alle cardinalita massime, abbiamo relationship:
uno a uno, uno a molti, molti a molti
5{35
le cardinalita vanno specicate per ciascuna entita che
partecipa alla relationship
HHH
HHH (p,P)
H
HHH
R
HHH H
(m, M)
E1
E2
ogni occorrenza di E1 partecipa ad almeno m e al piu M
occorrenze di R
ogni occorrenza di E2 partecipa ad almeno p e al piu P
occorrenze di R
5{36
Relationship \molti a molti"
Persona
H
(0,N) HHHHH(0,N)
HHHAmicizia H
HH
Animale
H
(0,N) HHHHH(1,N)
Alpinista
Montagna
HHHScalata
H
HH
Macchinista
HHH
HHH(1,N)
HHAbilitazione
HH
HH
(1,N)
Locomotore
5{37
Relationship \uno a molti"
H
Persona
(0,1) HHHHH(0,N)
HHHImpiego Societa
Cinema
(0,1)
HHH
HHH(1,N)
HHHUbicazione
HHH
Localita
Comune
(1,1)
HHH
HHH(1,N)
HHHUbicazione
HHH
Provincia
HHH
5{38
Relationship \uno a uno"
Professore
HHH
H (0,1)
HHHTitolarita HH
HHH
(0,1)
Cattedra
H
HHH (0,1)
Professore (1,1)HTitolarit
aHH
Cattedra
HHH
di ruolo
H H
H
HHH (1,1) Cattedra
Professore (1,1)HTitolarit
aHH
HH
coperta
di ruolo
HH H
5{39
Due avvertenze:
attenzione al \verso" nelle relationship uno a molti
le relationship obbligatorie-obbligatorie spesso hanno poco
senso
5{40
Cardinalita di attributi
Possono essere usate per:
indicare opzionalita (molto utili, corrispondono ai valori nulli)
per indicare attributi multivalore (non sempre utilizzati)
(0,N)
PERSONA
Nome
(0,1)
Targa automobile
Numero patente
5{41
Identicatore di una entita
\strumento" per l'identicazione univoca delle occorrenze
e costituito da
{ attributi (uno o piu) dell'entita:
identicatore interno
{ (da attributi e) entita esterne (attraverso relationship):
identicatore esterno
ogni entita deve avere (almeno) un identicatore
5{42
Identicatori interni
Data di nascita
Targa
AUTOMOBILE
Modello
Colore
Cognome
PERSONA
Nome
Indirizzo
5{43
Identicatore esterno
Matricola
Nome
(1,1)
Anno Iscrizione
STUDENTE
Cognome
(1,N)
ISCRIZIONE
UNIVERSITÀ
Città
Indirizzo
5{44
perche non parliamo degli identicatori delle relationship?
5{45
Uno schema con attributi e identicatori
(0,1)
Codice
DIREZIONE
(1,1)
Cognome
Stipendio
IMPIEGATO
AFFERENZA
(0,N)
Età
Data afferenza
PARTECIPAZIONE
Nome
Budget
(0,1)
(1,N)
PROGETTO
(1,N)
(1,N)
(0,1)
Telefono
DIPARTIMENTO
(1,1)
Nome
COM POSIZIONE
Data inizio
(1,N)
SEDE
Città
Numero civico
Indirizzo
Data consegna
Via
CAP
5{46
Generalizzazione
uomo e donna sono i due casi particolari di persona
dipendente e un concetto che generalizza i concetti di
funzionario, impiegato, dirigente
5{47
Generalizzazione
mette in relazione una o piu entita E1, E2, , E con un'altra
entita E, di esse piu generale, nel senso che le comprende
come caso particolare
:::
n
ogni proprieta di E e signicativa per E1, E2,
ogni occorrenza di E e occorrenza anche di E
ogni occorrenza di E e occorrenza di al piu una E
:::
,E
i
n
i
5{48
E1, E2, , E sono specializzazioni (sottotipi,
sottoinsiemi) di E
:::
n
le proprieta (attributi, relationship, altre generalizzazioni) di E
vengono ereditate da E1, E2, , E (e non rappresentate
esplicitamente)
:::
n
5{49
Dipendente
,,@@
Impiegato
Dirigente
Funzionario
Citta
5{50
HHHH
H Nascita H
HHH H
Dipartimento d
Professore
Persona
,@
Cognome
dNome
d
Studente
ogni professore e una persona
ogni studente e una persona
nessun professore e studente e viceversa
esistono persone che non sono ne studenti ne professori
ogni studente ha nome, cognome e citta di nascita (ereditati)
5{51
una generalizzazione e completa se ogni occorrenza del
\genitore" e occorrenza di uno dei gli
Persona
,,@@
Codice Fiscale
Cognome
eNome
e
e
Donna
Uomo
e
Pos Militare
5{52
nel caso di generalizzazione con un solo glio si parla di
sottoinsieme (o gerarchia is-a)
ovviamente, non si puo avere completezza
Persona
,,@@
Studente
5{53
possono esistere gerarchie a piu livelli e multiple gerarchie allo
stesso livello
un'entita puo essere inclusa in piu gerarchie, come genitore
e/o come glio
alcune congurazioni non hanno senso
il genitore di una gerarchia completa puo non avere
identicatore (purche ce l'abbiano tutte le entita glie)
5{54
Codice Fiscale
PERSONA
Cognome
Età
Stipendio
UOMO
DONNA
IMPIEGATO
Matricola
STUDENTE
Situazione militare
SEGRETARIO
Orario
DIRETTORE
PROGETTISTA
RESPONSABILE
DI PROGETTO
5{55
Documentazione associata
dizionario dei dati (entita, relationship, attributi, gerarchie)
vincoli non esprimibili
Entita
Impiegato
Descrizione
Impiegato che lavora
nella azienda
Progetto
Progetti ai quali lavorano gli impiegati della
azienda
Dipartimento Dipartimenti delle sedi
della azienda
Sede
Sede della azienda in
una certa citta
5{56
Attributi
Identicatore
Telefono, Nome
Nome, Sede
Citta, Indirizzo
Citta
Codice, Cognome, Codice
Stipendio, Eta
Nome, Budget,
Nome
Data consegna
5{57
Relationship
Direzione
Aerenza
Partecipazione
Composizione
Descrizione
Associa un dipartimento
al suo direttore
Associa un impiegato al suo
dipartimento
Associa agli impiegati
i progetti sui quali lavorano
Associa una sede
ai dipartimenti
di cui e composta
Entita Coinvolte
Attributi
Impiegato,
Dipartimento
Impiegato,
Data
Dipartimento
aerenza
Impiegato, Progetto Data inizio
Dipartimento, Sede
5{58
Vincoli di integrita sui dati
(1) Un impiegato puo essere direttore solo del dipartimento
a cui aerisce.
(2) Un impiegato non puo avere uno stipendio maggiore del
direttore del dipartimento al quale aerisce.
(3) Un impiegato non puo partecipare a un progetto se non
aerisce a nessun dipartimento.
(4) Il budget di un progetto deve essere superiore alla somma
degli stipendi degli impiegati che vi partecipano.
5{59

PROGETTAZIONE DI BASI DI DATI: METODOLOGIE E MODELLI

Transcript

Documenti analoghi

Polycolor Gesso

Esercitazioni 3

Seminario > come finanziare il mio documentario

Ipé Lapacho - Bruno Parquet

Polycolor Film Polycolor Body

Lo sguardo degli autori - Terra di Tutti Film Festival

Emilia-Romagna Sogno Usa per 7/10 imprenditori Bologna

in Mostra

Protocolli ed architetture di rete

F06_MAIMERI polycolor 3D cartella colori

Sex and the city