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

Datos de carácter personal.

CODIGO – NOMBRE – APELLIDOS – NIF – FECHANACIM (fecha nacimiento) - DIR – POB – CPOS (código postal) – PROV – TELEF – MOVIL (teléfono móvil) – ECIVIL (estado civil) – HIJOS (número de hijos) - ……en cuanto a datos personales.

Datos Bancarios.

Además existirán también los concernientes a sus datos bancarios. Por lo menos los siguientes: NROCUENTA – ENTIDAD – SUCURSAL – DIRBANCO (dirección del banco) – POBBANCO – CPOSBANCO – NOMDIRECTOR (nombre del director) – TEFELBANCO - …

Datos Relación Laboral.

Y además los que lo definen como trabajador de ésta empresa. Al menos los siguientes: PUESTO – SUELDO – NIVELRESPONSABILI (nivel de responsabilidad en la empresa) – 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.Flash WMV 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.

Flash WMV

Descargar video en formato:

Establecer una relación. Otro ejemplo.

Flash WMV

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