Paramètres de l’outil Créer une classe de relations

La définition des valeurs de paramètre lorsque vous exécutez l’outil de géotraitement Créer une classe de relations dépend du type de classe de relations dont vous avez besoin et des règles que vous devez appliquer.

Vous trouverez ci-dessous la description des paramètres en entrée de l’outil de géotraitement Créer une classe de relations pour vous permettre de déterminer les valeurs à utiliser :

Paramètres

Vous trouverez ci-après une explication de chaque paramètre de l’outil de géotraitement Créer une classe de relations :

• Origin Table (Table d’origine) : table ou classe d’entités à associer à la table de destination.
• Destination Table (Table de destination) : table à associer à la table d’origine.
• Output Relationship Class (Classe de relations en sortie) : nom de la classe de relations créée.
• Relationship Type (Type de relation) : indique le type de relation créé entre les tables d’origine et de destination.
  • Simple : les tables d’origine et de destination présenteront une relation simple. Il s’agit de l’option par défaut.
  • Composite : les tables d’origine et de destination présenteront une relation composite.
• Forward Path Label (Dénomination origine vers destination) : nom qui identifie de manière unique la relation lors de la navigation depuis la table d’origine vers la table de destination.
• Backward Path Label (Dénomination destination vers origine) : nom qui identifie de manière unique la relation lors de la navigation depuis la table de destination vers la table d’origine.
• Message Direction (Sens des messages) : sens dans lequel les messages sont transmis entre les tables d’origine et de destination. Par exemple, dans une relation entre des pylônes et des transformateurs, lorsqu’un pylône est supprimé, un message est transmis aux objets transformateurs auxquels il est relié pour indiquer que le pylône a été supprimé.
  • Forward (Vers l’avant) (origine vers destination) : les messages sont transmis depuis la table d’origine vers la table de destination.
  • Backward (Vers l’arrière) (destination vers origine) : les messages sont transmis depuis la table de destination vers la table d’origine.
  • Both directions (Les deux directions) : les messages sont transmis depuis la table d’origine vers la table de destination et inversement.
  • None (Aucun) (aucun message transmis) : aucun message n’est transmis. Il s’agit de l’option par défaut.
• Cardinality (Cardinalité) : indique le nombre de relations existant entre les lignes ou les entités de la table d’origine et les lignes ou les entités de la table de destination.
  • One to one (1:1) (Un vers un) : chaque ligne ou entité de la table d’origine peut être mise en relation avec zéro ou une ligne ou entité de la table de destination. Il s’agit de l’option par défaut.
  • One to many (1:M) (Un vers plusieurs) : chaque ligne ou entité de la table d’origine peut être mise en relation avec une ou plusieurs lignes ou entités de la table de destination.
  • Many to many (M:N) (Plusieurs vers plusieurs) : plusieurs lignes ou entités de la table d’origine peuvent être mises en relation avec une ou plusieurs lignes ou entités de la table de destination.
• Relationship class is attributed (Classe de relations décrite par des attributs) : indique si la classe de relations possède des attributs. Consultez la rubrique Comprendre les classes de relations décrites par des attributs pour en savoir plus sur l’emplacement de stockage de ces attributs et sur la procédure de création et de renseignement d’une classe de relations décrite par des attributs.
  • Activé : la classe de relations possède des attributs.
  • Désactivé : la classe de relations ne possède aucun attribut. Il s’agit de l’option par défaut.

• Origin Primary Key (Clé primaire d’origine) : pour les classes de relations un vers un ou un vers plusieurs qui ne possèdent aucun attribut, il s’agit du champ qui figure dans la table d’origine, souvent abrégé sous la forme PK (Primary Key), et qui est lié au champ Origin Foreign Key (Clé étrangère d’origine) de la table de destination.

  Pour les classes de relations plusieurs vers plusieurs ou décrites par des attributs, il s’agit du champ de la table d’origine lié au champ Origin Foreign Key (Clé étrangère d’origine) de la table intermédiaire de classes de relations.

• Origin Foreign Key (Clé étrangère d’origine) : pour les classes de relations un vers un ou un vers plusieurs qui ne possèdent aucun attribut, il s’agit du champ qui figure dans la table de destination, souvent abrégé sous la forme FK (Foreign Key), et qui est lié au champ Origin PrimaryKey (Clé primaire d’origine) de la table d’origine.

  Pour les classes de relations une vers plusieurs ou décrites par des attributs, il s’agit du champ de la table intermédiaire de classes de relations lié au champ Origin PrimaryKey (Clé primaire d’origine) de la table d’origine.

• Destination Primary Key (Clé primaire de destination) : champ de la table de destination lié au champ Destination Foreign Key (Clé étrangère de destination) de la table intermédiaire de classes de relations. Cette valeur est requise pour les classes de relations plusieurs vers plusieurs ou décrites par des attributs, mais doit rester vide pour les classes de relations un vers un ou un vers plusieurs qui ne sont pas décrites par des attributs.
• Destination Foreign Key (Clé étrangère de destination) : champ de la table intermédiaire de classes de relations lié au champ Destination Primary Key (Clé primaire de destination) de la table de destination. Cette valeur est requise pour les classes de relations plusieurs vers plusieurs ou décrites par des attributs, mais doit rester vide pour les classes de relations un vers un ou un vers plusieurs qui ne sont pas décrites par des attributs.

Classes d'origine et de destination

Lorsque vous créez une classe de relations, vous choisissez une classe comme origine et une autre comme destination. Il est important de distinguer les deux. Avec le comportement des suppressions en cascade dans les relations composites, cela semble évident.

Dans les relations simples, cela est essentiel. En effet, lorsqu’un enregistrement est supprimé dans la classe d’origine, la classe de relations simples recherche les enregistrements correspondants dans la classe de destination et définit la valeur de leur champ de clé sur Null (Nulle). Si vous vous trompez de classe d’origine et y supprimez des objets, des erreurs sont générées dans le champ de clé étrangère. L'exemple suivant illustre ce problème potentiel :

Il est important de distinguer les deux, en choisissant ce qui devrait être la destination comme origine et inversement.

Cas 1 : parcelle vers zone (incorrect)

Ce type d’erreur est courant. La table Zone contient les descriptions des différents codes de zonage et elle est semblable d’un point de vue conceptuel à une table de correspondance. Dans ce cas, la classe Parcelle est l'origine et la table Zone est la destination. Le problème est le suivant : lorsque vous supprimez une parcelle, la valeur du champ de clé (Zone) est définie sur Null pour l'enregistrement correspondant dans la table Zone et aucune des autres parcelles dotées de ce code de zonage n'a de correspondance dans la table Zone.

Cas 2 : zone vers parcelle (correct)

Pour rectifier le problème, définissez la table Zone comme origine. Supprimer une parcelle (objet de destination) n'a aucun effet sur la table Zone et supprimer un code Zone (objet d'origine) entraîne simplement la définition de la valeur du champ Zone dans les enregistrements de parcelle correspondants sur Null, ce qui est correct, car ils ne disposent plus d'un enregistrement de table Zone correspondant.

Nom de la classe de relations en sortie

Chaque classe de relations possède un nom qui apparaît dans la fenêtre Catalog (Catalogue). Il est recommandé de nommer la classe de relations avec un nom qui décrit les éléments participants ainsi que la cardinalité de la relation.

Commencez par le nom de la classe d'entités d'origine, suivi de Contient ou Contiennent, puis terminez par le nom de la classe d'entités de destination. Par exemple, AdresseContientZones ou ParcellesContiennentPropriétaires. Utilisez le pluriel dans le nom de la classe d'entités d'origine si elle est de cardinalité plusieurs vers un ou plusieurs vers plusieurs et utilisez le pluriel dans le nom de la classe d'entités de destination si elle est de type un vers plusieurs ou plusieurs vers plusieurs.

En suivant cette méthode, vous pouvez déterminer la cardinalité d'une classe de relations d'après son nom. Par exemple, si les deux classes d'entités sont au pluriel, le nom ParcellesContiennentPropriétaires suggère une relation de type plusieurs vers plusieurs.

Les noms doivent être uniques dans une géodatabase. Plusieurs objets (table, classe d’entités, classe de relations, etc.) ne peuvent pas porter le même nom. Consultez la rubrique Définir des propriétés de classe d’entités pour en savoir plus sur les règles et limitations appliquées aux noms de classe d’entités et de table.

Dénominations origine vers destination et destination vers origine

Les dénominations origine vers destination et destination vers origine s’affichent dans les boîtes de dialogue Attributes (Attributs) et Identify results (Identifier les résultats) dans ArcGIS Pro et vous permettent de naviguer parmi les objets reliés.

Une classe de relations comporte deux étiquettes :

• Une dénomination origine vers destination qui s’affiche lorsque vous vous déplacez depuis l’origine vers la destination. Dans l’exemple pylône-transformateur, cette étiquette pourrait être intitulée supporte, pour indiquer que ce pylône supporte ces transformateurs.
• Une étiquette arrière qui s'affiche lorsque vous naviguez de la destination vers l'origine. Dans l’exemple pylône-transformateur, cette étiquette pourrait être intitulée est monté sur, pour indiquer que ces transformateurs sont montés sur ce pylône.

Direction de notification des messages

Comme indiqué auparavant, lorsque vous supprimez un objet d'origine dans une relation composite, les objets de destination associés sont automatiquement supprimés.

Que vous utilisiez des relations simples ou composites, d'autres actions peuvent nécessiter la mise à jour d'une entité afin de déclencher la mise à jour de ses entités associées. En outre, les mises à jour peuvent être nécessaires dans une direction ou dans une autre, ou dans les deux.

• Lorsque vous déplacez ou faites pivoter une entité, les entités associées doivent se déplacer ou pivoter en même temps.
• Lorsque vous mettez à jour une entité, un attribut d'une entité associée doit être mis à jour en même temps.
• La mise à jour d'une origine peut nécessiter la mise à jour des objets de destination associés.
• La mise à jour des objets de destination associés peut nécessiter la mise à jour des objets d'origine.

Si votre relation requiert ce comportement, vous pouvez faire en sorte que les objets d'origine et de destination envoient des messages pour s'informer mutuellement des modifications qu'ils ont subies, ce qui permet de mettre à jour correctement les objets associés.

Pour ce faire, définissez la direction de notification des messages lorsque vous créez la relation. Si la mise à jour d’une origine nécessite la mise à jour des objets de destination reliés, définissez la direction de notification des messages sur Forward (Vers l’avant). Si la mise à jour de la destination nécessite la mise à jour des objets d’origine reliés, définissez la direction de notification des messages sur Backward (Vers l’arrière). Si les deux types de mise à jour sont nécessaires, définissez la direction de notification des messages sur Both (Les deux). Une fois la relation créée, vous devez programmer le comportement dans les objets qui reçoivent les messages afin qu’ils puissent répondre.

La seule exception concerne les relations composites lorsque le système de messagerie est défini sur Forward (Vers l’avant). Lorsque vous créez une relation composite avec le système de messagerie défini sur Avant, le déplacement ou la rotation d'un objet d'origine provoque le déplacement ou la rotation automatique des entités de destination associées. Si vous configurez correctement votre relation, cette fonctionnalité est active dès que vous créez la relation : aucune programmation personnalisée n'est requise.

Pour d'autres directions de notification des messages, une programmation personnalisée est nécessaire. Sauf si vous créez une relation composite avec un système de messagerie défini sur Forward (Vers l’avant) ou envisagez de programmer un comportement personnalisé, définissez la notification des messages sur None (Aucun). Sinon, les messages sont inutilement générés chaque fois que vous effectuez une opération de mise à jour, ce qui ralentit les performances.

Lorsque vous définissez la direction des relations composites, gardez à l'esprit que lorsque l'objet d'origine d'une relation composite est supprimé, tous les objets associés dans la destination sont automatiquement supprimés. C’est le cas lorsque le système de messagerie est défini sur Forward (Vers l’avant), Backward (Vers l’arrière), Both (Les deux) ou None (Aucun).

Directions de notification des messages

Itinéraire	Effet sur les relations simples	Effet sur les relations composites
Avant	Aucun effet sauf en cas de personnalisation avec programmation	La suppression de l’origine supprime la destination. Le déplacement ou la rotation de l’origine déplace ou fait pivoter la destination. Aucun effet sauf en cas de programmation d’un comportement personnalisé.
Arrière	Aucun effet sauf en cas de personnalisation avec programmation	La suppression de l’origine supprime la destination. Aucun effet sauf en cas de programmation d’un comportement personnalisé.
Les deux	Aucun effet sauf en cas de personnalisation avec programmation	La suppression de l’origine supprime la destination. Le déplacement ou la rotation de l’origine déplace ou fait pivoter la destination. Aucun effet sauf en cas de programmation d’un comportement personnalisé.
Aucun	Empêche l'envoi des messages, ce qui améliore légèrement les performances	La suppression de l’origine supprime la destination. Empêche l’envoi d’autres messages, ce qui améliore légèrement les performances.

Cardinalité

La cardinalité décrit le nombre maximal d’associations entre deux lignes ou colonnes de tables différentes.

Un SIG intègre des informations sur différents objets d’entités géographiques et non géographiques, qu’il est possible de mettre en relation pour bon nombre d’entre eux. Lorsque vous ajoutez des données non géographiques aux données d’entités, vous devez tenir compte des relations entre les objets et de l’éventuelle existence d’un champ commun.

Les relations font référence à une table d’origine ainsi qu’à une table de destination et définissent la manière dont les objets de la table d’origine sont reliés aux objets de la table destination. Pour créer une relation entre deux tables, vous devez identifier un champ commun doté de valeurs communes, appelé clé.

Remarque :

Les champs communs ne doivent pas nécessairement porter le même nom, mais doivent partager le même type de données. Les valeurs des champs communs permettent de lier les enregistrements de la table en fonction de la cardinalité définie.

La cardinalité d’une relation indique le nombre d’objets de la table d’origine reliés à un nombre défini d’objets de la table de destination. Trois cardinalités sont possibles pour une classe de relations :

• Un vers un : une ligne ou entité de la classe ou table d’origine peut être mise en relation avec zéro ou une ligne ou entité dans la classe ou table de destination. Il s’agit de la cardinalité par défaut. Par exemple, une parcelle ne peut comporter qu'une seule description légale.

  Remarque :

  Dans ArcGIS, cette cardinalité couvre également le type plusieurs vers un. Plusieurs parcelles associées à la même description légale sont un exemple de relation plusieurs vers un.

• Un vers plusieurs : une ligne ou entité de la classe ou table d’origine peut être mise en relation avec une ou plusieurs lignes ou entités dans la classe ou table de destination. Par exemple, une parcelle peut comporter plusieurs bâtiments. Dans une relation un vers plusieurs, le côté "un" doit être l'origine et le côté "plusieurs" doit être la classe de destination.
• Plusieurs vers plusieurs : un objet d’origine peut être mis en relation avec plusieurs objets de destination et, inversement, un objet de destination peut être mis en relation avec plusieurs objets d’origine. Par exemple, une propriété donnée peut comporter plusieurs propriétaires et un propriétaire donné peut posséder plusieurs propriétés. Pour en savoir plus, reportez-vous à la rubrique Comprendre les classes de relations décrites par des attributs.

Remarque :

Lors de l’évaluation de la cardinalité des objets entre deux tables, le terme « un » désigne réellement « zéro vers un » et « plusieurs » recouvre vraiment la notion de « zéro vers plusieurs ». Ainsi, lorsque vous créez une relation un vers plusieurs entre des parcelles et des bâtiments, par exemple, la relation permet tout ce qui suit :

• Une parcelle sans bâtiment
• Un bâtiment sans parcelle
• Une parcelle avec n'importe quel nombre de bâtiments

Une fois la classe de relations créée, vous pouvez affiner les cardinalités en ajoutant des règles à la classe de relations. Vous pouvez ajouter des règles qui spécifient le nombre de lignes ou d’entités dans la classe ou la table d’origine pouvant être mises en relation avec un nombre donné de lignes ou d’entités dans la classe de destination.

Remarque :

La cardinalité est définie lors de la création d’une classe de relations. Une fois la classe de relations créée, il n’est plus possible de modifier la cardinalité de cette dernière. Il est donc essentiel de prendre en compte et de vérifier la cardinalité des données avant de créer la classe de relations.

Clés primaires et étrangères

Dans une classe de relations, les objets de la table d’origine correspondent aux objets de la table de destination via les valeurs de leurs champs de clé.

Dans une classe de relations qui n’est pas décrite par des attributs, la relation est conservée lorsque les valeurs du champ Origin Primary Key (PK) (Clé primaire d’origine) de la table d’origine sont directement mises en relation avec les valeurs du champ Origin Foreign Key (FK) (Clé étrangère d’origine) de la table de destination. Contrairement à une vrai clé primaire, les valeurs du champ de clé primaire dans une relation ne doivent pas nécessairement être uniques pour chaque objet. Le champ de clé étrangère contient des valeurs qui correspondent à celles du champ de clé primaire dans la table d’origine. Dans ce cas également, les valeurs du champ de clé ne doivent pas nécessairement être uniques pour chaque ligne.

Par exemple, la parcelle 789 correspond aux permis 2 et 3 car tous ces enregistrements possèdent le même ID de parcelle.

Si vous le souhaitez, vous pouvez demander la création automatique d’une table intermédiaire dans une classe de relations décrite par des attributs lorsqu’une relation plusieurs vers plusieurs est créée. Cette table intermédiaire apparie les valeurs du champ Origin Foreign Key (Clé étrangère d’origine) et du champ Destination Foreign Key (Clé étrangère de destination) aux clés primaires des tables et classes d’entités reliées. Chaque ligne associe un objet d'origine à un objet de destination. Les champs de clé peuvent porter des noms différents, mais leur type de données doit être identique et ils doivent contenir le même genre d’informations, par exemple des ID de parcelle. Les champs de tous les types de données, à l'exception des champs BLOB (grand objet binaire), date et raster, peuvent être des champs de clé.

Par exemple, si vous souhaitez connaître les propriétaires des parcelles d’une communauté, une classe de relations plusieurs vers plusieurs peut-être créée entre la classe d’entités Parcel (Parcelle) et la table autonome Owner (Propriétaire). Cette classe de relations plusieurs vers plusieurs crée une table intermédiaire ou décrite par des attributs, ParcelToOwner, qui associe un ou plusieurs propriétaires à chaque parcelle.

Vous spécifiez les champs de clé lorsque vous créez une classe de relations.

Lorsque vous choisissez un champ de clé primaire, vous pouvez utiliser le champ ID de ligne, généralement connu sous le nom de champ IdObjet. Le champ IdObjet est automatiquement ajouté par ArcGIS lorsque vous créez une table ou une classe d'entités ou lorsque vous inscrivez une table ou couche de géodatabase d'entreprise. Ce champ garantit un ID unique pour chaque enregistrement. Il est géré par ArcGIS et vous ne pouvez pas le modifier.

La valeur IdObjet d'un objet donné ne change jamais tant qu'il demeure dans sa classe d'origine et, si l'objet est une entité, que vous ne le fractionnez pas. Si vous fractionnez une entité, elle conserve l'entité d'origine (tout en mettant à jour la géométrie) et crée une entité, à laquelle un nouvel IdObjet est attribué. Par conséquent, seule l'entité comportant l'IdObjet d'origine conserve les relations dépendantes de la valeur IdObjet.

C'est pour cette raison qu'il est préférable de créer et d'utiliser votre propre champ de clé primaire au lieu de vous appuyer sur le champ IdObjet. Voici comment votre propre champ de clé primaire permet de conserver les relations lorsque vous effectuez chacune de ces opérations.

• Lorsque vous importez des enregistrements dans une autre table ou classe d'entités, de nouvelles valeurs IdObjet sont attribuées et les relations reposant sur les valeurs IdObjet d'origine sont perdues. Si, à la place, vous fondez la relation sur une autre clé primaire, les valeurs ID de la clé primaire ne changent pas lors de l'importation des enregistrements. Ceci vous permet de conserver les relations lorsque vous importez des jeux associés d'objets dans de nouvelles classes.

  L'utilisation de la fonction Copier/Coller est une exception. La fonction Copier/Coller conserve les valeurs IdObjet. Ainsi, si vous prévoyez de déplacer des objets uniquement avec cette méthode, vous pouvez utiliser le champ IdObjet comme clé primaire.

• Lorsque vous fractionnez une entité, l'entité d'origine est conservée (avec la géométrie mise à jour) et une nouvelle entité est créée. Si une relation repose sur l'IdObjet d'origine, une seule des deux entités créées lors du fractionnement conserve la relation. Toutefois, si vous avez utilisé un autre champ comme clé, lorsque vous fractionnez l'entité, la valeur ID de l'entité d'origine est copiée sur les deux nouvelles entités. Dans ce cas, les enregistrements dans la table associée sont désormais associés aux deux nouvelles entités. Ceci est idéal si la classe de relations est de type plusieurs vers plusieurs.

  Si vous ne prévoyez pas de fractionner des entités et êtes certain que tous les objets demeureront dans leur classe d'origine, vous pouvez utiliser l'IdObjet comme ID. Si vous n’en êtes pas certain, il est préférable de configurer et d’utiliser votre propre champ ID au lieu de vous baser sur le champ ObjectID.

• Lorsque vous fusionnez deux entités, la nouvelle entité conserve l'IdObjet d'une des entités d'origine. Si vous prévoyez de fusionner des entités sans les retirer de leur classe ou les fractionner, vous pouvez utiliser le champ IdObjet comme clé primaire.