Editing ACID (section)

== Characteristics ==
The characteristics of these four properties as defined by Reuter and Härder are as follows:

=== Atomicity ===
{{Main article|Atomicity (database systems)}}
[[Database transaction|Transactions]] are often composed of multiple [[SQL syntax|statements]]. [[Atomicity (database systems)|Atomicity]] guarantees that each transaction is treated as a single "unit", which either succeeds completely or fails completely: if any of the statements constituting a transaction fails to complete, the entire transaction fails and the database is left unchanged. An atomic system must guarantee atomicity in each and every situation, including power failures, errors, and crashes.<ref>{{cite web
| access-date = 2011-03-23
| website = webopedia.com
| publisher = Webopedia
| title = Atomic operation
| date = 25 November 2003
| quote = An operation during which a processor can simultaneously read a location and write it in the same bus operation. This prevents any other processor or I/O device from writing or reading memory until the operation is complete.
| url = http://www.webopedia.com/TERM/A/atomic_operation.html}}</ref> A guarantee of atomicity prevents updates to the database from occurring only partially, which can cause greater problems than rejecting the whole series outright. As a consequence, the transaction cannot be observed to be in progress by another database client. At one moment in time, it has not yet happened, and at the next, it has already occurred in whole (or nothing happened if the transaction was cancelled in progress).

=== Consistency ===
{{Main article|Consistency (database systems)}}
[[consistency (database systems)|Consistency]] ensures that a transaction can only bring the database from one consistent state to another, preserving database [[Invariant (computer science)|invariants]]: any data written to the database must be valid according to all defined rules, including [[Integrity constraints|constraints]], [[Cascading rollback|cascades]], [[Database trigger|triggers]], and any combination thereof. This prevents database corruption by an illegal transaction. An example of a database invariant is [[referential integrity]], which guarantees the [[Unique key|primary key]]–[[foreign key]] relationship.<ref name="Date2012">C. J. Date, "SQL and Relational Theory: How to Write Accurate SQL Code 2nd edition", ''O'reilly Media, Inc.'', 2012, p. 180.</ref>

=== Isolation ===
{{Main article|Isolation (database systems)}}
Transactions are often executed [[concurrent computing|concurrently]] (e.g., multiple transactions reading and writing to a table at the same time). [[Isolation (database systems)|Isolation]] ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially. Isolation is the main goal of [[concurrency control]]; depending on the isolation level used, the effects of an incomplete transaction might not be visible to other transactions.<ref>{{Cite web |last=Archiveddocs |date=2012-10-04 |title=Isolation Levels in the Database Engine |url=https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms189122(v=sql.105) |access-date=2023-07-14 |website=learn.microsoft.com |language=en-us}}</ref>

=== Durability ===
{{Main article|Durability (database systems)}}
[[Durability (computer science)|Durability]] guarantees that once a transaction has been committed, it will remain committed even in the case of a system failure (e.g., power outage or [[Crash (computing)|crash]]). This usually means that completed transactions (or their effects) are recorded in [[non-volatile memory]].<ref>{{Cite book |last1=Silberschatz |first1=Abraham |url=https://www.worldcat.org/title/436031093 |title=Database system concepts |last2=Korth |first2=Henry F. |last3=Sudarshan |first3=S. |date=2011 |publisher=McGraw-Hill |isbn=978-0-07-352332-3 |edition=6th |location=New York |page=631 |chapter=Transactions |oclc=436031093}}</ref>