Re: A real world example

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.

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)?

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.

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

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"?

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.

- erk

.

Relevant Pages

  • Re: Calculated value dilemma
    ... I am designing a database for my charity (we are a local special needs ... and I should therefore simply calculate the balance ... Take advantage of 300 years of modern accounting practices and design ...
    (comp.databases.theory)
  • Re: Calculated value dilemma
    ... the database accurate, easy to use, and able to expand (the current ... and I should therefore simply calculate the balance ... Historical data should accurately reflect the history. ... calculated value of the balance would be dependent on the transaction ...
    (comp.databases.theory)
  • Re: Calculated value dilemma
    ... the database accurate, easy to use, and able to expand (the current ... I am considering having a transaction ... and I should therefore simply calculate the balance ... value of some attribute where no history is stored? ...
    (comp.databases.theory)
  • Re: Calculated value dilemma
    ... the database accurate, easy to use, and able to expand (the current ... I am considering having a transaction ... and I should therefore simply calculate the balance ... aggregate and the values that combine to form the aggregate is not due to a ...
    (comp.databases.theory)
  • Re: Application structure for NLB
    ... >> balance it. ... >> The thing is that by doing this we are actually putting more load on ... it's seldom appropriate to store object in the database and would rather ... Use virtual directories to provide mirrored access. ...
    (microsoft.public.inetserver.asp.general)