View Updating and Relational Theory

Chapter 10. Union Views

Listen to me—go spread the news—

It’s easy to update union views!

— Anon.:

Now let’s move on to union. You won’t be surprised to learn that the structure of this chapter is very similar to that of the previous one, on intersection. Just one preliminary remark: A UNION B resembles A INTERSECT B in that it’s not very interesting if A = B; unlike A INTERSECT B, however, it certainly is interesting—well, somewhat interesting—if A and B are disjoint. So my first example will be exactly that, an example involving a disjoint union.

Example 1: Disjoint Union

This example is essentially the inverse of the motivating example from Chapters Chapter 1 and Chapter 4. Thus, we’re given two relvars, LS (“London suppliers”) and NLS (“non London suppliers”), that look like this:

LS  { SNO , SNAME , STATUS , CITY } KEY { SNO }
NLS { SNO , SNAME , STATUS , CITY } KEY { SNO }

Of course, in terms of our usual suppliers-and-parts database, these relvars are probably views—views of relvar S, to be specific—but you can think of them as base relvars if you like. More to the point, observe that these relvars are indeed disjoint, inasmuch as it’s impossible for the very same tuple to appear in both. Here are the 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).

Now let’s define the (disjoint) ...