So What's a Type?From this point forward I'll switch to the term type in preference to domain. What is a type, exactly? In essence, it's a named, finite set of value s[*] all possible values of some specific kind: for example, all possible integers, or all possible character strings, or all possible supplier numbers, or all possible XML documents, or all possible relations with a certain heading (and so on). Moreover:
The fact that parameters in particular are declared to be of some type touches on an issue that I've mentioned but haven't properly discussed yet: namely, the fact that every type has an associated set of operators for operating on values and variables of the type in question. For example, integers have the usual arithmetic operators; dates and times have special calendar arithmetic operators; XML documents have what are called "XPath" operators; relations have the operators of the relational algebra; and every type has the operators of assignment (":=") and equality comparison ("="). Thus, any system that provides proper type support and "proper type support" here certainly includes allowing users to define their own types must provide a way for users to define their own operators, too, because types without operators are useless. It's important to understand also that values and variables of a given type can be operated upon solely by means of the operators defined for that type. For example, in the case of the system-defined type INTEGER:
By contrast, in the case of the user-defined type SNO, we would certainly define assignment and comparison operators (":=", "=", "", possibly ">", and so on); however, we probably wouldnt define operators "+", "*", and so on, which would mean that arithmetic on supplier numbers wouldn't be supported (why would we ever want to add or multiply two supplier numbers?). From everything I've said so far, then, it should be clear that defining a new type involves at least all of the following:
Observe that points 4 and 5 taken together imply that the system knows precisely which expressions are legal, as well as the type of the result for each such legal expression. By way of example, suppose we have a user-defined type POINT, representing geometric points in two-dimensional space. Here then is the Tutorial D definition[*] for an operator called REFLECT which, given a point P with cartesian coordinates (x,y), returns the "reflected" or "inverse" point with cartesian coordinates (-x,-y):
1 OPERATOR REFLECT ( P POINT ) RETURNS POINT ; 2 RETURN ( POINT ( - THE_X ( P ) , - THE_Y ( P ) ) ) ; 3 END OPERATOR ; Explanation:
Now, for the most part, I've been talking so far about user-defined types specifically. For a system-defined or built-in type, similar considerations apply, of course, but in this case the definitions are furnished by the system instead of by some user. For example, if INTEGER is a built-in type, then it's the system that defines the name, specifies legal integers, defines the hidden representation, and defines the corresponding operators. Of course, to someone who merely makes use of some user-defined type that's been defined by somebody else, that type looks just like a system-defined type anyway; indeed, in many ways that's the whole object of the exercise. I don't propose to go into much more detail regarding type and operator definitions, because they aren't specifically relational topics, for the most part. |