Disponible con una licencia Standard o Advanced.
Durante la creación de réplicas, se agregan filas y entidades a una réplica sobre la base de los filtros definidos en la aplicación. Una vez se completa, las clases de relación se procesan para incluir objetos relacionados adicionales.
El procesamiento de la clase de relación implica la evaluación de cada que participa en por lo menos una clase de relación. Cuando se evalúa un dataset, todas las filas que ya se han replicado se recopilan y se usan para consultar las filas relacionadas en los datasets relacionados. Las fila relacionadas devueltas por las consultas se agregan a la réplica. Cada dataset se visita una vez durante este proceso.
En ArcGIS AllSource, la clase de relación siempre se procesa en una única dirección, hacia delante. Una dirección hacia delante significa que se evalúa la clase de origen para agregar a la réplica filas relacionadas de la clase de destino. También puede desactivar el procesamiento de clases de relación durante la creación de la réplica.
En los siguientes ejemplos se muestra el comportamiento de replicación respecto a los objetos relacionados. El modelo de datos utilizado en estos ejemplos es una relación simple de origen-destino entre propiedades, edificios y su anotación relacionada.
Ejemplo uno
En este ejemplo se muestra el área de réplica que cubre ocho parcelas y seis edificios. Cuando se crea la réplica, se agregan dos edificios adicionales, dado que están relacionados con las parcelas. El procesamiento de la clase de relación también agrega a la réplica anotaciones para los edificios y las parcelas.
En el ejemplo anterior, se creó una réplica utilizando el comportamiento predeterminado, que incluye los objetos relacionados. En ArcGIS AllSource, puede personalizar la replicación e invalidar este comportamiento en el nivel global al utilizar la herramienta de geoprocesamiento Crear réplica. En el nivel global, el proceso de replicación se puede configurar para que no incluya objetos relacionados asociados a entidades identificadas para la replicación.
Ejemplo dos
En este ejemplo se muestra lo que pasa en caso de una relación circular. Durante el proceso de creación de la réplica, el sistema aplica lógica para interrumpir el círculo y evitar que procese en un bucle sin fin. Sin embargo, esta lógica lo hace de modo tal que no se puede predecir el orden en el que se procesan las relaciones.
Clases de relación donde un campo ObjectID es el campo clave principal
La replicación con clases de relación donde se utiliza un campo ObjectID como campo clave principal requiere procesamiento adicional durante la sincronización, lo que puede afectar al rendimiento. También puede producir comportamiento inesperado en algunos casos. A continuación se describen con más detalle. Después de revisar esta sección, quizá decida modificar las clases de relación para que utilicen campos de clave principal que no sean el campo ObjectID. Estas son algunas alternativas adecuadas a tener en cuenta:
- Clases de relación con un campo de clave principal de tipo GlobalID y un campo de clave externa de tipo GUID
- Cree y utilice su propio campo clave principal, único en todas las bases de datos
Procesamiento adicional durante la sincronización cuando el campo ObjectID es el campo de clave principal
Los valores de ObjectID de una clase de entidad o tabla no son únicos entre geodatabases. Una nueva fila de una geodatabase de réplica puede tener asignado el mismo ObjectID que una fila diferente de la otra geodatabase de réplica. El proceso de sincronización debe tener en cuenta estas diferencias al transferir relaciones entre geodatabases de réplica cuando la clave principal de la relación es una columna ObjectID . Para lograr esto, el proceso de sincronización detecta las clases de relación que utilizan la columna ObjectID. Si hay clases así presentes, el proceso de sincronización transmite información adicional que, a continuación, se utiliza para realizar procesamiento adicional.
El procesamiento implica el ajuste de valores de clave externa que tengan como objetivo el valor de ObjectID adecuado en la geodatabase objetivo para cada relación revisada. En casos donde se edite un gran número de relaciones, este procesamiento adicional puede tener un efecto visible sobre el rendimiento de la sincronización.
Comportamiento inesperado cuando el campo ObjectID es el campo de clave principal
A continuación, se describen casos en los que se puede observar un comportamiento inesperado cuando se utiliza el campo ObjectID como campo clave principal:
- Ediciones donde la fila de origen no existe en la geodatabase de réplica de destino: como se ha descrito, el proceso de sincronización realiza procesamiento adicional para mantener las relaciones cuando un campo ObjectID es el campo clave principal en una clase de relación. Una relación no se mantiene, no obstante, en los casos donde la edición implica hacer referencia a una fila de origen que no existe en la geodatabase de réplica relativa. Para una inserción, esto provoca que la clave externa se establezca en nulo en la fila de destino. Para una actualización, el valor de la clave externa queda como estuviera antes de la sincronización en la fila de destino. Tenga en cuenta que este comportamiento no se produce en las réplicas de réplica de check-out/check-in.
- El diagrama anterior muestra un caso donde existe una clase de relación simple entre las parcelas y los edificios, donde el campo ObjectID de la clase de entidad de las parcelas es la clave principal de origen. En este ejemplo, se crea una réplica solo para las parcelas y edificios dentro de una extensión espacial. Una vez creada la réplica, no obstante, se detecta un error de digitalización donde se descubre que un edificio se ha digitalizado en la parcela equivocada. Esto se corrige en la geodatabase de réplica primaria moviendo el edificio y editando la relación de modo que se relacione con la parcela correcta. A continuación, la réplica se sincroniza para aplicar los cambios a la réplica secundaria. En este caso el edificio se desplaza, pero continúa relacionado con la parcela incorrecta en la réplica secundaria. La relación no se cambió en la réplica secundaria porque la fila de origen correcta (la parcela con ObjectID 102 en la réplica principal) no existe en las geodatabases de réplica secundaria. En estos casos, las relaciones no se modifican.
- Claves externas pendientes: al crear una réplica, las filas se copian de la geodatabase de origen en la geodatabase de destino en función de cómo se defina la réplica. Al definir la réplica, puede decidir incluir filas de la tabla de destino que no tengan filas relacionadas en la tabla de origen. Los valores de clave externa en la tabla de destino para estas filas no relacionadas son iguales que los de la geodatabase de origen. Son claves externas que quedan pendientes, puesto que la fila de origen a la que hacen referencia no existe en la geodatabase de destino.
- El diagrama anterior describe un ejemplo donde puede producirse comportamiento inesperado como consecuencia de las claves externas pendientes. Aquí, la geodatabase de réplica primaria tiene una clase de relación simple entre las parcelas y los edificios. La clase de entidad de parcela es el origen y utiliza el campo ObjectID como clave principal. Se crea una réplica para incluir todos los edificios de la ciudad y las parcelas para un bloque. El proceso de creación de la réplica copia las parcelas y edificios adecuados de la geodatabase de la réplica primaria en la geodatabase de la réplica secundaria. En la réplica secundaria, los edificios relacionados con las parcelas que estén fuera de la manzana tienen claves externas pendientes, puesto que estas parcelas no forman parte de la réplica. Por ejemplo, el edificio cuya clave externa es 100 tiene una clave externa pendiente, dado que la parcela cuyo ObjectID es 100 no existe en el elemento secundario. Si se crea una nueva parcela en la réplica secundaria y se le asigna un ObjectID de 100, se relacionará involuntariamente con el edificio.