Re: Objects and Relations

From: JOG <jog_at_cs.nott.ac.uk>
Date: 19 Feb 2007 12:53:46 -0800
Message-ID: <1171918426.881412.140990_at_j27g2000cwj.googlegroups.com>


On Feb 19, 7:32 pm, "Walt" <wami..._at_verizon.net> wrote:
> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
>
> news:1171892555.782718.193500_at_q2g2000cwa.googlegroups.com...
>
> [big snip]
>
> > No comment on this? I've offered to points indicating to how thinking
> > in terms of entities can be unproductive - the lack of success of E/R
> > modelling in replacing RM (which was its original goal), and the
> > collapse of the entity-based manipulation of Classical AI in the 70's.
> > There is insight in both of these.
>
> I challenge whether replacing RM was, in fact, the original goal of Peter
> Chen. It seems to me from reading his papers, as though he wanted to
> provide an alternative to RM in situations where RM was not particularly
> relevant to the implementation environment. An example might be
> implementation in a Codasyl database. RM would give you a handle on the
> design of the Codasyl database, but it wouldn't be a particularly useful
> handle. ERM would give you an equally useful handle on the design of a
> Codasyl database, but with far less effort, and with far less implicit
> design in the modeling effort.

Fair point Walt, I didn't word that sentence too well. What I intended to say was that E/RM was intended to compete directly with RM - as a data model proper, and not merely as a tool at the conceptual layer; and that this is where it failed.

Academics I have spoken to who were there at the time have reounted of its initial fanfare and then slow degradation to a supporting role as a management tool.

>
> I myself have actually benefitted from this situation. In a database design
> situation, my colleague had taken the trouble to create an ER model out of a
> Codasyl DB design for a fairly large part of a fairly complex enterprise.
> The requirement to design a relational (OK, OK, SQL) database for reporting
> purposes required almost no preliminary conceptual database modeling,
> because the ER model was still relevant to the enterprise's data.

I can certainly see how it would be a useful diagramming mechanism in that situation.

>
> The fact that producing an RM out of an ERM is easy and straightforward is
> no accident.

I have to challenge you back on that one. Teaching database theory has shown me that the translation between thinking in terms of entities and links, and relations and propositions is extremely confusing for those beginning data management (especially in the area of encoding 'many to many' relationships), and that its certainly not intuitive. But of course that's just my personal experience. Received on Mon Feb 19 2007 - 21:53:46 CET

Original text of this message