1 / 46

PROGETTO DI BASI DI DATI PER UNA DITTA

PROGETTO DI BASI DI DATI PER UNA DITTA. TESINA PER L'ESAME DI BASI DI DATI MIOTTO MATTEO UNIVERSITA' DEGLI STUDI DI TRIESTE CORSO DI LAUREA TRIENNALE IN INGEGNERIA INFORMATICA A.A. 2008/09 Trieste, 20 febbraio 2009. ANALISI DEI REQUISITI. Requisiti espressi in linguaggio naturale

piera
Download Presentation

PROGETTO DI BASI DI DATI PER UNA DITTA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PROGETTO DI BASI DI DATI PER UNA DITTA TESINA PER L'ESAME DI BASI DI DATI MIOTTO MATTEO UNIVERSITA' DEGLI STUDI DI TRIESTE CORSO DI LAUREA TRIENNALE IN INGEGNERIA INFORMATICA A.A. 2008/09 Trieste, 20 febbraio 2009

  2. ANALISI DEI REQUISITI • Requisiti espressi in linguaggio naturale • Operazioni previste • Glossario dei termini • Strutturazione dei requisiti

  3. REQUISITI ESPRESSI IN LINGUAGGIO NATURALE [OTTENUTI DALL' INTERVISTA CON IL CLIENTE] • Si vuole realizzare una base di dati per una societàche si occupa di isolamenti acustici e termici interni ed esterni, dipinture di ogni genere, pavimenti in resine e piccoli restauri.I dati che si vogliono memorizzare riguardano il personale, i clienti, i cantieri (terminati e in esecuzione), i fornitori, gli stati delle proposte di preventivo, gli stati dei pagamenti delle fatture, le ore lavorate dal personale e il listino prezzi (prestazioni) della società. Si desidera tener traccia dei preventivi proposti vari clienti e delle fatture emesse. • Il personale della dittaè composto dai soci, dai dipendenti e dai prestatori di manodopera che, occasionalmente, si uniscono ai primi per la realizzazione di una qualche opera. • Per quanto riguarda ognuna di queste persone si intende tener conto dei dati personali quali nome, cognome, indirizzo, recapiti telefonici ed e-mail (anche multipli). Per quanto riguarda i dipendenti rappresentiamo anche codice fiscale, data assunzione e tipo di contratto. Per quanto riguarda i soci si desidera memorizzare il codice fiscale. Per i prestatori di manodopera (in genere artigiani) si vuole memorizzare la loro partita iva.Si vuole inoltre tener traccia delle ore lavorate dal personale nei vari cantieri, indicando il giorno e il relativo numero di ore lavorate. • Per i clienti, identificati da un codice, si vogliono memorizzare recapiti telefonici (anche multipli) e indirizzi e-mail (anche multipli). I clienti possono essere privati o imprese. Se i clienti rientrano nel primo caso memorizziamo codice fiscale, nome, cognome e indirizzo mentre, se rientrano nel secondo caso, rappresentiamo il nome dell’impresa, la partita iva, il possibile sito web, l’indirizzo della sede legale e l’indirizzo della sede operativa.Ogni cliente può possedere più cantieri, richiedere più preventivi e pagare più fatture. • Per i cantieri, si vogliono memorizzare dati quali nome, sito in cui si trova, data inizio lavori, presunta data di termine dei lavori e lo stato del cantiere (in fase di realizzazione o terminato).A scopo di promemoria per la società, si vogliono mantenere i codici delle bolle, emesse dai fornitori, riguardanti il materiale acquistato per i cantieri.Per quanto riguarda i fornitori rappresentiamo il nome, la partita iva, la sede legale e quella operativa, il possibile sito web, i recapiti telefonici e l'indirizzo e-mail. • Per il listino delle prestazioni, ogni prestazione è identificata da un codice ed è rappresentata da dati quali nome prestazione, prezzo unitario (per tutte le prestazioni l’unità di misura è €/mq) e breve descrizione. RACCOLTA DEI REQUISTI

  4. REQUISITI ESPRESSI IN LINGUAGGIO NATURALE [OTTENUTI DALL' INTERVISTA CON IL CLIENTE] • Per i preventivi, numerati, rappresentiamo la data di emissione, la data di scadenza e l’importo totale.Si vuole memorizzare anche il dettaglio preventivo, rappresentato dall’elenco delle prestazioni, le relative quantità e importo (non comprensivo di iva). Per quanto riguarda la proposta di preventivo si vuole tener conto dello stato di presa visione (si o no) e di accettazione (si o no). • Per le fatture emesse, i dati da memorizzare sono il numero della fattura (progressivo), la data di emissione, il codice fiscale o la partita iva del cliente, il totale imponibile, il totale iva e il totale comprensivo di iva.Si vuole memorizzare il dettagliofattura, rappresentato dall’elenco delle prestazioni, le relative quantità, l’importo e l’iva applicabile ad ogni prestazione (dato che quest’ultima può essere variabile). Per quanto riguarda il dettaglio non è importante memorizzare l’ordine con il quale i dettagli compaiono nella fattura. • Per quanto riguarda il pagamento di una fattura rappresentiamo lo stato (pagato o non pagato), la modalità di pagamento e la data di pagamento. RACCOLTA DEI REQUISTI

  5. OPERAZIONI PREVISTE SULLA BASE DI DATI OPERAZIONI PREVISTE

  6. OPERAZIONI PREVISTE SULLA BASE DI DATI OPERAZIONI PREVISTE

  7. GLOSSARIO DEI TERMINI GLOSSARIO DEI TERMINI

  8. GLOSSARIO DEI TERMINI GLOSSARIO DEI TERMINI

  9. Strutturazione dei requisiti

  10. Strutturazione dei requisiti

  11. Strutturazione dei requisiti

  12. PROGETTAZIONE CONCETTUALE • Analisi delle entità e delle relazioni • Costruzione schema Entità-Relazione • Business rules

  13. STRATEGIA DI PROGETTO • Per lo sviluppo dello schema concettuale si considera una strategiamista (o ibrida). Come previsto da tale strategia: • Si definisce uno schemascheletro contenente i concetti principali dell’applicazione. • Successivamente si considereranno questi concetti, anche separatamente, e si procederà per raffinamentisuccessivi, fino ad ottenere lo schema entità relazione finale. • SCHEMA SCHELETRO PROGETTAZIONE CONCETTUALE

  14. SPECIALIZZAZIONE ENTITA' CLIENTE • SPECIALIZZAZIONE ENTITA' PERSONALE PROGETTAZIONE CONCETTUALE Il cliente della ditta può essere privato oppure un impresa . La generalizzazione dell’entità cliente è dunque totaleedesclusiva dato che un cliente o è privato o è un impresa. Il personale della ditta può essere suddiviso in dipendenti, soci e prestatori di manodopera. La generalizzazione che ne consegue è totaleedesclusiva, dato che ciascun componente del personale può esser solamente o dipendente o socio o prestatore di manodopera.

  15. RAFFINAMENTO ENTITA' FATTURA • RAFFINAMENTO ENTITA' PREVENTIVO PROGETTAZIONE CONCETTUALE Il concetto di fattura ha proprietà significative (numero, totale imponibile, totale iva, totale, ecc.). Esso, però, è composto da un elenco di prestazioni, ognuna avente quantità e importi differenti. Anche le prestazioni hanno delle proprietà significative (ad es. prezzo unitario) ed hanno un esistenza autonoma. E' possibile dunque distinguere due entità, prestazione e fattura, associate da un concetto comune: il dettaglio, ovvero la rappresentazione della prestazione nelle quantità effettuate che la fattura vuole addebitare. Il raffinamento di tale entità viene effettuatoper le stesse motivazioni che hanno spinto il raffinamento dell’entità fattura. Si distingueranno dunque le entità fattura e preventivo, associate dalla relazione dettaglio preventivo.

  16. ULTERIORI ENTITA' E RELAZIONI PROGETTAZIONE CONCETTUALE Affinché si possano eseguire le prestazioni all’interno di un cantiere, è necessario ordinare il materiale. Solamente per scopi informativi (interni alla ditta), si desidera mantenere traccia delle bolle che i fornitori emettono alla consegna del materiale. A tal fine vengono aggiunte l’entità fornitore e la relazione emissione bolla che associa le due entità (cantiere e fornitore).In tal modo si potrà tenere conto delle bolle emesse da un certo fornitore per il materiale fornito ad un certo cantiere.

  17. SCHEMA ENTITA' RELAZIONE FINALE PROGETTAZIONE CONCETTUALE Lo schema E-R finale deriva dall’accorpamento dei vari raffinamenti applicati allo schema scheletro.

  18. ANALISI DELLE ENTITA' PROGETTAZIONE CONCETTUALE

  19. ANALISI DELLE ENTITA' PROGETTAZIONE CONCETTUALE

  20. ANALISI DELLE ENTITA' PROGETTAZIONE CONCETTUALE

  21. ANALISI DELLE ENTITA' PROGETTAZIONE CONCETTUALE

  22. ANALISI DELLE RELAZIONE E DELLE CARDINALITA' PROGETTAZIONE CONCETTUALE

  23. ANALISI DELLE RELAZIONE E DELLE CARDINALITA' PROGETTAZIONE CONCETTUALE

  24. ANALISI DELLE RELAZIONE E DELLE CARDINALITA' PROGETTAZIONE CONCETTUALE

  25. BUSINESS RULES PROGETTAZIONE CONCETTUALE Descrizione di concetti non esprimibili con il modello concettuale

  26. BUSINESS RULES PROGETTAZIONE CONCETTUALE Descrizione di concetti non esprimibili con il modello concettuale

  27. SCHEMA ENTITA' RELAZIONE FINALE CON ATTRIBUTI E CARDINALITA' PROGETTAZIONE CONCETTUALE

  28. PROGETTAZIONE logica • Analisi delle prestazioni • Analisi delle ridondanze schema E-R • Eliminazione generalizzazioni • Partizionamento/accorpamento di concetti • Scelta identificatori principali • Schema E-R ristrutturato • Traduzione verso il relazionale

  29. ANALISI DELLE PRESTAZIONI SU SCHEMA E-R [TAVOLA DEI VOLUMI] PROGETTAZIONE LOGICA Nella tavola dei volumi vengono riportati tutti i concetti dello schema concettuale (entità e relazioni) con il volume previsto a regime.

  30. ANALISI DELLE PRESTAZIONI SU SCHEMA E-R [TAVOLA DELLE OPERAZIONI] PROGETTAZIONE LOGICA Nella tavola delle operazioni si riporta, per ogni operazione, la frequenza prevista e un simbolo indicante se l'operazione è interattiva (I) o batch(B).

  31. ANALISI DELLE PRESTAZIONI SU SCHEMA E-R [TAVOLA DELLE OPERAZIONI] PROGETTAZIONE LOGICA Nella tavola delle operazioni si riporta, per ogni operazione, la frequenza prevista e un simbolo indicante se l'operazione è interattiva (I) o batch(B).

  32. ANALISI DELLE RIDONDANZE PROGETTAZIONE LOGICA Si può notare inoltre la presenza di attributi derivabili e quindi di ridondanze. Gli attributi che generano tali ridondanze sono: Si confrontano ora gli indici di prestazione in caso di presenza o assenza dei dati ridondanti RELATIVI ALL'ENTITA' FATTURA. Così facendo è possibile decidere se eliminare o mantenere tali ridondanze.

  33. TAVOLE DEGLI ACCESSI IN PRESENZA DI RIDONDANZA • TAVOLE DEGLI ACCESSI IN ASSENZA DI RIDONDANZA PROGETTAZIONE LOGICA Si confrontano ora gli indici di prestazione in caso di presenza e assenza dei dati ridondanti. Così facendo è possibile decidere se eliminare o mantenere tali ridondanze. Per gli accessi in scrittura si considera un costodoppio.

  34. ANALISI DELLE RIDONDANZE: CONSIDERAZIONI PROGETTAZIONE LOGICA • Dall'analisi effettuata ,in assenza dei dati ridondanti: • Totale imponibile (entità fattura); • Totale IVA (entità fattura); • Totale (entità fattura); • si effettueranno mediamente: • 10 accessi/settimana in meno nell'operazione 1 (inserimento dettaglio); • 20 accessi/settimana in meno nell'operazione 2 (aggiornamento dettaglio); • Stesso numero di accessi/settimana nell'operazione 3 (visualizzazione fattura e relativi dettagli); • Inoltre, la presenza dei dati ridondanti sopra citati, comporterebbe un inutileutilizzo di spaziosudisco necessario alla loro memorizzazione. • Si elimineranno, inoltre, gli attributiridondanti relativi alla relazione "dettagliofattura". Tale scelta è giustificata dal risparmio che si ottiene sia in termini di accessi (in scrittura) sia in termini di spazio. SOLUZIONI ADOTTATE Dalle considerazioni fatte, si adottano le seguenti soluzioni:

  35. ANALISI DELLE RIDONDANZE PROGETTAZIONE LOGICA In questo frammento di schema possiamo notare la presenza di un ciclo, riconoscendo, inoltre, un'associazione derivabile (tratto rosso). Quest'ultima è infatti derivabile dall'associazione proprietà (tratto verde). SOLUZIONE ADOTTATA Eliminazione dell’associazione ridondante (tratto rosso)

  36. ELIMINAZIONE DELLA GENERALIZZAZIONE CLIENTE PROGETTAZIONE LOGICA SOLUZIONE ADOTTATA Si può osservare che le entità figlie "privato" ed "impresa" hanno degli attributi che li distinguono. Inoltre ci sono operazioni che fanno riferimento solamente alle occorrenze figlie. Risulta quindi preferibile lasciare le due entità "privato" ed "impresa" aggiungendo due associazioni uno a uno tra queste entità e l'entità cliente. Le entità "privato" ed "impresa" sono identificate esternamente dall'entità "cliente". Vantaggi: Così facendo si evita di avere attributi con possibili valori nulli sull'entità genitore (della generalizzazione) e riduciamo le dimensione delle relazioni (del modello relazionale). Il fatto di avere relazioni di dimensioni abbastanza ridotte, a livello pratico, permetterà di recuperare più dati ad ogni accesso. Svantaggi: Aumento del numero di accessi. Aggiunta di un vincolo: ogni occorrenza di "cliente" deve partecipare o ad un'occorrenza di "dati privato" oppure a un'occorrenza di "dati impresa".

  37. ELIMINAZIONE DELLA GENERALIZZAZIONE PERSONALE PROGETTAZIONE LOGICA SOLUZIONE ADOTTATA Si può osservare che le entità figlie "dipendente", "socio" e "prestatore di mandopera" hanno degli attributi che li distinguono. Inoltre ci sono operazioni che fanno riferimento solamente alle occorrenze figlie. Risulta quindi preferibile mantenere tali entità aggiungendo tre associazioni uno a uno tra queste entità e l'entità "personale".Le entità "dipendente", "socio" e "prestatore di mandopera" sono identificate esternamente dall'entità "personale". Vantaggi: Così facendo si evita di avere attributi con possibili valori nulli sull'entità genitore (della generalizzazione) e riduciamo le dimensione delle relazioni (del modello relazionale). Il fatto di avere relazioni di dimensioni ridotte, a livello pratico, permetterà di recuperare più dati ad ogni accesso. Svantaggi: Aumento del numero di accessi. Andrà aggiunto un vincolo: ogni occorrenza di "personale" deve partecipare o ad un'occorrenza di "dati dati dipendente" oppure a un'occorrenza di "dati socio" oppure a un'occorrenza di "dati prestatore".

  38. PARTIZIONAMENTO/ACCORPAMENTO DI CONCETTI : ATTRIBUTI COMPOSTI PROGETTAZIONE LOGICA

  39. PARTIZIONAMENTO/ACCORPAMENTO DI CONCETTI : ATTRIBUTI COMPOSTI PROGETTAZIONE LOGICA ATTRIBUTI COMPOSTI: CONSIDERAZIONE FINALE Con le soluzioni sopra adottate (riguardanti i concetti PRIVATO ed IMPRESA) possiamo quindi trasferire gli attributi "via", "città", "provincia" e "CAP" dalle entità "privato" ed "impresa" all'entità "cliente", dato che le entità "privato" e "impresa", nella progettazione concettuale, erano specializzazioni dell'entità "cliente. Inoltre le operazioni più frequenti che vengono effettuate sulle entità "privato" ed "impresa" non utilizzano questi attributi. - Così facendo riduciamo la dimensione di queste 2 relazioni (modello relazionale) ottenendo un miglioramento delle prestazioni. - Con tale soluzione si evita l'inserimento di 4 attributi sia nell'entità "privato" che nell'entità "impresa", con un risparmio di 4 attributi e quindi, un risparmio in termini di spazio utilizzato.

  40. PARTIZIONAMENTO/ACCORPAMENTO DI CONCETTI: ATTRIBUTI MULTIPLI PROGETTAZIONE LOGICA

  41. SCELTA IDENTIFICATORI PRINCIPALI PROGETTAZIONE LOGICA • Gli identificatori sono utilizzati per stabilire i legami tra dati in relazioni diverse. Inoltre i DBMS richiedono tali identificatori per la costruzione degli indici. Per la scelta di un identificatore sono stati considerati i seguenti criteri: • Gli attributi con valori nulli non possono costituire identificatori principali; • Un identificatore costituito da uno o da pochi attributi è da preferire a identificatori costituiti da molti attributi; • Per garantire che gli indici siano di dimensioni ridotte; • Un identificatore interno è da preferire a un identificatore esterno; • Dato che gli identificatori esterni verranno tradotti in chiavi che includono gli identificatori delle entità coinvolte nell'identificazione esterna.

  42. SCHEMA E-R RISTRUTTURATO PROGETTAZIONE LOGICA

  43. TRADUZIONE VERSO IL RELAZIONALE: SCHEMI DI RELAZIONALE PROGETTAZIONE LOGICA PRESTAZIONE (IDPrestazione, Nome, PrezzoUnitario, Descrizione) DETTAGLIOFATTURA (Prestazione, Fattura, Quantità, IVA) DETTAGLIOPREVENTIVO (Prestazione, Preventivo, Quantità) FATTURA (Numero, DataEmissione, Stato, DataPagamento, TipoPagamento, Cantiere) PREVENTIVO (Numero, DataEmissione, DataScadenza, PresaVisione, Accettazione, Cliente) CLIENTE (IDCliente, Telefono1, Telefono2, Via, Città, Provincia, CAP, Email) CANTIERE (IDCantiere, Nome, DataInizio, DataFine, StatoLavori, Via, Città, Provincia, CAP, Cliente) PRIVATO (Cliente, Nome, Cognome, CodiceFiscale) IMPRESA (Cliente, Nome, PartitaIVA, SitoWeb) EMISSIONEBOLLA (Cantiere, Fornitore, CodiceBolla) ORELAVORATE (Cantiere, Personale, OreLavorate, Data) FORNITORE (PartitaIVA, Nome, Telefono1, Telefono2, Email, SitoWeb) INDIRIZZOFORNITORE (IDIndirizzo, Fornitore, Commento, Via, Città, Provincia, CAP) PERSONALE (IDPersonale, Nome, Cognome, Telefono1, Telefono2, Email, Via Città, Provincia, CAP) DIPENDENTE (Personale, CodiceFiscale, TipoContratto, DataAssunzione) SOCIO (Personale, CodiceFiscale) PRESTATOREMANODOPERA (Personale, PartitaIVA)

  44. TRADUZIONE VERSO IL RELAZIONALE [RAPPRESENTAZIONE GRAFICA]: VINCOLI DI INTEGRITA' REFERENZIALE PROGETTAZIONE LOGICA

  45. TRADUZIONE VERSO IL RELAZIONALE [RAPPRESENTAZIONE GRAFICA] PROGETTAZIONE LOGICA

  46. TRADUZIONE VERSO IL RELAZIONALE PROGETTAZIONE LOGICA

More Related