OBIEE – Modelagem de RPD para tabelas Factless

Share Button

Um dos grandes pilares para a construção de um BI é a modelagem e integração dos dados. Existe uma importância muito grande em desenvolver a estrutura do seu modelo de dados de forma com que a ferramenta que utilizamos para apresentação dos relatórios consiga atender as métricas necessárias para o usuário final. Porém, na maioria dos projetos no qual tenho atuado, essa importância só foi descoberta depois que todo o Data WarehouseDW estava pronto e o esforço e tempo para modifica-lo já não cabiam mais no cronograma de escopo dos projetos.

Neste artigo, venho mostrar uma solução através da modelagem do repositório de metadados, que pode ser aplicada em cases como citei a cima. A solução é uma sugestão dada por um dos meus parceiros de consultoria Gabriel Freitas, essa metodologia já é conhecida no universo de modelagem de dados como Factless (Fato sem Fatos).

Cenário:
Como sabemos, o BI Oracle utiliza o conceito de modelo de dados Star Schema convencional, ou seja, uma tabela de fatos para várias dimensões diferentes. Neste case, podemos dizer que temos modelo de negócios customizado, pois abrange mais de uma tabela de fatos que chamei de “Fato Auxiliar”. No diagrama abaixo, podemos observar que nossa Fato Auxiliar não possui Joins com outras dimensões que relacionam nossa “Fato Principal” (salvo a dimensão tempo).

 

Partindo de nosso modelo Star Schema customizado, precisamos realizar uma simples análise no Oracle BIEE 11g com base na query realizada em nosso DW:

Problema:
Se modelarmos a camada semântica do RPD através do Administrator Tool de forma idêntica ao modelo Star Schema customizado, como se fosse um convencional, as informações se perdem na agregação, trazendo dados nulos no resultado de nossa análise no OBIEE:

 

Solução:
Para resolver o problema de perda de dados originados de nossa Factless utilizei uma metodologia bem simples, implementada dentro do repositório de metadados, também conhecido como RPD. Primeiramente, configurei os joins físicos do modelo de forma com que a Factless assumisse um perfil de dimensão, onde voltamos a ter logicamente o conceito de modelo Star Schema padrão:

A próxima etapa de nossa implementação será realizada na camada de negócios do RPD, observe que configurei somente a regra de agregação para nossa fato principal, deixando nossa Factless sem regras de agregações em sua métrica.

Agora, vamos configurar mais um Source para nossa fato principal F01_Evento. Este passo permite mapear mais de uma origem de dados para a fato, permitindo que utilizemos colunas de dados oriundos de outras tabelas que fazem parte do nosso modelo de dados.

Edite as propriedades do Source da sua fato principal. Em seguida clique no botão ilustrado abaixo para adicionar mais uma tabela para origem de dados:

Selecione a tabela “Fato Auxiliar”:

Observe que depois disso, passamos a ter duas origens configuradas para nossa F01_EVENTO:

Agora o próximo passo, ainda na camada de negócios é criar uma nova coluna “VALOR_DESPERDICIO” dentro fato principal F01_EVENTO. Veja conforme na imagem abaixo, é necessário mapear a origem de dados da Factless apontando para o source que configuramos no passo anterior.

Depois disso, configure a regra de agregação para a nova coluna “VALOR_DESPERDICIO” de sua fato principal “F01_EVENTO” e crie a camada de apresentação para seu modelo de negócios que deve ficar da seguinte forma:

Resultado:
Crie uma nova análise no OBIEE, conforme demonstrei no problema mencionado anteriormente:

Em seguida visualize os resultados:

Carina Mendes.