Throughout this chapter, I’ve been using the term view in its original sense—the sense, that is, in which (in the relational context, at least) it was originally defined. Unfortunately, however, some terminological confusion has arisen in recent years: certainly in the academic world, and to some extent in the commercial world also. Recall that a view can be thought of as a derived relvar. Well, there’s another kind of derived relvar too, called a snapshot. As the name might tend to suggest, a snapshot, although it’s derived, is real, not virtual—meaning it’s represented not just by its definition in terms of other relvars, but also (at least conceptually) by its own separate copy of the data. For example (to invent some syntax on the fly):
VAR LSS SNAPSHOT ( S WHERE CITY = 'London' )
KEY { SNO }
REFRESH EVERY DAY ;Defining a snapshot is just like executing a query, except that:
The result of the query is saved in the database under the specified name (LSS in the example) as a “read-only relvar” (read-only, that is, apart from the periodic refresh—see the bullet item immediately following).
Periodically (EVERY DAY in the example) the snapshot is refreshed, meaning its current value is discarded, the query is executed again, and the result of that new execution becomes the new snapshot value. (Of course, other REFRESH options are possible: for example, EVERY MONDAY, EVERY 5 MINUTES, EVERY MONTH, and so on.)
In the example, therefore, snapshot LSS represents the data as it was at most 24 hours ago.
Snapshots are important in data warehouses, distributed systems, and many other contexts. In all such cases, the rationale is that applications can often tolerate—in some cases even require—data “as of” some particular point in time. Reporting and accounting applications are a case in point; such applications typically require the data to be frozen at an appropriate moment (for example, at the end of an accounting period), and snapshots allow such freezing to occur without locking out other applications.
So far, so good. The problem is, snapshots have come to be known (at least in some circles) not as snapshots at all but as materialized views. But they aren’t views! Views aren’t supposed to be materialized at all;[135] as we’ve seen, operations on views are supposed to be implemented by mapping them into suitable operations on the underlying relvars. Thus, “materialized view” is simply a contradiction in terms. Worse yet, the unqualified term view is now often taken to mean a “materialized view” specifically—again, at least in some circles—and so we’re in danger of no longer having a good term to mean a view in the original sense. In this book I do use the term view in its original sense, but be warned that it doesn’t always have that meaning elsewhere. Recommendations: Never use the term view, unqualified, to mean a snapshot; never use the term materialized view; and watch out for violations of these recommendations on the part of others!
[135] Despite the fact that, as we saw earlier, there’s at least one product on the market that does materialize them at least some of the time.