Define as precisely as you can the terms attribute, body, cardinality, degree, heading, relation, relvar, and tuple. Also, every relation and every relvar is of some (relation) type; define the term relation type as precisely as you can too.
What's a literal?
State as precisely as you can what it means for two tuples to be equal.
We saw in the section "What's a Tuple?" that it's strictly incorrect to say that, for example, S1 or even 'S1' is a supplier number ("a value of type SNO is a value of type SNO, not a value of type CHAR"). As a consequence, Figure 1-3 in Chapter 1 is pretty sloppy, inasmuch as it pretends that it is correct to think of, for example, S1 as a supplier number. Show the correct way of referring to the various scalar values in that figure, given the types specified for attributes in the suppliers-and-parts database in the introductory section in Chapter 2.
Write Tutorial D tuple selector invocations for a typical tuple from (a) the parts relvar, (b) the shipments relvar. Also show SQL's counterparts, if any, to those selector invocations.
Write a typical Tutorial D relation selector invocation. Also show SQL's counterpart, if any, to that selector invocation.
Does the concept of a tuple literal make any sense? What about a relation literal?
(This is essentially a repeat of Exercise 1-8 from Chapter 1, but you should be able to give a more comprehensive answer now.) There are many differences between a relation and a table. List as many as you can.
The attributes of a tuple can be of any type whatsoever (well, almost; can you think of any exceptions?). Give an example of (a) a tuple with a tuple-valued attribute, (b) a tuple with a relation-valued attribute (RVA).
Tuple equality was defined precisely in the body of the chapter but what about relation equality? (I'll discuss the question of relation comparisons in general in Chapter 5, but you might like to take a shot at defining relation equality for yourself here.)
Why don't the comparison operators "<" and ">" apply to tuples? Note that, by contrast, they do apply to SQL rows. How can this be? (Hint: What's the difference between SQL's rules for row equality and the relational rules for tuple equality?)
Give an example of a relation with (a) one RVA, (b) two RVAs. Also give two more relations that represent the same information as those relations but do not involve RVAs. Then give an example of a relation with an RVA such that there's no relation without an RVA that represents precisely the same information. (You might prefer to come back to this exercise after reading more about RVAs in Chapter 5.)
It's sometimes suggested that a relation (or relvar, rather) is really just a traditional computer file, with tuples instead of records and attributes instead of fields. Discuss.
Explain the relations TABLE_DUM and TABLE_DEE in your own words. Does SQL support them?
The following is a legitimate example of an SQL row value constructor:
ROW ( 1, NULL )
Is the row it represents null or not?
"Duplicates are a good idea in databases because duplicates occur naturally in the real world. For example, all pennies are duplicates of one another." How would you respond to this argument?
Why are the databases of Figures 3-1 and 3-2 nonrelational?
Do you think nulls occur naturally in the real world?
Nulls were originally proposed as a solution to the problem of missing information. Now, it's true that information is often missing in the real world (think of such things as "Speaker to be announced" or "Present address unknown," for example). Therefore, if nulls are prohibited, how should we deal with missing information inside our database systems? (As I'm sure you noticed, I didn't answer this question in the body of the chapter. This exercise might best serve as a basis for group discussion. I'll have a little more to say on the subject in Chapter 7.)
TABLE_DEE means TRUE and TABLE_DUM means FALSE. Do these facts mean we could dispense with the usual BOOLEAN data type? Also, DEE and DUM are relations, not relvars. Do you think it would ever make sense to define a relvar of degree zero?
We saw in the body of the chapter that this SQL expression:
VALUES ( 1, 2 ), ( 2, 1 ), ( 1, 1 ), ( 1, 2 )
denotes a table with four rows. What does the following SQL expression denote?
VALUES ( ( 1, 2 ), ( 2, 1 ), ( 1, 1 ), ( 1, 2 ) )