Every multi-statement change to a database should generally happen inside a transaction — a unit of work that either fully commits or fully rolls back, with no partial state visible in between:
BEGIN TRANSACTION;
UPDATE Employees SET salary = salary - 1000 WHERE id = 1;
UPDATE Employees SET salary = salary + 1000 WHERE id = 2;
COMMIT;
If the second UPDATE failed partway through — a constraint violation, a dropped connection — a transaction ensures the first one gets rolled back too, rather than leaving Alice's money deducted with nowhere for it to have gone. This matters directly to everything above: aggregate queries and reports are only as trustworthy as the transactional guarantees behind the writes that produced the data they're reading. See the ACID guarantees article for exactly what a transaction promises, and how isolation levels affect what a concurrent SELECT is allowed to see mid-transaction.