Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

In article <42b2996c$1_at_news.fhg.de>, savinov_at_host.com says...
> Yes, I agree. If we have an interactivity then we can solve the problem
> by asking questions. But I meant that it is a problem when we design our
> database. At this moment the designer, if he wants to explain what the
> data means, has to correctly specify the structure of tables. As one
> extreme we can create a number of tables without any relationships where
> each query has to contain all instructions (declarative) for building
> the necessary result set. Another extreme is where all ambiguities are
> resolved by moving the relationships (joins) into the database where
> they have a persistent form and are a integral part of the database and
> data semantics. In this case all simple constraints (imposed on one
> table) can be formally correctly propagated for getting the result.

The RM provides formal guidelines for designing our databases--- normalisation. It is not a panacea, but it states clearly why some relvar designs are bad. Thus, it guides you towards the best position between extremes.

Am I to understand that you advocate the second extreme? If so, do you by "all ambiguities are resolved" mean that the "hypergraph" (the graph of "join paths"---I hope you understand what I mean) is reduced to an acyclic one, so that there is but one relationship between any pair of "objects"/values? I agree that this simplifies some things, but in my opinion you have lost *far* more than you have gained. Especially since you can achieve the very same convenience with views / canned queries and appropriate user interfaces using a relational database.

-- 
Jon