Uso De Acces: Ejemplo de uso de acces

Realizar un BUEN análisis de la situación real de trabajo que se desea automatizar mediante Microsoft Access. Solo si se conocen a fondo (ordenadores aparte) los mecanismos de gestión, formas de trabajo, archivos de información (ficheros tradicionales en los que se almacenan los datos), documentos aplicables a las tareas (hojas de factura, talonarios de albaranes), así como listados (resúmenes diarios, semanales o mensuales) y formatos utilizados en ese determinado ámbito a automatizar, es posible trasladar a un entorno informático dicha operativa. Qué se hace y que se pretende hacer. En programación informática, esta misión la llevan a cabo los llamados analistas de aplicaciones, los cuales se sumergen físicamente en dicha actividad de la empresa o entidad correspondiente hasta que conocen a fondo su mecánica de trabajo en el día a día.

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.

Otros análisis propuestos:
Pensar en las fases a gestionar para cada una de las siguientes actividades propuestas, después de "pegarse como una lapa" a los profesionales de ese ámbito y conocer así los trabajos, las necesidades, las situaciones, las particularidades, etc... "Meterse en el papel" de quien, sin informática de por medio, desarrolla diariamente esa o esas tareas que se desean automatizar, en este caso mediante Access:

Multas de tráfico de un ayuntamiento.
Gestión de un video club.
Una academia de enseñanza.
Una inmobiliaria.
Control del gasto por consumo de electricidad en un pueblo.

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:

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, a saber, 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.

Fichero o archivo: Bolsa o bloque de información homogénea y referida a un mismo tema (por ejemplo los clientes de una empresa), y a su vez organizada en fichas (a las tradicionales fichas, en Access, se les denomina registros). Cada ficha o registro contiene a su vez un conjunto de datos alojados en unos espacios o lugares denominados campos.
Cada registro (o ficha) contiene por lo tanto, un conjunto de datos referidos a un elemento dentro del fichero. Por ejemplo, en un fichero de clientes, cada cliente tiene su ficha o registro. Cada ficha, a su vez, contendrá mas o menos campos según el nivel de control y gestión de información deseado, y dichos campos albergarán todos los datos del cliente que son necesarios para desarrollar las tareas propias de la actividad.

Siempre, las operaciones fundamentales de mantenimiento sobre los datos de un archivo son:

Altas (agregar nuevos registros -nuevos clientes, nuevos proveedores,,,)
Bajas (eliminar registros del archivo (baja de un cliente, baja de un artículo por ser descatalogado...)
Consultas (buscar el precio de un determinado artículo, el teléfono de un cliente...
Modificaciones (cambio de precio en un artículo, de dirección de envíos de un cliente...)

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.

Los Ficheros o archivos dependiendo del tipo de información que contienen, su peso específico dentro de la gestión, las tareas en las que están implicados, si sirven para actualizar a otros archivos o no, su duración en el tiempo... Pueden ser de tres tipos básicamente:

Archivos Maestros: Contienen la información principal para el proceso. Su duración en el tiempo es la del propio proceso y sus datos son actualizados por los archivos de movimiento y los maestros a su vez, actualizan a los archivos históricos. (Ejemplos de este tipo de archivo serán los de Clientes, proveedores, artículos, empleados y agencias)
Archivos de Movimiento o maniobra: Sus registros tienen una vida corta dentro del proceso, porque van cambiando con el propio proceso. Actualizan a los ficheros maestros. (Ejemplos de este tipo de archivo serán los de Pedidos ya que actualizan, por ejemplo al de artículos -en sus existencias- y al de Clientes en su volumen de compras acumulado -de tener definido este concepto en dicho archivo-. A fin de mes, los pedidos se reúnen por cliente, se facturan y se pasan al histórico de pedidos, quedando eliminados de la tabla de pedidos -otra opción es marcar mediante algún campo los pedidos facturados en vez de trasvasarlos a un histórico y eliminarlos del archivo de pedidos-)
Archivos históricos: Contienen registros que, en su momento, pertenecieron a los archivos maestros o de movimiento y que fueron anexados a estos archivos como datos históricos. Archivos que contienen registros que fueron actuales pero que en vez de ser eliminados se almacenan en este tipo de archivo como medida de seguridad y almacén de datos históricos. (Ejemplos de este tipo de archivo serán los Históricos de Clientes, Histórico de proveedores, Histórico de artículos, Histórico de empleados, Histórico de pedidos...-no los hemos reflejado en nuestro diagrama ni en la aplicación que vamos a desarrollar en este curso-) ¿Quien sabe si a fecha del año que viene necesitamos contactar con un cliente o un proveedor que lo fue nuestro, pero que a esa fecha ya no lo es? Su información será encontrada en los archivos históricos.

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 una base de datos, las estructuras básicas, los OBJETOS principales sin los cuales no pueden existir el resto de objetos de Access tales como consultas, formularios, informes y macros, son LAS TABLAS. Suponen el pilar fundamental en el diseño general de un sistema de base de datos relacional (que se basa en las relaciones entre las tablas).

Fichero o archivo tradicional >>>>> (en Access pasa a ser) >>>>> Tabla de Access

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

Para el archivo de...	Se definirá en Access...	La Tabla...
Clientes		Clientes
Artículos		Productos
Pedidos		Pedidos
Proveedores		Proveedores
Agencias de Transporte		Agencias
Vendedores de la empresa		Vendedores

Los Informes son diseños para obtener por impresora (también llamados listados), que se nutren de las informaciones que están (se encuentran) en las tablas.

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.

La importancia de codificar los elementos.

Cuando se manejan archivos en donde se alberga la información de ciertos elementos (clientes, artículos, pedidos, -en otros procesos: vehículos, alumnos, lecturas de contador, pacientes- ...) es MUY IMPORTANTE codificar dichos elementos asignando a cada uno un código (numérico o alfanumérico) que identifique exacta, única e inequívocamente a cada elemento del archivo de modo que no puedan existir dos códigos completos que se repitan en dicho archivo.

Estos códigos también se llaman identificadores y suelen recibir en las definiciones de las tablas nombres tales como:

Nombre del Campo	El campo contiene...
IdPedido	Número del pedido.
IdCliente	Número o código de cada cliente.
Codcli	Número o código de cada cliente.
IdProducto	Código único de cada artículo.
Codprodu	Código único de cada artículo o producto.

Los códigos (este tipo de campo), son los campos que posteriormente van a permitir enlazar o relacionar dos tablas cuya información se desea utilizar conjuntamente en un proceso o fase de la aplicación. Generalmente aunque no siempre, se relacionan dos tablas mediante campos de código.

Hablando en términos de Access, éstos campos deberán tener la propiedad de indexado = Sí y con o sin duplicados según proceda. Por ejemplo, la tabla de Pedidos se relacionará con la de Artículos (productos) mediante el código del artículo. Tanto en una tabla como en otra, deberán ser campos indexados aunque como es lógico, en la tabla de Artículos un mismo código NO se puede repetir (indexado Sí y SIN duplicados -puede ser y deberá ser clave principal

), mientras que en la tabla de Pedidos podremos tener un determinado artículo pedido varias veces por lo que será indexado Sí pero CON duplicados.

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...)

Ficha de tareas
Nombre de la tarea: Introducción y gestión de pedidos Nombre de la tabla: Pedidos Descripción: En cada pedido quedará recogida toda la información necesaria para posteriormente poder facturar (datos del cliente), que volumen de facturación se aplica a cada vendedor (datos del vendedor), cuántos pedidos se tramitan a través de tal compañía de envío (agencia de transporte)... Por lo tanto, inicialmente, constarán datos referidos a todos estos elementos.
Campos necesarios para llevar a cabo la tarea (el control de los pedidos):
CAMPO		DESCRIPCIÓN
IdPedido		Identificador único para el pedido
FechaPedido		Fecha en la que se realiza el pedido
FechaEntrega		Fecha en la que se entrega el pedido al cliente
FechaEnvío		Fecha en la que sale el pedido del almacén
FormaEnvío		Trabajamos con diferentes empresas para realizar los envíos de los artículos
Cargo		Precio que nos cuesta mandar el envío
IdCliente		Identificador único del cliente
NombreCompañía		Nombre de la compañía o empresa que nos hace el pedido.
NombreContacto		Nombre de la persona que nos ha hecho el pedido
Dirección		Dirección del cliente
Ciudad		Ciudad del cliente
Región		Ciudad del cliente
CódPostal		Código Postal del cliente.
País		País del cliente
Destinatario		Empresa que va a recibir el pedido. Aunque no es frecuente puede ser otra en la que entregar el pedido, otra sede.
DirecciónDestinatario		Dirección dónde el cliente quiere que vaya el pedido.
CiudadDestinatario		Ciudad a la que va a ir el pedido
RegiónDestinatario		Región a la que va a ir el pedido.
CódPostalDestinatario		Código postal del lugar a dónde va el pedido.
PaisDestinatario		País a la que va a ir el pedido.
IdProducto		Identificador del producto
NombreProducto		Nombre del producto
PrecioUnidad		Precio que se negocia en el momento de hacer cada pedido
Cantidad		Número de unidades que vamos a servir al cliente del producto.
Descuento		Descuento que se aplica y que se negocia en el momento de hacer el pedido
IdEmpleado		Identificador del empleado que recoge el pedido
NombreEmpleado		Nombre del empleado que recoge el pedido

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...

Nota: Se han asociado colores a cada uno de los campos para saber a que tabla de las analizadas corresponde. Desde <AQUÍ> se puede descargar el modelo de Ficha de tareas en formato Word para poder confeccionarlas.

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:

Ficha de tareas
Nombre de la tarea: Introducción y gestión de Productos Nombre de la tabla: Productos Descripción: Por cada producto o artículo de nuestro almacén, se guardarán en campos las informaciones consideradas como esenciales, para su correcto control. Fijémonos ahora que en el registro de cada producto consta SOLO el código de su proveedor. Observar que según el diagrama de bloques, la tabla de artículos está relacionada con la de proveedores mediante el campo código de proveedor (IdProveedor de esta tabla de Productos <= se relaciona con => IdProveedor de la tabla de Proveedores). Si tuviéramos que almacenar en el registro de cada artículo, todos los datos del proveedor, si en la tabla de productos tuviéramos 1.000 artículos o referencias del mismo proveedor, tendríamos 1.000 veces en la tabla de productos toda la información de ese proveedor. Las relaciones entre tablas solventan estos inconvenientes mejorando el aprovechamiento en disco y optimizando la velocidad del proceso.
Campos necesarios para llevar a cabo la tarea:
CAMPO		DESCRIPCIÓN
IdProducto		Identificador único del producto
NombreProducto		Nombre del producto
CantidadPorUnidad		Número de unidades que hay en una caja del producto.
PrecioUnidad		Precio de cada unidad del producto.
IdProvee		Código del proveedor que suministra este producto. Este campo se relacionará con el código de proveedor (IdProveedor) en la tabla de proveedores.

Ficha de la Tabla Clientes.

Ficha de tareas
Nombre de la tarea: Introducción y gestión de Clientes Nombre de la tabla: Clientes Descripción: Por cada cliente de nuestra empresa, se guardarán en campos las informaciones consideradas como esenciales, para su correcto control.
Campos necesarios para llevar a cabo la tarea:
CAMPO		DESCRIPCIÓN
IdCliente		Identificador único del cliente
NombreCompañía		Nombre de la compañía o empresa cliente.
NombreContacto		Nombre de la persona con la que hemos contactado.
CargoContacto		Cargo que tiene la persona con la que contactamos, en la empresa cliente.
Dirección		Dirección del cliente
Ciudad		Ciudad del cliente
Región		Región del cliente
CódPostal		Código Postal del Cliente
País		País del cliente
Teléfono		Teléfono del cliente
Fax		Fax del cliente

Ficha de la Tabla Agencias.

Ficha de tareas
Nombre de la tarea: Introducción y gestión de métodos de envío (agencias de transporte) Nombre de la tabla: Agencias Descripción: Por cada agencia de transporte con la que trabajamos y enviamos los pedidos, se guardarán en campos las informaciones consideradas como esenciales, para su correcto control.
Campos necesarios para llevar a cabo la tarea:
CAMPO		DESCRIPCIÓN
IdCompañiaEnvíos		Identificador único de la compañía de envíos
NombreEnvíos		Nombre de la compañía de envíos
Teléfono		Número de teléfono de la compañía de envíos

Ficha de la Tabla Vendedores.

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...

Ficha de tareas
Nombre de la tarea: Introducción y gestión de vendedores Nombre de la tabla: Vendedores Descripción: Por cada vendedor o comercial, se guardarán en campos las informaciones consideradas como esenciales, para su correcto control.
Campos necesarios para llevar a cabo la tarea:
CAMPO		DESCRIPCIÓN
IdEmpleado		Identificador único del empleado
Nombre		Nombre del empleado.
Apellidos		Apellidos del empleado.
Cargo		Cargo que tiene el empleado.
Tratamiento		Cómo dirigirnos a el
FechaNacimiento		Fecha de nacimiento del empleado
FechaContratación		Fecha de contratación del empleado
CódPostal		Código Postal del Cliente
Dirección		Dirección del empleado
Ciudad		Ciudad donde vive el empleado
Región		Región del empleado
CódPostal		Código postal del empleado
País		País dónde vive
TelDomicilio		Teléfono del empleado
Extensión		Extensión telefónica que tiene el empleado en la empresa.
Foto		Foto del empleado
Notas		Comentarios sobre el empleado
Jefe		jefe del que depende.

Ficha de la Tabla Proveedores.

Ficha de tareas
Nombre de la tarea: Introducción y gestión de Proveedores Nombre de la tabla: Proveedores Descripción: Por cada proveedor que nos suministra productos, se guardarán en campos las informaciones consideradas como esenciales, para su correcto control.
Campos necesarios para llevar a cabo la tarea:
CAMPO		DESCRIPCIÓN
IdProveedor		Identificador único del proveedor
NombreProveedor		Nombre de la compañía o empresa proveedora.
NombreContacto		Nombre de la persona con la que hemos contactado.
CargoContacto		Cargo que tiene la persona con la que contactamos, en la empresa proveedora.
Dirección		Dirección del proveedor
Ciudad		Ciudad del proveedor
Región		Región del proveedor
CódPostal		Código Postal del proveedor
País		País del proveedor
Teléfono		Teléfono del proveedor
Fax		Fax del proveedor

¡MUY IMPORTANTE!
En resumen, aquella información, que a priori, parezca que debe pertenecer a una tabla (con lo que tendríamos que definir campos para guardarla), si, pensando en miles de registros para esa tabla observamos que el contenido de ciertos campos se repite muchas veces, esos campos cuya información redunda, deberemos "sacarlos" a otra tabla aparte y codificar (asignar códigos) a esos elementos o registros de tal forma que al final, establezcamos una relación entre esas dos tablas mediante sus códigos.

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

Tipos de codificaciones: Existen diferentes métodos para codificar los elementos de un archivo o, en Access, de una tabla. Podríamos resumirlos en los siguientes:

Codificación secuencial simple: Consiste en asignar a cada elemento un número secuencial ascendente, con lo que cada uno tendría un número diferente de forma garantizada. En Access se definiría un campo de tipo autonumérico. Este tipo de código identifica inequívocamente a un registro o elemento, pero no es representativo, porque no nos aporta información sobre de qué elemento se trata. Si vemos el código 325 no nos dice nada sobre, por ejemplo de qué artículo se trata.
Codificación secuencial con reservas: Se asignan códigos, reservando rangos de números para elementos de diferentes familias. Así por ejemplo en una tabla de productos, los que tienen código del 1 al 100 son de camisería. Los del 101 al 200 pantalones... Es decir, se reservan abanicos de códigos para diferentes familias, tipos de elementos. El inconveniente que tiene esta codificación es que hay que reservar los rangos a mayores, previendo un rango lo suficientemente grande como para no "pillarnos", es decir, si en algún momento de nuestra actividad comercializásemos mas de 100 modelos de camisas tendríamos que replantear toda la codificación de nuevo. Puede ser peligroso quedarse "corto" en las reservas. Lo positivo que tiene es que si vemos un código 126 podremos afirmar, al menos de que se trata de un pantalón. El campo podría definirse como numérico.
Codificación por grupos: Consiste en asignar códigos mas o menos largos en donde por grupos de caracteres dentro de ese código queda definida cierta información sobre el elemento. Por ejemplo, los números de cuenta de un banco: Bajo esos 20 dígitos de un número de cuenta, los 4 primeros definen la entidad bancaria, los 4 restantes otra información, los 2 siguientes tal otra... 20131612120200015155. Es una codificación muy significativa. El campo sería definido como de texto con máscara de entrada ya que no se va a operar matemáticamente con esos códigos.
Codificación mnemotécnica: Es igual que la de por grupos solo que aparecen partes del código representadas con letras. supongamos una cuenta corriente (CC) de Caixa de Cataluña (CXC), de Logroño (LO)... CXCLO02CC00015155. También este campo, sería definido, evidentemente como de texto.

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.

Análisis, planificación y estructuración de una Base de Datos (II): Análisis de Tareas y Archivos de Datos.

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 vamos a estudiar, paso a paso y desde el principio, cómo 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 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.

Inscríbete, comienza ahora y si es lo que necesitas, lo compras y continuas... Una vez inscrito, te enviamos un email con los datos de acceso y puedes comenzar el curso de Access 2007 Aplicaciones realizando 3 unidades. Podrás acceder a videotuoriales, actividades multimedia, ejercicios prácticos, consultar al tutor, etc..

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):