FEEDERS de IBM Cognos TM1

Producto(s): IBM Cognos TM1; Área de Interés: Gestión Financiera

Uno de los conceptos más avanzados en el desarrollo de cubos de IBM Cognos TM1 es la implementación apropiada de FEEDERS dentro de normas de TM1. Este documento describe los FEEDERS y cómo usarlos efectivamente para un rendimiento mejorado al compilar cubos de IBM Cognos TM1.

Guy Jones, Gerente técnico de cliente, IBM

Guy Jones es un Gerente Técnico de Cliente para las soluciones de Cognos Performance Management. Ha utilizado TM1 durante 5 años y se ha involucrado extensamente en el desarrollo de sistemas complejos de prueba de concepto para clientes.



John Leahy, Consejero de prácticas comprobadas, IBM

John Leahy es un Consejero de Prácticas Comprobadas para IBM Business Analytics especializado en soluciones de Gestión de Rendimiento Financiero y es un Desarrollador Certificado de IBM Cognos TM1.



03-12-2012

Introducción

Propósito

Uno de los conceptos más avanzados en el desarrollo de cubos de IBM Cognos TM1 es la implementación apropiada de FEEDERS dentro de normas de TM1. Este documento describe los FEEDERS y cómo usarlos efectivamente para un rendimiento mejorado al compilar cubos de IBM Cognos TM1.

Requisito previo

Este documento cubre un concepto avanzado de IBM Cognos TM1 y utiliza terminología específica de TM1. El lector debe tener una comprensión de los cubos, dimensiones, normas y terminología de IBM Cognos TM1 antes de continuar.

Aplicabilidad

De IBM Cognos TM1 9.5.1 a IBM Cognos TM1 10.1

Exclusiones y Excepciones

No se han identificado exclusiones o excepciones.


Definición

¿Qué son los FEEDERS?

Los FEEDERS son utilizados por el motor de cálculos de IBM Cognos TM1 para manejar eficientemente la escasez en un cubo con cálculos basados en normas. Los FEEDERS identifican los campos en un cubo que son utilizados en un cálculo basado en normas y los distingue como excepciones para el algoritmo de compresión de datos escasos.

¿Por qué usar FEEDERS?

Los cubos de OLAP pueden estar escasamente llenados debido a los distintos niveles de granularidad en los datos disponibles o simplemente por la naturaleza del cubo. Por ejemplo, en un cubo de Lista de Materiales que incluye muchos productos, muchas partes distintas y muchos proveedores distintos habrá significativamente más células vacías que células llenas, ya que cada producto final no requiere cada parte distinta de cada proveedor distinto. En nuestra experiencia, la relación de células no llenadas con células llenas en escasez grande de cubos de OLAP frecuentemente puede ser mayor que 100.000.000:1.

Utilizar algoritmos densos de matriz estándar para cálculos en un cubo escaso puede consumir grandes cantidades de recursos informáticos y requerir una importante cantidad de tiempo para completarse. Para mejorar el rendimiento del cálculo en cubos escasos, IBM Cognos TM1 utiliza de forma predeterminada un algoritmo de compresión de datos escasos. Esto permite a IBM Cognos TM1 realizar agregaciones dimensionales o consolidaciones muy rápida y eficientemente. Tenga en mente que estas agregaciones dimensionales o consolidaciones son calculadas con base en el diseño jerárquico de las dimensiones en el cubo. Son distintas a los cálculos basados en normas que se usan para calcular diversos campos dentro o a través de dimensiones y cubos. Un ejemplo de una agregación dimensional o consolidación sería una dimensión que contenga los elementos Producto A, Producto B, Producto C y Productos Totales. Con base en el diseño jerárquico de la dimensión, cualquier célula con valores para Producto A, Producto B y Producto C agregarían a Productos Totales. Un ejemplo de un cálculo basado en normas sería: Precio * Volumen = Ingresos. En IBM Cognos TM1, las normas son definidas fuera de la dimensión en TM1 Rules Editor y son después aumentadas a un cubo de TM1.

Sin embargo, una vez que IBM Cognos TM1 detecta que una norma ha sido añadida a un cubo, el algoritmo de compresión de datos escasos automáticamente será inhabilitado por TM1. Esto es para garantizar que la norma calculará en forma correcta, ya que si el algoritmo de compresión de datos escasos fuera dejado en ellas, el campo calculado (la variable dependiente) y una parte o todos los campos de origen (las variables independientes) serían comprimidos y no estarían disponibles para que el cálculo funcionara adecuadamente. Si la norma es después implementada, el rendimiento del cubo de TM1 disminuirá significativamente, ya que no aprovecha el algoritmo de compresión de datos escasos.

Las dos opciones anteriores son 1) diseñar un cubo que sólo tenga agregaciones dimensionales o consolidaciones y después aprovechar al máximo el algoritmo de compresión de datos escasos para un rendimiento excelente; o 2) diseñar un cubo que utilice normas de TM1 para cálculos complejos pero que sufra un rendimiento pobre.

Afortunadamente, existe una tercera opción al diseñar cubos de IBM Cognos TM1. Esa opción es diseñar un cubo que utilice normas de TM1 para cálculos complejos pero que tenga el algoritmo de compresión de datos escasos habilitado en el cubo con una excepción para los campos que estén involucrados en cualquier cálculo basado en normas. Esta tercera opción es donde SKIPCHECK y FEEDERS entran en juego en las normas de TM1.

¿Qué es SKIPCHECK?

SKIPCHECK es utilizado en normas de TM1 para restaurar el algoritmo de compresión de datos escasos de TM1, el cual es inhabilitado de forma predeterminada cuando una norma de TM1 es creada para un cubo de TM1. Esencialmente altera temporalmente el comportamiento predeterminado de TM1 para cubos con normas.

¿Cuál es la configuración predeterminada?

De forma predeterminada, IBM Cognos TM1 no inserta automáticamente SKIPCHECK o FEEDERS en normas de TM1. Estos parámetros deben ser grabados en la norma por el Desarrollador de TM1. Si SKIPCHECK y FEEDERS no son grabados en una norma de TM1, entonces todas las células en el cubo serán evaluadas por el motor de cálculos de TM1 y algoritmos de supresión de ceros. Una norma de TM1 sin SKIPCHECK o FEEDERS realizará todos los cálculos correctamente pero el rendimiento será más lento que si esos parámetros han sido incluidos. El Desarrollador de IBM Cognos TM1 puede elegir opcionalmente si SKIPCHECK y FEEDERS son utilizados cubo por cubo.

¿Cómo funcionan los FEEDERS?

Los FEEDERS identifican los campos en un cubo que son utilizados en un cálculo basado en normas y los distingue como excepciones para el algoritmo de compresión de datos escasos.Esto permite que el algoritmo de compresión de datos escasos continúe funcionando en un cubo que tenga una norma asociada a él. El distintivo de FEEDERS identifica esos campos que utilizarán el algoritmo estándar de estructuras de datos densos, de forma que todas las células dentro del área de FEEDERS será evaluada durante los cálculos. Generalmente, mientras más FEEDERS tenga una norma, el rendimiento será más lento.

Los FEEDERS también pueden ser utilizados para supresión de ceros. Los algoritmos de supresión de ceros también utilizan FEEDERS para excluir cero elementos de la visa. Tome en cuenta que el sistema utiliza el FEEDER para determinar si la célula es incluida en la vista, y no si la célula es realmente de cero o no. Las células serán correctamente calculadas y visualizadas en una vista sin supresión, pero cuando la supresión de ceros está habilitada desaparecen. Esto es debido a que las células no son alimentadas.

Los FEEDERS son definidos por el Desarrollador de IBM Cognos TM1 en TM1 Rules Editor. En casi todos los casos, el Desarrollador define un FEEDER para cada norma. Cuando el usuario elige iniciar el servidor de TM1 o cuando el usuario salva la norma, el sistema evaluará las sentencias de FEEDER en las normas y marcará las células calculadas en el cubo para resaltar las células que no son de cero.

Una de las trampas más comunes en las que caen los Desarrolladores de IBM Cognos TM1 al implementar los FEEDERS es definir los FEEDERS en una forma ineficiente. Las dos situaciones más comunes que pueden impactar el rendimiento y la integridad son:

  • Implementaciones que resultan en la aplicación IBM Cognos TM1 siendo “sobre-alimentada”
  • Implementaciones que resultan en la aplicación IBM Cognos TM1 siendo “insuficientemente alimentada”

La consecuencia negativa de alimentar insuficientemente una aplicación es que las células que no son de cero pueden ser excluidas de los cálculos, rollups y supresión de ceros y por lo tanto pueden resultar valores calculados incorrectamente. La consecuencia de la sobre-alimentación es que más células serán alimentadas de las que se requiere, por lo que los cálculos serán más lentos y frecuentemente se necesitará más tiempo para evaluar los FEEDERS, en particular en el inicio del servidor de TM1 y al momento de salvar las normas. Además, los FEEDERS requerirán memoria adicional. Por lo tanto es mejor sobre-alimentar que alimentar insuficientemente, ya que la sobre-alimentación sólo resultará en un rendimiento más lento pero la alimentación insuficiente puede resultar en valores incorrectos. Sin embargo, existen técnicas que pueden ser empleadas para minimizar la sobre-alimentación.

Para resumir, la sobre-alimentación proporcionará los resultados esperados (integridad del cálculo, etc.), pero la aplicación operará en una forma menos eficiente, requiriendo más recursos informáticos y/o momentos más largos para completarse. Este punto es resaltado por el hecho de que el motor de cálculos de IBM Cognos TM1 realmente realizará 2 pases cuando se trata de supresión de ceros. Primero el motor evaluará las normas y los rollups dimensionales y producirá una vista. En el primer pase, usará FEEDERS para decidir si incluir o excluir la célula. Si tiene la supresión de ceros activada, el sistema realizará un segundo pase en la vista producida en el primer pase - eliminará cero filas y columnas con base en si la célula en la vista es realmente cero o no.


Cinco Consideraciones Importantes Específicas Para FEEDERS

Las cinco consideraciones más importantes específicas para FEEDERS al compilar una aplicación de TM1 son:

  1. Los FEEDERS sólo se aplican a células calculadas con normas o a un rollup de las mismas.
  2. Las células calculadas de nivel N: siempre necesitarán un FEEDER o integridad de cálculo y supresión de ceros. Tome en cuenta que en una dimensión jerárquica, los elementos de nivel N: son elementos de nivel final o de nivel hijo. Los elementos de nivel C: son elementos consolidados o de nivel padre que agregan elementos de nivel N:. Por ejemplo, si tiene los elementos Enero, Febrero, Marzo y Primer Trimestre definidos en una dimensión, entonces los elementos de nivel N: son los tres meses y el elemento de nivel C: es el total de Primer Trimestre.
  3. Las células de nivel C: son automáticamente alimentadas si su nivel N: hijo tiene FEEDERS definidos. El sistema buscará los FEEDERS del hijo de una célula de resumen para determinar si la célula de resumen es alimentada o no. Este principio aplica a rollups dimensionales de células calculadas de nivel N: o células calculadas de nivel C:. Para ilustrar este punto, suponga que tiene una medida que representa un "Balance de Cierre". Usted escribiría una norma, de forma que todos los elementos de resumen en la dimensión de tiempo obtenga el valor del último nivel hijo de ese padre. Así que para este ejemplo, el balance de cierre del Primer Trimestre sería tomado de Marzo en lugar de añadir Enero, Febrero y Marzo. Ya que Marzo es hijo de Primer Trimestre, no necesita alimentar el cálculo para Primer Trimestre. Los FEEDERS para las células de nivel C: son determinados al evaluar los FEEDERS del hijo de nivel N: del padre. Sin embargo, los FEEDERS de nivel C: son evaluados para supresión de ceros.
  4. Una vez que una célula es alimentada, continuará refiriéndose al FEEDER original aún después de que la sentencia de FEEDER haya cambiado. Hay dos métodos para forzar un reprocesamiento de los FEEDERS después de que se ha realizado un cambio: 1) emitir un comando CubeProcessFeeders en un TurboIntegrator de TM1; o 2) reiniciar IBM Cognos TM1 Server. Esto es crítico para estar consciente durante la fase de desarrollo de la aplicación. Por ejemplo, si un FEEDER original estuviera sobre-alimentado un cubo pero fuera después corregido al grabar un FEEDER más restrictivo que parezca ser preciso. Sin embargo, hasta que el Servidor TM1 sea reiniciado, no será posible verificar que el FEEDER está trabajando correctamente.
  5. Los FEEDERS de células numéricas sólo se activan una vez. Los FEEDERS de células de Serie se activan siempre que cambia su valor. Un parámetro es frecuentemente utilizado en una norma para determinar la ubicación para el resultado del cálculo. Si se está utilizando un miembro numérico para alimentar el cálculo, entonces ese FEEDER sólo se activará una vez, así que cualquier actualización al parámetro no creará el FEEDER para la nueva ubicación.

¿Dónde Se Definen los FEEDERS?

Los FEEDERS son definidos en TM1 Rule Editor. En general, debe haber al menos un FEEDER acompañante para cada norma. Las normas deben ser estructuradas de la siguiente manera:

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

Por ejemplo:

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

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

tome en cuenta que en este ejemplo sólo [‘A’] está siendo utilizado para ALIMENTAR la norma. La razón por la que [‘B’] no está también incluido será explicada más completamente en la sección titulada Multiplicación.


Determinando Si Una Célula Ha Sido Alimentada

Utilice estos métodos para determinar si una célula es alimentada o no. Tome en cuenta que si ha estado realizando muchas actualizaciones, tal vez valga la pena reiniciar el servidor de IBM Cognos TM1 antes de realizar estas pruebas.

Método 1 – Inspeccionar Visualmente la Norma

Este documento proporcionará una guía para definir los FEEDERS para muchas aplicaciones posibles. Al aplicar las guías aquí proporcionadas, debe ser posible visualizar normas de inspección, FEEDERS y datos de cubo y después identificar dónde pueden ser utilizados los FEEDERS para mejorar el rendimiento o dónde puede mejorarse un FEEDER existente para proporcionar un rendimiento aún mayor.

Método 2 – Verificar Visualmente Resultados de Cálculos

Verifique que los cálculos están siendo realizados correctamente y que el rollup de ese elemento está mostrando los resultados correctos. En el sencillo ejemplo mostrado a continuación, note que el rollup de "A*B" no se está haciendo correctamente. Esto es porque "A*B" no está siendo alimentado para "Jan", "Feb" y "Mar" y por lo tanto el motor de cálculos de IBM Cognos TM1 está ignorando esas células cuando realiza el rollup.

A continuación hay una vista de un cubo de IBM Cognos TM1 como se vio a través de IBM Cognos TM1 Cube Viewer. La vista está mostrando dos atributos "A" y "B" con el resultado "A*B" siendo derivado mediante una norma. En este ejemplo, la norma es definida de la siguiente manera:

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

Note que la intersección de "A*B" y "Q1-10" está mostrando cero, lo cual es un resultado incorrecto.

Figura 1 – Resultado de cálculo incorrecto debido a que [A*B] no está siendo alimentado o se está alimentando incorrectamente
Figure 1 – Incorrect calculation result due to the fact that [A*B] is not being fed correctly or at all

Método 3 – Verificar la Supresión de Ceros

Haga clic en el icono "Suppress Zeros" y después vuelva a calcular la vista. La vista a continuación ocurrirá después de que haya seleccionado el icono de supresión de ceros, lo que significa que no se mostrará ningún cero en el cubo de IBM Cognos TM1. La vista tampoco muestra células para "A*B" debido a la falta de FEEDERS. Note el mensaje al pasar el ratón que dice "Feeders:(Unnamed)".

Figura 2 – Muestra los elementos de dimensión "A" y "B" pero no el valor calculado "A*B" debido a la falta de FEEDERS cuando la supresión de ceros está habilitada
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

Método 4 – Usar la Opción Check FEEDERS

Con este método, los usuarios pueden hacer clic con el botón derecho en una célula de cálculo y seleccionar "Check Feeders…". La Figura 3 muestra el diálogo IBM Cognos TM1 Rules Tracer dialog, el cual se inicia cuando la opción "Check Feeders…" está seleccionada, muestra que marcar "Feeders(A*B, Q1-Q10)" indica que los valores para Jan-10, Feb-10 y Mar-10 no son alimentados. En este ejemplo, la consolidación de estos tres elementos no será mostrada correctamente, ya que los elementos no están siendo alimentados correctamente.

Figura 3 - Muestra los resultados de seleccionar "Check Feeders…" para el elemento consolidado Q1-10 al que le faltan FEEDERS
Figure 3 - Shows the results of selecting “Check Feeders…” for the consolidated item Q1-10 that is missing FEEDERS

La siguiente vista muestra el diálogo IBM Cognos TM1 Rules Tracer para "Feeders(A*B, Jan-10)". No hay FEEDER, ya que el valor para "Feeders (A*B, Jan-10)" se muestra como no alimentado.

Figura 4 - Muestra los resultados de seleccionar "Check Feeders…" para un elemento detallado Jan-10 que no está siendo alimentado
Figure 4 - Shows the results of selecting “Check Feeders…” for a detailed item Jan-10 that is not being fed

La siguiente figura muestra una vista de un cubo de IBM Cognos TM1 como es visto a través de IBM Cognos Cube Viewer después de insertar el siguiente FEEDER en la norma:

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

Note que los cálculos de nivel C: ahora son precisos para "A*B".

Figura 5 Muestra los resultados de "A*B" con FEEDERS definidos
Figure 5 Shows the results of “A*B” with FEEDERS defined

Al elegir invocar la función "Check Feeders…", el diálogo IBM Cognos TM1 Rules Tracer no muestra ninguna célula sin alimentar para "Feeders(A*B, Q1-10)" como se puede ver a continuación. También muestra el cálculo agregado de 600.0000 para la célula de nivel C: (A*B, Q1-10).

Figura 6 – Rules Tracer mostrando resultados de "Check Feeders…" sin células sin alimentar y con un valor consolidado correcto
Figure 6 – Rules Tracer showing results of “Check Feeders…” with no unfed cells and with a correct consolidated value

Para expandir el ejemplo anterior de alimentar un cálculo, recuerde que una de las cinco consideraciones importantes para los FEEDERS es que las células de nivel C: calculadas son automáticamente alimentadas si sus hijos ya han sido alimentados. El siguiente es un ejemplo simple que ilustra este punto. La Figura 7 está mostrando dos elementos "C" y "D" con el resultado "C*D" siendo derivado mediante una norma. Note que "C" y "D" hacen rollup para "C*D" en la jerarquía. Las normas para calcular "C*D" son las siguientes:

['C*D'] = c:if(ELLEV('Time', !Time) >= 1,Consolidatechildren('Time'),CONTINUE);
['C*D'] = c:['C']*['D'];
Figura 7 - Muestra resultados correctamente calculados para "C*D" sin el uso de FEEDERS
Figure 7 – Shows correctly calculated results for “C*D” without the use of FEEDERS

El diálogo IBM Cognos TM1 Rules Tracer en la Figura 8 muestra que no hay FEEDERS siendo utilizados para calcular (C*D, Q1-10). En este ejemplo, no hay necesidad de definir FEEDERS para "C*D", ya que "C" y "D" hacen rollup en "C*D" en la jerarquía. Como resultado, "C*D" es automáticamente alimentado. El punto clave en este ejemplo es que en algunas situaciones el usuario puede simplificar su desarrollo al utilizar la jerarquía natural dentro de una dimensión para impulsar valores calculados de nivel C: sin necesitar usar un FEEDER.

Figura 8 – No muestra elementos sin alimentar para "C*D", ya que es un elemento de nivel C: y es automáticamente alimentado desde sus hijos de nivel 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

Finalmente, los usuarios deben tener cuidado al usar el dispositivo "Check FEEDERS". Esta función examina todos los hijos de una célula calculada de nivel C: para determinar si se alimenta o no. Si elige utilizar el dispositivo en un resumen de alto nivel, el retorno puede requerir demasiado tiempo. Esto es porque el sistema tiene que evaluar todos los hijos de todas las dimensiones para determinar si la célula es alimentada o no.

Método 5 – Usar un Cubo "OverFeeds"

Use este método para determinar si la sobre-alimentación de un cubo de IBM Cognos TM1 está ocurriendo. La sobre-alimentación puede causar un pobre rendimiento general de consulta del cubo de IBM Cognos TM1.

Considere el ejemplo para un cubo de IBM Cognos TM1 llamado OverFeedSource" donde un usuario desea determinar si cualquiera de las células en este cubo está siendo sobre-alimentada. Esta es la norma de ejemplo siendo utilizada en este cubo:

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

La vista del cubo "OverFeedSource" en la Figura 9 está mostrando dos elementos "A" y "B" con el resultado "A*B" siendo derivado mediante una norma.

Figura 9 – Muestra los resultados de "A*B" utilizando "A" como el origen de FEED
Figure 9 – Showing the results of “A*B” using “A” as the FEED source

El procedimiento utilizado para verificar si se está dando una sobre-alimentación es el siguiente:

  1. Cree un nuevo cubo llamado "Overfeeds" con las mismas dimensiones que "OverFeedSource".
  2. Añada una norma a "Overfeeds" de la siguiente manera:
    SKIPCHECK; 
    [ ] = n: IF(DB('OverFeedSource', !Time, !Product, !OverFeeds) = 0,1,0); FEEDERS;
  3. Añada un FEEDER a "OverFeedSource" de la siguiente manera:
    []=>DB('Overfeeds', !Time, !Product, !OverFeeds);
  4. Abra el cubo "Overfeeds" en IBM Cognos TM1 Cube Viewer. La vista está mostrando dos elementos A y B con el resultado A*B siendo derivado mediante una norma. El cubo "Overfeeds" mostrará un valor de "1" en cada célula detallada que tenga un "0" en el cubo de origen y un valor de "1" en cada célula consolidada que esté siendo sobre-alimentada.
Figura 10 – Muestra un valor de "1" en cada célula detallada que tenga un "0" en el cubo de origen y un valor de "1" en cada célula consolidada que está siendo sobre-alimentada
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

La mejor forma de entender cómo funciona la sobre-alimentación en el cubo "Overfeeds" es considerando la siguiente tabla:

Tabla 1 – Análisis sobre cómo el cubo de IBM Cognos TM1 reacciona al uso de FEEDERS
Cubo OverFeedSourceCubo OverFeeds
ValorFed?Valor al FinalValor en C
0No10
011 (sobre-alimentada)

Al observar niveles de resumen para campos calculados, cualquier valor que no sea cero indicará una sobre-alimentación.

La Figura 11 muestra una vista del cubo de IBM Cognos TM1 Overfeeds donde "A*B" para "P3" es sobre-alimentada a medida que hace roll up a "Q1-10", aunque sea cero en el cubo de origen. P3 para Jan-10 se ha identificado con 1, lo cual indica que la célula ha sido sobre-alimentada.

Figura 11 – Muestra la sobre-alimentación de P3 para Jan-10
Figure 11 – Shows the over-feeding of P3 for Jan-10

La explicación para la sobre-alimentación es la construcción del FEEDER:

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

El sistema está utilizando el valor de "A" para determinar si debe alimentar a "A*B". Está ignorando el valor de "B". Como resultado, el sistema alimentará a "A*B" cuando "A"<>0 AND “B”=0, resultando en un cero "A*B".

Como será mostrado más adelante en otro ejemplo, esta es la forma normal de alimentar un cubo de IBM Cognos TM1 al utilizar factores de multiplicación. Esto causará sobre-alimentación, pero normalmente no a tanta como para que impacte severamente el rendimiento. A menos que se usen Feeders Condicionales, la sobre-alimentación no puede ser completamente eliminada de un Cubo donde la multiplicación, división, exponenciación u otras operaciones se lleven a cabo, pero puede mitigarse al alimentar la variable que tiene más probabilidades de ser cero.

La solución normal a la sobre-alimentación es utilizar FEEDERS Condicionales. Los FEEDERS Condicionales establecen condiciones en los FEEDERS. Este ejemplo también puede ser utilizado para ilustrar otro principio de FEEDER. Cambiar "A" a cero seguirá mostrando a "A" como sobre-alimentada en el cubo "Overfeeds". Esto es porque, una vez que una célula es alimentada, siempre es alimentada hasta que el Servidor TM1 es reciclado o la función TurboIntegrator de TM1 CubeProcessFeeders() es ejecutada.

Método 6 – Usar Performance Monitor

Este método no mostrará específicamente cuáles FEEDERS están sobre-alimentados, pero dará una idea de dónde empezar a buscar. A los Desarrolladores de TM1 frecuentemente se les presenta un modelo terminado o parcialmente terminado que se está ejecutando lentamente y está usando demasiada memoria.

Inicie el monitor de rendimiento en TM1 Architect al hacer clic con el botón derecho en el nombre del Servidor de TM1 y seleccionar "Start Performance Monitor" en el menú como se muestra en la Figura 12. Confirme que "Display Control Objects" debajo de la opción del menú View se ha habilitado.

Figura 12 – El menú contextual mostrado después de hacer clic con el botón derecho en una instancia de Servidor de TM1
Figure 12 – The context menu displayed after right-clicking on a TM1 Server instance

Confirme que "Display Control Objects" debajo de la opción del menú View se ha habilitado.

Abra el cubo de sistema “}StatsByCube” en IBM Cognos TM1 Cube Viewer y note que contiene la siguiente información sobre los FEEDERS como se muestra en la Figura 13. La línea "Feeders" muestra el número de células alimentadas y memoria utilizada por los FEEDERS bajo las columnas tituladas "Number of Fed Cells" y "Memory Used for Feeders". Busque cubos con valores particularmente largos bajo estas columnas. Use un cubo "overfeeds" como se describió anteriormente en el Método 5 para determinar si hay o no cálculos que se estén sobre-alimentando.

Figura 13 – Información de FEEDER de TM1 Control Object }StatsByCube
Figure 13 – FEEDER information from the TM1 Control Object }StatsByCube

Método 7 – Examinar TM1Server.log

Como fue el caso en el método anterior, este método no enumerará directamente cuáles FEEDERS son insuficientes, pero proporcionará un buen lugar para empezar a buscar. En el archivo tm1server.log, el sistema registra la carga de cada uno de los cubos, incluyendo la evaluación de los FEEDERS para cada cubo. El archivo tm1server.log está ubicado de forma predeterminada en el Directorio de Datos de TM1 para la instancia específica de Servidor de TM1 con la que está trabajando. Las ubicaciones de Directorios de Datos de TM1 son definidas por el usuario. Utilizando el Servidor de TM1 PlanSamp proporcionado con el paquete de instalación estándar de IBM Cognos TM1, el archivo tm1server.log estaría ubicado de forma predeterminada en la siguiente ubicación:
C:\Program Files\IBM\cognos\tm1\samples\tm1\PlanSamp\tm1server.log.

El siguiente ejemplo muestra las líneas seleccionadas del archivo tm1server.log para el nombre de cubo "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

Esta información puede ser utilizada para determinar el tiempo que se requiere para evaluar los FEEDERS para cada cubo. Si se requiere mucho tiempo para evaluar los FEEDERS de un cubo particular, entonces eso puede ser un indicativo de que los FEEDERS contenidos en el cubo son ineficientes.


Definiendo FEEDERS

Esta sección detalla la mayoría de los distintos tipos de cálculos y muestra cómo construir el FEEDER acompañante. Como norma general, al elegir un elemento para alimentar un cálculo, elija el elemento que cuando sea cero también los resultados del cálculo sean cero.

Es importante notar que la forma en que es definido un FEEDER depende del tipo de cálculo. En esta sección, una estrategia de FEEDER será descrita para cada uno de los siguientes tipos de cálculo:

  1. Multiplicación
  2. División
  3. Suma
  4. Resta
  5. Condicional
  6. Cubo a cubo

Si el cálculo es una combinación de los anteriores, entonces una combinación de las estrategias de FEEDER apropiadas será necesaria para cada componente del cálculo. Igual que con las normas, hay dos formas de definir el FEEDER: 1) al poner el nombre de miembro entre corchetes; y 2) al usar la función DB(). Hay ejemplos de ambos en muchas de las siguientes subsecciones.

Multiplicación

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

La multiplicación es el cálculo más sencillo de alimentar. En el ejemplo anterior, estamos usando "A" para alimentar el cálculo. También pudimos haber elegido "B". Pudimos haber elegido cualquiera, ya que "A" cero o "B" cero forzarán que el cálculo sea cero.

Para optimizar aún más el FEEDER, se debe elegir el elemento que tiene más probabilidades de ser cero. Para clarificar más este concepto, vamos a utilizar un cálculo típico de Ingresos;

[‘Ingresos’] = [‘unidades’]*[‘precio’];

En este ejemplo, elegiríamos alimentar "unidades", ya que tiene más probabilidades de ser cero. Por ejemplo, no todos los clientes comprarán todos los productos, así que muchas de las combinaciones serán cero. "precio" muy probablemente no será cero y principalmente fijo para todas las combinaciones de producto y cliente.

También es posible definir el FEEDER utilizando el formato de DB.

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

Normalmente no será necesario utilizar el formato DB, a menos que estuviera:

  1. Definiendo normas de cubo a cubo
  2. Definiendo un FEEDER condicional
  3. Manipulando los FEEDERS de forma que los elementos de FEEDER coincidan con elementos objetivo

El método de DB le da más flexibilidad, ya que puede intercalar sentencias condicionales y funciones de norma de IBM Cognos TM1. Consulte las secciones siguientes para obtener más detalles y ejemplos.

División

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

Los mismos principios discutidos en la sección de Multiplicación aplican para la División. Nuevamente, la elección de 'A' o 'B' no importa realmente al elegir qué elemento alimentar. Si cualquier elemento es cero, entonces el resultado del cálculo será cero o indefinido.

Suma

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

Aquí tenemos que alimentar ambas, ya que "A" cero no necesariamente obligará que el cálculo sea cero.

Resta

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

Igual que con la Suma, tenemos que alimentar ambas, ya que "A" cero no necesariamente obligará que el cálculo sea cero.

Normas Condicionales

Para ilustrar esto, hemos elegido un ejemplo que es comúnmente utilizado en aplicaciones de presupuestos o pronósticos. En el ejemplo a continuación (Figura 14), estamos realizando un cálculo para sólo aquellos métodos que sean distinguidos como meses de pronóstico (por ejemplo, de "May-10" en adelante, los meses de pronóstico tienen un fondo gris).

Figura 14 – Muestra los resultados de usar un FEEDER Condicional para los meses de pronóstico comenzando con May-10
Figure 14 – Shows the results of using a Conditional FEEDER for the forecast months starting with May-10

Para esos meses que son distinguidos como "Actual" (en este caso "Jan-10" a "Apr-10"), sólo queremos subir o ingresar el resultado del cálculo. Note que los meses de pronóstico reales (fila "E*F (For Forecast Months)" y meses "Jan-10" a "Apr-10") tienen un fondo blanco en sus células, lo que significa que estas células pueden aceptar valores ingresados manualmente y no son el resultado de un cálculo. La razón es que para los reales, el número es estático y no queremos que el sistema lo calcule en forma distinta que la forma en que está almacenado en el sistema de registro.

En este ejemplo estamos utilizando un atributo en la dimensión de tiempo para denotar meses reales o de pronóstico. La Figura 15 es una vista de Attributes Editor, en el cual un nuevo atributo llamado "Actual Flag" ha sido añadido y algunos meses específicos ("Jan-10" a "Apr-10") han sido denotados con una "A" para mostrar cuáles meses contienen reales.

Figura 15 – El atributo de dimensión de tiempo llamado "Actual Flag (Text)" con "A" en los meses denotados como datos reales
Figure 15 – The time dimension attribute named “Actual Flag (Text)” with “A” in the months denoted as actual data

La norma es definida de la siguiente manera:

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

El FEEDER es de la siguiente manera:

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

Normas de Cubo a Cubo

Un ejemplo simple es utilizado a continuación para ilustrar FEEDERS de norma de cubo a cubo, ya que es más complejo y presenta más retos. Considere los cubos de origen y destino definidos para el cubo de origen "FeederSource". El cubo “FeederSource” tiene dos dimensiones “FeederSource” (con un solo elemento llamado “Source”) y “Value” (con un solo elemento llamado “Value”) y un solo valor de datos de 10 como se muestra en la Figura 16.

Figura 16 – Muestra el cubo de origen de FEEDER de muestra llamado “FeederSource”
Figure 16 – Shows the example FEEDER source cube named “FeederSource”

En la Figura 17 a continuación, observamos una vista de un cubo de IBM Cognos TM1 llamado “FeederTarget” mostrando valores que son alimentados a partir del cubo de origen llamado “FeederSource”. El cubo “FeederTarget” tiene dos dimensiones “FeederTarget” (con un solo elemento llamado “Target”) y “Time” (con elementos de nivel N: para cada mes y elementos de nivel C: para consolidaciones trimestrales “Q1-10”, “Q2-10”, etc.) y los elementos de nivel N: han sido llenados con el valor del cubo “FeederSource” de 10.

Figura 17 – Una vista de un cubo de destino de IBM Cognos TM1 incluyendo valores cargados utilizando un FEEDER
Figure 17 – A view of an IBM Cognos TM1 target cube including values loaded using a FEEDER

La razón por la que los FEEDERS de cubo a cubo son más complejos es que usted define la norma en el cubo de destino y el FEEDER en el cubo de origen. En efecto, el cubo de origen está enviando los FEEDERS al cubo de destino y la norma en el cubo de destino los está recibiendo. La situación es complicada porque las estructuras de dimensión en los cubos de origen y destino pueden ser distintas. El siguiente ejemplo lo llevará a través del proceso etapa por etapa:

Etapa 1 – Definir la norma en el cubo de destino

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

Un punto importante aquí, que no está completamente resaltado en el ejemplo, es que la función de DB tendrá una estructura de parámetro que pertenece a la estructura dimensional del cubo de origen (el primer parámetro será el nombre de cubo, el segundo la primera dimensión en el cubo de origen, el tercero la segunda dimensión en el cubo de origen, etc.). Sin embargo, los valores que usted proporciona en el parámetro deben ser con respecto al cubo de destino o a un valor codificado.

Como este es un punto tan importante, lo ilustraremos con un sub-ejemplo.

Suponga que tiene dos cubos, “Cube S” y “Cube T”. Ambos tienen estructura de cubo idénticas con dimensiones idénticas, pero las dimensiones en cada cubo son una copia de la otra. Por ejemplo, las dimensiones en “Cube S” son “Product S” y “Time S”. Las dimensiones en “Cube T” son “Product T” y “Time T”. Las dos dimensiones de producto son idénticas y las dos dimensiones de tiempo son idénticas. Entones la norma sería:

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

Note que las dimensiones en el cubo de destino son sustituidas en los parámetros de la función de DB que representa la estructura del cubo de origen. Este es un punto importante. ¡Los Desarrolladores de TM1 han pasado muchas horas observando una norma intentando descubrir por qué no se salva!

Etapa 2 – Definir el FEEDER en el cubo de origen

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

‘2010’ – Es necesario codificar un valor aquí, ya que no hay dimensión de Tiempo en el cubo de origen. Al codificar un elemento de resumen de la dimensión de tiempo, se obliga al sistema a alimentar a todos los elementos de nivel N: de 2010. Note que si el cubo de origen contenía la dimensión de Tiempo, entonces el FEEDER sería construido de la siguiente manera:

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

'Target' – Es necesario codificar la medida, ya que hay un nombre de elemento de medida distinto en el origen y en el destino. Necesitamos codificarlo en un elemento en la dimensión de medidas de destino.

Este es el FEEDER para nuestro sub-ejemplo:

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

El FEEDER aquí es definido como el inverso de la norma. Note que las dimensiones en el cubo de origen son sustituidas en los parámetros de la función de DB que representa la estructura del cubo de destino. Esto puede causar algunos problemas y la siguiente lista fue armada para resaltar las buenas prácticas en el diseño de FEEDERS de cubo a cubo:

  1. Si la misma dimensión está en los cubos de destino y de origen, simplemente use “!DimensionName” en ese parámetro.
  2. Si tiene distintas dimensiones, que sean copias una de otra, entonces debe usar “!DimensionNameInSource” para ese parámetro.
  3. Si tiene una dimensión en el destino que no exista en el origen, entonces necesitará codificar un elemento de resumen en la dimensión de destino. En el ejemplo anterior, codificamos ‘2010’. Esto significa que el sistema automáticamente alimentará a todos los hijos de ‘2010’. Este dispositivo debe ser usado con precaución, ya que puede provocar escenarios de sobre-alimentación y largos periodos de inicio del servidor.
  4. Si tiene una dimensión en el origen que no existe en el destino, entonces necesitará codificar un elemento en la dimensión de origen.
  5. Si desea enfocarse en un elemento particular, entonces simplemente codifíquelo en el parámetro. Por ejemplo, ‘Revenue’ simplemente se enfocará en la medida de ingresos. Es posible minimizar la necesidad de hacer esto al utilizar los mismos nombres de medida en el origen y en el destino. De esa forma es posible simplemente utilizar “!TargetMeasureDimName”.
  6. Los FEEDERS que envía desde el cubo de origen deben coincidir con los elementos en el cubo de destino. Esto se aplica a todas las dimensiones. Para ilustrar este punto, considere el siguiente ejemplo. En la alimentación de un cubo semanal en un cubo mensual, las semanas no existían en el cubo mensual, así que no se alimentó nada. Es posible solucionar esto al cambiar el FEEDER de forma que los padres de la semana sean pasados en el FEEDER. Ya que los padres de las semanas son meses y los meses están presentes en el cubo de destino, los FEEDERS funcionarán como se espera.

Evitar el FEEDER de cubo a cubo

Hay ocasiones en las cuáles es posible evitar definir el FEEDER de cubo a cubo si la medida de destino es utilizada en un cálculo subsecuente. En la Figura 18, “Target” es el resultado de un cálculo de cubo a cubo, pero también es utilizado en el cálculo “Target*C”. El valor de “C” y “Jan-10” es 20. El valor calculado de “Target*C” para “Jan-10” es 200 (“Target” tiene un valor de 10 y “C” tiene un valor de 20.) El cubo de IBM Cognos TM1 está cargando valores con base en la siguiente fórmula de FEEDER:

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

Es posible eliminar la necesidad del FEEDER de cubo a cubo al simplemente alimentar “C” de la siguiente manera:

['C'] => ['Target * C'];
Figura 18 - Muestra al cubo de destino evitando la necesidad de una definición de FEEDER del cubo de origen simplemente al utilizar los valores del cubo de origen en un cálculo y alimentar ese cálculo dentro del cubo de destino
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

FEEDERS Condicionales

Es posible usar FEEDERS condicionales para reducir o eliminar la sobre-alimentación. Normalmente necesitará usar un FEEDER condicional para acompañar una norma condicional. Para ilustrar el punto, considere el ejemplo de sobre-alimentación que discutimos anteriormente:

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

Como discutimos anteriormente, el sistema está ignorando el valor de "B" cuando está construyendo el FEEDER. Es posible construir FEEDERS condicionales de la siguiente manera para solucionar el problema:

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

Note que para alimentar condicionalmente, es necesario usar una función de DB. En este caso, pone una sentencia IF en el parámetro de la función de DB que representa el nombre del cubo. Retorne el nombre del cubo para las células que desea alimentar y ‘’ (nulo) para aquellas que no desea alimentar.

Observando el cubo, ahora vemos que no estamos sobre-alimentando este cálculo. La Figura 19 es una vista del cubo “OverFeeds” mostrando los resultados de Jan-10 y Q1-10 con la sobre-alimentación corregida como se ilustra en los valores para Q1-10 sin tener ningún valor igual a 2.

Figura 19 – No muestra valores iguales a 2 en el campo de consolidación Q1-10, lo que significa que no hay sobre-alimentación del cubo de 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

¿Qué Tan Seguido Se Activan los FEEDERS?

De acuerdo con las cinco consideraciones importantes específicas para los FEEDERS, los FEEDERS de células numéricas se activan sólo una vez y los FEEDERS de células de Serie se activan siempre que cambia su valor. Esto es importante cuando un parámetro es utilizado para determinar la ubicación del resultado calculado. Para ilustrar este punto, la Figura 20 muestra un cubo de IBM Cognos TM1 con el valor de 100 calculado en la inserción de “Result” y “Feb-10” resaltado:

Figura 20 – Un cubo de IBM Cognos TM1 resaltando el valor de 100 en la intersección de “Result” y “Feb-10”
Figure 20 – An IBM Cognos TM1 cube highlighting the value 100 at the intersection of “Result” and “Feb-10”

La norma es definida como:

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

El FEEDER es:

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

Como es posible ver, estamos utilizando “Value” para alimentar a “Result” en una norma donde el parámetro “Month” está siendo utilizado para llenar el mes correcto en la dimensión de tiempo.

Si cambiamos el parámetro de Month al cambiar el campo en la intersección “Month”/”Jan-10” de “Feb-10” a “Mar-10”, entonces la célula ya no es alimentada. Esto es ilustrado en la Figura 21, donde “Q1-10” es cero en lugar de 100. Esto es debido a que los FEEDERS para células numéricas se activan sólo una vez. La célula “Result” para “Feb- 10” fue alimentada inicialmente, así que “Feb-10” es la única célula que puede ser alimentada. La solución para esto es cambiar el FEEDER por lo siguiente:

['Month','Jan-10']=> DB('FEEDERS', DB('FEEDERS', 'Jan-10', 'Month'), 'Result');
Figura 21 – Muestra que alimentar el cubo con un valor numérico puede resultar en cambios que no se reflejan apropiadamente
Figure 21 – Shows that feeding the cube with a numeric value can result in changes not being properly reflected

Note que ahora estamos utilizando “Month” en lugar de “Value” para alimentar el cálculo y, ya que “Month” es una serie, esto causará que el FEEDER se active cada vez que cambie. La siguiente vista de un cubo de IBM Cognos TM1 muestra los resultados correctos para “Q1-10” de 100.

Figura 22 – Muestra que alimenta el cubo con un valor de serie mostrará resultados actualizados tan pronto como el campo de datos es cambiado
Figure 22 – Shows that feeding the cube with a string value will display updated results as soon as a data field is changed

FEEDERS Persistentes

Los FEEDERS persistentes fueron presentados en IBM Cognos TM1 en la versión 9.5.1. El valor predeterminado para este parámetro es desactivado, pero puede habilitarlo al utilizar el parámetro PersistingOfFEEDERS en el archivo TM1s.cfg. Para habilitar los FEEDERS persistentes y mejorar el tiempo de recarga de los cubos con FEEDERS en la inicialización del Servidor de TM1, establezca el parámetro PersistingOfFEEDERS con un valor de “T” (verdadero) para almacenar los FEEDERS calculados en un archivo de FEEDERS.

PersistingOfFEEDERS=T

Cuando los FEEDERS persistentes son habilitados y el Servidor de TM1 encuentra un archivo de FEEDER persistente, carga los FEEDERS salvados, lo cual reduce el tiempo que normalmente se requiere para volver a calcular esos FEEDERS. Los FEEDERS son salvados cuando los datos son salvados o las normas son editadas. Usted no salva explícitamente los FEEDERS.

Para las instalaciones con muchos cálculos complejos de FEEDER, persistir los FEEDERS y después volver a cargalos en la inicialización del servidor mejorará el rendimiento. Para los FEEDERS simples, el tiempo requerido para leer FEEDERS desde el disco puede exceder el tiempo para volver a calcular los FEEDERS, pero la mayoría de las instalaciones se beneficiarán.

Es importante estar conscientes de que utilizar FEEDERS persistentes incrementará el tamaño de su sistema sólo en el disco. El tamaño de la memoria no es afectado por el uso de FEEDERS persistentes.

Es necesario tener cuidado al desarrollar aplicaciones utilizando FEEDERS persistentes. Como se mencionó anteriormente, el método normal para volver a evaluar los FEEDERS es reiniciar el Servidor de TM1. Sin embargo, si tiene los FEEDERS persistentes habilitados, primero necesitará ejecutar un proceso TurboIntegrator de TM1 que contenga la siguiente función en el prolog:

DeleteAllPersistentFEEDERS()

Esto forzará la evaluación de FEEDER en la inicialización del Servidor de TM1 en lugar de sólo leer el caché de FEEDER persistente.


Ejemplos de FEEDERS Complejos

La sección de FEEDER complejo detalla algunos ejemplos más complejos para situaciones del mundo real.

Cubo de Detalle a Resumen de Elementos de Línea

Un problema de modelado común, especialmente con aplicaciones de presupuestos y planificación, es enlazar un cubo de detalle de elemento de línea con un cubo de resumen donde las dimensiones sean listas de elementos necesarios (una lista específica de elementos como productos) en el cubo de origen y dimensiones reales en el cubo de destino. Considere el siguiente cubo de entrada llamado “LineItemSource”, el cual incluye Elemento de Línea, Descripción, Tiempo, Producto y Cantidad, como se muestra en la Figura 23.

Figura 23 – Muestra el cubo de entrada “LineItemSource”
Figure 23 – Shows the input cube “LineItemSource”

La Figura 24 es una vista del cubo de resumen “LineItemTarget”, el cual consolida los valores donde las listas de elementos necesarios se vuelven dimensiones (por ejemplo, Time es ahora columnas y Product es ahora filas). Este cubo muestra los elementos de línea de detalle así como los valores de resumen a nivel de Producto Total y de Tiempo Trimestral.

Figura 24 – Vista del cubo “LineItemTarget” con dimensiones creadas a partir de las listas de elementos necesarios en el cubo “LineItemSource”
Figure 24 – The “LineItemTarget” cube view with dimensions created from the pick-lists in the “LineItemSource” cube

Ya que no es posible modelar este tipo de estructura de cubo para transferir datos directamente de “LineItemSource” a “LineItemTarget”, es necesario pasar a través de un cubo intermedio llamado “LineItemCalc”. La siguiente vista es el cubo intermedio, el cual contiene todas las dimensiones de ambos cubos – Elemento, Producto y Tiempo.

Figura 25 – El cubo intermedio “LineItemCalc”, el cual contiene todas las dimensiones de “LineItemSource” y “LineItemTarget”
Figure 25 – The intermediate cube “LineItemCalc” which contains all the dimensions from both “LineItemSource” and “LineItemTarget”

Las casi correctas Normas y FEEDERS serían de la siguiente manera:

Para LineItemSource,

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

Para 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);

Para LineItemTarget,

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

Ahora pasemos a través de las normas y FEEDERS uno por uno y expliquemos.

Primero, comencemos con la norma que convierte las listas de elementos necesarios en dimensiones en el cubo “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);

Los componentes de la norma son:

  1. Negrita – compruebe si el nombre de elemento de la dimensión de producto en el cubo “LineItemCalc” coincide con el producto ingresado en el cubo “LineItemSource”. Note el uso de “@=” en ambas series.
  2. Cursiva – compruebe si el nombre de elemento de la dimensión de tiempo en el cubo “LineItemCalc” coincide con el mes ingresado en el cubo “LineItemSource”. Note el uso de “@=” en ambas series.
  3. Cursiva Negrita – retorne el valor de “Amount” desde el cubo “LineItemSource” si es TRUE.
  4. No haga nada si es FALSE.

Ahora, observemos el FEEDER asociado en el cubo “LineItemSource”.

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

Al observar una implementación de diseño inicial, el FEEDER fue definido de la siguiente manera:

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

Al recordar un consejo anterior en la sección de Normas de Cubo a Cubo , si hay una dimensión en el cubo de destino que no esté en el origen, en este ejemplo Producto y Tiempo, es posible codificar un elemento de resumen en el parámetro apropiado como se muestra en negrita anteriormente.

Aunque esto funcionará, tal vez no sea lo óptimo para todas las situaciones, ya que los volúmenes de datos pueden impactar negativamente los tiempos de inicio del Servidor de TM1. Esto es debido a que este tipo de FEEDERS resulta en sobre-alimentaciones severas, ya que el sistema tiene que alimentar cada uno de los productos y cada uno de los meses para cada uno de los elementos de línea. Considere cambiar el FEEDER, de forma que sólo alimente el Producto seleccionado en cualquier elemento de línea particular. Por ejemplo, sustituya ‘Total Product’ con DB('LineItemSource', !LineItem, 'Product') y ‘2010’ con DB('LineItemSource', !LineItem, 'Time'). Al hacer estos cambios, el tiempo de inicio del sistema será mejorado.

Un problema adicional con el FEEDER en el cubo “LineItemSource” es que está alimentando sólo una vez, así que no continuará funcionando si cambia el producto o la fecha del mes. La solución es alimentar las series, como se muestra en el siguiente ejemplo:

['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');

En este ejemplo, el FEEDER es repetido para cada dimensión (para Producto y Tiempo). Esto asegura que los números fluyan correctamente cuando producto y tiempo cambian. Así que las normas y FEEDERS correctos son:

Para 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');

Para 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;

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt, Business analytics
ArticleID=848170
ArticleTitle=FEEDERS de IBM Cognos TM1
publish-date=12032012