Aplicações em ETL

Fernanda Leôncio Garro Costa de Pinho

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

O que significa a sigla ETL?

ETL vem do inglês Extract, transform and load, ou seja: extração,
transformação e carga. É uma coleção de processos associados à extração dos
dados de origem, transformação desses dados e, finalmente, carga dos dados
em um Data Warehouse e/ou Data Mart. Nada impede que também seja
utilizado para enviar os dados para um determinado sistema da organização. A
extração e carga são obrigatórias para o processo, sendo a
transformação/limpeza opcional, mas que são boas práticas, tendo em vista que
os dados já foram encaminhados para o sistema de destino. É considerada uma
das fases mais críticas do Data Warehouse e/ou Data Mart.
Os projetos de data warehouse consolidam dados de diferentes fontes. A
maioria dessas fontes tende a ser bancos de dados relacionais ou arquivo de
texto (texto plano), mas podem existir outras fontes. Uma aplicação ETL tem
que ser capaz de se comunicar com as bases de dados e ler diversos formatos
de arquivos utilizados por toda a organização. Essa pode ser uma tarefa não
trivial, e muitas fontes de dados podem não ser acessadas com facilidade.

Figura 1 - Visão do ETL

O que significa a sigla ETL?

EXTRAÇÃO
É a coleta de dados dos sistemas de origem (também chamados Data Sources
ou sistemas operacionais), extraindo-os e transferindo-os para o ambiente de
DW, onde o sistema de ETL pode operar independente dos sistemas
operacionais.
O primeiro passo a ser tomado no processo de ETL é simplesmente a definição
das fontes de dados e fazer a extração deles. As origens deles podem ser várias
e também em diferentes formatos, onde poderemos encontrar desde os
sistemas transacionais das empresas até planilhas, flat files (arquivos textos),

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...

É importante avaliar a necessidade da empresa, custo da ferramenta,

funcionalidades da ferramenta e 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.

Custo de mão de obra

Algumas ferramentas possuem curva de aprendizado mais íngreme, dessa
forma, onerando a mão de obra.

O que significa a sigla ETL?

As ferramentas de ETL mais utilizadas no mercado são o Data Stage da
Ardent, agora adquirido pela Informix, o ETI da IBM, Sagent da própria Sagent,
Informática Power Conect da Informática e o DTS da Microsoft. Todas têm os
seus diferenciais e cada um poderá ser utilizado dependendo do caso de cada
empresa.
O que vale dizer é que uma ferramenta de ETL tem grande valia,
principalmente se os sistemas OLTP (transacionais) são muitos, pois elas são
uma poderosa fonte de geração de metadados, e que contribuirão muito para a
produtividade da sua equipe, porém deve-se tomar muito cuidado ao escolhê-la.
Seja minucioso, teste o máximo de ferramentas que puder e veja qual é a
mais adequada ao seu caso, pois elas exigem um alto investimento, tanto em
capacitação, quanto na própria aquisição. Em alguns casos é interessante o
auxílio de profissionais externos para a escolha. O fato verdadeiro é que os

Aplicações em ETL . 5
benefícios serão bastante vistosos e a produtividade aumentará
consideravelmente.

Figura 2 - Visão extração

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.

O que significa a sigla ETL

É nesta etapa que realizamos os devidos ajustes, podendo assim melhorar a
qualidade dos dados e consolidar dados de duas ou mais fontes. O estágio de
transformação aplica uma série de regras ou funções aos dados extraídos para
ajustar os dados a serem carregados.

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.

Figura 3 - Visão Transformação I

Figura 4 - Visão Transformação II

Figura 5 - Visão Transformação II

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

ETL é um processo importante

O processo ETL é uma das fases mais críticas na construção de um sistema
DW. Porque grandes volumes de dados são processados e serão implementadas
as regras e fórmulas dos indicadores que irão compor as tabelas de Fato. Nessa
fase está contida maior parte da inteligência da aplicação de BI.
Estudos relatam que o ETL e as ferramentas de limpeza de dados consomem
um terço do orçamento num projeto de DW, podendo, no que respeita ao
TEMPO de desenvolvimento de um projeto de DW, chegar a consumir 80%
desse valor. Outros estudos mencionam, ainda, que o processo de ETL tem
CUSTOS na ordem dos 55% do tempo total de execução do projeto de DW.

Aplicações em ETL . 8
 Front-End OLAP, DashBoard,
BSC

Extração Servidores

Integração Rede

Limpeza de Middleware
Dados

Figura 7 - Visão Importância ETL

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 para ETL

Antes de iniciar um projeto de ETL é necessário que os seguintes itens
estejam bem alinhados:

Requisitos de negócio

Você tem bem claro e documentado quais são os requisitos de negócio?

Como em qualquer projeto de desenvolvimento de software - inclusive para

projetos de Business Intelligence e Data Warehouse - existe a fase de
"levantamento de Requisito". O que acontece com a maioria dos Gestores e não
conhecedores do assunto é achar que as técnicas utilizadas no levantamento de
requisitos, para desenvolvimento de softwares, devem ser aplicadas na
construção de um DW. Esse é um erro básico que pode levar uma
implementação de DW ao fracasso. "Não estou afirmando que não podemos
adotar nenhuma técnica de Engenharia de Software", temos que entender que
são assuntos totalmente diferentes.
Existem várias abordagens para reunir os requisitos de informação. Isso não
significa que não há espaço para outras técnicas, tais como: brainstorming,
questionários, prototipagem, observações, casos de uso e etc. Porém devemos
ressaltar que nenhuma substitui a participação direta entre o analista, clientes
(interno ou externo).
Um fator determinante para o sucesso na sua gestão ou implementação é não
criar frustrações com o seu stakeholder, afinal isso é um Data Warehouse. Só
podemos carregar informação que existam nos sistemas legados, o que pode
acontecer é "se" futuramente algo for implementado podemos implementar no
nosso repositório.

Figura 8 - Requisitos de Negócio

Viabilidade dos Dados

Foi realizado uma análise de viabilidade dos dados?

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?

Cada tabela no DW pode ter um determinado tempo para guardar histórico. É

possivel se ter as tabelas de ST1 que armazenam apenas a visão diária.
Podemos ter as Dimensões que armazenam as informações processadas desde o
inicio do DW. Algumas fatos com visão de evolução de treze meses. Carteiras
com a visão dos últimos dois anos. A latência de cada tabela deve ser levantada
para que exista um planejamento sobre a expansão do banco utilizado pelo DW.

Políticas de Compliance e Segurança

Quais são as políticas de compliance e segurança adotadas pela empresa?

Compliance é o conjunto de disciplinas para fazer cumprir as normas legais e

regulamentares, as políticas e as diretrizes estabelecidas para o negócio e para
as atividades da instituição ou empresa, bem como evitar, detectar e tratar
qualquer desvio ou inconformidade que possa ocorrer.
Políticas de Segurança tem haver com a segurança aplicada a dados e
acessos. Tudo deve ser verificado antes de se iniciar o projeto para que essas
políticas não impactem no desenvolvimento do mesmo.

Figura 9 - Segurança de Dados

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

• Banco de dados Gerencial

• Extração • Informações relevantes dos sistemas
• Tratamento • Integrado
Arquivos • Integração
• Consistência • Não volátil
• Publicação • Cobrindo um grande período histórico

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

Data Mart (DM)

Subconjuntos de um DW completo. São pequenos DW, de visão
departamental ou de um determinado assunto, com o propósito de fornecer
visão estratégica dos dados setorizados.
Características:
 Consolidação de regras de negócio departamentais;
 Contém tabelas que consolidam as informações do DW
(Ex: Agregadas Mensais)
 Requer grande espaço de armazenamento.

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

Figura 11 - Business Intelligence II

Aplicações em ETL . 14
Capítulo 2 - Dimensões

Conhecendo e entendo as Dimensões e seus variados tipos.

O que é uma dimensão?

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).

Fluxo de Carga ETL

Custos
DM
DM Comercial

Figura 12 - Dimensão I

As dimensões relacionam-se através de hierarquias. Isto permite que um

indicador, embora estando ligado a apenas uma dimensão da hierarquia, possa
ser visto por todas as dimensões superiores a ela na hierarquia.

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

A chave primária de uma dimensão é sempre uma chave substituta

(surrogate key). Isso facilita a integração de diferentes fontes de dados. Na
carga da tabela de dimensão podem ser feitas operações de inserção (insert) e
atualização (update).

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:

- Número de ordem de compra

- Número de fatura
- Número de autorização

A decisão de usar uma dimensão degenerada é muitas vezes baseada no

desejo de fornecer uma referência direta a um sistema transacional, sem a
sobrecarga da manutenção de uma tabela dimensão separada.

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).

Figura 15 - Dimensão Junk I

O segundo conceito de dimensão junk está associada a dimensões degeneradas

que são representadas por textos, como observações, avaliações por extenso.

Aplicações em ETL . 17
 Figura 16 - Dimensão Junk II

Slowly Chanching Dimension

A maioria das dimensões são relativamente estáveis. Mas como registrar
mudanças de endereço, estado civil, alterações de hierarquia (sucursal mudando
de superintendência)? Existem três soluções possíveis

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:

Supplier Key Supplier_Code Supplier_Name Supplier_State

123 Abc Acme Supply Co CA

No exemplo acima, é Supplier_Code a chave natural e Supplier_Key é

uma chave substituta . Tecnicamente, a chave substituta não é necessária, uma
vez que a linha será exclusiva pela chave natural (Supplier_Code). No entanto,
para otimizar o desempenho usa-se um inteiro ao invés caracteres. Se o
fornecedor é transferido para a sede de Illinois o registro será substituído:

Supplier_Key Supplier_Code Supplier_Name Supplier_State

123 Abc Acme Supply Co IL

A desvantagem do método de tipo I é que não há nenhum histórico no data

warehouse. A vantagem, porém, é que é fácil de fazer o processo de
atualização.

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:

Supplier_Key Supplier_Code Supplier_Name Supplier_State Versão

123 Abc Acme Supply Co CA 0

124 Abc Acme Supply Co IL 1

Outro método consiste em adicionar colunas "data efetiva".

Supplier_Key Supplier_Code Supplier_Name Supplier_State START_DATE END_DATE

Acme Supply 01-Jan- 21-Dez-

123 Abc CA
Co 2000 2004

Acme Supply 22-Dez-

124 Abc IL
Co 2004

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

para gravar o estado original do fornecedor - apenas o histórico anterior é

armazenado.

Dimensão de mudança rápida

No caso de dimensões com alto volume e alta volatilidade, a estratégia
recomendada e a divisão dos dados da dimensão em duas tabelas. Em uma
tabela ficam os dados estáticos e em outra os dados voláteis.
Com isso, a tabela volátil cresce à medida que o histórico é registrado e a parte
estática fica estável.

Figura 17 - Dimensão de Mudança Rápida

Aplicações em ETL . 20
Capítulo 3 - Fatos

O que é uma tabela Fato?

É a tabela de um Data warehouse, que armazena os valores detalhados de

Métricas ou Fatos. Métricas são medidas brutas que servem de subsídios aos
indicadores. São compostas por vários tipos, como valor, quantidade, peso,
volume ou outro formato quantitativo.

Por exemplo:
- Tempo de permanência em site
- Quantidade de visitas

Um fato representa um indicador de análise elementar.

O indicador de análise é uma medição numérica que pode, por exemplo,
representar medidas relacionadas ao negócio.

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

Os indicadores podem ser classificados como:

Indicadores elementares: não podem ser fracionados em outros valores. Os

indicadores elementares que apresentam as mesmas características e que
podem ser visualizados pelas mesmas dimensões são agrupados nas chamadas
tabelas de fatos.

Indicadores compostos: são resultantes de cálculos realizados com outros

indicadores. Para cada indicador composto será apresentada a sua fórmula de
cálculo.

Por exemplo:
Taxa de Cancelamento de Proposta = Quantidade de Propostas
Canceladas/Quantidade de Propostas Emitida

A chave primária da tabela de fatos é composta das chaves primárias das

dimensões que a qualifica. Na carga da tabela de fatos são feitas somente
operações de inserção (insert).

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.

Figura 18. Fato sem fato

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.

Figura 20 - Fatos agregadas

Cuidados nas agregações

Deve-se dar atenção aos tipos de fato durante a agregação. São três tipos de
fato:
- Aditivos
- Semi-aditivos
- Não aditivos.

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:

- Quantidade de segurados ativos

- Valor do Prêmio e valor do sinistro

Aplicações em ETL . 24
 Figura 21 - Fatos aditivos

FATOS SEMI-ADITIVOS

Fatos semi-aditivos são aqueles em que se pode usar funções de grupo

matemáticas (SUM, COUNT...) para gerar a agregação em algumas dimensões
mas em outras não.

Por exemplo:

- Saldo de estoque.

Figura 22 - Fatos Semi Aditivos

Cuidados nas agregações

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:

- Percentual de participação na venda.

Aplicações em ETL . 25
 Figura 23 - Fatos não aditivos

Operacional Data Sore (ODS)

Uma ODS pode ser usada para integrar dados de várias fontes diferentes, de
modo, que as operações de negócios, análise e relatórios possam ser realizadas
enquanto as operações de negócios estão ocorrendo.
Este é o lugar onde a maioria dos dados utilizados na operação atual está
inserido antes de ser transferido para o Data Warehouse para armazenamento
em longo prazo.
Uma ODS é projetada para consultas relativamente simples em pequenas
quantidades de dados (tais como encontrar o status de um pedido do
cliente). Ela é semelhante à sua memória de curto prazo em que armazena
apenas informação muito recente. ODS é uma tabela desnormalizada.

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.

Figura 25 - Modelagem Dimensional I

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.

Figura 26 - Modelo Dimensional II

Os Fatos e Dimensões são tabelas do banco de dados, só que no modelo

dimensional adquirem nomes de Fatos e Dimensões de acordo com a função da
tabela.
Uma tabela de Fatos, em nosso exemplo “Fatos Vendas” contém medições
sobre o negócio como a quantidade de produtos que foi vendido, contém o valor
da venda e o valor unitário do produto vendido. Além destas informações de
fatos, esta tabela contém chaves para as tabelas de dimensões. Uma tabela de
fatos é extremamente grande referente à quantidade de registros que contém
neste exemplo ela armazena todas as vendas de cada produto feitas em cada
loja todos os dias. É comum uma tabela de fatos alcançar alguns Gigabytes logo
nos primeiros meses de uso do Data Warehouse.

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.

MODELO SNOW FLAKE

No modelo Snow Flake as tabelas dimensionais relacionam-se com a tabela de
fatos, mas algumas dimensões relacionam-se apenas entre elas, isto ocorre para
fins de normalização das tabelas dimensionais, visando diminuir o espaço
ocupado por estas tabelas, então informações como Categoria, Departamento e
Marca tornaram-se tabelas de dimensões auxiliares. As dimensões são
normalizadas. Cada nível da hierarquia é implementada em uma tabela de
dimensão.

Figura 27 - Modelo Snow Flake

No modelo Snow Flake existem tabelas de dimensões auxiliares que

normalizam as tabelas de dimensões principais. Na figura anterior estas tabelas
são (Ano, Mês e Dia) que normalizam a Dimensão Tempo, (Categoria,
Departamento e Marca) que normalizam a Dimensão Produto e a tabela Meio
que normaliza a Dimensão Promoção.
Construindo a base de dados desta forma, passamos a utilizar mais tabelas
para representar as mesmas dimensões, mas ocupando um espaço em disco
menor do que o de outros modelos. Este modelo chama-se Snow Flake, pois
cada dimensão se divide em várias outras tabelas, onde organizadas de certa
forma lembra um floco de neve.

MODELO STAR SCHEMA

No modelo Star todas as tabelas relacionam-se diretamente com a tabela de
fatos, sendo assim as tabelas dimensionais devem conter todas as descrições

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.

Figura 28 - Modelo Star

Este modelo é chamado de Star porque a tabela de fatos fica ao centro
cercado das tabelas dimensionais assemelhado a uma estrela.

Aplicações em ETL . 30
MODELO STARFLAKE
É um híbrido entre os modelos star e Snowflake, aproveitando o melhor de
cada um.

Produto
Linha

Figura 29 - Modelo Starflake

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

Relaciona os procedimento e condições para selecionar os dados desejáveis no

modelo dimensional.

Por exemplo:
- Selecionar apenas os segurados ativos.

/* selecionar apenas clientes Ativos*/

1 – Select nom_cli, des_end, num_tel, cpf_cnpj
from dm_cli
where cod_sta = ‘A’

- Selecionar clientes do Sexo Feminino.

/* selecionar apenas clientes do sexo Feminino*/

2 – Select nom_cli, des_end, num_tel, cpf_cnpj
from dm_cli
where idt_sex = 1

- Selecionar apenas clientes do tipo pessoa Jurídica.

/* selecionar apenas clientes do tipo pessoa Jurídica*/

3 – Select nom_cli, des_end, num_tel, cpf_cnpj
from dm_cli
where tip_pessoa = 2

Aplicações em ETL . 32
INTEGRAÇÃO DE DADOS

Define a forma de se correlacionar informações existentes em fontes de dados

distintas.

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;

 Codificação diferenciada em dimensões (sexo, estado civil e outras).

Figura 30 - Integração Dados

Condensação de Dados
Define a forma de reduzir o volume de dados visando obter informações
resumidas e sumariadas (agregações).

Por exemplo:

 Ao invés de exibir o cliente e o status do mesmo, cria-se indicadores de

Qtd. Clientes Ativos, Qtd. Clientes Inativos...

 Ao invés de exibir Transação a Transação cria-se o indicador Qtd.

Transações.

Aplicações em ETL . 33
 Visão
Dimensional

Figura 31 - Consolidação Dados

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

1 - SELECT TO_DATE(SYSDATE, 'DD/MM/RRRR HH24:MI:SS') FROM DUAL.

2 - SELECT TO_DATE(SYSDATE, 'DD/MM/YY') FROM DUAL.

DERIVAÇÃO DE DADOS

Define fórmulas a partir de dados existentes, minimizando a complexidade de

uma consulta ou aumentando a sua performance.

Por exemplo:

- Cálculo de percentuais
- Médias
- Desvios padrões

Aplicações em ETL . 34
 ACUMULA DIA
A DIA
DIA ANTERIOR
+ DIA ATUAL

Figura 32 - Derivação Dados

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

A ST2 AUX TEM COMO OBJETIVO OTIMIZAR O

PROCESSO DE CARGA DIÁRIO.

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

A ST2 TEM COMO OBJETIVO SERVIR DE BASE

PARA POSSÍVEIS REPROCESSAMENTOS.

Código Descrição
-1 Não se Aplica
-2 Não cadastrado

AGREGAR VISÃO DO
PELO ÚLTIMO
DIA DO
SATUS MÊS

Figura 33 - Processo de Carga

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.

Processo de carga dimensões

CONEXÃO SISTEMA MAPEAME

ORIGEM NTO DOS
CAMPOS CAMPO TEXTO
CONEXÃO RECEBERÁ AS
DESTINO DESCRIÇÕES
NÃO SE

Figura 34 - Tratamento Especial

Figura 35. Processo de Carga Dimensão

Aplicações em ETL . 39
Processo de carga das tabelas fatos

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:

1. Na query de carga deverão estar listadas:

I. Todas as SRK`S das Dimensões que serão chave da fato;

II. Todos os Indicadores;
III. Todas as Dimensões Degeneradas que houver.

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.

Figura 36. Processo Carga Fato I

Modelo de processo de carga utilizando o recurso de Lookup da ferramenta.

Figura 37. Processo Carga Fato II

Modelo de processo de carga sem utilizar Lookup.

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

DATA SOURCE COM

A QUERY
DEFINIÇÃO DO REJEIÇÃO
MÉTODO DE CARGA TODO
Figura 38 - Controle Rejeição I

Ao desenvolver um processo de carga de Fato, derivamos esse processo para

gerar duas tabelas, uma que será a FATO e outra que será a tabela de Rejeição.

Tratamento de erro

PROCESSO E TRATAMENTO

TABELA DE REJEIÇÃO

Características:

1. Nessa tabela são colocadas as colunas que possuem informações

importantes para identificar o registro rejeitado;

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.

TABELA DE REJEIÇÃO HISTÓRICA

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

PRIMAK, Fábio Vinicius. Decisões com BI. Editora Ciência Moderna.

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