Por qué y para qué normalizar?

A la hora de diseñar una base de datos podemos basarnos en dos enfoques principalmente:

realizar un modelo entidad/relación que posteriormente transformaremos a un esquema

entidad/relación 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 Teoría de la Normalización es un mejor ajuste. El segundo enfoque

hace necesaria la utilización de la Teoría de la Normalización por la facilidad de caer en una falta

de estructuración y redundancia.

Los problemas que se suelen presentar al tener un Esquema Relacional mal diseñado son los

siguientes:

Incapacidad para almacenar ciertos hechos

Redundancias y posibilidad de inconsistencias

Ambigüedades

Pérdida de información

Pérdida de Restricciones de Integridad

Anomalías de inserción, borrado y modificación

La Teoría de la Normalización nos permite identificar todos estos problemas y convertir esas

relaciones a una forma más deseable.

Proceso de normalización

La Teoría de la Normalización es una expresión formal de ideas sencillas con una aplicación muy

práctica que conducen a una correcta elección del esquema de la base de datos. Una relación

estará en determinada Forma Normal si satisface un cierto conjunto de restricciones. El

Procedimiento de Normalizar nos permitirá que si tenemos una relación en 2FN, se podrá

convertir en una forma más deseable (3FN), y así de forma sucesiva.

Hay que señalar que al aplicar un Proceso de Normalización a una base de datos por lo general

se aumenta el número 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.

Teoría de la normalización.En el desarrollo del diseño lógico obtenemos una serie de tablas finales que son

las candidatas a formar nuestra base de datos. Sin embargo, dichas tablas han sidoobtenidas a partir de un diseño conceptual elaborado sin ningún tipo de reglas, por loque podemos obtener un diseño de tablas más o menos heterogéneo.La teoría de la normalización consiste en un conjunto de reglas formales que nospermiten asegurar que un diseño lógico cumple una serie de propiedades, corrigiendo laestructura 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.Ambigüedades.Pérdida de información.Aparición en la base de datos de estados no válidos en el mundo real, es lo quese llama anomalías de inserción, borrado y modificación.Las reglas formales de la teoría de la normalización son conocidas con elnombre de formas normales. Existen seis formas normales, de forma que cuando la basede datos cumple las reglas de la primera forma normal se considera que está en primeraforma normal (1FN), cuando pasan la segunda, que está en segunda forma normal(2FN), etc. Además, una base de datos de la que se afirme que está en 2FN, estátambién en 1FN, pues las formas normales se aplican de forma sucesiva.De las seis formas normales, generalmente solo se aplican sobre las bases dedatos las tres primeras, considerando que una base de datos que está en 3FN es una basede datos correctamente diseñada. Por ello, expondremos a continuación estás tresprimeras formas normales.Para desarrollar la teoría de normalización de una base de datos tomaremoscomo ejemplo el diseño de la gestión de una empresa considerando solo la parte defacturación 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 unatabla contiene un solo valor atómico (simple). Un atributo que contiene varios valores

puede derivar en una perdida de datos.Tomando el ejemplo propuesto, hemos realizado un análisis y hemos obtenidoque para identificar la factura hemos creado como clave primaria el código de la facturay hemos establecido además la necesidad de que una factura posea los siguientescampos:Ciencias y Técnicas Estadísticas 5Adquisición y tratamiento de datos Diseño de bases de datos relacionalesFACTURACodigo_facturaCodigo_clienteNombre_clienteDireccion_clientePoblacion_clienteFecha_facturaForma_pagoCodigo_articulo_1Descripcion_1Cantidad_1Importe_1Tipo_IVA_1…Codigo_articulo_NDescripcion_NCantidad_NImporte_NTipo_IVA_N

Figura 6.4.1.1: Diseño inicial de las facturas.Analizando el diseño inicial de la tabla FACTURA, observamos la existencia demúltiples valores para los atributos (campos) siguientes: Codigo_articulo, descripcion,cantidad, importe e IVA. Analizando la tabla, observamos que no cumple la condiciónde 1FN. La solución consiste en crear una nueva tabla, que podemos llamarDETALLE_FACTURA a la cual se trasladan los datos repetitivos, en nuestro caso losdatos referentes a los artículos (codigo_articulo, descripción, cantidad, importe e IVA). FACTURACodigo_factura Codigo_clienteNombre_clienteDireccion_clientePoblacion_clienteFecha_factura Forma_pago DETALLE_FACTURACodigo_factura Codigo_articuloDescripcionCantidadImporte

Tipo_IVA Figura 6.4.1.2: Diseño de las facturas aplicando la 1FN.Cuando se produce la separación de datos de la tabla original en una nueva tabla,ésta además de los atributos necesarios, traslada la clave primaria de la tabla originalcomo parte de su nueva clave primaria, que estará formada, generalmente, por dosatributos.6.4.2 Segunda forma normal (2FN).La segunda forma normal, como la tercera que veremos a continuación, serelaciona con el concepto de dependencia funcional.Entendemos como dependencia funcional a la relación que tienen los atributos(campos) de una tabla con otros atributos de la propia tabla. Un campo tienedependencia funcional si necesita información de otro/s campo/s para poder contener unvalor.Una tabla se dice que esta en segunda forma normal (2FN) si sucede que:Está en 1FNCiencias y Técnicas Estadísticas 6Adquisición y tratamiento de datos Diseño de bases de datos relacionalesCada atributo (campo) no clave depende de la clave completa, no de parte deella.Por supuesto, una base de datos estará en 2FN si todas sus tablas lo están.La idea intuitiva de la 2FN es identificar todas las tablas con una clavecompuesta, pues todas las tablas con clave simple están por defecto en 2FN si están en1FN, y comprobar que cada uno de los campos de esta tabla depende de la clavecompleta.En nuestro ejemplo, la tabla FACTURA se encuentra en 2FN pues está en 1FN ysu clave es simple. Sin embargo la tabla DETALLE_FACTURA ha de ser analizadapues su clave es compuesta (esta formada por dos atributos).Analizando la tabla DETALLE_FACTURA, observamos que el atributodescripcion depende únicamente del atributo codigo_articulo (la descripción de un

articulo depende únicamente de que articulo se trate y es completamente independientede la factura), por lo cual la descripcion ha de ser llevada a una nueva tabla junto con elatributo clave codigo_articulo.Supongamos además, que el cliente nos indica que en la factura, aunque cadaarticulo posee calculado su IVA, el tipo de IVA que aplica es común a toda la factura yno depende en cada factura de los artículos, por lo cual, vemos que el atributoTipo_IVA solo depende funcionalmente del codigo_factura y no depende decodigo_articulo, por lo cual ha de ser devuelta a la tabla FACTURA como un únicoatributo Tipo_IVA que depende solo de la clave de FACTURA (codigo_factura). FACTURACodigo_factura Codigo_clienteNombre_clienteDireccion_clientePoblacion_clienteFecha_facturaForma_pago Tipo_IVA DETALLE_FACTURACodigo_factura Codigo_articuloCantidad Importe Figura 6.4.2.1: Diseño 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.ARTICULOCodigo_articulo Descripcion Todos los atributos que no son claves deben ser mutuamente independientes, esdecir, 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 tablaposiblemente contiene datos acerca de mas de una entidad, contradiciendo el principiode que cada tabla almacene información de una entidad.Ciencias y Técnicas Estadísticas 7

Adquisición y tratamiento de datos Diseño de bases de datos relacionalesEn nuestro ejemplo, podemos observar que las tablas ARTICULO yDETALLE_FACTURA se encuentran en 3FN. Sin embargo, la tabla FACTURA noestá en 3FN, pues los atributos Nombre_cliente, Direccion_cliente y Poblacion_clientedependen 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 tablaque haga referencia al cliente, tabla que llamaremos CLIENTE y que contendrá comoclave primaria el Codigo_cliente y como atributos el Nombre_cliente, Direccion_clientey Poblacion_cliente. Aplicando esto, nuestro diseño de las facturas da lugar a las tablasque pueden verse en la siguiente figura. FACTURACodigo_factura Codigo_clienteFecha_facturaForma_pago Tipo_IVA DETALLE_FACTURACodigo_factura Codigo_articuloCantidad Importe CLIENTECodigo_cliente Nombre_clienteDireccion_cliente Poblacion_cliente ARTICULOCodigo_articulo Descripcion Figura 6.4.3.1: Diseño de las facturas aplicando la 3FN.6.4.4 Consideraciones finales y problemas de la normalización.La teoría de la normalización nos ayuda a estructurar mejor las tablas de la basede datos, evitando posibles redundancias.Por otra parte, si seguimos la metodología de diseño expuesta en los puntos 6.2 y6.3 del tema, obteniendo un diseño conceptual que después es convertido en diseñológico, este diseño lógico resultante estará en 3FN siempre que todo el proceso se haya

realizado de forma correcta, sirviendo en este caso la teoría de la normalización paracomprobar que el diseño ha sido realizado correctamente. Si no lo fuese, podremosaplicar las formas normales para corregir los errores que hubieran podido producirse.Mientras la normalización resuelve los problemas relacionados con laestructuración de los datos en tablas, crea problemas añadidos a su propio concepto,como son la duplicación de datos y la ineficacia en la recuperación de información.Así, el proceso de normalización envuelve la descomposición de una tabla entablas más pequeñas, lo cual requiere que la clave primaria de la tabla original seincluya, como una clave foránea, en la tabla/s que se forman. Esto significa que amedida que se van creando estas claves foráneas se va incrementando las probabilidadesde poner en peligro la integridad de la base de datos.Otro efecto adicional del número creciente de tablas en la base de datos, es quese ve disminuido el rendimiento del sistema en la recuperación de la informacióncontenida. Esta disminución del rendimiento puede ser particularmente importante en Ciencias y Técnicas Estadísticas 8Adquisición y tratamiento de datos Diseño de bases de datos relacionalessistemas basados en microordenadores. Por tanto, en ciertas ocasiones es necesariollegar a un compromiso entre el nivel de normalización de la base de datos y elrendimiento del sistema.6.5 Ejercicios de diseño 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 ovarios proyectos, de forma que un proyecto solo depende de un departamento. Por otrolado cada departamento consta de uno o varios empleados, que trabajan de formaexclusiva para ese departamento, pero pueden trabajar simultáneamente en varios

proyectos. Cada empleado tiene un jefe encargado de supervisar su trabajo, pudiendocada jefe supervisar el trabajo de varios empleados. Dada la descripción anterior,desarrollar la base de datos normalizada hasta 3FN.6.5.2 Ejercicio.Dada el siguiente diseño de una tabla de una base de datos, aplicar las tresprimeras formas normales y llevar el diseño a 3FN.ENVIOCodigo_envioMatricula_camionModelo_camionCapacidad_camionCliente_1Direccion_cliente_1Pedido_cliente_1Articulo_1_pedido_cliente_1Volumen_articulo_1_pedido_cliente_1…Articulo_I_pedido_cliente_1Volumen_articulo_I_pedido_cliente_1…Cliente_NDireccion_cliente_NPedido_cliente_NArticulo_1_pedido_cliente_NVolumen_articulo_1_pedido_cliente_N…Articulo_J_pedido_cliente_NVolumen_articulo_J_pedido_cliente_N

Ciencias y Técnicas Estadísticas 9

Normalización

La normalización es un proceso que consiste en comprobar que las tablas (también denominadas relaciones en terminología 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 representación mediante un esquema relacional de las entidades y relaciones del modelo conceptual (diagrama E-R). Mediante la normalización se pueden solucionar diversos errores en el diseño de la base de datos así como mejorarlo. También 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 restricción sobre las posibles tuplas que podrían formar un ejemplar de relación r de R. La restricción dice que, para cualesquier dos tuplas t1 y t2 de r tales que t1[X] = t2[X], debemos tener también 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 están 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. También 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 relación 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 también 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. Nóse que el concepto de dependencia funcional no depende de la extensión concreta (contenido) que en un momento determinado tenga la tabla sino de cualquier posible extensión que pudiera tener.

Los atributos a y b pueden ser simples o compuestos (formados por la agregación 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 ningún 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 más la dirección también 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 dirección 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 dirección el teléfono de una persona, entonces con el dni y la dirección podrá determinarse el nombre y el teléfono.

Transitividad o enlace de dependencias funcionales. Si x -> y e y -> z entonces x -> z. Ejemplo: si con el dni puede determinarse el código de la provincia de residencia de una persona y con éste código puede determinarse el nombre de la provincia, entonces con el dni puede determinarse el nombre de la provincia. Éste es el mecanismo básico de funcionamiento del enlace entre tablas a partir de claves ajenas.

Reglas de normalización

El punto de partida del proceso de normalización es un conjunto de tablas con sus atributos, el denominado esquema relacional. Se pretende mejorar dicho esquema de datos. Se dice que una tabla están en una determinada forma normal si satisface un cierto número de restricciones impuestas por la correspondiente regla de normalización. La aplicación de una de estas reglas a un esquema relacional produce un nuevo esquema relacional en el que no se ha introducido ningún 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 normalización, 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 descomposición tiene que conservar dos propiedades fundamentales:

1.No pérdida de información. 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 intersección 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 pérdida de dependencias funcionales.

La normalización 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 normalización. Evidentemente las reglas de normalización imponen una serie de restricciones en lo relativo a la existencia de determinados esquemas relacionales. Según 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 normalización de forma incremental más 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 verificación 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