Why can an uncommitted transaction change data?

Question

SQL

Actually the question is why a transaction that is not completed (commit) is able to change the data in the cache, and not create a copy of the object, or at least a copy of the changed part.
Here we have the situation as in the screenshot:
1) Why can't we check the actions for integrity and correctness, and then change the data after the commit? Create a local A, write to it, after approval, write to the one in the cache, thereby disappearing, the problem of "dirty data".
2) How, after all the actions, even after rewriting A, did we get a rollback? (As I understand it, if A is overwritten, then the database actually checked for integrity, etc.)
3) Tell us who gives the final "fix \ rollback" ?
Well, or point out the errors, maybe I didn’t catch up with something ...

Answer 1

Read on. This seems to be a prelude to describing transaction isolation levels.
READ UNCOMMITTED - allows the DBMS to show data that has not yet been committed. This does not mean that the DBMS should behave this way at this isolation level, but the behavior is allowed by the standard for this isolation level. For example, in the mentioned postgresql at step t4 900 you can never get, even on read uncommitted.

Answer 2

"Clean" data is far from always important, it happens that speed is more important.
Here are two examples:
For example, what is the fundamental difference for you - will there be 1 like more or not?
On the other hand, in banking, the little things matter.
Therefore, sometimes consciously reduce "purity".

Answer 3

stackoverflow.com/questions/6477574/do-database-tr...