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

From: Jon Heggland <heggland_at_idi.ntnu.no>
Date: Tue, 7 Jun 2005 19:04:08 +0200
Message-ID: <MPG.1d0fedec11b23450989686_at_news.ntnu.no>


In article <42a5bf13$1_at_news.fhg.de>, savinov_at_host.com says...
> Jon Heggland schrieb:
> >>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.
>
> I did not describe any data model here - you try to see an evil where it
> does not exist.

You described a strange way of representing some information in the RM; it was noted that it didn't capture all the essential information, and you introduced some vague functionality to remedy this -- which I interpreted as non-relational. RM + new structures/operators = new data model.

> I provided a couple of examples and a couple of
> alternative designs and interpreations with the purpose to demonstrate
> that tables can be viewed as entities - that is all.

Tables are viewed as entities in the database's catalog. I'm sorry, what is your point again?

> >>And again, the whole example
> >>demonstrates that tables should be legal element for use in representing
> >>data semantics.
> >
> > No. It is not necessary.
>
> So why you represent real entities from your problem domain by tables?
> Again, it is not a matter of necessity, right or wrong.

I disagree, if we are talking about the qualities of data models. A data model should contain only necessary and sufficient functionality.

> Whenever you create a table you want it to represent some entity.

Actually, I want it to record facts (propositions). "Entities" is a too fuzzy and informal concept for me.

> If you define
> tables Departments, Products and Personel then you defined three kinds
> of entities and your model consists of three elements already! And you
> are saying it is not necessary.

No, of course these relvars are necessary. What is *not* necessary is structure and operators to enable you to represent each department as a table with no rows, and still be able to assign personnel to departments in a proper manner.

> What is not necessary, representing the
> state of data in the database? I do not understand. The initial point
> was that tables represent real entities even if you do not like that.

I prefer the view that relvars contain true propositions about the real world. What *is* a "real entity"? It depends---hence it is a concept of limited use in formal discussions.

> You might define a table ProductItems and then keep your products in one
> wide table. And then you might find it inconvenient and two additional
> tables, say, Cars and Houses. So you introduced into your model two
> additional entities called Cars and Houses.

Please explain more clearly. Does ProductItems initially include Cars and Houses? What are the attributes of Cars and Houses? Do they differ from ProductItems? What inconvenience am I remedying?

> The only problem is that RM
> does not allow to add properties to these entities because they are
> represented by tables.

You mean each car and house is a table? Why on earth would I do that? If not, what is keeping you from adding attributes to the Cars and Houses tables?

> >>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 do not introduce anything at all and if there is some complexity then
> it is done deliberatly - I provide examples which demonstrate that
> tables *are* used for modeling and representing data semantics.

You introduce "support from one common meta-table".

You "demonstrate that tables *are* used for modeling and representing data semantics"---how? These examples seem contrived; are you suggesting that anyone actually creates their databases along the lines of your #2? I still don't see your point---it's like me saying I provide examples that shovels *are* used upside down, therefore we should redesign them to work equally well both ways.

> >>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?
>
> Because our data has such a property.

What property? Nesting, inclusion? Are you arguing for network/hierarchical models?

> We always represent entities by
> tables and want our records to store internal records.

What are "internal records"? Why do we want our record to store them?

> >>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.
>
> Of course, and I absolutely agree here, tables are not vars - but only
> in relational model.

Vars? Rows/tuples, you mean?

> But in data modeling they are! And it would nice to
> have a model that formalizes this fact. As I illustrated in several
> previous examples we frequently use tables as records and vice versa.

In metamodelling, you mean? I still think your wording is sloppy---we do not use tables as records, we store information about tables in records. You can use the RM for this, as most relational-based implementations do.

> You project everything on relational model so it does not make sense to
> continue.

I agree about the sense bit, but I do not think it is a case of relational blindness on my part. It may rather be that we are talking about different things without realising it. I have some trouble understanding your messages; often, it seems that important words are missing. In any case, I have interpreted you as believing the RM has insufficient expressiveness for some purposes. I do not think you have substantiated this.

-- 
Jon
Received on Tue Jun 07 2005 - 19:04:08 CEST

Original text of this message