Exemples de données non chronologiques

Avant de passer à une étude plus détaillée des chronologies, voici une remarque d'avertissement concernant les données qui ont tendance à ne pas être adaptées aux chronologies.

Certains types de données ne sont pas adaptés aux chronologies, car elles ne varient pas avec le temps. Parmi les exemples courants :

Identificateurs uniques
L'une des caractéristiques d'un identificateur unique est qu'il ne varie pas intentionnellement au fil du temps. Par exemple, chaque personne peut être associée à un numéro de sécurité sociale unique. Ce numéro doit être modélisé en tant que nombre, et non Timeline<Number>. En revanche, le nom d'une personne peut varier au fil du temps, par exemple suite à un mariage ou à un acte formaliste. C'est l'une des raisons pour lesquelles il n'est pas judicieux de le choisir comme identificateur (avec l'absence d'unicité) ;
Dates
Les données de type date ne varient pas au fil du temps ¹. Par exemple, la date de naissance d'une personne est une date en particulier, et doit donc être modélisée en tant que date, et non en tant que Timeline<Date>. Les dates peuvent être utilisées pour construire une chronologie (par exemple, les dates de naissance et de décès d'une personne permettent de construire une Timeline<Boolean> indiquant si la personne est vivante, mais les dates elles-mêmes ne sont pas des chronologies).
Données ponctuelles
Certaines données capturent intentionnellement les données qui s'appliquent uniquement à une date spécifique. Par exemple, un élément de données surnameAtBirth doit être modélisé sous forme de chaîne, et non de Timeline<String>. Un élément de données incomeAtRetirement doit être modélisé sous forme de nombre, et non de Timeline<Number>

ATTENTION :

Lors de la modélisation de données, il est très important d'être clair en indiquant si l'élément de données varie effectivement au fil du temps. N'utilisez la chronologie que pour les éléments de données dont la valeur peut varier au fil du temps.

¹ Dans Cúram, certains éléments de données, tels que les informations collectées, peuvent avoir deux sortes d'historique enregistré :

Un historique de successions de données concernant les changements de situation réels, c'est-à-dire les cas où un événement se produit dans le monde réel et signifie que la représentation système de ces données est désormais obsolète, par exemple un changement de revenus de la personne dû à une augmentation ; et
Un historique de corrections des données conservées sur le système, dans lequel il s'avère que le système possède une représentation incorrecte de circonstances réelles ; par exemple, la date de début d'emploi d'une personne a été enregistrée de manière incorrecte.

En tant que tel, pour les éléments de données de type Date, les données peuvent être corrigées dans le système, mais jamais remplacées. Par conséquent, il peut exister un historique de corrections lié à l'élément de données, mais celui-ci (c'est-à-dire les dates auxquelles l'élément de données a été créé) est rarement utile lors de la création de règles CER.

En règle générale, les types de données utilisés dans les règles CER doivent modéliser des circonstances réelles, plutôt que des corrections à la représentation système. Utilisez la chronologie dans les cas où ces circonstances réelles peuvent varier au fil du temps ; et n'utilisez pas la chronologie dans les cas où les données réelles ne peuvent pas varier au fil du temps.