Re: Principle of Orthogonal Design
Date: Thu, 7 Feb 2008 04:14:45 -0800 (PST)
Message-ID: <5f812699-42cc-431f-aa69-4e8a801844e8_at_s8g2000prg.googlegroups.com>
On Feb 7, 8:21 pm, "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? 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? So wouldn't
>
> Ex Ey x in X /\ y in X /\ (P(a=x,b=y) /\ Q(a=y,b=x))
>
> be the join of P and Q on P.b = Q.a?
>
> Why should the extra quantifier be needed? And why should it be universal?
> A join is not a constraint, is it?
What happened to variable 'z'?
In order to get attributes x,y,z in the query result I don't think there should be any quantifiers at all. If you want to project a variable away from the query result then it should be existentially quantified. Received on Thu Feb 07 2008 - 13:14:45 CET