domingo, 15 de abril de 2012

Normalización 1FN, 2FN, 3FN, 4FN




Datos Normalizados en primera forma normal (1FN) y el universo de datos no normalizados

Antes del análisis y la comparación de los datos normalizados y los no normalizados, conozcamos que es la Normalización de datos:
¿Qué es normalización?
Normalización es un proceso que clasifica relaciones, objetos, formas de relación y demás elementos en grupos, en base a las características que cada uno posee. Si se identifican ciertas reglas, se aplica una categoría; si se definen otras reglas, se aplicará otra categoría.
Estamos interesados en particular en la clasificación de las relaciones BDR. La forma de efectuar esto es a través de los tipos de dependencias que podemos determinar dentro de la relación. Cuando las reglas de clasificación sean más y más restrictivas, diremos que la relación está en una forma normal más elevada. La relación que está en la forma normal más elevada posible es que mejor se adapta a nuestras necesidades debido a que optimiza las condiciones que son de importancia para nosotros:
• La cantidad de espacio requerido para almacenar los datos es la menor posible;
• La facilidad para actualizar la relación es la mayor posible;
• La explicación de la base de datos es la más sencilla posible
Se dice que una relación está en una determinada forma normal si satisface un cierto conjunto de restricciones. El proceso de normalización es reversible y no se pierde información.
Etapas de la Normalización


-La diferencia que existe entre los datos Normalizados en primera forma normal (1FN) y el universo de datos no normalizado:
El universo de datos no normalizado se refiere al conjunto de datos que están reunidos bajo un criterio en común, estos datos son una gran cantidad de información desorganizada y, en algunos casos, compleja para su análisis u otros usos, ya que tiene un albedrio de información, y en ello encontraremos muchas inconsistencias o ¨defectos¨, como las siguientes:
Ø La REDUNDANCIA de datos
Ø ERRORES DE ACTUALIZACION de datos.
Ø FALTA DE INTEGRIDAD E INCONSISTENCIA en los datos.
En relación a tablas no normalizadas (cuando almacenamos información no normalizada):
Ø Repetición de nombres de cada tabla.
Ø Presencia de dos filas iguales.
Ø Los datos de una misma columna de un mismo tipo.
Ø De inserción: imposibilidad de adicionar datos en la BD por la ausencia de otros.
Ø De borrado: pérdida no intencionada de datos debido a la eliminación de otros.
En cambio, cuando tenemos los datos organizados bajo ciertos criterios, como la Primera Forma Normal (1FN), se debe cumplir con lo siguiente:
  • Una relación R se encuentra en 1FN si y solo sí por cada renglón columna contiene valores atómicos.
  • Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos repetidos como valores, es decir, contienen un solo valor por cada celda.
  • Todos los ingresos en cualquier columna (atributo) deben ser del mismo tipo.
  • Cada columna debe tener un nombre único, el orden de las columnas en la tabla no es importante.
  • Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de las filas no es importante.

EJEMPLOS DE LA 1FN:

Ejemplo 1:
En esta Guía de Pedido, la PK es el Nro_GI (número de guía) quién determina a los demás atributos de la tabla.

Ejemplo 2:
En este caso de la biblioteca, la PK es el CodLibro, quién determina a los demás atributos de la tabla.



Ejemplo 3:
En esta Informe de Notas, la PK esta conformada por el ID-Estudiante y el ID-Clave, quienes determinan a los demás atributos de la tabla.


Ejemplo 4:
En esta Boleta de Ventas, la PK es el Num_bol (número de boleta) quién determina a los demás atributos de la tabla.



- Explique detalladamente que resuelve la segunda forma normal (2FN) presente 4 ejemplos. También muestre mediante ejemplos las fallas que presenta la 2FN.


Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben depender únicamente de la clave principal).
En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional x \rightarrow y es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que A \in X, X - \{A\} \nrightarrow Y. Una dependencia funcional x \rightarrow y es una dependencia parcial si hay algunos atributos A \in X que pueden ser eliminados de X y la dependencia todavía se mantiene, esto es A \in X, X - \{A\} \rightarrow Y.
Por ejemplo {DNI, ID_PROYECTO} \rightarrow HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente dependiente dado que ni DNI \rightarrow HORAS_TRABAJO ni ID_PROYECTO \rightarrow HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO} \rightarrow NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI \rightarrow NOMBRE_EMPLEADO mantiene la dependencia.
Ejemplos:
Considere una tabla describiendo las habilidades de los empleados:
Habilidades de los empleados
EmpleadoHabilidadLugar actual de trabajo
JonesMecanografía114 Main Street
JonesTaquigrafía114 Main Street
JonesTallado114 Main Street
BravoLimpieza ligera73 Industrial Way
EllisAlquimia73 Industrial Way
EllisMalabarismo73 Industrial Way
HarrisonLimpieza ligera73 Industrial Way
La única clave candidata de la tabla es {Empleado, Habilidad}.
El atributo restante, Lugar actual de trabajo, es dependiente solo en parte de la clave candidata, llamada Empleado. Por lo tanto la tabla no está en 2NF. Observe la redundancia de la manera en que son representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en la 114 Main Street, y dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable a anomalías de actualización: por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro "Tallado". Los datos resultantes implicarían respuestas contradictorias a la pregunta "¿Cuál es el lugar actual de trabajo de Jones?".
Un alternativa 2NF a este diseño representaría la misma información en dos tablas:
Empleados
EmpleadoLugar actual de trabajo
Jones114 Main Street
Bravo73 Industrial Way
Ellis73 Industrial Way
Harrison73 Industrial Way
Habilidades de los empleados
EmpleadoHabilidad
JonesMecanografía
JonesTaquigrafía
JonesTallado
BravoLimpieza ligera
EllisAlquimia
EllisMalabarismo
HarrisonLimpieza ligera
Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 2NF.
Sin embargo, no todas las tablas 2NF están libres de anomalías de actualización. Un ejemplo de una tabla 2NF que sufre de anomalías de actualización es:
Ganadores del torneo
TorneoAñoGanadorFecha de nacimiento del ganador
Des Moines Masters1998Chip Masterson14 de marzo de 1977
Indiana Invitational1998Al Fredrickson21 de julio de 1975
Cleveland Open1999Bob Albertson28 de septiembre de 1968
Des Moines Masters1999Al Fredrickson21 de julio de 1975
Indiana Invitational1999Chip Masterson14 de marzo de 1977
Aunque el Ganador y la Fecha de nacimiento del ganador están determinadas por una clave completa {Torneo, Año} y no son partes de ella, particularmente las combinaciones GanadorFecha de nacimiento del ganador son mostradas redundantemente en múltiples registros. Este problema es tratado por la tercera forma normal (3NF).

 - Explique detalladamente que resuelve la tercera forma normal (3FN) presente 4 ejemplos. También muestre mediante ejemplos las fallas que presenta la 3FN.


La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.
Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.
Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva vía DNUMBER porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.
Formalmente, un esquema de relacion R está en 3 Forma Normal Elmasri-Navathe,2 si para toda dependencia funcional X \rightarrow A, se cumple al menos una de las siguientes condiciones:
  1. X es superllave o clave.
  2. A es atributo primo de R; esto es, si es miembro de alguna clave en R.
Además el esquema debe cumplir necesariamente, con las condiciones de segunda forma normal.
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:
Ganadores del torneo
TorneoAñoGanadorFecha de nacimiento del ganador
Indiana Invitational1998Al Fredrickson21 de julio de 1975
Cleveland Open1999Bob Albertson28 de septiembre de 1968
Des Moines Masters1999Al Fredrickson21 de julio de 1975
Indiana Invitational1999Chip Masterson14 de marzo de 1977
La única clave candidata es {Torneo, Año}.
La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Año} vía el atributo no primario Ganador. El hecho de que la Fecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en diversos registros.
Ejemplos:
Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:
Ganadores del torneo
TorneoAñoGanador
Indiana Invitational1998Al Fredrickson
Cleveland Open1999Bob Albertson
Des Moines Masters1999Al Fredrickson
Indiana Invitational1999Chip Masterson
Fecha de nacimiento del jugador
JugadorFecha de nacimiento
Chip Masterson14 de marzo de 1977
Al Fredrickson21 de julio de 1975
Bob Albertson28 de septiembre de 1968
Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 3NF.

 - Explique detalladamente que resuelve la cuarta forma normal (4FN) presente 4 ejemplos. También muestre mediante ejemplos las fallas que presenta la 4FN.


Una tabla se encuentra en 4FN si, y sólo si, para cada una de sus dependencias múltiples no funcionales X->->Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.


Ejemplo:



Considere el siguiente ejemplo:
Permutaciones de envíos de pizzas
RestauranteVariedad de PizzaÁrea de envío
Vincenzo's PizzaCorteza gruesaSpringfield
Vincenzo's PizzaCorteza gruesaShelbyville
Vincenzo's PizzaCorteza finaSpringfield
Vincenzo's PizzaCorteza finaShelbyville
Elite PizzaCorteza finaCapital City
Elite PizzaCorteza rellenaCapital City
A1 PizzaCorteza gruesaSpringfield
A1 PizzaCorteza gruesaShelbyville
A1 PizzaCorteza gruesaCapital City
A1 PizzaCorteza rellenaSpringfield
A1 PizzaCorteza rellenaShelbyville
A1 PizzaCorteza rellenaCapital City
Cada fila indica que un restaurante dado puede entregar una variedad dada de pizza a un área dada.
Note que debido a que la tabla tiene una clave única y ningún atributo no-clave, no viola ninguna forma normal hasta el BCNF. Pero debido a que las variedades de pizza que un restaurante ofrece son independientes de las áreas a las cuales el restaurante envía, hay redundancia en la tabla: por ejemplo, nos dicen tres veces que A1 Pizza ofrece la Corteza rellena, y si A1 Pizza comienza a producir pizzas de Corteza de queso entonces necesitaremos agregar múltiples registros, uno para cada una de las Áreas de envío de A1 Pizza. En términos formales, esto se describe como que Variedad de pizza está teniendo una dependencia multivalor en Restaurante.
Para satisfacer la 4NF, debemos poner los hechos sobre las variedades de pizza ofrecidas en una tabla diferente de los hechos sobre áreas de envío:

Variedades por restaurante
RestauranteVariedad de pizza
Vincenzo's PizzaCorteza gruesa
Vincenzo's PizzaCorteza fina
Elite PizzaCorteza fina
Elite PizzaCorteza rellena
A1 PizzaCorteza gruesa
A1 PizzaCorteza rellena
Áreas de envío por restaurante
RestauranteÁrea de envío
Vincenzo's PizzaSpringfield
Vincenzo's PizzaShelbyville
Elite PizzaCapital City
A1 PizzaSpringfield
A1 PizzaShelbyville
A1 PizzaCapital City
En contraste, si las variedades de pizza ofrecidas por un restaurante a veces variaran de un área de envío a otra, la tabla original de la tres columnas satisfaría la 4NF.
Ronald Fagin demostró que es siempre posible alcanzar la 4NF (pero no siempre deseable). El teorema de Rissanen es también aplicable en dependencias multivalor.









No hay comentarios:

Publicar un comentario en la entrada