(Возврат на основную страницу)
Будущее OLAP от Microsoft и Oracle
Марк Ритман (Mark Rittman)
Я занимаюсь разработкой на платформе Oracle, объединяя приложения для интеллектуальных ресурсов предприятия и хранилища данных с применением серверных платформ Oracle для баз данных и приложений. В прошлом я освоил такие продукты Oracle, как Warehouse Builder и Oracle 10g. В этом месяце в предвкушении того, что Oracle приготовил для рынка OLAP, я собираюсь посмотреть, что же имеется в запасе у Microsoft. Это довольно интересно, поскольку у этих двух гигантов индустрии баз данных имеются совершенно различные и ясные представления о том, как будет развиваться индустрия OLAP, причем каждая точка зрения подкрепляется своими доводами.
Недавно вышла версия 10g базы данных от корпорации Oracle, поставляющаяся теперь вместе со встроенным многомерным сервером OLAP, известным как OLAP Option. Корпорация Microsoft, которая так лихо взяла штурмом рынок OLAP, реализовав Analysis Services в составе SQL Server 2000, вотвот выпустит долгожданную новую версию, первоначально имевшую кодовое название «Юкон», а теперь переименованную в SQL Server 2005. Oracle и Microsoft стремятся с помощью этих новых версий поновому организовать индустрию OLAP, и это будет иметь серьезные последствия для администраторов баз данных, отвечающих за работу хранилищ данных на основе традиционных реляционных СУБД. Так что же заготовлено у Oracle и Microsoft, и какое влияние это окажет на ваши будущие приложения для интеллектуальных ресурсов предприятия?
Немного истории
Индустрия OLAP имеет долгую и славную историю, причем концепция многомерного анализа восходит к выпущенной в 1962 году книге Кена Иверсона «Язык программирования» и к собственной технологии Express корпорации Oracle, реализованной ее проектировщиками в 1970 году. До недавнего времени в индустрии OLAP доминировали такие производители как Hyperion, Comshare, Microstrategy, при этом цена серверов OLAP обычно составляла десяткисотни тысяч долларов, а данные хранились в автономных выделенных многомерных базах данных. Однако в последние несколько лет большие производители баз данных, такие как Oracle и Microsoft, выдвинулись на рынок OLAP, включив серверы OLAP в состав своих традиционных реляционных баз данных и установив такие цены, которые способны подрезать конкурентоспособность лучших производителей. Начальные версии их серверов OLAP концентрировались на игре в «салочки» с производителями выделенных серверов OLAP. Однако новые версии каждой из этих корпораций грозят посвоему переопределить рынок OLAP, вытеснив из игры прочих производителей выделенных серверов OLAP. Так что же замышляют Oracle и Microsoft?
Analysis Services 2005 корпорации Microsoft
Корпорация Microsoft оказала огромное влияние на рынок OLAP в 1998 году, выпустив OLAP Services, «бесплатный» сервер OLAP, поставлявшийся вместе с SQL Server 7.0. Он был построен по технологии, которую корпорация Microsoft приобрела у Panorama Software Systems, начинающей израильской компании, давшей Microsoft опытную команду разработчиков OLAP, влившуюся в существовавшую тогда команду проектировщиков SQL Server (Редмонд, штат Вашингтон). Несмотря на конкурентоспособную ценовую политику и впечатляющий набор возможностей позиция сервера OLAP корпорации Microsoft была ограничена до выхода в свет версии SQL Server 2000, которая содержала улучшенный вариант сервера OLAP, известный сегодня как Analysis Services. Переименование в Analysis Services произошло изза того, что теперь в него вошел определенный набор функций Data Mining. Сервер имел ошеломляющий успех и стал лидером рынка. В 2003 году он занимал 23% рынка, опережая Hyperion с 22% и Cognos с 14%.
Хотя Analysis Services поставляется вместе с SQL Server 2000, он является самостоятельным сервером, и его часто используют с базами данных, произведенными не корпорацией Microsoft, такими как IBM DB2 и Oracle RDBMS. Однако, учитывая, что SQL Server был выпущен пять лет назад, Analysis Services начал устаревать. Сейчас внимание сфокусировано на той версии Analysis Services, которая будет поставляться как часть следующего выпуска SQL Server с кодовым названием «Юкон», который теперь официально называется SQL Server 2005.
Разработчики SQL Server Analysis Services 2005 обещали практически заново переписать технологию, на которой базировался Analysis Services 2000, причем множество изменений будет внесено в сам сервер OLAP, и будет применен радикально измененный подход к наполнению кубов OLAP и организации доступа в них. Одной из новых ключевых возможностей Analysis Services 2005 является концепция унифицированной многомерной модели Unified Dimensional Model (UDM).
Эта концепция не нова, она позволяет администраторам баз данных и разработчикам определять размерности, кубы OLAP и иерархии в абстрактной форме, которая затем может храниться как в реляционном, так и в многомерном виде. У Oracle такая возможность уже имелась в течение некоторого времени: в базе данных Oracle9i данные OLAP могли храниться либо как реляционные таблицы, либо как специализированные аналитические рабочие пространства Analytic Workspaces, при этом унифицированная многомерная модель помещалась в каталог OLAP Catalog. Сейчас корпорация Microsoft реализует свою собственную унифицированную многомерную модель для Analysis Services 2005 и пытается с ее помощью стереть различия между реляционной и многомерной отчетностью.
В Analysis Services 2000, как и в большинстве серверов OLAP, существовало ограничение на количество размерностей, которые могли быть связаны с кубом, а в Analysis Services 2005 этого ограничения больше нет. Кроме того, Analysis Services 2005 будет поставляться с возможностью Intellicube, которая при совместном ее применении с унифицированной многомерной моделью и при отсутствии всех ограничений на размерности позволит администраторам баз данных «забросить» в Analysis Services 2005 любую реляционную схему. При этом автоматически создастся настраиваемая схема куба, идентифицирующая фактографическую таблицу и таблицы размерностей (рис. 1).
Наряду с унифицированной многомерной моделью еще одной ключевой технологией, заявленной в Analysis Services 2005, является упреждающее кэширование. Это метод наполнения кубов OLAP исходными реляционными данными и последовательного агрегирования их в многомерные кубы OLAP.
Работа упреждающего кэширования кубов OLAP основана на первоначальном задании куба на исходных реляционных данных, после чего он становится доступным анализу. Затем по мере агрегирования данных куб становится сначала гибридным реляционномногомерным кубом, а позднее и полностью многомерным кубом с добавленными, где требуется, оптимизированными агрегированными величинами. Это освобождает администратора баз данных от проведения загрузки и обработки куба явным образом. Такой подход от Microsoft означает, что очень малыми усилиями администратор баз данных теоретически может развертывать базы данных OLAP, которые предоставляют информацию в реальном времени и в то же время располагают всеми преимуществами оптимизированных многомерных баз OLAP. Oracle планирует ввести аналогичные возможности в Oracle OLAP, стирая со временем различия между реляционным и многомерным хранением (но ожидается, что рабочая версия появится не ранее, чем в Oracle 11).
Помимо цены и впечатляющего набора возможностей еще одним орудием атаки Microsoft на рынок OLAP является MDX, язык запросов OLAP. Сверхъестественно похожий на SQL, но в то же время понастоящему многомерный, язык запросов MDX фактически стал языком запросов OLAP. Он поддерживается большинством производителей инструментария работы с запросами OLAP.
К примеру, базовый запрос MDX (взятый из предлагаемого MSDN введения в MDX) будет выглядеть так:
SELECT
{ [Measures].[Unit Sales],
Ã
[Measures].[Store Sales] } ON COLUMNS,
{ [Time].[1997], [Time].[1998] } ON ROWS
FROM Sales
WHERE ( [Store].[USA].[CA] )
На первый взгляд MDX выглядит во многом похожим на SQL, однако сходно смотрящийся синтаксис скрывает несколько концептуальных различий между двумя языками. Вот цитата из опубликованного в MSDN «Сравнения MDX и SQL»: «Принципиальным различием между SQL и MDX является способность MDX ссылаться на несколько размерностей. Хотя существует возможность пользоваться исключительно SQL для обращения с запросами к кубам в SQL Server 2000 Analysis Services, язык MDX предоставляет команды, спроектированные специально для извлечения данных из многомерных структур с практически любым количеством размерностей.
При обработке запросов SQL ссылается только на две размерности — столбцы и строки. Поскольку SQL проектировался для обработки лишь двумерных табличных данных, термины «столбцы» и «строки» имеют смысл в синтаксисе SQL.
По сравнению с ним MDX может обрабатывать одну, две, три и более размерностей в запросах. Поскольку в MDX может использоваться множество размерностей, каждая из них называется осью. Термины «столбец» и «строка» в MDX используются просто в качестве псевдонимов для размерностей первых двух осей в запросах MDX; имеются и другие размерности с псевдонимами, однако сами псевдонимы не несут смысла в MDX. MDX поддерживает их в целях наглядности показа, многие инструменты OLAP не могут показывать результирующий набор с более чем двумя размерностями».
Analysis Services 2005 расширяет функциональные возможности MDX и вводит сопровождение для построенного на базе стандарта XML языка XML for Analysis (XML/A http://www.xmla.org/), который поддерживает не только Microsoft, но и SAS, и Hyperion. Особо интересным фактом, касающимся XML/A, является то, что он с самого начала проектировался как Webслужба SOAP, доступ к которой можно получить через HTTP. Теоретически это открывает Analysis Services 2005 для любого сервера в сети. Данный вопрос пока еще пребывает в зачаточном состоянии, но хорошо уже то, что там присутствуют стандарты, которые в будущем обеспечат соответствие архитектуре, ориентированной на службы (http://www.servicearchitecture.com/webservices/articles/serviceoriented_architecture_soa_definition.html).
Как бы то ни было, сегодня ясно, что следующая версия Analysis Services значительно превзойдет функциональные возможности первых двух выпусков сервера OLAP корпорации Microsoft. В этом контексте Oracle ввела свои усовершенствования.
OLAP Option корпорации Oracle
Хотя сервер Analysis Services корпорации Microsoft имел огромный успех, первым производителем реляционных баз данных, осознавшим важность OLAP, была корпорация Oracle. Именно она приобрела в 1995 году технологию Express у компании IRI. Приход Oracle в мир OLAP и узаконил эту индустрию, и послужил сигналом побудки для традиционных производителей OLAP, потому что теперь им предстояло противостоять в гораздо более жесткой конкурентной борьбе громадным компаниям, производившим реляционные базы данных.
С того самого момента, как Oracle купила Express, целью корпорации стала интеграция этой технологии в реляционную базу данных Oracle. Такая цель была, в конце концов, достигнута в Oracle 9i. Эту версию Oracle провозгласила «первой реляционномногомерной СУБД», в ней в качестве отдельно лицензируемой опции была реализована технология OLAP под названием OLAP Option (http://www.oracle.com/technology/products/bi/olap/olap.html).
Интегрируя технологию Express в базу данных, Oracle выбрала совершенно иной путь, чем Microsoft, которая сохраняла собственную технологию OLAP отдельно от своей основной реляционной технологии. Oracle 9i и OLAP Option работали как единый процесс с единым с позиций управления экземпляром базы данных. При этом технология OLAP могла использовать все преимущества возможностей Oracle, таких как Real Application Clusters (http://www.oracle.com/technology/products/database/clustering/), секционирование, DataGuard (http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardOverview.html), а теперь и технология Grid. В отличие от Microsoft SQL Server база данных Oracle работает также на платформах, отличных от Windows, и OLAP Option может переноситься на все серверные платформы, на которых работает обычная база данных Oracle, включая Linux и Apple OSX.
Сейчас Oracle готова выпустить новую версию Oracle 10g OLAP (рис. 2), известную как 10.1.0.3. Oracle будет выпускать 10g OLAP вместе с инструментарием следующего поколения для обработки запросов, который проектировался для работы в 10.1.0.3. Похоже, что эти версии в состоянии идти «ноздря в ноздрю» с Analysis Services 2005.
Сильная сторона Oracle как применительно к реляционным базам данных, так и к серверам OLAP традиционно заключалась в наличии среды, обусловливающей большие аналитические наборы, множество одновременно работающих пользователей, а также требовавшей проведения сложного многомерного анализа. Разработанный Oracle язык OLAP Data Manipulation Language (OLAP DML: http://www.oracle.com/pls/db10g/db10g.to_toc?pathname=olap.101 percent2Fb10339 percent2Ftoc.htm&remark=portal+ percent28Data+warehousing percent29), обладающий большими функциональными возможностями и основанный на языке 4го поколения Express, включает такие черты, которые только сейчас начинают копироваться корпорацией Microsoft в язык MDX. Следующая версия Oracle 10g OLAP выйдет с новыми возможностями поддержки больших аналитических наборов.
В Oracle 10g OLAP было усовершенствовано секционирование. Теперь отдельные показатели, размерности и, безусловно, любые объекты аналитической рабочей области могут быть распределены по отдельным секциям. В 10g также введена новая форма сжатия кубов, что обещает не только повысить производительность обработки запросов (за счет извлечения меньшего количества блоков для заданного количества логических данных), но и значительно снизить время пакетной загрузки и агрегирования, при этом еще и экономя дисковое пространство.
Сжатие в Oracle 10g OLAP введено больше для улучшения производительности и масштабируемости, чем для экономии дискового пространства (хотя это очень неплохой побочный эффект). Чистый результат таков, что в заданном пакетном окне Oracle 10g OLAP теперь может загружать и агрегировать больше информации, чем раньше. Все это вкупе с ощутимым прогрессом в масштабируемости внутренних областей, таких как очень большие составные структуры, делает Oracle 10g OLAP потенциально весьма эффективной платформой при построении кубов, особенно больших.
Еще одним ключевым различием в подходах Oracle и Microsoft к OLAP является их выбор языка запросов. Как мы видели выше, Microsoft отдает предпочтение MDX, собственному многомерному языку запросов, с которым в качестве интерфейса API используется XML/A.
Однако Oracle твердо делает ставку на обычный SQL с аналитическими выражениями как на предпочтительный язык запросов для OLAP. Oracle предлагает как часть OLAP Option функцию OLAP_TABLE (https://cwisdb.cc.kuleuven.ac.be/ora10doc/olap.101/b10334/olap_table.htm), которая позволяет обычным запросам SQL получать доступ к собственным многомерным типам данных, содержащимся в аналитических рабочих областях. Это открывает Oracle OLAP для основных реляционных генераторов отчетов, таких как Microstrategy, Business Objects и Cognos.
В качестве примера приведем
следующий запрос SQL (взятый из технической статьи Oracle по доступу к данным
OLAP средствами SQL: http://
www.oracle.com/technology/products/bi/pdf/30807_SQLAccess.pdf),
который показывает, как функция OLAP_TABLE может извлекать многомерные данные в
обычный набор строк и столбцов:
SELECT time_id, channel_id, product_id,
Ã
customer_id, sales,
forecast_sales
FROM table(OLAP_TABLE('ddepot DURATION query',
'SALES_TYPE_TABLE',
‘FORECAST_SALES',
'DIMENSION time_id FROM time
DIMENSION channel_id FROM channel
DIMENSION product_id FROM
product
DIMENSION customer_id FROM customer
MEASURE sales FROM sales
MEASURE forecast_sales from fcast_sales'))
WHERE time_id IN ('Oct02','Nov02', 'Dec02')
AND channel_id = 'Direct'
AND product_id = 'Tide'
AND customer_id in ('All Customers');
И последнее: корпорация Oracle подготовила еще одну большую новость для 10g — грядущий выпуск Oracle 10g Business Intelligence, первого инструментального средства Oracle для работы с запросами, адресованными непосредственно аналитическим рабочим пространствам Oracle OLAP. Востребованность Oracle OLAP Option до сих пор была ограничена тем, что для работы с запросами не хватало доступного инструментария «с иголочки». Oracle планирует исправить эту ситуацию в ближайшие несколько месяцев с помощью Discoverer Plus OLAP — новой версии Oracle Discoverer, которая работает с обоими типами источников данных (как реляционными, так и OLAP), с помощью нового продукта Microsoft Excel Addin, который позволяет обрабатывать данные OLAP с использованием знакомого интерфейса Excel, а также Enterprise Planning and Budgeting — полного набора средств составления бюджетов, планирования и анализа, поставляемого как часть Oracle Applications 11.5.9.
К чему это приведет
Хотя многие новые возможности Oracle 10g OLAP и Microsoft Analysis Services 2005 появились в результате конкуренции, основное различие в подходе этих двух производителей баз данных сфокусировалось в выборе языка запросов MDX корпорацией Microsoft и SQL — корпорацией Oracle.
Все запланированные Microsoft новые возможности, такие как унифицированная многомерная модель, упреждающее кэширование и Intellicube, сфокусированы на облегчении ввода данных в кубы Analysis Services, эффективно устраняя потребность в какихлибо реляционных запросах к хранилищам данных. С внедрением оптимизированной схемы кубов Analysis Services 2005 это теоретически соединит гибкость реляционных систем с высокой производительностью MOLAP без необходимости когдалибо проектировать агрегирующие таблицы. Разумеется, это делает MDX языком запросов будущего для корпорации Microsoft, а XML/A — его интерфейсом API.
Oracle, в свою очередь, работает над тем, чтобы встроить функциональные возможности OLAP еще глубже в реляционные базы данных. При этом данные OLAP будут храниться в базах Oracle, сейчас либо в реляционном, либо в многомерном виде, а в будущем — в какомлибо гибридном формате. Этот формат будет обрабатываться на низком уровне, который не потребует внимания администраторов баз данных. Oracle, пользуясь всей мощью занимаемой позиции на рынке реляционных баз данных, ставит реляционные базы в центр своей стратегии в отношении OLAP. При этом базы данных будут поддерживать хранение собственных многомерных типов данных и объектов. Для Oracle язык SQL является предпочтительным, при этом Java OLAP API (или JOLAP в будущем) будет использоваться в качестве API, а генераторы отчетов на основе данных OLAP будут твердо встроены в базы данных Oracle.
Успех подхода Microsoft,
безусловно, определяется тем, сумеет ли корпорация заменить SQL на MDX в
качестве предпочтительного языка запросов. Успех Oracle зависит от того,
насколько удачно корпорация сможет встроить OLAP в реляционную СУБД и насколько
жизнеспособным окажется SQL с аналитическими расширениями и функцией OLAP_TABLE
в роли языка многомерных
запросов.
Предстоящий выбор
Администраторы баз данных, работающие в основном в среде Oracle или Microsoft, естественным образом склонятся к предложениям по OLAP этих производителей. Поскольку выход SQL Server 2005 ожидается не ранее 2005, множество новых возможностей Analysis Services привлечет администраторов баз данных, желающих с максимальной эффективностью воспользоваться свежими предложениями. Последняя версия Oracle OLAP Option доступна уже сейчас, и грядущая доступность новых версий инструментария Oracle для работы с запросами, несомненно, увеличит востребованность технологии Oracle OLAP.
А что же делать тем организациям, которые собираются внедрить аналитику OLAP, но не имеют предрасположенности ни к Oracle, ни к Microsoft? Для них стратегия такова: если у организации есть опыт применения Microsoft SQL Server, то можно с облегчением перенести все отчетные данные в кубы OLAP в Analysis Services и формировать отчеты с помощью MDX и XML/A. Если простота администрирования и установки являются обязательным требованием, и организация рассматривает платформы Windows как свой стандарт, то следует внимательнее взглянуть на Microsoft Analysis Services 2005, когда этот продукт выйдет в свет в следующем году. Если же вы заинтересованы в том, чтобы встроить аналитику OLAP в свои обычные приложения с базами данных, если приоритетами являются масштабируемость и обеспечение одновременной работы множества пользователей, если вам нравится более крутая кривая обучения и вы рассматриваете использование других платформ в дополнение к Windows, если ваша организация желает пользоваться SQL для формирования всей отчетности, то стоит поподробнее рассмотреть Oracle OLAP.
Универсальные высокопроизводительные иерархии в SQL Server
Дэннис В. Форбс (Dennis W. Forbes)
В большинстве случаев моделируемой структурой базы данных (далее БД) является вездесущая иерархия: все элементы связаны между собой (при этом все элементы, кроме корневого, имеют единственного родителя), и у каждого из них может быть от нуля до нескольких дочерних узлов.
Структуру базы данных часто называют «перевернутым деревом» из-за визуальной схожести, что неудивительно. Примеры таких иерархий включают корпоративные структуры составления отчетов, объединения по географическому местоположению, системы инвентаризационного учета (например, когда части собираются в компоненты, которые в свою очередь, могут объединяться в продукты, которые затем входят в состав установочных единиц и т. д.), перечень категорий аукционных торгов и проч. Файловая система наших компьютеров, дерево из папок и файлов, является распространенным примером подобной иерархической структуры.
К сожалению, реализация иерархий в моделях данных связана с определенными трудностями. Наиболее универсальные, высокореляционные модели могут оказаться сложными и неэффективными с точки зрения выполнения запросов. В то же время более ограниченные, жестко закодированные решения предоставляют краткосрочные преимущества, которые, впрочем, не способны избежать появления критических недостатков по мере расширения систем. В этой статье содержатся некоторые технологические приемы для достижения наилучшего результата в обеих сферах — мощный метод создания простых, самоподдерживающихся, универсальных, реляционных иерархических наборов.
MDX в Analysis Services: вопросы средней сложности
Уильям Пирсон (William Pearson)
В этой статье представлены практические примеры с обработкой иерархических связей в выражениях. Мы также рассмотрим, как можно обнаружить пустые члены, и покажем, почему это может быть так важно при построении выражений.
Использование иерархий куба для получения данных
В этой статье я рассмотрю применение вычисляемых членов для определения их вклада в более сложные вычисления. С этой целью они часто используются в финансовых и иных отчетах. Хорошим примером может служить расчет процента от общих расходов организации для индивидуальных магазинов, что позволит проанализировать успешность работы одного магазина по сравнению с другими, у подобных вычислений могут быть и другие применения. Мы также выполним вычисления доли каждого магазина в общей промежуточной сумме на различных уровнях иерархии измерения Store (City, State, Country).
Нашей задачей является демонстрация возможностей кубов в использовании иерархических связей между членами измерения. Мы также попрактикуемся в определении пустых членов и покажем, как следует строить логику, которая будет обрабатывать сложные ситуации, возникающие изза присутствия пустых членов.
Применение MDX в Analysis Services: извлечение данных из нескольких кубов
Уильям Пирсон (William Pearson)
Данный цикл статей призван научить вас практическому применению фундаментальных основ MDX с позиций MS SQL Server 2000 Analysis Services (далее для экономии места и времени в большинстве случаев я буду использовать название Analysis Services).
Нашей основополагающей целью будет манипулирование многомерными источниками данных с использованием выражений MDX в разнообразных сценариях, которые были составлены так, чтобы отвечать реальным потребностям интеллектуальных ресурсов предприятия. Предполагается, что для MSSQL Server 2000, MSSQL Server 2000 Analysis Services и в упоминаемых Books Online и Samples установлен Service Pack 3.
В этой статье мы проанализируем, как применить MDX в Analysis Services для одновременного извлечения значений из разных кубов. Это даст нам возможность получать доступ сразу к множеству источников данных OLAP, что зачастую очень полезно при анализе и составлении отчетов. Мы обсудим пример сценария из реальной жизни, в котором часто возникает необходимостьи, продемонстрируем, как вычислять среднее значение на единицу товара, используя пример расчета дохода от продажи единицы товара на основании значений, извлеченных из двух отдельных источников данных OLAP.
(Возврат на основную страницу)