1) The atomicity of transactions ensures that each database transaction is a single unit that adopts an "all or nothing" approach to execution. If any statement in the transaction fails, the entire transaction is rolled back.
2) Relational databases also ensure the consistency of each transaction with the database's business rules. If any element of an atomic transaction would disrupt the consistency of the database, the entire transaction fails.
3) The database engine enforces isolation between multiple transactions occurring at or near the same time. Each transaction occurs either before or after every other transaction and the view of the database that a transaction sees at its beginning is only altered by the transaction itself before its conclusion. No transaction should ever see the intermediate product of another transaction.
4) The final ACID principle, durability, ensures that once a transaction is committed to the database, it is permanently preserved through the use of backups and transaction logs. In the event of a failure, these mechanisms may be used to restore committed transactions.
NoSQL databases, on the other hand, embrace situations where the ACID model is overkill or would, in fact, hinder the operation of the database. Instead, NoSQL relies upon a softer model known, appropriately, as the BASE model. This model accommodates the flexibility offered by NoSQL and similar approaches to the management and curation of unstructured data. BASE consists of three principles:
1) Basic Availability: The NoSQL database approach focuses on availability of data even in the presence of multiple failures. It achieves this by using a highly distributed approach to database management. Instead of maintaining a single large data store and focusing on the fault tolerance of that store, NoSQL databases spread data across many storage systems with a high degree of replication. In the unlikely event that a failure disrupts access to a segment of data, this does not necessarily result in a complete database outage.
2) Soft State: BASE databases abandon the consistency requirements of the ACID model pretty much completely. One of the basic concepts behind BASE is that data consistency is the developer's problem and should not be handled by the database.
3) Eventual Consistency: The only requirement that NoSQL databases have regarding consistency is to require that at some point in the future, data will converge to a consistent state. No guarantees are made, however, about when this will occur. That is a complete departure from the immediate consistency requirement of ACID that prohibits a transaction from executing until the prior transaction has completed and the database has converged to a consistent state.
The BASE model isn't appropriate for every situation, but it is certainly a flexible alternative to the ACID model for databases that don't require strict adherence to a relational model.