Добрый день всем!
Помогите понять почему не работает суммирование верхних уровней иерархии для calculated measure, если оно отключено (Nonadditive) для меры-источника данных для этой calculated measure?
Инструментарий: Olacle 11R2 OLAP Option и Olacle AWM 11.2.0.4.0B

Исходные данные:
1. Имеются числа (A_INT), например: 1, 2, 3, 4, ..., привязанные ко времени (HOUR_ID):
одно число каждый час в 00 минут 00 секунд.
В таблице фактов имеем:
HOUR_ID A_INT
2017010100 1
2017010101 2
2017010102 3
2017010103 4
2017010104 5

2. Создан dimension time (DIM_TIME) с default иерархией (MH): YEAR - MONTH - DAY - HOUR. Dimension заполнен данными на весь диапазон данных A_INT.

3. Создан куб: CB_TEST c dimension time DIM_TIME и иерархией DIM_TIME.MH.
HOUR_ID смаплен с HOUR_ID таблицы фактов.

4. Создана measure A_INT ("Integrator") с отключенным агрегированием "Nonadditive (Do Not Summarize)". Исходя из задачи, агрегирование именно этих данных не имеет смысла. Мера смаплена со столбцом A_INT таблицы фактов.

5. Создана calculated measure A_DIF ("Differential (Ai - Ai-1)") которая вычисляет разность текущего и предыдущего значения из measure A_INT: LAG(CB_TEST.A_INT, 1) OVER (HIERARCHY DIM_TIME.MH)

6. Создана calculated measure A_DIF_SUM ("SUM of Differential") которая суммирует значения calculated measure A_DIF:
SUM(CB_TEST.A_DIF) OVER (HIERARCHY DIM_TIME.MH BETWEEN UNBOUNDED PRECEDING AND CURRENT MEMBER WITHIN LEVEL)


Что хочу от OLAP:
- Агрегацию SUM для уровней иерархии YEAR - MONTH - DAY , т.е. выше уровня HOUR. Сейчас суммирование выполняется только по уровню HOUR, в уровнях выше Null.

Что уже делал сам:
1. Перепробовал все условия агрегирования для SUM
2. Если в исходной measure A_INT включить любое агрегирование, то и зависимые calculated measure A_DIF и A_DIF_SUM будут выполнять агрегирование
3. Гуглин не помог, RTFM https://docs.oracle.com/cd/B28359_01/olap.111/b28124/calculations.htm#OLAUG500 тоже не проясняет такое поведение calculated measure.

Если нужны скрины что и как создано, запостю без проблем.
Заранее благодарен.

vikkivна SSAS делаем Scope-ами ...
Разбираюсь с OLAP недели три, поэтому полез смотреть про Scope. И вот, что интересно:
1. На https://msdn.microsoft.com/ru-ru/library/ms145989.aspx есть такие слова:
SCOPE создают вложенные кубы, имеющие «пустоты» вне зависимости от MDX Compatibility параметр. Например, инструкция Scope( Customer.State.members ) может включать штаты в тех странах или регионах, которые не имеют штатов, но содержат элементы-заполнители для штатов, невидимые в остальных случаях.

2. А в OLAP User's Guide http://docs.oracle.com/cd/E11882_01/olap.112/e17123/calculations.htm#CIHBADHE сказано вот что:
Calculated measure.... Like relational views, calculated measures store queries against data stored in other objects. Because calculated measures do not store data, you can ...
As soon as you create a calculated measure, it appears as a column in a cube view.


Моё предположение: когда я включаю ненужную мне агрегацию по мере-источнику данных A_INT, я как раз и создаю "элементы-заполнители", которые создают ячейки в кубе и строки в cube view, к которым "привязываются" результаты от calculated measures. Если так, то calculated measure не могут сами создать "пространство" для своих результатов...
Это предположение.

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

vikkiv.... в зависимости от текущего уровня переключая алгоритм расчёта
..
Попробую так, спасибо за идею. Как раз сейчас читаю мануал по OLAP DML, гибкая логика в оракловой OLAP Option реализуется на нём.
Аналога Scope в оракловом OLAP-е в явном виде не нашёл - он довольно старый и без "наворотов".

vikkivScope и Calcuated Measure разные понятия, однако можно вышеописанную/целевую логику встроить в CM (т.е. в зависимости от текущего уровня переключая алгоритм расчёта)...
iif isleaf()...
..
sum(descendants(...,LEAVES),мера)
..

Поведение Calcuated Measure не изменилось после встраивания логики агрегирования в Calcuated Measure, как vikkiv рекомендовал.

Исходный тест упростил до трёх мер:
- "обычной" (A_INT), привязанной к таблице фактов по часовым данным. Для это меры я включаю/выключаю агрегирование.
- calcuated measure (A_INT_CASE_SUM) с алгоритмом, как vikkiv рекомендовал:


- добавил ещё calcuated measure связанную только с иерархией времени DIM_TIME.MH



Текущее резюме:
- если в мере-источнике включено (ненужное мне) агрегирование, то в зависимой calcuated measure агрегирование тоже будет выполняться;
- если в мере-источнике отключить агрегирование, то в зависимой calcuated measure агрегирование "пропадёт";
- если calcuated measure зависит от стабильно-существующих данных, например календаря DIM_TIME.MH, то её данные видны и не зависят от других measure / calcuated measure

Скрин с результатами эксперимента: