Arquivo da categoria ‘Modelagem de Dados’

Olá pessoal, vamos retomar o assunto segurança no OBIEE, mais especificamente segurança em nível de coluna e filtro de dados.

 A segurança em nível de coluna ou pasta permite controlar a sua visibilidade, é implementada na camada de apresentação, ocultando os objetos para um determinado grupo de usuários.

 Já o Filtro de dados (Data Filter), já falamos dele neste blog, é implementado direto no grupo associado ao usuário, através de uma cláusula SQL .

 No nosso exemplo o usuário do grupo de Gerentes tem permissão para ver o total de vendas e o total de custos por cidade e regiões geográficas  já os vendedores devem ver o somente o total de vendas e apenas a cidade que ele representa.

 O usuário bieeuser1 que esta associado ao perfil de Gerentes construiu um relatório onde apresenta o total de vendas e custos variáveis por cidade e região geográfica e deseja publicar este relatório para todos os seus vendedores.

 A coluna de custos variáveis “10- Variable Costs” e a coluna Região “R50 Region” não deve ser visualizada pelo vendedor.

O usuário bieeuser2 esta associado ao perfil Vendedores e deve visualizar o mesmo relatório apenas para a cidade que ele representa, Bueno Aires.

 O resultado apresentado abaixo será para o Gerente:


O resultado apresentado abaixo será para o Vendedor:

Vamos iniciar implementando a segurança do filtro de dados (Data Filter) no OBIEE:

 1 – Para isto criamos uma tabela de controle de acesso onde é possivel definir o usuário, o grupo do usuário, a dimensão e o valor que será filtrado. Esta estrutura de tabela torna flexível a inclusão de futuros filtros de dados para outros usuários e outras dimensões.

 

 No nosso exemplo o usuário bieeuser2 receberá o filtro “Bueno Aires” para a dimensão City.

 2 – No OBIEE, vamos criar um bloco de inicialização buscando o valor desta tabela onde o grupo é o de Vendedores e o usuário será igual ao usuário que estiver logado na sessão.

 

 O login do usuário é pego através da variável de sessão USER.

 3 – A variável V_CIDADE será populado pelos valores retornados no bloco de inicialização que é marcado para ser sempre requerida durante a autenticação do usuário na aplicação.



ideia aqui é utilizar esta variável nos filtros de dados.

Salve tudo.

4 – Agora vamos incluir o filtro de dados no Grupo de Vendedores, acessando o Gerenciador de Identidades e click na role BI_Vendedores.


No nosso exemplo o único usuário associado a esta role é o usuário bieeuser2.

 Click em Permissões.

 

 5 – Click no sinal de “+” para adicionar um novo data filter e vamos selecionar a tabela de apresentação “Ship to Regions”.

 

 Click em editar expressão.

 

 A tabela será filtrado somente para a cidade que retornar na variável.

 

Bom agora vamos implementar a segurança em nível de coluna, no nosso caso os campos “10- Variable Costs” e “R50 Region” não devem ser apresentados para os Vendedores.

1 – Selecione as propriedades dos campos onde é necessário aplicar a restrição de acesso.

2 – Click em Permissões:

3 – Para o grupo de Vendedores marcamos para a role BI_Vendedores sem acesso.

4 – No arquivo de configuração NQSConfig.ini mude o parâmetro PROJECT_INACCESSIBLE_COLUMN_AS_NULL para YES, está sob a seção de segurança. Por padrão é definido como NO. Reinicie os serviços.

Este parâmetro permite que mesmo não tendo acesso as colunas o usuário consiga visualizar um relatório previamente construído com estas coluna.

Para o usuário que tem restrição, estas colunas também ficam ocultas no relatório

5 – O usuário bieeuser1 que esta no grupo de Gerentes consegue visualizar o campo “10-Variable Costs” e “R50 Region” na camada de apresentação e consegue utilizá-loa em qualquer relatório. Alem de visualizar os dado de todas as cidades.


6 – Já o usuário bieeuser2 que esta no grupo de Vendedores não consegue visualizar o campo “10-Variable Costs” e o campo “R50 Region” e acessa apenas a cidade que ele representa “Buenos Aires”.


Portanto, o relatório é apresentado para o vendedor ocultando as colunas que ele não tem acesso, alem de ver apenas as vendas de cidade que ele representa.

Bom pessoal, lembrando que este exemplo não esgota o assunto segurança no OBIEE, mesmo porque em cada cliente existe um cenário e necessidades diferentes.

A versão que utilizamos aqui do OBIEE foi a 11.1.1.5.5

Até a próxima.

Alan Viegas

Fala Galera, tudo bom???

Gostaria primeiramente de desejar um ótimo 2013 a todos!!!!

Hoje estou aqui para falar sobre hierarquias do tipo pai-filho.

Este tipo de hierarquia se difere da baseada em nível pelo fato dos níveis não estarem dispostos em colunas separadas (níveis fixos), todos os níveis tem o mesmo tipo e estão dispostos em uma mesma coluna e seus níveis são definidos em tempo de execução.

Para a realização deste “LAB”, utilizaremos o modelo físico a seguir:

No modelo acima, minha dimensão de Classe possui uma hierarquia do tipo pai-filho definida pelas colunas SK_CLASSE (membros da hierarquia) e SK_CLASSE_PAI (definição nos níveis), utilizaremos estas 2 colunas para gerar a hierarquia.

Após todo o mapeamento pronto, clique sob a tabela lógica “DM Classe 1g” com o direito do mouse e crie uma dimensão lógica do tipo pai-fiho como exibido na imagem abaixo:

Passo-a-passo para configuração da hierarquia

1 – Defina o nome da sua hierarquia , qual coluna contém os membros (Member key) dessa hierarquia e qual coluna contém os níveis (Parent Column);

Obs.: por default o OBI preenche o seu member key com a chave primária da tabela de dimensão.

Caso queira alterá-lo, basta clica r em procurar a direita do campo “Member Key”.

E nessa nova tela, selecionar a chave desejada.

2 – Definir a coluna com a informação dos níveis

No nosso caso, a coluna que contém a informação dos níveis é a SK_CLASSE_PAI, para defini-la, clique em procurar a direita de Parent Column e selecione a coluna SK_CLASSE_PAI.

.

3 – Definição da Tabela de relacionamento pai-filho

A tabela de relacionamento pai-filho serve para resolver dinamicamente os níveis de sua hierarquia

Clique em configuração pai-filho.

Clique em criar uma nova tabela de relacionamento pai-filho.

Neste primeiro passo de definição da tabela de relacionamento pai-filho, vamos informar o nome e local para os scripts de criação e população desta tabela e após isso clique em “próximo”.

Informe o nome que terá a sua tabela de relacionamento, tanto no banco de dados como em seu repositório e clique em “próximo”.

Após essa definição, o OBI gera os scripts que deverão ser executados no banco de dados. Você pode visualiza-los no diretório de destino que informou acima ou clicando em “Exibir Script” como demonstrado abaixo.

Clique em “finalizar”.

Após a definição da tabela de relacionamento pai-filho, verifique se as colunas desta tabela foram referenciadas de forma correta.

Por padrão estas colunas são definidas da seguinte forma

MEMBER KEY – Chave do membro da hierarquia

ANCESTOR_KEY – Nível pai do membro da hierarquia

DISTANCE – Distância entre o membro da hierarquia e o membro pai

IS_LEAF – Flag que identifica se o membro é o ultimo nível da hierarquia

Clique em OK para concluir a criação da hierarquia.

Após a criação da hierarquia do tipo pai-filho, você poderá visualiza-la na camada lógica do seu repositório.

Confira também se sua tabela de relacionamento pai-filho foi criada na camada física como mostrado abaixo.

4 – Após a criação de sua hierarquia precisamos alterar o modelo para fazer a inclusão da tabela de relacionamento pai-filho

Selecione na camada física a dimensão de classe já existente, a tabela de relacionamento pai-filho que acabamos de criar, a tabela de fatos utilizada e exiba os relacionamento entre estas 3 tabelas.

Note que a tabela que acabamos de criar não está ligada a nenhuma outra tabela.

Precisamos então deletar a junção direta entre a dimensão de classe e a tabela de fatos e posicionar a tabela de relacionamento pai-filho entre as 2 outras

.

Crie agora um relacionamento entre a tabela de relacionamento pai-filho e a tabela de fatos utilizando a chave do membro da hierarquia e um relacionamento entre a tabela de dimensão e a tabela de relacionamento pai-filho utilizando a chave do pai do membro (ANCESTOR_KEY) de sua hierarquia como nas imagens abaixo:

.

Após realizado os joins, o relacionamento entre estas 3 tabelas deverá ficar como apresentado abaixo:

.

Após a conclusão das alterações na camada física, precisamos adicionar na LTS (Logical Table Source) de nossa tabela de dimensões a nossa tabela de relacionamento pai-filho.

Para isso, na camada lógica, expanda o source da tabela de dimensão DM Classe 1g e clique 2 vezes sobre a origem dela para editá-la.

Clique em adicionar uma tabela física a origem lógica

E, em seguida, selecione a tabela de relacionamento pai-filho que acabamos de criar

Clique em OK para finalizarmos os ajustes de modelo.

5 – Criação e carga da tabela de relacionamento pai-filho no banco de dados

Após os ajustes no modelo, temos que criar e popular nossa tabela de relacionamento pai-filho no banco de dados.

Execute primeiramente o script de criação da tabela, como segue abaixo.

Após a criação da tabela, execute o script de carga como segue abaixo

Obs.: a tabela deve ser criada no mesmo schema de banco usando no connection pool do seu modelo.

6 – Validação do Procedimento

Após disponibilizar nossa dimensão (hierarquia pai-filho) na camada de apresentação para que possamos utilizar o objeto em reports, prompts e etc, entre no OBI e renove os metadados

Se o procedimento foi executado com sucesso, poderemos então visualizar a hierarquia criada

Abraços

Felipe Idalgo

 

banner_treinamento

O Oracle BI Server é um gerador de consultas SQL’s e o sucesso de um projeto de OBIEE depende muito do retorno destas consultas físicas executadas diretamente no banco.

A consulta SQL retorna o resultado corretamente e no menor tempo possível?

Os usuários finais não veem os SQL’s físicos, e nem devem ver, porem muitas vezes, os próprios desenvolvedores também não dão a devida atenção para elas tambem, acreditam não poder interferir, “o produto gera automaticamente estas SQL’s, não podem ser modificadas”. Isto não é verdade.

A qualidade destas SQL’s físicas é talvez, a questão mais importante de um projeto OBIEE, o desempenho deve ser sempre prioridade, mesmo que a apresentação seja prejudicada por isto.

Aceitar sacrifícios na apresentação da informação em prol ao desempenho durante o início do projeto é mais fácil do que depois, quando os gráficos e dashboards já estão sendo apresentados para o usuário e por causa de problemas de desempenho ser necessário alterá-los.

Os objetivos desde o início, devem ser a busca por resultados corretos, rápidos e fáceis de acessar.

Resultados corretos parecem óbvios, mas muitas vezes ignorados, usuários finais podem obter resultados errados por anos sem perceber nada. A análise das consultas SQL’s físicas podem identificar este tipo de problemas, como filtros ausentes, ou em excesso, tabelas indevidas incluídas nas análises, etc.

Resultados rápidos muitas vezes, não é o foco dos desenvolvedores no inicio do projeto. As expectativas dos usuários não são claras quanto ao desempenho, querem algo “aceitável”. A preocupação com desempenho só ocorre no final ou quando os problemas estão estourando em produção. É inútil ter um dashboard esteticamente bem apresentado se cada clique leva 2 minutos para retornar a informação.

Resultados fáceis ou facilidade na navegação e na construção das análises é o foco principal de todos no inicio do projeto (usuários e desenvolvedores) e é muitas vezes a principal causa dos problemas. O impacto sobre o desempenho deve ser sempre avaliado quando se discute com os usuários a apresentação das informações.

Vou demonstrar como visualizar a SQL física de uma determinada análise feita no OBIEE.

Vamos identificar a SQL Física da análise abaixo:

UNMyxx4GdIrycFHXVEO5P2ER_uR4nO1idE_WamCEROTt6csutbNdt9S-Y_wLQJRwgY8Rg2Pt3kuCDJOtJbd56DKWoY5NYVV6k9quj57dBr2wghZDuUk

Primeiramente capturamos a SQL Lógica, através da aba Avançado.

UIO4Zd3cp4E3FRVzEq-ifVVmVGLnWHtBjonG56dUST8QyxpD6sgUqpMw1aYeMAlF-r8UfSn5JjTTzMpG8-EAoSww0nr9zmfBJSwf9OC1yVeeIZTgR6Q

Cclick em Administração > Emitir SQL.

n2gdVsr7A9fvFykESssXMyNNsTiRv_tYGDbSZ67o9HzKxjeC3ZAg3TVvuxpdE967O2jntugFlFEpm1C83RmTlgijZU67n7IShjRte3YiobOnA-dP-xc

Cole a SQL Lógica aqui, desmarque a utilização de Cache e click em Emitir SQL.

o-tUwd3iv4zd1HOuk5WdQpOcKW7y08Qf9RJOwT2RIUQXE5_0SXEDYY_lcmEX9qLt8rNqVXEirV3Ehg7ETR4DOw1Dxy5hcHF8smT0F-El-MUofKaq258

O resultado será uma lista com os dados resultantes da consulta e no final um botão para verificar o log.

Este log é apresentado a seguir.

Abs.

Alan Viegas

 

banner_treinamento

Fala Galerinha do Mal..rsss, uma amiga hoje me acionou com uma dúvida sobre a possibilidade de se alterar o formato (orientação) de exportação PDF de um relatório de retrato para paisagem.

Montei um passo-a-passo bem simplificado de como fazer isso.

*** essa configuração é válida para toda página (aba).

1 – Edite o dashboard e navegue até a página que quer fazer a configuração;

2 – Clique em ferramentas na parte superior direita da página e após em “PDF e propriedade de impressão”;

3 – Nesta tela você tem as configurações disponíveis para impressão e exportação de relatórios PDF como descrito abaixo da imagem

Configurações da Página

– Tamanho do Papel (define o tamanho do papel utilizado na impressora)

– Orientação (define o formato da impressão)

– Imprimir linhas (define se serão impressas somente linhas exibidas no relatório ou se serão impressas todas as linhas)

– Ocultar Margens (oculta as margens da impressão)

Cabeçalho e Rodapé

– Incluir Cabeçalho (exibe informações definidas no cabeçalho com possíveis customiação)

– Incluir Rodapé (exibe informações definidas no rodapé com possíveis customiação)

4 – Para definir o tipo de impressão/exportação PDF como paisagem, basta definir o campo “orientação” como paisagem;

E… Bom Proveito…

Abraços,

Felipe Idalgo

Fala Pessoal, tudo certinho???

Vamos falar hoje sobre uma das formas de se implementar o ROW LEVEL SECURITY com uma tabela de permissões.

Para este exemplo utilizaremos uma tabela de cadastro de usuário contendo as informações de acesso, ou seja, qual usuário tem acesso a quais informações. Essa segurança pode ser implementada através de tabelas já armazenadas no banco de dados, servidor de usuários (AD por exemplo), até mesmo uma planilha Excel.

E… VAMOS LÁ!!! Passos para a implementação da segurança em nível de dados

*** Lembrando que isso é possível de diversar maneiras

1 – Criar uma tabela de usuário e permissões de acesso;

De acordo com o exemplo abaixo, o usuário weblogic tem acesso as informações dos usuários 1 e 2.

2 – Fazer o join da tabela de acessos com o modelo que deverá ser filtrado;

No exemplo abaixo, temos a tabela FATO_VENDAS, com informações de vendas por região e por usuário (vendedor).

.

Precisamos agora fazer o filtro dos dados através do usuário conectado no ambiente.

A regra de acesso aos dados será montada de acordo com o perfil do usuário que se conectou na aplicação, usaremos o grupo BIAdministrator para ilustrar os usuários internos (tem acesso a todas as informações) e o grupo BIConsumer para ilustrar os usuários externos (usuários que terão o filtro de dados aplicado).

3 – Vá no menu principal em Gerenciar > Identidade;

4 – Edite as propriedades do grupo BIConsumer com um clique-duplo;

5 – Clique em “Permissões…” e após na aba filtro de dados;

6 – Adicione um novo filtro na área de negócios e tabela desejada;

.

*** Utilizamos acima a variável USER. Ela é uma variável de sessão que retorna o usuário que se conectou na aplicação.
`

Após essa configuração, todos os usuários do grupo BIConsumer terão esse filtro adicionado implicitamente em suas consultas, ou seja, o usuário só enxergará o que foi lhe dado acesso previamente na tabela de controle.

Espero que tenham gostado!!! Deixem suas dúvidas, sugestões e etc e…. não se esqueçam de SEGUIR O NOSSO BLOG!!!!

Abraços,
Felipe Idalgo

Modelos dimensionais (star and snowflake schemas) normalmente funciona bem para a modelagem da maioria dos projetos de datamart e business intelligence, onde há relações um-para-muitos entre as tabelas de dimensão e as tabelas de fatos.

No entanto, às vezes é necessário modelar uma estrutura muitos-para-muitos entre as tabelas de dimensão e tabelas de fatos. Por exemplo, um funcionário de uma empresa pode pertencer a vários departamentos, e o mesmo departamento pode ser ocupado por vários funcionários.

Diante deste tipo de situação, você precisa modelar uma estrutura muitos-para-muitos entre as tabelas de dimensão e tabelas de fato. Porem como a maioria dos banco de dados suportam apenas relacionamentos um-para-muitos, é necessário implementar este tipo de relacionamento fisicamente através de uma tabela de junção (tabela Ponte ou Bridge) com dois relacionamento um-para-muitos.

Este tipo de projeto pode criar mais registros na tabela Ponte do que na tabela Fato. Você pode limitar o número de registros na tabela Ponte predefinindo grupos e forçando cada registro da Fato caber em um desses grupos predefinidos.

Veja o modelo físico abaixo considerando a tabela fato HORAS_TRABALHADAS:

Figura 1:

Neste exemplo a Dimensão funcionários pode estar relacionada a um ou mais departamentos e a dimensão departamentos pode ter um ou mais funcionários. A tabela “Ponte“ pode ter múltiplas linhas relacionando as duas dimensões.

Configurando a Logical Table Source (LTS)

Após arrastar as tabelas físicas para a camada lógica é necessário integrar na dimensão Funcionários as tabelas ponte e Departamentos. Abrindo as propriedades da LTS na aba General click, em adicionar e selecione as demais tabelas a partir do modelo físico.

Após importar, basta definir o tipo de join que será aplicado entre as tabelas.

No modelo lógico abaixo a Dimensão Funcionários esta ligada a Fato Horas Trabalhadas e todos os atributos de Departamento também fazem parte de Funcionários.

Ao criar a hierarquia para a Dimensão Funcionários, é possível definir Funcionários como menor nível de detalhe e Departamentos um nível mais elevado.

Um último passo que deve ser realizado é definir na tabela Fato qual o menor nível de detalhe que deve ser utilizado nas consulta.

Na Logical Table Source (LTS), na aba Content da tabela Fato você pode determinar este nível de detalhe para todas as dimensões relacionadas.

A modelagem aqui foi feita para exemplificar as características de uma estrutura muitos-para-muitos, obviamente que se poderia modelar de maneira diferente ou seja Funcionários e Departamentos em dimensões separadas, o que é o mais comum.

A Dimensão Departamento e Funcionários podem estar ligadas diretamente a Fato.

Porem, como foi dito inicialmente, existem necessidades de negócio que não é possível aplicar essa solução.

abraços
Alan Viegas