Essentially they end up rebuilding the "transaction log" that most RDBMS's use to commit data safely. Before any data is written to the "data" files of the dat

Essentially they end up rebuilding the "transaction log" that most RDBMS's use to commit data safely. Before any data is written to the "data" files of the database, it is written to a "log" file sequentially. Once that has succeeded, it will write to the data file, then write to the log file again to say that the write was successful. That way if the database breaks during the write, the system knows about it. It's also useful because it allows you to restore the database to a point in time, as you have a full log of all the transactions run (and you know how to un-run them). In this case, they just make the transaction log a little more accessible. For your example, erroneous historical data would remain in the system but with a new record being added indicating that at a certain date and time the old record was replaced with the new one. Basically if you think of a store processing a purchase for $100 and refund of $100 as 2 transactions (for $100 and -$100) rather than simply deleting the first transaction. This is important because things may have happened between the deposit of money and its refunding (e.g. interest payments).