[Php-avanzado] Normalizacion

Mie Abr 11 19:07:14 ART 2012

Hola Sergio,

	Muy buen comienzo!
	Te hago unas poca observaciones intercaladas con tu texto:

El mié, 11-04-2012 a las 17:56 -0300, Sergio Marquez escribió:
> Hola Leo, te envío la normalización de mi BD en 3FN. Saludos.
> 
> ----------------------------------------------------------------------------------
> 
> ARTICULOS ( ID int(10) PK, NOMBRE varchar(100) , DESCRIPCION
> varchar(300) , IDCATEGORIA smallint(5) , PRECIO decimal(10,4) , STOCK
> smallint(5) )

	Una cuestión técnica: fijate que en ARTICULOS_CATEGORIAS la clave
primaria es int(10), pero en ARTICULOS el campo IDCATEGORIA que es el
que relacionará con ARTICULOS_CATEGORIAS es un  smallint(5).
	Hacé que ambos sean int(10), porque de otra forma podría haber
Categorías que no sean relacionables con el Artículo, por no tener
capacidad de almacenar la referencia.

	Una cuestión relacional: el campo STOCK no debe ir en esta tabla (ni en
ninguna otra) ya que ese valor se calcula en tu sistema sumando las
facturas de proveedores y de clientes.
	Una regla de la normalización es no almacenar cosas que puedan ser
calculadas. Eso sería una repetición encubierta.

> ARTICULOS_CATEGORIAS ( ID int(10) PK , CATEGORIA varchar(100) ,
> DESCRIPCION varchar(300) )
> 
> CLIENTES ( ID int(10) PK , RAZON varchar(100) , EMAIL varchar(100) ,
> IDCONDIVA int(10) , DEUDA       decimal(10,4) , OTROS varchar(300) )

	Dos cosas: una es que DEUDA es al igual que STOCK un valor calculado, y
por tanto no va acá.

	La otra es que esta implementación excede tu SRS!
	En ningún momento especificás que un Cliente tenga DireccioneS, sino
solo Dirección, y por tanto esta tabla estaría de más.
	Si querés hacer que los Clientes tengan varias Direcciones, contá
conmigo para hacer este sistema más grande, pero previamente actualizá
la SRS

	Acá es donde se aplica la idea de que la SRS es un "documento vivo" y
que se actualiza a medida que se deciden cambios sobre el sistema.

> CLI_DOMICILIOS ( ID int(10) PK , DIRECCION varchar (50) , IDLOCALIDAD
> int(10) , IDCLIENTE int(10) )
> 
> CLI_ESTABLECIMIENTOS ( ID int(10) PK , DIRECCION int(11) , IDCLIENTE
> int(10) , IDLOCALIDAD int(10) )
> 
> CLI_TELEFONOS ( ID int(10) PK, TIPO tinyint(3), NUMERO varchar(50) ,
> IDCLIENTE int(10) )

	Qué es TIPO en los teléfonos del cliente?
	Esto no se desprende de la SRS...

> CONDIVA ( ID int(10) PK , CONDICION varchar(50) )
> 
> FACTURAS_CLI ( ID int(10) PK , TIPOIVA  char(1) , FECHA datetime ,
> IDCLIENTE int(10) , NETO decimal(10,4) , IVA decimal(10,4) , IIBB
> decimal(10,4) , DESCRIPCION varchar(300) )

	Varias cosas: en la cabecera de las Facturas no podés poner solo el
IDCLIENTE, ya que si hiciste una factura el mes pasado al Cliente "34 -
Leonardo - Cons Final" y ahora me actualizás los datos a "34 - Leonardo
Tadei - Monotributista" y me hacés una factura, con este almacenamiento
estarías cambiando erróneamente algo anterior, que como ya pasó, no
debería ser cambiado nunca.
	En la cabecera de las Facturas tenés que guardar los datos mínimos que
reflejen la realidad del Cliente al momento de emitírsela, y que esos
datos no sean cambiados jamás.

	Otra cosa es el campo NETO, que no debe ir por que es la suma de los
importes en el detalle.

	Otra cosa es que no hay como marcar si la factura está paga o no, y
esto hace falta para tu sistema.

	La última, y es la que más me preocupa, es que aparecen el importe del
IVA y de los IIBB, pero no hay especificado ni veo en los
almacenamientos dónde se guardan las Tasas de IVA y de IIBB para poder
hacer este cálculo.
	Qué son esos valores? Cómo se calculan?

> FACTURAS_PRO ( ID int(10) PK , TIPOIVA char(1) , FECHA datetime ,
> IDPROOVEDOR int(10) , NETO decimal(10,4) , IVA decimal(10,4) , IIBB
> decimal(10,4) , DESCRIPCION varchar(300) )

	Lo mismo respecto a los datos del Proveedor.
	Sin embargo el IVA y los IIBB es correcto que estén acá y no se
calculen, pero deben usarse los que figuren en la factura del Proveedor
por más que estén mal calculados o no coincidan con nuestros cálculos.

	Tampoco hay como marcar si está pagada o no.

> FACTURA_CLI_ITEMS ( ID int(10) OJ , IDFACTURA int(10) , IDARTICULO int(10) )

	A los Items les falta la cantidad, el valor al que fueron vendidos
(porque si no al cambiar un precio en los Artículos cambiás las ventas
pasadas!).
	También tenés que agregar datos del artículo para reconocerlo al
momento de ser vendido, pero en el RF5 indicás que se pueden modificar,
y el sistema no debe permitir cambiar lo que ya pasó.

> FACTURA_PRO_ITEMS ( ID int(10) PK , IDFACTURA int(10) , IDARTICULO int(10) )

	También les falta la cantidad y el precio.
	Luego está la misma consideración sobre el cambio de nombres de
Artículos...

> LOCALIDADES ( ID int(10) PK , NOMBRE varchar(50) , CP int(4) ,
> IDPROVINCIA int(10) )
> 
> PROVEEDORES ( ID int(10) PK , RAZON varchar(100) , EMAIL varchar(100)
> , WEB varchar(100) , IDCONDIVA int(10) , DEUDA decimal(10,4) , OTROS
> varchar(300) )

	El campo DEUDA no va porque es un dato calculado...

> PROVINCIAS ( ID int(10) PK , NOMBRE varchar(50) )
> 
> PRO_DOMICILIOS ( ID int(10) PK , DIRECCION  varchar(50) , IDLOCALIDAD
> int(10) , IDPROVEEDOR   int(10) )

	Lo mismo que para los Clientes, el tener múltiples domicilios excede tu
SRS. Ampliala para reflejar estas funcionalidades!

> PRO_TELEFONOS ( ID int(10) PK , TIPO tinyint(3) , NUMERO varchar(50) ,
> IDPROVEEDOR int(10) )

	La misma duda sobre el TIPO que aparece acá del teléfono.

> USUARIOS ( ID int(10) PK , USUARIO varchar(50) , PASSWORD varchar(100)
> , NOMBRE  varchar(100) , APELLIDO  varchar(100) , EMAIL varchar(100) ,
> ACCESO datetime )

	Bueno, por ahora nada más.
	Seguimos!

	Por favor, consultá si tenés alguna duda puntual sobre las correcciones
que te hago.

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