Database in Depth

Chapter Five. Relational Algebra

I'll begin this chapter by briefly reviewing a few important points from Chapter 1 . First, I remind you that each algebraic operator takes at least one relation as input and produces another relation as output. Second, I remind you that the fact that the output is the same kind of thing as the input—they're all relations—is the closure property of the algebra, and it's that property that lets us write nested relational expressions. Third, I gave outline descriptions in Chapter 1 of what I called "the original eight operators" (restrict, project, product, intersect, union, difference, join, and divide); now I want to define those operators, as well as a number of others, much more carefully. Before I can do so, however, I need to make a few general points:

• First, the operators are generic: they apply, in effect, to all possible relations. For example, we don't need one specific join operator to join employees and departments and another, different, join operator to join suppliers and shipments. (Incidentally, do you think an analogous observation applies to object-oriented systems?)

• Second, the operators are read-only: they "read" their operands and return a result, but they don't update anything. In other words, they operate on relations, not relvars.

• Of course, the previous point doesn't mean that relational expressions can't refer to relvars. For example, R UNION S, where R and S are relvar names, is certainly a valid relational expression in