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

In article <42a58ced$1_at_news.fhg.de>, savinov_at_host.com says...
> Tony Andrews schrieb:
> > 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.

No, it doesn't. The RM handles the case just fine, if you use it properly. This is not a limitation of the RM any more than it is a limitation of a shovel that it is really bad at digging if you hold it upside down.

> One solution is to connect them statically via your application.

Which defies the purpose of a DBMS.

> Another solutions is where
> you can store this information a table from #1 where one row represents
> one table.

I have trouble parsing this.

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

So you have added complexity, but not expressive power. That is what most "new" data models do. It is pointless.

> And again, the whole example
> demonstrates that tables should be legal element for use in representing
> data semantics.

No. It is not necessary.

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

Again, you introduce unnecessary complexity.

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

Why? What purpose does this serve?

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

No, tables (relvars) are not rows (tuples). A relvar can be *described* *using* tuples. This is very different.

-- 
Jon