Средства добычи знаний в бизнесе и финансах. OLAP-системы

Analysis Manager

Analysis Manager представляет собой утилиту, входящую в состав аналитических служб и предназначенную главным образом для администраторов баз данных OLAP рис. 2.

Рис. 2. Analysis Manager
В составе Analysis Manager имеется простейшее средство просмотра многомерных данных, представляющее собой элемент управления ActiveX, использующий для доступа к данным OLE DB for OLAP.
Analysis Manager использует библиотеки SQL DSO для создания и модификации объектов многомерной базы данных и OLE DB для доступа к исходным реляционным хранилищам данных. Что касается доступа к самим многомерным данным, то, повторимся, Analysis Manager использует для этой цели OLE DB for OLAP.

Архитектуры OLAP-клиентов

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

Рис.1. Семантический слой OLAP-клиентов

Принципы работы OLAP-клиентов

OLAP-клиент предоставляет конечному пользователю интерфейс для выполнения произвольных запросов к данным, их многомерного анализа и формирования интерактивных, модифицируемых самим пользователем отчетов**. При этом используются данные внешних источников.
Общий принцип работы OLAP-клиентов - предварительное описание семантического слоя, который "скрывает" физическую схему данных от пользователя (см. рис. 1). После создания этого слоя пользователь может самостоятельно манипулировать понятными ему объектами, используя термины предметной области. Например, для создания интерактивного отчета пользователь выбирает бизнес-объект "Продажи" и "перетаскивает" его атрибуты в области колонок или строк, далее он может так же просто, движениями мыши, задавать условия фильтрации или группировки данных (в этот момент OLAP-клиент генерирует SQL-запрос к реляционной базе данных (БД) или запрос к многомерной БД, например на языке MDX). Описание семантического слоя может храниться в выделенном репозитории метаданных, в приложении или в системном репозитории многомерной БД.
Разные OLAP-клиенты обладают различными архитектурами, и некоторые из OLAP-клиентов могут быть развернуты в нескольких вариантах архитектур. OLAP-клиенты способны работать в однопользовательском режиме с локальными данными отдельного

Рис. 2. OLAP-клиент MOLAP-сервера

ПК, в файл-серверной архитектуре, в классической двухуровневой клиент-серверной архитектуре, в трехуровневой клиент-серверной архитектуре с сервером приложения (в последнем случае OLAP-клиент может быть реализован как тонкий Web-клиент; эти Web-клиенты заслуживают отдельного обсуждения и здесь не рассматриваются).
Точно так же в OLAP-клиентах организуется и работа с метаданными. Источниками данных могут быть локальные таблицы (например, в формате dbf), таблицы SQL-серверов, локальные многомерные кубы, многомерные базы (кубы) данных OLAP-серверов. Возможна реализация вычисляющей OLAP-машины в OLAP-клиенте, в
MOLAP-сервере (OLAP-сервере, который обрабатывает данные, хранимые в физической многомерной БД), в ROLAP-сервере (OLAP-сервере, обрабатывающем данные, хранимые в реляционной БД), в сервере приложений. Далее будут приведены несколько примеров архитектур OLAP-клиентов, предназначенных для использования в локальных сетях и на отдельных ПК.

Варианты архитектур OLAP-клиентов

OLAP-клиент MOLAP-сервера. Первичные данные из внешних источников периодически загружаются в многомерную БД MOLAP-сервера, в которой постоянно хранятся как первичные атомарные данные, так и вычисленные в момент загрузки агрегаты (см. рис. 2). Часть метаданных, а именно описания атрибутов куба, и OLAP-машина находятся на сервере; OLAP-клиент предоставляет средства организации диалога и отображает данные в виде таблицы.

Рис. 3. OLAP-клиент с локальным кубом

При каждой манипуляции пользователя с этой таблицей генерируется запрос к OLAP-серверу на его языке, например MDX, и отображается вычисленный на сервере результат. Ограничения доступа пользователей к данным задаются на стороне MOLAP-сервера.
Наиболее простой OLAP-клиент этого типа - электронная таблица MS Excel, в которую встроен OLAP-компонент - "сводная таблица" (Pivot Table). Аналитическим приложением является книга MS Excel. Часть метаданных, описывающая свойства отчета, путь к серверу, имя базы данных и куба, хранится в книге MS Excel. Права доступа к отчету ограничиваются доступом к файлу MS Excel. Совместное использование настроек отчета группой пользователей обеспечивается копированием файла этих настроек на ПК каждого пользователя.


Существует несколько реализаций подобных OLAP- клиентов от третьих фирм, которые поставляются в виде дополнения (add-in) к MS Excel. Один из примеров - BusinessQuery компании BusinessObjects.
Достоинства и недостатки такого OLAP-клиента определяются свойствами MS Excel. Достоинства - простота освоения инструмента конечными пользователями и его относительно невысокая стоимость. Персональное владение файлом, в котором содержатся настройки отчета, удобно для пользователя, но усложняет сопровождение многопользовательских приложений. За счет предварительного вычисления агрегатов MOLAP-сервер обеспечивает наивысшую производительность обработки больших объемов данных

Рис. 4. OLAP-клиент и ROLAP-сервер

, и при этом предъявляются невысокие требования к ресурсам ПК пользователей. Но за это приходится платить необходимостью администрирования процессов загрузки данных из источников первичной информации.
Кроме приведенного здесь варианта, MS Pivot Table может работать и без OLAP-сервера (обрабатывая реально до 65 000 записей). OLAP-сервер MS OLAP Server 7/Analysis Services 2000 способен функционировать в режимах ROLAP, MOLAP или HOLAP (в последнем случае одновременно обрабатываются данные как многомерных, так и реляционных БД) - по выбору администратора.
OLAP-клиент c локальным кубом. Плоские данные могут быть перегружены в локальный многомерный куб/файл, который располагается на файл-сервере для общего использования или на локальном ПК - для персонального (см. рис. 3). Генерацию локальных кубов обеспечивают Cognos, MS Pivot Services, BusinessObjects.
Метаданные, описывающие физическую структуру куба, хранятся в нем самом, а метаданные, описывающие интерфейсы и отчеты, - в репозитории OLAP-клиента (BusinessObjects) или в приложении (Cognos, MS Excel).


Таким способом создаются "специальные редакции" OLAP- системы Cognos. Например, одна часть приложения Cognos Nasdaq Special Edition - генератор кубов - находится в бирже Nasdaq, а вторая часть - аналитическая - у пользователей. Пользователи подписываются на биржевые данные, рассылаемые им в виде

Рис.5 . OLAP-клиент с OLAP-машиной и центральным репозиторием метаданных

локальных кубов.
Эта технология удобна для автономной (off-line) работы на ПК, отключенном от сети, или для выполнения многократного анализа однажды подготовленных данных. И как показывают тесты, эта конфигурация до определенного объема данных показывает даже более высокое быстродействие, чем OLAP-сервер.
OLAP-клиент и ROLAP-сервер. Данные хранятся в реляционных СУБД внешних систем, все вычисления выполняются в масштабе реального времени (on-line) на специальном ROLAP-сервере (см. рис. 4). OLAP-клиент предоставляет интерактивный интерфейс пользователю, генерирует запросы на внутреннем языке системы к ROLAP-серверу, который на основе метаданных собственного репозитория преобразует их в SQL-запросы к источникам данных - реляционным СУБД.
Так реализована система MicroStrategy. MS OLAP Server 7/Analysis Services 2000 также может быть настроен для работы в такой архитектуре.
Трехуровневая конфигурация обеспечивает возможность обслуживания тысяч пользователей за счет масштабирования и кластеризации ROLAP-сервера. Требования к мощности ПК пользователей минимальны. В отличие от случая с MOLAP-сервером вычисления выполняются "на лету", что устраняет необходимость процедуры перезагрузки данных из реляционных БД в многомерные кубы. Такая система, как и OLAP-сервер, требует администрирования и не использует огромных

Рис. 6. OLAP-клиент с OLAP-машиной и множеством репозиториев метаданных в виде файлов

возможностей современных ПК.
В MicroStrategy оригинально решена операция детализации, или углубления (drill-down). При каждом запросе пользователя на детализацию отчета генерируется SQL-запрос, результат которого отображается в новом окне. Это не кажется удобным интерфейсным решением для пользователя. Но за счет того, что одновременно обрабатываются только те данные, что отображаются на экране, система обладает уникальной возможностью анализировать данные из реляционных баз неограниченного размера, вплоть до терабайтов.
OLAP-клиент с OLAP-машиной. OLAP-клиент со встроенной OLAP-машиной не хранит агрегатные данные на диске, а в момент запроса загружает их в оперативную память и выполняет вычисления на ПК пользователя (см. рис. 5). Источниками данных могут быть таблицы SQL-серверов, локальные таблицы, ERP-системы.
Работа с метаданными реализуется по-разному. Например, может существовать выделенный центральный репозиторий метаданных. Он хранит описания источников данных, запросов и отчетов и права пользователей.
Построить такую архитектуру позволяет система BusinessObjects. Единый репозиторий метаданных дает всем пользователям возможность применять однажды настроенные отчеты. Администратор получает инструмент для разграничения прав пользователей на бизнес-объекты и отчеты.

Рис. 7. OLAP-клиент с Хранилищем данных

; В клиент-серверной архитектуре с OLAP-машиной на стороне клиента реализован и OLAP-клиент "Контур Стандарт" компании Intersoft Lab. Отличие от архитектуры, описанной выше, состоит в том, что репозиторий метаданных оформлен в виде файла. В терминологии системы он называется "файл приложения" и содержит описание семантического слоя, скрывающего расположение в сети и структуру базы данных, а также описание интерактивных отчетов.


Этих файлов может быть один или много (см. рис. 6). Поэтому клиент может работать поочередно с несколькими репозиториями, которые могут находиться как на его ПК, так и на файл-сервере. Разделение прав доступа на данные реализуется средствами СУБД, а на отчеты - средствами операционной системы: для каждой рабочей группы создается свой файл приложения, доступ к которому ограничивается членами этой группы.
Достоинство этого способа состоит в отчуждаемости репозитория, который можно просто скопировать, послать по почте в филиалы. Кроме того, репозиторий не требует обслуживания. Такая архитектура обеспечивает необычайную гибкость при решении прикладных задач. Этот OLAP-клиент может работать как DOLAP (Desktop OLAP), если данные находятся на локальном ПК, как файл-серверное приложение, если файлы БД лежат на сетевом диске, или как мощное многопользовательское клиент-серверное приложение, если данные предоставляет SQL-сервер.
Независимо от способа хранения метаданных, в этом случае клиент-серверная

Рис. 8. OLAP-клиент, подключенный к БД транзакционной системы

система выполняет распределенные вычисления, при этом благодаря расположению OLAP-машины на стороне клиента в полной мере используется мощность ПК пользователей. Кроме того, не требуется администрирования дополнительной многомерной БД или ROLAP-сервера. При этом максимальные объемы данных и скорость их обработки зависят от мощности ЦП и объемов оперативной памяти ПК. Как показало тестирование системы "Контур Стандарт", на ПК с тактовой частотой 400 МГц и 194 Мб оперативной памяти OLAP-операции над загруженным в оперативную память массивом из миллиона уникальных записей выполняются практически с нулевым временем отклика. При прогнозировании производительности системы следует учитывать важную особенность работы OLAP-клиента в клиент-серверной архитектуре с РСУБД. И Business Objects, и "Контур Стандарт" выполняют анализ запросов пользователей и генерируют SQL-запрос к СУБД, в котором описывается подходящий алгоритм предварительной группировки.


Группирует сервер, а клиенту возвращается компактная выборка для дальнейших OLAP-вычислений. Размер этой выборки может быть в десятки и сотни раз меньше объема первичных данных. Таким образом, возможности OLAP-клиента также очень сильно зависят от мощности сервера БД. При достаточно быстром сервере и большом объеме реальных данных, в которых, как правило, существуют неуникальные записи, OLAP-клиент сможет обрабатывать десятки или даже сотни миллионов первичных, не агрегированных записей.

Применение OLAP-клиентов

OLAP-клиент может быть применен для решения нескольких бизнес-задач:

Создание аналитической инфраструктуры предприятия силами специалистов самого предприятия или внедренческой фирмы.

Создание тиражируемого аналитического приложения для популярной OLTP-системы силами независимого разработчика.

Создание тиражируемого Хранилища данных или высокоуровневого инструмента для построения Хранилищ данных.

Создание интегрированного аналитического модуля для OLTP-системы разработчиком этой системы.

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

Рис. 9. Приложение "Контур Стандарт" для тиражируемой OLTP-системы

Хранилище данных. Разработчик уникального Хранилища или универсального инструмента для построения Хранилищ может сконцентрироваться на проектировании БД и средств сбора и очистки данных. Выполнение запросов, анализ и выпуск отчетов делегируются готовым специализированным системам - OLAP-клиентам (см. рис. 7). Другими словами, программирование интерфейсов Хранилища может быть сведено только к созданию рабочего места администратора.
Транзакционная система. Транзакционные системы, от больших западных ERP-систем до компактных российских "бухгалтерий", наилучшим образом выполняют свои основные функции - автоматизацию учета и выпуск регламентированных отчетов, но не маркетинговый или финансовый анализ.


Однако они накапливают совокупность данных, которые можно использовать для этого анализа.
При помощи OLAP-клиента эти данные можно получать в режиме реального времени непосредственно из БД OLTP-системы (см. рис. 8). Для этого структура БД должна быть прозрачной, а мощность сервера БД достаточной для одновременного выполнения "длинных" аналитических запросов и "коротких" транзакций операционистов.

Рис. 10. Витрина данных OLTP-системы, созданная для анализа

Настройка OLAP-клиента на данные OLTP-системы дополняет ее оперативные и административные интерфейсы аналитическими, что дает большие экономические преимущества в сравнении с доработкой самих систем. Встроенные интерфейсы OLTP-системы будут продолжать служить для выполнения транзакций и, как правило, предназначаться для операционистов, а интерфейсы OLAP-клиента будут использоваться специалистами и руководителями.
Этот подход одинаково пригоден как для уникальных систем предприятия, так и для популярных тиражируемых систем. Так, BusinessObjects поставляет "Шаблоны быстрого развертывания" (Rapid Deployment Templates, RDT). Они представляют собой настройки семантического слоя, переводящие схемы данных популярных на Западе ERP-систем, таких, как SAP R\3, PeopleSoft и другие, на язык бизнес-объектов. При помощи RDT пользователь или поставщик конечных аналитических приложений может быстро настроить необходимые предприятию интерактивные интерфейсы и отчеты.
Настройки "Контур Стандарт" на тиражируемую бухгалтерскую систему, сохраненные в отдельном ресурсе - файле "Приложения", могут распространяться вместе с этой системой ее автором или, как дополнение к ней, независимым разработчиком (см. рис. 9).
Витрины данных. В случае, если БД оперативной системы закрыта для прямого доступа или ее структура не подходит для OLAP-анализа, можно создавать специальные наборы реляционных таблиц или многомерных кубов - Витрины данных (Data Mart) и периодически выгружать в них данные для анализа, например, из бухгалтерской системы (см.


рис. 10).
В этом случае аналитическое приложение для тиражируемой OLTP-системы состоит из трех элементов: программы выгрузки данных (она может быть разработана на языке программирования, встроенном в OLTP-систему), Витрины данных и OLAP-клиента, настроенного на Витрину данных.
Это решение может поставляться как самостоятельное приложение.
Витрины данных также создаются для уменьшения времени отклика при работе с очень большим Хранилищем данных. Для этого некоторые тематические данные регулярно выгружаются из него в многомерные или реляционные Витрины данных для использования группой специалистов.
Интеграция данных на рабочем столе пользователя. Важное достоинство большинства OLAP-клиентов - возможность интеграции данных из различных источников в одном приложении. Конечный пользователь будет работать с данными, физически расположенными в разных информационных системах предприятия, из единого интерфейса и единым образом, что очень удобно (см. рис. 11).
Допускается настройка одного пользовательского интерфейса OLAP-клиента сразу на несколько баз данных различных типов (SQL-серверы, локальные таблицы) и различных систем (бухгалтерская система, Хранилище данных, Витрина данных). Для этого в Business-Objects реализован специальный сервер BI-портал InfoView. MicroStrategy и "Контур Стандарт" могут отображать список отчетов независимо от их источников данных, в одной древовидной структуре папок.


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


Для разработчиков будет полезно принять во внимание тенденции в OLAP-технологиях. Средний человек практически не в состоянии анализировать отчеты, имеющие свыше семи измерений и более двух-трех десятков элементов в одном измерении. Таким образом, объемы данных для "человеческого" анализа являются константой, а мощность компьютеров, в том числе персональных, постоянно растет. Уже сегодня OLAP-сервер исчезает как отдельный продукт и превращается в стандартный сервис SQL-сервера. Дальнейшее повышение мощности ПК может привести к тому, что ее станет достаточно для выполнения OLAP-анализа подавляющего большинства приложений баз данных.



рис1

рис9

Будущие направления

Поставщики приложений бизнес-интеллекта прежде всего должны подчеркивать интеграцию своих приложений, тем самым делая их недорогими, простыми в развитии и удобными. Когда респондентов спрашивали об их восприятии "волны BI-приложений следующего поколения," был получен достаточно широкий диапазон ответов. Многие из этих ответов были основаны на понятии "интеграции". Респонденты предсказывают, что следующая BI-волна будет основана на интеграции приложений бизнес-интеллекта со всеми аспектами деятельности предприятия. В качестве аналогии обычно приводилось то влияние, которое было оказано технологией ERP на эксплуатационные качества систем предприятия. Подобная же динамика ожидается и от развития информационной составляющей систем предприятия. Другие волны развития систем бизнес-интеллекта ожидаются от приложений CRM, Web-доступа и информационных порталов.

Рисунок 3: Пользователи систем бизнес-интеллекта
В следующем вопросе респондентам предлагалось ранжировать приложения бизнес-интеллекта в соответствии с их важностью. Масштабируемое хранилище данных оказалось самым затребованным; около 63% опрошенных оценили его как "критически важное". В качестве других областей были перечислены: индикаторы бизнес-эффективности (57% оценили их как критически важные), CRM (46%), информационные порталы предприятия (43%), анализ данных в реальном времени с наличием обратной связ (33%), и внешние информационные источники (31%).
На вопрос о своих трудностях и предложениях по улучшению систем бизнес-интеллекта, почти все респонденты указывали на одно и то же: недостаток надлежащих навыков пользователей, слишком дорогие приложения, слишком трудно использовать и слишком трудно разрабатывать.

Что хранится в многомерной базе данных

Теоретически OLAP-куб, созданный с помощью аналитических служб Microsoft, может содержать все данные из таблицы фактов плюс агрегатные значения для тех групп записей из этой таблицы, которые соответствуют верхним уровням иерархии измерений. При необходимости можно производить динамическое обновление куба, если в таблицу фактов были добавлены новые записи, а также выбрать, будут ли данные с нижних уровней иерархии храниться в самом кубе, что соответствует способу хранения данных Multidimensional OLAP, или они будут считываться из таблицы фактов хранилища данных, что соответствует способам хранения данных Relational OLAP и Hybrid OLAP (способы хранения данных мы рассматривали в предыдущей статье данного цикла). С точки зрения пользователя различий между этими способами хранения нет, не считая разницы в производительности обращающихся к этим кубам приложений.
Аналитические службы сохраняют агрегатные данные только для простейших агрегатных функций (сумм, числа записей, максимальных и минимальных значений). Однако в случае необходимости можно создавать так называемые вычисляемые члены (calculated members) для получения других типов агрегатных значений (средних, средневзвешенных, смещенных и несмещенных дисперсий и т.д.). При этом, помимо применения встроенных средств создания агрегатных данных, Analysis Services позволяет использовать для вычисления агрегатных данных функции VBA или Excel, а также создавать собственные.
Так, для создания нескольких кубов, имеющих одинаковые измерения, можно сгруппировать их в одну многомерную базу данных, а сами эти измерения поместить в библиотеку (library), сделав их коллективными, то есть общедоступными для всех кубов, содержащихся в базе данных (shared dimensions). Можно также создавать измерения, принадлежащие только одному кубу (private dimensions).
И наконец, аналитические службы Microsoft позволяют создавать так называемые виртуальные кубы (virtual cubes), которые в определенной степени являются аналогами представлений (view) реляционных СУБД. Виртуальные кубы не содержат данных, но позволяют представить в виде единого куба данные из нескольких кубов, имеющих хотя бы одно общее коллективное измерение.

Что представляют собой аналитические службы

Как мы уже знаем, конечной целью использования хранилищ данных и OLAP являются анализ данных и представление результатов этого анализа в удобном для восприятия и принятия решений виде. Непосредственное обращение клиентского приложения, отвечающего за представление результатов анализа данных, к хранилищу данных в принципе возможно. Однако в этом случае в нем должны быть реализованы средства такого анализа, то есть по существу оно должно быть клиентским OLAP-средством. При всей простоте такого подхода к реализации OLAP он не лишен недостатков, связанных с ограничениями, налагаемыми на число измерений и количество членов в них (подробное рассмотрение этого вопроса можно найти в предыдущей статье данного цикла). Как мы знаем, у серверных OLAP-средств таких недостатков нет. Поэтому более прогрессивным представляется подход, основанный на применении серверных OLAP-средств в качестве промежуточного звена между хранилищем данных в виде реляционной СУБД и клиентским приложением. В этом случае OLAP-сервер должен превращать данные из реляционного хранилища в форму, более удобную для создания аналитических отчетов,— в OLAP-кубы.
Как уже было сказано выше, в качестве примера серверного OLAP-средства мы рассмотрим аналитические службы Microsoft (Microsoft Analysis Services), входящие в состав Microsoft SQL Server 2000 Enterprise Edition.
Основным компонентом аналитических служб является Analysis Server — сервис операционной системы Windows NT/2000. Этот сервер предназначен для создания OLAP-кубов на основе реляционных хранилищ данных, а также для предоставления доступа к ним из клиентских приложений. Ниже мы рассмотрим, какими именно объектами манипулирует этот сервер и с помощью каких механизмов это происходит.

Что такое хранилище данных

Информационные системы масштаба предприятия, как правило, содержат приложения, предназначенные для комплексного многомерного анализа данных, их динамики, тенденций и т.п. Такой анализ в конечном итоге призван содействовать принятию решений. Нередко эти системы так и называются— системы поддержки принятия решений.
Принять любое управленческое решение невозможно не обладая необходимой для этого информацией, обычно количественной. Для этого необходимо создание хранилищ данных (Data warehouses), то есть процесс сбора, отсеивания и предварительной обработки данных с целью предоставления результирующей информации пользователям для статистического анализа (а нередко и создания аналитических отчетов).
Ральф Кимбалл (Ralph Kimball), один из авторов концепции хранилищ данных, описывал хранилище данных как "место, где люди могут получить доступ к своим данным" (см., например, Ralph Kimball, "The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses", John Wiley & Sons, 1996 и "The Data Webhouse Toolkit: Building the Web-Enabled Data Warehouse", John Wiley & Sons, 2000). Он же сформулировал и основные требования к хранилищам данных:

поддержка высокой скорости получения данных из хранилища;

поддержка внутренней непротиворечивости данных;

возможность получения и сравнения так называемых срезов данных (slice and dice);

наличие удобных утилит просмотра данных в хранилище;

полнота и достоверность хранимых данных;

поддержка качественного процесса пополнения данных.

Удовлетворять всем перечисленным требованиям в рамках одного и того же продукта зачастую не удается. Поэтому для реализации хранилищ данных обычно используется несколько продуктов, одни их которых представляют собой собственно средства хранения данных, другие — средства их извлечения и просмотра, третьи — средства их пополнения и т.д.
Типичное хранилище данных, как правило, отличается от обычной реляционной базы данных. Во-первых, обычные базы данных предназначены для того, чтобы помочь пользователям выполнять повседневную работу, тогда как хранилища данных предназначены для принятия решений. Например, продажа товара и выписка счета производятся с использованием базы данных, предназначенной для обработки транзакций, а анализ динамики продаж за несколько лет, позволяющий спланировать работу с поставщиками, — с помощью хранилища данных.
Во-вторых, обычные базы данных подвержены постоянным изменениям в процессе работы пользователей, а хранилище данных относительно стабильно: данные в нем обычно обновляются согласно расписанию (например, еженедельно, ежедневно или ежечасно — в зависимости от потребностей). В идеале процесс пополнения представляет собой просто добавление новых данных за определенный период времени без изменения прежней информации, уже находящейся в хранилище.
И в-третьих, обычные базы данных чаще всего являются источником данных, попадающих в хранилище. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов.

Что такое OLAP

Системы поддержки принятия решений обычно обладают средствами предоставления пользователю агрегатных данных для различных выборок из исходного набора в удобном для восприятия и анализа виде. Как правило, такие агрегатные функции образуют многомерный (и, следовательно, нереляционный) набор данных (нередко называемый гиперкубом или метакубом), оси которого содержат параметры, а ячейки — зависящие от них агрегатные данные - причем храниться такие данные могут и в реляционных таблицах, но в данном случае мы говорим о логической организации данных, а не о физической реализации их хранения). Вдоль каждой оси данные могут быть организованы в виде иерархии, представляющей различные уровни их детализации. Благодаря такой модели данных пользователи могут формулировать сложные запросы, генерировать отчеты, получать подмножества данных.
Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). OLAP — это ключевой компонент организации хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных (см. E.F. Codd, S.B. Codd, and C.T.Salley, Providing OLAP (on-line analytical processing) to user-analysts: An IT mandate. Technical report, 1993). В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information — быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:

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

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

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

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

возможность обращаться к любой нужной информации независимо от ее объема и места хранения.

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

Деревья решений (decision trees)

Данный метод пригоден только для решения задач классификации, и поэтому весьма ограниченно применяется в области финансов и бизнеса, где чаще встречаются задачи численного прогноза. В результате применения этого метода к обучающей выборке данных создается иерархическая структура классифицирующих правил типа "ЕСЛИ... ТО...", имеющая вид дерева (это похоже на определитель видов из ботаники или зоологии). Для того чтобы решить, к какому классу отнести некоторый объект или ситуацию, мы отвечаем на вопросы, стоящие в узлах этого дерева, начиная с его корня. Вопросы имеют вид "значение параметра A больше x?". Если ответ положительный, мы переходим к правому узлу следующего уровня, если отрицательный - то к левому узлу; затем снова отвечаем на вопрос, связанный с соответствующим узлом. Так мы в конце концов доходим до одного из оконечных узлов - листьев, где стоит указание, к какому классу надо отнести рассматриваемый объект. Этот метод хорош тем, что такое представление правил наглядно и его легко понять. Но очень остро для деревьев решений стоит проблема значимости. Дело в том, что отдельным узлам на каждом новом построенном уровне дерева соответствует все меньшее и меньшее число записей данных - дерево дробит данные на большое количество частных случаев. Чем больше этих частных случаев, чем меньше обучающих примеров попадает в каждый такой частный случай, тем менее уверенной становится их классификация. Если построенное дерево слишком "кустистое" - состоит из неоправданно большого числа мелких веточек - оно не будет давать статистически обоснованных ответов. Как показывает практика, в большинстве систем, использующих деревья решений, эта проблема не находит удовлетворительного решения. Довольно много систем используют этот метод. Самыми известными являются С5.0 (RuleQuest, Австралия), Clementine (Integral Solutions, Великобритания), SIPINA (University of Lyon, Франция). Из доступных в России можно назвать IDIS (Information Discovery, США). Стоимость этих систем варьируется от 10 до 100 тыс. долл.

Генетические алгоритмы

Строго говоря, интеллектуальный анализ данных - далеко не основная область применения генетических алгоритмов, которые, скорее, нужно рассматривать как мощное средство решения разнообразных комбинаторных задач и задач оптимизации. Тем не менее генетические алгоритмы вошли сейчас в стандартный инструментарий методов data mining, поэтому они и включены в данный анализ. Этот метод назван так потому, что в какой-то степени имитирует процесс естественного отбора в природе. Пусть нам надо найти решение задачи, наиболее оптимальное с точки зрения некоторого критерия. Пусть каждое решение полностью описывается некоторым набором чисел или величин нечисловой природы. Скажем, если нам надо выбрать совокупность фиксированного числа параметров рынка, наиболее выраженно влияющих на его динамику, это будет набор имен этих параметров. Об этом наборе можно говорить как о совокупности хромосом, определяющих качества индивида - данного решения поставленной задачи. Значения параметров, определяющих решение, будут тогда называться генами. Поиск оптимального решения при этом похож на эволюцию популяции индивидов, представленных их наборами хромосом. В этой эволюции действуют три механизма: во-первых, отбор сильнейших - наборов хромосом, которым соответствуют наиболее оптимальные решения; во-вторых, скрещивание - производство новых индивидов при помощи смешивания хромосомных наборов отобранных индивидов; и, в-третьих, мутации - случайные изменения генов у некоторых индивидов популяции. В результате смены поколений в конце концов вырабатывается такое решение поставленной задачи, которое уже не может быть далее улучшено.
С точки зрения нашего анализа генетические алгоритмы имеют два слабых места. Во-первых, сама постановка задачи в их терминах не дает возможности проанализировать статистическую значимость получаемого с их помощью решения и, во-вторых, эффективно сформулировать задачу, определить критерий отбора хромосом под силу только специалисту. В силу этих факторов сегодня генетические алгоритмы надо рассматривать скорее как инструмент научного исследования, чем как средство анализа данных для практического применения в бизнесе и финансах. Сейчас в России доступен только один продукт этого типа - система GeneHunter фирмы Ward Systems Group. Его стоимость - около 1000 долл.

Хранение данных

Хранение данных является краеугольным камнем систем бизнес-аналитики. 87% компаний имеют одно или более функционирующих хранилищ данных, причем больше половины имеют несколько подобных хранилищ. Фактически, четыре компании имеют двадцать или более хранилищ, которые, (хотелось бы на это надеяться), некоторым способом логически интегрированы. 18% этих хранилищ имеет объем в терабайт или более. 30% респондентов ожидает, что объем их хранилища данных возрастет вдвое или даже в несколько раз за последующие два или три года.
Разнообразие источников данных, наполняющих хранилища, просто удивительно. Естественно, каждое хранилище использует транзакционные системы в качестве источника данных. Однако были упомянуты несколько необычных источников данных, такие как Web-сайты электронной коммерции (51%), привязки к базам данных, расположенным у заказчиков или бизнес-партнеров (49%), сервисы расширенного доступа к данным, которые обеспечивают характеристическую информацию по заказчикам (47%), извлечение информации из Web-сайтов (41%), сервисы поиска/обнаружения (34%) и каналы новостных данных от крупных новостных агентств (33%).
Наконец, 47% компаний имеют одну или более витрин данных, и 49% используют накопители операционных данных.

Рисунок 1: Цели и функции систем бизнес-интеллекта.

Истоки сегодняшних продуктов OLAP

Идея обработки многомерных данных не является новой. Фактически она восходит к 1962 году, когда Кен Айверсон опубликовал свою книгу "Язык программирования" ("A Programming Language" - APL). Первая практическая реализация APL была осуществлена в конце шестидесятых компанией IBM. APL - это математически определённый язык с многомерными переменными и изящными, хотя и довольно абстрактными операторами. Он предназначался больше для описания многомерных преобразований, нежели для использования в качестве практического языка программирования. Так, например, в нем не уделялось внимания таким приземленным вопросам, как работа с файлами или вывод на печать. В очень сжатой нотации языка использовались греческие символы. В действительности, тексты программ получались весьма компактными. Он стал известен, как "язык только для написания", потому что было гораздо легче переписать заново программу, нежели исправить ранее сохраненный текст.
К сожалению этот язык был придуман задолго до появления экранов с графическим интерфейсом и лазерных принтеров, а отображение греческих символов требовало специальных экранов, клавиатур и печатающих устройств. Позднее английские слова иногда использовали для замены греческих операторов, однако борцы за чистоту APL пресекли попытки популяризации их элитарного языка. APL поглощал машинные ресурсы и требовал больших затрат. Программы очень медленно выполнялись и обходились очень дорого. APL пожирал оперативную память, требуя шокирующие объемы (порядка 6 МБ), что сегодня звучит смехотворно.
Однако несмотря на неудачное начало, APL не был выброшен. Он использовался во многих деловых приложениях 70-х, 80-х годов, которые функционально подобны сегодняшним OLAP системам. Так, IBM разработала операционную систему для APL, названную VSPC, и некоторые люди считали ее идеальной средой для персонального использования задолго до появления электронных таблиц.
Но APL был слишком сложен в использовании, тем более что каждый раз появлялись несоответствия между самим языком и оборудованием, на котором делались попытки его реализации.

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

В 1970 году впервые появился прикладной многомерный программный продукт, в отличие от других, использовавшихся в учебных целях: Express. Он в полностью переписанном виде широко используется в современных OLAP приложениях, однако оригинальные концепции 70-х годов остались далеко позади. Сегодня, в конце 90-х Express остается одной из наиболее популярных OLAP-технологий, и компании Oracle удается поддерживать его на уровне современных требований наряду со многими новыми продуктами с архитектурой "клиент-сервер".

Больше многомерных продуктов появилось в 80-х годах. В начале десятилетия появился Stratagem, в новом обличии - Acumate (сегодня владельцем является Lucent), который продвигался на рынке до середины 90-х, но сегодня, в отличие от Express, используется очень ограниченно.

Comshare System W был многомерным продуктом другого стиля. Представленный в 1981 году, он первым использовал идею гиперкуба и был в большей степени ориентирован на конечного пользователя в разработке финансовых приложений. Он привнёс много концепций, которые, правда, еще не были хорошо проработаны, типа непроцедурных правил, полноэкранного просмотра многомерных данных, редактирования данных, автоматическое перевычисление и интеграция с реляционными данными (в пакетном режиме). Однако Comshare System W был достаточно тяжел для аппаратного обеспечения того времени и менее программируемым по сравнению с другими продуктами и, соответственно, был менее популярен в среде профессионалов ИТ. Он также пока используется, но продается всё меньше, поскольку не имел тех улучшений, которые ожидались. Хотя он и сегодня доступен на UNIX, он не является клиент-серверным продуктом, что не способствует его продвижению на рынке OLAP предложений.


В конце 80-х Comshare выпустил в среде DOS, а позднее для Windows, продукт под названием Commander Prism. Он использовал те же концепции, что были заложены в System W. Essbase, продукт компании Hyperion Solution, хотя и не является прямым потомком System W, был очевидно под влиянием его решений со своей ориентацией на финансовые приложения и организацией гиперкуба с полными предварительными вычислениями. По иронии судьбы Comshare в последствии приобрела лицензии Essbase, для использования в качестве основы для своих собственных современных OLAP продуктов.

Другим новаторским продуктом в начале 80-х был Metaphor. Он предназначался для профессиональных маркетологов. Он также предложил много новых концепций, которые стали популярными только в 90-х годах: такие как, клиент-серверные вычисления, многомерная обработка реляционных данных, многопользовательский режим и объектно ориентированная разработка приложений. К сожалению стандартные персональные компьютеры не обеспечивали тех характеристик, которые требовал Metaphor, и поставщики были вынуждены разрабатывать собственные персональные машины и сети. В последствии Metaphor стал работать удачно и на серийных персональных машинах, однако он никогда не использовал стандартный графический интерфейс пользователя (GUI).

В последствии Metaphor заключил маркетинговый альянс с компанией IBM, которой впоследствии и был поглощён. В середине 1994 года IBM решила интегрировать технологию Metaphor (переименованную в DIS) со своими будущими технологиями и расформировать дочернюю компанию, хотя заказчики протестовали и требовали продолжить поддержку продукта. Поддержка была продолжена для оставшихся заказчиков. IBM перевыпустила продукт под новым названием IDS, но это не способствовало его продвижению. Однако творческие, новаторские концепции Metaphor не были забыты, например в продуктах Information Advantage, Brio, Sagent, DSS Suite и Gentia их влияние очевидно.

В середине 80-х родился термин EIS (Executive Information System - информационная система руководителя).


Первым продуктом, явно выражавшим это направление, был Command Center фирмы Pilot. Это был продукт ориентированный на совместные вычисления, то, что сегодня мы называем архитектурой "клиент-сервер". Поскольку мощность персональных компьютеров 80-х годов была весьма ограничена, основная нагрузка падала на сервер, однако этот подход вернулся в современность в продуктах, подобным Information Advantage и Holos.. Pilot недолго продавал Command Center, но предложил много концепций, которые можно узнать в сегодняшних OLAP-продуктах, включая автоматическую поддержку временных промежутков, многомерные клиент-серверные вычисления и упрощённые манипуляции (посредством использования мыши и чувствительных экранов). Некоторые из этих концепций были повторно применены позднее в Pilot Analysis Server, который сегодня также закончил свое существование.

В конце 80-х среди инструментов конечного пользователя для анализа данных стали доминировать электронные таблицы. Первая многомерная электронная таблица появилась в виде Compete. Он продвигался на рынок как очень дорогой продукт для специалистов, но поставщики не обеспечили возможность захвата рынка этим продуктом, и компания Computer Associates приобрела права на него вместе с другими продуктами класса spreadsheet (электронных таблиц), включая Supercalc и 20/20. Основным эффектом от приобретения Compete компанией CA было резкое снижение цены и снятие защиты от копирования, что, естественно, способствовало его распространению. Однако он еще не был удачным. В течение нескольких лет Compete еще изредка можно было встретить в виде нагрузки в некоторых комплектах поставки. Позднее Compete был положен в основу SuperСalc 5, но многомерный аспект его не продвигался.

Компания Lotus была следующей, кто попытался войти на рынок многомерных электронных таблиц с продуктом Improv, который запускался на NeXT машине. Это гарантировало, что продажи 1-2-3 не снизятся, но когда тот со временем был выпущен под Windows, Excel уже стал настолько серьезным конкурентом, что продажи Improve не внесли заметных изменений в распределении рынка.


Lotus, подобно CA с Compete, скинула цену на Improv, однако и этого оказалось недостаточно для продвижения на рынке, и новые разработки в этой области не получили продолжения. Оказалось, что пользователи персональных компьютеров предпочитают электронные таблицы в оригинальной версии 1-2-3 и не интересуются новыми многомерными возможностями, если они не полностью совместимы с их старыми таблицами. Точно так же концепция небольших многомерных настольных электронных таблиц, предлагаемых в качестве продуктивного инструмента для персональных приложений, в действительности не оказались удобными и не прижились в реальной практике. Компания Microsoft пошла по этому пути, добавив PivotTables к Excel. Хотя немногие пользователи Excel получили выгоду от использования этой возможности, это, вероятно, единственный факт широкого использования возможностей многомерного анализа просто потому, что в мире очень много пользователей Excel.

Excel 2000 содежит более изощренную версию PivotTables, предназначенную для использования и в качестве настольного инструмента OLAP и как клиентской части для взаимодействия с Microsoft OLAP Services. Однако возможности OLAP в Excel 2000 не являются базовыми, ведущими, они скорее встроены как дополнительная, второстепенная возможность.

В конце 80-х фирма Sinper вошла в мир многомерных электронных таблиц первоначально с собственной электронной таблицей для DOS, а затем подсоединенной к версии 1-2-3 для DOS. Превращенный в продукт TM/1, он вошел в эру Windows как сервер баз данных в формате Excel и 1-2-3. Чуть позже Arbor сделал аналогичную вещь, хотя его новый Essbase мог работать только в режиме клиент-сервер, тогда как продукт фирмы Sinper мог так же работать на локальном компьютере. Этот подход принес мультиразмерность в электронные таблицы, которые являются столь популярными среди пользователей. Так или иначе, факт остается фактом, традиционные поставщики собственных инструментов представления данных конечному пользователю последовали по этому пути, и такие продукты, как DSS Server, Express, Holos, Gentia, MineShare, PowerPlay, MetaCube и WhiteLight теперь с гордостью предлагают высоко интегрированный доступ к электронным таблицам в своих серверах приложений.


По иронии судьбы за свои первые шесть месяцев существования Microsoft OLAP Services был одним из нескольких OLAP серверов, не имеющих клиентской части в виде электронной таблицы. Предложения компании Microsoft появились только в июне 1999 года в Excel 2000. Однако OLAP@Work встраиваемый в Excel заполнил этот пробел, и пока еще имеет гораздо лучшие эксплуатационые характеристики, чем собственный интерфейс Excel компании Microsoft.

Некоторые пользователи требуют для своих многомерных приложений возможности обработки очень больших многомерных баз данных. И реляционные OLAP-инструменты развиваются в этом направлении, отзываясь на эти нужды. Они предоставляют обычные средства просмотра многомерных данных, а иногда включают интерфейс конечного пользователя в виде электронной таблицы, даже если все данные хранятся в RDBMS (реляционных СУБД). Такие средства являются очень дорогими для пользователя, они менее производительны, чем специализированные инструменты многомерного анализа, но они обеспечивают эту, столь популярную форму анализа данных, даже если последние хранятся не в виде многомерных структур.

Другие постащики развивают то, что сегодня называется настольными OLAP (даже в случае Web-приложений, где гиперкубы обычно расположены на сервере): небольшие кубы, генерируемые из больших баз данных и затем загружаемые в персональный компьютер для обработки. Они действительно достигают большого успеха. А когда поставщик продает обе возможности: и инструмент формирования реляционных запросов и инструмент многомерного анализа и формирования отчетов (Cognos с Impromptu и PowerPlay), то достигает большего успеха у конечных пользователей, нежели в других случаях.

Сегодня поставщики реляционных баз данных активно занимаются многомерным анализом: Oracle, IBM, Microsoft, Informix и Sybase - все разрабатывают и выбраcывают на рынок продукты в этой области. Забавно, что компании, упорно игнорировавшие мультиразмерность многие годы, это - Oracle, Microsoft и IBM вскоре могут стать "триадой OLAP" с большой долей рынка OLAP, основываясь на продаже многомерных продуктов, которые были изобретены не ими.


Итак, что мы имеем за 35-летнюю историю?

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

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

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

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

Эволюционное программирование

Сегодня это самая молодая и наиболее перспективная ветвь data mining, реализованная, в частности, в системе PolyAnalyst. Суть метода в том, что гипотезы о виде зависимости целевой переменной от других переменных формулируются системой в виде программ на некотором внутреннем языке программирования. Если это универсальный язык, то теоретически на нем можно выразить зависимость любого вида. Процесс построения этих программ строится как эволюция в мире программ (этим метод немного похож на генетические алгоритмы). Когда система находит программу, достаточно точно выражающую искомую зависимость, она начинает вносить в нее небольшие модификации и отбирает среди построенных таким образом дочерних программ те, которые повышают точность. Таким образом система "выращивает" несколько генетических линий программ, которые конкурируют между собой в точности выражения искомой зависимости. Специальный транслирующий модуль системы PolyAnalyst переводит найденные зависимости с внутреннего языка системы на понятный пользователю язык (математические формулы, таблицы и пр.), делая их легкодоступными. Для того чтобы сделать полученные результаты еще понятнее для пользователя-нематематика, имеется богатый арсенал разнообразных средств визуализации обнаруживаемых зависимостей. Для контроля статистической значимости выводимых зависимостей применяется набор современных методов, например рандомизированное тестирование. Все эти меры приводят к тому, что PolyAnalyst показывает в задачах анализа российских финансовых рынков весьма высокие показатели.
В таблице 1 приведена оценка упомянутых методов и систем по трем предложенным критериям.
Таблица 1.

	тех. анализ	стат. пакеты	нейросети	CBR	деревья решений	GeneHunter	МГУА (NeuroShell)	PolyAnalyst
значимость	нет	++	-	+	-	-	-	++
интерпретируемость	нет	+-	-	-	++	+-	+	+
автоматизм	++	-	+	+	+	-	+	+

Классы систем интеллектуального анализа данных, применяемые в бизнесе и финансах

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

Клиенты аналитических служб

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

A Programming Language" Кена Айверсона

1962
Публикация " A Programming Language" Кена Айверсона (IBM)
Первый многомерный язык программирования. Использовал греческие символы в операторах. Стал доступным на больших ЭВМ (мэйнфреймах) IBM в конце 60-х годов, используется до сегодняшнего дня в ограниченных масштабах. APL не может считаться инструментом OLAP, но многие идеи, положенные в его основу, живы и сегодня. Фамильная традиция продолжена сыном Айверсона - Эриком Айверсоном, нане одним из руководителей Adaytum Software.
1970
Появился Express
Первый многомерный продукт, ориентированный на рыночные приложения; ныне - собственность компании Oracle. До сих пор остается одним из лидеров рынка OLAP( после неоднократного переписывания и дважды - смены собственника). Хотя программа сильно изменена, концепции и модель данных сохраняются.
1982
Comshare System W выпущен на собственной ЭВМ.
Первый OLAP инструмент, ориентированный на финансовые приложения. На рынке больше не предлагается, но пока используется на мэйнфреймах IBM; его потомок для Windows, Commander Prism, еще доступен. Позднее Essbase использовал многие его концепции.
1984
Запущен Metaphor
Первый ROLAP. Продажи его брата для Mac разочаровали, частично из-за техники, не допускающей клонирования и высокой цены(стартовая цена составляла $64,000). Однако, как и Mac, Metaphor имеет своих поклонников.
1985
Выпущен Pilot Command Center
Первая клинт-серверная информационная система руководителя, выполненная в стиле OLAP; использовалась на серверах VAX и стандартных PC в качестве клиента. Этот достойный продукт больше на рынке не предлагается, но остается в ограниченном использовании.
1990
Cognos PowerPlay
Он стал первым OLAP для Windows OLAP и первым настольным OLAP. Сегодня лидирует в секторе настольных OLAP, имея свыше 600,000 мест внедрения. Он является также наиболе перепродаваемым инструментом. Хотя мы пока классифицируем его как настольный OLAP, Cognos сегодня предлагает более масштабируемые клиент-серверные и Web версии.
1991
IBM поглощает Metaphor
Первый из многих OLAP продуктов, поменявших хозяина. Metaphor стал частью обреченного объединения Apple-IBM и ныне засиделся на IDS, у которого остется некоторое количество мест внедрения.
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 продукта. Возможно именно это событие выдвинуло OLAP на мировой рынок, и почти определенно оно переключило других поставщиков баз данных на эту проблему. Express сегодня стал гибридным OLAP и конкурирует одновременно как с многомерными, так и с реляционными инструментами OLAP.
1996
BusinessObjects 4.0
Первый цельный инструмент, обеспечивающий формирование многомерных и реляционных отчетов из настольного куба, динамически создаваемого из реляционных данных. В ранних версиях имелись проблемы, однако в версиях после 4.1 большинство из них решены, а версия 5.0 значительно улучшена.
1997
Microsoft объявляет об OLE DB для OLAP
Этот проект имел условное название "Tensor" и стал "промышленным стандартом" по OLAP API прежде чем какой-либо продукт стал его поддерживать. Более 40 компаний сегодня разрабатывают продукты, используя его, многие из которых уже выпущены.
1998
Создан IBM DB2 OLAP Server
Эта версия Essbase имеет реляционную структуру данных типа "звезда", сохраняемых либо в DB2, либо в другой реляционной базе данных, но пока боле походит на медленный MOLAP, чем на ROLAP.
1998
Сформирован Hyperion Solutions
Arbor и Hyperion Software слились в первую большую консолидацию на рынке OLAP. Несмотря на название, это больше передача прав Hyperion'а Arbor'у, чем слияние, и инициировано оно вероятно страхом перед наступлением Microsoft на рынок OLAP.
1999
Выпущен Microsoft OLAP Services
Этот проект имел условное название "Plato" и использовал технологию, купленную у Panorama Software Systems в 1996 году. Уже стал лидером рынка среди OLAP серверов без каких-либо усилий по развертыванию, имея изощренную архитектуру хранения данных (ROLAP/MOLAP/Hybrid), огромную поддержку третьих фирм, низкую цену и машину маркетинга компании Microsoft.

Конфиденциальность

Конфиденциальность в BI системах находится в незрелом состоянии. 22% компаний собирают личные данные пользователей, такие как адреса и номера телефонов. Отвечая на вопрос о политике конфиденциальности, только 11 компаний (из 22) ответили, что они имеют всестороннюю политику обеспечения конфиденциальности, а четыре компании сказали, что имеют разрозненые нормативные акты или не имеют вообще ничего. Между тем только один опрошенный отметил, что главным фактором тут служит отсуствие законодательных актов в области обеспечения конфиденциальности.

Многомерные кубы

В данном разделе мы более подробно рассмотрим концепцию OLAP и многомерных кубов. В качестве примера реляционной базы данных, который мы будем использовать для иллюстрации принципов OLAP, воспользуемся базой данных Northwind, входящей в комплекты поставки Microsoft SQL Server или Microsoft Access и представляющей собой типичную базу данных, хранящую сведения о торговых операциях компании, занимающейся оптовыми поставками продовольствия. К таким данным относятся сведения о поставщиках, клиентах, компаниях, осуществляющих доставку, список поставляемых товаров и их категорий, данные о заказах и заказанных товарах, список сотрудников компании. Подробное описание базы данных Northwind можно найти в справочных системах Microsoft SQL Server или Microsoft Access— здесь за недостатком места мы его не приводим.
Для рассмотрения концепции OLAP воспользуемся представлением Invoices и таблицами Products и Categories из базы данных Northwind, создав запрос, в результате которого получим подробные сведения о всех заказанных товарах и выписанных счетах:
SELECT dbo.Invoices.Country, dbo.Invoices.City, dbo.Invoices.CustomerName, dbo.Invoices.Salesperson, dbo.Invoices.OrderDate,dbo.Categories.CategoryName, dbo.Invoices.ProductName, dbo.Invoices.ShipperName, dbo.Invoices.ExtendedPriceFROM dbo.Products INNER JOIN dbo.Categories ON dbo.Products.CategoryID = dbo.Categories.CategoryID INNER    JOIN dbo.Invoices ON dbo.Products.ProductID = dbo.Invoices.ProductID В Access 2000 аналогичный запрос имеет вид:
SELECT Invoices.Country, Invoices.City,Invoices.Customers.CompanyName ASCustomerName, Invoices.Salesperson,Invoices.OrderDate, Categories.CategoryName, Invoices.ProductName, Invoices.Shippers.CompanyName AS ShipperName, Invoices.ExtendedPriceFROM Categories INNER JOIN (Invoices INNERJOIN Products ON Invoices.ProductID =Products.ProductID) ON Categories.CategoryID =Products.CategoryID; Этот запрос обращается к представлению Invoices, содержащему сведения обо всех выписанных счетах, а также к таблицам Categories и Products, содержащим сведения о категориях продуктов, которые заказывались, и о самих продуктах соответственно.
В результате этого запроса мы получим набор данных о заказах, включающий категорию и наименование заказанного товара, дату размещения заказа, имя сотрудника, выписавшего счет, город, страну и название компании-заказчика, а также наименование компании, отвечающей за доставку.

Для удобства сохраним этот запрос в виде представления, назвав его Invoices1. Результат обращения к этому представлению приведен на рис. 1.



Рис. 1. Результат обращения к представлению Invoices1

Какие агрегатные данные мы можем получить на основе этого представления? Обычно это ответы на вопросы типа:

Какова суммарная стоимость заказов, сделанных клиентами из Франции?

Какова суммарная стоимость заказов, сделанных клиентами из Франции и доставленных компанией Speedy Express?

Какова суммарная стоимость заказов, сделанных клиентами из Франции в 1997 году и доставленных компанией Speedy Express?

Переведем эти вопросы в запросы на языке SQL (аналогичные вопросы, сформулированные на английском языке, можно превратить в SQL-запросы с помощью Microsoft English Query, однако рассмотрение подобных средств выходит за рамки данной статьи).

Вопрос	SQL-запрос
Какова суммарная стоимость заказов, сделанных клиентами из Франции?	SELECT SUM (ExtendedPrice) FROM invoices1 WHERE Country=’France’
Какова суммарная стоимость заказов, сделанных клиентами из Франции и доставленных компанией Speedy Express?	SELECT SUM (ExtendedPrice) FROM invoices1 WHERE Country=’France’ AND ShipperName=’Speedy Express’
Какова суммарная стоимость заказов, сделанных клиентами из Франции в 1996 году и доставленных компанией Speedy Express?	SELECT SUM (ExtendedPrice) FROM Ord_pmt WHERE CompanyName=’Speedy Express’ AND OrderDate BETWEEN ‘December 31, 1995’ AND ‘April 1, 1996’ AND ShipperName=’Speedy Express’

Результатом любого из перечисленных выше запросов является число. Если в первом из запросов заменить параметр ‘France’ на ‘Austria’ или на название иной страны, можно снова выполнить этот запрос и получить другое число.


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

Country	SUM (ExtendedPrice)
Argentina	7327.3
Austria	110788.4
Belgium	28491.65
Brazil	97407.74
Canada	46190.1
Denmark	28392.32
Finland	15296.35
France	69185.48
Germany	209373.6
…	…

Полученный набор агрегатных значений (в данном случае — сумм) может быть интерпретирован как одномерный набор данных. Этот же набор данных можно получить и в результате запроса с предложением GROUP BY следующего вида:

SELECT Country, SUM (ExtendedPrice) FROM invoices1 GROUP BY Country  Теперь обратимся ко второму из приведенных выше запросов, который содержит два условия в предложении WHERE. Если выполнять этот запрос, подставляя в него все возможные значения параметров Country и ShipperName, мы получим двухмерный набор данных следующего вида (ниже показан фрагмент):

	ShipperName
Country	Federal Shipping	Speedy Express	United Package
Argentina	1 210.30	1 816.20	5 092.60
Austria	40 870.77	41 004.13	46 128.93
Belgium	11 393.30	4 717.56	17 713.99
Brazil	16 514.56	35 398.14	55 013.08
Canada	19 598.78	5 440.42	25 157.08
Denmark	18 295.30	6 573.97	7 791.74
Finland	4 889.84	5 966.21	7 954.00
France	28 737.23	21 140.18	31 480.90
Germany	53 474.88	94 847.12	81 962.58
…	…	…	…

Такой набор данных называется сводной таблицей (pivot table) или кросс-таблицей (cross table, crosstab). Создавать подобные таблицы позволяют многие электронные таблицы и настольные СУБД — от Paradox для DOS до Microsoft Excel 2000. Вот так, например, выглядит подобный запрос в Microsoft Access 2000:

TRANSFORM Sum(Invoices1.ExtendedPrice) AS SumOfExtendedPriceSELECT Invoices1.CountryFROM Invoices1GROUP BY Invoices1.CountryPIVOT Invoices1.ShipperName; Агрегатные данные для подобной сводной таблицы можно получить и с помощью обычного запроса GROUP BY:

SELECT Country,ShipperName, SUM (ExtendedPrice) FROM invoices1GROUP BY COUNTRY,ShipperName Отметим, однако, что результатом этого запроса будет не сама сводная таблица, а лишь набор агрегатных данных для ее построения (ниже показан фрагмент):

Country	ShipperName	SUM (ExtendedPrice)
Argentina	Federal Shipping	845.5
Austria	Federal Shipping	35696.78
Belgium	Federal Shipping	8747.3
Brazil	Federal Shipping	13998.26
…	…	…

Третий из рассмотренных выше запросов имеет уже три параметра в условии WHERE. Варьируя их, мы получим трехмерный набор данных (рис. 2).



Рис. 2. Трехмерный набор агрегатных данных

Ячейки куба, показанного на рис. 2, содержат агрегатные данные, соответствующие находящимся на осях куба значениям параметров запроса в предложении WHERE.

Можно получить набор двухмерных таблиц с помощью сечения куба плоскостями, параллельными его граням (для их обозначения используют термины cross-sections и slices).

Очевидно, что данные, содержащиеся в ячейках куба, можно получить и с помощью соответствующего запроса с предложением GROUP BY. Кроме того, некоторые электронные таблицы (в частности, Microsoft Excel 2000) также позволяют построить трехмерный набор данных и просматривать различные сечения куба, параллельные его грани, изображенной на листе рабочей книги (workbook).

Если в предложении WHERE содержится четыре или более параметров, результирующий набор значений (также называемый OLAP-кубом) может быть 4-мерным, 5-мерным и т.д.

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

Нейронные сети

Это большой класс разнообразных систем, чья архитектура в некоторой степени имитирует построение нервной ткани из нейронов. В одной из наиболее распространенных архитектур, многослойном перцептроне с обратным распространением ошибки, эмулируется работа нейронов в составе иерархической сети, где каждый нейрон более высокого уровня соединен своими входами с выходами нейронов нижележащего слоя. На нейроны самого нижнего слоя подаются значения входных параметров, на основе которых нужно принимать какие-то решения, прогнозировать развитие ситуации и т. д. Эти значения рассматриваются как сигналы, передающиеся в вышележащий слой, ослабляясь или усиливаясь в зависимости от числовых значений (весов), приписываемых межнейронным связям. В результате этого на выходе нейрона самого верхнего слоя вырабатывается некоторое значение, которое рассматривается как ответ, реакция всей сети на введенные значения входных параметров. Для того чтобы сеть можно было применять в дальнейшем, ее прежде надо "натренировать" на полученных ранее данных, для которых известны и значения входных параметров, и правильные ответы на них. Эта тренировка состоит в подборе весов межнейронных связей, обеспечивающих наибольшую близость ответов сети к известным правильным ответам. Такой подход оказался высокоэффективным в задачах распознавания образов, однако он почти не применим к большинству финансовых и экономических задач в российских условиях, так как не удовлетворяет двум из трех сформулированных в предыдущем разделе требований.
Во-первых, реальные нейросети, создаваемые, скажем, в результате обучения на истории российских финансовых рынков, - это очень сложные системы, включающие десятки нейронов и несколько сотен связей между ними. Во-вторых, количество степеней свободы создаваемой прогностической модели (вес каждой связи между нейронами сети) часто превышает число использовавшихся для обучения примеров (отдельных записей данных). Это означает, что нейросеть может "научиться" даже на массиве сгенерированных случайных чисел. И действительно, как показывает применение нейросети для решения тестовой задачи по анализу рынка акций, приведенной далее, она прекрасно объясняет все колебания рынка в прошлом, но не дает обоснованного прогноза на будущее. Невыполнимость требования прозрачности создаваемых прогностических моделей опять-таки связана со сложностью нейросети. Знания, зафиксированные как веса нескольких сотен межнейронных связей, совершенно не поддаются анализу и интерпретации человеком. Вследствие этого нейросети оказываются почти не пригодны для решения российских финансовых задач, хотя в развитых странах нейросети широко применяются в этой области. В России можно приобрести такие нейросетевые системы, как BrainMaker (CSS), NeuroShell (Ward Systems Group), OWL (HyperLogic). Стоимость их также довольно значительна: 1500-8000 долл.

Некоторые термины и понятия

Наряду с суммами в ячейках OLAP-куба могут содержаться результаты выполнения иных агрегатных функций языка SQL, таких как MIN, MAX, AVG, COUNT, а в некоторых случаях — и других (дисперсии, среднеквадратичного отклонения и т.д.). Для описания значений данных в ячейках используется термин summary (в общем случае в одном кубе их может быть несколько), для обозначения исходных данных, на основе которых они вычисляются, — термин measure, а для обозначения параметров запросов — термин dimension (переводимый на русский язык обычно как "измерение", когда речь идет об OLAP-кубах, и как "размерность", когда речь идет о хранилищах данных). Значения, откладываемые на осях, называются членами измерений (members).
Говоря об измерениях, следует упомянуть о том, что значения, наносимые на оси, могут иметь различные уровни детализации. Например, нас может интересовать суммарная стоимость заказов, сделанных клиентами в разных странах, либо суммарная стоимость заказов, сделанных иногородними клиентами или даже отдельными клиентами. Естественно, результирующий набор агрегатных данных во втором и третьем случаях будет более детальным, чем в первом. Заметим, что возможность получения агрегатных данных с различной степенью детализации соответствует одному из требований, предъявляемых к хранилищам данных, — требованию доступности различных срезов данных для сравнения и анализа.
Поскольку в рассмотренном примере в общем случае в каждой стране может быть несколько городов, а в городе — несколько клиентов, можно говорить об иерархиях значений в измерениях. В этом случае на первом уровне иерархии располагаются страны, на втором — города, а на третьем — клиенты рис. 3.

Рис. 3. Иерархия в измерении, связанном с географическим положением клиентов
Отметим, что иерархии могут быть сбалансированными (balanced), как, например, иерархия, представленная на рис. 3, а также иерархии, основанные на данных типа "дата—время", и несбалансированными (unbalanced).
Типичный пример несбалансированной иерархии — иерархия типа "начальник—подчиненный" ( ее можно построить, например, используя значения поля Salesperson исходного набора данных из рассмотренного выше примера), представлен на рис. 4.



Рис. 4. Несбалансированная иерархия

Иногда для таких иерархий используется термин Parent-child hierarchy.

Существуют также иерархии, занимающие промежуточное положение между сбалансированными и несбалансированными (они обозначаются термином ragged — "неровный"). Обычно они содержат такие члены, логические "родители" которых находятся не на непосредственно вышестоящем уровне (например, в географической иерархии есть уровни Country, City и State, но при этом в наборе данных имеются страны, не имеющие штатов или регионов между уровнями Country и City; (рис. 5).



Рис. 5. "Неровная" иерархия

Отметим, что несбалансированные и "неровные" иерархии поддерживаются далеко не всеми OLAP-средствами. Например, в Microsoft Analysis Services 2000 поддерживаются оба типа иерархии, а в Microsoft OLAP Services 7.0 — только сбалансированные. Различным в разных OLAP-средствах может быть и число уровней иерархии, и максимально допустимое число членов одного уровня, и максимально возможное число самих измерений.

Нелинейные регрессионные методы

Поиск зависимости целевых переменных от остальных ведется в форме функций какого-то определенного вида. Например, в одном из наиболее удачных алгоритмов этого типа - методе группового учета атрибутов (МГУА) зависимость ищут в форме полиномов. По всей видимости, этот метод дает более статистически значимые результаты, чем нейронные сети. К тому же полученная формула зависимости, полином, в принципе поддается анализу и интерпретации (хотя на практике все же бывает слишком сложна для этого). Это делает данный метод достаточно перспективным для анализа российских финансовых и корпоративных данных. В настоящее время из продающихся в России систем МГУА реализован лишь в системе NeuroShell компании Ward Systems Group.

Один из подходов к созданию систем поддержки принятия решений нового поколения

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

OLAP на клиенте и на сервере

Многомерный анализ данных может быть произведен с помощью различных средств, которые условно можно разделить на клиентские и серверные OLAP-средства.
Клиентские OLAP-средства представляют собой приложения, осуществляющие вычисление агрегатных данных (сумм, средних величин, максимальных или минимальных значений) и их отображение, при этом сами агрегатные данные содержатся в кэше внутри адресного пространства такого OLAP-средства.
Если исходные данные содержатся в настольной СУБД, вычисление агрегатных данных производится самим OLAP-средством. Если же источник исходных данных— серверная СУБД, многие из клиентских OLAP-средств посылают на сервер SQL-запросы, содержащие оператор GROUP BY, и в результате получают агрегатные данные, вычисленные на сервере.
Как правило, OLAP-функциональность реализована в средствах статистической обработки данных (из продуктов этого класса на российском рынке широко распространены продукты компаний StatSoft и SPSS) и в некоторых электронных таблицах. В частности, неплохими средствами многомерного анализа обладает Microsoft Excel 2000. С помощью этого продукта можно создать и сохранить в виде файла небольшой локальный многомерный OLAP-куб и отобразить его двух- или трехмерные сечения.
Многие средства разработки содержат библиотеки классов или компонентов, позволяющие создавать приложения, реализующие простейшую OLAP-функциональность (такие, например, как компоненты DecisionCube в Borland Delphi и Borland C++Builder). Помимо этого многие компании предлагают элементы управления ActiveX и другие библиотеки, реализующие подобную функциональность.
Отметим, что клиентские OLAP-средства применяются, как правило, при малом числе измерений (обычно рекомендуется не более шести) и небольшом разнообразии значений этих параметров, — ведь полученные агрегатные данные должны умещаться в адресном пространстве подобного средства, а их количество растет экспоненциально при увеличении числа измерений. Поэтому даже самые примитивные клиентские OLAP-средства, как правило, позволяют произвести предварительный подсчет объема требуемой оперативной памяти для создания в ней многомерного куба.

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

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

Преимущества применения серверных OLAP-средств по сравнению с клиентскими OLAP-средствами сходны с преимуществами применения серверных СУБД по сравнению с настольными: в случае применения серверных средств вычисление и хранение агрегатных данных происходят на сервере, а клиентское приложение получает лишь результаты запросов к ним, что позволяет в общем случае снизить сетевой трафик, время выполнения запросов и требования к ресурсам, потребляемым клиентским приложением. Отметим, что средства анализа и обработки данных масштаба предприятия, как правило, базируются именно на серверных OLAP-средствах, например, таких как Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, продуктах компаний Crystal Decisions, BusinessObjects, Cognos, SAS Institute.Поскольку все ведущие производители серверных СУБД производят (либо лицензировали у других компаний) те или иные серверные OLAP-средства, выбор их достаточно широк и почти во всех случаях можно приобрести OLAP-сервер того же производителя, что и у самого сервера баз данных.

Отметим, что многие клиентские OLAP-средства (в частности, Microsoft Excel 2000, Seagate Analysis и др.) позволяют обращаться к серверным OLAP-хранилищам, выступая в этом случае в роли клиентских приложений, выполняющих подобные запросы. Помимо этого имеется немало продуктов, представляющих собой клиентские приложения к OLAP-средствам различных производителей.

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

Ответственность

Несомненно, IT-отдел предприятия является главным звеном, ответственным за функционирование систем бизнес-аналитики. На вопрос, кто несет ответственность за аналитические системы на предприятии, 73% респондентов указали, что ответственность лежит на отдельной группе специалистов. Почти половина (41%) указала, что эта группа является структурной единицей IT-отдела, ответственной за работу хранилища данных; остальные 40% указали, что эта группа состоит как из IT-специалистов, так и из бизнес-персонала. По всем рассмотренным компаниям, у IT-группы, ответственной за хранилище данных, около 30% рабочего времени выделено на обслуживание систем бизнес-аналитики.
На вопрос о полномочиях принятия решения о приобретении, 39% респондентов указали, что высшее управленческое звено IT-отдела одобрило приобретение аналитических систем, а примерно половина указала, что подобное решение исходило со стороны различных отделов предприятия. Далее, конкретные лица BI-инициатив также оказались распределенными среди многочисленных отделов с отсутствем явно выраженного шаблона. Весьма удивительно, что BI-инициативы часто выдвигаются заказчиками (40%) и бизнес-партнерами (22%).

PivotTable Service, OLE DB for OLAP и ADO MD

Приложения, предназначенные для чтения OLAP-данных, при взаимодействии с аналитическими службами обязательно используют PivotTable Service — библиотеки, загружаемые в адресное пространство клиентского приложения. Эти библиотеки автоматически устанавливаются вместе с аналитическими службами (независимо от того, какая именно их часть установлена — клиентская или серверная), а также вместе с Microsoft Office 2000. В состав Microsoft SQL Server 2000 входит также инсталляционное приложение для установки PivotTable Service на компьютер, на котором не установлены ни аналитические службы, ни Microsoft Office.
PivotTable Service можно использовать в любой 32-разрядной версии Windows для просмотра серверных OLAP-кубов, а также для создания, модификации и чтения локальных OLAP-кубов, созданных в клиентском приложении, реализуя таким образом клиентскую OLAP-функциональность. Эти библиотеки реализуют кэширование в клиентском приложении данных, полученных как с OLAP-сервера, так и из реляционных источников данных. Помимо этого они позволяют осуществлять кэширование данных и на OLAP-сервере, повышая тем самым производительность работы с ним в случае обращения к одним и тем же данным нескольких пользователей.
Для взаимодействия с PivotTable Service клиентское приложение может использовать OLE DB for OLAP — расширение универсального механизма доступа к данным OLE DB, позволяющее обращаться к многомерным данным, а также ADO MD — библиотеки, представляющие собой надстройку над OLE DB for OLAP и являющиеся COM-серверами для доступа к многомерным данным, удобными для применения в клиентских приложениях.
Отметим, что спецификация OLE DB for OLAP является открытой. Это означает, что можно создавать и другие OLAP-серверы, поддерживающие OLE DB for OLAP (либо разрабатывать OLE DB-провайдеры к уже имеющимся OLAP-средствам), а также создавать клиентские приложения, обращающиеся к любым таким источникам данных с помощью PivotTable Service, OLE DB for OLAP и ADO MD.
Пользователи Delphi могут найти примеры применения OLE DB for OLAP и ADO MD в нашей статье "Borland Delphi и расширения ADO".

Предметно-ориентированные аналитические системы

Такие системы очень разнообразны, поэтому рассмотрим здесь один из наиболее типичных и важных классов этих систем, а именно системы анализа финансовых рынков, построенные на основе методов технического анализа. Технический анализ представляет собой совокупность нескольких десятков методов прогноза динамики цен и выбора оптимальной структуры инвестиционного портфеля, основанных на различных эмпирических моделях динамики рынка. Эти методы могут быть весьма просты (как, например, методы, использующие вычитание трендового значения), а могут иметь достаточно сложную математическую основу - скажем фрактальную математику или спектральный анализ. Поскольку, как правило, вся теория уже "зашита" в эти системы, а не выводится на основании истории рынка, то требования статистической значимости выводимых моделей и возможности их интерпретации для них не имеют смысла. Заметим лишь, что многие из рассматриваемых систем ориентированы на работу на западных рынках, не учитывают наших реалий и поэтому не очень пригодны для применения в России. Третьему требованию они удовлетворяют в большей степени, чем другие обсуждаемые классы систем, оперируют в терминах предметной области, понятных трейдерам и финансовым аналитикам, обычно имеют специализированные интерфейсы для загрузки финансовых данных и обладают другими преимуществами специализированных систем. На рынке имеется великое множество программ этого класса. Как правило, они довольно дешевы (обычно 300-1000 долл.). Из тех, что можно приобрести в России, назовем MetaStock (компания Equis International), SuperCharts (Omega Research), Candlestick Forecaster (IPTC), Wall Street Money (Market Arts).

Приложения Microsoft Office

Из других клиентских приложений, не входящих в состав аналитических служб, но часто используемых для просмотра OLAP-кубов, следует назвать приложения Microsoft Office, в частности Microsoft Excel. С помощью Excel можно обращаться к серверным OLAP-кубам, получая их двух- и трехмерные сечения на листах рабочих книг Excel в виде сводных таблиц, а также создавать локальные OLAP-кубы в виде файлов на основе реляционных данных, доступных с помощью OLE DB (рис. 3).

Рис. 3. Применение Excel в качестве OLAP-клиента
Кроме того, в состав Microsoft Office Web Components входит элемент управления ActiveX PivotTable List, позволяющий реализовать сходную функциональность как в обычном Windows-приложении, так и на HTML-странице, предназначенной для применения внутри корпоративной сети (рис. 4).

Рис. 4. Применение элемента управления PivotTable List в качестве OLAP-клиента
Подробнее о применении Microsoft Office в качестве клиентских приложений для аналитических служб мы расскажем в одной из следующих статей данного цикла.
Пользователи Delphi могут также обратиться к нашим статьям «Delphi, Excel и OLAP» и «Использование Web-компонентов Microsoft Office. Часть 2» (КомпьютерПресс № 12’2000), в которых рассматриваются примеры создания клиентских приложений с использованием Excel и Microsoft Office Web Components.
Отметим, что помимо Microsoft Office существуют и другие коммерческие продукты, предназначенные для обращения к OLAP-данным и создания OLAP-кубов. Кроме того, как мы уже говорили, можно создавать свои собственные приложения, использующие PivotTable Service, OLE DB for OLAP и ADO MD (рис. 5).

Рис. 5. Приложение, использующее PivotTable Service и OLE DB for OLAP

Примеры реализации информационных систем с использованием OLAP

Чтобы утверждения о необходимости и повсеместном распространении OLAP не казались голословными, рассмотрим несколько примеров решения задач с помощью OLAP-инструментов крупными зарубежными предприятиями.
Наш первый пример - одна из крупнейших американских энергетических компаний, Duke Energy, чьи активы превышают 20 миллиардов, а число сотрудников составляет 22 000 человек, работающих в различных подразделениях компании по всему миру. Сферой деятельности компании являются энергетическое обеспечение, обслуживание трубопроводов и поставки электрической энергии, природного газа и сжиженного природного газа. На момент внедрения OLAP компания предполагала выйти на нерегулируемый правительством энергетический рынок и отвоевать себе определенный кусок мирового энергетического бизнеса.
В процессе подготовки к этому новому этапу отдел управления информацией Duke Energy прорабатывал различные возможности применения использовавшихся компанией технологий для управления изменившимися информационными потребностями предприятия и обеспечения ему достойного места на рынке и соответствующего развития. В конечном счете, вопрос заключался в обеспечении своих конечных пользователей доступом к информации, хранящейся в корпоративных базах данных. Специалисты по управлению информацией выяснили, что в процессе принятия решений всем подразделениям, начиная с финансовых отделов и заканчивая кадровыми, исключительно важно иметь доступ к такой информации тогда и там, где она им необходима.
Система, которую Duke Energy использовал до этого момента, была сложной в плане использования и без серьезного вмешательства специалистов по управлению информацией не обеспечивала необходимый предприятию уровень точности и своевременности данных. Планируя апгрейд имеющихся систем поддержки принятия решений таким образом, чтобы сотрудники финансовых и других нетехнических подразделений компании могли наиболее полно использовать корпоративные данные, Duke Energy принял решение о внедрении OLAP-системы.
Была выбрана система поддержки принятия решений от Business Objects. В результате ее внедрения, данные, находящиеся в оперативной базе PeopleSoft и витрине данных IBM DB2 HRMS стали доступны для OLAP-анализа и разнообразных запросов и отчетов различных подразделений компании. Решение использует RDTs (Шаблоны быстрого развертывания, Rapid Deployment Templates), содержащие образцы отчетов, которые пользователи без специальных технических знаний могут настраивать по своему усмотрению для генерации незапланированных запросов к данным и отчетов.
В данном случае компания определила, что предложение Business Objects наилучшим образом отвечает ее потребностям. Но это не значит, что другие решения в чем-то хуже выбранного. Каждое предприятие, принявшее решение о внедрении OLAP, в первую очередь рассматривает оптимальность предложений различных поставщиков применительно к своим собственным проблемам и нуждам. Например, та же фирма Cognos успешно поставляет свои продукты таким серьезным клиентам, как Министерство обороны США и компании Boeing. Являясь клиентом Cognos с 1996 года, Министерство обороны постоянно обновляет имеющиеся системы, дополняя их новыми возможностями и разработками. В ноябре прошлого года финансовым подразделением Министерства (DFAS) была приобретена система бизнес-репортинга и анализа с новыми визуализационными возможностями (Cognos Visualizer), стоимостью 1 миллион долларов. Новое интранет-решение поддерживает инициативу "Business of DFAS", применяющую бизнес-терминологию к работе правительственного агентства, и объединяет данные из множества разрозненных систем, делая их доступными для тысяч сотрудников DFAS и других агентств Министерства через защищенный Интернет-портал. "Визуализатор" преобразует сложные данные в понятную удобную для использования информацию, отображая ее с использованием богатой графики, разнообразных презентационных возможностей и функций оценки данных. Роберт Эш (Robert Ashe), первый вице-президент Cognos, называет данное решение "ядром "электронного Правительства" (e-Government)", обеспечивающего федеральным агентствам возможность использовать Интернет для упрощения и ускорения доступа к необходимой им информации.


Главный специалист по информации DFAS Вэнс Козларич (Vance Kauzlarich) заявил, что процесс принятия решений в его подразделении нуждался в объемном представлении задач и факторов, влияющих на работу Агентства. Внедрение OLAP-технологии позволило создать такую картину для конечных пользователей, получивших в итоге возможность сформировать углубленное представление о работе Агентства, что в свою очередь, будет способствовать улучшению управления и принятия решений соответствующими сотрудниками.
Перед Boeing Company стояла несколько иная задача. Так как все самолеты собраны на заказ и включают до нескольких миллионов различных компонентов, сотрудникам требовалось серьезное бизнес-аналитическое (BI) решение для обработки данных таких существенных объемов. В рамках специальной программы по созданию инфраструктуры для репортинга в сфере принятия решений, 16 июля 2001 года в подразделении коммерческой авиации (Boeing Commercial Airplane unit) начато внедрение продукта Cognos Impromptu Web Reports, с помощью которого 11 500 сотрудников подразделения смогут генерировать через Интернет отчеты к базе данных по накладным и спецификациям на компоненты летательных аппаратов. Руководители Boeing Company полагают, что новое решение сэкономит значительное количество человеко-часов, ранее затрачивавшихся на создание таких отчетов вручную. Все вместе это закономерно будет способствовать улучшению процесса принятия решений.
Дабы не ограничиваться исключительно компаниями, OLAP-продукты которых описаны в предыдущей статье данной рубрики, рассмотрим еще одного крупного поставщика OLAP. Компания MicroStrategy, продукты которой в области OLAP остались за рамками предыдущей статьи данной рубрики, как и большинство лидеров этого рынка, также предлагает специализированные решения для отдельных областей бизнеса - финансов, страхования, здравоохранения, правительственных организаций и др. - на базе MicroStrategy Business Intelligence Platform. Одно из таких решений нашло применение в области энергетики.


Компания KeySpan, крупнейший на северо- востоке США поставщик природного газа, имеющий подразделения в Бруклине, Бостоне и на Лонг-Айленде, управляющий рядом сервисных энергетических компаний и более чем 13 000 сотрудников, использует MicroStrategy Narrowcast Server для обеспечения Нью-Йоркских домовладельцев и предприятий достаточным количеством энергии для отопления и подогрева воды. Narrowcast Server, являющийся ключевым компонентом MicroStrategy Business Intelligence Platform, предоставляет пользователям мощные аналитические возможности и интеллектуальную систему предупреждения. В частности, система посылает предупреждения о снижении или повышении расхода газа относительно проектного на соответствующие адреса электронной почты и пейджеры. Клиенты KeySpan, "продавцы", поставляющие газ конечным пользователям, могут подключиться к Экстранет компании для просмотра и анализа проектного и реального использования газа и принятия обоснованных решений относительно объемов газа, необходимых для передачи по трубопроводам в каждый конкретный день. KeySpan использует технологии MicroStrategy для анализа таких факторов, как исторические данные и погодные условия, чтобы спланировать объемы поставок газа. Narrowcast Server четыре раза в день сравнивает фактический поток газа с запланированным ранее в тот же день и отсылает отчет о неплановых ситуациях по электронной почте или пейджеру соответствующему клиенту KeySpan и оперативным подразделениям, контролирующим вентили трубопровода. Таким образом компании-поставщики могут оптимизировать объемы поставляемого потребителям газа в зависимости от ряда различных факторов.
Для примеров были намеренно выбраны организации циклопических размеров, построившие на основе OLAP-технологий суперсложные информационные системы, стоившие им фантастических затрат. Эти примеры наводят на мысль, что OLAP - вовсе не бесполезная игрушка для сумасшедших ученых-аналитиков, как считают некоторые российские ИТ-специалисты и бизнесмены, а стандартная технология ведения бизнеса, неотъемлимая часть инфраструктуры современной организации.

Распространенность

Предназначение систем бизнес-интеллекта больше не ограничено элитными пользователями из руководителей высшего звена. Теперь бизнес-интеллект затрагивает всю иерархию предприятия. В прошлом, системы бизнес-аналитики были предназначены для обслуживания руководителей и их штата, и предназначались главным образом для анализа финансовых вопросов. Хотя администраторы (75%) и линейное руководство (72%) относятся к категории высших пользователей, конторский персонал рассматривается в качестве пользователей систем бизнес-аналитики в 52% компаний. Сорок пять % компаний теперь поддерживают работу более ста пользователей, а 25 % - более 750 пользователей.

Реализация

Как правило, реализацией проектов интеллектуальных систем занимается внутренний IT-штат, и руководство ожидает немедленной реализации проекта, сопровождающееся быстрой окупаемостью. Респонденты указывают, что внутренний IT-штат действительно включен в реализацию проектов бизнес-интеллекта (70%) и что вовлеченность IT-специалистов будет постоянно увеличиваться (66%). Напротив, только 23% указали, что системные интеграторы включены в реализацию подобных проектов, и лишь 33% указали, что участие системных интеграторов увеличится. Удивительным результатом является то, что лишь 8% используют сервис-провайдеров для реализации конкретного сервиса бизнес-интеллекта; однако 33% ожидают, что сервис-провайдеры увеличат свое участие.
На вопрос о соответствующем возврате капиталовложений для инвестиций в системы бизнес-интеллекта, респоденты (66% лиц, занимающихся финансовым планированием) указали, что проекты внедрения систем бизнес-интеллекта должны иметь срок возврата инвестиций меньше одного года.

Рисунок 2: Приложения бизнес-интеллекта

Репозитарий аналитических служб

При создании описаний OLAP-кубов с помощью библиотек SQL DSO эти описания, или метаданные, сохраняются в репозитарии. Сами же данные сохраняются в каталоге, указанном при установке Analysis Services (впоследствии его местоположение можно изменить).
По умолчанию репозитарий аналитических служб представляет собой базу данных Access msmdrep.mdb, расположенную в каталоге Microsoft Analysis Services\Bin, который при необходимости можно перенести и в базу данных Microsoft SQL Server. Текущая версия аналитических служб не поддерживает сохранение репозитария в базах данных других СУБД, в то время как само исходное реляционное хранилище данных может содержаться в любой СУБД, доступной с помощью универсальных механизмов доступа к данным OLE DB и ODBC.
Создание приложений для чтения и записи в репозитарий с помощью средств, отличных от библиотек SQL DSO, не рекомендуется, так как структура репозитария не документирована и может быть изменена в последующей версии аналитических служб.
В следующей статье данного цикла мы рассмотрим процесс создания многомерной базы данных и OLAP-кубов с помощью Analysis Manager.

Рыночные ожидания

Рынок систем бизнес-интеллекта находится в полном расцвете сил и быстро растет. В недавнем прошлом, этот рынок был маленьким сегментом других рынков, таких как управление базами данных и инструментальные средства генерации отчетов. Теперь же рынок BI быстро растет, в соответствии с возрастанием интереса к таким приложениям бизнес-интеллекта, как CRM. Большинство респондентов (89%) ожидают рост рынка бизнес-интеллекта, а 23% ожидают взрывобразного роста в недалеком будущем. Буквально каждый опрошенный утверждал о финансовой выгоде от применения приложений бизнес-интеллекта, а 50% ответило, что эта выгода "весьма значительна".
30% опрошенных указали, что их бюджет на системы бизнес-интеллекта составляет около одного миллиона долларов или превышает эту сумму. 6% компаний имеют BI-бюджет 50 миллионов долларов или более. Нет никакой очевидной корреляции между BI-бюджетом и промышленностью. У 25% компаний бюджет систем бизнес-интеллекта имеет постоянный здоровый годовой рост на 30% или более, и 8% опрошенных ожидают удвоения бюджета в ближайшие два или три года.

Системы рассуждений на основе аналогичных случаев

Идея систем case based reasoning - CBR - крайне проста. Для того чтобы сделать прогноз на будущее или выбрать правильное решение, эти системы находят в прошлом близкие аналоги наличной ситуации и выбирают тот же ответ, который был для них правильным. Поэтому этот метод еще называют методом "ближайшего соседа" (nearest neighbour). Системы CBR показывают очень хорошие результаты в самых разнообразных задачах. Главный их минус заключается в том, что они вообще не создают каких-либо моделей или правил, обобщающих предыдущий опыт, - в выборе решения они основываются на всем массиве доступных исторических данных, поэтому невозможно сказать, на основе каких конкретно факторов CBR системы строят свои ответы. Примеры систем, использующих CBR, - KATE tools (Acknosoft, Франция), Pattern Recognition Workbench (Unica, США).

Службы преобразования данных

Источником данных для кубов OLAP, как правило, является реляционное хранилище данных. Сами по себе аналитические службы не содержат средств для пополнения реляционного хранилища данными из оперативных баз данных, с которыми работают пользователи. Однако такие средства содержат многие современные серверные СУБД.
В частности, в Microsoft SQL Server средства для переноса данных из одной реляционной СУБД в другую с возможным их преобразованием, которые можно применять и для пополнения хранилищ данных, называются службами преобразования данных (Data Transformation Services, DTS). Службы преобразования данных могут быть использованы не только с Microsoft SQL Server, но и с любыми другими источниками данных, доступными через универсальный механизм доступа к данным OLE DB (более подробное описание OLE DB и ADO вы найдете в книге «Базы данных для всех», которая будет выпущена издательством «КомпьютерПресс» этим летом).
Отметим, что DTS позволяют использовать дополнительные модули расширения (plug-ins) и в состав аналитических служб входит одно из таких расширений, позволяющее обновлять OLAP-кубы.

Состояние рынка систем бизнес-интеллекта

Основанная на телефонных интервью со 100 компаниями, это исследование анализирует тенденции важных изменений рынка приложений бизнес-интеллекта (BI - business intelligence). Спонсором этой публикации является DM Review, чья база данных подписчиков насчитывает более 72 тысяч профессионалов, работающих в области информационных технологий. В ходе опроса, бизнес- и IT-менеджерам задавался вопрос, вовлечены ли они непосредственно в работу с существующими BI-системами или планируют существенные капиталовложения в BI-системы на ближайший год.
Движущая сила изменений на рынке бизнес-интеллекта - электронная коммерция с ее цифровой экономикой мгновенных глобальных транзакций, требующей интеграции наследуемых систем. Компании вынуждены заново продумать и реорганизовать свои бизнес-процессы как часть процесса миграции в мир электронной коммерции. Потребности в структурированных сведениях о заказчиках, поставщиках, дистрибуторах, партнерах и конкурентах становятся все более и более острыми. Именно поэтому бизнес-интеллект стал центральным компонентом для любой эффективной инициативы электронной коммерции. В понятии бизнес-интеллекта включены такие современнейшие технологии, как управление взаимоотношениями с клиентами, анализ логистических цепочек, автоматизация продаж, дистрибутивные каналы и технологические прогнозы.
По общему убеждению, главная цель бизнес-интеллекта состоит в более мудром и за счет этого более гладком выполнении бизнес-процессов.
Давайте рассмотрим, что стоит за этим утверждением.
С точки зрения исторической перспективы, рынок бизнес-интеллекта традиционно был сосредоточен на поддержке принятия управленческих решений, с использованием технологии хранения данных, запросов/репортинга, многомерного анализа, добычи данных и информационных порталов.
В прошлом десятилетии этот набор технологий хорошо нам послужил. Бизнес-интеллект уменьшил риск и время принятия решений в областях бизнеса, имеющих дело с нетрадиционными, непредвиденными и запутанными ситуациями.
Вследствие этого успеха, рынок бизнес-интеллекта находится в постоянном напряжении, вызванном необходимостью поддержки самых разнообразных направлений - управления взаимоотношениями с клиентами, передовых вертикальных решений для таких областей, как телекоммуникации и здравохранение, и таких новейших технологий, как управление знаниями и интеллектуальный анализ текстовых данных.

Некоторые думают, что системы бизнес-интеллекта будут фрагментироваться на небольшие приложения и затем внедряться в конечные системы, тем самым навсегда исчезнув из поля зрения IT-специалистов. Другие специалисты находятся в неуверенности относительно динамики развития систем бизнес-интеллекта в наступающие годы. Следовательно, есть огромная неуверенность в рядах IT-специалистов, планирующих и реализующих системы бизнес-интеллекта, и в рядах поставщиков, разрабатывающих интеллектуальные продукты и сервисы.

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

Советы практикам бизнес-интеллекта

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

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

Исследуйте, как внешние источники данных могут расширять функциональность хранилища данных.

Определите и задокументируйте проблемы конфиденциальности, которые влияют на работу вашей компании, и старайтесь внедрять промышленные стандарты.

Постоянно улучшайте уровень навыков внутреннего IT-штата в соответствиями с концепциями и практикой бизнес-интеллекта.

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

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

Рассмотрите возможности вашей системной архитектуры к гладкому масштабированию. Быстро растущие интеллектуальные системы зачастую требуют адекватного увеличения ресурсов.

Аналогично, мы можем посоветовать поставщикам систем бизнес-интеллекта:

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

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

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

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

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

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

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

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

Современная роль приложений бизнес-интеллекта

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

SQL DSO

Decision Support Objects (DSO)— это набор библиотек, содержащих COM-объекты, позволяющие создавать и модифицировать многомерные базы данных и содержащиеся в них объекты (кубы, коллективные измерения и т.д.). Отметим, что Analysis Manager — приложение, использующее SQL DSO, — входит в состав аналитических служб.
Эти библиотеки можно использовать для разработки собственных приложений, в которых осуществляется создание или модификация многомерных баз данных, в том числе и для реализации действий, не предусмотренных в клиентских утилитах, входящих в состав аналитических служб (рис. 1).

Рис. 1. Приложение, использующее SQL DSO
Отметим, что SQL DSO можно использовать только для доступа к аналитическим службам Microsoft. Ни к каким другим OLAP-серверам с помощью этих библиотек обратиться нельзя.
Более подробно о применении SQL DSO мы расскажем в отдельной статье.

Средства добычи знаний в бизнесе и финансах

1. Классы систем интеллектуального анализа данных, применяемые в бизнесе и финансах
1.1. Предметно-ориентированные аналитические системы
1.2. Статистические пакеты
1.3. Нейронные сети
1.4. Системы рассуждений на основе аналогичных случаев
1.5. Деревья решений (decision trees)
1.6. Генетические алгоритмы
1.7. Нелинейные регрессионные методы
1.8. Эволюционное программирование
2. Тестовая задача
Вместо заключения, или "если очень хочется, то это только кажется"
Компьютерные технологии автоматического интеллектуального анализа данных переживают бурный расцвет. Это связано главным образом с потоком новых идей, исходящих из области компьютерных наук, образовавшейся на пересечении искусственного интеллекта, статистики и теории баз данных и обозначаемой как KDD (knowledge discovery in databases - обнаружение знаний в базах данных). Сейчас происходит лавинообразный рост числа программных продуктов, использующих технологии KDD, а также типов задач, где их применение дает значительный экономический эффект. Элементы автоматической обработки и анализа данных становятся неотъемлемой частью концепции электронных хранилищ данных и часто именуются в этом контексте data mining (добыча знаний из данных). На российском рынке эта технология делает лишь первые шаги. Отчасти это можно объяснить высокой стоимостью систем data mining, но, как показывает история развития других сегментов компьютерного рынка России, сам по себе этот фактор вряд ли является определяющим. Скорее здесь проявляется действие некоторых специфичных для России негативных факторов, резко уменьшающих эффективность применения технологии data mining. Постараемся определить эти факторы, проанализировать степень подверженности им различных классов систем интеллектуального анализа данных, а также выделить свойства таких систем, облегчающие российским покупателям их применение.
Начнем с характеристики российской специфики. Компьютерные системы поддержки принятия решений, в принципе, могут основываться на двух подходах.
Другой отличительной чертой российской экономики, как на макро-уровне, так и на уровне отдельных предприятий, является ее нестабильность; кроме того, она подвержена и действию многочисленных, неожиданно возникающих факторов. В то время как на Западе предприятия в основном работают в рамках уже устоявшейся законодательной базы, в сложившихся структурах товарных, финансовых и информационных потоков, российские предприятия вынуждены подстраиваться под постоянно меняющиеся правила игры. Это же касается российских финансовых рынков (например, ГКО), где примерно раз в полгода происходит существенная корректировка правил работы. Итак, человек должен обязательно контролировать и анализировать результаты, получаемые системами data mining. Это нужно, чтобы гарантировать учет всех влияющих на решение факторов. Как следствие, построенные модели должны быть прозрачны и допускать интерпретацию.

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

Названные факторы в большой степени определяют динамику продвижения data mining в России и будут определять ее еще 1,5-2 года.Рассмотрим теперь существующие классы систем добычи знаний и проанализируем их с точки зрения этих факторов, а затем проиллюстрируем данный анализ на примере одной из типичнейших задач из области финансовых рынков.

Статистические пакеты

Хотя последние версии почти всех известных статистических пакетов включают наряду с традиционными статистическими методами также элементы data mining, основное внимание в них уделяется все же классическим методикам - корреляционному, регрессионному, факторному анализу и другим. Главный недостаток систем этого класса - их невозможно эффективно применять для анализа данных, не имея глубоких знаний в области статистики. Неподготовленный пользователь должен пройти специальный курс обучения. Обычно в процессе исследования данных с помощью статистических пакетов приходится многократно применять набор из одних и тех же элементарных операций, однако в этих системах средства автоматизации процесса исследования либо отсутствуют, либо требуют программирования на некотором внутреннем языке, что также редко по силам пользователю, если он не статистик и не программист. Все эти факторы делают мощные современные статистические пакеты слишком тяжеловесными для массового применения в финансах и бизнесе. К тому же часто эти системы весьма дороги - от 1000 до 8000 долл. В качестве примеров, доступных в России, можно назвать SAS (компания SAS Institute), SPSS (SPSS) и Statgraphics (Statistical Graphics).

Таблица фактов

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

факты, связанные с транзакциями (Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата);

факты, связанные с «моментальными снимками» (Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка;

факты, связанные с элементами документа (Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);

факты, связанные с событиями или состоянием объекта (Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей).

Для примера рассмотрим факты, связанные с элементами документа (в данном случае счета, выставленного за товар).
Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа «дата/время»— ведь таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней повторяющиеся текстовые описания, как правило, невыгодно — лучше поместить их в меньшие по объему таблицы измерений. При этом как ключевые, так и некоторые неключевые поля должны соответствовать будущим измерениям OLAP-куба. Помимо этого таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем будут получены агрегатные данные.
Пример таблицы фактов, которая может быть построена на основе базы данных Northwind, приведен на рис. 2.



Рис. 2. Пример таблицы фактов
В данном примере измерениям будущего куба соответствуют первые шесть полей, а агрегатным данным — последние четыре.
Отметим, что для многомерного анализа пригодны таблицы фактов, содержащие как можно более подробные данные (то есть соответствующие членам нижних уровней иерархии соответствующих измерений). В данном случае предпочтительнее взять за основу факты продажи товаров отдельным заказчикам, а не суммы продаж для разных стран — последние все равно будут вычислены OLAP-средством. Исключение можно сделать, пожалуй, только для клиентских OLAP-средств (о них мы поговорим чуть позже), поскольку в силу ряда ограничений они не могут манипулировать большими объемами данных.
Отметим, что в таблице фактов нет никаких сведений о том, как группировать записи при вычислении агрегатных данных. Например, в ней есть идентификаторы продуктов или клиентов, но отсутствует информация о том, к какой категории относится данный продукт или в каком городе находится данный клиент. Эти сведения, в дальнейшем используемые для построения иерархий в измерениях куба, содержатся в таблицах измерений.

Таблицы измерений

Таблицы измерений содержат неизменяемые либо редко изменяемые данные. В подавляющем большинстве случаев эти данные представляют собой по одной записи для каждого члена нижнего уровня иерархии в измерении. Таблицы измерений также содержат как минимум одно описательное поле (обычно с именем члена измерения) и, как правило, целочисленное ключевое поле (обычно это суррогатный ключ) для однозначной идентификации члена измерения. Если будущее измерение, основанное на данной таблице измерений, содержит иерархию, то таблица измерений также может содержать поля, указывающие на «родителя» данного члена в этой иерархии. Нередко (но не всегда) таблица измерений может содержать и поля, указывающие на «прародителей», и иных «предков» в данной иерархии (это обычно характерно для сбалансированных иерархий), а также дополнительные атрибуты членов измерений, содержавшиеся в исходной оперативной базе данных (например, адреса и телефоны клиентов).
Каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов.
Отметим, что скорость роста таблиц измерений должна быть незначительной по сравнению со скоростью роста таблицы фактов; например, добавление новой записи в таблицу измерений, характеризующую товары, производится только при появлении нового товара, не продававшегося ранее.
Пример таблицы измерений приведен на рис. 3.


Рис. 3. Пример таблицы измерений
Одно измерение куба может содержаться как в одной таблице (в том числе и при наличии нескольких уровней иерархии), так и в нескольких связанных таблицах, соответствующих различным уровням иерархии в измерении. Если каждое измерение содержится в одной таблице, такая схема хранилища данных носит название «звезда» (star schema). Пример такой схемы приведен на рис. 4.

Рис. 4. Пример схемы «звезда»
Если же хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка» (snowflake schema). Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находящиеся в соотношении «один ко многим» в главной таблице измерений, соответствующей нижнему уровню иерархии, иногда называют консольными таблицами (outrigger table).
Пример схемы «снежинка» приведен на рис. 5.

Рис. 5. Пример схемы «снежинка»
Отметим, что даже при наличии иерархических измерений с целью повышения скорости выполнения запросов к хранилищу данных нередко предпочтение отдается схеме «звезда».
Однако не все хранилища данных проектируются по двум приведенным выше схемам. Так, довольно часто вместо ключевого поля для измерения, содержащего данные типа «дата», и соответствующей таблицы измерений сама таблица фактов может содержать ключевое поле типа «дата». В этом случае соответствующая таблица измерений просто отсутствует.
В случае несбалансированной иерархии (например, такой, которая может быть основана на таблице Employees базы данных Northwind, имеющей поле EmployeeID, которое одновременно является и первичным, и внешним ключом и отражает подчиненность одних сотрудников другим (см. рис. 1) в схему «снежинка» также следует вносить коррективы. В этом случае обычно в таблице измерений присутствует связь, аналогичная соответствующей связи в оперативной базе данных.
Еще один пример отступления от правил — наличие нескольких разных иерархий для одного и того же измерения. Типичные примеры таких иерархий — иерархии для календарного и финансового года (при условии, что финансовый год начинается не с 1 января), или с различными способами группировки членов измерения (например, группировать товары можно по категориям, а можно и по компаниям-поставщикам). В этом случае таблица измерений содержит поля для всех возможных иерархий с одними и теми же членами нижнего уровня, но с разными членами верхних уровней (пример такой таблицы приведен на рис. 3).
Как мы уже отмечали выше, таблица измерений может содержать поля, не имеющие отношения к иерархиям и представляющие собой просто дополнительные атрибуты членов измерений (member properties). Иногда такие атрибуты могут быть использованы при анализе данных.
Более подробно о проектировании хранилищ данных и одном из CASE-инструментов, способных упростить процесс их создания, — CA ERwin, рассказано в статье Сергея Маклакова «Хранилища данных и их проектирование с помощью CA ERwin», КомпьютерПресс, CD-ROM № 1’2001).
Следует сказать, что для создания реляционных хранилищ данных нередко применяются специализированные СУБД, хранение данных в которых оптимизировано с точки зрения скорости выполнения запросов. Примером такого продукта является Sybase Adaptive Server IQ, реализующий нетрадиционный способ хранения данных в таблицах (не по строкам, а по столбцам). Однако создавать хранилища можно и в обычных реляционных СУБД.
Итак, обсудив типичную структуру хранилища данных, на основе которых обычно строятся OLAP-кубы, вернемся к созданию OLAP-кубов и поговорим о том, какими бывают OLAP-инструменты.

Технические аспекты многомерного хранения данных

В многомерных хранилищах данных содержатся агрегатные данные различной степени подробности, например, объемы продаж по дням, месяцам, годам, по категориям товаров и т.п. Цель хранения агрегатных данных — сократить время выполнения запросов, поскольку в большинстве случаев для анализа и прогнозов интересны не детальные, а суммарные данные. Поэтому при создании многомерной базы данных всегда вычисляются и сохраняются некоторые агрегатные данные.
Отметим, что сохранение всех агрегатных данных не всегда оправданно. Дело в том, что при добавлении новых измерений объем данных, составляющих куб, растет экспоненциально (иногда говорят о «взрывном росте» объема данных). Если говорить более точно, степень роста объема агрегатных данных зависит от количества измерений куба и членов измерений на различных уровнях иерархий этих измерений. Для решения проблемы «взрывного роста» применяются разнообразные схемы, позволяющие при вычислении далеко не всех возможных агрегатных данных достичь приемлемой скорости выполнения запросов.
Как исходные, так и агрегатные данные могут храниться либо в реляционных, либо в многомерных структурах. Поэтому в настоящее время применяются три способа хранения данных:

MOLAP (Multidimensional OLAP) –— исходные и агрегатные данные хранятся в многомерной базе данных. Хранение данных в многомерных структурах позволяет манипулировать данными как многомерным массивом, благодаря чему скорость вычисления агрегатных значений одинакова для любого из измерений. Однако в этом случае многомерная база данных оказывается избыточной, так как многомерные данные полностью содержат исходные реляционные данные.

ROLAP (Relational OLAP) — исходные данные остаются в той же реляционной базе данных, где они изначально и находились. Агрегатные же данные помещают в специально созданные для их хранения служебные таблицы в той же базе данных.

HOLAP (Hybrid OLAP) — исходные данные остаются в той же реляционной базе данных, где они изначально находились, а агрегатные данные хранятся в многомерной базе данных.

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

Технологии доступа к аналитическим службам из клиентских приложений

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

Технологии интеллектуального анализа данных (ИАД)

Под ИАД следует понимать сложный анализ "очищенных" данных с использованием математических методов машинного обучения, таких как: статистические методы, нейронные сети, искусственный интеллект, генетические алгоритмы, деревья решений и т. д., а также, результаты их применения - методов представления данных. Смысл использования сложного анализа данных сведен к формулировке "получения новой информации из данных".
К информационным технологиям ИАД сегодня относятся:
I. Оперативный анализ данных
В основе концепции OLAP-систем лежит принцип многомерного представления данных: каждое числовое значение, содержащееся в ИХ, может иметь до нескольких десятков (сотен) атрибутов. Одним из существенных недостатков реляционной модели БД является невозможность объединять, просматривать и анализировать данные с точки зрения многомерности измерений, то есть наиболее понятным для аналитиков способом. С целью расширения функциональных возможностей традиционных реляционных СУБД следует включить многомерный анализ как одну из характеристик, так как: "реляционные БД были, есть и будут наиболее подходящей технологией для хранения корпоративных данных. Необходимость существует не в создании новой технологии разработки баз данных, а в средствах анализа, дополняющих функции существующих СУБД и достаточно гибких, чтобы автоматизировать интеллектуальную деятельность руководителя".
Многомерное представление данных представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению.
По типу используемой базы данных все OLAP-системы делятся на три класса:

1. Системы оперативной аналитической обработки многомерных баз данных (или MOLAP-системы), в которых данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:

1. гиперкубов - все хранимые в БД ячейки должны иметь одинаковую мерность, то есть находиться в максимально полном базисе измерений;

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

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


3. Гибридные системы оперативной аналитической обработки данных (Hybrid OLAP, HOLAP-системы) разработаны с целью совмещения достоинств и минимизации недостатков предыдущих систем. Они объединяют аналитическую гибкость и скорость ответа MOLAP-систем с постоянным доступом к реальным данным, свойственным ROLAP-системам.

II. Исследование данных (Data Mining)

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

III. Извлечение знаний из баз данных (Knowledge Discovery in Databases)

Технология представляет новое направление в области ИАД, где процесс поиска закономерностей в данных рассматривается как процесс машинного обучения. Технология объединяет в себе вопросы моделирования закономерностей и зависимостей в базах данных и определяет математические методы построения систем "открытия" (извлечения, добычи) новых данных на основе методов классификации, кластеризации, построения деревьев решений и др.

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

Основными компонентами концептуальной модели СИППР являются:

Информационное хранилище данных.

Организуется на платформе мощной СУБД. Поскольку размеры хранилища могут достигать сотен гигабайт и больше, используемая СУБД должна поддерживать, технологию "больших баз данных" (VLDB, Very Large Database). Для организации БД хранилищ целесообразно использовать программные продукты таких производителей как: Microsoft, IBM, Oracle, Informics, Terradata и аналогичных.

Средства погружения данных.

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

Одним из основных требований, предъявляемых к этим средствам, является обеспечение возможности доступа к различным источникам данных, что обеспечивается за счет использования универсального интерфейса доступа к данным (например, типа ODBC, OLE DB и т.д.).

Витрины данных.

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

Генераторы запросов, информационно-поисковые системы в области детализированных данных, нацеленных на поиск информации в реляционных СУБД.

Общепризнанным стандартом языка манипулирования реляционными данными признан SQL. Информационно-поисковые системы, обеспечивающие интерфейс конечного пользователя в задачах поиска детализированной информации, могут использоваться в качестве надстроек, как над отдельными БД, так и над ИХ.



Рисунок 1. Концептуальная модель системы интеллектуальной поддержки принятия решений

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

Системы ИАД и системы извлечения знаний из ИХ. Главными задачами являются поиск функциональных и логических закономерностей в накопленной информации, а также построение аналитических моделей и решающих правил, которые объясняют выявленные взаимосвязи и способны прогнозировать развитие бизнес-процессов.

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


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

Система "Darwin", разработанная компанией Thinking Machines (Бедфорд, шт. Массачусетс) позволяет строить модели на основе нейросетей и деревьев решений, а также использовать методы визуализации и классификации данных.

Пакет "PowerPlay 5.0" фирмы Cognos - выполняет многомерный анализ данных, включающих до двух и более миллионов записей, в масштабе корпоративного предприятия (свыше 2000 пользователей). Система позволяет: построение трехмерных графиков и диаграмм, ранжирование данных, немедленный возврат к верхнему уровню иерархии данных и систем меню, полностью определяемых ЛПР.

ROLAP-cистема "DSS Agent" компании MicroStrategy (Виенна, шт. Виргиния) представляет для построения ИХ интегрированный набор инструментов и методов объединения данных из разнородных источников.

Проект "Pablo for Windows" фирмы Andyne Computing (Кингстон, Канада) представляет СППР, позволяющую просматривать обобщенные выборки на основе данных из реляционных баз данных и манипулировать ими.

Программный пакет "Integrity Data Re-engineering Tool" производства компании Vality Technology. Представляет среду программирования, используемую для исследования, стандартизации и интегрирования данных из различных источников. "Integrity" выявляет новую информацию и наборы правил из оперативных данных, что позволяет разработчикам ИХ планировать и определять модели данных, которые бы правильно отображали сложности реального мира.

Продукты хранения данных фирмы Red Brick Systems, позволяющие: быстро разрабатывать и устанавливать приложения для управления; строить запросы к БД любого размера с информацией, собранной от разнородных источников; обеспечивать наилучший доступ к обобщающей и детальной информации в единой базе данных.

В качестве российских разработок следует отметить:


1. Нейронно-сетевой пакет "STATISTICA Neural Networks" компании StatSoft-Россия, предоставляющий возможность автоматически получать эффективные решения слабоструктурированных задач, в которых использование традиционных статистических методов является нерациональным.

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

2. Система "PolyAnalyst", представленная российской компанией Megaputer Intelligence в качестве инструментария для автоматического извлечения из данных решающих правил, зависимостей и других знаний, на основе которых могут приниматься управляющие решения.

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

3. OLAP-средства, в качестве приложений, внедряют в свои системы такие лидеры российского информационного рынка как "1 C", "Парус" и другие.

Нельзя не отметить и нашедшие широкое распространение CASE-средства, предназначенные для разработки подобных систем. Большую популярность завоевал такой продукт как ERwin® 4.0 (http://www.interface.ru/fset.asp?Url=/ca/news/pr010124798.htm) – представляющий промышленный инструментарий для моделирования данных, разработанный для поддержки структурного подхода к управлению информацией.

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

Технологии построения информационных хранилищ данных

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

очищаются - устранение ненужной информации;

агрегируются - вычисление сумм, средних;

трансформируются - преобразование типов данных, реорганизация структур хранения;

объединяются из внешних и внутренних источников – приведение к единым форматам;

синхронизируются - соответствие одному моменту времени.

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

Целостность и внутренняя взаимосвязь.

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

Предметная ориентированность.

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

Отсутствие временной привязки.

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

Доступность исключительно для чтения.

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

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

Использование технологий ИХ стало возможно благодаря следующим факторам:

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

снижение стоимости средств хранения информации дает возможность хранить данные, накопленные за длительные интервалы времени, с высокой степенью детализации;

снижение стоимости ЭВТ сложных архитектур;

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

Однако, информационные хранилища данных представляют только перспективную архитектуру построения СИППР масштаба корпоративного предприятия и является центральной ее частью. Для построения полнофункциональной СИППР необходимы специальные программные средства, ориентированные на аналитические технологии обработки данных - технологии интеллектуального анализа данных (ИАД).

Тестовая задача

Чтобы проиллюстрировать относительные преимущества и недостатки описанных методов и систем, а также чтобы как-то оценить реальный экономический эффект от их применения, используем их для решения одной и той же задачи - управления портфелем из двух наиболее ликвидных акций российских предприятий - Мосэнерго (MSNG) и "Норильский никель" (NKEL). Рассмотрим такую упрощенную стратегию, при которой на каждую из этих акций отводится половина портфеля, и мы можем либо полностью продать все акции MSNG или NKEL, либо купить их на сумму, составляющую ровно половину от стоимости портфеля. Для выработки правил, определяющих условия, при которых акции нужно покупать или продавать с помощью рассмотренных методов, мы использовали историю рынка за период 1 сентября 1995 - 5 января 1997 гг. Для проверки полученной информации был взят период с 6 января 1997 по 28 февраля 1997 гг. Мы решали эту задачу при помощи следующих систем и методов:
·  технический анализ - устранение тренда с оптимальной шириной окна; дерево решений (SIPINA);
·  генетический алгоритм (GeneHunter);
·  нейронная сеть - перцептрон с тремя скрытыми слоями и обратным распространением ошибки (NeuroShell);
·  метод группового учета атрибутов (NeuroShell);
·  метод "ближайшего соседа" (Unica); PolyAnalyst.
Применяя каждую систему, мы использовали установленные по умолчанию настроечные параметры, как это сделал бы пользователь-неспециалист. Разумеется, трудно делать какие-то надежные выводы по результатам решения одной задачи, однако эти результаты все же весьма показательны.
Чтобы оценить эффективность каждого из тестируемых методов, мы сравнивали доходность (измеряемую в процентах годовых) управления нашим портфелем с помощью полученных ими правил и доходность, которую мы получили бы, если бы просто держали эти акции в течение всего периода. Разница этих показателей для каждой методики в обучающем и тестовом периодах показана на рис. 1.

Рисунок 1.
Сравнительная доходность при использовании каждой методики.

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

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



Рисунок 2.
Разница в управлении портфелем акций.

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

Результаты, полученные на тестовом примере, в целом подтверждают корректность сделанного выделения основных требований, определяющих успешность применения систем добычи данных к российским задачам. Как видно из рисунков, в этом примере положительные результаты были продемонстрированы тремя системами из семи (PolyAnalyst, Pattern Recognition Workbench, а также одним из стандартных методов технического анализа).

Типичная структура хранилищ данных

Как мы уже знаем, конечной целью использования OLAP является анализ данных и представление результатов этого анализа в виде, удобном для восприятия и принятия решений. Основная идея OLAP заключается в построении многомерных кубов, которые будут доступны для пользовательских запросов. Однако исходные данные для построения OLAP-кубов обычно хранятся в реляционных базах данных. Нередко это специализированные реляционные базы данных, называемые также хранилищами данных (Data Warehouse). В отличие от так называемых оперативных баз данных, с которыми работают приложения, модифицирующие данные, хранилища данных предназначены исключительно для обработки и анализа информации, поэтому проектируются они таким образом, чтобы время выполнения запросов к ним было минимальным. Обычно данные копируются в хранилище из оперативных баз данных согласно определенному расписанию.
Типичная структура хранилища данных существенно отличается от структуры обычной реляционной СУБД. Как правило, эта структура денормализована (это позволяет повысить скорость выполнения запросов), поэтому может допускать избыточность данных.
Для дальнейших примеров мы снова воспользуемся базой данных Northwind, входящей в комплекты поставки Microsoft SQL Server и Microsoft Access. Ее структура данных приведена на рис. 1.

Рис. 1. Структура базы данных Northwind
Основными составляющими структуры хранилищ данных являются таблица фактов (fact table) и таблицы измерений (dimension tables).

Вместо заключения, или "если очень хочется, то это только кажется"

Рассмотренные объективные факторы, имеющие экономические корни, конечно, существенно влияют на процесс внедрения систем KDD как нового продукта на рынке программного обеспечения. Но если даже указанные проблемы частично будут решены, останется еще ряд "подводных течений", часто субъективного плана, играющих не меньшую роль.
Действительно, основным сдерживающим фактором развития сферы аналитических услуг являлся низкий спрос. Платежеспособные потребители были слабо заинтересованы в получении эффективных решений - экономическая конъюнктура позволяла получать прибыль другими способами. Сейчас, казалось бы, изменился инвестиционный климат, появился спрос на аналитический консалтинг, более того, производителям и продавцам программного обеспечения есть что предложить - рынок, вроде бы, созрел и снизу, и сверху. Проблема, однако, не в том, чтобы предложить нужный инструмент - оказалось, что потенциальные пользователи не могут его взять.
Причина банальна. KDD не просто рыночный продукт - это идеология, способ мышления. Эффективное использование KDD невозможно без конкретного человека. Ситуацию с приобретением программного продукта, реализующего KDD, зачастую можно сравнить с покупкой правил игры в шахматы в комплекте с доской. А кто будет играть? И как долго учиться?
Сегодня ощущается явный технологический и системный разрыв между разработчиками и пользователями. Разрыв на уровне языка общения, общих понятий, подхода к проблеме. Например, системщик, формулируя на своем языке указанные в начале статьи экономические факторы, характеризующие специфику российского рынка, при построении и исследовании математической модели обязательно отметит:
·  наличие на рынке нескольких взаимосвязанных систем, интересы которых могут не совпадать;
·  наличие возмущений, помех, ошибок измерений и другого рода неопределенностей, о которых в ряде случаев известны лишь границы изменений, а какие-либо вероятностные характеристики отсутствуют;
·  сами системы меняются со временем;

·  возможность влияния на системы по принципу обратной связи;

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

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

Что отсюда следует? Продвинутые предприниматели осознали, что KDD - реальный способ повышения эффективности работы. Вопрос не в том, нужны ли новые технологии, а в том, как их применить в каждом конкретном случае. Затраты на постановку задачи и сопровождение KDD могут на порядок превышать стоимость отдельного пакета программ: очевидно, что стоит потратить часть денег на обучение специалистов - в итоге выйдет дешевле и эффективнее. Возрастает роль специализированных консалтинговых фирм, осуществляющих комплексное сопровождение проектов, включая диагностику задачи, анализ методов решения, выработку рекомендаций, реализацию выбранного подхода, сопровождение, оптимизацию.

Внешние воздействия

Системы бизнес-интеллекта больше не ограничены выполнением внутренних функций. Они взаимодействуют со многими внешними для предприятия областями.
Наши респонденты подтверждали традиционные цели и функции для систем бизнес-интеллекта, например такие, как периодический репортинг для управленческого звена. В частности, согласно ответам 75% респондентов, "гибкий анализ по мере возникновения бизнес-проблем" является целью наивысшего приоритета для систем бизнес-аналитики.
Однако, весьма неожиданным фактом стала внешняя ориентация аналитических систем. Существенное количество компаний "поставляет информацию своим заказчикам в качестве обратной связи" (53%) и составляет отчеты для "поставщиков и бизнес-партнеров" (19%). Пользователи аналитических систем идут за пределы внутреннего управления, обеспечивая поддержку для заказчиков (43%), бизнес-партнеров (35%), поставщиков (21%) и дистрибуторов (17%). Доступ к среде хранилищ данных расширяется до "основанного на Web распространения информации для всех групп пользователей" (36%) и "персонализации информации для всех пользователей" (34%). Маркетинг (79%) и анализ отношений с заказчиками (70%) занимает почти такое же место, как и традиционные приложения бизнес-интеллекта, такие как финансовый анализ (82%) и анализ прибыльности (70%).

Введение в OLAP: часть Архитектура Microsoft Analysis Services

Что представляют собой аналитические службы
Что хранится в многомерной базе данных
Технологии доступа к аналитическим службам из клиентских приложений
SQL DSO
PivotTable Service, OLE DB for OLAP и ADO MD
Клиенты аналитических служб
Analysis Manager
Приложения Microsoft Office
Заключение
Службы преобразования данных
Репозитарий аналитических служб
В предыдущих статьях данного цикла (КомпьютерПресс № 4, 5’2001) мы рассказали об основах OLAP (On-Line Analytical Processing) — технологии многомерного анализа данных, а также рассмотрели типичную структуру хранилищ данных и некоторые технические аспекты многомерного хранения данных. Настоящая статья посвящена типичной архитектуре OLAP-служб, рассматриваемой на примере Microsoft Analysis Services — OLAP-сервера фирмы Microsoft, входящего в комплект поставки Microsoft SQL Server 2000 Enterprise Edition и на сегодняшний день признанного аналитиками Gartner Group одним из наиболее популярных продуктов этого класса.

Введение в OLAP: часть Хранилища данных

Типичная структура хранилищ данных
Таблица фактов
Таблицы измерений
OLAP на клиенте и на сервере
Технические аспекты многомерного хранения данных
Заключение
Первая статья данного цикла (см. Введение в OLAP: часть 1. Основы OLAP) была посвящена основам OLAP (On-Line Analytical Processing) — технологии многомерного анализа данных. В ней мы обсудили концепции хранилищ данных и OLAP, требования к хранилищам данных и OLAP-средствам, логическую организацию OLAP-данных, а также основные термины и понятия, относящиеся к многомерному анализу.
В настоящей статье мы рассмотрим типичную структуру хранилищ данных, поговорим о том, что представляет собой OLAP на клиенте и на сервере, а также обсудим некоторые технические аспекты многомерного хранения данных.

Введение в OLAP: часть Основы OLAP

Что такое хранилище данных
Что такое OLAP
Многомерные кубы
Некоторые термины и понятия
Заключение
В цикле статей "Введение в базы данных", публиковавшемся в последнее время (см. КомпьютерПресс #3/2000 — #3/2001), мы обсуждали различные технологии и программные средства, применяемые при создании информационных систем — настольные и серверные СУБД, средства проектирования данных, средства разработки приложений, а также Business Intelligence — средства анализа и обработки данных масштаба предприятия, которые в настоящее время становятся все более популярными в мире, в том числе и в нашей стране. Отметим, однако, что вопросы применения средств Business Intelligence и технологии, используемые при создании приложений такого класса, в отечественной литературе пока еще освещены недостаточно. В новом цикле статей мы попробуем восполнить этот пробел и рассказать о том, что представляют собой технологии, лежащие в основе подобных приложений. В качестве примеров реализации мы будем использовать в основном OLAP-технологии фирмы Microsoft (главным образом Analysis Services в Microsoft SQL Server 2000), но надеемся, что основная часть материала будет полезна и пользователям других средств.
Первая статья в данном цикле посвящена основам OLAP (On-Line Analytical Processing) — технологии многомерного анализа данных. В ней мы рассмотрим концепции хранилищ данных и OLAP, требования к хранилищам данных и OLAP-средствам, логическую организацию OLAP-данных, а также основные термины и понятия, применяемые при обсуждении многомерного анализа.

В данной статье мы ознакомились

В данной статье мы ознакомились с основами OLAP. Мы узнали следующее:

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

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

OLAP (On-Line Analytical Processing) является ключевым компонентом построения и применения хранилищ данных. Эта технология основана на построении многомерных наборов данных — OLAP-кубов, оси которого содержат параметры, а ячейки — зависящие от них агрегатные данные.

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

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


В данной статье мы рассмотрели типичную структуру реляционных хранилищ данных. Итак, теперь мы знаем, что:

типичная структура хранилища данных существенно отличается от структуры обычной реляционной СУБД— как правило, она денормализована;

основными составляющими структуры хранилищ данных являются таблица фактов (fact table) и таблицы измерений (dimension tables);

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

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

каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов;

если каждое измерение содержится в одной таблице измерений, такая схема хранилища данных носит название «звезда». Если же хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка».

Далее мы обсудили особенности клиентских и серверных OLAP-средств. Мы узнали, что:

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

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

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

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

MOLAP (Multidimensional OLAP) — и детальные, и агрегатные данные хранятся в многомерной базе данных. В этом случае многомерные данные полностью содержат исходные детальные данные;

ROLAP (Relational OLAP) — детальные данные остаются в той же реляционной базе данных, где они находились изначально. Агрегатные же данные помещаются в специально созданные для их хранения служебные таблицы в той же самой базе данных;

HOLAP (Hybrid OLAP) — детальные данные остаются в той же реляционной базе данных, где они и находились изначально, а агрегатные данные хранятся в многомерной базе данных.

В данной статье мы рассмотрели архитектуру аналитических служб Microsoft. Мы узнали, что:

основным компонентом аналитических служб является Analysis Server, представляющий собой сервис операционной системы Windows NT/2000 и предназначенный для создания OLAP-кубов и предоставления доступа к ним из клиентских приложений;

аналитические службы Microsoft поддерживают все известные технологии многомерного хранения данных— Multidimensional OLAP, Relational OLAP и Hybrid OLAP;

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

Далее, рассмотрев различные технологии доступа к OLAP-данным, мы узнали следующее:

для создания административных приложений следует применять Decision Support Objects (SQL DSO) — набор библиотек, в которых содержатся COM-объекты, позволяющие создавать и модифицировать многомерные базы данных и содержащиеся в них объекты, такие как кубы, коллективные измерения и т.д. SQL DSO можно использовать только для доступа к аналитическим службам Microsoft;

приложения, предназначенные только для чтения OLAP-данных, для взаимодействия с аналитическими службами обязательно используют PivotTable Service — библиотеки, загружаемые в адресное пространство клиентского приложения и предназначенные для просмотра серверных OLAP-кубов, а также для создания, модификации и чтения локальных OLAP-кубов, созданных в клиентском приложении;

для взаимодействия с PivotTable Service клиентское приложение может использовать OLE DB for OLAP — расширение универсального механизма доступа к данным OLE DB, позволяющее обращаться к многомерным данным, а также ADO MD — COM-серверы для доступа к многомерным данным, представляющие собой надстройку над OLE DB for OLAP и удобные для использования в клиентских приложениях. Спецификация OLE DB for OLAP является открытой.

И наконец, мы кратко рассмотрели, какие клиентские утилиты можно использовать для доступа к аналитическим службам, а именно:

Analysis Manager, входящий в состав аналитических служб, предназначен для создания и модификации объектов многомерной базы данных и использует для этой цели библиотеки SQL DSO. С его помощью можно осуществлять и просмотр многомерных данных, для чего используется OLE DB for OLAP;

нередко для просмотра OLAP-кубов применяются приложения Microsoft Office, в частности Microsoft Excel, а также ActiveX-компонент PivotTable List, входящий в состав Microsoft Office Web Components.

Защита доступа

Защита доступа к данным предприятия всегда была головной болью, но адекватная защита все же должна быть реализована. Двадцать четыре % компаний указали, что они имеют "чрезвычайно высокий" уровень защиты в своих системах бизнес-интеллекта; однако остальные 45 % указали, что они настоятельно желали бы достигнуть такого уровня. Другими словами, есть существенный разрыв между фактическими и желаемыми уровнями защиты доступа для бизнес-аналитических систем.



    Работа с информацией: Безопасность - Защита - Софт - Криптография

• Информационная безопасность
  
• Аспекты информационной безопасности
  
• Системы информационной безопасности
  
• Софт и информационная безопасность
  
• IInternet Information Services
  
  
• Защита и безопасность
  
• Защита с Firewall
  
• Атаки и информационная безопасность
  
• Информационная безопасность в интернет
  
  
• Борьба с вирусами
  
• Антивирусы против вирусов
  
• Хакеры и информационная безопасность
  
  
• Криптография