Upload
giovannetta-tonelli
View
222
Download
0
Embed Size (px)
Citation preview
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