Re: header part of the value?(B

From: JOG(B <jog_at_cs.nott.ac.uk>
Date: Sun, 24 Feb 2008 12:26:36 -0800 (PST)
Message-ID: <276265f0-8e50-4260-9eb4-4acd2619387b_at_j28g2000hsj.googlegroups.com>


On Feb 24, 6:48 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
> Occasionally the question has come up as to whether a
> relation value is the body, or the body+the header. In the past
> I've sided with the just-the-body approach, but today I decided
> that I don't think that anymore.

Oh eck.

>
> Consider the algorithm to perform a natural join on two
> relation values. Just values: not tables in a database
> with a known schema or whatever. Just two plain relation
> values. The natural join specification *requires* the header;
> it is defined (in part) in terms of the header. So the header
> must be part of the value.

So far so good. All makes sense.

>
> 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? We've broadly agreed in another thread that functions can be represented themselves as mathematical relations, so let us represent an example ternary relation-value, without a header component in sight:

{
{ (a, x1), (b, y1), (c, z1) } ,
{ (a, x2), (b, y2), (c, z2) } ,

...
{ (a, xn), (b, yn), (c, zn) }
}

No probs there right?

> (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 - lets call it V - as defined by the predicate and constraints. 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'd have:

R(t) $B":(B V

where:

V = { v : $B"O(Bf $B":(B v [ f = { (a,x), (b,y), (c,z) } $B"J(B P(x,y,z) $B"J(B z<10 ] }

or generally
V = { v : $B"O(Bf $B":(B v [ a correctly formed tuple, predicate fulfilled and constraints upheld] }

I'm not sure we need anything more than that. When we try and make an update, the model checks that the relation value we are suggesting does exist in V. If it does R(t+1) becomes the new value, and if it doesn't, we are returned a "looks like you've made a mistake" error.

Least that's how I see the mathematical situation after Codd incorporated attribute names into the mix (we don't need no steenking heea-ders, speedy gonzales). Regards, Jim.

>
> Certainly in practice this is the sort of thing that would
> be almost universally a good idea. But what theoretical
> basis does it have? I can think of none. So I propose,
> for your amusement, the mental model that a relation
> variable is merely a simple binding from a name to a
> <header, body> relation value, period, full stop. Also,
> *customarily* the variable has the update constraint
> that old.header = new.header.
>
> Marshall
Received on Sun Feb 24 2008 - 21:26:36 CET

Original text of this message