5.2.Оперативная аналитическая обработка (OLAP)
Инструменты класса OLAP (On-Line Analytical Processing, традиционный русский перевод – «оперативная аналитическая обработка») на сегодняшний день являются популярными аналитическими средствами, без которых практически невозможно представить информационно-аналитическую систему. Сам термин OLAP был введен в 1993 году Коддом, который рассмотрел недостатки реляционной модели с точки зрения корпоративных аналитиков. Средством, которое должно было исправить эти недостатки, и стала концепция OLAP. Справедливости ради нужно сказать, что подход, аналогичный OLAP (а именно, многомерное представление данных) использовался и до введения этого термина, но толчком к повсеместному распространению технологии и внедрению ее во множество аналитических продуктов, стала статья Кодда.
Среди недостатков реляционной модели и реляционных СУБД применительно к задачам анализа Кодд отметил следующие. Во-первых, аналитические запросы достаточно сложны, и связаны с выполнением большого количества относительно медленных реляционных операций соединения. Во-вторых, составление запросов к реляционным базам данных недоступно корпоративным аналитикам (в дальнейшем будем называть их «лицами, принимающими решение», или ЛПР). Второй недостаток обусловливает достаточно длинный цикл получения нужных сведений ЛПР – необходимо, к примеру, обратиться в информационную службу, где подготовят форму отчета с соответствующей информацией, а затем уже использовать отчеты этой формы. Решение этих проблем Кодд видел в аналитическом инструменте, поддерживающим многомерную модель, как понятную ЛПР. То есть, выделяется несколько измерений, в контексте которых рассматриваются различные показатели деятельности предприятия. Такая модель, в силу своей наглядности и интуитивности, должна позволить ЛПР самому обращаться к необходимой информации. С другой стороны, ответы на запросы должны генерироваться достаточно быстро (это требование и обусловливает часть «On-Line» акронима OLAP).
Кодд также сформулировал 12 правил, которым должна удовлетворять OLAP-система. Позднее, эти правила были переработаны в 18 свойств, разбитых на 4 группы. Данный набор правил не пользуется успехом. Возможно, в силу того, что в отличие от широко известного манифеста Кодда 1970 года, описывающего реляционную модель данных, статья 1993 года содержала гораздо меньше фундаментальных обоснований, и была менее выверена теоретически. Кроме того, она публиковалась под эгидой одного солидного поставщика аналитических систем и правила, сформулированные в ней, могут не быть универсальными, а учитывать специфику продуктов этого поставщика. Так или иначе, большей популярностью пользуется так называемый тест FASMI, который и можно принять за определение OLAP. FASMI является аббревиатурой, которая расшифровывается следующим образом:
Fast (быстрый) – время отклика системы должно измеряться секундами. Как показывают независимые исследования, время ожидания пользователем ответа от компьютера около 20 секунд. По истечении этого периода, у пользователя появляется чувство дискомфорта. Бесспорно, добиться выполнения любых запросов к большим массивам информации за секунды является сложной задачей для производителей OLAP инструментов. Собственно, это одно из основных направлений развития в этой области. Однако, как показывают некоторые опросы, неудовлетворительная скорость работы до сих пор является одной из главных претензий пользователей к инструментам этого класса.
Analisys (анализ) – система предназначена для всестороннего исследования данных, причем это исследование может содержать элементы бизнес-логики, поддерживать зависимости, определяемые пользователем и так далее.
Shared (разделяемый, многопользовательский) – система должна поддерживать многопользовательскую работу, обеспечивая при этом необходимый уровень конфиденциальности. Если допускается исправление данных пользователем, то оно должно управляться известными механизмами блокировок на нужном уровне.
Multidimensional (многомерный) – данные должны быть представлены в многомерной форме. Это главная часть определения OLAP.
Information (информация) – эта составляющая намекает на то, что результатом анализа становится информация (в противовес данным, хранящимся в реляционной базе).
Тест FASMI, как и правила Кодда, устанавливает некоторый эталон - «идеальный инструмент OLAP». В действительности, различные продукты можно сравнивать по тому, насколько удовлетворяют этим положениям. Продуктов, которые бы полностью им удовлетворяли, на данный момент не существует.
5.2.1.Связь OLAP и ХД
Хранилища данных отражают современную тенденцию к сбору и очистке данных транзакционных систем и сохранение их для задач анализа. Появление технологии ХД отчасти обусловлено теми же предпосылками, что и OLAP – разницей в аналитических запросах и типичных запросах к учетным системам. Кроме того, весьма актуальным оказалось желание сбора данных из всех источников на предприятии для создания более целостной информационной картины.
Разновидностью хранилищ данных являются витрины данных (или киоски данных). Их отличие от хранилищ данных заключается, в основном, в размерах. Если в ХД стекаются данные предприятия, то витрина представляет данные, относящиеся только к одному подразделению, службе или филиалу. Витрина может создаваться как независимо, так и представлять собой подмножество корпоративного хранилища данных.
Собранные из разных источников, согласованные, а иногда и обобщенные данные идеальны для анализа. Поэтому в большинстве случаев инструменты OLAP разворачиваются именно на базе хранилища или витрины данных, и предназначены для анализа содержащихся там данных. Это настолько общая тенденция, что в некоторых источниках понятия Хранилища данных (витрины данных) и OLAP не различаются. Однако из методологической потребности различие делать все-таки нужно. Технология ХД в большей степени ориентирована на сбор, очистку, и хранение данных, а OLAP – на их обработку и представление.
5.2.2.Структура информационно-аналитической системы и место OLAP в ней
Один из вариантов расположения технологии в структуре корпоративной системы показан на рисунке (Рис. 79). Данные разнородных источников собираются, очищаются, согласуются и помещаются в корпоративное хранилище данных. На основе данных, содержащихся в хранилище, разворачивается ряд витрин данных, представляющих собой тематически-сгруппированные подмножества данных хранилища. Например, могут существовать витрины данных для отдела маркетинга и отдела продаж. Содержимое витрин данных подвергается различным методам анализа, одним из видов которого и является OLAP. На приведенном рисунке аналитическая функциональность разделена на три сферы, однако, зачастую продукты объединяют функциональность различных сфер, и помимо обеспечения доступа и визуализации многомерных данных, могут, например, производить интеллектуальный постпроцессинг. А многие генераторы запросов «вбирают» в себя и возможность работы с многомерными данными.
Рис. 79. Полная структура корпоративной информационно-аналитической системы (ИАС)
5.2.3.Многомерная модель данных
Многомерную модель данных будем рассматривать на двух уровнях: концептуальном и логическом. Концептуальный уровень определяет общее представление об измерениях и значениях, а также основные операции с многомерной структурой. Аналогией является концептуальный уровень реляционной модели, объектами которого являются классы объектов реального мира и связи между ними. На логическом уровне будем рассматривать модель взаимодействия пользователя с конкретной реализацией концептуальной модели (с конкретным инструментом OLAP), по аналогии с логическим уровнем реляционной модели, которым является, например, SQL.
5.2.3.1.Концептуальная многомерная модель
В рамках многомерной модели все информационное пространство задачи разбивается на атрибуты двух типов: измерения и факты. Измерениями, как правило, становятся компоненты информационного пространства (атрибуты), не зависящие от анализируемых процессов, а характеристики анализируемых процессов становятся фактами. При этом, каждый факт имеет значение лишь в контексте конкретных значений набора измерений. Графически подобную модель легко представить в виде системы координат (или гиперкуба), где измерения являются гранями, а факты – точками в системе координат (или внутри куба). Понятно, что графически можно изобразить только куб с количеством измерений не больше трех, поэтому одной из наиболее популярных операций при работе с гиперкубом является его проекция на одно, два или три измерения. Пример куба, приведен на рисунке (Рис. 80).
Рис. 80. Куб данных
В дальнейшем, вне зависимости от реального количества измерений будем пользоваться термином гиперкуб.
В самом простом случае, измерения являются однородными, то есть состоят из равноправных значений. Например, значениями могут быть районы города, числа, филиалы и так далее. Но, в общем случае, и об этом писал в своей статье Кодд, измерения могут быть иерархическими, отражая иерархическую структуру организаций и характеристик процессов. Так, измерение может состоять из названий городов, и областей, к которым эти города относятся. Классическое измерение времени является иерархическим и содержит даты с группировкой по неделям, месяцам, кварталам и годам. Соответственно, пользователь при работе с гиперкубом может выбирать уровень детализации измерений и переходить от общих данных к детальным и обратно. Иерархия измерения может быть ровной или неровной. Ровная иерархия допускает только один вариант обобщения, тогда как неровная допускает несколько вариантов. Типичным примером неровной иерархии является иерархия временных единиц, в которой дни могут группироваться в недели, декады и месяцы, причем, в общем случае, никакой набор значений одной из этих единиц не объединяется в другую.
В качестве фактов для внутренних элементов иерархии измерения используются значения, полученные с помощью процедуры агрегирования из значений иерархии измерения более низкого порядка. Наиболее простым вариантом процедуры агрегирования (и наиболее часто встречающимся) может быть суммирование.
С гиперкубом можно выполнять следующие операции:
- выборка. Выбирается некоторое подмножество значений по одному или нескольким измерениям, и отобранные значения формируют новый куб;
- обобщение/детализация. Переход к более высокому (или более низкому) уровню иерархии измерения по одному или более измерениям.
- проекция. Фиксируются значения нескольких измерений (в том числе, на значении «Любой»), и результатом является получившийся гиперкуб.
- вращение. При отображении гиперкуба в виде сводной таблицы меняются местами оси.
5.2.3.2.Логическая многомерная модель
К сожалению, на логическом уровне многомерной модели не сложилось такого общепринятого стандарта, как в реляционной модели, поэтому разные инструменты предлагают немного различные логические модели. Различия эти заключаются как в используемой терминологии, так и в самой логической модели – основных частях базы данных, их атрибутах, связях между ними, и методах использования. Тем не менее, несмотря на различия, все продукты реализуют единую концептуальную модель, основы которой были изложены выше.
5.2.3.3.Агрегация данных
На самом низком уровне многомерной модели данных находится ее физический уровень, определяющий способ физического хранения и обработки объектов логического уровня. Для повышения скорости реакции системы и увеличения мощности системы разработчикам инструментов OLAP приходится решать самые разнообразные проблемы, одной из которых является определение необходимого уровня агрегации данных в OLAP-кубе. Мощные OLAP-сервера (например, Microsoft OLAP Service) предлагают и возможность настройки этого параметра вручную администратором базы данных, тем важнее понимание роли этого параметра и умение находить его оптимальное значение.
Основная идея заключается в том, что OLAP-система предварительно рассчитывает значения некоторых агрегированных ячеек (значения, соответствующие не листовым вершинам в иерархии измерений), и сохраняет их в кубе для того, чтобы при обращении к этим значениям сэкономить на вычислительных операциях и тем самым повысить общую скорость работы. Однако это агрегирование ведет к увеличению куба, занимаемого им дискового пространства и, косвенно, времени работы с ним за счет интенсификации дисковых операций (если куб хранится на диске).
В большинстве систем администратор при настройке куба имеет возможность установить процент агрегируемых значений по каждому измерению: 0%, если агрегируемые значения вообще не должны сохраняться, а должны каждый раз рассчитываться при необходимости, и 100%, если сервер должен предварительно рассчитать все агрегированные значения для всех вершин иерархии измерения.
5.2.4.Архитектуры OLAP
При анализе архитектур OLAP следует принять во внимание два основных технологических решения: размещение данных и способ обработки многомерных данных (выполнения многомерных запросов). Данные могут размещаться в реляционной СУБД, в многомерной СУБД, или локально в файлах. Запросы могут выполняться с помощью SQL, серверным многомерным процессором, или клиентским многомерным процессором. Всего существует 9 комбинаций решений, из которых смысл имеют только 6, вынесенных в таблицу (Таблица 10). В эту таблицу также вписаны названия продуктов, использующих соответствующую архитектуру.
Таблица 10. Варианты архитектур OLAP
|
Хранение многомерных данных
|
Обработка многомерных данных
|
Реляционная СУБД
|
Многомерная СУБД
|
Файл
|
SQL
|
1
- Cartesis Magnitude
- MicroStrategy
|
|
|
Многомерный серверный процессор
|
2
- Crystal Holos (ROLAP mode)
- IBM DB2 OLAP Server
- CA EUREKA:Strategy
- Longview Khalix
- Informix MetaCube
- Speedware Media/MR
- Microsoft Analysis Services
- Oracle Express (ROLAP mode)
- Pilot Analysis Server
- Sagent
- Applix iTM1
- WhiteLight
|
4
- SAS CFO Vision
- Crystal Holos
- Comshare Decision
- Hyperion Essbase
- Oracle Express
- Gentia
- Speedware Media/M
- Microsoft Analysis Services
- PowerPlay Enterprise Server
- Pilot Analysis Server
- Applix iTM1
|
|
Многомерный клиентский процессор
|
3
- Oracle Discoverer
- Informix MetaCube
|
5
- Comshare FDC
- Dimensional Insight
- Hyperion Enterprise
- Hyperion Pillar
- PwC CLIME
|
6
- Brio.Enterprise
- BusinessObjects
- Cognos PowerPlay
- Personal Express
- iTM1 Perspectives
|
Другой часто используемой классификацией архитектур OLAP является их подразделение на: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP), HOLAP (Hybrid OLAP), и DOLAP (Desktop OLAP). Эта классификация соотносится с описанной выше следующим образом:
ROLAP – квадраты 1, 2, 3 .
MOLAP – квадраты 4, 5 .
Desktop OLAP – квадрат 6 .
Hybrid OLAP – продукты, названия которых в таблице выделены курсивом.
Очевидно, что различные архитектуры имеют свои наборы достоинств и недостатков, различные области применения и различные стоимости.
5.2.4.1.О преимуществах и недостатках различных архитектур
Реляционное хранилище
Сохранение данных куба в реляционной базе данных является довольно очевидным вариантом, если OLAP разворачивается на основе существующего реляционного хранилища, витрины данных, или даже учетной системы.
Как правило, в этом случае в качестве реляционной схемы данных в этом случае используется «звезда» или «снежинка». Схема данных «звезда» означает, что есть одна таблица фактов и связанные с ней таблицы измерений. Схема «снежинка» является более сложной – здесь таблиц фактов может быть несколько. Пример схемы данных «звезда» приведен на рисунке (Рис. 81).
Рис. 81. Схема данных "Звезда"
OLAP-системы, основанные на реляционных хранилищах, отличаются немного худшим быстродействием, но они более эффективно используют дисковое пространство.
Многомерная БД
Решение, предполагающее сохранение OLAP-куба в многомерной базе данных, как правило, позволяет добиться большей производительности, но если сохранять куб в естественном виде, то размер получаемого файла будет чрезвычайно велик. Более того, данные будут очень разреженными, так как для большинства сочетаний измерений фактов не будет. Методы решения этой проблемы разрабатываются в теории многомерных баз данных.
Относительно МБД следует сделать еще одно замечание. Часто значение термина OLAP ограничивают использованием многомерных баз данных, интерпретируя многомерность, содержащуюся в определении OLAP, как многомерность хранения. Это неверно, ибо многомерность OLAP носит презентационный уровень – данные должны представляться в многомерной форме, и многомерное хранение это всего лишь один из путей реализации OLAP.
Смешанный вариант
Компромиссным вариантом организации хранения данных является хранение исходных данных в реляционных таблицах, а агрегированных значений в МБД. Это позволяет, с одной стороны, уменьшить размер многомерной БД за счет исключения из нее одиночных фактов, а с другой стороны, добиться высокой производительности, свойственной МБД, особенно при работе преимущественно с агрегированными значениями. Такое решение свойственно инструментам категории HOLAP.
5.2.5.Использование технологии OLAP
Существует несколько категорий продуктов, обеспечивающих ту или иную часть функциональности OLAP. В первую очередь, их можно разбить на OLAP-серверы и OLAP-клиенты. OLAP-серверы обеспечивают создание и наполнение кубов, а также выполнение многомерных запросов и передачу многомерных данных клиенту, реализуя при этом какой-то из интерфейсов обмена, который может быть стандартным, либо принятым у одного разработчика OLAP-решений. OLAP-клиенты предоставляют возможность работы с многомерными данными, их визуализации и пользовательской обработки. Они подразделяются на группы в зависимости от функциональной нагруженности. Самым простым OLAP-клиентом является такой, который не может работать без OLAP-сервера. Такой клиент образует интерактивную оболочку для доступа к данным OLAP-сервера (примером является Analysis Manager из набора MS SQL Server 2000 Analysis Services). Более сложные клиенты могут как работать с OLAP-серверами, так и создавать клиентские кубы из реляционных баз и сохранять их для локальной работы. Наиболее популярным из OLAP-клиентов этого вида является Microsoft Excel (другим примером может быть Cube Analyser из пакета Deductor).
6.Литература
К. Дейт. Введение в системы баз данных. 7-е изд. М.: СПб.: Вильямс, 2000.
Д. Мейер Теория реляционных баз данных. М.: Мир, 1987
Маклаков С.В. BPwin и Erwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 1999.
Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. М.: Финансы и статистика, 1998
Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М.: Финансы и статистика, 2000
Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. М.: Мир, 1999
Буч Г., Рамбо Д., Джекобсон А. Язык UML: руководство пользователя. М.: ДМК, 2000
М.Р. Когаловский. Энциклопедия технологий баз данных. М.: Финансы и статистика, 2002
Гектор Гарсиа-Молина, Джеффри Ульман, Дженифер Уидом. Системы баз данных. Полный курс. М., С.-Петербург, Киев: Вильямс, 2003.
Мартин Грабер. SQL. Справочное руководство
Использование ODBC для доступа к данным. М. "БИНОМ"
Кузнецов С.Д. Введение в модель данных SQL - Интернет-университет информационных технологий - ИНТУИТ.ру, 2005. http://www.intuit.ru/department/database/sqlmdintro/
Кузнецов С.Д. Введение в реляционные базы данных.Интернет-университет информационных технологий - ИНТУИТ.ру, 2005. http://www.intuit.ru/department/database/rdbintro/
Баженова И. Ю. Основы проектирования приложений баз данных Интернет-университет информационных технологий - ИНТУИТ.ру, 2006. http://www.intuit.ru/department/database/cdba2/
С. Д. Кузнецов. Проектирование и разработка корпоративных информационных систем. Центр Информационных Технологий, 1998. http://citforum.ru/cfin/prcorpsys/
E.F. Codd, S. B. Codd, and C.T. Salley, "Providing OLAP (Online Analytical Processing) to User-Analysts: An IT Mandate," 1993
Конноли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. – М.: Издательский дом «Вильямс», 2003. – 1440 с.
Щавелёв Л.В. Оперативная аналитическая обработка: концепции и технологии. - http://www.olap.ru/basic/olap_and_ida.htm
Хрусталёв Е.М. Агрегация данных в OLAP-кубах. – http://www.olap.ru/Home/mut.htm
Эйриэнн Х. Слотер Архитектуры OLAP. - http://www.olap.ru/Basic/olap_arch.htm
Альперович М. Введение в OLAP и многомерные базы данных. - http://www.olap.ru/Basic/alpero2i.htm
What is OLAP? - http://www.olapreport.com/fasmi.htm
OLAP Architectures - http://www.olapreport.com/Architectures.htm
Multidimensional Data Structures - http://www.olapreport.com/MDStructures.htm
|
