Re: Principle of Orthogonal Design
Date: Fri, 08 Feb 2008 00:17:32 GMT
Message-ID: <wcNqj.7545$0o7.4282_at_newssvr13.news.prodigy.net>
"Marshall" <marshall.spight_at_gmail.com> wrote in message news:36ccc828-188e-44bc-81ff-42758c5eb370_at_q21g2000hsa.googlegroups.com...
> On Feb 7, 3:21 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>> "Marshall" <marshall.spi..._at_gmail.com> wrote in message
>>
>> news:108e169d-a906-4818-a83f-42c1e11a85d1_at_1g2000hsl.googlegroups.com...
>>
>>
>>
>> > On Feb 5, 1:54 pm, Jan Hidders <hidd..._at_gmail.com> wrote:
>> >> On 5 feb, 22:06, Marshall <marshall.spi..._at_gmail.com> wrote:
>>
>> >> > However, suppose we have a binary predicate P over
>> >> > domain X and we want to assert it is reflexive? In predicate
>> >> > logic we can use the same name twice and express this
>> >> > very conveniently:
>>
>> >> > Ax in X: P(x,x)
>>
>> >> > How would we do this if P's attributes were already bound
>> >> > to the names "x" and "y"?
>>
>> >> Roughly the same, except you indicate the role in the predicate with
>> >> the attribute names. So assume that attribute names are 'a' and 'b':
>>
>> >> Ax in X: P(a=x,b=x)
>>
>> > I see. Okay, this is a very small change indeed. Basically we
>> > are just specifying attributes using the same syntax as is
>> > used in named-argument function invocation, in languages
>> > that support that feature. This still relies on using the
>> > quantifiers to introduce new names. And the attribute
>> > names of different relations are always insulated from
>> > each other: a relation may be in the scope of a quantifier,
>> > but it is never in the scope of another relation.
>>
>> > This seems like it will work as a logical language (where
>> > the results are always boolean) but I don't see how it
>> > could work in a query language, because it doesn't
>> > specify/unify the attribute names of the result relation.
>>
>> > An example:
>>
>> > Suppose we have
>> > P(a, b)
>> > Q(a, b)
>> > as subsets of X*X
>>
>> > and we want to join P and Q on P.b = Q.a.
>>
>> > Ax in X: Ey in X: Ez in X: P(a=y, b=x) & Q(a=x, b=z)
>>
>> > I guess I should go read about the tuple relational calculus
>> > and see what it does...
>>
>> > Marshall
>>
>> I'm confused, Marshall. Isn't
>>
>> Ex Ey x in X /\ y in X /\ (P(a=x,b=y) \/ Q(a=x,b=y))
>>
>> the extension of the database containing P and Q?
> > I guess we have to be careful about what formal system > we are speaking of. In predicate logic, (which the above > looks like, but maybe isn't what you meant) everything > evaluates to a boolean. As I read it, the above would > return true iff at least one of P, Q is not empty. > >
>> And isn't
>>
>> Ex Ey x in X /\ y in X /\ (P(a=x,b=y) /\ Q(a=x,b=y))
>>
>> the natural join of P and Q?
> > Well, I guess I have to know what the quantifiers return > if it isn't booleans. This is sorta my fault really ... >
The first sentence,
Ex Ey x in X /\ y in X /\ (P(a=x,b=y) \/ Q(a=x,b=y))
extends to be two sets of pairs of X values, which can be represented as relations having predicates P and Q respectively.
The second sentence,
Ex Ey x in X /\ y in X /\ (P(a=x,b=y) /\ Q(a=x,b=y))
extends to be a single set of pairs of X values containing those combinations that satisfy both P and Q. This could be represented as a single relation.
The third sentence,
Ex Ey x in X /\ y in X /\ (P(a=x,b=y) /\ Q(a=y,b=x))
which you didn't include, was a mistake on my part, since it wasn't the join of P and Q on P.b = Q.a, but rather the join of P and Q on P.b = Q.a /and/ P.a = Q.b, and extends to be a single set of pairs of X values as specified by (P(a=x,b=y) /\ Q(a=y,b=x)).
Obviously, to join only on P.b = Q.a there would need to be a third quantifier, but I don't think a universal quantifier is indicated:
Ex Ey Ez x in X /\ y in X /\ z in X /\ (P(a=x,b=y) /\ Q(a=y,b=z))
extends to be a single set of triples of X values containing those combinations that satisfy both P and Q as specified by (P(a=x,b=y) /\ Q(a=y,b=z)).
It should be noted that the extensions of these sentences are ordered pairs or triples, so some conversion (naming) would have to occur in order for them to be represented as database relations.
>
> Marshall
Received on Fri Feb 08 2008 - 01:17:32 CET