Re: One-To-One Relationships

On Dec 6, 5:30 pm, rp..._at_pcwin518.campus.tue.nl (rpost) wrote:
> JOG wrote:
>
> [...]
>
> >> What I meant to say was:
> >> an entity is a relationship except that an entity is identifiable in itself,
> >> while a relationship is identified by its (possibly entity-valued)
> >> attribute values. But I already said that in my previous post.
> >> By "identifiable" I mean "mentionable", "referrable".
>
> >I still think if you examine this again you'll see it really
> >struggles. 'What does identifiable in itself' mean?
>
> By "identifiable" I mean "mentionable", "referrable".
> "Can be used as an attribute value."

I already addressed that. To refer to something you have to identify it.

>
> In other words, I propose what is sometimes called
> an "object-oriented data model".

Ugh, that's even worse than a logical model based on ERM. Ah yes the OO-data model, the very one that died on its ass because it was a nightmare to query, nevermind the fact it was a retro-grade reinvention of the network model that was superceded 30 years ago.

Its like reinventing a square wheel.

>
> > We can only ever
> >identify things from observable attributes (and refer to them by
> >attributes too!).
>
> Certainly, but we don't always make those attributes explicit.

Yes we do. Always.

> And we don't always know what the relevant identifying attributes are.

Yes we do, otherwise we can't identify them in the real world.

> More importantly, idenification and entities are relative; they vary
> with context.
>
> For instance, I write under the hypothesis that you are a person,
> identifiable here as "JOG". But this assumption may be false: you may
> be writing under several different names, and "JOG" may be used by more
> than one person. Outside of this newsgroup I have no idea how to identify
> the person(s) writing here as JOG.

As far as you're concerned I am JOG. That's the entity you are dealing with, and that's all there is. Nothing else. It doesn't matter what's happening behind the curtain.

>
> I could remedy this by attempting to find more identifying information
> (posting headers, newsgroup history, whatever). But I don't. I have
> no need to. Assuming a newsgroup writer "JOG" works fine for me for now.

Why would you need to remedy it? What's wrong with it as it is? This is a nonsensical discussion.

> Should I ever want to, let's say, meet you on IRC or over coffee, I'd need
> to extend my model of you, and provide a more detailed identification.

Nope, then you'd be dealing with a different entity.

>
> The question is whether I want to impose in my modelling language
> the need to restructure the relationship between postings and authors
> as soon as I make such more detailed identifications of persons.
>
> [...]
>
> >> The question is not how entities are referred to in statements,
> >> but how to model the meaning of those statements. Let's take the
> >> "head of department" example again. Clearly when we obtain the
> >> information who is head of which department, the statement giving us
> >> this information will usually address the two relevant entities by name:
> >> e.g. when I read that Ms Rice is the head of the USA's Foreign Affairs
> >> department, I see two entities referred to by name.
>
> >There's the mistake imo. You have preassumed a conclusion - that
> >entities are there
>
> Nope. My entities are constructs in my model. I construct them myself.
> They do refer to things in the real world, but in a way my model doesn't
> fully describe.

A great load of use that's going to be when something happens in the real world that you need to update then.

>
> >I certainly see no entities in that statement at all. I see words. In
> >fact I can guarantee the existence of those words, but I certainly
> >can't metaphysical 'entities'. I can also see some words in the
> >statement describe roles and some that describe values. Some roles
> >aren't there so I resolve them in my noggin by context (e.g. Ms and
> >capitals indicates the start of a name for example.)
>
> >Just roles and values, a logical layer, on which I can impose all
> >sorts of conceptual models.
>
> Please describe how you describe that persons are heads of departments
> in a way that doesn't predetermine how I'm going to identify persons
> and departments from now on. Or is it Just Wrong to want that? Why?

Well not just wrong, but nonsensical. How can you describe something if you can't identify it? C'mon Reinier!

>
> >> Does that mean
> >> we should express the meaning of that statement, the "head of department"
> >> relationship, as one between department names and person names?
>
> >Why not? Its just data. Whatever conceptual model we want to conjure
> >in our heads afterwards is our own business.
>
> Nope. We don't decide whether people change their names,
> the personnel administration does (where I work, at least).
> We don't want an administration with headless departments
> as a side effect of name changes.

I'm afraid you've missed the point. I've given you examples but I'm not sure you have digested them properly mate.

>
> >> No, it doesn't, which becomes evident as soon as persons or departments
> >> change their names.
>
> >I 100% disagree, but now your getting into well trodden ground. If a
> >person changes their name are they then a different person? You are
> >saying no, but you are wrong because the actual answer is... It
> >depends! There's just no correct response.
>
> Sure, we can't predict or anticipate every need for change in advance.
> Still, I think this particular case is pretty clear.
>
> >If you think this is
> >madness and that obviously we'd still be talking about the same
> >person, I refer you back to the question "are you the same person as
> >when you were 5", or my example about Harry Potter books. Context is
> >everything.
>
> I am not trying to make claims about "what a real person really is".
> I don't believe in references into "the real world". All we can do
> is refer within models, or cross-refer from one model to another.

No, all our information comes from the real world. Start there, and think how you identify things. If you want to fall internally into your own model as an excuse for the lack of clarity, well your going to have to accept at somepoint something will happen in the real world and your database will break.

I'm sorry but I've given up with the rest because there is just no clarity in the argumentation, and its such a long post now.

I can only reccommend you go off and read all the arguments against the disaster that has been OO-DBMS.

>
> [...]
>
> >> My conclusion is that "head of" is a *reference* to the person entity,
> >> and that we need entities (or references) as first-class citizens in
> >> order to correctly express the meaning of this statement.
> [...]
>
> >You recognize two items as the same thing in the real world,
>
> Nope. I know other participants in this thread use the term "entity"
> in that way, but I don't. I recognize them as the same *in my model*.
>
> I should have probably explained that better ...
>
> >by some consistent attribute (or set thereof).
>
> The whole point of this discussion is that sometimes
> you do not have or want a consistent attribute to pick.
>
> >Pick the right ones, otherwise
> >your database will break.
>
> Sure, in a database all tuples ultimately need to be identifiable in
> terms of user-visible attributes, to avoid the existence of multiple
> equivalent tuples. But even there, "the right ones" are not in general
> a unique choice. E.g. depending on where I come I can identify myself
> by my passport and/or my driver's license. Sometimes the identification
> chosen depends on what information is practical or legal to maintain.
>
> >You highlight flaws in a designers schema,
> >not problems in an underlying model.
>
> ?? Which model is on top of which?
>
> >And don't underestimate how much
> >context resolving we do in our heads, and the amount of semantic
> >knowledge we apply to fix ambiguity and inconsistency.
>
> You appear to underestimate how much *flexibility* we have
> in all this context resolution business.
>
> --
> Reinier
Received on Thu Dec 06 2007 - 19:47:01 CET