Beginning HTML with CSS and XHTML incorporates practical examples that will show you how to structure your data correctly using (X)HTML, together with styling and layout basics using CSS. It also shows how to add dynamic behavior to your data using the JavaScript. language. All of the featured code and techniques are standards compliant and demonstrate best practices.so you will not waste time on any outdated techniques.

Errata Submission

If you think that you've found an error in Applied Mathematics for Database Professionals, please let us know about it. You will find any confirmed erratum below, so you can check if your concern has already been addressed.

Errata

Issue	Author's Response
Chapter 7, page 173, Listing 7-40, the comment for PSSR1 - /* Employee works for a known department */ - needs to be in bold typeface.	Noted. Thanks again.
simple typo, chapter 3, pg. 58, last paragraph of section titled "Negation Of Quantifiers", first sentence reads "...Table 1-12." should read "...Table 1-13.".	Thanks for spotting this one.
Chapter 11, page 298 The sentence "STC5's DI code could therefore approve this change because TX6 has already committed at t=4..." does not take into account that the scn is not set (because as table 11-5 shows, TX5 does not perform an update on EMP, thus the pre-statement trigger calling dbms_flashback.get_system_change_number never fires). Thus trigger HIST_AIS_STC5 would fail with a "ORA-06503: PL/SQL: Function returned without value" (refering to f_get_tx_start_scn) and transaction TX5 would rollback. Of course, there are still scenarios under which TX5 will complete even when it should not. For example, if TX5 issues an update on EMP (thus causing an insert on HIST due to the trigger on EMP) and then issues another insert on HIST (maybe because the developer is not aware of the existence of the trigger on EMP). This scenario could be prevented for example by using a sequence (whose value would be incremented by the trigger on EMP and would populate a package variable or session table) and trigger HIST_AIS_STC5 would validate that the particular sequence number value does not exist already in the hist table (requires an additional column in the hist table). There are probably more efficient/elegant solutions then using sequences, but I just wanted to provide an example.	"does not take into account that the scn is not set" You are right. When writing this, I was assuming the scn would have been saved (inside TX5) at t=0, because DML1 involves a table, say T1, of some other transition constraint that references the old snapshot of T1. I should have mentioned this of course. "thus causing an insert on HIST due to the trigger on EMP" ? This puzzles me. Not sure if I understand. Nowhere have I introduced such ("the") trigger: that is, a trigger that performs an insert on HIST. I only have a trigger that executes DL code for STC5. In fact, I am strongly against programming such trigger. The second note on page 254 is all about that: triggers should not hold BL code.
Chapter 11, page 263 Contraint emp_chk_dsal defines the minimum salary for the president to be 10001. However, based on minimum salary requirement defined in tuple universe definition tup_emp the minimum salary should be 120001.	tup_emp defines minimum salary requirements for Presidents as follows 12 * e(MSAL) > 120000 (using yearly salary amount, as is customary for the "upper" salary scales). Divide both sides by 12... And you get msal > 10000 (monthly) in the check-clause.
Page 173, subset requirement PSSR4. The way this is defined now, implies that the empty database state cannot be in the database universe. On page 223, I refer to exercise 12 of chapter 7, saying that the empty database is a valid value (member of the universe). PSSR4 should allow the empty database state. To fix this we could define it as follows: #{EMP}>0 implies {t(EMPNO)| t in TERM} proper-subset-of {e(EMPNO)| e in EMP}	Correct.
Page 151, the NOTE on the middle of the page. It says: Appendix F. It should read: Appendix D.	Correct
Page 122, inside the example predicate on top of the page a question mark should be deleted: t1(price)?<200 should read t1(price)<200	Correct.
Page 123, inside expression for P10(T). A capital sigma is used to denote summation. This should be replaced by SUM.	Correct
Page 120, Listing 6-3, expression for P6(T). A capital sigma is used to denote summation. However in this book we have not defined it. Instead we defined SUM. Sigma should be replaced by SUM.	Correct.
Page 115, Exercise 4, expression E11. Right after SP an infinity symbol (8 laying down) is printed. This should be replaced by the attribute renaming operator (double diamonds).	Correct
Page 40, first (full) paragraph. We can prove that in case the cartesian product of A times B and B times A are the same, A and B must be equal (and vice versa) IF AND ONLY IF BOTH A AND B ARE NOT THE EMPTY SET. (last capatalized part must be added).	Correct.
The shading in the Figure 2-2 (Chapter 2, pge 32) is very very faint. F.ex. it is not easy to see that only the small rectangle common to both A and B should be gray in the part above the "A (union sign, inverted U) B"	You are right. This is an issue in the second (and still current) print of the book. Copies fromt the first print do not have this problem. Note: the first print was produced by an official book-printer. After that batch was sold out all new copies of the book are printed "on-demand". It seems that this involves other printers that introduce the faintness issue you describe on page 32.
Chapter 4, page 71, Definition 4-2: Function The second conjunct in the proposition implies that if pairs p1 and p2 are not equal, then the the first coordinate of p1 is not equal to the second coordinate of the second pair. I believe the first coordinate of the second pair was intended, not the first. That is pi_1(p1) != pi_2(p2) should be pi_1(p1) != pi_1(p2). Both coordinate selectors should be pi_1 to select the first coordinate of both pairs. Is there an errata for this book that I could access?	You are right: both selectors should be pi1.
Appendix E. Page 363. Solution for Chapt 9 exercise 10. Very first line at the top of page 363 includes a condition that excludes SALESREPs. I think this is wrong because in this second existential quantifier we are evaluating the case for Sales Reps so by excluding them the join to SREP table has been cancelled out.	Yes, you are right: the condition should be deleted.
Chapter 11, p.292, The foreign key constraint declaration for PSSR2, after "You can declare a foreign key from DEPT to EMP as follows:" is not the correct one (it is a copy of the one listed previously on the same page).	Indeed. It should read: alter table dept add constraint dept_fk_emp foreign key(mgr) references emp(empno);
Chapter 10, p. 228-229, There is a right parantesis too many in subquery expression SEI in Listing 10-3.	Yes there is.
Chapter 9, p. 216, Listing 9-11, FEa last line: "e2(DEPTNO)=d " should be "e2(DEPTNO)=d(DEPTNO) "	Yes, it should.
Chapter 9, p. 203: The formal expression FEa is not logically equivalent with the formal expressions FEb and FEc in Listing 9-4. FEa is "employees who manage exactly two departments at two different locations" where as FEb and FEc are "employees who manage AT LEAST two departments at two different locations". To see this "in action" compare output of statements SEI,...,SEIV on the example database after doing "INSERT INTO dept(deptno,dname,loc,mgr) VALUES(16,'IT','COPENHAGEN',1001);".	Your insert will fail due to a table constraint in DEPT that says "One can manage at most two departments". Employee 1001 already manages departments 10 and 15... I admit though that it might be good to remind the reader of this particular DEPT table constraint.
Chapter 4, page 71, Definition 4-2: Function “F is a function over set A into set ... "pi1(p1) is not equal to pi2(p2)" Should read "pi1(p1) is not equal to pi1(p2)" Is that right? Thank you.	Yes, indeed, that is right: the pi2 should be pi1.
Chapter 7: p 164, Listing 7-30: tab_DEPT is defined of the powerset of itself - instead of the powerset of tup_DEPT as illustrated by the other listings on the same page (7-29, 7-31). (Simple typo.) Chapter 7: p 165, Listing 7-31, fourth table constraint (only one on this page; the other three in list 7-31 are on p164). The condition does not sufficiently capture the desired constraint. Proof by counter-example: Consider 3 grade tuples: { (GRADE;G1), (LLIMIT;3000), (ULIMIT;5000) } { (GRADE;G2), (LLIMIT;1000), (ULIMIT;4000) } { (GRADE;G3), (LLIMIT;2000), (ULIMIT;6000) } All three tuples cover the salary range 3000-4000, yet the triple meets the condition on the table universe. How to demonstrate? Let's allocate the g1, g2, g3 notations used in the constraints to the tuples. * If g1(GRADE) = G1, then there exists (two values of g2) with g2(LLIMIT) < g1(LLIMIT); g3 ranges over G, taking the tuple value identified by each of G1, G2, and G3 in turn. For g3(GRADE) = G1, g3(LLIMIT) = g1(LLIMIT) so the tuple is not counted. For g3(GRADE) = G2, g3(LLIMIT) < g1(LLIMIT) ^ g3(ULIMIT) >= g1(LLIMIT) ^ g3(ULIMIT) < g1(ULIMIT) so the tuple is counted. For g3(GRADE) = G3, g3(LLIMIT) < g1(LLIMIT) ^ g3(ULIMIT) >= g1(LLIMIT) ^ g3(ULIMIT) > g1(ULIMIT), so the tuple is not counted. So, the tuple set satisfies the constraint. * If g1(GRADE) = G2, then there does not exist a g2 with g2(LLIMIT) < g1(LLIMIT) so the condition is satisfied. * If g1(GRADE) = G3, then g2(GRADE) = G1 exists with g2(LLIMIT) < g1(LLIMIT); g3 ranges over G, taking the tuple value identified by each of G1, G2, and G3 in turn. For g3(GRADE) = G1, g3(LLIMIT) > g1(LLIMIT) so the tuple is not counted. For g3(GRADE) = G2, g3(LLIMIT) < g1(LLIMIT) ^ g3(ULIMIT) >= g1(LLIMIT) ^ g3(LLIMIT) < g1(ULIMIT) so the tuple is counted. For g3(GRADE) = G3, g3(LLIMIT) = g1(LLIMIT) so the tuple is not counted. So, the tuple set satisfies the constraint. QED? (Should there be a g3 != g1 in the condition? No, it isn't needed because of the use of '<' rather than '<=' in the criteria. OTOH, it might be clearer).	- Confirm on the symple typo. - A way to fix the fourth constraint such that it captures the desired meaning might be to add another constraint: one that prevents a salary-grade to be fully "enclosed" within another salary-grade. G1 is fully enclosed by G3 in your counter-example. This is a scenario that we do not (want to) allow in the GRADE table universe. We could fix this by adding a fifth constraint: forall g1, g2 in G: g1(LLIMIT)<g2(LLIMIT) implies g1(ULIMIT)<g2(ULIMIT)