Aunque en un artículo anterior comentamos que el tipo de relación más habitual entre dos tablas es de 1 a varios, hoy vamos a ver cómo tratar la modalidad varios a varios. Le dedicamos un artículo especial porque en la vida real, aparece con cierta frecuencia pero Access no es capaz de gestionar este tipo de relación de manera directa.

Punto de partida

Vamos a tomar nuevo como muestra la librería que ya hemos empleado con anterioridad, recordando la composición y relaciones que planteamos inicialmente:

El planteamiento inicial es claro y funciona sin problemas, pero presenta algunas limitaciones. Si pensamos en la relación real que puede existir entre Facturas y Libros, está claro que un libro puede aparecer en más de una factura. Al mismo tiempo, en una factura pueden aparecer uno o más libros, y aquí está la clave: uno o más.

Si supiéramos a ciencia cierta que los clientes siempre van a adquirir un número X de libros distintos, por ejemplo 2 ó 3, podríamos definir nuestra tabla con la técnica de relaciones múltiples y problema solucionado. Desafortunadamente, la vida es complicada, el futuro incierto y no sabemos qué harán nuestros clientes. Por lo tanto tenemos que definir nuestra base de datos de manera que responda a esta incertidumbre.

Cuando entre dos tablas pueda existir un número indeterminado de relaciones asociadas a un único dato, tendremos que definir una relación de tipo varios a varios.

Tratamiento

Es posible que ahora mismo no sepas cuándo puede darse el planteamiento anterior. No hay problema, párate a pensar y visualiza en tu mente una factura. También puedes mirar la siguiente imagen, en la que hay dos partes bien diferenciadas. Por un lado, tenemos el encabezamiento con los datos fijos; número, fecha, datos del cliente y de la expedición; y por otro, el cuerpo, donde aparecerán tantas líneas como artículos (sean libros o no) se compren.

Pues eso es precisamente lo que tenemos que hacer en Access, vamos a dividir la tabla Facturas en dos diferentes para albergar el Encabezado y las Líneas de facturación.

En Cabecera_ftra, hemos dejados los datos fijos que teníamos anteriormente. También hemos aprovechado para añadir algunos nuevos de aplicación general: Nº Factura, Fecha, Código Cliente, Descuento Especial y Forma de pago.

La tabla nueva de detalle, que hemos denominado Lineas_ftra, deberá contener como mínimo Nº Factura y Código Libro, pero puede mejorarse añadiendo por ejemplo un campo de Descuento.

Importante: En esta tabla no es necesario incluir campo clave, pero para que resulte eficiente, la propiedad Indexado del campo Nº Factura deberá tomar el valor Sí, con duplicados.

Después de la transformación, las relaciones de esta base de datos entre las tablas que hemos comentado quedarán de la siguiente forma:

Desdoble de tablas para tratar una relación varios a varios

Cuando trabajamos con este tipo de relaciones, a la hora de introducir los datos, lo habitual es hacerlo mediante un formulario con los datos de la Cabecera y un subformulario que muestre las Líneas de detalle. Ahora mismo, debes centrarte en comprender esta dinámica de trabajo, ya que trataremos la entrada de datos próximamente.

Conclusión

Siempre que en una situación podamos aplicar un modelo de factura, albarán o similar, estaremos ante una situación como la que acabamos de exponer. Eso implicará, trabajar dos tablas con un elemento común y los datos estrictamente necesarios para que resulten eficientes.