While technology was advancing in 1970–80s, for the first time users started to work together with the same data on a single or multiple machines. Working on a shared place could easily lead us to problems, data could overwritten while other user were doing a calculations with the exact same data. In the other hand, developers had to think about power outages and human errors to prevent any kind of lost or mistake in their storage systems.
Eventually working on the same data in the same machine caused operational problems. And of course, there was power outages and human errors as well. There should be some rules defined for database transactions intended to ensure reliability in any event of failures. At that stage, ACID theorem came to light offering a set of rules to prevent conflicts between operations of database transactions.
There was different possibilities to consider and variety of problems to take care of; which were eventually combined under abbreviation of ACID. Every letter in ACID stands for a rule. A for Atomicity, C for Consistency, I for Isolation and D for Durability.
Lets look deeper;
This rule tells us that every steps of a transaction are treated and processed as a single action. The transaction is going to be completed only when it’s all components completed successfully; if any step of transaction fails whole process goes invalid state then the database remains unchanged.
This is about data integrity. Consistency refers to the rules that given transaction must change affected data only in allowed principles. Any data that written database have to be relying on pre-defined rules of the database objects. This rules can be constraints declared for table or cascades, triggers etc.
Isolation is about concurrency and this property ensures that multiple transactions can run concurrently. Every transaction will be executed seriall, one after the other. When a transaction is executing, other transactions( we can say users) is not allowed to use or even see any unfinished transaction or its result. Isolating transactions from each other helps to maintain state of database. Enabling multiple transactions to occur independently without interference of other transactions prevents miscalculations and confuses.
Once a transaction is committed, it will persist and will not be undone to accommodate conflicts with other operations. it will remain committed even in the case of a system failure
All RDBMS relies on the rules above to provide and maintain reliability.