Tipos Relaciones Access 71f65

TIPOS RELACIONES ACCESS 2010 UNO A UNO Relación uno a uno: si ambos campos relacionados son claves principales o tienen índices únicos. Se caracteriza porque un registro en la tabla A solo puede tener un registro dependiente en la tabla B. Este tipo de relación no es habitual, debido a que la mayoría de la información relacionada de esta forma estaría en una sola tabla. Puede utilizar la relación uno a uno para dividir una tabla con muchos campos, para aislar parte de una tabla por razones de seguridad o para almacenar información que sólo se aplica a un subconjunto de la tabla principal. Por ejemplo, puede crear una tabla que registre los empleados participantes en un partido de fútbol benéfico. Cada jugador de fútbol de la tabla Jugadores de fútbol tiene un registro coincidente en la tabla Empleados. * Cada jugador de fútbol tiene un registro coincidente en la tabla Empleados. * Este conjunto de valores es un subconjunto del campo Id. de empleado y la tabla Empleados.

Ejemplo

Cada registro de EMPLEADO_PERSONAL puede relacionarse con uno y sólo un registro de EMPLEADO_LABORAL. Un registro de EMPLEADO_LABORAL sólo tiene una relación con uno y necesariamente uno de EMPLEADO_PERSONAL. Sin embargo un registro de EMPLEADO_PERSONAL puede no participar en ninguna relación, es decir no necesariamente con un registro de EMPLEADO_LABORAL

UNO A VARIOS Este tipo de relaciones es una de las más habituales e indica que un elemento de la tabla principal, estará en relación con varios registros de la tabla vinculada. La tabla principal será la que tenga la clave principal en la relación. Vamos a poner un pequeño ejemplo. Pongamos que tenemos la tabla clientes y la tabla facturas. Si hacemos una lectura rápida de la relación que deben tener estas tablas, podemos observar que UN cliente puede tener VARIAS facturas pero haciendo la lectura al revés observamos que UNA factura solo puede pertenecer a un UN solo cliente. En este ejemplo nuestra tabla principal es Clientes y la tabla vinculada Facturas.

Como vemos en el ejemplo, al tener en la tabla clientes un campo numérico (en este caso autonumérico), el campo que vincularemos de la tabla facturas, debe tener el mismo tipo de datos. Finalmente en la pantalla de relaciones, enlazaremos los dos campos. Eso nos permitirá tener los datos separados cada uno en su tabla pero tenerlos enlazados.

VARIOS A VARIOS

Este tipo de relaciones también es bastante frecuente. En este caso un elemento de la tabla principal puede tener varios registros relacionados de la tabla vinculada y a la inversa.

Vamos a ver dos opciones Creamos la tabla con otra clave Vamos a ver un ejemplo. Disponemos de una tabla de empleados y una tabla de máquinas reponedoras. UN empleado puede reponer VARIAS máquinas reponedoras. A su vez UNA máquina reponedora puede ser "repuesta" por VARIOS empleados diferentes. En estos casos, necesitamos crear una tabla intermedia que nos permita vincular las dos tablas. Vamos a verlo.

Como comentábamos anteriormente, en este caso no podemos crear una relación directa entre ambas tablas ya que los empleados harán más de una reposición y las máquinas se repondrán más de una vez, por tanto deberemos crear una tabla intermedia que además nos permitirá incluir campos como la fecha de la reposición, tiempo empleado...

De éste modo la relación nos quedaría así:

Creamos tabla con las claves de la otra Relación de varios a varios: es, en realidad, dos relaciones de uno a varios con una tercera tabla cuya clave principal consta de dos campos: las claves externas (clave externa: uno o más campos de tabla (columnas) que hacen referencia al campo o campos de clave principal de otra tabla. Una clave externa indica cómo están relacionadas las tablas.) de las otras dos tablas. Pensemos en las entidades PRODUCTOS y NUM_VENTA. Hay una relación entre ambas entidades puesto que una instancia de PRODUCTOS puede relacionarse con muchas filas de números de venta, entidad NUM_VENTA. Pero una venta también puede relacionarse con varios productos, siempre a través de una tabla de unión (la entidad VENTAS) con una lleve múltiple. Para crear una llave múltiple selecciona los campos clave y pulsa (en Access) el icono llave. En la imagen de abajo ves la manera de crear una llave múltiple, para una relación n: m. En la otra imagen verás otras tablas que completan la estructura... En realidad se trata de dos relaciones 1 a muchos: La primera entre NUM_VENTAS y VENTAS, un numero de venta cualquiera estará relacionado con 1 o más filas de VENTAS si la venta supone varios productos. La segunda entre PRODUCTOS y VENTAS, un producto se puede vender muchas veces...

RELACION INDEFINIDA o INDETERMINADA Este tipo de relación aparece cuando no hay coherencia de tipos de datos. Access no puede determinar el tipo de relación que existe entre las tablas. Los datos relacionados de esta manera normalmente son incoherentes y por tanto debe evitarse..

En resumen, para evitar las relaciones indeterminadas debemos controlar las siguientes variables: 1.- Debe existir una clave principal. 2.- La clave externa debe ser del mismo tipo que la clave principal. 3.- Es necesario activar la integridad referencial. 4.- Para poder activar la integridad referencial es necesario que no haya registros huérfanos..

REGISTRO HUERFANO, FILA O TUPLA COLGADA ¿Qué es un registro huérfano en un modelo de tablas relacionales? Antes de nada vamos a observar con detalle la imagen

Tenemos dos tablas con una relación de uno a muchos: 1 Tabla PROVEEDORES (lado uno a la derecha) 2 Tabla PEDIDOS (lado muchos a la izquierda en la que existen tuplas colgadas... ------------Explicación: nuestra tabla de proveedores tiene 9 proveedores de los productos de nuestra empresa, pero al observar la tabla de PEDIDOS vemos los pedidos 5, 7 y 8 cuyos números de proveedor (columna NP) son 0, 11 y 12 y es aquí donde se encuentra la inconsistencia. ¿Quiénes son los proveedores 0, 11 y 12? Estos proveedores no existen y por tanto forman pedidos de productos inexistentes. Son registros absurdos, huérfanos o colgados... Los datos en rojo son registros huérfanos en la relación entre PROVEEDORES y PEDIDOS. Access creará una relación indeterminada o se deberá desactivar la Integridad referencial...

Integridad referencial La integridad referencial es un sistema de reglas que utiliza Access 2010 para asegurarse que las relaciones entre registros de tablas relacionadas son válidas y que no se borren o cambien datos relacionados de forma accidental. Al exigir integridad referencial en una relación le estamos diciendo a Access 2010 que no nos deje introducir datos en la tabla secundaria si previamente no se ha introducido el registro relacionado en la tabla principal. Por ejemplo: Tenemos una tabla de habitantes y una tabla de poblaciones, en la tabla Habitantes tengo un campo Población que me indica en qué población vive el habitante, las dos tablas deberían estar relacionadas por el campo Población, en esta relación de tipo uno a varios la tabla Poblaciones es la tabla principal y la

tabla Habitantes la secundaria (una población tiene varios habitantes). Si marcamos la casilla Integridad Referencial, no nos dejará asignar a un habitante una población que no exista en la tabla Poblaciones. La integridad referencial dispone de dos acciones asociadas:  Actualizar en cascada los campos relacionados: Hace que cuando se cambie el valor del campo de la tabla principal, automáticamente cambiarán los valores de sus registros relacionados en la tabla secundaria. Por ejemplo: Si cambiamos el nombre de la población Vizcaya por Bizkaia en la tabla Poblaciones, automáticamente en la tabla Habitantes, todos los habitantes de Vizcaya se cambiarán a Bizkaia. 

Eliminar en cascada los registros relacionados: Cuando se elimina un registro de la tabla principal se borrarán también los registros relacionados en la tabla secundaria. Por ejemplo: Si borramos la población Vizcaya en la tabla Poblaciones, automáticamente todos los habitantes de Vizcaya se borrarán de la tabla de Habitantes.

Si no marcamos ninguna de las opciones no nos dejará ni cambiar el nombre de una población ni eliminar una población si ésta tiene habitantes asignados.