Pergunta

Temos de dados com duas origens diferentes: alguns vem de um cliente, alguns vem de diferentes fornecedores. Atualmente, nós fisicamente "merge" esses dados em uma tabela enorme com quase uma centena de colunas, dezenas de milhares de linhas e nenhuma separação formal entre as duas dimensões. Consequentemente, não podemos realmente usar esta tabela para muito.

Vou reformular essa bagunça em um adequado, mas pequena, esquema em estrela.

As duas dimensões são óbvias. Um deles, por exemplo, é o tempo.

Os dados fornecidos pelo cliente fornece uma série de valores de fato. Cada fornecedor pode (ou não) fornecem valores de fatos adicionais que se encaixam as mesmas dimensões.

dados Este facto, todos tem a mesma granularidade. Ele pode ser chamado de "escassa", porque não muitas vezes obter informações de todos os fornecedores.

Aqui está o meu dilema.

É esta tabela um fato - com alguns valores nulos -? Preenchida a partir de diferentes fontes

Ou isso é n +1 tabelas de fatos -? Um povoado do cliente, os outros preenchida a partir de cada fornecedor

Há prós e contras de cada projeto. Eu preciso de algumas segundas opiniões sobre a escolha entre "merge" ou "carga separadamente".


A receita suprimentos cliente, custo, contagem, pesos e outras coisas que eles sabem sobre o seu fim de uma transação.

Vendor um fornece alguns detalhes adicionais sobre algumas das operações - pesos, custos, durações. As demais operações não terá valor de um único fornecedor.

Vendor duas fontes de alguns detalhes adicionais sobre algumas das operações - volumes, durações, comprimentos, taxas de câmbio estrangeiras. As demais operações não terá nenhum valor para o vendedor dois.

Algumas transações terão ambos os fornecedores. Algumas transações não terão nem fornecedor.

Uma tabela com valores nulos? Três mesas?

Foi útil?

Solução

Eu iria para a tabela de fatos única. O destaque pro desta abordagem é que ele deixa todo o trabalho duro no tempo de carregamento em vez de no momento da consulta.

Outras dicas

Do que você descreve, parece que uma única tabela de fatos é o caminho a percorrer.

Parece que a tabela de fatos teria um grão de tempo x transação x cliente (?).

A minha pergunta anterior estava realmente tentando descobrir se alguns dos dados de fornecedores era um candidato para sua própria dimensão. Vou deixar para você para determinar isso. mas ele realmente não soar como ele.

fatos nulos pode lançar avisos durante agregações (dependendo da plataforma), mas a alternativa de preenchê-las com zeros possivelmente enganosas é pior.

Acredito que desde que ambas as fontes compartilham o mesmo grão a resposta é que você deve ter uma tabela de fatos. Pense sobre como você deseja que seus usuários finais para interagir com a informação. Se faz sentido e os relatórios de negócios serão beneficiados com esses dados sendo co-localizado, em seguida, que é sua resposta. Tentar embora para valores nulos evitar em seu tabelas de fatos. Se você pode digitar um zero (e os de zero faz sentido para os dados, ou seja, pense temperatura), em seguida, fazer isso. Ele vai salvar seus usuários alguma confusão e como TrickyNixon apontou irá causar problemas de agregação.

Na verdade, você está em um grande ponto aqui sobre a aplicação 'brownfield'. Você pode olhar para o que existe hoje e aproveitar a experiência para criar um design melhor. Este é o momento mais importante para selecionar o melhor grão que esperemos que não vai mudar para a vida da DW.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top