Database Reference
In-Depth Information
Figure 6-19.
The completed model with the derived entities BMW and Toyota represented in the database
as separate tables
How It Works
Table per Concrete Type is an interesting inheritance model in that it allows each derived entity to map to separate
physical tables. From a practical perspective, the tables need to share at least some part of a common schema. This
common schema is mapped in the base entity while the additional schema parts are mapped in the derived entities.
For Table per Concrete Type inheritance to work properly, the entity key must be unique across the tables.
The base entity is marked abstract, and it is not mapped to any table. In Table per Concrete Type, only the derived
entities are mapped to tables.
In our example, we marked the Car entity as abstract and we did not map it to any table. In the mapping shown
in Listing 6-35, notice that we mapped only the derived entities BMW and Toyota. We moved all of the common
properties (CarId, Model, Year, and Color) to the base entity. The derived entities contained only the properties
unique to the entity. For instance, the BMW entity has the additional CollisionAvoidance property.
Because the entities Toyota and BMW derived from the Car entity, they became part of the same Cars entity set.
This means that the CarId entity key must be unique within the entity set that now contains all of the derived entities.
Because the entities are mapped to different tables, it is possible that we can have collisions in the keys. To avoid this,
we set the CarId column in each table as an identity column. For the BMW table, we set the initial seed to 1 with an
increment of 2. This will create odd values for the CarId key. For the Toyota table, we set the initial seed to 2 with an
increment of 2. This will create event values for the CarId key.
When modeling relationships in Table per Concrete Type inheritance, it is better to define them at the derived
type rather than at the base type. This is because the Entity Framework runtime would not know which physical table
represents the other end of the association. In our example, of course, we provided a separate table (CarDealer) that
contains the relationship. This allowed us to model the relationship at the base entity by mapping the association to
the CarDealer table.
