[Php-avanzado] SRS -2- Jose Lo Piccolo

[Leonardo Tadei - Pegasus Tech Supply]

El jue, 10-12-2009 a las 13:48 -0300, Jose Lo Piccolo escribió:
> Leo:
> 
> Te paso la SRS modificada y debajo la normalización para ver que te parece.

	La SRS está Ok.
	Buenísimo que ya tengas la normalización!


	Te respondo intercalado:

	Una observación general: estás manejando varios "tipos" con un char
dándole sentido semántico al valor, en vez de relacionarlo con una
tabla.
	A veces es buena idea, a veces es mala idea, y a veces podés no cumplír
un requerimiento.

> ------------------------------------------------------------------------
> 
> NORMALIZACIÓN DE TABLAS
> 
> _*EMPRESAS*_ (empresas)
> 
> id integer
> 
> razon_social char(50)
> 
> domicilio_postal char(50)
> 
> telefono char(30)
> 
> email_empresa char(60)
> 
> email_admin char(60)
> 
> contacto char(30)

	Sé más generoso con los tamaños de razón social, domicilio, contacto y
e-mail. Después no te alcanzan y es un lío.
	Esto hacelo extensivo a todas las tablas...


> _*
> USUARIOS*_ (usuarios)
> 
> id integer
> 
> usuario char(10)
> 
> clave char(10)
> 
> nombre char(30)
> 
> email char(60)
> 
> tipo char(1) (<1> Administrador <2> Usuario Normal)
> 
> estado char(1) (<1> Activo <2> Inactivo)
> 
> id_empresa integer
> 
> 
> _*SECCIONES*_ (secciones)
> 
> id integer
> 
> id_empresa integer
> 
> nombre char(30)
> 
> descri texto
> 
> 
> _*TIPOS*_ (tiposbien)
> 
> id integer
> 
> id_empresa integer
> 
> descri char(50)
> 
> 
> _*BIENES*_ (bienes)
> 
> id integer
> 
> id_tipobien integer
> 
> id_empresa integer
> 
> id_seccion integer Sección actual
> 
> nombre char(50)
> 
> descri texto
> 
> fecha_ingreso date
> 
> nuevo_usado char(1) (<N> Nuevo <U> Usado)

	Esto debería estar en otra tabla, no fijo como dato.
	Es solo descriptivo y tal vez quieras agregar en el futuro "reparado",
"amortizado", etc.

> proveedor char(50)
> 
> marca char(30)
> 
> modelo char(20)
> 
> estado char(1) (<A> Activo <P> Pendiente <I> Inactivo)
> 
> path_foto char(255)
> 
> costo decimal(12,2)
> 
> email char(1) (<S> Si Envia email <N> No envia email)

	Para esto es mejor un boolean... no se me ocurre que sirva ningún valor
distinto de "sí" y "no"... pero a nivel de la normalización no está mal.

> fecha_baja date
> 
> 
> _*EVENTOS*_ (eventos)
> 
> id_bien integer
> 
> fecha date
> 
> tipo_evento char(1) (<1> Envio a Reparacion <2> Reparado <3> Actualización)

	Esto va en una tabla de "Tipos de Eventos" y acá solo el id.

> 
> descri texto
> 
> detalle_envio char(60)
> 
> id_usuario integer
> 
> costo decimal(12,2)
> 
> 
> _*BAJAS*_ (bajas)
> 
> id_bien integer
> 
> fecha date
> 
> motivo char(60)
> 
> id_usuario integer

	Una tabla para esto???
	Por qué no fecha de baja y motivo como campos del bien de uso, que
estarán NULL mientras está activo?
	No veo que nada de esto no dependa de la clave primaria

> 
> _*CAMBIOS SECCIONES*_ (cambiosec)
> 
> id_bien integer
> 
> fecha date
> 
> id_seccion_nueva integer
> 
> descri char(50)
> 
> Nota: al dar de alta un bien de uso, se alimentará esta tabla con los 
> datos de la sección actual y así llevar el registro de todas las 
> secciones por las cual va pasando un bien de uso.

	Ok.

	No veo ninguna otra cosa... seguimos más tarde!

> ------------------------------------------------------------------------
> 
> Saludos

	=mente!

-- 

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