E como lidar com SCD type 2 | ETL com Integration Services: transformação de dados

Estamos em um projeto onde todos do time fizeram essa formação da Alura, mas estamos esbarrando nesse exemplo....

Aqui, na tabela pai e filho, se uma vinculação mudar você vai sobrescrever tudo...

Mas e se eu não puder sobrescrever... se eu precisar manter o histórico.

Senti falta de exemplo de Slow Changing Dimension tipo 2, porque se em janeiro eu estava vinculado a são paulo e em fevereiro eu mudar minha vinculação para o rio de janeiro, um relatório que mostra as vendas do rio de janeiro por vendedor não pode "herdar" meu resultado de são paulo.

Para outros tipo de tabela, conseguimos adaptar relativamente fácil esse cenário, mas para tabelas do tipo pai e filho, gostaríamos da sua opinião de como lidar com isso.

Duany

Vamos primeiro como tratar dimensões PARENT-CHILDREN como SCD Type 2.

Vamos supor o exemplo abaixo.

FILHO	PAI	DATA INICIAL	DATA FINAL
SP		01/01/1001	31/12/2999
RJ		01/01/1001	31/12/2999
VEND1	SP	01/01/1001	31/12/2999
VEND2	SP	01/01/1001	31/12/2999
VEND3	RJ	01/01/1001	31/12/2999

Aplicando a mudaça ( VEND1 passa de SP ára o RIO DE JANEIRO)

FILHO	PAI	DATA INICIAL	DATA FINAL
SP		01/01/1001	31/12/2999
RJ		01/01/1001	31/12/2999
VEND1	SP	01/01/1001	31/01/2020
VEND1	RJ	31/01/2020	31/12/2999
VEND2	SP	01/01/1001	31/12/2999
VEND3	RJ	01/01/1001	31/12/2999

Como Vendedor é folha, a mudança é simples.

Mas quando o NÓ que muda tem descendentes, todos os seus descendentes devem mudar sua data de validade inicial e final.

Agora, vamso supor que tivéssemos:

CLI1, CLI2, CLI3, CLI4, CLI5, CLI6, CLI7 deste jeito:

FILHO	PAI	DATA INICIAL	DATA FINAL
SP		01/01/1001	31/12/2999
RJ		01/01/1001	31/12/2999
VEND1	SP	01/01/1001	31/12/2999
VEND2	SP	01/01/1001	31/12/2999
VEND3	RJ	01/01/1001	31/12/2999
CLI1	VEND1	01/01/1001	31/12/2999
CLI2	VEND1	01/01/1001	31/12/2999
CLI3	VEND2	01/01/1001	31/12/2999
CLI4	VEND2	01/01/1001	31/12/2999
CLI5	VEND3	01/01/1001	31/12/2999
CLI6	VEND3	01/01/1001	31/12/2999
CLI7	VEND3	01/01/1001	31/12/2999

Se o vendedor VEND1 foi pro RIO, ele tem que deixar seus clientes com algum vendedor de SP cuidar e ele vai assumir alguns clientes do Rio, que eram do outro vendedor carioca.

FILHO	PAI	DATA INICIAL	DATA FINAL
SP		01/01/1001	31/12/2999
RJ		01/01/1001	31/12/2999
VEND1	SP	01/01/1001	31/01/2020
VEND1	RJ	31/01/2020	31/12/2999
VEND2	SP	01/01/1001	31/12/2999
VEND3	RJ	01/01/1001	31/12/2999
CLI1	VEND1	01/01/1001	31/01/2020
CLI2	VEND1	01/01/1001	31/01/2020
CLI1	VEND2	31/01/2020	31/12/2999
CLI2	VEND2	31/01/2020	31/12/2999
CLI3	VEND2	01/01/1001	31/12/2999
CLI4	VEND2	01/01/1001	31/12/2999
CLI5	VEND3	01/01/1001	31/12/2999
CLI6	VEND3	01/01/1001	31/01/2020
CLI7	VEND3	01/01/1001	31/01/2020
CLI6	VEND2	31/01/2020	31/12/2999
CLI7	VEND2	31/01/2020	31/12/2999

Acima, quando o vendedor VEND1 foi pro Rio ele passou os clientes CLI1 e CLI2 para o VEND2, que continua em SP e assumiu os clientes CLI6 e CLI7 que eram do vendedor VEND3.

Se você notar a chave do NÓ passa a ser o código original + DATAS VALIDADES.

Teria que pensar como implementar esta lógica no SSIS. Mas é assim que as dimensões PARENT-CHILD devem ser tratadas quando possuem SCD TYPE 2.

Att

Victorino.