FONDAMENTI INFORMATICA II AA 2006/2007 PROGETTO 1 Irene Bont 1.

. Analisi dettagliata delle specifiche fornite Lo studente progetti una base di dati relativa al settore clienti di una ditta di catering. Vogliamo mantenere memoria di tutti suoi clienti; ovviamente i clienti possono essere sia privati che aziende. Per ciascun cliente dovranno essere memorizzate le informazioni necessarie per lindividuazione. Per i privati nome, cognome, indirizzo, numero di telefono, e-mail, ecc. Per le aziende Ragione sociale, partita IVA, numero di telefono, e-mail, ecc. Per ciascun cliente vogliamo memorizzare i preventivi effettuati, memorizzando la data, lora, loccasione, il numero di partecipanti, la location utilizzata, il costo complessivo e il menu fornito. Ovviamente devono essere memorizzati quali di questi preventivi sono andati a buon fine (cio hanno portato ad un effettivo lavoro). Per ciascun lavoro effettuato dalla ditta, vogliamo memorizzare quali dipendenti vi hanno partecipato, il pagamento ricevuto, memorizzando la data in cui e stato effettuato il pagamento e il conto corrente su cui e stato effettuato il pagamento. Per ciascuna location in cui la ditta ha lavorato, vogliamo memorizzare il proprietario, lindirizzo, il numero di telefono, il costo, il massimo numero di partecipanti. Le operazioni da compiere su questa base di dati sono le seguenti: - Individuare lelenco dei preventivi effettuati ad un dato cliente (2 volte al mese). - Individuare il totale pagato fino a quel momento da un dato cliente (1 volta al mese). - Individuare il numero di preventivi effettuati ad un dato cliente (1 volta al mese). - Inserimento di un nuovo preventivo (3 volte al giorno), - Individuare lelenco dei lavori effettivamente effettuati in una data location (1 volta a settimana). Si consideri che il mese si composto da 4 settimane. 2. Introduzione di ipotesi sugli aspetti non coperti dalle specifiche Possiamo ipotizzare che la ditta di catering metta a disposizione dei clienti la possibilit di noleggiare dei prodotti per svolgere il lavoro, quali sedie, tavoli, bicchieri, posate, tovaglie, piatti, attrezzi da cucina, ecc. 3. Progettazione della base di dati producendo uno schema E-R comprensivo di: a. Nomi di entit e relazioni b. Elenco di attributi di entit e relazioni c. Identificatori primari delle entit d. Cardinalit delle relazioni e. Eventuali generalizzazioni Iniziamo la progettazione concettuale individuando quali saranno le entit della nostra base di dati. Le entit sono classi di oggetti che hanno una loro esistenza autonoma indipendentemente dallesistenza di altre classi di oggetti. Basandosi sulla definizione, possiamo individuare immediatamente le seguenti entit: - Cliente - Preventivo - Dipendente - Location Infatti queste classi di oggetti hanno una loro esistenza autonoma. Le specifiche della base di dati prevedono anche la presenza dei seguenti insiemi: - Privato - Azienda - Lavoro - Proprietario

Poich tali insiemi esistono indipendentemente dal fatto che vengano utilizzati o meno, possiamo considerare anche questi come entit. Possiamo iniziare a disegnare il nostro schema E-R come mostrato in Figura 1.

Figura 1 A questo punto dobbiamo considerare che la base di dati prevede pi tipi di clienti (privati e aziende). Poich il privato e lazienda sono comunque clienti, possiamo ricorrere al costrutto della generalizzazione. Visto che i clienti sono necessariamente o privati o aziende, dovremo ricorrere a una generalizzazione totale. Lo schema E-R acquista la struttura mostrata in Figura 2:

Figura 2 Adesso colleghiamo tra di loro queste entit mediante delle relazioni. Il risultato e mostrato in Figura 3.

Figura 3 Aggiungendo gli attributi alle varie entit, otteniamo lo schema di figura 4.

Figura 4 Per completare lo schema E-R non resta che aggiungere le cardinalit alle varie relazioni. In base alle specifiche del progetto e in base alle considerazioni di tipo generale, sappiamo che:

Ogni cliente richiede almeno un preventivo, ma pu richiederne pi di uno -> la relazione RICHIESTA ha cardinalit (1,N) con lentit CLIENTE. - Ogni preventivo ha una e una sola richiesta da parte di un cliente -> la relazione RICHIESTA ha cardinalit (1,1) con lentit PREVENTIVO. - Ogni preventivo pu non diventare mai un lavoro effettivo, ma pu anche andare a buon fine e diventare lavoro effettivo pi volte -> la relazione CONVALIDA ha cardinalit (0,N) con lentit PREVENTIVO. - Ogni lavoro la messa in opera di uno e un solo preventivo -> la relazione CONVALIDA ha cardinalit (1,1) con lentit LAVORO. - Ogni preventivo ha una e una sola location proposta -> la relazione LOCAZIONE PROPOSTA ha cardinalit (1,1) con lentit PREVENTIVO. - Ogni location pu non essere proposta per nessun lavoro oppure pu essere proposta per pi di un lavoro -> la relazione LOCATION PROPOSTA ha cardinalit (0,N) con lentit LOCATION. - Ogni lavoro viene svolto da almeno un dipendente della ditta di catering -> la relazione PARTECIPAZIONE ha cardinalit (1,N) con lentit LAVORO. - Ogni dipendente partecipa almeno ad un lavoro, ma pu aver partecipato a pi lavori -> la relazione PARTECIPAZIONE ha cardinalit (1,N) con lentit DIPENDENTE. - Ogni location ha uno e un solo proprietario -> la relazione APPARTENENZA ha cardinalit (1,1) con lentit LOCATION. - Ogni persona proprietaria di almeno una location o anche di molte -> la relazione APPARTENENZA ha cardinalit (1,N) con lentit PROPRIETARIO. - Ogni lavoro si svolge in una e una sola location -> la relazione LOCATION USATA ha cardinalit (1,1) con lentit LAVORO. - Ogni location stata utilizzata per almeno un lavoro, ma pu essere stata utilizzata per pi lavori -> la relazione LOCATION USATA ha cardinalit (1,N) con lentit LOCATION. In base a quanto detto otteniamo lo schema E-R rappresentato in figura 5.

Figura 5 Infine aggiungiamo a questo schema E-R gli aspetti non coperti dalle specifiche. Otteniamo lo schema E-R di Figura 6.

Figura 6

4. Individuazione delle ridondanze presenti nello schema E-R (lo schema E-R deve contenere almeno due ridondanze, altrimenti lo studente introduca le ridondanze che mancano in modo da ridurre la complessit delle operazioni presenti nelle specifiche). Traduzione delle generalizzazioni. A questo punto dobbiamo procedere con la progettazione logica che permette di ricavare lo schema logico a partire dallo schema concettuale. Come possiamo vedere dalla Figura 6, nello schema E-R abbiamo un ciclo di entit e relazioni che abbiamo isolato in Figura 7. Un ciclo di questo tipo potrebbe essere indicazione di una ridondanza. Controlliamo se esiste effettivamente una relazione ridondante e nel caso in cui esista, se convenga eliminarla o meno.

Figura 7

La relazione LOCATION PROPOSTA non una ridondanza. Supponiamo infatti di aver eliminato la relazione LOCATION PROPOSTA e di dover inserire un nuovo preventivo non ancora convalidato. Nel caso in cui la base di dati non contenga un lavoro convalidato per tale preventivo, non possibile recuperare dalla base di dati linformazione su quale sia la location proposta per quel preventivo. La relazione LOCATION USATA non una ridondanza. Supponiamo infatti di aver eliminato la relazione LOCATION USATA e di voler trovare la location utilizzata per un dato lavoro. Se eliminassimo la relazione LOCATION USATA non saremmo pi in grado di recuperare la location in cui stato effettuato il lavoro. La relazione CONVALIDA una ridondanza. Supponiamo infatti di aver eliminato la relazione CONVALIDA e di voler recuperare quali preventivi sono andati a buon fine, cio hanno portato a un effettivo lavoro. Se eliminassimo la relazione CONVALIDA non saremmo pi in grado di distinguere tra preventivi andati a buon fine e non. Dobbiamo ora decidere come tradurre la generalizzazione presenti nel modello E-R di Figura 6 e isolata in Figura 8.

Figura 8 La generalizzazione dellentit CLIENTE di tipo totale. In questo caso possibile scegliere una delle seguenti opzioni: - Accorpamento dellentit padre sulle entit figlie. - Accorpamento delle entit figlie sullentit padre. - Nessun accorpamento. In questo caso non opportuno accorpare le entit figlie sullentit padre. Facendo in questo modo, per, avremmo cinque nuovi attributi sullentit padre, di cui due o tre assumerebbero comunque valore NULL (Figura 9).

Figura 9 Potremmo allora accorpare lentit padre sulle entit figlie, ma anche questa soluzione da scartarsi perch porterebbe a un grande spreco di memoria (Figura 10).

Figura 10 Per questo motivo decidiamo di tradurre la generalizzazione dellentit CLIENTE non eseguendo alcun accorpamento. Aggiungiamo come chiave di CLIENTE un attributo CODICE CLIENTE e un attributo TIPOLOGIA. Date queste considerazioni, lo schema E-R di Figura 6 pu essere modificato come indicato qui di seguito (Figura 11).

Figura 11

Per ridurre la complessit delle operazioni presenti nelle specifiche pu essere utile, infine, introdurre alcune ridondanze nello schema E-R. Possiamo allora aggiungere due attributi allentit CLIENTE quali TOTALE PAGATO e NUMERO PREVENTIVI, in modo da rendere pi immediate le operazioni 2 e 3. Lo schema diventa il seguente (Figura 12):

Figura 12

5. Compilazione della tavola dei volumi completa Supponiamo di avere la seguente tabella dei volumi:
CLIENTE PRIVATO AZIENDA PREVENTIVO LOCATION PROPRIETARIO PRODOTTO LAVORO DIPENDENTE E E E E E E E E E 100 90 10 900 20 10 2000 300 100 Tabella 1 Ogni cliente ha richiesto in media 9 preventivi Ogni location viene proposta in un preventivo in media 45 volte Ogni proprietario possiede in media 2 location In media vengono noleggiati 10 prodotti In media solo 1 preventivo su 3 viene convalidato in un effettivo lavoro Ogni location stata usata in media 15 volte Ogni dipendente ha partecipato in media a 30 lavori Ad ogni lavoro partecipano in media 10 dipendenti GENER. 1 GENER. 2 RICHIESTA LOCATION PROPOSTA APPARTENENZA LOCATION USATA PARTECIPAZIONE NOLEGGIO CONVALIDA R R R R R R R R R 100 50 900 900 20 300 3000 200 300

6. Compilazione della tavola degli accessi con e senza ridondanze relativa alle operazioni presenti nelle specifiche Dobbiamo eseguire sulla base di dati le seguenti operazioni: - Operazione 1 (2 volte al mese): Individuare lelenco dei preventivi effettuati ad un dato cliente - Operazione 2 (1 volta al mese): Individuare il totale pagato fino a quel momento da un dato cliente - Operazione 3 (1 volta al mese): Individuare il numero dei preventivi effettuati ad un dato cliente - Operazione 4 (3 volte al giorno): Inserimento di un nuovo preventivo - Operazione 5 (1 volta a settimana): Individuare lelenco di lavori effettivamente effettuati in una data location Contiamo il numero di operazioni elementari che devono essere effettuate per eseguire ciascuna di queste operazioni sia usando le ridondanze che no. - Operazione 1 (con le ridondanze). Dato il codice del cliente, occorre leggere 9 occorrenze della relazione RICHIESTA (ciascun cliente ha richiesto in media 9 preventivi) per recuperare il codice dei preventivi richiesti dal cliente. A questo punto occorre leggere 9 occorrenze dellentit PREVENTIVO per recuperare tutte le informazioni relative ai preventivi richiesti dal cliente. Quindi in totale occorre eseguire 18 letture. - Operazione 1 (senza le ridondanze). Dato il codice del cliente, occorre leggere 9 occorrenze della relazione RICHIESTA (ciascun cliente ha richiesto in media 9 preventivi) per recuperare il codice dei preventivi richiesti dal cliente. A questo punto occorre leggere 9 occorrenze dellentit PREVENTIVO per recuperare tutte le informazioni relative ai preventivi richiesti dal cliente. Quindi in totale occorre eseguire 18 letture. - Operazione 2 (con le ridondanze). Dato il codice del cliente, occorre leggere 1 occorrenza dellentit CLIENTE per recuperare il totale pagato dal dato cliente. Quindi in totale occorre eseguire 1 lettura.

Operazione 2 (senza le ridondanze). Dato il codice del cliente, occorre leggere 9 occorrenze della relazione RICHIESTA per recuperare il codice dei preventivi richiesti dal cliente. A questo punto occorre leggere 3 occorrenze della relazione CONVALIDA (solo 1 preventivo su 3 viene convalidato in un effettivo lavoro) per recuperare il codice dei lavori effettuati per un dato cliente. Infine occorre leggere 3 occorrenze dellentit LAVORO per recuperare il pagamento ricevuto per ogni lavoro effettuato. Quindi in totale occorre eseguire 15 letture. Operazione 3 (con le ridondanze). Dato il codice del cliente, occorre leggere 1 occorrenza dellentit CLIENTE per recuperare il numero dei preventivi effettuati per quel dato cliente. Quindi in totale occorre effettuare 1 lettura. Operazione 3 (senza le ridondanze). Dato il codice del cliente, occorre leggere 9 occorrenze della relazione RICHIESTA perch in media ciascun cliente ha richiesto 9 preventivi. Quindi in totale occorre eseguire 9 letture. Operazione 4 (con le ridondanze). Note tutte le informazioni del nuovo preventivo, occorre eseguire 1 scrittura sullentit CLIENTE per memorizzare le informazioni riguardo al cliente che richiede il preventivo, 1 scrittura sulla relazione GENER. 1 o GENER. 2 per specificare i dati del cliente, sia esso privato o azienda, 1 scrittura sullentit PREVENTIVO per memorizzare le informazioni riguardo al preventivo richiesto, 1 scrittura sullentit LOCATION per memorizzare informazioni riguardo alla location proposta, 1 scrittura sullentit PROPRIETARIO per memorizzare informazioni sul proprietario della location proposta. Quindi in totale occorre eseguire 5 scritture. Operazione 4 (senza le ridondanze). Note tutte le informazioni del nuovo preventivo, occorre eseguire 1 scrittura sullentit CLIENTE per memorizzare le informazioni riguardo al cliente che richiede il preventivo, 1 scrittura sulla relazione GENER. 1 o GENER. 2 per specificare i dati del cliente, sia esso privato o azienda, 1 scrittura sullentit PREVENTIVO per memorizzare le informazioni riguardo al preventivo richiesto, 1 scrittura sullentit LOCATION per memorizzare informazioni riguardo alla location proposta, 1 scrittura sullentit PROPRIETARIO per memorizzare informazioni sul proprietario della location proposta. Quindi in totale occorre eseguire 5 scritture. Operazione 5 (con le ridondanze). Dato lindirizzo della location, occorre leggere 15 occorrenze (ogni location stata usata in media 15 volte) dellentit LAVORO per recuperare le informazioni riguardanti i lavori effettuati in quella data location. Quindi in totale occorre eseguire 15 letture. Operazione 5 (senza le ridondanze). Dato lindirizzo della location, occorre leggere 15 occorrenze (ogni location stata usata in media 15 volte) dellentit LAVORO per recuperare le informazioni riguardanti i lavori effettuati in quella data location. Quindi in totale occorre eseguire 15 letture.

Possiamo riassumere queste informazioni nella seguente tabella: Letture Scritture 18 -18 -1 -15 -1 -9 --5 -5 15 -15 -Tabella 2

Op. 1 con ridondanze senza ridondanze Op. 2 con ridondanze senza ridondanze Op. 3 con ridondanze senza ridondanze Op. 4 con ridondanze senza ridondanze Op. 5 con ridondanze senza ridondanze

Poich le scritture sono operazioni pi dispendiose rispetto alle letture, solitamente si considera le scritture come aventi peso doppio rispetto alle letture.

7. Analisi della tavola degli accessi, al fine di decidere se mantenere o meno le ridondanze individuate Possiamo quindi completare le tavole degli accessi. con ridondanze Num. Op. Elementari N. VolteAlMese Op. elementari al mese Operazione 1 18 2 36 Operazione 2 1 1 1 Operazione 3 1 1 1 Operazione 4 10 84 840 Operazione 5 15 4 60 Numero Operazioni elementari al mese: 938 Tabella 3

senza ridondanze Num. Op. Elementari N. VolteAlMese Op. elementari al giorno Operazione 1 18 2 36 Operazione 2 15 1 15 Operazione 3 9 1 9 Operazione 4 10 84 840 Operazione 5 15 4 60 Numero Operazioni elementari al mese: 960

Tabella 4

Confrontando il numero di operazioni elementari al mese che vengono effettuate nei due casi, risulta evidente che conviene mantenere le ridondanze.

8. Traduzione dello schema E-R in tabelle, specificando: - Nomi delle tabelle - Attributi delle tabelle - Entit o Relazione da cui ciascuna tabella stata ricavata - Identificatori primari delle tabelle Innanzitutto dobbiamo individuare gli identificatori primari delle varie entit: - PRIVATO: possiamo utilizzare lattributo CODICE FISCALE come identificatore primario di questa entit. - AZIENDA: possiamo utilizzare lattributo PARTITA IVA come identificatore primario di questa entit. - CLIENTE: possiamo utilizzare lattributo CODICE CLIENTE come identificatore primario di questa entit. - PREVENTIVO: possiamo utilizzare lattributo CODICE PREVENTIVO come identifica tore primario di questa entit. - PRODOTTO: possiamo utilizzare lattributo CODICE PRODOTTO come identificatore primario di questa entit. - LOCATION: possiamo utilizzare linsieme degli attributi di INDIRIZZO come identificatore primario di questa entit. - LAVORO: possiamo utilizzare lattributo CODICE LAVORO come identificatore primario di questa entit. - PROPRIETARIO: possiamo utilizzare lattributo CODICE FISCALE come identificatore primario di questa entit. - DIPENDENTE: possiamo utilizzare lattributo CODICE FISCALE come identificatore primario di questa entit.

Otteniamo quindi lo schema E-R seguente (Figura 13):

Figura 13 Adesso siamo in grado di tradurre il modello E-R di Figura 13 in uno schema logico. Otteniamo le seguenti tabelle: - Privato (CodiceFiscale, Nome, Cognome, CodCliente) - Azienda (PartitaIva, RagioneSociale, CodCliente) - Cliente (CodCliente, Tipo, numPreventivi, TotPagato, NumTel, E-mail, Indirizzo 1) - Preventivo (CodPreventivo, CostoTot, NumPartecipanti, Occasione, Menu, Ora, Data, CodCliente, Indirizzo 2) - Proprietario (CodiceFiscale, NumTel, Nome, Cognome) - Lavoro (CodLavoro, PagamentoRicevuto, DataPagamento, ContoCorrente, Tipologia, CodPreventivo, Indirizzo 2) - Dipendente (CodiceFiscale, Nome, Cognome, NumTel, Indirizzo 3) - Partecipazione (CodLavoro, CodiceFiscale) - Prodotto (CodProdotto, Tipo) - Noleggio (CodPreventivo, CodProdotto) Basandoci sul loro significato originario, conviene sostituire il nome di alcune tabelle in modo da renderlo pi leggibile ad un lettore esterno. Operiamo i seguenti cambiamenti: - Indirizzo 1 -> IndirizzoCliente - Indirizzo 2 -> IndirizzoLocation - Indirizzo 3 -> IndirizzoDipendente In questo modo otteniamo le seguenti tabelle: Privato Nome Cognome Azienda PartitaIva RagioneSociale CodCliente

CodiceFiscale

CodCliente

Cliente CodCliente Tipo NumPreventivi TotPagato NumTel E-mail IndirizzoCliente

Cod Preventivo

Costo Tot

Num Partecipanti

Preventivo Occasione Menu

Ora

Data

Cod Cliente

Indirizzo Location

Proprietario CodiceFiscale NumTel Nome Cognome Lavoro Cod Pagamento Data Conto Tipologia Cod Indirizzo Lavoro Ricevuto Pagamento Corrente Preventivo Location Dipendente CodiceFiscale Nome Cognome numTel IndirizzoDipendente Partecipazione CodLavoro CodiceFiscale Prodotto CodProdotto Tipo

Noleggio CodPreventivo CodProdotto

9. Specificazione dettagliata dei vincoli di integrit referenziale che devono essere inseriti allinterno della base di dati al fine di garantirne la consistenza. Adesso non resta che aggiungere i vincoli di integrit che valgono su tali tabelle: - Esiste un vincolo di integrit referenziale tra lattributo CodCliente della tabella Cliente e la tabella Privato. - Esiste un vincolo di integrit referenziale tra lattributo CodCliente della tabella Cliente e la tabella Azienda. - Esiste un vincolo di integrit referenziale tra lattributo CodCliente della tabella Cliente e la tabella Preventivo. - Esiste un vincolo di integrit referenziale tra lattributo CodPreventivo della tabella Preventivo e la tabella Lavoro. - Esiste un vincolo di integrit referenziale tra lattributo CodPreventivo della tabella Preventivo e la tabella Noleggio. - Esiste un vincolo di integrit referenziale tra lattributo CodLavoro della tabella Lavoro e la tabella Partecipazione. - Esiste un vincolo di integrit referenziale tra lattributo CodiceFiscale della tabella Dipendente e la tabella Partecipazione. - Esiste un vincolo di integrit referenziale tra lattributo CodProdotto della tabella Prodotto e la tabella Noleggio. 10. Verifica della forma delle tabelle (Terza Forma Normale o Forma Normale di Boyce-Codd). Prima di tradurre lo schema E-R in modello relazionale abbiamo cercato di rendere lo schema E-R pi funzionale possibile. possibile per che le tabelle che sono state create presentino al loro interno delle ridondanze che possono portare a comportamenti indesiderati in fase di aggiornamento, inserimento o cancellazione. Per eliminare queste ridondanze dalle tabelle, conviene portare la base di dati in una delle forme normali che conosciamo. Innanzitutto, date le tabelle di partenza, occorre individuare tutte le dipendenze funzionali non banali che valgono su di esse. facile vedere che tutte le dipendenze funzionali hanno a primo membro una superchiave della tabella. Per questo motivo, le tabelle sono tutte in Forma Normale di Boyce-Codd. Tali dipendenze funzionali non producono anomalie.