Sabemos que a tabela fato é o objeto onde as medidas se concentram e que complementam as descrições que as dimensões de um data warehouse criam. Desta forma, é importante saber como elaborar uma ou algumas boas tabelas fato para agregar o máximo de valor possível nas análises do negócio.

Defina bem o grão – tabela fato é um objeto granular. Sempre comece definindo bem o seu grão e o que se quer medir, as dimensões irão acompanhar entregando mais valor. 

Medidas e dimensões são inversamente proporcionais, ainda que não pareça. Se uma fato possui muitas medidas, ela possivelmente  terá poucas dimensões e o contrário se aplica. Pondere isso quando estiver elaborando a tabela.

Chave primária – tabela fato também deve ter uma chave primária como toda tabela dentro de um banco relacional. É bem comum criarem uma chave primária unindo duas colunas quaisquer garantindo a unicidade de uma determinada linha, não está errado, mas necessita cuidado.

O ideal continua sendo criar um valor único, sequencial ou não, de tipo numérico para cada linha da tabela. Além de ser mais fácil de gerenciar, não torna o ETL um ‘ambiente’ complexo e necessitado de uma atenção especial; o que consome maior tempo.

Evite updates – tabelas fato são melhores gerenciadas com inserts e deletes, updates podem causar problemas além de serem mais lentos, principalmente em grandes ambientes. Tente garantir que todo valor será inserido mesmo que exista um registro antigo. Dependendo da situação, crie particionamento mantendo em linha apenas os fatos atuais.

Garanta a integridade – do mesmo modo que a integridade é a pedra fundamental em um modelo relacional, aqui não é diferente. A tabela fato precisa ser íntegra em refletir fielmente o que está relacionado com a dimensão. 

Qualquer ação que envolva um delete ou truncate na fato deve ser seguidamente acompanhada na dimensão, inclusive, tal processo deve ser iniciado pela fato; sempre que possível.

Faça levantamentos temporários na fato para identificar se há alguma FK corrompida ou sem referência correta com a dimensão.

PIPELINE DE LOOKUP DA DIMENSÃO COM A FATO

É normal termos dúvidas de como gerenciar e garantir a sincronia entre dimensão e fato na hora do ETL, parece meio complexo mas a confusão maior é por conta da ‘troca de chaves’.

Quando carregamos a fato, seja via tabela ou um arquivo qualquer, o que temos ali é um reflexo do que foi extraído do modelo relacional, logo, todas aquelas colunas ID são conhecidas como business key.

O que acontece após, até chegar na carga final para o data warehouse, é uma sincronia e troca das business key do modelo relacional para as surrogate key do modelo dimensional.

As surrogate key (SK) são inseridas na fato de acordo com a business key ou natural key da dimensão. 

Neste modelo simplificado de pipeline o que ele mostra é o seguinte:

  • O processo de lookup no ETL procura pelos valores correspondentes da natural key na dimensão no arquivo ou tabela da fato na área de stage.
  • Ao encontrar, esses valores, o software “substitui” durante o pipeline todos os IDs pela fk.
  • Como as SKs na fato estão relacionadas com as NKs na dimensão, conseguimos realizar qualquer consulta unindo as tabelas, caso esteja no banco.

O processo de lookup pode ser conceituado de forma simplista com um processo de substituição entre as chaves do modelo dimensional.

TIPOS DE FATO

Normalmente em um modelo dimensional, uma única fato é capaz de gerar duas outras totalizando três para cada área de negócio que se deseja analisar.

  • Transacional.
  • Periódica e;
  • Cumulativa

A fato transacional é a mais comum e utilizada em larga escala em qualquer modelo dimensional. Somente criada quando todas as transações são validadas, é dela que são formadas as medidas e as análises para cada área de negócio correspondente.

Daqui também pode surgir uma Fact Factless (fato sem fato) que seria uma subdivisão da original, mas que não possui medidas nem valores que possam gerar medidas para análise.

O maior exemplo deste modelo seria gerar uma fato apenas com os códigos de compra e venda de produto, pedido, código de rastreio e etc.

Fato periódica ou Snapshot – é um tipo de fato que possui um determinado ciclo de vida, não que este ciclo limite a tabela apagando seus dados após X período. O ciclo de vida é utilizado apenas para limitar a quantidade de informações que terá ali.

Por exemplo, uma área de vendas pode ter uma fato especifica para um trimestre. Este seria um caso de snapshot de uma tabela fato. A vantagem é tornar análises mais rápidas e certeiras daquele período de tempo.

O problema seria acumular diversos destes objetos no banco consumindo espaço e poluindo o ambiente.

Uma dica é utilizar uma view da dimensão data apenas com o período e as colunas da dimensão desejada para comparar as datas da fato com a view e retornar apenas o tempo desejado.

Fato cumulativa – esse é um tipo de fato que é muito utilizado quando estamos analisando um determinado processo dentro de uma área de negócio e este processo possui uma data de início e fim bem definidas.

Sua granularidade é com base em um histórico que marca seu início e fim.

O maior exemplo de uso seria para uma empresa de logística que entrega produtos de seus clientes.

Ainda que nesta fato a data de entrega seja desconhecida, é possível criá-la com uma data fim especial ao qual o SCD em suas rotinas diárias irá atualizar a data fim.

INSERÇÃO NA TABELA FATO

Inserções de dados na tabela fato não exigem grandes e complexos processos de ETL, o grande problema costuma ser relacionado a performance de inserção do que dificuldade.

Normalmente uma tabela fato possui muitas chaves estrangeiras e isso costuma gerar lentidão na carga por conta das restrições; o banco precisa garantir a integridade.

Então, aqui vão algumas dicas que podem melhorar sua inserção de dados nesta tabela.

  • Desative ou delete todos os index da tabela fato.
  • Separe os dados que são insert e os que são update.
  • Faça cargas minimamente logáveis; bulk-load.
  • Se for possível, desabilite as fks
  • Utilize paralelismo dentro das ferramentas de ETL.
  • Trabalhe com blocos de dados limitados e contínuos.
  • Evite muitos processos de lookup, deixe somente o necessário para o ambiente.

FATO COM SCD TIPO 1 E DIMENSÃO COM SCD TIPO 2 – COMO RESOLVER.

Em alguns ou na maioria absoluta dos cenários, não existe fato com um slowly changing dimension tipo 2, guardando registro  histórico de um item. Elas têm valores inseridos e só.

Como as SKs desta tabela são  relacionadas com a dimensão e possuem o relacionamento 1:1, uma consulta na fato sempre irá retornar o valor atual de um produto, por exemplo, caso ele tenha sido atualizado desde sua inserção.

Como em algumas situações desejamos juntar a fato com a dimensão analisando os dados históricos que a dimensão possui, algumas soluções podem ser adotadas para que fique conforme.

  1. Crie uma dimensão SCD tipo 2 apenas para situações pontuais e dimensões extremamente importantes. 
  2. Envolver na query entre fato  e dimensão a coluna com a versão do ETL retornando apenas os registros atuais, ou;
  3. Criar uma dimensão com tipo 2 e ligar tanto sua SK quanto NK na fato, o que a tornaria grande no sentido colunar, mas garantiria uma consulta adequada e com mais performance

LATE ARRIVING – ENTREGAS TARDIAS

Este é um cenário um tanto peculiar e até pouco usual onde ocorre uma carga de dados muito antigos ou dados que são inseridos bem depois do ocorrido. Às vezes a diferença pode ser de anos.

Imagine o seguinte cenário:

Um ambiente que possui uma dimensão com SCD tipo 2 ligada a fato e que mantém seus registros históricos. Essa dimensão possui 3 versões do mesmo registro devido às atualizações que ocorreram.

Essa inserção tardia esta situada entre as datas das  versões 2 e 3 do registro, e precisa ser carregada neste ambiente. O processo para inserir esse registro ocorre da seguinte forma:

  1. Localizar a dimensão e o devido registro de forma correta e entender como os dados e as versões estão dispostos no local.
  2. Execute um join entre a dimensão e fato pela SK.
  3. Ao identificar, reponha esse registro na fato entre as datas corretas.
  4. Se necessário for, faça uma carga na dimensão com as datas devidas para garantir a devida sincronia entre dimensão x fato.
  5. Se houver particionamento, consulte a tabela particionada para  com conjunto para não ter problemas, caso seja necessário, atualize-a também.

Com este procedimento, sua tabela fato estará sempre atualizada e em conformidade com as exigências das áreas de negócio.

CONCLUSÃO

Este foi um post mais teórico e tentei ser breve mostrando apenas algumas situações que podem ser atípicas e tipos de tabela fato, pelo menos as mais utilizadas.

É interessante perceber que de uma tabela fato central, diversas podem surgir agregando ainda mais no conhecimento e nas análises de dados do negócio permitindo uma maximização dos retornos e melhora nos processos.

Ainda que alguns conceitos possam ser básicos, espero que ajudem a esclarecer quaisquer dúvidas que possam ter sobre modelagem e entrega da tabela fato em um data warehouse!

Espero que gostem, deus os abençoe!

Saúde!