Re: A real world example

"erk" <eric.kaun_at_gmail.com> wrote in message news:1155757948.288621.151290_at_75g2000cwc.googlegroups.com...
> Brian Selzer wrote:
>> How so? In what way does the information principle require that
>> attributes
>> be mutable? A relational database contains knowledge about things, not
>> things. Now, if you're going to talk about something, then that thing
>> must
>> either exist or have existed in the universe.
>
> Referring to "things" and "entities" may be part of the problem, as
> it's on the slippery slope to First Great Blunderville. Facts are
> facts, and don't change, though our understanding of them does. A
> database state is simply a set of propositions, which uses predicates
> (relations) as the organizing principle. Constraints keep our
> propositions consistent, with respect to identifiable values. I don't
> think there's any necessity for a group of facts in one database state
> to be somehow traceable to a previous one. I could certainly be wrong;
> it just feels to me like this discussion is pivoting on identifiable
> "thingies," rather than logical constructs.
>

Facts are facts about things. If things can change, then the facts about them must also or must be replaced.

>> If a thing exists in the
>> universe and is relevant to the discussion, then there must be some way
>> to
>> distinguish that thing from all other things that exist, that have
>> existed
>> and that can exist, otherwise there isn't any way to be sure that you're
>> talking about the same thing in successive database instances.
>
> Why does one have to "talk about the same thing" in successive database
> instances (values)?
>

Again, facts are facts about things. If things can change--especially if things can alter their appearance without altering their identity, then the facts about those things must either change or be replaced.

>> It is often
>> necessary to know what was known about something in order to assert
>> something new. For example, when a credit card charge clears, the bank
>> must
>> know the balance of the account in order to compute the new balance.
>
> 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.

>> 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.

>> Because changes are set-based, without some
>> means to correlate the propositions in the preceding instance with those
>> in
>> the succeeding instance, you cannot be certain that you're talking about
>> the
>> same thing;
>
> 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.

>> therefore, you cannot be certain if the succeeding instance is
>> correct. The question is: should the solution to this problem be handled
>> in
>> implementations, or should the theory be strengthened to eliminate it?
>
> What "strengthening" would eliminate the "problem"?
>

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.

>> I believe Codd used the term "permanent" to describe surrogates. That
>> implies immutability. He did mention drastic circumstances, such as
>> merging
>> databases that could require that they change, but the impression I got
>> was
>> that they should be permanent.
>
> "Impression," "should," and "implies" are all insufficient explanation
> - if I missed your solution in a previous post, let me know, but Codd's
> writings aren't (especially in cases like this where there appears to
> be room for interpretation) holy writ.
>

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!

> - erk
>
Received on Wed Aug 16 2006 - 23:50:45 CEST