Re: The Practical Benefits of the Relational Model

Paul Vernon wrote:

> "Leandro Guimarães Faria Corsetti Dutra" wrote in message
> news:aop8p1$ojl84$1_at_ID-148886.news.dfncis.de...
>

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

        None but that they should exist. There is no reason to attach a particular significance to the choice of domains and attributes names as an identifier for relvars, merely because relvars are a computer-implementable representation of predicates, and there can be more than one predicate with the same set of attributes.

        Thus, why should be ban two base relvars from having the same set of attribute names? Even because the choice of which are the base and which the derived relvars is arbitrary provided that the database has a complete, normalised representation of the data in question.

>> 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.

        Agreed. As in the example at hand.

> I'll admit that I've never built a major database explicitly
> following the rule that an attribute name implies it's domain. But
> I've not been able to think of a situation where I would want to
> break such a rule, so I would like to suggest that such a constraint
> should be mandated on any true RDBMS system catalog.

        I don't think so, unless as suggested by Codd. So we'd have something like lover.person, loved.person, hater.person and hated.person.

> Well I agree that language, and the English language being an
> allegally particularly difficult example, does not respond well to
> formal structuring. But noetheless, my point (or at least hope) is
> that, simple(ish) attribute names are enough for both users and the
> database to have the same understanding of predicates.

        I have to strongly disagree here. "The database" (do you mean database or DBMS here) certainly have no understanding of predicates, as it is not any kind of complete AI. Rather the database is a simplified representation of predicates, suitable for implementation in a DBMS that   is responsible for enforcing all associated integrity constraints.

        So I love meaningful names, but they are meaningful if I know English, and the DBMS certainly doesn't.

>> 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.

        I fear I miss you. You are talking about documentation for the user on what's the underlying predicate, I am talking about integrity constraints enforcement. East is east, West is west…

> Ad-hoc documentaion on predicates is no good if the DMBS cannot
> reason using it. My proposal is that attribute names are good enougth
> documentation of predicates.

        But it is precisely because "ad-hoc [¿natural language?] documentaion on predicates is no good if the DMBS cannot reason" that we need integrity constraints…

> I do appreciate that, but Chris did say that only "detail level
> corrections might be needed". So I feel it is ok to comment against
> the wider points of the article.

        Yet I do think you misunderstand them. They are talking about meaning as to be enforced by and documented in the system, not as in documentation and meaningful naming.

>> 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*.

        But then you'd need full AI. Nothing less would suffice.

        Unless I misunderstand you. Perhaps you have something in mind besides meaningful naming? Do you have something to substitute for, or facilitate in, declaratively defining integrity constraints?

>>> 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.

        _The one_ database. In TTM no RDBMS ever sees more than one database in any context.

> I think that the idea of what exactly consists one database is a
> outstanding issue. I like the concept of 'expressible databases'
> (which Chris mentions in passing in Intro to DB systems), and in fact
> one of my motivations here is to explore this concept more fully.

        I think you are reading too much into the expression "expressible". It means just all the possible representations of data as derived (expressible) relvars arising from a given set of base relvars that form a database as a starting point.

        For this use of "expressible", see Codd's original article.

>> What to you mean as "local relvars"?

        Hm, as I understand it your explanation on "local relvars" is more in line with "derived relvars". As I understand "application relvars", they are temporary relvars created for a specific session.

-- 
  _
/ \ 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