COMPITO 2 CELESTE BONANNO MATR CDL: SDFA

Esercizio 1 ANALISI DEI REQUISITI Si vuole automatizzare la gestione dei prestiti di una biblioteca personale. A tale scopo è necessario memorizzare dati relativi a: Libri Amici Il fine ultimo è quello di ricavare le informazioni relative ai prestiti effettuati ai diversi amici. DOMINIO APPLICATIVO In questo caso il nostro dominio applicativo è rappresentato da tutte le entità coinvolte nel sistema biblioteca personale, in particolare quelle relative alla gestione dei prestiti.

SCHEMA ENTITÀ – RELAZIONI AMICI PRESTITI LIBRI 1 : N N : 1 N N

PROGETTAZIONE CONCETTUALE Nel nostro caso individuiamo le seguenti entità: Libri Amici Osserviamo gli attributi che queste due entità posseggono. 1.LIBRI Per lentità LIBRI sono stati individuati i seguenti attributi: Id libro: codice univoco del libro; Titolo libro: insieme di tutti i libri presenti in biblioteca; Autore Libro: insieme di tutti gli autori presenti nella biblioteca; Casa Editrice: insieme delle case editrici che compongono la raccolta; Anno di pubblicazione. 2.AMICI Per lentità AMICI individuiamo: Id Amico: codice univoco dellamico; Nome Amico: insieme di tutti i nomi del proprietario della biblioteca Soprannome amico: insieme di tutti i soprannomi degli amici del proprietario della biblioteca.

PROGETTAZIONE LOGICA DEFINIZIONE DELLE RELAZIONI AMICILIBRI PRESTITI N : N 1 : N N : 1

Un amico può infatti prendere in prestito più libri e, allo stesso modo uno stesso libro, può essere preso in prestito da più amici nel corso del tempo. Dalla relazione N:N deriva unulteriore entità che chiameremo PRESTITI cui attributi saranno: Id Prestito: codice univoco del prestito; Campo Link alla tabella AMICI: definisce lamico che ha preso in prestito un libro; Campo Link alla tabella LIBRI: definisce il libro che è stato preso in prestito; Data Ritiro Libro; Data Prevista consegna Libro; Data consegna libro

Nome CampoTipo Campo DimensioneVincoliNote Id_Libro NumericoIntero lungoPrimary key Titolo_Libro Testo40NOT NULL Autore_Libro Testo40NOT NULL Casa_ED_Libro Testo40NOT NULL Anno_pubblicazione _Libro Data/oraNOT NULL Nome CampoTipo CampoDimensioneVincoliNote Id_Amico NumericoIntero lungoPrimary key Nome_Amico Testo40NOT NULL Soprannome_Amico Testo40NOT NULL TABELLA AMICI PROGETTAZIONE LOGICA: DEFINIZIONE DELLE CARATTERISTICHE DEGLI ATTRIBUTI TABELLA LIBRI

TABELLA ESAMI Nome CampoTipo CampoDimensioneVincoliNote Id_Prestito NumericoIntero lungo Primary Key Fk_Amico NumericoIntero lungo Foreing Key Link alla tabella Amici Fk_Libro NumericoIntero lungo Foreign Key Link alla tabella Libri Data_Ritiro Data/OraNOT NULL Data_Prevista_C onsegna Data/OraNOT NULL Data_Consegna Data/Ora Come vediamo tutti gli attributi delle entità trattate non possono mai assumere valore nullo tranne la data di consegna del libro che è difficile da poter determinare. In più è necessario imporre il vincolo che la data della consegna debba essere successiva a quella del ritiro.

SCHEMA LOGICO

Esercizio 2

Nome CampoTipo Campo DimensioneVincoliNote Id_Paziente NumericoIntero lungoPrimary Key Nome_Paziente Testo20NOT NULL Cognome_Paziente Testo20NOT NULL DataNascita_Paziente Data/oraNOT NULL Nome CampoTipo Campo DimensioneVincoliNote Cod_Reparto NumericoIntero lungoPrimary Key Nome_Reparto Testo20NOT NULL Primario_Reparto Testo20NOT NULL TABELLA PAZIENTI TABELLA REPARTI

Nome CampoTipo CampoDimensioneVincoliNote Matr_Medico NumericoIntero lungoPrimary Key Nome_Medico Testo20NOT NULL Cognome_Medico Testo20NOT NULL Fk_Cod_Reparto NumericoIntero lungoForeign KeyLink a tabella Reparti TABELLA MEDICI

Nome CampoTipo Campo DimensioneVincoliNote Id_Ricovero NumericoIntero lungoPrimary Key Fk_Paziente_Ricovero NumericoIntero lungoForeign Key Link a tabella Pazienti Fk_Cod_Reparto_Rico vero NumericoIntero lungoForeign Key Link a tabella Reparti Data_Inizio_Ricovero Data/OraNOT NULL Data_Fine_Ricovero Data/Ora TABELLA RICOVERI

CHIAVI Le chiavi che secondo me è necessario inserire in questo data Base sono: Nella tabella PAZIENTI, lattributo Cod_Paziente sarà una Primary Key poiché identifica univocamente un paziente dellospedale; Nella tabella REPARTI, lattributo Cod_Reparto è una Primary Key poiché contraddistingue ogni reparto dellospedale; Nella tabella MEDICI, lattributo Matr_Medico è anchessa una Primary Key poiché identifica univocamente ogni medico dellospedale; Nella tabella RICOVERI: lattributo Fk_Cod_Paziente è una Foreign Key proveniente dalla tabella PAZIENTI; lattributo Fk_Cod_Reparto è lo stesso una foreign key proveniente dalla tabella REPARTI ; Per identificare una singola n-pla possiamo individuare una Super chiave formata da due attributi, Fk_Cod_Paziente e Data_Inizio_Ricovero.

VINCOLI Tabella PAZIENTI, REPARTI e MEDICI: Nessun attributo può essere NULL poiché ogni campo deve univocamente distinguere rispettivamente pazienti, reparti e medici. Nella tabella RICOVERI: Tutti gli attributi sono NOT NULL tranne, anche in questo caso lattributo Data_Fine_Ricovero che non può essere prevista e deve sottostare al vincolo di corrispondere ad una data successiva a quella registrata nel campo Data_Inizio_Ricovero

RELAZIONI REPARTO PAZIENTI MEDICI Più medici possono lavorare nello stesso reparto, ma ogni medico è assegnato ad un singolo reparto, del quale puo essere primario RICOVERI 1 : N N : 1 N N Un reparto può ospitare più pazienti. Un singolo paziente può essere ricoverato in più reparti.

Il risultato con Access