Если вы правильно спроектировали базу данных, у вас мало проблем с целостностью данных. Это означает выполнение работы по настройке отношений PK / FK, ограничений данных, правильных типов данных, триггеров и т. Д. Это особенно означает, что вы никогда не думаете, что приложение будет обрабатывать все это. Это может означать создание заданий для проверки определенных типов ввода данных и уведомление кого-либо о возможных проблемах. Это может означать пересмотр всех ваших импортов данных для использования стандартного набора процедур очистки. Это может означать создание способа идентификации и слияния дубликатов записей (во всех сложных базах данных должно быть написано приложение с дедупликацией, чтобы пользователи могли выбирать, какие данные сохранять и какие сохранять при обнаружении дубликатов).
Если вы неправильно спроектировали базу данных, вам нужно устанавливать эти вещи в базе данных по одному в зависимости от ваших бизнес-правил, исправляя неверные данные на ходу. Нет простого решения, если разработчики не смогли правильно спроектировать проект.
Поскольку потребности каждой базы данных очень разные, никто из тех, кого я знаю, не автоматизировал способ применения всех правил целостности, это большая часть того, что делает дизайнер базы данных при разработке базы данных. Я, конечно, не доверял бы ни одной программе COTS, чтобы сделать это, либо исходя из того, насколько плохо спроектирована каждая база данных COTS, которую я когда-либо испытывал к неудовольствию.