header part of the value?

#21

Marshall wrote:

Quote:

On Feb 24, 12:26 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

On Feb 24, 6:48 pm, Marshall <marshall.spi... (AT) gmail (DOT) 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.

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

[snip]

Quote:

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

Quote:

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?

Quote:

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.

Quote:

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

Quote:

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.

And this has the effect of changing the declared data type of the variable.

#22

Marshall wrote:

Quote:

On Feb 24, 12:26 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

On Feb 24, 6:48 pm, Marshall <marshall.spi... (AT) gmail (DOT) 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.

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

[snip]

Quote:

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

Quote:

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?

Quote:

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.

Quote:

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

Quote:

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.

And this has the effect of changing the declared data type of the variable.

#23

Marshall wrote:

Quote:

On Feb 24, 12:26 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

On Feb 24, 6:48 pm, Marshall <marshall.spi... (AT) gmail (DOT) 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.

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

[snip]

Quote:

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

Quote:

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?

Quote:

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.

Quote:

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

Quote:

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.

And this has the effect of changing the declared data type of the variable.

#24

Marshall wrote:

Quote:

On Feb 24, 12:26 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

On Feb 24, 6:48 pm, Marshall <marshall.spi... (AT) gmail (DOT) 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.

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

[snip]

Quote:

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

Quote:

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?

Quote:

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.

Quote:

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

Quote:

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.

And this has the effect of changing the declared data type of the variable.

#25

Marshall wrote:

Quote:

On Feb 24, 12:26 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

On Feb 24, 6:48 pm, Marshall <marshall.spi... (AT) gmail (DOT) 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.

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

[snip]

Quote:

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

Quote:

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?

Quote:

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.

Quote:

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

Quote:

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.

And this has the effect of changing the declared data type of the variable.

#26

Marshall wrote:

Quote:

On Feb 24, 12:26 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

On Feb 24, 6:48 pm, Marshall <marshall.spi... (AT) gmail (DOT) 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.

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

[snip]

Quote:

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

Quote:

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?

Quote:

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.

Quote:

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

Quote:

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.

And this has the effect of changing the declared data type of the variable.

#27

Marshall wrote:

Quote:

On Feb 24, 12:26 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

On Feb 24, 6:48 pm, Marshall <marshall.spi... (AT) gmail (DOT) 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.

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

[snip]

Quote:

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

Quote:

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?

Quote:

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.

Quote:

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

Quote:

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.

And this has the effect of changing the declared data type of the variable.

#28

Marshall wrote:

Quote:

On Feb 24, 12:26 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

On Feb 24, 6:48 pm, Marshall <marshall.spi... (AT) gmail (DOT) 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.

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

[snip]

Quote:

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

Quote:

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?

Quote:

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.

Quote:

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

Quote:

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.

And this has the effect of changing the declared data type of the variable.

#29

On Feb 24, 9:12 pm, Marshall <marshall.spi... (AT) gmail (DOT) com> wrote:

Quote:

On Feb 24, 12:26 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

On Feb 24, 6:48 pm, Marshall <marshall.spi... (AT) gmail (DOT) 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.

Quote:

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

Quote:

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"@(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"@(Bs $B"J(B $B&((B(r,s) ] }

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

Quote:

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

Quote:

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.

Quote:

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

Quote:

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

Quote:

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

Quote:

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.

Quote:

and/or drop either constraint.

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

Quote:

Marshall

#30

On Feb 24, 9:12 pm, Marshall <marshall.spi... (AT) gmail (DOT) com> wrote:

Quote:

On Feb 24, 12:26 pm, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

On Feb 24, 6:48 pm, Marshall <marshall.spi... (AT) gmail (DOT) 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.

Quote:

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

Quote:

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"@(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"@(Bs $B"J(B $B&((B(r,s) ] }

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

Quote:

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

Quote:

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.

Quote:

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

Quote:

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

Quote:

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

Quote:

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.

Quote:

and/or drop either constraint.

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

Quote:

Marshall