Design de um data warehouse com mais de uma tabela de fatos

Question

Eu sou novo no data warehousing. Primeiro, quero precisar do que a minha cópia do Data Warehouse Toolkit está no caminho para a minha caixa de correio (Snail Mail: P). Mas eu já estou estudando todas essas coisas com o que eu acho na rede.

O que eu não acho na rede, no entanto, é o que fazer quando você parece ter mais de um fato em um DW. No meu caso (seguro), tenho reembolsos que ocorram em uma base não regular. Um cliente não pode ter nenhum por 3 meses e depois dez nos mesmos meses. Nas outras mãos, tenho "taxa de assinatura" (não tenho certeza do que é o termo inglês correto, mas você recebe o ponto), que ocorre todos os meses ou a cada três meses. Que parece claramente como dois fatos distintos para mim.

Esses dois são meio fracamente acoplados por algumas dimensões, como o cliente ou o "produto de seguro". Agora são esses dois depósitos diferentes, na qual eu tenho que produzir dois relatórios diferentes e conectar os relatórios fora do DW? Ou existe uma maneira de projetar isso para se encaixar em uma única decição dw. Ou devo combinar esses dois fatos em um? Eu provavelmente perderia a granularidade em reembolsos então.

Algum blog eu li disse que um DW sempre tem uma tabela de fatos. Outros mencionam o passo de projetar quais são as tabelas de fatos com um s, mas não há instrução clara de se houver um link entre eles ou eles são apenas componentes distintos de um mesmo projeto DW.

Alguém sabe algumas referências sobre essa parte precisa do DW Design?

Answer 1

Levando suas perguntas para trás.

Um data warehouse pode ter mais de uma tabela de fatos. No entanto, você quer minimizar as junções entre tabelas de fato. Tudo bem duplicar informações de fato em diferentes tabelas de fatos.

dos objetos que você mencionou:

Reembolso é um fato. O timestamp é a dimensão do fato de reembolso.

taxa de assinatura é um fato. O timestamp é a dimensão do fato da taxa de assinatura.

Um reembolso pode acontecer mais de uma vez. Eu estou supondo que cada cliente tem uma taxa de assinatura. Portanto, parece que temos duas tabelas de fato até agora, cliente e reembolso do cliente.

Se você soubesse que só poderia estar no máximo 3 reembolsos (como exemplo), então você eliminaria a tabela de fatos de reembolso do cliente e colocar 3 colunas de reembolso na tabela do cliente.

Você também menciona o seguro. Um cliente pode ter mais de uma política. Então temos uma tabela de terceiro fato.

Um data warehouse é geralmente projetado usando um Star Schema . O esquema da estrela é basicamente uma tabela de fatos conectada a uma ou mais tabelas de dimensão. Você provavelmente terá mais de uma estrela em um data warehouse, já que já definimos 3 Tabelas de Fatos.

Answer 2

Eu percebo que estou respondendo a um antigo post, mas não estou satisfeito com nenhuma das respostas fornecidas. Eu sinto que nem respondi a pergunta.

Um esquema pode ter um ou mais fatos, mas esses fatos não estão ligados por nenhum relacionamento fundamental. É melhor prática de não participar de tabelas de fatos em uma única consulta como você faria com que se consulte um banco de dados normalizado / transacional. Devido à natureza de muitos a muitas junções, etc - os resultados seriam incorretos se tentados.

A resposta que você está procurando é que você precisa "perfurar", que basicamente significa que você está consultando cada tabela de fatos (esquema) separadamente e mesclando os resultados. Isso pode ocorrer usando o SQL ou preferencialmente por meio de uma ferramenta de relatórios / analíticos que você pode ter que referenciou o data warehouse. Em vez de duplicar as respostas sobre como fazer isso, directo a todos para dois artigos muito bons:

Três maneiras de perfurar por Chris Adamson

e

deve do armazém - perfuração através de Ralph Kimball

Answer 3

Você pode ter tantas tabelas de fato quanto quiser.No seu exemplo, você pode ter algo como:

dimproduto lista vários produtos - assinatura sendo uma delas. dimtransactiontype Listaria possíveis transações (compra, reembolso, taxa de assinatura recorrente ...)

Agora suponha que você esteja interessado em relatórios simplificados de assinatura, você poderia adicionar um factsubscription assim: