Recentemente, encontrei as colunas "válido de" e "válido para" em uma tabela de fatos . Obviamente, isso é comum para dimensões, mas nunca as vi em tabelas de fatos antes e não consigo encontrar nenhuma informação sugerindo que sejam amplamente usadas.
A granularidade da tabela é análoga às transações da conta bancária, portanto, um novo fato é gerado quando um depósito é feito ou um valor é retirado. A razão dada para a inclusão das colunas é a necessidade de relatórios consistentes (se executarmos este relatório hoje, deve ser o mesmo de uma semana atrás) combinado com a baixa qualidade dos sistemas/dados de origem; os usuários podem entrar no sistema de origem e dizer "este depósito foi na verdade apenas £ 10, não £ 100". Quando isso acontece, uma segunda linha de fato é inserida e a linha original é expirada.
Na minha opinião, uma nova linha de fato deve ser inserida para inverter a original para manter o histórico (aplicando -£100 no exemplo) e o fato atualizado deve ser inserido (+£10). Parece que trabalhar com as colunas válidas de/para introduz muita complexidade para os usuários ao relatar, bem como o risco de erro (resumindo os fatos ativos e expirados).
Alguém tem experiência com isso e há alguma referência que o aborde especificamente (postagens de blog, artigos ou mesmo livros)?
A validade depende de como os usuários desejam ver os dados. Você está olhando para isso apenas como um fato de transação. Outros tipos de tabelas de fatos incluem instantâneos periódicos e instantâneos cumulativos. Se você quiser ver todas as vezes que alguém corrigiu uma linha para ajudar a diminuir entradas incorretas, as datas efetivas podem ser apropriadas para que fique claro que a transação foi atualizada. Isso cria uma tabela de fatos um pouco semelhante a um SCD tipo 2.
O Grupo Kimball tem um artigo que aborda diretamente a sua pergunta .
Aqui está uma dica de design do Kimball Group que fala sobre tabelas de fatos instantâneos acumulativos com data efetiva.
Você pode estar certo ao dizer que deveria apenas adicionar transações que revertem a linha original. Parece que pode ser uma solução válida se você precisar apenas ver as transações e resumi-las. É assim que tenho visto a maioria dos dados contábeis funcionarem. Kimball diz que as tabelas de fatos com data efetiva podem ser úteis para calcular rapidamente os saldos das contas em um determinado momento, especialmente para rastrear saldos que mudam lentamente . Mas este é um caso bastante raro. Acho que sua preocupação de que será confuso para os usuários também é válida. Você tem que decidir se isso pode ser superado pela educação e se vale a pena pelas capacidades analíticas adicionadas aos dados.
Não tive que fazer tanto em minha experiência com armazenamento de dados porque a maioria dos meus fatos eram transações simples ou instantâneos periódicos. Mas criei várias tabelas de ponte datadas efetivas para relacionamentos muitos-para-muitos.
É a granularidade "transação" ou "saldo atual". Com base na sua descrição, parece que há uma mistura dos dois neste fato. Se a granularidade for "transação", você deverá calcular o saldo e corrigir quaisquer "transações" inseridas incorretamente. Se a granularidade for "saldo atual", você terá que lidar com a diferença entre corrigir um erro e atualizar o valor com base em uma transação.