Curso de Access Aplicaciones

Si en la tabla de pedidos, al introducir un pedido se anota el IdCliente del cliente que formula el pedido, como en la tabla maestra de clientes cada cliente viene identificado por su IdCliente (el nombre del campo no es necesario que coincida), el registro con ESE idCliente contendrá todos los datos del cliente que hace el pedido, con lo cual se dispondrá de la información del cliente que ha hecho cada pedido, por ejemplo para facturarle…
Igual para los artículos mediante los campos IdArtículo, para los vendedores con el campo IdVendedor, o de las compañías de transporte –no las hemos reflejado en este análisis-.

En MS Access, en el capítulo de las relaciones existe la exigencia de que los campos a relacionar, tengan la propiedad de ser indexados. En el lado de la relación de aquella tabla en donde para ese campo sí se puedan producir valores repetidos para varios registros ese campo Id será indexado sí CON duplicados, y en la tabla para la que no se puedan dar duplicidades para los valores de ese campo, éste quedará definido como indexado sí y SIN duplicados.
En la relación si ésta se define con integridad referencial, esto se representa con un 1 y un símbolo de infinito respectivamente para representar el SIN y el CON duplicados.

Pero focalizando el proceso de análisis de relaciones, en lo relativo a los artículos que se piden (productos), observamos que cada pedido con su IdPedido, solo puede tener anotado un artículo o producto pedido…
En la realidad, un pedido puede contener varios artículos diferentes con diferentes unidades a pedir…

¿CÓMO SOLUCIONAR ESTO?

Una buena forma de poder tomar nota por cada pedido, de varios artículos y de diferentes unidades pedidas para cada uno de ellos, además de NO anotar en la tabla de pedidos esa información, sería la siguiente:
Cada pedido tiene un numero de pedido definido por el campo IdPedido. Por ejemplo el pedido número 10, tendrá en la tabla de pedidos, el IdPedido = 10.
En una tabla aparte, por ejemplo denominada Detalles de pedidos, se introducirán, tantos registros como líneas de detalle se deseen para cada pedido, es decir, tantos registros como artículos pedidos para ese pedido con código IdPedido = 10 (en este ejemplo).
Por lo tanto, deberá definirse una tabla llamada Detalles de pedidos en la que se anoten las siguientes informaciones:
- A qué número de pedido corresponde esta línea de detalle (IdPedido).
- Qué artículo se pide (IdProducto –relacionado con la tabla de productos).
- Qué cantidad se pide. (opcionalmente precios unitarios, descuentos, etc…).

Las relaciones entre estas tablas quedarán como se muestra…

Y los tipos de relación, respecto a si son CON o SIN duplicados (representadas en la pantalla de relaciones como infinito o uno respectivamente) deberían quedar de la siguiente manera ya que en la tabla de Pedidos, no pueden existir 2 pedidos diferentes (cada uno de varios artículos) con el mismo código (sin duplicados).
Sin embargo, en la tabla de Detalles de pedidos, como un mismo pedido de la tabla de Pedidos, puede tener varios artículos diferentes que son pedidos, podrá haber varios registros que se correspondan con el mismo IdPedido de la tabla de Pedidos. Por lo tanto, un IdPedido en la tabla de Detalles de pedidos sí puede tener duplicados por esta razón (con duplicados).
De igual modo, un artículo (IdProducto) también puede tener repeticiones (duplicados) en la tabla de Detalles de pedidos ya que puede, en pedidos distintos de distintos clientes ser pedido (con duplicados). Sin embargo, en la tabla maestra de Productos, no puede estar el mismo artículo repetido. Sólo habrá un registro por cada artículo (sin duplicados):

Todas las relaciones definitivas entre las tablas de nuestra aplicación quedarán como se muestra…

Estas relaciones transcritas a la forma en que son representadas en MS Access aparecen en la pantalla de relaciones de la siguiente manera: