Modelagem de Dados: Hierarquias - Parte 1, por Gustavo Maia Aguiar

Desvantagens

Montagem total / parcial da hierarquia

Essa é uma das desvantagens mais inerentes ao modelo adjacente. Sua representação utiliza relações hierárquicas na própria tabela de definição de um objeto (no caso centro de custo). Para cada navegação, seja para encontrar membros superiores ou membros inferiores, um JOIN (iteração no vocabulário recursivo) é necessário. O problema surge pelo fato do número de níveis não ser conhecido e variável já que no exemplo proposto existe uma hierarquia desbalanceada.

Suponha, por exemplo, o cálculo do total de lançamentos do centro de custo “TI”, isto é, obter o somatório de seus lançamentos próprios e os lançamentos de seus centros de custo inferiores (sejam estes imediatos ou não). Para realizar esse cálculo será preciso coletar os lançamentos do centro de custo "TI" e realizar o cálculo de seus centros de custos inferiores imediatos (Projetos de Software e Infra-Estrutura) e de todos os centros de custos inferiores não imediatos (arquitetura, redes, bancos de dados, etc) até que se chegue aos centros de custo sem inferiores (nós folha).

A distância do centro de custo “TI” até os últimos centros de custos inferiores (nós folhas) é de três níveis. Isso significa que com três JOINs é possível escrever uma sentença SQL para realizar esse cálculo. Esse raciocínio, no entanto, não é suficiente para resolver o problema do cálculo do total de lançamentos de qualquer centro de custo. A consulta utilizada para nesse cálculo para o centro de custo “TI” não poderia ser utilizada em outros centros de custo como “Presidência”, “Recursos Humanos” e “Jurídico” já que a distância desses centro de custos até seus últimos centros de custo inferiores (nós folha) é respectivamente 4, 1 e 0 (o centro de custo “Jurídico” já é um nó folha).

Essas dificuldades aparecem tanto em pesquisas do tipo “TOP-DOWN” ou “BOTTOM-UP”. No exemplo da ARP Associados, pesquisas do tipo “TOP-DOWN” são as que, a partir de um centro de custo, precisam determinar todos os seus centros de custo inferiores (sejam imediatos ou não) enquanto pesquisas do tipo “BOTTOM-UP” são as que, a partir de um centro de custo, precisam determinar todos os seus centros de custos superiores (sejam imediatos ou não). De uma forma geral as pesquisas “BOTTOM-UP” são mais fáceis, pois, um centro de custo pode possuir apenas um superior imediato. Já nas pesquisas “TOP-DOWN”, um centro de custo pode possuir diversos centros de custo inferiores imediatos o que torna as consultas mais difícies de se elaborar.

Desempenho

O desempenho das consultas nesse tipo de modelo pode ser comprometido por dois fatores. O primeiro é a própria natureza iterativa desse modelo. A navegação entre os nós da hierarquia necessita de várias iterações para obter o retorno desejado e quanto maior o número de iterações menor é o desempenho. A dificuldade envolvida em elaborar determinadas consultas irá adicionar complexidade incorrendo em construções de código adicionais e possivelmente perda de desempenho.

Histórico

O modelo adjacente não é muito hábil em lidar com históricos. Se houver alguma mudança nas relações hierárquicas entre os centros de custo, é necessário arquivar toda a hierarquia e posteriormente realizar as alterações. Se por exemplo, o centro de custo "Infraestrutura" for eliminado e os centros de custo "Redes" e "Banco de Dados" vincularem-se diretamente ao centro de custo "TI", as relações "TI - Infraestrutura", "Infraestrutura - Redes" e "Infraestrutura - Banco de Dados" serão perdidas. Será necessário armazenar duas situações: a hierarquia da ARP antes dessa mudança e a hierarquia da ARP após essa mudança resultando em duas realidades. Basta uma outra mudança para resultar em uma terceira realidade. Manipular essas diferentes realidades em paralelo é uma tarefa extremamente trabalhosa embora nem sempre exigida. Muitas vezes não se deseja guardar esse tipo de informação em um histórico.