Re: Modelling Disjoint Subtypes

On Mar 24, 11:26 am, "V.J. Kumar" <vjkm..._at_gmail.com> wrote:
> "Marshall" <marshall.spi..._at_gmail.com> wrote innews:1174761278.831402.100630@y66g2000hsf.googlegroups.com:
>
> > On Mar 24, 9:04 am, "V.J. Kumar" <vjkm..._at_gmail.com> wrote:
>
> >> 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.
>
> 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 ?"

Okay.

One often wants to consider all the different sub-entities together. If one has ten different disjoint types, and one wants to count them, having a table for the common attributes means the count() can be done with a single table, vs. a join of ten tables.

On the other hand, if one has a query that needs both common and unique attributes, that query would require two tables vs. just one if we didn't have the common attributes in a supertype table. Anyone have any other considerations?

> I am not sure I understand the relevancy of your appeal to functional and
> OOP point of view.

You asked about the relevance of disjoint subtypes; I was pointing out how the construct appears in a wide variety of computational models.

Marshall Received on Sun Mar 25 2007 - 03:25:51 CEST