Databases Reference
In-Depth Information
Logical Data Model
Temporal Requirements
Physical Data Model
Temporal Metadata
An Asserted Versioning Database
Non-Temporal Tables
Asserted Versioning Tables
TEI Enforcement
TRI Enforcement
Figure 8.1 Designing and Generating an Asserted Versioning Database.
version tables. This means that when building new logical data
models, or extending old ones, data modelers can ignore tempo-
ral requirements and focus on design issues which are often
complex enough without introducing temporal considerations.
It means that temporal requirements can be expressed declara-
tively, in metadata associated with a conventional data model,
rather than by hardcoding those requirements in the data model
itself.
This greatly simplifies the work of the data modeler. Her
work, as far as temporality is concerned, is not to translate tem-
poral requirements into data model constructs. Instead, it
becomes that of simply expressing business requirements for
temporal data as a set of metadata associated with the data
model.
As well as developing the logical model, the other task for the
data modeler is to translate business requirements for temporal
information into metadata. There are metadata entries for each
table in the data model which is to be generated as an asserted
version table. For these tables, there are entries to specify which
business column or columns make up the business key for the
table. This metadata also provides the information which the
AVF needs to enforce temporal entity integrity and temporal
referential integrity.
Once the logical model and its associated metadata are com-
plete, the next step is to generate a physical data model from the
logical model. At this point, of course, the physical model that is
