La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Progettazione Logica 1 Progettazione logica I.Analisi delle prestazioni su schemi E-R II.Ristrutturazione di schemi E-R III.Traduzione verso il modello.

Presentazioni simili


Presentazione sul tema: "Progettazione Logica 1 Progettazione logica I.Analisi delle prestazioni su schemi E-R II.Ristrutturazione di schemi E-R III.Traduzione verso il modello."— Transcript della presentazione:

1

2 Progettazione Logica 1 Progettazione logica I.Analisi delle prestazioni su schemi E-R II.Ristrutturazione di schemi E-R III.Traduzione verso il modello relazionale

3 requisiti del Sistema informativo progettazione concettuale progettazione logica progettazione fisica SCHEMA LOGICO SCHEMA CONCETTUALE SCHEMA FISICO

4 Progettazione Logica3 Obiettivo della progettazione logica “Tradurre" lo schema concettuale (schema E-R) in uno schema logico (modello relazionale) che rappresenti gli stessi dati in maniera corretta ed efficiente

5 Progettazione Logica4 Dati di ingresso e uscita  Ingresso: schema concettuale informazioni sul carico applicativo modello logico  Uscita: schema logico documentazione associata

6 Progettazione Logica5  Lo schema E-R va ristrutturato: Semplificazione della traduzione: alcuni aspetti dello schema concettuale non sono direttamente rappresentabili nel modello logico Ottimizzazione del progetto: è necessario considerare le prestazioni Non si tratta di una pura e semplice traduzione

7 Schema E-R ristrutturato Modello logico Traduzione nel modello logico Schema logico Fase 2 Ristrutturazione dello schema E-R Schema E-R Carico applicativo Fase 1

8 Progettazione Logica7 Fase 1: Ristrutturazione schema E-R  E' indipendente dal modello logico scelto e si basa sui due principi di: semplificazione ottimizzazione  Osservazione: uno schema E-R ristrutturato non è (più) uno schema concettuale nel senso stretto del termine

9 Progettazione Logica8 Le prestazioni non sono valutabili con precisione su uno schema concettuale, dato che dipendono anche da parametri fisici: -dal sistema per la gestione di basi di dati utilizzato - dalle strutture dati utilizzate per memorizzare le tabelle - dai vari modi in cui si possono realizzare le operazioni in SQL Per ottimizzare il risultato abbiamo bisogno di analizzare le prestazioni a questo livello Analisi delle prestazioni su schemi E-R

10 Progettazione Logica9 Consideriamo degli "indici di prestazione" dei parametri che regolano le prestazioni di uno schema E-R:  occupazione di memoria (spazio): spazio di memoria necessario per memorizzare i dati descritti dallo schema dipende dal numero di occorrenze di entità e relazioni previste  costo di una operazione (tempo): numero di occorrenze (di entità e relationship) visitate per rispondere a un’operazione sulla base di dati

11 Progettazione Logica10 Informazioni necessarie per l’analisi delle prestazioni  Per studiare questi parametri abbiamo bisogno di conoscere, oltre allo schema, le seguenti informazioni volume dei dati : numero di occorrenze di ogni entità dello schema numero di occorrenze di ogni relationship dello schema dimensioni di ciascun attributo (di entità o relationship) caratteristiche delle operazioni: tipo di operazione (interattiva o batch) frequenza dell’esecuzione dati coinvolti (entità e/o relationship)

12 Città Indirizzo Telefono Dipartimento Composizione Sede Direzione Afferenza Impiegato Progetto Partecipazione Nome Cognome Budget Data Via CAP (1,1) (0,1) (1,N) (0,1) (1,1) (1,N) (0,N) (1,N) Codice Schema di riferimento

13 12 Tavola dei volumi vi sono riportati i concetti dello schema col volume previsto a regime

14 Progettazione Logica13 Occorrenze di una relationship  Il numero delle occorrenze di una relationship dipende da: Numero di occorrenze delle entità coinvolte nella relationship Numero medio di partecipazioni di una occorrenza di entità all’occorrenza della relationship  Esempio: Volume Composizione = Volume Dipartimento Volume Afferenza  Volume Impiegato Volume Direzione = Volume Dipartimento Volume Partecipazione = 3  Volume Impiegato

15 Progettazione Logica14 Esempio di valutazione di costo delle operazioni  Operazione: 1. assegna un impiegato a un progetto 2. trova tutti i dati di un impiegato, del dipartimento nel quale lavora e dei progetti ai quali partecipa 3. trova i dati di tutti gli impiegati di un certo dipartimento 4. per ogni sede trova i suoi dipartimenti con il cognome del direttore e l’elenco degli impiegati del dipartimento

16 Progettazione Logica15 Descrizione delle operazioni  L’analisi delle operazioni principali richiede la codifica di: tipo dell’operazione : Interattiva (I) o Batch (B) frequenza: numero medio di esecuzioni in un certo periodo di tempo schema di navigazione: frammento dello schema E/R interessato dall’operazione sul quale viene disegnato (con delle frecce) il “cammino logico” da percorrere per accedere alle informazioni di interesse

17 Progettazione Logica16 Tavola delle operazioni

18 Progettazione Logica17  Regola 80-20: l’80% del carico è generato dal 20% delle operazioni Dunque il carico si può valutare accuratamente basandoci sulle principali operazioni previste  Per ogni operazione significativa si costruisce uno schema di navigazione (frammento di di schema E-R interessato all’operazione) Regola 80-20

19 Telefono Nome Data (1,N) (0,1) (1,1) (1,N) Dipartimento Afferenza NomeBudget (1,N) Progetto Partecipazione Cognome (0,N) Codice Impiegato schema di navigazione Operazione 2: trova tutti i dati di un impiegato, del dipartimento nel quale lavora e dei progetti ai quali partecipa

20 Progettazione Logica19 Tavola degli accessi  Per ogni operazione significativa si costruisce una tavola degli accessi basata sullo schema di navigazione il campo costrutto specifica il tipo di concetto (entità o associazione) nel campo accessi si conta il numero degli accessi necessario per eseguire una volta l’operazione il campo tipo è riferito al tipo di operazione: le operazioni di scrittura (S) sono più onerose di quelle di lettura (L) il peso degli accessi in scrittura è in genere considerato doppio di quello delle letture

21 Progettazione Logica20 Tavola degli accessi Un accesso può essere di tipo L (lettura) o S (scrittura) Il numero delle istanze si ricava dalla tavola dei volumi mediante semplici operazioni es: in media ogni impiegato partecipa a 6000/2000 = 3 progetti

22 Progettazione Logica21 Attività della ristrutturazione Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relationship Scelta degli identificatori primari

23 Progettazione Logica22 1. Analisi delle ridondanze  Una ridondanza in uno schema E-R è una informazione significativa ma derivabile da altri dati  in questa fase si decide se eliminare le ridondanze eventualmente presenti o mantenerle

24 Progettazione Logica23 Ridondanze  Vantaggi semplificazione delle interrogazioni riduzione del numero degli accessi necessari per calcolare il dato derivato  Svantaggi appesantimento degli aggiornamenti maggiore occupazione di spazio

25 Progettazione Logica24 Forme di ridondanza in uno schema E-R  attributi derivabili: da altri attributi della stessa entità (o relazione) da altri attributi della stessa entità (o relazione) da attributi di altre entità (o relazioni)  relazioni derivabili dalla composizione di altre relazioni in presenza di ciclicicli

26 Progettazione Logica25 Attributo derivabile Fattura Importo netto IVA Importo lordo

27 Progettazione Logica26 Attributo derivabile da altra entità Importo totale Composizione AcquistoProdotto Prezzo (1,N) Importo totale è ottenibile con operazioni di aggregazione

28 Corso Studente Frequenza (0,N) (1,N) Professore Insegnamento (1,1) Docenza (0,N) (1,N) Ridondanza dovuta a ciclo

29 Progettazione Logica28 Mantenere o meno la ridondanza? La decisione di mantenere o eliminare una ridondanza va presa confrontando il costo di una esecuzione delle operazioni che coinvolgono il dato ridondante e l’occupazione di memoria, nei casi di presenza e assenza della ridondanza

30 Progettazione Logica29 Analisi di una ridondanza Residenza PersonaCittà Numero abitanti (1,1)(1,N) L’attributo numero abitanti è derivabile da una operazione di conteggio delle istanze di persona residenti in una città

31 Progettazione Logica30  Operazione 1: memorizza una nuova persona con la relativa città di residenza (500 volte al giorno)  Operazione 2: stampa tutti i dati di una città (incluso il numero di abitanti) (2 volte al giorno) tavola dei volumi

32 Progettazione Logica31 Presenza di ridondanza Operazione 1 Operazione 2

33 Progettazione Logica32 Assenza di ridondanza Operazione 1 Operazione 2 n.persone/n.città = media accessi per calcolare il numero di abitanti di una città

34 Progettazione Logica33 Presenza di ridondanza  Costi: Operazione 1: 1500 accessi in scrittura e 500 accessi in lettura al giorno Operazione 2: trascurabile.  Contiamo doppi gli accessi in scrittura  Totale di 3500 accessi al giorno

35 Progettazione Logica34 Assenza di ridondanza  Costi: Operazione 1: 1000 accessi in scrittura Operazione 2: accessi in lettura al giorno  Contiamo doppi gli accessi in scrittura  Totale di accessi al giorno Conviene dunque mantenere il dato ridondante

36 Progettazione Logica35 Ristrutturazione dello schema E-R Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relazioni Scelta degli identificatori primari

37 Progettazione Logica36 2. Eliminazione delle gerarchie  il modello relazionale non può rappresentare direttamente le generalizzazioni  entità e relazioni sono invece direttamente rappresentabili si eliminano perciò le gerarchie, sostituendole con entità e relazioni

38 Progettazione Logica37 Tre possibilità 1.accorpamento delle figlie della generalizzazione nel genitoreaccorpamento delle figlie della generalizzazione nel genitore 2.accorpamento del genitore della generalizzazione nelle figlieaccorpamento del genitore della generalizzazione nelle figlie 3.sostituzione della generalizzazione con relazionisostituzione della generalizzazione con relazioni

39 E0 R1 A01 A02 E3 R2 E4 E2 E1 A11 A21 Schema generale

40 Progettazione Logica39 Accorpamento delle figlie della generalizzazione nel genitore  E1 e E2 sono eliminate e le loro proprietà vengono aggiunte al padre E0  A E0 viene aggiunto anche un nuovo attributo, TIPO, che serve a distinguere le occorrenze di E1 da quelle di E2  Gli attributi A11 e A21 possono assumere anche valori nulli su E0

41 A11 A21 TIPO (0,1) (0,..) E0 A01 A02 R1 E3 R2 E4 Collasso verso l’alto

42 Studente LaureandoDiplomando Matr. Nome Tit.Stage Tit.Tesi Matr Relatore Denom. Azienda (1,1) (p,e) (1,n) Dom(Tipo)= {L,D,N} Denom. Studente Matr. Nome Tit.Stage (0,1) Tit.Tesi (0,1) Matr Relatore Azienda (0,1) Tipo (1,n) Esempio

43 Progettazione Logica42 Osservazioni  Conveniente quando le operazioni sulla base di dati non fanno molta distinzione tra le occorrenze e tra gli attributi di E0, E1, E2  Vantaggi: numero minore di accessi  Svantaggi: spreco di memoria per la presenza di valori nulli

44 E0 R1 A01 A02 E3 R2 E4 E2 E1 A11 A21 totale

45 44 Accorpamento del genitore della generalizzazione nelle figlie  E0 viene eliminato, i suoi attributi e identificatore vengono assegnati alle figlie  R11 e R12 sono le restrizioni di R1 alle occorrenze di E1 e E2 Nota Bene tale trasformazione è possibile solo se la generalizzazione è totale, altrimenti le occorrenze di E0 - (E1 U E2) non sarebbero rappresentate Conviene quando ci sono operazioni che si riferiscono solo a occorrenze di E1, o di E2 e fanno distinzioni tra tali entità

46 E3 R2 E4 E2 E1 A11 A21 R12 R11 A01 A02 A01 A02 Collasso verso il basso

47 Esempio Dipendente ImpiegatoOperaio CF Nome macchine capacità (t,e) Dirigente n_sottoposti Sindacato Contribuisce 0,1 1,n 0,1 1,n Dirige ImpiegatoOperaio macchine capacità Dirigente n_sottoposti Sindacato Contr_I 0,1 0,n 0,1 1,n CF Nome 0,n Contr_D 0,1 Contr_O 0,1 0,n Dir_D Dir_O Dir_I CF Nome CF Nome 0,n

48 Progettazione Logica47  Quando conviene utilizzare questa alternativa? Quando ci sono operazioni che si riferiscono solo a occorrenze di E1 oppure di E2, e fanno distinzioni tra le 2 entità Gli attributi non assumono mai valori nulli

49 Progettazione Logica48 Sostituzione della generalizzazione con relationship  La generalizzazione si trasforma in due associazioni uno a uno che legano l’entità padre E0 con E1 e E2  Si pongono dei vincoli per impedire che una occorrenza di E0 partecipi sia a E1 che a E2 Nota bene -conviene se gli accessi alle entità figlie sono separati dagli accessi al padre -è sempre possibile indipendentemente dalla copertura e conserva tutte le entità -le entità vengono mantenute e sono identificate esternamente

50 RG2 RG1 (1,1) (0,1) (1,1) (0,1) E0 A01 A02 E2 E1 R2 E4 A11 A21 R1 E3

51 Progetto Prog_swProg_hw Cod Desc N_schede Mesi uomo Comp_hw usa 1,n 0,n Esempio Progetto Prog_swProg_hw Cod Desc N_schede Mesi uomo Comp_hw usa 1,n 0,n 0,1 1,1

52 Progettazione Logica51  Quando conviene usare questa alternativa? quando la generalizzazione non è totale, quando ci sono operazioni che si riferiscono solo a occorrenze di E1, E2 oppure E0,  Risparmio di memoria rispetto alla scelta (1): non si introducono valori nulli  Aumento degli accessi per mantenere la consistenza delle occorrenze

53 Progettazione Logica52 Attività della ristrutturazione Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relazioni Scelta degli identificatori primari

54 Progettazione Logica53  entità e associazioni in uno schema E-R possono essere partizionati o accorpati per rendere più efficienti le operazioni, in base a un semplice principio:  gli accessi si riducono: separando attributi di un concetto che vengono acceduti separatamente; raggruppando attributi di concetti diversi acceduti insieme;

55 Progettazione Logica54 Ristrutturazioni, casi principali  partizionamento orizzontale/verticale di entità partizionamento orizzontale/verticale di entità  eliminazione di attributi multivalore eliminazione di attributi multivalore  accorpamento di entità/ relationship accorpamento di entità/ relationship

56 Progettazione Logica55 Impiegato Livello Stipendio Ritenute Cognome Indirizzo Data nascita Codice Partizionamento verticale di entità

57 Progettazione Logica56 Livello Stipendio Ritenute Cognome Indirizzo Data nascita Codice Dati Impiegato Dati anagrafici Dati lavorativi (1,1) Si separano gli attributi in gruppi omogenei

58 Progettazione Logica57 Agenzia Indirizzo Città Telefono Nome (1,N) Eliminazione di attributi multivalore

59 Progettazione Logica58 Numero Indirizzo Nome Utenza AgenziaTelefono (1,N) (1,1) Città l Si introduce una entità le cui istanze sono identificate dai valori dell’attributo l L’associazione può essere uno a molti o molti a molti

60 Progettazione Logica59 Agenzia Indirizzo Città Telefono Nome (1,3) Se la cardinalità massima K è nota: è possibile prevedere K repliche degli attributi Tel2Tel1Tel3 Nome Agenzia Indirizzo Città Eliminazione di attributi multivalore

61 Progettazione Logica60 Indirizzo Interno Cognome Indirizzo Data nascita Codice fiscale Intestazione PersonaAppartamento (0,1) (1,1) Accorpamento di Entità

62 Progettazione Logica61 Persona Interno Indirizzo Cognome Indirizzo Data nascita Codice fiscale (0,1)

63 Cognome Composizione GiocatoreSquadra (1,N) Ruolo NomeCittà Data acquisto Data cessione Cognome Comp. passata GiocatoreSquadra (0,N) (1,N) Ruolo Nome Città Data acquisto Data cessione Comp. attuale Data acquisto (1,1) (1,N) Partizionamento orizzontale di associazioni

64 Progettazione Logica63 Attività della ristrutturazione Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relationship Scelta degli identificatori primari

65 Progettazione Logica64 Scelta degli identificatori principali  operazione indispensabile per la traduzione nel modello relazionale perché nel modello relazionale le chiavi vengono usate per stabilire legami tra dati in relazioni diverse; i DBMS richiedono di specificare una chiave primaria;  si deve decidere quale degli identificatori utilizzare come chiave principale

66 Progettazione Logica65  Criteri Gli attributi con valori nulli non possono essere identificatori principali Gli identificatori con uno o pochi attributi sono preferibili vantaggio in termini di risparmio di memoria nella realizzazione dei legami logici tra le varie relazioni facilita le operazioni di join Un identificatore interno è preferibile Un identificatore utilizzato nelle operazioni più frequenti o importanti è preferibile

67 Progettazione Logica66 Se nessuno degli identificatori soddisfa i requisiti visti? Si introducono nuovi attributi (codici) contenenti valori speciali generati appositamente per questo scopo ES. Contatori, Sigle

68 67  L’identificatore {Interno, Indirizzo} è opzionale, quindi non può essere scelto  Tra Codice fiscale e Codice SSN la scelta dipende da quale è più frequentemente usato per accedere a una persona Interno Indirizzo Cognome Indirizzo Data nascita Codice fiscale (0,1) Codice SSN Persona

69 Progettazione Logica68 Fase 2: Traduzione verso il modello relazionale  Input: schema concettuale modello logico  Output: schema logico  Sono possibili altre fasi: Verifiche sulla qualità dello schema Normalizzazione dello schema prodotto

70 Progettazione Logica69 Traduzione verso il relazionale  idea di base: le entità diventano relazioni sugli stessi attributi e la chiave è l’identificatore principale le relationship (o associazioni) diventano relazioni i cui attributi sono gli identificatori delle entità coinvolte e gli attributi propri dell’associazione

71  Ogni entità è tradotta con una relazione con gli stessi attributi La chiave primaria coincide con l’identificatore principale dell’entità Gli attributi composti vengono ricorsivamente suddivisi nelle loro componenti, oppure si mappano in un singolo attributo della relazione, il cui dominio va opportunamente definito Per brevità, usiamo l’asterisco (*) per indicare la possibilità di valori nulli Persona indirizzo via città n.civico (0,1) CAP nome cognome cod_fiscale Persona(CF, Cognome, Nome, Via, NCivico*,Città,CAP)

72 Progettazione Logica71 Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Matricola, Codice, DataInizio) Partecipazione (0,N) (1,N) Cognome Stipendio Matricola Impiegato Nome Codice Budget Progetto Data inizio Entità e relationship molti a molti

73 Progettazione Logica72 Nomi più espressivi per gli attributi della chiave della relazione che rappresenta la relationship Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Matricola, Codice, DataInizio)

74 Progettazione Logica73 Nomi più espressivi per gli attributi della chiave della relazione che rappresenta la relationship Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Impiegato, Progetto, DataInizio)

75 Progettazione Logica74 Composizione Prodotto CompostoComponente CostoNomeCodice (0,N) Prodotto(Codice, Nome, Costo) Composizione(Composto, Componente, Quantità) Relationship ricorsive Quantità

76 75 Nome FornitoreProdotto Dipartimento Fornitura Partita IVAGenereCodice Quantità Nome Telefono (0,N) (1,N) Relationship n-arie Fornitore(PartitaIVA, Nome) Prodotto(Codice, Genere) Dipartimento(Nome, Telefono) Fornitura(Fornitore, Prodotto, Dipartimento, Quantità)

77 Progettazione Logica76 Cognome GiocatoreSquadra Contratto Data nascita Città Nome Ingaggio (1,1) (0,N) Ruolo Colori sociali Relationship uno a molti Giocatore(Cognome, DataNascita, Ruolo) Squadra(Nome, Città, ColoriSociali) Contratto(CognGiocatore, DataNascG, Squadra, Ingaggio)

78 Progettazione Logica77 Soluzione più compatta Giocatore(Cognome, DataNascita, Ruolo) Contratto(CognGiocatore, DataNascG, Squadra, Ingaggio) Squadra(Nome, Città, ColoriSociali)  Giocatore e Contratto hanno la stessa chiave: possiamo fonderle in un’unica relazione Giocatore(Cognome, DataNasc, Ruolo, Squadra, Ingaggio) Squadra(Nome, Città, ColoriSociali)  con vincolo di integrità referenziale fra Squadra in Giocatore e la chiave di Squadra

79 Progettazione Logica78 Cognome GiocatoreSquadra Contratto Data nascita Città Nome Ingaggio (0,1) (0,N) Ruolo Colori sociali Osservazione se la cardinalità minima della relationship è 0, allora Squadra e Ingaggio in Giocatore devono ammettere valore nullo Giocatore(Cognome, DataNasc, Ruolo, Squadra*, Ingaggio*) Squadra(Nome, Città, ColoriSociali)

80 79 Associazioni ricorsive uno a molti  In questo caso è possibile operare una traduzione con 1 o 2 relazioni 1 relazione: Impiegato(Codice, Nome, Qualifica, Responsabile*) FK: Responsabile REFERENCES Impiegato 2 relazioni: Impiegato(Codice, Nome, Qualifica) Dipendenza(Dipendente, Responsabile) FK: Dipendente REFERENCES Impiegato FK: Responsabile REFERENCES Impiegato ResponsabileDipendente QualificaNomeCodice (0,N)(0,1) Dipendenza Impiegato

81 80 Iscrizione StudenteUniversità CognomeMatricola AnnoDiCorso Nome Indirizzo (1,1)(1,N) Città Entità con identificazione esterna Studente(Matricola, Università, Cognome, AnnoDiCorso) Università(Nome, Città, Indirizzo) l Nel caso di entità identificata esternamente, si “importa” l’identificatore della/e entità identificante/i. l L’associazione relativa risulta automaticamente tradotta

82 81 DirettoreDipartimento Direzione Cognome Codice SedeNome Data inizio (1,1) Stipendio Telefono Relationship uno a uno (1,1) – (1,1) Direttore (Codice, Cognome, Stipendio) Dipartimento (Nome, Sede, Telefono, Direttore, InizioD) Direttore (Codice, Cognome, Stipendio, InizioD, Dipartimento) Dipartimento (Nome, Sede, Telefono)

83 Progettazione Logica82 ImpiegatoDipartimento Direzione Cognome Codice SedeNome Data inizio (0,1) (1,1) Stipendio Telefono Relationship uno a uno (0,1) – (1,1) tradurre l’associazione Direzione inglobandola in Impiegato non è in generale una buona scelta (dipende dai volumi dei dati in gioco): troppi valori nulli!

84 Progettazione Logica83 Relationship uno a uno (0,1) – (1,1) Impiegato(Codice, Cognome, Stipendio, Dipartimento*, DataInizio*) Dipartimento(Nome, Sede, Telefono) ImpiegatoDipartimento Direzione Cognome Codice SedeNome Data inizio (0,1) (1,1) Stipendio Telefono

85 Progettazione Logica84 Soluzione: Impiegato (Codice, Cognome, Stipendio) Dipartimento (Nome, Sede, Telefono, Direttore, InizioD) con vincolo di integrità referenziale, senza valori nulli

86 85 ImpiegatoDipartimento Direzione Cognome Codice SedeNome Data inizio (0,1) Stipendio Telefono Relationship uno a uno (0,1) – (0,1) Per evitare la presenza di valori nulli nelle chiavi esterne: Impiegato (Codice, Cognome, Stipendio) Dipartimento (Nome, Sede, Telefono, Direttore) Direzione (Direttore, Dipartimento, DataInizio)

87 Progettazione Logica86 2 relazioni: Persona(CF, Nome) Matrimonio(Marito, Moglie) Marito Moglie Nome CF (0,1) Matrimonio Persona Un esempio particolare

88 (1,1) (0,1) (1,N) (0,1) (1,1) (1,N) (0,N) (1,N) Città Indirizzo Telefono Dipartimento Composizione Sede Direzione Afferenza Impiegato Progetto Partecipazione Nome Cognome Budget Data Via CAP Codice

89 l Per le entità E che partecipano ad associazioni sempre con max-card(E,R) = n la traduzione è immediata: Sede(Città, Via, CAP) Progetto(Nome, Budget) l Anche l’associazione Partecipazione si traduce immediatamente: Partecipazione(Impiegato, Progetto) l L’entità Dipartimento si traduce importando l’identificatore di Sede e inglobando l’associazione Direzione Dipartimento(Nome, Città, Telefono, Direttore) l Per tradurre l’associazione Afferenza, assumendo che siano pochi gli impiegati che non afferiscono a nessun dipartimento, si opta per una rappresentazione compatta Impiegato(Codice, Cognome, Dipart*,CittàDip* Data*)

90 Progettazione Logica 89 Esercizio 1 Corso_AA Docente responsabilità nome cognome data_nascita (0,n)(1,1) cod_doc AAciclo Corso attivato (1,1) (0,n) cod_corso nome data FA_VISITA ( 1, 1 ) ( 0, N ) IN_VISITA ( 0, N ) ( 1, 1 ) MEDICO VISITA PAZIENTE esito nome cognome telefono cod_med nome cognome data_nascita cod_paziente

91 Progettazione Logica90 Esercizio 2 GIOCATORI(n_giocatore, cognome, iniziali, data_nascita, sesso, iscritto_dal, indirizzo, numero, cap, citta, telefono, n_socio) SQUADRE(n_squadra, n_giocatore, categoria) PARTITE(n_partita, n_squadra, n_giocatore, vittorie, sconfitte) PENALITA(n_pagamento, n_giocatore, data_pagamento, importo) MEMBRI_COMMISSIONE(n_giocatore, data_inizio, data_fine, carica) Trovare lo schema ER che dà luogo al seguente schema relazionale:


Scaricare ppt "Progettazione Logica 1 Progettazione logica I.Analisi delle prestazioni su schemi E-R II.Ristrutturazione di schemi E-R III.Traduzione verso il modello."

Presentazioni simili


Annunci Google