Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
Date: Fri, 17 Jun 2005 17:02:49 +0200
Jon Heggland schrieb:
> In article <42b2b671$1_at_news.fhg.de>, firstname.lastname@example.org 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?
We do not decompose anything. We simply build our model in a hierarchical manner. In particular, we do not know anything about universal realtion or its equivalent.
In other words, the main principle here is: position your tables vertically.
> Are these the levels you were talking about when you spoke of querying
> the data base at "different levels of detail"?
You can look at you organization from the point of view of employees. And the whole semantics will be propagated to this level and to this table. This is how modelling is done in COM.
>>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?
No. We do not decompose anything. Think of all the concepts here as normal tables. We create table O, then we create table E, then table OE and so on. We do not need to know anything about universal relation. The only thing we need to do consists in positioning the tables vertically as shown in the diagram (between top and bottom). As soon as you create a new table you need to position it somewhere in this diagram.
>>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?
Yes, independence of OE, ED and DM is the reason why we cannot make such an inference. Yet, we can make it possible if we assume something additional, for example, "having one common superconcept means their equality". In this case (Jon, D1) and (D1, Sally) will represent (Jon, D1, Sally). I do not know what is better so it is an open issue. May be we can make other explicit or implicit assumptions.
>>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?
If it exists then it will be used. If it does not exist then we need to make some implicit assumptions for answer the query. The table ED-DM plays the same role for ED and DM as DM plays for D and M.
> 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.
No. We do not create tables to answer queries. We create them in order to represent entities and relationships. We we need as many tables as are needed in the same RM. The difference is that they are positioned hierarchically and the data is interpeted differently. We use this hierarrchy to answer query and to interpret data.Received on Fri Jun 17 2005 - 17:02:49 CEST