Modelando uma estrutura muitos-para-muitos utilizando uma tabela Bridge (Ponte)

Publicado: 13/03/2012 por alanviegas em Modelagem de Dados
Tags:

Modelos dimensionais (star and snowflake schemas) normalmente funciona bem para a modelagem da maioria dos projetos de datamart e business intelligence, onde há relações um-para-muitos entre as tabelas de dimensão e as tabelas de fatos.

No entanto, às vezes é necessário modelar uma estrutura muitos-para-muitos entre as tabelas de dimensão e tabelas de fatos. Por exemplo, um funcionário de uma empresa pode pertencer a vários departamentos, e o mesmo departamento pode ser ocupado por vários funcionários.

Diante deste tipo de situação, você precisa modelar uma estrutura muitos-para-muitos entre as tabelas de dimensão e tabelas de fato. Porem como a maioria dos banco de dados suportam apenas relacionamentos um-para-muitos, é necessário implementar este tipo de relacionamento fisicamente através de uma tabela de junção (tabela Ponte ou Bridge) com dois relacionamento um-para-muitos.

Este tipo de projeto pode criar mais registros na tabela Ponte do que na tabela Fato. Você pode limitar o número de registros na tabela Ponte predefinindo grupos e forçando cada registro da Fato caber em um desses grupos predefinidos.

Veja o modelo físico abaixo considerando a tabela fato HORAS_TRABALHADAS:

Figura 1:

Neste exemplo a Dimensão funcionários pode estar relacionada a um ou mais departamentos e a dimensão departamentos pode ter um ou mais funcionários. A tabela “Ponte“ pode ter múltiplas linhas relacionando as duas dimensões.

Configurando a Logical Table Source (LTS)

Após arrastar as tabelas físicas para a camada lógica é necessário integrar na dimensão Funcionários as tabelas ponte e Departamentos. Abrindo as propriedades da LTS na aba General click, em adicionar e selecione as demais tabelas a partir do modelo físico.

Após importar, basta definir o tipo de join que será aplicado entre as tabelas.

No modelo lógico abaixo a Dimensão Funcionários esta ligada a Fato Horas Trabalhadas e todos os atributos de Departamento também fazem parte de Funcionários.

Ao criar a hierarquia para a Dimensão Funcionários, é possível definir Funcionários como menor nível de detalhe e Departamentos um nível mais elevado.

Um último passo que deve ser realizado é definir na tabela Fato qual o menor nível de detalhe que deve ser utilizado nas consulta.

Na Logical Table Source (LTS), na aba Content da tabela Fato você pode determinar este nível de detalhe para todas as dimensões relacionadas.

A modelagem aqui foi feita para exemplificar as características de uma estrutura muitos-para-muitos, obviamente que se poderia modelar de maneira diferente ou seja Funcionários e Departamentos em dimensões separadas, o que é o mais comum.

A Dimensão Departamento e Funcionários podem estar ligadas diretamente a Fato.

Porem, como foi dito inicialmente, existem necessidades de negócio que não é possível aplicar essa solução.

abraços
Alan Viegas

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s