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 
es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que 
. Una dependencia funcional es una dependencia parcial si hay algunos atributos 
que pueden ser eliminados de X y la dependencia todavía se mantiene, esto es 
.
es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que . Una dependencia funcional es una dependencia parcial si hay algunos atributos que pueden ser eliminados de X y la dependencia todavía se mantiene, esto es .
Por ejemplo {DNI, ID_PROYECTO} 
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 HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la dependencia.
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 HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la dependencia.
Ejemplos:
Considere una tabla describiendo las habilidades de los empleados:
| Empleado | Habilidad | Lugar actual de trabajo |
|---|---|---|
| Jones | Mecanografía | 114 Main Street |
| Jones | Taquigrafía | 114 Main Street |
| Jones | Tallado | 114 Main Street |
| Bravo | Limpieza ligera | 73 Industrial Way |
| Ellis | Alquimia | 73 Industrial Way |
| Ellis | Malabarismo | 73 Industrial Way |
| Harrison | Limpieza ligera | 73 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:
| Empleado | Lugar actual de trabajo |
|---|---|
| Jones | 114 Main Street |
| Bravo | 73 Industrial Way |
| Ellis | 73 Industrial Way |
| Harrison | 73 Industrial Way |
-
-
Habilidades de los empleados Empleado Habilidad Jones Mecanografía Jones Taquigrafía Jones Tallado Bravo Limpieza ligera Ellis Alquimia Ellis Malabarismo Harrison Limpieza 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:
| Torneo | Año | Ganador | Fecha de nacimiento del ganador |
|---|---|---|---|
| Des Moines Masters | 1998 | Chip Masterson | 14 de marzo de 1977 |
| Indiana Invitational | 1998 | Al Fredrickson | 21 de julio de 1975 |
| Cleveland Open | 1999 | Bob Albertson | 28 de septiembre de 1968 |
| Des Moines Masters | 1999 | Al Fredrickson | 21 de julio de 1975 |
| Indiana Invitational | 1999 | Chip Masterson | 14 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 Ganador/ Fecha 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 
está en 3 Forma Normal Elmasri-Navathe,2 si para toda dependencia funcional 
, se cumple al menos una de las siguientes condiciones:
está en 3 Forma Normal Elmasri-Navathe,2 si para toda dependencia funcional , se cumple al menos una de las siguientes condiciones:
es superllave o clave.
es atributo primo de ; esto es, si es miembro de alguna clave en .
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:
| Torneo | Año | Ganador | Fecha de nacimiento del ganador |
|---|---|---|---|
| Indiana Invitational | 1998 | Al Fredrickson | 21 de julio de 1975 |
| Cleveland Open | 1999 | Bob Albertson | 28 de septiembre de 1968 |
| Des Moines Masters | 1999 | Al Fredrickson | 21 de julio de 1975 |
| Indiana Invitational | 1999 | Chip Masterson | 14 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:
| Torneo | Año | Ganador |
|---|---|---|
| Indiana Invitational | 1998 | Al Fredrickson |
| Cleveland Open | 1999 | Bob Albertson |
| Des Moines Masters | 1999 | Al Fredrickson |
| Indiana Invitational | 1999 | Chip Masterson |
-
-
Fecha de nacimiento del jugador Jugador Fecha de nacimiento Chip Masterson 14 de marzo de 1977 Al Fredrickson 21 de julio de 1975 Bob Albertson 28 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:
| Restaurante | Variedad de Pizza | Área de envío |
|---|---|---|
| Vincenzo's Pizza | Corteza gruesa | Springfield |
| Vincenzo's Pizza | Corteza gruesa | Shelbyville |
| Vincenzo's Pizza | Corteza fina | Springfield |
| Vincenzo's Pizza | Corteza fina | Shelbyville |
| Elite Pizza | Corteza fina | Capital City |
| Elite Pizza | Corteza rellena | Capital City |
| A1 Pizza | Corteza gruesa | Springfield |
| A1 Pizza | Corteza gruesa | Shelbyville |
| A1 Pizza | Corteza gruesa | Capital City |
| A1 Pizza | Corteza rellena | Springfield |
| A1 Pizza | Corteza rellena | Shelbyville |
| A1 Pizza | Corteza rellena | Capital 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:
|
|
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.
