Re: Another view on analysis and ER

JOG wrote:

On Dec 18, 3:02 pm, "Brian Selzer" <br...@xxxxxxxxxxxxxxxxxxx> wrote:

"JOG" <j...@xxxxxxxxxxxxx> wrote in message

news:3e4b7a1f-8a53-4d16-aa2e-5d7e80e52884@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

On Dec 18, 4:38 am, "Brian Selzer" <br...@xxxxxxxxxxxxxxxxxxx> wrote:

"JOG" <j...@xxxxxxxxxxxxx> wrote in message

news:0110e0c9-3176-4c85-b089-e3a301eb93bc@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

On Dec 17, 2:31 pm, "Brian Selzer" <br...@xxxxxxxxxxxxxxxxxxx> wrote:

"JOG" <j...@xxxxxxxxxxxxx> 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.
.

Relevant Pages

  • Re: Another view on analysis and ER
    ... Broken database. ... immutable identifier is not required. ... I was not under the impression that they were memory locations. ... correspond to the information already in our db. ...
    (comp.databases.theory)
  • Re: some ideas about db rheory
    ... The database records not only the ... to the 'concept' using an identifier attribute. ... option ?Intrinsic Properties?. ... error committed when using standard relational techniques, ...
    (comp.databases.theory)
  • Re: Web Parts Instances
    ... For the cookie, I'm sure it is necessary for personalization. ... their corresponding database record upon reload (even once the user is ... Are you saying that Unique Identifier = pageURL+ ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Web Parts Instances
    ... otherwise) but I do not see how it relates to how the webparts recalculate ... Are you saying that Unique Identifier = pageURL+ ... interface with database record. ... multiple editor webpart instances on a page and each of them should map ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Web Parts Instances
    ... or otherwise) but I do not see how it relates to how the webparts ... Are you saying that Unique Identifier = pageURL+ ... interface with database record. ... multiple editor webpart instances on a page and each of them should ...
    (microsoft.public.dotnet.framework.aspnet)