NORMALIZACIÓN

Normalización

La normalización se encarga de obtener los datos agrupados en distintas tablas siguiendo una serie de pasos, de tal manera que los datos obtenidos tienen una estructura óptima para su implementación, gestión y explotación desde distintas aplicaciones futuras. Una de las ventajas principales que se obtiene al realizar la normalización es que la información no estará duplicada innecesariamente dentro de las estructuras: habrá mínima redundancia.

Primera forma normal

Se dice que una tabla está en primera forma normal si todos los valores que componen a sus tuplas son atómicos: un atributo no puede tener más de un valor. Para normalizar una tabla que no esté en 1FN han de seguirse los siguientes pasos:

• Se localizan los atributos correspondientes a la clave principal

• Se realiza una proyección sobre la tabla y así se descompone en varias, de manera que se hace la proyección de la clave con los atributos que tengan los valores únicos.

Por ejemplo, la siguiente tabla no está en 1FN:

Concepto de dependencia funcional

Se dice que un atributo B depende funcionalmente de A (A -> B) si cada valor de A se corresponde con un único valor de B o, visto de otra manera, si dado A puedo obtener B. Un caso típico podría ser DNI -> Nombre, pues dado un DNI puedo obtener el nombre de la persona con ese DNI.

Vamos a ver unas reglas que se pueden realizar entre atributos para poder obtener dependencias funcionales adicionalmente. Vamos a suponer que T es una tabla relacional y X, Y, Z son subconjuntos de atributos de la tabla T.

Reflexividad: Si los valores de un subconjunto de atributos Y están incluidos dentro de un subconjunto de atributos X, se dice que X depende funcionalmente de Y (Y -> X)

Aumentación: Si un subconjunto X depende funcionalmente de otro Y, dicha dependencia se mantendrá aunque se añada otro atributo a los dos subconjuntos (X -> Y entonces X.a -> Y.a)

Transitividad: Si Y depende funcionalmente de X y Z depende funcionalmente de Y, entonces Z depende funcionalmente de X (X -> Y e Y -> Z entonces X -> Z). Por ejemplo, DNI -> NOMBRE y NOMBRE -> DIRECCIÓN, luego DNI -> DIRECCIÓN

Dependencia funcional total: Un atributo Y tiene una dependencia funcional total con otro atributo X si tiene una dependencia funcional con X y no depende funcionalmente de ningún subconjunto de X. Por ejemplo, supongamos que una empresa tiene empleados y que una persona puede ser empleado de varias empresas. Según esto, podríamos decir que DNI.EMPRESA -> NOMBRE, pero esta dependencia no es total porque también es cierto que DNI -> NOMBRE. Sin embargo, no se puede identificar el sueldo de un empleado sin saber a qué empresa pertenece, por tanto, DNI.EMPRESA -> SUELDO sí es una dependencia funcional total.

Segunda forma normal

Esta forma normal se considerará únicamente cuando la clave principal sea compuesta, si no (la clave principal está formada por un único atributo) la tabla estaría en segunda forma normal.

Decimos que una tabla está en segunda forma normal si se cumplen las siguientes condiciones:

• Está en 1FN

• Todo atributo secundario (los que no pertenecen a la clave principal) tiene una dependencia funcional total de la clave completa y no de una parte de ella.

Para convertir una tabla que no esté en 2FN a 2FN se creará una tabla con la clave y todas sus dependencias funcionales totales y otra tabla con la parte de la clave que tiene dependencias con los atributos secundarios.

Por ejemplo, la siguiente tabla no está en 2FN:

ya que el campo "TelefonoProveedor" no es dependiente de la clave candidata {"NombreProducto, "NombreProveedor"} sino únicamente de "NombreProveedor". Se trata de no representar dos entidades distintas en una sola tabla. En este ejemplo, reorganizaríamos los datos de la siguiente manera:

Tabla Productos:

Tabla Proveedores:

Tercera forma normal

Una tabla está en 3FN si:

• Está en 2FN

• No existen atributos no primarios (no pertenecen a la clave) que son transitivamente dependientes de cada posible clave de la tabla, o lo que es lo mismo, un atributo secundario sólo puede ser conocido a través de la clave principal o claves secundarias de la tabla y no por medio de otro atributo no primario.

Para convertir una tabla que no esté en 3FN a 3FN se realizará una proyección de la clave a los elementos que no tengan dependencia funcional transitiva y otra tabla con una nueva clave a los elementos que anteriormente tenían esta dependencia.

Por ejemplo, la siguiente tabla no está en 3FN:

Tabla Atletas:

ya que, dado un número de licencia, podemos obtener la edad del inscrito, y dada la edad del inscrito, podemos averiguar la categoría a la que pertenece: tenemos una dependencia funcional transitiva. Evidentemente, dado el número de licencia podemos averiguar la categoría pero lo importante aquí es que la categoría depende de un atributo que no forma parte de la clave. Para normalizar, descompondremos la tabla en las siguientes:

Tabla Atletas:

Tabla Categorias:

Integridad

Finalizamos esta introducción a las bases de datos hablando de los distintos niveles de integridad que tendremos que asegurar a nuestros datos. Una vez realizado el diseño de la base de datos, hemos de preocuparnos por los siguientes puntos:

Integridad de los datos

La creación de un modelo de las entidades del espacio del problema y las asociaciones entre ellas es sólo una parte del proceso de modelización de los datos. También se deben captar las reglas que utilizará el sistema de base de datos para asegurar que los datos físicos que realmente mantiene son, si no correctos, al menos plausibles. En otras palabras, se debe modelar la integridad de los datos.

No puede garantizarse que los datos sean fidedignos; por ejemplo, que un pedido sea de 16 unidades o de 8 unidades depende de el usuario introductor de datos, con lo que para el sistema las dos posibles entradas serían validas aunque claro esta solo es una de ellas. Pero sí se puede garantizar mediante el diseño de la base de datos que los datos son conformes a las restricciones de integridad definidas para ellos.

Integridad de dominios

Una restricción de dominio es una regla que define esos valores validos. La elección de los tipo de datos (fecha , texto, etc.) es el primer paso para la determinación de las restricciones de dominio de un sistema.

El siguiente aspectos a considerar sobre la integridad de dominio es si al dominio se le permite contemplar valores desconocidos o inexistentes.

Integridad de transiciones

Las restricciones de integridad de transiciones definen los estados por los que una tupla puede pasar válidamente. Por ejemplo solo se permitirá que el saldo de un cliente cambie a de “Normal” a “Preferente” si el límite de crédito del cliente supera un determinado valor o si lleva al menos un año comerciando con la empresa. El requisito del límite de crédito seguramente estará controlado por un atributo de la relación Clientes, pero puede que el tiempo que lleva el cliente trabajando con la empresa no esté explícitamente guardado en ningún sitio. Será necesario calcular el valor de acuerdo con el registro más antiguo en el que figure el cliente en la relación Pedidos.

Integridad de entidades

Las restricciones de entidades aseguran la integridad de las entidades que son modeladas por el sistema. En el nivel más simple, la existencia de una clave principal es una restricción de entidad que impone la regla “cada entidad debe estar identificada de forma única”.

Integridad referencial

“Las claves externas no pueden quedar huérfanas”. Es decir ningún registro de la tabla externa puede contener una clave externa que no se corresponda con algún registro de la tabla principal. Las tuplas que contienen claves externas que no tienen una correspondiente clave candidata, se denominan entidades huérfanas. Tres de las formas en las que se pueden crear entidades huérfanas:

• Se añade una tupla externa con una clave que no se corresponde con una clave candidata en la tabla principal

• La clave candidata de la tabla principal cambia

• Se elimina en la tabla principal el registro referenciado

Integridad de transacciones

Una transacción es una serie de operaciones sobre la base de datos consideradas como una única operación, de manera que cuando se cierra la transacción la base de datos queda en un estado consistente.

Las restricciones de integridad de transacciones gobiernan las formas en que se puede manipular la base de datos. A diferencia de otras restricciones, las restricciones de transacción versan sobre el procesamiento y, por tanto, por sí mismas no son parte del modelo de datos. La base de datos debe respetar todas las restricciones de integridad definidas antes de que comience la transacción y una vez finalizada ésta, aunque se pueden violar temporalmente algunas de las restricciones durante la transacción.

Las transacciones pueden involucrar a múltiples registros, múltiples relaciones e incluso múltiples bases de datos. Siendo precisos, todas las operaciones sobre una base de datos son transacciones. Incluso la actualización de un único registro existente es una transacción. Estas transacciones de bajo nivel las realiza el motor de base de datos de forma transparente y, normalmente

...