Системы бизнес-интеллекта (BI-системы)

Сущность систем бизнес-интеллекта

Типичная ситуация, характерная для практически любой достаточно крупной организации, - наличие множества систем автоматизации для решения разных задач, разрозненное хранение данных и, как следствие, - отсутствие единого взгляда на управленческую информацию [45]. Создается парадоксальная ситуация. С одной стороны, в информационных системах предприятия имеется вся информация, необходимая для анализа. Но, с другой стороны, анализировать информацию, хранящуюся в различных трансакционных системах, базах данных и электронных таблицах, становится невозможно.

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

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

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

Хранилища данных

Функциональность

Напомним определение У. Инмона: хранилища данных - это "предметно-ориентированные, интегрированные, стабильные, поддерживающие хронологию наборы данных, используемые для поддержки принятия управленческих решений" [39].

Данные в хранилище попадают из оперативных (трансакционных) систем, а также из внешних источников. По аналогии с "материальными" хранилищами, хранилища данных предусматривают такие операции, как сбор данных ("приход материалов на склад"), хранение данных ("складской запас"), перемещение в витрины данных ("отгрузка товаров в розничную сеть").

С экономической точки зрения, хранилище данных приносит долгосрочный эффект тогда, когда оно становится надежным механизмом доставки данных, существенных для анализа и принятия решений. При этом не следует забывать и о затратной части: ведь информация может считаться действительно полезной лишь тогда, когда экономические выгоды от ее использования превышают затраты, связанные с ее приобретением. Построение хранилища данных - достаточно сложный проект и обеспечить его окупаемость в краткосрочной перспективе бывает непросто [45].

В качестве основы хранилища данных, как правило, используется реляционная модель хранения данных, что существенно облегчает дальнейшее развитие такого хранилища. Впрочем, существует и другой путь - применение оптимизированных структур, например, многомерных (по этому пути пошли разработчики компании SAP в своем продукте SAP BW). Однако, по мнению ряда исследователей (например, У. Инмона [46]), такой подход имеет целый ряд недостатков, не являясь достаточно гибким и универсальным. В самом деле, если данные из хранилища поступают лишь в ограниченное количество витрин данных и аналитических приложений, то от хранилища вовсе не требуется поддерживать специализированные запросы. В этом отношении использование реляционных баз данных экономичнее (без потери функциональности), а следовательно, - предпочтительнее.

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

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

OLAP-системы

Функциональность

Идея обработки многомерных данных восходит к 1962 году, когда К. Айверсон опубликовал свою работу "Язык программирования" (A Programming Language, APL) [47]. APL - это математически определенный язык с многомерными переменными и изящными, но довольно абстрактными операторами. В 70-е и 80-е годы он активно использовался во многих деловых приложениях, функционально схожих с современными OLAP-системами.

В 1993 году вышла в свет статья Е. Ф. Кодда, в которой впервые было дано формальное определение OLAP-технологии [48]. Эта работа получила большой резонанс и привлекла внимание к возможностям многомерного анализа. В статье были описаны двенадцать правил OLAP, к которым чуть позже (в 1995 году) были добавлены еще несколько. Все эти правила были разделены на четыре группы и названы "характеристиками" (features).

К правилам OLAP относятся:

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

Универсальным критерием определения OLAP как аналитического инструмента является тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации). Рассмотрим детально каждую из составляющих этой аббревиатуры [49].

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

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

Shared (разделяемый). Система должна предоставлять широкие воз-можности разграничения доступа к данным и одновременной работы многих пользователей.

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

Information (информация). Мощность различных программных про-дуктов характеризуется количеством обрабатываемых входных данных. Разные OLAP-системы имеют разную мощность: наиболее мощные из них могут оперировать, по крайней мере, в тысячу раз большим количеством данных по сравнению с самыми маломощными. При выборе OLAP-инструмента следует учитывать целый ряд факторов, включая дублирование данных, требуемую оперативную память, использование дискового пространства, эксплуатационные показатели, интеграцию с информационными хранилищами и т.п.

Обсуждая тему OLAP, следует упомянуть и о разновидностях многомерного хранения данных. Дело в том, что информационные массивы, логически упорядоченные по аналитическим направлениям и, таким образом, являющиеся многомерными с точки зрения конечных пользователей, не обязательно являются многомерными по их технологической реализации. Как правило, выделяют три разновидности хранения данных [45]:

• многомерный OLAP (multidimensional OLAP, MOLAP) - "OLAP в чистом виде", т.е. технология, основанная на хранении данных под управлением специализированных многомерных СУБД;
• реляционный OLAP (relational OLAP, ROLAP) - технология, основанная на хранении многомерной информации в реляционных базах данных, на основе одной или нескольких схем типа "звезда" или "снежинка";
• гибридный OLAP (hybrid OLAP, HOLAP) - технология, при которой одна часть данных хранится в многомерной базе, а другая часть - в реляционной. При этом инструментальные средства, поддерживающие эту технологию, обеспечивают прозрачность данных для пользователя, который на логическом уровне всегда работает с многомерными данными.

Выбор способа хранения зависит от нескольких факторов, таких как объем и структура данных, скорость выполнения запросов, частота обновления OLAP-кубов.

Средства формирования запросов и визуализации данных

Функциональность

Средства формирования запросов и построения отчетов обеспечивают функции построения запросов к информационно-аналитическим системам, интеграцию данных из нескольких источников, просмотр данных с возможностью их детализации и обобщения, построение и печать отчетов, в том числе презентационного качества. Некоторые из программных продуктов этого класса могут использоваться конечными пользователями, с минимальной поддержкой ИТ-департамента, другие же требуют определенного программирования и настраиваются техническими специалистами [45].

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