next up previous contents index
Next: System Level Consistency Up: Consistency Previous: Consistency   Contents   Index


Operation Level Consistency

Operation level consistency means that the operations of the transaction do not leave data (or whatever type of object that is operated upon) in an inconsistent state. More precisely, a transaction, when executed alone, transforms an initially correct system state into another correct state [6].

For instance, the bank account transaction to transfer $100 from one bank account to another, may not withdraw $100 from the first account and then incidentally deposit $101 on the second account, although this could easily be the case, e.g., due to a programming/typing error. I agree with [4, p.360] that (this type of) consistency generally is "the responsibility of the programmers", thus transactions are assumed to be correct. You could have consistency constraints [34] (or integrity constraints [6]), but I find it unlikely that it is possible to guard against any programming error; just think of one or more consistency constraints to avoid the extra $1 deposited in the scenario just mentioned. This view is supported by [6] (in a database context):

"In practice, a complete specification of the constraints governing a small database is impractical (besides, even if it were practical, enforcing the constraints would not be)."

It is also the way that the ORACLE database works [37]:

"A transaction should consist of all of the necessary parts for one logical unit of work -- no more and no less. Data in all referenced tables should be in a consistent state before the transaction begins and after it ends."

Making operation level consistency the programmers responsibility is not going to make me feel the least bit guilty (just handing the problem over to somebody else), because it is not hard to program in a operation level consistent manner, due to the atomic property of transactions.

Furthermore, it is my belief that consistency constraints are "easier" to specify and check in databases where data is typed, than it must be with shared files that to the operating system normally are nothing but uninterpreted sequence of bytes [52, p.246]. Even though this is the case, the operation level consistency is normally the C in ACID, i.e., it is a property of transactions in (distributed) operating systems. To my knowledge the consistency for database transactions have never been anything but system level consistency.


next up previous contents index
Next: System Level Consistency Up: Consistency Previous: Consistency   Contents   Index

michael@garfield.dk
2000-10-13