[Php-avanzado] Normalizacion Juan Manuel V1

Vie Dic 7 18:34:46 ART 2012

Hola Juan Manuel,

El vie, 07-12-2012 a las 10:47 -0300, Juan Manuel P. escribió:
> Perdon me olvide de adjuntar la nueva normalizacion al final.

	No te preocupes, nos pasa a todos.

	Te hago un par de comentarios para ganar tiempo, pero tenemos que
terminar de ver las cuestiones que te comento en el otro hilo de
conversación, porque implicarán algún ajuste menor en la SRS.

	Mientras, te comento sobre las cosas que parece que ya están
completamente especificadas:

[..]
> > > Mascotas
> > > [
> > > mas_id:integer(autoincremental);
> > > mas_name:Varchar(50);
> > > mas_sexo: Byte (0-Macho | 1-Hembra);
> > > mas_raz_id:integer;
> > > mas_edad:integer;
> > > mas_obs:text;
> > > mas_tam_id:integer; (FK)
> > > mas_loc_id:integer; (FK)
> > > mas_est_id:integer; (FK)
> > > mas_fecalta:timestamp;
> > > ]
> > 
> > Varias cosas:
> > - primero y principal, tenés acá el mismo problema de concepto que
> con
> > los Contactos.
> > - hacé una tabla con los dos sexos y poné acá una referencia. No
> > hacerlo, además de dejarte la normalización incompleta, te llena el
> > código de IF preguntando si es 0 o 1 para ponerle el nombre, que
> > normalizando bien, aparece directamente en la proyección.
> 
> Listo agregada la tabla de Sexos, siempre habia utilizado esta clase
> de normalizacion, dado que tener una tabla para dos registros que se
> sabe que no van a cambiar ni agregarse a futuro.

	Si el dato no está en una tabla, no tiene sentido siquiera hablar de
normalización.

	Si vamos al caso, hay sistemas de gestión comercial (bien normalizados)
que tiene una tabla para las letras de los comprobantes válidos: A, B,
C, E, NC, ND, R y X.
	No hay más ni es muy posible que cambien, pero la normalización refleja
la existencia de la entidad "Tipos de Comprobante" y al final del
proceso te aparece esta tabla con estos datos.

	Lo de que no cambien en el futuro no estés tan seguro: por ejemplo si
tenés que hacer una versión en inglés de este sistema, haber normalizado
implica editar dos registros, versus lo que estabas proponiendo que es
hacer cambios en el código en todas partes en dónde aparezcan los datos.

>  Incluso en lugares donde he trabajado se han manejado asi, y hasta
> con 4 valores no solo 0 y 1. Pero no hay problema, ya agregue la tabla
> Sexos.

	Eso es una falacia ad hominem!
	Son muchos más los seres humanos que no saben normalizar que los que sí
saben, y esto no significa que normalizar esté mal.
	Sin embargo, si creés que estoy interpretando mal la teoría de
Boyd-Codd, me gustaría conocer tu opinión al respecto, porque todos
podemos equivocarnos.

> > - no podés hacer solo una referencia a la Raza, porque en tu SRS se
> > pueden borrar y modificar, y de hacerlo cambiás las Mascotas
> publicadas
> > anteriormente.
> > - Idem para Tamaño, y para Especie.
>  
> 
> Pregunto, si como restriccion quiero poner que para modificar, o
> eliminar algun Tamaño, Especie, Raza, Localidad, Provincia o demas
> dato que estoy gestionando sea condicion que no exista ninguna mascota
> o Contacto que este asociada a dicho dato (Ej que ninguna mascota sea
> de Especie: Gato), en donde lo deberia redactar en la SRS? aca en la
> normalizacion?

	Este tipo de restricciones suelen proponerse por querer convertir en un
modelo estático, algo que es intrínsecamente dinámico... los sistemas
con este tipo de restricciones suelen ser muy incómodos de usar.
	El ejemplo típico de estas restricciones son los modelos de datos de
los sistemas de facturación, en los que el programador, por no saber
normalizar bien, decide que un artículo una vez vendido no puede ser ni
editado ni borrado.
	El sistema termina al poco tiempo lleno de datos "basura" por artículos
que no se fabrican o consiguen más, o simplemente por datos mal cargados
a los que legó a hacerse una venta.
	El ejemplo que te doy es muy común y bastante simple de ver en qué
consiste la incomodidad para el que lo usa... y si no entiendo mal,
estás haciendo una propuesta parecida pero aplicada a otro problema, con
lo que no es tan fácil de ver.

> Si va en la SRS, seria un Req No Funcional? y como deberia de
> redactarlo para que quedara correctamente expresado?

	De hacer algo así, tendrías que desglosar la "gestión" de cada cosa
afectada por esta restricción en subrequerimientos, y en el de
modificación y en el de borrado, especificar cómo es el mecanismo y las
condiciones para hacerlo.

> > > Mas_Pics
> > > [
> > > mpic_id:integer(autoincremental);
> > > mpic_mas_id:integer; (FK)
> > > mpic_name:Varchar(50);
> > > ]
> > 
> > Es poco 50 para el nombre de una imagen. Poné por lo menos 128.
> 
> Preferiria dejarlo en 50, mas que nada porque el nombre no lo asigna
> el usuario sino el sistema, en base al ID de la mascota y al numero de
> fotos que se cargaron de la mascota (en la SRS en el diccionario se
> especifican que pueden ser hasta 3)
> EJ: IMG1_1.png, IMG1_2.png, etc, etc...

	Bueno, dejalo así, pero si renombrás completamente las imágenes, te
perdés posicionamiento en los buscadores porque los archivos no tienen
nombres descriptivos.

> Como eso es algo interno del sistema, que no agrega funcionalidad no
> lo especifique en la srs porque considere que no agregaba ni restaba
> saber como se iban a manejar los registros.

	Poner como se manejan registros en la SRS sería del todo incorrecto,
porque un registro habla de la solución, y la SRS debe especificar solo
el problema.
	Pero es completamente válido (cuando hace falta, y este no parece uno
de esos casos) especificar qué se tiene que hacer con las imágenes
recibidas en términos de funcionamiento.

> > > Mas_Situaciones
> > > [
> > > msit_id:integer(autoincremental);
> > > msit_name:Varchar(25);
> > > ]
> > 
> > Qué es esta tabla ???
> 
> Esta tabla es la que tiene las situaciones de las mascotas
> [Encontrada, Perdida, Reunida]. Dado que las mascotas poseen
> exactamente los mismos datos, es por esto que preferi normalizar a
> tener 3 tablas diferentes con los mismos campos e informacion si con
> agregar una tabla y un FK a la de mascotas se logra exactamente lo
> mismo.
> Aclaracion: me habia olvidado en la normalizacion agregar el campo en
> la mascota, referente a su situacion.

	Dos cosas: 
1) con la aclaración y el agregado de la referencia la tabla tiene
sentido.
2) esta implementación contradice tus RF 15.4 y RF16.4 así que no podés
seguir este camino, porque la normalización va para otro lado :-(

	Como nota al margen, me causó simpatía tu expresión "preferi normalizar
a tener 3 tablas diferentes"... porque la normalización no es una
cuestión de preferencias, sino de aplicar la norma.

> > > Sugerencias
> > > [
> > > sug_id:integer(autoincremental);
> > > sug_name:varchar(50);
> > > sug_email:varchar(100);
> > > sug_texto:varchar(500);
> > > ]
> > 
> > Según tu SRS las sugerencias no se guardan, solo se envían. O esta
> > tabla sobra o el RF está incompleto.
> > 
> Corregi el RF agregando que se guarden a demas de que se envien las
> sugerencias.

	Ok. Ya lo vi en la SRS.

> > > TAdmins
> > > [
> > > tad_id:integer(autoincremental);
> > > tad_name:Varchar(100);
> > > ]
> > > 
> > > Admins
> > > [
> > > adm_id:integer(autoincremental);
> > > adm_nombre:Varchar(50);
> > > adm_apellido:Varchar(50);
> > > adm_user:Varchar(20);
> > > adm_pass:Varchar(20);
> > > adm_email:Varchar(100);
> > > adm_tad_id:integer; (FK)
> > > ]
> > > 
> > > Tablas_Autorizadas
> > > [
> > > tab_id:integer(autoincremental);
> > > tab_name:Varchar(30);
> > > ]
> > 
> > Qué es esto???
> > 
> > Si es lo que supongo, lo que se autoriza es el acceso a
> > funcionalidades, que expresado para las tablas (lo que no siempre es
> > posible) te da por cada tabla permiso para ver, agregar, modificar y
> > borrar.
> 
> Sucede que el webhosting donde esta alojado el sitio no me permite
> asociar permisos especificos para cada tabla sino para la bd en
> general( lo acabo de descubrir hoy cuando hacia la normalizacion).
> Entonces  para poder implementar los permisos que va a tener cada
> tabla para cada tipo de administrador, necesito hacer que las tablas
> que se gestionan sean registradas en esta otra tabla para poder
> despues asignar los permisos correspondientes y las acciones que se
> pueden realizar.

	Juan Manuel, estás mezclando las cosas.
	Si vas a definir los accesos por la definición de cada usuario en la
DB, para lo cual tenés que ser SysDBA, este RNF se implementará en la
propia DB y no aparece nada en la normalización. Es muy raro que seas
SysDBA de un hosting, tal y como charlamos en clase.
	Si en cambio vas a gestionar los permisos por software, tiene entonces
sentido hacer referencia solo a las funcionalidades, y no a las tablas,
porque lo que vas a implementar son funcionalidades.
	Pero igual todo esto es una complicación innecesaria, porque dijiste
que solo hay 2 tipos de administradores, así que sabiendo de qué tipo es
un administrador, el software ya puede determinar si puede o no hacer
una tarea dada.

> > > Autorizaciones
> > > [
> > > aut_id:integer(autoincremental);
> > > aut_name:Varchar(15);
> > > ]
> > > 
> > > Permisos
> > > [
> > > per_tad_id:integer; (FK)
> > > per_tab_id:integer; (FK)
> > > per_aut_id:integer; (FK)
> > > ]
> > 
> > Y si esto es el acceso ver, agregar, modificar y borrar de cada
> tabla,
> > no se justifica, porque no existen más que estas 4 cosas para hacer
> > sobre los datos.
> > 
> Exactamente, solamente existen esos 4 pero aca se va a registrar lo
> que esta permitido hacer para cada tipo de administrador.
> EJ: Permisos[ per_tad_id:1, per_tab_id:1, per_aut_id:1]. 
> Permisos[ per_tad_id:1, per_tab_id:1, per_aut_id:2]. 
> Permisos[ per_tad_id:1, per_tab_id:1, per_aut_id:4]. 
> Donde per_tad_id:1 es el tipo de administrador, per_tab_id es la tabla
> a la que ese tipo de administrador va a poder realizar acciones,
> per_aut_id es la accion que puede realizar el tipo de administrador.
> En el ejemplo, suponete, el aut_id:1 es lectura, el aut_id:2 es
> agregar y el aut_id:4 es borrar, o sea este tipo de administrador no
> puede modificar un registro existente en la tabla 1.

	Por lo que te digo arriba, nada de esto parece hacer falta.
	Pero de hacer falta, no podés determinar los permisos escribiendo 1, 2,
4, porque en ese caso no estás en Primera Forma Normal.

	Seguimos con esto luego de resuelto el tema de la otra conversación,
por si implica cambios en la SRS.

	Saludos cordiales!

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