Replicación y datos relacionados

Este tema se aplica sólo a ArcEditor y ArcInfo.

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 completado este proceso, 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.

Cada clase de relación se procesa en una única dirección. De forma predeterminada, la dirección es hacia delante, pero esto también se puede cambiar hacia atrás en el momento de la creación. 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. Una dirección hacia atrás significa que se evalúa la clase de destino para agregar a la réplica filas relacionadas de la clase de origen. También es posible desactivar el procesamiento de la clase de relación para una clase de relación concreta durante la creación de la réplica.

Dado que cada dataset se evalúa una vez, y cada clase de relación se procesa en, a lo sumo, una dirección, el orden en el que se evalúan los datasets es importante. El sistema tiene lógica para procesar los dataset en el orden para el que se agregarán los objetos más relacionados. Puede influir sobre el orden en el que se procesan los datasets cambiando la dirección o desactivando el procesamiento para clases de relación concretas.

En los siguientes ejemplos se mostrará el comportamiento de replicación con 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 sus anotaciones relacionadas.

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 regla anotaciones para el edificio y las parcelas.

Ejemplo dos

En este ejemplo se muestra cómo replicar relaciones a través del procesamiento hacia delante. Seleccionando los dos edificios de la réplica primaria para la replicación y utilizando la dirección de procesamiento hacia delante predeterminada para los registros relacionados, las anotaciones relacionadas con esos edificios se replican también en el elemento secundario.

El diagrama siguiente muestra un caso donde se eligen esos mismos dos edificios pero se decide utilizar una dirección de procesamiento hacia atrás para la clase de relación prop_build. Aquí, además de las anotaciones relacionadas con los edificios, también se incluyen las parcelas relacionadas con esos edificios y las anotaciones de las parcelas.

Ejemplo tres

En los ejemplos anteriores, se creó una réplica utilizando el comportamiento predeterminado de incluir los objetos relacionados. Es posible anular este comportamiento, ya sea en el nivel global o en el local, para personalizar la replicación. 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.

En este ejemplo, los edificios y las propiedades están seleccionados en el área de réplica pero, dado que se eligió la opción de excluir los registros relacionados, las anotaciones asociadas a los edificios y las parcelas no se replican.

Ejemplo cuatro

En este ejemplo, aunque el área de réplica incluye cuatro propiedades (17691, 17692, 17698, 17697) que tienen edificios relacionados, todos los edificios se han excluido explícitamente de la replicación. Puesto que el comportamiento predeterminado global consistente en incluir los objetos relacionados siempre está todavía en efecto para las demás clases de entidad, las anotaciones de propiedad se incluirán de nuevo en la réplica.

Ejemplo cinco

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.

Para obtener un resultado predecible en el caso de las relaciones circulares, puede elegir no procesar una de las relaciones o elegir el procesamiento hacia atrás para una de las clases de relación. Por ejemplo, el diagrama siguiente muestra el caso donde R3 está establecido para procesar hacia atrás. Ahora el orden de procesamiento es previsiblemente T1 - T2 - T3. Aquí, T3 tendrá registros relacionados agregados desde T1 y T2, pero ningún registro de T3 se agregará a T1 o T2.

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, 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. Algunas buenas alternativas son las siguientes:

• Clases de relación con un campo de clave principal de tipo GlobalID y un campo de clave externa de tipo GUID
• Su propio campo de clave principal, que es único entre 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 recibir el mismo ObjectID que una fila completamente 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 donde se puede ver comportamiento inesperado:

• Ediciones donde la fila de origen no existe en la geodatabase de réplica objetivo: como ya se ha descrito, el proceso de sincronización realiza procesamiento adicional para mantener las relaciones cuando un campo ObjectID es el campo de 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 producirá con las réplicas checkout.

  

  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 parcele con ObjectID 102 en el elemento primario) no existe en las geodatabases de la 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 sobre la base de la definición de 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. Estas claves externas quedan pendientes, puesto que la fila del origen a la que hacen referencia no existe en la geodatabase objetivo.

  

  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 parcelas que estén fuera del bloque tendrán 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.