Mise à jour le 7 février 2022
Il semble qu'il y ait toujours eu une confusion autour des termes « relate » et « relationship class ». Dans cet article, nous allons tenter de clarifier cela. Les captures d'écran d'exemple proviennent d'ArcMap mais les concepts s'appliquent également à ArcGIS Pro.
Les bases
- Un relate (également appelé table relate) est une propriété d'une couche dans ArcGIS Pro ou ArcMap. Vous créez un table relate afin de pouvoir interroger et sélectionner des entités dans une couche et voir toutes les entités liées dans une autre couche ou table. Un table relate existe uniquement dans une carte ou un fichier de couche (.lyr).
- Une relationship class est un objet dans une géodatabase qui stocke des informations sur une relation entre deux classes d'entités, entre une classe d'entités et une table non spatiale, ou entre deux tables non spatiales. Les deux participants dans une relationship class doivent être stockés dans la même géodatabase.
- La cardinalité contrôle comment les relates et les relationship classes sont configurés. La cardinalité n'est pas une mesure de la ferveur d'un fan de baseball de St. Louis, c'est une description de la façon dont les enregistrements dans deux tables différentes sont liés l'un à l'autre. Cardinality peut être un-à-un, un-à-plusieurs, plusieurs-à-un, ou plusieurs-à-plusieurs.
- Les table relates sont créés entre des tables qui ont une cardinalité un-à-plusieurs ou plusieurs-à-un. Les relationship classes supportent toutes les cardinalités.
- Lorsque vous créez un table relate ou une relationship class, vous spécifiez le champ dans chaque table sur lequel la relation sera basée. Les champs doivent être du même type de données (c'est-à-dire texte, entier court, entier long, object ID, etc.).
- Les relates peuvent être créés et modifiés avec une licence Basic, Standard, ou Advanced.
- Les relationship classes peuvent être créées et modifiées avec une licence Standard ou Advanced. Elles sont en lecture seule avec une licence Basic.
Tout est clair maintenant ? Non ? OK, approfondissons.
L'exemple
Dans la Table des matières de la carte ci-dessus, vous voyez une couche des casernes de pompiers de la ville et une table non spatiale qui stocke des données sur le personnel du service d'incendie de la ville. Un table relate a été créé entre la couche et la table non spatiale basé sur un champ entier court dans chaque table qui stocke un numéro d'identification de caserne.
Que se passe-t-il lorsqu'une caserne est sélectionnée sur la carte ?
Ci-dessous, vous voyez la table attributaire pour la couche des casernes de pompiers et la table du personnel incendie. L'option pour afficher uniquement les entités sélectionnées est utilisée pour les deux tables. Remarquez que bien qu'un seul enregistrement de caserne soit sélectionné (la caserne Washington), six enregistrements dans la table du personnel incendie sont sélectionnés.
Cela vous indique que la couche Fire Stations a une cardinalité un-à-plusieurs avec la table du personnel incendie. Pour chaque caserne, plusieurs membres du personnel incendie sont associés. Dans ce cas, six pompiers sont affectés à la caserne Washington. Parce que les tables sont liées, lorsque vous sélectionnez une caserne vous pouvez facilement savoir qui travaille à cette caserne. Les table relates sont bidirectionnels, ce qui signifie que vous pouvez aussi sélectionner un enregistrement dans la table du personnel incendie et accéder au nom de la caserne à laquelle le pompier est affecté.
Vous n'avez même pas besoin de sélectionner une entité ou d'ouvrir les tables ; vous pouvez rapidement voir l'information en utilisant l'outil Identify. Le nom de la table liée s'affiche sous le nom de l'entité sur le côté gauche de la fenêtre Identify. En développant la table liée, vous révélez les enregistrements liés. Cliquer sur un enregistrement lié affiche les données stockées dans la table liée.
Supposons que Brian Butler soit transféré à la caserne Adams. Vous allez modifier la table FirePersonnel pour refléter cela. Voici les étapes pour accomplir cela en utilisant notre exemple.
- Démarrez une session d'édition.
- Dans la table Fire Personnel, sélectionnez l'enregistrement de Brian Butler.
- Dans le champ Number_, changez la valeur à 1714 (le numéro d'identification pour la caserne Adams).
- Fermez la table et sauvegardez vos modifications.
- Cliquez sur la caserne Adams avec l'outil Identify.
- Brian Butler apparaît maintenant dans la liste du personnel associé à la caserne Adams.
- Cliquez sur la caserne Washington avec l'outil Identify.
- L'enregistrement de Brian Butler ne s'affiche plus.
Pourquoi utiliser une Relationship Class ?
Les table relates sont utiles pour accéder rapidement et visualiser des informations sur le monde réel qui sont effectivement stockées dans deux tables différentes. Cependant, les relationship classes offrent des capacités plus puissantes.
En plus de sélectionner des enregistrements dans une table et voir les enregistrements liés dans l'autre, avec une relationship class vous pouvez définir des règles et propriétés qui contrôlent ce qui se passe lorsque les données dans l'une ou l'autre des tables sont modifiées, ainsi que garantir que seules des modifications valides soient effectuées. Vous pouvez configurer une relationship class pour que modifier un enregistrement dans une table mette automatiquement à jour les enregistrements liés dans l'autre table.
En utilisant l'exemple ci-dessus, supposons qu'une relationship class soit créée entre la couche Fire Stations et la table du personnel incendie. La ville a une exigence selon laquelle toutes les casernes doivent avoir un minimum de cinq pompiers et un maximum de 15 pompiers. Une règle a été créée pour cette relationship class qui reflète cette exigence.
A la fin de l'exemple du table relate, la caserne Washington avait cinq pompiers assignés. Maintenant, avec la relationship class en place, si un employé essaie d'assigner un numéro différent de caserne à l'un des pompiers de Washington, un message d'erreur s'affichera et il comprendra qu'une règle existe exigeant que toutes les casernes aient au moins cinq pompiers assignés. Avant de modifier le numéro de caserne d'un pompier existant, il devra assigner un nouveau pompier à la caserne Washington. Après cela fait, il pourra changer le numéro de caserne pour le pompier existant afin de refléter un transfert.
La relationship class garantit que les modifications des données sont valides et soutient l'objectif du service d'incendie que les affectations du personnel respectent l'exigence de la ville.
Rappelez-vous
- Les table relates existent uniquement dans une carte ou un fichier de couche.
- Les relationship classes existent comme objets distincts dans une géodatabase. Si l'une des tables participantes est supprimée de la géodatabase, la relationship class est également supprimée.
- Tant les table relates que les relationship classes permettent aux utilisateurs d'accéder et visualiser des informations pour des entités liées depuis n'importe quelle table.
- Les relationship classes sont souvent utilisées pour assurer l'intégrité des données. Elles aident à rendre votre géodatabase intelligente.
Beaucoup plus pourrait être dit sur les relates et les relationship classes, mais dans un souci de simplicité nous allons terminer cet article ici. Espérons qu'une partie de cette confusion a été dissipée. Pour plus d'informations sur ce sujet, consultez ce sujet d'aide.
