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

From: Alexandr Savinov <>
Date: Fri, 17 Jun 2005 13:39:27 +0200
Message-ID: <42b2b671$>

Jon Heggland schrieb:
> In article <42b2996c$>, 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.

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.

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

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. So it is a more complex problem (and very interesting one). In COM the model is represented as follows:

  / | | \
  \/ \/ \/
   \ | /

Top and Bottom are formally added. Here OE, ED and DM are independent because they do not have a common subtable (Bottom is empty). 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:

  / | | \
  \/ \/ \/

   |  \ /
   | ED-DM
   |   |


In this case we need some more efforts to infere something by propagating constraints but this case is precisely what is studied in COM and how COM views the data. Note that each item in ED is relationship instance connecting E and D while it is an object connected with objects from DM by means of hyper-hyperedge ED-DM.

In fact, the table ED-DM resolves the problem because it makes ED and DM dependent. Actually this table stores precisely the semantics we lost and the database lacked when it needed it for inference. It establishes a dependence between each fact that a manager is a head of department and each fact that employee works in a department. (I omitted other necessary tables like OE-ED but I hope you understand what I mean.)

Received on Fri Jun 17 2005 - 13:39:27 CEST

Original text of this message