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

Alexandr Savinov wrote:
> 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's what I can conclude from the above: 1. We have two relational database designs that accomplish the same thing
2. #2 requires an additional relation to identify the various folders (each of which is a separate table) as folders - this relation is never detailed
3. There's no inherent advantage to #2 (that I can identify) 4. #2 requires more work

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

No, it's not. You CAN define a separate relation for each department - for example, DEPATMENT_01, DEPARTMENT_02, etc. What I think you're arguing for is multi-values, as in Pick. We've had that discussion before, but in short, if you really want to store a list in an attribute, you can. You just can't expect an RDBMS to know how to cope with it, apart from operations you define over it.

But again, if you want to query the "contents" of several departments, you now need to include some other relation, even if it's a sort of catalog relation. None of the above looks in the least appealing to me, and you've yet to identify the benefit.

> 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 see no advantages - can you enumerate them?

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

And you've still given no reasons for this. Your examples show relational doing it more simply, and yielding a result with more general power.

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

Nor does there need to be, although a common model would be nice. It's fairly simple (and most DBMS vendors do it for SQL) to define "system catalog" relations that allow you to use the full relational operators on your database (which could have constraints you define - for example, to control naming, enforce patterns, etc). This would be simply a relational database design, not an extension of the theory.

• Eric