ETL – Extração,

Transformação e
Carga de dados
Autor
Marlom Alves Konrath
Autora revisora
Elisamara de Oliveira
 Apresentação
Caro(a) estudante,

Conforme veremos neste conteúdo, o processo de ETL (Extraction, Transform and Load)
corresponde a mais de 70% do esforço e dos recursos envolvidos em um Data Warehouse (DW).
Ou seja, as decisões tomadas durante a definição, o estabelecimento e a implantação de um
processo de ETL serão responsáveis por grande parte do sucesso ou fracasso de um projeto de
DW.

ETL é o nome genérico para uma série de processos através dos quais os dados são obtidos de
diversas fontes e, em seguida, transformados, agrupados, calculados e modificados, conforme
necessário, até ficarem no formado adequado ao seu destino. Ao final, esses dados alimentarão
um ou mais sistemas que compõem um DW, que fornecerão dados valiosos para o negócio.

Nossa caminhada começa com uma reflexão sobre o universo de dados corporativos e a
importância de sua integração, quando abordaremos os principais tipos de integração e
mostraremos uma rápida visão dos passos do ETL.

Na sequência, iremos nos aprofundar em cada uma das etapas do ETL, iniciando pela definição
dos requisitos, para que possamos ser mais assertivos na implementação dos demais passos.
Na etapa de Extração, vamos discutir os desafios relacionados ao uso de múltiplas fontes de
dados e à heterogeneidade de seus formatos, afinal, hoje as ferramentas de ETL são capazes de
ler arquivos de texto, conectar com bancos de dados, abrir arquivos em formatos de documentos
e planilhas, acessar e analisar conteúdos de redes sociais, sites web, entre outros. Uma vez
reunidos e selecionados os dados importantes para a tomada de decisão, a próxima etapa –
Transformação – realiza a limpeza dos dados, sua uniformização, sempre que possível, e a
aplicação de complexos processos para sua adequação ao formato de destino desejado. Na
sequência, veremos que a etapa de Carga é responsável por alimentar o DW com dados limpos e
confiáveis obtidos na etapa de Transformação.

Estudadas as etapas, passaremos a nos concentrar nas ferramentas e soluções de ETL

existentes, começando pelo seu histórico. Veremos uma lista das principais ferramentas de
mercado e, na sequência, uma atenção especial será dada às soluções livres e de código aberto.
Nessa etapa, sugerimos você baixe e experimente as principais ferramentas gratuitas. Além de
ser uma atividade prazerosa, experimentar e realizar pequenas simulações nessas ferramentas
lhe trará grandes insights e permitirá uma compreensão muito melhor do conteúdo. Para
concluir a etapa das ferramentas de ETL, discutiremos brevemente o cenário envolvendo o
desenvolvimento de uma solução própria de ETL em vez de utilizarmos uma ferramenta
comercial pronta. Para ajudar nessa decisão, buscamos elencar os prós e contras de cada
abordagem, bem como as principais considerações que devem guiar essa decisão.

Para completar nosso estudo, os modelos de integração em lote e em tempo real serão
abordados, seguidos de uma comparação entre eles. Nosso foco será direcionado para os dados
ou, mais especificamente, para o entendimento e a definição dos metadados, do Modelo de
Dados Canônico e do Gerenciamento de Dados Mestres. Em seguida, os principais padrões de
integração de dados em tempo real serão vistos. Nosso estudo termina com a exposição das
principais tecnologias e arquiteturas utilizadas na integração de dados em tempo real pelas
organizações.

Então, prepare um bom café, escolha um local tranquilo de estudo e mãos à obra: é hora de
conhecermos mais sobre o tema, seus desafios e experimentar as primeiras integrações de
dados.

Espero e desejo profundamente que este material lhe seja muito proveitoso.

Prof. Marlom Alves Konrath

Videoaula - Apresentação

Escaneie a imagem ao lado com um app QR code para assistir o vídeo ou clique aqui
[https://player.vimeo.com/video/475194604] .
 1 A importância da integração de dados
Qualquer empresa de médio ou grande porte hoje em dia possui um ambiente computacional
composto por centenas ou milhares de sistemas que foram desenvolvidos ou comprados para
atender às demandas de seus colaboradores e clientes. Para que a alta gerência possa ter uma
visão mais consolidada da empresa e consiga tomar decisões melhores, essas informações
precisam ser cada vez mais integradas, de forma a permitir análises mais precisas.

Para realizar essa integração de dados, precisamos primeiro obter os dados de fontes diversas,
processá-los e depois convertê-los em um formato comum. Além disso, precisamos que
diferentes sistemas “conversem” entre si. Seja pela substituição de um sistema antigo por um
novo, seja pela necessidade de troca de dados entre diferentes aplicações. A movimentação de
dados entre sistemas é um desafio não trivial e com o qual toda empresa precisa lidar.

A maior parte do gerenciamento de dados tem seu foco direcionado para os dados armazenados
de maneira estruturada em bancos de dados e arquivos. Interfaces de dados e APIs (Application
Programming Interfaces) são frequentemente criadas para permitir a troca de informação entre
diferentes sistemas.

Figura 1 – Troca de informações entre

sistemas.

Fonte: Adam Nowakowski/unsplash.com

Contudo, o incremento do portfólio de sistemas, se não tratado adequadamente, pode levar a um

crescimento indesejado na complexidade das interfaces, implicando altos custos de
gerenciamento e integração entre sistemas.
Dessa forma, a aplicação das melhores práticas na integração de dados tem o potencial de
melhorar significativamente o custo-benefício do gerenciamento das interfaces de dados.

Há um consenso no ambiente corporativo de que a compra e posterior configuração de pacotes

de software é mais vantajosa economicamente do que o seu desenvolvimento interno. Isso
ocorre principalmente porque, em um pacote de software de prateleira, os custos com o
desenvolvimento de novas funcionalidades e a detecção e resolução de erros acabam sendo
compartilhados entre todos os clientes que o adquirem da empresa fabricante.

Os pacotes de software oferecem, muitas vezes, ferramentas e formas de integração com outros
sistemas. Entretanto, ao contrário de sua instalação, que em geral segue passos padronizados, o
processo de integração entre diferentes sistemas é uma tarefa muito mais customizada, na qual
adaptações particulares ao ambiente corporativo precisam ser gerenciadas.

Esse tipo de integração pode se tornar uma atividade particularmente desafiadora ao levarmos
em consideração que diferentes sistemas corporativos terão, cada um, a sua própria versão de
entidades como clientes, produtos, serviços ofertados, regras de negócio e formas de
disponibilização e acesso.

Como as estruturas de dados principais existirão em cada um dos sistemas, será necessário
integrarmos esses dados entre os sistemas, pois, caso contrário, um mesmo cliente poderá ter
que realizar múltiplos cadastros. E, mesmo no caso de múltiplos cadastros, a integração é
importante para identificarmos, por exemplo, que um cliente que comprou nosso produto X é o
mesmo que está assinando o serviço Y.

A integração de ferramentas e soluções de diferentes fabricantes pode levar a um cenário no

qual o uso de pacotes de software acaba gerando requisitos de integração de dados muito
complexos. Essa complexidade pode acabar eliminando a economia obtida com o uso de
pacotes de software de prateleira, se comparados com soluções desenvolvidas internamente.

Em cenários de Big Data, em geral, a melhor solução consiste em não tentarmos integrar os
dados entre os diversos sistemas. Em vez disso, deixamos os diferentes tipos de dados em seus
locais e formatos originais e distribuímos o seu processamento. Somente quando os resultados
das requisições a cada um dos conjuntos de dados forem obtidos é que os valores serão
consolidados, computados e salvos de maneira integrada.
 Figura 2 – Fontes de dados do Big Data.

Fonte: innoscience.com.br [https://www.innoscience.com.br/innovation-data-analytics/] .

A integração de dados é fundamental em uma solução de Big Data, mas a maneira como essa
integração ocorre pode divergir bastante do modelo tradicional de integração de dados. Ao longo
das últimas décadas, diversas novas tecnologias deram origem ao surgimento de novas
necessidades de integração.

A virtualização de servidores e as soluções baseadas em nuvem utilizam muito a replicação de

dados como forma de construir sistemas escaláveis e tolerantes a falhas. Novamente, a
integração de dados dessas soluções é bem diferente das utilizadas em data centers
tradicionais. Estruturas de dados em memória se tornaram também muito comuns e visam a
fornecer soluções de alta performance para o armazenamento e a busca de informações
dinâmicas e semiestruturadas.

Todas essas tecnologias levaram ao que conhecemos hoje como virtualização de dados.
Segundo a IBM (2019), com a virtualização de dados “é possível consultar dados em vários
sistemas sem precisar copiar e replicar dados, o que reduz custos”.

A virtualização de dados consiste, portanto, na consolidação de dados a partir de uma ou mais

fontes e em sua disponibilização em um modelo de dados virtual. Diferentemente das técnicas
de ETL, na virtualização de dados estes não são copiados para outro local, mas são mantidos
apontamentos para os dados em suas fontes originais.
 Figura 3 – Virtualização e serviços em
nuvem.

Fonte: mgtek.com.br
[https://mgtek.com.br/lages/blog/virtualiz
acao-de-servidor-voce-sabe-o-que-e-e-
qual-a-sua-importancia/] .

A partir desse cenário em que mostramos a você, estudante, o universo de dados corporativos e
a importância de sua integração, vamos dedicar esta Unidade ao tema, apresentando as noções
básicas sobre a integração de dados. Apresentaremos a seguir alguns dos desafios e
características relacionados à integração de dados, abordaremos os principais tipos de
integração de dados, associaremos a integração de dados ao processo de ETL e detalharemos o
fluxo mais comum das atividades envolvidas em ETL.
 2 O que é integração de dados
Ter dados confiáveis e disponíveis é um fator crucial para a tomada de decisão e para o sucesso
de qualquer organização. Os processos responsáveis pela gerência dos dados e da sua
qualidade compõem as disciplinas de Governança de Dados e Gerenciamento da Qualidade de
dados.

Segundo o site do governo federal (GOV.BR, 2019) a Governança de Dados representa

o exercício de autoridade e controle, relacionado ao planejamento, monitoramento e execução, sobre

a gestão de ativos de dados de modo a promover a interoperabilidade das informações, meios de

análise (...) e serviços digitais mais simples e ágeis ao cidadão, organizações e empresas.

Já o Gerenciamento da Qualidade de Dados, de acordo com a organização internacional DAMA

(2011), refere-se à

aplicação de conceitos e práticas de gerenciamento da qualidade total para melhorar a qualidade

dos dados e das informações, incluindo a definição de políticas e diretrizes de qualidade dos dados,

medição da qualidade dos dados (...), análise da qualidade dos dados, limpeza e correção dos dados,

melhoria do processo da qualidade dos dados, e educação em qualidade de dados.

A DAMA International é uma associação global, sem fins lucrativos, independente de fornecedor,
de profissionais técnicos e de negócios, dedicada ao avanço dos conceitos e práticas de
gerenciamento de informações e dados.

Figura 4 – Logotipo da DAMA

International.

Fonte: dama.org
[https://dama.org/sites/default/files/DAMA
%20Corporate%20Logo.jpg] .

Este é um ponto tão importante que existem soluções comerciais voltadas exclusivamente para
essa área, como o Oracle Enterprise Data Quality e o Microsoft Data Quality Services.

Ainda de acordo com a organização DAMA (2011), a integração de dados se refere ao processo
de gerenciamento dos dados que trafegam entre bases de bancos de dados, aplicações e
organizações. A integração consolida os dados em formatos consistentes, de maneira física ou
virtual. Assim, ao contrário do senso comum, a integração de dados se refere mais à
movimentação de dados do que à sua persistência.

Em geral, a parte mais difícil e complexa de uma integração de dados é a sua transformação em
um formato comum. O entendimento dos dados a serem combinados e a definição e
compreensão da estrutura a ser utilizada requer ao mesmo tempo conhecimentos técnicos e de
negócios sobre os dados e seu uso esperado.

A transformação de dados a partir de múltiplas fontes pode envolver desde a simples mudança
da formatação de um dado até cálculos complexos ou a busca de informações adicionais. A
figura 5 representa graficamente esse processo de transformação e integração de dados.
 Figura 5 – Diagrama de transformação de dados.

Fonte: elaborada pelo autor.

Em uma empresa, a existência de múltiplos sistemas heterogêneos torna inviável uma integração
ponto a ponto de cada sistema com os demais. Assim, muito do planejamento relativo à TI nas
organizações tende a ocorrer em torno do gerenciamento eficiente de dados e o seu
armazenamento em SGBDs (Sistemas Gerenciadores de Banco de Dados) ou outras tecnologias.

Soluções específicas para a integração, a consolidação e o gerenciamento de dados, como Data

Warehouse e Data Marts (DMs), foram projetadas e desenvolvidas a fim de centralizar dados com
finalidades de uso específicas.

Segundo Amazon (2020), um Data Warehouse (DW) é “um repositório central de informações que
podem ser analisadas para tomar decisões mais fundamentadas”.

Os dados que têm valor para a tomada de decisão são coletados a partir de SGBDs e outras
fontes, transformados e salvos em formatos que permitem a geração de relatórios e análises
avançadas por parte das áreas de negócio. Mas será que todos os setores e tomadores de
decisão da empresa necessitam ter acesso a todos os relatórios disponíveis em um DW? Ou será
que o ideal é terem que navegar por vários menus ou criarem filtros específicos apenas para ter
acesso aos dados que necessitam para a tomada de decisão?

A resposta da primeira pergunta é: claro que não! A segunda pergunta tem sua resposta nos Data
Marts! Então vamos estudá-los! A figura 6 apresenta o exemplo de um DW com vários DMs.
 Figura 6 – Exemplo de um Data Warehouse com vários Data Marts.

Fonte: talend.com [ttps://www.talend.com/wp-content/uploads/data-mart-

diagram.jpg] .

Segundo Talend (2020) um Data Mart (DM) é uma base de dados orientada para um assunto
específico e que representa frequentemente uma partição de um DW corporativo. Ou seja, um
Data Mart é um mini Data Warehouse, contendo apenas os dados analíticos necessários em uma
unidade de negócio, como vendas ou marketing.

Mais recentemente, a busca por conhecimento e integração a partir de fontes de dados não
estruturados se tornou imprescindível nas organizações. Assim, os sistemas passaram a
analisar também e-mails, sites, redes sociais, arquivos de áudio e vídeo e outras fontes e
associá-los a clientes, funcionários, produtos, perfis de usuários, padrões de preferência ou outro
tipo de agrupamento ou padrão comum que tenha sido encontrado.
 3 Tipos de integração de dados
A complexidade de integração entre diferentes sistemas pode crescer exponencialmente se não
for adequadamente gerenciada. O foco principal da integração de dados está nos processos de
descoberta, definição, associação e transformação de dados entre diferentes sistemas. Assim,
uma abordagem comum na implementação da integração envolve a definição de um modelo
principal para as entidades mais importantes de uma organização, como cientes, produtos,
serviços, faturas, ofertas, entre outros. Esse modelo é conhecido como Modelo Canônico e busca
padronizar os dados, permitindo o seu reúso e reduzindo a complexidade e o custo das
integrações.

Em relação aos tipos de integração, as três formas mais comuns são o processamento em lote,
em tempo real e big data, que veremos a seguir.

3.1 Integração de dados em lote

A integração de dados em lote é aquela em que os dados são agrupados e enviados de maneira
periódica (de hora em hora, diariamente, semanalmente, mensalmente etc.) de uma origem para
um destino. Nesse caso, há um compromisso e um entendimento comum entre os dois sistemas
em relação ao layout do arquivo utilizado.

Esse tipo de troca de dados entre dois sistemas, em que um sistema passa dados para outro, é
chamada de ponto a ponto. Nesse tipo de abordagem, o arquivo de dados frequentemente não é
processado pelo sistema receptor de maneira imediata. Em vez disso, o sistema receptor irá
realizar o processamento em um momento posterior. Dessa forma, o modelo de integração é
chamado de "assíncrono", uma vez que o sistema que envia o arquivo não aguarda uma
confirmação imediata antes que a transação seja considerada concluída. Veja a diferença entre
modo síncrono e assíncrono na figura 7.
 Figura 7 – Modo assíncrono × síncrono.

Fonte: elaborada pelo autor.

A abordagem em lote é particularmente muito eficaz e apropriada em cenários de interações de

dados muito grandes, como conversões de dados e carregamento de instantâneos (snapshots)
de dados em DWs. A grande vantagem dessa abordagem está na velocidade de transferência e
carregamento de dados. Como não há processamento adicional além do necessário para salvar
o arquivo, esse modelo tende a ser muito mais rápido que o cenário de integração em tempo real.

Esse modelo também é definido como fortemente acoplado, uma vez que o formato do arquivo
de dados precisa ser o mesmo em todos os sistemas envolvidos, e alterações no modelo deverão
ser incorporadas em todos os sistemas de maneira simultânea.

Na abordagem em lote, é comum a criação de um perfil de dados. Isso porque a criação de perfil
de dados acaba tornando explícita a necessidade de que os dados de origem sejam corrigidos e
limpos antes da implementação do ETL. Esse processo permite que possamos entender melhor a
qualidade dos dados com os quais estamos lidando.

A boa notícia é que em alguns cenários o processo de correção dos dados pode ser parcialmente
automatizado. Entretanto, algum grau de investimento é frequentemente necessário na correção
manual dos dados e na mudança de processos para que os novos dados estejam mais próximos
do padrão de qualidade desejado.
 Videoaula - Integração em tempo real

Escaneie a imagem ao lado com um app QR code para assistir o vídeo ou clique aqui
[https://player.vimeo.com/video/475207807] .

3.2 Integração de dados em tempo real

As interfaces entre os sistemas que são necessárias para a realização de uma única transação
comercial são chamadas interfaces em tempo real ou streaming. Quando comparadas com a
integração em lote, a troca de dados em tempo real geralmente envolve uma quantidade muito
menor de dados sendo transmitidos. Esse tipo de interface também é considerado fortemente
acoplada, uma vez que os sistemas de envio e recebimento concordam quanto ao formato da
mensagem.

Estudante, vale a pena você assistir a este vídeo que fala sobre streaming de vídeo denominado
TecMundoExplica: Streaming. Um exercício interessante seria você associar o tema com o
streaming de dados síncrono do qual estamos falando aqui. Acesse em: youtube.com
[https://www.youtube.com/watch?v=C27uLHViR5Q] .

A troca de dados ocorre na forma de uma mensagem entre dois sistemas e o seu processamento
geralmente ocorre de maneira imediata no sistema de destino. Mesmo que o processamento não
ocorra no instante do recebimento, é comum que o sistema que está enviando a mensagem
aguarde por uma confirmação de processamento pelo destino antes de considerar a operação
como concluída. Por isso, esse modelo é chamado de síncrono, uma vez que a origem irá
aguardar a sinalização de conclusão do destino.

Algumas soluções de integração em tempo real flexibilizam um pouco o acoplamento de dados

através do uso de padrões de design lógico. É o caso, por exemplo, dos bancos de dados NoSQL,
nos quais um documento pode ter diferentes atributos em cada entidade.

3.3 Integração de Big Data

O uso da expressão big data, neste contexto, indica a existência de um grande volume de dados,
bem como a coexistência de dados de diferentes formatos e tecnologias. Para que possam ser
processados, a integração de dados de big data, em geral, irá envolver a distribuição paralela do
processamento dos dados, executada sobe os dados de origem e a integração apenas dos seus
resultados.

A consolidação dos dados antes do seu processamento é em geral impraticável do ponto de

vista econômico, em função do processamento e do espaço de armazenamento extra requeridos
para tal operação.

A integração de dados estruturados e não estruturados é considerada como fracamente

acoplada, dada a diversidade de modelos que podem ser encontrados nos dados não
estruturados e o seu modelo de integração pode ser síncrono ou assíncrono. A figura 8 ilustra a
diferença entre os tipos de dados.
 Figura 8 – Dados estruturados x não estruturados.

Legenda: diferença entre os tipos de dados (estruturados e não estruturados).

Fonte: grupotreinar.com.br
[https://www.grupotreinar.com.br/blog/2016/4/9/vis%C3%A3o-geral-sobre-a-
gest%C3%A3o-de-conte%C3%BAdo-n%C3%A3o-estruturado-e-ecm.aspx] .

Videoaula - ETL

Escaneie a imagem ao lado com um app QR code para assistir o vídeo ou clique aqui
[https://player.vimeo.com/video/475199537] .
 4 O processo ETL – Extract, Transform and Load
O processo de integração de dados envolve três grandes etapas:

1. Extract (Extração): obter dados a partir das fontes onde eles estão armazenados;
2. Transform (Transformação): alterar os dados para que sejam compatíveis com o formato de destino
desejado; e
3. Load (Carga): carregar os dados no sistema de destino.

Essas três etapas são mais conhecidas pela sigla ETL.

Toda integração de dados, independentemente de ser realizada em lote ou em tempo real, de ser
conduzida de forma síncrona ou assíncrona, aborda em maior ou menor grau essas três ações
básicas.

Embora seja um conceito simples, existem grandes diferenças em projetos e soluções de ETL.
Podemos encontrar descrições de processos que utilizam a sigla ETL, mas que possuem tarefas
que variam drasticamente.

As ferramentas existentes também nos mostram que a variedade de abordagens e estilos de

integração de dados possuem vários níveis de complexidade e adequação. Mas antes de o
processo de ETL iniciar, é essencial, como já dissemos, criar um perfil de dados.

4.1 ETL – Etapa 1: Extração

A primeira parte do ETL envolve o processo de extração dos dados. Para isso, precisamos
acessar os dados no banco de dados ou sistema em que eles estão disponíveis. Além disso,
precisamos saber o formato, o significado e as relações dos dados que temos interesse em
copiar.

Duas abordagens são possíveis na extração dos dados: na primeira delas são usados recursos
internos de onde o sistema de origem se encontra para realizar uma cópia dos dados desejados.
Já na segunda, é utilizado um sistema externo, especializado na extração, para realizar o acesso
e a obtenção dos dados.

A grande vantagem de se usar recursos de onde o sistema de origem se encontra para realizar a
extração é que a equipe local entende completamente o significado dos dados, a forma e
tecnologia na qual eles são armazenados. E o conhecimento do sistema e da tecnologia, bem
como o formato e o significado dos dados de origem, tende a ser o maior obstáculo na
implementação do processo de extração. Outra vantagem reside no fato de que a maioria dos
sistemas está em constante evolução, a qual acaba afetando também a forma e o local onde os
dados são armazenados. Ao realizar o processo de extração internamente, a equipe de
desenvolvimento pode realizar os ajustes necessários no processo de extração para que este
passe a considerar as mudanças implementadas nos dados.

No entanto, essa abordagem algumas vezes não é possível. Dois motivos principais podem
inviabilizar a extração dos dados pela equipe interna:

1. o sistema de origem pode ser um sistema crítico de produção e pode não ser viável impactar
negativamente o desempenho da produção, adicionando mais operações do que foram projetadas; e
2. a equipe de desenvolvimento e/ou suporte do sistema de origem pode não considerar a extração de dados
uma prioridade ou estar ocupada demais em outras atividades.

O uso de um aplicativo externo e especializado na extração dos dados tem a vantagem de

ocasionar um menor impacto no sistema de origem, embora essa ação possa causar alguma
sobrecarga no sistema de armazenamento. A maioria dos aplicativos de extração especializados
é muito eficiente na busca dos dados em bancos de dados relacionais e não relacionais. A sua
utilização, entretanto, requer pessoal treinado no uso de ferramentas e tecnologia específicas de
extração.

A desvantagem dessa abordagem é que possíveis modificações na forma ou local onde os dados
são armazenados terão de ser comunicadas à equipe para que o processo de extração seja
corretamente ajustado.

Em alguns cenários, o processo de extração gera um arquivo de dados que é enviado e salvo em
outro local, geralmente outro servidor ou plataforma. Armazenar os dados extraídos na
plataforma ou servidor de destino, bem como quaisquer pontos intermediários, é chamado de
armazenamento temporário dos dados ou data staging. Geralmente, existe um ponto de
armazenamento temporário tanto na plataforma do servidor de origem, bem como na de destino.
A figura 9 ilustra esse processo.
 Figura 9 – Armazenamento temporário dos dados ou data staging.

Legenda: armazenamento temporário dos dados ou data staging usado no

processo de extração de dados.
Fonte: elaborada pelo autor.

O armazenamento temporário dos dados nos permite também validar e auditar o que foi enviado
e o que foi recebido, bem como criar um modelo em que o processamento dos dados entre os
sistemas de origem e de destino seja fracamente acoplado ou assíncrono, pois os sistemas não
precisam realizar atividades coordenadas para processar os dados ao mesmo tempo, podendo
fazê-lo quando lhes for mais conveniente.

No entanto, a leitura e gravação do disco é significativamente mais lenta que o processamento

na memória. Por esse motivo, algumas implementações optam por pular essa etapa, tornando o
processo muito mais rápido, especialmente quando o fator velocidade é crítico. Nesse caso,
escolhemos sacrificar a possibilidade de validação e o desacoplamento entre os sistemas para
ganhar em termos de performance.

4.2 ETL – Etapa 2: Transformação

A tarefa de transformar os dados, tornando-os compatíveis com a estrutura de dados de destino,

é, em geral, a parte mais maleável do sistema, podendo variar de uma ação extremamente
simples até um conjunto de ações bastante complexo e, algumas vezes, impraticável. Também
não é incomum essa tarefa demandar a coleta de informações adicionais em outras fontes de
dados.
Suponha que um sistema deve gerar relatórios diários (a cada 24 horas) que apresentem o total
de vendas nos Estados Unidos, mas com datas em formato brasileiro (dd/mm/aaaa). Como as
datas americanas trabalham no formato mm/dd/aaaa, há necessidade de transformação de
dados, pois o tipo de data que está na fonte de dados americana deve ser ajustado para o formato
brasileiro.

A definição do processo de transformação exige que tenhamos requisitos de negócios

detalhados e que tenham sido revisados e aprovados pelas áreas responsáveis. Esta é a parte
em que a área de negócios terá papel fundamental. Os processos de extração e carregamento, ao
contrário, são implementados quase que exclusivamente através de processos técnicos, exigindo
pouca revisão da área de negócios, exceto para garantir que os dados corretos estejam sendo
utilizados. Nesta etapa, a existência do perfil de dados representa um passo muito importante,
pois é normal encontrarmos formatos e conteúdos inesperados. Os formatos e as estruturas de
dados no destino também precisam ser conhecidos com antecedência, para que o processo de
transformação possa ser adequadamente desenhado.

A equipe de TI pode ajudar nessa definição das regras de negócio, mas jamais deve ser a única
responsável por essa etapa. O seu desconhecimento sobre aspectos de negócio pode levar a
decisões erradas e com sérios impactos nos resultados finais. Assim, é imprescindível que a
definição, revisão e aprovação dos requisitos de negócio seja feita pelas áreas de negócio e por
pessoas familiarizadas com os dados em questão.

4.3 ETL – Etapa 3: Carga

A parte final do ETL diz respeito à inserção dos dados na estrutura de dados de destino, ou seja,
em fazer com que os dados resultantes do processo de transformação sejam salvos no destino
para serem utilizados pelo negócio. As duas principais abordagens para realizarmos o
carregamento dos dados no destino são: (a) utilizar um aplicativo que já existe ou (b) escrever
código específico para esse fim.

Sempre que possível, devemos preferir utilizar o aplicativo existente, pois esse código já possui
embutida a compreensão de como os dados devem ser estruturados. Mesmo que o código atual
do aplicativo não tenha sido projetado para o carregamento de altos volumes de dados, ainda
assim é preferível ajustar o processo de carregamento para permitir o uso do aplicativo atual do
que escrever um código específico para essa inserção.

Independentemente do método escolhido, as regras de validação presentes nas estruturas de

dados de destino não devem ser desativadas durante o processo de carregamento, a não ser que
seja absolutamente certo que todas as verificações de validação foram feitas antes do processo
de carga de dados.

Assista ao vídeo What is an ETL Tool? no link: youtube.com [https://www.youtube.com/watch?

v=K_FCHYWGGug] .
 Exercícios de fixação
Os principais tipos de integração de dados são:

extrair, transformar e carregar.

por linha, por coluna e por tabela.

em lote, em tempo real e big data.

de arquivo e de sistema.

Em relação ao uso dos recursos do sistema de origem para a extração dos dados, assinale a
alternativa correta.

A equipe local será a única responsável pela correta extração dos dados.

Só devemos usar o recurso do sistema de origem quando não houver outra alternativa.

O uso dos recursos do sistema de origem não terá impacto no desempenho geral do sistema.

A equipe local entende melhor os dados e o seu significado.

A etapa em que os dados já prontos são armazenados nos sistemas de destino é chamada de:

extrair.

carregar.

transformar.

staging area.
 RECAPITULANDO

Estudante, até agora nos concentramos nos aspectos básicos relacionados à integração
de dados. Citamos brevemente alguns assuntos que serão detalhados e trabalhados com
mais profundidade nas próximas Unidades.

Nossa jornada começou com uma breve contextualização, mostrando a importância da

integração de dados nos cenários atuais e o que envolve um cenário de integração de
dados.

Em seguida, abordamos os três cenários de integração de dados: em lote, em tempo real

e de Big Data. A integração de dados em lote foi mais detalhada, introduzindo a ideia de
um processo.

A continuação de nosso estudo nos levou a entender melhor os passos típicos de um

processo de ETL. Detalhamos um pouco mais os passos Extrair, Transformar e Carregar
e mostramos que nesse processo pode ser usada uma área para armazenamento
temporário ou data staging.

Agora é hora de começarmos a entender mais profundamente cada um dos passos de

um processo de ETL, especialmente a parte da transformação, onde, em geral, iremos
despender a maior parte do esforço e tempo.
 5 O processo de ETL e suas etapas
Segundo Sharda, Delen e Turban (2019, p. 173),

o processo de ETL consiste na extração (leitura de dados de uma ou mais bases de dados),

transformação (conversão dos dados extraídos de seu formato prévio para o formato no qual eles

precisam estar para poderem ser inseridos em um Data Warehouse- DW ou simplesmente em outra

base de dados) e carga (inserção dos dados dentro do DW.

Esses três processos representam as ações mais essenciais e são geralmente acompanhados
por tarefas intermediárias. Anteriormente abordamos a importância da criação de perfil e o uso
de uma área de armazenamento temporário como exemplos de tarefas intermediárias. No
entanto, o número de passos ou etapas do ETL pode variar. Mas, independentemente de quantas
tarefas são executadas e da sua ordem, a função principal de um ETL é entregar para o DW
informações integradas e confiáveis que, posteriormente, serão usadas em processos de análise
(Analytics) para orientar a tomada de decisão empresarial (observe a figura 10).

Figura 10 – Processo de ETL.

Principais etapas do processo de ETL.

Fonte: xplenty.com [https://www.xplenty.com/blog/etl-vs-elt/] .

Vamos ver as propostas de alguns autores.

Kimball e Caserta (2004) dividem o processo de transformação em dois, criando um modelo de

quatro passos: extração, limpeza, conformação e entrega (carga).

Reeve (2013) fala em criação de perfil, extração, transformação e carga.

Kimball e Ross (2013) elencam 34 subsistemas que formam a arquitetura em um ETL, divididos
em 4 componentes principais:

Extração (3 componentes): consiste em obter os dados das fontes e gravá-los em disco no ambiente
do ETL;
Limpeza e conformidade (5 componentes): consiste em submeter os dados iniciais a um processo de
melhoria de qualidade e combiná-los a partir de duas ou mais fontes para criar e impor as dimensões
e métricas definidas;
Entrega (carga) (13 componentes): envolve a estruturação física e a carga dos dados nos modelos
dimensionais do servidor de apresentação; e
Gerenciamento (13 componentes): consiste no gerenciamento dos sistemas e processos do ambiente
do ETL de uma maneira coerente.

Outros especialistas da área discutem qual a melhor ordem de processamento das tarefas.
Alguns julgam que o modelo mais eficiente é extrair, transformar e carregar. Já outros defendem
que o mais adequado seria extrair, carregar e só então transformar. A diferença principal diz
respeito a quando a etapa de transformação deve ocorrer: no servidor de origem, no servidor de
destino ou em um servidor separado (FRIEDLAND, 2016; ALVI, 2018; KUMAR, 2020).

Essa discussão se torna mais relevante quando o volume de dados a ser processado é muito
grande, cenário típico do Big Data. No caso de um alto volume de dados, é interessante que o
sistema seja capaz processá-los da maneira mais eficiente possível. A existência de áreas de
armazenamento temporários (staging areas) para os dados também poderão afetar
significativamente a velocidade do processamento.

Para nosso estudo, adotaremos a ordem clássica de execução em 3 etapas do ETL, conforme
podemos ver na figura 11.

Figura 11 – Etapas de um ETL.

Legenda: etapas do processo de ETL.

Fonte: Ferreira et al. (2010, p. 759).
Conforme mostra a figura 11, a fase de Extração (Extract) deve permitir a busca de dados em
múltiplas fontes (sources) e em múltiplos formatos (arquivos de texto, bancos de dados,
documentos, planilhas, tabelas em sites web etc.). A fase de Transformação inclui a limpeza dos
dados (Transform & Clean) e utiliza uma Data Staging Area (DSA). A etapa de Carga (Load)
carrega os dados limpos e transformados no DW. Mas antes de abordarmos as etapas do
processo de ETL em mais detalhes, vamos começar esta Unidade com uma das atividades mais
desafiadoras de todo o processo: o estabelecimento dos requisitos. Assim, na Unidade 2 vamos
inicialmente tratar dos tipos de requisitos e decisões que devemos considerar na fase de
planejamento da implantação de um ETL. Nas seções seguintes falaremos sobre as três etapas
do ETL com mais detalhes.
 6 Requisitos de um projeto que envolve o processo de ETL
Segundo Kimball e Caserta (2004), o processo que envolve a transformação dos dados de seu
formato original para as tabelas de dimensões consome ao menos 70% do tempo, esforço e
recursos de um projeto de DW. É, portanto, a definição desse processo que irá determinar muito
do sucesso ou fracasso do projeto.

Muito mais do que transformar e agrupar os dados, a ideia é utilizarmos o ETL para adicionar
valor significativo a eles. Para isso, o ETL buscará, entre outros, permitir que dados de múltiplas
fontes e formatos sejam utilizados conjuntamente, buscando remover falhas ou indicar
informações ausentes e ajustar os dados para serem usados da melhor maneira para o negócio.

Mas como podemos descobrir a melhor maneira para o negócio? É aqui que entra a importância
da elaboração correta dos requisitos. Esta etapa é, acredite, um dos desafios mais árduos do
projeto.

Os requisitos reúnem aquilo que é necessário (requisitado) para satisfazer as necessidades e

objetivos do projeto.

Kimball e Caserta (2004) propõem as seguintes categorias que definem ou levam à especificação
de requisitos em um projeto de DW:

requisitos de negócio: tipicamente obtidos através de entrevistas, reúnem o que o usuário final deseja
em relação ao DW, ou seja, o conjunto de informações para auxiliá-lo na tomada de decisão. Assim
como o negócio, estes requisitos estão em constante mudança e precisam ser reavaliados
periodicamente;
requisitos de conformidade: envolvem a definição de evidências de que o processo está de acordo
com a legislação de regulamentos que a empresa deve seguir;
requisitos de segurança: envolvem a definição de quem terá acesso aos dados, a possível criação de
perfis para esses acessos e os mecanismos de controle e registro de ações que deverão ser
empregados;
perfil de dados: envolve a análise preliminar de quão completos e corretos estão os dados para que
possamos avaliar se os resultados esperados com o DW poderão ser atingidos ou não. Embora essa
categoria possa parecer mais como uma tarefa do que como definição de requisitos, ela é colocada
aqui porque a criação do perfil de dados irá mostrar o cenário atual. Este cenário poderá servir como
fator impulsionador para a criação de novos requisitos de negócio, com vistas a melhorar a qualidade
dos dados. A análise também nos permitirá definir os requisitos mínimos em relação ao perfil e à
qualidade dos dados;
integração de dados: envolve o estabelecimento de atributos e dimensões comuns a partir de
diferentes fontes de dados, bem como a criação de requisitos de equalização das métricas de negócio
em uma base comum, que permita comparações mais independentes e imparciais;
latência dos dados: envolve a determinação dos requisitos em relação à frequência de atualização
dos dados, ou seja, o tempo máximo que poderá se passar entre a ocorrência de determinado evento e
a sua contabilização pelo DW;
arquivamento e procedência: envolve a determinação de requisitos referentes às necessidades de
manutenção e armazenamento a cada grande transformação realizada nos dados, a fim de permitir o
cumprimento de requisitos legais e/ou comparações, análises e reprocessamentos futuros;
interface de entrega ao usuário: envolve a definição dos requisitos em relação ao conteúdo e a
definição de como será a estrutura de apresentação dos dados ao usuário final;
habilidades disponíveis: as decisões envolvendo requisitos técnicos devem considerar se os
conhecimentos que a equipe possui são suficientes para a condução do projeto ou como as lacunas
detectadas serão sanadas. Assim, não devemos construir um sistema que dependa de um módulo
crítico escrito em Java ou de uma integração com uma ferramenta ETL comercial através do uso de
Java, por exemplo, se não houver na equipe técnica profissionais habilitados nessa tecnologia. Ou, se
essa opção for inviável, teremos que criar requisitos que definam como o conhecimento dessa nova
tecnologia será adquirido e mantido;
licenciamento de software: os custos com modelo de licenciamento e/ou aquisição de software e os
impactos na ampliação do seu uso devem estar claramente definidos e aprovados; e
arquitetura: as decisões envolvendo a arquitetura devem ser tomadas no início do projeto e se manter
consistentes ao longo de sua implementação.
 7 Etapa Extração do processo de ETL
A primeira etapa de um processo de ETL é a extração dos dados, cujo objetivo principal é ler,
identificar e copiar o conjunto de dados de origem que será considerado no fluxo do ETL
utilizando o mínimo de recursos possível para não afetar os sistemas de origem (KIMBALL;
CASERTA, 2004).

Pinheiro e McNeill (2014) destacam que, apesar de essa etapa ser considerada a mais simples,
possui suas complexidades, especialmente em relação à definição das atualizações
incrementais e às mudanças nos dados de origem que ocorrem ao longo do tempo. Já Lane
(2005) afirma que esse é frequentemente o passo mais demorado no projeto do ETL.

Em geral, a principal dificuldade encontrada recai sobre o fato de que cada fonte de dados possui
seu conjunto distinto de características de acesso, formato e possibilidades de extração. Aliado
a isso, à medida que as empresas evoluem, elas desenvolvem ou adquirem novos sistemas para
administrar seus negócios. Esses sistemas são, frequentemente, incompatíveis entre si e
utilizam tecnologias e protocolos de comunicação heterogêneos.

Kimball e Caserta (2004) sugerem que, antes de começarmos o processo de extração, seja
construído um mapa de dados lógicos que documente o relacionamento entre os campos de
origem e de destino. Esse documento irá vincular o início do processo de ETL ao seu resultado
final.

De acordo com Hoffner, Ramesh e Topi (2017) há dois modelos de extração possíveis:

extração completa: ocorre na primeira extração, quando os dados serão pela primeira vez utilizados
no ETL. Pode ocorrer também quando não é possível identificarmos quando o dado mudou, o que nos
obriga a ler todo o conjunto novamente. Uma vez que essa extração trabalha com todos os dados, não
há a necessidade de mantermos registros de mudanças nos dados de origem desde a última
atualização; e
extração incremental: ocorre após a primeira extração e considera apenas os dados que foram
modificados desde a última extração. Para que possamos utilizar essa técnica, deve ser possível
identificar todas as mudanças que ocorreram desde um determinado instante de tempo, ou seja, o
sistema deve ser capaz de emitir uma notificação de atualização (o sistema de origem é capaz de
notificar o processo de ETL que um dado mudou).
Assista ao vídeo PowerCenter : Incremental Extraction of Source que mostra na prática uma
extração incremental de dados, no link: youtube.com [https://www.youtube.com/watch?
v=DwIjsipQ2nc] .

7.1 Tipos de fontes e uso de fontes diversas

Cada fonte de dados pode utilizar uma tecnologia diferente de conexão, formato e forma de
extração. Em alguns cenários, se a tecnologia ou outro fator impedir a conexão direta com a
fonte de dados, pode ser necessária a extração desses dados através da criação de um arquivo
simples.

Segundo Kimball e Caserta (2004), as fontes a partir das quais os dados são provenientes (veja a
figura 12) incluem:

SGBDs: o acesso aos dados de bancos de dados é realizado geralmente através de conexão via ODBC
(Open Database Connectivity). ODBC é uma camada intermediária entre a aplicação e o SGBD para o
qual o driver foi desenvolvido. Sua principal vantagem é a transparência de acesso, uma vez que os
detalhes arquiteturais do SGBD de destino são implementados pelo driver;

Figura 12 – Fontes de dados.

Legenda: diferentes fontes de dados.

Fonte: elaborada pelo autor a partir de blog.bi9.com.br
[https://blog.bi9.com.br/business-intelligence/] .
mainframes: algumas grandes empresas ainda utilizam mainframes e sistemas legados no suporte
às atividades do dia a dia. A integração com esses sistemas envolve desafios únicos e específicos da
solução adotada;
arquivos simples (flat files):estes podem ser a única opção quando não há conexão direta com a fonte
de dados por não suportar operação de integração ou estar localizada fora da organização. Nos
passos intermediários do ETL, também é comum salvarmos dados em arquivos, pois costuma ser
mais rápido do que o armazenamento em um SGBD. Os formatos mais comuns para estes tipos de
arquivo são:
campos de texto com tamanho fixo no arquivo;
campos separados por um delimitador, como o CSV; e
XML, JSON, YAML.
arquivos de logs: registros de acesso de servidores web nos permitem entender o comportamento dos
usuários no site e esta pode ser uma informação muito valiosa. Tão valiosa que existe uma subárea
de conhecimento dentro do DW, chamada de clickstream data warehousing, que é voltada
exclusivamente para a análise desse tipo de registro; e
sistemas ERP: por serem sistemas que abrangem boa parte das atividades da organização e terem
sido adaptados ao negócio, esta classe de sistemas pode conter milhares de tabelas. Assim, Corr e
Stagnitto (2012) sugerem que, em vez de tentar entender o modelo de dados, é mais fácil utilizarmos
um adaptador para o ERP, fornecido por seu fabricante, para a tarefa de extração.
 8 Etapa Transformação do processo de ETL
A Transformação é a segunda etapa do processo de ETL. Nesta etapa os dados serão
transformados para se adequarem ao padrão final desejado, a fim de permitir o seu uso no DW.
Ou seja, é nesta fase que os dados são ajustados, convertidos e calculados de seu formato inicial
para o formato de destino.

A transformação dos dados normalmente poderá ser bastante complexa e envolver a aplicação
de uma série de regras, funções e ações sobre os dados.

Moss e Atre (2003) definem os principais passos desta etapa como limpeza, resumo, derivação,
agregação e integração.

Kimball e Caserta (2004) separam limpeza e conformidade em um processo e, em outro

processo, as transformações necessárias até a entrega dos dados nas tabelas fato e dimensão.

Em nossa abordagem, vamos tratar a etapa de Transformação em três atividades, conforme

veremos a seguir.

8.1 Limpeza e conformidade

Segundo Kimball e Caserta (2004), as tarefas de limpeza e conformidade são os principais

passos para a adição de valor em um processo de ETL. Isso porque os demais passos, embora
também importantes, envolvem apenas a movimentação e reformatação dos dados, enquanto as
tarefas de limpeza e conformidade realizam mudanças mais profundas nos dados e fornecem
indicadores de sua qualidade, ou seja, definem se poderão ou não ser utilizados com sucesso
para os fins a que se destinam.

O primeiro passo da Limpeza é a elaboração de uma análise da qualidade dos dados. Existem
ferramentas específicas para analisar, tratar e garantir a qualidade dos dados. As empresas
apresentadas na figura 13 são as principais fabricantes de ferramentas de qualidade de dados,
divididas no quadrante mágico do Gartner.
Figura 13 – Quadrante Mágico do Gartner para ferramentas de qualidade de
dados.

Fonte: gartner.com
[https://www.gartner.com/resources/363400/363493/363493_0001.png] .
Chien e Jain (2019) apresentam uma relação bem completa de ferramentas e as avaliações
realizadas sobre estas ferramentas. Acesse no link: b2bsalescafe.files.wordpress.com
[https://b2bsalescafe.files.wordpress.com/2019/09/gartner-magic-quadrant-for-data-quality-
tools-march-2019.pdf] .

O quadrante mágico do Gartner “é uma representação gráfica do mercado tecnológico por

determinado período. Define forças dentro de um segmento empresarial, fazendo com que fiquem
nítidas as qualidades e possíveis falhas das empresas mais significativas da área de tecnologia.
O quadrante é dividido da seguinte forma:

1. Líderes (Leaders): reúne as empresas tecnologicamente mais avançadas. São aquelas que
ditam as regras dentro do seu segmento por ter uma melhor visão de mercado e capacidade de
levar adiante as suas promessas.

2. Desafiadores (Challengers): são empresas que estão logo atrás dos líderes. São companhias
com capacidade de execução plena, mas possuem apenas uma parcela do mercado.

3. Visionários (Visionaries): reúne as empresas mais fortes em pesquisa e desenvolvimento,

verdadeiras visionárias.

4. Concorrentes de Nicho (Niche Players): são aquelas que focam em determinadas

características de um mercado. Por exemplo, uma empresa automobilística focada apenas em
carros 4×4 para trilhas. Ela se diferencia de uma fabricante de carro comum.”

Fonte: opservices.com.br [https://www.opservices.com.br/o-que-e-o-quadrante-magico-do-

gartner] .

A análise de qualidade deverá apontar estatisticamente a quantidade de problemas encontrados

nos dados de origem. Alguns autores sugerem a utilização de tabelas fato e dimensão para
armazenar as violações encontradas, permitindo saber a evolução da qualidade ao longo do
tempo, ou seja, se a qualidade dos dados está melhorando, piorando ou se permanece
estagnada.

A análise da qualidade dos dados deve observar dados fora do padrão esperado. Essas violações
podem ser agrupadas em três grupos principais:
 valores errados em colunas: nesta categoria incluímos a existência de valores NULL em colunas
requeridas, valores numéricos fora das faixas esperadas e colunas com valores não esperados ou
sabidamente errados;
erros de integridade: nesta categoria estão os erros de integridade referencial, ou seja, a existência de
valores sem correspondência entre a chave primária e a chave estrangeira; e
violações de regras de negócio: detecta violações de regras referentes ao negócio. Pode envolver
regras simples, como uma que estabeleça que, se o cliente for menor de idade, ele deve ter um
responsável cadastrado; neste caso, a inexistência de um responsável seria uma violação. Pode
envolver também cenários mais complexos como a agregação de valores e análises estatísticas; por
exemplo, um aumento ou diminuição superior a 50% na quantidade de exames realizado por
determinada unidade de atendimento entre dois meses consecutivos poderia ser um fator de alerta.

Segundo Kozielski e Wrembel (2008), as tarefas de conformidade devem lidar com as seguintes
classes de conflitos:

problemas no nível do esquema: lida com conflitos de nomenclatura, como o uso do mesmo nome
para entidades ou objetos diferentes ou nomes diferentes para uma mesma entidade. Pode envolver
também diferenças de representação de um mesmo objeto em fontes diversas ou a necessidade de
conversão de uma escala para outra (por exemplo, a conversão de quilos para arrobas ou de graus
Celsius para Fahrenheit).

Assista ao vídeo O que é o BI - Começando pelo ETL que mostra na prática um exemplo simples
de transformação de dados, no link: youtube.com [https://www.youtube.com/watch?
v=gR0H5oyii7Q] .

problemas no nível do registro: lida com problemas de consistência e registros contraditórios ou

duplicados; e
problemas no nível de valores: lida com diferentes formas de se representar os mesmos valores ou
com a representação de valores diferentes de forma igual. Por exemplo, uma fonte utilizar ‘M’ e ‘F’
para masculino e feminino e outra fonte utilizar 0 para o sexo masculino e 1 para o sexo feminino.
Outro exemplo é uma fonte salvar datas no formato americano (mês/dia/ano) e outra fonte no
formato brasileiro (dia/mês/ano). Neste caso, 1/02/2020 representam datas diferentes em cada uma
das fontes.
 A figura 14 apresenta alguns exemplos de problemas de conformidade.

Legenda: exemplos de transformação relacionados à conformidade.

Fonte: player.slideplayer.com.br [https://player.slideplayer.com.br/18/5851811/] .

Observe que a conformidade é importante para que informações de fontes diferentes sejam
adequadamente entendidas e tratadas. Mas os ajustes de valores que estão em escalas ou
formatos diferentes para uma base comum são entendidos por alguns autores como
pertencentes aos cálculos de transformação que serão apresentados em seguida.

8.2 Agregação e cálculos

Uma vez que os dados tenham sido limpos e formatados, ou ajustados para uma base comum,
precisaremos realizar os cálculos e modificações necessárias para que os dados fiquem no
formato de destino desejado.

Essas modificações poderão envolver, por exemplo: a) a realização de cálculos para agrupar e
somar vendas por região, período, vendedor, cliente ou qualquer outro fator (dimensão) que
desejarmos; b) a mescla de tabelas de cliente de vários sistemas, identificando e agrupando as
informações quando um mesmo cliente estiver em mais de uma base de dados.

Segundo Hoffner, Ramesh e Topi (2017), a transformação dos dados poderá envolver uma grande
variedade de funções que podem ser agrupadas em duas categorias:

funções em nível de registro (record-level functions): operam sobre um conjunto de registros, como
um arquivo ou tabela, e suas funções principais são:
 seleção: envolve a extração e particionamento dos dados relevantes a serem utilizados no DW
de acordo com os critérios definidos;
junção: envolve a combinação dos dados de diversas fontes em uma tabela ou visão única;
normalização: envolve o processo de decompor relações com anomalias para produzir
relacionamentos melhor estruturados; e
agregação: envolve o processo de transformar os dados de uma versão mais detalhada para
um formato mais resumido.

Assista ao vídeo Utilizando Merge Rows (Diff) - Pentaho Data Integration para ver um exemplo de
seleção apenas de linhas novas no link: youtube.com [https://www.youtube.com/watch?
v=KnfF6gCzYG4] .

Funções em nível de campo (field-level functions): convertem os dados de um formato na origem

para um formato diferente no destino. Essas mudanças são de dois tipos:
campo único: envolve uma transformação de um tipo de dados para outro, seja através de um
cálculo matemático ou algoritmo, seja através de uma busca em outra tabela (exemplo:
conversão da sigla de um estado para o seu nome MG è Minas Gerais); e
múltiplos campos: envolve a transformação de uma ou mais colunas na origem em uma ou
mais colunas no destino. Por exemplo, a junção dos campos endereço, número, complemento,
CEP, cidade e Estado na origem em um único campo no destino, ou a separação do nome de
um único campo de oferta na origem nas colunas fabricante, produto e modelo no destino. A
figura 15 mostra dois exemplos desse tipo de transformação. No exemplo à esquerda, os
campos EmpName (nome do empregado) e TelephoneNo (número do telefone) são
concatenados para criarem uma chave única para cada empregado. Já a transformação da
direita realiza a separação do campo ProductCode (código de produto) em BrandName (nome
da marca) e ProductName (nome do produto).

Figura 15 – Exemplo de transformação em nível de campo

Legenda: exemplos de transformação de múltiplos campos.

Fonte: adaptado de Hoffner, Ramesh e Topi (2017, p. 455).
Em outra abordagem, Reeve (2013) define que o processo de transformação pode ser de quatro
tipos:

1. Simple Mapping: representa a forma mais simples de transformação, no qual um campo de dados (texto,
número, data etc.) possui um valor consistente na origem, mas que deve ser formatado para um valor
diferente no destino. Por exemplo, imagine que em um sistema A os Estados são salvos com seus nomes
completos (exemplo: Minas Gerais) e que no DW eles deverão ser mostrados como suas siglas. Assim,
estabeleceremos um mapeamento de Minas Gerais com MG.

Assista ao vídeo Power Query #10 ETL nos dados e mesclar tabelas no link: youtube.com
[https://www.youtube.com/watch?v=kUxHNAX411w] .

2. Lookups: ocorre quando os valores de um campo de dados na origem precisam ser mapeados para um
conjunto limitado de valores possíveis no destino. Para isso, o dado na origem é transformado em um
conjunto diferente no destino. Os requisitos irão definir como os mapeamentos de valores entre origem e
destino ocorrerão. Por exemplo, imagine que em um sistema os clientes sejam classificados em uma
escala de 0 a 10. Agora, imagine que nas Tabelas Fato de destino os clientes sejam classificados, segundo
sua importância, em Bronze, Prata, Ouro ou Diamante. Assim, nesta etapa poderíamos mapear as relações
conforme apresentado no quadro 1.

Quadro 1 – Exemplo de pesquisa e transformação no ETL.

Origem Destino

0a3 Bronze

4a6 Prata

7a8 Ouro

9 a 10 Diamante

Legenda: exemplo de uma pesquisa no sistema de origem e mudança no destino.

Fonte: elaborado pelo autor.

3. Aggregation and Normalization: na grande maioria das vezes, a transformação de dados envolve
processos bem mais complexos que os anteriores. Determinar o valor dos dados no destino pode exigir a
recuperação de vários dados da origem que podem estar em várias estruturas distintas. Um registro em
uma tabela de dados na fonte, por exemplo, pode acabar sendo mapeado para vários registros no destino.
O contrário também é verdadeiro.
Outro ponto importante, especialmente quando lidamos com várias fontes de dados distintas, é
estabelecermos mecanismos para determinar se dois ou mais dados presentes na origem
representam a mesma entidade no destino. Neste caso, além de eliminarmos a repetição, será
necessário determinar qual fonte deverá ser usada se alguma informação divergir entre elas.
Esse tipo de processamento é chamado de correspondência de dados e é parte central de ação
do Gerenciamento de Dados Mestres (Master Data Management – MDM), que se preocupa em
fornecer um ponto único de referência (o dado mestre) e associá-lo a dados referenciados. A
figura 16 apresenta um exemplo desse cenário: dois sistemas, representados pelas tabelas à
esquerda, contêm dados sobre clientes; através do CPF conseguimos concluir que o cliente
Carlos Rocha já realizou compras no site e nas lojas físicas; os campos em vermelho mostram
os dados que estão diferentes nos dois sistemas. A tabela da direita mostra os dados já
agregados. Neste caso, o campo nome foi obtido do sistema CLIENTES das lojas físicas, ao
passo que o campo endereço foi obtido do sistema CLIENTES da loja virtual.

Figura 16 – Exemplo de agregação.

Legenda: exemplo de agregação de clientes de dois sistemas em uma base comum.

Fonte: elaborada pelo autor.

Assista ao vídeo Master Data Management, que explica o que é Master Data Management no link:
youtube.com [https://www.youtube.com/watch?v=JF4mUqyoRFg] .

4. Calculation: em muitas transformações, o que interessa ao negócio não são os dados brutos. Neste caso os
valores a serem armazenados nas estruturas de dados de destino serão derivados de outros dados através
da aplicação de algum método de cálculo ou fórmula. Um exemplo de cálculo pode envolver cenários em
que os dados coletados na origem são insuficientes para preencher a estrutura de dados de destino. Neste
caso, os requisitos de negócio é que deverão especificar o comportamento da transformação. O resultado
da transformação pode determinar a utilização de um valor padrão no destino, a busca em fontes de dados
adicionais ou, até mesmo, a necessidade de que os dados sejam inseridos através de uma operação
manual.
Em 2012, a empresa americana Target identificou um nicho de mercado que queria explorar. Os
americanos possuem o hábito de comprar em várias lojas. Compram doces em lojas específicas
de doces e brinquedos em lojas só de brinquedos. Embora a Target vendesse de tudo, muitos
clientes compravam apenas parte de suas necessidades lá. A Target detectou que havia um
período em que esse hábito mudava: próximo ao nascimento de uma criança. No período final da
gravidez os pais estão em geral muito cansados e mudam o hábito indo em um só lugar. A Target
então criou um algoritmo que, baseado nos itens de compra de uma pessoa, conseguia prever
com bastante exatidão se havia alguma grávida na família ou não. Assim, passou a mandar
anúncios direcionados para esse público. Houve, inclusive, uma situação particular de um pai que
foi reclamar de estar recebendo ofertas desse tipo... mas a verdade é que ele não sabia que a filha
estava grávida. Ou seja, a Target descobriu, antes do pai, a gravidez de sua filha. Fonte: Hill
(2012).

A descoberta do padrão de consumo de grávidas foi feita através de técnicas de data-mining.

Mas, uma vez descoberto o padrão, o cálculo (calculation) foi incorporado ao ETL para a geração
de anúncios e códigos de cupom personalizados.

Note que alguns desses quatro tipos de transformações podem ocorrer também em outras fases
do ETL, como na etapa de limpeza e conformidade dos dados. Esse tipo de sobreposição de
ações é comum, pois a manipulação dos dados pode ocorrer em etapas.

8.3 Tabelas Fato e Dimensão

Em um projeto que envolve a criação de um DW, utiliza-se a modelagem multidimensional de

dados. Machado (2012) define a modelagem multidimensional como uma técnica que visa à
criação de um modelo de dados que permita a estruturação dos dados de forma que seja
possível apresentá-los em visões que ofereçam suporte à sua análise de forma mais precisa.
Esse modelo multidimensional é formado por três elementos básicos:

1. fatos, que são uma coleção de itens. Cada fato representa um item, uma transação ou um evento de
negócio. Os fatos são representados por valores numéricos e implementados em tabelas fatos. Exemplos
de fatos seriam vendas, produtos etc.;
2. dimensões, que definem o contexto de um assunto de negócios e participam de um fato, como ano, cidade,
mês, país, vendedor etc.; e
3. medidas (variáveis), que são atributos numéricos que representam um fato. As medidas podem ser valor
em reais das vendas, número de unidades de produtos vendidos etc.
A figura 17 ilustra o conceito de um modelo multidimensional com o fato vendas e as dimensões
e medidas associadas.

Figura 17 – Fato, dimensões e medidas.

Legenda: exemplo de um modelo multidimensional.

Fonte: adaptada de professor.ufop.br
[http://professor.ufop.br/sites/default/files/janniele/files/aula10.pdf] , p. 14.

Através da integração de dados, procuramos tratá-los e adaptá-los para as tabelas fato e

dimensão, combinando a melhor informação das diversas fontes de dados em uma visão
unificada. Esta visão deve ser consistente e, para isso, precisamos implementar interfaces
consistentes para as tabelas fato e as dimensões associadas.

As dimensões devem representar a mesma coisa em cada tabela fato com a qual estejam
ligadas. Isso nos permitirá que esse atributo comum seja usado como base para comparações
entre diferentes tabelas fato.

Segundo Kimball e Caserta (2004), o estabelecimento, a publicação, a manutenção e a imposição

dessas dimensões, denominadas dimensões conformadas (conformed dimensions), é uma das
responsabilidades centrais do time de projeto do DW e representa 80% do esforço desta etapa.

Para deixar mais claro, imagine como seria um DW que possuísse 10 dimensões diferentes, uma
para cada tabela fato existente. Nesse cenário, cada dimensão poderia possuir nomes de
campos diferentes para um mesmo atributo. Imagine como poderia ser confuso entendermos um
DW assim.

Em relação às tabelas fato, que representam os 20% do esforço restantes, devemos buscar
utilizar a mesma terminologia para haver consistência nos relatórios. A sua construção envolve
um processo mais colaborativo, pois as áreas de negócio envolvidas em cada tabela fato
precisam concordar na adoção de uma visão unificada.

Durante essa fase, devemos buscar também identificar medidas similares presentes em cada
tabela fato. Por exemplo, várias tabelas fato podem relatar dados de receita ou faturamento. Se
os usuários quiserem comparar essas medidas em tabelas fato separadas, então as regras de
negócio dessas medidas devem ser as mesmas. O momento e a frequência em que os dados
serão atualizados também devem ser os mesmos. Imagine se uma tabela fato medir a receita
apenas no final do mês e outra fizer isso diariamente? Algum tipo de conclusão útil seria
possível?

É importante ressaltar, ainda, que a adequação das tabelas fato para um formato, escala ou
modelo comum poderá exigir transformações adicionais nos dados. Mas, se isso for possível,
provavelmente poderemos realizar comparações diretas importantes para a tomada de decisões.
 9 Etapa Carga do Processo ETL
A parte final do processo de ETL envolve a carga (ou entrega) dos dados e o seu armazenamento
nas tabelas apropriadas. Nesse ponto os dados já estarão limpos, ajustados e transformados no
formato de destino, portanto, prontos para serem carregados no sistema final.

Vimos que no processo de extração, os dados podem ser obtidos a partir de diversas fontes de
dados distintas e heterogêneas. De maneira similar, na fase de carregamento os dados poderão
ser entregues para um ou mais repositórios finais, como Data Marts, por exemplo, antes de
serem inseridos no DW.

Há dois pontos principais que devemos considerar no processo de carga. O primeiro deles diz
respeito a se devemos impor ou desabilitar as restrições de integridade, valores nulos ou
inválidos e índices durante a carga dos dados. Como o processo de carga poderá envolver
grande quantidade de dados e causar sobrecarga sobre o sistema de destino, o ideal é que a
imposição dessas restrições seja desabilitada durante a carga no sistema de destino. Isso
poderá diminuir consideravelmente o processamento do sistema de destino e tornar o processo
mais eficiente. Contudo, desabilitar a validação das regras aumenta também o risco de
inserirmos dados errados ou inválidos no sistema. Portanto, só devemos desativar a imposição
das regras se a integridade for garantida pela ferramenta de ETL, ou se tivermos validações
anteriores à carga dos dados que garantam que as restrições foram validadas e estão de acordo
com o modelo de dados.

O segundo ponto diz respeito ao tipo de carga que será realizado. Ponniah (2010) define três
tipos de carregamento possíveis:

carregamento inicial: ocorre quando populamos todas as tabelas do DW pela primeira vez;
carregamento incremental: apenas as mudanças ocorridas desde a última carga são inseridas. Este é
o tipo ideal de carga quando temos a informação de tudo o que mudou desde a última carga de dados;
e
carregamento total: o conteúdo de uma ou mais tabelas é totalmente apagado e as tabelas são
recarregadas com os novos dados.

Podemos notar que o carregamento inicial é também um carregamento total de todas as tabelas
do sistema. O carregamento total possui a desvantagem de, em geral, consumir um tempo maior
que o modelo incremental. Mas a sua principal vantagem é que ele tende a ser bem mais simples
de ser implementado.
Assista ao vídeo Pentaho DI - Carga da tabela fato que mostra na prática um processo de carga
de dados, no link: youtube.com [https://www.youtube.com/watch?v=KS5MZIX_fnQ] .

Devido ao fato de o processo de carga poder tomar uma grande quantidade de tempo, ele deve
ser cuidadosamente planejado. Adicionalmente, se optarmos por desligar a imposição das regras
de integridade, provavelmente o DW terá que ficar offline durante o processo de carga.

Outra possibilidade é dividirmos o processo de carga em partes menores. Por último, mas não
menos importante, o processo de carga deve verificar se todos os dados foram inseridos com
sucesso e relatar quaisquer erros ou insucessos encontrados durante essa fase. É importante
definirmos também se determinado tipo de erro pode ser apenas registrado e o processo
continua, ou se a sua ocorrência fará com que o processo seja abortado.
 Exercícios de fixação
O único exemplo de dados fora do padrão é:

valores errados em colunas.

erros de integridade.

violações de regras de negócio.

valores nulos em coluna.

NÃO é um tipo de carregamento de dados em um processo ETL:

Carregamento Inicial.

Carregamento Diferencial.

Carregamento Incremental.

Carregamento Total.

As tabelas que armazenam as coleções de itens, eventos ou acontecimentos são chamadas de:

tabelas Fato.

tabelas Dimensão.

tabelas Dinâmicas.

tabelas Valor.
 RECAPITULANDO

Nesta Unidade, você aprendeu sobre os requisitos e as etapas de um processo de ETL.

Como deve ter ficado claro, a transformação é a parte mais difícil e trabalhosa de todo o
processo. Mas é, ao mesmo tempo, a parte que pode agregar mais valor ao negócio.

Começamos falando brevemente de como a necessidade de integração levou ao

desenvolvimento das primeiras ferramentas de ETL.

No entanto, antes de nos debruçarmos sobre cada uma das etapas, vimos os requisitos
que idealmente devemos considerar e definir na fase de preparação e planejamento, ou
seja, antes da implantação de um processo de ETL.

Em seguida, começamos pela primeira etapa de um ETL: o processo de extração,

mostrando os tipos de extração de dados possíveis e os tipos de fontes de dados que são
comumente utilizadas.

Continuando, foi a vez de lidarmos com a parte mais complexa e dispendiosa do

processo: a transformação dos dados. Em geral, esta parte é subdividida em várias
etapas, cuja ordem e funcionalidades podem variar bastante, mas que normalmente irão
envolver mecanismos de validação e ajuste da qualidade dos dados e de transformação
e derivação desses dados para o formato de destino desejado.

O processo de ETL termina com os dados já formatados sendo carregados em seus

destinos finais.
 10 Visão geral das ferramentas de ETL
Como já vimos, o processo de ETL consiste em extrair dados de diversas fontes, trabalhar sobre
esses dados, aplicando validações e modificações para que se adequem às estruturas de dados
de destino e, por fim, armazená-los em um ou mais destinos. Nesse contexto, as ferramentas de
ETL são aplicações cuja finalidade é permitir a execução dessas tarefas da maneira mais simples
e automatizada possível. Mas não pense em uma ferramenta de ETL apenas com a finalidade de
construção de um DW. A utilidade dessas ferramentas pode ser bem ampla. Por exemplo,
poderíamos utilizar esse tipo de ferramenta para carregar os dados de um arquivo de texto em
uma tabela de um banco de dados, para analisar a qualidade dos dados em um sistema ou até
mesmo para manter registros de auditoria.

Nesta Unidade vamos detalhar mais o estudo sobre as ferramentas de ETL. Começamos com um
histórico que nos ajudará a entender as necessidades de negócio que levaram à criação de
aplicações de ETL. Em seguida, vamos listar as gerações de ferramentas de ETL e suas
principais características. Depois apresentaremos a relação das ferramentas mais conhecidas e
utilizadas. Veremos as principais ferramentas de código aberto que você pode obter,
experimentar e utilizar livremente, permitindo assim o aprofundamento de seus conhecimentos.
Na última seção, analisaremos as possíveis implicações de uma organização optar pelo
desenvolvimento próprio de uma solução de ETL.
 11 História do ETL e suas ferramentas
A popularização dos PCs nos anos 1970 trouxe a indesejável consequência de que os dados que
antes residiam em um mainframe agora se encontravam espalhados em vários computadores,
fenômeno que à época foi chamado de ilhas de dados. A partir dessa realidade, surgiu a proposta
de um Sistema de Gerenciamento de Banco de Dados (SGBD) distribuído que pudesse ler e
integrar as diferentes bases de dados em um único local. A necessidade de integrar dados em
SGBDs diferentes fez com que o processo de ETL se tornasse um método padrão para obter
dados de diversas fontes, transformá-los e carregá-los em um destino comum. Foi nesse cenário
que a ideia de ETL ganhou popularidade (SAS, 2020).

Mas, segundo Zode (2008), embora existissem algumas ferramentas, o mais comum era que os
primeiros processos de ETL fossem codificados de forma customizada, ou seja, os
programadores de cada organização escreviam o código específico para suas necessidades.
Esse tipo de solução, além de ser mais difícil e trabalhoso de ser mantido, frequentemente exigia
o uso de diferentes linguagens de programação ou de linguagens de script para realizar as
tarefas de um ETL.

Segundo Hammergren e Simon (2009), o surgimento do ETL está muito ligado ao marketing,
tendo as bases do que hoje conhecemos como data warehousing, desenvolvidas a partir dos
trabalhos de Charles Parlin e Arthur Nielsen, que foram os primeiros a tentar coletar e processar
dados, a fim de fornecer informação sobre desempenho competitivo e market share.

Em 1984 a Teradata lançou comercialmente a primeira versão de seu produto e, em 1986, a

revista Fortune nomeou o Teradata o produto daquele ano. Em 1988, a IBM introduziu o termo
Business Data Warehouse em uma arquitetura que a empresa denominou Business Information
System – EBIS (DEVLIN; MURPHY, 1988).

Na década de 1990, surgiram os primeiros Data Warehouses. As primeiras a adotarem esta

tecnologia (early adopters) foram as empresas nas áreas de telecomunicações, de seguros,
bancos e varejo. Com a publicação do livro Building the Data Warehouse, William (Bill) Inmon
passou a ser conhecido como o “pai do Data Warehouse” (INMON, 1990).
 Figura 18 – Capa do livro Building the
Data Warehouse.

Fonte: abebooks.com
[https://pictures.abebooks.com/isbn/97808
94354045-us.jpg] .

O surgimento dos DWs levou também à introdução de novas soluções de ETL e ao

desenvolvimento de ferramentas para diferentes fontes de dados. Integrações e aquisições entre
empresas e departamentos não raramente levaram organizações a utilizarem concorrentemente
diferentes soluções de ETL não integradas entre si (SAS, 2020).

Logo surgiram as primeiras implementações de ETL e a partir de 1995 a adoção começou a ser
mais significativa. Em 2006, a Microsoft comprou a empresa ProClarity. No ano seguinte, a Oracle
comprou a Hyperion, a SAP adquiriu a Business Objects e a IBM se uniu à Cognos. Assim, as
grandes empresas da área de TI e banco de dados entraram definitivamente no mercado de DW.

De acordo com Ravindra (2019), sistemas tradicionais de ETL apresentam duas características
principais:

foram projetados para extrair e carregar dados primariamente de SGBDs; e

o processo de extrair, transformar e carregar é realizado de maneira intervalada e periódica, através
da execução de rotinas em lote.

Mas esse cenário vem mudando bastante nos últimos anos. Novas necessidades, como a
integração de dados em tempo real, o uso de fontes de dados não estruturados e o crescente
aumento no volume de dados (Big Data) estão expandindo tremendamente as funcionalidades e
as necessidades de escalabilidade das ferramentas de ETL.
Adicione a isso a emergência da Internet das Coisas (Internet of Things - IoT), dos paradigmas
de desenvolvimento ágil e das arquiteturas de microsserviços, em que pequenos componentes,
independentes entre si, são interligados dinamicamente. Esses componentes podem agir tanto
como fonte quanto como destino de dados, e podem ser dinamicamente modificados ou
substituídos. Isso tudo traz mais dinamismo às ferramentas de ETL. Mas antes de abordarmos
essa dinamicidade, vamos primeiro dar uma olhada nas principais gerações das ferramentas de
ETL.
 12 Gerações de ferramentas de ETL
Segundo Zode (2008) e Stonebaker (2014), há três gerações principais de ferramentas ETL (veja
a figura 19). Veremos cada uma delas a seguir com base no trabalho desses autores.

Figura 19 – Gerações de Ferramentas ETL.

Legenda: características das três gerações de ferramentas ETL.

Fonte: elaborada pelo autor.

12.1 Primeira geração

As primeiras ferramentas de ETL eram customizadas pelos programadores das organizações ou

eram soluções que geravam códigos nativos. A grande maioria das ferramentas utilizava código
em linguagem COBOL, pois os dados estavam armazenados em mainframes.

Esse tipo de solução não permitia paralelismo, mas seu desempenho era bom.

As principais vantagens dessa geração foram:

as ferramentas eram eficientes na extração de dados de sistemas legados; e

apresentavam bom desempenho devido ao uso de linguagem nativa.

As principais limitações eram:

exigiam um conhecimento aprofundado de programação nas plataformas utilizadas; e

não suportavam processamento em paralelo.

Segundo Stonebaker (2014), a primeira geração resolveu principalmente a parte T

(Transformação) da sigla ETL.

12.2 Segunda geração

A segunda geração surgiu em meados de 1990 com os primeiros mecanismos de automação do
ETL. Nessa geração as ferramentas de ETL já haviam passado a executar todo o processo de
transformação, desobrigando o programador de ter que conhecer várias linguagens de
programação. O programador agora passa a precisar saber apenas a programação ETL.

Essa geração de ferramentas passou a apresentar um ambiente gráfico, no qual o desenvolvedor

podia desenhar fluxos de execução (workflows) que definiam a forma de processamento dos
dados.

As principais vantagens desta geração foram:

uso de interface gráfica;

abordagem baseada no uso de um motor interno, que interpreta o fluxo do processo de ETL,
melhorando a rapidez e eficiência no desenvolvimento dos processos; e
por utilizarem uma única linguagem de programação, as funções do processo de ETL passaram a ser
altamente integradas e automatizáveis.

As principais limitações eram:

a obrigatoriedade de que todos os fluxos de dados das várias fontes tivessem que passar pelo motor
interno tornou o processo ineficiente para grandes volumes de dados; e
a realização de todas as transformações no motor interno também o tornou um ponto de
estrangulamento no processo.

Segundo Stonebaker (2014), é nessa geração que as funcionalidades são ampliadas,

especialmente com a introdução dos módulos de limpeza e conformidade dos dados e a adição
de adaptadores para trabalhar com muitos tipos de dados novos.

12.3 Terceira geração

As duas principais características da terceira geração foram a criação de uma arquitetura

distribuída e a habilidade em gerar SQL nativo, o que eliminou a necessidade de intermediários
entre a ferramenta de ETL e os sistemas de origem e destino.

A terceira geração, portanto, é aquela em que a carga de processamento pode ser paralelizada e
distribuída, sendo também capaz de usar as funcionalidades do SGBD para as transformações
de dados e outras ações, como a junção de tabelas, por exemplo.

As principais vantagens dessa geração são:

capacidade de lidar com transformações complexas;

capacidade de distribuição da carga de processamento e de explorar os recursos dos SGBDs de forma
eficiente;
 suporte ao paralelismo de dados, de componentes e do fluxo (pipeline);
capacidade de lidar eficientemente com formatos como XML;
oferta de recursos de atualizações incrementais; e
interface gráfica melhorada e com recursos de debugging e versionamento dos fluxos de ETL.

As principais limitações são:

a obrigatoriedade de que todos os fluxos de dados das várias fontes tenham que passar pelo motor
interno pode tornar o processo ineficiente para grandes volumes de dados; e
muitas soluções não suportam a integração dos metadados com ferramentas do usuário final.

Segundo Stonebaker (2014), a terceira geração é projetada para escalar para milhares de fontes
de dados e utilizar métodos estatísticos e de aprendizado de máquina para automatizar muitas
tarefas menos complexas, reduzindo a necessidade de intervenção humana apenas ao essencial.
 13 Ferramentas de ETL mais conhecidas e utilizadas
O mercado das ferramentas de ETL está em amplo crescimento e desenvolvimento. Assim, novas
soluções, arquiteturas e funcionalidades surgem frequentemente. As empresas têm tentado se
diferenciar e oferecer soluções mais abrangentes e, para isso, têm adicionado capacidades como
aprendizado de máquina e inteligência artificial em seus pacotes.

Veremos as principais ferramentas de ETL usadas no mercado. Optamos por listar aqui aquelas
apontadas por Zaidi, Thoo e Heudecker (2019) e SoftwareTestingHelp (2020), por considerar que
tendem a ter um futuro mais duradouro em função de sua maturidade e fatia de mercado que
ocupam.

Algumas empresas podem possuir mais de uma ferramenta que podemos enquadrar na categoria
de ETL. Este é o caso da Oracle, que possui tanto o Oracle Data Integration Platform quanto o
Oracle Warehouse Builder.

A figura 20 apresenta o quadrante mágico do Gartner, classificando as ferramentas, como já

vimos, nas categorias Leader, Challengers, Niche Players e Visionaries.
 Figura 20 – Quadrante Mágico do Gartner para ferramentas de ETL.

Legenda: quadrante mágico do Garner para ferramentas de integração de dados.

Fonte: gartner.com
[https://www.gartner.com/resources/369500/369547/369547_0001.png] .

O quadro 2 apresenta a relação de algumas das principais ferramentas de ETL com o nome do
fabricante, da ferramenta e o link oficial do fabricante para maiores informações (caso o link não
funcione mais, procure localizá-lo pelo Google, ok?).

Quadro 2 – Principais ferramentas ETL.

Fabricante Ferramenta URL

Ab Initio Co>Operating abinitio.com [https://www.abinitio.com/en/system/the-cooperating-

System® system]

Actian Data Connect actian.com [https://www.actian.com/data-integration/dataconnect-

Integration integration/]

Platform

Adeptia Adeptia adeptia.com [https://adeptia.com/products/Adeptia-Connect-

Connect enterprise-integration]
Fabricante Ferramenta URL

Apache Apache NiFi nifi.apache.org [https://nifi.apache.org/]

Foundation

Apache Apache Airflow airflow.apache.org [https://airflow.apache.org/]

Foundation

CloverDX Data cloverdx.com [https://www.cloverdx.com/]

Management

Platform

Denodo Denodo denodo.com [https://www.denodo.com/en/denodo-platform/overview]

Platform

Hevo Hevo Platform hevodata.com [https://hevodata.com/platform/]

Hitachi Pentaho Data hitachivantara.com [https://www.hitachivantara.com/en-

Vantara Integration us/products/data-management-analytics/pentaho-platform/pentaho-

data-integration.html]

IBM IBM InfoSphere ibm.com [https://www.ibm.com/analytics/information-server]

Information

Server

Improvado.io Improvado improvado.io [https://improvado.io/lp/improvado-etlv]

ETLV

Informatica PowerCenter informatica.com [https://www.informatica.com/products/data-

integration/powercenter.html]

Information Omni-Gen informationbuilders.com

Builders [https://www.informationbuilders.com/learn/ibtv/what-omni-gen]

Iri Iri Voracity iri.com [https://www.iri.com/products/voracity]

Matillion Matillion ETL matillion.com [https://www.matillion.com/products/etl-software/]

Microsoft SQL Server microsoft.com [https://docs.microsoft.com/en-us/sql/integration-

Integration services/sql-server-integration-services]

Services
 Fabricante Ferramenta URL

Oracle Oracle oracle.com [https://www.oracle.com/application-

Warehouse development/technologies/warehouse/warehouse-builder.html]

Builder

Qlik Attunity qlik.com [https://www.qlik.com/us/products/qlik-replicate]

Replicate

SAP SAP Data sap.com [https://www.sap.com/products/data-services.html]

Services

SAS SAS® Data support.sas.com [https://support.sas.com/en/software/data-

Integration integration-studio-support.html]

Studio

Skyvia Data skyvia.com [https://skyvia.com/data-integration/]

Integration

SnapLogic Intelligent snaplogic.com [https://www.snaplogic.com/products/intelligent-

Integration integration-platform]

Platform

Syncsort Connect ETL syncsort.com [https://www.syncsort.com/en/products/connect-etl]

Talend Talend Open talend.com [https://www.talend.com/products/talend-open-studio/]

Studio

TIBCO TIBCO tibco.com [https://www.tibco.com/products/tibco-businessevents]

Software BusinessEvents

Xplenty Xplenty xplenty.com [https://www.xplenty.com/is/]

Platform

Fonte: elaborado pelo autor.

Além das ferramentas citadas no quadro 2, há diversas outras soluções disponíveis no mercado.
As possibilidades de conexão com centenas de diferentes tipos de fontes de dados fazem com
que a maioria das ferramentas consiga trabalhar com praticamente qualquer origem de dados.

Muitas das soluções apresentadas na tabela possuem mais de uma forma de utilização, variando
de aplicações que devem ser instaladas localmente (Apache Flow, Pentaho Kettle), passando por
soluções híbridas (Talend Open Studio, Microsoft SQL Server Integration Services) e terminando
em ferramentas que são 100% na nuvem (Xplenty Platform, Skyvia Data Integration, Improvado
ETLV).

Assista ao vídeo Apresentação Criação de Data Warehouse com Talend Data Integration ETL Parte
1, que mostra na prática o uso da ferramenta Talend, no link: youtube.com
[https://www.youtube.com/watch?v=9MWoYsz4258] .

Videoaula - Ferramentas gratuitas

Escaneie a imagem ao lado com um app QR code para assistir o vídeo ou clique aqui
[https://player.vimeo.com/video/475206201] .
Videoaula - Talend

Escaneie a imagem ao lado com um app QR code para assistir o vídeo ou clique aqui
[https://player.vimeo.com/video/475216022] .

Videoaula - Pentaho (Parte 1)

Escaneie a imagem ao lado com um app QR code para assistir o vídeo ou clique aqui
[https://player.vimeo.com/video/475210269] .
Videoaula - Pentaho (Parte 2)

Escaneie a imagem ao lado com um app QR code para assistir o vídeo ou clique aqui
[https://player.vimeo.com/video/475212340] .

Videoaula - JasperSoft

Escaneie a imagem ao lado com um app QR code para assistir o vídeo ou clique aqui
[https://player.vimeo.com/video/475214299] .
 14 Ferramentas de ETL de código aberto
Praticamente todas as soluções comerciais apresentadas anteriormente possuem versões
gratuitas com períodos de avaliação que variam entre 30 e 90 dias. No entanto, após esse
período será necessário comprar ou licenciar o uso do produto. Assim, vamos apresentar aqui as
principais ferramentas de código aberto e uso livre, inclusive comercial, e que não possuem
custos de licenciamento.

Com exceção do Apache Airflow, todas as demais possuem modelos de licenciamento duplo e
suas versões pagas incluem ferramentas adicionais e suporte comercial por parte dos
fabricantes.

A principais ferramentas ETL de código aberto (cujas versões open source podem ser obtidas
diretamente no site da empresa) são:

Talend Open Studio: primeira ferramenta de código aberto, surgiu em 2006, e é uma das mais
conhecidas e utilizadas. Suporta tanto ETL, quanto ELT, e uma ferramenta de orquestração do fluxo de
dados muito robusta. Possui um módulo Data Quality que permite medir a qualidade e integridade
dos dados.

Figura 21 – Logotipo da Talend Open

Studio

Fonte: es.talend.com
[https://es.talend.com/resources-browse/?
type=article] .

Hitachi Vantara Pentaho: é uma solução de BI. A ferramenta Kettle, sigla recursiva de Kettle Extration
Transformation Transport Load Environment, foi desenvolvida em Java, e permite a criação de fluxos
de ETL através de uma interface gráfica simples, intuitiva e muito poderosa.

Figura 22 – Logotipo da Pentaho.

Fonte: xpand-it.com [https://www.xpand-

it.com/pentaho-webinar-2018-expert-
sessions/] .
Jaspersoft ETL: ferramenta da TIBCO, tem a versão de código aberto baseada no Talend, o que torna
as duas soluções muito similares.

Figura 23 – Logotipo da Jaspersoft ETL.

Fonte: docs.tibco.com
[https://docs.tibco.com/pub/js-
jrs/6.1.2/doc/pdf/JasperReports-Server-
Admin-Guide.pdf] .

DataCleaner Community Edition: focado primariamente na análise e melhoria da qualidade dos

dados, o DataCleaner é baseado em Java e executa como uma aplicação.

Figura 24 – Logotipo DataCleaner

Community Edition.

Fonte: itqlick.com
[https://www.itqlick.com/datacleaner/prici
ng] .

Apache Airflow: plataforma de código livre focada na execução de fluxos de trabalho agendados
como tarefas DAG (Directed Acyclic Graphs). As tarefas são criadas através de scripts codificados
utilizando a linguagem Python e um escalonador é responsável por executá-las em um ou mais nós
de processamento (workers).

Figura 25 – Logotipo Apache Airflow.

Fonte: apache.org
[https://apache.org/logos/] .
O Developer Edition do Microsoft SQL Server oferece uma versão completa de solução que inclui
o módulo de ETL Integration Services, disponibilizada gratuitamente para todos os membros do
programa Visual Studio Dev Essentials, cuja inscrição pode ser feita no site da empresa. Além do
SQL Server Integration Services, estão também disponíveis gratuitamente o Business Intelligence
do SQL Server e o Power BI. Obviamente, essas versões não podem ser utilizadas
comercialmente, mas podem ser uma grande fonte de aprendizado a você, estudante.

Videoaula - Apache Kafka

Escaneie a imagem ao lado com um app QR code para assistir o vídeo ou clique aqui
[https://player.vimeo.com/video/475222076] .
 15 Solução de ETL customizada × Ferramenta de mercado
Ao chegar até aqui, você já deve ter uma ideia dos desafios que a construção de um ETL impõe.
Além da gama de fontes de dados que podemos ter a necessidade de suportar, será necessário
implementar também as tarefas de limpeza, conformidade, agregação e transformação dos
dados e criar mecanismos para que sejam colocados em seus destinos finais.

Pode ser que alguma dessas funcionalidades não seja necessária, ou talvez possamos optar por
implementar apenas um ou outro módulo, utilizando uma ferramenta já existente para as demais
tarefas, criando assim um modelo personalizado híbrido.

Para auxiliar nessa decisão, Tanzer (2019) sugere inicialmente que as seguintes questões sejam
respondidas:

1. Quais são as principais necessidades de negócio que deverão ser atendidas?

2. Quais são as necessidades de negócio que você gostaria de ter atendido, mas ainda não conseguiu?
3. Você terá tempo suficiente para construir e testar o seu próprio ETL? E este será capaz de acompanhar o
crescimento da organização e suas demandas?
4. Quanto se espera economizar desenvolvendo a solução internamente em comparação com a aquisição ou
licenciamento de uma ferramenta pronta?
5. Optando por uma solução pronta, qual o seu grau de aderência às necessidades de negócio atuais e
futuras e quais serão os custos estimados para a sua implantação e configuração?

Obviamente a decisão entre utilizar uma ferramenta pronta ou desenvolver internamente não é
uma escolha trivial, e a sua análise deverá levar em consideração diversos outros aspectos.
Alguns outros pontos que devem ser considerados incluem:

cultura da empresa;
maturidade e a capacidade do time de desenvolvimento;
quantidade e heterogeneidade das fontes de dados;
sistemas e tecnologias existentes e planejadas;
complexidade da transformação de dados que será exigida;
volume de dados estimado;
estratégia de segurança da informação; e
suporte e treinamento necessário.

Tanzer (2019) aponta as seguintes vantagens de cada abordagem:

Vantagens de se desenvolver internamente:

maior flexibilidade: ferramentas prontas podem apresentar limitações de representação de
dados ou funcionalidades. Sistemas codificados de forma customizada podem ser adaptados
mais facilmente para qualquer tipo de metadado;
controle e visibilidade totais: você sabe exatamente o que está sendo feito com os dados e tem
controle total sobre o fluxo; e
pode ter uma melhor relação custo-benefício: se apenas alguns módulos são necessários,
programar apenas esta parte pode ser mais barato do que a aquisição de uma ferramenta
 completa.
Vantagens de se adquirir uma ferramenta pronta:
economia: o uso de uma solução pronta elimina o tempo e esforço que seria empregado na
sua construção;
o custo é justificado: a solução de ETL será mais simples e rápida, mostrando resultados em
um prazo menor; e
o fluxo de dados e a escalabilidade são gerenciados: uma solução pronta terá mais
mecanismos de validação e tratamento de falhas e tende a apresentar menos problemas de
escalabilidade do que uma solução caseira.

Videoaula - Power BI

Escaneie a imagem ao lado com um app QR code para assistir o vídeo ou clique aqui
[https://player.vimeo.com/video/475192189] .
Videoaula - Processo de plotagem com o uso de Power BI

Escaneie a imagem ao lado com um app QR code para assistir o vídeo ou clique aqui
[https://player.vimeo.com/video/475217936] .
 Exercícios de fixação
Assinale a alternativa que preenche corretamente a lacuna.
“Foi apenas a partir da ______ geração que as ferramentas de ETL começaram a suportar o
paralelismo de processamento, aumentando em muito as possibilidades de processamento de
dados.”

1ª.

2ª.

3ª.

4ª.

NÃO é uma solução de ETL de código aberto a ferramenta:

Talend Open Studio.

Hitachi Vantara Pentaho.

Jaspersoft ETL.

Qlik Attunity Replicate - Carregamento Inicial.

Assinale a alternativa que provavelmente irá representar uma vantagem de se desenvolver uma
solução de ETL internamente.

Maior flexibilidade.

Maior escalabilidade.

Maior economia.

Maior tempo de processamento.

 RECAPITULANDO

Nesta Unidade nos dedicamos exclusivamente ao estudo das ferramentas de ETL.

Começamos apresentando um histórico do surgimento desse tipo de ferramentas. Em
seguida, apresentamos as gerações de ETL e suas soluções. Listamos as ferramentas
mais conhecidas e utilizadas e mostramos como algumas delas são classificadas de
acordo com o quadrante mágico do Gartner. Depois destacamos as ferramentas de
código aberto que você poderá utilizar livremente sem ter de arcar com custos de
compra ou licenciamento.

Ao final, elencamos alguns questionamentos que idealmente devem ser respondidos

caso a organização esteja pensando em desenvolver uma ferramenta de ETL própria. As
vantagens e desvantagens dessa abordagem em relação ao uso de uma solução
comercial pronta também foram citadas.
 16 Modelos de integração de dados
Em muitos cenários de negócio atuais, não é mais aceitável o uso do modelo de integração de
dados em lote, conhecido como modelo tradicional de ETL, no qual o processo é executado em
intervalos regulares e durante períodos de menor carga no sistema, como durante a madrugada.
As pressões ou necessidades de negócio simplesmente não podem esperar até o próximo dia
para ter os resultados da operação em um departamento ou sistema.

Para lidar com essa nova necessidade, as ferramentas de ETL evoluíram para fornecer soluções
de integração de dados em tempo real.

Nesta Unidade apresentaremos o modelo em lote e discutiremos em mais detalhes os principais

conceitos envolvidos em uma integração em tempo real. Após apresentarmos o modelo de
integração em lote, introduziremos o modelo em tempo real e faremos uma comparação do
modelo de integração em lote com o modelo em tempo real. Em seguida, apresentaremos uma
separação dos metadados em três categorias, focando na definição do conceito de um Modelo
de Dados Canônico que possivelmente terá de ser desenvolvido e nas opções de gerenciamento
de dados mestres. Depois, abordaremos as principais tecnologias e arquiteturas que são
utilizadas comumente em integrações em tempo real. Por último, falaremos sobre as
tecnologias, arquiteturas ou estratégias comumente adotadas pelas organizações para a
operacionalização desse tipo de demanda.
 17 Integração de Dados em Lote (Batch)
Tradicionalmente, o modelo mais comum de integração entre sistemas tem sido a troca ou
transmissão de um grande arquivo de dados de um sistema para outro. Essa troca é realizada
em períodos intervalares, como diariamente, semanalmente, mensalmente etc. Esse arquivo
contém registros cujos conteúdo e formato são conhecidos e previamente acordados entre as
partes.

Esse processo é chamado de modo em lote porque os dados são agrupados (batched) em um
único arquivo e o lote inteiro é enviado de uma só vez. O modelo em lote contrasta com o de
tempo real, no qual, em geral, cada registro é enviado individualmente. A figura 26 apresenta um
diagrama mostrando o fluxo padrão de uma integração de dados em lote.

Figura 26 – Processo ETL com integração em lote.

Legenda: diagrama ETL para processamento em lote.

Fonte: d1x2i8adp1v94i.cloudfront.net [https://d1x2i8adp1v94i.cloudfront.net/wp-
content/uploads/2012/12/ETL_input_output.jpg] .

Esse é o tipo de abordagem mais indicado para integrações de arquivos de dados muito grandes.

A definição do escopo envolve inicialmente o mapeamento dos requisitos e um projeto de alto

nível para determinar se a integração de dados em lote é a solução mais apropriada.

O ciclo de vida para o desenvolvimento de uma interface de integração de dados em lote

geralmente envolve três fases:

1. especificação dos atributos dos dados;

2. criação do perfil de dados; e
3. validação e atualização periódica dos atributos e do perfil de dados.
Até pouco tempo atrás, a especificação inicial dos dados tinha como ponto de partida o
entendimento de quais atributos deveriam ser preenchidos no destino, e só depois eram
mapeados os atributos que precisariam ser extraídos na origem. Isto é, procurava-se saber que
tipos de informações, relatórios, análises ou dados operacionais seriam necessários no destino
para, só então, definir as informações que seriam coletadas e enviadas. Mas o surgimento de
técnicas como a mineração de dados, o desenvolvimento das redes neurais e a criação de novos
algoritmos, como o MapReduce, fizeram com que a definição de atributos fosse invertida. Assim,
primeiro se buscava entender que tipos de informações poderiam ser encontradas nas fontes e
só depois seria definido como os dados seriam armazenados e processados no destino.

Uma vez que os dados tenham sido especificados, também é essencial definir o perfil dos dados
reais nas estruturas de dados de origem e de destino. A criação de um perfil de dados de
produção é crucial para entendermos que dados precisarão ser considerados e em quais fontes
os atributos apropriados serão encontrados. A criação desse perfil irá envolver a compreensão
de como os dados realmente se parecem, incluindo aspectos de exclusividade, densidade
(valores nulos ou vazios), formato e valores válidos.

O perfil de dados, além do seu valor comercial, é fundamental para a especificação da

transformação necessária nos dados. A conversão de um dado de seu formato de origem para o
destino irá exigir uma combinação de conhecimentos técnico e de negócios. Portanto, é
importante que os responsáveis pelas áreas comercial e de tecnologia revisem e concordem com
o projeto especificado da transformação de dados, com base em suas necessidades e no perfil
de dados de produção elaborado.

Criado o perfil de dados, é recomendado que seja definida uma forma de validação ou
comprovação periódica de que os dados dos sistemas de origem estão de acordo com o que foi
passado aos sistemas de destino, isto é, que a transformação está ocorrendo de acordo com o
que foi planejado e definido.

17.1 Criação do perfil de dados

O processo de criação de perfil de dados, também conhecido como avaliação de dados,

descoberta de dados ou análise da qualidade de dados, refere-se ao processo de examinar,
analisar e criar resumos úteis de dados (PEARLMAN, 2019).
Em um artigo da revista Harvard Business Review, os professores Tadhg Nagle, Thomas Redman
e David Sammon publicaram os resultados de um estudo envolvendo 75 executivos e
descobriram que apenas 3% dos dados das organizações em que atuavam atingiram os
requisitos básicos do que os professores consideravam como de qualidade aceitável, mesmo
utilizando o padrão mais baixo possível de qualidade. Thomas Redman, em outro estudo, revela
que essa baixa qualidade de dados representava, apenas nos EUA, uma perda estimada de US$
3,1 trilhões.

Leia mais em: hbr.org [https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-

standards] .

A criação de perfil de dados se refere, portanto, ao ato de examinarmos os dados disponíveis em

uma fonte de dados, coletar estatísticas e informações sobre eles, visando a definir o quão
completos e bons esses dados são para representar a realidade. Nesse processo, devemos
também estar atentos e buscar identificar registros duplicados, dados inconsistentes ou
faltantes, informações ambíguas e a frequência de cada uma dessas ocorrências.

Uma boa qualidade de dados é fundamental, pois dados com baixa qualidade poderão,
irremediavelmente, levar a más decisões de negócio.

A criação de perfil deve ser executada quando dados em potencial para uma extração forem
identificados por meio da coleta de requisitos de alto nível.

É fundamental para o sucesso do projeto que a criação de perfil não seja ignorada e que as
diferenças entre o que era esperado e os dados encontrados nas fontes seja criteriosamente
analisada e discutida a fim de, entre outros, evitar atrasos inesperados no projeto.

Assista ao vídeo Alteryx Visualytics Demo, que ilustra como uma ferramenta de software pode ser
usada no processo de criação do perfil de dados e melhoria da sua qualidade. Acesse em:
.youtube.com [https://www.youtube.com/watch?v=tidXV_r6ht0] .
 18 Modelo de integração de dados em tempo real
Como dissemos, as ferramentas de ETL evoluíram para fornecer soluções em tempo real (real
time) ou próximo ao real (near real time).

Soluções de tempo real: envolvem o emprego de alguma técnica de fluxo (streaming) de dados em um
modelo baseado em eventos. Um evento representa uma ação importante ocorrida em algum sistema
e que precisa ser capturada e tratada pelo processo de integração em tempo real.
Soluções de tempo próximo ao real: refletem cenários em que a atualização dos dados em um Data
Mart ou Data Warehouse ocorre em questão de alguns minutos, geralmente não ultrapassando 1 hora.

A figura 27 apresenta o exemplo de uma solução de ETL que processa eventos em tempo real;
cada evento irá gerar um job de ETL específico, e mais de um job pode estar em execução ao
mesmo tempo.

Figura 27 – Solução de ETL em tempo real.

Legenda: exemplo de um fluxo de ETL em tempo real.

Fonte: netdna-ssl.com [https://3l0wd94f0qdd10om8642z9se-wpengine.netdna-
ssl.com/wp-content/uploads/2019/12/29_StreamingETL-800x377.png] .
 19 Integração em tempo real × integração em lote
Em uma integração em tempo real, o conjunto de dados que representa uma interação no
sistema é chamado de mensagem. Da mesma maneira que ocorre no modelo em lote, na
integração em tempo real cada mensagem irá passar pelos mesmos processos de análise,
transformação, validação e segurança dos dados. Mas como isso ocorre sobre um conjunto
menor de dados, a integração em tempo real tende a ser mais lenta do que o modelo em lote para
um mesmo conjunto de dados. Assim, a integração em tempo real geralmente impõe limitações
mais severas em relação à quantidade ou ao volume de dados que poderão ser processados.

A interação entre aplicações em tempo real é, na maioria das vezes, realizada através de
interfaces entre a aplicação e o processo de ETL. Assim, em vez de os dados de diversas
aplicações serem obtidos diretamente de uma API ou SGBD em períodos de menor atividade,
pode ser necessária a construção, ou o ajuste, de diversas interfaces nos sistemas da empresa
para permitir a integração em tempo real.

Segundo Reeve (2013), a tecnologia para lidar com a integração de dados em tempo real é mais
complexa que a integração de dados em lote. As atividades básicas de extrair, transformar e
carregar estão presentes, mas são ajustadas para lidar com dados em um modelo de mensagens
individuais. As regras e o modo de processamento também terão de ser ajustados para esse
novo cenário. Mas então precisaremos ter dois conjuntos de regras e talvez até ferramentas
diferentes para lidar com a integração em lote e em tempo real? Não podemos utilizar o conjunto
de regras e ferramentas da programação em tempo real para lidar com dados em lote ou vice-
versa? Infelizmente, na maioria das vezes, não. E há dois motivos principais para isso:

1. se a integração em lote já existir, as interfaces com as fontes de dados já estarão estabelecidas, ou seja, já
foram definidas, implementadas, validadas e estão em uso. Trocar essas interfaces pode representar um
custo elevado; e
2. mesmo se o custo não for um fator impeditivo, o segundo motivo se refere ao fato de que é pouco provável
que uma interface que trabalha com mensagens para integração em tempo real apresente um
desempenho satisfatório ao lidar com grandes volumes de dados, como ocorre no modelo em lote. A
integração de dados em tempo real é inerentemente mais lenta porque cada mensagem trocada,
geralmente via alguma API, tem de passar por todo o fluxo de maneira individualizada.

Assim, a maioria das organizações opta por ter dois conjuntos de ferramentas e regras: uma para
as integrações em lote e outra para o cenário de tempo real. Obviamente um mesmo processo
não utilizará os dois conjuntos, o que a organização irá fazer é utilizar a ferramenta apropriada
para cada tarefa ou sistema.

Segundo Kimball et al. (2008), em alguns cenários as ferramentas de integração em lote poderão
fazer análises e transformações adicionais nos dados processados em tempo real, quando
apropriado.
 20 Modelos de dados para integração em tempo real
Na integração de dados em lote ou tradicional durante a etapa de transformação, em geral, há
uma avaliação em relação à qualidade dos dados. Em muitos casos, se a qualidade não atingir o
limiar mínimo definido pela organização, pode ser que o processo de ETL seja interrompido até
que essa pendência seja sanada. E isso poderá envolver, inclusive, uma intervenção humana ou
correção manual das informações.

Já em um cenário de integração em tempo real, devemos procurar ter o mínimo de interrupções

no processo, pois a disponibilidade quase que instantânea dos dados em um DW ou DM é uma
necessidade do negócio. Assim, uma estratégia frequentemente adotada pelas empresas é a
definição de um Modelo de Dados Canônico ou a utilização de algum mecanismo de
gerenciamento de dados mestres.

Embora estejamos focando aqui a integração de dados em tempo real, o modelo de dados
também é válido e deveria ser implementado na integração de dados em lote. Entretanto, no
modelo em tempo real a definição de dados mais precisa se torna essencial.

20.1 Metadados

Os metadados associados à integração de dados em tempo real são praticamente os mesmos

da integração de dados em lote. Em geral, eles são categorizados em três tipos: de negócio,
técnicos e operacionais, assim definidos:

metadados de negócio: incluem as definições de negócios dos dados. Como exemplo podemos citar
as definições de segurança de acesso, ou seja, quais dados podem ser transmitidos ou visualizados
por quais aplicações e usuários. É nessa categoria que estarão também as regras de negócio da
organização;
metadados técnicos: incluem os modelos lógicos e físicos e o layout dos dados de origem, dados de
destino e modelo canônico intermediário. Também incluem as transformações e mapeamentos entre
os modelos de origem e destino, incluindo quais dados devem ser monitorados e o que fazer quando
um evento relevante ocorre; e
metadados operacionais: são aqueles gerados a partir da execução da integração de dados em tempo
real. Fornecem informações da construção dos dados, ou seja, quando eles foram gerados ou
alterados. Os metadados operacionais também fornecerão informações sobre quem alterou e acessou
os dados e quando essa alteração ocorreu. Esses dados são muito valiosos para usuários corporativos
e técnicos, além de auditores.
Assista ao vídeo What is Metadata?, que ilustra o conceito de metadados, no link: youtube.com
[https://www.youtube.com/watch?v=HXAstVP3-y0] .

A definição e separação dos diferentes tipos de metadados deve ser o primeiro passo na
construção de uma integração de dados em tempo real. Quando pensamos em uma solução que
estará integrando dados de maneira automática e contínua, ter os metadados operacionais bem
definidos será fundamental para que possamos saber se as engrenagens estão funcionando
conforme o esperado ou não.

20.2 Modelo de Dados Canônico

Como já vimos, é comum uma organização possuir vários sistemas e aplicações para suportar o
negócio. E muitos desses sistemas irão armazenar e lidar com dados que se referem a uma
mesma entidade. Por exemplo, os conceitos de cliente, produto e vendas poderão existir em
diversos sistemas.

Considerando que um mesmo cliente pode estar em mais de uma base de dados ou sistema da
organização, em uma integração de dados, o ideal é que consigamos combinar as informações
desse cliente. Identificar um mesmo cliente em diferentes sistemas organizacionais e agrupar as
suas interações, compras, perfil e interesses pode ser um diferencial competitivo importante.
Mas pelo fato de os sistemas serem diferentes, em praticamente todos os casos o conjunto de
dados que são armazenados e processados em cada sistema também será divergente. Assim, ao
pensarmos em uma integração, precisaremos criar uma visão unificada de cada uma dessas
entidades (clientes, produtos, ofertas etc.), definindo suas características e criando uma espécie
de “modelo padrão da organização” para aquela entidade. Esse modelo de dados é o que
chamamos Modelo de Dados Canônico. Ele não precisa cobrir necessariamente todos os dados
da organização, apenas aquelas informações que precisam ser integradas e/ou compartilhadas.

Para uma organização, o modelo de dados canônico significa documentar detalhadamente todos
os termos, entidades e itens importantes ao negócio. Cada termo será apropriadamente definido
e os relacionamentos entre os termos mapeados.

Em relação à integração de dados, o modelo canônico pode ser entendido como um modelo
virtual e sua implementação pode ocorrer através da definição de um ponto central (hub), que
pode ser usado como mecanismo de passagem entre todas as interfaces entre os sistemas da
organização.

O modelo de dados canônico deve ser extenso o suficiente para incorporar todos os dados da
organização que serão compartilhados entre os seus sistemas.

20.3 Gerenciamento de dados mestres

Uma vez estabelecido um entendimento comum e unificado do que representa um cliente,

produto etc., o próximo passo na integração de dados pode ser a definição de uma forma de
gerenciamento centralizado e corporativo dessas entidades.

O Gerenciamento de Dados Mestres ou Master Data Management (MDM) é uma arquitetura

desenvolvida para gerenciar o conjunto principal de dados da organização em áreas importantes,
como clientes, produtos e estrutura organizacional. Chamamos essas informações de dados
mestres porque esses elementos são em geral os itens mais importantes nos dados
transacionais da organização.

Assista ao vídeo Master Data Management, que ilustra o conceito de Master Data Management,
no link: youtube.com [https://www.youtube.com/watch?v=JF4mUqyoRFg] .

Ferramentas de MDM incorporam regras para remover dados duplicados ou incorretos e

padronizar as informações e representações, fornecendo informações mais precisas de maneira
integrada e uma visão unificada dos dados entre os diversos canais e sistemas organizacionais.

Portanto, é extremamente importante que as informações sobre os dados mestres estejam

corretas e que todas as partes da organização trabalhem com a mesma versão dos dados
mestres. Por exemplo, se um cliente alterar seu endereço em um sistema, essa mudança deverá
se refletir nos demais. Obrigar o usuário a alterar a mesma informação em mais de um sistema
de uma mesma organização é algo que, convenhamos, na maioria das vezes não faz sentido.

Se a organização tiver dúvidas sobre a viabilidade e as vantagens de se ter um gerenciamento

centralizado desses elementos, uma análise dos custos associados a inconsistências,
atualização e erros anteriores provavelmente deixará claro que haverá benefícios e economia na
utilização de um conjunto de dados centralizado.

As organizações em geral implementam soluções MDM para ter uma visão consolidada dos
dados mestres para fins de relatório e transação. A figura 28 apresenta o exemplo de um
diagrama MDM, em que cada aplicação possui seu repositório de dados e o MDM é o ponto
comum responsável em centralizar e unificar as visões.

Figura 28 – Diagrama de um Master Data Management.

Fonte: 5.imimg.com [https://5.imimg.com/data5/JS/OD/GLADMIN-

6928638/master-data-management-mdm-500x500.jpg] .

A arquitetura de uma solução de MDM é muito semelhante à arquitetura hub-and-spoke que

veremos adiante. A diferença é que o modelo de dados no MDM em geral também armazena os
dados, ao passo em que o modelo hub-and-spoke representa apenas uma forma comum de
passagem de dados.

O gerenciamento de dados mestres não requer necessariamente a implementação de um

aplicativo separado. O primeiro passo pode ser a determinação de uma aplicação já existente,
que será utilizada como mestre para os dados de um domínio ou entidade.

Segundo Reeve (2013), uma vez definido o local onde os dados mestres ficarão, todos os demais
locais serão considerados como “escravos” e a habilidade de realizar atualizações diretamente
pode ser desabilitada nos sistemas escravos.

Como pode haver dificuldades em alterarmos um sistema existente para se tornar o mestre, na
prática a criação ou utilização de uma aplicação separada é o modelo habitualmente mais
adotado.

Existem dois tipos de soluções de gerenciamento de dados mestres. São eles:

1. o primeiro modelo fornece um registro de informações de dados mestres e referências de onde eles estão
localizados. Ou seja, o registro das informações não armazena necessariamente todos os dados mestres,
mas apenas um ponteiro para onde eles estão localizados; e
2. o segundo modelo é aquele que fornece um armazenamento de dados onde todos os dados mestres são
copiados e mantidos centralizados. Nesse caso, o sistema MDM não fornece apenas uma referência
cruzada às fontes de dados mestres, mas também uma cópia dos dados e é o sistema de registro desses
dados. Alguns autores dizem que, nesse tipo de abordagem, o MDM fornece e mantém a “cópia de ouro”
dos dados, ou seja, a melhor versão existente desses dados na organização.
 21 Padrões para integração de dados em tempo real
Aqui vamos abordar os principais padrões que podem ser utilizados em uma integração de
dados em tempo real, ou seja, como os diversos sistemas da organização poderão enviar e
receber dados para implementar a troca de mensagens em tempo real.

Em relação ao acoplamento entre as aplicações e o processo de ETL, devem ser consideradas as

melhores práticas de projeto de interfaces, que estabelecem que a conexão deve ser o mais
fracamente acoplada (loosely coupled) possível, pois:

devemos evitar que a integração de um determinado sistema com o DW seja construída sobre uma
interface que funciona apenas para essa função ou na qual o fluxo de determinada rotina no sistema
considera a troca de dados com o DW;
ajudará a lidar com falhas, uma vez que se não houver dependências entre os sistemas, a falha ou
indisponibilidade em um deles não irá afetar a disponibilidade do outro. Por exemplo, se parte do
fluxo de uma venda incluir o envio com sucesso de uma mensagem para uma ferramenta de ETL,
uma falha nesse envio irá afetar o fluxo de venda, o que é indesejável; e
podemos mais facilmente substituir um dos sistemas sem a necessidade de alterar outros, uma vez
que os sistemas são independentes entre si.

Os padrões que vamos apresentar a seguir são aqueles que, segundo Reeve (2013), têm
apresentado maiores vantagens em relação ao desenvolvimento de interfaces específicas.

21.1 Modelo ponto a ponto e modelo hub-and-spoke

Um padrão que facilita muito a integração de dados é o modelo conhecido como hub-and-spoke.
Segundo Russom (2008), esta é a arquitetura mais adotada em uma integração em tempo real.
Mas o que é esse modelo?

Para apresentá-lo, vamos primeiramente falar de seu antagonista, o modelo ponto a ponto.
Tradicionalmente, as interfaces são projetadas em um modelo ponto a ponto, no qual cada
sistema interage diretamente com outro sistema com o qual queira compartilhar dados. Dessa
forma, sempre que dois sistemas precisarem trocar dados, uma interface entre eles precisará ser
definida e, possivelmente, construída.

Agora imagine se houver muitos sistemas e diversas trocas de informações entre eles. Como
você já deve ter notado, mesmo com um número não muito grande de sistemas, a quantidade de
interfaces pode logo se tornar um problema.

Para melhor elucidar, vamos imaginar que cada sistema possua uma interface com todos os
demais. Nesse caso, o número de combinações possíveis para n sistemas será (n+(n-1))/2.
Assim, para 10 sistemas seriam necessárias ((10*9)/2)=45 interfaces. Já para 20 sistemas
precisaríamos de ((20*19)/2)=190 interfaces. Como você pode notar, esse número logo se
tornará impraticável. Lógico, nem todo sistema precisa ter interface com todos os demais, mas
mesmo assim esse número pode ser tornar muito grande muito rapidamente.

A figura 29 apresenta um exemplo da arquitetura ponto a ponto em contraposição a um modelo

hub-and-spoke.

Figura 29 – As arquiteturas ponto-a-ponto e hub-and-spoke.

Demonstração do número de conexões nas arquiteturas ponto a ponto (à esquerda) e hub-and-spoke (à

direita).
Fonte: download.101com.com [http://download.101com.com/pub/TDWI/Images/WW25_Figure8901a.gif] .

Na figura 29, o diagrama à esquerda mostra um arranjo de 66 interfaces que integram 12

sistemas (alguns usuários chamam a arquitetura ponto a ponto pelo nome carinhoso de
“espaguete” ... por que será?). Já o diagrama à direita mostra os mesmos 12 sistemas
organizados no modelo hub-and-spoke (nada de espaguete, certo?).

No padrão hub-and-spoke, o layout dos dados da organização é mantido no hub, sendo uma
estrutura que se aproxima de forma ideal do modelo de dados canônico que discutimos
anteriormente. Cada sistema que desejar trocar informações deverá transformar seus dados do
formato que usa internamente para o layout do hub. Note que o hub não é um repositório de
dados, ou seja, os dados não necessariamente serão armazenados nele. O hub define apenas o
formato comum.

Há implementações desse modelo, como o Enterprise Service Bus, em que os dados podem ser
temporariamente armazenados no hub. Mas, do ponto de vista de sua aplicabilidade, o hub não
precisa sequer existir fisicamente. Se os dados forem transformados no formato comum
estabelecido, poderíamos implementar esse modelo enviando as mensagens diretamente entre
as aplicações.
A vantagem dessa abordagem é que a adição de um novo sistema não implicará na codificação
de diversas interfaces específicas. Apenas mais uma interface com o hub deverá ser definida.
Assim, o crescimento no número de interfaces é linear.

Como você já deve ter percebido, o formato de dados definido pelo hub é crítico nessa
arquitetura. Esse formato deverá ser muito bem pensado e estudado para suportar todas as
interfaces de dados da organização. Por isso mesmo, a definição do modelo canônico ou de
outro a ser utilizado pelo hub costuma ser a parte mais difícil para uma integração efetiva.

21.2 Modelo Pedido-Resposta e Modelo Publicar-Assinar

O próximo ponto que devemos considerar se refere à forma como os sistemas trocam as
mensagens em uma integração. Há duas arquiteturas principais nessa categoria: os modelos
Pedido-Resposta (Request-Reply) e Publicar-Assinar (Publish-Subscribe).

O modelo padrão de interação é o Pedido-Resposta. Neste modelo um sistema envia uma

mensagem para outro e espera uma resposta. A comunicação pode ser síncrona, quando quem
enviou a mensagem fica parado até que receba a resposta, ou assíncrona, quando o sistema que
enviou o pedido não espera por uma resposta para seguir adiante. A figura 30 apresenta um
exemplo desse tipo de interação.

Figura 30 – Exemplo do Modelo Pedido-Resposta (Request-Reply).

Fonte: learning.oreilly.com [https://learning.oreilly.com/library/view/managing-

data-in/9780123971678/images/F000121f12-04-9780123971678.jpg] .

Outra forma de interação muito utilizada é o modelo Publicar-Assinar. Neste modelo, os

sistemas declaram seu interesse, ou seja, realizam a assinatura, para receber determinado tipo
de mensagem. Os sistemas que produzem as informações irão então, sempre que um evento
ocorrer, “publicar” as mensagens, isto é, enviá-las para a rede de “assinantes”.
A figura 31 mostra um exemplo do modelo Publicar-Assinar.

Figura 31 – Exemplo do Modelo Publicar-Assinar (Publish-Subscribe).

Legenda: exemplo de uma troca de mensagens no modelo Publicar-Assinar (Publish-Subscribe).

Fonte: realtimeapi.io [https://realtimeapi.io/wp-content/uploads/2017/09/pubsub-1.png</a>.] .

O controle do envio e o controle de se o assinante possui permissão para receber a mensagem

podem ser realizados tanto pelo processo que gera a publicação como por um sistema
totalmente separado, conhecido comumente como middleware, que é responsável pela
orquestração entre quem publica e quem assina. Esse middleware pode se apresentar em
diferentes níveis de integração.

Um middleware é uma classe de software independente de aplicação e que fornece meios de se

capturar, rotear e executar mensagens de transações entre aplicações. Em geral, utilizamos
conectores ou adaptadores para conectar as aplicações participantes na rede de integração, e
módulos intermediários (brokers) são utilizados para rotear as mensagens de acordo com as
regras de publicação e assinatura.
 22 Tecnologias e arquiteturas para integração em tempo real
Além de nos preocuparmos com os modelos de dados, de arquiteturas e de trocas de mensagens
de sistemas, a criação de um DW com integração de dados em tempo real pode envolver
integrações mais complexas.

Assim, Kimball e Caserta (2008) categorizam os requisitos de integração em dois tipos:

integração de dados: representam os requisitos que podem ser satisfeitos simplesmente

movimentando dados entre bancos de dados. Ou seja, os dados são compartilhados sem a
participação dos sistemas que os geraram, ignorando a sua lógica; e
integração de aplicação: também chamados de integração funcional, seus requisitos são atendidos
através da integração entre as aplicações através do uso de um middleware.

Ao pensarmos em integração entre aplicações, diversas tecnologias e níveis podem ser

empregados. A seguir veremos os principais deles.

22.1 ETL em Microlotes

No modelo convencional de ETL (modelo por integração em lote), a abordagem baseada em

arquivo é muito eficaz em atender os requisitos de lotes diários, semanais e/ou mensais. As
transações realizadas desde a última execução são agrupadas e movidas em massa e as
dimensões são salvas como instantâneos (snapshots) no tempo. Entre uma execução e outra, as
transações daquela janela de tempo não aparecerão no DW.

O ETL em microlotes (Micro-Batch ETL) é muito semelhante ao ETL convencional, apenas a

frequência dos lotes é muito maior. Em outras palavras, o intervalo de tempo entre duas
execuções do processo de ETL é diminuído significativamente. Esses microlotes executados
frequentemente alimentam partições de tempo real nos Data Marts. Uma vez por dia, ou em
algum outro intervalo regular, os dados de tempo real são copiados para os DMs estáticos e as
partições de tempo real são esvaziadas. A figura 32 apresenta um esquema desse tipo de
abordagem.
 Figura 32 – Exemplo de ETL em microlotes.

Legenda: exemplo do fluxo de um ETL em microlote.

Fonte: wisdomjobs.com [https://www.wisdomjobs.com/tutorials/the-logical-
relationship-of-the-real-time-partition-to-its-data-mart.png] .

O ETL em microlotes é uma boa opção para DWs que toleram latências de até uma hora.
Segundo Kimball e Caserta (2004), essa é a abordagem mais simples para fornecer relatórios em
tempo próximo ao real. Segundo Meyers (2014), séries temporais são o tipo ideal de dados para
essa abordagem.

22.2 Service-Oriented Architecture (SOA)

A Arquitetura Orientada a Serviços (SOA) é um princípio de projeto no qual o software é definido e

construído em partes desacopladas e que fornecem serviços bem definidos. Os serviços podem
envolver a realização de alguma atividade ou o retorno de alguma informação ou resposta.

Softwares desenvolvidos internamente e mesmo pacotes comerciais de software podem oferecer

essa capacidade de interação. Os serviços são chamados por meio de uma API. Uma arquitetura
orientada a serviços é particularmente relevante na integração, porque a natureza bem definida
dos serviços direciona as suas interações.

Embora um aplicativo possa ser totalmente implementado utilizando apenas serviços que
interagem entre si, esta não é em geral a melhor abordagem. Por serem independentes entre si,
uma arquitetura toda construída sob essa ótica terá várias partes redundantes em cada serviço,
como controle de acesso e segurança, por exemplo. Em geral, é mais eficiente entendermos
como os dados serão integrados e criarmos APIs específicas para isso.

Uma SOA irá incluir o registro e a relação dos serviços disponíveis e como eles são chamados.
Embora as primeiras implementações do SOA foram através do SOAP (Simple Object Access
Protocol), tornou-se mais comum o uso do padrão REST (REpresentational State Transfer).

22.3 Enterprise Service Bus (ESB)

Um Enterprise Service Bus (ESB) ou Barramento de Serviços Corporativo é implementado através

de um middleware, que geralmente o executa em um servidor totalmente separado, e que se
torna o elemento central na comunicação entre aplicações.

A diferença entre o ESB e o SOA é que o primeiro é uma ferramenta ou mecanismo, enquanto o
SOA é uma filosofia de projeto. O ESB é geralmente implementado em um ambiente mais
heterogêneo, com aplicativos que utilizam diferentes tecnologias e não necessariamente foram
programados sob a visão de serviços. Ou seja, um ESB pode estar conectado a aplicativos
escritos como serviços, mas geralmente irá incluir também aplicativos que utilizaram outras
abordagens. Se todos os aplicativos forem escritos como serviços, um ESB provavelmente não
será necessário, mas este é um cenário raro.

Quase todas as soluções de integração de dados corporativas, operacionais, em tempo real ou

próximo ao real usam um ESB. Em outras palavras, a maioria das interfaces que suportam o
trabalho diário são implementadas usando um ESB.

Um Enterprise Service Bus é usado para coordenar a movimentação de mensagens de dados

entre diferentes servidores, que podem estar executando tecnologias diferentes. A figura 33
mostra um exemplo de um ESB.
 Figura 33 – Exemplo de um Enterprise Service Bus.

Legenda: exemplo de um barramento de serviços corporativo.

Fonte: netdna-ssl.com [https://4e93fz2p9xwy411qyb3s885q-wpengine.netdna-ssl.com/wp-
content/uploads/2017/12/Enterprise-Service-Bus.png] .

Na figura 33, cada servidor conectado ao ESB utiliza um adaptador para se conectar às filas de
mensagens recebidas e enviadas de cada aplicativo. Cabe ao adaptador tratar quaisquer
transformações que precisem ocorrer devido às diferenças entre as tecnologias envolvidas.

O ESB é responsável por continuamente verificar (pool) cada fila de mensagens de saída de cada
aplicação conectada. Assim, cada vez que uma aplicação enviar uma mensagem ao ESB, este irá
processá-la e colocá-la na fila de entrada das aplicações correspondentes. Se uma aplicação
não estiver conectada (estiver offline) quando uma mensagem relevante chegar, o ESB é
responsável por manter uma cópia dessa mensagem na fila de mensagens do aplicativo até que
este volte a se conectar com o ESB.

A implementação de um Enterprise Service Bus geralmente inclui também a implementação

lógica de um modelo de integração no modelo hub-and-spoke. Embora esta não seja uma
obrigatoriedade, essas duas abordagens são consideradas complementares (HAMMER;
TIMMERMAN, 2007).

22.4 Enterprise Application Integration (EAI)

No nível mais alto de complexidade está a integração de aplicações corporativas, também

chamado, por vezes, de integração funcional. O Enterprise Application Integration (EAI) é um tipo
de arquitetura ou abordagem de integração de dados que descreve um conjunto de tecnologias
utilizadas para suportar uma integração real de aplicações.
O EAI pode se apoiar em todas técnicas de integração de aplicativos que vimos até agora,
incluindo a abordagem hub-and-spoke, usando ESBs e vários padrões de interação, como
Publicar-Assinar. O seu objetivo é conectar aplicativos que foram desenvolvidos e
implementados em momentos diferentes e usando tecnologias diferentes.

O EAI normalmente envolve a construção de um conjunto de componentes adaptadores e de um

módulo intermediador, conhecido como broker, que move transações comerciais, na forma de
mensagens, entre os vários sistemas da rede de integração. Os adaptadores específicos de cada
aplicação são responsáveis por lidar com toda a lógica necessária para criar e executar
mensagens, e os brokers são responsáveis por rotear as mensagens adequadamente, com base
nas regras de publicação e assinatura.

A figura 34 apresenta o diagrama de um EAI para um DW com integração de dados em tempo

real. As aplicações de ERP (Enterprise Resource Planning) e SFA (Sales Force Automation) não
precisam saber qualquer aspecto uma da outra. Seus adaptadores são responsáveis por
capturar, interpretar e aplicar as mensagens em cada uma das aplicações. Assim, qualquer
mudança em um cliente ou produto, por exemplo, será capturada pelo adaptador correspondente
e enviado como uma mensagem para o broker. Este, por sua vez, irá rotear a mensagem para
quaisquer sistemas que tenham assinado o seu recebimento.

Figura 34 – Diagrama de um EAI.

Legenda: diagrama de um EAI para um data warehouse em tempo real.

Fonte: Kimball e Caserta (2008, p. 443).

No diagrama da figura 34, um dos assinantes prováveis de clientes seria o Customer Dimension
Authority Adapter. Assim, imagine que o adaptador do ERP detecte uma mudança em cliente. Ele
irá então enviar uma mensagem “mudança em cliente” ao broker, contendo a transação
correspondente. O broker irá encaminhar essa mensagem para os assinantes, provavelmente os
adaptadores de SFA e Customer Dimension Authority. O adaptador de Customer Dimension
Authority irá chamar algum método do gerenciador da dimensão Customer para tratar a
mudança. Esse método, por sua vez, irá transformar e atualizar um ou mais registros da
dimensão Customer. O adaptador do Customer Dimension Authority irá detectar essa mudança e
gerar uma nova mensagem “mudança na dimensão cliente” ao broker. Este irá encaminhar a
nova mensagem aos assinantes, entre eles os adaptadores dos Data Marts Order e Sales Call,
que atualizariam suas tabelas dimensão correspondentes.

É interessante notar que, se o driver do ERP estiver assinando mensagens do tipo “mudança na
dimensão cliente”, a mensagem do Customer Dimension Authority poderá inclusive afetar de
volta o ERP. Isso poderia acontecer no caso de o Customer Dimension Authority ser responsável
por padronizar os dados de clientes. Assim, uma mudança de uma cliente no ERP afetaria o
Customer Dimension Authority que, por sua vez, afetaria de volta o ERP (e possivelmente o SFA).

Uma das vantagens dessa arquitetura é que a entrada de uma nova aplicação irá exigir apenas a
criação de um novo adaptador e novas regras de publicar e assinar no broker. Uma outra
vantagem, segundo Reeve (2013), é que, independente da metodologia utilizada para a
integração, sempre teremos que solucionar os problemas em algum lugar. E os adaptadores EAI
fazem isso no local ideal: o mais próximo possível do aplicativo.

Ainda segundo Reeve (2013), a melhor prática na integração de dados é interagir através dos
aplicativos e permitir que o código do aplicativo manipule o acesso às estruturas de dados
subjacentes. Mesmo que um aplicativo não tenha um conjunto predefinido de serviços ou APIs, é
sempre melhor tentarmos criar um invólucro (wrapper) que chame o código do aplicativo para
acessar os dados, em vez de tentar fazê-lo diretamente.

22.5 Enterprise Information Integration (EII)

A última forma de integração que veremos é a Enterprise Information Integration (EII) ou

Integração de Informações Corporativas. Em cenários em que o código para acessar dados de
uma aplicação não pode ser chamado, não nos resta alternativa a não ser acessar diretamente
as estruturas de dados do aplicativo.

Nesse caso, uma pequena quantidade de código precisará ser escrita para ignorar o aplicativo e
acessar os dados diretamente. Deve-se, sempre que possível, utilizar as mesmas ferramentas da
aplicação para acesso ao SGBD ou aos dados. Por exemplo, se o aplicativo em que os dados são
produzidos for um sistema legado e não houver uma API ou serviço para acesso, o código escrito
irá acessar o banco de dados diretamente e ficará monitorando todas as atualizações, gerando
mensagens para as mudanças e as enviando ao adaptador EAI ou publicadas no ESB.

Videoaula - Processo completo de ETL

Escaneie a imagem ao lado com um app QR code para assistir o vídeo ou clique aqui
[https://player.vimeo.com/video/475220984] .
 Exercícios de fixação
O padrão de integração de dados no qual um middleware é utilizado para capturar e rotear as
mensagens é chamado de:

Pedido-Reposta.

Publicar-Assinar.

Middleware dependent.

Integração direta.

O modelo de dados no qual criamos visões unificadas das principais entidades de uma
organização é o:

Modelo de Dados Canônico.

Gerenciamento de Dados Mestres.

Modelo de Dados Real.

Gerenciamento de Dados Escravos.

NÃO são metadados associados à integração de dados em tempo real:

Metadados de Negócio.

Metadados Técnicos.

Metadados Operacionais.

Metadados de Ligação.
 RECAPITULANDO

Esta Unidade apresentou o modelo de integração de dados em lote, comparando-o com o

modelo de integração em tempo real. Discutimos as principais considerações que
devemos ter em mente ao pensarmos em um cenário de integração em tempo real ou
tempo próximo ao real.

Vimos que as regras em uma integração em tempo real são um pouco diferentes e, em
geral, mais complexas que a abordagem de ETL tradicional.

Destacamos a necessidade de estabelecer um modelo de dados canônico e a

possibilidade de estabelecer um modelo de gerenciamento centralizado de dados
comum entre várias aplicações diferentes da organização.

Estudamos os padrões de interface ponto a ponto e hub-and-spoke e os modelos de

troca de mensagens Pedido-Resposta e Publicar-Assinar.

Por último, apresentamos as principais tecnologias e arquiteturas que podemos utilizar

em um cenário de integração de dados em tempo real.
 Considerações finais
Prezado(a) estudante, estamos encerrando este conteúdo e espero que você tenha ficado
interessado em aprender ainda mais sobre ETL e integração de dados.

Nesse caso, não deixe de baixar e utilizar as principais ferramentas de ETL que indicamos.
Mesmo as ferramentas comerciais, que utilizam modelo de licenciamento pago, possuem, em
geral, opções de avaliação que permitem o seu uso por pelo menos 30 dias. Explore as
ferramentas que mais lhe interessarem. O entendimento e aprendizado de como essas
ferramentas funcionam o permitirá solidificar também os conceitos que vimos no conteúdo.

Ao longo das Unidades, vimos a importância e os principais modelos de integração de dados.

Exploramos também cada uma das etapas do processo de Extração, Transformação e Carga de
Dados.

Na verdade, antes mesmo da Extração, mostramos a importância da definição dos diferentes

tipos de requisitos e de uma análise inicial da qualidade dos dados.

O estudo de ETL iniciou com a etapa de Extração, quando vimos os tipos de fontes de dados
mais comuns e os desafios de integração com fontes de dados múltiplas.

A etapa de Transformação foi, provavelmente, a que demandou maior esforço de entendimento.

Isso se deve ao fato de essa fase ser uma das mais complexas e demoradas. Entender o
significado dos dados, conhecer as peculiaridades de cada fonte de dados e estabelecer a
ligação entre os requisitos de negócio, as fontes de dados e os processos de transformação que
serão necessários não são tarefas fáceis ou triviais, muito pelo contrário: esta será
provavelmente a etapa mais demorada na implantação de um Data Warehouse.

Por fim, vimos que a etapa de Carga dos dados se preocupa em garantir que as informações
sejam gravadas corretamente em seus destinos.

Estudamos a evolução das ferramentas de ETL e as principais soluções comerciais e de código

aberto existentes.

Ao final, os principais tópicos referentes à integração de dados em tempo real foram explorados.

Nosso objetivo ao longo de todo o material foi apresentar a você os principais desafios dessa
área de conhecimento que demanda cada vez mais profissionais capacitados e comprometidos
no estabelecimento de soluções que permitam a tomada de decisões em escala.
Acreditamos que os conhecimentos aqui apresentados fornecem as bases necessárias para que
você entenda e possa começar a lidar de maneira efetiva com o processo de ETL. Esperamos que
esses conhecimentos lhe sejam muito úteis, tanto pessoal como profissionalmente, mas que
continuem sendo apenas mais um passo numa jornada de muito sucesso!

Fortuna audaces sequitur!

Prof. Marlom Konrath

 Exercícios de fixação - respostas
Os principais tipos de integração de dados são:

extrair, transformar e carregar.

por linha, por coluna e por tabela.

em lote, em tempo real e big data.

de arquivo e de sistema.

Em relação ao uso dos recursos do sistema de origem para a extração dos dados, assinale a
alternativa correta.

A equipe local será a única responsável pela correta extração dos dados.

Só devemos usar o recurso do sistema de origem quando não houver outra alternativa.

O uso dos recursos do sistema de origem não terá impacto no desempenho geral do sistema.

A equipe local entende melhor os dados e o seu significado.

A etapa em que os dados já prontos são armazenados nos sistemas de destino é chamada de:

extrair.

carregar.

transformar.

staging area.

O único exemplo de dados fora do padrão é:

valores errados em colunas.

 erros de integridade.

violações de regras de negócio.

valores nulos em coluna.

NÃO é um tipo de carregamento de dados em um processo ETL:

Carregamento Inicial.

Carregamento Diferencial.

Carregamento Incremental.

Carregamento Total.

As tabelas que armazenam as coleções de itens, eventos ou acontecimentos são chamadas de:

tabelas Fato.

tabelas Dimensão.

tabelas Dinâmicas.

tabelas Valor.

Assinale a alternativa que preenche corretamente a lacuna.

“Foi apenas a partir da ______ geração que as ferramentas de ETL começaram a suportar o
paralelismo de processamento, aumentando em muito as possibilidades de processamento de
dados.”

1ª.

2ª.

3ª.
 4ª.

NÃO é uma solução de ETL de código aberto a ferramenta:

Talend Open Studio.

Hitachi Vantara Pentaho.

Jaspersoft ETL.

Qlik Attunity Replicate - Carregamento Inicial.

Assinale a alternativa que provavelmente irá representar uma vantagem de se desenvolver uma
solução de ETL internamente.

Maior flexibilidade.

Maior escalabilidade.

Maior economia.

Maior tempo de processamento.

O padrão de integração de dados no qual um middleware é utilizado para capturar e rotear as

mensagens é chamado de:

Pedido-Reposta.

Publicar-Assinar.

Middleware dependent.

Integração direta.
O modelo de dados no qual criamos visões unificadas das principais entidades de uma
organização é o:

Modelo de Dados Canônico.

Gerenciamento de Dados Mestres.

Modelo de Dados Real.

Gerenciamento de Dados Escravos.

NÃO são metadados associados à integração de dados em tempo real:

Metadados de Negócio.

Metadados Técnicos.

Metadados Operacionais.

Metadados de Ligação.
 Autoria
Marlom Alves Konrath
Autor
Possui graduação em Análise de Sistemas pela Universidade do Vale do Rio dos Sinos e
mestrado em Computação Aplicada pela mesma instituição. Atual diretor técnico executivo de TI
de um grupo de empresas em São Paulo e professor universitário, com mais de 20 anos de
experiência profissional.

Elisamara de Oliveira
Autora revisora
Possui doutorado em Engenharia Elétrica pela Universidade de São Paulo, mestrado em Ciência
da Computação pela Universidade Federal de Minas Gerais e é bacharel em Ciência da
Computação pela Universidade Federal de Minas Gerais. Tem mais de 30 anos de experiência
profissional na área de TI, com atuação mais recente como designer pedagógica EAD, realizando
a supervisão de qualidade técnica de conteúdo EAD, além de elaborar, credenciar, autorizar e
coordenar projetos e cursos de pós-graduação EAD na área de TI.
 Glossário

Data warehousing
É um processo para coletar e gerenciar dados de diversas fontes para fornecer informações
comerciais significativas. É um mix de tecnologias e componentes que auxiliam no uso
estratégico dos dados. Requer o armazenamento eletrônico de uma grande quantidade de
informações por uma empresa em uma estrutura projetada para consulta e análise, em vez de
processamento de transações. É um processo de transformar dados em informações e
disponibilizá-los aos usuários em tempo hábil. Fonte: guru99.com
[https://www.guru99.com/data-warehousing.html] .

Gerenciamento de Dados Mestres (Master Data Management

– MDM)
É o principal processo usado para gerenciar, centralizar, organizar, categorizar, localizar,
sincronizar e enriquecer dados mestres de acordo com regras comerciais e operacionais, bem
como estratégias de vendas e de marketing de uma empresa. Os dados mestre podem assumir a
forma de informações sobre produtos, clientes, fornecedores, localização e ativos, além de
quaisquer fontes de informações que impulsionem os negócios. Fonte: stibosystems.com
[https://www.stibosystems.com/pt-br/what-is-master-data-management] .

Internet of Things – IoT

Internet das Coisas é o modo como os objetos físicos estão conectados e se comunicando entre
si e com o usuário, através de sensores inteligentes e softwares que transmitem dados para uma
rede. Como se fosse um grande sistema nervoso que possibilita a troca de informações entre
dois ou mais pontos. O resultado disso é um planeta mais inteligente e responsivo que nos
permite entender melhor como essas coisas funcionam, e como funcionam juntas para melhor
nos servir. Fonte: proof.com.br [https://www.proof.com.br/blog/internet-das-coisas/] .

Metadados
O prefixo meta vem do grego e significa além de. Assim, metadados são informações
acrescentadas aos dados e que têm como objetivo adicionar informar sobre eles para tornar
mais fácil a sua organização. Um item de um metadado pode informar do que se trata aquele
dado em uma linguagem inteligível para um computador. Os metadados têm a função de facilitar
o entendimento dos relacionamentos e evidenciar a utilidade das informações dos dados. Fonte:
new.safernet.org.br [https://new.safernet.org.br/content/o-que-s%C3%A3o-os-metadados] .

Microsserviços
Microsserviços são uma abordagem arquitetônica e organizacional do desenvolvimento de
software na qual o software consiste em pequenos serviços independentes que se comunicam
usando APIs bem definidas. Esses serviços pertencem a pequenas equipes autossuficientes. As
arquiteturas de microsserviços facilitam a escalabilidade e agilizam o desenvolvimento de
aplicativos, habilitando a inovação e acelerando o tempo de introdução de novos recursos no
mercado. Fonte: aws.amazon.com
[https://aws.amazon.com/pt/microservices/#:~:text=Microsservi%C3%A7os%20s%C3%A3o%20u
ma%20abordagem%20arquitet%C3%B4nica,pertencem%20a%20pequenas%20equipes%20autoss
uficientes.] .

Requisitos
Requisitos são funções, objetivos, propriedades, restrições que o sistema deve possuir para
satisfazer contratos, padrões ou especificações de acordo com o(s) usuário(s). De forma mais
geral, um requisito é uma condição necessária para satisfazer um objetivo. Fonte:
devmedia.com.br [https://www.devmedia.com.br/introducao-a-requisitos-de-software/29580] .

William Inmon
William H. (Bill) Inmon (nascido em 1945) é um cientista da computação americano, reconhecido
por muitos como o pai do Data Warehouse. Foi ele que escreveu o primeiro livro, realizou a
primeira conferência (com Arnie Barnett), escreveu a primeira coluna de uma revista e foi o
primeiro a oferecer aulas de data warehousing. Inmon criou a definição aceita do que é um Data
Warehouse - uma coleção de dados variante no tempo, orientada ao assunto, não volátil e
integrada, para apoiar as decisões da gerência. Fonte: en.wikipedia.org
[https://en.wikipedia.org/wiki/Bill_Inmon] .
 Bibliografia
Bibliografia Clássica
DAMA INTERNATIONAL. Dictionary of Data Management. Nova Jersey: Technics Publications,
LLC, 2011.

DEVLIN, B.; MURPHY, P. An architecture for a business and information system. IBM Systems
Journal, v. 27, n. 1, p. 60-80, 1988.

FERREIRA, J. et al. O Processo ETL em Sistemas Data Warehouse. In: INFORUM, II SIMPÓSIO DE
INFORMÁTICA, 2010, Braga. Anais [...]. Braga: Universidade do Minho, 2010. Disponível em:
inforum.org.pt [http://inforum.org.pt/INForum2010/papers/sistemas-inteligentes/Paper080.pdf]
. Acesso em: 5 maio 2020.

HAMMER, K.; TIMMERMAN, T. Fundamentals of Software Integration. 1 ed. Nova York: Jones &
Bartlett Learning, 2007.

HAMMERGREN, T.; SIMON, A. Data Warehousing for Dummies. 2. ed. Indianápolis: Wiley
Publishing, 2009.

HILL, K. How Target figured out a teen girl was pregnant before her father did. Forbes, 16 fev.
2012. Disponível em: forbes.com [https://www.forbes.com/sites/kashmirhill/2012/02/16/how-
target-figured-out-a-teen-girl-was-pregnant-before-her-father-did/#28da54866668] . Acesso
em: 14 jun. 2020.

INMON, W. A Brief History of ETL. SearchData Management, 8 maio 2008. Disponível em:
searchdatamanagement.techtarget.com
[https://searchdatamanagement.techtarget.com/news/2240033946/A-brief-history-of-ETL] .
Acesso em: 5 maio 2020.

INMON, W. Building the Data Warehouse. 1 ed. Nova York: Wiley, 1990.

KAKISH, K.; KRAFT, T. A. ETL Evolution for Real-Time Data Warehousing. In: PROCEEDINGS OF
THE CONFERENCE ON INFORMATION SYSTEMS APPLIED RESEARCH, v. 5, n. 2214, 2012, Nova
Orleans. Anais [...]. Nova Orleans: Education Special Interest Group of the AITP, 2012. Disponível
em: researchgate.net
[https://www.researchgate.net/publication/280837435_ETL_Evolution_for_Real-
Time_Data_Warehousing] . Acesso em: 26 maio 2020.
KIMBALL, R. et al. The Data Warehouse Lifecycle Toolkit. 2 ed. Indianápolis: Wiley Publishing,
2008.

KIMBALL, R.; CASERTA, J. The Data Warehouse ETL toolkit: practical techniques for extracting,
cleaning, conforming and delivering data. Indianápolis: Wiley Publishing, 2004.

KIMBALL, R.; ROSS, M. The Data Warehouse toolkit: the definitive guide to dimensional modeling.
3. ed. Indianápolis: Wiley Publishing, 2013.

KOZIELSKI, S.; WREMBEL, R. New Trends in Data Warehousing and Data Analysis. Annals of
Information Systems (Book 3). Nova York: Springer, 2008.

LANE, P. Oracle Database: Data Warehousing Guide 10g Release 2 (10.2) B14223-02. Redwood
City: Oracle, 2005. Disponível em: docs.oracle.com
[https://docs.oracle.com/cd/B19306_01/server.102/b14223.pdf] . Acesso em: 7 maio 2020.

MEYERS, I. Best Practices for Micro-Batch Loading on Amazon Redshift. AWS Big Data Blog, 25
jul. 2014. Disponível em: aws.amazon.com [https://aws.amazon.com/pt/blogs/big-data/best-
practices-for-micro-batch-loading-on-amazon-redshift/] . Acesso em: 17 maio 2020.

MOSS, L. T.; ATRE, S. Business Intelligence Roadmap: the complete project lifecycle for decision-
support applications. Boston: Pearson Education, 2003.

PINHEIRO, C. A. R.; MCNEILL, F. Heuristics in Analytics: a practical perspective of what influences

our analytical world. Nova Jersey: John Wiley & Sons Inc., 2014.

PONNIAH, P. Data Warehousing Fundamentals for IT Professionals. Indianápolis: Wiley Publishing

Inc., 2010.

REEVE, A. Managing Data in Motion. 1 ed. Waltham: Morgan Kaufmann, 2013.

RUSSOM, P. Data Integration architecture: what it does, where it’s going, and why you should
care. TDWI, 27 maio 2008. Disponível em: tdwi.org [https://tdwi.org/articles/2008/05/27/data-
integration-architecture-what-it-does-where-its-going-and-why-you-should-care.aspx] . Acesso
em: 29 maio 2020.

STONEBAKER, M. Three Generations of Data Integration Systems. Tamr, 18 maio 2014. Disponível
em: tamr.com [https://www.tamr.com/blog/three-generations-data-integration-systems/] .
Acesso em: 18 maio 2020.
ZODE, M. The Evolution of ETL: from Hand-coded ETL to Tool-based ETL. 2008. Disponível em:
citeseerx.ist.psu.edu [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.114.4838] .
Acesso em: 26 maio 2020.

Bibliografia Geral
ALVI, I. A. ETL vs. ELT: Transform First or Transform Later?. Data Warehouse Information Center,
30 ago. 2018. Disponível em: datawarehouseinfo.com [https://datawarehouseinfo.com/etl-vs-
elt-transform-first-or-transform-later/] . Acesso em: 4 maio 2020.

CHIEN, M.; JAIN, A. Magic Quadrant for Data Quality Tools. Gartner, 27 mar. 2019. Disponível em
b2bsalescafe.files.wordpress.com [https://b2bsalescafe.files.wordpress.com/2019/09/gartner-
magic-quadrant-for-data-quality-tools-march-2019.pdf] . Acesso em: 24 jul. 2020.

CONCEITOS de data warehouse: o que é um data warehouse?. AWS, 7 jul. 2020. Disponível em:
aws.amazon.com [https://aws.amazon.com/pt/data-warehouse/] . Acesso em: 5 maio 2020.

CORR, L.; STAGNITTO, J. Agile Data Warehouse Design. Leeds: DecisionOne Press, 2012.

DATA QUALITY Services. Microsoft, 10 dez. 2013. Disponível em: docs.microsoft.com

[https://docs.microsoft.com/en-us/sql/data-quality-services/data-quality-services] . Acesso
em: 29 abr. 2020.

FRIEDLAND, D. ETL vs ELT: We Posit, You Judge. IRI Total Data Management, 2016. Disponível em:
iri.com [https://www.iri.com/blog/data-transformation2/etl-vs-elt-we-posit-you-judge/] .
Acesso em: 5 maio 2020.

GOV.BR. O que é? - Governança de Dados. Gov.br, 27 nov. 2019. Disponível em: gov.br
[https://www.gov.br/governodigital/pt-br/governanca-de-dados] . Acesso em: 7 jun. 2020.

HOFFNER, J. A.; RAMESH, V.; TOPI, H. Modern Database Management. 13 ed. Boston: Pearson
Education, 2017.

KUMAR, R. ETL vs. ELT: how to choose the best approach for your Data Warehouse. Software
Advice, 13 abr. 2020. Disponível em: softwareadvice.com
[https://www.softwareadvice.com/resources/etl-vs-elt-for-your-data-warehouse/] . Acesso em:
5 maio 2020.

MACHADO, F. N. R. Tecnologia e Projeto de DW. São Paulo: Erica, 2012.

NAGLE, T.; REDMAN, T. C.; SAMMON, D. Only 3% of Companies’ Data Meets Basic Quality
Standards. Harvard Business Review, 11 set. 2017. Disponível em: hbr.org
[https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-standards] . Acesso
em: 4 maio 2020.

ORACLE. Oracle Data Integration Platform. 2020a. Disponível em: oracle.com

[https://www.oracle.com/cloud/integration/data-integration-platform-cloud/] . Acesso em: 27
maio 2020.

ORACLE. Oracle Warehouse Builder. 2020b. Disponível em: oracle.com

[https://www.oracle.com/application-development/technologies/warehouse/warehouse-
builder.html] . Acesso em: 27 maio 2020.

ORACLE. Understanding Oracle Enterprise Data Quality. 2020c. Disponível em: docs.oracle.com
[https://docs.oracle.com/en/middleware/enterprise-data-quality/12.2.1.3/dqarc/overview-
oracle-enterprise-data-quality.html] . Acesso em: 29 abr. 2020.

PEARLMAN, S. What is Data Profiling?. Talend, 2019. Disponível em: talend.com

[https://www.talend.com/resources/what-is-data-profiling/] . Acesso em: 4 maio 2020.

PETERSEN, T. Extract, transform, and load (ETL). 2019. Disponível em: docs.microsoft.com
[https://docs.microsoft.com/en-us/azure/architecture/data-guide/relational-data/etl] . Acesso
em: 5 maio 2020.

RAVINDRA, S. Streaming Data Integration: the evolution of ETL. WSO2, 16 ago. 2019. Disponível
em: wso2.com [https://wso2.com/library/article/2019/08/streaming-data-integration-the-
evolution-of-etl/] . Acesso em: 26 maio 2020.

REDMAN, T. Bad Data costs the U.S. $3 Trillion per year. Harvard Business Review, 22 set. 2016.
Disponível em: hbr.org [https://hbr.org/2016/09/bad-data-costs-the-u-s-3-trillion-per-year] .
Acesso em: 4 maio 2020.

SAS INSTITUTE. ETL: What it is and why it matters. 2020. Disponível em: sas.com
[https://www.sas.com/en_th/insights/data-management/what-is-etl.html] . Acesso em: 25 maio
2020.

SHARDA, R.; DELEN, D.; TURBAN, E. Business intelligence e análise de dados para gestão do
negócio. 4. ed. Porto Alegre: Bookman, 2019.
SOFTWARETESTINGHELP. 15 Best ETL Tools in 2020 (A Complete Updated List). 2020. Disponível
em: softwaretestinghelp.com [https://www.softwaretestinghelp.com/best-etl-tools/] . Acesso
em: 27 maio 2020.

TANZER, P. Build or buy ETL Tools: the pros and cons of building a pipeline. Panoply, 19 mar.
2019. Disponível em: blog.panoply.io [https://blog.panoply.io/build-or-buy-etl-tools-the-pros-
and-cons-of-building-a-pipeline] . Acesso em: 28 maio 2020.

THOO, E. et al. Magic Quadrant for Enterprise Integration Platform as a Service. 2019. Disponível
em: informatica.com [https://www.informatica.com/data-integration-magic-quadrant.html] .
Acesso em: 5 maio. 2020.

VIRTUALIZAÇÃO DE Dados. IBM, 12 jun. 2019. Disponível em: ibm.com [https://www.ibm.com/br-

pt/analytics/data-virtualization] . Acesso em: 28 abr. 2020.

WATTS, S. ETL Basics: Extract, Transform & Load. BMC Blogs, 14 dez. 2017. Disponível em:
bmc.com [https://www.bmc.com/blogs/what-is-etl-extract-transform-load-etl-explained/] .
Acesso em: 6 maio 2020.

WHAT IS A Data Mart? Talend, 28 set. 2018. Disponível em: talend.com

[https://www.talend.com/resources/what-is-data-mart/] . Acesso em 14 jul. 2020.

ZAIDI, E.; THOO, E.; HEUDECKER, N. Magic Quadrant for Data Integration Tools. 2019. Disponível
em gartner.com [https://www.gartner.com/doc/reprints?id=1-1OBCG8GI&ct=190725&st=sb] .
Acesso em: 26 maio 2020.