A fato é a principal tabela do Data Warehouse, ela fica no centro do Star Schema e é rodeada por dimensões.

A tabela fato armazena o que ocorreu, é o fato propriamente dito, por isso ela tem esse nome, porque é o fato ocorrido.

É na tabela fato onde as métricas são armazenadas, junto com as surrogate keys que ligam às dimensões que descrevem essa métrica.

Existem 6 tipos de fatos:

Fato transacional

Fatos transacionais são as mais comuns. A maioria dos bilhões de linhas que temos no Data Warehouse são de tabelas fato transacional. Elas geralmente utilizam métricas aditivas, aquelas métricas que a gente pode somar por todas as dimensões.

Vou explicar duas formas que a gente armazena os dados em uma fato transacional.

Em uma forma de transação por linha

A cada transação que ocorre, você insere uma nova linha.

Nesse exemplo, é uma fato de vendas. Então cada item de uma venda vai ser salvo em uma linha da fato.

É claro que você já sabe que nas colunas de dimensão não vai estar realmente o nome do item, mas uma surrogate key. O exemplo foi feito assim apenas para facilitar a visualização.

Agora, imagina que eu vou no mercado comprar 3 Coca-Colas.

Foi registrado que no dia 10/12/2016, foi vendido uma Coca-Cola para o cliente Piton em Porto Alegre, e quem fez essa venda foi a Bia. Ali também tem o código da transação, que é uma dimensão degenerada, e o valor unitário desse produto, quantos itens foram vendidos, se tinha desconto, e o valor final da compra.

Mas foram 3 Coca-Colas que eu comprei, então como é uma transação por linha, vou inserir uma nova linha para cada item, mantendo o mesmo código da transação, porque foi a mesma compra.

Aí eu saí da loja e fui pra casa, mas chegou visita e tomaram minhas Coca-Colas. Então de noite eu fui lá buscar mas Coca-Cola, e gerou uma nova transação, porque agora é uma nova compra.

Então basicamente é isso, quando a gente registrar na fato uma transação por linha, é dessa forma que vai ficar. Uma coisa que você vai ver é que a quantidade do item vai ser sempre 1 e o valor da venda vai ser quase sempre igual, exceto se o desconto mudar.

É interessante trabalhar dessa forma quando você tem desconto, por exemplo: Na compra de 3 itens, o último tem um desconto.

Aí já muda, eu vou ter um desconto em um dos itens.

Em uma forma de linha por transação

Essa é outra forma que a gente utiliza para trabalhar uma foto transacional.

Vou fazer a mesma leitura aqui, no dia 10/12/2016, o cliente Piton comprou uma Coca-Cola em Porto Alegre e quem fez a venda foi a Bia. O código da transação é o mesmo lá de cima porque é a mesma compra, só que está sendo representada de um jeito diferente.

Mas aqui é uma linha por transação. Ou seja, essa transação, que é a mesma que repetiu três vezes no primeiro exemplo, vai ser um único registro nessa fato. O preço unitário aqui segue o mesmo, mas na quantidade eu vou ter 3. Aí no valor da venda vou ter já o total da compra, que vai ser 10,40.

A forma de uma linha por transação é a mais utilizada. Mas porque eu estou mostrando os dois? Para você saber como que isso pode ser feito.

E como nesse exemplo, às vezes você quer ver uma variação por item, como foi o caso do desconto, e precisa ter uma transação por linha. Mas em via de regra, o mercado trabalha com uma linha por transação.

Fato agregada

Essa fato tem a função de acelerar o desempenho das consultas.

Tenho aqui um exemplo com uma fato visitantes e dimensões de data e hora. Não coloquei os atributos porque a ideia é que você entenda a técnica.

A dimensão de data é a clássica dimensão de tempo, e a de hora é onde tem a hora e o minuto.

Que problema que essa fato resolve?

Ela vai monitorar os visitantes de um determinado site, por isso temos as dimensões de site e canal, sendo o canal o meio por onde o visitante chegou na página.

A fato vai monitorar as pageviews, ou seja, sempre que alguém acessa o site.

Mas eu não quero ver os visitantes por minuto, quero eles consolidados.

Aí você vai pensar: mas isso aí as ferramentas de BI já fazem em tempo de execução.

Sim. E a maioria dos projetos deixa dessa forma, deixa a ferramenta consolidar já em tempo real. Mas pensa em um caso aqui que é um site que a gente tá fazendo a análise de visitantes, que existem milhões de pageviews por segundo.

Imagina pedir para a ferramenta de BI conectar no Data Warehouse e consolidar elas em tempo de execução, pensa no tempo que vai levar.

Então quando tem esse tipo de situação, você provavelmente vai ter problema de performance porque o dashboard vai demorar pra carregar.

E como se resolve isso? Existe um conceito pra isso, que é a fato agregada.

Fiz um exemplo dessa fato, onde tenho a data mostrando o dia, a hora por minuto, o canal, a página e a quantidade de pageviews.

Aqui eu fiz só dos minutos da hora 13, do dia 10, do canal facebook e da página home, mas uma fato completa teria todos os dias, todos os minutos de todas as horas, de todos os canais e de todas as páginas, ou seja, seria um monstro.

Mas o que o cliente precisa ver é isso aqui:

O total de pageviews por dia e por canal.

É aí que entra a fato agregada, ela serve para juntar um bolo de dados quando eu não quero analisar no nível do grão.

E como que fica então? Você cria uma fato agregada com os dados que precisa e fica com uma fato normal e outra agregada.

Fato consolidada

Essa é bem parecida com a agregada, mas serve para combinar 2 tipos de processos.

O que é processo? Área de negócio, área de assunto, processo de negócio.

Diferente da fato agregada, que serve para consolidar as coisas. A fato consolidada é para consolidar duas fatos.

Mas calma, você não vai fazer nenhum join com as fatos. O que acontece é que no processamento do ETL, na hora de carregar a fato, você vai carregar uma, carregar a outra, e misturar as duas. Evidente que o grão precisa ser o mesmo.

Um exemplo clássico: você tem uma fato venda, e depois precisa juntar ela com uma fato venda orçada.

É claro que você pode fazer uma dimensão de cenário e já colocar lá se ela é orçada. Mas isso é em um mundo ideal onde você começa seu Data Warehouse do zero sem nenhum problema. E muitas vezes, mesmo que não tenha sido um desleixo, na hora de fazer o levantamento de requisitos, ninguém nunca falou que seria necessário trabalhar com orçamento de venda, então ao invés de criar uma dimensão de cenário e reprocessar tudo, foi feito uma nova fato. São várias situações em que isso pode acontecer.

As fatos consolidadas adicionam uma complexidade extra no processamento do ETL. Você vai ter que reconfigurar um monte de coisa ou simplesmente fazer um novo, como a maioria das pessoas faz.

É sempre importante você entender onde isso aqui se encaixa e analisar pontualmente, vai ter que olhar o problema e ver como resolver.

Exemplo:

Tenho aqui uma fato venda e dimensões de cliente, produto e tempo, o de sempre.

Então apareceu o problema do valor orçado que ninguém tinha falado e foi criada uma nova fato.

Depois disso, você cria uma fato consolidada e coloca nela o valor real e o orçado, que antes estavam em fatos diferentes.

E os dados dela você pode pegar tanto das fatos como lá da origem.

Fato snapshot periódico

Vou mostrar 3 opções de como isso se comporta.

A opção #1 é uma fato transacional, é um exemplo clássico de uma fato estoque. Ela controla o produto, quantidade de entrada, quantidade de saída e o saldo do produto.

No dia 23/10/2017, às 6h, eu tive a entrada de 2000 cafés no estoque, e nesse mesmo horário, uma saída de 500, ficando com um saldo de 1500.

Depois, ao meio dia, foi feito um novo pedido para o fornecedor, então entrou mais 400 cafés e depois saiu 1500, ficando com o saldo de 400. E assim por diante.

O que é o snapshot periódico, então? Ele é baseado no tempo, seja data, dia, semana ou hora. Nesse exemplo a gente vai trabalhar no dia.

Na opção #2, temos uma snapshot periódica, que é a famosa foto. Eu tiro uma foto do momento atual e salvo ali.

Ela tem as colunas de entrada e saída, que são opcionais, mas é bom colocar, porque o pessoal de negócio sempre pede esse tipo de métrica adicional.

Essa opção salva só o saldo final do dia, então se fosse fazer uma análise em cima dessa fato, teria o saldo do estoque dia a dia.

Isso é bem comum, pega um Wallmart da vida e olha a quantidade de entra e sai de estoque, então você vai precisar usar esse tipo de tabela, onde vai ter somente o consolidado daquele dia.

Então porque já não deixa só assim, sem a fato anterior?

Como eu falei, às vezes nós precisamos ter uma visão como na opção #1, mas em outros casos, vamos precisar de uma visão como na opção #2.

Nesse caso do exemplo você tem as duas opções, mas se não tiver a fato transacional, pode pegar direto do ETL e jogar para a snapshot. Mas quando tem a transacional, é mais fácil ler ela e jogar na outra fato.

Na opção #3 do exemplo, tenho uma fato transacional diária, que é uma abstração da opção #2, então tenho a entrada e saída de produtos no dia.

E também uma fato de snapshot mensal.

Então quando chega no último dia do mês, você pega o saldo e joga lá na snapshot mensal.

Lembrando: é possível fazer isso direto pelo ETL, mas a snapshot geralmente é feita em cima de outra fato.

Fato de snapshot acumulado

Essa fato vai ser dividida em três etapas de atualização, mas entenda que etapa de atualização não é update na fato.

Então qual a diferença de um snapshot acumulado para periódico? O periódico pega o momento no período, tira uma fotografia e insere na fato. O acumulado também é uma fotografia, mas em mais de um momento.

Como exemplo, peguei um caso que eu trabalhei, em um centro de distribuição.

Nele, temos 3 colunas de datas, que são uma role-playing dimension, que eu já expliquei no post sobre tipos de dimensões.

É uma fato de estoque normal, de recebimento e controle do centro de distribuição. Ela controla a quantidade recebida do produto, a quantidade inspecionada e a quantidade armazenada.

E como funciona essa fato?

Passo 1

Primeiro, isso é um processo demorado, então em um primeiro momento, se recebe um lote de produtos.

Então no dia 02/06/2017 foi recebido 100 itens do produto 1. Aí no sistema de negócio deles, vão entrar com o processo de inspeção.

Passo 2

No outro dia aconteceu a inspeção e eu preciso armazenar isso na fato. Mas não vou deletar tudo, eu simplesmente revisito a fato.

Ou seja, não estou atualizando ou dando um update, mas voltando na fato, porque a carga dela ainda não foi concluída.

Passo 3

Depois, no dia 04/06/2017, os produtos foram armazenados, aí novamente, a fato é revisitada e a data de armazenamento e quantidade são inseridas nela.

Algumas questões extras:

Muitas vezes as pessoas acham que isso aqui vai aumentar a complexidade do ETL e vai ficar mais difícil de controlar, e é verdade, vai mesmo.

Você está fazendo paradas no processo por dias, então o processo não vai terminar nesse tempo. Algumas pessoas preferem dar uma carga só depois que já foi tudo carregado, o que é possível também.

Esse caso aqui é para quando você precisa monitorar o avanço, por exemplo, quando eu quero entender quanto tempo levou entre receber e inspecionar, ou inspecionar e armazenar.

É importante você entender aqui: quando você precisa revisitar a fato para inserir mais dados nela sem deletar o registro que já tinha, isso se chama snapshot acumulado.

Quem geralmente usa isso aqui? Logística ou times de venda/entrega.

E como que é feito no geral? O ETL vai lá e carrega o primeiro campo, depois deixa a carga, ou seja, o job, voltar depois de tantos dias, então carrega um outro pedaço, e depois que está completo, ele dá OK naquele processinho ali.

Fato sem fato

Uma tradução pro nosso dia a dia seria fato sem métricas.

Ela também é chamada de fato de associação ou de intersecção, mas o termo técnico é fato sem fato ou factless fact table.

E para que serve? Para fazer uma intersecção de dimensões. Às vezes a gente quer comparar ou cruzar algo somente entre duas dimensões e não tem uma métrica para fazer essas comparações.

Essa fato é a exceção, só é usada quando se precisa fazer uma intersecção entre as dimensões.

Dois exemplos de fato sem fato: frequência de aluno ou venda com promoção.

Qual é a ideia?

Tem o aluno e a universidade, aí tem um curso, um professor e a dimensão de tempo.

E tem a fato frequência. O objetivo dessa fato é fazer a associação entre as dimensões.

Ou seja, quero comparar os alunos com os cursos, os alunos com os professores, o tempo com o curso, o curso com o professor, e por aí vai, mas não tem nenhuma métrica envolvida.

Importante: eu poderia ter uma fato transacional escrito quantidade de alunos, mas a gente não vai fazer isso, a ideia aqui é apresentar uma fato de associação.

E normalmente quando precisa desse tipo de fato é nesse caso que eu vou mostrar ou uma análise do que não vendeu em uma promoção.

Por que isso acontece? Lembra que para entrar na fato precisa ter um fato ocorrido, e que se não tem fato não tem dado?

Por exemplo: No dia 10 de dezembro entrou um aluno para o curso de design de Data Warehouse, então assim, esse é um fato que ocorreu e ponto, é uma fato transacional. Agora, eu quero saber o que não aconteceu, ou seja, quando tem nulo, de não aconteceu nada.

Você pode ver que nesse exemplo a fato só tem Foreign Keys, eu uso ela só para fazer os cruzamentos e apresentar os dados, porque se não eu não teria como ver. É isso.

Alguns desses tipos não serão utilizados no seu dia a dia, mas é importante você saber que todos existem para poder voltar neles quando alguma situação atípica acontecer. Então mesmo que não aplique todos eles, tenha essa lista à mão para quando precisar.

E para completar, leia também sobre os tipos de métricas e de dimensões. E caso ainda tenha dúvidas sobre como criar as tabelas fatos e definir suas métricas, dê uma olhada no post sobre modelagem de Data Warehouse.