SQL and Relational Theory, 2nd Edition

THE RELIANCE ON ATTRIBUTE NAMES

There’s one question that might have been bothering you but hasn’t been addressed in this chapter so far. The operators of the relational algebra, at least as described in this book, all rely heavily on attribute naming. For example, the Tutorial D expression R1 JOIN R2—where I’ll suppose, just to be definite, that R1 and R2 are base relvars—is defined to do the join on the basis of those attributes of R1 and R2 that have the same names. But the question often arises: Isn’t this approach rather fragile? For example, what happens if we later add a new attribute to relvar R2, say, that has the same name as one already existing in relvar R1?

Well, first let me clarify one point. It’s true that the operators do rely, considerably, on proper attribute naming. However, they also require attributes of the same name to be of the same type (and hence in fact to be the very same attribute, formally speaking); equivalently, they require attributes of different types to have different names. Thus, for example, an error would occur—at compile time, too, I would hope—if, in the expression R1 JOIN R2, R1 and R2 both had an attribute called A but the two A’s were of different types.^[90] Note that this requirement (that attributes of different types have different names) imposes no serious limitation on functionality, thanks to the availability of the attribute RENAME operator.

Now to the substance of the question. In fact, there’s a popular misconception here, and ...