Отменить в транзакционной базе данных

Я не знаю, как реализовать свойство отмены удобных интерфейсов с использованием транзакционной базы данных.

С одной стороны, желательно, чтобы у пользователя была многоуровневая (бесконечная) возможность отмены, как указано здесь в ответе. Шаблоны, которые могут помочь в этой проблеме, — это Memento или Command.

Однако, используя сложную базу данных, включающую триггеры, постоянно растущие порядковые номера и необратимые процедуры, трудно представить, как действие отмены может работать в точках, отличных от границ транзакции. Другими словами, отменить до момента, когда транзакция, зафиксированная в последний раз, является просто откатом, но как можно вернуться к другим моментам?

ОБНОВЛЕНИЕ (на основе ответов до сих пор): я не обязательно хочу, чтобы отмена работала, когда модификация уже зафиксирована, я бы сосредоточился на работающем приложении с открытой транзакцией. Всякий раз, когда пользователь нажимает кнопку «Сохранить», это означает фиксацию, но перед сохранением — во время той же транзакции — должна работать отмена. Я знаю, что использование базы данных в качестве постоянного уровня — это всего лишь деталь реализации, и пользователь не должен беспокоиться об этом. Но если мы думаем, что «идея отмены в базе данных и в графическом интерфейсе — это принципиально разные вещи», и мы не используем отмену с базой данных, то бесконечная отмена — это просто модное слово. Я знаю, что "откат - это... не пользовательская отмена".

Итак, как реализовать отмену на уровне клиента с учетом «каскадных эффектов в результате любого изменения» внутри одной и той же транзакции?

Решение проблемы

Идея отмены в базе данных и в графическом интерфейсе — это принципиально разные вещи; GUI будет однопользовательским приложением с низким уровнем взаимодействия с другими компонентами; база данных — это многопользовательское приложение, в котором изменения могут иметь каскадный эффект в результате любого изменения.

Что нужно сделать, так это позволить пользователю попробовать применить предыдущее состояние как новую транзакцию, которая может работать, а может и не работать; или, в качестве альтернативы, просто не иметь отмен после фиксации (аналогично отмене после сохранения, что является опцией во многих приложениях).