Re: no names allowed, we serve types only

From: paul c <>
Date: Sun, 14 Feb 2010 18:40:34 GMT
Message-ID: <CsXdn.64868$Db2.44550_at_edtnps83>

Keith H Duggar wrote:
> Of course the conventional definition of a relation's header
> is a set of ordered pairs of "attributes" of the form <A, T>
> where A is the "name" of the attribute (which must be unique
> within the header) and T is a type.
> I'm wondering, do we really need A? Can we not simplify this
> header notion to just a set of types? All we need do then is
> supply operators to conveniently "copy" types if or when one
> needs multiples attributes of the "same" type. Often we don't
> even require this. Here are some examples:
> no type copy necessary if we already have unique types
> DateTime = {Date, Time}
> Inventory = {Supplier, Part, Integer}
> type copy used to generate unique types
> Point2D = {copy Integer X, copy Integer Y}
> So aren't the "ordered pair" and "attribute names" a perhaps
> sometimes convenient yet always unnecessary complication? We
> can do all we need to solely with types and sufficiently rich
> type systems. One nice result is that now a header is just a
> plain simple set without ordered pairs demanding an auxiliary
> uniqueness constraint on names across all the pairs. What are
> your thoughts?
Heh, good excuse to mention one of my favourite topics - transitive relations. I seem to remember that in the 1969 paper, Codd just used types without attribute names (though I think he called them domains just as Bertie Russell had). Then in the 1970 version he introduced attribute names. I thought his reason was to allow closures. I'm not quite clear how this "copy" enables closures. A transitive relation seems to need two sets of names or attributes, eg., in a family tree, an attribute that sometimes stands for "parent" or "child" at other times stands for "ancestor" or "descendant". I believe it's the case that the transitive relation implies the closure relation and vice versa. To put it another way, my guess is that attribute names were Codd's way of being able to depict both relations in one, avoiding recursive definitions. I realize this isn't a direct answer to the question. Received on Sun Feb 14 2010 - 19:40:34 CET

Original text of this message