[Php-avanzado] Normalizacion Juan Manuel V2
Juan Manuel P.
tucu_21 en hotmail.com
Vie Dic 7 21:42:00 ART 2012
Leo te contesto abajo y copio la V2 de la normalizacion abajo de todo.
> From: leonardot en pegasusnet.com.ar
> To: php-avanzado en pato2.fi.mdp.edu.ar
> Date: Fri, 7 Dec 2012 18:34:46 -0300
> Subject: Re: [Php-avanzado] Normalizacion Juan Manuel V1
>
> 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.
>
Tenes Razon, no lo habia pensado de esa forma.
> > 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 para nada sino que luego de trabajar durante un año ahi me acostumbre a que cuando tenia datos de esta forma los manejaba con codigos numericos y era el codigo el que sabia como interpretarlos.
Pero son vicios que quedan de experiencias laborales, las cuales no siempre estan bien hechas.
> > > - 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.
Ok, igual si bien es un poco enroscado es verdad, habia pensado en como dije si no habia ninguna relacion con ninguna otra tabla del sistema si se podia borrar el dato, pero sino no se permitia. Lo que esto generaba es que se debia crear un nuevo registro con el dato ingresado de forma correcta y posteriormente cambiar las referencias (el id viejo por el id nuevo) en todo el sistema y ahi si se podria eliminar el dato, pero como dijiste es bastante complicado y enroscado.
> > 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.
>
Me parece que hacer eso seria muy complicado y dar un paso atras en la SRS, por lo que prefiero hacer como nos explicaste en su momento en clase.
En lugar del ID se guarda el valor de ese campo, es por ello que puse los campos con la misma longitud que el campo de la tabla original y a demas agregue provincias.
Debo reconocer que esto me complica totalmente, porque cuando tenga que hacer los filtros o busquedas si un administrador borro "Mar del Plata" y ahora pasa a llamarla "MDP" las Mascotas Perdidas o Encontradas o Reunidas posteriores al cambio no voy a tener una referencia valida.
Como podria hacer segun vos para corregir esto? o para que no suceda este problema?
> > > > 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.
>
Hice el cambio, ahora estan las tablas Mascotas_Perdidas, Mascotas_Encontradas, Mascotas_Reunidas.
Tuve que dejar Mas_Situaciones porque ahora se me genera un problema con las tablas Mas_Pics, Mas_Reuniones, Mas_Observaciones (excepto que estas tablas tambien deban pasar a ser Mas_Reuniones_Perdidas, Mas_Reuniones_Encontradas, etc, etc).
Es por eso que agregue un campo en estas tablas mencionadas, que las relaciona con Mas_Situaciones en la cual se hace referencia a que tabla corresponde la mascota, pero como explique decime si esto es correcto o si deberia desglosar Mas_Reuniones, Mas_Observaciones y Mas_Pics
> > > > 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.
Ok, lo manejo por codigo todo entonces.
> > > > 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.
>
Listo entonces todo esto fue eliminado de la Normalizacion.
> 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
>
Provincias
[
pro_id: integer(autoincremental);
pro_name: Varchar(100);
]
Localidades
[
loc_id: integer(autoincremental);
loc_name: Varchar(150);
loc_pro_id: integer; (FK)
]
Especies
[
esp_id: integer(autoincremental);
esp_name: Varchar(100);
]
Razas
[
raz_id: integer(autoincremental);
raz_name: Varchar(150);
raz_esp_id:integer;(FK)
]
Tamanos
[
tam_id: integer(autoincremental);
tam_name: Varchar(25);
]
EstadosPublicacion
[
est_id: integer(autoincremental);
est_name: Varchar(25); [Activo | Pendiente de Confirmación | Pendiente de Publicación | Rechazad]
]
Contactos_Mascotas
[
con_id: integer(autoincremental);
con_name: Varchar(50);
con_email: Varchar(100);
]
Contactos_Externos
[
cext_id: integer(autoincremental);
cext_name: Varchar(50);
cext_email: Varchar(100);
]
Sexos
[
sex_id:integer(autoincremental);
sex_name:Varchar(20);
]
Mascotas_Perdidas
[
mas_id: integer(autoincremental);
mas_name: Varchar(50);
mas_sex:Varchar(20);
mas_raza: Varchar(150);
mas_edad: integer;
mas_obs: text;
mas_tamano: Varchar(25);
mas_loc: Varchar(150);
mas_prov: Varchar(100);
mas_est_id: integer; (FK)
mas_con_id:integer(FK);
mas_fecalta: timestamp;
]
Mascotas_Encontradas
[
mas_id: integer(autoincremental);
mas_name: Varchar(50);
mas_sex:Varchar(20);
mas_raza: Varchar(150);
mas_edad: integer;
mas_obs: text;
mas_tamano: Varchar(25);
mas_loc: Varchar(150);
mas_prov: Varchar(100);
mas_est_id: integer; (FK)
mas_con_id:integer(FK);
mas_fecalta: timestamp;
]
Mascotas_Reunidas
[
mas_id: integer(autoincremental);
mas_name: Varchar(50);
mas_sex:Varchar(20);
mas_raza: Varchar(150);
mas_edad: integer;
mas_obs: text;
mas_tamano: Varchar(25);
mas_loc: Varchar(150);
mas_prov: Varchar(100);
mas_est_id: integer; (FK)
mas_con_id:integer(FK);
mas_fecalta: timestamp;
]
Mas_Situacion
[
sit_id:integer(autoincremental);
sit_name:Varchar(50);
sit_tabla:Varchar(50);
]
Mas_Pics
[
mpic_id: integer(autoincremental);
mpic_mas_id: integer; (FK)
mpic_name: Varchar(50);
mpic_sit_id:integer;(FK)
]
Mas_Codigos
[
mcod_id: integer(autoincremental);
mcod_link: varchar(100);
mcod_mas_id: integer; (FK)
mcod_sit_id:integer;(FK)
mcod_fecalta: timestamp;
]
Mas_Observaciones
[
mobs_id: integer(autoincremental);
mobs_mas_id: integer; (FK)
mobs_con_id: integer; (FK)
mobs_cext_id: integer; (FK)
mobs_calle: Varchar(100);
mobs_loc_id: integer; (FK)
mobs_sit_id:integer;(FK)
]
Mas_Reuniones
[
mreu_id: integer(autoincremental);
mreu_mas_id: integer;
mreu_sit_id:integer;(FK)
mreu_con_id: integer;
]
Sugerencias
[
sug_id: integer(autoincremental);
sug_name: varchar(50);
sug_email: varchar(100);
sug_texto: varchar(500);
]
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)
]
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20121207/b67af2bd/attachment-0001.html>
Más información sobre la lista de distribución Php-avanzado