Table Inheritance

The idea where there are sub-tables in RDBMS that "inherit" the schema of the parent(s) table. Often found in the context of OODBMS products.

More specifically, table inheritance occurs when you have a table A that contains tuples with a certain schema. In addition, there is a second table B containing tables with an "inherited" schema--usually one with additional attributes in the tuples. Furthermore, A and B are constrained such that for every element in B, the projection of said element that excludes the extra attributes, is found in A. When this occurs, B is said to be a subtable of A.

This occurs when relations in a database are mapped to classes in an OO language (for a class with a given set of data members; there's a table whose schema defines an equivalent set of attributes), and there is a correspondence between class instances (objects) in an application and tuples in the equivalent table. When subclasses (and subclass instances) of the class appear (often adding additional data members), a corresponding relation containing instances of the subclass (and a schema matching the subclass definition) is made. But since instances of the subclass are also valid instances of the base class; every tuple in the subtable must correspond with a (sliced) tuple in the supertable.

DateAndDarwen thoroughly trash the idea in TheThirdManifesto.


Many, perhaps most relational proponents don't find this concept very useful, generally because they believe that over the longer run variations of a concept don't really stay in a "tree shape" (LimitsOfHierarchies). Schemas are more fragile than application OOP classes, and thus refactoring the inheritance hierarchy to deal with changes could be problematic. Unlike OOP inheritance, attributes are the preferred way to classify rows at the sub-entity level, not pedigree.

Of course, there's no reason that TableInheritance need be "tree-shaped", though certain OODBMS products and OO-relational mapping products that do it may be limited to single table inheritance. Multiple table inheritance would remove the "tree" limit.

I have never seen a proposed usage scenario for multiple schema inheritance. Single inheritance has been proposed for the Party Pattern (ContactAndAddressModels). Generally, something that complex would be better managed via the SetTheory built into relational rather than dealing with potentially overlapping hierarchies. Of course, this risks turning into another multi-trees versus sets HolyWar.

What holy war? I don't know what you mean by a "multi-tree"; if you mean what I think you mean, the proper name for such a creature is a DirectedAcyclicGraph. That's what the "inheritance tree" in system with MultipleInheritance looks like. And guess-what? That's also what the "inheritance tree" in a SetTheory based type system looks like. Such a HolyWar would be a civil war, it seems.

What keeps it from having cycles? Recursive definitions certainly seem possible if the compiler/interpreter does not check against it. Also, I consider sets simpler, or at least better understood, than DirectedAcyclicGraph.


Returning to the subject at hand, and ignoring the foray into AbstractAlgebra? above, there is one problem with sets, when sets are expressed as relations (or as enumerations):

They are finite.

Relational tables have no way of encoding infinite sets. Suppose I wanted to represent the set of all pairs of integers (we'll ignore the issue of finite-precision math). Using a struct/class definition, it's easy:

 struct PairOfInts? { int x, y; };
In C/C++, this gives us two things: First, a means to construct an arbitrary pair of ints, and second; the concept of the type of a pair of ints - in other words, a set of which every pair of ints is a member.

{But how do you populate the struct with your int values? You would make an array of that struct right? If you use an array then you have to populate the array, just like you have to populate the table! So I'm not understanding what your point is; can you please clarify? Also, a table could have a column type that supports two ints (a struct type) in one cell, but current databases do not have such a rich type systems.}

Switching to relational, we can easily write an equivalent schema. In SQL:

 CREATE TABLE pair_of_ints
 (
   x INT,
   y INT
 )
One can create a table of that type, and populate it with as many pairs as one likes. HOWEVER, since tables are enumerated sets; only a finite number of pairs (those inserted into the table) can be so populated. The relational algebra doesn't provide a way, inductive or deductive, to build up a set with an infinite number of members.

Now, there are tools and theories to overcome this problem. The combination of relations and logic programming, wherein relations can contain ground cases for a logic language (such as Datalog), augmented with Prolog-style rules, is capable of inductively describing infinite sets. However, this is still an area of research; and certain queries in logic languages (like trying to disprove a proposition), can be dicey.

Inevitably, if you want to encode something infinite, you first devise some finite representation of it.

What would be a real world manifestation of this (alleged) gap? I want a tool that helps people get work done, not so much a better theoretical notation.

{The relational model was theoretical with a theoretical notation and helped people get work done...}

I meant a practical need to have a set with infinite members.

{I don't even understand what he is getting at with the infinite member idea, because a struct doesn't say you can have infinite members... you would have to make an ARRAY of STRUCT first, or pointers to the struct, or a list of the struct... a struct is just a single data item, not infinite. But as for finding a practical need for things, my point is that Top disses theory too much when in fact theory and practice are bridged - they are not separate like you think.}

Then show it, not just claim it. "Here's a practical scenario where lack of feature X causes real-world difficulties." If that's too much to ask, then I guess I just view the world all wrong and stupidly and am fucked in the head.


See Also: ObjectsAreFromMarsTablesAreFromVenus, FirstGreatBlunder, SetsAndPolymorphism

JanuaryZeroSix


EditText of this page (last edited April 8, 2012) or FindPage with title or text search