COMPITO 2 CELESTE BONANNO MATR. 570089 CDL: SDFA

COMPITO 2

CELESTE BONANNOMATR. 570089

CDL: SDFA

Esercizio 1

ANALISI DEI REQUISITISi 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 APPLICATIVOIn 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 CONCETTUALENel nostro caso individuiamo le seguenti entità:• Libri• AmiciOsserviamo gli attributi che queste due entità posseggono.1. LIBRIPer l’entità “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. AMICIPer l’entità “AMICI” individuiamo:• Id Amico: codice univoco dell’amico;• 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 LOGICADEFINIZIONE DELLE RELAZIONI

AMICI LIBRI

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 un’ulteriore entità che chiameremo PRESTITI cui attributi saranno:•Id Prestito: codice univoco del prestito;•Campo Link alla tabella AMICI: definisce l’amico 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 Campo Tipo Campo

Dimensione Vincoli Note

Id_Libro Numerico Intero lungo Primary key

Titolo_Libro Testo 40 NOT NULL

Autore_Libro Testo 40 NOT NULL

Casa_ED_Libro Testo 40 NOT NULL

Anno_pubblicazione_Libro

Data/ora NOT NULL

Nome Campo Tipo Campo Dimensione Vincoli Note

Id_Amico Numerico Intero lungo Primary key

Nome_Amico Testo 40 NOT NULL

Soprannome_Amico Testo 40 NOT NULL

TABELLA AMICI

PROGETTAZIONE LOGICA: DEFINIZIONE DELLE CARATTERISTICHE DEGLI ATTRIBUTI

TABELLA LIBRI

TABELLA ESAMI

Nome Campo Tipo Campo Dimensione Vincoli Note

Id_Prestito Numerico Intero lungo

Primary Key

Fk_Amico Numerico Intero lungo

Foreing Key

Link alla tabella Amici

Fk_Libro Numerico Intero lungo

Foreign Key

Link alla tabella Libri

Data_Ritiro Data/Ora NOT NULL

Data_Prevista_Consegna

Data/Ora NOT 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 Campo Tipo Campo

Dimensione Vincoli Note

Id_Paziente Numerico Intero lungo Primary Key

Nome_Paziente Testo 20 NOT NULL

Cognome_Paziente Testo 20 NOT NULL

DataNascita_Paziente Data/ora NOT NULL

Nome Campo Tipo Campo

Dimensione Vincoli Note

Cod_Reparto Numerico Intero lungo Primary Key

Nome_Reparto Testo 20 NOT NULL

Primario_Reparto Testo 20 NOT NULL

TABELLA PAZIENTI

TABELLA REPARTI

Nome Campo Tipo Campo Dimensione Vincoli Note

Matr_Medico Numerico Intero lungo Primary Key

Nome_Medico Testo 20 NOT NULL

Cognome_Medico Testo 20 NOT NULL

Fk_Cod_Reparto Numerico Intero lungo Foreign Key Link a tabella Reparti

TABELLA MEDICI

Nome Campo Tipo Campo

Dimensione Vincoli Note

Id_Ricovero Numerico Intero lungo Primary Key

Fk_Paziente_Ricovero Numerico Intero lungo Foreign Key

Link a tabella Pazienti

Fk_Cod_Reparto_Ricovero

Numerico Intero lungo Foreign Key

Link a tabella Reparti

Data_Inizio_Ricovero Data/Ora NOT NULL

Data_Fine_Ricovero Data/Ora

TABELLA RICOVERI

CHIAVI

Le chiavi che secondo me è necessario inserire in questo data Base sono:•Nella tabella PAZIENTI, l’attributo Cod_Paziente sarà una Primary Key poiché identifica univocamente un paziente dell’ospedale;

•Nella tabella REPARTI, l’attributo Cod_Reparto è una Primary Key poiché contraddistingue ogni reparto dell’ospedale;

•Nella tabella MEDICI, l’attributo Matr_Medico è anch’essa una Primary Key poiché identifica univocamente ogni medico dell’ospedale;

•Nella tabella RICOVERI: l’attributo Fk_Cod_Paziente è una Foreign Key proveniente dalla tabella PAZIENTI; l’attributo 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 l’attributo 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

MEDICIPiù medici possono

lavorare nello stesso reparto, ma ogni

medico è assegnato ad un singolo reparto, del quale puo essere

primario

RICOVERI

1 : N

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