Re: A pk is *both* a physical and a logical object.

On Jul 25, 1:47 pm, "David Cressey" <cresse..._at_verizon.net> wrote:
> "JOG" <j..._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.

Very well put imo. Received on Wed Jul 25 2007 - 14:51:34 CEST