4.3.3. Оперативная аналитическая обработка (olap)

4.3.3.1. Определение OLAP

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

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

1. Fast (быстрый). Быстрой можно считать систему, среднее время выдачи результатов обработки запросов в которой составляет порядка 5 сек. Указываются также следующие показатели: время обработки наиболее простых запросов – 1 сек., наиболее сложных – 20 сек. Исследования реакции пользователей показывают, что неудачным считается время обработки запроса более 30 сек. ИС, удовлетворяющая указанным требованиям производительности, однозначно будет воспринята пользователями лучше, чем неудовлетворяющая, даже более многофункциональная.

2. Analysis (анализ). Система может справляться с любым логическим и статистическим анализом, характерным для данного приложения. Этим определением одновременно ограничивается какой-то класс необходимых задач анализа и расширяются возможности системы до размеров этого класса.

3. Shared (разделяемой). ИС осуществляет все требования конфиденциальности (возможно, до уровня ячейки).

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

5. Information (информации). Само понятие в расшифровке не нуждается. По отношению к обрабатываемой в OLAP-системах информации выделяют следующие специфические аспекты:

   1. дублирование данных;

   2. требуемая оперативная память;

   3. требуемое дисковое пространство;

   4. эксплуатационные показатели;

   5. возможности интеграции с различными источниками данных и информационными фондами.

Более подробно требования к OLAP-системам были сформулированы Е.Ф.Коддом с соавторами в 1993 г. Первоначальные 12 правил были подвергнуты критике и критикуются до сих пор, поэтому в 1995 г. они были доработаны, дополнены еще шестью и разбиты на 4 группы:

1. Основные особенности (B):

   1. Многомерное концептуальное представление данных (Multidimensional Conceptual View). Концептуальное представление модели данных должно способствовать выполнению аналитиками интуитивных операций с многомерными данными.

   2. Интуитивное манипулирование данными (Intuitive Data Manipulation). Манипуляции должны выполняться в интуитивно понятном пользовательском интерфейсе.

   3. Доступность (Accessibility). Инструментарий OLAP должен накладывать свою логическую схему на физические массивы данных и представлять их независимо от их организации.

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

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

   6. Архитектура "клиент-сервер" (Client-Server Architecture). Серверный компонент инструмента OLAP должен быть достаточно интеллектуальным и обладать способностью строить общую концептуальную схему на основе обобщения и консолидации различных логических и физических схем баз данных для обеспечения эффекта прозрачности (см. ниже). Это достаточно жесткое требование. Оно фактически сильно занижает требования к функциональности клиентской части. На практике практически не выполняется.

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

   8. Поддержка многопользовательского режима (Multi-User Support). Несколько аналитиков должны иметь возможность работать одновременно с одной аналитической моделью или создавать различные модели на основе одних данных. Инструмент должен предоставлять им конкурентный доступ, обеспечивать целостность и защиту данных.

2. Специальные особенности (S):

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

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

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

   4. Обработка отсутствующих значений. Все отсутствующие значения игнорируются при обработке.

3. Особенности представления отчетов (R):

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

   2. Устойчивая производительность (Consistent Reporting Performance). С увеличением числа измерений и размеров базы данных аналитики не должны столкнуться с каким бы то ни было уменьшением производительности. Замечание 1: увеличение числа измерений или размеров БД существенно не влияет на производительность в БД с полными предварительными вычислениями. Замечание 2: в хороших продуктах производительность практически линейно зависит от количества ячеек, используемых при формировании отчета, которых может быть гораздо больше, чем тех, что появляются в окончательном отчете. Замечание общее: принципиальным фактором, влияющим на производительность, является количество выполняемых вычислений и их размещение (на клиентской машине, на сервере многомерной базы данных или в реляционной СУБД).

   3. Автоматическая настройка физического уровня (в первом варианте "Динамическая обработка разреженных матриц" – Dynamic Sparse Matrix Handling). Скорость доступа должна быть постоянной вне зависимости от расположения ячеек данных, моделей, числа измерений и т.д.

4. Управление измерениями (D):

   1. Универсальность (равноправие) измерений (Generic Dimensionality). Все измерения данных должны быть равноправны. Дополнительные характеристики могут быть предоставлены любому измерению. Базовая структура данных, формулы и форматы отчетов не должны опираться на какое-то одно измерение. Замечание 1: опытом доказано, что это наиболее спорное правило из первоначальных двенадцати, т.к. в абсолютном большинстве ситуаций измерение "время" специфично и неэквивалентно остальным. Замечание 2: Это правило следует рассматривать для универсального инструмента, но с наиболее низким приоритетом, и можно игнорировать для специфического приложения.

   2. Неограниченное число измерений и уровней агрегации (Unlimited Dimensions and Aggregation Levels). Согласно Кодду: должны поддерживаться 15 – 20 измерений. Каждое из этих измерений должно допускать практически неограниченное количество определенных пользователем уровней агрегации по любому направлению консолидации. Согласно более реалистичным авторам: абсолютное большинство реальных приложений не требуют более 8 – 10 измерений. На практике это требование может по большому счету игнорироваться.

   3. Неограниченные операции между размерностями (кроссмерные операции) (Unrestricted Cross-Dimensional Operations). Все виды операций должны быть дозволены для любых измерений и задаваться на функционально полном языке.

4.3.3.2. Классификация OLAP

Классификация продуктов, реализующих OLAP, базируется на классификации моделей данных СУБД, используемых этими продуктами:

1. Многомерные OLAP (Multidimensional OLAP, MOLAP) работают только со своими собственными многомерными базами данных. Они основываются на патентованных технологиях для многомерных СУБД и являются наиболее дорогими. Эти системы либо включают в себя интегрированный клиентский интерфейс, либо используют для связи с пользователем внешние программы работы с электронными таблицами. Для обслуживания таких систем требуется специальный штат сотрудников, занимающихся установкой, сопровождением системы, формированием представлений данных для конечных пользователей. Примеры: Essbase компании Arbor Software [31], Oracle Express Server компании Oracle. Наиболее мощным (и самым дорогим) представителем данного класса является SAS System компании SAS Institute. SAS System состоит из множества подсистем-модулей, которые позволяют проектировать готовые решения – расширенные административные ИС, дополненные функциями OLAP и ИАД. Благодаря такому подходу достигается компромисс между гибкостью настройки и простотой использования: разработкой СППР занимаются администраторы на этапе проектирования, а аналитики работают с адаптированной для них системой.

2. Реляционные OLAP (Relational OLAP, ROLAP) возникли после программной статьи Кодда 1993 г. Осуществляют представление данных, хранимых в классической реляционной базе, в многомерной форме. Примеры: DSS/Server и DSS/Agent компании MicroStrategy, MetaCube компании Informix, DecisionSuite компании Information Advantage и другие. ROLAP-системы хорошо приспособлены для работы с крупными хранилищами. Подобно системам первого класса, они требуют значительных затрат на обслуживание и предусматривают многопользовательский режим работы.

3. Гибридные OLAP (Hybrid OLAP, HOLAP) разрабатывались с целью совмещения достоинств и минимизации недостатков, присущих предыдущим классам. Такие продукты ориентированы на работу и с реляционными, и с многомерными ХД. Подразумевается, что детализированные данные хранятся в РСУБД, а агрегированные – в МСУБД.

4. Инструменты генерации запросов и отчетов для настольных ПК, дополненные функциями OLAP и/или интегрированные с внешними средствами, выполняющими такие функции. Эти системы осуществляют выборку данных из источников, преобразуют их и помещают в динамическую многомерную БД, функционирующую на клиентской станции конечного пользователя. Для работы с небольшими, просто организованными базами эти средства подходят наилучшим образом. Примеры: BusinessObjects одноименной компании, BrioQuery компании Brio Technology, PowerPlay компании Cognos.

4.3.3.3. История продуктов OLAP. Основные производители

Таблица 12 – История продуктов OLAP. Основные производители

Год	Событие	Комментарий
1970	Появился Express	Первый многомерный продукт, ориентированный на рыночные приложения; ныне – собственность компании Oracle.
1982	Comshare System W выпущен на собственной ЭВМ.	Первым использовал идею гиперкуба и был в большей степени ориентирован на финансовые приложения. Новые концепции (не проработанные): непроцедурных правил, полноэкранного просмотра многомерных данных, редактирования данных, автоматическое перевычисление, интеграция с реляционными данными (в пакетном режиме). Недостатки: высокие аппаратные требования, низкая настраиваемость. В настоящее время существует Comshare Commander Prism для Windows, основанный на принципах System W.
1984	Запущен Metaphor	Первый ROLAP. Предназначался для профессиональных маркетологов. Новые концепции: клиент-серверные вычисления, многомерная обработка реляционных данных, многопользовательский режим, объектно ориентированная разработка приложений. Недостатки: специфические требования к аппаратному обеспечению (фактически не работал на серийных ЭВМ), высокая стоимость.
1985	Выпущен Pilot Command Center	Первая клиент-серверная ИС руководителя (EIS); использовалась на серверах VAX и стандартных PC в качестве клиента. Предложенные концепции: многомерные клиент-серверные вычисления; автоматическая поддержка времени.
1990	Cognos PowerPlay	Первый OLAP для Windows и первый настольный OLAP.
1992	Выпущен Essbase	Первый OLAP продукт, имеющий хороший рынок. В 1997 году стал лидером рынка среди OLAP серверов.
1993	Напечатана статья Кодда с определением OLAP	Эта статья, инициированная компанией Arbor Software, привлекла внимание многих людей к многомерному анализу. Однако, правила Кодда для OLAP были вскоре забыты (в отличие от влиятельных и уважаемых правил для реляционных баз данных).
1994	MicroStrategy DSS Agent	Первый ROLAP без многомерной СУБД, почти вся обработка выполняется с помощью SQL-запросов.
1995	Создан Holos 4.0	Первый гибридный OLAP (HOLAP). Многие другие OLAP продукты сегодня используют этот подход. Holos сегодня является собственностью Seagate, его проявления на рынке затухают.
1995	Oracle приобретает Express	Именно это событие считают причиной качественного изменения статуса OLAP на мировом рынке.
1996	BusinessObjects 4.0	Первый цельный инструмент, обеспечивающий формирование многомерных и реляционных отчетов из настольного куба, динамически создаваемого из реляционных данных.
1997	Microsoft объявляет об OLE DB для OLAP	Этот проект имел условное название "Tensor" и стал "промышленным стандартом" по OLAP API прежде чем какой-либо продукт стал его поддерживать. Множество компаний сегодня разрабатывают продукты, используя его.
1998	Создан IBM DB2 OLAP Server	Поддерживает реляционные структуры данных типа "звезда", сохраняемые как в DB2, так и в другой реляционной базе данных.
1998	Сформирован Hyperion Solutions	Arbor и Hyperion Software слились в первую большую консолидацию на рынке OLAP.
1999	Выпущен Microsoft OLAP Services	Этот проект имел условное название "Plato" и использовал технологию, купленную у Panorama Software Systems в 1996 году. Смешанная архитектура хранения данных (ROLAP/MOLAP/Hybrid).
2007	Oracle приобрела Hyperion
2007	SAP приобрела BusinessObjects
2008	IBM приобрела Cognos
2011	Выпущен комплекс Oracle Exalytics	Сервер аналитической обработки на основе Essbase и Timesten

Современное состояние OLAP:

1. Возможности современного аппаратного обеспечения снижают определяющую роль недостатков MOLAP.

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

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

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

Последствия неправильного выбора:

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

б) более типичен случай, когда некоторая часть проекта оказывается работоспособной, в результате чего виновники имеют возможность характеризовать результат как "успешный", что способствует потере стимула дальнейшего развития в этом направлении; для стратегического развития предприятия последствия могут быть более тяжелыми, чем в первом случае;

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

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

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

1. Необходимо понять:

   1. основные информационные процессы, осуществляемые пользователями;

   2. основные алгоритмы их работы;

   3. умения, знания, навыки пользователей;

   4. наличествующая необходимость в новых знаниях и алгоритмах.

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

3. На данной стадии требовать от пользователей только самого обобщенного описания самых основных потребностей.

4. Не принимать никаких структурных решений до понимания потребностей бизнеса.

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

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

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

1. Объемы входной информации, в том числе планируемые.

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

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

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

5. Интегрирование: связь с другими системами, типа электронной почты, информационных хранилищ (data warehouses), систем "добычи данных" (data mining) и т.д.

6. Число пользователей и их размещение: воздействие архитектуры, секретность, расходы.

7. Вид пользователя: высшее руководство, финансы, маркетинг, продажи, производство и т.д.

8. Опыт подразделений внедрения и разработки: Excel, VB, JavaScript, Java, SQL, ETL, EIS, Web, проектирование многомерных баз данных и т.д

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

10. Платформа сервера: NT, Unix, AS/400, Linux.

11. Стандарты клиентской части и браузера.

12. Разворачиваемая архитектура: локальная сеть и модемная связь, высокоскоростной клиент/сервер, intranet, Internet.

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

14. Бюджет: программное обеспечение, аппаратные средства, услуги, передача данных.

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

1. Следует анализировать степень предвзятости рекомендаций перед их использованием. Основные недостатки рекомендателей: материальная заинтересованность, неосведомленность.

2. Список требований следует подвергать "фильтрации". Слишком большой список сокращает возможности выбора.

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

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

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

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

1. Неуниверсальность большинства продуктов, несмотря на заявления производителей:

   1. интегрируемость не со всеми приложениями сторонних фирм;

   2. зависимость относительной эффективности от объемов данных;

   3. зависимость относительной эффективности от числа пользователей;

   4. преимущественная ориентация на работу в глобальных или в локальных сетях.

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

3. Неверное понимание интегрируемости продуктов покупателями. Продукты какого-либо производителя не обязательно совместимы между собой.

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

5. Опасность игнорирования новых продуктов в случае установления долгосрочного стандарта.

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