Re: Newbie question about db normalization theory: redundant keys OK?

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:U2W8j.80311$Um6.5491_at_newssvr12.news.prodigy.net...
>
> "David Portas" <REMOVE_BEFORE_REPLYING_dportas_at_acm.org> wrote in message
> news:HZednQ8PPZsCBP7anZ2dnUVZ8qClnZ2d_at_giganews.com...
>> The only way to tell whether the current state of the database equals
>> some previous state is to query again and compare that to a result
>> previously retrieved. That comparison is usually based on a key value. It
>> makes no difference what type of value is used for the key. The
>> comparison is exactly the same whether it is an "artificial" key or
>> otherwise. (I'm not too concerned about defining what an "artificial" key
>> is because I don't think it matters).
>>
>
> I disagree. Unless the identifier is a rigid designator or a rigid
> definite description, then any comparison based upon that identifier is
> suspect. It may be the case that the key values are identical, but the
> individuals in each state that are identified by that key value are
> different individuals. For example, "the first person in line" can be
> different people at different times.
>

Isn't that purely a question of what propositions we want to represent?

Assume that the tuple:

1. ('Celko', 'Database 101', 222, 6)

represents the proposition:

P: "Teacher named Celko teaches class 'Database 101' in room 222 during period 6"

which we assume to be true at a certain point in time. At some later time we replace tuple A with two different tuples:

B: ('Selzer', 'Database 101', 222, 6)
C: ('Celko', 'Zen Buddhism', 223, 6)

representing propositions of the same kind as P.

Those propositions assert absolutely nothing about whether Celko in A is the same individual as Celko in C. They assert nothing about whether room 222 in the first case is the same as in the second. Crucially, they DO NOT assert whether any individual previously known as "Celko" changed his name to "Selzer" or whether he was replaced by an entirely different person called "Selzer".

The reason that you (and Tony I guess) think it is "suspect" to compare tuple A with tuple B is that you are applying your own intended interpretation, which the database was never designed to support. There are other interpretations however, which are potentially valid (the interpretations of the proposition P kind for example). If those valid interpretations are the ones required and understood by the users of the data then the database is quite sufficient as proposed.

>> BTW I seriously doubt whether it would be possible or desirable to
>> implement anything like a ROWVERSION in a true RDBMS. The consequences of
>> SQL Server's implementation are serious because it attempts to identify
>> row data based on something other than keys. I have never been a fan of
>> the ROWVERSION feature.
>>
>
> In what way does it attempt to identify row data based on something other
> than keys?

A problem arises with relational assignment - something that SQL doesn't support. In an assignment it is meaningless to talk of individual tuples being updated or left unchanged. The only valid basis for anything like ROWVERSION might be a comparison of the relation value before the assigment and the relation value after. But the ROWVERSION feature has no means of specifying a key on which to perform such a comparison (presumably the comparison would be a join on one of the candidate keys). ROWVERSION just assumes that such a comparison can be made with or without a key (this is SQL after all!).

Every kind of update in an RDBMS must surely be equivalent to some relational assignment. That's why I seriously doubt whether anything quite like ROWVERSION is possible or desirable.

-- 
David Portas