Lors de la création d’un réplica, les lignes et les entités y sont ajoutées en fonction des filtres définis dans l’application. Ensuite, les classes de relations sont traitées pour inclure des objets reliés supplémentaires.
Le traitement des classes de relations nécessite d’évaluer chacun des jeux de données qui font partie d’au moins une classe de relations. Lors de l’évaluation d’un jeu de données, toutes les lignes déjà répliquées sont collectées et utilisées pour rechercher les lignes reliées dans les jeux de données associés. Toutes les lignes reliées renvoyées par les requêtes sont ajoutées au réplica. Chaque jeu de données est consulté une fois pendant ce traitement.
Dans ArcGIS Pro, une classe de relations est toujours traitée dans un seul sens, vers l’avant. Un traitement vers l’avant consiste à évaluer la classe d’origine pour ajouter des lignes reliées de la classe cible au réplica. Il est également possible de désactiver le traitement des 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 reliés. Le modèle de données utilisé dans ces exemples est une relation simple de type origine-destination entre les propriétés, les bâtiments et leur annotation.
Exemple 1
Cet exemple montre la zone de réplica recouvrant huit parcelles et six bâtiments. Lorsque le réplica est créé, deux bâtiments supplémentaires sont ajoutés du fait qu’ils sont reliés aux parcelles. Le traitement de la classe de relations ajoute également l’annotation des bâtiments et des parcelles au réplica.
Dans l’exemple ci-dessus, un réplica a été créé suivant le comportement par défaut qui consiste à inclure les objets reliés. Dans ArcGIS Pro, il est possible de personnaliser la réplication et de remplacer globalement ce comportement à l’aide de l’outil de géotraitement Créer un réplica. Au niveau global, il est possible de configurer la réplication de manière à ne pas y inclure les objets reliés associés aux entités retenues pour la réplication.
Exemple 2
Cet exemple décrit le fonctionnement d’une relation circulaire. Au cours du processus de création du réplica, le système applique une logique pour rompre la relation circulaire et l’empêcher ainsi de se poursuivre indéfiniment en boucle. Toutefois, la nature même de cette logique fait qu’il est impossible de prédire l’ordre de traitement des relations.
Classes de relations dont le champ de clé primaire est un champ ObjectID
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. Ce scénario est décrit dans le 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. Voici les variantes possibles :
- Classes de relations avec un champ de clé primaire de type GlobalID et un champ de clé étrangère de type GUID
- Création et utilisation de votre propre champ de clé primaire, unique dans toutes les bases de données
Traitement supplémentaire pendant la synchronisation dans le cas où 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 exclusives dans toutes les géodatabases. Une nouvelle ligne d’une géodatabase de réplica peut se voir allouer la même valeur ObjectID qu’une ligne complètement différente d’une autre géodatabase de réplica. Le processus de synchronisation doit tenir compte de ces différences pour le transfert des relations dans les géodatabases de réplica lorsque la clé primaire de la relation est une colonne ObjectID . Pour ce faire, le processus de synchronisation recherche les classes de relations qui utilisent la colonne ObjectID. Si des classes de cette nature sont détectées, le processus de synchronisation transmet des informations supplémentaires qui sont ensuite utilisées pour effectuer un traitement supplémentaire.
Le traitement nécessite d’ajuster les valeurs de clé étrangère de façon à cibler la valeur ObjectID correspondante dans la géodatabase cible pour chaque relation modifiée. S’il existe de nombreuses relations modifiées, ce traitement supplémentaire peut nuire sensiblement à la synchronisation.
Comportement inattendu lorsque le champ ObjectID est le champ de clé primaire
Voici les cas dans lesquels il est possible d’observer un comportement inattendu lorsque le champ ObjectID est utilisé comme champ de clé primaire :
- Mises à jour dont la ligne d’origine n’existe pas dans la géodatabase de réplica - Comme décrit précédemment, le processus de synchronisation exécute un traitement supplémentaire pour conserver les relations lorsqu’un champ ObjectID tient lieu de champ de clé primaire dans une classe de relations. Pour autant, une relation n’est pas conservée dans les cas où la mise à jour nécessite de référencer une ligne d’origine qui n’existe pas dans la géodatabase de réplica associé. Pour une insertion, la clé étrangère est alors définie comme étant nulle (valeur Null) dans la ligne de destination. Pour une mise à jour, la clé étrangère conserve sa valeur antérieure à 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.
- Dans le diagramme ci-dessus, il existe une classe de relations simple entre les parcelles et les bâtiments dont 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 compris dans une étendue spatiale. Une fois le réplica créé, la détection d’une erreur de numérisation révèle 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 par le déplacement du bâtiment et la mise à jour de la relation de manière à relier le bâtiment à la bonne parcelle. Le réplica est ensuite synchronisé pour appliquer les modifications au réplica enfant. Dans ce cas, le bâtiment a bien été déplacé, mais il reste relié à la mauvaise parcelle dans le réplica enfant. La relation n’a pas été rectifiée dans le réplica enfant du fait que la ligne d’origine correcte (parcelle portant l’ObjectID 102 dans le réplica enfant) n’existe pas dans les géodatabases du réplica enfant. En pareil cas, les relations ne sont pas modifiées.
- Clés étrangères pendantes - Lors de la création d’un réplica, les lignes sont copiées de la géodatabase source dans la géodatabase cible en fonction de la définition du réplica. Pour définir un réplica, vous pouvez choisir d’inclure les lignes de la table de destination sans les lignes reliées de la table d’origine. Les valeurs de clé étrangère de la table de destination pour ces lignes non reliées sont les mêmes que celles de 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 cas de figure illustré dans le diagramme ci-dessus montre que l’existence de clés étrangères pendantes peut donner lieu a un comportement inattendu. Ici, la géodatabase du réplica parent comporte 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 urbain. Le processus de création du réplica copie les parcelles et bâtiments correspondant de la géodatabase du réplica parent dans la géodatabase du réplica enfant. Dans le réplica enfant, les bâtiments reliés aux parcelles situées en dehors de l’îlot urbain ont des clés étrangères pendantes du fait que ces parcelles ne font pas partie du réplica. Par exemple, le bâtiment dont la clé étrangère a pour valeur 100 a une clé pendante puisque la parcelle dont l’ObjectID a pour valeur 100 n’existe pas dans l’enfant. Si une nouvelle parcelle est créée dans le réplica enfant, et qu’un ObjectID égal à 100 lui est attribué, elle est involontairement reliée au bâtiment.
Rubriques connexes
Vous avez un commentaire à formuler concernant cette rubrique ?