Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Índice
1. Qué es la normalización
2. Cómo se normaliza una base de datos
3. Otras formas normales
4. Pros y contras de la normalización
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.
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
Nº cliente
Dirección
Pos.ítem
Artículo
artículo
Cliente
Precio
Fecha
Uds.
Nº
Nº cliente
Dirección
Pos.ítem
Artículo
artículo
Cliente
Precio
Fecha
Uds.
Nº
12 30.01.2018 María 12 C/ Principal 2, 2 Auriculares 3-0023-D 2 75 euros
4 Pérez 12345 Villarriba
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.
Hecho
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.
Datos de facturas
Nº factura
Nº cliente
Pos.ítem
Artículo
Dirección
Cliente
artículoNº
Precio
Fecha
Uds.
123 29.01.2018 José 11 Pl. 1 Monitor 2-0023-D 10 200
García Principal euros
1,
12345
Villarrib
a
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:
Para cumplir con el estado atómico de los datos, los atributos cliente y dirección se han de
subdividir en los atributos más específicos nombre y apellidos, así
como calle, número, código postal y municipio.
Nota
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í:
Nombre
Pos. ítem
Nº factura
Apellido
Nº cliente
Municipio
Nº artículo
Artículo
€)Precio (en
Fecha
Calle
Uds.
CP
Nº
123 29.01.2 Garcí José 11 Pl. 1 12345 Villarri 1 Monitor 2- 10 200
018 a Princi ba 0023-
pal D
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.
Consejo
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.
Apellido
Municipio
Nº artículo
Nº factura
Artículo
Precio
Fecha
Calle
Uds.
CP
Nº
123 11 1 29.01.2 García José Pl. 1 12345 Villarri Monitor 2- 10 200
018 Princip ba 0023-
al D
C/ 1-
1 30.01.201 Marí Principa 1234 0023-
124 2 1 8 Pérez a l 2 5 Villarriba Portátil D 2 1200
Nº artículo
Pos. ítem
Nº factura
Apellido
Nº cliente
Municipio
Artículo
Precio
Fecha
Calle
Uds.
CP
Nº
Nº artículo
Pos. ítem
Nº factura
Apellido
Nº cliente
Municipio
Artículo
Precio
Fecha
Calle
Uds.
CP
Nº
124 2 30.01.2 Pérez María 12 C/ 2 12345 Villarri Auricula 3- 2 75
018 Princi ba res 0023-
pal D
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:
1. 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.
2. 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
Nombre
Municipio
Apellido
Nº cliente
Fecha
Calle
CP
Nº
Nº artículo
Precio en €
Pos. ítem
Artículo
Uds.
123 1 Monitor 2-0023-D 10 200
Nota
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.
Nuestro esquema incumple las condiciones de la tercera forma normal en varios puntos:
Factura
Nº factura
Nombre
Municipio
Apellido
Nº cliente
Fecha
Calle
CP
Nº
Nº artículo
Precio en €
Artículo
Nº ítem
Uds.
123 1 Monitor 2-0023-D 10 200
Factura
123 29.01.2018 11
124 30.01.2018 12
Municipio
Nº cliente
Apellido
Calle
CP
Nº
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
Precio en €
Nº artículo
Artículo
3-0023-D Auriculares 75
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.
Nota
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.
La forma normal de Boyce-Codd solo es relevante para las tablas con varias claves
candidatas compuestas, en las que las claves se superponen, es decir, para aquellos
casos en los que un atributo es común a dos claves candidatas (dos claves candidatas
comparten un atributo).
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:
Las dos claves permiten identificar a cada uno de los registros. El único atributo que no
forma parte de ninguna clave es unidades: como no depende de forma transitiva de
ninguna de las candidatas a clave, se ajusta a la 3FN.
Unidades
proveedor
artículo
Unidades
Nº
Nº
Proveedor
Nº proveedor Proveedor
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.
Nota
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.
La siguiente tabla muestra qué artículos ha pedido cada cliente y dónde se han de
entregar:
Nº cliente Nº artículo CP
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
Nº cliente Nº artículo
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.
Nota
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.
¿Cuándo se da este caso? Para entenderlo, partimos del supuesto de una empresa que
administra una página web TYPO3 y una tienda online Magento. Tres empleados son los
encargados de gestionarlas: Pérez, García y González, y cada uno de ellos aporta
conocimientos de distinta índole.
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.
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.
Proyecto Empleado
Magento Pérez
Magento García
TYPO3 Pérez
TYPO3 García
TYPO3 González
Proyecto Empleado
Empleado Conocimientos
Pérez PHP
Pérez SQL
Pérez JavaScript
García PHP
García JavaScript
González PHP
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:
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.
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.