Normalización de bases de datosDigamos que queremos crear una tabla con la información de usuarios, y los datos a guardar son el nombre, la empresa, la dirección de la empresa y algún e-mail, o bien URL’s si las tienen. En principio comenzarías definiendo la estructura de una tabla como esta:
Normalización CERO
Diríamos que la anterior tabla esta en nivel de Normalización Cero porque ninguna de nuestras reglas de normalización ha sido aplicada. Observa los campos url1 y url2 -- ¿Qué haremos cuando en nuestra aplicación necesitemos una tercera url ? ¿Quieres tener que añadir otro campo/columna a tu tabla y tener que reprogramar toda la entrada de datos de tu código? Obviamente no, tú quieres crear un sistema funcional que pueda crecer y adaptarse fácilmente a los nuevos requisitos. Echemos un vistazo a las reglas del Primer Nivel de Normalización, y las aplicaremos a nuestra tabla.
Primer nivel de Formalización/Normalización. (F/N)
1. Eliminar los grupos repetitivos de las tablas individuales.
2. Crear una tabla separada por cada grupo de datos relacionados.
3. Identificar cada grupo de datos relacionados con una clave primaria.
¿Ves que estamos rompiendo la primera regla cuando repetimos los campos url1 y url2 ? ¿ Y qué pasa con la tercera regla, la clave primaria ? La regla tres básicamente significa que tenemos que poner un campo tipo contador autoincrementable para cada registro. De otra forma, ¿Qué pasaría si tuviéramos dos usuarios llamados Joe y queremos diferenciarlos. Una vez que aplicamos el primer nivel de F/N nos encontraríamos con la siguiente tabla: 
Ahora diremos que nuestra tabla está en el primer nivel de F/N. Hemos solucionado el problema de la limitación del campo url. Pero sin embargo vemos otros problemas....Cada vez que introducimos un nuevo registro en la tabla usuarios, tenemos que duplicar el nombre de la empresa y del usuario. No sólo nuestra BD crecerá muchísimo, sino que será muy fácil que la BD se corrompa si escribimos mal alguno de los datos redundantes. Aplicaremos pues el segundo nivel de F/N:
Segundo nivel de F/N
1. Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros.
2. Relacionar estas tablas mediante una clave externa (Clave foránea).
Hemos separado el campo url en otra tabla, de forma que podemos añadir más en el futuro sin tener que duplicar los demás datos. También vamos a usar nuestra clave primaria para relacionar estos campos:

Vale, hemos creado tablas separadas y la clave primaria en la tabla usuarios, userId, está relacionada ahora con la clave externa en la tabla urls, relUserId. Esto está mejor. ¿Pero qué ocurre cuando queremos añadir otro empleado a la empresa ABC? ¿ o 200 empleados ? Ahora tenemos el nombre de la empresa y su dirección duplicándose, otra situación que puede inducirnos a introducir errores en nuestros datos. Así que tendremos que aplicar el tercer nivel de F/N:
Tercer nivel de F/N.
1. Eliminar aquellos campos que no dependan de la clave.
Nuestro nombre de empresa y su dirección no tienen nada que ver con el campo userId, así que tienen que tener su propio empresaId:
Ahora tenemos la clave primaria EmprId en la tabla empresas relacionadas con la clave externa recEmpresaId en la tabla usuarios, y podemos añadir 200 usuarios mientras que sólo tenemos que insertar el nombre 'ABC' una vez. Nuestras tablas de usuarios y urls pueden crecer todo lo que quieran sin duplicación ni corrupción de datos. La mayoría de los desarrolladores dicen que el tercer nivel de F/N es suficiente, que nuestro esquema de datos puede manejar fácilmente los datos obtenidos de una cualquier empresa en su totalidad, y en la mayoria de los casos esto será cierto.
Ejemplo 2Consideremos la base de datos de personal de una empresa que tiene un conjunto de departamentos. Cada departamento tiene un conjunto de empleados, un conjunto de proyectos y un conjunto de oficinas. Cada empleado tiene una historia de salarios (el conjunto de salarios que ese empleado ha recibido). Cada oficina tiene un conjunto de teléfonos.
La base de datos debe contener la siguiente información:
1. Por cada departamento: número de departamento (único), presupuesto y el número de empleado del gerente del departamento (único).
2. Por cada empleado: número de empleado (único), número de proyecto en el que actualmente trabaja, número de oficina y número de teléfono; más la fecha y salario para cada salario recibido en ese puesto.
3. Por cada proyecto: número de proyecto (único) y presupuesto.
4. Por cada oficina: número de oficina (único), superficie en metros cuadrados y números (únicos) de todos los teléfonos de esa oficina.
El siguiente diagrama muestra las dependencias funcionales directas, tanto las implicadas por el enunciado como las correspondientes a las suposiciones semánticas (razonables) explicitadas más abajo.

Ir al Inicio