SSIS – Criando seu próprio SCD 4

Neste post da série você irá aprender a usar alguns componentes da ferramenta de ETL e integração de dados da Microsoft, o Integration Services, para criar um fluxo de carga de dimensões personalizado.


Para conseguir manter a abstração de SGBD, não utilizando queries complexas para efetuar as cargas, e ainda assim otimizar o processo de ETL da dimensão de Clientes da Light LTDA, você precisará criar o seu próprio fluxo de SCD, utilizando outros componentes disponíveis no Integration Services.

Para iniciar a criação do novo fluxo de ETL, primeiramente crie uma nova dimensão chamada DM_CLIENTES_v2 para efetuar a nova carga. utilize o código abaixo.

USE OLAP
GO 

CREATE TABLE DM_CLIENTES_v2 ( 
    SK INT NOT NULL IDENTITY (1,1),
    ID INT,
    NOME VARCHAR(25),
    CPF VARCHAR(14),
    EMAIL VARCHAR(25),
    DDD CHAR(2),
    TELEFONE CHAR(8),
    DATA_INICIO DATE,
    DATA_FIM DATE)
GO

Em solution explorer clique com o botão direito em SSIS Packages e crie um novo pacote. Arraste um novo Data Flow Task da barra de ferramentas, para o Control Flow. Dê um duplo clique e, novamente da barra de ferramentas, arraste para dentro do campo em branco do Data Flow os seguintes componentes:

  • Dois componentes OLE DB SOURCE – Serão responsáveis pelas conexões com a tabela CLIENTES do banco OLTP e com a Dimensão DM_CLIENTES_v2 do banco OLAP;
  • Dois componentes SORT – O componente SORT é responsável, como o próprio nome já diz, por ordenar os registros de uma origem ligada a ele de acordo com a(s) chave(s) selecionada(s);
  • Um componente MERGE JOIN – Esse componente será responsável por concatenar as colunas da tabela de origem (CLIENTES) com as colunas da tabela de destino (DM_CLIENTES_v2) de acordo com o(s) campos(s) ordenado(s) pelos sorts;
  • Um componente CONDITIONAL SPLIT – Esse componente é responsável por filtrar os dados conforme os parâmetros passados. Nesse fluxo, ele separará os novos registros (as linhas que existem na tabela de Clientes mas não estão na dimensão), daqueles a serem atualizados dentro da dimensão DM_CLIENTES_v2 (seja com relação ao update ou a inserção de um novo registro histórico);
  • Um componente DERIVED COLUMN – Esse componente será responsável por criar a data de inicio e de fim que fará o versionamento dos dados históricos da dimensão DM_CLIENTES_v2;
  • Um componente OLE DB DESTINATION – Esse componente servirá para que possamos fazer a inserção dos novos registros na dimensão DM_CLIENTES_v2;
  • Três componentes OLE DB COMMAND  Esses componentes serão responsáveis por fazer o update nos campos que precisam ser atualizados e por inserir os novos registros históricos, atualizando esses registros com as respectivas datas de inicio e fim.

Captura de Tela 2015-10-13 às 17.00.37


Comece definindo cada um dos OLE DB Source. O primeiro deve estar configurado na base de dados OLTP, na tabela Clientes, chame-o de Origem. O segundo deve estar configurado na base de dados OLAP, na dimensão DM_CLIENTES_v2, chame-o, por sua vez, de Destino. Ligue cada um dos OLE DB Source em um operador Sort.

Captura de Tela 2015-10-13 às 17.08.59

Agora configure cada um dos Sorts para ordenar os registros pelo campo ID.

Captura de Tela 2015-10-13 às 17.09.59

Renomeie cada um deles (Segundo o OLE DB Source em que estiver ligado) de Ordena_Origem e Ordena_Destino.  Ligue o Sort Ordena_Origem ao componente Merge Join. Na janela que se abrirá, escolha a opção Merge join left output.

Captura de Tela 2015-10-13 às 17.11.37

Ligue também o Sort Ordena_Destino ao Merge Join. feito isso, abra o componente Merge Join. Ele servirá para concatenar as colunas da tabela Clientes com as colunas da dimensão DM_Clientes, ordenando-as através da chave definida nos Sorts. É necessário que você altere a opção join type de Inner join, para Left outer join. Isso se faz necessário para trazermos os registros que estão na Origem, mas ainda não foram inseridos no Destino.

Uma boa prática, já que as colunas da Origem e as colunas do Destino têm o mesmo nome, é concatenar no Output das colunas derivadas do Sort Ordena_Destino, o sufixo _Dest para que não venhamos a fazer confusão nas configurações seguintes. Veja na figura abaixo.

Captura de Tela 2015-10-13 às 17.16.09

Seguindo com a construção do fluxo de ETL, ligaremos o componente Merge Join ao componente Derived Column. Renomeie esse componente para Cria_Datas. Abra-o e configure  duas novas colunas para o fluxo. Uma chamada Data_Inicio e a outra Data_Fim. Use o código abaixo em ambas as colunas na aba Expression.

(DT_DBTIMESTAMP)(@[System::StartTime])

Agora, ligue o Cria_Datas ao componente Conditional Split. Esse permitirá que os dados sejam divididos para que se possa trabalhar separadamente com cada situação. Configure as três linhas no Conditional Split seguindo a figura abaixo.

Captura de Tela 2015-10-13 às 17.39.27

Após ter configurado cada uma das três linhas de código do Conditional Split, você o ligará ao componente OLE DB Destination. Será apresentada uma janela com a opção de você fazer esse link pela condição Insert, Update ou Histórico. Escolha a opção Insert. Configure este componente para receber os novos registros, ignorando a coluna SK (ela é IDENTITY) e a coluna DT_FIM, logo esses registros não possuem esse dado pois são novos.

Captura de Tela 2015-10-13 às 17.47.37

Agora faça outra ligação do Conditional Split para o primeiro OLE DB Command. Selecione a opção UPDATE na janela de configurações.

Esse componente merece uma atenção especial pois, além de sua configuração ser um pouco mais complexa que a dos demais componentes, ele é o principal componente do fluxo por ser o responsável, tanto pelos updates, quanto pela atualização do versionamento dos registros através das colunas DATA_INICIO e DATA_FIM, criando assim os registros históricos. Ele funciona através de parâmetros e queries ANSI.

Ao abrir a tela do componente OLE DB Command, ele estará na aba de conexões. Você precisará indicar o banco o qual deseja fazer mudanças. Ness caso, faça conexão com o database OLAP.

Na aba de propriedades do componente, você se preocupará somente com a última definição: SqlCommand. Nesse campo você escreverá a query que será responsável pela mudança que você desejar executar nos seus através do ETL.

Nesse caso você usará o script abaixo.

UPDATE DM_CLIENTES2 SET DATA_INICIO = ?, NOME = ? WHERE ID = ? AND DATA_FIM IS NULL; 

Essa query é um simples de update, construída no padrão ANSI que fará a atualização dos campos DATA_INICIO, NOME com base no ID da dimensão DM_CLIENTES_v2.

Na próxima aba, você irá mapear que campos os parâmetros receberam para que possam atualizar o campo DATA_INICIO e NOME da Dimensão DM_CLIENTES_v2.

Os parâmetros são definidos na sequência exata de como são configurados na query. Ligue o Param_0 ao campo DT_INICIO (campo que foi definido no Derived Column antes de começarmos a configurar o OLE DB Command), o Param_1 à coluna NOME e o Param_2 à coluna ID (note que estamos usando os campos que vieram da origem e foram concatenados aos campos do destino com o auxilio do componente Merge Join).

Feito isso, você já tem configurado no fluxo os novos registros que serão adicionados diariamente pelo banco OLTP da Light LTDA e também as possíveis mudanças nos nomes dos Clientes, que possam vir a ocorrer devido algum tipo de erro de cadastro.


Agora você irá configurar a etapa final do fluxo que é a inserção dos registros históricos. Ligue o componente Conditional Split ao próximo OLE DB Command e na janela de configurações selecione a ultima opção disponível, HISTORICO. Conecte no banco de dados OLAP.

Usaremos o código abaixo para configurar na aba de propriedades do componente a opção SqlCommand.

UPDATE DM_CLIENTES_v2 SET DATA_FIM = ? WHERE ID = ? AND DATA_FIM IS NULL;

Essa query também realizará um update, e também é construída em padrão ANSI. Por sua vez, será responsável pela atualização do campo DATA_FIM dos registros que formarão o conteúdo histórico da dimensão DM_CLIENTES_v2.

Como já fora dito, basta seguir uma sequência lógica para configurar os parâmetros aos campos devidos. O primeiro parâmetro fora definido como sendo o novo valor da coluna DATA_FIM, logo o ligaremos aos campo DATA_FIM. O segundo ligaremos à coluna ID.

O próximo passo é a configuração do OLE DB Command que fará a inserção do novo registro histórico. Você usará a query abaixo para configurar a opção SqlCommand.

INSERT INTO DM_CLIENTES_v2 (
    ID,NOME,CPF,EMAIL,DDD,TELEFONE,DATA_INICIO )
VALUES (?,?,?,?,?,?,?);

Esta é a última query (também em ANSI) de configuração do nosso fluxo de SCD que está sendo criado. Essa query de INSERT irá depositar na dimensão DM_CLIENTES_v2 todos os registros que ainda não foram adicionados no Data Warehouse da Light LTDA.

Agora apenas configure os parâmetros de forma sequencial à forma que a query foi construída ligando cada um deles ao campo responsável por popular cada coluna da DM_CLIENTES_v2. O fluxo ficará conforme a figura abaixo.

Captura de Tela 2015-10-13 às 18.17.03

Dessa forma, resumidamente, o Fluxo de SCD criado funciona assim:

  1. O fluxo lê os dados do OLTP e da Dimensão que está no OLAP;
  2. Em seguida ordena esses dados pela chave primária da dimensão (nesse caso o campo ID);
  3. Acontece no componente Merge Join nada mais que uma união entre os campos da origem e do destino. É formada uma grande tabela. Isso serve para que o proximo componente possa, com base na comparação entre um campo da origem e o mesmo campo no destino, decidir se aquela linha de registro irá ser inserida, atualizada, transformada em histórico ou se nem mesmo participará do resto do fluxo;
  4. O Conditional Split funciona como um Case da liguagem SQL. Ele irá decidir como cada linha de registro vai ser tratada com base na comparação entre o registro na origem e aquele mesmo registro do destino. Caso naquela linha de registro o campo de ID da origem estiver preenchido e o ID do destino não, ele direciona o dado para ser inserido na Dimensão. Funcionará no mesmo raciocínio com o fluxo que direciona para o Update e para o Histórico.

Se executada, a carga de ETL que foi criada será capaz de inserir todos os 500 mil registros da tabela Clientes na dimensão DM_CLIENTES_v2, em apenas aproximadamente 7 segundos.


Como foi demonstrado, o componente Slowly Changing Dimension do Integration Services, apesar de cumprir com o prometido de manter o versionamento dos dados históricos, deixa muito a desejar com relação a performance.

Não fora demonstradas atualizações e inserções de registros, mas, caso seja de seu interesse, altere dados ou insira novas linhas no banco de dados OLTP da Light LTDA e observe como o SSIS irá trabalhar em ambas as situações. A performance é incomparável.

Sendo assim, seguindo os conceitos de SCDs e o passo a passo de criação do fluxo de ETL de Slowly Changing Dimension, será possível ajustá-lo às realidades de qualquer situação existente no mercado.

Anúncios

SSIS – Criando seu próprio SCD 3

Neste post da série você irá aprender a configurar o componente Slowly Changing Dimension na ferramenta de Integração de Dados da Microsoft, o Integration Services.


Vamos agora iniciar os testes de carga da Dimensão de Clientes da Light LTDA. Utilizaremos em primeiro momento, o componente Slowly Changing Dimension do Integration Services.

Para que isso seja possível, precisamos criar primeiramente um projeto na ferramenta de ETL da Microsoft. Feito isso, abra o seu package default e arrastar da barra de ferramentas o componente Data Flow Task para o Control Flow.

Renomeie o componente para teste_1 e em seguida, abra-o. Após isso, vá até a barra de ferramentas e arraste para dentro do Data Flow Task, os componentes OLE DB Source e Slowly Changing Dimension. A tela da ferramenta deverá estar conforme abaixo.

Captura de Tela 2015-10-13 às 16.14.45

O círculo vermelho, no canto direito de cada um dos componentes, sinaliza que eles precisam ser configurados.

O componente OLE DB Source será responsável pela conexão com o banco de dados OLTP da Light LTDA.

Obs – Como exemplo, foi utilizado o OLE BD Source, porque foi utilizado o SQL Server. Caso você necessite extraia os dados de outro Database, ou mesmo de vários, o Integration Services tem a possibilidade de se conectar via ODBC a uma grande variedade de bancos.

Após configurado o componente de conexão à fonte de dados, você precisará ligá-lo ao componente Slowly Changing Dimension.

Ao abrir o componente SCD, será apresentada uma janela que lhe permitirá configurar as colunas de entrada de dados (colunas que virão da tabela Clientes do banco OLTP), as colunas da Dimensão de Clientes e a(s) chave(s) lookup. Configure conforme a figura abaixo.

Captura de Tela 2015-10-13 às 16.21.02

Após isso, você poderá selecionar na próxima janela de configuração os tipos de Slowly Changing Dimension que usará na carga da dimensão de Clientes.

É possível, através deste componente, manter os dados da coluna imutáveis (Fixed attibute), executar um update nos registros da coluna (Changing attibute), ou manter o histórico de alterações dos dados da coluna (Historical attribute).

Nesse caso, os dados de CPF do cliente não serão alterados, logo, esses serão códigos únicos por pessoa. O NOME do cliente foi marcado como Changing attibute porque, caso haja algum erro no cadastro, será possível corrigi-lo em uma carga futura. Já os campos DDD, TELEFONE e EMAIL foram definidos como Historical attribute, pois queremos guardar um histórico de todos os telefones e e-mails de nossos clientes. A tela de configuração ficará como na imagem a seguir.

Captura de Tela 2015-10-13 às 16.23.24

Avance na configuração do próximo passo do componente. Na tela de opções dos atributos históricos, selecione a opção use start and end dates to identify current and expired recordes e, para a opção Start date column, escolha o campo DATA_INICIAL e para a opção End date column, o campo DATA_FIM (esses campos guardarão a data de inicio e de fim de cada um dos registros históricos da dimensão).

Captura de Tela 2015-10-13 às 16.25.25

No próximo passo, desabilite a opção de suporte a membros inferidos. Ao final da configuração do componente, o próprio Slowly Changing Dimension se encarregará de construir todo o fluxo que fará a carga da nossa dimensão de Clientes da Light LTDA. O fluxo de ETL ficará conforme a imagem abaixo.

Captura de Tela 2015-10-13 às 16.28.14

Essa rotina de carga da dimensão DM_CLIENTES, se executada, terminará em um tempo médio de 2 horas e 25 minutos.


No próximo post da série você aprenderá a usar alguns componentes da Ferramenta de integração de Dados e ETL da Microsoft, o Integration Services, para criar um fluxo de carga de dados personalizado para popular a Dimensão de clientes.

SSIS – Criando seu próprio SCD 2

Nesse post da série você irá preparar o ambiente de testes para que seja possível criarmos os fluxos de carga de dados da dimensão de Cliente de nosso Data Warehouse fictício da Light LTDA.


Criando o ambiente de testes OLTP e OLAP

Um OLTP (On-line Transaction Processing) é que um sistema de banco de dados que trabalha com os dados em tempo real.

Geralmente estes SGBDs estão ligados a uma aplicação, recebendo constantemente os dados inseridos, alterados e excluídos desse sistema pelo usuário.

Já um On-line Analytical Processing (OLAP), como o próprio nome já diz, é um ambiente responsável por guardar dados analíticos, um Data Warehouse.


Vamos iniciar a criação do nosso ambiente de testes. Você irá criar a tabela, que guarda os dados dos clientes no banco OLTP de uma grande empresa de vendas fictícia, chamada Light LTDA, usando o código abaixo.

CREATE DATABASE OLTP
GO

USE OLTP
GO 

CREATE TABLE CLIENTES ( 
    ID INT NOT NULL IDENTITY (1,1),
    NOME VARCHAR(25),
    CPF VARCHAR(14),
    EMAIL VARCHAR(25),
    DDD CHAR(2),
    TELEFONE CHAR(8),
    DATA_CADASTRO DATE)
GO

Depois de criada a base de dados e a tabela de clientes, é necessário inserir os seus registros. Você adicionará à essa tabela 500 mil dados de clientes no ano de 2013 usando o código abaixo.

DECLARE @n INT, @n1 INT, @n2 INT, @n3 INT, @n4 INT, 
        @n5 INT, @n6 INT, @n7 INT, @n8 INT, @n9 INT 
DECLARE @d1 INT, @d2 INT
DECLARE @nome VARCHAR(21), @email VARCHAR(20), @cpf VARCHAR(14) 
DECLARE @ddd CHAR(2), @telefone CHAR(8)
DECLARE @data DATE
DECLARE @contador INT

SET @contador = 0

WHILE @contador < 500000

BEGIN	
-- Gera nome do cliente aleatório.
SET @nome = SUBSTRING(CONVERT(VARCHAR(40), NEWID()),0,21);

-- Gera CPF do cliente aleatório.
SET @n = 9;
SET @n1 = CAST((@n + 1) * RAND(CAST(NEWID() AS VARBINARY )) AS INT)
SET @n2 = CAST((@n + 1) * RAND(CAST(NEWID() AS VARBINARY )) AS INT)
SET @n3 = CAST((@n + 1) * RAND(CAST(NEWID() AS VARBINARY )) AS INT)
SET @n4 = CAST((@n + 1) * RAND(CAST(NEWID() AS VARBINARY )) AS INT)
SET @n5 = CAST((@n + 1) * RAND(CAST(NEWID() AS VARBINARY )) AS INT)
SET @n6 = CAST((@n + 1) * RAND(CAST(NEWID() AS VARBINARY )) AS INT)
SET @n7 = CAST((@n + 1) * RAND(CAST(NEWID() AS VARBINARY )) AS INT)
SET @n8 = CAST((@n + 1) * RAND(CAST(NEWID() AS VARBINARY )) AS INT)
SET @n9 = CAST((@n + 1) * RAND(CAST(NEWID() AS VARBINARY )) AS INT)
SET @d1 = @n9*2+@n8*3+@n7*4+@n6*5+@n5*6+@n4*7+@n3*8+@n2*9+@n1*10;
SET @d1 = 11 - (@d1%11);

IF (@d1 >= 10) 
SET @d1 = 0
SET @d2 = @d1*2+@n9*3+@n8*4+@n7*5+@n6*6+@n5*7+@n4*8+@n3*9+@n2*10+@n1*11;
SET @d2 = 11 - ( @d2%11 );

IF (@d2 >= 10) 
SET @d2 = 0;
SET @cpf = CAST(@n1 AS VARCHAR(1)) + 
CAST(@n2 AS VARCHAR(1)) + 
CAST(@n3 AS VARCHAR(1)) + '.' + 
CAST(@n4 AS VARCHAR(1)) + 
CAST(@n5 AS VARCHAR(1)) + 
CAST(@n6 AS VARCHAR(1)) + '.' +
CAST(@n7 AS VARCHAR(1)) + 
CAST(@n8 AS VARCHAR(1)) + 
CAST(@n9 AS VARCHAR(1)) + '-' +
CAST(@d1 AS VARCHAR(1)) + 
45 CAST(@d2 AS VARCHAR(1))

-- Gera email do cliente aleatório.
SET @email = SUBSTRING(CONVERT(varchar(40), NEWID()),0,11) + 
'@email.com';

-- Gera data de cadastro do cliente aleatória.
SET @data = CONVERT(DATE, CONVERT(VARCHAR(15),'2013-' 
+CONVERT(VARCHAR(5),(CONVERT(INT,RAND()*12))+1) + '-' + 
CONVERT(VARCHAR(5),(CONVERT(INT,RAND()*27))+1) ))

-- Gera DDD do cliente aleatório.
SET @ddd = CAST(@n8 AS VARCHAR(1)) +
CAST(@n4 AS VARCHAR(1))

-- Gera telefone do cliente aleatório.
SET @telefone = CAST(@n6 AS VARCHAR(1)) +
CAST(@n9 AS VARCHAR(1)) +
CAST(@n2 AS VARCHAR(1)) + 
CAST(@n4 AS VARCHAR(1)) +
CAST(@n1 AS VARCHAR(1)) +
CAST(@n5 AS VARCHAR(1)) +
CAST(@n8 AS VARCHAR(1)) +
CAST(@n3 AS VARCHAR(1)) 

-- Popula a tabela Clientes.
INSERT INTO CLIENTES VALUES (
    @nome ,
    @cpf ,
    @email ,
    @ddd ,
    @telefone ,
    @data )

SET @contador = @contador + 1 

END

Por último, você precisará criar o banco OLAP e a dimensão de Clientes de um dos Data Marts da instituição Light LTDA. Isso será possível utilizando o script abaixo.

CREATE DATABASE OLAP
GO
 
USE OLAP
GO 

CREATE TABLE DM_CLIENTES ( 
     SK NOT NULL IDENTITY (1,1), 
     ID INT NOT NULL,
     NOME VARCHAR(25),
     CPF VARCHAR(14),
     EMAIL VARCHAR(25),
     DDD CHAR(2),
     TELEFONE CHAR(8),
     DATA_INICIO DATE
     DATA_FIM DATE )
GO

Obs – Para quem está iniciando os estudos em Business Intelligence, os Data Marts são pequenas partes de um Data Warehouse formados por tabelas denominadas Fatos e Dimensões. Basicamente, as Dimensões são tabelas que contém atributos relacionados a determinado assunto. Já as tabelas de Fato contém as chaves primários das dimensões (as Foreign Key) e medidas, métricas e valores.


No Próximo post da série você irá aprender a configurar o componente Slowly Changing Dimension na ferramenta de ETL Integration Services.

SSIS – Criando seu próprio SCD 1

Essa série será dividida em 4 Partes. A primeira parte irá tratar de alguns conceitos relacionados a Business Intelligence. no Segundo post você terá os scripts para criação do ambiente de testes. Na terceira e quarta parte nos usaremos os componentes no SSIS para criar o Slowly Changing Dimension.


 O grande crescimento dos ambientes de negócios tem dado origem a uma quantidade de dados cada vez maior. Essas informações são à chave para que os lideres dessas empresas tenham a possibilidade de decidir de forma eficaz.

Um sistema de BI (Business Intelligence) é uma ferramenta poderosíssima de tomada de decisões. Através dela é possível obter análises dos dados da instituição, possibilitando assim a eficiência nas escolhas relativas à empresa.

Em sua constituição, uma ferramenta de BI é formada por um Data Warehouse (ou DW, também traduzido para Armazém de Dados) que é uma estrutura de armazenamento de dados cuja sua principal função é receber dados e organizá-los de maneira histórica para construção das análises do BI.

Os dados de um DW podem ser retirados de diversas fontes de dados (arquivos .txt, .csv, tabelas do excel, e bancos de dados relacionais). Essas informações são exportadas para o Data Warehouse usando um processo chamado ETL (Extract, Transformation and LoadExtração, Transformação e Carga). Através desse processo, é possível não somente retirar os dados das diversas fontes, mas também agregá-lo, tratá-lo ou até mesmo transformá-lo se necessário.


Todo o DW é permeado pelo conceito temporal. Todas as tabelas de Fato de todos os Data Marts são carregadas baseadas nas foreign keys, que têm como origem a dimensão de tempo. Porém, os efeitos de tempo não estão isolados somente para as atividades das tabelas de Fato. Todas as dimensões sejam elas de região, clientes, produtos, empregados ou quaisquer outras, também são afetadas pela passagem do tempo.

Muitas vezes o administrador de BI irá se deparar com uma mudança no agrupamento de dados de uma dimensão. Algumas vezes será apenas uma correção nos dados já gravados no DW, outras uma verdadeira alteração em um ponto do tempo de um membro de uma dimensão específica. Como essas alterações são aleatórias e não frequentes, elas são chamadas de Slowly Changing Dimensions (Mudanças Lentas de Dimensões), também abreviado para SCDs.


Existem vários tipos de Slowly Changing Dimensions, cada um indicado para algum tipo específico de situação, entretanto 2 deles são muito utilizados. Estes são:

Tipo 1 – Sobrescrição de Dados: Nesse primeiro tipo de SCD, supondo um exemplo onde temos uma dimensão de vendedores, com um campo que guarda os dados de localidade onde esses vendedores atuam, teríamos que apenas executar um update no dado de localidade dessa dimensão.

Por exemplo, se o colaborador Arthur Luz mudou de Brasília para o Rio de Janeiro, o campo que guarda a localidade deixaria de conter o registro Brasília e passaria a conter Rio de Janeiro.

figura 1
Primeiro momento no tempo: Arthur Luz em Brasília.
figura 2
Segundo momento no tempo: Arthur Luz no Rio de Janeiro.

Nesse caso de Slowly Changing Dimension, é necessário tomar cuidados, pois levando em consideração uma análise feita no mês em que esse colaborador mudou de localidade, em ambas as regiões, o dado dos relatórios que usufruíssem dos dados dos vendedores, apareceriam incorretos ou incompletos.

Esse tipo de SCD é mais utilizado para realizar updates em campos que possivelmente possam sofrer alterações devido um cadastro equivocado.

Tipo 6 – Adição de uma nova linha de registro: Essa técnica é a mais utilizada para guardar histórico em projetos de DW e é contemplada (assim como o tipo 1) pela ferramenta de ETL da Microsoft, o Integration Services.

Nesse tipo de SCD, cada alteração de localidade de colaboradores da dimensão de vendedores seria um novo registro com data de início e fim, sendo que o registro atual (no caso do exemplo disponível, a cidade do Rio de Janeiro), não possuiria data de fim e sua data de início seria igual à data de fim do registro anterior (no caso, a cidade de Brasília).

figura 3
Primeiro momento no tempo: Arthur Luz em Brasília.
figura 4
Segundo momento no tempo: Arthur Luz saiu de Brasília.
figura 6
Segundo momento no tempo: Arthur Luz foi movido para o Rio de Janeiro.

Observe que a Data de Início do Registro de ID 127 é a mesma Data de Fim do Registro de ID 56.


SSIS – Componente Slowly Changing Dimensions

O Integration Services (SSIS) é a ferramenta da Microsoft utilizada para efetuar cargas de ETL em Data Warehouses. Ela possui em sua barra de ferramentas um componente chamado Slowly Changing Dimension, que é utilizado para carregar os históricos das dimensões do DW.

Ela faz o que promete, todavia, quando usado em dimensões com um grande número de registros, com um agravante: a performance. Cada carga de ETL, de cada uma das dimensões, dura (dependendo da quantidade de registros e do servidor) de 2 a 4 horas.

Como modo de resolver o problema de performance do componente passa-se normalmente, a utilizar queries para efetuar as cargas de ETL (através da própria ferramenta de ETL, ou com o uso de stored procedures). Isso reduz o tempo de carga de algumas horas para poucos minutos.

Em situações onde não existe possibilidade de migração de SGBD, as queries para extrações, transformações e cargas funcionam muito bem. Mas, se existe um risco de mudança de banco de dados, as queries seriam um gargalo, pois todo ETL (ou parte dele, caso as queries tenham sido feitas, em sua maioria, em padrão ANSI) teria que ser refeito com a linguagem específica do novo banco.

Essa é uma característica fantástica das ferramentas de ETL: a abstração de banco. Quando você utiliza bem os componentes da ferramenta escolhida, independente do SGBD usado, o ETL continua intacto e em pleno funcionamento se alterado o banco de dados.

Dessa forma, utilizando o fluxo que será explicado nos próximos posts, você continua com uma boa performance nas cargas de ETL (sem a necessidade de queries), porém mantendo a abstração de banco de dados.