Errata to

Information Modeling and Relational Databases, Third Edition

Halpin, T. and Morgan T. 2024

(Morgan Kaufmann)

Last updated: 2026 April 27

If you spot any other errors in this third edition, please e-mail them to Terry Halpin at [email protected].

The following corrections should be made to the first printing. To determine the print version of your copy of the book, look at the row of digits below the copyright notice on the verso of the main title page: the final digit denotes the print version (e.g. 1 = first printing, 2 = second printing).

The symbol "-->" means "is replaced by".

Page 40, question 3, insert the following as the third sentence: "Here, the marital status "single" is used in the sense of "never married".

Pages 113-114, replace the three paragraphs below Fig. 4.3 by:

"  If accepted, this update may be pictured as shown in Figure 4.3. The database is a variable whose population at any state is a distinct list of facts (i.e, a sequence of facts that are distinct from one another). If instead, the database population is a set of facts, if the fact that Adams jogs is already present and this fact is now added again the population remains unaltered because sets are insensitive to repetition. For example, the set {Adams jogs, Adams jogs} is identical to the set {Adams jogs}. Sets are defined simply by their membership, and don't change if we display a member more than once.

   In practice, when a fact is added to a database it is stored in a previously unallocated space. So, accepting this update would cause the fact that Adams jogs to be stored twice, in separate locations. This is an example of redundancy. If redundancy occurs, the database is a list formed from a bag or multiset of facts, where repetition is significant. For example, the bags [1] and [1, 1] are different.

    Avoiding redundancy in a database helps maintain its integrity by simplifying the correct handling of updates. For instance, if the fact that Adams jogs is stored twice in the database and we later delete or change this fact, then we need do this for both its recorded instances. Controlling redundancy can be a headache, and uncontrolled redundancy can lead to inconsistency. A second reason for avoiding redundancy is to save space (computers have finite storage capabilities).

    For conceptual schema design, no redundancy may occur in the conceptual database. Redundancy is the repetition of an elementary or existential fact. Since each row of a conceptual fact table corresponds to one fact, no row of a conceptual fact table may be repeated. So, the fact table in Figure 4.3(b) is illegal, be-cause the Adams row is repeated. Here, for any given state of the database, each person can be recorded as being a jogger at most once. As a result, each entry in the column of the fact table is unique (no duplicates may appear in this column). We may represent this uniqueness constraint explicitly by placing a bar above or below the fact role as shown in Figure 4.4. ".

p. 247, paragraphs 5 and 6, replace by: "The quantifier "Each" normally precedes the name of the subtype being defined, as shown in Figure 6.39. The operator "is defined as a" or "is defined as an" is used after the supertype name. Asserted subtypes use unqualified "is a" connections. For example, asserting that MalePatient is a subtype of Patient, simply means Each MalePatient is a Patient. Derived and semiderived subtypes require subtyping definitions that add conditions to the "is a" connection. For example, Each MalePatient is defined as a Patient who is of Gender 'M'. If desired, but only within a subtype derivation rule, "is defined as a" and "is defined as an" may be shortened to "is a" and "is an".

Page 248, , para. 5, replace by: "In Figure 6.39, the mutual exclusion between MalePatient and FemalePatient is implied by their definitions, together with the uniqueness constraint on the gender predicate (Each Patient is of at most one Gender). The constraint that MalePatient and FemalePatient exhaust Patient is implied by the subtype definitions, the {'M','F'} constraint, and the mandatory role on the gender predicate (Each Patient is of at least one Gender). In ORM, derived subtypes are well defined and all relevant constraints on defining predicates must be declared (graphically or textually). Hence, any exclusion or exhaustion constraints on derived subtypes are always implied. In ORM, all derived constraints are displayed in green, as in Figure 6.39. This notation is supported in the Visio ORM stencil, but is not yet supported in the NORMA tool."

Page 288, Figure 7.21: Symmetric and antisymmetric relations should overlap (as purely reflexive relations are their intersection), and strongly intransitive relations should be a proper subset of acyclic relations. Here is an updated version of Figure 7_21:

Page 262, Fig. 6.56: Change color of Xor constraint to green.

Page 289, sentence 1: "constraints" --> "constraints on non-empty relations".

Page 336, Fig, 8.41: Change color of exclusion constraint to green.

Page 336, Fig, 8.42: Change color of Xor constraint to green.

Page 341, Fig. 8.50: Change color of Xor constraint to green.

Page 428, paragraph 4, append to the first sentence ending with "Chapter 2": "where "single" is used in the sense of "never married".

Page 428, paragraph 5: in sentence 3 change "10.29(a)" to "10.29(b)" and in sentence 4 change "10.29(b) to "10.29(c)".

Page 459, Figure 10.60(a): Add the predicate text "is monolingual" to the unary predicate.

p. 506, Fig. 11.25: Change color of Xor constraint to green.

p. 507, Fig. 11.26: Change color of Xor constraint to green.

Page 521, Figure 13.35(c): change the colour of the predicate reading "smokes" to black. Note: the role of the objectifed unary applies only to its positve instances.

Page 524, Fig. 11.38: Change color of Xor constraint to green.

Page 525, Fig. 11.39: Change color of Xor constraint to green.

Page 792, Figure 15.22(b): "F(in Y)" --> "F[in Y]".

Page 925, second constraint formula: Insert closing parenthesis so it reads "ic (c1, c2, n) requires (hasCountryName(c1,n) and hasCountryName(c2,n)) implies c1 = c2 ".

Page 983, first block of OWL code: Delete closing double-quote after "Person" and "Tony".