OBIEE - Visão Geral
Por Leornado Silva
Oracle Business Intelligence Enterprise Edition (OBIEE) é uma completa solução de sistema de Business Intelligence para empresas, que oferece capacidades de criação de relatórios, consultas ad hoc, análise, dashboards e scorecards.
O OBIEE é gigantesco, oriundo do antigo Siebel, aplicativo este comprado pela Oracle, e seu manual possui mais de 2800 páginas! Mas tenham calma pois não vou escrever aqui cada detalhe. Ainda ouso dizer que não é necessário mais de um mês de uso contínuo da ferramenta para já pegar as “manhas”.
Para quem está habituado, em seu núcleo o aplicativo funciona da mesma forma que o antigo “Oracle BI Discoverer” ou qualquer um dos outros ad hoc, ferramentas de consulta destinados a ser usados por usuários de negócios.
Neste artigo, vou tentar passar a funcionalidade principal e básica para o que já é habitual de quem entende de SQL. Após isso, vou mostrar a visão do analista de negócios na ferramenta, a visão do desenvolvedor na ferramenta e, por fim, a comparação com outras ferramentas de mercado. Então, vamos entender um pouco sobre ad hoc?
AD HOC
Vamos começar com um exemplo muito simples. Da sua coleção de tabelas de bancos de dados relacionais, armazenados em, digamos, um banco de dados Oracle, você seleciona um subconjunto que é de interesse para um determinado grupo de usuários corporativos. Vamos supor que você selecione as tabelas "Clientes", "Produtos" e "Vendas":
Para manter as coisas bem simples, vamos supor que cada tabela contém apenas poucas colunas, conforme mostra a desc SQL a seguir:
Os desenvolvedores normalmente poderiam juntar essas tabelas para criar uma visão única, desnormalizada, dando às mesmas, nomes mais “business-friendly”.
SELECT c.customer_name "Nome do cliente",
p.product_name "Nome do produto",
s.sales_quantity "Quantidade de Vendas",
s.sales_value "Valor Geral de Vendas"
FROM customers c,
products p,
sales s
WHERE c.customer_id=s.customer_id
AND p.product_id=s.product_id
ORDER BY 1, 2;
Os desenvolvedores fariam a partir daí uma expressão SQL para poder executar cálculos. Por exemplo:
SELECT c.customer_name "Nome do cliente",
p.product_name "Nome do produto",
sum (s.sales_quantity) "Quantidade Total de Vendas",
sum (s.sales_value) "Valor Geral de Vendas Total"
FROM customers c,
products p,
sales s
WHERE c.customer_id=s.customer_id
AND p.product_id=s.product_id
GROUP BY c.customer_name, p.product_name
ORDER BY 1, 2;
Partindo deste básico, quero apenas que vocês entendam que, se este exemplo fosse mais realista e você tivesse que incluir todos os valores de coluna e expressões que possam ser de interesse do usuário, você teria uma query imensa com centena de colunas e dúzias de tabelas.
Agora vamos supor que esse modo de exibição mestre desnormalizada de dados é realizada em algum armazenamento de dados residente na memória, pronto para uso. Como os usuários de negócios consideram SQL com o mesmo descontentamento que os vampiros consideram o alho, você precisa esconder o SQL e apenas apresentar a seus colegas com um conjunto de itens correspondentes aos alias:
Nome do cliente
Nome do produto
Total de vendas (Quantidade)
Valor Total das Vendas
Mais uma vez, em um exemplo mais realista, você pode ter centenas desses itens de apresentação, e você fazer um esforço para organizá-los em grupos lógicos que formaram os nós em uma árvore que os usuários de negócios poderia navegar - da mesma forma que eles navegar estruturas de diretório dentro do Windows Explorer.
Agora, para criar uma consulta o que o usuário de negócios tem a fazer é clicar sobre os itens de apresentação que são de seu interesse, como por exemplo:
Cliente Nome
Valor Total das Vendas
Nos bastidores, o software irá recuperar a consulta mestre e "podá-la", eliminando as colunas e expressões que não foram selecionados, e através da remoção de qualquer tabela redundante, juntar as expressões:
SELECT c.customer_name "Nome do cliente",
sum (s.sales_value) "Valor Total de Vendas"
FROM customers c,
sales s
WHERE c.customer_id=s.customer_id
GROUP BY c.customer_name
ORDER BY 1;
Em seguida, o software irá executar a consulta lapidada e exibir os resultados assim como o usuário do negócio solicitou.
Então, em essência, ad hoc é muito simples. Os desenvolvedores precisam construir apenas as consultas mestras que são de interesse dos usuários de negócios, e os usuários de negócios apenas escolhem entre a seleção de itens de apresentação que estão em evidência.
A arquitetura do OBIEE
Se reduzirmos a arquitetura de OBIEE para sua essência, podemos dizer que consiste em um usuário olhando os componentes – “BI Presentation Services” - e uma fonte de dados voltada para componente - o "BI Server":
O BI Presentation Services recebe uma seleção de itens de apresentação feita por um usuário de negócio, constrói uma consulta SQL simples e encaminha para o BI Server. No nosso caso do exemplo acima, o arquivo de log será:
Do ponto de vista do BI Presentation Services todos os valores do item correspondem a valores de colunas em uma tabela de banco de dados únicos. O BI Server traduz esta solicitação simples em otimizadas subconsultas SQL nativas e envia cada subconsulta à fonte de dados correspondente. No caso do exemplo que é simples, temos uma única fonte de dados e o arquivo log envia para o banco de dados o seguinte:
Como podemos ver, esta consulta corresponde exatamente à nossa consulta "podada" acima, na explicação do ad hoc. O BI Server aguarda os resultados a serem devolvidos, integra-os e executa os cálculos que não foram realizados pela fonte de dados, retornando estes resultados para o BI Presentation Services no formato simplificado. Em seguida, os dados são formatados em uma tabela dinâmica ou gráfico, indo direto para um navegador web do usuário empresarial.
Espero que gostem!
Até a próxima!