- Relaciones. Creación de tablas.

Establecer relaciones.
Nota: Los alumnos que hayan realizado el curso de Access (no aplicaciones) ya han
estudiado el contenido de los primeros apartados de éste capítulo en la última lección.
Pueden por lo tanto, volver a recorrerlo para asentar correctamente sus conceptos
(aconsejado), o bien pasar directamente al apartado Crear las tablas.

Introducción.
Access es un programa gestor de base de datos, pero como ya se ha comentado, además
es relacional, es decir, se basa en el trabajo, no con tablas individuales como hasta ahora
hemos manejado en este curso, sino en el trabajo entre varias tablas relacionadas entre si.
De éste modo (con tablas relacionadas), la información se gestiona mucho más eficazmente
y más rápidamente que si en vez de estar separada en varias tablas relacionadas estuviera en
una sola tabla grande y pesada de “mover” y gestionar.

Para poder visualizar y trabajar con datos procedentes de varias tablas, es necesario
establecer relaciones entre ellas. Estas relaciones hacen que todas las tablas se comporten
como un solo grupo, pudiendo utilizar datos de varias tablas en una consulta, formulario o
informe.

Existen otros gestores de bases de datos en el mercado informático que se fundamentan en

otros sistemas de trabajo: Bases de datos documentales, distribuidas… pero Access es
RELACIONAL.

Manteniendo la información en tablas relacionadas ganaremos tiempo (ya que

conseguiremos mayor velocidad en el trabajo), así como mayor espacio libre en disco (más
megabytes disponibles para trabajar).

Así pues, algunas de las muchas ventajas que presenta la relación entre las distintas tablas
de una base de datos son las siguientes:

• Almacenar en cada una de las tablas distintos datos, no teniendo que repetir un
mismo dato en varias tablas (a excepción del campo común a todas ellas).
• El proceso de introducción de información es más rápido, al no tener que introducir
datos repetitivos.
• El espacio requerido para almacenar la base de datos es menor, ya que no se
almacenan datos repetidos.
• Al actualizar los datos solo habrá que modificarlos en una sola tabla, disminuyendo
la probabilidad de cometer un error y haciendo el proceso más rápido y seguro.
• Posibilidad de activar opciones de 'integridad referencial' (mecanismo de Access
para las relaciones). Esta característica garantiza en mayor grado la seguridad en el
trabajo con los datos.
Por qué de las relaciones (supuesto).

Veamos con un ejemplo en que consiste relacionar tablas. El por qué de su necesidad. Las
ventajas que ello aporta a la base de datos. Para ello, partiremos de un supuesto práctico.

Supuesto: Se dispone de una tabla de empleados de una gran empresa con una plantilla de
500 trabajadores.

Cada trabajador, además de contar con sus datos personales, dispone de unos datos
bancarios en donde tiene domiciliada la nómina, así como unos datos que definen
totalmente su puesto de trabajo, sueldo, pluses, etc…

Por cada trabajador, deberemos tener tantos datos individuales como sean necesarios para
identificarlo a él inequívocamente (como empleado de la empresa) frente a los demás
empleados. Al menos, los campos para cada trabajador, serían los siguientes:

CODIGO – NOMBRE – APELLIDOS – NIF – FECHANACIM

Datos de
(fecha nacimiento) - DIR – POB – CPOS (código postal) – PROV
carácter
– TELEF – MOVIL (teléfono móvil) – ECIVIL (estado civil) –
personal.
HIJOS (número de hijos) - ……en cuanto a datos personales.
Además existirán también los concernientes a sus datos
bancarios. Por lo menos los siguientes: NROCUENTA –
Datos
ENTIDAD – SUCURSAL – DIRBANCO (dirección del banco) –
Bancarios.
POBBANCO – CPOSBANCO – NOMDIRECTOR (nombre del
director) – TEFELBANCO - …
Y además los que lo definen como trabajador de ésta empresa. Al
menos los siguientes: PUESTO – SUELDO –
Datos Relación NIVELRESPONSABILI (nivel de responsabilidad en la empresa)
Laboral. – FECHAALTA (fecha de alta en la empresa) –
PLUSCONVENIO (si el trabajador tiene plus convenio o no lo
tiene)- …

Esto significa, que por cada trabajador, por cada registro de la gran tabla EMPLEADOS,
deberíamos tener toda su información alojada en todos estos campos, por lo que por cada
registro de la tabla (por cada empleado, y recordemos que en nuestro ejemplo son 500), se
necesitarían tantos bytes (caracteres de ocupación en disco) como sumatorio de bytes
tuvieran todos los campos de cada registro.

Cada campo, dependiendo de su tipo y/o longitud, tiene en Access -como sabemos- un
tamaño expresado en bytes.
Por lo tanto, por cada empleado de nuestra plantilla (500 empleados) se ocuparán 407 bytes
en disco. O sea 407 (bytes por empleado) por 500 (empleados) = 203.500 bytes, unos 199
kbytes (203.500 / 1.024) ocuparía nuestra tabla de empleados (a grandes rasgos).

Pero vamos a reflexionar un poco mas. Si de los 500 trabajadores tenemos 300 peones,
todos ellos tendrán la misma categoría, sueldo, nivel de responsabilidad y plus convenio,
luego los datos de Peón, 1.000 euros, baja, y plus convenio=no (respectivamente) serán
valores que se repiten 300 (en este caso) veces en nuestra tabla de empleados.

Por otro lado, todos los empleados que tengan su cuenta bancaria en la misma entidad y
sucursal tendrían los mismos datos para los campos ENTIDAD – SUCURSAL –
DIRBANCO – POBBANCO – CPOSBANCO – NOMDIRECTOR – TEFELBANCO –
con lo cual se tendría esa información dupli, tripli, cuadruplicada dentro de nuestra "gran"
tabla. Se estaría mal utilizando el espacio del disco conteniendo informaciones repetidas
que, además de tener que teclear muchas veces, multiplica la probabilidad de cometer
errores por parte del usuario. El sistema óptimo va a ser mantener no una tabla grande con
toda esa información, sino varias tablas relacionadas.
Para resolver el problema de en cuántas tablas mantener la información, que datos en cada
tabla, etc., aunque existan técnicas científicas y sofisticadas para resolverlo, hagamos las
siguientes reflexiones:

La información de qué campos es la que, más o menos masivamente se va a repetir a lo

largo de nuestra tabla de empleados (en éste ejemplo). Basta con imaginarse las fichas de
20 trabajadores, pensando en todas las situaciones que se puedan dar (que varios tengan las
mismas condiciones de sueldo, puesto, etc., por parte de la empresa. De que varios
compartan la misma entidad bancaria, por lo tanto los mismos datos bancarios a excepción
de numero de cuenta que evidentemente cada empleado tiene la suya…

Coloquemos en una tabla de dos columnas, de todos los campos necesarios, los que no
van a repetir sus contenidos masivamente (puede darse que existan cuatro empleados
llamados María pero esto se considera casualidad, no repetición masiva ya que pudiera no
haber cuatro María), y los que sí van a repetir sus valores de forma considerable y
reiterada.

Todos los empleados que operen con el mismo banco y sucursal, tendrán los mismos
valores para los campos ENTIDAD – SUCURSAL – DIRBANCO – POBBANCO –
CPOSBANCO – NOMDIRECTOR – TELEFBANCO - …

Si éstos datos de las entidades bancarias, los introducimos en una tabla aparte, de bancos,
tendremos por cada sucursal bancaria, un registro con sus datos una sola vez en la tabla
BANCOS. De modo contrario, en el caso de tener diez empleados con su cuenta bancaria
en la misma sucursal, deberíamos tener los datos bancarios en el propio registro de datos de
cada empleado en la tabla empleados, por lo que la información de banco estaría repetida,
en este caso, diez veces innecesariamente.

También, y de igual manera, todos los empleados que operen con el mismo puesto de
trabajo dentro de la empresa, tendrán los mismos valores para los campos PUESTO –
SUELDO – NIVELRESPONSABILI – PLUSCONVENIO.

En caso de tener 20 administrativos, esos datos se ubicarían para cada empleado en la tabla
empleados, con lo que tendríamos 20 veces repetida en la tabla empleados esa información.
Sin embargo, si creamos una tabla separada llamada CATEGORÍAS, cada categoría
profesional, con todos los datos que la definen estaría en dicha tabla una sola vez sin
repeticiones.

De esta primera consideración, deduciremos la necesidad de tener la información, en tres

grandes bloques, en tres tablas (según éste ejemplo).

Una contendrá los datos de los EMPLEADOS, otra los datos de los BANCOS, y otra los
datos de las CATEGORÍAS profesionales de ésta empresa. Así, en la tabla de bancos por
cada entidad y sucursal, tendremos un solo registro con todos los datos que definen a dicha
sucursal, exactamente igual para las categorías. Pero ¿cómo saber cuales son los datos
bancarios que corresponden a un determinado trabajador? ¿cómo saber el sueldo, categoría,
etc. de un determinado trabajador si dichos datos ya no se van a encontrar en la tabla
empleados? ¿Cómo poder asignar a cada empleado “su” banco y “su” categoría profesional
con todas sus informaciones?

Para organizar correctamente los elementos de una lista (artículos, empleados, socios,
películas, pedidos…) se recurre con frecuencia a una técnica que consiste en asignar a cada
elemento un código, que no es ni más ni menos que un número (generalmente) que
identifica inequívocamente a cada elemento de ese conjunto frente al resto. También y
desde el inicio, a cada empleado ya le habíamos asignado un código de empleado único
para cada trabajador dentro de la empresa de nuestro ejemplo.

Si de la anterior disección o separación de datos respecto al gran bloque o, tabla inicial,

llegamos a la conclusión de que si asignamos a cada entidad un código numérico (a cada
una uno distinto) y a cada categoría profesional uno distinto, solo nos quedaría incluir entre
los datos de dada empleado el código de banco que le corresponde así como el código de
categoría que tiene.

Y por lo tanto de esta situación pasaríamos a ésta otra:

Cada empleado tendrá ahora en su registro, el código que le corresponde dentro de la tabla
de bancos, decir que si tiene su cuenta bancaria y por lo tanto su nómina domiciliada en la
oficina urbana número 100 del Banco Santander y en la tabla de entidades esa oficina tiene
asignado el código 12, en el registro del empleado Pedro González en campo codigoenti
tendrá el valor 12. Mediante ese código de entidad 12, se busca en la tabla de entidades la
que tiene número 12 y en ese registro se encontrarán todos los datos que definen a esa
sucursal bancaria.

De la misma manera en el campo codigocat de Pedro González se almacenará el código de

categoría que le corresponde según la tabla categorías, en donde se definen todas las
informaciones relativas a la categoría de este empleado por parte de la empresa.

En la tabla de empleados, pueden existir por lo tanto 100 peones con el mismo codigocat =
7 que es Peón según la tabla de categorías. Esta relación indica que varios empleados se
relacionan con un solo registro en la tabla de categorías. Se trata como comentaremos más
adelante, de una relación uno a varios.

Así pues: El código de entidad de la tabla de empleados deberá coincidir (estar relacionado)
con un código de entidad de la tabla de entidades y el código de categoría de la tabla de
empleados deberá coincidir (estar relacionado) con el código de categoría de la tabla de
categorías.

Trabajar con varias tablas más reducidas de tamaño, es más eficiente que trabajar con tablas
grandes y pesadas de “mover”. En cuanto al ahorro de espacio en disco, analicemos los
números que salen:

Tabla de EMPLEADOS:
Como vemos, en la tabla empleados, hemos introducido el campo que va a permitir
relacionar dicha tabla con la tabla de entidades bancarias. Como en la tabla de empleados,
podemos encontrar varios que enlacen con el registro de la misma entidad en la tabla de
empleados, será un campo numérico entero largo, indexado sí pero con duplicados, ya
que como comentamos se puede duplicar el código de entidad en la tabla de empleados. Sin
embargo en la tabla relacionada de Entidades, el campo codenti será autonumérico, entero
largo, indexado si sin duplicados, ya que en la tabla entidades no podemos tener más de
una con el mismo código.

El mismo razonamiento sirve para el campo codigocat y codcatego. En la tabla de

empleados será indexado si con duplicados y en la tabla categorías el campo será
indexado si sin duplicados ya que en la tabla y en la empresa no existen dos categorías
iguales y codificadas con el mismo numero (código de categoría).

Tabla de ENTIDADES:

Tabla de CATEGORÍAS:

Tenemos por lo tanto, 3 tablas en vez de una. Mediante los campos relacionados, desde el
registro de un empleado, tendremos acceso a los datos de “su” banco y a los datos de “su”
puesto de trabajo con todas las informaciones pertinentes.

Si tenemos por lo tanto 500 empleados como se planteó al principio en este ejemplo, de
tener solo una tabla, el tamaño ocupado sería de 407 bytes X 500 registros = 203.500 bytes
o lo que es lo mismo 198,7 kbytes.
Si esos 500 empleados trabajan con 20 entidades bancarias distintas y en la empresa existen
10 categorías profesionales diferentes (por ejemplo), el tamaño de los datos en nuestra base
de datos sería como sigue:

• Tabla de empleados: 500 X 244 = 122.000 bytes.

• Tabla de entidades: 20 X 143 = 2.860 bytes.
• Tabla de categorías: 10 X 36 = 360 bytes.

Luego el total de nuestra información ocupa: 122.000 + 2.860 + 360 = 125.220 bytes.

La comparativa es de 125.220 bytes (en tres tablas relacionadas) frente a 203.500 bytes
(con la información en una sola tabla).Tenemos un ahorro, por lo tanto de 78.280 bytes, lo
cual supone un ahorro en disco de 76,4 kbytes. Alrededor de un 40% de ahorro.

Podemos, por tanto, establecer las siguientes grandes ventajas, aparte de la detallada
anteriormente:

• Un aspecto no cuantificable numéricamente de forma tan sencilla es el de la

velocidad que se optimiza manejando tres tablas “ligeras” frente a una sola tabla
“pesada”.
• Las veces que el usuario se ahorra por no tener que teclear repetidamente mucha
información idéntica.
• La disminución, en consecuencia, del número de errores de tecleo.
• De variar el sueldo de una categoría, por ejemplo, bastaría con modificar el campo
sueldo en el registro de esa categoría en la tabla de categorías, y no en los 100
trabajadores que existen en plantilla con esa categoría.
• Por tener las tablas relacionadas (esto no se ha visto aún) se pueden activar unos
mecanismos de seguridad que por ejemplo, impidan eliminar una categoría
profesional de la tabla categorías mientras existan trabajadores de esa categoría en
la tabla empleados. A esto se le llama integridad referencial.

Por lo tanto, y en Access, la relación entre las tres tablas quedará como sigue (a
continuación se verá como establecer dichas relaciones en Access):
Importante: Como ya se ha anticipado, todo el curso se desarrolla a través de la base de
datos que ahora se va a crear desde el principio. La base de datos se llamará Gestión de
pedidos.accdb. En la segunda parte de este capítulo veremos cómo crear las tablas de
nuestra aplicación de pedidos así como aprender a establecer las relaciones que existen
entre ellas.

Crear las tablas.

En primer lugar crearemos las tablas que obtuvimos como resultado de la normalización
(proceso de definición de campos para una tabla) realizada en el tema anterior. Las tablas
son:

Tabla: Clientes.
Tabla: Compañías de envíos.

Tabla: Detalles de pedidos.

Tabla: Empleados.

Tabla: Pedidos.
Tabla: Productos.

Establecer las claves e índices.

Para definir la relaciones es preciso haber establecido correctamente la clave principal en
cada tabla. En el caso de la tabla de detalles de pedidos la clave está formada por dos
campos, y se establece de la siguiente forma:

1. Abrimos la tabla en modo diseño.

2. Mientras mantenemos pulsada la tecla CTRL seleccionamos los dos campos que
formarán la clave principal (Idproducto e Idpedido) pulsando en los selectores de
fila de la izquierda..

3. En la ficha de Diseño dentro de las Herramientas de Tabla, pulsamos sobre el botón

Clave Principal para establecer la clave quedando marcada la clave en ambos
campos.
Recordamos que una clave principal podía estar formada por un solo campo de la
tabla, o por una combinación de varios. No obstante se recomienda la creación de
campos clave artificiales, siendo recomendables los de tipo autonumérico.

Creación de Tabla y Establecer la Clave Principal.

FlashWMV
Descargar video en formato:

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 Desarrollo de Aplicaciones realizando 3 unidades. Podrás acceder a
videotuoriales, actividades multimedia, ejercicios prácticos, consultar al tutor, etc..
Índices múltiples.

Aunque nos salimos del tema central de este capítulo, vamos a ver a continuación como
podemos crear índices múltiples.

Un índice simple es una tabla oculta que genera Access en la cual establece el valor del
campo que esta siendo indexado y la posición que ocupa en la tabla. De esta forma cuando
ordenamos por un campo indexado, se ejecuta esta operación de forma muy rápida ya que
esa tarea se había realizado con anterioridad. Además si establecemos que el índice es (sin
duplicados), Access evitará que introduzcamos valores repetidos en ese campo. En la tabla
de clientes, si añadiéramos el campo CIF, dicho campo podríamos indexarlo sin duplicados,
y de esta forma no podríamos duplicar a un cliente cuyo CIF ya existe en nuestra tabla de
clientes.

Un índice múltiple esta formado por varios campos, y puede ser definido con duplicados o
sin ellos. La única diferencia es que el orden se establece por la combinación de varios
campos, en lugar de uno solo. En la tabla de vendedores, para evitar introducir duplicados,
podríamos crear un índice múltiple sin duplicados formado por (apellidos, nombre,
teldomicilio). Una vez creado el índice, Access evitará que metamos a un vendedor cuya
combinación de esos tres campos coincida con los de un dato ya existente. Lo vemos por
pasos:

1. Abrimos la tabla Empleados en la vista Diseño.

2. Accedemos al botón Índices, dentro de la ficha diseño en las Herramientas de
Tabla.

3. Aparecerá el cuadro de índices.

4. En una nueva línea escribimos el nombre del índice Ej:"triple", y a continuación
seleccionamos los campos que formarán ese índice.

5. Pulsamos de nuevo sobre el nombre del índice y cambiamos a la parte inferior del
cuadro donde establecemos las características del índice.
 6. Seleccionaremos que no va a ser la clave principal en la primera opción.
Seleccionamos que Sí debe ser un índice único (sin duplicados), e indicamos que sí
puede haber valores nulos en el índice en previsión de que falte algún dato en
alguno de estos campos.
7. Guardamos los cambios en el diseño de la tabla, y para probarlo podemos intentar
añadir un nuevo cliente con el mismo nombre apellidos y teléfono que otro que
exista.

Relacionar tablas.

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 Desarrollo de Aplicaciones realizando 3
unidades. Podrás acceder a videotuoriales, actividades multimedia, ejercicios
prácticos, consultar al tutor, etc..

Tipos de relaciones.

De lo comentado, se deduce que la relación entre dos tablas es única y se establece siempre
a través de un campo común a ambas. No es necesario que el campo tenga el mismo
nombre pero si es aconsejable acostumbrarse a nombrar los campos comunes del mismo
modo, para evitar posibles equivocaciones a la hora de crear las relaciones.
Cuando se establece una relación entre tablas, una de ellas actuará como tabla principal y la
otra como tabla relacionada.

Si entre dos tablas existe una relación y se crea otra, ésta sustituirá a la anterior, ya que no
puede existir más de una relación entre dos tablas. Sin embargo, una tabla sí puede tener
relaciones con más de una tabla, siempre y cuando sea con tablas distintas.

Access permite establecer tres tipos diferentes de relaciones entre dos tablas, y cada una de
ellas tiene unas características que condicionarán el comportamiento final de la base de
datos. Por ello, debe seleccionarse correctamente el tipo de relación entre las tablas para
obtener el resultado esperado.

Los tres tipos de relaciones que existen son:

• Relación uno a uno: Relaciona un único registro de la tabla principal

con uno sólo de la tabla relacionada. Este tipo de relación produce el
mismo resultado que si se unieran los campos de ambas tablas en una
sola tabla.
• Relación uno a varios: Es el tipo de relación mas frecuente. Un único
registro de la tabla principal se puede relacionar con varios de la tabla
relacionada. Este tipo de relación es la que utilizaremos la mayoría de
las veces.
• Relación varios a varios: Un registro de la tabla principal se relaciona
con varios de la tabla relacionada y, además, un registro de la tabla
relacionada se relaciona con varios de la tabla principal. Este tipo de
relaciones se puede transformar en dos relaciones de tipo uno a varios,
creando una tabla intermedia de unión.

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 Desarrollo de Aplicaciones realizando 3
unidades. Podrás acceder a videotuoriales, actividades multimedia, ejercicios
prácticos, consultar al tutor, etc..

El Panel de Relaciones.

Las relaciones se establecen y modifican desde el panel de relaciones, al cual se accede

seleccionando la opción Relaciones de la Ficha Herramientas de Base de Datos - Grupo
Mostrar u Ocultar.
Cuando se accede por primera vez a la ventana de relaciones, ésta aparece vacía:

Sobre la misma aparecerá el cuadro de diálogo que muestra la siguiente figura, desde el
cual se pueden agregar las tablas que se van a relacionar entre sí. Los pasos a seguir son:
 1. En la ficha Tablas, seleccionar las tablas a relacionar (manteniendo la
tecla Ctrl pulsada hacer clic sobre ellas) y a continuación hacer clic
sobre el botón Agregar.
2. Una vez seleccionadas las tablas, hacer clic en el botón Cerrar para
abandonar el cuadro de diálogo. En la ventana de relaciones aparecerán
las tablas que se han agregado.

Es posible añadir nuevas tablas con las que crear nuevas relaciones en cualquier momento.
El procedimiento a seguir en este caso es el que se expone a continuación:

1. Acceder a la ventana de relaciones seleccionando la opción Relaciones

de la Ficha Herramientas de Base de Datos - Grupo Mostrar u
Ocultar.
2. Seleccionar la opción Mostrar tabla dentro de la Ficha Diseño en la
cinta de Herramientas de relaciones. El cuadro de diálogo que se
presenta es Mostrar tabla (el mismo visto anteriormente).

3. En la ficha Tablas seleccionar y agregar aquellas que se precisen.

4. Hacer clic sobre el botón Cerrar, para abandonar el cuadro de diálogo.
Para eliminar tablas de la ventana de relaciones, basta con pulsar sobre la tabla que se
quiere eliminar y pulsar la tecla Supr.

Al cerrar la ventana de relaciones, si en ella se ha realizado alguna modificación, se

visualizará un mensaje de advertencia como el que muestra la figura siguiente, permitiendo
guardar los cambios realizados o, por el contrario, salir sin guardar los mismos.

Creación de Relaciones entre tablas.

FlashWMV

Descargar video en formato:

Establecer una relación. Otro ejemplo.

FlashWMV

Descargar video en formato:

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 Desarrollo de Aplicaciones realizando 3
unidades. Podrás acceder a videotuoriales, actividades multimedia, ejercicios
prácticos, consultar al tutor, etc..

Establecer una relación entre dos tablas.

Las relaciones entre tablas se establecen en el panel de relaciones, siendo el procedimiento

el siguiente:

1. Situar el puntero del ratón sobre el campo común a ambas de la tabla

principal.
2. Pulsar el botón izquierdo del ratón y, sin soltarlo, arrastrar el campo
hasta el campo común de la tabla relacionada.

3. Soltar el botón del ratón. Aparecerá el cuadro de diálogo que muestra la

figura siguiente:
 4. Hacer clic sobre el botón Crear para establecer la relación. En la
ventana de relaciones aparecerán ambas tablas unidas a través de un
línea, cuyos extremos se sitúan frente a los campos de unión y en ellos
se muestra el tipo de relación que hay entre las tablas.

De este modo hemos establecido una relación entre la tabla de clientes y la de pedidos, al
realizar la relación de está manera no establecemos ninguna seguridad, es decir, siguiendo
con el ejemplo, tal y como hemos hecho esta relación, podríamos tener un pedido realizado
por un cliente que no tuviéramos registrado en la tabla de clientes, es decir, un cliente cuyo
nombre, compañía .... no lo conociéramos. Para evitar estos errores existe la integridad
referencial, la cual estudiaremos a continuación.
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 Desarrollo de Aplicaciones realizando 3
unidades. Podrás acceder a videotuoriales, actividades multimedia, ejercicios
prácticos, consultar al tutor, etc..

Modificar y eliminar relaciones.

Una vez establecidas las relaciones entre las distintas tablas, es posible modificar las
mismas o incluso eliminarlas. Ambas operaciones se realizan desde el Panel de Relaciones,
como ya se ha comentado anteriormente.

Para modificar una relación los pasos a seguir son:

1. Hacer clic sobre la línea de la relación que se quiere modificar y ésta se

visualizará con un trazo más grueso, indicando que está seleccionada.
2. Seleccionar la opción Modificar relaciones de la Ficha Diseño -
Grupo Herramientas.

3. Se muestra el mismo cuadro de diálogo que aparecía al crear la relación.

4. Realizar las modificaciones necesarias.
5. Hacer clic sobre el botón Aceptar.

Para eliminar una relación, basta con seleccionar la relación que se quiere eliminar y
pulsar a continuación la tecla Supr (o seleccionar la opción Eliminar de la Ficha Inicio -
Grupo Registros).

Integridad referencial.
La integridad referencial es un conjunto de reglas de Access que garantizan que las
relaciones entre los registros de tablas relacionadas son válidas y que no se eliminan ni
modifican accidentalmente datos relacionados que satisfacen dicha relación. Sirve para
aumentar la seguridad en el tratamiento de los datos que coexisten entre dos tablas
relacionadas.

Se puede establecer integridad referencial cuando se cumplen todas las condiciones

siguientes:
 • El campo que relaciona ambas tablas tiene que ser en la tabla principal un campo
clave (indexado si y sin duplicados) y en la otra tabla, también indexado (con o sin
duplicados según proceda).
• Los campos relacionados tienen el mismo tipo de datos, a excepción de que la
relación se establezca entre un campo de tipo Autonumérico y un campo de tipo
Numérico, siempre y cuando este último sea un Entero largo (por lo tanto los dos
campos con la misma longitud: entero largo). No se pueden relacionar un campo de
texto con uno de fecha, uno numérico con uno de texto...
• Ambas tablas deben pertenecer a la misma base de datos de Access (estar dentro
del mismo archivo .accdb).

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 Desarrollo de Aplicaciones realizando 3 unidades. Podrás acceder a
videotuoriales, actividades multimedia, ejercicios prácticos, consultar al tutor, etc..

Establecer integridad referencial.

Cuando se establece la integridad referencial (marcando la casilla pertinente en el panel de

modificar relaciones) se van a cumplir obligatoriamente, las siguientes reglas:

• No podemos introducir un valor para ese campo en la tabla relacionada si

antes no ha sido introducido en la tabla principal, es decir, no podemos tener en
la tabla de pedidos un pedido realizado por un código de cliente que no exista.

Otro ejemplo: no podemos tener o anotar en la tabla de participantes un participante con

un número de socio que no exista en la tabla relacionada de socios (habría que dar de alta
al participante previamente en la tabla socios. Una buena opción sería colocar en el
formulario de inscripciones un botón de comando que nos "lleve" y abra el formulario de
socios para poderle dar de alta. Al cerrar el formulario de socios una vez dado de alta,
regresaríamos al formulario de inscripciones y como ese nuevo socio ya existe en la tabla
de socios, nos permitiría su entrada).

No podremos introducir tampoco a un empleado un código de entidad bancaria si no se ha

introducido esa entidad previamente en la tabla entidades. No se puede asignar a un
trabajador un código de categoría si esa categoría no está dada de alta en la tabla categorías.
No se puede añadir un pedido en una tabla de pedidos de un artículo si el artículo no existe
previamente en la tabla de artículos...

• No se puede eliminar un registro de una tabla principal si existen registros

coincidentes en la tabla relacionada, no podemos eliminar un cliente que está en
la tabla de pedidos, es decir está realizando un pedido.
Otro ejemplo: No podemos eliminar un socio que está en la tabla de participaciones. No
podremos eliminar una entidad bancaria mientras existe un empleado que domicilie su
nómina por ella, no podremos eliminar una categoría profesional de la empresa mientras
algún empleado la tenga asignada. No se podría borrar un artículo mientras existen
pedidos de ese artículo en la tabla de pedidos. no se podría dar de baja un vehículo (de
una base de datos de un ayuntamiento) mientras en la tabla relacionada multas existan
multas sobre ese vehículo...

• No se puede cambiar un valor de clave principal en la tabla principal si el

registro tiene registros relacionados, siguiendo el ejemplo, no podríamos cambiar
el número de cliente en la tabla de clientes si este cliente en este momento esta
realizando un pedido, es decir está en la tabla pedidos.

Otro ejemplo: No podríamos cambiar el número de socio en la tabla de socios si este socio
en este momento esta participando en un torneo, es decir está en la tabla participaciones.
Para el resto de ejemplos propuestos, exactamente igual.

Si se quiere exigir el cumplimiento de estas reglas, hay que seleccionar la casilla de

verificación Exigir integridad referencial al crear la relación (paso 3).

Al hacerlo se activarán las dos opciones (con casilla de opción) que aparecen debajo:

• Actualizar en cascada los campos relacionados: si se activa esta opción, al

modificar el valor del campo común a ambas tablas en un registro de la tabla
principal, se actualizará dicho valor en todos los registros relacionados en la tabla
relacionada. (Si cambiamos el número de cliente en la tabla clientes, de forma
automática se cambia en todos los registros de la tabla pedidos).
• Eliminar en cascada los registros relacionados: si se activa esta opción, al borrar
un registro de la tabla principal, se borrarán todos los registros dependientes en la
tabla relacionada. (Si se elimina un cliente en la tabla clientes se eliminan de forma
automática todos los registros que tengan que ver con ese cliente en la tabla
 pedidos). Esta opción es muy peligrosa ya que en Access una vez que se elimina un
registro ya no se puede volver a recuperar.

Muy Importante: Esta opción es muy arriesgada ya que en Access una vez que se elimina
un registro ya no se puede volver a recuperar. Es fundamental llevar una buena política de
copias de seguridad.

Al establecer la integridad referencial en la figura siguiente se observa que la relación es

uno (1) a varios ( ), un cliente (cuyos datos se encuentran en la tabla Clientes) puede
haber realizado varios pedidos (los datos de éstos se encuentran en la tabla Pedidos).

Consultas de varias tablas.

En Access, es posible realizar consultas involucrando campos de varias tablas, de modo que
el resultado de la consulta muestre información procedente de todas ellas. Para que una
consulta pueda realizarse sobre campos de varias tablas, éstas deben tener un campo
común, y las tablas deberán estar relacionadas por esos campos. Si no se hubieran
establecido las relaciones anteriormente, habría que establecerlas en este momento (en la
propia consulta), ya que si no existen relaciones entre las tablas, Access no encontrará
relación entre los campos especificados en la ventana de diseño y no mostrará ningún
registro como resultado de la consulta.

Una vez establecidas las relaciones entre las tablas el modo de generar una consulta de
varias tablas es similar a la de creación de cualquier otra consulta, sin más que "subir" a la
parte superior de la consulta las tablas necesarias (varias en lugar de una sola), y "bajar" los
campos a incluir en la consulta desde cada correspondiente tabla en la que se encuentren.
Crear una consulta con varias tablas (relacionadas).
FlashWMV
Descargar video en formato:

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 Desarrollo de Aplicaciones realizando 3 unidades. Podrás acceder a
videotuoriales, actividades multimedia, ejercicios prácticos, consultar al tutor, etc..

Más ejemplos de tablas relacionadas.

Ejemplo-1: Supongamos que en la federación de golf (siguiendo con el ejemplo de la base

de datos Socios del Club) se ha asignado un responsable tutor por cada uno de los niveles
de juego de forma que a cada jugador le pasa a corresponder un responsable deportivo en
virtud de si su nivel de juego es principiante, medio o senior. Dicho tutor, tiene unos datos
que lo identifican, tales como son su nombre, apellidos, teléfono de contacto, fax, dirección
de e-mail, dirección de oficina...Sería preciso que en el registro de cada socio se dispusiera
de toda la información de su tutor o responsable deportivo.

Tras un análisis de la nueva situación, se deduce que si en la tabla socios agregamos tantos
campos como para albergar la información de dichos tutores, a todos los socios con el
mismo nivel de juego, les va a corresponder el mismo tutor, con lo que todos los datos del
tutor estarían repetidos de forma masiva y redundante en la tabla socios (ocupando mucho
espacio y lentificando el proceso básicamente). Quizás la mejor solución sea, en este caso,
definir otra tabla llamada Tutores, en la que deberá existir un registro para cada nivel de
juego y por lo tanto para cada tutor. La estructura de la tabla sería la siguiente:
Se introducirán los datos de los niveles junto a sus responsables...

Pero, ¿de qué manera podríamos enlazar o relacionar esta nueva tabla de tutores con
la gran tabla de socios?

Será necesario relacionar el nivel de juego de cada socio de la tabla de socios con el código
de nivel de la tabla de tutores. Pero como son de distinto tipo (texto -en socios- frente a
numérico -en tutores-) no se podrá. La solución es sustituir en la tabla de socios el campo
nivel por el campo codnivel (por ejemplo) de tipo numérico y luego colocar a cada socio un
código (el que corresponde a su nivel de juego) en este campo de acuerdo a los niveles y
tutores introducidos en la tabla de tutores (1, 2 o 3).

1. Se deberá crear en la tabla de socios el campo codnivel.

2. Mediante tres consultas de actualización, a aquellos que tengan nivel de juego
principiante, actualizaremos ese nuevo campo codnivel (de la tabla de socios) a 1.
De igual manera, los socios con nivel senior actualizaremos a 2 su campo codnivel.
Y a 3 el campo codnivel de los socios con nivel senior.
 3. A continuación deberemos (de forma recomendada, aunque en este ejemplo no lo
borremos) eliminar el campo nivel de la tabla socios ya que, a partir de ahora, se
conocerá el nivel de juego gracias a un código en la tabla de socios, que se
corresponderá con uno de los niveles y tutores de la tabla tutores.
4. Ahora tendremos que establecer la relación (en la pantalla de relaciones) de acuerdo
a la siguiente pantalla:

A partir de este momento, podríamos crear consultas, formularios e informes en donde

aparecen ambas tablas implicadas, eso si, previamente relacionadas.
Otro ejemplo de tablas relacionadas.
FlashWMV
Descargar video en formato:

Ejemplo-2: Supongamos un ejemplo superficial de gestión de sanciones de tráfico en una

localidad. Existen diferentes tipos de sanción (tipos de multa), diferentes guardias o
agentes, los vehículos, los cuales pertenecen a un ciudadano o propietario, y... por supuesto
sanciones. Las sanciones las "pone" un agente a un vehículo, un determinado día, a una
hora, en un lugar, y esa infracción es de un determinado tipo de entre las que se pueden
sancionar. Un ciudadano puede tener más de un vehículo.

La información habrá que disgregarla en diferentes tablas, (la de vehículos se supone que la
facilita tráfico con todos los vehículos), que deberán estar... Relacionadas. La siguiente
imagen muestra un posible planteamiento.
Ejercicios
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 Desarrollo de Aplicaciones realizando 3 unidades. Podrás acceder a
videotuoriales, actividades multimedia, ejercicios prácticos, consultar al tutor, etc..

Ejercicio 1.
1. Crear todas las tablas de la aplicación de pedidos, con los campos y propiedades que
se han indicado a lo largo de los contenidos de la unidad didáctica.
2. Crear las relaciones de la base de datos de pedidos según aparecen en el siguiente
esquema.
Para probar el funcionamiento de la base de datos introducir dos o tres registros en cada
tabla, comenzando lógicamente por las tablas simples, empleados, clientes, compañías de
envíos y productos. Después introduciremos algún pedido, y finalmente los detalles de los
pedidos.