Re: Guessing?

From: Brian Selzer <brian_at_selzer-software.com>
Date: Sun, 22 Jun 2008 11:09:33 -0400
Message-ID: <NWt7k.9428$xZ.2735@nlpi070.nbdc.sbc.com>

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:HTk7k.11571$mh5.9313_at_nlpi067.nbdc.sbc.com...
>
> "paul c" <toledobysea_at_ac.ooyah> wrote in message
> news:%yf7k.23319$Jx.3424_at_pd7urf1no...
>> Brian Selzer wrote:
>>> "paul c" <toledobysea_at_ac.ooyah> wrote in message
>> ...
>>>>> ... 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.
>>> ...
>>
>> One may choose one's starting point so as to conclude that it is
>> 'inescapable' (sorry, not trying to mimic Bob B's high tones), but I feel
>> that escape from this consequence is rather necessary!
>
> Why is it necessary?
>
>> (seems a pedantic consequence to me which usually signals to me that
>> something basic is just wrong, also I'm not saying I have the IQ
>> wherewithal to show how, but am wondering whether a more complete POOD
>> might argue that the presence of any non-disjunctive tuple in a db, no
>> matter whether it's in a base or 'virtual' relation, trumps any
>> disjunctive operator that might have produced/manifested it.)
>>
>
> Consider the following statements:
>
> 1. Susan is an electrical engineer.
> 2. Susan is a mechanical engineer.
> 3. Susan is an electrical engineer or Susan is a mechanical engineer.
>
> Now, suppose you have a base relation P whose members map to individuals
> that exemplify the property of being an electrical engineer, a base
> relation Q whose members map to individuals that exemplify the property of
> being a mechanical engineer, and a virtual relation (a view) R (P UNION Q)
> whose members map to individuals that exemplify either the property of
> being an electrical engineer or the property of being a mechanical
> engineer or both. The presence of a tuple in the virtual relation with a
> value that maps to Susan tells us only that Susan exists and that she is
> either an electrical engineer or a mechanical engineer or both. It does
> not tell us which. It is only the fact that the value that maps to Susan
> appears also in both of the base relations that tells us that in fact
> Susan is both an electrical engineer and a mechanical engineer. So here
> we have three relations, two base, one derived, that draw their values
> from the same domain, but it is where a particular value appears that
> imparts different aspects of meaning to that value. Note that there is no
> overlap in meaning for relations P and Q--even though they draw their
> values from the same domain: whether an individual is an electrical
> engineer or not has no bearing whatsoever on whether that individual is a
> mechanical engineer or not.
>

Where POOD comes in is if P and Q in addition to an attribute whose values map to individuals who can be an electrical engineer or a mechanical engineer respectively, have another attribute in common--say, for example, one that indicates that individual's sex. Now the predicates become something like:

Px \/ Rxy and
Qx \/ Rxy.

Which violates POOD. Decomposition produces:

R{X, Y}
P{X} P[X] IN R[X]
Q{X} Q[X] IN R[X]

Note that a relation with a predicate Px \/ Rxy cannot just be decomposed into relations
P{X} and R{X, Y} with predicates Px and Rxy respectively because the predicate
Px \/ Rxy requires that whenever there is an x, there must also be a y. Hence the inclusion dependency. Received on Sun Jun 22 2008 - 10:09:33 CDT

Original text of this message