Re: Columns without names

Bob Badour wrote:
> 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.

Yes, I understand that a set is a valid type within a relation, but that's tangential to the point I was trying to make. Either I was ambiguous, or you've missed my gist. Let me explain what I was getting at better:

Given RM is built upon set theory, and not the other way around, it assumes the a priori existence of a set concept external to that of a relation (a relation of course being defined as a subset of the cross product of n sets, and the enumeration of those sets being the domain for a specific attribute of any tuple). Now Codd correctly recognized this, and the existence of sets is a given in Relational Theory, as they are the method that domains are specified.

However the Relational Model does not AFAIK specify the requirement of a set construct in any implementation of it - just a relation, despite the fact that the latter is derived from the former. Implementations I deal with certainly don't offer me support for user-defined domains, and I do not have a tool to define the fundamental construct used by the model.

Now I can simulate this functionality by mimicking domain sets, by creating a relation with a single attribute 'value'. Then on any insertion or update into any relation that has an attribute based upon this domain set, I can specify a constraint that joins via that attribute. If an empty relation results, the insert/update fails. This, however, is somewhat of a kludge. Received on Mon Sep 18 2006 - 02:24:10 CEST