The document discusses four approaches to representing object inheritance in a relational database: table per concrete class with implicit polymorphism, table per concrete class, table per class hierarchy, and table per subclass. It explains the advantages and disadvantages of each approach, noting that table per class hierarchy has the best performance for polymorphic queries but can lose data integrity, while table per subclass best maintains normalization but requires more joins. The best strategy depends on an application's polymorphic query and association needs versus data integrity and performance factors.

1. Professional Open Source™
Mapping Inheritance
© JBoss, Inc. 2003, 2004. 07/17/04 1

2. Mapping Class Inheritance
Professional Open Source™
 Inheritance is such a visible structural mismatch between the object-
oriented and relational worlds because object-oriented systems
model both is a and has a relationships.
 SQL-based models provide only has a relationships between entities;
 SQL database management systems don’t support type inheritance .
 Four different approaches to representing an inheritance hierarchy:
– Table per concrete class with implicit polymorphism—Use no explicit
inheritance mapping, and default runtime polymorphic behavior.
– Table per concrete class—Discard polymorphism and inheritance
relationships completely from the SQL schema.
– Table per class hierarchy—Enable polymorphism by denormalizing the
SQL schema, and utilize a type discriminator column that holds type
information.
– Table per subclass—Represent is a (inheritance) relationships as has a
(foreign key) relationships.
© JBoss, Inc. 2003, 2004. 2

3. Table per concrete class with implicit polymorphism
Professional Open Source™
 The mapping for CreditCard and BankAccount is straightforward, each in its
 own entity <class> element, as we have done already for classes without a superclass
 (or persistent interfaces).
 Hibernate still knows about the superclass (or any interface) because it scans the
persistent classes on startup.
© JBoss, Inc. 2003, 2004. 3

4. Problems with previous strategy
Professional Open Source™
 The main problem with this approach is that it doesn’t support
polymorphic associations very well. In the database, associations are
usually represented as foreign key relationships. As both the
subclasses has different table which has a different foreign key, if we
have to use superclass reference in any other class, it is difficult.
 In previous figure, if the subclasses are all mapped to different
 tables, a polymorphic association to their superclass (abstract
BillingDetails in this example) can’t be represented as a simple
foreign key relationship
 Polymorphic queries (queries that return objects of all classes that
match the interface of the queried class) are also problematic.
 A query against the superclass must be executed as several SQL
SELECTs, one for each concrete subclass.
© JBoss, Inc. 2003, 2004. 4

5. Problems with previous strategy
Professional Open Source™
A further conceptual problem with this mapping strategy is that
several different columns, of different tables, share exactly the
same semantics. This makes schema evolution more complex.
For example, a change to a superclass property results in changes
to multiple columns. It also makes it much more difficult to
implement database integrity constraints that apply to all
subclasses.
This approach is recommended where polymorphism isn’t usually
required, and when modification of the superclass in the future is
unlikely.
© JBoss, Inc. 2003, 2004. 5

6. Table per concrete class with unions
Professional Open Source™
 In this situation, we again have two tables and duplicate superclass
columns in both: CREDIT_CARD and BANK_ACCOUNT.
© JBoss, Inc. 2003, 2004. 6

7. Advantages of this strategy
Professional Open Source™
 The first advantage you may notice with this strategy is the shared
declaration of superclass (or interface) properties. No longer do you
have to duplicate these mappings for all concrete classes—Hibernate
takes care of this.
 Keep in mind that the SQL schema still isn’t aware of the inheritance;
effectively, we’ve mapped two unrelated tables to a more expressive
class structure.
 Polymorphic queries use union
 Another much more important advantage is the ability to handle
polymorphic associations; for example, an association mapping
from User to BillingDetails would now be possible. Hibernate can use
a UNION query to simulate a single table as the target of the
association mapping
© JBoss, Inc. 2003, 2004. 7

8. Table per class hierarchy
Professional Open Source™
 An entire class hierarchy can be mapped to a single table. This table
includes columns for all properties of all classes in the hierarchy. The
concrete subclass represented by a particular row is identified by the
value of a type discriminator column.
© JBoss, Inc. 2003, 2004. 8

9. Advantages of table per class hierarchy strategy
Professional Open Source™
 This mapping strategy is a winner in terms of both performance and
simplicity.
 It’s the best-performing way to represent polymorphism—both
polymorphic and non polymorphic queries perform well—and it’s even
easy to implement by hand.
 Ad-hoc reporting is possible without complex joins or unions. Schema
evolution is straightforward.
 There is one major problem: Columns for properties declared by
subclasses must be declared to be nullable. If your subclasses each
define several non nullable properties, the loss of NOT NULL
constraints may be a serious problem from the point of view of data
integrity.
 Another important issue is normalization.
© JBoss, Inc. 2003, 2004. 9

10. Table per subclass
Professional Open Source™
 The fourth option is to represent inheritance relationships as relational
foreign key associations.
 Every class/subclass that declares persistent properties—including
 abstract classes and even interfaces—has its own table.
 Unlike the table per concrete class strategy we mapped first, the table
here contains columns only for each non inherited property (each
property declared by the subclass itself) along with a primary key that
is also a foreign key of the superclass table.
 See next page for diagram ..
© JBoss, Inc. 2003, 2004. 10

11. Mapping all classes of the hierarchy to their own table
Professional Open Source™
© JBoss, Inc. 2003, 2004. 11

12. Professional Open Source™
 If an instance of the CreditCard subclass is made persistent, the
values of properties declared by the BillingDetails superclass are
persisted to a new row of the BILLING_DETAILS table. Only the
values of properties declared by the subclass are persisted to a new
row of the CREDIT_CARD table. The two rows are linked together
 by their shared primary key value. Later, the subclass instance may
be retrieved from the database by joining the subclass table with the
superclass table.
 The primary advantage of this strategy is that the SQL schema is
normalized. Schema evolution and integrity constraint definition are
straightforward.
 A polymorphic association to a particular subclass may be
represented as a foreign key referencing the table of that particular
subclass.
© JBoss, Inc. 2003, 2004. 12

13. Choosing a strategy
Professional Open Source™
 If you don’t require polymorphic associations or queries, lean toward table per
concrete-class—in other words, if you never or rarely query for BillingDetails
and you have no class that has an association to BillingDetails(our model
has).
 An explicit UNION-based mapping should be preferred, because (optimized)
polymorphic queries and associations will then be possible later. Implicit
polymorphism is mostly useful for queries utilizing non-persistence-related
interfaces.
 If you do require polymorphic associations (an association to a superclass,
hence to all classes in the hierarchy with dynamic resolution of the concrete
class at runtime) or queries, and subclasses declare relatively few properties
(particularly if the main difference between subclasses is in their behavior),
lean toward table-per-class-hierarchy. Your goal is to minimize the number of
nullable columns and to convince yourself (and your DBA) that a
denormalized schema won’t create problems in the long run.
© JBoss, Inc. 2003, 2004. 13

14. Professional Open Source™
 If you do require polymorphic associations or queries, and subclasses
 declare many properties (subclasses differ mainly by the data they
hold), lean toward table-per-subclass. Or, depending on the width and
depth of your inheritance hierarchy and the possible cost of joins
versus unions, use table-per-concrete-class.
© JBoss, Inc. 2003, 2004. 14