Técnicas e Ferramentas ETL

Prévia do material em texto

Brasília-DF. 
Técnicas e FerramenTas eTL
Elaboração
Hugo Cardoso
Bruno Campos
Produção
Equipe Técnica de Avaliação, Revisão Linguística e Editoração
Sumário
APrESEntAção .................................................................................................................................. 5
orgAnizAção do CAdErno dE EStudoS E PESquiSA ..................................................................... 6
introdução ..................................................................................................................................... 8
unidAdE i
CICLO DE VIDA DE UM ETL ................................................................................................................. 11
CAPítulo 1
PrOCEssOs EM UM PrOjETO DE ETL ..................................................................................... 12
CAPítulo 2
PAssOs DE UM ETL ................................................................................................................ 19
unidAdE ii
EXTrAÇÃO DE DADOs ....................................................................................................................... 21
CAPítulo 1
EsTrUTUrA DE DADOs ........................................................................................................... 21
CAPítulo 2
TéCnICAs DE EXTrAÇÃO ...................................................................................................... 27
unidAdE iii
TrAnsFOrMAÇÃO E CArGA DE DADOs ............................................................................................ 38
CAPítulo 1
TéCnICAs DE LIMPEzA E COnFOrMIDADE DE DADOs............................................................ 38
CAPítulo 2
TéCnICAs DE CArGA ........................................................................................................... 47
unidAdE iV
FErrAMEnTAs ETL .............................................................................................................................. 62
CAPítulo 1
InFOrMATICA Power Center.............................................................................................. 62
CAPítulo 2
MiCrosoft sQL server integration serviCes – ssIs ......................................................... 66
CAPítulo 3
Pentaho Data integration – PDI ........................................................................................ 70
CAPítulo 4
COMPArAÇÃO EnTrE As FErrAMEnTAs ............................................................................... 75
PArA (não) FinAlizAr ...................................................................................................................... 76
rEFErênCiAS .................................................................................................................................... 78
5
Apresentação
Caro aluno
A proposta editorial deste Caderno de Estudos e Pesquisa reúne elementos que se entendem 
necessários para o desenvolvimento do estudo com segurança e qualidade. Caracteriza-se pela 
atualidade, dinâmica e pertinência de seu conteúdo, bem como pela interatividade e modernidade 
de sua estrutura formal, adequadas à metodologia da Educação a Distância – EaD.
Pretende-se, com este material, levá-lo à reflexão e à compreensão da pluralidade dos conhecimentos 
a serem oferecidos, possibilitando-lhe ampliar conceitos específicos da área e atuar de forma 
competente e conscienciosa, como convém ao profissional que busca a formação continuada para 
vencer os desafios que a evolução científico-tecnológica impõe ao mundo contemporâneo.
Elaborou-se a presente publicação com a intenção de torná-la subsídio valioso, de modo a facilitar 
sua caminhada na trajetória a ser percorrida tanto na vida pessoal quanto na profissional. Utilize-a 
como instrumento para seu sucesso na carreira.
Conselho Editorial
6
organização do Caderno 
de Estudos e Pesquisa
Para facilitar seu estudo, os conteúdos são organizados em unidades, subdivididas em capítulos, de 
forma didática, objetiva e coerente. Eles serão abordados por meio de textos básicos, com questões 
para reflexão, entre outros recursos editoriais que visam a tornar sua leitura mais agradável. Ao 
final, serão indicadas, também, fontes de consulta, para aprofundar os estudos com leituras e 
pesquisas complementares.
A seguir, uma breve descrição dos ícones utilizados na organização dos Cadernos de Estudos 
e Pesquisa.
Provocação
Textos que buscam instigar o aluno a refletir sobre determinado assunto antes 
mesmo de iniciar sua leitura ou após algum trecho pertinente para o autor 
conteudista.
Para refletir
Questões inseridas no decorrer do estudo a fim de que o aluno faça uma pausa e reflita 
sobre o conteúdo estudado ou temas que o ajudem em seu raciocínio. É importante 
que ele verifique seus conhecimentos, suas experiências e seus sentimentos. As 
reflexões são o ponto de partida para a construção de suas conclusões.
Sugestão de estudo complementar
Sugestões de leituras adicionais, filmes e sites para aprofundamento do estudo, 
discussões em fóruns ou encontros presenciais quando for o caso.
Praticando
Sugestão de atividades, no decorrer das leituras, com o objetivo didático de fortalecer 
o processo de aprendizagem do aluno.
Atenção
Chamadas para alertar detalhes/tópicos importantes que contribuam para a 
síntese/conclusão do assunto abordado.
7
Saiba mais
Informações complementares para elucidar a construção das sínteses/conclusões 
sobre o assunto abordado.
Sintetizando
Trecho que busca resumir informações relevantes do conteúdo, facilitando o 
entendimento pelo aluno sobre trechos mais complexos.
Exercício de fixação
Atividades que buscam reforçar a assimilação e fixação dos períodos que o autor/
conteudista achar mais relevante em relação a aprendizagem de seu módulo (não 
há registro de menção).
Avaliação Final
Questionário com 10 questões objetivas, baseadas nos objetivos do curso, 
que visam verificar a aprendizagem do curso (há registro de menção). É a única 
atividade do curso que vale nota, ou seja, é a atividade que o aluno fará para saber 
se pode ou não receber a certificação.
Para (não) finalizar
Texto integrador, ao final do módulo, que motiva o aluno a continuar a aprendizagem 
ou estimula ponderações complementares sobre o módulo estudado.
8
introdução
O processo que engloba Extração, Transformação e Carga (Extract, Transform and Load) é a base 
de um Data Warehouse. Um sistema de ETL (Extract Transform Load), devidamente projetado, 
extrai dados dos sistemas origens, reforça a qualidade dos dados e sua consistência, padroniza 
os dados de modo que as origens separadas podem ser utilizadas em conjunto, e, finalmente, 
proporciona aos dados em um formato pronto para que os desenvolvedores de aplicação (possam 
construir aplicativos de apoio) e usuários finais podem tomar decisões. Assim, este material está 
organizado em torno destas quatro etapas.
Embora a construção de um processo de ETL seja uma atividade que não é muito visível para 
os usuários finais, consome facilmente 70 % dos recursos necessários para a implementação e 
manutenção de um Data Warehouse.
O processo de ETL agrega um valor significativo aos dados. É muito mais do que um garimpo para 
obter dados de sistemas origem para o Data Warehouse.
Suas principais características são:
 » remover erros e corrigir falta de dados na origem;
 » fornecer medições para analisar a confiabilidade dos dados;
 » capturar o fluxo dos dados dos sistemas transacionais;
 » padronizar os dados de múltiplas origens para serem usados em conjunto;
 » estruturar os dados para ser usado em ferramentas de consultas utilizadas pelo 
usuário final. 
ETL é um assunto simples e complicado ao mesmo tempo. A maioria o entende como extrair 
informações da origem e carregar em um DW (Data Warehouse). Mas não é só isso, a maioria dos 
profissionais está cada vez mais valorizando a necessidade de limpar e padronizar os dados ao longodo fluxo de carga. E é evidente que o próximo passo no projeto de rotinas de ETL é quebrar em 
milhares e sub-rotinas, independente de como seja o seu sistema origem, suas regras de negócio e 
seus softwares e aplicativo de geração de relatório. 
objetivos
Com esse material, você será capaz de ampliar seus conhecimentos a respeito dos seguintes temas.
 » Arquitetura de ETL.
 » Decompor o problema em partes que são mais fáceis de gerenciar.
9
 » Aplicar técnicas reutilizáveis de desenvolvimento.
 » Analisar os detalhes com outra perspectiva.
 » Desenvolver um julgamento para evitar retrabalho ou a omissão de recursos 
importantes.
11
unidAdE iCiClo dE VidA dE 
uM Etl
Esta unidade apresenta o objetivo de oferecer o embasamento dos principais conceitos necessários 
para se desenvolver um projeto de ETL tais como planejamento, arquitetura e projeto. 
O principal desafio é construir um projeto de ETL com o melhor custo-benefício, 
confiável, escalável, complacente, visível, seguro e gerenciável para disponibilizar 
dados em um Data Warehouse e fazê-lo disponível para consulta ao usuário final. 
(KIMBALL; RALPH, 2012)
No mercado, alguns profissionais entendem as siglas “E”, “T”, “L” da seguinte forma.
 » “E”: Extrai dados de algum lugar
 » “T”: Faz alguma coisa
 » “L”: Carrega para uma tabela de destino
Parece ser apenas a movimentação de dados de um local para outro, porém a extração pode 
transformar-se, rapidamente, em uma grande e complexa tarefa.
E esses passos são dissolvidos conforme:
 » as origens;
 » as particularidades dos dados;
 » a habilidade da equipe;
 » as ferramentas de consulta e de relatório.
Cuidado!!!
 » Justifique e documente sua “criatividade” nesse processo.
 » Essa abordagem leva ao caos de tabelas, módulos, processos, Scripts, 
Triggers, alertas e agendamento de Jobs.
 » Projeto incremental sem controle geralmente falha.
12
UNIDADE I │ CICLO DE VIDA DE UM ETL
À primeira vista, quando os dados são movidos do sistema origem para o ambiente 
de Data Warehouse, parece que nada além de simples extrações de dados de um 
local para o outro está ocorrendo. Em virtude dessa enganosa simplicidade, muitas 
empresas começaram a construir seu Data Warehouse erroneamente. 
(INMON; BILL, s.d.)
CAPítulo 1
Processos em um projeto de Etl
As etapas de um projeto de ETL são formadas pelas etapas ilustradas na Figura 1 e detalhadas a 
seguir. Essas etapas são usadas para orientá-lo a fim de que você possa tomar as melhores decisões 
arquiteturais no início de um projeto de ETL.
Figura 1. Etapas de um Projeto ETL
Fonte: Kimball; ralph (2004).
levantamento dos tipos de requisitos
Viabilidade do de um projeto de ETL só se torna concreta com todos os requisitos levantados.
 » Necessidades do Negócio - São os requisitos de informação dos usuários finais 
do Data Warehouse. Usamos o termo necessidades de negócio para estreitar o 
conteúdo das informações que os usuários finais precisam para tomar decisões. 
Mas, esse requisito se destina a identificar o extenso conjunto de fontes de 
informação que a equipe de ETL deverá introduzir no Data Warehouse. Observe 
que as necessidades de negócios estão ligadas diretamente à escolha das fontes de 
dados e que o entendimento e constante análise das necessidades do negócio é uma 
atividade central da equipe de ETL.
 » O resultado deste processo é um conjunto de expectativas que os usuários 
adquirem sobre quais dados irão gerar informações para eles. Em muitos casos, 
as entrevistas com os usuários finais e as investigações de possíveis fontes não 
revelam totalmente as complexidades e as limitações de dados. E a equipe de ETL, 
13
CICLO DE VIDA DE UM ETL │ UNIDADE I
muitas vezes, faz descobertas significativas que podem afetar as necessidades 
negócio do usuário final, podendo interferir na expectativa original, descobrindo 
recursos adicionais nas fontes de dados que expandem a capacidade de tomada de 
decisões dos usuários finais.
 » Requisitos de Padrões – São cópias arquivadas de fontes de dados, ciclo de 
vida das transações e seus históricos de mudanças, algoritmos bem-documentados, 
provas de segurança das cópias dos dados pelo tempo.
 » Data Profiling - É uma forma sistemática de examinar qualidade, escopo e 
contexto de uma fonte de dados (exemplo de ferramenta na Figura 2). O uso dessa 
prática pode determinar a complexidade de um sistema de ETL e por consequência 
a sua viabilidade de construção. Pois, quando os dados estão “limpos”, requer 
menos transformação e menor intervenção humana, mas quando estão “sujos”, 
requer eliminação de alguns campos, marcação de falta de dados e criação de 
chaves substitutas (artificiais), substituição automática de valores corrompidos 
(algoritmos inteligentes) e até intervenção humana em nível de registro.
Data profiling emprega métodos analíticos para olhar para os dados com 
a finalidade de desenvolver um conhecimento aprofundado do conteúdo, 
estrutura e qualidade dos dados. Uma boa ferramenta pode processar uma 
grande massa de dados e a habilidade do analista, pode descobrir todos os 
tipos de questões que precisam ser abordadas. 
(OLSON; JACK, s.d.)
Figura 2. Microsoft sQL server 2012 Data Profiling viewer
Fonte: <http://ssis-ssdt.blogspot.com.br/>
14
UNIDADE I │ CICLO DE VIDA DE UM ETL
 » Requisitos de Segurança – Não é recomendada a abordagem de controle de 
informações por usuário diretamente nas estruturas físicas de dados (grants 
diretamente nas tabelas), recomendando-se o uso da abordagem de controle de 
informações baseadas em regras na interface de usuário final (mapas de acessos 
oferecidos pelas ferramentas de OLAP - On-line Analytical Processing). Em relação 
à equipe de ETL, são consideradas boas práticas de projeto criar três ambientes 
distintos: desenvolvimento, homologação e produção, respectivamente. E a 
segurança deve ser estendida aos backups das fontes de dados. Em síntese, existem 
políticas de segurança apropriadas para cada papel de recurso em uma plataforma 
de BI.
 » Integração de Dados – Nem todos os sistemas transacionais de uma companhia 
possuem integração de informações e conceitos, mesmo os que possuem seus 
processos implantados em soluções de sistemas ERP (Enterprise Resource 
Planning) em todas as suas áreas de negócio sempre uma área irá demandar um 
sistema apartado para atender suas necessidades, pois o ERP não atende como um 
todo devido à falta de flexibilidade. Para isso, Kimball criou o conceito de fatos e de 
dimensões padronizado, que será abordado nos Capítulos a seguir.
 » Latência dos Dados – Define a rapidez em que os dados devem ser entregues 
aos usuários finais, afetando, e muito, a definição de arquitetura e influenciando 
a implementação de um sistema de ETL. De certa forma, fluxos de dados 
tradicionais podem ser melhorados atualmente com algoritmos de processamento 
inteligentes, processamento paralelo e com investimento em hardware. Algumas 
vezes, se a latência dos dados é urgente em nível de tempo real, a arquitetura de 
ETL tem que ser convertida de Batch (em pacotes grandes por maior espaço de 
tempo) para Streaming (pacotes menores por menor espaço de tempo). Assim, 
essa troca não é gradual e evolutiva, pois é uma grande mudança de paradigma 
em que quase todas as etapas do pipeline de entrega de dados devem ser 
retrabalhadas. 
 » Arquivamento e Linhagem de Dados – Todos os sistemas de BI (Business 
Intelligence) precisam de armazenamento de dados antigos, seja para comparações 
com dados atuais ou para reprocessá-los em caso de perda. Recomenda-se sempre 
manter os dados antigos arquivados, de forma que seja mais fácil recarregá-los 
do que tentar reprocessá-los através do ETL. E, cada grupo de dados arquivado 
deve conter seus devidos metadados, descrevendo sua origem, quais dados foram 
processados e quais foram os passos utilizados (muitas vezes necessário pelos 
requisitos de conformidade).
 » Interface para os Usuários Finais – Equipe de ETL deve trabalhar em 
conjuntocom a equipe de modelagem e a equipe de aplicação, com o foco em deixar 
as aplicações para o usuário final mais rápidas e simples (mapear exatamente o que 
os usuários finais necessitam).
15
CICLO DE VIDA DE UM ETL │ UNIDADE I
Não é indicado que a aplicação tenha características muito complexas, pois as 
consultas e as navegações ficam extremamente lentas!!!
 » Habilidades Disponíveis – É recomendável que se tenha dentro da equipe, 
profissionais com habilidades avançadas na ferramenta de ETL ou na plataforma 
de desenvolvimento utilizada. 
Isso leva a uma grande questão nos projetos de ETL: codificar o sistema de 
ETL com alguma plataforma de desenvolvimento conhecida ou obter uma 
ferramenta de ETL?
 » Licenças de Legados - Em muitos casos, em um projeto de ETL, a ferramenta 
escolhida para implementação é uma que já se encontra utilizada pela organização 
(que já possui licenças e convivência). Mas, algumas vezes, manter a mesma 
ferramenta pode ser um erro. As ferramentas de ETL evoluem progressivamente 
e certas características podem influenciar os projetos de ETL quanto ao tempo de 
implementação, execução etc.
definição da arquitetura
Nesta etapa, deve-se tomar grandes decisões sobre o modo em que se construirá o sistema de ETL.
 » Utilizar ou não uma ferramenta de ETL – Muitos custos são necessários 
no início de um projeto (pelo menos um servidor de BD [Banco de Dados], um 
servidor de BI, licenças de SGBDs (Sistema de Gerenciamento de Banco de Dados), 
consultores, custo de gerenciamento de rede etc.). É recomendável dar importância 
ao custo de aquisição de uma ferramenta de ETL (pois, comprá-la, certamente 
reduzirá os custos de desenvolvimento e manutenção do DW). 
Para ajudar nessa discussão, Kimball elaborou um artigo sobre o assunto:
<http://www.kimballgroup.com/2008/04/06/should-you-use-an-etl-tool>
A empresa Gartner disponibiliza anualmente estudos sobre diversas tecnologias de 
mercado. E entre eles, há um sobre ferramentas de integração, como exemplo, o 
resultado mais recente ilustrado na figura a seguir.
16
UNIDADE I │ CICLO DE VIDA DE UM ETL
Figura 3. Avaliação das Ferramentas ETL
Fonte: Gartner (10/2012).
 » Escolher tipo de processamento do fluxo de dados – A arquitetura padrão 
de um sistema de ETL é baseada em um batch periódico que extrai dados da origem, 
em que flui pelo sistema e resulta em outro batch que atualiza as informações nas 
tabelas em que o usuário final utiliza. Mas quando uma carga em um DW de tempo 
real se torna necessária em um ambiente informacional, a abordagem por batch não 
se aplica. A alternativa para essa necessidade seria o fluxo de dados por streaming, 
onde o dado no nível de registro flui continuamente do sistema origem para as 
tabelas e telas consumidas pelos usuários. A mudança da abordagem Batch para 
Streaming é uma mudança de paradigma, pois apesar de continuar suportando 
os passos fundamentais de um fluxo de dados (extração, limpeza, conformidade 
e carga), cada um desses passos tem de ser adaptado para o processamento em 
tempo real.
 » Dependência de tarefa horizontal X vertical
 › Um fluxo de tarefa horizontal permite que cada tabela de destino possa ser 
carregada de forma independente. Como exemplo, se há uma tabela de pedidos 
17
CICLO DE VIDA DE UM ETL │ UNIDADE I
e outra de envios, elas serão carregadas de forma independente, e cada uma ou 
as duas podem ser liberadas em tempo previsto ou com atraso. Isso significa que 
os passos de extração, limpeza, conformidade e carga não estão sincronizados 
entre esses dois Jobs.
 › Um fluxo de tarefa verticalmente orientado sincroniza dois ou mais fluxos de 
Jobs separados de modo que, acima de tudo, as cargas das tabelas finais ocorrem 
simultaneamente. Normalmente, as etapas anteriores são sincronizadas, 
especialmente se dimensões em conformidade como cliente ou fornecedor, 
são usadas por mais de um sistema. Assim, todos os Jobs chegam à etapa de 
conformidade e na de carga ou nenhum deles chegarão.
 » Agendamento de tarefas – Uma decisão arquitetural importante de como 
controlar todo o seu sistema de ETL com uma tecnologia de escalonamento 
automatizada. Em um extremo, todos os Jobs serão inicializados digitando-se uma 
linha de comando ou clicando-se em um ícone. E outro extremo, uma ferramenta 
de escalonamento gerencia a execução de todos os Jobs, entende-se quando um 
Job executa com sucesso, espera-se o status de vários sistemas para ser satisfeito 
e conduz a comunicação com supervisores humanos caso haja algum alerta de 
emergência e, finalmente, gera-se um relatório de status.
 » Tratamento de exceções – Não deverá ser uma série randômica de pequenos 
alertas Ad hoc e comentários deixados em arquivos, mas, sim, devem estar em um 
sistema abrangente, tal como mecanismos uniformes para relatar todas as instâncias 
de exceções do processo de ETL em um banco de dados separado com o nome do 
processo, o tempo da exceção, com diagnóstico de severidade, a ação tomada e o 
último status de resolução da exceção. Assim, todo Job deve ser projetado para 
relatar esses registros de exceção gravando em um repositório de dados.
 » Gestão de qualidade – Similarmente, você deve decidir em uma resposta em 
comum para as questões de qualidade que surgem no processamento dos dados. 
Além de provocar um relatório com registros de exceções, todos os problemas de 
qualidade tem que ser gerados um registro de auditoria anexado nos dados dos 
fatos e dimensões. Dados corrompidos ou suspeitos devem ser manipulados com 
um pequeno número de respostas uniformes, tal como preencher dados textuais 
nulos com uma marcação ou fornecer o mínimo de valores numéricos tendenciosos 
que foram corrompidos antes de ser entregue no DW.
 » Recuperação e reinicialização de Jobs – Inicialmente, você precisa construir 
seu sistema de ETL com uma estratégia de recuperação de carga por um termino 
anormal e reiniciar o processo. Jobs de ETL devem ser reentrantes, senão seria 
inacessível realizar atualizações múltiplas de erro. Por exemplo, um Job que subtrai 
uma marca específica, resultando em uma categoria de produto global que não é 
permitida rodar duas vezes. Esse tipo de pensamento necessita reconstruir cada 
18
UNIDADE I │ CICLO DE VIDA DE UM ETL
Job de ETL, pois mais cedo ou mais tarde, a execução desses Jobs terminar-se-ão 
abruptamente ou perder-se-ão mais de uma vez. Em algum lugar, de alguma forma, 
você deve impedir que isso de acontecer.
 » Metadados – Metadados das tabelas de SGBD e das ferramentas de desenho de 
modelagem são facilmente de serem capturados, mas provavelmente compõem 
apenas 25% do metadados que necessários para entender e controlar o sistema. 
Outros 25% são gerados pela etapa de limpeza do ETL. Mas, os maiores desafios 
dos metadados para uma equipe de ETL é como e onde armazenar a informação 
de fluxo de dados. Uma vantagem importante das ferramentas de ETL é que elas 
mantêm os metadados dos fluxos de dados automaticamente. Caso se codifique o 
ETL na mão, é necessário desenvolver seu próprio repositório de metadados.
 » Segurança – Em um ambiente de ETL é menos granular do que o ambiente do 
usuário final. Porém, uma abordagem sistemática para demandas de segurança 
garantem a cobertura das tabelas e cada backup fisicamente e administrativamente 
em um ambiente de ETL. Os datasets mais delicados e importantes devem ser 
orquestrados com relatórios operacionais impressos monitorando cada acesso e cada 
comando realizado por todos os administradores desse ambiente. O log impresso 
deverá ser produzido por uma impressora dedicada fechada em uma sala, que não 
pode ser aberta por nenhuma equipe normal de TI (Tecnologia da Informação). 
O arquivamento desses datasets dever-se-á ser armazenado com checksum para 
garantir que eles não foram alterados.
implementação
Como o foco principal desse material é a implementação de rotinas para cada tabela de fatos e de 
dimensões em que foi ensinado na disciplina de modelagem de dados.Essa etapa será detalhada na 
próxima Unidade, bem como o Teste e a Entrega.
19
CAPítulo 2
Passos de um Etl
descrição de fluxo de dados
Há quatro passos intermediários (ou etapas) presentes na maioria dos DWs, conforme a Figura 
4, a seguir. Ao longo deste material, será admitido que todo processo de ETL irá suportar o DW 
estruturado com esses passos e que o dado é escrito no disco em paralelo com a transferência para 
a próxima etapa.
Figura 4. Fluxo de Dados
Fonte: Kimball; ralph (2004).
Extração
Os dados crus oriundos dos sistemas origens são, geralmente, escritos diretamente no disco, 
com o mínimo de estruturação. Dados de sistemas origens estruturados (como banco de dados 
hierárquicos IMS (Information Management System) ou XML (Extensible Markup Language) 
datasets), geralmente, são escritos em um flat file ou em tabelas relacionais nessa etapa. Isso permite 
que a extração original seja simples e rápida quando possível e permite grande flexibilidade para 
reiniciar a extração se houver uma interrupção. Inicialmente, capturam-se os dados que podem ser 
lidos várias vezes quanto necessários para suportar as etapas sucessoras. Em alguns casos, os dados 
capturados são removidos após a conclusão da etapa de limpeza, e, em outros casos, os dados são 
mantidos em backup de arquivo em longo prazo. A captura inicial dos dados pode ser armazenada 
em pelo menos em um ciclo de modo a que as diferenças entre as extrações sucessivas podem ser 
computadas. Foram guardadas as transformações de conteúdo severas para a etapa de limpeza e 
conformidade, mas o melhor lugar para resolver certos problemas de formatos dos dados legados 
é nessa etapa. Os problemas de formatações incluem resolver grupos repetidos, redefinir colunas 
sobrecarregadas e também realizar conversões de baixo nível como converter bit em caractere, 
EBCDIC (Extended Binary Coded Decimal Interchange Code) para ASCII (American Standard 
Code for Information Interchange) e decimal para inteiro.
20
UNIDADE I │ CICLO DE VIDA DE UM ETL
limpeza
Na maioria dos casos, o nível aceitável de qualidade dos dados para os sistemas origens é diferente 
dos requisitos de qualidade de um DW. O processamento de Data Quality pode envolver muitos 
passos discretos, incluindo validação de valores (o CEP [Código de Endereçamento Postal] está 
presente e está no intervalo correto?), assegurar consistência sobre os valores (o CEP é daquela 
cidade?), remover duplicados (o mesmo consumidor aparece duas vezes com poucos atributos 
diferentes) e verificar se as regras e procedimentos complexos de negócios foram aplicados (os 
clientes platinum tiveram o status de extensão de credito associada?). A transformação de dados 
pode ainda envolver intervenção humana e exercitar o julgamento sobre alguma regra. Os resultados 
dessa etapa são frequentemente armazenados de forma quase permanente, visto que os requisitos 
de transformações são irreversíveis normalmente possuem diversas regras.
Além disso, um pergunta interessante que emerge nesses ambientes é se o dado limpo pode ser 
realimentado para os sistemas origens de forma a reduzir a necessidade de processar o mesmo 
problema no dado várias vezes em cada extração. Mesmo que os dados não possam ser realimentados 
fisicamente para o sistema origem, as exceções devem ser reportadas para construir um caso para 
melhoria no sistema origem. Essas questões de dados são também importantes para a comunidade 
de usuários finais de BI.
Conformidade
A Conformidade de Dados é necessária quando dois ou mais sistemas origens são integrados no 
DW. Origens de dados separadas não podem ser consultadas juntas ao menos que alguns ou todos 
os rótulos textuais dessas origens fora feito identicamente e ao menos medidas numericamente 
similares tenham sido matematicamente fracionadas para que diferentes taxas entre essas medidas 
façam sentido. A Conformidade de Dados é um passo significativo considerado mais do que uma 
simples limpeza de dados. Apresenta como premissa, um acordo global da organização para utilizar 
domínios e medidas padronizadas.
Carga
A questão da camada back room é transformar os dados prontos para consulta. O último e crucial 
passo é fisicamente estruturar os dados em uma séria de esquemas simples e simétricos conhecidos 
como modelos dimensionais ou modelos estrela. Esses modelos reduzem significativamente 
o tempo de uma query e simplifica o desenvolvimento de uma aplicação. Modelos dimensionais 
são requisitos de muitas ferramentas de consultas e esses modelos são a base da construção de 
cubos OLAP. 
Para obter mais informações de tratamentos sobre modelagem dimensional, tenha 
como referência o livro Data Warehouse Toolkit, Second Edition (WILEY, 2002).
21
unidAdE iiEXtrAção dE 
dAdoS
Esta Unidade se destina ao auxílio na decisão de utilizar ou não uma área de Staging, e sua 
estruturação e planejamento. E, também, nas possíveis técnicas de extrações de dados de diversos 
sistemas origens para prover subsídio às etapas de transformação e de conformação de dados da 
área de Back Room.
A estrutura de dados primária para um sistema de banco de dados será revisada, iniciando-se 
a análise em camada de Staging, para as necessidades transiente e permanente. Deve-se ser 
especialmente aplicado em apoiar os requisitos financeiros e legais. Nesse caso, não ocorre apenas 
o processo de armazenamento dos dados, mas também há a obrigatoriedade de documentar as 
regras pelas quais o dado foi criado. Se isso não for suficiente, dever-se-á provar que o dado não 
foi adulterado.
O passo de extração do ETL será destacado para estudo e será necessário o aprofundamento desse 
passo, a fim de observar-se se aquela extração poderá ser relevante. Há a opção de realiza-la ou 
não com a ferramenta de Data-Profiling, que irá revelar se os dados estão com qualidade suficiente 
para atender o objetivo do negócio. O próximo grande passo será criar um mapa lógico de dados que 
conecta os dados do sistema origem aos dados finais documentando suas regras de transformações. 
Obrigando-se a manter esse documento conforme ocorrência de uma nova alteração, tornando a 
descrição mais valiosa do seu sistema de ETL.
CAPítulo 1
Estrutura de dados
A área de Back Room de um DW tem sido chamada frequentemente de área de Stage. Staging, nesse 
contexto, significa escrita em disco e, no mínimo, é recomendado dado staging nos quatros passos 
do fluxo de dados. A equipe de ETL necessitará de diferentes estruturas de dados para atender a 
todas as necessidades legítimas de staging. Assim, o objetivo deste Capítulo é descrever todos os 
tipos de estruturas de dados que, provavelmente, se possa precisar.
22
UNIDADE II │ EXTRAÇÃO DE DADOS
To stage or not to stage?
A decisão de armazenar os dados em uma área de stage física versus o processamento em memória 
é a escolha fundamental de um arquiteto do ETL. A habilidade desenvolver um processo de ETL 
eficiente depende em até certo ponto na capacidade de determinar o equilíbrio entre I/O (Input/
Output) físico e processamento em memória.
O desafio de alcançar esse delicado equilíbrio entre físico e memória em um processo de ETL é uma 
tarefa que deve ser avaliada com o objetivo de criar um processo otimizado. 
Os questionamentos de se criar ou não uma área de stage dependem de dois objetos conflitantes:
 » obter os dados da fonte de origem para o destino final o mais rápido possível;
 » ter a capacidade de recuperar-se de falha sem reiniciar desde o início do processo.
A decisão de estagiar dados varia de acordo com o seu ambiente e requisitos de negócio. Se você 
pretende fazer todo o processamento de dados em memória, tenha em mente que cada Data 
Warehouse, independentemente de sua arquitetura ou ambiente, inclui uma área de stage de 
alguma forma ou de outra.
Considere as seguintes razões para estagiar os dados antes de serem carregados para o Data 
Warehouse:
 » Recuperabilidade – Na maioria dos ambientes corporativos, é uma boa 
prática estagiar os dadosassim que eles forem extraídos do sistema origens e, 
em seguida, novamente, imediatamente após cada um dos passos importantes 
de transformação, assumindo que, para um quadro especial, os passos de 
transformação são significativos. Estas tabelas de staging (em um sistema de 
banco de dados ou arquivo) servem como pontos de recuperação. Ao implementar 
essas tabelas, o processo não terá que invadir o sistema fonte novamente se as 
transformações falharem. Além disso, o processo não terá de transformar os dados, 
caso o processo de carregamento falha. Quando estagiar dados é puramente para 
fins de recuperação, os dados devem ser armazenados em um arquivo sequencial no 
sistema de arquivos, em vez de em um banco de dados. Staging para recuperação 
é especialmente importante quando se extrai a partir de sistemas operacionais que 
substituem seus próprios dados.
 » Backup – Muitas vezes, o enorme volume de dados impede que o Data Warehouse 
de ser backup confiável no patamar de banco de dados. Já ocorreram catástrofes 
documentais que poderiam ter sido evitados se apenas os arquivos de carga fossem 
salvos, comprimidos e arquivados. Se as tabelas de teste estão no sistema de 
arquivos, elas podem facilmente ser compactadas em um espaço muito reduzido e 
guardadas em sua rede. Então, se você precisar recarregar o Data Warehouse será 
suficiente simplesmente descompactar os arquivos de carga e recarregá-los.
23
 EXTRAÇÃO DE DADOS │ UNIDADE II
 » Auditoria – Muitas vezes, a linhagem de dados entre a fonte e de destino é perdida 
no código de ETL. Quando chega a hora de auditar o processo de ETL, tendo 
estagiados os dados, fazer auditoria entre as diferentes partes dos processos de ETL 
é muito mais simples porque os auditores (ou programadores) podem simplesmente 
comparar o arquivo de entrada original com as regras de transformação lógicas 
contra o arquivo de saída. Essa staging de dados é especialmente útil quando o 
sistema de origem substitui sua história. Quando as perguntas sobre a integridade 
da informação nos dias de superfície de armazenamento de dados ou mesmo 
semanas após um evento ocorreu, revelando a encenado extrair dados a partir do 
período de tempo em questão pode restaurar a confiabilidade do Data Warehouse. 
Uma vez que se decidiu estagiar pelo menos alguns dos dados, deve-se resolver 
sobre a arquitetura apropriada de sua área de stage. Como é o caso com qualquer 
outro banco de dados, se a área de stage de dados não é planejada cuidadosamente, 
ele irá falhar. Projetar área de stage de dados corretamente é mais importante do 
que projetar as aplicações habituais por causa do grande volume de área de stage de 
dados (às vezes, fica maior do que o Data Warehouse em si). 
Projetando a área de stage
A staging area de dados armazena em seu caminho para a área de apresentação final do Data 
Warehouse. Às vezes, os dados na área de stage são preservados para apoiar funcionalidades que 
requerem histórico, enquanto outros dados são eliminados com cada processo. Quando o histórico é 
mantido na área de stage, esta é, muitas vezes, referenciada como uma área de stage persistente. 
Quando os dados são removidos em cada carga, a área é considerada transitória. É perfeitamente 
válida para a área de stage de dados, ser um híbrido, composto por uma mistura de tabelas staging 
persistentes e transitórias.
Certifique-se do uso apropriado da área de stage, visto que este desempenha vários 
papéis nas operações contidas em um Data Warehouse. Há mais papéis no stage do 
que apenas construir os arquivos temporários para apoiar a execução do próximo 
Job. Um determinado arquivo temporário também pode ser usado para reiniciar o 
fluxo de Jobs se um problema grave acontecer. O arquivo pode ser uma forma de 
auditoria ou prova de que os dados tinham um conteúdo específico, quando foi 
processado.
Independentemente da persistência dos dados na área de stage, algumas regras básicas deverão 
ser seguidas quando a área de stage for projetada e implantada. As seguintes regras têm a 
mesma premissa para todos: Quem não compuser a equipe de ETL, deverá afastar-se! Deverão 
ser estabelecidas e praticadas as seguintes regras para que o projeto de Data Warehouse seja 
bem-sucedido.
 » A área de stage deve pertencer à equipe de ETL. O acesso à área de stage de 
dados, e todos os dados dele, é vedado para qualquer pessoa que não seja a equipe de 
24
UNIDADE II │ EXTRAÇÃO DE DADOS
ETL. A área de stage de dados não é projetado para a apresentação. Não há índices 
ou agregações para apoiar a consulta na área de stage. Não existem quaisquer 
acordos de nível de serviço para acesso a dados ou a consistência na área de stage. 
Todos estes requisitos de acesso de dados são tratados na área de apresentação.
 » Os usuários não são permitidos na área de stage, por qualquer motivo. 
Dados na área de stage devem ser considerados uma área de canteiro de obras. 
Permitir o acesso de pessoas não autorizadas na área pode causar problemas. 
Usuários curiosos com acesso à área de stage, podem muitas vezes, utilizar 
indevidamente os dados, e com isso, podem reduzir a percepção da integridade do 
Data Warehouse.
 » Relatórios não podem acessar os dados da área de stage. A área de stage de 
dados é um local de trabalho. As tabelas são adicionadas, removidas ou modificadas 
pela equipe de ETL sem notificar a comunidade de usuários. Este conceito não 
significa que a área é liberada com as tabelas sendo adicionadas, removidas, e 
modificada por programadores à vontade. No entanto, isso não significa que 
a área seja destina a ser uma bancada de trabalho, não é um caso de exibição. A 
área é um ambiente controlado, ou seja, as modificações nas tabelas na área de 
stage em produção devem passar pelo mesmo ciclo de vida de tabelas na camada 
de apresentação de Data Warehouse. No entanto, ao contrário das alterações das 
tabelas de produção do DW , tabelas de dados staging podem ser alterados sem 
que os usuários sejam notificados, quebrando relatórios que possam estar usando 
a tabela alterada. Assim, não permita que quaisquer relatórios sejam direcionados 
para a área de stage, mesmo quando tais apontamentos sejam temporários.
 » Apenas processos de ETL podem ser lidos e escritos na área de stage. 
Cada Data Warehouse exige conjuntos de dados que não possuem uma fonte externa 
convencional, como uma tabela de tipos de status de qualidade de dados. Quando 
o Data Warehouse requer dados que não existem em qualquer ambiente de banco 
de dados externo existente, no entanto, ele tem que vir para a área de staging de 
dados como outros dados. É importante compreender que a área de stage de dados 
não é um ambiente transacional e que não se deve permitir que os dados sejam 
inseridos manualmente. Se as tabelas manuais devem ser mantidas, um aplicativo 
deve ser desenvolvido fora da área de stage de dados, e os dados resultantes devem 
ser fornecidos para a equipe de ETL e incorporado à área de stage por meio de um 
processo de ETL.
O grupo de ETL é dono da área de stage de dados. Isso significa que o arquiteto de ETL projeta as 
tabelas dentro dela e decide se uma tabela pertence ao banco de dados ou, com base nos requisitos 
de seus respectivos processos de ETL, é mais adequado para o sistema de arquivos. 
Quando a área de stage é inicialmente configurada, o arquiteto de ETL deve fornecer à equipe 
de administradores de banco de dados (DBA) e os administradores de sistema operacional com 
uma medida geral de armazenamento de dados da área de stage para que eles possam estimar as 
25
 EXTRAÇÃO DE DADOS │ UNIDADE II
alocações de espaço e configurações de parâmetros para o banco de dados de staging, arquivo de 
sistemas e estruturas de diretório.
Figura 5. Planilha volumétrica das tabelas da área de stage
Fonte: Kimball; ralph (2004).
A Figura 5 demonstra um exemplo da planilha de volumetria de uma staging area, concentrando-se 
nas tabelas entregues no final do fluxo de dados de ETL. Um sistema de rastreamentovolumétrico 
completo teria planilhas semelhantes para cópias de dados de origem e os arquivos de staging que 
se seguiram às etapas de limpeza e conformidade.
A planilha de volumetria lista cada tabela na área de stage com as seguintes informações.
 » Nome da tabela – O nome da tabela ou do arquivo na área de stage. Há uma linha 
na planilha para cada tabela de staging.
 » Estratégia de atualização – Esse campo mostra como a tabela é mantida. Se 
for uma tabela staging persistente, ela terá dados acrescentados, atualizados e 
talvez removidos. Uma staging temporária são truncadas e recarregadas com cada 
processo.
 » Frequência de carga – Mostra com que frequência a tabela é carregada ou 
alterada pelo processo de ETL. Quase frequentemente, isso é diário, mas pode ser 
semanal, mensal ou qualquer outro intervalo de tempo. Em ambiente em tempo 
real, tabelas na área de stage podem ser atualizadas constantemente.
26
UNIDADE II │ EXTRAÇÃO DE DADOS
 » ETL Job(s) – Tabelas de staging são preenchidas ou atualizadas via Job de ETL. 
O Job de ETL é o Job ou programa que afeta a tabela stage ou arquivos. Quando 
muitos Jobs afetam uma única tabela stage, deverão ser listados todos os Jobs nesta 
seção da planilha.
 » Contagem inicial de linhas – A equipe de ETL deve estimar a quantidade de 
linha que cada tabela da área de stage deverá conter inicialmente. A contagem 
inicial é baseada inicialmente nas linhas das tabelas origens e/ou destino.
 » Tamanho médio de uma linha – Com o propósito estimar tamanho do banco 
de dados que irá armazenar os dados da área de stage, você deve fornecer ao DBA 
o comprimento médio de linha de cada tabela de staging. Em um ambiente Oracle, 
cria-se a tabela em um ambiente de desenvolvimento, executam-se estatísticas, e 
reúnem-se essas informações da tabela sys.all_tables. Por exemplo, no Oracle, o 
pacote STATS DBMS pode ser usado para preencher as colunas com estatísticas 
adequadas.
 » Crescer com – Mesmo que tabelas são atualizadas em um intervalo programado, 
elas não crescem necessariamente cada vez que são tocadas. O campo “Crecer Com” 
é baseado em regras de negócio. É necessário definir-se quando cada tabela na área 
de stage cresce. Por exemplo, uma tabela de status cresce à medida que um novo 
status é adicionado. Embora a tabela seja tocada diariamente para procurar por 
alterações, a adição de novos status é bastante rara.
 » Linhas mensais esperadas – Esta estimativa é baseada no histórico e em regras 
de negócios. A previsão de crescimento é necessária para o DBA para alocar espaço 
apropriado para a tabela. A contagem mensal de linhas é um alicerce para calcular 
quantos bytes a tabela cresce a cada mês.
 » Bytes esperados mensalmente – É uma conversão das Linhas mensais 
esperadas.
 » Tamanho inicial da tabela – É geralmente representada em bytes ou em 
megabytes. É uma conversão da contagem inicial de linhas.
 » Tamanho estimado em 6 (seis) meses - Uma estimativa de tamanho de tabela 
depois de seis meses de atividade ajuda a equipe de DBA a estimar o crescimento do 
banco de dados de ou sistema de arquivos da staging. Essa medição é normalmente 
representada em megabytes.
27
CAPítulo 2
técnicas de extração
Uma vez que seu projeto de Data Warehouse é lançado, percebe-se que a integração de todos os 
sistemas díspares em toda a empresa é o verdadeiro desafio para a obtenção do Data Warehouse 
para um estado em que ele é utilizável. Sem os dados, o Data Warehouse é inútil.
O primeiro passo da integração é extrair dados com sucesso dos sistemas de fontes primárias. Cada 
fonte de dados tem o seu conjunto específico de características que precisam ser geridas de forma a 
extrair dados de forma eficaz para o processo de ETL.
Como as empresas evoluem, eles adquirem ou herdam vários sistemas de computador para ajudar 
a empresa a gerir os seus negócios, onde a lista de sistemas pode ir e ir aumentando. Pior ainda, 
não são apenas os sistemas separados e adquiridos em épocas diferentes, mas muitas vezes eles são 
logicamente e fisicamente incompatíveis.
O processo de ETL precisa efetivamente integrar os sistemas que são diferentes.
 » Sistemas Gerenciadores de Bancos de Dados
 » Sistemas Operacionais
 » Hardware
 » Protocolos de Comunicação
Antes de iniciar a construção de seus sistemas de extração, você precisa de um mapa de dados lógico 
que documenta a relação entre os campos da fonte original e campos de destino final das tabelas que 
você irá entregar para o front-end. 
Há quinze anos, pensava-se que o Data Warehouse era imutável: a enorme biblioteca de dados 
write-once. Com o benefício de muita experiência nos anos seguintes, sabe-se agora que Data 
Warehouses precisam constantemente ser atualizados, corrigidos e alterados. 
Parte 1: mapeamento lógico de dados
A implementação física pode resultar em uma catástrofe se não for cuidadosamente arquitetado 
antes de ser implementado. Assim como com qualquer outro tipo de construção, dever-se-á realizar 
um planejamento eficiente antes de iniciar qualquer ação.
28
UNIDADE II │ EXTRAÇÃO DE DADOS
Antes de começar a desenvolver um único processo ETL, é necessário certificar-se de que há 
a documentação necessária para o processo de conformidade lógica e física com as políticas 
estabelecidas de ETL, procedimentos e padrões.
O mapa de dados lógico descreve a relação entre os pontos extremos de partida e os pontos extremos 
de destino do seu sistema de ETL.
Projetando o lógico antes físico
Introduzir-se diretamente no mapeamento de dados físicos desperdiça tempo e exclui a 
documentação. Esta seção descreve como desenvolver o processo ETL lógico e usá-lo para mapear 
sua implementação física de ETL. Os seguintes passos deverão ser realizados antes de iniciar 
qualquer desenvolvimento físico ETL.
1. Possuir um plano – O processo de ETL deve ser planejado de forma lógica 
e documentado. O mapa de dados lógico é fornecido pelo arquiteto de Data 
Warehouse e é a especificação para a equipe de ETL para criar os Jobs do ETL 
físico. Este documento, às vezes, é referido como o relatório de linhagem de dados. 
O mapa lógico de dados é a base dos metadados, que é eventualmente apresentado 
aos testadores de garantia de qualidade (Quality Assurance - QA) e, finalmente, 
para os usuários finais, para descrever exatamente o que é feito entre o sistema 
fonte final e Data Warehouse.
2. Identificar fonte de dados candidata – Começando com os objetivos de 
negócios de mais alto nível, identificar as possíveis fontes de dados dos candidatos 
que poderão apoiar as decisões necessárias para a comunidade de negócio. 
Identificar também nessas fontes elementos de dados específicos que se acredita 
serem fundamentais para os dados do usuário final. Estes elementos de dados são, 
então, as entradas para o passo de perfil de dados.
3. Analisar os sistemas fonte com uma ferramenta de perfilamento de 
dados (Data Profiling) – Dados nos sistemas fonte devem ser examinados 
para a qualidade dos dados, integridade e aptidão para o efeito. Dependendo da 
sua organização, a qualidade dos dados pode ou não cair sob a responsabilidade 
da equipe de ETL, mas este passo de perfilamento de dados deve ser realizado por 
alguém com um olho para as necessidades dos tomadores de decisões que irão 
utilizar o Data Warehouse. Os dados em cada sistema origem devem ser analisados. 
Qualquer anomalia de dados detectada deve ser documentado, e os esforços devem 
ser feitos para aplicar regras de negócio adequadas para corrigir os dados antes 
de serem carregados para o Data Warehouse. Deverá permanecer em aberto a 
possibilidade de que o projeto pare com essa etapa! Se os dados não podem apoiar 
os objetivos de negócio, este é o tempo para descobrir isso.
29
 EXTRAÇÃO DE DADOS │ UNIDADE II
4. Definir linhagem de dados e regras de negócio – Uma vez que as fontes 
de dados foram qualificadas pelo passo de perfilamento de dados e o modelo de 
dados de destino final é entendido, o arquiteto de Data Warehouse eo analista 
de negócios devem direcionar o arquiteto e os desenvolvedores de ETL por meio 
da linhagem de dados e as regras de negócio para extrair, transformar e carregar 
as áreas do Data Warehouse. Compreensão completa da linhagem de dados e 
regras de negócio não será alcançada até que a equipe de ETL tenha encontrado 
todas as realidades nos dados; no entanto, esta etapa tem como objetivo 
transferir conhecimento, tanto quanto possível para a equipe de ETL. No passo 
de perfilamento de dados deve ser criado duas subcategorias de regras de negócio 
específicas de ETL:
 › alterações necessárias aos dados durante as etapas de limpeza;
 › coerções nas dimensões e fatos para alcançar a conformidade padrão em fontes 
de dados separados.
5. Definir o modelo físico do DW – A equipe de ETL deve entender 
completamente o modelo de dados físico do Data Warehouse. Esse entendimento 
inclui conceitos de modelagem dimensional. Compreender os mapeamentos de 
forma tabela-por-tabela não é bom o suficiente. A equipe de desenvolvimento 
deve ter um entendimento completo de como as dimensões, fatos e outras 
tabelas especiais no modelo dimensional trabalhem juntos para implementar 
soluções ETL de sucesso. É importante lembrar-se de que o principal objetivo 
do sistema de ETL é entregar os dados de forma mais eficaz para as ferramentas 
do usuário final.
6. Validação de cálculos e fórmulas – Verifique com os usuários finais quaisquer 
cálculos especificados na linhagem de dados. É útil para certificar se os cálculos 
estejam corretos antes de gastar tempo de codificação dos algoritmos errados em 
seu processo de ETL.
detalhando o mapeamento lógico de dados
Antes de detalhar as diferentes fontes que você vai encontrar, precisa-se explorar o desenho atual 
do documento de mapeamento lógico de dados (Figura 6). O documento contém a definição de 
dados para os sistemas fonte do Data Warehouse de toda a empresa, o modelo dados para Data 
Warehouse-alvo e a manipulação exata dos dados necessários para transformá-lo a de seu formato 
original para seu destino final.
30
UNIDADE II │ EXTRAÇÃO DE DADOS
Figura 6. Mapeamento lógico dos dados
Fonte: Kimball; ralph (2004).
Algumas ferramentas de ETL e de Modelagem de dados (Por exemplo: ERWin, Power Designer, 
EA etc.) possuem funcionalidades para registrar o mapeamento lógico, tendo como boas práticas 
documentar tudo no mesmo repositório.
Não subestimar o tempo para entendimento dos dados das fontes – extremamente 
necessário (dados e sistemas).
Fases da análise das fontes de dados
O mapeamento lógico dos dados não pode existir até que os sistemas de fontes sejam identificados 
e analisados. A análise do sistema fonte é geralmente dividida em duas fases principais:
Fase de descoberta dos dados
Depois de entender o que o destino tem de se parecer, é preciso identificar e analisar as fontes de 
dados se atentando com os tópicos a seguir.
 » Geralmente apenas o “maior sistema” é identificado com fonte de dados (ex.: ERP, 
CRM - Customer Relationship Management).
31
 EXTRAÇÃO DE DADOS │ UNIDADE II
 » Algumas vezes, alguns sistemas escolhidos como fonte não são realmente as 
melhores origens dos dados.
 » É de responsabilidade da Equipe de ETL descobrir requisitos de dados, determinando 
exatamente quais serão as bases, tabelas e atributos que farão parte do processo de 
ETL (análises completas podem salvar muito tempo do projeto).
 » É necessário listar e documentar todos os sistemas fonte com artefatos (ex.: 
notas de entrevistas, relatórios, modelos ER – Entidade Relacionamento etc.).
 » É fundamental identificar “Quem usa esses dados na organização?” – mapeamento 
de usuários x fontes de dados.
 » É de responsabilidade da equipe de ETL sempre rastrear os possíveis sistemas fonte 
na organização.
Tracking report (monitoramento de sistemas-fonte)
Monitorar os sistemas-fonte por meio da planilha (Figura 7). Mantê-los é atividade conjunta da 
equipe de ETL com os ADs – Administradores de Dados (servirá para fases futuras do DW).
Figura 7. relatório de rastreamento dos sistemas Fonte
Fonte: Kimball; ralph (2004).
System-of-Record: Sistema de registros principal da empresa (transacional), geralmente é uma fonte 
de dados (ex.: ERP) mandatória para aquele Data Mart. Assim, é necessário lidar com o “mesmo 
dado” duplicado, movimentado, manipulado em diversos sistemas fonte, algumas vezes identificar 
bases de dados ou nome de arquivos não é trivial (depende da arquitetura dos sistemas legados). É 
recomendável verificar também se algum esforço para integração dos dados dos sistemas fonte já 
foi feito, tais como:
 » levantar informações de quais fontes foram utilizadas, o processo, regras de negócio 
envolvidas, motivo de possíveis falhas do projeto;
32
UNIDADE II │ EXTRAÇÃO DE DADOS
 » analisar os sistemas fonte: entender o seu conteúdo;
 » aquisição de modelo de ER (se for baseado em banco relacional);
 » considerar o uso de Engenharia Reversa para obter o modelo físico da base;
 » procurar por descrições de alto nível dos bancos de dados, tabelas e colunas (atributos);
 » Data Profiling Identificar as chaves primárias e as chaves naturais da fonte.
 › Identificar os tipos de dados e seus ranges.
 › Identificar os relacionamentos entre as tabelas (levar em consideração falta de 
FK físico).
 › Identificar os relacionamentos implícitos na tabela (look-up table). Ex.: Na tabela 
Pedido existe o atributo NomeProduto (mesmo existindo a chave estrangeira 
ProdutoId).
 › Identificar cardinalidade dos relacionamentos (1:1, 1:N, N:M).
 › Procurar por atributos com mesmo nome em tabelas diferentes.
Análise do conteúdo dos dados
Compreendendo o conteúdo dos dados é crucial para determinar a melhor abordagem para a 
recuperação. Normalmente, não é até que se inicie o trabalho com os dados que, ao analisa-los, irá 
perceber as anomalias que existem nela. As anomalias mais comuns que se devem incluir são as 
seguintes.
 » Valores nulos: importante identificar onde existem.
 » Se forem FK atentar para as junções: utilizar OUTER JOIN (INNER JOIN causará 
perda de dados!);
 » Sempre que possível utilizar valores padronizados para os campos nulos (descrição 
de negócio para ser nulo).
 » É importante verificar se existem dados de data/hora em colunas que não são do 
tipo DATE (ou DATETIME).
 » Muitos sistemas legados implementam as datas através de campos STRING.
 » É necessário verificar os formatos diferentes das datas: parte importante de qualquer 
DW, o tempo! (ex.: “13-JAN-11”, “13/01/2011”, “January, 13, 2011”).
 » Atentar para configurações de região (Regional Settings).
33
 EXTRAÇÃO DE DADOS │ UNIDADE II
Coleta de regras de negócio
Você pode pensar que nesta fase do processo que todas as regras de negócio devem ter sido colhidos. 
Como poderiam os modeladores de dados criarem um modelo de dados sem conhecer todas as 
regras de negócio, certo? Errado. As regras de negócio necessárias para a equipe de modelagem de 
dados são bastante diferentes daquelas exigidas pela equipe de ETL. Por exemplo, a definição da 
dimensão do estado de modelagem de dados pode ser algo como:
 » não se basear apenas nas regras mapeadas pelos ADs;
 » geralmente o nível de descrição das regras de negócio é muito mais detalhado para 
a equipe de ETL;
 » além da descrição da coluna, é necessário saber como estão os dados e que regras 
foram aplicadas durante o input;
 » regras de negócio para o ETL são mais técnicas;
 » ao descobrir anomalias nos dados é importante documentar, levantar como eles 
devem ser levados para o DW (aprovado pelo responsável).
integração de fontes heterogêneas
Mais que coletar dados e uni-los no mesmo repositório, o objetivo é sempre conformar entidades 
(dimensões) em prol do negócio da organização, unificando os seus conceitos. Com isso, garante-se 
o sucesso do projeto de DW.
Uma boa prática ao carregar dados na Staging, sempre indicar de qual(is) sistema(s) 
aquele registro está vindo!!!Extração de dados modificados
Durante a carga inicial, capturar alterações no conteúdo dos dados na fonte é importante porque é 
mais provável extrair a fonte de dados inteira ou uma porção a partir de um determinado ponto no 
tempo incrementalmente. Com isso, deve-se atentar aos seguintes itens.
 » Uma vez que a extração inicial é completa, capturar as mudanças nas fontes se torna 
prioridade.
 » Não é uma tarefa trivial - Necessário planejamento de estratégia de captura 
de mudanças incrementais por meio de pesquisa de comportamento da fonte 
(dependendo das situações específicas).
 » Nunca assumir o uso de uma coluna sem verificar seus dados!
34
UNIDADE II │ EXTRAÇÃO DE DADOS
 » “Manutenção do DW” significa manter os dados atualizados.
 » Escolher da técnica de detecção de mudança dependerá das características de 
acesso, modelagem, indexação das tabelas nos banco de dados fonte.
técnicas de detecção de dados modificados
Existem várias maneiras de capturar alterações nos dados de origem e todas elas são eficazes, 
dependendo do modo como o sistema origem foi desenhado.
 » Utilização de colunas de auditoria
 › Geralmente colunas adicionadas no “final” das tabelas (CreateDate e 
LastModified).
 › Valores podem ser inseridos/atualizados através de triggers ou sistema.
 › Necessário analisar e testar os valores dessa coluna.
 › Quando o sistema for NULL (CreateDate), melhor escolher outra técnica.
 › Importante ter cuidado quando o sistema for responsável pela atualização desse 
campo e existir a possibilidade de execução de script “por fora”: alto risco.
 › Nesse caso, estipular procedimento de comunicação dos scripts executados.
 › Lógica: comparar a última data de modificação com o que existe no Staging.
 › Caso a última data de modificação seja nula, forçar valor de referência. Ex.: select 
max (greatest( nvl( create_date, ‘01-JAN-0001’), nvl( last_mod_date, ‘01-JAN-
0001’))).
 › Nos casos em que os registros das tabelas-fato nunca sejam alterados, ignorar a 
coluna de última modificação.
 › Criar uma tabela onde existam as informações de cada extração, de cada tabela e 
a data do último registro extraído.
 » Utilização de arquivos de Log de bases
 › O Log guarda todas as transações efetuadas na base de dados.
 › Tomar cuidado com essa abordagem, pois muitas vezes a política de “purga” 
efetuada pelos DBAs pode levar à perda das informações.
35
 EXTRAÇÃO DE DADOS │ UNIDADE II
 › É recomendável utilizar as funcionalidades que algumas ferramentas de ETL 
possuem para leitura de arquivos Log (não ler o arquivo como texto diretamente).
 » Extrações “Temporais”
 › Selecionar todos os registros com CreateDate ou LastModified maior que 
SYSDATE-1.
 › Abordagem “perigosa”: pode levar a duplicação de dados, principalmente caso 
alguma falha ocorra durante o último processamento.
 › Utilizada quando o volume de dados é muito pequeno e/ou há tratamento mais 
elaborado de dados duplicados.
 » Processo de Eliminação
 › Preserva exatamente a cópia de toda a (Staging Area) carregada na última 
extração.
 › O processo compreende as tabelas fonte inteiras e realiza a comparação com a 
última carregada na base.
 › Não é a abordagem mais eficiente, mas é a mais segura/confiável.
 › Comparação entre tabelas novas e anteriores registro a registro.
 › Considerar a utilização de BULK COPY.
 » Extração Incremental e Inicial
 › Utilizar tabelas: ExtraçãoAnterior e ExtraçãoCorrente.
 › Inicialmente, carregue tudo na ExtraçãoCorrente (*).
 › Quando o processo de extração finalizar, renomear o ExtraçãoCorrente para 
ExtraçãoAnterior e limpar a ExtraçãoCorrente.
 › (*) Selecionar a ExtraçãoCorrente MINUS ExtraçãoAnterior dará todos os 
registros modificados.
 › MINUS pode ser uma operação muito demorada: considerar componentes 
existentes nas ferramentas de ETL.
36
UNIDADE II │ EXTRAÇÃO DE DADOS
dicas para extração
 » Utilizar colunas da fonte com índices
 › Avaliar com o DBA que as colunas utilizadas na cláusula WHERE possuem 
índice (caso contrário às consultas podem provocar FULL SCAN).
 » Recuperar apenas os dados necessários
 › Otimizar consultas para descartar dados desnecessários.
 » Utilizar DISTINCT moderadamente
 › Verificar qual melhor estratégia: efetuar o DISTINCT na consulta ou trazer todos 
os dados e agregá-los na AS.
 » Utilizar UNION, MINUS, INTERSECT moderadamente
 › Operações de conjunto (SET OPERATIONS) tem custo alto. Levar em 
consideração o uso de UNION ALL ao invés de UNION.
 » Forçar utilização de índice quando necessário
 › Na consulta, utilizar HINT para forçar o emprego de índice, sobretudo quando 
IN ou OR for utilizado na cláusula WHERE.
 » Evitar o uso de NOT
 › A maioria dos SGBDs acaba efetuando um FULL TABLE SCAN quando NOT ou 
<> é utilizado.
 » Evitar o uso de funções na cláusula WHERE
 › Tentar empregar palavras-chave em comparações. LIKE ‘J%’ em vez de 
SUBSTR(‘LAST_NAME’,1,1 ) = ‘J’
 › EFF_DATE BETWEEN ‘01-JAN-2002’ AND ‘31-JAN-2002’ em vez de TO_
CHAR(EFF_DATE, ‘YYY-MON’ ) = ‘2002-JAN‘.
O objetivo final das consultas de Extração é coletar todas as chaves naturais e 
medidas relevantes.
37
 EXTRAÇÃO DE DADOS │ UNIDADE II
detecção de registros excluídos e sobrescritos na 
fonte
Exclusão ou mudança de registros nos sistemas-fonte pode ser cruciais para o projeto caso não 
sejam notificadas. Deve-se considerar:
 » negociar com os “donos” dos sistemas fonte como/quando serão essas notificações;
 » checar histórico de total de registros de medidas na fonte e verificar qual a mudança 
o quanto antes;
 » adicionar um registro na tabela fato, identificando o registro excluído na fonte.
38
unidAdE iii
trAnSForMAção 
E CArgA dE 
dAdoS
Essa Unidade irá abordar os quatro grandes tópicos na transformação de dados.
 » Objetividade – reduz erro nos dados, melhora a qualidade, deixa os dados mais 
úteis e padroniza os principais atributos textuais e numéricos compartilhados por 
toda organização.
 » Técnicas de qualidade de dados – abrange desde a definição de um campo 
no nível de banco de dados (propriedade de uma coluna) até a verificação de 
consistência campo a campo (estrutura) e verificações específicas nos dados com 
relação às regras de negócio.
 » Metadados – contém técnicas em conjunto com as regras de negócio. Será descrita 
uma metodologia para construir uma forma de representar as investigações de 
qualidade dos dados.
 » Medições de qualidade de dados – Porpor-se-á um conjunto de medições para 
que a equipe de ETL possa criar um fluxo de processamento de qualidade dos dados.
E, na etapa de carga, serão apresentadas técnicas de desenvolvimento para carregar informações 
das dimensões e dos fatos de um Data Warehouse. Apresentando boas práticas de desenvolvimento 
para dimensão histórica chamada Slowly Change Dimension nos seus três tipos, respectivamente, 
e técnicas de pipelining de-para de Surrogates-Key para as fatos.
CAPítulo 1
técnicas de limpeza e conformidade 
de dados
Limpeza e Conformidade são os principais passos em que o sistema de ETL agrega mais valor. As 
outras etapas de extração e carga são evidentemente necessárias, mas elas só movem e reformatam 
os dados. Os passos de limpeza e conformidade geram um potente metadados. Observando-se em 
direção às fontes, este potente metadados é um diagnóstico do que está errado nos sistemas-fonte. 
Em última análise, os dados sujos podem ser corrigidos apenas mudando a maneira como esses 
sistemas fonte coletam os dados. Pode-se considerar Reengenharia de Processos de Negócios?
39
TRANSFORMAÇÃO E CARGA DE DADOS │ UNIDADE III
Metadados gerados nas etapas de limpeza e conformidade acompanham dados reais até a área 
de trabalho do usuário, ou pelo menos deveria possuir este desempenho. A equipe de ETL deve 
disponibilizar um potente metadados para limpeza e conformidade, e é aí que a dimensão de 
auditoria aparece. Poderá surgir o seguinte questionamento: “O que se deve focar a princípio?” 
Talvez a melhor respostaseja: “Realizar a melhor análise de perfil de dados possível”. 
definição de qualidade de dados
Serão alinhados alguns vocabulários básicos focados na acurácia. Dados precisos significam que os 
dados são assim classificados.
 » Corretos - Valores e descrições do dado descrevem fielmente (com certeza) seus 
objetos associados. Ex.: Se um cliente mora no Rio de Janeiro, então o atributo 
Cidade da tabela Cliente deve conter exatamente Rio de Janeiro.
 » Não ambíguos - Valores e descrições do dado devem ter sentido único. Ex.: 
Anápolis existe em vários estados (ambíguo), mas Anápolis-GO não.
 » Consistentes - Valores e descrições do dado devem ter termos convencionados. 
Ex.: Termos “Rio”, “Rio de Janeiro”, “R.Jan.” convencionados: “Rio de Janeiro”.
 » Completos - Assegurar que os valores individuais e descrições do dado sejam 
definidos (não nulo) para cada instância. O Número total de registros é completo, 
ou seja, nada foi perdido durante o fluxo.
Valores nulos devem ter representação de termos de negócio vinculados a eles, 
mesmo que sejam termos como “Inválido” ou “Sem descrição”.
Parte 1: projete objetivos
Esta parte discute as pressões inter-relacionadas que formam os objetivos das iniciativas de 
qualidade de dados e as prioridades, por vezes conflitantes, que a equipe de ETL deve aspirar ao 
equilíbrio. Foram propostas algumas abordagens para atingir esse equilíbrio e formular uma política 
de qualidade de dados que atenda às necessidades de importantes grupos de usuários.
O (sub) sistema de análise da qualidade dos dados (QA) deve prover informações para os perfis.
 » Gerente de DW - Responsabilidade de tomar decisões do dia-a-dia, garantindo 
que as regras de negócio estão sendo aplicadas nos dados de forma correta. O 
Sistema de QA deve prover histórico das transformações dos dados.
 » Analista de Negócio - Responsabilidade de definir a estratégia das informações 
do DW (objetivos analíticos, indicadores, fontes de informações etc.). O Sistema de 
40
UNIDADE III │ TRANSFORMAÇÃO E CARGA DE DADOS
QA deve prover as métricas sobre a adesão das informações do DW operacional com 
as políticas de negócio preestabelecidas (verificando informações sobre a qualidade 
do fluxo implementado.).
 » Líder de QA - Responsabilidade de detectar, corrigir e analisar questões de 
qualidade. Deve trabalhar em conjunto com o Analista de Negócio para definir 
políticas de limpeza dos dados. O Sistema de QA deve prover medidas que descrevam 
a frequência e severidade de todas as questões detectadas de qualidade dos dados.
 » Gerente de Dimensões - Responsabilidade de criar e publicar dimensões 
conformadas, aplicar labels nos atributos, criar e atribuir chaves surrogadas e 
controlar versões.
 » Provedor de Fatos - Responsabilidade por receber as dimensões dos gerentes 
de dimensões e aplicar as mudanças necessárias no fato, como converter as chaves 
naturais pelas chaves surrogadas (substitutas). Geralmente, está no papel de DBA 
da instância do fato.
Figura 8. Prioridade da qualidade dos dados
Fonte: Kimball; ralph (2004).
Quatro pressões ou prioridades interligadas moldam os objetivos de seu sistema de qualidade de 
dados conforme ilustrado na Figura 8. Mas, é impossível para o subsistema de limpeza resolver 
em termos absolutos, todos esses fatores simultaneamente. É necessário equilibrar, refletindo nas 
prioridades de cada situação.
41
TRANSFORMAÇÃO E CARGA DE DADOS │ UNIDADE III
 » Completude vs. Velocidade
 O ETL de qualidade dos dados não pode ser otimizado tanto a velocidade como 
completude. Em vez disso, nós aspiramos a encontrar um ponto apropriado na 
curva de relação exponencial (ver Figura 9), que atinge o equilíbrio que buscamos.
Figura 9. relação entre a Completude e Velocidade de Implementação
Fonte: Kimball; ralph (2004).
 Aplicar questões conflitantes com os usuários do DW sobre latência e qualidade 
de dados, como por exemplo, “Quando as informações se tornam obsoletas para 
você?” ou “Quão importante é obter as informações comprovadamente corretas?”.
 » Corretude vs. Transparência
 Muita transparência no sistema pode resultar num DW fraco que não enderece 
as necessidades do negócio. Por outro lado, excesso de corretude no sistema pode 
esconder deficiências operacionais e atrasar o progresso da organização (é válido 
levantar os problemas encontrados na fonte). Assim, é necessário estabelecer um 
limite entre os tipos de defeitos, catalogando-os e provendo uma forma fácil de 
verificá-los usando dimensão de Auditoria.
Figura 10. Questões Políticas de Qualidade de Dados
Fonte: Kimball; ralph (2004).
42
UNIDADE III │ TRANSFORMAÇÃO E CARGA DE DADOS
 Ilustrado na Figura 10, trata-se de um método para categorizar o conjunto de 
desafios de qualidade de dados enfrentados em projetos de Data Warehouse e 
isolar aqueles que devem ser abordados pelos subsistemas de ETL de qualidade de 
dados.
 › Categoria A - Falta de informações básicas (bugs de sistemas, falhas de 
processo etc).
 › Categoria B - Resolvidas (tecnicamente) com melhor custo/benefício na fonte.
 › Categoria C - Resolvidas (tecnicamente) com melhor custo/benefício no ETL.
 › Categoria D - Resolvidas somente pelo ETL, como por exemplo, informações 
incompletas ou incorretas em alguns sistemas fonte. É muito rara a implementação 
desse processo de ETL.
Parte 2: entregáveis da etapa de limpeza
Uma empresa séria, com o intuito melhorar a qualidade dos dados, deve basear-se em medições 
rigorosas. Isto deveria manter registros precisos dos tipos de problemas de qualidade de dados que 
se procura, quando se observa, o que se observa, e os seus resultados.
Informações devem ser capazes de responder as análises.
 » O processo de QA está evoluindo?
 » Quais sistemas fonte têm maior ocorrência de problemas?
 » Existem padrões ou tendências identificadas nos resultados de QA?
 » Existe alguma relação da qualidade dos dados com a performance da empresa?
 » Quais processos de limpeza custam mais (tempo) e o porquê?
E para responder esses questionamentos, os entregáveis são os seguintes.
 » Data Profiling (Perfilamento de Dados) - Limpeza de dados deve realmente 
começar antes da primeira etapa da construção do sistema de ETL. É extremamente 
recomendável realizar uma análise de perfilamento de dados completa das fontes 
de dados durante o planejamento inicial e a fase de projeto.
 » Uma boa análise de perfilamento de dados tem a forma de um repositório de 
metadados específico descrevendo desse modo.
 › Definições de esquemas
 › Objetos de negócio
43
TRANSFORMAÇÃO E CARGA DE DADOS │ UNIDADE III
 › Domínios
 › Fontes de dados
 › Definições de tabelas
 › Sinônimos
 › Regras de dados
 › Regras de valores
 › Questões a serem tratadas
Perfilamento de dados não é a única ferramenta de avaliação quantitativa de 
suas fontes de dados, esta saída deve influenciar fortemente o conteúdo das 
duas entregas operacionais. Apêndice B do livro de Jack Olson, Data Quality: The 
Accuracy Dimension tem uma lista abrangente de subcategorias expandindo a lista 
acima, que deve ser criado por meio de análise de perfil de dados para formar a base 
do repositório de metadados.
 » Fato de eventos de erro – Esse entregável é estruturado como modelo de 
dados dimensional do tipo star ou snowflake, conforme a Figura 11, para capturar 
eventos de limpeza. Cada erro de qualidade de dados ou problema identificado pelo 
subsistema de limpeza de dados é capturado como uma linha na tabela de fatos de 
evento de erro. Em outras palavras, o grão desta tabela fato é cada ocorrência de 
erro de cada verificação da qualidade dos dados. Lembre-se de que a verificação 
da qualidade é uma tela. Então, caso sejam executadas dez telas separadas contra 
algum conjunto de dados e a cada tela identificou dez registros defeituosos, um total 
de 100 registros seriam gravados na tabela fato de erro. 
Figura 11. Esquema da Tabela de Evento de Erros
Fonte: Kimball; ralph (2004).
44
UNIDADE III │ TRANSFORMAÇÃOE CARGA DE DADOS
 » Dimensão de Auditoria - Os eventos da tabela de erros podem acontecer sem 
ser em nível de registro (grão). Essa dimensão serve para associar indicadores de 
QA com as tabelas fato do DW, descrevendo o contexto completo de cada registro 
de uma tabela fato (toda sua linhagem) conforme o layout identificado na Figura 
12. Os registros dessa tabela são criados após a finalização da etapa de limpeza e 
conformação e deve conter uma descrição textual das mudanças que ocorreram. No 
caso da etapa ser finalizada com sucesso apenas um registro seria criado.
Figura 12. Dimensão de Auditoria
Fonte: Kimball; ralph (2004).
 » Se o processamento ocorrer com sucesso, mesmo com alguns registros sendo 
rejeitados durante os checks de QA (por exemplo, valores muito altos, fora do 
domínio) apenas 2 registros serão incluídos na dimensão. Atributos de Data Quality 
são calculados por meio de todos os eventos da tabela-fato de erro de determinado 
registro ou fonte de dados. Seus campos textuais são úteis para descrever as 
condições de erro no nível de negócio, pode conter a quantidade total de eventos de 
erro e o código de severidade máximo e é lugar ideal para registrar a linhagem dos 
dados.
45
TRANSFORMAÇÃO E CARGA DE DADOS │ UNIDADE III
 » Maior vantagem: levar essas informações para os usuários, que podem cruzá-las 
com informações do cubo (de negócio). Ex.: quantidade de vendas com valores fora 
do domínio.
Parte 3: relatórios e suas medidas
Um nível mais abaixo, a seção de relatórios define um conjunto de pontos de controle e filtros que 
você configurou em muitos lugares para medir a qualidade dos dados. Com os relatórios, estamos 
a construir uma abordagem unificada para capturar eventos de qualidade de dados e responder a 
esses eventos com ações apropriadas.
 » Fase detecção de anomalia: A anomalia de dados é um pedaço de dados que 
não se encaixam no domínio com resto dos dados que estão armazenados. Detectar 
estas anomalias requer técnicas específicas e implica análise analítica. 
Amostragem de dados - A maneira mais simples para verificar se há anomalias é contar as linhas 
em uma tabela, enquanto agrupa na coluna em questão. Esta consulta simples, cujos resultados 
são apresentados na Figura 13, mostra a distribuição dos valores e exibe dados potencialmente 
corruptos.
Exemplo:
select state, count(*)
from order_detail
group by state;
Figura 13. Exemplo de Anomalias de Dados
Fonte: Kimball; ralph (2004).
46
UNIDADE III │ TRANSFORMAÇÃO E CARGA DE DADOS
Como você pode-se observar na Figura 13, anomalias de dados são imediatamente expostas. Os 
outliers no conjunto de resultados são anomalias de dados e devem ser apresentados ao proprietário 
do negócio com uma forte recomendação de que sejam limpas no sistema. As Ferramentas de 
Perfilhamento de Dados foram desenvolvidas para ajudar nesse tipo de análise de amostragem de 
dados.
 » Tipos de verificações de QA - É útil dividir os vários tipos de verificações de 
qualidade de dados em quatro grandes categorias.
 › Propriedades de coluna (domínio)
 › Verificação se atributo do registro contém valores esperados.
 › Verificação de NULL em colunas exigidas.
 › Valores numéricos que estejam fora de limite mínimo/máximo (range).
 › Colunas com tamanho muito pequeno ou muito grande.
 › Estrutura
 › Foca na estrutura de dados e não no dado em si (como acima).
 › Verificação de integridade dos dados: relações entre colunas (por exemplo, FK - 
Foreign Key), verificação de chaves primárias (forçar identidade) etc.
 › Regras de dados ou valores
 › Verificação de regras de negócio entre os atributos de um registro, das mais 
simples às mais complexas.
Ex.: Se um cliente tem no campo [limite de saque] o valor 1000, então o campo [status] deve conter 
“Cliente padrão”.
47
CAPítulo 2
técnicas de carga
dimensões e estratégias de carga
Tabelas de dimensão são o “coração” do Data Warehouse. Elas fornecem o contexto para as tabelas 
de fatos e, portanto, para todas as medidas.
Embora as tabelas de dimensão sejam geralmente menores do que as tabelas de fatos, elas são 
fundamentais para o sucesso do Data Warehouse, pois fornecem os pontos de entrada para as 
tabelas de fatos.
O processo de entrega começa com os dados limpos e conformados, resultante dos subsistemas de 
origem.
O plano de carga básica é relativamente simples: executam-se transformações básicas nos dados 
para construção das linhas da dimensão para então carregar na tabela de apresentação final. 
Isso, normalmente, inclui atribuição de uma surrogate key, pesquisas de código (Lookups) para 
fornecer descrições apropriadas, dividindo ou combinando colunas para apresentar os valores 
de dados apropriados, ou aplicar a estrutura de tabela na terceira forma normal em dimensões 
desnormalizadas.
Estratégias de cargas históricas em dimensões
Slowly Change Dimensions (SCd) tipo 1
Esta é a abordagem mais simples em que é feita a substituição de um ou mais atributos de um 
registro já existente na dimensão. É útil sempre que os valores antigos do atributo não possuem 
nenhum significado ou devem ser descartados (por exemplo, a correção de um erro) ou se não 
houver interesse em manter a história dos valores anteriores e não houver necessidade de executar 
relatórios históricos. 
Uma substituição é sempre realizada por UPDATE nos dados, e embora a inserção de novos registros 
em um tipo de SCD requer a geração de novas chaves de dimensão, as alterações em um SCD tipo 1 
nunca afetam as chaves de tabela dimensão ou das chaves das tabelas fato e, em geral, têm o menor 
impacto sobre os dados dos três tipos de SCD. 
Vantagem
 » Rápido e fácil
48
UNIDADE III │ TRANSFORMAÇÃO E CARGA DE DADOS
Desvantagem
 » Perde-se o histórico das alterações dos atributos. Observa-se apenas os atributos 
descritivos como eles existem na atualidade.
No exemplo a seguir, ao observar-se o comércio do jogo Sim City ao longo do tempo, percebe--
se que, em momentos sazonais, há um aumento considerável de suas vendas, mas não se sabe o 
porquê!
Linha original
Chave do Produto ID do Produto Descrição Departamento
12345 SC3000 Sim City 3000 Educacional
Linha atualizada
Chave do Produto ID do Produto Descrição Departamento
12345 SC3000 Sim City 3000 Estratégico
Devido ao SCD tipo 1 sobrescrever os dados, a técnica de mais fácil implementação 
é utilizar instruções SQL UPDATE para conseguir com que todos os atributos da 
dimensão reflitam corretamente os valores atuais.
Infelizmente, como o SQL UPDATE é uma transação de baixo desempenho e pode 
inflar a Janela de carga ETL. A dica de melhor maneira de reduzir essa sobrecarga é 
empregar sua carga em massa (Bulk loader).
Da seguinte maneira: Preparam-se os novos registros da dimensão em uma 
tabela separada. Em seguida, apagam-se esses registros da tabela de dimensão e 
recarregam-nos com o comando SQL Insert em carga em massa (Bulk Loader).
Slowly Change Dimensions tipo 2
O SCD Tipo 2 é a técnica padrão para acompanhar com precisão as mudanças nas entidades 
dimensionais e associá-las corretamente com as tabelas de fatos.
A ideia básica é muito simples. Quando o Data Warehouse é notificado de que um registro de 
dimensão existente precisa ser mudado, ao invés de substituir, o Data Warehouse cria um novo 
registro na dimensão no momento da mudança. A esse novo registro de dimensão é atribuído uma 
nova Surrogate Primary Key (Chave primária substituta), e essa chave é utilizada a partir desse 
momento, em todas as tabelas de fatos que fazem referência a essa dimensão como uma chave 
estrangeira. 
Quando a nova chave é atribuída imediatamente no momento da mudança, nenhum registro já 
existente em qualquer tabela de fatos precisa ser atualizado ou alterado, e também em nenhuma das 
tabelas de fatos agregadas precisam ser recalculadas.
49
TRANSFORMAÇÃO E CARGA DE DADOS │ UNIDADE III
Figura 14. sCD Tipo 2 - Partições perfeitamente históricas
Fonte: Kimball; ralph (2004).
Na Figura 14, pode-se ilustrar