У клиента может измениться бизнес-идентификатор, а исторические факты должны остаться привязанными к прежней сущности. Зачем аналитической модели отдельный суррогатный ключ?
Суррогатный ключ даёт сущности стабильный внутренний идентификатор, независимый от изменяемого бизнес-идентификатора. Факты связываются с версией или экземпляром сущности по этому ключу, поэтому изменение внешнего идентификатора не переписывает исторические связи и не искажает прошлые отчёты.
В операционных системах естественные ключи часто совпадают с идентификаторами из предметной области: номером клиента, договора или документа. Со временем такие значения могут измениться из-за исправления ошибки, объединения систем или изменения бизнес-правил.
Аналитические системы должны сохранять исторический контекст. Поэтому в моделях хранилищ отделяют естественный ключ источника от внутреннего ключа хранилища, который не зависит от изменений во внешней системе.
Если факт ссылается непосредственно на изменяемый бизнес-идентификатор, изменение этого значения создаёт неоднозначность. Старые факты могут начать связываться с новой записью, потерять связь или потребовать массового обновления.
Проблема особенно заметна при ведении истории атрибутов клиента. Например, один и тот же клиент мог иметь разные значения идентификатора в разных источниках или в разные периоды, но продажи за прошлые даты должны относиться к состоянию клиента, актуальному тогда.
В аналитической модели клиент получает суррогатный ключ, обычно техническое значение, уникальное внутри хранилища. Бизнес-идентификатор хранится отдельно как атрибут, необходимый для сопоставления с источниками.
При загрузке система ищет клиента по бизнес-идентификатору и правилам идентификации. Если это прежняя сущность, сохраняется её суррогатный ключ; если появилась новая историческая версия измерения, создаётся новая строка с другим суррогатным ключом. Факт получает ключ той версии, которая была актуальна для него по правилам загрузки.
Это позволяет отделить два случая: изменение атрибута существующего клиента и появление другой сущности с похожим или повторно использованным бизнес-идентификатором. Сам по себе суррогатный ключ не решает задачу поиска соответствий: для неё нужны правила сопоставления, контроль качества и, при необходимости, история источников.
Основной компромисс — усложнение загрузки и отладки. Пользователю труднее объяснить технический идентификатор, а соединение с источником требует преобразования ключей. Зато модель устойчивее к изменениям источников, поддерживает историю и не заставляет обновлять большие объёмы фактов.
Суррогатный ключ не следует считать доказательством тождественности объектов. Если источник переиспользовал бизнес-идентификатор для другого клиента, это должно быть выявлено отдельными правилами; автоматическая привязка только по номеру может испортить историю.
Компания объединяет CRM и систему продаж. В CRM клиент сначала имел идентификатор C-104, затем из-за миграции получил 84721. Вариант с использованием бизнес-идентификатора напрямую требует обновлять ссылки в исторических фактах или поддерживать сложную логику сопоставления; его плюс — простота первичной загрузки, минус — хрупкость истории.
Вариант с одним ключом на каждую строку клиента хорошо сохраняет изменения атрибутов, но не всегда позволяет отличить изменение клиента от новой сущности. Выбранная схема использует стабильный суррогатный ключ для сущности, отдельное хранение прежних бизнес-идентификаторов и правила проверки соответствий.
В результате новые данные связываются с нужной сущностью без переписывания фактов, а исторические отчёты сохраняют корректные связи. При этом спорные случаи попадают в контрольный поток, а не разрешаются молча эвристикой.
1. Нужно ли создавать новый суррогатный ключ при каждом изменении атрибута клиента?
Нет, это зависит от требования к истории. Если нужно хранить только текущее значение атрибута, строку можно обновить, сохранив тот же ключ. Если требуется знать значение атрибута на дату факта, для значимого изменения создают новую историческую версию с новым ключом и периодом её действия.
2. Чем суррогатный ключ отличается от просто неизменяемого бизнес-идентификатора?
Неизменяемый бизнес-идентификатор может быть достаточен, если его уникальность, стабильность и область действия гарантированы на всём жизненном цикле данных. Суррогатный ключ дополнительно изолирует хранилище от правил и форматов источников, позволяет объединять несколько систем и различать версии или сущности при коллизиях внешних идентификаторов.
3. Как избежать появления нескольких суррогатных ключей для одного клиента при повторной загрузке?
Нужны детерминированный поиск существующей сущности, уникальные ограничения или контрольные проверки на уровне измерения, а также идемпотентная логика загрузки. При временной недоступности справочника нельзя безусловно создавать новую сущность на каждый неполный входной пакет: иначе повторная обработка породит дубликаты и разорвёт аналитику.