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

From: Alexandr Savinov <>
Date: Tue, 07 Jun 2005 16:07:20 +0200
Message-ID: <42a5aa2b$>

Tony Andrews schrieb:
> Alexandr Savinov wrote:

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

> #1 is the right way
> #2 is the wrong way

We do not have here "wrong" or "right". It is a matter of fact: we can model things by using records and we can model things by using tables. When you say "wrong" you probably mean it is not desirable but you still do it! If you have tables in your model then you have some things represented by them! Any model is some thing existing in the problem domain.

When you say "wrong" then you contradict to another principle. You actually suggest to keep all data in one common table because you find it wrong to decompose schema and introduce more tables for special purposes. So again, entities can be represented by tables and vice versa one table represents one entity. It is not right or wrong, it is what we currently have.

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

> What would be the benefits of approach #2? The drawbacks are obvious
> enough. How would you express a relationship between departments with
> approach #2? Or associate employees with departments?

As I wrote approach #2 is already used in any model that has tables in it because any table represents some element of the problem domain. However, RM does not provide means for manipulating and representing data in this way so it is qualified as illegal procedure.

When you ask about benefits and indicate drawbacks then you are actually critisizing relational model. In other words, you came to the conclusion that RM does not allow us to deal with some entities such as those represented by tables. So you are right that it is difficult to represent relationships between departments in approach 2 but you need to address this question to those who is responsible for RM - not me! Because I know that it is a serious problem in RM (among others).

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

> I'm not sure what you mean by this. AFAIK it has always been the case
> that we would expect that the relational schema (metadata) would itself
> be defined in relations in the form of the "system catalog". No new
> theory is needed, since it is just another application of the
> relational model.

No, it is not another application. Schema with its information is an integral part of the model so it is the same application. If you have a data model and you define a couple of tables then you may ask a question what properites these tables have and where they are living actually. RM does not ask these questions and does not provide an answer. Schema (meta-data) is an integral part of database but on the other hand it is something completely different. What if you have meta-meta-data? What might be a solution.

Received on Tue Jun 07 2005 - 16:07:20 CEST

Original text of this message