Início / dba / Perguntas / 182851
Accepted
mheptinstall
Asked: 2017-08-08 02:51:04 +0800 CST

Booleano como medida na tabela de fatos ou valor de dimensão/atributo

  • 772

Minha tabela de fatos consiste em reclamações com dimensões típicas de quem, o quê e quando. Temos uma meta de que a reclamação deve ser respondida dentro de um determinado período de tempo.

Não tenho certeza sobre a melhor forma de modelar se a reclamação teve uma resposta dentro desse período de tempo.

Posso armazenar o valor de destino e o resultado na tabela de fatos como números inteiros com o resultado como medida. Ou eu poderia usar uma dimensão que tem valores de sim/não em vez de representar isso como uma medida, eu poderia usar uma medida calculada no meu cubo. Ou eu poderia usar uma combinação de ambos.

Existem prós, contras e pegadinhas modelando os fatos das formas descritas acima?

Prevejo que esta tabela de fatos será usada para obter o número total de reclamações, o número de reclamações respondidas a tempo, a porcentagem respondida a tempo e também identificar reclamações individuais que não foram respondidas a tempo.

data-warehouse dimensional-modeling

1 respostas

  1. Best Answer

    Aqui está uma maneira flexível de armazená-lo que deve suportar mudanças nos requisitos no futuro.

    • Armazene o destino em uma dimensão como dim_complaint_type. Dessa forma, se no futuro você tiver diferentes tipos de reclamações – por exemplo, Faturamento, Técnico, ... – cada uma delas pode ser categorizada e ter alvos diferentes. Ao aplicar o tipo 2 de dimensões de alteração lenta no atributo de destino, você também pode alterar sua meta de um ano para outro sem alterar o resultado de reclamações anteriores. Você também pode fazer análises hipotéticas alterando o destino em uma dimensão e ver quanto mais/menos estão no prazo.
    • Armazene o tempo de resposta na tabela de fatos, como elapsed_time (inteiro) ou como registration_date e closure_date conforme sugerido nos comentários. Minha preferência vai para registration_date e closure_date com uma coluna calculada elapsed_time que é registration_date - closing_date.

    Para o resultado, eu não o armazenaria como um sinalizador (sim/não), mas como um número. Se você ligar para a coluna on_timee colocar 1 para cada reclamação que atende à meta, poderá facilmente SOMAR nessa coluna para ter o total de reclamações on_time em um período.

    Eu vejo três maneiras de obter o resultado:

    • Não armazená-lo, mas calculá-lo em tempo real em seus relatórios, tendo a mesma fórmula em todos os lugares para verificar se fact_complaint.elapsed_timeé menor ou igual dim_complaint_type.targetou não. Pode ser perigoso se pessoas diferentes usarem fórmulas diferentes. Se você tem uma ferramenta com uma camada de metadados (por exemplo, OBIEE, SAP BO, ...), você pode definir essa medida de resultado de uma vez por todas.
    • Crie uma visualização que una fact_complaint e dim_complaint_type e inclua essa medida de resultado na lista de seleção. Seria definido de uma vez por todas. Mas você precisa ter cuidado com essa abordagem, pois alguma ferramenta de relatório pode não agir da mesma maneira com uma tabela ou visualização. O otimizador de banco de dados também pode não ser capaz de fazer toda a sua mágica da mesma maneira.
    • Na verdade, armazene-o em sua tabela de fatos (ou seja, calcule-o em tempo de ETL). Esta é provavelmente a melhor abordagem em termos de desempenho. Mas é necessário atualizar essa coluna se você alterar o destino de algumas reclamações anteriores.
    • 4

relate perguntas