Databases Reference
In-Depth Information
when all three relvars are base ones (again, see the section “The Motivating Example
Continued”). Such a user will be allowed to delete tuples, and/or to update attributes other
than attribute SNO, within relvar NLS, but that's all. Once again, there's no magic.
Note:
In connection with this last point, it might be thought that the fact that a user who
sees only view NLS is limited in the operations he or she is allowed to perform on that relvar
constitutes a violation of
The Principle of Interchangeability—
but of course it doesn't; as we've
seen, the very same limitations apply in the case where NLS is a base relvar.
OVERLAPPING RESTRICTIONS
Let's take a look at a slightly more complicated restriction example. Suppose we define two
restriction views of the suppliers relvar S, NLS (“non London suppliers”) and NPS (“non Paris
suppliers”). Both of these views have key {SNO}. Sample values are shown in Fig. 4.2. Here
are the predicates for the views:
NLS:
Supplier SNO is under contract, is named SNAME, has status STATUS, and is
located in city CITY (and CITY isn't London).
NPS:
Supplier SNO is under contract, is named SNAME, has status STATUS, and is
located in city CITY (and CITY isn't Paris).
S NLS
┌─────┬───────┬────────┬────────┐ ┌─────┬───────┬────────┬────────┐
│ SNO │ SNAME │ STATUS │ CITY │ │ SNO │ SNAME │ STATUS │ CITY │
├═════┼───────┼────────┼────────┤ ├═════┼───────┼────────┼────────┤
│ S1 │ Smith │ 20 │ London │ │ S2 │ Jones │ 10 │ Paris │
│ S2 │ Jones │ 10 │ Paris │ │ S3 │ Blake │ 30 │ Paris │
│ S3 │ Blake │ 30 │ Paris │ │ S5 │ Adams │ 30 │ Athens │
│ S4 │ Clark │ 20 │ London │ └─────┴───────┴────────┴────────┘
│ S5 │ Adams │ 30 │ Athens │ NPS
└─────┴───────┴────────┴────────┘ ┌─────┬───────┬────────┬────────┐
│ SNO │ SNAME │ STATUS │ CITY │
├═════┼───────┼────────┼────────┤
│ S1 │ Smith │ 20 │ London │
│ S4 │ Clark │ 20 │ London │
│ S5 │ Adams │ 30 │ Athens │
└─────┴───────┴────────┴────────┘
Fig. 4.2: Relvars S, NLS, and NPS—sample values
