Propiedades de clases de relación

Disponible con una licencia Standard o Advanced.

Una clase de relación contiene varias propiedades que definen cómo se relacionan los objetos en el origen con los objetos en el destino. Estas propiedades se especifican al crear la clase de relación.

• Tipo: simple o compuesto
• Clases de origen y de destino
• Claves principales y externas
• Cardinalidad: ¿la relación es de uno a uno, de uno a muchos o de muchos a muchos?
• Dirección de notificación del mensaje, aplicable si desea implementar la actualización en cascada personalizada o eliminar el comportamiento
• Si desea o no almacenar atributos para cada relación
• Nombre
• Etiquetas hacia delante y hacia atrás que se muestran al navegar los registros relacionados en ArcMap

Una vez que se ha creado la relación, puede especificar reglas para refinar la cardinalidad.

Simple frente a compuesta

Al crear una clase de relación, se especifica si es simple o compuesta.

En una relación simple, los objetos relacionados pueden existir independientemente entre sí. Por ejemplo, en una red de ferrocarriles puede haber cruces de ferrocarril que tengan una o más lámparas de señal relacionadas. Sin embargo, puede existir un cruce de ferrocarril sin una lámpara de señal y puede haber lámparas de señal en la red de ferrocarriles donde no hay cruces de ferrocarril.

Al eliminar un objeto de origen en una relación simple, el valor de campo de la clave externa para el objeto de destino correspondiente está establecido en Nulo. Este comportamiento de clave externa se diseñó para mantener integridad referencial entre entidades. Si se elimina la entidad del origen, el valor en la clave externa ya no está relacionando esa fila con una entidad en el origen y, en consecuencia, ya no es necesario el valor de clave externa ya y se establece en Nulo. El único propósito de la clave externa consiste en mantener una relación entre el objeto de destino y el objeto de origen relacionado. Si no hay ninguna entidad de origen con el valor de clave principal correspondiente, entonces no hay ninguna razón para mantener el valor de la clave externa. Si desea relacionar la misma entidad de destino con una entidad de origen nueva o diferente en el futuro, el campo de clave externa se puede actualizar de Nulo al nuevo valor de clave externa.

Eliminar un objeto de destino no tiene ningún efecto en el valor de clave principal en el objeto de origen relacionado.

Las relaciones simples pueden tener una cardinalidad de uno a uno, de uno a muchos o de muchos a muchos.

Al igual que las relaciones simples, las relaciones compuestas también mantienen una integridad referencial cuando se eliminan los objetos, pero realizan esto de un modo diferente. En una relación compuesta, los objetos de destino no pueden existir independientemente de los objetos de origen, de modo que cuando se elimina el origen, los objetos de destino relacionados también se eliminan en un proceso denominado eliminación en cascada.

Una relación compuesta también puede ayudarle a mantener entidades espacialmente; desplazar o girar una entidad de origen hace que las entidades de destino relacionadas se desplacen o giren con la misma cuando la mensajería se establece en Adelante.

Las relaciones compuestas son siempre de uno a muchos cuando se crean pero se pueden restringir con reglas de la relación para que sean de uno a uno.

Clases de origen y de destino

Al crear una clase de relación, seleccione una clase que sea el origen y otra que sea el destino. Es importante no confundir las dos. Con el comportamiento de eliminaciones en cascada en las relaciones compuestas, la importancia de esta cuestión puede resultar obvia.

En relaciones simples, es esencial que sea correcto. Esto se debe a que cuando se elimina un registro en la clase de origen, la clase de relación simple busca los registros correspondientes en la clase de destino y establece el valor de los campos clave en Nulo. Si selecciona como origen la clase equivocada y elimina objetos en el origen, introducirá errores en el campo de clave externa. El siguiente ejemplo muestra cómo puede ocurrir esto:

Caso 1: parcela a zona (erróneo)

Se trata de un supuesto de error común. La tabla Zona contiene las descripciones de los distintos códigos de zonificación y es conceptualmente similar a una tabla de búsqueda. En este caso, la clase Parcel es el origen y la tabla Zona es el destino. El problema es que al eliminar una parcela, el valor en el campo clave (Zona) se establece en Nulo para el registro correspondiente en la tabla Zona y ninguna de las demás parcelas que tienen dicho código de zonificación tienen una coincidencia en la tabla Zona.

Caso 2: zona a parcela (correcto)

Para corregir el problema, establezca la tabla Zona como origen. La eliminación de una parcela (un objeto de destino), no tendrá ningún efecto en la tabla Zona y la eliminación de un código de Zona (un objeto de origen), simplemente establecerá el valor del campo Zona en los registros de parcela correspondientes en Nulo, que es el que debería ser, porque ya no tienen un registro de tabla Zona correspondiente.

Claves principales y externas

En una clase de relación, los objetos en el origen coinciden con objetos en el destino a través de los valores en los campos clave. En el siguiente ejemplo, la parcela 789 coincide con los permisos 2 y 3 porque todos esos registros tienen el mismo ID de parcela.

El campo clave en la clase de origen de una relación se denomina la clave principal y se suele abreviar como PK. A diferencia de una verdadera clave principal, los valores del campo de clave principal de una relación no es necesario que sean únicos para cada objeto.

El campo clave en la clase de destino se denomina clave externa y se suele abreviar como FK. Contiene valores que coinciden con los del campo de clave principal en la clase de origen. Nuevamente, los valores del campo clave no tienen que ser únicos para cada fila.

Los campos clave pueden tener nombres diferentes pero deben ser del mismo tipo de datos y contener el mismo tipo de información, como ID de parcela. Pueden ser campos clave los campos de todo tipo de datos, excepto objeto binario grande (BLOB), fecha y ráster. Los campos clave se especifican al crear una clase de relación.

Al decidirse por un campo de clave principal, una opción consiste en utilizar el campo ID de fila, normalmente denominado campo ID de objeto. ArcGIS agrega automáticamente el campo Id. de objeto al crear una clase de entidad o tabla o al registrar una capa de geodatabase corporativa o tabla. Este campo garantiza un identificador único para cada registro. Es mantenido por ArcGIS y no puede modificarlo.

El valor ID de objeto de un objeto determinado no cambia nunca mientras permanezca en su clase original y, si el objeto es una entidad, no lo divida. Si divide una entidad, mantendrá la entidad original (pero actualizará la geometría) y crear una nueva entidad, que tendrá un nuevo ID de objeto asignado a la misma. Como resultado, solo la entidad con el ID de objeto original mantendrá relaciones que dependan del valor ID de objeto.

Por ello, puede ser mejor crear y utilizar su propio campo de clave principal en lugar de confiar en el campo ID de objeto. A continuación se describe cómo su propio campo de clave principal puede ayudarle a mantener las relaciones cuando se realiza cada una de estas operaciones.

• Al importar registros a otra clase de entidad o tabla, se asignan nuevos valores ID de objeto, perdiendo cualquier relación basada en los valores ID de objeto originales. Si, en su lugar, basa la relación en otra clave principal, los valores del identificador de la clave principal no cambiarán cuando se importan los registros. Esto le permite conservar las relaciones al importar conjuntos relacionados de objetos a nuevas clases.

  Una excepción es cuando se utiliza la función de copiar y pegar. Copiar y pegar conserva los valores ID de objeto, de modo que si piensa mover objetos solo con este método, puede utilizar el campo ID de objeto como clave principal.

• Al dividir una entidad, la entidad original se mantiene (con geometría actualizada) y se crea una nueva entidad. Si tiene una relación basada en el ID de objeto original, solo una de las dos entidades creadas en la división mantendrá la relación. Sin embargo, si utilizó otro campo como clave, al dividir la entidad, el valor del identificador de la entidad original se copiaría en las dos nuevas entidades. En consecuencia, los registros de la tabla relacionada se relacionarían ahora con sendas nuevas entidades, ideal si la clase de relación se ha definido como de muchos a muchos.

  Si no va a dividir las entidades y está seguro de que todos los objetos permanecerán en su clase original, puede utilizar el ID de objeto como identificador. Si no puede garantizarlo, es mejor definir y utilizar su propio campo de identificador en lugar de confiar en el campo ID de objeto.

• Al combinar dos entidades, la nueva entidad conserva el ID de objeto de una de las entidades originales. Si planea combinar entidades pero no mover entidades fuera de su clase ni dividirlas, puede utilizar el campo ID de objeto como clave principal.

Cardinalidad

La cardinalidad de una relación especifica el número de objetos de la clase de origen que se pueden relacionar con varios objetos en la clase de destino. Una relación puede tener una de estas tres cardinalidades:

De uno a uno: un objeto de origen puede relacionarse solo con un objeto de destino. Por ejemplo, una parcela solo puede tener una descripción legal. En ArcGIS, esta cardinalidad también cubre de muchos a uno. Un ejemplo de relación de muchos a uno es muchas parcelas que se relacionan con la misma descripción legal.

De uno a muchos: un objeto de origen se puede relacionar con varios objetos de destino. Por ejemplo, una parcela puede tener muchos edificios. En una relación de uno a muchos, el lado de uno debe ser la clase de origen y el lado de muchos debe ser la clase de destino.

De muchos a muchos: un objeto de origen puede relacionarse con varios objetos de destino y, a la inversa, un objeto de destino puede relacionarse con varios objetos de origen. Por ejemplo, una propiedad determinada puede tener muchos propietarios y un propietario determinado puede poseer muchas propiedades.

Los términos uno y muchos pueden resultar confusos. Uno es realmente de cero a uno y muchos es realmente de cero a muchos. Por tanto, al crear una relación de uno a muchos entre parcelas y edificios, por ejemplo, la relación permite todas las posibilidades siguientes:

• Una parcela sin edificios
• Un edificio sin parcela
• Una parcela con cualquier número de edificios

Reglas de relación

Cuando se crea una clase de relación, se crea con las cardinalidades de uno a uno, de uno a muchos o de muchos a muchos.

Con frecuencia es necesario definir una relación en condiciones más restrictivas. En una relación de parcelas y edificios, por ejemplo, podría ser necesario requerir que cada edificio esté asociado a una parcela o que una parcela pueda contener un número máximo de edificios. Desea evitar que un usuario se olvide de asociar un edificio a una parcela o que asocie demasiados edificios a una parcela.

Si tiene subtipos, puede restringir el número y tipo de objetos en el origen que se pueden relacionar con determinado tipo de objetos en el destino. Por ejemplo, los postes de acero admiten transformadores de clase A, mientras que los postes de madera admiten transformadores de clase B. Además, es posible que también tenga que especificar el rango de cardinalidad permisible para cada par de subtipos válido. Por ejemplo, un poste de acero puede admitir 0-3 transformadores de clase A, mientras que un poste de madera puede admitir 0-2 transformadores de clase B.

Para ver las reglas de relación para su clase de relación, haga clic con el botón derecho en la clase de relación en el panel Catálogo para abrir el cuadro de diálogo Propiedades de clase de relación y seleccione la pestaña Reglas.

Esto muestra una lista de todas las reglas posibles que pueden existir para su clase de relación. La columna Habilitado indica cuál de las reglas está activa actualmente.

Se pueden ordenar las reglas de clase de relación en la pantalla seleccionando Origen y después Subtipo de destino o Destino y después Subtipo de origen en el menú desplegable Ordenar por.

Para eliminar una regla de la clase de relación, desactive la casilla de verificación Habilitado de la fila que representa la regla que desea eliminar y haga clic en Aceptar

Para crear una nueva regla en la clase de relación:

1. Active la casilla de verificación Habilitado de la fila que representa la regla que desea agregar a la clase de relación
2. Establezca las cardinalidades Mín y Máx adecuadas en la regla para el origen y el destino introduciendo números enteros en sus celdas correspondientes
3. Repita los pasos 1 y 2 para cada regla que desee agregar
4. Haga clic en Aceptar

Una vez agregada una regla de relación a una clase de relación, dicha regla se convierte en la única relación válida que puede existir. Para hacer otras cardinalidades y combinaciones de relaciones válidas, debe agregar reglas de relación adicionales.

En el ejemplo siguiente, un vertedero de HazMat se puede relacionar con uno o dos pozos profundos o entre dos y siete pozos poco profundos. Sin embargo, si un vertedero sanitario se relaciona con un pozo profundo, pero no se ha creado ninguna regla entre estos dos subtipos, el comando Validar entidades considerará que la relación no es válida.

Dirección de notificación del mensaje

Como se analizó anteriormente, cuando se elimina un objeto de origen en una relación compuesta, los objetos de destino relacionados se eliminan automáticamente.

Tanto si está trabajando con relaciones simples o con relaciones compuestas, puede haber otras acciones que requieran una actualización de una entidad para desencadenar una actualización en sus entidades relacionadas. Además, puede que sea necesario hacer actualizaciones en una u otra dirección o en ambas.

• Al desplazar o girar una entidad, desea que las entidades relacionadas se desplacen o giren con la misma.
• Cuando se actualiza una entidad, desea que un atributo de una entidad relacionada se actualice automáticamente.
• La actualización de un origen puede requerir la actualización de los objetos de destino relacionados.
• La actualización de objetos de destino puede requerir la actualización de los objetos de origen.

Si la relación requiere este comportamiento, puede hacer que los objetos de origen de destino envíen mensajes para notificarse entre sí cuando se produzcan cambios, permitiendo que los objetos relacionados se actualicen de forma apropiada.

Para lograrlo, establezca la dirección de notificación del mensaje al crear la relación. Si la actualización de un origen requiere que se actualicen los objetos de destino, establezca la dirección de notificación del mensaje en Hacia delante. Si la actualización de un destino requiere que se actualicen los objetos de origen, establezca la dirección de notificación del mensaje en Hacia atrás. Si necesita ambos, establezca la dirección de notificación del mensaje en Ambos. Cuando haya creado la relación, a continuación, debe programar el comportamiento en los objetos que reciben los mensajes para que puedan responder.

La única excepción son las relaciones compuestas en las que la mensajería se establece en Hacia delante. Cuando se crea una relación compuesta con mensajería hacia delante, el desplazamiento o giro de un objeto de origen hace que se desplacen o giren automáticamente con él las entidades de destino relacionadas. Dado que configura la relación correctamente, esta funcionalidad funciona siempre que haya creado la relación, no se requiere programación personalizada.

Para otras direcciones de notificación de mensaje, se requiere programación personalizada. A menos que esté creando una relación compuesta con mensajería hacia delante o pretenda programar un comportamiento propio, establezca la notificación de mensajes en Ninguna. De lo contrario, se generarán mensajes innecesariamente cada vez que realice una operación de edición, ralentizando el rendimiento.

Al establecer la dirección para relaciones compuestas, tenga presente que cuando se elimina el objeto de origen en una relación compuesta, se eliminan automáticamente todos los objetos relacionados en el destino. Esto ocurre independientemente de si la mensajería se ha establecido en hacia delante, hacia atrás, ambas o ninguna.

Direcciones de notificación del mensaje

Dirección	Efecto en relaciones simples	Efecto en relaciones compuestas
Hacia delante	Ningún efecto a menos que se haya personalizado con programación	Al eliminar el origen, se elimina el destino Al desplazar o girar el origen se desplaza o gira el destino Ningún otro efecto a menos que se haya programado comportamiento propio
Atrás	Ningún efecto a menos que se haya personalizado con programación	Al eliminar el origen, se elimina el destino Ningún otro efecto a menos que se haya programado comportamiento propio
Ambas	Ningún efecto a menos que se haya personalizado con programación	Al eliminar el origen, se elimina el destino Al desplazar o girar el origen se desplaza o gira el destino Ningún otro efecto a menos que se haya programado comportamiento propio
Ninguna	Evita que se envíen los mensajes, mejorando ligeramente el rendimiento	Al eliminar el origen, se elimina el destino Evita que se envíen otros mensajes, mejorando ligeramente el rendimiento

Relaciones de muchos a muchos

En las relaciones de uno a uno y de uno a muchos, los valores de la clave principal de la clase de origen se relacionan directamente con los valores de la clave externa de la clase de destino.

Las relaciones de muchos a muchos, por otro lado, exigen el uso de una tabla intermedia para asignar las asociaciones. En consecuencia, al crear una relación de muchos a muchos, se crea automáticamente una tabla intermedia. En la tabla intermedia se asignan los valores de clave principal del origen a los valores de clave externa del destino. Cada fila asocia un objeto de origen a un objeto de destino.

Cuando se crea la tabla intermedia, solo se generan los campos automáticamente. ArcGIS no sabe qué objetos de origen están asociados a los objetos de destino, de modo que debe crear manualmente las filas en la tabla. Rellenar esta tabla es la etapa que conlleva más tiempo en la configuración de la relación.

Atributos de relación

La tabla intermedia de una relación de muchos a muchos puede servir opcionalmente para un segundo fin: almacenar atributos de la propia relación. Por ejemplo, en una base de datos de parcela, puede tener una clase de relación entre parcelas y propietarios, donde los propietarios poseen parcelas y las parcelas son propiedad de los propietarios. Un atributo de cada relación podría ser el porcentaje de propiedad. Si necesita almacenar tales atributos, puede agregarlos a la tabla intermedia al crear la relación o posteriormente en cualquier momento.

Aunque no es tan útil, al configurar una relación de uno a uno o de uno a muchos, puede tener la misma necesidad de almacenar atributos de la relación. En tal caso, debe especificarlo al crear la relación para que se cree una tabla intermedia. Como en el caso de las relaciones de muchos a muchos, la tabla intermedia asigna los valores de clave principal del origen a los valores de clave externa del destino, permitiéndole almacenar cualquier número de atributos para cada relación.

Si agrega la clase de relación al mapa, aparecerá como una tabla que se puede abrir y manipular. ArcGIS no expone la tabla intermedia para otras operaciones. Por ejemplo, no puede mostrar sus propiedades en el panel Catálogo ni agregar o eliminar campos en la vista Campos, y tampoco admite el uso de dominios o valores predeterminados.

Nombre

Cada clase de relación tiene un nombre que se muestra en el panel Catálogo. Para hacer que la estructura de base de datos sea fácil de entender, nombre la clase de relación de modo que el nombre describa la relación.

Empiece por el nombre de la clase de entidad del origen, siga con Tiene o Tienen y termine por el nombre de la clase de entidad de destino. Por ejemplo, DirecciónTieneZonas o ParcelasTienenPropietarios. Utilice plural en el nombre de la clase de entidad de origen si se trata de una cardinalidad de muchos a uno o de muchos a muchos y utilice el plural en el nombre de la clase de entidad de destino si se trata de una cardinalidad de uno a muchos o de muchos a muchos.

Con este método, puede determinar la cardinalidad de una clase de relación a partir de su nombre. Por ejemplo, con las dos clases de entidad en plural, ParcelasTienenPropietarios sugiere una relación de muchos a muchos.

Etiquetas hacia delante y hacia atrás

Las etiquetas hacia delante y hacia atrás se muestran en los cuadros de diálogo Atributos e Identificar resultados en el panel Mapa y le ayudan a navegar entre objetos relacionados.

Una clase de relación tiene dos etiquetas:

• Una etiqueta hacia delante que se muestra al navegar desde el origen hasta el destino. En el ejemplo de los postes de transformadores, esta etiqueta podría ser "admite", que significa que este poste admite estos transformadores.
• Una etiqueta hacia atrás que se muestra al navegar desde el destino hasta el origen. En el ejemplo de postes de transformadores, esta etiqueta podría ser "va montado sobre", que significa que estos transformadores van montados sobre este poste.