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

Jon Heggland schrieb:
> In article <42a5bac9$1_at_news.fhg.de>, savinov@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.

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. 

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

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

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.

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.

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.

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.

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.

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