Bitemporal modeling¶

Record each fact along both valid time—when it holds in the modeled world—and transaction or system time—when the database records it—so corrections preserve what was believed earlier while enabling as-of knowledge and as-of reality queries.

Version: v3 · 2026-09-19 · History
Domain-specific #: 1388
Domain group: Interdisciplinary & Synthetic
Origin domain: Data Science & Analytics
Subdomains: Data Management, Temporal Databases and Information Modeling → Data Science & Analytics

Core Idea¶

Bitemporal modeling represents facts with two independent temporal dimensions: valid time records when a fact is true in the modeled reality, and transaction or system time records when that version is stored or believed by the database. rather than overwrite a superseded assertion, the database closes its system-time interval and records a corrected version with its own valid-time extent; queries can then slice the two-dimensional history by what was known at one system time and what was valid at one world time.

How would you explain it like I'm…

The Two-Date Diary

Imagine a diary where every note has two dates: when the thing really happened, and when you wrote it down. If you find out you got something wrong, you do not erase it; you add a fixed note. Later you can see both what really happened and what you believed back then.

True-When and Known-When Records

Bitemporal modeling is a way of storing information in a database using two different kinds of time. One is 'valid time': when something was actually true in the real world, like when someone lived at an address. The other is 'transaction time': when the database recorded that information. When something needs fixing, the old record isn't erased. Instead, it's marked as no longer believed, and a corrected version is added. This lets you ask two kinds of questions: 'What was true on this date?' and 'What did we think was true, back on that date?'

Valid-Time and Transaction-Time History

Bitemporal modeling represents each fact with two independent time dimensions. Valid time records when the fact is true in the real world; transaction time, also called system time, records when that version was stored in, or believed by, the database. When information is corrected, the database doesn't overwrite it. It closes the old version's transaction-time interval and adds a new version with its own valid-time range. This gives a two-dimensional history, so you can ask what the database knew at a past moment and what was true at a given real-world time, and these can differ. That's more than simple versioning or an 'effective date' column, which track only one kind of time. It's especially useful for auditing corrections and reconstructing past reports exactly as they were.

Bitemporal modeling represents facts along two orthogonal time axes: valid time, when a fact holds in the modeled reality, and transaction (system) time, when a given version is stored or believed by the database. Corrections are non-destructive: a superseded assertion is not overwritten but has its system-time interval closed, and a corrected version is recorded with its own valid-time extent. Queries can then slice the two-dimensional history by what was known as of one system time and what was valid as of one world time. This is distinct from ordinary versioning, event logging, slowly changing dimensions, or a single effective-date field. The model fails if the timestamps are unlabeled, if transaction time can be edited without audit semantics, if old versions are overwritten, if valid and recorded time are forced to coincide, if interval inclusivity changes silently, or if a load timestamp is mistaken for a full system-time history. A sound implementation names both axes and their clock semantics, defines interval boundaries and current markers, specifies how inserts, corrections, and deletions close or create versions, enforces key and coalescing constraints, and demonstrates distinct as-known-then and valid-as-of queries. It enables reconstructing past reports, auditing corrections, and preventing later knowledge from contaminating reconstructions of earlier states.

Scope of Application¶

Bitemporal modeling applies when the analyst can specify a database fact or versioned record whose truth in the modeled domain and presence in the database each vary over an explicitly represented time domain and establish that every modeled fact has explicit semantics for both valid and transaction time, historical versions remain queryable, and update operations preserve the distinction between a retroactive or prospective world-time correction and the later recording event. The entry describes an information-modeling identity; legal retention, privacy, access control, storage cost, and compliance obligations remain system- and jurisdiction-specific.

Clarity¶

A clear claim names the carrier, governing rule, assumptions, and recognition test. This matters because business time, effective time, event time, load time, assertion time, and transaction time are used inconsistently across products, so two columns do not establish the intended semantics.

Identity and measurement remain separate. Clock resolution, late arrivals, time zones, backfills, batch loading, and concurrent transactions affect recorded intervals; reconstruction accuracy depends on disciplined update semantics and source completeness, not merely timestamp precision.

Manages Complexity¶

The abstraction compresses relational and graph implementations, point and interval timestamps, current-state and append-only physical designs, SQL system-versioned and application-time tables, event-sourced projections, and domain-specific additional time axes into a stable carrier, rule, invariant, and failure boundary. It makes comparison tractable while retaining the variables that control validity.

Abstract Reasoning¶

Type the carrier. Establish a database fact or versioned record whose truth in the modeled domain and presence in the database each vary over an explicitly represented time domain and reject examples from a different problem.
Lock the rule. Express that every modeled fact has explicit semantics for both valid and transaction time, historical versions remain queryable, and update operations preserve the distinction between a retroactive or prospective world-time correction and the later recording event independently of one notation or implementation.

Knowledge Transfer¶

Transfer within data management is strong when new cases preserve the same carrier, mechanism, and diagnostic. The move from A database records on March 10 that a contract rate was valid from January 1, then on April 5 learns that the rate should have changed on February 15. to A financial report is reproduced both exactly as generated at quarter close and as it would be restated using corrections entered afterward. demonstrates that continuity.

Relationships to Other Abstractions¶

Current abstraction Bitemporal modeling Domain-specific

Parents (1) — outgoing typed relations

Bitemporal modeling is a kind of Versioning Prime

The model literally retains successive record versions instead of overwriting them; What makes it its own entry: orthogonal valid-time and transaction-time histories with non-destructive correction and two-axis query semantics, rather than ordinary versioning, event logging, slowly changing dimensions, or a single effective-date field.

Hierarchy path (1) — routes to 1 parentless root

Bitemporal modeling → is a kind of Versioning

Neighborhood in Abstraction Space¶

Bitemporal modeling sits in a moderately populated region (49^th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Relational Database Theory (13 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25