Class Table Inheritance is one of several techniques for designing SQL tables in situations where subclasses that extend classes would apply if SQL had a mechanism for inheritance, which it doesn't.
SQL as such has no formal mechanism for implementing inheritance on behalf of the database builder. However, there are ways to design tables that mimic, to some extent, the behavior you would get from subclasses that extend classes in an object oriented environment.
Class Table Inheritance is one such design technique. In this technique, there is one table for the class, and one table for each distinct subclass. Columns that are relevant to all members of the class go in the class table. Columns that are only relevant to some subclasses (often only one subclass) go in the appropriate subclass table(s). The concept can easily be extended to cases where the class is itself a subclass of some even more generic superclass.
The primary key of the class table and the primary key of the subclass tables are usually shared. This is described under the tag shared-primary-key. Implementing shared primary key involves some work on the part of the programmer, because the primary key has to be propagated from the class table to the appropriate subclass table(s) by programmed action whenever new entries are made in the class table. Shared primary keys enforce the one-to-one nature of the relationship.
A join between one of the subclass tables and the class table is simple, easy, and fast. All rows in the class table that do not pertain to the subclass at hand will drop out of the join. For convenience, these joins might be kept in defined views.
There are circumstances where the subclasses are mutually exclusive. A pet is never both a dog and a cat. There are cases where the subclasses are not mutually exclusive. One person might be both a student and an instructor at a university.
A different but simpler technique for dealing with inheritance is described under the tag single-table-inheritance.
