Databases Reference
In-Depth Information
Chapter 10
U n i o n V i e w s
Listen to me—go spread the news—
It's easy to update union views!
—Anon.:
Where Bugs Go
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 1 and 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) union of LS and NLS as a view ULN:
ULN { SNO , SNAME , STATUS , CITY } KEY { SNO }
