c
 



  

   
¡IMPORTANTE!
Esta parte del primer capítulo aporta unas reflexiones básicas y fundamentales para comprender
posteriormente el resto de los contenidos de este curso con la claridad necesaria. Nos hará ser
capaces de comprender lo importante que es la fase de análisis para la realización de cualquier
aplicación Access.

     


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

à Desde el origen de un planteamiento de trabajo con manejo de información y  al

estilo tradicional (sin ordenadores) ...
à Nos guíen hasta tener bien definidas las  para Access así como sus  
 
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 
 será una tarea sencilla y en otras el resultado de muchísimas
reflexiones.

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

à c
 
   
à ^     
 
à          
   
à á  
   
  
! 
à   
  
à   
   
  
 
à Œ 

     
à j
 
     

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

Análisis, planificación y estructuración de una Base de Datos (I): Objetivo y Fases del proceso.

c
 
   

" # $j 
 

       #   
%
 c

 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.

^     

 

 #     

 
     
  c

 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    
& las 'c^j^ de trabajo pueden ser las
siguientes:

à R


„

  

  



à R


V „ 
  

  



à R


?

  

  


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

à R


¢   
  

  


à á
„


 


 

Si se trabaja con varias agencias de transporte y se desean controlar las expediciones de

mercancía...

à R


V
„
V  V? 

  

  


 

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

à R


? ¢  

  

  

à j
 
 „
 
  
 

à Œ 

V 

 

  

 
 
 
 



 
  
 

 

 

 
 

 


 

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:
 à R
 
 
 

à ]



à è
   

 
à è


  
à Œ


 

 




    

Œonfeccionar un    (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): á  

       
  
    #
!  Œlientes, 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    
& , los    
 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.

'
! 
! 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 
!,
en Access, se les denomina registros). Œada ficha o registro contiene a su vez un conjunto de
 alojados en unos espacios o lugares denominados campos.

Œada   (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. Œada ficha,
a su vez, contendrá mas o menos
 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  
      de mantenimiento sobre los datos de un archivo son:

à c (agregar nuevos registros -nuevos clientes, nuevos proveedores,,,)

à  (eliminar registros del archivo (baja de un cliente, baja de un artículo por ser
descatalogado...)
à Œ  (buscar el precio de un determinado artículo, el teléfono de un cliente...
à % 

  (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 
! 
! (
.
à Para el mantenimiento de pedidos el 
! 
!  .

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

à Para el mantenimiento de vendedores el 

! 
!    .

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 

! 
! 
.

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

à Para el mantenimiento 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 '
! 
! 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   básicamente:

à c
!%  Œontienen 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. j 
 
 

Œ

 

  
 

à c
!   %     Sus registros tienen una vida corta dentro del
proceso, porque van cambiando con el propio proceso. Actualizan a los ficheros
maestros. j 
 

  ! 


 

 
"
#
 "
Œ




 

"



 "$


 %

  

   
    

    !



 
  
   "  
     

%
  

    
      
  
   


 
  
"

à c
! !
 Œontienen 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. j 
      

 &  Œ


&   &  
 &  
  & 
"

  
  

    
 

 
 
 !   
 

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

  
   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 .
Dichas tablas, son estructuras de filas y columnas que albergan  referidos a un mismo tema.
Œada fila llamada ahora   contiene la información que antes estaba plasmada en una ficha
del fichero. Œada columna de una tabla representa un
. 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 .

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

Ñ  

''''' 
$   '''''( 
$

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

 
!  ^   
 c

 )
Œlientes Œ  
Artículos 

Pedidos  
Proveedores   
Agencias de Transporte c

Vendedores de la empresa *   
Los á   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:   
  
 

     
 

    
  
  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 "%c á
c· j
c)^.


 
 
   

Œuando 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:

  Πj


  
IdPedido Número del pedido.
IdŒliente Número o código de cada cliente.
Œodcli Número o código de cada cliente.
IdProducto Œódigo único de cada artículo.
Œódigo único de cada artículo o
Œodprodu
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 ŒON duplicados.

De una sentada reflexión de sobre qué informaciones nos interesa gestionar sobre cada una de las
fases o  , es decir, de cada uno de los ficheros contemplados, es decir de
  
 , obtenemos, por ejemplo, las siguientes conclusiones que vamos a plasmar en un
modelo de documento denominado 'áŒcj)c"jc^ (una para la gestión de pedidos, otra para
productos, para clientes, para agencias, vendedores, proveedores...)

'
!  

    Introducción y gestión de pedidos

    
 

  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.

Œ
 
 + 
   ,
Œc% j^Œ"áŒá
á  Identificador único para el pedido
'
!  Fecha en la que se realiza el pedido
'
!j   Fecha en la que se entrega el pedido al cliente
'
!j ( Fecha en la que sale el pedido del almacén
Trabajamos con diferentes empresas para
'j (
realizar los envíos de los artículos
Œ Precio que nos cuesta mandar el envío
ጠ Identificador único del cliente
Nombre de la compañía o empresa que nos
 Œ(
hace el pedido.
Nombre de la persona que nos ha hecho el
 Π

pedido


 Dirección del cliente

Œ Œiudad del cliente
"  Œiudad del cliente
ΠΗdigo Postal del cliente.
( País del cliente
Empresa que va a recibir el pedido. Aunque no
   es frecuente puede ser otra en la que entregar
el pedido, otra sede.
Dirección dónde el cliente quiere que vaya el


   
pedido.
Œ   Œiudad a la que va a ir el pedido
"     Región a la que va a ir el pedido.
Œ   Œódigo postal del lugar a dónde va el pedido.
   País a la que va a ir el pedido.
á
 Identificador del producto
 
 Nombre del producto
Precio que se negocia en el momento de hacer

$ 
cada pedido
Número de unidades que vamos a servir al
Π
cliente del producto.
Descuento que se aplica y que se negocia en
 
 
el momento de hacer el pedido
Identificador del empleado que recoge el
áj 
pedido
 j  Nombre del empleado que recoge el pedido

Œomo vemos, aparecen datos sobre el  , sobre el

  que hace el pedido, sobre
la 
    que realiza en envío de ese pedido, sobre el (
 que se pide
(inicialmente plantearemos que cada pedido solo es de un artículo), y también sobre el comercial o
    de la empresa que genera ese pedido...
  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   '
!   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 c

 que es un       

  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 IdŒliente), 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, 

   '
!     
 
 
        
  (
 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   (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:

'
!  

   : Introducción y gestión de Productos

   

 

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


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

Œc% j^Œ"áŒá
IdProducto Identificador único del producto
NombreProducto Nombre del producto
Número de unidades que hay en una
ŒantidadPorUnidad
caja del producto.
PrecioUnidad Precio de cada unidad del producto.
Ηdigo del proveedor que suministra
este producto. Este campo se
IdProvee relacionará con el código de proveedor
(IdProveedor) en la tabla de
proveedores.

Ficha de la Tabla Œlientes.

'
!  

   : Introducción y gestión de Œlientes

   Π 
 

  Por cada cliente de nuestra empresa, se guardarán en campos las
informaciones consideradas como esenciales, para su correcto control.
Œ
 
 
Œc% j^Œ"áŒá
IdŒliente Identificador único del cliente
Nombre de la compañía o empresa
NombreŒompañía
cliente.
Nombre de la persona con la que
NombreŒontacto
hemos contactado.
Œargo que tiene la persona con la que
ŒargoŒontacto
contactamos, en la empresa cliente.
Dirección Dirección del cliente
Œiudad Œiudad del cliente
Región Región del cliente
ŒódPostal Œódigo Postal del Œliente
País País del cliente
Teléfono Teléfono del cliente
Fax Fax del cliente

Ficha de la Tabla Agencias.

'
!  

   : Introducción y gestión de métodos de envío (agencias de transporte)

   c

 

  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.
Œ
 
 
Œc% j^Œ"áŒá
Identificador único de la compañía de
IdŒompañiaEnvíos
envíos
NombreEnvíos Nombre de la compañía de envíos
Número de teléfono de la compañía de
Teléfono
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...

'
!  

   : Introducción y gestión de vendedores

   *   
 

  Por cada vendedor o comercial, se guardarán en campos las informaciones
consideradas como esenciales, para su correcto control.
Œ
 
 
Œc% j^Œ"áŒá
IdEmpleado Identificador único del empleado
Nombre Nombre del empleado.
Apellidos Apellidos del empleado.
Œargo Œargo que tiene el empleado.
Tratamiento Ηmo dirigirnos a el
FechaNacimiento Fecha de nacimiento del empleado
FechaŒontratación Fecha de contratación del empleado
ŒódPostal Œódigo Postal del Œliente
Dirección Dirección del empleado
Œiudad Œiudad donde vive el empleado
Región Región del empleado
ΗdPostal Ηdigo postal del empleado
País País dónde vive
TelDomicilio Teléfono del empleado
Extensión telefónica que tiene el
Extensión
empleado en la empresa.
Foto Foto del empleado
Notas Œomentarios sobre el empleado
Jefe jefe del que depende.

Ficha de la Tabla Proveedores.

'
!  

   : Introducción y gestión de Proveedores

     
 

  Por cada proveedor que nos suministra productos, se guardarán en campos
las informaciones consideradas como esenciales, para su correcto control.
Œ
 
 
Œc% j^Œ"áŒá
IdProveedor Identificador único del proveedor
Nombre de la compañía o empresa
NombreProveedor
proveedora.
Nombre de la persona con la que
NombreŒontacto
hemos contactado.
Œargo que tiene la persona con la que
ŒargoŒontacto contactamos, en la empresa
proveedora.
Dirección Dirección del proveedor
Œiudad Œiudad del proveedor
Región Región del proveedor
ΗdPostal Η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.

Π

     

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

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

à Œ 

  

   Œonsiste 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. ^  
  )*+



  
!, 
  

à Œ 

  


     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. G  ! 
  ! 
 
  -*.   
 
  !      
 


 El
campo podría definirse como numérico.

à Œ 

  Œonsiste 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... -./0/1/-/-0200015155. 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.

à Œ 

  &

 Es igual que la de por grupos solo que aparecen partes del
código representadas con letras. supongamos una cuenta corriente (ŒŒ) de Œaixa de
Œataluña (Œ Œ), de Logroño (LO)... ŒŒ .-ŒŒ00015155. 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.

j
 
     

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 Œlientes, 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 ጠ .

Habrá que anotar también la información que identifica de forma precisa al vendedor que efectúa la
venta. Ese campo será el á*  .

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 á
.
Esos campos comunes en ambas tablas van a ser la base de las "j c· j^.

j
 
 

Si en la tabla de pedidos, al introducir un pedido se anota el ጠ del cliente que formula el
pedido, como en la tabla maestra de clientes cada cliente viene identificado por su IdŒliente (el
nombre del campo no es necesario que coincida), el registro con ESE ጠ 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 ác(

, para los vendedores con el campo
á*  , 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   2. En el lado de la relación de aquella tabla en donde para
ese campo ( se puedan producir valores repetidos para varios registros ese campo Id será
  2(Π
, y en la tabla para la que  se puedan dar duplicidades para los
valores de ese campo, éste quedará definido como   2(^á 
.

En la relación si ésta se define con    

, esto se representa con un 1 y un
símbolo de infinito respectivamente para representar el SIN y el ŒON 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"j^)3

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:

Œada pedido tiene un numero de pedido definido por el campo IdPedido.  



%-/


 

á 0-/

En una tabla aparte, por ejemplo denominada     , 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 Œ ^á 
 (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      , 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):
Analizando las Relaciones paso a paso (Parte I).

Analizando las Relaciones paso a paso. (Parte II) La Tabla Detalles de Pedidos.

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:
Œ
 
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    así como las  
  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 c


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