1. Relacciones entre tablas de Access
Cuando relacionamos dos o más tablas en Access, lo que estamos haciendo es combinar
la información de todas las tablas relacionadas de forma que a partir de la información
obtenida en una tabla, podamos acceder a la información de otra, que de algún modo
tiene algo en común con la primera.
Vamos a seguir desarrollando la aplicación de base de datos que ya iniciamos
anteriormente. La base de datos discoteca.
La finalidad de esta base de datos es, en última instancia, disponer de una relación o
lista de los título disponibles, pudiendo aumentar o disminuir el tamaño añadiendo
nuevos títulos o borrándolos de la lista. O simplemente modificando parte de alguno de
los registros que ya existe,
También queremos que nuestra base de datos mantenga un control de los préstamos que
se hace a los socios. Para ello, inicialmente, podríamos pensar en crear un registro para
cada uno de los préstamos y no complicarnos más la vida.
Un registro de estas características podria ser:
Nº Socio NIF Nombre Apellidos Dirección Población C. Postal
Provincia Prestamo1 Prestamo2 Prestamo3 Prestamo4 Fecha Devuelto
Préstamo (S/N)
Fecha
devolución
Bueno, pues podría ser. Pero este sistema, que ciertamente es bastante simple, tiene
algunos inconvenientes.
Si el socio en cuestión quiere que se le presten cuatro títulos en vez de máximo tres, que
es lo que soporta el registro tal y como se ha definido, pues hay un problema: habría que
rehacer la tabla y añadir un campo más que albergara ese dato.
Podemos pensar: vale, lo que hacemos es restringir inicialmente el número de títulos a
prestar a cada socio. Pensemos en tres como máximo y así la tabla anterior nos sirve
perfectamente.
Pues vale también. Pero si por costumbre los socios suelen llevar prestados uno o dos
titulos como máximo, pensemos en la cantidad de campos vacíos que vamos a tener que
gestionar más adelante. Y el espacio que ocupan.
Pensemos también en el gran tamaño que vamos a necesitar para introducir toda la
información requerida. Si un socio es muy habitual y visita nuestro negocio cada dos
días en busca de nuevos títulos, por cada préstamo que realicemos a esta persona
tendremos que repetir el nº de socio, nif, nombre, apellidos, dirección completa...
cuando lo único que varía con el registro precedente del mismo socio es el título de los
CD’s que solicita y la fecha de préstamo.
Además la repetición de tanta información nos va a garantizar casi seguro, que vamos a
cometer algún error al cumplimentar tanto dato.
Javier Fernández Castelo Pág 1 6 de mayo de 2012

2. De todo esto, se desprende que debemos estructurar la información de forma que
podamos evitar todos los inconvenientes arriba expuestos.
La estructura de la que se habla es las relaciones entre tablas.
Podemos establecer tres tipos de relaciones entre tablas y/o consultas:
Relación Uno Uno: es poco probable que utilicemos este tipo de relaciones pero si lo
hacemos, será para dividir en varias una tabla con muchos campos, o bien porque
queremos aislar parte de la información de una tabla creando otra, relacionada de esta
manera por motivos de seguridad o para almacenar datos de una parte de los registros de
la tabla. Piensesé en el subconjunto de empleados de una empresa que además trabajan
en otra: son pluriempleados y
necesitamos almacenar esa
información.
La relación uno a uno, otorga a cada
registro de una tabla un único registro
en la otra relacionada y viceversa. Es
decir, las dos tablas tendrán registros
únicos en su seno pero las dos tienen
algún dato común. Los campos relacionados deben ser campos únicos.
En el trabajo que nos ocupa: la base de datos Discoteca, tenemos una relación de socios.
Cada registro corresponde a un único socio, luego cada uno de estos registros es único.
Por otra parte, de estos socios, hay algunos que realizan donaciones de material, pero no
todos ellos. La tabla mecenazgo relaciona mediante un campo idéntico al de la tabla
clientes, aquellos que realizan donaciones. También en esta tabla los mecenas que
aparecen en la relación son únicos, solo aparecen una vez. Fijémonos que no hemos
necesitado repetir el nombre y apellidos de los mecenas, estos ya están en la tabla
Socios.
Relación Varios a Varios: Este tipo de relación, se va a caracterizar porque cada
registro de una tabla A puede estar relacionado con varios registros de la tabla B y cada
registro de la tabla B con varios de la tabla A.
Para conseguir este tipo de relación, en Access es necesario disponer de una tabla
“Puente”:
Pensemos en la siguiente relación: en una fábrica, un pedido puede estar relacionado
con varias piezas (referencias) de producción y, al a vez, una pieza (una referencia),
puede estar
relacionada
con varios
pedidos.
Esto que es
tan habitual
en Access se
realiza con
una tabla
puente que
Javier Fernández Castelo Pág 2 6 de mayo de 2012

3. podemos denominar Detalle de pedido.
En nuestro ejemplo, un mismo CD-Rom ha podido ser prestado durante cierto tiempo
en varios domicilios y al mismo tiempo, un solo domicilio ha podido solicitar varios
CD-ROM. La relación en este caso contempla una tabla puente llamada Prestamos, que
hace de nexo.
Relación Uno a Varios.: es la relación más habitual. En esta, un registro perteneciente
a una tabla A está relacionado con varios registros de otra tabla, tabla B. En la imagen
anterior, la tabla Titulos está relacionado con la tabla Prestamos de forma que un Titulo
puede ser solicitado en varios préstamos.
El campo que se va a relacionar con varios, ha de ser un campo llave o único.
Si tratamos de relacionar dos tablas mediante campos en que ninguno de los dos es
clave principal o llave , la relación creada es Indeterminada.
Dentro de las relaciones entre tablas de una base de datos, es necesario conocer que se
entiende por “Exigir integridad referencial.”
Exigir integridad referencial es un mecanismo que evita que se borren registros de
forma accidental.
Debe cumplir varias condiciones:
La tabla principal, contendrá el campo clave y será la parte “uno” de una relación “uno
a varios”. Esto significa que ese campo clave ha de ser único, sin duplicados.
Los campos relacionados de dos tablas han de tener el mismo tipo de datos.
Las tablas han de pertenecer a la misma base de datos. Si son tablas vinculadas no se
puede modificar su estructura desde esta.
• No puede introducir un valor en el campo de clave externa de la tabla
relacionada que no exista en la clave principal de la tabla principal. No obstante,
puede introducir un valor Nulo en la clave externa, especificando que los
registros no están relacionados. Por ejemplo, no puede tener un pedido asignado
a un cliente que no existe, pero puede tener un pedido asignado a nadie mediante
la introducción de un valor Nulo en el campo Id. de cliente.
• No puede eliminar un registro de una tabla principal si existen registros
coincidentes en una tabla relacionada. Por ejemplo, no puede eliminar un
registro de empleados de la tabla Empleados si existen pedidos asignados al
empleado en la tabla Pedidos.
• No puede cambiar un valor de clave principal en la tabla principal si ese registro
tiene registros relacionados. Por ejemplo, no puede cambiar el Id. de un
empleado en la tabla Empleados si existen pedidos asignados a ese empleado en
la tabla Pedidos.
En cuanto a la actualización o eliminación de registros en cascada, significa que
eliminando el registro en el que se encuentra la clave principal, eliminamos todos
aquellos registros de la tabla relacionada que contengan esa misma clave externa
relacionada y a la hora de actualiza, lo mismo.
Por último, podemos contemplar tres tipos de combinación:
Incluir solo las filas donde los campos combinados de ambas tablas sean iguales
Javier Fernández Castelo Pág 3 6 de mayo de 2012

4. Incluir TODOS los registros de la tabla cuya relación es “uno” y solo aquellos
registros de la tabla cuya relación es “varios” donde los campos combinados sean
iguales.
Incluir TODOS los registros de la tabla cuya relación es “varios” y solo aquellos
registros de la tabla cuya relación es “uno” donde los campos combinados sean iguales.
Javier Fernández Castelo Pág 4 6 de mayo de 2012

5. Explicado todo lo anterior, pasemos a realizar un ejemplo que complemente un poco
más nuestra base de datos “Discoteca”.
Centrémonos en las tablas que vamos a necesitar para este ejemplo.
Habíamos creado anteriormente la tabla Títulos y habíamos introducido ya algunos
registros.
Ahora vamos a crear algunas nuevas tablas y vamos a ver como y porqué las
relacionamos unas con otras.
La siguiente tabla a crear va a ser la tabla “Préstamos”.
La estructura de esta tabla será la siguiente:
con esta tabla, se pretende controlar, a quien, cuando, cuanto tiempo han sido prestados
los discos que figuran en la tabla Titulos.
En esta tabla aparece el número de socio como receptor de cada volumen.
Podríamos haber confeccionado la tabla de manera que en ella figurara el nombre del
prestatario pero como ya dijimos en otra ocasión, sería redundante que cada vez que se
preste un disco a una persona tengamos que apuntar sus datos completos.
En vez de todos los datos de la persona que ha recibido un préstamo, hacemos
referencia a la misma mediante un código. Podría ser su DNI, ya que es por si mismo un
código único para cada persona. En este caso, podríamos haber opta optado por crear el
código “Número de socio”., mas corto y fácil de escribir.
De hecho, en un primer momento se optó por esa solución pero, más adelñante nos
surgió la idea de que no era el socio el que estaba directamente relacionado con el
préstamo. Más adelante veremos por qué
Pero lo expuesto hasta ahora, no nos da idea de quien tiene o ha recibido cada disco.
Necesitamos una nueva tabla que nos informe de quien es la persona que recibirá los
CD’s. La tabla a la que hacemos referencia es la que se indica más abajo, que hemos
llamado “Socios”.
Javier Fernández Castelo Pág 5 6 de mayo de 2012

6. Esta está “indirectamente” relacionada con la anterior, “Prestamos”
Un nuevo vistazo a la tabla recién construída, nos alerta de que es posible que algún
socio decida darnos dos o más domicilios diferentes donde enviar sus pedidos de forma
habitual (nuestro Club entrega a domicilio). Es por esto que modificamos la tabla
Socios, que inicialmente tenía los campos de Domicilio, C.P, Población y Provincia y al
mismo tiempo, vamos a crear otra nueva tabla que englobe estos datos para cada socio,
la tabla “Domicilios”, que quedará de esta forma:
Por último, existe una figura, que llamamos “mecenas” que de forma altruista dona una
cantidad en metálico para la adquisición de títulos o en algunos casos los propios CD’s.
Dada la estructura del negocio, en los estatutos se refleja que está prohibido revelar las
cantidades donadas, por lo que estas no van a aparecer en la base de datos. Solo
aparecerá el donante y las fechas de alta y baja. La estructura de esta nueva tabla la
vemos en la siguiente imagen
Javier Fernández Castelo Pág 6 6 de mayo de 2012

7. Con esta última tabla, que no tenía otro sentido que explicar las relaciones uno a uno,
concluímos con la creación de tablas necesarias por el momento para nuestro propósito:
crear una aplicación que controle los títulos de una colección y los prestamos efectuados
a los socios del Club.
Es el momento de mstrar con estarán relacionadas unas con otras.
Ya hems adelantado más arriba como irán relacionándose. Ahora vamos a ver como
hacerlo.
En la barra de herramientas
de Access, mientras no
tenemos abierto ningún objeto
de base de datos, aparece el
botón “Relaciones”. Pulsando
sobre él, aparece el cuadro
“Relaciones” donde vamos a “dibujar” aquellas que necesitamos.
En esta nueva imagen vemos el aspecto que
presenta este cuadro, así como la nueva barra de
herramientas que surge con él.
Como siempre, podemos descubrir cual es el
cometido de cada botón que aparece con solo
situar el puntero del ratón sobre el botón elegido
durante unos instantes. Esto hace que aparezca
una etiqueta mostrando la función de cada uno
de los objetos.
Javier Fernández Castelo Pág 7 6 de mayo de 2012

8. Pulsando sobre el botón “Mostrar Tabla”,
aparece un nuevo cuadro que contiene las
tablas de la base de datos. De estas, podemos
elegir aquellas que deseamos tengan relación
entre sí . para seleccionarlas, solo es
necesario pulsar doble clic sobre las
deseadas o bien seleccionarlas con un clic y
pulsar sobre el botón “Agregar”.
Seleccionadas aquellas que van a intervenir
y “dibujadas “ ya en el cuadro al efecto,
podemos comenzar a establecer cono relacionarlas no sin antes cerrar el cuadro de
diálogo que permanece abierto hasta que se lo indiquemos.
Relacionar dos tablas es tan sencillo como situarse en el campo (por el que deseamos
relacionar) de la representación de una tabla, pulsando con el botón izquierdo del
ratón,sin soltar el botón, arrastrar el puntero hasta el campo de la otra tabla que
relaciona ambas.
En la figura de la derecha, pretendemos
relacionar las tablas “Prestamos1” y
“Titulos1”. Además, queremos hacerlo a
través del campo clave “Indice”.
Pulsamos con el botón izquierdo del ratón
sobre el campo “Indice” de la tabla
“Prestamos1” y sin soltar, arrastramos hasta situal el puntero sobre el campo “Indice” de
la tabla “Titulos1”. Esta acción despliega un cuadro de dialogo como el que vemos a la
izquierda de este texto donde se nos permitirá gestionar esas relaciones.
En este caso, exigiremos integridad diferencial,
actualizar y eliminar registros en cascada y además
estableceremos el tipo de relación pulsando en el botón
“Tipo de combinación”.
Tras pulsar este, aparece un nuevo cuadro de dialogo, en
esta ocasión, nos muestra tres tipos de relaciones que se
pueden dar y que se muestran en la figura. Elegimos la
número dos, que es la que se adapta a nuestras
necesidades actuales y cerramos pulsando el botón
“Aceptar”.
Mediante esta acción, hemos relacionado las
dos tablas: “Titulos” y “Prestamos” mediante
el campo clave “Indice”.
Haremos notar que al relacionar mediante un
campo, este debe ser del mismo tipo de datos
en ambas tablas. No se relacionarán dos
tablas cuyos campos relacionados sean uno
numérico y el otro de texto, por ejemplo.
De la misma manera que hemos relacionado estas dos tablas, procederemos a relacionar
todas las demás, formando un entramado como el que aparece en la figura siguiente.
Javier Fernández Castelo Pág 8 6 de mayo de 2012

9. Este es el aspecto que tendrá el diagrama de relacciones.
Con estas, estamos asegurándonos, dadas las indicaciones hechas al programa, que se
exigirá que los datos relativos a campos de combinación, al menos sean correctos. No se
permiten errores al teclearlos. También aseguramos que eliminando un registro que
contiene una clave, eliminamos todos aquellos de otras tablas que esten relacionados
con esta clave. Del mismo modo, no tendremos que teclear el dato de un campo clave en
ambas tablas. Con hacerlo en la principal, el dato se inserta en la secundaris.
Para ver lo que ya hemos conseguido, sigamos con nuestro ejemplo.
Ahora, vamos a crear el formulario que nos permita dar de alta a los socios.
Pasamos, si no lo estamos ya en la pantalla para administrar el objeto Formulario.
Vamos a crear un nuevo formulario con el asistente, así nos vamos familiarizando con
él.
el primer paso del asistente nos va a
solicitar que ingresemos las tablas (o
consultas) que van a formar parte del
formulario. Para seleccionarlas,
desplegamos el cuadro desplegable y
vamos seleccionando aquellas que
necesitemos de una en una. Seleccionada
la primera, seleccioinamos ahora los
campos. Para ello, pulsamos el selector señalado
en la imagen porque queremos incluir todos los
campos de la tabla “Socios”.
Nuevamente pasamos a buscar otra tabla,
eligiendo ahora la tabla “Domicilios”. De nuevo
seleccionamos todos los campos y todos ellos
deberán estar en el cuadro “Campos
Seleccionados” del asistente como se muestra en la figura adjunta. Pulsamos el botón
“siguiente” para continuar hacia el siguiente paso.
Javier Fernández Castelo Pág 9 6 de mayo de 2012

10. En este nuevo cuadro del asistente se nos muestra que para ese formulario, formado por
dos tablas relacionadas existen dos maneras de presentar los datos: o bien por Socios, o
bien por Domicilios.
Como vemos, al presentar los datos por socios, como sabemos que a cada socio le puede
corresponder varios domicilios, el propio programa se prepara para crear un
subformulario o un formulario vinculado (dependiendo de nuestra elección en este
mismo cuadro de diálogo) donde introducir, para cada socio, los domicilios que se
precisen.
Aquí vamos a hacer notar que no hemos tenido que reservar campos para almacenar
cada domicilio que se añada. Con esta estructura, se van añadiendo en la tabla
domicilios sin tener que modificar estructuras anteriores.
Si elegimos presentar los datos por
Domicilios, en vez de por socios, el
programa se prepara para crear un
formulario único, sin subformularios. Esto
es así porque si presentamos los datos por
domicilios, a cada uno de estos le
corresponderá un socio y solo uno, aunque
el mismo socio figure en varios registros.
Teniendo en cuenta las distintas altrnativas,
nosotros elegimos para este ejemplo la
primera de ellas, es decir, ver los datos por Socio y formulario con subformularios.
Pulsamos el botón “Siguiente” para elegir la distribución. Dejamos en esta ocasión la
distribución que nos sugiere Access por defecto y volvemos a pulsar en el botón
“siguiente”. Ahora se nos
muestra las opciones de
estilo. También dejamos el
estilo por defecto y pulsamos
“Siguiente”.
Por último, el paso final del
asistente nos pregunta por los
nombres el formulario y
subformulario creados,
dándonos uno para cada
objeto por defecto. Optamos
por aceptar los nombres
sugeridos y pulsamos sobre el botón “Finalizar”.
Javier Fernández Castelo Pág 10 6 de mayo de 2012

11. Aparece por fin el formulario creado. Como vemos, automáticamente se ha creado en su
seno un subformulario. Solo resta dar formato a los espacios que se han ido abriendo en
el formulario para adecuarlos al tamaño de la información que contienen.
Para esto, procedemos dimensionando cada objeto y cuando estemos satisfechos,
pulsamos sobre el botón guardar de la barra de herramientas estandar.
Algunos contenedores no pueden ser redimensionados en modo vista. Entonces,
pasamos a modo diseño y modificamos sus propiedades.
En primer lugar, observamos que el contenedor subformulario no es lo suficientemente
grande como para albergar todos los campos de forma visible.
Este contenedor no se puede modificar masqueen modo diseño. Pasamos a modo diseño
y tiramos del “tirador” central derecho hasta que creamos que es suficiente. Volvemos a
modo vista para ver el resultado y repetimos la operación las veces que sea necesario.
Vemos que también es necesario modificar el tamaño del formulario. Lo hacemos y
pulsamos “Guardar”.
Ahora lo que no está muy bien es el tamaño de las celdas.. por ejemplo, el campo DNI
es un poco pequeño y se ve que no cabe la letra final del DNI. En modo vista lo
podemos redimensionar estirando el campo correspondiente hacia la derecha tanto como
sea necesario. Esta operación se realiza con el ratón sobre la cabecera o titulo de DNI,
se aproxima al margen derecho del campo hasta que el puntero se transforme en una
cruz con flechas en los brazos. En ese momento, sin soltar el botón, se arrastra el ratón
hasta donde sea necesario. Alcanzado el tamaño deseado, se pulsa sobre el botón
“Guardar” y se procede de igual forma con el resto de los campos.
El aspecto final ha de parecerse al de la imagen
Javier Fernández Castelo Pág 11 6 de mayo de 2012