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

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1186967829.283726.289850_at_o61g2000hsh.googlegroups.com...
> On Aug 5, 3:26 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
>>
>> news:1185445415.561100.98380_at_o61g2000hsh.googlegroups.com...
>>
>> > Just as another example of what i'm on about with this construct
>> > m'larkey: Imagine the library has two copies of "harry potter and the
>> > deathly hallows". Are they the same book?
>>
>> > 1) If your construct is the one that uses the barcode on the sleeve as
>> > an identifier, then no, different books.
>> > 2) If your construct is the one that uses the ISBN number as an
>> > identifier, then yes, same book.
>>
>> > There's no correct answer, and which you pick just depends on the
>> > application. A Loans database could use Barcodes; A library listings
>> > database could use ISBN.
>>
>> A very thought-provoking example. Are they the same book? From the
>> information given, no, they're not the same book. They are two different
>> physical manifestations of the same abstract individual. Abstract
>> individuals are incomplete in the sense that they cannot exist apart from
>> their physical manifestations, for to exist is to be spatiotemporally
>> located.
>> As a consequence, the identity relation fails just in case there
>> are no physical manifestations; therefore, it must be assumed that there
>> exist physical manifestations. So if each tuple in a relation describes
>> a
>> specific abstract individual, then that relation must be a projection of
>> another--even if it isn't defined in the schema. Since the abstract
>> individual exemplifies all of its physical manifestations and cannot
>> exist
>> apart from those physical manifestations, the existence of a tuple in a
>> relation that uses ISBNs as key values implies the existence of at least
>> one
>> tuple in a relation that uses barcodes as key values--even if the barcode
>> relation is not defined in the schema. If at some point in the future
>> the
>> loans and library listings databases were combined, there would clearly
>> be a
>> cyclical relationship between the set of abstract individuals denoted by
>> ISBNs and the set of concrete individuals denoted by barcodes.
>
> I'm glad you thought it was an interesting example. I personally see
> no distinction between your "abstract" and "physical manifestations".
> To illustrate this all i'm asking is that you just extend the example
> to use more constructs - maybe I now have five books, the two harry
> potters from before, another that's got illustrations, one translated
> into mandarin and a digital version. We now have an almighty
> conundrum if someone asks us "which of these are the same book". How
> do you split up "physical" and "abstract" now? It would be an absolute
> spaghetti to try to hazard an answer!
>

It is simple. An abstract individual cannot be spatiotemporally located. The one thing that the five individuals above have in common is the abstract individual: they are all physical manifestations of it. Neither the addition of illustrations, the translation into mandarin nor the encoding into digital form changes the fact that the abstract individual exemplifies each of those five tangible instances. Try a simpler example: the number 5 is an abstract individual. You have 5 senses; you have 5 digits on each of your hands; there are 5 points on each star of each American flag; most cars leave the factory with 5 wheels (including the spare). There are uncountable physical manifestations of the number 5, but the abstract concept, the number 5, cannot exist apart from them.

> There just isn't a correct response, without knowing the correct
> context over the lifetime of an application.
>

The lifetime of database often exceeds the lifetime of the applications for which it was originally designed. I have clients that are still using databases that were designed in the early '90s. The applications that were built to use the database have evolved or have been replaced over the years.

> And then hopefully its only a short jump to see that if "Mrs Smith"
> gets married and our database breaks because we chose surnames as an
> identifier, it was our mistake when we were doing the conceptual
> modeling and no problem with the theory. Her name didn't identify over
> her whole time at a company, and /that/ was our context we should have
> considered.
>

It would be a giant leap backward to assume that any update that affects a key necessarily selects a different individual. It is definitely not the case for relation schemata with more than one key, and it reduces by half the ways that individuals can be identified in queries. Where is the logic in the assuption? Since it is clearly not the case when there is more than one key, how can it possibly stand when there is only one key. Certainly a relation that has more than one key can be decomposed into an equivalent set of relations where one has only one key--a key that may be the target of an update. Would it always be the case then that a new individual is selected? Certainly not. Received on Mon Aug 13 2007 - 07:56:24 CEST