Цель доклада

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

Цель доклада: раскрыть и осветить 2 вопроса: 1) понятие OLAP и их прикладное значение в финансовом управлении; 2) реализация OLAP-функциональности в программных решениях: различия, возможности, преимущества, недостатки.

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

Управление финансами

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

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

Пожалуй, трудно определить уровень «максимальной эффективности использования ресурсов», но в любом случае,

Финансовый директор всегда должен знать:

• сколько финансовых ресурсов имеется?
• откуда будут поступать средства и в каких объемах?
• куда вкладывать более эффективно и почему?
• и в какие моменты времени все это необходимо совершать?
• сколько нужно для обеспечения нормальной деятельности предприятия?

Чтобы получать обоснованные ответы на эти вопросы необходимо иметь, анализировать и знать как анализировать достаточно большое количество показателей деятельности. Кроме того, ФУ охватывает огромное количество областей: анализ денежных потоков (движения денежных средств), анализ активов и пассивов, анализ прибыльности, маржинальный анализ, анализ рентабельности, ассортиментный анализ.

Знания

Поэтому ключевым фактором эффективности процесса управления финансами является наличие знаний:

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

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

Что есть сейчас

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

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

Что надо делать

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

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

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

Базовые понятия OLAP-технологий

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

Традиционная система поддержки принятия решений

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

Но такой способ поддержки принятия решений лишен гибкости и имеет много недостатков:

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

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

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

Понимание OLAP

Что дает OLAP?

• Развитые инструменты доступа к данным хранилища
• Динамическое интерактивное манипулирование данными (вращения, консолидации или детализации)
• Наглядное визуальное отображение данных
• Быстрота – анализ осуществляется в реальном режиме времени
• Многомерное представление данных - одновременный анализ ряда показателей по нескольким измерениям

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

Базовые понятия, которыми оперируют OLAP-технологии, следующие:

Многомерность

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

Эти данные представлены в двух измерениях:

• статья
• бизнес-единица

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

На рисунке видно 3-е измерение, Время, в дополнение к первым двум. (Статья, бизнес-единица)

Другой способ показать многомерные данные – это представить их в форме куба:

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

• Какие затраты в каких бизнес-единицах критичны?
• Как изменяются затраты бизнес-единиц во времени?
• Как изменяются статьи затрат во времени?

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

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

Обычно OLAP-приложения позволяют получать данные по 3 и более измерениям, например, можно добавить еще одно измерение – План-Факт, Категория затрат: прямые, косвенные, по Заказам, по Месяцам. Дополнительные измерения позволяют получать больше аналитических срезов и обеспечивают ответы на вопросы с несколькими условиями.

Иерархичность

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

Например, затраты целесообразно сгруппировать иерархично:

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

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

Изменение направлений анализа в кубе (вращение данных)

Как правило, оперируют понятиями: измерения, заданные в столбцах, строках (их может быть несколько), остальные формируют срезы, содержание таблицы формируют размерности (продажи, затраты, денежные средства)

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

Отображение данных куба зависит от:

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

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

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

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

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

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

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

Несмотря на большие возможности OLAP (кроме того, идея сравнительно давняя – 60-е года) реально применение его практически не встречается на наших предприятиях. Почему?

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

Наш подход и западный к применению OLAP

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

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

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

Прикладное использование OLAP

• Бюджет
• Движение денежных средств

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

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

• Финансовая и управленческая отчетность (с аналитикой, которая необходима руководству)
• Маркетинг
• Balanced Scorecard
• Анализ прибыльности

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

OLAP -продукты

В данном разделе будет идти речь об OLAP как о программном решении.

Общие требования к OLAP-продуктам

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

Есть характеристики, которые должны соблюдаться во всех OLAP-продуктах (если это OLAP-продукт), в которых и заключается идеал технологии. Это 5 ключевых определений, которые характеризуют OLAP (так называемый, тест FASMI): Быстрый Анализ Разделяемой Многомерной Информации .

• Быстрый (FAST) - означает, что система должна обеспечивать выдачу большинства ответов пользователям в пределах приблизительно пяти секунд. Даже если система предупредит, что процесс будет длиться существенно дольше, пользователи, могут отвлечься и потерять мысль, при этом качество анализа страдает. Такую скорость не просто достигнуть с большими количествами данных, особенно, если требуются специальные вычисления «на лету». Поставщики прибегают к широкому разнообразию методов, чтобы достигнуть этой цели, включая специализированные формы хранения данных, обширные предварительные вычисления, или же ужесточая аппаратные требования. Однако полностью оптимизированных решений на сегодняшний день нет. На первый взгляд может казаться удивительным, что при получении отчета за минуту, на который не так давно требовались дни, пользователь очень быстро начинает скучать во время ожиданий, и проект оказывается намного менее успешным, чем в случае мгновенного ответа, даже ценой менее детального анализа.
• Разделяемой означает, что система дает возможность выполнять все требования защиты данных и реализовывать распределенный и одновременный доступ к данным для различных уровней пользователей. Система должна быть способна обработать множественные изменения данных своевременным, безопасным способом. Это - главная слабость многих OLAP продуктов, которые имеют тенденцию предполагать, что во всех приложениях OLAP требуется только чтение, и предоставляют упрощенные средства защиты.
• Многомерной - ключевое требование. Если бы необходимо было определить OLAP одним словом, то выбрали бы его. Система должна обеспечить многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий, поскольку это определяет наиболее логичный способ анализировать бизнес. Минимальное число измерений, которые должны быть обработаны, не устанавливается, поскольку это также зависит от приложения, и большинство продуктов OLAP, имеет достаточное количество измерений для тех рынков, на которые они нацелены. И опять же, мы не определяем, какая основная технология базы данных должна использоваться, если пользователь получает действительно многомерное концептуальное представление информации. Эта особенность - сердцевина OLAP
• Информации. Необходимая информация должна быть получена там, где она необходима, независимо от ее объема и места хранения. Однако многое зависит от приложения. Мощность различных продуктов измеряется в терминах того, сколько входных данных они могут обрабатывать, но не сколько гигабайт они могут хранить. Мощность продуктов весьма различна - самые большие OLAP продукты могут оперировать, по крайней мере, в тысячу раз большим количеством данных по сравнению с самыми маленькими. По этому поводу следует учитывать много факторов, включая дублирование данных, требуемую оперативную память, использование дискового пространства, эксплуатационные показатели, интеграцию с информационными хранилищами и т. п.
• Анализ означает, что система может справляться с любым логическим и статистическим анализом, характерным для данного приложения, и обеспечивает его сохранение в виде, доступном для конечного пользователя. Пользователь должен иметь возможность задавать новые специальные вычисления как часть анализа без необходимости программирования. То есть все требуемые функциональные возможности анализа должны обеспечиваться интуитивным способом для конечных пользователей. Средства анализа могли бы включать определенные процедуры, типа анализа временных рядов, распределения затрат, валютных переводов, поиска целей и др. Такие возможности широко отличаются среди продуктов, в зависимости от целевой ориентации.

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

Технологические аспекты OLAP

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

Компоненты OLAP-систем (из чего состоит OLAP-система?)

Как правило, OLAP-система включает в себя следующие компоненты:

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

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

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

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

Следует отметить, что термин «OLAP» неразрывно связан с термином «хранилище данных» (Data Warehouse). Хранилище данных - это предметно-ориентированное, привязанное ко времени и неизменяемое собрание данных для поддержки процесса принятия управляющих решений. Данные в хранилище попадают из оперативных систем (OLTP-систем), которые предназначены для автоматизации бизнес-процессов, хранилище может пополняться за счет внешних источников, например статистических отчетов.

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

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

Задача хранилища - предоставить «сырье» для анализа в одном месте и в простой, понятной структуре. То есть концепция Хранилищ Данных - это не концепция анализа данных, скорее это концепция подготовки данных для анализа. Она предполагает реализацию единого интегрированного источника данных.

OLAP-продукты: архитектуры

При использовании OLAP-продуктов важны 2 вопроса: как и где хранить и обрабатывать данные. В зависимости от того, как реализуются 2 этих процесса различают архитектуры OLAP. Существует 3 способа хранения данных для OLAP и 3 способа обработки этих данных. Многие производители предлагают несколько вариантов, некоторые пытаются доказать, что их подход – единственный самый благоразумный. Это, конечно, абсурд. Однако совсем немного продуктов могут оперировать в более, чем в одном режиме качественно.

Варианты хранения OLAP-данных

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

• Реляционные базы данных: это типичный выбор, если на предприятии учетные данных хранятся в РБД. В большинстве случаев, данные следует хранить в денормализованной структуре (самая приемлемая схема «звезда»). Нормализованная база данных не приемлема по причине очень низкой производительности выполнения запросов при формировании агрегированных величин для OLAP (часто итоговые данные хранятся в агрегированных таблицах).
• Файлы баз данных на клиентском компьютере (киоски или витрины данных): эти данные могут заранее распространяться или создаваться по запросам на клиентских компьютерах.

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

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

Варианты обработки OLAP-данных

Существует 3 тех же самых варианта обработки данных:

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

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

Матрица OLAP-архитектур

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

Варианты хранения многомерных данных Варианты многомерной обработки данных	Реляционная база данных	Серверная многомерная база данных	Клиентский компьютер
	Cartesis Magnitude
Многомерная серверная обработка	Crystal Holos (ROLAP mode) IBM DB2 OLAP Server CA EUREKA:Strategy Informix MetaCube Speedware Media/MR Microsoft Analysis Services Oracle Express (ROLAP mode) Pilot Analysis Server Applix iTM1	Crystal Holos Comshare Decision Hyperion Essbase Oracle Express Speedware Media/M Microsoft Analysis Services PowerPlay Enterprise Server Pilot Analysis Server Applix iTM1
Многомерная обработка на клиентском компьютере	Oracle Discoverer Informix MetaCube	Dimensional Insight Hyperion Enterprise	Cognos PowerPlay Personal Express iTM1 Perspectives

Так как именно хранение определяет обработку, то принято группировать по вариантам хранения, то есть:

• ROLAP-продукты в секторах 1, 2, 3
• Настольный OLAP – в секторе 6

MOLAP-продукты – в секторах 4 и 5

HOLAP-продукты (позволяющие как многомерный, так и реляционный вариант хранения данных) – во 2 и 4 (выделены курсивом)

Категории OLAP-продуктов

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

	Особенности	Преимущества	Недостатки	Представители
Прикладной OLAP	Законченные приложения, с богатой функциональностью. Практически все требуют многомерной базы данных, хотя некоторые работают и с реляционной. Многие из этой категории приложений специализированы, например, продажи, производство, банковское дело, бюджетирование, финансовая консолидация, анализ продаж	Возможность интеграции с различными приложениями Высокий уровень функциональности Высокий уровень гибкости и масштабируемости	Сложность приложения (необходимость обучения пользователя) Высокая стоимость	Hyperion Solutions Crystal Decisions Information Builders
	В основе продукта лежит нереляционная структура данных, обеспечивающая многомерное хранение, обработку и представление данных. Данные в процессе анализа выбираются исключительно из многомерной структуры. Несмотря на высокий уровень открытости, поставщики склоняют покупателей приобретать их же инструментарий	Высокая производительность (быстрые вычисления суммарных показателей и различные многомерные преобразования по любому из измерений). Среднее время ответа на нерегламентированный аналитический запрос при использовании многомерной БД обычно на 1-2 порядка меньше, чем в случае РБД Высокий уровень открытости: большое количество продуктов, с которыми возможна интеграция Легко справляются с задачами включения в информационную модель разнообразных встроенных функций, проведения пользователем специализированного анализа и т. п.	Необходимость большого дискового пространства для хранения данных (из-за избыточности данных, которые хранятся). Это крайне неэффективное использование памяти - за счет денормализации и предварительно выполненной агрегации объем данных в многомерной базе соответствует в 2.5-100 раз меньшему объему исходных детализированных данных. В любом случае, MOLAP не позволяют работать с большими базами данных. Реальный предел - база объемом в 10-25 гигабайт Потенциальная возможность «взрыва» базы данных – неожиданное, резкое, непропорциональное возрастание ее объемов Отсутствие гибкости при необходимости модификации структур данных. Любое изменение в структуре измерений почти всегда требует полной перестройки гиперкуба Для многомерных БД, в настоящее время отсутствуют единые стандарты на интерфейс, языки описания и манипулирования данными	Hyperion (Essbase)
DOLAP (Desktop OLAP)	Клиентские OLAP-продукты, которые достаточно легко внедрить и которые требуют низких затрат в расчете на одно место Речь идет о такой аналитической обработке, где гиперкубы малы, размерность их небольшая, потребности скромны, и для такой аналитической обработки достаточно персональной машины на рабочем столе Цель производителей этого рынка – автоматизация сотен и тысяч рабочих мест, но пользователи должны производить достаточно простой анализ. Покупателей зачастую ориентируют покупать больше рабочих мест, чем это необходимо	Хорошая интеграция с базами данных: многомерными, реляционными Возможность совершения комплексных покупок, что снижает стоимость проектов внедрения Простота использования приложений	Весьма ограниченная функциональность (не сравнимы в этом плане со специализированными продуктами) Весьма ограниченная мощность (малые объемы данных, небольшое количество измерений)	Cognos (PowerPlay) Business Objects Crystal Decisions
	Это самый маленький сектор рынка. Детальные данные остаются там, где они были изначально - в реляционной БД; некоторые агрегаты хранятся в той же БД в специально созданных служебных таблицах	Способны работать с очень большими объемами данных (экономичное хранение) Предусматривают многопользовательский режим работы, в том числе и в режиме редактирования, а не только чтения Более высокий уровень защиты данных и хорошие возможности разграничения прав доступа Возможно частое внесение изменений в структуру измерений (не требуют физической реорганизации БД)	Низкая производительность, значительно проигрывают по скорости отклика многомерным (отклик на сложные запросы измеряется в минутах или даже часах, чем в секундах). Это более удобные построители отчетов, чем интерактивные аналитические инструменты Сложность продуктов. Требуют значительных затрат на обслуживание специалистами по информационным технологиям. Для обеспечения производительности, сравнимой с MOLAP, реляционные системы требуют тщательной проработки схемы базы данных и настройки индексов, то есть больших усилий со стороны администраторов БД Дорогостоящие для внедрения Ограничения SQL остаются реальностью, что не позволяет реализовать в РСУБД многие встроенные функции, легко обеспечиваемых в системах основанных на многомерном представлении данных	Information Advantage Informix (MetaCube)

Следует отметить, что потребители гибридных продуктов, которые позволяют выбирать режим ROLAPи MOLAP, таких как Microsoft Analysis Services, OracleExpress, Crystal Holos, IBM DB2 OLAPServer, почти всегда выбирают режим MOLAP.

Каждая из представленных категорий имеет свои сильные и слабые стороны, нет единственно оптимального выбора. Выбор влияет на 3 важных аспекта: 1) производительность; 2) дисковое пространство для хранения данных; 3) возможности, функциональность и особенно на масштабируемость OLAP-решения. При этом необходимо учитывать объемы обрабатываемых данных, мощность техники, потребности пользователей и искать компромисс между быстродействием и избыточностью дискового пространства, занятого базой данных, простой и многофункциональностью.

Классификация Хранилищ Данных в соответствии с объёмом целевой БД

Недостатки OLAP

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

Выбор OLAP-продукта

Правильно выбрать OLAP-продукт сложно, но очень важно, если вы хотите, чтобы проект не провалился.

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

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

В процессе выбора необходимо рассмотреть 2 вопроса:

• оценить потребности и возможности предприятия
• оценить существующее на рынке предложение, важны также и тенденции развития

Затем все это сопоставить и, собственно говоря, произвести выбор.

Оценка потребностей

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

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

Некоторые факторы уже стали очевидными после ознакомления с обзором категорий OLAP-продуктов, а именно:

Технические аспекты

• Источники данных: корпоративное хранилище данных, OLTP-система, табличные файлы, реляционные базы данных. Возможность увязки OLAP-инструментария со всеми СУБД, используемыми в организации. Как показывает практика, интеграция разнородных продуктов в устойчиво работающую систему - один из наиболее важных вопросов, и его решение в ряде случаев может быть связано с большими проблемами. Необходимо разобраться, насколько просто и надёжно можно интегрировать средства OLAP с существующими в организации СУБД. Важно также оценить возможности интеграции не только с источниками данных, но и с другими приложениями, в которые, возможно, понадобится экспортировать данные: электронная почта, офисные приложения
• Изменчивость данных, которые учитываются
• Платформа сервера: NT, Unix, AS/400, Linux - но не следует настаивать, чтобы заданные спецификацией OLAP продукты выполнялись на сомнительных или умирающих платформах, которые Вы все еще используете
• Стандарты клиентской части и браузера
• Разворачиваемая архитектура: локальная сеть и модемная связь PC, высокоскоростной клиент/сервер, intranet, extranet, Internet
• Международные особенности: многовалютная поддержка, многоязычные операции, коллективное использование данных, локализация, лицензирование, обновление Windows

Объемы входной информации, которые имеются и которые появятся в будущем

Пользователи

• Сферу приложения: анализ продаж/маркетинга, составление бюджета/планирование, анализ показателей деятельности, анализ бухгалтерских отчетов, качественный анализ, финансовое состояние, формирование аналитических материалов (отчетов)
• Число пользователей и их размещение, требования к разделению прав доступа к данным и функциям, секретность (конфиденциальность) информации
• Вид пользователя: высшее руководство, финансы, маркетинг, HR, продажи, производство и т.д
• Опыт пользователя. Уровень квалификации пользователя. Рассмотреть вопрос о проведении обучения. Очень важно, чтобы клиентское OLAP-приложение было таким, чтобы пользователи чувствовали себя уверенно и могли эффективно его использовать.

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

Внедрение

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

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

Эффект от правильной организации, стратегического и оперативного планирования развития бизнеса трудно заранее оценить в цифрах, но очевидно, что он в десятки и даже сотни раз может превзойти затраты на реализацию таких систем. Однако не следует и заблуждаться. Эффект обеспечивает не сама система, а люди с ней работающие. Поэтому не совсем корректны декларации типа: «система Хранилищ Данных и OLAP-технологий будет помогать менеджеру принимать правильные решения». Современные аналитические системы не являются системами искусственного интеллекта и они не могут ни помочь, ни помешать в принятии решения. Их цель своевременно обеспечить менеджера всей информацией необходимой для принятия решения в удобном виде. А какая информация будет запрошена и какое решение будет принято на её основе, зависит только от конкретного человека ее использующего.

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

Условия высокой конкуренции и растущей динамики внешней среды диктуют повышенные требования к системам управления предприятия. Развитие теории и практики управления сопровождались появлением новых методов, технологий и моделей, ориентированных на повышение эффективности деятельности. Методы и модели в свою очередь способствовали появлению аналитических систем. Востребованность аналитических систем в России – высокая. Наиболее интересны с точки зрения применения эти системы в финансовой сфере: банки, страховой бизнес, инвестиционные компании. Результаты работы аналитических систем необходимы в первую очередь людям, от решения которых зависит развитие компании: руководителям, экспертам, аналитикам. Аналитические системы позволяют решать задачи консолидации, отчетности, оптимизации и прогнозирования. До настоящего времени не сложилось окончательной классификации аналитических систем, как и нет общей системы определений в терминах, использующихся в данном направлении. Информационная структура предприятия может быть представлена последовательностью уровней, каждый из которых характеризуется своим способом обработки и управления информацией, и имеет свою функцию в процессе управления. Таким образом аналитические системы будут располагаться иерархически на разных уровнях этой инфраструктуры.

Уровень транзакционных систем

Уровень хранилищ данных

Уровень витрин данных

Уровень OLAP – систем

Уровень аналитических приложений

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

Очень часто информационно-аналитические системы, создаваемые в расчете на непосредственное использование лицами, принимающими решения, оказываются чрезвычайно просты в применении, но жестко ограничены в функциональности. Такие статические системы называются в литературе Информационными системами руководителя (ИСР), или Executive Information Systems (EIS) . Они содержат в себе предопределенные множества запросов и, будучи достаточными для повседневного обзора, неспособны ответить на все вопросы к имеющимся данным, которые могут возникнуть при принятии решений. Результатом работы такой системы, как правило, являются многостраничные отчеты, после тщательного изучения которых у аналитика появляется новая серия вопросов. Однако каждый новый запрос, непредусмотренный при проектировании такой системы, должен быть сначала формально описан, закодирован программистом и только затем выполнен. Время ожидания в таком случае может составлять часы и дни, что не всегда приемлемо. Таким образом, внешняя простота статических СППР, за которую активно борется большинство заказчиков информационно-аналитических систем, оборачивается катастрофической потерей гибкости.

Динамические СППР, напротив, ориентированы на обработку нерегламентированных (ad hoc) запросов аналитиков к данным. Наиболее глубоко требования к таким системам рассмотрел E. F. Codd в статье , положившей начало концепции OLAP. Работа аналитиков с этими системами заключается в интерактивной последовательности формирования запросов и изучения их результатов.

Но динамические СППР могут действовать не только в области оперативной аналитической обработки (OLAP); поддержка принятия управленческих решений на основе накопленных данных может выполняться в трех базовых сферах .

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

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

Сфера закономерностей. Интеллектуальная обработка производится методами интеллектуального анализа данных (ИАД, Data Mining) , главными задачами которых являются поиск функциональных и логических закономерностей в накопленной информации, построение моделей и правил, которые объясняют найденные аномалии и/или прогнозируют развитие некоторых процессов.

Оперативная аналитическая обработка данных

В основе концепции OLAP лежит принцип многомерного представления данных. В 1993 году в статье E. F. Codd рассмотрел недостатки реляционной модели, в первую очередь указав на невозможность "объединять, просматривать и анализировать данные с точки зрения множественности измерений, то есть самым понятным для корпоративных аналитиков способом", и определил общие требования к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик.

Классификация продуктов OLAP по способу представления данных.

В настоящее время на рынке присутствует большое количество продуктов, которые в той или иной степени обеспечивают функциональность OLAP. Около 30 наиболее известных перечислены в списке обзорного Web-сервера http://www.olapreport.com/. Обеспечивая многомерное концептуальное представление со стороны пользовательского интерфейса к исходной базе данных, все продукты OLAP делятся на три класса по типу исходной БД.

Самые первые системы оперативной аналитической обработки (например, Essbase компании Arbor Software , Oracle Express Server компании Oracle ) относились к классу MOLAP, то есть могли работать только со своими собственными многомерными базами данных. Они основываются на патентованных технологиях для многомерных СУБД и являются наиболее дорогими. Эти системы обеспечивают полный цикл OLAP-обработки. Они либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для связи с пользователем внешние программы работы с электронными таблицами. Для обслуживания таких систем требуется специальный штат сотрудников, занимающихся установкой, сопровождением системы, формированием представлений данных для конечных пользователей.

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

Наконец, гибридные системы (Hybrid OLAP, HOLAP) разработаны с целью совмещения достоинств и минимизации недостатков, присущих предыдущим классам. К этому классу относится Media/MR компании Speedware . По утверждению разработчиков, он объединяет аналитическую гибкость и скорость ответа MOLAP с постоянным доступом к реальным данным, свойственным ROLAP.

Многомерный OLAP (MOLAP)

В специализированных СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:

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

2) поликубов (каждая переменная хранится с собственным набором измерений, и все связанные с этим сложности обработки перекладываются на внутренние механизмы системы).

Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства.

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

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

С другой стороны, имеются существенные ограничения.

Многомерные СУБД не позволяют работать с большими базами данных. К тому же за счет денормализации и предварительно выполненной агрегации объем данных в многомерной базе, как правило, соответствует (по оценке Кодда ) в 2.5-100 раз меньшему объему исходных детализированных данных.

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

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

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

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

Время ответа системы на нерегламентированные запросы является наиболее критичным параметром.

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

Реляционный OLAP (ROLAP)

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

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

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

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

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

ведение

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

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

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

Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing).

OLAP – это ключевой компонент организации хранилищ данных.

Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных (см. E.F. Codd, S.B. Codd, and C.T.Salley, Providing OLAP (on-line analytical processing) to user-analysts: An IT mandate. Technical report, 1993).

В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information – быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:

· предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;

· возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;

· многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;

· многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это – ключевое требование OLAP);

· возможность обращаться к любой нужной информации независимо от ее объема и места хранения.

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

2. Что такое OLAP

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

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

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

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

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

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

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

3. История создания 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. Основным эффектом от приобретения CA Compete было резкое снижение цены на него и снятие защиты от копирования, что, естественно, способствовало его распространению. Однако он не был удачным. 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.

4. 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 обеспечивает обработку на больших массивах хранимых данных, так как возможно обеспечение более экономичного хранения, но, вместе с тем, значительно проигрывает в скорости работы многомерной. Подобные рассуждения привели к выделению нового класса аналитических инструментов – HOLAP. Это гибридная (hybrid) оперативная аналитическая обработка. Инструменты этого класса позволяют сочетать оба подхода – реляционного и многомерного. Доступ может вестись как к данным многомерных баз, так и к данным реляционных.

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

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

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

Механизм OLAP является на сегодня одним из популярных методов анализа данных. Есть два основных подхода к решению этой задачи. Первый из них называется Multidimensional OLAP (MOLAP) – реализация механизма при помощи многомерной базы данных на стороне сервера, а второй Relational OLAP (ROLAP) – построение кубов "на лету" на основе SQL запросов к реляционной СУБД. Каждый из этих подходов имеет свои плюсы и минусы. Их сравнительный анализ выходит за рамки этой статьи. Мы же опишем нашу реализацию ядра настольного ROLAP модуля.

Такая задача возникла после применения ROLAP системы, построенной на основе компонентов Decision Cube, входящих в состав Borland Delphi. К сожалению, использование этого набора компонент показало низкую производительность на больших объемах данных. Остроту этой проблемы можно снизить, стараясь отсечь как можно больше данных перед подачей их для построения кубов. Но этого не всегда бывает достаточно.

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

Схема работы

Общую схему работы настольной OLAP системы можно представить следующим образом:

Алгоритм работы следующий:

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

Рассмотрим как подобная система может быть устроена внутри. Начнем мы это с той стороны, которую можно посмотреть и пощупать, то есть с отображений.

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

Кросс-таблица

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

Таким образом, таблицу можно разделить на следующие элементы, с которыми мы и будем работать в дальнейшем:

Заполняя матрицу с фактами, мы должны действовать следующим образом:

• На основании данных об измерениях определить координаты добавляемого элемента в матрице.
• Определить координаты столбцов и строк итогов, на которые влияет добавляемый элемент.
• Добавить элемент в матрицу и соответствующие столбцы и строки итогов.

При этом нужно отметить то, что полученная матрица будет сильно разреженной, почему ее организация в виде двумерного массива (вариант, лежащий на поверхности) не только нерациональна, но, скорее всего, и невозможна в связи с большой размерностью этой матрицы, для хранения которой не хватит никакого объема оперативной памяти. Например, если наш куб содержит информацию о продажах за один год, и если в нем будет всего 3 измерения – Клиенты (250), Продукты (500) и Дата (365), то мы получим матрицу фактов следующих размеров:

Кол-во элементов = 250 х 500 х 365 = 45 625 000

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

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

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

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

Подготовка данных

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

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

Библиотека компонентов CubeBase

Описанные выше идеи были положены в основу при создании библиотеки компонентов CubeBase.

TСubeSource осуществляет кэширование и преобразование данных во внутренний формат, а также предварительное агрегирование данных. Компонент TСubeEngine осуществляет вычисление гиперкуба и операции с ним. Фактически, он является OLAP-машиной, осуществляющей преобразование плоской таблицы в многомерный набор данных. Компонент TCubeGrid выполняет вывод на экран кросс-таблицы и управление отображением гиперкуба. TСubeChart позволяет увидеть гиперкуб в виде графиков, а компонент TСubePivote управляет работой ядра куба.

Сравнение производительности

Данный набор компонент показал намного более высокое быстродействие, чем Decision Cube. Так на наборе из 45 тыс. записей компоненты Decision Cube потребовали 8 мин. на построение сводной таблицы. CubeBase осуществил загрузку данных за 7сек. и построение сводной таблицы за 4 сек. При тестировании на 700 тыс. записей Decision Cube мы не дождались отклика в течение 30 минут, после чего сняли задачу. CubeBase осуществил загрузку данных за 45 сек. и построение куба за 15 сек.

На объемах данных в тысячи записей CubeBase отрабатывал в десятки раз быстрее Decision Cube. На таблицах в сотни тысяч записей – в сотни раз быстрее. А высокая производительность – один из самых важных показателей OLAP систем.

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

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

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

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

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

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

OLAP-технология относится к виду интеллектуального анализа и предполагает 12 принципов:

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

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

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

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

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

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

7. Динамическое управление разреженными матрицами . Физическая схема OLAP-инструмента должна полностью адаптироваться к специфической аналитической модели для оптимального управления разреженными матрицами. Разреженность (измеряется в процентном отношении пустых ячеек ко всем возможным) – это одна из характеристик распространения данных.

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

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

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

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

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

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

Для решения простых задач анализа данных возможно использовать бюджетное решение – офисные приложения Excel и Access компании Microsoft, которые содержат элементарные средства OLAP-технологии, позволяющие создавать сводные таблицы и строить на их основе различные отчеты.