Использование виртуальных кубов в IBM InfoSphere Warehouse 9.7 для комбинирования бизнес-сценариев и повышения производительности

Виртуальные кубы (virtual cube) являются одной из новых функциональных возможностей Cubing Services в IBM InfoSphere™ Warehouse 9.7. Виртуальный куб позволяет объединить несколько кубов, чтобы один запрос возвращал объединенные результаты из кубов, входящих в объединение. Виртуальные кубы дают возможность значительно сократить время реагирования сервера кубов на запросы за счет эффективного сегментирования данных с целью оптимального использования кэш-памяти (в некоторых случаях время отклика сокращается более чем в 100 раз). Виртуальные кубы также предоставляют решение для комбинирования результатов путем объединения различных региональных кубов в общий куб для страны. Они позволяют также объединять данные о продажах с курсами обмена валют для получения представления о результатах бизнеса во всем мире. В этой статье рассказывается, как создать виртуальные кубы, как они работают и как использовать их с InfoSphere Warehouse Cubing Services 9.7.

Адриан Митря, программист, IBM

Адриан Митреа (Adrian Mitrea) - фотографияАдриан Митря (Adrian Mitrea) руководит разработкой функциональности виртуальных кубов для IBM InfoSphere Warehouse Cubing Services 9.7. Пришел в IBM в качестве стажера в 2003 году. Получил степень по вычислительной технике в Техническом университете Клуж-Напока в Румынии.



23.09.2011

Введение

Виртуальный куб - это логический куб, определенный на основе двух существующих кубов: либо двух реальных кубов, либо двух других виртуальных кубов, либо одного виртуального и одного реального куба. Если нужно сгруппировать более двух кубов, их можно объединять парами. Полученные виртуальные кубы можно объединять с другими кубами, как показано на рисунке 1. Объединение осуществляется на основе названий измерений. Измерения с одинаковыми названиями в обоих кубах будут объединяться. Измерения, существующие в одном кубе и не имеющие соответствующего измерения с тем же самым названием в другом, будут просто добавляться в виртуальный куб. Виртуальные кубы могут использоваться для комбинирования двух кубов, имеющих одно или несколько общих измерений. Два куба считаются имеющими общее измерение, если измерение с определенным названием присутствует в обоих кубах. Например, если два куба имеют измерение [Time], в контексте виртуальных кубов считается, что они имеют общее измерение [Time]. Два объединяемых куба могут принадлежать различным моделям кубов, поэтому они могут иметь совершенно разные внутренние структуры. Основное требование – у них должно быть хотя бы одно общее измерение. Виртуальные кубы и зависимые кубы должны размещаться в одной базе данных; виртуальный куб может быть определен только с использованием кубов из одного и того же сервера кубов.

В качестве примера на рисунке 1 показаны кубы, объединенные в виртуальные кубы. Виртуальные кубы идентифицируются символом звездочки (*). На рисунке кубы Store Sales (продажи через магазин) и Web Sales (Web-продажи) имеют почти идентичные измерения и объединены в виртуальный куб Total Sales (суммарные продажи). Виртуальный куб Total Sales и куб Inventory (склад) имеют общее измерение Time (время) и объединены в виртуальный куб Inventory Sales (продажи и склад). Отметим, что виртуальные кубы (Total Sales) могут участвовать в формировании других виртуальных кубов (Inventory Sales). Виртуальный куб Inventory Sales в данном случае полезен потому, что он группирует кубы, являющиеся частью двух отдельных бизнес-задач: куб Inventory используется для отслеживания движения по складу, а куб Sales используется для отслеживания данных об объеме продаж.

Рисунок 1. Группирование кубов для формирования виртуальных кубов
Рисунок 1. Группирование кубов для формирования виртуальных кубов

Когда выдается запрос к виртуальному кубу, этот запрос направляется в зависимые кубы, формирующие два промежуточных результата, которые объединяются в соответствии с оператором объединения виртуального куба. Операторами объединения могут быть SUM, MINUS, PRODUCT, DIVIDE, MAX, MIN и NOP (возвращает данные из первого куба в определении виртуального куба).

Например:

  • При объединении [CubeA] и [CubeB] в [Virtual Cube] с использованием оператора SUM выборка из [Virtual Cube] = выборка из [CubeA] + выборка из [CubeB].
  • При объединении [CubeA] и [CubeB] с использованием оператора MAX выборка из [Virtual Cube] = MAX (выборка из [CubeA], выборка из [CubeB]).

Сценарии применения виртуальных кубов

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

Сценарий сокращения времени ожидания: сегментирование данных по времени

Вся информация о продажах хранится в одном кубе [AllSales]. Фактические данные добавляются каждую ночь, что вызывает необходимость обновления таблиц материализованных запросов (MQT). Для больших кубов это требует значительного времени. Чтобы улучшить производительность, можно сегментировать данные для куба [AllSales] по времени, образовав два куба [HistoricSales] и [CurrentMonthSales], и определить виртуальный куб под названием [VirtualSales], объединяющий эти два куба. Куб [HistoricSales] используется для записи информации о прошлых продажах, которая меняется не часто. Меньший куб [CurrentMonthSales] используется для записи информации о суточных продажах за текущий месяц. Куб [CurrentMonthSales] называется дельта-кубом (delta cube).

Повышению производительности обновлений кэша способствуют несколько факторов:

  • Время обновления MQT-таблицы уменьшается, поскольку обычно нужно обновлять только маленькие MQT-таблицы, основанные на [CurrentMonthSales].
  • Большие MQT-таблицы, основанные на [HistoricSales], обновляются только один раз в месяц.
  • Поскольку результаты запросов из куба [HistoricSales] заранее кэшированы, производительность запросов по данным о продажах за весь период времени повышается.
  • Из-за меньшего размера куба [CurrentMonthSales] производительность запросов по данным о продажах за текущий месяц или за весь период времени повышается.

Данные можно сегментировать по времени, определяя представления (view) базы данных, содержащие исторические данные и данные текущего месяца соответственно. Модели куба для [HistoricSales] и [CurrentMonthSales] используют эти представления вместо таблиц базы данных. Представления следует создавать заново ежемесячно, когда данные, накопленные в представлении для текущего месяца, переходят в историческое представление. Повышение производительности в данном сценарии непосредственно связано с размером куба [CurrentMonthSales] относительно куба [HistoricSales]. Для получения наилучших результатов исторический куб должен быть как можно большим, а инкрементный куб CurrentMonth должен быть как можно меньшим.

В одном тестовом сценарии использовался куб текущего месяца, в котором фактическая таблица состояла из 3 миллионов строк, а исторический куб основывался на фактической таблице с 900 миллионами строк. Тестовые запросы для одного пользователя выполнялись более чем в 100 раз медленнее в случае, когда большой куб [AllSales] содержал все данные по сравнению с использованием виртуального куба [VirtualSales]. Чтобы достичь подобного соотношения размеров между дельта-кубом и кубом с историческими данными, дельта-куб можно уменьшить, настроив его на обновление еженедельно, два раза в неделю и т.д., в зависимости от объема данных.

Следующий пример основан на базе данных GOSALES, поставляемой с версией 9.7. В демонстрационных целях сегментация по времени выполняется только по годам. Создаются два куба, [CSSalesMarketing_Recent] и [CSSalesMarketing_Historic], и виртуальный куб [CSSalesMarketing], объединяющий эти кубы. Фактическая таблица для [CSSalesMarketing_Recent] заменяется представлением, в котором данные разбиваются по годам, как показано в листинге 1.

Листинг 1. Создание представления текущих данных
create view GOSALESDW.fact_recent as select ORDER_DAY_KEY, ORGANIZATION_KEY, 
EMPLOYEE_KEY, RETAILER_KEY, RETAILER_SITE_KEY, PRODUCT_KEY, PROMOTION_KEY, 
ORDER_METHOD_KEY, SALES_ORDER_KEY, SHIP_DAY_KEY, CLOSE_DAY_KEY, QUANTITY, 
UNIT_COST, UNIT_PRICE, UNIT_SALE_PRICE, GROSS_MARGIN, SALE_TOTAL, GROSS_PROFIT 
from gosalesdw.sls_sales_fact fact, gosalesdw.go_time_dim time 
where fact.ORDER_DAY_KEY = time.DAY_KEY and time.CURRENT_YEAR = 2007;

В листинге 2 показано, как создать представление исторических данных.

Листинг 2. Создание представления исторических данных
create view GOSALESDW.fact_historic as select ORDER_DAY_KEY, ORGANIZATION_KEY, 
EMPLOYEE_KEY, RETAILER_KEY, RETAILER_SITE_KEY, PRODUCT_KEY, PROMOTION_KEY, 
ORDER_METHOD_KEY, SALES_ORDER_KEY, SHIP_DAY_KEY, CLOSE_DAY_KEY, QUANTITY, 
UNIT_COST, UNIT_PRICE, UNIT_SALE_PRICE, GROSS_MARGIN, SALE_TOTAL, GROSS_PROFIT 
from gosalesdw.sls_sales_fact fact, gosalesdw.go_time_dim time 
where fact.ORDER_DAY_KEY = time.DAY_KEY and time.CURRENT_YEAR < 2007;

В качестве столбцов представления выбираются все столбцы, определенные в исходной сегментируемой таблице данных gosalesdw.sls_sales_fact. Модели куба для этих двух кубов очень просты и в целях демонстрации имеют одно измерение [Time] и один показатель: Sale Total (Recent) и Sale Total (Historic), соответственно. Виртуальный куб переименовывает обе эти единицы измерения в Sale Total и объединяет оба куба, используя в качестве оператора объединения сложение. Результат запроса к виртуальному кубу равен сумме одинаковых запросов к двум кубам.

На рисунках 2, 3 и 4 показано использование измерения [Time] и показателя Sale Total с Microsoft® Excel. Отметим, что общий итог для виртуального куба равен сумме общего итога для [CSSalesMarketing_Recent] и общего итога для [CSSalesMarketing_Historic]. [CSSalesMarketing_Recent] содержит значения только для 2007 года, в то время как [CSSalesMarketing_Historic] содержит значения только за годы, предшествовавшие 2007 году.

В таблице 1 и на рисунке 2 показаны данные для [CSSalesMarketing_Recent] из Pivot Table Field List при выборе Time и Sale Total (Recent).

Таблица 1. Данные для [CSSalesMarketing_Recent]
Итог продаж (недавних)2007Общий итог
Итого1117336274.071117336274.07
Рисунок 2. [CSSalesMarketing_Recent] содержит только данные за 2007 год
Рисунок 2. [CSSalesMarketing_Recent] содержит только данные за 2007 год

В таблице 2 и на рисунке 3 показаны данные для [CSSalesMarketing_Historic] из Pivot Table Field List при выборе Time, Year и Sale Total (Historic).

Таблица 2. Данные для [CSSalesMarketing_Historic]
Итог продаж (исторических)200420052006Общий итог
Итого914352803.721159195590.161495891100.903569439494.78
Рисунок 3. [CSSalesMarketing_Historic] содержит только исторические данные
Рисунок 3. [CSSalesMarketing_Historic] содержит только исторические данные

В таблице 3 и на рисунке 4 показаны данные для объединенных кубов из Pivot Table Field List при выборе Time, All, Year и Sale Total.

Таблица 3. Объединенные продажи
Продажи2004200520062007Итог
Исторические914352803.721159195590.161495891100.903569439494.78
Недавние1117336274.071117336274.07
Общий итог4686775768.85
Рисунок 4. [CSSalesMarketing] содержит и исторические, и недавние данные
Рисунок 4. [CSSalesMarketing] содержит и исторические, и недавние данные

Примеры определений виртуальных кубов и самих кубов для сценария сегментирования по времени находятся в доступном для загрузки файле GSDB_TimePartitionExample. Загрузите его и исследуйте эти виртуальные кубы.

Общее бизнес-представление: сценарий "Конвертация валют"

Вся информация о продажах хранится в одном кубе [GlobalSales], и нужно преобразовать некоторые из показателей продаж, представленные в долларах США, в другие валюты. Если данные о продажах и курсы валют хранятся в одном кубе [GlobalSales], то он содержит много лишних данных и с ним трудно работать. Для решения этой проблемы можно создать куб [CurrencyExchange] для хранения курсов валют, чтобы не менять куб [Global Sales], и определить виртуальный куб [SalesConversion] для конвертации валют. Кубы [GlobalSales] и [CurrencyExchange] имеют некоторые общие измерения, например Time, но обычно при этом разные структуры.

В виртуальном кубе [SalesConversion] необходимо определить вычисляемый элемент, выполняющий реальную конвертацию валют. Поскольку реальная конвертация валют может происходить не ежедневно, а только в заданный день или с определенной периодичностью (например, ежемесячно или еженедельно), в данном сценарии можно использовать функции ClosingPeriod и OpeningPeriod. Например, в листинге 3 определены вычисляемые элементы, использующиеся для конвертации валют, если она осуществляется в конце каждого месяца.

Листинг 3. Вычисляемые элементы для конвертации валют
Calculated member name: Conversion2
Calculation: closingperiod([Time].[Month], [Time].currentmember), 
		[SalesConversion].[Measures].[CONVERSION_TO_LOCAL])
		
Calculated member name: UnitSalesLocal
Calculation:[ Virtual Cube].[Measures].[Conversion2] * 
		[SalesConversion].[Measures].[Unit sale price]

Отметим, что один виртуальный элемент использует другой.

Объединение различных кубов: сценарий "Запасы и продажи"

Иногда полезно объединить кубы, которые имеют не много общих измерений, так как для выполнения некоторых запросов объединение этих кубов может иметь смысл. Скажем, виртуальный куб [Inv Sales], объединяющий куб [Inventory] и куб [Sales], содержит некоторые измерения, общие для обоих кубов (например, [Time] и [Product]), а некоторые измерения не являются общими. Два этих куба решают две различные бизнес-задачи: отслеживание ключевых показателей производительности для продаж и анализ уровней запасов.

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

Например, можно вычислить эффективность управления ресурсами, используя формулу коэффициента оборачиваемости, как показано в листинге 4.

Листинг 4. Вычисление коэффициента оборачиваемости
Inv Turnover Ratio = [Inv Sales].[Measures].[Cost of Goods Sold] / 
	[Inventory].[Measures].[Average Inventory] 
	
where
	
[Inv Sales].[Measures].[Cost of Goods Sold] = 
	[Inventory].[Measures].[Cost of Goods] * 
	[Sales].[Measures].[Quantity Sold].

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

Таблица 4. Коэффициент оборачиваемости товарных запасов, полученный из кубов [Sales] и [Inventory] за январь 2000 г.
Категория товаровЦена единицы товара (Inventory)Проданное количество (Total sales)Стоимость проданных товаров (Inv_sales)Средний запас (Inventory)Коэффициент оборачиваемости (Inv_sales)
Home$483.764816$2329812.24$1162019.662.0
Jewelry$366.362963$1085509.86$569437.791.9
Shoes$4882.4846736$228187351.60$103371760.702.2
Sports$654.724316$2825771.52$1422073.662.0

Объединение нескольких кубов продаж: сценарий "Web-продажи и продажи через магазин"

При отслеживании данных об эффективности продаж в разных кубах виртуальный куб предоставляет способ иметь общее представление путем объединения отдельных кубов. Например, если имеется куб [Web Sales], отслеживающий эффективность продаж через Интернет, и куб [Store Sales], содержащий данные о продажах, реализованных через магазины, можно использовать виртуальный куб [Total Sales] для получения общего представления об эффективности торговли.

В этом примере оба куба, [Web Sales] и [Store Sales], имеют аналогичные измерения (например, [Product] и [Date]), но разные структуры. Куб [Store Sales] имеет дополнительное измерение [Store], как показано в списке полей сводной таблицы на рисунке 5. Аналогично, [Web Sales] имеет измерение [Websites], не существующее в [Store Sales]. Виртуальный куб [Total Sales] переименовывает измерение [Date] из обоих кубов в [Date (Total Sales)] и измерение [Items] на [Items (Total Sales)]. Эта операция выполняется в демонстрационных целях и не является обязательной, поскольку измерения [Date] и [Items], имея одинаковое название в обоих кубах, объединяются.

[Total Sales] также переименовывает два измерения, имеющиеся в обоих кубах, чтобы гарантировать аналогичность их названия и объединения. [Gross Profit (Store Sales)] и [Gross Profit (Web Sales)] переименовываются в [Gross Profit (Total Sales)]. Кубы [Web Sales] и [Store Sales] объединяются с использованием суммирования (+) в качестве оператора объединения, поэтому результат запроса к виртуальному кубу [Total Sales] будет суммой запросов к [Web Sales] и [Total Sales]. Например, на рисунке 6 показан список PivotTable Field с выбранными полями Date (Total Sales), Items (Total Sales) и Gross Profit (Total Sales). Gross Profit (Total Sales) равен 6425085101.50 $, как показано на рисунке 5.

Рисунок 5. [Total Sales] объединяет [Web Sales] и [Store Sales]
Рисунок 5. [Total Sales] объединяет [Web Sales] и [Store Sales]

Объединение кубов

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

Таблица 5. Объединение измерений кубов с целью формирования виртуального куба
Sales +Inventory >Inventory Sales
ProductProductProductИзмерения с идентичными названиями объединяются
TimeTimeTimeИзмерения с идентичными названиями объединяются
InventoryInventoryНесовпадающие измерения добавляются
StoreНежелательные измерения скрываются

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

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

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

В приведенных ниже примерах кубы имеют эквивалентные уровни, называемые State (например, California в США) и Province (например, Ontario в Канаде). В таблице 6 эти два уровня находятся на одной и той же глубине, поэтому результатом их объединения является уровень State Province, содержащий члены California и Ontario.

Таблица 6. Объединение названий уровней для общих измерений должно выполняться по иерархиям с семантически идентичными уровнями
Sales EastSales WestAll sales
CountryCountryCountry
StateProvinceState Province (несовпадающие названия объединяются)
CityCityCity
NeighborhoodNeighborhood

В таблице 7 State и Province находятся на разных уровнях, и они не будут объединяться друг с другом. Вместо этого Province объединяется с Region (например, Pacific для США не имеет эквивалента в Канаде), но Region и Province семантически не идентичны.

Отметим, что запрос к уровню Neighborhood примера виртуального куба возвращает результаты только из куба, содержащего этот уровень, например Sales East. Поскольку Sales West ничего не знает об этом уровне, возвращаемые значения могут поступать только из Sales East. Запрос к уровню City возвращает результаты из обоих кубов, поскольку оба куба имеют уровень под названием City.

Таблица 7. Если элементы не выровнены семантически, могут быть возвращены неправильные результаты.
Sales EastSales WestAll sales
CountryCountryCountry
RegionProvinceRegion Province (неверно сопоставленные уровни сформируют бессмысленные результаты)
StateState

Кроме объединения уровней, виртуальные кубы выполняют также объединение членов для общих измерений исходных кубов. Члены тоже объединяются в соответствии с их названиями, как показано на рисунке 6 и в таблице 8.

Рисунок 6. Объединение членов
Рисунок 6. Объединение членов
Таблица 8. Объединение членов для формирования виртуального куба
Cube ACube BVirtual cube
Store salesStore salesStore salesОбъединяются члены с идентичными названиями
Unit sales EastUnit sales EastНесовпадающие члены добавляются в виртуальный куб
Unit sales WestUnit sales WestНесовпадающие члены добавляются в виртуальный куб

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


Работа с виртуальными кубами

Виртуальные кубы определяются при помощи Design Studio. Задачи администрирования виртуальных кубов выполняются при помощи приложения Cubing Services Administration Console. В листинге 5 и на рисунке 7 показано, как выглядят элементы виртуального куба в Design Studio. Особо примечательные папки помечены звездочкой.

Рисунок 7. Представление элементов виртуального куба в Design Studio
Рисунок 7. Представление элементов виртуального куба в Design Studio
Листинг 5. Структура папок Design Studio
VirtualCubes
    Data Diagrams
    Data Models
        Database Model.dbm
            Database
            SQL Statements
            OLAP Objects
                CSSalesMarketing_Historic
                    FACT
                    Time
                    Cubes
                        *CSSalesMarketing_Historic* (this is a cube)
                            Time
                            Cube Facts (CSSalesMarketing_Historic)
                CSSalesMarketing_Recent
                    FACT
                    Time
                    Cubes
                        *CSSalesMarketing_Recent* (this is a cube)
                            Time
                            Cube Facts (CSSalesMarketing_Recent)
                *CSSalesMarketing* (this is a virtual cube)
                    MDX Calculated Measures
                    *Virtual Dimensions* (only renamed virtual dimensions appear here)
                        Time
                            *MDX Calculated Members*
                            Virtual Members
                    *Virtual Measures*
                        Sale total
                        Sale total
                Shared Dimensions
            GOSALESDW
            MDX
            Schema
    Other Files
    SQL Scripts

Для создания виртуальных кубов выполните следующие действия:

  1. Добавьте виртуальный куб в модель, используя опцию Add Virtual Cube.
  2. Выберите два куба, которые будут объединяться в виртуальный куб. Можно выбрать любые кубы из списка доступных.
  3. При желании переименуйте любые существующие измерения исходных кубов, выбирая Add Virtual Dimension, с целью их объединения.
  4. При желании переименуйте члены измерения для их объединения, выбирая Add Virtual Member.
  5. При желании определите или добавьте вычисляемые члены в виртуальный куб, выбирая Add MDX Calculated Member.

Единственными элементами виртуальных кубов, которые отображает Design Studio, являются те, которые были явно изменены путем выполнения операций Add. Для просмотра полной структуры куба, в которую входят все доступные измерения, иерархии и члены, можно использовать браузер измерений Design Studio. Например, если [VirtualCube] определяется как объединение [CubeA] и [CubeB], при добавлении виртуального куба в модель Design Studio отображает [VirtualCube]. Если [CubeA] имеет измерение времени под названием [Time], а [CubeB] имеет измерение времени под названием [Tiempo] и эти два измерения нужно объединить, поскольку они семантически идентичны, для выполнения объединения можно переименовать [Tiempo] в [Time]. Операция Add Dimension позволяет переименовать [CubeB].[Tiempo] в [Time]. В Design Studio вы увидите одно виртуальное измерение, определенное для виртуального куба, которое переименовывает [Tiempo] в [Time].

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

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

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

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

Виртуальные вычисляемые члены могут определяться для любого виртуального измерения, которое было добавлено в модель с использованием Add Virtual Dimension. Если некоторые члены для виртуального измерения были переименованы, в вычислениях могут использоваться новые названия членов. Ниже представлены некоторые дополнительные соображения о виртуальных вычисляемых членах:

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

Управление виртуальными кубами из Administration Console

Для пользователей Administration Console виртуальные кубы отличаются от обычных кубов в следующем:

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

Система защиты измерений

Система защиты измерений (dimensional security) - это новая функциональность InfoSphere Warehouse 9.7. Подробная информация об этой функциональности приведена в статье из раздела Ресурсы. Для виртуального куба система защиты измерений наследуется из двух составляющих его кубов. Каких-либо особенных настроек системы защиты для виртуального куба нет. Защиту можно установить для реальных исходных кубов.

Например, пусть для виртуального куба, основанного на кубах [Sales West] и [Sales East], каждый из которых имеет измерение [Store], куб [Sales West] разрешает видимость только потомков [California], а куб [Sales East] - только потомков [Florida]. Тогда виртуальный куб будет разрешать видимость только потомков Florida и California.


Запуск виртуальных кубов в Cube Server

При запуске сервера Cubing Services анализируются элементы, определенные при помощи Design Studio. К ним относятся виртуальные измерения, члены и вычисляемые члены. Если измерение или член виртуального куба переименовывается, доступное для виртуального куба название определяется пользователем. Например, пусть [CubeA] и [CubeB] объединяются в [VirtualCube]. Измерение времени для [CubeA] называется [Time], а для [CubeB] - [Tiempo]. Переименование [CubeB].[Tiempo] в [Time] вызывает объединение CubeA.[Time] с CubeB.[Tiempo], поскольку они оба имеют название Time. Виртуальный куб будет иметь измерение [Time]. Следующий шаг - объединение иерархий общих измерений из двух исходных кубов. В данном примере иерархии для CubeA.[Time] и CubeB.[Tiempo] объединяются уровень за уровнем, начиная с нулевого уровня.

Процесс объединения проверяет, имеют ли члены измерения одинаковые названия, и если это так, виртуальный куб будет содержать только один член, полученный путем объединения исходных членов. Если член существует только в одном из кубов, он просто добавляется в виртуальный куб. Например, измерение [CubeA].[Time] имеет члены 2008 и 2009, а [CubeB].[Time] имеет члены 2007 и 2008. Виртуальный куб, объединяющий эти два куба, будет иметь члены 2007, 2008, объединенный из обоих кубов, а также 2009. Запрос для 2007 возвращает данные из родительского куба [CubeB], а запрос для объединенного члена 2008 возвращает результаты из обоих кубов [CubeA] и [CubeB], объединенные в соответствии с оператором объединения. Если же, например, [CubeB].[Time] имеет члены 2007 и 2008_1, то виртуальный куб из предыдущего примера будет иметь члены 2007, 2008, 2008_1 и 2009. Если переименовать 2008_1 в 2008, виртуальный куб будет иметь члены 2007, 2008, объединенный из обоих кубов, а также 2009.

Еще одно важное замечание относительно виртуальных кубов. Что произойдет, если структура двух кубов меняется во время работы сервера кубов и эти кубы перезагружаются? В этом случае виртуальный куб следует перекомпоновать путем его остановки и запуска. При каждом запуске виртуального куба проверяются оба составляющих его куба и выполняется объединение.


Заключение

В данной статье рассказано, как создаются виртуальные кубы и как работает процесс объединения. Также подробно описана работа с виртуальными кубами при помощи Design Studio и Administration Console. Представленные примеры охватывают широкий диапазон ситуаций и могут служить отправной точкой при реализации ваших собственных решений. Рассмотренные сценарии решают следующие задачи:

  • Повышение производительности за счет сегментирования по времени.
  • Глобальное представление бизнеса с использованием конвертации валют.
  • Анализ оборачиваемости товарных запасов.
  • Объединение данных из различных кубов, таких как Web Sales и Store Sales.
  • Географическое сегментирование данных, когда один куб отслеживает продажи на востоке, а второй - на западе.

Загрузка

ОписаниеИмяРазмер
GSDB_TimePartitionExampleGSDB_TimePartitionExample.xml15KБ

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=761031
ArticleTitle=Использование виртуальных кубов в IBM InfoSphere Warehouse 9.7 для комбинирования бизнес-сценариев и повышения производительности
publish-date=09232011