Avaliação: | Publicado em: 08/05/2007

Modelagem de Dados: Hierarquias - Parte 3

Gustavo Maia Aguiar é graduado em Administração de Empresas e pós-graduado em bancos de dados, atua na área de tecnologia de informação desde 2001, exercendo funções de desenvolvedor, analista, administrador de banco de dados (DBA) e administrador de dados (AD). É profissional certificado (MCP, MOS, MCDBA, MCAD, MCTS, MCITP, MCT, MVP e Itil Certified Professional). Já trabalhou em instituições do governo, iniciativa privada e parceiros Microsoft em atividades de suporte, consultoria e treinamento. É membro ativo e moderador dos fóruns de SQL Server do MSDN e TechNet e das comunidades SQL Server Brasil e SQL Brasil (Orkut). Semanalmente publica artigos de banco de dados e SQL Server em seu blog.

Modelagem de Dados: Hierarquias - Parte 3

A Tabela Ponte (Bridge Table)

Nos artigos anteriores foram explanados conceitos, tipos, elementos, características presentes em relações hierárquicas. Foram apresentadas a técnica do modelo adjacente e a técnica do modelo dos caminhos materializados como forma de se representar em um modelo de dados uma hierarquia.

Os artigos demonstraram que ambas as técnicas apresentam vantagens, desvantagens, cenários aplicáveis e algumas alternativas para superar suas limitações. Apesar das diferenças, ambas não conseguem lidar muito bem com a navegação entre níveis hierárquicos quando são consideradas relações entre níveis de forma indireta (especialmente no sentido bottom-up). Apenas com o aumento da complexidade das instruções SQL, a utilização de extensões proprietárias ou o repasse de parte do processamento para a aplicação é que essas técnicas podem lidar melhor com esse tipo de necessidade.

Ainda que esses artifícios expandam as capacidades da técnica do modelo adjacente ou da técnica dos caminhos materializados, há um outro problema: Ambas as técnicas não estão aptas a lidar com o histórico de maneira eficiente. É certo que manter o histórico de relações hierárquicas não é uma demanda muito comum, mas em todo o caso, é necessário que se desenvolva técnicas para fazê-lo afinal nunca se sabe quando esse tipo de informação será necessária.

A técnica da tabela ponte (bridge table) representa uma alternativa para lidar melhor com as adversidades da navegação no sentido bottom-up e armazenar os registros históricos de maneira a eliminar a necessidade de se reconstruir toda a hierarquia.

A origem

A primeira vez que vi a descrição dessa técnica foi em uma das maiores literaturas de Data Warehouse publicadas. Trata-se do livro de Ralph Kimball: The Data Warehouse Toolkit. Embora esteja relacionada a um ambiente de Data Warehouse, sua adaptabilidade não representa nenhuma dificuldade em situações onde a modelagem ER é necessária.

Nas técnicas anteriores, para responder a determinadas perguntas, quase sempre era necessário um processamento adicional. Através de uma lógica recursiva, ou basendo-se na posição de determinados elementos, um algoritmo era aplicado de forma a obter a informação desejada. Essa técnica introduz certas redundâncias de forma que não seja necessário “calcular” quem são os níveis superiores e inferiores não imediatos, qual a distância entre dois níveis ou ainda qual é a profundidade da árvore. Através de uma proposta de modelagem, essas informações já são armazenadas.

Páginas: « Anterior 1 2 3 4 5 6 Próximo »  Próximo: A Implementação »