Re: Columns without names
Date: Sun, 17 Sep 2006 23:15:53 GMT
Message-ID: <JGkPg.21838$9u.257263_at_ursa-nb00s0.nbnet.nb.ca>
JOG wrote:
> 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?
Stop and think about it for a minute. Is a set type generator any different from an array type generator or an interval type generator?
Nothing in the RM prohibits set types except as database variables. Sets, sequences, streams, etc. all have extremely useful values and operations. Received on Mon Sep 18 2006 - 01:15:53 CEST