Normalización: evita las redundancias en las bases de datos
Uno de los términos clave de la modelación relacional de datos es la normalización. En este modelo la calidad del diseño de la base de datos viene determinada por una redundancia reducida al mínimo posible, puesto que los datos repetidos producen anomalías semánticas que dificultan tanto el procesamiento automático de los datos como el mantenimiento mismo de la base de datos. La normalización es la estrategia con la que se eliminan las redundancias en las bases de datos relacionales.
Qué es la normalización
La normalización es un concepto de diseño de bases de datos que se aplica a las bases de datos relacionales para evitar las redundancias.
El modelo relacional es el concepto más extendido en la gestión informatizada de los datos. En las bases de datos de este tipo, la información se guarda en registros en tablas interconectadas por medio de claves. Un registro se compone de varios campos de valores que se subordinan a ciertos atributos a lo largo de las columnas de la tabla.
La siguiente tabla muestra los datos de facturas ficticias, emitidas por una distribuidora 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 ordenadores portátiles y 2 juegos de auriculares.
Datos de facturas
El modelo relacional es el concepto más extendido en la gestión informatizada de los datos. En las bases de datos de este tipo, la información se guarda en registros en tablas interconectadas por medio de claves. Un registro se compone de varios campos de valores que se subordinan a ciertos atributos a lo largo de las columnas de la tabla.
La siguiente tabla muestra los datos de facturas ficticias, emitidas por una distribuidora 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 ordenadores portátiles y 2 juegos de auriculares.
Datos de facturas
Nº factura | Fecha | Cliente | Nº cliente | Dirección | Pos.ítem | Artículo | Nº artículo | Uds. | Precio |
---|---|---|---|---|---|---|---|---|---|
123 | 29.01.2018 | José García | 11 | Pl. Principal 1, 12345 Villarriba | 1 | Monitor | 2-0023-D | 10 | 200 euros |
123 | 29.01.2018 | José García | 11 | Pl. Principal 1, 12345 Villarriba | 2 | Ratón | 4-0023-D | 12 | 50 céntimos |
123 | 29.01.2018 | José García | 11 | Pl. Principal 1, 12345 Villarriba | 3 | Silla oficina | 5-0023-D | 1 | 120 euros |
124 | 30.01.2018 | María Pérez | 12 | C/ Principal 2, 12345 Villarriba | 1 | Portátil | 1-0023-D | 2 | 1200 euros |
124 | 30.01.2018 | María Pérez | 12 | C/ Principal 2, 12345 Villarriba | 2 | Auriculares | 3-0023-D | 2 | 75 euros |
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 corresponde a un registro, denominado tupla.
Esta tabla constituye un ejemplo de tabla mal diseñada, puesto que ya de entrada saltan a la vista sus múltiples redundancias. A esto se añade que las celdas de las columnas Cliente y Dirección contienen datos compuestos por más de un valor (multivalor). Se hablaría en este caso de una base de datos no normalizada, cuyo mayor inconveniente radica en que necesita más memoria como consecuencia de la repetición de valores. Además, los atributos que contienen datos multivalor no se pueden procesar ni relacionar bien. Así, según esta tabla de ejemplo, los dos clientes tienen una dirección de Villarriba, pero como esta informació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 compuestos por varios valores se han desarrollado, en el marco de los modelos relacionales, tres formas normales que se complementan entre sí. Cada forma normal persigue que la base de datos se encuentre en un estado determinado, y para lograrlo, se han de cumplir ciertas condiciones. Una base de datos satisface entonces la primera, la segunda o la tercera forma normal, si se cumplen las condiciones de cada una de ellas.
Esta tabla constituye un ejemplo de tabla mal diseñada, puesto que ya de entrada saltan a la vista sus múltiples redundancias. A esto se añade que las celdas de las columnas Cliente y Dirección contienen datos compuestos por más de un valor (multivalor). Se hablaría en este caso de una base de datos no normalizada, cuyo mayor inconveniente radica en que necesita más memoria como consecuencia de la repetición de valores. Además, los atributos que contienen datos multivalor no se pueden procesar ni relacionar bien. Así, según esta tabla de ejemplo, los dos clientes tienen una dirección de Villarriba, pero como esta informació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 compuestos por varios valores se han desarrollado, en el marco de los modelos relacionales, tres formas normales que se complementan entre sí. Cada forma normal persigue que la base de datos se encuentre en un estado determinado, y para lograrlo, se han de cumplir ciertas condiciones. Una base de datos satisface entonces la primera, la segunda o la tercera forma normal, si se cumplen las condiciones de cada una de ellas.
Se entiende como normalización al proceso de ajuste de una base de datos a una forma normal de un grado más alto. Si se hace a una forma normal de un grado menor toma el nombre de denormalización.
Cómo se normaliza una base de datos
Para aclarar cómo se aplican las tres formas normales a una base de datos relacional, se recorrerán en adelante las diversas fases de la normalización con ejemplos. Partiremos para ello del fragmento mostrado arriba.
Primera forma normal (1FN)
Una tabla en una base de datos relacional está en la primera forma normal cuando se cumplen estas condiciones:
En nuestra tabla los campos correspondientes a los atributos cliente, dirección y precio no son atómicos o no contienen datos del mismo tipo:
Datos de facturas
- Todos los datos son atómicos.
- Todas las columnas contienen el mismo tipo de datos.
En nuestra tabla los campos correspondientes a los atributos cliente, dirección y precio no son atómicos o no contienen datos del mismo tipo:
Datos de facturas
Nº factura | Fecha | Cliente | Nº cliente | Dirección | Pos.ítem | Artículo | Nº artículo | Uds. | Precio |
---|---|---|---|---|---|---|---|---|---|
123 | 29.01.2018 | José García | 11 | Pl. Principal 1, 12345 Villarriba | 1 | Monitor | 2-0023-D | 10 | 200 euros |
123 | 29.01.2018 | José García | 11 | Pl. Principal 1, 12345 Villarriba | 2 | Ratón | 4-0023-D | 12 | 50 céntimos |
123 | 29.01.2018 | José García | 11 | Pl. Principal 1, 12345 Villarriba | 3 | Silla oficina | 5-0023-D | 1 | 120 euros |
124 | 30.01.2018 | María Pérez | 12 | C/ Principal 2, 12345 Villarriba | 1 | Portátil | 1-0023-D | 2 | 1200 euros |
124 | 30.01.2018 | María Pérez | 12 | C/ Principal 2, 12345 Villarriba | 2 | Auriculares | 3-0023-D | 2 | 75 euros |
Las celdas en negrita muestran que nuestra tabla incumple ambas condiciones y por lo tanto no está en la primera forma normal. Para normalizarla se hace lo siguiente:
- Subdividir todos los datos multivalor en columnas separadas.
- Comprobar que los valores en cada columna son del mismo tipo.
En general, depende del contexto cuándo se considera que un valor es atómico. Si no es necesario separar el nombre de los apellidos, el nombre completo puede considerarse un valor atómico. Con todo, en la práctica se recomienda subdividir los valores compuestos en las unidades más pequeñas.
En la columna Precio hay datos en euros y en céntimos: hay que decidirse por un tipo de dato (en €) para generar campos coherentes. Quedaría así:
Nº factura | Fecha | Apellido | Nombre | Nº cliente | Calle | Nº | CP | Municipio | Pos. ítem | Artículo | Nº artículo | Uds. | Precio (en €) |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
123 | 29.01.2018 | García | José | 11 | Pl. Principal | 1 | 12345 | Villarriba | 1 | Monitor | 2-0023-D | 10 | 200 |
123 | 29.01.2018 | García | José | 11 | Pl. Principal | 1 | 12345 | Villarriba | 2 | Ratón | 4-0023-D | 12 | 0,50 |
123 | 29.01.2018 | García | José | 11 | Pl. Principal | 1 | 12345 | Villarriba | 3 | Silla oficina | 5-0023-D | 1 | 120 |
124 | 30.01.2018 | Pérez | María | 12 | C/ Principal | 2 | 12345 | Villarriba | 1 | Portátil | 1-0023-D | 2 | 1200 |
124 | 30.01.2018 | Pérez | María | 12 | C/ Principal | 2 | 12345 | Villarriba | 2 | Auriculares | 3-0023-D | 2 | 75 |
El resultado es una tabla que, si bien está en la primera forma normal, los valores duplicados siguen impidiendo procesar los datos de forma eficiente. Para reducir las redundancias se recomienda llevarla a la segunda forma normal.
La primera forma normal establece campos de valores atómicos y con ello facilita las consultas a la base de datos. Los datos que forman parte de campos no atómicos no pueden consultarse por separado.
Segunda forma normal (2FN)
Para estar en la segunda forma normal, a las condiciones de la primera se añade la siguiente:
En nuestro ejemplo, los atributos número de factura, número de cliente y posición de ítem podrían componer una posible superclave:
- Los atributos que no forman parte de ninguna clave han de depender funcionalmente de toda la clave primaria.
En nuestro ejemplo, los atributos número de factura, número de cliente y posición de ítem podrían componer una posible superclave:
Nº factura | Nº cliente | Pos. ítem | Fecha | Apellido | Nombre | Calle | Nº | CP | Municipio | Artículo | Nº artículo | Uds. | Precio |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
123 | 11 | 1 | 29.01.2018 | García | José | Pl. Principal | 1 | 12345 | Villarriba | Monitor | 2-0023-D | 10 | 200 |
123 | 11 | 2 | 29.01.2018 | García | José | Pl. Principal | 1 | 12345 | Villarriba | Ratón | 4-0023-D | 12 | 0,50 |
123 | 11 | 3 | 29.01.2018 | García | José | Pl. Principal | 1 | 12345 | Villarriba | Silla oficina | 5-0023-D | 1 | 120 |
124 | 12 | 1 | 30.01.2018 | Pérez | María | C/ Principal | 2 | 12345 | Villarriba | Portátil | 1-0023-D | 2 | 1200 |
124 | 12 | 2 | 30.01.2018 | Pérez | María | C/ Principal | 2 | 12345 | Villarriba | Auriculares | 3-0023-D | 2 | 75 |
Una clave número de factura, número de cliente y posición de ítem con los valores {124, 12, 1} permitiría entonces identificar claramente al registro de la compra que ha hecho María Pérez:
124 | 12 | 1 | 30.01.2018 | Pérez | María | C/ Principal | 2 | 12345 | Villarriba | Portátil | 1-0023-D | 2 | 1200 |
---|
Pero para esta identificación no es necesaria toda la información aportada por la superclave. Una combinación de número de factura y posición de ítem (es decir, un subconjunto de la superclave) debería bastar para identificar a cada registro. Estas claves con la mínima cantidad de atributos se conocen como claves candidatas.
Nº factura | Pos. ítem | Fecha | Apellido | Nombre | Nº cliente | Calle | Nº | CP | Municipio | Artículo | Nº artículo | Uds. | Precio |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
123 | 1 | 29.01.2018 | García | José | 11 | Pl. Principal | 1 | 12345 | Villarriba | Monitor | 2-0023-D | 10 | 200 |
123 | 2 | 29.01.2018 | García | José | 11 | Pl. Principal | 1 | 12345 | Villarriba | Ratón | 4-0023-D | 12 | 0,50 |
123 | 3 | 29.01.2018 | García | José | 11 | Pl. Principal | 1 | 12345 | Villarriba | Silla oficina | 5-0023-D | 1 | 120 |
124 | 1 | 30.01.2018 | Pérez | María | 12 | C/ Principal | 2 | 12345 | Villarriba | Portátil | 1-0023-D | 2 | 1200 |
124 | 2 | 30.01.2018 | Pérez | María | 12 | C/ Principal | 2 | 12345 | Villarriba | Auriculares | 3-0023-D | 2 | 75 |
Normalmente, se escoge a una clave candidata por tabla para representarla. Su valor ideal es una numeración correlativa. 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 componerse 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 relacionan entre sí. Para hacerlo se siguen estos pasos:
Para que una tabla esté en la 2FN enviamos a los atributos dependientes del número de factura a una tabla separada llamada Factura:
Factura
Como cualquier candidata a clave, la clave primaria también puede componerse 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 relacionan entre sí. Para hacerlo se siguen estos pasos:
- Comprueba que todos los atributos no-clave dependen por completo de la clave primaria. Esta dependencia se da si todos los atributos de la clave primaria son necesarios para identificar a los atributos no-clave. Esto quiere decir también que las tablas con claves primarias simples se ajustan automáticamente a la 2FN si se cumplen las condiciones para la 1FN.
- Relega a los atributos no-clave que no dependen de la clave primaria a tablas diferentes.
Para que una tabla esté en la 2FN enviamos a los atributos dependientes del número de factura a una tabla separada llamada Factura:
Factura
Nº factura | Fecha | Apellido | Nombre | Nº cliente | Calle | Nº | CP | Municipio |
---|---|---|---|---|---|---|---|---|
123 | 29.01.2018 | García | José | 11 | Pl. Principal | 1 | 12345 | Villarriba |
124 | 30.01.2018 | Pérez | María | 12 | C/ Principal | 2 | 12345 | Villarriba |
A la tabla con el resto de datos la llamamos Posición del ítem:
Posición del ítem
Posición del ítem
Nº factura | Pos. ítem | Artículo | Nº artículo | Uds. | Precio en € |
---|---|---|---|---|---|
123 | 1 | Monitor | 2-0023-D | 10 | 200 |
123 | 2 | Ratón | 4-0023-D | 12 | 0,50 |
123 | 3 | Silla oficina | 5-0023-D | 1 | 120 |
124 | 1 | Portátil | 1-0023-D | 2 | 1200 |
124 | 2 | Auriculares | 3-0023-D | 2 | 75 |
Tras la normalización, el número de factura se encuentra en ambas tablas, conectándolas. 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.
La conexión por clave foránea o ajena (Foreign Key) permite consultar a dos tablas a la vez. Se habla entonces de un Join.
Nuestras tablas están ahora en la segunda forma normal, pero aún no se han eliminado del todo las redundancias. Por eso‚ la meta de la normalización suele ser la tercera forma normal.
Tercera forma normal (3FN)
Para que una tabla esté en la tercera forma normal ha de cumplir las condiciones de las dos primeras y además:
Nuestro esquema incumple las condiciones de la tercera forma normal en varios puntos:
Factura
- Los atributos no-clave no pueden depender de forma transitiva de una clave candidata.
Nuestro esquema incumple las condiciones de la tercera forma normal en varios puntos:
Factura
Nº factura | Fecha | Nombre | Apellido | Nº cliente | Calle | Nº | CP | Municipio |
---|---|---|---|---|---|---|---|---|
123 | 29.01.2018 | García | José | 11 | Pl. Principal | 1 | 12345 | Villarriba |
124 | 30.01.2018 | Pérez | María | 12 | C/ Principal | 2 | 12345 | Villarriba |
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 específica de la tercera forma normal:
Posición del ítem
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 específica de la tercera forma normal:
Posición del ítem
Nº factura | Nº ítem | Artículo | Nº artículo | Uds. | Precio en € |
---|---|---|---|---|---|
123 | 1 | Monitor | 2-0023-D | 10 | 200 |
123 | 2 | Ratón | 4-0023-D | 12 | 0,50 |
123 | 3 | Silla oficina | 5-0023-D | 1 | 120 |
124 | 1 | Portátil | 1-0023-D | 2 | 1200 |
124 | 2 | Auriculares | 3-0023-D | 2 | 75 |
Para eliminar las dependencias entre atributos no-clave repartimos los datos en tablas separadas que se interconectan con claves ajenas. De este modo, resultarán las cuatro tablas normalizadas Factura, Cliente, Posición y Artículo.
La clave primaria de la tabla Factura es un número de factura correlativo. Cada número de factura se clasifica con la fecha de la factura y el número de cliente:
Factura
La clave primaria de la tabla Factura es un número de factura correlativo. Cada número de factura se clasifica con la fecha de la factura y el número de cliente:
Factura
Nº factura | Fecha | Nº cliente |
---|---|---|
123 | 29.01.2018 | 11 |
124 | 30.01.2018 | 12 |
En la tabla Cliente se depositan datos más aproximados 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:
Nº cliente | Apellido | Nombre | Calle | Nº | CP | Municipio |
---|---|---|---|---|---|---|
11 | García | José | Pl. Principal | 1 | 12345 | Villarriba |
12 | Pérez | María | C/ Principal | 2 | 12345 | Villarriba |
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 correlativa 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.
Nº factura | Posición | Nº artículo | Uds. |
---|---|---|---|
123 | 1 | 2-0023-D | 10 |
123 | 2 | 4-0023-D | 12 |
123 | 3 | 5-0023-D | 1 |
124 | 1 | 1-0023-D | 2 |
124 | 2 | 3-0023-D | 2 |
La tabla Artículo solo contiene los detalles sobre cada artículo, como su denominación o el precio. Como clave primaria tenemos el número de artículo correlativo:
Nº artículo | Artículo | Precio en € |
---|---|---|
1-0023-D | Portátil | 1200 |
2-0023-D | Monitor | 200 |
3-0023-D | Auriculares | 75 |
4-0023-D | Ratón | 0,50 |
5-0023-D | Silla oficina | 120 |
En nuestro ejemplo puede parecer poco eficiente fragmentar dos tablas en cuatro. De hecho, las redundancias en los datos de solo dos clientes no saltan apenas a la vista. Imaginemos, sin embargo, que queremos procesar varios cientos de miles de registros sobre clientes o sobre la gama de productos de la empresa de forma consistente y libre de contradicciones. Esto solo suele ser posible con un esquema que se ajuste a la tercera forma normal.
Ten en cuenta que no siempre es posible evitar por completo los valores duplicados en las bases de datos relacionales. Volviendo a nuestra base de datos, se puede observar que la conexión de tablas con claves ajenas puede estar ligado a redundancias. Se habla en este caso de redundancia de claves.
Aun cuando la normalización de bases de datos implica un mayor esfuerzo de programación, la tercera forma normal está considerada como el estándar para los esquemas relacionales y solo se descarta bajo contadas excepciones. Una de ellas sería la denormalizacion 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. Denormalizando la base de datos se espera reducir el número de tablas y con ello la duración de la consulta.
Otras formas normales
La mayor parte de las veces, la normalización acostumbra a finalizar en la tercera forma normal. Las formas que describimos a continuación guardan relación con esquemas especiales y solo se utilizan en casos excepcionales.
Forma normal de Boyce-Codd (FNBC)
La llamada forma normal de Boyce-Codd es una versión más fuerte que la tercera. Si en esta se afirma que:
Las bases de datos que están en la 3FN y no tienen claves candidatas compuestas se convierten automáticamente en representantes de la FNBC.
La tabla a continuación contiene dos claves candidatas formadas por dos atributos cada una:
Dada la dependencia entre número de proveedor y proveedor, no se ajusta a la FNBC. El atributo número de proveedor tiene dependencia transitiva 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
- Ningún atributo no-clave puede depender de forma transitiva de una clave candidata;
- Ningún atributo puede depender de forma transitiva de una clave candidata, a no ser que se trate de una dependencia trivial.
Las bases de datos que están en la 3FN y no tienen claves candidatas compuestas se convierten automáticamente en representantes de la FNBC.
La tabla a continuación contiene dos claves candidatas formadas por dos atributos cada una:
- Número de proveedor y número de artículo
- Proveedor y número de artículo
Dada la dependencia entre número de proveedor y proveedor, no se ajusta a la FNBC. El atributo número de proveedor tiene dependencia transitiva 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
Nº proveedor | Proveedor | Nº artículo | Unidades |
---|---|---|---|
Z-012 | Ejemplo AG & Co. KG | 1-0023-D | 900 |
Z-012 | Ejemplo AG & Co. KG | 2-0023-D | 250 |
Z-012 | Ejemplo AG & Co. KG | 3-0023-D | 395 |
Z-077 | Ejemplo1 GmbH | 4-0023-D | 1275 |
Z-077 | Ejemplo1 GmbH | 5-0023-D | 12000 |
Las dependencias transitivas podrían evitarse si se escindiera la primera tabla en las tablas Unidades y Proveedor, de forma que no se encontrara ninguna clave candidata que se superpusiera a otra.
Unidades
Unidades
Nº proveedor | Nº artículo | Unidades |
---|---|---|
Z-012 | 1-0023-D | 900 |
Z-012 | 2-0023-D | 250 |
Z-012 | 3-0023-D | 395 |
Z-077 | 4-0023-D | 1275 |
Z-077 | 5-0023-D | 12000 |
Proveedor
Nº proveedor | Proveedor |
---|---|
Z-012 | Ejemplo AG & Co. KG |
Z-077 | Ejemplo1 GmbH |
La FNBC impide las redundancias que se producen cuando las claves candidatas han de enumerar varias veces a los mismos atributos de clave identificativos, interfiriéndose así las unas a las otras. En la tabla de arriba el ajuste a la FNBC impide que se den redundancias en la columna Proveedor.
Se habla de dependencia trivial cuando un atributo es dependiente funcional de sí mismo. Dado que esto siempre es así, sea cual sea el estado de la base de datos, en Lógica las dependencias triviales equivalen a una tautología.
Cuarta forma normal (4FN)
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:
La siguiente tabla muestra qué artículos ha pedido cada cliente y dónde se han de entregar:
Lugar de entrega de los pedidos
- No hay dependencias multivaluadas a no ser que sean triviales.
La siguiente tabla muestra qué artículos ha pedido cada cliente y dónde se han de entregar:
Lugar de entrega de los pedidos
Nº cliente | Nº artículo | CP |
---|---|---|
234 | 1-0023-D | 12345 |
234 | 2-0023-D | 12345 |
567 | 1-0023-D | 56789 |
567 | 3-0023-D | 56789 |
567 | 4-0023-D | 56789 |
567 | 5-0023-D | 56789 |
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 entregarán en el código postal 56789.
Los registros solo pueden identificarse con una superclave 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 dependencias transitivas ni triviales, de modo que también cumple con la FNBC. Sin embargo, sí contiene dependencias multivaluadas, 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 inconveniente 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 redundantes. Si se lleva a esta tabla a la 4FN, estas repeticiones pueden reducirse. Para ello, se ha de fragmentar la tabla de tal manera que no presente ninguna dependencia o, al menos, solo dependencias multivaluadas 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 relacionados.
Artículo
Los registros solo pueden identificarse con una superclave 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 dependencias transitivas ni triviales, de modo que también cumple con la FNBC. Sin embargo, sí contiene dependencias multivaluadas, 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 inconveniente 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 redundantes. Si se lleva a esta tabla a la 4FN, estas repeticiones pueden reducirse. Para ello, se ha de fragmentar la tabla de tal manera que no presente ninguna dependencia o, al menos, solo dependencias multivaluadas 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 relacionados.
Artículo
Nº cliente | Nº artículo |
---|---|
234 | 1-0023-D |
234 | 2-0023-D |
567 | 1-0023-D |
567 | 4-0023-D |
567 | 5-0023-D |
Lugar de entrega
Nº cliente | CP |
---|---|
234 | 12345 |
567 | 56789 |
Como vemos, la cuarta forma normal elimina las redundancias producidas por las dependencias multivaluadas, en este caso, en la columna CP.
En nuestro forzado ejemplo, presuponemos un solo código postal por cliente, pero si cada cliente pudiera ordenar la entrega de sus compras a sitios diferentes, se daría una dependencia entre el número de artículo y el código postal y la tabla estaría ya en la 4FN aun sin normalizar.
Quinta forma normal (5FN)
Una tabla está en la 5FN cuando satisface las condiciones de la cuarta y cumple, además, esta condición:
La tabla de aquí abajo presenta qué cualificación aporta cada trabajador a cada proyecto de software –de este modo, puede deducirse de forma indirecta qué nivel de conocimiento requiere cada proyecto.
Conocimientos por empleado y proyecto
- La tabla no puede fragmentarse más sin que se pierda información.
La tabla de aquí abajo presenta qué cualificación aporta cada trabajador a cada proyecto de software –de este modo, puede deducirse de forma indirecta qué nivel de conocimiento requiere cada proyecto.
Conocimientos por empleado y proyecto
Empleado | Proyecto | Conocimientos |
---|---|---|
Pérez | Magento | PHP |
Pérez | Magento | SQL |
Pérez | TYPO3 | JavaScript |
Pérez | TYPO3 | SQL |
García | Magento | PHP |
García | TYPO3 | JavaScript |
González | TYPO3 | PHP |
El empleado Pérez aporta al proyecto Magento sus conocimientos en PHP y SQL y para la página web TYPO3 recurre a SQL y a JavaScript. García también se encarga de la programación PHP de la tienda online y trabaja con JavaScript en la página web. Por último, González solo participa en el proyecto TYPO3, encargándose en solitario de la programación PHP. De esto se concluye que para utilizar Magento se requiere experiencia en PHP y SQL, mientras que un proyecto de TYPO3 da por sentado tener conocimientos en PHP, SQL y JavaScript.
La tabla solo posee una clave compuesta por todos los atributos, cumpliendo así con la 3FN y la FNBC. Al no darse dependencias entre los tres atributos también sería una representante de la 4FN.
Se tratará ahora de comprobar si también está en la 5FN. Para ello fragmentaremos la tabla original Conocimientos por empleado y proyecto en tres tablas: Participación en proyecto, Conocimientos por empleado y Requerimientos por proyecto.
La tabla Participación en proyecto muestra los proyectos en los que participa cada trabajador:
La tabla solo posee una clave compuesta por todos los atributos, cumpliendo así con la 3FN y la FNBC. Al no darse dependencias entre los tres atributos también sería una representante de la 4FN.
Se tratará ahora de comprobar si también está en la 5FN. Para ello fragmentaremos la tabla original Conocimientos por empleado y proyecto en tres tablas: Participación en proyecto, Conocimientos por empleado y Requerimientos por proyecto.
La tabla Participación en proyecto muestra los proyectos en los que participa cada trabajador:
Proyecto | Empleado |
---|---|
Magento | Pérez |
Magento | García |
TYPO3 | Pérez |
TYPO3 | García |
TYPO3 | González |
La tabla Conocimientos por empleado reseña los conocimientos en lenguajes de programación o de bases de datos que tiene cada empleado:
Empleado | Conocimientos |
---|---|
Pérez | PHP |
Pérez | SQL |
Pérez | JavaScript |
García | PHP |
García | JavaScript |
González | PHP |
Por último, la tabla Requerimientos por proyecto deja entrever qué cualificación técnica requiere trabajar en cada proyecto:
Requerimientos por proyecto
Requerimientos por proyecto
Proyecto | Cualificación |
---|---|
Magento | PHP |
Magento | SQL |
TYPO3 | JavaScript |
TYPO3 | SQL |
TYPO3 | PHP |
A primera vista, la escisión de la tabla original aporta claridad. Con todo, las tablas que como esta resultan de la normalización ¿igualan en cantidad de información a la tabla original? Para averiguarlo debemos llevar a cabo un Join, una consulta a la base de datos que implique a las tres tablas. El resultado es sorprendente:
Reconstrucción de Conocimientos por empleado y proyecto
Reconstrucción de Conocimientos por empleado y proyecto
Empleado | Proyecto | Conocimientos |
---|---|---|
Pérez | Magento | PHP |
Pérez | Magento | SQL |
Pérez | TYPO3 | JavaScript |
Pérez | TYPO3 | SQL |
Pérez | TYPO3 | PHP |
García | Magento | PHP |
García | TYPO3 | JavaScript |
García | TYPO3 | PHP |
González | TYPO3 | PHP |
Al reconstruir la tabla original debemos dar por supuesto que cada empleado implicado en el proyecto aporta sus cualificaciones si el proyecto las requiere. La informació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 fragmentarse sin pérdidas, cumpliendo 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 interesante, no obstante, en aquellos casos en los cuales se obtienen nuevos datos a partir de los disponibles. Nuestro ejemplo deja ver que tanto Pérez como García tienen conocimientos en PHP que podrían aportar en el futuro a TYPO3, aunque actualmente colaboran con otras aptitudes. Esta información podría servir a la empresa para diseñar el desarrollo de software en este proyecto de forma más eficiente.
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 interesante, no obstante, en aquellos casos en los cuales se obtienen nuevos datos a partir de los disponibles. Nuestro ejemplo deja ver que tanto Pérez como García tienen conocimientos en PHP que podrían aportar en el futuro a TYPO3, aunque actualmente colaboran con otras aptitudes. Esta información podría servir a la empresa para diseñar el desarrollo de software en este proyecto de forma más eficiente.
Pros y contras de la normalización
El objetivo de la normalización es la reducción de los valores duplicados y si se normaliza a una base de datos en alguna de las formas normales descritas, la tabla resultante presentará la ventaja de contar con menos redundancia que la original. Así, la normalización simplifica el mantenimiento de los bancos de datos.
Por otro lado, normalizar una base de datos implica siempre separar los atributos en tablas independientes. Esto requiere probablemente integrar claves foráneas y puede conducir a redundancias de claves. Pero su mayor inconveniente es que en una base de datos normalizada 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.
Por otro lado, normalizar una base de datos implica siempre separar los atributos en tablas independientes. Esto requiere probablemente integrar claves foráneas y puede conducir a redundancias de claves. Pero su mayor inconveniente es que en una base de datos normalizada 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.