Databases Reference
In-Depth Information
with future effective end dates automatically roll off the view
when that date arrives. This responsiveness to the passage of
time is a feature of most Asserted Versioning views, and because
of it, these views remain current and do not have to be periodi-
cally modified.
A non-temporal view presents a conventional table as a
queryable object. The mental image associated with this view is
that there is no such thing as assertion time or effective time; there
is simply the eternal present, our efforts to update data to keep up
with it, and our occasional updates to correct mistakes we have
made along the way. This view supports the mental image of a
conventional table for the person querying the database.
And the mental image of a conventional table is also
supported for those updating an asserted version table, not just
for those querying one. As long as they do not specify either
assertion time or effective time on their insert, update or delete
transactions, it will seem to them that they are maintaining data
in a conventional table. This maintenance is not done by writing
SQL transactions; it is done by making an API Call to our
Asserted Versioning Framework.
6
These are insert, update and
delete transactions that are submitted via the API to the AVF.
We call them temporal transactions, and our first introduction
to how they work will be in Chapter 7. Our point here is that in
a database all of whose tables are asserted version tables, any
table can be made to look like a conventional table to those
who query it and to those who maintain it. And by the same
means, any table can be made to look like a version table to both
sets of users, or like an assertion table.
But as important as views are, we believe that most SQL writ-
ten against asserted version tables, at least SQL that is written by
developers, will not make use of views. The reason is that views
have limited flexibility, and that the benefits they provide in
return are often not that important to developers.
The benefit provided by views is simplification. Views can
select a specific set of rows, implement specific joins, and proj-
ect a specific set of columns from across the joined tables. The
larger the number of queries that would otherwise have to do
this same work themselves, the more value the view provides.
With a view, these specifications are written once, not once in
each of the queries that share the criteria.
6
However, as we go to press, we have incorporated Instead Of triggers in release 1 of
the Asserted Versioning Framework. With these triggers, the person writing these
transactions is able to write them as standard SQL transactions, and the AVF will
translate them into the physical SQL which will update the database.
