Documente Academic
Documente Profesional
Documente Cultură
Ejemplo Normalizacin
Un paciente puede acudir al mdico muchas veces en la vida. En cada visita que realiza el paciente le puede atender un mdico distinto por motivos distintos. Un mdico a su vez atiende a muchos pacientes. Los campos en comn son los cdigos de los pacientes y de los mdicos. Estos campos compartidos tienen el origen en la tabla que los cre (tabla mdicos o tabla pacientes) De esa forma los datos de una visita en parte procedern de las tablas mdicos y pacientes, y en parte sern datos propios de visitas.
el problema: si cada vez que viene un Paciente al mdico se le tiene que abrir una ficha, en poco tiempo los datos personales del paciente (direccin y telfono) estarn repetidos muchas veces.
Ejemplo 2:
Se desea crear una tabla con la informacin de usuarios, y los datos a guardar son el nombre, la empresa, la direccin de la empresa y algun e-mail, o bien URL si las tienen.
usuarios Nombre Joe Jill Empresa ABC XYZ Direccion_ empresa Work Lane Job Street Url1 abc.com abc.com Url2 xyz.com xyz.com
Esta tabla esta en nivel de Formalizacin Cero porque ninguna de las reglas de normalizacin ha sido aplicada.
Eliminar los grupos repetitivos de la tablas individuales. Crear una tabla separada por cada grupo de datos relacionados. Identificar cada grupo de datos relacionados con una clave primaria.
usuarios userId 1 1 2 2 nombre Joe Joe Jill Jill empresa ABC ABC XYZ XYZ direccin_ empresa 1 Work Lane 1 Work Lane 1 Job Street 1 Job Street url abc.com xyz.com abc.com xyz.com
Cada vez que introducimos un nuevo registro en la tabla usuarios, tenemos que duplicar el nombre de la empresa y del usuario.
Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros. Relacionar estas tablas mediante una clave externa.
direccion_empres a 1 Work Lane 1 Job Street
empresas emprId 1 2
uno-a-uno
La tabla usuarios en el Primer Nivel de F/N del ejemplo de arriba. Por un momento imaginamos que ponemos el campo url en una tabla separada, y cada vez que introducimos un registro en la tabla usuarios tambin introducimos una sola fila en la tabla urls. Entonces tendramos una relacin uno-a-uno: cada fila en la tabla usuarios tendra exactamente una fila correspondiente en la tabla urls.
uno-con-varios
En el Segundo Nivel de F/N. las tablas permiten a un slo usuario tener asociadas varias urls. Esta es una relacin uno-convarios, el tipo de relacin ms comn, y hasta que se present el dilema del Tercer Nivel de F/N.
varios-con-varios,
La relacin varios-con-varios, sin embargo, es ligeramente ms compleja. Observa en el Tercer Nivel de F/N se tiene a un usuario relacionado con varias urls. Ahora se va a cambiar la estructura para permitir que varios usuarios estn relacionados con varias urls y as se tendra una relacin varios-con-varios.
emprId
empresa
ABC XYZ
urls
relatedUrlId 1 1 2 2
relatedUserId 1 2 1 2
1.
En las relaciones varios-con-varios, entidades independientes no pueden ser almacenadas en la misma tabla. Ya que slo se aplica a las relaciones varios-convarios, la mayora de los desarrolladores pueden ignorar esta regla de forma correcta. Pero es muy til en ciertas situaciones, tal como esta. Hemos optimizado nuestra tabla urls eliminado duplicados y hemos puesto las relaciones en su propia tabla.
La tabla original debe ser reconstruida desde las tablas resultantes en las cuales a sido troceada.
Los beneficios de aplicar esta regla aseguran que no has creado ninguna columna extraa en tus tablas y que la estructura de las tablas que has creado sea del tamao justo que tiene que ser. Es una buena prctica aplicar este regla, pero a no ser que estes tratando con una extensa estructura de datos probablemente no la necesitars.
Ejercicio
Normalizar la siguiente tabla.
IdPedido IdCliente Id.Vendedor Fecha_Pedido Fecha_Entrega Productos
5 6 3 5 1
3 chorizos, 2 ajos, 1 cebolla 4 panes, 2 fresas 1 revista, 2 cds, 1 pan 2 Manzanas, 1 pan, 2 quesos 1 vino, 2 panes