Supertyping Tables - Is Multiple Inheritance Possible?

Question

It's possible that this question either has a simple answer that's a standard practice, or has no answer because it can't be done for a simple reason, or is otherwise just an interesting thought exercise. I'm currently sitting on the last option, but hoping for the first...

Let's say I want to create a "group" or "class" of entities within my data model. Generally, I'd use a supertype table like this:

DrivableEntity
----------
ID (PK, auto-increment)
Type (int or otherwise some kind of enum)

Car
----------
ID (PK, FK to DrivableEntity)
(car-specific fields)

Bike
----------
ID (PK, FK to DrivableEntity)
(bike-specific fields)

Then my inserts would probably go through what externally looks like a normal CRUD procedure for each sub-table but internally inserts into DrivableEntity and then uses the scope identity to insert into the intended table.

Being more of a programmer than a data modeler, this got me thinking about object inheritance. For direct inheritance this is great. The common data/tasks can be abstracted up a level, Liskov Substitution can be maintained, etc. But is multiple inheritance possible in a data model?

I'm primarily a C# developer, so I started thinking in terms of interfaces. What if I wanted to expose tables which "implemented" IDrivable and/or ITowable, etc. Is something like this possible? Has anybody done anything like it before?

Answer 1

Generally two approaches to the data model work well for what you described.

The model you already described is one of the approaches, and has the benefit of being very "tidy". It works especially well if you have a large number columns in the tables, so the size of an individual object doesn't get too large or wide.

DrivableEntity
----------
ID (PK, auto-increment)
Type (int or otherwise some kind of enum)

Car
----------
ID (PK, FK to DrivableEntity)
(car-specific fields)

Bike
----------
ID (PK, FK to DrivableEntity)
(bike-specific fields)

The other approach is to keep all the columns nullable in a single table, and mark each row with a type indicator. This approach can get messy fast, but has much less overhead for simple cases.

You can model inheritance or interfaces in your original model, simply by adding another foreign key column to one of the "derived" entities. For instance:

FlyableEntity
-------------
ID (PK)
... flyable attributes

FlyingCar (implements/inherits IDrivable and IFlyable)
-------------
DrivableEntityID (PK, FK)
FlyableEntityID (PK, FK)
... add flying car attributes

or:

FlyingCar (inherits from Car)
-------------
CarID (PK, FK)
FlyableEntityID (FK)
... add flying car attributes

Answer 2

David,

The Entity Framework has the ability to use inheritance. This is good overview of inheritance in the Entity Framework. You can use POCO with EF to create your own interfaces to provide access to the data.

The situation you are describing isn't really multiple inheritance, as you have one base table/entity and to derived tables/entities. To model this in EF, you create a base entity, then create each child entity. At this point, you can map child entity propreties of each type to the correct table.

With that said, your insert/update/delete logic is going to get very complex. The Entity Framework might run into issues with a complex model.

The question that I would have is, why are you doing this? If it is to share common data between types, I would recommend creating Views on the server that join the parent table with the child tables. It will be much faster, and you can handle CUD (create/update/delete) operations with an instead of trigger which will make for easier SQL, as there is a clear split between data access and data storage.

Does this make sense?

Erick

Answer 3

You could create views to solve this problem.

viewDriveableCar
ViewDrivabaleBike
ViewTowableCar

Then combine the views into a super view combining drivable and towable entities using a union. You could only include those column that were common among both. Similar but different names would need to be normalized:

CREATE VIEW vrDiveTow
AS

SELECT
viewDriveableCar.CarId as ID,
... other attributes

UNION

SELECT
viewTowableCar.TowableId as ID,
... other attributes
UNION

A big gotcha. SQL uses query plans which can be cached to produce the results. If SQL's query plan is built around querying for 'Seven-Up' and you are filtering for 'Coke' then the query plan is ineffective and a full table scan actully gets used.

Answer 4

Subtyping is possible, but also discouraged. Databases are world of their own and you should not try to bring OOP principles into that world. Many have tried, many have failed. If you try to think about database "objects" in OOP terms, your database will suffer.