Re: A real world example

"erk" <eric.kaun_at_gmail.com> wrote in message news:1155827594.752249.65890_at_h48g2000cwc.googlegroups.com...
> 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
>
Received on Fri Aug 18 2006 - 09:40:15 CEST