Quais são algumas maneiras de implementar um relacionamento muitos para muitos em um data warehouse?

As topologias dominantes da modelagem do Data Warehouse (Star, Snowflake) são projetadas com relacionamentos um-para-muitos. A legibilidade, o desempenho e a estrutura da consulta diminuem severamente quando confrontados com um relacionamento muitos para muitos nesses esquemas de modelagem.

Quais são algumas maneiras de implementar um relacionamento muitos para muitos entre dimensões ou entre a tabela de fatos e uma dimensão em um data warehouse e quais comprometimentos eles causam com relação à granularidade e ao desempenho de consulta necessários?

Na minha experiência, uma hierarquia recursiva é a maneira mais prática de lidar com isso. Oferece as seguintes vantagens:

1. Profundidade ilimitada.
2. Compacidade.
3. Flexibilidade.
4. Rapidez.

Por outro lado, é necessária uma tabela extra para cada nível de junções "para muitos". Isso é codificado e difícil de manter em relação às atualizações de esquema.

Usando índices filtrados, uma grande tabela de junções hierárquicas pode ser executada em velocidade superior às tabelas dedicadas. O motivo é que cada associação é apenas "pai-filho" em comparação com "para associar tabela a tabela de dados". Este último possui mais índices para processar e armazenar.

Eu tenho tentado resolver este problema por muitos anos. Recentemente, foi isso que eu criei.

Alguns cenários para relacionamentos M: M em um modelo de armazém de dados

A maioria dos servidores OLAP e sistemas ROLAP tem um meio de lidar com estruturas de dados M: M agora, mas há algumas advertências sobre isso que você precisará prestar atenção. Se você implementar relacionamentos M: M, precisará ficar de olho na camada de relatórios e em quais ferramentas deseja apoiar.

Cenário 1: dimensão M: M em uma tabela de fatos

Um exemplo disso pode ser vários drivers em uma política de motor. Se você adicionar ou remover um driver, a transação de ajuste de política poderá ter um relacionamento com uma lista de drivers que mudam com o ajuste.

Opção 1 - M: M tabela de ponte de fatos do driver Isso terá um volume bastante grande de dados, pois possui linhas de drivers x transações para uma determinada política. O SSAS pode consumir essa estrutura de dados diretamente, mas é mais lento consultar através de uma ferramenta ROLAP.

Se o seu relacionamento M: M for baseado em entidades específicas da linha de fatos (por exemplo, motoristas em um carro), isso também pode ser apropriado para uma ferramenta ROLAP, desde que sua ferramenta ROLAP suporte relacionamentos M: M (por exemplo, usando contextos no Business Objetos).

Opção 2 - Tabela de dimensões fictícias de 'combinações' Se você estiver mapeando uma lista de códigos comuns para uma tabela de fatos (ou seja, as entidades vinculadas não são peculiares à linha de fatos), poderá adotar outra abordagem que reduzirá os volumes de dados. Um exemplo desse tipo de cenário são os códigos do CDI em uma visita de internação. Cada visita hospitalar terá um ou mais diagnósticos e / ou procedimentos do CDI listados contra ele. Os códigos ICD são globais.

Nesse caso, você pode criar uma lista distinta das combinações de códigos em cada caso. Faça uma tabela de dimensões com uma linha para cada combinação distinta e tenha uma tabela de links entre as combinações e as tabelas de referência para os próprios códigos ICD.

A tabela de fatos pode ter uma chave de dimensão para a dimensão 'combinações', e a linha de dimensão possui uma lista de referências aos códigos ICD reais. A maioria das ferramentas ROLAP pode consumir essa estrutura de dados. Se sua ferramenta funcionar apenas com um relacionamento M: M real, você poderá criar uma exibição que emule o relacionamento M: M entre o fato e a tabela de referência de codificação. Essa seria a abordagem preferida com o SSAS.

Vantagens da opção 1: - Indexadas adequadamente, as consultas baseadas na seleção de linhas da tabela de fatos com um determinado relacionamento através da tabela M: M podem ser razoavelmente eficientes.

• Modelo conceitual ligeiramente mais simples

Vantagens da opção 2: - O armazenamento de dados é mais compacto

• Você pode emular um relacionamento 1: M direto, apresentando as combinações em um formato legível por humanos como um código na dimensão 'combinações'. Isso pode ser mais útil em ferramentas de relatório mais difíceis que não têm suporte para relacionamentos M: M.

Cenário 2: relação M: M entre dimensões:

É mais difícil pensar em um caso de uso, mas é possível imaginar algo fora da assistência médica com os códigos do CDI novamente. Em um sistema de análise de custos, a visita hospitalar pode se tornar uma dimensão e terá relações M: M entre a visita (ou o episódio do consultor na fala do NHS) e os códigos.

Nesse caso, você pode configurar os relacionamentos M: M e, possivelmente, codificar uma renderização legível por humanos na dimensão base. Os relacionamentos podem ser feitos através de tabelas de links M: M diretas ou através de uma tabela de 'combinações' de pontes como antes. Essa estrutura de dados pode ser consultada corretamente por meio de objetos de negócios ou ferramentas ROLAP de melhor qualidade.

Em primeiro lugar, não consigo ver o SSAS sendo capaz de consumir isso sem levar o relacionamento até a tabela de fatos; portanto, você precisa apresentar uma visão do relacionamento M: M entre a codificação e a tabela de fatos linhas para usar o SSAS com esses dados.

Gostaria de saber exatamente em que tipo de relacionamento muitos para muitos você tem em mente em seu modelo, seja no sistema transacional ou em qualquer modelo de dados em que esteja atualmente.

Normalmente, os relacionamentos muitos para muitos entre dimensões são fatos sobre dimensões. O fato de um cliente solicitar de várias filiais que atendem a muitos clientes ou algo assim. Cada um desses é um fato. Teria uma data efetiva ou algo assim, mas o relacionamento poderia ser "sem fatos". O relacionamento em si pode ter outras dimensões além do cliente e da filial. Portanto, é um esquema em estrela típico com uma tabela de fatos (potencialmente sem fatos) no centro. Como essa estrela pode se relacionar com outras estrelas dimensionais no armazém dependerá obviamente. Sempre que você combinar estrelas diferentes, faça isso nas chaves comerciais e tenha certeza de que não está realizando junções cruzadas inadvertidas.

Normalmente, não se reporta essas tabelas de relacionamento de dimensão no mesmo grau que as tabelas de fatos maiores e, quando o fazem, nem sempre são tantos dados, portanto não tendem a afetar o desempenho. No caso acima, você pode observar a utilização do cliente / filial ao longo do tempo, mas dados melhores sobre as quantidades reais de pedidos estariam disponíveis em sua tabela de fatos, que provavelmente também teriam dimensões para o cliente, filial etc. Isso não é o que a maioria das pessoas consideraria muitos para muitos (embora um pedido possa ser considerado para definir um relacionamento muitos para muitos, de cliente para filial), portanto, são mais comuns em ambientes de data warehouse. Você só faria agregações numéricas em modelos muitos para muitos se tivesse acumulado informações resumidas para esse nível de relacionamento - por exemplo, cliente, filial, mês,

Aqui estão alguns artigos relevantes de Kimball e outros que podem se aplicar à modelagem de um determinado relacionamento muitos-para-muitos proposto. Observe que um relacionamento muitos para muitos é um conceito apenas no domínio do problema / modelo lógico. Em um modelo OLTP normalizado, ele ainda seria tratado com uma tabela de links que é, obviamente, uma para muitas em cada sentido. Em um modelo de data warehouse Kimball não normalizado, há várias maneiras de fazer isso, uma das quais basicamente trata essa tabela de links como o fato no centro de uma estrela. Outra é como uma matriz de colunas de sinalização.

Por fim, a escolha dependerá exatamente do que você está modelando, de como está mudando e de como deseja fazer um relatório. É aqui que a modelagem dimensional e o data warehousing em geral divergem bastante do modelo normalizado. O modelo normalizado concentra-se nas relações lógicas e teóricas dos dados, que data warehousing sempre mantém um olho nos casos de uso realistas e desnormaliza para que esses desempenhem.

Modelando hierarquias alternativas usando uma tabela de ponte:

http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf

Três opções para um relacionamento muitos para muitos (vinculado a alocações numéricas de compartilhamentos - veja os comentários para algumas informações interessantes)

http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/

Infelizmente, muitos artigos da Kimball's Information Week / DBMS mag não têm mais bons links ...

Uma maneira de resolvermos isso é ter uma tabela de fatos com apenas 2 colunas, de chave estrangeira das 2 dimensões com relação de muitos para muitos.