Databases Reference
In-Depth Information
assumption (a) is in fact the right one (i.e., if ST{SNO} and SC{SNO} are supposed to be equal
after all, even though no constraint to that effect has been explicitly stated).
Now, as I'm sure you've realized, we're dealing with a big issue here. Indeed, what we're
talking about is the classic ambiguity issue (or what some people describe as an ambiguity issue,
at any rate). To spell the point out, the fact that there doesn't seem to be a good way to choose
among the various options is exactly what critics complain about; I mean, it's exactly why some
writers believe view updating is, in the general case, impossible. So I want to present arguments
in favor of my own position, which is that I think we should go with option 3 (i.e., cascade to
both). Before I do that, however, let me just point out that no analogous problem arises in
connection with the projection counterpart to the join example under discussion, even though (as
I've said previously) join views and projection views are two sides of the same coin. The reason
is this: If we start with relvar S and replace it by its projections ST and SC, then certainly any
information that can be represented by the original design can also be represented by the revised
design. But if we start with relvars ST and SC and replace them by their join S, then it's possible
that some information can be represented by the original design and not by the revised design—
in which case information equivalence is lost. And it's only if information equivalence is lost
that the ambiguity issue arises.
Pragma
As I've said, I'm going to present arguments in favor of the position that we should go with
option 3—the position, in other words, that we should treat Example 2 as far as possible just like
Example 1. But first let me remind you of something I said in Chapter 3:
Even when we don't have information equivalence, sometimes it'll be possible to apply the view updating
rules anyway (albeit only partially, perhaps), and I'll discuss such cases in detail too.
But I must stress that
updating in such cases can lead to results that, while of course always formally predictable and well
defined, might sometimes be undesirable—possibly even unacceptable for some reason).
Because of this
state of affairs, I leave to others (perhaps the individual user, perhaps the DBA, perhaps even the DBMS) the
choice as to whether updates should in fact be allowed in such situations.
The case at hand is a perfect example of the foregoing; to go with option 3 means,
precisely, applying the rules that work in the information equivalence case to the case where
information is hidden, or lost. In other words, there's a clear element of pragma involved in my
position here.
6
Now, I'm going to do my best to convince you that the pragma in question makes
sense—in particular, as the extract from Chapter 3 says, it does at least produce results that are
formally predictable and well defined—but, as that extract also makes clear, it's entirely possible
that others will disagree with my position here and so might want to opt out (as it were) of my
6
Here and elsewhere in this topic I choose to overlook the fact that none of the dictionaries I consulted seem to recognize
pragma
as a legitimate English word.
