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

Tony Andrews schrieb:

> Alexandr Savinov wrote:
> 

> 
> 
> Sorry if my negative predisposition is so obvious.  (I can't deny that
> I have it.)  However, I will try to understand...
> 
> 

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

-- 
alex
http://conceptoriented.com