# Re: header part of the value?

Date: Sun, 24 Feb 2008 13:12:13 -0800 (PST)

Message-ID: <1d6e51c8-8c77-4ae1-8847-c0f357a3c5b8_at_d21g2000prf.googlegroups.com>

On Feb 24, 12:26 pm, JOG <j..._at_cs.nott.ac.uk> wrote:

> On Feb 24, 6:48 pm, Marshall <marshall.spi..._at_gmail.com> wrote:

*>
**> > Of course, that then leads me to think of a relation value
**> > as a <header, body> tuple.
**>
**> Woaaaah, hold on a tootin minute there cowboy...why would it lead you
**> to think that? Why is a db-relation value not merely a set of finite
**> partial functions (db-tuples), mapping attribute names onto values?
*

"body" = a set of finite partial functions f: a -> v "header" = the domain of f

I don't see any contradiction here.

> > (Let us omit column type

*> > information for the present discussion.) Then one imagines
**> > an updatable relation variable in a database as holding
**> > a value of this tuple type. BUT then we notice that we
**> > have this restriction that the header must not be updated.
**> > Why is that?
**>
**> Well, a relation variable is defined as representing (at any given
**> point in time) a value from a set of valid relations
*

Yes. (Although lately I like "bound to" better than "representing.")

*> lets call it V
*

> - as defined by the predicate and constraints.

Do we *have* to have a predicate? I say NO! The math doesn't change any. In fact the whole system gets simpler if we say that the predicate, which we usually think of as being a separate, required piece, is just another ordinary mundane run-of-the-mill constraint.

So: a relvar is a name bound to a relation value. Period. We might also have some constraints that reference that variable.

> So, for instance,

*> continuing the above example we had a relvar R, that had to match the
**> predicate P(x, y, z) and enforce the constraint that c is less than
**> 10
*

And then of course we could add more constraints, and/or drop either constraint.

Marshall Received on Sun Feb 24 2008 - 22:12:13 CET