Identificar relaciones

Ahora que ha dividido la información en tablas debe indicar a Visual FoxPro la manera de agruparla de nuevo de forma significativa. Por ejemplo, el formulario siguiente incluye información procedente de tablas distintas.

El formulario Entrada de pedidos utiliza información de varias tablas.

Visual FoxPro es un sistema de administración de bases de datos relacionales. Esto significa que los datos relacionados se almacenan en tablas separadas. A continuación defina las relaciones entre las tablas que Visual FoxPro utilizará para buscar información asociada almacenada en la base de datos.

Por ejemplo, suponga que desea telefonear a un empleado para consultarle sobre una venta que ha realizado. Los números de teléfono de los empleados están registrados en la tabla Employee, y las ventas se registran en la tabla Orders. Al indicar a Visual FoxPro la venta en la que estamos interesados, éste puede buscar el número de teléfono utilizando la relación existente entre las dos tablas. El mecanismo funciona gracias a que Employee_id, la clave principal de la tabla Employee, es también un campo de la tabla Orders. En la terminología de las bases de datos, el campo Employee_id de la tabla Orders es una clave externa, ya que se refiere a la clave principal de una tabla distinta, o externa.

Campo Employee_id como clave principal de la tabla Employee y como clave externa de la tabla Orders

Así, para establecer una relación entre dos tablas (tabla A y tabla B) se agrega la clave principal de una de ellas a la otra, de forma que aparezca en ambas. Pero, ¿cómo se decide de qué tabla se toma la clave principal? Para configurar correctamente las relaciones, primero es necesario determinar su naturaleza. Hay tres tipos de relaciones entre tablas:

• Relaciones de uno a varios
• Relaciones de varios a varios
• Relaciones de uno a uno

En el resto de esta sección se presenta un ejemplo de cada tipo de relación y se explica cómo diseñar las tablas de forma que Visual FoxPro pueda asociar sus datos correctamente. El propósito de cada ejemplo es explicar la forma de determinar las relaciones entre las tablas y cómo decidir los campos de las tablas que deben utilizarse para las relaciones. No se pretende describir el uso de la interfaz de Visual FoxPro para relacionar tablas.

Ejemplo:

La relación de uno a varios es la más común en una base de datos relacional. En una relación de este tipo, un registro de la tabla A puede tener más de un registro coincidente en la tabla B, pero cada registro de la tabla B tendrá como máximo un registro coincidente en la tabla A.

Por ejemplo, las tablas Category y Products de la base de datos de Comercial Tasmania tienen una relación de uno a varios.

Las tablas Category y Products representan una relación de uno a varios.

Para establecer la relación, agregue el campo o los campos que forman la clave principal del lado "uno" de la relación a la tabla del lado "varios". En el lado "uno" se utiliza una clave de índice principal o candidato y en el lado "varios" puede usarse una clave de índice normal. En este caso, el campo Category_id de la tabla Category se agregaría a la tabla Products, ya que una categoría incluye muchos productos. Visual FoxPro utilizará el número de Id. de categoría para localizar la categoría correspondiente a cada producto.

Para obtener información sobre la creación de claves de índice, consulte Trabajar con tablas.

Ejemplo:

En una relación de varios a varios, un registro de la tabla A puede tener más de un registro coincidente en la tabla B y a un registro de la tabla B también puede corresponderle más de un registro de la tabla A. Este tipo de relación requiere cambios en el diseño de la base de datos para su correcta especificación en Visual FoxPro.

Para detectar relaciones de varios a varios entre las tablas es importante observar los dos sentidos de cada relación. Por ejemplo, considere la relación entre pedidos y productos de la base de datos de Comercial Tasmania. Cada pedido puede tener más de un producto. Así que por cada registro de la tabla Orders puede haber múltiples registros relacionados en la tabla Products. Pero esto no es todo. Cada producto puede aparecer en varios pedidos. Así que por cada registro de la tabla Products puede haber múltiples registros relacionados en la tabla Orders.

Las tablas Orders y Products representan una relación de varios a varios.

Los temas de las dos tablas (Orders y Products) tienen una relación de varios a varios. Esto supone un problema en el diseño de la base de datos. Para entender este problema, imagine lo que ocurriría si intentase establecer la relación entre las dos tablas agregando el campo Product_id a la tabla Orders. Para tener más de un producto por pedido, en la tabla Orders necesita más de un registro por pedido. Tendría que repetir una y otra vez la información para cada registro relacionado con el mismo pedido, lo que supone un diseño poco eficaz que puede llevar a una falta de exactitud en los datos. El mismo problema aparece si se incluye el campo Order_id en la tabla Products: sería necesario más de un registro en la tabla Products para cada producto real. ¿Cómo puede resolverse este problema?

La respuesta consiste en crear una tercera tabla que divida la relación de varios a varios en dos relaciones de uno a varios. Esta tercera tabla se denomina tabla de unión, ya que actúa como unión entre las dos tablas. En la tabla de unión incluya la clave principal de cada una de las dos tablas anteriores.

La tabla Order_Line_Items crea un vínculo de uno a varios entre Orders y Products.

Una tabla de unión podría guardar únicamente las dos claves principales de las tablas que vincula o, como en la tabla Order_Line_Items, la tabla de unión podría contener información adicional.

Cada registro de la tabla Order_Line_Items representa una línea de un pedido. La clave principal de la tabla Order_Line_Items consta de dos campos: las claves externas de las tablas Orders y Products. El campo Order_id por sí solo no sirve como clave principal de la tabla, ya que un mismo pedido puede tener varias líneas de productos. El Id. de pedido se repite para cada línea de un pedido, por lo que el campo no contendrá valores únicos. El campo Product_id tampoco funcionará, ya que un mismo producto puede aparecer en varios pedidos diferentes. Sin embargo, los dos campos juntos en la tabla de unión producirán siempre un valor único para cada registro. La tabla de unión no requiere su propia clave principal.

En la base de datos de Comercial Tasmania, las tablas Orders y Products no se relacionan directamente. En su lugar lo hacen a través de la tabla Order_Line_Items. La relación de varios a varios entre los pedidos y los productos se representa en la base de datos mediante dos relaciones de uno a varios:

• Las tablas Orders y Order_Line_Items tienen una relación de uno a varios. Cada pedido puede tener más de una línea de producto, pero cada línea sólo estará conectada a un pedido.
• Las tablas Products y Order_Line_Items tienen una relación de uno a varios. Cada producto puede tener más de una línea asociada, pero cada línea sólo se refiere a un producto.

Ejemplo:

En una relación de uno a uno, cada registro de la tabla A no puede tener más de un registro coincidente en la tabla B y a cada registro de la tabla B no puede corresponderle más de un registro coincidente en la tabla A. Este tipo de relación es poco habitual y puede indicar la necesidad de una modificación en el diseño de la base de datos.

Las relaciones de uno a uno entre dos tablas son poco usuales ya que, en muchos casos, la información de ambas tablas puede combinarse de forma sencilla en una tabla única. Por ejemplo, suponga que se crea una tabla, llamada Ping_Pong_Players, para hacer un seguimiento de un torneo benéfico de ping-pong en Comercial Tasmania. Como todos los jugadores son empleados, esta tabla tendrá una relación de uno a uno con la tabla Employee de la base de datos de Comercial Tasmania.

Las tablas Employee y Ping_Pong_Players representan una relación de uno a uno.

Sería posible agregar todos los campos de la tabla Ping_Pong_Players a la tabla Employee. Sin embargo, la tabla Ping_Pong_Players se utiliza para un acontecimiento puntual y la información dejará de ser necesaria cuando éste termine. Además, no todos los empleados juegan al ping-pong, de modo que si los campos se incorporasen a la tabla Employee, estarían vacíos en muchos registros. Por estas razones tiene sentido crear una tabla distinta.

Cuando detecte la necesidad de una relación de uno a uno en una base de datos, considere primero si es conveniente agrupar la información en una sola tabla. Por ejemplo, en la tabla Employee, un empleado puede tener un director, que también es un empleado. Puede agregar un campo para el número de identificación del director. Para reunir la información más tarde, puede usar una autocombinación en la consulta o vista. No necesita una tabla independiente para resolver la relación uno a uno. Si no quiere hacerlo por alguna razón, a continuación se muestra cómo configurar la relación uno a uno entre las dos tablas:

• Si las dos tablas tratan del mismo tema, probablemente podrá definir la relación utilizando el mismo campo de clave principal en ambas.
• Si las dos tablas tratan de temas distintos y tienen claves principales diferentes, elija una de ellas e incluya su campo de clave principal en la otra como clave externa.

Vea también

Determinar los campos necesarios | Mejorar el diseño | Organizar los requisitos en tablas | Análisis de los requisitos de datos | Diseñar bases de datos | Crear bases de datos | Trabajar con tablas