Цель доклада

В данном докладе речь пойдет об одной из категорий интеллектуальных технологий, которые являются удобным аналитическим инструментом – 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 (On-Line Analytical Processing), любая организация может почти мгновенно (в течение пяти секунд) получить необходимые для работы данные. OLAP можно определить вкратце пятью ключевыми словами.

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

ANALYSIS (Аналитический) говорит, что система может произвести любой анализ, как статистический, так и логический, и затем сохраняет его в доступном виде.

SHARED (Разделяемый) означает, что система обеспечивает требуемую конфиденциальность, вплоть до уровня ячейки

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

INFORMATION (Информационная). Нужная информация должна быть доставлена туда, где она необходима.

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

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

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

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

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

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

Различные производители имеют разные механизмы представления данных. Процедура гетерогенного представления подразумевает извлечение, трансформирование и загрузку (ETL). Например, в Microsoft SQL Server 2005 Analysis Services проблема консолидации данных реализована с помощью Data Source Views – видов источников данных, описывающих аналитические модели представления.

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

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

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

Примеры продуктов: Microsoft Excel Pivot Tables, Microsoft Analysis Services, SAP BW, Oracle Essbase, Oracle OLAP, Cognos PowerPlay, MicroStrategy, Business Objects.

Финансовое планирование-бюджетирование.

Многомерная модель позволяет одновременно вводить данные и легко анализировать их (например, план факт анализ). Поэтому ряд современных продуктов класса CPM (Corporate Performance Management) используют OLAP%модели. Важная задача – многомерный обратный расчёт (backsolve, breakback, writeback), позволяющий рассчитать требуемые изменения детальных ячеек при изменении агрегированного значения. Это инструмент для анализа «что-если» (what-if), т.е. для проигрывания различных вариантов событий при планировании.

Примеры продуктов: Microsoft PerformancePint, Oracle EPB, Oracle OFA, Oracle Hyperion Planning, SAP SEM, Cognos Enterprise Planning, Geac.

Финансовая консолидация.

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

Примеры продуктов: Oracle FCH, Oracle Hyperion FM, Cognos Controller.

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

Список литературы:

1. Erik Thomsen. OLAP Solutions: Building Multidimensional Information Systems Second Edition. Wiley Computer Publishing John Wiley & Sons, Inc., 2002.

2. OLAP council white paper, http://www.olapcouncil.org/research/whtpaply.htm

3. Gerd Stumme and Bernhard Ganter. Formal Concept Analysis _ Mathematical Foundations.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Точки продаж
  - Сотрудники
  - Партнеры

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

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

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

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

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

4. Классификация OLAP-продуктов.

5. Принципы работы OLAP-клиентов.

7. Сферы применения OLAP-технологий.

8. Пример использования OLAP-технологий для анализа в сфере продаж.

1. Место OLAP в информационной структуре предприятия.

Термин "OLAP" неразрывно связан с термином "хранилище данных" (Data Warehouse ).

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

Задача хранилища - предоставить "сырье" для анализа в одном месте и в простой, понятной структуре.

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

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

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

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

Место OLAP в информационной структуре предприятия (рис. 1).

Рисунок 1 . Место OLAP в информационной структуре предприятия

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

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

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

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

По Кодду, многомерное концептуальное представление данных (multi-dimensional conceptual view ) представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных.

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

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

Операция спуска (drilling down ) соответствует движению от высших ступеней консолидации к низшим ; напротив, операция подъема (rolling up ) означает движение от низших уровней к высшим (рис. 2).

Рисунок 2. Измерения и направления консолидации данных

3. Требования к средствам оперативной аналитической обработки.

Многомерный подход возник практически одновременно и параллельно с реляционным . Однако, только начиная с середины девяностых годов, а точнее с
1993 г., интерес к МСУБД начал приобретать всеобщий характер. Именно в этом году появилась новая программная статья одного из основоположников реляционного подхода Э. Кодда , в которой он сформулировал 12 основных требований к средствам реализации OLAP (табл. 1).

Таблица 1.

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

Правила оценки программных продуктов класса OLAP

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

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

Помнить 12 правил Кодда слишком обременительно для большинства людей. Оказались, что можно резюмировать OLAP-определение только пятью ключевыми словами: Быстрый Анализ Разделяемой Многомерной Информации - или, кратко - FASMI (в переводе с английского: F ast A nalysis of S hared M ultidimensional I nformation ).

Это определение впервые было сформулировано в начале 1995 года и с тех пор не нуждалось в пересмотре.

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

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

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

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

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

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

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

Тест FASMI - разумное и понятное определение целей, на достижение которых ориентированы OLAP.

4. Классификация OLAP -продуктов.

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

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

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

Многомерные кубы строятся на основе исходных и агрегатных данных. И исходные и агрегатные данные для кубов могут храниться как в реляционных, так и многомерных базах данных. Поэтому в настоящее время применяются три способа хранения данных: MOLAP (Multidimensional OLAP ), ROLAP (Relational OLAP ) и HOLAP (Hybrid OLAP ). Соответственно, OLAP -продукты по способу хранения данных делятся на три аналогичные категории:

1. В случае MOLAP , исходные и агрегатные данные хранятся в многомерной БД или в многомерном локальном кубе.

2. В ROLAP -продуктах исходные данные хранятся в реляционных БД или в плоских локальных таблицах на файл-сервере. Агрегатные данные могут помещаться в служебные таблицы в той же БД. Преобразование данных из реляционной БД в многомерные кубы происходит по запросу OLAP -средства.

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

Классификация по месту размещения OLAP -машины.

По этому признаку OLAP -продукты делятся на OLAP -серверы и OLAP -клиенты:

· В серверных OLAP -средствах вычисления и хранение агрегатных данных выполняются отдельным процессом - сервером. Клиентское приложение получает только результаты запросов к многомерным кубам, которые хранятся на сервере. Некоторые OLAP -серверы поддерживают хранение данных только в реляционных базах, некоторые - только в многомерных. Многие современные OLAP -серверы поддерживают все три способа хранения данных: MOLAP , ROLAP и HOLAP .

MOLAP.

MOLAP - это Multidimensional On-Line Analytical Processing, то есть Многомерный OLAP. Это означает, что сервер для хранения данных использует многомерную базу данных (МБД). Смысл использования МБД очевиден. Она может эффективно хранить многомерные по своей природе данные, обеспечивая средства быстрого обслуживания запросов к базе данных. Данные передаются от источника данных в многомерную базу данных, а затем база данных подвергается агрегации. Предварительный расчет - это то, что ускоряет OLAP-запросы, поскольку расчет сводных данных уже произведен. Время запроса становится функцией исключительно времени, необходимого для доступа к отдельному фрагменту данных и выполнения расчета. Этот метод поддерживает концепцию, согласно которой работа производится единожды, а результаты затем используются снова и снова. Многомерные базы данных являются относительно новой технологией. Использование МБД имеет те же недостатки, что и большинство новых технологий. А именно - они не так устойчивы, как реляционные базы данных (РБД), и в той же мере не оптимизированы. Другое слабое место МБД заключается в невозможности использовать большинство многомерных баз в процессе агрегации данных, поэтому требуется время для того, чтобы новая информация стала доступна для анализа.

ROLAP.

ROLAP - это Relational On-Line Analytical Processing, то есть Реляционный OLAP. Термин ROLAP обозначает, что OLAP-сервер базируется на реляционной базе данных. Исходные данные вводятся в реляционную базу данных, обычно по схеме "звезда" или схеме "снежинка", что способствует сокращению времени извлечения. Сервер обеспечивает многомерную модель данных с помощью оптимизированных SQL-запросов.

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

Агрегированные/Предварительно агрегированные данные.

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

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

· OLAP -клиент устроен по-другому. Построение многомерного куба и OLAP -вычисления выполняются в памяти клиентского компьютера. OLAP -клиенты также делятся на ROLAP и MOLAP . А некоторые могут поддерживать оба варианта доступа к данным.

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

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

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

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

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

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

· Мощные ПК аналитиков – еще один довод в пользу OLAP -клиентов. При применении OLAP -сервера эти мощности не используются.

Среди преимуществ OLAP-клиентов можно также назвать следующее:

· Затраты на внедрение и сопровождение OLAP -клиента существенно ниже, чем затраты на OLAP -сервер.

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

5. Принципы работы OLAP -клиентов.

Рассмотрим процесс создания OLAP-приложения с помощью клиентского инструментального средства (рис. 1).

Рисунок 1. Создание OLAP-приложения с помощью клиентского ROLAP-средства

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

Принцип работы клиента OLAP-сервера иной. В OLAP-сервере при создании кубов пользователь манипулирует физическими описаниями БД. При этом в самом кубе создаются пользовательские описания. Клиент OLAP-сервера настраивается только на куб.

При создании семантического слоя источники данных – таблицы Sales и Deal – описываются понятными конечному пользователю терминами и превращаются в «Продукты» и «Сделки». Поле «ID» из таблицы «Продукты» переименовывается в «Код», а «Name » - в «Товар» и т.д.

Затем создается бизнес-объект «Продажи». Бизнес-объект – это плоская таблица, на основе которой формируется многомерный куб. При создании бизнес-объекта таблицы «Продукты» и «Сделки» объединяются по полю «Код» товара. Поскольку для отображения в отчете не потребуются все поля таблиц – бизнес-объект использует только поля «Товар», «Дата» и «Сумма».

В нашем примере на базе бизнес-объекта «Продажи» создан отчет по продажам товаров по месяцам.

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

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

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

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

6. Выбор архитектуры OLAP-приложения.

При реализации информационно-аналитической системы важно не ошибиться в выборе архитектуры OLAP-приложения. Дословный перевод термина On-Line Analytical Process - «оперативная аналитическая обработка» - часто воспринимается буквально в том смысле, что поступающие в систему данные оперативно анализируются. Это заблуждение - оперативность анализа никак не связана с реальным временем обновления данных в системе. Эта характеристика относится к времени реакции OLAP-системы на запросы пользователя. При этом зачастую анализируемые данные представляют собой снимок информации «на вчерашний день», если, например, данные в хранилищах обновляются раз в сутки.

В этом контексте более точен перевод OLAP как «интерактивная аналитическая обработка». Именно возможность анализа данных в интерактивном режиме отличает OLAP-системы от систем подготовки регламентированных отчетов.

Другой особенностью интерактивной обработки в формулировке родоначальника OLAP Э. Кодда является возможность «объединять, просматривать и анализировать данные с точки зрения множественности измерений, т. е. самым понятным для корпоративных аналитиков способом». У самого Кодда термин OLAP обозначает исключительно конкретный способ представления данных на концептуальном уровне - многомерный. На физическом уровне данные могут храниться в реляционных базах данных, однако на деле OLAP-инструменты, как правило, работают с многомерными базами данных, в которых данные упорядочены в виде гиперкуба (рис. 1).

Рисунок 1. OLAP – куб (гиперкуб, метакуб )

При этом актуальность этих данных определяется моментом наполнения гиперкуба новыми данными.

Очевидно, что время формирования многомерной базы данных существенно зависит от объема загружаемых в нее данных, поэтому разумно ограничить этот объем. Но как при этом не сузить возможности анализа и не лишить пользователя доступа ко всей интересующей информации? Существует два альтернативных пути: Analyze then query («Сначала проанализируй - затем запроси дополнительную информацию») и Query then analyze («Сначала запроси данные - затем анализируй»).

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

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

К достоинствам второго подхода следует отнести «свежесть» информации, которую пользователь получает в виде многомерного отчета - «микрокуба ». Микрокуб формируется на основе только что запрошенной информации из актуальной реляционной базы данных. Работа с микрокубом осуществляется в интерактивном режиме - получение срезов информации и ее детализация в рамках микрокуба осуществляется моментально. Другим положительным моментом является то, что проектирование структуры и наполнение микрокуба осуществляется пользователем «на лету», без участия администратора баз данных. Однако подход страдает и серьезными недостатками. Пользователь, не видит общей картины и должен заранее определяться с направлением своего исследования. В противном случае запрошенный микрокуб может оказаться слишком мал и не содержать всех интересующих данных, а пользователю придется запрашивать новый микрокуб , затем новый, затем еще и еще. Подход Query then analyze реализует инструментальное средство BusinessObjects одноименной компании и инструментальные средства платформы Контур компании Intersoft Lab .

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

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

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

Наиболее яркими представителями подхода «Analyze then query » являются инструментальные средства PowerPlay и Impromptu компании Cognos .

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

7. Сферы применения OLAP-технологий.

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

Рассмотрим некоторые сферы применения OLAP-технологий, взятые из реальной жизни.

1. Продажи.

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

2. Закупки.

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

3. Цены.

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

4. Маркетинг.

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

5. Склад.

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

6. Движение денежных средств.

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

7. Бюджет.

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

8. Бухгалтерские счета.

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

9. Финансовая отчетность.

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

10. Посещаемость сайта.

Лог-файл Интернет-сервера многомерен по природе, а значит подходит для OLAP-анализа. Фактами являются: количество посещений, количество хитов, время проведенное на странице и другая информация, имеющаяся в логе.

11. Объемы производства.

Это еще один пример статистического анализа. Таким образом, можно анализировать объемы выращенного картофеля, выплавленной стали, произведенного товара.

12. Потребление расходных материалов.

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

13. Использование помещений.

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

14. Текучесть кадров на предприятии.

Анализ текучести кадров на предприятии в разрезе филиалов, отделов, профессий, уровня образования, пола, возраста, времени.

15. Пассажирские перевозки.

Анализ количества проданных билетов и сумм в разрезе сезонов, направлений, видов вагонов (классов), типов поездов (самолетов).

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

8. Пример использования OLAP -технологий для анализа в сфере продаж.

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

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

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

Измерение «Клиенты» отражает структуру продаж по территориально-географическому признаку. В каждом измерении могут существовать свои ие рархии, например, в данном измерении это может быть структура: Страны – Регионы – Города – Клиенты.

Для анализа эффективности деятельности подразделений следует создать свое измерение. Например, можно выделить два уровня иерархии: департаменты и входящие в них отделы, что и должно найти отражение в измерении «Подразделения».

По сути, измерения «Время», «Товары», «Заказчики» достаточно полно определяют пространство предметной области.

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

OLAP – куб для анализа будет иметь вид (рис. 2):

Рисунок 2. OLAP – куб для анализа объема продаж

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

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

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

Рисунок 3. Структура аналитического отчета

Разрежем наш OLAP – куб и получим отчет о продажах за третий квартал, он будет иметь следующий вид (рис.4).

Рисунок 4. Отчет о продажах за третий квартал

Можно разрезать куб вдоль другой оси и получить отчет о продажах группы товаров 2 в течение года (рис. 5).

Рисунок 5. Поквартальный отчет о продажах товара 2

Аналогично можно проанализировать отношения с клиентом 4, разрезав куб по метке Клиенты (рис. 6)

Рисунок 6. Отчет о поставках товаров клиенту 4

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