Re: Guessing?
Date: Tue, 27 May 2008 08:38:12 -0400
Message-ID: <VgT_j.2473$N87.1642_at_nlpi068.nbdc.sbc.com>
"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
news:483ac46d$0$4069$9a566e8b_at_news.aliant.net...
> paul c wrote:
>> Bob Badour wrote:
>> ...
>>
>>> ... (Not that I like anthropomorphizing dbmses.)
>>
>> Right, saying the dbms 'knows' something invites talk of it being able to
>> 'guess' and other mysticisms. For want of a better word, for now I'll
>> try to remember to quote it.
>
> With POOD, any tuple satisfies the predicate of at most one relation in
> the dbms. Thus, with POOD, the dbms can calculate a unique relation to
> which to apply any insert, update or delete with the goal of avoiding
> anomalous behaviour.
>
This just does not make sense. Suppose that a Vendor can also be a Customer since they're both Companies, and suppose that Company 'Philco' usually supplies 'RG6 connectors,' but occasionally buys them. So then if you have two relations,
VendorParts {Company, Part},
CustomerParts {Company, Part},
that enumerate the parts that a company supplies and the parts that a company buys respectively,
In TTM, Darwin raises objections to such a strict form of orthogonality, and I agree: it's a problem to disallow more than one relationship between things, and in the case of unary relations, it's a problem to disallow something from having more than one property. (Page 436 if you're interested.)
> In the case of the union view from Codd's book, POOD requires the base
> relations to have disjoint predicates. Because the predicates are
> disjoint, the dbms can calculate to which base relation to apply the
> insert. If one ignores POOD, the dbms still calculates the base relations
> to which to apply the insert, but the base relations need not be disjoint.
>
> Symmetry requires the dbms apply the insert to all base relations in the
> union view for which the tuple satisfies the predicate.
>
> In this respect, Codd's example is a straw man. In the example, he failed
> to declare the predicates to the dbms so they were unavailable for
> calculation.
Received on Tue May 27 2008 - 14:38:12 CEST