Re: header part of the value?

From: Bob Badour <>
Date: Sun, 24 Feb 2008 17:59:44 -0400
Message-ID: <47c1e8d4$0$4038$>

Marshall wrote:

> On Feb 24, 12:26 pm, JOG <> wrote:

>>On Feb 24, 6:48 pm, Marshall <> 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.

Isn't that like saying there is no way to write multiplication without a way to extract the digits from the operands?


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

Given specialization by constraint, the only data type for which that is true is the universal supertype.

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

And given specialization by constraint, that is synonymous with saying the data type is important. What is the data type if not the predicate?

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

Which is synonymous with the variable having a declared data type.

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

Two relation variables but a single database 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

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

And this has the effect of changing the declared data type of the variable. Received on Sun Feb 24 2008 - 22:59:44 CET

Original text of this message