You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
BITEMPORAL<br />
MarkLogic's bitemporal feature allows you to track database documents along two<br />
time axes simultaneously. It lets you keep track of the time when a fact was true<br />
(the valid time) as well as the time when the database knew that truth (the system time).<br />
Tracking data on two time axes is critical in industries such as finance, insurance, and<br />
intelligence. It enables organizations to justify why they made decisions based on what<br />
they knew about the world at a given time.<br />
How does MarkLogic manage bitemporal data? Each temporal document has four<br />
timestamp values (valid start, valid end, system start, and system end) that define the<br />
effective valid and system times for the document data. When you insert temporal<br />
documents for new time periods, MarkLogic keeps track of the system timestamp<br />
values and makes sure the overall version history is filled in appropriately. By default,<br />
the versions that make up the bitemporal history of a document never go away<br />
(although their timestamps may change).<br />
You can query bitemporal data by specifying ranges for the valid and system times. To<br />
resolve bitemporal queries, MarkLogic uses four range indexes, one for each timestamp,<br />
to quickly isolate the matching documents.<br />
A BITEMPORAL EXAMPLE<br />
Imagine a simple example where we're tracking a person's location over time with<br />
temporal documents. The valid time indicates when the person truly was at a location<br />
while the system time tracks when we knew that information (by default, this is based<br />
on when the document was saved in the database). Each time the person's location<br />
changes, we ingest a new temporal document representing that knowledge. Behind the<br />
scenes, MarkLogic performs housekeeping on the existing temporal documents to keep<br />
the timestamps up-to-date so we have a history of "what we knew" and "when we<br />
knew it."<br />
Let's say that a person moved to the city of Alameda on January 1. We learn about<br />
this and add the data to our database on January 5. Since our document is a temporal<br />
document, it includes four timestamps—a valid start, valid end, system start, and system<br />
end. At this point, we've never known the person to be anywhere else, so only the start<br />
times are set (the end times stay set to the default, infinity). The valid start time tells us<br />
when the person was in Alameda, and the system start time records when we knew it:<br />
90
Change language