Slowly Changing Dimension

Vamos conhecer um pouco do conceito de SCD, muito usado no dia a dia de um Data Warehouse. By Lito – Consultas no Wikipedia, Ralph Kimball, Margy Ross (The Data Warehouse Toolkit), John Wiley & Sons, Bruce Ottmann, Chris Angus (Data processing system), Kimball University (Handling Arbitrary Restatements of History).

 

Dimension (Dimensão) é um termo em gerenciamento de dados e Data Warehousing que se refere a agrupamentos lógicos de dados como localização geográfica, as informações dos clientes, ou informações sobre o produto. Slowly Changing Dimensions (SCD) são dimensões que têm dados que mudam lentamente ou seja, as mudança em suas informações ocorrem em grandes espaços de tempo. Podemos citar, por exemplo, um Cliente que esta cadastrado a 5 anos e que agora esta casado, após cinco anos de cadastramento, só agora faremos uma mudança em seu cadastro, informando o seu casamento. 

Outro exemplo, temos uma dimensão em nosso banco de dados que controla os registros das vendas da nossa empresa, por vendedores. A criação de relatórios de vendas parece bastante simples, até que um vendedor é transferido de um escritório regional para o outro. Como gravar essa alteração na nossa dimensão de vendas? 

Poderíamos somar ou tirar a média de vendas por vendedor, mas se usarmos isso para comparar o desempenho dos vendedores, teremos com certeza, informações enganosas.  Se o vendedor que foi transferido costumava trabalhar em um mercado quente, onde as vendas eram fáceis, e agora trabalha em um mercado onde as vendas são pouco frequentes, seus totais ficarão muito mais forte do que os outros vendedores em sua nova região, mesmo que eles sejam bons.  Podemos também, criar um novo registro para o vendedor transferido, como se fosse uma pessoa nova em vendas, mas isso traria problemas também. 

Lidar com essas questões envolve metodologias de gestão nas SCD, que podemos definir como TIPOS. Temos gerenciamentos dos tipos 1, 2, 3, 4 e 6.  SCDs Tipo 6 são também chamados de híbridos SCDs. 

Tipo 0  

O método do tipo 0 é uma atitude passiva para a gestão de mudança do valor na dimensão, nenhuma ação será tomada. Values remain as they were at the time the dimension record was first entered. Os valores permanecem como estavam no momento da inclusão do registro na dimensão. In certain circumstances historical preservation with a Type 0 SCD may occur. Em determinadas circunstâncias, a preservação histórica com um SCD tipo 0 pode ocorrer. But, higher order SCD types are often employed to guarantee history preservation, whereas Type 0 provides the least control or no control over managing a slowly changing dimension. Mas, os tipos de ordem superior (1 a 6) são frequentemente utilizados para garantir a preservação da história, enquanto o tipo 0 fornece o menor controle ou nenhum controle sobre o gerenciamento de uma SCD.   

Os tipos mais usados em SCD são os tipos 1, 2 e 3.  

Tipo 1  

A metodologia do tipo 1 substitui os dados antigos com os novos dados e, portanto, não controla os dados históricos em tudo.  Este é o mais adequado para corrigir certos tipos de erros de dados, tais como a ortografia de um nome  (Supondo que você não vai precisar saber como ele costumava ser incorreto no passado). 

Outro exemplo seria o de uma tabela do banco de dados que mantém informações do fornecedor.

Supplier_key      Supplier_Name         Supplier_State  
001     Phlogistical Sociedade de Abastecimento        CA 

Agora imagine que este fornecedor mude a sua sede para Illinois.  A atualização da tabela seria simplesmente substituir este registro:

Supplier_key      Supplier_Name         Supplier_State  
001      Phlogistical Sociedade de Abastecimento       IL 

A desvantagem óbvia deste método de gestão SCD é que não há registros históricos mantidos no armazém de dados.  Você não pode dizer se seus fornecedores estão tendendo a ir para o Centro-Oeste, por exemplo.  Mas a vantagem disto é que estes são muito fáceis de manter 

Tipo 2  

No método de Tipo 2,  faixas de dados históricos são criados. Criando vários registros nas tabelas de dimensões com chaves separadas.  Com o tipo 2, temos a preservação ilimitada da história, pois um novo registro é inserido cada vez que uma alteração é feita. 

 No mesmo exemplo, se o fornecedor passa a Illinois, a tabela ficaria assim:

 Supplier_key       Supplier_Code        Supplier_Name            Supplier_State      versão  
001  ABC        Phlogistical Sociedade de Abastecimento            CA      0 
002  ABC        Phlogistical Sociedade de Abastecimento             IL       1 

Outro método popular para essa versão é adicionar colunas para a data de vigência.

 Supplier_key    Supplier_Code    Supplier_Name    Supplier_State    Data_inicial   Data_final  
001  ABC  Phlogistical Sociedade de Abastecimento  CA  01-Jan-2000  21-Dec-2004
002  ABC   Phlogistical Sociedade de Abastecimento  IL  22-Dec-2004   

Nulo na Data_final significa versão atual.  Em alguns casos, uma data de substituição elevada (por exemplo, 9999-12-31) pode ser usado como uma data de término, de modo que o campo possa ser incluído em um índice. 

As operações que fazem referência a esta chave substituta (Surrogate_Key) são, então, permanentemente ligados a essas frações de tempo definido por cada linha na Dimensão SCD.  Se houver mudanças a posteriori feitas no conteúdo da dimensão, ou se um novo conjunto de atributos é adicionado à dimensão (por exemplo, uma coluna de Representante de Vendas), que têm diferentes datas de vigência aos já definidos, então isso pode resultar na necessidade das atuais  operações serem atualizadas para refletir a nova situação.  Esta pode ser uma operação de banco de dados cara, Neste caso tipo 2 SCD pode não ser uma boa opção, pois o modelo dimensional está sujeito a alterações.

Tipo 3

No método do tipo 3 são criadas colunas separadas para representar as faixas das alterações.  Enquanto no tipo 2  a preservação histórica é  ilimitada, o tipo 3 tem limitação na preservação da história,  pois é limitado ao número de colunas designadas para armazenar dados históricos.  Tipo 1 e Tipo 2  são muito similares,  já o tipo 3 vai inserir  colunas adicionais para as tabelas:

 Supplier_key Supplier_Name   Original_Supplier_State Effective_Date Current_Supplier_State
001  Phlogistical Sociedade de Abastecimento  CA 22-Dec-2004 IL

Note-se que este registro não pode acompanhar todas as mudanças históricas, tais como quando um fornecedor se muda duas vezes.  Pode-se, para melhorar a informação, criar a coluna Previous_Supplier_State em vez de Original_Supplier_State que, então,  acompanhará todas as mudanças históricas. Acompanhar sim, rastrear não, pois saberemos qual foi o Estado anterior á nova mudança, porém não saberemos se houve mudanças anteriores, se houveram outros estados antes do Previous_Supplier_State.

Tipo 4

O método de tipo 4  é, habitualmente, conhecido apenas como o uso de “tabelas de histórico”,  onde se mantém uma tabela os dados atuais, e uma tabela adicional é utilizado para manter um registro de algumas ou todas as alterações.

Seguindo o exemplo acima, a tabela original pode ser chamado de fornecedores e da tabela de histórico pode ser chamada  Supplier_History.

Fornecedor
Supplier_key Supplier_Name Supplier_State
001 Phlogistical Sociedade de Abastecimento IL

 

Supplier_History
 Supplier_key Supplier_Name Supplier_State Create_Date
001 Phlogistical Sociedade de Abastecimento CA 22-Dec-2004

Este método assemelha-se como tabelas de auditoria banco de dados e como as funções técnicas do Change Data Capture.

Tipo 6 / Hibrido  

O método Tipo 6 é aquele que combina as abordagens dos tipos 1,2 e 3 (1 + 2 + 3 = 6).  Uma possível explicação para a origem do termo é que foi inventado por Ralph Kimball, durante uma conversa com Stephen Pace de Kalido, mas também tem sido referido por Tom Haughey.  Não é frequentemente utilizado porque tem o potencial de complicar o acesso do usuário final, mas tem algumas vantagens sobre as outras abordagens, especialmente quando técnicas são empregadas para mitigar a complexidade.

A abordagem é usar um SCD tipo 2, mais a adição de um par adicional de colunas de data para indicar o período de validade de uma linha específica e um sinalizador para indicar se o registro é o registro atual.

Esta abordagem tem várias vantagens:

  • o usuário pode escolher a consulta usando os valores atuais da tabela dimensional, limitando as linhas na tabela de dimensão através de um filtro para selecionar apenas os valores atuais
  • alternativamente, o usuário pode usar os valores como 3eles eram  “no momento da operação”  usando um dos campos de data sobre a transação como uma restrição sobre a tabela de dimensão.
  • se houver um número de colunas de data da transação (por exemplo, data da encomenda, data de transporte, confirmação de data), em seguida, o usuário pode escolher qual a data para analisar os dados pelo fato – algo que não é possível usar outras abordagens.

Esta é a forma como a tabela Supplier ficaria com Tipo 6 dimensões de alteração lenta:

Supplier Fornecedor
Row_Key  Supplier_key  Supplier_code Supplier_Name  Supplier_State Data_inicial  Data_final Indicador Atual
1 001 ABC001 Phlogistical Sociedade de Abastecimento CA 22-Dec-2004 15-Jan-2007 N
2 001 ABC001 Phlogistical Sociedade de Abastecimento IL 16-Jan-2007 1-Jan-2099  Y

Implementações alternativas de tipo 6 pode incluir uma data final em branco.  Outras abordagens incluem o uso de um número de revisão, em vez de uma chave de linha.

Note, as operações devem ter a chave do fornecedor como chave estrangeira (mesmo que isso não seja uma junção de uma coluna exclusiva) em combinação com um filtro de data.  A junção não deve ser a chave primária para a tabela (linha de chave).  A transação também pode, opcionalmente, realizar uma ou mais chaves de linha (para permitir o uso do SCD Tipo 2, além de Tipo 6) dependendo de qual das colunas de transações datestamp o usuário deseja analisar – mas note os problemas de desempenho com esta abordagem descrita na seção Tipo SCD 2.

Observe que as colunas  Indicador_Corrente  e Row_Key são opcionais – eles não são necessários para a análise, mas pode simplificar a consulta e gestão, respectivamente.

Observação: O ideal é que um fato só deve ter uma data de evento única, para representar a data em que a transação ocorreu. Se houver várias datas, considere a divisão do Fato para atender os eventos mais granulares.

No exemplo a seguir, queremos consultar os seguintes operações de entrega:

Delivery Entrega
 Delivery_Key Supplier_key Quantity Product Delivery_Date Order_Date
1 001 132 Bags 22-Dec-2006 15-Oct-2006 
2 001 324 Chairs 15-Jan-2007 1-Jan-2007 

Para consultar o star schema usando os dados de referência histórica a partir da data da entrega, a consulta fica assim:

SELECT   delivery.delivery_cost,   supplier.supplier_name,   supplier.supplier_state

FROM delivery INNER JOIN supplier   ON delivery.supplier_key = supplier.supplier_key

WHERE delivery.delivery_date >= supplier.start_date

  AND delivery.delivery_date < supplier.end_date

Para consulta usando a data do pedido, o SQL simplesmente precisa ser alterado para fazer referência a order_date.

Para consultar o esquema estrela usando os dados de referência atual, a consulta fica assim:

SELECT   delivery.delivery_cost,  supplier.supplier_name,  supplier.supplier_state

FROM delivery  INNER JOIN supplier   ON delivery.supplier_key = supplier.supplier_key

WHERE supplier.start_date <= CURRENT_TIMESTAMP

  AND supplier.end_date > CURRENT_TIMESTAMP

Notas

  • CURRENT_TIMESTAMP é uma função padrão ISO SQL. Para fabricantes específicos  incluir o NOW() função no PostgreSQL sintaxe / MySQL, getdate() no SQL Server, e SYSDATE para Oracle.
  • Atenção – Se a cláusula WHERE que restringe as linhas na tabela de dimensão não estiver presente, em seguida, a consulta irá  potencialmente retornar registros duplicados e dar as respostas erradas, por isso essa técnica deve ser usada com cuidado.
  • Algumas ferramentas de Business Intelligence não tratam  da geração de joins complexos como estes.
  • Os Processos de ETL  necessários para criar essa tabela também precisam ser cuidadosamente projetados para garantir que não haja sobreposições nos períodos de tempo distintos para cada item de dados de referência.
  • A cláusula > = e < é necessária para garantir que nenhum período de tempo seja omitido.
  • Muitas vezes, uma visão é criada em cima da tabela, que pode filtrar as linhas ou colunas.  Isso simplifica o join se apenas as linhas atuais  são necessárias para determinadas consultas.  Essa visão pode ser materializada em uma tabela física se o espaço não for um problema.  Isso pode ser feito automaticamente pelos SGBD mais modernos e automaticamente atualizados.
 

 Até a próxima!

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: