Tu portal de
formación online

Infórmate
Inicio » Catálogo » Curso de Access 2007 Desarrollo de Aplicaciones » 2 - Relaciones. Creación de tablas. Establecer relaciones.

Curso de Access 2007 Desarrollo de Aplicaciones

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



Si desea obtener un acceso sin restricciones a los contenidos del curso de Access 2007 Desarrollo de Aplicaciones y disfrutar de todas las herramientas del aula virtual (Videos explicativos streaming, acceso a los foros, chat, ejercicios resueltos, la ayuda del tutor, audioconferencia, estudio de grabación, test y actividades de autoevaluación, etc...) puede inscribirse completamente gratis y comenzar a realizar de forma inmediata el curso.