Note: A glossary of technical terms used in these columns can be found on the Web sites of the authors. In addition, a listing of earlier articles and/or columns in this series can also be found on DMReview.com, MindfulData.com and InbaseInc.com.
Figure 1 is the taxonomy of temporal data management methods, which we began discussing last time. However, the section under the node "Integrated Time" has changed. We will discuss the change when we get to that part of the taxonomy.
The principal reason for discussing this taxonomy is to distinguish the various things we may mean when we talk about managing time in databases. Each method of time management has its place in an enterprise data architecture (EDA). But our specific focus, in our "Time and Time Again" series and in this column has been what Figure 1 shows as the right-hand node of the lowest branch, the one labeled "tri-temporal time." This is the method we have been calling "asserted versioning."
In our last column, we explained the distinction between reconstructable time and queryable time, and between the two kinds of queryable time - event time, which is recorded as a series of transactions against an original state of some object; and state time, which is recorded as a series of states, each new one resulting from an insert, update or delete transaction.
We continue by explaining the distinction between the two kinds of state time - snapshot time and version time.
Snapshot Time
Within the computer science community, the term "snapshot" refers to a non-temporal state table, one whose rows are physically updated as changes are submitted to it. We have referred to such tables as "non-temporal" and will continue to do so. But as we and most IT professionals use the term "snapshot," it refers to periodic copies of an entire database or at least of a number of logically related tables in a database. We will continue to use the term in this way.
The first point about snapshots is that, when they are taken, they copy entire tables or even entire databases. This is a very straightforward way of keeping track of history, at least compared to the complexities of bi- and tri-temporal data management. It is also quite wasteful, because over a typical time span of days, weeks or months, only a small number of the rows in most tables will be updated. For those rows that are not updated, snapshots are simply duplicate copies.
A second point about snapshots is that their results are kept online. This distinguishes them from the backups, archives and transaction logs, which implement what our taxonomy calls "reconstructable history."
The online results of snapshots may be stored in the same database as the tables they are copies of or in a different database. Typically, the first option is referred to as keeping a set of "snapshot tables," and the second is referred to as updating a data warehouse.
A final point about snapshots is that they may also miss changes. A row that is inserted after one snapshot and deleted prior to the next one will not show up in that next snapshot. If there are two or more updates made to the same column of a row between snapshots, only the last one will show up in the snapshot.
Be the first to comment on this post using the section below.