Design Pattern - Generic - Nontemporal Data

Purpose

This Design Pattern describes nontemporal data — data without any reference to time — and how to handle it in a data solution.

Motivation

In a nontemporal environment, data simply ‘is’. A record represents the current state until it is updated, and when that happens the previous state is gone. If a customer changes their phone number, it is no longer possible to retrieve the previous one, nor is there any record of when, or how often, the change occurred.

Many systems still work this way. In fact, one of the use cases for implementing a data solution is to ensure that previous states can be reproduced, even when the operational system cannot do so. Understanding nontemporal data is therefore a prerequisite for deciding how — and whether — to add timelines to it.

Applicability

This pattern applies when deciding how to model data that carries no time component of its own:

Data from operational systems that only maintain current state.
Reference data that rarely, if ever, changes.
Events generated by streaming technology, such as sensor measurements. In these cases it is highly unlikely, or even technically impossible, to receive updates — the only information received is the value ‘now’.

Structure

A nontemporal data object stores only the most recent version of each record:

There is no timestamp that supports historical queries.
An update replaces the previous state, which is lost.
Point-in-time analysis and audit requirements cannot be supported.
Storage requirements are lower than for temporal approaches.

Events are a special case: each event is immutable and complete at the moment it occurs, so there is nothing to update and no historization within the record itself.

Implementation guidelines

Unless there are compelling reasons to do otherwise, implement even genuinely nontemporal data as a unitemporal or bitemporal data object (Satellite). This avoids defining separate patterns and templates for an exceptional case, thereby simplifying the overall solution.
When event data is loaded into a temporal structure this way, note that — strictly speaking — it is not temporal data: the values will never change over time. The timelines simply remain trivially complete.
Reserve truly nontemporal storage for cases where history is genuinely not required and will never be required, since the decision is effectively irreversible: history that was not captured cannot be reconstructed later.

Considerations and consequences

Nontemporal storage contradicts the principle of maintaining complete historical context in the integration layer, and is therefore generally discouraged there.
The simplification gained (no temporal columns, simpler queries) is paid for with the permanent loss of change history and auditability.
Standardising on temporal structures even for nontemporal sources keeps the solution uniform: one set of patterns, templates, and processes serves all data.