Re: A real world example


"erk" <eric.kaun@xxxxxxxxx> wrote in message
news:1155827594.752249.65890@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Brian Selzer wrote:
Facts are facts about things. If things can change, then the facts about
them must also or must be replaced.

I think the "thing-orientation" here gets in the way of thinking about
facts as instances of predicates that we care about. When we talk about
the database, it's the predicates that are primary, not the things they
concern. A change in the database doesn't necessarily reflect a "thing
changing", unless you collapse "thing" to mean predicate rather than
some entity.


If a constraint is defined in terms of successive states of a database, then
facts cannot be thought of just in terms of instances of predicates. Any
such instance has identity only within a single relation value. Since the
value of a candidate key determines the values of all other attributes, it
can be used to identify a single tuple within a single relation value;
therefore, it can be used in other relation values as a substitute for
enumerating all of the attribute values of the referenced tuple in every
referencing tuple within the same database state--but only within the same
database state. Extending the scope of a candidate key's ability to
identify instances of predicates from a single database state to successive
database states would require that those instances be identical, not just
the candidate key values. If the values determined by the candidate key
value in the proposed state were different than those in the current state,
then the instances would not have the same properties, and therefore, would
not be the same. Instances are values; values do not change. Therefore,
relaxing this restriction so that a candidate key value can identify
instances in successive database states that are not necessarily identical,
but have identical candidate key values can only be possible if the
instances of a predicate represent things in the universe of discourse that
can have their appearance altered without altering their identity, and what
is identified by a candidate key value is not just a tuple, but something in
the universe.

Maybe, but from a functional standpoint, that operator is just a
function (e.g. "subtract $500 from X), in which the balance is a free
variable. Only in an imperative world does that involve "knowing"
(referencing) the "previous" balance. Function application means
there's no "query" of the value prior to the update.

Not necessarily. For example, consider a sales order that can have
several
states, proposed, open, firm, shipped, received, closed, cancelled.
Assume
that the order stated is the normal set of state changes for the order.
Now
consider that an order that cannot become proposed once it is firm, it
cannot become received unless it has been shipped. It cannot become
closed
unless it has been received. Unless you define special operators to deal
with the states, you need to know what the old value was in order to
maintain the consistency of the database throughout the update.

Maybe the discrepancy hinges on the phrase "you need to know." I'd
argue that no query is needed, merely constraints.


What type of constraints? I don't understand how you could define a
constraint. Could you please show me?

More
importantly, the bank must be able to identify the account that is
about
to
change, and that identity must remain constant in both the preceding
and
succeeding database instances.

Why? As long as it can be identified via some query, what difference
does it make? For example, if I make a database schema change and
introduce a new key, with appropriate view changes to support old
application code, is there some logical distinction? If the external
queries all still produce the same results, excepting the specific
values being updated, what does "identity" have to do with it?

Because changes are set-based, and if the identity of the account can
change, then it's possible to update the wrong row, or to allow a charge
to
clear that shouldn't be allowed.

There is no "wrong row," only a set of propositions. The same
possibility for human error would seem to be present in any update:
that you might issue an update without knowing about a change made
between the time you last loaded the page, and the time you pressed
Save, and therefore could violate a constraint which you wouldn't
violate if only the database were in the state you think it is (based
on what's on the screen). This issue seems to be a particular variant.

There is no "thing." These are propositions, or assertions if you like,
nothing more. The only meaning is in the correlation of queries to
external phenonema of interest.

What are the propositions or assertions about? If they're about values
then
they're just hot air. A database contains knowledge. Knowledge about
what?
Scalar values? I don't think so.

They're about what is in our heads - the application (business) domain.
The database doesn't care about that; it's in crafting predicates and
constraints that we tell the database as much as it needs to (or can)
"know."

The relational model doesn't have a correct theoretical mechanism to
correlate tuples during updates. The scope of a key value's ability to
identify a tuple is a single relation value from a single database
instance.
I think that the model is incomplete without such a mechanism, because
there
are some constraints that cannot be enforced, and certain update
anomalies
can occur, as I've provided examples of in other posts.

Since we're not talking about a machine that "really knows" the real
world, I don't understand what sort of mechanism you have in mind -
what is an example of a "correct theoretical mechanism"? The relational
model already allows surrogate keys.

But it does not require them. Nor does it define mutability constraints in
conjunction with entity integrity. Nor does it define a tuple-level
assignment operator. I think that the definition of the model should be
strong enough so that I can't break it.


True, but it felt really good to spank Badour after all of the abuse he's
dished out, unprovoked for the most part, I might add. I really loved
the
fact that he doesn't even understand the definition of a candidate key!

I didn't gather from that exchange that he had, but don't feel like
diving into that particular argument...

- erk



.

Relevant Pages

  • Re: A real world example
    ... If a constraint is defined in terms of successive states of a database, ... Yes, that's all facts are, though constraints mean that your facts are ... value of a candidate key determines the values of all other attributes, ... The frame of reference for a candidate key is a ...
    (comp.databases.theory)
  • Re: A real world example
    ... If a constraint is defined in terms of successive states of a database, ... facts cannot be thought of just in terms of instances of predicates. ... Yes, that's all facts are, though constraints mean that your facts are ...
    (comp.databases.theory)
  • Re: A real world example
    ... If a constraint is defined in terms of successive states of a database, ... facts cannot be thought of just in terms of instances of predicates. ... Yes, that's all facts are, though constraints mean that your facts are ... referencing all of the attribute values, nor, given only the key value, ...
    (comp.databases.theory)
  • Re: A real world example
    ... facts as instances of predicates that we care about. ... A change in the database doesn't necessarily reflect a "thing ... argue that no query is needed, merely constraints. ... There is no "wrong row," only a set of propositions. ...
    (comp.databases.theory)
  • Re: A real world example
    ... If a constraint is defined in terms of successive states of a database, ... Yes, that's all facts are, though constraints mean that your facts are ... model already allows surrogate keys. ...
    (comp.databases.theory)