Análisis, planificación y estructuración de una B.D.

Objetivo de este apartado del curso

Inculcar al alumno la necesidad fundamental de seguir unas pautas ordenadas que nos sirvan para que:

• Desde el origen de un planteamiento de trabajo con manejo de información y datos al estilo tradicional (sin ordenadores) ...
   
• Nos guíen hasta tener bien definidas las tablas para Access así como sus relaciones pertinentes. Dichas tablas van a ser posteriormente la base sólida para el desarrollo de una aplicación completa y adecuada a dicho ámbito o actividad profesional.
  En ocasiones, este análisis será una tarea sencilla y en otras el resultado de muchísimas reflexiones.

Pasos a seguir

Los pasos secuenciales a realizar para definir correctamente una base de datos bien podrían ser los siguientes:

1 - Análisis de la situación real de trabajo.
2 - Separar en partes o fases los procesos o tareas.
3 - Diseñar un diagrama de bloques reflejando las dependencias entre las partes.
4 - Identificar los grupos de datos o bolsas de información: Los archivos de datos.
5 - Definición de las tablas.
6 - Definición de la estructura y diseño de campos de las tablas.
7 - Codificación de los elementos.
8.- Establecer las relaciones entre las tablas definidas.
 

Vamos a detallar en secuencia, cada uno de éstos pasos:

Análisis de la situación real de trabajo

Separar en partes o fases los procesos o tareas

Organizar y separar en partes o fases, cuantos procesos o tareas reales de trabajo se deseen trasladar a Access. Dichas partes o elementos se derivan de la actividad concreta que se desempeña en la empresa. Qué gestiones se realizan normalmente bajo dicha actividad: Se trata, de crear meditadamente (no a la ligera) una relación (un censo) de las actividades o tareas que conforman la gestión a informatizar. Es preferible un buen planteamiento desde el principio, que múltiples replanteamientos posteriores que, a veces, tienen difícil solución.

Por ejemplo, y básicamente, para una gestión de almacén las FASES de trabajo pueden ser las siguientes:

• Mantenimiento de clientes (altas bajas consultas y modificaciones de clientes).
• Mantenimiento de artículos o productos (altas bajas consultas y modificaciones de artículos).
• Mantenimiento de pedidos (altas bajas consultas y modificaciones de pedidos).

Si se desea controlar que vendedor o comercial realiza tal o tales ventas...

• Mantenimiento de vendedores (altas bajas consultas y modificaciones de vendedores).
• Informes de comisiones a vendedores. Niveles de ventas...

Si se trabaja con varias agencias de transporte y se desean controlar las expediciones de mercancía...

• Mantenimiento de agencias de transporte (altas bajas consultas y modificaciones de agencias).

Si se desean controlar las compras a los proveedores de mercancía...

• Mantenimiento de proveedores (altas bajas consultas y modificaciones de proveedores).
• Elaboración de documentos (tales como facturas, albaranes...).
• Creación de listados e informes diversos (tales como listados de artículos clasificados por familias, listado de clientes por nivel de compras, listados de artículos bajo mínimos...) derivados de la información almacenada y mantenida.

Diseñar el diagrama de bloques

Confeccionar un diagrama de bloques (un esquema) en el que se representa cada una de las tareas definidas en el paso anterior, enlazando mediante flechas que tarea depende de cual y cual no depende de ninguna otra. (esas flechas desembocarán en relaciones cuando se tengan definidas las tablas).

En el ejemplo de la gestión de almacén, el diagrama de bloques podría ser el siguiente:

Los archivos de datos

Una vez definidas las tareas a realizar, tenerlas enumeradas, y debidamente plasmadas en un diagrama de bloques (es decir, un esquema de dependencias que refleje en bloques lo que se hace cotidianamente en ese trabajo): Identificar con que elementos, grupos de datos o bloques de información se trabaja para poder realizar dichas tareas: Clientes, proveedores, artículos, agencias de transporte, pedidos, vendedores...  Estos bloques de datos, estos archivos, estos almacenes de información posteriormente en Access constituirán las tablas.

Para el ejemplo inicial que nos va a servir para comprender el desarrollo de aplicaciones en Access que va a ser la gestión de almacén los bloques de información serán, para cada tarea definida y representada en el diagrama de bloques del punto anterior, los siguientes:

• Para el mantenimiento de clientes interviene lo que tradicionalmente ha sido siempre el fichero o archivo de clientes.

• Para el mantenimiento de artículos o productos el fichero o archivo de artículos.
• Para el mantenimiento de pedidos el fichero o archivo de pedidos.

Si se desea controlar que vendedor o comercial realiza tal o tales ventas...

• Para el mantenimiento de vendedores el fichero o archivo de vendedores.

Si se trabaja con varias agencias de transporte y se desean controlar las expediciones de mercancía...

• Para el mantenimiento de agencias de transporte el fichero o archivo de agencias.

Si se desean controlar las compras a los proveedores de mercancía...

• Para el mantenimiento de proveedores fichero o archivo de proveedores.
• Para la elaboración de facturas, albaranes de pedido...la información necesaria se encuentra en los archivos ya definidos (pedidos, clientes, artículos...).
• Para la creación de listados e informes diversos (tales como listados de artículos clasificados por familias, listado de clientes por nivel de compras, listados de artículos bajo mínimos...) la información necesaria para su elaboración se encuentra también repartida entre los archivos ya mencionados.

Definición de las tablas

Definición de las tablas a partir de los bloques de información ya identificados como ficheros de datos en el punto anterior. Lo que tradicionalmente han sido siempre los archivos de datos (pequeños o grandes cajones metálicos generalmente que contienen fichas de cartulina), en Access y en la mayoría de los programas gestores de bases de datos se denominan tablas. Dichas tablas, son estructuras de filas y columnas que albergan datos referidos a un mismo tema. Cada fila llamada ahora registro contiene la información que antes estaba plasmada en una ficha del fichero. Cada columna de una tabla representa un campo. En la celda de la tabla en la que intersecta una fila con una columna tendremos un determinado campo dentro del cual normalmente se albergará un dato.

En el ejemplo de gestión de pedidos las tablas a definir y crear en la base de datos desde Access serán:

Definición de la estructura y diseño de campos

El siguiente paso es confeccionar un censo de las informaciones o datos que se albergarán en cada tabla: Definición de campos para las tablas de la aplicación. Definir las informaciones necesarias y de utilidad para la gestión que cada tabla deberá albergar. Definir los campos que va a tener cada tabla, así como su tipo y propiedades mas indicadas (siendo conscientes de que las propiedades de los campos se van a poder modificar a posteriori).
A éste proceso se le reconoce también, de forma más técnica, como NORMALIZACIÓN DE DATOS.

De una sentada reflexión de sobre qué informaciones nos interesa gestionar sobre cada una de las fases o tareas, es decir, de cada uno de los ficheros contemplados, es decir de cada una de las tablas previstas, obtenemos, por ejemplo, las siguientes conclusiones que vamos a plasmar en un modelo de documento denominado FICHA DE TAREAS (una para la gestión de pedidos, otra para productos, para clientes, para agencias, vendedores, proveedores...)

Como vemos, aparecen datos sobre el propio pedido, sobre el cliente que hace el pedido, sobre la agencia de transportes que realiza en envío de ese pedido, sobre el artículo que se pide (inicialmente plantearemos que cada pedido solo es de un artículo), y también sobre el comercial o empleado vendedor de la empresa que genera ese pedido...

Para que en un pedido consten todas las informaciones que se consideran necesarias, en principio podríamos pensar que serían necesarios tantos campos en la estructura de la tabla como los expuestos en la relación anterior, en la Ficha de tareas. Sin embargo, gracias a que trabajamos con Access que es un sistema gestor de bases de datos relacional con que, por ejemplo, en cada pedido se almacene, además de la información propia del pedido (campos de color azul y representados en negrita en la Ficha de tareas anterior), el código del cliente que hace el pedido (el IdCliente), con ese código o Id, podremos acceder al registro de ESE cliente en la tabla maestra de clientes (que es otra tabla en la misma base de datos y está aparte). Observar el diagrama de bloques anterior para apreciar que la tarea de gestión de pedidos está vinculada o relacionada con la de clientes (entre otras).

De igual modo, los campos de nuestra Ficha de tareas refleja información o campos que ya tenemos en la tabla de vendedores, en la tabla de agencias, en la tabla de artículos.... Si cada vendedor, si cada agencia de transporte, si cada artículo (producto) tiene una clave única que lo identifica en su tabla, con que en cada pedido archivemos solo ese código, gracias a las relaciones de Access se puede acceder a la tabla relacionada pertinente y la información está ahí accesible. Toda la información de ese registro.
Por ejemplo: Si en un pedido consta que el cliente que hace el pedido es el que tiene código de cliente 7, con ese código, se accede al registro del cliente 7 en la tabla de clientes y ahí está toda la información de ese cliente que se precise... De la misma forma las relaciones entre tablas nos permiten acceder a la información de las demás tablas maestras de vendedores, de productos y de agencias.

En las tablas maestras (productos, clientes, agencias de transporte -métodos de envío-, vendedores y proveedores) todos los campos que se precisen serán necesarios en la descripción y estructura de la tabla. Veamos las Fichas de tareas para cada una de las restantes tablas previstas:

Por último en nuestra empresa hay varios vendedores y deseamos asociar a cada pedido que nos realicen, a un vendedor, sólo de este modo, podremos llevar un control de comisiones a pagar a los vendedores, cifras acumuladas de ventas por vendedor...

Codificación de los elementos

Como ya se ha comentado es muy importante codificar los elementos que se encuentran en una tabla. Asignar a cada uno un código.

Para nuestra aplicación, cada elemento de cada tabla (cada registro) deberá poseer un código, y en aquella tabla en la que se desee tener acceso a información de otro elemento o registro de otra tabla (vinculada con ésta primera según nuestro diagrama de bloques) también deberá tener un campo código que enlace o se relacione con el primero.

La pantalla de relaciones en Access, al final del análisis, quedará definida como la que se muestra a continuación (no es necesario comprenderla en este punto):

Pero, estudiemos en secuencia y desde el principio, como llegar a estas relaciones...

Para evitar las duplicaciones innecesarias de información:

Las tablas maestras de nuestra aplicación contienen la información de Clientes, Productos, Proveedores, Vendedores, Agencias...

Eliminemos por lo tanto de la tabla de Pedidos la información que ya se tiene en las tablas maestras:

Pero será necesario, hacer constar en el registro de cada pedido, alguna información que nos permita saber qué cliente hace ese pedido. Ninguna información mejor que ese dato que identifica inequívocamente a cada cliente: Su código, su IdCliente.
Habrá que anotar también la información que identifica de forma precisa al vendedor que efectúa la venta. Ese campo será el IdVendedor.
Habrá que anotar también, qué producto es pedido por lo que habrá que anotar tan solo el código del artículo es decir el IdProducto.

Esos campos comunes en ambas tablas van a ser la base de las RELACIONES.

Establecer las relaciones

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:

Conclusión

Llegados a éste punto de nuestro análisis, ya se tendría definida:

- Una base de datos.
- En ella tendríamos definidos unos objetos llamados tablas con la estructura pertinente de campos.
- Entre esas tablas estarían definidas las relaciones necesarias mediante sus campos clave.

Nos encontramos ahora en el punto de partida para comenzar a trabajar con MS Access.

Sentadas estas bases primordiales para el correcto análisis de una aplicación Access pasamos en el siguiente capítulo a definir las tablas así como las relaciones pertinentes entre ellas.

Posteriormente, a lo largo de éste curso, deberemos diseñar y definir una interfaz de usuario básica, es decir, los formularios necesarios para que el usuario sea capaz de sacar el partido preciso a la información contenida en la tablas de la forma más intuitiva y sencilla. El diseño de una buena interfaz (pantallas intermediarias entre el usuario y los datos) constituirá la base para un manejo sencillo de la aplicación, incluso por usuarios que, quizás no sepan nada de Access ni de gestión de bases de datos.

Mas tarde habrá que construir realmente la Aplicación (apartado muy técnico y milimetrado): Los enlaces de las consultas, los datos, crear las automatizaciones que se asignarán a botones en los formularios. Habrá que crear las macros, quizás escribir y aprender a interpretar código en Visual Basic...

Para terminar, todo este complejo "mecanismo" llamado aplicación, deberá ser testado, es decir, deberemos verificar su correcto funcionamiento. Habrá que depurarlo, habrá que revisarlo.
También con su uso, será susceptible de una introducción de mejoras.