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


"David Portas" <REMOVE_BEFORE_REPLYING_dportas@xxxxxxx> wrote in message
news:nIidnZ42CIler_jaRVnygwA@xxxxxxxxxxxxxxx
"Brian Selzer" <brian@xxxxxxxxxxxxxxxxxxx> wrote in message
news:U2W8j.80311$Um6.5491@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

"David Portas" <REMOVE_BEFORE_REPLYING_dportas@xxxxxxx> wrote in message
news:HZednQ8PPZsCBP7anZ2dnUVZ8qClnZ2d@xxxxxxxxxxxxxxx
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




.

Relevant Pages

  • Re: A implies I
    ... propositions as true only when their subject terms exist (or, ... interpretation of syllogistic logic roughly 70 years ago. ... tradition according to which the ancients were unaware of empty terms." ... A and O are contradictories. ...
    (sci.logic)
  • Re: Minimal set theory for model theory?
    ... If you Google Orayen and Paradox ... interpretation should be the set of all sets, ... the universal class will ALWAYS be proper, ... Take R as the 'aboutness' relation among propositions, ...
    (sci.logic)
  • Re: Minimal set theory for model theory?
    ... If you Google Orayen and Paradox ... interpretation should be the set of all sets, ... the universal class will ALWAYS be proper, ... Take R as the 'aboutness' relation among propositions, ...
    (sci.logic)
  • Re: Newbie question about db normalization theory: redundant keys OK?
    ... how you conclude that for FOL there MUST be separate interpretations just ... temporal database models and even logic programming that don't require ... an interpretation is an assignment. ...
    (comp.databases.theory)
  • Re: Character assignment question in Function
    ... us your interpretation of what is happening. ... help, you generally have misunderstood something, so your interpretation ... If is *VERY* common in such cases for the ... fail to compile such an assignment. ...
    (comp.lang.fortran)