Re: Another view on analysis and ER

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....

>
> 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?

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?

>
> > > 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. Received on Fri Dec 07 2007 - 13:11:27 CET