[Php-avanzado] Normalización
David Barraud
davidbarraud en gmail.com
Dom Jul 15 10:10:46 ART 2012
Hola Leo, te escribo para preguntarte lo siguiente:
Tengo las tablas:
*#solicitudes*
id_solicitud
id_depto
depto_nombre
id_estado
fecha_inicio
fecha_fin
problema
solucion
*#solicitudesDetalles*
Id_solicitud_detalle
Id_solicitud
Id_producto
nombre
cantidad
Lo que quiero saber es si los campos
id_depto
depto_nombre
problema
solucion
de la tabla #solicitudes deberían estar en #solicitudesDetalles.
Muchas gracias.
El 11 de julio de 2012 21:28, Leonardo Tadei - Pegasus Tech Supply <
leonardot en pegasusnet.com.ar> escribió:
> Hola David,
>
> listo!
>
> con esto que me decís, la Normalización queda terminada y de
> acuerdo
> con tu SRS. La guardo como futura referencia.
>
> Respecto a quién pide las Solicitudes, si interesa registrar algo,
> no
> tiene ningún impacto agregar en la tabla Solicitudes un campo
> "pedido_por" y poner ahí el nombre del usuario logueado, o en nombre y
> apellido de la tabla Login.
>
> Nunca se sabe cuando va a hacer falta esta información.
>
> Igual, si para vos no es relevante, tomá esto como una sugerencia y
> nada más.
>
> Ahora, ponete corriendo a terminar el código para entregar!!!
>
>
>
> El mié, 11-07-2012 a las 17:04 -0300, David Barraud escribió:
> > Hola Leo, con respecto al campo que marcaste que no va, efectivamente
> > no va, me quedó en la corrección y no lo borré al copiarlo.
> >
> > No queda constancia de quién hace la Solicitud de Reparación? Me
> > parece
> > recordar que estaba en versiones anteriores de tu SRS... pero tal vez
> > me
> > esté confundiendo de trabajo final.
> >
> > En un principio había pensado colocar quién solicitaba la reparación
> > pero ví que era más importante para mí el "departamento" que la
> > solicita y no la persona, por eso en el departamento no coloco
> > responsable porque en realidad no me interesa por el momento definir
> > esto.
> > Ya queda en la solicitud el departamento que pide el trabajo.
> >
> > RNF
> > #login
> > id_login
> > usuario
> > pass
> > nombre
> > apellido
> > admin
> >
> > con respecto al campo admin lo uso para colocar el número 0 o 1. Voy a
> > tener 2 niveles de usuario: el administrador del sistema que es el que
> > va a cargar las solicitudes y hacer el trabajo y el operador que se va
> > a encargar de chequear qué trabajo se está haciendo, en realidad es el
> > gerente que va a poder ver qué trabajo se hizo y qué se está haciendo
> > en el momento o queda por hacer. Una pantalla de consulta.
> > Entonces si el campo admin es 0 va a la página del operador y si es 1
> > a la página del administrador.
> >
> >
> >
> >
> > El 10 de julio de 2012 17:31, Leonardo Tadei - Pegasus Tech Supply
> > <leonardot en pegasusnet.com.ar> escribió:
> > Hola David,
> >
> > te respondo intercalado:
> >
> > El dom, 08-07-2012 a las 15:19 -0300, David Barraud escribió:
> > > Hola Leo, te paso las correcciones hechas con los detalles
> > que me
> > > pediste.
> > >
> > >
> > > Normalización
> > >
> > > #departamentos
> > >
> > > id_depto
> > >
> > > depto_nombre
> > >
> > >
> > >
> > > #categorias
> > >
> > > id_categoria
> > >
> > > nombre
> > >
> > >
> > >
> > > #insumos
> > >
> > > id_producto
> > >
> > > id_categoria
> > >
> > > imagen
> > >
> > > nombre
> > >
> > >
> > >
> > > #RemitosAltaStock
> > >
> > > id_remito_alta
> > >
> > > fecha
> > >
> > >
> > >
> > > #RemitosAltaStockDetalle
> > >
> > > id_alta_detalle
> > >
> > > id_remito_alta
> > >
> > > id_producto
> > >
> > > nombre
> > >
> > > cantidad
> > >
> > >
> > >
> > > #RemitosBajaStock
> > >
> > > id_remito_baja
> > >
> > > fecha
> > >
> > >
> > >
> > > #RemitosBajaStockDetalle
> > >
> > > id_baja_detalle
> > >
> > > id_remito_baja
> > >
> > > id_producto
> > >
> > > nombre
> > >
> > > cantidad
> > >
> > > motivo
> >
> >
> >
> > Hasta acá está bien.
> >
> > > #solicitudes
> > >
> > > id_solicitud
> > >
> > > id_depto
> > >
> > > depto_nombre
> > >
> > > id_estado
> > >
> > > id_remito_baja
> >
> >
> > El campo id_remito_baja es incorrecto. La Solicitud de
> > reparación no
> > tiene que hacer referencias al Remito de Baja.
> > La propia Solicitud de Reparación _es_ la baja de los
> > insumos usados.
> >
> > > fecha_inicio
> > >
> > > fecha_fin
> > >
> > > problema
> > >
> > > solucion
> > >
> > >
> > >
> > > #solicitudesDetalles
> > >
> > > Id_solicitud_detalle
> > >
> > > Id_solicitud
> > >
> > > Id_producto
> > >
> > > nombre
> > >
> > > cantidad
> > >
> > >
> > >
> > > #estados
> > >
> > > id_estado
> > >
> > > estado
> >
> >
> > El resto está bien.
> > Te falta(n) la(s) tabla(s) para implementar los RNF
> >
> > No queda constancia de quién hace la Solicitud de
> > Reparación? Me parece
> > recordar que estaba en versiones anteriores de tu SRS... pero
> > tal vez me
> > esté confundiendo de trabajo final.
> >
> > Resumiendo: sin ese campo y agregando como se guardan
> > los usuarios esto
> > está listo.
> >
> > Saludos!
> >
> >
> > PD: hoy recibí otro mensaje igual a este, así que también lo
> > damos por
> > contestado.
> >
> >
> > > El 6 de julio de 2012 00:32, Leonardo Tadei - Pegasus Tech
> > Supply
> > > <leonardot en pegasusnet.com.ar> escribió:
> > > Hola David,
> > >
> > >
> > > El jue, 05-07-2012 a las 15:44 -0300, David Barraud
> > escribió:
> > > > Bien, entonces me faltaría una tabla en
> > #solicitudes que me
> > > guarde los
> > > > insumos que se usan para cada solicitud
> > >
> > >
> > > Me parece que decís bien, pero por las dudas
> > lo vuelvo
> > > a expresar acá:
> > > las Solicitudes normalizadas quedan en dos tablas,
> > una con la
> > > "cabecera"
> > > de la solicitud, y otra con el "detalle" en dónde
> > constan los
> > > insumos.
> > >
> > > Si te fijás, los comprobantes de altas y de
> > bajas son
> > > casi iguales,
> > > salvo que la "cabecera" es más chica (y los de baja
> > tienen el
> > > motivo
> > > como parte de los detalles).
> > >
> > > > y el cálculo del stock de los insumos sería la
> > sumatoria de
> > > las Alta
> > > > de Stock - baja de stock - baja de stock en las
> > solicitudes.
> > >
> > >
> > > Correcto!
> > >
> > > > Si estoy en lo correcto decime si estas tablas
> > quedarían de
> > > esta
> > > > manera:
> > >
> > >
> > > Mmm... más o menos así. La idea está bien,
> > pero te
> > > falta pulir un par
> > > de detalles:
> > >
> > > 1) Los nombre de las tablas en plural, y lo de los
> > campos en
> > > singular.
> > > Parece una pavada pero es de veras importante para
> > no
> > > confundirte.
> > > 2) Si tenés id_depto, como tu RF1 dice que se
> > gestionan,
> > > tenés que
> > > guardar acá el nombre del departamento, porque si
> > después se
> > > cambia o se
> > > borra, no tenés que cambiar las Solicitudes ya
> > generadas.
> > > Nota: No pasa lo mismo con id_estado, porque no se
> > gestiona.
> > > 3) La tabla de detalles se ve bien. A nivel de
> > nomenclatura,
> > > es un poco
> > > confuso porque el "remito" es la solicitud entera,
> > así que uno
> > > esperaría
> > > que la palabra "remito", si está, esté en la primer
> > tabla. Si
> > > una tabla
> > > se llama "Solicitudes", la otra podría llamarse algo
> > como
> > > "SolicitudesDetalles" o "SolicitudesItems", es decir
> > un nombre
> > > que
> > > denote que depende de la primera y que no tiene
> > sentido sin
> > > ella.
> > > Yo empiezo todo con "Solicitudes...", pero esto es
> > de viejo
> > > mañoso,
> > > porque después el ver las tablas alfabéticamente se
> > ven juntas
> > > las
> > > relacionadas, y no con otras tablas en el medio,
> > pero sería un
> > > nombre
> > > más correcto "ItemsSolicitud" o
> > "DetallesSolicitud"... más
> > > correcto pero
> > > incómodo.
> > > Mientras sea claro y explícito, llamalas como
> > quieras. Que una
> > > diga
> > > "Remito" y la otra no, desentona, pero no es que en
> > nombres de
> > > tablas o
> > > de campos haya cosas "mal" si son representativas.
> > >
> > > Saludos!
> > >
> >
> >
> >
> > --
> > Leonardo Tadei
> > leonardot en pegasusnet.com.ar
> > Blog: http://blog.pegasusnet.com.ar
> > Firma pública:
> > http://www.pegasusnet.com.ar/LeonardoTadei-public.key
> >
> > _______________________________________________
> > Php-avanzado mailing list
> > Php-avanzado en pato2.fi.mdp.edu.ar
> > http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> >
> >
> > _______________________________________________
> > Php-avanzado mailing list
> > Php-avanzado en pato2.fi.mdp.edu.ar
> > http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>
> --
>
> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> Pegasus Tech Supply
> Tel: (+54)(+223) 471-2880
> La Salle 1131 - Mar del Plata - Argentina
> http://www.pegasusnet.com.ar
> http://www.grupopegasus.com
> Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
>
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20120715/ff74d52b/attachment-0001.html>
Más información sobre la lista de distribución Php-avanzado