Posso ter códigos não-medida misturado com medidas na minha tabela de fato?

Question

Estamos fazendo um pouco complexo de acumulação de dados. Nosso cliente nos envia algumas coisas que inclui duas dimensões (tempo e uma unidade de negócio). Tempo é principalmente ano-mês. A dimensão da unidade de negócios tem apenas alguns atributos:. Um nome, e algumas categorias às quais BU de podem pertencer para fins de relatório e análise

O material que nos enviar inclui algumas informações sobre o estado atual (datas e códigos). Estes parecem fato-like. Eles também enviar alguma informação que caracteriza a relação com a unidade de negócio (principalmente códigos adicionais). Novamente, estes são únicos para o período de unidade de negócios e tempo.

Finalmente, eles enviam-nos coisas que são claramente fatos aditivos. Ele inclui moeda e conta que têm unidades adequadas.

Devo misturar esta informação qualitativa em uma única tabela de fatos com os fatos aditivos? Ou devo separar o material qualitativo (que só pode ser usado com contagem) a partir do material quantitativo (que pode ser usado com uma soma)?

Answer 1

Só colocar as coisas na tabela de fatos se eles são degenerados (causando uma alta cardinalidade / problemas de unicidade em sua dimensão onde leva a dimensão para uma relação 1-1 a tabela de fatos). Kimball recomenda evitar a tentação de colocar qualquer coisa, mas dimensões degenerados com os fatos (número de ordem único, por exemplo).

Você pode sempre colocar estes em que Kimball chama de "lixo" dimensão. Todos esses códigos podem simplesmente ser aglomeradas em uma dimensão lixo. A maioria das datas iria na tabela de fatos como chaves em sua dimensão de data em um papel particular (geralmente com uma chave int natural do AAAAMMDD forma - uma das únicas vezes que não usamos uma chave sem sentido substituto não-identidade)

Eu gosto de ingenuamente ver a estrela como todos os fatos e, em seguida, as colunas que vão para quais dimensões é simplesmente determinada pela conveniência. Não se deve necessariamente vê-los como correspondendo a uma entidade de negócio particular - lembre-se, a estrela não é um estilo ERD normalizada banco de dados OLTP

.

Answer 2

Se os dados é tanto diretamente relacionado ao fato de aditivo e não é algo que você quer ser agrupamento / classificação / pesquisar em, em seguida, colocá-lo na tabela de fatos está bem.

Esteja ciente, porém, que os dados não-aditivos na tabela de fatos vão quer evitar roll-ups ou vai se tornar uma operação com perdas.

Answer 3

Brad Wilson descreve com precisão o risco de adicioná-los à sua tabela de fatos. No passado, eu adicionei atributos lixo à minha mesa verdade apenas para exigir refatoração mais tarde.

O material que nos enviar inclui alguns informações sobre o estado atual (datas e códigos). Estes parecem fato-like. Eles também enviar alguma informação que caracteriza a relação com a unidade de negócio (principalmente adicional códigos). Novamente, estes são exclusivos para o unidade de negócios e período de tempo.

O propósito do negócio fazem as datas servir? De imediato, eu recomendo fazer essas suas próprias dimensões e descrevê-los com precisão.

Como voláteis são os códigos extras que vêm em? Se o grão de sua tabela fato é data e BU, por que não podem ser incluídos na dimensão BU e tratados como mudança lenta atributos?

Sem mais detalhes eu não posso fazer uma recomendação firme, mas estas seriam as primeiras perguntas que eu me perguntava.