No­r­ma­li­za­ción: evita las re­du­n­da­n­cias en las bases de datos

Uno de los términos clave de la mo­de­la­ción re­la­cio­nal de datos es la no­r­ma­li­za­ción. En este modelo la calidad del diseño de la base de datos viene de­te­r­mi­na­da por una re­du­n­da­n­cia reducida al mínimo posible, puesto que los datos repetidos producen anomalías se­má­n­ti­cas que di­fi­cu­l­tan tanto el pro­ce­sa­mie­n­to au­to­má­ti­co de los datos como el ma­n­te­ni­mie­n­to mismo de la base de datos. La no­r­ma­li­za­ción es la es­tra­te­gia con la que se eliminan las re­du­n­da­n­cias en las bases de datos re­la­cio­na­les.

La no­r­ma­li­za­ción es un concepto de diseño de bases de datos que se aplica a las bases de datos re­la­cio­na­les para evitar las re­du­n­da­n­cias.

El modelo re­la­cio­nal es el concepto más extendido en la gestión in­fo­r­ma­ti­za­da de los datos. En las bases de datos de este tipo, la in­fo­r­ma­ción se guarda en registros en tablas in­te­r­co­ne­c­ta­das por medio de claves. Un registro se compone de varios campos de valores que se su­bo­r­di­nan a ciertos atributos a lo largo de las columnas de la tabla.

La siguiente tabla muestra los datos de facturas ficticias, emitidas por una di­s­tri­bui­do­ra de material de oficina. El empleado José García ha hecho un pedido para su empresa de 10 monitores, 12 ratones y una silla de oficina. La compra de María Pérez comprende 2 or­de­na­do­res po­r­tá­ti­les y 2 juegos de au­ri­cu­la­res.

Datos de facturas

En la base de datos de esta tienda online, los datos de las facturas se ordenan en función de los atributos número de factura (Nº factura), fecha, cliente, número de cliente (Nº cliente), dirección, posición del ítem (Pos. ítem), artículo, número de artículo (Nº artículo), número de unidades (Uds.) y precio. Cada línea de la tabla co­rre­s­po­n­de a un registro, de­no­mi­na­do tupla.

Esta tabla co­n­s­ti­tu­ye un ejemplo de tabla mal diseñada, puesto que ya de entrada saltan a la vista sus múltiples re­du­n­da­n­cias. A esto se añade que las celdas de las columnas Cliente y Dirección contienen datos co­m­pue­s­tos por más de un valor (mu­l­ti­va­lor). Se hablaría en este caso de una base de datos no no­r­ma­li­za­da, cuyo mayor in­co­n­ve­nie­n­te radica en que necesita más memoria como co­n­se­cue­n­cia de la re­pe­ti­ción de valores. Además, los atributos que contienen datos mu­l­ti­va­lor no se pueden procesar ni re­la­cio­nar bien. Así, según esta tabla de ejemplo, los dos clientes tienen una dirección de Vi­lla­rri­ba, pero como esta in­fo­r­ma­ción no se ha recogido por separado (calle, número, CP, municipio), no sería posible filtrar la tabla por clientes del mismo municipio.

Para evitar los campos dobles o co­m­pue­s­tos por varios valores se han de­sa­rro­lla­do, en el marco de los modelos re­la­cio­na­les, tres formas normales que se co­m­ple­me­n­tan entre sí. Cada forma normal persigue que la base de datos se encuentre en un estado de­te­r­mi­na­do, y para lograrlo, se han de cumplir ciertas co­n­di­cio­nes. Una base de datos satisface entonces la primera, la segunda o la tercera forma normal, si se cumplen las co­n­di­cio­nes de cada una de ellas.

Para aclarar cómo se aplican las tres formas normales a una base de datos re­la­cio­nal, se re­co­rre­rán en adelante las diversas fases de la no­r­ma­li­za­ción con ejemplos. Pa­r­ti­re­mos para ello del fragmento mostrado arriba.

Una tabla en una base de datos re­la­cio­nal está en la primera forma normal cuando se cumplen estas co­n­di­cio­nes:

• Todos los datos son atómicos.
• Todas las columnas contienen el mismo tipo de datos.

Un registro se considera atómico cuando a cada in­fo­r­ma­ción (cada asunto) se le reserva una celda propia.

En nuestra tabla los campos co­rre­s­po­n­die­n­tes a los atributos cliente, dirección y precio no son atómicos o no contienen datos del mismo tipo:

Datos de facturas

Las celdas en negrita muestran que nuestra tabla incumple ambas co­n­di­cio­nes y por lo tanto no está en la primera forma normal. Para no­r­ma­li­zar­la se hace lo siguiente:

1. Su­b­di­vi­dir todos los datos mu­l­ti­va­lor en columnas separadas.
2. Comprobar que los valores en cada columna son del mismo tipo.

Para cumplir con el estado atómico de los datos, los atributos cliente y dirección se han de su­b­di­vi­dir en los atributos más es­pe­cí­fi­cos nombre y apellidos, así como calle, número, código postal y municipio.

En la columna Precio hay datos en euros y en céntimos: hay que decidirse por un tipo de dato (en €) para generar campos cohe­re­n­tes. Quedaría así:

El resultado es una tabla que, si bien está en la primera forma normal, los valores du­pli­ca­dos siguen im­pi­die­n­do procesar los datos de forma eficiente. Para reducir las re­du­n­da­n­cias se re­co­mie­n­da llevarla a la segunda forma normal.

Para estar en la segunda forma normal, a las co­n­di­cio­nes de la primera se añade la siguiente:

• Los atributos que no forman parte de ninguna clave han de depender fu­n­cio­na­l­me­n­te de toda la clave primaria.

Al principio, se definió a una base de datos re­la­cio­nal como un sistema de tablas re­la­cio­na­das por medio de claves. Las claves sirven para ide­n­ti­fi­car ine­quí­vo­ca­me­n­te a los registros. La clave que permite nombrar cla­ra­me­n­te a cada una de las filas de una tabla se denomina su­pe­r­cla­ve. Esta puede resultar de los valores de una única columna o de la suma de los valores de varias columnas.

En nuestro ejemplo, los atributos número de factura, número de cliente y posición de ítem podrían componer una posible su­pe­r­cla­ve:

Una clave número de factura, número de cliente y posición de ítem con los valores {124, 12, 1} pe­r­mi­ti­ría entonces ide­n­ti­fi­car cla­ra­me­n­te al registro de la compra que ha hecho María Pérez:

Pero para esta ide­n­ti­fi­ca­ción no es necesaria toda la in­fo­r­ma­ción aportada por la su­pe­r­cla­ve. Una co­m­bi­na­ción de número de factura y posición de ítem (es decir, un su­b­co­n­ju­n­to de la su­pe­r­cla­ve) debería bastar para ide­n­ti­fi­car a cada registro. Estas claves con la mínima cantidad de atributos se conocen como claves ca­n­di­da­tas.

No­r­ma­l­me­n­te, se escoge a una clave candidata por tabla para re­pre­se­n­tar­la. Su valor ideal es una nu­me­ra­ción co­rre­la­ti­va. Esta clave se erige en clave primaria y señala el orden de los registros.

Como cualquier candidata a clave, la clave primaria también puede co­m­po­ne­r­se de un solo valor o, como en nuestro ejemplo, de varias claves. Nuestra tabla utiliza una clave primaria compuesta; formada por el número de factura y la posición de ítem.

Pero para llevar a una tabla a la segunda forma normal, no solo es necesario conocer la clave primaria y todos los atributos que no son clave, sino también cómo se re­la­cio­nan entre sí. Para hacerlo se siguen estos pasos:

1. Comprueba que todos los atributos no-clave dependen por completo de la clave primaria. Esta de­pe­n­de­n­cia se da si todos los atributos de la clave primaria son ne­ce­sa­rios para ide­n­ti­fi­car a los atributos no-clave. Esto quiere decir también que las tablas con claves primarias simples se ajustan au­to­má­ti­ca­me­n­te a la 2FN si se cumplen las co­n­di­cio­nes para la 1FN.
2. Relega a los atributos no-clave que no dependen de la clave primaria a tablas di­fe­re­n­tes.

Si volvemos a nuestra tabla y la ob­se­r­va­mos ate­n­ta­me­n­te, podremos ver que las co­n­di­cio­nes para la segunda forma normal no se cumplen por los si­guie­n­tes motivos: la columna Fecha solo depende del número de factura, pero no de la posición del artículo en la factura. Lo mismo puede decirse para los datos de los clientes (apellido, nombre, calle, nº, CP, municipio).

Para que una tabla esté en la 2FN enviamos a los atributos de­pe­n­die­n­tes del número de factura a una tabla separada llamada Factura:

Factura

A la tabla con el resto de datos la llamamos Posición del ítem:

Posición del ítem

Tras la no­r­ma­li­za­ción, el número de factura se encuentra en ambas tablas, co­ne­c­tá­n­do­las. Mientras que este atributo actúa de clave primaria en la tabla Factura, en la tabla Posición del ítem se utiliza como clave foránea y forma parte, al mismo tiempo, de la clave primaria compuesta de la tabla.

Nuestras tablas están ahora en la segunda forma normal, pero aún no se han eliminado del todo las re­du­n­da­n­cias. Por eso‚ la meta de la no­r­ma­li­za­ción suele ser la tercera forma normal.

Para que una tabla esté en la tercera forma normal ha de cumplir las co­n­di­cio­nes de las dos primeras y además:

• Los atributos no-clave no pueden depender de forma tra­n­si­ti­va de una clave candidata.

Se da una de­pe­n­de­n­cia tra­n­si­ti­va si un atributo que no es clave depende de otro atributo que no es clave y de forma indirecta de su clave candidata.

Nuestro esquema incumple las co­n­di­cio­nes de la tercera forma normal en varios puntos:

Factura

En la tabla Factura, los atributos nombre y apellido así como calle, número, CP y municipio no solo dependen de la clave primaria (número de factura) sino también del número de cliente.

En la tabla Posición del ítem los atributos artículo y precio dependen de la clave primaria compuesta por número de factura y el número de ítem, pero también del número de artículo. También se infringe aquí la condición es­pe­cí­fi­ca de la tercera forma normal:

Posición del ítem

Para eliminar las de­pe­n­de­n­cias entre atributos no-clave re­pa­r­ti­mos los datos en tablas separadas que se in­te­r­co­ne­c­tan con claves ajenas. De este modo, re­su­l­ta­rán las cuatro tablas no­r­ma­li­za­das Factura, Cliente, Posición y Artículo.

La clave primaria de la tabla Factura es un número de factura co­rre­la­ti­vo. Cada número de factura se clasifica con la fecha de la factura y el número de cliente:

Factura

En la tabla Cliente se depositan datos más apro­xi­ma­dos sobre los clientes, y ambas tablas, Factura y Cliente, se conectan mediante el número de cliente, que en la tabla Cliente hace de clave primaria y en Factura de clave ajena:

Una tabla crucial en nuestra base de datos es la Posición del ítem, puesto que revela qué artículos se incluyen en cada factura y cuántas unidades se han pedido. La clave primaria co­rre­la­ti­va de la tabla resulta del número de factura y la posición del ítem en la factura. Los artículos están presentes en la tabla solo con el número de artículo y actúan de clave ajena que enlaza con la tabla Artículo.

La tabla Artículo solo contiene los detalles sobre cada artículo, como su de­no­mi­na­ción o el precio. Como clave primaria tenemos el número de artículo co­rre­la­ti­vo:

En nuestro ejemplo puede parecer poco eficiente fra­g­me­n­tar dos tablas en cuatro. De hecho, las re­du­n­da­n­cias en los datos de solo dos clientes no saltan apenas a la vista. Ima­gi­ne­mos, sin embargo, que queremos procesar varios cientos de miles de registros sobre clientes o sobre la gama de productos de la empresa de forma co­n­si­s­te­n­te y libre de co­n­tra­di­c­cio­nes. Esto solo suele ser posible con un esquema que se ajuste a la tercera forma normal.

Aun cuando la no­r­ma­li­za­ción de bases de datos implica un mayor esfuerzo de pro­gra­ma­ción, la tercera forma normal está co­n­si­de­ra­da como el estándar para los esquemas re­la­cio­na­les y solo se descarta bajo contadas ex­ce­p­cio­nes. Una de ellas sería la de­no­r­ma­li­za­cion de bases de datos que están en la tercera forma normal a la segunda forma normal. Esto se hace porque los Joins que enlazan varias tablas en bases de datos muy grandes tardan mucho tiempo. De­no­r­ma­li­za­n­do la base de datos se espera reducir el número de tablas y con ello la duración de la consulta.

La mayor parte de las veces, la no­r­ma­li­za­ción aco­s­tu­m­bra a finalizar en la tercera forma normal. Las formas que de­s­cri­bi­mos a co­n­ti­nua­ción guardan relación con esquemas es­pe­cia­les y solo se utilizan en casos ex­ce­p­cio­na­les.

La llamada forma normal de Boyce-Codd es una versión más fuerte que la tercera. Si en esta se afirma que:

• Ningún atributo no-clave puede depender de forma tra­n­si­ti­va de una clave candidata;

En la presente forma normal se ha de cumplir que:

• Ningún atributo puede depender de forma tra­n­si­ti­va de una clave candidata, a no ser que se trate de una de­pe­n­de­n­cia trivial.

La forma normal de Boyce-Codd solo es relevante para las tablas con varias claves ca­n­di­da­tas co­m­pue­s­tas, en las que las claves se su­pe­r­po­nen, es decir, para aquellos casos en los que un atributo es común a dos claves ca­n­di­da­tas (dos claves ca­n­di­da­tas comparten un atributo).

Las bases de datos que están en la 3FN y no tienen claves ca­n­di­da­tas co­m­pue­s­tas se co­n­vie­r­ten au­to­má­ti­ca­me­n­te en re­pre­se­n­ta­n­tes de la FNBC.

La tabla a co­n­ti­nua­ción contiene dos claves ca­n­di­da­tas formadas por dos atributos cada una:

• Número de proveedor y número de artículo
• Proveedor y número de artículo

Las dos claves permiten ide­n­ti­fi­car a cada uno de los registros. El único atributo que no forma parte de ninguna clave es unidades: como no depende de forma tra­n­si­ti­va de ninguna de las ca­n­di­da­tas a clave, se ajusta a la 3FN.

Dada la de­pe­n­de­n­cia entre número de proveedor y proveedor, no se ajusta a la FNBC. El atributo número de proveedor tiene de­pe­n­de­n­cia tra­n­si­ti­va de la clave candidata compuesta por proveedor y número de artículo y el atributo proveedor de la clave candidata compuesta por número de proveedor y número de artículo.

Unidades por proveedor

Las de­pe­n­de­n­cias tra­n­si­ti­vas podrían evitarse si se es­ci­n­die­ra la primera tabla en las tablas Unidades y Proveedor, de forma que no se en­co­n­tra­ra ninguna clave candidata que se su­pe­r­pu­sie­ra a otra.

Unidades

Proveedor

La FNBC impide las re­du­n­da­n­cias que se producen cuando las claves ca­n­di­da­tas han de enumerar varias veces a los mismos atributos de clave ide­n­ti­fi­ca­ti­vos, in­te­r­fi­rié­n­do­se así las unas a las otras. En la tabla de arriba el ajuste a la FNBC impide que se den re­du­n­da­n­cias en la columna Proveedor.

Para que una tabla esté en la cuarta forma normal, ha de estar en la de Boyce-Codd y cumplir, además, con esta condición:

• No hay de­pe­n­de­n­cias mu­l­ti­va­lua­das a no ser que sean triviales.

La de­pe­n­de­n­cia mu­l­ti­va­lua­da (mu­l­ti­va­lued de­pe­n­de­n­cy) o mu­l­ti­va­lor tiene lugar siempre que dos atributos sin relación entre sí, dependan del mismo atributo. Veámoslo con un ejemplo.

La siguiente tabla muestra qué artículos ha pedido cada cliente y dónde se han de entregar:

Lugar de entrega de los pedidos

Puede verse que el cliente con el número 234 ha pedido los artículos 1-0023-D y 2-0023-D, que se han de entregar en su dirección con el código postal 12345. Para el cliente 567, los artículos 1-0023-D, 3-0023-D, 4-0023-D y 5-0023-D se en­tre­ga­rán en el código postal 56789.

Los registros solo pueden ide­n­ti­fi­car­se con una su­pe­r­cla­ve compuesta por los tres atributos (nº cliente, nº artículo y código postal). Al no darse ningún atributo no-clave la tabla está en 3FN. Tampoco presenta de­pe­n­de­n­cias tra­n­si­ti­vas ni triviales, de modo que también cumple con la FNBC. Sin embargo, sí contiene de­pe­n­de­n­cias mu­l­ti­va­lua­das, puesto que el atributo nº de artículo y el atributo código postal dependen de nº de cliente pero no guardan relación entre sí.

El in­co­n­ve­nie­n­te de este diseño es que cada vez que se registre un nuevo artículo para un cliente, también será necesario incluir el código postal, de modo que habrá datos re­du­n­da­n­tes. Si se lleva a esta tabla a la 4FN, estas re­pe­ti­cio­nes pueden reducirse. Para ello, se ha de fra­g­me­n­tar la tabla de tal manera que no presente ninguna de­pe­n­de­n­cia o, al menos, solo de­pe­n­de­n­cias mu­l­ti­va­lua­das triviales. Crearemos , entonces, dos tablas separadas, lo cual es posible porque el número de artículo y el código postal no están re­la­cio­na­dos.

Artículo

Lugar de entrega

Como vemos, la cuarta forma normal elimina las re­du­n­da­n­cias pro­du­ci­das por las de­pe­n­de­n­cias mu­l­ti­va­lua­das, en este caso, en la columna CP.

Una tabla está en la 5FN cuando satisface las co­n­di­cio­nes de la cuarta y cumple, además, esta condición:

• La tabla no puede fra­g­me­n­tar­se más sin que se pierda in­fo­r­ma­ción.

¿Cuándo se da este caso? Para en­te­n­de­r­lo, partimos del supuesto de una empresa que ad­mi­ni­s­tra una página web TYPO3 y una tienda online Magento. Tres empleados son los en­ca­r­ga­dos de ge­s­tio­nar­las: Pérez, García y González, y cada uno de ellos aporta co­no­ci­mie­n­tos de distinta índole.

La tabla de aquí abajo presenta qué cua­li­fi­ca­ción aporta cada tra­ba­ja­dor a cada proyecto de software –de este modo, puede deducirse de forma indirecta qué nivel de co­no­ci­mie­n­to requiere cada proyecto.

Co­no­ci­mie­n­tos por empleado y proyecto

El empleado Pérez aporta al proyecto Magento sus co­no­ci­mie­n­tos en PHP y SQL y para la página web TYPO3 recurre a SQL y a Ja­va­S­cri­pt. García también se encarga de la pro­gra­ma­ción PHP de la tienda online y trabaja con Ja­va­S­cri­pt en la página web. Por último, González solo participa en el proyecto TYPO3, en­ca­r­gá­n­do­se en solitario de la pro­gra­ma­ción PHP. De esto se concluye que para utilizar Magento se requiere ex­pe­rie­n­cia en PHP y SQL, mientras que un proyecto de TYPO3 da por sentado tener co­no­ci­mie­n­tos en PHP, SQL y Ja­va­S­cri­pt.

La tabla solo posee una clave compuesta por todos los atributos, cu­m­plie­n­do así con la 3FN y la FNBC. Al no darse de­pe­n­de­n­cias entre los tres atributos también sería una re­pre­se­n­ta­n­te de la 4FN.

Se tratará ahora de comprobar si también está en la 5FN. Para ello fra­g­me­n­ta­re­mos la tabla original Co­no­ci­mie­n­tos por empleado y proyecto en tres tablas: Pa­r­ti­ci­pa­ción en proyecto, Co­no­ci­mie­n­tos por empleado y Re­que­ri­mie­n­tos por proyecto.

La tabla Pa­r­ti­ci­pa­ción en proyecto muestra los proyectos en los que participa cada tra­ba­ja­dor:

La tabla Co­no­ci­mie­n­tos por empleado reseña los co­no­ci­mie­n­tos en lenguajes de pro­gra­ma­ción o de bases de datos que tiene cada empleado:

Por último, la tabla Re­que­ri­mie­n­tos por proyecto deja entrever qué cua­li­fi­ca­ción técnica requiere trabajar en cada proyecto:

Re­que­ri­mie­n­tos por proyecto

A primera vista, la escisión de la tabla original aporta claridad. Con todo, las tablas que como esta resultan de la no­r­ma­li­za­ción ¿igualan en cantidad de in­fo­r­ma­ción a la tabla original? Para ave­ri­guar­lo debemos llevar a cabo un Join, una consulta a la base de datos que implique a las tres tablas. El resultado es so­r­pre­n­de­n­te:

Re­co­n­s­tru­c­ción de Co­no­ci­mie­n­tos por empleado y proyecto

Al re­co­n­s­truir la tabla original debemos dar por supuesto que cada empleado implicado en el proyecto aporta sus cua­li­fi­ca­cio­nes si el proyecto las requiere. La in­fo­r­ma­ción de que González se ha encargado él solo de programar el proyecto TYPO3 en PHP se ha perdido. Esto quiere decir que la tabla original no puede fra­g­me­n­tar­se sin pérdidas, cu­m­plie­n­do así con la quinta forma normal.

En la práctica, pocas veces se topa con esquemas que cumplan con la 4FN pero no con la 5FN. La quinta forma normal es in­te­re­sa­n­te, no obstante, en aquellos casos en los cuales se obtienen nuevos datos a partir de los di­s­po­ni­bles. Nuestro ejemplo deja ver que tanto Pérez como García tienen co­no­ci­mie­n­tos en PHP que podrían aportar en el futuro a TYPO3, aunque ac­tua­l­me­n­te colaboran con otras aptitudes. Esta in­fo­r­ma­ción podría servir a la empresa para diseñar el de­sa­rro­llo de software en este proyecto de forma más eficiente.

El objetivo de la no­r­ma­li­za­ción es la reducción de los valores du­pli­ca­dos y si se normaliza a una base de datos en alguna de las formas normales descritas, la tabla re­su­l­ta­n­te pre­se­n­ta­rá la ventaja de contar con menos re­du­n­da­n­cia que la original. Así, la no­r­ma­li­za­ción si­m­pli­fi­ca el ma­n­te­ni­mie­n­to de los bancos de datos.

Por otro lado, no­r­ma­li­zar una base de datos implica siempre separar los atributos en tablas in­de­pe­n­die­n­tes. Esto requiere pro­ba­ble­me­n­te integrar claves foráneas y puede conducir a re­du­n­da­n­cias de claves. Pero su mayor in­co­n­ve­nie­n­te es que en una base de datos no­r­ma­li­za­da los datos que forman un todo lógico ya no se guardan juntos. Si se quiere reunir a los datos que figuran en tablas separadas es necesario ejecutar un Join.

Las consultas a las bases de datos con Joins permiten filtrar datos complejos; pero llevarlas a cabo requiere un esfuerzo mayor que una consulta simple, a lo que viene a sumarse la lentitud de la ejecución de la consulta cuando los Joins implican a un gran número de tablas.