Re: Modelling Disjoint Subtypes

On 24 Mar, 20:26, "V.J. Kumar" <vjkm..._at_gmail.com> wrote:
>
> > If there is no constraint separating R1<x, y> with R2,<x,y>, then
> > they are *not* disjoint.
>
> When I said "because R1 and R2 are disjoint", I implied that there is a
> constraint of course, e.g.: "R1 join R2 is_empty" or similar, as there
> would be with the three relvars !. Having dealt with that diversion,
> back to the original question: "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 ?"
>

One answer is that constraints and other logic relevant to x and y may have to be created for both relvars in the second case but only for one (the supertype one) in the first case. This is mostly an issue of implementation rather than design.

Another problem is the possible difficulty of enforcing the disjoint constraint at all in the absense of the supertype table. Many SQL implementations cannot do that for example (the problem described in my blog post).

Yet another answer is addressed by Date in McGovern with their "Orthogonal Design" principle. Potential ambiguity is created if the same predicate is represented in multiple places in the schema because of multiple relvars with meanings that "overlap". http://www.dbdebunk.com/page/page/622331.htm

--
David Portas