1 / 13

PROGETTAZIONE DI UN DATA BASE TURCO MERY MAT. 565773 CPA

PROGETTAZIONE DI UN DATA BASE TURCO MERY MAT. 565773 CPA. Progetto di un Data Base primo compito. Dominio applicativo. Progetto Logico. Schema concettuale. Schema logico. requisiti. DBMS. Analisi dei requisiti . Con la creazione del Data Base si intende migliorare la gestione

marge
Download Presentation

PROGETTAZIONE DI UN DATA BASE TURCO MERY MAT. 565773 CPA

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. PROGETTAZIONE DI UN DATA BASE TURCO MERY MAT. 565773 CPA

  2. Progetto di un Data Baseprimo compito Dominio applicativo Progetto Logico Schema concettuale Schema logico requisiti DBMS

  3. Analisi dei requisiti Con la creazione del Data Base si intende migliorare la gestione della biblioteca personale. Definire il dominio applicativo vuol dire studiare tutte le componenti, le dinamiche rientranti nell'attività che si intende gestire mediante il data base. A tele scopo dovranno essere tenuti in considerazione i dati relativi a: Nome o soprannome di chi prende il libro; Libri, Prestiti. In tal modo sarà possibile avere informazioni veloci e precise sulla disponibilità di un libro effettuando una ricerca nel DB.

  4. PROGETTAZIONE CONCETTUALE: definizione di dominio, entità, attributi e relazioni La progettazione dei data base necessita una definizione di uno schema concettuale, ossia la definizione di classi di dati necessarie, e le relazioni esistenti tra di esse. Si individuano le ENTITA' , che nel nostro caso specifico sono: AMICI LIBRI PRESTITI Ogni entità è definita a sua volta da una serie di attributi che la compongono.

  5. ENTITA' & ATTRIBUTI Per l'entità AMICI si prevede venga indicato il nome o soprannome, che sarà unico, tale da evitare duplicazioni. Gli attributi saranno perciò: Nome amico; Soprannome; Telefono; E-mail. Per l'entità LIBRI si avranno i seguenti attributi: Titolo; Editore ; Autore; Data pubblicazione. Non sarà necessario attribuire un codice univoco ai libri in quanto è stabilito a priori che non ci sono libri con lo stesso titolo.

  6. ENTITA' & ATTRIBUTI Non sarà necessario attribuire un codice univoco ai libri in quanto è stabilito a priori che non ci sono libri con lo stesso titolo. Dalla combinazione delle precedenti entità affiancate dalla registrazione della data di presa in prestito e della restituzione, scaturisce un'ulteriore entità la cui gestione è ciò che interessa alla fine del progetto in essere: la gestione dei prestiti. Una volta definite le entità ed i loro attributi, si passa alla definizione delle relazioni esistenti tra di esse.

  7. DEFINIZIONE DELLE RELAZIONI Il nostro dominio applicativo è composto da tutte le dinamiche coinvolte nel prestito di un libro. Le relazioni esistenti tra le entità possono essere così schematizzate: AMICO LIBRO PRESTITI

  8. Tra amici e libri esiste una relazione 1: n (uno a molti) caratterizzata dal fatto che un amico può prendere in prestito più libri; un libro invece può essere preso in prestito da un solo amico (per singola operazione di prestito). Tra libri e prestiti esiste una relazione n:1 in quanto un prestito può avere ad oggetto più libri, ma un libro può essere oggetto di un solo prestito per volta. Tra amici e prestiti esiste una relazione 1: n perché un amico può richiedere più prestiti. Definizione delle relazioni

  9. Definizione delle relazioni Ogni entità ed i suoi attributi vengono rappresentati attraverso una tabella. AMICI

  10. LIBRI

  11. PRESTITI

  12. Secondo punto del compito CHIAVI PRIMARIE Tab. PAZIENTI: Codice Tab. REPARTI: codice Tab. MEDICI: Matricola. La tabella ricoveri non ha chiavi primarie VINCOLI DI INTEGRITA' REFERENZIALE: Tab. Reparti: PRIMARIO Tab. Ricoveri: PAZIENTI e REPARTO Tab. Medici: REPARTO La tabella PAZIENTI non ha Foreing key

  13. Delle entità esaminate e dei rispettivi attributi, nessuno dei campi esposti può presentare un valore nullo, in quanto: Un paziente verrà registrato nel data base al momento del ricovero, quindi verranno registrati tutti i dati utili alla sua identificazione, il reparto in cui viene ricoverato, e attraverso un link, anche il primario del reparto. Nella registrazione del reparto dovrà necessariamente essere indicato il nome del reparto, e il primario verrà attribuito attraverso un link alla tabella “Medici”. La tabella “medici” riporterà tutti gli estremi del medico, e un link relativo al reparto gestito. Da tutte queste interazioni scaturisce la tabella dei “Ricoveri” nella quale verranno annotati tutti i dati relativi al ricovero comprese le date di ingresso e dimissione dall'ospedale. Si intuisce come ogni attributo sia indispensabile al fine di individuare con precisione un ricovero con tutti i suoi dati, rendendo quindi possibile effettuare una ricerca su ogni singolo attributo ed ottenere una risposta precisa e dettagliata. VALORI NULLI

More Related