Databases Reference
In-Depth Information
Here's an example (it's a
Tutorial D
definition of the “London suppliers” view LS from
Chapter 1):
VAR LS VIRTUAL ( S WHERE CITY = 'London' ) ;
Now, it's well known that a view can be thought of as a kind of “window into” the relvar or
relvars in terms of which it's defined, in the sense that operations on the view are “really”
operations on those underlying relvars. In other words, the DBMS is supposed to support user
operations on a view, be they retrievals or updates, by mapping them—the operations, that is—
into suitable operations on the base relvars in terms of which the view in question is ultimately
defined. (I say
ultimately defined
here because if views really do behave just like base relvars,
then one thing we can certainly do is define further views on top of them, and so on to any
depth.) Thus, for example, the following expression—
LS WHERE STATUS > 10
(which can be thought of as representing a retrieval operation on view LS)—maps to:
S WHERE CITY = 'London' AND STATUS > 10
And the following update operation on LS (actually a delete)—
DELETE ( LS WHERE STATUS > 10 ) FROM LS ;
—maps to:
DELETE ( S WHERE CITY = 'London' AND STATUS > 10 ) FROM S ;
From all of the above, it's clear there's a logical difference between views and base relvars.
By
The Principle of Interchangeability
, however, that difference isn't one that should affect the
user—the aim, to repeat, is to make views “look and feel” just like base relvars as far as the user
is concerned, even with respect to updating. (The distinction between base relvars and views is
relevant to the DBA and DBMS but not, to repeat, to the user. At least, that's the intent.) In
other words, the user of a given view should ideally be unaware that his or her operations on that
view are being mapped to operations on the underlying relvar(s); ideally, in fact, that user
shouldn't even have to be aware that the view is indeed a view, nor indeed that the underlying
relvars even exist.
