Capítulo 6 Normalizacion

La normalización es la transformación de las vistas de usuario complejas y del almacén de datos a un juego de estructuras de datos más pequeñas y estables. Además de ser más simples y estables, las estructuras de datos son más fáciles de mantener que otras estructuras de datos. (Kendall, 2005).

La normalización de bases de datos es un proceso que consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional. Con objeto de minimizar la redundancia de datos, facilitando su gestión posterior (Wikipedia).

Una vez obtenido el esquema relacional resultantes del modelo entidad relación que representaba la base de datos, normalmente tendremos una buena base de datos. Pero otras veces, debido a fallos en el diseño o a problemas indetectables en esta fase del diseño, tendremos un esquema que puede producir una base de datos que incorpore estos problemas:

Redundancia. Se llama así a los datos que se repiten continua e innecesariamente por las tablas de las bases de datos.

Ambigüedades. Datos que no clarifican suficientemente el registro al que representan.

6.1 Primera Forma Normal

Es la forma normal propia al esquema relacional, de uso obligatorio.

  • Todos los atributos llave están definidos.
  • No hay grupos repetidos en la tabla. Cada fila/columna contiene un solo valor, no un conjunto de ellos.
  • Todos los atributos son dependientes de la llave primaria.
  • Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son simples e indivisibles.
  • No debe existir variación en el número de columnas.
  • Los campos no clave deben identificarse por la clave (dependencia funcional).
  • Debe existir una independencia del orden tanto de las filas como de las columnas; es decir, si los datos cambian de orden no deben cambiar sus significados.

Algunos ejemplos de tablas (o de vistas) que no satisfacen esta definición de primera forma normal son:

  • Una tabla que carece de una clave primaria. Esta tabla podría acomodar filas duplicadas, en violación de la condición de filas duplicadas.
  • Una vista cuya definición exige que los resultados sean retornados en un orden particular, de modo que el orden de la fila sea un aspecto intrínseco y significativo de la vista. Las tuplas en relaciones verdaderas no están ordenadas una con respecto de la otra.
  • Una tabla con por lo menos un atributo que pueda ser nulo. Un atributo que pueda ser nulo estaría en violación de la condición 4, que requiere a cada campo contener exactamente un valor de su dominio de columna. Sin embargo, debe observarse que este aspecto de la condición 4 es controvertido. Muchos autores consideran que una tabla está en 1FN si ninguna clave candidata puede contener valores nulos, pero se aceptan éstos para atributos (campos) que no sean clave, según el modelo original de Codd sobre el modelo relacional, el cual hizo disposición explícita para los nulos.

Tupla con valores multiples. Es imperativo mantener la unicidad de los valores de los atributos/columnas. En que si bien la solución inicial puede ser duplicar el registro/tupla para contener la información adicional, no es una medida aceptada. Otra opción aparente sería agregar curso 1 y curso 2. Al igual que lo indicado en la figura siguiente permtiría atributos en blanco o nulos.

Transformación 1 FN. Adición de columna Transformación 1 FN. Adición de nueva entidad/relación (telefonos) Entonces, la solución pasa por la creación de otra entidad/tabla para el almacenamiento de teléfonos.

6.2 Segunda Forma Normal

6.3 Tercera Forma Normal

6.4 Problema de Redundancia

Primera Forma Normal. Separamos las tablas estableciendo la relación entre ella por matricula, que referencia al alumno (clave primaria). Por tanto la nueva tabla tiene como clave primaria “codigo” y posee un campo matricula que actúa como clave foránea a matricula en alumno.

La relación alumno.matricula <- curso.matricula establece la vinculación entre los registros de cada tabla.

Aún existe redundancia de datos en tabla de cursos. Por ende debe dividirse en una tabla alterna.

Segunda Forma Normal. Cuando se estable una relación muchos a muchos (N:M) se genera una relación como tabla adicional. En este caso alumno_curso.

Tercera Forma Normal. Eliminar aquellos campos que no dependan de la clave. Carrera no depende directamente de la clave primaria en alumnos, por tanto debe sacarse de la tabla alumnos.

6.5 Discusión

Referencia