The
most common architecture of an OLTP system that uses transactional data is a three-tier architecture that typically consists of a presentation tier, a business logic tier, and a data warehouse tier. The presentation level is the front-end, where the transaction originates through human interaction or is generated by the system. The logical level consists of rules that verify the transaction and ensure that all the data needed to complete the transaction is available. The data store tier stores the transaction and all data related to it.
The main features of an online transaction processing system are as follows
:
- ACID compliance: OLTP systems must ensure that the entire transaction is recorded correctly. A transaction is usually an execution of a program that may require the execution of multiple steps or operations. It can be complete when all parties involved recognize the transaction, or when the product/service is delivered, or when a certain number of updates are made to specific tables in the database. A transaction is successfully recorded only if all the steps involved are executed and recorded. If there is any error in any of the steps, the entire transaction must be aborted and all steps must be removed from the system. Therefore, OLTP systems must comply with atomic, consistent, isolated and durable (ACID) properties to ensure the accuracy of the data in the system.
- Atomic: Atomicity controls ensure that all steps in a transaction are completed correctly as a group. That is, if any step between transactions fails, all other steps must also fail or be reversed. The successful completion of a transaction is called confirmation. The error of a transaction is called an abortion.
- Consistent: The transaction preserves the internal consistency of the database. If you run the transaction itself against a database that is initially consistent, when the transaction finishes, the database execution will be consistent again.
- Isolated: The transaction is executed as if it were running alone, with no other transactions. That is, the effect of executing a set of transactions is the same as executing them one at a time. This behavior is called serialization and is typically implemented by locking specific rows in the table.
- Durable: The results of the transaction will not be lost in a failure.
- Concurrency: OLTP systems can have enormously large user populations, with many users trying to access the same data at the same time. The system must ensure that all these users trying to read or write to the system can do so simultaneously. Concurrency controls ensure that two users accessing the same data in the database system at the same time will not be able to change that data, or that one user has to wait until the other user has finished processing before changing that data.
- Scale: OLTP systems must be able to scale up and down instantly to manage transaction volume in real time and execute transactions simultaneously, regardless of the number of users trying to access the system.
- Availability: An OLTP system must always be available and always ready to accept transactions. The loss of a transaction can lead to loss of income or can have legal implications. Because transactions can be executed from anywhere in the world and at any time, the system must be available 24/7.
- High performance and short response time: OLTP systems require nanosecond or even shorter response times to maintain business user productivity and meet growing customer expectations.
- Reliability: OLTP systems typically read and manipulate small, highly selective amounts of data. It is paramount that at any given time the data in the database is trusted and trusted by the users and applications that access that data.
- Security: Because these systems store highly sensitive customer transaction data, data security is critical. Any non-compliance can be very costly for the company.
- Recoverability: OLTP systems must have the ability to recover in the event of any hardware or software failure.
