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

[Владимир Максимов]

Цитата:

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

Только что рассмотрел не номенклатуру, а измерения Клиентов и Поставщиков. Стандарт для всех иерархий атрибутов будь то ключ или обыная иерархия типа Группа клиентов / поставщиков пишут составной ключ DataArea+Поле ключа. Значит, стандарт не подразумевает обединением одинаковых кодов или названий ли групп в единый элемент в разрезе компаний, что в принципе логично, так как это могут быть разные клиенты или поставщики или разные группы с этим кодом.(о чём мы до этого вели дискуссию)

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

Собственно, для решения проблемы и создаются разные базы данных. Одна - для ведения документов в Axapta, другая - для формирования отчетов (кубов). Эти базы данных имеют принципиально разную структуру

"Составной ключ" - это "неизбежное зло" в рамках существующей идеологии Axapta. Раз "в принципе" есть разделение по компаниям, то очевидно, любой ключ в Axapta в своем составе должен иметь ссылку на компанию. Иначе как делить данные по компаниям-то?

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

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

[Cardagant]

Цитата:

Сообщение от Владимир Максимов

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

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

[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.

[twilight]

Цитата:

Сообщение от Владимир Максимов

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

Объем зависит от типа ключа или длины ключа? Зависимость экспоненциальная или линейная?