Parámetros de la herramienta Crear clase de relación

Cómo se configuran los valores de los parámetros al ejecutar la herramienta de geoprocesamiento Crear clase de relación depende del tipo de clase de relación que necesite y de las reglas que deba aplicar.

Para ayudarle a entender los valores que deben utilizarse, se describen los parámetros de entrada de la herramienta de geoprocesamiento Crear clase de relación.

Parámetros

A continuación se explica cada parámetro de la herramienta de geoprocesamiento Crear clase de relación:

• Tabla de origen: la tabla o clase de entidad asociada a la tabla de destino.
• Tabla de destino: la tabla asociada a la tabla de origen.
• Clase de relación de salida: el nombre de la clase de relación que se creará.
• Tipo de relación: especifica el tipo de relación que se creará entre las tablas de origen y destino.
  • Simple: las tablas de origen y destino tendrán una relación simple. Esta es la opción predeterminada.
  • Compuesta: las tablas de origen y destino tendrán una relación compuesta.
• Etiqueta de ruta origen-destino: un nombre para identificar la relación de manera unívoca al navegar de la tabla de origen a la tabla de destino.
• Etiqueta de ruta destino-origen: un nombre para identificar la relación de manera unívoca al navegar de la tabla de destino a la tabla de origen.
• Dirección del mensaje: especifica la dirección en la que se transmitirán los mensajes entre las tablas de origen y destino. Por ejemplo, en una relación entre postes y transformadores, cuando se elimina un poste, se enviará un mensaje a sus objetos de transformador relacionados para informar que fue eliminado.
  • Hacia delante (de origen a destino): los mensajes se transmitirán de la tabla de origen a la tabla de destino.
  • Hacia atrás (de destino a origen): los mensajes se transmitirán de la tabla de destino a la tabla de origen.
  • Ambas direcciones: los mensajes se transmitirán de la tabla de origen a la tabla de destino y de la tabla de destino a la tabla de origen.
  • Ninguna (no se propagan mensajes): no se transmitirá ningún mensaje. Esta es la opción predeterminada.
• Cardinalidad: especifica cuántas relaciones existirán entre las filas o entidades de la tabla de origen y las filas o entidades de la tabla de destino.
  • Uno a uno (1:1): cada fila o entidad de la tabla de origen puede estar relacionada con cero o una fila o entidad de la tabla de destino. Esta es la opción predeterminada.
  • Uno a muchos (1:M): cada fila o entidad de la tabla de origen puede estar relacionada con una o varias filas o entidades de la tabla de destino.
  • Muchos a muchos (M:N): varias filas o entidades de la tabla de origen pueden estar relacionadas con una o varias filas o entidades de la tabla de destino.
• Clase de relación con atributos: especifica si la clase de relación tendrá atributos. Consulte Comprender las clases de relación con atributos para obtener más información sobre dónde se almacenan estos atributos y cómo crear y rellenar una clase de relación con atributos.
  • Activado: la clase de relación tendrá atributos.
  • Desactivado: la clase de relación no tendrá atributos. Esta es la opción predeterminada.

• Clave principal de origen: en las clases de relación de uno a uno o de uno a muchos sin atributos, es el campo de la tabla de origen, a menudo abreviado como PK, que se vincula con el campo Clave externa de origen de la tabla de destino.

  En las clases de relación de muchos a muchos o con atributos, es el campo de la tabla de origen que se vincula con el campo Clave externa de origen de la tabla de clase de relación intermedia.

• Clave externa de origen: en las clases de relación de uno a uno o de uno a muchos sin atributos, es el campo de la tabla de destino, a menudo abreviado como FK, que se vincula con el campo Clave principal de origen de la tabla de origen.

  En las clases de relación de uno a muchos o con atributos, es el campo de la tabla de clase de relación intermedia que se vincula con el campo Clave principal de origen de la tabla de origen.

• Clave principal de destino: el campo de la tabla de destino que se vincula con el campo Clave externa de destino de la tabla de clase de relación intermedia. Este valor es obligatorio para las clases de relación de muchos a muchos o con atributos, pero debe dejarse vacío en las clases de relación de uno a uno o de uno a muchos sin atributos.
• Clave externa de destino: el campo de la tabla de clase de relación intermedia que se vincula con el campo Clave principal de destino de la tabla de destino. Este valor es obligatorio para las clases de relación de muchos a muchos o con atributos, pero debe dejarse vacío en las clases de relación de uno a uno o de uno a muchos sin atributos.

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 su campo 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:

Es importante no confundir los dos, eligiendo el que debería ser el destino como origen y viceversa.

Caso 1: parcela a zona (erróneo)

Se trata de un supuesto común de este error. 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.

Nombre de la clase de relación de salida

Cada clase de relación tiene un nombre que se muestra en el panel Catálogo. Se recomienda asignar un nombre a la clase de relación de modo que el nombre describa los elementos participantes y la cardinalidad de 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.

Los nombres deben ser únicos en una geodatabase: no puede haber más de un objeto (tabla, clase de entidad, clase de relación, etc.) con el mismo nombre. Consulte Definir propiedades de clases de entidad para obtener más información sobre las reglas y limitaciones de nombres de tabla y clase de entidad.

Etiquetas de ruta origen-destino y destino-origen

Las etiquetas de origen-destino y destino-origen se muestran en los cuadros de diálogo Atributos e Identificar resultados en ArcGIS Pro y le ayudan a navegar entre objetos relacionados.

Una clase de relación tiene dos etiquetas:

• Una etiqueta de origen-destino que se muestra al navegar del origen al destino. En el ejemplo del poste-transformador, 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 del poste-transformador, esta etiqueta podría ser va montado sobre, que significa que estos transformadores van montados sobre este poste.

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.

Direcciones de notificación del mensaje

Dirección	Efecto en relaciones simples	Efecto en relaciones compuestas
adelante	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.
Ambos	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.
Ninguno	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.

Cardinalidad

La cardinalidad describe el número máximo de asociaciones entre las filas o columnas de dos tablas diferentes.

Un SIG integra información sobre diversos objetos de entidades geográficas y no geográficas, muchos de los cuales pueden estar relacionados. Al agregar datos no geográficos a sus datos de entidad, debe tener en cuenta cómo se relacionan los objetos y si existe un campo común.

Las relaciones se construyen en torno al concepto de una tabla de origen y otra de destino y cómo se relacionan los objetos de la tabla de origen con los objetos de la tabla de destino. Para crear una relación entre dos tablas, debe identificar un campo común a ambas con valores comunes, conocido como clave.

Nota:

No es obligatorio que los campos comunes tengan el mismo nombre, pero sí que tengan el mismo tipo de datos. Los valores de los campos comunes se utilizan para vincular los registros de la tabla en función de la cardinalidad definida.

La cardinalidad de una relación especifica cuántos objetos de la tabla de origen están relacionados con cuántos objetos de la tabla de destino. Una clase de relación puede tener una de estas tres cardinalidades:

• Uno a uno: una fila o entidad de la clase o tabla de origen puede relacionarse con cero o una fila o entidad de la clase o tabla de destino. Esta es la configuración predeterminada. Por ejemplo, una parcela solo puede tener una descripción legal.

  Nota:

  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.

• Uno a muchos: una fila o entidad de la clase o tabla de origen puede relacionarse con una o varias filas o entidades de la clase o tabla 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.
• 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. Para obtener más información, consulte Comprender las clases de relación con atributos.

Nota:

Al evaluar la cardinalidad de los objetos entre dos tablas, la terminología "uno" es en realidad de cero a uno, y la terminología "muchos" es en realidad 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

Si se ha creado una clase de relación, puede perfeccionar aún más las cardinalidades agregando reglas a la clase de relación. Puede agregar reglas que especifiquen el número de filas o entidades de la clase o tabla de origen que se permite relacionar con un número de filas o entidades de la clase de destino.

Nota:

La cardinalidad se define cuando se crea una clase de relación. Una vez creada la clase de relación, la cardinalidad para la clase de relación no puede modificarse; por lo tanto, es importante considerar y verificar la cardinalidad de los datos antes de crear la clase de relación.

Claves principales y externas

En una clase de relación, los objetos de la tabla de origen coinciden con los objetos de la tabla de destino a través de los valores de sus campos clave.

En una clase de relación sin atributos, la relación se mantiene cuando los valores del campo Clave principal de origen (PK) de la tabla de origen se relacionan directamente con los valores del campo Clave externa de origen (FK) de la tabla de destino. 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 de clave externa contiene valores que coinciden con los del campo de clave principal de la tabla de origen. Nuevamente, los valores del campo clave no tienen que ser únicos para cada fila.

Por ejemplo, la parcela 789 coincide con los permisos 2 y 3 porque todos esos registros tienen el mismo ID de parcela.

Opcionalmente, en una clase de relación con atributos, como cuando se crea una relación de muchos a muchos, también se crea automáticamente una tabla intermedia. Esta tabla intermedia asigna los valores del campo Clave externa de origen y del campo Clave externa de destino a las claves principales de las tablas o clases de entidad relacionadas. Cada fila asocia un objeto de origen a un objeto de destino. Los campos clave pueden tener nombres diferentes, pero deben ser del mismo tipo de datos de campo y contener el mismo tipo de información, como los ID de parcela. Pueden ser campos clave los campos de todo tipo de datos, excepto objeto binario grande (BLOB), fecha y ráster.

Por ejemplo, para ayudar a determinar los propietarios de las parcelas de su comunidad, se crea una clase de relación de muchos a muchos entre la clase de entidad Parcela y la tabla independiente Propietario. Esta clase de relación de muchos a muchos creará una tabla intermedia o con atributos, ParcelToOwner, que asociará uno o varios propietarios a cada parcela.

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, se recomienda que configure y utilice su propio campo ID en lugar de confiar en el campo ObjectID.

• 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.