[Php-avanzado] SRS versión final???

[Leonardo Tadei - Pegasus Tech Supply]

Hola Maximiliano,

	te respondo intercalado:

El lun, 03-02-2014 a las 18:51 -0200, Maximiliano Lizondo escribió:
> Leo, estoy normalizando y hasta ahora tengo esta primera versión:
> 
> 
> DICCIONARIO:
> ------------
> 
> 
> Países: nombre de país
> Provincias: nombre de provincia, país
> Localidades: nombre de localidad, país, provincia, código postal
> Proveedores: razón Social, país, provincia, localidad, dirección,
> email, página web, teléfono
> (Se considera proveedores a sellos discográficos y comerciantes, que
> son gestionados por el sistema UNICAMENTE a través de un usuario
> administrador)
> Tipo de documento: país, DNI/CI/LE/LC
> Tipo de envío: país, provincia, localidad, correo argentino/correo
> privado/encomienda por ómnibus, precio de envío
> Clientes: nombre de cliente, tipo de cliente, tipo de documento,
> número de documento, país, provincia, localidad, dirección, email.
> (Se considera cliente a cualquier individuo que accede al sistema para
> registrarse en el mismo)
> Tipo de cliente: particular/revendedor
> Tipos de moneda: nombre de moneda, país
> Productos: nombre de producto, código de identificación, proveedor,
> formato de producto
> Lista de precios de productos: productos, tipos de moneda, precio de
> producto, clientes
> Formatos de productos: nombre de formato, CD/TAPE/VINYL
> Estado de pedido: 
>   *en proceso (pedido siendo procesado por el sistema)
>   *cancelado (pedido “en proceso” que es luego cancelado por el
> sistema)
>   *verificado (pedido “en proceso” que es luego verificado por el
> sistema)
>   *entregado (pedido “verificado” que es luego entregado en el
> domicilio del cliente)
> Pedidos:  cliente, productos, tipo de envío, precio total del pedido,
> estado de pedido, fecha de estado
> 
> 
> 
> 
> TABLAS:
> -------
> 
> 
> Localidades:
> id_localidad
> nombre_localidad
> codigo postal
> id_provincia
> 
> 
> Paises:
> id_pais
> nombre_pais
> 
> 
> Provincias:
> id_provincia
> nombre_provincia
> id_pais
> 
> 
> Clientes:
> 
> id_cliente
> nombre_cliente
> tipo_cliente
> tipo_documento
> numero_documento
> direccion
> email
> id_localidad
> id_lista_precios

	Te faltan las tablas para los Tipos de Documento y para los Tipos de
Cliente.

> Proveedores:
> 
> id_proveedor
> razón Social
> dirección
> email
> página web
> teléfono
> id_localidad
> 
> 
> Productos:
> 
> id_producto
> nombre_producto
> formato de producto
> código de identificación (comercial)
> id_proveedor

	falta la tabla de Formatos de Producto

> Listas_de_precios: (no está completa porque tengo dudas con esto,
> explico abajo)
> id_lista_precios
> ***productos, tipos de moneda, precio de producto, clientes
> 
> 
> Pedidos:
> id_pedido
> productos
> tipo de envío
> precio total del pedido
> id_cliente

	Varias cosas. Por una parte, en Pedidos tenés que volver a poner los
datos relevantes del Cliente, porque si ponés solo una referencia, al
hacer ABM de un Cliente cambiás los Pedidos ya registrados, lo cual no
debe pasar.
	Por otra parte, tenés acá una relación 1-N con una tabla que podría
llamarse PedidosItems que será la que tenga los datos de los Productos
(equivalentes a los renglones de un pedido en papel, con las cantidades
de cada Producto y los datos del mismo).
	No me acuerdo si está en la SRS, pero suena razonable que el Pedido
tenga una fecha.
	También debe tener un Estado de Pedido!

> 
> Estados_de_pedidos:
> id_estado
> nombre_estado
> fecha_estado
> id_pedido

	No. Te hace falta tener una tabla con los Estados de Pedidos, pero el
Estado de un Pedido en sí, será una referencia en Pedidos a esta tabla,
ya que un Pedido no puede estar en más de un Estado a la vez.

> 
> Bueno, la duda que tengo es respecto a las listas de precios. En mi
> caso, las mismas se asignan por cliente. Podrían existir varias listas
> y cada cliente podría tener asignadas varias de ellas (es una
> funcionalidad que me recomendaste hacerla no tan restrictiva, como
> sería asignar listas en base al "tipo de cliente").

	Bueno, mi recomendación era que el sistema soporte varias listas, y
poder asignarle a un Cliente cualquiera de las existentes, y no varias a
la vez (que no se me ocurre para qué serviría en este caso).

> El tema es cómo encajan las listas de precios en la estructura de las
> tablas normalizadas. Yo había pensado que, como existe la posibilidad
> que haya varias listas, armar una tabla "Listas_de_precios" con los
> campos "id_lista", "descripcion" e "id_cliente". En ese caso, el
> contenido del campo "descripción" sería la lista de precios en un
> archivo .pdf o algo similar.
> Por favor, decime si estoy muy errado o qué alternativa podría usar.

	Estás más o menos. Por una parte, hace falta tener una tabla
Listas_de_Precios, que tendrá un id y un nombre.
	Luego hace falta ponerle los precios a los Productos. Esto se hará con
una tabla con id, id_lista, id_producto, precio.
	Posiblemente no sea exactamente así por el papel que juega la Moneda
(de la que tampoco hay tabla).
	Luego, si un Cliente puede tener solo una Lista de Precios a la vez,
que es lo que especificaste, simplemente en la tabla Clientes tendrás
una referencia a qué Lista de Precios es la de él... si en cambio un
Cliente tiene muchas Listas de Precios, entonces te quedará una relación
N-M, que necesitará una tabla aparte.

>  Gracias!

	Por nada!


PD: qué asunto poco descriptivo!


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