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