Re: Another view on analysis and ER


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

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. 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. As a
consequence, if you can identify the information about something, then you
can also indentify that something. For that reason it makes sense to me to
think of OIDs as rigid designators for objects in the wild.


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



.

Relevant Pages

  • Re: Another view on analysis and ER
    ... I have found the fact that database tuples and mathematical tuples ... "Has no correspondence whatsoever with data as observed" might ... Say the construct in our UoD representing the entity E does not use its ... subsequently recognize them again we observe identifying properties. ...
    (comp.databases.theory)
  • Re: Another view on analysis and ER
    ... I have found the fact that database tuples and mathematical tuples ... "Has no correspondence whatsoever with data as observed" might ... subsequently recognize them again we observe identifying properties. ... I cannot directly observe your age, ...
    (comp.databases.theory)
  • Re: A real world example
    ... use a temporal attribute to make the tuples in the database instance ... preceding a change correspond to tuples in the database instance ... issuing a series of assignments introduces its own problems. ... including those that are not included in the propositions about it. ...
    (comp.databases.theory)
  • Re: Database design, Keys and some other things
    ... In a typical personnel system, new employee ids are assigned by the HR department, and they are responsible, ultimately, for avoiding duplicate assignments. ... Exposing system owned data to users should be done only when necessary: error codes/messages, ... This excludes any data that might be used exclusively by the database. ... The database should have no other "hestitation" in providing any collected data or metadata within the constraints of security. ...
    (comp.databases.theory)
  • Re: A real world example
    ... use a temporal attribute to make the tuples in the database instance ... I was referring to why tuples between relation-values cannot correspond ... issuing a series of assignments introduces its own problems. ... including those that are not included in the propositions about it. ...
    (comp.databases.theory)