Databases Reference
In-Depth Information
operations involved in the view defining expression. In fact, we already know this, because we
know from Chapter 2 that every relational expression has a corresponding predicate, and of
course a view has exactly the predicate that corresponds to its defining expression. For example,
consider view LS (“London suppliers”) once again. That view is a restriction of relvar S, and its
predicate is therefore the logical AND of the predicate for S and the specified restriction
condition:
Supplier SNO is under contract, is named SNAME, has status STATUS, and is located in
city CITY
AND
city CITY is London.
Or more colloquially:
Supplier SNO is under contract, is named SNAME, has status STATUS, and is located in
CITY London.
Note, however, that this latter form obscures the fact that CITY is a parameter. Indeed it is a
parameter, but the corresponding argument is always the constant London. (As noted in Chapter
1, a more realistic version of view LS would probably project away the CITY attribute, precisely
because of this fact. I choose not to do so here in order to keep the example simple. However,
I'll have more to say about this possibility in Chapter 5.)
Aside:
If you prefer the somewhat more formal style for predicates described in Chapter 2,
you might alternatively say the predicate for view LS looks something like this:
is_entity ( SNO ) AND
has_SNAME ( SNO , SNAME ) AND
has_STATUS ( SNO , STATUS ) AND
has_CITY ( SNO , CITY ) AND
CITY = 'London'
End of aside
.
