Re: Another view on analysis and ER

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:0110e0c9-3176-4c85-b089-e3a301eb93bc_at_v4g2000hsf.googlegroups.com...
> 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.
>

Well, that's just it. If the entities that are represented in the database are being tracked, then there can't be any changes "unbeknownst to us." Which contains more information, a set of still photographs or a video recording? Which, then, is better, an occasional snapshot of the entities that are interesting or active monitoring of those entities?

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

An object identifier is simply a rigid designator--a name--that is assigned to an object during instantiation.

>> 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 - 05:38:04 CET