Depois de entendermos como uma arquitetura de B.I e D.W se sustenta e é criada, vamos para o próximo ponto que é criar as tabelas de dimensão do D.W.

Além disso, vamos entender como podemos controlar alterações nas dimensões através do recurso SCD (SLOWLY CHANGING DIMENSION).

Conceito

Como sabemos, a tabela dimensão tem como objetivo responder às seguintes perguntas para o processo de negócio (tabela fato)

  1. What?
  2. Why?
  3. When?
  4. Where?
  5. Who?
  6. How many?
  7. How often.

Podemos perceber que criar a tabela dimensão tem base no processo 5W2H na análise de negócios e isto faz todo sentido quando entendemos que B.I é uma ferramenta para melhorar e alavancar o negócio.

Para uma boa modelagem e uma tabela dimensão satisfatória, entenda o máximo possível do negócio que está sendo modelado.

Se necessário for, crie um questionário, analise notas fiscais, possíveis planilhas etc. Estes recursos podem ser úteis para mapear processos que não ficaram claros ou não foram entendidos logo início.

Exemplo simples de uma tabela dimensão com suas chaves. Nos próximos tópicos vamos entender o que cada chave representa.

Assim como na modelagem relacional, a modelagem dimensional também utiliza o sistema de chaves para garantir a restrição de integridade.

As chaves específicas que a tabela dimensão possui, são:

  • Surrogate Key – coluna com chave que cria um identificador único para um atributo da tabela do D.W;
  • Alternative Key – identificador único que é herdado do banco

A surrogate key atua como uma primary key na tabela dimensão.

Já a chave alternativa é um tipo de chave que era PK na modelagem relacional no modelo de negócio e agora é uma chave candidata na tabela dimensão.

A chave alternativa é necessária para o processo de slowly change dimension (SCD).

E porque não devemos utilizar as chaves alternativas da tabela dimensão como chaves primárias no D.W?

Como elas são alternativas, não são aconselhadas para esse tipo de operação pois como dito antes, são utilizadas para controle de mudanças quando configuramos o SCD, além do mais, podemos destacar os seguintes pontos:

  • Podem gerar um plano de execução para o banco muito lento e ineficiente;
  • Alguns podem utilizar chave composta, o que também poderia prejudicar a execução e performance da query;
  • E pelo fato de um D.W receber dados de diversas fontes, pode acabar gerando conflito entre chaves criando problemas com a integridade do banco

Algumas colunas configuradas com o SCD type 2 ( que controla o registro de atualização) esta chave é imprescindível para configurar esse recurso e controlar as mudanças no processo de ETL, logo, se ela for promovida para PK, perdemos este importante recurso, uma vez que não será possível manter um histórico.

Outra coluna importante que temos que ter na tabela dimensão é a METADATA que é usada pelo D.W e pelo processo de ETL para histórico e até mesmo auditoria. Cada linha passa a receber uma TAG que ajuda o D.W a rastrear qual foi a última operação do ETL.

Uma das colunas da categoria metadata é a [batchid] que cria um registro do tipo timestamp que indica o último insert ou update de uma operação de ETL e marcam as operações de SCD com os horários de início e fim.

SLOWLY CHANGING DIMENSION

É um tipo de recurso específico que um D.W possui que controla as mudanças que ocorrem nos dados gravados no banco à medida que elas vão ocorrendo.

Existem três tipos de configuração para o SCD.

  • Type 0;
  • Type 1;
  • Type 2.

Cada coluna do D.W pode receber um tipo diferente de slowly changing dimension

TYPE 0

Na configuração type 0 temos um registro absoluto sobre todas as mudanças que podem ocorrer naquele atributo que foi configurado com este tipo.

Quando realizamos uma mudança em uma linha desta coluna, o velho e o novo registro ficam armazenados para controle e auditoria.

Por ser uma forma de controle mais completa, não é indicada para atributos que possam sofrer atualizações constantes. Muito recomendado pra atributos tipo: Nome, RG, CPF, CNPJ etc.

TYPE 1

É o modelo de controle que reescreve no D.W as alterações que ocorreram na fonte ocasionadas pela aplicação ou qualquer outro ERP e etc.

Se a coluna da tabela dimensão tem grande participação em relatórios da empresa, esse tipo de configuração de SCD não é muito recomendado.

TYPE 2

Já o modelo type 2 cria um registro histórico do atributo original com horários de inicio e fim daquela linha, indicando o período que o registro anterior era válido e o início do registro atual.

Este modelo é muito similar ao modelo de controle implementado em bancos relacionais OLTP utilizando o recurso de temporal tables.

Como ocorre o SCD Type 2?

Quando realizamos uma operação de carga no D.W ao final do processo de ETL, o controle de versão verifica se o registro que está sendo inserido é novo ou se está atualizando um existente verificando o registro histórico que esta coluna possui.

Se for um registro inexistente, apenas insere e cria o histórico para esta linha. Se não, atualiza a linha e altera o histórico existente com novas datas de início e fim da operação.

NOTA: se ao consultar um valor histórico de uma determinada linha do d.w e na data final dela o valor for null ou 31/12/9999 podemos considerar este valor sendo atual.

Veja o seguinte cenário para esclarecimento:

Suponhamos que a nossa carga de ETL no D.W termine sempre 00:30, logo podemos concluir que o registro da cliente Alice foi criado no dia 01/01/2020 e foi validado pelo D.W no dia 02/01 às 00:30.

No dia 05/10 a mesma cliente fez uma nova compra, informado o novo endereço que foi validado no processo de ETL e carregado para o D.W na rotina da madrugada, alterando a cidade em que vive. Logo, este primeiro registro passa a ter uma nova data de fim, veja.

Como nosso processo de ETL termina sempre 00:30, então no dia 06/10, os novos registros serão validados no D.W, mostrando a atualização da cidade realizada pela cliente. Passando a ser exibido desta forma.

Repare que enquanto não houver uma nova atualização nos dados da Alice, a data fim será 31/12/9999 ou, em alguns casos, NULL.

COMO ESCOLHER ENTRE STAR-SCHEMA E SNOWFLAKE

Alguns podem se perguntar se existe uma forma correta de modelagem ou se temos de adotar um modelo fixo para criar o D.W, e com ele ir até o final tendo assim que escolher entre os dois tipos de modelo, e a resposta é  não, você não precisa.

A possível escolha do modelo vai depender da complexidade e do processo de negócio que estamos modelando para validar o data warehouse, assim como, das necessidades e requisitos do negócio e das partes interessadas.

O que podemos perceber é que muitos projetos começam com o modelo star schema, uma vez que ele é mais simples e fácil de compreender e este vai evoluindo para o modelo snowflakes uma vez que mais dimensões vão sendo adicionadas.

Entenda que quanto mais dimensões criadas, maior complexidade do modelo e é natural que o modelo star schema acabe evoluindo se tornando um mix entre os dois, o que muitos chamam de modelo STARFLAKE.

Modelo final também podendo ser conhecido como STARFLAKE

Com isso, terminamos o processo de entendimento sobre as tabelas dimensões, os processos e controles de mudanças, o que ela representa no modelo dimensional, seus tipos de chave e se devemos escolher entre os dois modelos star schema e snowflakes.

No próximo post será sobre tabela fato, espero vocês lá!

Saúde!