Re: A pk is *both* a physical and a logical object.
Date: Wed, 25 Jul 2007 12:47:37 GMT
Message-ID: <JDHpi.11863$zy4.7083_at_trndny07>
"JOG" <jog_at_cs.nott.ac.uk> wrote in message
news:1185355659.582994.59190_at_k79g2000hse.googlegroups.com...
> On Jul 24, 8:27 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> > "JOG" <j..._at_cs.nott.ac.uk> wrote in message
> >
> > news:1185211122.628701.219130_at_g4g2000hsf.googlegroups.com...
> >
> >
> >
> > > On Jul 23, 3:57 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> > >> [snip]
> > >> I don't miss the point: I dismiss it not only because it is a gross
> > >> oversimplification based upon faulty assumptions but also because it
is
> > >> incorrect.
> >
> > > I have no faulty assumptions, but feel free to try and knock something
> > > down specifically. It is good practice for me to defend a standpoint,
> > > even a solid one. However, as ever, I only post because I think I
> > > might be able to help.
> >
> > >> Although a key value identifies (or is a surrogate for) an
> > >> individual in the Universe of Discourse, it is not correct to assume
that
> > >> the same key value identifies the same individual at every database
value
> > >> in
> > >> which it appears.
> > >> Here's proof: given a relation schema with two keys, one
> > >> whose values rigidly designate individuals and one whose values
represent
> > >> non-rigid definite descriptions for individuals,
> >
> > > "non-rigid definite desciptions for individuals". This makes no sense,
> > > but this is probably a symptom of the points below.
> >
> > >> there can be a tuple in
> > >> each of two possible relation values that has the same value for the
> > >> rigid
> > >> key, but different values for the non-rigid key.
> >
> > > Forget the database - it starts way before then brian, back in real
> > > life, when we are stating propositions about the item types of which
> > > we speak. It is how we can permanently identify these items when we
> > > talk about them that defines what they are. It has nothing to do with
> > > keys, which just identify propositions - by the time you get to the RM
> > > the mistake has already happened.
> >
> > "The right front tire on my car is going flat."
> >
> > "The tire with serial number BC324J5367 is going flat."
>
> Ok, first let me say i totally understand what you are saying. Second
> let me add that we advocate the same solution of using a surrogate key
> to solve any ensuing problems, we just argue about /why/ we are doing
> it.
>
> Let me consider the propistions you stated:
> Construct identified in the first proposition - "Right Front Tyre"
> Construct identified in the second proposition - "Tyre BC324j5637"
>
> These are different things. "What", you no doubt cry, "of course
> they're the same bloody thing". Well, consider that I also tell the
> mechanic:
>
> "The right front tyre on my car always goes flat"
>
> What do I mean: The tyre that is on now, or whatever tyre I put there.
> It could be either. One bit of rubber, which I'm continually
> repairing, or new tyres that I keep changing. Its probably going to be
> the latter in this case, and the mechanic might check my suspension.
>
> The current overlap I have with tyre BC324j5637 is lost. The two
> constructs are not the same thing over time, and hence should not be
> encoded in a database as such. The design should consider which is
> appropriate - the construct of a tyre with a code identifier, or the
> construct of a tyre with a position identifier.
>
> Note that change over time is not the only example of this being an
> issue.
>> > Both of these statements state that a particular tire is going flat;
> >
> > however, the first depends upon the current state of affairs to identify
the
> > tire, whereas the second does not. The first employs a non-rigid
definite
> > description, and the second a rigid definite description, since the
serial
> > number is part of the physical makeup of the tire.
> > Obviously, the first
> > statement is what I would tell my mechanic, not the second. Who in
their
> > right mind would get out of the car and clean off all of the mud so that
the
> > tire can be examined to determine what the serial number is?
>
> Well noone. We as humans can flick to different overlapping constructs
> with ease because of contextual and situational knowledge, in a way
> that differs from the needs of a formal database encoding.
>
Exactly.
In ordinary human discourse, we are constantly disambiguating the communication we get from other human beings. We use a complex combination of acquired linguistic skill and real world knowledge to accomplish this. Consider the following two sentences:
"The city council denied the militants a permit for a march because they
advocated violence."
"The city council denied the militants a permit for a march because they
feared violence."
Regardless of what grammarians might say, most listeners (at least in the US) would disambiguate the word "they" differently in the two sentences above.
This process of disambiguation breaks down in situations where the communication is more formal, and less context laden. The kind of data normally stored in databases is notoriously free of the sort of context that permits human disambiguation to be error free. Not only that, but the reader of database data may be some sort of programmed automaton, like a computer program, whose operation doesn't react to the context that may be provided when the data is retrieved.
It's for this reason that identification of entities has to be done in a much more formal manner, when dealing with database data, than it is in ordinary discourse. This was just as true in the magtape era, when data was stored in files and records, as it is in the database era. Received on Wed Jul 25 2007 - 14:47:37 CEST