C2.00

Relación INDETERMINADA entre tablas de Acces

C10.00

REGISTRO HUERFANO, FILA O TUPLA COLGADA

Páginas:
       1 
Relación INDETERMINADA entre tablas de Acces

Las relaciones entre tablas pueden ser:

1 DE UNO A UNO.

2 DE UNO A VARIOS.

3 DE VARIOS A VARIOS.

4 INDETERMINADA.

Esta última es una relación no consistente puesto que crea tuplas con escaso o ningún valor que siempre debe evitarse ya que genera datos incoherentes de ningún valor...

En la imagen siguiente podemos ver dos relaciones entre la tabla EMPLEADO_PERSONAL y las tablas NUM_VENTAS y CIUDADES.

La relación entre EMPLEADO_PERSONAL y NUM_VENTAS se realiza con el campo N_EMPLE de EMPLEADO_PERSONAL que es una clave principal (llave) de tipo numérico entero que se relaciona con N_EMPLE de NUM_VENTAS que es una clave externa igualmente de tipo numérico entero. N_EMPLE debe ser un campo del mismo tipo en ambas claves, pero centremonos en la segunda relación...

La relación entre EMPLEADO_PERSONAL y CIUDADES se realiza con el campo Ciudad de EMPLEADO_PERSONA y el campo CIUDAD de la tabla CIUDADES, pero ¿cual es la clave principal? ¡ninguna! En esas condiciones Acces crea una relación indefinida, indeterminada o inconsistente.

Relación INDETERMINADA entre tablas de Acces

Sin embargo, el hecho de que no haya clave principal no determina totalmente que la relación sea inconsistente o poco fiable, pueden darse de hecho otras situaciones en la que a pesar de existir una clave principal sigamos obteniendo una relación inconsistente.

Veamos la imagen siguiente en la que si existe una clave principal CIUDAD en la tabla CIUDADES. No parece haber impedimento para crear una relación consistente que no obstante no termina de crearse pudiendo deberse a varias causas. La primera de ellas es que no se activa la integridad referencial, es decir, un mecanismo que asegure al motor de la B.D. que no quedaran tuplas colgadas o en otras palabras que no quede un registro huerfano en EMPLEADO_PERSONAL. Por ejemplo, imaginemos que la tabla CIUDADES contiene tres registros con las ciudades Granada, Málaga y Almería. Por otro lado, imaginemos que hay dos empleados que son de Madrid, es evidente que el motor de la base de datos no podría encontrar a estos dos empleados mediante esta relación, por lo tanto si no activamos la integridad referencial es lógico que Acces cree una relación poco fiable...

Sin embargo, activar la integridad referencial tampoco garantiza que Acces pueda crear una relación consistente. O dicho de otra manera, para que Acces pueda activar la integridad referencial es necesario que los datos sean realmente íntegros.

Por ejemplo, en la imagen siguiente pretendemos relacionar la clave principal CIUDAD con la clave externa Salario, lo cual es absurdo puesto que CIUDAD es un campo de tipo texto y Salario es un campo de tipo numérico. Al activar integridad referencial Acces me advertirá de que no se pueden relacionar claves de distinto tipo, así que obtendremos nuevamente una relación inconsistente.

Pero podríamos pensar que si relacionamos CIUDAD con Direccion1 que es de tipo texto entonces sí podríamos activar integridad, pero el motor de Acces comprobará que los registros de EMPLEADO_PERSONAL quedan huerfanos puesto que el campo Direccion1 no coincide con las ciudades, así que tampoco se podrá activar la integridad y nuevamente la relación será inconsistente...

En resumen, para evitar las relaciones indeterminadas debemos controlar las siguiente 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 interidad referencial es necesario que no haya registros huerfanos, en nuestro ejemplo, no puede existir ningún empleado cuya ciudad no exista en la tabla de CIUDADES...

----------------------

Si tienes dudas puedes realizarlas creando una entrada en este título...

----------------------








Sesión:
registrar en twiiter
Inicie sesión ...


Editores de contenidos

No es un Editor...



Títulos


Tweets aulapc.es:





 eduardo@aulapc.es Granada (España)