Business intelligence na prática_ modelagem multidimensional e data warehouse - UNIASSELVI

Prévia do material em texto

Indaial – 2020
Business intelligence 
na prática: ModelageM 
MultidiMensional e data 
Warehouse
Prof. Rodrigo Ramos Nogueira
1a Edição
Copyright © UNIASSELVI 2020
Elaboração:
Prof. Rodrigo Ramos Nogueira
Revisão, Diagramação e Produção:
Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri 
UNIASSELVI – Indaial.
Impresso por:
N778b
Nogueira, Rodrigo Ramos
Business intelligence na prática: modelagem 
multidimensional e data warehouse. / Rodrigo Ramos Nogueira. – 
Indaial: UNIASSELVI, 2020.
177 p.; il.
ISBN 978-85-515-0454-3
1. Banco de dados. - Brasil. Centro Universitário 
Leonardo Da Vinci.
CDD 005.74
III
apresentação
Caro acadêmico!
Estamos iniciando o estudo da disciplina Business Intelligence na 
Prática: Modelagem Multidimensional e Data Warehouse. Esta disciplina 
objetiva proporcionar uma imersão de conceitos teóricos e principalmente 
práticos de como construir sistemas de Business Intelligence proporcionan-
do um poder decisório nas organizações.
Este livro conta com diversos recursos didáticos externos, por isso, 
recomendamos fortemente que você realize todos os exemplos e exercícios 
para um aproveitamento excepcional da disciplina. Aproveitamos a opor-
tunidade para destacar a importância de desenvolver as autoatividades, 
lembrando que elas não são opcionais, visto que objetivam a fixação dos 
conceitos apresentados. Em caso de dúvida na realização das atividades, su-
gerimos que você entre em contato com seu tutor externo ou com a tutoria 
da UNIASSELVI, não prosseguindo nas atividades sem ter sanado todas as 
dúvidas que, eventualmente, poderão surgir.
Neste contexto, o livro de Business Intelligence na Prática está divi-
dido em três unidades de estudo. A Unidade 1 tratará dos assuntos Progra-
mação para Big Data, tipos de dados e armazenamento e Data Warehouse. 
Na Unidade 2 estudaremos sobre OLAP x OLTP, extração, transformação e 
carga e, por fim, transformações na prática. Já a Unidade 3 abordará sobre 
modelagem multidimensional, operações e servidores OLAP e ferramentas 
de dashboards.
Bom estudo! Sucesso na sua trajetória acadêmica e profissional!
IV
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para 
você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novi-
dades em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é 
o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um 
formato mais prático, que cabe na bolsa e facilita a leitura. 
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagra-
mação no texto, aproveitando ao máximo o espaço da página, o que também contribui para 
diminuir a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, 
apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade 
de estudá-lo com versatilidade nas telas do celular, tablet ou computador. 
 
Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para apre-
sentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto em 
questão. 
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas institu-
cionais sobre os materiais impressos, para que você, nossa maior prioridade, possa continuar 
seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de De-
sempenho de Estudantes – ENADE. 
 
Bons estudos!
NOTA
V
VI
Olá, acadêmico! Iniciamos agora mais uma disciplina e com ela 
um novo conhecimento. 
Com o objetivo de enriquecer seu conhecimento, construímos, além do livro 
que está em suas mãos, uma rica trilha de aprendizagem, por meio dela você 
terá contato com o vídeo da disciplina, o objeto de aprendizagem, materiais complemen-
tares, entre outros, todos pensados e construídos na intenção de auxiliar seu crescimento.
Acesse o QR Code, que levará ao AVA, e veja as novidades que preparamos para seu estudo.
Conte conosco, estaremos juntos nesta caminhada!
LEMBRETE
VII
UNIDADE 1 - INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE .......1
TÓPICO 1 - BIG DATA – A EXPLOSÃO DOS DADOS ....................................................................3
1 INTRODUÇÃO .......................................................................................................................................3
2 A EXPLOSÃO DOS DADOS ................................................................................................................3
2.1 BUSINESS INTELLIGENCE .............................................................................................................5
2.2 BUSINESS INTELLIGENCE – MECANISMOS PRÁTICOS........................................................8
RESUMO DO TÓPICO 1........................................................................................................................13
AUTOATIVIDADE .................................................................................................................................14
TÓPICO 2 - TIPOS DE DADOS E EXEMPLOS DE ARMAZENAMENTO .................................17
1 INTRODUÇÃO .....................................................................................................................................17
2 DADOS ESTRUTURADOS ................................................................................................................18
3 DADOS SEMIESTRUTURADOS .....................................................................................................21
3.1 DOCUMENTO XML .......................................................................................................................21
3.2 ARQUIVOS CSV ..............................................................................................................................23
3.3 JSON...................................................................................................................................................24
3.4 BSON - MONGODB ........................................................................................................................25
4 DADOS NÃO ESTRUTURADOS .....................................................................................................27
RESUMO DO TÓPICO 2........................................................................................................................30
AUTOATIVIDADE .................................................................................................................................31
TÓPICO 3 - INTRODUÇÃO AO DATA WAREHOUSE ..................................................................35
1 INTRODUÇÃO .....................................................................................................................................35
2 DATA WAREHOUSE ...........................................................................................................................36
2.1 ARQUITETURA PROPOSTA POR INMON ................................................................................38
2.2 ARQUITETURA PROPOSTA POR KIMBALL ............................................................................40
RESUMO DO TÓPICO 3........................................................................................................................51
AUTOATIVIDADE .................................................................................................................................52
UNIDADE 2 - BUSINESS INTELLIGENCE NA PRÁTICA: EXTRAÇÃO, 
 TRANSFORMAÇÃO E CARGA .................................................................................55
TÓPICO 1 - OLAP x OLTP .....................................................................................................................571 INTRODUÇÃO .....................................................................................................................................57
2 OLAP VS OLTP .....................................................................................................................................58
2.1 MODELAGEM E PROGRAMAÇÃO EM AMBIENTES TRANSACIONAIS .........................59
2.2 OLTP - UTILIZANDO SQL ...........................................................................................................60
RESUMO DO TÓPICO 1........................................................................................................................65
AUTOATIVIDADE .................................................................................................................................66
TÓPICO 2 - EXTRAÇÃO, TRANSFORMAÇÃO E CARGA ...........................................................67
1 INTRODUÇÃO .....................................................................................................................................67
2 FERRAMENTAS DE ETL ....................................................................................................................69
suMário
VIII
2.1 ETL E BIG DATA STREAMING ...................................................................................................70
2.2 ETL NA NUVEM .............................................................................................................................73
2.3 PENTAHO DATA INTEGRATION ...............................................................................................74
2.4 PROGRAMANDO UMA FERRAMENTA DE ETL ....................................................................75
2.5 EXTRAÇÃO - REALIZANDO A EXTRAÇÃO DE DADOS ......................................................76
2.6 EXTRAÇÃO COM PENTAHO DATA INTEGRATION .............................................................76
2.7 EXTRAÇÃO UTILIZANDO PYTHON .........................................................................................79
RESUMO DO TÓPICO 2........................................................................................................................81
AUTOATIVIDADE .................................................................................................................................82
TÓPICO 3 - TRANSFORMAÇÕES NA PRÁTICA ...........................................................................85
1 INTRODUÇÃO .....................................................................................................................................85
2 TRANSFORMAÇÃO POR AGRUPAMENTO ...............................................................................86
2.1 TRANSFORMAÇÕES NUMÉRICAS, TEXTUAIS E CONVERSÕES ......................................92
2.2 TRANSFORMAÇÃO UTILIZANDO MACHINE LEARNING PARA ENRIQUECIMENTO 
SEMÂNTICO ....................................................................................................................................96
RESUMO DO TÓPICO 3......................................................................................................................104
AUTOATIVIDADE ...............................................................................................................................105
UNIDADE 3 - VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS ........107
TÓPICO 1 - MODELAGEM MULTIDIMENSIONAL ...................................................................109
1 INTRODUÇÃO ...................................................................................................................................109
2 MODELAGEM MULTIDIMENSIONAL .......................................................................................109
2.1 COMPONENTES DA MODELAGEM MULTIDIMENSIONAL ............................................111
2.1.1 Métricas ..................................................................................................................................113
2.1.2 Tipos de Tabelas Fato ...........................................................................................................113
2.2 PREPARANDO O AMBIENTE DE IMPLEMENTAÇÃO DE UM DATA WAREHOUSE ..114
2.2.1 Fato Transacional .................................................................................................................118
2.2.2 Fato por agrupamento de dados: Agregada, Snapshot e Consolidada ..........................119
2.2.3 Tipos de Dimensões .............................................................................................................121
2.2.4 Degenerate Dimension .........................................................................................................121
2.2.5 Slowly Changing Dimensions .............................................................................................122
2.2.6 Role-playing Dimension ......................................................................................................123
2.2.7 A Dimensão Tempo ..............................................................................................................124
2.3 OS MODELOS DE DADOS MULTIDIMENSIONAIS..............................................................125
2.3.1 Modelo Estrela ......................................................................................................................126
2.3.2 Modelo Snowflake ................................................................................................................128
RESUMO DO TÓPICO 1......................................................................................................................135
AUTOATIVIDADE ...............................................................................................................................136
TÓPICO 2 - OPERAÇÕES E SERVIDORES OLAP ........................................................................139
1 INTRODUÇÃO ...................................................................................................................................139
2 SERVIDORES E CLIENTES OLAP ................................................................................................139
2.1 TIPOS DE SERVIDORES OLAP ...................................................................................................140
2.1.1 ROLAP – Relational On Line Analytical Processing .......................................................140
2.1.2 MOLAP – Multidimensional On Line Analytical Processing ........................................141
2.1.3 HOLAP – Hybrid On Line Analytical Processing ...........................................................142
2.1.4 DOLAP – Desktop On Line Analytical Processing ..........................................................142
2.1.5 O Cubo OLAP .......................................................................................................................143
2.1.6 Operações OLAP ..................................................................................................................146
2.1.7 Slice .........................................................................................................................................146
IX
2.1.8 Dice .........................................................................................................................................147
2.1.9 Drill-Down .............................................................................................................................148
2.1.10 Roll-Up .................................................................................................................................149
RESUMO DO TÓPICO 2......................................................................................................................152
AUTOATIVIDADE ...............................................................................................................................153
TÓPICO 3 - FERRAMENTAS DE DASHBOARDS ........................................................................1551 INTRODUÇÃO ...................................................................................................................................155
2 PENTAHO ............................................................................................................................................156
2.1 POWER BI .......................................................................................................................................158
RESUMO DO TÓPICO 3......................................................................................................................160
AUTOATIVIDADE ...............................................................................................................................161
REFERÊNCIAS .......................................................................................................................................163
X
1
UNIDADE 1
INTRODUÇÃO AO BUSINESS 
INTELLIGENCE E DATA WAREHOUSE
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
A partir do estudo desta unidade, você deverá ser capaz de:
• contextualizar sobre big data e volume de dados;
• conhecer sobre o papel dos usuários na geração de dados;
• saber mais sobre conceitos de Business Intelligence;
• ter uma visão geral sobre projetos de Business Intelligence;
• aprender sobre os tipos de dados;
• conhecer o conceito de Data Warehouse;
• refletir sobre as arquiteturas de Data Warehouse existentes.
Esta unidade de ensino contém três tópicos. No final de cada um deles você 
encontrará autoatividades que contribuirão para a apropriação dos conteúdos.
TÓPICO 1 – BIG DATA – A EXPLOSÃO DOS DADOS
TÓPICO 2 – TIPOS DE DADOS E ARMAZENAMENTO
TÓPICO 3 – INTRODUÇÃO AO DATA WAREHOUSE
Preparado para ampliar seus conhecimentos? Respire e vamos 
em frente! Procure um ambiente que facilite a concentração, assim absorve-
rá melhor as informações.
CHAMADA
2
3
TÓPICO 1
UNIDADE 1
BIG DATA – A EXPLOSÃO DOS DADOS
1 INTRODUÇÃO
Há 20 anos era muito custoso ter um computador e poucos tinham acesso 
a ele. Os que tinham utilizavam internet discada e no máximo 56 kbps/s. Se você 
nasceu antes dos anos 2000, provavelmente conhecia bem o barulhinho para se 
conectar à internet discada, aos que desconhecem, para se conectar, era preciso 
ter uma linha telefônica, que ficava ocupada durante a utilização da internet. Para 
acompanhar as revoluções tecnológicas, eram vendidas revistas sobre o assunto 
nas bancas de jornais.
Em paralelo a isso, a internet vivia sua primeira revolução nos anos 2000. 
Enquanto usuários se preocupavam com o Bug do Milênio, as gigantes da tecno-
logia começavam a ter seus primeiros problemas de armazenamento. As gigantes 
da computação, como Google e Amazon, foram obrigadas a desenvolver suas 
próprias soluções para armazenar seu volume de dados, que passavam de cente-
nas de Terabytes. Em 2009, devido à dimensão desse problema, houve uma reu-
nião com os grandes nomes do armazenamento de dados em busca de soluções.
O volume de dados era tão grande que diversas tecnologias estavam em 
ascensão: a Google com o Big Table, a Amazon com o DynamoDB e o Facebook já 
aparecendo no cenário com suas próprias tecnologias. Você já parou para pensar 
qual é o seu papel durante essa explosão de dados?
2 A EXPLOSÃO DOS DADOS
Você tem noção da quantidade de informação que você gera diariamente? 
Seja pelas mídias sociais, aplicativos de mensagens ou até mesmo softwares espe-
cíficos, diariamente produzimos uma grande massa de dados. 
Durante muitos anos, os usuários foram apenas consumidores de informa-
ção e conteúdo. Um programa de TV, tradicionalmente, mensurava sua audiência 
pelo ibope e o número de pessoas assistindo em capitais. Hoje, enquanto um pro-
grama é transmitido, as pessoas comentam sobre ele na internet, com isso, além do 
envolvimento do público, também é possível aproveitar os dados fornecidos. 
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
4
Todos os comentários sobre determinado programa formam uma grande 
base de dados, sob o qual é possível extrair conhecimento, principalmente saber 
se as pessoas estão ou não gostando do que está sendo transmitido. 
FIGURA 1 – INTERAÇÃO COM REDES SOCIAIS
FONTE: http://bit.ly/2IeY0QX. Acesso em: 1º jan. 2020.
É claro que o uso de smartphones não é o único responsável pela geração 
de dados em larga escala no mundo. Com a utilização de smartwatches, pulsei-
ras, sensores de precisão, entre os mais diversos tipos de conectados, o volume 
de dados aumentou significativamente, complementado pela grande variedade 
de tipos de dados. 
O número de dispositivos conectados à Internet, incluindo as máquinas, 
sensores e câmeras que compõem a Internet das Coisas (IoT), continua crescendo a 
um ritmo constante. Uma nova previsão da International Data Corporation (IDC) 
estima que haverá 41,6 bilhões de dispositivos conectados à IoT, gerando 79,4 zet-
tabytes (ZB) de dados em 2025. À medida que o número de dispositivos IoT co-
nectados aumenta, a quantidade de dados gerados por esses dispositivos também 
cresce. Alguns desses dados são pequenos e intermitentes, indicando uma única 
métrica de integridade de uma máquina, enquanto grandes quantidades de dados 
podem ser geradas por câmeras de vigilância por vídeo usando a visão computa-
cional para analisar multidões de pessoas, por exemplo (SEGINFO, 2020).
Após você compreender o seu papel na geração de dados no seu cotidia-
no, definiremos, a seguir, o conceito de Big Data. 
Big Data é um grande volume de dados, coletado das mais variadas fontes 
e tipos de dados, em que se deseja extrair insights com velocidade, armazenando 
TÓPICO 1 | BIG DATA – A EXPLOSÃO DOS DADOS
5
dados com veracidade, sob o qual se permite extrair informação com valor. Esses 
cinco itens em destaque são definidos como os 5 Vs do Big Data (volume, varia-
das/variedade, velocidade, veracidade e valor). 
Big Data não trata apenas da dimensão volume, como parece à pri-
meira vista, mas existe também uma variedade imensa de dados, não 
estruturados, dentro e fora das empresas (coletados das mídias sociais, 
por exemplo), que precisam ser validados (terem veracidade para se-
rem usados) e tratados em velocidade adequada para terem valor para 
o negócio. A fórmula é, então, Big Data = volume + variedade + veloci-
dade + veracidade, gerando valor (TAURION, 2013 p. 19).
FIGURA 2 – OS Vs DE BIG DATA
FONTE: https://brunovasconcelos.me/2018/02/26/o-que-e-big-data/. Acesso em: 1º jan. 2020.
O volume de dados disponível mais do que dobra a cada dois anos e os 
algoritmos aperfeiçoam-se rapidamente, ao passo que, em razão quase inversa-
mente proporcional, os custos de armazenamento decrescem. Técnicas de análise 
de dados, antes acessíveis apenas às agências de espionagem, laboratórios de pes-
quisa e grandes conglomerados comerciais são, paulatinamente, democratizadas 
(MAYER-SCHONBERGER; CUKIER, 2014).
Quando falamos do papel de Big Data nas organizações, não estamos fala-
mos apenas em gerar um grande volume de dados, mas sim de utilizar estes dados 
para gerar conhecimento organizacional para tomada de decisões estratégicas, sen-
do que, para isso, muitas vezes, utilizamos técnicas de Business Intelligence. 
2.1 BUSINESS INTELLIGENCE
Iniciamos nosso estudo falando do grande volume de dados e da sua im-
portância para as organizações. No entanto, a preocupação com o armazenamen-
to e a extração de conhecimento é algo secular, visto que se nos aprofundarmos 
iremos parar em 18.000 a.C., os quais nossos ancestrais utilizavam ossos de ba-
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
6
buíno para fazer operações matemáticas cravadas (armazenadas) em paredes das 
cavernas. Podemos, também, utilizar como exemplo os desenhos rupestres que 
foram feitos há mais de 40.000 anos e que serviram para armazenar dados sobre 
a história humana. 
FIGURA 3 – ARMAZENAMENTO DE DADOS NO PASSADO
FONTE: O autor
Quando trazemos essa reflexão para a história recente,caminhamos para 
os anos 1980, quando muita coisa aconteceu no mundo da computação, princi-
palmente no que tange à revolução dos computadores pessoais e dos sistemas 
operacionais. No mundo dos dados não foi diferente, muita coisa aconteceu nes-
sa década que impactam na nossa vida até hoje. 
Um destaque especial para os nomes de Edgar Frank Codd e Richard Mil-
ler Devens. Codd, em seu artigo “A relational model of data for large shared data 
banks”, publicado em 1983, explica que sua arquitetura para armazenamento de 
dados relacionais, utilizada majoritariamente em todas as organizações, serve 
como base para o desenvolvimento de novas tecnologias de bancos de dados. 
Já Devens, em seu livro “Cyclopaedia of commercial and business anecdotes”, 
publicado em 1864, descreve que a iniciativa de coletar dados e a capacidade 
de extrair informação nos resultados coletados auxilia as organizações em suas 
tomadas de decisão. Para ele, Business intelligence é a capacidade de coletar in-
formações e reagir a elas.
O conceito de Business Intelligence é utilizado para definir todo o conjun-
to de tecnologias e processos utilizados na coleta, organização, análise, compar-
tilhamento e monitoramento de dados, com ênfase para dar suporte a decisões 
estratégicas. Ainda assim, houve diversos autores que trouxeram suas definições 
para o termo Business Intelligence, o grande ponto é que como Business Intelli-
gence tem como base à coleta de dados para a geração de informações organiza-
cionais, é um termo que já sofreu e pode sofrer mutações, conforme o cenário dos 
dados mudam no mundo. 
TÓPICO 1 | BIG DATA – A EXPLOSÃO DOS DADOS
7
A seguir, o conceito, a definição e os objetivos de Business Intelligence na 
perspectiva de alguns autores.
QUADRO 1 – DEFINIÇÕES DE BUSINESS INTELLIGENCE
Um sistema automático para disseminar informação para vários setores de 
qualquer empresa, utilizando máquinas de processamento de dados (compu-
tadores), autoabstração e autocodificação de documentos e criando perfis para 
cada ponto de ação da organização por palavra padrão (LUHN, 1958).
É a aplicação de um conjunto de técnicas e ferramentas que são propostas para 
auxiliar na administração de um negócio e na tomada de decisões (SANTOS, 2009).
Pode ser definido como o apoio de modelos matemáticos e metodologias de 
análise que explorem os dados disponíveis para gerar informação e conheci-
mento para processos de tomada de decisões complexas (VERCELLIS, 2009).
Refere-se às aplicações e tecnologias para consolidar, analisar e oferecer acesso a 
grandes quantidades de dados, para ajudar os usuários a tomarem melhores de-
cisões empresariais e estratégicas. As aplicações de BI oferecem visões históricas, 
atuais e previsíveis das operações de negócio (RAINER; CEGIELSKI, 2011).
De forma mais ampla, pode ser entendido como a utilização de variadas fontes 
de informação para definir estratégias de competitividade nos negócios da em-
presa. Podem ser incluídos nesta definição os conceitos de estruturas de dados, 
representadas pelos bancos de dados tradicionais, data warehouse e data marts, 
criados objetivando o tratamento relacional e dimensional de informações, bem 
como as técnicas de data mining aplicadas sobre elas, buscando correlações e 
fatos “escondidos” (BARBIERI, 2011).
Une dados, tecnologia, análises e conhecimento humano para otimizar decisões 
nos negócios e ultimamente tem dirigido o sucesso das empresas. Programas de 
BI usualmente combinam um Data Warehouse empresarial (EDW) e uma pla-
taforma de ferramentas de BI para transformar dados em informações usáveis 
para o negócio (TDWI, 2013). 
Refere-se à coleção de SIs e de tecnologias que dão suporte à tomada de decisão 
gerencial ou operacional – controle pelo fornecimento de informações nas ope-
rações internas e externas (TURBAN; VOLONIMO, 2013).
Em alguns momentos deste livro você se deparará com os termos: “suporte à 
tomada de decisão gerencial”, “suporte às decisões da organização” ou algo relacionado 
a empresas, muitas vezes esse tipo de aplicação só existe em grandes corporações. Por 
isso, é muito importante frisar que esses conceitos foram cunhados porque tais tecnolo-
gias surgiram dentro de empresas, no entanto, o emprego de tais tecnologias se aplica a 
qualquer setor. Por exemplo, uma ONG pode ter um sistema de Business Intelligence para 
saber quais os melhores locais para fazer ações de reflorestamento ou um líder comunitá-
rio pode ter um sistema de Business Intelligence para monitorar o rendimento das crianças 
de uma comunidade na escola.
IMPORTANT
E
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
8
É um termo guarda-chuva que inclui aplicações, infraestrutura e ferramentas e 
as melhores práticas que permitem acesso e análise de informações para promo-
ver e otimizar decisões e performance (GARTNER, 2013). 
Refere-se às aplicações e tecnologias que são utilizadas para coletar, acessar 
e analisar dados e informações de apoio à tomada de decisão (BALTZAN; 
PHILLIPS, 2012). 
É o processo de transformação de dados brutos em informações utilizáveis para 
maior efetividade estratégica, insights operacionais e benefícios reais para o 
processo de tomada de decisão nos negócios (DUAN; XU, 2012).
FONTE: Adaptado de Botelho e Razzolini Filho (2014)
Conforme vimos, Business Intelligence pode ser assimilado de diversas 
maneiras, mas ao analisar tais definições, é possível compreender que essa ferra-
menta utiliza os dados da organização para dar suporte à tomada de decisões, ou 
seja, Business Intelligence é o processo de utilizar os dados em favor da organi-
zação, extraindo conhecimento e insights a partir deles. Vamos entender melhor 
como ele se aplica na prática?
2.2 BUSINESS INTELLIGENCE – MECANISMOS PRÁTICOS
Agora que você compreendeu os conceitos e a definição de Business In-
telligence, falaremos um pouco de como isso acontece na prática. De modo geral, 
para entender como um sistema de BI funciona, torna-se essencial a compreensão 
de seus elementos. Para isso, precisamos conhecer o tripé da gestão de sistemas 
inteligentes: dados, informação e conhecimento. 
FIGURA 4 – DADOS, INFORMAÇÃO E CONHECIMENTO
FONTE: <http://bit.ly/2VFdINl>. Acesso em: 1º jan. 2020.
TÓPICO 1 | BIG DATA – A EXPLOSÃO DOS DADOS
9
• Dados: são fatos de um mundo real, que estão armazenados em algum lugar, 
mas que não possuem sentido, pode-se dizer que o dado é a informação em sua 
forma bruta, ou seja, ainda não lapidada. Segundo Valentim (2002), dados são 
simples observações sobre o estado do mundo.
• Informação: são dados dotados de relevância e propósito; são dados organiza-
dos de modo significativo, ou seja, que possuem algum sentido, é aquilo que 
leva à compreensão (VALENTIM, 2002). 
• Conhecimento: vem de discernimento, prática e experiência de vida. O conhe-
cimento é extraído a partir dos dados e informações armazenadas, sendo aqui-
lo que não pode ser visto por uma perspectiva humana, mas sim extraída. Na 
visão de Valentim (2002), o conhecimento é uma informação valiosa da mente 
humana. Inclui reflexão, síntese e contexto.
No cenário de BI, nosso objetivo é justamente coletar dados de uma ou 
várias fontes, armazená-los em uma estrutura organizada que permita extrair in-
formação e executar algoritmos que permitam gerar conhecimento. 
Para compreender melhor, vejamos o exemplo a seguir:
A AgroGama é uma empresa que gerencia um conjunto de fazendas e 
consta com diversos sócios, entre eles donos das terras e acionistas. Os equipa-
mentos utilizados durante o plantio são todos da indústria agro 4.0, ou seja, as 
colheitadeiras inteligentes emitem relatório dos grãos colhidos diretamente para 
um servidor; com isso, é possível saber a qualidade dos produtos, bem como a 
quantidade. Também há o uso de um sistema de informação em cada fazenda 
para controle de funcionários, animais e da produção interna. Os gestores da em-
presa agora precisam que seja desenvolvido um sistema de Business Intelligence 
que permita quese obtenham informações gerenciais sobre todas as fazendas 
para que se possa obter insights e tomar decisões.
 
Com base nesse texto, para aplicarmos o BI, faremos alguns questiona-
mentos:
• Onde estão os dados?
R.: Os dados são oriundos dos sensores, dos aplicativos e dos sistemas já utiliza-
dos. São exemplos de dados: soja, feijão, 3.00, 4000, alto, médio, baixo. 
• Onde está a informação?
R.: A informação acontece visto que há estrutura nesses dados, permitindo com 
que tenham sentido. Por exemplo: o feijão custa R$ 4,50 o kg na venda, a fazenda 
X produz 4000 kg de soja por mês. 
• Onde está o conhecimento?
R.: O conhecimento acontecerá a partir de perguntas que não podem ser formula-
das a partir dos dados armazenados. Por exemplo: “Qual a fazenda mais produti-
va?” é uma questão que pode ser respondida a partir da análise dos dados. O co-
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
10
nhecimento vai além, permitindo retornar coisas como “Todas as quintas-feiras, 
se a temperatura subir e chover a mais do que 30 mm, haverá baixa na produção” 
ou “Todas as fazendas que produzem milho e soja, mas não tem gado, têm uma 
produção abaixo da média”.
Note que, nesse exemplo, falamos sobre o que é feito, mas não como é 
feito. Do ponto de vista de tecnologias empregadas, não há uma exatidão para 
que haja um cenário de Business Intelligence, é importante que os dados sejam 
coletados, que tenha-se uma estrutura sólida de armazenamento e que possamos 
extrair conhecimento em cima do que foi armazenado. 
FIGURA 5 – EXEMPLO DE ARQUITETURA DE UM SISTEMA DE BUSINESS INTELLIGENCE 
FONTE: Siteware (2020, s.p.)
No geral, cada implementação de um Business Intelligence tem três pilares:
• Coleta de dados: no primeiro momento, todas as informações e dados da em-
presa são coletados e analisados. São determinadas características como: pro-
dutividade, oportunidades, reputação etc.
TÓPICO 1 | BIG DATA – A EXPLOSÃO DOS DADOS
11
• Organização e análise: os dados e informações recolhidos e analisados são or-
ganizados em bancos de dados. Para facilitar a visualização dos gestores, po-
de-se apresentá-los visualmente, com o auxílio de ferramentas e plataformas.
• Ação e monitoramento: os responsáveis tomam decisões baseadas nas infor-
mações analisadas e monitoram seus resultados.
Não existe uma arquitetura geral para o desenvolvimento de uma arqui-
tetura de Business Intelligence, o importante é que a arquitetura contenha os pi-
lares de um sistema de BI.
Excel - a Eterna Ferramenta de Business Intelligence
O Microsoft Excel se torna quase imbatível quando o tema é geração de relatórios, neste 
exato momento, milhares de pessoas estão gerando relatórios no Excel enquanto outras 
milhares estão estudando como fazê-lo. 
O Visicalc, desenvolvido por Dan Bricklin, conhecido como o “pai das planilhas eletrôni-
cas”, foi o precursor das planilhas eletrônicas e também pela utilização dos computadores 
pessoais. Naquela época, os computadores existentes custavam cerca de R$ 15 mil, tam-
bém não existia a Internet (pelo menos não como a conhecemos hoje) e havia poucos 
softwares de gestão. Com toda essa explanação, para que se comprava um computador? 
As planilhas eletrônicas justificavam o investimento, pois além de armazenarem os dados 
sobre a gestão das empresas, tornaram-se as primeiras ferramentas de inteligência de 
negócios e suporte à decisão.
Estamos em 2020, passaram-se mais de 30 anos desde a criação das planilhas e há uma 
imensidão de ferramentas computacionais para gestão de empresas e suporte à decisão. 
Por que, então, o Excel ainda é tão utilizado? São diversos fatores que fazem da ferramen-
ta obter tanto número de usuários, o principal com certeza é a sinergia do Pacote Office 
com o sistema operacional Windows, que apenas na versão 10 alcançou 270 milhões de 
usuários em todo mundo. 
A ferramenta é imensamente utilizada pelas empresas para os mais diversos tipos de funcio-
nalidades. Independentemente do porte ou segmento da organização, é uma ferramenta al-
tamente difundida no ambiente empresarial, pois oferece infinitas possibilidades para manter 
os processos automatizados e organizados. Os recursos do Excel permitem que o usuário 
faça cálculos complexos, principalmente aqueles que envolvem a área financeira de um 
negócio. Além disso, é possível criar uma planilha de gastos, uma planilha para controlar o 
fluxo de caixa, calcular preços dos produtos e serviços oferecidos pela empresa, registrar os 
pagamentos, toda a parte contábil da organização, entre outras funcionalidades.
Um outro fator muito impactante no uso da ferramenta é o fato de as empresas comu-
mente utilizarem softwares ERP para realizar a gestão de todos os processos organizacio-
nais, por exemplo, o SAP. Este tipo de software é informalmente chamado de “engessado”, 
pois, ao invés de se adaptar às rotinas da empresa, é a empresa que se adapta ao funcio-
namento do software. 
Muitas vezes, as empresas precisam gerar relatórios específicos que atendam às suas ne-
cessidades particulares e estes relatórios não são fornecidos pelo software ERP, a empresa, 
então, pode até fazer uma requisição e solicitar que seja implementado, mas isso envol-
NOTA
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
12
FONTE: O autor
Uma vez tendo acesso aos dados através de planilhas, estes são integrados, também em 
planilhas, cabendo à empresa gerar seus próprios relatórios, importando várias planilhas, 
consolidando, explorando e utilizando os mais diversos recursos. 
FONTE: Adaptado de: NOGUEIRA, R. Análise de dados usando dashboards. Indaial: 
UNIASSELVI, 2019.
ve tempo e alto custo. Em contrapartida, os ERPs fornecem diversos relatórios sobre os 
módulos (financeiro, comercial, gestão, estoque, entre outros) e estes mesmos relatórios 
podem ser importados no formato de planilhas eletrônicas.
FIGURA 6 – EXEMPLO DE GERAÇÃO DE RELATÓRIOS COM O EXCEL
Nesse momento, você deve estar se perguntando: “Mas se eu já tenho domí-
nio de Excel, então eu já sei tudo sobre BI?”. A grande questão é que o Excel é uma ferra-
menta de relatórios, sob a qual os seus usuários gastam muito tempo preparando os dados 
para poder extrair informações sobre ele. Lembrando que um cenário de BI deve fazer a 
coleta, o armazenamento e a apresentação dos dados, de forma automática.
INTERESSA
NTE
13
Neste tópico, você aprendeu que:
• Big data é composto por volume, velocidade, variedade, veracidade e valor.
• Como usuário, você tem um importante papel na geração de um grande volu-
me de dados.
• A evolução da tecnologia, bem como o surgimento de novas tecnologias, como 
IoT, geram um conjunto expressivo de dados, implicando na Big Data.
• Business Intelligence é um termo que foi cunhado no final dos anos 1980, mas 
vinga até hoje; é um termo que já sofreu e pode sofrer mutações, conforme o 
cenário dos dados mudam no mundo. 
• Para ter um cenário de Business intelligence, é necessário ter coleta, armazena-
mento e processos que permitam sua análise. 
RESUMO DO TÓPICO 1
14
1 Leia o texto a seguir:
O Sistema de Apoio à Decisão (SAD) e Business Intelligence (BI), a partir de da-
dos do ambiente organizacional, seja interno e/ou externo, os transformam em 
informações na forma de relatórios, gráficos, tabela e indicadores, permitindo 
uma análise e um diagnóstico do ambiente e dos processos e proporcionando 
aos gestores condições de antecipar o futuro e reduzir riscos e incertezas na 
tomada de decisão.
Sobre Business Intelligence, assinale a alternativa CORRETA:
FONTE: SILVA, R. A. da; SILVA, F. C. A.; GOMES, C. F. S. O uso do Business Intelligence (BI) em 
sistema de apoio à tomada de decisão estratégica. Revista GEINTEC - Gestão, Inovação e 
Tecnologias, v. 6, n. 1, p. 2780-2798, 2016.
a) O desenvolvimento de Business Intelligence pode acontecer apenas em 
grandes corporações.
b) O desenvolvimento de Business Intelligence acontece apenas na teoria.
c) O desenvolvimento deBusiness Intelligence pode acontecer em qualquer 
organização. 
d) O desenvolvimento de Business Intelligence acontece apenas em organiza-
ções do ramo agrícola.
2 Big Data é o termo em Tecnologia da Informação que trata sobre grandes con-
juntos de dados que precisam ser processados e armazenados. O conceito do 
Big Data se iniciou com 5 Vs: Velocidade, Volume, Veracidade, Valor e Varie-
dade. Um sistema de IoT coleta dados de diversos dispositivos: áudio, vídeo, 
texto, binários. Sobre em qual V o IoT está relacionado, assinale a alternativa 
CORRETA: 
a) Volume. 
b) Velocidade.
c) Valor.
d) Variedade.
Para as próximas questões, considere o cenário a seguir:
“Você integrará à equipe o desenvolvimento de um sistema de Business In-
telligence para Smart Home. O sistema tem como objetivo coletar dados de 
uma casa inteligente, que já está funcionando normalmente, no entanto, cada 
dispositivo está independente. Também deve permitir que o usuário tenha um 
Dashboard com todas as informações da casa e de seus dispositivos pessoais”.
AUTOATIVIDADE
15
FIGURA 7 – SMARTHOME DASHBOARD
FONTE: <https://product.haleema.me/project/smart-home-dashboard/>. Acesso em: 29 fev. 2020.
3 Considerando o cenário do dispositivo indicado e sabendo que os dados são 
a forma mais bruta da informação, assinale a alternativa CORRETA que apre-
senta exemplo(s) de dados sobre esse cenário:
 
a) TV, Relógio, 1, 2000.23, 30 ºC, 200 Mhz.
b) Relatório de dispositivos que mais consomem energia.
c) Previsão do consumo de energia para o próximo dia.
d) Não é possível ter dado neste cenário.
4 Considerando o cenário do dispositivo indicado e sabendo que a informação 
traz organização e sentido aos dados armazenados, assinale a alternativa COR-
RETA que apresenta exemplo(s) de informações sobre esse cenário:
 
a) TV, Relógio, 1, 2000.23, 30 ºC, 200 Mhz.
b) Relatório de dispositivos que mais consomem energia.
c) Previsão do consumo de energia para o próximo dia.
d) Não é possível ter informação neste cenário.
16
5 Considerando o cenário do dispositivo indicado e sabendo que o conheci-
mento é adquirido a partir dos dados armazenados, sendo experiências e práti-
cas além da informação, assinale a alternativa CORRETA que apresenta exem-
plo(s) de conhecimento sobre esse cenário:
 
a) TV, Relógio, 1, 2000.23, 30 ºC, 200 Mhz.
b) Relatório de dispositivos que mais consomem energia.
c) Previsão do consumo de energia para o próximo dia.
d) Não é possível ter dado neste cenário.
17
TÓPICO 2
TIPOS DE DADOS E EXEMPLOS 
DE ARMAZENAMENTO
UNIDADE 1
1 INTRODUÇÃO
Quando falamos sobre Business Intelligence e sobre Big Data, falamos que 
tais tecnologias dependem diretamente de um item para existir: o dado. Logo, 
para que possamos armazená-lo, manutení-lo e analisá-lo é necessário tê-lo ar-
mazenado e preparado.
Por isso se torna interessante que você tenha conhecimento sobre os da-
dos, como gerá-los, como consumi-los e como tratá-los. Para isso, é importante 
conhecer os tipos de dados. 
Durante este tópico você estudará os tipos de dados que se dividem entre 
não estruturados, semiestruturado e estruturados. No contexto de desenvolvi-
mento de sistemas, os dados estruturados são maioria, no entanto, dada a explo-
são de dados que discutimos no mundo, a maioria dos dados são semiestrutura-
dos e não estruturados.
 
FIGURA 8 – SMARTHOME DASHBOARD
FONTE: O autor
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
18
2 DADOS ESTRUTURADOS
 
Quando se lê dados estruturados, logo assume-se que este dado possui 
uma estrutura e isso está correto. No entanto, no contexto dos tipos de dados, 
dizer que um dado é estruturado significa dizer que ele possui uma estrutura 
criada para o seu armazenamento. Precisamente, significa dizer que esta estrutu-
ra foi criada anteriormente à existência dos dados, ou seja, um dado estruturado 
é aquele que já tem uma estrutura antes mesmo do dado existir.
Os tipos estruturados são:
• Dados organizados em blocos semânticos (relações).
• Dados de um mesmo grupo.
• Dados que possuem as mesmas descrições (atributos).
• Dados que possuem descrições para todas as classes de um grupo apresentam 
o mesmo formato (esquema).
• Dados que são tradicionalmente mantidos em um SGBD e são chamados de 
estruturados por manterem a mesma estrutura de representação (rígida), pre-
viamente projetada (esquema).
Os Sistemas Gerenciadores de Bancos de Dados – SGBDs – são softwares 
utilizados para armazenar e manutenir os dados. 
Um sistema gerenciador de banco de dados (SGBD) é uma coleção de 
programas que permite aos usuários criar e manter um banco de da-
dos. O SGBD é, portanto, um sistema de software de propósito geral 
que facilita os processos de definição, construção, manipulação e com-
partilhamento de bancos de dados entre vários usuários e aplicações. 
A definição de um banco de dados implica especificar os tipos de da-
dos, as estruturas e as restrições para os dados a serem armazenados 
em um banco de dados (ELMASRI et al. 2005, p. 10).
Aqui temos um ponto importante, pois quando cunhou-se a terminologia 
SGBD só existia um tipo estrutura de banco de dados conhecida: os bancos de 
dados relacionais. Atualmente são diversos os tipos de gerenciadores de bancos 
de dados, os chamados NoSQL (Not Only SQL - Não Apenas AQL).
 
Os SGBDs do tipo NoSQL contêm diversos tipos de estruturas de armaze-
namento como: orientado a grafos, orientado a documentos, chave-valor, orienta-
do a grafos, orientado a colunas, entre muitos outros que surgem a cada momen-
to. O ponto nesse momento é que os bancos de dados não relacionais (NoSQL) 
são de diversos tipos e muitos deles não contemplam uma estrutura prévia de 
armazenamento.
Por isso dizemos que os dados estruturados se referem aos sistemas ge-
renciadores de bancos de dados relacionais – SGBDR. Lembrando que, na defini-
ção de um dado estruturado, a estrutura deve existir antes de o dado ser inserido. 
Vamos compreender como isso funciona na prática? 
TÓPICO 2 | TIPOS DE DADOS E EXEMPLOS DE ARMAZENAMENTO
19
Tendo com objetivo executar um exemplo prático, precisamos utilizar um 
SGBDR, nesse caso utilizaremos o PostgreSQL para construção do exemplo, no 
entanto, os comandos utilizados são ANSI-SQL e devem funcionar em todos os 
SGBDRs.
Para instalar o PostgreSQL na sua máquina, você pode obter os insta-
ladores e os arquivos binários no site https://www.postgresql.org/download/. 
No entanto, nesse primeiro momento, vamos utilizar uma opção em nuvem, o 
ElephantSQL. 
O ElephantSQL é uma ferramenta on-line para criação e manutenção de 
bancos de dados PostgreSQL, a ferramenta pode ser acessada em: https://www.
elephantsql.com/. Na tela de acesso inicial são apresentadas diversas opções, com 
diversos espaços em disco, bem como um preço associado.
Em sua opção FREE, o ElephantSQL permite criar um banco de dados de 
até 20 Mb de maneira gratuita sem a necessidade de fornecer dados de cartão de 
crédito, sendo essa opção utilizada para construir os exemplos desta Unidade.
FIGURA 9 – ELEPHANTSQL
FONTE: O autor
No ElephantSQL do navegador é possível executar comandos de acesso 
aos dados pela aba Browser. Será nessa caixa de texto que executaremos os co-
mandos para execução do nosso exemplo. 
 
https://www.elephantsql.com/
https://www.elephantsql.com/
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
20
Primeiramente, é bom saber que os SGBDRs se comunicam por uma mes-
ma linguagem, denominada SQL (Structured Query Language - Linguagem de 
Consulta Estruturada). A SQL pode ser dividida em dois tipos:
• DML (Data Definition Language - Linguagem de Definição de Dados): a lin-
guagem de definição está relacionada à definição da estrutura de um banco 
de dados, a partir dela que são definidas as estruturas, as tabelas e os campos, 
bem como a manutenção da estrutura.
• DML (Data Manipulation Language - Linguagem de Manipulação de Dados): 
a linguagem de manipulação está relacionada aos dados; a partir do momentoque a estrutura é criada, será possível com uma DML inserir, excluir, atualizar 
e consultar dados em um SGBD. 
Note que em sua definição, os dados estruturados devem ter uma estrutu-
ra definida antes da inserção dos dados, justamente o que acontece com a DML. 
Vejamos um exemplo de comandos que criam estruturas, em específico, o Qua-
dro 2 cria uma tabela. 
QUADRO 2 – DDL - CRIANDO UMA TABELA
create table aluno 
(
 id_pessoa integer primary key,
 nome varchar(100),
 cpf varchar(11)
)
FONTE: O autor
Uma vez tendo criado a tabela pelo comando do Quadro 2, para entender 
o conceito de um dado estruturado, execute os comandos mostrados pelo Quadro 
3, digitando cada comando na sequência, linha por linha.
QUADRO 3 – DML - INSERINDO REGISTROS
insert into aluno (id_pessoa, nome, cpf) values (1,"Rodrigo", "51255584896");
insert into aluno (id_pessoa, nome, cpf) values (2,"João", "125555848969");
insert into aluno (id_pessoa, nome, cpf, sexo) values (3,"Luiz", "125528848969", "M");
insert into aluno (id_pessoa, nome, cpf, idade) values (4,"Maria", "125578948969", 35);
FONTE: O autor
Ocorreu tudo bem durante a execução? O que aconteceu nas linhas 3 e 
4? Repare que ao executar essas linhas aconteceu um erro, o erro indica que os 
campos idade e sexo não existem, o que é verdade, pois a estrutura de um banco 
de dados não pode ser alterada durante sua execução. Caso se deseje inserir uti-
lizando esses campos, deve-se alterar a estrutura da tabela.
TÓPICO 2 | TIPOS DE DADOS E EXEMPLOS DE ARMAZENAMENTO
21
QUADRO 4 – DML E DML - ALTERANDO TABELA E INSERINDO REGISTROS
alter table aluno add sexo varchar(1); 
alter table aluno add idade integer;
insert into aluno (id_pessoa, nome, cpf, sexo) values (3,'Luiz', '12552884896', 'M');
insert into aluno (id_pessoa, nome, cpf, idade) values (4,'Maria', '25578948969', 35);
FONTE: O autor
Agora que pudemos compreender mais do conceito de dados estrutura-
dos e como esse conceito funciona na prática, na próxima seção será visto sobre 
os dados semiestruturados.
3 DADOS SEMIESTRUTURADOS
 
Não há como ter metade de um banco de dados com estrutura e outra 
sem. Quando falamos de bancos de dados semiestruturados, estamos falando de 
um tipo de dados que não tem estrutura definida previamente. 
Os dados semiestruturados permitem alteração da estrutura em tempo 
de execução, isto significa que campos podem ser adicionados ou removidos a 
qualquer momento. 
Os tipos semiestruturados são:
• Dados em sua maioria da Web.
• Dados que apresentam uma organização bastante heterogênea.
• A alta heterogeneidade dificulta as consultas a estes dados.
• Os dados semiestruturados são dados em que o esquema de representação está 
presente (de forma explícita ou implícita).
Conforme já discutimos, a Web e os dispositivos IoT são grandes respon-
sáveis pela geração de dados no mundo. A grande característica desses dados é o 
fato de terem uma estrutura dinâmica, que pode ser alterada em execução.
Conhecendo um pouco sobre o conceito de dados semiestruturados, veja-
mos alguns exemplos deste tipo de dados.
3.1 DOCUMENTO XML
O XML (eXtensive Markup Language - Linguagem de Marcação Exten-
sível) é uma linguagem de marcação que tem uma estrutura muito similar ao 
HTML (Hypertext Markup Language - Linguagem de Marcação de Hipertexto).
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
22
Tanto o XML quanto o HTML têm sua organização e sintaxe dada por 
<tags>. A principal diferença é que o HTML é utilizado para criação e exibição de 
conteúdo na Web, enquanto o XML é utilizado para armazenamento de dados. 
O XML é recomendado pela W3C para a criação de documentos com dados 
organizados hierarquicamente. Vejamos um exemplo de um documento XML.
QUADRO 5 – EXEMPLO DE XML
<?xml version="1.0" ?>
<pedidos>
 <pedido id="1">
 <produto id="1">
 <descricao>Jaleco</descricao>
 <preco>3.50</preco>
 <quantidade>3</quantidade>
 </produto>
 </pedido>
</pedidos>
FONTE: O autor
Para validar se a sintaxe do documento anterior está correta, basta usar o 
seguinte validador: https://www.w3schools.com/xml/xml_validator.asp. Criare-
mos, agora, um outro documento, baseado no anterior, mas utilizando recursos 
de dados semiestruturados.
QUADRO 6 – ADICIONANDO ELEMENTOS AO XML
<?xml version="1.0" ?>
<pedidos>
 <pedido id="1">
 <produto id="1">
 <descricao>Jaleco</descricao>
 <preco>3.50</preco>
 <quantidade>3</quantidade>
 </produto>
 <produto id="2">
 <descricao>Jaleco</descricao>
 <quantidade>3</quantidade>
 <totalproduto>10,5</totalproduto>
 </produto>
 </pedido>
</pedidos>
FONTE: O autor
TÓPICO 2 | TIPOS DE DADOS E EXEMPLOS DE ARMAZENAMENTO
23
Note que alteramos a estrutura do documento passando a mesma infor-
mação que há em pedido 1 para o pedido 2, dito isto, você percebe que ambos 
produtos contêm a mesma informação, mas estruturada de maneira diferente. 
Qual o problema disso? O grande problema será na hora de consumir esses da-
dos, afinal a mesma consulta não retornará para a mesma informação.
O XML compreende um padrão adotado pelo W3 Consortium, que possi-
bilita a troca de dados na Internet, além de representar dados semiestruturados. 
Uma grande quantidade de dados é atualmente publicada em páginas HTML 
(ALMEIDA, 2002).
Documentos XML são tradicionalmente utilizados para integração entre 
sistemas, nas quais organizações utilizam esse tipo de documento para enviar e 
receber dados. Tendo em vista validar dados nessa troca de informação, existem 
a DTD XMLSchema, que são mecanismos para conferir se os XMLs seguem um 
padrão definido durante a troca.
3.2 ARQUIVOS CSV
Os documentos deste tipo se assemelham muito a tabelas ou a um docu-
mento Excel. O termo “CSV” tem como significado Comma Separated Values, ou 
seja, é um arquivo separado por vírgula (ou ponto e vírgula). Assim como o XML, 
este é um formato de arquivo que permite realizar o intercâmbio de dados entre 
sistemas que utilizam SGBDs diferentes. 
QUADRO 7 – CSV
id_produto, descricao, preco, estoque
1,Jaleco, 3.50,30
2,Chapéu, 13.50,100
3,Calça , 33.50,130
FONTE: O autor
Leia o artigo “DTDs versus XML schema: a practical study”, dos autores Geert 
Jan Bex, Frank Neven e Jan Van den Bussche. Disponível em: https://www.researchgate.
net/publication/2938069_DTDs_versus_XML_schema_a_practical_study.
DICAS
https://www.researchgate.net/profile/Geert_Bex
https://www.researchgate.net/profile/Geert_Bex
https://www.researchgate.net/profile/Frank_Neven
https://www.researchgate.net/profile/Jan_Van_den_Bussche
https://www.researchgate.net/publication/2938069_DTDs_versus_XML_schema_a_practical_study
https://www.researchgate.net/publication/2938069_DTDs_versus_XML_schema_a_practical_study
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
24
Os documentos deste tipo têm grande importância nesse curso, pois mui-
tas bases de dados públicas disponibilizam seus dados nesse formato.
3.3 JSON
O formato JSON é um dos mais utilizados na Web para troca de informa-
ções, seja em aplicações de interoperabilidade ou até mesmo para desenvolver 
aplicações Ajax (Asynchronous Javascript and XML, em português “Javascript 
Assíncrono e XML”).
JSON significa “Javascript Object Notation”, do qual nada mais é que o 
formato leve ideal para transferência/intercâmbio de dados. Isto se dá pelo fato 
de sua estrutura ser igual a um objeto da linguagem javascript (FILLIPI, 2017).
A seguir, um exemplo de como é a estrutura de um documento JSON para 
realizar o armazenamento de produtos. 
QUADRO 8 – JSON
[
 {
 “cliente”: “João Fernandes”,
 “produto”: “Jaleco”,
 “valor_total”: “3.5”,
 “metodo”: “cartão”, 
 “promocao”:”sim”
 }
 
]
FONTE: O autor
A dinâmica de alteração de elementos de um documento JSON é muito 
similar ao XML, a cada novo elemento pode-se alterar a estrutura. Perceba que ao 
inserir o novo elemento em produto,ainda que a estrutura tenha ficado próxima, 
o elemento promoção foi removido, bem como os elementos produto e método 
foram alterados para que recebam um array com vários produtos. 
TÓPICO 2 | TIPOS DE DADOS E EXEMPLOS DE ARMAZENAMENTO
25
QUADRO 9 – ALTERAÇÃO DE UM DOCUMENTO JSON
[
 {
 “cliente”: “João Fernandes”,
 “produto”: “Jaleco”,
 “valor_total”: “3.5”,
 “metodo”: “cartão”
 },
 {
 “cliente”: “João Henrique”,
 “produto”: [“Jaleco”,”lentes”,”óculos”],
 “valor_total”: “256.78”,
 “metodo”: [“cartão”, “dinheiro”]
 }
 
]
 FONTE: O autor
3.4 BSON - MONGODB
A seção sobre MongoDb pode ser considerada uma continuação da abor-
dagem com JSON, uma vez que o sistema de armazenamento do Mongodb é 
baseado em BSON, uma versão binária do JSOn como o conhecemos. 
O MongoDB é um banco de dados NoSQL de código aberto sob a li-
cença GNU AGPL v3.0, escrito em C++, orientado a documentos e livre 
de schemas. Seu nome é derivado da expressão em inglês humongous, 
que pode ser traduzido como “enorme” ou “monstruoso”. O Mon-
goDB inicialmente foi desenvolvido como um componente de serviço 
pela empresa 10gen em outubro de 2007, passando a ser um software 
open source em 2009. Atualmente, o MongoDB é um dos mais popula-
res banco de dados NoSQL (senão o mais popular) e está na versão 2.6. 
O projeto ainda é mantido pela 10gen que oferece suporte comercial e 
demais serviços (NASCIMENTO, 2020, p. 15).
Para obter o instalador no MongoDB em seu computador, você pode aces-
sar o link: https://www.mongodb.com/download-center. Uma vez instalado, va-
mos colocar em prática, antes disso, é preciso compreender que o MongoDB é 
NoSQL e em uma associação com os bancos de dados relacionais seus elementos 
principais são:
• Banco de Dados (SGBDR) → Banco de Dados (MongoDB).
• Tabelas (SGBDR) → Coleções (MongoDB).
• Linhas (SGBDR) → Documentos (MongoDB).
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
26
O primeiro passo é criar o seu banco de dados, para isso, no terminal do 
MongoDB digite Use BDLoja. Com este comando, você criará um banco de da-
dos chamado loja.
Uma vez criado um banco de dados, o processo de criação de uma collec-
tion é dinâmica e aqui conseguiremos ver a definição de dados semiestruturados 
na prática, ao contrário dos bancos de dados relacionais, em que se deve primei-
ramente criar uma tabela e, posteriormente, inserir dados a ela. 
Repetiremos no MongoDB os mesmos dados utilizados inseridos em 
JSON, veja como ficará o código completo.
QUADRO 10 – COMANDOS MONGODB
1 Use 
2 db.CollectionProduto.insertOne({cliente: “João Fernandes”,produto: “Jale-
co”, valor_total: “3.5”, metodo: “cartão” } )
3 db.CollectionProduto.insertOne({ cliente: "João Henrique", produto: ["Jale-
co","lentes","óculos"], valor_total: 256.78, metodo: ["cartão", "dinheiro"] })
4 db.CollectionProduto.find()
FONTE: O autor
Ao executar o código mostrado no Quadro 10, na linha 1 você criará o 
banco de dados. Na linha 2, a Collection é criada e o primeiro pedido é inserido, 
na linha 3, o segundo pedido é inserido. Por fim, na linha 4, é executada uma 
consulta que retornará todos os elementos da CollectionProduto. O resultado es-
perado será algo como mostra a Figura 10.
FIGURA 10 – MONGODB
FONTE: O autor
TÓPICO 2 | TIPOS DE DADOS E EXEMPLOS DE ARMAZENAMENTO
27
4 DADOS NÃO ESTRUTURADOS
 
Você aprendeu que os dados estruturados são aqueles que têm uma estru-
tura criada antes do armazenamento dos dados e que os dados semiestruturados 
vão definindo a estrutura do banco de dados conforme os dados vão sendo inse-
ridos. O que esses dois tipos têm em comum? Para cada dado armazenado você 
sabe o que ele é, você reconhece o valor, o nome, o preço, isso significa estrutura. 
Já os dados não estruturados são aqueles que não possuem nenhuma estrutura, 
nem prévia, nem criada em execução.
Os tipos não estruturados são:
• São os dados que não possuem uma estrutura definida.
• São os dados que estruturas são descritas implicitamente. 
• A maioria dos dados na Web são deste tipo.
Os dados não estruturados são aqueles em que há a necessidade de um 
pré-processamento para que haja uma compreensão dos dados armazenados. Em 
geral, os dados não estruturados são textos, áudios e imagens.
Vamos pegar o exemplo de uma imagem: como saber o que há em uma 
imagem? Nós como humanos temos esse conhecimento, mas para que o compu-
tador possa compreender, no geral, uma imagem é quebrada pixel a pixel, para 
cada pixel são coletados metadados sobre cada pixel, por exemplo: cor, curva, 
profundidade.
Tendo como objetivo obter mais conhecimento, bem como poder executar o 
MongoDB, você poderá acessar: https://docs.mongodb.com/manual/tutorial/. O site possui 
um guia completo sobre os principais comandos do MongoDB e também um terminal 
on-line em que você poderá executar seus comandos.
DICAS
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
28
FIGURA 11 – IMAGEM EM PIXELS
FONTE: <https://gartic.com.br/t4nk_b0y/desenho-livre/super-mario-pixels-2>. Acesso 
em: 1º jan. 2020.
Os textos também são amplamente utilizados em cenários de gestão do 
conhecimento, no entanto, são compreensíveis para os humanos, mas não para a 
máquina. 
Para que se possam realizar operações de sistemas inteligentes utilizando 
dados de textos, utilizam-se técnicas que convertem textos para linguagem de 
máquina. A técnica mais conhecida é denominada Bag-of-Words, que consiste 
em transformar um texto em um conjunto de dados binários.
A Figura 12 traz um exemplo de um texto em sua forma inteira e sua trans-
crição para Bag-of-words, à esquerda os textos completos e à direita as palavras 
e suas ocorrências na forma de Bag-of-words. Note que a partir da transformação 
em Bag-of-words, o texto agora tem uma estrutura e a partir deste momento po-
derá ser compreendido pela máquina. 
https://gartic.com.br/t4nk_b0y/desenho-livre/super-mario-pixels-2
TÓPICO 2 | TIPOS DE DADOS E EXEMPLOS DE ARMAZENAMENTO
29
FIGURA 12 – EXEMPLO DE BAG OF WORDS
FONTE: <https://www.quora.com/What-is-the-bag-of-words-algorithm>. Acesso em: 1º jan. 
2020.
https://www.quora.com/What-is-the-bag-of-words-algorithm
30
RESUMO DO TÓPICO 2
Neste tópico, você aprendeu que:
• Os dados são divididos em estruturados, não estruturados e semiestruturados.
• Os dados estruturados têm uma estrutura predefinida e são tradicionalmente 
SBGDR.
• A estrutura dos dados semiestruturados são definidas no decorrer da execu-
ção; são exemplos de dados semiestruturados: XML, CSV, JSON e MongoDb 
(BSON).
• Os dados não estruturados não têm nenhuma estrutura; são exemplos de da-
dos não estruturados: imagens, textos, áudios e vídeos.
31
1 Os dados são o novo petróleo, são essenciais para a implementação de um 
sistema de Business Intelligence. Observe a figura a seguir.
FIGURA 13 – TIPO DE DADO
FONTE: O autor
Assinale a alternativa CORRETA que apresenta o tipo de dado contemplado 
pela imagem anterior:
a) É um dado do tipo estruturado.
b) É um dado do tipo semiestruturado.
c) É um dado do tipo não estruturado.
d) Nenhuma das alternativas.
2 Os dados são o novo petróleo, são essenciais para a implementação de um 
sistema de Business Intelligence. Observe o quadro a seguir.
QUADRO 11 – TIPO DE DADO
Os Lusíadas
Os Lusíadas é uma obra de poesia épica do escritor português Luís Vaz de 
Camões, considerada a "epopeia portuguesa por excelência". Provavelmen-
te concluída em 1556, foi publicada pela primeira vez em 1572 no período 
literário do Humanismo, três anos após o regresso do autor do Oriente.
FONTE: O autor
AUTOATIVIDADE
32
Assinale a alternativa CORRETA que apresenta o tipo de dado contemplado 
pelo quadro anterior:
a) É um dado do tipo estruturado.
b) É um dado do tipo semiestruturado.
c) É um dado do tipo não estruturado.
d) Nenhuma das alternativas.
3 Os dados são o novo petróleo, são essenciais para a implementação de um 
sistema de Business Intelligence. Observe o quadro a seguir.
QUADRO12 – TIPO DE DADO
CREATE TABLE Pessoa (
 ID int,
 Nome varchar(255),
 Sonrenome varchar(255),
 Endereco varchar(255),
 Cidade varchar(255) 
);
FONTE: O autor
Assinale a alternativa CORRETA que apresenta o tipo de dado contemplado 
pelo quadro anterior:
a) É um dado do tipo estruturado.
b) É um dado do tipo semiestruturado.
c) É um dado do tipo não estruturado.
d) Nenhuma das alternativas.
4 Os dados são o novo petróleo, são essenciais para a implementação de um 
sistema de Business Intelligence. Observe o quadro a seguir.
QUADRO 13 - TIPO DE DADO
{ nome:"João", Idade: 20, Sexo: 'M', Cursos:["Big Data", "IoT" , "ADS"]};
FONTE: O autor
Assinale a alternativa CORRETA que apresenta o tipo de dado contemplado 
pelo quadro anterior:
a) É um dado do tipo estruturado.
b) É um dado do tipo semiestruturado.
c) É um dado do tipo não estruturado.
d) Nenhuma das alternativas.
33
5 Os dados são o novo petróleo, são essenciais para a implementação de um 
sistema de Business Intelligence. Observe o quadro a seguir.
QUADRO 14 – TIPO DE DADO
<bilhetee>
<data>
 <dia>12</dia>
 <mês>11</mês>
 <ano>2020</ano>
</data>
<para>José</para>
<de>Maria</de>
<título>Lembrete</título>
<corpo>Ir ao cinema</corpo>
</bilhete>
FONTE: O autor
Assinale a alternativa CORRETA que apresenta o tipo de dado contemplado 
pelo quadro anterior:
a) É um dado do tipo estruturado.
b) É um dado do tipo semiestruturado.
c) É um dado do tipo não estruturado.
d) Nenhuma das alternativas.
34
35
TÓPICO 3
INTRODUÇÃO AO DATA 
WAREHOUSE
UNIDADE 1
1 INTRODUÇÃO
Durante esta Unidade estudamos diversos itens, começamos com uma 
reflexão sobre a explosão dos dados e com o grande volume de dados que há no 
mundo atualmente. Discorremos pelos tipos de dados e em como funcionam e 
passamos pelos conceitos essenciais de Business Intelligence e como ele deve ser 
implementado. 
Durante o desenvolvimento de um sistema de Business Intelligence não 
há particularidades técnicas, como é o caso do desenvolvimento de sistemas, que 
são compostos de todo um conjunto de metodologias e documentos. Quando 
falamos em desenvolver um Business Intelligence na prática, estamos falando de 
um sistema que consolidará os dados da empresa de tal modo que permitirá dar 
suporte à tomada de decisões. O ideal de um sistema é que contemple os pilares 
de Business Intelligence.
FIGURA 14 – PILARES DO BUSINESS INTELLIGENCE
FONTE: <https://www.goedert.com.br/business-intelligence/>. Acesso em: 1º jan. 2020.
https://www.goedert.com.br/business-intelligence/
36
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
Para a implementação de um processo de inteligência de negócios dentro 
de uma organização existem diversas ferramentas, no entanto, são poucas as ar-
quiteturas e metodologias. Isso acontece porque a principal arquitetura para um 
projeto de BI está dando certo há quase 40 anos. Vamos aprender mais sobre ela. 
2 DATA WAREHOUSE
Data Warehouse é um termo que nasceu nos anos 1970 e tem sua paterni-
dade dividida entre Ralph Kimball e Bill Inmon, autores que diferem em pontos 
específicos, mas que convergem na importância do seu desenvolvimento para 
alcançar a eficiência em um projeto de Business Intelligence. Data Warehouse tem 
como tradução literal Armazém de Dados e seu objetivo é realmente esse. 
FIGURA 15 – RALPH KIMBALL E BILL INMON
FONTE: O autor.
Segundo Nogueira (2019), Bill Inmon começou a discutir os principais fatores 
em torno do Data Warehouse e o termo já começou a existir a partir dos anos 1970. In-
mon trabalhou extensivamente na aprimoração de suas experiências em todas as formas 
de modelagem de dados relacionais. O trabalho de Bill Inmon como pioneiro do Data 
Warehouse foi o livro intitulado “Building the Data Warehouse”, um dos principais sobre 
tecnologia sobre desenvolvimento de projetos de dados na prática. Ralph Kimball, com a 
publicação de “The Data Warehouse Toolkit”, divide com Inmon a paternidade dos concei-
tos sobre o que é um Data Warehouse.
IMPORTANT
E
O data warehouse é o processo de coletar dados de sistemas de banco de 
dados herdados e de transações e transformá-los em informações organizadas 
em um formato amigável para incentivar a análise de dados e apoiar a tomada de 
TÓPICO 3 | INTRODUÇÃO AO DATA WAREHOUSE
37
decisões de negócios baseada em fatos. O processo que envolve a transformação 
de dados de seu formato original em um armazenamento de dados dimensional 
representa pelo menos 70% do tempo, esforço e despesa da maioria dos projetos 
de data warehouse (KIMBALL; CASERTA, 2011).
De modo geral, você pode compreender o Data Warehouse como um 
grande banco de dados analíticos, que é alimentado pelas mais diversas fontes de 
dados de uma empresa e tem a missão de integrar todos eles. 
Em sua definição do conceito de Data Warehouse, Kimball e Ross (2011) 
afirmam que data warehouse é um sistema que extrai, limpa, conforma e entrega 
os dados de origem em um armazenamento de dados dimensional e, em seguida, 
suporta e implementa consultas e análises para fins de tomada de decisão.
Inmon (2005), por sua vez, traz uma definição mais completa, na qual um 
Data Warehouse é formado por uma coleção de dados, orientado a um assunto, 
integrado, com tempo variável e não volátil, para suporte ao gerenciamento dos 
processos de tomada de decisão. Segundo Nogueira (2019), esses itens significam:
• Orientado a assunto: uma vez notando-se a necessidade da implementação 
de um Data Warehouse em uma organização, este terá um tema e um objeto 
de análise. Um Data Warehouse é orientado a assunto pelo fato de que este 
sempre estará relacionado a um tema, o qual consultas serão realizadas. Isso 
significa que ele sempre será direcionado a um tema, seja vendas, financeiro, 
fiscal ou compras. Ainda neste livro falaremos sobre o tema data mart, que é 
quando podemos ter vários assuntos integrados.
• Integrado: nesta Unidade falamos sobre diversos tipos de dados (XML, JSON, 
CSV, SGBDR), ou seja, uma das principais características de um Data Warehou-
se é a integração. Um Data Warehouse pode integrar vários sistemas internos 
que usam SGBD e ao mesmo tempo integrar com redes sociais via JSON, fazen-
do dessa dinâmica nas fontes de dados sua principal característica, bem como 
um dos principais desafios. 
• Variável em relação ao tempo: o fator temporal é, na maioria dos casos, de-
terminante na análise dos dados armazenados em um Data Warehouse. Desse 
modo, a cada carga de um novo conjunto de dados, este será associado com 
um determinado tempo. Vejamos a importância do tempo, por exemplo: em 
um Data Warehouse de ações, na bolsa de valores obtém-se os meses nos quais 
há uma maior queda nas ações e os meses em que há um número maior de 
vendas. Sendo assim, é necessário que os dados de Data Warehouse sejam ar-
mazenados em relação ao tempo.
• Não volátil: este fator também está relacionado ao tempo, uma vez que todo 
registro que é inserido em um Data Warehouse é associado a um tempo. Não 
devem haver exclusões, por isso é não volátil. Isso não significa que o registro 
não constará como removido, mas que haverá duas ocorrências, uma primeira 
na data de sua inserção indicando que existiu e uma segunda indicando a data 
que foi removido. 
38
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
Quando analisamos as duas definições como um todo, podemos perceber 
que o Data Warehouse é tratado como um grande banco de dados analítico, ali-
mentado pelas mais diversas fontes de dados da organização.
Uma vez conhecendo melhor as definições e os conceitos, entenderemos 
um pouco mais sobre as principais arquiteturas utilizadas. 
2.1 ARQUITETURA PROPOSTA POR INMON
Agora que conhecemos um pouco mais sobre o conceito de um Data Wa-
rehouse e seu papel dentro de uma organização, nos aprofundaremos em como 
ele pode ser implementado. Quando falamos em arquitetura, estamos falando de 
uma visão geral de como um Data Warehouse se comportará. 
FIGURA 16 – ARQUITETURA DE BILL INMONFONTE: Adaptada de Carvalho (2010)
Nesta figura, os elementos representam:
• Dados operacionais e externos: o termo dados operacionais remete aos dados 
dos sistemas transacionais utilizados pela empresa (sistema de venda, de gestão 
etc.) que utilizam sistemas gerenciadores de banco de dados. Os dados externos 
são dados da Web, dispositivos externos ou até mesmo de sistemas de terceiros. 
• Extração dos Dados, Limpeza dos Dados e Carga dos Dados: refere-se ao 
processo de tratamento dos dados, que devem ser preparados para serem ar-
mazenados. Como há a possibilidade de existirem dados externos, essa etapa 
também é responsável por fazer a integração destes. Por fim, os dados são car-
regados no Data Warehouse.
TÓPICO 3 | INTRODUÇÃO AO DATA WAREHOUSE
39
• Data Warehouse e Data Marts: são os locais onde os dados são armazenados 
em si. A diferença é que os data marts são setoriais, remetem-se a setores da 
empresa, Marketing, por exemplo. Já o Data Warehouse pode ser compreendi-
do como a consolidação de todos os data marts.
• Sistemas de Entrega de Informações: referem-se a mecanimos para fornecer 
dados para aplicações terceiras, como um web service que permite a realização 
de consultas.
• Aplicações e Ferramentas: são os meios de visualização e consumo dos dados 
armazenados; a partir das ferramentas, os dados armazenados em um Data 
Warehouse são utilizados para a produção de informação e conhecimento.
Uma característica da abordagem de Inmon está relacionada à estratégia 
de modelagem de dados proposta pelo autor, tal estratégia é denominada Snow-
Flake. O modelo SnowFlake é muito próximo do que é conhecido da modelagem 
tradicional de banco de dados, ainda que seja orientado a consultas, o modelo de 
Inmon aplica a normalizado, por isso as tabelas formam ramificações no formato 
de flocos de neve (SnowFlake).
FIGURA 17 – MODELO FLOCO DE NEVE
FONTE: Adaptada de Nogueira (2019)
40
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
2.2 ARQUITETURA PROPOSTA POR KIMBALL
A arquitetura de um Data Warehouse mostra o comportamento e os ele-
mentos essenciais para que um cenário de Business Intelligence possa acontecer 
e dar suporte à decisão. 
Em uma abordagem similar ao que vimos anteriormente, a arquitetura 
proposta por Kimball tem sido amplamente utilizada pela literatura e em pro-
jetos reais. A Figura a seguir mostra uma visão geral do funcionamento desta 
arquitetura.
FIGURA 18 – ARQUITETURA DE KIMBALL
FONTE: Adaptada de Kimball e Ross (2011)
Pode-se dizer que a arquitetura proposta por Kimball e Ross (2011) é com-
posta por camadas de dados: fontes de dados, área de trabalho, área de apresen-
tação e ferramentas de acesso aos dados. Tais camadas podem ser descritas como:
• Fontes Provedoras: um Data Warehouse é composto por dados oriundos dos 
sistemas transacionais de uma organização, mas também pode receber dados 
externos. Esta camada contém todos os dados possíveis de serem armazenados 
no Data Warehouse (banco de dados relacional, orientado a objetos, não estru-
turados, textual, Web etc.) que serão armazenados no modelo multidimensio-
nal desenvolvido, permitindo que sejam realizadas as análises.
TÓPICO 3 | INTRODUÇÃO AO DATA WAREHOUSE
41
• Área de Trabalho: será aqui que o maior esforço computacional deverá acon-
tecer, cerca de 80% do tempo do projeto deve ser gasto na área de trabalho, 
visto que são realizados os processos de integração das fontes de dados, bem 
como as transformações necessárias para armazenar os dados de acordo com o 
modelo definido para Data Warehouse. Nesta camada são realizados os prin-
cipais procedimentos da chamada ETL (Extract, Transform and Load - Extração 
Transformação e Carga).
• Área de Apresentação de Dados: esta camada é responsável pela criação do 
Data Warehouse em si, não somente do armazenamento, mas de mecanismos 
para o consumo de dados com ênfase na sua principal tarefa: análise dos dados. 
• Ferramentas de Acesso aos Dados: essa camada será responsável por consu-
mir os dados de um Data Warehouse, gerando informação e conhecimento. 
Será aqui que as ferramentas de visualização de dados farão uso do servidor 
para submeter requisições de acesso aos dados armazenados. 
Assim como visto anteriormente, Kimball tem sua proposta de uma mo-
delagem para os dados que serão armazenados no Data Warehouse. O modelo 
proposto por Kimball é denominado modelo estrela, o nome se dá justamente 
pelo formato que as tabelas ficam dispostas. Ao contrário do modelo SnowFlake, 
o modelo estrela não apresenta normalização dos dados. A Figura 18 mostra um 
exemplo do modelo estrela.
FIGURA 19 – MODELO ESTRELA
FONTE: O Autor
42
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
Você pode notar que as duas abordagens são próximas, com algumas 
particularidades em suas arquiteturas, apesar dos modelos oferecerem modelos 
diferentes. 
A principal diferença entre as modelagens é que apesar do modelo floco 
de neves oferecer mais integridade aos dados, ele será mais custoso. O modelo 
estrela, por sua vez, atende à ideia de um banco de dados analítico. Com poucas 
tabelas, permite que as consultas sejam executadas de maneira mais rápida.
No que se refere às arquiteturas, você não precisa se apegar, afinal pode 
adaptar a arquitetura dependendo do problema a ser desenvolvido. No caso de 
Nogueira (2017), por exemplo, no desenvolvimento de uma aplicação de coleta 
de notícias em tempo real, que coleta notícias e armazena em um sistema de Data 
Warehouse determinado Newsminer, para fazer a coleta, a análise e a implemen-
tação de algoritmos de machine learning ele utilizou uma arquitetura proposta 
por ele mesmo.
FIGURA 20 – EXEMPLO DE ARQUITETURA 
FONTE: Adaptado de Nogueira (2017)
Em um sistema para coleta de dados da rede social Twitter, tendo como 
objetivo utilizar algoritmos de machine learning para analisar os sentimentos so-
bre os candidatos à eleição em 2018, Suter et al. (2019) propõe uma arquitetura 
de Data Warehouse para realizar o armazenamento dos textos, bem como da sua 
recuperação. 
TÓPICO 3 | INTRODUÇÃO AO DATA WAREHOUSE
43
FIGURA 21 – EXEMPLO DE ARQUITETURA 
FONTE: Adaptado de Suter et al. (2019)
LEITURA COMPLEMENTAR
Desenvolvimento de Dashboards interativos utilizando ferramentas
de Business Intelligence para descoberta de fatores determinantes
da evasão universitária
Introdução 
A evasão escolar tem se mostrado um problema que impacta a educação 
sob variadas perspectivas e afeta os discentes, as instituições de ensino, os siste-
mas de ensino e a sociedade em geral. De outro lado, ferramentas de Business 
Intelligence são amplamente utilizadas nos mais diversos cenários de suporte à 
decisão como uma oportunidade de organização de dados e eventos, em especial 
para a projeção de cenários e possibilidades futuras.
No ensino superior, a evasão é um problema que atinge até mesmo o ce-
nário internacional, afetando os resultados dos sistemas educacionais, além dis-
so, são desperdícios sociais, acadêmicos e econômicos (PRIM; FÁVERO, 2012). 
Um levantamento realizado pelo Ministério da Educação e Cultura (MEC) com 
dados do censo relativos ao ano de 2015 revelou um crescimento nas taxas de 
desistências dos cursos de ingresso, na avaliação do fluxo de alunos entre 2010 e 
2014. Em 2010, 11,4% dos alunos abandonaram o curso para o qual foram admiti-
dos. Em 2014, esse número chegou a 49%.
Para tanto, este trabalho tem por finalidade de estudo a implementação 
de um banco de dados multidimensional com a utilização de dashboards intera-
tivos, a fim de compilar os dados relevantes à evasão do Curso de Bacharelado 
de Sistemas de Informação (BSI) do Instituto Federal Catarinense de uma forma 
organizada e analítica para a gestão do Campus, permitindo a realização de con-
sultas por diversas perspectivas do perfil acadêmico; coletar e analisar dados re-
44
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
ferentes à evasão dos alunos do curso de Bachareladoem Sistemas de Informação 
do Instituto Federal Catarinensepor meio de um banco de dados multidimensio-
nal que permita o desenvolvimento de dashboards interativos.
Revisão de literatura
Sabendo que o principal objetivo deste trabalho é análise dos dados refe-
rente à evasão dos alunos do curso de Bacharelado em Sistemas de Informação 
por meio de um banco de dados multidimensional, buscou-se os principais tra-
balhos da literatura atual que realizaram tal integração. O trabalho de Alves et al. 
(2016), aborda uma solução para os gestores do Centro Universitário de Patos de 
Minas – UNIPAM uma ferramenta de auxílio, para que o gestor possa realizar 
a tomada de decisão de forma mais segura e mais estruturada através de dados 
analisados, sendo essa solução o uso de Balanced Scorecard (BSC) e Business In-
telligence (BI).
Para a obtenção das informações, os autores buscaram, previamente, jun-
to à instituição, os índices de abandono de curso por curso e por centro, forma de 
ingresso por forma de evasão, perfil geográfico de alunos que abandonam cursos 
e o coeficiente de rendimento de alunos que abandonam um curso.
De acordo com os campos supracitados e necessários para análise, as fon-
tes de dados usadas no trabalho são baseadas em planilhas geradas pela DTIC – 
Diretoria de Tecnologia de Informação e Comunicação da UNIRIO. Então, com o 
auxílio da ferramenta de BI Tableau, foi possível gerar o primeiro indicador mais 
generalizado e mostrar a porcentagem de evasão de alunos de Ampla Concorrên-
cia em cada curso por semestre, desde 2010. O trabalho foi dado como prioridade 
ao fato “Evasão”, mas com o uso e aplicação de uma ferramenta BI, os usuários 
conseguem analisar muitos outros fatos relevantes para a instituição, como mobi-
lidade entre cursos, transferências externas, entre outros.
Metodologia
Para atingir os objetivos propostos neste trabalho, primeiramente foi rea-
lizado um estudo e análise, através de uma pesquisa de campo, de todos os alu-
nos matriculados nas turmas de 2010 a 2018 do Curso de Bacharelado de Sistemas 
de Informação e, em um âmbito geral, foi identificando o perfil de cada aluno 
para apontar o provável motivo da evasão dos alunos.
Para levantar as causas da evasão, foi aplicado um questionário aos acadê-
micos evadidos, acadêmicos que estão cursando e aos acadêmicos que já conclu-
íram o curso. As perguntas foram elaboradas com o auxílio de outras pesquisas 
e questionários aplicados em outros estudos semelhantes, em que algumas ques-
tões foram reescritas e adaptadas para fins de desenvolvimento dos dashboards 
e do data warehouse.
TÓPICO 3 | INTRODUÇÃO AO DATA WAREHOUSE
45
ARQUITETURA
O questionário foi desenvolvido na plataforma de formulários do Goo-
gle Drive. Então foi gerado um link do questionário e encaminhado via e-mail 
aos acadêmicos do curso, entre os meses de setembro a outubro do ano de 2018, 
tendo como base de dados informações fornecidas pelo Registro Escolar da Ins-
tituição em estudo e a coordenação do curso de Bacharelado em Sistemas de In-
formação por meio de uma solicitação escrita autorizada garantindo o sigilo das 
informações. Junto aos links dos questionários também foi encaminhado uma 
breve explicação do estudo enfatizando a sua relevância não apenas para o curso 
de Bacharelado em Sistemas de informação, mas sim para o desenvolvimento 
educacional da Instituição em estudo.
Depois de feita a coleta e análise dos dados destes questionários, foi de-
senvolvido o banco de dados multidimensional, para então compilar os dados e 
gerar os índices de evasão do curso de BSI com o uso das ferramentas de Business 
Intelligence. A fonte de dados da arquitetura tem como base o arquivo em forma-
to .csv e para que as informações dos questionários sejam armazenadas de acordo 
com o modelo multidimensional e os dados disponibilizados para as aplicações, 
a coleta dos questionários é realizada previamente, bem como seu pré-processa-
mento, compondo a etapa de ETL, ou área de trabalho.
Em seguida, na área de apresentação é feita a carga dos dados pré-pro-
cessados no Data Warehouse e utilizada a ferramenta de acesso aos dados Power 
BI para gerar os dashboards, contendo os índices e a efetivação das operações de 
OLAP do banco, conforme ilustrado na Figura - Arquitetura. Tendo como premis-
sa que o modelo estrela é a estrutura básica de um modelo de dados multidimen-
sional, este também foi utilizado na modelagem multidimensional deste projeto, 
no qual sua composição típica possui uma grande entidade central denominada 
fato e um conjunto de entidades menores denominadas dimensões, arranjadas ao 
redor dessa entidade central, o qual forma uma estrela.
O modelo multidimensional (ver figura a seguir) representa o projeto lógi-
co do banco multidimensional para a descoberta de fatores determinantes da eva-
são do curso estudado. Para sua implementação foi utilizado a abordagem HOLAP 
(Hybrid Online Analytical Processing) por intermédio de um servidor PostgreSQL.
46
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
M
O
D
E
LO
 M
U
LT
ID
IM
E
N
SI
O
N
A
L 
PA
R
A
 A
 D
E
SC
O
B
E
R
TA
 D
E
 F
AT
O
R
E
S 
D
E
T
E
R
M
IN
A
N
T
E
S 
D
A
 E
V
A
SÃ
O
D
IM
EN
SÃ
O
_M
O
TI
V
O
_E
SC
O
LH
A
ID
_M
O
TI
V
O
_E
SC
O
LH
A
: I
N
TE
G
ER
 N
O
T 
N
U
LL
 [P
K
]
M
O
TI
V
O
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
FA
TO
_A
LU
N
O
ID
_A
LU
N
O
: I
N
TE
G
ER
 N
O
T 
N
U
LL
 [P
K
]
ID
A
D
E:
 V
A
RC
H
A
R 
N
O
T 
N
U
LL
SE
XO
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
ST
A
TU
S:
 V
A
RC
H
A
R 
N
O
T 
N
U
LL
ID
_C
ID
A
D
E:
 IN
TE
G
ER
 N
O
T 
N
U
LL
 [F
K
]
ID
_E
VA
D
ID
O
: I
N
TE
G
ER
 [F
K
]
ID
_T
RA
N
SP
O
RT
E:
 IN
TE
G
ER
 N
O
T 
N
U
LL
 [F
K
]
ID
_T
U
RM
A
: I
N
TE
G
ER
 N
O
T 
N
U
LL
 [F
K
]
ID
_P
ER
FI
L:
 IN
TE
G
ER
 N
O
T 
N
U
LL
 [F
K
]
ID
_A
TI
V
O
: I
N
TE
G
ER
 [F
K
]
ID
_F
O
RM
A
D
O
: I
N
TE
G
ER
 [F
K
]
D
IM
EN
SÃ
O
_E
VA
D
ID
O
ID
_E
VA
D
ID
O
: I
N
TE
G
ER
 N
O
T 
N
U
LL
 [P
K
]
TR
A
BA
LH
A
_A
RE
A
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
FA
TO
R_
EV
A
SA
O
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
IN
ST
IT
U
IC
A
O
_E
V
IT
A
R:
 V
A
RC
H
A
R 
N
O
T 
N
U
LL
PE
RI
O
D
O
_E
VA
SA
O
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
TR
O
C
O
U
_C
U
RS
O
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
D
IM
EN
SÃ
O
_A
TI
V
O
ID
_A
TI
V
O
: I
N
TE
G
ER
 N
O
T 
N
U
LL
 [P
K
]
TR
A
BA
LH
A
_A
RE
A
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
C
O
N
C
LU
IU
_T
U
RM
A
_I
N
IC
IA
L:
 V
A
RC
H
A
R 
N
O
T 
N
U
LL
O
U
TR
O
_C
U
RS
O
_A
RE
A
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
D
IM
EN
SÃ
O
_F
O
RM
A
D
O
ID
_F
O
RM
A
D
O
: I
N
TE
G
ER
 N
O
T 
N
U
LL
 [P
K
]
TR
A
BA
LH
A
_A
RE
A
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
C
O
N
C
LU
IU
_T
U
RM
A
_I
N
IC
IA
L:
 V
A
RC
H
A
R 
N
O
T 
N
U
LL
O
U
TR
O
_C
U
RS
O
_A
RE
A
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
PO
N
TE
_D
IF
IC
U
LD
A
D
E_
D
IS
C
IP
LI
N
A
ID
_A
LU
N
O
: I
N
TE
G
ER
 N
O
T 
N
U
LL
 [P
FK
]
ID
_D
IF
IC
U
LD
A
D
E_
D
IS
C:
 IN
TE
G
ER
 N
O
T 
N
U
LL
 [P
FK
]
D
IM
EN
SÃ
O
_D
IF
IC
U
LD
A
D
E_
D
IS
C
IP
LI
N
A
ID
_D
IF
IC
U
LD
A
D
E_
D
IS
C:
 IN
TE
G
ER
 N
O
T 
N
U
LL
 [P
K
]
ID
_D
IF
IC
U
LD
A
D
E_
D
IS
C:
 V
A
RC
H
A
R 
N
O
T 
N
U
LL
D
IM
EN
SÃ
O
_C
ID
A
D
E
ID
_C
ID
A
D
E:
 IN
TE
G
ER
 N
O
T 
N
U
LL
 [P
K
]
N
O
M
E_
C
ID
A
D
E:
 V
A
RC
H
A
R 
N
O
T 
N
U
LL
U
F:
 V
A
RC
H
A
R 
N
O
T 
N
U
LL
M
U
D
A
N
C
A
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
D
IM
EN
SÃ
O
_T
U
RM
A
ID
_T
U
RM
A
: I
N
TE
G
ER
 N
O
T 
N
U
LL
 [P
K
]
N
O
M
E_
TU
RM
A
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
D
IM
EN
SÃ
O
_T
RA
N
SP
O
RT
E
ID
_T
RA
N
SP
O
RT
E:
 IN
TE
G
ER
 N
O
T 
N
U
LL
 [P
K
]
TI
PO
_T
RA
N
SP
O
RT
E:
 V
A
RC
H
A
R 
N
O
T 
N
U
LL
D
IM
EN
SÃ
O
_P
ER
FI
L_
SO
C
IA
L
ID
_P
ERFI
L:
 IN
TE
G
ER
 N
O
T 
N
U
LL
 [P
K
]
RE
N
D
A
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
H
O
RA
S_
TR
A
BA
LH
O
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
EN
SI
N
O
_M
ED
IO
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
PO
N
TE
_M
O
TI
V
O
_E
SC
O
LH
A
ID
_A
LU
N
O
: I
N
TE
G
ER
 N
O
T 
N
U
LL
 [P
FK
]
ID
_M
O
TI
V
O
_E
SC
O
LH
A
: I
N
TE
G
ER
 N
O
T 
N
U
LL
 [P
FK
]
PO
N
TE
_D
IF
IC
U
LD
A
D
E_
C
U
RS
O
ID
_D
IF
IC
U
LD
A
D
E_
C
U
RS
O
: I
N
TE
G
ER
 
N
O
T 
N
U
LL
 [P
FK
]
ID
_A
LU
N
O
: I
N
TE
G
ER
 N
O
T 
N
U
LL
 [P
FK
]
D
IM
EN
SÃ
O
_D
IF
IC
U
LD
A
D
E_
C
U
RS
O
ID
_D
IF
IC
U
LD
A
D
E_
C
U
RS
O
: I
N
TE
G
ER
 
N
O
T 
N
U
LL
 [P
K
]
D
IF
IC
U
LD
A
D
E_
C
U
RS
O
: V
A
RC
H
A
R 
N
O
T 
N
U
LL
TÓPICO 3 | INTRODUÇÃO AO DATA WAREHOUSE
47
Resultados e discussão
A modelagem multidimensional permite que as consultas de um banco 
de dados sejam realizadas de maneira mais intuitiva e flexível pelo usuário, além 
de possibilitar a obtenção de um desempenho superior, no que se refere às con-
sultas e análise de grandes volumes de dados.
O data warehouse foi populado de acordo com as respostas obtidas pelo 
questionário aplicado aos alunos, sendo assim, podemos fazer um gerenciamento 
das informações em que os dados estão organizados dentro de tabelas e definidas 
as relações entre estas tabelas. Deste modo, pode-se extrair ou até mesmo combi-
nar os dados de diversas tabelas, obtendo uma consulta ampla de informações.
O primeiro indicador gerado é mais generalizado com o intuito de mos-
trar os dados de perfil dos alunos, conforme mostra a figura a seguir.
PERFIL ALUNO
As dimensões foram dispostas nos filtros para dinamizar e flexibilizar os 
resultados. Dessa maneira, é possível selecionar um dos status do aluno (ativo, 
formado e/ou evadido) ou por uma turma em específico, o qual gerará as métri-
cas de idade, gênero, quantos alunos de cada status participaram da pesquisa, a 
cidade e estado, com localização geográfica, em que cada aluno morava quando 
fez o processo seletivo para o curso e se ele mudou de endereço devido ao ingres-
so no curso.
48
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
Pode-se observar que 74,4% dos alunos que participaram da pesquisa são 
do gênero masculino e com uma faixa etária predominante de 18 a 25 anos de idade, 
sendo boa parte do estado de Santa Catarina e mais especificamente da cidade de 
Instituto Federal Catarinense, onde é localizado o campus que disponibiliza o curso.
A próxima figura exibe os indicadores de um perfil explorando a dimen-
são “social” dos alunos, em que é considerado como análise o meio de transporte 
que o aluno utiliza (para os ativos) ou utilizava (para os formados e evadidos) 
para chegar ao Campus, a forma como realizou o ensino médio, quantas horas 
diárias o aluno trabalha e a renda familiar. Como exemplo de indicador, tem-se 
qual o meio de transporte mais utilizado pelo aluno de uma determinada turma.
PERFIL SOCIAL
Obtemos que a maioria dos alunos (62,79%) realizaram o ensino médio 
todo em escola pública e que utilizam/utilizavam o carro (32,56%) e o transporte 
público (26,74%) como meio de transporte para chegar ao campus.
O próximo indicador gerado, como mostra a figura a seguir, relata as in-
formações específicas sobre os alunos evadidos que responderam à pesquisa. Re-
lata-se qual fator levou o aluno a evadir o curso, se a instituição poderia ter feito 
algo para evitar a evasão do aluno e em que período o aluno evadiu, por exemplo.
Nota-se que o período do curso que mais possui evasão é o 2º período, 
com 23,53% e o fator que levou o aluno a evadir o curso é a “insatisfação com o 
curso escolhido”, 20%. Então, temos um possível indicador que o aluno abando-
na o curso logo no início por insatisfação de sua escolha. A figura também mostra 
informações se o aluno evadido, nos dias atuais, está ingressado na área tecnoló-
gica e 41,18% responderam que sim e que 47,06% dos alunos pretendem concluir 
o curso de Bacharelado em Sistemas de Informação. Dos 34 alunos evadidos que 
responderam à pesquisa, 26,47% evadiram para realizar outro curso superior.
TÓPICO 3 | INTRODUÇÃO AO DATA WAREHOUSE
49
ALUNOS EVADIDOS
Com o intuito de apresentar índices estatísticos referentes à evasão dos 
alunos do curso de Bacharelado em Sistemas de Informação do IFC Campus 
Camboriú, fora elaborado um dashboard indicando informações mais específi-
cas sobre esses alunos. Conforme podemos observar na próxima figura, a maio-
ria dos alunos evadidos é de regiões próximas ao campus, mais especificamente 
dos estados de Santa Catarina, Rio Grande do Sul e alguns de São Paulo, sendo 
que para 88,24% não houve a necessidade de mudar de cidade para frequentar o 
curso, destes, 39,39% possuem uma faixa etária de idade de 26 a 35 anos, sendo 
88,24% do gênero masculino e 67,65% destes realizaram os estudos de ensino 
médio todo em escola pública. Dos alunos evadidos, 61,76% se deslocavam até o 
campus para frequentar as aulas do curso utilizando o carro como meio de trans-
porte e a maioria destes alunos, 61,76%, possuem uma renda familiar entre 2 e 5 
salários mínimos.
Com a elaboração dos dashboards apresentados, é eminente a importân-
cia da adoção do BI como uma ferramenta de apoio à tomada de decisão. As ne-
cessidades do processamento de informações corretas e alinhadas aos objetivos 
estratégicos compreendem um papel fundamental para a determinação de cená-
rios que possam auxiliar o processo de tomada de decisão e, consequentemente, 
promover inteligência e vantagem competitiva, agregando valor ao negócio e à 
organização.
50
UNIDADE 1 | INTRODUÇÃO AO BUSINESS INTELLIGENCE E DATA WAREHOUSE
ÍNDICES DE ALUNOS EVADIDOS
 
Considerações finais
Este artigo teve como objetivo o desenvolvimento de dashboards intera-
tivos utilizando ferramentas de business intelligence para descoberta de fatores 
determinantes da evasão do curso de Bacharelado em Sistemas de Informação, 
capaz de auxiliar os gestores no processo de tomada de decisão sobre a evasão 
escolar do Instituto Federal Catarinense. Para atingir o objetivo geral, foram defi-
nidos sete objetivos específicos, sendo o primeiro: levantar todas as informações 
relevantes sobre evasão das turmas de 2010 a 2018 do curso, os quais fariam parte 
da interface de tomada de decisão. Para alcançar esse objetivo foram identifica-
dos na literatura quais eram os motivos e causas que levam os alunos a evadirem, 
além das consequências causadas pela evasão.
A principal contribuição deste trabalho de conclusão de curso consistiu 
na navegação dos dados de um Data Warehouse de evasão escolar e desenvol-
vimento de dashboards interativos para análise desses dados, possibilitando aos 
gestores acadêmicos um melhor entendimento de como a evasão acontece no cur-
so estudado, qual o perfil dos alunos evadidos, entre outros indicadores.
FONTE: GRABOSKI, J. et al. Desenvolvimento de Dashboards interativos utilizando 
ferramentas de Business Intelligence para descoberta de fatores determinantes da evasão 
universitária. II Workshop de Sistemas de Informação do IFC Camboriú. 2019. 
51
RESUMO DO TÓPICO 3
Neste tópico, você aprendeu que:
• Business Intelligence não tem uma implementação exata.
• Um projeto de Business Intelligence deve seguir seus pilares.
• Business Intelligence pode ser implementado por meio de um Data Warehouse.
• Um Data Warehouse pode ser considerado um banco de dados analítico.
• Existem dois autores de Data Warehouse com propostas para seu desenvolvi-
mento.
Ficou alguma dúvida? Construímos uma trilha de aprendizagem 
pensando em facilitar sua compreensão. Acesse o QR Code, que levará ao 
AVA, e veja as novidades que preparamos para seu estudo.
CHAMADA
52
1 Um Data Warehouse é composto por diversos itens, mas para que sua im-
plementação aconteça com eficiência, é necessário que seja desenvolvido um 
modelo de dados. Observe a imagem a seguir.
FIGURA22 – MODELO DE DADOS
AUTOATIVIDADE
FONTE: O autor
Sobre essa imagem, assinale a alternativa CORRETA:
a) É um modelo estrela.
b) É um modelo floco de neve.
c) É um modelo boneco de neve.
d) É um modelo galáxia.
2 Um Data Warehouse é composto por diversos itens, mas para que sua im-
plementação aconteça com eficiência, é necessário que seja desenvolvido um 
modelo de dados. Observe a imagem a seguir.
Lineorder
lo_orderkey
lo_linenumber
lo_partkey
lo_suppkey
lo_orderdate
lo_commitdate
lo_custkey
lo_revenue
lo_quantity
...1
1
1
1
N
N
N
N
Part
p_partkey
p_name
p_mfgr
p_category
p_brand1
p_color
p_type
p_size
p_container
Date
d_datekey
p_date
p_dayofweek
p_month
p_year
p_yearmonthnum
p_yearmonth
p_daynumweek
...
Customer
c_custkey
c_address
c_city
c_nation
c_region
c_name
Supplier
s_suppkey
s_address
s_city
s_nation
s_region
s_name
53
FIGURA 23 – MODELO DE DADOS
FONTE: O autor
Sobre essa imagem, assinale a alternativa CORRETA: 
a) É um modelo estrela.
b) É um modelo floco de neve.
c) É um modelo boneco de neve.
d) É um modelo galáxia.
3 O texto “Desenvolvimento de Dashboards interativos utilizando ferra-
mentas de Business Intelligence para descoberta de fatores determinantes da 
evasão universitária” apresenta um sistema que utiliza técnicas de Data Wa-
rehouse. Sobre a arquitetura utilizada por este trabalho, relacionando com o 
que foi estudado no Tópico 3, assinale a alternativa CORRETA: 
a) A arquitetura foi baseada em Rosembergh.
b) A arquitetura foi baseada em Kimball.
c) A arquitetura foi baseada em Inmon.
d) Nenhuma das alternativas.
54
4 O texto “Desenvolvimento de Dashboards interativos utilizando ferra-
mentas de Business Intelligence para descoberta de fatores determinantes da 
evasão universitária” apresenta um sistema que utiliza técnicas de Data Wa-
rehouse. Este texto apresenta um modelo multidimensional. Com relação ao 
StarSchema e ao SnowFlake, qual é o tipo desse diagrama?
5 O texto “Desenvolvimento de Dashboards interativos utilizando ferra-
mentas de Business Intelligence para descoberta de fatores determinantes da 
evasão universitária” apresenta um sistema que utiliza técnicas de Data Wa-
rehouse. Considerando a arquitetura utilizada, bem como a arquitetura de 
Kimball, quais são as fontes provedoras?
55
UNIDADE 2
BUSINESS INTELLIGENCE 
NA PRÁTICA: EXTRAÇÃO, 
TRANSFORMAÇÃO E CARGA
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
A partir do estudo desta unidade, você deverá ser capaz de:
• contextualizar sobre sistemas transacionais;
• conhecer sobre o funcionamento de um SGBD;
• criar e manipular banco de dados com SQL;
• entender o conceito de ETL;
• conhecer as ferramentas de ETL;
• utilizar o Pentaho e o Python no processo de ETL;
• desenvolver mecanismos e utilizar ferramentas para ETL.
Esta unidade de ensino contém três tópicos. No final de cada um deles 
você encontrará autoatividades que contribuirão para a apropriação dos 
conteúdos.
TÓPICO 1 – OLAP x OLTP
TÓPICO 2 – EXTRAÇÃO, TRANSFORMAÇÃO E CARGA
TÓPICO 3 – TRANSFORMAÇÕES NA PRÁTICA
Preparado para ampliar seus conhecimentos? Respire e vamos 
em frente! Procure um ambiente que facilite a concentração, assim absorve-
rá melhor as informações.
CHAMADA
56
57
TÓPICO 1
OLAP x OLTP
UNIDADE 2
1 INTRODUÇÃO
O termo Data Warehouse, como em sua tradução, tem o papel de atuar 
como um armazém de dados. Seu objetivo é armazenar os dados de todos os sis-
temas que a empresa utiliza, bem como ser alimentados de fontes externas (como 
a Web).
Uma vez os dados estando armazenados em um Data Warehouse, são uti-
lizados para gerar poder decisório para uma organização. Isso significa utilizar 
os dados armazenados, realizando análises que deem suporte a decisões impor-
tantes nas organizações.
Supondo que um Data Warehouse seja desenvolvido para uma multina-
cional que fabrica veículos, ele deve permitir extrair informações do tipo:
● Quais regiões são mais lucrativas?
● Quais são os insumos mais caros?
● Quais os funcionários mais produtivos?
● Quais são os veículos que mais vendem?
Nesse momento você pode estar se perguntando se esse tipo de consulta 
não poderia ser gerado por consultas SQL. No entanto, vale lembrar que uma das 
características de um Data Warehouse é que ele é integrado, isso significa que é 
alimentado por diversas fontes de dados. Com o desenvolvimento de modelos 
multidimensionais, torna-se possível realizar consultas pelas mais diversas pers-
pectivas. Complementado pelas ferramentas de visualização, é possível realizar:
● A combinação de itens que mais causa infelicidade ao cliente.
● O perfil de cliente que é mau pagador.
● Tirar diagnósticos em que há gargalo na produção. 
O objetivo deste tópico é compreendermos melhor o funcionamento dos 
sistemas transacionais, relacionando-o com os ambientes de consulta de um Data 
Warehouse.
UNIDADE 2 | 
58
2 OLAP VS OLTP
O processo de Data Warehouse fornece arquiteturas e ferramentas para 
que os executivos organizem sistematicamente, entendam e usem seus dados 
para tomar decisões estratégicas. Os sistemas de Data Warehouse são ferramen-
tas valiosas no mundo competitivo e de rápida evolução. 
Nos últimos anos, muitas empresas gastaram milhões de dólares na cons-
trução de Data Warehouses em toda a empresa. Muitas pessoas acham que, com 
a crescente concorrência em todos os setores, o Data Warehouse se torna uma fer-
ramenta de marketing essencial – uma maneira de reter os clientes, aprendendo 
mais sobre suas necessidades (HAN; PEI; KAMBER, 2011).
No entanto, quando realizamos o desenvolvimento de um ambiente de 
Data Warehouse, o objetivo é que este esteja apto a realizar um conjunto de ope-
rações de consulta on-line, ou seja, todo projeto de um Data Warehouse tem como 
objetivo o desenvolvimento de análises. 
Este tipo de ambiente utiliza um processo denominado Online Analytical 
Processing (OLAP). O Termo OLAP tem seu significado como base na análise, 
afinal, o objetivo de um Data Warehouse é prover uma arquitetura voltada para 
o consumo de dados.
Deste modo, em um ambiente OLAP, desde a modelagem, projeto da ar-
quitetura e até mesmo no desenvolvimento, todas as etapas são desenvolvidas 
com ênfase na otimização das consultas que serão realizadas. 
Por outro lado, os sistemas transacionais são desenvolvidos e orientados 
a transações, por isso são denominados Online Transaction Processing (OLTP). De 
modo geral, transações são operações de persistência de dados (inserção, atuali-
zação e remoção, que podem acontecer independente ou em conjunto). 
Este tipo de sistema, o mesmo que alimenta um Data Warehouse (siste-
mas operacionais, por exemplo: gestão de estoque, gestão de vendas, entre ou-
tros), tem como objetivo garantir integridade durante a realização das transações, 
por isso todos os recursos são desenvolvidos com ênfase nelas. Ao contrário de 
um ambiente de Data Warehouse, que tem como objetivo fazer consultas, os sis-
temas OLTP têm ênfase em realizar inserções, alterações e exclusões para garantir 
a integridade dos dados.
No sentido de comparar as diferenças entre essas abordagens, Han, Pei e 
Kamber (2011) elencam os seguintes pontos de comparação:
• Usuários e orientação do sistema: um sistema OLTP é orientado ao cliente e é 
usado para processamento de transações e consultas por funcionários, clientes 
e profissionais de tecnologia da informação. Um sistema OLAP é orientado 
para o mercado e é usado para análise de dados por profissionais do conheci-
mento, incluindo gerentes, executivos e analistas.
• Conteúdo dos dados: um sistema OLTP gerencia dados atuais que, geralmen-
te, são muito detalhados para serem facilmente usados na tomada de decisões. 
TÓPICO 1 | OLAP x OLTP
59
Um sistema OLAP gerencia grandes quantidades de dados históricos, fornece 
facilidades para resumo e agregação e armazena e gerencia informações em 
diferentes níveis de granularidade. Esses recursos facilitam o uso dos dados 
para tomadas de decisão informadas.
• Design do bancode dados: um sistema OLTP geralmente adota um modelo de 
dados de relacionamento com entidades e um design de banco de dados orien-
tado a aplicativos. Um sistema OLAP geralmente adota um modelo em estrela 
ou em floco de neve e um design de banco de dados orientado ao assunto.
• Visualização: um sistema OLTP concentra-se principalmente nos dados atuais 
de uma empresa ou departamento, sem se referir a dados históricos ou da-
dos em diferentes organizações. Por outro lado, um sistema OLAP geralmente 
abrange várias versões de um esquema de banco de dados, devido ao pro-
cesso evolutivo de uma organização. Os sistemas OLAP também lidam com 
informações originadas de diferentes organizações, integrando informações de 
muitos armazenamentos de dados. Devido ao seu enorme volume, os dados 
OLAP são armazenados em várias mídias de armazenamento.
• Padrões de acesso: os padrões de acesso de um sistema OLTP consistem prin-
cipalmente em transações atômicas curtas. Esse sistema requer mecanismos de 
controle e recuperação de simultaneidade. No entanto, os acessos aos sistemas 
OLAP são principalmente operações de somente leitura (porque a maioria dos 
data warehouses armazena informações históricas em vez de atualizadas), em-
bora muitos possam ser consultas complexas.
Quando nos referimos aos ambientes OLTP, estamos falando dos sistemas 
operacionais que alimentam um Data Warehouse: sistemas de venda, gestão de clientes, 
sistema de estoque, entre outros. Já tratando-se de OLAP, estamos falando de ambientes 
de consulta em um Data Warehouse.
IMPORTANT
E
2.1 MODELAGEM E PROGRAMAÇÃO EM AMBIENTES 
TRANSACIONAIS
Antes de darmos continuidade ao nosso estudo sobre o desenvolvimento 
de ambiente de Data Warehouse e sistemas OLAP, é importante consolidarmos 
nossos conhecimentos básicos sobre os sistemas transacionais.
Em sistemas transacionais, a modelagem é realizada por intermédio do 
modelo relacional. Este modelo tem como principal objetivo a integridade dos 
dados, ou seja, independente da aplicaç ão, o banco de dados conseguirá ter da-
dos sólidos. Garantir a integridade dos dados significa que após o seu armazena-
mento, eles poderão ser recuperados no mesmo estado, sem sofrer alterações não 
autorizadas.
UNIDADE 2 | 
60
A integridade pode ser garantida de maneira física, no entanto, ainda 
mesmo na modelagem, podem ser criados mecanismos para garantir a integri-
dade dos dados. Isto muitas vezes acontece pelo processo de normalização dos 
dados (ELMASRI; NAVATHE, 2011). 
A normalização dos dados é um processo realizado com objetivo de se ob-
ter um modelo de dados mais íntegro possível, e com essas normas respeitadas, 
as redundâncias e inconsistências poderão ser evitadas. Deste modo, Nogueira 
(2016) elenca as três primeiras formas normais e os passos seguidos para garantir 
que elas sejam cumpridas:
● Primeira Forma Normal: a primeira forma normal trata da atomicidade dos 
atributos, proibindo atributos compostos, multivalorados e relações aninha-
das. Para que uma tabela esteja na primeira forma normal, é preciso obedecer 
aos seguintes passos:
○ 1. Identificar a chave primária da tabela.
○ 2. Procurar o grupo que está se repetindo e retirá-lo da tabela.
○ 3. Criar uma nova tabela com os atributos repetidos, em que a chave primá-
ria desta tabela será chave estrangeira na tabela anterior.
○ 4. Repetir este processo até que todas as tabelas geradas estejam na primeira 
forma normal.
● Segunda Forma Normal: a segunda forma normal está relacionada à depen-
dência funcional da chave primária. Para estar na segunda forma normal, a 
tabela deve estar na primeira forma normal e nenhum dos campos que não são 
chaves podem depender apenas de parte da chave primária. Para remover a 
dependência funcional, os passos a seguir devem ser respeitados:
○ 1. Identificar campos que são dependentes apenas de parte da chave primá-
ria e não da chave primária como um todo.
○ 2. Remover da tabela todos os campos que não são dependentes funcionais.
● Terceira Forma Normal: a terceira forma normal está relacionada à chamada 
dependência transitiva, ou seja, um campo não deve depender de um outro 
campo “não chave”. Para remover a dependência transitiva, deve-se identificar 
os campos que são dependentes transitivos de outros campos e removê-los.
Para compreender melhor o processo de normalização e das formas normais, 
deixamos uma sugestão de leitura com exemplos passo a passo: Normalização de dados 
e as formas normais. Disponível em: https://www.luis.blog.br/normalizacao-de-dados-e-
-as-formas-normais.html.
DICAS
2.2 OLTP - UTILIZANDO SQL 
No desenvolvimento de sistemas transacionais, os dados são armazena-
dos, tradicionalmente, nos sistemas gerenciadores de bancos de dados, softwares 
TÓPICO 1 | OLAP x OLTP
61
utilizados para fazer a interface entre aplicações e os dados. O SGBD é, portanto, 
um sistema de software de propósito geral que facilita os processos de definição, 
construção, manipulação e compartilhamento de bancos de dados entre vários 
usuários e aplicações. A definição de um banco de dados implica especificar os ti-
pos de dados, as estruturas e as restrições para serem armazenados em um banco 
de dados (ELMASRI; NAVATHE, 2011). 
Na unidade anterior você aprendeu a utilizar o PostgreSQL por intermé-
dio da ferramenta on-line ElephantSQL. Desta forma, você poderá continuar uti-
lizando esta ferramenta para a execução dos exemplos a serem expostos neste 
tópico. Para instalar em sua máquina o PostgreSQL para todos os sistemas opera-
cionais, acesse o link: https://www.postgresql.org/download/.
Os sistemas gerenciadores de bancos de dados relacionais utilizam uma 
linguagem comum, denominada SQL (Structured Query Language) – linguagem 
de consulta estruturada. Mesmo que cada SGBD tenha sua particularidade, existe 
todo um conjunto de comandos que são comuns a todos. Estudaremos a seguir 
alguns deles. 
Para exemplificar, considere o seguinte modelo de dados, criado para re-
presentar um sistema de vendas e controle de estoque. Como se trata de um ban-
co de dados relacional, durante sua criação, torna-se necessário fazer referência 
entre as tabelas. A ligação que é mostrada na imagem graficamente, durante a 
criação da SQL, será feita pelas chaves primárias e estrangeiras. Vamos fazer um 
exemplo da criação das tabelas pessoa, cliente e fornecedor?
QUADRO 1 – CRIAÇÃO DE TABELAS
CREATE TABLE PESSOA
(
 ID_PESSOA INTEGER NOT NULL,
 NOME VARCHAR(100) NOT NULL,
 ENDERECO VARCHAR(100) NOT NULL,
 PRIMARY KEY (ID_PESSOA)
);
CREATE TABLE FORNECEDOR
(
 ID_FORNECEDOR INTEGER NOT NULL,
 CNPJ VARCHAR(14) NOT NULL,
 FOREIGN KEY (ID_FORNECEDOR) REFERENCES PESSOA (ID_PESSOA),
 PRIMARY KEY (ID_FORNECEDOR)
);
CREATE TABLE CLIENTE
(
 ID_CLIENTE INTEGER NOT NULL,
 CPF VARCHAR(11) NOT NULL UNIQUE,
 DATA_NASC TIMESTAMP NOT NULL,
 PRIMARY KEY (ID_CLIENTE),
 FOREIGN KEY (ID_CLIENTE) REFERENCES PESSOA (ID_PESSOA)
);
FONTE: O autor
https://www.postgresql.org/download/
UNIDADE 2 | 
62
Quando criamos tabelas normalizadas, um banco de dados terá um nú-
mero maior de tabelas, que dependerão uma da outra. No exemplo criado ante-
riormente, note que para inserir um cliente ou um fornecedor, é necessário que 
o registro já exista na tabela pessoa. Vejamos os passos necessários para popular 
esta base de dados.
QUADRO 2 – POPULANDO UM BANCO DE DADOS
INSERT INTO PESSOA (ID_PESSOA, NOME, ENDERECO) VALUES
(1, 'Luiz Fernando', 'Rua das Flores'),
(2, 'Bruce Wayne', 'Mansão'),
(3, 'Darth Vader', 'Força Negra'),
(4, 'Yoda', 'não ter'),
(5, 'Obi Wan','Terra Venus'),
(6, 'Barry Allen', 'Central City'),
(7, 'Felicity Smoak', 'Star City'),
(8, 'Solomon Grundy', 'Cyrus Gold'),
(9, 'Clark Kent', 'Metropolis'),
(10, 'Ted Mosby', 'New York');
INSERT INTO CLIENTE (ID_CLIENTE, CPF, DATA_NASC) VALUES
(1, 66666666666, '1989-03-25'),
(3, 99999999999, '1910-05-12'),
(6, 88888888887, '1990-05-12'),
(7, 88888888888, '1990-10-12'),
(9, 33333333333, '1950-05-05');
INSERT INTO FORNECEDOR (ID_FORNECEDOR,CNPJ) VALUES (2, 66666666666),
(4, 999999999999),
(5, 8888888887),
(8, 8888888888888),
(10, 3333333333333);
FONTE: O autor
Uma vez estes dados estando armazenados, podem ser recuperados atra-
vés do comando SQL SELECT, que é utilizado para retornar valores em um banco 
de dados. Segundo Sallai (2014), na construção de relatórios, os comandos SE-
LECT podem vir acompanhados da instrução WHERE, que aplica filtros e jun-
ções (JOIN). Entre essas junções, as mais comuns podem ser:
● INNER JOIN: o Inner Join é o método de junção mais conhecido e retorna os 
registros que são comuns às duas tabelas de uma junção.
● LEFT JOIN: o Left Join tem como resultado todos os registros que estão na ta-
bela A (mesmo que não estejam na tabela B) e os registros da tabela B que são 
comuns à tabela A.
● RIGHT JOIN: usando o Right Join, teremos como resultado todos os registros 
que estão na tabela B (mesmo que não estejam na tabela A) e os registros da 
tabela A que são comuns à tabela B.
TÓPICO 1 | OLAP x OLTP
63
FIGURA 1 – REPRESENTAÇÃO GRÁFICA DOS JOIN
 
FONTE: Adaptada de Sallai (2014)
No exemplo do sistema de vendas, podemos utilizar os comandos de jun-
ção para extrair os mais diversos relatórios. Vamos conferir alguns exemplos:
Selecionar todos os produtos cujo preço custe mais do que R$ 4000
SELECT * FROM produto where preco > 4000.00
Selecionar todos os fornecedores 
SELECT f.cnpj, p.nome from pessoa
 INNER JOIN fornecedor as f
 on f.id_fornecedor = p.ID_PESSOA
Selecionar todos os clientes 
SELECT p.nome, p.endereco from pessoa
 INNER JOIN cliente as c
 ON c.id_cliente = p.id_pessoa
Selecionar o total de clientes
SELECT count(c.id_cliente)
from cliente as c;
UNIDADE 2 | 
64
Selecionar o total já vendido pela empresa
SELECT sum(p.preco)
from produto as p
 INNER JOIN produto_estoque as pe
 ON pe.id_produto = p.id_produto
 INNER JOIN item_venda as iv
 ON iv.id_estoque = pe.id_estoque;
Com isso finalizamos nossa abordagem sobre os comandos SQL em am-
bientes transacionais. É importante ressaltar que tais comandos, principalmente 
as consultas, serão muito utilizados na construção e manutenção de ambientes de 
Data Warehouse (OLAP).
O processo de modelagem, construção e manipulação de um banco de dados 
envolve diversos fatores. Deixamos sugestões de leitura para que você possa se aprofundar 
neste tema.
MILANI, A. PostgreSQL-Guia do Programador. São Paulo: Novatec, 2008.
SILBERSCHATZ, A.; SUNDARSHAN, S.; KORTH, H. F. Sistema de banco de dados. Rio de 
Janeiro: Elsevier, 2016.
DICAS
65
RESUMO DO TÓPICO 1
Neste tópico, você aprendeu que:
• Os sistemas OLTP são orientados a transações.
• Os sistemas OLAP são orientados a consultas.
• As diferenças entre OLAP e OLTP estão na modelagem dos dados e entendeu 
como funcionam os sistemas OLTP.
• É possível utilizar SQL para criar e manipular um banco de dados.
66
AUTOATIVIDADE
Para desenvolver as atividades propostas, considere o modelo utilizado sobre 
o sistema de vendas.
1 Utilizando o comando CREATE e explorando as chaves primárias e estran-
geiras, crie a estrutura completa do modelo de vendas. 
2 A partir da estrutura criada, popule a tabela venda. Para isso, realize todas 
as inserções necessárias, lembrando que é necessário existir clientes cadastra-
dos e produtos em estoque.
3 Com os dados armazenados, produtos em estoque e vendas realizadas, crie 
uma consulta que retorne à quantidade de produtos já vendidos.
4 A partir dos dados armazenados no banco, crie uma consulta que retorne o 
código da venda e a quantidade de produtos vendidos. 
5 A partir dos dados armazenados no banco, crie uma consulta que retorne o 
código da venda e o total por venda (R$).
67
TÓPICO 2
EXTRAÇÃO, TRANSFORMAÇÃO E CARGA
UNIDADE 2
1 INTRODUÇÃO
O Processo de ETL – Extract Transform and Load –, em português Extra-
ção, Transformação e Carga, é responsável por fazer a integração entre as fontes 
de dados e um Data Warehouse desenvolvido. 
O processo de ETL está no coração de um projeto de Data Warehouse, 
pois em bancos de dados transacionais, a integridade dos dados é responsabilida-
de de um SGBD a partir de uma modelagem realizada com qualidade. 
Em um Data Warehouse, espera-se que os dados cheguem ao modelo 
multidimensional com a integridade garantida, e essa garantia é responsabilida-
de do processo de ETL.
O processo de ETL é tão importante que muitos autores afirmam que é 
nessa etapa que grande esforço computacional acontece. Para Kimball e Ross 
(2011), cerca de 70% do tempo gasto no desenvolvimento de um Data Warehou-
se é gasto na ETL. Nagabhushana (2006) afirma que cerca de 60% a 80% de um 
projeto de implementação de um Data Warehouse seja dedicado à etapa de ETL. 
FIGURA 2 – EXTRAÇÃO, TRANSFORMAÇÃO E CARGA
FONTE: <HTTPS://WWW.DBBEST.COM/BLOG/EXTRACT-TRANSFORM-LOAD-ETL-
TECHNOLOGIES-PART-1/>. Acesso em: 1º mar. 2020.
UNIDADE 2 | 
68
Sobre o processo de ETL, Nogueira (2017) descreve cada etapa como:
● Extração: é responsável por extrair os dados das fontes, ou seja, é o processo de 
recuperação dos dados necessários das fontes de origem, que podem ser as ta-
belas reais ou simplesmente cópias que foram carregadas no Data Warehouse. 
A etapa de extração deve ser capaz de ler e compreender os dados da fonte e 
copiar apenas os dados necessários.
● Transformação: esta etapa, literalmente, transforma os dados coletados das fon-
tes de acordo com os definidos no modelo do Data Warehouse. Nesta etapa, são 
realizados pré-processamentos, nos quais são identificados os dados duplicados, 
integração entre os dados, substituição de valores, limpeza de campos e toda a 
transformação necessária para adequar as fontes de dados. Um exemplo de uma 
transformação comum realizada por processos ETL é relacionado com campos 
de sexo, em alguns sistemas são “M” para Masculino e “F” para Feminino, po-
rém em outros está guardado como “H” para Masculino e “M” para Feminino, 
em outros, ainda, podemos encontrar “1” para Masculino e “2” para Feminino, 
cabendo transformá-los para um único formato. A etapa de transformação tam-
bém é responsável por resolver desafiadores problemas oriundos das fontes de 
dados, como ausência de informação, valores inválidos, ausência de integridade 
referencial, violação de regras de negócios, cálculos inválidos, duplicação de in-
formação, inconsistência de dados e falhas na modelagem das fontes de dados. 
● Carga: uma vez que os dados foram coletados e transformados, a etapa de carga 
é responsável por armazenar os dados no Data Warehouse. Na etapa carga, o 
Data Warehouse é alimentado com novos dados, de forma que as estruturas de 
dados (por exemplo, tabelas no caso de bancos relacionais) sejam atualizadas 
para conter os novos dados. Normalmente, o Data Warehouse é colocado off-line 
durante a carga, de forma que nenhum usuário possa consultar o Data Warehou-
se simultaneamente. Como o armazenamento de dados em ambientes de Data 
Warehouse, normalmente, envolve grandes quantidades de dados, a etapa de 
carga sempre ocorre em um período regular, por exemplo, diariamente.
A importância do processo de ETL pode ser compreendida na definição 
de Kimball e Caserta (2011), que afirma que um sistema de ETL é análogo ao da 
cozinha de um restaurante, onde os chefes pegam matérias-primas e as trans-
formam em deliciosas refeições para os clientes. Sendo assim, o maior esforço 
computacional é responsável pela preparação dos dados contidos na ETL, fican-
do as camadas de Data Warehouse e de visualização de dados responsáveis por 
consumir, alimentando-se destes dados que já estão “prontos”.
A ETL é composta por três etapas: Extração, Transformação e Carga, bem 
como um conjunto de ferramentas para realizar essas operações. Estudaremos a 
seguir cada uma delas.
TÓPICO 2 | EXTRAÇÃO, TRANSFORMAÇÃO E CARGA
69
2 FERRAMENTAS DE ETL
 
Durante o projeto de um Data Warehouse, muitas decisões devem ser to-
madas, como qual modelagem realizar, qual sistema gerenciador de bancode 
dados utilizar, bem como qual ferramenta será utilizada para desenvolvimento 
do processo de ETL. 
Vale ressaltar que o processo de ETL não precisa estar associado a uma 
ferramenta, e seu processo é definido pela arquitetura que será utilizada. A ferra-
menta utilizada deverá dar suporte ao processo definido. Sobre a escolha de uma 
ferramenta de ETL para dar suporte ao processo de Data Warehouse, Ferreira et 
al. (2010a) elencam os seguintes pontos que devem ser considerados:
● Suporte à plataforma: deve ser independente de plataforma de Banco de Da-
dos, podendo assim correr em qualquer uma.
● Tipo de fonte independente: deve ser capaz de ler diretamente da fonte de da-
dos, independentemente do seu tipo, saber se é uma fonte de SGBDR, arquivo 
simples ou um arquivo XML. 
● Apoio funcional: deve apoiar-se na extração de dados de múltiplas fontes, na lim-
peza de dados e na transformação, agregação, reorganização e operações de carga. 
● Facilidade de uso: deve ser facilmente usada pelo usuário.
● Paralelismo: deve apoiar as operações de vários segmentos e execução de có-
digo paralelo, internamente, de modo que um determinado processo pode ti-
rar proveito do paralelismo inerente da plataforma que está sendo executada. 
Também deve suportar a carga, ter equilíbrio entre os servidores e capacidade 
de lidar com grandes volumes de dados. Quando confrontados com cargas 
muito elevadas de trabalho, a ferramenta deve ser capaz de distribuir tarefas 
entre múltiplos servidores. 
● Apoio ao nível do debugging: deve apoiar o tempo de execução e a limpeza 
da lógica de transformação. O utilizador deve ser capaz de ver os dados antes 
e depois da transformação. 
● Programação: deve apoiar o agendamento de tarefas ETL, aproveitando, as-
sim, melhor o tempo, não necessitando de intervenção humana para completar 
uma tarefa particular. Deve também ter suporte para programação em linha de 
comandos usando programação externa. 
● Implementação: deve suportar a capacidade de agrupar os objetos ETL e im-
plementá-los em ambiente de teste ou de produção, sem a intervenção de um 
administrador de ETL. 
● Reutilização: deve apoiar a reutilização da lógica de transformação para que o 
utilizador não precise reescrever, várias vezes, a mesma lógica de transforma-
ção outra vez.
Existe uma gama de ferramentas para realizar o processo de ETL forne-
cido pelas mais diversas empresas. Em um estudo recente, Souibgui et al. (2019) 
realizou a comparação e indica como atuais as ferramentas Talend Data Integra-
tion, Pentaho Data Integration, Microsoft SQL Server Integration e Services Infor-
matica Data Integration. 
UNIDADE 2 | 
70
Em um estudo anterior, Ferreira et al. (2010a) indicavam um conjunto de 
ferramentas que podem ser utilizadas no processo de ETL: 
● Oracle Warehouse Builder (OWB).
● Data Integrator & Data Services XI.
● IBM Information Server.
● PowerCenter. 
● Elixir Repertoire. 
● SQL Server Integration Services.
● Talend Open Studio & Integration Suite. 
● DataFlow Manage.
● Data Integrator. 
● Open Text Integration Center. 
● Transformation Manager. 
● Data Manager/Decision Stream.
● Clover ETL.
● Pentaho Data Integration.
● Adeptia Integration Server.
Do ponto de vista acadêmico, bem como do ponto de vista financeiro de 
uma organização, sempre é bom ter uma perspectiva do custo do uso de uma 
ferramenta, optando-se sempre pelo emprego de tecnologias livres.
Sobre ferramentas ETL de livres e proprietárias, Ferreira et al. (2010b) 
elencam como ferramentas livres de ETL: Pentaho, SpagoBI e JasperSoft; e como 
ferramentas proprietárias: Business Object , Cognos, Microsoft , Microstrategy e 
SpotFire.
2.1 ETL E BIG DATA STREAMING 
Quando se fala de Big Data e o processo de ETL para ambientes de Data 
Warehouse, é comum o termo Big Data Streaming aparecer. Segundo Nogueira 
(2019), o termo streaming é utilizado em diversos contextos em tecnologia, como 
serviços de streaming de música e vídeo, que têm como objetivo fornecer esses 
recursos em tempo real. No contexto de Big Data e dados, streaming de dados 
representa coleta e armazenamento em tempo real.
Quando falamos em Big Data Streaming, os frameworks Apache Hadoop 
e Apache Spark são comumente citados, afinal são os principais do mercado. 
O Hadoop é um framework de Big Data com ênfase em hardware de 
baixo custo, o Hadoop é composto por diversos projetos, dentre o qual o que se 
destaca é o Hadoop File System, um sistema de arquivos distribuídos que faz 
com que diversos computadores unidos sejam reconhecidos como um supercom-
putador. O Spark, por outro lado, é um framework para processamento de Big 
Data construído com foco em velocidade, facilidade de uso e análises sofisticadas. 
TÓPICO 2 | EXTRAÇÃO, TRANSFORMAÇÃO E CARGA
71
Oferece APIs de alto nível em Java, Scala e Python, bem como um conjunto de 
bibliotecas que o tornam capaz de trabalhar de forma integrada, em uma mesma 
aplicação, com SQL, streaming e análises complexas, para lidar com uma grande 
variedade de situações de processamento de dados (COMPUTERWORLD, 2020).
Para compreender melhor a relação do processo ETL tradicional compa-
rado com o processo de ETL feito por um framework de streaming de Big Data, o 
Quadro 1 mostra um comparativo entre tais abordagens. 
QUADRO 3 – COMPARANDO ETL NORMAL E BIG DATA STREAMING
Vantagens do processo ETL
ETL Tradicional ETL Utilizando Hadoop
Facilidade de desenvolvimen-
to: como o processo geralmente 
envolve o desenvolvimento da 
saída para trás e o carregamen-
to apenas dos dados relevantes, 
reduz a complexidade e o tempo 
envolvidos no desenvolvimento.
Separação de preocupações: o processo de 
ETL separa as tarefas de carregamento e 
transformação em blocos independentes e, 
assim, minimiza as interdependências entre 
esses processos. Isso facilita o gerenciamen-
to de projetos, pois o projeto pode ser divi-
dido em partes gerenciáveis. Isso também 
minimiza os riscos, pois um problema em 
uma área não afeta a outra.
Maturidade do processo: esse 
processo tem sido a norma para 
o desenvolvimento de Data Wa-
rehouse e está em prática há 
mais de duas décadas. O pro-
cesso de ETL é bastante maduro, 
com várias implementações de 
produção e boas práticas e pro-
cessos bem definidos.
Flexível e à prova do futuro: na implemen-
tação da ETL, dados completos dos sistemas 
de origem já estão disponíveis no data lake. 
Isso, combinado com o isolamento do pro-
cesso de transformação, garante que requisi-
tos futuros possam ser facilmente incorpora-
dos à estrutura do Data Warehouse.
Disponibilidade de ferramen-
tas: está disponível um núme-
ro prolífico de ferramentas que 
implementam ETL. Isso fornece 
flexibilidade na escolha da ferra-
menta mais apropriada.
Utiliza hardware existente: o Hadoop usa 
o mesmo hardware para armazenamento e 
também para processamento. Isso ajuda a 
reduzir os custos adicionais de hardware. 
Disponibilidade de conhecimen-
to: as décadas de existência e a 
adoção extensiva do processo de 
ETL em todo o mundo garanti-
ram uma disponibilidade abun-
dante de especialistas em ETL.
Custo-benefício: todos os pontos mencio-
nados, além da estrutura Hadoop de códi-
go aberto, reduzem custos consideráveis de 
operação e manutenção do processo de ETL.
UNIDADE 2 | 
72
Desvantagens do processo ETL
ETL Tradicional ETL Utilizando Hadoop
Flexibilidade: o processo ETL 
carrega apenas os dados impor-
tantes, conforme identificados no 
momento do design. Se houver 
a necessidade de adicionar um 
atributo de dados adicional ou 
se um novo atributo de dados for 
introduzido no sistema, isso en-
volveria a atualização e a reenge-
nharia de toda a rotina ETL.
Maturidade do processo: embora o processo 
de ETL já esteja lá há algum tempo, ele não 
foi amplamente adotado. No entanto, o pro-
cesso de ETL está ganhando popularidade e 
adoção com a ascensão do Hadoop. A cola-
boração em todo o setor para implementar as 
melhores práticas de ETL está aumentando.
Hardware: a maioria das ferra-
mentasETL vem com seus pró-
prios requisitos de hardware. 
Eles possuem mecanismos de 
execução de proprietários que 
não usam o hardware do arma-
zém de dados existente. Isso 
gera custos adicionais.
Disponibilidade de ferramentas: como re-
sultado da adoção limitada, atualmente o 
número de ferramentas disponíveis para 
implementar processos ETL no Hadoop afe-
ta a disponibilidade de especialistas em ELT.
Custo: os custos de manutenção, 
hardware e licenciamento das 
ferramentas ETL somam ao cus-
to total de operação e manuten-
ção do processo ETL.
Limitado a dados relacionais: 
as ferramentas ETL tradicionais 
são limitadas principalmente ao 
processamento de dados relacio-
nais. Eles não conseguem pro-
cessar dados semiestruturados e 
não estruturados, como feeds de 
mídia social, arquivos de log etc.
Disponibilidade de conhecimento: a ado-
ção limitada da tecnologia ELT novamente 
afeta a disponibilidade de especialistas em 
ELT. Atualmente, os especialistas do ELT no 
Hadoop são escassos. No entanto, isso está 
mudando rapidamente. A imensa populari-
dade e adoção do Hadoop e ELT no Hadoop 
está aumentando o número de pessoas tra-
balhando nessas tecnologias.
FONTE: Adaptado de Bitwise (2020)
Um ponto importante é que as ferramentas de ETL tradicionais não estão dis-
sociadas do Apache Hadoop. Este pode ser inclusive um ponto decisório na escolha de 
uma ferramenta para realizar o processo de ETL. Um exemplo é o Pentaho Data Integration, 
que pode ser conectado ao Apache Hadoop para realizar os processos de ETL. 
ATENCAO
TÓPICO 2 | EXTRAÇÃO, TRANSFORMAÇÃO E CARGA
73
2.2 ETL NA NUVEM
Por uma outra perspectiva, segundo a ComputerWorld (2020), os serviços 
de cloud movimentarão mais de US$ 300 bilhões até 2021. A matéria ainda discu-
te um estudo de Gartner que indica que os serviços de TI estão crescendo de 2% a 
3% ao ano, enquanto o crescimento da Nuvem deve crescer seis vezes mais, com 
alta estimada em 18%.
Quando falamos de computação em nuvem e o emprego de serviços como 
Amazon AWS, Microsoft, IBM, Google Cloud, entre muitos outros, segundo Rolo 
(2016), a grande capacidade de armazenamento e o grande poder de processa-
mento têm potencializado que arquiteturas como Data Warehouses sejam hospe-
dadas na nuvem, originando o surgimento de novas aplicações analíticas.
Quando nos referimos à nuvem, estamos falando de um mercado gigante 
e milionário que está diariamente brigando pelo futuro da era da informação. São 
tantas ferramentas e tantas empresas que seria necessário um livro inteiro apenas 
para comparar as ferramentas de ETL em nuvem.
Leia o artigo de Peter Sayer: 12 principais ferramentas de Business Intelli-
gence em 2019. Disponível em: https://cio.com.br/12-principais-ferramentas-de-busines-
s-intelligence-em-2019/. 
DICAS
Dentre vários fatores que podem te levar a escolha de uma ferramenta de 
ETL com ênfase na nuvem, o fator principal é a arquitetura. Caso a arquitetura 
tenha sido projetada inteiramente na nuvem, o recomendado é optar por uma op-
ção de ferramenta de ETL que permita ao mesmo suite em nuvem que esteja sen-
do utilizado para toda arquitetura de Big Data e Data Warehouse. Um exemplo 
deste tipo de ferramenta é o AWS Glue, pertencente ao suite em nuvem Amazon 
Web Services. Este tipo de ETL tem um papel em uma arquitetura própria e tende 
a funcionar melhor quando são utilizados todos os recursos da plataforma, pois 
já está integrado ao ambiente.
O AWS Glue é um serviço de extração, transformação e carga (ETL) geren-
ciado que facilita a preparação e a carga de dados para análises pelos clientes. Você 
pode criar e executar uma tarefa de ETL com apenas alguns cliques no Console 
de Gerenciamento da AWS. Basta indicar ao AWS Glue os dados armazenados na 
AWS que ele os descobre e armazena os metadados associados (ex.: definição e 
esquema de tabela) no AWS Glue Data Catalog. Uma vez catalogados, os dados 
são disponibilizados imediatamente para pesquisas, consultas e ETL (AWS, 2020).
UNIDADE 2 | 
74
FIGURA 3 – ARQUITETURA DE UMA APLICAÇÃO ETL DA NUVEM AWS
FONTE: <HTTPS://WWW.DBBEST.COM/BLOG/EXTRACT-TRANSFORM-LOAD-ETL-
TECHNOLOGIES-PART-1/>. Acesso em: 1º mar. 2020.
2.3 PENTAHO DATA INTEGRATION
 
Pentaho é um software de código aberto para Business Intelligence desen-
volvido em 2004 utilizando a linguagem Java. Desde então o Suite Pentaho ga-
nhou novas versões, bem como diversos recursos para todas as etapas do proces-
so de Data Warehouse e opções avançadas para Big Data e mineração de dados.
Em 2015, a empresa Pentaho foi adquirida pela Hitachi Data Systems em 
uma operação milionária considerada a maior operação entre empresas de Big 
Data. A Pentaho era uma das principais empresas globais do setor, com uma 
grande plataforma baseada em código aberto para diversas soluções de Big Data. 
Com a aquisição, a Hitachi se posicionou de forma única no mercado, oferecendo 
integração de dados, expertise em business analytics e tecnologias fundamentais 
para agregar valor ao Big Data (HITACHI, 2015). 
Uma das principias características do Pentaho no passar dos anos, e que 
se mantém atualmente, é o fato de sempre ter softwares proprietários, mas nunca 
deixar de manter a versão livre. O fato de o Pentaho ser um software livre e de 
código aberto faz com que ele esteja em evidência no mundo das ferramentas 
para Business Intelligence.
Sobre o processo de ETL, a ferramenta dentro do suite Pentaho é o Pentaho 
Data Integration, que por sinal é considerado o carro-chefe para quem utiliza os 
recursos do Pentaho. O Pentaho Data Integration – PDI –, também conhecido como 
Kettle, é a ferramenta de ETL da Pentaho. É um software desenvolvido em Java 
baseado no conceito de processo para extração, transformação e carga (ETL) de 
dados. O Pentaho Data Integration (PDI) fornece ferramentas que incluem ETL e 
agendamento em um ambiente unificado – a interface do cliente PDI (LIMA, 2019).
https://www.dbbest.com/blog/extract-transform-load-etl-technologies-part-1/
https://www.dbbest.com/blog/extract-transform-load-etl-technologies-part-1/
TÓPICO 2 | EXTRAÇÃO, TRANSFORMAÇÃO E CARGA
75
Para utilizar o PDI, é recomendável que seja utilizada a versão CE, que 
é a versão disponibilizada em software livre. A versão atual do Pentaho CE está 
disponível no link: https://sourceforge.net/projects/pentaho/.
FIGURA 4 – PENTAHO DATA INTEGRATION - TELA INICIAL
FONTE: O autor 
O funcionamento do PDI segue conforme o processo de ETL, ou seja, seus 
componentes são voltados para extração, transformação e carga. No geral, os 
componentes do Pentaho são divididos entre jobs e transformações.
 
Tanto em um Job quanto em uma Transformação é possível criar passos 
para automatizar tarefas de ETL, porém, na Transformação, criamos alguma ta-
refa mais detalhada, pois oferece maiores recursos para o tratamento dos dados. 
Já no Job, podemos utilizar para integrar várias Transformações, criando assim 
um projeto com várias etapas de tratamento, ainda é possível adicionar regras 
de validação e controle de fluxo. É interessante conseguirmos dividir um projeto 
em Transformações que fazem pequenas tarefas, assim é possível reaproveitá-las 
(SALDANHA, 2018).
2.4 PROGRAMANDO UMA FERRAMENTA DE ETL
Durante nosso estudo sobre os tipos de dados, na Unidade 1, você apren-
deu que 80% dos dados são do tipo estruturado e não estruturado. Em um cenário 
onde imagens, textos, áudios, vídeos e textos dominam os dados, cada vez mais 
os sistemas de Business Intelligence se tornam complexos de ser desenvolvidos, 
e muitas vezes as ferramentas podem não dar suporte.
https://sourceforge.net/projects/pentaho/
UNIDADE 2 | 
76
Outro ponto é o fato da integração com outros setores, como equipes de 
Big Data e Machine Learning, que já utilizam tecnologias específicas, das quais há 
um destaque especial para a linguagem Python. 
Um exemplo do desenvolvimento da própria ferramenta de ETL é o caso 
de Lyra (2016), que para o desenvolvimento de Dashboards sobre dados da te-
lefonia móvel,utilizou programas escritos nas linguagens Python e Shell Script 
para realizarem o processo, havendo um ganho considerável de desempenho 
quando comparado ao uso do Pentaho, o que se encontra de acordo com a teoria 
de Kimball. 
2.5 EXTRAÇÃO - REALIZANDO A EXTRAÇÃO DE DADOS
A extração é o primeiro passo no processo de obtenção de dados em um 
ambiente de Data Warehouse. Esse processo consiste em deduzir métodos de lei-
tura e compreensão dos dados de uma origem e copiá-los para o sistema ETL 
para posterior manipulação (SANTOS et al., 2017). 
Todas as ferramentas de ETL possuem suas próprias estratégias para re-
alizar a extração de dados das fontes, para que possam ser coletados de diversas 
fontes para futuramente serem integrados.
2.6 EXTRAÇÃO COM PENTAHO DATA INTEGRATION
Na criação de um processo utilizando o PDI, dois elementos são muito 
importantes: os inputs e os outputs. Os inputs são as entradas de dados, em um 
cenário de Data Warehouse, são fontes de dados. Já os outputs são as saídas de 
dados, em um Data Warehouse, podem ser compreendidos como o banco de da-
dos multidimensional que armazenará os dados. 
Para ter uma visão geral do Pentaho Data Integration, faremos um exem-
plo simples, extrair dados de um banco de dados e salvar em um documento 
externo. Para isso, primeiramente no menu de objetos do PDI, é necessário sele-
cionar a opção Input → Table Input.
TÓPICO 2 | EXTRAÇÃO, TRANSFORMAÇÃO E CARGA
77
FIGURA 5 – INSERINDO INPUT NO PDI
FONTE: O autor
Para realizar o exemplo foi utilizado um banco de dados no PostgreSQL, 
criando uma tabela com o seguinte comando:
QUADRO 4 – TABELA DE EXEMPLO
CREATE TABLE produto
(
 nome varchar (100)
);
insert into produto (nome) values ('Mouse'), ('Teclado'), ('HD'), ('Celular'), ('Ta-
blet'), ('Monitor');
FONTE: O autor
Uma vez que o banco de dados já está criado, bem como o objeto input 
table, é possível configurar o objeto com um duplo clique em cima dele. A opção 
Wizard oferece uma configuração dinâmica, ao selecionar essa opção já aparecerá 
todas as opções de SGBDs a que o PDI tiver mecanismos de conexão. 
UNIDADE 2 | 
78
FIGURA 6 – CONECTANDO PENATHO COM BANCO DE DADOS 
FONTE: O autor 
Quando associamos com o processo de ETL, a criação de um elemento 
input está associado ao processo de extração, uma vez que está extraindo dados 
de um banco de dados. Após realizar a conexão, o objeto Table permitirá que se-
jam executados comandos SQL para realizar a extração dos dados.
FIGURA 7 – EXTRAINDO DADOS DA TABELA 
 
FONTE: O autor
TÓPICO 2 | EXTRAÇÃO, TRANSFORMAÇÃO E CARGA
79
Após realizar a extração, armazenaremos os dados em um arquivo ex-
terno. Para o armazenamento, podem ser utilizados os elementos da categoria 
Output, no exemplo é utilizado Text Input. 
FIGURA 8 – EXTRAINDO DADOS DA TABELA 
FONTE: O autor 
Nesse exemplo, realizamos o processo de extração de um conjunto de da-
dos de uma tabela (Table Input) e sua respectiva carga em um arquivo externo 
(Text File Output). Este é apenas um pequeno exemplo, mas diversos outros re-
cursos podem ser utilizados e discutiremos sobre eles no decorrer da Unidade. 
2.7 EXTRAÇÃO UTILIZANDO PYTHON
Com quase 2 bilhões de sites existentes em todo o mundo em 2020 (IN-
TERNET LIVE STATS, 2020), cada vez mais se torna interessante para as organi-
zações desenvolver aplicações que extraiam dados da Web com objetivo de ter 
um sistema de Business Intelligence apoiando as decisões de uma organização.
 
No que se refere ao emprego da Web como fonte de dados para alimentar 
ambientes de Data Warehouse há diversos tipos de aplicações: sistema de mine-
ração de notícias em tempo real, Data Warehouse para análise de dados de redes 
sociais, utilização de Data Warehouse para armazenar dados para estudos sobre 
Fake News, entre outros (SUTER et al., 2019). 
Devido à diversidade das fontes de dados utilizadas e das mais diver-
sas maneiras de coletá-los, muitas vezes as ferramentas de ETL não suportam o 
cenário, tornando-se necessário o desenvolvimento de mecanismos próprios de 
extração. Neste contexto, é comum que o desenvolvimento da etapa de extração 
seja feito por intermédio de um Web crawler.
UNIDADE 2 | 
80
A coleta automática de dados da Internet, utilizando sistemas auto-
matizados que interagem com APIs ou aplicações Web (simulando a 
ação de um usuário comum) é definida como Web Scraping (ou Web 
Crawling, quando se tratando de sistemas que interagem com diver-
sas páginas de um website). Web crawlers são utilizados, praticamen-
te, desde o início da operação da Internet, uma vez que permitem a 
coleta de dados que não são estruturados, não possuem API pública 
acessível ou, em último caso, dados que estão protegidos da publica-
ção massiva (RIBAS; NODA; MARQUES, 2018, p. 8).
Para o desenvolvimento de uma coleta baseada em sites da Web, realiza-
remos um exemplo utilizando a biblioteca news-please, que permite construir um 
mecanismo de coleta simples que extrai dados de um site ao passar seu respecti-
vo link (HAMBORG et al., 2017).
No quadro a seguir será mostrado o exemplo de como utilizar esta biblio-
teca para realizar a extração de dados de uma determinada URL e mostrar o título 
e o texto de uma notícia. Note que no exemplo realizamos a coleta de uma única 
notícia, mas utilizando o mesmo script pode se criar uma lista de URLs que serão 
visitadas e seus conteúdos extraídos para armazenamento futuro. 
QUADRO 5 – EXTRAÇÃO COM PYTHON
from newsplease import NewsPlease
coleta_site = NewsPlease.from_url('https://www.washingtonpost.com/po-
litics/trump-legal-team-advances-blanket-defense-against-impeachmen-
t/2020/01/29/3b27f0b2-42b2-11ea-b5fc-eefa848cde99_story.html')
print("Titulo")
print(coleta_site.title)
print("Texto Completo")
print(coleta_site.maintext)
FONTE: O autor
81
RESUMO DO TÓPICO 2
Neste tópico, você aprendeu que:
● A ETL (Extract, Transform and Load) faz parte da arquitetura de um Data Wa-
rehouse.
● O processo de ETL é composto por Extração, Transformação e Carga de dados.
● A extração é responsável por coletar dados das fontes.
● A transformação é responsável por adequar os dados ao modelo que será utili-
zado para armazenar os dados.
● O processo de ETL pode ser feito por diversas ferramentas.
82
AUTOATIVIDADE
1 O Data Warehouse é independente de qualquer tecnologia e pode ser desen-
volvido e utilizado em plataformas informáticas que variam desde sistemas 
de bases de dados a sistemas proprietários especialmente concebidos para a 
gestão de armazéns de dados. Dentre as etapas de um Data Warehouse, existe 
uma etapa em que há o maior esforço computacional, no qual é gasto até 80% 
do tempo. 
FONTE: CALDEIRA, C. Data Warehousing: conceitos e modelos. Lisboa: Edições Sílabo, 2012.
Sobre essa etapa, assinale a alternativa CORRETA:
a) Fonte dos Dados.
b) Modelo Multidimensional.
c) Extração, Transformação e Carga.
d) Operações OLAP.
2 A etapa de ETL é uma das mais críticas de um projeto de Data Warehouse, 
pois uma informação carregada erroneamente trará consequências imprevisí-
veis nas fases posteriores. O objetivo desta fase é fazer a integração de infor-
mações de fontes múltiplas e complexas.
FONTE: FERREIRA, R. M. Solução de ETL desenvolvida para o cliente CETIC.br – Centro de 
Estudos sobre as Tecnologias da Informação e da Comunicação. Tese de Doutorado. Rio de 
Janeiro: Universidade Federal do Rio de Janeiro, 2014. 
Sobre a maneira de criar a ETL, assinale a alternativa CORRETA :
a) Utilizando Pentaho Data Integration.
b) Utilizando serviços de Nuvem.
c) Utilizando linguagens de programação.
d) Todas as alternativas estão corretas.
3 A ETL é um componente crítico no sucesso da implementação de qualquer 
Data Warehouse. O desenho e a implementação deste componente envolvem 
o desenvolvimento de processos complexos, que interagem com a maioria 
dos restantes componentes do Data Warehouse. Muitas vezes a etapa de ETL 
precisa estar acoplada a frameworks de Big Data streaming. Assinale a alter-
nativaCORRETA que apresenta o nome de frameworks para Big Data:
a) Apache hadoop e Apache Spark.
b) Apache hadoop e Apache PostgreSQL.
c) Apache Hive e Apache Spark.
d) Nenhuma das alternativas.
83
4 O AWS Glue é um serviço de extração, transformação e carga (ETL) gerencia-
do que facilita a preparação e a carga de dados para análises pelos clientes. O 
Glue faz parte do suite de softwares disponibilizados pela Amazon para execu-
tar Business Intelligence. Sobre o AWS Glue, assinale a alternativa CORRETA:
a) É um framework de Big Data. 
b) É uma ferramenta de ETL na nuvem. 
c) É uma ferramenta de ETL executada localmente.
d) Todas as alternativas estão corretas.
5 Pentaho Data Integration é uma das ferramentas do Suite Pentaho, ferra-
menta desenvolvida para realizar os processos de Extração, Transformação e 
Carga de maneira visual. Analise a transformação a seguir: há um elemento 
Table input tb_produto_pg que contém uma consulta SQL que obtém dados 
de duas tabelas e as envia para o elemento Table Output tb_produto_mysql. 
FIGURA 9 – ELEMENTO
FONTE: O autor
Assinale a alternativa CORRETA que associa a imagem com o processo de ETL:
a) No elemento tb_produto_mysql é feita a extração.
b) No elemento tb_produto_mysql é feita a carga.
c) No elemento tb_produto_pg é feita a transformação.
d) No elemento tb_produto_pg é feita a carga.
84
85
TÓPICO 3
TRANSFORMAÇÕES NA PRÁTICA
UNIDADE 2
1 INTRODUÇÃO
No decorrer desta unidade, você aprofundou seus conhecimentos sobre o 
desenvolvimento de Business Intelligence por intermédio da arquitetura de um 
Data Warehouse. Pode-se compreender que a etapa de ETL é a que demanda 
mais esforço computacional em um processo de Data Warehouse.
Neste processo, a Extração e a Carga têm um importante papel, pois são 
responsáveis por sincronizar as fontes de dados com os dados de origem (Modelo 
Multidimensional / Data Warehouse).
No entanto, no intermédio está a Transformação, que tem as principais 
missões durante o processo de ETL, como:
● Limpeza.
● Padronização.
● Normalização.
● Integração.
A transformação dos dados é responsável por realizar a limpeza de da-
dos, detectando erros e os corrigindo quando possível. A transformação de dados 
converte dados do formato herdado ou do host para o formato do Data Warehou-
se. A limpeza e a transformação de dados são etapas importantes para melhorar a 
qualidade dos dados e, posteriormente, os resultados das aplicações que venham 
a consumir estes dados (HAN; PEI; KAMBER, 2011).
O processo de transformação compõe uma importante etapa dentro da 
ETL, vale lembrar que quando se desenvolve um ambiente de Data Warehouse es-
tamos falando de OLAP, no qual o principal objetivo é fornecer consultas eficientes. 
Deste modo, o banco de dados multidimensional não é construído com ênfase na 
integridade dos dados, ou seja, a etapa de ETL, e principalmente a transformação, 
será responsável por garantir a qualidade dos dados armazenados. 
Para compreender melhor o processo de transformação de dados em am-
bientes de Data Warehouse, a seguir, realizaremos exemplos práticos utilizando 
tecnologias já mencionadas. 
86
UNIDADE 2 | 
2 TRANSFORMAÇÃO POR AGRUPAMENTO
 
O Data Warehouse é um repositório de dados provenientes dos dados 
operacionais (dos Sistemas OLTP), em que se cria um ambiente homogêneo e pa-
dronizado, com finalidade de propiciar análises de negócio concentradas em um 
só local. Com isso, desenvolve-se um ambiente de observação de desempenho, de 
comparação e análise de dados on-line a fim de extrair informações relevantes ao 
negócio (ambientes OLAP) (MONTEIRO et al., 2004). De modo geral, em um Data 
Warehouse os dados operacionais brutos são transformados em um formato de 
Warehouse prontos para serem consultados e utilizados pelo usuário. 
Quando estudamos a comparação entre sistemas OLTP (transacionais) e 
OLAP (analíticos), você pôde compreender que dentre as mais diversas caracte-
rísticas que se opõem a estas tecnologias, a principal diferença entre ambos está 
no modelo construído para armazenar os dados. 
Neste contexto, o desafio é obter os dados que estão armazenados em 
sistemas OLTP, em duas ou mais tabelas, e, posteriormente, armazená-los em 
sistemas OLAP que contêm um número menor de tabelas.
Para exemplificar, consideraremos o cenário de um sistema de controle de 
vendas e gestão de estoque de produtos. A seguir é mostrado o modelo relacional 
desenvolvido com ênfase na integridade dos dados de um sistema transacional. 
FIGURA 10 – MODELO RELACIONAL - OLTP
FONTE: O autor 
Com o objetivo de representar os mesmos dados do sistema de vendas, no 
entanto, que serão armazenados em um Data Warehouse e com ênfase em análi-
ses (OLAP), foi desenvolvido o modelo a seguir.
TÓPICO 3 | TRANSFORMAÇÕES NA PRÁTICA
87
FIGURA 11 – MODELO MULTIDIMENSIONAL - OLAP
FONTE: O autor 
Existem diversas análises que podem ser feitas tendo os dois modelos em 
mãos, no entanto, focaremos no processo de transformação dos dados do modelo 
relacional para o modelo multidimensional. 
Durante o estudo sobre ETL, você pôde observar diversas ferramentas, 
cada uma com sua particularidade. No entanto, há um item em comum sobre este 
tipo de transformação para que seja realizada com êxito, trata-se do domínio da 
linguagem SQL. Ainda que existam ferramentas que deem suporte visual à etapa 
de ETL, o conhecimento de SQL será necessário para compreender os modelos e 
poder promover as extrações e transformações necessárias. 
Para compreender esse processo, consideraremos um trecho dos mode-
los e realizaremos uma transformação utilizando Pentaho Data Integration. Para 
isso, consideraremos o produto e sua quantidade em estoque, que no modelo re-
lacional é armazenado em duas tabelas, já no multidimensional em apenas uma.
FIGURA 12 – TRANSFORMAÇÃO DOS MODELOS
FONTE: O autor
Para a realização do exemplo foram utilizados dois bancos de dados no 
PostgreSQL, mas que pode ser realizado em qualquer banco de dados relacional 
88
UNIDADE 2 | 
que esteja conectado ao Pentaho Data Integration. Para criação e população do 
trecho do banco de dados relacional é utilizado o código a seguir.
QUADRO 6 – CÓDIGO SQL OLTP PRODUTO
--Criação das Tabelas
CREATE TABLE produto (
 id_produto INTEGER PRIMARY KEY NOT NULL,
 nome VARCHAR NOT NULL,
 preco NUMERIC NOT NULL
);
CREATE TABLE item_estoque (
 id_estoque INTEGER PRIMARY KEY NOT NULL,
 id_produto INTEGER NOT NULL,
 FOREIGN KEY (id_produto) REFERENCES produto (id_produto)
);
--População da Tabelas
insert into produto(id_produto, nome, preco) values (1, 'Mouse',15.30);
insert into produto(id_produto, nome, preco) values (2, 'Teclado',19.90);
insert into item_estoque(id_estoque, id_produto) values (1,1);
insert into item_estoque(id_estoque, id_produto) values (2,1);
insert into item_estoque(id_estoque, id_produto) values (3,1);
insert into item_estoque(id_estoque, id_produto) values (4,1);
insert into item_estoque(id_estoque, id_produto) values (5,1);
insert into item_estoque(id_estoque, id_produto) values (6,1);
insert into item_estoque(id_estoque, id_produto) values (7,2);
insert into item_estoque(id_estoque, id_produto) values (8,2);
insert into item_estoque(id_estoque, id_produto) values (9,2);
insert into item_estoque(id_estoque, id_produto) values (10,2);
FONTE: O autor
Uma vez criado o banco de dados de origem, para criar o trecho que re-
presenta a tabela dimensao_produto, indicada no modelo anterior, deve-se utili-
zar o seguinte comando SQL:
QUADRO 7 – CÓDIGO SQL OLTP PRODUTO
--Criação das Tabelas
create table dm_produto
(
 id_produto integer,
 nome varchar(100),
 preco numeric,
 estoque integer
)
FONTE: O autor
TÓPICO 3 | TRANSFORMAÇÕES NA PRÁTICA
89
Agora que já temos os bancos de dados e as tabelas feitas, iremos para o 
Pentaho Data Integration criar uma nova transformação, que deverá ser compos-
ta por um elemento para extrair os dados do banco de dados relacional (Table 
Input) e um elemento para carregar os dados natabela dimensao_produto (Table 
Output).
FIGURA 13 – TRANSFORMAÇÃO RELACIONAL X MULTIDIMENSIONAL COM PDI
 
FONTE: O autor
Ao criar o modelo relacional (OLTP), este representa o estoque dos pro-
dutos por duas tabelas: produto e item_estoque. Sendo assim, o desafio é coletar 
e transformar dados destas duas tabelas em uma, a dimensao_produto. 
Neste caso, para a realização da transformação, devemos analisar os cam-
pos dos dados coletados e de onde serão carregados. Para isso, faremos duas 
perguntas:
Existem campos no modelo dimensional que não existe no modelo re-
lacional? 
R.: Sim, existe o campo quantidade_estoque.
É possível obter os campos faltantes a partir de consultas SQL? 
R.: Sim, é possível realizar uma junção e agrupamento das tabelas pro-
duto e item_estoque, trazendo as informações necessárias para popular a tabela 
dimensao_produto. 
Deste modo, é possível realizar a transformação através de comandos 
SQL, ao clicar duas vezes no objeto da extração, basta entrar com o comando 
necessário para realizar a junção e o agrupamento. A figura a seguir mostra o 
exemplo da SQL já inserida no elemento que faz a extração dos dados. Perceba 
90
UNIDADE 2 | 
que todos os campos já existem na junção, mas um novo campo é criado com o 
nome de qt_estoque, este campo será responsável por realizar a soma de todos os 
itens de um produto que há no estoque.
FIGURA 14 – EXTRAÇÃO E TRANSFORMAÇÃO COM SQL 
FONTE: O autor
Agora que os dados coletados do ambiente transacional já estão prepara-
dos, é necessário adequar os dados da fonte com os dados. Para isso, no Pentaho 
Data Integration, basta dar um duplo clique no objeto Table Output. 
A próxima figura mostra as configurações da tabela em que será realizada 
a carga, no caso dimensao_produto. Durante este tipo de transformação, no qual 
se deseja equiparar os campos extraídos com os campos de onde será realizada a 
carga, o passo mais importante está na aba Database Fields. Note que ao criar a 
SQL garantimos o mesmo número de campos, deste modo, como todos os cam-
pos têm o mesmo nome, salvo o estoque, basta equiparar qt_estoque da consulta 
SQL realizada com o campo estoque da tabela dm_produto. 
TÓPICO 3 | TRANSFORMAÇÕES NA PRÁTICA
91
FIGURA 15 – EXTRAÇÃO, TRANSFORMAÇÃO E CARGA COM SQL 
 
FONTE: O autor
Para executar a transformação que foi criada, basta clicar no botão “play” 
o qual permitirá que todo processo seja realizado, contendo os dados do banco de 
dados transacional (OLTP) e armazenando no OLAP. 
Uma vez realizado esse procedimento, você poderá consultar ambos os 
bancos de dados, obtendo os mesmos dados, armazenados em diferentes modelos. 
A Figura 16 mostra as consultas realizadas para recuperar os mesmos dados, no 
banco de dados de origem e no banco de dados que foi realizado a carga dos dados.
FIGURA 16 – DADOS NA FONTE E NO MODELO MULTIDIMENSIONAL 
FONTE: O autor
92
UNIDADE 2 | 
2.1 TRANSFORMAÇÕES NUMÉRICAS, TEXTUAIS E 
CONVERSÕES
Quando estudamos a visão geral sobre o processo de ETL, aprendemos 
que a transformação é responsável, dentre outras tarefas, por integrar e transfor-
mar os dados para um determinado padrão. 
A integração pode acontecer em diversos momentos, em diversos cenários 
de dados, mas de modo geral é responsável por extrair dados de diversas fontes 
de dados, integrá-los e prepará-los para serem carregados no Data Warehouse.
Um exemplo clássico abordado pela literatura é o exemplo do campo sexo. 
As fontes de dados podem representar o campo sexo de diversas maneiras, sendo 
necessário um mecanismo para integrar todas essas fontes, unindo-as em um único 
padrão, o do modelo multidimensional (Data Warehouse) (CAMPOS, 2013). 
FIGURA 17 – INTEGRAÇÃO COM O CAMPO SEXO 
FONTE: Adaptada de Campos (2013)
Para compreender o processo da integração, realizaremos o processo utili-
zando duas fontes de dados distintas, para permitir que este processo seja repro-
dutível para quantas fontes de dados sejam necessárias. 
Primeiramente, devem ser criados dois bancos de dados: um banco de 
dados transacional de origem (OLTP) e um banco de dados multidimensional 
(OLAP). O quadro a seguir mostra a estrutura de criação das tabelas utilizadas 
que devem ser executadas e populadas.
TÓPICO 3 | TRANSFORMAÇÕES NA PRÁTICA
93
QUADRO 8 – SQL PARA PREPARAR O AMBIENTE PARA REALIZAR A INTEGRAÇÃO
-- Fonte de Dados OLTP 1
create table fornecedor
(
 id_fornecedor integer primary key,
 data_cadastro varchar(20),
 nome varchar(100),
 sexo varchar(1)
)
insert into fornecedor values (1,'25/01/2019' ,'Luiz Henrique','M');
insert into fornecedor values (2,'25/01/2019' ,'Maria Fernanda','F');
-- Fonte de Dados OLTP 2
create table fornecedor2
(
 id_fornecedor integer primary key,
 data_cadastro varchar(20),
 nome varchar(100),
 sexo varchar(10)
)
insert into fornecedor values (1,'25/01/2019' ,'Luiz Felipe','Masculino');
insert into fornecedor values (2,'25/01/2019' ,'Mikaela Varela','Feminino');
-- Fonte de Dados OLAP
create table dimensao_fornecedor
(
 id_fornecedor serial primary key,
 data_cadastro date ,
 nome varchar(50),
 sexo smallint
)
FONTE: O autor
O primeiro passo dentro do Pentaho Data Integration é criar os objetos 
necessários para realizar a extração dos dados, nesse caso, para cada fonte de da-
dos utilizaremos um Table Input. Para a tabela em que os dados serão carregados, 
será utilizado um Table Output. 
94
UNIDADE 2 | 
FIGURA 18 – INTEGRAÇÃO COM PDI 
FONTE: O autor
Note que as tabelas possuem uma estrutura diferente, e ao repetir o pro-
cedimento conforme o exemplo anterior, aconteceu um erro. Este erro acontece 
porque as tabelas da fonte de dados são diferentes das tabelas onde os dados 
serão carregados.
Para contornar esse problema, utilizaremos alguns objetos de transfor-
mação do Pentaho. Na aba Design → Transform → Value Mapper, é possível 
inserir um elemento que realiza o mapeamento de elementos de acordo com o 
valor esperado no banco de dados de origem, ou seja, realiza uma padronização. 
FIGURA 19 – VALUE MAPPER
FONTE: O autor
TÓPICO 3 | TRANSFORMAÇÕES NA PRÁTICA
95
Com um duplo clique no Value Mapper, é possível realizar a configu-
ração, selecionando o campo, o valor atual e o valor pelo qual será substituído. 
Como no banco de dados em que os dados serão armazenados (OLAP) o campo 
sexo recebe valores 0 ou 1, será utilizado esse padrão na substituição. A Figura 20 
mostra a configuração para as duas tabelas criadas anteriormente, em que Source 
Value se refere aos valores armazenados nas fontes de dados e Target Value ao ban-
co de dados multidimensional. 
FIGURA 20 – CONFIGURAÇÃO DO VALUE MAPPER
FONTE: O autor
No que se refere ao campo sexo, a questão foi resolvida. No entanto, ainda 
é necessário definir o tipo de dados deste campo, bem como realizar a padroni-
zação do campo data_cadastro. Para isso, na aba Design → Transform → Select 
Values é possível inserir um elemento que fará este tipo de padronização. 
FIGURA 21 – SELECT VALUES
FONTE: O autor
Note que o elemento Select Values faz a integração entre os dados de am-
bas as fontes de dados. Para que isso seja possível utilizando um único elemento, é 
necessário que as fontes tenham o mesmo número de campos, bem como campos 
com mesmo nome. Com um duplo clique, a configuração do elemento será aberta.
96
UNIDADE 2 | 
FIGURA 22 – CONFIGURAÇÃO DO SELECT VALUES 
FONTE: O autor
Podemos reparar na configuração do Select Values todos os campos de 
acordo com a tabela dimensao_fornecedores, onde os dados, já integrados, serão 
armazenados. Note que não existe o campo id_fornecedor, isso acontece, pois 
em cada fonte provedora existe um valor para id_fornecedor, se realizarmos a 
extração, poderá ocasionar em dados repetidos. Por isso, durante a criação da 
dimensao_fornecedor foi utilizado o tipo de dados serial, que criará um código 
id_fornecedor sequencial.
Uma vez realizada a configuração, o Pentaho Data Integration está pronto para 
executar o processo de ETL.Para isso, basta apertar “play” ou o atalho (Tecla F9).
FIGURA 23 – FINALIZANDO O PROCESSO DE ETL 
 
FONTE: O autor
2.2 TRANSFORMAÇÃO UTILIZANDO MACHINE LEARNING 
PARA ENRIQUECIMENTO SEMÂNTICO
 
As aplicações de machine learning têm a necessidade de obtenção de da-
dos de qualidade, quando isto não acontece é gasto grande parte do tempo rea-
lizando o pré-processamento desses dados. Esse tempo pode ser economizado 
caso a fonte de dados seja proveniente de um ambiente de Data Warehouse.
Em contrapartida, os algoritmos de machine learning podem ser acopla-
dos na etapa de ETL com a finalidade de agregar conhecimento e enriquecer os 
dados armazenados em um ambiente de Data Warehouse. As técnicas de desco-
berta de conhecimento têm sido empregadas para enriquecer semanticamente os 
TÓPICO 3 | TRANSFORMAÇÕES NA PRÁTICA
97
dados e metadados em ambientes de Data Warehouse durante o processo ETL 
(NOGUEIRA, 2017).
De modo geral, o enriquecimento semântico por intermédio de algorit-
mos de machine learning acontece com a aplicação destas técnicas para trazer 
significado aos dados coletados. A aplicação destas técnicas pode ir além, como 
auxiliar no preenchimento de valores vazios, outliers, valores inválidos, gerando 
enriquecimento semântico por meio de algoritmos de machine learning.
No exemplo da coleta de notícias que realizamos com o biblioteca news-ple-
ase, o enriquecimento semântico pode acontecer, por exemplo, com a aplicação de 
um algoritmo para categorizar uma notícia (política, artes, futebol etc.). Isso porque 
alguns sites exibem em algum momento a categoria da notícia, seja pela própria 
URL ou no corpo da notícia. No entanto, existem sites que não contêm essas cate-
gorias, tornando-se necessário utilizar o enriquecimento semântico para descobrir. 
 
Para exemplificar, utilizaremos uma base de dados já populada denomi-
nada 20NewsGroup e dividi-la em duas partes, uma com categoria e outra sem 
categoria. No exemplo do enriquecimento semântico, é quando utilizamos os da-
dos categorizados para descobrir os que não contêm categoria. O algoritmo utili-
zado é o Naive Bayes com a biblioteca scikit-learn para aplicar Machine Learning.
QUADRO 9 – ENRIQUECIMENTO SEMÂNTICO
from sklearn.datasets import fetch_20newsgroups
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.naive_bayes import MultinomialNB
print("Todas as Categorias")
#print(newsgroups_train.target_names)
noticas_categorizada = fetch_20newsgroups(subset='train')
vectorizer = TfidfVectorizer()
vectors = vectorizer.fit_transform(newsgroups_train.data)
noticas_sem_categoria = fetch_20newsgroups(subset='test',categories=catego-
ries)
bag_of_words = vectorizer.transform(noticas_sem_categoria.data)
clf = MultinomialNB(alpha=.01)
clf.fit(vectors, newsgroups_train.target)
pred = clf.predict(bag_of_words)
i=0
for id_categoria in pred:
 print("Noticia:", noticas_sem_categoria.data[i])
 print("Categoria recebida pelo Enriquecimento Semântico:", newsgroups_
train.target_names[id_categoria])
 i= i+1
FONTE: O autor
98
UNIDADE 2 | 
Para compreender melhor o conceito de enriquecimento semântico é inte-
ressante que você possa ler alguns trabalhos que aplicam este conceito em seu desenvol-
vimento. Por isso, deixamos algumas sugestões de leitura. 
MONTEIRO, R.; NOGUEIRA, R. R.; MOSER, G. Desenvolvimento de um sistema para a 
classificação de fake news acoplado à etapa de etl de um data warehouse de textos de 
notícias em língua portuguesa. 2019. Disponível em: https://www.researchgate.net/pu-
blication/334747124_Desenvolvimento_de_um_sistema_para_a_classificacao_de_Fake-
news_com_Textos_de_Noticias_em_lingua_Portuguesa. Acesso em: 12 fev. 2020.
MOREIRA, J. L; CORDEIRO, K. F; CAMPOS, M. L. M. JointOLAP - sistema de informação 
para exploração conjunta de dados estruturados e textuais: um estudo de caso no setor 
elétrico. 2013. Disponível em:
https://www.researchgate.net/publication/278243345_JointOLAP_-_Sistema_de_Infor-
macao_para_Exploracao_Conjunta_de_Dados_Estruturados_e_Textuais_Um_estudo_
de_caso_no_setor_eletrico. Acesso em: 12 fev. 2020.
SILVA, M. C. B.; GONZÁLEZ, S. M. SelfBI: tomada de decisão sob demanda do usuário utili-
zando dados da Web. 2016. Disponível em: https://pdfs.semanticscholar.org/a61d/121d0e-
777d0dd3ca74d0ebd3187189301334.pdf. Acesso em: 12 fev. 2020.
DICAS
https://www.researchgate.net/publication/334747124_Desenvolvimento_de_um_sistema_para_a_classificacao_de_Fakenews_com_Textos_de_Noticias_em_lingua_Portuguesa
https://www.researchgate.net/publication/334747124_Desenvolvimento_de_um_sistema_para_a_classificacao_de_Fakenews_com_Textos_de_Noticias_em_lingua_Portuguesa
https://www.researchgate.net/publication/334747124_Desenvolvimento_de_um_sistema_para_a_classificacao_de_Fakenews_com_Textos_de_Noticias_em_lingua_Portuguesa
https://www.researchgate.net/publication/278243345_JointOLAP_-_Sistema_de_Informacao_para_Exploracao_Conjunta_de_Dados_Estruturados_e_Textuais_Um_estudo_de_caso_no_setor_eletrico
https://www.researchgate.net/publication/278243345_JointOLAP_-_Sistema_de_Informacao_para_Exploracao_Conjunta_de_Dados_Estruturados_e_Textuais_Um_estudo_de_caso_no_setor_eletrico
https://www.researchgate.net/publication/278243345_JointOLAP_-_Sistema_de_Informacao_para_Exploracao_Conjunta_de_Dados_Estruturados_e_Textuais_Um_estudo_de_caso_no_setor_eletrico
https://pdfs.semanticscholar.org/a61d/121d0e777d0dd3ca74d0ebd3187189301334.pdf
https://pdfs.semanticscholar.org/a61d/121d0e777d0dd3ca74d0ebd3187189301334.pdf
TÓPICO 3 | TRANSFORMAÇÕES NA PRÁTICA
99
Detecção de Casos de Violência Patrimonial a partir do Twitter
Inicialmente, as redes sociais na Web eram vistas apenas como ambientes 
que permitiam a seus membros se comunicarem com amigos e familiares a partir 
das conexões mantidas entre os usuários. Com o decorrer do tempo, tais platafor-
mas transformaram-se em um profícuo mecanismo de comunicação por meio do 
qual usuários são capazes de expressar sentimentos e manifestar suas opiniões. 
O Twitter é uma das redes sociais mais utilizadas no mundo atualmente. 
O Brasil ocupa a segunda posição entre os países com mais usuários no Twitter 
(NISHA, 2016). Em janeiro de 2016, o Twitter possuía cerca de 320 milhões de 
usuários ativos que geravam aproximadamente 1 bilhão de mensagens diaria-
mente [TWITTER 2016]. Naturalmente, essa rede social representa uma impor-
tante fonte para a troca de opiniões. Nos últimos anos, a segurança pública tem 
se tornado um dos maiores desafios da sociedade brasileira. 
De fato, os dados são alarmantes e evidenciam uma escalada da violên-
cia que atinge principalmente os grandes centros urbanos. De acordo com uma 
pesquisa realizada em São Paulo [CPP/INSPER, 2013], no período entre 2003 e 
2013, registrou-se um aumento de 37% nos casos de furto, quando considerados 
os dados oficiais do governo estadual. Todavia, o mesmo estudo conclui que o 
aumento real foi de 81,5%. Tal diferença pode ser explicada pelo fato de que mui-
tas vítimas não registram ocorrência desses crimes. Em se tratando de casos de 
roubo, apenas 35,3% das pessoas entrevistadas fizeram o registro, sendo o “medo 
de represália” (30%) e a “descrença que faria alguma diferença” (18,9%) os prin-
cipais motivos alegados por quem não registrou o boletim de ocorrência. 
Assim, faz-se necessário buscar alternativas que permitam melhorar as 
estatísticas utilizadas pelos gestores e, preferencialmente, que reflitam uma visão 
mais recente dos acontecimentos e mais condizente com a realidade. Uma fonte 
viável para a obtenção desses dados são as redes sociais. De fato, devido à ocor-
rência cotidiana de assaltos, roubos e furtos nas principais cidades brasileiras, é 
natural que os seus cidadãos se utilizem das redes sociais para manifestar indig-
nação e alertar amigos mediante o relato dos crimes aos quais foram submetidos. 
Este trabalho apresenta o sistema DETECT (Detecção de Eventos Criminais a par-
tir do Twitter), que analisa dados da rede social Twitter com o objetivode detectar 
mensagens (tweets) que relatem a ocorrência de crimes de violência patrimonial. 
Além de auxiliar aos gestores, tais dados podem servir também para ajudar na 
orientação dos cidadãos em áreas que não estão familiarizados, possivelmente, 
alimentando sistemas de navegação a fim de alertar os usuários sobre trechos 
com maior incidência de crimes. 
LEITURA COMPLEMENTAR
100
UNIDADE 2 | 
Trabalhos relacionados 
O problema de extrair e analisar tweets relacionados à violência pode ser 
visto como um problema de categorização ou classificação de tópicos, ou seja, 
decidir se um tweet será classificado como violento ou não violento. Nesta se-
ção, são discutidos os principais trabalhos encontrados na literatura que analisam 
dados do Twitter no contexto da violência. Basave et al. (2013) apresentam um 
trabalho de detecção de tweets sobre violência através de um modelo de detecção 
de violência (VDM – Violence Detection Model). 
Este modelo propõe uma classificação da violência em nível de documen-
to para domínios gerais em conjunção com detecção de tópicos e análise de tópi-
cos relacionados à violência. O trabalho apresenta um modelo interessante para 
identificação de tweets violentos, contudo, não possui abordagem para a defini-
ção e tratamento da localização onde o tweet foi submetido. Li et al. (2012) intro-
duzem um sistema de análise e detecção de eventos relativos à criminalidade e a 
desastres naturais baseados no Twitter, denominado TEDAS. 
O sistema permite detectar novos eventos, analisar padrões temporais e 
espaciais e identificar a importância dos eventos através do uso de mapas de calor 
gerados a partir de dados de geolocalização de tweets. TEDAS utiliza uma amos-
tra menor de tweets para a análise com enfoque principal voltado para a detecção 
de desastres naturais. ReDites constitui um sistema de detecção, rastreamento 
e monitoramento em tempo real de eventos em redes sociais (OSBORNE et al., 
2014). No experimento realizado neste trabalho, foi avaliada a possível detecção 
do ataque terrorista ao shopping Westgate, que ocorreu em setembro de 2013 
no Quênia, utilizando apenas tweets obtidos através da Streaming API. ReDites 
propõe a análise de tweets geolocalizados em tempo real, identificando as locali-
dades das ocorrências de imediato. Similarmente aos trabalhos relacionados, DE-
TECT extrai e analisa os tweets em busca de padrões. Um dos diferenciais desta 
proposta é a possibilidade de integração dos dados encontrados com dados go-
vernamentais relacionados à segurança pública, possibilitando a sua validação.
Esta seção descreve as etapas seguidas neste trabalho para o processa-
mento dos dados da plataforma Twitter: extração dos tweets, análise dos dados 
e visualização. A Figura a seguir apresenta uma visão geral do sistema, cuja exe-
cução é dividida em quatro passos: extração, análise, identificação de localização 
e resultados. O Passo 1 representa a fase de extração, que dispõe do módulo de 
extração, responsável por obter os tweets através da Streaming API e gerar arqui-
vos de saída para serem utilizados pelo módulo de seleção executado no Passo 
2. O módulo de seleção recuperará os tweets que contêm termos sobre violência 
patrimonial. Durante a fase de análise, a cada tweet é atribuído um índice de 
relevância a fim de detectar aqueles que de fato relatam um crime de violência 
patrimonial. Em seguida, no Passo 3, DETECT tentará identificar o local da ocor-
rência do crime através de seu próprio conteúdo ou de tags de geolocalização a 
partir do módulo de localização do tweet. Finalmente, no Passo 4, os resultados 
são visualizados e armazenados pelo módulo de visualização e armazenamento.
TÓPICO 3 | TRANSFORMAÇÕES NA PRÁTICA
101
Extração de tweets
Para o módulo de extração de tweets, foi escolhido o mecanismo de extra-
ção Streaming API, que permite a extração em modo stream, ou seja, no momento 
da geração dos tweets. O módulo de extração implementado em DETECT foi 
desenvolvido em Python. 
A abrangência da extração são os tweets gerados em tempo real e escritos 
em língua portuguesa, sem nenhuma filtragem de termos específica. Além da 
funcionalidade básica de extração, o módulo exclui os retweets (replicação de 
tweets) no momento da extração para evitar repetições.
Análise
O processo de escolha para as palavras-chave utilizado na seleção de twe-
ets teve origem a partir de uma pesquisa acerca de termos comuns presentes em 
relatos de crimes de violência patrimonial. As derivações destas palavras também 
foram utilizadas como palavras-chave. 
A base de termos que serviu como referência para a seleção neste trabalho 
foi construída levando em conta dados de boletins de ocorrência e comentários 
postados na Web a partir do site “Onde fui roubado” . 
Dentre as palavras utilizadas na seleção de tweets incluem-se roubo, as-
salto, furto, arrombamento, mão armada e arrastão. Para implementar o módulo 
de seleção de tweets, foi utilizado o Pentaho Data Integration (Kettle), que dis-
ponibiliza um ambiente ETL2. A transformação de seleção feita pelo Kettle é re-
presentada pela figura a seguir, onde os tweets são filtrados de acordo com as 
palavras-chave e enviados para o módulo de análise de relevância.
102
UNIDADE 2 | 
Após os tweets terem sido selecionados de acordo com as palavras-chave, 
um dicionário com índices de relevância foi criado a partir de uma solução de-
senvolvida em Python, utilizando a biblioteca de análise léxica NLTK3. A criação 
do dicionário teve como base alguns tweets selecionados para estudo. Para cada 
tweet, as stopwords (artigos, pronomes etc.) são removidas e às palavras restan-
tes são atribuídas relevâncias de acordo com a sua frequência. 
Para aquelas que possuem relação com o tema, atribui-se uma relevância 
positiva. Às palavras mais frequentes que não possuem relação com o tema e que 
remetem um novo sentido ao tweet, designa-se uma relevância negativa. Por fim, 
para palavras que não dizem respeito ao contexto da violência patrimonial e não 
interferem no sentido da mensagem define-se uma relevância neutra.
Considerando, por exemplo, o tweet “Ontem à noite uma mulher foi as-
saltada no ponto de ônibus do meu lado”, a análise o destacaria como resultado 
devido à ocorrência de palavras com alta relevância (“ponto de ônibus”). Por 
outro lado, o tweet “Está na hora de assaltar a geladeira” não seria retornado pelo 
DETECT devido ao termo “geladeira” estar muitas vezes associado à expressão 
popular assaltar a geladeira e, consequentemente, possuir baixa relevância. Sen-
do assim, através de uma transformação no Kettle, é atribuída a relevância de 
cada tweet a partir do dicionário. A relevância total de um tweet é calculada a 
partir da soma das relevâncias de cada palavra. Caso o resultado seja positivo, o 
tweet é considerado relevante.
Localização de Tweets 
Os tweets sem informações de geolocalização correspondem a maior par-
te de tweets gerados (GONZALEZ et al., 2012). Para identificar a origem dessas 
mensagens, foi implementada uma abordagem que se baseia em: (i) verificar se 
algum logradouro foi incluído no conteúdo do tweet; e (ii) identificar a locali-
zação do usuário que gerou o tweet através da obtenção de dados do perfil de 
usuário. Em (i), os tweets passam por uma análise léxica a partir de um conjunto 
de palavras-chave (ex.: rua, avenida, estrada etc.). Mediante a obtenção do logra-
douro e da cidade do usuário, tal informação é analisada pelo Google Maps API 
para atribuir a geocodificação correspondente. Finalmente, os dados de latitude e 
longitude retornados pela Google Maps API são enviados para o módulo de visu-
alização, que gera um mapa de calor relacionado com as áreas de maior incidên-
cia de tweets retornados pelo DETECT. Os mapas de calor foram implementados 
a partir de um script Python que utiliza a Google Maps API. Os resultados são 
gerados em um arquivo .html que inclui a exibição do mapa.
TÓPICO 3 | TRANSFORMAÇÕES NA PRÁTICA
103
Prova de conceitoA fim de avaliar as funcionalidades do DETECT, foi realizada uma extra-
ção de tweets entre os meses de setembro de 2015 e janeiro de 2016. Destes tweets, 
210.881.326 não possuíam informações de geolocalização e 1.679.008 possuíam 
informações de geolocalização. O total de tweets extraídos no período menciona-
do foi de 212.560.334. 
O sistema DETECT foi executado a partir de um ambiente construído 
sobre a plataforma de nuvem Microsoft Azure. Tal fato garantiu a estabilidade 
necessária durante a fase de coleta dos tweets. Para o protótipo utilizado neste 
experimento, foram implementados os seguintes módulos: módulo de extração, 
módulo de seleção, criação de dicionário e módulo de análise de relevância para 
tweets geolocalizado.
O sistema detectou 569 tweets geolocalizados com relevância ao tema de 
violência patrimonial de acordo com o dicionário gerado. Dentre aqueles mais 
relevantes, a maioria foi gerada na cidade do Rio de Janeiro. Um mapa de calor 
com as principais áreas de geração destas mensagens no Rio de Janeiro é apre-
sentado na figura.
FONTE: CLARINDO, J. P.; COUTINHO, F.; FREITAS, A. L. Detecção de casos de violência 
patrimonial a partir do Twitter. 2019. Disponível em: http://www.each.usp.br/digiampietri/
BraSNAM/2016/p17.pdf. Acesso em: 12 fev. 2020.
104
RESUMO DO TÓPICO 3
Neste tópico, você aprendeu que:
● A transformação é responsável pela limpeza, integração e consolidação dos 
dados coletados.
● A transformação pode ser feita utilizando qualquer ferramenta de ETL.
● Utilizando Pentaho Data Integration é possível realizar diversos tipos de trans-
formações.
● Utilizando ferramentas de ETL, pode-se criar transformações numéricas, tex-
tuais e conversões.
● É possível utilizar linguagem Python para coletar dados e realizar enriqueci-
mento semântico utilizando Machine Learning.
105
1 Um Data Warehouse é composto por diversos itens, mas para que sua im-
plementação aconteça com eficiência, é necessário que seja desenvolvido um 
modelo de dados. Observe a imagem a seguir.
FIGURA 24 – MODELO DE DADOS
AUTOATIVIDADE
FONTE: O autor
Supondo que para popular o sistema você receba um banco de dados opera-
cional (OLTP) e um JSON com os endereços, o que será necessário fazer com 
estes dados na ETL?
2 Um Data Warehouse é composto por diversas etapas, dentre elas a ETL é 
responsável por 80% de todo esforço computacional. Suponha que exista uma 
fonte de dados que receba os endereços por código, mas no modelo multidi-
mensional é armazenado o formato de texto. Assinale a alternativa CORRETA 
que apresenta o componente da ETL responsável por adequar estes dados: 
a) Transformação.
b) Extração.
c) Carga.
d) Nenhuma das Alternativas.
3 O texto “Detecção de Casos de Violência Patrimonial a partir do Twitter” 
realiza a coleta e análise de dados da rede social Twitter com técnicas de Data 
Warehousing. Assinale a alternativa CORRETA que apresenta a ferramenta 
de ETL utilizada pelo autor:
 
Lineorder
lo_orderkey
lo_linenumber
lo_partkey
lo_suppkey
lo_orderdate
lo_commitdate
lo_custkey
lo_revenue
lo_quantity
...1
1
1
1
N
N
N
N
Part
p_partkey
p_name
p_mfgr
p_category
p_brand1
p_color
p_type
p_size
p_container
Date
d_datekey
p_date
p_dayofweek
p_month
p_year
p_yearmonthnum
p_yearmonth
p_daynumweek
...
Customer
c_custkey
c_address
c_city
c_nation
c_region
c_name
Supplier
s_suppkey
s_address
s_city
s_nation
s_region
s_name
106
a) Power BI.
b) PostgreSQL.
c) Pentaho Data Integration.
d) Nenhuma das Alternativas.
4 A rede social Twitter tem um grande conjunto de dados que pode ser utiliza-
do para as mais diversas pesquisas. Dentre as áreas de estudo, existe a análise 
de sentimentos, que categoriza cada texto como: positivo, negativo e neutro. 
Supondo que haja um conjunto de dados que contenha as informações do sen-
timento (positivo, negativo e neutro) e outro que não as contenham, assinale a 
alternativa CORRETA que apresenta o nome da técnica que permite alimentar 
um Data Warehouse utilizando Machine Learning para descobrir valores:
a) Descoberta de dimensões.
b) Análise de Risco.
c) Enriquecimento Semântico.
d) Pentaho Data Integration.
5 Um sistema de Data Warehouse é alimentado por um banco de dados rela-
cional, um arquivo JSON e um documento XML. O Data Warehouse armaze-
na informações de crédito de clientes, no entanto, cada uma destas fontes de 
dados armazena o status do cliente de maneira diferente:
● Banco Relacional: Positivo e Negativo.
● JSON: 1 e 0.
● XML: Sim e Não.
Assinale a alternativa CORRETA que apresenta a etapa da ETL por integrar 
esses dados e armazenar com um único padrão:
a) Transformação.
b) Enriquecimento Semântico.
c) Carga.
d) Extração.
107
UNIDADE 3
VISUALIZAÇÃO DOS 
DADOS: CONSTRUÇÃO DE 
DASHBOARDS
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
A partir do estudo desta unidade, você deverá ser capaz de:
• introduzir o aluno à camada de visualização de dados;
• explicar os elementos da modelagem multidimensional;
• aprofundar conceitos sobre o modelo estrela e floco de neve;
• explicar conceitos sobre o servidor OLAP;
• ver as principais ferramentas de visualização de dados do mercado.
Esta unidade de ensino contém três tópicos. No final de cada um deles você 
encontrará atividades que contribuirão para a apropriação dos conteúdos..
TÓPICO 1 – MODELAGEM MULTIDIMENSIONAL
TÓPICO 2 – OPERAÇÕES E SERVIDORES OLAP
TÓPICO 3 – FERRAMENTAS DE DASHBOARDS
Preparado para ampliar seus conhecimentos? Respire e vamos 
em frente! Procure um ambiente que facilite a concentração, assim absorve-
rá melhor as informações.
CHAMADA
108
109
TÓPICO 1
MODELAGEM MULTIDIMENSIONAL
UNIDADE 3
1 INTRODUÇÃO
O conhecimento armazenado ao longo dos anos nas bases de dados orga-
nizacionais é um bem vital para a sobrevivência de uma empresa neste mercado 
competitivo. Para a sua efetiva utilização como apoio ao processo decisório de 
uma organização, os dados precisam estar organizados de uma forma que possi-
bilite o seu acesso rápido e fácil entendimento (BRUZAROSCO, 2000). 
Você aprendeu que para dar suporte ao tomador de decisões são desen-
volvidos sistemas de Business Intelligence, que muitas vezes acontecem por in-
termédio de uma arquitetura de Data Warehouse. 
O processo de Data Warehouse tem início com a coleta dos dados, que 
pode acontecer de sistemas transacionais, dados da Web, dados de sensores e 
dos mais diversos tipos de dados possíveis, que são integrados e consolidados 
em uma arquitetura de Data Warehouse. Após realizar a etapa de ETL, pode-se 
dizer que os dados são armazenados em um Data Warehouse que, por sua vez, 
é representado por um modelo de dados orientado à análise de dados e extração 
de informação. 
Segundo Elmasri e Navathe (2005), um modelo de dados é um conjunto 
de conceitos que podem ser usados para descrever a estrutura e as operações 
em um banco de dados. Durante nosso estudo vimos de maneira mais ampla 
a modelagem dimensional, suas principais características, modelos, bem como 
diferenças com a modelagem transacional. 
A partir de agora iremos compreender mais a fundo o funcionamento da 
modelagem multidimensional, bem como estudar os principais modelos utiliza-
dos por esta abordagem. 
 
2 MODELAGEM MULTIDIMENSIONAL
Um modelo de dados é uma coleção de conceitos que podem ser usados 
para descrever um conjunto de dados e as operações para manipular esses dados 
(LISBOA FILHO; IOCHPE, 1999). De modo geral, o modelo de dados tem a mis-
são de representar os dados em níveis de abstração, ou seja, ser ao mesmo tempo 
compreensível ao usuário e permitir a criação de uma arquitetura de armazena-
mento para os dados. 
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
110
A característica básica de um modelo de dados, como o próprio termo 
explicita, é que ele é uma abstração da realidade. Um modelo de dados fornece 
uma base formal para ferramentas e técnicas usadas para suportar a modelagem 
de dados. Modelagem de dados é o processo de abstração ondesomente os ele-
mentos essenciais da realidade observada são enfatizados, descartando-se os ele-
mentos não essenciais.
A modelagem multidimensional, também abordada pela literatura como 
modelagem dimensional, é o nome dado a uma técnica que tem como objetivo 
desenvolver bancos de dados analíticos por meio de suas dimensões. A aborda-
gem da simplicidade é trazida por Kimball e Ross (2011), que afirmam que o con-
ceito de modelagem dimensional foi utilizado como uma abordagem com ênfase 
na simplicidade de como os usuários utilizam os dados. 
A modelagem dimensional é uma metodologia que permite modelar lo-
gicamente dados para melhorar o desempenho de consultas e prover facilidade 
de utilização a partir de um conjunto de eventos básicos de medição. Os modelos 
dimensionais são compreensíveis, previsíveis, ampliáveis e resistentes ao ataque 
específico de grupos de usuários de negócio, por se manterem fiéis à simplicida-
de, terem uma perspectiva voltada para as necessidades analíticas da empresa e 
especialmente ao seu formato simétrico, em que todas as dimensões normalmen-
te são pontos de entrada iguais na tabela de fatos (HOKAMA, 2004).
A técnica de modelagem multidimensional trata da elaboração de um 
projeto lógico de um banco de dados, que tem sua aplicação destinada à análise 
de dados. Utilizando a modelagem multidimensional, estabelece-se a estrutura 
de dados sob qual cubo de dados será analisado. Segundo Nogueira (2019), a 
modelagem multidimensional é uma estratégia de modelagem de dados que tem 
ênfase na análise dos dados, ou seja, na realização de consultas. 
Ao contrário da modelagem relacional (OLTP), na modelagem multidi-
mensional a única preocupação é realizar consultas com bom desempenho, nesta 
etapa não há preocupação com a integridade dos dados. 
Sim, é isso mesmo que você acaba de ler, durante o desenvolvimento do mo-
delo multidimensional não há a preocupação com a integridade dos dados. Lembre-se de 
que quando os dados chegarem até o modelo, já terão passado pelo processo de ETL, que 
é o responsável pela coleta, integração e carga dos dados, ficando a seu cargo todo esforço 
computacional, visando garantir a integridade dos dados armazenados. 
NOTA
TÓPICO 1 | MODELAGEM MULTIDIMENSIONAL
111
2.1 COMPONENTES DA MODELAGEM MULTIDIMENSIONAL
A modelagem multidimensional (ou modelagem dimensional) tem esse 
nome principalmente pelo componente principal: as dimensões. De modo geral, um 
modelo multidimensional é composto por uma Tabela Fato e demais tabelas denomi-
nadas dimensões. Vamos compreender o significado de cada uma no modelo.
FIGURA 1 – FATOS E DIMENSÕES 
FONTE: <http://bit.ly/2Qgb0KA>. Acesso em: 20 jan. 2020. 
A Tabela Fato pode ser compreendida como o objeto da análise, ou seja, 
no mundo real qual é o principal objeto a ser analisado. Se o seu objetivo é fazer 
a análise de vendas de uma empresa, seu fato será vendas, se o objetivo é desen-
volver um sistema de análise de mensagens, o fato será a mensagem, se a análise 
for em cima do estoque, o fato será o estoque, e assim por diante.
Em seguida, a Figura 2 mostrará o exemplo de um modelo multidimen-
sional, no qual a Tabela Fato, que se chama FATO_VENDAS, fica ao centro. As 
dimensões são compostas pelas tabelas: DIMENSAO_FUNCIONARIO, DIMEN-
SAO_LOJA, DIMENSAO_PRODUTO, DIMENSAO_DATA.
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
112
FIGURA 2 – FATOS E DIMENSÕES 
FONTE: <https://canaltech.com.br/business-intelligence/Conhecendo-o-modelo-
multidimensional-na-pratica/>. Acesso em: 20 jan. 2020. 
Segundo Rossi (2017), as tabelas fato descrevem um processo ou operação 
da instituição sob qual será realizado uma análise. A granularidade é representa-
da por cada linha de uma tabela, de certo modo compreendido como o tamanho.
A granularidade vem realmente de grão, qual o menor grão (dado) possível 
de ser armazenado. O grão é o menor nível da informação e é definido de acordo com 
as necessidades elencadas no início do projeto. Ele é determinado para cada Tabela Fato, 
já que normalmente Fatos possuem informações e granularidades distintas. É importan-
te entender o relacionamento existente entre o detalhamento e a granularidade. Quan-
do falamos de menor granularidade, ou granularidade fina, significa maior detalhamento 
(menor sumarização) dos dados. Maior granularidade, ou granularidade grossa, significa 
menor detalhamento (maior sumarização). Assim podemos notar que a granularidade e o 
detalhamento são inversamente proporcionais. 
FONTE: <https://canaltech.com.br/business-intelligence/a-granularidade-de-dados-no-da 
ta-warehouse-26310/>. Acesso em: 10 mar. 2020.
IMPORTANT
E
TÓPICO 1 | MODELAGEM MULTIDIMENSIONAL
113
Na sequência compreenderemos melhor como as Tabelas Fato e Dimen-
sões funcionam, bem como seus principais tipos e características, porém, primei-
ro, na próxima seção veremos o conceito de métricas, essencial para a continui-
dade do conteúdo.
2.1.1 Métricas
 
Durante o projeto de um Data Warehouse, na modelagem multidimen-
sional, a Tabela Fato recebe como chave estrangeira de todas as Dimensões, bem 
como as métricas. Métricas são valores relacionados ao Fato estudado, que será 
analisado pelas perspectivas das dimensões. 
Segundo Piton (2017), a métrica é utilizada para medir ou para quantificar 
algo. Em ambientes alimentados por sistemas OLAP são sempre números pro-
venientes de transações da empresa. Tudo que o Data Warehouse for mensurar 
é métrica, geralmente sendo o usuário que realizará a medição. Por exemplo: as 
métricas número de vendas ou seguidores em determinada rede social. Em cima 
delas o usuário realizará medição: soma, média, contagem, ou qualquer operação 
que utilize esses valores. 
Segundo Carvalho (2009) e Correa (2018), as métricas podem ser dividi-
das em aditivas, semiaditivas e não aditivas, em que cada uma significa:
• Métricas aditivas: são métricas na quais após a implementação os usuários po-
derão realizar operações de adição (soma) utilizando qualquer dimensão do 
modelo utilizado. No exemplo do modelo multidimensional para venda visto 
anteriormente, o exemplo de uma métrica aditiva é o VALOR_TOTAL, pois 
utilizando este valor será possível realizar somas, bem como demais operações 
de análise de todas as dimensões. 
• Métricas não aditivas: as métricas não aditivas são valores que não podem ser 
manipulados livremente, como valores percentuais ou relativos.
• Métricas semiaditivas: são métricas que podem ser somadas apenas utilizando 
um conjunto específico de dimensões e não por todas. Supondo que no modelo 
do sistema de vendas seja adicionado a dimensão BANCO e a métrica SAL-
DO_BANCO, esta métrica poderá ser analisada por um número limitado de 
dimensões. As métricas semiaditivas são valores que não podem ser somados 
em todas as dimensões.
Agora que você já conhece o que é uma métrica, estudaremos os tipos de 
fato e conheceremos sua relação com as métricas.
2.1.2 Tipos de Tabelas Fato
A Tabela Fato é um componente de Data Warehouse, que contém os da-
dos transacionais que se deseja analisar. Normalmente um fato é algum assunto 
específico que ocorreu, como venda, por exemplo. Este tipo de tabela contém, na 
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
114
maioria dos casos, indicadores numéricos que, consolidados, agregam valor ao 
negócio (CORREA, 2018).
FIGURA 3 – MODELAGEM DA TABELA FATO: A VENDA COMO OBJETO DE ANÁLISE DE UM 
DATA WAREHOUSE
FONTE: Adaptada de Kimball e Ross (2011)
No que se refere a sua modelagem, bem como em sua futura implementa-
ção, a Tabela Fato é como se fosse uma tabela de um banco de dados qualquer. No 
entanto, para esse tipo de implementação utilizamos o modelo lógico. Os campos 
pertencentes à Tabela Fato são, tradicionalmente, chaves estrangeiras das dimen-
sões que a Fato está associada, complementando as métricas utilizadas. 
2.2 PREPARANDO O AMBIENTE DE IMPLEMENTAÇÃO DE 
UM DATA WAREHOUSE
Esta é uma seção complementar, que tem como objetivolhe auxiliar na 
implementação de um banco de dados relacional, bem como um modelo multi-
dimensional. 
No decorrer desta unidade trabalharemos com exemplos e com dados, 
por isso quando falarmos sobre modelo transacional de vendas, para melhor 
aproveitamento, será necessário que você crie um banco de dados transacional. 
Para isso vamos propor o modelo de vendas mostrado pela Figura 4. 
TÓPICO 1 | MODELAGEM MULTIDIMENSIONAL
115
FIGURA 4 – MODELO TRANSACIONAL 
FONTE: O autor 
Para poder realizar o processo de envio de dados para o modelo multidi-
mensional (ETL), bem como exemplificar os tipos de tabelas, precisaremos criar o 
banco de dados na prática, bem como alimentá-lo com dados. Os comandos SQL 
para criação são:
 
QUADRO 1 – CRIAÇÃO DO BANCO DE DADOS TRANSACIONAL
-- Comando de criação da tabela pessoa 
create table pessoa(
 id_pessoa integer not null,
 nome varchar (100) not null,
 endereco varchar (100) not null,
 primary key (id_pessoa)
);
-- Comando de criação da tabela fornecedor 
create table fornecedor(
 id_fornecedor integer not null,
 cnpj varchar (14) not null unique,
 foreign key (id_fornecedor) references pessoa (id_pessoa),
 primary key (id_fornecedor)
);
-- Comando de criação da tabela fornecedor 
create table cliente(
 id_cliente integer not null,
 data_nasc timestamp,
 cpf varchar (11) not null unique,
 foreign key (id_cliente) references pessoa (id_pessoa),
 primary key (id_cliente)
);
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
116
-- Comando de criação da tabela venda 
create table venda(
 id_venda integer not null,
 data date,
 id_cliente integer not null,
 foreign key (id_cliente) references cliente (id_cliente),
 primary key (id_venda)
);
-- Comando de criação da tabela produto 
create table produto(
 id_fornecedor integer not null, 
 id_produto integer not null,
 dercricao varchar not null,
 preco double precision not null,
 foreign key(id_fornecedor) references fornecedor (id_fornecedor),
 primary key (id_produto)
);
-- Comando de criação da tabela produto_estoque, esta tabela armazena cada 
item inserido no estoque
create table produto_estoque(
 id_estoque integer not null,
 id_produto integer not null,
 foreign key (id_produto) references produto (id_produto),
 primary key (id_estoque)
);
FONTE: O autor
Como em um ambiente de Data Warehouse se trabalha com um grande con-
junto de dados para desenvolver consultas, disponibilizamos um conjunto de dados com-
pleto, bem como uma explicação mais detalhada que pode ser encontrada no link: https://
colab.research.google.com/drive/1sZ09dSgUwwhc7bM5ZzaU-UVhccpYCIj4.
DICAS
Quando nos referirmos ao modelo multidimensional, estaremos nos refe-
rindo ao modelo de banco de dados que armazenará os dados de um Data Wa-
rehouse, para execução dos próximos exemplos utilizaremos o seguinte modelo 
multidimensional.
TÓPICO 1 | MODELAGEM MULTIDIMENSIONAL
117
FIGURA 5 – MODELO MULTIDIMENSIONAL - OLAP
FONTE: O autor 
Discutiremos maiores detalhes sobre a implementação de um modelo 
multidimensional no próximo tópico, de todo modo, para realizar a implementa-
ção do modelo anterior, você precisará do seguinte código SQL. 
QUADRO 2 – IMPLEMENTAÇÃO DO MODELO MULTIDIMENSIONAL
-- Fonte de Dados OLTP 1
create table fornecedor
(
 id_fornecedor integer primary key,
 data_cadastro varchar(20)-- Comando de criação da dimensão cliente
create table DIMENSAO_CLIENTE(
 id_cliente integer primary key.
 nome varchar,
 endereco varchar
)
-- Comando de criação da dimensão fornecedor
create table DIMENSAO_FORNECEDOR(
 id_produto integer primary key.
 nome varchar,
 produtos varchar
)
-- Comando de criação da dimensão tempo 
create table DIMENSAO_TEMPO(
 id_tempo integer primary key.
 dia integer,
 mes integer, 
 ano integer,
 hora integer, 
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
118
 minuto integer,
 segundo integer, 
 dia_semana integer
)
-- Comando de criação da dimensão produto
create table DIMENSAO_PRODUTO(
 id_produto integer primary key.
 nome varchar, 
 preco numeric, 
 estoque integer
)
-- Comando de criação da tabela fato 
create table FATO VENDA(
 id_cliente integer, 
 id_produto integer,
 id_fornecedor integer, 
 id_tempo integer, 
 foreign key id_cliente references cliente(id_cliente),
 foreign key id_produto references produto(id_produto),
 foreign key id_fornecedor references fornecedor(id_fornecedor),
 foreign key id_tempo references tempo(id_tempo) 
 )
FONTE: O autor
O banco de dados multidimensional é alimentado pela fonte de dados OLTP 
mostrada anteriormente através de um processo de ETL. Todo o processo, bem como a 
base de dados completa pode ser encontrada em:
https://colab.research.google.com/drive/1sZ09dSgUwwhc7bM5ZzaU-UVhccpYCIj4.
DICAS
2.2.1 Fato Transacional 
Segundo Rossi (2017), a Tabela Fato Transacional é uma tabela em que 
cada linha corresponde a uma transação relacionada a um evento operacional 
da instituição em um instante e local. Este tipo de fato pode conter um número 
grande de dimensões e geralmente utiliza métricas aditivas. 
 
Para compreender melhor o funcionamento de uma Tabela Fato Transa-
cional, vamos considerar um modelo transacional criado. Logo, para popular um 
modelo multidimensional durante o processo de ETL será utilizada a seguinte 
consulta nos dados transacionais:
TÓPICO 1 | MODELAGEM MULTIDIMENSIONAL
119
QUADRO 3 – CONSUMO DE DADOS PARA POPULAR UMA FATO TRANSACIONAL
SELECT v.id_venda, c.id_cliente, f.id_fornecedor, v.data, p.preco, p.descricao 
FROM venda as v
 INNER JOIN cliente as c
 ON v.id_cliente = c.id_cliente
 INNER JOIN item_venda as iv
 ON iv.id_venda = v.id_venda
 INNER JOIN produto_estoque as e
 ON iv.id_estoque = e.id_estoque
 INNER JOIN produto as p
 ON e.id_produto = p.id_produto 
 INNER JOIN fornecedor as f
 ON p.id_fornecedor = f.id_fornecedor 
FONTE: O autor
A consulta no banco transacional retornará todo o conteúdo das vendas 
linha por linha. Por isso, apesar de a Tabela Fato Transacional ser a abordagem 
mais utilizada, podemos reparar o motivo de um Data Warehouse conter bilhões 
de registros. A figura a seguir mostra o exemplo de um trecho do retorno da con-
sulta que retorna todos os registros de venda. 
FIGURA 6 – CONSULTA PARA POPULAR A TABELA FATO TRANSACIONAL
FONTE: O autor 
2.2.2 Fato por agrupamento de dados: Agregada, 
Snapshot e Consolidada
Quando falamos sobre desenvolver um mecanismo Business Intelligence, 
quanto mais dados armazenamos, maior será a capacidade analítica. No entanto, 
existem alguns métodos que permitem agrupar dados por período. 
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
120
A Tabela Fato Agregada, por exemplo, tem como objetivo agregar (agru-
par) os registros coletados do ambiente transacional. Na maioria dos casos, esse 
tipo de tabela faz o agrupamento explorando a dimensão tempo, armazenando 
os dados por um período. 
Vamos fazer o exemplo anterior, mas agora utilizando o conceito de Fato 
Agregado, no qual agrupamos os dados coletados por período. Confira a seguir 
um exemplo de como funciona o comando que faz a agregação dos dados tran-
sacionais.
QUADRO 4 – CONSUMO DE DADOS PARA POPULAR UMA FATO AGREGADA
SELECT v.data, sum(p.preco) as total_venda , count(e.id_estoque) as total_es-
toque FROM venda as v
 INNER JOIN cliente as c
 ON v.id_cliente = c.id_cliente
 INNER JOIN item_venda as iv
 ON iv.id_venda = v.id_venda
 INNER JOIN produto_estoque as e
 ON iv.id_estoque = e.id_estoque
 INNER JOIN produto as p
 ON e.id_produto = p.id_produto 
 INNER JOIN fornecedor as f
 ON p.id_fornecedor = f.id_fornecedor 
group by data
FONTE: O autor
No comando SQL repare que o cabeçalho da consulta realiza operações de 
agregação SUM(P.PRECO) que somarátodos os produtos vendidos, o comando 
COUNT(E.ID_ESTOQUE) que retorna os produtos em estoque, e os agrupa por 
dia através do comando GROUP BY DATA. 
Complementarmente aos tipos de Tabela Fato mencionados anteriormente, 
existe um tipo de Tabela Fato denominada Fato sem Fato. Esta tabela não possui métricas e 
é composta apenas pelas chaves estrangeiras das dimensões. 
ATENCAO
TÓPICO 1 | MODELAGEM MULTIDIMENSIONAL
121
2.2.3 Tipos de Dimensões
As dimensões descrevem qualitativamente o fato, respondendo às pergun-
tas “Quem? Onde? Quando? Como?” associadas ao evento medido (ROSSI, 2017). 
As dimensões têm como objetivo alimentar a Tabela Fato, no conceito do consumo 
dos dados, as dimensões suportam as análises realizadas pela Tabela Fato.
No exemplo que realizamos sobre o modelo multidimensional de venda, 
a Tabela Fato é alimentada por dados:
• Cliente: fornecendo informações e registros sobre clientes que realizaram ven-
das.
• Produto: fornecendo valores, quantidade e demais registros sobre produtos 
vendidos.
• Tempo: fornece dados sobre período para que sejam explorados todos os níveis 
do aspecto temporal.
2.2.4 Degenerate Dimension
Segundo Kimball et al. (2008), dimensões degeneradas comumente ocor-
rem quando grãos da Tabela Fatos são uma única transação (ou linha de transa-
ção). Números de cabeçalho de controle de transação atribuídos pelo processo 
de negócio operacional são tipicamente dimensões degeneradas, como ordem, 
bilhete, transações de cartão de crédito, ou verificar os números. Estas dimensões 
degeneradas são chaves naturais dos “pais” dos itens de linha.
Mesmo que não exista nenhuma tabela de dimensão correspondente aos 
atributos, dimensões degeneradas podem ser bastante úteis para agrupar linhas 
em conjunto relacionadas com tabelas de fatos. 
Saiba mais sobre Tabela Fato em: 
PITON, R. O que é Tabela Fato (e seus tipos). Disponível em: https://rafaelpiton.com.br/
blog/data-warehouse-tipos-fatos/.
DICAS
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
122
2.2.5 Slowly Changing Dimensions
 
Slowly Changing Dimensions (SCD), em português, significa Dimensões 
que mudam lentamente. Isto porque esse tipo de dimensão pode sofrer alteração 
com passar do tempo. Segundo Canaltech (2014), as Slowly Changing Dimen-
sions retratam as dimensões que sofrem atualizações em seus campos e as classi-
ficam pelo tipo de mudança existente em cada uma delas.
Esse tipo de dimensão tem a missão de manter os dados atualizados de 
acordo com a fonte de dados. No entanto, vale lembrar que um Data Warehouse 
armazena dados históricos, por isso é importante criar mecanismos para garantir 
que as alterações também sejam armazenadas. 
Supondo que em determinada dimensão, os registros originais sejam da-
dos pela figura a seguir:
FIGURA 7 – REGISTRO ORIGINAL
FONTE: Adaptada de Canaltech (2014)
Ao considerar os dados do exemplo, dentre as alternativas para a imple-
mentação da carga em uma dimensão SCD, estão as opções:
• Sobreposição: nessa opção, os dados antigos são ignorados, a dimensão será 
atualizada de acordo com um novo valor que veio da fonte de dados.
• Armazenamento de histórico: nessa opção é possível armazenar um histórico 
dos dados armazenados; pode ser considerada para fins a data de inserção. Ao 
se aplicar existirão mais dados armazenados, ocupando mais espaço, porém 
atenderá melhor o conceito de um Data Warehouse. 
• Criação de um novo campo: a criação de um novo campo é utilizada geralmen-
te para atualizar com o último valor, não para todas as atualizações, mas pelo 
menos o valor anterior. 
A figura a seguir mostra a aplicação do conceito de dimensão SCD utili-
zando as três abordagens vistas no exemplo. 
TÓPICO 1 | MODELAGEM MULTIDIMENSIONAL
123
FIGURA 8 – REGISTRO APÓS NOVOS DADOS
Chave
Dimensão
Código 
Item Nome Setor Nome Responsável
1 25 Coordenação de Produtos João Pereira
Chave
Dimensão
Código 
Item Nome Setor Nome Responsável
1 25 Coordenação de Produtos Carlos José
2 25 Coordenação de Produtos João Pereira
Chave
Dimensão
Código 
Item Nome Setor Nome Responsável
Nome Responsável 
Atual
1 25 Coordenação de Produtos Carlos José João Pereira
FONTE: Adaptada de Canaltech (2014)
2.2.6 Role-playing Dimension
As Role-playing Dimension podem ser compreendidas como uma dimen-
são que é referenciada mais de uma vez pela Tabela Fato, ou seja, a Tabela Fato 
terá várias chaves estrangeiras apontando para esse tipo de dimensão. 
 
Para exemplificar, considere uma Dimensão Tempo, conforme criamos no 
exemplo do modelo de venda. No modelo original, existe apenas o conceito de 
venda, existindo a referência à Dimensão Tempo como o tempo em que a venda 
foi realizada. 
Faremos uma suposição de que o modelo além da venda suportasse a en-
trega, logo teríamos o tempo da venda e o tempo da entrega. Nesse caso, ao invés 
de se criar uma nova dimensão de tempo, se aproveita a existente fazendo duas 
referências, uma para o tempo da venda e outra para o tempo da entrega. 
FIGURA 9 – IMPLEMENTANDO UMA ROLE-PLAYING DIMENSION
FONTE: Adaptada de Piton (2017)
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
124
2.2.7 A Dimensão Tempo
 
Como você pode ter percebido, em um ambiente de Data Warehouse não 
é comum utilizarmos os campos data na forma de time, date ou timestamp. Isso 
acontece com o objetivo de otimizar o tempo das consultas, uma vez que ao invés 
de referenciar um tipo de dado complexo, como é o caso de um timestamp, utiliza 
o tipo integer. 
A Dimensão Tempo geralmente é criada na etapa de implementação de 
um Data Warehouse, em que a tabela é alimentada com todos os seus campos no 
intervalo de data que será composto desde o primeiro registro no banco de dados 
de origem e projetando no mínimo um ano de dados para frente. 
Com isso, a Dimensão Tempo será uma tabela com bilhões de registros, mas 
que permitirá oferecer alto desempenho na realização de consultas, permitindo ex-
plorar seus campos (filtro por dia da semana, do mês, quinzena, entre outros).
A implementação da Dimensão Tempo pode ser feita utilizando ferra-
mentas de Business Intelligence, como o Pentaho. Tais ferramentas permitem que 
seja gerado, de maneira visual, a dimensão tempo, alimentando toda a dimensão 
com dados sintéticos. 
No caso do Pentaho, é possível fazer isso utilizando o elemento Genera-
te Rows, uma funcionalidade do Pentaho para popular dinamicamente tabelas. 
Para popular as datas, é necessário navegar através do menu Input → Generate 
Rows. Utilizando esse recurso, basta configurá-lo de acordo com a data de início 
e fim que o Pentaho gerará os dados da Dimensão Tempo. 
FIGURA 10 – IMPLEMENTANDO A DIMENSÃO TEMPO UTILIZANDO PENTAHO
FONTE: <http://opendesignarch.blogspot.com/2013/08/creating-time-dimension-table-in.html>. 
Acesso em: 9 mar. 2020.
TÓPICO 1 | MODELAGEM MULTIDIMENSIONAL
125
No tocante à implementação da Dimensão Tempo, também é possível ge-
rar os dados por meio de uma linguagem de programação. Como já utilizamos 
Python no decorrer do livro, vamos fazer um exemplo de geração de dados utili-
zando esta linguagem.
QUADRO 5 – POPULANDO A DIMENSÃO TEMPO COM PYTHON
from datetime import datetime, timedelta
import sys
data_inicio = datetime.strptime(sys.argv[1], '%Y-%m-%d')
data_fim = datetime.strptime(sys.argv[2], '%Y-%m-%d')
for x in range((data_fim - data_inicio ).days + 1):
 proxima_data= start_date + timedelta(x)
 print "%s,%s,%s" % (proxima_data.strftime('%B'), proxima_data.strfti-
me('%Y'), next_date.strftime('%Y_%m_%d'))
FONTE: O autor
Visando incrementar seus conhecimentos sobre as Dimensões, sugerimos a 
seguinte leitura: 
Piton, R. Tabela Dimensão: os 5 tipos que você deve conhecer. Disponível em: https://rafa-
elpiton.com.br/blog/data-warehouse-tipos-dimensoes/. Acesso em: 9 mar. 2020.
Para compreender melhor o funcionamento da implementação das Tabela 
Fato e Dimensão, desenvolvemos mais exemplos práticos sobre este conteúdo em:
https://colab.research.google.com/drive/1RewZWG45dvNZZSMUspm0OyKM6y8MKRta.DICAS
DICAS
2.3 OS MODELOS DE DADOS MULTIDIMENSIONAIS
 
Durante nosso primeiro capítulo você aprendeu algumas diferenças es-
senciais sobre a modelagem multidimensional em ambientes de Data Warehouse. 
Agora estudaremos um pouco mais a fundo ambos os modelos de dados: Star 
Schema e Snowflake. 
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
126
2.3.1 Modelo Estrela
 
O Star Schema, modelo estrela, é uma estratégia de modelagem de dados 
muito utilizada na construção de modelos multidimensionais para ambientes de 
Data Warehouse. Esse tipo de modelo é construído com o objetivo de dar suporte 
à tomada de decisão e melhorar o desempenho das consultas em ambientes mul-
tidimensionais. 
O modelo estrela é a estrutura básica de um modelo de dados multidi-
mensional, e é composto de uma tabela principal ao centro do modelo (TABELA 
FATO) e ao redor desta tabela as demais tabelas, que são chamadas de DIMEN-
SÕES, sendo que esta disposição forma uma estrela, daí o nome do modelo.
FIGURA 11 – MODELO ESTRELA
FONTE: O autor 
Vale lembrar que um Data Warehouse tem como principal objetivo a aná-
lise dos dados, partindo deste princípio, ao implementá-lo utilizando a mode-
lagem estrela consolidada, os dados coletados das fontes serão consolidados no 
menor número de tabelas possível. 
Nogueira (2019) cita as seguintes perguntas que podem auxiliar no pro-
cesso de construção do modelo estrela. 
• Quais tabelas posso juntar em apenas uma? Por exemplo, ao invés de existir a 
tabela bairro, cidade, estado e país, ligadas por chaves, você pode inserir todas 
essas informações em uma única tabela chamada localidade. 
TÓPICO 1 | MODELAGEM MULTIDIMENSIONAL
127
• Quais dados eu calculo que podem ser armazenados em um campo? Um exem-
plo disso é quando no banco transacional existe a tabela produto e a quanti-
dade vendido, sendo que o valor total é calculado por consulta. Ao realizar o 
modelo estrela para este caso, será criada uma métrica na Tabela Fato chamada 
total, que armazenará esse valor já calculado, o que otimiza o tempo de respos-
ta das análises. 
FIGURA 12 – MODELAGEM ESTRELA PARA SISTEMA DE VOO
FONTE: <https://community.qlik.com/legacyfs/online/101747_Sem%20T%C3%ADtulo1.png>. 
Acesso em: 9 mar. 2020.
Partindo do exemplo utilizado anteriormente, além da solução já propos-
ta, a figura a seguir mostra uma alternativa de modelagem para o mesmo sistema 
de vendas, note que existe uma tabela central (FATO) sendo alimentada pelas 
demais (DIMENSÕES). A principal percepção que se pode ter ao aplicar a mode-
lagem estrela é a redução do número de tabelas, o que implicará melhor desem-
penho das consultas.
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
128
FIGURA 13 – EXEMPLO DE MODELO MULTIDIMENSIONAL ESTRELA DE VENDAS
FONTE: Adaptada de Nogueira (2019)
2.3.2 Modelo Snowflake
O esquema floco de neve é uma variação do esquema estrela, no qual 
todas as tabelas de dimensão são normalizadas na terceira forma normal (3FN), 
ou seja, são retirados das tabelas os campos que são funcionalmente dependentes 
de outros campos que não são chaves. Recomenda-se utilizar o esquema floco de 
neve apenas quando a linha de dimensão ficar muito longa e começar a ser rele-
vante do ponto de vista de armazenamento (HOKAMA, 2004).
TÓPICO 1 | MODELAGEM MULTIDIMENSIONAL
129
FIGURA 14 – MODELO SNOWFLAKE
FONTE: O autor 
 
Dentre as características dessa modelagem, aplica o conceito de normali-
zação e por isso tem diversas tabelas. Conforme vimos, o processo de normaliza-
ção nos obriga a criar novos campos a cada forma normal aplicada. 
Como a modelagem multidimensional é uma estratégia que objetiva oti-
mizar o processo de recuperação de informações através de consultas, tal proces-
so não pode utilizar um excesso de tabelas, o que implicará um excesso de jun-
ções. Por isso, ao utilizar o modelo Snowflake, o recomendado é que ao se pensar 
em normalização aplique no máximo a terceira forma normal.
A principal diferença entre o esquema floco de neve e o esquema estrela 
é o fato de o primeiro possuir um maior número de tabelas para representar as 
mesmas dimensões e também de necessitar de menos espaço em disco com a 
mesma informação.
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
130
FIGURA 15 – MODELO FLOCO DE NEVE PARA SISTEMA DE VOO
FONTE: <https://community.qlik.com/legacyfs/online/101748_Sem%20T%C3%ADtulo.png>. 
Acesso em: 9 mar. 2020.
TÓPICO 1 | MODELAGEM MULTIDIMENSIONAL
131
Dicas de Kimball para a Modelagem Multidimensional
No contexto da modelagem multidimensional, Ralph Kimball, criador do 
Kimball Group e principalmente um dos principais nomes do Data Warehouse, dei-
xa regras importantes para o desenvolvimento da modelagem multidimensional.
 
RALPH KIMBALL
FONTE: <https://bit.ly/3bgyqsf>. Acesso em: 10 mar. 2020.
Regra #1 - Carregue dados detalhados para as estruturas dimensionais: 
modelos dimensionais devem ser populados com um alicerce de dados detalhados 
para suportar os requisitos imprevisíveis de filtragem e agrupamento necessários 
para atender às consultas dos usuários de negócios. Usuários normalmente não 
precisam visualizar um registro por vez, mas é impossível prever em quais diferen-
tes maneiras eles pretendem ver os dados e acessar os detalhes. Se apenas dados 
agregados estiverem disponíveis, então você já deve ter se deparado com padrões 
de utilização dos dados que levaram os usuários a chegar a uma barreira intrans-
ponível quando eles querem acessar os detalhes. É claro, dados detalhados podem 
ser complementados por modelos dimensionais agregados que trazem vantagens 
de desempenho para consultas frequentes de dados sumarizados, mas os usuários 
de negócios não conseguem viver apenas dos dados agregados; eles precisam dos 
detalhes sangrentos para responder seus diferentes questionamentos.
Regra #2 - Estruture os modelos dimensionais em torno dos processos 
de negócios: os processos de negócios são as atividades desenvolvidas por sua 
empresa; elas representam eventos mensuráveis, como registrar um pedido ou 
LEITURA COMPLEMENTAR
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
132
emitir uma fatura para um consumidor. Processos de negócios normalmente cap-
turam ou geram métricas únicas de desempenho associadas a cada evento. Estas 
métricas são traduzidas em fatos, com cada processo de negócios representado 
por uma única tabela fato.
Além destas tabelas fato para cada processo, tabelas fato consolidadas às 
vezes são criadas para combinar métricas de vários processos em uma tabela fato 
com um nível padronizado de detalhe. Novamente, tabelas fato agregadas são 
um complemento para as tabelas fato detalhadas relacionadas aos processos de 
negócio, e não um substituto para elas.
Regra #3 - Tenha certeza de que cada tabela fato tenha uma dimensão de 
data associada: os eventos mensuráveis descritos na Regra #2 sempre têm uma 
data de algum tipo associada a eles, sejam eles um balancete mensal ou uma 
transferência de dinheiro registrada em seu centésimo de segundo. Cada tabela 
fato deve ter ao menos uma chave estrangeira associada a uma tabela de dimen-
são data, cuja granularidade é cada único dia, com os atributos de calendário 
e suas características não padronizadas relacionadas à data do evento, como o 
período fiscal ou um indicador corporativo de feriado. Às vezes múltiplas chaves 
estrangeiras de data estão ligadas em uma única tabela fato.
Regra #4 - Certifique-se de que todos os fatos em uma única tabela fato 
estão na mesma granularidade ou nível de detalhe: existem três granularidades 
fundamentais para classificar todas as tabelas fato: transacional, snapshot perió-
dico, ou snapshot acumulado. Independente de sua granularidade, cada métrica 
em uma tabela fato deve estar exatamente no mesmo nível de detalhe. Quando 
você mistura fatos representando muitos níveis de granularidade em uma mesma 
tabela fato, você estará criando confusão para os usuários de negócios etornando 
as aplicações de BI vulneráveis a erros de valores ou outros resultados incorretos.
Regra #5 - Resolva relacionamentos muitos para muitos em tabelas fato: 
como uma tabela fato guarda os resultados de um evento de um processo de ne-
gócios, existem inerentemente relacionamentos muitos para muitos (M:M) entre 
suas chaves estrangeiras, como diferentes produtos vendidos em diferentes lojas 
em diferentes dias. Estes campos de chaves estrangeiras nunca devem conter va-
lores nulos. Às vezes dimensões podem ter valores diferentes para uma única 
métrica, como diferentes diagnósticos associados com uma consulta médica ou 
diferentes clientes de uma conta bancária. Nestes casos, seria irracional resolver 
as dimensões multivaloradas diretamente na tabela fato, pois isto poderia violar a 
granularidade natural da métrica. Neste caso, podemos usar um relacionamento 
muitos para muitos, com uma tabela de relacionamento em conjunto à tabela fato.
Regra #6 - Resolva os relacionamentos muitos para um nas tabelas de 
dimensões: hierarquicamente, relacionamentos muitos para um (M:1) entre atri-
butos são normalmente desnormalizados ou concentrados em uma única tabela 
dimensão. Caso você não queira passar a maior parte de sua carreira desenhando 
modelos entidade-relacionamento para sistemas transacionais, você precisa resis-
TÓPICO 1 | MODELAGEM MULTIDIMENSIONAL
133
tir a sua instintiva tendência a normalizar ou criar um snowflake com subdimen-
sões menores para cada relacionamento M:1; desnormalização de dimensões é a 
regra do jogo na modelagem dimensional.
É bastante comum ter muitos relacionamentos M:1 em uma única tabela 
dimensão.
Relacionamentos um para um, como uma única descrição de produto asso-
ciada a um código de produto, também são encontrados em uma tabela dimensão.
Ocasionalmente, relacionamentos muitos para um são resolvidos na ta-
bela fato, como no caso de uma tabela de dimensão detalhada com milhões de 
linhas e com atributos frequentemente atualizados. Entretanto, usar a tabela fato 
para resolver relacionamentos M:1 deve ser feito de forma moderada.
Regra #7 - Gravar nomes de relatórios e valores de domínios de filtros em 
tabelas dimensão: os códigos e, mais importante ainda, as decodificações e descri-
ções associadas a eles usadas como nomes de colunas em relatórios e como filtros 
em consultas devem ser gravadas em tabelas dimensionais. Evite gravar campos 
com códigos criptográficos ou volumosos campos descritivos na própria tabela 
fato; da mesma forma, não grave apenas o código na tabela de dimensão e assuma 
que os usuários não precisam das decodificações descritivas ou que elas podem ser 
resolvidas na aplicação de BI. Se a informação for um nome de linha/coluna ou um 
filtro de menu, então ela deve ser tratada como um atributo de dimensão. 
Embora tenhamos dito na Regra #5 que as chaves estrangeiras de tabelas 
fato nunca devem ser nulas, também é aconselhável evitar nulos em campos de 
atributos de tabelas dimensão, trocando o valor nulo por um valor como “NA” 
(não se aplica) ou algum outro valor padrão, determinado pela administração de 
dados, para reduzir a confusão entre os usuários, se possível.
Regra #8 - Tenha certeza de que as tabelas dimensão usam uma chave 
artificial: chaves artificiais, sem significado e sequenciais (exceto para a dimensão 
data, em que chaves cronologicamente definidas e mais inteligíveis são aceitáveis) 
provêm um grande número de benefícios operacionais; chaves menores significam 
menores tabelas fato, menores índices e desempenho melhorado. Chaves artificiais 
são absolutamente necessárias no caso de você estar registrando as alterações dos 
atributos da dimensão com uma nova linha para cada mudança. Mesmo que seus 
usuários de negócios inicialmente não visualizem o valor de registrar as alterações 
nos atributos, usar chaves artificiais tornará uma futura alteração de política menos 
onerosa. As chaves artificiais também permitem mapear múltiplas chaves transa-
cionais para um único perfil, adicionalmente protegendo contra atividades opera-
cionais inesperadas, como a reutilização de um código de produto obsoleto ou a 
aquisição de uma outra empresa com suas próprias regras de codificação.
Regra #9 - Crie dimensões padronizadas para integrar os dados na em-
presa: dimensões padronizadas (também conhecidas por dimensões comuns, 
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
134
principais, ou de referência) são essenciais para o Data Warehouse empresarial. 
Gerenciadas no sistema de ETL e então reutilizadas associadas a diversas tabelas 
fato, dimensões padronizadas trazem atributos descritivos consistentes para os 
modelos dimensionais e permitem a habilidade de navegar através dos dados in-
tegrados de diferentes processos de negócios. A matriz de negócios da empresa é 
o diagrama de arquitetura-chave para representar os processos de negócios prin-
cipais da organização e suas dimensões associadas. A reutilização das dimensões 
padronizadas finalmente diminui o tempo de desenvolvimento, eliminando o de-
senho redundante e o esforço de desenvolvimento; entretanto, dimensões padro-
nizadas requerem um compromisso e investimento em administração de dados 
e governança, desta forma você não precisa que cada pessoa concorde com cada 
uma das dimensões para atingir a conformidade.
Regra #10 - Avalie requisitos e realidade continuamente para desen-
volver uma solução de Business Intelligence que seja aceita pelos usuários de 
negócios e suporte seu processo de tomada de decisões: os responsáveis pela 
modelagem dimensional devem constantemente balancear os requisitos do usuá-
rios de negócios com as realidades inerentes aos dados de origem associados para 
desenvolver um modelo que possa ser implantado, e que, mais importante ainda, 
tenha uma boa chance de ser útil aos negócios. A avaliação dos requisitos versus 
realidades é parte da tarefa dos desenvolvedores de Data Warehouse, apesar de 
você estar focado na modelagem dimensional, estratégia do projeto, arquiteturas 
ETL ou implantação/planejamento de manutenção.
FONTE: <https://www.ambientelivre.com.br/tutoriais-pentaho-bi/kimball-university-as-10-regras-
essenciais-para-a-modelagem-de-dados-dimensional.html>. Acesso em: 9 mar. 2020.
135
RESUMO DO TÓPICO 1
Neste tópico, você aprendeu que:
• O modelo de dados é composto por diversos elementos.
• Há diversos tipos de dimensões e fatos.
• A dimensão tempo é um tipo especial utilizado para otimizar as consultas.
• As métricas são utilizadas para armazenar valores para a tabela fato. 
136
1 Um Data Warehouse é composto por diversos itens, mas para que sua im-
plementação aconteça com eficiência é necessário que seja desenvolvido um 
modelo de dados. Analise a imagem a seguir.
AUTOATIVIDADE
Analisando o modelo multidimensional, assinale a alternativa CORRETA sob 
qual modelo é representado.
a) Modelo Estrela.
b) Modelo Floco de Neve.
c) Modelo Snowflake.
d) Modelo Rain.
2 Um Data Warehouse é composto por diversos itens, mas para que sua im-
plementação aconteça com eficiência é necessário que seja desenvolvido um 
modelo de dados. Analise a imagem a seguir:
Lineorder
lo_orderkey
lo_linenumber
lo_partkey
lo_suppkey
lo_orderdate
lo_commitdate
lo_custkey
lo_revenue
lo_quantity
...1
1
1
1
N
N
N
N
Part
p_partkey
p_name
p_mfgr
p_category
p_brand1
p_color
p_type
p_size
p_container
Date
d_datekey
p_date
p_dayofweek
p_month
p_year
p_yearmonthnum
p_yearmonth
p_daynumweek
...
Customer
c_custkey
c_address
c_city
c_nation
c_region
c_name
Supplier
s_suppkey
s_address
s_city
s_nation
s_region
s_name
137
Analisando o modelo multidimensional, assinale a alternativa CORRETA sob 
qual modelo é representado.
a) Modelo Estrela.
b) Modelo Star.
c) Modelo Snowflake.
d) Modelo Rain.
3 Modelagem dimensional é uma das técnicas e conhecimentos mais utiliza-
dos e importantes para modelar o Data Warehouse. Até para utilizar ferra-
mentas, na parte de modelar os metadados ou cubos OLAP,você vai precisar 
entender de modelagem dimensional, a não ser que você utilize outro tipo de 
arquitetura de modelo de dados. Existem dois tipos de metodologias de mo-
delagem de dados usados no Data Warehouse: a Snowflake e a Star Schema, 
que é a mais utilizada.
FONTE: <https://rafaelpiton.com.br/blog/data-warehouse-modelagem-dimensional/>. 
Acesso em: 9 mar. 2020.
Assinale a alternativa CORRETA que contenha os principais componentes do 
modelo multidimensional. 
a) Tabelas de fato, tabelas com dimensões e métricas.
b) Data Warehouse e Data Marts.
c) SGBD e SQL.
d) Corpus data e data lake.
138
4 O Data Warehouse deve ser desenhado para transpor os limites de cada 
um dos sistemas transacionais. Ele é construído para responder questões que 
não estão limitadas às transações ou aos sistemas individuais, apresentando, 
desta forma, uma visão integrada e completa dos negócios. Uma das técnicas 
utilizadas para se obter um modelo para o Data Warehouse que identifique e 
represente as informações importantes para o modelo de negócios é a mode-
lagem dimensional ou multidimensional.
FONTE: <https://www.devmedia.com.br/artigo-sql-magazine-13-modelagem-de-data-
warehouses-e-data-marts-parte-1/5656>. Acesso em: 9 mar. 2020.
Na abordagem da literatura, existem duas estratégias de modelagem multi-
dimensional, assinale a alternativa CORRETA que contenha essas estratégias. 
a) SQL e SGBD.
b) 1FN, 2FN e 3FN.
c) Data Warehouse e Data Marts.
d) Star Schema e Snowflake.
5 Após realizar a coleta e o armazenamento dos dados em um Data Warehou-
se, as ferramentas de dashboards são utilizadas para extrair métricas e indi-
cadores. 
Assinale a alternativa CORRETA sobre a definição de métrica.
a) As métricas são medidas calculadas e são compostas pelas métricas. Estão 
um nível acima das métricas, pois possuem uma visão mais ampla e direcio-
nada da realidade observada.
b) As métricas são ferramentas que permitem extrair conhecimento, além do 
que são realizadas pelas ferramentas de dashboard.
c) As métricas são as medidas brutas, atômicas e de simples composição. Em 
uma estrutura de Data Warehouse, são armazenadas na tabela Fato e medem 
os descritivos salvos nas dimensões.
d) As métricas são dados brutos antes de serem armazenados em um Data 
Warehouse.
139
TÓPICO 2
OPERAÇÕES E SERVIDORES OLAP
UNIDADE 3
1 INTRODUÇÃO
No decorrer do conteúdo estudado, você aprendeu a diferenciar os sis-
temas OLTP de um ambiente OLAP, de modo geral, aprendeu que um sistema 
OLTP é um banco de dados operacional que tem como objetivo armazenar dados 
garantindo as transações e que um ambiente OLAP é formado por um Data Wa-
rehouse, que tem como objetivo armazenar os dados com ênfase na análise. 
A partir de agora desmistificaremos o funcionamento dos sistemas OLAP 
e como implementá-los em um Data Warehouse. O OLAP é a capacidade de o 
sistema processar os dados analiticamente, explorando a multidimensionalidade 
do banco de dados em que os dados estão armazenados. Por isso, o processo de 
modelagem multidimensional se torna fundamental para a construção do am-
biente OLAP.
Segundo Nogueira (2019), as análises nesses ambientes ocorrem em um 
tempo mais rápido. Objetivando-se atingir tempo real nas consultas, são executa-
das de maneira eficiente quando comparadas com as mesmas consultas executa-
das em um ambiente OLTP. 
2 SERVIDORES E CLIENTES OLAP 
Um Servidor OLAP é o ambiente no qual um banco de dados multidi-
mensional é implementado. Durante a criação de um servidor OLAP é considera-
da a modelagem, bem como a arquitetura necessária para implementá-la, desde 
a arquitetura até o sistema gerenciador de banco de dados. 
Segundo Mazzola (2002), um servidor OLAP é uma ferramenta de alta ca-
pacidade, utilizada por múltiplos usuários e projetada especificamente para dar 
suporte ao acesso aos dados armazenados em ambientes de consultas multidimen-
sionais. O projeto do servidor e a estrutura dos dados são otimizados para que 
facilitem a rapidez das consultas que utilizam os dados de um Data Warehouse, de 
maneira que a recuperação das informações receba orientações de flexibilidade e 
transformação de dados brutos sejam firmados em relações sobre fórmulas.
Você pode compreender um servidor OLAP como toda arquitetura uti-
lizada para permitir o armazenamento de dados em um Data Warehouse, de tal 
140
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
modo que os dados possam ser consumidos por meio de consultas. As aplicações 
que consomem tais dados são denominadas Clientes OLAP.
Qualquer programa que consiga se conectar a um servidor OLAP e consu-
mir os dados pode ser considerado um cliente OLAP. Assim, podemos considerar 
que esta classe de software inclui todos os programas que de algum modo se co-
nectam ao banco de dados multidimensional e realizam consultas (RIBEIRO, 2010). 
Um Servidor OLAP é um sistema de manipulação de dados de alta capa-
cidade e de multiutilização, especificamente desenhado para suportar e operar 
com estruturas de dados multidimensionais. Uma estrutura multidimensional é 
formada de modo que todos os dados sejam localizados e acedidos com base na 
interseção dos membros das dimensões que definem esse dado específico. O de-
senho do servidor e a estrutura dos dados são otimizados para obtenção rápida 
de qualquer informação específica, assim como para cálculos rápidos e flexíveis 
e, ainda, para a transformação de dados fonte com base em fórmulas de cálculo. 
O Servidor OLAP pode, também, tratar fisicamente a informação multidi-
mensional processada, de forma a dar tempos de resposta rápidos e consistentes 
aos utilizadores finais, ou pode carregar as estruturas de dados em tempo real a 
partir de Bases de Dados relacionais ou outras, ou oferecer uma seleção de ambas. 
Dado o estado tecnológico atual e a exigência, da parte dos utilizadores finais, de 
tempos de resposta rápidos e consistentes, a opção de colocar os dados multidi-
mensionais no Servidor OLAP é a mais utilizada (OLAP COUNCIL, 1995).
2.1 TIPOS DE SERVIDORES OLAP
Segundo Nogueira (2017), o OLAP é o processamento on-line de dados 
com foco em análise para tarefas de tomada de decisão. As análises ocorrem em 
tempo real, ou seja, são executadas de maneira eficiente quando comparadas com 
as mesmas consultas executadas nos sistemas transacionais. Servidores OLAP 
sempre empregam uma visão multidimensional dos dados, fazendo com que haja 
grande aplicabilidade quando integrados a bancos de dados multidimensionais.
2.1.1 ROLAP – Relational On Line Analytical Processing
Partindo do nome, nessa implementação, o servidor para manipular os 
dados é implementado utilizando um sistema gerenciador de banco de dados 
relacional. Durante a implementação, o servidor é constituído de uma camada de 
interface entre o modelo relacional e o modelo multidimensional, pois transforma 
as requisições multidimensionais do usuário em rotinas de acesso às tabelas que 
armazenam os dados. Sua vantagem é a eficiência no armazenamento de dados 
esparsos e o segredo está na modelagem dos dados. 
TÓPICO 2 | OPERAÇÕES E SERVIDORES OLAP
141
FIGURA 16 – FUNCIONAMENTO ROLAP
FONTE: Adaptada de Shigunov (2007)
Segundo Shigunov (2007), um servidor ROLAP não tem dados pré-calcu-
lados. Intercepta a consulta e apresenta a questão para o banco de dados relacio-
nal com o objetivo de obter os dados que respondem à questão. Em algumas si-
tuações, é mais lento que a tecnologia MOLAP. Adequado para grandes volumes 
de dados e necessidade de dados detalhados. Recomendado quando os usuários 
não sabem exatamente o que vão perguntar ao longo do tempo. 
2.1.2 MOLAP – Multidimensional On Line Analytical 
Processing
Esta implementação é específica para a multidimensionalidade e para isso 
armazena e executa operações diretamente sobre uma matriz de dados. Se os da-
dos não forem esparsos, esses servidores são mais eficientes em armazenamento 
e recuperação do que os servidores ROLAP, uma vez que sua arquitetura é proje-
tada especificamentepara este fim.
FIGURA 17 – FUNCIONAMENTO MOLAP
FONTE: Adaptada de Shigunov (2007)
Segundo Shigunov (2007), a arquitetura MOLAP contém dados pré-cal-
culados, considerando todas as possíveis respostas para um dado conjunto de 
questões. Propicia bom desempenho, independentemente da quantidade de di-
mensões da consulta. Algumas alterações levam à necessidade de recalcular o 
banco de dados. Cubos podem ficar muito grandes à medida que novas dimen-
sões e dados detalhados são acrescentados. Recomendado quando os usuários 
têm problemas dentro de um escopo.
142
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
2.1.3 HOLAP – Hybrid On Line Analytical Processing
O termo híbrido está relacionado à mistura de abordagens. Neste conceito, 
quando se fala em um servidor HOLAP (Hybrid On Line Analytical Processing), 
ou seja, processamento analítico on-line híbrido, estamos falando da mistura das 
técnicas empregadas pelos servidores ROLAP e MOLAP. 
FIGURA 18 – FUNCIONAMENTO HOLAP
FONTE: Adaptada de Shigunov (2007)
Os servidores HOLAP adotam uma forma de armazenamento em dois 
níveis, um para dados densos (um registro associado a cada entrada do índice), 
que são colocados em matrizes, e outro para dados esparsos (um registro asso-
ciado a cada entrada do índice), que são alocados em tabelas, ou seja, torna-se 
uma aplicação robusta, integrando tanto matrizes quanto tabelas, armazenando 
o modelo multidimensional, o que demanda um maior requisito de equipe para 
desenvolvê-lo.
2.1.4 DOLAP – Desktop On Line Analytical Processing
O DOLAP tem como objetivo a execução de consultas em computado-
res pessoais, este tipo de OLAP não se refere à implementação do armazena-
mento, mas sim à distribuição de dados. Essa abordagem tem como objetivo 
otimizar as consultas através do compartilhamento dos dados do servidor 
com quem o conecta.
Utilizar uma abordagem DOLAP não significa que não haverá um servi-
dor centralizado, mas que para economizar recursos computacionais, os dados 
serão enviados para a máquina que está fazendo a requisição. 
TÓPICO 2 | OPERAÇÕES E SERVIDORES OLAP
143
FIGURA 19 – FUNCIONAMENTO HOLAP
FONTE: <https://www.slideshare.net/Aneeb_Khawar/cs437-lecture-13>. Acesso em: 9 mar. 2020.
Durante a realização de uma consulta utilizando a estratégia DOLAP, o 
conjunto de dados multidimensionais deve ser criado no servidor e uma cópia é 
transferida para o desktop. Utilizando esta técnica é possível trazer portabilidade 
aos usuários OLAP que não possuem acesso direto ao servidor, no entanto, tem 
que se ter um cuidado com o período da análise, uma vez que o ambiente Desk-
top não pode ficar diferente do servidor OLAP. 
2.1.5 O Cubo OLAP
Quando desenvolvemos um modelo de dados multidimensional, nele 
adicionamos dimensões. Uma dimensão, além de alimentar uma Tabela Fato, 
também permite que as consultas sejam realizadas, de tal modo que possam ser 
analisadas por diversas perspectivas, ou seja, é possível explorar os dados das 
dimensões para explorar a multidimensionalidade do modelo criado. 
O cubo OLAP, também chamado de cubo de dados, é uma representação 
abstrata da representação analítica dos dados que estão armazenados multidi-
mensionalmente. Pode-se dizer que o cubo OLAP é uma metáfora visual para 
como os dados são vistos de acordo com as dimensões.
Quando falarmos do cubo OLAP você pode imaginar um cubo mágico 
que você entregará nas mãos de um tomador de decisão. Com o cubo na mão, o 
usuário de um Data Warehouse poderá manipulá-lo, girar, retirar pequenos tre-
chos e, principalmente, poderá olhar por seus diversos lados.
 
144
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
FIGURA 20 – MANIPULANDO UM CUBO
FONTE: <http://bit.ly/2UcbW3H>. Acesso em: 9 mar. 2020.
É importante compreender que um cubo de dados pode representar tanto 
o modelo multidimensional por inteiro ou consultas que explorem suas dimen-
sões. A Figura 21 mostra o exemplo do modelo multidimensional em sua repre-
sentação em forma de cubo, note que essa é uma das possíveis representações, 
como o cubo é uma metáfora, a figura apresenta apenas o número possível para 
este, três dimensões. Cada cubo representa um valor de venda, e as faces do cubo 
representam as dimensões de análise: produto, fornecedor e tempo. 
FIGURA 21 – REPRESENTAÇÃO MULTIDIMENSIONAL NA FORMA DE UM CUBO DE DADOS
FONTE: Adaptada de Nogueira (2019)
Quando falamos de análise multidimensional por meio de um cubo de 
dados, as análises também podem ser feitas por intermédio de um cuboide. Um 
cuboide é uma combinação de dimensões, é uma maneira visual de compreen-
der a análise multidimensional dos dados, principalmente quando existe mais de 
uma dimensão de análise. 
TÓPICO 2 | OPERAÇÕES E SERVIDORES OLAP
145
Para compreender melhor os cuboides, consideraremos os seguintes 
cubos de dados que em conjunto formam quatro dimensões. 
FIGURA 22 – CUBOS 4D
FONTE: <http://professor.pucgoias.edu.br/SiteDocente/admin/arquivosUpload/5587/material/
OLAP.pdf>. Acesso em: 9 mar. 2020.
Ao analisar os cubos é possível perceber a combinação dos cubos de da-
dos que contêm quatro (4) dimensões (tempo, item, local e fornecedor), isto im-
plica que para realizar a análise serão 16 cuboides gerados a partir dele, conforme 
mostra a Figura 23.
FIGURA 23 – CUBOIDES
FONTE: <http://professor.pucgoias.edu.br/SiteDocente/admin/arquivosUpload/5587/material/
OLAP.pdf>. Acesso em: 9 mar. 2020.
http://professor.pucgoias.edu.br/SiteDocente/admin/arquivosUpload/5587/material/OLAP.pdf
http://professor.pucgoias.edu.br/SiteDocente/admin/arquivosUpload/5587/material/OLAP.pdf
146
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
Um cuboide básico possui os dados mais detalhados, exceto os próprios 
dados de origem; é composto de todas as dimensões, como tempo, item, localiza-
ção, fornecedor. Por exemplo, um usuário pode explorar o cuboide base (tempo, 
item, localização, fornecedor) ao longo da dimensão “fornecedor” para cuboide 
(hora, item, local). Neste caso, o cuboide base é o cuboide parental, ou seja, que 
representa uma hierarquia e um cuboide 3D (tempo, item, localização) que repre-
senta uma hierarquia pai → filho.
2.1.6 Operações OLAP
Aprendemos que os servidores OLAP são arquiteturas para providenciar o 
melhor desempenho possível nas consultas em um ambiente de Data Warehouse. 
Tradicionalmente, os servidores permitem a exploração dos dados me-
diante à realização das operações OLAP, operam aumentando e diminuindo a 
granularidade dos dados. Tais operações são: Slice, Dice, Drill-Down e Roll-Up.
2.1.7 Slice
Essa operação significa fatiar, deste modo retorna valores específicos de 
uma dimensão do cubo, pode-se dizer que a fatia é uma parte do cubo a ser visu-
alizado, seleciona uma dimensão específica de um determinado cubo e fornece 
um novo subcubo. 
A Figura 24 mostra um exemplo de uma operação Slice, em que inicial-
mente existem três dimensões (cidade, tempo e itens) e após a realização da ope-
ração foi aplicado um filtro de tempo selecionando apenas o bimestre Q1, assim, 
fatiou-se mostrando apenas duas dimensões. 
TÓPICO 2 | OPERAÇÕES E SERVIDORES OLAP
147
FIGURA 24 – OPERAÇÃO DE SLICE 
FONTE: Adaptada de Han, Pei e Kamber (2011)
2.1.8 Dice
Dice, no contexto da realização de operações e manipulação do cubo 
OLAP, significa “parte de um cubo”. Esta operação são slices consecutivos, per-
mitindo gerar diversos cortes no cubo, gerando um subcubo. No exemplo da Fi-
gura 25, veremos que o círculo do meio representa um conjunto de filtros, tais 
filtros podem ser compreendidos como slices, que em conjunto formam um dice. 
148
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
FIGURA 25 – OPERAÇÃO DE DICE
FONTE: Adaptada de Han, Pei e Kamber (2011)
2.1.9 Drill-Down
O operador Drill-Down realiza uma navegação pelos dados de um mode-
lo multidimensional, obtendo um maior nível de detalhamento, aproximando-se 
da granularidade mínima. Ao aplicar essa operação, está descendouma hierar-
quia de conceitos para uma dimensão. 
A Figura 26, assim como nos exemplos anteriores, mostra um cubo inicial 
quando realizada uma operação de Drill-Down, que expande os dados do cubo, 
trazendo as mesmas informações, que antes eram mostradas por bimestre, agora 
organizadas por meses. Pode-se dizer que a operação de Drill-Down expande o 
cubo de dados. 
TÓPICO 2 | OPERAÇÕES E SERVIDORES OLAP
149
FIGURA 26 – OPERAÇÃO DE DRILL-DOWN
FONTE: Adaptada de Han, Pei e Kamber (2011)
2.1.10 Roll-Up
Uma operação que realiza o oposto do drill-down, o roll-up sumariza as 
informações, diminuindo o nível de detalhes. A operação de roll-up executa a 
agregação em um cubo de dados. A Figura 27 mostra que a hierarquia está defi-
nida em palavras e textos. 
A operação de roll-up, no exemplo, agrega os dados de palavras para tex-
tos, gerando um cubo resultante com o total de ocorrências por textos, ao invés do 
cubo inicial que agrupava por palavra.
Para que você tenha uma visão prática de como as consultas acontecem de 
acordo com as operações OLAP, disponibilizamos alguns exemplos práticos em:
https://colab.research.google.com/drive/1ki6HAEKwTFWgVHHeFUcodJbbyFdz61YL.
DICAS
150
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
FIGURA 27 – OPERAÇÃO DE ROLL-UP
FONTE: Adaptada de Han, Pei e Kamber (2011)
Uma vez conhecidos os operadores OLAP, podemos explorar as dimen-
sões de um Data Warehouse. Essas operações são executadas no servidor OLAP 
e consumidas pelas ferramentas de visualização de dados.
Hierarquias: as hierarquias descrevem a lógica dos relacionamentos entre os 
dados, é a base para a navegação entre os diferentes níveis de detalhe em uma estrutura 
multidimensional (HOKAMA, 2004). 
IMPORTANT
E
TÓPICO 2 | OPERAÇÕES E SERVIDORES OLAP
151
FIGURA 28 – EXEMPLO DE HIERARQUIA
FONTE: Adaptada de Hokama (2004)
152
RESUMO DO TÓPICO 2
Neste tópico, você aprendeu que:
• Existem servidores e clientes OLAP.
• É possível implementar diversos tipos de servidores OLAP.
• O cubo de dados é uma metáfora visual para o modelo multidimensional.
• Há operações de análise de dados realizadas em cima de um cubo de dados.
153
AUTOATIVIDADE
1 As ferramentas OLAP são geralmente uma das três arquiteturas: ROLAP 
– Relational OLAP, MOLAP – Multidimensional OLAP e HOLAP – Hybrid 
OLAP. ROLAP realiza o processamento do Data Warehouse em uma estrutu-
ra física do modelo relacional e modelada dimensionalmente.
FONTE: <https://www.ufsm.br/orgaos-suplementares/cpd/wp-content/uploads/
sites/350/2018/07/cisti2008.pdf>. Acesso em: 9 mar. 2020.
Assinale a alternativa CORRETA sobre qual tipo de servidor utiliza o armaze-
namento físico multidimensional.
a) ROLAP.
b) MOLAP.
c) FOLAP.
d) OLAR.
2 OLAP é uma categoria de software específica para realizar processamento 
analítico dos dados de Data Warehouse, de maneira que este processamento 
deve ocorrer com alto desempenho, consistência e interatividade e auxiliar a 
tomada de decisão em uma organização através da interpretação desses da-
dos em várias visões multidimensionais.
FONTE: <https://www.ufsm.br/orgaos-suplementares/cpd/wp-content/uploads/
sites/350/2018/07/cisti2008.pdf>. Acesso em: 9 mar. 2020.
Assinale a alternativa CORRETA sobre qual tipo de servidor utiliza o armaze-
namento físico relacional.
a) ROLAP.
b) MOLAP.
c) FOLAP.
d) OLAR.
3 Em ambientes de Data Warehouse o principal objetivo é a realização de 
análises, por isso o processamento dos dados é feito através de servidores e 
operações OLAP (On Line Analytical Processing – Processamento Analítico 
On-line). Os servidores OLAP processam os dados analiticamente, exploran-
do a multidimensionalidade do banco de dados em que os dados estão ar-
mazenados. No que se refere à implementação de um servidor OLAP, eles 
podem ser ROLAP, MOLAP, DOLAP e HOLAP. 
https://www.ufsm.br/orgaos-suplementares/cpd/wp-content/uploads/sites/350/2018/07/cisti2008.pdf
https://www.ufsm.br/orgaos-suplementares/cpd/wp-content/uploads/sites/350/2018/07/cisti2008.pdf
154
Assinale a alternativa CORRETA sobre o HOLAP.
 
a) Nos servidores HOLAP o H tem como significado Híbrido, ou seja, é uma 
tecnologia que é implementada com a junção dos servidores ROLAP e MO-
LAP, tendo características pertencentes às outras duas arquiteturas.
b) Essa implementação é específica para a multidimensionalidade e para isso 
armazena e executa operações diretamente sobre uma matriz de dados.
c) Esse tipo de OLAP não se refere à implementação do armazenamento, mas 
à distribuição de dados. Essa abordagem tem como objetivo otimizar as con-
sultas através do armazenamento no computador do usuário.
d) Partindo do nome, nessa implementação, o servidor para manipular os da-
dos será implementado utilizando um sistema gerenciador de banco de dados 
relacional.
4 Tradicionalmente, os servidores permitem a exploração dos dados median-
te a realização das operações OLAP e operam aumentando e diminuindo a 
granularidade dos dados. Assinale a alternativa CORRETA que contenha tais 
operações:
a) Slice, Delete, Roll-up e Roll-Down.
b) Slice, Dice, Roll-up e Drill-Down.
c) Slice, Dice, Insert e Update. 
d) Insert, Update, Roll-up e Roll-Down.
5 Os Data Warehouses podem ser explorados por diversas perspectivas, ou 
seja, explorando a multidimensionalidade do modelo criado. O cubo de da-
dos é uma representação abstrata da representação analítica dos dados arma-
zenados multidimensionalmente. 
Assinale a alternativa CORRETA que contenha o conceito de cuboide. 
a) Um cuboide é uma combinação de dimensões, é uma maneira visual de 
compreender a análise multidimensional dos dados. Um cuboide básico pos-
sui os dados mais detalhados, exceto os próprios dados de origem.
b) Um cuboide é uma ferramenta gráfica para modelagem de banco de dados. 
Existem diversos recursos, desde a simples modelagem e geração do banco de 
dados, até mesmo a conexão com engenharia reversa para diversos SGBDs. 
c) Um cuboide é muito próximo do que é conhecido da modelagem tradicio-
nal de banco de dados, uma vez que durante sua construção são levadas em 
consideração as formas normais.
d) Um cuboide torna o carregamento dos dados menos complexo, mas o uso 
dessa estrutura para consulta é difícil, pois envolve muitas tabelas e junções.
155
TÓPICO 3
FERRAMENTAS DE DASHBOARDS
UNIDADE 3
1 INTRODUÇÃO
Durante nosso livro você aprendeu que os dados são coletados, prepara-
dos, modelados, armazenados, aplicando todo um conjunto de métodos e ferra-
mentas com um único objetivo final: auxiliar o tomador de decisões. 
A implementação de um sistema de Business Intelligence em uma orga-
nização tem como objetivo fornecer insights para suportar as mais diversas de-
cisões de negócio, porém, tudo que foi desenvolvido até esse momento não será 
visto pelo usuário final, afinal para ele só uma coisa interessa: o resultado. 
Quando olhamos para um Data Warehouse, os Dashboards pertencem à 
camada de ferramentas de visualização dos dados. Uma vez os dados estando 
consolidados e armazenados, tais ferramentas são responsáveis por consumir tais 
dados e apresentar para o usuário final. 
Segundo Nogueira (2019), os Dashboards, algumas vezes chamados de 
Business Intelligence Dashboards (principalmente no idioma inglês), independen-
te de nomenclatura, têm como função sua própria tradução literal: painel. Para 
compreender melhor sobre isso, usaremos a essência de um painel, pegue como 
exemplo o painel de um carro, ou até melhor, de um avião. Este painel tem uma im-
portante função, mostrar tudo que está acontecendo durante o percurso, a posição 
geográfica de onde está, o status do combustível, o funcionamento das peças, entre 
muitas outras informações. Você até pode navegar sem um painel, mas sem dúvi-
da que utilizando-se dele é possível analisar a viagem por diversas perspectivas e 
tomar as melhores decisões, que o farão ter a melhor viagem possível.
FIGURA 29 – PAINEL DE DADOS X PAINEL DE UM AVIÃO
FONTE: Adaptada de Nogueira (2019)
UNIDADE 3| VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
156
No cenário corporativo, um Dashboard tem o mesmo objetivo de um pai-
nel de voo: mostrar tudo que está acontecendo em uma organização, o mais pró-
ximo do tempo real possível. 
Quando se imagina uma empresa que utiliza um Data Warehouse para 
armazenar seus dados, você pode imaginar que na sala da diretoria ou do CEO 
haverá TVs que estarão mostrando dados em tempo real sobre todos os setores 
da organização. 
FIGURA 30 – DASHBOARDS CORPORATIVOS
FONTE: <https://www.datapine.com/blog/tv-dashboard-software-for-office-display-design/>. 
Acesso em: 9 mar. 2020.
No processo de desenvolvimento de um Data Warehouse é comum a ca-
mada de visualização dos dados, principalmente quando se pensa em mostrar 
Dashboards com resultados. Existem ferramentas consolidadas no mercado, va-
mos conhecer algumas delas a seguir.
2 PENTAHO
O Pentaho é uma suíte de ferramentas que tem seu nome diretamente 
ligado ao processo de Business Intelligence e Data Warehouse. Foi desenvolvido 
em 2004 pela então Pentaho Corporation, era inicialmente um conjunto de ferra-
mentas separadas. Este software foi considerado uma das melhores aplicações 
para inteligência empresarial em 2008. 
Ainda que o carro-chefe da empresa seja o Pentaho Data Integration, uti-
lizado durante o processo de ETL, a empresa possui ferramentas para todas as 
camadas de um Data Warehouse. Segundo Ferreira et al. (2010), todos esses recur-
TÓPICO 3 | FERRAMENTAS DE DASHBOARDS
157
sos podem ser combinados e acionados sequencialmente para criação de soluções 
mais sofisticadas. Além disso, a plataforma executa todas as soluções de Business 
Intelligence como serviços e, por isso, é possível prover acesso às soluções para 
sistemas externos, via Web Services e outras fontes de dados.
Dentre suas ferramentas, o Pentaho conta com o Pentaho Business, uma 
ferramenta utilizada para conectar-se ao modelo multidimensional e gerar gráficos 
organizacionais. A Figura 31 mostra a tela inicial do Pentaho Business na versão 8.2, 
a versão atual da ferramenta, que além das funcionalidades já citadas conta com 
ferramentas para Big Data e IoT (Internet of Things – Internet das Coisas). 
FIGURA 31 – PÁGINA PRINCIPAL DO PENTAHO BUSINESS
FONTE: O autor 
O Pentaho tem uma interface bem amigável, na tela vista anteriormente, 
uma vez clicado em New existem opções de relatórios, dentre os quais os Dashbo-
ards. O primeiro item para criar um Dashboard é selecionar um data source, ou 
fonte de dados, você pode até utilizar diversos, mas tem de realizar a integração 
entre eles antes da criação com o recurso que a própria ferramenta provê.
 
A Figura 32 apresenta a tela de criação de Dashboards com dois gráficos 
distintos, um de valores de venda por produto e um outro que contém vendas 
dispersas geograficamente. Note que na aba inferior é possível selecionar um ob-
jeto, que é um gráfico específico, e nos parâmetros podem ser aplicados filtros 
que alteram a exibição dos gráficos de acordo com parâmetros de entrada. 
UNIDADE 3 | VISUALIZAÇÃO DOS DADOS: CONSTRUÇÃO DE DASHBOARDS
158
FIGURA 32 – GERAÇÃO DE DASHBOARDS COM PENTAHO BUSINESS
FONTE: O autor
2.1 POWER BI
Pioneira em softwares de escritórios, a Microsoft não fica de fora quando o 
tema é ferramenta para tomada de decisões. Uma de suas ferramentas que tem to-
mado conta dos escritórios junto ao Excel em todo mundo é o Microsoft Power BI.
O projeto inicial do Power Bl foi desenvolvido por Ron George no verão 
de 2010, nomeado Project Crescent e teve sua primeira versão disponibilizada 
para download em 2011, com recursos do banco de dados Microsoft, o Microsoft 
SQL Server. Mais tarde recebeu o nome atual, Power BI, tendo como objetivo se 
tornar um componente do suíte de aplicativos para escritório Office 365. 
FIGURA 33 – POWER BI TELA INICIAL
FONTE: O autor 
TÓPICO 3 | FERRAMENTAS DE DASHBOARDS
159
O Power BI tem se destacado principalmente pela sua fácil integração 
com bancos de dados relacionais, principalmente com o Microsoft SQL Server 
(sistema gerenciador de banco de dados pertencente à Microsoft), outros pontos 
que podemos até notar na figura que apresenta a tela inicial do programa é o 
suporte e a documentação. A ferramenta tem tomado conta do mercado por ter 
uma gama de informação on-line, o que auxilia muito os usuários novos e antigos 
a utilizar os recursos do Power BI. 
FIGURA 34 – POWER BI - EXEMPLO DE DASHBOARD
FONTE: O autor 
Saiba como dar os primeiros passos para trabalhar com a ferramenta Microsoft 
Power BI. Disponível em: https://www.devmedia.com.br/microsoft-power-bi-primeiros-
-passos/38128.
DICAS
160
RESUMO DO TÓPICO 3
Neste tópico, você aprendeu que:
• Os dashboards são utilizados para realizar análises de dados.
• Existem diversas ferramentas para criação de dashboards.
• A camada de visualização de um Data Warehouse é responsável por consumir 
dados e suportar decisões.
• As principais ferramentas de Dashboard do mercado são o Pentaho e o Power BI.
161
AUTOATIVIDADE
1 As informações mais importantes da sua organização devem estar sempre 
disponíveis de forma rápida e prática. Com uma boa ferramenta de Business 
Intelligence, é possível visualizar claramente as demandas problemáticas para 
o seu negócio. Por meio das plataformas é possível configurar rapidamente a 
sua ferramenta de BI e a exibição das informações consolidadas na forma de 
Dashboards. 
FONTE: <https://farolbi.com.br/a-importancia-do-dashboard-em-ferramentas-de-business-
intelligence/>. Acesso em: 9 mar. 2020.
Assinale a alternativa CORRETA que contenha ferramentas de Dashboards.
a) Pentaho Business e Power BI.
b) Pentaho Data Integration e SQL.
c) Pentaho Business e Pentaho Data Integration. 
d) SQL Server e Oracle.
2 Você estudou diversas arquiteturas de criação de um Data Warehouse. Com 
o objetivo de compreender a aplicação de um Dashboard inserido no contexto 
de Data Warehouse, projete a arquitetura de Kimball, inserindo o Power BI 
em sua devida camada. 
R.:
162
163
REFERÊNCIAS
ABREU, G. O. L. de. Big Data: como extrair volume, variedade, velocidade e 
valor da avalanche de informação cotidiana. Revista Temática, [on-line], v. 10, 
n. 11, nov. 2014. Disponível em: https://periodicos.ufpb.br/index.php/tematica/
article/view/21510. Acesso em: 1º mar. 2020.
ALMEIDA, M. B. Uma introdução ao XML, sua utilização na Internet e alguns con-
ceitos complementares. Ciência da informação, Brasília, v. 31, n. 2, p. 5-13, 2002.
AWS. AWS Glue. 2020. Disponível em: https://aws.amazon.com/pt/glue/. Aces-
so em: 10 jan. 2020.
BITWISE. Traditional ETL vs ELT on Hadoop. 2020. Disponível em: https://
www.bitwiseglobal.com/blogs/traditional-etl-vs-elt-on-hadoop/. Acesso em: 2 
jan. 2020.
BOTELHO, F. R.; RAZZOLINI FILHO, E. Conceituando o termo Business In-
telligence: origem e principais objetivos. Sistemas, Cibernética e Informática, 
[on-line], v. 11, n. 1, 2014. 
BRUZAROSCO, D. et al. Criando Data Warehouse com o modelo dimensional. 
Acta Scientiarum. Technology, v. 22, p. 1389-1397, 2000.
CAMPOS, S. R. Validação de dados em sistemas de Data Warehouse através de 
índice de similaridade no processo de ETL e mapeamento de trilhas de audi-
toria utilizando indexação ontológica. Dissertação de Mestrado em Engenharia 
Elétrica. Departamento de Engenharia Elétrica. Faculdade de Tecnologia. Brasí-
lia: Universidade de Brasília, 2013.
CANALTECH. O que significa e qual a importância do SCD no Data Wa-
rehouse. 2014. Disponível em: https://canaltech.com.br/infra/O-que-significa-e-
-qual-a-importancia-do-SCD-no-Data-Warehouse/. Acesso em: 20 jan. 2020. 
CARVALHO, G. T. de. Aplicação de práticas ágeis na construção de Data Wa-
rehouse evolutivo. Tese de Doutorado. São Paulo: Universidade de São Paulo. 2009.
CARVALHO, I. M. Contribuições das tecnologias KDD e DW como ferramentas 
de gestão do conhecimento aplicadas ao processo de compras do governo eletrô-
nico. Revista Democracia Digital e Governo Eletrônico, [on-line],v. 1, n. 2, 2010.
CLARO, D. B. Dados estruturados, semiestruturados e não estruturados. 2020. 
Disponível em: https://docplayer.com.br/878315-Prof-daniela-barreiro-claro.
html. Acesso em: 1º jan. 2020.
https://aws.amazon.com/pt/glue/
https://canaltech.com.br/infra/O-que-significa-e-qual-a-importancia-do-SCD-no-Data-Warehouse/
https://canaltech.com.br/infra/O-que-significa-e-qual-a-importancia-do-SCD-no-Data-Warehouse/
164
CODD, E. F. A relational model of data for large shared data banks. 1983. 
Disponível em: https://dl.acm.org/doi/10.1145/357980.358007. Acesso em: 1º mar. 
2020. 
COMPUTERWORLD. Avanço da nuvem traz oportunidades de crescimen-
to em TI, aponta Gartner. 2020. Disponível em: https://computerworld.com.
br/2019/03/31/gartner-destaca-oportunidades-de-crescimento-com-avanco-da-
-nuvem/. Acesso em: 2 jan. 2020.
COMPUTERWORLD. Hadoop ou Spark? Veja qual se aplica melhor para a sua 
empresa. 2016. Disponível em: https://computerworld.com.br/2016/07/11/hado-
op-ou-spark-veja-qual-se-aplica-melhor-para-sua-empresa/. Acesso em: 2 jan. 
2020.
CORREIA, M. Armazenamento e Mineração de Dados. Kenya: African Virtual 
Universit, 2018.
DEVENS, R. M. Cyclopaedia of commercial and business anecdotes. New 
York: Appleton and company, 1864.
ELMASRI, R. et al. Sistemas de banco de dados. São Paulo: Pearson, 2005.
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 6. ed. São Paulo: 
Person, 2011.
FAVARETTO, F. Ambiente de Data Warehouse para análise de algumas medi-
das utilizadas na administração da produção. Revista da FAE, Curitiba, v. 8, n. 
2, 2005.
FERREIRA, J. et al. O processo ETL em sistemas Data Warehouse. 2010a. 
Disponível em: https://www.researchgate.net/publication/265195317_O_Proces-
so_ETL_em_Sistemas_Data_Warehouse. Acesso em: 12 fev. 2020.
FERREIRA, M. et al. Um estudo de caso com análise comparativa entre ferra-
mentas de BI livre e proprietária. Porto Alegre: SBC, 2010b.
FILIPPI, L. Admanager: gerenciador de publicidade móvel. 2017. Disponível 
em: http://www.repositorio.jesuita.org.br/handle/UNISINOS/6963?show=full. 
Acesso em: 1º mar. 2020.
HAMBORG, F. et al. News-please: a generic news crawler and extractor. 15th 
International Symposium of Information Science, [on-line], p. 218-223, 2017.
HAN, J.; PEI, J.; KAMBER, M. Data mining: concepts and techniques. Rio de 
Janeiro: Elsevier, 2011.
https://www.researchgate.net/publication/265195317_O_Processo_ETL_em_Sistemas_Data_Warehouse
https://www.researchgate.net/publication/265195317_O_Processo_ETL_em_Sistemas_Data_Warehouse
http://www.repositorio.jesuita.org.br/handle/UNISINOS/6963?show=full
165
HITACHI. Hitachi Data Systems conclui a compra da Pentaho, maior aquisi-
ção de uma empresa de Big Data até hoje. 2015. Disponível em: https://www.
hitachivantara.com/pt-br/news-resources/press-releases/2015/br150601.html. 
Acesso em: 10 jan. 2020.
HOKAMA, D. D. B. A modelagem de dados no ambiente Data Warehouse. São 
Paulo: Universidade Presbiteriana Mackenzie, 2004.
INMON, W. H. Building the data warehouse. New Jersey: John Wiley & Sons, 
2005.
INTERNET LIVE STATS. FAQ. 2020. Disponível em: https://www.internetlives-
tats.com/faq/. Acesso em: 12 fev. 2020.
KIMBALL, R. et al. The data warehouse lifecycle toolkit. New Jersey: John 
Wiley & Sons, 2008.
KIMBALL, R.; CASERTA, J. The data warehou se ETL toolkit: practical techni-
ques for extracting, cleaning, conforming, and delivering data. New Jersey: John 
Wiley & Sons, 2011.
KIMBALL, R.; ROSS, M. The data warehouse toolkit: the complete guide to 
dimensional modeling. New Jersey: John Wiley & Sons, 2011.
LIMA, M. R. F. Desenvolvimento de um Data Mart e Automatização do Pro-
cesso ETL no contexto da Produção Acadêmica do CEULP/ULBRA. Palmas, 
TO: Centro Universitário Luterano de Palmas, 2019.
LISBOA FILHO, J.; IOCHPE, C. Um estudo sobre modelos conceituais de dados 
para projeto de bancos de dados geográficos. Revista IP - Informática Pública, 
v. 1, n. 2, p. 37-90, 1999.
LYRA, A. L. B. Uso de um processo ETL em um modelo Data Warehouse para 
a geração de Dashboards de indicadores de redes de telefonia celular. Tese de 
Doutorado. Rio de Janeiro: Universidade Federal do Rio de Janeiro, 2016.
MARQUESONE, R. Big Data: técnicas e tecnologias para extração de valor dos 
dados. São Paulo: Casa do Código, 2016.
MAYER-SCHONBERGER, V.; CUKIER, K. Big data: como extrair volume, varie-
dade, velocidade e valor da avalanche de informação cotidiana. Rio de Janeiro: 
Elsevier, 2014.
MAZZOLA, I. S. Projeto de Data Warehouse dimensional. Programa de Pós-
-Graduação em Ciência da Computação. Florianópolis: UFSC, 2002.
https://www.hitachivantara.com/pt-br/news-resources/press-releases/2015/br150601.html
https://www.hitachivantara.com/pt-br/news-resources/press-releases/2015/br150601.html
https://www.internetlivestats.com/faq/
https://www.internetlivestats.com/faq/
166
MONTEIRO, A. V. G. et al. Uma aplicação de Data Warehouse para apoiar negó-
cios. Cadernos do IME - Série Informática, [on-line], v. 16, p. 48-58, 2004.
MOREIRA, J. P. C. L. M. et al. A construção de um sistema de armazenamento 
de dados no âmbito do sistema GIST98/EUROBUS. Tese de Mestrado. Porto: 
Universidade do Porto, 2000.
NAGABHUSHANA, S. Data Warehousing, OLAP and Data Mining. New De-
lhi, India: New Age International, 2006.
NASCIMENTO, M. B. MongoDB: um estudo teórico-prático do conceito de 
banco de dados NoSQL. 2020. Disponível em: encurtador.com.br/ckZ38. Acesso 
em: 1º jan. 2020.
NOGUEIRA, R. R. Análise de dados usando dashboards. Indaial: UNIASSEL-
VI, 2019.
NOGUEIRA, R. R. Arquitetura de coleta e armazenamento de dados: Hadoop e 
Spark. Indaial: UNIASSELVI, 2019.
NOGUEIRA, R. R. Newsminer: um sistema de data warehouse baseado em 
texto de notícias. 2017. Disponível em: https://repositorio.ufscar.br/handle/ufs-
car/9138. Acesso em: 1º mar. 2020.
NOGUEIRA, R. R. Passo a passo para a modelagem de dados. SQL Magazine, 
[on-line], v. 1, p. 15-25, 2016.
OLAP COUNCIL. OLAP and OLAP Server definitions. 1995. Disponível em: 
http://www.olapcouncil.org/research/glossaryly.htm. Acesso em: 26 fev. 2020.
PITON, R. Data Warehouse – O que é Tabela Fato (e seus tipos). 2017. Disponí-
vel em: https://rafaelpiton.com.br/blog/data-warehouse-tipos-fatos/. Acesso em: 
20 jan. 2020.
PITON, R. Tabela Dimensão: os 5 tipos que você deve conhecer. 2017. Dispo-
nível em: https://rafaelpiton.com.br/blog/data-warehouse-tipos-dimensoes/. 
Acesso em: 20 jan. 2020.
REINSEL, D.; GANTZ, J.; RYDNING, J. The digitization of the world: from 
edge to core - Data age 2025. 2018. Disponível em: https://www.seagate.com/
files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf. 
Acesso em: 1º mar. 2020.
RIBAS, W. A.; NODA, E.; MARQUES, D. BigPy: um sistema WEB para cap-
tura, tratamento e visualização de dados de defesa do consumidor utilizando 
Python. 2018. Disponível em: http://hto.ifsp.edu.br/portal/images/thumbnails/
images/IFSP/Cursos/Coord_ADS/Arquivos/TCCs/2018/TCC_WederAlvesRibas_
HT1320386.pdf. Acesso em: 1º mar. 2020.
https://rafaelpiton.com.br/blog/data-warehouse-tipos-fatos/
http://hto.ifsp.edu.br/portal/images/thumbnails/images/IFSP/Cursos/Coord_ADS/Arquivos/TCCs/2018/TCC_WederAlvesRibas_HT1320386.pdf
http://hto.ifsp.edu.br/portal/images/thumbnails/images/IFSP/Cursos/Coord_ADS/Arquivos/TCCs/2018/TCC_WederAlvesRibas_HT1320386.pdf
http://hto.ifsp.edu.br/portal/images/thumbnails/images/IFSP/Cursos/Coord_ADS/Arquivos/TCCs/2018/TCC_WederAlvesRibas_HT1320386.pdf
167
RIBEIRO, P. M. Open Source Data Warehousing e Business Intelligence. Dis-
sertação de Mestrado. Coimbra: Instituto Politécnico de Coimbra, 2010.
ROLO, L. C. P. Sistema de gestão e auditoria fiscal na nuvem. Tese de Dou-
torado. Escola Superior de Tecnologia. Castelo Branco: Instituto Politécnico de 
Castelo Branco, 2016. 
ROSSI, R. G. Análise de componentes principais em Data Warehouses. Tese de 
Doutorado. São Paulo: Universidade de São Paulo, 2017.
SALDANHA, R. Business Intelligence: análise sobre as soluções de BI e estudode caso usando Pentaho. Londrina: Universidade Estadual de Londrina, 2018.
SALLAI, F. SQL Join: entenda como funciona o retorno dos dados. 2014. Dispo-
nível em: https://www.devmedia.com.br/sql-join-entenda-como-funciona-o-re-
torno-dos-dados/31006. Acesso em: 1º mar. 2020.
SANTOS, C. A. et al. Um modelo de sistema de informação gerencial: vantagem 
competitiva no processo da logística reversa do óleo de cozinha. Research, So-
ciety and Development, v. 4, n. 1, p. 62-88, 2017.
SEGINFO. 41,6 bilhões de dispositivos de IoT gerarão 79,4 zettabytes de dados 
em 2025. 2020. Disponível em: https://seginfo.com.br/2019/06/26/416-bilhoes-de-
-dispositivos-de-iot-gerarao-794-zettabytes-de-dados-em-2025. Acesso em: 25 
jan. 2020.
SHIGUNOV, F. Uma aplicação OLAP sobre a Web para análise dos dados do 
vestibular da UFSC e diretrizes para a sua integração com GIS. Florianópolis: 
UFSC, 2007.
SITEWARE. O que é BI Business Intelligence? 2020. Disponível em: https://
www.siteware.com.br/gestao-estrategica/o-que-e-bi-business-intelligence/. 
Acesso em: 1º jan. 2020.
SOUIBGUI, M. et al. Data quality in ETL process: a preliminary study. Procedia 
Computer Science, [on-line], v. 159, p. 676-687, 2019.
SUTER, J. et al. Um Data Warehouse baseado no Twitter para análise de senti-
mento em língua portuguesa: estudo de caso das eleições de 2018. 2018. Dispo-
nível em: https://sol.sbc.org.br/index.php/erbd/article/view/8477. Acesso em: 1º 
mar. 2020.
TAURION, C. Big data. Rio de Janeiro: Brasport, 2013.
VALENTIM, M. L. P. et al. Inteligência competitiva em organizações: dado, 
informação e conhecimento. DataGramaZero, Rio de Janeiro, v. 3, n. 4, p. 1-13, 
2002.