OLAP Кубы, общее представление о кубах и немного конкретных вопросов

[vizir]

Приветствую.

Суть проблемы:
Не достаточное понимание OLAP кубов, в контексте аксапты 2012 и VS 2013. Из-за этого возникает множество различных вопросов, ответы на которые не найти в мануалах, где показываются основы и стандартные/простейшие кубы.

Задача:
Модифицировать уже имеющийся рабочий куб(проект в VS2013).


Проект куба создавался в VS, но использует представления и таблицы из аксапты. У меня получилось добавить несколько мер(если это так называется), потому что они уже имелись в представлении, но не получилось модифицировать представление в аксапте, чтобы создать свою собственную меру.

Пока что, основные вопросы таковы:
1. Мера - это по сути поле таблицы или представления. Если оно есть, то и фильтровать в кубе его возможно. Так ли это?

2. "Представление источников данных" в проекте VS. Что оно из себя представляет? Как я понял, оно может генериться само средствами VS на основании представлений и таблиц из аксапты, но, в том проекте что у меня, присутствует множество представлений(view), которых в аксапте (и соответственно в SQL сервере) нет. Очевидно их создали в VS, но я не могу понять зачем. В каких случаях требуется создавать дополнительные представления данных в проекте, а не в аксапте?

3. Связи между table и view в "представлении источников данных". Для чего они нужны? Что они из себя представляют? (В ER диаграмме связи показывают отношения между таблицами, но тут ведь они не просто для вида?)

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

Лучше, чем написано в справке от Microsoft у меня не получится

Общие сведения о кубах OLAP


Однако для определенности, все-таки уточню

Цитата:

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

1. Мера - это по сути поле таблицы или представления. Если оно есть, то и фильтровать в кубе его возможно. Так ли это?

Как правило. Но это может быть и функция. И не обязательно по полю. Это могут быть некие статистические функции по количеству записей, например.

Цитата:

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

2. "Представление источников данных" в проекте VS. Что оно из себя представляет?

Здесь название полностью отражает суть. Это именно "представление" (отображение) всех источников данных и связей между ними. Точнее, в каком именно виде исходные данные представлены внутри куба OALP. С чем именно происходит работа внутри куба.

Цитата:

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

В каких случаях требуется создавать дополнительные представления данных в проекте, а не в аксапте?

В тех случаях, когда в Axapta эти представления не нужны Т.е. это некие дополнительные выборки необходимые только и исключительно для данного куба OLAP

Цитата:

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

3. Связи между table и view в "представлении источников данных". Для чего они нужны? Что они из себя представляют? (В ER диаграмме связи показывают отношения между таблицами, но тут ведь они не просто для вида?)

В первую очередь с той же целью. Показать по каким правилам (по каким полям) следует связывать источники данных между собой. Не отображают, а определяют! Ведь источник данных могут быть созданы и внутри куба. И связи между источниками могут быть не стандартными.

Дополнительным "бонусом" являются свойства связей, которые определяют некие дополнительные критерии вычисления/отображения "мер" при тех или иных типах связей.

[BIDeveloper]

Цитата:

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

В первую очередь с той же целью. Показать по каким правилам (по каким полям) следует связывать источники данных между собой. Не отображают, а определяют! Ведь источник данных могут быть созданы и внутри куба. И связи между источниками могут быть не стандартными.

Дополнительным "бонусом" являются свойства связей, которые определяют некие дополнительные критерии вычисления/отображения "мер" при тех или иных типах связей.

Еще связи используются:
1. При добавлении измерений в куб происходит автоматическая привязка по полям из связи.
2. В измерении можно выбирать атрибуты не только из основной таблицы измерения, но и из связанных с ней.

[BIDeveloper]

Цитата:

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

В тех случаях, когда в Axapta эти представления не нужны Т.е. это некие дополнительные выборки необходимые только и исключительно для данного куба OLAP

Например, есть технические представления для enum-ов. В Аксапте значения enum хранятся в виде целых чисел. Но пользователю удобнее видеть статус заказа не как число 2, а как "Оприходован". Поэтому на каждый enum создается представление с парой полей ключ - значение.
Кроме того, вычислимые поля делать в Аксапте очень неудобно. Их гораздо проще написать уже в проекте.

[vizir]

Спасибо всем за ответы. Теперь немного понятнее стало

Но теперь при создании меры, значение из представления в аксапте почему то умножается на число, которое я нигде не могу найти. То есть я создал дополнительное расчетное тестовое поле в представлении, в аксапте представление открывается и выводится верно, а если открывать через куб, то значение поля умножается на некое число. В чем может быть дело?

[twilight]

На целое число? Например, как вариант, если у вас данные в нескольких компаниях, а куб вы открываете без фильтра по компании.

[vizir]

Цитата:

На целое число?

Да, на целое. Но другие поля не множатся.

[vizir]

Да, спасибо! Фильтр по месяцам не был выставлен, сразу за 4 месяца считалось

[vizir]

Цитата:

на каждый enum создается представление с парой полей ключ - значение

Создал представление в проекте, связал два представления по полям, но вместо чисел значения так и не появились. Что ещё требуется сделать, чтобы выводились значения enum'ов вместо цифр?

[twilight]

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

[vizir]

Вычисления (не знаю точно как называется) в кубе не подсчитываются в поле ИТОГ в экселе. Я так понимаю, что в поле итог должна быть сумма всех значений этого столбца, но если столбец состоит из этих вычислений, то формула применяется и к итоговому полю. Как сделать, чтобы итог выводился правильный? Или что гуглить?

п.с. вычисление делит одно измерение на другое. это расчетное поле, но по нему тоже нужно выводить итог.

[Ivanhoe]

По хорошему в самом вычислении нужно прописать условие: если мы на нижнем уровне измерений - то считаем по формуле, если нет - то суммируем значения вычисления всех потомков.

[twilight]

Один метод правильно написал Ivanhoe.
Второй метод - создаем фиктивную меру в группе мер (по полю, которое всегда 0).
В вычислениях в кубе задаем формулу для этой фиктивной меры на нижнем уровне измерений (читайте про Scope). На верхнем уровне она будет агрегироваться сама.

[vizir]

А как узнать что мы на нижнем уровне измерений? По какому признаку?

Пробовал создавать меру, и скоп пробовал использовать, пока никаких результатов. Только нули выводятся.

[Ivanhoe]

Как-то так: https://docs.microsoft.com/ru-ru/sql/mdx/isleaf-mdx

[vizir]

Теперь итог по нижнемуц уровню считается нормально, а Общий итог по всем нижним уровням снова кривой. Как его отловить?

[Ivanhoe]

Напишите тут код измерения

[vizir]

SCOPE ([Measures].[Недогруз Тест Шт], [Номенклатура].[Код номенклатуры].members);

this = case when [Номенклатура].[Код номенклатуры].currentmember.level.ordinal>0 then

IIF(IsEmpty([Measures].[Факт Отгрузка шт]) AND IsEmpty([Measures].[Факт Заявка шт]), NULL,
(IIF(IsEmpty([Measures].[Факт Отгрузка шт]), 0 - [Measures].[Факт Заявка шт],
(IIF(IsEmpty([Measures].[Факт Заявка шт]), 0,
(IIF((([Measures].[Факт Отгрузка шт] - [Measures].[Факт Заявка шт]) < 0),([Measures].[Факт Отгрузка шт] - [Measures].[Факт Заявка шт]), 0 )))))))
else
aggregate([Номенклатура].[Код номенклатуры].members)

end
;
END SCOPE;


Общий итог считается по другому измерению - коду клиента. В нем на текущий момент вот этим скриптом считается итог по измерению номенклатур. А как одновременно считать итог и по другому измерению с учетом этого - никак не допру.

[Ivanhoe]

Так тут явно есть анализ Номенклатуры, а где анализ остальных Dimensions? По идее нужно проверять isLeaf() на полном срезе.