An Introduction to Database Systems 8Ed - C J Date - Solutions Manual Episode 1 Part 4 pptx

Copyright (c) 2003 C. J. Date page 5.1

Chapter 5

T y p e s

Principal Sections

• Values vs. variables

• Types vs. representations

• Type definition

• Operators

• Type generators

• SQL facilities

General Remarks

This chapter is new in this edition (it's a greatly expanded and

completely rewritten version of portions of Chapter 5 from the

seventh edition). It opens with this remark:

Note: You might want to give this chapter a "once over

lightly" reading on a first pass. The chapter does logically

belong here, but large parts of the material aren't really

needed very much prior to Chapter 20 in Part V and Chapters

25-27 in Part VI.

From a teaching point of view, therefore, you might want to just

take types as a given for now and go straight on to Chapter 6. If

you do, however, you'll need to come back to this material before

covering any of Chapters 20 and 25-27, and you'll need to be

prepared for occasional questions prior to that point on the

topics you've temporarily skipped.

As noted in the introduction in this manual to this part of

the book, it's this part above all others that I believe

distinguishes this book from the competition. With respect to

this chapter specifically, one feature that sets the book apart

from others (including previous editions of this book) is its

emphasis on domains as types. The chapter goes into considerable

detail on what's involved in defining──and, to some extent,

implementing──such types (associated operators included). The

stated position that a domain and a type are the same thing

permeates the entire book from this point forward; in fact, I

prefer the term type, and use domain mostly just in contexts where

history demands it.

Copyright (c) 2003 C. J. Date page 5.2

So we're talking about type theory. Type theory is really a

programming language topic; however, it's highly relevant to

database theory, too (in fact, it provides a basis on which to

build such a theory). It might be characterized as the point

where "databases meet programming languages." It seems to me that

the database community ignored this stuff for far too long, to

their cost (to ours too, as users). I could certainly quote some

nonsense from the database literature in this connection. For

example:

(Begin quote)

Even bizarre requests can easily be stated; for example,

SELECT c.customer_name

FROM Customer_Table c, Zoo_animal_Table z

WHERE c.no_of_children = z.no_of_legs

AND c.eye_color = z.eye_color ;

This request joins the Customer_Table and Zoo_animal_Table

relations based on relationships phrased in terms of

no_of_children, no_of_legs, and eye_color. The meaning of these

relationships is not entirely clear.

(End quote)

This quote is taken from a book on object databases; I'll leave it

as an exercise for you to deconstruct it.

By way of a second example, I could simply point to the mess

the SQL standard has made of this whole issue (see Section 5.7 in

this chapter, also the "SQL Facilities" sections in Chapters 6, 9,

19, 20, and 26).

The approach we advocate (to databases overall), then, is

founded on four core concepts: type, value, variable, operator.

These concepts are NOT novel (I like to say "they're not new and

they'll never be old"). Of them, type is the most fundamental ...

To see why, consider type INTEGER (this example is taken from the

annotation to reference [3.3], The Third Manifesto):

• The integer "3" might be a value of that type.

• N might be a variable of that type, whose value at any given

time is some integer value (i.e., some value of that type).

• And "+" might be an operator that applies to integer values

(i.e., to values of that type).