Data types (types for short) are fundamental to computer science. Relational theory in particular requires a supporting type theory, because relations are defined over types; that is, every attribute of every relation is defined to be of some type (and the same is true of relvars too, of course). For example, I’m going to assume throughout this book that attribute STATUS of the suppliers relvar S is defined to be of type INTEGER. Under that assumption, every relation that’s a possible value for relvar S must also have a STATUS attribute of type INTEGER—which means in turn that every tuple in such a relation must also have a STATUS attribute that’s of type INTEGER, which means in turn that the tuple in question must have a STATUS value that’s an integer.
I’ll be discussing such matters in more detail later in this chapter. For now, let me just say that—with certain important exceptions, which I’ll also be discussing later—a relational attribute can be of any type whatsoever, implying among other things that such types can be arbitrarily complex. In particular, those types can be either system or user defined. In this book, however, I don’t plan to say much about user defined types as such, because:
The whole point about user defined types (from the point of view of the user who is merely using them, that is, as opposed to the user who actually has the job of defining them) is that they’re supposed to behave just like system defined types anyway.
Comparatively few users will ever be faced with the job of defining a type—and type definition doesn’t really involve any specifically relational considerations in any case.
From this point forward, therefore, you can take the term type to mean a system defined type specifically, unless the context demands otherwise. The relational model prescribes just one such type, BOOLEAN (the most fundamental type of all). Type BOOLEAN contains exactly two values: two truth values, to be specific, denoted by the literals TRUE and FALSE, respectively. Of course, real systems will support a variety of other system defined types as well, and I’ll assume for definiteness that types INTEGER (integers), RATIONAL (rational numbers), and CHARACTER (character strings of arbitrary length) are among those supported. Note: I’ll discuss the system defined types supported by SQL in particular later in the chapter.
Aside: A rational number is a number that can be expressed as the ratio of two integers (e.g., 3/8, 5/12, −4/3); an irrational number is a number that can’t be so expressed (e.g., π, √2). Rational numbers (only) have the property that, in decimal notation, the fractional part of such a number can be expressed as either (a) a finite sequence of digits followed by an infinite sequence of zeros, which can be ignored without loss (e.g., 3/8 = 0.375000...), or (b) a possibly empty finite sequence of digits followed by another finite sequence of digits, the first of which is nonzero, that infinitely repeats (e.g., 5/12 = 0.41666...). By contrast, the fractional part of an irrational number in decimal notation consists of an infinite, nonrepeating sequence of digits (e.g., π = 3.14159..., √2 = 1.41421...). A real number is a number that’s either rational or irrational. Now, many programming languages support a numeric type they call REAL; computers being finite, however, the only real numbers computers are actually capable of representing are necessarily rational ones. Hence Tutorial D’s choice of the keyword RATIONAL. End of aside.
In the interest of historical accuracy, I should now explain that when Codd first defined the relational model, he said relations were defined over domains, not types. In fact, however, domains and types are exactly the same thing. Now, you can take this claim as a position statement on my part, if you like, but I want to present a series of arguments in support of that position. I’ll start with the relational model as Codd originally defined it; thus, I’ll use the term domain, not type, until further notice. There are two major topics I want to discuss, one in each of the next two sections:
Equality comparisons and “domain check override”: This part of the discussion I hope will convince you that domains really are types.
Data value atomicity and first normal form: And this part I hope will convince you that those types can be arbitrarily complex.