# Re: header part of the value?

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

{(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