Modèle de relation¶

Une relation est un lien entre deux entités dans le modèle Tracker. Une relation est considérée comme une donnée dans DHIS2 et est basée sur un type de relation, de la même manière qu'une entité suivie est basée sur un type d'entité suivie.

Les relations relient toujours deux entités. Il peut s'agir des entités suivies, des inscriptions et des événements, ainsi que toute combinaison de ces entités. Notez que toutes ces combinaisons ne sont pas actuellement disponibles dans l'interface utilisateur.

Les relations entre les entités peuvent être classées comme unidirectionnelles ou bidirectionnelles, chaque type nécessitant différents niveaux d'accès pour leur création.

• Les relations unidirectionnelles exigent que l'utilisateur ait :
  • Accès en écriture à l'entité "A"
  • Accès en lecture à l'entité "B"
• Les relations bidirectionnelles nécessitent un accès en écriture aux entités "A" et "B".

Lors de la récupération des relations à partir d'un [endpoint de l'exportateur du Tracker] (#webapi_tracker_export), seules celles provenant de l'entité demandée sont affichées. Cela signifie que l'entité fait partie d'une relation bidirectionnelle ou l'entité "A" est dans une relation unidirectionnelle.

Type de relation¶

Un type de relation est la définition des propriétés que possède une relation. Les relations sont toujours composées de deux côtés, appelés "de" et "à", et les entités qui peuvent être contenues pour chaque côté sont déterminées par le type de relation. Les propriétés qui déterminent ce que chacun des côtés peut contenir sont appelées contraintes, respectivement deContrainte et àContrainte. Ces contraintes sont importantes lorsque l'on travaille plus tard avec les données, pour comprendre ce qu'une relation peut et ne peut pas contenir.

Chacune des contraintes définies dans le type de relation est constituée de plusieurs propriétés. La propriété principale est l'entité relationnelle, qui décide du type d'entités que la relation peut contenir. Les entités peuvent être l'une des suivantes pour chaque contrainte :

• Entité suivie
• Inscription
• Événement

Selon le type d'entité de relation que vous sélectionnez, vous pouvez choisir des limitations supplémentaires pour chaque contrainte. Le tableau suivant explique les différentes combinaisons que vous pouvez configurer :

Ces limitations supplémentaires exigeront que l'entité corresponde à la limitation fixée avant de pouvoir être créée. Par exemple, si votre relation est entre une mère et un enfant, les deux contraintes auront leur type d'entité suivie requise fixée à Personne et pourraient facultativement fixer l'Inscription au Programme de santé maternelle et au Programme pour enfants respectivement. De cette façon, seules les instances d'entité suivie de type Personne et inscrites au programme requis peuvent être incluses dans ces relations.

En plus des contraintes définies par un type de relation, chaque relation peut être configurée comme étant bidirectionnelle, "true" ou "false".

• Si la propriété est définie sur false, la relation est unidirectionnelle.
• Si elle est définie sur "true", la relation est bidirectionnelle. Comme indiqué précédemment ici, ce paramètre a une incidence sur les niveaux d'accès requis pour la création de la relation, et sur les relations affichées lors de l'exportation d'une entité qui fait partie de la relation.

Une chose importante que l'on doit noter à propos des relations bidirectionnelles, c'est que les côtés "de" et "à" sont toujours significatifs dans la base de données, ce qui signifie que chaque entité doit correspondre à la contrainte pour ce côté. Cependant, du point de vue de l'utilisateur, le côté dans lequel chaque entité est stockée est négligeable.

Example¶

• Bidirectional relationship relA connects teA to teB and connects teB to teA.
• Unidirectional relationship relB connects teA to teC but DOES NOT connect teC to teA.
• teA originates relationships relA and relB.
• teB originates relationships relA.
• teC originates no relationships.
• relA originates from teA and from teB, and points to teA and to teB.
• relB originates from teA and points to teC.