Re: Another view on analysis and ER

On Dec 17, 2:31 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
> [snip]
> > Look, to identify an external entity, some attribute /must/ be
> > immutable for us to recognize it as the same thing (in fact for it to
> > be the same thing full stop), so let me exemplify what I think is the
> > problem in your reasoning:
>
> > 1) Say the construct in our UoD representing the entity E does not use
> > its immutable identifer, X.
> > 2) In the outside world imagine that, unbeknownst to us everything
> > about the external entity E changes apart from X.
> > 3) We are presented with E, but cannot find /one single/ attribute
> > that matches with any of the constructs in our UoD.
> > 4) We hence deign it to be a new construct, and add it. The original
> > construct is now garbage, and its continued existence in the db will
> > generate serious querying errors.
> > 5) Broken database.
>
> I don't agree with your line of reasoning. This is what can happen:
>
> 1) Say the construct in our UoD representing the entity E does not use its
> immutable identifier, X.
> 2) In the outside world, everything about entity E changes apart from X.

You missed out the words 'unbeknownst to us'. Kind of crucial Brian.

> 3) The database is told what is different about entity E via an UPDATE,

Hence step 3 is the knock-on error. The whole point was that you cannot identify E in the database. You can't be guaranteed to know E's history, and there are no attributes recorded for E in the db which are any longer the same. So would you know what to update? Either by magic, or you simply can't do it.

> 4) The representation in the database is adjusted to reflect the current
> state of entity E.
> 5) Consistent database.
>
> In an update, both the old values and the new values are submitted, so an
> immutable identifier is not required.
>
> > Incorrect schema choices (not picking X for the internal construct)
> > are a serious design error that will generate this problem. However
> > OID's positively facilitate the mistake, promoting the concept that E
> > has an identity outside of its attributes. They don't even require you
> > to take a stab at picking the correct identifer, so the whole mess can
> > be avoided.
>
> Your argument is specious. How can assigning a name to something promote
> the concept that that something has an identity outside of its attributes?

Non-sequitur - an OID is not a name. A name would be an attribute like any other. Keep your specious's to yourself selzerama.

> Moreover, it may be the case that one or more of the attributes that are
> necessary to rigidly describe that something are not relevant to the problem
> at hand. Furthermore, assigning a name to something doesn't change the fact
> that there may be other ways to identify it--it may just be that that
> identification may change.
>
> > These are serious practical issues for data modelling imo. External
> > entities must correspond to your internal constructs, and if your UoD
> > cannot do this (which I concede to your point that this can very
> > easily happen), then that is when we require a surrogate to be
> > invented to provide the correspondence.
>
> >> So it is certainly not at odds with the theories of
> >> identity
>
> ...
>
> read more >>
Received on Tue Dec 18 2007 - 01:53:06 CET