Re: Guessing?

From: Brian Selzer <brian_at_selzer-software.com>
Date: Fri, 20 Jun 2008 15:25:14 -0400
Message-ID: <SuT6k.3976$cW3.2410_at_nlpi064.nbdc.sbc.com>

"paul c" <toledobysea_at_ac.ooyah> wrote in message news:thE6k.17347$Jx.12051_at_pd7urf1no...

> Brian Selzer wrote:

>> "paul c" <toledobysea_at_ac.ooyah> wrote in message
>> news:63z6k.38054$gc5.18499_at_pd7urf2no...

>>> Brian Selzer wrote:
>>>> "paul c" <toledobysea_at_ac.ooyah> wrote in message 
>>>> news:etU_j.167881$rd2.59570_at_pd7urf3no...
>>>>> Brian Selzer wrote:
>>>>>> "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:
>>> ...
>>>>>>> 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,
>>>>>>
>>>>>> the tuple, {Company:'Philco', Part:'RG6 connector'}, can obviously 
>>>>>> appear in both relations, so I don't buy the notion 'any tuple 
>>>>>> satisfies the predicate of at most one relation.'
>>>>>> ...
>>>>> Isn't this a straw man too?  (arguing against POOD with an example 
>>>>> that doesn't follow POOD.)
>>>> I think it does follow POOD, but I think Badour's overstrict 
>>>> interpretation of POOD is flawed.
>>> In that case, why don't you state your interpretation (in less than say 
>>> 50 words or so I could hope).
>>

>> POOD seeks to prevent the occurrance of base relations with overlapping
>> meanings.

>
>
> Okay, even though "overlapping" might be a bit vague, that's much less 
> than 50 words ;)
>
>
> > ... In a first order language, you have constant symbols and

>> predicate symbols, and under an interpretation, meaning is assigned not
>> only to the constant symbols but also to the predicate symbols. The way
>> I see it, the only way you can have overlapping meanings is if a relation
>> has a disjunctive predicate. ...

>
>
> Not sure if that's so, but willing to assume it is for now.  It reminds me 
> that I have doubts about whether any relation should be allowed to 
> disjunctions within individual propositions, at least if we want 
> 'interchangeability'.  For example, a base relvar that has been inserted 
> to with "union" certainly doesn't have a disjunctive predicate so why 
> should a view that is manifested the same way be different?

Because one involves two database states and the other involves only one. Any mutating operation necessarily involves two database states (or instances, or values--whichever nomenclature you prefer): there is what was then supposed to be the case and what is now supposed to be the case. But a view simply presents information contained in one database state--what is now supposed to be the case--in a different way. The connection between what is presented by a view and what is in the underlying relations is the expression that defines the view. If that happens to be a union, then the predicate of the view is the disjunction of the predicates of the two operands of the union. This is inescapable.

> The only time I can see where a view should preserve the disjunction is 
> when it concerns relations that aren't so-called 'union-compatible'.
>

Then you are suggesting that we ignore the connection between a derived relation and that which underlies it. Ignore the connection and a view is no longer a derived relation--a stored query--but rather a stored query result.

>

>> ... For example, if relation R has predicate Pxy and relation S has
>> predicate Pxy \/ Qxy, then there is overlapping meaning between relations
>> R and S because a tuple that satisfies P can appear in both, but if
>> relation T has predicate Qxy, then there isn't any overlap between R and
>> T (assuming, of course, that predicates P and Q are atomic). The idea
>> that there can be only one relation with a particular heading is just
>> stupid, since it would require many relations to have disjunctive
>> predicates. To me it doesn't make sense to have a relation that contains
>> either customer parts or vendor parts or both just because the heading
>> for customer parts is identical to the heading for vendor parts.

>
> Personally, I would like to avoid disjunctive predicates entirely but for 
> a different reason, as I suggested above.

I'm going to go out on a limb and suggest that a database without disjunctive predicates for relations is a database that satisfies both POOD and POFN. It seems to me that decomposition is only ever indicated when the original predicate is a disjunction.

For example, if a relation R {A, B, C}
can be decomposed into relations S {A, B} and T {A, C} then the predicate of R must be a disjunction of the predicates of S and T: Rabc = Sab \/ Tac where Sab and Tac are the predicates of S and T respectively. With just one inclusion dependency, say S[A] IN T[A]. the predicate of R must be something like Sab /\ Tac \/ ~Sab /\ Tac. With a cyclical inclusion dependency, S[A] = T[A], the predicate is no longer disjunctive: it's something like Sab /\ Tac, and that's a case where decomposition is contraindicated. Received on Fri Jun 20 2008 - 21:25:14 CEST