Réplication et données reliées

Cette rubrique concerne exclusivement ArcEditor et ArcInfo.

Lors de la création d'un réplica, les lignes et les entités sont ajoutées à un réplica en fonction des filtres définis dans l'application. Une fois cette opération terminée, les classes de relations sont traitées pour inclure des objets reliés supplémentaires.

Le traitement des classes de relations nécessite l'évaluation de chaque jeu de données participant à au moins une classe de relations. Lorsqu'un jeu de données est évalué, toutes les lignes qui ont déjà été répliquées sont regroupées et utilisées pour interroger les lignes des jeux de données reliés. Toutes les lignes reliées renvoyées par les requêtes sont ajoutées au réplica. Chaque jeu de données est visité une fois pendant ce processus.

Chaque classe de relations est traitée dans une seule direction. Par défaut, la direction est définie sur avant mais elle peut également être définie sur arrière lors de la création. Une direction avant signifie que la classe d'origine est évaluée pour ajouter des lignes reliées de la classe de destination au réplica. Une direction arrière signifie que la classe de destination est évaluée pour ajouter des lignes reliées de la classe d'origine au réplica. Vous pouvez également désactiver le traitement des classes de relations pour une classe de relations spécifique lors de la création du réplica.

Chaque jeu de données étant évalué une fois et chaque classe de relations étant traitée au plus dans une direction, l'ordre d'évaluation des jeux de données est important. Le système utilise une logique pour traiter les jeux de données dans l'ordre selon lequel les objets les plus reliés seront ajoutés. Vous pouvez modifier l'ordre de traitement des jeux de données en changeant de direction ou en désactivant le traitement de classes de relations spécifiques.

Les exemples suivants illustrent le comportement de réplication par rapport aux objets reliés. Le modèle de données utilisé dans ces exemples est une simple relation origine-destination entre les propriétés, les bâtiments et leur annotation reliée.

Exemple un

Cet exemple montre la zone de réplica couvrant huit parcelles et six bâtiments. Lorsque le réplica est créé, deux bâtiments supplémentaires sont ajoutés car ils sont reliés aux parcelles. Le traitement des classes de relations ajoute également les annotations des bâtiments et des parcelles au réplica.

Exemple deux

Cet exemple montre la réplication de relations à l'aide d'un traitement avant. En sélectionnant les deux bâtiments du réplica parent à répliquer et en utilisant la direction de traitement avant par défaut pour les enregistrements reliés, les annotations reliées à ces bâtiments sont également répliquées dans l'enfant.

Le diagramme suivant présente un cas où vous choisissez ces deux bâtiments mais décidez d'utiliser une direction de traitement arrière pour la classe de relations prop_build. Ici, outre les annotations de bâtiment reliées, les parcelles reliées à ces bâtiments sont incluses, ainsi que les annotations des parcelles.

Exemple trois

Dans les exemples précédents, un réplica a été créé selon le comportement par défaut, à savoir l'inclusion d'objets reliés. Il est possible d'ignorer ce comportement à un niveau global ou local afin de personnaliser chaque réplication. Au niveau global, le processus de réplication peut être configurée de manière à ne pas inclure les objets reliés associés aux entités qui doivent être répliquées.

Dans cet exemple, les bâtiments et les propriétés sont sélectionnés dans la zone du réplica, mais l'option permettant d'exclure les enregistrements reliés étant activée, les annotations associées aux bâtiments et aux parcelles ne sont pas répliquées.

Exemple quatre

Dans cet exemple, bien que la zone du réplica comprenne quatre propriétés (17691, 17692, 17698, 17697) qui possèdent des bâtiments reliés, tous les bâtiments ont été explicitement exclus de la réplication. Dans la mesure où le comportement par défaut global, correspondant à toujours inclure les objets reliés est encore en vigueur pour les autres classes d'entités, l'annotation de propriété est à nouveau incluse dans le réplica.

Exemple cinq

Cet exemple montre le résultat d'une relation circulaire. Lors du processus de création du réplica, le système applique une certaine logique pour briser le cercle et empêcher ainsi un traitement en boucle sans fin. Cependant, dans cette logique, l'ordre de traitement des relations reste imprévisible.

Pour obtenir un résultat prévisible avec des relations circulaires, vous pouvez choisir de ne pas traiter l'une des relations ou d'appliquer un traitement arrière à l'une des classes de relations. Par exemple, le diagramme suivant montre le cas où R3 est configuré pour un traitement arrière. L'ordre de traitement est désormais prévisible : T1 - T2 - T3. Ici, T3 contiendra des enregistrements reliés provenant de T1 et T2, mais aucun enregistrement de T3 ne sera ajouté à T1 ou T2.

Classes de relations où un champ ObjectID est le champ de clé primaire

La réplication de classes de relations où un champ ObjectID est utilisé comme un champ de clé primaire nécessite un traitement supplémentaire lors de la synchronisation, ce qui peut affecter les performances. Cette opération peut également entraîner un comportement inattendu dans certains cas. Les sections suivantes décrivent plus en détail ces situations. Après avoir examiné cette section, vous pouvez décider de modifier vos classes de relations pour utiliser des champs de clé primaire autres que le champ ObjectID. Voici quelques bonnes alternatives :

• L'utilisation de classes de relations avec un champ de clé primaire de type GlobalID et un champ de clé étrangère de type GUID
• L'utilisation de votre propre champ de clé primaire, lequel est unique dans toutes les bases de données.

Un traitement supplémentaire pendant la synchronisation lorsque le champ ObjectID est le champ de clé primaire.

Les valeurs ObjectID d'une table ou d'une classe d'entités ne sont pas uniques dans toutes les géodatabase. Une nouvelle ligne d'une géodatabase de réplica peut être associée au même ObjectID qu'une ligne totalement différente d'une autre géodatabase de réplica. Le processus de synchronisation doit tenir compte de ces différences lors du transfert de relations entre les géodatabases de réplica lorsque la clé primaire de la relation est une colonne ObjectID. Pour cela, le processus de synchronisation détecte les classes de relations qui utilisent la colonne ObjectID. Si de telles classes sont présentes, le processus de synchronisation transmet des informations supplémentaires utilisées ensuite pour effectuer le traitement supplémentaire. Le traitement implique l'adaptation des valeurs de clé étrangère en fonction de la valeur ObjectID cible de la géodatabase cible pour chaque relation modifiée. Dans les cas où un grand nombre de relations sont modifiées, ce traitement supplémentaire peut avoir un effet significatif sur les performances de synchronisation.

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

Les sections suivantes décrivent des cas pouvant entraîner un comportement inattendu :

• Mises à jour pour lesquelles la ligne d'origine n'existe pas dans la géodatabase de réplica cible : comme indiqué ci-dessus, le processus de synchronisation effectue un traitement supplémentaire pour gérer les relations lorsqu'un champ IdObjet est le champ de clé primaire d'une classe de relations. Cependant, la gestion d'une relation est impossible si la modification implique le référencement d'une ligne d'origine qui n'existe pas dans la géodatabase de réplica associée. Dans le d'une insertion, la clé étrangère est alors définie sur une valeur nulle dans la ligne de destination. Dans le cas d'une mise à jour, la clé étrangère conserve la valeur qu'elle affichait avant la synchronisation dans la ligne de destination. Notez que ce comportement n'affecte pas les réplicas d'extraction.

  

  Le diagramme ci-dessus montre une classe de relations simples entre des parcelles et des bâtiments, où le champ ObjectID de la classe d'entités parcelles est la clé primaire d'origine. Dans cet exemple, un réplica est créé uniquement pour les parcelles et les bâtiments figurant dans une étendue spatiale. Cependant, une fois le réplica créé, une erreur de numérisation signale qu'un bâtiment a été numérisé dans la mauvaise parcelle. Ce problème peut être résolu dans la géodatabase du réplica parent en déplaçant le bâtiment et en modifiant la relation afin de l'associer à la bonne parcelle. Le réplica est ensuite synchronisé pour appliquer les modifications apportées au réplica enfant. Cas où le bâtiment a été déplacé mais este lié à la mauvaise parcelle dans le réplica enfant : La relation n'a pas été modifiée dans le réplica enfant car la ligne d'origine correcte (la parcelle avec une valeur ObjectID de 102 dans le parent) n'existe pas dans les géodatabases du réplica enfant. Dans ce 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 vers la géodatabase cible selon la manière dont le réplica est défini. Lorsque vous définissez le réplica, vous pouvez choisir sélectionner des lignes de la table de destination sans inclure les lignes correspondantes dans la table d'origine. Les valeurs de clé étrangère de la table de destination pour ces lignes non reliées sont identiques à celles de la géodatabase source. Ces clés étrangères sont appelées "clés pendantes" car la ligne d'origine auxquelles elles font référence n'existe pas dans la géodatabase cible.

  

  Le diagramme ci-dessus montre un exemple de comportement inattendu provoqué par des clés étrangères pendantes. Ici, la géodatabase du réplica parent comporte une classe de relations simples entre des parcelles et des bâtiments. La classe d'entités parcelles représente l'origine et utilise le champ ObjectID comme clé primaire. Un réplica est créé afin d'inclure tous les bâtiments de la ville ainsi que les parcelles d'un quartier. Le processus de création du réplica copie les parcelles et les bâtiments correspondants de la géodatabase du réplica parent vers la géodatabase du réplica enfant. Dans le réplica enfant, les bâtiments reliés à des parcelles situées à l'extérieur du quartier comportent des clés étrangères pendantes puisque ces parcelles ne font pas partie du réplica. Par exemple, le bâtiment avec une clé étrangère de 100 affiche une clé étrangère pendante car la parcelle avec la valeur ObjectID 100 n'existe pas dans l'enfant. Si une nouvelle parcelle est créée dans le réplica enfant avec valeur ObjectID de 100, celle-ci sera involontairement reliée au bâtiment.