Грамотно написанное аналитическое приложение способствует совершенствованию всего бизнес-процесса, начиная от анализа ситуации и заканчивая этапом принятия решения. Поскольку совместная работа сотрудников — составная часть бизнес-процесса, любое нетривиальное аналитическое приложение должно поддерживать совместное использование идей и конкретных результатов работы. Специалисты Microsoft разработали SQL Server 2000 Analysis Services — инструмент, предоставляющий набор простых функций для совместной работы. С помощью этих функций аналитик может исследовать различные варианты развития событий (What-If Analysis). Например, службы Analysis Services могут использоваться для анализа работы алгоритма с обратной записью (Write-Back) на уровне ячеек (Cell-Level) и на уровне размерности (Dimension-Level). Однако эффективная совместная работа требует большего, чем просто анализ работы алгоритма с обратной записью; приложение должно уметь работать с бизнес-логикой (Business Logic), участвовать в последовательности связанных информационных обменов в процессе выполнения пользователем той или иной процедуры (Conversation Thread), «понимать» принятый план действий (Action Plan). В этой статье мне бы хотелось проанализировать архитектуру аналитического бизнес-приложения (Collaborative Analytic Application) и рассмотреть историю самого вопроса.

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

Так как в Analysis Services нет встроенных функций для совместного использования Business Logic, Conversation Thread и Action Plan, все эти возможности необходимо уметь реализовать за счет имеющейся функциональности. Основной вопрос — как реализовать совместное использование бизнес-логики? В следующем примере термин «бизнес-логика» будет обозначать специфические для данного бизнеса формулы, такие, как именованные наборы (Named Sets) и вычисляемые ячейки (Calculated Members). Пример бизнес-логики — формула, на основе которой определяется список десяти самых важных клиентов; чаще всего такая формула сильно зависит от вида бизнеса. Иногда главный критерий в подобной формуле — доход клиента, иногда — прибыль и длительность работы с клиентом.

Analysis Services может хранить и извлекать данные об именованных наборах и вычисляемых ячейках, но данный инструмент не позволяет создавать новые Calculated Members и Named Sets на основе программного интерфейса клиента — ADO MD. Чтобы создать на сервере бизнес-логику, доступную для совместного использования, необходим Analysis Manager или же административный интерфейс программирования Decision Support Objects (DSO). Дополнительная информация о трех программных интерфейсах приведена во врезке «Интерфейсы Analysis Services». Хотя DSO-доступ требует наличия прав администратора OLAP, можно разработать специальную службу, которая будет иметь OLAP-доступ с привилегиями администратора, и установить ее на прикладном OLAP-сервере (либо на промежуточном уровне). После этого разработанная служба делается доступной приложениям клиента, чтобы они могли выполнить такие специфические действия, как создание новой бизнес-логики.

Совместное использование документов

Еще одна функция коллективной работы — совместное использование документов. Такая работа с документами означает необходимость реализации возможностей Conversation Thread и Action Plan, связанных с аналитической информацией в кубе данных. Например, аналитик просматривает прибыль компании за последние несколько кварталов и обнаруживает, что определенная линия продукции убыточна. Он разрабатывает план действий в соответствии с увеличением прибыли по продуктам этой линии. После обсуждения намеченного плана мероприятий с остальными сотрудниками аналитик может дополнительно запустить процедуру Conversation Thread для исследования иных путей повышения прибыльности продукции.

Поскольку информация аналитика в части Action Plan и Conversation Thread связана с некоторой порцией OLAP-куба, есть смысл хранить такую информацию вместе с анализируемой порцией. В этом случае другие аналитики смогут увидеть информацию от своего коллеги только в контексте рассматриваемой проблемы. Можно связать информацию аналитика с определенной порцией куба с помощью функции Analysis Services, называемой Action. Функция Action — это связь с информацией или же команда, которая ассоциируется с метаданными куба, такими, как размерность, уровень, ячейка. Функция чем-то напоминает Calculated Members и Named Sets в том смысле, что создавать и редактировать объекты можно только тому клиенту API ADO MD, который «породил» их. Другими словами, нельзя создать совместно используемую функцию Action. В предлагаемой для анализа архитектуре мне необходимо было создавать и редактировать Action для их последующего использования остальными аналитиками куба, а следовательно, требовалось подключить возможности административного API DSO.

Разработка архитектуры

На Рисунке 1 приведена предлагаемая архитектура. То, что создается самим пользователем, затенено. Прежде всего пользователь формирует Web-службу, которая делает доступными функции коллективной работы — включая создание Action, Calculated Members и Named Sets — поверх DSO API. Затем пользователь создает клиентское приложение, в котором применяется комбинация ADO MD для стандартного доступа к кубу и возможности Web-службы, поддерживающей коллективную работу. Также у пользователя может возникнуть желание задействовать SQL Server для работы с дополнительной информацией разделяемого характера — документами Action Plan, Conversation Threads и другими относящимися к делу спецификациями в любой области бизнес-логики.

Программирование в DSO не настолько прямолинейно, как в ADO MD, так как большинство объектов DSO имеет одинаковый тип — MDStore. К примеру, если у пользователя есть Database Object, Cube Object и Dimension Object, он декларирует и применяет все эти объекты как MDStore-объекты. Даже если базовые объекты метаданных имеют различную природу, одни и те же методы и свойства доступны для всех объектов. В зависимости от природы используемого объекта метаданных, некоторые методы и свойства не работают вовсе или работают по-разному. Электронный справочник SQL Server Books Online (BOL) содержит очень мало примеров программирования DSO, поэтому изучать DSO придется самостоятельно.

Рисунок 1. Архитектура аналитического приложения.

Если коллективное приложение разрабатывается в виде Web-службы, в качестве среды программирования можно выбрать Visual Studio .NET. Visual Studio .NET имеет интегрированные свойства, которые могут оказаться полезными для проектирования Web-служб. Полное описание процесса создания такого приложения выходит за рамки данной статьи, более подробно я рассмотрю лишь ту его часть, которая касается использования DSO. Чтобы обсуждение было более предметным, я написал простое тестовое приложение на С#, в котором с помощью DSO создается Calculated Member. В Листинге 1 показан исходный код моего приложения. Я создал в Visual Studio .NET проект Windows Application Project для написания и тестирования исходного кода и рекомендую читателям проделать то же самое, поскольку Windows Application — достаточно простая среда для написания и отладки программ. После того как вы напишете и отладите свой код, можно будет создать Web Service Project и скопировать в него отлаженный исходный код.

С помощью кода, приведенного в Листинге 1, выполняются подключение к OLAP-серверу и поиск куба FoodMart 2000 Sales, для которого имеется список ассоциативных команд. Это текстовые MDX-команды, которые исполняются службами Analysis Services для каждого клиента, установившего сессию с сервером. В коде создается новая команда, и для свойства Statement выполняется настройка на MDX-команду, которая необходима для создания нового Calculated Member. Затем код вызывает метод куба Update() для сохранения измененного списка команд в репозитарий Analysis Services. После этого соединение с сервером закрывается.

Далее код вызывает метод ReleaseComObject. В процессе отладки я обнаружил, что данный метод совершенно необходим. В среде разработки .NET крайне медлительный «сборщик мусора», .NET освобождает ресурсы далеко не сразу. Когда используются COM-объекты, такие, как библиотеки DSO, несвоевременная «сборка мусора» может создать проблемы, если COM-объект ожидает окончания работы этой программы. Я столкнулся с такой ситуацией, когда раз за разом стал получать access violation error, выходя из тестовой программы С#. В конце концов стало ясно, что требуется явным образом указать .NET Runtime Library на необходимость освободить память ненужного более DSO Server Object.

Поскольку BOL содержит мало информации о DSO-программировании, создание Action и Calculated Member может потребовать проведения розыскных мероприятий. Вот несколько советов на эту тему. С помощью Analysis Manager следует создать Calculated Member, Action или Named Set и воспользоваться DSO для отображения корректного синтаксиса MDX-операторов. Чтобы просмотреть синтаксис команд MDX, созданных с помощью Analysis Manager, требуется снять комментарий с цикла For Each в Листинге 1. Когда цикл исполняется, метод MessageBox.Show() отображает все команды, ассоциированные с кубом dsoCube.

До сих пор существуют различные мнения по поводу того, что же такое в действительности аналитическое приложение, хотя аналитические программы уже получили большое распространение. Практически каждый поставщик услуг на рынке Business Intelligence (BI) предлагает аналитические приложения, но каждый из них при этом вкладывает в данное понятие свой смысл. На мой взгляд, аналитическое приложение должно способствовать развитию бизнес-процесса, начиная с этапа анализа и заканчивая этапом принятия решения. А если так, то коллективная работа — краеугольный камень любой аналитической программы, поскольку невозможно принять правильное решение без привлечения знаний держателей акций, заинтересованных лиц и тех, кто принимает ответственные решения. Хотя Analysis Services не во всех своих «коллективных» проявлениях подходит для создания эффективного аналитического приложения, в любой организации без особого труда можно создать собственные коллективные функции на основе имеющейся в Analysis Services функциональности. Итак, когда в следующий раз потребуется добавить в аналитическое приложение очередную коллективную функцию, рекомендую воспользоваться кратким обзором, представленным в настоящей статье.

Интерфейсы Analysis Services

Analysis Services имеет три программных интерфейса, которые могут использоваться в среде аналитического приложения. Первые два интерфейса — ADO MD и OLE DB For OLAP — размещаются на стороне клиента. Оба они предоставляют клиенту функции для исследования данных и метаданных, алгоритм обратной записи и аналитические функции (в режиме read-only). Повлиять на содержимое куба, с которым сообща работают пользователи системы, можно только через механизм Write-Back. Если необходимо изменять данные Analysis Services каким-то иным способом, следует задействовать административный программный интерфейс Decision Support Objects (DSO). DSO позволяет создавать и изменять кубы, размерности, вычисляемые ячейки, а также использовать иные функции для интерактивного взаимодействия через приложение Analysis Manager.

Расс Уитни возглавляет исследовательское отделение в компании Knosys, руководит разработкой клиентского инструментария OLAP и является членом совета директоров компаний Knosys и Distributed Database Consulting (DDBC). С ним можно связаться по адресу: rwhitney@knosysinc.com.