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

From: Alexandr Savinov <savinov_at_host.com>
Date: Wed, 08 Jun 2005 11:00:10 +0200
Message-ID: <42a6b3ad$1@news.fhg.de>

Jon Heggland schrieb:
> In article <42a5bf13$1_at_news.fhg.de>, savinov_at_host.com says...
>

>>Jon Heggland schrieb:
>>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.

You are right, but you are talking about something different. Forget about records (facts). Of course, when we crate a table we want to record fact. But that completely different from what we are started talking about. The point was what one table means by itself? Assume you have no records. Then you create a table, say, DEPARTMENT_01, with some columns or without columns. Is it a fact from you problem domain? There have been two opinions:

It is not a fact (entity). Tables are special constructs that have nothing to do with representing facts. They have special meaning completely different from that of facts and hence they have special mechanisms for manipulating and representing.
It is a fact. Tables represent some entites from the problem domain just like records. In this example, DEPARTMENT_01 *is* some entity, which is however represented by a table rather than a row in some other table.

This is precisely the point we started to discuss. This topic is much wider that RM or data modeling. It is very important in ontologies, in OO programming (is class an object) and other fiedls, and it can be reformulated in different terms.

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

The question was: "Do tables represent facts/entities from the problem domain?" In other words, if I create tables DEPARTMENT_01 and DEPARTMENT_02 then do they represent real departments (independent of theor rows and other tables)?

My opinion is yes, they objectively represent real facts (of existence of entities) but the contemporary models do not recognize this and are not designed to handle such a knowledge. (It is not plus or minus - they simply desgined so.)

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

Yes, I also prefer to represent facts (about existing entities and their relationships) by rows. However, any database has many tables (thousands) and the question is "if they also represent normal facts then why do we treat them differently?". We may have many product types or departments or other classes represented by tables and we would like to treat them like normal facts. For example, each product type may have its unique characteristics. If tables are not facts then we would like to know what is the difference between them and why do they have such a special treatment.

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

I mean that we might define two tables Cars and Houses for keeping a set of Car products and a set of House products separately each with its appropriate set of columns. We do it instead of having one common table for all types of products.

ProductItems = <Id, Power, Area>

1, 150, null
2, 180, null
3, null, 130
4, null, 140

Alternatively we may have two tables:

Cars = <Id, Power>
1, 150
2, 180

Houses = <Id, Area>
1, 130
2, 140

Question: Do tables Cars and Houses represent facts about the problem domain? In other words, could we retrieve some properties of the entities represented by these tables?

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

Yes, it seems that we are talking about different things. But the problem whether tables/classes can be viewed as facts/entities/objects/records is very important and it is more general then data modeling.

-- 
alex
http://conceptoriented.com

Received on Wed Jun 08 2005 - 04:00:10 CDT