Cognos Determinants

Como eu havia prometido mes passado, vou fazer uma explicação de como é e pra quê serve esse trem,

Pela pela IBM:

Determinant é um modo de prover controle sobre granularidade.
Quando utilizar:

• Joins in multiplos níveis de granularidade em uma única query.
  Um exemplo bastante comum é o de uma Dimensão de Tempo. As vezes precisamos fazer joins com fatos em nível dia e outras em nível mês. Joins em níveis multiplos podem gerar informações duplicada, pois no caso de dia e mês a informações de mês se repetirá para cada dia deste.
• Campos BLOB em query.
  Consultas sobre campos BLOB necessitam de informações que pode ser adicionadas nos determinants.

Exemplo:

Ano	Mes	Dia	Data
2011	05	2011-05-01	1 de Maio de 2011
2011	05	2011-05-02	2 de Maio de 2011

Vamos supor que preciso trazer informações da Fato Notas Fiscal, que é diária, nesse caso meu join seria pela  própria data ou ID da dimensão.

Numa segunda consulta preciso trazer informações da Fato de Orçamento, está é mensal, logo esse join seria por Ano + Mes.

Agora vamos imaginar o caso real, preciso ver se minhas vendas estão atingindo as metas de orçamento, logo vou juntar duas fatos numa consulta, mas cada uma tem uma nivel de granulariade diferente, como impedir a duplicação dos dados?

Podemos criar os seguintes determinants.

Name	Key	Attributes	Uniquely Identified	Group By
Ano	Ano	Nenhum	Não	Sim
Mes	Ano, Mes	Nenhum	Não	Sim
Dia	Dia	Data	Sim	Não

*É importante lembrar que para os determinantes funcionarem é preciso ter um join nos campos deste.

Então temos 3 determinants, um para cada nível da dimensão. Não é necessário criar um determinante para cada nível das dimensões, apenas para os que fazem joins.

Repare que no nível mês, não temos um campo que identifica os registros unicamente, então temos que colocar o Ano e Mês como chave.

Na prática o determinante criará um uma sub-consulta na dimensão agrupando os dados pelos campos chave e utilizando a função MIN nos campos atributos.

Isso reolve o problema.

Como sempre, em caso de dúvidas, e-mail.!!

Dica da semana

Relatório lento? DMR, Relacional ou OLAP?

- DMR
Coisa feia.. mas funciona basicamente como um cubo, tanto que MDX funciona.
Se seu relatório é em DMR e está lento, procure verificar o tamanho das tabelas envolvidas, esse modo foi desenvolvido para tratar de tabelas pequenas, agregadas, em tabelas muito grandes considere a abordagem normal.

- Relacional
Ai o bixo pega, pois podem ser muitos fatores, creio que os mais comuns são falta de índices e utilização de funções de aplicação logo de cara.
Sempre que for fazer um relatório, leve para a query somente o que for estar visível ou necessário para agregações, tenha certeza de que os relacionamentos estão bem feitos e analise a query para conferir.
Faça uma consulta paralela ao banco e compare os tempos do relatório e do banco, não pode ser muito diferente.
Funções como total( ... for) dificilmente são aplicadas no banco, e são geralmente tratadas na aplicação(servidor cognos), se forem utilizadas na primeira query farão um belo estrago, trazendo muito mais informação do que o necessário para só depois agregar, nesse caso, faça subqueries e só utilize essas funções depois que o nível de agregação do banco já foi feito.

- OLAP(Cubos)
Isso serve para todos os cubos MSAS, PowerCube, etc
Não faça detail filters, pois funciona como funções de aplicação, que antes de filtrar trazem todos os dados do cubo, e isso pesa pacas!!
Utilize slicers(filtros de contexto) e a função filter, que são muito mais performáticas.

Dúvidas? E-mail me!