Scalar Versus Nonscalar Types

It's usual to think of types as being either scalar or nonscalar. Loosely, a type is scalar if it has no user-visible components and nonscalar otherwise and the values, variables, attributes, operators, parameters, and expressions of some type T are scalar or nonscalar according as type T itself is scalar or nonscalar. For example:

• Type INTEGER is a scalar type; hence, values, variables, and so on of type INTEGER are also all scalar, meaning they have no user-visible components.

• Tuple and relation types are nonscalar the pertinent user-visible components being, of course, the corresponding attributes and hence tuple and relation values, variables, and so on are also all nonscalar.

That said, I must now stress the point that these notions are quite informal. Indeed, we've already seen that the concept of atomicity has no absolute meaning, and "scalarness" is just the concept of atomicity by another name. Thus, the relational model nowhere formally relies on the scalar versus nonscalar distinction. In this book, however, I do rely on it informally; to be specific, I use the term scalar in connection with types that are neither tuple nor relation types, and the term nonscalar in connection with types that are either tuple or relation types.

Let's look at an example. Here's a Tutorial D definition for the base relvar S (suppliers):

     1 VAR S BASE     2     RELATION { SNO SNO, SNAME NAME, STATUS INTEGER, CITY CHAR }     3     KEY { SNO } ;

Explanation:

• The keyword VAR in line 1 means this is a variable definition; the keyword BASE means the variable is a base relvar specifically.

• Line 2 specifies the type of this variable. The keyword RELATION shows it's a relation type; the rest of the line specifies the set of attributes that make up the corresponding heading (where, as you'll recall from Chapter 1, an attribute is an attribute-name:type-name pair). The type is, of course, a nonscalar type. No significance attaches to the order in which the attributes are specified.

• Line 3 defines {SNO} to be a candidate key for this relvar.

In fact, the example also illustrates another point namely, that the type:

     RELATION { SNO SNO, SNAME NAME, STATUS INTEGER, CITY CHAR }

is an example of a generated type. In general, a generated type is one that's obtained by invoking some type generator (in the example, the type generator is RELATION). You can think of a type generator as a special kind of operator; it's special because (a) it returns a type instead of (for example) a scalar value, and (b) it's invoked at compile time instead of run time. For instance, most programming languages support a type generator called ARRAY, which lets users define a variety of specific array types. For the purposes of this book, however, the only type generators we need to consider are TUPLE and, of course, RELATION. Here's an example involving the TUPLE type generator:

     VAR SINGLE_SUPPLIER         TUPLE { STATUS INTEGER, SNO SNO, CITY CHAR, SNAME NAME } ;

The value of variable SINGLE_SUPPLIER at any given time is a tuple with the same heading as that of relvar S. (I've specified the attributes in a different sequence deliberately, just to show that the sequence doesn't matter.) Thus, we might imagine a code fragment that, first, extracts a one-tuple relation (perhaps the relation containing just the tuple for supplier S1) from the current value of relvar S; then extracts the single tuple from that one-tuple relation; and, finally, assigns that tuple to the variable SINGLE_SUPPLIER. In Tutorial D:

     SINGLE_SUPPLIER := TUPLE FROM ( S WHERE SNO = SNO('S1') ) ;

By the way, note carefully that a tuple t and a relation r that contains just that tuple t aren't the same thing. In particular, they're of different types t is of some tuple type and r is of some relation type (though of course they do have the same heading).

NOTE

I don't want you to misunderstand me here. While a variable like SINGLE_SUPPLIER might well be needed in some application program that accesses the suppliers-and-parts database, I'm not saying that such a variable can appear inside the database itself. A relational database contains variables of exactly one kind namely, relation variables (relvars); that is, relvars are the only kind of variable allowed in a relational database. I'll revisit this point in Chapter 8, in connection with what's called The Information Principle.

There's just one more thing I want to say about tuple and relation types: even though such types do obviously have user-visible components (namely, their attributes), there's no suggestion that those components have to be physically stored as such. In fact, the physical representation of values of such types should be hidden from the user, just as it is for scalar types.