Propriétés de la classe de relations

Cette rubrique s'applique uniquement à ArcEditor et ArcInfo.

Remarque :

Les classes de relations peuvent être créées et modifiées dans ArcInfo et ArcEditor, mais elles sont en mode lecture seule dans ArcView. Les classes d'entités qui participent à une classe de relations seront aussi en lecture seule dans ArcView.

Une classe de relations contient plusieurs propriétés qui définissent comment les objets de l'origine sont reliés aux objets de la destination. Vous spécifiez ces propriétés lorsque vous créez la classe de relations.

• Type : simple ou composite
• Classes d'origine et de destination
• Clés primaire et étrangère
• Cardinalité : la relation est-elle de type un vers un, un vers plusieurs et plusieurs vers plusieurs ?
• Direction de notification de message, applicable si vous souhaitez mettre en œuvre un comportement de mise à jour ou de suppression en cascade personnalisé
• Si vous souhaitez ou non stocker des attributs pour chaque relation
• Nom
• Appellations avant et arrière qui s'affichent lorsque vous naviguez dans des enregistrements reliés dans ArcMap

Une fois que vous avez créé la relation, vous pouvez spécifier des règles pour affiner la cardinalité.

Relation simple et relation composite

Lorsque vous créez une classe de relations, vous spécifiez si elle est simple ou composite.

Dans une relation simple, des objets reliés peuvent exister indépendamment les uns des autres. Par exemple, un réseau ferroviaire peut comporter des intersections avec un ou plusieurs signaux lumineux. Cependant, une intersection de voie ferrée peut exister sans signal lumineux et des signaux lumineux exister sur le réseau ferroviaire là où il n'y a pas d'intersection.

Lorsque vous supprimez un objet d'origine dans une relation simple, le champ de clé étrangère pour l'objet de destination correspondant est défini sur une valeur nulle. Ce comportement de clé étrangère a vocation de maintenir l'intégrité référentielle entre des entités. Si l'entité d'origine est supprimée, la valeur dans la clé étrangère ne relie plus cette ligne à une entité dans l'origine ; en conséquence, la valeur de clé étrangère n'est plus requise et prend la valeur nulle. Le seul objectif de la clé étrangère consiste à maintenir une relation entre l'objet de destination et l'objet d'origine associé. En l'absence d'entité d'origine avec la valeur de clé primaire correspondante, il n'y a plus lieu de conserver la valeur de clé étrangère. Si vous souhaitez relier la même entité cible à une entité d'origine nouvelle ou différente à l'avenir, le champ FK de valeur nulle peut être actualisé en fonction de la nouvelle valeur FK.

La suppression d'un objet de destination n'a aucun effet sur la valeur de clé primaire dans l'objet d'origine associé.

Les relations simples peuvent avoir des cardinalités de type un vers un, un vers plusieurs et plusieurs vers plusieurs.

A l'instar des relations simples, les relations composites conservent leur intégrité référentielle lorsque les objets sont supprimés, mais elles le font différemment. Dans une relation composite, les objets de destination ne peuvent pas exister indépendamment des objets d'origine. Par conséquent, lorsque l'origine est supprimée, les objets de destination associés sont également supprimés dans un processus appelé une suppression en cascade.

Cette règle de dépendance est également appliquée par la commande Valider les entités d'ArcMap, une commande exécutée dans une session de mise à jour pour tester l'intégrité référentielle. Si vous avez créé un objet de destination mais que vous ne l'avez pas associé à un objet d'origine, la commande Valider les entités vous signale l'erreur.

Une relation composite peut également vous aider à gérer spatialement des entités ; le déplacement ou la rotation d'une entité d'origine entraîne le déplacement ou la rotation des entités cibles reliées lorsque la messagerie est paramétrée sur Avant.

Les relations composites sont toujours de type un vers plusieurs lorsque vous les créez, mais elles peuvent devenir des relations de type un vers un avec des règles de relation.

Classes d'origine et de destination

Lorsque vous créez une classe de relations, vous sélectionnez une classe pour tenir lieu d'origine et une autre classe pour tenir lieu de destination. Il est important de ne pas confondre ces deux classes. Cela semble évident, compte tenu du comportement de suppression en cascade dans des relations composites.

Dans les relations simples, il est également essentiel de bien différencier l'origine et la destination. En effet, lorsque vous supprimez un enregistrement 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 leurs champs clés sur Null. Si vous sélectionnez la mauvaise classe comme origine et que vous supprimez des objets dans l'origine, vous provoquez des erreurs dans le champ de clé étrangère. L'exemple suivant illustre la manière dont cela peut se produire :

Cas 1 : Parcelle vers Zone (erroné)

Il s'agit d'un scénario fréquent d'erreur. La table Zone contient les descriptions pour les différents codes de zonage et elle est semblable d'un point de vue conceptuel à une table de correspondance ArcInfo Workstation. Dans ce cas, la classe Parcel (parcelle) est l'origine et la table Zone est la destination. C'est ainsi que vous définiriez la relation dans ArcInfo Workstation. Le problème est que lorsque vous supprimez une parcelle, la valeur du champ clé (Zone) est définie sur Null pour l'enregistrement correspondant dans la table Zone, et aucunes des autres parcelles qui ont ce code de zonage n'ont de correspondance dans la table Zone.

Cas 2 : Zone vers Parcelle (correct)

Pour résoudre le problème, définissez la table Zone comme origine. La suppression d'une parcelle (un objet de destination) est sans conséquences sur la table Zone. Par contre, lorsque vous supprimez un code Zone (un objet d'origine), la valeur du champ Zone dans les enregistrements de parcelle correspondants devient simplement Null, ce qui est logique puisque les parcelles n'ont alors plus d'enregistrement correspondant dans la table Zone.

Clés primaire et étrangère

Dans une classe de relations, les objets de l'origine correspondent aux objets de la destination via les valeurs de leurs champs clés. Dans l'exemple suivant, la parcelle 789 correspond aux champs Permit 2 et 3 parce que tous ces enregistrements ont le même code parcelle (Parcel ID).

Le champ clé de la classe d'origine d'une relation s'appelle clé primaire (souvent abrégée en PK – Primary Key). Contrairement à une clé primaire réelle, les valeurs du champ de clé primaire ne doivent pas être forcément uniques pour chaque objet.

Le champ clé de la classe de destination est appelé clé étrangère (souvent abrégée en FK - Foreign Key). Il contient des valeurs correspondant à celles du champ de clé primaire dans la classe d'origine. Là encore, les valeurs de champ clé n'ont pas besoin d'être uniques pour chaque ligne.

Les champs clés peuvent porter des noms différents mais le type de données doit être le même et ils doivent contenir le même type d'informations, par exemple des codes parcelle. Les champs de tous les types de données à l'exception des types BLOB (Binary Large Object), date et raster peuvent être des champs de clé. Vous spécifiez les champs clés lorsque vous créez une classe de relations.

Lors du choix d'un champ de clé primaire, une option consiste à utiliser le champ d'identifiant d'enregistrement, généralement appelé champ ObjectID. Le champ ObjectID est ajouté automatiquement par ArcGIS lorsque vous créez une classe d'entités ou une table ou que vous enregistrez une couche ou une table ArcSDE. Ce champ garantit l'utilisation d'un identifiant unique pour chaque enregistrement. Il est géré par ArcGIS et vous ne pouvez pas le modifier.

La valeur ObjectID d'un objet donné ne change jamais tant qu'il reste dans sa classe d'origine et, si l'objet est une entité, vous ne devez pas le fractionner. Si vous fractionnez une entité, l'opération conserve l'entité d'origine (mais la géométrie est actualisée) et crée une nouvelle entité à laquelle un nouvel identifiant ObjectID est attribué. En conséquence, seule l'entité avec l'identifiant ObjectID d'origine conservera l'ensemble des relations qui dépendent de la valeur ObjectID.

Pour cette raison, il est préférable de créer et d'utiliser votre propre champ de clé primaire au lieu de vous baser sur le champ ObjectID. La section suivante décrit la manière dont votre propre champ de clé primaire peut aider à gérer des relations lorsque vous exécutez chacune de ces opérations.

• Lorsque vous importez des enregistrements vers une autre classe d'entités ou table, de nouvelles valeurs ObjectID sont attribuées, ce qui entraîne la perte de toutes les relations basées sur les valeurs ObjectID initiales. Si vous basez plutôt la relation sur une autre clé primaire, les valeurs d'ID de la clé primaire ne changeront pas lors de l'importation des enregistrements. Cela vous permet de conserver les relations lorsque vous importez des ensembles liés d'objets vers de nouvelles classes.

  La fonction Copier/Coller constitue une exception à cette règle. La fonction Copier/Coller conserve les valeurs ObjectID. Par conséquent, si vous prévoyez de déplacer des objets avec cette méthode uniquement, vous pouvez utiliser le champ ObjectID comme 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. Pour en savoir plus sur l'utilisation d'un ObjectID en tant que clé primaire avec réplication, consultez la rubrique Réplication de données reliées.
• Lorsque vous fractionnez une entité, l'entité d'origine est conservée (et sa géométrie actualisée) et une nouvelle entité est créée. Si vous disposez d'une relation basée sur l'identifiant ObjectID d'origine, seule l'une des deux entités créées lors du fractionnement conservera la relation. En revanche, si vous utilisez un autre champ comme clé, lorsque vous fractionnez l'entité, la valeur d'ID de l'entité initiale est copiée vers les deux nouvelles entités. En conséquence, les enregistrements de la table reliée sont maintenant liés aux deux nouvelles entités, ce qui représente une solution idéale si la classe de relations est configurée avec un type plusieurs vers plusieurs.

  Si vous n'envisages pas de fractionner des entités et que vous êtes sûr que tous les objets resteront dans leur classe initiale, vous pouvez utiliser ObjectID comme identifiant. Si vous n'en n'êtes pas certain, il est préférable de configurer et d'utiliser votre propre champ d'ID plutôt que d'utiliser le champ ObjectID.

• Lorsque vous combinez deux entités, la nouvelle entité conserve la valeur ObjectID de l'une des entités initiales. Si vous prévoyez de combiner des entités mais pas de les déplacer hors de leur classe ou de les fractionner, vous pouvez utiliser le champ ObjectID comme clé primaire.

Cardinalité

La cardinalité d'une relation spécifie le nombre d'objets de la classe d'origine pouvant être liés avec des objets de la classe de destination. Une relation peut avoir l'une de ces trois cardinalités :

Un vers un : un objet d'origine peut être lié à un seul objet de destination. Par exemple, une parcelle ne peut avoir qu'une seule description légale. Dans ArcGIS, cette cardinalité recouvre également le type plusieurs vers un. Le cas de nombreuses parcelles liées à la même description légale constitue un exemple de relation plusieurs vers un.

Un vers plusieurs : un objet d'origine peut être lié à plusieurs objets de destination. Par exemple, une parcelle peut avoir de nombreux bâtiments. Dans une relation un vers plusieurs, le côté "un" doit être la classe d'origine et le côté "plusieurs" doit être la classe de destination.

Plusieurs vers plusieurs : un objet d'origine peut être lié à plusieurs objets de destination et, inversement, un objet de destination peut être lié à plusieurs objets d'origine. Par exemple, une propriété donnée peut avoir beaucoup de propriétaires et un propriétaire donné peut posséder beaucoup de propriétés.

Les termes "un" et "plusieurs" peuvent être trompeurs. Un est en réalité zéro vers un et plusieurs est en réalité zéro vers plusieurs. Par conséquent, lorsque vous créez, par exemple, une relation un vers plusieurs entre des parcelles et des bâtiments, la relation autorise tous les cas suivants :

• Une parcelle sans bâtiments
• Un bâtiment sans parcelle
• Une parcelle avec tout nombre de bâtiments

Après avoir créé une relation, vous pouvez affiner les cardinalités en définissant des règles pour la relation. Vous pouvez définir des règles spécifiant le nombre d'objets dans l'origine qui sont autorisés à être liés à plusieurs objets dans la destination.

Règles de relation

Lorsque vous créez une classe de relations, vous la créez avec les cardinalités un vers un, un vers plusieurs et plusieurs vers plusieurs.

Une relation doit souvent être définie dans des termes plus restrictifs. Dans une relation de parcelles et de bâtiments, par exemple, vous pouvez avoir besoin d'exiger que chaque bâtiment soit associé à une parcelle ou qu'une parcelle puisse contenir un nombre maximal de bâtiments. Vous souhaitez empêcher un utilisateur d'oublier d'associer un bâtiment à une parcelle ou d'associer trop de bâtiments à une parcelle.

Si vous avez des sous-types, vous pouvez imposer le nombre et le type d'objets dans l'origine pouvant être liés à un certain type d'objet dans la destination. Par exemple, des pylônes en acier supportent des transformateurs de classe A alors que les pylônes en bois supportent des transformateurs de classe B. En outre, vous pouvez avoir également besoin de spécifier la plage de cardinalité admissible pour chaque paire de sous-types valide. Par exemple, un pylône en acier supporte de 0 à 3 transformateurs de classe A alors qu'un pylône en bois peut supporter 0 à 2 transformateurs de classe B.

Une fois que vous avez créé une classe de relations, vous pouvez spécifier les règles qui contribuent à garantir ces règles d'intégrité référentielle :

1. Dans ArcCatalog ou dans la fenêtre Catalogue, cliquez avec le bouton droit sur une classe de relation existante pour afficher la boîte de dialogue de ses Propriétés et cliquez sur l'onglet Règles.
2. Sélectionnez un sous-type de la classe d'origine et cochez un sous-type correspondant de la classe de destination.
3. Cochez les cases correspondant à la cardinalité de la relation entre l'origine et la destination. Définissez les cardinalités minimale et maximale pour la règle. La boîte de dialogue vous empêche de définir une valeur minimale supérieure à la valeur maximale. Définissez donc d'abord la valeur maximale de cardinalité.

Lorsqu'une règle de relations est ajoutée à une classe de relations, cette règle devient l'unique relation valide existante. Pour valider d'autres combinaisons de relations et de cardinalités, vous devez ajouter des règles de relations supplémentaires.

Dans l'exemple ci-dessous, un site d'enfouissement des déchets HazMat peut être lié à un ou deux puits profonds ou à deux à sept puits peu profonds. Toutefois, si un site d'enfouissement des déchets sanitaires est lié à un puits profond mais qu'aucune règle n'a été créée entre ces deux sous-types, la commande Valider les entités considère la relation comme incorrecte.

Une fois les règles configurées et une session de mise à jour ouverte, vous pouvez tester ces règles à l'aide de la commande Valider les entités d'ArcMap. Cette commande vous indique si des entités actuellement sélectionnées violent une règle de relation.

Direction de notification de message

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

Que vous utilisiez des relations simples ou composites, il peut exister d'autres actions pour lesquelles une mise à jour d'une entité déclenche une mise à jour des entités liées correspondantes. En outre, des mises à jour peuvent être requises dans une direction ou une autre, ou dans les deux à la fois.

• Lorsque vous déplacez ou faites pivoter une entité, vous souhaitez que les entités liées se déplacent ou pivotent en même temps.
• Lorsque vous mettez à jour une entité, vous souhaitez qu'un attribut d'une entité liée soit mis à jour automatiquement.
• La mise à jour d'une origine peut nécessiter la mise à jour des objets de destination associés.
• La mise à jour d'objets de destination peut nécessiter la mise à jour des objets d'origine associés.

Si votre relation nécessite ce comportement, vous pouvez faire en sorte que les objets d'origine et de destination envoient des messages pour se notifier mutuellement lorsqu'ils sont modifiés, ce qui permet aux objets associés d'être mis à jour correctement.

Pour ce faire, définissez la direction de notification de message lorsque vous créez la relation. Si la mise à jour d'une origine nécessite la mise à jour des objets de destination associés, définissez la direction de notification de message sur Avant. Si la mise à jour de la destination nécessite la mise à jour des objets d'origine associés, définissez la direction de notification de message sur Arrière. Si vous avez besoin des deux directions, définissez la direction de notification de message sur Les deux. Une fois que vous avez créé la relation, vous devez programmer le comportement des objets recevant les messages pour qu'ils puissent répondre.

La seule exception concerne les relations composites lorsque la messagerie est définie sur Avant. Lorsque vous créez une relation composite avec la messagerie avant, le déplacement ou la rotation d'un objet d'origine entraîne automatiquement le déplacement ou la rotation des entités qui lui sont liées. Dans la mesure où vous configurez votre relation correctement, cette fonctionnalité est opérationnelle dès que vous avez créé la relation ; aucune programmation personnalisée n'est requise.

Pour les autres directions de notification de message, une programmation personnalisée est nécessaire. Définissez la notification de message sur Aucun, sauf si vous créez une relation composite avec une messagerie avant ou que vous prévoyez de programmer un comportement personnalisé. Sinon, des messages inutiles sont générés chaque fois que vous exécutez une opération de mise à jour, ce qui ralentit les performances.

Lorsque vous définissez la direction pour les relations composites, n'oubliez pas que lorsque l'objet d'origine d'une relation composite est supprimé, tous les objets associés de la destination sont supprimés automatiquement. Cela se produit, que la messagerie soit définie sur Avant, Arrière, Les deux ou Aucun.

Outil Angle	Incidence sur les relations simples	Incidence sur les relations composites
Avant	Aucune incidence sauf dans le cas d'une 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 Aucune autre incidence sauf si un comportement personnalisé est programmé
Arrière	Aucune incidence sauf dans le cas d'une personnalisation avec programmation	La suppression de l'origine supprime la destination Aucune autre incidence sauf si un comportement personnalisé est programmé
Les deux	Aucune incidence sauf dans le cas d'une 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 Aucune autre incidence sauf si un comportement personnalisé est programmé
Aucune	Empêche l'envoi de 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

Directions de notification de message

Relations plusieurs vers plusieurs

Dans les relations de type un vers un et un vers plusieurs, les valeurs de la clé primaire dans la classe d'origine sont directement liées aux valeurs de la clé étrangère dans la classe de destination.

En revanche, les relations plusieurs vers plusieurs nécessitent l'utilisation d'une table intermédiaire pour mapper les associations. De ce fait, lorsque vous créez une relation plusieurs vers plusieurs, une table intermédiaire est créée automatiquement. La table intermédiaire mappe les valeurs de clé primaire de l'origine sur les valeurs de clé étrangère de la destination. Chaque ligne associe un objet d'origine à un objet de destination.

Seuls les champs sont générés lors de la création de la table intermédiaire. ArcGIS ne sait pas à quels objets de destination les objets d'origine sont associés et les lignes doivent donc être créées manuellement dans ArcMap. Le remplissage de cette table constitue la phase la plus longue de la configuration de la relation.

Attributs de relation

La table intermédiaire d'une relation de type plusieurs vers plusieurs peut éventuellement avoir une autre utilité : stocker les attributs de la relation elle-même. Par exemple, une base de données de parcelles peut contenir une classe de relations entre des parcelles et des propriétaires dans laquelle des propriétaires possèdent des parcelles et des parcelles appartiennent à des propriétaires. Un attribut de chaque relation peut représenter des parts de copropriété. Pour stocker de tels attributs, vous pouvez les ajouter à la table intermédiaire lorsque vous créez la relation, ou ultérieurement.

Bien que cela ne soit pas aussi utile, lorsque vous configurez une relation un vers un ou un vers plusieurs, vous pouvez avoir également besoin de stocker des attributs de la relation. Dans ce cas, vous devez le spécifier lorsque vous créez la relation pour qu'une table intermédiaire soit créée pour vous. Comme avec les relations plusieurs vers plusieurs, la table intermédiaire mappe des valeurs de clé primaire de l'origine sur des valeurs de clé étrangère de la destination, vous permettant de stocker tout nombre d'attributs pour chaque relation.

Vous pouvez afficher un aperçu de la table intermédiaire dans ArcCatalog ou dans la fenêtre Catalogue pour consulter les données qu'elle contient. Si vous ajoutez la classe de relations à ArcMap, elle apparaît sous la forme d'une table que vous pouvez ouvrir et manipuler. ArcGIS ne présente pas la table intermédiaire pour d'autres opérations. Par exemple, vous ne pouvez pas afficher ses propriétés dans ArcCatalog ou dans la fenêtre Catalogue pour ajouter ou supprimer des champs, et cette table ne prend pas en charge l'utilisation de valeurs ou de domaines par défaut.

Nom

Chaque classe de relations comporte un nom qui s'affiche dans l'arborescence du catalogue. Pour rendre la structure d'une base de données facile à comprendre, attribuez à la classe de relations avec un nom qui décrit la relation.

Commencez par le nom de la classe d'entités d'origine, faites le suivre par "Contient" ou "Contiennent" et terminez avec le nom de la classe d'entités de destination, par exemple, AdresseContientZones ou ParcellesContiennentPropriétaires. Utilisez le pluriel pour le nom de la classe d'entités d'origine s'il s'agit d'une cardinalité plusieurs vers un ou plusieurs vers plusieurs et utilisez le pluriel pour le nom de classe d'entité de destination dans le cas d'une cardinalité un vers plusieurs ou plusieurs vers plusieurs.

Avec cette méthode, vous pouvez déterminer la cardinalité d'une classe de relations à partir de son nom. Par exemple, ParcellesContiennentPropriétaires suggère une relation plusieurs vers plusieurs car le nom des deux classes d'entités est au pluriel.

Appellations avant et arrière

Les appellations avant et arrière s'affichent dans les boîtes de dialogue Attributs et Résultats d'identification dans ArcMap pour vous aider à naviguer entre des objets associés.

Une classe de relations a deux appellations :

• Une appellation avant qui s'affiche lorsque vous naviguez de l'origine vers la destination. Dans l'exemple du pylône de transformateur, cette appellation pourrait être "supporte", ce qui signifie que ce pylône supporte ces transformateurs.
• Une appellation arrière qui s'affiche lorsque vous naviguez de la destination vers l'origine. Dans l'exemple du pylône de transformateur, cette appellation pourrait être "est monté sur", ce qui signifie que ces transformateurs sont montés sur ce pylône.