relacciones entre tablas de access

Javier Fernández Castelo Pág 1 6 de mayo de 2012

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

Préstamo Devuelto (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.


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


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


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.


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


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


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.


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.


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.


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


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

relacciones entre tablas de access

Documents