VIEWS AND PREDICATES

The Principle of Interchangeability implies that a view (just like a base relvar) has a relvar predicate, in which the parameters correspond one to one to the attributes of the relvar—i.e., the view—in question. However, the predicate that applies to a view V is a derived predicate: It’s derived from the predicates for the relvars in terms of which V is defined, in accordance with the semantics of the relational operations involved in the view defining expression. In fact, you already know this: In Chapter 6, I explained 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, as defined near the beginning of the section VIEWS ARE RELVARS. That view is a restriction of relvar S, and its predicate is therefore the logical AND of the predicate for S and the 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 London.

Note, however, that this more colloquial form obscures the fact that CITY is a parameter. Indeed it is a parameter, but the corresponding argument is always the constant ‘London’. (Precisely for this reason, in fact, a more realistic version of view LS would probably project away the CITY attribute. I prefer not to do this here, in order to keep the example as simple as possible.)

Similarly, the predicate for view NLS is:

Supplier SNO is under contract, is named SNAME, has status STATUS, and is located in city CITY, which isn’t London.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.189.250