Inheritance is a concept that has no equivalent in the relational world.
However,
it is possible to implement it by using strict disciplines and a combination of relational features like tables and foreign keys.

One of the paramount issues about mapping inheritance is how well the mapping supports polymorphism.
Any Object-Oriented persistence facility that deserves its name needs to allow the retrieval of all the Fruits,
and return a heterogeneous collection of Apples,
Oranges and Bananas.
Also,
it must perform this operation in an efficient manner.
In particular,
polymorphic retrieval should not cost one SELECT per retrieved object.

A secondary - yet important - issue is how well the mapping plays by the rules of orthogonal orthodoxy.

Another issue we'll examine is how well the mapping supports 'complex' queries,
that is,
queries that involve several objects.

Three strategies are in common use,
that go by the name Vertical,
Horizontal and Filtered mapping.
They all have advantages and disadvantages.

The following sections describe the three strategies in details.
They make use of a simple object model to illustrate the mappings.

Each concrete class is mapped onto a single table. Each row in the table describes the persistent state of one object.

The attributes are mapped onto columns, usually one column per attribute but not necessarily. For example, collections may be stored elsewhere (for example on a link table) and thus require no column on the class' table.

Polymorphic retrieval costs one SELECT per concrete conforming class; retrieving all the Persons costs two SELECTs. These SELECTs, however, don't use joins - an expensive operation. In our example, retrieving all the Persons requires the following two SELECTs:

SELECT id, name, age FROM NaturalPerson
SELECT id, name, form FROM LegalPerson

This mapping is reasonable with regard to relational orthodoxy, but not perfect: the 'name' column is present on two different tables, with the same semantic.

The biggest drawback, however, happens when you try to perfrom complex queries. Suppose oyu want to retrieve all the Persons (Natural- or Legal-) that own a Vehicle of make 'Saab' (be it a Car or a Plane). Sticking with equijoins, the cost of the operation is four SELECTs:

Each class has its corresponding table, which contains only the class' direct fields. In other words, the table doesn't store the inherited fields. Both concrete and abstract classes get a table. The state of an object is thus scattered over several tables.

This mapping sometimes needs an extra column that carries a type identifier. In our example, we take the very resonable assumption that Person is an abstract class. Had we decided to allow 'pure' Persons, we would have been faced with the following problem: the Person table would contain rows that describe pure Persons, but also rows that describe the Person part of Natural- and LegalPersons. We would need to filter those incomplete objects out when retrieving the pure Persons. Thus the Person table would look like this:

Entire hierarchies are mapped onto a single table. Two rows may describe objects of different types, maybe completely unrelated. The set of columns is the uperset of all the columns needed by all the attributes of any of the classes involved in the mapping.

A special 'type' column contains an value that uniquely identifies the concrete class of the object described by the row.

All the columns related to attributes that don't occur in all the classes must be declared as NULLABLE. Indeed, the table may contain mostly NULL values.

This mapping is very questionable according to relational orthodoxy. Even if one decides to forgo these rules, using such a mapping takes away many of the interesting features offered by modern RDBM systems. Because nearly all the columns must allow NULL values, we cannot take advantage of features like referential integrity constraints, domain constraints, indexes, etc.

Also, as the table becomes cluttered with NULL values, the relative number of significant columns in any given row tends towards zero: we may end up retrieving rows consisting of a little information swimming in a sea of NULLs.

In effect, this mapping may end up hindering performance instead of improving it in presence of deep hierarchies with many attributes.

Tangram supports both vertical mapping and filtered mapping, and any hybrid of the two.

The 'table' attribute in the class description in the Schema can be used to put the state of several classes on the same table. The table name defaults to the class name, resulting in a vertical mapping.