header part of the value?

#41

On Feb 25, 5:26 am, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

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

What if the relation has no tuples?

#42

On Feb 25, 5:26 am, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

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

What if the relation has no tuples?

#43

On Feb 25, 5:26 am, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

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

What if the relation has no tuples?

#44

On Feb 25, 5:26 am, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

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

What if the relation has no tuples?

#45

On Feb 25, 5:26 am, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

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

What if the relation has no tuples?

#46

On Feb 25, 5:26 am, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

Quote:

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

What if the relation has no tuples?

#47

On Feb 25, 8:12 am, David BL <davi... (AT) iinet (DOT) net.au> wrote:

Quote:

On Feb 25, 5:26 am, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

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

What if the relation has no tuples?

Then the value bound to the relvar would be the empty set.

#48

On Feb 25, 8:12 am, David BL <davi... (AT) iinet (DOT) net.au> wrote:

Quote:

On Feb 25, 5:26 am, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

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

What if the relation has no tuples?

Then the value bound to the relvar would be the empty set.

#49

On Feb 25, 8:12 am, David BL <davi... (AT) iinet (DOT) net.au> wrote:

Quote:

On Feb 25, 5:26 am, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

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

What if the relation has no tuples?

Then the value bound to the relvar would be the empty set.

#50

On Feb 25, 8:12 am, David BL <davi... (AT) iinet (DOT) net.au> wrote:

Quote:

On Feb 25, 5:26 am, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:

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

What if the relation has no tuples?

Then the value bound to the relvar would be the empty set.