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

On Jul 23, 8:41 am, "David Cressey" <cresse..._at_verizon.net> wrote:
> <joelle.alc..._at_gmail.com> wrote in message
>
> news:1185149625.763136.122460_at_n60g2000hse.googlegroups.com...
>
>
>
> > On Jul 18, 4:08 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> > > "Roy Hann" <specia..._at_processed.almost.meat> wrote in message
>
> > >news:BI2dnYRWNeP4VADb4p2dnAA_at_pipex.net...
>
> > > > "Brian Selzer" <br..._at_selzer-software.com> wrote in message
> > > >news:oXdni.23174$Rw1.4623_at_newssvr25.news.prodigy.net...
> > > > [snip]
> > > >>> You can call what the user issued an update, if you care to, but
> what
> > > >>> really happened is that an individual, identified by the before
> value
> > > >>> of
> > > >>> the key, was deleted, and a new individual, identified by the
> after
> > > >>> value
> > > >>> of the key was inserted. The fact that the old value and the new
> value
> > > >>> used
> > > >>> the same storage ("row", if you like) is irrelevant. They are
> > > >>> different
> > > >>> values, and they designate different individuals.
>
> > > >> Not so. Consider the following statement:
>
> > > >> I moved the widgit with lot number 203 at location 22 to location
> 44.
>
> > > > What is the so-called "individual" here? The widget, the lot number
> or
> > > > the location? You've told us the key is the entire header, so it is
> > > > irreducible, so none of these is inescapably unique in this table.
>
> > > The widgit.
>
> > > >> Now assuming that there can only be one widgit from the same lot at a
> > > >> particular location, then the definite description before the update,
>
> > > >> the widgit with lot number 203 at location 22
>
> > > >> refers to the same widgit as the definite description after the
> update,
>
> > > >> the widgit with lot number 203 at location 44.
>
> > > >> If there is also a rigid designator, then the situation becomes
> clear:
>
> > > >> before the update, these all denote the same individual:
>
> > > >> the widgit with serial number 123 and with lot number 203 at
> location 22
> > > >> the widgit with serial number 123
> > > >> the widgit with lot number 203 at location 22
>
> > > >> which is the same individual as these:
>
> > > >> the widget with serial number 123 and with lot number 203 at
> location 44
> > > >> the widget with serial number 123
> > > >> the widget with lot number 203 at location 44
>
> > > >> after the update.
>
> > > >> So, if relation widgits {lot_number, location}
> > > >> has a tuple {lot_number=203, location=22}
>
> > > > How the heck does this tuple represent *anything* about widget 123 (or
> any
> > > > other particular widget) if the serial number isn't an attribute?
> The
> > > > only way it can do that is if you first assert your entire relation
> > > > represents propositions about the widget with serial number 123
> > > > exclusively. That's fair enough and I'd have no problem with it, but
> you
> > > > aren't saying that.
>
> > > It doesn't. I introduced serial number to illustrate the point that the
> > > same individual can exist at different possible worlds even if its
> definite
> > > description is not rigid. At this point that point had already been
> made.
> > > What followed ties that fact back to databases.
>
> > > {lot_number, location} is the key for widgits. (Again, there can only
> be
> > > one widgit with the same lot number at a particular location.) So
> > > {lot_number=203, location=22} identifies a particular widgit at a given
> > > database value.
>
> > > >> and an update is issued:
>
> > > >> UPDATE widgits SET location=44 WHERE lot_number = 203 AND location=22
>
> > > >> Then the resulting relation has a tuple
>
> > > >> {lot_number=203, location=44}
>
> > > >> that refers to the same individual as the tuple
>
> > > >> {lot_number=203, location=22}
>
> > > >> before the update.
>
> > > > I am now satisified that you are talking nonsense. Erudite-sounding
> > > > nonsense but still nonsense.
>
> > > > Roy
>
> > This has been analyzed before on cdt, and as I recall Brian misses the
> > point that an 'individual' is only characterized by its identifying
> > attributes, and that there is nothing more to its nature whatsoever.
> > What we deem as identifying attributes may vary from one application
> > to another, and as they do so varies the definition itself of what
> > actually makes up the 'individual' too This can sounds unintuitive to
> > many (even though they naturally resolve such variations in their
> > everyday conversations all the time), so I can easily see where the
> > confusion comes from.
>
> > I actually prefer the term 'construct' to thing, entity or individual
> > within database design (even in spite of its semantic overloading)
> > because it highlights that when we define an item's identifiers,
> > attributes and boundaries, we do so in our heads, that these
> > definitions are not god-made, and that they can change quite happily
> > from one situation to another.
>
> > In this case, if you use the schema {lot_number, location} then you
> > are saying that the widget construct being discussed is identified by
> > the lot_number/location pair, and as far as your universe of discourse
> > is concerned /that is it/. If that was not the case (and serial_number
> > is the identifying attribute for the individual being constructed)
> > then that should have been used. However if the attribute you defined
> > as the identifying property changes, well then, it is now a different
> > item according to your description of the world.
>
> > I believe this very subtle issue (and it is one which I grappled with
> > for a long time), but that it is the cause of many serious database
> > design errors. How you identify your constructs in the real world
> > should correspond to how you identify them in the database's
> > propositions, otherwise your setting yourself up for a serious fall in
> > the future.
>
> Oddly enough, native Spanish speakers grapple with this issue quite
> differently than native speakers of most other languages, such as English or
> French. The reason is that Spanish has two verbs, "ser" and "estar"
> where most modern languages have only one verb, "to be". The distinction,
> to the Spanish speaker is so intuitive as to defy explanation at the verbal
> level, and infuriating to the person just beginning to learn Spanish.
>
> Using attributes like "location" that would go with the "estar" verb in
> Spanish to identify something is to invite confusion concerning how that
> something retains its identidy over its lifespan.
>
> I realize this is off topic, but I couldn't resist making the point that
> the way we think about reality is a function of the language we use to
> formulate our thoughts.

I think this is very perceptive David - incredibly interesting too. I have experienced a similar thing with mandarin speakers, where grammar is completely different - tenses don't really exist, there are no such things as plurals, new words may only be derived from combinations of old ones, and there is no distinction between nouns and verbs. All wildly OT, but interesting nonetheless.

Does this mean that spanish speakers design better databases? ;) Received on Mon Jul 23 2007 - 10:20:07 CEST