Хранить значения натуральных ключей необходимо, потому что они связывают хранимые данные с реальным миром (внешними классификаторами, реестрами и т.п.), и с ними работают бизнес-пользователи: в выпадающих списках, отчетах и дашбордах. Но в методологии Anchor Modeling для связи таблиц используются только суррогатные ключи, не подверженные изменениям, и это правильно. Поэтому нужно хранить связь натуральных ключей с суррогатным ключом, предпочтительно формата UUIDv7. Как же это сделать в методологии Anchor Modeling?
Авторы Anchor Modeling предлагают формировать составной натуральный ключ соответствующим представлением (view) из нескольких атрибутов разных сущностей (anchor), а для увеличения производительности использовать материализованное представление. Но связь с суррогатным ключом не может храниться в представлении, а материализованное представление невозможно дополнить новыми данными, сохранив при этом связь натуральных ключей с суррогатным ключом для прежних данных. То есть, это не работает.
Задача заключается в поиске суррогатного ключа по введенному натуральному ключу и дате, а также в поиске и выводе натурального ключа по суррогатному ключу и дате.
При этом натуральный ключ может быть составным. Состав, форматы и значения полей натурального ключа, полученные из разных источников данных, могут быть разными. Значения полей натурального ключа, соответствующего определенному суррогатному ключу, могут изменяться со временем.
Нужно выделить источники данных таким образом, чтобы на любой момент времени в прошлом для определенного суррогатного ключа существовало не более одного связанного натурального ключа из определенного источника данных. Иначе невозможно будет однозначно определить натуральный ключ по суррогатному ключу.
Эта задача может быть решена с помощью таблицы решений. В методологии Anchor Modeling таблица решений может моделироваться исторической (то есть, с полями start_date и end_date) таблицей связей (historized tie), в которой должны быть внешние ключи, соответствующие суррогатному ключу и атрибутам натурального ключа. При этом для каждого источника данных нужна отдельная таблица связей, либо в единой таблице связей нужен внешний ключ, указывающий на источник данных (anchor или knot).
Выводы этой статьи можно применить и к методологии Data Vault.
