La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Basi di dati Progetto Logico per il Modello Relazionale (E. Baralis, Politecnico di Torino)

Presentazioni simili


Presentazione sul tema: "Basi di dati Progetto Logico per il Modello Relazionale (E. Baralis, Politecnico di Torino)"— Transcript della presentazione:

1 Basi di dati Progetto Logico per il Modello Relazionale (E. Baralis, Politecnico di Torino)

2 2 Trasformazione da schema E-R a modello relazionale Risultato: schema relazionale nella forma normale opportuna. SCHEMA E-R Schema E-R ristrutturato A Set di relazioni (modello relazionale) B passo A: ristrutturazione passo B: traduzione

3 3 Passo A: ristrutturazione dello schema E-R E’ una fase di riorganizzazione dello schema E-R sulla base del carico applicativo previsto. Il carico applicativo consiste di: 1)Volumi dei dati (memoria d’occupazione); 2)Caratteristiche delle operazioni (piu’ rilevanti).

4 4 Carico applicativo 1)Volumi dei dati: valutati come N*O, dove N è il numero di occorrenze di ogni entità e/o relazione; O è l’occupazione in bytes di ogni occorrenza. 2)Caratteristiche delle operazioni: - tipo (interattivo o batch); - frequenza (numero medio di operazioni in una certa unità di tempo); - volumi di dati coinvolti.

5 5 Indici di prestazioni Lo scopo del passo di ristrutturazione è di ottimizzare i seguenti indici di prestazione: –costo di una operazione: valutato come numero di accessi ad occorrenze di entità e/o relazione visitati per rispondere a una operazione; –occupazione di memoria

6 6 Esempio codicenome impiegato progetto dipartimento nomebudgetdata_consegna data_inizio data_afferenza afferenza partecipazione stipendio età telefono (1,n) nome N_progetti (0,n) (1,n) (0,1) (1,n)

7 7 Tavola dei volumi ConcettoTipoVolume (n. occ) Impiegato Dipartimento Progetto entità Partecipazione Afferenza relazione Dipende dalla cardinalità delle entità e dalla cardinalità media di partecipazione di una occorrenza di entità ad una relazione: Ipotesi: se un impiegato partecipa in media a 3 progetti, la relazione partecipazione ha in media 2000*3 occorrenze; invece afferenza ha cardinalità di poco inferiore a impiegato

8 8 Tavola delle operazioni Operazione 1: assegna un impiegato ad un progetto. Operazione 2: trova tutti i dati di un impiegato (con i dati del suo dipartimento e l’elenco dei progetti ai quali lavora). Operazione 3: trova tutti i dati di un dipartimento (con l’elenco dei suoi dipendenti). OperazioneTipoFrequenza Operazione 1 Operazione 2 Operazione 3 interattiva batch interattiva 50 volte al giorno 100 volte al giorno 1 volta alla settimana

9 9 Costo dell’Operazione 1: “assegna un impiegato ad un progetto” Schema dell’operazione impiegato progetto nomebudgetdata_consegna data_inizio partecipazione stipendio età N_progetti (0,n) (1,n) codicenome +1

10 10 Tavola degli accessi ConcettoTipoN accessi Impiegatoentità relazione 1 1 Partecipazione Lettura/Scrittura S S Costo: 2 operazioni di scrittura * 50 volte al giorno

11 11 Passo A: ristrutturazione dello schema E-R E’ costituito da una sequenza di passi: 1)Analisi delle ridondanze; 2) Eliminazione delle gerarchie di generalizza- zione; 3) Partizionamento/accorpamento di entità; 4)Scelta degli identificatori.

12 12 Analisi delle ridondanze Conviene mantenere l’attributo ridondante N_progetti in impiegato? Costo in volumi di dati per l’attributo N_progetti: 2000 impiegati * 2 byte= 4Kbyte. Costo in aggiornamento (Op.1): 1 accesso in scrittura per 50 volte al giorno. Costo in lettura (Op.2): 1 accesso in lettura per 100 volte al giorno. Se supponiamo che un’operazione di scrittura costi il doppio rispetto ad una di lettura si hanno 200 accessi al giorno.

13 13 Eliminazione attributo N_progetti Alternativamente potrei contare il numero di occorrenze della relazione partecipazione che si riferiscono ad un certo impiegato. Costo in volumi di dati: nullo. Costo di mantenimento: nullo. Costo di lettura: in media 3 operazioni di lettura per 100 volte al giorno: 300 accessi al giorno.

14 14 Eliminazione delle gerarchie di generalizzazione Vi sono alcune possibilità: 1)Collassamento delle sottoclassi nella superclasse: –gli attributi delle sottoclassi sono uniti a quelli dell’entità superiore –si aggiunge un attributo discriminante 2)Eliminazione della superclasse: –propagazione degli attributi della superclasse in tutte sottoclassi 3)Mantenimento di tutte le entità, correlate da relazioni che rappresentano la generalizzazione.

15 15 STUDENTE C_FISC NOME CORSO_DI_STUDI LAUREANDO UNIVERSITARIO HA_ RELATORE SOCIO_ DI FACOLTA` ASSOCIAZIONE_ STUDENTESCA (p,e) (1,1) (1,n) (0,1) TITOLO_ TESI TUTORE STUDENTE C_FISC NOME CORSO_DI_ STUDI HA_ RELATORE SOCIO_ DI FACOLTA` ASSOCIAZIONE_ STUDENTESCA (0,1) (1,n) (0,1) TUTORE GRADO(a.d.,(0,1)) TITOLO_TESI (0,1) Esempio

16 16 Scelta 1 Svantaggi: Incremento di occupazione di memoria (presenza di valori nulli per gli attributi non significativi). Vantaggi: Conviene quando le operazioni non fanno distinzione rispetto all’appartenenza di una occorrenza a una sottoclasse: numero minore di accessi perché le occorrenze di interesse sono tutte concentrate in una stessa entità.

17 17 IMPIEGATO PAGA_ CONTR (0,1) (1,1) CONTRIBUTI SEGRETARIOINGEGNERE MANAGER USA WORD_PROCESSOR (t,e) (0,m) (0,n) CAPACITA` SPECIALIZZAZIONE NOME C_FISC NUM_SOTTOPOSTI (1,n) DIRETTORE Rappresentazione di gerarchie di generalizzazione mediante sottoclassi Esempio (0,1) (1,n)

18 18 CONTR_1 CONTRIBUTI CONTR_2 INGEGNERE MANAGER CONTR_3 SEGRETARIO USA WORD_PROCESSOR DIRETT_2 DIRETT_1 DIRETT_3 (0,1) (1,n) (1,1) (0,m) (0,n) C_FISC NOME SPECIALIZ C_FISC NOME CONOSC NUM_SOTTOPOSTI C_FISC NOME

19 19 Scelta 2 Svantaggi: E’ possibile solo se la generalizzazione è totale, altrimenti le occorrenze della sopraclasse non sarebbero rappresentate. Occorre duplicare il numero di relazioni per ciascuna sottoclasse. Vantaggi: Conviene se le operazioni fanno accesso solo ad occorrenze di una o delle altre sottoclassi. Si risparmia in memoria perché si eliminano i valori nulli degli attributi. Si riducono gli accessi rispetto alla scelta 3 perché per accedere ad un’occorrenza di una sottoclasse non si deve passare per la sopraclasse.

20 20 PROGETTO HA (1,m) (1,n) MEMBRI_ PROGETTO PROGETTO_ SW PROGETTO_ HW SOTTOCONTRATTO USA COMPONENTI_HW (p,o) (1,n) (0,m) MESI_UOMO CONTRAENTE_ PRINCIPALE NUM_ SCHEDE BUDGET NUM_PROG NOME_PROG Rappresentazione di gerarchie di generalizzazione tramite relazioni Esempio

21 21 PROGETTO HA (1,m) (1,n) MEMBRI_ PROGETTO PROGETTO_ SW PROGETTO_ HW SOTTOCONTRATTO USA COMPONENTI_HW (1,n) (0,m) MESI_UOMO CONTRAENTE_ PRINCIPALE NUM_ SCHEDE BUDGET NUM_PROG NOME_PROG TIPO_SW TIPO_HW TIPO_ SOTTOCONTR (0,1) (1,1)

22 22 Scelta 3 Svantaggi Si incrementa il numero di accessi per le occorrenze delle sottoclassi. Se la generalizzazione è totale ed esclusiva, occorre aggiungere dei vincoli: una occorrenza della sopraclasse deve partecipare ad una ed una sola relazione con una delle sottoclassi. Vantaggi Conviene quando la generalizzazione non è totale, e le operazioni fanno accesso o ad occorrenze della sopraclasse, o di sottoclassi. Si risparmia memoria e ciò può aumentare il numero di dati che si recuperano con l’accesso ad un singolo buffer di disco.

23 23 Partizionamento di entità (e relazioni) Il partizionamento d’entità (relazioni) corrisponde a separare i concetti che vengono acceduti da operazioni diverse. Si può decomporre: verticalmente selezionando gli attributi (tramite proiezione). Ha il vantaggio che generano entità semplici, con pochi attributi. orizzontalmente (selezionando le occorrenze sulla base dei valori degli attributi). Ciò può anche essere visto come l’introduzione di una nuova generalizzazione a livello logico. Ha lo svantaggio che si duplicano le relazioni per le due nuove entità.

24 24 Esempio: partizionamento verticale di entità impiegato cognome indirizzo Data_nascita codice livello stipendio ritenute Dati anagraficiDati lavorativi Dati_impiegato (1,1) livello stipendio ritenute cognome indirizzo Data_ nascita codice

25 25 Partizionamento di relazione GiocatoreSquadra composizione (1,n) città nome cognome ruolo GiocatoreSquadra Composizione attuale (1,n)(1,1) nome città cognome ruolo Composizione precedente (1,n) (0,n) Data_ acquisto Data_ cessione (0,1) Data_ acquisto Data_cessione Data_acquisto

26 26 Accorpamento di entità L’accorpamento d’entità corrisponde a raggruppare i concetti che vengono acceduti insieme dalle stesse operazioni. Ciò ad esempio permette di ridurre il numero di join tra entità. Uno svantaggio però consiste nel fatto che potrebbero essere introdotti attributi con valori nulli. Inoltre si introduce una certa ridondanza, il che è equivalente ad una operazione di de- normalizzazione. Perciò viene utilizzata dove sussistono relazioni 1:1 o 0:1 tra le entità da accorpare, e raramente se le relazioni sono 1:molti.

27 27 Esempio Personaappartamento intestazione (1,1) (0,1) indirizzo interno cognome indirizzo Data_ nascita CF Persona cognome indirizzo Data_ nascita CF Indirizzo (0,1) Interno (0,1)

28 28 Eliminazione di attributi composti Due possibilità: a)considerare l’attributo composto come insieme di attributi singoli Problema: si perde la nozione di collegamento tra gli attributi b)eliminare le componenti individuali considerando solo i valori aggregati Problema: il singolo attributo deve poi essere scisso dall’applicazione per individuare i valori separati

29 29 PERSONA INDIRIZZO PERSONA COGNOME ETA` SESSO VIA CITTA` STATO COGNOME ETA` SESSO VIA CITTA` STATO (a) Schema con un attributo composto (b) Attributo composto ridotto nelle sue componenti Esempio PERSONA (c) Attributo composto considerato come attributo singolo COGNOME ETA` INDIRIZZO SESSO

30 30 Eliminazione degli attributi multivalore dalle entità Ogni attributo a molti valori è rappresentato da un'entità, in cui può essere rappresentato come attributo a singolo valore. La nuova entità contiene l’attributo a molti valori più l’identificatore dell’entità di origine. L’identificatore della nuova entità è l’insieme di tutti gli attributi.

31 31 E1 R EAM E1 Attributi multivalore di entità A A B A B (1,n) B A

32 32 PRODOTTO PRODOTTO_MATERIALE Esempio CODICE_PRODOTTO CODICE_MATERIALE (1,n) DESCRIZIONE PREZZO CODICE_PRODOTTO DESCRIZIONE PREZZO CODICE_PRODOTTO CODICE_MATERIALE

33 33 Eliminazione degli attributi multivalore dalle relazioni Attributo a molti valori appartiene alla relazione R tra le entità E1 e E2  nuova entità NE che include 1 o 2 attributi presi da E1 o E2 (o entrambi) in funzione del tipo di relazione: –relazione 1 a 1: NE richiede 1 degli identificatori di E1 o E2 –relazione 1 a molti: NE comprende l’identificatore di E2 (E2 nel lato “molti”) –relazione molti a molti: NE comprende gli identificatori provenienti da E1 ed E2

34 34 La chiave primaria di NE è costituita da: –tutti gli attributi di NE provenienti da E1 ed E2 –l’attributo multi valore Gli attributi non multivalore di R rimangono a R. Eliminazione degli attributi multivalore dalle relazioni

35 35 Attributi a molti valori di relazioni E1 R E2 Attrib B E1 R E2 C D (0,n) (0,m) A B (1,n) C D A B C D

36 36 INSEGNANTE CORSO TIENE (0,m) (1,n) CF_INSEGNANTE DIPARTIMENTO TELEFONO MAX_NUM_STUD SEMESTRE (1,n) NUM_CORSO Esempio

37 37 OFFERTA_ CORSI SEMESTRE INSEGNANTE CORSO TIENE (0,m) (1,n) CF_INSEGNANTE DIPARTIMENTO TELEFONO MAX_NUM_STUD NUM_CORSO CF_INSEGNANTE NUM_CORSO eliminazione di attributo multivalore da una relazione tramite creazione di entità separate

38 38 Scelta degli identificatori Un attributo che ammette valori nulli non può essere un identificatore. La scelta tra due identificatori alternativi avviene in base alla semplicità. Occorre considerare anche la presenza di eventuali identificatori esterni. Conviene preferire gli identificatori che vengono utilizzati dal maggior numero di operazioni. In alcuni casi, può convenire creare “ad arte” un codice che serva da identificatore. Questo potrebbe essere creato automaticamente dal DBMS o sarà l’applicazione a dover gestire la creazione e l’unicità del codice.

39 39 Eliminazione di identificatori esterni Gli identificatori esterni sono trasformati in identificatori interni. E1 R E2 A B ID (1,1) (1,n) E2 E1 B B A

40 40 UNIVERSITÀ ISCRIVE STUDENTE CODICE UNIVERSITÀ NOME CITTÀ MATRICOLA_STUDENTE COGNOME ETÀ (a) Schema iniziale Esempio

41 41 UNIVERSITÀ STUDENTE CODICE UNIVERSITÀ NOME CITTÀ MATRICOLA_STUDENTE COGNOME ETÀ (b) Schema finale CODICE UNIVERSITÀ Esempio +

42 42 Eliminazione di identificatori esterni E1 R1 E3 E2 R2 E1 E2 E3 A B C A ID1 A B A B ID2 C

43 43 Passo B: traduzione nel modello relazionale 1)Traduzione di ogni entità in una tabella 2) Traduzione delle relazioni: –le relazioni 1:1, 1:molti, molti:1 sono modellate aggiungendo attributi a tabelle esistenti –le relazioni molti:molti richiedono sempre la creazione di una nuova tabella

44 44 IMPIEGATO Traduzione di entità Entità = Tabella Esempio: CF NOME COGNOME STIPENDIO IMPIEGATO (CF, NOME, COGNOME, STIPENDIO)

45 45 Riassunto Associazione binaria molti a molti E1 A11 A12 R AR E2 A21 A22 (X,n) E1(A11,A12) E2(A21,A22) R(A11,A21,AR)

46 46 Riassunto Associazione ternaria molti a molti E1 A11 A12 R AR E2 A21 A22 (X,n) E1(A11,A12) E2(A21,A22) E3(A31,A32) R(A11,A21,A31,AR) E3 A31 A32 (X,n)

47 47 Riassunto Associazione uno a molti con partecipazione obbligatoria E1 A11 A12 R AR E2 A21 A22 (1,1) (X,n) E1(A11,A12,A21,AR) E2(A21,A22)

48 48 Riassunto Associazione uno a molti con partecipazione opzionale E1 A11 A12 R AR E2 A21 A22 (0,1) (X,n) E1(A11,A12,A21*,AR*) E2(A21,A22) Oppure E1(A11,A12) E2(A21,A22) R(A11,A21,AR)

49 49 Riassunto Associazione con identificatore esterno E1 A11 A12 R AR E2 A21 A22 (1,1) (X,Y) E1(A11,A21,A12,AR) E2(A21,A22)

50 50 Riassunto Associazione uno a uno con partecipazione obbligatoria per entrambe le entita` E1 A11 A12 R AR E2 A21 A22 (1,1) E1(A11,A12,A21,AR) E2(A21,A22) Oppure E1(A11,A12) E2(A21,A22,A11,AR)

51 51 Riassunto Associazione uno a uno con partecipazione opzionale per una sola entita` E1 A11 A12 R AR E2 A21 A22 (1,1) (0,1) E1(A11,A12,A21,AR) E2(A21,A22)

52 52 Riassunto Associazione uno a uno con partecipazione opzionale per entrambe le entita` E1 A11 A12 R AR E2 A21 A22 (0,1) E1(A11,A12,A21*,AR*) E2(A21,A22) Oppure E1(A11,A12) E2(A21,A22,A11*,AR*) Oppure E1(A11,A12) E2(A21,A22) R(A11,A21,AR)

53 53 Esercizio 1 Si vuole realizzare una base di dati per una societa’ che eroga corsi, di cui vogliamo rappresentare i dati dei partecipanti ai corsi e dei docenti. Per i partecipanti (circa 5000), identificati da un codice, si vuole memorizzare il codice fiscale, il cognome, l’eta’, il sesso, il luogo di nascita, il nome dei loro attuali datori di lavoro, i posti dove hanno lavorato in precedenza insieme al periodo, l’indirizzo e il numero telefonico, i corsi che hanno frequentato (i corsi sono in tutto 200) e il giudizio finale. Si vuole rappresentare anche i seminari che stanno attualmente frequentando, e per ogni giorno, i luoghi e le ore dove sono tenute le varie lezioni. I corsi hanno un codice, un titolo e possono avere varie edizioni, con le date di inizio e fine, e numero dei partecipanti. Se gli studenti sono liberi professionisti, vogliamo conoscere l’area di interesse e, se lo possiedono, il titolo. Per coloro che lavorano alle dipendenze di altri, vogliamo conoscere il livello ricoperto e la posizione. Per gli insegnanti (circa 300) rappresentiamo il cognome, l’eta’ il posto dove sono nati, il nome del corso che insegnano e di quelli che hanno gia’ insegnato e che possono insegnare. Rappresentiamo anche tutti i loro recapiti telefonici. Inoltre, i docenti possono essere dipendenti interni della societa’ o collaboratori esterni.

54 54 Operazioni 1.inserisci un nuovo partecipante: 40 volte al giorno 2.assegna un partecipante ad una edizione di corso: 50 volte al giorno 3.inserisci un nuovo docente e i corsi che puo’ insegnare: 2 volte al giorno 4.assegna un docente abilitato ad una edizione di corso: 15 volte al giorno 5.stampa le informazioni su una edizione di corso passata, con gli orari delle lezioni e numero dei partecipanti: 10 volte al giorno 6.stampa tutti i corsi offerti, con i relativi docenti abilitati: 20 volte al giorno 7.per ogni docente, trova tutti i partecipanti ai corsi da lui insegnati: 5 volta alla settimana 8.effettua una statistica sulla votazione riportata dai partecipanti a una edizione di corso: 10 volte al mese (batch).

55 55 Tavole dei volumi Lezione: 8000 Edizione corso: 1000 Corso: 200 Docente: 300 Collaboratore: 250 Interno: 50 Partecipante: 5000 Dipendente: 4000 Professionista: 1000 Datore: 8000 Part passata: Part corrente: 500 Composizione: 8000 Appartenenza: 1000 Collaboratore: 250 Doc passata: 900 Doc corrente: 100 Abilitazione: 500 Impiego corrente: 4000 Impiego passato: 1000

56 56 Schema concettuale: corso corso edizione_corso lezione partecipante partecipazione_ corrente partecipazione_ passata votazione titolo codice appartenenza composizione data_ inizio data_ fine (1,1) (0,n) (1,n) (1,1) orario aula giorno (0,n) n_partecip

57 57 Schema concettuale: partecipante partecipante CF cognome sesso codice eta’ citta’_nascita dipendente professionista area posizione livello (p,e) titolo_professionale

58 58 Schema concettuale: datore di lavoro datore_di_lavoro nome indirizzo telefono partecipante dipendente professionista (p,e) occupazione_ attuale occupazione_ passata data_inizio data_fine (1,1) (0,n)

59 59 Schema concettuale: docente corso edizione_corso appartenenza (1,1) (0,n) docente collaboratore interno (t,e) abilitazione (1,n) docenza_ corrente docenza_ passata (0,1) (0,n) (0,1) CF cognome eta’ citta’_nascita tel (0,n)

60 60 Mantenere attributo derivato n_partecip? Tra le operazioni specificate, solo le prestazioni delle operazioni 2 e 5 vengono influenzate da n_partecip. Non conviene tenerlo perche’ in questo caso ci sono svantaggi: – nell’occupazione aggiuntiva (4Kb) – stesso numero di accessi (490) che in assenza di dato derivato

61 61 Calcolo accessi con n_partecip presente Op 2 (50 volte al giorno) tipo concetto n. accessi lettura scrittura partecipante ed_corso partecip_ corrente 1 1 1x 2 Totale: 300 accessi al giorno

62 62 Calcolo accessi con n_partecip presente Op 5 (10 volte al giorno) tipo concetto n. accessi lettura ed_corso appartenenza corso composizione Totale: 190 accessi al giorno lettura 8 lezione

63 63 Calcolo accessi con n_partecip assente Op 2 (50 volte al giorno) tipo concetto n. accessi lettura scrittura partecipante ed_corso partecip_ corrente x 2 Totale: 200 accessi al giorno

64 64 Calcolo accessi con n_partecip assente Op 5 (10 volte al giorno) tipo concetto n. accessi lettura ed_corso appartenenza corso composizione Totale: 290 accessi al giorno lettura 8 lezione lettura partecip_ corrente 10

65 65 Eliminazione delle gerarchie Conviene eliminare la gerarchia dei docenti (le operazioni non fanno distinzione e le classi figlie non hanno attributi aggiuntivi) Conviene mantenere le sottoclassi della gerarchia sui partecipanti (ci sono molti attributi aggiuntivi che diverrebbero valori null nella classe padre, anche se le operazioni 1, 2 e 8 non fanno differenza tra le occorrenze dei partecipanti): introduciamo due relazioni dati_dipendente e dati_professionista.

66 66 Partizionamento di concetti Partizionare edizione_corso in passato e corrente? (operazione 5 considera solo le edizioni passate) –Non conviene perche’ si dovrebbero duplicare le relazioni composizione e appartenenza; –Inoltre, le operazioni 7 e 8 non fanno distinzione tra le edizioni di corso correnti e passate.

67 67 Accorpamento di concetti Accorpare docenza_passata e docenza_corrente? (e analogamente partecipazione_passata e corrente?) –Conviene perche’ le operazioni 7 e 8 non fanno differenza tra le occorrenze passate e correnti –Inoltre, non si dovrebbero spostare le occorrenze di docenza e partecipazione correnti in quelle passate una volta terminata l’edizione del corso. –C’e’ pero’ lo svantaggio che c’e’ uno spreco di memoria per rappresentare l’attributo votazione anche per le partecipazioni correnti. Tuttavia, la frazione del numero totale di occorrenze di partecipazioni correnti e’ piccola rispetto a quelle passate (1/20, e si sprecano solo 2 Kb nell’ipotesi di allocare 4 bytes per ciascuna votazione).

68 68 Scelta degli identificatori principali Scegliamo il codice interno per identificare i partecipanti. Invece assegnamo un codice ad-hoc per identificare l’edizione corsi invece di usare la coppia (data_inizio,codice_corso) che rappresenta un identificatore troppo “pesante” (e viene usato per rappresentare anche le relazioni partecipazione e docenza).

69 69 Schema ER ristrutturato: corso corso edizione_corso lezione partecipante partecipazione votazione (0,1) titolo codice appartenenza composizione data_inizio data_fine (1,1) (0,n) (1,n) (1,1) orario aula giorno (0,n) codice

70 70 Schema ER ristrutturato: partecipante partecipante CF cognome sesso codice eta’ citta’_nascita dipendente professionista area posizione livello titolo_professionale dati_dip dati_prof (0,1) (1,1)

71 71 telefono corso edizione_corso appartenenza (1,1) (0,n) docente abilitazione (1,n) docenza (0,n) (0,1) CF cognome eta’ citta’_nascita tel (0,n) tipo Schema ER ristrutturato: docente telef_docente intestazione (0,n) (1,1)

72 72 Schema ER ristrutturato: datore cognome codice partecipante CF sesso eta’ citta’_nascita dipendente professionista area posizione livello titolo_professionale dati_dip dati_prof (0,1) (1,1) datore_di_lavoro nome indirizzo telefono occupazione_ attuale occupazione_ passata data_inizio (1,1) (0,n) data_inizio data_fine (0,n)

73 73 Traduzione nel modello relazionale Edizione_corso(codice, data_inizio, data_fine, corso, docente) Lezione(ora, aula, giorno, edizione_corso) Docente(CF, cognome, eta’, citta’_nascita, tipo) Telefono(numero, docente) Corso(codice, nome) Abilitazione(corso, docente) Partecipante(codice, CF, cognome, eta’, citta’_nascita, sesso) Partecipazione(partecipante, edizione_corso, votazione*) Datore(nome, telefono, indirizzo) Occupazione_passata(partecipante, datore, data_inizio, data_fine) Professionista(partecipante, area, titolo*) Dipendente(partecipante, livello, posizione, datore, data_inizio)

74 74 Schema relazionale della societa’ di formazione Edizione_corso(codice, data_inizio, data_fine, corso, docente) Lezione(ora, aula, giorno, edizione_corso) Docente(CF, cognome, eta’, citta’_nascita, tipo) Telefono(numero, docente) Corso(codice, nome) Abilitazione(corso, docente) Partecipante(codice, CF, cognome, eta’, citta’_nascita, sesso) Partecipazione(partecipante, edizione_corso, votazione*) Datore(nome, telefono, indirizzo) Occupazione_passata(partecipante, datore, data_inizio, data_fine) Professionista(partecipante, area, titolo*) Dipendente(partecipante, livello, posizione, datore, data_inizio)


Scaricare ppt "Basi di dati Progetto Logico per il Modello Relazionale (E. Baralis, Politecnico di Torino)"

Presentazioni simili


Annunci Google