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

Conclusão

A representação de hierarquias costuma ser um requisito comum em diversos sistemas de informação. Cedo ou tarde algum sistema ou regra de negócio irá expor o modelo de dados à presença de hierarquias desbalanceadas.

Após quatro artigos explicando as hierarquias, seus tipos, seus elementos e as dificuldades de transpor sua representação conceitual para a implementação física em bancos de dados relacionais e objetos relacionais, creio que foi possível demonstrar que embora essa tarefa possa parecer difícil, existem técnicas que podem facilitar na recuperação das informações necessárias. Algumas dessas técnicas potencializam requisitos como desempenho enquanto outras privilegiam a diminuição do espaço. Algumas outras podem exercer combinações entre esses fatores e tornar as consultas mais fáceis de serem formuladas

No desenvolvimento de diversas aplicações, muitas vezes os projetistas, costumam utilizar a técnica que conhecem melhor ou que consideram como correta. Alguns problemas são facilmente resolvidos por uma técnica específica, mas é preciso ficar claro que muitas vezes, não existe uma única solução correta. Quase sempre se recorre ao modelo adjacente ou ao modelo dos caminhos aninhados e algumas vezes eles definitivamente não são a melhor solução para responder às perguntas de uma determinada aplicação. Existem situações em que nenhuma das quatro técnicas é adequada. Dependendo dos requisitos envolvidos, freqüência de atualização e integração com os demais dados, utilizar um arquivo XML pode ser mais interessante do que armazenar hierarquias em bancos de dados relacionais ou objeto-relacionais.

Embora todas as técnicas possam representar hierarquias com maior ou menor facilidade é preciso escolher uma alternativa ótima em termos de espaço, desempenho, flexibilidade, facilidade na formulação de consultas entre outros aspectos. Nenhuma das alternativas é perfeitamente capaz de ser a melhor em todos os aspectos. A tabela abaixo é um pequeno resumo que pode auxiliar na escolha da técnica mais adequada. Ela está isenta do repasse da complexidade para a aplicação ou a utilização de extensões proprietárias.

	Modelo Adjacente	Caminhos Materializados	Bridge Table	Caminhos Aninhados
Simplicidade	+	+	+/-	-
Consultas (Relação imediata)	+	+	+	+/-
Consultas (Relação não imediata)	-	+/-	+	+
Economia de Espaço	+	+/-	-	+/-
Montagem total / parcial da hierarquia	-	-	+	+/-
Desempenho	+/-	+/-	+	+
Histórico	-	-	+	-
Identificação de elementos e características	-	-	+	+/-
Gestão da redundância	+	+	-	+/-

A escolha da técnica mais adequada deve ser pautada principalmente nos requisitos atuais e futuros do usuário que refletem diretamente no tipo de perguntas que deverão ser respondidas. Esses requisitos podem ser simples como saber quem é o superior imediato de determinado membro, quem são os membros inferiores imediatos, etc até requisitos mais complexos como distância em níveis de determinados membros, montagem da árvore total ou parcial a partir de determinado membro seja dos níveis acima deste ou abaixo deste.

Embora cada artigo tenha se focado mais em uma técnica específica, de forma nenhuma as técnicas não são mutuamente exclusivas. É possível utilizá-las de forma combinada em um único modelo de dados. Não há nenhum impeditivo em construir um modelo de dados que em uma única tabela contemple o modelo adjacente, o modelo dos caminhos materializados e o modelo dos caminhos aninhados. Utilizar as técnicas de forma combinada pode permitir maior flexibilidade já que para determinadas perguntas se utiliza uma técnica e para outras perguntas se utiliza outra técnica. Os únicos pré-requisitos são a criação de mecanismos de atualização dos dados para cada técnica utilizada e a avaliação final do desempenho de se utilizar técnicas combinadas.

Acredito que agora trabalhar com hierarquias será uma tarefa um pouco mais fácil. Esse foi o objetivo ao longo desses quatro artigos.

Até a próxima