Re: Little question for RDM theoristes

From: Marshall <>
Date: 16 Jun 2006 08:44:53 -0700
Message-ID: <>

U-gene wrote:
> Two relations (relvalues) exists. These relations have different
> headers (schemas). Are these relvalues the values of different types?

The type *relation* is a generic type. That is, it is an abstract (uninstantiable) type that is parameterized by other types. (We also have parameterization by attribute names in this case.)

The two relations you mention above have the same generic type, relation, but different specific types, in that the relation type has different parameters.

So the answer to your question is "yes and no." :-)

> IMHO all relvalues have the same type and the headers is just data.

The "header" (I don't like that term much) isn't "just" data. It's metadata; that is, it is known statically and potentially subject to static analysis. The "rows" of the relation are *not* subject to static analysis, because they are not static values. (Speaking from a programming languages perspective.)

This situation is blurred somewhat by the fact that most DBMSs have highly dynamic, reflective behavior. You can query the schema at runtime. Note, however, that this is not a requirement of the RM. You could build a perfectly usable, useful programming language with natural join, etc., that was fully static, with no facilities for getting schema information at runtime. Indeed, such a system could completely discard metadata prior to runtime.

(The reflective system which didn't do that would probably be more useful, but this utility is not free nor required. Still, I'd prefer to use the reflective system.)

> May
> be it is special kind of data which is different from rel.bodies' data.
> . But persons exist who think in other way - if relvalues have
> different headers they are values of different types. So I'll glag to
> hear your opinions.

This isn't so much a matter of opinion as it is a matter of a specific choice for the definition of "type."

Marshall Received on Fri Jun 16 2006 - 17:44:53 CEST

Original text of this message