1Copyright © Computer Aided Education, S.A.

Relaciones

1. INTRODUCCIÓN

En todo diseño de una base de datos relacional nos encontramos con dos conceptos fundamentalmente: las tablas y las

relaciones.

Las tablas permiten almacenar la información necesaria, mientras que las relaciones tienen dos objetivos: facilitar la extracción o consulta de dicha información y asegurar su integridad, es decir, mantener la base de datos en un estado coherente.

Para esto último se utiliza lo que se conoce como “restricciones de integridad referencial”. Aunque el nombre puede parecer complicado, veremos que no lo es tanto.

Supondremos que disponemos del diseño de nuestra base de datos, por lo que no sólo conocemos las tablas requeridas sino también qué relaciones existen entre ellas. Veamos pues, cómo implementar esta parte del diseño utilizando SQL Server Management Studio.

Lo primero que tenemos que conocer es que podemos encontrar dos tipos de relaciones: 1 a muchos y Muchos a muchos.

Una relación 1 a muchos entre dos tablas promociona una de las tablas como principal y otra como secundaria.

¿Qué quiere decir esto? Es mejor verlo con un ejemplo.

Cojamos el caso de la relación entre las tablas Categorias y Productos. Si piensa en ello, comprobará que una categoría puede tener muchos productos relacionados, en el sentido de que están clasificados dentro de la misma; y, sin embargo, un producto sólo puede pertenecer a una determinada categoría.

Vemos, por lo tanto, que aquí la tabla principal o parte 1 es la de Categorias y la tabla secundaria o parte muchos es la de Productos.

Este tipo de relaciones es muy fácil de representar en una base de datos SQL Server:

1.- Debe crear un campo adicional en la tabla secundaria que haga referencia a la tabla principal.

2.- Debe establecer la relación.

2. RELACIONES 1 A MUCHOS

2

Relaciones

Aquí lo que estamos haciendo es representar la relación 1 a muchos entre las tablas Categorias y Productos con el campo IdCategoria en la tabla Productos. Así, para cada producto será muy fácil conocer en qué categoría está clasificado.

El dato que se guardará en este nuevo campo es justamente el identificador o clave principal de la categoría (tabla principal de la relación), por lo que este campo debe ser del mismo tipo que aquel o, al menos, de un tipo de datos compatible.

Finalmente, debemos decidir si permitiremos valores nulos para el campo que hace referencia a una categoría o no. Esto depende mucho de la naturaleza de la relación.

Debe preguntarse: ¿tiene sentido disponer de un producto del que no conocemos su categoría? Si la respuesta puede ser sí, entonces permita los valores nulos; en caso contrario, no lo permita.

¿Y cuándo puede tener sentido en este caso? Bien, imagine que se elimina una categoría.

Si desea que los productos de esa categoría sigan existiendo en la base de datos, tal vez sea conveniente permitir valores nulos en el campo IdCategoria de la tabla Productos. De esta forma, se podría representar un producto de una categoría eliminada.

Como puede ver, permitir los valores nulos suele complicar el diseño (y programación) de la base de datos. Pero es algo que tenemos que estudiar para ver si lo necesitamos.

Tras añadir el campo que representa la relación, debemos definirla realmente. Esto se consigue con el botón Relaciones de la barra de herramientas.

Aunque no es obligatorio, por claridad

le recomenda-mos que utilice el mismo nom-bre en ambas tablas. Así, si

el campo clave de la tabla

Categorias es IdCategoria,

cree un nuevo campo con las

mimas caracte-rísticas y nom-bre en la tabla

Productos.

3Copyright © Computer Aided Education, S.A.

Relaciones

Recuerde que la relación se definirá en la estructura de la tabla secundaria.

Vemos que el título de este cuadro de diálogo es Relaciones de clave externa y es que el campo IdCategoria de la tabla Productos es una clave externa, ya que hace referencia a la información almacenada en otra tabla (Categorias en este caso).

Bien, debe pulsar en el botón Agregar de este cuadro de diálogo y definir la relación.

Lo primero es indicar la tabla relacionada. Para ello, haga clic en la propiedad Especificación de tablas y columnas y pulse en el botón con tres puntos que aparece.

4

Relaciones

En el cuadro de diálogo anterior deberá indicar las tablas que intervienen en la relación y mediante qué campos.

Como queremos representar la relación entre las tablas Categorias y Productos, vemos que en la lista Tabla de clave principal hemos elegido la tabla Categorias (con el campo IdCategoria) y en la lista Tabla de clave externa ya tenemos la tabla Productos (con su campo IdCategoria).

Por lo tanto se establece una relación entre las tablas Categorias y Productos a través del campo IdCategoria de ambas tablas.

Fíjese que esto queda reflejado en el nombre de la relación FK_Productos_Categorias. Lo que quiere decir que se trata de una relación de clave externa (Foreign Key), de forma que la tabla Productos (tabla secundaria) hace referencia a la tabla Categorias (tabla principal).

De esta forma iría creando las relaciones entre las distintas tablas.

Hemos comentado que uno de los objetivos de las relaciones es mantener la base de datos en un estado coherente.

Tal vez no ha entendido muy bien a qué nos estábamos refiriendo y tiene razón. Bien, lo que esto quiere decir es que los datos que se almacenan en las distintas tablas deben cumplir una serie de restricciones y no poder almacenar cualquier valor.

Con el ejemplo de las tablas Categorias y Productos se ve muy bien. Imagine que está introduciendo un nuevo producto en el catálogo de la tienda.

Lógicamente necesita conocer en qué categoría lo incluirá y, lo que es incluso más importante, que esa categoría exista en la tabla Categorias.

¿Por qué? Porque si no es así, incluiría un producto de una categoría inexistente.

Para que esto lo controle la propia base de datos, debemos exigir las restricciones de integridad referencial.

¿Ve cómo es útil que ambos campos tengan el mismo nom-

bre? De esta forma, ha sido

fácil identifi-carlos.

3. RESTRICCIONES DE INTEGRIDAD REFERENCIAL

5Copyright © Computer Aided Education, S.A.

Relaciones

Esto se consigue definiendo la relación de clave externa y estableciendo la propiedad Exigir restricción de clave externa al valor Sí.

Adicionalmente, podemos indicar qué ocurre cuando se modifica o eliminan registros de la tabla principal. Volvamos a nuestro ejemplo:

---> ¿Qué debe ocurrir cuando se modifica el valor del identificador de una categoría en la tabla Categorias?

Esto lo indicaremos en la propiedad Regla de actualización de la sección Especificación de INSERT y UPDATE.

Pues podemos elegir hasta cuatro acciones distintas:

Sin acción: simplemente no se permite la modificación de la clave de una categoría si tiene productos relacionados.

Cascada: se modifica también el valor del identificador de la categoría en la tabla Productos.

Establecer en Null: se establece a Null el campo de la tabla Productos (siempre que así lo hayamos permitido).

Establecer predeterminado: se establece al valor predeterminado de este campo en la tabla Productos (siempre que se haya definido dicho valor).

---> ¿Qué debe ocurrir cuando se elimine una categoría de la tabla Categorias?

Esto lo indicaremos, de forma parecida, en la Regla de eliminación de la misma sección de propiedades.

6

Relaciones

Al exigir las restricciones de integridad referencial, nos aseguramos de que la base de datos se mantendrá en un estado coherente.

Además, podemos indicar qué queremos que ocurra cuando se modifica o elimina un registro que tiene registros relacionados en otras tablas.

Por defecto, esto no se permitirá, pero podremos indicar que también se modifiquen o eliminen esos registros relacionados si activamos la opción de hacerlo en cascada.

Otras relaciones 1 a muchos que puede encontrar en esta base de datos son:

- Los carritos de la compra contienen productos (tablas CarritoCompra y Productos).- Los clientes realizan órdenes de compra (tablas Clientes y Ordenes).- ...

Continuamos la lección estudiando otro tipo de relación menos frecuente pero que también puede aparecer en una base de

datos: las relaciones muchos a muchos.

Por ejemplo, podemos ver que en una orden de compra pueden aparecer varios productos (junto a la cantidad en que se compran) y, además, un producto puede aparecer en varias órdenes de compra.

Por lo tanto, estamos identificando una relación muchos a muchos entre las tablas Productos y Ordenes.

Las relaciones muchos a muchos no se pueden representar directamente en una base de datos relacional, sino que se tienen que seguir estos pasos:

1.- Crear una nueva tabla en la que aparecerán dos campos representando las claves principales de las tablas relacionadas. Estos dos campos constituirán la clave principal de la nueva tabla.

4. RELACIONES MUCHOS A MUCHOS

7Copyright © Computer Aided Education, S.A.

Relaciones

Adicionalmente pueden aparecer más campos en esta tabla, propios de la relación.

2.- Una vez creada la tabla adicional, establecer una relación 1 a muchos entre la nueva tabla y cada una de las tablas implicadas.

Aquí puede ver la tabla LineasOrden, que refleja justamente la relación Muchos a muchos entre las tablas Ordenes y Productos. Fíjese que la clave principal de esta nueva tabla es el par (IdOrden, IdProducto), es decir, las claves de las tablas implicadas.

Y ahora definamos la definición de las relaciones 1 a muchos entre esta nueva tabla y las dos implicadas en la relación.

Fíjese todo lo que estamos consiguiendo con las relaciones y la integridad referencial:

Al añadir nuevos registros, nos aseguramos de que los valores de las claves externas existen en las tablas principales a las que hacen referencia.

8

Relaciones

Al actualizar o modificar una clave principal en la tabla principal, ocurrirá lo mismo en la tabla secundaria.

Aunque definir las relaciones y exigir la integridad referencial va a dificultar la programación, ya que se tienen que cumplir todas estas restricciones, facilitamos que no se pueda dejar la base de datos en un estado inconsistente.

9Copyright © Computer Aided Education, S.A.

Relaciones

A) TABLAS

CarritoCompra: Representa el conjunto de productos que ha elegido comprar el usuario. Tendremos un registro por cada producto insertado en su carrito, por lo que se necesita la clave principal IdRegistro para identificar dicho registro e IdCarrito para identificar el carrito en cuestión. Este último campo coincidirá con el número de cliente si es un usuario registrado o con un identificador aleatorio si no lo es. De esta forma, se relaciona el carrito con el usuario en cuestión.

Nombre del campo

Tipo de datos Permitir valores nulos

Clave principal

IdRegistro int (Identidad) No SíIdCarrito varchar(50) No NoIdProducto int No NoCantidad smallint Sí NoFechaRegistro datetime Sí No

Categorias: Incluye la descripción de cada categoría de productos que tenemos en la tienda. Por ejemplo, artículos de decoración, utensilios de concina, etc. Esta tabla podría incluir detalles específicos de cada categoría si fuera necesario, de forma que todos los productos de la misma "heredarían" dichas características.

Nombre del campo

Tipo de datos Permitir valores nulos

Clave principal

IdCategoria int (Identidad) No SíDescripción varchar(MAX) Sí No

ESTRUCTURA DE LA BASE DE DATOS TiendaDetallesBD

10

Relaciones

Clientes: Almacena toda la información necesaria sobre los clientes, incluyendo su dirección de correo electrónico y password, datos necesarios para entrar como usuario registrado en la tienda virtual.

Nombre del campo

Tipo de datos Permitir valores nulos

Clave principal

IdCliente int (Identidad) No SíNombre varchar(50) No NoApellidos varchar(MAX) No NoDireccion varchar(MAX) Sí NoPoblacion varchar(80) Sí NoCodPostal char(5) Sí NoProvincia varchar(50) Sí NoEmail varchar(40) No NoPassword varchar(12) No NoTelefono varchar(15) Sí NoFechaNacimiento datetime Sí NoEdad int Sí No

LineasOrden: Tabla resultante de la relación Muchos a muchos entre las tablas Productos y Ordenes. Se almacena el detalle de cada producto incluido en una orden en firme de compra. El campo Cantidad tiene que ser mayor o igual que 1.

Nombre del campo

Tipo de datos Permitir valores nulos

Clave principal

IdOrden int No SíIdProducto int No SíCantidad smallint Sí NoSubtotal money Sí No

11Copyright © Computer Aided Education, S.A.

Relaciones

Ordenes: Representa los pedidos en firme efectuados por el usuario. Para ello, habrá tenido que identificarse para entrar en la tienda virtual como un usuario registrado. Se guarda el total del pedido para no tener que calcularlo cada vez.

Nombre del campo

Tipo de datos Permitir valores nulos

Clave principal

IdOrden int (Identidad) No SíIdCliente int No NoFechaOrden datetime No NoFechaEnvio datetime Sí NoTotal money Sí No

Productos: Almacena toda la información de los productos disponibles en la tienda, incluyendo un campo donde se indica la ubicación de una imagen digital del producto.

Nombre del campo

Tipo de datos Permitir valores nulos

Clave principal

IdProducto int (Identidad) No SíNombre varchar(80) No NoPrecio money Sí NoDescripcion varchar(MAX) Sí NoImageURL varchar(100) Sí NoPeso decimal(8, 3) Sí NoIdCategoria int No No

B) RELACIONES

En el diagrama siguiente puede ver gráficamente las relaciones existentes en la base de datos. Las relaciones se representan mediante enlaces que unen las tablas. Como límites de estos enlaces tenemos un icono de llave, que representa la parte 1, y un símbolo del valor infinito, que representa la parte muchos. En todas ellas se exigen las restricciones de integridad referencial y están activadas las modificaciones y eliminaciones en cascada.

12

Relaciones