Examinez les conseils, les outils et les fonctionnalités propres à ArcGIS Pro lors de l’utilisation des données associées à partir d’une classe de relations.
Copier des données dans une classe de relations
Vous pouvez copier n’importe quel jeu de classes d’entités, classes d’entités ou table à partir d’une géodatabase dans une géodatabase de destination à l’aide de Copy (Copier)
et Paste (Coller) 
. Pour chaque jeu de classes d'entités, classe d'entités et table que vous copiez et collez, le résultat est un nouveau jeu de classes d'entités, une nouvelle classe d'entités et une nouvelle table dans la géodatabase de destination avec toutes les entités ou tous les enregistrements provenant des données source.
Lors d'une opération de copie et de collage, vous copiez également les données dépendantes. Imaginons que vous copiez une classe d’entités ou une table qui fait partie d’une classe de relations. En pareille situation, la classe de relations et toutes les autres classes d’entités ou tables de la classe de relations sont également copiées. Il en va de même pour une classe d’entités avec une annotation liée aux entités ; cette dernière est également copiée. Lorsque vous copiez une classe d’entités avec des règles attributaires, les règles attributaires et toute classe d’entités ou séquences supplémentaires à lesquelles les règles font référence sont copiées. Pour une classe d'entités qui possède un domaine, un sous-type ou un index, le domaine, le sous-type ou l'index est également copié.
Attention :
L’outil de géotraitement Classe d’entités vers géodatabase copie uniquement les classes d’entités simples. Par exemple, si des classes d’entités sont incluses dans les jeux de classes d’entités à exporter, seules les classes d’entités sont copiées. Le jeu de classes d’entités et tous les éléments avancés, comme les topologies, les classes de relations ou les pièces jointes, ne sont pas copiés dans la géodatabase en sortie.
Mise à jour des données dans une classe de relations
Une classe de relations peut être configurée de telle sorte que lorsque vous modifiez un objet, les objets liés sont automatiquement mis à jour. Cette opération peut impliquer le déplacement physique des entités liées, la suppression des objets liés ou encore la mise à jour d’un attribut. Par exemple, vous pouvez configurer une relation de sorte que dès que vous déplacez un poteau électrique, les transformateurs et les autres équipements rattachés se déplacent avec lui. En définissant des règles, une classe de relations peut restreindre le type de relations qui sont valides. Par exemple, un pylône peut supporter trois transformateurs au maximum. Un pylône en acier peut supporter des transformateurs de classe A, mais pas des transformateurs de classe B. Les classes de relations maintiennent activement l’intégrité référentielle entre les classes liées, même si l’une d’entre elles n’a pas été ajoutée à la session ArcGIS Pro. Lorsqu’un objet qui participe à des relations simples avec d’autres objets est supprimée de la géodatabase, toutes ses relations sont également supprimées. Si l’objet supprimé correspond à l’objet d’origine, la clé étrangère de tous les objets de destination liés est nulle. L’objet d’origine n’est pas affecté si l’objet supprimé est un objet de destination.
Supposons que les relations sont conservées sous forme de lignes dans une table intermédiaire (relations plusieurs vers plusieurs ou relations attribuées). Lorsqu’un objet d’origine ou de destination et ses relations sont supprimés, les lignes correspondant à ces relations sont supprimées de la table intermédiaire.
Dans la fenêtre Attributes (Attributs) 
, vous pouvez créer et supprimer des relations entre les entités sélectionnées et ajouter de nouvelles relations entre les entités sélectionnées et des enregistrements non spatiaux dans une table. Les entités associées doivent participer à la même classe de relations.
Pour plus d’informations sur la mise à jour des données dans une classe de relations, consultez Modifier les relations d’entités.
En procédant à des mises à jour automatiques des objets liés, une classe de relations vous épargne de devoir effectuer des opérations de mises à jour supplémentaires.
Pour en savoir plus sur la mise à jour et la gestion des classes de relations, et de leurs données associées, lorsqu’elles sont stockées dans une géodatabase d’entreprise, reportez-vous à la rubrique Versionnement des données dans une classe de relations.
Suivi de l’éditeur et classes de relations
Le suivi de l’éditeur inclut un paramètre pour les classes d’entités et les tables qui enregistre automatiquement des informations sur les insertions et les mises à jour effectuées dans la classe. Il conserve un enregistrement de l’éditeur ayant créé ou modifié les données, ainsi qu’un horodatage de la mise à jour. Le suivi de l’éditeur s’applique uniquement aux opérations sur les jeux de données existants, et non aux opérations qui créent des jeux de données.
Tous les types de classes de relations ne prennent pas en charge le suivi de l’éditeur. Lorsqu’une classe de relations est créée avec une cardinalité de type plusieurs vers plusieurs (M:N) ou avec des attributs, une table intermédiaire est créée. Le suivi d’éditeur peut uniquement être activé sur des classes de relations basées sur des tables (c’est-à-dire, des classes de relations plusieurs vers plusieurs ou attribuées). 
Définir la règle de fractionnement de la classe de relations
Lorsqu’une classe d’entités linéaires ou surfaciques est créée, un modèle de fractionnement est automatiquement défini par défaut sur la classe d’entités. Le modèle de fractionnement détermine la façon dont la géométrie de l’entité et les attributs dans la table sont divisés lorsqu’une entité est fractionnée lors d’une mise à jour.
Outre la définition du modèle de fractionnement sur une classe d’entités, vous pouvez également définir la règle de division sur une classe de relations. La règle de fractionnement de la classe de relations détermine le mode de traitement des enregistrements liés dans la table de destination lorsqu’une entité de la classe d’entités d’origine est divisée au cours de la mise à jour.
En fonction du type de la classe de relations (simple ou composite), il est possible de définir des comportements de règle différents, comme Default (simple) (Par défaut (simple)), Default (composite) (Par défaut (composite)) et Duplicate related objects (Dupliquer les objets associés).
Pour plus de détails sur la procédure de définition et d’utilisation de cette propriété de la classe de relations, reportez-vous à la rubrique Définir la règle de fractionnement de la classe de relations.
Utiliser les attributs de la relation
ArcGIS Pro contient des outils contribuant à établir et maintenir une relation.
- Si vous possédez des objets dans l’origine et la destination, mais qu’ils ne sont pas liés, vous pouvez établir manuellement les relations, une à une, dans ArcGIS Pro. Pour cela, sélectionnez un ou plusieurs objets dans la destination, sélectionnez un ou plusieurs objets dans l’origine, puis ouvrez la boîte de dialogue Attributes (Attributs) et reliez-les. Il est nécessaire qu’au moins un côté de la relation contienne des entités.
- Vous pouvez sélectionner un objet et créer un objet lié dans une classe liée s’il s’agit d’un nouvel enregistrement dans une table et non d’une entité.
- Vous pouvez supprimer un objet d’une relation dans la boîte de dialogue Attributes (Attributs).
- Lorsque vous avez terminé la mise à jour d’une relation composite ou d’une relation avec des règles, vous pouvez utiliser les règles attributaires de validation ou de contrainte pour vérifier votre travail et appliquer l’intégrité référentielle de vos données.
Index attributaires sur les classes de relations attribuées
Les index attributaires peuvent accélérer les jointures et localiser facilement des enregistrements correspondant à une requête attributaire sur les tables, classes d’entités, shapefiles ou classes de relations attribuées.
Pour la plupart des requêtes attributaires, rechercher un enregistrement à l’aide d’un index est plus rapide que de parcourir la totalité de la table en commençant par le premier enregistrement. Une fois que vous avez des données dans une table, une classe d’entités, un shapefile ou une classe de relations attribuées, vous pouvez créer des index attributaires pour les champs que vous interrogez fréquemment.
En savoir plus sur les index attributaires dans la géodatabase
Règles attributaires sur les données dans une classe de relations
Des règles attributaires permettent de lire et mettre à jour des enregistrements associés de jeux de données qui participent à des classes de relations dans une géodatabase.
Des règles peuvent être appliquées aux classes d’entités et tables participant à des classes de relations, qui incluent des pièces jointes et des annotations liées aux entités. Des règles attributaires peuvent également intercepter des événements de mises à jour effectuées dans les classes d’origine et de destination d’une relation (à savoir, l’ajout, le retrait ou la suppression d’un enregistrement associé). Par exemple, une règle attributaire de calcul immédiat peut mettre à jour un champ attributaire lorsqu’une entité est ajoutée à une classe d’entités associée.
Si vous utilisez des classes de relations, vous pouvez lire les enregistrements associés à l’aide de fonctions Arcade qui renvoient les enregistrements liés des entités en entrée. Les enregistrements associés de classes de relations peuvent également être mis à jour à l’aide de règles de calcul en fonction du renvoi du dictionnaire.
Les fonctions et expressions de script Arcade peuvent être utilisées dans des règles attributaires de calcul afin d’accéder aux données associées dans une classe de relations. Lisez les enregistrements associés d’une classe de relations à l’aide des fonctions Arcade FeatureSetByName, FeatureSetByRelationShipName et FeatureSetByRelationshipClass. Vous pouvez également ajouter un nouvel enregistrement associé pour une classe de relations lors d’une modification de type mise à jour. 
Attention :
Lorsqu’une classe de relations plusieurs vers plusieurs ou décrites par des attributs est créée, une table intermédiaire est créée. Cette table intermédiaire n’est pas reconnue comme une classe d’objets dans la géodatabase. Par conséquent, les comportements de géodatabase comme les règles attributaires, les domaines, les sous-types, les valeurs conditionnelles et les valeurs par défaut ne peuvent pas être appliqués ni utilisés avec ce type de table intermédiaire.
Les règles attributaires de validation ou decontrainte peuvent être créées ou appliquées pour respecter les règles de la classe de relations.
En savoir plus sur les règles attributaires et les classes de relations et sur les règles de classe de relations de validation.
Versionnement des données dans une classe de relations
Pour permettre à d’autres utilisateurs de la base de données d’afficher ou de modifier le contenu des données dans une base de données ou une géodatabase d’entreprise, vous devez leur accorder les privilèges correspondants.
Lorsque des privilèges sont accordés à une classe d’entités ou table qui participe à une classe de relations, les privilèges doivent être accordés à la classe d’origine ainsi qu’à la classe de destination. Si les classes d’entités d’origine et de destination se trouvent dans le même jeu de classes d’entités, elles ont le même ensemble de privilèges, puisque ces derniers sont accordés au niveau du jeu de classes d’entités. Toutefois, lorsque les classes d’origine et de destination ne sont pas dans le même jeu de données d'entité, vous devez vous assurer qu'elles bénéficient toutes deux des privilèges appropriés. Si la classe de relations est décrite par des attributs ou a une cardinalité de type plusieurs vers plusieurs, les privilèges sont automatiquement propagés à la table intermédiaire lorsque vous attribuez les privilèges à la classe d’origine.
Les classes de relations sont stockées et demeurent dans la géodatabase. Elles facilitent la mise à jour. Une classe de relations dans une géodatabase d’entreprise est prise en charge avec les options de processus de mise à jour suivantes :
- Versionnement de branche
- Versionnement traditionnel
- Versionnement traditionnel (déplacement des mises à jour dans la base)
- Mise à jour non versionnée
Lorsque les classes de relations et les données associées sont stockées dans une géodatabase d’entreprise, les mises à jour apportées aux données peuvent être gérées par le biais de versions. Dans une géodatabase d’entreprise avec plusieurs éditeurs, les versions permettent aux différents utilisateurs d’utiliser et de mettre à jour les mêmes entités ou enregistrements simultanément sans appliquer de verrouillages ou dupliquer des données. Les versions offrent à chaque éditeur sa propre vue unique et isolée des données.
Conseils sur les classes de relations en lien avec le versionnement de branche
Vous ne pouvez pas inscrire un jeu de données en tant que branche versionnée si le jeu de données fait partie d’une classe de relations et si la clé primaire de la relation est le champ ObjectID.
Conseil :
Utilisez l’outil de géotraitement Migrer la classe de relations pour migrer une classe de relations basées sur un ID d’objet vers une classe de relations basées sur un ID global.
En savoir plus sur l’inscription d’un jeu de données en tant que branche versionnée
Dans le cadre du versionnement de branche, des conflits peuvent être détectés durant le processus de réconciliation lorsque la version nommée est réconciliée avec la version par défaut. Par exemple, un conflit survient lorsqu’une entité ou une classe de relations liée topologiquement est modifiée dans la version nommée actuelle et la version par défaut.
Conseil :
Examinez les conflits de mise à jour de la version nommée et de la version par défaut dans la vue Conflicts (Conflits). 
Dans le cadre du versionnement de branche, lorsque vous résolvez des conflits, vous choisissez la représentation des entités et des attributs que vous souhaitez conserver. La suppression d’une entité d’une classe de relations source risque de générer un message entraînant la suppression d’une entité de la classe de relations destinataire. Soyez conscients des ramifications lorsque vous décidez d’effectuer un remplacement lors de conflit impliquant des classes d’entités source qui font partie de classes de relations.
Conseils sur les classes de relations en lien avec le versionnement traditionnel
Le versionnement traditionnel offre une souplesse d’utilisation des versions pour les transactions longues lorsque vous y accédez directement depuis la géodatabase d’entreprise, ainsi qu’une expérience de mise à jour simplifiée lorsque vous utilisez des services d’entités pour les transactions plus courtes.
Le versionnement traditionnel avec la possibilité de déplacer les mises à jour dans la base est une forme facultative de versionnement traditionnel. Elle permet aux éditeurs et aux applications d’accéder directement aux données de base tout en permettant aux autres éditeurs d’utiliser leurs propres versions isolées. Cette option de versionnement tire parti de nombreux avantages du versionnement traditionnel. Toutefois, vous pouvez seulement mettre à jour des entités simples telles que des points, des lignes, des polygones, des annotations et des classes de relations. Vous ne pouvez pas modifier de classe d’entités dans une topologie, un jeu de données réseau ou un réseau de distribution.
Dans le cas du versionnement traditionnel, les conflits peuvent être détectés durant l’opération de réconciliation lorsque vous enregistrez des mises à jour dans une version et que la même entité a été actualisée dans cette version au cours d’une session de mise à jour différente (ou qu’elle est actualisée dans une session de mise à jour et supprimée dans l’autre).
Conseil :
Dans le cas du versionnement traditionnel, si votre processus prévoit qu’un utilisateur effectue la mise à jour et qu’un autre effectue la réconciliation, vous devez vous assurer que ce dernier bénéficie d’autorisations complètes sur l’ensemble des classes d’entités et des tables qui ont été modifiées dans la version. Si ce n’est pas le cas, l’utilisateur ne peut pas procéder à la réconciliation. Comme indiqué dans la section ci-dessus en ce qui concerne l’attribution de privilèges, l’utilisateur qui effectue la réconciliation doit bénéficier d’autorisations complètes sur les classes d’origine et de destination participant à une classe de relations modifiée, y compris les relations simples ou composites. Lors de ce processus, l’utilisateur qui procède à la réconciliation doit également disposer d’autorisations suffisantes sur la version. Il doit pouvoir modifier la version à réconcilier (qui doit donc être publique) et afficher la version cible (qui doit donc lui appartenir ou être publique ou protégée).
Dans le cas du versionnement traditionnel, lorsque vous résolvez des conflits, vous choisissez la représentation des entités et des attributs que vous souhaitez conserver. La suppression d’une entité d’une classe de relations source risque de générer un message entraînant la suppression d’une entité de la classe de relations destinataire. Soyez conscients des ramifications lorsque vous décidez d’effectuer un remplacement lors de conflit impliquant des classes d’entités qui font partie de classes de relations. Par exemple, dans un jeu de classes d’entités d’installations électriques, si vous supprimez un pylône lié à un ou plusieurs transformateurs, ceux-ci sont également supprimés.
Utiliser la réplication de géodatabase avec les classes de relations
La réplication de géodatabase vous permet de répliquer tous les jeux de données d’une géodatabase d’entreprise, ou certains d’entre eux. Elle permet de définir les entités ou lignes à répliquer à l’aide de filtres et de classes de relations. 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. Les classes de relations servent à ajouter des entités et des lignes supplémentaires.
L’exemple suivant illustre le comportement de la réplication concernant les objets associés. Le modèle de données utilisé dans cet exemple correspond à une relation origine-destination simple entre des propriétés, des bâtiments et leurs annotations liées.
Reportez-vous à la rubrique Préparer les données à répliquer pour plus d’informations.
La synchronisation conserve les relations. Pour la réplication monodirectionnelle et bidirectionnelle, les filtres et les règles de classes de relations utilisés lors de la création de réplica sont également appliquées pendant la synchronisation. Toutes les modifications apportées dans chaque jeu de données de réplica depuis la dernière synchronisation sont évaluées au moment de déterminer les modifications à envoyer. Si une mise à jour correspond aux filtres du réplica, celle-ci est synchronisée.
Par exemple, certaines entités d’une classe d’origine (des bâtiments) ont été sélectionnées pour être répliquées. Les bâtiments sont liés via une classe de relations simples à des enregistrements attributaires d’une table exclus de la réplication. Pendant la mise à jour du réplica enfant, un bâtiment a été supprimé. Lors de la synchronisation, afin d’annuler la relation avec l’entité supprimée, l’entrée correspondante figurant dans le champ de clé étrangère de la classe de destination associée, la table, est définie sur NULL.
Partager des jeux de données contenant une classe de relations
Les services d’entités permettent d’effectuer des requêtes sur les données liées, mais uniquement si la relation est définie via une classe de relations de géodatabase et que les tables d’origine et de destination se trouvent dans la carte avant la publication.
Pour autoriser des requêtes sur des données liées dans un service d’entités ou une couche d’entités hébergée, définissez une classe de relations entre la classe d’entités et la table ou classe d’entités associée. Les données apparentées accessibles par le biais d’une classe de relations seront incluses dans le service d’entités que vous publiez. Pour prendre en charge des requêtes qui renvoient des objets liés, vous devez inclure la table et la couche de la classe de relations dans la carte publiée. Le service d’entités ignore la relation si la carte ne contient pas la couche d’origine ou de destination ou la table.
Remarque :
Pour les classes de relations attribuées, incluez la table de classes de relations dans la carte.
En savoir plus sur la préparation des données en vue de publier un service d’entités, la création d’un service d’entités et l’utilisation des données liées via des services (vidéo).
Rubriques connexes
Vous avez un commentaire à formuler concernant cette rubrique ?