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

[Ivanhoe]

Посмотрите, как в стандарте сделан справочник номенклатур, что такое Используемый продукт, а что такое просто продукт. Именно для кросс-компани там и введен единый код продукта. Посмотрите уже на стандартные кубы. Аккуратно и с точки зрения бизнеса, а не разработчика.

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

[Cardagant]

Цитата:

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

Посмотрите, как в стандарте сделан справочник номенклатур, что такое Используемый продукт, а что такое просто продукт. Именно для кросс-компани там и введен единый код продукта. Посмотрите уже на стандартные кубы. Аккуратно и с точки зрения бизнеса, а не разработчика.

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

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

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

Цитата:

Сообщение от 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 использовали как в качестве ключа, так и для того, чтобы проверять изменения хоть в таблице измерения, хоть в фактах. Можно лукапить только поле хэша вместо проверки каждого поля по отдельности.

[twilight]

Цитата:

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

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

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