Tecnologías de la Información y la Comunicación

Temario:    Proceso de normalización

Las interrelaciones

Álgebra Relacional

Proceso de normalización

El proceso de normalización es un estándar que consiste, básicamente, en un proceso de conversión de las relaciones entre las entidades, evitando:

• La redundancia de los datos: repetición de datos en un sistema.
• Anomalías de actualización: inconsistencias de los datos como resultado de datos redundantes y actualizaciones parciales.
• Anomalías de borrado: pérdidas no intencionadas de datos debido a que se han borrado otros datos.
• Anomalías de inserción: imposibilidad de adicionar datos en la base de datos debido a la ausencia de otros datos.
• Tomando como referencia la tabla siguiente:

Se plantean una serie de problemas:

• Redundancia: cuando un autor tiene varios libros, se repite la nacionalidad.
• Anomalías de modificación: Si Ad.Mig. y Ma.Piat. desean cambiar de editor, se modifica en los 2 lugares. A priori no podemos saber cuántos autores tiene un libro. Los errores son frecuentes al olvidar la modificación de un autor. Se pretende modificar en un sólo sitio.
• Anomalías de inserción: Se desea dar de alta un autor sin libros, en un principio. NOMBRE y CODLIBRO son campos clave, una clave no puede tomar valores nulos.

Asegurando:

• Integridad entre los datos: consistencia de la información.

El proceso de normalización nos conduce hasta el modelo físico de datos y consta de varias fases denominadas formas normales, estas formas se detallan a continuación.

Definición de la clave

Antes de proceder a la normalización de la tabla lo primero que debemos de definir es una clave, esta clave deberá contener un valor único para cada registro (no podrán existir dos valores iguales en toda la tabla) y podrá estar formado por un único campo o por un grupo de campos.

En la tabla de alumnos de un centro de estudios no podemos definir como campo clave el nombre del alumno ya que pueden existir varios alumnos con el mismo nombre. Podríamos considerar la posibilidad de definir como clave los campos nombre y apellidos, pero estamos en la misma situación: podría darse el caso de alumnos que tuvieran los mismo apellidos y el mismo nombre (Juan Fernández Martín).

La solución en este caso es asignar un código de alumno a cada uno, un número que identifique al alumno y que estemos seguros que es único.

Una vez definida la clave podremos pasar a estudiar la primera forma normal.

Primera forma normal (1NF)

Se dice que una tabla se encuentra en primera forma normal (1NF) si y solo si cada uno de los campos contiene un único valor para un registro determinado. Supongamos que deseamos realizar una tabla para guardar los cursos que están realizando los alumnos de un determinado centro de estudios, podríamos considerar el siguiente diseño:

Podemos observar que el registro de código 1 si cumple la primera forma normal, cada campo del registro contiene un único dato, pero no ocurre así con los registros 2 y 3 ya que en el campo cursos contiene más de un dato cada uno. La solución en este caso es crear dos tablas del siguiente modo:

Como se puede comprobar ahora todos los registros de ambas tablas contienen valores únicos en sus campos, por lo tanto ambas tablas cumplen la primera forma normal.

Una vez normalizada la tabla en 1NF, podemos pasar a la segunda forma normal.

Segunda forma normal (2NF)

La segunda forma normal compara todos y cada uno de los campos de la tabla con la clave definida. Si todos los campos dependen directamente de la clave se dice que la tabla está es segunda forma normal (2NF).

Supongamos que construimos una tabla con los años que cada empleado ha estado trabajando en cada departamento de una empresa:

Tomando como punto de partida que la clave de esta tabla está formada por los campos código de empleado y código de departamento, podemos decir que la tabla se encuentra en primera forma normal, por tanto vamos a estudiar la segunda:

1.    El campo nombre no depende funcionalmente de toda la clave, sólo depende del código del empleado.

2.     El campo departamento no depende funcionalmente de toda la clave, sólo del código del departamento.

3.     El campo años si que depende funcionalmente de la clave ya que depende del código del empleado y del código del departamento (representa el número de años que cada empleado ha trabajado en cada departamento)

Por tanto, al no depender todos los campos de la totalidad de la clave la tabla no está en segunda forma normal, la solución es la siguiente:

Podemos observar que ahora si se encuentras las tres tabla en segunda forma normal, considerando que la tabla A tiene como índice el campo Código Empleado, la tabla B Código Departamento y la tabla C una clave compuesta por los campos Código Empleado y Código Departamento.

Tercera forma normal (3NF)

Se dice que una tabla está en tercera forma normal si y solo si los campos de la tabla dependen únicamente de la clave, dicho en otras palabras los campos de las tablas no dependen unos de otros. Tomando como referencia el ejemplo anterior, supongamos que cada alumno sólo puede realizar un único curso a la vez y que deseamos guardar en que aula se imparte el curso. A voz de pronto podemos plantear la siguiente estructura:

Estudiemos la dependencia de cada campo con respecto a la clave código:

• Nombre depende directamente del código del alumno.
• Curso depende de igual modo del código del alumno.
• El aula, aunque en parte también depende del alumno, está mas ligado al curso que el alumno está realizando.

Por esta última razón se dice que la tabla no está en 3NF. La solución sería la siguiente:

Una vez conseguida la segunda forma normal, se puede estudiar la cuarta forma normal.

Cuarta forma normal (4NF)

Una tabla está en cuarta forma normal si y sólo si para cualquier combinación clave - campo no existen valores duplicados. Veámoslo con un ejemplo:

Comparemos ahora la clave (Figura) con el atributo Tamaño, podemos observar que Cuadrado Grande está repetido; igual pasa con Círculo Azul, entre otras. Estas repeticiones son las que se deben evitar para tener una tabla en 4NF.

La solución en este caso sería la siguiente:

Ahora si tenemos nuestra base de datos en 4NF.

Otras formas normales

Existen otras dos formas normales, la llamada quinta forma normal (5FN) que no detallo por su dudoso valor práctico ya que conduce a una gran división de tablas y la forma normal dominio / clave (FNDLL) de la que no existe método alguno para su implantación.

Las interrelaciones

Las interrelaciones son las relaciones que existen entre varias tablas del sistema (Clientes y Pedidos, por ejemplo). Existen tres formas de interrelaciones dependiendo de la cardinalidad con la que se combinan los elementos de ambas tablas.

Interrelaciones uno a uno

Una interrelación es de uno a uno entre la tabla A y la tabla B cuando a cada elemento de la clave de A se le asigna un único elemento de la tabla B y para cada elemento de la clave de la tabla B contiene un único elemento en la tabla A. Un ejemplo de interrelación de este tipo es la formada por las tablas Datos Generales de Clientes y Datos Contables de Clientes. En esta relación cada cliente tiene una única dirección y una dirección en cada una de las tablas. Representamos la relación como A 1: 1 B.

Ante la presencia de este tipo de relación nos podemos plantear el caso de unificar todos los datos en única tabla pues no es necesario mantener ambas tablas a la misma vez.

Este tipo de relación se genera cuando aparecen tablas muy grandes, con gran cantidad de campos, disgregando la tabla principal en dos para evitar tener una tabla muy grande. También surge cuando los diferentes grupos de usuario cumplimentan una información diferente para un mismo registros; en este caso se crean tantas tablas como registros, evitando así tener que acceder a información que el usuario del grupo actual no necesita.

Interrelaciones uno a varios

Una interrelación es de uno a varios entre las tablas A y B cuando una clave de la tabla A posee varios elementos relacionados en la tabla B y cuando una clave de la tabla B posee un único elemento relacionado en la tabla A.

Estudiemos la relación entre la tabla de clientes y la tabla de pedidos. Un cliente puede realizar varios pedidos pero un pedido pertenece a un único cliente, por tanto se trata de una relación uno a varios y la representamos A 1: n B.

Estas relaciones suelen surgir de aplicar la 1NF a una tabla.

Interrelaciones varios a varios

Una interrelación es de varios a varios entre las tablas A y B cuando una clave de la tabla A posee varios elementos relacionados en la tabla B y cuando una clave de la tabla B posee varios elementos relacionados en la tabla A.

Un caso muy característico de esta interrelación es la que surge entre las tablas de Puestos de Trabajo y Empleados de una empresa. Un Empleado puede desempeñar realizar varias funciones dentro de una empresa (desempeñar varios puestos de trabajo), y un puesto de trabajo puede estar ocupado por varios empleados a la misma vez. Esta interrelación la representamos como A n: n B.

No se deben definir relaciones de este tipo en un sistema de bases de datos, debido a su complejidad a la hora de su mantenimiento, por este motivo se debe transformar este tipo de relación es dos interrelaciones de tipo 1: n, empleando para ello una tabla que denominaremos puente y que estará formada por las claves de ambas tablas. Esta tabla puente debe contener una única clave compuesta formada por los campos clave de las tablas primeras.

Ahora existe una relación 1: n entre Empleados y Tabla Puente y otra relación 1: n entre Puestos y Tabla Puente ya que un empleado posee varios códigos de empleado en la tabla puente pero cada elemento de la tabla puente pertenece a un único empleado.

Por otro la un puesto de trabajo posee varios elementos relacionados en la tabla puente, pero cada elemento de la tabla puente está relacionado con un único elemento de la tabla puestos.

Problemas con las interrelaciones

A la hora de establecer las interrelaciones existentes en un sistema de bases de datos nos podemos encontrar dos problemas:

1.    Interrelaciones recursivas: un elemento se relaciona consigo mismo directamente.

2.     Interrelaciones circulares o cíclicas: A se relaciona con B, B se relaciona con C y C se relaciona con A.

Ambos casos pueden suponer un grabe problema si definimos una relación con integridad referencial y decimos eliminar en cascada (al eliminar una clave de la tabla A se eliminan los elementos relacionados en la tabla B). Supongamos la relación recursiva existen en la relación Empleado y Supervisor (ambos son empleados de la empresa). Está claro que un empleado está supervisado por otro empleado. Veamos la forma de solucionarlo:

Para solucionar la relación debemos crear una tabla formada por dos campos. Ambos campos deben ser el código del empleado pero como no podemos tener dos campos con el mismo nombre a uno de ellos le llamaremos código supervisor.

Para terminar de resolver la interrelación recursiva basta con definir dos interrelaciones entre la tabla empleados y la tabla puente de tipo 1: n. La primera relación se crea utilizando las claves Empleados[Código] y Tabla Puente[Código Empleado]. La segunda entre Empleados[Código] y Tabla Puente [Código Supervisor].

Las interrelaciones cíclicas o circulares no son muy frecuentes y no existe una metodología estándar para su eliminación, normalmente son debidas a errores de diseño en la base de datos, principalmente en el diseño conceptual del sistema de datos. Por tanto si llegamos a este punto hay que volver a replantearse todo el diseño de la base de datos.

Atributos de las interrelaciones

En la mayoría de las interrelaciones definidas será conveniente exigir integridad relacional entre las claves. Exigiendo la integridad referencial se consigue que en una relación de tipo 1: n o de tipo 1: 1, no se puede añadir ningún valor en la tabla destino si no existe en la tabla origen. Dicho con un ejemplo: en la relación Clientes y Pedidos la tabla Pedidos contiene un campo que se corresponde con el código del Cliente, si se exige la integridad referencia no se podrá escribir un código de cliente en la tabla Pedidos que no exista en la tabla Clientes; de no exigir la integridad referencial se podrán crear pedidos con códigos de clientes que no existen, generando incongruencia de datos en la base de datos.

Definida la integridad referencial (siempre necesaria) podemos exigir la actualización en cascada (siempre necesaria); esta actualización implica que si cambiamos el código a un cliente, debemos actualizar dicho código en la tabla de pedidos, de no ser así, al cambiar el código a un cliente, perderemos los pedidos que tenía realizados.

Para concluir debemos hablar de la eliminación en cascada (NO siempre necesaria), la eliminación en cascada consiste en eliminar todos los datos dependientes de una clave. En nuestro ejemplo implica que al borrar un cliente hay que eliminar todos los pendidos que ha realizado. En muchas ocasiones no interesa realizar esta operación de eliminación en cascada por motivos diversos. Si en el caso de clientes y pedidos no se exige eliminación en cascada no se podrá borrar ningún cliente en tanto en cuanto tenga realizado algún pedido (de lo contrario tendríamos incongruencia de datos).

Algebra relacional

Las operaciones de álgebra relacional manipulan relaciones. Esto significa que estas operaciones usan uno o dos relaciones existentes para crear una nueva relación. Esta nueva relación puede entonces usarse como entrada para una nueva operación. Este poderoso concepto - la creación de una nueva relación a partir de relaciones existentes hace considerablemente más fácil la solución de las consultas, debido a que se puede experimentar con soluciones parciales hasta encontrar la proposición con la que se trabajará.

El álgebra relacional consta de nueve operaciones:

1.    Unión

2.     Intersección

3.     Diferencia

4.     Producto

5.     Selección

6.     Proyección

7.     Reunión

8.     División

9.     Asignación

Las cuatro primeras se toman de la teoría de conjunto de las matemáticas; las cuatro siguientes son operaciones propias del álgebra relacional y la última es la operación estándar de dar un valor a un elemento.

Unión

La operación de unión permite combinar datos de varias relaciones. Supongamos que una determinada empresa internacional posee una tabla de empleados para cada uno de los países en los que opera. Para conseguir un listado completo de todos los empleados de la empresa tenemos que realizar una unión de todas las tablas de empleados de todos los países.

No siempre es posible realizar consultas de unión entre varias tablas, para poder realizar esta operación es necesario e imprescindible que las tablas a unir tengan las mismas estructuras, que sus campos sean iguales.

Intersección

La operación de intersección permite identificar filas que son comunes en dos relaciones. Supongamos que tenemos una tabla de empleados y otra tabla con los asistentes que han realizado un curso de inglés (los asistentes pueden ser empleados o gente de la calle). Queremos crear una figura virtual en la tabla denominada "Empleados que hablan Inglés", esta figura podemos crearla realizando una intersección de empleados y curso de inglés, los elementos que existan en ambas tablas serán aquellos empleados que han asistido al curso.

Diferencia

La operación diferencia permite identificar filas que están en una relación y no en otra. Tomando como referencia el caso anterior, deberíamos aplicar una diferencia entre la tabla empleados y la tabla asistentes al curso para saber aquellos asistentes externos a la organización que han asistido al curso.

Producto

La operación producto consiste en la realización de un producto cartesiano entre dos tablas dando como resultado todas las posibles combinaciones entre los registros de la primera y los registros de la segunda. Esta operación se entiende mejor con el siguiente ejemplo:

El producto de A * B daría como resultado la siguiente tabla:

Selección

La operación selección consiste en recuperar un conjunto de registros de una tabla o de una relación indicando las condiciones que deben cumplir los registros recuperados, de tal forma que los registros devueltos por la selección han de satisfacer todas las condiciones que se hayan establecido. Esta operación es la que normalmente se conoce como consulta.

Podemos emplearla para saber que empleados son mayores de 45 años, o cuales viven en Madrid, incluso podemos averiguar los que son mayores de 45 años y residen en Madrid, los que son mayores de 45 años y no viven en Madrid, etc..

En este tipo de consulta se emplean los diferentes operadores de comparación (=,>, <, >=, <=, <>), los operadores lógicos (and, or, xor) o la negación lógica (not).

Proyección

Una proyección es un caso concreto de la operación selección, esta última devuelve todos los campos de aquellos registros que cumplen la condición que he establecido. Una proyección es una selección en la que seleccionamos aquellos campos que deseamos recuperar. Tomando como referencia el caso de la operación selección es posible que lo único que nos interese recuperar sea el número de la seguridad social, omitiendo así los campos teléfono, dirección, etc.. Este último caso, en el que seleccionamos los campos que deseamos, es una proyección.

Reunión

La reunión se utiliza para recuperar datos a través de varias tablas conectadas unas con otras mediante cláusulas JOIN, en cualquiera de sus tres variantes INNER, LEFT, RIGHT. La operación reunión se puede combinar con las operaciones selección y proyección.

Un ejemplo de reunión es conseguir los pedidos que nos han realizado los clientes nacionales cuyo importe supere 15.000 unidades de producto, generando un informe con el nombre del cliente y el código del pedido. En este caso se da por supuesto que la tabla clientes es diferente a la tabla pedidos y que hay que conectar ambas mediante, en este caso, un INNER JOIN.

División

La operación división es la contraria a la operación producto y quizás sea la más compleja de explicar, por tanto comenzaré con directamente con un ejemplo. Una determinada empresa posee una tabla de comerciales, otra tabla de productos y otra con las ventas de los comerciales. Queremos averiguar que comerciales han vendido todo tipo de producto.

Lo primero que hacemos es extraer en una tabla todos los códigos de todos los productos, a esta tabla la denominamos A.

En una segunda tabla extraemos, de la tabla de ventas, el código del producto y el comercial que lo ha vendido, lo hacemos con una proyección y evitamos traer valores duplicados. El resultado podría ser el siguiente:

Si dividimos la tabla B entre la tabla A obtendremos como resultado una tercera tabla que:

1.    Los campos que contiene son aquellos de la tabla B que no existen en la tabla A. En este caso el campo Código Comercial es el único de la tabla B que no existen en la tabla A.

2.     Un registro se encuentra en la tabla resultado si y sólo si está asociado en tabla B con cada fila de la tabla A

¿Por qué el resultado es 23?. El comercial 23 es el único de la tabla B que tiene asociados todos los posibles códigos de producto de la tabla A.

Asignación

Esta operación algebraica consiste en asignar un valor a uno o varios campos de una tabla.

Cálculo relacional

El cálculo relacional usa un enfoque completamente diferente al álgebra relacional. No obstante, los dos lenguajes son lógicamente equivalentes. Esto significa que cualquier consulta que pueda resolverse en un lenguaje puede resolverse en el otro. La solución para toda consulta en este tipo de cálculo se define por:

1.    Una lista de resultados

2.     Una sentencia de cualificación

La lista de resultados está clara, son aquellos registros que cumplen las condiciones que deseamos. La sentencia de cualificación contiene las condiciones que deseamos que cumplan los registros de la lista de resultados. La diferencia entre el cálculo y el álgebra radica en que el cálculo realiza la operación en un único paso, sin necesidad de tener que obtener tablas intermedias, el álgebra realiza las operaciones paso a paso.

Normalmente el cálculo relacional se apoya en algún lenguaje de interrogación de bases de datos como puede ser el SQL y que desarrollaré más adelante.

El cálculo relacional incluye un concepto nuevo denominado cuantificador, los cuantificadores tratan de averiguar el número de registros afectados por una determinada operación, incluso antes de realizarla. Según su naturaleza los podemos dividir en dos grupos:

Cuantificadores existenciales

Son aquellos que tratan de averiguar el número de registros que devolvería un tipo de consulta. Por ejemplo: saber el número de clientes de Madrid que han comprado el producto 2015. Si el número de registros que satisfacen esta relación es mayor que cero, podemos generar la consulta para lanzar posteriormente un informe, en caso contrario se puede enviar un mensaje al usuario para que sepa que no hay ningún cliente con estas características.

Cuantificadores universales

Son aquellos que indican que una condición se aplica a todas las filas de algún tipo. Se usa para brindar la misma capacidad que la operación división del álgebra relacional.