Académique Documents
Professionnel Documents
Culture Documents
2015
Aplicações em ETL
Fernanda Leôncio Garro Costa de Pinho
©Copyright do Instituto de Gestão em Tecnologia da Informação.
Todos os direitos reservados.
Aplicações em ETL . 2
Capítulo 1 - Introdução ao ETL .................................................................... 4
Capítulo 2 - Dimensões ............................................................................. 15
Capítulo 3 - Fatos .................................................................................... 21
Capítulo 4 – Modelagem Dimensional ......................................................... 27
Capítulo 5 – Processo ETL Parte I ............................................................... 36
Capítulo 5 – Processo ETL Parte II .............................................................. 41
Bibliografia .............................................................................................. 43
Aplicações em ETL . 3
Capítulo 1 - Introdução ao ETL
Aplicações em ETL . 4
dados que vem do grande porte e também arquivos do tipo DBF, do antigo
Clipper ou Dbase.
A seguir são apresentados alguns dos fatores que devem ser analisados antes
de começar a fase de extração dos dados:
• A extração de dados do ambiente operacional para o ambiente de data
warehouse demanda uma mudança na tecnologia. Os dados são transferidos de
bancos de dados hierárquicos, tal como o adabas, ou de bases do grande porte,
como o DB2, para uma nova tecnologia de SGBD para Data Warehouse, tal
como o IQ da Sybase, Red Brick da Informix,
Essbase ou o DB2 para DW:
• A seleção de dados do ambiente operacional pode ser muito complexa, pois
muitas vezes é necessário selecionar vários campos de um sistema transacional
para compor um único campo no data warehouse
• Outro fator que deve ser levado em conta é que dificilmente há o modelo de
dados dos sistemas antigos, e se existem não estão documentados
O segundo passo é definir a ferramenta que irá fazer a extração. É importante
avaliar a necessidade da empresa, custo da ferramenta, custo da mão de obra...
Necessidade da empresa
Identificar através do porte da empresa e do porte dos projetos quais são as
necessidades relacionadas às funcionalidades e capacidade das ferramentas.
Custo da ferramenta
Existem ferramentas com custos muito elevados, custos medianos e Free.
Funcionalidades da ferramenta
Analisar as funcionalidades de cada ferramenta, principalmente as
relacionadas às opções de conexão com outras fontes.
Aplicações em ETL . 5
benefícios serão bastante vistosos e a produtividade aumentará
consideravelmente.
TRANSFORMAÇÃO
Definidas as fontes, partimos para o segundo passo que consiste em
transformar e limpar esses dados. Mas o que afinal de contas, o que é isso?
Bem vamos descrever de uma forma bem simples. Quando obtemos os dados
de uma fonte, que na maioria das vezes é desconhecida nossa, e foi concebida
há muito tempo atrás, os mesmos possuem muito lixo e há muita inconsistência.
Por exemplo:
Quando um vendedor de linhas telefônicas for executar uma venda, ou
inscrição, ele está preocupado em vender, e não na qualidade dos dados que
está inserindo na base, então se por acaso o cliente não tiver o número do CPF a
mão, ele cadastra um número qualquer, desde que o sistema aceite, um dos
mais utilizados é o 999999999-99. Agora imagine um diretor de uma companhia
telefônica consultar o seu Data Warehouse (DW) para ver quais são os seus
maiores clientes, e aparecer em primeiro lugar o cliente que tem o CPF
999999999-99? Seria no mínimo estranho. Por isso, nessa fase do DW, fazemos
a limpeza desses dados, para haver compatibilidade entre eles.
Além da limpeza, temos de fazer na maioria das vezes uma transformação,
pois os dados provêm de vários sistemas, e por isso, geralmente uma mesma
informação tem diferentes formatos.
Por exemplo:
Em alguns sistemas a informação sobre o sexo do cliente pode estar
armazenada no seguinte formato: “M” para Masculino e “F” para Feminino,
Aplicações em ETL . 6
porém em algum outro sistema está guardado como “H” para Masculino e “M”
para Feminino e assim sucessivamente.
Quando levamos esses dados para o DW, deve-se ter uma padronização
deles, ou seja, quando o usuário for consultar o DW, ele não pode ver
informações iguais em formatos diferentes, então quando fazemos o processo de
ETL, transformamos esses dados e deixamos num formato uniforme sugerido
pelo próprio usuário. No DW, teremos somente M e F, fato esse que facilitará a
análise dos dados que serão recuperados pela ferramenta OLAP.
Carga
A fase de carga carrega os dados no Data Warehouse (DW). Consiste em
fisicamente estruturar e carregar os dados. Este processo varia amplamente.
Dentro de um mesmo DW temos diferentes períodos de execução para cada
tipo de processo de carga. Alguns são mensais, outros diários...
Neste momento também é definida a LATÊNCIA das informações. Isso pode
variar para cada tabela a ser carregada.
Aplicações em ETL . 7
Figura 6 - Visão processo completo
Aplicações em ETL . 8
Front-End OLAP, DashBoard,
BSC
Extração Servidores
Integração Rede
Limpeza de Middleware
Dados
Aplicações em ETL . 9
As ferramentas de ETL podem ser utilizadas para fazer todo tipo de trabalho
de importação, exportação, transformação de dados para outros ambientes de
banco de dados ou para outras necessidades a serem endereçadas.
Por exemplo: Importação de base de outra empresa.
Requisitos de negócio
Aplicações em ETL . 10
Verificar a viabilidade dos dados é garantir que o que se deseja carregar no
DW é possivel de ser extraído, tratado e carregado.
Latência dos Dados
Qual é o tempo máximo permitido para disponibilização dos dados através do
sistema de BI?
Principais conceitos
Business Intelligence
É um processo de coleta, transformação, análise e distribuição de dados para
melhorar a decisão dos negócios. Termo cunhado (ou pelo menos popularizado)
pelo Gartner Group no final da década de 80.
Descreve a capacidade de a empresa ter acesso e explorar seus dados,
desenvolvendo percepção e conhecimento, o que leva à melhora do processo de
tomada de decisões. Sua infraestrutura tecnológica é composta de Data
Warehouse ou Data Marts, data mining e ODS, além das ferramentas
pertinentes.
Principais processos uma aplicação de Business Intelligence:
Modelagem Dimensional
OLAP
Aplicações em ETL . 11
Sistemas Processo de carga Ambiente Usuário final
Origem (Extração do DataWarehouse
ERP Análise indicadores
Sistemas
legados
TX • Painéis
T • Relatórios
• Gráficos
Dados • Consultas
externos • Dashboards
Aplicações em ETL . 12
Principais conceitos
Data Warehouse (DW)
É uma coleção de dados orientados a assuntos, integrados, não voláteis,
variáveis com o tempo.
Características:
Consolidação de regras de negócio corporativas
É formado pelas tabelas de fatos e dimensão
Requer grande espaço de armazenamento
Um DW contém o histórico de anos da organização
Staging Área
Área de tratamento, padronização e transformação das informações
operacionais para carga na arquitetura BI.
Características:
Cópia das tabelas do legado
Filtros simples por data
Tempo de ETL rápido
Requer médio espaço de armazenamento
Em cada início de processamento tem seus dados apagados (truncados).
Propósitos
Desonerar processamento do legado
Criar independência do legado. Uma vez carregado os dados no layout
da Staging as demais etapas de carga serão transparentes.
Ser fonte de carga da ODS ou DW.
ODS
Base de dados integrada, volátil, de valores correntes, e que contém somente
dados detalhados. Também pode ser entendido como uma visão integrada do
mundo operacional.
Características:
Consolidação de conceitos do Operacional
É uma base de dados operacional integrada
Tempo de ETL médio
Requer médio espaço de armazenamento Um ODS pode conter
informações referentes a períodos variando entre 30 e 60 dias
Propósitos
Apoio ao operacional como fonte de consultas
Ser fonte de carga/apoio do processo ETL do DW
Facilitar o Trace Back do DW
Aplicações em ETL . 13
Sistemas
Legados
Staging Staggins Areas
DM Produção
* Cópia dos dados do legado
* Formato pré-definido
(Uma vez carregados os dados,
independe do legado)
* Consolida bases
ERP
operacionais DataWarehouse DW
ODS ODS´s
Corporativ
Origens
Data Mart´s
Externos * Dimensões e fatos
Corporativas
* Regras de negócio
corporativas
* Dimensões e fatos
Departamentais
* Regras de negócio
departamentais
Aplicações em ETL . 14
Capítulo 2 - Dimensões
DIMENSÃO
As dimensões identificam um indicador de análise sobre um empreendimento,
negócio ou ação feita.
Através das dimensões é possível identificar quando (mês, ano), onde
(estado, região) e com quem (segurado, produto) ocorreu um indicador de
análise (prêmio emitido).
Custos
DM
DM Comercial
Figura 12 - Dimensão I
Por exemplo:
O indicador “prêmio pago” é identificado pela dimensão ‘dia aviso’. Como essa
dimensão pertence à hierarquia de tempo, o indicador também pode ser visto
pelas dimensões ‘mês aviso’, ‘trimestre aviso’, ‘semestre aviso’ e ‘ano aviso’.
Aplicações em ETL . 15
O que é uma dimensão?
Figura 13 - Dimensão II
Dimensão degenerada
Em um Data Warehouse, uma Dimensão Degenerada é uma dimensão que é
derivada da Tabela Fato e não tem sua própria Tabela de Dimensão. Elas são
usadas frequentemente quando a granularidade de uma tabela de fato
representa os dados de nível Transacional.
Por exemplo:
Aplicações em ETL . 16
Figura 14 - Dimensão Degenerada
Dimensão Junk
O primeiro conceito de Dimensão Junk está associado às dimensões de baixa
cardinalidade (domínios de valor como sexo, estado civil).
Aplicações em ETL . 17
Figura 16 - Dimensão Junk II
Tipo 1
O valor anterior é sobreposto pelo valor atual, perdendo-se o histórico. Usado
principalmente para correção de informações, como nome de segurado e
descrição de produto. Exemplo de uma tabela fornecedor:
Aplicações em ETL . 18
Tipo 2
Uma nova ocorrência é criada na dimensão. A partir desse momento os fatos
são associados a essa ocorrência. Isso cria um histórico de movimentação na
dimensão. É importante a inclusão de atributos de controle como data de início
de validade, data de fim de validade e uma flag para identificação do perfil
corrente.
Este método rastreia dados históricos, criando vários registros de uma
determinada chave natural nas tabelas dimensionais com distintas chaves
substitutas e / ou números de versão diferentes. Histórico ilimitado é preservado
para cada inserção.
Por exemplo, se o fornecedor se muda para Illinois números da versão serão
incrementados sequencialmente:
O END_DATE nulo na linha dois indica a versão atual. Em alguns casos, uma
data substituta inválida (por exemplo, 9999-12-31) pode ser usada como uma
data de fim, de modo que o campo pode ser incluído em um índice, e de modo
que o valor nulo de substituição não será necessária quando se realizar a
consulta.
Transações que fazem referência a uma determinada chave
substituta (Supplier_Key) são, então, permanentemente ligadas aos intervalos
de tempo definidos por essa linha da dimensão. Uma tabela agregada resumindo
fatos pelo Estado continua a refletir o estado histórico, ou seja, o estado que
fornecedor estava no momento da transação; não há necessidade de
atualização.
Se houver alterações no conteúdo da dimensão, ou, se novos atributos forem
adicionados à dimensão (por exemplo, uma coluna Sales_Rep) que têm
Aplicações em ETL . 19
diferentes datas efetivas dos já definidos, então as transações existentes
necessitam de ser atualizadas para refletir a nova situação. Esta pode ser uma
operação de banco de dados custosa por isso tipo 2 SCDs não são uma boa
opção se o modelo dimensional está sujeito a alterações.
Tipo 3
Dois atributos são mantidos na dimensão, um representando o valor atual e o
outro representando o valor anterior. Não é recomendado quando se deseja um
histórico mais completo.
O Tipo 3 preserva o histórico limitado, uma vez que é limitada ao número de
colunas designadas para o armazenamento de dados históricos. A estrutura da
tabela original, em Tipo 1 e Tipo 2 é a mesma, mas do tipo III acrescenta
colunas adicionais. No exemplo a seguir, uma coluna adicional foi adicionada
Original_Suppli Current_Supplier_
Supplier_Key Supplier_Code Supplier_Name Effective_Date
er_State State
Acme Supply
123 Abc CA 22-Dez-2004 IL
Co
Aplicações em ETL . 20
Capítulo 3 - Fatos
Por exemplo:
- Tempo de permanência em site
- Quantidade de visitas
Por exemplo:
- Valor do prêmio emitido
- Valor do sinistro pago
Pode também quantificar uma característica da transação.
Por exemplo:
- Quantidade de propostas implantadas
- Quantidade de beneficiários
Por exemplo:
Taxa de Cancelamento de Proposta = Quantidade de Propostas
Canceladas/Quantidade de Propostas Emitida
Aplicações em ETL . 21
Fatos sem Fato
Às vezes é necessário vistoriar indicadores que não são representados por
uma quantidade ou valor, como por exemplo, mudança de status.
Nesse caso é utilizado o recurso de se criar uma tabela de fatos sem fatos.
Para facilitar a implementação de consulta, sugere-se a inclusão de uma
coluna de quantidade que terá sempre o valor igual a 1.
Uma tabela de fatos, tipicamente sem fatos, que registra todos os produtos que
estão em promoção numa determinada loja, independentemente de ser vendidos
ou não.
Consulta: Quais produtos estavam em promoção, mas não venderam?
Fatos acumulados
Representam um tempo indeterminado, que cobre o ciclo de vida da
transação ou do produto ou pessoa. Quase sempre possuem múltiplas datas,
representando os múltiplos eventos ou fases que ocorrem durante o curso de um
ciclo de vida.
Por exemplo:
- Carteira de Clientes.
Aplicações em ETL . 22
QTD Estoque
400 Ton
Depósito
Jan/2013
Figura 19 - Fatos acumulados
Aplicações em ETL . 23
Agregações de Fatos
Para tornar a consulta mais ágil, podem ser criadas tabelas de agregação, com a
exclusão de dimensões associadas ao fato ou com a associação a um nível
superior da hierarquia.
FATOS ADITIVOS
Fatos aditivos são aqueles em que se pode usar funções de grupo matemáticas
(SUM, COUNT...) para gerar a agregação.
Por exemplo:
Aplicações em ETL . 24
Figura 21 - Fatos aditivos
FATOS SEMI-ADITIVOS
Por exemplo:
- Saldo de estoque.
FATOS SEMI-ADITIVOS
Fatos não aditivos são aqueles em que não se pode usar funções de grupo
matemáticas (SUM,COUNT...) para gerar a agregação. É o caso de valores
relação/razão entre fatos.
Por exemplo:
Aplicações em ETL . 25
Figura 23 - Fatos não aditivos
Figura 24 - ODS
Aplicações em ETL . 26
Capítulo 4 – Modelagem Dimensional
Modelos
O modelo dimensional para construção de banco de dados para Data
Warehouse é uma forma de modelagem onde as informações se relacionam de
forma que pode ser representada como um cubo. Sendo assim podemos fatiar
este cubo e aprofundar em cada dimensão ou eixo para extrair mais detalhes
sobre os processos internos que ocorrem na empresa que em um modelo
relacional torna-se muito complicados de serem extraídos e muitas vezes até
impossíveis de serem analisadas.
O modelo dimensional permite visualizar dados abstratos de forma simples e
relacionar informações de diferentes setores da empresa de forma muito eficaz.
O que torna o Data Warehouse mais poderoso é que informações que se
situam em vários sistemas, planilhas e arquivos espalhados por todos os setores
da empresa, são reunidos em um banco de dados de forma dimensional, sendo
assim tendo informações unificadas e padronizadas em um mesmo local.
Vejamos o caso de uma empresa que possui várias lojas filiais e que deseja
acompanhar o desempenho de suas vendas ao longo do tempo. Um desenhista
de Data Warehouse visualiza estas informações de uma forma como um cubo
que pode ser descrito com três dimensões principais que são:
- Tempo
- Loja
- Produto
Na intersecção destas três dimensões está a quantidade de produtos que foi
vendido.
Modelos
Neste modelo cada cubo menor, ou seja, a intersecção entre as dimensões ou
eixos, representa uma quantidade de um produto que foi vendido em uma
determinada loja em uma data especifica.
Mas se quisermos saber e controlar também se os produtos que foram
vendidos participavam de uma promoção teríamos que ter mais uma dimensão
chamada PROMOÇÃO, e se quisermos controlar em cada momento as equipes de
marketing que atuaram em cima das promoções e das lojas devemos ter mais
outra dimensão, e se quisermos controlar os clientes que compraram os
produtos teríamos que ter uma dimensão Clientes, sendo assim teríamos um
modelo com seis dimensões. Não é possível desenhar tantas dimensões
Aplicações em ETL . 27
graficamente, mas seguem o mesmo conceito de cubo, pois é possível navegar,
aprofundar-se, detalhar e acompanhar os desempenhos destas dimensões ao
longo do tempo. Um modelo dimensional pode ter quantas dimensões forem
necessárias.
Um modelo de dados dimensional é extremamente simples, isto facilita para
os usuários deste banco de dados identificarem onde estão localizadas as
informações e permite que os softwares que naveguem por estes bancos de
dados com eficiência. Outro fator importante para a modelagem dimensional é a
velocidade de acesso a uma informação, com modelos simples sem muitas
tabelas para relacionar, é muito rápido para extrair as informações necessárias.
Um modelo dimensional conta basicamente com uma tabela de fatos central e
tabelas dimensionais ligadas diretamente a elas.
Modelos
As tabelas de Dimensões contêm descrições textuais sobre cada um dos
elementos que fazem parte do processo, no exemplo que citamos temos três
dimensões (Tempo, Loja e Produto) as tabelas dimensionais contêm vários
atributos que descrevem em detalhes todas as características que possam definir
e serem úteis para futuras pesquisas no Data Warehouse.
A dimensão Produto deve ter descrições curtas e detalhadas sobre o produto,
deve também ter o tamanho, peso, categoria, cor, departamento, marca, tipo da
embalagem, etc. Ou seja, todos os atributos que podem definir o produto e que
possam ser utilizados para futuras pesquisas e analises que ajudarão o
empresário a tomar decisões sobre seu negócio.
A dimensão Loja deve conter informações sobre as lojas que fazem parte do
complexo do negócio, dentre estas informações deve ter descrições como
endereço, CEP, região, cidade, bairro, telefone, gerente, etc.
A dimensão Tempo deve ter detalhes sobre o calendário para que facilite
pesquisas estratégicas, então a dimensão tempo não deve ter somente a data
Aplicações em ETL . 28
em que o produto foi vendido, mas deve conter informações como dia no mês,
dia na semana, número do dia na semana, mês, número do mês no ano, ano,
número da semana no ano, número de semanas corridas, número de meses
corridos por trimestre, período fiscal, indicador de feriado, indicador de fim de
semana, indicador de último dia do mês, etc.
Aplicações em ETL . 29
que são necessárias para defini uma classe como Produto, Tempo ou Loja nela
mesma, ou seja, as tabelas de dimensões não são normalizadas no modelo
estrela, então campos como Categoria, Departamento, Marca contém suas
descrições repetidas em cada registro, assim aumentando o tamanho das
tabelas de dimensão por repetirem estas descrições de forma textual em todos
os registros.
As dimensões são desnormalizadas. Uma hierarquia é implementada em uma
única tabela, ou os níveis são associados diretamente à tabela de fatos.
Aplicações em ETL . 30
MODELO STARFLAKE
É um híbrido entre os modelos star e Snowflake, aproveitando o melhor de
cada um.
Produto
Linha
CONSIDERAÇÕES
O Modelo Floco (Snow Flake) reduz o espaço de armazenamento dos dados
dimensionais, mas acrescenta várias tabelas ao modelo, deixando-o mais
complexo, tornando mais difícil a navegação pelos softwares que utilizarão o
banco de dados. Outro fator é que mais tabelas serão utilizadas para executar
uma consulta, então mais JOINS de instrução SQL serão feitos, tornando o
acesso aos dados mais lento do que no modelo estrela.
O Modelo Estrela (Star Schema) é mais simples e mais fácil de navegação
pelos softwares, porém desperdiça espaço repetindo as mesmas descrições ao
longo de toda a tabela, porém análises feitas mostram que o ganho de espaço
normalizando este esquema resulta em um ganho menor que 1% do espaço
total no banco de dados, sendo assim existem outros fatores mais importantes
para serem avaliados para redução do espaço em disco como a adição de
agregados e alteração na granularidade dos dados, estes temas serão abordados
em colunas posteriormente.
Aplicações em ETL . 31
Tratamentos de Dados
Para que os dados saiam de um modelo origem e migrem para um modelo
dimensional, são necessários cinco tratamentos diferentes (filtro, integração,
condensação, conversão e derivação), divididos em 3 processos (extração,
transformação e carga).
FILTROS DE DADOS
Por exemplo:
- Selecionar apenas os segurados ativos.
Aplicações em ETL . 32
INTEGRAÇÃO DE DADOS
Por exemplo:
Segurado de Automóvel e segurado de Saúde com informações comuns
(nome, endereço) e informações específicas a cada área;
Condensação de Dados
Define a forma de reduzir o volume de dados visando obter informações
resumidas e sumariadas (agregações).
Por exemplo:
Aplicações em ETL . 33
Visão
Dimensional
Conversão de Dados
Define os procedimentos para se transformar dados em unidades e formatos
diferentes.
Por exemplo:
- Conversão de datas
- Unidades monetárias
- Taxas
DERIVAÇÃO DE DADOS
Por exemplo:
- Cálculo de percentuais
- Médias
- Desvios padrões
Aplicações em ETL . 34
ACUMULA DIA
A DIA
DIA ANTERIOR
+ DIA ATUAL
Aplicações em ETL . 35
Capítulo 5 – Processo ETL Parte I
Staging Área
A Staging área é uma etapa muito importante no desenvolvimento do Data
Warehouse. É a área intermediária onde são armazenados temporariamente os
dados extraídos da origem e que serão devidamente tratados e armazenados no
DW. A Staging área é o subsídio necessário para a carga das dimensões e fatos.
Representa um armazenamento intermediário dos dados, facilitando a
integração dos dados antes de sua atualização no ODS e posteriormente no DW.
A Staging área não tem como função sumarizar dados, mas agilizar o
processo de consolidação, proporcionado um melhor desempenho na fase da
atualização dos dados. A Staging Área é o único lugar para determinar os
valores que vêm efetivamente dos sistemas legados. A Staging Área dever ser
usada para limpeza dos dados que entram no processo de extração e
transformação.
O Staging Área ou área de retenção é a parte mais importante na construção
de um DW. São varias as utilidades e funcionalidades da Staging Área.
Primeiro é a Extração. A extração basicamente seria buscar as informações
dos sistemas legados e fontes externas da empresa e coloca-las na Staging Área
para validação, transformação e carga. Existem varias técnicas para fazer isso,
vamos ver algumas nos próximos artigos. O importante é termos as informações
novas ou atualizadas do dia anterior, tendo assim um retrato dia a dia do que foi
incluído, excluído e alterado. A partir dai não precisamos mais do banco de
dados de produção, ou seja, não corremos o risco de concorrer consumindo
assim recursos dos sistemas legados.
Segundo é a Transformação. Com os dados do dia anterior na Staging Área
podemos fazer as transformações necessárias. Essas transformações vão variar
dependendo da modelagem e dos sistemas ERPs. Vamos citar um exemplo bem
simples de transformações: No sistema X1 temos um campo na tabela tb1 com
o nome sexo que se refere ao sexo da pessoa onde “F” feminino e “M”
Masculino. Já no sistema X2 temos um campo na tabela tb2 com o nome sexo
que se refere ao sexo da pessoa onde “0” feminino e “1” Masculino. Bem na
Staging Área tratamos essas transformações, ou seja, definimos por exemplo
que vamos usar 0 e 1 para definir feminino e masculino . Então a Staging Área
recebe do sistema X1 da tabela tb2 os dados em forma de “F” e “M” e
transforma em 0 e 1. Assim podemos receber os dados de varias formas, mas
ao chegar ao DW sempre será 0 ou 1.
Terceiro é a Carga. O processo de carga é realizado após todos os
tratamentos feitos nos dados nos processos de extração e transformação. Essa
etapa consiste em carregar os dados tratados, limpos e armazenados na Staging
Área para o DW.
Lembramos que a Staging Área é carregada e limpa todos os dias. Ela não
armazena os dados, só recebe, transforma e entrega para o ODS. Após a
entrega dos dados no ODS ela é limpa.
Podemos resumir a Staging Área como sendo o ambiente intermediário de
armazenamento e processamento dos dados oriundos de aplicações OLTP e
outras fontes, para o processo de extração e transformação e carga (ETL),
possibilitando o seu tratamento, e evitando problemas como concorrência com o
ambiente transacional no consumo de recursos.
Aplicações em ETL . 36
Exemplos de tabelas geradas na Staging Área:
- Staging1
Características:
1. Query de carga idêntica à tabela de origem
2. Fonte de Origem é a tabela origem
3. Levam-se todos os campos da tabela origem
4. Não existe chave primária na ST1
5. Método de carga escolhido Truncate
6. A cada processamento a tabela será esvaziada e carregada novamente
Staging2 Aux
Características:
1. Query de carga com transformações e cálculos;
2. Fonte de origem é a ST1;
3. Levam-se os campos que serão utilizados nas Dimensões e Fatos;
4. Existe chave primária na ST2. A chave montada é a chave de negócio;
5. Método de carga escolhido Truncate;
6. Latência diária;
7. A cada processamento a tabela será esvaziada e carregada novamente.
Staging2
Características:
1. Query de carga com transformações e cálculos;
2. Fonte de origem é a ST1;
3. Levam-se os campos que serão utilizados nas Dimensões e Fatos;
4. Existe chave primária na ST2. A chave montada é a chave de negócio;
5. Método de carga escolhido Update/Insert;
6. A latência dessa tabela será de todo o período de carga do dw.
7. A cada processamento a tabela será atualizada com alterações de
registros já existentes e com novos registros.
Aplicações em ETL . 37
CONSIDERAÇÕES
STAGING2 AUX
QUERY COM TRANSFORMAÇÕES
ORIGEM ST1
APENAS CAMPOS QUE SERÃO UTILIZADOS NA
DIMENSÃO
POSSUI CHAVE PRIMÁRIA
MÉTODO TRUNCATE
POUCO ESPAÇO DE ARMAZENAMENTO
LATÊNCIA PEQUENA - DIÁRIA
STAGING2
QUERY COM TRANSFORMAÇÕES
ORIGEM ST1
APENAS CAMPOS QUE SERÃO UTILIZADOS NA
DIMENSÃO
POSSUI CHAVE PRIMÁRIA
MÉTODO UPDATE/INSERT
MAIOR ESPAÇO DE ARMAZENAMENTO
LATÊNCIA GRANDE - ANOS
Código Descrição
-1 Não se Aplica
-2 Não cadastrado
AGREGAR VISÃO DO
PELO ÚLTIMO
DIA DO
SATUS MÊS
Aplicações em ETL . 38
Processo de carga dimensões
As cargas das dimensões serão originadas a partir das ST2 de Dimensões.
- Dimensão
Características:
1. Query apenas de leitura da ST2, pois as transformações já foram feitas
2. Fonte de Origem é a ST2 Aux para carga diária e a ST2 para carga full
3. Altera-se algum nome de campo para se adequar as regras da corporação
de acordo com o Dicionário de Dados da mesma
4. Para cada chave de negócio será gerada uma SRK
5. A SRK é um campo numérico sequencial
6. O método de carga de uma dimensão é sempre update/insert com
exceção das dimensões que guardam histórico das alterações
7. A cada processamento a tabela será esvaziada e carregada novamente.
As SRK`s das Dimensões serão utilizadas nas Fatos. Portanto não é possível
ser ter chaves nulas nas Fatos. Para resolvermos esse problema criamos nas
dimensões dois registros especiais.
Ex: Para determinados produtos existe a Categoria Produto, para outros não
existe essa informação. Então ao carregar a Fato, os Produtos que possuem
Categoria Produto carregarão a SRK correspondente e para os que não possuem
a Categoria Produto, será carregado o registro especial de acordo com a regra
de negócio estabelecia.
Aplicações em ETL . 39
Processo de carga das tabelas fatos
As cargas das tabelas de Fatos serão originadas a partir das ST2 de Fato e das
Dimensões.
Fatos
Características:
2. Fonte de Origem é a ST2 Aux para carga diária e a ST2 para carga full;
3. O método de carga de uma dimensão é sempre update/insert.
4. A cada processamento os campos selecionados anteriormente com update
serão alterados e novos registros serão inseridos diariamente.
Aplicações em ETL . 40
Capítulo 5 – Processo ETL Parte II
Tratamento de Erro
ERRO
- Erro ao não encontrar na Dimensão uma ocorrência da tabela de Fato.
Por Exemplo:
- No arquivo contendo as Transações diárias, que carregará a Fato F_TXN, existe
a ocorrência de algumas Transações para o cliente 1045. Porém o cliente 1045
não foi encontrado carregado na dimensão DM_CLIENTE.
TABELA
DESTINO
CONTROLE DE REJEIÇÃO MAPEAMENTO
DOS CAMPOS
Tratamento de erro
PROCESSO E TRATAMENTO
TABELA DE REJEIÇÃO
Características:
Aplicações em ETL . 41
I. Todas as chaves de negócio
II. Um campo contendo a razão da rejeição: rejeição srk_cli não encontrada.
Características:
1. Essa tabela terá a mesma visão da tabela de rejeição, porém ela terá o
método append a fim de guardar o histórico das rejeições;
2. Será criado um campo de data de carga, dat_crg para controle da data da
rejeição.
3. Deverá ser criado um processo com uma query semelhante à query de
carga da tabela fato, porém, terá como principal tabela a rejeição histórica ao
invés da ST2.
4. Esse processo irá verificar se o que está na tabela de rejeição já foi
carregado nas dimensões.
5. Se as ocorrências da rejeição histórica forem encontradas nas dimensões
os registros serão carregados na tabela fato.
6. Se as ocorrências da rejeição histórica não forem encontradas nas
dimensões os registros serão carregados na tabela rejeição.
7. Esse processo será repetido diariamente e acontecerá logo após o
processo de carga das tabelas fatos.
Aplicações em ETL . 42
Bibliografia
http://www.ralphkimball.com/
http://www.devmedia.com.br/
http://pt.slideshare.net/robsjc/conceitos-gerais-de-etl-qlikview#
http://www.datawarehouse.inf.br/etl.htm
http://www.dataprix.net/pt-pt/blogs/juan-vidal/aspectos-avaliar-sele-o-uma-ferramenta-etl
http://luanmorenodba.wordpress.com/2010/09/03/18/
http://social.technet.microsoft.com/wiki/contents/articles/5917.aspx
http://www2.ifsp.edu.br/edu/prp/sinergia/complemento/sinergia_2012_n3/pdf_s/segmentos/a
rtigo_02_v13_n3.pdf
Aplicações em ETL . 43