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

From: Alexandr Savinov <>
Date: Tue, 07 Jun 2005 14:02:35 +0200
Message-ID: <42a58ced$>

Tony Andrews schrieb:

> Alexandr Savinov wrote:

>>Tony Andrews schrieb:
>>>Which part of the decomposition process reduces 1 row to 0 rows? I
>>>must have missed that part...
>>I'll try to exlain using another example (but I am not sure if it is
>>necessary taking into account your apriori negative predisposition).
> Sorry if my negative predisposition is so obvious.  (I can't deny that
> I have it.)  However, I will try to understand...

>>This example is especially illustrative for those who absolutely trusts RM.
>>How can you model a tree of items? There are two major alternatives:
>>1. Create a table with folders and a table with items. Each folder and
>>each item has a field which specifies its parent folder.
>>2. Craate one table for each folder and store all items belonging to
>>this folder in this table. There exist as many tables as we have folders.
>>Conclusion: This example demonstrates that tables have the same semantic
>>load as normal records, i.e., they should be treated not only as a
>>structural element but also as means for representing data semantics.
>>Addding/removing tables changes the model semantics rather than only its
> False: your alternative #2 does not represent the tree structure at
> all, it is just a bunch of unrelated tables, each of which contains
> some items.  Where did the folder tree structure go?  Try again!

Yes, you are right, we need to connect the tables so that each table known its parent table. But it does not change the point - it only even better demonstrates limitations of relational model. One solution is to connect them statically via your application. Another solutions is where you can store this information a table from #1 where one row represents one table. But do not say that #2 is now equivalent to #1. Because the main issue here is that for each row from Folder table there is one real table which contains a set of items. Now very important point (for the solution): if in case #1 each item specifies the parent folder by using some field, i.e., by using legal relational facility, then in #2 each item belongs to its folder (table) by using 'instance of' relation, i.e., it is a row in this table. Thus we use for data modeling two absolutely different types of relations. And again, the whole example demonstrates that tables should be legal element for use in representing data semantics.

Here is even simnpler example. Assume you have a number of departments. There is two ways how you can represent them: 1. As records in a table of departments
2. As individual tables (possibly with support from one common meta-table from #1 as you noticed because relational model does not
allow for tables to have fields and to be used as entities)

It is very general and wide spread trade off and it is important to recognize that there is such an alternative (but it is prohibited to think so in RM). Once you start a new model you need to decide what entities will be represented by tables. Normally these are special entities which have high level organizing role. Sometimes we can to keep them as normal tables without support. But in many cases we need to have additional properites and structure for them. In the latter case we also duplicate them as normal records in a (meta-)table. I can continue with advantages and disadvantages and analysis of properties but if you recognize this point as an alternative then you can do it easily yourself.

I return to the initial point: tables should be considered normal entities with special role and vice versa normal entities should be able to play a role of tables.

Another aspect of this problem. A schema is not part of the relational model but it is heavily used in complex applications. You know that any implementation has a table of tables and it is reflects the fact that tables are rows and have normal properties. Thus practice also confirms my hypothesis however currently there is no a data model (theory) for that.

Received on Tue Jun 07 2005 - 14:02:35 CEST

Original text of this message