1.- Mayor ocupación en disco de los datos: el mismo dato se repite N veces, por lo que ocupan espacio innecesario. Podéis ver cómo se repite la dirección y el teléfono de “Juancito Pérez Pí” tres veces, desperdiciando espacio (con almacenarlo una sola vez sería suficiente).
2.- Posibles inconsistencias de datos: debido a la repetición de datos, es posible que por un error, los datos sean inconsistentes. Por ejemplo, podéis ver que el teléfono de “Federico Antóñez” es 555-111111 en un registro pero 555-111112 en el otro, así que… ¿cuál de los dos teléfonos es el correcto?
3.- Problemas a la hora de cambiar datos repetidos: si un cliente cambia de teléfono o dirección, tenemos que modificar todas sus facturas (o cualquier tabla donde aparezca el número de teléfono) para cambiarle el dato, siendo un proceso engorroso y pudiendo crear más inconsistencias si cometemos un error.
Hay casos muy especiales en los que la redundancia de datos puede ser recomendable por razones de rendimiento, aunque esta es la excepción que confirma la regla, y yo no lo habría sin pensármelo dos veces.
La solución que da la primera forma normal a este problema es poner los datos en tablas separadas, dependiendo del origen de la información: la información perteneciente a factura irá en la tabla FACTURA y la información perteneciente a clientes irá en la tabla CLIENTE. Además, podemos encontrarnos con el problema que los clientes de países distintos tiene una codificación independiente, es decir, que pude existir el cliente 1 de España y el cliente 1 de Argentina a la vez. Un diseño que cumpla la primera forma normal podría ser:
|| FACTURA || ||
|| Columna || Tipo ||
|| (*) Referencia || A(10) ||
|| Descripción || A(50) ||
|| Cód cliente || N(5) ||
|| País || A(20) ||
|| Importe || N(12) ||
|| CLIENTE || ||
|| Columna || Tipo ||
|| (*) Cód. Cliente || N(5) ||
|| (*) País || A(20) ||
|| Nombre || A(50) ||
|| Teléfono || A(10) ||
|| Dirección || A(50) ||
Tan sólo se almacena el código del cliente para cada una de sus facturas, y cuando se tenga que modificar la dirección, se modificará para todas las facturas de ese cliente. Con esto ya hemos hecho que se cumpla la 3ª forma normal. Siguiendo con nuestro ejemplo, los datos quedarían así:
FACTURA:
|| Ref. || Descripción || Cód cliente || País || Importe ||
|| FR00123 || Tornillos sin rosca || 1 || Argentina || 500 ||
|| FR00124 || Servicios prestados || 2 || España || 4.587 ||
|| FR00125 || Compra de tuercas sin agujero || 1 || Argentina || 258.987 ||
|| FR00126 || Atrasos || 2 || España || 1.245.847 ||
|| FR00127 || Tornillos sin rosca || 2 || España || 500 ||
CLIENTE:
|| Cód. cliente || País || Nombre || Teléfono || Dirección ||
|| 1 || Argentina || Federico Antóñez || 555-111111 || C/ Alta, nº 2 ||
|| 1 || España || Juancito Pérez Pí || 555-131415 || C/ del Abedul, s/n ||
|| 2 || España || Antoñito “el salao” || 555-999888 || C/ Marismas, 25 ||
Y para que la tabla CLIENTE cumpla con la primera forma normal, hemos tenido que añadir una nueva columna (Código), que sirve para identificar a cada cliente con un código. Como es posible que exista el mismo código de cliente varias veces (una vez por cada país), la columna País se ha tenido que incluir dentro de la clave primaria. La segunda forma normal nos dice que hay que sacar las columnas descriptivas que pertenezcan a la clave a otra tabla. Si embargo, la primera forma normal no nos dice que la tabla CLIENTE esté mal definida, ya que todos los campos son datos relacionados con el cliente. Pero vemos que el País (España, Argentina, etc.) se repetirá varias veces, volviendo a caer en el error de la redundancia. Para ello hay que crear una tabla aparte en la que se incluya el código y la descripción del país y así, a la hora de almacenar el país en la tabla CLIENTE, sólo se almacenará un código y no su descripción completa que ocupa mucho más espacio. Además a la hora de modificar una descripción, sólo habrá que modificarla una vez.
El esquema en segunda forma normal quedaría así:
|| FACTURA || ||
|| Columna || Tipo ||
|| (*) Referencia || A(10) ||
|| Descripción || A(50) ||
|| Cód. Cliente || N(3) ||
|| Cód país || N(5) ||
|| Importe || N(12) ||
|| CLIENTE || ||
|| Columna || Tipo ||
|| (*) Cód cliente || N(3) ||
|| (*) Cód país || N(5) ||
|| Nombre || A(50) ||
|| Teléfono || A(10) ||
|| Dirección || A(50) ||
|| PAIS || ||
|| Columna || Tipo ||
|| (*) Cód. país || N(5) ||
|| Descripción || A(50) ||
Y los datos del siguiente modo: FACTURA:
|| Ref. || Descripción || Cód cliente || Cód. País || Importe ||
|| FR00123 || Tornillos sin rosca || 1 || 22 || 500 ||
|| FR00124 || Servicios prestados || 2 || 34 || 4.587 ||
|| FR00125 || Compra de tuercas sin agujero || 1 || 22 || 258.987 ||
|| FR00126 || Atrasos || 2 || 34 || 1.245.847 ||
|| FR00127 || Tornillos sin rosca || 2 || 34 || 500 ||
CLIENTE:
|| Cód. cliente || Cód. País || Nombre || Teléfono || Dirección ||
|| 1 || 22 || Federico Antóñez || 555-111111 || C/ Alta, nº 2 ||
|| 1 || 34 || Juancito Pérez Pí || 555-131415 || C/ del Abedul, s/n ||
|| 2 || 22 || Antoñito “el salao” || 555-999888 || C/ Marismas, 25 ||
PAÍS:
|| Cód. País || Descripción ||
|| 22 || Argentina ||
|| 34 || España ||
En este punto, aunque sólo hayamos aplicado la primera y segunda forma normal, ya tenemos la base de datos normalizada, ya que la tercera forma normal, se cumple en todas las tablas.
Una forma de abreviar las formas normales es aplicando directamente la tercera, ya que si un esquema de base de datos cumple la tercera forma normal, automáticamente está cumpliendo la primera y la segunda.
Concepto de relación
Se denomina relación a todo aquellos vínculos que establecen unas tablas con otras, debidos a la aplicación de las formas normales.
En el ejemplo anterior, hemos creado relaciones entre unas tablas y otras desde el momento en que se separan los datos en más de una tabla y se utiliza el código como enlace entre unas y otras. Una relación que hemos creado ha sido la que se establece entre la tabla CLIENTE y la tabla PAIS. Ambas tablas están "intercomunicadas" por una de sus columnas: Cód Pais para CLIENTE y Código para PAIS. Con esta relación sabemos que todo campo Cód País de la tabla CLIENTE, tiene un registro equivalente en la tabla PAIS.
Relación 1-1
La relación 1-1 se establece cuando un registro de la tabla A tiene un solo registro relacionado en la tabla B. Esta relación se podría establecer por ejemplo si creamos una tabla de Pagos de facturas.
Si la clave se hubiese definido sólo con el campo "Referencia", no podríamos haber insertado más de una fecha para la misma referencia. Sin embargo al definirla con los campos "Referencia, Fecha", podemos introducir tantas parejas Referencia-Fecha como queramos.
Las relaciones 1-N también son llamadas normalmente maestro-detalle, donde el maestro es la tabla A (el 1 en la relación) y el detalle es la tabla B (el N en la relación). En nuestro ejemplo FACTURA es el maestro y PAGOS_FRACCIONADOS_FACTURA un detalle de FACTURA...
