Триггеры здесь не очень красиво смотрятся.DFilushinнадо было б считать не по всем полям, есть вспомогательные, их игнорироватьНа каждое изменение таких вспомогательных полей будет вызываться триггер,
делающий неслабый обсчет контрольной суммы или как минимум проверку изменения нужных полей.

А если, как ты говоришь, объекты разбросаны по разным таблицам. Это ж какие триггеры будут…
Допустим, есть таблицы A, B, C.
Объект «Накладная» хранит данные в таблице А и С.
Объект «Служебная записка» хранит данные в таблице В и С.
При изменении таблицы С, триггер должен выяснить с каким объектом он связан
(придется добавить ключик принадлежности, или (о ужас!) искать через FK таблиц A и B)
и продолжать проверку. А если данные объекта размазаны более чем по двум таблицам,
то очень тяжело представить логику таких триггеров. Либо она будет многократно дублироваться,
либо придется писать хитрую процедуру, которая в начале своей работы будет разбираться кто и в связи с чем ее вызвал.

Если реализовать DML-операции через процедуры, как было отмечено в прошлом топике,
то проверка будет в том месте, где ей надо быть.
Делай подобные DML процедуры и закрывай прямой доступ на insert/update/delete.
Процедурам которые меняют вспомогательные поля доступ на update даешь, это нормальная практика.

Сторонними средствами (если не знать пароля SYSDBA) ничего не получится изменить!

Верно!
И подумай какая красота будет в программе.
В свойстве UpdateSQL пишешь просто:
Аналогичное и для InsertSQL и DeleteSQL
Для тех, кто любит ООП, это есть инкапсуляция.
Что там творится внутри DML_Invoice_Update вызывающей программе не интересно.
Может со временем появится таблица D. Ты добавишь ее обработку в процедуре, а в программе ничего менять не нужно, разве что SelectSQL.