Disponible avec une licence Standard ou Advanced.
Une classe de relations contient plusieurs propriétés qui définissent la manière dont les objets d'origine sont associés aux objets de 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 primaires et étrangères
- Cardinalité : la relation est-elle de type un vers un, un vers plusieurs et plusieurs vers plusieurs ?
- Direction de notification des messages, applicable si vous souhaitez implémenter une mise à jour en cascade personnalisée ou supprimer un comportement
- Si vous souhaitez stocker des attributs pour chaque relation
- Nom
- Étiquettes avant et arrière qui apparaissent lorsque vous parcourez des enregistrements associés dans ArcMap
Une fois que vous avez créé la relation, vous pouvez spécifier des règles pour affiner la cardinalité.
Simple et composite
Lorsque vous créez une classe de relations, vous spécifiez si elle est simple ou composite.
Dans une relation simple, les objets associés peuvent être indépendants 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, la valeur de champ de la clé étrangère de l'objet de destination correspondant est définie sur Null. Ce comportement de la clé étrangère a pour objectif pour conserver l'intégrité référentielle parmi les entités. Si l'entité d'origine est supprimée, la valeur dans la clé étrangère n'associe plus cette ligne à une entité dans l'origine. Par conséquent, la valeur de clé étrangère n'est plus requise et est définie sur Null. L'objectif unique de la clé étrangère est de conserver une relation entre l'objet de destination et l'objet d'origine associé. Si aucune entité d'origine ne possède la valeur de clé primaire correspondante, il n'est pas nécessaire de conserver la valeur de clé étrangère. Si vous souhaitez dans le futur mettre en relation la même entité de destination avec une entité d'origine nouvelle ou différente, vous pouvez définir le champ Clé étrangère sur la nouvelle valeur de clé étrangère au lieu de la valeur Null.
Supprimer 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 être indépendants des objets d'origine. Ainsi, lorsque l'origine est supprimée, les objets de destination associés sont également supprimés au cours d'un processus nommé suppression en cascade.
Une relation composite vous permet également de conserver les entités spatialement. Le déplacement ou la rotation d'une entité d'origine provoque le déplacement ou la rotation des entités de destination associées lorsque le système de messagerie est défini sur Avant.
Les relations composites sont toujours de type un vers plusieurs lorsque vous les créez, mais peuvent être contraintes au type un vers un avec des règles de relations.
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, 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 de clé sur Null. Si vous vous trompez de classe d'origine et supprimez des objets dans l'origine, des erreurs sont générées dans le champ de clé étrangère. L'exemple suivant illustre ce problème potentiel :
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.
Clés primaires et étrangères
Dans une classe de relations, les objets d'origine correspondent aux objets de destination via les valeurs de leurs champs de clé. Dans l'exemple suivant, la parcelle 789 correspond aux permis 2 et 3, car tous ces enregistrements possèdent le même ID de parcelle.
Le champ de clé dans la classe d'origine d'une relation se nomme clé primaire et est fréquemment abrégé sous la forme PK (Primary Key). 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é dans la classe de destination se nomme clé étrangère et est fréquemment abrégé sous la forme FK (Foreign Key). Il contient des valeurs qui correspondent à celles du champ de clé primaire dans la classe d'origine. Dans ce cas également, les valeurs du champ de clé ne doivent pas nécessairement être uniques pour chaque ligne.
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é. 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 appuyer sur le champ IdObjet.
- 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.
Cardinalité
La cardinalité d'une relation indique le nombre d'objets dans la classe d'origine pouvant être associés à un certain nombre d'objets dans la classe de destination. Trois cardinalités sont possibles pour une relation :
Un vers un : un objet d’origine peut être associé à un objet de destination uniquement. Par exemple, une parcelle ne peut comporter qu'une seule description légale. 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 : un objet d’origine peut être associé à plusieurs objets 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 associé à plusieurs objets de destination et, inversement, un objet de destination peut être associé à 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.
Les termes "un vers plusieurs" peuvent être trompeurs. "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
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 ou 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 exiger que chaque bâtiment soit associé à une parcelle ou qu'une parcelle contienne un nombre maximal de bâtiments. Vous souhaitez éviter qu'un utilisateur oublie d'associer un bâtiment à une parcelle ou qu'il n'associe trop de bâtiments à une parcelle.
Si vous possédez des sous-types, vous pouvez limiter le nombre et le type des objets dans l'origine pouvant être associés à un certain type d'objet dans la destination. Par exemple, les pylônes en acier supportent des transformateurs de classe A alors que les pylônes en bois supportent des transformateurs de classe B. Vous pouvez en outre être amené à spécifier la plage de cardinalité autorisée pour chaque paire de sous-types valide. Par exemple, un pylône en acier peut supporter 0 à 3 transformateurs de classe A alors qu'un pylône en bois peut supporter 0 à 2 transformateurs de classe B.
Pour consulter les règles de relations de votre classe de relations, cliquez avec le bouton droit de la souris sur la classe de relations dans la fenêtre Catalog (Catalogue) pour ouvrir la boîte de dialogue Relationship Class Properties (Propriétés de la classe de relations) et cliquez sur l’onglet Rules (Règles).
Cela affiche une liste de toutes les règles possibles qui peuvent exister pour votre classe de relations. La colonne Enabled (Activé) indique les règles actuellement actives.
Vous pouvez trier les règles des classes de relations dans l’affichage en sélectionnant Origin then Destination Subtype (Origine puis sous-type de destination) ou Destination then Origin Subtype (Destination puis sous-type d’origine) dans le menu déroulant Sort By (Trier par).
Pour supprimer une règle d’une classe de relations, décochez la case Enabled (Activé) pour la ligne représentant la règle à supprimer et cliquez sur OK.
Pour créer une règle sur la classe d’entités, procédez comme suit :
- Cochez la case Enabled (Activé) pour la ligne qui représente la règle que vous souhaitez ajouter à la classe de relations.
- Définissez les cardinalités appropriées Min et Max sur la règle pour l’origine et la destination en saisissant des entiers dans leurs cellules correspondantes.
- Répétez les étapes 1 et 2 pour chaque règle à ajouter.
- Cliquez sur OK.
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 d’autres règles de relations.
Dans l'exemple ci-dessous, un site d'enfouissement de substances dangereuses peut être associé à un ou deux puits profonds ou à entre deux et sept puits peu profonds. Toutefois, si un site d'enfouissement sanitaire est associé à 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 non valide.
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 associés, définissez la direction de notification des messages 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 des messages sur Arrière. Si vous nécessitez les deux, définissez la direction de notification des messages sur 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 sont les relations composites lorsque le système de messagerie est défini sur 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 Avant ou prévoyez de programmer un comportement personnalisé, définissez la notification des messages sur 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. Ceci se produit que le système de messagerie soit défini sur Avant, Arrière, Les deux ou Aucun.
| Itinéraire | Effet sur les relations simples | Effet sur les relations composites |
|---|---|---|
Avant | Aucun effet sauf en cas de personnalisation avec programmation |
|
Arrière | Aucun effet sauf en cas de personnalisation avec programmation |
|
Les deux | Aucun effet sauf en cas de personnalisation avec programmation |
|
Aucun | Empêche l'envoi des messages, ce qui améliore légèrement les performances |
|
Relations plusieurs vers plusieurs
Dans les relations un vers un et un vers plusieurs, les valeurs dans la clé primaire de la classe d'origine sont directement associées aux valeurs dans la clé étrangère de la classe de destination.
Les relations plusieurs vers plusieurs, d'un autre côté, nécessitent l'utilisation d'une table intermédiaire pour apparier les associations. Par conséquent, lorsque vous créez une relation de type plusieurs vers plusieurs, une table intermédiaire est automatiquement créée. La table intermédiaire apparie les valeurs de clé primaire de l'origine aux 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 la table. Le renseignement de cette table est la phase la plus longue de la configuration de la relation.
Attributs d'une relation
La table intermédiaire d'une relation de type plusieurs vers plusieurs peut également jouer un second rôle : elle peut stocker les attributs de la relation 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 les parts de copropriété. Si vous devez stocker ces attributs, vous pouvez les ajouter dans la table intermédiaire lorsque vous créez la relation ou ultérieurement.
Même si cela n'est pas aussi utile, lorsque vous configurez une relation un vers un ou un vers plusieurs, vous pouvez également avoir besoin de stocker les attributs de la relation. Dans ce cas, vous devez le préciser lorsque vous créez la relation afin qu'une table intermédiaire soit créée à votre intention. Comme avec les relations plusieurs vers plusieurs, la table intermédiaire apparie les valeurs de clé primaire de l'origine aux valeurs de clé étrangère de la destination, ce qui vous permet de stocker n'importe quel nombre d'attributs pour chaque relation.
Si vous ajoutez la classe de relations à la carte, elle apparaît sous forme de 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 la fenêtre Catalog (Catalogue), ajouter ou supprimer des champs dans la vue Fields (Champs) et l’utilisation de valeurs ou domaines par défaut n’est pas prise en charge.
Nom
Chaque classe de relations possède un nom qui apparaît dans la fenêtre Catalogue. Pour faciliter la compréhension de la structure de la base de données, attribuez à la classe de relations un nom qui décrit 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.
Etiquettes avant et arrière
Les étiquettes avant et arrière s’affichent dans les boîtes de dialogue Attributes (Attributs) et Identify results (Identifier les résultats) de la fenêtre Map (Carte) et vous permettent de naviguer parmi les objets associés.
Une classe de relations comporte deux étiquettes :
- Une étiquette avant qui s'affiche lorsque vous naviguez de l'origine vers la destination. Dans notre exemple pylône-transformateur, cette étiquette pourrait être "supporte", ce qui indique que ce pylône supporte ces transformateurs.
- Une étiquette arrière qui s'affiche lorsque vous naviguez de la destination vers l'origine. Dans notre exemple pylône-transformateur, cette étiquette pourrait être "est monté sur", ce qui indique que ces transformateurs sont montés sur ce pylône.
Vous avez un commentaire à formuler concernant cette rubrique ?