Editing Consistency (database systems)

{{Short description|Guarantee of validity following an update}}
{{About||Consistency in distributed systems as defined in the CAP Theorem|CAP theorem}}

In [[database systems]], '''consistency''' (or '''correctness''') refers to the requirement that any given [[database transaction]] must change affected data only in allowed ways. 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 does not guarantee correctness of the transaction in all ways the application programmer might have wanted (that is the responsibility of application-level code) but merely that any programming errors cannot result in the violation of any defined database constraints.<ref name="Date2012">C. J. Date, "SQL and Relational Theory: How to Write Accurate SQL Code 2nd edition", ''O'reilly Media, Inc.'', 2012, pg. 180.</ref>

In a distributed system, referencing [[CAP theorem]], consistency can also be understood as after a successful write, update or delete of a Record, any read request immediately receives the latest value of the Record.

==As an ACID guarantee==
Consistency is one of the four guarantees that define [[ACID]] [[database transaction|transactions]]; however, significant ambiguity exists about the nature of this guarantee. It is defined variously as:
* The guarantee that [[Relational database#Constraints|database constraints]] are not violated, particularly once a transaction commits.<ref name="Haerder & Reuter">{{cite journal | url=http://www.minet.uni-jena.de/dbis/lehre/ws2005/dbs1/HaerderReuter83.pdf | archive-url=http://web.archive.org/web/20170907170115/http://www.minet.uni-jena.de/dbis/lehre/ws2005/dbs1/HaerderReuter83.pdf | archive-date=2017-09-07 | title=Principles of Transaction-Oriented Database Recovery |author1=Haerder, T |author2=Reuter, A. | journal=Computing Surveys |date=December 1983  | volume=15 | issue=4 | pages=287–317| doi=10.1145/289.291 | s2cid=207235758 }}</ref><ref>{{cite web|url=http://databases.about.com/od/specificproducts/a/acid.htm|title=The ACID Model|author=Mike Chapple|work=About|access-date=2014-07-23|archive-date=2016-12-29|archive-url=https://web.archive.org/web/20161229001436/http://databases.about.com/od/specificproducts/a/acid.htm|url-status=dead}}</ref><ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/aa480356.aspx|title=ACID properties}}</ref><ref>{{cite web|url=http://www.techopedia.com/definition/23949/atomicity-consistency-isolation-durability-acid|title=What is ACID in Databases? - Definition from Techopedia|author=Cory Janssen|work=Techopedia.com}}</ref><ref>{{cite web|url=http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=27614|title=ISO/IEC 10026-1:1998 - Information technology -- Open Systems Interconnection -- Distributed Transaction Processing -- Part 1: OSI TP Model}}</ref>
* The guarantee that any transactions started in the future necessarily see the effects of other transactions committed in the past.<ref name="CAP Theorem Paper">{{cite web |url=http://www.glassbeam.com/sites/all/themes/glassbeam/images/blog/10.1.1.67.6951.pdf |title=Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services |url-status=dead |archive-url=https://web.archive.org/web/20190629112250/https://www.glassbeam.com/sites/all/themes/glassbeam/images/blog/10.1.1.67.6951.pdf |archive-date=2019-06-29}}</ref><ref name="Ports et al">{{cite journal | url=http://drkp.net/papers/txcache-osdi10.pdf | title=Transactional Consistency and Automatic Management in an Application Data Cache |author1=Ports, D.R.K. |author2=Clements, A.T. |author3=Zhang, I. |author4=Madden, S. |author5=Liskov, B. | journal=Mit Csail}}</ref>

As these various definitions are not mutually exclusive, it is possible to design a system that guarantees "consistency" in every sense of the word, as most [[relational database management system]]s in common use today arguably do.

==As a CAP trade-off==
The [[CAP theorem]] is based on three trade-offs, one of which is "atomic consistency" (shortened to "consistency" for the acronym), about which the authors note, "Discussing atomic consistency is somewhat different than talking about an ACID database, as database consistency refers to transactions, while atomic consistency refers only to a property of a single request/response operation sequence. And it has a different meaning than the Atomic in ACID, as it subsumes the database notions of both Atomic and Consistent."<ref name="CAP Theorem Paper" /> In the CAP theorem, you can only have two of the following three properties: consistency, availability, or partition tolerance. Therefore, consistency may have to be traded off in some database systems.

==See also==
* [[Consistency model]]
* [[CAP theorem]]
*[[Referential integrity]]
* [[Eventual consistency]]

==References==
{{Reflist}}

{{DEFAULTSORT:Consistency (Database Systems)}}
[[Category:Data management]]
[[Category:Transaction processing]]