Databases Reference
In-Depth Information
Once again, the restriction conditions could be dropped without loss, this time from both
the insert rule and the delete rule (why, exactly, in each case?).
Of course, as explained in the introduction to this chapter, we're talking about an
intersection example, and thus we're dealing with a situation in which information equivalence is
lost more or less by definition. To spell the point out, any information that can be represented by
relvar XLP alone can certainly be represented by relvars NLS and NPS taken in combination, but
the converse is false. (Here's an example of a query on the latter that has no exact counterpart on
the former: “Get suppliers in London.”) As a consequence, it should be obvious that there'll be
certain updates that can be done on NLS and/or NPS that have no exact counterpart on XLP. An
example of such an update is “Insert a tuple for supplier S9 into NPS without simultaneously
inserting that same tuple into NLS” (i.e., update the database to say there's a “new” supplier S9
who is located in London). However, despite all of the foregoing—despite the lack of
information equivalence in particular—it is at least true that updates on the intersection view
XLP always work satisfactorily. And the reason for this satisfactory state of affairs is precisely
that the overlap in this example is explicit.
Now let's briefly consider a user who sees just relvar XLP (an information hiding
situation). Such a user:
a.
Will know the relvar predicate;
b.
Will know that supplier numbers are unique and CITY values are never London or Paris;
c.
Won't be aware of any compensatory actions.
Such a user can't be allowed to insert tuples into the relvar, nor to update supplier numbers
within the relvar, because such operations have the potential to violate constraints of which the
user is unaware.
Finally, let me point out that if NLS and NPS are indeed themselves views (i.e., views of
relvar S), then XLP could alternatively have been defined directly as a restriction of S, thus:
S WHERE CITY
≠
'London' AND CITY
≠
'Paris'
Let's call this restriction XLP′. Clearly, then, updates on XLP′ should have the same effect as
updates on XLP—and so they do. To be specific:
INSERT: Tuples to be inserted into either XLP or XLP′ must have CITY value neither
London nor Paris and so must be inserted into the other as well.
