# Re: Modelling Disjoint Subtypes

Date: Sun, 25 Mar 2007 12:05:31 GMT
Message-ID: <fAtNh.14892\$PV3.154385_at_ursa-nb00s0.nbnet.nb.ca>

```>>"Marshall" <marshall.spi..._at_gmail.com> wrote innews:1174761278.831402.100630_at_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.

You just punched the tar baby. Entity? What entity?

> 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.

All of that is irrelevant. The specific constraint was chosen to maximize use of foreign key constraints and to minimize general WFF usage. That is all.

> 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?

In the general case, one will have both in any case due to the magic of views.

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

>