## Exercise 2-1What's a type? What's the difference between a domain and a type? ## Exercise 2-2What do you understand by the term selector? ## Exercise 2-3What's a THE_ operator? ## Exercise 2-4Physical representations are always hidden from the user: true or false? ## Exercise 2-5Elaborate on the following: argument versus parameter; database versus DBMS; generated type versus nongenerated type; scalar versus nonscalar; type versus representation; user-defined type versus system-defined type; user-defined operator versus system-defined operator. ## Exercise 2-6What do you understand by the term coercion? Why is coercion a bad idea? ## Exercise 2-7Why doesn't "domain check override" make sense? ## Exercise 2-8What's a type generator? ## Exercise 2-9Define first normal form. ## Exercise 2-10Let X be an expression. What's the type of X? What's the significance of the fact that X is of some type? ## Exercise 2-11Using the definition of the REFLECT operator in the body of the chapter as a pattern, define a Tutorial D operator that, given an integer, returns the cube of that integer. ## Exercise 2-12Use Tutorial D to define an operator that, given a point with cartesian coordinates x and y, returns the point with cartesian coordinates f(x) and g(y), where f and g are predefined operators. ## Exercise 2-13Give an example of a relation type. Distinguish between relation types, relation values, and relation variables. ## Exercise 2-14Use SQL or Tutorial D (or both) to define relvars P and SP from the suppliers-and-parts database. If you give both SQL and Tutorial D definitions, identify as many differences between them as you can. What's the significance of the fact that relvar P (for example) is of a certain relation type? ## Exercise 2-15Given the types specified in the introductory section for attributes in the suppliers-and-parts database, which of the following scalar expressions are valid? For those that are, state the type of the result; for the others, show an expression that will achieve what appears to be the desired effect. a. CITY = 'London' b. SNAME || PNAME c. QTY * 100 d. QTY + 100 e. STATUS + 5 f. 'ABC' < CITY g. COLOR = CITY h. CITY || 'burg' ## Exercise 2-16It's sometimes suggested that types are really variables, in a sense. For example, employee numbers might grow from three digits to four as a business expands, so we might need to update "the set of all possible employee numbers." Discuss. ## Exercise 2-17A type is a set of values, and the empty set is a legitimate set; thus, we might define an empty type to be a type where the set in question is empty. Can you think of any uses for such a type? ## Exercise 2-18In the body of the chapter, I said the equality comparison operator "=" applies to every type (though I didn't spell out the semantics, which are that if v1 and v2 are values of the same type, then v1 = v2 evaluates to TRUE if and only if v1 and v2 are the very same value). As explained in more detail in Chapter 8, however, SQL doesn't require "=" to apply to every type, nor does it prescribe the semantics in all of the cases where it does apply. What are the implications of this state of affairs? ## Exercise 2-19Following on from the previous exercise, we can say that v1 = v2 evaluates to TRUE if and only if executing some operator Op on v1 and executing that same operator Op on v2 always has exactly the same effect, for all possible operators Op. But this is another precept that SQL violates. Can you think of any examples of such violation? What are the implications? ## Exercise 2-20Why are pointers excluded from the relational model? ## Exercise 2-21The Assignment Principle which is very simple, but fundamental states that after assignment of the value v to the variable V, the comparison V = v evaluates to TRUE. Yet again, however, this is a precept that SQL violates (fairly ubiquitously, in fact). Can you think of any examples of such violation? What are the implications? ## Exercise 2-22Do you think that types "belong to" databases, in the same sense that relvars do? ## Exercise 2-23In the section "Domain-Constrained Comparisons," I showed an SQL SELECT - FROM - WHERE expression that contained another such expression nested inside it (a "subquery"). Now, each of the SELECT clauses in the overall expression could have been replaced by the arguably simpler form SELECT* ("SELECT star"). But "SELECT *" suffers from certain problems, which is why I usually not invariably avoid using it in this book. Identify as many of those problems as you can. Can you think of any other constructs in SQL that suffer from similar problems? ## Exercise 2-24In the first example of an SQL SELECT expression in this chapter, I pointed out that there was no terminating semicolon because the SELECT expression was an expression and not a statement. But what's the difference? |

Database in Depth: Relational Theory for Practitioners

ISBN: 0596100124

EAN: 2147483647

EAN: 2147483647

Year: 2006

Pages: 127

Pages: 127

Authors: C.J. Date

Similar book on Amazon

flylib.com © 2008-2017.

If you may any questions please contact us: flylib@qtcs.net

If you may any questions please contact us: flylib@qtcs.net