Re: header part of the value?

On Feb 29, 1:23 am, Jan Hidders <hidd...@xxxxxxxxx> wrote:
On 29 feb, 08:02, Marshall <marshall.spi...@xxxxxxxxx> wrote:
On Feb 27, 11:56 pm, Jan Hidders <hidd...@xxxxxxxxx> wrote:
On 24 feb, 19:48, Marshall <marshall.spi...@xxxxxxxxx> 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.

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.

That is not correct. The natural join can be defined without referring
to the header.

I am skeptical, however my intuition is that we might not be
speaking the same language here.

Natural join is defined to be an equijoin on pairs of attributes
in each operand with the same name, yes?

Depends on your definition of equijoin. The natural join leaves only
one of the homonymous columns, equijoins do not under all definitions
do that.

Sure.


So how do you
know which attributes have the same name without access
to the header? How do you even know that there *are*
attributes, without the header?

Since we are working in the named perspective, they are included in
the tuples. I'm frankly a bit surprised that I have to point this out
to you. See the standard definitions in the Alice book.

This point was addressed earlier in the thread. My perspective
is that if you are going to say you can produce the header
by examining the tuples, and the tuples are part of the
relation, then if you have the tuples you have the header:
header-is-part-of-value.


Certainly in practice this is the sort of thing that would
be almost universally a good idea. But what theoretical
basis does it have?

Static typing goes out the window.

Yes, certainly; that bears mentioning. That doesn't change the
algebra at all, though, does it?

The standard relational algebra is essentially statically typed and
it's formal definition is based on that. If you drop that, you will
have to give new definitions that take into account that the headers
might not be what you expect. I would not call that "doesn't change at
all".

I suppose that's true. It is not true of the relational lattice
though.


Marshall
.

Relevant Pages

  • Re: TRUE and FALSE values in the relational lattice
    ... E * E: natural join ... the relation with empty header and a single empty tuple ... the equality relation with header ... So the syntax becomes: ...
    (comp.databases.theory)
  • Re: header part of the value?
    ... The natural join specification *requires* the header; ... Natural join is defined to be an equijoin on pairs of attributes ... Depends on your definition of equijoin. ... The standard relational algebra is essentially statically typed and ...
    (comp.databases.theory)
  • Re: header part of the value?
    ... Consider the algorithm to perform a natural join on two ... The natural join specification *requires* the header; ... (Let us omit column type ... a value of this tuple type. ...
    (comp.databases.theory)
  • Re: header part of the value?
    ... Just two plain relation ... The natural join specification *requires* the header; ...
    (comp.databases.theory)
  • Re: header part of the value?
    ... I've sided with the just-the-body approach, ... The natural join specification *requires* the header; ... much of the current interest in programming languages ...
    (comp.databases.theory)