Re: header part of the value?

From: Marshall <marshall.spight_at_gmail.com>
Date: Wed, 27 Feb 2008 19:08:37 -0800 (PST)
Message-ID: <69f11b9f-28a0-4c51-aae6-624baada5954_at_s12g2000prg.googlegroups.com>


Apparently some email communication has migrated to the newsgroups! I have no objection.

On Feb 27, 6:27 pm, Tegiri Nenashi <TegiriNena..._at_gmail.com> wrote:
> Marshall Spight wrote:
> > On Tue, Feb 26, 2008 at 10:44 AM, Tegiri Nenashi
> >> .... (The discussion motivated by constraint databases snipped)
> > Just as we could write:
>
> > x < 1 /\ y = a \/
> > x < 1 /\ y = b
>
> > could we not also write
>
> > x + 3 = y \/
> > x + 5 = y
>
> And also
> x + 3 < y \/
> x + 5 < y

Sure.

> >> On the side note (related to the recent c.d.t thread you started), the
> >> header with inequalities becomes something like
>
> >> {" =< x", "x <= "}
>
> >> In other words, one needs to specify a little bit more than just
> >> attribute names.
>
> > Hmmm. I don't see why one needs to specify more than attribute
> > names. I don't see the inequalities as being part of the *attribute
> > name*. Rather they are part of the relation value, aren't they?
>
> > I could see arguing for them as a separate constraint, though.
>
> Why? In your example:
>
> x + 3 = y \/
> x + 5 = y
>
> we extract the common part "x + ... = y" into a relation header (yes,
> it appeared that we need a meta variable which is distinct from
> attribute names x and y), and keep the constants in the relation body
> like this:
>
> x + ... = y
> -----------
> 3
> 5

Well ... okay. I see what you are doing, but I still don't see the motivation. It appears to me as if you are viewing the equation "x + 3 = y" as having 3 as the free variable, and x and y as constants! Whereas I would consider it much more natural to consider x and y as free variables, or parameters, or attribute names (they are all the same) and 3 and 5 as constants.

> >> Please note that you can't have overlapping intervals
> >> there. They collapse into a single interval much like duplicate tuples
> >> collapse into a single tuple with standard relations. For example, we
> >> can have
>
> >> x>= y<=
> >> --- ---
> >> 1 3
> >> 2 6
> >> 5 7
>
> >> Yet, if x and y are the same (that is we join it with the equality
> >> relation `x=y`), we'll get
>
> >> x>= x<=
> >> --- ---
> >> 1 7
>
> > That perspective seems odd to me. I don't understand
> > the motivation to have this proposal affect the headers
> > or attribute names.
>
> Well, in Date&Darwen&Lorentzos book there is a special operator
> calculating a cover of a system of intervals. In constrained
> relational databases this operation is natural. Although the example
> above is tricky, do we really equate attribute names, or values
> (whatever those values may be). Certainly, we don't naively try to
> equate the constants written in the table rows, because
>
> x>= y<=
> --- ---
> 1 3
> 2 6
> 5 7
>
> is differerent from
>
> x= y=
> --- ---
> 1 3
> 2 6
> 5 7

Sure ... but ...

In the previous email, I brought up the distinction between extensional relations and those that are algorithmically specified. I still see that as the better way to think of the distinction.

If I may select and project from your example, consider:

  x>=
  ---
  1

  2
  5

That to me seems to be simply a special case, that of the natural join of the following two relations (specified via comprehension)

  {(x, y) | x >= y}
and

  {(y) | y in {1, 2, 5}}

followed by the projection over x. For which there is no difficulty, neither mathematical, nor computational. It is easily implemented, I may add.

This operation, a natural join of an extensional relation against an algorithmic one, followed by projection over the non-joined columns, is exactly "partial application" in the functional programming
world.

Perhaps the issue is obscured by the fact that the various comparators are usually primitive? This is why I moved in the direction of examples
written against arbitrary f(x) and g(x). Did they make any sense?

Does my drawing a distinction between extensional relations and algorithmic ones make any sense?

> > Your specification of Q:
>
> > Q = {x < 1 /\ y = a \/ x < 2 /\ y = a}
>
> > Fully parethesized, that would be this, yes?
>
> > Q = {((x < 1) /\ (y = a)) \/ ((x < 2) /\ (y = a)}
>
> > That to me seems already identical to
>
> > Q = {((x < 2) /\ (y = a)}
>
> Yes, this is how the "duplicate" tuples (or should I better say
> redundant facts?) in the generalized constraint relations are reduced.
> This is generalization of duplicate tuple removal for ordinary
> relational model.

Yes.

Marshall Received on Thu Feb 28 2008 - 04:08:37 CET

Original text of this message