Ejemplos de datos que no son de línea de tiempo

Antes de continuar examinando las líneas de tiempo de manera más detallada, una nota de precaución sobre los datos que tienden a no ser adecuados para las líneas de tiempo.

Determinados tipos de datos no son adecuados para las líneas de tiempo, ya que los datos no varían con el tiempo. Son ejemplos comunes:

Identificadores exclusivos
Una de las características de un identificador exclusivo es que deliberadamente no varía a lo largo del tiempo, por ejemplo cada persona puede tener asignado un número de la seguridad social exclusivo. El número de la seguridad social se debe modelar como un número, no una línea de tiempo<Número>. Por el contrario, el nombre de una persona puede variar con el tiempo, por ejemplo debido al matrimonio o a un cambio de nombre por escritura unilateral, que es una de las razones por la que esta es una mala elección como identificador (además de la falta de exclusividad);
Fechas
Los datos de tipo fecha no varían con el tiempo¹. Por ejemplo, la fecha de nacimiento de una persona es una fecha concreta y por lo tanto no se debe modelar como fecha, ni como una Línea de tiempo<Fecha>. Las fechas pueden utilizarse para construir una línea de tiempo (por ejemplo, la fecha de nacimiento y la fecha de defunción de una persona se utilizarán para construir una Línea de tiempo<Booleano> para determinar si la persona está viva, pero las fechas en sí mismas no son líneas de tiempo).
Datos de punto en el tiempo
Algunos datos capturan intencionadamente datos que se aplican sólo a una fecha determinada. Por ejemplo, un elemento de datos para surnameAtBirth se debe modelar como una serie, no una línea de tiempo<Serie>. Un elemento de datos para incomeAtRetirement se debe modelar como un número, no como una Línea de tiempo<Número>

PRECAUCIÓN:

Al modelar datos es muy importante tener claro si el elemento de datos realmente varía a lo largo del tiempo. Utilice sólo la línea de tiempo para elementos de datos donde el valor puede variar con el tiempo.

¹ En Cúram, determinadas partes de datos, por ejemplo Prueba, pueden tener dos clases de historial almacenadas:

Un historial de sucesiones de datos relacionados con los cambios de circunstancias en el mundo real, es decir, donde se produce un suceso en el mundo real lo que significa que la representación del sistema de dichos datos está ahora anticuada, por ejemplo un cambio en los ingresos de una persona debido a un aumento salarial y
Un historial de correcciones en los datos mantenidos el sistema, donde el sistema tiene una representación incorrecta de las circunstancias del mundo real, por ejemplo se encuentra que la fecha de inicio de empleo de una persona se ha registrado correctamente.

Por eso, para elementos de datos de tipo fecha, los datos se pueden corregir en el sistema, pero nunca con éxito. De este modo puede haber un historial de correcciones para el elemento de datos, pero este historial de correcciones (es decir las fechas en las que se ha creado el elemento de datos) raramente tiene interés al crear las reglas de CER.

Normalmente, los tipos de datos utilizados en las reglas de CER deben modelar circunstancias del mundo real, en lugar de correcciones en la representación del sistema. Utilice la línea de tiempo donde esas circunstancias del mundo real puedan cambiar a lo largo del tiempo y no utilice la línea de tiempo donde los datos del mundo real no puedan variar con el tiempo.