[Php-avanzado] Tablas de Bibliotech

[Leonardo Tadei - Pegasus Tech Supply]

Hola Pehuén,

El jue, 26-12-2013 a las 16:58 -0300, Fernando Pehuén Borsani escribió:
> Hola profe!
> 
> Gracias por las correcciones profe, la verdad es que leyéndolas me di cuenta
> que no pensé en varias cosas al escribir la SRS.
> Puede ser que la SRS sea independiente de la implementación, pero la verdad
> es que al trabajar en la implementación se me ocurren detalles de la SRS.

	No estoy seguro de compartir tu afirmación por el contenido del resto
del mensaje. Si las cosas que no pensaste son sobre la definición del
problema sería cierto, pero si las cosas que no pensaste y se te ocurren
ahora son sobre como implementar el software, sería un pensamiento
incorrecto porque estarías amoldando el problema a la solución que se te
ocurre, en vez de crear una solución para el problema dado...

> LT> Mantenimientos: según la SRS no hay relación con el Empleado.
> 	Esta me parece una omisión importante en mi SRS, me parece que sería
> mejor modificarla para incluir este atributo. (El mantenimiento y la
> destrucción de unidades es uno de los momentos donde ocurren más robos).
> 	Si no me equivoco esto significa que ahora los empleados son parte
> de las referencia funcionales, así debería incluirlos en tal sección, ¿no?.

	Es correcto. Si para el problema es relevante saber quien manda a
mantenimiento y por qué causa una unidad, tendrías que agregar al
empleado como un atributo más y con esto se convertiría en una
funcionalidad.

> LT>Bueno y ahora lo más doloroso: para poder implementar los libros, las
> unidades, los visitantes y los asociados, tenés que poner datos de estas
> entidades en los Préstamos, Devoluciones y Mantenimientos, porque si no al
> borrar por ejemplo un Libro, te quedan los préstamos inconsistentes, o al
> borrar un Visitante te quedan los Comentarios inconsistentes... Todo esto
> asumiendo que los Libros son un dato "vivo" del sistema y que al borrarlo,
> borrarás todas sus Unidades, votos, popularidad, comentarios, 
> etc...

	Acá es dónde me parece que estás acomodando el problema a una solución
preconcebida en vez de diseñar una solución al problema planteado...


> 	Prefiero orientarme para otra solución, aunque signifique tener que
> completar la SRS.
> 	En el caso particular de los visitantes, si son baneados, que es una
> medida disciplinaria, entonces también borraría todos sus comentarios.

	Con esto, si un visitante hace 100 comentarios razonables y luego hace
10 malos porque se enteró que sos el autor del software y te odia,
borrarías sus 110 comentarios incluyendo los 100 buenos!
	Todo esto además de una pérdida de información valiosa es innecesario
en la SRS actual, porque los comentarios se gestionan, con lo que
podrías borrar solo los 10 malos.

	Te pongo un ejemplo extremo: un cliente compra 100 veces, un año le va
mal y usando su crédito deja 3 facturas impagas. La empresa decide no
venderle más... y tu software borraría las 100 ventas anteriores???

	Quiero decirte que hay muchas situaciones en que esto es inviable, lo
que significa que no es necesario desde el punto de vista técnico: solo
hay que normalizar bien para soportar las funcionalidades.

> 	Los asociados solo los permitiría dar de baja si no se efectuaron
> préstamos (o sea, si los quieren dar de baja tras haberlos dado de alta, lo
> cual puede ser útil en caso de error grave). Si ya comentaron o pidieron
> libros solo les cambiaría el nivel de permiso a inhabilitado (o sea, quedan
> baneados, el nivel de permiso cero).  Parecido para los empleados.


	Sí, pero esto haría necesario agregar "estados" o "niveles de permiso"
a los asociados (cosa que en la SRS no existe pero que agregaste en la
última normalización supongo que por descubrir que la estructura de los
datos tenían este problema) y complica todas las querys en que
participan. La implementación técnica de esta "solución" no solo no
respeta el problema real, sino que es más compleja que la normalización
correcta y su implementación.


> 	Igual con las editoriales y autores, solo permito la baja si ningún
> libro los tiene como dato. Si están presentes en algún libro, entonces solo
> los inhabilito para que no se los utilice en una nueva alta.
> 	Un libro solo lo puedo borrar si no tiene unidades. En otro caso, no
> se puede.

	Este manejo es razonable dado que en el problema no se requiere llevar
un histórico de las editoriales, autores y géneros usados.
	Como te decía, el libro es un "dato vivo" y su existencia condiciona la
existencia de sus componentes.

> 	Las unidades solo se pueden borrar si nunca tuvieron movimientos. Si
> tuvieron movimientos y quedan fuera de circulación, simplemente se marca su
> estado correspondiente (extraviado, destruido).

	Esto es completamente innecesario, y hacerlo implica resolver un
problema muy distinto al que especificaste (y perderte aprender como se
normaliza en estos casos, forzando a que dichos casos desaparezcan)

> Si me da el visto bueno, modifico la SRS con estos cambios y le envío una
> nueva versión de la SRS y las tablas normalizadas.

	Me hace falta una nueva versión de la SRS para que los empleados pasen
a ser una funcionalidad y se relacionen con 
	Todo lo demás, me parece, es cambiar el problema agregando un montón de
funcionalidades arbitrarias para llevarlo a la solución que ya tenés
pensada :-(


PD: fijate que en el RF18 parece faltarle la relación con los meses del
año.
PPD: no recuerdo una tabla con los meses! Es para implementar el RF17.

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