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 PRESTITO AMICI N N 1 : N N : 1

Tra lentità libri ed lentità amici esiste unassociazione 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.

AMICI LIBRI N : N PRESTITO 1 : N N : 1

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 lamico 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 lentità 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 allinterno della biblioteca

Per lentità 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 degli amici

Nome campoTipo CampoDimensioneVincoliNote IdAmiciNumericoIntero LungoPrimary Key NomeAmiciTesto20Not Null CognomeAmiciTesto30Not Null SoprannomeAmiciTesto50Unique IndirizzoAmiciTesto40Not Null TelefonoAmiciNumerico15Not Null E-mai AmiciTesto50

Nome campoTipo campoDimensioneVincoliNote IdLibriNumericoIntero LungoPrimary Key TitoloLibriTesto50Unique AnnoPubblicazioneLibriData CollocazioneLibriNumerico

Nome campoTipo campoDimensioneVincoliNote IdPrestitoNumericoIntero LungoPrimary Key FkLibri PrestitoNumericoIntero LungoForeign KeyLink alla Tabella Libri FkAmici PrestitoNumericoIntero LungoForeign KeyLink alla Tabella Amici Data restituzione prestitoDataNot Null

MEDICO REPARTO PAZIENTI RICOVERO N : 1 N N 1 : N

MEDICO REPARTO N : 1 Tra lentità medico e lentità reparto esiste una relazione 1 : N in quanto: in un reparto ci sono più medici; più medici sono presenti in un reparto.

REPARTOPAZIENTI RICOVERO N : N 1 : N N : 1

Tra lentità reparto e lentità pazienti esiste unassociazione 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 lentità Paziente sono stati individuati i seguenti attributi: Cod Paziente : chiave primaria nonché codice univoco per identificazione paziente Nome Paziente Cognome Paziente Per lentità Reparto sono stati individuati i seguenti attributi: Cod Reparto: chiave primaria nonché codice univoco per identificazione reparto Nome Reparto Primario Reparto Per lentità 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 lentità Reparto e lentità 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 lattributo Paziente e lattributo 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 allinterno 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.