Re: Another view on analysis and ER

On Dec 8, 11:28 am, David BL <davi..._at_iinet.net.au> wrote:
> On Dec 7, 9:11 pm, JOG <j..._at_cs.nott.ac.uk> wrote:
>
>
>
> > On Dec 7, 12:41 am, David BL <davi..._at_iinet.net.au> wrote:
>
> > > 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]
> > > > , 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.
>
> > Yup, we did have crossed wires - I thought you were referring to
> > integrity constraints (which of course are very much part of a
> > relation's intension too).
>
> > > > > [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.
>
> > O.k., so the next natural question is back to our team entity...
>
> > Team(goalkeeper:Jim, defender:David, Midfielder:Jon, Attacker:Bob)
>
> > But by the definition you are positing, there is no team entity here
> > at all right? Because the identifying attributes are entities
> > themselves (assuming people are entities of course)? Hmmm....
>
> Do you think the distinction between directly or indirectly
> identifying a team is an important consideration when designing the
> predicates?
>
> According to the characterisation, for your above predicate a "team"
> is only a relationship, not an entity. The rationale is that it isn't
> considered appropriate to identify the team because it has a fleeting
> existence compared to the entities that comprise the team. Note
> however, that without a direct team identifier we have assumed that
> every time we change a player we have a *different* team. See how it
> fits in with the notion of a fleeting existence?

I do indeed. And of course I realise that changing players would yield a different team, and that in many applications this wouldn't be desirable.

>
> This relates back to the paradox of change that you recently raised
> with Reinier. There is nothing wrong with the above definition of a
> team unless it doesn't match our conceptual model.

absolutely agree.

> More specifically
> it can be very useful to allow a team to keep its identity despite
> players that come and go over time.

Doubly agreed. In most situations in fact. I still find it jarring however, that even though my example team is just defined by its players (I wouldn't call this indirectly, but I understand what you are getting it), to say that it is not an entity - I think most people would still refer to it as such.

For my sins I follow aston villa, and many a time you hear fans say that the current lineup isn't a patch of the team of the 80's. And yet they still view them simultaneously as the same team too. Its a fascinating use of language constructs. They have two different conceptual models which they flip between depending on context, extracting entities from the /same underlying data/.

> It's fuzzy, but humans choose to
> identify entities despite the paradox of change. I think this is the
> real purpose behind entities in this discussion.
>
> This consideration is very important to the DB schema design. I think
> the entity-relationship terminology is useful for highlighting the
> importance of the whole issue.

Perhaps. Or perhaps it highlights why the 'paradoxes' originate in the first place. Either way I find these conversations very useful for highlighting weaknesses in my thinking, so thanks all round.

>
>
> > > 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.
>
> > Maximal entity types... er.... sounds like things are getting more
> > convoluted. Which brings me to the real question. Whats the point of
> > all this? Why not give up on trying to make what I still feel is an
> > artificial split between entities and relationships? What is gained by
> > that split that makes it worth the effort?
>
> Did I answer that question with the team example?
>
> Perhaps you agree with the significance of choosing whether to
> directly or indirectly identify a team in the logical design, but
> don't like to interpret it as an entity / relationship distinction.
> That may be fair enough. I like Marshall's Occam's razor comment
> (just write the dam tables).
>
> > As ERM has evolved relationships are looking, more and more like
> > entities anyhow. Now they are shapes not lines, now they can have
> > attributes too... One more step, make them boxes instead of diamonds,
> > and the job is done. What would we have lost then? Might I invoke
> > occam's razor and say that a system with one type is preferable to
> > two, unless making a split has any real benefits?
>
> I suspect the decision of whether to directly identify a thing in the
> real world (despite the paradox of change) is so important it's
> convenient to reserve "entity" for when that happens.
>
> I agree this would be much more palatable if we had a more formal
> definition of what it means to directly identify a thing.
>

Well that brings me to bundle theory I guess. Hume addressed many of the issues of entities hundreds of years ago, and I get the feeling a lot E/R experts wouldn't have any idea of his work.

>
>
> > > > > 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.
>
> > Jon seems to have covered a lot of comments I might make, so I won't
> > replicate his post. Instead I shall drink tea.
>
> You both ask lots of good (and tricky) questions. Cheers.
Received on Sat Dec 08 2007 - 20:57:46 CET