So What s a Type?


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:

[*] Finite because we're dealing with computers, which are finite by definition. Also, note that qualifier named; types with different names are different types.

  • Every value is of some type in fact, of exactly one type, except possibly if type inheritance is supported, a concept that's beyond the scope of this book. Note, therefore, that types are disjoint or nonoverlapping. (To elaborate briefly: as one reviewer said, surely types WarmBloodedAnimal and FourLeggedAnimal overlap? Indeed they do; but what I'm saying is that if types overlap, then for a variety of reasons we're getting into the realm of type inheritance in fact, into multiple inheritance. Since those reasons, and indeed the whole topic of inheritance, are independent of the context we're in, be it relational or something else, I'm not going to discuss them in this book.)

  • Every variable, every attribute, every operator that returns a result, and every parameter of every operator is declared to be of some type. And to say that (for example) variable V is declared to be of type T means, precisely, that every value v that can legally be assigned to V is itself of type T.

  • Every expression denotes some value and is therefore of some type: namely, the type of the value in question, which is to say the type of the value returned by the outermost operator in the expression (where by "outermost" I mean the operator that's executed last). For example, the type of the expression (A+B)*(X-Y) is the declared type of the operator "*", whatever that happens to be.

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:

  • The system provides an assignment operator ":=" for assigning integer values to integer variables.

  • It also provides comparison operators "=", "<", and so on, for comparing integer values.

  • It also provides arithmetic operators "+", "*", and so on, for performing arithmetic on integer values.

  • It does not provide string operators "||" (concatenate), SUBSTR (substring), and so on, for performing string operations on integer values; in other words, string operations on integer values are not supported.

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:

  1. Specifying a name for that type (obviously enough).

  2. Specifying the values that make up that type. I'll discuss this aspect in more detail in Chapter 6.

  3. Specifying the hidden physical representation for values of that type. As noted earlier, this is an implementation issue, not a model issue, and I won't discuss it further in this book.

  4. Specifying the operators that apply to values and variables of that type (see below).

  5. For those operators that return a result, specifying the type of that result (again, see below).

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):

[*] I could have used SQL, but operator definitions in SQL involve a number of details that I don't want to get into here.

     1 OPERATOR REFLECT ( P POINT ) RETURNS POINT ;     2    RETURN ( POINT ( - THE_X ( P ) , - THE_Y ( P ) ) ) ;     3 END OPERATOR ;

Explanation:

  • Line 1 shows that the operator is called REFLECT, takes a single parameter P of type POINT, and returns a result also of type POINT (so the declared type of the operator is POINT).

  • Line 2 is the operator implementation code. It consists of a single RETURN statement. The value to be returned is, of course, a point, and it's obtained by invoking the POINT selector operator; that invocation has two arguments, corresponding to the X and Y coordinates of the point in question. Each of those arguments involves a THE_ operator invocation; those invocations yield the X and Y coordinates of the point argument corresponding to parameter P, and negating those coordinates leads us to the desired result.

  • Line 3 marks the end of the definition.

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.



Database in Depth
Database in Depth: Relational Theory for Practitioners
ISBN: 0596100124
EAN: 2147483647
Year: 2006
Pages: 127
Authors: C.J. Date

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net