Re: Columns without names

Nice responses. I gladly concede that there is no fundamental difference with '7' and 'b', as there is with any other label or name.

Marshall wrote:
>[snip]
> But elsewhere in the post, I note you said "[when]
> considering domain-defining statements ..."
>
> If you're going where I think you're going, then I would
> propose that it is better *not* to think of domain
> definitions as being relations.

Aye that's exactly where I was going - exploring the possibiility of single column 'domain' relations with no column name, or perhaps simply 'value'.

> What works better, as
> best I can tell, is to consider them simple sets.
> Then the entire issue of attribute names doesn't
> arise, which makes sense since for an application
> (domain definition) where we only ever have unary
> relations, attribute names is unneccessary. In
> fact, the relational operators on unary relations
> behave like (non-relational) set operators: join
> is like intersection, etc.
>
> So instead of thinking of the set of natural numbers
> as { (0), (1), (2), ... } we think of it as { 0, 1, 2 ...}
> which is simpler and makes more sense. I would
> say that 7 is not a proposition; 7 is a value. When
> we put it in the context of a predicate, it gains
> meaning. So in the context of the predicate
> "The old lady across the street has X cats",
> the relation, (X=7) is a proposition, but 7
> by itself, with no context, is a simple value.
>
>
> Marshall

Okay, I've convinced myself that using a relation to represent a collection of elements, that another relation attribute may refer to as its domain is probably a mistake, and a domain should be defined as it is mathematically - simply as a set of naked elements, and not as singleton tuples.

However AFAIK the relational model offers no scope for defining such things. Is this an omission or something orthogonal to relational theory itself, that one relies on any implementation to handle? Received on Sun Sep 17 2006 - 23:43:00 CEST