Re: Notions of Type

J M Davitt wrote:
> paul c wrote:

>> J M Davitt wrote:
>>
>>> David Cressey wrote:
>>>
>>>> "Marshall" <marshall.spight_at_gmail.com> wrote in message
>>>> news:1155833602.403082.5690_at_h48g2000cwc.googlegroups.com...
>>>>...

I'm also not sure if this is a digression, but it's interesting to me. Just to explain my use of it, I think I usually try to use the word 'relation' in this way: a value that happens to have a structure that is acceptable to the relational operators. This value is also immutable, to use a word that some people have been using in quite a different context lately. From the point of view of the dbms, all possible relations (values) always exist (but aren't necessarily used or stored).   What I understand of D&D is that they have this indirection device, a pointer called a relvar to allow references to certain of the relations/values and to indicate which relations/values we are interested in. So it's relvars that change, not relations.

For me, there is no difference between a relation and a relation value.   When somebody is defining a relation, manipulating the 'set of attributes' I can see that they have a different purpose in mind than when they are manipulating one but I don't think this matters because two different relations are involved. Put another way, a Data Definition Language is a convenience, it's not essential, as long as a header is a relation. (A dbms that supports transactions might take pains to prevent relvars that point to a header from being changed in the same transaction as relvars that refer to that header, but that's another topic.)

Now things get a little murky for me, but I'll try, please stop reading when it ceases to make sense, if it hasn't already! Others have read D&D more thoroughly than I but I think it's a twist to say that a set of attributes wouldn't be a relation value because assuming we're talking about a header, I think it could be as long as we assume a catalog that supplies a default name for the values of the names in a header's values.

(At first I thought BB might have been implying that 'set of attributes' is not appropriate lingo for the original question and that perhaps 'header relation' would be better for this purpose, except, maybe, for the fact that a header, D&D or otherwise, must be degree 2 - attribute name and domain.)

But if we don't assume a catalog, maybe you are right after all in saying that closure doesn't need both operands to be relations. I'd be just as happy if projection happened as several steps, perhaps the first one making a set out of operand 1's header and then intersecting that with the second operand's "set of attributes", although I know some people would prefer an exception if the second operand had an element value that wasn't in the first operand's header. Then the resulting set is treated as a header to identify the subset of attributes desired to be projected. Ie., I don't see anything wrong with a relational operator, project, depending on set operators. As you say, the result is still a relation.

p Received on Fri Aug 18 2006 - 07:27:27 CEST