[Php-avanzado] Tablas de Bibliotech

[Leonardo Tadei - Pegasus Tech Supply]

Hola Pehuén,

El mar, 07-01-2014 a las 22:42 -0300, Fernando Pehuén Borsani escribió:
> Hola Profe! Acá le envío la siguiente iteración de las tablas.
> 
> Con respecto a las correcciones de la última versión: 
> 
> LT>"No entiendo la referencia el Extravío al Préstamo. Esto se asumir que
> solo se pueden extraviar libros prestados, lo cual es una situación
> demasiado ideal..."
> La SRS solo contempla el extravío como la unidad que un asociado nunca
> devolvió (es una biblioteca ideal nomás).

	Ok.

> LT>"(eso, o seguís pensado que "un préstamos" viene a la biblioteca para ser
> devuelto ;-) )"
> No es eso profe, lo que pienso es que en el préstamo están los datos que
> necesito (como asociado y libro), de ahí la relación entre DEVOLUCIONES y
> PRESTAMOS.

	Bueno...
	Habría que agregárle a Préstamos algunos datos del Asociado, como
Nombre y Apellido, de manera tal que se pueda borrar un Asociado (y sus
Cuotas porque no serían de utilidad) sin que el Préstamos pierda datos
de a quién fue hecho.
	Sería necesaria la funcionalidad, independientemente de esto, que no se
pueda borrar un Asociado si tiene préstamos vigentes, pero como esto es
una cuestión técnica, no vale mucho la pena tenerlo como una
funcionalidad en la SRS.

> LT> 'Los idEmpleado, nombre y apellido tienen que estar una sola vez.'
> Es como lo había especificado en la SRS, por eso registro a los dos
> empleados.
> Incluyo dos veces los datos de los empleados porque está el empleado que
> entrega el libro, y el empleado de mantenimiento que lo recibe.

	Ahhh... te faltan entonces agregar esto en el RF28: cambiar "empleados"
por "empleado[27] que entrega la unidad y "empleado[27] que recibe la
unidad".

> LT> "ADQUISICIONES. También le falta referencias al Libro... y también a
> Extravíos y Devoluciones, sino al borrar un Libro o una Unidad, no sabés que
> se adquirió ni qué se extravió."
> Introduzco en ADQUISICIONES el código interno que le pone la biblioteca a
> cada unidad y el código del libro (~ISBN), ya que estos dos datos
> identifican inequívocamente a cada unidad, y le voy a agregar el título
> porque es práctico.

	Ok.
	Me acabo de dar cuenta de que las "adquisiciones" son "reposiciones" de
una unidad extraviada por parte del asociado... estuve todo este tiempo
pensando que era cuando la biblioteca compraba material nuevo..

> En EXTRAVIOS y DEVOLUCIONES no lo incluí por lo mencionado tras las citas 1
> y 2. Si le parece que no es aceptable, lo incluimos y listo.

	Dejalo así para mantener la premisa de la situación ideal... así no te
queda desparejo.
	Perdón por las objeciones, pero hace más de 10 años que no puedo hacer
un software para situaciones ideales y me las tengo que ver con la sucia
realidad :-(

> LT>'No podés tener en PRESTAMOS idUnidad como clave foránea, porque la DB te
> va a impedir borrar Unidades que aparezcan en la tabla PRESTAMOS, que es
> justamente lo que se quiere permitir!!!'
> Retiré las claves foráneas para permitir el borrado de visitantes, asociados
> y unidades. Como el libro es un dato vivo entonces está bien mantener en
> ciertos lugares los idLibro como claves foráneas, ¿no?

	Solo si no te afecta a la estructura de los Préstamos, que es lo que
hay que conservar sí o sí independientemente de que se borren o
modifiquen otros datos.
	En este momento por ejemplo, si borrás a un asociado no sabés a quién
le hiciste el préstamo. Ponele al menos el nombre y apellido.

	Che, ahora que el Empleado es una funcionalidad, no vale la pena
registrar qué empleado entrega un libro? y quién lo recibe cuándo se
devuelve?

> Gracias por la evaluación, espero su respuesta.

	Por nada!
-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
Web: http://leonardo.tadei.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key