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

In article <42b2b671$1_at_news.fhg.de>, savinov_at_host.com says...
> > 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.
>
> Yes, normalization in the RM is a mechanism to bring an order into a
> flat set of tables. If you like you can view COM as one special way of
> normalization - a kind of hierarchical multidimensional normal form. But
> it requires chaning you view of data and its semantics.

It seems I can view COM as the universal relation, decomposed in several levels from bottom to top---is that it?

Are these the levels you were talking about when you spoke of querying the data base at "different levels of detail"?

> Removing cycles in the hypergraph does not solve the problem It sovles
> it for only one case and using at least one additional assumption. The
> hypergraph representation itself is a particular case. Consider the case
> where edges of the hypergraph themselves are dependent (have an edge
> between them) - it is a hyper-hypergraph.

How is this possible? I am not particularly familiar with hypergraphs, but based on Ullman's slides, that does not make sense to me.

> So it is a more complex
> problem (and very interesting one). In COM the model is represented as
> follows:
>
> Top
> / | | \
> O E D M
> \/ \/ \/
> OE ED DM
> \ | /
> Bottom

Is O the projection of OE over O and so on? In other words, is this a stepwise decomposition of the UR?

> Top and Bottom are formally added. Here OE, ED and DM are independent
> because they do not have a common subtable (Bottom is empty).

Therefore, you cannot query the database about which employees are managed by Sally, even though (Jon, D1) and (D1, Sally) are rows in the ED and DM tables, respectively?

> We have 4
> nodes and edges in the hypergraph. In general case the model has more
> levels and ED and DM might be dependent by having a common subtable:
>
> Top
> / | | \
> O E D M
> \/ \/ \/
> OE ED DM
> | \ /
> | ED-DM
> | |
> Bottom

And this ED-DM table is needed to answer the query?

It seems very clear to me now that your model is more complicated than the RM, despite your claims of simplicity. You need another subtable to be able to ask about offices and departments, and yet another to ask about offices and managers. With more supertables at the top, isn't this a geometrical progression in the number of table? No wonder you are talking about thousands of tables. While the RM does this with three tables (or less, depending on functional dependencies), and you can ask it about anything that can be deduced from them.

So a far more complicated database with far more structures and mechanisms, and less ability to derive knowledge from it. And for what? The ability to state some queries more simply.

I'll let you have the last word if you like, but I am quitting this thread. It takes more time than it is worth.

-- 
Jon