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 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.
El comando Validar entidades de ArcMap, un comando que se ejecuta en una sesión de edición para probar la integridad referencial, fuerza también esta regla de dependencia. Si creó un objeto de destino pero no lo asoció a un objeto de origen, Validar entidades le advierte del error.
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 de ArcGIS Desktop Advanced Workstation. En este caso, la clase Parcel es el origen y la tabla Zona es el destino. De esta forma se establecería la relación en ArcGIS Desktop Advanced Workstation. 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.
- La replicación con clases de relación donde se utiliza un campo ID de objeto como campo clave principal requiere procesamiento adicional durante la sincronización, que puede afectar al rendimiento. También puede producir comportamiento inesperado en algunos casos. Para obtener más información sobre cómo utilizar un ID de objeto como clave principal con Replicación, consulte Replicación y datos relacionados.
- 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
Después de haber creado una relación, puede refinar las cardinalidades estableciendo reglas para la relación. Puede establecer reglas que especifiquen el número de objetos en el origen que se permite que se relacionen con varios objetos en el destino.
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.
Una vez que haya creado una clase de relación, puede especificar reglas que ayuden a forzar estas reglas de integridad referencial:
- En ArcCatalog o en la ventana Catálogo, haga clic con el botón derecho en una clase de relación existente para mostrar su cuadro de diálogo Propiedades de clase de relación y después haga clic en la pestaña Reglas.
- Elija un subtipo de la clase de origen y compruebe un subtipo correspondiente de la clase de destino.
- Active las casillas de verificación para la cardinalidad de origen y de destino. Establezca las cardinalidades mínima y máxima adecuadas para la regla. El cuadro de diálogo evita que establezca un valor mínimo que sea superior al valor máximo, por tanto establezca primero el valor de cardinalidad máximo.
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 más reglas de relación.
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.
Después de haber establecido las reglas y comenzado la edición, puede probarlas con el comando Validar entidades de ArcMap. El comando Validar entidades le indica si alguna de las entidades seleccionadas actualmente infringe una regla de relación.
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, 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.
| Dirección | Efecto en relaciones simples | Efecto en relaciones compuestas |
|---|---|---|
Hacia delante | Ningún efecto a menos que se haya personalizado con programación |
|
Atrás | Ningún efecto a menos que se haya personalizado con programación |
|
Ambos | Ningún efecto a menos que se haya personalizado con programación |
|
Ninguno | Evita que se envíen los 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.
Puede ver una vista previa de la tabla intermedia en ArcCatalog o en la ventana Catálogo para ver los datos que contiene. Si agrega la clase de relación a ArcMap, 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 ArcCatalog o en la ventana Catálogo para agregar o eliminar los campos y no admite el uso de dominios o valores predeterminados.
Nombre
Cada clase de relación tiene un nombre que se muestra en el Árbol de 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 ArcMap 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.