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

ОПЕРАТИВНЫЙ АНАЛИЗ ДАННЫХ - On-Line Analytical Processing (OLAP) - информационная технология, которая предоставляет руководителям различного уровня возможность получения необходимой информации для принятия управленческих, финансовых и кадровых решений.
В основе концепции OLAP лежит принцип многомерного представления данных. Первое четкое определение OLAP предложено в 1993 году Е.Ф.Коддом (E.F.Codd) в статье, опубликованной при поддержке Arbor Software (теперь - Hyperion Software). Статья включала 12 правил, которые сейчас уже стали широко известными и описаны на сайте любого поставщика OLAP приложений.
Е.Ф.Кодд рассмотрел недостатки реляционной модели, в первую очередь указав на невозможность "объединять, просматривать и анализировать данные с точки зрения множественности измерений, то есть самым понятным для корпоративных аналитиков способом", и определил общие требования к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик.
В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:

• предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;
• возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;
• многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;
• многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это - ключевое требование OLAP);
• возможность обращаться к любой нужной информации независимо от ее объема и места хранения. Дискуссии в основном касаются пятисекундного интервала ожидания результатов анализа конечным пользователем OLAP-продукта. Именно этим объясняют применение технологий с "кубами", которую применяет большинство производителей аналитических систем. Остальные требования не противоречат "классическим" 12 правилам Э.Кодда и относятся скорее к требованиям на используемое "железо" и линии связи.
  Наш взгляд на эту проблему всегда был классическим - использование "кубов" однозначно исключает продукт из класса OLAP. В 2005 году появились публикации фирмы Microsoft, которые указывают на то, что OLAP и "кубы" понятия несовместимые.

Принимать ту или иную точку зрения можно, ответив для себя на следующие вопросы:
1. Должны ли мы к требуемому времени отклика в пять секунд добавить время на создание "кубов"? Это дополнительное время может измеряться в минутах (при технологиях "инкрементации" готовых кубов новыми данными), в часах или сутках (в зависимости от объемов БД) при создании и "процессинге" новых "кубов" и слабо предсказуемым временем на объяснение требований пользователя администраторам БД и "OLAP-систем" на создание новых кубов, согласование граничных условий агрегации показателей и т.д. и т.п.
2. Можно ли считать "OLAP с кубами" средством для поддержки принятия решений, если вопрос надо решить "здесь и сейчас", а ответ надо ждать несколько суток плюс пять секунд?
3. В БД современных предприятий тысячи показателей. "Кубы" более чем с десятком измерений - скорее исключение, чем правило. Добавление каждого нового измерения в "куб" увеличивает БД (хранилище "куба") минимум на порядок. "Кубы" из скольких измерений можно "процессить" за приемлемое время? (О шестом требовании Кодда - о равноценности измерений для анализа - приэтом скромно "забывают".) Как из тысяч измерений выбрать и включить в "кубы" те, которые потребуются пользователю завтра или через минуту? Классический пример - решения SAP. Даже на самой простейшей их подсистеме HR (кадры), по данным за 2005 год, созданы и постоянно "процессятся" 32 "куба". (Это помимо более чем 300 заранее разработанных форм и постоянно работающих специалистов над созданием все новых и новых отчетов для анализа. Неплохо помнить и о том, что это требует постоянного обучения персонала и т.д.)
4. Предприятия каких размеров и доходности могут позволить себе покупку "OLAP-систем" стоимостью десятки тысяч долларов за рабочее место и дорогостоящего оборудования для его эксплуатации, покупку (или поиск), обучение, содержание (и удержание!) хорошо обученных высококвалифицированных специалистов (иначе теряется смысл их содержать)? Очевидно, что из этого списка однозначно выпадают малые предприятия и, с большой вероятностью, средние. М.б. это им и не нужно? Факты говорят об обратном. Цена неправильного решения для малого и даже среднего предприятия часто оказывается относительно более серьезной, чем для большого.

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

Из чего мы исходили?

• любой фиксируемый факт многомерен изначально. Из этого следует простой вывод - не обязательно раскладывать факты по полочкам "кубов", чтобы извлекать эту многомерность из любой неупорядоченной, в пределе - даже из потока OLTP-информации;
• провести анализ информации невозможно не прочитав ее один раз. А т.к. факты фиксируются независимо друг от друга, то логично предположить, что и однократный проход по информации может быть распараллелен на многопроцессорных серверах;
• мышление человека изначально многомерно. Задавая вопросы, человек осознает, что любой факт происходит во времени, пространстве, может быть отнесен к определенным категориям на какой-либо шкале и т.д. Когда человек задает естественный для его сознания вопрос, например: "Какие товарные группы лучше продаются в различных климатических зонах, в разные периоды года, в разных странах?", то полученный им многомерный (в данном случае - четырехмерный) документ для него естественен и понятен. Поэтому следует дать пользователю инструмент, который позволит ему в терминах своей предметной области задать интересующие вопросы и получить ответы в эргономичной, т.е. удобной и понятной форме;
• комбинаторика говорит о том, что один и тот же многомерный документ может быть представлен любым из (N+1)! способов. Каждый пользователь может иметь свои представления об удобстве и предпочтениях представления информации. Следует дать любому пользователю возможность представить информацию так, как ему удобнее.

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