Re: A real world example


"erk" <eric.kaun@xxxxxxxxx> wrote in message
news:1155757948.288621.151290@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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



.

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 ... model already allows surrogate keys. ...
    (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: Wiki software for genealogy (long)
    ... those specific facts. ... Data can substantiate other data (although not prove ... documents of interest in my database. ... only connections I wish to make are all assumptions, either mapping a ...
    (soc.genealogy.britain)
  • Re: Database design, Keys and some other things
    ... except maybe that a database contains dead objects in the sense then as soon as they are in the database they stop behaving - food for another thread). ... some of their facts to establish that reason. ... to a refutation of the idea that there's any essential difference between the industry standard external identifier and the database-specific surrogate key: it's a matter of context merely, and not anything intrinsic to that data, or how it is managed. ... What is essential to this question is what their nature is. ...
    (comp.databases.theory)
  • Re: Where do business rules belong... OCP and SPs
    ... Database stuff is all about persistence. ... It's true that a database is a representation of facts, ... called business rules and they can and should be represented in the ... They are a lot better for that than general-purpose programming ...
    (comp.object)