Хранить данные - важно. Иметь возможность их прочитать - полезно. Не оболваниться в процессе внесения в эти данные изменений - жизненно необходимо для любой информационной системы. Свойство "не оболваниться" и воплощают в себе транзакции БД.
Что имеем по факту: транзакция БД - это просто одна из функций, которая гарантируется нам конституцией используемой БД и её СУБД. В общем-то, сейчас эта функция есть в наличии почти у любой уважающей себя (СУ)БД. Псевдокод транзакции будет выглядеть как-то так:
[ START TRANSACTION;
UPDATE accounts
SET balance = balance - 100
WHERE id = 1;
COMMIT (or ROLLBACK)]
Логика этого псевдокода проста: пользователь инициирует выполнение транзакции, между компьютером пользователя и базой данных устанавливается стабильное соединение; далее последовательно выполняются команды внутри транзакции - внести изменения в данные, что-то удалить, что-то создать; далее транзакцию нужно красиво завершить одним из двух способов - либо сделать ROLLBACK, и всё отменить, либо сделать COMMIT - и всё подтвердить.
Логика транзакций устроена так, что пока нет коммита, изменения либо не сохраняются непосредственно на физическом носителе (например, временно живут записанными в специальный лог), либо есть возможность их откатить (во временный лог записываются старые значения, и если что-то пойдёт не так, значения будут оттуда перезаписаны обратно на носитель). Эта логика реализует свойство атомарности, которое ожидают от транзакций: либо всё, либо ничего.
Когда это важно? Например, чтобы предотвратить такую неприятную ситуацию: пользователь оплатил заказ, мы приняли оплату, записали поступление в базу, но из-за сбоя электричества не создали заказ пользователя. В общем, если есть некоторая логика, которую важно гарантировано реализовать сразу полной пачкой, тогда нужна атомарность.