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

Alexandr Savinov wrote:
> 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.

I mean it would be wrong to do so. You *cannot* and should not try to model things by using tables with no rows.

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

No, I don't suggest any such thing. I use different tables to record different *kinds* of proposition. I would *never*, as you propose, use different tables to represent single instances of the same kind of proposition.

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

And you think it should be legal because...?

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

No, *you* are the odd one out here, who for some reason thinks the RM should offer two different ways to achieve one thing, the second being your bizarre plan to create 1 table per fact.

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

Because RM is logical, not physical. It doesn't care where the data "lives".

Before embarking on this whole enterprise, have you actually studied the relational model in depth? I did see that in your references in one of your papers you listed only a 1970 paper by Codd. I think you really need to have a very thorough understanding of the relational model before you try to overthrow it, and I'm not convinced that you have that at the moment - I can't see how you could make some of the claims you do if you did! ;-) Received on Tue Jun 07 2005 - 18:28:39 CEST