Re: header part of the value?(B

From: JOG(B <jog_at_cs.nott.ac.uk>
Date: Sun, 24 Feb 2008 16:28:57 -0800 (PST)
Message-ID: <28e335ae-156e-4747-b8c7-0b09a9641b7b_at_z17g2000hsg.googlegroups.com>


On Feb 24, 9:12 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
> 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

Ok, then if it helps forget functions, with their associated use and semantic connotations, merely view the db-tuples in my example as sets of ordered pairs. The first elements of said pairs appear to be role names and the second elements role values to us on the outside, but as far as the set theory is concerned they are both just common garden constants.

I'm not seeing the need for adding the extra 'header' component, and of course would refer to ol' occam as backup.

>
> 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 header just seems a superfluous structure to me atm. But then as you'll see below, I agree with everything else your saying, and I'm not sure headers are actually the major issue (I may be wrong of course).

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

How so?

Let me bend your ear for a minute and show you how I'd represent joins - given the representation I used in my examples, a natural join of R and S (using their lowercase equivalents to represent the tuples they possess) on attribute a, can be written set theoretically as:

Join(R,S) = { p: $B"P(Br$B":(BR, $B"P(Bs$B":(BS [ p=r$B"_at_(Bs $B"J(B $B"P(B(a,v)$B":(Br,s ] }

In fact I can generalize to a theta join by just generalizing the final clause in the set definition:

$B&((B-Join(R,S) = { p: $B"P(Br$B":(BR, $B"P(Bs$B":(BS [ p=r$B"_at_(Bs $B"J(B $B&((B(r,s) ] }

Clean, and purely set theoretic. I shoot... I score?

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

bound is good.

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

Aye, you picked the one I intended. It must be a residual V for Vendetta thing.

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

I too 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.

I utterly and totally agree. I actually doctored the example I gave in my last post from my own work, to separate out the 'predicate' from 'constraints' because I thought it would be a step too far from the normal view of predication cdt. In the original version there was no separation, and both were 'constraints'.

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

Sure but it is only required as part of the definition of the referring set of valid relation values no? As such it is still 'pinned' on one relvar (perhaps I've misunderstood what you were getting at though).

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

We are in dizzying accordance there.

> and/or drop either constraint.

Or do even crazier things like using disjunctive predicates, existential quantifiers for missing data, etc...

>
> Marshall
Received on Mon Feb 25 2008 - 01:28:57 CET

Original text of this message