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

In article <42a5bac9$1_at_news.fhg.de>, savinov_at_host.com says...
> Jon Heggland schrieb:
> > In that case, you are using the rows in the "system table register"
> > table for your information; the actual tables you create and drop are
> > just irrelevant side effects -- you don't use them for anything at all.
>
> Yes, these are side effects if we are not going to insert any rows into
> those system table rows.

You are not making sense. In the RM, we do not insert rows into rows. (Well, it is possible to have tuple-valued attributes, but I don't think that is what you are talking about.)

> But this example was used to demonstrate that
> tables are used to represent some entities from the problem domain and
> in this sense it is possible to model the problem domain by using
> tables.

"Entity" is a very informal concept. Whether something is regarded as an "entity" or not depends on the viewpoint. A relvar may be considered as an entity, but it is not very useful to do so when your other entities are departments, employees and managers and such -- it mixes perspectives best kept separate. This is conceptual/semantic modelling, which is more of an art than a science.

> The fact that tables are normally used to include records while
> records are normally used to include fields simply emphasizes their
> special use. In general case any entity has two aspects:
>
> - it can be viewed as a collection of other entities (collection here
> means formally logical sum or a set normally designated as {}),
>
> - it can be viewed as a combination of other entities (combination here
> means formally logical product designated as <>).

This makes no sense to me. Is an entity in your world a boolean expression?

> - we can define an entity as a collection of other entities

Can we? That is a recursive definition. Where does it end?

> (let's call
> it 'instance of' relation between a table and its member). In this case
> the members physically belong to the collection.

Physically? What do you mean by that?

> - we can use a relation between an object and its value. In this case
> the record logically belongs to its values (other records), for example,
> a record <1, 5, 10> belongs to 1, to 5 and to 10 simultaniously.

What does "logically belongs" mean? Is "record", "object" and "entity" the same in your terminology? Are 1, 5 and 10 also records/objects/entities? Or values? What do they "logically belong" to?

> In relational model tables are simply containers (collection of other
> entities) and it is impossible to directly define new properties for
> them.

Is that a problem? Why?

> Records are simply objects (combinations of other entities) and we
> cannot add records to records.

"Record" is not a RM term. Do you mean tuples (rows)? If so, in what sense is a tuple a combination of other tuples? And why, if this is true in your world, can't we add tuples to tuples? I must admit I am on the verge of invoking Date's incoherence principle here.

> And such a definition is really effective
> and covers a huge number of situations. However, the question was how
> can we treat tables as entities and can they be treated as entities at
> all.

Before we answer that, we should ask ourselves what the purpose of such treatment would be. Of course, the catalog in a database treats the tables as entities, but I don't think that is what you mean.

> > Alternatively, if the "system table register" is not organized as a
> > relational table, you are no longer using the relational model, and the
> > whole point is lost.
>
> As far as I understand the relational model does not use any system
> table or a table of tables - it is how RDBMSs are implemented.
> Relational model works independently of how this meta information is
> stored and if it exists at all.

It must of course exist in a real implementation. But I agree that it has little relevance when discussing how the RM works. My point was just that the "empty tables" approach to modelling is faulty -- an empty table does not contain any information (except its "closed world assumption" interpretation, but that is of limited use in such circumstances).

-- 
Jon