Re: Modelling Disjoint Subtypes

From: Marshall <marshall.spight_at_gmail.com>
Date: 24 Mar 2007 11:34:38 -0700
Message-ID: <1174761278.831402.100630_at_y66g2000hsf.googlegroups.com>


On Mar 24, 9:04 am, "V.J. Kumar" <vjkm..._at_gmail.com> wrote:

>

> Could anyone please provide a meaningful relational design example where
> disjoint entity subtype/supertype hierarchy would truly be beneficial ? I
> am aware of Pascal's example but do not find it convincing.

Disjoint subtypes are one of the most common types in programming. As you mentioned, they are ubiquitous in OO programming. In functional programming, disjointness is express via algebraic datatypes, and they see heavy use in that context. The canonical example in the FP world is a parse tree. Clearly each node in the tree can be of only a single kind. Knowing this is true enables techniques such as provably exhaustive pattern matching.

In C, the disjoint type is the union. As is customary in C, the construct is completely unsafe, but nonetheless it's the same basic idea.

Another kind of disjoint type is the enum, as in Java or C++.

> In other words, under what circumstances, other than an attempt to
> emulate object oriented viewpoint, "R <x, y>; R1 <super R, z>; R2 <super
> R, w>" is 'better' than just "R1<x,y,z>, R2<x,y,w>" ? What is achieved by
> such decomposition ? Clearly, there is no data redundancy because R1 and
> R2 are disjoint !

If there is no constraint separating R1<x, y> with R2,<x,y>, then they are *not* disjoint. Nothing stops us from doing:

  insert R1(x, y, z) (1,1,1);
  insert R2(x, y, w) (1, 1, 1);

Marshall Received on Sat Mar 24 2007 - 19:34:38 CET

Original text of this message