Категории информационных систем. OLAP в финансовом управлении

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

Функциональность OLAP, как систем реализующих интеллектуальный анализ данных, заключается в динамическом многомерном анализе консолидированных данных предприятия, направленном на поддержание следующих аналитических и навигационных видов деятельности пользователя:

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

OLAP-технология

OLAP-технология является альтернативой традиционным методам анализа данных, основанным на различных системах реализации SQL-запросов к реляционной БД. OLAP-системы играют важнейшую роль в анализе и планировании деятельности крупных предприятий и являются одним из направлений развития ИТ. В основу кладутся требования людей принимающих решения к предоставляемой информации, сложившейся индивидуальные особенности ведения дел и принятый механизм принятия решения. С точки зрения пользователя основное отличие OLAP-системы от ХД заключается: в предметной структурированности информации (именно предметной, а не технической). Работая с OLAP-приложением, пользователь применяет привычные категории и показатели – виды материалов и готовой продукции, регионы продаж, объем реализации, себестоимость, прибыль и т. п. А для того чтобы сформировать любой, даже довольно сложный запрос, пользователю не придется изучать SQL. При этом ответ на запрос будет получен в течение всего нескольких секунд. Кроме того, работая с OLAP-системой, экономист может пользоваться такими привычными для себя инструментами, как электронные таблицы или специальные средства построения отчетов.

Разработка решений по управлению предприятием

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

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

Главная особенность аналитических БД (OLAP) – это возможность формирования нерегламентированных запросов к аналитической БД. Загрузка данных в систему производится из оперативной БД предприятия. Корпоративная аналитическая система может состоять из нескольких модулей, каждый из которых обрабатывает несколько информационных массивов, необходимых для проведения всестороннего анализа соответствующего аспекта деятельности предприятия. Информационная модель, на основе которой разработана информационная система, в полном объеме описывает все аспекты предметной области и обеспечивает наглядность и простоту доступа к необходимым для анализа данным.

Внешнее отображение информации в системе

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

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

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

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

OLAP-отчет

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

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

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

Филиал

Статья бюджета

Продукт

Сумма

Процентные доходы

Итого

30 000 000

Непроцентные доходы

Клиентские платежи

Обменные операции

Итого

10 000 000

Итого

40 000 000

Процентные доходы

Итого

6 000 000

Непроцентные доходы

Клиентские платежи

Обменные операции

Итого

3 000 000

Итого

9 000 000

Новосибирск

Итого

52 000 000

Рис. 1 OLAP-отчет

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

Любые данные в OLAP-отчете делятся на две категории – измерения (строки или даты) и факты или меры (числовые данные). Отчет состоит из нескольких фиксированных областей – область колонок, строк, данных и неактивных измерений.

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

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

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

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

Особенности OLAP отчета

Итак, OLAP-отчет отличается рядом принципиальных особенностей, это:

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

Запросы, отчеты, анализ

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

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

Каталог OLAP-решений и проектов смотрите в разделе OLAP на TAdviser.

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

Требования к OLAP-системам. FASMI

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

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

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

При этом такая связка должна удовлетворять очевидным требованиям поддержки импорта-экспорта из нескольких источников данных, осуществления процедур очистки и трансформации данных, унификации используемых классификаторов и справочников. Кроме того, к этим требованиям добавляется необходимость учёта различных циклов обновления данных в существующих информационных системах и унификации требуемого уровня детализации данных. Сложность и многогранность этой проблемы привела к появлению концепции хранилищ данных , и, в узком смысле, к выделению отдельного класса утилит конвертации и преобразования данных - ETL (Extract Transform Load) .

Модели хранения активных данных

Выше мы указали, что OLAP предполагает многомерное иерархическое представление данных, и, в каком-то смысле, противопоставляется базирующимся на РСУБД системам.

Это, однако, не значит, что все OLAP-системы используют многомерную модель для хранения активных, "рабочих" данных системы. Так как модель хранения активных данных оказывает влияние на все диктуемые FASMI-тестом требования, её важность подчёркивается тем, что именно по этому признаку традиционно выделяют подтипы OLAP - многомерный (MOLAP), реляционный (ROLAP) и гибридный (HOLAP).

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

Хранение активных данных в многомерной БД

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

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

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

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

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

Хранение активных данных в реляционной БД

Могут храниться данные OLAP и в традиционной РСУБД . В большинстве случаев этот подход используется при попытке «безболезненной» интеграции OLAP с существующими учётными системами, либо базирующимися на РСУБД хранилищами данных . Вместе с тем, этот подход требует от РСУБД для обеспечения эффективного выполнения требований FASMI-теста (в частности, обеспечения минимального времени реакции системы) некоторых дополнительных возможностей. Обычно данные OLAP хранятся в денормализованном виде, а часть заранее рассчитанных агрегатов и значений хранится в специальных таблицах. При хранении же в нормализованном виде эффективность РСУБД в качестве метода хранения активных данных снижается.

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

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

Среди достоинств хранения данных в РСУБД обычно называют большую масштабируемость таких систем.

Хранение активных данных в «плоских» файлах

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

Гибридный подход к хранению данных

Большинство производителей OLAP-систем, продвигающих свои комплексные решения, часто включающие помимо собственно OLAP-системы СУБД , инструменты ETL (Extract Transform Load) и отчетности, в настоящее время используют гибридный подход к организации хранения активных данных системы, распределяя их тем или иным образом между РСУБД и специализированным хранилищем, а также между дисковыми структурами и кэшированием в оперативной памяти.

Так как эффективность такого решения зависит от конкретных подходов и алгоритмов, применяемых производителем для определения того, какие данные и где хранить , то поспешно делать выводы о изначально большей эффективности таких решений как класса без оценки конкретных особенностей рассматриваемой системы.

OLAP (англ. on-line analytical processing) – совокупность методов динамической обработки многомерных запросов в аналитических базах данных. Такие источники данных обычно имеют довольно большой объем, и в применяемых для их обработки средствах одним из наиболее важных требований является высокая скорость. В реляционных БД информация хранится в отдельных таблицах, которые хорошо нормализованы. Но сложные многотабличные запросы в них выполняются довольно медленно. Значительно лучшие показатели по скорости обработки в OLAP-системах достигаются за счет особенности структуры хранения данных. Вся информация четко организована, и применяются два типа хранилищ данных: измерения (содержат справочники, разделенные по категориям, например, точки продаж, клиенты, сотрудники, услуги и т.д.) и факты (характеризуют взаимодействие элементов различных измерений, например, 3 марта 2010 г. продавец A оказал услугу клиенту Б в магазине В на сумму Г денежных единиц). Для вычисления результатов в аналитическом кубе применяются меры. Меры представляют собой совокупности фактов, агрегированных по соответствующим выбранным измерениям и их элементам. Благодаря этим особенностям на сложные запросы с многомерными данными затрачивается гораздо меньшее время, чем в реляционных источниках.

Одним из основных вендоров OLAP-систем является корпорация Microsoft . Рассмотрим реализацию принципов OLAP на практических примерах создания аналитического куба в приложениях Microsoft SQL Server Business Intelligence Development Studio (BIDS) и Microsoft Office PerformancePoint Server Planning Business Modeler (PPS) и ознакомимся с возможностями визуального представления многомерных данных в виде графиков, диаграмм и таблиц.

Например, в BIDS необходимо создать OLAP-куб по данным о страховой компании, ее работниках, партнерах (клиентах) и точках продаж. Допустим предположение, что компания предоставляет один вид услуг, поэтому измерение услуг не понадобится.

Сначала определим измерения. С деятельности компании связаны следующие сущности (категории данных):

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

Рис.1. Таблицы измерений и фактов в аналитической БД. Последовательность создания
После создания многомерного источника данных в BIDS имеется возможность просмотреть его представление (Data Source View). В нашем примере получится схема, представленная на рисунке ниже.


Рис.2. Представление источника данных (Data Source View) в Business Intellingence Development Studio (BIDS)

Как видим, таблица фактов связана с таблицами измерений посредством однозначного соответствия полей-идентификаторов (PartnerID, EmployeeID и т.д.).

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

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

Что такое хранилище данных?

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

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

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

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

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

Как строят хранилище?

ETL – базовое понятие: Три этапа:
  • Извлечение – извлечение данных из внешних источников в понятном формате;
  • Преобразование – преобразование структуры исходных данных в структуры, удобные для построения аналитической системы;
Добавим еще один этап – очистка данных (Cleaning ) – процесс отсеивания несущественных или исправления ошибочных данных на основании статистических или экспертных методов. Чтобы не формировать потом отчеты типа «Продажи за 20011 год».

Вернемся к анализу.

Что такое анализ и для чего он нужен?

Анализ – исследование данных с целью принятия решений. Аналитические системы так и называют - системы поддержки принятия решений (СППР ).

Здесь стоит указать на отличие работы с СППР от простого набора регламентированных и нерегламентированных отчетов. Анализ в СППР практически всегда интерактивен и итеративен. Т.е. аналитик копается в данных, составляя и корректируя аналитические запросы, и получает отчеты, структура которых заранее может быть неизвестна. Более подробно к этому мы вернемся ниже, когда будем обсуждать язык запросов MDX .

OLAP

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

Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). OLAP - это ключевой компонент организации традиционных хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром Коддом , известным исследователем баз данных и автором реляционной модели данных. В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:

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

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

Многомерные понятия

Мы будем использовать для иллюстрации принципов OLAP базу данных Northwind, входящую в комплекты поставки Microsoft SQL Server и представляющую собой типичную базу данных, хранящую сведения о торговых операциях компании, занимающейся оптовыми поставками продовольствия. К таким данным относятся сведения о поставщиках, клиентах, список поставляемых товаров и их категорий, данные о заказах и заказанных товарах, список сотрудников компании.

Куб

Возьмем для примера таблицу Invoices1, которая содержит заказы фирмы. Поля в данной таблице будут следующие:
  • Дата Заказа
  • Страна
  • Город
  • Название заказчика
  • Компания-доставщик
  • Название товара
  • Количество товара
  • Сумма заказа
Какие агрегатные данные мы можем получить на основе этого представления? Обычно это ответы на вопросы типа:
  • Какова суммарная стоимость заказов, сделанных клиентами из определенной страны?
  • Какова суммарная стоимость заказов, сделанных клиентами из определенной страны и доставленных определенной компанией?
  • Какова суммарная стоимость заказов, сделанных клиентами из определенной страны в заданном году и доставленных определенной компанией?
Все эти данные можно получить из этой таблицы вполне очевидными SQL-запросами с группировкой.

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

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

Если же нам захочется получить те же данные, но еще в разрезе годов, тогда появится еще одно изменение, т.е. набор данных станет трехмерным (условным тензором 3-го порядка или 3-х мерным «кубом»).

Очевидно, что максимальное количество измерений – это количество всех атрибутов (Дата, Страна, Заказчик и т.д.), описывающих наши агрегируемые данные (сумму заказов, количество товаров и т.п).

Так мы приходим к понятию многомерности и его воплощению – многомерному кубу . Такая таблица будет у нас называться «таблицей фактов ». Измерения или Оси куба (dimensions ) – это атрибуты, координаты которых – выражаются индивидуальными значениями этих атрибутов, присутствующих в таблице фактов. Т.е. например, если информация о заказах велась в системе с 2003 по 2010 год, то эта ось годов будет состоять из 8 соответствующих точек. Если заказы приходят из трех стран, то ось стран будет содержать 3 точки и т.д. Независимо от того, сколько стран заложено в справочнике Стран. Точки на оси называются ее «членами» (Members ).

Сами агрегируемые данные в данном случае буду назваться «мерами» (Measure ). Чтобы избежать путаницы с «измерениями», последние предпочтительней называть «осями». Набор мер образует еще одну ось «Меры» (Measures ). В ней столько членов (точек), сколько мер (агрегируемых столбцов) в таблице фактов.

Члены измерений или осей могут быть объединены одной или несколькими иерархиями (hierarchy ). Что такое иерархия, поясним на примере: города из заказов могут быть объединены в районы, районы в области, области страны, страны в континенты или другие образования. Т.е. налицо иерархическая структура – континент-страна-область-район-город – 5 уровней (Level ). Для района данные агрегируются по всем городам, которые в него входят. Для области по всем районам, которые содержат все города и т.п. Зачем нужно несколько иерархий? Например, по оси с датой заказа мы можем хотеть группировать точки (т.е. дни) по иерархии Год-Месяц-День или по Год-Неделя-День : в обоих случаях по три уровня. Очевидно, что Неделя и Месяц по-разному группируют дни. Бывают также иерархии, количество уровней в которых не детерминировано и зависит от данных. Например, папки на компьютерном диске.

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

MDX

Перейдем к языку запросов в многомерных данных.
Язык SQL изначально был спроектирован не для программистов, а для аналитиков (и поэтому имеет синтаксис, напоминающий естественный язык). Но он со временем все больше усложнялся и теперь мало кто из аналитиков хорошо умеет им пользоваться, если умеет вообще. Он стал инструментом программистов. Язык запросов MDX, разработанный по слухам нашим бывшим соотечественником Мойшей (или Мошей) Посуманским (Mosha Pasumansky) в дебрях корпорации Майкрософт, тоже изначально должен был ориентирован на аналитиков, но его концепции и синтаксис (который отдаленно напоминает SQL, причем совершенно зря, т.к. это только путает), еще сложнее чем SQL. Тем не менее его основы все же понять несложно.

Мы рассмотрим его подробно потому что это единственный язык, который получил статус стандартного в рамках общего стандарта протокола XMLA , а во вторых потому что существует его open-source реализация в виде проекта Mondrian от компании Pentaho . Другие системы OLAP-анализа (например, Oracle OLAP Option) обычно используют свои расширения синтаксиса языка SQL, впрочем, декларируют поддержку и MDX.

Работа с аналитическими массивами данных подразумевает только их чтение и не подразумевает запись. Т.о. в языке MDX нет предложений для изменения данных, а есть только одно предложение выборки - select.

В OLAP из многомерных кубов можно делать срезы – т.е. когда данные фильтруются по одной или нескольким осям, или проекции – когда по одному или нескольким осям куб «схлопывается», агрегируя данные. Например, наш первый пример с суммой заказов из стран – есть проекция куба на ось Страны. MDX запрос для этого случая будет выглядеть следующим образом:

Select ...Children on rows from
Что здесь что?

Select ключевое слово и в синтаксис входит исключительно для красоты.
– это название оси. Все имена собственные в MDX пишутся в квадратных скобках.
– это название иерархии. В нашем случае – это иерархия Страна-Город
– это название члена оси на первом уровне иерархии (т.е. страны) All – это мета-член, объединяющий все члены оси. Такой мета-член есть в каждой оси. Например в оси годов есть «Все года» и т.п.
Children – это функция члена. У каждого члена есть несколько доступных функций. Таких как Parent. Level, Hierarchy, возвращающие соответственно предка, уровень в иерархии и саму иерархию, к которой относится в данном случае член. Children – возвращает набор членов-потомков данного члена. Т.е. в нашем случае – страны.
on rows – Указывает как расположить эти данные в итоговой таблице. В данном случае – в заголовке строк. Возможные значении здесь: on columns, on pages, on paragraphs и т.п. Возможно так же указание просто по индексам, начиная с 0.
from – это указание куба, из которого производится выборка.

Что если нам не нужны все страны, а нужно только пара конкретных? Для этого можно в запросе указать явно те страны которые нам нужны, а не выбирать все функцией Children.

Select { ..., ... } on rows from
Фигурные скобки в данном случае – обявление набора (Set ). Набор – это список, перечисление членов из одной оси .

Теперь напишем запрос для нашего второго примера – вывод в разрезе доставщика:

Select ...Children on rows .Members on columns from
Здесь добавилось:
– ось;
.Members – функция оси, которая возвращает все члены на ней. Такая же функция есть и у иерархии и у уровня. Т.к. в данной оси иерархия одна, то ее указание можно опустить, т.к. уровень и иерархии тоже один, то можно выводить все члены одним списком.

Думаю, уже очевидно, как можно продолжить это на наш третий пример с детализацией по годам. Но давайте лучше не детализировать по годам, а фильтровать – т.е. строить срез. Для этого напишем следующий запрос:

Select ..Children on rows .Members on columns from where (.)
А где же тут фильтрация?

where – ключевое слово
– это один член иерархии . Полное имя с учетом всех терминов было бы таким: .. , но т.к. имя этого члена в рамках оси уникально, то все промежуточные уточнения имени можно опустить.

Почему член даты в скобках? Круглые скобки – это кортеж (tuple ). Кортеж – это один или несколько координат по различным осям. Например для фильтрации сразу по двум осям в круглых скобках мы перечислим два члена из разных измерений через запятую. Т. е. кортеж определяет «срез» куба (или «фильтрацию», если такая терминология ближе).

Кортеж используется не только для фильтрации. Кортежи могут быть и в заголовках строк/колонок/страниц и т.п.

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

Select crossjoin(...Children, ..Children) on rows .Members on columns from where (.)
Crossjoin – это функция. Она возвращает набор (set) кортежей (да, набор может содержать кортежи!), полученный в результате декартового произведения двух наборов. Т.е. результирующий набор будет содержать все возможные сочетания Стран и Годов. Заголовки строк, таким образом, будут содержать пару значений: Страна-Год .

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

Вопрос: чем отличается фильтрация в where от фильтрации путем указания членов осей в on rows. Ответ: практически ничем. Просто в where указывается срез для тех осей, которые не участвуют в формировании заголовков. Т.е. одна и та же ось не может одновременно присутствовать и в on rows , и в where .

Вычисляемые члены

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

With member . as ‘.CurrentMember / ..’, FORMAT_STRING=‘0.00%’ select ...Children on rows from where .
Вычисление происходит в контексте ячейки, у которой известные все ее атрибуты-координаты. Соответствующие координаты (члены) могут быть получены функцией CurrentMember у каждой из осей куба. Здесь надо понимать, что выражение .CurrentMember / .. ’ не делит один член на другой, а делит соответствующие агрегированный данные срезов куба! Т.е. срез по текущей территории разделится на срез по всем территориям, т.е. суммарное значение всех заказов. FORMAT_STRING – задает формат вывода значений, т.е. %.

Другой пример вычисляемого члена, но уже по оси годов:

With member . as ‘. - .’
Очевидно, что в отчете будет не единица, а разность соответствующих срезов, т.е. разность суммы заказов в эти два года.

Отображение в ROLAP

Системы OLAP так или иначе базируются на какой-нибудь системе хранения и организации данных. Когда речь идет о РСУБД, то говорят о ROLAP (MOLAP и HOLAP оставим для самостоятельного изучения). ROLAP – OLAP на реляционной БД, т.е. описанная в виде обычных двумерных таблиц. Системы ROLAP преобразуют MDX запросы в SQL. Основная вычислительная проблема для БД – быстрая агрегация. Чтобы быстрее агрегировать, данные в БД как правило сильно денормализованы, т.е. хранятся не очень эффективно с точки зрения занимаемого места на диске и контроля целостности БД. Плюс дополнительно содержат вспомогательные таблицы, хранящие частично агрегированные данные. Поэтому для OLAP обычно создается отдельная схема БД, которая лишь частично повторяет структуру исходных транзакционных БД в части справочников.

Навигация

Многие системы OLAP предлагают инструментарий интерактивной навигации по уже сформированному запросу (и соответственно выбранным данным). При этом используется так называемое «сверление» или «бурение» (drill). Более адекватным переводом на русский было бы слово «углубление». Но это дело вкуса., в некоторых средах закрепилось слово «дриллинг».

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

  • drill-down – фильтрация по одной из исходных осей отчета с выводом детальной информации по потомкам в рамках иерархии выбранного фильтрующего члена. Например, если имеется отчет по распределению заказов в разрезе Стран и Годов, то при щелчке на 2007-м году выведется отчет в разрезе тех же Стран и месяцев 2007 года.
  • drill-aside – фильтрация под одной или нескольким выбранным осям и снятие агрегации по одной или нескольким другим осям. Например, если имеется отчет по распределению заказов в разрезе Стран и Годов, то при щелчке на 2007-м году выведется другой отчет в разрезе, например, Стран и Поставщиков с фильтрацией по 2007 году.
  • drill-trough – снятие агрегации по всем осям и одновременная фильтрация по ним же – позволяет увидеть исходные данные из таблицы фактов, из которых получено значение в отчете. Т.е. при щелчке по значению ячейки выводится отчет со всеми заказами, которые дали эту сумму. Эдакое мгновенное бурение в самые «недра» куба.
На этом все. Теперь, если вы решили посвятить себя Business Intelligence и OLAP самое время приступать к чтению серьезной литературы.

Теги:

  • OLAP
  • Mondrian
  • Business Intelligence
  • MDX
Добавить метки

Целью курсовой работы является изучение технологии 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-анализа является проверка возникающих гипотез.

Статьи по теме: