Olap и персонал.

[NJD]

Внедряем модуль расчеты с персоналом. У пользователя есть куча разных хитрых отчетов по численности и по начисленным/удержанным деньгам в различных разрезах. Часть этих разрезов из штатки, часть из карточек сотрудников, фин аналитики конечно же, rpaytrans и т.д.
Думаю агрегировать все эти данные в какой-то таблице, и потом анализировать её в олапе. Вопрос по организации этой таблицы. Думаю, с какой дискретностью делать эту таблицу - думается что нужно делать с дискретностью час. Т.е. за каждый час (бежим по табелю), смотреть кто, с какой аналитикой, где работал. Тут правда встает вопрос - как мне впихивать в эту почасовую таблицу данные о з.п. Тупо брать период начисления и делить на количество часов? Никто не сталкивался с подобной задачей? Какой подход оптимальный?

[belugin]

Мы делали так (правда не по персоналу, но может и вам подойдет): при обработке ОЛАП куба он извещал о факте обработки запрос (Query), а запрос уже подготавливал данные в промежуточных таблицах.

[glibs]

Я про ЗП ничего не могу сказать, но я делал кубы не Аксаптовские, а обычные. Для их подготовки рисовал интеллектуальные вьюхи на T-SQL (например, делался UNION по таблицам LedgerTrans и LedgerBudget). Такой подход нашел весьма удобным для задач, котоыре передо мной стояли (в описанном выше примере в результате получался план-факт с drill-down до проводок).

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

Это тоже из серии "может и вам подойдет".

[slava09]

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