Re: Another view on analysis and ER

From: David BL <davidbl_at_iinet.net.au>
Date: Thu, 6 Dec 2007 16:41:53 -0800 (PST)
Message-ID: <82454ebf-f6df-437b-a937-fba746d170e6_at_i29g2000prf.googlegroups.com>


On Dec 7, 5:36 am, JOG <j..._at_cs.nott.ac.uk> wrote:
> On Dec 6, 7:49 pm, David BL <davi..._at_iinet.net.au> wrote:
>
>
>
>
>
> > [snip general agreement]
> > > > Nevertheless we
> > > > believe that the identifier can be used successfully in the real
> > > > world. This could depend on the population statistics, such as the
> > > > way we identify people around us by their facial characteristics, and
> > > > it is helpful that people don't tend to have extensive plastic
> > > > surgery, exchange body parts on a regular basis or cross dress. This
> > > > allows them to be identified by names like "John".
>
> > > I'm not sure I'm following this entirely David. "John" is just another
> > > attribute, and it can be used to refer to someone, but we know it
> > > wouldn't identify them uniquely. The reason we can get away with using
> > > it in day to day conversation is because humans are incredibly good at
> > > resolving context (whereas a computer is not). We'd only use someone's
> > > first name alone when we know its use will not be ambiguous.
>
> > My only point is that in particular contexts we are comfortable with
> > thinking of humans as entities that we are able to identify.
>
> Er, ok. I can't disagree with you there. (Although I think I'm missing
> where you were going with that point though.)

So am I :)

> > > > By contrast I think a relationship is characterised as only being
> > > > identified by the entities that it relates.
>
> > > Well, coupla things. Relationships can have attributes too, and they
> > > can be part of the identifying set.
>
> > Agreed, but that can be accommodated without upsetting the distinction
> > I'm alluding to.
>
> Ok. gotcha.
>
> > [schnnippp]
> > > > Now I see the same distinction being made in a propositional
> > > > encoding.
>
> > > I'm not sure why - there are no entities in a propositional encoding,
> > > just roles and values.
>
> > The RM formalism has attributes, domains, tuples and relations. Are
> > roles part of the formalism or outside?
>
> Apologies my fault there. I use the term roles as per the ORM, but I
> should have said attributes (even thought they are pretty analagous).
> I prefer to use the term role because it is more specific, whereas
> attribute is a subtly ambiguous word - sometimes its used to denote
> attribute name, sometimes the attribute-value, and sometimes both. But
> yes anyhow, I meant "there are no entities in a propositional
> encoding, just attributes and values".

In the formalism I think of "attribute" as a pair of name and domain, and certainly not a value.

> > I see entities come into the propositional encoding in the
> > instantiations of the intentional definitions of the predicates. This
> > is outside the mathematical formalism. However, of what practical use
> > is a relation without a well defined intensional definition?
>
> Yup, I see what you're saying (if you meant intenSional definitions
> that is!)

Oops.

> , but I'm not sure I agree. Intensional definitions only
> refer to rules concerning valid values for predicate variables, not
> valid entities. If I've missed a trick there, perhaps its worth an
> example?

An intensional definition should uniquely define a corresponding extension. For example

predicate:

    album(N)

intension:

    String N is the name of a studio album     released before 2003, of the band Garbage

extension:

    {

        {N=Garbage},
        {N=Version 2.0},
        {N=beautifulgarbage}

    }

An instantiation of the intensional definition is

    String "Version 2.0" is the name of a studio     album released before 2003, of the band Garbage

This natural language sentence refers to a studio album entity in the real world. The name value is distinct from the entity. The existence of the entity is implied by the intensional definition.

> > [ker-shhhnip]
> > > Summarizing the above I gathered that you are saying that:
> > > RELATIONSHIP: married(Husband, Wife, Location)
> > > ENTITY: married(MarriageId, Husband, Wife, Location)
> > > So the only difference is that the entity has a marriageID? I am not
> > > clear why you think the addition of this surrogate would change a
> > > relationship into an entity!
>
> > In the first case the marriage is a relationship because it is only
> > identified indirectly by the entities that are involved. In the
> > second case the marriage has been directly identified.
>
> Ok, sorry if I'm being dense, but are you saying that the second case
> is an entity because it can be identified without reference to another
> entity? And would a logical consequence be therefore that no
> identifying attributes of an entity may be entities themselves?

Yes.

X is an entity in the context of the model if there exists set A of attributes + values that identify X and there doesn't exist a subset of A that identifies a different entity Y.

Actually this attempted definition isn't quite right. For example you could determine that a team is an entity except for the fact that you end up identifying the team captain as well. Perhaps that problem can be fixed by talking about maximal entity types corresponding to cartesian products of domains and noting that team identifiers aren't suitable for identifying players more generally. Maybe Reinier can help.

>
> > That seems
> > like a significant difference in the logical layer. It shows up in
> > the intensional definitions where a marriage takes on a "role" as an
> > entity.
>
> > In the second case there must be some underlying reason to introduce a
> > marriage identifier. That reason points at a significant difference
> > in requirements. Don't assume the marriage identifier is a surrogate
> > id! Instead assume this is a well conceived design, and it's a
> > natural identifier.
>
> Well hey, I don't think a surrogate means a poorly conceived design.
> But I take your point, the Marriage ID in this case is coming from
> some external source, and hasn't been instigated by the designer of
> this modeller.
Received on Fri Dec 07 2007 - 01:41:53 CET

Original text of this message