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

From: Alexandr Savinov <savinov_at_host.com>
Date: Tue, 07 Jun 2005 18:42:11 +0200
Message-ID: <42a5ce76$1@news.fhg.de>

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

In RM yes, we are not inserting rows into rows. But in reality a row in a (system) table represents another table which can be used to insert records. Since the table and its counter-part in the system catalogue are the same we insert records into records. Again, this is not a part of the relational model.

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

By entities we normally mean something that has some properties (there are some other important criteria).

So you prefer to separate things and add new dedicated mechanisms for each use. I prefer to decrease the number of primary things and reduce other to a small number of basic elements. Why to we need to have conceptual/semantic modeling separate from other data modeling issues?

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

If you interpret collection and combination as logical connectives (AND and OR) then it can be expressed so, if they are algebraic operations (sum and product) then it is algebraic expression, if they are set operations (intersection and union) then...

Whatever name these operations have we have:

x = <a1,a2,...,an>{b1,b2,...,bm}

where ai and bi are other entities from the model. In particular, this new entity x may be a member of some combination, say, y=<...,x,...>{...} or some collection z=<...>{...,x,...}

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

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

Recursion is prohibited. There exists top and bottom.

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

If x = <a1,a2,...,an>{b1,b2,...,bm}
then x physically includes b1,b2,...,bm

The meaning is that physical inclusion is hierarchical and permanent. If an entity bi was included (created) into x then it exists there forever and cannot change its container (records cannot be moved without change of identity and references are always constant).

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

If x = <a1,a2,...,an>{b1,b2,...,bm}
then x is logically included into a1,a2,...,an

The logical inclusion is flexible and we can freely change it. A record is included into all its values simultaniously as a group or category.

Records/objects/entities/items are one and the same - there is no necessity to distinguish them.

Value is role of object in a combination where it is a member:

If x = <a1,a2,...,an>{b1,b2,...,bm} then x, a1,a2,...,an are all normal objects but a1,a2,...,an play a role of values for x.

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

It depends (too general question).

For relational model no, it is an advantage.

But when you create your 101st data model you start feeling that tables have some additional meaning in addition to being a container for records, i.e., you feel that in many cases tables behave like normal entities (like records) and frequently we need to treat them like normal entities.

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

In concept-oriented terms:

r = <r1,r2,...,rn>{}

where r is a record and r1,r2,...,rn are other records.

Records, items, rows and tuples are used as equivalent (depending on context).

A table is defined as follows:

t = <>{r1,r2,...,rn}

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

Definitely empty tables are useless because they are costly resource while records are cheap. There are also other obvious arguments.

But there was an opinion that tables are not entities and cannot be used for modelling. I have another opinion - tables can be treated as tables and frequently we need to treat them as entitites.

-- 
alex
http://conceptoriented.com

Received on Tue Jun 07 2005 - 11:42:11 CDT