Я понимаю общую концепцию суррогатного ключа в среде DWH. Но есть два аспекта, которые я не понимаю и не могу найти информацию о них:
1) Суррогатный ключ уникален для одной строки - он используется как общий дескриптор отношений между всеми ячейками в строке. Из-за того, как хранятся данные, суррогатный ключ не является строго необходимым для определения взаимосвязи между ячейками в строке. Но если ваша строка представляет счетную идентичность (строку) в объекте (таблице), что было бы в случае, если ваша база данных нормализована, то ссылка на один единственный суррогатный ключ (обычно первичный ключ) проще, чем сохранение ссылки всем участникам первичного ключа. Например, поддерживать индекс для одного компактного столбца проще, чем для всей строки.
На самом деле таблицы, суррогатные ключи имеют другое применение. Поскольку данные часто объединяются из многих источников, есть вероятность, что вы столкнетесь с проблемой составных первичных ключей (используется несколько объединенных столбцов, однозначно идентифицирующих каждую строку), а также с проблемой дублирования бизнес-ключей (ключей, взятых из разных исходные системы). Поскольку для поиска используются суррогатные ключи, важна их компактность. Используйте возрастающее целое число или хэш фиксированной длины и сохраните бизнес-ключ из источника в отдельном столбце.
2) На этот вопрос сложно ответить, потому что я не знаю, какое программное обеспечение вы используете для управления размерами и иерархиями. Это сильно влияет на вещи. В типичной денормализованной архитектуре Кимбалла в таблице измерений суррогатный ключ используется для ссылки на уникальную строку в таблице измерений. В таблице измерений с несколькими иерархиями значение этого может быть немного запутанным. Суррогатный ключ будет действительно уникальным только для иерархии с наибольшей кардинальностью (количеством элементов), поскольку именно он будет определять, сколько строк будет в таблице измерений. Таким образом, практика такова, что ключ уникален для таблицы измерения И ровно ОДНОЙ из иерархий в ней - той, которая имеет наибольшее количество элементов. Если к этому добавить управление версиями иерархий (медленно меняющиеся измерения), точное значение суррогатного ключа может быть обманчивым.
Примечание/Рэнт: обычно я нахожу идею нескольких иерархий в одной таблице измерений довольно ужасной. Правда, это уменьшает количество ссылок на измерения в таблице фактов, но есть и недостатки. Денормализация таблицы измерений имеет несколько последствий (уродливое дублирование). Одним из них является риск двойного счета при соединении в таблице измерений. Это часто исправляется (или замалчивается) используемыми программными пакетами, проверяя, совпадают ли значения, а затем суммируя их и уменьшая количество, если они совпадают. Но это распространенный источник аномалий подсчета и ошибок суммирования, с которыми в будущем могут справиться только действительно грязные хакеры. Которых я видел довольно много.
да, суррогатный ключ уникален для одной строки - он используется как общий дескриптор отношений между всеми ячейками в строке. Из-за того, как хранятся данные, суррогатный ключ не является строго необходимым для определения взаимосвязи между ячейками в строке. Но если ваша строка представляет счетную идентичность (строку) в объекте (таблице), что было бы в случае, если ваша база данных нормализована, то ссылка на один единственный суррогатный ключ (обычно первичный ключ) проще, чем сохранение ссылки всем участникам первичного ключа. Например, поддерживать индекс для одного компактного столбца проще, чем для всей строки.
