Re: Newbie question about db normalization theory: redundant keys OK?
Date: Mon, 17 Dec 2007 03:55:40 GMT
Message-ID: <0rm9j.24872$4V6.3317_at_newssvr14.news.prodigy.net>
"David Portas" <REMOVE_BEFORE_REPLYING_dportas_at_acm.org> wrote in message
news:nIidnZ42CIler_jaRVnygwA_at_giganews.com...
> "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:
>
> A: ('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.
>
Isn't it true that with FOL, there must be separate interpretations for tuple A and tuple B, since they belong to different database values, whereas with modal or temporal logic, the same interpretation can apply to both? Since it is under an interpretation that values are assigned meaning, the separate interpretations for tuple A and tuple B permit identical values to mean totally different things or different values to mean the same thing. Without a common interpretation, it cannot be determined whether or not the individuals referenced by the key values in tuple A and tuple B are the same individual or different individuals. This is why I think it is suspect to compare tuple A with tuple B unless the key is a rigid designator or a rigid definite description. Note that the presence of a rigid designator or rigid definite description implies a common interpretation under which comparisons are no longer suspect.
>>> 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.
>
That assumes that relational assignment is primitive. I would argue that insert, update and delete are the primitive operations, and that assignment is a shorthand for a combination of the primitives delete and insert. Information is lost when an update is translated into an assignment, but not so the reverse: an assignment can always be translated into a delete and an insert.
> --
> David Portas
>
>
Received on Mon Dec 17 2007 - 04:55:40 CET