Si vuole progettare un database per la gestione dei prestiti di
una biblioteca personale.
La progettazione deve tenere conto di quanto emerso in fase di
analisi:
• Il proprietario può prestare più libri ai suoi amici
• Gli amici vengono identificati univocamente attraverso il
soprannome
• Il proprietario non possiede libri aventi lo stesso titolo
• Il proprietario prende nota della data di restituzione dei libri
• Il dominio applicativo è rappresentato da tutte le entità coinvolte nel
sistema Biblioteca Personale, in particolare quelle relative alla
gestione dei prestiti di libri.
LIBRI
N
PRESTITO
AMICI
N
Tra l’entità libri ed l’entità amici esiste un’associazione
molti – a – molti in quanto:
• un libro può essere prestato a uno o più amici;
• e un amico può pretendere in prestito uno o più libri.
1
:
N
LIBRI
AMICI
N
N
:
1
:
PRESTITO
N
Dalla relazione N:N deriva una ulteriore entità ( Prestito) i cui
attributi saranno i seguenti:
• Id Prestito : codice univoco del prestito;
• Campo link alla tabella Amici : definisce l’amico che ha preso
il libro in prestito;
• Campo link alla tabella Libri : definisce il libro oggetto del
prestito;
• Data Restituzione Prestito : insieme delle date della fine del
prestito.
Nel nostro esempio le entità individuale sono:
•LIBRI
•AMICI
Per l’entità Libri sono stati individuati i seguenti attributi:
• Id Libri : codice univoco per identificazione libro
• Titolo Libro : insieme di tutti i titoli dei libri presenti in biblioteca
• AnnoPubblicazioneLibri: anno di pubblicazione dei libri presenti in
biblioteca
• CollocazioneLibri: posto in cui si trovano i libri all’interno della
biblioteca
Per l’entità Amici sono stati individuati i seguenti attributi:
•
•
•
•
•
•
•
IdAmici: codice univoco per identificazione amico
NomeAmici: insieme di tutti i nomi degli amici
CognomeAmici: insieme di tutti i cognomi degli amici
Soprannome Amico: insieme dei soprannomi degli amci
IndirizzoAmici: insieme degli indirizzi degli amici
TelefonoAmici: insieme dei numeri di tel degli amici
E-mai Amici: insieme delle email degli amici
Nome campo
Tipo Campo
Dimensione
Vincoli
IdAmici
Numerico
Intero Lungo
Primary Key
NomeAmici
Testo
20
Not Null
CognomeAmici
Testo
30
Not Null
SoprannomeAmici
Testo
50
Unique
IndirizzoAmici
Testo
40
Not Null
TelefonoAmici
Numerico
15
Not Null
E-mai Amici
Testo
50
Note
Nome campo
Tipo campo
Dimensione
Vincoli
IdLibri
Numerico
Intero Lungo Primary Key
TitoloLibri
Testo
50
AnnoPubblicazioneLibri
Data
CollocazioneLibri
Numerico
Unique
Note
Nome campo
Tipo campo Dimensione
IdPrestito
Numerico
Intero Lungo Primary Key
FkLibri Prestito
Numerico
Intero Lungo Foreign Key Link alla
Tabella
Libri
FkAmici Prestito
Numerico
Intero Lungo Foreign Key Link alla
Tabella
Amici
Data restituzione prestito Data
Vincoli
Not Null
Note
N
:
MEDICO
1
REPARTO
N
RICOVERO
PAZIENTI
N
MEDICO
N
:
1
REPARTO
Tra l’entità medico e l’entità reparto esiste una relazione 1 : N
in quanto:
• in un reparto ci sono più medici;
• più medici sono presenti in un reparto.
1
:
N
REPARTO
PAZIENTI
N
N
:
:
RICOVERO
1
N
Tra l’entità reparto e l’entità pazienti esiste un’associazione
molti – a – molti in quanto:
• in un reparto possono essere ricoverati uno o più pazienti;
• uno o più pazienti possono essere stati ricoverati in uno o più reparti.
In questo esempio le entità individuale sono:
• Paziente
•Reparto
•Medico
Per l’entità Paziente sono stati individuati i seguenti attributi:
•Cod Paziente : chiave primaria nonché codice univoco per identificazione paziente
•Nome Paziente
•Cognome Paziente
Per l’entità Reparto sono stati individuati i seguenti attributi:
•Cod Reparto: chiave primaria nonché codice univoco per identificazione reparto
•Nome Reparto
•Primario Reparto
Per l’entità Medico sono stati individuati i seguenti attributi:
• Matricola Medico chiave primaria nonché codice univoco per identificazione medico
• Nome Medico
• Cognome Medico
• Reparto Medico: campo link alla tabella Reparto (chiave esterna)
Dalla relazione N : N esistente tra l’entità Reparto e l’entità Pazienti,
deriva una ulteriore entità ( Ricovero) i cui attributi sono i seguenti:
• Paziente : Campo link alla tabella Pazienti (chiave esterna)
• Inizio Ricovero
•Fine Ricovero
•Reparto: Campo Link alla tabella Reparto (chiave esterna)
Dalle considerazioni fin qui fatte, posso concludere dicendo che:
Nella Tabella Pazienti, il Cod Pazienti, essendo chiave primaria, non può
assumere valori nulli, anzi se viene a mancare questo valore si perde il
collegamento con la Tabella Ricoveri. Gli attributi Nome e Cognome, anche
questi importanti identificano in maniera univoca, insieme al Codice, il
Paziente.
Stesso discorso viene fatto per la Tabella Reparto.
Nella Tabella Ricoveri tutti gli attributi non possono assumere valori nulli,
in quanto l’attributo Paziente e l’attributo Reparto sono chiavi esterne che
servono, come già detto, da collegamento per le rispettive tabelle; invece
data inizio e fine ricovero, sono importanti, a mio avviso, per avere
conoscenza delle stanze libere o occupate all’interno di un reparto.
Nella Tabella Medici gli attributi che non posso assumere valori nulli sono:
la matricola (chiave primaria) in quanto identifica in maniera univoca il
medico e il reparto, che essendo chiave esterna, crea il collegamento con la
tabella Reparto. Gli altri attributi, quali, il Nome e Cognome medico
possono assumere valori nulli perché il medico viene già identificato
attraverso la matricola.
