Università degli Studi di Torino Facoltà di Economia

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "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

Basi di dati. (Sistemi Informativi) teoria e pratica con Microsoft Access. Basi di dati. Basi di dati. Basi di dati e DBMS DBMS DBMS

Basi di dati. (Sistemi Informativi) teoria e pratica con Microsoft Access. Basi di dati. Basi di dati. Basi di dati e DBMS DBMS DBMS Basi di Basi di (Sistemi Informativi) Sono una delle applicazioni informatiche che hanno avuto il maggiore utilizzo in uffici, aziende, servizi (e oggi anche sul web) Avete già interagito (magari inconsapevolmente)

Dettagli

Progettazione di basi di dati. Progettazione di basi di dati. Ciclo di vita dei sistemi informativi. Fasi del ciclo di vita [1]

Progettazione di basi di dati. Progettazione di basi di dati. Ciclo di vita dei sistemi informativi. Fasi del ciclo di vita [1] Progettazione di basi di dati Progettazione di basi di dati Requisiti progetto Base di dati Struttura Caratteristiche Contenuto Metodologia in 3 fasi Progettazione concettuale Progettazione logica Progettazione

Dettagli

Progettazione di un DB....in breve

Progettazione di un DB....in breve Progettazione di un DB...in breve Cosa significa progettare un DB Definirne struttura,caratteristiche e contenuto. Per farlo è opportuno seguire delle metodologie che permettono di ottenere prodotti di

Dettagli

Progettazione base dati relazionale

Progettazione base dati relazionale Progettazione base dati relazionale Prof. Luca Bolognini E-Mail:luca.bolognini@aliceposta.it Progettare una base di dati Lo scopo della progettazione è quello di definire lo schema della base di dati e

Dettagli

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Progettazione Basi Dati: Metodologie e modelli!modello Entita -Relazione Progettazione Base Dati Introduzione alla Progettazione: Il ciclo di vita di un Sist. Informativo

Dettagli

PROGETTAZIONE CONCETTUALE

PROGETTAZIONE CONCETTUALE Fasi della progettazione di basi di dati PROGETTAZIONE CONCETTUALE Parte V Progettazione concettuale Input: specifiche utente Output: schema concettuale (astrazione della realtà) PROGETTAZIONE LOGICA Input:

Dettagli

Introduzione alla progettazione. Metodologie e modelli per la progettazione di basi di dati. Il ciclo di vita dei sistemi informativi

Introduzione alla progettazione. Metodologie e modelli per la progettazione di basi di dati. Il ciclo di vita dei sistemi informativi Metodologie e modelli per la progettazione di basi di dati Introduzione alla progettazione Il problema: progettare una base di base di dati a partire dai suoi requisiti Progettare: definire la struttura,

Dettagli

PROGETTAZIONE DI UN DATABASE

PROGETTAZIONE DI UN DATABASE Indice PROGETTAZIONE DI UN DATABASE 1.Il modello ER (entity relationship)...1 Generalità...1 I costrutti principali del modello...2 Entità...2 Associazioni...2 Attributi...2 Altri costrutti del modello...2

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli

Database. Appunti di Amaranto Oronzo e Giancane Diego Lezione dell Ing. Lucia Vaira 24/04/2014

Database. Appunti di Amaranto Oronzo e Giancane Diego Lezione dell Ing. Lucia Vaira 24/04/2014 Database Appunti di Amaranto Oronzo e Giancane Diego Lezione dell Ing. Lucia Vaira 24/04/2014 Cos'è un database? È una struttura di dati composta da tabelle a loro volta composte da campi. Caratteristiche

Dettagli

Basi di Dati Relazionali

Basi di Dati Relazionali Corso di Laurea in Informatica Basi di Dati Relazionali a.a. 2009-2010 PROGETTAZIONE DI UNA BASE DI DATI Raccolta e Analisi dei requisiti Progettazione concettuale Schema concettuale Progettazione logica

Dettagli

Progettazione concettuale

Progettazione concettuale Progettazione concettuale Strategie top-down A partire da uno schema che descrive le specifiche mediante pochi concetti molto astratti, si produce uno schema concettuale mediante raffinamenti successivi

Dettagli

Il modello Entity-Relationship: elementi di base

Il modello Entity-Relationship: elementi di base Il modello Entity-Relationship: elementi di base Sistemi Informativi T Versione elettronica: 06.1.ER.base.pdf I modelli concettuali dei dati Vogliamo pervenire a uno schema che rappresenti la realtà di

Dettagli

Basi di dati Progettazione logica. Elena Baralis Politecnico di Torino

Basi di dati Progettazione logica. Elena Baralis Politecnico di Torino Progettazione logica Progettazione logica Richiede di scegliere il modello dei dati!modello relazionale Obiettivo: definizione di uno schema logico relazionale corrispondente allo schema ER di partenza

Dettagli

Informatica (Basi di Dati)

Informatica (Basi di Dati) Corso di Laurea in Biotecnologie Informatica (Basi di Dati) Modello Entità-Relazione Anno Accademico 2009/2010 Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati Lucidi del Corso di Basi di Dati 1, Prof.

Dettagli

Basi di dati. Le funzionalità del sistema non vanno però ignorate

Basi di dati. Le funzionalità del sistema non vanno però ignorate Basi di dati La progettazione di una base di dati richiede di focalizzare lo sforzo su analisi, progettazione e implementazione della struttura con cui sono organizzati i dati (modelli di dati) Le funzionalità

Dettagli

I livelli di progettazione possono essere così schematizzati: Esistono tre tipi diversi di modelli logici: Modello gerarchico: Esempio SPECIFICHE

I livelli di progettazione possono essere così schematizzati: Esistono tre tipi diversi di modelli logici: Modello gerarchico: Esempio SPECIFICHE I DATABASE o basi di dati possono essere definiti come una collezione di dati gestita dai DBMS. Tali basi di dati devono possedere determinati requisiti, definiti come specifiche, necessarie per il processo

Dettagli

Progettazione logica relazionale (1/2)

Progettazione logica relazionale (1/2) Progettazione di basi di dati (1/2) Introduzione Ristrutturazione dello schema ER Eliminazione delle gerarchie Partizionamento di concetti Eliminazione degli attributi multivalore Eliminazione degli attributi

Dettagli

Cardinalità e identificatori. Informatica. Generalizzazioni. Generalizzazioni. Generalizzazioni. Generalizzazioni

Cardinalità e identificatori. Informatica. Generalizzazioni. Generalizzazioni. Generalizzazioni. Generalizzazioni e identificatori Codice (0,1) (1,1) Dirige Informatica Lezione 8 Laurea magistrale in Scienze della mente Laurea magistrale in Psicologia dello sviluppo e dell'educazione Anno accademico: 2012 2013 1 Cognome

Dettagli

LABORATORIO di INFORMATICA

LABORATORIO di INFORMATICA Università degli Studi di Cagliari Corso di Laurea Magistrale in Ingegneria per l Ambiente ed il Territorio LABORATORIO di INFORMATICA A.A. 2010/2011 Prof. Giorgio Giacinto IL MODELLO ER PER LA PROGETTAZIONE

Dettagli

Basi di dati. Il Modello Relazionale dei Dati. K. Donno - Il Modello Relazionale dei Dati

Basi di dati. Il Modello Relazionale dei Dati. K. Donno - Il Modello Relazionale dei Dati Basi di dati Il Modello Relazionale dei Dati Proposto da E. Codd nel 1970 per favorire l indipendenza dei dati Disponibile come modello logico in DBMS reali nel 1981 (non è facile realizzare l indipendenza

Dettagli

MODELLO RELAZIONALE. Introduzione

MODELLO RELAZIONALE. Introduzione MODELLO RELAZIONALE Introduzione E' stato proposto agli inizi degli anni 70 da Codd finalizzato alla realizzazione dell indipendenza dei dati, unisce concetti derivati dalla teoria degli insiemi (relazioni)

Dettagli

Il modello Entity-Relationship per il progetto delle basi di dati

Il modello Entity-Relationship per il progetto delle basi di dati 1 Il modello Entity-Relationship per il progetto delle basi di dati Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova Le metodologie di progettazione delle Basi di Dati 2 Una metodologia

Dettagli

Progettazione di Basi di Dati

Progettazione di Basi di Dati Progettazione di Basi di Dati Prof. Nicoletta D Alpaos & Prof. Andrea Borghesan Entità-Relazione Progettazione Logica 2 E il modo attraverso il quale i dati sono rappresentati : fa riferimento al modello

Dettagli

Fasi del progetto ( 1 )

Fasi del progetto ( 1 ) Progetto 2004-2005 2005 Esercitazione delle lezioni 2, 3 e 4. 1 Fasi del progetto ( 1 ) Analisi dettagliata delle specifiche fornite dal committente. Questa fase è fondamentale per capire a fondo quali

Dettagli

database: modello entityrelationship

database: modello entityrelationship Insegnamento di Informatica CdS Scienze Giuridiche A.A. 2007/8 database: modello entityrelationship Prof.Valle D.ssaFolgieri Lez7 25.10.07 Trattamento dati. Database: modello entity-relationship 1 Fasi

Dettagli

Lezione 5: Progettazione di Software e Database. Ingegneria del Software. Il Software 19/11/2011. Dr. Luca Abeti

Lezione 5: Progettazione di Software e Database. Ingegneria del Software. Il Software 19/11/2011. Dr. Luca Abeti Lezione 5: Progettazione di Software e Database Dr. Luca Abeti Ingegneria del Software L ingegneria del software è la disciplina che studia i metodi e gli strumenti per lo sviluppo del software e la misura

Dettagli

Associazioni. Informatica. Associazioni. Associazioni. Associazioni. Attributi. Possono esistere associazioni diverse che coinvolgono le stesse entità

Associazioni. Informatica. Associazioni. Associazioni. Associazioni. Attributi. Possono esistere associazioni diverse che coinvolgono le stesse entità Informatica Possono esistere associazioni diverse che coinvolgono le stesse entità Lezione 7 Lavora a Laurea magistrale in Scienze della mente Laurea magistrale in Psicologia dello sviluppo e dell'educazione

Dettagli

Modello Relazionale dei DBMS - Vincoli Tradizionalmente, esistono quattro modelli logici: Gerarchico Reticolare Relazionale A oggetti XML I modelli

Modello Relazionale dei DBMS - Vincoli Tradizionalmente, esistono quattro modelli logici: Gerarchico Reticolare Relazionale A oggetti XML I modelli Modello Relazionale dei DBMS - Vincoli Tradizionalmente, esistono quattro modelli logici: Gerarchico Reticolare Relazionale A oggetti XML I modelli gerarchico e reticolare sono più vicini alle strutture

Dettagli

11 - Progettazione Logica

11 - Progettazione Logica Corso di Laurea in Ingegneria Gestionale SAPIENZA Università di Roma Esercitazioni del corso di Basi di Dati Prof.ssa Catarci e Prof.ssa Scannapieco Anno Accademico 2011/2012 11 - Progettazione Logica

Dettagli

Basi di Dati. Progettazione del Modello ER. K. Donno - Progettazione del Modello ER

Basi di Dati. Progettazione del Modello ER. K. Donno - Progettazione del Modello ER Basi di Dati Progettazione del Modello ER Dai requisiti allo schema ER Entità, relazioni e attributi non sono fatti assoluti dipendono dal contesto applicativo Nella pratica si fa spesso uso di una strategia

Dettagli

70555 Informatica 3 70777 Sicurezza 2. 70555 Mario Rossi 70777 Anna Bianchi. Esempio istanza:

70555 Informatica 3 70777 Sicurezza 2. 70555 Mario Rossi 70777 Anna Bianchi. Esempio istanza: DOMANDE 1) Definire i concetti di schema e istanza di una base di dati, fornendo anche un esempio. Si definisce schema di una base di dati, quella parte della base di dati stessa che resta sostanzialmente

Dettagli

I database relazionali sono il tipo di database attualmente piu diffuso. I motivi di questo successo sono fondamentalmente due:

I database relazionali sono il tipo di database attualmente piu diffuso. I motivi di questo successo sono fondamentalmente due: Il modello relazionale I database relazionali sono il tipo di database attualmente piu diffuso. I motivi di questo successo sono fondamentalmente due: 1. forniscono sistemi semplici ed efficienti per rappresentare

Dettagli

BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA. Lezione II - BioIngInfMed

BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA. Lezione II - BioIngInfMed BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA 1 Sistema Informativo Un sistema informativo (SI) è un componente di una organizzazione il cui obiettivo è gestire le informazioni utili per gli scopi dell

Dettagli

Progettare una basi di dati vuole dire progettare la struttura dei dati e le applicazioni

Progettare una basi di dati vuole dire progettare la struttura dei dati e le applicazioni LA PROGETTAZIONE DI BASI DI DATI Progettare una basi di dati vuole dire progettare la struttura dei dati e le applicazioni La progettazione dei dati è l attività più importante Per progettare i dati al

Dettagli

La progettazione concettuale: il modello ER. 17/12/2007 Unità di Apprendimento A2 1

La progettazione concettuale: il modello ER. 17/12/2007 Unità di Apprendimento A2 1 La progettazione concettuale: il modello ER 17/12/2007 Unità di Apprendimento A2 1 1 La progettazione concettuale Prima di procedere con la progettazione concettuale è necessario effettuare un analisi

Dettagli

Data Base Relazionali

Data Base Relazionali Data Base Relazionali Modello Relazionale dei dati Basi di Dati Relazionali 1 Progettazione di DB METODOLOGIA DI PROGETTO IN TRE FASI Descrizione formalizzata e completa della realtà di interesse REALTA'

Dettagli

LABORATORIO. 2 Lezioni su Basi di Dati Contatti:

LABORATORIO. 2 Lezioni su Basi di Dati Contatti: PRINCIPI DI INFORMATICA CORSO DI LAUREA IN SCIENZE BIOLOGICHE Gennaro Cordasco e Rosario De Chiara {cordasco,dechiara}@dia.unisa.it Dipartimento di Informatica ed Applicazioni R.M. Capocelli Laboratorio

Dettagli

Design di un database

Design di un database Design di un database Progettare un database implica definire quanto i seguenti aspetti: Struttura Caratteristiche Contenuti Il ciclo di design di un database si suddivide in tre fasi principali: progettazione

Dettagli

Rappresentazione grafica di entità e attributi

Rappresentazione grafica di entità e attributi PROGETTAZIONE CONCETTUALE La progettazione concettuale, ha il compito di costruire e definire una rappresentazione corretta e completa della realtà di interesse, e il prodotto di tale attività, è lo schema

Dettagli

Il modello relazionale

Il modello relazionale Il modello relazionale Il modello relazionale è stato introdotto nel 1970 da E.F. Codd. Soltanto a metà degli anni ottanta ha trovato una buona diffusione sul mercato, in quanto all epoca della sua introduzione

Dettagli

Basi di dati. Concetti introduttivi ESEMPIO. INSEGNAMENTI Fisica, Analisi, Aule. Docenti. Entità Relazioni Interrogazioni. Ultima modifica: 26/02/2007

Basi di dati. Concetti introduttivi ESEMPIO. INSEGNAMENTI Fisica, Analisi, Aule. Docenti. Entità Relazioni Interrogazioni. Ultima modifica: 26/02/2007 Basi di dati Concetti introduttivi Ultima modifica: 26/02/2007 ESEMPIO INSEGNAMENTI Fisica, Analisi, Informatica Aule Docenti Entità Relazioni Interrogazioni St udent i Database 2 Tabella (I) STUDENTE

Dettagli

Corso di Sistemi di Elaborazione delle Informazioni I Anno 2005/2006. Esercizi entità relazione risolti. a cura di Angela Campagnaro 802749

Corso di Sistemi di Elaborazione delle Informazioni I Anno 2005/2006. Esercizi entità relazione risolti. a cura di Angela Campagnaro 802749 Corso di Sistemi di Elaborazione delle Informazioni I Anno 2005/2006 Esercizi entità relazione risolti a cura di Angela Campagnaro 802749 Indice: Esercizio 1: Un insieme di officine 1.1 Testo esercizio.3

Dettagli

Alessandra Raffaetà. Basi di Dati

Alessandra Raffaetà. Basi di Dati Lezione 2 S.I.T. PER LA VALUTAZIONE E GESTIONE DEL TERRITORIO Corso di Laurea Magistrale in Scienze Ambientali Alessandra Raffaetà Dipartimento di Informatica Università Ca Foscari Venezia Basi di Dati

Dettagli

Database 1 biblioteca universitaria. Testo del quesito

Database 1 biblioteca universitaria. Testo del quesito Database 1 biblioteca universitaria Testo del quesito Una biblioteca universitaria acquista testi didattici su indicazione dei professori e cura il prestito dei testi agli studenti. La biblioteca vuole

Dettagli

Il database management system Access

Il database management system Access Il database management system Access Corso di autoistruzione http://www.manualipc.it/manuali/ corso/manuali.php? idcap=00&idman=17&size=12&sid= INTRODUZIONE Il concetto di base di dati, database o archivio

Dettagli

Data Base. Ing. Maria Grazia Celentano www.mariagraziacelentano.it

Data Base. Ing. Maria Grazia Celentano www.mariagraziacelentano.it Data Base Ing. Maria Grazia Celentano www.mariagraziacelentano.it 1 Introduzione 2 Sistemi informativi e informatici 3 Sistemi informativi e informatici 4 Dati e informazioni 5 Le Basi di Dati 6 Proprietà

Dettagli

Partite string string int int. Perché studiare il Modello Relazionale? Capitolo 2. Relazione: tre accezioni. Basi di dati relazionali: definizioni

Partite string string int int. Perché studiare il Modello Relazionale? Capitolo 2. Relazione: tre accezioni. Basi di dati relazionali: definizioni Perché studiare il Modello Relazionale? Capitolo 2 Il modello relazionale È il modello più largamente usato Produttori: IBM, Informix, Microsoft, Oracle, Sybase, etc. Sistemi proprietari nei modelli più

Dettagli

MODELLO E/R. Modellazione dei dati

MODELLO E/R. Modellazione dei dati MODELLO E/R Maria Mirto Modellazione dei dati Modellare i dati significa: costruire una rappresentazione semplificata della realtà osservata, individuandone gli elementi caratterizzanti e i legami intercorrenti

Dettagli

Progettazione Logica. Progettazione Logica

Progettazione Logica. Progettazione Logica Consorzio per la formazione e la ricerca in Ingegneria dell'informazione Tabelle per ogni concetto Docente: Cesare Colombo CEFRIEL colombo@cefriel.it http://www.cefriel.it Passaggio al modello logico (1)

Dettagli

DIPARTIMENTO IMPIEGATO PROGETTO SEDE. (0,1) (1,1) DIREZIONE Cognome. Codice. Telefono (0,1) (1,N) AFFERENZA. Stipendio (0,N) Nome (1,1) Età

DIPARTIMENTO IMPIEGATO PROGETTO SEDE. (0,1) (1,1) DIREZIONE Cognome. Codice. Telefono (0,1) (1,N) AFFERENZA. Stipendio (0,N) Nome (1,1) Età PROGETTAZIONE LOGICA 7í0 Progettazione logica Obiettivo: ëtradurre" lo schema concettuale in uno schema logico che rappresenti gli stessi dati in maniera corretta ed eæciente Input: Output: æ schema concettuale

Dettagli

Basi di dati. Concetti Introduttivi ESEMPIO. Fisica, Analisi, Informatica. Entità Relazioni Interrogazioni. Database 2

Basi di dati. Concetti Introduttivi ESEMPIO. Fisica, Analisi, Informatica. Entità Relazioni Interrogazioni. Database 2 Basi di dati Concetti Introduttivi ESEMPIO Fisica, Analisi, Informatica Entità Relazioni Interrogazioni Database 2 Tabella (I) STUDENTE Attributi Data di Nascita Indirizzo Matricola Luca Neri 27/10/1980

Dettagli

Informatica per l'impresa. Sistemi per la gestione di basi di Dati

Informatica per l'impresa. Sistemi per la gestione di basi di Dati Informatica per l'impresa Sistemi per la gestione di basi di Dati Prof. Mauro Gaspari gaspari@cs.unibo.it 1 1 Sistema Informativo Insieme degli strumenti, risorse e procedure che consentono la gestione

Dettagli

Il Modello Relazionale

Il Modello Relazionale Il Modello Relazionale Il modello relazionale 1 Il modello relazionale Proposto da E. F. Codd nel 1970 per favorire l indipendenza dei dati e reso disponibile come modello logico in DBMS reali nel 1981

Dettagli

Organizzazione delle informazioni: Database

Organizzazione delle informazioni: Database Organizzazione delle informazioni: Database Laboratorio Informatico di base A.A. 2013/2014 Dipartimento di Scienze Aziendali e Giuridiche Università della Calabria Dott. Pierluigi Muoio (pierluigi.muoio@unical.it)

Dettagli

Corso di Basi di Dati A.A. 2013/2014

Corso di Basi di Dati A.A. 2013/2014 Corso di Laurea in Ingegneria Gestionale Sapienza - Università di Roma Corso di Basi di Dati A.A. 2013/2014 8 - Progettazione Concettuale Tiziana Catarci, Andrea Marrella Ultimo aggiornamento : 27/04/2014

Dettagli

Modulo 2 Data Base 2

Modulo 2 Data Base 2 Modulo 2 Data Base 2 Università degli Studi di Salerno Corso di Laurea in Scienze della comunicazione Informatica generale Docente: Angela Peduto A.A. 2004/2005 Relazioni: riepilogo Relazione : concetto

Dettagli

Le Basi di dati: generalità. Unità di Apprendimento A1 1

Le Basi di dati: generalità. Unità di Apprendimento A1 1 Le Basi di dati: generalità Unità di Apprendimento A1 1 1 Cosa è una base di dati In ogni modello di organizzazione della vita dell uomo vengono trattate informazioni Una volta individuate e raccolte devono

Dettagli

Identificatori delle entità

Identificatori delle entità Identificatori delle entità Permettono di identificare in maniera univoca le occorrenze delle entità Ogni entità deve averne (almeno) uno Targa Automobile Modello Colore Nome Persona Data di nascita Indirizzo

Dettagli

BASI DI DATI - : I modelli di database

BASI DI DATI - : I modelli di database BASI DI DATI - : I modelli di database DAL 1960 ci si e' orientati verso 3 direzioni: 1 MODELLO GERARCHICO Se i dati si presentano naturalmente in una struttura ad albero (ES. File System) Limiti: rigidità

Dettagli

Basi di dati. Gabriella Trucco gabriella.trucco@unimi.it

Basi di dati. Gabriella Trucco gabriella.trucco@unimi.it Basi di dati Gabriella Trucco gabriella.trucco@unimi.it Esempio Quando si pensa ad un database, generalmente si immagina una tabella contenente grandi quantità di informazioni, sulla quale è possibile

Dettagli

1.1 I componenti di un DBMS... 5

1.1 I componenti di un DBMS... 5 Indice 1 Introduzione ai DBMS.......................................................... 1 1.1 Scopi di un DBMS............................................................ 1 1.2 Modelli dei dati..............................................................

Dettagli

Progettazione del Software

Progettazione del Software L4.4 Progettazione del Software Emiliano Casalicchio Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti http://www.ce.uniroma2.it/courses/psw Seconda Parte La fase di

Dettagli

Lo schema concettuale risultante dalla progettazione concettuale è l input alla fase di progettazione logica.

Lo schema concettuale risultante dalla progettazione concettuale è l input alla fase di progettazione logica. Progettazione logica Lo schema concettuale risultante dalla progettazione concettuale è l input alla fase di progettazione logica. La progettazione logica è basata su un particolare modello logico dei

Dettagli

Vincoli di Integrità

Vincoli di Integrità Vincoli di Integrità Antonella Poggi Dipartimento di informatica e Sistemistica Sapienza Università di Roma Progetto di Applicazioni Software Anno accademico 2010-2011 Questi lucidi sono stati prodotti

Dettagli

LA NORMALIZZAZIONE. Introduzione

LA NORMALIZZAZIONE. Introduzione LA NORMALIZZAZIONE Introduzione La normalizzazione e' una tecnica di progettazione dei database, mediante la quale si elimina la rindondanza dei dati al fine di evitare anomalie nella loro consistenza

Dettagli

Schemi Entita`-Associazione: linguaggio

Schemi Entita`-Associazione: linguaggio Schemi Entita`-Associazione: linguaggio sintassi linguaggio: regole di composizione di strutture sempre piu` complesse. semantica linguaggio: rappresentazione/realizzazione della sintassi. sintassi E-A:

Dettagli

Lezione 2. Il modello entità relazione

Lezione 2. Il modello entità relazione Lezione 2 Il modello entità relazione Pag.1 Introduzione alla progettazione delle basi di dati 1. Analisi dei requisiti Quali sono le entità e le relazioni dell organizzazione? Quali informazioni su queste

Dettagli

Impresa di raccolta e riciclaggio di materiali metallici e di rifiuti.

Impresa di raccolta e riciclaggio di materiali metallici e di rifiuti. Impresa di raccolta e riciclaggio di materiali metallici e di rifiuti. Indice Cognome Nome Matr.xxxxxx email Cognome Nome Mat. Yyyyyy email Argomento Pagina 1. Analisi dei requisiti 1 a. Requisiti espressi

Dettagli

Capitolo 8. Esercizio 8.1

Capitolo 8. Esercizio 8.1 Capitolo 8 Esercizio 8.1 Si consideri lo schema Entità-Relazione ottenuto come soluzione dell esercizio 7.4. Fare delle ipotesi sul volume dei dati e sulle operazioni possibili su questi dati e, sulla

Dettagli

Consegno relazione su testimonianza aziendale a cui ho partecipato: Poker S.p.A. Gruppo Gnosys

Consegno relazione su testimonianza aziendale a cui ho partecipato: Poker S.p.A. Gruppo Gnosys Nome Cognome Matricola Consegno relazione su testimonianza aziendale a cui ho partecipato: Poker S.p.A. Gruppo Gnosys Corso di Information and Communication Technology II esame scritto del 20 febbraio

Dettagli

L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE

L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE Roccatello Ing. Eduard L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE Agenda Presentazione docente Definizione calendario Questionario pre corso

Dettagli

MODELLO E/R. Prof. Francesco Accarino IIS Altiero Spinelli Sesto San Giovanni

MODELLO E/R. Prof. Francesco Accarino IIS Altiero Spinelli Sesto San Giovanni MODELLO E/R Prof. Francesco Accarino IIS Altiero Spinelli Sesto San Giovanni Modellazione dei dati Modellare i dati significa: costruire una rappresentazione semplificata della realtà osservata individuandone

Dettagli

PROVE SCRITTE CON SOLUZIONE

PROVE SCRITTE CON SOLUZIONE ANNO ACCADEMICO 2011/2012 SISTEMI INFORMATIVI E BASI DI DATI CORSO DI LAUREA IN INGEGNERIA GESTIONALE PROVE SCRITTE CON SOLUZIONE Prof. Domenico Beneventano 2 INDICE 1 Struttura della Prova Scritta 5 1.1

Dettagli

Basi di Dati. Conversione Modello ER in Modello Relazionale. K. Donno - Conversione Modello ER in Modello Relazionale

Basi di Dati. Conversione Modello ER in Modello Relazionale. K. Donno - Conversione Modello ER in Modello Relazionale Basi di Dati Conversione Modello ER in Modello Relazionale Il Modello Relazionale che rappresenta la realtà di interesse può essere ricavato direttamente dal Modello ER attraverso una sequenza di operazioni

Dettagli

I Sistemi Informativi

I Sistemi Informativi I Sistemi Informativi Definizione Un Sistema Informativo è un mezzo per acquisire, organizzare, correlare, elaborare e distribuire le informazioni che riguardano una realtà che si desidera descrivere e

Dettagli

COS È UN LINGUAGGIO? LINGUAGGI DI ALTO LIVELLO LA NOZIONE DI LINGUAGGIO LINGUAGGIO & PROGRAMMA

COS È UN LINGUAGGIO? LINGUAGGI DI ALTO LIVELLO LA NOZIONE DI LINGUAGGIO LINGUAGGIO & PROGRAMMA LINGUAGGI DI ALTO LIVELLO Si basano su una macchina virtuale le cui mosse non sono quelle della macchina hardware COS È UN LINGUAGGIO? Un linguaggio è un insieme di parole e di metodi di combinazione delle

Dettagli

ARCHIVI E DATABASE (prof. Ivaldi Giuliano)

ARCHIVI E DATABASE (prof. Ivaldi Giuliano) ARCHIVI E DATABASE (prof. Ivaldi Giuliano) Archivio: è un insieme di registrazioni (o records) ciascuna delle quali è costituita da un insieme prefissato di informazioni elementari dette attributi (o campi).

Dettagli

Cardinalità. Informatica. Cardinalità. Cardinalità. Cardinalità. Cardinalità. Cardinalità delle associazioni:

Cardinalità. Informatica. Cardinalità. Cardinalità. Cardinalità. Cardinalità. Cardinalità delle associazioni: Informatica Lezione 3 Laurea magistrale in Psicologia Laurea magistrale in Psicologia dello sviluppo e dell'educazione Anno accademico: 2008-2009 delle associazioni: engono specificate per ciascuna partecipazione

Dettagli

Modello relazionale. ing. Alfredo Cozzi 1

Modello relazionale. ing. Alfredo Cozzi 1 Modello relazionale E fondato sul concetto matematico di relazione tra insiemi di oggetti Una relazione su n insiemi A1, A2,..,An è un sottoinsieme di tutte le n-uple a1,a2,,an che si possono costruire

Dettagli

Basi di dati. Maurizio Lenzerini. Dipartimento di Informatica e Sistemistica Antonio Ruberti Università di Roma La Sapienza. Anno Accademico 2011/2012

Basi di dati. Maurizio Lenzerini. Dipartimento di Informatica e Sistemistica Antonio Ruberti Università di Roma La Sapienza. Anno Accademico 2011/2012 Basi di dati Dipartimento di Informatica e Sistemistica Antonio Ruberti Università di Roma La Sapienza Anno Accademico 2011/2012 http://www.dis.uniroma1.it/~lenzerin/home/?q=node/44 4. La progettazione

Dettagli

PROGETTAZIONE CONCETTUALE

PROGETTAZIONE CONCETTUALE PROGETTAZIONE CONCETTUALE 1 Il Modello Concettuale Nella progettazione concettuale la descrizione dei dati da rappresentare avviene a livello astratto indipendentemente dal computer e dal software utilizzato.

Dettagli

Il modello Entity-Relationship (ER)

Il modello Entity-Relationship (ER) Il modello Entity-Relationship (ER) Prof. Genny Tortora tortora@unisa.it Università di Salerno, a.a. 2010/2011 E.R.: Introduzione Il modello Entità-Relazione (ER) è un diffusissimo data model di alto livello,

Dettagli

Progettazione concettuale usando il modello Entità-Relazione (ER) e Progettazione Logica

Progettazione concettuale usando il modello Entità-Relazione (ER) e Progettazione Logica Progettazione concettuale usando il modello Entità-Relazione (ER) e Progettazione Logica 1 Introduzione alla progettazione delle basi di dati v Progettazione concettuale (in questa fase si usa il modello

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 B1 - Progettazione dei DB 1 Prerequisiti Ciclo di vita del software file system Metodologia di progettazione razionale del software 2 1 Introduzione Per la realizzazione

Dettagli

Progettazione di Database

Progettazione di Database Progettazione di Database Progettazione Concettuale: strutturazione della realtà che si vuole rappresentare secondo uno schema concettuale Dallo schema concettuale si ricava lo schema del database relazionale

Dettagli

Modello dei Dati ENTITÀ-RELAZIONE (ENTITY-RELATIONSHIP) é l insieme di concetti, simboli, regole che useremo per rappresentare il modello concettuale

Modello dei Dati ENTITÀ-RELAZIONE (ENTITY-RELATIONSHIP) é l insieme di concetti, simboli, regole che useremo per rappresentare il modello concettuale Modello dei Dati E-R ENTITÀ-RELAZIONE O (ENTITY-RELATIONSHIP) é l insieme di concetti, simboli, regole che useremo per rappresentare il modello concettuale R.Gori - G.Leoni Modello dei Dati Entità-Relazione

Dettagli

Linguaggi e Paradigmi di Programmazione

Linguaggi e Paradigmi di Programmazione Linguaggi e Paradigmi di Programmazione Cos è un linguaggio Definizione 1 Un linguaggio è un insieme di parole e di metodi di combinazione delle parole usati e compresi da una comunità di persone. È una

Dettagli

Modello Relazionale. Modello Relazionale. Relazioni - Prodotto Cartesiano. Relazione: tre accezioni. Es. Dati gli insiemi

Modello Relazionale. Modello Relazionale. Relazioni - Prodotto Cartesiano. Relazione: tre accezioni. Es. Dati gli insiemi Modello Relazionale Modello Relazionale Proposto agli inizi degli anni 70 da Codd Finalizzato alla realizzazione dell indipendenza dei dati Unisce concetti derivati dalla teoria degli insiemi (relazioni)

Dettagli

SISTEMI INFORMATIVI AVANZATI -2010/2011 1. Introduzione

SISTEMI INFORMATIVI AVANZATI -2010/2011 1. Introduzione SISTEMI INFORMATIVI AVANZATI -2010/2011 1 Introduzione In queste dispense, dopo aver riportato una sintesi del concetto di Dipendenza Funzionale e di Normalizzazione estratti dal libro Progetto di Basi

Dettagli

14. LA PROGETTAZIONE CONCETTUALE: IL DIAGRAMMA ER

14. LA PROGETTAZIONE CONCETTUALE: IL DIAGRAMMA ER 14. LA PROGETTAZIONE CONCETTUALE: IL DIAGRAMMA ER La progettazione concettuale consiste nel riorganizzare tutti gli elementi che si hanno a disposizione dopo la fase di raccolta delle richieste (utente),

Dettagli

DBMS (Data Base Management System)

DBMS (Data Base Management System) Cos'è un Database I database o banche dati o base dati sono collezioni di dati, tra loro correlati, utilizzati per rappresentare una porzione del mondo reale. Sono strutturati in modo tale da consentire

Dettagli

DB - Modello relazionale dei dati. DB - Modello Relazionale 1

DB - Modello relazionale dei dati. DB - Modello Relazionale 1 DB - Modello relazionale dei dati DB - Modello Relazionale 1 Definizione Un modello dei dati è un insieme di meccanismi di astrazione per definire una base di dati, con associato un insieme predefinito

Dettagli

Metodologia di Progettazione database relazionali

Metodologia di Progettazione database relazionali Informatica e Telecomunicazioni S.p.A. Metodologia di Progettazione database relazionali I&T Informatica e Telecomunicazioni S.p.A Via dei Castelli Romani, 9 00040 Pomezia (Roma) Italy Tel. +39-6-911611

Dettagli

1. PRIME PROPRIETÀ 2

1. PRIME PROPRIETÀ 2 RELAZIONI 1. Prime proprietà Il significato comune del concetto di relazione è facilmente intuibile: due elementi sono in relazione se c è un legame tra loro descritto da una certa proprietà; ad esempio,

Dettagli

Il modello relazionale dei dati

Il modello relazionale dei dati Il modello relazionale dei dati Master Alma Graduate School Sistemi Informativi Home Page del corso: http://www-db.deis.unibo.it/courses/alma_si1/ Versione elettronica: 04Relazionale.pdf Obiettivi della

Dettagli

IL MODELLO RELAZIONALE

IL MODELLO RELAZIONALE IL MODELLO RELAZIONALE E i vincoli per le basi di dati relazionali 2 La storia Introdotto nel 1970 da E. F. Ted Codd http://en.wikipedia.org/wiki/edgar_f._codd (centro ricerche IBM) Codd, E.F. (1970).

Dettagli

Il Modello Relazionale

Il Modello Relazionale Il Modello Relazionale 1 Proposto da E. F. Codd nel 1970 per favorire l indipendenza dei dati e reso disponibile come modello logico in DBMS reali nel 1981 Si basa sul concetto matematico di relazione,

Dettagli

Facoltà di Farmacia - Corso di Informatica

Facoltà di Farmacia - Corso di Informatica Basi di dati Riferimenti: Curtin cap. 8 Versione: 13/03/2007 1 Basi di dati (Database, DB) Una delle applicazioni informatiche più utilizzate, ma meno conosciute dai non informatici Avete già interagito

Dettagli

Modellazione dei dati in UML

Modellazione dei dati in UML Corso di Basi di Dati e Sistemi Informativi Modellazione dei dati in UML Angelo Montanari Dipartimento di Matematica e Informatica Università degli Studi di Udine Introduzione UML (Unified Modeling Language):

Dettagli