Databases Reference
In-Depth Information
sufficient to suggest, logical and physical data independence are basically the same problem, too;
they too differ only in that they show up at different points in the overall system architecture).
Views Serve a Variety of Purposes
In
SQL and Relational Theory
, I said views serve two rather different purposes. To be specific, I
said the following:
The user who actually defines a given view
V
is, obviously, aware of the expression
exp
,
say, that defines that view (i.e., the corresponding view defining expression). Thus, that
user can use the name
V
wherever the expression
exp
is intended. However, such uses are
basically just shorthand, and are explicitly understood to be just shorthand by the user in
question. What's more, the user in question is perhaps unlikely to request any updates on
V
—though if such updates are requested, they must behave as expected, of course.
By contrast, a user who's merely informed that
V
exists and is available for use is
supposed, at least ideally,
not
to be aware of that view defining expression; to that user, in
fact,
V
is supposed to look and feel just like a base relvar, as I've said (see the foregoing
discussion of logical data independence).
Of these two purposes, it's the second that's the important one, and the one that's the
primary focus of this topic. Note, however, that it subdivides into two further possibilities: The
views seen by a given user can effectively be equivalent either (a) to the underlying base data in
its entirety—see the discussion of information equivalence later in this chapter—or (b) to some
proper subset of that underlying base data. The latter case constitutes one form of
information
hiding
. And as noted in Chapter 1 (see the section “There's No Magic” in that chapter), a user
from whom information is hidden is seeing only part of the picture, as it were, and it's only to be
expected that there'll be certain operations that such a user can't be allowed to perform. We'll
see several examples of such situations in later chapters.
Note:
One specific reason for using views to hide information is
security
. For example, a
rule to the effect that some user isn't allowed to see supplier cities can be enforced by making
that user use a view that's the projection of relvar S on all attributes but CITY. In my opinion,
however, there are better ways to manage authorization than using views: better ways, that is, of
controlling who is allowed to do what to what data (see, e.g., my topic
An Introduction to
Database Systems
, 8th edition, Addison-Wesley, 2004). In other words, I regard this use of
views as a red herring, and I don't propose to say much about it in this topic.
