О средствах Business Intelligence и других особенностях ожидаемой версии Microsoft SQL Server

Не секрет, что Microsoft SQL Server сейчас является одним из лидеров рынка систем управления базами данных, и, как показывает практика, этот успех вполне обоснован. Выпуск последних двух версий данного продукта сопровождался рядом интересных нововведений. В состав SQL Server 7.0 входил OLAP-сервер, это был первый серверный OLAP-продукт, включенный в серверную СУБД без существенного повышения стоимости, и в то же время появились API для создания клиентских приложений, средства доступа к OLAP-данным в Microsoft Office и даже компоненты для отображения этих данных на Web-страницах корпоративных intranet-серверов. В состав SQL Server 2000 были включены средства поиска закономерностей — Data Mining. Можно без конца спорить о том, какая реализация OLAP или Data Mining лучше — предложенная Microsoft, Oracle или тандемом Hyperion и IBM. Однако очевидно, что именно деятельность Microsoft на рынке аналитических средств сделала их доступными не только крупным корпорациям, но и небольшим компаниям, а также стимулировала включение OLAP-средств и средств Data Mining в состав СУБД других производителей, сделав эту технологию не только уделом избранных специалистов, но и общедоступным средством ведения бизнеса (о других возможностях SQL Server рассказано во врезке «Что еще ждать от SQL Server?»).

Зная о предстоящем выпуске в следующем году новой версии Microsoft SQL Server, известной как Yukon, многие разработчики интересуются, что нового следует ожидать от этого продукта, в том числе какие аналитические средства войдут в его состав. Именно поэтому вниманию читателей предлагается интервью с Юаном Гарденом (Euan Garden), менеджером команды разработчиков Microsoft SQL Server (Product Unit Manager), с которым в ходе конференции TechEd Europe-2003 беседовала Наталия Елманова. Дополнительные сведения по теме читатели найдут во врезке «Некоторые пояснения».

Когда следует ожидать выпуска Yukon?

В данный момент мы работаем над бета-версией, предоставляемой некоторым из наших партнеров и заказчиков. Первой общедоступной бета-версией смогут воспользоваться подписчики MSDN в конце 2003 или в начале 2004 г. Вторая общедоступная бета-версия должна появиться в первой половине 2004 г. Окончательная же версия продукта будет выпущена во второй половине 2004 г. Нам предстоит решить, какие составные части войдут в разные редакции данного продукта, собрать и протестировать окончательную версию, иными словами, продукт следует «привести в товарный вид». На это требуется время. Обычно с момента принятия решения о готовности составных частей продукта до его выпуска проходит два месяца. Иными словами, выпуска окончательной версии продукта следует ожидать с июля по сентябрь 2004 г.

Известно ли, каковы будут редакции этого продукта и их цены?

Вопросы ценовой политики в отношении различных редакций этого продукта еще окончательно не решены, но список редакций уже известен — Evaluation Edition, Standard Edition, Developer Edition, Enterprise Edition и MSDE (Microsoft Desktop Engine).

Многие из наших читателей уже знают, что данный продукт будет содержать Common Language Runtime внутри ядра СУБД. Означает ли это, что разработчики получат возможность создавать код триггеров и хранимых процедур с помощью .NET-совместимых языков, таких как Visual Basic.NET или C#?

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

Сейчас мы работаем в тесном взаимодействии с командами специалистов, отвечающих за Visual Basic .NET, C#, С++ managed extensions, чтобы убедиться, что их и наши технологии корректно работают вместе. Одновременно мы работаем и с командой разработчиков J#, и с некоторыми независимыми поставщиками .NET-совместимых языков, но пока я могу сказать, что именно эти три языка, C#, VB.NET и С++, гарантированно можно будет использовать для написания серверного кода.

Мы гордимся технологией .NET — она позволяет делать многое, и именно поэтому мы активно взаимодействуем с независимыми поставщиками языков для данной платформы, чтобы проверить, как работает код, созданный с помощью этих языков. Нужно обязательно иметь возможность проверки кода, ведь он, по существу, будет выполняться внутри серверного процесса. Если говорить о применении в SQL Server языков программирования, отличных от T-SQL, то и в текущей версии мы можем создавать расширения для хранимых процедур с помощью C++. Однако наличие Common Language Runtime внутри сервера позволяет задействовать многие языки для написания серверного кода, и это именно то, что нужно нашим заказчикам.

При создании решений с применением аналитических служб SQL Server 7 или SQL Server 2000 (и вообще средств Business Intelligence) весьма важным оказывается вопрос выбора или написания клиентского приложения. Каких нововведений, облегчающих создание подобных решений, следует ожидать в средствах Business Intelligence, входящих в состав Yukon?

Многое зависит от того, какое именно клиентское приложение необходимо в конкретном проекте. Если нужен клиент, отображающий отчеты, мы создаем службы отчетов, которые будут доступны для SQL Server 2000 уже в конце 2003 г. В Yukon функциональность этих служб будет расширена. Появится возможность генерировать отчеты как по реляционным данным, так и по данным аналитических служб.

Если же речь идет об аналитических приложениях с развитым пользовательским интерфейсом, есть смысл обратить внимание на приложения Microsoft Office — мы сотрудничаем с командой разработчиков этого продукта. Отличные клиентские аналитические приложения можно создавать с помощью Microsoft Office Web Components; кроме того, у нас есть Excel, который действительно является самым популярным средством Business Intelligence в мире.

Если же вы сами создаете хранилище данных, можно использовать еще один продукт из семейства Microsoft Office — Data Analyzer. Команда, отвечающая за него, сейчас создает новый аналитический инструмент, который будет работать совместно с Yukon.

Известно, что пользователя не всегда устраивают Excel или Data Analyzer в качестве OLAP-клиента. Как показывает практика, для многих эти инструменты, равно как и сама концепция многомерных данных, оказываются сложны. В результате разработчики в общем случае вынуждены создавать клиентские приложения для аналитических служб с помощью таких библиотек, как ADO MultiDimensional (ADO MD) и Decision Support Objects (DSO), что зачастую требует немалых трудозатрат. Будут ли разработчикам предоставлены какие-либо новые библиотеки, упрощающие создание OLAP-клиентов? Появятся ли версии этих библиотек, основанные на управляемом коде, или управляемые провайдеры данных для аналитических служб?

Да. В первую очередь будет возможен доступ к данным аналитических служб с помощью ADO.NET. Задача упрощения доступа к многомерным данным очень важна, поэтому мы и придаем такое значение службам отчетов и ставим перед собой цель выпустить их до конца года. Сервер отчетов также будет включать великолепный API для разработчиков, позволяющий адаптировать приложения для тех или иных задач и поддерживать архитектуру встраиваемых модулей (plug-ins). Замечу, что многие наши партнеры, создающие клиентские приложения для аналитических служб (а их более 40), уже используют этот API или планируют перейти на него в ближайшее время.

Что нового ожидается в средствах обнаружения закономерностей, Data Mining, входящих в состав SQL Server?

В этой области реализовано два существенных нововведения, о которых я уже имею право рассказывать. Первое из них касается увеличения числа самих моделей Data Mining (сейчас, как известно, их только две). Второе имеет отношение к средствам отображения данных Data Mining. Пока средства создания клиентских частей приложений Data Mining ограниченны, а пользователям такие приложения крайне необходимы. Поэтому мы включим в состав новой версии SQL Server несколько средств визуализации для Data Mining. Теперь можно создать хранилище данных, с помощью средств визуализации сразу же попробовать применить Data Mining и понять, какие скрытые закономерности присутствуют в этих данных.

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

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

Можете ли вы что-нибудь рассказать о новых моделях Data Mining, которые будут применяться в Yukon? Есть ли среди них какие-либо широко известные модели и алгоритмы?

К сожалению, пока нет. Некоторые подробности будут раскрыты на конференции Professional Developers Conference в октябре и на конференции ассоциации Professional Association for SQL Server — PASS 2003 Community Summit — в ноябре. Там же мы продемонстрируем и средства визуализации для Data Mining.

Что касается известных моделей и алгоритмов, хочется отметить следующее. Существует несколько моделей Data Mining, довольно хорошо известных, например Decision Trees. Однако мы даем возможность взглянуть на них иначе.

Вспомним, что было до выхода седьмой версии SQL Server. В те времена работать с OLAP могли только опытные пользователи, а сами OLAP-средства были сложны и стоили очень дорого. Выпустив SQL Server 7.0, мы сделали технологию OLAP доступной многим и куда более простой в применении, до нас такого еще никто не совершал. А ведь технологии OLAP уже почти 25 лет.

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

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

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

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

В чем мы действительно добились успеха, так это в разработке спецификации XML for Analysis: на сегодня список производителей OLAP-средств, объявивших о поддержке этой спецификации, включает около 60 компаний, среди которых Hyperion, Sybase, поставщики клиентских приложений, такие как Сognos, Business Objects, ProClarity, Panorama. Цель нашей совместной работы — добиться того, чтобы OLAP-серверы и клиентские приложения лучше работали вместе и чтобы на основе данной спецификации можно было достичь совместимости между OLAP-клиентами и OLAP-серверами разных производителей.

Я не знаю, планирует ли Oracle поддерживать спецификацию XML for analysis, но многие ведущие производители OLAP-серверов, такие как Hyperion, обязательно будут это делать.

При разработке приложений заказчики нередко указывают разработчикам, какие технологии они должны использовать, и в результате последним приходится создавать решения с применением OLAP-средств, СУБД и средств разработки разных производителей. В этом случае отсутствие стандартного универсального механизма доступа к OLAP-данным, аналогичного механизмам ODBC или OLE DB для реляционных СУБД, создает определенные проблемы.

Такие проблемы можно решать с помощью Web-служб — данная технология позволяет достичь определенной интероперабельности между приложениями разных производителей и задействовать возможности OLAP и других технологий Business Intelligence. Спецификацию XML for Analysis мы рассматриваем именно как описание API для Web-служб.

Предусматривает ли спецификация XML for Analysis возможность не только чтения, но и создания OLAP-кубов?

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

Если же говорить о создании собственных клиентских приложений, то имеет смысл рассматривать возможность применения ADO.NET. Соответствующий провайдер для аналитических служб основан на спецификации XML for Analysis.

Если не секрет, почему провайдер ADO.NET для аналитических служб появился так поздно? Сама платформа Microsoft.NET, технология ADO.NET и даже Visual Studio.NET существуют уже достаточно давно. Есть определенное количество пользователей Visual Studio.NET, интересующихся созданием OLAP-клиентов, но пока для решения данной задачи ничего, кроме ADO, ADO MD, SQL DSO, основанных на традиционной технологии COM, не предлагается.

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

Если взглянуть на платформу .NET в целом, можно заметить, что она все еще открыта для усовершенствований. Пока механизм доступа к данным ADO.NET не может полностью заменить механизмы ADO и OLE DB. На самом деле, конечно, рано или поздно следует довести механизм ADO.NET до такого состояния, чтобы он мог полностью заменить ADO. Ко времени выхода Yukon это должно произойти — ADO.NET заменит ADO, OLE DB, ODBC. Можно будет продолжать использовать эти механизмы, но, если пользователи не захотят иметь с ними дела, они смогут обойтись только механизмом ADO.NET. Пока это не так. Например, средства администрирования многомерных и реляционных баз данных SQL Server — Analysis Manager и SQL Server Enterprise Manager — используют ODBC в качестве механизма доступа к данным. В Yukon аналогичные приложения будут применять ADO.NET.

Говоря о применении COM, замечу, что, создавая платформу Microsoft.NET, мы учли и позитивный, и негативный опыт применения COM, а также постарались избежать проблем, связанных с этой технологией. В частности, мы поняли, что такое средство хранения метаданных, как библиотеки типов, не всегда удобно в применении. В .NET появилось много нового, чего не было в COM, например версионность и средства разграничения доступа. COM была технологией, позволившей в свое время достичь определенного уровня межъязыкового взаимодействия. Я думаю, применение .NET решит многие проблемы, свойственные COM.

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

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

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

Наталья Елманова - независимый консультант, к.ф.-м.н. С ней можно связаться по адресу: 1011.g23@relcom.ru.


Что еще ждать от SQL Server?

Весной этого года представители Microsoft объявили о некоторых планах дальнейшего развития SQL Server и поставляемых с ним средств Business Intelligence. Одним из первых шагов в этом направлении станет добавление в SQL Server средств создания отчетов (Reporting Services). В планы Microsoft входит формирование открытой расширяемой платформы для генерации отчетов, которую разработчики смогут использовать для расширения функциональности своих решений. Интерфейс служб генерации отчетов будет реализован в виде Web-службы. Кроме того, эти службы будут поддерживать широкий спектр источников данных, включая OLE DB- и ODBC-источники, а сами отчеты можно будет сохранять в различных форматах, включая HTML и форматы документов Microsoft Office. В дальнейшем ожидается ряд усовершенствований аналитических служб Microsoft SQL Server и средств Data Mining.

Предполагаемая структура использования средств Business Intelligence представлена на рис.1.

Рисунок 1. Пользователи средств Business Intelligence

По мнению специалистов Microsoft, средства Business Intelligence будут применять от 70 до 90% пользователей.


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

Data Mining — это процесс поиска корреляций, тенденций, взаимосвязей и закономерностей посредством различных математических и статистических алгоритмов — кластеризации, создания выборок, регрессионного и корреляционного анализа. Цель этого поиска — представить данные в таком виде, чтобы можно было построить модель, которая позволяла бы прогнозировать процессы, играющие роль при планировании бизнеса (например, динамику спроса на те или иные товары или услуги).

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

XML for Analysis представляет собой API, основанный на SOAP (Simple Object Access Protocol), предназначенный для стандартизации доступа клиентских приложений к OLAP-данным через Internet. Спецификация XML for Analysis разработана компаниями Hyperion Solutions Corporation и Microsoft Corporation.

XML for Analysis описывает универсальный механизм доступа к аналитическим данным (OLAP-кубам и моделям Data Mining) через Internet, не требующий необходимости устанавливать клиентские компоненты, которые предоставляют соответствующие интерфейсы. XML for Analysis предполагает, что данный механизм должен быть оптимизирован для применения в Web — число обращений к серверу в случае применения средств, поддерживающих эту спецификацию, минимизировано, а клиентское приложение не хранит свое состояние (stateless), что позволяет создавать масштабируемые распределенные аналитические приложения. XML for Analysis можно применять не только для реализации Web-запросов, но и для осуществления взаимодействия между серверами.

С точки зрения авторов OLAP Report, XML for Analysis имеет наибольшие шансы стать независимым от производителей OLAP-средств универсальным механизмом запросов к OLAP-данным, но не заменит полностью исходные API для доступа к многомерным данным, созданные для конкретных продуктов, так как, очевидно, будет уступать им в производительности. Тем не менее такой API позволит создавать универсальные клиентские OLAP-средства, поддерживающие одновременно несколько серверных OLAP-продуктов, и многие аналитики предсказывают, что роль XML for Analysis в области аналитических приложений будет так же важна, как роль ODBC в мире реляционных СУБД.

Поделитесь материалом с коллегами и друзьями