Re: Objects and Relations

I don't have much time to respond at the moment because of work pressures, so I apologize for the brevity in the responses.

On 27 Feb, 16:25, "vldm10" <vld..._at_yahoo.com> wrote:
> On Feb 13, 4:49 am, "JOG" <j..._at_cs.nott.ac.uk> wrote:
>
> > RM does not take this view. It is not concerned with 'entities', but
> > facts - propositions composed of roles and values.
>
> The above two sentence (it seems to me) have the unusual ideas and its
> logic is not consequential enough.
> As these are the basic things in RM I have the following remarks:
>
> 1)
> E. Codd in his paper RM/T has the chapters about the entities:
> 4. Designation of Entities
> 5. Entity Types
> 6. Classification of Entities
> 7. Entities and their immediate Properties.
> .....

Yes that is RM/T and not RM. Do not confuse the two. I do not personally hold much stock with large chunks of the Tasmanian version. I don't imagine views Codd as divine or do not believe he made mistakes in his huge body of work - as a case in point, along with his arguments in favour of nulls, I believe RM/T extends RM along completely the wrong path. This in no way degrades the revolutionary achievements of his work in my eyes.

>
> The paper was written 10 years after his first paper about RM. He had
> a lot of time to think about RM, now in better scientific and
> technical environment. In introduction of RM/T and regarding semantic
> data modeling E. Codd wrote:
> "The goal is nevertheless an extremely important one because even
> small successes can bring understanding and order into the field of
> database design."
> Now regarding your ideas it seems that: RM is not concerned with
> 'entities' but the author of RM is concerned with 'entities'.

So? I can quite happily find an authors work illuminating without agreeing with everything he proposed throughout his years.

>
> 2)
> RM works with the facts but this is not specific only for RM. Every DB
> model works with the facts. In fact I can't imagine that some DB model
> - models non-facts.

Then imo you need to distinguish modelling propositions and modelling objects better.

>
> 3)
> I have a feeling that you don't distinguish completely Conceptual
> Model from Logical Model. In this sense you can't substitute
> the concept of the entities with the logic of the propositions.

I see no basis for this. Many of my posts to dawn for example have centred on the distinction between the two layers.

What I don't distinguish as different concepts, are 'entities' and 'relationships'. I would perhaps describe both constructs as 'relationships'; perhaps you would prefer the phrase "associative entities" (I don't really care about the semantics). And in coming to this viewpoint I have found Kent just as influential as Codd.

>
> 4)
> The story about the propositions can lead you back toward the design
> style of "programming-files-based" application. Well known example
> from the books about the propositions in RM exists in fact in the
> Cobol applications Example:
> Let a Cobol application has the following "logical record" for
> Supplier with "fields" : SNO, SNAME, SSTATUS, and SCITY. This
> heading for the file represents a certain predicate which looks like:
> Supplier SNO is under contract, is named SNAME, has status SSTATUS,
> and is located in city SCITY.
> So regarding "logical" description of data structure the relational RM
> use the similar ideas as old Cobol applications.
> Of course there are differences as well as the advantages and the
> disadvantages. The relational applications use the relations, they are
> DB, etc.

I cannot follow this, but I imagine I don't agree.

>
> 5) DB Design is the most important step in the construction of DB. It
> is very complex - much more then Predicate Calculus.

I do not see the relevence of this to the preceding discussion, or any relevance to comparison of DB design to a calculus I'm afraid.

>
> Vladimir Odrljin
Received on Tue Feb 27 2007 - 18:18:44 CET