Databases Reference
In-Depth Information
today. Rather, this is more like what philosophers call a rational
reconstruction of what happened. It seems to us that, in fact,
warehouses are the form that backup files took when brought
on-line and assembled into a single database instance, and data
marts are the form that transaction logs took when brought on-
line and assembled into their database instances. The former is
history as a series of states that things go through as they change
over time. The latter is history as a series of those changes
themselves.
But warehouses and data marts are macro structures. They
are structures of temporal data at the level of databases and their
instances. In this topic, we are concerned with more micro-level
structures, specifically structures at the level of tables and their
instances. And at this level, temporal data is still a second-class
citizen. To manage it, developers have to build temporal
structures and the code to manage them, by hand. In order to
fully appreciate both the costs and the benefits of managing
temporal data at this level, we need to see it in the context of
methods of temporal data management as a whole. In Chapter
1, the context will be historical. In the next chapter, the context
will be taxonomic.
In this topic, we will not be discussing hardware, operating
systems, local and distributed storage networks, or other
advancesintheplatformsonwhichweconstructtheplaces
where we keep our data and the pipelines through which we
move it from one place to another. Of course, without signifi-
cant progress in all of these areas, it would not be possible to
support the on-line management of temporal data. The reason
is that, since the total amount of non-current data we might
want to manage on-line is far greater than the total amount of
cu rentdatathatweareadydomanageon ine,the
technologies for managing on-line data could easily be over-
whelmed were those technologies not
rapidly advancing
themselves.
We have already mentioned, in the Preface, the differences
between non-temporal and temporal data and, in the latter cate-
gory, the two ways that time and data are interwoven. How-
ever it is not until Part 2 that we will begin to discuss the
complexities of bi-temporal data, and how Asserted Versioning
renders that complexity manageable. But since there are any
number of things we could be talking about under the joint
heading of time and data, and since it would be helpful to
narrow our focus a little before we get to those chapters, we
would like to introduce a simple mental model of this key
set of distinctions.
