Des règles attributaires peuvent être utilisées pour lire et mettre à jour des enregistrements associés de jeux de données qui participent à des classes de relations dans une géodatabase. Des règles peuvent être appliquées aux classes d’entités et tables qui participent à des classes de relations, qui incluent des pièces jointes et une annotation liée à une entité. Des règles attributaires peuvent également être utilisées pour intercepter des événements de mise à jour de mises à jour effectuées dans les classes d’origine et de destination d’une relation (à savoir, ajout, retrait ou suppression d’un enregistrement associé). Par exemple, une règle attributaire de calcul immédiat peut mettre à jour un champ attributaire lorsqu’une entité est ajoutée à une classe d’entités associée.
Événements de déclenchement avec des classes de relations
Les règles attributaires immédiates sont déclenchées sur des événements de mise à jour, comme des opérations d’insertion, de mise à jour et de suppression. Lorsque vous ajoutez un enregistrement associé à ArcGIS AllSource à l’aide des options Add New To Relationship (Ajouter un nouvel élément à la relation) ou Add Selected To Relationship (Ajouter l’élément sélectionné à la relation) du menu contextuel, plusieurs événements de mise à jour sont déclenchés.
Si vous utilisez l’opération Add New To Relationship (Ajouter un nouvel élément à la relation) du menu contextuel, les événements suivants se produisent :
- Une ligne vide est créée dans la table de destination de la classe de relations.
- Insérez un déclencheur sur la ligne de destination.
- La clé étrangère est définie sur la ligne de destination.
- Mettez à jour le déclencheur sur la ligne de destination.
Les opérations Add Selected To Relationship (Ajouter l’élément sélectionné à la relation) et Remove From Relationship (Supprimer de la relation) du menu contextuel peuvent également être utilisées.
Le tableau ci-après répertorie les fonctions spécifiques qui peuvent être distinguées sur l’événement de mise à jour en comparant $originalFeature.key et $feature.key.
| Fonction | Événement | Expression ArcGIS Arcade |
|---|---|---|
Ajouter une entité à une relation | Mettre à jour | Isempty($originalfeature.key) == true et isempty($feature.key) == false |
Ajouter les entités sélectionnées à une relation | Mettre à jour | Isempty($originalfeature.key) == true et isempty($feature.key) == false |
Supprimer une entité d’une relation | Mettre à jour | Isempty($originalfeature.key) == false et isempty($feature.key) == true |
Supprimer une opération effectuée sur un enregistrement associé | Suppr |
Lire les enregistrements associés
Si vous utilisez des classes de relations, vous pouvez lire les enregistrements associés à l’aide de fonctions Arcade qui renvoie les enregistrements associés des entités en entrée.
- FeatureSetByRelationshipName : l’exécution est limitée au contexte du serveur. Si vous utilisez cette fonction pour les règles attributaires, vérifiez que l’option Exclude from application evaluation (Exclure de l’évaluation de l’application) est activée.
- FeatureSetByRelationshipClass : prend en charge l’exécution à la fois côté serveur et côté client. Les règles qui utilisent cette fonction peuvent être exécutées en local dans l’application (par exemple, ArcGIS AllSource et ArcGIS Maps SDKs for Native Apps) avant que la mise à jour ne soit envoyée à la source de données.
Vous pouvez également lire les enregistrements associés à l’aide de la fonction Arcade FeatureSetByName et les filtrer en fonction de la clé étrangère.
Lisez les enregistrements associés d’une classe de relations à l’aide de la fonction ArcadeFeatureSetByName.
Une règle de calcul est créée sur le champ InspectionCount dans la classe d’entités du poteau qui fait partie d’une classe de relations un vers plusieurs avec la table d’inspections. La fonction FeatureSetByName permet de lire directement la classe d’inspections et d’extraire les enregistrements associés lors de la mise à jour. L’utilisation de cette fonction Arcade nécessite de connaître le champ de la classe de relations. Pour cette classe de relations, la clé primaire d’origine est le champ globalID de la classe d’entités du poteau et la clé étrangère d’origine est le champ poleguid de la table autonome d’inspections.//A calculation rule that returns the count of a pole inspection records.
//When a pole feature is updated, the calculation rule reads all its related inspections records from the comments field and returns the total inspection count for that feature.
Var fs = FeatureSetByName($datastore, “Inspection”, [“comments”], false)
Var poleGuid = $feature.poleguid
Var fsinspected = Filter(fs, “POLEGUID= @poleguid”);
Return count(fsinspected)
Lisez un enregistrement associé d’une classe de relations à l’aide de la fonction ArcadeFeatureSetByRelationShipName.
Le même script permettant de lire les enregistrements associés d’une classe de relations peut être réécrit avec la fonction FeatureSetRelationshipName. Si vous utilisez cette fonction, vous n’avez pas besoin de connaître la clé étrangère, mais uniquement le nom de la relation, à savoir pole_inspection.
Attention :
Si vous utilisez cette fonction pour créer une règle attributaire, vérifiez que l’option Exclude from application evaluation (Exclure de l’évaluation de l’application) est activée.
//A calculation rule that returns the count of a pole inspection records.
//When a pole feature is updated, the calculation rule reads all its related inspections records from the comments field and returns the total inspection count for that feature.
Var fsinspected = FeatureSetByRelationshipName($feature, “pole_inspection”, [“comments”], false)
Return count(fsinspected)Lisez un enregistrement associé d’une classe de relations à l’aide de la fonction ArcadeFeatureSetByRelationshipClass.
Le même script permettant de lire les enregistrements associés d’une classe de relations peut être réécrit avec la fonction FeatureSetByRelationshipClass. Si vous utilisez cette fonction, vous n’avez pas besoin de connaître la clé étrangère, mais uniquement le nom de la relation, à savoir pole_inspection. Cette fonction prenant en charge l’exécution à la fois côté serveur et client, les règles attributaires qui utilisent cette fonction peuvent être exécutées en local dans l’application.//A calculation rule that returns the count of a pole inspection records.
//When a pole feature is updated, the calculation rule reads all its related inspections records from the comments field and returns the total inspection count for that feature.
Var fsinspected = FeatureSetByRelationshipClass ($feature, “pole_inspection”, [“comments”], false)
Return count(fsinspected)
Créer, mettre à jour et supprimer des enregistrements associés
Les enregistrements associés de classes de relations peuvent également être mis à jour à l’aide de règles de calcul en fonction du renvoi du dictionnaire.
Voici un exemple de création de règle de calcul qui crée un enregistrement associé. Lorsque le champ de commentaire d’un poteau est mis à jour par l’utilisateur, le mot-clé du dictionnaire edit est utilisé pour créer un enregistrement d’inspection. De même, vous pouvez mettre à jour ou supprimer des enregistrements associés. Pour en savoir plus, reportez-vous à la rubrique Mots-clés du dictionnaire de règles attributaires.
Ajoutez un nouvel enregistrement associé pour une classe de relations lors d’une mise à jour.
Une règle de calcul permet de créer un nouvel enregistrement associé lorsque le champ de commentaire d’un poteau est mis à jour par l’utilisateur. Dans cette expression, le mot-clé du dictionnaire edit est utilisé pour créer un nouvel enregistrement d’inspection si le champ des commentaires est modifié. De même, vous pouvez mettre à jour ou supprimer des enregistrements associés. Pour plus d’informations, reportez-vous à la rubrique Mots-clés du dictionnaire de règles attributaires.//A calculation rule that triggers on an update event when the pole comment field is edited.
//The expression first checks if the comment field changed and creates a new related record.
If ($originalfeature.comment != $feature.comment)
{
Return {
“edit”: [{
“className”: “inspection”,
“adds”: [{ “attributes”: { “comments”: $feature.comment } }]
}]
}
Return;
Valider et évaluer les règles de la classe de relations
Des règles attributaires de validation ou decontrainte peuvent être créées et appliquées pour faire respecter les règles de la classe de relations.
Par exemple, il existe une configuration de classe de relations entre la classe d’entités des pylônes (origine) et la table Inspections (destination). Au moins une inspection ou plusieurs inspections doivent être enregistrées pour chaque pylône.
Pour ce faire, vous pouvez créer une règle de classe de relations un vers un (1:1) ou un vers plusieurs (1:M) entre ces données associées. Une fois la règle de classe de relations créée, vous pouvez utiliser le script suivant pour écrire une règle attributaire de validation à appliquer à la classe d’entités des pylônes (origine) pour imposer que chaque pylône passe avec succès une ou plusieurs inspections ://A validation rule that ensures each pole passes one or more inspections.
var fsInspections = FeatureSetByRelationshipClass($feature, "poles");
if (count(fsInspections) == 0) return false;
return true;
Une fois cette règle attributaire de validation ajoutée aux données, le processus d’évaluation examine les règles applicables aux données pour s’assurer qu’elles sont respectées. La méthode d’évaluation utilisée dépend du type de règle et des propriétés.
Les règles de validation sont évaluées au moment spécifié par l’utilisateur à l’aide de la vue Error Inspector (Inspecteur d’erreurs) ou de l’outil Évaluer les règles. Au cours de l’évaluation, une règle de validation crée des entités d’erreurs signalant les entités à l’origine des violations des règles. Les entités d’erreurs pour ces règles peuvent être examinées dans la vue Error Inspector (Inspecteur d’erreurs).
Remarque :
Vous pouvez créer ces règles à l’aide de la fonction Arcade FeatureSetByRelationshipName ou FeatureSetByRelationshipClass. La fonction FeatureSetByRelationshipClass vous permet d’évaluer les règles par le biais d’un service côté client. Elle requiert ArcGIS Pro 3.2 ou version ultérieure et est expliquée dans la section Lire les enregistrements associés ci-dessus.
Pour modifier cette règle attributaire afin d’imposer qu’un pylône ne fasse l’objet que d’une seule inspection ou ne fasse l’objet d’aucune inspection, vous pouvez réécrire le script comme suit ://A validation rule that ensures each pole has one or fewer inspections.
var fsInspections = FeatureSetByRelationshipClass($feature, "poles");
if (count(fsInspections) > 1 ) return false;
return true;
Vous pouvez également créer et appliquer une règle attributaire de contrainte aux données. Les règles de contrainte spécifient des configurations d’attributs acceptables et des relations générales sur une entité. À la différence des règles de calcul, les règles de contrainte ne sont pas utilisées pour renseigner des attributs. Elles permettent de s’assurer que des conditions spécifiques sont remplies pour une entité et peuvent empêcher la mise à jour si une condition n’est pas remplie.
Les règles de contrainte sont évaluées au cours des opérations de mise à jour pour les événements déclencheurs tels que l’insertion, la mise à jour, et la suppression et renvoient la valeur vrai ou faux pour indiquer si une règle a été respectée ou non, comme suit :
- Vrai : l’expression de script fournie est respectée et l’entité sera créée.
- Faux : l’expression de script fournie n’est pas respectée et l’entité ne sera pas créée.
Lors de la création et de l’application de règles attributaires de contrainte, prêtez une attention particulière au déclencheur de mise à jour.
Par exemple, une règle attributaire de contrainte est créée et appliquée à la classe d’entités des pylônes pour imposer qu’au moins un événement d’inspection existe pour chaque pylône dans la classe d’entités des pylônes. Si la règle attributaire de contrainte est configurée pour un déclenchement en cas d’insertion, par exemple lorsqu’un nouveau pylône est ajouté, la création du pylône échoue. Dans ce scénario, il est recommandé de créer la règle attributaire de contrainte avec un déclenchement en cas de mise à jour et non en cas d’insertion.
Remarque :
Le bouton Ready to Use Rules (Règles prêtes à l’emploi) 
permet d’accéder à une galerie de vérifications configurables prenant en charge la création de règles de contrainte et de validation. Ce bouton est disponible avec une licence ArcGIS Data Reviewer.
En savoir plus sur la création de règles attributaires à l’aide de ArcGIS Data Reviewer
En savoir plus sur la création et la gestion des règles attributaires
Vous avez un commentaire à formuler concernant cette rubrique ?