Skip to content

Commit

Permalink
Update transactional-data.md
Browse files Browse the repository at this point in the history
Fixing two typos.
  • Loading branch information
Ed Price - MSFT authored and bennage committed Feb 28, 2018
1 parent 023d88e commit 9a724bb
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions docs/data-guide/concepts/transactional-data.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,9 +7,9 @@ ms:date: 02/12/2018

# Transactional data

Transactional data is information that that tracks the interactions related to an organization's activities. These interactions are typically business transactions, such as payments received from customers, payments made to suppliers, products moving through inventory, orders taken, or services delivered. Transactional events, which represent the transactions themselves, typically contain a time dimension, some numerical values, and references to other data.
Transactional data is information that tracks the interactions related to an organization's activities. These interactions are typically business transactions, such as payments received from customers, payments made to suppliers, products moving through inventory, orders taken, or services delivered. Transactional events, which represent the transactions themselves, typically contain a time dimension, some numerical values, and references to other data.

Transactions typically need to be *atomic* and *consistent*. Atomicity means that an entire transaction always succeeds or fails as one unit of work, and is never left in a half-completed state. If a transaction cannot be completed, the database system must roll back any steps that were already done as part of that transaction. In a traditional RDBMS, this rollback happens automatically if a transaction cannot be compoleted. Consistency means that transactions always leave the data in a valid state. (These are very informal descriptions of atomicity and consistency. There are more formal definitions of these properties, such as [ACID](https://en.wikipedia.org/wiki/ACID).)
Transactions typically need to be *atomic* and *consistent*. Atomicity means that an entire transaction always succeeds or fails as one unit of work, and is never left in a half-completed state. If a transaction cannot be completed, the database system must roll back any steps that were already done as part of that transaction. In a traditional RDBMS, this rollback happens automatically if a transaction cannot be completed. Consistency means that transactions always leave the data in a valid state. (These are very informal descriptions of atomicity and consistency. There are more formal definitions of these properties, such as [ACID](https://en.wikipedia.org/wiki/ACID).)

Transactional databases can support strong consistency for transactions using various locking strategies, such as pessimistic locking, to ensure that all data is strongly consistent within the context of the enterprise, for all users and processes.

Expand Down Expand Up @@ -41,4 +41,4 @@ Transactional data tends to have the following traits:

## See Also

[Online Transaction Processing](../scenarios/online-transaction-processing.md)
[Online Transaction Processing](../scenarios/online-transaction-processing.md)

0 comments on commit 9a724bb

Please sign in to comment.