Database Contepts for Java Programmer: Part 1 – ACID Properties

Posted on August 22, 2009. Filed under: Database | Tags: Database |

This article will provide a basic background on concepts and standards for Database Management Systems. As a Java programmer you are expected to know all of these concepts that apply to all forms of Database Management Systems: relational (RDBMS), object (ODBMS), XML (XDBMS), and others as well as object-relational mapping and XML-mapping products.

I will be covering the following topics -

ACID Properties [Part 1]

Keys [Part 2]

Database Transaction [Part 3]

Normalization [Part 4]

Indexes [Part 5]

ACID Properties

ACID properties are an important concept for databases. The acronym ACID stands for Atomicity, Consistency, Isolation, and Durability. These properties are the four goals that every DBMS must strive to achieve. Any database that fails to meet any of these four goals can be considered not reliable.

Atomicity – Atomicity refers to “all or nothing”. In other words, when your database is updated “all or nothing” of this update should be available to anyone. It is critical that the DBMS maintain the atomic nature of transactions in spite of any DBMS, operating system or hardware failure.

Consistency – Consistency is the ACID property that ensures that any changes to values in an instance are consistent with changes to other values in the same instance. In other words, it states that only valid data will be written to the database. If, for some reason, a transaction is executed that violates the database’s consistency rules, the entire transaction will be rolled back and the database will be restored to a state consistent with those rules. On the other hand, if a transaction successfully executes, it will take the database from one state that is consistent with the rules to another state that is also consistent with the rules.

Isolation – Isolation requires that multiple transactions occurring at the same time not impact each other’s execution.

Degrees of isolation [As defined by Jim Gray]:

degree 0 – a transaction does not overwrite data updated by another user or process (“dirty data”) of other transactions
degree 1 – degree 0 plus a transaction does not commit any writes until it completes all its writes (until the end of transaction)
degree 2 – degree 1 plus a transaction does not read dirty data from other transactions
degree 3 – degree 2 plus other transactions do not dirty data read by a transaction before the transaction commits

Durability - Changes made by the committed transaction are permanent and must survive any failure [Database system, CPU, Application etc].

Further Reading:

Part 2 – Keys

Part 3 – coming soon

Part 4 – coming soon

Part 5 – coming soon

References:

http://en.wikipedia.org/wiki/Database_transaction

http://www.service-architecture.com/

http://databases.about.com/od/specificproducts/a/acid.htm