Re: A real world example

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.

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.

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.

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, ... 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 ... value of a candidate key determines the values of all other attributes, ... argue that no query is needed, merely constraints. ...
    (comp.databases.theory)
  • Re: Prolog type overloading
    ... If I have in my database next, it means ... I know - it is just that I am extending a single-user game programme to ... same name for predicates meant to be doing the same thing. ... It's not always clever to be clever. ...
    (comp.lang.prolog)
  • Re: Prolog type overloading
    ... If I have in my database next, it means ... nextclauses. ... It's not always clever to be clever. ... I would use different names for different predicates. ...
    (comp.lang.prolog)