Normalizacion de tablas de bases de datos hasta 3FN

1. Bases de datos. Normalización
Profesor: José Javier Bermúdez Hernández

2. ¿Qué es la normalización?
 La teoría de la normalización, desarrollada por Codd en
1972, es un método de análisis y diseño que permite
mejorar el diseño lógico de una Base de datos relacional.
 Se fundamenta en las Formas Normales, que son un
conjunto de restricciones que deben cumplir las relaciones.
 La normalización persigue evitar:
 La redundancia de los datos: repetición de datos en un
sistema.
 Anomalías de actualización: inconsistencias de los
datos como resultado de datos redundantes y
actualizaciones parciales.
 Anomalías de borrado: pérdidas no intencionadas de
datos debido a que se han borrado otros datos.
 Anomalías de inserción: imposibilidad de adicionar
datos en la base de datos debido a la ausencia de otros
datos.

3. Por ejemplo: redundacia
 Tomado como ejemplo esta tabla, se plantea el
problema:
 Redundancia: cuando un autor tiene varios libros, se
repite la nacionalidad.

4. Por ejemplo: anomalías de
actualización
 Tomado como ejemplo esta tabla, se plantea el problema:
 Anomalías de modificación: Si Adoración de Miguel y Mario Piattini
desean cambiar de editor, se tendría que modificar en al menos esos 2
lugares, en esas dos filas. A priori no podemos saber cuántos autores
tiene un libro. Los errores son frecuentes al olvidar la modificación de un
autor. Se pretende modificar en un sólo sitio.

5. Por ejemplo: anomalías de inserción
 Tomado como ejemplo esta tabla, se plantea el problema:
 Anomalías de inserción: Se desea dar de alta un autor sin libros,
en un principio. NOMBRE y CODLIBRO son campos que forman
parte de la clave, una clave no puede tomar valores nulos.

6. Por ejemplo: anomalías de borrado
 Tomado como ejemplo esta tabla, se plantea el problema:
 Anomalías de borrado: si se borra el registro del único libro de un
autor que tiene un solo libro (Emilio Carrillo) se perdería toda la
información de la editorial, si solo tiene ese libro y del autor.
Sería deseable poder borrar ese libro pero no al autor ni la
editorial.

7. 1FN
 Sólo se permiten valores
atómicos en una columna.
 Un ejemplo de esto es
cuando en un campo de
texto metemos varios valores
del mismo dominio, como por
ejemplo tres números de
teléfono
 Para evitar esto hay que
definir una nueva tabla que
tendrá el identificador de la
tabla de la que parte y el
campo multivaluado,
haciendo juntos de clave
única compuesta.

8. 1FN
 No se permiten grupos
repetidos en varias columnas
Esto es una variante de lo
anterior: separamos los campos
de un mismo dominio en varias
columnas, haciendo un grupo
difícilmente procesable a la hora
de consultarlo. En el ejemplo
anterior sería tener el campo
telefono1, telefono2… y así. Es
evidente que este fallo del
diseño es incluso peor que el
anterior pues habrá muchos
campos nulos, y en caso de
necesitar más tendríamos que
redimensionar la tabla con un
nuevo campo (telefono3). Pero
la solución es sencilla: la misma
que en el anterior caso.

9. Dependencia funcional
 Dada una relación (tabla) R, el atributo y de R
depende funcionalmente del atributo x de R
R.x ------------> R.y
si x determina el valor de y, es decir, un valor y
en R está asociado a cada valor x en R. Tanto
x como y pueden ser atributos compuestos.
 Ejemplo, dada la tabla:
PERSONA(NIF, nombre, apellidos, edad)
Podemos observar al menos esta dependencia
funcional:
NIF ------------> nombre

10. 2FN
 Una tabla está en segunda forma normal siempre que esté en
primera forma normal y todos sus atributos (campos) dependan
totalmente de la clave sin ser parte de ella.
 Es decir, si un campo de la tabla no depende totalmente de la
clave (que puede ser compuesta), debe sacarse fuera con la
parte de la clave principal de la que es dependiente.

11. 3FN
 Una relación está en 3FN si, y sólo
si, está en 2FN y, además, cada
atributo no clave no depende
transitivamente de la clave primaria.
 Ejemplo, dada esta tabla,
analizando los datos podemos ver
que para el mismo inquilino
tenemos el mismo importe de
alquiler.
cod_inquilino --- cod_edificio
cod_edificio --- alquiler
Por lo que hay una transitiva:
cod_imquilino --- alquiler
¡No está en 3FN!

12. 3FN
 ¿Cómo se soluciona el problema? Se extraen los
atributos dependientes en otra tabla. En la tabla
original se deja el atributo del que dependen otros,
que será clave ajena a la nueva tabla.
INQUILINO(cod_inquilino, cod_edificio)
------------
EDIFICIO(cod_edificio, alquiler)