Re: Modelling Disjoint Subtypes
Date: Wed, 28 Mar 2007 16:39:12 +0200 (CEST)
Message-ID: <Xns99016C61C8E14vdghher_at_194.177.96.26>
"David Portas" <REMOVE_BEFORE_REPLYING_dportas_at_acm.org> wrote in news:1175074877.506103.251950_at_e65g2000hsc.googlegroups.com:
> 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.
Ok.
>
> 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).
Your implementation, whilst nice, does not enforce one-to-one but only one-to-zero-or-one relationship. I gather it's impossible to achieve in SQL Server, although can be done in Oracle in a purely declarative way. On the other hand, you can enforce disjointness with just two tables in SQL Server, programmatically, but cannot do the same in Oracle.
>
> 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
But we are discussing the disjoint case such that thanks to the constraints the meanings do not overlap. It's interesting to notice that Date and McGoveran do not discuss the issue in terms of entity subtype/supertype, but rather in terms of potential redundancy, perhaps due to the entity subtype/supertype dubious and often misleading intuition coming from its OO origins.
>
> --
> David Portas
>
>
>
>
>
>
>
>
>
>
Received on Wed Mar 28 2007 - 16:39:12 CEST