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

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1185178807.041723.264340_at_o61g2000hsh.googlegroups.com...
> 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.

>

>

Not necessarily. At the information requirements level, database design is intensely political. Spanish speakers have a different tradition of politics than Anglos, one which may not give them an advantage. In short, there are too many variables here to make a single sweeping statement. Received on Mon Jul 23 2007 - 12:57:07 CEST