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-клиенты способны работать в однопользовательском режиме с локальными данными отдельного
 |
ПК, в файл-серверной архитектуре, в классической двухуровневой клиент-серверной архитектуре, в трехуровневой клиент-серверной архитектуре с сервером приложения (в последнем случае OLAP-клиент может быть реализован как тонкий Web-клиент; эти Web-клиенты заслуживают отдельного обсуждения и здесь не рассматриваются).
Точно так же в OLAP-клиентах организуется и работа с метаданными. Источниками данных могут быть локальные таблицы (например, в формате dbf), таблицы SQL-серверов, локальные многомерные кубы, многомерные базы (кубы) данных OLAP-серверов. Возможна реализация вычисляющей OLAP-машины в OLAP-клиенте, в
MOLAP-сервере (OLAP-сервере, который обрабатывает данные, хранимые в физической многомерной БД), в ROLAP-сервере (OLAP-сервере, обрабатывающем данные, хранимые в реляционной БД), в сервере приложений. Далее будут приведены несколько примеров архитектур OLAP-клиентов, предназначенных для использования в локальных сетях и на отдельных ПК.
Варианты архитектур OLAP-клиентов
OLAP-клиент MOLAP-сервера. Первичные данные из внешних источников периодически загружаются в многомерную БД MOLAP-сервера, в которой постоянно хранятся как первичные атомарные данные, так и вычисленные в момент загрузки агрегаты (см. рис. 2). Часть метаданных, а именно описания атрибутов куба, и OLAP-машина находятся на сервере; OLAP-клиент предоставляет средства организации диалога и отображает данные в виде таблицы.
 |
Наиболее простой OLAP-клиент этого типа - электронная таблица MS Excel, в которую встроен OLAP-компонент - "сводная таблица" (Pivot Table). Аналитическим приложением является книга MS Excel. Часть метаданных, описывающая свойства отчета, путь к серверу, имя базы данных и куба, хранится в книге MS Excel. Права доступа к отчету ограничиваются доступом к файлу MS Excel. Совместное использование настроек отчета группой пользователей обеспечивается копированием файла этих настроек на ПК каждого пользователя.
Существует несколько реализаций подобных OLAP- клиентов от третьих фирм, которые поставляются в виде дополнения (add-in) к MS Excel. Один из примеров - BusinessQuery компании BusinessObjects.
Достоинства и недостатки такого OLAP-клиента определяются свойствами MS Excel. Достоинства - простота освоения инструмента конечными пользователями и его относительно невысокая стоимость. Персональное владение файлом, в котором содержатся настройки отчета, удобно для пользователя, но усложняет сопровождение многопользовательских приложений. За счет предварительного вычисления агрегатов MOLAP-сервер обеспечивает наивысшую производительность обработки больших объемов данных
 |
Кроме приведенного здесь варианта, 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, а вторая часть - аналитическая - у пользователей. Пользователи подписываются на биржевые данные, рассылаемые им в виде
 |
Эта технология удобна для автономной (off-line) работы на ПК, отключенном от сети, или для выполнения многократного анализа однажды подготовленных данных. И как показывают тесты, эта конфигурация до определенного объема данных показывает даже более высокое быстродействие, чем OLAP-сервер.
OLAP-клиент и ROLAP-сервер. Данные хранятся в реляционных СУБД внешних систем, все вычисления выполняются в масштабе реального времени (on-line) на специальном ROLAP-сервере (см. рис. 4). OLAP-клиент предоставляет интерактивный интерфейс пользователю, генерирует запросы на внутреннем языке системы к ROLAP-серверу, который на основе метаданных собственного репозитория преобразует их в SQL-запросы к источникам данных - реляционным СУБД.
Так реализована система MicroStrategy. MS OLAP Server 7/Analysis Services 2000 также может быть настроен для работы в такой архитектуре.
Трехуровневая конфигурация обеспечивает возможность обслуживания тысяч пользователей за счет масштабирования и кластеризации ROLAP-сервера. Требования к мощности ПК пользователей минимальны. В отличие от случая с MOLAP-сервером вычисления выполняются "на лету", что устраняет необходимость процедуры перезагрузки данных из реляционных БД в многомерные кубы. Такая система, как и OLAP-сервер, требует администрирования и не использует огромных
 |
возможностей современных ПК.
В MicroStrategy оригинально решена операция детализации, или углубления (drill-down). При каждом запросе пользователя на детализацию отчета генерируется SQL-запрос, результат которого отображается в новом окне. Это не кажется удобным интерфейсным решением для пользователя. Но за счет того, что одновременно обрабатываются только те данные, что отображаются на экране, система обладает уникальной возможностью анализировать данные из реляционных баз неограниченного размера, вплоть до терабайтов.
OLAP-клиент с OLAP-машиной. OLAP-клиент со встроенной OLAP-машиной не хранит агрегатные данные на диске, а в момент запроса загружает их в оперативную память и выполняет вычисления на ПК пользователя (см. рис. 5). Источниками данных могут быть таблицы SQL-серверов, локальные таблицы, ERP-системы.
Работа с метаданными реализуется по-разному. Например, может существовать выделенный центральный репозиторий метаданных. Он хранит описания источников данных, запросов и отчетов и права пользователей.
Построить такую архитектуру позволяет система BusinessObjects. Единый репозиторий метаданных дает всем пользователям возможность применять однажды настроенные отчеты. Администратор получает инструмент для разграничения прав пользователей на бизнес-объекты и отчеты.
 |
Этих файлов может быть один или много (см. рис. 6). Поэтому клиент может работать поочередно с несколькими репозиториями, которые могут находиться как на его ПК, так и на файл-сервере. Разделение прав доступа на данные реализуется средствами СУБД, а на отчеты - средствами операционной системы: для каждой рабочей группы создается свой файл приложения, доступ к которому ограничивается членами этой группы.
Достоинство этого способа состоит в отчуждаемости репозитория, который можно просто скопировать, послать по почте в филиалы. Кроме того, репозиторий не требует обслуживания. Такая архитектура обеспечивает необычайную гибкость при решении прикладных задач. Этот OLAP-клиент может работать как DOLAP (Desktop OLAP), если данные находятся на локальном ПК, как файл-серверное приложение, если файлы БД лежат на сетевом диске, или как мощное многопользовательское клиент-серверное приложение, если данные предоставляет SQL-сервер.
Независимо от способа хранения метаданных, в этом случае клиент-серверная
 |
Группирует сервер, а клиенту возвращается компактная выборка для дальнейших OLAP-вычислений. Размер этой выборки может быть в десятки и сотни раз меньше объема первичных данных. Таким образом, возможности OLAP-клиента также очень сильно зависят от мощности сервера БД. При достаточно быстром сервере и большом объеме реальных данных, в которых, как правило, существуют неуникальные записи, OLAP-клиент сможет обрабатывать десятки или даже сотни миллионов первичных, не агрегированных записей.
Применение OLAP-клиентов
OLAP-клиент может быть применен для решения нескольких бизнес-задач:
Создание аналитической инфраструктуры предприятия силами специалистов самого предприятия или внедренческой фирмы. Создание тиражируемого аналитического приложения для популярной OLTP-системы силами независимого разработчика. Создание тиражируемого Хранилища данных или высокоуровневого инструмента для построения Хранилищ данных. Создание интегрированного аналитического модуля для OLTP-системы разработчиком этой системы.
Перечисленные бизнес-задачи могут быть решены с использованием различных конфигураций информационных систем, построенных с помощью OLAP-клиента.
|
Рис. 9. Приложение "Контур Стандарт" для тиражируемой OLTP-системы |
Хранилище данных. Разработчик уникального Хранилища или универсального инструмента для построения Хранилищ может сконцентрироваться на проектировании БД и средств сбора и очистки данных. Выполнение запросов, анализ и выпуск отчетов делегируются готовым специализированным системам - OLAP-клиентам (см. рис. 7). Другими словами, программирование интерфейсов Хранилища может быть сведено только к созданию рабочего места администратора.
Транзакционная система. Транзакционные системы, от больших западных ERP-систем до компактных российских "бухгалтерий", наилучшим образом выполняют свои основные функции - автоматизацию учета и выпуск регламентированных отчетов, но не маркетинговый или финансовый анализ.
Однако они накапливают совокупность данных, которые можно использовать для этого анализа.
При помощи OLAP-клиента эти данные можно получать в режиме реального времени непосредственно из БД OLTP-системы (см. рис. 8). Для этого структура БД должна быть прозрачной, а мощность сервера БД достаточной для одновременного выполнения "длинных" аналитических запросов и "коротких" транзакций операционистов.
 |
Настройка 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
Будущие направления
Поставщики приложений бизнес-интеллекта прежде всего должны подчеркивать интеграцию своих приложений, тем самым делая их недорогими, простыми в развитии и удобными. Когда респондентов спрашивали об их восприятии "волны 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" Кена Айверсона
Конфиденциальность
Конфиденциальность в 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’ |
Выполнив эту процедуру со всеми странами, мы получим следующий набор данных (ниже показан фрагмент):
| 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 |
| … | … |
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 |
| … | … | … | … |
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-кубы, перейдем к некоторым ключевым терминам и понятиям, используемым при многомерном анализе данных.
