Re: ID field as logical address

From: Brian Selzer <brian_at_selzer-software.com>
Date: Thu, 4 Jun 2009 03:12:22 -0400
Message-ID: <rtKVl.28063$c45.1324_at_nlpi065.nbdc.sbc.com>


"Walter Mitty" <wamitty_at_verizon.net> wrote in message news:RzwVl.15$tr5.10_at_nwrddc02.gnilink.net...
>
> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> news:2zuVl.25052$as4.10008_at_nlpi069.nbdc.sbc.com...
>
>
>> I disagree. It is my contention that each tuple in a
>> database--regardless of whether it is in a base or a derived
>> relation--maps to some thing in the Universe of Discourse but no two
>> tuples in the same database map to exactly the same thing. When
>> presented with a proposed database, there must be some mechanism to
>> correlate the things that each tuple in the current database maps to with
>> the things that each tuple in the proposed database maps to.
>
>
> Why?

Because the set of symbols that is an instance of a key can map to different things in the universe at different points in time, and more importantly, different sets of symbols that are instances of a key can map to the same thing at different points in time. In the example I provided, the set of symbols, {"Mary", "Smith"}, that maps to the particular person that is Single before the update cannot map to the same person after the update because the transition constraint prohibits Single people from becoming Divorced, yet after one valid update, the set of symbols, {"Mary", "Jones"}, maps to the person that the set of symbols, {"Mary", "Smith"}, mapped to before the update. So obviously, simply joining the relation before to the relation after an update could yield an incorrect result, thereby permitting garbage to get in or preventing valid information from being recorded. Received on Thu Jun 04 2009 - 09:12:22 CEST

Original text of this message