CACrown ArchivesThe cinema collection
Menu
Research dossier · General Reference

Atomicity (database systems)

that a transaction is either completed completely or not at all

Cross-disciplinary reference desk with index cards, atlas, dictionary and catalogue
General referenceInterpretive dossier study · Crown Archives visual atlas
Record originEnglish Wikipedia
Text licenseCC BY-SA 4.0
Source revisionSep 8, 2026
Entity authorityQ3306359
Source-derived summary

In database systems, atomicity (; from Ancient Greek: ἄτομος, romanized: átomos, lit. 'undividable') is the property of a database transaction consisting of an indivisible and irreducible series of database operations such that either all occur, or none occur. It is one of the ACID transaction properties: Atomicity, Consistency, Isolation, Durability.

A guarantee of atomicity prevents partial database updates from occurring, because they can cause greater problems than rejecting the whole series outright. As a consequence, an atomic 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).

An example of transaction atomicity could be a digital monetary transfer from bank account A to account B. It consists of two operations, debiting the money from account A and crediting it to account B. Performing both of these operations inside of an atomic transaction ensures that the database remains in a consistent state, if either operation fails there will not be any unaccountable credits or debits affecting either account.

The same term is also used in the definition of First normal form in database systems, where it instead refers to the concept that the values for fields may not consist of multiple smaller values to be decomposed, such as a string into which multiple names, numbers, dates, or other types may be packed.

Orthogonality

Atomicity does not behave completely orthogonally with regard to the other ACID properties of transactions. For example, isolation relies on atomicity to roll back the enclosing transaction in the event of an isolation violation such as a deadlock; consistency also relies on atomicity to roll back the enclosing transaction in the event of a consistency violation by an illegal transaction.

As a result of this, a failure to detect a violation and roll back the enclosing transaction may cause an isolation or consistency failure.

Implementation

Typically, systems implement Atomicity by providing some mechanism to indicate which transactions have started and which finished; or by keeping a copy of the data before any changes occurred (read-copy-update).

Editorial summary

This brief starts where responsible research should: with the source description of “Atomicity (database systems)” as that a transaction is either completed completely or not at all. Everything that follows is an evidence route, not borrowed authority.

Editorial reviewA concise reference frame for defining the subject, testing terminology and identifying the institution closest to the evidence. The current 359-word lead offers orientation but no explicit four-digit date, so chronology should not be assumed. The selected authority fields contribute no independent date. The account is most persuasive where Atomicity, database and systems can be independently traced.
Editorial analysis

Why this record matters

The subject matters to the general reference register because the source frames it as that a transaction is either completed completely or not at all. Its deeper value depends on whether names, dates, institutions and citations support that framing.

Evidence profile

The citation trail is more important than the brevity of the summary: it shows where individual claims can be examined in context. The source revision retrieved here is dated Sep 8, 2026. The linked authority identifier is Q3306359. None of the 0 selected statements returned an explicit reference.

Critical limits

Overview language is designed for orientation and should not be treated as a substitute for the evidence cited beneath it. The source lead contains qualifying language; that uncertainty should survive quotation, summary and reuse. Authority statements aid reconciliation but still require their own references, qualifiers and ranks to be checked.

How to read it

Use the entry as an orientation point, then follow its citations and revision history. Names, dates and institutional relationships should be checked against the original record.

Best used for
  • Subject orientation
  • Search vocabulary
  • Locating named sources
Verify next

The closest primary source, responsible institution and strongest cited specialist reference.

Three-step research path

  1. Establish the record: confirm the title “Atomicity (database systems)”, its source revision and the description used here.
  2. Expand the search: follow Atomicity (database systems) primary sources, Atomicity (database systems) archive and Atomicity research across catalogues and specialist indexes.
  3. Test the account: compare the strongest cited source with the responsible institution’s current record and note any disagreement.

Questions for further research

  1. Which source most directly establishes the central claim about “Atomicity (database systems)”?
  2. Which institution is responsible for the underlying evidence?
  3. Which cited source is closest to the event, object or claim?
Subject index

Search terms from this dossier

Source & attribution

This entry incorporates text from Atomicity (database systems)” on English Wikipedia. Contributors are listed in the page history. Text is available under the Creative Commons Attribution-ShareAlike 4.0 License. Selected authority identifiers and statements are retrieved from Wikidata under CC0; their references and qualifiers remain part of the verification path.