Sou novo em DW/BI e essa parece ser uma pergunta bastante básica, mas não consigo encontrar uma boa resposta.
Eu tenho uma tabela de fatos que teria mais de uma data associada a ela, então pensei que teria várias chaves de data para a mesma tabela de dimensões, por exemplo, SubmittedDateKey, ClosedDateKey. Obviamente, o SQL Server pode fazer isso - minha reserva é que, quando projetei um esquema de prova de conceito dessa maneira, as ferramentas do cliente (ou seja, Tableau, Excel) pareciam ficar confusas sobre como mapear os relacionamentos. (Também encontrei esta postagem no fórum dizendo que o Analytic Workspace Manager da Oracle proíbe explicitamente isso, o que obviamente não implica nada sobre o meu mundo da Microsoft, mas sugere que é um não-não geral.)
Existe uma prática recomendada em DW/BI sobre isso? Em vez de ter uma tabela de dimensões conectada a cada uma dessas chaves, devo ter várias tabelas de dimensões idênticas, por exemplo, SubmittedDateDimension, ClosedDateDimension?
Obrigado!
Eu usaria a mesma tabela de dimensões. Especialmente para uma dimensão de data
Esta é uma Dimensão de Interpretação de Papel também aqui
Eu não permitiria que uma ferramenta de cliente (ou uma postagem no fórum da Oracle!) determinasse meu design do SQL Server DW.
Geralmente, as ferramentas downstream referenciam seus dados em algum tipo de formato intermediário, como cubos SSAS, arquivos QlikView QVD ou simplesmente CSV. Mas se sua ferramenta de downstream estiver acessando o banco de dados diretamente, você pode simplesmente criar uma série de visualizações, uma para cada dimensão de interpretação. Cada um pode ser definido como
SELECT * FROM Dates. Faça com que o Tableau e o Excel façam referência a eles em vez daDatestabela única.Isso pressupõe que você não esteja usando chaves estrangeiras para direcionar a(s) ferramenta(s) de análise. Nesse caso, recomendo que você os descarte, pois a sobrecarga geralmente não vale a pena para um depósito. Se não puder, você não tem escolha a não ser criar várias
Datestabelas.