Errata
The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".
The following errata were submitted by our customers and approved as valid errors by the author or editor.
Color key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update
Version | Location | Description | Submitted By | Date submitted | Date corrected |
---|---|---|---|---|---|
Other Digital Version | xvi Kindle location |
"As this latter view is a projection of a restriction, we can infer the effects of updates on it by invoking Date’s rules for updating through projection to determine the effects on the underlying restriction, then invoke the rules for updating though restriction to determine the effects on the underlying base relvar S. |
Kevin Davis | Feb 13, 2013 | |
Other Digital Version | Kindle Locations 1014-1016 Kindle Locations 1014-1016 |
The Lisp hacker in me sensed mismatched brackets: |
Kevin Davis | Feb 14, 2013 | |
Other Digital Version | Kindle Locations 1110-1111 Ch 2, end note 30 |
In a sense, therefore, NOT MATCHIG is actually more fundamental than MINUS is. |
Kevin Davis | Feb 15, 2013 | |
Other Digital Version | Kindle Locations 1178-1179 Ch 3, Section: The View Update Problem |
"Personally I do think views should be supported, for reasons I�ll explain in the section Data Independence on page 34; further, ... Note from the Author or Editor: |
Kevin Davis | Feb 15, 2013 | |
Other Digital Version | Kindle Locations 1232-1233 Ch 3, last paragraph before section: Views Serve a Variety of Purposes |
"It follows that we must solve this problem, for otherwise we have to give up on the goal of data independence. (Logical ... |
Kevin Davis | Feb 15, 2013 | |
Other Digital Version | Kindle Locations 1282-1284 just before How Not to do it in Ch 3 |
Second, (a) the mapping between a view and the relvars in terms of which it�s defined should be specified separately and concealed from the user, just as (b) the mapping between a base relvar and physical storage already is specified separately and concealed from the user. Note from the Author or Editor: |
Kevin Davis | Feb 17, 2013 | |
Other Digital Version | Kindle Locations 1447-1457 Kindle Locations 1447-1457 |
S is equal to the (disjoint) union of LS and NLS:FORALL x ∈ S ( UNIQUE y ∈ LS ( x = y ) OR UNIQUE y ∈ NLS ( x = y ) ) AND FORALL y ∈ LS ( UNIQUE x ∈ S ( x = y ) AND FORALL y ∈ NLS ( UNIQUE x ∈ S ( x = y ) Note from the Author or Editor: |
Kevin Davis | Feb 21, 2013 | |
Other Digital Version | Kindle Locations 4131-4133 Kindle Locations 4131-4133 |
Example 1: Disjoint Union This example is essentially the inverse of the motivating example from Chapters Chapter � 1 and Chapter � 4. Note from the Author or Editor: |
Kevin Davis | Feb 22, 2013 | |
Other Digital Version | Kindle Locations 1868-1869 Kindle Locations 1868-1869 |
One reviewer of an early draft of this book asked why, in the example of relvars S, LS, and NLS, the compensatory actions all had to be cascades. To be specific, he � the reviewer was male � Note from the Author or Editor: |
Kevin Davis | Feb 26, 2013 | |
Other Digital Version | Kindle Locations 1930-1932 Kindle Locations 1930-1932 |
S := ( S WHERE CITY ≠ 'Paris' OR STATUS = 30 ) UNION ( EXTEND S WHERE CITY = 'Paris' AND STATUS ≠ 30 ) : { STATUS := 30 } ) ; Note from the Author or Editor: |
Kevin Davis | Feb 27, 2013 | |
Other Digital Version | Kindle Locations 1801-1806 Kindle Locations 1801-1806 [ Section: More on Compensatory Actions ] |
It will often be the case that the compensatory actions can be stated in a variety of syntactically distinct but semantically equivalent forms. For example, the delete rule from S to LS and NLS — ON DELETE d FROM S : DELETE ( d WHERE CITY = 'London' ) FROM LS , DELETE ( d WHERE CITY ⊆ 'London' ) FROM NLS ; Note from the Author or Editor: |
Kevin Davis | Feb 26, 2013 | |
Other Digital Version | Kindle Locations 1942-1945 Kindle Locations 1942-1945 |
nit ".Note" in: |
Kevin Davis | Feb 27, 2013 | |
Other Digital Version | Kindle Locations 1961-1964 Kindle Locations 1961-1964 |
An attempt is made to insert a new tuple for supplier S2, with CITY value London, into relvar NLS. That attempt fails, however, because it violates the constraint on relvar NLS that the CITY value in that relvar can never be London. So the update fails overall; the previous step (viz., deleting the original tple for supplier S2 from NLS) is undone, and the net effect is that the database remains unchanged. |
Kevin Davis | Feb 27, 2013 | |
Other Digital Version | Kindle Locations 3413-3418 Kindle Locations 3413-3418 |
In the Kindle edition there is a �White Sun With Rays� as the JD symbol between the SCP: and the line starting with {{SNO.: Note from the Author or Editor: |
Kevin Davis | Mar 07, 2013 | |
Other Digital Version | Kindle Locations 3612-3613 Kindle Locations 3612-3613 [ Ch 8 Ex 1, turning to updates ... ] |
2. Suppose we delete all tuples for supplier S1 from relvar SP. The effect will be to delete all tuples for supplier S1 from relvar SSP and also to delete the tuple (S1,20) from relvar S. |
Kevin Davis | Mar 08, 2013 | |
Other Digital Version | Kindle Locations 3617-3619 Kindle Locations 3617-3619 |
6. Suppose we delete the tuple (S1,20) from relvar S. The effect will be to delete all tuples for supplier S1 from relvar SSP. Of course, the rule governing deletes on SSP will now come into play, which will (not unreasonably) have the effect of deleting all tuples for supplier S1 from relvar SP as well. |
Kevin Davis | Mar 08, 2013 | |
Other Digital Version | Kindle Locations 3639-3642 Kindle Locations 3639-3642 |
A concrete example of a database value satisfying the foregoing conditions can be obtained by extending Figure � 8-1 to reinstate the usual tuple for supplier S5 (see Figure � 8-2 overleaf, and observe in particular that the relations shown as the current values of relvar SP and SSP in that figure are the same as they were in Figure � 8-1). Note from the Author or Editor: |
Kevin Davis | Mar 08, 2013 | |
Printed | Page 66 3rd block of code (of 4), 3rd line |
Delete closing parenthesis before the colon at the end of the line. |
![]() C.J. Date |
Feb 27, 2013 | |
Printed | Page 138 Paragraph beginning "Explanation:" |
In line 2 of the paragraph, replace "that SP tuple" by "that SP tuple (except that the SNO attribute is projected away)". |
![]() C.J. Date |
Sep 29, 2013 | |
Printed | Page 236 Final para., line 2 |
Delete closing parenthesis following the word “type”. |
![]() C.J. Date |
Feb 13, 2013 | |
Other Digital Version | 729 Kindle location |
"For reasons of simplicity and familiarity, however, I’ll stay with the conventional DELETE and INSERT operators throughout the remainder of this book, and I’ll assume throughout the texty Note from the Author or Editor: |
Kevin Davis | Feb 13, 2013 |