OLAP в финансовом управлении. Гибридный подход к хранению данных. Этот непонятный OLAP

В 1993 году основоположник реляционного подхода к построению баз данных Эдгар Кодд с партнерами (Edgar Codd, математик и стипендиат IBM), опубликовали статью, инициированную компанией "Arbor Software" (сегодня это известнейшая компания "Hyperion Solutions"), озаглавленную "Обеспечение OLAP (оперативной аналитической обработки) для пользователей-аналитиков", в которой сформулированы 12 особенностей технологии OLAP , которые впоследствии были дополнены еще шестью. Эти положения стали основным содержанием новой и очень перспективной технологии.

Основные особенности технологии OLAP (Basic):

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

Специальные особенности ( Special ):

• обработка неформализованных данных;
• сохранение результатов OLAP : хранение их отдельно от исходных данных;
• исключение отсутствующих значений;
• обработка отсутствующих значений.

Особенности представления отчетов ( Report ):

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

Управление измерениями ( Dimension ):

• универсальность измерений;
• неограниченное число измерений и уровней агрегации ;
• неограниченное число операций между размерностями.

Исторически сложилось так, что сегодня термин " OLAP " подразумевает не только многомерный взгляд на данные со стороны конечного пользователя, но и многомерное представление данных в целевой БД. Именно с этим связано появление в качестве самостоятельных терминов "Реляционный OLAP" ( ROLAP ) и "Многомерный OLAP" ( MOLAP ).

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

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

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

Рис. 6.14.

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

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

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

В настоящее время быстрое развитие получило направление, называемое динамическим моделированием (Dynamic Simulation ), в полной мере реализующее указанный выше принцип FASMI.

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

В таблице 6.3 приведены сравнительные характеристики статического и динамического анализа.

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

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

Ключевые вопросы "Сколько продано?", "На какую сумму продано?" расширяются по мере усложнения бизнеса и накопления исторических данных до некоторого множества факторов, или разрезов: "..в Санкт-Петербурге, в Москве, на Урале, в Сибири…", "..в прошлом квартале, по сравнению с нынешним", "..от поставщика А по сравнению с поставщиком Б…" и т. д.

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

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

Время . Как правило, это несколько периодов: Год, Квартал, Месяц, Декада, Неделя, День. Многие OLAP -инструменты автоматически вычисляют старшие периоды из даты и вычисляют итоги по ним.

Категория товара . Категорий может быть несколько, они отличаются для каждого вида бизнеса: Сорт, Модель, Вид упаковки и пр. Если продается только один товар или ассортимент очень невелик, то категория не нужна.

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

Регион . В зависимости от глобальности бизнеса можно иметь в виду Континент, Группа стран, Страна, Территория, Город, Район, Улица, Часть улицы. Конечно, если есть только одна торговая точка, то это измерение отсутствует.

Продавец . Это измерение тоже зависит от структуры и масштабов бизнеса. Здесь может быть: Филиал, Магазин, Дилер, Менеджер по продажам. В некоторых случаях измерение отсутствует, например, когда продавец не влияет на объемы сбыта, магазин только один и так далее.

Покупатель . В некоторых случаях, например, в розничной торговле , покупатель обезличен и измерение отсутствует, в других случаях информация о покупателе есть, и она важна для продаж. Это измерение может содержать название фирмы-покупателя или множество группировок и характеристик клиентов: Отрасль, Группа предприятий, Владелец и так далее.. Анализ структуры продаж для выявления важнейших составляющих в интересующем разрезе. Для этого удобно использовать, например, диаграмму типа "Пирог" в сложных случаях, когда исследуется сразу 3 измерения - "Столбцы". Например, в магазине "Компьютерная техника" за квартал продажи компьютеров составили $100000, фототехники -$10000, расходных материалов - $4500. Вывод: оборот магазина зависит в большой степени от продажи компьютеров (на самом деле, быть может, расходные материалы необходимы для продажи компьютеров, но это уже анализ внутренних зависимостей).

Анализ динамики ( регрессионный анализ - выявление трендов ). Выявление тенденций, сезонных колебаний. Наглядно динамику отображает график типа "Линия". Например, объемы продаж продуктов компании Intel в течение года падали, а объемы продаж Microsoft росли. Возможно, улучшилось благосостояние среднего покупателя, или изменился имидж магазина, а с ним и состав покупателей. Требуется провести корректировку ассортимента. Другой пример: в течение 3 лет зимой снижается объем продаж видеокамер.

Анализ зависимостей (корреляционный анализ). Сравнение объемов продаж разных товаров во времени для выявления необходимого ассортимента - "корзины". Для этого также удобно использовать график типа "Линия". Например, при удалении из ассортимента принтеров в течение первых двух месяцев обнаружилось падение продаж картриджей с порошком.

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

OLAP -системы являются частью более общего понятия "интеллектуальные ресурсы предприятия" или "средства интеллектуального бизнес-анализа" ( Business Intelligence - BI), которое включает в себя помимо традиционного OLAP -сервиса средства организации совместного использования данных и информации, возникающих в процессе работы пользователей хранилища. Технология Business Intelligence обеспечивает электронный обмен отчетными документами, разграничение прав пользователей, доступ к аналитической информации из Internet и Intranet .

Настольные OLAP-программы и OLAP-компоненты

Классификация OLAP - программ

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

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

Программы, реализующие эту методику, делятся на следующие категории:

1. OLAP-сервер или MOLAP-многомерная СУБД. Это машина вычислений и многомерная база данных, к которой обращаются клиентские программы с командами на получение данных и выполнение вычислений. В MOLAP хранятся - наборы данных, фактов и измерений, с заранее вычисленными агрегатами.
2. MOLAP-компонента. Это инструмент программиста, при помощи которого разрабатываются клиентские программы, получающие вычисленные кубов от OLAP-сервера по какому-либо интерфейсу, например OLE DB for OLAP корпорации Microsoft.
3. ROLAP-компонента. Это тоже инструмент программиста. В отличие от визуальной OLAP-компоненты она содержит собственную OLAP-машину для преобразования реляционных данных или многомерной матрицы в многомерные кубы. Другими словами, эта программа по запросу пользователя в оперативной памяти вычисляет агрегаты и сама же их отображает на экране.
4. ROLAP-сервер. Относительно новый класс программного обеспечения. В отличие от OLAP-сервера не имеет в своем составе многомерной базы данных, а преобразует данные реляционной СУБД в многомерные кубы по запросу многих клиентских приложений.
5. OLAP-программа. Это законченное решение, содержащее в своем составе OLAP-компоненту, средства описания произвольных запросов (Ad-hoc query) и интерфейс доступа к базам данных. В свою очередь такие программы можно разбить на две группы: MOLAP- и ROLAP-программы.

OLAP-компоненты

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

Подавляющее большинство поставщиков OLAP, а их в мире насчитывается около 140, не продают свои компоненты. Нам известно только три компоненты, которые можно купить для собственной разработки. Это Decision Cube компании Inprise в составе компиляторов Delphi и C++ Builder, Pivot Table корпорации Microsoft в составе MS Office, и Dynamic Cube компании Data Dynamic, специализирующейся на разработке OLAP-компонент.

Decision Cube компании Inprise поставляется как VCL-компонента. По нашей классификации относится к ROLAP-компонентам, то есть содержит в своем составе OLAP-машину и предназначен только для работы с реляционными СУБД или локальными таблицами. Он отличается весьма скромными возможностями. Например, в нем нельзя открыть один элемент измерения, или установить фильтр по нескольким измерениям, отобразить несколько фактов одновременно. Производительность компоненты невысока. Пределом является около 4000 записей при 5 измерениях. Компонента отображает в таблице одновременно только один факт. Неприятной особенностью является наличие в исходных текстах нескольких ошибок, в результате чего только высококвалифицированные программисты после исправления этих ошибок могут использовать компоненту в своих разработках. К достоинствам можно отнести простоту применения и освоения компоненты. При правильном использовании и небольших объемах данных продукты на базе этой компоненты могут оказаться полезными и приемлемыми по быстродействию.

Pivot Table корпорации Microsoft поставляется в двух вариантах: как составная часть MS Excel и как Web-компонента. Web-компонента (ActiveX) может быть использована как в браузере, так и собственном Windows-приложении. Pivot Table является одновременно и MOLAP- и ROLAP-компонентой. По протоколу OLE DB for OLAP он может взаимодействовать с многомерной СУБД MS OLAP Server, или другими 70-ю многомерными СУБД, разработчики которых поддержали этот протокол. По протоколу OLE DB Pivot Table может получать данные от реляционной СУБД и выполнять вычисления кубов в памяти. И конечно данные могут быть получены из заданной области таблицы MS Excel. В этом случае его производительность не отличается от производительности Decision Cube. Компонента отображает в таблице одновременно только один факт. Однако инструментарий компоненты шире, чем у Decision Cube - реализована произвольная фильтрация и раскрытие одного элемента измерения. Основным назначением компоненты является создание интерфейсов к OLAP-серверу в рамках концепции Business Intelligent корпорации Microsoft.

Dynamic Cube компании Data Dynamic является классической ROLAP-компонентой. Он поставляется как VCL для программистов Delphi и C++ Builder и как COM для приверженцев компонентной модели. OLAP- машина компоненты весьма мощна. Она с легкостью обрабатывает десятки и чуть медленнее даже сотни тысяч записей. Есть множественная фильтрация, открытие элемента одного измерения, некоторые дополнительные функции. Компонента позволяет отображать в таблице одновременно несколько фактов. Однако эта компонента довольно дорога, особенно впечатляет ее стоимость для профессиональных разработчиков.

Все три описанные выше компоненты по сравнению с готовыми продуктами многих поставщиков имеют весьма скупую функциональность, ограничивающуюся классическими функциями OLAP: drill down, move, rotate и пр. В то же время в некоторых готовых продуктах часто встречается инструментальная панель, наполненная кнопками дополнительных удобных функций. Таких как, и даже кнопками, выполняющими популярные аналитические задачи, например классический маркетинговый анализ 20/80.

Настольные OLAP-программы

Еще недавно поставщики OLAP-серверов продавали свои продукты по таким ценам, что их покупатели должны были быть богаты как арабские шейхи. Так, приобретение Oracle Express обошлось бы в $100 000 за рабочие места двух аналитиков и двух администраторов. Но, даже после выхода на рынок компании Microsoft, которая обрушила цены, предоставив OLAP-сервер бесплатно в составе MS SQL Server, создание Хранилищ данных или витрин данных остается серьезным мероприятием, требующим привлечения профессионального разработчика, администрирования в процессе эксплуатации и других расходов.

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

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

• Локальные манипулируют данными таблицы MS Excel или небольших баз данных типа Access, DBF, Paradox.
• Корпоративные DOLAP имеют доступ к SQL-серверам или многомерным базам данных и, таким образом, тоже делятся на две категории.

Корпоративные DOLAP, предназначенные для анализа данных SQL-серверов позволяют анализировать уже имеющиеся в корпорации данные, хранящиеся в OLTP-системах. Однако вторым их назначением может быть быстрое и дешевое создание Хранилищ или витрин данных, когда программистам организации требуется лишь создать совокупности таблиц типа "звезда" и процедуры загрузки данных. Наиболее трудоемкая часть работы - разработка интерфейсов с многочисленными вариантами пользовательских запросов, интерфейсов и отчетов становится ненужной. Это буквально за несколько часов реализуется в DOLAP-программе. Освоение же такой программы конечным пользователем требует 30 минут.

DOLAP программы поставляются самими разработчиками баз данных, многомерных и реляционных. Это SAS Corporate Reporter, являющийся почти эталонным по удобству и красоте продуктом, Oracle Discovery, комплекс программ MS Pivot Services и Pivot Table и другие. Эти продукты, за исключением программ Microsoft, стоят недешево. Так SAS Corporate Reporter обойдется в $2000 на одного пользователя.

Большая группа программ поставляется в рамках компании "OLAP в массы", которую проводит корпорация Microsoft. Эти программы предназначены для работы с MS OLAP Services. Как правило, они являются улучшенными вариантами Pivot Table и предназначены для использования в рамках MS Office или Web. Это Matryx, Knosys и т.д.

Благодаря простоте, дешевизне и огромной эффективности этот класс продуктов приобрел огромную популярность на Западе. Большие корпорации строят свои Хранилища с распределенным доступом на основе таких программ.

OLAP-продукты компании "Intersoft Lab"

Контур Стандарт

Основным продуктом компании "Intersoft Lab" является большая информационно-управленческая система "Контур Корпорация", построенная по принципам Хранилища данных. Однако в процессе общения с клиентами компании осознала, что далеко не все готовы на инвестиции и организационные мероприятия, связанные с построением серьезного Хранилища данных. Первым шагом на этом пути для многих банков и предприятий мог бы стать OLAP-анализ данных из имеющихся OLTP-систем и собственных аналитических базах данных.

Для этих целей был создан DOLAP-продукт "Контур Стандарт".

Контур Стандарт 1.0 Первая версия системы относилась к классу локальных DOLAP. Средства программы позволяли организовать прямой доступ к dbf- и paradox-файлам. Кроме того, в состав дистрибутивного пакета входил мигратор данных, который помогал собрать в локальные таблицы данные из имеющихся у организации систем.

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

Одновременно для удобства администрирования программа была разделена на две редакции. Редакция "Developer" позволяет IT-специалисту описать источники данных и выборки. При этом создаются семантические словари, которые скрывают от конечного пользователя физический слой и переводят данные на язык предметной области. Редакция "Run-Time" позволяет анализировать данные и выпускать отчеты. Основным способом манипуляции данными является OLAP-компонента, которая позволяет без программирования и специальных навыков создавать необходимые отчеты. Одновременно были созданы и новые виды удобных аналитических инструментов, которые формально не являются OLAP-таблицами, но являются OLAP-средствами по духу, т.е. реализуют on-line анализ, но в другой форме представления данных.

В первых двух версиях применялась ROLAP-компонента Decision Cube компании Inprise. Однако ее невысокая мощность и функциональная упрощенность сдерживала применение программы в банках и организациях для анализа больших объемов данных. Поэтому было принято решение о ее замене. Маркетинговый анализ и ревизия интеллектуальных и производственных мощностей самой компании привели к решению о создании собственной OLAP-компоненты. В результате разработки компоненты, которую назвали Contour Cube, появилась следующая версия программы - "Контур Стандарт" 3.0, которая позволяет обрабатывать выборки данных до миллиона записей и обладает расширенной аналитической функциональностью.

Contour Cube

Компонента Contour Cube компании "Intersoft Lab" является представителем ROLAP-компонент. Она состоит из OLAP-машины, интерфейса доступа к данным, находящимся в SQL-серверах и других источниках, и визуальной части.

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

Версия VCL для использования в средах Delphi и C++ Builder компании Inprise. В этом случае данные поставляются через стандартный Data Set этих компиляторов. Доступ к источникам обеспечивается как при помощи BDE, так и ADO, поддержанной в последних версиях этих сред.

Версия COM предназначена для разработчиков на Visual Basic, Visual С++ и т.д. Она обеспечивает доступ к данным при помощи ADO. В будущих версиях будет поддержан и доступ к OLAP-серверам через интерфейс OLE DB for OLAP.

Версия ActiveX является Web-компонентой для создания аналитических Интернет-интерфейсов в стиле, предложенном Microsoft.

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

Основными достоинствами компоненты являются:

• Обработка больших объемов данных.
• Минимальные требования к памяти.
• Расширенная функциональность.

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

Создание множества версий компоненты стало возможно благодаря ее многослойной архитектуре. Слой OLAP Engine является относительно независимой частью компоненты. Он реализован как кросс-платформенная библиотека, имеющая API для различных слоев визуализации. Этот API обладает функциями загрузки данных, вычисления срезов многомерного куба и выполнения аналитических и сервисных функций. Сам слой OLAP Engine состоит из машины вычислений и абстрактного многомерного Хранилища данных, которое может сохраняться в виде файла для передачи другим пользователям или длительного использования.

Обработка больших объемов данных

Тесты на персональном компьютере с процессором Intel Celeron 400 и оперативной памятью 64 Мб дали следующие результаты. Загрузка 60 000 записей с 6-ю измерениями занимает 5 секунд; дальнейшие манипуляции, такие как полный поворот таблицы, drill down и drill up выполняются за десятые доли секунды.

Это лучшие по порядку величины (sic!) результаты из известных нам OLAP-компонент. Так, Decision Cube и Pivot Table (без использования OLAP Services) требуют десятки секунд для загрузки и поворота таблицы объемом в 4000 записей и 6-ю измерениями. Скорость работы Dynamic Cube ниже, чем у Contour Cube, в среднем на 30% на средних объемах данных и в разы на предельных объемах.

Таким образом, во многих случаях благодаря своей мощности компонента делает необязательным использование OLAP-сервера. Это значительно упрощает процессы внедрения и администрирования корпоративной системы.

Минимальные требования к памяти

В момент работы с данными компонента занимает наименьший объем оперативной памяти по сравнению с одноклассниками. Так при загрузке 40 000 записей Contour Cube потребляет 7 МБ, Decision Cube 15 МБ.

Расширенная функциональность

В компоненте объединены функции лучших OLAP-компонент:

• Множественный фильтр по измерениям.
• Генерация как стандартных временных периодов ("Год", "Квартал", "Месяц", "Декада", "Неделя", etc.), так и задаваемых пользователем ("Финансовый год", "Сезон", "Время суток") по измерению типа "дата".
• Сортировка по измерениям.
• Сортировка по фактам.
• Открытие одного значения измерения (ветви).
• Автоматическое управление диаграммой.
• Ручная настройка диаграммы.
• Множество фактов.
• Множество стандартных алгоритмов агрегации фактов.
• Алгоритм агрегации "Остаток счета".

Уникальное свойство компоненты - алгоритм агрегации "Остаток счета". В связи с тем, что в основном OLAP-компоненты предназначаются для анализа продаж и других суммирующих видов анализов, они агрегируют по времени и остатки счетов. Это является ошибкой - остаток счета за квартал не является суммой остатков счета за день, а является остатком за последний день квартала. Реализация этого алгоритма позволяет использовать компоненту для анализа балансов и делает ее полезной не только для экономистов и маркетологов, но и для бухгалтеров.

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

• Удалить нулевые колонки, удалить нулевые строки, удалить нулевые колонки и строки. Применяется для сжатия разреженных таблиц.
• Полный поворот. При этом колонки и строки таблицы меняются местами. Применяется для улучшения восприятия таблиц аналитиком, для подбора лучшей печатной формы.
• Фильтр по факту. Позволяет задать абсолютные граничные значения факта или количество наибольших или наименьших элементов. Является одним из инструментов факторного анализа.
• Кластерный анализ. Разбиение данных на заданное количество групп по предельным значениям факта. Например, разбиение клиентов на крупных, средних и мелких по объемам полученных от них доходов.
• 80/20. Популярная на Западе разновидность кластерного анализа в маркетинге. Пример ее применения: показать 20% клиентов, которые приносят 80% прибыли.
• Ранжирование. Генерация нового измерения "место в списке" по значению заданного факта и сортировка по нему. Полезно для анализа избирательных компаний, сравнения банков, предприятий, филиалов по заданному показателю.
• Отображение одновременно нескольких статистических итогов, таких как среднее, среднеквадратическое отклонение и т.д. Эта функция понравится продвинутым специалистам, особенно в области финансового, фондового анализа.
• Выгрузка в форматы MS Excel, MS Word, html. Позволяют продолжить анализ привычными средствами MS Excel, создать отчет произвольной формы, опубликовать отчет в Интернет.

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

OLAP - аббревиатура от английского On-Line Analytical Processing - это название не конкретного продукта, а целой технологии. По-русски удобнее всего называть OLAP оперативной аналитической обработкой. Хотя в некоторых изданиях аналитическую обработку называют и онлайновой, и интерактивной, однако прилагательное "оперативная" как нельзя более точно отражает смысл технологии OLAP.

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

Рассмотрим, как обычно происходит процесс разработки решений.

Исторически сложилось так, что решения по автоматизации оперативной деятельности наиболее развиты. Речь идет о системах транзакционной обработки данных (OLTP), иначе называемых оперативными системами. Эти системы обеспечивают регистрацию некоторых фактов, их непродолжительное хранение и сохранение в архивах. Основу таких систем обеспечивают системы управления реляционными базами данных (РСУБД). Традиционным подходом являются попытки использовать уже построенные оперативные системы для поддержки принятия решений. Обычно пытаются строить развитую систему запросов к оперативной системе и использовать полученные после интерпретации отчеты непосредственно для поддержки решений. Отчеты могут строиться на заказной базе, т.е. руководитель запрашивает отчет, и на регулярной, когда отчеты строятся по достижении некоторых событий или времени. Например, традиционный процесс поддержки принятия решений может выглядеть таким образом: руководитель идет к специалисту информационного отдела и делится с ним своим вопросом. Затем специалист информационного отдела строит запрос к оперативной системе, получает электронный отчет, интерпретирует его и доводит его до сведения руководящего персонала.

Конечно, такая схема обеспечивает в какой-то мере поддержку принятия решений, но она имеет крайне низкую эффективность и огромное число недостатков. Ничтожное количество данных используется для поддержки критически важных решений. Есть и другие проблемы. Подобный процесс очень медленен, так как длителен сам процесс написания запросов и интерпретации электронного отчета. Он занимает многие дни, в то время как руководителю, быть может, необходимо принять решение прямо сейчас, немедленно. Если учесть, что руководителя после получения отчета может заинтересовать другой вопрос (скажем, уточняющий или требующий рассмотрения данных в другом разрезе), то этот медленный цикл должен повториться. А так как процесс анализа данных оперативных систем будет происходить итерационно, то времени тратится ещё больше. Другая проблема - различие областей деятельности специалиста по информационным технологиям и руководителя, которые могут мыслить в разных категориях и, как следствие, - не понимать друг друга. Это значит, что потребуются дополнительные уточняющие итерации, а это снова время, которого всегда не хватает. Ещё одной важной проблемой является сложность отчетов для понимания. У руководителя нет времени выбирать интересующие цифры из отчёта, тем более что их может оказаться слишком много (вспомним огромные многостраничные отчеты, в которых реально используются несколько страниц, а остальные - на всякий случай). Отметим также, что работа по интерпретации ложится чаще всего на специалистов информационных отделов. То есть грамотный специалист отвлекается на рутинную и малоэффективную работу по рисованию диаграмм и т.п., что, естественно, не может благоприятно сказываться на его квалификации. Кроме того, не является секретом присутствие в цепочке интерпретации благожелателей, заинтересованных в преднамеренном искажении поступающей информации.

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

В действительности эти проблемы не являются следствием низкого качества оперативной системы или ее неудачной постройки. Корни проблем кроются в фундаментальном отличии той оперативной деятельности, которая автоматизируется оперативной системой, и деятельностью по разработке и принятию решений. Отличие это состоит в том, что данные оперативных систем являются просто записями о некоторых имевших место событиях, фактах, но никак не информацией в общем смысле этого слова. Информация - это то, что снижает неопределенность в какой-либо области. И было бы очень неплохо, если бы информация снижала неопределенность в области подготовки решений. По поводу непригодности для этой цели оперативных систем, построенных на РСУБД, в свое время высказался небезызвестный E.F. Codd, человек, стоявший в 70-е годы у истоков технологий систем управления реляционными БД: "Хотя системы управления реляционными БД доступны для пользователей, они никогда не считались средством, дающим мощные функции по синтезу, анализу и консолидации (функций, называемых многомерным анализом данных)". Речь идет именно о синтезе информации, о том, чтобы превращать данные оперативных систем в информацию и даже в качественные оценки. OLAP позволяет выполнять такое превращение.

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

Немного истории

Идея обработки данных на многомерных массивах не является новой. Фактически она восходит к 1962 году, когда Ken Iverson опубликовал свою книгу "Язык программирования" ("A Programming Language", APL). Первая практическая реализация APL состоялась в поздних шестидесятых компанией IBM. APL - это очень изящный, математически определённый язык с многомерными переменными и обрабатываемыми операциями. Он подразумевался как оригинальное, мощное по сравнению с другими практическими языками программирования средство по работе с многомерными преобразованиями.

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

Однако, досада от этих первоначальных ошибок не убила идею. Она использовалась во многих деловых приложениях 70-х, 80-х годов. Многие из этих приложений имели черты современных систем аналитической обработки. Так, IBM разработала операционную систему для APL, названную VSPC, и некоторые люди считали ее идеальной средой для персонального использования, пока электронные таблицы не стали повсеместно распространены.

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

В 80-х годах APL стал доступен на персональных машинах, но не нашел рыночного применения. Альтернативой было программирование многомерных приложений с использованием массивов в других языках. Это было очень тяжелой задачей даже для профессиональных программистов, что вынуждало ждать следующего поколения многомерных программных продуктов.

В 1972 году несколько прикладных многомерных программных продуктов, ранее использовавшихся в учебных целях, нашли коммерческое применение: например, Express. Он в полностью переписанном виде остаётся и сейчас, однако оригинальные концепции 70-х годов перестали быть актуальными. Сегодня, в 90-х, Express является одной из наиболее популярных OLAP-технологий, и Oracle (r) будет продвигать его и дополнять новыми возможностями.

Больше многомерных продуктов появилось в 80-х годах. В начале десятилетия - продукт с названием Stratagem, позднее называемый Acumate (сегодня владельцем является Kenan Technologies), который еще продвигался до начала 90-х, но сегодня, в отличие от Express, практически не используется.

Comshare System W был многомерным продуктом другого стиля. Представленный в 1981 году, он был первым, где предполагалась большая ориентированность на конечного пользователя и на разработку финансовых приложений. Он привнёс много новых концепций, которые, правда, не были хорошо адаптированы: такие, как полностью непроцедурные правила, полноэкранный просмотр и редактирование многомерных данных, автоматическое перевычисление и пакетная интеграция с реляционными данными. Однако Comshare System W был достаточно тяжел для аппаратного обеспечения того времени по сравнению с другими продуктами. Он меньше использовался в будущем, всё меньше продавался, и в продукте не делалось никаких улучшений. Хотя он и сегодня доступен на UNIX, он не является клиент-серверным, что не способствует повышению его предложения на рынке аналитических продуктов. В поздних 80-х Comshare выпустил продукт для DOS, а позднее для Windows. Эти продукты назывались Commander Prism и использовали те же концепции, что и System W.

Другой творческий продукт поздних 80-х назывался Metaphor. Он предназначался для профессиональных маркетологов. Он также предложил много новых концепций, которые только сегодня начинают широко использоваться: клиент-серверные вычисления, использование многомерной модели для реляционных данных, объектно ориентированная разработка приложений. Однако стандартное аппаратное обеспечение персональных машин тех дней не было способно работать с Metaphor и поставщики были вынуждены разрабатывать собственные стандарты на персональные машины и сети. Постепенно Metaphor стал работать удачнее и на серийных персональных машинах, однако продукт был выполнен исключительно для OS/2 и имел свой собственный графический интерфейс пользователя.

Затем Metaphor заключил маркетинговый альянс с IBM, которой впоследствии и был поглощён. В середине 1994 года IBM решила интегрировать технологию Metaphor (переименованную в DIS) со своими будущими технологиями и тем самым прекратить финансирование отдельного направления. Однако заказчики выразили своё неудовольствие и потребовали продолжить поддержку продукта. Поддержка была продолжена для оставшихся заказчиков, а IBM перевыпустила продукт под новым названием DIS, что, однако, не сделало его популярным. Но творческие, новаторские концепции Metaphor не были забыты и видны сегодня во многих продуктах.

В середине 80-х родился термин EIS (Executive Information System - информационная система руководителя). Первым продуктом, ясно продемонстрировавшим это направление, был Pilot"Аs Command Center. Это был продукт, который позволял выполнять совместные вычисления, то, что мы называем сегодня клиент-серверными вычислениями. Поскольку мощность персональных компьютеров 80-х годов была ограничена, продукт был очень "сервероцентричен", однако этот принцип и сегодня очень популярен. Pilot недолго продавал Command Center, но предложил много концепций, которые можно узнать в сегодняшних OLAP-продуктах, включая автоматическую поддержку временных промежутков, многомерные клиент-серверные вычисления и упрощённое управление процессом анализа (мышь, чувствительные экраны и т.п.). Некоторые из этих концепций были повторно применены позднее в Pilot Analysis Server.

В конце 80-х электронные таблицы были доминирующими на рынке инструментов, предоставляющих анализ конечным пользователям. Первая многомерная электронная таблица была представлена продуктом Compete. Он продвигался на рынок как очень дорогой продукт для специалистов, но поставщики не обеспечили возможность захвата рынка этим продуктом, и компания Computer Associates приобрела права на него вместе с другими продуктами, включая Supercalc и 20/20. Основным эффектом от приобретения Compete компанией Computer Associates было резкое снижение цены на него и снятие защиты от копирования, что, естественно, способствовало его распространению. Однако он не был удачным. Compete положен в основу Supercalc 5, но многомерный аспект его не продвигается. Старый Compete всё ещё используется в связи с тем, что в свое время в него были вложены немалые средства.

Компания Lotus была следующей, кто попытался войти на рынок многомерных электронных таблиц с продуктом Improv, который запускается на NeXT машине. Это гарантировало, как минимум, что продажи 1-2-3 не снизятся. Но когда тот со временем был выпущен под Windows, Excel уже имел большую долю рынка, что не позволило Lotus внести какие-либо изменения в распределение рынка. Lotus, подобно CA с Compete, переместила Improv в нижнюю часть рынка, однако и это не стало условием удачного продвижения на рынке, и новые разработки в этой области не получили продолжения. Оказалось, что пользователи персональных компьютеров предпочли электронные таблицы 1-2-3 и не интересуются новыми многомерными возможностями, если они не полностью совместимы с их старыми таблицами. Так же концепции маленьких, настольных электронных таблиц, предлагаемых как персональные приложения, в действительности не оказались удобными и не прижились в настоящем деловом мире. Microsoft (r) пошла по этому пути, добавив PivotTables (в русской редакции это называется "сводные таблицы") к Excel. Хотя немногие пользователи Excel получили выгоду от использования этой возможности, это, вероятно, единственный факт широкого использования в мире возможностей многомерного анализа просто потому, что в мире очень много пользователей Excel.

OLAP, ROLAP, MOLAP...

Общеизвестно, что когда Кодд опубликовал в 1985 году свои правила построения реляционных СУБД, они вызвали бурную реакцию и впоследствии сильно отразились вообще на индустрии СУБД. Однако мало кто знает, что в 1993 году Кодд опубликовал труд под названием "OLAP для пользователей-аналитиков: каким он должен быть". В нем он изложил основные концепции оперативной аналитической обработки и определил 12 правил, которым должны удовлетворять продукты, предоставляющие возможность выполнения оперативной аналитической обработки.

Вот эти правила (текст оригинала по возможности сохранен):

1. Концептуальное многомерное представление. Пользователь-аналитик видит мир предприятия многомерным по своей природе. Соответственно и OLAP-модель должна быть многомерной в своей основе. Многомерная концептуальная схема или пользовательское представление облегчают моделирование и анализ так же, впрочем, как и вычисления.
2. Прозрачность. Вне зависимости от того, является OLAP-продукт частью средств пользователя или нет, этот факт должен быть прозрачен для пользователя. Если OLAP предоставляется клиент-серверными вычислениями, то этот факт также, по возможности, должен быть незаметен для пользователя. OLAP должен предоставляться в контексте истинно открытой архитектуры, позволяя пользователю, где бы он ни находился, связываться при помощи аналитического инструмента с сервером. В дополнение к этому прозрачность должна достигаться и при взаимодействии аналитического инструмента с гомогенной и гетерогенной средами БД.
3. Доступность. Пользователь-аналитик OLAP должен иметь возможность выполнять анализ, базирующийся на общей концептуальной схеме, содержащей данные всего предприятия в реляционной БД, также как и данные из старых наследуемых БД, на общих методах доступа и на общей аналитической модели. Это значит, что OLAP должен предоставлять свою собственную логическую схему для доступа в гетерогенной среде БД и выполнять соответствующие преобразования для предоставления данных пользователю. Более того, необходимо заранее позаботиться о том, где и как, и какие типы физической организации данных действительно будут использоваться. OLAP-система должна выполнять доступ только к действительно требующимся данным, а не применять общий принцип "кухонной воронки", который влечет ненужный ввод.
4. Постоянная производительность при разработке отчетов. Если число измерений или объем базы данных увеличиваются, пользователь-аналитик не должен чувствовать какой-либо существенной деградации в производительности. Для конечного пользователя критичной является как постоянная производительность, так и поддержание легкости в использовании и ограничения сложности OLAP. Если пользователь-аналитик будет испытывать существенные различия в производительности в соответствии с числом измерений, тогда он будет стремиться компенсировать эти различия стратегией разработки, что вызовет представление данных другими путями, но не теми, которыми действительно нужно эти данные представить. Затраты времени на обход системы для компенсации ее неадекватности - это не то, для чего аналитические продукты предназначены.
5. Клиент-серверная архитектура. Большинство данных, которые сегодня требуется подвергать оперативной аналитической обработке, содержатся на мэйнфреймах с доступом через ПК. Это означает, что OLAP-продукты должны быть способны работать в среде клиент-сервер. С этой точки зрения представляется необходимым, чтобы серверный компонент аналитического инструмента был настолько "интеллектуальным", чтобы различные клиенты могли присоединяться к серверу с минимальными затруднениями и интеграционным программированием. "Интеллектуальный" сервер должен быть способен выполнять отображение и консолидацию между несоответствующими логическими и физическими схемами баз данных. Это обеспечит прозрачность и возможность построения общей концептуальной, логической и физической схемы.
6. Общая многомерность. Каждое измерение должно применяться безотносительно своей структуры и операционных способностей. Дополнительные операционные способности могут предоставляться выбранным измерениям, и, поскольку измерения симметричны, отдельно взятая функция может быть предоставлена любому измерению. Базовые структуры данных, формулы и форматы отчетов не должны смещаться в сторону какого-либо измерения.
7. Динамическое управление разреженными матрицами. Физическая схема OLAP-инструмента должна полностью адаптироваться к специфической аналитической модели для оптимального управления разреженными матрицами. Для любой взятой разреженной матрицы существует одна и только одна оптимальная физическая схема. Эта схема предоставляет максимальную эффективность по памяти и операбельность матрицы, если, конечно, весь набор данных помещается в памяти. Для практических операций с большими аналитическими моделями базовые физические данные OLAP-инструмента должны конфигурироваться к любому подмножеству измерений и в любом порядке. Физические методы доступа также должны динамически меняться и содержать различные типы механизмов, таких как: непосредственные вычисления, B-деревья и производные, хеширование, возможность комбинировать эти механизмы при необходимости. Разреженность (измеряется в процентном отношении пустых ячеек ко всем возможным) - это одна из характеристик распространения данных. Невозможность регулировать разреженность может сделать эффективность операций недостижимой. Если OLAP-инструмент не может контролировать и регулировать распространение значений анализируемых данных, модель, претендующая на практичность, базирующаяся на многих путях консолидации и измерениях, в действительности может оказаться ненужной и безнадежной.
8. Многопользовательская поддержка. Часто несколько пользователей-аналитиков испытывают потребность работать совместно с одной аналитической моделью или создавать различные модели из единых данных. Следовательно, OLAP-инструмент должен предоставлять возможности совместного доступа (запроса и дополнения), целостности и безопасности.
9. Неограниченные перекрестные операции. Различные уровни свертки и пути консолидации вследствие их иерархической природы представляют зависимые отношения в OLAP-модели или приложении. Следовательно, сам инструмент должен подразумевать соответствующие вычисления и не требовать от пользователя-аналитика вновь определять эти вычисления и операции. Вычисления, не следующие из этих наследуемых отношений, требуют определения различными формулами в соответствии с некоторым применяющимся языком. Такой язык может позволять вычисления и манипуляцию с данными любых размерностей и не ограничивать отношения между ячейками данных, не обращая внимания на количество общих атрибутов данных конкретных ячеек.
10. Интуитивная манипуляция данными. Переориентация путей консолидации, детализация, укрупнение и другие манипуляции, регламентируемые путями консолидации, должны применяться через отдельное воздействие на ячейки аналитической модели, а также не должны требовать использования системы меню или иных множественных действий с пользовательским интерфейсом. Взгляд пользователя-аналитика на измерения, определенный в аналитической модели, должен содержать всю необходимую информацию, чтобы выполнять вышеуказанные действия.
11. Гибкие возможности получения отчетов. Анализ и представление данных являются простыми, когда строки, столбцы и ячейки данных, которые будут визуально сравниваться между собой, либо находятся вблизи друг от друга, либо располагаются в соответствии с некоторой логической функцией, имеющей место на предприятии. Средства формирования отчетов должны представлять собой синтезируемые данные или информацию, следующую из модели данных в ее любой возможной ориентации. Это означает, что строки, столбцы или страницы должны показывать одновременно от 0 до N измерений, где N - число измерений всей аналитической модели. В дополнение к этому, каждое измерение содержимого, показанное в одной записи, колонке или странице, должно также быть способно показать любое подмножество элементов (значений), содержащихся в измерении, причем в любом порядке.
12. Неограниченная размерность и число уровней агрегации. Исследование о возможном числе необходимых измерений, требующихся в аналитической модели, показало, что одновременно может использоваться до 19 измерений. Отсюда вытекает настоятельная рекомендация, чтобы аналитический инструмент был способен одновременно предоставить как минимум 15 измерений, а предпочтительнее 20. Более того, каждое из общих измерений не должно быть ограничено по числу определяемых пользователем-аналитиком уровней агрегации и путей консолидации.

Фактически сегодня разработчики OLAP-продуктов следуют этим правилам или, по крайней мере, стремятся им следовать. Эти правила можно считать теоретическим базисом оперативной аналитической обработки, с ними трудно спорить. Позже было выведено множество следствий из 12 правил, которые мы, однако, не будем приводить, дабы излишне не усложнять повествование.

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

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

MOLAP. Собственно многомерная (multidimensional) OLAP. В основе продукта лежит нереляционная структура данных, обеспечивающая многомерное хранение, обработку и представление данных. Соответственно и базы данных называют многомерными. Продукты, относящиеся к этому классу, обычно имеют сервер многомерных баз данных. Данные в процессе анализа выбираются исключительно из многомерной структуры. Подобная структура является высокопроизводительной.

ROLAP. Реляционная (relational) OLAP. Как и подразумевается названием, многомерная структура в таких инструментах реализуется реляционными таблицами. А данные в процессе анализа, соответственно, выбираются из реляционной базы данных аналитическим инструментом.

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

Есть еще один достаточно экзотический вид оперативной аналитической обработки - DOLAP. Это "настольный" (desktop) OLAP. Речь идет о такой аналитической обработке, где гиперкубы малы, размерность их небольшая, потребности скромны, и для такой аналитической обработки достаточно персональной машины на рабочем столе.

Заключение

Оперативная аналитическая обработка позволяет значительно упростить и ускорить процесс подготовки и принятия решений руководящим персоналом. Оперативная аналитическая обработка служит цели превращения данных в информацию. Она принципиально отличается от традиционного процесса поддержки принятия решений, основанного, чаще всего, на рассмотрении структурированных отчетов. По аналогии, разница между структурированными отчетами и OLAP такая, как между ездой по городу на трамвае и на личном автомобиле. Когда вы едете на трамвае, он двигается по рельсам, что не позволяет хорошо рассмотреть отдаленные здания и тем более приблизиться к ним. Наоборот, езда на личном автомобиле дает полную свободу передвижения (естественно, следует соблюдать ПДД). Можно подъехать к любому зданию и добраться до тех мест, где трамваи не ходят.

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

Кроме этой статьи Вы можете посмотреть по тематеке текущего раздела:
в разделе "Энциклопедия"
7 статей в разделе "Статьи".

Разобравшись в том, что такое OLAP и каковы его свойства, перейдем к самому, пожалуй, важному вопросу: для кого предназначены программ­ные продукты этого класса?

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

Часто возникает вопрос: чем, с точки зрения пользователя-аналитика, OLAP-система отличается от хранилища данных? Можно сказать, что главное, с точки зрения пользователя, отличие OLAP состоит в струк­турированности информации в соответствии с ее предметной (именно предметной, а не технической) сущностью. Работая с OLAP-приложе- нием, аналитик использует привычные финансово-экономические тер­мины, категории и показатели (виды материалов и готовой продукции, регионы продаж, объем реализации, себестоимость, прибыль и т. п.), а для того чтобы сформировать любой, даже довольно сложный запрос, ему не придется изучать язык SQL. И при этом ответ на запрос будет получен в течение всего нескольких секунд. Кроме того, работая с OLAP-системой, экономист может пользоваться такими привычными для себя инструментами, как электронные таблицы, или специальными средствами построения отчетов.

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

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

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

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

Концепция Business Performance Management: начало пути Средства формирования запросов и отчетности

Как уже было отмечено, средства формирования запросов и постро­ения отчетов {Query and Reporting took) обеспечивают функции пост­роения запросов к информационно-аналитическим системам, интегра­цию данных из нескольких источников, просмотр данных с возможностью детализации и обобщения, построение и печать полно­ценных отчетов, в том числе презентационного качества. Некоторые из программных продуктов этого класса могут использоваться конечными пользователями, с минимальной поддержкой ИТ-департамента, другие же требуют определенного программирования и настраиваются техни­ческими специалистами.

Типичными представителями систем этого класса являются програм­мные продукты корпорации Hyperion, объединенные в семейство Hyperion Performance Suite.

Hyperion Performance Suite представляет собой набор средств построения запросов, анализа, формирования отчетов и их регламентированной до­ставки в рамках всей организации. Эти программные продукты вошли в линейку BI-систем Hyperion после того, как в 2003 году Hyperion при­обрел Brio Software - компанию, хорошо известную на рынке систем бизнес-интеллекта благодаря своим эффективным и легким в использо­вании решениям. До этого на протяжении ряда лет компании Hyperion и Brio тесно сотрудничали как технологические партнеры, поэтому объ­единение их разработок позволило создать уникальную линейку, в кото­рой решения Hyperion (OLAP-система Hyperion Essbase и аналитические приложения - Hyperion Planning, Hyperion Financial Management и дру­гие) оказались органично дополнены современными средствами запросов и отчетности Brio. В результате Hyperion стал обладателем самой мощной и полнофункциональной линейкой из всех присутствующих на рынке программных продуктов класса Business Intelligence. Сегодня все эти решения, по достоинству оцененные многими зарубежными компаниями, стали доступны российским предприятиям.

Комплект Hyperion Performance Suite включает в себя два программных продукта - Hyperion Intelligence и Hyperion SQR.

Hyperion Intelligence - это современная, удобная в работе система для формирования сложных запросов к различным источникам данных, включая ERP, CRM, банковские и прочие транзакционные системы, а также для представления этих данных в удобном для анализа виде. Эф­фективно используя данные, хранящиеся в существующих информаци­онных системах , Hyperion Intelligence дает возможность разработчикам, аналитикам и потребителям превратить «сырые» данные в ценную информацию для принятия решений. Аналитические возмож­ности системы позволяют специалистам организации оперативно оцени­вать возможности и тенденции бизнеса и повысить обоснованность принимаемых управленческих решений, а интуитивно понятный интер­фейс пользователя, основанный на Интернет-технологиях, делает инфор­мацию доступной любому из уполномоченных пользователей.

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

Линейка BI-решений Hyperion, дополненная средствами запросов и отчетности, доставшимися «по наследству» от Brio, представляет инте­рес как для ИТ-специалистов, так и для конечных пользователей.

С точки зрения конечного пользователя, это - удобный инструмент, позволяющий решить уже упоминавшуюся проблему, с которой так часто сталкиваются менеджеры и предметные специалисты - проблему «единого взгляда на управленческую информацию». Напомним, что эта проблема состоит в том, что очень часто управленческая информация, необходимая для анализа и принятия решений, хранится в разных ис­точниках - учетных системах, ERP-системах, базах данных и т. п. Это крайне затрудняет получение нужной информации и ее представление в удобном для пользователя виде: специалисты вынуждены тратить время на рутинные процедуры сбора данных и их обработки, причем с риском искажения. Управленческая информация, полученная таким путем, часто не соответствует требованиям достоверности и актуаль­ности, что снижает ее ценность. В этом плане BI-решения Hyperion позволяют существенно упростить и ускорить сбор информации, уни­фицировать ее и представить в удобной и наглядной форме. Такая информация - надежная база для принятия управленческих решений, при этом рутинные процедуры сводятся к минимуму, а время специа­листов высвобождается для решения аналитических задач.

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

Целью курсовой работы является изучение технологии OLAP, понятие ее реализации и структуры.

В современном мире компьютерные сети и вычислительные системы позволяют анализировать и обрабатывать большие массивы данных.

Большой объем информации сильно усложняет поиск решений, но дает возможность получить намного точнее расчеты и анализ. Для решения такой проблемы существует целый класс информационных систем, выполняющих анализ. Такие системы называют системами поддержки принятия решений (СППР) (DSS, Decision Support System).

Для выполнения анализа СППР должна накапливать информацию, обладая средствами ее ввода и хранения. Всего можно выделить три основные задачи, решаемые в СППР:

· ввод данных;

· хранение данных;

· анализ данных.

Ввод данных в СППР осуществляется автоматически от датчиков, характеризующих состояние среды или процесса, или человеком-оператором.

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

При вводе данных одновременно несколькими операторами, необходимо решать проблемы модификации и параллельного доступа одних и тех же данных.

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

В подсистемах ввода данных, называемых OLTP (On-linetransactionprocessing), реализуется операционная обработка данных. Для их реализации используют обычные системы управления БД (СУБД).

Подсистема анализа может быть построена на основе:

· подсистемы информационно-поискового анализа на базе реляционных СУБД и статических запросов с использованием языка SQL;

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

· подсистемы интеллектуального анализа. Данная подсистема реализует методы и алгоритмы DataMining .

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

1.2 Определение OLAP -систем

Технология комплексного многомерного анализа данных получила название OLAP. OLAP - это ключевой компонент организации ХД.

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

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

Основное назначение OLAP-систем - поддержка аналитической деятельности, произвольных запросов пользователей-аналитиков. Целью OLAP-анализа является проверка возникающих гипотез.