Re: Relation Definition

From: Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be>
Date: Sun, 20 Feb 2005 11:22:29 GMT
Message-ID: <Vp_Rd.16147$rG1.1249419_at_phobos.telenet-ops.be>


Anith Sen wrote:
> Jan,
>

>>>For the authorative ones that real database theorists use see the 
>>>definitions in the Alice book:

>
> I apologize if I missed the obvious. But where in the Alice book did you
> find the definition you just stated?

Their definition of an instance of a header in the named perspective is equivalent with mine in the sense that every instance of a database schema is a relation as I defined it and vice versa. Note, btw, that I used the words "goes roughly something like" and not "appears verbatim in". But I'm pretty confident that Serge Abiteboul et al. would approve of my rephrasing of their definition.

>>>No. Of all the formal definitions of the relational model I have seen his 
>>>is probably the clumsiest.

>
> In what way does your definition any less clumsy than what is in Date's
> book?

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. Unless you are describing a system with run-time typing there is no real need to includes types in values.

> Date defines a relation as having a header consisting of a set of n
> named, typed attributes and set of n-dimensional tuples where each dimension
> value of the tuple corresponds to a named, typed attribute.

That definition is problematic for several reasons: (1) What is exactly a "set of named typed attributes"? Is it a set of attribut names together with a function that associates them with types? Or is it just a set of attribute names and is their association with types postulated before this definition? The difference matters. (2) The notion of n-dimensional tuple is usually reserved for ordered tuples which is not appropriate here. (3) It is not made precise what "corresponds to" means in the final sentence. One would expect that the definition is extended with a function that maps the numbers 1 through n to an attribute in the header such the i'th dimensional value of the tupel is of the type that is associated with it in the header.

> [...] Given Date has an entire career explaining how theory
> can be practical and his explanations occasionally informal, I see nothing
> clumsy in his definition.

You're entitle to your opinion. Chris Date is truly excellent when it comes to explaining stuff at undergraduate level, but I wouldn't dream of using his books for advanced database theory courses.

> Meanwhile, I can see you ignored the typed perspective altogether though.

Indeed. That is by design. This should not be defined in the notion of relation but in the notions of relation types and the relationship them and relations:

Def. [Relation type] A *relation type* is a partial function that maps column names to domains and is defined for a finite set of column names.

Def. [Instance] A *relation is an instance of a relation type* if it holds for all tuples in the relation that (1) they are defined for the same set of column names as the relation type and (2) they associate column names with an element of the domain that the relation type associates it with.

  • Jan Hidders
Received on Sun Feb 20 2005 - 12:22:29 CET

Original text of this message