Пример для бюджетного процесса.

Так, например, ПОЛУЧЕННАЯ СУММА в доходную часть бюджета, которая является одним из возможных показателей доходов, может определяться датой поступления платежа (время), кодом дохода (соответственно классификатору доходов), плательщиком данного платежа и признаком вида расчета (денежный, безденежный и т.д.):

ПОЛУЧЕННАЯ СУММА (Время, КОД ДОХОДА, ПЛАТЕЛЬЩИК, ВИД РАСЧЕТА)

Соответственно измерениями, которые являются ключами показателя ПОЛУЧЕННАЯ СУММА, будут в данном примере Время, КОД ДОХОДА, ПЛАТЕЛЬЩИК и ВИД РАСЧЕТА. Иначе можно сказать, что перечисленные Время, КОД ДОХОДА, ПЛАТЕЛЬЩИК и ВИД РАСЧЕТА являются параметрами (аргументами), определяющими значение показателя ПОЛУЧЕННАЯ СУММА. Выбирая для анализа конкретные значения перечисленных параметров (значения измерений), соответственно определяются значения показателя.

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

Например, измерение ВРЕМЯ имеет временную иерархию Все годы, годы, кварталы, месяцы, пятидневки, дни. Приведенный в примере показатель ПОЛУЧЕННАЯ СУММА в бюджетном процессе определяется во времени днем перечисления платежа (измерение ВРЕМЯ). В многомерной базе данных показатель полученная СУММА соответственно временной иерархии при агрегировании будет определяться суммированием по входящим элементам нижнего уровня (для пятидневки суммируются соответствующие полученные суммы по всем входящим в нее дням, для месяца суммируются соответствующие полученные суммы по всем входящим в него пятидневкам и т.д.).

Обратной к агрегированию является операция дезагрегирования. Тот же показатель полученная СУММА при переходе по временной иерархии сверху вниз раскладывается по входящим элементам иерархии нижнего уровня (например, полученная сумма за месяц раскладывается по входящим в него пятидневкам).

Одно измерение может также содержать несколько иерархий. Отдельные иерархии одного измерения задают разные схемы агрегирования анализируемых показателей.

Например, при анализа расходов бюджета для классификации расходов используется "Интегрированный классификатор расходов", которому соответствует измерение "Расходы бюджета". В рамках этого общего классификатора (измерения) используются различные расходные иерархии:

§ «классификатор видов расходов (КВР)”

§ «классификатор функциональных статей расходов (КФСР)"

§ «классификатор экономических статей расходов (КЭСР)»

§ «классификатор ведомственной структуры расходов (КВСР)»

§ «классификатор целевых статей расходов (КЦСР)».

Построение иерархий аналогично построению их в стандартных бюджетных классификаторах. Расходы бюджета, соответствующие элементам структуры каждого классификатора, определяются суммированием статей расходов входящих элементов нижнего уровня. При дезагрегировании укрупненные статьи расходов бюджета раскладываются по входящим элементам нижнего уровня.

В данном примере одному измерению соответствует, таким образом, пять иерархий.

Указанные механизмы агрегирования и дезагрегирования по всем заданным иерархиям в каждом из измерений автоматически поддерживаются реализующими OLAP базовыми программными средствами, обеспечивая широкие возможности анализа данных.

Измерения и иерархии задаются при разработке конкретной аналитической системы и определяются требованиями бюджетного аналитика к анализу данных. При этом существуют объективные ограничения на количество и состав вводимых измерений и иерархий.

Бюджетный аналитик заинтересован в расширении состава измерений, которые используются в создаваемой аналитической системе. Чем больше измерений существует в OLAP- системе, тем больше возможностей для анализа информации с разных точек зрения или от различных параметров. Вместе с тем, многомерные данные всегда представляются на плоском экране дисплея или распечатываются на листе бумаги, которые при графическом представлении в изометрии позволяют изобразить только три измерения в качестве координатных осей (таблица определяется только двумя измерениями). Значения других измерений при этом фиксируются, что при большом их количестве затрудняет анализ, делая его плохо интерпретируемым. Практически в используемых OLAP - системах по указанной причине применяется до 10 измерений.

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

Индексация анализируемых данных по измерениям (как было сказано выше, в многомерной базе данных анализируемые показателя индексируются значениями измерений) подразумевает, что в структуре реляционной базы данных учетной системы имеется связь между анализируемыми показателями и значениями измерений. На основе этих связей происходит формирование многомерной базы данных. Ввести некоторое измерение в многомерную базу данных, которое не поддерживается структурой реляционной базы данных учетной системы (нет структурной связи между анализируемыми показателями и значениями вводимого измерения), нельзя.

Например, в используемой в Министерстве Финансов Московской области бюджетной учетной системе СЕ2 в базе данных имеются таблицы, определяющие привязку партнеров (плательщики налогов и получатели бюджетных средств) к городам, сельским округам, поселкам и др. На основе этой информации для многомерной базы данных можно сформировать для измерения «Партнеры» (налогоплательщики и получатели бюджетных средств) иерархию «География» для анализа доходов и расходов бюджета относительно географии региона.

Аналогичная бюджетная учетная система АРМ «Бюджет» не имеет таблиц, определяющих привязку партнеров к городам, сельским округам или поселкам региона. Это приводит к тому, что для анализа бюджетных данных, накапливаемых в данной системе, нельзя ввести аналогичную рассмотренной выше иерархию «География».

Важный вопрос - наличие данных. Если они есть, в любом виде, как Excel-таблица, в базе данных учетной системы, в виде структурированных отчетов филиалов, ИТ-специалист сможет передать их OLAP-системе напрямую или с промежуточным преобразованием. Для этого OLAP-системы имеют специальные инструменты. Если этих данных нет, или они имеют недостаточную полноту и качество, OLAP не поможет.

1.4.3 Примеры применения OLAP – технологий.