Por qu y para qu normalizar?

A la hora de disear una base de datos podemos basarnos en dos enfoques principalmente: realizar un modelo entidad/relacin que posteriormente transformaremos a un esquema entidad/relacin o, escribiendo directamente un Esquema Relacional con lo que pensamos que es necesario. Normalmente, el primer enfoque nos lleva a un Esquema Relacional estructurado y con poca redundancia al que aplicar la Teora de la Normalizacin es un mejor ajuste. El segundo enfoque hace necesaria la utilizacin de la Teora de la Normalizacin por la facilidad de caer en una falta de estructuracin y redundancia. Los problemas que se suelen presentar al tener un Esquema Relacional mal diseado son los siguientes:

Incapacidad para almacenar ciertos hechos Redundancias y posibilidad de inconsistencias Ambigedades Prdida de informacin Prdida de Restricciones de Integridad Anomalas de insercin, borrado y modificacin

La Teora de la Normalizacin nos permite identificar todos estos problemas y convertir esas relaciones a una forma ms deseable.

Proceso de normalizacin
La Teora de la Normalizacin es una expresin formal de ideas sencillas con una aplicacin muy prctica que conducen a una correcta eleccin del esquema de la base de datos. Una relacin estar en determinada Forma Normal si satisface un cierto conjunto de restricciones. El Procedimiento de Normalizar nos permitir que si tenemos una relacin en 2FN, se podr convertir en una forma ms deseable (3FN), y as de forma sucesiva. Hay que sealar que al aplicar un Proceso de Normalizacin a una base de datos por lo general se aumenta el nmero de relaciones de la misma. Esto puede hacer que disminuya la eficacia de las consultas, pero ganaremos en itegridad y en poder modificar el Esquema Relacionar si los requerimientos cambian.

Teora de la normalizacin. En el desarrollo del diseo lgico obtenemos una serie de tablas finales que son

las candidatas a formar nuestra base de datos. Sin embargo, dichas tablas han sido obtenidas a partir de un diseo conceptual elaborado sin ningn tipo de reglas, por lo que podemos obtener un diseo de tablas ms o menos heterogneo. La teora de la normalizacin consiste en un conjunto de reglas formales que nos permiten asegurar que un diseo lgico cumple una serie de propiedades, corrigiendo la estructura de los datos de las tablas y evitando una serie de problemas como: Incapacidad de almacenar ciertos hechos. Redundancias y, por tanto, posibilidad de inconsistencias. Ambigedades. Prdida de informacin. Aparicin en la base de datos de estados no vlidos en el mundo real, es lo que se llama anomalas de insercin, borrado y modificacin. Las reglas formales de la teora de la normalizacin son conocidas con el nombre de formas normales. Existen seis formas normales, de forma que cuando la base de datos cumple las reglas de la primera forma normal se considera que est en primera forma normal (1FN), cuando pasan la segunda, que est en segunda forma normal (2FN), etc. Adems, una base de datos de la que se afirme que est en 2FN, est tambin en 1FN, pues las formas normales se aplican de forma sucesiva. De las seis formas normales, generalmente solo se aplican sobre las bases de datos las tres primeras, considerando que una base de datos que est en 3FN es una base de datos correctamente diseada. Por ello, expondremos a continuacin ests tres primeras formas normales. Para desarrollar la teora de normalizacin de una base de datos tomaremos como ejemplo el diseo de la gestin de una empresa considerando solo la parte de facturacin a los clientes. 6.4.1 Primera forma normal (1FN). Una base de datos se considera que est en 1FN si cada atributo (campo) de una tabla contiene un solo valor atmico (simple). Un atributo que contiene varios valores puede derivar en una perdida de datos. Tomando el ejemplo propuesto, hemos realizado un anlisis y hemos obtenido que para identificar la factura hemos creado como clave primaria el cdigo de la factura y hemos establecido adems la necesidad de que una factura posea los siguientes campos:
Ciencias y Tcnicas Estadsticas 5

Adquisicin y tratamiento de datos Diseo de bases de datos relacionales

FACTURA Codigo_factura Codigo_cliente Nombre_cliente Direccion_cliente Poblacion_cliente Fecha_factura Forma_pago Codigo_articulo_1 Descripcion_1 Cantidad_1 Importe_1 Tipo_IVA_1 Codigo_articulo_N Descripcion_N Cantidad_N Importe_N Tipo_IVA_N

Figura 6.4.1.1: Diseo inicial de las facturas. Analizando el diseo inicial de la tabla FACTURA, observamos la existencia de mltiples valores para los atributos (campos) siguientes: Codigo_articulo, descripcion, cantidad, importe e IVA. Analizando la tabla, observamos que no cumple la condicin de 1FN. La solucin consiste en crear una nueva tabla, que podemos llamar DETALLE_FACTURA a la cual se trasladan los datos repetitivos, en nuestro caso los datos referentes a los artculos (codigo_articulo, descripcin, cantidad, importe e IVA).
FACTURA Codigo_factura Codigo_cliente Nombre_cliente Direccion_cliente Poblacion_cliente Fecha_factura Forma_pago DETALLE_FACTURA Codigo_factura Codigo_articulo Descripcion Cantidad Importe Tipo_IVA

Figura 6.4.1.2: Diseo de las facturas aplicando la 1FN. Cuando se produce la separacin de datos de la tabla original en una nueva tabla, sta adems de los atributos necesarios, traslada la clave primaria de la tabla original como parte de su nueva clave primaria, que estar formada, generalmente, por dos atributos. 6.4.2 Segunda forma normal (2FN). La segunda forma normal, como la tercera que veremos a continuacin, se relaciona con el concepto de dependencia funcional.

Entendemos como dependencia funcional a la relacin que tienen los atributos (campos) de una tabla con otros atributos de la propia tabla. Un campo tiene dependencia funcional si necesita informacin de otro/s campo/s para poder contener un valor. Una tabla se dice que esta en segunda forma normal (2FN) si sucede que: Est en 1FN
Ciencias y Tcnicas Estadsticas 6 Adquisicin y tratamiento de datos Diseo de bases de datos relacionales

Cada atributo (campo) no clave depende de la clave completa, no de parte de ella. Por supuesto, una base de datos estar en 2FN si todas sus tablas lo estn. La idea intuitiva de la 2FN es identificar todas las tablas con una clave compuesta, pues todas las tablas con clave simple estn por defecto en 2FN si estn en 1FN, y comprobar que cada uno de los campos de esta tabla depende de la clave completa. En nuestro ejemplo, la tabla FACTURA se encuentra en 2FN pues est en 1FN y su clave es simple. Sin embargo la tabla DETALLE_FACTURA ha de ser analizada pues su clave es compuesta (esta formada por dos atributos). Analizando la tabla DETALLE_FACTURA, observamos que el atributo descripcion depende nicamente del atributo codigo_articulo (la descripcin de un articulo depende nicamente de que articulo se trate y es completamente independiente de la factura), por lo cual la descripcion ha de ser llevada a una nueva tabla junto con el atributo clave codigo_articulo. Supongamos adems, que el cliente nos indica que en la factura, aunque cada articulo posee calculado su IVA, el tipo de IVA que aplica es comn a toda la factura y no depende en cada factura de los artculos, por lo cual, vemos que el atributo Tipo_IVA solo depende funcionalmente del codigo_factura y no depende de codigo_articulo, por lo cual ha de ser devuelta a la tabla FACTURA como un nico atributo Tipo_IVA que depende solo de la clave de FACTURA (codigo_factura).
FACTURA Codigo_factura Codigo_cliente Nombre_cliente Direccion_cliente Poblacion_cliente Fecha_factura Forma_pago Tipo_IVA

DETALLE_FACTURA Codigo_factura Codigo_articulo Cantidad Importe

Figura 6.4.2.1: Diseo de las facturas aplicando la 2FN. 6.4.3 Tercera forma normal (3FN). Una tabla se dice que est en tercera forma normal (3FN) si: Est en 2FN.
ARTICULO Codigo_articulo Descripcion

Todos los atributos que no son claves deben ser mutuamente independientes, es decir, un atributo no debe depender de otro atributo no clave de su tabla. Si un atributo que no es clave depende de otro atributo que no es clave, la tabla posiblemente contiene datos acerca de mas de una entidad, contradiciendo el principio de que cada tabla almacene informacin de una entidad.
Ciencias y Tcnicas Estadsticas 7 Adquisicin y tratamiento de datos Diseo de bases de datos relacionales

En nuestro ejemplo, podemos observar que las tablas ARTICULO y DETALLE_FACTURA se encuentran en 3FN. Sin embargo, la tabla FACTURA no est en 3FN, pues los atributos Nombre_cliente, Direccion_cliente y Poblacion_cliente dependen funcionalmente del atributo Codigo_cliente, campo que no es clave. Por ello, debemos extraer estos atributos de la tabla FACTURA e incluirlos en una nueva tabla que haga referencia al cliente, tabla que llamaremos CLIENTE y que contendr como clave primaria el Codigo_cliente y como atributos el Nombre_cliente, Direccion_cliente y Poblacion_cliente. Aplicando esto, nuestro diseo de las facturas da lugar a las tablas que pueden verse en la siguiente figura.
FACTURA Codigo_factura Codigo_cliente Fecha_factura Forma_pago Tipo_IVA DETALLE_FACTURA Codigo_factura Codigo_articulo Cantidad Importe CLIENTE Codigo_cliente Nombre_cliente Direccion_cliente

Poblacion_cliente ARTICULO Codigo_articulo Descripcion

Figura 6.4.3.1: Diseo de las facturas aplicando la 3FN. 6.4.4 Consideraciones finales y problemas de la normalizacin. La teora de la normalizacin nos ayuda a estructurar mejor las tablas de la base de datos, evitando posibles redundancias. Por otra parte, si seguimos la metodologa de diseo expuesta en los puntos 6.2 y 6.3 del tema, obteniendo un diseo conceptual que despus es convertido en diseo lgico, este diseo lgico resultante estar en 3FN siempre que todo el proceso se haya realizado de forma correcta, sirviendo en este caso la teora de la normalizacin para comprobar que el diseo ha sido realizado correctamente. Si no lo fuese, podremos aplicar las formas normales para corregir los errores que hubieran podido producirse. Mientras la normalizacin resuelve los problemas relacionados con la estructuracin de los datos en tablas, crea problemas aadidos a su propio concepto, como son la duplicacin de datos y la ineficacia en la recuperacin de informacin. As, el proceso de normalizacin envuelve la descomposicin de una tabla en tablas ms pequeas, lo cual requiere que la clave primaria de la tabla original se incluya, como una clave fornea, en la tabla/s que se forman. Esto significa que a medida que se van creando estas claves forneas se va incrementando las probabilidades de poner en peligro la integridad de la base de datos. Otro efecto adicional del nmero creciente de tablas en la base de datos, es que se ve disminuido el rendimiento del sistema en la recuperacin de la informacin contenida. Esta disminucin del rendimiento puede ser particularmente importante en
Ciencias y Tcnicas Estadsticas 8 Adquisicin y tratamiento de datos Diseo de bases de datos relacionales

sistemas basados en microordenadores. Por tanto, en ciertas ocasiones es necesario llegar a un compromiso entre el nivel de normalizacin de la base de datos y el rendimiento del sistema. 6.5 Ejercicios de diseo de bases de datos. 6.5.1 Ejercicio. Una empresa pretende desarrollar una base de datos de empleados y proyectos. La empresa esta estructurada en departamentos, cada uno de los cuales posee uno o

varios proyectos, de forma que un proyecto solo depende de un departamento. Por otro lado cada departamento consta de uno o varios empleados, que trabajan de forma exclusiva para ese departamento, pero pueden trabajar simultneamente en varios proyectos. Cada empleado tiene un jefe encargado de supervisar su trabajo, pudiendo cada jefe supervisar el trabajo de varios empleados. Dada la descripcin anterior, desarrollar la base de datos normalizada hasta 3FN. 6.5.2 Ejercicio. Dada el siguiente diseo de una tabla de una base de datos, aplicar las tres primeras formas normales y llevar el diseo a 3FN.
ENVIO Codigo_envio Matricula_camion Modelo_camion Capacidad_camion Cliente_1 Direccion_cliente_1 Pedido_cliente_1 Articulo_1_pedido_cliente_1 Volumen_articulo_1_pedido_cliente_1 Articulo_I_pedido_cliente_1 Volumen_articulo_I_pedido_cliente_1 Cliente_N Direccion_cliente_N Pedido_cliente_N Articulo_1_pedido_cliente_N Volumen_articulo_1_pedido_cliente_N Articulo_J_pedido_cliente_N Volumen_articulo_J_pedido_cliente_N

Ciencias y Tcnicas Estadsticas 9

Normalizacin
La normalizacin es un proceso que consiste en comprobar que las tablas (tambin denominadas relaciones en terminologa propia del modelo relacional de datos) definidas cumplen unas determinadas condiciones. Se pretente garantizar la no existencia de redundancia y una cierta coherencia en la representacin mediante un esquema relacional de las entidades y relaciones del modelo conceptual (diagrama E-R). Mediante la normalizacin se pueden solucionar diversos errores en el diseo de la base de datos as como mejorarlo. Tambin se facilita el trabajo posterior del administrador de la base de datos y de los desarrolladores de aplicaciones.

Dependencia Funcional
Una dependencia funcional, denotada por X -> Y, entre dos conjuntos de atributos X y Y que son subconjuntos de R (R ={A1, A2,...,A3}) especifica una restriccin sobre las posibles tuplas que podran formar un ejemplar de relacin r de R. La restriccin dice que,

para cualesquier dos tuplas t1 y t2 de r tales que t1[X] = t2[X], debemos tener tambin t1[Y] = t2[Y]. Esto significa que los valores componentes de Y de una tupla de r dependen de los valores del componente X, o estn determinados por ellos; o bien, que los valores del componente X de una tupla determinan de manera nica (o funcionalmente) los valores del componente Y. Tambin decimos que hay una dependencia funcional de X a Y o que Y depende funcionalmente de X. Sean a y b atributos de una misma tabla o relacin T. Se dice que b es funcionalmente dependiente de a y se denota T.a -> T.b o bien simplemente a -> b si todo posible valor de a tiene asociado un nico valor de b, o lo que es lo mismo, en todas las tuplas de T en las que el atributo a toma el mismo valor v1, el atributo b toma tambin un mismo valor v2. Claramente a -> b no implica b -> a. Pueden repetirse los valores del atributo b para distintos valores de a. Un mismo atributo puede determinar funcionalmente a varios atributos lo cual se denota a -> (b1, b2, ...). Puede darse una dependencia funcional mutua: a -> b y b -> a o lo que es lo mismo a <> b. Nse que el concepto de dependencia funcional no depende de la extensin concreta (contenido) que en un momento determinado tenga la tabla sino de cualquier posible extensin que pudiera tener. Los atributos a y b pueden ser simples o compuestos (formados por la agregacin de varios atributos). Los atributos funcionalmente dependientes pueden o no formar parte de la clave primaria de la tabla, de una clave altenativa o de una clave ajena de otra tabla. El atributo b es funcionalmente dependiente de forma completa de a si a -> b y b no depende funcionalmente de ningn subconjunto de atributos de a. Si a es un atributo simple y a -> b entonces la dependencia funcional es con seguridad completa. Las dependencias funcionales verifican una serie de propiedades denominadas axiomas de Armstrong: Reflexividad. A partir de cualquier atributo o conjunto de atributos siempre puede deducirse l mismo. Dependencia trivial: x -> x. Aumentatividad. Si x -> y entonces x+z -> y. As se puede aumentar trivialmente el antecedente de una dependencia. Ejemplo: si con el dni se determina el nombre de una persona, entonces con el dni ms la direccin tambin se determina el nombre. Proyectividad. Si x -> y+z entonces x -> y. Ejemplo: si a partir del dni es posible deducir el nombre y la direccin de una persona, entonces con el dni es posible determinar el nombre. Aditividad. Si x -> y y z -> w entonces x+z -> y+w. Ejemplo: si con el dni se determina el nombre y con la

direccin el telfono de una persona, entonces con el dni y la direccin podr determinarse el nombre y el telfono. Transitividad o enlace de dependencias funcionales. Si x -> y e y -> z entonces x -> z. Ejemplo: si con el dni puede determinarse el cdigo de la provincia de residencia de una persona y con ste cdigo puede determinarse el nombre de la provincia, entonces con el dni puede determinarse el nombre de la provincia. ste es el mecanismo bsico de funcionamiento del enlace entre tablas a partir de claves ajenas.

Reglas de normalizacin
El punto de partida del proceso de normalizacin es un conjunto de tablas con sus atributos, el denominado esquema relacional. Se pretende mejorar dicho esquema de datos. Se dice que una tabla estn en una determinada forma normal si satisface un cierto nmero de restricciones impuestas por la correspondiente regla de normalizacin. La aplicacin de una de estas reglas a un esquema relacional produce un nuevo esquema relacional en el que no se ha introducido ningn nuevo atributo.

Un esquema relacional se compone de una serie de ternas T(A,D) donde T es el nombre de una tabla, A el conjunto de los atributos de esa tabla y D el conjunto de dependencias funcionales que existen entre esos atributos. Si una tabla no satisface una determinada regla de normalizacin, se procede a descomponerla en otras dos nuevas que s las satisfagan. Esto usualmente requiere decidir qu atributos de la tabla original van a residir en una u otra de las nuevas tablas. La descomposicin tiene que conservar dos propiedades fundamentales: 1.No prdida de informacin. Sea T(A,D) que se divide en T1(A1,D1) y T2(A2,D2). A partir de los atributos comunes en ambos esquemas es posible determinar los atributos de T1 no presentes en T2 (es decir, el conjunto A1 - A2) o bien los atributos de T2 no presentes en T1 (el conjunto diferencia A2 - A1). Desde cualquier esquema se consigue recuperar los datos del otro mediante un mecanismo de clave ajena que permite reconstituir el esquema original de partida. Expresado mediante dependencias funcionales, la interseccin de los conjuntos de

atributos A1 y A2 debe determinar funcionalmente la diferencia de los conjuntos de atributos A1 - A2 o bien A2 A1. 2.No prdida de dependencias funcionales. La normalizacin consiste pues en descomponer los esquemas relacionales (tablas) en otros equivalentes (puede obtenerse el original a partir de los otros) de manera que se verifiquen unas determinadas reglas de normalizacin. Evidentemente las reglas de normalizacin imponen una serie de restricciones en lo relativo a la existencia de determinados esquemas relacionales. Segn se avance en el cumplimiento de reglas y restricciones se alcanzar una mayor forma normal. Existen cinco formas normales hacia las cuales puede conducir el proceso de normalizacin de forma incremental ms una forma normal independiente de las otras. Un esquema relacional que satisface todas las restricciones impuestas por la tercera forma normal se considera de buena calidad aunque es mejor que satisfaga una interesante propiedad. La verificacin de una forma normal implica el cumplimiento de todas las formas normales anteriores. La primera forma normal es de cumplimiento obligatorio para que exista siquiera un esquema relacional propiamente formado