Re: Relation Definition

>> It is simpeler. Date includes the typing information, the header, in the
>> value, the relation, that the type is supposed to describe. That makes
>> things unnecessarily complicated.

Reading down to the bottom of your post it seems to me like you are defining a relation value while Date's definition refers to a relvar, or a relation variable. If so, you can ignore the above since it makes sense to avoid the reference to typed attributes when talking about the instance of a tuple without a mapping function.

If it is not, then, how is the definition of a relation variable any useful, if one ignores the relevancy of type of an attribute value while defining it? At the practical level, isn't this an impetus for accommodating type-less markers as attribute values in a relation?

>> (1) What is exactly a "set of named typed attributes"?

Precisely, a set of attribute-type pair with a name. One might *loosely* view an attribute as a "named substitute" of a type in a relation header. Ignoring the reference to types in the relation header, one can even define an n-ary relation simply as a set of n-tuples, which is more or less equivalent to the mathematical definition.

>> (2) The notion of n-dimensional tuple is usually reserved for ordered
>> tuples which is not appropriate here.

Not sure in which context you are talking about dimensions here (vector space? N-space? ). Loosely, a tuple is n-dimensional if it has n attributes where n is finite. One might have a 0-dimensional tuple in a 0-ary or nullary relation, 1-dimensional tuple in an unary relation and so on.

Can you post a reference which suggests the relevance of the n-dimensional tuples is usually reserved for ordered tuples?

>> (3) It is not made precise what "corresponds to" means in the final
>> sentence.

Yes, I can see that & it was my mistake in paraphrasing the definition.

-- 
Anith