Page Comparison

...

• The abstract class Person
• The concrete class Employee, derived from Person
• The concrete class Customer, also derived from Person
• The abstract class Order, not derived from Person

Here is the UML diagram:

FIXME ILLUImage Added

In the following discussion, we will simply use dashed boxes for signaling table borders.

...

For single table inheritance, objects instances belonging into the same tree of ancestry go into the same table.

FIXME ILLUImage Added

This gives us two tables:

...

Concrete table inheritance reduces the number of columns in tables significantly, at the expense of speed and programmer convenience. This diagram shows how the inheritance tree is sliced up for concrete table inheritance:

FIXME ILLUImage Added

For concrete table inheritance, we end up with separate tables for each concrete class (hence the name "concrete table inheritance"). In our example, we give each of the Employee- and Customer- branches its own table. Nothing changes for Order, of course. Here is a list of tables and their columns:

...

With class table inheritance, you can reduce the number of columns even further, albeit at the expense of even more speed and programmer convenience. Here is the diagram that shows that each class gets its own table:

FIXME ILLUImage Added

Consequently, we end up with four tables.

...

Order is not affected in this thought experiment and happy as a clam with its OrderID and Date columns.
As explained in the re-store section of the overview, class table inheritance transforms the "is-a" relationship into a "has-a" relationship. Expressed in UML:

FIXME ILLUImage Added

In the left ("IS A") diagram we see that the object someEmployee is an Employee which in turn "is a" (subclass of) Person. It is possible to store the same attributes of an Employee without inheriting from Person, however, by making a separate instance of Person and putting a reference to it into someEmployee. In the right diagram we see that "HAS A"-relationship. This is essentially what class table inheritance does to inheritance behind the scenes: spreading a single "instance" over several instances and establishing references between them. This is very economical in terms of redundancy, but clumsy in terms of speed and programmer convenience. After all, the query for assembling all instance data is complicated by JOINs.
As you see, the three approaches to object-relational mapping must make compromises between minimizing space or minimizing complications. Which approach is actually used in a re-motion application must be decided by a developer after taking into account how the data is used (but be aware that class table inheritance is not supported by re-motion yet). In practice a mixture between class table inheritance and concrete table inheritance is used. Before we turn to discussing how such decisions are made for a given domain, here is a recap of the advantages and disadvantages of the three table inheritance strategies in one handy grid:

...