Práticas comprovadas do IBM Cognos: IBM Cognos BI – Melhore o Desempenho do Acesso a Dados Relacionais Interativos

Natureza do Documento: Diretriz, Produto(s): IBM Cognos 8 Framework Manager, IBM Cognos 8 Studios, Área de Interesse: Modelagem, Design de Relatório

Diretrizes e técnicas que podem ajudar a melhorar o desempenho quando os analistas e autores lidam de forma interativa com origem de dados relacionais nos Studios do IBM Cognos BI (Query Studio, Analysis Studio, Report Studio Express).

Introdução

Propósito

Esse documento fornecerá algumas diretrizes e técnicas que podem ajudar a melhorar o desempenho quando os analistas e autores lidam de forma interativa com origens de dados relacionais nos Studios do IBM Cognos BI.

Aplicabilidade

As diretrizes e técnicas nesse documento foram validadas usando:

  • IBM Cognos BI versão 8.4.x e versão 10.1
  • O banco de dados de amostras GS_DB DB2

Exclusões

Esse documento não abrange as origens de dados OLAP.


Visão Geral

No IBM Cognos BI, os autores e analistas têm a oportunidade de trabalhar de forma interativa com origens de dados nos Studios, como no IBM Cognos BI Query Studio, IBM Cognos BI Analysis Studio, IBM Cognos BI Report Studio Express e o novo Business Insight Advanced studio do IBM Cognos 10 (que substituiu o Report Studio Express no IBM Cognos 10). Esses Studios são chamados de Studios interativos, que permitem que o usuário arraste itens de consulta para o relatório, um de cada vez ou vários simultaneamente, para gerar um relatório de forma dinâmica. Para cada um desses gestos o IBM Cognos BI reenvia a consulta para a origem de dados. Ao lidar com origens de dados relacionais, isso pode gerar preocupações sobre os tempos de resposta e as cargas para a origem de dados.

Por exemplo, no Query Studio, é bastante comum para os autores desenvolverem lentamente seus relatórios ao arrastar um item de cada vez. Considere o modelo abaixo.

O diagrama mostra um esquema em estrela simples com uma tabela de fatos no centro e suas dimensões relacionadas, nesse caso, promoções, produtos e tempo.

Agora, considere os conteúdos do pacote conforme eles aparecem no Query Studio.

Os autores podem desenvolver lentamente sua consulta ad hoc ao adicionar o item Year da dimensão de tempo, o que gera uma consulta ao banco de dados.

E segundo lugar, o autor pode adicionar Promotion name a partir da dimensão de promoções.

Nesse momento, duas consultas foram emitidas para o banco de dados e os autores podem observar um atraso no desempenho para obter os resultados. Essas duas dimensões são unidas através da tabela de fatos de vendas. Consequentemente, a consulta pode levar mais tempo do que o esperado, uma vez também está incorporando a tabela de fatos na consulta para produzir os resultados. Em casos em que a tabela de fatos tem um grande volume, milhões ou até mesmo bilhões de linhas, o tempo de espera para o que é considerado uma consulta simples pode levar mais tempo do que o esperado.

Os autores podem, então, continuar a desenvolver suas consultas com um item de cada vez, o que gera uma consulta ao banco de dados por adição.

Esse documento irá discutir algumas técnicas sobre as quais os autores devem estar cientes ao lidar com as origens de dados de forma interativa, assim como irá fornecer algumas soluções que podem ser implementadas por modeladores de metadados ou administradores de relatório para ajudar a fornecer melhores tempos de resposta para consultas potencialmente lentas. .


Filtre Primeiro

Uma opção para os analistas e autores melhorarem o tempo de resposta de consultas interativas é filtrar seus relatórios ou análises primeiro. Isso pode ser feito pela criação de filtros pelos usuários ou imposição aos autores através de filtros implícitos criados no modelo.

No Query Studio, os filtros podem ser adicionados antes de adicionar os itens de consulta ao relatório. Basta clicar com o botão direito no item no qual deseja basear o filtro e selecionar Filter for report.

Aplique todos os filtros desejados ao relatório primeiro e, em seguida, adicione os itens da consulta ao relatório. Isso pode reduzir drasticamente os registros recuperados do banco de dados, uma vez que os itens são adicionados ao relatório.

Para os outros Studios, é possível aplicar filtros de contexto antes de adicionar itens ao relatório ou análises. Esse método se aplica às origens de dados dimensionais apenas como origens OLAP ou origens dimensionally modelled relational (DMR). DMR é o conceito de adicionar informações dimensionais no modelo de Framework Manager para permitir a consulta do estilo OLAP na origem relacional subjacente. Como esse documento é voltado para as origens relacionais, as técnicas a seguir implicam em pacotes DMR, mas também se aplicam a origens de dados OLAP.

No Analysis Studio, clique com o botão direito no item a ser filtrado e clique em Filter as Context (captura de tela à esquerda abaixo) ou arraste o item para a área Context filter (captura de tela à direita abaixo) da análise.

No Report Studio Express ou Business Insight Advanced, os itens podem ser arrastados para a área Context filter para obter os mesmos resultados. A captura de tela abaixo é do Report Studio Express.

O Report Studio Express suporta apenas origens de dados dimensionais, já o Business Insight Advanced suporta origens de dados dimensionais e relacionais. Consequentemente, em relação ao tocante ao Business Insight Advanced, essa técnica se aplica apenas aos pacotes DMR em que as origens de dados relacionais estão envolvidas.


Selecione Vários Itens Simultaneamente

Adicionar mais itens simultaneamente a um relatório ou análise reduzirá a quantidade de consultas enviadas à origem de dados.

Para os relatórios de lista no Query Studio, todos os itens necessários para o relatório podem ser selecionados em conjunto e arrastados para o relatório simultaneamente.

Caso tenha dúvidas sobre todos os itens necessários para o relatório, recomenda-se a adição de mais itens inicialmente e a remoção posterior, uma vez que as consultas são armazenadas em cache. Os resultados em cache podem ser reutilizados, o que reduzirá o tempo de resposta conforme o relatório for editado. No entanto, a adição de novos itens irá requerer uma nova consulta à origem de dados.

No entanto, com Analysis Studio e Report Studio Express, é possível adicionar vários itens às linhas ou colunas simultaneamente, o que ajudará a reduzir as consultas à origem de dados. Porém, diferente dos relatórios de lista, todos os itens de relatório não podem ser adicionados simultaneamente, pois as linhas, colunas e medidas têm suas próprias áreas de lançamento.

No Business Insight Advanced, há a opção de criar listas, tabulações cruzadas e gráficos. O tipo de objeto de relatório com o qual está trabalhando irá determinar o escopo dos itens que podem ser adicionados ao objeto de relatório simultaneamente. Para os gráficos, os dados são recuperados apenas após uma medida ser adicionada ao relatório.


Design com as opções No Data ou Limited Data

Dependendo do Studio interativo, os usuários podem criar sem dados ou dados limitados. A opção de Limited Data no Query Studio foi possibilitada pelos modeladores de metadados que implementam os Filtros de Design, que limitam as linhas recuperadas da origem de dados com base nos filtros. Os Filtros de Design são abordados na próxima seção.

Realizar o design de relatórios sem dados permite aos autores adicionar todos os itens necessários para o relatório antes de enviar uma consulta para a origem de dados. Exatamente da mesma forma que adicionar todos os itens simultaneamente na seção anterior, isso reduz drasticamente as consultas à origem de dados, enquanto oferece aos autores a liberdade de adicionar itens individualmente sem a preocupação com os tempos de espera entre cada adição. Assim que ficarem satisfeitos com o design do relatório, os autores podem visualizá-lo com todos os dados.

No Query Studio as opções são encontradas em Run Report .

O relatório pode ser visualizado com a opção sem dados ou dados limitados. Novamente, os dados limitados serão dados baseados nos Filtros de Design implementados pelo modelador de metadados no Framework Manager. Assim que o design do relatório satisfizer os requisitos, ele pode ser executado com todos os dados.

Ao realizar a visualização com dados limitados, os autores irão observar resumos em branco. A captura de tela abaixo ilustra esse comportamento.

Isso é feito para garantir que os usuários não visualizem esses totais erroneamente como números de negócios verdadeiros. Os números são baseados em um conjunto reduzido de registros restritos pelos filtros de modelo além do controle do usuário.

Observe: O comportamento padrão para trabalhar de forma interativa com a origem de dados pode ser alterado para o Query Studio. As opções Preview with No Data ou Preview with Limited Data podem ser configuradas como o comportamento padrão ao seguir as etapas abaixo.

  1. Pare o servidor IBM Cognos BI.
  2. No servidor IBM Cognos BI, navegue até <Diretório de Instalação do IBM Cognos BI>/templates/ps/async.
  3. Copie o arquivo system.xml.sample existente para system.xml.

    A linha a seguir define o compartimento padrão:
    <param name="limitedDataMode">nodata</param>

    Quando configurado para nodata, o comportamento padrão será visualizar sem dados. Se configurado como partial, como mostrado abaixo, o comportamento padrão será usar os Filtros de Design.
    <param name="limitedDataMode">partial</param>
  4. Modifique a entrada conforme o necessário, salve o arquivo e reinicie o servidor.

Para reverter para o comportamento original, pare o servidor, remova ou renomeie o arquivo system.xml e, em seguida, reinicie o servidor.

No Report Studio Express e Business Insight Advanced, os autores podem trabalhar no Design Mode no menu Visualizações ao selecionar Page Design.

Observe: O comportamento padrão para trabalhar de forma interativa com a origem de dados pode ser alterado para o Report Studio Express e para o Business Insight Advanced. É possível configurar o Preview Mode ou o Design Mode como o comportamento padrão ao seguir as etapas abaixo.

Report Studio Express:

  1. No servidor IBM Cognos BI, navegue até <Diretório de Instalação do IBM Cognos BI>\webcontent\pat\profiles.
  2. Abra a unidade de transferência profile_express.xml em um editor e altere o elemento de XML a seguir de:
    <defaultPageView view="PagePreview"/>
    para
    <defaultPageView view="PageDesign"/>
  3. Salve o arquivo.

Business Insight Advanced:

  1. No servidor IBM Cognos BI, navegue até <Diretório de Instalação do IBM Cognos BI>\webcontent\pat\profiles.
  2. Abra a unidade de transferência Profile_bua_standalone.xml em um editor e altere o elemento de XML a seguir de:
    <setting name="StartPageView" defaultValue="PagePreview"/>
    para
    <setting name="StartPageView" defaultValue="PageDesign"/>
  3. Salve o arquivo.

No Analysis Studio, os autores podem optar por obter os dados factuais posteriormente ao selecionar Get Data Later na pasta Configurações .

Os membros dimensionais ainda são exibidos nas bordas, nesse caso, anos e linhas de produto, mas os dados factuais não são recuperados. Para recuperar os dados factuais, basta clicar no link Get data na área de fatos da análise ou desmarcar a opção Get Data Later em Configurações .

No entanto, essa opção ainda recupera os membros de dimensão nas bordas através de junções com uma tabela de fatos comum. Se o desempenho ainda não for aceitável com o uso do recurso Get Data Later, considere a técnica descrita na seção 8, Crie Assuntos de Consulta Falsos.


Prompts, Filtros de Design e Cálculos Comuns

Os modeladores podem implementar diferentes tipos de filtros de prompt para guiar os autores em direção a consultas mais eficientes, assim como criar Filtros de Design para permitir que os autores trabalhem com um subconjunto de dados menor ao projetar seus relatórios. Ambos os tipos de filtros podem ser úteis com o acesso a dados interativo. Também é possível adicionar cálculos ao modelo para reduzir os gestos nos Studios interativos.

Prompts

Os modeladores podem implementar prompts usando uma sintaxe de prompt simples, como ?Prompt Name? ou ao usar macros de prompt. Os macros de prompt fornecem um grau de controle maior sobre os prompts, mas estão além do escopo desse documento. Consulte o Guia do Usuário do IBM Cognos BI Framework Manager para obter informações detalhadas sobre os macros de prompt.

Um exemplo de implementação de um prompt em um modelo é mostrado abaixo, em que o assunto da consulta de dimensão de tempo tem um filtro adicionado com a sintaxe de prompt.

Os usuários precisarão filtrar seu relatório em um ou mais anos.

Para adicionar um filtro:

  1. Em Project Viewer, clique duas vezes sobre o assunto da consulta para abrir seu diálogo Definition.
  2. Clique na guia Filters e clique no link Incluir no canto inferior direito.
  3. Insira a expressão de filtro desejada e clique em OK.

O filtro é exibido conforme mostrado abaixo. Se as reticências abaixo de Usage forem clicadas (também mostrada abaixo), há três opções entre as quais escolher. O padrão será Always em que o filtro sempre será aplicado. Optional permite os usuários efetuarem o bypass do prompt e o Design Mode Only afeta o teste no Framework Manager e afeta as linhas retornadas ao visualizar os dados limitados no Query Studio. Ele também afeta os relatórios executados no Report Studio, caso eles estejam configurados para serem executados com dados limitados, mas isso está além do escopo desse documento, uma vez que isso não está relacionado ao acesso a dados interativo.

No Query Studio, por exemplo, o prompt aparece assim que um item da dimensão de tempo é adicionado ao relatório.

Os autores são automaticamente obrigados a focar seus relatórios ao fornecer um ou mais anos de dados, em vez de retornar todos por padrão.

Filtros de Design

No Framework Manager, os modeladores também podem aplicar Filtros de Design. Por exemplo, a dimensão promoções pode ser limitada a um número reduzido de dimensões ao aplicar o filtro no campo PROMOTION_KEY.

As propriedades de uso do filtro serão configuradas para Design Mode Only.

Agora, se a opção Preview with Limited Data estiver ativada no Query Studio, como observado abaixo, os autores podem começar a adicionar itens ao relatório com tempos de resposta mais rápidos uma vez que os dados estão filtrados.

As promoções no relatório são filtradas pelo Filtro de Design aplicado no modelo.

Se Preview All Data estiver ativado, então todos os tipos de promoção são retornados no relatório.

Dicas para aplicação dos Filtros de Design

Algumas tabelas de dimensão podem ser bastante grandes e são boas candidatas para os Filtros de Design. No entanto, normalmente são as tabelas de fatos, que são as maiores, que se beneficiarão dos Filtros de Design. As tabelas de fatos podem ser filtradas em uma ou chaves estrangeiras.

Se os Filtros de Design forem aplicados ao assunto de consulta de fato e a quaisquer assuntos de consulta de dimensão, certifique-se de que os filtros sejam o mesmo para o fato e a dimensão relacionada. Caso não sejam, nenhum dado será retornado nos relatórios ao realizar a visualização com dados limitados.

Lembre-se do exemplo PROMOTION_KEY mostrado anteriormente para a dimensão de promoções. Uma vez que a tabela de fatos de vendas é bastante grande, o mesmo filtro deve ser aplicado nela.

As mesmas chaves devem ser usadas, caso contrário não haverá correspondências de registro entre as duas tabelas subjacentes quando elas forem filtradas e nenhum dado será retornado.

Cálculos Comuns

Os modeladores podem adicionar os cálculos comumente usados ao modelo para ajudar os autores a serem mais produtivos enquanto reduz a quantidade de consultas enviadas para o banco de dados. Adicionar os cálculos ao modelo pode reduzir o número de gestos que um autor precisa realizar ao desenvolver um cálculo nos Studios interativos.

Por exemplo, no Query Studio, um autor pode desejar multiplicar a coluna A pela coluna B. Cada uma dessas colunas precisa ser adicionada ao relatório antes de o cálculo poder ser realizado, o que tem o potencial de enviar três consultas distintas para o banco de dados: uma consulta para a coluna A, uma para a coluna B e uma para o cálculo da coluna A multiplicada pela coluna B. Um cálculo de modelo pode reduzir isso a uma consulta.


Forneça Consultas de Ponto de Partida

Os administradores de relatório pode adotar a abordagem de fornecer as análises ou os relatórios de ponto de partida comumente usados para os Studios interativos. Esses relatórios de ponto de partida/análises podem ser adequadamente filtrados para garantir tempos de resposta aceitáveis. Esse recurso isolado ou em conjunto com os prompts e Filtros de Design podem melhorar de maneira drástica os tempos de espera conforme os autores projetam seus relatórios.


Crie Assuntos de Consulta de Fato Falsos

Como mencionado anteriormente, em alguns casos os autores podem desenvolver seus relatórios em um Studio interativo item a item. Eles podem adicionar itens de duas ou mais dimensões antes de adicionar quaisquer itens de uma tabela de fatos comum entre as dimensões.

Por exemplo, eles podem adicionar Year na dimensão de tempo e Promotion Name da dimensão de promoção. O resultado é que as duas dimensões serão unidas através da tabela de fatos de vendas.Se a tabela de fatos for grande em termos de volume, então o tempo de resposta pode ser maior do que o esperado. Os autores achar que esperar por dados factuais de uma tabela grande aceitável, mas podem não entender a razão de uma simples consulta de duas tabelas de dimensão não retornar imediatamente.

Outro efeito colateral desse cenário é que qualquer forma de materialização (agregados pré-calculados) no banco de dados pode ser ignorada uma vez que não há fatos incluídos na consulta. Se a consulta for escrita ao adicionar uma dimensão seguida por um fato e, então, outra dimensão, a otimização do banco de dados deve incluir a materialização conforme o necessário.

Além de algumas diretrizes fornecidas anteriormente nesse documento, os modeladores de metadados podem utilizar uma técnica em que é possível implementar uma tabela de fatos falsa que pode ser uma junção alternativa para uma tabela de fatos grande. A tabela de fatos falsa será usada nas junções em vez da tabela de fatos real, com isso melhorando os tempos de resposta ao realizar consultas apenas nas dimensões.

O resultado final do assunto de consulta de fato falso será a criação de um Produto Cartesiano para as dimensões, que é retornado em um período de tempo mais curto. Enquanto o resultado pode não ser o esperado da perspectiva de dados, essa técnica permite que os autores trabalhem rapidamente com alguma forma de resultado. Os resultados se tornam expressivos assim que itens da tabela de fatos forem adicionados ao relatório. Se isso for aceitável para os usuários e as outras técnicas mencionadas nesse documento não forem opções viáveis ou precisarem ser aumentadas, então essa técnica pode ser considerada.

Como qualquer técnica e implementação, ela deve ser completamente testada e ajustada precisamente até atender os requisitos.

Para implementar um assunto de consulta de fato falso, crie uma tabela de uma linha no banco de dados ou use uma tabela virtual como a SYSDUMMY1 do DB2 ou Dual do Oracle. Nesse exemplo, usaremos a SYSDUMMY1.

  1. No Framework Manager, crie um assunto de consulta de origem de dados e atribua a ela um nome que seja venha alfabeticamente antes da tabela de fatos real que ela visa substituir na dimensão para as consultas de dimensão. A razão para isso é que o caminho da junção usará o assunto de consulta de fato que vem primeiro alfabeticamente. O caminho do relacionamento alfabeticamente na primeira posição é determinado com base nos códigos ASCII dos nomes de assunto de consulta, em que todas as letras minúsculas vêm depois das letras maiúsculas.Nesse exemplo, o nome "A Fake Sales Fact" será usado com a seguinte expressão:

    Selecionar 1 como a Chave de SYSIBM.SYSDUMMY1 retorna uma linha com um valor de 1.

    A sintaxe de amostra para o Oracle seria Select 1 as key from dual. Uma sintaxe de amostra para o SQL Server seria Select 1 as 'Key'. Cada fornecedor terá uma sintaxe brevemente diferente.

    Para alguns fornecedores, como com a Oracle e o SQL Server, a opção SQL Type precisará ser alterada para Native. Essa opção é encontrada ao selecionar a guia Teste na definição de assunto de consulta, clicar em Option no canto inferior direito, a guia SQL Settings e selecionar Native do SQL Type .

  2. Em seguida, crie junções do assunto de consulta de fato falso com as dimensões necessárias. Inicialmente, crie uma junção a partir da chave principal da dimensão para a chave de fato falso.
  3. Clique nas reticências para a expressão de relacionamento e adicione a seguinte lógica à definição de relacionamento.
    1=1

    ou

    [DB2 GOSALESDW].[GO_TIME_DIM].[DAY_KEY]=[DB2GOSALESDW].[A Fake Sales Fact].[Key]
  4. Clique em OK.

    Observe a alteração no diálogo de relacionamento.

    A linha de link não existe mais entre as chaves, uma vez que o relacionamento agora é uma expressão complexa que vai além de vincular itens de um assunto de consulta a outro.

    A lógica 1=1 está na expressão para garantir que a junção sempre seja verdadeira e permitir o conjunto de resultados do produto cartesiano. A junção das chaves nunca será verdadeira nesse caso, mas é necessário uma vez que o IBM Cognos BI requer pelo menos um assunto de consulta para criar uma junção válida.

    Crie esse tipo de junção entre o fato falso e cada dimensão necessária. Nesse exemplo, os resultados aparecem como mostrado abaixo.

Teste os Fatos Falsos

Antes de publicar o pacote no IBM Cognos BI, certifique-se de que o fato falso está incluído no pacote como um objeto oculto. Dessa forma, ele estará disponível para as junções, mas não estará visível para os usuários, o que evitará confusão e desordem.

Publique o pacote no IBM Cognos BI e abra-o no Query Studio. Nesse caso, um item da dimensão de tempo e um da dimensão de promoção serão adicionados ao relatório.

Um Produto Cartesiano é retornado. Esses resultados podem não ser expressivos para o autor até uma medida do fato ser adicionada, uma vez que se trata de uma combinação simples de cada item em uma tabela com cada item na outra tabela. Porém, o tempo de resposta permitirá que os autores trabalhem mais rapidamente.

Assim que um fato é adicionado, os dados fornecem os resultados esperados.

Pode parecer que os dados desaparecem nesse ponto, uma vez que as junções através da tabela de fatos provavelmente são mais esparsas em suas combinações do que os resultados do Produto Cartesiano. Isso pode confundir alguns autores e pode exigir um pouco de estudo.

Considerações sobre Fatos Falsos

Se o modelo de Framework Manager não aplicar uma forma de filtragem nos assuntos de consulta de dimensão, é possível tentar realizar junções de grandes Produtos Cartesianos. Essa operação pode potencialmente falhar ou causar uma sobrecarga significativa no nível do banco de dados ou para as operações do IBM Cognos BI no tempo de execução.

Os seguintes casos em que isso pode ocorrer.

  • Grandes tabelas de dimensões podem produzir junções que utilizam muitos recursos. Por exemplo, 10.000 linhas em uma dimensão multiplicadas por 10.000 linhas em outra produziriam uma junção Cartesiana de 100.000.000 linhas.
  • Combinar três ou mais dimensões em uma consulta sem dados factuais também pode resultar em junções Cartesianas grandes. Mesmo se as dimensões individuais forem relativamente pequenas, a junção Cartesiana cresce exponencialmente com cada adição de uma dimensão. Por exemplo, se a dimensão 1 tiver 500 linhas, a dimensão 2 tiver 600 linhas e a dimensão 3 tiver 1000 linhas, o Produto Cartesiano será igual a 300.000.000 linhas.
  • Em determinados cenários, o IBM Cognos BI desenvolve cubos dinâmicos que são usados como uma origem para os relatórios. Outro potencial efeito colateral com uma junção Cartesiana é a de que a quantidade de dados que é transferida para o cubo dinâmico pode fazer com que o governor de desenvolvimento lance uma exceção (muita memória usada) ou exceda os limites do cubo (número de membros, membros por nível, etc.) que poderia não ocorrer normalmente quando os dados factuais são incluídos, uma vez que eles podem ser esparsos por natureza.

Em qualquer um dos casos, considere incluir uma lógica adicional nas expressões de junção para a tabela de fatos falsa que reduzirá o intervalo de valores da chave de junção que podem ser retornados das tabelas de dimensão.

Por exemplo, na expressão de relacionamento entre a dimensão de tempo e o fato falso, é possível aplicar um filtro para reduzir os registros da dimensão de tempo para apenas alguns dias.

O filtro pode ser customizado de acordo com o que fizer mais sentido para a necessidade de negócios. Talvez o filtro seja para o ano atual, o trimestre atual ou para o mês atual. A filtragem pode ser aplicada a qualquer um dos relacionamentos de dimensão relacionados em que for necessário melhorar o desempenho.

Esse tipo de conjunto de resultados reduzido pode ser comparado à visualização de relatórios com dados limitados. A diferença nesse caso é que a filtragem é feita automaticamente para o autor até os dados factuais serem incluídos no relatório.

Usando o modelo de amostra nesse documento, adicionar itens no Query Studio a partir de todas as três dimensões retorna um conjunto de registros bastante reduzido.

A junção Cartesiana é reduzida pelos filtros encontrados nas expressões de junção de cada dimensão para o fato falso.

Assim que os dados factuais do assunto de consulta dos fatos de vendas são adicionados ao relatório, o relacionamento de junção passa pela tabela de fatos de vendas em vez de passar pela tabela de fatos falsa e os dados são retornados conforme o esperado.

Alternativa ao Método de Fato Falso

Como uma alternativa ao método de fato falso implementado no modelo, e desde que seu DBA não importe, é possível solicitar que uma tabela de fatos sem fatos seja criada no banco de dados contendo apenas combinações de chave estrangeira para todas as dimensões que deseja relacionar na ausência de passar por uma tabela de fatos.

As combinações de chave incluídas nessa tabela seriam as que fazem sentido para os dados de dimensão retornados em um relatório quando não são usados dados factuais reais.

Diferente do método de fato falso, a tabela de fatos sem fatos será importada no modelo, em vez de criá-la. No entanto, da mesma forma que no método de fato falso, você irá assegurar que o assunto de consulta sena nomeado de forma que ele venha alfabeticamente antes da tabela de fatos real e que ela esteja relacionada a todas as dimensões necessárias. Você também incluirá o novo assunto de consulta no pacote e irá configurá-lo como um objeto oculto.


CQEConfig.xml - Desativar a Passagem pelos Assuntos de Consulta de Fato

O IBM Cognos BI pode ser configurado para não passar pelos assuntos de consulta de fato nas consultas apenas de dimensão. Essa configuração é feita no arquivo CQEConfig.xml localizado na pasta <Local de instalação do IBM Cognos BI>/configuration. Por padrão, o arquivo é apenas um arquivo de amostra chamado CQEConfig.xml.sample. As configurações nesse arquivo não são selecionadas quando o IBM Cognos BI é iniciado até o arquivo ser renomeado para CQEConfig.xml.

Para configurar o IBM Cognos BI de forma global para não passar pelo assunto de consulta de fato para as dimensões, apenas consultas, siga essas etapas em cada servidor de relatório do IBM Cognos BI em seu ambiente.

  1. Na pasta <local de instalação do IBM Cognos BI>/configuration, copie o CQEConfig.xml.sample para CQEConfig.xml.
  2. Adicione a seguinte elemento de seção Transformations sob o elemento <component name="CQE"> conforme mostrado abaixo
    		<component name="CQE">		
    			<section name="Transformations">
    				<!--Default: "useAlphabeticalFirstFact"--> 
      			<entry name="dimOnlyQuery" value="useNoFacts" /> 
    			</section>

    A seção comentada (entre as tags <!-- -->) fornece a configuração de valor padrão, useAlphabeticalFirstFact, para a entrada dimOnlyQuery. Essa configuração diz ao IBM Cognos BI para usar a tabela de fatos comum na primeira posição alfabeticamente entre as dimensões em uma consulta de dimensão apenas. O valor useNoFacts diz ao IBM Cognos BI para não passar por uma tabela de fatos comum para consultas de dimensão apenas.
  3. Salve o arquivo e reinicie o serviço do IBM Cognos BI.

Exemplo de useNoFacts

Antes de configurar o arquivo CQEConfig.xml para o useNoFacts, O SQL de uma consulta de dimensão apenas que seleciona Year do assunto de consulta da dimensão de Tempo e Order method do assunto de consulta Order method aparece conforme mostrado abaixo.

Cognos SQL

select distinct 
       GO_TIME_DIM.CURRENT_YEAR  as  Year1,
       SLS_ORDER_METHOD_DIM.ORDER_METHOD_EN  as  Order_method
 from 
       great_outdoors_warehouse..GOSALESDW.GO_TIME_DIM GO_TIME_DIM,
       great_outdoors_warehouse..GOSALESDW.SLS_ORDER_METHOD_DIM SLS_ORDER_METHOD_DIM,
       great_outdoors_warehouse..GOSALESDW.SLS_SALES_FACT SLS_SALES_FACT
 where 
       (SLS_SALES_FACT.ORDER_DAY_KEY = GO_TIME_DIM.DAY_KEY) and 
       (SLS_SALES_FACT.ORDER_METHOD_KEY = SLS_ORDER_METHOD_DIM.ORDER_METHOD_KEY)

SQL Nativo

select distinct "GO_TIME_DIM"."CURRENT_YEAR" AS "Year1",
 "SLS_ORDER_METHOD_DIM"."ORDER_METHOD_EN" AS 
"Order_method"
 from "GOSALESDW"."GO_TIME_DIM" "GO_TIME_DIM", "GOSALESDW"."SLS_ORDER_METHOD_DIM" 
"SLS_ORDER_METHOD_DIM", "GOSALESDW"."SLS_SALES_FACT" "SLS_SALES_FACT"
 where "SLS_SALES_FACT"."ORDER_DAY_KEY" = "GO_TIME_DIM"."DAY_KEY" and 
"SLS_SALES_FACT"."ORDER_METHOD_KEY" = "SLS_ORDER_METHOD_DIM"."ORDER_METHOD_KEY"

Em ambos, Cognos SQL e SQL Nativo, Year e Order method são unidos através da tabela SLS_SALES_FACT.

Após configurar o arquivo CQEConfig.xml para usar o useNoFacts na seção Transformations, o SQL aparece conforme mostrado abaixo.

Cognos SQL

select 
     D2.Year1  as  Year1,
     D3.Order_method  as  Order_method
 from 
     (select 
          GO_TIME_DIM.CURRENT_YEAR as Year1,
          RSUM(1 at GO_TIME_DIM.CURRENT_YEAR
          order by GO_TIME_DIM.CURRENT_YEAR asc local) as 
 sc
      from 
          (select 
               GO_TIME_DIM.CURRENT_YEAR  as  CURRENT_YEAR
           from 
               great_outdoors_warehouse..GOSALESDW.GO_TIME_DIM GO_TIME_DIM
           group by 
               GO_TIME_DIM.CURRENT_YEAR
          ) GO_TIME_DIM
      group by 
          GO_TIME_DIM.CURRENT_YEAR
      order by 
          Year1 asc
     ) D2
      full outer join 
     (select 
          SLS_ORDER_METHOD_DIM.ORDER_METHOD_EN  as  Order_method,
          RSUM(1  at SLS_ORDER_METHOD_DIM.ORDER_METHOD_EN  order by 
SLS_ORDER_METHOD_DIM.ORDER_METHOD_EN asc  local)  as  sc
      from 
          great_outdoors_warehouse..GOSALESDW.SLS_ORDER_METHOD_DIM SLS_ORDER_METHOD_DIM
      group by 
          SLS_ORDER_METHOD_DIM.ORDER_METHOD_EN
      order by 
          Order_method asc
     ) D3
      on (D2.sc = D3.sc)

SQL Nativo

select "GO_TIME_DIM"."CURRENT_YEAR" AS "CURRENT_YEAR"
 from "GOSALESDW"."GO_TIME_DIM" "GO_TIME_DIM"
 group by "GO_TIME_DIM"."CURRENT_YEAR"
 order by 1 asc 

select "SLS_ORDER_METHOD_DIM"."ORDER_METHOD_EN" AS "C0"
 from "GOSALESDW"."SLS_ORDER_METHOD_DIM" "SLS_ORDER_METHOD_DIM"

Você notará que há duas subconsultas no Cognos SQL, uma para Year e outra para Order method. Há também uma junção externa integral entre essas duas subconsultas baseada em uma coluna chamada sc. A coluna sc é um alias para uma coluna que é usada para unir as duas subconsultas. Em outras palavras, ela é uma coluna de união (stitch column (sc)). Isso permite que o conjunto de registros completo seja recuperado para Year e Order method e, em seguida, unidos na coluna sc, que é apenas contagem corrente (1, 2, 3, 4, etc.). Se um conjunto de registros tiver mais linhas do que o outro, os dados nessa coluna continuarão enquanto serão exibidos espaços em branco para a outra, como visto abaixo.

Essa união é feita de forma local nesse caso e pode ser determinada ao examinar o SQL Nativo. O SQL Nativo trata-se apenas de duas instruções de seleção separadas, uma para Year (CURRENT_YEAR na tabela real) e uma para Order method (ORDER_METHOD_EN na tabela real).

Apesar de essa configuração global poder evitar a passagem por tabelas de fatos bastante grandes e melhorar o desempenho em muitos casos, é possível encontrar cenários em que as tabelas de dimensão também são bastante grandes. Nesses casos, lembre-se de que o processamento local de uma junção externa integral também pode impactar no desempenho. Novamente, algumas formas de filtragem das tabelas de dimensão (discutidas anteriormente nesse documento) podem ajudar a suavizar as preocupações sobre desempenho.


Conclusão

Para usuários vivenciando tempos de resposta lentos nos Studios interativos do IBM Cognos BI com origens de dados relacionais, o uso de qualquer técnica ou uma combinação das técnicas e diretrizes descritas nesse documento pode melhorar a experiência do usuário final. Assim como com qualquer implementação, os requisitos devem ter o escopo definido antes de decidir sobre uma estratégia, seguido por testes completos. O teste deve ser realizado em todos os Studios que se aplicam ao ambiente.

Comentários

developerWorks: Conecte-se

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


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

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

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management
ArticleID=935672
ArticleTitle=Práticas comprovadas do IBM Cognos: IBM Cognos BI – Melhore o Desempenho do Acesso a Dados Relacionais Interativos
publish-date=07082013