Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
 Oracle BI - модель данных с полуаддитивными мерами  [new]
Кostas_11
Member

Откуда:
Сообщений: 107
Добрый день.
Есть "концептуальный" вопрос: как организовывать модель данных в BI, для работы с числовыми атрибутами измерений как с фактами (агрегировать, использовать в отчетных формулах и т.д.)?

Поясню вопрос.
"По бизнесу" для разных коммерческих подразделений ввели много KPI, на основе показателей, которые, по своей сути, являются просто атрибутом какого-либо измерения.
Как пример, "Сумма первой покупки" - атрибут измерения "Клиенты", просто константа (купил "Клиент1" первый раз на 1000р, вот "Сумма первой покупки" для "Клиента1" всегда будет 1000р).

В отчетах надо получить сумму первых покупок за месяц без детализации по "Клиентам" - см. таб.2 и таб.3.


Т.е. "Сумма первой покупки" в рамках одной группы клиентов - повторяющееся значение и схема агрегации в рамках группы клиентов д.б. avg (или min или max)
'Группа Москва' - 1000р
'Группа Сыктывкар' - 1313р;
в рамках месяца нужна сумма из ранее проагрегированных значений, т.е. сумма из средних 1000+1313=2313р

Как такую двойную агрегацию прописать в репозитории?

Описание предметной области.
В данный момент предметная область реализована след. образом (см. рисунок):
- Измерение "Группы клиентов" ("ID группы клиентов","Наименование") - состоит из клиентов, объедененных в группы по географическому признаку
('Группа Москва', 'Группа Сыктывкар'...)
- Измерение "Время" (ID дня, Месяц, Квартал, Год)
- Измерение "Признак 1" ("ID признака 1","Наименование пр. 1") - деление групп клиентов по размеру ('большая', 'маленькая', 'огромная'...)
- Измерение "Признак 2" ("ID признака 2","Наименование пр. 2") - деление групп клиентов по классу ('полезная', 'так себе'...)
и
- Факт "Продажи" ("ID группы клиентов", "ID дня", "ID признака 1", "ID признака 2", "Сумма первой покупки", "Сумма продаж")

К сообщению приложен файл. Размер - 27Kb
24 апр 17, 16:56    [20430265]     Ответить | Цитировать Сообщить модератору
 Re: Oracle BI - модель данных с полуаддитивными мерами  [new]
Leoris
Member

Откуда:
Сообщений: 43
Кostas_11, если следовать вашей логике, то надо добавить колонку "Сумма первой покупки" в измерение Группа клиентов... А когда бизнес попросит анализ по Признакам - ещё и туда добавить по колонке. Что, конечно же, не правильно.

Признак "первая продажа" - свойство факта продажи, а не клиента. Уберите из фактов колонку "Сумма первой продажи" и добавьте измерение "Тип продажи" с значениями "Первая продажа" и "Вторичные продажи". Тогда ваши пользователи смогут сразу анализировать их со всеми доступными разрезами используя всего лишь одну меру "Сумма продаж".
25 апр 17, 09:06    [20431561]     Ответить | Цитировать Сообщить модератору
 Re: Oracle BI - модель данных с полуаддитивными мерами  [new]
terna
Member

Откуда:
Сообщений: 75
Кostas_11,
Очень правильный Вам совет дали.
Но если по каким-то причинам оставите как есть, то для того чтобы сделать разную агрегацию по измерениям нужно в показателе на вкладке Aggregation поставить галку "Based on Dimentions", а дальше выбирать в зависимости от измерения.
25 апр 17, 10:22    [20431741]     Ответить | Цитировать Сообщить модератору
 Re: Oracle BI - модель данных с полуаддитивными мерами  [new]
Кostas_11
Member

Откуда:
Сообщений: 107
To terna,
спасибо.

Собственно, так и делаем, но есть расхождение в данных. Т.е. порядок цифр сходится, а полного совпадения нет.

Доп. вопрос 1:
для корректной работы правил агрегирования, заданных на этой вкладке, имеет значение по всем ли измерениям "звезды" построены иерархии или только по тем измерениям, у которых своя схема агрегации? А остальные измерения записаны одной строкой как "Other SUM("Сумма первой покупки")" и иерархии не имеют?

Или нужно сначала построить все иерархии для всех измерений и все их перечислить на вкладке Aggregation?

Доп. вопрос 2:
Есть ли/должна ли быть разница в результате отчета при перечислении всех измерений со схемой агрегации SUM на вкладке Aggregation и, если все эти измерения записать как "Other SUM("Сумма первой покупки")"?
28 апр 17, 17:08    [20444637]     Ответить | Цитировать Сообщить модератору
 Re: Oracle BI - модель данных с полуаддитивными мерами  [new]
Кostas_11
Member

Откуда:
Сообщений: 107
Leoris,
спасибо за ответ, но не до конца понял, предложенный вариант.

Верно ли понял что и первые продажи и все остальные находятся в одном поле (см. рисунок), а в соседнем признак первой продажи?

1. А как первая продажа (в рамках измерения "ID группы клиентов") должна разбиваться по остальным измерениям: "ID признака 1", "ID признака 2"?

2. Если в отчете будет выбран интервал дат куда не попадает первая продажа? Например, первая продажа по "Группа Москва" была 01.01.2011, а отчет по этой группе, строится с 10.01.2011?

3. И какую схему агрегации выставить на "Сумму продаж"? Показатель теперь общий.

К сообщению приложен файл. Размер - 17Kb
28 апр 17, 17:52    [20444762]     Ответить | Цитировать Сообщить модератору
 Re: Oracle BI - модель данных с полуаддитивными мерами  [new]
terna
Member

Откуда:
Сообщений: 75
Кostas_11,

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

А по поводу второго способа
Кostas_11
1. А как первая продажа (в рамках измерения "ID группы клиентов") должна разбиваться по остальным измерениям: "ID признака 1", "ID признака 2"?

2. Если в отчете будет выбран интервал дат куда не попадает первая продажа? Например, первая продажа по "Группа Москва" была 01.01.2011, а отчет по этой группе, строится с 10.01.2011?

3. И какую схему агрегации выставить на "Сумму продаж"? Показатель теперь общий.

Я себе представляю следующим образом.
сумма продажи никак не должна разбиваться по остальным измерениям - по каким была, пусть по тем и будет.
У вас будет показатель "сумма первой продажи (служебный)"
case признак первой продаж=1 then сумма продаж else 0 end - формула на основе физического источника
по нему единая агрегация сумма
Потом второй показатель Сумма первой продажи =сумма первой продажи (служебный) - в формуле на основе других логических показателей. А на вкладке Levels уже установите правильно уровни по агрегации: как я понимаю в Вашем случае total по всем измерениям кроме группы клиентов, это если по всем измерениям определяется раз и на всегда и только по группам надо суммировать.
Но я вот вообще не уверена, какой из вариантов будет дольше работать - надо тестировать. Я бы предположила, что второй дольше, чем тот, который вы реализуете на данный момент.
2 май 17, 17:07    [20451047]     Ответить | Цитировать Сообщить модератору
 Re: Oracle BI - модель данных с полуаддитивными мерами  [new]
Кostas_11
Member

Откуда:
Сообщений: 107
terna,
спасибо.

Есть ли ссылка на описание объекта "иерархия"? Интересует какие связи, возможности и т.д. появляются с наличием этого объекта у измерения?
Т.е. я считал, что если мне нужен дрилап/дрилдаун, то, да, строю иерархию, в противном случае иерархию не создаю. Однако, вы пишите, что надо создавать для всех измерений.
10 май 17, 18:02    [20470190]     Ответить | Цитировать Сообщить модератору
 Re: Oracle BI - модель данных с полуаддитивными мерами  [new]
terna
Member

Откуда:
Сообщений: 75
Кostas_11,

https://docs.oracle.com/cd/E23943_01/bi.1111/e10540/lts.htm#BIEMG244
вот тут не про иерархии, а про то, что нужно у фактовой таблицы обязательно определять контент, и очень рекомендуется определять его именно по уровням иерархии. Соответственно, и иерархии нужны.
Это позволяет понимать серверу, из какого факта нужно брать цифру, когда выбрано то или иное поле таблицы-измерения. И если там, для какого-то измерения в уровне ничего не указано, то возникает ворнинг, говорящий о том, что сервер думает, что у вас не связаны измерение и факт.
Эта же функциональность позволяет добавлять агрегированные фактовые источники и указывать серверу для какого уровня агрегации там хранятся данные.
в общем, в простом случае можно просто правой кнопкой щелкать по измерению и выбирать "create level-based hierarchy" - создается автоматом иерархия с общим и детальным уровнем, а в контенте факта проставляется по умолчанию детальный уровень.
16 май 17, 13:36    [20484868]     Ответить | Цитировать Сообщить модератору
 Re: Oracle BI - модель данных с полуаддитивными мерами  [new]
Кostas_11
Member

Откуда:
Сообщений: 107
terna,
спасибо.
"Насоздавал" иерархий, стало лучше. Данные теперь не бьются "на копейки" - вероятнее всего из-за множественных схем агрегации на показателях. Кстати Others поставить последним не получается, требуется ставить его первым, а остальные измерения после него.

Буду смотреть дальше, но из-за того что один логический факт состоит из кучи физических таблиц, отличающихся по показателям и измерениям, получаются совершенно не читаемые селекты ((( С кучей вложенностей, партишенбаев, SYS_OP_MAP_NONNULL-ов...

Или, вообще, в журнале разные несвязанные селекты на требуемый отчет, результаты которых BI "как-то там" сводит в единое множество.
16 июн 17, 14:24    [20570161]     Ответить | Цитировать Сообщить модератору
Все форумы / OLAP и DWH Ответить