Re: header part of the value?

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.

Or maybe it would be better if I said Relation is an ADT with a way to extract a header from it. Just because I say <header, body> doesn't mean there's physical memory dedicated to the header. <header, body> is a possrep, not a C struct.

The point that changed my thinking was the realization that there is no way to write natural join without a way to extract the header from the operands.

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

Let's call *what* V? You used three things that start with v in that sentence. I guess you mean the "set of valid relations."

> - as defined by the predicate and constraints.

Yeah, that's what I'm proposing thinking of differently. *Why* is the predicate not itself a constraint? We don't *have* to have any constraints--the constraint set could be empty.

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.

(Another point: constraints cannot always be pinned on a particular variable, no more so than a method can always be pinned on a particular OOP class. Same problem. A foreign key constraint for example is a constraint on *two* relations.)

> 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

What if we change that to:

"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)"

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