Esercizio Si consideri lo schema conce/uale, che descrive i da3 di con3 corren3 bancari. Un cliente puo essere 3tolare di piu con3 corren3 e che uno stesso conto corrente puo essere intestato a diversi clien3.
Si supponga che su ques3 da3, sono definite le seguen3 operazioni principali: Operazione 1: Apri un conto corrente ad un cliente. Operazione 2: Leggi il saldo totale di un cliente. Operazione 3: Leggi il saldo di un conto. Operazione 4: Ri3ra i soldi da un conto con una transazione allo sportello. Operazione 5: Deposita i soldi in un conto con una transazione allo sportello. Operazione 6: Mostra le ul3me 10 transazioni di un conto. Operazione 7: Registra transazione esterna per un conto. Operazione 8: Prepara rapporto mensile dei con3. Operazione 9: Trova il numero dei con3 possedu3 da un cliente. Operazione10: Mostra le transazioni degli ul3mi 3 mesi dei con3 delle societa con saldo nega3vo.
Si supponga che, in fase opera3va, i da3 di carico per questa applicazione bancaria siano:
Effe/uare la fase di proge/azione logica sullo schema E- R tenendo conto dei da3 forni3. Nella fase di ristru/urazione si tenga conto del fa/o che sullo schema esistono due ridondanze: Gli a/ribu3 Saldo Totale e Numero di ConB dell en3ta CLIENTE. Essi possono infar essere deriva3 dall associazione TITOLARITÀ e dall en3ta CONTO.
Analisi delle ridondanze: Nello schema esistono 2 da3 ridondan3: Saldo totale e Numero di ConB. Saldo totale: Ipo3zzando che l a/ributo saldo totale sia di 3po float (32 bit e quindi 4 bytes per ogni occorrenza), l u3lizzo di questo dato richiederebbe 4*15.000 bytes, con un u3lizzo di memoria pari a 60 KB. Le operazioni coinvolte con questo dato sono la 2, la 4, la 5, la 7 e la 8. Si procede analizzando il costo per ognuna di queste operazioni, non conteggiando l operazione 8 che viene svolta in batch una sola volta al mese. Con dato ridondante Per l operazione 2 abbiamo: 1x2.000 accessi in le/ura = 2.000 accessi al giorno Per l operazione 4 abbiamo: 1x2.000 accessi in le/ura (leggo il saldo totale) + 2x2.000 accessi in scri/ura (scrivo il nuovo saldo) = 6.000 accessi al giorno (10k accessi in le/ura) Per l operazione 5 abbiamo: 1x1.000 accessi in le/ura (leggo il saldo totale) + 2x1.000 accessi in scri/ura (scrivo il nuovo saldo) = 3.000 accessi al giorno (5k accessi in le/). Per l operazione 7 abbiamo: 1x1.500 accessi in le/ura (leggo il saldo totale) + 2x1.500 accessi in scri/ura (scrivo il nuovo saldo) = 4.500 accessi al giorno (7k in le/ura)
Senza dato ridondante Per l operazione 2 abbiamo: ipo3zzando che la query di ricerca dei con3 di un cliente abbia un costo pari a 20 accessi in le/ura, mol3plicato per 2.000 operazioni al giorno, o/engo 40.000 accessi al giorno. Per l operazione 4 abbiamo: Nessun accesso aggiun3vo Per l operazione 5 abbiamo: Nessun accesso aggiun3vo Per l operazione 7 abbiamo: Nessun accesso aggiun3vo In conclusione, il dato ridondante ho 15.000 accessi, mentre senza il dato ridondante ho 40.000 accessi al giorno. Il dato ridondante mi fa risparmiare 25.000 accessi a fronte di 60 KB di memoria.
Numero di con3: Per quanto riguarda il numero di con3 posseduto da un cliente, l u3lizzo di memoria col dato ridondante è di 1 byte per cliente, che equivale a 15 KB di memoria. Le operazioni coinvolte sono la 1 e la 9. Anche senza svolgere i con3, si puo notare che l u3lizzo del dato è di sole 75 volte al giorno e in modalita batch con l operazione 9. Il conseguente miglioramento di efficienza sara nell ordine di un migliaio di accessi in meno al giorno. Sarà quindi a discrezione del progersta l u3lizzo o meno del dato. In questo caso ipo3zziamo quindi di non ritenerlo necessario.
Eliminazione delle gerarchie: Nello schema è presente una sola gerarchia rela3va all en3ta CLIENTE, che viene dis3nto in PERSONA FISICA o SOCIETÀ. L en3ta SOCIETÀ ha gli a/ribu3 Par3ta IVA e Capitale che la dis3nguono. L unica operazione che fa una dis3nzione sul 3po di cliente è la numero 10. Visto lo scarso numero di operazioni e il poco spazio necessario per accorpare le due en3ta, si decide di accorpare gli a/ribu3 Par3ta IVA e Capitale in Cliente. Sarà l a/ributo Par3ta IVA ad iden3ficare un cliente come societa.
Scelta degli idenbficatori principali: Gli iden3ficatori sono Numero transazione per l en3ta TRANSAZIONE, Numero Conto per l en3ta CONTO. Per quanto riguarda l en3ta CLIENTE, l iden3ficatore è l a/ributo Numero cliente; l a/ributo Par3ta Iva iden3fica le societa e se presente deve essere univoco.
Schema relazionale TRANSAZIONE(Numero transazione, Tipo, Data, Ammontare) CONTO(Numero Conto, Saldo) CLIENTE(Numero cliente, Saldo Totale, Limite di credito, Nome, Indirizzo, Par3ta IVA*, Capitale*) OPERAZIONE(Numero conto, Numero transazione) TITOLARITÀ(Numero conto, Numero cliente)
Esercizio Si consideri lo schema conce/uale nel quale l a/ributo Saldo di una occorrenza di CONTOCORRENTE è o/enuto come somma dei valori dell a/ributo Importo per le occorrenze di OPERAZIONE ad essa correlate tramite la relazione MOVIMENTO.
Valutare se convenga o meno mantenere la ridondanza, tenendo conto del fa/o che le cardinalità delle due en3tà sono CC = 2.000 e OP =20.000 e che le operazioni più importan3 sono: OP1 scri/ura di un movimento, con frequenza f1 = 10 OP2 le/ura del saldo con frequenza f2 = 1000.