Università degli Studi di Torino Facoltà di Economia

Transcript

1 Università degli Studi di Torino Facoltà di Economia Corso di Information and Communication Technology II Progettazione di basi di dati: introduzione, il modello E-R, traduzione da E-R a relazionale -- a.a Diego Magro 1 2 Introduzione Introduzione Finora abbiamo trattato: i concetti di base di dati, di DBMS e di modello dei dati il modello relazionale dei dati (relazioni, tabelle, schemi, istanze, vincoli di integrità) l algebra relazionale SQL (soprattutto la parte reltiva alle interrogazioni) MA quando una base di dati deve essere creata ex-novo, il primo passo NON è quello di sedersi davanti ad un computer e iniziare a scrivere codice SQL!!! La creazione di una base di dati è un processo complesso che richiede una metodologia La creazione di una base di dati richiede un attenta PROGETTAZIONE! Progettazione: defininizione della struttura, delle caratteristiche e del contenuto di una base di dati La progettazione della base di dati è una delle parti del processo di sviluppo di un sistema informativo (di cui la base di dati è una delle componenti) La scrittura del codice è solo un passo di questo processo! 3 4

2 Introduzione: ciclo di vita di un sistema informativo Introduzione: ciclo di vita di un sistema informativo Il ciclo di vita di un sistema informativo si compone delle seguenti attività (che non necessariamente sono eseguite in stretta sequenza: il risultato di qualche attività può richiedere di rivedere scelte fatte ai passi precedenti): 1. Studio di fattibilità: esamina diverse alternative, ne definisce costi, vantaggi, svantaggi, stabilisce priorità nella realizzazione delle vario componenti 2. Raccolta e analisi dei requisiti: individua caratteristiche e funzionalità che il sistema dovrà avere; stabilisce requisiti sw e hw. Forte interazione con i futuri utenti 3. Progettazione a) dei dati: individua struttura e organizzazione dei dati b) delle applicazioni: individua caratteristiche dei programmi applicativi 4. Implementazione: realizza il sistema informativo (costruita e popolata la base di dati e prodotto il codice dei programmi) 5. Validazione e collaudo: verifica il corretto funzionamento e la qualità del sistema informativo 6. Funzionamento: il sistema informativo è effettivamente utilizzato dagli utenti finali 5 6 Introduzione: ciclo di vita di un sistema informativo Introduzione: progettazione di basi di dati 3. Progettazione a) dei dati: individua struttura e organizzazione dei dati b) delle applicazioni: individua caratteristiche dei programmi applicativi 4. Implementazione: realizza il sistema informativo (costruita e popolata la base di dati e prodotto il codice dei programmi) 5. Validazione e collaudo: verifica il corretto funzionamento e la qualità del sistema informativo La progettazione di una base di dati si avvale di una metodologia Metodologia consiste in: 1. decomposizione dell intera attività in un insieme di fasi 2. strategie e criteri di scelta da adottare nelle varie fasi 3. modelli di riferimento per descrivere l input e l output delle varie fasi 6. Funzionamento: il sistema informativo è effettivamente utilizzato dagli utenti finali 7 8

3 Introduzione: progettazione di basi di dati Introduzione: progettazione di basi di dati Nell ambito delle basi di dati si è consolidata una metodologia di progettazione checonsiste delle seguenti fasi (eseguite in cascata) 1. Progettazione concettuale: produce una descrizione formale e completa dell organizzazione dei dati tramite un modello concettuale dei dati (schema concettuale). Tale descrizione è indipendente dal modo in cui i dati saranno codificati nel sistema reale, così come dalle esigenze di efficienza delle applicazioni che useranno i dati. Pertanto in questa fase non si fa alcuna assuzione né sul modello logico che sarà utilizzato (relazionale? gerarchico? reticolare? altro?) né sulle strutture fisiche di memorizzazione (file e indici) 2. Progettazione logica: traduce lo schema concettuale nel modello logico adottato dal DBMS scelto (il modello relazionale è una delle possibilità) (schema logico) Si usano criteri per ottimizzare le operazioni che saranno effettuate sui dati e tecniche formali per l analisi della qualità dello schema logico prodotto Nessuna assunzione sulle strutture fisiche di memorizzazione 3. Progettazione fisica: definisce le strutture fisiche di memorizzazione (file e indici) (schema fisico) N.B: il risultato della progettazione di una base di dati non è solo lo schema fisico, ma comprende anche gli schemi concettuale e logico! 9 10 Introduzione: progettazione di basi di dati Uno studio particolareggiato della metodologia di progettazione delle basi di dati esula dagli scopi del corso Entity-Relationship (E-R), Entità-Relazione o Entità-Associazione è un modello concettuale dei dati E l analogo sul piano concettuale del relazionale (o del gerarchico, o del reticolare, ) Ci limiteremo a descrivere alcuni aspetti delle fasi di progettazione concettuale e progettazione logica. Il modello relazionale descrive i dati a livello logico; E-R descrive i dati a livello concettuale Il relazionale fa uso dei concetti di relazione, tabella, attributo, tupla, (lo schema logico è espresso per mezzo dei concetti del modello logico) E-R fa uso dei concetti (o costrutti) di entità, associazione, attributo, cardinalità, identificatore, generalizzazione, (lo schema concettuale è espresso per mezzo dei costrutti del modello concettuale) 11 12

4 (Entità) Esaminiamo i costrutti del modello (ogni costrutto ha una rappresentazione grafica purtroppo, non esiste un consenso unanime su tale rappresentazione: qui ne scegliamo una) (Entità) In uno schema concettuale, ogni entità ha un nome che la identifica univocamente all interno dello schema (in uno schema non possono esservi due entità con lo stesso nome) ed è graficamente rappresentata da un rettangolo, es.: Entità: rappresentano insiemi di oggetti (es. persone, cose, fatti) con caratteristiche comuni, es:,,, FATTURA, ORDINE Una occorrenza di una entità è un elemento dell insieme rappresentato dall entità, es.: un particolare medico, un particolare reparto, una specifica affezione, la tale fattura, quel preciso ordine FATTURA ORDINE (Relazioni o associazioni) (Relazioni o associazioni) Associazioni (dette( anche Relazioni): rappresentano legami logici fra entità es.: AFFEZIONE è una possibile relazione che lega le entità e ; è una possibile relazione che lega le entità e N.B. l omonimia fra le relazioni del modello E-R e quella del modello relazionale sottintende una somiglianza fra le due (entrambe denotano relazioni in senso matematico), ma è bene tener presente che NON SONO LA STESSA COSA! Una occorrenza di una relazione fra due entità è una coppia di elementi, uno dei quali appartiene ad una delle due entità e l altro appartiene all altra entità, es. una occorrenza della relazione AFFEZIONE è una coppia il cui primo elemento è (poniamo) quel particolare paziente (cioè quella particolare occorrenza dell entità ) e il secondo è quella tal patologia (cioè quella particolare occorrenza dell entità ) 15 16

5 (Relazioni o associazioni) (Relazioni o associazioni) Es.: paz 1 paz 2 paz 3 aff 1 aff 2 aff 3 aff 4 pat 1 pat 2 In uno schema concettuale, ogni relazione ha un nome che la identifica univocamente all interno dello schema (in uno schema non possono esservi due relazioni con lo stesso nome) ed è graficamente rappresentata da un rombo unito con delle linee alle entità coinvolte, es.: aff 5 pat 3 paz 4 Paziente Patologia paz 1, paz 2, paz 3, paz 4 sono occorrenze dell entità ; pat 1, pat 2, pat 3 sono occorrenze dell entità ; aff 1 = (paz 1, pat 1 ) è un occorrenza della relazione AFFEZIONE e il suo significato inteso è che il paziente paz 1 è affetto dalla patologia pat 1. Si noti che un paziente può essere affetto da una o più patologie, una patologia può riguardare uno o più pazienti, ma anche nessuno (es. pat 2 ) 17 AFFEZIONE Questo frammento di schema concettuale intende esprimere il fatto che nella realtà di interesse esistono dei pazienti e delle patologie e che i pazienti sono affetti da patologie (o, equivalentemente, che le patologie possono interessare i pazienti) 18 (Relazioni o associazioni) Possono esservi più relazioni diverse fra le stesse entità, es.: (Relazioni o associazioni) Finora abbiamo visto relazioni che legano due entità (dette relazioni binarie): è possibile avere relazioni che legano tre (ternarie) o più (ennarie) entità: nel corso, considereremo soltanto relazioni binarie E possibile avere relazioni ricorsive, cioè fra un entità e se stessa, es.: SUPERVISIO NE Nella realtà di interesse esistono degli impiegati e fra di essi sussiste la relazione fra supervisore e subordinati Nella realtà d interesse esistono reparti e medici e i medici afferiscono a reparti (relazione ) che sono diretti da medici (relazione ) 19 Supervisore IMPIEGATO Subordinato N.B.: nelle relazioni ricorsive, quando un elemento di un occorrenza gioca un ruolo diverso dall altro all interno della relazione, occorre specificare i nomi dei ruoli (es.: Supervisore e Subordinato ) 20

6 (Relazioni o associazioni) Una relazione nel modello E-R rappresenta una relazione in senso matematico fra gli insiemi denotati dalle entità coinvolte, es.: AFFEZIONE (Relazioni o associazioni) è bene tener presente la precisa semantica delle relazioni nel modello E-R quando si costruisce e quando si interpreta uno schema concettuale Es. supponiamo di voler rappresentare il concetto di visita medica con una relazione E-R fra e : denota l insieme dei pazienti; denota l insieme delle possibili patologie; AFFEZIONE denota una relazione in senso matematico fra i due insiemi, cioè un sottoinsieme del prodotto cartesiano VISITA La realtà modellata da questo schema è una realtà in cui un dato medico può visitare un certo paziente non più di una volta! Perché? (Relazioni o associazioni) (Attributi) perché, come detto, VISITA è un sottoinsieme del prodotto cartesiano VISITA è un insieme Attributi: descrivono le caratteristiche elementari delle (occorrenze delle) entità e delle (occorrenze delle) relazioni, es.: il fatto che un medico ha un cognome, un nome, un codice identificativo, ecc. può essere espresso per mezzo di attributi associati all entità VISITA non può contenere elementi ripetuti per ogni medico m 1 e per ogni paziente p 1, la coppia (m 1, p 1 ) (che rappresenta il fatto che il medico m 1 ha visitato il paziente p 1 ) può comparire in VISITA non più di una volta ciò significa che il medico m 1 può visitare il paziente p 1 non più di una volta In uno schema concettuale, ogni attributo è associato ad un entità o ad una relazione ed ha un nome che lo identifica univocamente fra gli attributi associati ad una stessa entità o ad una stessa relazione (una stessa entità o una stessa relazione non può avere due attributi con lo stesso nome) 23 24

7 (Attributi) Un attributo è graficamente rappresentato da un pallino unito da una linea all entità o alla relazione cui esso si riferisce, es (Attributi) Il precedente frammento di schema concettuale modella una situazione in cui nella realtà d interesse esistono reparti e medici; ogni reparto ha un nome e ogni medico ha un cognome, un nome e un codice identificativo; inoltre, i medici afferiscono ai reparti che sono diretti da medici; l afferenza ad un reparto e la direzione di un reparto da parte di un medico hanno entrambe una data d inizio (Attributi) Nel modello E-R vi sono anche attributi composti: raggruppano in un singolo attributo proprietà affini, es. Indirizzo attributo composto da Via, Numero Civico, CAP : (Attributi) Es. di frammento di schema concettuale che utilizza i costrutti fin qui visti (tale schema è ancora incompleto) Via SPECIALIZZA ZIONE ELETTORE Indirizzo Numero Civico Sesso Età CAP RICOVERO _ InizioRicovero Gli attributi non composti (es.,, ecc.) sono detti attributi semplici 27 AFFEZIONE DataNascita 28 Descrizione

8 (Cardinalità delle relazioni) E-R, oltre ai costrutti di base fin qui visti, comprende altri costrutti che consentono di specificare ulteriormente la struttura dei dati Cardinalità delle relazioni: sono associate ad ogni ramo della relazione e specificano il numero minimo e massimo di occorrenze della relazione in cui ogni occorrenza di ciascuna entità può comparire; generalmente, per cardinalià minima si usa 0 (zero) o 1 (uno) e per cardinalità massima si usa 1 (uno) o N (il cui significato è più d uno ). Graficamente sono rappresentate da coppie di valori (m,n) (dove m è la cardinalità minima e n è la cardinalità massima e m n) scritte vicino al ramo di relazione cui si riferiscono. 29 (Cardinalità delle relazioni) Es.: AFFEZIONE Le cardinalità associate al ramo della relazione AFFEZIONE dell entità significano che ogni paziente è affetto da almeno una patologia (cardinalità minima uguale a 1) e può essere affetto da più di una patologia (cardinalità massima uguale a N) Le cardinalità associate al ramo della relazione AFFEZIONE dell entità significano che ogni patologia può non interessare alcun paziente (cardinalità minima uguale a 0) oppure può interessare uno o più pazienti (cardinalità massima uguale a N) 30 (Cardinalità delle relazioni) Es. questa è una situazione che rispetta il precedente frammento di schema concettuale (Cardinalità delle relazioni) Es. questa è una situazione che NON rispetta il precedente frammento di schema concettuale paz 1 aff 1 paz 1 aff 1 paz 2 aff 3 aff 2 aff 4 pat 1 pat 2 paz 2 aff 2 aff aff 4 3 pat 1 pat 2 paz 3 paz 3 aff 5 pat 3 pat 3 paz 4 paz 4 Paziente Patologia Paziente Patologia 31 32

9 (Cardinalità delle relazioni) Altro es.: (Cardinalità delle relazioni) Altro es.: (1,1) (1,1) Ogni reparto ha almeno un medico ad esso afferente (e può averne più d uno) 33 Ogni medico afferisce ad esattamente un reparto (cioè non vi sono né medici che non afferiscono ad alcun reparto né medici che afferiscono a più di un reparto) 34 (Cardinalità delle relazioni) (Cardinalità delle relazioni) Altro es.: Altro es.: (1,1) (1,1) Ogni reparto è diretto da esattamente un medico (cioè non vi sono né reparti senza direzione né reparti diretti da più di un medico) 35 Ogni medico dirige al più un reparto, ma possono esservi medici che non dirigono alcun reparto 36

10 (Cardinalità delle relazioni) Es. questa è una situazione che NON rispetta il precedente frammento di schema concettuale (Cardinalità delle relazioni) Es. di frammento di schema concettuale che utilizza i costrutti fin qui visti (tale schema è ancora incompleto) rep 1 affer 1 (1,1) SPECIALIZZA ZIONE rep 2 affer 2 affer 3 med 1 med 2 rep 3 rep 4 affer 4 med 3 med 4 RICOVERO _ Reparto Medico (1,1) InizioRicovero AFFEZIONE DataNascita Descrizione (Cardinalità degli attributi) Cardinalità degli attributi: sono associate ad ogni attributo di entità o di relazione e specificano il numero minimo e massimo di valori dell attributo associati ad ogni occorrenza di entità o di relazione Come nel caso delle cardinalità delle relazioni, generalmente, per cardinalià minima si usa 0 (zero) o 1 (uno) e per cardinalità massima si usa 1 (uno) o N (il cui significato è più d uno ). Graficamente sono rappresentate da coppie di valori (m,n) (dove m è la cardinalità minima e n è la cardinalità massima e m n) scritte vicino all attributo cui si riferiscono. Siccome le cardinalità più comuni per gli attributi sono (1,1), solo le cardinalità diverse da queste compaiono esplicitamente negli schemi concettuali (ciò significa che se nessuna cardinalià è specificata per un attributo, è da intendersi (1,1)) 39 (Cardinalità degli attributi) Esempi: IMPIEGATO IMPIEGATO IMPIEGATO IMPIEGATO (0,1) NumTelefono NumTelefono NumTelefono NumTelefono Un impiegato ha esattamente un cognome, un nome, un codice identificativo ed un numero di telefono Analogo al caso precedente, ma il numero di telefono è opzionale (può non esserci) e, se c è, è unico Analogo al caso precedente, ma un impiegato può non avere un numero di telefono (cioè il numero di telefono è opzionale), oppure può averne uno solo, oppure può averne più d uno Analogo al caso precedente, ma un impiegato deve avere almeno un numero di telefono e può averne più d uno 40

11 (entificatori delle entità) entificatori delle entità: per ogni entità è specificato un identificatore, cioè un insieme di concetti (attributi e/o entità) che servono ad identificare univocamente ogni singola occorrenza dell entità Spesso, per identificare univocamente le occorrenze di un entità è sufficiente un insieme di attributi dell entità (in questo caso si parla di identificatore interno); talvolta, gli attributi dell entità non sono sufficienti ad identificare le occorrenze ed è necessario usare altre entità (identificatore esterno) Per la rappresentazione grafica degli identificatori, si veda gli esempi (entificatori delle entità) Es. (identificatore interno): come identificare le singole occorrenze dell entità? In altre parole, cosa rende distinguibile un reparto da un altro? Visto che all interno di uno stesso ospedale non vi sono due reparti con lo stesso nome, un buon modo per identificare univocamente ogni reparto è farlo attraverso il suo nome. Nel modello E-R questo si esprime specificando l attributo nome quale identificatore dell entità (e disegnandolo con il pallino nero): (entificatori delle entità) (entificatori delle entità) Altro esempio (identificatore interno): consideriamo l entità STUDENTE_TO riportata qui sotto e che denota gli studenti dell Università di Torino : in linea di principio, è possibile che due diversi studenti abbiano lo stesso nome, lo stesso cognome, siano nati nello stesso giorno e risiedano nella stessa città; tuttavia, due studenti della stessa Università hanno sempre due numeri di matricola distinti, pertanto un buon identificatore per l entità STUDENTE_TO è l attributo MATRICOLA Altro esempio (identificatore interno): è possibile che l identificatore di un entità sia composto da più di un attributo, ad esempio, se si ritiene che un impiegato possa essere univocamente identificato dal nome, cognome e data di nascita (usualmente non è così ), si può modellare questa situazione con l entità seguente: DataNascita Matricola STUDENTE_TO DataNascita CittaResidenza IMPIEGATO CittaResidenza N.B.: ogni entità deve avere almeno un identificatore i cui attributi coinvolti hanno tutti cardinalità (1;1) 43 44

12 (entificatori delle entità) Es. (identificatore esterno): con riferimento all esempio dell ospedale, supponiamo di voler modellare una realtà costituita da più ospedali anziché da uno solo (es.: tutti gli ospedali pubblici di una certa regione) e consideriamo l entità. E ovvio che il nome del reparto non è più un buon identificatore, in quanto ospedali distinti possono avere reparti con lo stesso nome (es.: il reparto di nusologia può essere presente in più di un ospedale) tuttavia, all interno di uno stesso ospedale i nomi dei reparti sono univoci per identificare il reparto è necessario (e sufficiente) conoscerne sia il nome, sia l ospedale di appartenenza Questa situazione può essere modellata ricorrendo ad un identificazione esterna, come nel seguente frammento di schema concettuale: (entificatori delle entità) Piano dataistituzione (1,1) APPARTENE NZA OSPEDALE Indirizzo l entità OSPEDALE partecipa alla identificazione delle occorrenze dell entità (entificatori delle entità) Piano dataistituzione (1,1) APPARTENE NZA OSPEDALE Indirizzo (entificatori delle entità) N.B.: gli attributi di una relazione non possono partecipare a definire alcun identificatore! Quindi, in particolare, non è possibile usare gli attributi di una relazione per identificarne le istanze Data VISITA N.B.: le entità che partecipano all identificazione (nell esempio, solo l entità OSPEDALE) devono partecipare a relazioni alle quali l entità che deve essere identificata (nell esempio, ) partecipa con cardinalità (1,1) DataNascita Non è un buon modo per modellare il fatto che uno stesso medico può visitare lo stesso paziente in giorni diversi, in quanto la relazione VISITA non può contenere entrambe le triple (m, p, d 1 ) e (m, p, d 2 ), anche se d 1 d

13 (entificatori delle entità) Es. un possibile schema concettuale (completo) relativo ad un singolo ospedale (in questo schema non vi sono identificazioni esterne) RICOVERO (1,1) InizioRicovero (1,1) AFFEZIONE SPECIALIZZA ZIONE _ Generalizzazioni: esprimono un particolare legame tra un entità E (detta entità padre) e una o più entità E 1,,E n (dette entità figlie), in cui l entità padre rappresenta una generalizzazione dei concetti espressi dalle entità figlie o, viceversa, le entità figlie esprimono concetti che sono casi particolari di quello espresso dall entità padre (per la rappresentazione grafica, si veda gli esempi) Ogni insieme denotato dalle entità figlie è sottoinsieme dell insieme denotato dall entità padre; con una notazione non rigorosa: E 1 E,, E n E Ereditarietà: ogni attributo o relazione specificati per l entità padre è ereditata dalle entità figlie (quindi in una entità figlia non occorre e non si deve! specificare esplicitamente né gli attributi dell entità padre, né le relazioni cui l entità padre partecipa, mentre è possibile specificare attributi e/o relazioni specifiche dell entità figlia non presenti nel padre) 49 (0,1) DataNascita Descrizione 50 Es.: fra il personale di un ospedale vi sono le categorie dei medici e dei paramedici (1,1) PERSONALE (1,1) PERSONALE Riguardano tutto il personale, non sono esplicitamente ripetuti nelle entità e PARA, ma sono da queste ereditati (quindi sia un medico che un paramedico hanno un codice identificativo che è identificatore delle entità e partecipano alla relazione ) PARA SPECIALIZZA ZIONE PARA SPECIALIZZA ZIONE 51 DataNascita Descrizione 52 DataNascita Descrizione

14 (1,1) PARA PERSONALE Solo i medici possono dirigere i reparti e hanno una o più specializzazioni SPECIALIZZA ZIONE Per le generalizzazioni occorre specificare anche il tipo: per ogni generalizzazione bisogna specificare se è parziale (p) o totale (t); inoltre, bisogna specificare se è esclusiva (e) o sovrapposta (s) Una generalizzazione è totale se ogni occorrenza dell entità padre è necessariamente anche un occorrenza di almeno un entità figlia; in caso contrario (cioè se possono esservi occorrenze dell entità padre che non sono occorrenze di alcuna entità figlia), essa è parziale Una generalizzazione è esclusiva se ogni occorrenza dell entità padre è occorrenza di al più un entità figlia (cioè non può esservi alcuna occorrenza dell entità padre che è occorrenza di due o più entità figlie); in caso contrario, essa è sovrapposta N.B.: tutte le 4 combinazioni sono possibili: una generalizzazione può essere parziale e esclusiva (p,e), oppure parziale e sovrapposta (p,s), oppure totale e esclusiva (t,e) oppure totale e sovrapposta (t,s) 53 DataNascita Descrizione 54 Es: il personale di un ospedale comprende sia medici che paramedici, ma non solo (ad es. vi sono anche gli ausiliari, che non sono stati modellati nello schema), quindi la seguente generalizzazione è parziale Inoltre, non esiste alcun dipendente di un ospedale che abbia i ruoli sia di medico che di paramedico, quindi la seguente generalizzazione è esclusiva PERSONALE p PERSONALE (p, e) PARA PARA 55 56

15 personale medici paramedici PERSONALE (1,1) PERSONALE (p, e) (p, e) PARA PARA SPECIALIZZA ZIONE esempio di dipendente che non è né medico né paramedico (es. un ausiliario) Altro es. (generalizzazione (t,e)): Il personale paramedico può avere o non avere un diploma di scuola media superiore CONDIPL PARA PERSONALE (t, e) SENZADIPL (p, e) medici personale paramedici diplomati non diplomati Altro es. (può esservi anche una sola entità figlia), es. i medici con più di una specializzazione in questo caso non ha senso specificare né p/t né e/s CONDIPL PARA PERSONALE (t, e) SENZADIPL (p, e) medici plurispec personale paramedici diplomati non diplomati _PLURISPEC 59 60

16 Altro es. (generalizzazione (p,s)): torinesi Altro es. (generalizzazione (t,s)): universitari studenti_to lavoratori_to studenti_uni lavoratori_uni TORINESI UNIVERSITARI (p, s) (t, s) STUDENTI_TO LAVORATORI_TO STUDENTI_UNI LAVORATORI_UNI esempio di torinese che non è né studente né lavoratore esempio di torinese che è sia studente che lavoratore 61 esempio di individuo che è sia uno studente universitario che un lavoratore dell università 62 Termina qui la panoramica sui principali costrutti E-R riprendiamo l esempio delle visite effettuate da un medico ad un paziente e cerchiamo di capire come costruire uno schema concettuale che modelli questa realtà in modo soddisfacente il seguente schema è inadatto, in quanto modella una situazione in cui uno stesso medico può visitare un medesimo paziente al più una volta Una possibile soluzione è quello di specificare le cardinalità per l attributo Data della relazione VISITA: in questo modo, ogni coppia (m,p) ha un insieme di date ad essa associato che rappresentano tutte le date (e possono esservene più d una) in cui il medico m ha visitato il paziente p Data Data VISITA VISITA DataNascita DataNascita 63 64

17 E se si volesse modellare anche l esito di ogni visita? Una possibile soluzione: attributo misto (Data, Esito), con cardinalità Data Esito VISITA DataNascita Esito Data DataEsito VISITA Lo schema precedente è inadatto, in quanto non modella la corrispondenza fra la data in cui una visita è effettuata e l esito di tale visita DataNascita Documentazione di schemi Entity-Relationship (E-R) Un altra soluzione (più elegante): trasformare VISITA in un entità con identificatore esterno, legata a e a da due nuove relazioni Lo schema E-R, spesso, non è sufficiente per descrivere esaurientemente i dati a livello concettuale DataNascita La ragione principale: E-R non sempre riesce ad esprimere tutte le proprietà significative dei dati (ad es. non tutti i vincoli di integrità sui dati sono esprimibili in E-R) ESECUZIONE _VISITA (1,1) Data (1,1) VISITA _SUBITA Altra ragione: talvolta è opportuno fornire descrizioni più dettagliate dei vari concetti presenti nello schema concettuale, rispetto alle descrizioni che ne fa lo schema stesso VISITA Esito 67 68

18 Documentazione di schemi Entity-Relationship (E-R) Allo schema concettuale vengono generalmente affiancati due documenti: Documentazione di schemi Entity-Relationship (E-R) (Dizionario dei dati) Dizionario dei dati costituito da due tabelle: una per le entità, l altra per le relazioni, es.: 1. Il dizionario dei dati: descrive entità e relazioni 2. Descrizioni di vincoli di integrità (soprattutto quelli non espressi nello schema concettuale, ma eventualmente anche quelli espressi nello schema, ma che necessitano di più dettagliate descrizioni) e regole di derivazione (che descrivono come certe proprietà possono essere ricavate da altre proprietà) 69 Entità Descrizione Reparto dell ospedale Medico correntemente in servizio presso l ospedale competenza specialistica medica patologia di cui può essere affetto qualche paziente paziente correntemente ricoverato presso l ospedale,, Attributi (nome scientifico della patologia),,, DataNascita (gg/mm/aaaa) entificatore 70 Documentazione di schemi Entity-Relationship (E-R) (Dizionario dei dati) Relazione RICOVERO Descrizione associa ciascun medico al reparto cui appartiene associa ciascun reparto ad al primario che lo dirige associa ciascun paziente al reparto in cui è correntemente ricoverato : un reparto ha almeno un medico ad esso afferente (1,1): ogni medico afferisce ad uno ed un solo reparto (1,1): ogni reparto ha uno ed un solo primario (0,1): ogni medico dirige al più un reparto, ma può anche non dirigerne nessuno : un reparto può avere 0, 1 o più pazienti in esso ricoverati (1,1): ogni paziente è ricoverato in uno ed un solo reparto Entità coinvolte Attributi inizioafferenza: data in cui il medico ha iniziato ad afferire al reparto iniziodirezione: data in cui il primario ha iniziato a dirigere il reparto inizioricovero: data in cui il paziente ha iniziato il proprio ricovero nel reparto 71 Documentazione di schemi Entity-Relationship (E-R) (Dizionario dei dati) continuazione Relazione AFFEZIONE _ SPECIALIZZA ZIONE Descrizione associa ciascun paziente alle patologie da cui è correntemente affetto associa ad ogni specialità medica l insieme delle patologie ad essa attinente associa ad ogni medico le discipline in cui egli è specializzato : ogni paziente è correntemente affetto da almeno una patologia : ogni patologia può interessare nessuno, uno o più pazienti : ogni specialità si occupa di almeno una patologia : ogni patologia ha almeno una specialità medica di riferimento : ogni medico è specializzato in almeno una disciplina : possono esservi uno o più medici specializzato in una stessa disciplina, ma è anche possibile che per qualche disciplina non vi siano competenze in ospedale Entità coinvolte Attributi 72

19 Documentazione di schemi Entity-Relationship (E-R) (Descrizione di vincoli di integrità) RV1: il primario di un reparto deve afferire a tale reparto Documentazione di schemi Entity-Relationship (E-R) (Regole di derivazione) per schema concettuale di esempio, non vi sono regole di derivazione RV2: ogni paziente deve essere ricoverato in un reparto diretto da un primario specializzato in una disciplina cui è attinente almeno una patologia da cui il paziente è affetto modifichiamolo leggermente, in modo da poter fare due esempi di regole di derivazione i due vincoli precedenti non sono espressi (né esprimibili!) nello schema concettuale Documentazione di schemi Entity-Relationship (E-R) (Regole di derivazione) Documentazione di schemi Entity-Relationship (E-R) (Regole di derivazione) (1,1) SPECIALIZZA ZIONE RD1: l età di ciascun paziente si ottiene sottraendo la data di nascita del paziente alla data corrente NumSpecializzazioni RD2: il numero di specializzazioni di ciascun medico si ottiene contando il numero di discipline mediche in cui egli è specializzato RICOVERO _ InizioRicovero (1,1) Eta AFFEZIONE (0,1) DataNascita Descrizione 75 76

20 Gli schemi E-R descrivono la struttura dei dati a livello concettuale, senza fare alcuna assunzione sul modello logico dei dati che si intende adottare Prima di essere tradotta nel modello logico di riferimento, la descrizione concettuale subisce un processo di ristrutturazione Una volta scelto il modello logico, occorre tradurre la descrizione concettuale in una descrizione logica dei dati (è uno dei passi della fase di progettazione logica) Noi abbiamo scelto come modello logico dei dati il modello relazionale (quello attualmente più diffuso) La ristrutturazione degli schemi E-R ha due principali obiettivi: porre le condizioni per la codifica di procedure efficienti per la manipolazione dei dati facilitare il processo di traduzione nel modello logico Esistono regole che consentono di tradurre uno schema E-R in un equivalente schema relazionale Non descriveremo il processo di ristrutturazione degli schemi E-R, diciamo solo che esso comprende generalmente una trasformazione del modello concettuale E-R in un equivalente modello E-R in cui (fra l altro): gli attributi sono tutti semplici ( nessun attributo composto) gli attributi hanno tutti cardinalità (1,1) o (0,1) non vi sono generalizzazioni Le regole per la traduzione da E-R a relazionale devono dire come si traducono: 1. le entità con identificatore interno 2. le entità con identificatore esterno 3. i vari tipi di relazioni E-R In generale, ogni passo di traduzione produce una tabella con una certa chiave, un insieme (eventualmente vuoto) di vincoli di integrità referenziale e un insieme (eventualmente vuoto) di vincoli di altro tipo Lo schema E-R così modificato è tradotto nel modello logico di riferimento (per noi, il modello relazionale) 79 Qui scegliamo di presentare una sola possibilità per ogni passo di traduzione anche laddove sono possibili alternative Gli esempi su riquadro color oro si riferiscono all esempio dell ospedale usato in tutto questo modulo 80

21 (trad. entità con identificatore interno) (trad. entità con identificatore interno) Un entità con identificatore interno è tradotta con una tabella tale che ha lo stesso nome dell entità ha tante colonne quanti sono gli attributi dell entità ad ogni attributo dell entità corrisponde una colonna della tabella il valore di in una colonna può essere NULL se e solo se il corrisponente attributo dell entità ha cardinalità (0,1) chiave della tabella è l insieme degli attributi che formano l dentificatore dell entità Es.: (0,1) Descrizione nessuna Atri vincoli: nessuno possibile valore nullo (, Descrizione (*) ) 81 Caso analogo al precedente: nessuna Altri vincoli: nessuno () 82 (trad. entità con identificatore esterno) Es.: (trad. entità con identificatore esterno) Es.: Piano dataistituzione Indirizzo Piano dataistituzione Indirizzo (1,1) APPARTENE NZA OSPEDALE (1,1) APPARTENE NZA OSPEDALE rinominati (per evitare ambiguità)! (Reparto, Ospedale, Piano, dataistituzione) (Reparto, Ospedale, Piano, dataistituzione) fra Ospedale e la chiave della tabella che traduce OSPEDALE Atri vincoli: nessuno 83 fra Ospedale e la chiave della tabella che traduce OSPEDALE Atri vincoli: nessuno 84

22 Es.: Es.: Matricola Data Voto Titolo NumCrediti Matricola Data Voto Titolo NumCrediti STUDENTE ESAME CORSO STUDENTE ESAME CORSO ESAME(MatricolaStudente, TitoloCorso, Data, Voto) rinominati (per miglior comprensibilità)! ESAME(MatricolaStudente, TitoloCorso, Data, Voto) fra MatricolaStudente e la chiave della tabella che traduce STUDENTE fra TitoloCorso e la chiave della tabella che traduce CORSO Altri vincoli: nessuno 85 fra MatricolaStudente e la chiave della tabella che traduce STUDENTE fra TitoloCorso e la chiave della tabella che traduce CORSO Atri vincoli: nessuno 86 _ (0,1) Descrizione _(Specialita, Patologia) fra Specialita e la chiave della tabella che traduce fra Patologia e la chiave della tabella che traduce Altri vincoli: ogni valore della chiave della tabella che traduce deve comparire in almeno una tupla di _ ogni valore della chiave della tabella che traduce deve comparire in almeno una tupla di _ 87 Riprendiamo esempio dell identificazione esterna. La relazione è tradotta traducendo l identificazione esterna (quindi non richiede una tabella che la rappresenti), ma: Piano fra Ospedale e la chiave della tabella che traduce OSPEDALE Altri vincoli: nessuno dataistituzione (1,1) APPARTENE NZA OSPEDALE Indirizzo (Reparto, Ospedale, OSPEDALE(, Indirizzo) Piano, dataistituzione) nessuna Altri vincoli: ogni valore di deve comparire fra i valori dell attributo Ospedale in 88

23 Caso analogo al precedente: SPECIALIZZA ZIONE AFFEZIONE SPECIALIZZAZIONE(Medico, Specialita) fra Medico e la chiave della tabella che traduce fra Specialita e la chiave della tabella che traduce Altri vincoli: ogni valore della chiave della tabella che traduce deve comparire fra i valori dell attributo Medico in SPECIALIZZAZIONE 89 (0,1) DataNascita Descrizione AFFEZIONE(Paziente, Patologia) fra Paziente e la chiave della tabella che traduce fra Patologia e la chiave della tabella che traduce Altri vincoli: ogni valore della chiave della tabella che traduce deve comparire fra i valori dell attributo Paziente in AFFEZIONE 90 (1,1) (1,1) N.B.: la traduzione della relazione non ha prodotto una tabella a sé stante, ma è stata effettuata inglobandone le informazioni nello schema di (,,, Reparto, ) fra Reparto e la chiave della tabella che traduce Altri vincoli: ogni valore della chiave della tabella che traduce deve comparire fra i valori dell attributo Reparto in 91 (,,, Reparto, ) fra Reparto e la chiave della tabella che traduce Altri vincoli: ogni valore della chiave della tabella che traduce deve comparire fra i valori dell attributo Reparto in 92

24 (1,1) (1,1) negli esempi illustrati nelle precedenti slide relative al modello relazionale, questo attributo è stato omesso per ragioni di spazio (,,, Reparto, ) fra Reparto e la chiave della tabella che traduce Altri vincoli: ogni valore della chiave della tabella che traduce deve comparire fra i valori dell attributo Reparto in 93 (, Primario, ) fra Primario e la chiave della tabella che traduce Altri vincoli: nella tabella non devono esservi valori ripetuti per l attributo Primario 94 (1,1) (1,1) N.B.: la traduzione della relazione non ha prodotto una tabella a sé stante, ma è stata effettuata inglobandone le informazioni nello schema di negli esempi illustrati nelle precedenti slide relative al modello relazionale, questo attributo è stato omesso per ragioni di spazio (, Primario, ) fra Primario e la chiave della tabella che traduce Altri vincoli: nella tabella non devono esservi valori ripetuti per l attributo Primario 95 (, Primario, ) fra Primario e la chiave della tabella che traduce Altri vincoli: nella tabella non devono esservi valori ripetuti per l attributo Primario 96

25 RICOVERO (1,1) InizioRicovero (,,, DataNascita, Reparto, InizioRicovero) fra Reparto e la chiave della tabella che traduce Altri vincoli: nessuno DataNascita 97 RICOVERO (1,1) InizioRicovero (,,, DataNascita, Reparto, InizioRicovero) fra Reparto e la chiave della tabella che traduce Altri vincoli: nessuno DataNascita N.B.: la traduzione della relazione RICOVERO non ha prodotto una tabella a sé stante, ma è stata effettuata inglobandone le informazioni nello schema di 98 RICOVERO InizioRicovero (1,1) (,,, DataNascita, Reparto, InizioRicovero) fra Reparto e la chiave della tabella che traduce Altri vincoli: nessuno negli esempi illustrati nelle precedenti slide relative al modello relazionale, questo attributo è stato omesso per ragioni di spazio Sono stati forniti e commentati esempi di traduzione di relazioni E-R con le seguenti combinazioni di cardinalità: (1,1) (1,1) (0,1) (1,1) Analoghi criteri guidano la traduzione delle restanti combinazioni di cardinalità non coperte dagli esempi riportati in questi lucidi, cioè: (0,1) (0,1) (0,1) (0,1) (1,1) (1,1) DataNascita