Re: One-To-One Relationships

From: David Cressey <cressey73_at_verizon.net>
Date: Fri, 30 Nov 2007 18:26:58 GMT
Message-ID: <SBY3j.11$xB.2_at_trndny06>


"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:6df10c5d-d8e2-4eee-bbd6-700642bf8916_at_w40g2000hsb.googlegroups.com...
> On Nov 30, 12:45 pm, "David Cressey" <cresse..._at_verizon.net> wrote:

> This is interesting David. Perhaps it infers the distinction (which I
> christen henceforth as Jim's law):
>
> ENTITY PROPONENT: Does not believe a particular conceptual model
> should not bound to a specific logical one.
> TUPLE PROPONENT: Does not believe a particular logical model should be
> bound to a single conceptual one.
>
> Any takers?
>

Isn't there an extra "not" in the description of the entity proponent?

Apart from that, I kinda like the symmetry.

I'd have to say that the chronological order that I practiced was generally to start with a conceptual model, use that as a vehicle to verify that the analysis was correct and complete, and move forward from that to a design model (logical, then physical).

That biases me towards the view that there can be more than one logical model for the same conceptual model. When I speak that way, it might make me sound like an "Entity Proponent", but in reality I think there is a time and a place for entities, and a time and a place for tuples (although I tend to call them "rows").

There are, however, exceptions to the chronological order. More than once, I've come across databases that are in wide use, and have critical business functions dependent on them, and where no conceptual model exists. The people who think at that level are at the mercy of technicians who work at the more detailed levels, and those technicians are unable to summarize the information storing capacity of the database in terms that make sense at the more global level.

The question usually arises whether the database really meets the information needs of the enterprise, or whether it needs to be revised and extended. This could either be because the database was wrong to begin with, or because the enterprise has evolved.

In such situations, "reverse engineering" a physical data model back to a logical data model, back to a conceptual data model has been useful to discuss the costs and benefits of revising and extending the database with the directors of the enterprise. I realize that I'm streching the meaning of reverse engineering, but I think it's fair use of the term.

The question of whether more than one conceptual model, and ones that are substantively different, can result in the same logical model arises. I have to admit that that question eludes me. Received on Fri Nov 30 2007 - 19:26:58 CET

Original text of this message