Re: One-To-One Relationships

From: Cimode <cimode_at_hotmail.com>
Date: Thu, 6 Dec 2007 05:12:14 -0800 (PST)
Message-ID: <892eedd5-fa44-4585-b277-180438e69d64_at_y5g2000hsf.googlegroups.com>


On Dec 3, 5:46 pm, Jan Hidders <hidd..._at_gmail.com> wrote:
> On 3 dec, 13:46, Cimode <cim..._at_hotmail.com> wrote:
>
>
>
> > On Dec 3, 11:00 am, Jan Hidders <hidd..._at_gmail.com> wrote:
>
> > > On 2 dec, 19:40, Cimode <cim..._at_hotmail.com> wrote:
>
> > > > On 2 déc, 16:11, Jan Hidders <hidd..._at_gmail.com> wrote:
>
> > > > > On 2 dec, 14:16, Cimode <cim..._at_hotmail.com> wrote:
>
> > > > > > On 2 déc, 10:36, Jan Hidders <hidd..._at_gmail.com> wrote:
>
> > > > > > > On 1 dec, 06:26, vldm10 <vld..._at_yahoo.com> wrote:
>
> > > > > > > > On Nov 30, 9:34 am, Jan Hidders <hidd..._at_gmail.com> wrote:
>
> > > > > > > > > Why by only one attribute? Why not by a set of attributes? Or a
> > > > > > > > > combination of attributes and relationships (as is the case for weak
> > > > > > > > > entities)?
>
> > > > > > > > This is OK, but my advice to you -don't use it often.
> > > > > > > > I will give you one example:
> > > > > > > > The relation has A1, A2, A3, A4 "attributes" and they are mutually
> > > > > > > > independent (i.e. they are in BCNF)
> > > > > > > > The "attributes" can change their values for "entity" like in
> > > > > > > > "temporal DB". User needs on line all information for any "entity" in
> > > > > > > > any moment.
> > > > > > > > Can you please write the key for this relation so that we can discuss
> > > > > > > > it.
>
> > > > > > > You do realize we were talking about ER modeling, not RM modeling,
> > > > > > > don't you?
>
> > > > > > I am talking about neither of the two. If you ask me, I place terms
> > > > > > like *entity* on the same level than terms like *object*: too
> > > > > > subjective to be reliable to build logical reasonning onto.
>
> > > > > Any data model is to some extent subjective since it represents the
> > > > > universe of discourse of a certain group of people. Of course the
> > > > > representation of that data models should be exactly defined, but that
> > > > > doesn't require that the notion of entity is more defined than it is
> > > > > now.
>
> > > > > > But I should phrased my question otherwise: what's more elementary/
> > > > > > best than a name to identify an entity, any entity ?
>
> > > > > Your question seems to assume that all things that we can speak about
> > > > > always have a unique name. For a particular universe of discourse that
> > > > > may or may not be the case.
>
> > > > I am not assuming anything.
>
> > > Good. Then the answer to your question is simple. If the entity
> > > doesn't have a name already in the UoD then it is better to not have a
> > > name to identify it in your model.
>
> > I am sorry I do not understand your answer.
>
> > I have *not* asked the question: *what would happen if the name is not
> > an attribute of the entity?* but *what's best/more elementary than a
> > name to identify an entity from another entity?*
>
> The more elaborate answer is that the best thing is that which comes
> closest to how this is done in the UoD that you are trying to
> describe.
Thank you for your answer. Are you saying that E/R main criteria distinguishness of entities depends in fact on context ? Can we assume that if *UoD* or context changes the initial criteria for distinguishing entities may also change ?

> After all, a model is better if it more closely describes
> the thing that it tries to describe (presuming it stays at the right
> abstraction level and doesn't come too close).
I have hard time understanding the advantage of having entity *description no to be separated from *distinguishability*. Description of an entity may change often because its characteristics may evolve but what distinguish it from other entities should not change In other word, I believ establishing a tight bind between the two concepts may complicate things.

> It may look more simple to invent your own naming scheme, but a more simple model is not necessarily a better model.
Simplicity is a subjective concept in itself. I find that not naming the entity actually would make things more complicated than ever to work onto. How can an update be made on a entity one can't even name but must describe? What about entities that have the same/common characterictics? Are they totally/partly the same because they are totally/partially undistinguishable?
But I see your viewpoint.

> So if things are
> identified by an elaborate description that involves several
> attributes, or even several facts about the entity, then this is what
> you should describe in your model. It may look more simple to invent
> your own naming scheme, but a more simple model is not necessarily a
> better model.
I am not convinced that taking such path actually simplifies anything. Somehow I feel the fact of not separating entity distinguishability from description makes changes more complex to handle. If at T0 some entity E1 is totally separate from E2, I want it to remain that way. If at T1 E2 has new charactestics that belong to E1, I *still* want to be able to distingush it from E1. According to the E/R you have nicely put, I would loose that difference...How does E/R deal with this problem?

> Does that make sense to you?
It does make sense but I am still not convinced. See above...

[Snipped] Received on Thu Dec 06 2007 - 14:12:14 CET

Original text of this message