APOSTILA- INTEGRAÇÃO DE ARQUITETURA ETL

Prévia do material em texto

INTEGRAÇÃO DE ARQUITETURA ETL 1 
 
 
Integração de arquitetura ETL 
 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 2 
Arquitetura ETL 
 
A arquitetura ETL, é o processo mais longo e trabalhoso da fase de construção de um 
BI, pois é a extração dos dados de uma base transacional de origem, transformação, 
limpeza desses dados e carregamento na base de dados analítica (DW). 
 
Esta etapa do processo deve se basear na busca das informações mais importantes 
em sistemas fontes internos ou externos e que estejam em conformidade com a 
modelagem. Essa busca, na maioria, é dificultada pelo fato de as informações estarem 
armazenadas em fontes distintas de dados. 
 
Em um primeiro momento, é normal que a carga inicial seja feita para que todos os 
dados do sistema origem sejam transferidos para uma área do DW chamada de Stage 
e posteriormente passada para a área chamada ODS, também no DW. 
 
Após isso, as demais cargas serão incrementais. Como diz um dos projetistas que 
lançaram o BI (Kimball), é a mais eficiente e carrega somente os registros que foram 
alterados ou inseridos na base origem. 
 
E o que é ODS (Operational Sata Store)? 
 
A construção de um ODS é facultativa, entretanto, ajuda em muito a diminuir os 
esforços de construção de um DW. Todo o esforço de integração entre os sistemas 
transacionais da empresa seriam depositados no ODS e a carga do DW seria 
simplificada de maneira incomensurável. 
 
Alguns dados operacionais podem ir direto para o DW, através da camada de 
programas de ETL, enquanto outros dados operacionais são enviados para o ODS e 
depois do ODS para o DW. 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 3 
Um ODS é integrado, orientado a assunto, volátil, desenhado para atender aos 
usuários operacionais, em grandes processos de integração, permitindo melhor 
performance. 
 
Vamos estudar também o que é Stage Area, pois também faz parte do processo de 
ETL. 
 
Por que precisamos da Stage Area? 
 
A Stage Area é um repositório necessário para integrar todos os tipos de dados em 
um único formato porque simplesmente temos informações de diversas origens 
diferentes e de diversas plataformas. 
 
Ela garante a existência única de dados, eliminando a possibilidade de termos dados 
repetidos ou similares ou até mesmo com valores diferentes em um DW, dados não 
sincronizados e dados “sujos”. 
 
A Stage Area deve ser usada também para “limpar” os dados, é o único lugar que 
serve para determinar os valores que vêm efetivamente de sistemas legados. 
 
Portanto, é um repositório único de dados que necessita de dados sólidos e confiáveis, 
de onde possamos extrair informações, tratá-las e fazer com que essas informações 
gerem resultados e deixem de ser somente dados para ser informações. 
 
Resumindo, a Stage Area é uma camada intermediária entre a extração dos dados 
legados até a carga no DW. Muito utilizada quando estamos extraindo um volume 
enorme de dados, já que essa camada auxilia na limpeza desses dados, ou seja, temos 
que carregar em nosso DW somente aquilo que interessa aos gestores e o que for 
confiável. Com o volume de dados que temos hoje oriundos de várias fontes de dados 
externas tornou-se bem utilizada. 
 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 4 
O significado de ETL 
 
A Extração é a coleta de dados dos sistemas de origem (também chamados Data 
Sources ou sistemas operacionais), extraindo-os e transferindo-os para o ambiente de 
DW, onde o sistema de ETL pode operar independentemente dos sistemas 
operacionais. 
 
Os esforços de um projeto de BI devem ser concentrados nesse processo, já que, para 
o funcionamento correto do BI, os dados devem refletir a pura verdade e nada mais, 
o que faz do ETL um processo que deve ser pensado e realizado com cuidado. 
 
A Transformação é a etapa seguinte à extração. Nessa fase, faz-se também a 
limpeza dos dados. Verificam-se erros de digitação, restrições de permissão dos 
bancos (quando há alguma restrição desse tipo, só usuários não podem inserir no 
DW), padronizam-se as abreviações etc. 
 
Os dados a serem carregados devem possuir qualidade e para garantir a qualidade 
dos dados devemos observar o seguinte: 
 
• Unicidade - evitar duplicações de informação; 
• Precisão - os dados não devem perder suas características originais assim que 
são carregados no DW; 
• Completude - não deve gerar dados parciais dos dados importantes para a 
análise; 
• Consistência - os dados devem ser coerentes com os dados das dimensões, 
devem ter forma homogênea para a carga no DW. 
 
 
 
Enquanto busca-se a homogeneidade dos dados, podem ocorrer dois tipos de 
conflitos: 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 5 
• Semânticos - são aqueles que envolvem a palavra ou o nome associado às 
estruturas de modelagem, como ter o mesmo nome para entidades distintas; 
• Estruturais - são os que dizem respeito à própria estrutura da modelagem. 
 
Os conflitos estruturais mais típicos são: 
 
• Diferenças de unidades - quando as unidades utilizadas diferem, embora 
forneçam a mesma informação. Como uma distância em metros ou em 
quilômetros; 
 
• Diferenças de precisão - quando a precisão escolhida varia de um ambiente para 
outro. Se um valor monetário é armazenado com número de casas decimais 
diferente do que foi extraído, por exemplo; 
 
• Diferenças em códigos ou expressões - quando o código utilizado difere um 
do outro. Por exemplo, quando o sexo é definido com código M (masculino) e F 
(feminino) ou (1) masculino e (2) feminino; 
 
• Diferenças de abstração - quando a forma de estruturar uma mesma informação 
segue critérios diferentes. Quando um endereço está armazenado em uma coluna 
ou em várias, separado em nome da rua, número, complemento etc. 
 
Depois de termos identificado os conflitos, criamos regras de conversão que visam 
exatamente a corrigi-los. Essas regras podem ser criadas através de ferramentas de 
integração. 
 
O estágio de transformação aplica uma série de regras ou funções aos dados extraídos 
para ajustar os dados a serem carregados. Algumas fontes de dados necessitarão de 
muito pouca manipulação de dados. 
 
Em outros casos, pode ser necessário trabalhar algumas transformações, como, por 
exemplo: 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 6 
• Junção de dados provenientes de diversas fontes; 
• Seleção de apenas determinadas colunas; e 
• Tradução de valores codificados (se o sistema de origem armazena 1 para sexo 
masculino e 2 para feminino, mas o DW armazena M para masculino e F para 
feminino, por exemplo). 
 
Após essas observações, pode-se iniciar o processo de Carga. Nesse momento, são 
carregados os dados das Dimensões e da tabela Fato. 
 
Esse processo pode ser bastante demorado e requerer muito recurso de 
processamento. Por esse motivo, procura-se torná-lo mais curto, pois o DW será 
utilizado constantemente. 
 
Logo, devemos tomar alguns cuidados, tais como: 
• Desligamento de índices e referências de integridade (isso pode prejudicar a 
validade dos dados, pois não são validados no momento da inserção); 
• Ter consciência de que alguns dados podem não ser carregados no momento da 
carga e assim devemos verificar os motivos para que possamos solucionar o 
problema. 
 
Após as dimensões estarem corretamente carregadas, já é possível iniciar a carga da 
tabela Fato. Depois de modelados para conter apenas os dados de importância para a 
empresa, direcionam quais regras serão utilizadas. Por exemplo: filtros do que será 
inserido ou somas a serem realizadas, provocando o aparecimento de regras que 
passaram despercebidas no início da modelagem. 
 
No entanto, a tabela Fato demanda cuidados na sua carga, como: 
• Uso das chaves artificiais das dimensões para que se tenha uma integridade 
referencial; 
• Controle de valores nulos obtidos no momento da transação para que não gerem 
a falta de integridade referencial, como datas que, estando nulas,invalidarão o 
histórico do fato. 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 7 
 
Técnicas para amenizar o processo devido ao grande volume de dados podem ser 
usadas, como: 
• Carga incremental da tabela Fato, que irá carregar apenas dados novos ou 
alterados; 
• Execução do processo em paralelo e em momentos de pouco ou nenhum uso do 
SGBD; e 
• Utilização de tabelas auxiliares que serão renomeadas como definitivas ao fim da 
carga. 
 
A parte de Gerenciamento é composta por serviços para auxiliar no gerenciamento 
do DW. Aqui nós temos tarefas específicas para gerenciamento de jobs, planos de 
backup, verificação de itens de segurança e compliance. 
 
Na imagem abaixo, podemos visualizar um exemplo de modelo de Arquitetura ETL. O 
objetivo aqui não é discutir sobre toda a arquitetura, mas visualizar os principais 
componentes que fazem parte de um sistema ETL. 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 8 
 
 
Além dos 4 itens citados acima, ainda temos alguns requisitos que devem estar muito 
bem alinhados, que são: 
 
• Requisitos de negócio – Está bem claro e documentado quais são os requisitos 
de negócio? 
• Viabilidade dos dados - Foi realizada análise de viabilidade dos dados? 
• Latência dos dados - Qual é o tempo máximo permitido para disponibilização 
dos dados através do sistema de BI? 
• Políticas de compliance e segurança - Quais são as políticas de compliance e 
segurança adotadas pela empresa? 
 
O processo ETL 
O ETL é um processo para extrair dados de um sistema de Bases de Dados (BD), sendo 
esses dados processados, modificados e posteriormente inseridos em uma outra BD. 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 9 
Estudos relatam que o ETL e as ferramentas de limpeza de dados consomem um terço 
do orçamento em um projeto de BI, podendo, no que respeita ao tempo de 
desenvolvimento de um projeto de BI, chegar a consumir 80% desse valor. 
 
Outros estudos mencionam, ainda, que o processo de ETL tem custos na ordem dos 
55% do tempo total de execução do projeto de BI. 
 
O processo deve ser bem planejado para evitar transtornos futuros e até mesmo para 
que não ocasione, em casos extremos, a interrupção dos sistemas operacionais da 
empresa. Dessa forma, o DW terá informações tratadas com qualidade e grande valor 
para apoiar as decisões organizacionais. 
 
Um bom ETL deve ter escalabilidade e ser de manutenção bem fácil. Devemos analisar 
a janela de operação, pois como trabalha com grandes volumes de dados não é em 
qualquer momento que ele poderá ser executado. Devemos também analisar a 
periodicidade de execução. 
 
Um processo bem definido e bem desenvolvido é fator importantíssimo para o sucesso 
do projeto. Portanto, devemos tratar o ETL como sendo o “cordão umbilical” que une 
e possibilita a condução dos dados ao DW. 
 
Esse processo não é visto pela área usuária. Por isso, muitas vezes não se dá a ele a 
sua devida importância. Mas tudo depende dele. Sem o ETL não há como se ter 
BI. 
 
O processo de ETL pode ser representado pela imagem abaixo: 
 
https://canaltech.com.br/business-intelligence/entendendo-o-processo-de-etl-22850/
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 10 
 
 
Na figura abaixo, a camada inferior representa o armazenamento dos dados que são 
utilizados em todo o processo. No lado esquerdo podemos observar os dados 
“originais” provenientes, na maioria dos casos, de BD ou, então, de ficheiros com 
formatos heterogêneos, por exemplo, de texto. 
 
Os dados provenientes dessas fontes são obtidos (como é ilustrado na área superior 
esquerda da figura) por rotinas de extração que fornecem informação igual ou 
modificada, relativamente à fonte de dados original. 
 
Posteriormente, esses dados são propagados para a Staging Area onde são 
transformados e limpos antes de serem carregados para a base de dados (DW). Essa 
base é representada na parte direita da figura e tem como objetivo o armazenamento 
dos dados. 
 
O carregamento dos dados no DW é realizado por meio das atividades de carga 
representadas na parte superior direita da figura. 
 
http://igti.com.br/blog/wp-content/uploads/2017/08/image-1.png
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 11 
 
 
É importante que se tenha consciência de que as alterações nos dados não afetam as 
fontes originais, mas, sim, os dados no momento de extração para o repositório do 
DW. Mais ainda que os ajustes são modelados de acordo com as necessidades do 
modelo de DW, atendendo, assim, às restrições que são necessárias para esse modelo. 
 
O processo de carga processa os mapeamentos sintáticos e semânticos entre os 
esquemas, respeitando as restrições de integridade e criando uma visão concretizada 
e unificada das fontes. Esse processo é dos mais árduos e complexos de obter devido 
a sua complexidade que dependerá da heterogeneidade das bases de dados. 
 
Para iniciar o processo de ETL quanto aos dados a serem carregados, temos que 
prestar atenção em alguns pontos: 
• Comparar o número de registros entre os dados das fontes e o número de 
registros carregados para o DW; 
• Comparar valores únicos de determinados atributos entre as fontes e os dados 
carregados para o DW; 
• Procurar fazer um bom esquema de dados para perceber as limitações dos 
valores atribuídos; 
• Procurar validar os conteúdos de cada atributo, ou seja, não permitir que, por 
razões de codificação, o limite de caracteres entre cada esquema relacional 
(fonte e destino) resulte na falha do fluxo de dados; 
• Assegurar que os dados são transformados corretamente de acordo com as 
regras de negócio especificadas; 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 12 
• Criar testes, os mais diversos possíveis, para antever algumas situações 
consequentes; 
• Validar o processamento correto de campos no ETL, tais como chaves 
estrangeiras; 
• Verificar sempre se os tipos de dados presentes no DW são os que se 
planejaram; 
• Procurar e testar a integridade referencial entre as tabelas. 
 
Após esses pontos serem totalmente analisados, temos que assegurar que o sistema 
ETL rejeite ou substitua valores com problemas, corrija ou ignore os dados e reporte 
dados inválidos. Lembrando que isso faz parte do processo Qualidade de dados. 
 
Metadados do ETL 
 
Além da Extração, Transformação e Carga, temos mais dois itens que devem ser 
avaliados: armazenamento e metadados. Veja a figura abaixo: 
 
 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 13 
É de suma importância que o projeto do BI seja documentado. Essa documentação é 
chamada de metadados, que podem ser: 
• Técnicos - para a utilização do desenvolvedor; ou 
• Semânticos ou de negócio - para o usuário final. 
 
O fator mais importante da documentação técnica é a fonte dos dados, se é de origem 
interna ou externa. 
 
Um problema muitas vezes de implementação do projeto de BI é a não confecção da 
sua documentação, que certamente acarretará em problemas na manutenção do 
modelo e utilização do software pelo do usuário final. 
 
Os metadados devem ser atualizados sempre que os dados não processados são 
transformados em informações prontas para consultas dos usuários finais, a fim de 
auxiliá-los na tomada de decisão. 
 
Quais informações os metadados mantém: 
• A estrutura dos dados segundo a visão do programador; 
• A estrutura dos dados segundo a visão dos analistas de SAD; 
• A fonte de dados que alimenta o DW; 
• A transformação sofrida pelos dados no momento de sua migração para o DW; 
• O modelo de dados; 
• O relacionamento entre o modelo de dados e o DW; 
• O histórico das extrações de dados; 
• Os dados referentes aos relatórios que são gerados pelas ferramentas OLAP; 
• Os dados que são gerados nas camadas semânticas. 
 
Os metadados podem surgir de vários locais durante o decorrer do projeto. Eles 
provêm de repositórios de ferramentas case, que geralmente já estão estruturados, 
facilitando a integração da origem dos metadados e o repositóriodos mesmos. Essa 
fonte de metadados é riquíssima. 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 14 
Outros dados que devem ser guardados no repositório de metadados é o material que 
surgirá das entrevistas com os usuários. Dessas entrevistas podem-se obter 
informações preciosas que não estão documentadas em nenhum outro lugar, além de 
regras para validação dos dados depois de carregados no DW. 
 
As fontes metadados (ferramentas de modelagem de dados, ferramentas de extração, 
transformação e carga etc.) devem ser integradas no repositório por várias 
necessidades. 
 
Uma arquitetura de metadados bidirecional permite que os dados modificados na fonte 
possam ser alterados também no repositório automaticamente. 
 
Essa arquitetura é altamente desejável por duas razões chaves: 
1. Permite a essas ferramentas compartilhar metadados. Isso é desejável no mercado 
de ferramentas de apoio de decisão. A maioria das corporações que construíram 
um sistema de apoio à decisão não pensou na integração das ferramentas. Essas 
não são integradas. Por isso, não se comunicam facilmente. Até mesmo essas 
ferramentas que podem ser integradas tradicionalmente requerem bastante 
programação manual para compartilhar dados; 
2. Metadados bidirecional é atraente para corporações que querem implementar um 
repositório de metadados em toda empresa. 
 
Conceitos e tipos de Metadados 
 
Os metadados representam informações que caracterizam a informação documentada. 
Em essência, sobre cada faceta da informação, auxiliando a organização na sua 
publicação e suporte, esses respondem: 
• O que? 
• Quem? 
• Quando? 
• Onde? 
• Como? 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 15 
 
Além disso, em um ambiente marcado pela complexidade e distribuição das 
informações entre os diversos componentes da Arquitetura de ETL, os metadados 
proveem o relacionamento entre esses componentes e as respectivas informações que 
armazenam. 
 
Abaixo, veja o esquema geral do Metadados: 
 
 
 
 
Caracterização geral dos Tipos de Metadados 
 
Tipo de metadados Uso Exemplos 
De negócio Interpretação efetiva dos 
dados requeridos pelos 
processos de tomada de 
decisão. 
• Conceitos das métricas 
disponibilizadas em um 
Data Mart, bem como 
os dados que a 
compõem; 
• Conceitos e 
caracterização das 
consultas disponíveis 
sobre o Ambiente de 
BI. 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 16 
Técnico Criação, evolução e 
administração operacional 
do ambiente de BI. 
• Regras de captura, 
integração e 
transformação dos 
dados incorporados ao 
data Warehouse e/ou 
ODS; 
• Frequência de 
utilização das 
informações do 
ambiente; 
• Indicadores de 
qualidade dos dados. 
 
 
Organizando os Metadados 
 
As iniciativas em prol dos metadados enfrentam muitas dificuldades dentro do mundo 
corporativo, a começar pelo esforço de desenvolvimento de um repositório unificado 
(não existem soluções de prateleiras) capaz de capturar os metadados oriundos de 
múltiplas fontes. 
 
Desliza pela dificuldade de determinação de um ROI (Retorno do Investimento), passa 
pela aversão de técnicos e gestores, de forma geral, quanto ao serviço de 
documentação e, finalmente, repousa na pressão do negócio por entregas rápidas de 
produtos. 
 
Esses e outros fatores criam obstáculos que envolvem não somente o aspecto 
puramente técnico, mas ainda o cultural. Para alcançar um bom nível de qualidade, os 
metadados requerem um método de captura, descrição, manutenção e organização 
para, então, serem disponibilizados para a comunidade técnica e de negócio. Essas e 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 17 
outras atividades constituem o processo de Gestão ou Administração dos 
Metadados. 
 
Contudo, esse processo isoladamente não é capaz de alcançar seu propósito maior: 
manter vivo os metadados, ou seja, versionados a cada modificação da informação. 
 
Além da disponibilidade com alta confiabilidade, a informação precisar estar 
conceituada e contextualizada ao longo tempo de forma a preservar sua proficuidade 
para o negócio. Função essa cumprida pelos metadados. 
 
Infelizmente, o número de organizações que percebem, conscientemente, o valor dos 
metadados ainda é pequeno. Entretanto, o crescimento das iniciativas relativas à 
Governança de TI, bem como os casos de insucesso das iniciativas de BI, tem 
contribuindo para modificar esse cenário paulatinamente. 
 
 
 
Qualidade dos dados no ETL 
 
O que vem a ser realmente qualidade de dados? 
 
Por qualidade de dados entende-se o grau de aderência entre as visões apresentadas 
pelos dados armazenados e os mesmos dados no mundo real. 
 
Um nível de qualidade de dados de 100% indicaria perfeita aderência com o mundo 
real, enquanto que um nível de 0% indicaria total falta de aderência. 
 
Nenhum sistema de grande porte tem qualidade de dados de 100%. A grande questão 
não é garantir que a qualidade de dados seja perfeita, mas, sim, que seja 
suficientemente precisa, atualizada e consistente para que a organização possa 
sobreviver e tomar decisões razoáveis. 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 18 
A qualidade de dados ainda pode ser definida como “grau de adequação ao uso”, o 
que implica que o conceito de qualidade dos dados também tenha caráter relativo. 
Assim, dados considerados de qualidade apropriada para um uso específico podem 
não ter qualidade suficiente para outro uso. 
 
O controle da qualidade em bases de dados envolve todas as etapas do tratamento da 
informação, desde a sua criação até o uso final. 
 
Na tomada de decisão, a qualidade dos dados tem bastante impacto, pois cada vez 
mais organizações chegam à consciência da importância de disporem de um bom 
sistema de informações para apoiar a tomada de decisões. 
 
O desdobramento natural desse processo é a implantação de soluções em BI que 
possam ler as informações presentes em sistemas transacionais (ERP, CRM etc.) e, 
assim, fornecer análises de dados. 
 
O problema surge quando, ao coligir os dados, começam a aparecer incongruências, 
por apresentar dados que foram mal introduzidos ou imputados de outro setor da 
empresa, por exemplo. 
 
Apesar de somente comprometerem seriamente a eficiência das soluções em BI em 
sua fase de implantação, esses erros podem, contudo, contribuir para o 
desvirtuamento de índices e médias, complicando as análises. 
 
Sabemos que informação de qualidade é parte essencial do processo decisório. Os 
dados necessários para a consolidação das informações são um dos ativos mais 
importantes de qualquer empresa. 
 
Esses são os bens intangíveis que ajudam a manter a competitividade e que podem 
definir a sobrevivência da organização no mercado. Para isso acontecer, é necessário 
que os dados tenham a confiabilidade e precisão exigidas pelo negócio, pois estes são 
cruciais para um correto direcionamento das atividades empresariais. 
http://www.mxm.com.br/blog/2016/03/23/decisoes-mais-assertivas-com-business-intelligence/
http://www.mxm.com.br/blog/2016/12/23/software-erp-na-nuvem-ou-local-qual-melhor-opcao-para-sua-empresa/
https://www.profissionaisti.com.br/2013/09/projetos-de-implantacao-de-bi-principais-erros-e-dicas-para-corrigi-los/
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 19 
 
Além disso, eles devem ser precisos, consistentes e aderentes às regras de negócio. A 
qualidade de dados tem relação com a limpeza e padronização dos dados na 
construção de uma solução de Business Intelligence (BI). 
 
A Qualidade de Dados vai muito além de apenas ajustes nos dados. Através de 
auditoria nos dados, o BI possibilita fazer um mapeamento da real situação e assim 
traçar estratégias de melhoramento. 
 
Contudo, essa participação é só a ponta do iceberg. Em um mundo perfeito, esse seria 
um problema que não deviria preocupar os sistemas analíticos. Porém, como sabemos, 
o mundo não é perfeito. 
 
Pensando na Qualidade de Dados como parte influente (etambém influenciada) pelos 
processos empresarias, podemos entendê-la como sendo de responsabilidade de todos 
da organização. Por isso, todas as áreas de uma empresa são responsáveis 
solidárias pela qualidade que os dados apresentam. 
 
O processo de Qualidade de Dados, portanto, não pode ser confundido com 
ferramenta. Isso seria minimizar a real dimensão do problema. Ferramentas irão 
ajudar sim, desde que se adequem às necessidades do processo (não o contrário). 
Todavia, passar a responsabilidade apenas a elas poderá ser “um tiro no pé”. 
 
A perfeita aderência do processo de Qualidade de Dados ao negócio implica, entre 
outras coisas: 
• Aumento da produtividade; 
• Qualidade do serviço prestado aos clientes; 
• Melhoria na tomada de decisão. 
 
Para isso, devemos ter dados completos, consistentes e precisos. A falta de efetividade 
dos processos de negócios são causa e também consequência da má qualidade dos 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 20 
dados. É como se fosse um ciclo retroalimentado, onde a entrada (input) de dados de 
baixa qualidade em um processo gera uma saída (output) também de baixa qualidade. 
 
Esse irá realimentar o processo seguinte da cadeia de atividades até se chegar ao 
processo de decisão, fechando assim um círculo vicioso. 
 
 
Além do BI, a Qualidade de Dados envolve também áreas como gestão de dados, 
gestão da informação, qualidade, segurança da informação e gerenciamento de 
processos. 
 
O processo de desenvolvimento de uma solução de BI é um dos melhores meios para 
se encontrar distorções entre dados nos diversos sistemas da empresa. 
 
A etapa de melhoria da qualidade desses dados é de grande importância para auxiliar 
corretamente as decisões dos gestores. E cabe a eles definirem se essa melhoria deve 
ser temporária e reativa (apenas para a análise das informações estratégicas) ou se 
deverá ser estendida a todas operações do negócio. 
 
A qualidade de dados pode ser medida através de algumas dimensões (OLSON, 2003): 
• Acuracidade; 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 21 
• Disponibilidade em tempo; 
• Relevância; 
• Completude; 
• Compreensibilidade; 
• Confiabilidade. 
 
Veja a seguir o detalhamento de cada uma delas: 
 
Acuracidade 
 
É a medida de quão próximo o dado está do dado real. É a principal dimensão de 
qualidade de um dado. 
 
Se essa dimensão não atende a um nível satisfatório, o pleno atendimento a todas as 
demais dimensões não é significativo. 
 
Para um dado acurado, espera-se que o mesmo seja representado de forma 
consistente e não ambígua. 
 
Disponibilidade em tempo 
 
Implica em quão atualizado o dado encontra-se no momento em que é necessário 
para utilização. 
 
Relevância 
 
Diz respeito a quão útil o dado é no contexto em que se encontra inserido. 
 
Completude 
 
Indica o quão de acordo com amplitude e profundidade esperadas o dado se encontra. 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 22 
Compreensibilidade 
 
Indica o quão fácil é entender o dado e o quão além o dado vai da sua real 
necessidade. 
 
Confiabilidade 
 
Indica o quão corretas estão as fontes de dados, bem como as transformações pelas 
quais o dado sofreu. 
 
Desafios específicos de qualidade de dados para o BI 
 
Uma baixa qualidade de dados compromete totalmente uma implementação de BI. 
 
Segundo Redman (2001), são vários os desafios para se implementar um DW de alta 
qualidade. Os clientes de BI são diferentes dos clientes de sistemas operacionais, daí 
é natural que os requisitos de qualidade de dados sejam diferentes. 
 
As cadeias de processo de tomada de decisão costumam ser mais dificilmente 
entendidas do que as cadeias de processo operacionais, o que dificulta a compreensão 
das necessidades do cliente. 
 
Em sistemas transacionais, os dados novos costumam ser bem mais importantes. Em 
BI, os dados antigos também tem grande importância, então as necessidades do 
usuário envolvem também questões de histórico de informação. 
 
Grande parte dos dados de Data warehouse provém de sistemas transacionais. Como 
os dados para o BI exigem padronização e formatação de dados, a obtenção de dados 
em sistemas transacionais sem padronização definida pode esbarrar em complicadas 
questões políticas. 
 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 23 
Integração de Dados 
 
O termo integração de dados refere-se ao processo de combinar dados de diferentes 
fontes para prover uma única visão compreensível de todos os dados combinados. 
 
Pode ser abordado de diferentes formas, em diferentes níveis de abstração, desde a 
integração manual por usuários que interagem diretamente com todos os sistemas de 
informação relevantes, até a integração física dos dados pela transferência de dados 
para um novo depósito de dados comum. 
 
Hoje, temos a necessidade de integrar fontes de dados múltiplas e heterogêneas, 
bancos de dados relacionais e registros de transações online etc. Logo, limpeza de 
dados e técnicas de integração de dados são aplicadas, assegurando consistência em 
convenções de nomes, estruturas de codificação, medidas de atributos etc., entre 
diferentes fontes de dados. Por exemplo, o preço de hotel: moeda, taxas, se inclui 
café da manhã etc. 
 
Independentemente da arquitetura de BI, há um processo comum de integração de 
dados que é o ETL. 
Embora seja uma atividade que não é visível para os usuários finais (e patrocinadores), 
o ETL facilmente consome 70% dos recursos (pessoas, tempo, dinheiro) necessários 
para a implementação e manutenção da base de dados analítica. 
 
Qual a melhor maneira de projetar e construir um sistema de ETL? 
 
Isso “depende”: 
• Das fontes de dados; 
• Das limitações dos dados; 
• Das linguagens de script; 
• Das ferramentas de ETL disponíveis; 
• Das habilidades do pessoal envolvido (TI e negócio); 
• Da plataforma de BI. 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 24 
 
Existem alguns requisitos e restrições a considerar antes de projetar um sistema de 
ETL: 
• Necessidades do negócio (KPIs); 
• Conformidade legal dos dados; 
• Qualidade dos dados; 
• Segurança; 
• Integração de dados e sistemas; 
• Latência dos dados. 
 
Arquiteturas de Integração de dados 
 
• Consolidação de dados; 
• Virtualização de dados; 
• Propagação de dados; 
• Serviços de dados. 
 
Veja a especificação de cada uma: 
 
Consolidação de dados 
 
Os dados são capturados de múltiplas origens, na maioria dos casos em 
procedimentos batch com intervalos programados, tratados e integrados em um 
repositório único. 
 
Essa abordagem de consolidação é a mais utilizada para a geração do DW Corporativo, 
mas também aparece como opção para a criação de um “canal ou camada” de dados 
capaz de servir a sistemas de informação de diferentes finalidades. 
 
 
 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 25 
Virtualização de dados 
 
Também referenciada como Federação de dados, essa técnica provê uma integração 
dos dados correntes por meio de um mecanismo que captura e manipula os dados 
diretamente a partir das bases de origens. 
 
Como toda manipulação ocorre em tempo de execução, não há a sobrecarga e custos 
relativos a um repositório permanente, somente é necessário conhecer as origens dos 
dados. 
 
Por outro lado, esse mesmo fato impede que essa técnica seja utiliza em situações 
cujo nível de qualidade dos dados seja problemático, pois há potencial impacto sobre 
o tempo de resposta devido ao aumento da concorrência sobre as bases de origem. 
 
Propagação de dados 
 
Essa técnica realiza uma operação de cópia de dados de um local para outro que pode 
ocorrer de maneira assíncrona ou síncrona. 
 
Por ser orientada a evento. Diferentemente das outras citadas anteriormente, esta 
pode ser aplicada às necessidades de tráfego de dados em real time ou quase. 
 
Outro ponto relevante da técnica recai no seu uso em movimentaçõesbidirecionais, 
em procedimentos de backups incrementais e no balanceamento da carga de trabalho. 
 
Serviços de dados 
 
Essa arquitetura oferece uma forma de consumo de dados diferente das utilizadas até 
o momento. 
 
Viabilizada pelo SOA (Service Oriented Application). Sistemas de informação e dados 
perdem o forte acoplamento, isto é, os primeiros passam a consumir os dados que 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 26 
necessita por meio de solicitações a uma camada de serviços e não mais pelo acesso 
direto aos bancos de dados. 
 
Esses serviços podem ser utilizados para uma variedade de finalidades como: 
• Sincronização de dados; 
• Virtualização de dados; 
• Transformação de dados. 
 
Como trabalhar com ETL 
 
Existem duas maneiras de trabalharmos com o ETL, ou seja, executar a carga dos 
dados fontes (internos e/ou externos) no DW: 
 
• Desenvolver programas (códigos customizados) internos à empresa - 
essa opção tem um grande problema: a manutenção do projeto. Pois, todas às 
vezes que tivermos alguma alteração na carga, teremos que saber exatamente o 
que deverá ser alterado, podendo ser um ou vários programas, caso a 
documentação (metadados) não esteja atualizada. Isso pode acarretar sérios 
problemas, podendo colocar as decisões a serem tomadas em grandes riscos; 
 
• Adquirir no mercado ferramenta de ETL - a aquisição de ferramentas para a 
extração, limpeza e carga tem crescido exponencialmente devido ao problema 
citado acima, porém temos que analisar com cuidado a necessidade da empresa e 
os benefícios, pois estamos falando de custo, então esses pontos devem estar 
muito bem definidos. Essas ferramentas apresentam uma natureza de propósito 
ou finalidade única no que se refere ao estilo de integração e funcionalidades de 
qualidade de dados suportados, mas também possuem facilidades quanto à 
manutenção do projeto, pois existem recursos para analisarem tudo o que será 
afetado com a manutenção, além de possuírem metadados e uma análise de 
impacto do nível de alteração que está para acontecer. 
 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 27 
Perguntas sobre o processo de carga para o DW 
 
• “Se eu vou só transportar dados de um lugar para o outro, preciso comprar uma 
ferramenta pra isso?” 
• “É só pegar meia dúzia de tabelinhas do banco A e mais algumas do banco B e 
colocar no banco C, certo?” 
• “Para que ferramenta?” 
• “Além de ter de entender de PL/SQL, TSQL e Java, eu agora vou ter que aprender 
mais uma tecnologia só para transportar dados?” 
• “Não dá para fazer um programinha para poder fazer essas cargas?” 
• “Uma ferramenta de ETL é muito cara?” 
 
De fato, são questionamentos que à primeira vista parecem imbatíveis. Os custos com 
ferramentas de ETL podem ser expressivos, nenhum gestor irá despender recursos 
financeiros se julgar que eles não absolutamente necessários e isso se aplica a 
ferramentas de ETL. 
 
Avaliar o valor agregado de um novo servidor ou de um novo software é algo 
relativamente direto. Entretanto, avaliar os ganhos de uma ferramenta de ETL antes 
mesmo de adquiri-la já é algo bem mais complicado. 
 
Se o retorno é difícil de ser mensurado e de ser visto, naturalmente adquirir uma 
ferramenta de ETL pode não ser algo fácil. 
 
Dado esse contexto, é comum surgir os questionamentos: “Preciso mesmo de uma 
ferramenta de ETL?”; “Não dá para desenvolver isso na mão?” 
 
A resposta categórica de muitos fabricantes é simplesmente dizer que a ferramenta 
de ETL é indispensável, que tem várias vantagens, é mais performática etc. Não 
podemos discordar desses argumentos, mas possuir uma ferramenta de ETL não é 
indispensável para todas as situações e há cenários em que a construção hard code 
pode ser mais vantajosa. 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 28 
 
Há vantagens e desvantagens associadas à utilização de uma ferramenta ou fazer todo 
o processo hard code. 
 
A escolha em optar ou não por uma ferramenta de ETL juntamente com a 
complexidade do projeto é crucial na determinação do percentual gasto na extração 
dos dados a serem carregados no DW. Portanto, tenha sempre em mente que em toda 
aquisição de tecnologia existem necessidades que devem ser muito bem avaliadas. 
 
Ferramentas de ETL 
 
As ferramentas de ETL permitem acessar dados de várias origens (sources), 
transformá-los de acordo com as regras e validações do negócio e carregá-los nos 
mais variados sistemas de destino (targets). 
 
 
 
Elas oferecem benefícios significativos, como: 
• Controles especiais de carga; 
• Performance; 
• Conectividade com diversos tipos de sources e targets; 
• Interface de desenvolvimento amigável. 
 
Vale mencionar que, como em outros tipos de projetos, é essencial que se tenham 
claros os requisitos de negócio. Deve-se levar em conta que estamos normalmente 
falando de um grande volume de dados, que podem ser críticos para a tomada de 
decisão de negócios, por meio de relatórios e ferramentas OLAP. 
 
As ferramentas ETL existentes no mercado possuem meios de garantir boa 
performance durante os processos. Muitas dão suporte para cloud (nuvem) e realizam 
a integração com as mídias sociais. 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 29 
Um dos maiores desafios hoje para a prática de ETL é o custo para os projetos, 
influenciado por possíveis práticas inadequadas durante o desenvolvimento do projeto, 
mesmo utilizando ferramentas robustas. 
 
O retorno do investimento das iniciativas de ETL virá pela automatização de tarefas 
repetitivas que consumiriam horas de serviços profissionais e pela melhor qualidade 
da gestão propiciada pela tomada de decisão com dados entregues na hora certa e de 
maneira correta. 
 
Muitas ferramentas oferecem diferentes recursos, que devem ser avaliados conforme 
as necessidades da empresa e suas fontes de dados. 
 
Diferentes desafios podem fazer parte dessa escolha: 
• Capacidade de análise e armazenamento de dados pelas ferramentas; 
• Possibilidade de apoio à modelagem multidimensional; 
• Facilidade de integração em fusões e aquisições; 
• Relacionamento com outras empresas, clientes ou fornecedores. 
 
Abaixo veja algumas ferramentas líderes de mercado: 
 
• Informática - a principal ferramenta é o PowerCenter. Apesar de apresentar 
custo mais alto, a Informática tem se apresentado altamente capaz de se adaptar 
às necessidades do mercado; 
• IBM - a IBM vem com o InfoSphere DataStage também já com tradicional 
destaque. Como ponto forte de suas ferramentas está a diversidade de uso e 
amplitude de funcionalidades. Também de maior custo, tem feito esforços para 
promover ofertas e preços diferenciados; 
• SAP - o SAP Data Services e as outras soluções oferecidas pela companhia têm 
como atrativo o uso amplo, também pelas opções de integração com MDM e 
governança de dados em todo o ecossistema SAP. Funciona melhor para as 
empresas que já operam com SAP; 
https://www.informatica.com/br/products/data-integration/powercenter.html
https://www-01.ibm.com/software/data/infosphere/
http://go.sap.com/product/data-mgmt/data-services.html
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 30 
• Oracle - a principal ferramenta é o Oracle Data Integrator, que foi alvo de 
melhorias no último ano e tem a vantagem competitiva de oferecer integração com 
outros sistemas da marca. No entanto, os usuários apontam que este recurso ainda 
apresenta erros frequentes; 
• Talend - o Open Studio tem como vantagem seu sistema de licenciamento 
escalonável, que permite investimento progressivo; 
• Existem algumas ferramentas opensource que também devem ser analisadas, pois 
dependendo pode ser utilizada, a mais conhecida é o Pentaho. 
 
Conclusão 
 
Com o crescimento das empresas no mercado atual, a exigência de informação rápida 
e da maneira mais simples possível está cada vez maior. Isso porque empresas que 
demoram mais para tomadas de decisões acabam ficando para trás eperdendo 
competitividade. 
 
O BI atualmente é a fonte de informação mais importante para as empresas, porém 
não importa se essa fonte seja de fácil acesso ou se o acesso é rápido se as 
informações não estiverem lá. 
 
Outro problema que aparece é que as informações nunca estão em um único lugar, 
precisando assim integrá-las e convergi-las para um único ponto. 
 
Com isso, as soluções de ETL representam grande parte do setor de BI das empresas, 
pois ele é responsável por carregar e padronizar os dados de diversas fontes. Quanto 
mais rápido for esse processo, mais rápida é a disponibilização da informação para as 
áreas de gerência para tomadas de decisões e mais rápida será a resposta da empresa 
às variações do mercado. 
 
O processo ETL é o mais complexo e moroso na construção de um sistema DW, devido 
a aspectos já anteriormente vistos aqui. Nos dias de hoje, são disponibilizadas diversas 
ferramentas de ETL no mercado, cada uma com as suas particularidades. 
http://www.oracle.com/us/products/middleware/data-integration/059303.html
https://www.talend.com/products/talend-open-studio
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 31 
 
As suas capacidades de tratamento e manipulação de informação, aliadas à facilidade 
e simplicidade de utilização, tornam-nas uma referência entre as ferramentas ETL 
abordadas. 
 
Na aquisição de uma ferramenta desse tipo, é muito importante saber adequar essa 
escolha ao problema em questão, sendo que a produtividade na obtenção das 
informações geradas pelo DW refletirá o grau de acerto dessa escolha. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 32 
BIBLIOGRAFIA 
 
ELIAS, Diego. Entendendo o processo de ETL. Disponível em: 
<https://canaltech.com.br/business-intelligence/entendendo-o-processo-de-etl-
22850/> Acesso em: 19 março 2018. 
 
______. Qualidade de Dados - A Arte de Lapidar a Informação. Disponível em: 
<https://www.binapratica.com.br/data-quality>. Acesso em: 19 março 2018. 
 
FEINBERG, Donald. Data integration technology and architecture: building your 
data circulatory system. São Paulo: Gartner Enterprise Integration Summit, 2008. 
 
GONÇALVES, Rodrigo Ribeiro. Integração de Dados na Prátic. Ed. Erica, 2012. 
 
GONÇALVES, Marcio. Extração de dados para Data Warehouse. Rio de Janeiro: 
Axcel Books, 2003. 
 
HOKAMA, Daniele Del Bianco; CAMARGO, Denis; FUJITA, Francine; FOGLIENE, João 
Luiz Valentim. A modelagem de dados no ambiente Data Warehouse. Disponível 
em: <https://pt.scribd.com/doc/86014285/2004ModelagemDW>. Acesso em: 19 
março 2018. 
 
JORG, T.; DESSLOCH, S. Towards generating ETL processes for incremental 
loading. Ed. IDEAS, 2008. 
 
JOSKO, João Marcelo Borovina. Metadados – O significado da informação no 
ambiente de Business Intelligence. Disponível em: 
<https://www.devmedia.com.br/metadados-o-significado-da-informacao-no-
ambiente-de-business-intelligence/7417>. Acesso em: 19 março 2018. 
 
KIMBALL, Ralph; CASERTA, Joe. The DataWarehouse ETL Toolkit: Practical 
Techniques for Extracting Cleaning, Conforming and Delivering Data. Ed. Wiley, 2004. 
https://canaltech.com.br/business-intelligence/entendendo-o-processo-de-etl-22850/
https://canaltech.com.br/business-intelligence/entendendo-o-processo-de-etl-22850/
https://www.binapratica.com.br/data-quality
https://pt.scribd.com/doc/86014285/2004ModelagemDW
https://www.devmedia.com.br/metadados-o-significado-da-informacao-no-ambiente-de-business-intelligence/7417
https://www.devmedia.com.br/metadados-o-significado-da-informacao-no-ambiente-de-business-intelligence/7417
 
 
 INTEGRAÇÃO DE ARQUITETURA ETL 33 
 
______. ETL Toolkit. Ed. Wiley, 2008. 
 
MENDES, Carina. ODI – Gerenciamento de Metadados. Disponível em: 
<http://carinamendes.com/odi-gerenciamento-de-metadados/>. Acesso em 19 março 
de 2018. 
 
PANOS VASSILIADIS, P.; SIMITSIS, A.; GEORGANTAS, P.; TERROVITIS, M.; 
SKIADOPOULOS, S. Ageneric and customizable frameworkfor the design of 
ETL scenarios. Ed. Information Systens 30, 2005. 
 
REDMAN, Thomas. Data Quality: The Field Guide. 1. ed. Ed. Digital Press, 2000. 
 
RIBEIRO, Viviane. All about Data. Disponível em: 
<https://vivianeribeiro1.wordpress.com/2011/06/28/o-que-e-etl-2/>. Acesso em: 19 
março 2018. 
 
SANTOS, Maribel Yasmina. Business Intelligence: Tecnologias da Informação na 
Gestão de Conhecimento. Ed. FCA e Ed. Informática, 2006. 
 
TAKANA, Asterio K. Tópicos Avançados de Banco de Dados (Business 
Intelligence). Integração de Dados e ETL. Disponível em: 
<http://www.uniriotec.br/~tanaka/SAIN/03-ETL-2015.1.pdf>. Acesso em: 19 março 
2018. 
 
http://carinamendes.com/odi-gerenciamento-de-metadados/
https://vivianeribeiro1.wordpress.com/2011/06/28/o-que-e-etl-2/
http://www.uniriotec.br/~tanaka/SAIN/03-ETL-2015.1.pdf