Diseñar una base de datos con múltiples tablas

Es comprensible que queramos poner a funcionar ya nuestra base de datos. Pasar directamente a introducir datos y sacarle provecho a nuestro flamante Access. Pero como hemos visto anteriormente el diseño de la base de datos previamente a su creación es un paso imprescindible y fundamental, en un buen diseño esta la diferencia entre una base de datos ágil y funcional o por el contrario encontrarnos con problemas a cada clic de ratón que nos hará desesperante la mas mínima búsqueda de datos.

Por eso vamos a diseñar lo mas didácticamente posible un ejemplo para nuestra base de datos.

Supongamos que trabajamos en una empresa. Cualquier empresa. Toda empresa tiene una actividad principal que es vender algo, que en este caso a ese algo lo llamaremos producto. Vamos a partir desde aquí.

Los datos que necesitamos para cada venta son:
Qué hemos vendido (Nombre de producto), Cuanto hemos vendido (Cantidad), A quien se lo hemos vendido (cliente) y Numero de cuenta para cobrárselo (NCcliente).

Pero según trabajemos con estos datos necesitaremos otros datos del cliente, como son el nombre de la empresa para la que trabaja (Empresa), Sus apellidos (Apellidos), Puesto que desempeña (Puesto), Teléfono de contacto (Teléfono), Los datos para enviar los pedidos (Dirección, Población, CP)

Pero claro, podríamos pedirle algo mas a nuestra base de datos, también seria conveniente que cada venta tuviese en cuenta las existencias del almacén y que llegado el caso se notificase la necesidad de hacer un nuevo pedido al proveedor.

Es evidente que si añadimos mas campos a nuestra tabla pronto se convertiría en un dolor de cabeza mas que en una ayuda. Para ello debemos unificar los campos por criterios como ya sabemos.

Empezaremos con la tabla de los datos referidos exclusivamente al cliente.

Ahora veremos los datos referidos exclusivamente al producto

Quizás sea necesario explicar aquí la necesidad de algunos campos. "Código Producto" es el campo clave necesario para distinguir unos productos de otros y relacionarlos con otras tablas.
Tal vez no sea tan evidente la necesidad de un campo para el proveedor, veámoslo mas detenidamente. En realidad el producto no tiene solo su nombre, digamos que también tiene apellidos, esta relacionado con la empresa que lo distribuye, no basta decir que necesitamos producto "DentifricoMasBlanco", necesitamos pedírselo a quien pueda proporcionárnoslo. Y para esto necesitamos los datos del Proveedor.

Pero la primera norma es agrupar campos por afinidad y aunque es evidente que los campos del producto dependen de la tabla del proveedor, también es fácil ver que la tabla del proveedor no depende de los productos. Es decir que un solo proveedor tiene muchos productos pero que además podemos utilizar los datos de la tabla proveedores para otras funciones distintas, por ejemplo para tener contactos con los comerciales, o para desarrollar nuevas líneas de negocio.

Así pues la solución es crear un campo que relacione una con otra tabla para aprovechar todas las ventajas de las bases de datos relacionales, y el vinculo entre las dos tablas es el campo "IDProveedor"

Vamos a complicar aun más las cosas,

En esta tabla de pedidos vemos que hay tres campos de Códigos, el primero "Código Pedido" es el propio a la tabla "Pedidos", la función de los siguientes es relacionar esta tabla con las otras.
Gracias al "Código Cliente" no es necesario introducir en esta tabla los datos del cliente que realiza el pedido, basta con teclear su numero de código, y Access se encargara de escribir por nosotros todos los campos que le pidamos, como son el nombre de la empresa, la dirección, el numero de Cuenta, etc...

Con el campo "Código Producto" pasa exactamente igual, en vez de teclear en cada pedido una y otra vez todos los datos de todos los artículos, como su nombre, o su precio o descripción del producto. Access se encarga de relacionar las dos tablas gracias a este campo.