Newsgroup: it.comp.software.database
Titolo: gestione biblioteca

Salve a tutti, per un semestre intero non ho potuto seguire il corso di basi
di dati, adesso dovrei realizzare una serie di piccoli progettini, purtroppo
però parto da zero. Ne ho gia relizzati alcuni ma adesso ne ho trovato uno
che dovrebbe essere facile ma non riesco a capire una cosa. Allora, devo
gestire una biblioteca di medie dimensioni ed ho difficoltà a gestire il
prestito dei libri. Ho individuato tre tabelle: una per i libri, una per gli
utenti della biblioteca ed una per i prestiti. Nella tabella dei libri ho un
campo che mi indica il numero di copie disponibili. Come faccio ogni volta
che viene prestato un libro a decrementare il numero di copie disponibili??
devo per forza fare una INSERT e poi un UPDATE??
Inoltre, voi come lo organizzereste il database?!? grazie mille in
anticipo!!


Cercando di non darti la pappa pronta, provo a farti ragionare...
Innanzitutto che dati metteresti nella tabella dei libri?
Quali nella tabella dei prestiti?
Come gestiresti il prestito?
M.
-- 
"- in Italia cosa rischia uno che tortura?
- ..Se è una tortura e via, poco.. Se ha anche scaricato musica da 
Internet, quattro anni"
Sergio Staino (Bobo e figlia, maggio 2004)

 Come gestiresti il prestito?
se non dovessi anche contare il numero di copie disponibili, metterei in
relazione "codice_libro" della tabella libro con il "codice_libro" della
tabella prestiti, ed il "codice_socio" della tabella prestiti con il
"codice_socio" della tabella socio. E credo dovrebbe funzionare. O
sbaglio?!?


 sbaglio?!?
E se tu gestissi le copie come libri a sè stanti cosa succederebbe?



cioè ogni singola copia è un libro a se stante??
esempio:
codice_copia = 1, titolo = la divina commedia
codice_copia= 2, titolo = la divina commedia
così?!?

SongBird wrote:

Si...


 - ..Se č una tortura e via, poco.. Se ha anche scaricato musica da


 "id_socio, id_copia"... così potrebbe funzionare?
Perché complicarti la vita con una ulteriore tabella?
Non sarebbe più semplice avere nella stessa tabella dei libri le varie 
copie? Avere un ID di catalogo sul libro non ti costa nulla...
Con la struttura "libro" {codice_libro, titolo, autore, anno 
pubblicazione, classificazione}
avrai in tabella dei dati tipo:
01001A, "LA DIVINA COMMEDIA", "Dante Alighieri", null, 01
01001B, "LA DIVINA COMMEDIA", "Dante Alighieri", null, 01
01001C, "LA DIVINA COMMEDIA", "Dante Alighieri", null, 01
02001A, "Il Nome della Rosa", "Umberto Eco", null, 02
02002A, "I Promessi sposi", "Alessandro Manzoni", null, 02
02002B, "I Promessi sposi", "Alessandro Manzoni", null, 02
Ogni volume è codificato e catalogato.
Quando è in prestito lo aggiungi alla tabella dei prestiti.
A questo punto sulla tabella dei prestiti si possono fare delle 
considerazioni... quali?
M.
-- 
"- in Italia cosa rischia uno che tortura?
- ..Se è una tortura e via, poco.. Se ha anche scaricato musica da 



Se realizzo la tabella prestiti in questo modo:
Prestito (id_socio, codice_libro, data_inizio, data_restituzione)
l'id_socio lo metto in relazione con l'id_socio della tabella socio, stessa
cosa per il codice_libero che sarà messo in relazione con il campo
codice_libro della tabella libro. A questo punto penso debba essere inserito
nella tabella prestiti, anche un campo del tipo "restituito", in questo modo
posso sapere se un libro che è stato dato in prestito (e che quindi non
dovrebbe essere disponibile) è stato restituito (e quindi è disponibile)
giusto?!?

 giusto?!?
Tu vuoi tenere traccia di tutte le persone che hanno preso un libro in
prestito o ti basta sapere se c'è o non c'è (e in questo caso chi e quando
l'ha preso)?
Il campo "restituito" e' già incluso in "data_restituzione" non mi pare
occorra aggiungerlo.
Ciao!
Fabrizio
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/


Per "data restituzione" intendo la data fissata per la restituzione, non la
data in cui il libro è stato restituito. Il campo "restituito" mi serve per
sapere se il libro è stato restituito. Effettivamente potrei anche
sostituire questo campo con un altro in cui inserirei la data effettiva di
consegna.

 giusto?!?
Si è no.
Analizziamo il flusso di informazioni:
Tutti i libri sono in biblioteca.
Un socio prende un libro in prestito.
	Che dati abbiamo?
Considera che uno stesso volume non può essere in prestito due volte.
Puoi sfruttare il campo stesso della data_restituzione come flag di 
restituzione.
Quindi per sapere se un libro è in prestito cosa fai?
Fai una ricerca dove?


 consegna.
La data di restituzione prevista può essere calcolata tramite la 
data_inizio + i gg di prestito. Non è necessario al momento averla in 
tabella.
M.


per vedere se un libro è in prestito devo controllare se ogni copia del
libro è disponibile oppure no. prima mi seleziono le copie che "dovrei"
avere per ogni libro (ipotizzo quindi di avere una tabella per le copie ed
una per i libri), e poi vedo se le copie sono presenti nella tabella dei
prestiti, e per ogni copia che sarà presente nella tabella dei prestiti
controllo se il campo "data di restituzione" è vuoto oppure no... devo fare
qualcosa del genere o sbaglio?!?

 qualcosa del genere o sbaglio?!?
Esatto.
Metti in relazione uno a molti (right join) la tabella dei libri con la 
tabella dei prestiti filtrando quest'ultima per i record che hanno il 
campo data_restituzione a null. In questo modo vedi subito quali sono i 
libri in prestito.



ok... quindi i miei problemi dovrebbero essere stati risolti. Per quanto
riguarda la normalizzazione, credi ci siano delle tabelle da normalizzare?!?

 riguarda la normalizzazione, credi ci siano delle tabelle da normalizzare?!?
Per come stavamo strutturando la tabella libri sarebbe meglio fare come 
avevi anticipato tu. Ciò avere un punto di raccolta dell'anagrafica del 
libro (id_libro, titolo, autore, editore, isbn) e un punto di raccolta 
delle informazioni relative alle copie del libro (id_volume, id_libro, 
dislocazione, data_acquisto, data_restauro, data_macero, etc)
Non mi pare ci sia altro. Molto dipende anche dalla complessità che vuoi 
raggiungere. Puoi fare anche studi statistici: vedere quale libro viene 
preso in prestito più spesso (lo ricavi dalla tabella dei prestiti); 
dare uno storico dei prestiti per un socio (sempre ricavato dalla 
tabella dei prestiti) e così via.
Spero di esserti stato d'aiuto.
M.



certo che mi sei stato d'aiuto... stamattina non sapevo come organizzare
l'archivio, e non avevo idea di come fare a gestire il prestito dei libri...
direi che mi sei stato di grande aiuto... grazie :-)

 Ogni volume è codificato e catalogato.
Non è normalizzato e secondo me c'è una ridondanza eccessiva.
Mi sembra molto meglio come aveva proposto lui, una tabella dove memorizzi
le informazioni relative al libro e una tabella dove memorizzi le
informazioni relative alla copia del libro a disposizione della biblioteca
(e quindi dove associ un identificativo del libro, che potrebbe essere il
codice ISBN dove diponibile, con il codice d'archivio della biblioteca).
Con questa organizzazione sarebbe anche possibile organizzare un catalogo di
libri, anche eventualmente non ancora o non più a disposizione della
biblioteca ma dei quali la biblioteca vuole tenere le informazioni
registrate. Con la tua soluzione invece non si può. Senza parlare di tutti
gli altri problemi che la ridondanza può causare e che tutti noi conosciamo
bene.

 wrote in message
eMkxc.431058$rM4.17...@news4.tin.it...

Non avevo letto gli altri messaggi.
Chiedo scusa.

 
Nessun problema. Sicuramente m'è sfuggito qualcosa. Ad esempio gli 
autori, anch'essi possono essere messi in una tabella separata in modo 
da ottimizzarne la ricerca; anche gli editori...


 da ottimizzarne la ricerca; anche gli editori...
Infatti io farei così per un progetto serio. Ed è quello che generalmente si
richiede ad un DB normalizzato.
Poi bisogna vedere quanto lo vuole complesso e completo il professore che
deve giudicare questo esame.

 deve giudicare questo esame.
E usare due tabelle diverse per i libri prestati e restituiti e per quelli
in prestito, in modo da velocizzare la ricerca dei secondi (operazione credo
eseguita molto più spesso), avrebbe per voi un senso o si guadagna talmente
poco che è inutile? (certo dipende dal numero di utenti e da quanto tempo
funziona il sistema)


 funziona il sistema)
A me piace poco.
Tra l'altro non è che una persona entra in una biblioteca e chiede di avere
il libro disponibile codice 124, invece entra e chiede "Il signore degli
anelli" è disponibile? Quindi la ricerca la fai su tutti i libri della
biblioteca e questa ti restituirà i codici di tutte le copie e
l'informazione riguardo quali copie sono disponibili e quali no.
In ogni caso, anche se fosse diversamente, avresti un guadagno certamente
trascurabile in termini di tempo per le ricerche e un raddopio del tempo
richiesto per i prestiti. Considera che un database medio non ha problemi a
gestire volumi di centinaia di milioni di record.

Si...
oppure si potrebbe usare un solo record per ogni titolo, con un campo
"copie acquistate" e un campo "copie prestate".
che controindicazioni ti vengono in mente?
saluti.
-- 
Gianni Rondinini
Icem s.r.l. - 
http://www.icem.it
Tel: 
+39 0545 78036
Fax: 
+39 0545 78727

 che controindicazioni ti vengono in mente?
Ogni volta che viene preso in prestito un libro devi modificare il 
record ed aggiornarlo e così in fase di restituzione. Se non sei accorto 
nella gestione degli accessi concorrenti hai il rischio di avere più o 
meno copie prestate di quante in realtà non sia. A questo punto il 
carico di lavoro della Business Logic è troppo elevato con un alto 
rischio di errori e non avresti la possibilità di costruirti uno storico 
dei dati.
Con l'altra soluzione invece quando ti presenti allo sportello del 
prestito sai che quella copia è catalogata ed è univocamente gestita dal 
database, con i vantaggi che questo comporta.
M.