Implementando Hierarquias Irregulares no Microstrategy (Ragged Hierarchies)

Continuando o assunto de Hierarquias atípicas no Microstrategy, chegou a hora de falar sobre Hierarquias Irregulares. Este é um outro assunto cuja solução funciona para qualquer ferramenta, e também é faz parte da metodologia de Advanced Data Warehousing da Microstrategy.

Hierarquias Irregulares ou Ragged Hierarchies é algo como o que você vê abaixo:

Para todos os meus exemplos, gosto de fazer pequenos cases, com modelos de dados utilizando a ferramenta DBDesigner. Implementei um pequeno datamart no Microsoft Access, depois inseri um conteúdo fake, e fiz o mapeamento de sua camada semântica no Microstrategy, para poder exemplificar e mostrar como é na prática, tudo aquilo que estou falando.

Começamos pelo pequeno datamart abaixo, que simula a estrutura de um plano de contas fictício de uma empresa, com 4 níveis, da conta mais sintética até a mais analítica. Uma tabela temporal de mês e uma pequena fato.

Nessa estrutura, foi inserido o seguinte conteúdo, mostrado em duas partes. Este que seria um pedaço do nosso plano de contas fictício:

Primeiro o Ativo da empresa, a Conta Nível 1. Ele é dividido em 3 subgrupos: Ativo Circulante, Ativo Não Circulante e Permanente, que são as Contas Nível 2. 
Para este exemplo, vamos isolar o Ativo Circulante. Abrindo sua estrutura, temos as seguintes Contas Níveis 3 e 4:

Ativo Circulante é uma Conta Nível 2. Embaixo dela, temos Contas Nível 3: Clientes e Disponível. Nessas contas, seguindo a estrutura, temos em cada uma suas Contas Analíticas, na cor amarela, cada uma com um valor monetário igual a 10. 
Porém, observe, que a Conta 5, está diretamente ligada ao Nível 2 - Ativo Circulante, sem a existência de um Nível 3. Em outras palavras, a Conta 5 que é do Nível 4, está ligada diretamente ao Ativo Circulante do Nível 2.
Se você é um projetista cuidadoso, resolveu isso ainda nas camadas de datawarehouse e ETL, e este problema não "estourou" no front end. Porém, se chegou até no Microstrategy, olhe as consequências. O modelo de dados analisado foi mapeado em um projeto no developer. O primeiro cenário, é se emitirmos um relatório, somente com as contas analíticas e seus totais:

Veja que todas as contas foram retornadas, com o valor de 10 em cada uma delas, totalizando 50. Então para este nível de detalhe não teremos problema. O problema ocorre quando você adiciona outros níveis superiores no relatório, ou faz o drill entre níveis superiores:

Observe, quando adicionamos os demais níveis, a última conta, aquela que está ligada diretamente do seu Nível 4 para o Nível 2 sem passar pelo Nível 3, não aparece, pois não compõe o join. Desta forma o valor total passa a ser 40, o que é um erro.


Solução:

Para corrigir este problema é simples. Basta inserir o membro faltante entre o Nível 2 e o Nível 4:

Este novo membro é um conteúdo na tabela dim_Conta_Nivel_3, que deverá estar como pai da Conta 5 na dim_Conta_Nivel_4. Quanto a sua descrição, alguns preferem herdar o descrição do nível pai, outros preferem subir a descrição do nível filho. Eu prefiro um conteúdo como "Nível Ausente".  Com esta correção na camada de ETL, veja como fica agora nosso relatório:

Agora observe o total 50. Observe também que todas as cinco contas aparecem e o nível que estava faltando também com seu novo descritivo. Esta é a solução recomendada pela Microstrategy para hierarquias irregulares, e este conteúdo assim como o do post anterior caem na prova da MCEP.

Obrigado e boa noite

Fabio Idalgo