Arquivo por tag: Universe Designer

mar 22 2012

Informações de Direitos no Universe Design

Hoje falaremos brevemente sobre como visualizarmos os níveis de segurança atribuídos a cada grupo no CMC do SAP BO.

A SAP tem incluído um grupo de usuários do Universo Designer desde a Release 2 (R2 XI). Para trabalharmos com esses grupos é recomendado
atribuirmos um usuário a um ou mais grupos para que se tornem subgrupos do grupo pai. A idéia é que os usuários ou subgrupos criados possam herdar todos os direitos do grupo pai.

Observando recentemente a versão 4.0 do SAP BO verificamos que o mesmo atribui segurança de forma diferente entre as duas ferramentas de camada semântica. Para o Universe Design Tool a SAP utiliza um alto-nível de controle de acesso conforme verificamos na figura abaixo.

Usando o Gerenciador de permissões, podemos analisar e verificar que realmente a ferramenta do Universo nos oferece um controle total aos usuários do projeto.

Observamos também que a nova ferramenta de design atribui direitos avançados, não só controle completo, para o grupo interno de usuários do Universe Designer.

Falaremos com mais detalhes sobre as permissões, grupos de usuários e suas aplicações em artigos futuros.

Até breve.

out 26 2011

Universe Designer – Acessando SAP BW

No artigo de hoje falaremos em como criar uma conexão de Universo SAP BO para acessar uma base BW, algumas características importantes de um universo conectado ao BW, dicas importantes de como otimizar um universo e daremos uma visão geral de como acontece essa integração do SAP BO com o BW.

1 –Acessando SAP BW

Acessar dados do SAP BW com o Business Objects permite oferecer aos usuários uma alternativa ao SAP BEx.

O SAP BEx é, até então, a ferramenta principal oferecida pela SAP para análise de informações armazenadas no Business Warehouse. Há uma carência muito grande dos usuários BW por alternativas mais poderosas, essa foi uma das razões pelas quais houve um interesse em integrar essas duas poderosas ferramentas SAP BO e BW.

O Business Objects integra-se de forma razoável a diversas bases OLAP (Hyperion EssBase, Microsoft SQL Analysis Server, SAP BW), Com a aquisição da Business Objects pela SAP, houve a integração das plataformas beneficiando e satisfazendo ambos os usuários (SAP
BO e BW). Logo, torna-se cada vez mais importante para o consultor que trabalha com SAP BO, capacitar-se em produtos SAP,  principalmente SAP BW.

Instalando SAP Integration KIT:

Através do SAP Integration KIT é que poderemos acessar bases BW, R/3 ou MySAP ERP. Para isso, dois profissionais devem estar envolvidos: o administrador do ambiente SAP B O e um especialista BASIS para realizar as devidas configurações no ambiente SAP.

O SAP Integration KIT trás 7 (sete) transportes, com compatibilidade para os padrões Unicode e ANSI. O utilizá-los com a versão do BASIS 6.20 ou posteriores, devemos adotar o padrão Unicode. Para versões anteriores, devemos optar pelo padrão ANSI.

2 – Criando um universo para acessar o BW

Podemos utilizar um universo para mapear diretamente uma estrutura de um QueryCube ou de um InfoCube.

O processo de criação do universo é automático. As estruturas OLAP são mapeadas como classes, dimensões, métricas e detalhes.

Nenhuma tabela estará disponível no painel de estrutura do Designer.

Os passos para a criação de um universo OLAP que acesse o BW são:

– Criar uma nova conexão apontando para um InfoCube ou um QueryCube.

– Criar o universo a partir da conexão.

– Salvar e exportar o universo.

3 – Criando uma conexão OLAP SAP BW

Siga os procedimentos de criação de uma conexão, e selecione como Midleware “SAP Business Warehouse 3.x”.

Preencha o campo “Name” com um nome único. Abaixo vemos as opções para utilização do Single Sign-on e de Credenciais de banco de dados.

Preencha os campos “Username” e  “Password” respectivamente com o usuário e a senha de acesso ao ambiente SAP.

Selecione o servidor ou digite seu IP no campo “Application Server”.

Preencha os campos “System Number”, “Client” e “Language” com as informações de acesso ao SAP.  Essas informações podem ser obtidas com o especialista BASIS.

Ao clicar em “Next”, será apresentada a janela para explorar os cubos disponíveis.

Existe também a possibilidade de procurar o cubo pelo nome, preenchendo o campo abaixo da lista de cubos e clicando em “Search”.

Na lista de cubos, podemos ver uma sessão chamada “Favorites” (Favoritos). Essa sessão armazena cubos para que sejam acessados rapidamente. Para adicionar um cubo a essa sessão, localize o cubo desejado, clique com o botão direito e selecione a opção “Add to
Favorite”.

Ao encontrar o cubo desejado, selecione-o e clique em “Ok”. Finalize o utilitário de configuração da conexão normalmente.

4 – Criando um universo a partir de uma conexão BW

Inicie a criação de um universo e selecione a conexão OLAP desejada conforme imagem. Clique em “Testar” para validar a conexão.

Clique em “Ok”. O processo de geração do universo é automático, traduzindo as estruturas OLAP para os objetos do universo.

O processo não é interativo, e vai refletir exatamente a estrutura do InfoCube selecionado na conexão, incluindo seus filtros.

Ao final do processo, um universo terá sido criado refletindo a estrutura do InfoCube.

As hierarquias são representadas nas classes e os objetos podem ser renomeados.

Não é possível customizar os objetos do universo. Qualquer alteração deverá ser realizada no InfoCube e o universo ser atualizado para refletir as alterações.

Salve e exporte o universo para que o mesmo esteja disponível no repositório do CMS.

Observação Importante: Para que possamos criar um universo a partir de uma query do BW é necessário que essa consulta esteja com a opção de ter acesso externo para ser usada como BD OLAP habilitada conforme imagem abaixo no BEx  Query Designer do BW.

Ao se trabalhar com universos integrados ao BW nos deparamos com alguns Problemas:

1 – A performance muitas das vezes é baixa, e não há muito o que fazer no universo para melhorá-la. Nesses casos todo o esforço de modelagem e otimização deve estar no nível do InfoCube.

2 – É gerado acoplamento entre o universo e o InfoCube, logo, qualquer alteração no InfoCube afetará o universo.

3 – O universo é pouco flexível. Toda a capacidade de modelagem está centralizada no consultor BW.

5– Resolvendo Problemas com Universos

Nessa sessão falaremos brevemente sobre algumas dicas importantes pra quem trabalha modelando universos e desenvolvendo relatórios e painéis gerenciais com as ferramentas da SAP BO.

– LOOP.

Loop são relacionamentos entre tabelas onde, a partir de outros relacionamentos chegamos à tabela de origem.

Contextos: Podemos resolver o problema do loop definindo contextos que isolem os relacionamentos, porém, às vezes os relacionamentos redundantes podem estar  incluídos no mesmo contexto.

-Isolated Join.

Quando utilizamos contextos em um universo, todas as junções devem participar de pelo menos um contexto. Quando uma junção não faz parte de um contexto, a validação aponta um erro do tipo “Isolated Join”.

Para resolver, basta adicioná-la ao contexto devido, ou caso não seja possível, crie  um contexto exclusivo para adicioná-la.

Aumentando o limite de itens listados na lista de valores.

Por padrão, são listados no máximo 99 valores nas listas de valores. Para aumentar esse número proceda da seguinte maneira:

Como universo aberto, selecione a opção  “Propriedades” no menu “Arquivo”. Clique na aba “Parâmetro”.

– No campo nome, digite “MAX_INLIST_VALUES”, e no campo valor, o valor que você deseja utilizar. Para desligar o limite, informe como valor “-1”. Clique então em “Adicionar”.

– Clique em “Ok” para finalizar a configuração.

– Otimizando consultas.

Eventualmente o SAP BO executa duas consultas no banco de dados para resolver uma consulta do usuário. Para resolver esse problema e melhorar a performance…

– Na aba ”Parâmetro” da tela de “Parâmetros do Universo”, digite no campo “Nome” o valor “JOIN_BY_SQL” e no campo valor “YES”, e clique em “Adicionar”.

AVISO: Essa técnica não garante que o Business Objects consiga resolver qualquer consulta utilizando apenas uma instrução SQL, apenas habilita esse mecanismo para quando for possível.

Utilizando Full Outer Join.

Por questões de desempenho, o BO inibe o uso do recurso Full Outer Join. Para habilitá-lo…

– Na aba ”Parâmetro” da tela de “Parâmetros do Universo”.  Selecione o valor “ANSI92” na lista “Parâmetro”. Os campos “Nome” e “Valor”.  Altere o campo “Valor” para “Yes” e clique em “Substituir”.

AVISO: Essa técnica pode comprometer a performance do universo.

Conclusão:

– É de responsabilidade do consultor manter o universo performático e seguro.

– Saber como modelar um Data Warehouse e entender seu propósito e arquitetura determina o sucesso de um projeto de BI.

– O universo agrega benefícios interessantes, porém, pode comprometer o modelo quando mal utilizado.

– Fique atento para integração com SAP BW. Nem sempre é a solução dos problemas. Eventualmente pode ser mais interessante extrair as informações e armazená-las em um banco transacional por questões de performance
e flexibilidade.

– A documentação oficial do produto e fóruns são bons locais para buscar ajuda na resolução de problemas.

– Entenda os princípios envolvidos nas técnicas. Dominá-los permite combiná-los para obter novos e melhores resultados.

Espero que tenham gostado desse artigo e Até a próxima.

out 04 2011

Modelagem de Universos – Uma visão geral (Parte 02)

No artigo anterior vimos conceitos ligados à modelagem de universos no SAP BO como Contexto e Apelidos (Alias). Hoje vamos falar conceitualmente sobre tabelas derivadas e Hierarquias, conceitos extremamente importantes para que possamos fazer um universo bem modelado.

TABELAS DERIVADAS

Nem sempre é possível deixar o universo resolver os relacionamentos entre as entidades. Algumas vezes é necessário realizar consultas usando a linguagem do SGBD para ganhar performance.

Para manter o universo simples de dar manutenção, podemos utilizar recursos que abstraiam uma grande quantidade de  relacionamentos por uma visão (views), porém, não temos a possibilidade de alterar diretamente o banco de dados.

Tabelas derivadas são artifícios semelhantes a visões (views), porém, definidas no nível de universo.

Problemas Resolvidos com Tabelas Derivadas:

1-  Consultas mais performática, por utilizar instruções de baixo nível para acesso aos dados.

2-  Entidades identificadas mais facilmente.

3- Relacionamentos complexos abstraídos em uma estrutura similar a uma tabela.

Problemas Gerados pelas Tabelas Derivadas:

1- Consultas muito complexas são difíceis de manter, diferente de relacionamentos representados graficamente.

2- O desempenho de tabelas derivadas são inferiores a visões simples (views) ou visões materializadas (materialized views) no banco de dados, pois a consulta será validada e compilada sempre que for necessário.

3- Podem trazer problemas, pois, tratam-se de consultas que serão associadas a outras consultas montadas pelo próprio Business Objects.

HIERARQUIAS

1-  São definidas automaticamente pelo SAP BO, através da ordem em que as dimensões aparecem em uma classe.

2- Nem sempre todos os níveis da hierarquia estão presentes na mesma classe.

3- A hierarquia definida por padrão pelo SAP BO pode conter níveis incorretos.

Benefício do Uso de Hierarquias:

1 – Flexibilidade na definição de hierarquias lógicas.

2- Remoção de níveis indevidos.

3- Possibilidade de definir hierarquias que não estão materializadas em uma dimensão do Data Warehouse.

Problemas no Uso de Hierarquias:

1- Hierarquias definidas nas classes são mais intuitivas.

2- Hierarquias customizadas demandam tempo de manutenção.

Independente do negócio a ser modelado é sempre recomendável conhecermos os recursos que o Universo possui para que tenhamos melhores condições de determinar qual a melhor estratégia para se modelar um DW.

Com isso finalizamos essa parte conceitual sobre modelagem de Universos, espero que tenham gostado.

Até a próxima.

 

out 02 2011

Modelagem de Universos – Uma visão geral (Parte 01)

O objetivo desse artigo é mostrar os principais conceitos ligados à modelagem de um universo, como contexto, Apelido (alias), tabelas derivadas e Hierarquias.
Esses conceitos são importantes, pois através do conhecimento do negócio em que se está modelando, poderemos adotar um ou mais desses recursos disponíveis na ferramenta Universe Designer da SAP BO. Uma boa modelagem é fundamental para que se tenha um projeto de BI consistente, performático e que atenda de forma adequada os requerimentos de uma determinada área de negócio.

Com o Data Warehouse modelado, precisamos construir o universo, com a preocupação de
manter as qualidades, e agregar maiores benefícios onde possível.

Ao longo desse artigo serão apresentados os seguintes conceitos:

1-     Ferramentas para garantir a semântica das consultas: Contexto.

Benefícios: Impedir que o usuário realize consultas fora da semântica do negócio e  casos como produtos cartesianos.

2-     Ferramentas para possibilitar o reuso de entidades: Apelido (Alias).

          Benefícios: Utilizar mais de uma instância da mesma entidade no mesmo universo,  diminuindo o trabalho de modelagem e
manutenção.

3-    Ferramentas para possibilitar a abstração do modelo: Tabelas Derivadas.

        Benefícios: Permitir que consultas sejam realizadas utilizando SQL para prover maior desempenho e flexibilidade.

4-     Ferramentas para possibilitar a customização do modelo: Hierarquias.

       Benefícios: Possibilitar a definição de hierarquias não materializadas.

CONTEXTOS

Contextos permitem definir um conjunto de relacionamentos válidos, refletindo assim a semântica envolvida na análise do negócio e evitando que consultas inválidas e prejudiciais sejam executadas.

Ele também é indicado para modelos onde existem fatos com níveis de detalhes distintos. Isso porque impedirá o relacionamento de métricas com dimensões não relacionadas.

Sem ele, ao gerar uma consulta com dimensões que não se relacionam com as métricas, obteríamos um produto cartesiano.

Problemas Resolvidos com Contextos:

1-     Eliminam-se erros de relacionamentos cíclicos (loop relationships), pois, as entidades do contexto relacionam-se apenas dentro dos limites do contexto.

2-     Eliminam-se problemas de consultas arbitrárias a regras de negócio, orientando o usuário sobre como e o que explorar no modelo.

Não será possível realizar produto cartesiano com entidades de contextos diferentes, no entanto, essa possibilidade ainda existe em entidades do mesmo contexto. Veremos no Short Joins como eliminar essa possibilidade.

APELIDOS (Alias):

Eventualmente precisamos adicionar mais de uma referência à mesma entidade em um modelo,  porém, não podem existir duas entidades com o mesmo nome no universo.

Eventualmente nos deparamos com modelos onde os nomes são complexos e pouco semânticos.

O apelido (alias) é a ferramenta que permite atribuir um novo nome a referência de uma entidade, possibilitando maior clareza no seu nome ou que haja mais de uma referência sua dentro do mesmo universo.

No próximo artigo falaremos conceitualmente sobre tabelas derivadas e Hierarquias.

Até a próxima.

set 24 2011

Universe Designer – Segurança da Informação (Parte 02)

Para finalizarmos o estudo sobre segurança da Informação em universos nessa última parte vamos estudar os Tipos de Autenticações
existentes no Universo e aprender a definir regras de acesso.

Tipos de Autenticação:

Entre eles, os de maior importância são:
 Bases LDAP: Aceita integração com bases LDAP como o Open LDAP.

 Active Directory: Integra a autenticação com o serviço de diretório da Microsoft presente desde o Windows 2000.

 Lotus Dominos: Integra-se com o serviço de diretórios da IBM, o Lotus Dominus.

 SAP: Integra a autenticação com o serviço de gestão de segurança do SAP.

Além dessas integrações, o Business Objects, permite a implementação do esquema de autenticação “Single Sign-on”, onde as credenciais informadas pelo usuário para autenticar-se na sua estação de trabalho são transmitidas para o Business Objects de forma transparente, evitando que seja solicitado para o usuário autenticar-se no repositório do CMS.

Definindo Regras de Acesso aos Objetos do Universo:


Tendo discutido as possibilidades de autenticação oferecidas pelo Business Objects, veremos como definir, em nível de universo, as regras de acesso aos objetos.

O esquema de definição de níveis de acesso no universo garante flexibilidade, pois, permite controlar questões como:

– Controlar o acesso por níveis hierárquicos.

– Controlar o acesso a métricas de informações estratégicas.

– Controlar acesso ao nível de usuários ou grupos.

No menu “Ferramentas”, acesse o sub-menu  “Gerenciar segurança…”, clique na opção “Gerenciar restrições de acesso…” A seguinte tela será apresentada:

Abaixo da lista “Restrições disponíveis”, clique em “Novo”. Será apresentado o seguinte diálogo:

Preencha o campo “Nome da Restrição” com um nome único para a restrição. Clique então na aba “Objetos”.

Clique em adicionar e selecione os objetos que desejar. Após selecionar os objetos desejados, clique em “Ok” para retornar para a tela de “Gerenciamento de restrições de Acesso”.

Agora precisamos associar a restrição que criamos a um grupo de usuários ou a um usuário (o que não é recomendável por tornar a gestão do acesso mais complexa).
Na lista “Grupos e usuários disponíveis, clique em “Adicionar usuário ou grupo”“. A seguinte tela será apresentada:


Os grupos e usuários existentes são apresentados na lista da esquerda. Para selecioná-los, marque os grupos desejados e clique em “>”. Após isso clique em “Ok” para retorna a tela de “Gerenciamento de restrições de acesso”.

Com a restrição desejada marcada na lista a esquerda e os grupos de usuários desejados marcados na lista a direita, clique em “Aplicar”.  O nome da restrição aplicada ao grupo aparecerá na coluna “Restrição” da lista da esquerda. Clique então em “Ok” para salvar as alterações realizadas.

Conclusões sobre Regras de Acesso aos Objetos do Universo:

 Vimos que a modelagem de universos deve também incluir a preocupação com a segurança da informação.

A associação entre as integrações do SAP Business Objects com sistemas de autenticação, o artifício de persistir a política de acesso da origem dos dados e a definição de regras de acesso em nível de universo atribuí flexibilidade, robustez e rapidez no controle da segurança.

As definições de segurança em nível de objetos não são óbvias e precisam estar bem documentadas e atualizadas para permitir a
correta administração do ambiente. Mantenha sempre o administrador do SAP Business Objects e da origem dos dados informado a respeito da utilização de recursos e do aproveitamento das regras de segurança.

Qualquer integração trás acoplamento entre aplicações. Manter uma boa documentação e uma boa comunicação com os envolvidos
evitam problemas.

Espero que tenham gostado desse artigo e que o mesmo passa ser útil para definir regras de acesso e segurança nos objetos relacionados ao Universo.

set 24 2011

Universe Designer – Segurança da Informação (Parte 01)

Nesse artigo vamos tratar de um assunto muito importante para todas as organizações que tem seus dados gerenciais armazenados em um DW Corporativo, que é a questão da segurança das informações acessadas, analisadas, etc.

O foco do nosso estudo de hoje é conhecer alguns conceitos ligados a esse assunto dentro da ferramenta Universe Designer do SAP BO.

O Universo é um participante ativo da estratégia de segurança da informação em uma aplicação de Business Intelligence.

Ao longo desse estudo vamos analisar e entender os seguintes aspectos da segurança da informação ligada ao Universo:

Tipos de Conexão com o Banco de Dados.

Suas características em relação a segurança e desempenho.

Tipos de Autenticação.

Como integrar a autenticação de outras ferramentas ao Universo.

Configuração de Níveis de Acesso aos Objetos do Universo.

Utilizando os recursos de administração do ambiente para limitar o acesso as informações.

1 – Tipos de Conexão com o banco de Dados:

O universo pode-se conectar com um banco de dados de três formas:

1.Segura (Secured). A conexão é gerenciada pelo repositório do CMS e pode ser compartilhadas por diversos universos.

2.Pessoal (Personal). A conexão é armazenada na estação do usuário que a criou e só estará acessível para ele.

3.Compartilhada (Shared). Armazenada na estação do usuário, porém, pode ser utilizada por outros usuários.

A conexão segura é requerida para que o universo seja exportado para o repositório do CMS.

A conexão pessoal é útil para desenvolvimento individual standalone.

Já a conexão compartilhada é bastante útil quando se está no ambiente de desenvolvimento e não se quer comprometer o
ambiente que já está em produção. Todos os usuários de desenvolvimento podem utiliza-la, porém, não poderão exportar o universo.

Configurando conexões seguras:

No menu “Ferramentas”, selecione “Conexões”. Serão apresentadas as conexões existentes. Clique em “Adicionar” para iniciar o
assistente de configuração para uma nova conexão.

Selecione a fonte o SGBD a ser utilizada. Neste momento podemos inclusive configurar conexões com o SAP Business Warehouse, Hyperion Essbase e Teradata.

Preencha os dados da credencial de segurança, ou marque a opção “Usar Credenciais de banco de dados associadas à conta de usuários do SAP Business Objects.”

Essa estratégia permite que sejam utilizadas credenciais individuais para acesso ao banco de dados, transferindo a responsabilidade de controle de acesso para a origem dos dados.

No caso de conexões com o SAP BW, torna-se um recurso bastante interessante para persistir a política de segurança já configurada no ambiente SAP.

Este recurso só está disponível para conexões seguras e precisa da participação do administrador do SAP Business Objects a fim de configurar as credenciais corretamente para cada usuário.

Clicando em “Avançar”, vemos a tela com o resumo das configurações da conexão e a possibilidade de testá-la. Clique em “Avançar”.

Chegamos à tela de parâmetros avançados da conexão. Neste momento temos diversas possibilidades para melhoria de desempenho. Saber usá-las corretamente trará ganhos significativos para projeto.

Parâmetros Avançados da Conexão:

Primeira opção a ser configurada é o comportamento da conexão com relação a manter-se ou não conectada.
Desconectar após cada transação: Lento, pois, cada vez que uma consulta for realizada, será necessária estabelecer uma nova conexão, consumindo tempo.

Manter a conexão ativa durante n minutos: Vem marcada como opção padrão e tem a vantagem de ser encerrada, mesmo que a aplicação aborte de forma anormal.

Manter a conexão ativa durante toda a sessão: Funciona apenas para aplicação Full-Client (Desk-i, Designer, etc.) Mantém-se
ativa enquanto o usuário utilizar a aplicação.

Logo abaixo vemos as opções para a configuração de utilização de memória.

Tamanho do Array Fetch: Informa o número de registros carregados para memória por vez. Significa que, em uma consulta que retorne 100 registros, serão realizadas 10 carregamentos em memória se este parâmetro estiver configurado para 10.

Quanto maior o valor informado, mais rápida será a resposta para a consulta, porém, maior será o consumo de memória no servidor.

Configurá-lo com o valor 1 desabilitará essa função, fazendo com que seja processada linha a linha, tornando a resposta mais lenta. Consultas com campos BLOB desabilitam automaticamente essa função.

Tamanho do Array bind: Define o espaço de memória que será armazenado pelo Connection Server antes de carregar o resultado da consulta em memória.
Quanto maior for o tamanho, maior será a quantidade de dados carregadas por vez, aumentando a performance.
Desconexão do login por tempo: Número de segundos que serão utilizados tentado estabelecer uma conexão antes de notificar o usuário da impossibilidade. Clique em “Avançar”.

Parâmetros Personalizados da Conexão:

Podemos definir parâmetros personalizados para a conexão. As opções são “Binary Slice Size” e “Hints” (apenas para Oracle).
Binary Slice: Define o tamanho da página de informações binárias enviadas para o repositório quando exportamos o universo.

Hint: Permite que sejam utilizados hints (instruções dadas diretamente ao Oracle) em consultas. Alguns hints são:

FIRST_ROWS: Otimiza o tempo de resposta.

RULE: Usa otimização baseada em regras e não em custo.

FULL: Realiza full table scan, ignorando índices.

ROWID: Varre a tabela pelo ROWID.

Concluindo a criação da conexão:

Clique em “Concluir”. O sistema retornará para a tela de “Lista de Conexões”. Clique em “Concluir” novamente para finalizar o processo.
Como vimos, criar devidamente a conexão do universo permite melhorar a performance e aprimorar a segurança das informações.

Caso haja dúvidas na configuração dos parâmetros, utilize os padrões. Eles são dimensionados para funcionar de forma aceitável na maioria dos casos.

Oriente-se sempre com o administrador do Business Objects e do Banco de Dados antes de alterar os parâmetros para evitar impactos  negativos no ambiente.

Espero que tenham gostado dessa primeira parte, na segunda parte concluiremos o estudo de segurança dentro do Universo.

Até breve.

set 20 2011

Função de Projeção

É bem interessante a gente seguir boas práticas no BO, pois ela nos dará boa visão das funções de cada objeto e evitará muitos problemas futuros. Segue uma boa dica com relação a Função de Projeção.

É muito importante, ao incluir qualquer objeto de qualquer tabela, definir sua qualificação, pois é a partir dela que poderemos identificar se poderemos utilizar para agregação ou para navegação, filtrar ou até mesmo para fazer Drill.

Para uma análise multidimensional adequada, podemos classificar o objeto de três formas: Dimensão, Indicador e Informação.

É importante ressaltar que será desta forma que controlaremos o comportamento de cada objeto.

Este artigo terá o foco na classificação do Indicador, pois será a partir dela que falaremos da função de projeção e sobre a diferença entre esta e a agregação do SQL.

Vamos começar a explicar a diferença entre as duas funções, pois assim ficará mais fácil a compreensão da função de projeção.

A função de agregação do SQL faz o mesmo papel do SQL (segue as regras de cada SGBD), ou seja, caso você queira somar todo os valores de venda de um determinado produto, basta você incluir na linha de comando um SUM(indicador) e colocar o GROUP BY. Se eu tiver uma coluna que esteja detalhando todos os meus produtos, eu estarei agrupando pelo nível mais baixo, porém, se eu tiver apenas o produto, os valores serão somados e agrupados por produto.

No caso da Função de Projeção do BO, o resultado é bem parecido, porém estes objetos não são excludentes. Ou seja, caso queira agrupar por uma dimensão, precisarei colocar o SUM no meu objeto (indicador) de qualquer forma.

Cabe ressaltar que a função de projeção serve para controlar o resultado da apresentação em uma tabela e ela é complementar a função de agregação do SQL. Segue o exemplo mostrando que a agregação do SQL poderá ser feita sem que haja uma função de projeção.

No exemplo abaixo mostramos o mesmo indicador com None na função de projeção.

Quando classificamos um objeto como indicador, precisamos decidir o comportamento que daremos a ele na apresentação. Se quisermos o comportamento de mostrar apenas o máximo dos valores ou o somatório dos mesmos, quando temos apenas o produto, precisamos definir também a função de projeção.

Segue um exemplo de um objeto com a função de projeção.

Fizemos um comparativo para mostrar o resultado dos dois indicadores mostrados acima. O primeiro do exemplo é com relação ao objeto com função de projeção definido e o segundo objeto a função de projeção não foi definida (None).

Cabe ressaltar que o default para o Oracle é o SUM e para o BW, Base de Dados Delegado.

Seguem abaixo as opções da função de projeção.
– Banco de Dados Designado;
– Contagem;
– Máx;
– Média;
– Min;
– Nenhum;
– Soma.

OBS: Explicaremos em outro post algumas peculiaridades sobre o Banco de Dados Designado

jul 26 2011

Lista de Valores (List of Values – LOV)

Olá pessoal,

hoje vamos aprofundar no quesito modelagem de universos e o post de hoje é Lista de Valores, o famoso LOV (do inglês, List Of Values).

Quando criamos um objeto do tipo dimensão ou detalhe em um universo, o BO atribui uma lista de valores. Essa lista de valores é uma seleção distinta dos valores da(s) coluna(s) a qual o objeto faz referência e é atribuída na criação do objetos, porém, somente será criada quando este for utilizado em algum critério de seleção pela primeira vez.
Os valores então serão lidos do banco e armazenados em um arquivo .LOV no servidor na mesma pasta do universo.
Uma vez atribuído LOV a objetos que estão agrupados em uma hierarquia, você irá criar uma consulta que transforma um dos objetos em um filtro de consulta.
Prática:
Acesse na barra de ferramentas do Universo do BO a seguinte opção: Ferramentas > Lista de valores > Criar lista de valores em cascata.

Mova os objetos na seqüência hierárquica que você gostaria de apresentar para seu usuário. Não se esqueça de marcar a opção “Exibição Hierárquica”. Após isso, clique em Gerar LOVs.
Salve e exporte o Universo. Teste no WebIntelligence executando qualquer consulta usando esta dimensão em questão.

Construa uma consulta e crie um “prompt” em um dos objetos da LOV em cascata. Por exemplo, no mais inferior na hierarquia, selecione um nome de cliente.

No Web Intelligence aparecerá o “prompt” para selecionar a dimensão em cascata.
• Benefícios:
–Flexibilidade na definição de valores customizáveis para um objeto do universo.
–Melhor desempenho, pois permite que a lista de valores seja carregada apenas uma vez e armazenada em um arquivo para posteriores consultas, diminuindo o acesso ao banco de dados.
 
 
• Problemas:
–Ocupa espaço em disco no servidor.
–Difícil de manter e atualizar, precisando da interação do usuário.
–Pode gerar a falsa impressão de falta de atualização no DW (Data Warehouse).

 

Até a próxima!

jul 17 2011

@Aggregate_Aware

Este função é muito poderosa quando nós temos que ditar as regras do caminho a ser percorrido. Ou seja quando queremos tomar as rédeas da “escolha” de qual medida a ser utilizada e em que situação, a função @Aggregate_Aware é uma ótima opção, porém não faz milagre.

Primeiro de tudo devemos ter em mente que esta função atende muito bem quando estamos utilizando as medidas agregada e atômica, porém nada impede de utilizar com dimensões.

Quando temos duas fatos, uma agregada e outra atômica, com a mesma medida, porém com a granulosidade diferente e queremos disponibilizar apenas uma medida para os usuários , esta é uma ótima oportunidade para utilizar a função @Aggregate_Aware.

Digamos que a minha fato atômica se chame XPTO_AT e a minha fato agregada se chame XPTO_AG e uma das fatos tem dimensões particulares, ou seja, próprias e outras compartilhadas que são comuns as duas (esta diferença é importante para o sucesso da função). Uma observação importante é que ao escrever a função no objeto, devemos escolher sempre a medida mais agregada primeiro, pois é ela que será utilizada caso encontre o cenário “ideal” e depois a medida atômica. Veja o exemplo ao longo do texto.

Seguem alguns exemplos para o cenário ficar mais claro.

Fato XPTO_AT:
Dimensões:
Cidade, Cliente, Tempo

Fato XPTO_AG:
Dimensões:
Tempo

OBS: A diferença está nas dimensões utilizadas em cada fato.

Podemos encontrar a dimensão Tempo nas duas tabelas, porém a fato XPTO_AG tem apenas esta dimensão e, como escolheremos (na sintaxe da função) esta medida primeiro, a ferramenta verificará se este cenário é o ideal. Ou seja, se eu escolhi apenas o tempo e medida na minha consulta, a ferramenta mostrará os dados da fato agregada, porém se eu escolher o tempo, a medida e a cidade, a ferramenta escolherá a fato atômica para mostrar os dados.

Neste caso a sintaxe fica sendo @Aggregate_Aware( XPTO_AG.MEDIDA, XPTO_AT.MEDIDA ).

Após construído este objeto e disponibilizado no universo, teremos que verificar se as tabelas são compatíveis ou não. Cabe ressaltar que os objetos/tabelas deverão ser compatíveis para que esta função dê certo!

Em Tool(Ferramentas) / Aggregate Navigation (Navegação da Agregada) . Segue o exemplo do eFashion.

Encontraremos do nosso lado esquerdo as tabelas do universo e do nosso lado direito os objetos que são compatíveis ou não e os que não forem compatíveis estarão marcados.

Selecione, na parte esquerda, a tabela XPTO_AT e depois verifique se o objeto construído (na parte direita) está compatível com esta tabela. Caso não esteja, retire a marcação.

Selecione, na parte esquerda, a tabela XPTO_AG e depois verifique se o objeto construído (na parte direita) está compatível com esta tabela. Caso não esteja, retire a marcação.

Se preferir poderá utilizar a detecção automática de incompatibilidade dos objetos que geralmente funciona muito bem. Este botão encontra-se no canto inferior esquerdo (Detect Incompatible).

Agora exporte o objeto e teste a nova funcionalidade!