Кейс: изменение значения первичного ключа

Если значение первичного ключа изменяется не при выполнении специальных административных процедур, а в ходе обычной эксплуатации системы, то это выглядит как ошибка проектирования системы. Однако, иногда приходится иметь дело с такими системами.

Вопрос об изменении значения первичного ключа может также возникнуть в контексте интеграции систем.

Например, система А посылает в шину данных сообщения об изменениях бизнес-сущности Товар. И в этих сообщениях каждый отдельный экземпляр сущности – индивидуальный товар – идентифицируется бизнес-ключом, значение которого может быть изменено пользователем системы А (см. мой пост Кейс: изменение значения бизнес-ключа). А в системе Б, которая получает сообщения из шины данных и на их основании актуализирует собственную копию бизнес-сущности Товар, бизнес-ключ является первичным ключом таблицы в БД. И на него ссылаются внешние ключи из других таблиц.

Сможет ли система Б обновить первичный ключ, если она получит сообщение об изменении бизнес-ключа?

Кейс: изменение значения бизнес-ключа

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

Бизнес-ключ, как правило, имеется у справочников (страны, типы заказа, ...), ресурсных сущностей (товар, поставщик, ...) и операционных сущностей (заказ, промо-акция, ...). Другие сущности (конфигурации, бизнес-транзакции) используют внешние бизнес-ключи как часть собственного уникального ключа.

Бывает, что бизнес-ключ изменяется пользователем.

ddiff. Эффективное сравнение данных в разных БД

Как вы поступаете, когда нужно сравнить два больших набора данных? Скорее всего, первое, что вы делаете, – проверяете, одинаковое ли количество строк в каждом наборе и одинаковые ли суммы по некоторым столбцам. Можно еще сравнить количество уникальных значений в одних и тех же столбцах в двух наборах, минимальные и максимальные значения столбцов, сумму длин строк в строковых столбцах.

К сожалению, СУБД не предоставляют агрегатных функций для расчета хэша для набора строк. Поэтому для быстрого и грубого сравнения двух наборов данных приходится использовать возможности имеющихся агрегатных функций. Например:

Активирование и деактивирование логических сущностей в оперативной БД

Каждая логическая сущность предметной области

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

Например, запись справочника может быть активной в течение всего жизненного цикла – от ее создания до удаления, или до выведения системы из эксплуатации. А экземпляр мастер-данных (товар, партнер, сотрудник и т.д.), как правило, активен в течение некоторого периода времени, пока с ним работают бизнес-процессы (пока товар закупается или продается, пока партнер связан договорными отношениями, пока сотрудник не уволился, и т.д.).

Информация

Что такое информация?

Два подхода к ответу на этот вопрос заключены в следующих известных высказываниях:

• "Информация физична." Рольф Ландауэр.
• "Это различие, порождающее различие." Грегори Бейтсон.

Вся информация во Вселенной имеет физический носитель, и все физические тела несут информацию – от элементарных частиц до жестких дисков, книг и систем космического масштаба.