Eu e outro DBA da nossa empresa temos a tarefa de revisar um design de banco de dados que um fornecedor desenvolveu para nós. O fornecedor disse que usa Kimball como base para seu design. (NOTA: Não estou procurando argumentos de Kimball vs Inmon, etc.) Eles criaram um mercado com vários fatos e dimensões.
Agora, com toda a justiça, nossa empresa nunca projetou um único mercado. Sempre tivemos os consultores fazendo isso. E nunca fomos enviados para aulas nem nada. Portanto, nosso conhecimento sobre armazenamento / marcadores / modelagem dimensional etc. baseia-se na pouca experiência que temos, no que podemos encontrar na Internet e na leitura pessoal (temos os livros de Inmon e Kimball e estamos tentando fazê-lo). .
Agora que o cenário está preparado para o meu nível de conhecimento, chegamos ao desafio do design.
Existe uma tabela de fatos chamada "Estatísticas de perda de sinistros" (isso é para seguros). E eles estão tentando capturar os pagamentos de reivindicações (acumulados até um nível mensal) e, em seguida, o dinheiro nas reservas (como uma conta bancária para reivindicações). Eles desejam ver os valores mensais dos pagamentos (nada demais). Mas eles desejam ver o saldo atual da conta das reservas.
Vou dar um exemplo pictórico.
Digamos que configuramos US $ 1000 em reservas para uma reivindicação. Isso é anulado (portanto, em alguns aspectos, funciona como uma conta bancária).
Em outubro de 2014, ainda não pagamos nada. Portanto, a empresa deseja ver os pagamentos e o saldo da reserva no final de outubro.
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------Então novembro chega. Fazemos pagamentos de US $ 100, US $ 150 e US $ 75 dólares. Eles desejam ver esses valores agregados e a reserva no saldo da seguinte forma:
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------
- 112014 - 325.00 - 675.00 -
-----------------------------------------------E então digamos que temos zero pagamentos em dezembro e mais US $ 200 em janeiro do próximo ano.
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------
- 112014 - 325.00 - 675.00 -
-----------------------------------------------
- 122014 - 0.00 - 675.00 -
-----------------------------------------------
- 12015 - 200.00 - 475.00 -
-----------------------------------------------Aqui é onde eu luto. Meu entendimento é que a parte de pagamentos está correta. Todos eles são agregados mensalmente em cada registro. Assim, você pode fazer o rollup adicional, se desejar para o ano, trimestre, etc.
Mas o valor das reservas é diferente. É um equilíbrio. E a empresa quer ver quanto está em jogo a cada mês. Mas você não pode agregar neste campo. Se você o fizesse, obteria alguns resultados instáveis.
De alguma forma, isso me parece errado. Mas não posso dizer sinceramente que modelei o suficiente ou sei o suficiente. Tudo o que posso dizer é o que sei. E pelo que sei, todos os valores em um Fato devem ter a mesma granularidade.
Ambos os números têm a mesma granularidade de um "mês", mas não são do ponto de vista do que representam. Um é o agregado de dólares em um mês. O outro é apenas o equilíbrio.
Isso está correto? Eu tenho empurrado para trás este design. Estou errado em fazer isso? Tudo bem fazer isso de fato? Ou o meu senso de "cheiro de código" de um design ruim é preciso?
Qualquer ajuda seria apreciada. NOTA: por favor, não diga apenas "Deveria ser o modo X", por favor, explique por que deveria ser assim para que eu possa aprender com isso.
EDIT : Bem, eu aprendi que meu entendimento inicial do Fato está errado. A granularidade NÃO é mensal. A granularidade é o nível da transação. Isso significa que, dentro de MONTH_YEAR (ou seja, é o período do relatório financeiro), haverá várias transações de pagamento e recuperação. Aqueles serão lançados por data ou data da transação. Porém, devido a um relatório anterior que a empresa vê e também à maneira como os dados são armazenados no sistema legado de origem, eles queriam colocar os dados transacionais (uma linha por) e o saldo mensal de reserva (uma linha por mês). )
Depois que soube disso, percebi que o problema não era tanto aditivo versus não aditivo, nem mesmo semi-aditivo, mas grãos, que era o que eu suspeitava desde o início. Nossa equipe de DBA discutiu isso com a equipe do projeto e relatou que eles estão tentando colocar dois grãos diferentes no mesmo fato, e isso não estava correto. Que eles devem distribuir as transações para um nível mensal, permitindo que eles recebam os pagamentos, recuperações e o saldo da reserva mensal (isto é, um fato semi-aditivo), porque tudo estaria em um nível mensal. Ou eles precisam encontrar uma maneira de dividir o saldo da reserva em transações para preservar a granulação no nível da transação. Ou eles precisam dividir o fato em dois fatos. Um pode ser o nível mensal para o saldo da reserva. O outro pode estar no nível da transação para pagamentos e recuperações. (Não há razão para que eles também não pudessem colocar os pagamentos e recuperações em um nível mensal no fato do nível mensal também. Depende das necessidades da empresa.)
Dado o que aprendi, vou marcar a resposta de Thomas como a correta. No entanto, sinto que a discussão que comecei com a pergunta original ainda é boa para os outros aprenderem, por isso deixarei intacta a parte original da minha pergunta. Também pretendo conceder uma recompensa à resposta de nikadam, pois isso me ensinou muito sobre fatos aditivos, não aditivos e semi-aditivos, e corrigi muitos mal-entendidos que tive sobre modelagem dimensional.
