Проверенные приемы IBM Cognos : Эффективное использование фидеров IBM Cognos TM1

PПродукт (продукты): IBM Cognos TM1; область интересов: управление финансами

Одним из сложных вопросов при разработке кубов IBM Cognos TM1 является надлежащая реализация т.н. фидеров (feeder) в рамках правил TM1. Данный документ посвящен описанию фидеров и их эффективному применению для повышения производительности при построении кубов IBM Cognos TM1.

Гай Джонс, технический руководитель по решениям для клиентов, IBM

Гай Джонс (Guy Jones) является техническим руководителем по решениям для клиентов на базе продукта Cognos Performance Management. Г. Джонс использовал продукт TM1 на протяжении пяти лет и активно участвовал в разработке сложных систем для подтверждения концепций для клиентов.



Джон Лихи, консультант по проверенным приемам, IBM

Джон Лихи (John Leahy) является консультантом по проверенным приемам для продуктов IBM Business Analytics; он специализируется в области решений для управления финансовой эффективностью и является сертифицированным разработчиком для IBM Cognos TM1.



21.06.2013

Введение

Назначение

Надлежащая реализация т.н. фидеров (FEEDER) в рамках правил TM1 является одним из сложных вопросов при разработке кубов IBM Cognos TM1. Данный документ посвящен описанию фидеров и их эффективному применению для повышения производительности при построении кубов IBM Cognos TM1.

Обязательные требования

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

Применимость

Продукт IBM Cognos TM1, версии с 9.5.1 по 10.1

Исключения

Отсутствуют.


Определения

Что такое фидеры

Вычислительный механизм продукта IBM Cognos TM1 использует фидеры для эффективного использования разреженности куба с вычислениями на основе правил. Фидеры выявляют в кубе поля, которые задействованы в вычислениях на основе правил, и помечают эти поля как исключения для алгоритма сжатия разреженных данных.

Причины использования фидеров

OLAP-кубы могут иметь очень низкую степень заполнения вследствие разных уровней гранулярности в имеющихся данных или просто в силу природы конкретного куба. Например, в кубе Bill of Materials (Ведомость материалов), который охватывает множество конечных продуктов, множество различных компонентов и множество различных поставщиков, пустых ячеек будет значительно больше, чем заполненных, поскольку не каждый конечный продукт нуждается в каждом отдельном компоненте от каждого отдельного поставщика. Наш опыт показывает, что в больших разреженных OLAP-кубах отношение количества незаполненных ячеек к количеству заполненных ячеек может превышать 100 000 000:1.

Применение алгоритмов, ориентированных на матрицы со стандартной плотностью, к вычислениям в разреженном кубе может привести к потреблению значительных вычислительных ресурсов и потребовать большого времени на выполнение. С целью повышения производительности вычислений в разреженных кубах в продукте IBM Cognos TM1 по умолчанию применяется алгоритм сжатия разреженных данных. Это позволяет продукту IBM Cognos TM1 выполнять агрегацию и консолидацию по различным измерениям очень быстро и очень эффективно. Не следует забывать, что эти агрегации или консолидация вычисляются согласно иерархической организации измерений в кубе. Они отличаются от вычислений на основе правил, которые используются для расчета различных полей внутри или за пределами измерений и кубов. В качестве примера агрегации или консолидации по измерениям рассмотрим измерение, содержащее следующие элементы: Product A, Product B, Product C и Total Products. Согласно иерархической организации измерения, все ячейки со значениями для элементов Product A, Product B и Product C будут агрегированы в элемент Total Products. Пример основанного на правилах вычисления: Price * Volume = Revenue. В продукте IBM Cognos TM1 правила определяются за пределами измерения с помощью инструмента TM1 Rules Editor, после чего добавляются к кубу TM1.

Однако если продукт IBM Cognos TM1 обнаруживает, что к кубу было добавлено правило, он автоматически деактивирует алгоритм сжатия разреженных данных. Эта мера призвана гарантировать корректное вычисление правила — если алгоритм сжатия разреженных данных будет оставлен в активированном состоянии, то вычисляемое поле (зависимая переменная) и некоторые или все исходные поля (независимые переменные) будут сжаты и окажутся недоступными для надлежащей работы вычислений. В результате после реализации правила производительность куба TM1 значительно уменьшится, поскольку он не сможет воспользоваться алгоритмом сжатия разреженных данных.

В вышеописанной ситуации у нас имеются две возможности: 1) Спроектировать куб, у которого есть только агрегации или консолидация по измерениям, а затем в полной мере использовать алгоритм сжатия разреженных данных для повышения производительности; 2) Спроектировать куб, который использует правила TM1 для сложных вычислений, но при этом страдает от низкой производительности.

К счастью, при проектировании кубов IBM Cognos TM1 имеется и третья возможность. Эта возможность состоит в проектировании куба, который использует правила TM1 для сложных вычислений, но при этом имеет активированный алгоритм сжатия разреженных данных с исключениями для полей, которые задействованы в каких-либо вычислениях на основе правил. Именно в этом случае в правилах TM1 применяются опции SKIPCHECK и FEEDERS.

Что такое SKIPCHECK

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

Что представляет собой поведение по умолчанию

По умолчанию IBM Cognos TM1 не вставляет параметры SKIPCHECK или FEEDERS в правила TM1 автоматически. Эти параметры должны быть вписаны в правило разработчиком TM1. Если параметры SKIPCHECK и FEEDERS не будут вписаны в правило TM1, то все ячейки в кубе будут оценены ("обсчитаны") вычислительным механизмом TM1 и алгоритмами подавления нулей. Правило TM1 без параметра SKIPCHECK или FEEDERS выполнит все вычисления корректно, однако при этом производительность будет ниже, чем в случае включения этих параметров. Разработчик IBM Cognos TM1 может в качестве опции задать использование параметров SKIPCHECK и FEEDERS в каждом конкретном кубе.

Как работают фидеры

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

Фидеры также можно использовать для подавления нулей. Алгоритмы подавления нулей используют фидеры с целью исключения нулевых элементов из представления. Обратите внимание, что с помощью фидера система определяет, включена ли ячейка в представление, а не устанавливает факт наличия/отсутствия у этой ячейки нулевого значения. Ячейки будут корректно вычислены и отображены в "неподавленном" представлении, однако при активированном подавлении нулей они исчезнут. Это обуславливается тем фактом, что эти ячейки не снабжаются.

Фидеры задаются разработчиком IBM Cognos TM1 в инструменте TM1 Rules Editor. Почти во всех случаях разработчик задает фидер для каждого правила. Когда пользователь запускает сервер TM1 или когда пользователь сохраняет правило, система оценивает FEEDER-утверждения в правилах и помечает вычисляемые ячейки в кубе с целью выделения ненулевых ячеек.

Одна из наиболее распространенных ошибок, которую совершают многие разработчики IBM Cognos TM1 при реализации фидеров, состоит в задании фидеров неэффективным способом. Две наиболее распространенных ситуации, способные отрицательно повлиять как на производительность, так и на целостность данных:

  • Реализации, приводящие к "избыточному снабжению" приложения IBM Cognos TM1
  • Реализации, приводящие к "недостаточному снабжению" приложения IBM Cognos TM1

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

Таким образом, избыточное снабжение обеспечит ожидаемые результаты (целостность вычислений и т.д.), однако приложение будет работать менее эффективно — потреблять больше вычислительных ресурсов и/или требовать больше времени на исполнение. Этот тезис подтверждается тем фактом, что при подавлении нулей вычислительный механизм IBM Cognos TM1 фактически выполняет два прохода. Сначала механизм оценивает правила и свертки (обобщения) измерений, а также создает представление. В первом проходе он будет использовать фидеры, чтобы решить, включить ли или исключить ячейку. Если подавление нулей активировано, система выполнит второй проход над представлением, созданным в первом проходе — она удалит нулевые строки и столбцы исходя из реального наличия/отсутствия нулевого значения у ячейки в представлении.


Пять важных соображений относительно фидеров

Пять наиболее важных соображений относительно фидеров при построении приложения TM1.

  1. Фидеры применяются только к вычисляемым на основе правил ячейкам или к их сверткам.
  2. Вычисляемым ячейкам уровня N: будет всегда требоваться фидер для поддержания целостности вычислений и для подавления нулей. Обратите внимание, что в иерархическом измерении элементы уровня N: являются элементами уровня листа или дочернего уровня. Элементы уровня C: являются консолидированными элементами или элементами родительского уровня, которой осуществляет агрегацию элементов уровня N:. Например, если в размерности заданы элементы January, February и March и 1 квартал, тогда элементами уровня N: являют эти три месяца, а общее количество за 1 квартал является элементом уровня C:.
  3. C: Ячейки уровня C: снабжаются автоматически, если их дочерние элементы уровня N: имеют заданные для них фидеры. Система будет просматривать фидеры дочерних элементов сводной ячейки, чтобы определить, осуществляется ли снабжение сводной ячейки. Этот принцип применяется к пространственным сверткам вычисляемых ячеек уровня N: или к вычисляемым ячейкам уровня C:. Чтобы проиллюстрировать этот тезис, предположим, что у нас есть показатель Closing Balance. Напишем правило, согласно которому все сводные элементы в измерении Time будут извлекать значение из дочернего элемента уровня последнего листа данного родителя. Таким образом, в данном примере показатель Closing Balance за 1 квартал (Q1) будет считаться на основе месяца March, а не посредством сложения месяцев January, February и March. Поскольку March является дочерним элементом Q1, у нас нет необходимости снабжать вычисление для Q1. Фидеры для ячейки уровня C: задаются посредством оценки фидеров дочерних элементов уровня N: от родителя. Однако фидеры уровня C: подвергаются оценке с целью подавления нулей.
  4. После того как ячейка будет заполнена, она продолжит обращаться к исходному фидеру даже после того, как FEEDER-утверждение будет изменено. Существует два метода для принудительного инициирования повторной обработки фидеров после изменения: 1) выполнить команду CubeProcessFeeders в процессе TM1 TurboIntegrator (TI); 2) перезапустить сервер IBM Cognos TM1. Это необходимо иметь в виду на всем протяжении разработки приложения. Например, исходный фидер чрезмерно снабжал куб, но затем был скорректирован посредством написания более строгого фидера, который оказался точнее. Однако до тех пор пока сервер TM1 Server не будет перезапущен, у нас не будет возможности для проверки этого фидера на предмет его корректной работы.
  5. Фидеры из числовых ячеек срабатывают лишь один раз. Фидеры из строковых ячеек срабатывают при каждом изменении их значения. В правиле часто используется параметр, задающий расположение результата вычислений. Если для снабжения вычисления используется числовой элемент, то этот фидер будет только срабатывать один раз — таким образом, любое обновление вышеупомянутого параметра не будет создавать фидер для нового расположения.

Где задаются фидеры

Фидеры задаются в инструменте TM1 Rule Editor. В общем случае для каждого правила должен существовать как минимум один сопроводительный фидер. Правила должны быть структурированы следующим образом:

SKIPCHECK;
#
# Write your Rules here
#
FEEDERS;
#
# Write Your FEEDERS here
#
# End of Rule

Пример:

SKIPCHECK;
['A*B']=n:['A']*['B'];

FEEDERS;
['A']=>['A*B'];

Обратите внимание, что в этом примере для снабжения правила используется только элемент [‘A’]. Причина, по которой не включен элемент [‘B’], будет объяснена более подробно в разделе под названием Умножение.


Определение наличия снабжения ячейки

Для определения того, осуществляется ли снабжение той или иной ячейки, можно использовать приведенные ниже методы. Примечание. Если вы внесли большое количество обновлений, то перед выполнением этих проверок следует перезапустить сервер IBM Cognos TM1.

Метод 1 Визуальное инспектирование правила

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

Метод 2 Визуальная проверка результатов вычисления

Проверьте, что вычисление выполняется корректно и что свертка данного элемента демонстрирует корректные результаты. В показанном ниже простом примере обратите внимание на то, что свертка A*B” выполняется некорректно. Это вызвано тем, что A*B” не снабжается из ячеек Jan, Feb и Mar, поэтому вычислительный механизм IBM Cognos TM1 игнорирует эти ячейки, когда выполняет свертку.

Ниже показано представление куба IBM Cognos TM1 в инструменте IBM Cognos TM1 Cube Viewer. В этом представлении демонстрируется два атрибута (A и B) и результат (A*B), получаемый посредством правила. В данном примере правило определено следующим образом.

['A*B'] = n: ['A']*['B'];

Обратите внимание, что на значение на пересечении A*B” и Q1-10 равно нулю, что неверно.

Рисунок 1. Неправильный результат вычисления вследствие того, что [A*B] снабжается некорректно или вообще не снабжается
Figure 1 – Incorrect calculation result due to the fact that [A*B] is not being fed correctly or at all

Метод 3 Проверка на подавление нулей

Нажмите на пиктограмму Suppress Zeros, а затем пересчитайте представление. Показанное ниже представление возникнет после того, как вы выберете вышеупомянутую пиктограмму подавления нулей, в результате чего в кубе IBM Cognos TM1 не будет показано никаких нулей. Кроме того, в этом представлении не показаны ячейки для A*B вследствие отсутствия фидеров. Обратите внимание на всплывающее сообщение Feeders:(Unnamed).

Рисунок 2. При задействованном подавлении нулей выводятся элементы измерений A и B, но не расчетное значение A*B
Figure 2 – Shows the dimension items “A” and “B” but not the calculated value “A*B” due to the lack of FEEDERS when zero-suppression is enabled

Метод 4. Использование опции Check FEEDERS

Для использования этого метода пользователю нужно нажать правой кнопкой по вычисляемой ячейке и выбрать опцию Check Feeders. На рис. 3 показано диалоговое окно IBM Cognos TM1 Rules Tracer, которое открывается в случае выбора опции Check Feeders. Таким образом, проверка Feeders(A*B, Q1-Q10) показывает, что значения для Jan-10, Feb-10 и Mar-10 не доставляются (not fed). В этом примере консолидация этих трех элементов будет показана некорректно, поскольку они не снабжаются корректно.

Рисунок 3. Результаты выбора опции Check Feeders для консолидированного элемента Q1-10, для которого отсутствуют фидеры
Figure 3 - Shows the results of selecting “Check Feeders…” for the consolidated item Q1-10 that is missing FEEDERS

В следующем представлении демонстрируется диалоговое окно IBM Cognos TM1 Rules Tracer для Feeders(A*B, Jan-10). В данном случае фидер отсутствует, поскольку значение для Feeders (A*B, Jan-10) показано как not fed (не снабжаемое).

Рисунок 4. Результаты выбора опции Check Feeders для детализированного элемента Jan 10, снабжение которого не осуществляется
Figure 4 - Shows the results of selecting “Check Feeders…” for a detailed item Jan-10 that is not being fed

На следующем рисунке показано представление куба IBM Cognos TM1 в инструменте IBM Cognos TM1 Cube Viewer после вставки в правило следующего фидера.

['A']=>['A*B'];

Обратите внимание, что вычисления уровня C: для A*B” теперь осуществляются точно.

Рисунок 5. Результаты A*B” после задания фидеров
Figure 5 Shows the results of “A*B” with FEEDERS defined

На следующем рисунке показано, что после вызова функции Check Feeders в диалоговом окне IBM Cognos TM1 Rules Tracer не показано никаких неснабжаемых ячеек для Feeders(A*B, Q1-10). На этом рисунке также показан результат консолидированного вычисления 6000000 для ячейки уровня C: (A*B, Q1-10).

Рисунок 6. Представление Rules Tracer с результатами функции Check Feeders без неснабжаемых ячеек и с корректным консолидированным значением
Figure 6 – Rules Tracer showing results of “Check Feeders…” with no unfed cells and with a correct consolidated value

Для более подробного рассмотрения предыдущего примера со снабжением вычисления вспомним одно из пяти важных соображений относительно фидеров: Вычисляемые ячейки уровня C:снабжаются автоматически, если их дочерние элементы уже снабжаются.. Следующий простой пример иллюстрирует этот тезис. На рис. 7 показано два элемента (C и D) и результат C*D, получаемый посредством правила. Обратите внимание, что C и D в иерархии обобщаются в виде C*D. Правила для вычисления C*D выглядят следующим образом.

['C*D'] = c:if(ELLEV('Time', !Time) >= 1,Consolidatechildren('Time'),CONTINUE);
['C*D'] = c:['C']*['D'];
Рисунок 7. Корректное вычисление результатов для C*D без использования фидеров
Figure 7 – Shows correctly calculated results for “C*D” without the use of FEEDERS

В диалоговом окне IBM Cognos TM1 Rules Tracer на рисунке 8 нет никаких фидеров, которые бы использовались для вычисления (C*D, Q1-10). В этом примере нет никакой необходимости задавать фидеры для C*D, поскольку оба элемента (C и D) в иерархии обобщаются в виде C*D. В результате снабжение C*D производится автоматически. Ключевой момент в этом примере состоит в следующем. В некоторых ситуациях пользователь может упростить разработку посредством задействования естественной иерархии в пределах измерения с целью вычисления значений уровня C: без необходимости применения фидера.

Рисунок 8. Неснабжаемые элементы для C*D отсутствуют, поскольку это элемент уровня C:, который снабжается автоматически из своих дочерних элементов уровня N:.
Figure 8 – Shows no unfed items for “C*D” as it is a C: level item and is automatically fed from its N: level children

И, наконец, пользователям следует соблюдать осторожность при использовании функции Check FEEDERS. Эта функция исследует все дочерние элементы вычисляемой ячейки уровня C: с целью определения того, снабжается ли она или нет. Использование этой функции для высокоуровневого обобщения может потребовать много времени для получения результатов. Это вызвано тем, что для определения того, снабжается ли ячейка или нет, система должна оценить все дочерние элементы всех измерений.

Метод 5. Использование куба OverFeeds

Этот метод призван определить, происходит ли избыточное снабжение куба IBM Cognos TM1. Избыточное снабжение способно снизить общую производительность при обработке запросов к кубу IBM Cognos TM1.

Рассмотрим пример для куба IBM Cognos TM1 с именем OverFeedSource, в котором пользователь желает выяснить, подвергается ли избыточному снабжению какая-либо из ячеек в этом кубе. В этом примере в кубе используется следующее правило.

SKIPCHECK; 
['A*B']= n:['A']*['B'];
FEEDERS; 
['A']=>['A*B'];

Представление куба OverFeedSource на рис. 9 демонстрирует два элемента (A и B) и результат A*B, получаемый посредством правила.

Рисунок 9. Результаты A*B при использовании A в качестве как источника снабжения
Figure 9 – Showing the results of “A*B” using “A” as the FEED source

Для проверки на наличие избыточного снабжения применяется следующая процедура.

  1. Создайте новый куб с именем Overfeeds с такими же измерениями, как у куба OverFeedSource.
  2. Добавьте к кубу Overfeeds следующее правило.
    SKIPCHECK; 
    [ ] = n: IF(DB('OverFeedSource', !Time, !Product, !OverFeeds) = 0,1,0); FEEDERS;
  3. Добавьте к кубу OverFeedSource следующий фидер.
    []=>DB('Overfeeds', !Time, !Product, !OverFeeds);
  4. Откройте куб OverFeeds в инструменте IBM Cognos TM1 Cube Viewer. Представление демонстрирует два элемента (A и B) и результат A*B, получаемый посредством правила. Куб OverFeeds будет содержать значение 1 в каждой детализированной ячейке, которая имела значение 0 в исходном кубе, и значение 1 в каждой консолидированной ячейке, которая подвергается избыточному снабжению.
Рисунок 10. Значение 1 в каждой детализированной ячейке, которая имела значение 0 в исходном кубе, и значение 1 в каждой консолидированной ячейке, которая подвергается избыточному снабжению
Figure 10 – Shows a value of “1” in every detailed cell that had a “0” in the source cube and a value of “1” in every consolidated cell that is being over-fed

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

Таблица 1. Анализ реагирования куба IBM Cognos TM1 на использование фидеров
Куб OverFeedSourceКуб OverFeeds
ЗначениеСнабжается?Значение на уровне листаЗначение на уровне C
0Нет10
0Да11 (чрезмерное снабжение)

Любое ненулевое значение в сводных уровнях для вычисляемых полей указывает на избыточное снабжение.

На рис. 11 показан куб Overfeeds, у которого элемент A*B для элемента P3 подвергается избыточному снабжению, поскольку он обобщается до элемента Q1-10 даже при нулевом значении в исходном кубе. Пересечение P3 и Jan 10 имеет значение 1. Это говорит о том, что данная ячейка подвергается избыточному снабжению.

Рисунок 11. Избыточное снабжение P3 для Jan 10
Figure 11 – Shows the over-feeding of P3 for Jan-10

Избыточное снабжение объясняется созданием следующего фидера.

['A']=>['A*B'];

С помощью значения A система определяет, следует ли осуществлять снабжение A*B. При этом значение B игнорируется. В результате система осуществляет снабжение A*B в том случае, когда A<>0 AND B=0, результатом чего является нулевое значение A*B.

Как будет показано позднее в другом примере, обычный способ снабжения куба IBM Cognos TM1 состоит в использовании умножающих коэффициентов. Это приведет к избыточному снабжению, но, как правило, не до такой степени, что существенно снизить производительность. Если не использовать т.н. условные фидеры (Conditional Feeder), избыточное снабжение невозможно полностью устранить из куба, в котором имеют место такие операции, как умножение, деление, возведение в степень и др., однако его можно смягчить посредством снабжения переменной, которая с наибольшей вероятностью будет иметь нулевое значение.

Нормальное решение для проблемы избыточного снабжения состоит в использовании условных фидеров. Условные фидеры задают условия для фидеров. Этот пример может использоваться для иллюстрации еще одного принципа из области фидеров. При изменении значение A на нулевое значение представление по-прежнему будет показывать, что ячейка A подвергается избыточному снабжению в кубе Overfeeds. Это вызвано тем, что если ячейка снабжается, то она всегда снабжается до тех пор, пока сервер TM1 не будет перезапущен, или пока не будет выполнена функция CubeProcessFeeders() инструмента TM1 TurboIntegrator.

Метод 6. Использование инструмента Performance Monitor

Этот метод не показывает конкретно, какие фидеры подвергаются избыточному снабжению, однако он указывает, с чего следует начинать при решении данной проблемы. Нередко разработчики TM1 получают готовую или частично готовую модель, которая работает медленно и потребляет очень много памяти.

Запустите функцию Performance Monitor инструмента TM1 Architect, для чего нажмите правой кнопкой на имени сервера TM1 и в появившемся меню выберите опцию Start Performance Monitor (см. рис. 12). Убедитесь в том, что в меню View активирована опция Display Control Objects.

Рисунок 12. Контекстное меню, отображаемое после нажатия правой кнопкой на экземпляре сервера TM1
Figure 12 – The context menu displayed after right-clicking on a TM1 Server instance

Убедитесь в том, что в меню View активирована опция Display Control Objects.

В инструменте IBM Cognos TM1 Cube Viewer откройте системный куб }StatsByCube и обратите внимание на содержащуюся в нем информацию о фидерах (см. рис. 13). Строка Feeders показывает количество снабжаемых ячеек и объем памяти, используемой фидерами — в столбцах под названиями Number of Fed Cells и Memory Used for Feeders, соответственно. Отыщите кубы с особенно большими значениями в этих столбцах. Используйте куб OverFeeds, как описано ранее в Методе 5, чтобы определить, подвергаются какие-либо вычисления избыточному снабжению.

Рисунок 13. Информация о фидере из служебного куба }StatsByCube
Figure 13 – FEEDER information from the TM1 Control Object }StatsByCube

Метод 7. Исследование журнала TM1Server.log

Как и предыдущий метод, данный метод не показывает конкретно, какие фидеры неэффективны, однако он указывает, с чего следует начинать при решении данной проблемы. В файле tm1server.log система регистрирует загрузку каждого куба, включая оценку фидеров для каждого куба. По умолчанию файл tm1server.log находится в каталоге TM1 Data Directory для конкретного экземпляра сервера TM1, с которым вы работаете. Расположение каталогов типа TM1 Data Directory задается пользователем. При использовании эталонного сервера TM1 с именем PlanSamp, включенного в стандартный пакет установки IBM Cognos TM1, файл tm1server.log по умолчанию находится в следующем месте:
C:\Program Files\IBM\cognos\tm1\samples\tm1\PlanSamp\tm1server.log.

В следующем примере показаны некоторые строк из файла tm1server.log для куба с именем BW COST CALCULATION.

3536 INFO 2012-05-16 23:41:22.580  TM1.Cube  Loading cube BW COST CALCULATION 
3536 INFO 2012-05-16 23:41:22.611 TM1.Server TM1CubeImpl::ProcessFEEDERS: Computing
 FEEDERS for base cube 'BW COST CALCULATION'. 
3536 INFO 2012-05-16 23:41:22.611 TM1.Server TM1CubeImpl::ProcessFEEDERS: Done computing
 FEEDERS for base cube 'BW COST CALCULATION'. 
3536 INFO 2012-05-16 23:41:22.611 TM1.Cube Done loading cube BW COST CALCULATION

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


Задание фидеров

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

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

  1. Умножение
  2. Деление
  3. Сложение
  4. Вычитание
  5. Вычисления на основе условий
  6. Cube-to-cube

Если определенное вычисление представляет собой комбинацию вышеупомянутых типов вычислений, то для каждого компонента вычисления потребуется комбинация соответствующих стратегий в области фидеров. Как и в случае правил, существует два способа для задания фидеров: 1) заключение имени элемента в квадратные скобки; 2) использование функции DB(). В следующих подразделах приведены примеры для обоих способов.

Умножение

['A*B'] = n: ['A']*['B'];
['A']=>['A*B'] ;

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

Для дальнейшей оптимизации фидера следует выбрать элемент, который с наибольшей вероятностью будет иметь нулевое значение. С целью разъяснения этой концепции мы будем использовать типичное вычисление Revenue.

[‘Revenue’] = [‘units’]*[‘price’];

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

Кроме того, задать фидер можно с использованием формата DB.

['A']=> DB('FEEDERS', 'A*B', !Time);

Обычно в использовании формата DB нет необходимости, за исключением следующих случаев.

  1. Задание правил типа cube-to-cube
  2. Задание условного фидера
  3. Манипулирование фидерами таким образом, чтобы FEEDER-элементы соответствовали целевым элементам.

Метод с использованием DB предоставляет разработчику более гибкие возможности, поскольку позволяет встраивать условные операторы и функции правил IBM Cognos TM1. Более подробные сведения и примеры приведены в следующих разделах.

Деление

['A/B']=n:['A']/['B'];
['A']=>['A/B'];

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

Сложение

['A+B']=n:['A']+['B'];
['A']=>['A+B'];
['B']=>['A+B'];

В данном случае мы должны снабжать оба элемента, поскольку нулевое значение элемента A не обязательно приведет к нулевому результату вычисления.

Вычитание

['A-B']=n:['A']-['B'];
['A']=>['A-B'] ;
['B']=>['A-B'] ;

Как и в случае со сложением, мы должны снабжать оба элемента, поскольку нулевое значение элемента A не обязательно приведет к нулевому результату вычисления.

Правила на основе условий

В качестве иллюстрации мы выбрали пример, который обычно используется в приложениях бюджетирования или прогнозирования. В следующем примере (рис. 14) мы выполняем вычисление только для тех месяцев, которые отмечены как прогнозируемые (т.е. начиная с May-10; прогнозируемые месяцы имеют серый фон).

Рисунок 14. Результаты использования условного фидера для прогнозируемых месяцев, начиная с May-10
Figure 14 – Shows the results of using a Conditional FEEDER for the forecast months starting with May-10

Для тех месяцев, которые отмечены как Actual (реально существующие; в данном случае это месяцы с Jan 10 по Apr-10), мы хотим только загружать или вводить результат вычисления. Обратите внимание, что у реально существующих прогнозируемых месяцев (строка E*F (For Forecast Months) и месяцы с Jan 10 по Apr-10) ячейки имеют белый фон. Это означает, что данные ячейки способны принимать вводимые вручную значения и не являются результатом вычисления. Причина этого состоит в том, что реально существующие значения являются статичными, и мы не хотим, чтобы система вычисляла их способом, отличающимся от их способа их хранения в системе записей.

В этом примере мы используем атрибут в измерении time для обозначения реально существующих или прогнозируемых месяцев. На рис. 15 показано представление Attributes Editor, в которое добавлен новый атрибут с именем Actual Flag, а несколько конкретных месяцев (с Jan 10 по Apr-10) обозначены символом A, чтобы показать, какие месяцы содержат реально существующие данные.

Рисунок 15. Атрибут Actual Flag (Text) измерения time с символом A у месяцев, содержащих реально существующие данные
Figure 15 – The time dimension attribute named “Actual Flag (Text)” with “A” in the months denoted as actual data

Правило задано следующим образом.

['E*F (For Forecast Months)'] = n: IF( ATTRS('Time', !Time, 'Actual Flag')
 @<>'A',['E']*['F'],STET);

FEEDER выглядит следующим образом.

['E']=> ['E*F (For Forecast Months)'];

Правила типа Cube-to-Cube

Следующий простой пример показывает, что правило типа cube-to-cube имеет более высокий уровень сложности и создает больше проблем. Рассмотрим исходный и целевой кубы, заданные для исходного куба FeederSource. Куб FeederSource имеет два измерения — FeederSource (с единственным элементом с именем Source) и Value (с единственным элементом с именем Value) — и единственное значение данных, равное 10 (см. рис. 16)..

Рисунок 16. Пример фидера для исходного куба с именем FeederSource
Figure 16 – Shows the example FEEDER source cube named “FeederSource”

На рис. 17 показано представление куба FeederTarget продукта IBM Cognos TM1, значения которого поступают от исходного куба с именем FeederSource. Куб FeederTarget имеет два измерения — FeederTarget (с единственным элементом Target) и Time (с элементами уровня N: для каждого месяца и с элементами уровня C: для поквартальной консолидации Q1-10, Q2-10 и т.д.), а все элементы уровня N: были заполнены значением из куба FeederSource, которое равно 10.

Рисунок 17. Представление целевого куба IBM Cognos TM1 со значениями, загруженными с помощью фидера
Figure 17 – A view of an IBM Cognos TM1 target cube including values loaded using a FEEDER

Причина повышенной сложности фидеров типа cube-to-cube состоит в том, что правило задается в целевом кубе, а фидер — в исходном кубе. Вследствие этого исходный куб отправляет фидеры в целевой куб, а правило в целевом кубе получает их. Ситуация усложняется тем фактом, что структуры измерений в исходном и целевом кубах могут различаться. В следующем примере мы рассмотрим весь процесса.

Шаг 1. Задайте правило в целевом кубе

['Target'] = n: DB('FeederSource', 'Value', 'Source');

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

В силу важности этого момента мы иллюстрируем его на подпримере.

Предположим, у нас есть два куба, Cube S и Cube T. Оба эти куба имеют идентичные структуры с идентичными измерениями, однако измерения в каждом кубе являются копией измерений в другом кубе. Например, куб Cube S имеет измерения Product S и Time S. Куб Cube T имеет измерения Product T и Time T. Эти два измерения Product идентичны, два измерения Time также идентичны. Таким образом, правило будет иметь следующий вид.

[‘Target’] = n: DB (‘Cube S’, ‘Source’, !Product T, !Time T);

Примечание. Измерения целевого куба заменяют параметры функции DB, которые представляют структуры исходного куба. Это весьма важный момент — разработчики TM1 провели много часов в попытках выяснить, почему правило не осуществляет сохранение!

Шаг 2. Задайте фидер в исходном кубе

['Source'] => DB('FEEDERTarget', '2010', 'Target');

‘2010’ — в данном случае необходимо жестко закодировать значение, поскольку в исходном кубе нет измерения Time. Жесткое кодирование обобщающего элемента в измерении Time заставляет систему снабдить все элементы уровня N: значением 2010. Примечание. Если бы исходный куб содержал измерение Time, то фидер был бы создан в следующем виде.

['Source'] => DB('FEEDERTarget', !Time, 'Target');

'Target' — В данном случае необходимо жестко закодировать показатель, поскольку в исходном кубе и в целевом кубе имеются различные имена показателя элемента. Необходимо жестко закодировать имя в элементе измерения целевого куба. Фидер для нашего подпримера имеет следующий вид.

[‘Source’]=> DB (‘Cube T’, ‘Target’, !Product S, !Time S);

В данном случае фидер задан "реверсивно" правилу. Примечание. Измерения исходного куба заменяют параметры функции DB, представляющие структуры целевого куба. Это может породить определенные проблемы, поэтому мы скомпоновали следующий список, обобщающий практические рекомендации по разработке фидеров типа cube-to-cube.

  1. Если одно и то же измерение находится и в целевом кубе, и в исходном кубе, используйте в этом параметре значение “!DimensionName”.
  2. Если у вас есть различные измерения, которые являются копиями друг друга, то для этого параметра необходимо использовать значение “!DimensionNameInSource”.
  3. Если в вашем целевом кубе имеется измерение, которое не существует в исходном кубе, то вам придется жестко закодировать сводный элемент в целевом измерении. В приведенном выше примере мы жестко закодировали значение ‘2010’. В результате система автоматически снабдит все дочерние элементы значением ‘2010’. Эту функцию следует использовать с осторожностью, поскольку она способна породить ситуации с чрезмерным снабжением и с длительным запуском сервера.
  4. Если в вашем исходном кубе имеется измерение, которое не существует в целевом кубе, то вам придется жестко закодировать элемент в исходном измерении.
  5. Если вы хотите сделать целевым определенный элемент, жестко закодируйте его в соответствующем параметре. Например, элемент Revenue будет целевым только для показателя revenue. Потребность в выполнении вышеописанных процедур можно минимизировать, используя одинаковые имена показателя в исходном кубе и в целевом кубе. Это позволит использовать только значение “!TargetMeasureDimName”.
  6. Фидеры, которые вы отправляете из исходного куба, должны соответствовать элементам в целевом кубе. Это требование применяется ко всем измерениям. Для иллюстрации этого положения рассмотрим следующий пример. При снабжении помесячного куба, которое предполагалось осуществлять посредством еженедельного куба, в помесячном кубе не существовало недель, поэтому реального снабжения не происходило. Эта проблему можно обойти посредством изменения фидера таким образом, чтобы родители недели передавались в фидер. Поскольку родителями недель являются месяцы, а месяцы присутствуют в целевом кубе, то фидеры будут работать ожидаемым образом.

Как избежать фидеров типа cube-to-cube

В некоторых ситуациях можно избежать задания фидеров типа cube-to-cube, если целевой показатель используется в последующем вычислении. На рис. 18 Target — это результат вычисления типа cube-to-cube, который также используется в дальнейшем в вычислении Target*C”. Значение для C и для Jan 10 равно 20. Вычисленное значение Target*C для Jan 10 равно 200 (Target имеет значение 10, а C имеет значение 20). Куб IBM Cognos TM1 загружает значения согласно следующей формуле фидера.

['Target * C'] = n: DB('FeederSource', 'Value', 'Source') * ['C'];

Потребность в фидере типа cube-to-cube можно устранить достаточно просто — осуществляя снабжение элемента C следующим образом.

['C'] => ['Target * C'];
Рисунок 18. Целевой куб, избегающий необходимости определения фидера для исходного куба значения исходного куба используются в вычислении, а затем целевой куб снабжается этим вычислением
Figure 18 – Shows target cube circumventing the need for a source cube FEEDER definition by simply using the source cube values in a calculation and feeding that calculation within the target cube

Условные фидеры

Условные фидеры (Conditional FEEDER) можно использовать для уменьшения или для полного устранения избыточного снабжения. Обычно условные фидеры используются для дополнения условного правила. Для иллюстрации этого тезиса рассмотрим пример с чрезмерным снабжением, который уже использовался выше.

['A']=>['A+B' ];

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

['A']=>DB(IF(['B']=0,'','OverFeedSource'), !Time, !Product, 'A*B');
['B']=>DB(IF(['A']=0,'','OverFeedSource'), !Time, !Product, 'A*B');

Примечание. Для условного фидера необходимо использовать функцию DB. В этом случае мы помещаем оператор IF в параметр функции DB, которая представляет имя куба. Мы будем возвращать имя куба для ячеек, которые мы ходим снабжать, и значение ‘’ (null) для остальных ячеек.

Посмотрев на куб, мы увидим, что теперь мы не осуществляем чрезмерного снабжения этого вычисления. Представление куба Overfeeds на рис. 19 демонстрирует результаты Jan 10 и Q1-10 со скорректированным избыточным снабжением (это подтверждается тем обстоятельством, что ни одно из значений для Q1-10 не равно 2.

Рисунок 19. В консолидационном поле Q1-10 отсутствуют значения, равные 2; т.е. отсутствует избыточное снабжение куба IBM Cognos TM1
Figure 19 – Shows no values equal 2 in the Q1-10 consolidation field, which means there is no overfeeding of the IBM Cognos TM1 cube

Как часто срабатывают фидеры

Согласно изложенным выше пяти важным соображениям относительно фидеров, фидеры из числовых ячеек срабатывают лишь один раз, а фидеры из строковых ячеек срабатывают при каждом изменении их значения. Это важно в тех случаях, когда для задания размещения вычисленного результата используется параметр. С целью иллюстрации этого тезиса на рис. 20 показан куб IBM Cognos TM1 с выделенным вычисленным значением 100 на пересечении строки Result и столбца Feb-10.

Рисунок 20. Куб IBM Cognos TM1 с выделенным значением 100 на пересечении строки Result и столбца Feb-10
Figure 20 – An IBM Cognos TM1 cube highlighting the value 100 at the intersection of “Result” and “Feb-10”

Правило задано следующим образом.

['Result'] = IF(DB('FEEDERS', 'Jan-10', 'Month') @= DIMNM('Time', DIMIX('Time', !Time)),
 DB('FEEDERS', 'Jan-10', 'Value'),STET);

Фидер выглядит следующим образом.

['Value','Jan-10']=> DB('FEEDERS', DB('FEEDERS', 'Jan-10', 'Month'), 'Result');

Несложно увидеть, что мы используем Value для снабжения Result в правиле, в котором параметр Month используется для внесения корректного значения месяца в измерение Time.

Если мы изменим параметр Month посредством изменения значения поля на пересечении Month/Jan 10 со значения Feb-10 на значение Mar-10, то ячейка больше не будет снабжаться. Это проиллюстрировано на рис. 21, где Q1-10 имеет нулевое значение вместо значения 100. Это вызвано тем, что фидеры для числовых ячеек срабатывают только один раз. Ячейка Result для Feb-10 была снабжена изначально, поэтому Feb-10 — это единственная ячейка, для которой возможно снабжение. Решение состоит в том, чтобы изменить фидер следующим образом.

['Month','Jan-10']=> DB('FEEDERS', DB('FEEDERS', 'Jan-10', 'Month'), 'Result');
Рисунок 21. Снабжение куба числовым значением способно привести к изменениям, которые не будут отражены надлежащим образом
Figure 21 – Shows that feeding the cube with a numeric value can result in changes not being properly reflected

Примечание. В данном случае для снабжения вычисления мы используем Month вместо Value. Поскольку Month является строкой, фидер будет срабатывать при каждом изменении. Следующее представление куба IBM Cognos TM1 демонстрирует для Q1-10, корректный результат, равный 100.

Рисунок 22. Снабжение куба посредством строкового значения обеспечивает корректное отображения обновленных результатов после изменения поля данных
Figure 22 – Shows that feeding the cube with a string value will display updated results as soon as a data field is changed

Персистентные фидеры

Персистентные фидеры (Persistent FEEDER) были введены в продукте IBM Cognos TM1 версии 9.5.1. По умолчанию этот параметр выключен, однако его можно включить с помощью параметра PersistingOfFEEDERS в файле TM1s.cfg. Чтобы активировать персистентные фидеры и сократить время перезагрузки кубов с фидерами при запуске сервера TM1, присвойте параметру PersistingOfFEEDERS значение T (истина) для сохранения вычисленных фидеров в соответствующем файле

PersistingOfFEEDERS=T

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

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

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

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

DeleteAllPersistentFEEDERS()

При запуске сервера TM1 эта функция принудительно инициирует оценку фидера вместо его чтения из кэша персистентных фидеров.


Примеры сложных фидеров

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

Куб Line Items Detail-to-Summary

Распространенная проблема моделирования, особенно у приложений бюджетирования и планирования, состоит в связывании куба Line Items Detail с кубом Summary, в котором измерения представляют собой т.н. отборочные списки (специальный список таких элементов, как товары) в исходном кубе и реальные измерения в целевом кубе. Рассмотрим следующий входной куб с именем LineItemSource, который включает элементы Line Item, Description, Time, Product и Amount (см. рис. 23).

Рисунок 23. Входной куб LineItemSource
Figure 23 – Shows the input cube “LineItemSource”

На рис. 24 показано представление сводного куба LineItemTarget, консолидирующего значения, при которых отборочные списки становятся измерениями (т.е. теперь Time — это столбцы, а Product — это строки). Этот куб демонстрирует элементы LineItem, а так же значения Summary на уровне Total Product и на уровне Time Quarterly.

Рисунок 24. Представление куба LineItemTarget, измерения которого созданы из отборочных списков в кубе LineItemSource
Figure 24 – The “LineItemTarget” cube view with dimensions created from the pick-lists in the “LineItemSource” cube

Поскольку структуру куба этого типа невозможно смоделировать с целью прямой передачи данных из LineItemSource в LineItemTarget, необходимо задействовать промежуточный куб с именем LineItemCalc. На следующем рисунке показано представление промежуточного куба, который содержит все измерения обоих кубов — Item, Product и Time.

Рисунок 25. Промежуточный куб LineItemCalc, содержащий все измерения куба LineItemSource и куба LineItemTarget
Figure 25 – The intermediate cube “LineItemCalc” which contains all the dimensions from both “LineItemSource” and “LineItemTarget”

Почти корректные правила и фидеры имеют следующий вид.

Для LineItemSource

SKIPCHECK;
FEEDERS;
['Amount'] => DB('LineItemCalc',DB('LineItemSource', !LineItem, 'Product') , !LineItem,
 DB('LineItemSource', !LineItem, 'Time'), 'Value');

Для LineItemCalc

SKIPCHECK;
['Value' ] = n: IF(DIMNM('Product',DIMIX('Product', !Product)) @= DB('LineItemSource',
 !LineItem, 'Product') & DIMNM('Time',DIMIX('Time', !Time)) @= DB('LineItemSource',
 !LineItem, 'Time') ,DB('LineItemSource', !LineItem, 'Amount'),STET);

FEEDERS;
['Value'] => DB('LineItemTarget', !Product, !Time, !Value);

Для LineItemTarget

SKIPCHECK;
['Value'] = n: DB('LineItemCalc', !Product, 'Total', !Time, !Value);
FEEDERS;

Теперь поочередно просмотрим и объясним правила и фидеры.

Начнем с правила, которое преобразует отборочные списки в измерения куба LineItemCalc.

['Value'] = n: IF(DIMNM('Product',DIMIX('Product', !Product)) @= DB('LineItemSource',
 !LineItem, 'Product') & DIMNM('Time',DIMIX('Time', !Time)) @= DB('LineItemSource',
 !LineItem, 'Time') ,DB('LineItemSource', !LineItem, 'Amount'),STET);

Рассмотрим компоненты этого правила.

  1. Жирный шрифт. Эти компоненты проверяют, соответствует ли имя элемента измерения Product в кубе LineItemCalc товару, введенному в кубе LineItemSource”. Обратите внимание на использование @=, поскольку в обоих случаях это строки.
  2. Курсивный шрифт. Эти компоненты проверяют, соответствует ли имя элемента в измерении Time куба LineItemCalc месяцу, введенному в кубе LineItemSource. Обратите внимание на использование @=, поскольку в обоих случаях это строки.
  3. Полужирный курсивный шрифт. Эти компоненты возвращают значение Amount из куба LineItemSource в случае TRUE (ИСТИНА).
  4. Они ничего не делают в случае FALSE (ЛОЖЬ).

Теперь рассмотрим ассоциированный фидер в кубе LineItemSource.

['Amount'] => DB('LineItemCalc',DB('LineItemSource', !LineItem, 'Product') ,
 !LineItem, DB('LineItemSource', !LineItem, 'Time'), 'Value');

В начальной реализации этот фидер был задан следующим образом.

['Amount'] => DB('LineItemCalc', 'Total Product', !LineItem, '2010', 'Amount');

Напомним совет из предыдущего раздела Правила типа Cube-to-Cube. Если в целевом кубе имеется измерение, отсутствующее в исходном кубе (как Product и Time в этом примере), то можно жестко закодировать сводный элемент в соответствующий параметр, как показано полужирном шрифтом выше.

Хотя этот подход будет работать, он может оказаться неоптимальным для некоторых ситуаций, поскольку большие объемы данных могут негативно повлиять на продолжительность запуска сервера TM1. Это вызвано тем, что данный тип фидера приводит к серьезному чрезмерному снабжению, поскольку системе приходится снабжать каждый отдельный элемент Product и каждый отдельный элемент Month для каждого отдельного элемента LineItem. Рассмотрим изменение фидера, при котором снабжается только элемент Product, выбранный на любом определенном элементе LineItem. Например, заменим ‘Total Product’ на DB('LineItemSource', !LineItem, 'Product'), а ‘2010’ заменим на DB('LineItemSource', !LineItem, 'Time'). После этих изменений система будет запускаться существенно быстрее.

Еще одна проблема с фидером в кубе LineItemSource состоит в том, что он осуществляет снабжение только один раз, поэтому он не будет продолжать работу в случае изменения данных Product или Month. Решение состоит в снабжении строк, как показано в следующем примере.

['Product'] => DB('LineItemCalc',DB('LineItemSource', !LineItem, 'Product') ,
 !LineItem, DB('LineItemSource', !LineItem, 'Time'), 'Value');

['Time'] => DB('LineItemCalc',DB('LineItemSource', !LineItem, 'Product') ,
 !LineItem, DB('LineItemSource', !LineItem, 'Time'), 'Value');

В этом примере фидер повторен для каждого измерения (и для измерения Product, и для измерения Time). Это гарантирует корректное протекание информации при внесении изменений по этим измерениям. Таким образом, корректные правила и фидеры будут иметь показанный ниже вид.

Для LineItemSource

SKIPCHECK;

FEEDERS;

['Product'] => DB('LineItemCalc',DB('LineItemSource', !LineItem, 'Product') ,
 !LineItem, DB('LineItemSource', !LineItem, 'Time'), 'Value');

['Time'] => DB('LineItemCalc',DB('LineItemSource', !LineItem, 'Product') ,
 !LineItem,
DB('LineItemSource', !LineItem, 'Time'), 'Value');

Для LineItemCalc

SKIPCHECK;

['Value'] = n: IF(DIMNM('Product',DIMIX('Product', !Product)) @= DB('LineItemSource',
 !LineItem, 'Product') & DIMNM('Time',DIMIX('Time', !Time)) @= DB('LineItemSource',
 !LineItem, 'Time') ,DB('LineItemSource', !LineItem, 'Amount'),STET);

FEEDERS;
['Value'] => DB('LineItemTarget', !Product, !Time, !Value); LineItemTarget

SKIPCHECK;
['Value'] = n: DB('LineItemCalc', !Product, 'Total', !Time, !Value);
FEEDERS;

Комментарии

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=935000
ArticleTitle=Проверенные приемы IBM Cognos : Эффективное использование фидеров IBM Cognos TM1
publish-date=06212013