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

[Raven Melancholic]

Опять же, если привязываться к конкретным реализациям (та же DAX2012) по номенклатуре, то все равно даже код номенклатуры не совсем определяет нужную позицию.
Например, если использовать в качестве системы планирования Hypirion, но нужно как-то определять систему НСИ. Часто используемая связка для Hypirion в качестве системы НСИ в России это "Норма" от Ланит. В Норме нет таких понятий, которые есть в DAX как "Конфигурация", "Размер", "Цвет", в итоге приходится комбинации номенклатура+конфигурация+что-то из DAX (в DAX2012 это вариант продукта) преобразовывать в один код Нормы. Ну и, наоборот, один код Нормы нужно преобразовать в вариант продукта.
В Вашем случае, один код в разных партициях это разные сущности для которых нужно каким-то образом обеспечить идентификацию в хранилище по данным Аксы и наоборот, из кода в хранилище, обеспечить соответствие объекта в DAX.
В DAX2012 R3 в подсистеме прогнозирования спроса такие соответствия предлагают определять через ключи распределения. Понятно, что при помощи ключей распределения можно определить только достаточно ограниченные концепции, но что-то в этом есть.

[Raven Melancholic]

Цитата:

работающих в текущий момент

А почему, вдруг, работающих в текущий момент. Хранилище и куб предназначены совсем не для текущих отчетов. Нужно знать что происходило не только сегодня, но и вчера, месяц назад, год назад, 5 лет назад. Скорее всего, тут понадобится что-то позволяющее определить что было в конкретный момент. Будут ли это измерения, построенные на таблицах измерений, или измерения, построенные на таблицах фактов опять же определяется со стороны бизнеса, а не технической реализации.
Как уже сказал Ivanhoe, при построении хранилища перед технической реализацией нужно определиться с задачами хранилища. Я-то по простому, по-деревенски назвал все это хранилищем, системой НСИ (нормативно-справочной информации), а Ivanhoe привел уже научные названия DWH, MDM ...
Прежде чем строить хранилище, попробуйте ответить на вопрос как оно будет использоваться (причем не в рамках таблиц, кубов, а просто с точки зрения задаваемых вопросов), забудьте и технической реализации, представьте, что все ведется на бумаге. Какие данные Вы бы предоставили для ответов на вопросы бизнес-пользователей? Технический вопрос при реализации хранилища уже второстепенный.

[Cardagant]

Цитата:

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

А почему, вдруг, работающих в текущий момент. Хранилище и куб предназначены совсем не для текущих отчетов. Нужно знать что происходило не только сегодня, но и вчера, месяц назад, год назад, 5 лет назад. Скорее всего, тут понадобится что-то позволяющее определить что было в конкретный момент. Будут ли это измерения, построенные на таблицах измерений, или измерения, построенные на таблицах фактов опять же определяется со стороны бизнеса, а не технической реализации.
Как уже сказал Ivanhoe, при построении хранилища перед технической реализацией нужно определиться с задачами хранилища. Я-то по простому, по-деревенски назвал все это хранилищем, системой НСИ (нормативно-справочной информации), а Ivanhoe привел уже научные названия DWH, MDM ...
Прежде чем строить хранилище, попробуйте ответить на вопрос как оно будет использоваться (причем не в рамках таблиц, кубов, а просто с точки зрения задаваемых вопросов), забудьте и технической реализации, представьте, что все ведется на бумаге. Какие данные Вы бы предоставили для ответов на вопросы бизнес-пользователей? Технический вопрос при реализации хранилища уже второстепенный.

Спасибо за ответ! Ваш тезис ясен: Хранилище - система для "анализа" и хранения информации в историческом контексте. Для отчётов "на данный момент" (на сейчас) как ничто лучше подойдёт OLTP транзакционная база. Абсолютно согласен.

Хочу лишь заметить, что я не искусен в искусстве построения хранилищ данных, все эти концепции для меня новы, поэтому и прощу помощи. Мне просто дали репорты и сказали хотим перенести их в кубы, построенные на хранилище данных. Вот теперь мучаюсь... Но хочется сделать всё правильно и эффективно...

Один из репортов привёл в предыдущем сообщении.

[Ivanhoe]

Согласен с Raven Melancholic по поводу "на бумаге".
Также, чтобы особо не теоретизировать (а судя по поставленной задаче, речь идет про концепцию а не строгую теорию), я бы выделил следующие шаги:
1. Нарисовать на бумаге отчет - выделить факты и разрезы. В вашем примере количество сотрудников - это факт, а не свойство разреза.
2. Нарисовать на бумаге структуру хранилища - таблицы фактов, таблицы разрезов и их связи. Определил ключи (скорее всего - естественные, т.к. пользователю должно быть прозрачно с каким элементом разреза он работает).
3. Продумать техническую реализацию хранилища. При этом нужно понимать, что классическое хранилище нужно тогда, когда у вас много систем для построения общих отчетов (и в таком случае надо понимать, как вы будете поддерживать хранилище при изменении требований или систем-источников). Если это не так и все данные есть в Аксе, то можно пойти по пути примеров стандартных кубов - данные брать из основной OLTP-базы. Если важно уменьшить нагрузку на основную БД - выделить копию БД (зеркало) для этих целей.

[Cardagant]

Цитата:

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

Согласен с Raven Melancholic по поводу "на бумаге".
Также, чтобы особо не теоретизировать (а судя по поставленной задаче, речь идет про концепцию а не строгую теорию), я бы выделил следующие шаги:
1. Нарисовать на бумаге отчет - выделить факты и разрезы. В вашем примере количество сотрудников - это факт, а не свойство разреза.
2. Нарисовать на бумаге структуру хранилища - таблицы фактов, таблицы разрезов и их связи. Определил ключи (скорее всего - естественные, т.к. пользователю должно быть прозрачно с каким элементом разреза он работает).
3. Продумать техническую реализацию хранилища. При этом нужно понимать, что классическое хранилище нужно тогда, когда у вас много систем для построения общих отчетов (и в таком случае надо понимать, как вы будете поддерживать хранилище при изменении требований или систем-источников). Если это не так и все данные есть в Аксе, то можно пойти по пути примеров стандартных кубов - данные брать из основной OLTP-базы. Если важно уменьшить нагрузку на основную БД - выделить копию БД (зеркало) для этих целей.

С Вашей точки зрения должен ли к этому быть непосредственно привлечён бизнес? И кто должен делать основную работу?

[Cardagant]

Ткаже, как уже было замечено прежде, хранилище прежде всего характеризует историчность данных и анализ в разрезе этой историчности.

Хороший пример был приведён выше, когда мы анализируем сумму продаж по 2012му году мы, в случае факта на таблицы сотрудники, не знаем сколько было работников в 2012м году, так как таблица была приведена в соответствие к текущему состоянию в источнике.

[Ivanhoe]

Согласен с Raven Melancholic по поводу "на бумаге".
Также, чтобы особо не теоретизировать (а судя по поставленной задаче, речь идет про концепцию а не строгую теорию), я бы выделил следующие шаги:
1. Нарисовать на бумаге отчет - выделить факты и разрезы. В вашем примере количество сотрудников - это факт, а не свойство разреза.
2. Нарисовать на бумаге структуру хранилища - таблицы фактов, таблицы разрезов и их связи. Определил ключи (скорее всего - естественные, т.к. пользователю должно быть прозрачно с каким элементом разреза он работает).
3. Продумать техническую реализацию хранилища. При этом нужно понимать, что классическое хранилище нужно тогда, когда у вас много систем для построения общих отчетов (и в таком случае надо понимать, как вы будете поддерживать хранилище при изменении требований или систем-источников). Если это не так и все данные есть в Аксе, то можно пойти по пути примеров стандартных кубов - данные брать из основной OLTP-базы. Если важно уменьшить нагрузку на основную БД - выделить копию БД (зеркало) для этих целей.

[Ivanhoe]

1-й пункт делает, конечно, бизнес. Иначе ничего не взлетит.
В случае с сотрудниками, по-хорошему, нужно брать за основу таблицу назначений (приемов на работу, переводов, увольнений). Если ее нет, а есть "просто список сотрудников" - тогда вам нужно в любом случае где-то хранить факт по количеству - или отдельная процедура и таблица в Аксе, либо специальная функция для DWH, которая считает количество по таблице сотрудников каждую ночь и пишет в свою таблицу фактов.

[Cardagant]

Цитата:

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

1-й пункт делает, конечно, бизнес. Иначе ничего не взлетит.
В случае с сотрудниками, по-хорошему, нужно брать за основу таблицу назначений (приемов на работу, переводов, увольнений). Если ее нет, а есть "просто список сотрудников" - тогда вам нужно в любом случае где-то хранить факт по количеству - или отдельная процедура и таблица в Аксе, либо специальная функция для DWH, которая считает количество по таблице сотрудников каждую ночь и пишет в свою таблицу фактов.

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

[Ivanhoe]

Ну и нормально. Нет данных - отчет покажет "пусто". Если бизнес считает, что это неверно - пусть предоставит данные, а вы их куда-нибудь загрузите - в Аксу, в DWH, да хоть руками вбить в OLAP, если рассматриваете writeback.

[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 или её самодельная реализация в аксе в виде таблиц соответствия.

[twilight]

Цитата:

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

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

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

[Ivanhoe]

Если говорим про клиентов / поставщиков то можно за ключ взять PartyId. В таком случае ГАК и будет тем самым общим справочником контрагентов. А если в ГАК две записи - значит и контрагенты разные. Ну по крайней мере такая логика в AX 2012.