Progettazione logica Analisi delle prestazioni su schemi E-R

Presentazione sul tema: "Progettazione logica Analisi delle prestazioni su schemi E-R"— Transcript della presentazione:

1 Progettazione logica Analisi delle prestazioni su schemi E-R
Ristrutturazione di schemi E-R Traduzione verso il modello relazionale Progettazione Logica

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

3 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 Progettazione Logica

4 Dati di ingresso e uscita
schema concettuale informazioni sul carico applicativo modello logico Uscita: schema logico documentazione associata Progettazione Logica

5 Non si tratta di una pura e semplice traduzione
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 Progettazione Logica

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

7 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 Progettazione Logica

8 Analisi delle prestazioni su schemi E-R
Per ottimizzare il risultato abbiamo bisogno di analizzare le prestazioni a questo livello 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 Progettazione Logica

9 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 Progettazione Logica

10 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) Progettazione Logica

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

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

13 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 Progettazione Logica

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

15 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 Progettazione Logica

16 Tavola delle operazioni
Progettazione Logica

17 Regola 80-20 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) Progettazione Logica

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

19 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 Progettazione Logica

20 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 Progettazione Logica

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

22 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 Progettazione Logica

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

24 Forme di ridondanza in uno schema E-R
attributi derivabili: 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 cicli Progettazione Logica

25 Attributo derivabile Importo netto Fattura IVA Importo lordo
Progettazione Logica

26 Attributo derivabile da altra entità
Importo totale Composizione Acquisto Prodotto Prezzo (1,N) Importo totale è ottenibile con operazioni di aggregazione Progettazione Logica

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

28 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 Progettazione Logica

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

30 tavola dei volumi 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) Progettazione Logica

31 Presenza di ridondanza
Operazione 1 Operazione 2 Progettazione Logica

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

33 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 Progettazione Logica

34 Assenza di ridondanza Costi: Contiamo doppi gli accessi in scrittura
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 Progettazione Logica

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

36 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 Progettazione Logica

37 Tre possibilità accorpamento delle figlie della generalizzazione nel genitore accorpamento del genitore della generalizzazione nelle figlie sostituzione della generalizzazione con relazioni Progettazione Logica

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

39 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 Progettazione Logica

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

41 Esempio 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) Studente Laureando Diplomando Matr. Nome Tit.Stage Tit.Tesi Matr Relatore Denom. Azienda (1,1) (p,e) (1,n)

42 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 Progettazione Logica

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

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à

45 Collasso verso il basso

46 Esempio Dipendente Impiegato Operaio CF Nome macchine capacità
Dirigente n_sottoposti Sindacato Contribuisce 0,1 1,n Dirige Impiegato Operaio macchine capacità Dirigente n_sottoposti Sindacato Contr_I 0,1 0,n 1,n CF Nome Contr_D Contr_O Dir_D Dir_O Dir_I

47 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 Progettazione Logica

48 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 Progettazione Logica

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

50 Esempio Progetto Prog_sw Prog_hw Cod Desc N_schede Mesi uomo Comp_hw
usa 1,n 0,n Progetto Prog_sw Prog_hw Cod Desc N_schede Mesi uomo Comp_hw usa 1,n 0,n 0,1 1,1

51 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 Progettazione Logica

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

53 gli accessi si riducono:
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; Progettazione Logica

54 Ristrutturazioni, casi principali
partizionamento orizzontale/verticale di entità eliminazione di attributi multivalore accorpamento di entità/ relationship Progettazione Logica

55 Partizionamento verticale
di entità Impiegato Livello Stipendio Ritenute Cognome Indirizzo Data nascita Codice Progettazione Logica

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

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

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

59 Eliminazione di attributi multivalore
Agenzia Indirizzo Città Telefono Nome (1,3) Se la cardinalità massima K è nota: è possibile prevedere K repliche degli attributi Tel2 Tel1 Tel3 Nome Agenzia Indirizzo Città Progettazione Logica

60 Accorpamento di Entità
Codice fiscale Cognome Interno Indirizzo (0,1) (1,1) Intestazione Persona Appartamento Data nascita Indirizzo Progettazione Logica

61 Persona Data nascita Codice fiscale (0,1)
Interno Indirizzo Cognome Data nascita Codice fiscale (0,1) Progettazione Logica

62 Partizionamento orizzontale di associazioni
(0,1) Cognome Composizione Giocatore Squadra (1,N) Ruolo Nome Città Data acquisto Data cessione Cognome Comp. passata Giocatore Squadra (0,N) (1,N) Ruolo Nome Città Data acquisto Data cessione attuale (1,1)

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

64 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 Progettazione Logica

65 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 Progettazione Logica

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

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 Data nascita Codice fiscale (0,1) Codice SSN Persona

68 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 Progettazione Logica

69 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 Progettazione Logica

70 Persona(CF, Cognome, Nome, Via, NCivico*,Città,CAP)
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)

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

72 Impiegato(Matricola, Cognome, Stipendio)
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) Progettazione Logica

73 Impiegato(Matricola, Cognome, Stipendio)
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) Progettazione Logica

74 Relationship ricorsive
Quantità (0,N) Composizione (0,N) Composto Componente Prodotto Costo Nome Codice Prodotto(Codice, Nome, Costo) Composizione(Composto, Componente, Quantità) Progettazione Logica

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

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

77 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) con vincolo di integrità referenziale fra Squadra in Giocatore e la chiave di Squadra Progettazione Logica

78 Osservazione Cognome Giocatore Squadra Contratto Data nascita Città Nome Ingaggio (0,1) (0,N) Ruolo Colori sociali 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) Progettazione Logica

79 Associazioni ricorsive uno a molti
Responsabile Dipendente Qualifica Nome Codice (0,N) (0,1) Dipendenza Impiegato 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

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

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

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

83 Relationship uno a uno (0,1) – (1,1)
Impiegato Dipartimento Direzione Cognome Codice Sede Nome Data inizio (0,1) (1,1) Stipendio Telefono Impiegato(Codice, Cognome, Stipendio, Dipartimento*, DataInizio*) Dipartimento(Nome, Sede, Telefono) Progettazione Logica

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

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

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

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

88 Progetto(Nome, Budget)
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) Anche l’associazione Partecipazione si traduce immediatamente: Partecipazione(Impiegato, Progetto) L’entità Dipartimento si traduce importando l’identificatore di Sede e inglobando l’associazione Direzione Dipartimento(Nome, Città, Telefono, Direttore) 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*)

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

90 Esercizio 2 Trovare lo schema ER che dà luogo al seguente schema relazionale: 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) Progettazione Logica