Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: A pk is *both* a physical and a logical object.

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

From: Brian Selzer <brian_at_selzer-software.com>
Date: Tue, 24 Jul 2007 07:27:28 GMT
Message-ID: <ARhpi.44028$YL5.8755@newssvr29.news.prodigy.net>

"JOG" <jog_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."

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? Now, I understand that as soon as the tire is replaced, or as soon as the tires are rotated, or as soon as I trade in my car, "the right front tire on my car" denotes a different tire.

The point is that a description need not be rigid to be definite. It may also be the case that the serial number of the tire is not relevant to the problem at hand. Its absence from the database schema does not necessarily mean that it does not exist. It certainly doesn't mean that "the right front tire on my car" denotes the same tire in all possible states of affairs.

>> Here each individual has
>> two sets of identifying properties: one that identifies the individual at
>> all possible states of affairs and one that identifies the individual at
>> a
>> particular state of affairs.
>
> Utterly and totally incorrect. A construct that is one thing (i.e. has
> the same identity) "over all its possible states" is a completely
> different kettle of fish to an item which is only the "same thing in
> one state". They are different constructs, with different identifiers
> - even if they overlap.
>

I beg to differ. The combination of a non-rigid definite description and the rest of the information about a particular state of affairs rigidly designates a particular individual. One alternative to using surrogates where keys can be updated is to record for each tuple in a separate set of attributes the key value that identified an individual when it was originally inserted along with the transaction time of the original insert. Since only one tuple can have a particular key value at a particular point in time, the original key value when combined with the original insertion time permanently identifies the individual. In this case the original key value represents the non-rigid definite description that identified the individual at the state of affairs denoted by the original insertion time. Once an individual is identified, everything else that is true about it can be determined, including other rigid designators.

> (This explains how I am both the same person _and_ a different person
> to the picture of me as a ten year old. The concept of a person type
> has two different constructions, with different identifers. I can
> quickly flick between the two interpretations in real life by
> assessing the context of any particular question)
>
> Which of these constructs is applicable depends on the context,
> situation and application. If you have picked the wrong one when you
> are designing a schema, well then, eventually your database will break
> (as I know you have seen and remedied yourself in the past).
>
> I think this is pretty much the whole sticking point so for now i have
> snipped the rest.
>
> Regards, Jim.
>
>> [huge snip]
>
Received on Tue Jul 24 2007 - 02:27:28 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US