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

In article <42a5ce76$1_at_news.fhg.de>, savinov_at_host.com says...
> > 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.

They are not the same. One is the thing; the other is a description of the thing. I think the statement "we insert records into records" is misleading---it can be justified, but it is a stretch. It confuses more than it elucidates.

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

Not really---in fact, I have gotten the impression that it is you who want to add dedicated mechanisms to rectify perceived faults in the RM.

When it comes to conceptual/semantic modelling versus logical modelling, it is unfortunate that they are separate, but it is hard to avoid. Conceptual modelling is informal and human-oriented, while logical modelling is formal and machine-oriented. However, note that I do not like Entity-Relationship modelling; the separation between entities and relationships seems arbitrary to me, and ER diagrams have too little formality and expressive power. I prefer ORM or Carlis and Maguire's LDS.
> 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...

What are the semantics of a product or a sum of arbitrary entities? Does it have any connection to logic?

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

Oh, so you are talking about defining specific entities, not the concept "entity" in general? Sorry. So the bottom entity is a collection of nothing at all? Are entities nothing more than collections of other entities? If so, how can they have any information content, if all you have to build upon is nothing?

Anyway, how is this different from the network data model from thirty years ago?

> 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).
[8<]
> 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.

Sounds indeed like a network data model (or hierarchical? Can an entity participate in just one container?), with some extra restrictions. Why make it so complicated?

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

In that case I suggest you pick one term and stick with it.

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

I haven't had that "feeling" yet. Examples of where we "need" this?

> In concept-oriented terms:
>
> r = <r1,r2,...,rn>{}
>
> where r is a record and r1,r2,...,rn are other records.

I.e. a record must have an empty collection/sum?

> A table is defined as follows:
>
> t = <>{r1,r2,...,rn}

I.e. a table must have an empty product (or what you call it)?

What do you call x = <a1,a2,...,an>{b1,b2,...,bm}, then? Is it both a table and a record, or neither?

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

In the modelling tools and the system catalog, yes---I don't think anyone disputes that. Any other applications? My principal objection is to the idea of mixing modelling with meta-modelling, I.e. treating a table in a given model as an entity in the very same model. It may be possible, but the costs outweigh the gains. In fact, I don't see any gains at all.

-- 
Jon