Добрый день коллеги!

Есть вопрос.
История такая, есть ПРИЗНАК, который имеет около 5-ти атрибутов.
Некоторые из атрибутов войдут в иерархию, листьями которой будут значения ПРИЗНАКА.
Все атрибуты должны быть доступны в отчетности.
Оцените, плз, два варианта:
1. Создасть признак, с 5-ю атрибутами и куб с одной ссылкой на этот ПРИЗНАК.
2. Создать 6 признаков и куб с шестью ссылками.

Интересуют такие параметры:
a. Временная характеристика формирования отчетов по различным разрезам (не только по ПРИЗНАКУ ес-но)
б. Удобство для юзера в BEX.
в. Быстродествие иерархии, сильно ли будет тупить при раскрытии уровней.

Спасибо всем откликнувшимся!

ИМХО если тебе нужна будет аналитика в разрезе 6 признаков, то лучше их делать как отдельные признаки в кубе, чтобы потом можно было разворачивать отчет по ним. Если же они носят чисто информативный смысл, типа для СПП-элемента признак "Действителен С", "Действителен ПО" или "Статус СПП", по которым аналитика строиться не будет, то не стоит их выносить.

p.s. не думаю что целью стоит ставить временные характеристики, в первую очередь покрытие бизнес-требований и возможность дальнейшего гибкого манипулирования данными.

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

млин, забыл про них совсем

В том то и вопрос!!!
Мне кажется, что если внести признаки в куб, должно меньше тупить, но на практике не проверял. Может кто пробовал?

Да на практике у тебя есть 2 подразделения, в одном 100 человек, в другом 15000, угадай, какая ветка будет открываться быстрее

Не понял?

Количество записей в моем кубе будет равно кол-ву записей в ПРИЗНАКЕ*N, N - месяц. В случае <2.> куб будет содержать больше данных за счет 5-ти признаков. Это критично? или BW наоборот выиграет при выборках при втыкании всех показателей в куб?

Если речь о иерархии - то там кол-во узлов будет одно и тоже, отличие будет только в том, что признаки будут/не будут храниться в табличке атрибутов.

Кол-во данных в таблице фактов в любом случае будет одинаково
А вопрос моделирования нужно рассматривать на конкретном примере.

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

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

а если в атрибутах, то стандартная процедура change run и никаких удалений, загрузок заново и т.д.