Vendita all ingrosso di piante

Transcript

1 Progetto Concettuale Dall analisi dei requisiti al al diagramma ER ESEMPI Vendita all ingrosso di piante Si vuole rappresentare una base dati per la gestione della vendita all ingrosso di piante, tenendo conto delle seguenti informazioni: Sono trattate diverse specie di piante. Per ciascuna specie sono noti sia il nome latino che il nome comune, ed un codice univoco attraverso cui la specie viene identificata. Per ciascuna specie è inoltre noto se sia tipicamente da giardino o da appartamento e se sia una specie esotica o no. Le piante possono essere verdi oppure fiorite. Nel caso di specie di piante fiorite, sono note tutte le colorazioni in cui ciascuna specie è disponibile. I clienti sono identificati attraverso un codice cliente e sono costituiti da privati e da rivendite. Per ciascun privato sono noti il codice fiscale, il nome e l indirizzo della persona, mentre per ogni rivendita sono noti la partita iva, il nome e l indirizzo della rivendita. I fornitori sono identificati attraverso un codice fornitore; per ciascun fornitore sono inoltre noti il nome, il codice fiscale e l indirizzo. Il fornitore può fornire diverse specie di piante. Tuttavia le piante della stessa specie sono acquistate sempre da uno stesso fornitore. Si vuole tener traccia di tutti gli acquisti eseguiti da ciascun cliente. Un acquisto, effettuato in una data specifica, è relativo a una certa quantità di piante appartenenti ad una determinata specie. Il listino prezzi, in cui si vuole tener traccia dei prezzi assunti nel tempo da ciascuna specie di piante.

2 Diagramma ER Gestione delle piscine comunali di Torino Si vuole rappresentare una base dati contenete le informazioni relative alle piscine gestite del comune di Torino, tenendo conto delle seguenti informazioni: Le piscine sono identificate univocamente attraverso il nome (ad esempio Vigone, Comunale, Trecate, ecc). Per ciascuna sono inoltre noti l'indirizzo, un numero di telefono, ed il nome di un responsabile. Nel caso la piscina disponga anche di una vasca all'aperto, la base dati contiene l'informazione di quando tale vasca è utilizzabile (ad esempio da Marzo a Settembre, da Luglio ad Agosto, ecc.) Presso le piscine sono organizzati dei corsi; lo stesso tipo di corso può essere svolto presso piscine diverse, eventualmente con modalità differenti. Ciascun corso è pertanto identificato dal nome dell'attività svolta, quali Aerobica, Acquagym, Corso di Sincronizzato o corso per Gestanti, e dal nome della Piscina presso cui tale corso si svolge. Per ciascun corso, svolto presso una certa piscina, è noto il costo, il numero massimo e minimo di partecipanti, in quali giorni della settimana si svolge ed a che ora. Si ipotizzi che presso ciascuna piscina ogni corso sia svolto una sola volta al giorno, ma più volte durante la settimana. Il corpo insegnante lavora a rotazione presso le varie piscine. Per ciascun insegnante è noto il codice fiscale, che lo identifica, un nome, il numero di cellulare, se disponibile, e l'elenco delle qualifiche dell'insegnante (ad esempio istruttore di sub, istruttore di aerobica, ecc). All'interno della base dati si vuole tener traccia di tutti gli intervalli di tempo in cui un insegnante ha lavorato presso ciascuna piscina. Non si escluda che lo stesso insegnante possa aver lavorato presso una stessa piscina in intervalli di tempo diversi. Le piscine possono essere frequentate o da persone che sono iscritte ai corsi, o secondo la modalità ad ``ingresso singolo'' per svolgere nuoto libero (si noti che sono registrate per l'ingresso singolo solo le persone che non hanno mai frequentato corsi). Tutte le persone che accedono alle piscine comunali sono identificate attraverso il loro codice fiscale ed inoltre sono noti il nome, un indirizzo ed un numero di telefono. Le persone che sono iscritte ai corsi devono presentare un certificato medico. Pertanto, nel caso la persona sia iscritta ad un corso, il database contiene l'informazione del medico che ha redatto il certificato, la data in cui la persona ha presentato il certificato, l'età della persona, e l'elenco dei corsi a cui è iscritta. Per le persone che hanno fatto solo ingressi sono noti solo la data in cui è stato effettuato l'ultimo ingresso e presso quale piscina.

3 Diagramma ER Diagramma ER Rappresentazione alternativa della relazione LEZIONE

4 Diagramma ER Rappresentazione alternativa della relazione ROTAZIONE Noleggio di videocassette Si vuole rappresentare una base dati per la gestione di una catena di centri di servizio per il noleggio delle videocassette, tenendo conto delle seguenti informazioni: Ogni centro di servizio è identificato attraverso un codice numerico univoco; inoltre viene riportato l indirizzo del centro ed il numero di telefono. La base dati contiene le informazioni relative a tutte le persone impiegate presso la catena. Per ciascun impiegato sono noti il codice fiscale, il nome, il titolo di studio ed un recapito. Il codice fiscale permette di identificare univocamente l impiegato all interno della base dati. Gli impiegati possono essere spostati da un centro all altro a seconda delle esigenze; si vuole pertanto tenere traccia di tutti gli intervalli di tempo in cui un impiegato ha prestato servizio presso un centro e della carica che ha rivestito in quel periodo (per esempio, cassiere o commesso). I film disponibili presso la catena sono identificati dal titolo e dal nome del regista; inoltre sono noti l anno in cui il film è stato girato, l elenco degli attori principali del film, il costo corrente di noleggio della videocassetta ed eventualmente i film disponibili presso la catena di cui il film in questione rappresenta la versione remake. Per ogni film è nota la collocazione all interno di ciascun centro di servizio. In particolare, sono noti il settore, la posizione all interno del settore ed il numero di copie in cui il film è disponibile. Ciascun settore è identificato attraverso un codice numerico univoco all interno del centro di servizi e dal codice del centro di servizio stesso. Per ogni film sono noti i centri di distribuzione da cui è fornito ed il costo relativo. Tali centri di distribuzione sono caratterizzati dal nome del centro di distribuzione, da un recapito e sono identificati attraverso un codice numerico.

5 Diagramma ER Prenotazioni esami in una ASL Si vuole rappresentare una base dati per la gestione di un sistema di prenotazioni di esami medici all interno di una Azienda Sanitaria Locale (ASL), tenendo conto delle seguenti informazioni: Ciascun paziente è identificato da un codice di tessera sanitaria ed è caratterizzato da un nome, un cognome, l indirizzo, la data ed il luogo di nascita. Gli esami medici che possono essere eseguiti sono identificati da un codice numerico e sono caratterizzati dalla descrizione di esame medico (ad esempio Radiografia, ecc.). Gli ospedali della ASL sono identificati da un codice numerico e sono caratterizzati da un nome e un indirizzo. I laboratori che eseguono gli esami sono identificati da un codice univoco all interno di un ospedale della ASL e sono caratterizzati dal nome del laboratorio, dal piano di ubicazione e dal numero di stanza. Per ogni prenotazione di un esame da parte di un paziente si vuole memorizzare la data e l ora dell esame, il laboratorio presso cui è eseguito, il costo del ticket e se tale esame è prescritto con urgenza. Si tenga presente che ogni paziente può effettuare più prenotazioni dello stesso esame in date diverse. Si noti inoltre che lo stesso esame non può essere ripetuto nello stesso giorno dallo stesso paziente. Ogni ospedale è suddiviso in reparti identificati da un codice numerico univoco all interno dell ospedale di appartenenza e caratterizzati dal nome del reparto e da un numero di telefono. Il personale del reparto è identificato attraverso il codice fiscale; sono noti inoltre il nome, il cognome e l indirizzo di domicilio. Tra il personale, nel caso dei medici primari del reparto è noto l elenco delle specializzazioni, mentre per il personale volontario è noto il nome dell associazione di appartenenza, se disponibile.

6 Diagramma ER Gestione di una farmacia Si vuole rappresentare una base dati per la gestione dei prodotti disponibili in una farmacia tenendo conto delle seguenti informazioni: Ciascun prodotto è caratterizzato univocamente dal nome del prodotto stesso e dall informazione relativa alla ditta fornitrice del prodotto. I prodotti presenti nella farmacia possono essere medicinali oppure prodotti di profumeria. Per ciascun prodotto è comunque noto l elenco degli usi possibili del prodotto stesso (ad esempio malattie da raffreddamento, dolori alle ossa, oppure detergente per il viso o per il corpo). Della ditta fornitrice sono invece noti un recapito, il nome, utilizzato per identificare la ditta stessa, ed eventualmente il numero di fax se disponibile. Nel caso dei medicinali, la base dati contiene l informazione relativa al fatto che un medicinale sia mutuabile o no, e se la vendita sia effettuabile solo se viene presentata una ricetta medica. Inoltre è nota la categoria farmacoterapeutica di appartenenza del medicinale (ad esempio antibiotico, oppure anti-infiammatorio) e se esistono interazioni tra quella categoria farmacoterapeutica ed altre categorie farmacoterapeutiche. I medicinali sono contenuti in cassetti, contenuti a loro volta in scaffali. Gli scaffali sono identificati da un codice numerico univoco per ciascuna categoria farmacoterapeutica ed i cassetti da un codice numerico univoco per ciascuno scaffale. Nel caso infine di medicinali che richiedano la ricetta medica, si vuole tener traccia di ogni vendita effettuata per quel medicinale, indicando il giorno, la quantità ed il nome del medico che ha fatto la prescrizione.

7 Diagramma ER Corsi di lingua inglese Si progetti una base dati per la gestione dei corsi di lingua inglese, tenuti presso un instituto di insegnamento. Tutte le informazioni fanno riferimento ad un solo anno scolastico in corso, e non viene richiesto di mantenere le informazioni relative agli anni scolastici precedenti. La base dati deve contenere le seguenti informazioni: I corsi sono organizzati per livelli. Ciascun livello è identificato dal nome del livello stesso (ad esempio Elementary, Intermediate, First Certificate, Advanced, Proficiency); inoltre è specificato il nome del libro di testo e se viene richiesto di sostenere un esame finale. I corsi sono identificati univocamente dal nome del livello cui afferiscono e da un codice progressivo, necessario per distinguere corsi che fanno riferimento allo stesso livello. Per ciascun corso sono note la data di attivazione, il numero di iscritti e l elenco dei giorni in cui è tenuto. Per gli insegnanti sono noti il nome, l indirizzo, la nazione di provenienza, ed i corsi a cui sono stati assegnati. Si assuma che a ciascun corso sia assegnato un unico insegnante. Per gli allievi sono noti il nome, un recapito, il corso a cui sono iscritti, la data di iscrizione al corso e il numero di assenze fatte finora. Gli allievi possono anche prenotare lezioni private, qualora vogliano approfondire alcuni aspetti della lingua inglese. Si vuole tener traccia di tutte le lezioni private eventualmente richieste da un allievo, in quale data e con quale insegnante. La scuola organizza poi un insieme di attività culturali. Ciascuna attività è identificata da un codice progressivo, e sono noti il giorno e l ora in cui verrà tenuta. Nel caso di proiezioni in lingua originale, sono noti il nome del film ed il nome del regista. Nel caso di conferenze, sono noti l argomento che verrà trattato ed il nome del conferenziere. Per poter partecipare alle attività gli allievi devono iscriversi.

8 Diagramma ER Campionato Europeo edizione 2000 Si vuole rappresentare una base dati per la gestione delle partite di calcio svolte nell'ambito del Campionato Europeo edizione 2000, tenendo conto delle seguenti informazioni: Le squadre che partecipano agli Europei di calcio sono identificate univocamente dal nome della nazione di appartenenza (ad esempio Italia, Romania, Inghilterra, ecc.). Per ogni squadra è noto il nome dell'attuale allenatore e l'elenco delle precedenti edizioni degli europei vinte dalla squadra stessa. Inoltre per ogni squadra è noto il nome di un fan club se disponibile. Gli Europei sono organizzati in turni di gioco. Ciascun turno è identificato univocamente dal nome del turno stesso, (esempio: ``qualificazione'', ``quarti'', ``semifinale'' e ``finale''). La base di dati contiene l'elenco delle squadre che prendono parte a ciascun turno di gioco. Le partite di calcio sono identificate attraverso un numero d'ordine univoco all'interno di ciascun turno di gioco. Per ogni partita sono noti i nomi delle due squadre coinvolte, dove si gioca l'incontro (Amsterdam, Bruxelles, Rotterdam o Bruges) ed a che ora. I giocatori sono identificati univocamente dal nome. Per ciascuno è inoltre nota la squadra in cui gioca negli europei, e con quale numero di maglia. Per ogni giocatore è ancora noto un recapito. Per ciascuno dei giocatori che ha segnato, si vuole memorizzare nella base di dati, per ogni partita giocata, il minuto di gioco in cui tale giocatore ha segnato un goal, e se questo è avvenuto su rigore. Infine la base di dati contiene l'informazione relativa a quale arbitro è stato assegnato a ciascuna partita. Per ogni arbitro è noto il nome, che lo identifica univocamente, un recapito, ed il numero complessivo di presenze agli europei.

9 Diagramma ER Progetto Logico per il il Modello Relazionale

10 Progetto logico da diagrammi ER Gli schemi ER descritti in precedenza sono in grado di descrivere un dominio applicativo ad un dato livello di astrazione, fornendo così una descrizione sintetica e visiva e permettendo di scambiare informazioni tra i vari componenti del gruppo di progetto. Anche la semantica dell applicazione è fornita in gran parte dagli schemi ER, che però non vengono utilizzati direttamente da nessun DBMS in commercio. Progetto logico da diagrammi ER Quest ultima limitazione impedisce l uso diretto degli schemi ER, e impone la traduzione di tali schemi in altri schemi di dati, in questo caso gli schemi logico relazionali visti nella prima parte del corso.

11 Le fasi di progetto Dunque i passi da compiere per effettuare il progetto completo di una base di dati sono: raccolta dei requisiti relativi al dominio applicativo desiderato (per lo più in linguaggio naturale); progettazione concettuale; produce i diagrammi ER progettazione logica; produce uno schema logico relazionale del tipo descritto nei lucidi del Prof. Ceri nella prima parte del corso; viene anche prodotto il codice SQL, limitatamente al codice di tipo DDL (definizione delle tabelle); utilizzo effettivo del DBMS tramite l uso combinato di DDL e DML al fine di produrre le applicazioni necessarie in azienda. Il progetto logico L unico passaggio ancora da illustrare è quello tra il secondo ed il terzo punto, cioè il passaggio dagli schemi E/R agli schemi logico relazionali. In particolare il progetto logico, dato lo schema E/R, presenta in generale una soluzione standard determinabile in modo semplice e diretto. Sono tuttavia talvolta presenti soluzioni alternative.

12 Il progetto logico Per determinare l alternativa più opportuna è bene considerare che: le proprietà logiche hanno la precedenza rispetto ai motivi di efficienza; è bene mantenere sulla stessa entità informazioni che verranno consultate frequentemente assieme; è bene tenere su entità separate informazioni che verranno consultate separatamente; è bene limitare quanto più possibile l incidenza di valori nulli in attributi opzionali. Trasformazione da schema ER a modello relazionale Risultato: schema relazionale normalizzato SCHEMA ER passo A A Schema ER semplificato passo B 3 fasi B Set di relazioni (modello relazionale) 2 fasi

13 Passo di semplificazione dello schema ER 1) Eliminazione delle gerarchie di generalizzazione (IS-A) 2) Selezione delle chiavi primarie ed eliminazione degli identificatori esterni 3) Eliminazione degli attributi multivalore e composti Schema ER semplificato Dopo le prime tre fasi lo schema E/R è costituito solo più da entità, relazioni e attributi semplici. La quarta fase non pone problemi, mentre la quinta e ultima fase richiede molta attenzione. Siccome ciascuna di queste fasi impoverisce lo schema, la semantica persa deve essere recuperata sotto forma di vincoli di integrità.

14 Passo di traduzione nel modello relazionale 4) Traduzione di ogni entità in una relazione e di tutte le associazioni in schemi di relazioni le relazioni 1:1, 1:molti, molti:1 sono modellate aggiungendo attributi a relazioni esistenti le relazioni molti:molti richiedono sempre la creazione di una nuova relazione (tabella) 5) Verifica di normalizzazione Eliminazione delle gerarchie di generalizzazione (IS-A) Poiché il modello relazionale non rappresenta le gerarchie, queste ultime devono essere sostituite da entità e relazioni. Data la gerarchia di esempio riportata in figura: si hanno tre possibilità.

15 Eliminazione delle gerarchie di generalizzazione (IS-A) 1) Collassamento delle sottoclassi nella superclasse (verso l alto) 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. Collassamento verso l alto Tutte le entità figlie vengono riunite nell entità padre, aggiungendo un attributo selettore per specificare a quale delle sottoentità appartiene l istanza di E; gli attributi A1 e A2 diventano opzionali, in quanto non significativi per tutte le istanze di E.

16 STUDENTE (p,e) Esempio C_FISC NOME CORSO_DI_STUDI TUTORE(0,1) GRADO (0,1) TITOLO_TESI (0,1) STUDENTE C_FISC NOME CORSO_DI_ STUDI LAUREANDO UNIVERSITARIO (1,1) TITOLO_ TESI HA_ RELATORE SOCIO_ DI (0,1) TUTORE (0,1) HA_ RELATORE (0,1) SOCIO_ DI (1,n) (1,n) (1,n) (1,n) FACOLTA` ASSOCIAZIONE_ STUDENTESCA FACOLTA` ASSOCIAZIONE_ STUDENTESCA Collassamento verso l alto Il collasso verso l alto favorisce le operazioni che consultano insieme gli attributi dell entità padre e quelli di una entità figlia; in tal caso si accede infatti a una sola entità, anziché a due tramite una associazione, e serviranno meno operazioni di join. Si avrà peraltro una certa percentuale di valori nulli tra gli attributi, dal momento che gli attributi obbligatori per le entità figlie divengono opzionali per il padre.

17 Collassamento verso l alto Se la copertura della ISA è totale esclusiva il selettore ha tanti valori (N) quante sono le sottoentità. Se è parziale esclusiva il selettore ha N+1 valori, e il valore in più serve per le istanze che non appartengono ad alcuna sottoentità. Se la copertura non è esclusiva occorrono tanti selettori booleani quante sono le sottoentità (l i-esimo selettore è a TRUE per ogni istanza di E che appartiene all i-esima sottoentità), e se è anche parziale i selettori possono essere anche tutti a FALSE. Le relazioni connesse alle sottoentità si trasportano su E, e le card. minime diventano 0. Collassamento verso il basso Si elimina l entità padre trasferendone gli attributi su tutte le entità figlie. Un associazione del padre è replicata tante volte quante sono le entità figlie. Se però la copertura non è totale non si può fare (dove mettere gli E che non sono né E1 né E2?), e se la copertura non è esclusiva si introduce ridondanza.

18 Esempio C_FISC NOME IMPIEGATO (0,1) PAGA_ (1,1) CONTR CONTRIBUTI (t,e) DIRETTO_DA SEGRETARIO INGEGNERE MANAGER (0,m) CAPACITA` (1,n) USA SPECIALIZZAZIONE NUM_SOTTOPOSTI (0,n) WORD_PROCESSOR Rappresentazione di gerarchie di generalizzazione mediante sottoclassi CONTR_1 USA (0,1) (0,1) (0,1) C_FISC C_FISC NOME SEGRETARIO INGEGNERE NOME CAPACITÀ (1,n (0,m) ) SPECIALIZ (1,1) CONTR_2 C_FISC NOME DIRIGE_1 (0,1) MANAGER (1,n) CONTRIBUTI NUM_SOTTOPOSTI (0,1) (0,1) CONTR_3 DIRIGE_3 (0,1) (1,n) (0,n) (1,1) DIRIGE_2 (1,n) WORD_PROCESSOR

19 Collassamento verso il basso Il collassamento verso il basso è una soluzione interessante in presenza di molti attributi di specializzazione, in quanto con il collasso verso l alto si avrebbe un eccesso di valori nulli. Sono così anche favorite le operazioni in cui si accede separatamente alle entità figlie. Mantenimento delle entità Nel caso del mantenimento delle entità con relazioni tutte le entità vengono mantenute; le entità figlie sono in associazione con l entità padre, e sono identificate esternamente (ricordo che qui viene utilizzata la convenzione usata in BDD per gli identificatori esterni) tramite l associazione.

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

21 Eliminazione di identificatori esterni Gli identificatori esterni sono trasformati in identificatori interni. E1 ID A E1 B A (1,1) R E2 (1,n) B E2 B Selezione delle chiavi primarie Tra i diversi identificatori di una entità deve essere designata una chiave primaria, affinché il DBMS possa provvedere al controllo dell unicità dei valori. È opportuno scegliere la chiave più frequentemente usata per accedere all entità, e si devono preferire chiavi semplici a chiavi composte e chiavi interne a chiavi esterne.

22 Eliminazione degli identificatori esterni Qualora due entità siano legate da una relazione e si abbia una chiave esterna, si può eliminare la relazione a patto di trasferire la chiave primaria dell entità priva di chiave esterna come attributo sull entità precedentemente dotata di identificatore esterno (attributo esterno che in tal modo scompare). In presenza di più identificazioni in cascata, è necessario iniziare la propagazione dall entità che non ha identificazioni esterne. Esempio UNIVERSITÀ CODICE UNIVERSITÀ NOME CITTÀ ISCRIVE STUDENTE MATRICOLA_STUDENTE COGNOME ETÀ (a) Schema iniziale

23 Esempio UNIVERSITÀ CODICE UNIVERSITÀ NOME CITTÀ + STUDENTE CODICE UNIVERSITÀ MATRICOLA_STUDENTE COGNOME ETÀ (b) Schema finale Eliminazione di identificatori esterni E1 A A E1 R1 ID1 E2 B E2 A B R2 E3 C E3 ID2 A B C

24 Eliminazione di attributi composti Le relazioni non possono per definizione contenere attributi composti o ripetuti, ma solamente attributi atomici. Nel caso di attributi composti (es. indirizzo composto da via, numero e città) si può scomporre l attributo e considerare i suoi componenti come attributi semplici (in tal modo si perde la visione unitaria, ma si mantiene l articolazione dei componenti), oppure eliminare i componenti e considerare il solo attributo semplice indirizzo (perdendo così parte dei dettagli, ma semplificando lo schema). 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

25 Esempio PERSONA COGNOME ETA` SESSO INDIRIZZO VIA CITTA` (a) Schema con un attributo composto STATO PERSONA COGNOME ETA` SESSO VIA CITTA` STATO (b) Attributo composto ridotto nelle sue componenti PERSONA COGNOME ETA` SESSO INDIRIZZO (c) Attributo composto considerato come attributo singolo Eliminazione di attributi multivalore dalle entità Gli attributi ripetuti, cioè gli attributi multivalore (con cardinalità variabile, per es. (1,n)) vanno eliminati come nell esempio riportato.

26 Eliminazione di attributi multivalore dalle entità Si noti che la traduzione non è corretta qualora esista il caso di un locale appartenente a più agenzie (con Nome diverso) con un gruppo di numeri telefonici in comune. In tal caso la traduzione, per essere corretta, dovrebbe essere completata da una identificazione esterna posta sull'entità TELEFONO (per garantire l'univocità del telefono nell'ambito dell'agenzia); oppure la cardinalità sul lato TELEFONO dovrebbe essere (1,n). La traduzione riportata in figura è dunque corretta se si suppone che un telefono possa essere di una sola agenzia (cosa del resto assai logica nella pratica). Eliminazione di attributi multivalore dalle entità La strategia corretta (in generale) per la traduzione degli attributi multivalore è dunque quella di partire sempre dalla figura riportata e di decidere caso per caso se la cardinalità sul lato dell'entità aggiunta (in questo caso TELEFONO) deve essere (1,1) oppure (1,n). La scelta dell'(1,1) o dell'(1,n) va poi giustificata in sede di esame. L'uso dell'identificazione esterna sul lato TELEFONO, che corrisponderebbe all'uso della cardinalità (1,n), è comunque fortemente sconsigliato; utilizzare direttamente la cardinalità (1,n).

27 Eliminazione di 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. Attributi multivalore di entità E1 A B (1,n) A E1 R EAM B A E1 EAM A B

28 Esempio PRODOTTO CODICE_PRODOTTO CODICE_MATERIALE (1,n) DESCRIZIONE PREZZO PRODOTTO CODICE_PRODOTTO DESCRIZIONE PREZZO PRODOTTO_MATERIALE CODICE_PRODOTTO CODICE_MATERIALE Traduzione di entità e associazioni in schemi di relazioni Ogni entità è tradotta con una relazione (notare che qui relazione significa tabella e non associazione) con gli stessi attributi, e la chiave è la chiave dell entità stessa. Ogni associazione è tradotta con una relazione (tabella) con gli stessi attributi, cui si aggiungono gli identificatori di tutte le entità che essa collega (la chiave dell associazione è composta dalle chiavi delle entità collegate).

29 Traduzione di entità Entità = Relazione * (ovvero Tabella) * secondo il modello relazionale IMPIEGATO SSN NOME COGNOME SALARIO IMPIEGATO (SSN, NOME, COGNOME, SALARIO) Esempio

30 Traduzione di entità e associazioni in schemi di relazioni Il progetto logico, cioè la trasformazione degli schemi E/R in relazioni (tabelle), presenta in generale una soluzione standard, anche se sono possibili soluzioni alternative. Per le associazioni N a M la traduzione standard è l unica possibile, mentre per i casi 1 a 1 e 1 a N sono possibili altre forme di traduzione, che danno origine a un minor numero di relazioni (tabelle) (riducendo così il numero di join), ma penalizzano le consultazioni sui soli attributi delle entità che sono state fuse. Traduzione delle relazioni molti a molti Non dipende dalla cardinalità minima. K1 A1 B1 (0,n) (0,n) E1 R E2 K2 A2 B2 AR BR E1(K1,A1,B1) R(K1,K2,AR,BR) E2(K2,A2,B2)

31 Esempio STUDENTE (1,n) ISCRITTO_ A MATRICOLA_STUDENTE COGNOME GPA SEMESTRE VOTO (1,n) CORSO NUMERO_CORSO NOME_CORSO STUDENTE (NUMERO_STUDENTE, COGNOME, GPA) CORSO (NUMERO_CORSO, NOME_CORSO) ISCRITTO_A (MATRICOLA_STUDENTE, NUMERO_CORSO, SEMESTRE, VOTO) Traduzione delle relazioni 1-1 e 1-molti Vediamo dunque i casi in cui le cardinalità valgono (1,1) oppure (1,n).

32 Traduzione di relazioni 1-1 Si considera la cardinalità minima. Una sola relazione, se la partecipazione di entrambe le entità è totale: card min = 1, card max = 1 Scelta della chiave primaria: le due entità hanno la stessa chiave primaria si sceglie quella chiave primaria le due entità hanno chiavi primarie diverse si sceglie una delle due chiavi primarie Traduzione di relazioni 1-1 E sufficiente una sola relazione (tabella) K1 A1 B1 (1,1) (1,1) E1 R E2 K2 A2 B2 AR BR E12(K1,A1,B1,K2,A2,B2,AR,BR) oppure E12(K1,A1,B1,K2,A2,B2,AR,BR) La chiave in questo caso può essere indifferentemente K1 o K2.

33 Traduzione di relazioni 1-1 Ma è possibile anche utilizzare due relazioni K1 A1 B1 (1,1) (1,1) E1 R E2 K2 A2 B2 AR BR E1(K1,A1,B1) + E2(K2,A2,B2,K1,AR,BR) compattando l associazione su una delle due entità (in questo caso E2) Traduzione di relazioni 1-1 Relazioni separate, se una o entrambe le entità hanno partecipazione parziale nella relazione: card min = 0, card max = 1 un entità con partecipazione parziale tre relazioni separate, oppure una sola relazione scegliendo opportunamente la chiave (quella del lato (0,1)) entrambe le entità con partecipazione parziale tre relazioni separate

34 Traduzione di relazioni 1-1 La chiave sarà K2 (ci saranno infatti dei valori nulli in corrispondenza di K1, il che rende K1 non utilizzabile come chiave). K1 A1 B1 (1,1) (0,1) E1 R E2 K2 A2 B2 AR BR E12(K1,A1,B1,K2,A2,B2,AR,BR) Traduzione di relazioni 1-1 Con tre relazioni K1 A1 B1 (0,1) (1,1) E1 R E2 K2 A2 B2 AR BR E1(K1,A1,B1) E2(K2,A2,B2) R(K1,K2,AR,BR)

35 Traduzione di relazioni 1-1 Con tre relazioni K1 A1 B1 (0,1) (0,1) E1 R E2 K2 A2 B2 AR BR E1(K1,A1,B1) E2(K2,A2,B2) R(K1,K2,AR,BR) La chiave di R può essere K1 o K2 Esempio CLIENTE (1,1) (1,1) CON INDIRIZZO_SPED NUM_CLIENTE NOME_CLIENTE NUM_CLIENTE INDIRIZZO_SPED SPEDIZ_CLIENTE (NUM_CLIENTE, NOME_CLIENTE, INDIRIZZO_SPED) (a) una sola relazione

36 Esempio CLIENTE (0,1) (1,1) POSSIEDE CARTA_CREDITO LIMITE_ CREDITO NUM_CLIENTE NOME_CLIENTE TIPO_CARTA NUM_CARTA CLIENTE (NUM_CLIENTE,NOME_CLIENTE) CARTA_CREDITO (TIPO_CARTA, NUM_CARTA, LIMITE_CREDITO) POSSIEDE_CARTA (TIPO_CARTA,NUM_CARTA,NUM_CLIENTE) (b) Relazioni separate; un entità ha partecipazione parziale Esempio MASCHIO (0,1) (0,1) SPOSA FEMMINA MASCHIO_SSN NOME DATA DURATA NOME FEMMINA_SSN MASCHIO (MASCHIO_SSN, NOME) FEMMINA (FEMMINA_SSN, NOME) SPOSA (MASCHIO_SSN, FEMMINA_SSN, DATA, DURATA) (b) Relazioni separate; entrambe le entità hanno partecipazioni parziali

37 Traduzione di relazioni 1 a molti K1 A1 B1 (1,1) (1,n) E1 R E2 K2 A2 B2 AR BR Se E1 partecipa completamente, inclusione dell identificatore di E2 (e degli attributi della relazione) in E1. E1 può cioè essere fusa con l associazione E1(K1,A1,B1,K2,AR,BR) E2(K2,A2,B2) Esempio CITTA` NOME POPOLAZIONE (1,1) APPARTIENE_ A (1,n) STATO NOME GOVERNATORE POPOLAZIONE CITTA` (NOME CITTA`, NOME STATO, POPOLAZIONE) STATO (NOME STATO, GOVERNATORE, POPOLAZIONE) (a) Partecipazione totale

38 Traduzione di relazioni 1 a molti Questa soluzione è adatta anche se la cardinalità per E1 è (0,1), anche se in tal caso possono esserci dei valori NULL. In questo caso ad un dato valore di K1 corrisponde uno ed un solo valore di K2 (ma non viceversa). K1 A1 B1 (0,1) (1,n) E1 R E2 K2 A2 B2 AR BR E1(K1,A1,B1,K2,AR,BR) E2(K2,A2,B2) Traduzione di relazioni 1 a molti Volendo usare la soluzione standard a 3 tabelle, la tabella R non ha più K2 come chiave, cioè si ha: K1 A1 B1 (0,1) (1,n) E1 R E2 K2 A2 B2 E1(K1,A1,B1) E2(K2,A2,B2) R(K1,K2,AR,BR) AR BR

39 Esempio VENDITORE (1,n) EMETTE NOME TELEFONO SCONTO (0,1) ORDINE NUMERO_ORDINE DATA VENDITORE (NOME, TELEFONO) ORDINE (NUM_ORDINE, DATA) ORDINE_VENDITA (NUM_ORDINE, NOME_VENDITORE, SCONTO) (b) Partecipazione parziale Relazioni n-arie (n>2) Le associazioni n-arie (che coinvolgono cioè più di due entità) vengono tradotte in maniera standard. La relazione eredita tutti gli identificatori delle n entità collegate che diventano identificatori della nuova relazione (come per le relazioni binarie molti a molti)

40 COD_COMP (1,n) COMPONENTE Esempio PRODOTTO (1,n) FORNISCE CODICE_PRODOTTO NOME DESCRIZIONE QUANTITA` DESCRIZIONE Relazione ternaria (1,n) FORNITORE CODICE_FORNITORE NOME INDIRIZZO TELEFONO COMPONENTE (COD_COMP, DESCRIZIONE) PRODOTTO (CODICE_PRODOTTO, NOME, DESCRIZIONE) FORNITORE (CODICE_FORNITORE, NOME, INDIRIZZO, TELEFONO) FORNISCE (CODICE_PRODOTTO, CODICE_COMPONENTE, CODICE_FORNITORE, QUANTITA`) Esempio AUTOMOBILE NUM_TELAIO NOME_CLIENTE CLIENTE (1,n) (1,n) VENDITA_ AUTO PREZZO_AUTO AMMONTARE_PRESTITO DISTRIBUTORE NOME_DISTRIB (1,n) INTERESSI BANCA_ FINANZIATRICE NOME_BANCA Relazione quaternaria VENDITA_AUTO (NUM_TELAIO, NOME_CLIENTE, NOME_DISTRIB, NOME_BANCA, PREZZO_AUTO, AMMONTARE_PRESTITO, INTERESSI)

41 Esempio NOME IMPIEGATO DATA_DI_NASCITA E`_SUBORDINATO_A E`_IL_SUPERIORE_DI CAPO_ DI relazione recursiva Relazione molti a molti: IMPIEGATO(NOME, DATA_DI_NASCITA) CAPO_DI(NOME_CAPO, NOME_SUBORDINATO) Relazione 1 a molti: IMPIEGATO(NOME, DATA_DI_NASCITA) CAPO_DI(NOME_SUBORDINATO, NOME_CAPO) o IMPIEGATO(NOME, DATA_DI_NASCITA, NOME_CAPO) Progetto Logico Dal diagramma ER allo schema logico relazionale ESEMPI

42 Vendita all ingrosso di piante Si vuole rappresentare una base dati per la gestione della vendita all ingrosso di piante, tenendo conto delle seguenti informazioni: Sono trattate diverse specie di piante. Per ciascuna specie sono noti sia il nome latino che il nome comune, ed un codice univoco attraverso cui la specie viene identificata. Per ciascuna specie è inoltre noto se sia tipicamente da giardino o da appartamento e se sia una specie esotica o no. Le piante possono essere verdi oppure fiorite. Nel caso di specie di piante fiorite, sono note tutte le colorazioni in cui ciascuna specie è disponibile. I clienti sono identificati attraverso un codice cliente e sono costituiti da privati e da rivendite. Per ciascun privato sono noti il codice fiscale, il nome e l indirizzo della persona, mentre per ogni rivendita sono noti la partita iva, il nome e l indirizzo della rivendita. I fornitori sono identificati attraverso un codice fornitore; per ciascun fornitore sono inoltre noti il nome, il codice fiscale e l indirizzo. Il fornitore può fornire diverse specie di piante. Tuttavia le piante della stessa specie sono acquistate sempre da uno stesso fornitore. Si vuole tener traccia di tutti gli acquisti eseguiti da ciascun cliente. Un acquisto, effettuato in una data specifica, è relativo a una certa quantità di piante appartenenti ad una determinata specie. Il listino prezzi, in cui si vuole tener traccia dei prezzi assunti nel tempo da ciascuna specie di piante. Diagramma ER

43 Schema logico relazionale ATTENZIONE: in questo e nei successivi modelli, le chiavi non sono sottolineate. Vedere esercizi svolti in aula FORNITORI (CodiceF, CodFisc, Nome, Indirizzo) La generalizzazione sulle piante può essere tradotta eliminando la entità figlia FIORITE. Si introduce l attributo TipoPianta per discriminare tra le piante fiorite e non fiorite. PIANTE (CodiceP, TipoPianta, NomeLat, NomeCom, Giardino, Esotica, CodiceF) COLORAZIONI (CodicePFiorita, Colore) LISTINO (CodiceP, DataInizio, DataFine*, Prezzo) La generalizzazione sui clienti può tradotta eliminando le entità figlie PRIVATI e RIVENDITE. Si introduce l attributo TipoCliente per discriminare tra i clienti privati e le rivendite. CLIENTI (CodiceC, TipoCliente, Nome, Indirizzo, CodFisc*, P.IVA*) TEMPO (Data) ACQUISTANO (CodiceP, CodiceC, Data, quantità) Altre possibili traduzioni La generalizzazione sulle piante può essere tradotta mantenendo la entità figlia FIORITE: PIANTE (CodiceP, NomeLat, NomeCom, Giardino, Esotica, CodiceF) FIORITE (CodicePFiorita) COLORAZIONI (CodicePFiorita, Colore) La generalizzazione sui clienti può essere tradotta mantendo le entità CLIENTE, PRIVATI e RIVENDITE: CLIENTI (CodiceC, Nome, Indirizzo) PRIVATI (CodiceCPrivato, CodFisc) RIVENDITE (CodiceCRivendita, P.IVA) TEMPO (Data) ACQUISTANO (CodiceP, CodiceC, Data, quantità) La generalizzazione sui clienti può essere tradotta eliminando l entità padre CLIENTI: PRIVATI (CodiceCPrivato, CodFisc, Nome, Indirizzo) RIVENDITE (CodiceCRivendita, P.IVA, Nome, Indirizzo) TEMPO (Data) ACQUISTANOPRIVATI (CodiceP, CodiceCPrivato, Data, quantità) ACQUISTANORIVENDITE(CodiceP, CodiceCRivendita, Data, quantità)

44 Gestione delle piscine comunali di Torino Si vuole rappresentare una base dati contenete le informazioni relative alle piscine gestite del comune di Torino, tenendo conto delle seguenti informazioni: Le piscine sono identificate univocamente attraverso il nome (ad esempio Vigone, Comunale, Trecate, ecc). Per ciascuna sono inoltre noti l'indirizzo, un numero di telefono, ed il nome di un responsabile. Nel caso la piscina disponga anche di una vasca all'aperto, la base dati contiene l'informazione di quando tale vasca è utilizzabile (ad esempio da Marzo a Settembre, da Luglio ad Agosto, ecc.) Presso le piscine sono organizzati dei corsi; lo stesso tipo di corso può essere svolto presso piscine diverse, eventualmente con modalità differenti. Ciascun corso è pertanto identificato dal nome dell'attività svolta, quali Aerobica, Acquagym, Corso di Sincronizzato o corso per Gestanti, e dal nome della Piscina presso cui tale corso si svolge. Per ciascun corso, svolto presso una certa piscina, è noto il costo, il numero massimo e minimo di partecipanti, in quali giorni della settimana si svolge ed a che ora. Si ipotizzi che presso ciascuna piscina ogni corso sia svolto una sola volta al giorno, ma più volte durante la settimana. Il corpo insegnante lavora a rotazione presso le varie piscine. Per ciascun insegnante è noto il codice fiscale, che lo identifica, un nome, il numero di cellulare, se disponibile, e l'elenco delle qualifiche dell'insegnante (ad esempio istruttore di sub, istruttore di aerobica, ecc). All'interno della base dati si vuole tener traccia di tutti gli intervalli di tempo in cui un insegnante ha lavorato presso ciascuna piscina. Non si escluda che lo stesso insegnante possa aver lavorato presso una stessa piscina in intervalli di tempo diversi. Le piscine possono essere frequentate o da persone che sono iscritte ai corsi, o secondo la modalità ad ``ingresso singolo'' per svolgere nuoto libero (si noti che sono registrate per l'ingresso singolo solo le persone che non hanno mai frequentato corsi). Tutte le persone che accedono alle piscine comunali sono identificate attraverso il loro codice fiscale ed inoltre sono noti il nome, un indirizzo ed un numero di telefono. Le persone che sono iscritte ai corsi devono presentare un certificato medico. Pertanto, nel caso la persona sia iscritta ad un corso, il database contiene l'informazione del medico che ha redatto il certificato, la data in cui la persona ha presentato il certificato, l'età della persona, e l'elenco dei corsi a cui è iscritta. Per le persone che hanno fatto solo ingressi sono noti solo la data in cui è stato effettuato l'ultimo ingresso e presso quale piscina. Diagramma ER

45 Diagramma ER Rappresentazione alternativa della relazione LEZIONE Diagramma ER Rappresentazione alternativa della relazione ROTAZIONE

46 Schema logico relazionale La generalizzazione sulle piscine è stata tradotta togliendo l entità figlia CON_VASCA_ALL APERTO e mantenendo l entità padre PISCINA. Si è introdotto l attributo Tipo per discriminare tra le piscine con e senza vasca all aperto. PISCINA (NomeP, IndP, TelP, Resp., Tipo, Da*, A*) CORSO (NomeP, NomeC, Min, Max, Costo) TEMPO1 (Giorno) LEZIONE (NomeP, NomeC, Giorno, Ora) La generalizzazione sulle persone è stata tradotta mantenendo sia l entità padre PERSONA che le due entità figlie ISCRITTO_CORSO e INGRESSO_SINGOLO: PERSONA (CodFiscPe, NomePe, IndPe, TelPe) ISCRITTO_CORSO (CodFiscPe_Iscritto_Corso, Medico, DataCert,DataNascita) INGRESSO_SINGOLO (CodFiscPe_Ingresso_Singolo, DataIng.) FREQUENZA_CORSI (CodFiscPe_Iscritto_Corso, NomeP, NomeC) INSEGNANTE (CodFiscI, NomeI, CellI*) QUALIFICHE (CodFiscI, QualificaI) TEMPO2 (DataInizio) ROTAZIONE (CodFiscI, DataInizio, NomeP, DataFine) Noleggio di videocassette Si vuole rappresentare una base dati per la gestione di una catena di centri di servizio per il noleggio delle videocassette, tenendo conto delle seguenti informazioni: Ogni centro di servizio è identificato attraverso un codice numerico univoco; inoltre viene riportato l indirizzo del centro ed il numero di telefono. La base dati contiene le informazioni relative a tutte le persone impiegate presso la catena. Per ciascun impiegato sono noti il codice fiscale, il nome, il titolo di studio ed un recapito. Il codice fiscale permette di identificare univocamente l impiegato all interno della base dati. Gli impiegati possono essere spostati da un centro all altro a seconda delle esigenze; si vuole pertanto tenere traccia di tutti gli intervalli di tempo in cui un impiegato ha prestato servizio presso un centro e della carica che ha rivestito in quel periodo (per esempio, cassiere o commesso). I film disponibili presso la catena sono identificati dal titolo e dal nome del regista; inoltre sono noti l anno in cui il film è stato girato, l elenco degli attori principali del film, il costo corrente di noleggio della videocassetta ed eventualmente i film disponibili presso la catena di cui il film in questione rappresenta la versione remake. Per ogni film è nota la collocazione all interno di ciascun centro di servizio. In particolare, sono noti il settore, la posizione all interno del settore ed il numero di copie in cui il film è disponibile. Ciascun settore è identificato attraverso un codice numerico univoco all interno del centro di servizi e dal codice del centro di servizio stesso. Per ogni film sono noti i centri di distribuzione da cui è fornito ed il costo relativo. Tali centri di distribuzione sono caratterizzati dal nome del centro di distribuzione, da un recapito e sono identificati attraverso un codice numerico.

47 Diagramma ER Schema logico relazionale IMPIEGATI (CodFisc., Nome, Recapito, TitoloStudio) CENTRO (CodC, Indiriz., Tel.) DATA (DataInizio) LAVORA_IN (CodC, CodFisc., DataInizio, DataFine, Carica) SETTORE (CodC, CodS) FILM (Regista, Titolo, CostoNol., Anno) ATTORI (Regista, Titolo, Attore) COLLOCAZIONE(CodC, CodS, Regista, Titolo, #Copie, Posizione) REMAKE_DI (RegistaRemake, TitoloRemake, RegistaFilmOriginale, TitoloFilmOriginale) DISTRIBUTORE (CodD, Nome, Indiriz.) DISTRIBUITO_DA (Regista, Titolo, CodD, Costo)

48 Altre possibili traduzioni La relazione REMAKE_DI poteva anche essere così tradotta: FILM (Regista, Titolo, CostoNol., Anno, RegistaFilmOriginale*, TitoloFilmOriginale*) Questo tipo di traduzione è preferibile qualora la maggior parte dei film contenuti nella base di dati disponga di una versione remake. Prenotazioni esami in una ASL Si vuole rappresentare una base dati per la gestione di un sistema di prenotazioni di esami medici all interno di una Azienda Sanitaria Locale (ASL), tenendo conto delle seguenti informazioni: Ciascun paziente è identificato da un codice di tessera sanitaria ed è caratterizzato da un nome, un cognome, l indirizzo, la data ed il luogo di nascita. Gli esami medici che possono essere eseguiti sono identificati da un codice numerico e sono caratterizzati dalla descrizione di esame medico (ad esempio Radiografia, ecc.). Gli ospedali della ASL sono identificati da un codice numerico e sono caratterizzati da un nome e un indirizzo. I laboratori che eseguono gli esami sono identificati da un codice univoco all interno di un ospedale della ASL e sono caratterizzati dal nome del laboratorio, dal piano di ubicazione e dal numero di stanza. Per ogni prenotazione di un esame da parte di un paziente si vuole memorizzare la data e l ora dell esame, il laboratorio presso cui è eseguito, il costo del ticket e se tale esame è prescritto con urgenza. Si tenga presente che ogni paziente può effettuare più prenotazioni dello stesso esame in date diverse. Si noti inoltre che lo stesso esame non può essere ripetuto nello stesso giorno dallo stesso paziente. Ogni ospedale è suddiviso in reparti identificati da un codice numerico univoco all interno dell ospedale di appartenenza e caratterizzati dal nome del reparto e da un numero di telefono. Il personale del reparto è identificato attraverso il codice fiscale; sono noti inoltre il nome, il cognome e l indirizzo di domicilio. Tra il personale, nel caso dei medici primari del reparto è noto l elenco delle specializzazioni, mentre per il personale volontario è noto il nome dell associazione di appartenenza, se disponibile.

49 Diagramma ER Schema logico relazionale PAZIENTE (CodTes., Nome, Cognome, Ind., DataN, LuogoN) ESAME (CodE, Descr.) OSPEDALE (CodO, Nome, Ind.) LABORATORIO (CodO, CodLab, NomeLab, Piano, Stanza) PRENOTAZIONE (CodTes., CodE, Data, Ora, Costo, Urg., CodO, CodLab) REPARTO (CodO, CodR, Nome, Tel.) Le generalizzazione sul personale può essere tradotta eliminando le entità figlie PRIMARI e VOLONTARI. Si introduce l attributo TipoPersonale per discriminante tra il personale Primario, il personale Volontario ed altro personale (essendo la generalizzazione parziale). PERSONALE (CodFisc., TipoPersonale, Nome, Cognome, Domicilio, Assoc.*, CodO, CodR) SPECIALIZZAZIONI (CodFiscPrimario, Specializ.)

50 Altre possibili traduzioni Le generalizzazione sul personale poteva essere tradotta eliminando l entità padre PERSONALE. Si introduce l entità figlia ALTRO_PERSONALE, essendo la generalizzazione parziale. Poiché l entità PERSONALE partecipa con una cardinalità (1,1) ad una relazione binaria con REPARTO, allora PRIMARI, VOLONTARI e ALTRO_ PERSONALE parteciperanno con una cardinalità (1,1) alla relazione binaria con REPARTO. PRIMARI (CodFisc.Primario, Nome, Cognome, Domicilio, CodO, CodR) SPECIALIZZAZIONI (CodFisc.Primario, Specializ.) VOLONTARI (CodFisc.Volontario, Assoc.*, Nome, Cognome, Domicilio, CodO, CodR) ALTRO_PERSONALE (CodFisc.AltroPers., Nome, Cognome, Domicilio, CodO, CodR) Le generalizzazione sul personale poteva essere tradotta mantenendo le entità PERSONALE, PRIMARI, e VOLONTARI. PERSONALE (CodFisc., Nome, Cognome, Domicilio, CodO, CodR) PRIMARI (CodFisc.Primario) SPECIALIZZAZIONI (CodFisc.Primario, Specializ.) VOLONTARI (CodFisc.Volontario, Assoc.*) Gestione di una farmacia Si vuole rappresentare una base dati per la gestione dei prodotti disponibili in una farmacia tenendo conto delle seguenti informazioni: Ciascun prodotto è caratterizzato univocamente dal nome del prodotto stesso e dall informazione relativa alla ditta fornitrice del prodotto. I prodotti presenti nella farmacia possono essere medicinali oppure prodotti di profumeria. Per ciascun prodotto è comunque noto l elenco degli usi possibili del prodotto stesso (ad esempio malattie da raffreddamento, dolori alle ossa, oppure detergente per il viso o per il corpo). Della ditta fornitrice sono invece noti un recapito, il nome, utilizzato per identificare la ditta stessa, ed eventualmente il numero di fax se disponibile. Nel caso dei medicinali, la base dati contiene l informazione relativa al fatto che un medicinale sia mutuabile o no, e se la vendita sia effettuabile solo se viene presentata una ricetta medica. Inoltre è nota la categoria farmacoterapeutica di appartenenza del medicinale (ad esempio antibiotico, oppure anti-infiammatorio) e se esistono interazioni tra quella categoria farmacoterapeutica ed altre categorie farmacoterapeutiche. I medicinali sono contenuti in cassetti, contenuti a loro volta in scaffali. Gli scaffali sono identificati da un codice numerico univoco per ciascuna categoria farmacoterapeutica ed i cassetti da un codice numerico univoco per ciascuno scaffale. Nel caso infine di medicinali che richiedano la ricetta medica, si vuole tener traccia di ogni vendita effettuata per quel medicinale, indicando il giorno, la quantità ed il nome del medico che ha fatto la prescrizione.

51 Diagramma ER Schema logico relazionale DITTA (NomeD, Recapito, Fax*) Le generalizzazione sul prodotto è stata tradotta eliminando l entità figlia PROFUMERIA e mantenedo l entità figlia MEDICINALE. L attributo TipoProdotto è un attributo discriminante tra i prodotti di profumeria e gli altri prodotti. PRODOTTO (NomeD, NomeP, TipoProdotto) USI DEL PRODOTTO (NomeD, NomeP, Uso) Le generalizzazione sui medicinali è stata tradotta eliminando l entità figlia RICHIEDE RICETTA: MEDICINALE (NomeD, NomeP, Mutuabile, NomeC, TipoMedicinale) VENDITA (CodV, Data, Medico, NomeD, NomeP, Quantità) CATEGORIA (NomeC) INTERAZIONE (NomeC, NomeCInteragente) SCAFFALE (NomeC, #Scaff.) CASSETTO(NomeC, #Scaff., #Cass.) SI TROVA IN (NomeD, NomeP, NomeC, #Scaff., #Cass.)

52 Corsi di lingua inglese Si progetti una base dati per la gestione dei corsi di lingua inglese, tenuti presso un instituto di insegnamento. Tutte le informazioni fanno riferimento ad un solo anno scolastico in corso, e non viene richiesto di mantenere le informazioni relative agli anni scolastici precedenti. La base dati deve contenere le seguenti informazioni: I corsi sono organizzati per livelli. Ciascun livello è identificato dal nome del livello stesso (ad esempio Elementary, Intermediate, First Certificate, Advanced, Proficiency); inoltre è specificato il nome del libro di testo e se viene richiesto di sostenere un esame finale. I corsi sono identificati univocamente dal nome del livello cui afferiscono e da un codice progressivo, necessario per distinguere corsi che fanno riferimento allo stesso livello. Per ciascun corso sono note la data di attivazione, il numero di iscritti e l elenco dei giorni in cui è tenuto. Per gli insegnanti sono noti il nome, l indirizzo, la nazione di provenienza, ed i corsi a cui sono stati assegnati. Si assuma che a ciascun corso sia assegnato un unico insegnante. Per gli allievi sono noti il nome, un recapito, il corso a cui sono iscritti, la data di iscrizione al corso e il numero di assenze fatte finora. Gli allievi possono anche prenotare lezioni private, qualora vogliano approfondire alcuni aspetti della lingua inglese. Si vuole tener traccia di tutte le lezioni private eventualmente richieste da un allievo, in quale data e con quale insegnante. La scuola organizza poi un insieme di attività culturali. Ciascuna attività è identificata da un codice progressivo, e sono noti il giorno e l ora in cui verrà tenuta. Nel caso di proiezioni in lingua originale, sono noti il nome del film ed il nome del regista. Nel caso di conferenze, sono noti l argomento che verrà trattato ed il nome del conferenziere. Per poter partecipare alle attività gli allievi devono iscriversi. Diagramma ER