martes, 24 de junio de 2014

Relaciones varios a varios: tratamiento

Aunque en artículos anteriores hemos comentado que el tipo de relación más habitual entre dos tablas  es de 1 a varios, hoy vamos a ver cómo tratar esta modalidad que, en la vida real, aparece con cierta frecuencia pero que Access no es capaz de gestionar de manera directa.

Ejemplo

Vamos a tomar nuevo como muestra la librería que ya hemos empleado en otros artículos, recordando la composición y relaciones que planteamos inicialmente:

Relaciones de una base de datos básica para libreria


Ahora bien, si pensamos en la relación que en la realidad podría existir entre Facturas y Libros, está claro que un libro puede aparecer en más de una factura, y 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.

Sin embargo,  la vida es complicada y 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.

Tratamiento

Párate a pensar y visualiza en tu mente una factura, y si no, mira la imagen, verás 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.

Factura tipo con zona de Encabezado y Detalle


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 pero también hemos añadido 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.

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, pero espero que ya sepas cómo solucionar esta situación.

No hay comentarios:

Publicar un comentario