Суррогатные ключи. Конвейерная обработка суррогатных ключей

Автор оригинала: Ральф Кимбалл (все статьи)
Перевод на русский язык: Михаил Замыслов

Хорошая система суррогатных ключей стоит трудов

В прошлом месяце я заострил внимание на необходимости использования суррогатных ключей для каждой опреации объединения в хранилищах данных. Иными словами каждый ключ объединения между таблицей фактов и таблицей размерностей должен быть суррогатным ключом или независимым целочисленным числом, но не натуральным или значащим (зависящим) ключом. Значение суррогатного ключа должно начинаться единицей, второе значение должно быть два и так далее. Не должно быть никакой связи. Взглянув на суррогатный ключ вы не должны иметь возможности представить себе какие данные содержит идентифицированная им запись. Все суррогатные ключи представляются 4х байтным целочисленным (integer, int - прим. переводчика) числом (иногда даже 2х байтным для небольших размерностей), т.к. 4мя байтами можно представить более 2 млрд. записей размерности. В своей практике я не встречал таблиц размерностей соизмеримых с двумя миллиардаим записей.

В прошлой статье я отметил, что суррогатные ключи разрешают проблему администратора хранилищ данных в представлении медленно изменяющихся размерностей, в принципе как и представление неизвестных (unknown) или еще неопределенных (not-yet-recorded) значений размерности. В завершении следует отметить, что применение суррогатных ключей позволяет полностью контролировать хранилище данных, изолируя его от изменений в системе производства.

С момента создания записи в таблице размерности с корректным суррогатным ключом, каждая таблица фактов, ссылающаяся на это измерение должна содержать соответствующий суррогатный ключ. В таком случае суррогатный ключ в таблице фактов становится внешним ключом. Определите для себя таблицу размерностей задающей значения ключей ("keymaster") для измерения. Таблица измерения определяет верность суррогатного ключа, т.к. он является первичным ключом таблицы измерения.

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

Ключи для таблиц измерений

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

Когда мы говорим о создании ключей таблиц размерностей, мы должны выделить первичную загрузку (импорт) таблицы размерности от последующих. Первичная загрузка (импорт) скорее всего создаст число записей точно совпадающих с числом записей необзодимых для определения данных производства. Преположим что данные производства точны, достоверны и не содержат дублирующихся записей. Исходя из этого, просто добавляем последовательсноть суррогатных ключей по мере первичной загрузки размерности. Этот процесс является простым последовательным чтением входящих данных как показано на рисунке.

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

При анализе импортируемых данных определяющих размерности, наиболее сложным является случай, когда запись с данным натуральным ключом уже импортирована, но в системе производства некоторые поля этой записи изменились. Это классический пример медленно изменяющихся размерностей; например товар может претерпеть небольшие изменения описывающих упаковку или состав, но артикул товара (клюя товара) не изменился, или клиент имеет тот же идентификатор, но некторые сведения о нем, такие как семейное положение, изменились. Для разрешения этой проблемы у вас должна быть сформирована политика медленно изменяющихся измерений. Политика гласит что если определенное (достоверное или неизменяющееся - прим. переводчика) описательное поле размерности изменяется, данные в записи полностью переписываются (так называемые изменения Типа 1) (SCD-1 - прим. переводчика). Но если изменяются другие описательные поля, такие как семейное положе�