Moving Average In Tm1

TM1 Developer Jobs A tabela a seguir é para comparação com o acima e fornece estatísticas para toda a categoria de títulos de emprego em trabalhos permanentes anunciados em todo o Reino Unido. A maioria das vagas de emprego incluem um título de trabalho discernível. Como tal, os números na primeira linha fornecem uma indicação do número total de postos de trabalho permanentes na amostra global. Títulos de Trabalho Categoria Permanent IT anúncios de emprego com uma correspondência na categoria de Títulos de Empregos Como de todos os trabalhos permanentes de TI localizados no Reino Unido Número de salários citados Mudança salarial mediana ano-a-ano 90 ofereceu um salário de mais de 10 ofereceu um salário de mais Do Reino Unido, excluindo o salário médio de Londres TM1 Developer Jobs Demand Trend A tendência de procura de anúncios de emprego que apresentaram o TM1 Developer no cargo. TM1 Developer Salary Trend Este gráfico fornece a média móvel de 3 meses para os salários cotados em trabalhos de TI permanentes citando TM1 Developer no Reino Unido. TM1 Developer Histogram Salário Este gráfico fornece um histograma salarial para empregos de TI citando TM1 Developer durante os 3 meses a 16 de dezembro de 2016 no Reino Unido. TM1 Developer Top 7 Job Localizações A tabela abaixo analisa a demanda e fornece um guia para os salários médios citados em empregos de TI citando TM1 Developer no Reino Unido durante o período de 3 meses a 16 de dezembro de 2016. A coluna Rank Change fornece uma indicação da mudança Na demanda dentro de cada localidade com base no mesmo período de 3 meses do ano passado. O IBM Cognos TM1 FEEDERS Introdução Um dos conceitos mais avançados no desenvolvimento de cubos IBM Cognos TM1 é a implementação correta de FEEDERS dentro das regras TM1. Este documento descreve FEEDERS e como usá-los efetivamente para melhorar o desempenho ao criar cubos do IBM Cognos TM1. Pré-requisito Este documento aborda um conceito avançado do IBM Cognos TM1 e usa terminologia específica da TM1. O leitor deve ter uma compreensão dos cubos, dimensões, regras e terminologia do IBM Cognos TM1 antes de prosseguir. Aplicabilidade IBM Cognos TM1 9.5.1 através do IBM Cognos TM1 10.1 Exclusões e Exceções Não foram identificadas exclusões ou exceções. Definição O que são FEEDERS FEEDERS são usados ​​pelo mecanismo de cálculo do IBM Cognos TM1 para auxiliar no gerenciamento da dispersão em cubos com o SKIPCHECK habilitado. Alguns cubos podem ter cálculos de regras, mas ser extremamente pequeno ou denso e não precisar de SKIPCHECK. FEEDERS identifica as células em um cubo que pode conter um valor calculado baseado em regras e garante que esses valores são incluídos nos cálculos de agregação. SKIPCHECK é uma palavra-chave inserida na parte superior de um arquivo de regra que habilita o algoritmo de consolidação de dados esparsos TM1s. Cubos utilizando SKIPCHECK normalmente requer FEEDERS, outra palavra-chave inserida mais tarde em um arquivo de regra. Consulte a seção 2.3 para obter mais informações sobre SKIPCHECK. Por que usar FEEDERS Os cubos OLAP podem ser muito pouco povoados, pois tais dados de gerenciamento dentro de cubos TM1 se tornam muito importantes. Veja abaixo alguns exemplos de problemas enfrentados na construção de Cubos TM1: Exemplo 1 Cubo de Vendas Considere um Cubo de Vendas com as seguintes dimensões e contagem de elementos: Lojas (500) Geografia (300) Produtos (50.000) Canais (6) Unidade de Negócios ) Tempo (300) Medidas (15) Contagem de células do cubo 500 300 50000 6 12 300 15 2.430.000.000.000.000 de células TM1 armazena todos os dados como um duplo, mas a RAM consumida armazenando cada célula depende do número de dimensões no cubo. Usando algoritmos de matriz densa padrão para cálculos em um cubo esparso pode consumir grandes quantidades de recursos de computação e levar uma quantidade significativa de tempo para ser concluída. Um cubo de 5 dimensões exigirá143 bytes por célula para armazenamento de dados. Para melhorar o desempenho do cálculo em cubos esparsos, o IBM Cognos TM1 usa um algoritmo esparso de agregação de dados. Isso permite que o IBM Cognos TM1 realize agregações ou consolidações dimensionais de forma rápida e eficiente. Lembre-se de que essas agregações ou consolidações dimensionais são calculadas com base no desenho hierárquico das dimensões usadas pelo cubo. Eles são diferentes dos cálculos baseados em regras que são usados ​​para calcular várias células dentro ou entre dimensões e cubos. Um exemplo de agregação ou consolidação dimensional seria uma dimensão do produto que contém os itens Produto A, Produto B, Produto C e Produtos totais. Com base no desenho hierárquico da dimensão, todas as células com valores para o Produto A, Produto B e Produto C agregariam a Total de Produtos. Um exemplo de um cálculo baseado em regras seria: Volume Volume Receita. No IBM Cognos TM1, as regras são definidas fora da dimensão no TM1 Rules Editor e, em seguida, são salvas em um cubo TM1. No entanto, uma vez que o IBM Cognos TM1 detecta que uma regra foi adicionada a um cubo (quando um arquivo. rux foi criado e salvo), o algoritmo de agregação de dados esparsos será automaticamente desativado pela TM1. Isso é para garantir que os cálculos agregados calcularão valores que incluem os valores calculados da regra. Os valores calculados da regra estarão sempre corretos. Se a regra for então implementada, o desempenho do cubo TM1 diminuirá significativamente uma vez que não pode tirar proveito do algoritmo de agregação de dados esparsos. Em média, os cubos grandes e esparsos sofrerão degradação do desempenho enquanto cubos menores não. Se o algoritmo de consolidação esparsa fosse deixado ligado, TM1 ignoraria as células calculadas de regra ao calcular consolidações, retornando um resultado incorreto. Se o algoritmo de consolidação esparsa fosse desativado, TM1 retornaria o resultado correto, mas o sistema ficaria consideravelmente mais lento. Claramente, ambas as opções acima são indesejáveis, o que resultou na introdução do conceito de alimentadores. Os alimentadores são uma maneira de permitir que os cubos que contêm regras continuem a alavancar os benefícios de desempenho do algoritmo de consolidação esparsa, mas também garantir que as células calculadas com regras não sejam ignoradas quando células consolidadas estão sendo calculadas. Cubos dispersos sem consolidações e sem requisitos de supressão zero podem conter cálculos de regra sem alimentadores. Além disso, quanto mais denso for um cubo, independentemente do tamanho, menos cubo se beneficiará do skipcheck e dos alimentadores. O que é SKIPCHECK SKIPCHECK é usado em regras TM1 como um algoritmo de consolidação esparsa. Ele basicamente substitui o comportamento padrão TM1 para cubos com regras. Qual é a configuração padrão Por padrão SKIPCHECK é ON, até que um arquivo de regra seja criado, o que efetivamente desabilita skipcheck. Como funcionam os FEEDERS Ao contrário das regras, os alimentadores só se aplicam a células de nível de folha e nunca a células consolidadas. No entanto, elementos consolidados podem ser usados ​​na especificação de uma instrução de alimentador como uma forma abreviada de especificar todos os elementos de folha dentro da consolidação. Ao especificar um elemento consolidado em uma instrução de alimentador, ocorre o seguinte: Alimentação de uma consolidação significa que todos os descendentes de folhas da consolidação serão alimentados se houver um valor presente. Por exemplo, se o elemento consolidado continha quatro elementos de folha, mas apenas dois deles continham um valor, então apenas aqueles dois se alimentariam. Alimentar a uma consolidação significa que todas as células da folha sob a consolidação serão alimentadas. Por exemplo, se o elemento consolidado continha quatro elementos de folha, então todos os quatro elementos de folha seriam alimentados. Este é um princípio importante como algumas pessoas acreditam erroneamente que é a consolidação que está fazendo a alimentação ou ser alimentado. Isso pode tornar as regras de depuração e os alimentadores mais difíceis se este princípio não for bem compreendido. Quando um alimentador é aplicado, define um sinalizador de byte único ou pseudo-dados em uma célula de folha para sinalizar que ele deve ser consolidado. Isso garante que o algoritmo de consolidação esparsa não ignore essa célula ao calcular valores consolidados. Uma vez alimentado, uma célula permanece alimentada até que o servidor seja reiniciado ou o cubo seja descarregado. Em geral, os alimentadores não são necessários para as regras de nível C. A única exceção é quando uma regra é aplicada a um elemento consolidado onde ele não tem valores em qualquer um de seus elementos filho. Subalimentação e superalimentação É o papel do autor das regras garantir que as células calculadas são alimentadas corretamente. Deve-se tomar cuidado para garantir que os alimentadores alimentam exatamente quantas células são necessárias, nem mais nem menos. Pode haver consideráveis ​​efeitos colaterais se um modelo não for alimentado corretamente. A subalimentação ocorre quando alguns ou todos os valores que estão sendo calculados não são alimentados. Na maioria dos casos, isso resultará em resultados incorretos ao analisar dados consolidados no cubo. A subalimentação deve ser evitada, pois prejudica a integridade do modelo. Ao escrever alimentadores, você deve começar com o inverso da regra que você está alimentando para garantir a alimentação é adequada. A sobrealimentação ocorre quando (a) as células que não contêm valores calculados de regra estão sendo alimentadas ou (b) quando as células calculadas com regra que resultam em um valor zero estão sendo alimentadas. Ambas as situações devem ser evitadas, mas especialmente (a). Enquanto overfeeding não resultará em valores incorretos no cubo tem um efeito prejudicial sobre o desempenho do sistema. O tempo necessário para alimentar células que não necessitam de alimentação é desperdiçado, e todos os alimentadores desnecessários ocupam memória que também é desperdiçado. Sobrealimentação pode causar uma explosão significativa na memória e pode aumentar o tempo de execução de consultas consolidadas. Onde estão FEEDERS FEEDERS definidos são definidos no TM1 Rule Editor. Em geral, deve haver pelo menos um FEEDER acompanhante para cada regra. As regras devem ser estruturadas da seguinte forma: Ao analisar os níveis de sumário para campos calculados, qualquer valor diferente de zero indicará uma sobrealimentação. A Figura 11 mostra uma vista do Overfeeds do cubo do IBM Cognos TM1 em que AB para P3 é sobrealimentado à medida que rola até Q1-10 mesmo que seja zero no cubo de origem. P3 para Jan-10 foi identificado com 1, o que indica que a célula foi sobrealimentada. A Figura 11 mostra a sobrealimentação de P3 para Jan-10 A explicação para a sobrealimentação é a construção do ALIMENTADOR: O sistema está usando o valor de A para determinar se ele deve alimentar AB. Está ignorando o valor de B. Como resultado, o sistema alimentará AB quando Altgt0 E B0, resultando em um zero AB. Como será mostrado mais adiante em outro exemplo, esta é a maneira normal de alimentar um cubo do IBM Cognos TM1 usando fatores de multiplicação. Levará à sobre-alimentação, mas tipicamente não a tal uma extensão onde severamente impacta o desempenho. A menos que os Condicionais sejam usados, a sobrealimentação pode nunca ser completamente eliminada de um Cube onde a multiplicação, divisão, exponenciação ou outras operações ocorrem, mas pode ser atenuada pela alimentação da variável que é mais provável ser zero. A solução normal para overfeeding é usar condicionais FEEDERS. ALIMENTADORES condicionais definem condições em ALIMENTADORES. Este exemplo também pode ser usado para ilustrar outro princípio FEEDER. Alterar A para zero ainda mostrará A como sobre-alimentado no cubo Overfeeds. Isso ocorre porque, uma vez que uma célula é alimentada, ela é sempre alimentada até que o servidor TM1 seja reciclado ou a função TM1 TurboIntegrator CubeProcessFeeders () seja executada. Método 6 Usar o Monitor de Desempenho Este método não mostrará especificamente quais ALIMENTADORES estão sobre a alimentação, mas dará uma idéia de onde começar a procurar. Muitas vezes TM1 desenvolvedores são apresentados com um modelo acabado ou parcialmente terminado que está funcionando lento e está usando um monte de memória. Inicie o monitor de desempenho no Arquiteto TM1 clicando com o botão direito do mouse no nome do Servidor TM1 e selecionando Iniciar o Monitor de Desempenho no menu, conforme mostrado na Figura 12. Confirme se os Objetos de Controle de Exibição encontrados na opção do menu Exibir foram habilitados. Figura 12 O menu de contexto exibido depois de clicar com o botão direito do mouse em uma instância do TM1 Server Confirme se Display Control Objects como encontrado na opção de menu View foi habilitado. Abra o cubo do sistema StatsByCube no IBM Cognos TM1 Cube Viewer e observe que ele contém as seguintes informações sobre FEEDERS como mostrado na Figura 13. A linha Feeders mostra o número de células alimentadas ea memória usada pelos FEEDERS sob as colunas intituladas Number of Fed Cells and Memória utilizada para alimentadores, respectivamente. Procure cubos com valores particularmente grandes sob essas colunas. Use um cubo overfeeds como descrito anteriormente no método 5 para determinar se ou não os cálculos estão sendo sobre-alimentados. Examine o TM1Server. log Como no caso do método anterior, este método não lista diretamente quais FEEDERS são ineficientes, mas fornecerá um bom lugar para começar a procurar. No arquivo tm1server. log, o sistema registra o carregamento de cada cubo, incluindo a avaliação dos FEEDERS para cada cubo. O arquivo tm1server. log está localizado por padrão no TM1 Data Directory para a instância específica do TM1 Server com a qual você está trabalhando. As localizações dos Directórios de Dados TM1 são definidas pelo utilizador. Usando o exemplo do PlanSamp TM1 Server fornecido com o pacote de instalação padrão do IBM Cognos TM1, o arquivo tm1server. log será localizado por padrão no seguinte local: C: Program FilesIBMcognostm1samplestm1PlanSamptm1server. log. O exemplo a seguir mostra as linhas selecionadas do arquivo tm1server. log para o nome do cubo BW COST CALCULATION: Esta informação pode ser usada para determinar o tempo que leva para avaliar os FEEDERS para cada cubo. Se leva muito tempo para avaliar os FEEDERS para um determinado cubo, então isso poderia ser uma indicação de que os alimentadores contidos no cubo são ineficientes. Definindo FEEDERS Esta seção detalha a maioria dos diferentes tipos de cálculos e mostra como construir o FEEDER acompanhante. Como regra geral, ao escolher um elemento para alimentar um cálculo, escolha o elemento que, quando zero, os resultados dos cálculos também são zero. É importante notar que a maneira como um FEEDER é definido depende do tipo de cálculo. Nesta seção, uma estratégia FEEDER será descrita para cada um dos seguintes tipos de cálculo: Se o cálculo for uma combinação dos itens acima, então uma combinação das estratégias FEEDER apropriadas será necessária para cada componente do cálculo. Como com as regras, existem duas maneiras de definir o FEEDER: 1) ao incluir o nome do membro entre colchetes e 2) usando a função DB (). Há exemplos de ambos em várias das sub-seções a seguir. Multiplicação A multiplicação é o cálculo mais fácil de se alimentar. No exemplo acima, estamos usando A para alimentar o cálculo. Poderíamos também ter escolhido B. Poderíamos ter escolhido um tanto como um zero A ou um zero B forçará o cálculo a ser zero. Para otimizar ainda mais o FEEDER, deve-se escolher o elemento com maior probabilidade de ser zero. Para esclarecer ainda mais este conceito, vamos usar um cálculo de receita típico Neste exemplo, escolheríamos alimentar unidades porque as unidades são mais prováveis ​​de serem zero. Por exemplo, nem todos os clientes irão comprar todos os produtos, então muitas das combinações serão zero. Preço será muito provavelmente não-zero e principalmente fixado para todas as combinações de produto e cliente. Você também pode definir FEEDER usando o formato DB. Definindo regras de cubo a cubo Definindo um condicional ALIMENTADOR Manipulando os ALIMENTADORES para que os elementos de ALIMENTADOR correspondam aos elementos de destino O método de DB fornece mais flexibilidade à medida que você é capaz de incorporar condicional E as funções de regra do IBM Cognos TM1. Consulte as seções subseqüentes para obter mais detalhes e exemplos. Os mesmos princípios discutidos na seção Multiplicação se aplicam à Divisão. Novamente, a escolha de A ou B realmente não importa ao escolher qual item alimentar. Se qualquer item for zero, o resultado do cálculo será zero ou indefinido. Aqui temos que alimentar ambos porque um zero A não forçará necessariamente o cálculo a ser zero. Subtração Como com a adição, temos que alimentar tanto porque um zero A não forçará necessariamente o cálculo a ser zero. Regras Condicionais Para ilustrar isso, escolhemos um exemplo que é comumente usado em aplicações de orçamento ou previsão. No exemplo abaixo (Figura 14), estamos realizando um cálculo apenas para aqueles meses que são sinalizados como meses de previsão (isto é, a partir de maio de 10, os meses de previsão têm um fundo cinza) Figura 14 Mostra os resultados de usar um FEEDER condicional Para os meses de previsão que começam em Maio-10 Para aqueles meses que são sinalizados como reais (neste caso Jan-10 a Apr-10), só queremos carregar ou inserir o resultado do cálculo, observe que os meses de previsão reais Linha EF (For Forecast Months) e meses Jan-10 até Apr-10) têm um fundo branco em suas células, o que significa que essas células podem aceitar valores inseridos manualmente e não são o resultado de um cálculo. O número é estático e não queremos que o sistema o calcule de forma diferente da forma como ele é armazenado no sistema de registro. Neste exemplo, estamos usando um atributo na dimensão de tempo para indicar meses reais ou previstos. É uma vista do Editor de Atributos em que um novo atributo chamado Flag Real foi adicionado e alguns meses específicos (Jan-10 até Apr-10) foram denotados com um A para mostrar quais meses contêm reais. Figura 15 O atributo de dimensão de tempo chamado Real Flag (Texto) com A nos meses indicados como dados reais A regra é definida da seguinte forma: O FEEDER é o seguinte: Regras de cubo para cubo Um exemplo simples é usado abaixo para ilustrar cube - To-cube regra FEEDERS como é mais complexo e introduz mais desafios. Considere os cubos de origem e de destino definidos para o cubo de origem FeederSource. O cubo FeederSource tem duas dimensões FeederSource (com um único item chamado Source) e Value (com um único item chamado Value) e um único valor de dados de 10, como mostrado na Figura 16. Figura 16 Mostra o exemplo FEEDER fonte cubo chamado FeederSource Na Figura 17 abaixo, vemos uma visualização de um cubo do IBM Cognos TM1 chamado FeederTarget mostrando os valores que estão sendo alimentados a partir do cubo de origem chamado FeederSource. O cubo FeederTarget tem duas dimensões FeederTarget (com um único item chamado Target) e Time (com N: itens de nível para cada mês e itens de nível C para consolidações trimestrais Q1-10, Q2-10, etc.) eo nível N: Todos os itens foram preenchidos com o valor do cubo FeederSource de 10. Figura 17 Uma exibição de um cubo de destino do IBM Cognos TM1 incluindo valores carregados usando um FEEDER A razão pela qual os FEEDERS de cubo a cubo são mais complexos é que você define a No cubo de destino eo FEEDER no cubo de origem. Com efeito, o cubo de origem está enviando os FEEDERS para o cubo de Destino ea regra no cubo de destino está recebendo-os. A situação é complicada pelo fato de que as estruturas de dimensão nos cubos de origem e de destino podem ser diferentes. O seguinte exemplo irá percorrer o processo passo a passo: Etapa 1 Definir a regra no cubo de destino Um ponto importante aqui, que não é totalmente destacado no exemplo, é que a função de DB terá uma estrutura de parâmetros que pertence à dimensão Estrutura do cubo de origem (o primeiro parâmetro será o nome do cubo, o segundo a primeira dimensão no cubo de origem, o terceiro, a segunda dimensão no cubo de origem, etc.) No entanto, os valores que você fornecer no parâmetro devem Ser com relação ao cubo alvo ou um valor codificado. Uma vez que este é um ponto tão importante, vamos ilustrá-lo com um sub-exemplo. Suponha que você tenha dois cubos, Cube S e Cube T. Ambos têm estruturas de cubo idênticas com dimensões idênticas, mas as dimensões em cada cubo são uma cópia do outro. Por exemplo, as dimensões no Cubo S são Produto S e Tempo S. As dimensões no Cubo T são Produto T e Tempo T. As duas dimensões do produto são idênticas e as duas dimensões de tempo são idênticas. Em seguida, a regra seria: Observe que as dimensões no cubo de destino são substituídas nos parâmetros da função DB representando a estrutura do cubo de origem. Este é um ponto importante TM1 Desenvolvedores passaram muitas horas olhando para uma regra tentando descobrir por que ele wouldnt salvar Etapa 2 Defina o FEEDER no cubo de origem 2010 É necessário codificar um valor aqui porque não há nenhuma dimensão de tempo No cubo de origem. Por codificação rígida de um elemento de resumo da dimensão de tempo, força o sistema a alimentar todos os N: itens de nível de 2010. Observe que se o cubo de origem tivesse a dimensão de tempo, então o FEEDER seria construído da seguinte maneira: Target É necessário codificar a medida porque existe um nome de elemento de medida diferente na origem e no destino. Precisamos codificá-lo para um elemento na dimensão de medidas de destino. Aqui está o FEEDER para o nosso sub-exemplo: O FEEDER aqui é definido como o inverso da regra. Observe que as dimensões no cubo fonte são substituídas nos parâmetros da função DB representando a estrutura do cubo alvo. Isso pode causar alguns problemas e a lista a seguir foi montada para destacar as práticas recomendadas na criação de cube-to-cube ALIMENTADORES Se a mesma dimensão estiver nos cubos de destino e de origem, use simplesmente DimensionName nesse parâmetro. Se você tiver dimensões diferentes, que são cópias uns dos outros, então você deve usar DimensionNameInSource para esse parâmetro. Se você tiver uma dimensão no destino que não existe na origem, então você precisará codificar um item de resumo na dimensão de destino. No exemplo acima, estamos codificados em 2010. Isso significa que o sistema alimentará automaticamente todas as crianças de 2010. Esse recurso deve ser usado com cautela, pois pode levar a cenários de sobre-alimentação e longos tempos de inicialização do servidor. Se você tiver uma dimensão na origem que não existe no destino, então você precisará codificar um item na dimensão de origem. Se você deseja segmentar um elemento em particular, então apenas hard-code-lo no parâmetro. Por exemplo, a Receita apenas direcionará a medida de receita. Você pode minimizar a necessidade de fazer isso usando os mesmos nomes de medida na origem e destino. Dessa forma, você pode apenas usar TargetMeasureDimName. Os FEEDERS enviados pelo cubo de origem devem corresponder aos elementos do cubo de destino. Isso se aplica a todas as dimensões. Para ilustrar este ponto, considere o seguinte exemplo. Na alimentação de um cubo semanal para um cubo mensal, as semanas não existiam no cubo mensal, então nada foi alimentado. Você pode contornar isso alterando o FEEDER para que os pais da semana passem no FEEDER. Uma vez que os pais de semanas são meses e meses estão presentes no cubo de destino, o FEEDERS vai funcionar como esperado. Cubo a cubo FEEDER avoidance Há ocasiões em que você pode evitar definir o cube-to-cube FEEDER se a medida alvo é usado em um cálculo subseqüente. Na Figura 18, Target é o resultado de um cálculo de cubo para cubo, mas também é usado ainda no cálculo TargetC. O valor para C e Jan-10 é 20. O valor calculado de TargetC para Jan-10 é 200 (Target tem um valor de 10 e C tem um valor de 20.) O cubo do IBM Cognos TM1 está carregando valores com base no seguinte Fórmula FEEDER: Você pode remover a necessidade do FEEDER cubo-para-cubo simplesmente alimentando C da seguinte forma: Figura 18 Mostra o cubo alvo evitando a necessidade de uma definição do FEEDER de cubo fonte usando simplesmente os valores do cubo fonte em um cálculo e alimentando Cálculo dentro do cubo alvo Condicional ALIMENTADORES Você pode usar ALIMENTADORES condicionais para reduzir ou eliminar a sobrealimentação. Normalmente, você usaria um FEEDER condicional para acompanhar uma regra condicional. Para ilustrar o ponto, considere o exemplo de sobrealimentação que discutimos anteriormente: Como discutimos anteriormente, o sistema está ignorando o valor de B quando está construindo o FEEDER. Você pode construir FEEDERS condicionais da seguinte maneira para resolver o problema: Observe que, para alimentar condicionalmente, você precisa usar uma função DB. Nesse caso, você coloca uma instrução IF no parâmetro da função DB que representa o nome do cubo. Retornar o nome do cubo para células que você deseja alimentar e (nulo) para aqueles que você não. Ao olhar para o cubo, vemos agora que não estamos alimentando demais esse cálculo. A Figura 19 é uma vista do cubo OverFeeds mostrando os resultados de Jan-10 e Q1-10 com a sobrealimentação corrigida como ilustrado pelos valores para Q1-10 não tendo quaisquer valores iguais a 2. Figura 19 Não mostra valores iguais a 2 No campo de consolidação Q1-10, o que significa que não há sobrealimentação do cubo IBM Cognos TM1 Quantas vezes os FEEDERS disparam De acordo com as cinco considerações importantes específicas para FEEDERS, FEEDERS de células numéricas disparar apenas uma vez e FEEDERS de células String disparar sempre que a sua Alterações de valor. Isso é importante quando um parâmetro é usado para determinar o local do resultado calculado. Para ilustrar este ponto, a Figura 20 mostra um cubo do IBM Cognos TM1 com o valor de 100 calculado na interseção de Result e Feb-10 em destaque: Figura 20 Um cubo do IBM Cognos TM1 destacando o valor 100 na intersecção de Result e Feb-10 The A regra é definida como: Como você pode ver, estamos usando Value to feed Result em uma regra onde o parâmetro Month está sendo usado para preencher o mês correto na dimensão de tempo. Se alterarmos o parâmetro Mês alterando o campo no cruzamento Mês / Jan-10 de 10 de fevereiro a 10 de março, a célula não será mais alimentada. Isto é ilustrado na Figura 21 em que Q1-10 é zero em vez de 100. Isto é porque o FEEDERS para células numéricas disparar apenas uma vez. A célula Resultado para fevereiro-10 foi alimentada inicialmente, portanto, Feb-10 é a única célula que pode ser alimentada. A solução para isso é alterar o FEEDER para o seguinte: Figura 21 Mostra que a alimentação do cubo com um valor numérico pode resultar em alterações não estão sendo adequadamente refletido Note que estamos agora usando mês em vez de valor para alimentar o cálculo e porque mês é Uma string, isso fará com que o FEEDER disparar cada vez que ele muda. A seguinte exibição de um cubo do IBM Cognos TM1 mostra os resultados corretos para Q1-10 de 100. Figura 22 Mostra que a alimentação do cubo com um valor de seqüência de caracteres exibirá resultados atualizados assim que um campo de dados for alterado Alimentos persistentes Alimen - tadores persistentes foram introduzidos no IBM Cognos TM1 na versão 9.5.1. O valor padrão para esse parâmetro está desativado, mas você pode habilitá-lo usando o parâmetro PersistingOfFEEDERS no arquivo TM1s. cfg. Para habilitar os FEEDERs persistentes e melhorar o tempo de recarga de cubos com FEEDERS na inicialização do TM1 Server, defina o parâmetro PersistingOfFEEDERS como um valor de T (true) para armazenar os FEEDERS calculados em um arquivo FEEDERS. Quando os FEEDERs persistentes estão ativados eo servidor TM1 encontra um arquivo FEEDER persistente, ele carrega os FEEDERS salvos, o que reduz o tempo normalmente usado para recalcular os FEEDERS. Os FEEDERS são salvos quando os dados são salvos ou as regras são editadas. Você não salva os FEEDERS explicitamente. Para instalações com muitos cálculos de FEEDER complexos, persistente FEEDERS e, em seguida, recarregá-los na inicialização do servidor melhorará o desempenho. Para os FEEDERS simples, o tempo necessário para ler FEEDERS do disco pode exceder o tempo para recalcular os FEEDERS, mas a maioria das instalações será beneficiada. É importante estar ciente de que o uso de FEEDERS persistentes aumentará o tamanho do sistema apenas no disco. O tamanho da memória não é afetado pelo uso de FEEDERS persistentes. Você precisa ter cuidado ao desenvolver aplicações usando persistente FEEDERS. Como mencionado anteriormente, o método normal para reavaliar os FEEDERS é reiniciar o TM1 Server. Se, no entanto, você tiver FEEDERS persistentes habilitado, primeiro você precisará executar um processo TM1 TurboIntegrator contendo a seguinte função no prolog: Isso forçará a avaliação FEEDER na inicialização do servidor TM1 em vez de apenas ler o cache persistente FEEDER. Complexo FEEDER Exemplos A seção FEEDER complexo detalha alguns exemplos mais complexos para situações do mundo real. Cubo Detalhe-Resumo de Itens de Linha Um problema comum de modelagem, especialmente com as aplicações de orçamento e planejamento, é vincular um cubo de detalhe de item de linha a um cubo de resumo onde as dimensões são listas de seleção (uma lista específica de itens, como produtos) Cubo de origem e dimensões reais no cubo de destino. Considere o seguinte cubo de entrada chamado LineItemSource, que inclui Item de linha, Descrição, Tempo, Produto e Valor, conforme mostrado na Figura 23. Figura 23 Mostra o cubo de entrada LineItemSource A Figura 24 é uma visualização do cubo de resumo LineItemTarget, que consolida os valores onde As listas de seleção se tornam dimensões (isto é, o tempo agora é colunas eo produto agora é linhas). Este cubo mostra os itens de linha de detalhe, bem como valores de resumo no nível de Produto Total e no nível de Trimestre de Tempo. Figura 24 A exibição do cubo LineItemTarget com dimensões criadas a partir das listas de seleção no cubo LineItemSource Como não é possível modelar esse tipo de estrutura de cubo para transferir diretamente dados de LineItemSource para LineItemTarget, é necessário passar por um cubo intermediário chamado LineItemCalc . A exibição a seguir é o cubo intermediário que contém todas as dimensões de ambos os cubos Item, Produto e Tempo. Figura 25 O cubo intermediário LineItemCalc que contém todas as dimensões de LineItemSource e LineItemTarget As Regras e FEEDERS quase corretas seriam as seguintes: Agora vamos passar pelas regras e FEEDERS um a um e explicar. Primeiro, vamos começar com a regra que converte as listas de seleção em dimensões no cubo LineItemCalc: Os componentes da regra são: Negrito verifique se o nome do elemento da dimensão do produto no cubo LineItemCalc corresponde ao produto inserido no LineItemSource cubo. Observe o uso de como são ambas as strings. Verificação em itálico para ver se o nome do elemento da dimensão de tempo no cubo LineItemCalc corresponde ao mês inserido no cubo LineItemSource. Observe o uso de como são ambas as strings. Negrito Itálico Retorna o valor de Amount do Cubo LineItemSource se VERDADEIRO. Não faça nada se FALSO. Agora, vejamos o FEEDER associado no cubo LineItemSource. Ao analisar uma implementação de projeto inicial, o FEEDER foi definido da seguinte maneira: Ao lembrar uma dica anterior na seção Cubo-to-Cube Rules, se houver uma dimensão no cubo de destino que não esteja na fonte, neste exemplo Product E Time, você pode hard-code um item de resumo para o parâmetro apropriado como mostrado em negrito acima. Embora isso funcione, pode não ser o ideal para todas as situações, pois os volumes de dados podem afetar negativamente os tempos de inicialização do servidor TM1. Isso ocorre porque este tipo de FEEDER resulta em sobrealimentação grave, pois o sistema precisa alimentar cada produto individual e cada mês para cada item individual. Considere alterar o FEEDER para que ele alimente somente o Produto selecionado em qualquer item de linha específico. For example, substitute Total Product with DB(LineItemSource. LineItem, Product) and 2010 with DB(LineItemSource. LineItem, Time) . In making these changes, the system start-up time will be improved. An additional problem with the FEEDER in the LineItemSource cube is that it is feeding only once so it will not continue to work if we change either the product or month data. The solution is to feed the strings, as shown in the following example: In this example, the FEEDER is repeated for each dimension (for both Product and Time). This ensures that the numbers correctly flow when both product and time are changed. So the correct rules and FEEDERS areCognos TM1 Jobs The demand trend of job ads citing Cognos TM1 as a proportion of all IT jobs with a match in the Business Applications category. Cognos TM1 Salary Trend This chart provides the 3-month moving average for salaries quoted in permanent IT jobs citing Cognos TM1 within the UK. Cognos TM1 Salary Histogram This chart provides a salary histogram for IT jobs citing Cognos TM1 over the 3 months to 16 December 2016 within the UK. Cognos TM1 Top 18 Job Locations The table below looks at the demand and provides a guide to the median salaries quoted in IT jobs citing Cognos TM1 within the UK over the 3 months to 16 December 2016. The Rank Change column provides an indication of the change in demand within each location based on the same 3 month period last year. Classifique a mudança no mesmo período Último ano Correspondência Permanent IT Job Ads Salário médio Últimos 3 meses