Re: computational model of transactions
From: Brian Selzer <brian_at_selzer-software.com>
Date: Mon, 07 Aug 2006 18:38:29 GMT
Message-ID: <FMLBg.4753$9T3.3495_at_newssvr25.news.prodigy.net>
>> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
>> news:1154955541.250800.254900_at_m79g2000cwm.googlegroups.com...
>> > Brian Selzer wrote:
>> >> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
>> >> news:1154690573.601286.285520_at_i3g2000cwc.googlegroups.com...
>> >> > Erwin wrote:
>> >> >> > It is not always the case that if more than one actor is
>> >> >> > updating the same resource, that those updates must be
>> >> >> > serialized.
>> >> >>
>> >> >> I leave that one on your account.
>> >> >>
>> >> >> > To illustrate this, ignore the business rules in the above
>> >> >> > example.
>> >> >>
>> >> >> Ignoring business rules is not my idea of a good example. And
>> >> >> especially not this kind of example, since I've been a bank
>> >> >> programmer
>> >> >> for 15 years. I can assure you no one in the bank business would
>> >> >> accept the kind of risky manipulations with account balances that
>> >> >> you
>> >> >> propose.
>> >> >>
>> >> >> > The semantics of the update involve modification, not replacement
>> >> >>
>> >> >> You obviously see a difference between modification and
>> >> >> replacement.
>> >> >> I
>> >> >> don't. So please explain.
>> >> >
>> >> > I've noticed that this has cropped up a lot recently, where there
>> >> > exists a belief that one is changing part of a fact, as opposed to
>> >> > the
>> >> > truth that one is deleting a now incorrect fact, and inserting a
>> >> > brand
>> >> > new one. It appears a primary example where a common and
>> >> > understandable
>> >> > intuition is misleading.
>> >> >
>> >>
>> >> No, the circumstances underpinning a fact have changed, and the
>> >> database
>> >> must be changed to reflect that. A true statement is either an axiom
>> >> or
>> >> reflects circumstances that exist in a real or conceptual frame of
>> >> reference
>> >> that is called the universe of discourse. Axioms are always true and
>> >> can
>> >> stand by themselves, otherwise they wouldn't be called axioms;
>> >> therefore,
>> >> the only statements in a database that can change are those that
>> >> reflect
>> >> circumstances that exist in the universe. There is no contest in the
>> >> chicken/egg debate when it comes to which comes first: a database
>> >> contains
>> >> knowledge about the universe, so when a change occurs, it occurs first
>> >> in
>> >> the universe and then becomes known by the database. So if
>> >> circumstances
>> >> change in the universe such that a statement about something relevent
>> >> to
>> >> the
>> >> discussion that was known to be true no longer is, then it follows
>> >> that
>> >> that
>> >> statement must be altered to reflect the new circumstances. In the
>> >> same
>> >> way, if circumstances change such that something new becomes relevant,
>> >> then
>> >> new statements must be added to reflect that change. Similarly, if
>> >> circumstances change such that something that was relevant no longer
>> >> is,
>> >> then the statements about that thing must be removed.
>> >>
>> >> Relations are a sound mechanism to classify statements about things so
>> >> that
>> >> the discussion can be directed toward some goal. The predicate of a
>> >> relational database not only classifies the statements contained
>> >> within
>> >> but
>> >> also limits the scope of the discussion. The presence in a relation
>> >> of a
>> >> statement about something indicates that that thing is relevant to the
>> >> discussion. For example, if a relation contains statements about the
>> >> location of people, then if someone's location changes, then there
>> >> must
>> >> be
>> >> corresponding statements in the database states preceding and
>> >> succeeding
>> >> the
>> >> change. The absence of a statement in the succeeding database state
>> >> implies
>> >> that that person's location is no longer relevant; the presence of an
>> >> additional statement implies that an additional person's location has
>> >> become
>> >> relevant.
>> >
>> > Brian, we are dealing with propositions. Propositions _do not_ change,
>> > they are either true or false, and that's it. There is no way past
>> > this. Now we _can_ extract information about our external 'conceptual
>> > entities' by examining these facts and matching identifying attributes
>> > for them. We can even look at previous states of the database to see
>> > how the facts that concerned them have changed.
>> >
>> I understand that we're dealing with propositions. But a proposition
>> reflects some facet of a snapshot of the universe. If it is possible to
>> correlate a proposition in one database state with one in the next, then
>> it
>> is possible to compare the two propositions that reflect the same facet
>> of
>> the universe in successive database states.
>> it is possible to describe how
>> each attribute is different; therefore, it is possible to describe how
>> the
>> attributes in the succeeding proposition must be different than those in
>> the
>> preceeding one in order to reflect the current circumstances surrounding
>> that facet of the universe. I understand that propositions do not
>> change,
>> but it's easier to say "the proposition must change to reflect current
>> circumstances," than "the corresponding proposition in the succeeding
>> database state must have attribute values that differ from those in the
>> preceding state in order to denote the circumstances surrounding that
>> facet
>> of the universe reflected by each proposition that correspond to the
>> succeeding database state."
>> >
> Received on Mon Aug 07 2006 - 20:38:29 CEST
Date: Mon, 07 Aug 2006 18:38:29 GMT
Message-ID: <FMLBg.4753$9T3.3495_at_newssvr25.news.prodigy.net>
"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1154969618.412132.30160_at_75g2000cwc.googlegroups.com...
> Brian Selzer wrote:
>> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
>> news:1154955541.250800.254900_at_m79g2000cwm.googlegroups.com...
>> > Brian Selzer wrote:
>> >> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
>> >> news:1154690573.601286.285520_at_i3g2000cwc.googlegroups.com...
>> >> > Erwin wrote:
>> >> >> > It is not always the case that if more than one actor is
>> >> >> > updating the same resource, that those updates must be
>> >> >> > serialized.
>> >> >>
>> >> >> I leave that one on your account.
>> >> >>
>> >> >> > To illustrate this, ignore the business rules in the above
>> >> >> > example.
>> >> >>
>> >> >> Ignoring business rules is not my idea of a good example. And
>> >> >> especially not this kind of example, since I've been a bank
>> >> >> programmer
>> >> >> for 15 years. I can assure you no one in the bank business would
>> >> >> accept the kind of risky manipulations with account balances that
>> >> >> you
>> >> >> propose.
>> >> >>
>> >> >> > The semantics of the update involve modification, not replacement
>> >> >>
>> >> >> You obviously see a difference between modification and
>> >> >> replacement.
>> >> >> I
>> >> >> don't. So please explain.
>> >> >
>> >> > I've noticed that this has cropped up a lot recently, where there
>> >> > exists a belief that one is changing part of a fact, as opposed to
>> >> > the
>> >> > truth that one is deleting a now incorrect fact, and inserting a
>> >> > brand
>> >> > new one. It appears a primary example where a common and
>> >> > understandable
>> >> > intuition is misleading.
>> >> >
>> >>
>> >> No, the circumstances underpinning a fact have changed, and the
>> >> database
>> >> must be changed to reflect that. A true statement is either an axiom
>> >> or
>> >> reflects circumstances that exist in a real or conceptual frame of
>> >> reference
>> >> that is called the universe of discourse. Axioms are always true and
>> >> can
>> >> stand by themselves, otherwise they wouldn't be called axioms;
>> >> therefore,
>> >> the only statements in a database that can change are those that
>> >> reflect
>> >> circumstances that exist in the universe. There is no contest in the
>> >> chicken/egg debate when it comes to which comes first: a database
>> >> contains
>> >> knowledge about the universe, so when a change occurs, it occurs first
>> >> in
>> >> the universe and then becomes known by the database. So if
>> >> circumstances
>> >> change in the universe such that a statement about something relevent
>> >> to
>> >> the
>> >> discussion that was known to be true no longer is, then it follows
>> >> that
>> >> that
>> >> statement must be altered to reflect the new circumstances. In the
>> >> same
>> >> way, if circumstances change such that something new becomes relevant,
>> >> then
>> >> new statements must be added to reflect that change. Similarly, if
>> >> circumstances change such that something that was relevant no longer
>> >> is,
>> >> then the statements about that thing must be removed.
>> >>
>> >> Relations are a sound mechanism to classify statements about things so
>> >> that
>> >> the discussion can be directed toward some goal. The predicate of a
>> >> relational database not only classifies the statements contained
>> >> within
>> >> but
>> >> also limits the scope of the discussion. The presence in a relation
>> >> of a
>> >> statement about something indicates that that thing is relevant to the
>> >> discussion. For example, if a relation contains statements about the
>> >> location of people, then if someone's location changes, then there
>> >> must
>> >> be
>> >> corresponding statements in the database states preceding and
>> >> succeeding
>> >> the
>> >> change. The absence of a statement in the succeeding database state
>> >> implies
>> >> that that person's location is no longer relevant; the presence of an
>> >> additional statement implies that an additional person's location has
>> >> become
>> >> relevant.
>> >
>> > Brian, we are dealing with propositions. Propositions _do not_ change,
>> > they are either true or false, and that's it. There is no way past
>> > this. Now we _can_ extract information about our external 'conceptual
>> > entities' by examining these facts and matching identifying attributes
>> > for them. We can even look at previous states of the database to see
>> > how the facts that concerned them have changed.
>> >
>>
>> I understand that we're dealing with propositions. But a proposition
>> reflects some facet of a snapshot of the universe. If it is possible to
>> correlate a proposition in one database state with one in the next, then
>> it
>> is possible to compare the two propositions that reflect the same facet
>> of
>> the universe in successive database states.
> > Let me stop you there Brian, because this is the sticking point, and I > really think its a mistake. Statements (as distinct from 'entities') > can only be correlated to each other by comparing similarities in the > values of their fields, and thats it. There is simply nothing else _to > them_ to compare. And certainly not with "this is the next version of > the proposition" - there is no logical rhyme or reason for that. How > could one justify thinking that there should? I think this is a common > misintuition in how we view databases. >
I don't think they can be separated. You have things (the universe) and statements about those things (the database). If a proposition describes some aspect of something, then it depends upon that thing. For example, if a proposition states the location of a person, then that statement is tied to that person. If the universe changes such that the person is in a different location, then there should be a similar statement in the next database state (provided that the person's location is still relevant) that corresponds to the previous one but specifies new location. I agree that one way to correlate statements is through their attributes (another would be to introduce an operation more granular than relational assignment, but I think that would be counterproductive), but I would also argue that there must always be a means to correlate them, regardless of whether or not one of the thing's identifying attributes changes.
> Just to qualify that - a next version of a 'conceptual entity', if one > wants to think like that, is fine, but that's not what a database is > holding (or ever should be at the logical level), it's just storing > communicated statements. All best, J. >
>> it is possible to describe how
>> each attribute is different; therefore, it is possible to describe how
>> the
>> attributes in the succeeding proposition must be different than those in
>> the
>> preceeding one in order to reflect the current circumstances surrounding
>> that facet of the universe. I understand that propositions do not
>> change,
>> but it's easier to say "the proposition must change to reflect current
>> circumstances," than "the corresponding proposition in the succeeding
>> database state must have attribute values that differ from those in the
>> preceding state in order to denote the circumstances surrounding that
>> facet
>> of the universe reflected by each proposition that correspond to the
>> succeeding database state."
>>>> >> >
>> >> (This is why I argued in an earlier thread that statements in one
>> >> database state must be able to be correllated with statements in the
>> >> next:
>> >> how else would you be able to tell what changed, what became
>> >> interesting,
>> >> and what should now be ignored.)
>> >
>> > By examining those identifying attributes for our external entity. If
>> > there is no consistent identifying attributes between database states
>> > for that 'entity' across our statements of fact, that task is utterly
>> > impossible, and one has highlighted a serious design flaw not a problem
>> > with the relational theory.
>> >
>> > So I agree that 'conceptual entities' can slowly change their
>> > characteristics. But propositions cannot - I think it is due to a
>> > conflation of these two concepts that confusion arises. At least it did
>> > for me. All best Jim.
>> >
>> >
>> >>
>> >> Thus, a statement that is no longer true must either be modified to
>> >> reflect
>> >> the new state of the object of the statement, or it must be removed to
>> >> reflect that the information is no longer relevant.
>> >>
>> >> There is a significant difference between modification and
>> >> replacement.
>> >>
>> >> >>
>> >> >> > the operation
>> >> >> > involved, addition, is communitive and associative.
>> >> >>
>> >> >> You mean "commuTAtive", of course, and furthermore that's
>> >> >> completely
>> >> >> irrelevant. As for associativity : it is important to observe that
>> >> >> each transaction in this example does exactly one addition with
>> >> >> exactly
>> >> >> two arguments. So unless you can think of a way for the system to
>> >> >> detect that multiple independent transactions are doing such a
>> >> >> thing
>> >> >> (performing an associative operation), and then replace those
>> >> >> multiple
>> >> >> independent operations with one single, transaction-surpassing,
>> >> >> operation that has the same result, associativity is also
>> >> >> irrelevant.
>> >> >> If you cannot think of such a way for the system to detect this
>> >> >> (I'm
>> >> >> in
>> >> >> that case), you're stuck with doing multiple additions
>> >> >> one-at-a-time,
>> >> >> and you're stuck with the fact that for the additions that are
>> >> >> executed
>> >> >> second and third, one of those arguments should be the result of
>> >> >> the
>> >> >> former. Therefore it is necessary that the transactions be
>> >> >> serialized.
>> >> >> Otherwise it would mean a transaction is allowed to see
>> >> >> uncommitted
>> >> >> results from another one.
>> >
> Received on Mon Aug 07 2006 - 20:38:29 CEST