Методы создания сводных отчетов с расширенной функциональностью

Одно из очевидных решений проблемы заключается в создании пользовательских иерархий из разнородных атрибутов типа «Месяц — Категория» (рис. 1).

Рис. 1. Пользовательская иерархия
«Месяц — Категория»

Сразу оговоримся, что в самих сводных таблицах не получится создать какие­либо иерархии. Максимум, что допускается при построении сводных отчетов, — это выполнить операцию группировки элементов измерения. Причем для каждого измерения можно организовать единственную группировку.

В принципе, любую комбинацию атрибутов в OLAP-источнике можно объединить в иерархию. Для небольших кубов такой подход может быть даже оправданным, но для существенных объемов данных объединение атрибутов, не составляющих «естественную» (Natural) иерархию, серьезно понижает производительность всей системы.

Естественные иерархии имеют связи типа «многие к одному» или «один к одному», их кардинальность равна числу элементов нижнего (листового) уровня, а любой элемент верхнего (старшего) уровня функционально зависит от своих подчиненных. К примеру, у января всегда будет признак «I квартал», причем эта связь никак не зависит от потребностей пользователя или характера решаемых задач. Более того, она не меняется с течением времени. Такую связь атрибутов часто называют жесткой — rigid. Практически это означает, что любой элемент с уровня «Квартал» можно связать с набором ключевых элементов измерения опосредованно через уровень «Месяц».

Обратимся еще раз к нашему примеру. Здесь наблюдается иная ситуация. Атрибут «Категория данных» (признаки «План» или «Факт») логически не связан с отчетным периодом. Иначе говоря, между атрибутами «Категория» и «Время» установлено только отношение «многие ко многим» — каждый элемент одного атрибута может сочетаться с любым элементом другого. Для января могут храниться как плановые, так и фактические данные, для апреля — только плановые, а для декабря может не быть даже плановых показателей. Заметим, что с течением времени ситуация может измениться, причем существенно: если в феврале для апреля были определены только плановые показатели, то в мае после подведения итогов будут известны и фактические значения.

Получается, что возможные сочетания атрибутов из измерений «Категория» и «Время» определяются посредством таблицы фактов. Если в таблице фактов есть кортеж с заданным сочетанием, например «Январь — Факт», то связь между этими элементами считается установленной, в противном случае — нет. С помощью таблицы фактов можно задать любые, даже совершенно экзотические иерархии, что открывает пользователю широкие возможности по манипуляции данными при решении различных прикладных задач.

Когда в аналитическом кубе имеется иерархия «Месяц — Категория», создание отчета о результатах деятельности из начала статьи становится минутным делом. Достаточно поместить данное измерение в область столбцов отчета, затем для месяцев I квартала оставить только подчиненные значения «Факт», а для месяцев II квартала — «План».

Повторимся еще раз: атрибут «Категория» в данном случае уже не является самостоятельным измерением, это всего лишь нижний уровень иерархии. Следовательно, его можно определять отдельно для каждого элемента верхнего уровня — «Месяц», то есть точно так же, как если бы мы выбирали месяцы I квартала без оглядки на II квартал.

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

Во­первых, при таком подходе для любой комбинации атрибутов требуется создание отдельной иерархии. Допустим, мы хотим немного изменить исходный макет отчета и сделать таблицу следующего вида (табл. 4).

Иерархия «Месяц — Категория» для такой таблицы уже не подойдет. Иерархия является жесткой структурой, в которой заранее определен и строго зафиксирован порядок следования уровней. Положение уровней в иерархии нельзя менять, в отличие от места измерений в макете отчета сводной таб­лицы. Поэтому, чтобы получить раскладку для табл. 4, придется сделать еще одну, новую пользовательскую иерархию — «Категория — Месяц» (рис. 2).

Рис. 2. Пользовательская иерархия
«Категория — Месяц»

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

Во­вторых, иерархии, состоящие из разнородных атрибутов, гораздо более требовательны к ресурсам системы по сравнению с естественными. Единственный способ увязать между собой независимые атрибуты заключается в создании измерения, в котором ключевым элементом является индексное поле таблицы фактов. У такого измерения атрибутом может быть любое поле, что потенциально позволяет создать на его базе иерархию произвольной структуры. Однако кардинальность такого измерения равна мощности таблицы фактов, хотя при правильном проектировании должна быть существенно (на порядки) меньше. Часто измерения подобного рода обозначают специальным термином — дегенерированные.

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

Поиск по сайту: