Re: Modelling Disjoint Subtypes
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 24 Mar 2007 18:52:41 GMT
Message-ID: <ZreNh.14641$PV3.151425_at_ursa-nb00s0.nbnet.nb.ca>
>
>
> 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++.
>
>
>
>
>
> 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);
Date: Sat, 24 Mar 2007 18:52:41 GMT
Message-ID: <ZreNh.14641$PV3.151425_at_ursa-nb00s0.nbnet.nb.ca>
Marshall wrote:
> 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);
The point someone seems to have missed is the RM doesn't treat dijointedness as anything special. A base relation describing commissions might be constrained to 'Seller' today but allow both 'Seller' and 'Author' tomorrow when a company starts paying commissions to authors. Predicate calculus and set algebra each already have sufficient expressiveness to handle both easily.
OO on the other hand requires greater complexity for less flexibility. Received on Sat Mar 24 2007 - 19:52:41 CET