Databases Reference
In-Depth Information
Anyway, the most important message from the discussion overall is this:
In general,
compensatory actions apply not just to delete or insert operations taken separately, but rather to
such operations taken in combination
. Of course, for any specific update, either the delete set
d
or the insert set
i
might be empty (and if
d
is empty, the rule reduces to a simple insert rule; if
i
is
empty, it degenerates to a simple delete rule).
THE MOTIVATING EXAMPLE CONTINUED
Let's get back to relvars S, LS, and NLS. Further, let's continue to assume those relvars are all
base relvars (still no views yet). However, let me now remind you that—conceptually speaking,
at any rate—we can regard relvar S by itself as constituting a database
DB1
and relvars LS and
NLS together as constituting another database
DB2
, such that
DB1
and
DB2
are information
equivalent. So let's consider a user who sees just database
DB2
. That user:
1.
Knows the corresponding predicates:
LS:
Supplier SNO is under contract, is named SNAME, has status STATUS, and is located
in city CITY (and CITY is London).
NLS:
Supplier SNO is under contract, is named SNAME, has status STATUS, and is
located in city CITY (and CITY isn't London).
2.
Is aware of all pertinent type information, is aware of the fact that {SNO} is a key for each
of these relvars, and is aware of the following constraints:
CONSTRAINT ... IS_EMPTY ( LS WHERE CITY
≠
'London' ) ;
CONSTRAINT ...
IS_EMPTY ( NLS WHERE CITY = 'London'
) ;
CONSTRAINT ... DISJOINT { LS { SNO } , NLS { SNO } } ;
Note that these constraints refer to relvars LS and NLS only (this user doesn't even know
relvar S exists).
3.
Is
not
aware of any compensatory actions (because all of the compensatory actions in this
example include some reference to relvar S).
