IL MODELLO ENTITÀ-RELAZIONE

Transcript

1 IL MODELLO ENTITÀ-RELAZIONE PROGETTAZIONE CONCETTUALE DI UNA BASE DI DATI FASI DELLA PROGETTAZIONE DI UNA BASE DI DATI

2 Introduzione alla progettazione delle basi di dati 1. Analisi dei requisiti! Dati, alicazioni, operazioni più frequenti! Analisi informale con gli utenti 2. Progettazione concettuale! Descrizione ad alto livello dei dati da memorizzare! Uso del modello ER! produzione di uno schema di base di dati raresentato graficamente da un diagramma Giorgio Giacinto 2010 Basi di Dati 3 Introduzione alla progettazione delle basi di dati 3. Progettazione logica! Scelta di un DBMS per l implementazione della base di dati.! Tradurre del diagramma ER nello schema logico del DBMS (noi considereremo il relazionale) 4. Raffinamento dello schema (normalizzazione)! controllo dello schema relazionale per trovare ridondanze e relative anomalie. 5. Progettazione fisica e ulteriore raffinamento dello schema! si considerano il carico di lavoro e le prestazioni del sistema per effettuare ulteriori modifiche sullo schema. Giorgio Giacinto 2010 Basi di Dati 4

3 Introduzione alla progettazione delle basi di dati 6. Progettazione delle alicazioni e della sicurezza Ingegneria del software Limiti d uso della base di dati da parte di diversi grui di utenti In tutti i momenti della progettazione si deve prevedere un feedback per le fasi precedenti Giorgio Giacinto 2010 Basi di Dati 5 IL MODELLO ENTITÀ-RELAZIONE (ER)

4 Introduzione alla progettazione delle basi di dati! Progettazione concettuale (in questa fase si usa il modello ER)! Quali sono le entità e le relazioni dell organizzazione?! Quali informazioni su queste entità e relazioni dovrebbero essere memorizzate nella base di dati?! Quali sono i vincoli di integrità o le regole aziendali (business rules) in vigore? Giorgio Giacinto 2010 Basi di Dati 7 Basi del modello ER Entità: oggetto del mondo reale distinguibile da altri oggetti! Una entità è descritta (nel DB) usando un insieme di attributi! Insieme di entità: una collezione di entità simili (es., tutti gli impiegati)! Tutte le entità in un insieme di entità hanno lo stesso insieme di attributi Ciascun insieme di entità ha una chiave Ciascun attributo ha un dominio Giorgio Giacinto 2010 Basi di Dati 8

5 Basi del modello ER (segue) Relazione: associazione tra 2 o più entità. Ad esempio, Bianchi lavora nel reparto Farmacia! Insieme di relazioni: collezione di relazioni simili! Ciascuna relazione è denotata da una n-tupla {(e 1,,e n ) e 1! E 1,,e n! En} che correla n insiemi di entità E 1... E n! Le relazioni possono anche avere attributi descrittivi! Lo stesso insieme di entità può partecipare a diversi insiemi di relazioni, o in ruoli differenti all interno dello stesso insieme Giorgio Giacinto 2010 Basi di Dati 9 Basi del modello ER (segue) dal r rid budget Lavora_In Reparti Località subordinato supervisore Indirizzo capienza Dipende_da Giorgio Giacinto 2010 Basi di Dati 10

6 Relazioni! Una relazione è univocamente identificata dalle entità che vi partecipano! Lavora_in (binaria) è identificata da e rid! Lavora_in (ternaria) è identificata da, rid e Indirizzo Giorgio Giacinto 2010 Basi di Dati 11 Vincoli di chiave! Lavora_In dal rid r budget! un impiegato può lavorare in molti reparti! un reparto può Dirige Reparti avere molti impiegati! Di contro, ciascun Reparto ha al più un direttore! Un reparto compare al più in una relazione di Dirige 1-a-1 1-a-Molti Molti-a-1 Molti-a-molti Giorgio Giacinto 2010 Basi di Dati 12

7 Vincoli di partecipazione! C è un direttore per ogni reparto?! Se sì, questo è un vincolo di partecipazione: la partecipazione di Reparti in Dirige viene detta totale (piuttosto che parziale)! Ogni valore rid della tabella Reparti deve aarire in almeno una riga della tabella Dirige! Il vincolo di chiave impone che il valore di rid compaia in una sola riga di Dirige Giorgio Giacinto 2010 Basi di Dati 13 Vincoli di partecipazione dal rid r budget Dirige Reparti Lavora_In dal Giorgio Giacinto 2010 Basi di Dati 14

8 Vincoli di cardinalità! Vincoli di chiave e di partecipazione considerati insieme sono anche detti vincoli di cardinalità (essi definiscono una cardinalità massima e minima, rispettivamente)! I vincoli di cardinalità definiscono il minimo (v. di partecipazione) e il massimo (v. di chiave) numero di istanze della relazioni cui partecipa una istanza dell entità! Es. Persona (1,1) (1,N) Vive Città Giorgio Giacinto 2010 Basi di Dati 15 Entità deboli! Una entità debole può essere identificata univocamente solo considerando la chiave primaria di un altra entità (proprietario)! L insieme di entità proprietarie e l insieme di entità deboli devono partecipare in un insieme di relazioni uno-a-molti (1 proprietario, molte entità deboli)! L insieme di entità deboli deve avere partecipazione totale in questo insieme di relazioni identificanti costo p età Polizza Familiari Giorgio Giacinto 2010 Basi di Dati 16

9 Gerarchie ISA Paghe_orarie Ore_lavorate ISA idcontratto Imp_A_Ore Imp_A_Contratto Se dichiariamo A ISA B, ogni entità A è considerata anche come entità B le risposte alle interrogazioni dovrebbero riflettere questo fatto è specializzato in sottoclassi _A_Ore e _A_Contratto sono generalizzati in Come in C++, o altri linguaggi di programmazione, gli attributi vengono ereditati. Giorgio Giacinto 2010 Basi di Dati 17 Gerarchie ISA Vincoli di disgiunzione può Joe essere un Imp_A_Ore e anche una entità di Imp_A_Contratto? (Permesso/non permesso) default: non permesso. Altrimenti usiamo un asserzione Vincoli di copertura deve, ogni entità di, essere anche una entità di Imp_A_Ore o una entità di Imp_A_Contratto? (Sì/No - Copertura totale o parziale) default: copertura parziale. Altrimenti usiamo un asserzione Motivi per usare ISA Aggiungere attributi descrittivi specifici a una sottoclasse Identificare le entità che partecipano a una relazione Giorgio Giacinto 2010 Basi di Dati 18

10 PROGETTAZIONE CONCETTUALE Progettazione concettuale usando il modello ER! Scelte di progetto! Un concetto dovrebbe essere modellato come una entità o come un attributo?! Un concetto dovrebbe essere modellato come una entità o come una relazione?! Identificare le relazioni: binarie o ternarie?! Raresentazione di vincoli nel modello ER! molta della semantica dei dati può (e dovrebbe) essere catturata! però alcuni vincoli non possono essere catturati dai diagrammi ER Giorgio Giacinto 2010 Basi di Dati 20

11 Progettazione concettuale usando il modello ER! Necessità di ulteriori raffinamenti dello schema! lo schema relazionale ottenuto dai diagrammi ER è un buon punto di partenza. Ma il progetto ER è soggettivo e non può esprimere certi vincoli Quindi lo schema relazionale può aver bisogno di raffinamenti Giorgio Giacinto 2010 Basi di Dati 21 Entità o Attributi?! Indirizzo dovrebbe essere un attributo di o una entità (connessa a da una relazione)?! Dipende dall uso che vogliamo fare delle informazioni sull indirizzo, e dalla semantica dei dati! se abbiamo diversi indirizzi per impiegati, indirizzo deve essere una entità (poiché gli attributi non possono assumere più valori)! se la struttura (città, via, etc) è importante, ad esempio vogliamo trovare gli impiegati in una data città, indirizzo deve essere modellato come una entità (poiché i valori degli attributi sono atomici) Giorgio Giacinto 2010 Basi di Dati 22

12 Entità o Attributi? (segue)! Lavora_In2 non permette a un impiegato di lavorare in un reparto per due o più periodi! Simile al problema della registrazione di indirizzi multipli per un impiegato: vogliamo registrare diversi valori degli attributi descrittivi per ciascuna istanza della relazione Giorgio Giacinto 2010 Basi di Dati 23 dal dal al Lavora_In2 Lavora_In3 Durata rid rid r Reparti al budget r budget Reparti Entità o Relazioni?! Il diagramma ER a lato è corretto nel caso in cui un direttore ha un budget discrezionale separato per ciascun reparto! Che succede se un direttore ha un budget discrezionale che copre tutti i reparti da lui diretti?! Ridondanza di rbudget, che è memorizzato per ciascun reparto gestito dal direttore! Ingannevole: suggerisce che rbudget sia legato al reparto ISA parziale dal rbudget r rid budget Gestisce2 Reparti dal r rid budget Gestisce3 Reparti rbudget Direttore Giorgio Giacinto 2010 Basi di Dati 24

13 Relazioni binarie o relazioni ternarie? p età Copre Familiari Polizze! Vincoli aggiuntivi polizzaid costo! Una polizza non può essere posseduta congiuntamente da due o più impiegati! Ogni polizza deve essere posseduta da qualche impiegato! Familiari è un insieme di entità deboli! Identificata da p e polizzaid! Un vincolo di chiave su Polizze significherebbe che una polizza può coprire solo un familiare! Giorgio Giacinto 2010 Basi di Dati 25 Relazioni binarie o relazioni ternarie? p età Familiari Intestatario Beneficiario Polizze polizzaid costo Giorgio Giacinto 2010 Basi di Dati 26

14 Relazioni binarie o relazioni ternarie? (segue)! L esempio precedente illustra un caso in cui due relazioni binarie sono migliori di una relazione ternaria! Un esempio nell altra direzione: una relazione ternaria Contratti mette in relazione gli insiemi Pezzi, Reparti e Fornitori, e ha l attributo descrittivo quantità. Nessuna combinazione di relazioni binarie è un sostituto adeguato! F può fornire P, D ha bisogno di P, e D tratta con F non implicano che D sia d accordo sul comprare P da F! Come registreremo quantità? Giorgio Giacinto 2010 Basi di Dati 27 Vincoli oltre il modello ER! Dipendenze funzionali! ad esempio, un reparto può ordinare due pezzi distinti dallo stesso fornitore! Non si può esprimere in termini della relazione ternaria Contratti! La normalizzazione raffina il progetto ER tenendo in considerazione le DF! Dipendenze di inclusione! caso speciale: chiavi esterne (si possono esprimere nel modello ER)! ad esempio, almeno una persona deve dipendere da ciascun direttore. Chiave esterna? Esprimibile nel modello ER? Giorgio Giacinto 2010 Basi di Dati 28

15 Vincoli oltre il modello ER! Vincoli generali! Ad esempio, budget discrezionale del direttore minore del 10% dei budget combinati di tutti i reparti che gestisce Giorgio Giacinto 2010 Basi di Dati 29 Riassunto della progettazione concettuale! La progettazione concettuale segue l analisi dei requisiti! Porta a una descrizione ad alto livello dei dati che devono essere memorizzati! Il modello ER è molto usato per la progettazione concettuale! I costrutti sono espressivi, vicini al modo in cui la gente pensa alle alicazioni! Costrutti di base: entità, relazioni e attributi (di entità e relazioni)! Alcuni costrutti addizionali: entità deboli, gerarchie ISA e aggregazione! Nota: ci sono molte varianti del modello ER Giorgio Giacinto 2010 Basi di Dati 30

16 Riassunto della progettazione concettuale (segue)! Nel modello ER si possono esprimere diversi tipi di vincoli di integrità! vincoli di chiave! vincoli di partecipazione e vincoli di sovraosizione/copertura per le gerarchie ISA.! Nella definizione di insieme di relazioni sono anche impliciti alcuni vincoli di chiave esterna.! Alcuni di questi vincoli possono essere espressi in SQL solo se usiamo vincoli CHECK o asserzioni generali. Giorgio Giacinto 2010 Basi di Dati 31 Riassunto della progettazione concettuale (segue)! Alcuni vincoli (in particolare le dipendenze funzionali) non possono essere espressi nel modello ER! I vincoli giocano un ruolo importante nel determinare il miglior progetto di base di dati per una organizzazione. Giorgio Giacinto 2010 Basi di Dati 32

17 Riassunto della progettazione concettuale (segue)! Il progetto ER è soggettivo. Ci sono spesso molti modi per modellare un dato scenario! Analizzare le alternative può essere complicato, specialmente per una grande azienda. Scelte comuni includono! Entità o Attributo! Entità o Relazione! Relazione binaria o N-aria! Uso delle gerarchie ISA! Uso dell aggregazione Giorgio Giacinto 2010 Basi di Dati 33 Riassunto della progettazione concettuale (segue)! Garantire un buon progetto della base di dati! lo schema relazionale risultante dovrebbe essere analizzato e ulteriormente raffinato.! Le informazioni delle DF e le tecniche di normalizzazione sono particolarmente utili. Giorgio Giacinto 2010 Basi di Dati 34

18 METODOLOGIE DI PROGETTO Metodologie di progetto! Le metodologie per la progettazione concettuale sono basate su! raffinamento incrementale dello schema! astrazione come meccanismo di raffinamento! controllo della qualità dello schema concettuale! decomposizione in sottoschemi! analisi integrata di dati e funzioni! Le principali metodologie sono! top-down! bottom-up! mista Giorgio Giacinto 2010 Basi di Dati 36

19 Top-down! Implementa una serie di trasformazioni dello schema iniziando con concetti molto astratti per andare verso concetti più concreti e dettagliati! Il primo schema contiene (in una raresentazione molto astratta) tutto il contenuto di informazione della realtà da raresentare! Meccanismo di trasformazione: raffinamento! Es. Persona Studente Giorgio Giacinto 2010 Basi di Dati 37 Bottom-up! Parte dai requisiti dettagliati, raggruandoli in concetti più astratti! Meccanismo di trasformazione: astrazione! Es. Problemi: conflitti tra le definizioni dei concetti, ridondanze, necessità di ristrutturazione (ma più naturale) Giorgio Giacinto 2010 Basi di Dati 38

20 Mista! Decomposizione controllata dei requisiti! Struttura globale dello schema! Generazione bottom-up dei sottoschemi! Integrazione dei sottoschemi guidata dalla struttura Giorgio Giacinto 2010 Basi di Dati 39 Qualità dello schema concettuale! Correttezza! lo schema raresenta correttamente (sintatticamente e semanticamente) i requisiti iniziali! Completezza! lo schema raresenta tutti i requisiti! Minimalità! lo schema raresenta solo i requisiti e ogni loro aspetto aare solo una volta! Leggibilità! lo schema è facile da interpretare ed esprime i requisiti in modo naturale Giorgio Giacinto 2010 Basi di Dati 40

21 Qualità dello schema concettuale (segue)! Modificabilità! lo schema può essere facilmente modificato se i requisiti cambiano! Auto-documentabilità! lo schema non ha bisogno di materiale aggiuntivo esterno Giorgio Giacinto 2010 Basi di Dati 41 Esempio di top-down Requisiti! Vogliamo raresentare le informazioni sugli impiegati. In particolare, i dati si riferiscono a! persone, con, data di nascita e sesso;! Località dove le persone sono nate e vivono attualmente.! Ci sono due tipi di località: stati degli USA e paesi stranieri. Nel primo caso, vogliamo raresentare anche l ammontare della popolazione dello stato, mentre nel secondo caso vogliamo raresentare la capitale del paese! impiegati con il loro salario! direttori con associato il del reparto che dirigono Giorgio Giacinto 2010 Basi di Dati 42

22 Primi raffinamenti Dati personali Dati personali Dati delle persone Dati delle località Dati delle persone Riferiti a Dati delle località Giorgio Giacinto 2010 Basi di Dati 43 Ulteriore raffinamento Dati delle persone Persona Impiegato Direttore Dati delle località Località Stato Paese Riferiti a Nato Vive Giorgio Giacinto 2010 Basi di Dati 44

23 Raffinamento finale Persona sesso Persona Data di nascita Impiegato salario Impiegato Reparto Direttore Direttore popolazione Stato Stato capitale Paese Paese Giorgio Giacinto 2010 Basi di Dati 45 Schema finale (1,1) Nato (1,N) (1,1) Vive (1,N) sesso Data di nascita Persona reparto Località capitale Impiegato direttore stato paese salario popolazione Giorgio Giacinto 2010 Basi di Dati 46

24 Bottom-up Scelta degli attributi! Nome dell impiegato! Data di nascita dell impiegato! Sesso dell impiegato! Salario dell impiegato! Nome del direttore! Data di nascita del direttore! Reparto del direttore! Sesso del direttore! Nome del paese! Capitale del paese! Nome dello stato! Popolazione dello stato Giorgio Giacinto 2010 Basi di Dati 47 Scelta delle entità sesso Data di nascita popolazione Impiegato salario Paese sesso Data di nascita capitale Direttore reparto Stato Giorgio Giacinto 2010 Basi di Dati 48

25 ISA Persona sesso Impiegato Data di nascita salario sesso Data di nascita Direttore reparto Località capitale Stato popolazione Paese Giorgio Giacinto 2010 Basi di Dati 49 Ristrutturazione degli attributi sesso Persona Data di nascita reparto Località capitale Impiegato Direttore stato Paese salario popolazione Giorgio Giacinto 2010 Basi di Dati 50

26 Relazioni (1,1) Nato (1,N) (1,1) Vive (1,N) sesso Persona Data di nascita reparto località capitale Impiegato Direttore stato paese salario popolazione Giorgio Giacinto 2010 Basi di Dati 51