In ACID is C the responsibility of the DBMS implementation?

StackOverflow https://stackoverflow.com/questions/22158415

Question

I am confused on the very concept of ACID.
All references/textbooks describe ACID as a set of properties that the database system is expected/required to maintain in order to preserve data integrity.
But the C part of ACID i.e. Consistency does not really seem to actually be a responsibility of the database.
In some references (e.g. Silberschatz) in the sense that the code itself of a transaction (if run in isolation) lefts the database in consistent state i.e. the transaction code is correct and hence this is the application's programmer's perspective not of the DBMS.
And in other references the description is vague like "leaving the database in consistent state"
So which is correct?

Was it helpful?

Solution

In transactions, the technical term consistent means "satisfying all known integrity constraints".

By definition, integrity constraints are declared to the dbms, and are expected to be enforced by the dbms. Why? Because if application programmers were responsible, every application programmer might make a different decision about what constitutes a consistent update operation.

For example, one application programmer might decide that every unit price that's more than $10,000 is in error. Another application programmer might decide that every unit price that's more than $12,000 is in error--but that $11,000 is a valid unit price. One programmer's work will accept a unit price of $11,000; the other's will kick it out as an error.

Relational databases resolve that inconsistency by centralizing decisions about unit prices. In this particular case, that decision might be centralized in the form of a CHECK() constraint on the "unit_price" column. Once that integrity constraint is in place, every update operation will result in a consistent value in the "unit_price" column. It doesn't matter

  • how many application programmers there are,
  • how well (or how poorly) trained they are,
  • how many different applications there are,
  • what languages they're written in,
  • whether the sleep-deprived DBA is executing an update from a command-line console.

All those update operations will find it impossible to set the "unit_price" column to a value fails to satisfy all the known integrity constraints. That means all those update operations will result in a state that satisfies all the known integrity constraints. That's the definition of consistent.

  • In the relational model, integrity constraints and business rules mean the same thing.1 Some people use business rules to mean something else; you have to determine their meaning by careful reading.

  • Integrity constraints (or business rules) should never be under the control of end users if your data is important. Constraints can easily be changed by a DBA, usually with a single SQL statement. But knowing which statement to execute and when to execute it is not in most end user's skill set.

  • The terms consistent and correct mean two different things. A database state can be consistent without being correct. A unit price that is within the range of a CHECK() constraint might still be the wrong price, a person's name might be misspelled, etc.

  • Neither the relational model nor the SQL standards are defined by a particular SQL implementation. They're especially not defined by MySQL's behavior, which is just barely SQL. (CHECK constraints parsed but not enforced, indeterminate results using GROUP BY, no analytic functions, nonstandard quoting in backticks, etc.)

If I had Database System Concepts in front of me, and I wanted to understand what the author meant by "Ensuring consistency for an individual transaction is the responsibility of the programmer who codes the transaction.", I'd ask myself these questions.

  • Is there any errata that refers to the section in question?
  • What does the author say about ACID properties in earlier editions? In later editions?
  • Does the author distinguish correct transactions (they have the right data) from consistent transactions (they don't violate any of the integrity constraints)?
  • Does the author always say that consistency is the responsibility of the programmer? (I'd say that correctness is; consistency isn't.)
  • What programmer is the author talking about? (Application programmer writing a Rails app? DBA writing a stored proc? Hard-core programmer writing the transactional subsystem for PostgreSQL?)
  • Does the author never say that consistency is the responsibility of the dbms?
  • Does the author ever say that, of the four ACID properties of transactions, A, I, and D are the responsibility of the dbms, but C isn't? (I'll bet he doesn't.)
  • Is consistency of an individual transaction different from consistency of a database? Where else does the author talk about that?
  1. "Centralized control of the database can help in avoiding such problems--insofar as they can be avoided--by permitting the data administrator to define, and the DBA to implement, integrity constraints (also known as business rules) to be checked whenever any update operation is performed." An Introduction to Database Systems, 7th ed, C.J. Date, p 18.
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top