Relational Inheritance Thoughts The most fundamental property of relational inheritance is that it creates hierarchies of relations that act as composite relations. That is, relational inheritance produces a tree of relations (presumably tables) that itself can be treated as a relation. The tree can be queried as if it were a single table, and provided that the signature of the tuple is distinct, inserts and updates can also be polymorphically executed against the hierarchical composite relation. Obviously, relational inheritance is one way to realize an object-relational feature in a database. What is almost as obvious is that inheritance introduces a non-relational database element into the underlying database model. Depending on whether or not the implementation supports single or multiple inheritance the resulting product supports not only a relational database model but also either a hierarchical or an acyclic network [acdg]. At the risk of belaboring the point, relational single inheritance resembles a hierarchical database, like a traditional computer file system. A relational multiple inheritance database resembles a network database, like the once promising CODASYL standard or the GROVE or DOM representation of an XML hyper-document. I recall reading somewhere that network databases can realize all the functional power of a relational database and the reverse is also true (thus, network and relational databases are functional equivalents). Translating between the two models is, unfortunately, not trivial. The reader will know from experience that normalized relational databases (and more so, some strategic denormalized data warehouse forms) are relatively easy to query. On the other hand, algorithmic data structures naturally become trees and directed graphs. It is easy to do application programming for a network database. A database with relational multiple inheritance is a hybrid between a relational database and network database that ought to support any mixture of the data models without prejudice. The ability to handle a network data model has the advantage of eliminating the need to provide a translation layer that marshals data to and from each application that uses the database. The networked object oriented data from an application can (theoretically) go directly into the network composite relation without the translation needed to put it in relational form. More generally, the ability to work with a dual system supporting both relational and network models simultaneously will give database designers another degree of freedom in expressive power. A good designer will be that much better with relational inheritance options. (On the other hand, novice and poor designers will have more rope with which to hang themselves.) On the downside, one expects that a data design cannot be optimized both for write operations and for queries. Relational inheritance allows database to be designed for the convenience of application programmers at the expense of report writers. Given the typical design process for databases and the relative power and prestige of application and report developers one indeed expects that relational inheritance *will* be used to the advantage of application programmers and the detriment of report writers. Furthermore, relational multiple inheritance databases have to encompass the complexity of Relational X Network. A relational multiple inheritance database system should be a degree of magnitude more complex than its relational (or network) relative. The reward will be more expressive convenience for database designers. The resulting system, however, will have no more functional power than either a relational or network database system. Also interesting is that a table (or relation) may have an “attitude” toward parenthood. The table may be preapted. A preapted table is explicitly and completely ready for use as the parent of a class hierarchy. It is fully class aware. One should be able to explicitly make a preapted stand-alone table Adhamic, ready for use as the first ancestor of a hierarchy. Of course, you should also be able to declare that a preapted table is FINAL. Furthermore, declaring any class property on a table should implicitly make the table itself a member of a relational inheritance network. Note that strict preaptation does not allow for opportunistically finding a purely relational table and using the relational table as the first ancestor of a relational inheritance class. Another attitude toward parenthood is indifference. There are various ways that a table may be purely relational, thus indifferent to being used as a class ancestor. The table may be implicitly ignorant. As far as a found Adhamic table is concerned there is no class. It is absolutely unconstrained by any objects dependent on it and it would be utterly ignorant that it is implicated in a class. No doubt, implicit indifference would make for a problematic implementation. In another variation on indifference, a relational table could be found and quietly, implicitly bound to a class. This is arguably what Postgresql's INHERITS clause is working toward though the implementation is incomplete. The incomplete implementation leaves Postgresql with some annoying aspects reminiscent of implicit ignorance. In a third variation a designer can opportunistically inherit from a purely relational table, but first the relational table must be made explicitly aware that it will be used in a relational network. One would probably extend ALTER TABLE to accommodate the new semantics. It should go without saying, but some naïve suggestions for extending Postgresql's INHERITS clause regarding class unique constraints warrant mentioning that relational inheritance classes *must* be hierarchical. It may be tempting to allow global declarations that let descendants constrain the current state of an ancestor, but down that road lies chaos. Relational inheritance should use a strict subclassing model wherein subclasses nest within subclasses until one reaches to top of a hierarchy. Two subclassing models present themselves. One is Java-like where all objects must be derived from objects, ultimately tracing their ancestry to the Ur-object. In a database this would mean that every table would have to ultimately derive from ur-table. The Java-like system can be called an “forced inheritance modality.” The other modality is more like C++. Multiple hierarchies are allowed, tables can be relational and need not be object aware. Object tables can derive from relational tables. This sort of system can be called a “dual inheritance modality”. Postgresql's INHERITS clause implements the more expressive dual inheritance modality. The major detraction is that a class cannot be directly instantiated, but can only be based on a preexisting purely relational table. As you read this, remember that the relational inheritance classes are not slavishly analogous to classes in object oriented programming languages. For example, in well designed OO programming you avoid directly accessing data. With relational inheritance, in contrast, you directly access data. The tuple is the interface. ------ [acdg]: Of course, in asserting that a relational inheritance database with multiple inheritance support is acyclic, one assumes that there is no way to “forward declare” an inheritance vector. A DECLARE/DEFINE function might provide mutual or recursive inheritance.
