Mise à jour le 7 février 2022
La différence entre relates (souvent appelés table relates) et les relationship classes est une source de beaucoup de confusion, surtout pour les nouveaux utilisateurs d'ArcGIS. Bien qu'ils sonnent de manière similaire, ces termes désignent des choses différentes. Les deux ont des avantages et il y a des raisons d'utiliser chacun d'eux. Voici les points principaux à connaître.
- Un relate existe dans une carte ou un fichier de couche.
- Une relationship class est un objet dans une géodatabase.
- Les relates peuvent être créés et modifiés avec une licence ArcGIS Pro ou ArcGIS Desktop Basic, Standard, ou Advanced.
- Les relationship classes peuvent être créées et modifiées avec une licence ArcGIS Pro ou ArcGIS Desktop Standard ou Advanced. Elles sont en lecture seule avec une licence Basic.
Tout est clair maintenant ? Non ? Continuons alors.
Démystification de la terminologie
Les relates sont excellents car ils vous permettent de sélectionner des entités dans une couche, puis de voir facilement les entités liées dans une autre couche ou les enregistrements liés dans une table non spatiale. Les relationship classes sont excellentes car elles permettent un « comportement intelligent ». Vous pouvez définir des règles sur la façon dont les classes d'entités ou tables participantes se comportent lorsqu'un événement se produit. Par exemple, avec une relationship class en place, si une entité est supprimée, alors son enregistrement associé dans l'autre classe d'entités ou table peut être automatiquement supprimé également.
Tant les relates que les relationship classes reposent sur la cardinalité, qui décrit comment les enregistrements dans deux tables différentes sont liés entre eux — la cardinalité peut être un-à-un, un-à-plusieurs, plusieurs-à-un, ou plusieurs-à-plusieurs.
- Un-à-un : Chaque entité a exactement un enregistrement lié dans l'autre table.
- Un-à-plusieurs : Les entités dans une table peuvent avoir plus d'un enregistrement lié dans l'autre table.
- Plusieurs-à-un : Plusieurs entités dans une table ont un enregistrement lié dans l'autre table.
- Plusieurs-à-plusieurs : Plusieurs entités dans une table ont plusieurs enregistrements dans l'autre table.
Les relates supportent les cardinalités un-à-plusieurs et plusieurs-à-un, tandis que les relationship classes supportent toutes les cardinalités. Les classes d'entités et tables qui participent à un relate ou à une relationship class doivent avoir un champ du même type de données (texte, entier court, entier long, object ID, etc.). Ce champ sera le « point de connexion » (aussi appelé champ clé) entre les deux.
L'exemple du Relate
La carte ci-dessous contient une couche de casernes de pompiers et une table non spatiale qui stocke des données sur le personnel du service d'incendie de la ville. Un relate a été créé entre la couche et la table non spatiale, qui ont une cardinalité un-à-plusieurs (chaque caserne a plusieurs membres du personnel). Le relate est basé sur un champ entier court dans les deux tables qui stocke un numéro d'identification de caserne. Les champs ont des noms différents, mais cela n'a aucune importance.
Grâce au relate, il est facile de savoir quel personnel est affecté à chaque caserne. Il suffit d'utiliser l'outil Identifier et de cliquer sur une caserne sur la carte. Dans la fenêtre Identifier, le nom de la table liée s'affiche sous le nom de l'entité caserne. En développant la table, on voit les enregistrements associés à cette caserne (la caserne Washington dans cet exemple, qui compte six membres du personnel affectés).
Supposons que Brian Butler soit transféré à la caserne Adams. Son enregistrement dans la table FirePersonnel est modifié pour remplacer le numéro de la caserne Washington (2) par celui de la caserne Adams (202). Lorsque la modification est enregistrée, les données affichées dans la fenêtre Identifier refléteront sa nouvelle affectation. Washington n'a maintenant plus que cinq membres du personnel affectés...
... tandis que la liste du personnel de la caserne Adams inclut désormais Brian.
L'exemple de Relationship Class
Les table relates sont très utiles pour visualiser rapidement des données d'entités stockées dans des tables séparées (pour des raisons d'efficacité de gestion des données). Cependant, les relationship classes vous permettent d'en faire plus que simplement visualiser facilement des données. Avec une relationship class, vous pouvez définir des règles et propriétés qui contrôlent ce qui se passe lorsque des données dans l'une ou l'autre table sont modifiées. Vous pouvez aussi garantir que seules des modifications valides soient effectuées.
En reprenant l'exemple ci-dessus, supposons qu'une relationship class nommée StationsPersonnel ait été créée entre la classe d'entités Fire Stations et la table Fire Personnel. Supposons aussi que la ville exige que toutes les casernes aient au minimum cinq pompiers affectés et au maximum quinze pompiers affectés. Une règle a été créée dans la relationship class pour appliquer cette exigence.
Avec le transfert de Brian Butler à la caserne Adams, Washington se retrouve avec cinq pompiers affectés. Jean Fiorini a cependant demandé un transfert, et sa demande a été approuvée. Un technicien SIG responsable du maintien des données SIG du service incendie met à jour l'enregistrement de Jean dans la table du personnel avec le nouveau numéro de caserne. Elle reçoit un message lui signalant que cette modification enfreint une règle.
- Note : Selon la version d'ArcGIS utilisée et comment la relationship class a été configurée, les modifications qui entrent en conflit avec une règle de relationship class peuvent ne pas être acceptées.
La base de données sait que sans Jean, Washington aura moins de cinq membres du personnel affectés. Pour respecter la règle de relationship class, le technicien doit d'abord ajouter un pompier à la caserne Washington, puis modifier l'enregistrement de Jean pour refléter sa nouvelle affectation.
Une relationship class vise à garantir que toutes les modifications des données sont valides et que la base SIG d'une organisation reflète précisément et soutient les besoins réels. Supposons que la personne ayant approuvé le transfert de Jean n'ait pas réalisé que Washington ne compterait plus que quatre pompiers. La règle de relationship class a mis en lumière cette information clé, et nous supposerons que le technicien SIG communique ce problème afin d'éviter toute perte matérielle ou humaine ultérieure due à un effectif insuffisant.
Vous souhaitez en savoir plus sur les relates et les relationship classes ? Consultez ces sujets d'aide :
Pour une formation détaillée et une pratique concrète avec relates, relationship classes et autres capacités géodatabase qui garantissent l'intégrité des données, suivez notre cours Managing Geospatial Data in ArcGIS.
