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 instance d'entité suivie est basée sur un type d'entité suivie.
Les relations comprennent toujours deux entités, et ces entités peuvent inclure des instances d'entités suivies, des inscriptions et des événements, et toute combinaison de ceux-ci. Notez que toutes ces combinaisons ne sont pas disponibles dans les applications actuelles.
En outre, les relations peuvent être définies comme unidirectionnelles ou bidirectionnelles. La seule différence fonctionnelle est qu'elles nécessitent actuellement différents niveaux d'accès pour être créées. Les relations unidirectionnelles exigent que l'utilisateur ait un accès en écriture de données à l'entité "de départ" et un accès en lecture de données à l'entité "d"arrivée", tandis que les relations bidirectionnelles exigent un accès en écriture de données pour les deux.
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 :
- Instance d'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 :
| Instance d'entité suivie | Inscription | Événement | |
|---|---|---|---|
| Type d'entité suivie | Obligatoire | Facultatif | - |
| Programme | - | Obligatoire | - |
| Étape du programme | - | Obligatoire | Facultatif |
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 qu'un type de relation peut avoir, chaque relation peut être définie comme bidirectionnelle, vraie ou fausse. Si la propriété est définie sur fausse, les relations sont alors considérées comme unidirectionnelles. Comme mentionné précédemment, la seule différence fonctionnelle entre ces relations est la rigueur de l'accès lors de leur création ou de leur mise à jour - la bidirectionnelle étant la plus stricte. Les relations sont également présentées différemment dans l'IU selon que la relation est bidirectionnelle ou unidirectionnelle.
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.