The first point I want to discuss is this: Every subset of a body is a body—or, loosely, every subset of a relation is a relation. (Once again I mentioned this fact in Chapter 1, but now I want to say a little more about it.) In particular, since the empty set is a subset of every set, a relation can have a body that consists of an empty set of tuples (and we call such a relation an empty relation). For example, suppose there are no shipments right now. Then relvar SP will have as its current value the empty shipments relation, which we might draw like this (and now I revert to the convention by which we omit the type names from a heading in informal contexts; throughout the rest of the book, in fact, I’ll feel free to regard headings as either including or excluding type names—whichever best suits my purpose at the time):

Note that, given any particular relation type, there’s exactly one empty relation of that type—but empty relations of different types aren’t the same thing, precisely because they’re of different types. For example, the empty suppliers relation isn’t equal to the empty parts relation (their bodies are equal but their headings aren’t).

Consider now the relation depicted here:

This relation contains just one tuple (equivalently, it’s of cardinality one). If we want to access the single tuple it contains, then we’ll have to extract it somehow from its containing relation. Tutorial D uses syntax of the form TUPLE FROM rx for this purpose, where rx is any expression that denotes a relation of cardinality one—for example, it might be the expression RELATION {TUPLE {SNO ‘S1’, PNO ‘P1’, QTY 300}}, which is in fact a relation selector invocation (actually it’s a literal). SQL, by contrast, uses coercion: If (a) tx is a table expression that’s being used as a row subquery (meaning it appears where a row expression is expected), then (b) the table t denoted by tx is supposed to contain just one row r, and (c) that table t is coerced to that row r. Here’s an example (it’s the row assignment example from the section ROW AND TABLE TYPES IN SQL in Chapter 2):

     SET SRV = ( S WHERE SNO = 'S1' ) ;

We also need to be able to test whether a given tuple t appears in a given relation r. In Tutorial D:

     t ∈ r

This expression returns TRUE if t appears in r and FALSE otherwise. The symbol “∈” denotes the set membership operator; the expression t ∈ r can be read as “t [is] in r” or “t appears in r.” In fact, as you’ve probably realized, “∈” is essentially SQL’s IN—except that the left operand of SQL’s IN is usually a scalar, not a row, which means there’s some coercion going on once again (i.e., the scalar is coerced to the row that contains it).^[43] Here’s an example (“Get suppliers who supply at least one part”):

     SELECT SNO , SNAME , STATUS , CITY
     FROM   S
     WHERE  SNO IN        /* "SNO" coerced to "ROW(SNO)" */
          ( SELECT SNO
            FROM   SP )

Note: As I’m sure you know, SQL also supports NOT IN. The Tutorial D analog is “∉”; in other words, the Tutorial D expression “t ∉ r” means tuple t isn’t in relation r.