Modeling Inheritance - Overview
This article is relevant to entity models that utilize the deprecated Visual Studio integration of Telerik Data Access. The current documentation of the Data Access framework is available here.
When objects and/or class definitions are mapped to a relational schema, then a set of technical challenges are encountered. The notion is that there are concepts of the object-oriented world that simply don't have a corelated capability in the relational world. This is the root of the problem which Telerik Data Access is trying to solve. This section will show you how to model inheritance mapping by using the Telerik Data Access Visual Designer.
Translating Object Concepts to Relational Elements
Some translations are simple and straightforward:
- Object -> Table
- Property -> Field
- Collections -> Foreign Keys
However, other kind of translations are neither simple nor straightforward:
- Interface -> ???
- Abstract Class -> ???
- Inheritance -> ??? - critically important concept in the object-oriented programming, which doesn't have immediate corresponding allegory in the relational database technology.
Vertical Mapping
Telerik Data Access offers a couple of different ways to ultimately model inheritance hierarchies in a relational database. The simplest, most straightforward approach is to use vertical mapping. With vertical mapping each class has its own table containing only its fields. That strategy is also known as "table-per-concrete-class" model. Each concrete persistent class in the domain model is persisted to its own table. For example, a Customer object is stored in the Customers table.
The benefits of this strategy are:
- Simple, easy to use, easy to understand, easy to maintain
- Easy to extend - just add another table or field
However, there are some downsides in this strategy:
- Inheritance hierarchies aren't represented in the database
- You can still maintain them in the code, but there is no database representation of the hierarchy.
Flat Mapping
The second of the three choices for modeling inheritance in the database is to use Flat mapping. With flat mapping, fields from the subclasses are mapped to a superclass table. Flat mapping is the simplest and is usually the fastest option so it is the default. In Flat mapping, the entire class hierarchy is persisted to a single table. That includes everything from an interface/abstract class at the top, all the way down to implementation classes at the bottom. How this actual works is to extend the table to include additional fields needed by the subclasses. Also you need to provide a "discriminator" column to tell Telerik Data Access which rows are for which classes.
The benefits in this approach are:
- Scales well - querying against any object in the hierarchy will be a query against a single table.
- Easy to extend - just add additional fields for each new class.
The downsides in this strategy are:
- Fields that extend subclasses in the table must be nullable.
- Awkward to look at from outside the Telerik Data Access world.
Horizontal Mapping
The third choice for modeling inheritance in the database is to use 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) for horizontally mapped classes to be declared as abstract.
In this section: