Я провел предварительный обзор существующих на рынке OLAP-продуктов. Количество поставщиков таких продуктов достаточно велико. Такими поставщиками являются: Targit, Next Action Technology, Cartesis, Hyperion Solutions, Cristal Decisions, Knosys, Cognos, Brio Technology, Sybase, Arbor Systems, SAS Institute, IQ Software, Business Objects, Oracle, Informix, Microsoft, IBM и другие. В виду достаточно большого количества, я сузил круг сравниваемых продуктов наиболее известными и долго работающими на рынке поставщиками. Итак, я выбрал следующих поставщиков: Microsoft, Sybase, IBM, Oracle, Informix. Каждая из этих фирм известна своими достижениями в области СУБД и имеет в ряде своих продуктов и OLAP-средства.

Таблица 1. Сравниваемые OLAP-продукты

Далее будут рассматриваться только те программные продукты, которые перечислены в Таблице 1.

4.2. Основные принципы OLAP

В первую очередь необходимо определить основные параметры, позволяющие считать конкретный продукт OLAP-продуктом. В 1993 году Е. Ф. Кодд с партнерами опубликовали статью, озаглавленную «Обеспечение OLAP для пользователей - аналитиков»[9], как некий "мандат" информационной технологии. В этой статье Е. Ф. Кодд сформулировал 12 основополагающих принципов OLAP. В 1995 году к ним были добавлены еще шесть. Доктор Кодд разбил на четыре группы эти правила, назвав их "особенностями".

4.2.1.Основные особенности

F1: Многомерное концептуальное представление данных. Эта особенность является сердцевиной OLAP.

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

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

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

F5: Модели анализа OLAP. Д-р Кодд требует, чтобы OLAP продукты поддерживали все четыре модели анализа, которые он описывает в своей статье (Категориальный, Толковательный, Умозрительный и Стереотипный). Это можно перефразировать, как формирование параметрически настраиваемых отчетов, формирование разрезов и группировок с обращением, анализом в стиле "что, если" и моделями поиска целей, соответственно.

F6: Архитектура "клиент-сервер". Д-р Кодд требует, чтобы продукт был не только клиент-серверным, но и чтобы серверный компонент был бы достаточно интеллектуальным для того, чтобы различные клиенты могли подключаться с минимумом усилий и программирования. Это требование существенно сильнее, чем просто архитектура "клиент-сервер", и относительно небольшое количество продуктов удовлетворяют ему. В сущности, это косвенно означает, что OLAP доступен с Вашего рабочего стола. Возможно д-р Кодд предполагал доступ через Web, или он предвосхищал повсеместное принятие стандарта, которым обещает стать OLE DB для OLAP. 

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

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

4.2.2.Специальные особенности

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

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

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

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

4.2.3.Особенности представления отчетов

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

F14: Стандартная производительность отчетов. Д-р Кодд требует, чтобы производительность формирования отчетов существенно не падала с ростом количества измерений и размеров базы данных.

F15: Автоматическая настройка физического уровня. Д-р Кодд требует, чтобы OLAP системы автоматически настраивали свою физическую схему в зависимости от типа модели, объемов данных и разряженности базы данных. Большинство поставщиков весьма далеки от этого прекрасного идеала. Компания Panorama technology, приобретенная компанией Microsoft в октябре 1996г, заложила здесь новый фундамент, и пользователи теперь могут извлечь выгоды из Microsoft OLAP Services.

4.2.4.Управление измерениями

F16: Универсальность измерений. Все измерения должны быть равноправны, каждое измерение должно быть эквивалентно и в структуре и в операционных возможностях.

F17: Неограниченное число измерений и уровней агрегации. Технически нет продукта, который мог бы соответствовать этому требованию, потому что нет такой вещи, как неограниченный объект на ограниченном компьютере. В любом случае, немного приложений нуждаются в более, чем порядка 8-ми или 10-ти измерениях, немного приложений имеют иерархию более шести консолидированных уровней. Д-р Кодд предлагает, что в случае принятия некоторого максимума, он должен обеспечивать по крайней мере 15 измерений, а предпочтительнее - 20.

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

4.3. Тест FASMI

В 1995 году Найджел Пендс и Ричард Крит из OLAP Report [11] уточнили определение OLAP Д-р Кодда, предложив так называемый тест FASMI. Этот критерий просто утверждает, что OLAP-приложения должны обеспечивать Быстрый Анализ Разделяемой Многомерной Информации (Fast Analysis of Shared Multidimensional Information).

Fast (Быстрый) - анализ должен производиться одинаково быстро по всем аспектам информации. Приемлемое время отклика - 5 с или менее.

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

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

Multidimensional (Многомерной) - это основная, наиболее существенная характеристика OLAP.

Information (Информации) - приложение должно иметь возможность обращаться к любой нужной информации, независимо от ее объема и места хранения.

4.4 Критерии сравнения OLAP-продуктов

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

1. Поддержка ODBC-протокола.

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

2. Поддержка доступа к нереляционных источникам данных.

Имеется в виду возможность OLAP-продукта осуществлять доступ не только к СУБД посредством ODBC, но и к другим источникам данных. Такими источниками могут быть текстовые файлы, файловые системы, такие как Windows NT® и UNIX®, индексно-последователь­ные файлы, электронная почта, электронные таблицы, средства управления проектами и многое другое. Примером протокола, позволяющего осуществлять доступ к нереляционных источникам данных является OLE DB.

3. Возможность хранения данных в форме MOLAP и HOLAP.

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

4. Временное хранение многомерных данных на клиентских компьютерах.

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

5. Возможность создания вычисляемых меток.

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

6. Совместная работа с несколькими кубами.

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

7. Масштабируемость.

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

8. Оптимизация схемы агрегирования.

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

9. Удобные средства администрирования.

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

10. Решение проблемы «взрыва данных».

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