Forward mapping models for classes in an inheritance hierarchy

Article information
Article relates to	OpenAccess Classic
Created by	Alexander Filipov
Last modified	December 18, 2008
Last modified by	Alexander Filipov

SOLUTION
To explain the different types of forward mapping in this article we have the following class hierarchy:

It consists of a base ‘Pet’ class, two inheritors – ‘Cat’ and ‘Dog’ and additional ‘Rottweiler’ and ‘WienerDog’ classes that inherit the ‘Dog’ class. Each of them has some information fields. What we want is to make them persistent by using the Telerik OpenAccess ORM tool and ‘Forward mapping’. This can be accomplished in various ways. They differ in how the data is structured in the database and each mapping model has its advantages and disadvantages. This article will guide you how to choose the most appropriate for your needs.


Flat mapping
Flat mapping uses only one table and fields from the subclasses are mapped to the superclass table. It requires the addition of a discriminator or indicator column to the table for the base class to identify the type of each row (except for one special case which has been described below). Flat mapping is the simplest and is usually the fastest option.

Advantages of flat mapping are:

• Only a single query is required to retrieve all of the instances in a hierarchy without any extra joins
• Creating, updating or deleting an instance requires only a single INSERT, UPDATE or DELETE statement

Disadvantages of flat mapping are:

• The base table has many columns that may be used by only a few subclass instances
• A discriminator or class indicator column is required to identify the type of each row

Because flat mapping is the default model used by Telerik OpenAccess ORM, there are no additional actions needed to achieve it except persisting your classes (a step by step ‘how to’ can be found here).
While the project is being built, the following table is created:



The discriminator column has the name ‘voa_class’ by default and its type is a 32-bit positive hash of the fully qualified class name. This value can be changed with another or even can be removed if flat mapping without a discriminator column is required. On the forward mapping wizard can be noticed that mapping strategy for all subclasses was set to ‘flat’. These are the default settings. We will have to change them later when using other mapping models.




Flat mapping with no discriminator
Normally a discriminator column is required for flat inheritance. However if each class in the hierarchy has at the most one subclass, then the discriminator can be disabled and all the rows are considered instances of the leaf class of the hierarchy. A UserException is thrown on any attempt to persist a non-leaf-class instance.
In the example flat mapping without a discriminator column could be used if we had only the ‘Pet’, ‘Dog’ and ‘Rottweiler’ classes or any other hierarchy that has no more than one child class per parent. Configuration is made in the ‘Forward mapping’ wizard by selecting the ‘{no}’ option in the ‘Class-ID’ combo box for the top class (in the example this is ‘Pet’).



As a result the following table is created:




Vertical mapping
With vertical mapping each class has its own table containing only its fields.

Advantages of vertical mapping are:

• Tables are normalized as they only contain columns for the fields of the class they are for and rows are only present for instances of that class
• New subclasses can be added without changing existing tables
• A discriminator column is not required. This may help when mapping an inheritance hierarchy to existing tables.

Disadvantages of vertical mapping are:

• Joins are used to fetch fields from possible subclasses in a single query. If the type of the instance being fetched is known then only its tables are joined, otherwise, all possible subclass tables must be included.
• Creating, updating, or deleting an instance requires multiple INSERT, UPDATE or DELETE statements (one for each table involved)

To enable vertical mapping for a subclass change its mapping strategy in the ‘Forward mapping’ wizard to ‘vertical’. This change should be made for each child class we want to map vertically. Setting for the ‘Dog’ class looks like this:



The corresponding tables for the sample class hierarchy, with vertical mapping are shown below:

Note that there is a discriminator column in the ‘pet’ table. It can be disabled the same way as it is for ‘flat mapping’ - by selecting the ‘{no}’ option in the ‘Class-ID’ combo box for the base class. Nevertheless it is a good practice to keep this column because OpenAccess ORM optimizes the SQL statements and higher performance is achieved when all the instances returned are known to be of a given subclass. For example if the following OQL query is executed:

The generated SQL statement would be:

Note that INNER joins are used instead of OUTER joins, which is faster.

Mixed Flat and Vertical mapping
Telerik OpenAccess ORM supports mixing of flat and vertical mappings in the same hierarchy. For example, in order to save database space, you could choose to use vertical mapping only for seldom-used subclasses with many large fields. Change the inheritance strategy to ‘vertical’ only for these classes and leave the default settings for the rest.
In the example if both ‘Dog’ and ‘Cat’ strategies are changed to vertical with ‘WeinerDog’ and ‘Rottweiler’ left flat, the hierarchy will be mapped to three database tables as shown below. A discriminator column (‘voa_class’) is added to the base table to distinguish between ‘Dog’, ‘WeinerDog’ and ‘Rottweiler’.




Horizontal mapping
Horizontal inheritance can only be enabled for the topmost class in a hierarchy. Each immediate subclass is stored in its own table with a "copy" of the fields from the superclass. A horizontally mapped class, i.e. the superclass, does not itself have a table. Therefore, a horizontally mapped class cannot be directly persisted. Only subclasses of the class can be stored in the database. For this reason, it is recommended (but not required) that horizontally mapped classes be declared abstract.

Note:
While using single or multiple field identity, it is required that the horizontally mapped class is declared abstract.
In case of horizontal mapping, the identity and version information is specified at the next derived class, and if the IdentityField and the VersionField specified are fields that belong to the base class, those fields have to be accessible from the derived classes. Therefore, declaring these fields as "Protected" might be the best way, since if these fields are declared as "Private" the enhanced code will not be able to access these fields. The enhancer will check this and report an error.

Each subclass may map the fields inherited from the superclass differently. Each subclass may have its own settings for identity type, objectid-class, key generator and optimistic locking just like a top level class. Classes further down the hierarchy may be mapped with any combination of flat and vertical inheritance.
To enable horizontal mapping, just change the inheritance strategy to ‘horizontal’ (in the ‘Forward mapping’ wizard) for the base class and change the default values for the rest if needed.

For example our ‘WeinerDog’ and ‘Rottweiler’ classes have been mapped ‘vertically’. The corresponding tables for the sample class hierarchy, with horizontal mapping are shown below:


Advantages of horizontal mapping are:

• Persisting and modifying instances of subclasses whose superclass uses horizontal mapping is as fast as flat inheritance mapping, since generally only a single INSERT, DELELTE or UPDATE statement will need to be issued
• Fetching a single instance will not require any joins
• Attributes that are common to multiple persistent classes can just be defined in the superclass; this increases the performance and relational design restrictions of using a vertical mapping are reduced

Disadvantages of horizontal mapping are:

• The base class, in this case, is not really handled like other persistent classes but only its members are inherited into its derived classes
• Each class derived from the horizontally mapped base class starts a new hierarchy. This is especially relevant while using single or multiple identity, as in this case, the identity must be defined in the derived classes and not in the base class. Also each directly derived class must declare its own identity type, because identity types are not sharable across hierarchies.
• Querying the topmost class in the hierarchy is expensive as it will require multiple SELECT statements, one for each concrete subclass, to be executed against the database; Querying subclasses is just as efficient as flat mapping
• References to and collections and maps of the topmost class are not supported
• From a relational design standpoint, horizontal mappings are not normalized, since attributes are repeated across different tables