SlideShare a Scribd company logo
1 of 8
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 lasotras 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.

More Related Content

What's hot

Unidad 2. modelo entidad relacion
Unidad 2. modelo entidad relacionUnidad 2. modelo entidad relacion
Unidad 2. modelo entidad relacion
LuiS YmAY
 
Diagrama entidad-relacion normalización
Diagrama entidad-relacion normalizaciónDiagrama entidad-relacion normalización
Diagrama entidad-relacion normalización
cintiap25
 

What's hot (20)

Registro de desplazamiento
Registro de desplazamientoRegistro de desplazamiento
Registro de desplazamiento
 
Taller de Base de Datos - Unidad 6 SQL procedural
Taller de Base de Datos - Unidad 6 SQL proceduralTaller de Base de Datos - Unidad 6 SQL procedural
Taller de Base de Datos - Unidad 6 SQL procedural
 
Calculo relacional de base de datos
Calculo relacional de base de datosCalculo relacional de base de datos
Calculo relacional de base de datos
 
Algebra relacional
Algebra relacionalAlgebra relacional
Algebra relacional
 
Practica 2 manejo del código bcd en display de 7 segmentos.
Practica 2 manejo del código bcd en display de 7 segmentos.Practica 2 manejo del código bcd en display de 7 segmentos.
Practica 2 manejo del código bcd en display de 7 segmentos.
 
Unidad 2. modelo entidad relacion
Unidad 2. modelo entidad relacionUnidad 2. modelo entidad relacion
Unidad 2. modelo entidad relacion
 
Pilas estáticas. IESIT
Pilas estáticas. IESITPilas estáticas. IESIT
Pilas estáticas. IESIT
 
3. Modelo ER - Relacional
3. Modelo ER - Relacional3. Modelo ER - Relacional
3. Modelo ER - Relacional
 
Árboles Rojo - Negro
Árboles Rojo - NegroÁrboles Rojo - Negro
Árboles Rojo - Negro
 
Ejercicios+de+Normalización.pdf
Ejercicios+de+Normalización.pdfEjercicios+de+Normalización.pdf
Ejercicios+de+Normalización.pdf
 
Diccionario de base de datos.
Diccionario de base de datos.Diccionario de base de datos.
Diccionario de base de datos.
 
Unidad v algebra relacional
Unidad v   algebra relacionalUnidad v   algebra relacional
Unidad v algebra relacional
 
Manual para usar la tarjeta del fpga cyclone iv de altera
Manual para usar la tarjeta del fpga cyclone iv de alteraManual para usar la tarjeta del fpga cyclone iv de altera
Manual para usar la tarjeta del fpga cyclone iv de altera
 
Guia de ejercicio sql
Guia de ejercicio sqlGuia de ejercicio sql
Guia de ejercicio sql
 
Sensor de nivel de agua
Sensor de nivel de aguaSensor de nivel de agua
Sensor de nivel de agua
 
Consultas en access
Consultas en accessConsultas en access
Consultas en access
 
La función BDCONTAR Excel
La función BDCONTAR ExcelLa función BDCONTAR Excel
La función BDCONTAR Excel
 
Ejercicio 2
Ejercicio  2Ejercicio  2
Ejercicio 2
 
Diagrama entidad-relacion normalización
Diagrama entidad-relacion normalizaciónDiagrama entidad-relacion normalización
Diagrama entidad-relacion normalización
 
Dfd
DfdDfd
Dfd
 

Similar to Tipos relaciones access 2010

Las relaciones
Las relacionesLas relaciones
Las relaciones
Mapo15
 
Base de datos 2
Base de datos 2Base de datos 2
Base de datos 2
sanThiiT
 

Similar to Tipos relaciones access 2010 (20)

Tema relaciones
Tema relacionesTema relaciones
Tema relaciones
 
Conceptos básicos sobre relaciones
Conceptos básicos sobre relacionesConceptos básicos sobre relaciones
Conceptos básicos sobre relaciones
 
Relaciones
RelacionesRelaciones
Relaciones
 
Bd acces
Bd accesBd acces
Bd acces
 
Bd acces
Bd accesBd acces
Bd acces
 
Relacion entre tablas
Relacion entre tablasRelacion entre tablas
Relacion entre tablas
 
Tabla relaciones1
Tabla relaciones1Tabla relaciones1
Tabla relaciones1
 
Relaciones
RelacionesRelaciones
Relaciones
 
Guía #3 access
Guía #3 accessGuía #3 access
Guía #3 access
 
base de datos
base de datos base de datos
base de datos
 
Integridad referencial
Integridad referencialIntegridad referencial
Integridad referencial
 
Las relaciones
Las relacionesLas relaciones
Las relaciones
 
Las relaciones
Las relacionesLas relaciones
Las relaciones
 
Las relaciones
Las relacionesLas relaciones
Las relaciones
 
Las relaciones
Las relacionesLas relaciones
Las relaciones
 
intregridad referencial
intregridad referencialintregridad referencial
intregridad referencial
 
Relaciones
RelacionesRelaciones
Relaciones
 
Relaciones en access
Relaciones en accessRelaciones en access
Relaciones en access
 
Relaciones de Acces 2007
Relaciones de Acces 2007Relaciones de Acces 2007
Relaciones de Acces 2007
 
Base de datos 2
Base de datos 2Base de datos 2
Base de datos 2
 

Tipos relaciones access 2010

  • 1. 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
  • 2. 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.
  • 3. 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.
  • 4. 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 lasotras 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.
  • 5. 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..
  • 6. 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
  • 7. 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
  • 8. 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.