Re: The Practical Benefits of the Relational Model

Paul Vernon wrote:
>
> In particular if we assume that relvar names are simply short
> cuts for the set of attribute names in a relvar, and therefore relvar names
> are strictly optional, then it should *not be possible* to create two
> relvars in a database with the same set of attribute names. (BTW I've
> assumed that: attribute_name -> attribute_data_type).

        Actually that is a big "if". Why "relvar names are simply shortcuts of the set of attribute names"?

        I assume you are thinking base relvars, because this sure wouldn't make any sense about derived relvars.

        Finally, *usually* an attribute name will be its domain name, but from Codd's first paper it is clear that a relvar header can have the same domain twice, and then their names must be different.

> In other words I say that it *is* the names that have meaning (contrary to
> what D&D say in TTM).

        Meaning to the user, sure. But surely you don't want to name your relvars, attributes, domains and constraints with long-winded, full explanations. So we settle for at most two or three words, and perhaps some of them abbreviated. Therefore, we need external documentation or internal comments on names to know the real meaning.

        Now, what Date & McGoveran are worried about in their article is meaning that can be structurally captured thru relvars and their domains, and thru associated integrity constraints. As they rightly point, this is just an approximation for the system's use.

> Why appeal to some external meaning that we don't
> even try to capture in the database - thereby breaking the Information
> Principle? I'd agree that external predicates read better than a
> conjunction of attribute names, but they should not actually add any extra
> 'meaning'.

        I don't understand. What do you propose to substitute for documentation on predicates? What does that have to do with the Information Principle? How could you document a predicate in the database, except for the catalog and comments on it?

> In the article, Chris & David suggest that they are trying to insert tuples
> that have no attibute names into the database. This is wrong. What they
> should be inserting are tuples such as:
> <LOVER: Romeo, LOVEE: Juilet>
>
> then with sensible relvar attribute names, e.g. (LOVER & LOVEE) and (HATER &
> HATEE), there is not need to talk about external meanings that are not known
> to the DBMS.

        Remember the article is old, therefore they used SQL notation. But I agree that sensible relvar attribute names are a big part of the solution for the meaning problem, *for the user*. But the focus of the article is on the meaning *for the system*.

        BTW, the system knows nothing about the user-intended meaning of LOVER, LOVEE, HATER, HATEE. Probably the article should be revised to make all that clearer.

> Now it might be a bit of a pain to have a RDBMS that did not allow two
> tables to have the same attribute names (and types) in the same *database*,

        Remember that the database concept in TTM is much more strict. Basically, everything that can be seen by the system must be regarded as a database, regardless of complications as namespaces or distribution.

> but frankly I could live with such a restriction if it enforced the
> Orthogonal Design Principle (and if any local relvars we not seen as part of
> the main database)

        What to you mean as "local relvars"?

-- 
  _
/ \ Leandro Guimarães Faria Corsetti Dutra        +41 (21) 216 15 93
\ / http://homepage.mac.com./leandrod/        fax +41 (21) 216 19 04
  X  http://tutoriald.sourceforge.net./      Orange Communications CH
/ \ Campanha fita ASCII, contra correio HTML      +41 (21) 644 23 01