Инструментальные средства построения комплексов моделей и аналитических приложений в olap-технологии (стр. 2 )

В 1993 году по инициативе компании Arbor Software (сегодня это Hyperion Solutions) Доктор Кодд с партнерами опубликовали статью «Обеспечение OLAP для пользователей - аналитиков», которая объединила основные положения информационной технологии. Сформулированные в статье требования к OLAP-технологии оказались достаточно спорными, так как не имели строгого математического обоснования. Первая статья включала двенадцать правил, а затем в 1995-м году к ним были добавлены еще шесть. Доктор Кодд разбил правила на четыре группы, назвав их "особенностями" [6].

Рассмотрим суть OLAP-технологии путем краткого обзора этих особенностей.

Основные особенности (Basic):

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

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

3.  Доступность. Особенно подчеркивается роль OLAP в качестве прослойки между гетерогенными источниками данных и представлением для конечного пользователя.

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

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

6.  Архитектура "клиент-сервер". Необходимо чтобы продукт был не только архитектуры «клиент-сервер», но и чтобы серверный компонент был интеллектуальным, для того чтобы различные клиенты могли подключаться к нему с минимумом усилий и программирования.

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

8.  Многопользовательская поддержка. Часто для выполнения аналитических задач необходимо одновременное использование одной и той же аналитической модели или данных предприятия. OLAP-инструменты должны обеспечивать одновременный доступ (извлечение и изменение), целостность и безопасность.

Специальные особенности (Special)

9.  Обработка ненормализованных данных. Необходима интеграция между OLAP-машиной и денормализованными источниками данных.

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

11.  Извлечение отсутствующих значений. Все отсутствующие значения должны преобразовываться к единообразному представлению, определенному в реляционной модели версии 2 [7].

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

Особенности представления отчетов (Report)

13.  Гибкость формирования отчетов. Измерения могут быть размещены в аналитическом отчете так, как это нужно пользователю.

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

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

Управление измерениями (Dimension)

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

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

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

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

Правила Кодда не дают четкого определения, что именно считать OLAP, и в связи с этим в 1995 году ассоциацией OLAP Report был сформирован так называемый тест «FASMI» [18]. При его формировании ключевым моментом была простота, легкость запоминания и независимость теста от продукта. FASMI означает – Fast Analysis of Shared Multidimensional Information (быстрый анализ разделенной многомерной информации).

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

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

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

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

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

Некоторые производители OLAP-продуктов, такие как Microsoft, IBM и Oracle, пытаются утвердить в качестве стандарта свои технологии доступа к многомерной информации. Компания Microsoft разработала технологию OLE DB for OLAP и язык многомерных запросов MDX. В 2000 году группа компаний, в числе которых Hyperion, IBM и Oracle, объявили о начале разработки нового платформенно-независимого стандарта создания, хранения, доступа и обслуживания данных в OLAP-серверах - JOLAP, основанного на технологии Java. Однако ни одна из указанных технологий к настоящему времени так и не стала стандартом. Скорее всего, из-за разногласий среди крупных производителей, в ближайшей перспективе единого OLAP-стандарта не появится.

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

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

Интеграция с хранилищами данных позволяет расширить как возможности самой системы анализа, так и возможности систем хранения данных. Для аналитической системы интеграция с хранилищами данных дает возможность сохранения результатов промежуточных расчетов, схем данных, моделей представления анализируемой информации и отчетных форм [53, 81].

Кроме того, аналитическая система должна обладать прозрачным механизмом доступа к информации, содержащейся как в промышленных СУБД, таких как Oracle, MS SQL, Sybase ASA/ASE, Interbase/Firebird, так и настольных вроде MS Access, MS Excel, dBase, Paradox и пр.

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

1.3 Обзор технологических подходов и программных решений для оперативной аналитической обработки

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

Все OLAP-продукты можно условно поделить на OLAP-сервера (server OLAP) и настольные OLAP-системы (desktop OLAP) [15]. OLAP-сервера используются как хранилища многомерной информации и осуществляют быструю навигацию и выборку данных по запросам. Доступ пользователя к информации при этом осуществляется только через заранее подготовленные многомерные кубы. Настольные OLAP-системы являются инструментарием пользователей-аналитиков, а источником информации могут выступать как многомерные, так и реляционные базы данных. Часто настольные системы могут предоставлять пользователю возможность самостоятельного проектирования многомерных кубов.

OLAP-серверы

Microsoft Analysis Services [http://www. /sql/] – является самостоятельным OLAP-сервером фирмы Microsoft, позволяющим создавать и управлять многомерными кубами. Для хранения кубов можно выбрать различные варианты: в реляционных, многомерных и гибридных структурах. Для работы с готовыми кубами на клиентских местах можно использовать как средства фирмы Microsoft, входящие в состав пакета Microsoft Office, так и множество сторонних разработок, в том числе российских, например DigitalDesign фирмы DigDes (г. Санкт-Петербург).

Аналитические средства фирмы Oracle, имеющие общее название Oracle Express [htpp://www. ], представляют собой средства интеграции реляционных и многомерных данных, а также средства разработки аналитических приложений, позволяющих осуществлять моделирование, прогнозирование и статистический анализ (в том числе в области бизнеса). Ключевым компонентом этого набора продуктов является OLAP-сервер Oracle Express Server.

Разработка приложений может производиться с помощью Oracle Express Objects [27] — объектно-ориентированного графического средства для создания приложений на базе Express Server. Oracle Express Analyzer представляет собой клиентское средство, позволяющее обращаться к Oracle Express Objects и расширять функциональность. Для выполнения аналитических запросов и осуществления поиска закономерностей может применяться средство Oracle Discoverer, а для создания отчетов — Oracle Reports Developer.

Помимо собственно OLAP-сервера, средств доступа к OLAP-данным и средства разработки BI-приложений, Oracle поставляет ряд готовых BI-решений на их основе, в частности Oracle Financial Analyzer, Oracle Sales Analyzer, Oracle Demand Planning.

PowerPlay Enterprise Server фирмы Cognos [www. ] – сервер многомерной базы данных, позволяющий просматривать заранее подготовленные кубы и отчеты. Сами кубы и отчеты формируются входящей в состав пакета поставки утилитой Transformer. В качестве интернет-сервера система использует Internet Information Server фирмы Microsoft. Для формирования произвольных оперативных запросов необходимо использовать дополнительное программное обеспечение – Cognos Impromptu.

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

Настольные OLAP-системы

Business Objects [56] является лидером среди компаний, занимающихся настольными OLAP-системами. Фирма выпускает одноименный продукт, разделенный на ряд составляющих. Инструмент Designer предназначен для построения так называемых Universes, которые представляют собой набор бизнес-объектов, построенных на основе произвольной схемы данных, которая ссылается на объекты реляционной СУБД. Для построения произвольных запросов и поиска закономерностей (data mining) существуют инструменты BusinessObjects и BusinessMiner, которые при работе обращаются к заранее подготовленным Universe. Недостатками продукта является высокая цена, а также четкое разделение задач дизайнера и аналитика.

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

Другим значащим разработчиком на российском рынке является кампания Intersoft Lab [57], выпускающая продукты серии Contour. Линейка продуктов состоит из средств формирования кубов «Контур Дизайнер кубов» и «Контур Генератор кубов» и средств просмотра кубов «Контур Стандарт» и «Контур OLAPBrowser». Помимо недостатков, свойственных пакету Deductor фирмы BaseGroup, линейка Contour обладает гораздо меньшими аналитическими возможностями: отсутствуют средства статистического и нейросетевого анализа, средства очистки, прогнозирования и поиска закономерностей.

OLAP-компоненты

Для разработки настольных OLAP-систем рядом производителей выпускаются специальные библиотеки, включающие средства хранения многомерной информации, а также средства ее представления в кросс-таблицах и диаграммах. В ходе диссертационного исследования проведен обзор и сравнение этих библиотек, результаты которого представлены в таблице 1 (более широкое сравнение, в том числе с разработанными OLAP-компонентами представлены в приложении 1). В обзор включены решения, предлагаемые для создания настольных OLAP-приложений от фирмы Borland – Decision Cube, входящий в пакет разработки приложений Borland Delphi, фирмы Microsoft – Pivot Table, входящий в состав Microsoft Office, а также самостоятельные библиотеки фирмы Data Dynamics [http://] и разработку российского производителя Intersoft Lab – Countour Cube [57, http://].

Таблица 1 – Сравнение библиотек OLAP-компонент

	Библиотека	Decision Cube (Borland)	Pivot Table (Microsoft)	DynamiCube (Data Dynamics)	Contour Cube (Intersoft lab)
Функция
Одновременная фильтрация нескольких значений	–	+	+	+
Фильтрация по N лучшим / худшим	–	+	–	–
Скрытие незначащих строк/столбцов	–	–	–	+
Скрытие произвольной строки	–	+	–	–
Детализация / группировка значения измерения	–	+	+	+
Наличие статистических функций агрегации показателей	–	+	+	+
Одновременный расчет нескольких показателей	–	+	+	+
Построение вычисляемых показателей	–	+	+	+
Процентное представление показателей	–	+	+	+
Выделение исключительных значений показателей	–	–	+	–
Сортировка по значению показателя	–	+	–	+
Сохранение куба	–	–	+	+
Экспорт в Excel, HTML	–	–	+	+
Детализация до исходных данных (плоских)	–	+	–	–
Ранжирование	–	–	+	+
Автоматический расчет итогов для выделенной области данных	–	+	–	–
Скорость на Celleron 800/128: 1. открытия выборки в 150000 записей 2. построение плоского представления из 2 измерений 3. расчет факта	не удалось дождаться результата	не удалось дождаться результата	1 + 3 = 180 сек. 2. 270 сек. Суммарно 450 с	1 + 2 +3 за 40 сек. Суммарно 40 с
Скорость на P4 2400/512	не удалось дождаться результата	не удалось дождаться результата	не удалось дождаться результата	1+2+3 за 23,5 с

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