The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
| Version |
Location |
Description |
Submitted By |
| Printed |
Page 45
definition of tuple equality |
in the definition of tuple equality, shouldnt the last line read "the value vi of Ai in t1 is equal to the value vi of Ai in t2"?
|
Anonymous |
| Printed |
Page 46
definition of realation |
in the definition of relation, shouldnt the word "degree" in line 4 be italicized (to match cardinality)?
|
Anonymous |
| Printed |
Page 56
TABLE_DUM and TABLE_DEE |
By p. 56 the author has already established that TABLES ARE NOT PART OF
THE RELATIONAL MODEL. The entities which this section discusses ought not have the
string 'table' in their names. I suggest rel_dum and rel_dee for these two special
relation values. They are hardly 'tables'
in the common technical usage of the word, table, but the reasoning that
identifies them as legitimate relation values is compelling.
|
Anonymous |
| Printed |
Page 76
line 5 |
There is an error in your errata:
|
Anonymous |
| Printed |
Page 76
line 5 |
Replace:
"projection well"
with
"projection ... well"
The relevant text from line 5 is "... relational projection as well, ...".
|
Anonymous |
| Printed |
Page 91
bottom of page |
On p. 91 of Date's book (the last four sentences on the page), he says
"the semidifference between r and s is the difference between r and r MATCHING s; that is, r SEMIMINUS s is equivalent to r MINUS (r MATCHING s)."
He then shows the SQL equivalent of S SEMIMINUS SP as
SELECT S.*
FROM S
EXCEPT
SELECT S.*
FROM S,SP
WHERE S.SNO=SP.PNO;
But on page 89 (at the top) he shows S SEMIJOIN SP to be equivalent to this SQL
SELECT DISTINCT S.*
FROM S,SP
WHERE S.SNO=SP.PNO;
The DISTINCT keyword is need here; otherwise, the result is not be a valid relation. Without it there would be duplicate tuples. So why did Date omit DISTINCT from the SQL equivalent of S SEMIMINUS SP, at the bottom of p. 91? Shouldn't the correct SQL analogue of S SEMIMUS SP be
SELECT S.*
FROM S
EXCEPT
SELECT DISTINCT S.*
FROM S,SP
WHERE S.SNO=SP.PNO;
even though the result is the same without DISTINCT?
regards,
Kurt Krueckeberg
|
kurt krueckeberg |
| Printed |
Page 95
bottom of page |
The SQL code given at the bottom of page 95 is:
SELECT P.*, (P.WEIGHT * 454) AS GMWT
FROM O
WHERE (P.WEIGHT*454) > 7000;
Should this not be:
SELECT P.PNO, (P.WEIGHT * 454) AS GMWT
FROM O
WHERE (P.WEIGHT*454) > 7000;
Since the code at the bottom of p. 95 shows how to "Get part number and gram weight for parts with gram weight greater than 7000 grams". The Tutorial D code does properly show a Projection that returns just the two values of part number and gram weight. However, returns all the columns of P, plus the gram weight.
|
kurt krueckeberg |
| Printed |
Page 102
4rd |
First, project distributes over intersect and union, though not difference.
MUST BE:
First, project distributes over union, though not intersect and difference.
|
Anonymous |
| Printed |
Page 146
Last sentence of paragraph four. |
On p.146 of Database in Depth, the last sentence of the 4th reads: "The only nontrivial join dependency satisfied by this relvar is the fuctional dependency*:
{ SNO, PNO, JNO } -> { QTY }
which is an arrow out of a superkey."
This should read: "The only nontrivial functional dependency satisfied by this relvar is the fuctional dependency:
{ SNO, PNO, JNO } -> { QTY }"
which is an "arrow out of a superkey."
-----------
It should read this way because the functional dependency of { SNO, PNO, JNO } -> { QTY } implies that the only JD is the trivial JD consisting of all the attributes of the reval: * { {SNO, PNO, JNO, QTY } }.
The asterick at the bottom of page 146 makes this point. It reads: "Equivalently, using the name SPJQ to refer to the set of all attributes of SPJ, the revlar satisfies the trivial JD * {SPJQ}.(Recall from chapter 5 that the join of a single relations r is just r itself.)"
|
Kurt Krueckeberg |
