Elementos Básicos sobre Normalización en Bases de Datos. Parte II

El presente artículo da continuidad al anterior titulado: Elementos Básicos sobre Normalización en Bases de Datos. Parte I, en el cual se abarcaron los dos primeros niveles de Formalización/Normalización (F/N). Para tener un buen punto de partida debe estudiarse la Parte I del tema en cuestión.

Recordando

Iniciaremos haciendo un breve recordatorio del 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.

id	nombre	empresa	dirección_empresa
1	Pedro	LCT	Lacetel, Miramar, Habanal
2	Jorge	CGR	Cubagran, Bayamo, Granma

email_id	user_id	email
1	1	direccion@lacetel.com
2	1	economia@lacetel.com
3	2	direccion@cubagran.com
4	2	economia@cubagran.com

De este ejemplo quedó pendiente la siguiente pregunta:

• ¿Pero qué ocurre cuando queremos añadir otro empleado a la empresa LCT? ¿o 500 empleados?

Pues bien, podemos decir que tenemos el nombre de la empresa y su dirección duplicándose, otra situación que puede inducirnos a introducir errores en nuestros datos. Para evitar esto tendremos que aplicar el tercer nivel de F/N:

Tercer nivel de F/N:

• 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 id, así que tienen que tener su propio id_empresa como se muestra aquí:

usuarios
id	nombre	id_empresa_fk
1	Pedro	1
2	Jorge	2

empresas
id_empresa	empresa	dirección_empresa
1	LCT	Lacetel, Miramar, Habanal
2	CGR	Cubagran, Bayamo, Granma

emails
email_id	user_id	email
1	1	direccion@lacetel.com
2	1	economia@lacetel.com
3	2	direccion@cubagran.com
4	2	economia@cubagran.com

Ahora tenemos la clave primaria id_empresa en la tabla empresas, relacionada con la clave externa id_empresa_fk en la tabla usuarios, y podemos añadir 500 usuarios mientras que sólo tenemos que insertar el nombre 'LCT' una vez. Nuestras tablas de usuarios y emails pueden crecer todo lo que quieran sin duplicación ni corrupción de datos. Muchos desarrolladores dirían que con aplicar hasta 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, esto será cierto en una buena parte de los casos.

Sin embargo, miremos la tabla emails ¿Se puede apreciar la duplicación de datos? Esto es perfectamente aceptable si le pedimos al usuario de nuestra aplicación la entrada de datos del campo email, y por lo tanto es sólo una coincidencia que Pedro y Jorge teclearan los mismos emails. ¿Pero qué pasaría si en lugar de entrada libre de texto usáramos un menú desplegable con varios emails predefinidos? Es aquí donde tendríamos que ir al siguiente nivel de F/N, el cuarto, muchos desarrolladores lo pasan por alto porque depende mucho de un tipo muy específico de relación, la relación 'muchos a muchos’, la cual aún no hemos visto.

Relaciones entre Datos

Antes de entrar en detalles acerca del cuarto nivel de F/N es preciso tener presente tres tipos de relaciones que se establecen entre los datos, estas son:

1.    Uno a uno

2.    Uno a muchos

3.    Muchos a muchos

La relación muchos a muchos, es ligeramente más compleja que las dos primeras. Observa en el ejemplo del Tercer Nivel de F/N que tenemos a un usuario relacionado con varios emails. Entonces, vamos a cambiar la estructura para permitir que varios usuarios estén relacionados con varios emails y así tendremos una relación muchos a muchos. Esta es la forma en la que quedarían las tablas:

usuarios
id	nombre	id_empresa_fk
1	Pedro	1
2	Jorge	2

empresas
id_empresa	empresa	dirección_empresa
1	LCT	Lacetel, Miramar, Habanal
2	CGR	Cubagran, Bayamo, Granma

emails
email_id	email
1	direccion@lacetel.com
2	economia@lacetel.com
3	direccion@cubagran.com
4	economia@cubagran.com

emails_relations
relation_id	email_id	user_id
1	1	1
2	1	2
3	2	1
4	2	2

Para disminuir la duplicación de los datos (proceso que nos llevará al Cuarto Nivel de F/N), hemos creado una tabla que sólo tiene claves externas y primarias emails_relations. Ahora podemos expresar fielmente la relación que ambos Pedro y Jorge tienen entre cada uno de ellos, y entre ambos, los emails. Así que veamos exactamente qué pasa en el Cuarto Nivel de F/N:

Cuarto nivel de F/N:

• En las relaciones muchos a muchos, entidades independientes no pueden ser almacenadas en la misma tabla.

Hemos optimizado nuestra tabla emails eliminado duplicados y hemos puesto las relaciones en su propia tabla.

Quinto nivel de F/N:

En la mayoría de los casos no es necesario aplicar este quinto nivel:

• La tabla original debe ser reconstruida desde las tablas resultantes en las cuales ha sido divida en partes.

La correcta aplicación de esta regla proporciona la seguridad de que no has creado ninguna columna extraña en tus tablas y que la estructura de las tablas que has creado sea del tamaño justo que tiene que ser.

Es una buena práctica aplicar esta regla, pero a no ser que estés tratando con una extensa estructura de datos probablemente no la necesitarás.