Databases Reference
In-Depth Information
And I hope you can see that, from this user's perspective, all updates—all INSERTs, all
DELETEs, all UPDATEs, and more generally all relational assignments—work exactly as
expected.
Information Hiding
Now what about a user who sees only relvar NLS, say? Such a user knows the pertinent
predicate (see above), knows the pertinent type information, knows also that {SNO} is a key for
the relvar, and is aware of the following constraint:
CONSTRAINT ...
IS_EMPTY ( NLS WHERE CITY = 'London' ) ;
Clearly, this user can't be allowed to insert tuples into relvar NLS, nor to update supplier
numbers within that relvar, because such operations have the potential to violate certain
constraints that (of necessity) are hidden from the user in question. In other words, the user is
seeing only part of the picture, as it were. As I put it in Chapter 1, there's no magic! To state the
matter a little more precisely, there's no information equivalence here—there are clearly
propositions that can be represented by relvar S and not by relvar NLS, and so it's only to be
expected that there'll be operations available on relvar S that have no counterpart on relvar NLS
when considered in isolation.
That said, I do need to elaborate somewhat ... First of all, when I say some user “can't be
allowed” to perform some operation on some relvar, what I mean, of course, is that the user in
question shouldn't be granted the relevant authority. In other words, I'm assuming the DBA, or
some other suitably authorized user, will use the authorization subsystem appropriately in order
to ensure that operations that don't make much sense can't be attempted.
Second, to repeat something I said in Chapter 1, I suppose it
might
be possible to allow the
user to perform such operations after all, just so long as he or she is prepared to accept
occasional error messages to the effect that an operation is rejected simply “because the system
says so,” without further explanation. The point is this: Whether such an operation succeeds or
fails will depend in general, not only on those hidden constraints as such, but also on the current
state of the hidden part of the database. (As a concrete illustration of this point, given our usual
sample values, inserting the tuple (S1,Smith,20,Paris) into NLS will fail, while inserting
(S6,Smith,20,Paris) will succeed.) From the user's point of view, in other words, the behavior of
such operations will be both unpredictable and (when they fail) inexplicable. Such a situation
seems to me highly unattractive, and I therefore don't propose that such a possibility be
supported.
