[Php-avanzado] normalizacion

[Leonardo Tadei - Pegasus Tech Supply]

Hola Germán y Paula

El mié, 07-03-2012 a las 20:54 -0300, German Valencia escribió:
> Hola leo, acá te mandamos la normalización a ver como la ves,
> obviamente estamos ávidos de sugerencias !!!! Salutte !!
> (ya se me vas a criticar los guiones bajos !!! jejej paulita ya lo hizo)

	Si ya lo hizo Paula, seguro que fue una crítica de buena calidad... yo
voy a criticar que la tabla Clientes tiene un campo id_cli... de qué va
a ser sino el ID en la tabla Clientes?
	Pero es una crítica para entrar en calor, y si la nomenclatura es
coherente, por mi no hay problema.

	Veamos la normalización (les intercalo texto cerca de la cosa en
cuestión):

> ==========
> CLIENTES
> ==========
> id_cli
> nom
> ape
> razsoc
> dir
> cuit
> tel
> cat_imp
> 
> ==========
> MESAS
> ==========
> id_mesa
> id_estado
> fecha
> 
> =========
> ESTADO_MESAS
> ==========
> id_estado
> desc
> 
> =========
> CAT_IMPO
> =========
> id_cat
> desc
> 
> ========
> MOZOS
> ========
> id_mozo
> nom
> ape
> tipo_doc
> nro_doc
> tel
> dir
> 
> ========
> TIPO_DOCU
> ========
> id_doc
> desc
> 
> ========
> RUBROS
> ========
> id_rubro
> desc
> tipo_rubro
> 
> =========
> TIPO_RUBROS
> =========
> id_tipo_rubro
> desc

	Esto viene de la forma en que hicieron la especificación, pero a nivel
de entidades, no hace falta una tabla TIPO_RUBROS, sino que lo que hacen
falta son una tabla RUBROS_Productos y otra RUBROS_MateriasPrimas.
	No hay ninguna funcionalidad ni entidad que haga necesaria la
superestructura TIPO_RUBROS. Lo que están haciendo al crearla es
reflejar la realidad del sistema, en el que los Productos tiene sus
Rubros, y las Materias Primas tienen sus propios Rubros, con lo que
evidentemente no son el mismo "rubro", es decir, no dependen de la misma
clave primaria.
	Por lo tanto las NF2 y NF3 dicen que van en tablas aparte, sin ninguna
relación entre ellas.
	

> =========
> PRODUCTOS
> =========
> id_prod
> nom
> id_rubro
> puntof
> precio
> 
> =========
> MAT_PRIMAS
> =========
> id_mp
> id_rubro
> nom
> puntop

	Estas dos tablas quedan así, salvo que ahora cada id_rubro está
relacionado con una tabla distinta.

> ========
> PROVEEDORES
> ========
> id_prov
> razsoc
> dir
> tel
> mail
> nom
> cont
> tel_cont
> 
> =========
> F_PAGOS
> =========
> id_fpago
> desc
> 
> =========
> ADICIONES
> =========
> id_adic
> id_mesa
> f_ocup
> f_liber
> id_mozo

	La tabla de adiciones queda inconsistente si se edita o borra una Mesa
o un Mozo... en los RF2 y RF12 queda clarísimo que ambas cosas pueden
modificarse y borrarse, por lo tanto deberán agregar en las Adiciones
los campos representativos de Mesa y Mozo para que se puedan editar o
borrar y no generar incosistencias.

> ========
> DET_ADICIONES
> ========
> id_adic
> id_det_adic
> cant
> id_prod
> nom_prod
> precio_prod

	Acá si están reflejando el RF7, y de editar o borrar un Producto, esto
sigue funcionando!
	Apliquen la misma idea a ADICIONES.

> =========
> TICKETS
> =========
> id_ticket
> fecha
> id_adic
> id_cli

	Falta la Forma de Pago...
	Acá tiene la misma inconsistencia respecto al RF4: esto se rompe al
editar o borrar un Cliente.
	Noten que al RF13 indicar que las Adiciones solo se registran, es
perfectamente válido tener acá solo el ID y recuperarla si hace falta.
	Supongo que están pensado en que el detalle del Ticket no es necesario,
justamente porque está en las adiciones. Lo están pensado bien desde la
normalización, pero tomen nota de esta decisión y de quién la tomó,
porque generan un acoplamiento innecesario entre dos entidades que son
perfectamente autónomas, con lo que se limitan por ejemplo el pagar con
2 tickets una adición por ser con diferentes formas de pago... a mi me
da lo mismo, porque está bien desde la normalización, pero se limitan
muchas posibilidades futuras.

> =========
> REMITO_C
> =========
> id_remc
> nro
> fecha
> id_prov
> nom_prov

	Si con solo el nombre del proveedor alcanza para reconocerlo en el
futuro, esto etá bien.

> =========
> DET_REM_C
> =========
> id_det_remc
> id_remc
> cant
> nom_mp
> id_mp
> 
> =========
> CTA_CTE
> =========
> id_cta
> id_cli
> id_fpago

	WTF ?
	Por un alado, esta tabla parece innecesaria.
	Por otro, no entiendo qué tiene que ver la Forma de Pago con la Cta
Cte... si me lo explican....

> =========
> PAGOS_CTA_CTE
> =========
> id_pago
> id_cta
> monto
> fecha

	Mmm... creo que entiendo, pero no.
	Lo que tienen que registrar son Movientos de Cuenta Corriente.
	Estos Movimientos serán de un cliente, y tendrán un importe del lado
del debe u otro del lado del haber.
	La tabla CTA_CTE me parece innecesaria, porque todo Cliente que tenga
al menos un Movimiento de Cta Cte ya tiene una Cta Cte...
	Ahora, si hay clientes que pueden tener Cta Cte y otros que no, se
comieron un campo en el Cliente (y especificar esta funcionalidad,
porque así como está, todos podrían tener una).

> =========
> REMITO_MP
> =========
> id_remmp
> fecha
> id_mp
> cant
> nom
> 
> =========
> REMITO_P
> =========
> id_remp
> fecha
> id_prod
> cant
> nom

	Esto últimos dos deberían tener la misma estructura Comprobante-Detalle
que hicieron para las Adiciones y para los Remitos de Compra. De paso,
póngale un nombre más largo para tener que adivinar menos...

	Por ahora, hasta acá.
	Hacemos más rápido si corrigen todo y reenvían, porque si corrigen solo
una parte vuelvo a tener que descubrir lo que acabo de escribir, y tardo
más en responder... además, me dejan con la duda de si les expliqué bien
o no, y explico más largo todavía ;-)

	Saludos y adelante!

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