Réplication et données reliées

Disponible avec une licence Standard ou Advanced.

Pendant la création d’un réplica, les lignes et les entités sont ajoutées à un réplica d’après les filtres définis dans l’application. Lorsque cette opération est terminée, les classes de relations sont traitées pour inclure des objets associés supplémentaires.

Le traitement des classes de relations consiste à évaluer chaque jeu de données faisant partie d’au moins une classe de relations. Lors de l’évaluation d’un jeu de données, toutes les lignes ayant déjà été répliquées sont recueillies et utilisées pour effectuer une requête sur les lignes associées dans les jeux de données reliés. Toutes les lignes associées renvoyées par les requêtes sont ajoutées au réplica. Chaque jeu de données est visité une fois au cours de ce processus.

Dans ArcGIS Pro, une classe de relations est toujours traitée dans un seul sens, vers l’avant. La direction vers l’avant correspond à une évaluation de la classe d’origine, en vue d’ajouter les lignes reliées issues de la classe de destination au réplica. Vous pouvez également désactiver les classes de relations lors de la création d’un réplica.

Les exemples suivants illustrent le comportement de la réplication en fonction des objets associés. Le modèle de données utilisé dans ces exemples correspond à une relation origine-destination simple entre des propriétés, des bâtiments et leurs annotations liées.

Exemple 1

Cet exemple représente la zone de réplication couvrant huit parcelles et six bâtiments. Lors de la création du réplica, deux bâtiments supplémentaires sont ajoutés, car ils sont liés aux parcelles. Par ailleurs, des annotations relatives aux bâtiments et aux parcelles sont ajoutées au réplica lors du traitement des classes de relations.

Dans l’exemple ci-dessus, un réplica a été créé avec le comportement par défaut qui inclut des objets associés. Dans ArcGIS Pro, vous pouvez personnaliser la réplication et remplacer globalement ce comportement à l’aide de l’outil de géotraitement Créer un réplica. Au niveau global, vous pouvez configurer le processus de réplication de manière à n’inclure aucun objet associé en relation avec les entités identifiées pour la réplication.

Exemple 2

Cet exemple illustre le fonctionnement d’une relation circulaire. Au cours du processus de création de réplica, la logique appliquée au système permet d’interrompre le cycle et d’éviter que le traitement génère une boucle sans fin. Cependant, cette logique est telle que l’ordre de traitement des relations est imprévisible.

Classes de relations dans lesquelles un champ ObjectID est le champ de clé primaire

Une réplication avec des classes de relations qui utilisent un champ ObjectID comme champ de clé primaire nécessite un traitement supplémentaire pendant la synchronisation, ce qui risque d’impacter les performances. Ceci peut également entraîner un comportement inattendu dans certains cas. Ces derniers sont décrits en détail ci-après. À la fin de cette section, libre à vous de modifier vos classes de relations de sorte qu’elles utilisent d’autres champs de clé primaire que le champ ObjectID. Les solutions de rechange suivantes sont bonnes à envisager :

• Classes de relations avec un champ de clé primaire de type GlobalID et un champ de clé étrangère de type GUID
• Créer et utiliser votre propre champ de clé primaire, unique dans toutes les bases de données

Traitement supplémentaire lors de la synchronisation, lorsque le champ ObjectID est le champ de clé primaire

Les valeurs ObjectID d’une classe d’entités ou d’une table ne sont pas uniques d’une géodatabase à l’autre. Il est possible d’attribuer à une nouvelle ligne dans une géodatabase de réplica le même champ ObjectID qu’une ligne différente dans l’autre géodatabase de réplica. Le processus de synchronisation doit tenir compte de ces différences lors du transfert des relations d’une géodatabase de réplica à l’autre, lorsque la clé primaire de la relation est une colonne ObjectID . Pour ce faire, le processus de synchronisation détecte les classes de relations utilisant la colonne ObjectID. Si de telles classes existent, le processus de synchronisation transmet des informations supplémentaires qui seront utilisées pour effectuer un traitement supplémentaire.

Ce traitement consiste à ajuster les valeurs de clé étrangère afin d’atteindre la valeur ObjectID appropriée dans la géodatabase cible pour chaque relation mise à jour. Lorsqu’un grand nombre de relations sont mises à jour, ce traitement supplémentaire peut avoir un effet notable sur les performances de la synchronisation.

Comportement inattendu lorsque le champ ObjectID est le champ de clé primaire

La section suivante décrit les cas où il est possible d’observer un comportement inattendu lorsque le champ ObjectID est utilisé comme champ de clé primaire :

• Mises à jour où la ligne d’origine n’existe pas dans la géodatabase de réplica cible : comme décrit précédemment, le processus de synchronisation effectue un traitement supplémentaire pour conserver les relations lorsqu’un champ ObjectID est le champ de clé primaire dans une classe de relations. Cependant, une relation n’est pas conservée si la mise à jour fait référence à une ligne d’origine qui n’existe pas dans la géodatabase du réplica associé. Dans le cas d’une insertion, la clé étrangère est alors définie sur la valeur Null dans la ligne de destination. Dans le cas d’une mise à jour, la clé étrangère conserve la valeur qu’elle avait avant la synchronisation dans la ligne de destination. Il convient de préciser que ce comportement ne se manifeste pas avec les réplicas d’extraction/insertion.

  

  • Le diagramme ci-dessus représente le cas d’une classe de relations simple entre des parcelles et des bâtiments, dans laquelle le champ ObjectID de la classe d’entités des parcelles est la clé primaire d’origine. Dans cet exemple, un réplica est créé uniquement pour les parcelles et les bâtiments dans une étendue spatiale. Une fois le réplica créé, cependant, une erreur de numérisation est détectée là où il s’avère qu’un bâtiment a été numérisé dans la mauvaise parcelle. Cette erreur est corrigée dans la géodatabase du réplica parent grâce au déplacement du bâtiment et à la mise à jour de la relation de manière à lier le bâtiment à la parcelle adéquate. Le réplica est ensuite synchronisé pour que les modifications soient appliquées au réplica enfant. Dans ce cas précis, le bâtiment a été déplacé, mais il est toujours lié à la mauvaise parcelle dans le réplica enfant. En effet, la relation n’a pas été modifiée dans le réplica enfant car la ligne d’origine correcte (parcelle dont l’ObjectID est 102 dans le réplica parent) n’existe pas dans les géodatabases du réplica enfant. Dans ces cas, les relations ne sont donc pas modifiées.

• Clés étrangères pendantes : lors de la création d’un réplica, les lignes sont copiées depuis la géodatabase source vers la géodatabase cible en fonction du mode de définition du réplica. Lors de la définition du réplica, vous avez la possibilité d’inclure des lignes de la table de destination sans les lignes associées de la table d’origine. Les valeurs de clé étrangère dans la table de destination relatives à ces lignes non associées sont identiques à celles figurant dans la géodatabase source. Il s’agit de clés étrangères pendantes puisque la ligne d’origine qu’elles référencent n’existe pas dans la géodatabase cible.

  

  • Le diagramme ci-dessus fournit un exemple du comportement inattendu que des clés étrangères pendantes peuvent provoquer. Dans cet exemple, la géodatabase du réplica parent possède une classe de relations simple entre les parcelles et les bâtiments. La classe d’entités des parcelles constitue l’origine et utilise le champ ObjectID comme clé primaire. Un réplica est créé pour inclure tous les bâtiments de la ville et les parcelles d’un îlot de bâtiments. Au cours du processus de création du réplica, les parcelles et bâtiments appropriés sont copiés depuis la géodatabase du réplica parent vers la géodatabase du réplica enfant. Dans le réplica enfant, les bâtiments liés aux parcelles à l’extérieur de l’îlot de bâtiments possèdent des clés étrangères pendantes, étant donné que ces parcelles ne font pas partie du réplica. Par exemple, le bâtiment dont la clé étrangère est 100 possède une clé étrangère pendante, étant donné que la parcelle dont l’ObjectID est 100 n’existe pas dans l’enfant. Si une nouvelle parcelle est créée dans le réplica enfant et qu’un ObjectID de 100 lui est attribué, elle sera mécaniquement liée au bâtiment.