Re: Another view on analysis and ER
Date: Tue, 18 Dec 2007 03:27:57 -0800 (PST)
On Dec 18, 4:38 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
> > 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."
And how pray are you "tracking" these entities in the real world? Following them around in the real world with a camera? Or hiring temps to stalk them? ;)
When a car turns up for your vehicle database, with all its attributes changed apart from the VIN, and thats the /one/ attribute we didn't record in the db, how exactly are you going to ask it what its history was, so that you can update the right line in the table?
Its impossible. By not using the VIN, we're fubar.
> 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.
<scratches head/> Surely this one has been done to death? An OID is a logical address, and even those in favour of OID's recognize that. It has nothing to do with the external entity, it is just a logical location where information about the entity is being stored. (I wonder if you are confusing what I'm talking about, with using a GUID as a surrogate attribute say, which is of course fine). Regards, J.
> >> 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 - 12:27:57 CET