- 1 августа 1998 г.
Архитектуры OLAP
На этот раз рубрика "Технологии OLAP и DWH" посвящена архитектурам OLAP. В
первой из статей рассмотрены виды архитектур. Несмотря на то, что этому
материалу уже больше двух лет, основные положения остались прежними. Главным
образом, слегка устарела классификация. Так, сегодня уже существует однозначное
разделение систем класса OLAP-клиент и настольный OLAP. Кроме того, некоторые
фирмы переходят или уже перешли к выпуску новых OLAP-продуктов. Так, Oracle
закрывает рассмотренный в этой статье проект Oracle Express и переходит на
другое архитектурное решение, а компания Cognos, помимо описанного здесь
настольного OLAP, сейчас имеет еще и продукт класса OLAP-клиент для реляционных
БД и OLAP серверов других производителей. Права на OLAP-сервер Essbase перешли
от Arbor к Hiperion Solutions.
В связи с радикальным повышением мощности компьютеров меньшее значение стало
придаваться хранению данных в многомерных базах и предварительному вычислению
агрегатов. Например, по имеющейся у нас непроверенной информации OLAP Service
Oracle 9 уже не является МСУБД, а по видимому будет ROLAP-надстройкой над
реляционным сервером. Все большее распространение получают OLAP-клиенты к
РСУБД, вычисления в которых достаточно эффективно выполняются на современных
мощных клиентских компьютерах.
Успешная компания сегодня должна принимать множество различных решений. И чем более обоснованные решения будут приняты, тем большего успеха и прибыли достигнет предприятие. Для многих лиц, играющих ключевую роль в принятии решений, способность быстрее и эффективнее конкурента анализировать бизнес-процессы означает принятие более правильных решений, достижение большей прибыльности и большего успеха. Оптимизация реляционной базы данных предоставила компаниям возможность продуктивно собирать данные о транзакциях, поставляя информации лицам, принимающим решения. Тем не менее, имеется верхний предел объема данных, который может содержаться в реляционной базе данных, при котором еще сохраняется возможность достаточно эффективно осуществлять анализ.
OLAP позволяет выполнять быстрый и эффективный анализ над большими объемами данных. Данные хранятся в многомерном виде, что наиболее близко отражает естественное состояние реальных бизнес-данных. Кроме того, OLAP предоставляет пользователям возможность быстрее и проще получать сводные данные. С его помощью они могут при необходимости углубляться (drill down) в содержимое этих данных для получения более детализированной информации.
В данной статье рассмотрены системы хранения данных, архитектуры OLAP и определены типы бизнес-структур, которые существенно выигрывают от применения возможностей OLAP. При этом в статье проанализированы лидеры рынка OLAP и дан обзор соответствующих продуктов и/или линеек продуктов. Эти темы дополнены рассмотрением технологий Data Mining и Хранилищ данных.
Компоненты OLAP-систем
OLAP-система состоит из множества компонент. На самом высоком уровне представления система включает в себя источник данных, OLAP-сервер и клиента. Источник данных представляет собой источник, из которого берутся данные для анализа. Данные из источника переносятся или копируются на OLAP-сервер, где они систематизируются и подготавливаются для более быстрого впоследствии формирования ответов на запросы. Клиент - это пользовательский интерфейс к OLAP-серверу. В этом разделе статьи описываются функции каждой компоненты и значение всей системы в целом.
Источники
Источником в OLAP-системах является сервер, поставляющий данные для анализа. В зависимости от области использования OLAP-продукта источником может служить Хранилище данных, наследуемая база данных, содержащая общие данные, набор таблиц, объединяющих финансовые данные или любая комбинация перечисленного. Способность OLAP-продукта работать с данными из различных источников очень важна. Требование единого формата или единой базы, в которых бы хранились все исходные данные, не подходит администраторам баз данных. Кроме того, такой подход уменьшает гибкость и мощность OLAP-продукта. Администраторы и пользователи полагают, что OLAP-продукты, обеспечивающие извлечение данных не только из различных, но и из множества источников, оказываются более гибкими и полезными, чем те, что имеют более жесткие требования.
Сервер
Прикладной частью OLAP-системы является OLAP-сервер. Эта составляющая выполняет всю работу (в зависимости от модели системы), и хранит в себе всю информацию, к которой обеспечивается активный доступ. Архитектурой сервера управляют различные концепции. В частности, основной функциональной характеристикой OLAP-продукта является использование для хранения данных многомерной (ММБД, MDDB) либо реляционной (РДБ, RDB) базы данных. Этот раздел описывает "за" и "против" каждого из этих подходов.
MOLAP
MOLAP - это Multidimensional On-Line Analytical Processing, то есть Многомерный OLAP. Это означает, что сервер для хранения данных использует ММБД. Поскольку большинство OLAP-продуктов основаны на МДБД, под OLAP часто понимают также и MOLAP.
Смысл использования ММБД очевиден. Она может эффективно хранить многомерные по своей природе данные, обеспечивая средства быстрого обслуживания запросов к базе данных. Данные передаются от источника данных (как это описано выше) в многомерную базу данных, а затем база данных подвергается агрегации. Предварительный расчет - это то, что ускоряет OLAP-запросы, поскольку расчет сводных данных уже произведен. Время запроса становится функцией исключительно времени, необходимого для доступа к отдельному фрагменту данных и выполнения расчета. Этот метод поддерживает концепцию, согласно которой работа производится единожды, а результаты затем используются снова и снова. Многомерные базы данных являются относительно новой технологией. Использование ММБД имеет те же недостатки, что и большинство новых технологий. А именно - они не так устойчивы, как РБД, и в той же мере не оптимизированы. Другое слабое место ММБД заключается в невозможности использовать большинство многомерных баз в процессе агрегации данных, поэтому требуется время для того, чтобы новая информация стала доступна для анализа.
"Взрыв" базы данных
"Взрыв" базы данных представляет собой феномен многомерных баз. Несмотря на то, что эта проблема исследовалась специалистами, тем не менее, трудно объяснить, почему и как это происходит. Представляется, что это связано с разреженностью базы данных и предварительной агрегацией данных. Если многомерная база данных содержит небольшое число элементов данных, сравнимое с количеством обеспечиваемых ею уровней агрегации, каждый фрагмент данных будет вносить больший вклад во все получаемые из него данные. Когда база данных "взрывается", размер ее становится существенно больше, чем он должен быть.
Сложно определить условия "взрыва" базы данных или предсказать, "взорвется" ли некая конкретная структура. Одним из подходов, который, похоже, может помочь решить проблему "взрыва", является динамическое управление разреженными данными. Эта методика позволяет анализировать свои собственные модели хранения и оптимизировать их с целью предотвращения "взрыва" базы данных.
Таблица 1. Многомерные базы данных
За | Против |
Точно моделируют бизнес-данные | Как правило, не могут грамотно управлять очень большими базами данных |
Обеспечивают быстрый доступ без SQL | Представляют собой новую, и, поэтому, еще не оптимизированную технологию |
Содержат заранее рассчитанные сводные данные | Имеют риск "взрыва" |
ROLAP
ROLAP - это Relational On-Line Analytical Processing, то есть Реляционный OLAP. Термин ROLAP обозначает, что OLAP-сервер базируется на реляционной базе данных. Исходные данные вводятся в реляционную базу данных, обычно по схеме "звезда" или схеме "снежинка", что способствует сокращению времени извлечения. Сервер обеспечивает многомерную модель данных с помощью оптимизированных SQL-запросов.
Существует ряд причин для выбора именно реляционной, а не многомерной базы данных. РБД - это хорошо отработанная технология, имеющая множество возможностей для оптимизации. Использование в реальных условиях дало в результате более проработанный продукт. К тому же, РБД поддерживают более крупные объемы данных, чем ММБД. Они как раз и спроектированы для таких объемов. Основным аргументом против РБД является сложность запросов, необходимых для получения информации из большой базы данных с помощью SQL. Неопытный SQL-программист мог бы с легкостью обременить ценные системные ресурсы попытками выполнить какой-нибудь подобный запрос, который в ММБД выполняется гораздо проще.
Таблица 2. Реляционные базы данных
За | Против |
Идеальны для больших объемов данных | Для сложных запросов SQL не является оптимальным |
Отработанная, оптимизированная технология | Определение оптимальной схемы хранения данных представляется более трудным и важным делом |
Агрегированные/Предварительно агрегированные данные
Быстрая реализация запросов является императивом для OLAP. Это один из базовых принципов OLAP - способность интуитивно манипулировать данными требует быстрого извлечения информации. В целом, чем больше вычислений необходимо произвести, чтобы получить фрагмент информации, тем медленнее происходит отклик. Поэтому, чтобы сохранить маленькое время реализации запросов, фрагменты информации, обращение к которым обычно происходит наиболее часто, но которые при этом требуют вычисления, подвергаются предварительной агрегации. То есть они подсчитываются и затем хранятся в базе данных в качестве новых данных. В качестве примера типа данных, который допустимо рассчитать заранее, можно привести сводные данные - например, показатели продаж по месяцам, кварталам или годам, для которых действительно введенными данными являются ежедневные показатели.
Различные поставщики придерживаются различных методов отбора параметров, требующих предварительной агрегации и числа предварительно вычисляемых величин. Подход к агрегации влияет одновременно и на базу данных и на время реализации запросов. Если вычисляется больше величин, вероятность того, что пользователь запросит уже вычисленную величину, возрастает, и поэтому время отклика сократиться, так как не придется запрашивать изначальную величину для вычисления. Однако, если вычислить все возможные величины - это не лучшее решение - в таком случае существенно возрастает размер базы данных, что сделает ее неуправляемой, да и время агрегации будет слишком большим. К тому же, когда в базу данных добавляются числовые значения, или если они изменяются, информация эта должна отражаться на предварительно вычисленных величинах, зависящих от новых данных. Таким образом, и обновление базы может также занять много времени в случае большого числа предварительно вычисляемых величин. Поскольку обычно во время агрегации база данных работает автономно, желательно, чтобы время агрегации было не слишком длительным.
Клиент
Клиент - это как раз то, что используется для представления и манипуляций с данными в базе данных. Клиент может быть и достаточно несложным - в виде таблицы, включающей в себя такие возможности OLAP, как, например, вращение данных (пивотинг) и углубление в данные (дриллинг), и представлять собой специализированное, но такое же простое средство просмотра отчетов или быть таким же мощным инструментом, как созданное на заказ приложение, спроектированное для сложных манипуляций с данными. Интернет является новой формой клиента. Кроме того, он несет на себе печать новых технологий; множество интернет-решений существенно отличаются по своим возможностям в целом и в качестве OLAP-решения - в частности. В данном разделе обсуждаются различные функциональные свойства каждого типа клиентов.
Несмотря на то, что сервер - это как бы "хребет" OLAP-решения, клиент не менее важен. Сервер может обеспечить прочный фундамент для облегчения манипуляций с данными, но если клиент сложен или малофункционален, пользователь не сможет воспользоваться всеми преимуществами мощного сервера. Клиент настолько важен, что множество поставщиков сосредотачивают свои усилия исключительно на разработке клиента. Все, что включается в состав этих приложений, представляет собой стандартный взгляд на интерфейс, заранее определенные функции и структуру, а также быстрые решения для более или менее стандартных ситуаций. Например, популярны финансовые пакеты. Заранее созданные финансовые приложения позволят специалистам использовать привычные финансовые инструменты без необходимости проектировать структуру базы данных или общепринятые формы и отчеты.
Инструмент запросов/Генератор отчетов
Инструмент запросов или генератор отчетов предлагает простой доступ к OLAP-данным. Они имеют простой в использовании графический интерфейс и позволяют пользователям создавать отчеты перемещением объектов в отчет методом "drag and drop". Тогда как традиционный генератор отчетов предоставляет пользователю возможность быстро выпускать форматированные отчеты, генераторы отчетов, поддерживающие OLAP, формируют актуальные отчеты. Конечный продукт представляет собой отчет, имеющий возможности углубления в данные до уровня подробностей, вращения (пивотинг) отчетов, поддержки иерархий и др.. Add-Ins (дополнения) электронных таблиц.
Сегодня во многих направлениях бизнеса с помощью электронных таблиц производятся различные формы анализа корпоративных данных. В каком-то смысле это идеальное средство создания отчетов и просмотра данных. Аналитик может создавать макросы, работающие с данными в выбранном направлении, а шаблон может быть спроектирован таким образом, что, когда происходит ввод данных, формулы рассчитывают правильные величины, исключая необходимость неоднократного ввода простых расчетов. Тем не менее, все это дает в результате "плоский" отчет, что означает, что как только он создан, трудно рассматривать его в различных аспектах. Например, диаграмма отображает информацию за некоторый временной период, - скажем, за месяц. И если некто желает увидеть показатели за день (в противоположность данным за месяц), необходимо будет создать абсолютно новую диаграмму. Предстоит определить новые наборы данных, добавить в диаграмму новые метки и внести множество других простых, но трудоемких изменений. Кроме того, существует ряд областей, в которых могут быть допущены ошибки, что в целом уменьшает надежность. Когда к таблице добавляется OLAP, появляется возможность создавать единственную диаграмму, а затем подвергать ее различным манипуляциям с целью предоставления пользователю необходимой информации, не обременяя себя созданием всех возможных представлений.
Интернет в роли клиента
Новым членом семейства OLAP-клиентов является Интернет. Существует масса преимуществ в формировании OLAP-отчетов через Интернет. Наиболее существенным представляется отсутствие необходимости в специализированном программном обеспечении для доступа к информации. Это экономит предприятию кучу времени и денег.
Каждый Интернет-продукт специфичен. Некоторые упрощают создание Web-страниц, но имеют меньшую гибкость. Другие позволяют создавать представления данных, а затем сохранять их как статические HTML-файлы. Все это дает возможность просматривать данные через Интернет, но не более того. Активно манипулировать данными с их помощью невозможно. Существует и другой тип продуктов - интерактивный и динамический, превращающий такие продукты в полнофункциональные инструменты. Пользователи могут осуществлять углубление в данные, пивотинг, ограничение измерений, и др. Прежде, чем выбрать средство реализации Интернет, важно понять, какие функциональные возможности требуются от Web-решения, а затем определить, какой продукт наилучшим образом воплотит эту функциональность.
Приложения
Приложения - это тип клиента, использующий базы данных OLAP. Они идентичны инструментам запросов и генераторам отчетов, описанным выше, но, кроме того, они вносят в продукт более широкие функциональные возможности. Приложение, как правило, обладает большей мощностью, чем инструмент запроса.
Разработка
Обычно поставщики OLAP обеспечивают среду разработки для создания пользователями собственных настроенных приложений. Среда разработки в целом представляет собой графический интерфейс, поддерживающий объектно-ориентированную разработку приложений. К тому же, большинство поставщиков обеспечивают API, который может использоваться для интеграции баз данных OLAP с другими приложениями.
Архитектуры OLAP
MOLAP
Сегмент рынка, принадлежащий многомерным базам данных, связан с компаниями, основным продуктом которых являются машины баз данных. Они не обязательно озабочены тем, какие инструменты будет применять пользователь для того, чтобы манипулировать информацией, содержащейся в базе данных (т.е. клиентом), они просто обеспечивают мощный сервер для того, чтобы пользователь мог самостоятельно построить собственные настроенные приложения или приобрести готовые приложения у другого поставщика. Тем не менее, деятельность ряда производителей охватывает одновременно и клиентскую и серверную области MDDB/Application OLAP.
ROLAP
Реляционному OLAP отводится наименьший сегмент рынка. Поставщики, работающие в данной области, создают OLAP-продукты, использующие реляционную базу данных для хранения многомерных кубов.
Прикладной OLAP
Безусловно, это самая большая область, и это, в общем-то, то, с чем обычно связывают и что обычно понимают под термином "OLAP". Прикладной OLAP, как правило, состоит из многомерных баз данных, доступ к которым происходит через конкретное приложение, или, возможно, через множество приложений. Поставщики в данной области рынка в основном предлагают клиенты для базы данных. Клиент может быть как простым средством просмотра, так и более мощным приложением.
Настольный OLAP
Представителями настольного OLAP являются продукты, необязательно соединяющиеся с сервером. Они могут запускаться в основном на клиентской части, хотя данные в форме куба данных могут загружать и с сервера. Тот факт, что куб данных строится и хранится на машине пользователя, позволяет рекомендовать их тем, кто часто использует портативные компьютеры или кто нечасто запускает настолько сложные отчеты, что для их формирования необходима более высокая скорость клиента, а, следовательно, и более мощный сервер для ее обеспечения.
Поставщики и обзор продуктов
Различные поставщики реализуют OLAP на основе собственных корпоративных представлений о том, что должно входить в идеальный OLAP-продукт. Поставщики, рассмотренные ниже, придерживались различных подходов, включая и те, что основаны на многомерной базе данных, реляционной базе данных и приложениях, добавляющих возможности OLAP на различные уровни.
Процесс их реального функционирования может служить количественным параметром при рассмотрении различных теоретических подходов к OLAP. С этой целью OLAP Council разработал аттестационную задачу APB-1 для количественного сравнения работы различных OLAP-продуктов. OLAP Council представляет собой консорциум, образованный несколькими поставщиками OLAP для поддержки ключевых принципов OLAP. В общем, принципы признают, что OLAP является важнейшей технологией для обеспечения корпоративных аналитиков инструментами, требующимися для выполнения необходимого им анализа. В апреле 1996 г. была выпущена первая аттестационная задача в области OLAP - APB-1.
Контрольная задача определяет параметры базы данных и устанавливает набор из 10 запросов, отражающих нормальное использование. Поставщик OLAP создает подходящую базу данных и затем запускает запросы. Отдельное измерение - AQT (среднее время запроса, Average Query Time), генерируется на основе времени, которое затрачивается на загрузку базы данных, агрегацию данных и последующий запуск запросов. Правила определяют, что легально и что нелегально - например, нужно ли рассчитывать заранее значения данных, какие из рассчитанных величин могут храниться и др.
Хотя результаты APB-1 и могут пригодиться при определении того, способен ли продукт выполнять ту или иную задачу, в качестве единиц измерения общей применимости продукта они далеки от идеала. Аттестационная задача запускается только поставщиками, создающими OLAP-серверы, поскольку эта задача относится именно к серверу. Для завершения аттестации APB-1 необходимо, чтобы поставщик опубликовал отчет, в котором отражена специфика ее прохождения. Это подразумевает аппаратное обеспечение, информацию о версии OLAP-сервера и клиента, операционную систему и т.д. Эта информация должна быть использована для определения допустимости AQT (результата аттестации). Например, AQT может оказаться совершенно вне конкуренции, однако аппаратная часть может оказаться неосуществимой в данных конкретных условиях бизнеса.
Ниже, при обсуждении поставщиков везде, где возможно, приведена информация по результатам аттестации и ценам.
MOLAP
Oracle
Oracle является лидером в данной области бизнеса, в 1996 году ему принадлежала доля в 20,7%. Oracle приобрел Express у IRI Software в 1995 году. Линейка продуктов Express (прим перев. - который в настоящее время компания планирует закрыть, перейдя на другое архитектурное решение - Oracle Services) представляет собой корпоративный подход Oracle к OLAP, включая сервер, клиентскую часть, возможности ROLAP и Интернет-решения.
Сервер:
На момент написания этой статьи существовало два OLAP-серверных продукта Oracle. Express Server был главной OLAP-машиной для Oracle. Он предоставлял многомерную базу данных и являлся машиной для других OLAP-продуктов фирмы. К тому же, Oracle предлагает Personal Express - локально работающий сервер Express. Он предоставляет пользователям доступ и возможность работать с базой данных в автономном режиме. Все это идеально подходит для мобильных компьютеров.
Главной особенностью Express Server является способность использовать разнообразные источники данных. Данные для многомерной базы данных могут собираться из реляционной базы (при помощи Express Relational Access Manager), многомерной базы, табличного или плоского файла.
APB-1: На плотности данных 0.1: Общее время загрузки 10:43 (минуты:секунды), Общее время для 250,000 запросов: 20:15. Общее затраченное время: 30:58. (18 марта 1998 г.[ORC1])
Администрирование:
Администрирование и обслуживание базы данных Express производится с помощью Express SPL (языка хранимых процедур, Stored Procedure Language). Процедуры созданы для определения измерений, стандартных программ извлечения, организации базы данных и различных других задач.
Разработка:
Пользователи могут разрабатывать собственные OLAP-приложения для Express с помощью Express Objects. Objects обеспечивают разработчикам графический интерфейс и объектно-ориентированный подход для создания приложений.
Кроме того, Express предлагает разработчикам API для различных способов доступа к базам данных Express.
Клиент:
Oracle обеспечивает множество путей доступа к базе данных. Express Analyzer содержит графический интерфейс к базе данных и позволяет пользователю легко формировать отчеты. Кроме того, Analyzer может иметь общие объекты с Express Objects, а также выпускать приложения, разработанные с их помощью. Discoverer наиболее точно можно описать как инструмент запросов к данным. Он проще, чем Analyzer, однако наиболее популярен среди средств запросов к данным. Помимо этого, Express содержит дополнительные таблицы, которые можно использовать совместно с Excel.
Приложения:
У Oracle существует два готовых приложения. Это Financial Analyzer и Sales Analyzer. Они используют машину и кэш данных Express Server, и содержат конфигурации отчетов, разработанные для нужд финансовых аналитиков и аналитиков продаж. Они полезны и пользователям, поскольку определяют важные функции, обычно участвующие в обоих видах анализа, который еще только будет реализован в Express Server (прим. перев. - на момент написания статьи).
Интернет:
Web Agent и Web Publisher - это средства создания интернет-ресурсов, предоставляемые Express. Используя любое из этих средств, пользователь может создать динамичный и интерактивный сайт, что обеспечивается применением различных возможностей OLAP. Web Agent в большей мере инструмент разработчика; он представляет собой набор предварительно определенных процедур, включенных в Express Server SPL. Сайты могут строиться так же, как строятся пользовательские интерфейсы к базе данных. Для конечного пользователя существует Web Publisher. Web Publisher сопряжен с Express Analyzer и имеет возможность для создания собственных интерактивных сайтов теми, кто не имеет серьезного программистского опыта. Web Publisher в основном является "мастером", который ведет пользователя через все этапы построения сайта и обеспечивает графический интерфейс для поддержки его создания. Он тоже может подвергаться настройке, хотя и не в такой степени, как Web Agent allows.
Arbor
Arbor Software Corporation - это главный соперник Oracle. Ее продуктом является Essbase, а самым последним его релизом на момент написания этой статьи был Essbase Server 5. Очень популярен сервер Arbor для различных OLAP-продуктов, что говорит о том, что многие поставщики OLAP и их продукты не обязательно выпускают полные приложения, а могут использовать в качестве базы данных Arbor (или другой продукт), и затем создавать интерфейсы к базе данных. В качестве примера можно привести Comshare и Web-компоненту от для Arbor - CrystalInfo, выпускаемую Seagate Software. В последнее время Arbor заключил партнерское соглашение с IBM. Многомерное хранение данных в Arbor Essbase Server будет заменено (прим. перев. - в настоящее время замена уже произведена) на DB2 от IBM. Предполагается, что это будет ROLAP-система, но фактически это не так. Это просто OLAP-система без одного из лучших свойств многомерных баз данных, но с преимуществами системы РБД. То есть, возможно, у вас не будет лучшего времени запроса, но зато вы сможете хранить больше данных, более полно использовать структуру РБД и в качестве языка для доступа к данным у вас будет SQL. Это хорошо, когда данным предстоит находиться в режиме совместного доступа с другими системами, построенными на основе SQL.
Server:
Последним на момент выпуска этой статьи был релиз OLAP-сервера Arbor Essbase 5.0. Arbor реализует разнообразные функции защиты, позволяя администраторам точно определять схемы доступа вплоть до уровня ячейки. К тому же, от пользователей может требоваться ввод пароля на чтение или чтение/запись некоторых данных. Для паролей может быть задан срок его использования или срок неактивности пользователя, по истечении которого пароль требует изменения. Эти свойства предоставляют администраторам возможность проводить гибкую политику защиты базы данных.
APB-1: AQT равен 0,0113 секунд/запрос. (11 марта 1998 [ARB1])
Essbase поддерживается на следующих платформах:
- Win95
- WinNT
- OS/2
- AS/400
- HP-UX
- IBM-AIX
- Sun Solaris
Инструменты:
В дополнение к таблицам Essbase Spreadsheet Add-in, обеспечивающих пользователей возможностями OLAP в рамках их таблиц, Arbor предлагает WIRED for OLAP (средство анализа и презентаций), Crystal Info for Essbase (генератор отчетов и расписаний) и SQL Drill-Through, позволяющий пользователям просматривать подробности данных в исходных реляционных базах.
Приложения:
Arbor не так давно выпустил Arbor Essbase Adjustment Module. Это приложение помогает пользователям в подготовке регулярно выпускаемых отчетов. Он способствует автоматизации форматирования отчетов и процессов расчета. Кроме того, существует еще Arbor Currency Conversion Module, способный конвертировать различные валюты в национальную на основе модели для отслеживания обменных курсов.
Разработка:
Essbase Objects является мощным средством разработки приложений для Essbase. Они содержат объектно-ориентированный подход к программированию OLAP, применяя сложный набор управляющих элементов 32-bit ActiveX. К числу замечательных свойств Essbase Objects относится возможность перекомпиляции его в оптимизированный код Essbase, и, следовательно, улучшения его выполнения. Essbase Extended Spreadsheet Toolkit также позволяет разработчикам строить на заказ приложения, расширяющие функциональность таблиц. И наконец, Arbor еще и выпускает API, предоставляющий разработчикам возможность встраивать базы данных Essbase в программы на языках C/C++ и Visual Basic.
Управление сервером:
Essbase Application Manager обеспечивает GUI для баз данных и приложений Essbase. Благодаря ему упрощается обслуживание и администрирование баз данных, объектов и приложений. Кроме того, существует SQL Interface, при помощи которого пользователи могут получать доступ к данным из реляционной базы и использовать их в Essbase Server.
Цена Essbase Servers начинается с $37 500.
ROLAP
MicroStrategy
В области ROLAP признанным лидером является компания MicroStrategy. Их философией является отсутствие ограничений на размер Хранилища данных, так что нет никаких проблем с его увеличением. Поскольку они являются производителями реляционного OLAP, уровень СППР достаточно высок. Сервер СППР представляется верным шагом в направлении Хранилищ данных.
У MicroStrategy нет OLAP-машины, которая могла бы работать локально, что неудобно для пользователей, часто работающих с ноутбуками или для тех, что просто предпочитает работать автономно. Тем не менее, у них существует продукт, DSS Broadcaster, позволяющий отсылать данные на различные выходные устройства. DSS Broadcaster отсылает данные по запросу или когда происходит определенное событие. Например, менеджеру может отсылаться ежедневное обновление с суммами прибыли за предыдущий день. Эта информация может поступать по электронной почте, на пейджер или мобильный телефон, а также по факсу.
Сервер:
DSS Server является центральным продуктом в линейке СППР. Это мощная машина, позволяющая другим агентам получать доступ к реляционной базе данных в многомерном режиме. DSS Server содержит разнообразные драйверы баз данных для оптимизации их под необходимую реляционную базу данных (они поддерживают Oracle, DB2, Sybase, Red Brick, Informix, и другие реляционные базы). К тому же, акцент делается на способность их роста и включает в себя драйвер для адаптации к Очень большим базам данных (Very Large Databases, VLDBs), размер которых превышает терабайт.
Природа реляционного OLAP-продукта (то есть требующего реляционной базы данных) ограничивает MicroStrategy в возможности предоставления действительно индивидуального сервера для автономной работы, однако с помощью DSS Agent (см. Клиент) набор данных может загружаться и анализ может выполняться и в автономном режиме.
Клиент:
DSS Agent представляет собой клиент или клиентский инструмент к DSS Server. Одним из преимуществ DSS Agent является использование интеллектуальных агентов для автоматизации бизнес-процессов. Например, с помощью DSS Agent можно создать агента, знающего, когда и где необходимо искать данные и затем что с ними делать потом (то есть, как производить их очистку и куда их поместить). Используя агенты, можно автоматизировать множество обычных, но часто повторяемых задач.
DSS Executive использует возможности DSS Agent для реализации высококачественного генератора отчетов и средства анализа. Он использует объектно-ориентированный подход и интерфейс, работающий по технологии "drag-and-drop" для быстрого создания приложений управленческих информационных систем силами самих пользователей.
И, наконец, MicroStrategy предлагает дополнение Excel Add-In, которое может использоваться для придания таблицам функциональных возможностей OLAP.
Разработка:
С помощью DSS Objects разработчики получают возможность создавать приложения, интегрирующие DSS Server. Для доступа к DSS Server разработчики могут использовать Visual Basic, Delphi и C/C++. DSS Objects поставляется в пакете с Excel Add-In, который можно быстро настроить для непосредственного использования.
Приложения:
У MicroStrategy отсутствуют какие-либо приложения или наборы; ближе всего к этим понятиям стоит DSS Broadcaster, использующий информацию из базы данных и способный активно передавать эту информацию по различным каналам. Данные могут пересылаться согласно расписанию или в результате определенного изменения в их параметрах (exception reporting, т.е. "событийная отчетность").
Интернет:
Новое поколение Интернет-ориентированного OLAP от MicroStrategy представлено DSS Web 5.0. Одним из примечательных свойств DSS Web 5.0 является поддержка Microsoft webcasting standart. Это позволяет автоматически передавать web-страницы на компьютер пользователя. В числе важнейших возможностей DSS Web можно назвать способность сохранять карты или диаграммы, полученные из Интернет, мастера отчетов и настраиваемые пакеты отчетов. DSS Web использует преимущества Java и ActiveX, чтобы создать настраиваемую web-страницу. К тому же, встроенная защита для Netscape обеспечивает средства аутентификации пользовательских приоритетов для контроля доступа.
Прикладной OLAP
Comshare
В качестве примера OLAP-продукта можно взять Comshare. Несмотря на то, что это приложение, оно дополняет продукт функциональными возможностями OLAP.
Сервер:
Comshare Decision проявляет гибкость относительно используемого совместно с ним сервера. Applix TM-1, Arbor Essbase и Oracle Express - все эти многомерные серверы баз данных могут использоваться совместно с Decision. В отличие от инструментов, ориентированных на конкретный сервер (таких, как TM-1 RAP), выбор сервера не представляет сложностей.
Hyperion
Hyperion Software - это производитель, выпускающий исключительно OLAP-клиенты. Последним продуктом на момент выхода этой статьи был Hyperion MBA, или Multidimensional Business Analyst, заменивший HyperionOLAP. HyperionOLAP был популярным, мощным клиентом к базе данных Applix TM-1. Согласно последним данным на тот момент (1997 год), Hyperion занимал второй по величине сегмент рынка, опережаемый только компанией Oracle (прим перев. - в последние годы он обогнал Oracle. В настоящее время он является поставщиком Essbase, который раньше принадлежал Arbor).
Природа продукта гарантирует, что большая часть функциональных возможностей основана на серверной базе данных, а именно - на TM-1. Hyperion популярен благодаря своим дополнительным аналитическим возможностям, реализуемым в форме сложных измерений, предварительно определенных функций и отчетности. Целью его является формирование мощного финансового пакета, включающего в себя OLAP.
Сервер:
HyperionMBA и Analytical Accountant используют сервер Applix TM-1.
Платформы:
Windows NT
Клиент:
Hyperion предлагает два клиентских OLAP-решения. Первое, HyperionMBA, использует OLAP для бизнес-анализа. Как это обычно бывает в OLAP-приложениях, Hyperion применяет в своих решениях сложные измерения и предварительно определенные функции для расчетов и манипуляций с валютами. Программа Hyperion Analytic Accounting включает свойства OLAP в расчетные пакет.
Настольный OLAP
Cognos
Cognos служит неплохим примером настольного OLAP-продукта. Это означает, что большая часть обработки производится не на сервере, а локально. Impromptu представляет собой инструмент запросов, используемый для извлечения данных из многомерной базы данных. Данные затем помещаются в PowerPlay, хранящий powercube на рабочем столе компьютера пользователя (прим. перев. - с момента написания статьи линейка продуктов Cognos существенно расширилась).
Объединение OLAP с технологией Data Mining и Хранилищами данных
Часто OLAP упоминается совместно с Data Mining и Хранилищами данных. И все три технологии развиваются по мере того, как компании начинают осознавать ценность данных.
Реляционные базы данных в свое время были революционным решением, позволяющим предприятиям собирать данные из ежедневных транзакций в крупномасштабные средства хранения. При помощи SQL было возможно выполнять элементарный анализ этих данных. Когда же потребовался более сложный анализ, выяснилось, что SQL и РБД вовсе не идеальное решение. Таблицы были в состоянии обеспечивать более гибкий анализ, но имели ряд существенных недостатков. Данные, подлежащие импорту в таблицу из базы данных и сама таблица были не в состоянии эффективно оперировать большими объемами данных.
С течением времени все больше и больше компаний начали реализовывать Хранилища данных и применять к своим данным средства Data Mining. Хранилище данных обеспечивает хранение очищенных корпоративных данных. Данные по транзакциям проверяются на корректность, категоризируются и затем помещаются в Хранилище. Инструменты Data Mining позволяют аналитикам предприятий выявить скрытые тенденции в данных. Несмотря на то, что может показаться, что OLAP-системы предлагают одновременно и Хранилища данных и инструменты Data Mining, здесь есть некоторая тонкость.
Инструмент OLAP просто дает возможность выполнять быстрый и простой анализ данных. В целом, пользователь-аналитик имеет представление о том, что он собирается найти в некотором представлении данных. Он просто хочет иметь средство манипулирования данными чтобы наиболее наглядно отразить некоторые их аспекты.
Инструмент Data Mining пытается обнаружить скрытые тенденции в данных. В данном случае не пользователь, а именно сам инструмент проводит анализ данных. Обычно инструмент Data Mining занят поиском тенденций и различных аспектов, которые человеку трудно выявить в большом объеме данных.
Заключение и вывод
В качестве резюме, еще раз коснемся вопросов, которые необходимо рассмотреть, принимая решение о том, какой продукт наилучшим образом отвечает потребностям пользователя:
- Откуда поступают данные?
Данные, подлежащие анализу, могут находиться в различных местах. Возможно, что база данных OLAP будет получать их из корпоративного Хранилища данных или из OLTP-системы. Выше были указаны такие источники, как табличные файлы, ASCII-файлы и реляционные базы данных. Если OLAP-продукт уже имеет возможность получить доступ к какому-то источнику данных, процессы категоризации и очистки данных сокращаются. - Какие манипуляции пользователь производит над
данными?
Как только пользователь получил доступ к базе данных и начал выполнять анализ, важно, чтобы он был в состоянии оперировать данными соответствующим образом. В зависимости от потребностей пользователя, может оказаться, что необходим мощный генератор отчетов или возможность создавать и размещать динамические web-страницы. Вместе с тем, может быть пользователю предпочтительнее иметь в своем распоряжении средство простого и быстрого создания собственных приложений. - Каков общий объем данных?
Это наиболее важный фактор при определении базы данных OLAP. Реляционные OLAP-продукты способны оперировать большими объемами данных лучше, чем многомерные. Если объем данных не требует использования реляционной базы, многомерный продукт может использоваться с неменьшим успехом. - Кем является пользователь?
При определении клиента OLAP-системы важен уровень квалификации пользователя. Некоторым пользователям удобнее интегрировать OLAP с таблицей, тогда как другие предпочтут специализированное приложение. В зависимости от квалификации пользователя решается и вопрос о проведении обучения. Крупная компания может пожелать оплатить тренинги для пользователей, компания меньшего размера может отказаться от них. Клиент должен быть таким, чтобы пользователи чувствовали себя уверенно и могли эффективно его использовать.
Автор: Эйриэнн Х. Слотер