DAX и хранилище данных

[Alex_K]

Цитата:

Сообщение от Cardagant

Затем, чтобы не получилось некоего "схлопывания" записей. Например. опять же с одинаковыми кодами. Выход - генерить собственный ключ на основе трёх полей.
Совсем не переносить составной ключ ведь нельзя.

HASHBYTES (Item_Id+DataareaID) будет неплохим аналогом бизнес-ключа измерения. По крайней мере, позволит аккуратно отрабатывать SCD. Если такой код назначать однократно и сохранять в InventTable, то это будет по Кимбаллу называться durable key. В таком случае, даже изменение кода номенклатуры не нарушит целостность данных в DWH.

Код компании заодно можно добавить в атрибуты измерения Номенклатура и получить level-based иерархию Компания-Номенклатура. По этому же атрибуту можно будет в кубике или BI-системе разграничить доступ к элементам измерения.

Но само собой, проблему унификации справочника это не решит. Тут действительно нужна или "взрослая" MDM или её самодельная реализация в аксе в виде таблиц соответствия.

[Raven Melancholic]

Вот с использованием HASHBYTES никак не соглашусь. В зависимости от алгоритма это минимум 16 байт. Мне думается, что уж гораздо проще использовать какой-нибудь другой способ генерации уникального значения с размером поменьше.

[Cardagant]

Цитата:

Сообщение от Raven Melancholic

Вот с использованием HASHBYTES никак не соглашусь. В зависимости от алгоритма это минимум 16 байт. Мне думается, что уж гораздо проще использовать какой-нибудь другой способ генерации уникального значения с размером поменьше.

Можно конвертировать в bigint, тогда ключ будет 8 байт.

[Alex_K]

Если в DWH мы, как положено, используем суррогатные ключи, то размер бизнес-ключа (или durable-ключа) значения не имеет. Плюс-минус десяток микросекунд на запись при выполнении ETL-процесса - по сравнению с загрузкой/процессингом длиннющей таблицы фактов сущий пустяк.

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

[Cardagant]

Цитата:

Сообщение от Alex_K

Если в DWH мы, как положено, используем суррогатные ключи, то размер бизнес-ключа (или durable-ключа) значения не имеет. Плюс-минус десяток микросекунд на запись при выполнении ETL-процесса - по сравнению с загрузкой/процессингом длиннющей таблицы фактов сущий пустяк.

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

А как Вы использовали HASHBYTES() для проверки изменения числовых значений фактов?

Не в строку же конвертировали?

[Alex_K]

Цитата:

Сообщение от Cardagant

А как Вы использовали HASHBYTES() для проверки изменения числовых значений фактов?

Не в строку же конвертировали?

Ну было дело... Конвертировал... Только не hashbytes(), а какой-то другой случай с бинарным типом данных.
А вообще, в SQL Server 2008 и выше есть побитовые операторы.
Сравнил, если результат равен 0 - налево, иначе - направо.

Вообще, "зависит от...". Если важно иметь возможность (мало ли зачем) видеть значение ключа/атрибута глазками, лучше сразу привести к строке и сохранить в таблице. Опять же, стоимость хранения и чтения в запросах для такой строки невелика, да и использоваться это поле будет только в ETL.