Re: Another view on analysis and ER

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 19 Dec 2007 11:18:44 -0400
Message-ID: <47693657$0$5285$9a566e8b_at_news.aliant.net>


JOG wrote:

> On Dec 18, 3:02 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> 

>>"JOG" <j..._at_cs.nott.ac.uk> wrote in message
>>
>>news:3e4b7a1f-8a53-4d16-aa2e-5d7e80e52884_at_e10g2000prf.googlegroups.com...
>>
>>>On Dec 18, 4:38 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>>>
>>>>"JOG" <j..._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."
>>
>>>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? ;)
>>
>>It doesn't really matter. If you're issuing updates, then you're tracking
>>them. If you're issuing assignments, that is, deletes and inserts, then
>>you're not.
> 
> 
> ah, what a prickly thing terminology is. You seem to be referring to
> tracking items internally in the db, whereas I am referring to the
> difficulty (or sometimes impossibility) of tracking something
> externally without using its attributes to recognize it. I am
> concerned with the issues of identifying something out there in the
> real world before it gets to the DBA, and only then with corresponding
> that to what we have in the database.
> 
> 

>>>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.
>>
>>We'll ask the surveillance team what the old values were, of course ;)
>>
>>It's funny. Yours is almost the same argument I presented several years
>>ago. IIRC, the resolution of that argument was that I am a vociferous
>>ignorant. Perhaps you'll have better luck than I.
>>
>>>>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.
>>
>>Perhaps I am. My understanding of object identifiers is that they are
>>arbitrary numbers assigned by the system to objects as they are instatiated.
>>I was not under the impression that they were memory locations.
> 
> 
> OID's once referred specifically to memory locations (and still do in
> OOP), but are now more generally viewed as logical locations (and
> hence why they are often referred to as 'pointers', indicating where
> information about an item is currently being /stored/). They are very
> much a internal system artifact, whereas a name, a name is an
> attribute - part of the information proper outside of the system.

I am always astounded by the folks who claim OID's are logical just like a surrogate and immediately claim their advantage is speed. :-\

>>Now,
>>whether they identify something or they identify information about something
>>is not important, since there is a 1:1 correspondence between that which is
>>interesting about something and the information about that something.

> 
> Ok, so we are seeking the same things - an immutable identifier for an
> entity so it can be 'tracked' - and it's just our approaches that
> differ. As with hidden surrogates, the main problem with OID's is that
> they don't do squit for us outside the database, and thats our first
> port of call in the data management process.
> 
> Its like I was saying with the car - you can't ask it what its OID is
> so you can update the right object. You can't examine its mutable
> attributes to correspond to the right OID, because they may have all
> changed. You can't necessarily ask it anything about it's history
> because it's, well,...a car. So you need the VIN, a pretty good stable
> identifier, that we can recognize in the real world, and use to
> correspond to the information already in our db.
> 
> I hope at least, given the assumption that one cannot always rely on
> 'tracking' an item outside of the database (and hence the whole
> 'unbeknownst' changes are possible), that my 1-5 point argument
> doesn't look quite so specious. Merry Xmas, J.

Your biggest mistake is thinking Selzer might comprehend a simple, straightforward and compelling argument. Received on Wed Dec 19 2007 - 16:18:44 CET

Original text of this message