Теперь перейдем собственно к Oracle OLAP.

Как я уже упомянул, в 1995 году Oracle приобрел компанию IRI – пионера в области MOLAP, производителя Express. Я сам впервые столкнулся Oracle Express в 1999 году. Если бы я не прочитал, что первая его версия появилась в 1970, никогда бы не подумал.

На самом деле, с 1970 продукт несколько раз переписывался, в том числе и на другие языки программирования. И в 1995, когда его купил Oracle, Express был лидером в своем классе.

Семейство Oracle Express состоит из нескольких продуктов:

  • Oracle Express Server – собственно многомерный сервер.
  • Oracle Express Objects – RAD среда, напоминающая Visual Basic, с помощью которой можно написать любой интерфейс пользователя.
  • Oracle Express Analyzer – смотрелка кубов (в том случае если вы не хотите писать собственный интерфейс). Этот же Analyzer является runtime-средой для приложений, написанных на Objects.
  • Express Web Publisher – компонент, который позволяет публиковать данные из Express на вебсайтах.

У Express Server есть помимо стандартных возможностей просмотра содержимого кубов, есть ряд интересных и иногда даже уникальных возможностей. Например:

  • Возможность не только читать данные из куба, но и писать их в куб (Writeback), причем в произвольную ячейку или группу ячеек. Для этого даже не надо переводить куб в какой-либо специальный режим. На самом деле даже расчет агрегатов производится как вычисление значения нужной агрегированной ячейки и последующей записью ее в куб. Эта возможность очень востребована на пример при What-If (что-если) анализе. Когда нужно изменить некий параметр, и после этого пересчитать значение связанных с ним ячеек. Или когда значение агрегата не вычисляется, а вводится пользователем. Такое часто бывает в финансовых приложениях.
  • Модели (MODELS) – специальная конструкция в Express, позволяющая описать многошаговую последовательность вычисления одних данных на основе других, причем в нескольких вариантах сразу (оптимистическом, пессимистическом и т.д.) Результат будет зафиксирован в кубе и доступен уже просто для чтения другим пользователям.
  • Формулы – по сути, это аналог View в реляционных базах. То есть имея данные в кубах, можно описать виртуальный куб, который содержит данные из других кубов и вычисления над ними. Для пользователя формула видна как обычный куб. Например если у нас есть кубик содержащий продажи по дням в некоторой валюте, то имея второй куб с курсами валют на каждую дату, можно написать формулу, которая будет для каждой даты и для каждой валюты пересчитывать данные по курсу. Для пользователя это будет видно как обычный куб, у которого добавится еще одно измерение – требуемая валюта. Формулы хранятся в кубе.
  • Наконец, программы. Это аналог хранимых процедур в реляционных базах. Не все можно описать языком запросов. Часто требуется написать процедуру из многих шагов, итераций и т.д. В Express можно было написать на собственном языке Express Language практически все что угодно: процедуры загрузки, агрегации, преобразования, очистки. И даже можно писать формулы (см. пред пункт), включающие в себя результаты вычисления программы по введенным параметрам.

При этом, все это работало очень быстро и вообще Express нетребователен к ресурсам. На основе Express написан, например, продукт Oracle Financial Analyzer, предназначенный для планирования и бюджетирования. Этот продукт успешно использует все вышеперечисленные возможности Express.

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

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

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

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

Учитывая это, в Oracle пришли к идее, что если взять движок Express Server и поместить его вместе с OLAP-данными внутрь СУБД Oracle, то это даст ряд преимуществ, тем более что диски и память стали дешевле:

  • Упрощение администрирования. Не нужно создавать специальную систему резервного копирования только для OLAP, бэкап OLAP данных будет происходить вместе с бэкапом базы Oracle.
  • Не нужна специальная система безопасности для OLAP – полномочия будут раздаваться централизованно, так как это делается в Oracle.
  • Если OLAP база располагается на том же сервере что и транзакционная, то не нужна перекачка данных между транзакционным и OLAP сервером, а это выигрыш в производительности.
  • Можно организовать прозрачный доступ пользователя к OLAP и не OLAP данным. Даже через обычный SQL.
  • И т.д.

В итоге решение о включении Express в состав СУБД было принято. И появилась OLAP опция СУБД Oracle. Которая сейчас называется просто Oracle OLAP. Express существует и продается, в том числе в составе Oracle Financial Analyzer, но усилия разработчиков в основном направлены на OLAP опцию базы.

Но так как процесс интеграции нереляционной СУБД внутрь реляционной оказался не так прост, то он занял некоторое время.
Сначала, в первом релизе Oracle 9i не было MOLAP, был организован только ROLAP.
Во втором релизе появился MOLAP (то есть движок Express был интегрирован в базу), но понадобилось время и несколько промежуточных релизов чтобы оптимизировать код.

Фактически, в 9-ой версии к функциональности OLAP ничего нового не добавлялось, и только в версии 10g, а особенно в 10.2 появился новый функционал, который позволяет делать то, что нельзя было делать в Express. Например:

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

Поэтому, если вы только знакомитесь с Oracle OLAP лучше всего начинать с версии 10.2.

К сожалению, OLAP опция не поддерживает тот API, который был в Express, поэтому приложения, написанные на Express Objects не могут работать с OLAP опцией. Вместо этого в OLAP есть Java OLAP API, через который работает например Discoverer for OLAP.

Для написания собственных приложений, можно использовать этот API, плюс так называемые Business Intelligence Beans – Java компоненты, которые сами умеют доставать данные из OLAP, используя API и выводить данные в табличном и графическом виде. На самом деле, их применение гораздо шире. Хотя начались они и с OLAP опции, но отображение информации в табличном и графическом виде необходимо не только в OLAP опции, поэтому со временем BI Beans стали использоваться во многих продуктах Oracle, например в Enterprise Manager-е. И вообще, поскольку рисовалки графиков и таблиц принимают на вход данные в XML формате, то их можно использовать практически с чем угодно. Если вы, конечно, пишете на Java.

Но если вы Java не используете, вы можете работать с кубами MOLAP при помощи обычного (почти) SQL. Дело в том, что в Oracle существует табличная функция OLAP_TABLE, которая при обращении к ней из SQL ведет себя как VIEW, но в нее можно передавать параметры, говорящие движку MOLAP, что нужно достать из куба.
Выглядеть этот запрос будет, например так (взято отсюда):

SELECT *
FROM TABLE(
OLAP_TABLE(
\'AWG DURATION SESSION\',
\'\',
\'\',
\'MEASURE quant AS NUMBER FROM cubname_quantity
DIMENSION firms FROM FIRMS_DIM
WITH ATTRIBUTE firm_name FROM FIRMS_DIM_LONG_DESCRIPTION
DIMENSION countues FROM COUNTRIES_DIM
DIMENSION time FROM TIME_DIM\'
)
)

Такой запрос можно положить во VIEW и делать запросы к этой VIEW с помощью любого SQL-инструмента. Таким образом нет необходимости поддержки специального API со стороны клиентских инструментов. Любой инструмент может работать с MOLAP, даже тот, разработчики которого и не думали о такой возможности.

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

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

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

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

Кроме того,