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