# Re: header part of the value?

From: Marshall <marshall.spight_at_gmail.com>
Date: Sun, 24 Feb 2008 13:12:13 -0800 (PST)

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

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

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, 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

"we had a relvar R, that had to enforce the constraints 1) that c is less than 10 and 2) R has the predicate P(x, y, z)"

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

Original text of this message