1_modelagem_e_arquitetura_dw

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

W
BA
07
48
_v
1.
2
MODELAGEM E ARQUITETURA 
DO DW (DATA WAREHOUSE)
2019
Editora e Distribuidora Educacional S.A.
Avenida Paris, 675 – Parque Residencial João Piza
CEP: 86041-100 — Londrina — PR
e-mail: editora.educacional@kroton.com.br
Homepage: http://www.kroton.com.br/
Presidente
Rodrigo Galindo
Vice-Presidente de Pós-Graduação e Educação Continuada
Paulo de Tarso Pires de Moraes
Conselho Acadêmico
Carlos Roberto Pagani Junior
Camila Braga de Oliveira Higa
Carolina Yaly
Giani Vendramel de Oliveira
Juliana Caramigo Gennarini
Nirse Ruscheinsky Breternitz
Priscila Pereira Silva
Tayra Carolina Nascimento Aleixo
Coordenador
Nirse Ruscheinsky Breternitz
Revisor
Renata Maria Silva Costa
Wendel Brustolin
Editorial
Alessandra Cristina Fahl
Beatriz Meloni Montefusco
Daniella Fernandes Haruze Manta
Hâmila Samai Franco dos Santos
Mariana de Campos Barroso
Paola Andressa Machado Leal
Dados Internacionais de Catalogação na Publicação (CIP)
 Catarino, Iolanda Claudia Sanches
C357m Modelagem e arquitetura do DW (data warehouse)/
Iolanda Claudia Sanches Catarino, Marise Miranda -
 Londrina: Editora e Distribuidora Educacional S.A. 2019.
 156 p.
 
 ISBN 978-85-522-1536-3
 
 1. Big data. 2. Banco de dados. I. Catarino, Iolanda
 Claudia Sanches. II. Miranda, Marise. Título. 
 
CDD 000 
 Thamiris Mantovani CRB: 8/9491
© 2019 por Editora e Distribuidora Educacional S.A.
Todos os direitos reservados. Nenhuma parte desta publicação poderá ser 
reproduzida ou transmitida de qualquer modo ou por qualquer outro meio, 
eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer outro tipo de 
sistema de armazenamento e transmissão de informação, sem prévia autorização, 
por escrito, da Editora e Distribuidora Educacional S.A.
 3
SUMÁRIO
Apresentação da disciplina ......................................................................................04
Banco de Dados Transacionais versus Bancos de Dados Analíticos .................05
Conceitos básicos sobre Data Warehouse ..............................................................31
Data Marts ...................................................................................................................57
Modelagem de dados para um Data Warehouse ................................................81
Esquema Estrela e Esquema Floco de Neve .................................................. 110
Ferramentas de Dados em um Data Warehouse ..................................................131
Mineração de Dados em Data Warehouse .............................................................154
MODELAGEM E ARQUITETURA DO DW (DATA WAREHOUSE)
4
Apresentação da disciplina
A disciplina Modelagem e Arquitetura de Data Warehouse contempla 
a modelagem, a arquitetura com seus componentes e os tipos de 
ferramentas que integram um ambiente de Data Warehouse.
Assim, no primeiro tema da disciplina, são contextualizados os 
princípios, os elementos e as características dos bancos de dados 
transacionais e dos bancos de dados analíticos. No segundo e terceiro 
temas, são fundamentados os conceitos de Data Warehouse e Data Marts, 
abordando o ambiente, a arquitetura e a relação entre os componentes 
de um ambiente de Data Warehouse.
O quarto tema introduz a modelagem de dados para Data Warehouse, 
abordando um comparativo entre o Modelo Entidade Relacionamento 
(MER) com os princípios e a estrutura da modelagem multidimensional. 
O quinto tema compreende a representação da modelagem 
multidimensional para Data Warehouse, demonstrando e exemplificando 
as características, os elementos e a aplicação do Esquema Estrela 
(Star Schema) e do Esquema Floco de Neve (Snow Flake Schema), que é 
considerado uma extensão do Esquema Estrela.
O sexto tema introduz os fundamentos sobre o Processamento Analítico 
Online (Online Analytical Processing – OLAP) em comparação com o 
Processamento de Transações Online (Online Transaction Processing – 
OLTP); além disso, apresenta as operações OLAP e a classificação das 
ferramentas OLAP de acordo com a estratégia de armazenamento 
dessas ferramentas. O sétimo e último tema da disciplina aborda 
o processo de Descoberta de Conhecimento em Bases de Dados 
(Knowledge Discovery in Databases – KDD) e suas etapas, além dos 
fundamentos e das fases do processo de mineração de dados (Data 
Mining), enfatizando que a mineração de dados é considerada a principal 
atividade do processo KDD. Por fim, apresenta-se uma síntese dos 
principais métodos e técnicas aplicados nas ferramentas de Data Mining.
Banco de Dados Transacionais 
versus Bancos de Dados Analíticos 
Autora: Marise Miranda
Objetivos
• Reconhecer os contextos em que se aplicam os 
bancos de dados transacionais e os bancos de dados 
analíticos.
• Acompanhar a estrutura tecnológica e de dados que 
suporte as transações dos sistemas de informação.
• Escolher a estrutura tecnológica e de dados para 
suportar as atividades analíticas que envolvam áreas 
de conhecimento especializadas, como o apoio à 
tomada de decisão.
6
1. Consolidação de diferentes fontes de dados
Todos os dias, crescentes quantidades de dados são disponibilizadas 
nas organizações por meio de diversas fontes internas e externas 
e pela internet. A automação de serviços, como as vendas on-line, 
está constantemente produzindo e divulgando dados sobre bens de 
consumo e sobre as respectivas transações associadas a esse serviço.
Os comportamentos das pessoas são expostos constantemente 
em redes sociais, consolidando-se como uma fonte de dados. As 
preferências, novidades, datas festivas, entre outras informações, 
são incluídas pelo usuário. O uso de tecnologias integradas nos 
serviços por aplicativos gera enormes volumes de dados, como o 
uso de transações bancárias, a navegação na internet e a troca de 
informações digitais.
Todos esses dados gerados em larga escala, vindos de diferentes 
fontes, tanto externas quanto internas às empresas, formam um 
conjunto de dados, chamados, normalmente, de datasource, criando, 
quando reunidos em um único local, os sistemas de banco de dados. 
Os sistemas gerenciadores desses ambientes denominam-se Sistema 
de Gerenciamento de Banco de Dados (SGBD).
Esses conjuntos de dados podem ser formados por um arquivo, por 
um banco de dados específico em um Database Management System 
(DBMS) ou até mesmo por um feed de dados ativo. O SGBD ou DBMS 
são softwares que gerenciam a base de dados, retirando da aplicação do 
cliente o gerenciamento do acesso, a organização e a manipulação dos 
dados. Já os feeds de dados são fluxos de dados XML gerados a partir de 
uma fonte de dados on-line, sendo transmitidos para um documento ou 
aplicativo de destino.
7
Os dados podem estar localizados no mesmo computador que o 
programa ou em outro computador em algum lugar da rede. O conjunto 
de dados provenientes de diversas fontes deve ser modelado em 
uma certa estrutura para que possa ser armazenado, manipulado e 
recuperado. A necessidade de estruturar esse conjunto em um modelo 
de dados serve para explicar suas características de funcionamento e 
comportamento.
1.1 Modelo de dados
As fontes de dados são armazenadas segundo um modelo de banco de 
dados, organizados em uma estrutura lógica de um banco de dados, 
incluindo os relacionamentos, os tipos de dados e as restrições que 
determinam como eles podem ser armazenados e acessados. Os tipos 
de modelos de dados estão associados à tipologia, estando os mais 
comuns listados a seguir:
• Modelo de banco de dados hierárquico.
• Modelo relacional.
• Modelo de rede.
• Modelo de banco de dados orientado a objetos.
• Modelo de relacionamento entre entidades.
• Modelo de BD NoSQL.
Cada modelo de banco de dados é tratado de forma personalizada e 
é projetado com base em regras e conceitos que são adotados pelos
projetistas. A maioria dos modelos de dados pode ser representada por 
um diagrama de banco de dados a ele associado (Figura 1).
8
Figura 1 – Modelo genérico de diagrama de banco de dados
 
 
 
 
 
 
 
 
 
Fonte: elaborada pela autora.
Os diagramas de banco de dados auxiliam na descrição de um banco de 
dados e de suas dependências, além de serem o modelo dos dados e 
mostrarem como se relacionam. Nesse sentido, é importante adotar um 
SGBD para dar suporte ao modelo adotado. A maioria dos sistemas de 
gerenciamento de banco de dados é construída sobre um determinado 
modelo de dados e requer que seus usuários abstraiam esse modelo. 
No entanto, diversos modelos se aplicam a diferentes estágios do 
processo de desenho do banco de dados, sendo um reflexo da forma 
como o especialista enxerga os dados. O administrador de banco de 
dados está ligado ao modelo físico dos dados, ao tipo, aos atributos, ao 
armazenamento, à performance do banco etc.
Os modelos de dados podem ser também conceituais, que é uma 
visão de alto nível acerca de como os dados se relacionam e quais 
dados integram esse modelo. Assim, o modelo conceitual abstrai o 
relacionamento entre as entidades e suas especializações, facilitando o 
mapeamento dos dados. Já os modelos lógicos, baseados em registros 
nas tabelas, refletem a proximidade de como os dados são armazenados 
no servidor e suas chaves de ligações.
Definir qual modelo será usado requer a compreensão e adequação 
de como aplicar o modelo que será adotado. Nem todos os modelos 
definem pontos fortes, mas ajudam a definir as priorizações, como 
9
velocidade, redução de custos, usabilidade, entre outras características 
intrínsecas. Ao escolher um modelo, este deve refletir o ambiente 
observado em que os dados são gerados, servindo para especificar 
relacionamentos, documentar e normalizar os dados.
1.2 Modelo de banco de dados hierárquico
O modelo hierárquico organiza os dados em uma estrutura semelhante 
a uma árvore, em que cada registro possui um único pai ou raiz (Figura 
2). Os registros são classificados por meio da especificação organizada 
de suas entidades e de seus relacionamentos. As entidades possuem 
relacionamentos entre si e refletem os objetos de acordo com sua 
existência no mundo real, sejam abstratos ou concretos, como cliente, 
vendas, produtos, estoque etc.
Figura 2 – Modelo hierárquico
 
Fonte: elaborada pela autora.
Esse modelo foi usado em SGBD das décadas de 1960 e 1970, sendo 
mantido atualmente apenas em poucos sistemas legados (sistemas 
informacionais ou gerenciais existentes na empresa, que podem 
ser antigos ou recentes). Hoje em desuso por conta de ineficiências 
operacionais, é apenas explorado nesse contexto para acrescentar um 
timeline sobre a evolução dos modelos.
10
1.3 Modelo relacional
O modelo relacional é o mais utilizado atualmente. Segundo Machado 
(2011), ele classifica os dados em tabelas, também conhecidas como 
relações, sendo cada uma composta por colunas e linhas. Cada coluna 
lista um atributo da entidade em questão, como produto, preço ou data 
de venda, sendo os atributos em uma relação chamados de domínio. 
Na Figura 3, o exemplo mostra um determinado atributo ou combinação 
de atributos escolhido como uma chave primária, que pode ser 
referenciada em outras tabelas, quando então é chamada de chave 
estrangeira na tabela na qual foi referenciada, no caso ID_Paciente e 
Cod_convenio. Em um modelo de banco de dados relacional, a chave 
primária refere-se à coluna que nunca se repete e pode ser usada como 
índice. A chave estrangeira é formada por meio de um relacionamento 
com a chave primária de uma ou mais tabelas.
Figura 3 – Modelo relacional de convênio médico
ID Paciente Nome_paciente Sobrenome_paciente
123456 Maria De Souza
123457 Rosa Cristina Alencar
123458 Alberto Noronha
Cod_convenio Convenio
123456 Maria
123457 Rosa
123458 Albeto
ID Paciente Cod_convenio Tipo_plano Data_adesao
123456 123456 Premium 26/11/2012
123457 123457 Corporativo 01/04/1999
123458 123458 Co participação 01/02/2017
Fonte: elaborado pela autora
Cada uma das linhas, também chamadas de tuplas, inclui dados 
sobre uma instância específica da entidade em questão, como o ID do 
11
paciente. Esse modelo reflete os tipos de relacionamentos entre essas 
tabelas, incluindo relacionamentos um para um, um para muitos e 
muitos para muitos. Isso significa que a chave primária de uma tabela 
está relacionada com a chave estrangeria em outra tabela, formando um 
relacionamento entre tabelas. Um exemplo é a escola que tem várias 
turmas, estando um relacionamento de uma escola relacionado com 
várias turmas. Um aluno pertence somente a uma turma (um para um), 
e alunos cursam disciplinas (N para N).
Em bancos de dados, as tabelas podem ser normalizadas ou trazidas 
para obedecer às regras de normalização, as quais organizam os dados 
em projeto de banco de dados, reduzem as redundâncias, aumentam 
a integridade para os dados e melhoram seu desempenho. Além disso, 
elas minimizam as anomalias de modificações dos dados, dando maior 
flexibilidade em sua utilização.
A utilização das regras de normalização produz resultados adaptáveis 
em validações estatísticas. Isso quer dizer que uma query que contenha 
função estatística pode ser sempre utilizada para novas entradas de 
dados, desde que estes obedeçam às regras de normalização. Quando 
normalizado, cada dado é atômico ou dividido nas menores partes úteis. 
Os bancos de dados relacionais geralmente são gravados em Structured 
Query Language (SQL).
1.4 Modelo de rede
O modelo de rede em banco de dados baseia-se no modelo hierárquico, 
permitindo relacionamentos muitos para muitos entre registros que 
estão vinculados, como alunos matriculados em disciplinas. Isso implica 
a necessidade de vários registros pai (MACHADO, 2011). Esse modelo 
possibilita relações complexas (Figura 4).
12
Figura 4 – Modelo de rede em banco de dados
 
 
 
 
 
 
 
 
 
Empregado Cliente 
Transacoes_Vendas 
Vendedor 
Produto 
 
Fonte: elaborada pela autora.
1.5 Modelo de BD orientado a objetos
O modelo de banco de dados orientado a objetos é o modelo pós-
relacional mais conhecido, pois incorpora tabelas, mas não se limita a 
elas. Esses modelos também são conhecidos como modelos de banco 
de dados híbridos, pois contêm dados como imagem, áudio, vídeo ou 
hipertexto.
1.6 Modelo de relacionamento entre entidades
Esse modelo captura as relações entre entidades do mundo real muito 
parecidas com o modelo de rede, mas não está diretamente ligado à 
estrutura física do banco de dados. Em vez disso, é frequentemente 
usado para projetar um banco de dados conceitual. Ele auxilia nas 
visões existentes dos relacionamentos entre as tabelas e na construção 
de novas visões em um DW, utilizadas para compor as dimensões e as 
tabelas fato.
13
Os dados armazenados em tabelas, como nomes, locais, produto etc., 
são denominados de entidades, e cada uma possui certos atributos, 
que, quando juntos, formam seu domínio. A entidade pessoa possui 
dados armazenados com o nome de pessoas, por exemplo. A entidade 
endereço tem que ter o local onde a pessoa mora, a rua, o número, 
o CEP, o bairro, a cidade, o Estado e o país. A cardinalidade, ou 
relacionamentos entre entidades, também pode e deve ser mapeada, 
por exemplo, se a entidade pessoa possui mais de um local, residência 
ou trabalho.
Machado (2011) ilustra que esse modelo é utilizado em nível 
de abstração de projetos de banco de dados, descriminando as 
características dos dados, chave primária e estrangeira. A chave primária 
pertence a um conjunto de campos que nunca se repetem e, portanto, 
podem ser usados como índice. Já a chave estrangeira é utilizada 
para criar os relacionamentos entre as tabelas. A Figura 5 apresenta 
um exemplo de modelo ER, ou simplesmente MER (Modelo Entidade 
Relacionamento).
Figura 5 – MER
 
 
 
 
Tbl_produto 
id_prodt (INT) 
prodt_name (TEXT) 
prodt_qt (INT) 
Id_categoria (INT)
Tbl_categoria 
id_categ (INT) 
nome_categ (TEXT) 
prodt_qt (INT) 
descricao categ (INT) 
Fonte: elaborada pela autora.
O MER é uma forma comum do diagrama de esquema em estrela, 
no qual uma tabela de fatos central se conecta a várias tabelas 
dimensionais (Figura 6).
14
Figura 6 – Modelo Estrela
 
 
 
 
 
 
Dimensão 3 Fato 
Dimensão 4 
Dimensão 1 
Dimensão 2 
Dimensão 5 
Fonte: elaborada pela autora.
As dimensões e os fatos são componentes complementares e 
dependentes entre si. Em um modelo dimensional, é obrigatória a 
existência de ambos (MACHADO, 2011, p 79). Esses elementos são 
fundamentais para a compreensão e análise das informações, pois, 
sem eles no modelo dimensional, pode haver comprometimento ou 
inviabilização nas análises pretendidas.
Essa percepção é muito importante para elaborar projetos em DW, já 
que uma série de agregações, sumarizações e tratamentos é necessária 
para criar as visões necessárias a partir das dimensões descritas por 
meio da tabela fato. É muito importante perceber que o banco de dados 
15
se mantém preservado, e as métricas e visões são construídas em um 
modelo estrela, de múltiplas dimensões.
PARA SABER MAIS
Tabela fato: é a principal tabela do MER ou das dimensões 
do DW. Nela, são armazenadas as métricas, que são os 
fatos propriamente ditos, e as Foreign Keys (FK – chaves 
estrangeiras, em português), que são as chaves que ligam 
os dados das dimensões com a tabela fato. As métricas são 
as medidas de tudo aquilo que a empresa quer medir para 
gerar valor e controle, ligando suas FK às dimensões que as 
descrevem.
Tabela dimensões: é a tabela que qualifica os dados 
provenientes da tabela fato. Por meio dela, pode-se criar 
análises dos dados em múltiplas perspectivas.
1.6.1 Modelo multidimensional
Esse modelo é uma variação do modelo relacional, sendo projetado 
para facilitar o processamento analítico. Vale ressaltar que o modelo 
relacional é otimizado para o processamento de transações on-
line (OLTP – On-line Transaction Processing), enquanto o modelo 
multidimensional é projetado para processamento analítico on-line 
(OLAP). Cada célula em um banco de dados dimensional contém 
dados sobre as dimensões rastreadas pelo banco de dados. De uma 
forma visível para o analista, é como uma coleção de cubos, em vez 
de tabelas bidimensionais, que podem ser consumidas para consulta 
(KIMBALL, 2002).
16
É muito comum encontrar as siglas como referência ao tipo de banco, 
se transacional ou analítico. O OLTP refere-se ao banco transacional, a 
base de dados original, cujo acesso deve ser preservado e restrito. Já 
quando se trata das análises, das métricas, das visões e das dimensões, 
o modelo deve ser projetado para ser consumido em ferramentas 
analíticas, dashboards, gráficos e relatórios, nesse caso, o OLAP.
1.7 Modelo de BD NoSQL
A obtenção de dados de outras fontes que não são modelos SQL surgiu 
em contraste ao modelo relacional, como um modelo de banco de dados 
semiestruturados e não estruturados, chamados de NoSQL. Além desse, 
dados provenientes da web, na qual várias consultas são realizadas, são 
semiestruturados, o que significa que há algum nível de organização, 
diferentemente da alta organização dos dados estruturados em um BD 
relacional.
Já os bancos de dados não estruturados são dados provenientes de 
vídeos, áudios, textos, redes sociais e da web. Em geral, são dados que 
contêm algum tipo de organização dos dados aos usuários. As funções 
de pesquisa na internet são convertidas em consultas para um servidor 
de BD realizar as operações de processamento. Vale ressaltar que 
esses dados não estruturados ou semiestruturados precisam ser pré-
processados para serem tradados como dados estruturados.
2. Banco de dados transacionais
Os bancos de dados transacionais são otimizados para executarem 
sistemas de produção, desde portais de instituições financeiras até 
de lojas de varejo. Neles, são feitas a leitura e a escrita em registros 
individuais de dados muito rapidamente, mantendo a integridade dos 
dados. Os bancos de dados transacionais não são criados para análises, 
17
embora muitas vezes se tornem ambientes analíticos, pelo fato de já 
estarem em funcionamento como bancos de dados, em produção, ou 
seja, estão prontos para serem consumidos pelos usuários.
A estratégia usual de iniciar com as análises dos dados muitas vezes 
é criar uma réplica do banco de dados transacional. Isso garante que 
as consultas analíticas não impeçam, acidentalmente, as consultas de 
produção, críticas para os negócios, enquanto exigem configuração 
mínima adicional. A desvantagem é que esses bancos de dados são 
projetados para processar transações, e não para análises. Usá-los como 
análise é um ótimo começo, mas podem trazer limitações que impeçam 
a necessidade de configurações analíticas mais específicas.
2.1 Integridade dos dados
A arquitetura dos bancos de dados transacionais é compatível com a 
Atomicidade, Consistência, Isolamento e Durabilidade (ACID), o que 
garante que as gravações no banco de dados sejam bem-sucedidas 
ou falhem juntas, mantendo um alto nível de integridade dos dados 
ao gravá-los no banco de dados. Os bancos transacionais são, 
portanto, essenciais para as transações comerciais, nas quais um alto 
nível de integridade de dados é necessário. 
Como exemplo, trazemos uma transação bancária. O cliente realiza 
o débito de uma conta-corrente e crédito para outra conta-corrente. 
Essa ação desencadeará um processo de transações financeiras, que 
utilizarão um banco de dados, devendo a arquitetura desse banco/
processo garantir o sucesso ou a falha na transação.
A ACID é um conjunto de propriedades que descreve como os bancos 
de dados transacionais são projetados para preservar a integridade 
das gravações neles. As principais propriedades são descritas 
no Quadro 1.
18
Quadro 1 – Propriedades ACID – Banco de Dados Transacional
Propriedades Descrição
Atomicidade
Se mesmo uma parte da transação falhar, toda a 
transação falhará. Dessa forma, todas as transações 
devem ser 100% bem-sucedidas para serem 
confirmadas com êxito no banco de dados.
Consistência
Uma transação é gravada no banco de 
dados (trazendo-o de um estado válido para 
outro) ou a transação é revertida.
Isolamento
As transações que ainda não foram 
concluídas não podem ser processadas/
modificadas por outras transações.
Durabilidade
Depois que uma transação é gravada no banco 
de dados, ela permanecerá lá, mesmo no 
caso de uma falha no banco de dados.
Fonte: adaptado de MySQL ([s.d.]).
2.2 Latência
A latência em banco de dados é o período de “dormência” dos dados 
que chegam ao ambiente operacional, para armazenamento em um 
banco transacional ou deste para um banco analítico (INMON, 2005). 
Como bancos de dados transacionais são projetados para executar 
sistemas em produção, eles são muito bons em operações que devem 
ser concluídas em milissegundos, sendo a baixa latência, então, uma 
característica deles.
2.3 Principais características do BD transacional
A seguir, trazemos um resumo das principais características que 
identificam um banco de dados transacional (Quadro 2). 
Quadro 2 – Características BD Transacional
Requerimentos Descrições
Normalização Altamente normalizado
Esquema Gravação impositiva
19
Consistência Coerência forte, garantia de ACID
Integridade Alta integridade
Usa transações SIM
Atualizável SIM
Escalável SIM
Carga de trabalho Gravações intensas, leituras moderadas
Indexação Índices primários e secundários
Tamanho do dado De pequeno a médio
Modelo Relacional
Flexibilidade de consulta Altamente flexível
Escalabilidade Pequeno (MBs) a grande (alguns TBs) (*)
(*) MBs – MegaBytes; TBs – TeraBytes.
Fonte: adaptado de Kimball (2002).
3. Banco de dados analítico
Um banco de dados analítico é um sistema somente de leitura que 
armazena dados para históricos ou métricas de negócios, como o 
desempenho de vendas e a projeção de níveis de estoque. Os analistas 
da área de negócios, executivos
corporativos e outros funcionários 
podem consumir consultas e analisar relatórios provenientes de um 
banco de dados analítico. Os conjuntos das informações, por sua vez, 
são atualizados regularmente, à medida que os dados de transações 
recentes são incorporados ao banco de dados analítico.
O projeto de um banco de dados analítico permite suportar aplicações 
tanto de Business Intelligence (BI), métricas analíticas e Big Data, em geral, 
como de um Data Warehouse ou Data Mart.
O banco de dados analítico é diferente dos banco de dados operacional, 
transacional ou OLTP, sendo o primeiro usado para análises e o segundo 
para processar as transações. Embora os bancos transacionais possam 
ser usados para suportar o armazenamento de dados e as aplicações de 
BI, não são recomendados por questões de integridade e escalabilidade. 
O banco convencional deve ser preservado, e o banco analítico deve 
estar em outro schema.
https://searchbusinessanalytics.techtarget.com/definition/business-intelligence-BI
https://searchdatamanagement.techtarget.com/definition/data-warehouse
https://searchsqlserver.techtarget.com/definition/data-mart
20
PARA SABER MAIS
Data Mart (DM): representa um subconjunto de dados do DW, 
em geral por assunto ou departamento (MACHADO, 2011).
Schema: um esquema de BD representa a configuração 
lógica da totalidade ou de alguma parte da base de dados 
relacional. Existem dois esquemas principais em BD. Um é 
o esquema de BD lógico, que contempla restrições lógicas, 
como integridade, exibições e tabelas, aplicadas aos dados 
armazenados. Já um esquema de BD físico define como 
os dados são armazenados fisicamente no servidor de 
armazenamento, em termos de arquivos e índices.
Os bancos de dados analíticos surgiram para atender especificamente 
às necessidades das empresas que desejam construir repositórios de 
dados de alto desempenho. Atualmente, eles são criados para analisar 
volumes extremamente grandes de dados com maior rapidez do que 
os bancos transacionais, utilizando, para isso, técnicas que aumentam a 
performance das respostas às consultas. Algumas técnicas mais usuais 
são citadas a seguir, de acordo Kimball (2002).
 1. Técnica do armazenamento de dados colunar. Um banco de 
dados analítico tem uma estrutura baseada em coluna, sendo 
cada coluna de dados armazenada em seu próprio arquivo e 
organizada geralmente em esquema estrela. Esse design torna o 
banco analítico altamente flexível, o que facilita a operação em um 
grande conjunto de pontos de dados em uma determinada coluna 
com muita rapidez. Bancos de dados transacionais dependem de 
armazenamento de dados baseado em linha. Eles são ótimos para 
operar rapidamente em uma única linha, mas um design baseado 
em linha não pode ser dimensionado para lidar com grandes 
volumes de dados da mesma maneira que um design colunar.
21
A vantagem do processamento orientado por colunas é que os 
cálculos em colunas individuais são muito rápidos. Por exemplo, para 
realizar uma consulta ao banco de dados para determinar o maior 
salário mensal – máximo (salário) – entre todos os funcionários, só é 
necessário procurar a coluna salário. Nesse caso, apenas um bloco 
deve ser carregado por um acesso ao disco rígido.
O armazenamento baseado em colunas fornece dados 
direcionados para análise, o que melhora significativamente o 
desempenho. A abordagem orientada por colunas é usada, entre 
outras, por plataformas de banco de dados, tais como Hadoop, 
HBase da Apache, Vertica e Sybase IQ da SAP.
	 2.	 Eficiente	compressão	de	dados. Como resultado direto de seu 
design de armazenamento de dados em colunas, um banco de 
dados analítico é capaz de executar eficientemente a compactação 
de dados em cada coluna de dados específica. A compactação de 
dados é fator determinante, tanto quanto ao espaço que os dados 
ocuparão como com que rapidez poderão ser manipulados.
 3. Cargas de trabalho distribuídas. Em um sistema distribuído, os 
dados são armazenados em um cluster de servidores (geralmente 
chamados de nós). Por exemplo, em um Warehouse Redshift, os 
dados podem ser armazenados em servidores diferentes de 2-14, 
com o Redshift coordenando o processamento paralelo das consultas 
analíticas realizadas nessa infraestrutura. Essa paralelização 
permite o processamento eficiente de volumes de dados cada vez 
maiores. Bases de dados analíticas são tipicamente construídas com 
processamento distribuído em seu núcleo.
ASSIMILE
Redshift: está disponível na Amazon Web Services (AWS) 
e é um serviço de armazenamento de dados em escala 
22
de petabytes totalmente gerenciado na nuvem. Um Data 
Warehouse do Amazon Redshift é um conjunto de recursos 
de computação chamado de nós, que são organizados 
em um grupo chamado de cluster. Cada cluster executa 
um mecanismo do Amazon Redshift e contém um ou mais 
bancos de dados.
3.1 Comparação entre bancos de dados transacionais e bancos 
de dados analíticos 
Há ainda dúvidas quanto aos bancos de dados transacionais e analíticos, 
no que se refere a qual usar. Quando uma transação bancária é 
realizada, por exemplo, com um depósito em cheque em determinada 
conta-corrente, um processo transacional é disparado. Essa ação 
irá gerar um conjunto de dados para ser associado, armazenado e 
recuperado, com a informação ali contida, por meio de determinada 
organização desses dados. Essa manipulação de dados, quer seja na 
consulta ou na gravação, é caracterizada pelas transações envolvidas em 
todo esse processo ou procedimento.
Essa ação de depósito gera uma transação, que tem como foco 
descrever as transações. Esse depósito gera uma transação que tem um 
determinado valor, uma origem, um destino, um determinado tempo, 
entre outras informações. Essas ações são processadas por um sistema 
que dará a garantia de integridade dos dados, uma ordem temporal 
em cada movimento contido na ação do depósito. Por esse motivo, um 
dos principais requisitos dos sistemas transacionais é a performance/
desempenho, ou seja, é necessário que a transação ocorra no momento 
em que foi requerida, como um sistema em tempo real.
Já o banco de dados analítico é provido de informações advindas do 
banco transacional. Os dados coletados no BD transacional servirão de 
insumos para darem respostas às decisões organizacionais e estratégicas. A 
23
atividade de análise sobre esses dados, do banco analítico, em geral ocorre 
em modo off-line, quando se englobam os dados transacionais, agrupados, 
sumarizados ou amostrados para responder às indagações feitas pelos 
analistas da empresa ou de negócios.
Diferentemente dos dados transacionais, os dados analíticos requerem 
e necessitam de estruturação em datasets de análise. A aquisição dos 
dados analíticos se dá de diferentes maneiras, em geral por extrações 
dos bancos de dados em formato de arquivos tipo .txt, .CSV ou .XLSX.
Os Datasets ou conjunto de dados são necessários para as análises de 
dados, representando agrupamentos, comportamentos e amostragens 
que permitem a aplicação de modelos matemáticos, como tentativa de 
explicar e dar um significado àqueles dados. Eles são representações 
de dados tabulares, formatados em registros nas linhas, representando 
os acontecimentos ou as ocorrências e as características desses 
acontecimentos nas colunas. Esse dataset resultará em um comportamento 
associado àqueles acontecimentos e àquelas características.
O Quadro 3 representa uma comparação geral entre o BD analítico e o 
transacional, para auxiliar no projeto de um BD com foco em DW.
Quadro 3 – Comparação geral entre BD analítico e BD transacional
Característica Analítico Transacional
Caso de uso Analisa grandes volumes 
de dados para a 
análise de negócios.
Processa grandes 
volumes de transações 
em tempo real.
Objetivo da otimização Insere rapidamente e 
seleciona um grande 
número de linhas.
Inserções, atualizações, 
seleções e exclusões em 
tempo real em menos linhas.
Consultas Especializadas e 
personalizadas.
Amplas e genéricas.
Consulta
de tempos 
de resposta
Segundos para uma 
consulta analítica.
Milissegundos para uma 
consulta transacional.
Bancos de dados 
de exemplo
Vertica, Redshift, Greenplum, 
Teradata, ParAccel.
MySQL, PostgreSQL, 
Microsoft SQL Server.
Fonte: elaborado pela autora. 
24
Existem questões de relevância quando ocorre uma tentativa 
reducionista de comparar um banco de dados transacional e um 
banco analítico. Nesse contexto, vale ressaltar que a comparação 
serve como apoio para a tomada de decisão. Por exemplo como fazer 
um projeto inicial de DW para BI partindo de um modelo elementar 
de um banco de dados existente na organização? O projeto de um DW 
para BI pode ser concebido de diferentes maneiras. Queries analíticas 
podem rodar na aplicação front end, tirando o processamento do 
banco de dados.
Outro ponto fundamental é o fato de os bancos de dados do 
exemplo do Quadro 3 com capacidade analítica demandarem relativa 
complexidade para serem implementados. Alguns apresentam 
solução muito eficaz, mas demandam uso de memória de máquina 
virtual, o que acaba elevando o custo da operação analítica.
Novas ferramentas ou soluções estão sempre em desenvolvimento 
para resolver alguns problemas de performance de bancos de dados 
tradicionais para transações. Porém, isso não tira a capacidade de 
um SGBD tradicional para bancos de dados transacional suportar 
as análises.
A questão não é tão simplista. Deve-se considerar o volume, 
a integridade, a velocidade, entre outras questões, pois o 
processamento dos dados para análises depende de cálculos pré-
programados. Além disso, análises em tempo real vão demandar 
acessos contínuos, o que demanda capacidade do banco. A melhor 
maneira é sempre partir de um conceito básico: o banco de dados de 
repositório, que armazena as transações, não é para ser usado para 
análises ou pré-processamento. Um projeto de DW para BI considera 
um fluxo de dados, um banco para armazenar as transações e um 
banco para processar as análises.
25
4.	Considerações	finais
Um banco de dados transacional deve integrar as bases de dados 
da organização, os dados brutos dos processos, preservando sua 
integridade. Já um banco de analítico não é um banco físico real, como o 
transacional, mas sim de dimensões para construir as visões analíticas. 
Portanto, um DW é um repositório que abarca dimensões, tabelas fato e 
visões, que serão consumidas como apoio para a tomada de decisão. O 
DW é o caminho intermediário entre os dados transacionais e os dados 
analíticos.
TEORIA EM PRÁTICA
Criar um dataset para análises é uma tarefa complexa. 
Suponha que você tenha que criar um dataset pelo Excel 
relativo ao desempenho de uma cafeteria. São vendidos em 
média 200 cafés diariamente. A cafeteria abre de domingo 
a domingo, das 7 horas da manhã até às 20 horas. Além do 
tradicional café, vende também água, chá e leite, além de 
pão de queijo, pão com manteiga e brigadeiro. A média de 
vendas de todos as bebidas, com exceção do café, é de R$ 
77,00 diariamente, enquanto a média diária de vendas dos 
produtos alimentícios fica em R$ 65,00.
Você poderá elaborar um dataset simulando as vendas 
dos itens descritos. Leve em consideração o desempenho 
de um mês dessa cafeteria. Descrimine o banco de dados 
para uma abordagem baseada em cáculos de maneira que 
as análises dos dados sejam realizadas pelo usuário. Por 
exemplo, simule um dataset com os dados preenchidos 
na tabela, como data, hora, produto, tipo de produto, 
quantidade, número do pedido e ID do pedido. A simulação 
precisa ter regras estabelecidas nesse contexto, então pode-
26
se vislumbrar um cenário em dez anos de vendas de café. 
Por exemplo, houve uma variação de 16%; o preço do café 
foi de R$1,00, há dez anos, para R$ 4,40. A contabilização 
desses 10 anos resultou em 720.000 cafés vendidos, 
aproximadamente. Tabule os dados e crie conceito de 
perspectiva analítica, a partir do modelo:
ID_pedido Data Hora Produto Tipo de produto Qte. Nº pedido Preço unitário Preço total
1 14/01/2019 07:23 bebida café expresso 2 321 R$4,40 R$8,80
2 14/01/2019 07:25 bebida médio 1 322 R$5,40 R$9,40
      comida pão de queijo 1 322 R$4,00  
3 14/01/2019 07:27 comida pão manteiga 1 323 R$2,50 R$2,50
4                
5                
6                
Etc. Etc. Etc. Etc. Etc. Etc. Etc. Etc. Etc.
Observe que o pedido 2 já consiste em um cálculo da soma 
de dois produtos em um mesmo pedido.
Fica mais uma dica: 200 * 30 dias = 6.000 por mês, 72.000 
por ano, em dez anos = 720.000 cafés. Simule as condições 
de vendas de 30 dias apenas. Avalie quais análises podem 
ser estratificadas a partir desse dataset.
VERIFICAÇÃO DE LEITURA
1. Por que um banco de dados transacional não deve ser 
usado para análises? Aponte a resposta correta.
a. Um banco de dados transacional deve preservar 
a integridade dos dados e, portanto, não é 
recomendável utilizá-lo para análises.
27
b. Um banco de dados transacional deve preservar 
as tabelas fato dos dados e, portanto, não é 
recomendável utilizá-lo para análises.
c. Um banco de dados transacional deve preservar as 
visões dos datasets e, portanto, não é recomendável 
utilizá-lo para análises.
d. Um banco de dados transacional deve preservar a 
tecnologia de processamento dos dados e, portanto, 
não é recomendável utilizá-lo para análises.
e. Um banco de dados transacional deve preservar o 
fluxo dos dados e, portanto, não é recomendável 
utilizá-lo para análises.
2. As consultas em banco de dados analítico são diferentes 
de um banco de dados transacional. Qual alternativa 
apresenta a característica das consultas em um banco de 
dados analítico?
a. As consultas em um BD analítico são 
genéricas e amplas.
b. As consultas em um BD analítico são genéricas.
c. As consultas em um BD analítico são 
especializadas e amplas.
d. As consultas em um BD analítico são especializadas e 
personalizadas .
e. As consultas em um BD analítico são genéricas e 
modeladas matematicamente.
3. Os bancos de dados analíticos utilizam técnicas que 
aumentam a performance no tempo de resposta às 
consultas. Qual é a técnica de armazenamento nas 
tabelas que melhora a performance em um BD analítico.
28
a. Matricial.
b. Colunar.
c. Em linha.
d. Tabular.
e. 1ª coluna e 1ª linha da tabela.
Referências	Bibliográficas
INMON, W. H. Building the Data Warehouse. 4. ed. New York: Wiley Computer 
Publishing, 2005.
KIMBALL, R. The Data Warehouse Toolkit: guia completo para modelagem 
dimensional. Rio de Janeiro: Campus, 2002.
MACHADO, F. N. Tecnologia e Projeto de Data Warehouse: uma visão 
multidimensional. São Paulo: Érica, 2011.
MYSQL. MySQL 5.6 Reference Manual. 14.2 InnoDB and the ACID Model. [s.d.]. 
Disponível em: https://dev.mysql.com/doc/refman/5.6/en/mysql-acid.html. Acesso 
em: 7 abr. 2019.
RASLAN, D. A.; CALAZANS, Angélica T. S. Data Warehouse: conceitos e aplicações. 
2014. Disponível em: https://www.publicacoesacademicas.uniceub.br/gti/article/
viewFile/2612/2400. Acesso em: 23 mar. 2019.
Gabarito
Questão 1 - Resposta A
Resolução: A arquitetura dos bancos de dados transacionais é 
compatível com a ACID, o que garante que as gravações no banco 
de dados sejam bem-sucedidas ou falhem juntas, mantendo um 
alto nível de integridade dos dados ao gravá-los dados no banco 
de dados. Os bancos transacionais são, portanto, essenciais para 
transações comerciais em que um alto nível de integridade de 
dados é necessário.
https://dev.mysql.com/doc/refman/5.6/en/mysql-acid.html
https://www.publicacoesacademicas.uniceub.br/gti/article/viewFile/2612/2400
https://www.publicacoesacademicas.uniceub.br/gti/article/viewFile/2612/2400
29
Como exemplo, temos uma transação bancária, com débito de 
uma conta-corrente e crédito para outra conta-corrente, devendo a 
arquitetura garantir o sucesso ou a falha na transação.
Questão 2 - Resposta D
Resolução: 
Quadro 3 – Comparação geral entre BD analítico e BD 
transacional
Característica Analítico Transacional
Caso de uso Analisa grandes 
volumes de dados
para 
análise de negócios.
Processa grandes 
volumes de transações 
em tempo real.
Objetivo da otimização Insere rapidamente e 
seleciona um grande 
número de linhas.
Inserções, atualizações, 
seleções e exclusões 
em tempo real em 
menos linhas.
Consultas Especializadas e 
personalizadas.
Amplas e genéricas.
Consulta de tempos 
de resposta
Segundos para uma 
consulta analítica.
Milissegundos para uma 
consulta transacional.
Bancos de dados 
de exemplo
Vertica, Redshift, 
Greenplum, 
Teradata, ParAccel.
MySQL, PostgreSQL, 
Microsoft SQL Server.
Fonte: elaborado pela autora.
Conforme o quadro comparativo, a característica das consultas em 
um banco de dados analítico é especializada ou personalizada, pois 
tende a representar alguma agregação e sumarização e cálculos 
dos dados a serem estudados ou analisados.
Questão 3 - Resposta B
Resolução: Técnica do armazenamento de dados colunar. Um 
banco de dados analítico tem uma estrutura baseada em coluna, 
sendo cada coluna de dados armazenada em seu próprio arquivo 
e organizada geralmente em esquema estrela. Esse design torna o 
banco analítico altamente flexível, o que facilita a operação em um 
30
grande conjunto de pontos de dados em uma determinada coluna 
com muita rapidez. Bancos de dados transacionais dependem de 
armazenamento de dados baseado em linha. Eles são ótimos para 
operar rapidamente em uma única linha, mas um design baseado 
em linha não pode ser dimensionado para lidar com grandes 
volumes de dados da mesma maneira que um design colunar.
Conceitos básicos sobre 
Data Warehouse
Autora: Marise Miranda
Objetivos
• Viabilizar ambientes para implentações em Data 
Warehouse (DW).
• Descrever as características de 
construção de um DW.
• Apresentar a composição do ambiente de 
inicialização de projeto DW. 
32
1. A viabilização de um Data Warehouse
Os sistemas transacionais priorizavam o foco nas técnicas estruturadas 
para manter a integridade e a qualidade dos dados ali armazenados. 
Todos os tipos de transações em um processo eram armazenados, como 
baixa em estoque de peças, venda de produto unitário, entre outros. 
A elevação de rotinas com níveis de erros mínimos, testes incessantes 
e integridade física do banco de dados estabeleciam os elementos de 
controle do ambiente operacional, como a soma de todas as peças 
baixadas em estoque para controle de reposição.
Com a necessidade de informações executivas ou estratégicas, 
somando-se informação aos dados armazenados, veio a necessidade de 
especificações associadas e modelagens de sistemas que fornecessem 
indicadores. Os casos anteriores, como baixa das peças do estoque 
e soma das peças baixadas em estoque para controle, são exemplos 
de informações executivas. Assim, correlacionar as somas das peças 
baixadas com as vendas dos produtos que utilizaram essas peças pode 
determinar a compra de reposição em maior ou menor volume, a fim de 
que a empresa não incorra em prejuízo ao comprar peças que não serão 
utilizadas, ficando ociosas no estoque, ou ao perder vendas por falta de 
peças que não foram repostas em estoque. Esse último exemplo implica 
em informações estratégicas.
Nesse sentido, há uma diferença entre um projeto de banco de dados 
transacional, Online Transaction Processingn (OLTP), ou Processamento 
de Transações em Tempo Real, e um projeto para DW com tecnologia 
Online Analytical Processing (OLAP), ou Processamento Analítico em 
Tempo Real. O primeiro é utilizado no dia a dia da empresa, registrando 
cada operação e alimentando um conjunto de informações executivas. 
O segundo faz referência às informações estratégicas, em função 
do processamento analítico, por meio de sumarizações, agregações, 
cálculos e correlações dos seus conjuntos de dados.
33
Como os dados são relativos e descrevem um objeto de interesse, de 
modo estático, a informação é algo que se acrescenta ao dado, podendo 
ser um modo dinâmico. Porém, a informação não é estratificada 
sistematicamente por diferentes tipos e fontes de dados; ela é a 
combinação de dados e o tratamento inserido a essa combinação, 
considerando sua temporalidade. Esse tratamento é a sentença 
associada que gera certo conceito, conhecimento, afirmação dos dados 
armazenados em tabelas e os relacionamentos entre si. Essas sentenças 
são a chave de uma implementação bem-sucedida de um DW, em que 
este deve permitir a criação de bases de informação para a realização 
de análises.
Um repositório ou armazém de dados deve possuir um DW em que se 
realizem análises como as listadas a seguir:
• Segmentação de clientes (Figura 1).
• Indicadores da campanha de marketing.
• Performance das vendas.
• Análise da fidelização dos clientes.
• Mensuração do atendimento ao cliente.
• Status da lucratividade (Figura 2).
• Comportamento das oscilações dos negócios.
Figura 1 – Segmentação de clientes
Fonte: AndreyPopov/iStock.com.
34
Figura 2 – Status das oscilações da lucratividade
Fonte: firstpentuer/iStock.com.
Essas análises do DW devem servir para que outras ferramentas 
obtenham mais clientes, mantenham os clientes existentes na base ou, 
ainda, permitam desenvolver canais novos de clientes, como o caso de 
um CRM (customer relationship management, ou relacionamento com o 
cliente). A integração de dados entre ferramentas pode ser observada 
nas figuras a seguir: 
 
Figura 3 – Dados operacionais 
e relacionamento com o 
cliente (CRM)
Figura 4 – DW – Integração e 
análise dos dados 
Fonte: cnythzl/iStock.com. Fonte: priyanka gupta/iStock.com.
35
Essa integração entre uma tecnologia que fornece milhares de dados 
do relacionamento de clientes, o CRM, e uma ferramenta de análise 
de dados, em uma arquitetura de DW, pode gerar a possibilidade de 
conhecer características de comportamento de clientes afetados pela 
economia ou mudança de negócio em um espaço de tempo pequeno – 
por meio de análise dos dados do cliente com o momento econômico de 
uma determinada época do ano, por exemplo. Esse cenário possibilita 
gerar um estudo analítico que mostra o comportamento do cliente 
explícito, quando analisado isoladamente, ou em agrupamentos de 
clientes, que podem relevar por meio das análises comportamentos 
favoráveis ao consumo de determinado produto.
Nesse sentido, as organizações precisam se apoiar na tomada de 
decisão por meio de diagnósticos mais assertivos, provenientes das 
análises obtidas a partir dos dados da organização. Comparativamente, 
um médico faz a anamnese, que é uma entrevista para ouvir os relatos 
do paciente sobre suas dores e queixas, e com isso estabelece um 
diagnóstico; porém, com os exames, pode realizar um diagnóstico mais 
preciso e, assim, instituir condutas terapêuticas.
De forma semelhante, os executivos precisam se apoiar em informações 
precisas sobre os dados para diagnosticar tendências e administrar 
estratégias com profundidade. Por isso, as análises sobre sazonalidades 
e tendências e as análises temporais podem apresentar indicadores 
de tomada de decisão sobre crescimento ou riscos para os negócios, 
conforme o conhecimento de quem analisa. Os dados estão lá, mas 
a forma de como torná-los interpretativos a fim de possibilitar um 
diagnóstico requer técnicas analíticas e suporte de arquiteturas que 
permitam combinações de dados.
A tecnologia de DW veio nessa direção para dotar as organizações e a 
dinâmica de seus negócios de capacidade analítica com base na sua 
competência operacional armazenada.
36
2. Construção de um DW
A realidade histórica da organização, seus clientes, seus fornecedores, 
suas operações, suas despesas e sua lucratividade são a base para 
construir um Data Warehouse (armazém de dados). Esse armazém, 
repositório ou banco de dados deve se manter disponível e acessível 
para consultas e análises dos dados ali armazenados.
Podemos observar que não há uma referência à especificidade de 
um banco de dados em que estão armazenados milhões de registros 
in natura ou dados brutos, preservados e íntegros. Quando um DW 
é
citado, nesse contexto, diz-se que dimensões são criadas acima 
desses dados brutos. Um armazém de dados no contexto de DW, 
que não é o mesmo do banco de dados transacional, é referenciado 
assim, como uma área de stage, uma área estacionária para armazenar 
somente aqueles dados que serão utilizados para análises. Assim, o 
que se armazena é uma cópia dos dados necessários para as análises, 
preservando os dados originais guardados no banco transacional.
O conceito de DW mudou também o contexto de banco de dados, 
separando os transacionais e o que é um armazém de dados (que 
também é um banco de dados), isolado do original, para que os dados 
do armazém possam ser consultados nas análises, em função da 
necessidade de diversos arranjos entre esses dados.
Inmon (2005) destaca a mudança na abordagem em relação aos dados 
brutos, uma vez que no início dos registros de dados não havia uma 
experiência que pudesse prever arranjos diferentes para suportar 
análises. O objetivo de arquiteturas básicas para banco de dados era 
apenas armazenar ou guardar os registros, sem a robustez necessária 
para suportar necessidades futuras.
As necessidades analíticas sobre os dados provocaram mudanças na 
arquitetura, surgindo demandas provenientes de dados derivados. Os 
dados do dia a dia, das operações, são os dados brutos, enquanto os 
dados resumidos, agregados, sumarizados ou calculados são os dados 
derivados. Essa divisão, dados brutos e informacionais/analíticos, 
37
proposta por Inmon (2005) justifica sua necessidade de acordo com os 
motivos elencados a seguir na Figura 5.
Figura	5	–	Justificativas	da	divisão	entre	dados	brutos/operacionais	
e	analíticos/informacionais
 
Fonte: blackred/iStock.com.
Os dados que suportam as demandas 
operacionais, são fisicamente 
distintos, não servindo para atender 
as necessidades informacionais ou 
analíticas.
A tecnologia para o processamento operacional é tecnicamente 
diferente da tecnologia necessária em suportar informações 
ou análises.
Fonte: a-image/iStock.com.
Os usuários de dados operacionais são 
diferentes para usuários que consomem 
dados informativos ou analíticos.
O processamento de dados operacionais tem características diferentes 
de processamento analítico ou informacional.
Fonte: adaptado de Inmon (2005).
https://www.istockphoto.com/br/portfolio/blackred?mediatype=photography
https://www.istockphoto.com/br/portfolio/a-image?mediatype=photography
38
As justificativas levam em consideração a finalidade de uso dos dados. A 
base de dados bruta é consistente e original e necessita ser preservada. 
A partir dela, uma cópia dos dados é feita com o objetivo de agregar e 
sumarizar os dados necessários às análises. Os usuários que consomem 
as informações das bases de dados transacionais são os que controlam 
ou realizam as operações diárias. Já os usuários analíticos consomem 
análises para encontrar diagnósticos estratégicos e que possam servir 
de tomada de decisão. Essas são as principais razões que motivam a 
separação de ambientes entre uma base de dados operacionais de uma 
para análises.
Ainda com o objetivo de ampliar o entendimento acerca da necessidade 
de separar contextos de construção de ambientes para banco de dados, 
a Figura 5, proposta por Inmon (2005, p. 16), destaca as diferenças 
entre os dados operacionais e os analíticos. Essa diferença é decorrente 
da evolução de sistema de suporte para a decisão e a inabilidade dos 
bancos de dados operacionais fornecerem insumos desse fim.
Explorando o exemplo da Figura 6, temos uma empresa fabricante de 
produtos alimentícios com três filiais, cada qual com sua base de dados 
intermediária conectada a um único banco de dados, que registra todas 
as operações. Dependendo de como o relatório é extraído pela matriz, 
podem ocorrer discrepâncias, tais como relatório de todo o período 
do ano na perspectiva da filial 3 e relatório de metade do período na 
perspectiva da matriz sobre as vendas, ambos referentes ao produto 
2. Obviamente, os relatórios não vão coincidir, porque a forma de 
extração dos dados coletados no período é diferente – as amostras são 
diferentes.
O problema?
• Um departamento precisa dos resultados das vendas anuais e o 
outro departamento dos resultados de vendas de alguns meses.
• A base de dados é comum, mas a temporalidade é de cada 
departamento.
39
Figura 6 – Modelo de extração de venda do produto 2 por duas 
perspectivas distintas em relação ao período
 
 
 
 
 
 
 
 
 
Matriz 
Fonte: elaborada pela autora.
Suponhamos que os produtos alimentícios sejam os seguintes: produto 
1 – feijão; produto 2 – arroz; produto 3 – macarrão; produto 4 – farinha; 
e produto 5 – tempero. As linhas tracejadas em vermelho e amarelo 
representam a perspectiva de extração de diferentes maneiras em 
relação ao produto 2. A diferença consiste na necessidade de extração 
de venda do produto 2 da filial 3, enquanto a matriz tem a necessidade 
de fazer a extração de venda de todas a filiais juntas para analisar as 
vendas do produto 2, ou seja, a filial 3 analisa as suas vendas próprias 
de arroz e a matriz analisa as vendas de arroz de todas as filiais. Se o 
acesso à base de dados da filial 3 não tem a mesma referência analítica, 
as divergências podem ocorrer, pois a filial 3 poderá analisar as suas 
vendas mensais de arroz, e a matriz poderá analisar o desempenho 
diário de vendas de arroz das filiais.
40
Esse cenário pode remeter a análises distintas. A filial 3 só poderá 
perceber seu desempenho a cada 30 dias, podendo ocorrer 
variabilidades diárias nas vendas sem que a filial tome alguma ação; ao 
contrário da matriz, que poderá questionar alguma tomada de decisão 
da filial 3 em função das análises diárias.
Assim, para que as divergências nas análises não ocorram, é 
recomendável que na construção de um DW a sua arquitetura preconize 
referências analíticas comuns, como desempenho comparativo 
entre as filiais, ranking de vendas de produtos, produtos com maior 
rentabilidade, setorização das vendas, aumento da eficiência das vendas 
sem afetar as outras filiais, entre outras análises. Em grande parte, os 
dados são estratificados empiricamente, sem que testes amostrais 
garantam que o comportamento seja o mesmo em diferentes datasets.
As análises de dados são implementadas para responder às perguntas 
sobre os negócios, direcionando a tomada de decisão. Machado (2011) 
mostra o percentual de tempo gasto em atividades sem estratégia e com 
estratégia de acesso aos dados, conforme a Figura 7. A análise de dados 
sem aplicações estratégicas, desde o acesso, a preparação, as decisões e 
as ações, gasta em média cerca de 20% a mais do que se houvesse uma 
aplicação estratégica em relação aos dados, desde a sua escolha das 
análises até as decisões e consequentemente ações.
A Figura 7 mostra a curva descendente quando não há aplicação de 
estratégias sobre os dados a serem analisados, consumindo um esforço 
maior no acesso aos dados e nas análises. Quando há uma estratégia 
desenvolvida, com perguntas corretas do que se quer analisar, os dados 
necessários às repostas e às análises têm menor esforço de tempo 
gasto, deixando um tempo maior para o desenvolvimento das decisões.
41
Figura 7 – Percentual de tempo gasto em atividades 
relacionadas aos dados
Fonte: adaptado de Machado (2011, p. 20).
As atividades relacionadas aos dados sem uma estratégia envolvida 
em relação ao acesso e às análises demandam maior percentual de 
tempo, um total de 30%, resultando em pouco tempo para transformar 
essas análises em decisões, o que leva a pouco tempo na preparação 
de cenários e ações de implementação, cerca de 8,6 % de tempo gasto. 
Ao contrário de utilizar uma estratégia em relação aos dados, o tempo 
gasto é de cerca de 10% para acessar os dados e construir as análises 
qualificadas o suficiente para serem consumidas em forma de decisões 
mais elaboradas, gerando insumos suficientes para a preparação de 
cenários e ações, em tempo médio 20%
maior.
ASSIMILE
Estratégia de dados: aplicar conceitos estratégicos 
utilizados nos negócios ou no desenvolvimento de 
tecnologia não tem o mesmo resultado dos dados para 
suportar a precisão, o acesso, o compartilhamento e até 
a reutilização, como acontece no caso de codificação 
42
em software. A estratégia de dados garante que todos 
os recursos de dados estejam disponíveis para serem 
utilizados, compartilhados e manejados de forma fácil e 
eficiente. Assim, a estratégia de dados garante que eles 
sejam consumidos como ativo dentro da organização, e 
os datasets fornecem métricas e indicadores a todos os 
projetos da organização.
Gerenciamento de dados: em geral envolve metadados, 
gestão de dados mestre, governança, migração, integração 
e qualidade de dados.
O DW é uma coleção orientada por assuntos, integrada, variante no 
tempo e não volátil, para apoiar o processo de tomada de decisão das 
organizações (INMONN, 2005). Na definição de Kimball (2002), o DW 
é a cópia específica de tabelas do banco transacional para consultas e 
análises, criando visões funcionais. Um projeto de construção de um 
DW depende, fundamentalmente, de arquitetura, e, por isso, Machado 
(2011) deixa claro que o “DW é uma arquitetura e não uma tecnologia” 
(MACHADO, 2011, p. 25), pois a tecnologia, sim, ajuda a construir, operar 
e monitorar um projeto DW implantado.
A construção de um DW inicia com a recuperação dos dados históricos 
da empresa, o que significa realizar cópias da história da organização 
dos dois anos anteriores, como recomenda Machado (2011), uma vez 
que o banco de dados de um DW não é, fisicamente, o mesmo dos 
dados transacionais. Na verdade, os dados armazenados em um DW são 
a cópia histórica do banco de dados transacional.
A construção pressupõe necessidades de informações especializadas e 
indicadores de performance da organização. Uma base histórica auxilia 
43
na criação de comparações com dados atuais e tendências futuras. 
A construção prevê também a utilização de ferramentas de Sistemas 
Especialistas (EIS) e Sistemas de Suporte à Decisão (DSS), as quais são 
utilizadas em diferentes níveis de gestão das organizações, de acordo 
com Turban (2005). A Figura 8 representa o modelo de Turban (2005) e 
os sistemas de informação relacionados a cada nível organizacional.
Figura 8 – Sistemas de informação versus Níves organizacionais
 
 
 
 
 
 
 
 
 
 
 
Ambiente de 
Data Warehouse (DW) 
Fonte: adaptado de Turban (2007, p. 41).
Os níveis organizacionais necessitam de um determinado tipo de 
informação. O nível operacional processa os Sistemas Transacionais 
(TPS); o gerenciamento de operações acessa os Sistema de Informação 
Gerencial (SIG – MIS em inglês); a gestão tática acessa o DSS para apoiar 
as decisões; e, por último, a gestão estratégica acessa o EIS. Assim, o 
ambiente de DW é resultante do DSS e do EIS.
44
PARA SABER MAIS
TPS - Transaction Processing System: são dados capturados 
dos processos diários da organização. Exemplo: relatório de 
vendas, relatório de salários.
MIS - Management Information System: são relatórios 
temporais, comparativos, sumarizados, para 
acompanhamento da gerencia para resolver problemas, 
supervisionar atividades e rastreabilidade. Exemplo: 
relatórios de vendas mensais acompanhado do resultado 
financeiro.
DSS - Decision Support System: são análises com 
abordagens para tomada de decisão da alta gestão. 
Exemplos: análises, dados internos, dados externos que 
podem ser manipulados, correlacionados para apoio a 
tomada de decisão. Aqui criam-se os modelos analíticos, 
para a geração de um ambiente de conhecimento para 
consulta e recuperação de informação relevante. Aqui a 
modelagem estatística é usada para estabelecer relações 
e a programação linear para encontrar otimizações, 
modelagem preditiva e criar previsões.
EIS - Expert Information System: são sistemas de informação 
especializados, com capacidade de realizar inferências. 
Exemplo: técnicas de Machine Learning.
Considerando os níveis organizacionais EIS, DSS e parte do MI, dos quais 
a gestão estratégica e tática fazem parte, um projeto final da construção 
de DW deverá ter as seguintes características:
45
1. Disponibilidade da informação para a gerência.
2. Views (visões) representadas graficamente mostrando o 
comportamento.
3. Rápido tempo de resposta de ferramentes de apoio à tomada 
de decisão.
4. Precisão nas informações disponibilizadas.
5. Visão de indicadores expandida.
6. Abragência de recursos para analytics.
7. Acesso às solicitações e expectativas das análises especializadas 
da alta gerência supridas por meio da Tecnologia da Informação.
ASSIMILE
O objetivo do DW é disponibilizar informações para o apoio 
à tomada de decisão das organizações, por meio de uma 
base de dados somente leitura.
Não existe DW pronto para ser utilizado sem esforço 
anterior em levantar as necessidades da organização e seus 
executivos.
Construir um DW exige estudo e envolvimento da empresa 
e seus colaboradores.
Resumindo, a construção de um DW exige a transferência e a 
transformação dos dados históricos dos sistemas organizacionais, 
coletados nas operações diárias, para uma base de dados independente, 
a qual no contexto da DW usa dados somente para operações 
de consulta. Nessa construção, o DW tem uma composição de 
conjunto específico, orientada por assunto, com vários subconjuntos 
denominados Data Marts.
46
3. Composição do ambiente de Data Warehouse
Machado (2011) afirma que a tecnologia de DW é considerada uma 
evolução do Ambiente de Apoio à Decisão. Isso significa que, com os 
avanços tecnológicos de DW, os Ambientes de Apoio à Tomada de 
Decisão passaram a ser denominados de Ambientes de DW, constituídos 
de repositórios de Data Marts (DM). Assim, vários DM compõem o DW. 
O DM representa um subconjunto de dados do DW, em geral por 
assunto ou departamento (MACHADO, 2011). Como o DW representa 
um alto custo para a organização, os DM podem ser reconhecidos 
como uma versão reduzida de um DW, facilitando a implementação 
de analytics departamental. O DM é representado como um pequeno 
DW projetado para uma unidade de negócio, que é o departamento da 
organização (TURBAN, 2005). Como exemplo, o departamento de vendas 
de uma empresa pode ser considerado um DM em relação a seus dados 
e a suas informações.
Um DW consiste na integração dos dados da organização para análises 
gerenciais e estratégicas, consolidadas por meio das informações de 
fontes internas, fontes heterogêneas, fontes externas, sumarizações, 
agrupamentos, filtragem e preparação de dados. Sob um ponto de 
vista físico, ele é um banco descendente de dados relacionais, só que 
projetado para consulta e análise. Tem dimensões e tabelas fato, que 
são mescladas para serem consultadas. Um banco DW nunca poderá ter 
transações de escrita e leitura, pois estas são características do banco 
transacional. É importante lembrar que o DW é conceitualmente um 
banco Read Only, ou seja, somente de leitura.
O DW contém dados históricos derivados de dados transacionais, 
incluindo dados de outras fontes e novos dados, advindos de resultados 
da mesclagem dos dados, ou, ainda, de fórmulas calculadas incluídas 
na coluna de uma tabela. Ele tem uma composição que separa a carga 
de trabalho para análise da carga de trabalho para transações. No 
47
primeiro caso, permite a consolidação de diferentes fontes nessa carga 
de trabalho analítica.
Além de ferramentas analytics e demais aplicações para o 
gerenciamento da coleta de dados e da entrega dos resultados prontos 
para serem consumidos, a composição do DW inclui:
• ETL - Extract Tranform Load : extração, transformação e 
carregamento dos dados para o DW. Por exemplo: uma empresa 
do ramo alimentício tem seus dados armazenados no banco de 
dados transacionais, e a ferramenta de ETL irá carregar somente 
os dados de interesse para análises para o banco de dados 
repositório do DW. Outro exemplo é a ETL ser feita
somente com 
as vendas diárias dos produtos alimentícios, mas, se houver a 
necessidade de uma análise por hora, os dados dos horários das 
vendas deverão ser carregados pela ETL.
• OLAP - Online Analytical Processing : processamento analítico em 
tempo real. Por exemplo, uma análise está sendo feita por ano, na 
dimensão temporal, mas o usuário precisar mudar para uma visão 
por trimestre ou diária. A ferramenta OLAP tem que possibilitar 
essa granularidade da dimensão tempo para que o usuário tenha 
as visões por ano, por dia e por trimestre, conforme sua interação. 
A interação acontece por meio de filtros na dimensão tempo.
Um DW possui um conjunto característico personalizado, distintamente 
dos ambientes convencionais das organizações. Por esse motivo, não 
há como replicar um DW de uma empresa para outra. Assim, cada 
projeto de DW é único, não na essência, mas no seu modo de operação 
e aplicação. Ao final do desenho do projeto, ele deverá apresentar um 
rol de atribuições, elencadas a seguir no Quadro 1, para cumprir a sua 
finalidade.
48
Quadro 1 – Atribuições de um DW
Atribuição Caracterização Exemplo
a) Extração dos dados. Fontes diversas (internas e 
externas).
Data completa, 
produtos, preço.
b) Transformação 
dos dados.
Necessidade de mesclagem 
ou combinação de dados, 
gerando novos dados 
específicos.
Normalização da data, 
valores maiores que zero.
c) Infraestrutura 
tecnológica e manutenção.
Específica para essa 
finalidade.
Servidores de serviços.
d) Representação 
dos dados.
Visualizações gráficas, 
tabuladas, sumarizadas 
pronta para consumo 
conforme perfil 
dos usuários.
Gráfico percentual de 
desepenho de vendas.
e) Especialização. Dados podem ser extraídos 
ou não para níveis mais 
específicos, os Data Marts, e 
destes para bases de dados 
individualizadas.
Inclusão de filtros nas visões
f) Acesso. Personalizado por meio de 
ferramentas que promovem 
acessos com diferentes 
níveis de apresentação.
Usuários com níveis de 
acesso as visões.
g) Não há atualização. As atualizações ou 
updates não ocorrem 
diretamente no DW.
As atualizações de dados 
ocorrem no banco 
transacional e deste uma 
cópia é carregada para o 
banco do DW.
Fonte: adaptado de Turban (2005, p. 86-89).
Vale reforçar que os dados atualizados na base transacional e de outras 
fontes não são carregados no DW diretamente, ou seja, primeiro a carga 
ocorre em outro banco. Isso significa que esses dados provenientes de 
atualizações em outras fontes são extraídos, transformados e depois 
49
carregados para o DW. Em geral, ficam em uma área chamada stage, 
um banco estacionário de espera da carga. Para ilustrar, a Figura 9 
representa um esquema de fluxo que antecede a entrada de dados em 
um banco DW e a saída deste com resultados prontos para consumo.
Os dados originais ou fontes de dados (data sources) armazenados em 
diferentes bancos de dados, internos e externos, no caso provenientes 
de CRM, ERP e supply chain (dados da cadeia de fornecimento), são 
extraídos por uma ferramenta de ETL e, em seguida, transformados 
e carregados para o banco estacionário do DW. No DW, ocorrem 
as técnicas necessárias para gerar os processamentos das análises 
em tempo real (OLAP), da mineração de dados (Data Mining) e da 
visualização de relatórios (reporting).
Figura 9 – Fluxo de dados de um DW
Fonte: vaeenma/iStock.com. 
50
O DW da Figura 9 mostra que ele armazena dados de forma agrupada 
ou por assunto, dados do CRM, dados do ERP e dados da supply chain. Os 
bancos de dados transacionais são orientados por processo, enquanto o 
DW é orientado por assunto. Assim, seu armazenamento é, na realidade, 
uma transformação dos dados operacionais e das transações do dia 
a dia da organização, com algum tipo de valor agregado por meio de 
sumarizações, contagens, filtragens, agregações, correlações etc.
Por que sumarizações, contagens, filtragens, agregações, correlações 
etc. geram valor aos dados operacionais? Porque essas técnicas 
incluem algum tipo de informação modelada matematicamente. Uma 
sumarização é um resumo dos resultados estatísticos básicos. Por 
exemplo, um comando summary em linguagem de software estatístico 
R nos retornará para um conjunto de dados, média, mediana, moda, 
quartis, valores máximo e mínimo. Um filtro pode associar lógicas como 
“e”, “ou”, “=”, entre outras, para que os relatórios mostrem dados com 
detalhes associados ou não. Contagens são importantes em análises, 
pois representam o universo dos dados por meio de quantificações, 
o que, de certa forma, contribui para análises qualificadas quando 
comparações de contagem são realizadas; algumas técnicas são a 
frequência por amplitude, histogramas, séries temporais etc.
A filtragem no âmbito de DW tem dois sentidos: um interfere nos 
resultados das análises e usa o filtro como estratificador no ETL. O 
primeiro como filtro refere-se à lógica – e, ou, igual, entre, não nulo etc. 
–, que no contexto do usuário foi disponibilizado na forma de cubo para 
seleção e leitura do banco de dados do DW. No segundo caso, um filtro 
como estratificador na ETL significa a disponibilização de parte, uma 
amostra, um extrato dos dados que serão carregados para o banco do 
DW. A Figura 10 mostra o fluxo dos dados, na entrada e saída do DW, 
assim como o filtro na ETL como extrator e o filtro no cubo para análises.
51
Figura 10 – Entrada e saída do ambiente de DW
 
Fonte: adaptada de Turban (2005, p. 82, 84, 87).
Todo o fluxo dos dados em um projeto de entrada e saída de um DW 
tem por alvo municiar informações a um grupo de pessoas que precisam 
de apoio para tomar decisões. Essa construção vem da necessidade 
gerada por esse grupo em um contexto norteado pelas competências de 
determinado tipo de negócio.
A entrada e a saída do DW requerem que a composição do ambiente 
tenha aspectos orientados ao fluxo dos dados, dentro os quais 
caracterizam-se os listados no Quadro 2. De maneira geral, essas 
orientações são aquelas que devem nortear a visão macro do 
projeto de DW.
52
Quadro 2 – Características da visão macro de um projeto DW
Características Detalhamento
Orientação 
por assunto.
• Agrupamento por assuntos de interesse.
• Indicadores analíticos e desempenho.
Variação de tempo. • Datas são componentes chave.
• Janelas de tempo.
• Alta temporalidade.
Volatividade. • Carga incial e incremental.
• Acesso em modo leitura (read).
Integração. • Padronização dos dados.
• Filtragem, amostra, agregação.
Arquitetura. • Ferramentas de carga inicial e atualizações 
periódicas.
• Ferramentas de limpeza dos dados.
• Ferramentas de consultas.
• Data Marts.
Papeis. • Recursos Humanos.
Centralização de 
competências.
• BI.
Fonte: adaptado de Machado (2011, p. 29-31).
Um DW precisa ser relevante para o grupo de pessoas competentes 
que toma as decisões na organização. Esse grupo precisa olhar para 
o desempenho da empresa e dos negócios e ver que tipo de produto 
ou serviço está em um ciclo de lucro e de queda. Quanto tempo o ciclo 
positivo desses produtos ou serviços dura? Perguntas são feitas por 
essas pessoas, as quais precisam amparar suas respostas na relevância 
dos dados da empresa.
De uma maneira ampla, a composição de um DW inclui os dados 
estruturados, as formas de comunicação dos dados em diferentes 
pontos de armazenamento, o processamento e representação da 
informação ao usuário ou cliente.
53
4.	Considerações	finais
Fazendo um fechamento, vale reforçar que o DW auxilia a empresa a 
entender o desempenho dos negócios a partir do conhecimento sobre 
os seus dados. Para isso, não basta disponibilizá-lo a quem decide, é 
preciso que se crie um contínuo fluxo de entrada e saída de dados e 
que se gere um valor para quem os consume dentro da empresa. As 
considerações apresentadas mostram a necessidade da participação 
de várias entidades da organização, como a área de TI, a área de 
banco de dados, os gestores de departamentos, os funcionários do 
operacional e o alto escalão, de maneira a estarem
alinhados com 
o projeto. Também são necessários a preparação da implantação, a 
manutenção e a atualização e o uso estratégico efetivo do DW dentro 
da corporação. Vale refletir sobre como criar um fluxo contínuo dentro 
da organização, desde a origem dos dados até as análises oferecidas 
aos analistas, para que o projeto de DW se torne indispensável às ações 
estratégicas internas.
TEORIA EM PRÁTICA
A empresa Fisioampla é especailizada em serviços de saúde 
de fisioterapia e possui filiais em diversos locais do País. Ela 
tem cadastrados cerca de 1.200.000 clientes que utilizam 
os serviços especilizados de fisioterapia na matriz e em 30 
filiais. Além dos serviços, presta consultas especilizadas 
para reabilitação de acidentados, pessoas com mobilidade 
reduzida e idosos. Cada clínica possui um amplo sistema de 
reabilitação e atendimento com fisioterapeutas associados. 
Há consultas clínicas que, além de recomendarem as 
sessões de fisiterapia, recomendam o uso de produtos que 
vão auxiliar na reabilitação ou na redução dos problemas 
relacionados.
Para extrair valor dos seus dados, a Fisioampla contratou 
você para estruturar um projeto de DW. Analise o 
cenário e proponha uma arquitetura para que a empresa 
54
tenha ideia de como os seus dados serão utilizados. 
Também faça simulações de quais análises poderiam ser 
alcançadas com visualizações analíticas que surgiriam do 
uso dessa arquitetura. Você pode listar alguns exemplos 
de visualizações em relação à dimensão tempo, como: 
Que tipo de paciente é atendido nos quatro trimestres do 
ano? Qual tipo de fisoterapia é mais solicitada e em qual 
época do ano? Elenque mais oito questões associadas 
com a dimensão tempo que poderiam ser de interesse da 
Fisioampla.
VERIFICAÇÃO DE LEITURA
1. Com a evolução de sistema de suporte à decisão, por 
que os contextos na construção de banco de dados 
operacionais e analíticos precisam ser diferentes?
a. Porque há uma inabilidade dos bancos de dados 
operacionais.
b. Porque o banco de dados operacional não precisa 
ser físico.
c. Porque o banco de dados analítico não pode ser um 
banco lógico.
d. Porque a volumetria exigida não pode ser suportada 
em bancos operacionais.
e. Porque há uma inabilidade nas execuções 
matemáticas dos bancos de dados analíticos.
2. O que garante que todos os recursos de dados estejam 
disponíveis para serem utilizados, compartilhados e 
manejados de forma fácil e eficiente?
55
a. As consultas ao banco de dados.
b. A estratégia de dados.
c. As análises e relatórios.
d. A qualidade dos dados.
e. A existência de um DW.
3. O que é uma coleção orientada por assuntos, integrada, 
variante no tempo e não volátil, e que apoia o processo 
de tomada de decisão das organizações?
a. Um banco de dados operacional.
b. Um Data Mart.
c. Um Data Warehouse.
d. Um banco de dados analíticos.
e. Um banco de dados transacionais.
Referências	Bibliográficas
INMON, W. H. Building the Data Warehouse. 4. ed. New York: Wiley Computer 
Publishing, 2005.
KIMBALL, R. The Data Warehouse Toolkit: guia completo para modelagem 
dimensional. Rio de Janeiro: Campus, 2002.
MACHADO, F. N. R. Tecnologia e Projeto de Data Warehouse. 5. ed. São Paulo, 
Editora Érica, 2011.
TURBAN, E. Administração de tecnologia da Informação. Editora Campus, 2005.
Gabarito
Questão 1 - Resposta A
Resolução: Com o objetivo de ampliar o entendimento acerca da 
necessidade de separar contextos de construção de ambientes 
para banco de dados, Inmon (2005) destaca as diferenças, entre 
56
os dados operacionais e os dados analíticos. Essa diferença é 
decorrente na evolução de sistema de suporte a decisão e a 
inabilidade dos bancos de dados operacionais fornecerem 
insumos para esse fim.
Questão 2 - Resposta B
Resolução: A estratégia de dados garante que todos os 
recursos de dados estejam disponíveis para serem utilizados, 
compartilhados e manejados de forma fácil e eficiente e que 
sejam consumidos como ativo dentro da organização. Os data 
sets fornecem métricas e indicadores a todos os projetos da 
organização.
Questão 3 - Resposta C
Resolução: Na conceituação dada por Inmonn (2005), o DW 
é uma coleção orientada por assuntos, integrada, variante no 
tempo e não volátil, para apoiar o processo de tomada de decisão 
das organizações. Na definição de Kimball (2002), ele é a cópia 
específica de tabelas do banco transacional para consultas e 
análises, criando visões funcionais. Um projeto de construção de 
um DW depende fundamentalmente de arquitetura, e, por isso, 
Machado (2010) deixa claro que o “DW é uma arquitetura e não 
uma tecnologia”, pois a tecnologia, sim, ajuda a construir, operar e 
monitorar um projeto DW implantado.
Data Marts
Autora: Iolanda Cláudia Sanches Catarino
Objetivos
• Conhecer e compreender os fundamentos sobre 
Data Marts.
• Conhecer e compreender a arquitetura padrão de 
Data Warehouses.
• Conhecer e compreender os tipos de arquiteturas e 
implementação de Data Marts.
58
1. Fundamentos sobre Data Marts
As organizações precisam responder de maneira ágil e eficiente às 
mudanças e oportunidades de mercado. Tomar decisões estratégicas 
exige análise e interpretação de informações analíticas que identifiquem 
oportunidades, comportamentos e tendências da sociedade do 
conhecimento.
Os ambientes de Data Warehouse (DW) integram sofisticadas 
ferramentas para análises complexas de dados históricos e descoberta 
de conhecimento, assegurando o suporte à tomada de decisão, 
como exemplifica a Figura 1. Eles apresentam diferentes formatos de 
consultas dinâmicas e relatórios analíticos, disponibilizados aos usuários 
estratégicos, a partir de dashboards de ferramentas com recursos 
intuitivos para sua geração. A implantação de um DW demanda alto 
investimento, tempo e considerável esforço gerencial, sendo usado 
principalmente por grandes empresas.
Figura 1 – Acesso às ferramentas de um ambiente de 
Data Warehouse
Fonte: adapatada de cifotart/iStock.com. Fonte: adaptada de zmicierkavabata/
iStock.com.
Uma das principais características do DW é a integração dos dados de 
diferentes origens, proporcionando um ambiente estático, que não sofre 
https://www.istockphoto.com/br/portfolio/zmicierkavabata?mediatype=illustration
https://www.istockphoto.com/br/portfolio/zmicierkavabata?mediatype=illustration
59
modificações durante o seu acesso. Apenas novas cargas com dados 
atuais são inseridas, a partir de critérios previamente estabelecidos, 
permitindo, assim, o seu acesso por meio de ferramentas front-end e/ou 
aplicativos.
Na concepção de Inmon (1997), o DW é um agrupamento de dados 
que deve ser guiado por temas normalizados (integrados) para 
facilitar as consultas analíticas. É necessário também possuir níveis de 
granularidade e de armazenamento bem apurados. Além disso, em 
nenhuma hipótese, devem ser modificados (não-voláteis), pois esses 
dados são uma “fotografia” (snapshot) de determinada situação em um 
período específico. 
Esse procedimento certifica ao DW uma particularidade em sua 
utilização, tornando-o um ambiente com dois propósitos específicos 
distintos, o de carga de dados e o de acesso aos usuários. Dessa forma, 
para que um ambiente de DW seja consistente e eficaz, os dados 
precisam ser padronizados e consolidados para só depois serem 
disponibilizados no sistema, de modo que os administradores possam 
utilizá-los como ferramenta de apoio no processo decisório.
O DW organizacional pode manter um armazém central de dados 
da organização inteira ou pode manter armazéns menores, 
descentralizados, denominados Data Marts. Portanto, muitas empresas 
iniciam o desenvolvimento de DW estruturando-o em conjuntos 
de dados orientados por assunto ou categoria, para atenderem às 
necessidades de pequenos grupos de usuários ou de níveis funcionais 
da empresa, investindo, assim, na implementação de Data Marts.
Segundo Date (2004), os DW surgiram pela necessidade de fornecer 
uma origem de dados única, limpa e consistente para fins de apoio à 
decisão
e pela necessidade de fazê-lo sem causar impacto sobre os 
sistemas operacionais que normalmente têm exigências restritas de 
desempenho com cargas de trabalho previsíveis. Porém, percebeu-se 
60
que os usuários executavam extensivas operações de análise de dados 
sobre um subconjunto do DW completo, repetindo com frequência as 
mesmas operações sobre o mesmo subconjunto de dados. Dessa forma, 
a ideia de construir um espaço de armazenamento limitado, adaptado 
à finalidade imediata, extraindo e preparando os dados exigidos 
diretamente de fontes locais, assim como fornecendo acesso mais 
rápido aos dados, levou ao conceito de Data Marts.
Date (2004) descreve o Data Mart como “um depósito de dados 
especializado, orientado por assunto, integrado, volátil e variável no 
tempo, que fornece apoio a um subconjunto específico de decisões da 
gerência” (DATE, 2004, p. 604). Por especializado, entende-se que ele 
contém dados para apoio a uma área específica de análise comercial 
e, por volátil, entende-se que os usuários podem atualizar os dados e 
talvez até mesmo criar novos dados para algum propósito.
Na concepção de Rob e Coronel (2011), um Data Mart é um pequeno 
subconjunto de um DW, sobre um único assunto, que fornece suporte às 
decisões de um pequeno grupo de pessoas, podendo ser criado a partir 
de dados extraídos de um DW maior, com o objetivo específico de dar 
suporte a acessos mais rápido para determinado grupo ou função, como 
ilustra a Figura 2, a qual conta com o DW Organizacional composto por 
três Data Marts: marketing, vendas e financeiro.
Rob e Coronel (2011) enfatizam que:
A única diferença entre um Data Mart e um Data Warehouse é o tamanho 
e o escopo do problema a ser resolvido. Portanto, as definições de 
problemas e as exigências de dados são essencialmente a elas para 
ambos. (ROB; CORONEL, 2011, p. 551)
De acordo com Laudon e Laudon (2014), um Data Mart é: 
61
Um subconjunto de um Data Warehouse, no qual uma porção resumida ou 
altamente focalizada dos dados da organização é colocada em um banco 
separado destinado a uma população específica de usuários (LAUDON; 
LAUDON, 2014, p. 194)
Assim como na visão de Machado (2013), os Data Marts representam 
um subconjunto dos DW que permitem o acesso descentralizado à 
informação, podendo ser direcionados a um departamento ou a uma 
área específica do negócio.
Figura 2 – Ambiente básico de Data Warehouse
Fonte: elaborada pela autora.
Rainer e Cegielski (2011) destacam que um “Data Mart é um data 
warehouse pequeno, projetado para as necessidades do usuário 
final em uma unidade estratégica de negócios ou um departamento” 
(RAINER; CEGIELSKI, 2011, p. 126). Já Kimball et al. (1998), especialista no 
assunto, define que um Data Mart, também conhecido como Warehouse 
Departamental, é uma abordagem descentralizada do conceito de DW, 
caracterizando os seus principais benefícios como:
a. Demandam menos investimento porque são mais baratos.
b. Podem ser implementados mais rapidamente.
62
c. Apoiam as necessidades e o controle local de grupos de usuários 
por níveis funcionais.
d. Fornecem uma resposta mais rápida aos grupos de usuários.
e. Disponibilizam consultas mais fáceis de serem analisadas e 
navegadas.
Machado (2013) afirma que uma das principais vantagens de se 
implantar um Data Mart em uma empresa é a possibilidade de 
retorno rápido, garantindo um maior envolvimento do usuário final, 
capaz de avaliar os benefícios extraídos de seu investimento.
A partir das definições apresentadas, conclui-se que um Data Mart é 
um subconjunto lógico e físico da área de representação de um DW 
que agrupa dados sobre um único assunto para fornecer suporte 
às decisões de um grupo de pessoas específicas. Contudo, algumas 
empresas optam por implementarem primeiramente o Data Marts 
para a posterior migração para um DW, considerando que pessoas 
em níveis organizacionais e funcionais diferentes necessitam de 
dados com formatos distintos de agregação, síntese e apresentação, 
além de menor investimento.
2. Arquitetura de Data Warehouses e Data Marts
O funcionamento de uma arquitetura padrão de DW consiste na 
integração das diversas fontes de dados com o ambiente de extração 
e transformação, com a base de dados do DW, mecanismos de 
comunicação, processamento e com ambientes intuitivos para os 
usuários, a partir de ferramentas de consultas dinâmicas com interfaces 
de apresentação das informações interativas.
O processo de extração dos dados obtidos de diversas fontes de dados 
operacionais, transformação e carga em DW normalmente prevê um 
63
estágio intermediário de preparação, sincronização e integração dos 
dados. Ferramentas de Extraction, Transformation and Load (ETL) são 
responsáveis pela extração, transformação e carregamento dos dados 
no DW. Durante esse estágio, eles permanecem em uma área de 
armazenamento intermediária entre as bases de dados operacionais 
e o DW para realização das ações de limpeza e integração dos dados. 
Essa área de armazenamento intermediária é conhecida como Staging 
Area, Data Staging ou Operational Data Store (ODS – Depósito de Dados 
Operacionais).
Inmon (1997) explica que um depósito de dados operacional é uma 
coleção de dados orientada por assunto, integrada, volátil (atualizável), 
atual ou quase atual. O objetivo principal do Staging Area é criar um 
ambiente intermediário de armazenamento e processamento dos 
dados para o processo ETL, possibilitando o tratamento dos dados 
para permitir sua posterior integração em formato e tempo, o que evita 
problemas após a criação do DW e a concorrência com o ambiente 
transacional no que diz respeito ao consumo de recursos. A Figura 3 
representa o processo de ETL com o Staging Area.
No lado esquerdo da figura, estão as fontes de dados, que são 
compostas respectivamente por sistemas Online Transaction Processing 
(OLTP), dados externos, outras fontes e arquivos simples (flat files). 
No centro da figura, está a Staging Area e no lado direito está o DW. A 
extração é a fase em que os dados dos sistemas são transportados de 
diferentes fontes para uma base de dados para serem transformados. 
A transformação é a etapa em que são tratados, corrigindo erros de 
integridade, de redundância, de digitação etc. e integrando-os em um 
modelo único para ser utilizado no DW. A carga é a fase em que os 
dados são levados da Staging Area para um ou mais Data Marts, para 
então serem consultados por meio das aplicações dos usuários.
64
Figura 3 – Processo de ETL com Staging Area
Fonte: elaborada pela autora.
PARA SABER MAIS
Online Transaction Processing (OLTP – Processamento 
de Transações em Tempo Real): os sistemas OLTP são 
transacionais e registram todas as transações operacionais 
das organizações. São utilizados no processamento dos 
dados que são gerados diariamente por meio dos sistemas 
informacionais das empresas.
ASSIMILE
O ambiente de processamento de dados analíticos difere 
do ambiente de dados transacionais ou operacionais. 
Os sistemas OLTP servem como fonte de dados para o 
ambiente de DW, enquanto as ferramentas Online Analytical 
Processing (OLAP – Processamento Analítico On-line) 
65
auxiliam na análise dinâmica e multidimensional de dados 
consolidados, permitindo que o usuário final tenha uma 
visão completa das informações analiticamente.
Machado (2013) descreve que uma Staging Area permite ao 
administrador do DW extrair os dados no momento em que estão 
disponíveis, para, posteriormente, integrá-los, facilitando as extrações 
dos sistemas operacionais durante períodos fora do pico de operações. 
Um ODS pode ser usado também como área provisória para 
reorganização física dos dados operacionais extraídos de várias fontes, 
como dos sistemas legados da empresa e de demais sistemas e serviços 
da internet, em um único formato que será mantido no DW.
Segundo Kimball et al. (1998), além da Staging Area, o ideal é que exista 
uma segunda área intermediária, o ODS, antes da carga definitiva 
para o DW. Um
ODS deve ser uma base de dados obtida da extração, 
transformação e limpeza de dados dos sistemas fontes operacionais da 
empresa. Com um ODS, não é necessário refazer toda a extração para 
corrigir eventuais problemas na transferência dos dados para o DW.
Para Machado (2013), o ODS não é um componente indispensável 
em um DW, sendo sua criação uma decisão de projeto. Contudo, por 
economia de espaço de armazenamento em disco, muitos DW são 
implementados sem ODS.
Muitos projetos de DW possuem ODS e utilizam essa área para fazerem 
validações de regras de negócio, enquanto na Staging Area ocorre a 
limpeza, verificando chaves repetidas e problemas de integridade 
referencial. A Figura 4 ilustra a arquitetura de um DW com Staging Area e 
Data Marts.
66
Figura 4 – Arquitetura de um Data Warehouse 
com uma Staging Area e Data Marts
Fonte: elaborada pela autora.
No lado esquerdo da figura, estão as fontes de dados, que, nesse 
exemplo, são compostas pelos sistemas operacionais e flat files 
(arquivos simples). Um pouco mais à direita, está a Staging Area. 
No centro da figura está o DW, que é composto pelos metadados, 
dados resumidos e dados brutos, ou seja, os dados obtidos com 
seus valores de origem e que são armazenados sem sofrerem 
nenhum tratamento. Um pouco mais à direita, estão os Data Marts 
categorizados em marketing, vendas e financeiro. Por fim, no lado 
direito da figura, estão as ferramentas de apoio à decisão – Analysis 
Reporting, OLAP e Data Mining. 
De acordo com a figura, os dados são extraídos das fontes de 
dados e transportados para a Staging Area, na qual os dados 
são transformados. Após o processo de transformação, eles são 
carregados no DW. Em seguida, são extraídos do DW e carregados 
67
nos Data Marts para uso posterior, e, quando necessário, os usuários 
acessam os Data Marts utilizando ferramentas de apoio à decisão.
Em certos casos, um projeto começa com o desenvolvimento de um 
DW e se compõe em vários Data Marts. No entanto, um Data Mart 
pode também ser criado de modo independente, sem a necessidade 
de extrair os dados do DW. Algumas empresas utilizam essa técnica, 
criando primeiro os Data Marts conforme a necessidade e depois o 
Data Warehouse, como uma consolidação dos diversos Data Marts 
(DATE, 2004).
3. Tipos de arquitetura e implementação
A escolha da arquitetura é uma decisão que causa impactos quanto 
ao sucesso do projeto, podendo afetar no tempo de execução, no 
retorno do investimento, na velocidade dos benefícios da utilização 
das informações, na satisfação do usuário e nos recursos necessários à 
implementação de uma arquitetura.
Para a definição de uma arquitetura de DW ou de Data Marts, deve-
se levar em conta, principalmente, o porte da empresa, a qualificação 
e a experiência dos profissionais de tecnologia da informação e 
comunicação e os recursos disponibilizados para o investimento. 
Contudo, a arquitetura pode ser definida ou modificada após o começo 
da implementação. Nesse caso, depois que o projeto de DW é iniciado, 
para mudar a sua arquitetura, será despendido um longo tempo, 
atrapalhando o andamento do projeto. Por isso, é importante ela já 
estar definida no início do projeto.
A arquitetura de um DW abrange um conjunto de ferramentas que 
envolve a carga inicial dos dados até a geração de consultas que 
68
apoiam os usuários no processo de tomada de decisão. Alguns fatores 
interferem na escolha da arquitetura e implementação, tais como:
a. Tempo para execução do projeto.
b. Estrutura das instalações físicas da empresa.
c. Rápido retorno do investimento.
d. Satisfação dos usuários estratégicos.
A definição de uma arquitetura determina o local em que o DW ou os 
Data Marts estarão alocados fisicamente. Machado (2013) apresenta 
a seguinte classificação das arquiteturas: global, independente e 
integrada, podendo o tipo de implementação ser top down, bottom up e a 
combinada.
A arquitetura global é considerada a que mais comporta as necessidades 
de um DW integrado com alto nível de acessos e utilização das 
informações para todos os departamentos de uma empresa, podendo 
ser fisicamente centralizada ou fisicamente distribuída nas instalações 
da empresa. Normalmente, o DW é global, ou seja, reflete o escopo 
de acessos em um repositório comum de dados com a geração 
das informações para o suporte à decisão, disponível para toda a 
empresa. Nesse tipo de arquitetura, consome-se muito tempo de 
desenvolvimento e administração, e seu custo de implementação é 
muito alto. (MACHADO, 2013).
A Figura 5 ilustra os dois caminhos de utilização de uma arquitetura 
global, a global centralizada e a global distribuída, podendo em ambas 
o acesso aos dados ser realizado de locais fisicamente separados. 
Mesmo assim, todas as estruturas têm acesso a todas as informações 
da empresa. O topo da Figura 5 ilustra que o DW está distribuído em 
três instalações físicas de uma empresa e, na parte inferior, mostra que 
o DW está mantido em uma única instalação física da empresa, ou seja, 
centralizado, considerando que a empresa existe em um único local.
69
Figura 5 – Arquitetura global do tipo centralizada e distribuída
Fonte: adapatada de Machado (2013).
A arquitetura independente mantém Data Marts stand-alone, em 
que há dados específicos da necessidade da empresa, considerando 
que cada departamento tem sua informação sem a integração com 
outros departamentos. Contudo, há restrição quanto a um mínimo de 
integração organizacional e não permite nenhuma visão global. Esse 
tipo de arquitetura é controlado por um grupo específico de usuários, 
atendendo às necessidades específicas. Sua implementação é rápida e 
de poucos impactos nos recursos de tecnologia da informação, sendo, 
assim, a arquitetura mais adotada pelas empresas.
A Figura 6 exemplifica a arquitetura do tipo independente, na 
qual cada estrutura ou departamento pode ter suas informações 
específicas, categorizando-as em Data Marts separados, não se tendo a 
obrigatoriedade de essas informações serem integradas.
70
A arquitetura integrada de Data Marts é implementada por Data Marts 
separadamente em grupos específicos ou departamentos, os quais são 
integrados ou interconectados, provendo uma visão organizacional 
maior dos dados e das informações (MACHADO, 2013).
Figura 6 – Arquitetura independente de Data Marts
Fonte: adapatada de Machado (2013).
A arquitetura integrada requer mais complexidade no projeto de 
especificação dos requisitos dos Data Marts, devido à proposta de 
integração dos dados e das informações, aumentando a capacidade e 
a qualidade de visão corporativa das informações. Uma vantagem da 
arquitetura integrada é que os usuários de um departamento podem 
acessar e utilizar os dados de um Data Mart de outro departamento. A 
Figura 7 ilustra uma arquitetura integrada, em que cada departamento 
tem suas informações específicas, mas suas informações são integradas 
com os outros departamentos, a partir da integração de dois ou mais 
Data Marts.
71
Figura 7 – Arquitetura integrada de Data Marts
Fonte: adapatada de Machado (2013).
As abordagens de implementação de Data Marts são classificadas em top 
down, bottom up e a combinada.
A implementação do tipo top down é conhecida como a proposta 
mais adotada e recomendada de implementação de Data Marts para 
um ambiente de DW. Exige-se inicialmente o envolvimento de todos 
os departamentos da empresa para planejamento completo sobre 
as fontes de dados que serão utilizadas; a análise e o projeto dos 
requisitos e das estruturas de dados; a especificação da qualidade dos 
dados a serem considerados; a definição da padronização dos dados; a 
recuperação dos modelos de dados dos sistemas transacionais vigentes; 
o projeto de segurança; e as definições das tecnologias que serão 
adotadas para o desenvolvimento do DW.
Esse tipo de implementação força a empresa a definir regras de 
negócios de forma corporativa antes de iniciar o projeto de DW. O 
processo inicia-se com a extração, a transformação
e a integração dos 
72
dados dos sistemas operativos e dos dados externos para a Staging Area 
e/ou para um ODS, para, posteriormente, serem transferidos para o DW. 
A partir do DW, são extraídos os dados e metadados para os Data Marts 
(MACHADO, 2013).
A Figura 8 ilustra a implementação do tipo top down, com a extração de 
dados de sistemas transacionais, fontes externas, sistemas legados e 
arquivos simples, nos quais essas informações passam por um processo 
de extração e transformação, iniciando na Staging Area e no ODS até 
o desenvolvimento dos Data Marts, a partir do DW, para posterior 
disponibilização das informações, a partir de diferentes ferramentas de 
apoio à decisão – Analysis Reporting, OLAP e Data Mining.
Figura 8 – Tipo de implementação Top Down
Fonte: elaborada pela autora.
O Quadro 1 elenca as vantagens e desvantagens da implementação top 
down, segundo Machado (2013).
73
Quadro 1 – Vantagens e desvantagens da implementação Top Down
Vantagens
1. Herança de arquitetura: os Data Marts originados a partir de um DW utilizam a 
mesma arquitetura e os mesmos dados, permitindo uma fácil manutenção.
2. Visão de empreendimento: o DW concentra o histórico de negócio da empresa, 
permitindo a extração em níveis menores de informações.
3. Repositório de metadados centralizado e simples: o DW provê um repositório de 
metadados central para o sistema, provendo manutenções mais simples.
4. Controle e centralização de regras: garante a existência de um único conjunto de 
aplicações para extração, limpeza e integração dos dados, e de processos centra-
lizados de manutenção e monitoração.
Desvantagens
1. Implementações muito longas: os DW são normalmente desenvolvidos de modo 
iterativo por áreas de assunto, sendo necessário uma média de 15 ou mais me-
ses para que a primeira área de assunto entre em produção.
2. Alta taxa de risco: dificuldade em garantir e sustentar o investimento neste tipo 
de ambiente.
3. Heranças de cruzamentos funcionais: necessidade de equipes de desenvolvi-
mento e de usuários finais altamente qualificados que acompanhem as deman-
das vigentes e emergentes da organização.
4. Expectativas relacionadas ao ambiente: a demora do projeto e a falta de retorno 
rápido podem induzir expectativas desagradáveis nos usuários.
Fonte: adaptado de Machado (2013).
A implementação do tipo bottom up permite a implementação 
incremental do DW por meio do desenvolvimento de Data 
Marts independentes. Ela vem se popularizando em virtude de 
a implementação top down exigir alto investimento financeiro e 
tecnológico. O processo começa na extração, transformação e 
integração dos dados para um ou mais Data Marts, baseados em um 
modelo dimensional. Esse tipo de implementação pode trazer um 
grande problema de redundância de dados e inconsistências, devido ao 
DW ser desenvolvido de forma incremental, mas poderá ser minimizado 
por meio de planejamentos e boas práticas de projetos de software.
74
A Figura 9 exemplifica a implementação bottom up, a qual se inicia de 
forma incremental em cada Data Mart para a posterior composição do 
DW, formando, assim, uma estrutura de múltiplos Data Marts.
Figura 9 – Tipo de Implementação Bottom Up
Fonte: adapatada de Machado (2013).
O Quadro 2 elenca as vantagens e desvantagens da implementação 
bottom up, segundo Machado (2013).
Quadro 2 – Vantagens e desvantagens 
da implementação Bottom Up
Vantagens
1. Implementação rápida: o desenvolvimento dos Data Marts é direcionado por as-
sunto, permitindo um rápido desenvolvimento e, posteriormente, em produção.
2. Retorno rápido: a arquitetura baseada no desenvolvimento incremental de Data 
Marts demonstra o seu valor e confiança para o usuário final.
3. Manutenção do enfoque da equipe: a elaboração de Data Marts incrementais 
permite que os principais negócios sejam focados inicialmente, sem que haja 
gastos no desenvolvimento de áreas que não são essenciais ao problema.
4. Herança incremental: a estratégia de desenvolvimento de Data Marts de forma 
incremental porporciona confiança e expertise das equipes, minimizando os ris-
cos e problemas característicos de projetos de software.
75
Desvantagens
1. Perigo de legamarts: os Data Marts independentes transformam-se em Data Mar-
ts legados, ou legamarts que podem dificultar, quando não inviabilizam futuras 
integrações, gerando problemas e não soluções.
2. Desafio de possuir a visão de empreendimento: dificuldade em manter um rí-
gido controle de negócio ao extrair e combinar as fontes individuais durante o 
desenvolvimento de Data Marts incrementais.
3. Administrar e coordenar múltiplas equipes e iniciativas: dificuldade em manter 
um rígido controle durante o processo de desenvolvimento de Data Marts em 
paralelo, tentando coordenar os esforços e recursos das múltiplas equipes, es-
pecialmente nas áreas de regras e semântica empresariais.
Fonte: adaptado de Machado (2013).
A Figura 10 representa a implementação do tipo combinada, que tem o 
propósito de integrar as arquiteturas top down e a bottom up. Segundo 
Machado (2013), nessa abordagem, elabora-se a modelagem de dados 
da visão macro do DW e, posteriormente, implementa-se os Data Marts. 
A principal vantagem dessa abordagem é a garantia da consistência dos 
dados obtida em virtude do modelo de dados único do DW, consistindo 
no mapeamento e na implementação dos Data Marts.
Figura 10 – Tipo de implementação combinada
Fonte: adapatada de Machado (2013).
76
4. Considerações Finais
A busca por informações que amparassem o trabalho dos tomadores de 
decisão passou a ser uma constante, pois percebeu-se que as empresas 
guardavam um patrimônio digital em seus bancos de dados e que os 
administradores poderiam aprimorar seus processos e usufruir desse 
patrimônio digital. Ao transformar a informação em conhecimento, poder-
se-ia potencializar e agregar valor aos negócios.
Ao longo das décadas, identificou-se a necessidade de dividir as tarefas 
de gerenciamento e análise dos dados em diferentes níveis gerenciais, 
crescendo, assim, a necessidade de respostas mais rápidas, seguras, 
confiáveis e que melhor se adaptassem às necessidades do gerenciamento 
da empresa e dos negócios. A partir desse cenário, surgiram os ambientes 
de DW organizacional, que geralmente mantêm um armazém central de 
dados da organização inteira, ou armazéns menores, descentralizados, 
denominados Data Marts. Assim, um Data Mart é um subconjunto de um 
DW que agrupa dados sobre um único assunto para fornecer suporte às 
decisões de um grupo de pessoas específicas.
TEORIA EM PRÁTICA
Vamos tomar como base uma das maiores redes de 
farmácias e drogarias do segmento de varejo farmacêutico 
nacional, com aproximadamente 550 lojas nos 25 estados 
e Distrito Federal. Essa rede investiu R$ 35 milhoes em 
novas lojas e reformas, incluindo a reestruturação da 
arquitetura global do tipo distribuída do ambiente de Data 
Warehouse e Data Marts da rede que está concentrada nas 
regiões Sul e Sudeste do País. Assim, considerando que 
a rede pretende aprimorar os serviço de atendimento 
personalizado aos seus clientes, faça um levantamento e 
escolha uma tecnologia emergente para integrar o novo 
77
ambiente de Data Warehouse organizacional de serviços de 
inteligência artificial que agregue inteligência ao negócio 
e principalmente proporcione novas funcionaliades, a fim 
de garantir a customização ágil aos clientes. A partir da 
definição da tecnologia emergente de inteligência artificial, 
elenque as principais etapas para o projeto da nova 
arquitetura do Data Warehouse organizacional e relacione 
algumas nos serviços que poderão ser disponibilizados aos 
usuários estratégicos e/ou clientes.
VERIFICAÇÃO DE LEITURA
1. Uma das principais características de um ambiente de 
Data Warehouse é a interação dos dados de diversas 
fontes distintas, proporcionando um ambiente estático, 
que não sofre modificações. O Data Warehouse 
organizacional pode manter um armazém central de 
dados da organização
inteira ou também menores, 
descentralizados, denominados ____________________. 
Assinale a alternativa correta que preenche a lacuna:
a. Data Sources.
b. Data Marts.
c. Data Mining.
d. Ferramentas OLAP.
e. Staging Area.
78
2. Um Data Mart é um subconjunto lógico e físico da área 
de representação de um Data Warehouse que agrupa 
dados sobre um único assunto para fornecer suporte 
às decisões de um grupo de pessoas específicas. 
Sobre as principais características e/ou benefícios do 
desenvolvimento de Data Marts, julgue os itens a seguir: 
I. Apoiam as necessidades e o controle local de grupos 
de usuários por níveis funcionais ou departamentos de 
uma empresa. 
II. Demandam menos investimento que o 
desenvolvimento do Data Warehouse organizacional. 
III. Podem ser implementados mais rapidamente, 
fornecendo uma resposta mais rápida aos grupos 
de usuários. 
IV. Mantêm um depósito de dados central com níveis 
de granularidade e de armazenamento bem apurados e 
não são não-voláteis. 
 
Estão corretos os itens:
a. I – II.
b. II – III.
c. III – IV.
d. I – II – III.
e. I – II – III – IV.
3. A definição de uma arquitetura determina o local onde 
o Data Warehouse ou os Data Marts estarão alocados 
fisicamente. Para a definição de uma arquitetura, deve-
se levar em conta principalmente o porte da empresa, a 
qualificação e expertise dos colaboradores e os recursos 
disponibilizados para os investimentos. 
79
Assinale a alternativa correta que indica a classificação 
dos tipos de arquitetura de Data Warehouse e Data Marts:
a. Independente, centralizada e acoplada.
b. Independente, acoplada e coesa.
c. Transacional, integrada e funcional.
d. Global, transacional e aglomerada.
e. Global, independente e integrada.
Referências	Bibliográficas
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro: 
Campus, 2004.
INMON, W. H. Como construir o data warehouse. Rio de Janeiro: Campus, 1997.
KIMBALL, R. et al. The data warehouse lifecycle toolkit. New York: John Wiley & 
Sons, 1998.
LAUDON, K. C.; LAUDON, J. P. Sistemas de informação gerenciais. 11. ed. São Paulo: 
Pearson Prentice Hall, 2014.
MACHADO, Felipe N. Tecnologia e projeto de data warehouse. 6. ed. São Paulo: 
Erica, 2013.
RAINER, R. K.; CEGIELSKI, C. G. Introdução	a	sistemas	de	informação:	apoiando e 
transformando negócios na era da mobilidade. 3. ed. Rio de Janeiro: Elsevier, 2011.
ROB, P.; CORONEL, C. Sistemas de banco de dados: projeto, implementação e 
adminsitração. 8. ed. São Paulo: Cengage Learning, 2011.
Gabarito
Questão 1 - Resposta B.
Resolução: Na concepção de Rob e Coronel (2011), um Data Mart 
é um pequeno subconjunto de um DW, sobre um único assunto, 
que fornece suporte às decisões de um pequeno grupo de pessoas, 
podendo ser criado a partir de dados extraídos de um DW maior, 
80
com o objetivo específico de dar suporte a acessos mais rápido 
para determinado grupo ou função.
Questão 2 - Resposta D.
Resolução: Os itens I, II e III estão corretos. O item IV é uma 
característica do Data Warehouse, e não dos Data Marts, pois, 
segundo Inmon (1997), o Data Warehouse refere-se a um conjunto 
de dados baseado em assuntos, integrado, não-volátil e variável 
ao longo do tempo, de apoio às decisões gerenciais. Uma das 
principais características do Data Warehouse é a interação dos 
dados de diversas fontes distintas, proporcionando um ambiente 
estático, que não sofre modificações.
Questão 3 - Resposta E.
Resolução: A escolha da arquitetura é uma decisão que causa 
impactos quanto ao sucesso do projeto, podendo afetar o tempo de 
execução, o retorno do investimento, a velocidade dos benefícios 
da utilização das informações, a satisfação do usuário e os recursos 
necessários a sua implementação. A definição de uma arquitetura 
determina o local em que o DW ou os Data Marts estarão alocados 
fisicamente. Machado (2013) apresenta a seguinte classificação das 
arquiteturas: global, independente e a integrada, podendo o tipo de 
implementação ser top down, bottom up ou a combinada.
Modelagem de dados para um 
Data Warehouse
Autora: Marise Miranda
Objetivos
• Reconhecer os aspectos da granularidade e como 
eles afetam as análises dos negócios. 
• Aplicar as técnicas de modelagem de dados.
• Caracterizar a modelagem multidimensional para 
conceber as visualizações e medidas relacionadas 
sobre um conjunto de dados.
82
1. Aspectos sobre granularidade de dados
A compreensão sobre os dados e a granularidade assume uma etapa 
importante para modelar os dados em estruturas por níveis. Por 
exemplo, a venda de determinado produto se relaciona a seu preço, 
à baixa no estoque desse produto e ao cliente que o adquiriu, mas a 
quantidade de vendas dos produtos também são dados, no entanto, 
representa já um modelo em que vários produtos vendidos foram 
somados, não interessando nesse nível elevado de granularidade os 
nomes dos clientes para os quais o produto foi vendido. A granularidade 
tem a ver com o grau de sumarização, redução ou agregação dos dados. 
O produto em si é o grão, o nível mais baixo de granularidade, mas a 
quantidade desse mesmo produto vendido representa uma abstração, 
um nível e uma granularidade elevados. O dado, nesse caso, faz 
referência à soma desses produtos vendidos.
Kimball (2002) explica que especificar o grau de granularidade 
dos conjuntos de dados que serão analisados deve ser de comum 
entendimento entre os analistas que estão projetando o DW e os 
usuários que consumirão as análises. O grau de granularidade se 
apresenta em níveis: o baixo nível está relacionado com o dado 
bruto sem transformação, enquanto o alto nível está com os dados 
transformados, por exemplo, uma soma de quantidades vendidas de 
determinado produto.
As tabelas utilizadas no processo de análises devem ser construídas 
no nível mais baixo de granularidade possível, aumentando a 
flexibilidade e extensibilidade conforme o tipo de filtragem ou os 
agrupamentos exigidos nas consultas pelos usuários (KIMBALL, 2002). 
Para compreendermos as recomendações propostas pelo mesmo autor, 
83
vejamos a seguir um modelo que expressa as restrições relativas à 
granularidade (Figura 1).
Figura 1 – Níveis de granularidade dos dados
 
Fonte: adaptada de Kimball (2002, p. 133-134).
Machado (2011) destaca que a granularidade de dados faz referência 
ao nível de sumarização dos dados, considerando este como um 
aspecto importante em projetos de DW. Quanto mais detalhes 
dos dados, menor será a granularidade; já quanto menos detalhes 
houver, maior será a granularidade.
Em bancos transacionais, a granularidade é importante, porque 
o dado mais bruto está armazenado lá, diferentemente de 
banco de dados analítico, que opera os ambientes de DW, nos 
quais sumarizações e agregações afetam a granularidade. A 
granularidade afeta profundamente o volume de dados que estão 
armazenados em um DW.
A Figura 2 exemplifica a abordagem da granularidade em baixo 
e em alto níveis, considerando os detalhamentos pelos dados ou 
84
pelas sumarizações. O modelo mostra a diferença entre os dois 
níveis, um refere-se às vendas por vendedor, e o outro à soma das 
vendas no mês.
Figura 2 – Exemplo de granularidade e nível de detalhamento
Fonte: elaborada pela autora.
A entidade venda mostra os detalhes relacionados à venda de cada 
vendedor, a data, a hora, o vendedor associado e o valor da venda. É 
possível extrair um relatório das vendas por vendedor, ou seja, aqui há 
um nível baixo de granularidade e nível alto de detalhes. Já na entidade 
Soma_Vendas, a granularidade é alta e não expressa especificidade sobre 
os detalhes da venda, mas consolida o valor das vendas no mês. O primeiro 
modelo pode ser importante para a promoção de algum vendedor, 
já o segundo serve de apoio para a tomada de decisão da alta gestão 
da empresa.
Machado (2011) alerta que a granularidade de um DW auxilia no foco do 
projeto, e a modelagem fica mais fácil. Trazendo como exemplo, uma 
85
sumarização mensal é fácil e rápida,
mas se a sumarização requer saber as 
vendas relativas à semana da Páscoa, com promoções que iniciam 45 dias 
antes, há a necessidade da elaboração da sumarização mais detalhada, a 
cada 15 dias, obtendo três conjuntos quinzenais de dados sumarizados.
O Quadro 1 contempla o exemplo de forma detalhada, a nível de dado, 
baixa granularidade. O quadro consiste no detalhamento de dez vendas, 
sendo registrados as vendas por vendedor, o valor, a data e a hora. 
Todos os registros são lançados em uma base de dados transacional. 
O ID (identificação) de cada venda está associado a um número, que 
relaciona um dos três vendedores, o valor de cada venda por vendedor, 
a data e a hora, respectivamente.
Quadro 1 – Dados armazenados no banco transacional
Id_Vendas Data Hora Vendedor Valor
1 14/06/2012 16:03:12 Paulo M. R$ 2.500,00
2 15/06/2012 16:33:01 Julio W. R$ 1.850,00
3 16/06/2012 18:50:10 Paulo M. R$ 3.300,00
4 17/06/2012 16:33:01 Paulo M. R$ 4.500,00
5 18/06/2012 17:25:06 Maria T. R$ 200,00
6 13/07/2012 12:03:12 Julio W. R$ 2.135,00
7 14/07/2012 14:40:59 Paulo M. R$ 100,00
8 15/07/2012 13:22:08 Paulo M. R$ 130,00
9 16/07/2012 14:15:16 Maria T. R$ 4.750,00
10 17/07/2012 15:17:30 Maria T. R$ 1.889,00
Fonte: elaborado pela autora.
Caso um relatório de vendas seja emitido a partir dos dados do Quadro 
1, ele poderia ser executado como na Figura 3.
86
Figura 3 – Relatório de valor de vendas versus vendedor
Relatório Vendedor versus Valor 
Fonte: elaborada pela autora.
O relatório de vendedor versus valor das vendas realizadas representa 
a totalidade dos dados registrados na base. No entanto, esse exemplo 
é meramente ilustrativo. Em um banco de dados real, os registros de 
vendas de grandes lojas têm um volume que impossibilitaria a sua 
representação. Por esse motivo, são necessárias a seleção de conjuntos 
e realização das sumarizações. 
O Quadro 2 representa a sumarização realizada mensalmente; nela, 
a granularidade aumenta e o nível de detalhamento diminui, pois 
não é possível saber quais dias tiveram a melhor venda, não se tem o 
detalhe de qual vendedor vendeu mais, ou, ainda, em qual horário está 
ocorrendo a venda. Porém, para a tomada de decisão, o mês de junho 
teve desempenho de 57% aproximadamente sobre o total das vendas 
dos dois meses somados.
87
Quadro 2 – Dados sumarizados para análises
Mês Soma_Valor
Jun/12 R$ 12.350,00
Jul/12 R$ 9.004,00
Fonte: elaborado pela autora.
As vendas somadas nos meses de junho e julho do ano de 2012 foram 
de R$ 21.354,00. O exemplo é bastante reduzido, e, por esse motivo, a 
elaboração de sumarizações é didática e bastante simples. No entanto, 
em um DW em que os dados de diversas lojas são carregados para 
analisar o desempenho do ano de 2012, por exemplo, com 50 lojas 
de uma rede, com vendas diárias acima de R$ 20.000,00, as consultas 
deverão ser elaboradas de maneira a responder à pergunta a seguir 
(Figura 4).
Figura 4 – Pergunta analítica
Fonte: adaptado de Deagreez/ iStock.com. 
https://www.istockphoto.com/br/portfolio/Deagreez?mediatype=photography
88
Para responder a esse alto nível de granularidade, foi necessário criar 
sumarizações mensais que não estavam armazenadas, mas calculadas 
por meio de consultas no banco de dados analítico. Vamos supor que, 
na coleta de dados das 50 lojas, apenas quatro diferentes lojas tenham 
os dados registrados no banco; ao analisar as tabelas fornecidas 
apenas por essas quatro lojas, fica difícil concluir qual mês teve melhor 
desempenho. O nível de granularidade é muito baixo em função do 
detalhamento na Figura 5.
Figura 5 – Dados coletados das vendas mensais de quatro lojas
Loja 1 Loja 2
Loja 3 Loja 4
Fonte: elaborada pela autora.
89
Com base nos resultados coletados, estratificados na Figura 5, é possível 
responder à pergunta com apenas quatro lojas? Se fôssemos aguardar 
a obtenção dos dados de 50 lojas, poderíamos incorrer em demora 
ou muitas vezes os dados nem serem disponibilizados a tempo para 
a análise de tomada de decisão, cujo principal objetivo é responder o 
mais rápido possível à pergunta realizada. Sendo assim, o modelo de 
sumarização deve estar preparado para receber os dados das outras 
46 lojas, mas não pode ser impeditivo para a realização das consultas 
analíticas, o que deve estar claro também para a alta gestão, que terá 
uma visão parcial.
A granularidade precisa estar explícita, o que quer dizer que a 
sumarização será realizada para apenas quatro lojas com a expectativa 
para mais 46 lojas. Uma estratégia de granularidade deve ser executada 
em acordo com os projetistas e usuários que irão analisar os dados. 
Dessa maneira, a sumarização terá como base inicial as quatro lojas 
com os respectivos faturamentos mensais, conforme apresentado no 
Quadro 3. 
No quadro a seguir, as tabelas periféricas servem de insumo para as 
sumarizações na tabela central, cuja granularidade é maior, sem o nível 
de detalhamento das tabelas adjacentes.
90
Quadro 3 – Tabela sumarizada a partir das tabelas adjacentes
Filial 1 Filial 2
Id_
Vendas
Data Hora Vendedor Valor
Id_
Vendas
Data Hora Vendedor Valor
1 14/01/2012 16:03:12 Paulo M. R$ 2.200,00 BG 1 14/06/2012 16:03:12 Paulo M. R $2.500,00
2 15/01/2012 16:33:01 Julio W. R$ 1.550,00 2 15/06/2012 16:33:01 Julio W. R$ 1.850,00
3 16/01/2012 18:50:10 Paulo M. R$ 2.500,00 Fato 3 16/06/2012 18:50:10 Paulo M. R$ 3.300,00
4 17/02/2012 16:33:01 Paulo M. R$ 1.850,00 4 17/06/2012 16:33:01 Paulo M. R$ 4.500,00
5 18/02/2012 17:25:06 Maria T. R$ 3.300,00 Mês Soma_Valor 5 18/06/2012 17:25:06 Maria T. R$ 200,00
6 13/02/2012 12:03:12 Julio W. R$ 4.500,00 jan/12 R$6.250,00 6 13/07/2012 12:03:12 Julio W. R$ 2.135,00
7 14/03/2012 14:40:59 Paulo M. R$ 200,00 fev/12 R$9.650,00 7 14/07/2012 14:40:59 Paulo M. R$ 100,00
8 15/03/2012 13:22:08 Paulo M. R$ 430,00 mar/12 R$ 3.863,00 8 15/07/2012 13:22:08 Paulo M. R$ 130,00
9 16/03/2012 14:15:16 Maria T. R$ 2.110,00 abr/12 R$ 6.400,00 9 16/07/2012 14:15:16 Maria T. R$ 4.750,00
10 17/03/2012 15:17:30 Maria T. R$ 1.123,00 mai/12 R$13.763,00 10 17/07/2012 15:17:30 Maria T. R$ 1.889,00
jun/12 R$12.350,00
Filial 3 jul/12 R$ 9.004,00 Filial 4
Id_
Vendas
Data Hora Vendedor Valor ago/12 R$ 5.450,00
Id_
Vendas
Data Hora Vendedor Valor
1 14/08/2012 16:03:12 Paulo M. R$ 2.600,00 set/12 R$ 6.136,00 1 14/04/2012 16:03:12 Paulo M. R$ 1.200,00
2 15/08/2012 16:33:01 Julio W. R$ 1.550,00 out/12 R$ 4.863,00 2 15/04/2012 16:33:01 Julio W. R$ 150,00
3 16/08/2012 18:50:10 Paulo M. R$ 1.300,00 3 16/04/2012 18:50:10 Paulo M. R$ 200,00
4 17/09/2012 16:33:01 Paulo M. R $4.200,00 4 17/04/2012 16:33:01 Paulo M. R$ 150,00
5 18/09/2012 17:25:06 Maria T. R $800,00 5 18/04/2012 17:25:06 Maria T. R$ 3.200,00
6 13/09/2012 12:03:12 Julio W. R$ 1.136,00 6 13/04/2012 12:03:12 Julio W. R$ 1.500,00
7 14/10/2012 14:40:59 Paulo M. R$ 200,00 7 14/05/2012 14:40:59 Paulo M. R$ 700,00
8 15/10/2012 13:22:08 Paulo M. R$ 430,00 AG 8 15/05/2012 13:22:08 Paulo M. R$ 830,00
9 16/10/2012 14:15:16 Maria T. R$ 4.110,00 9 16/05/2012 14:15:16 Maria T. R$ 5.110,00
10 17/10/2012 15:17:30 Maria T. R$ 123,00 10 17/05/2012 15:17:30 Maria T. R$ 7.123,00
Legenda: AG – Alta granularidade; BG – Baixa granularidade. 
Fonte: elaborado pela autora.
A tabela sumarizada contém os valores das somas de cada mês, sendo 
alimentada a partir dos dados provenientes das tabelas das lojas. Esse 
conjunto forma o DW do exemplo.
Se esses dois níveis de granularidade fossem usados para uma 
representação gráfica, como mostra o Gráfico 1, pode-se verificar que o 
gráfico com a nível de granularidade baixo fica impossível de analisar, no 
91
entanto, quando a tabela sumarizada e explicitada em modo gráfico é 
possível realizar as leituras de forma eficiente.
Gráfico	1	–	Representação	dos	dados	versus granularidade
 
Fonte: elaborado pela autora.
A representação gráfica Valores vendas/dia remete a uma relação de 
alta densidade dos dados para uma baixa granularidade, portanto, 
sua interpretação fica prejudicada. No entanto,
a alta granularidade 
propicia melhor representação da sumarização, tornando mais 
eficientes as comparações e a análise do comportamento dos dados 
em uma visão de conjunto. Nesse caso, o mês de maio de 2012 teve o 
melhor desempenho.
PARA SABER MAIS
Dados históricos: são os dados provenientes do ambiente 
operacional levemente resumidos (MACHADO, 2011). Há, 
assim, dois níveis de granularidade: os dados históricos 
nos quais possam ser alcançados níveis de detalhes; 
e os dados resumidos, compactos e de fácil acesso, 
disponíveis para análises.
92
À medida que a granularidade se eleva, esta corresponde à diminuição 
da utilização de consultas às bases dos dados operacionais. Nesse 
sentido, a modelagem dos dados para um projeto DW é diferente da de 
um ambiente operacional.
Esse é também o motivo de não ser possível mover um banco 
transacional para um banco analítico, pois acarretaria alta complexidade 
para realizar consultas ad hoc, que exigem cálculos acessórios. Os 
modelos de dados transacionais são construídos de acordo com a 3ª 
Forma Normal (3FN) e não respondem com rapidez às consultas, que 
necessitam de mais de cinco joins de tabelas.
PARA SABER MAIS
3FN: é uma forma de normalização; nesse caso, cálculos 
são excluídos da tabela, pois eles dependem de colunas 
dessa tabela. 
Consultas ad hoc: são consultas especializadas ou específicas, 
como um cálculo, uma sumarização ou uma junção de duas 
tabelas, para estabelecer uma correspondência.
Join: são métodos de junção de dados de tabelas diferentes, 
respeitando-se os modelos de conjuntos. Por exemplo, o 
inner join da tabela A com a tabela B retorna os dados que são 
comuns nas duas tabelas; o left join entre a tabela A e a tabela 
B retorna todos os dados da tabela A mais os dados comuns 
entre A e B.
A modelagem de dados é um requisito fundamental para o DW e não 
pode utilizar as mesmas técnicas que são aplicadas para modelar os 
bancos transacionais. Existem duas técnicas distintas, a modelagem 
93
ER (Entidade Relacionamento) e a multidimensional, ambas com 
abordagem específica para modelos DW.
2. Modelagem de dados para DW
Um modelo é uma abstração e tenta refletir o mundo real. Modelar 
é uma abordagem que vislumbra o que ser quer realizar ou fazer. 
Como exemplo, um esquema ou um desenho que tenta refletir um 
pensamento ou uma ideia. A equação de uma reta que liga dois pontos 
do espaço é um modelo que tenta refletir ou explicar uma linha feita por 
um conjunto de pontos alinhados. Funciona da mesma maneira quando 
se trata de dados (MACHADO, 2011). O dado sozinho é um número ou 
uma variável e pouco representa algo, mas, quando associado a outros 
dados e transformado, revela contextos e associa ideias.
O diagrama ER é uma ferramenta que ajuda na análise de requisitos de 
negócio e no desenho da estrutura de dados relacionada a esse negócio 
(MACHADO, 2011). Inmon (2005) afirma que há três tipos de modelagem 
de dados, mas destaca o ERD (Entity Relationship Diagram – Diagrama 
Entidade Relacionamento), que representa um alto nível de abstração, 
cuja integração define os limites do modelo de dados, sendo necessária 
sua definição antes que a modelagem ERD comece.
Como exemplo, uma casa tem orçamento mensal para que as despesas 
sejam realizadas. Sendo assim, deve haver um controle de despesas em 
relação ao orçamento, ou seja, elas não podem ultrapassar o orçamento 
mensal disponível. Exemplos de despesas podem ser produtos ou serviços 
que serão consumidos ou usados com um valor monetário associado. Com 
base nesses requisitos mínimos, é possível fazer a modelagem elaborando 
uma tabela “Controle de despesas”, com colunas para o tipo e o valor das 
despesas e com o orçamento disponível, a ser decrementado do valor total 
como uma forma de controle.
94
As características da modelagem requerem a análise prévia em relação 
aos dados. O orçamento disponível deve ter um valor previsto e uma data 
de previsão. Despesas é uma entidade que tem como atributos a data 
em que ocorreu a despesa, a sequência da despesa (número de vezes), 
o nome da pessoa que realizou a despesa, a sua identificação com a 
tabela de classificação do orçamento, o mês em que a despesa ocorreu, 
o tipo de despesa e o valor da despesa. Outras entidades são incluídas na 
modelagem com o objetivo de associar o nome da pessoa que realizou a 
despesa, o tipo de despesa, como é a sua classificação no orçamento, se o 
valor da despesa foi incluído e se ela cabe no orçamento mensal.
Para ilustrar as duas abordagens sobre modelagem do exemplo 
anterior, sob o ponto de vista de negócio, o diagrama da Figura 6 
representa um modelo para operacionalizar esse negócio.
Figura 6 – MER da operacionalização do negócio despesa 
versus orçamento
Fonte: adaptado de Machado (2011, p. 67).
95
O modelo ER descreve as operações relacionadas ao negócio e às 
ligações entre as entidades do modelo. A abordagem dessa modelagem 
é operacional. Outra abordagem para esse contexto do exemplo das 
despesas versus orçamento é a da gestão do negócio. Nessa perspectiva, 
pode-se analisar como ocorre a necessidade de encontrar respostas 
com respeito à evolução orçamentária anual. 
Ainda como ponto de reflexão, qual a taxa da relação entre despesa e 
orçamento? Pensando um pouco mais além, quais produtos ou serviços 
apresentam evolução histórica de aumento?
As respostas a essas perguntas permitem encontrar o comportamento 
do desempenho do negócio, buscar simulações de cenários para 
embasar as análises estratégicas e alocar decisões. Essa abordagem 
remete à necessidade de construir um modelo dimensional. No 
exemplo, as perguntas feitas são abstrações de localidade (onde), 
temporalidade (quando), responsabilidade (quem) e classificação (o quê).
Essas abstrações podem ser exemplificadas da seguinte forma:
a. Localidade (Onde?): local, cidade, região, país, etc.
b. Temporalidade (Quando?): trimestral, mensal, anual, semanal, 
diário, etc.
c. Responsabilidade (Quem?): vendedor, promotor, pessoa, 
fornecedor, etc.
d. Classificação (O quê?): venda, promoção, despesa, gastos, etc.
Uma modelagem pode ser construída com base nas abstrações de 
localidade, tempo, responsáveis e classificação. Outras abstrações 
novas podem ser incluídas conforme o negócio da empresa. A Figura 
7 representa um diagrama, sobre o mesmo exemplo, mas em outra 
perspectiva, a multidimensional.
96
Figura 7 – Modelo multidimensional
Fonte: adaptada de Machado (2011, p. 68).
Os questionamentos apresentados não podem ser respondidos por 
meio de consultas às bases de dados operacionais, pois são necessários 
cálculos de percentuais destinados às despesas que afetaram o 
orçamento. Esses dados calculados são provenientes das operações de 
entrada dos dados e da relação entre despesa e orçamento calculada 
em tabelas acessórias.
Esse exemplo permite contextualizar dois modelos de dados: um seria o 
modelo ER e o outro o modelo multidimensional. Um depende do outro, 
em que o MER contém os elementos operacionais da empresa, e o 
modelo multidimensional reflete as métricas às dimensões relacionadas.
2.1 Modelagem ER
Um modelo ER utiliza três caracterizações para os dados: entidade, 
relacionamento e atributos. A entidade é o objeto do mundo real, identificado 
97
e com significado próprio, podendo ser um lugar, uma pessoa ou um evento. 
Ela representa classes de objetos e pode ser observada e classificada de 
acordo com suas caraterísticas e propriedades (MACHADO, 2011). Esses 
objetos do mundo remetem a um escopo de integração do mundo real, que 
determina qual parte poderá refletir um modelo (INMON, 2005). O modelo 
é descrito em suas partes e como elas se relacionam; no caso de dado, é o 
Modelo Entidade Relacionamento (MER).
Para elucidar esse contexto, a Figura 8 exemplifica um MER de vendas, em 
que o vendedor vende o produto. Vendedor e produto são as entidades 
e “vende” é o relacionamento entre as duas entidades. O Id_produto e Id_
vendedor são as chaves primárias de
cada entidade, Produto é valor_produto 
e Nome são os atributos relativos a cada entidade.
Figura 8 – Modelo ER Vendedor Produto 
– modelo conceitual
Fonte: elaborada pela autora.
O reconhecimento de uma entidade é orientado pelo mundo real, no 
ambiente em que ela existe, retratando a sua realidade por meio dos 
dados. Pelo exemplo, o vendedor tem um nome a ele associado e tem a 
ação de vender algo, que são produtos, os quais têm um tipo e um valor 
(MACHADO, 2011).
98
A nomeação da entidade deve ser clara e refletir uma comunicação 
acessível sobre ela, orientando-se por uma nomenclatura que 
represente suas características e seu escopo. Por exemplo, venda, 
pessoa, produto: venda é a ação em si, que relaciona a pessoa ao 
produto; pessoa é quem compra ou até quem vende; e produto é o 
objeto que foi vendido.
Cada entidade contém atributos, e um deles é o atributo chave, que 
se identifica exclusivamente ao registro ao qual a chave pertence. 
Na entidade Vendedor, a chave primária (PK) é o Id_Vendedor, é o 
identificador numérico de cada nome de vendedor. Em uma tabela do 
banco de dados, a chave primária é incluída em outra tabela e passa a 
ser uma chave estrangeira (FK), para que os relacionamentos funcionem. 
O mesmo acontece com produto, que tem um Id e um PK, conforme o 
modelo da Figura 9.
ASSIMILE
Chave estrangeira (FK – Foreign Key): é um atributo em um 
sistema relacional, cujos valores são os valores da chave 
primária de outra entidade relacionada. Não é uma chave 
primária (INMON, 2005, p. 497).
Chave primária (PK – Primary Key): é um atributo que 
contém valores que identificam exclusivamente o registro 
no qual a chave existe (INMON, 2005, p. 501).
Analisando sob o ponto de vista de tabelas no banco de dados, o modelo 
ER Vendas pode ter as tabelas criadas conforme a Figura 9.
99
Figura 9 – Modelo Lógico “Venda”
Fonte: elaborada pela autora.
O modelo lógico representa as entidades e seus relacionamentos, com 
as indicações da chave primária na tabela Vendedor (desenho da chave 
preta) e da chave estrangeira na tabela Produto Venda (desenho da 
chave verde). Ao construir as tabelas que serão inseridas no banco de 
dados, uma possível organização pode ser verificada no Quadro 4. A 
tabela Produto Venda contém o Id_vendedor como FK, para que a venda 
possa estar relacionada com a tabela de vendedor.
100
Quadro 4 – Tabelas dimensão do banco de dados
Vendedor
Id_vendedor Nome
1 Mario
2 Luis 
3 Sergio
4 Augusto
5 Juvenal
Produto Venda
Id_pro-
duto tipo_produto
valor_pro-
duto id_vendedor
1 Geladeira soft R$ 2.500,00 4
2 Fogão galaxi R$ 899,00 3
3 Geladeira alfa R$ 1.890,00 3
4
Microondas 
wave R$ 450,00 1
5 Ferro pass R$ 120,00 2
6
Aquecedor 
ice5 R$ 3.689,00 1
7
Microndas 
wavelet R$ 730,00 4
8 geladeira first R$ 1.320,00 2
Fonte: elaborado pela autora.
A partir das tabelas Vendedor e Produto Venda, é possível criar uma 
tabela sumarizada do total de vendas de cada vendedor. Essa nova 
tabela poderia ser criada a partir da tabela Vendedor e da Produto 
Venda (Quadro 5), com o objetivo de representar o resultado do 
desempenho de cada vendedor. São duas tabelas dimensões que 
participam da tabela Fato Desempenho Vendedor, uma dimensão 
Vendedor e outra Produto Venda.
Quadro 5 – Tabela Fato Desempenho Vendedor
Desempenho vendedor
Id_vendedor Nome total_vendedor
1 Mario R$ 4.139,00
2 Luis R$ 1.440,00
3 Sergio R$ 2.789,00
4 Augusto R$ 3.230,00
5 Juvenal R$ -
Fonte: elaborado pela autora.
101
O Quadro 5 representa a sumarização dos valores de cada produto 
vendido por vendedor. A tabela Fato é concebida para visualizar um 
conjunto de medidas que descrevem o desempenho característico 
dos vendedores relacionados com o tipo de negócio, com a venda de 
produtos na categoria eletrodomésticos. Ela é composta por partes da 
tabela Vendedor e partes da tabela Produto Venda, incluindo as somas 
das vendas por vendedor. Essa abordagem é denominada modelagem 
multidimensional e está representada pelo caso em estudo no Quadro 
6. A modelagem multidimensional será explorada posteriormente, 
detalhando a composição das tabelas Fato e das tabelas dimensões, 
formando um cubo de interações.
Quadro 6 – Modelo muldimensional vendas
Vendedor
Id_vendedor Nome
1 Mario
2 Luis 
3 Sergio
4 Augusto
5 Juvenal
Desempenho vendedor
Id_vendedor Nome total_vendedor
1 Mario R$ 4.139,00
2 Luis R$ 1.440,00
3 Sergio R$ 2.789,00
4 Augusto R$ 3.230,00
5 Juvenal R$–
Produto Venda
Id_produto tipo_produto valor_produto id_vendedor
1 Geladeira soft R$ 2.500,00 4
2 Fogão galaxi R$ 899,00 3
3 Geladeira alfa R$ 1.890,00 3
4 Microondas wave R$ 450,00 1
5 Ferro pass R$ 120,00 2
6 Aaquecedor ice5 R$ 3.689,00 1
7 Microndas wavelet R$ 730,00 4
8 Geladeira first R$ 1.320,00 2
Fonte: elaborado pela autora.
=
m
ed
id
as
=
102
Machado (2011) observa que a modelagem multidimensional é mais 
simples e inteligível do que a modelagem ER. Embora o nível de 
abstração seja elevado, o modelo multidimensional está mais acessível 
em termos de oferta de informação e é usado em projetos de DW, 
justamente por ser objetivo e compor conjuntos de dados que possam 
representar alguma resposta às perguntas.
2.2 Modelagem muldimensional
Uma questão emblemática no projeto de DW é a utilização do modelo 
relacional (MER) e do modelo muldimensional para o design do banco 
de dados de DW. Inmon (2005) orienta o uso do modelo relacional 
para projetos DW, no entanto, Kimball (2002) orienta que o modelo 
multidimensional deve ser levado em consideração em projetos de DW. 
Fazendo uma análise das duas orientações, conclui-se que a modelagem 
relacional é a abordagem de longo prazo no desenho de projetos DW, 
enquanto a modelagem multidimensional permite implementações a 
curto prazo, quando o escopo é reduzido.
A modelagem multidimensional, segundo Machado (2011, p. 79), é 
uma técnica para concepção e visão de dados a partir de um conjunto, 
que pode formular respostas às perguntas de negócios. Essa técnica é 
utilizada para sumarizar e restruturar dados, de modo a representá-los 
em visões que tragam suporte às análises necessárias. Como exemplo, 
as companhias aéreas utilizam essa técnica para representar seus DW 
por causa do tipo de negócio, agência reguladora do governo, agências 
de viagens e aeroportos.
Machado (2011) esclarece que o modelo multidimensional é composto 
por três elementos básicos:
103
a. Fatos.
b. Dimensões.
c. Métricas.
Uma tabela Fato é composta por dados, medidas e contexto 
provenientes de dimensões. Uma Fato representa um item, uma 
transação ou um evento relacionado ao negócio e possui valores 
numéricos, sendo sua implementação feita em tabelas denominadas 
tabela Fato (fact tables).
As dimensões, para Machado (2011), são os elementos, os dados, as 
fórmulas e os cálculos processados que participam ou são chamados 
por meio de chaves estrangeiras (FK) dentro de uma Fato. As dimensões 
são os assuntos do negócio, por exemplo, faturamento por mês, gastos 
por semana, vendas por região etc. As dimensões apresentam um 
contexto do negócio, supondo uma análise de vendas; ou melhor, em 
uma tabela Fato de vendas, as dimensões que participam dessa Fato 
podem ser vendas dos produtos em relação ao tempo, à localização, aos 
clientes, aos vendedores, às sazonalidades, entre outros cenários que 
influenciam no negócio.
Já as medidas são os atributos valorados numericamente que 
representam uma tabela Fato. Como exemplo de medida, a quantidade 
de unidades de um produto vendidas, a quantidade de produtos em 
estoque, o percentual de lucro, entre outras medições.
Portanto, ao casar as três técnicas, as dimensões, a Fato e as medidas, 
a melhor maneira de visualizar é por intermédio de um cubo. A forma 
facilitadora de representar o modelo multimensional é pelo desenho 
de um cubo tridimensional, colocando as características técnicas 
nele. A Figura 10 mostra uma representação cúbica multidimensional, 
considerando um negócio genérico
de venda de produtos por cidade.
104
Figura 10 – Modelagem muldimensional vendas
 
DIMENSÕES: PRODUTO, CIDADE, TRIMESTRE.
Fato: produtos por cidade no trimestre.
Medidas: soma das vendas trimestrais por produto.
Fonte: hh5800/ iStock.com.
O exemplo demostra claramente como a modelagem multidimensional 
pode ser representada por meio de um cubo, formado por tabelas 
que se associam, sumarizam ou se agregam e que compõem alguma 
métrica. Cada tabela pode ser interpretada como uma dimensão, todas 
as tabelas juntas formam o cubo e, hieraquicamente, a granularidade 
em nível alto ou baixo. Disso são extraidas as tabelas Fato e destas 
as medidas. Há casos em que medidas e cálculos são realizados nas 
Vendedores
Pr
od
ut
os
Loj
as
Temporalidade
https://www.istockphoto.com/br/portfolio/hh5800?mediatype=photography
105
dimensões para depois serem indexados nas tabelas Fato. A partir das 
Fatos, medidas, sumarizações e agregações podem ser representadas 
por meio de visualizações a serem consumidas pelos usuários.
3. Considerações Finais
A modelagem de dados é uma das etapas importantes em um projeto 
de DW, levando em consideração os níveis de granularidade do dado e/
ou do conjunto de dados a partir dos quais se quer obter resultados ou 
respostas. Além disso, a modelagem entidade relacionamento propõe 
um caminho inicial para sistematizar conceitos mais complexos, como 
a granularidade, e a abordagem sobre como construir tabelas Fato a 
partir de tabelas dimensões. A maturidade necessária empregada à 
modelagem multidimensional se tornará mais eficiente à medida que 
a base do modelo ER estiver compreendida. Projetos de DW requerem 
um acúmulo de experiências dos profissionais, principalmente na fase 
inicial, na modelagem. Na prática, cubos, dimensões, Fatos e medidas 
devem ser modelados multidimensionalmente em um projeto de DW 
por serem mais fáceis de implementar.
TEORIA EM PRÁTICA
Uma empresa produtora de grãos para exportação e 
abastecimento no mercado brasileiro deseja iniciar um 
projeto de Data Warehouse. A empresa compra os grãos 
in natura de três fazendas, faz a coleta nos silos e leva 
para a produção de lotes para a comercialização interna 
e internacional. Faça uma simulação de uma modelagem 
muldimensional, considerando cinco tipos de grãos: feijão 
fradinho, feijão carioca, feijão preto, feijão branco e feijão 
fava. A produção é trimestral, com variações de 10% em 
106
cada trimestre, sendo a melhor safra nos três ultimos 
meses do ano, quando não esta é afetada pelas variações 
climáticas e pelas chuvas. As fazendas estão localizadas 
nas regiões Norte, Nordeste e Centro-Oeste, e a fábrica de 
separação e ensacamento fica no sul do país. A logística 
para transporte dos silos das fazendas é quinzenal. A 
produção dos feijões é afetada pela variação climática 
nos seis primeiros meses do ano – clima muito quente e 
chuvas. Com base nesse cenário, projete um banco de DW 
por meio das técnicas de modelagem multidimensional. 
Simule o ambiente populando as tabelas dimensões com 
dados fictícios de produção agrícula, temperatura, tempo e 
localidade.
VERIFICAÇÃO DE LEITURA
1. Quais os elementos básicos que compõem um 
modelo multidimensional e um modelo relacional, 
respectivamente?
a. Modelo multidimensional: Fatos, dimensões 
e métricas; modelo relacional: entidade, 
relacionamento, atributos.
b. Modelo multidimensional: entidade, dimensões e 
métricas; modelo relacional: Fatos, relacionamento, 
atributos.
c. Modelo multidimensional: Fatos, entidades e métricas; 
modelo relacional: entidade, relacionamento, 
dimensões.
107
d. Modelo multidimensional: entidade, relacionamento, 
atributos; modelo relacional: fatos, dimensões 
e métricas.
e. Modelo multidimensional: entidade e dimensões; 
modelo relacional: fatos e relacionamento.
2. A sumarização e reestruturação dos dados permite 
representá-los em visões que suportem as análises. Para 
que isso ocorra, é necessária a utilização de técnica que 
auxilie na concepção e no desenho da visão dos dados 
em conjunto, indo do nível mais alto ao nível mais baixo 
de detalhamento desses dados. Aponte a alternativa 
correta que cite essa técnica.
a. Modelagem.
b. Granularidade.
c. Relacionamento.
d. Entidade.
e. Especialização.
3. O que representa atributos valorados numericamente e 
as tabelas Fato, associando, por exemplo, quantidades 
de vendas, quantidade em estoque, percentual de 
lucro etc.
a. Relacionamento.
b. Chave estrangeira.
c. Medidas.
d. Modelos.
e. Chave primária.
108
Referências	Bibliográficas
INMON, W. H. Building the Data Warehouse. 4. ed. New York: Wiley Computer 
Publishing, 2005.
KIMBALL, R. The Data Warehouse Toolkit: guia completo para modelagem 
dimensional. Rio de Janeiro: Campus, 2002.
MACHADO, F. N. R. Tecnologia e Projeto de Data Warehouse. 5. ed. São Paulo, 
Editora Érica, 2011.
Gabarito
Questão 1 - Resposta A.
Resolução: De acordo com Machado (2011), o modelo 
multidimensional é composto por elementos básicos fatos, 
dimensões e métricas, enquanto uma tabela Fato é composta por 
dados, medidas e contexto, provenientes de dimensões. Essas 
dimensões são assuntos do negócio e têm três outros elementos 
básicos, dados, fórmulas e cálculos processados, que participam 
ou são chamados por meio de chaves estrangeiras dentro de uma 
Fato. Já o modelo relacional utiliza três caracterizações para os 
dados: entidade, relacionamento e atributos.
Questão 2 - Resposta B.
Resolução: A granularidade é uma técnica que visa auxiliar nas 
sumarizações, nas visões e na concepção de análises de conjuntos 
de dados. Essa técnica pode ser utilizada para representar níveis 
de detalhamento dos negócios, desde as operações até as análises 
específicas. Quanto maior o nível de detalhamento menor a 
granularidade e vice-versa.
109
Questão 3 - Resposta C.
Resolução: As medidas ou métricas são os atributos valorados 
numericamente que representam uma tabela Fato, que será usada 
para compor as representações da mensuração pretendida. São 
exemplos de medida: a quantidade de unidades de um produto 
vendidas, a quantidade de produtos em estoque, o percentual de 
lucro, entre outras medições.
Esquema Estrela e Esquema Floco 
de Neve
Autora: Iolanda Cláudia Sanches Catarino
Objetivos
• Conhecer e compreender a modelagem 
multidimensional e seus elementos.
• Conhecer e compreender o Esquema Estrela (Star 
Schema) da modelagem multidimensional.
• Conhecer e compreender o Esquema Floco 
de Neve (Snow Flake Schema) da modelagem 
multidimensional.
111
1. Fundamentos da modelagem multidimensional
Nos sistemas transacionais com o uso de bancos de dados 
relacionais, a performance em tempo de resposta, bem como a 
minimização da redundância e inconsistência dos dados, pode 
ser garantida com o processo formal de normalização de dados, 
tornando as consultas mais simples para atenderem às tarefas 
rotineiras dos usuários. Já nos Data Warehouses (DW), as consultas são 
mais complexas, envolvendo um grande volume de dados históricos 
com diferentes codificações e predominando-se a não-volatilidade. 
Para o projeto e as especificação dos DW, adota-se a modelagem 
multidimensional, a qual representa uma abstração dos dados 
armazenados, consistindo em um modelo composto por tabelas Fato 
e de Dimensões, que proporcionam uma visão multidimensional de 
grande quantidade de dados.
Segundo Kimball (1998), os Fatos representam uma coleção de itens 
de dados, composta de dados de medidas, representando uma 
transação ou um evento de negócio. Um fato é representado por 
valores numéricos em um esquema e implementado em tabelas 
denominadas de tabelas Fato. As dimensões são os elementos que 
participam de um fato, ou seja, são as possíveis formas de visualizar 
os dados de forma descritiva e classificatória, determinando o 
contexto de um assunto de negócio. Os elementos que representam 
uma dimensão são especificados em um esquema e implementados 
em tabelas denominadas de tabelas de Dimensões.
O modelo multidimensional contém as mesmas informações que 
um modelo normalizado, mas agrupa os dados com o objetivo 
de reestruturá-los para facilitar a compreensão dos usuários e 
melhorar o desempenho de consultas dinâmicas, a partir de uma 
112
representação conceitual dos dados em várias visões, que exibem 
as informações no formato de um cubo. Esse cubo pode ser fatiado 
e aprofundado em cada dimensão ou em seu eixo para permitir 
a extração dos detalhes e processos internos de uma empresa de 
forma simples de serem analisados.
Na visão de Barbieri (2001), a modelagem multidimensional é uma 
técnica de projeto que conduz os dados a uma fase (cubo) em que 
a informação reside na interseção de várias dimensões, permitindo 
que o usuário perceba os dados em uma forma próxima de seu 
entendimento, com várias perspectivas possíveis, entre elas o tempo 
e o espaço. Elmasri e Navathe (2011) explicam que: 
Modelos multidimensionais tiram proveito dos relacionamentos 
inerentes nos dados para preencherem os dados em matrizes 
multidimensionais, chamadas cubos de dados. Se tiverem mais de 
três dimensões, estes podem ser chamados de hipercubos. (ELMASRI; 
NAVATHE, 2011, p. 722)
Um processamento Online Analytical Processing (OLAP – 
Processamento Analítico On-line) estrutura logicamente dados 
multidimensionais no formato de um cubo, a partir do qual os 
usuários finais visualizam os dados armazenados como um cubo de 
dados. O cubo apresenta várias dimensões que são subconjuntos 
de atributos. A Figura 1 mostra um exemplo de cubo de dados com 
três dimensões: localização com hierarquia dos dados por estado 
e cidade; tempo com hierarquia dos dados por ano e trimestre; e 
produto, a partir do qual é possível mensurar o volume de vendas 
calculando o valor total/quantidade de vendas dos produtos por 
estado/cidade no ano/trimestre.
113
Figura 1 – Exemplo de cubo de dados
Fonte: elaborada pela autora.
PARA SABER MAIS
Online Analytical Processing (OLAP – Processamento 
Analítico On-line): o termo representa a característica 
de trabalhar os dados com operadores dimensionais, 
possibilitando uma forma múltipla e combinada de análise. O 
ambiente de processamento analítico OLAP é caracterizado 
por consultas complexas, estruturadas e frequentes, 
envolvendo agregação ou relacionamento de dados para 
gerar informações que apoiam processos decisórios.
Um modelo de dados multidimensional poder ser representado por 
um cubo tridimensional não implica que haja um limite para o número 
114
de dimensões que podem ser associadas a uma tabela Fato. Não 
há limite matemático para o número de dimensões utilizadas (ROB; 
CORONEL, 2011).
Existem algumas abordagens específicas para a modelagem 
multidimensional, derivadas da aparência do esquema traçado, a partir 
do Diagrama de Entidades e Relacionamentos (DER), relacionando as 
tabelas Fato com as tabelas de Dimensões. A mais utilizada é o Esquema 
Estrela (Star Schema) e uma variante deste esquema é denominada de 
Esquema Floco de Neve (Snow Flake Schema), as quais são apresentadas 
nos itens a seguir.
2. Esquema Estrela (Star Schema)
O Esquema Estrela (Star Schema) é a abordagem proposta por Ralph 
Kimball que visa criar esquemas físicos mais simples e incrementais. 
O nome estrela foi definido em função da disposição em que se 
encontram as tabelas, sendo a tabela Fato centralizada no esquema 
e as tabelas de Dimensões relacionadas nas pontas do esquema, de 
forma independente entre as dimensões. Segundo Kimball (1998), 
o esquema de dados mais utilizado na especificação de um DW é o 
Esquema Estrela.
Na concepção de Poe, Klauer e Brobst (1998), o Esquema Estrela 
possui uma estrutura simples com poucas tabelas e associações 
bem definidas, aproximando do contexto do modelo de negócio 
e facilitando a geração de consultas complexas de forma intuitiva 
e interativa, por meio dos vários parâmetros de consultas. 
Nesse esquema, o assunto principal fica ao centro do esquema, 
representado pela tabela Fato, enquanto suas características, 
as dimensões, representadas por tabelas de Dimensões, ficam 
115
posicionadas ao seu redor, permitindo a leitura e compreensão até 
mesmo de usuários finais que não estão adaptados às estruturas de 
banco de dados.
As tabelas de Dimensões contêm a descrição textual do negócio 
representada pelos atributos e com a indicação da chave primária, 
que serve como base para manter a integridade referencial quando 
relacionada com a tabela Fato. Ela é a tabela dominante do Esquema 
Estrela composta por dois tipos de atributos: as chaves estrangeiras, 
que caracterizam as métricas estabelecidas nas tabelas de 
Dimensões, e os atributos, que definem os fatos a serem medidos.
Na concepção de Colaço Jr. (2004), o nome Esquema Estrela foi 
adotado pela semelhança com uma estrela, sendo composto de 
uma tabela dominante no centro, chamada de Fatos, rodeada por 
tabelas auxiliares, chamadas de tabelas de Dimensões. A tabela 
Fato conecta-se às tabelas de Dimensões por várias junções e cada 
tabela de Dimensão se conecta com apenas uma junção à tabela 
Fato. O esquema tem como característica básica a presença de dados 
altamente redundantes, considerando a desnormalização das tabelas 
dimensionais dos dados, para se obter um melhor desempenho em 
tempo de execução.
De acordo com Machado (2013), o Esquema Estrela é a estrutura 
básica de um modelo de dados multidimensional composto por uma 
grande entidade central denominada Fato (Fact Table) e um conjunto 
de entidades menores denominadas Dimensões (Dimension Tables), 
organizadas ao redor da entidade central, formando uma estrela, como 
mostra a Figura 2. Os relacionamentos entre a tabela Fato e as tabelas 
de Dimensões são definidos por ligações simples em um relacionamento 
de um para muitos (1:N), no sentido das dimensões para o fato.
116
Figura 2 – Esquema Estrela (Star Schema)
Fonte: adaptada de Machado (2013).
Rob e Coronel (2011) descrevem que o Esquema Estrela é uma técnica 
de modelagem de dados utilizada para mapear dados multidimensionais 
de suporte às decisões em um banco de dados relacional, por meio de 
seus fatos e de suas dimensões, que são representados como tabelas 
físicas no banco de dados do DW, sendo a tabela Fato relacionada a 
cada tabela de Dimensão em um relacionamento “muitos para um”. Os 
seguintes componentes são relacionados nesse esquema:
a. Fatos: são medidas numéricas que representam um aspecto 
ou uma atividade específica do negócio e que podem ser 
calculados ou derivados em tempo de execução, sendo 
armazenados em uma tabela Fato que constitui o centro 
do Esquema Estrela. Os fatos normalmente utilizados em 
análise de dados comerciais referem-se aos indicadores de 
desempenho do negócio.
117
b. Dimensões: são as características descritivas que fornecem 
as perspectivas adicionais a um determinado fato por 
meio de seus atributos. As dimensões são armazenadas 
em tabelas de Dimensões vinculadas à tabela Fato. As 
dimensões normalmente utilizadas em uma análise de dados 
de vendas (Fatos Vendas) podem ser as de produto/serviço, 
localização e tempo.
c. Atributos: representam os valores das características descritivas 
sobre os fatos. Cada tabela de Dimensão contém atributos 
que costumam ser utilizados para buscarem, filtrarem e 
classificarem fatos.
d. d. Hierarquias: representam a ordenação em hierarquias 
de atributos no interior das dimensões, fornecendo uma 
organização vertical adotada com a finalidade de detalhamento 
e agregação de dados no DW por operações de drill down ou 
roll up (também chamado de drill up). As operações permitem 
o detalhamento dos atributos, definindo um caminho para 
identificar como os dados devem ser dissociados ou agregados. 
A Figura 3 mostra o exemplo de hierarquias dos atributos 
de localização detalhada por região, estado, cidade e loja; 
tempo detalhado por ano, trimestre, mês e semana; e produto 
detalhado por tipo, categoria, grupo e subgrupo.
ASSIMILE
A granularidade de dados
faz referência ao nível de 
detalhamento dos dados de uma tabela. Quanto maior o 
nível de detalhe, menor será a granularidade.
118
Figura 3 – Hierarquia de atributos
Fonte: adaptada de Rob e Coronel (2011).
Os DW geralmente são constituídos de muitas tabelas Fato que 
armazenam grande quantidade de dados históricos relacionados com as 
tabelas de Dimensões, cada uma projetada para responder a questões 
específicas de suporte a decisões. As tabelas Fato e de Dimensões são 
relacionadas por chaves estrangeiras, sendo a chave primária do lado 
“1” da tabela de Dimensão armazenada como parte da chave primária 
do lado “muitos” da tabela Fato. Como a tabela Fato está relacionada 
com várias tabelas de Dimensões, sua chave primária é sempre formada 
combinando-se as chaves estrangeiras que apontam para as tabelas de 
Dimensões, o que forma uma chave composta.
A Figura 4 ilustra um exemplo do Esquema Estrela com os 
relacionamentos entre as tabelas Fato de Vendas e as tabelas de 
Dimensões de localização, tempo, loja filial e produto. A chave primária 
da tabela Fato vendas é composta de loc_ID, tem_ID, loj_ID e pro_ID. 
Cada registro da tabela Fato vendas representa os produtos vendidos 
119
por uma loja, em uma localização específica e em uma data específica, 
identificado exclusivamente pela combinação dos valores de cada uma 
de suas chaves estrangeiras.
Figura 4 – Esquema Estrela para vendas
Fonte: elaborada pela autora.
Colaço Jr. (2004) descreve que o Esquema Estrela é assimétrico, uma vez 
que se percebe nitidamente a tabela Fato como dominante do esquema, 
e flexível, para suportar a inclusão de novos elementos de dados, bem 
como mudanças que ocorram no projeto.
A Figura 5 ilustra um esquema com duas tabelas Fato, também 
conhecido como uma constelação de fatos, ou seja, um conjunto 
de tabelas Fato que compartilham algumas tabelas de Dimensões 
do mesmo esquema. Na figura, as tabelas Fato vendas e compras 
compartilham as tabelas de Dimensões de produto e tempo.
120
Figura 5 – Esquema Estrela para vendas e compras
Fonte: elaborada pela autora.
Destacam-se como as principais vantagens do Esquema Estrela:
• A estrutura padronizada e regular do esquema é bastante simples, 
permitindo que a modelagem do esquema e as ferramentas de 
acesso aos dados disponibilizem funcionalidades intuitivas que 
facilitem a interação dos usuários com a manipulação dos dados, 
bem como acesso à apresentação e ao desempenho das consultas 
geradas para análise das informações (KIMBALL; ROSS, 2013).
• A facilidade e a flexibilidade da inclusão de novos elementos de 
dados, a partir do relacionamento da tabela Fato com uma nova 
tabela de Dimensão, bem como o acréscimo de novas colunas às 
mesmas tabelas de Dimensões (COLAÇO JR., 2004).
• As consultas ocorrem inicialmente nas tabelas de Dimensões e 
depois nas tabelas Fato, assegurando a consistência dos dados 
por meio de uma estrutura de chaves que garanta o acesso aos 
dados com melhor desempenho.
• O fornecimento de um mapeamento direto e intuitivo entre as 
entidades de negócios de um modelo de dados para as tabelas 
Fato e tabelas de Dimensões do esquema facilita o entendimento 
de usuários finais que não estejam adaptados às estruturas de 
bancos de dados.
121
Date (2004) aponta como uma desvantagem do Esquema Estrela o fato 
de nem sempre os esquemas resultarem em projetos físicos legítimos, 
ou seja, um projeto que preserve todas as informações e restrições em 
um projeto lógico correto, considerando os princípios da modelagem 
relacional. Assim, muitas vezes é necessário normalizar as tabelas de 
Dimensões. Já Barbieri (2001) destaca como uma desvantagem do 
Esquema Estrela a falta de estruturas previstas para armazenar dados já 
dissociados ou agregados.
3. Esquema Floco de Neve (Snow Flake Schema)
O Esquema Floco de Neve (Snow Flake Schema) pode ser considerado 
uma extensão do Esquema Estrela. Nesse esquema, as tabelas 
de Dimensões visam eliminar a redundância dos atributos 
descritivos, organizando-os em uma hierarquia de tabelas de 
Dimensões normalizadas. Contudo, isso aumenta o número de 
tabelas de Dimensões, resultando em consultas mais complexas e 
desempenho reduzido.
Machado (2013) descreve que o Esquema Floco de Neve é uma 
decomposição de uma ou mais dimensões que possuem hierarquias 
entre seus elementos. Dessa forma, cada uma das “pontas da estrela” 
passa a ser o centro de outras estrelas com suas tabelas de Dimensões 
normalizadas até a terceira forma normal, definindo relacionamentos 
muitos para um entre as tabelas de Dimensões decompostas e 
formando, assim, uma hierarquia por meio desses relacionamentos, 
como mostra a Figura 6, a dimensão localização decomposta em cidade, 
estado e região, e a dimensão produto decomposta em tipo de produto.
Elmasri e Navathe descrevem que o “esquema floco de neve é uma 
variação do esquema estrela em que as tabelas dimensões de um 
122
esquema estrela são organizadas em uma hierarquia ao normalizá-
las” (ELMASRI; NAVATHE, 2011, p. 725). A Figura 6 ilustra o Esquema 
Floco de Neve.
Figura 6 – Esquema Floco de Neve
Fonte: adaptada de Machado (2013).
O Esquema Floco de Neve separa as hierarquias das dimensões em 
tabelas diferentes, especificando variantes da dimensão principal. 
Considera-se que a aplicação da técnica de normalização nas tabelas 
de Dimensões aumenta consideravelmente o número de dimensões, 
diminuindo consequentemente a performance das consultas dinâmicas. 
A Figura 7 mostra uma representação do Esquema Floco de Neve e 
ilustra a dimensão de localização normalizada na terceira forma normal 
com as tabelas de dimensões cidade, estado, região e país, obtendo 
simplicidade semântica e facilitando a navegação do usuário final pelas 
dimensões.
123
Figura 6 – Esquema Floco de Neve para Vendas
Fonte: elaborada pela autora.
Kimball e Ross (2013) afirmam que os projetistas devem minimizar a 
transformação de um Esquema Estrela em Esquema Floco de Neve 
devido ao impacto da complexidade desse tipo de estrutura sobre 
o usuário final, considerando que o ganho em termos de espaço de 
armazenamento é pouco relevante.
A utilização do Esquema Estrela é extremamente recomendável pelos 
aspectos de ganhos de performance, quando comparado com o 
Esquema Floco de Neve, que resulta normalmente da normalização 
de tabelas de Dimensões. Considera-se que a redundância no caso da 
adoção do Esquema Estrela é amplamente compensada pelas reduções 
de operações de junção, que são necessárias para a recuperação de 
dados em tempo de execução.
124
4. Considerações Finais
Soluções eficientes e que envolvem questões de análises complexas 
dos processos de negócio de uma empresa requerem uma visão das 
informações de diferentes perspectivas para permitir a identificação de 
problemas, tendências e oportunidades de negócios.
Na modelagem multidimensional de um DW, o contexto das 
funcionalidades que determinam os processos de negócio de uma 
empresa é especificado em tabelas Fato. Ela é a principal tabela de um 
esquema dimensional, que contém vários fatos correspondentes a cada 
uma de suas linhas que armazenam uma ou mais medidas numéricas, 
constituindo valores para a análise dimensional. A tabela Fato relaciona-
se com as tabelas de Dimensões, que representam as entidades de 
negócio e constituem as estruturas de entrada, que realizam os filtros 
de valores aplicados na manipulação dos fatos. Kimball e Ross (2013) 
reforçam que, quanto maiores o tempo e a atenção nesse processo, 
melhor será a qualidade da base de dados de um DW.
A decisão de optar pelo Esquema Estrela ou pelo Esquema Floco de 
Neve deve ser tomada levando em consideração principalmente a 
complexidade da solução e o volume de dados a ser manipulado, 
ou seja, é uma decisão que compete às boas práticas de projetos. 
Os esquemas, por meio de seus fatos e de suas dimensões, podem 
fornecer informações em diferentes formatos e graus de detalhamento, 
auxiliando, assim, na transformação das
informações em conhecimento 
para o suporte às decisões.
TEORIA EM PRÁTICA
Considere que uma das maiores locadoras de veículos 
do país tem 143 filiais localizadas em vários estados 
brasileiros e 18 filiais em 4 países da América Latina. Cada 
125
filial disponibiliza o serviço de aluguel de seus veículos 
para clientes nacionais e estrangeiros. A locadora possui 
uma ampla frota com veículos de diferentes categorias 
(ônibus, carros de passeio, utilitários etc), variadas 
marcas e modelos. Os gestores da locadora pretendem 
analisar os custos, o faturamento e os lucros das filiais 
de diferentes períodos das locações, principalmente 
de datas festivas, para tomarem decisões estratégicas 
para a expansão de novas filiais. Para isso, represente a 
modelagem multidimensional, no formato do Esquema 
Estrela, contemplando as dimensões que participarão dos 
fatos mensuráveis para a geração de consultas dinâmicas, a 
partir de ferramentas OLAP, disponibilizadas no projeto de 
desenvolvimento do Data Warehouse da locadora.
VERIFICAÇÃO DE LEITURA
1. Os esquemas de dados utilizados na modelagem 
dos Data Warehouses (DW) compreendem a chamada 
modelagem multidimensional. Ela representa uma 
abstração dos dados armazenados, consistindo em um 
modelo composto por tabelas Fato e de Dimensões, 
que proporcionam uma visão multidimensional de 
grande quantidade de dados. A tabela Fato é a principal 
tabela de um esquema dimensional, que geralmente 
contém vários fatos que indicam valores para a análise 
dimensional, enquanto as tabelas de Dimensões 
representam as características descritivas que fornecem 
as perspectivas adicionais aos fatos.
 Assinale a alternativa correta que descreve as 
características das tabelas Fato e de Dimensões.
126
a. A tabela Fato representa entidades de negócio e 
constituem as estruturas de entrada que servem 
para armazenar informações como tempo, produto, 
cliente etc. Ela tem uma relação 1:N com as tabelas de 
Dimensões.
b. A tabela Fato deve ser entendida como a tabela que 
realiza os filtros de valores aplicados na manipulação 
dos dados, determinando o contexto de um assunto 
de negócio.
c. As tabelas de Dimensões servem para armazenar 
medidas numéricas associadas a eventos de negócio. 
Possuem como chave primária uma chave única.
d. As tabelas de Dimensões servem para armazenar 
uma ou mais medidas numéricas, que constituem 
os valores objetos da análise dimensional. 
Possuem normalmente como chave primária uma 
chave composta.
e. As tabelas de Dimensões representam as 
características descritivas, que fornecem as 
perspectivas adicionais a um determinado fato por 
meio de seus atributos. Elas têm uma relação 1:N com 
a tabela Fato.
2. Existem algumas abordagens específicas para a 
modelagem multidimensional, derivadas da aparência 
do esquema traçado, a partir do Diagrama de Entidades 
e Relacionamentos (DER), relacionando as tabelas Fato 
com as tabelas de Dimensões. O ___________________ 
é a abordagem que visa criar esquemas físicos mais 
simples e incrementais devido à disposição em que se 
127
encontram as tabelas, sendo a tabela Fato centralizada 
no esquema e as tabelas de Dimensões relacionandas 
nas pontas do esquema.
 Assinale a alternativa que preenche 
corretamente a lacuna:
a. Esquema Cubo.
b. Esquema Estrela.
c. Esquema Floco de Neve.
d. Esquema MER.
e. Esquema Multifocal.
3. O nome do Esquema Estrela foi definido em função da 
disposição em que se encontram as tabelas, sendo a 
tabela Fato centralizada no esquema e as tabelas de 
Dimensões relacionadas nas pontas do esquema, de 
forma independente entre as dimensões.
 Sobre as principais vantagens do Esquema Estrela, julgue 
os itens a seguir:
 I. A presença de dados altamente redundantes, 
considerando a desnormalização das tabelas 
dimensionais dos dados, para se obter um melhor 
desempenho em tempo de execução.
 II. As consultas ocorrem inicialmente na tabela Fato e 
depois nas tabelas de Dimensões, assegurando a 
precisão dos dados por meio de uma estrutura de 
chaves que garante o acesso aos dados com melhor 
desempenho.
128
 III. A estrutura padronizada e regular do esquema é 
bastante simples, faciliatando a apresentação, o 
desempenho das consultas geradas e a compreensão 
até mesmo de usuários finais que não estão adaptados 
às estruturas de banco de dados.
 IV. A flexibilidade da inclusão de novos elementos de dados, 
a partir do relacionamento da tabela Fato com uma nova 
tabela de Dimensão, e o acréscimo de novas colunas às 
mesmas tabelas de Dimensões.
 Estão corretos os itens:
a. I – II.
b. II – III.
c. III – IV.
d. I – III – IV.
e. I – II – III – IV.
Referências	Bibliográficas
BARBIERI, Carlos. BI – Business Intelligence: modelagem & tecnologia. Rio de 
Janeiro: Axcel Books, 2001.
COLAÇO, M. Jr. Projetando sistemas de apoio à decisão baseados em data 
warehouse. Rio de Janeiro: Axcel Books do Brasil, 2004.
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro: 
Campus, 2004.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São 
Paulo: Pearson Addison Wesley, 2005.
KIMBALL, R. et al. The data warehouse lifecycle toolkit. New York: John Wiley & 
Sons, 1998.
KIMBALL, R.; ROSS, M. The data warehouse toolkit: the complete guide to 
dimensional modeling. 3 ed. New York: John Wiley & Sons, 2013.
129
MACHADO, Felipe N. Tecnologia e projeto de data warehouse. 6. ed. São Paulo: 
Erica, 2013.
POE, V.; KLAUER, P.; BROBST S. Building a data warehouse for decision support. 
New Jersey: Prentice Hall PTR, 1998.
ROB, P.; CORONEL, C. Sistemas de banco de dados: projeto, implementação e 
administração. 8. ed. São Paulo: Cengage Learning, 2011.
Gabarito
Questão 1 - Resposta E.
Resolução: A modelagem multidimensional representa uma 
abstração dos dados armazenados, consistindo em um modelo 
composto por tabelas Fato e de Dimensões, que proporcionam 
uma visão multidimensional de grande quantidade de dados.
Fatos: é uma coleção de itens de dados composta de dados de 
medidas, representando uma transação ou um evento de negócio. 
Um fato é representado por valores numéricos em um esquema e 
implementado em tabelas denominadas tabelas Fato.
Dimensões: são os elementos que participam de um fato, ou seja, 
são as possíveis formas de visualizar os dados de forma descritiva e 
classificatória, determinando o contexto de um assunto de negócio. 
Os elementos que representam uma dimensão são especificados 
em um esquema e implementados em tabelas denominadas de 
tabelas de Dimensões.
Questão 2 - Resposta B.
Resolução: Segundo Kimball (1998), o Esquema Estrela (Star 
Schema) é a abordagem que visa criar esquemas físicos mais 
simples e incrementais. O nome estrela se dá devido à disposição 
em que se encontram as tabelas, sendo a tabela Fato centralizada 
130
no esquema e as tabelas de Dimensões relacionandas nas pontas 
do esquema.
Questão 3 - Resposta D.
Resolução: Considerando a abordagem do Esquema Estrela da 
modelagem multidimensional, o item II está errado, porque as 
consultas ocorrem inicialmente nas tabelas de Dimensões e depois 
nas tabelas Fato, para assegurar a consistência dos dados por meio 
de uma estrutura de chaves, que garante o acesso aos dados com 
melhor desempenho.
.
Ferramentas de Dados em um 
Data Warehouse
Autora: Iolanda Cláudia Sanches Catarino
Objetivos
• Conhecer e compreender os fundamentos do 
Processamento Analítico On-line (OLAP).
• Conhecer e compreender as operações OLAP.
• Conhecer e compreender a classificação das 
ferramentas OLAP.
132
1. Fundamentos sobre o Processamento Analítico 
On-line (OLAP)
O número de usuários que precisa de análises de dados mais 
sofisticadas vem crescendo nas organizações, indo além dos níveis 
gerenciais mais altos. A viabilização e a extração eficazes de informações 
de um ambiente de Data Warehouse (DW) para proporcionar essas 
análises são possíveis a partir de ferramentas que disponibilizam 
recursos avançados para suportar operações
sobre o conjunto de dados 
multidimensional, gerando consultas dinâmicas com interface intuitiva 
para os usuários.
As ferramentas de apoio à decisão estão relacionadas com o conceito de 
Business Intelligence (BI) – inteligência aplicada aos negócios –, que “refere-
se ao conjunto de tecnologias que permitem o cruzamento de informações 
e suportam a análise dos indicadores de desempenho de um negócio” 
(COLAÇO JR., 2004, p. 26). Pela maior popularidade do uso das ferramentas 
de acesso a um DW, destacam-se as ferramentas Online Analytical 
Processing (OLAP – Processamento Analítico On-line), termo criado como 
tecnologia OLAP em 1993 por Edgar Frank Codd, matemático britânico que 
desenvolveu o modelo de banco de dados relacional.
PARA SABER MAIS
Business Inteligence: de acordo com Barbieri (2001), esse 
termo é referente a um “guarda-chuva” conceitual, visto que 
se dedica à captura de dados, informações e conhecimentos 
que permitam as empresas competirem com maior 
eficiência em uma abordagem evolutiva de modelagem de 
dados, capaz de promover a estruturação de informações 
em depósitos retrospectivos e históricos, permitindo sua 
modelagem por ferramentas analíticas.
133
Barbieri (2001) enfatiza que o termo Processamento Analítico On-line 
representa a característica de se trabalhar os dados com operadores 
dimensionais, possibilitando uma forma múltipla e combinada 
de análise.
O OLAP desempenha análise multidimensional de dados empresariais 
e oferece capacidades para cálculos complexos, análises de 
tendências e modelagem de dados sofisticados. Ele habilita usuários 
finais a fazerem análises de dados em múltiplas dimensões com 
recursos diversos para visualização das informações, provendo o 
entendimento de que eles necessitam para a melhor tomada de 
decisão. Pode ser um processo simples, fácil, rápido, controlável e de 
acesso à inteligência implícita nos dados.
Um processamento OLAP estrutura logicamente dados 
multidimensionais na forma de um cubo, possibilitando que os 
usuários finais visualizem os dados armazenados como um cubo de 
dados, o qual apresenta várias dimensões, que são subconjuntos 
de atributos. É interessante destacar que os cubos são estáticos, ou 
seja, não estão sujeitos a alterações e devem ser criados antes de sua 
utilização. No entanto, eles não podem ser criados por consultas ad 
hoc. Em vez disso, a consulta é realizada em cubos pré-criados com 
eixos definidos.
Date (2004) explica que o termo OLAP pode ser definido como o 
processo interativo de criar, gerenciar, analisar e gerar relatórios 
sobre dados. Os dados, então, são percebidos e manipulados como 
se estivessem armazenados em um array multidimensional.
O OLAP proporciona acesso aos dados de um determinado negócio, 
podendo o usuário obter uma compreensão que lhe ofereça 
134
condições de melhor planejamento e gerenciamento. O arranjo em 
cubos do OLAP permite analisar as múltiplas dimensões dos dados 
utilizados pela empresa, em múltiplas combinações, sob ângulos 
variados, podendo o executivo identificar também tendências e 
descobrir o que está acontecendo nos negócios (BISPO, 1998).
As ferramentas que apresentam características OLAP passaram 
a ser referenciadas como ferramentas OLAP. A maioria delas é 
implementada para ambientes multiusuários em arquitetura Cliente-
Servidor, proporcionando resultados rápidos e consistentes às 
consultas interativas executadas pelos usuários. Em um projeto de 
implementação de uma ferramenta OLAP, pode haver a necessidade 
de integração de dados de diferentes plataformas de bases de dados, 
e, com isso, soluções de conectividade devem ser definidas. Consultas 
complexas podem demandar respostas que requeiram flexibilidade e 
performance, que se tornam possíveis pela modelagem dos dados.
Machado (2013) descreve que as ferramentas OLAP surgiram com 
os sistemas de apoio à decisão para fazerem a consulta e a análise 
dos dados dos DW, sendo as aplicações às quais os usuários têm 
acesso para extrair os dados de suas bases e construir os relatórios 
com recursos que atendam aos gestores. Por ser uma ferramenta 
de processamento analítico on-line de dados, uma aplicação OLAP 
soluciona vários problemas de análise e consolidação dos dados, com 
capacidade de visualização das informações a partir de diferentes 
perspectivas para os usuários estratégicos, utilizando-se de consultas 
dinâmicas em tempo de execução do sistema.
A característica mais marcante das modernas ferramentas OLAP é a 
capacidade de análise multidimensional. Os dados são processados 
e visualizados em uma estrutura multidimensional, sendo 
135
especialmente atrativos para os tomadores de decisões de negócios. 
Enquanto o DW mantém os dados de suporte a decisões integrados, 
orientados por assunto, variáveis no tempo e não voláteis, o sistema 
OLAP fornece o front end por meio do qual os usuários finais acessam 
e analisam esses dados (ROB; CORONEL, 2011).
Adicionalmente, é interessante observar que os sistemas OLAP são 
projetados para utilizar os dados operacionais de DW, ou seja, um 
sistema OLAP pode acessar os dados armazenados em um DW ou 
os dados armazenados em um banco de dados operacional ou até 
mesmo ambos, dependendo da implementação. Em qualquer caso, a 
análise multidimensional de dados exige algum tipo de representação 
de dados nessa mesma dimensão, o que normalmente é fornecido 
pelo mecanismo de OLAP (ROB; CORONEL, 2011). Em contraste com 
os sistemas Online Transaction Processing (OLTP – Processamento 
de Transações On-line), as ferramentas OLAP destacam-se pelo 
potencial de recuperação de grande volume de dados e pela análise 
de informações de forma rápida e com diferentes perspectivas.
ASSIMILE
Online Transaction Processing (OLTP - Processamento 
de Transações On-line): o termo refere-se aos sistemas 
transacionais, que são utilizados no processamento dos 
dados de rotina, gerados diariamente, a partir dos sistemas 
informacionais de uma organização.
O Quadro 1 apresenta as principais diferenças entre os processamentos 
OLAP e OLTP, segundo Barbieri (2001).
136
Quadro 1 – Diferenças entre OLAP e OLTP
OLAP OLTP
Baseado em dados 
históricos, consolidados e 
frequentemente totalizados.
Baseado em transações de dados 
atuais de funções repetitivas.
Operações de agregação 
e cruzamentos de dados 
sumarizados.
Operações de manipulação de 
dados individuais, por meio 
dos comandos de inserção, 
atualização e exclusão.
Atualizações quase inexistentes, 
apenas novas inserções.
Atualizações em grande 
número de registros.
Disponibiliza as informações sob 
diferentes perspectivas do negócio.
Organiza os dados orientados 
aos processos.
Fonte: elaborado pela autora.
Codd, Codd e Salley (1993) descrevem que uma ferramenta OLAP deve 
conter 12 critérios, relacionados a seguir:
1. Visão conceitual multidimensional: os dados são modelados em 
diversas dimensões, possibilitando a extração de dados mais 
intuitivos e o cruzamento de todos os tipos de dados para gerar 
informações de fácil leitura e análise.
2. Dimensionalidade genérica: a ferramenta deve proporcionar 
condições ao usuário para executar manipulações ou cálculos 
entre as dimensões. Dessa forma, a estrutura básica dos dados e o 
formato dos relatórios não devem ser influenciados por nenhuma 
dimensão de dados.
3. Dimensões e níveis de agregação ilimitados: um modelo analítico 
comum pode conter de 15 a 20 dimensões de dados. Paralelamente, 
137
os níveis de agregação devem ser ilimitados, desde a mínima até a 
máxima granularidade.
4. Operações dimensionais: considera-se um modelo analítico e 
tomam-se duas ou mais células pertencentes a diferentes dimensões 
dentro desse modelo para serem usadas na realização de cálculos.
5. Manipulação de matriz esparsa dinâmica: para qualquer matriz 
esparsa de dados, existe um e somente um esquema físico, o qual 
provê a máxima eficiência e operacionalidade, para maximizar o 
desempenho, baseada na densidade dos dados armazenados.
6. Arquitetura
cliente-servidor: a maioria dos dados é armazenada em 
um servidor de rede e acessada por meio de computadores pessoais. 
Portanto, é necessário que a ferramenta seja capaz de operar em um 
ambiente cliente-servidor para atender a multiusuários.
7. Acessibilidade: a ferramenta tem que traçar seu próprio esquema 
lógico para tratar os dados heterogêneos armazenados e, assim, 
executar qualquer conversão necessária para apresentar ao usuário 
uma única e consistente visão dos dados.
8. Transparência: a ferramenta deve atender a todas as solicitações 
dos usuários, a partir de planilhas eletrônicas, aplicativos de 
suporte à decisão ou outras interfaces. Se a ferramenta está em 
uma arquitetura cliente/servidor, então os acessos devem ser 
transparentes aos usuários.
9. Manipulação de dados intuitiva: todo o processo de criação de 
modelos, manipulação de dados e realização de cálculos deve 
acontecer da forma mais intuitiva para os usuários, sem necessitar de 
nenhum tipo de auxílio.
10. Desempenho consistente de relatório: mesmo com o aumento do 
número de dimensões ou do tamanho do banco de dados, o usuário 
não deve perceber uma degradação significativa no desempenho do 
fornecimento de informações.
138
11. Flexibilidade nas consultas: a análise e a apresentação dos dados 
tornam-se mais simples quando linhas, colunas e células que vão ser 
comparadas visualmente são organizadas por agrupamentos lógicos 
para efetuarem qualquer tipo de consulta.
12. Suporte multiusuário: muitas vezes, vários usuários necessitam 
trabalhar simultaneamente com o mesmo modelo analítico ou 
criar modelos diferentes a partir dos mesmos dados. Assim, a 
ferramenta tem que prover esses acessos simultâneos sem prejuízo 
à integridade e à segurança dos dados.
2. Operações OLAP
Uma característica importante que deve estar presente em ferramentas 
OLAP é a capacidade de efetuar algumas operações. Existem diversos 
operadores OLAP que permitem acessar os dados em esquemas 
multidimensionais. Cada operação sobre um conjunto de dados 
multidimensional retorna uma apresentação ou sumarização diferente 
de informações.
Em seguida, são apresentadas as principais operações realizadas 
com cubos de dados. As operações do tipo Drill (Drill Down, Drill 
Up, Drill Across e Drill Through) permitem a navegação ao longo dos 
níveis hierárquicos de uma dimensão. As operações do tipo Slice and 
Dice têm como objetivo realizar a navegação por meio dos dados na 
visualização do cubo.
2.1 Drill Down 
Essa operação ocorre quando o usuário aumenta o nível de detalhe da 
informação, diminuindo a granularidade, ou seja, navega verticalmente, 
descendo a hierarquia no sentido mais específico.
139
De acordo com Elmasri e Navathe (2011):
Uma exibição Drill-Down fornece uma visão mais detalhada”. Por exemplo, 
desagregar “as vendas do país por região e, depois, as vendas regionais 
por sub-região e também separando produtos por estilos. (ELMASRI; 
NAVATHE, 2011, p. 724)
A Figura 1 mostra um exemplo de Drill Down:
Figura 1 – Exemplo de Drill Down
Volume de produção 
(em milhar)
Telefone celular Tablet
2017 2018 2017 2018
Região Sul
RS 35 29 18 21
SC 47 38 20 23
Drill Down 
Dimensão localização geográfica 
Membro RS
Volume de produção 
(em milhar)
Telefone celular Tablet
2017 2018 2017 2018
RS
Canoas 9 7 5 6
Porto Alegre 12 11 6 8
Fonte: adaptada de Machado (2013).
No exemplo da Figura 1, uma operação de Drill Down acontece sobre 
a dimensão localização geográfica. O primeiro quadro, localizado no 
topo da figura, apresenta o volume de produção por região geográfica 
e pelos estados dessa região. Ao realizar um Drill Down, abre-se o nível 
140
de detalhe da dimensão localização geográfica, visualizando somente 
um estado da região anterior (no exemplo, o RS – Rio Grande do 
Sul), entretanto, abrindo os valores para as cidades desse estado (no 
exemplo, Canoas e Porto Alegre) (MACHADO, 2013).
2.2 Drill Up ou Roll Up
Essa operação é o oposto do Drill Down e ocorre quando o usuário 
aumenta o nível de granularidade, diminuindo o nível de detalhamento 
da informação, ou seja, permite ao usuário uma visão mais agregada das 
informações.
Elmasri e Navathe (2011) explicam que “uma exibição Roll-Up sobe 
na hierarquia, agrupando em unidades maiores ao longo de uma 
dimensão” (ELMASRI; NAVATHE, 2011, p. 723). Na concepção de Date, 
Drill Up “significa ir de um nível mais baixo de agregação até um nível 
mais alto” (DATE, 2004, p. 613). Por exemplo, mover de produtos 
individuais para uma categorização maior dos produtos.
A Figura 2 mostra um exemplo de Drill Up, cuja operação está sendo 
realizada sobre a dimensão tempo. O primeiro quadro, localizado no 
topo da figura, apresenta o volume de produção global independente 
de produtos na região Sul, nos estados do Rio Grande do Sul e de 
Santa Catarina, distribuídos por trimestre em 2018. O segundo 
quadro, localizado na parte inferior da figura, apresenta os mesmos 
dados, mas somente de um dos trimestres, o primeiro. A operação de 
sair do segundo quadro para o primeiro é uma Drill Up, pois o usuário 
sai de um nível mais baixo de detalhe (um trimestre específico de 
um ano) para um nível mais alto (todos os trimestres de um ano) 
(MACHADO, 2013).
141
Figura 2 – Exemplo de Drill Up
Volume de produção 
(em milhar)
2018
1ª Trimestre 2ª Trimestre 3ª Trimestre 4ª Trimestre
Região Sul
RS 12 12 11 15
SC 15 13 12 21
Drill Up 
Dimensão tempo
Volume de produção 
(em milhar)
1ª Trimestre
Janeiro Fevereiro Março
Região Sul
RS 5 3 4
SC 7 4 4
Fonte: adaptada de Machado (2013).
É importante destacar que, apesar de alguns autores tratarem Drill Up e 
Roll Up como sinônimos, Date (2004) argumenta que há uma diferença 
sutil entre elas: Roll Up é a operação de criar os agrupamentos e as 
agregações desejadas, enquanto Drill Up é a operação de acessar essas 
agregações.
2.3 Drill Across
Essa operação permite navegar transversalmente no eixo da dimensão, 
retirando ou inserindo posições da dimensão, ou seja, ocorre quando 
o usuário pula um nível intermediário dentro da mesma dimensão. Por 
exemplo, a dimensão tempo é composta por ano, semestre, trimestre, 
mês e dia (MACHADO, 2013). A operação Drill Across é executada quando 
142
o usuário passar de ano direto para trimestre ou mês. A Figura 3 
apresenta um exemplo de Drill Across:
Figura 3 – Exemplo de Drill Across
Volume de produção 
(em milhar)
Telefone celular Tablet
2017 2018 2017 2018
Região Sul
RS 35 29 18 21
SC 47 38 20 23
Drill Down 
Dimensão localização geográfica 
Membro RS
Volume de produção 
(em milhar)
Telefone celular Tablet
Janeiro 2017 Janeiro 2018 Janeiro 2017 Janeiro 2018
Região Sul
RS 5 3 2 2
SC 7 4 3 2
Fonte: adaptada de Machado (2013).
No exemplo da Figura 3, há dois quadros com o volume de produção. 
O primeiro, localizado no topo da figura, mostra os valores antes de 
executar um Drill Across. O segundo, localizado na parte inferior da 
figura, mostra os valores após a execução de um Drill Across. Nesse 
exemplo, foi executado um Drill Across de ano para mês (janeiro). 
Notemos que, no primeiro quadro, os valores correspondem ao volume 
de produção por ano (2017 e 2018). No segundo quadro, após executar 
um Drill Across, os valores correspondem apenas ao volume de produção 
do mês de janeiro de 2017 e 2018.
143
2.4 Drill Throught
Essa operação ocorre quando o usuário navega de uma informação 
contida em uma dimensão para uma outra dimensão. Por exemplo, 
quando o usuário está na dimensão de tempo e no próximo passo 
começa a analisar a informação por região (MACHADO, 2013).
A Figura 4 mostra um exemplo de Drill Throught. O primeiro quadro, 
localizado no topo da figura, apresenta a quantidade de produtos 
vendidos por região e cidades, distribuídos por ano. O segundo 
quadro, localizado na parte inferior da figura, apresenta a quantidade 
de produtos vendidos por ano, mas distribuídos por lojas da cidade 
de Porto Alegre, da região Sul. A operação de sair do primeiro para
o 
segundo é conhecida como Drill Throught, pois o usuário seleciona um 
membro (cidade Porto Alegre) dentro de uma dimensão (região) e passa 
a analisar uma outra dimensão (loja).
Figura 4 – Exemplo de Drill Throught
Volume de produção 
(em milhar)
Telefone celular Tablet
2017 2018 2017 2018
RS
Porto Alegre 12 11 6 8
Canoas 9 7 5 6
Caxias do Sul 11 11 5 6
Pelotas 8 7 5 5
Drill Throught 
Membro Porto Alegre
Volume de produção 
(em milhar)
Telefone celular Tablet
2017 2018 2017 2018
Loja 18 2 2 1 1
Loja 19 3 2 1 2
Loja 20 4 5 3 3
Loja 21 3 2 1 2
Fonte: elaborada pela autora.
144
2.5 Slice and Dice
Essas operações ocorrem para realizar a navegação por meio dos dados 
na visualização de um cubo. Slice and Dice significa a redução do escopo 
dos dados em análise, além da mudança da ordem das dimensões, 
mudando assim a orientação com que os dados são visualizados. 
Entretanto, Machado (2013) explica que Slice é:
A operação que corta o cubo, mas mantém a mesma perspectiva de 
visualização dos dados, [ou seja], fatiar ou realizar Slice é a operação de 
visualizar somente a produção de um tipo de produto, por exemplo, 
celulares. (MACHADO, 2013, p. 89)
 No exemplo da Figura 5, está sendo realizado um Slice sobre a 
dimensão produto. O primeiro quadro, localizado no topo da figura, 
apresenta o volume de produção de celulares e tablets na região Sul 
nos dois últimos anos. O segundo quadro, localizado na parte inferior 
da figura, apresenta os mesmos dados somente de celulares, ou seja, 
apenas uma fatia dos dados. A operação de visualizarmos somente a 
produção de um tipo de produto (celulares) é conhecida como Slice.
Figura 5 – Exemplo de Slice
Volume de produção 
(em milhar)
Celulares e tablets
Janeiro Fevereiro Março
Região Sul
RS 12 10 8
SC 16 15 10
Slice 
Dimensão produto 
Membro Celulares
Volume de Produção 
(em milhar)
Celulares
Janeiro Fevereiro Março
Região Sul
RS 8 5 5
SC 11 9 6
Fonte: elaborada pela autora.
145
A operação Dice é utilizada para limitar o conjunto de valores a ser 
mostrado, fixando-se algumas dimensões. Segundo Machado (2013), 
Dice é “a mudança de perspectiva da visão”, ou seja, “é a extração de um 
‘subcubo’ ou a interseção de vários Slices” (MACHADO, 2013, p. 90).
A Figura 6 mostra um exemplo da operação Dice. No primeiro quadro, 
localizado no topo da figura, é possível visualizar o volume de produção 
no sentido estado, cidade, ano, modelo de produto e produto, ou seja, 
cada valor apresentado significa o volume produzido em um estado, em 
uma cidade, em um ano, de um modelo de produto e de um produto. 
No segundo quadro, localizado na parte inferior da figura, foi alterada 
a perspectiva para modelo de produto, produto, ano, estado e cidade, 
ou seja, cada valor agora representa a produção de um modelo de 
produto e um produto, em um ano, em um estado e em uma cidade. O 
objetivo desse tipo de análise é descobrir comportamentos conforme a 
perspectiva de análise dos dados. (MACHADO, 2013).
Figura 6 – Exemplo de Dice
Volume de produção 
(em milhar)
Telefone celular Tablet
2017 2018 2017 2018
RS
Porto Alegre 12 11 6 8
Canoas 9 7 5 6
Dice 
Volume de produção 
(em milhar)
Modelo CT1
RS
Canoas Porto Alegre
Telefone celular
2017 9 12
2018 7 11
Tablet 2017 5 6
2018 6 8
Fonte: elaborada pela autora.
146
3.	Classificação	das	ferramentas	OLAP
As ferramentas OLAP podem ser classificadas de acordo com 
a estratégia de armazenamento, sendo chamadas de OLAP 
Multidimensional (MOLAP), OLAP Relacional (ROLAP), OLAP Híbrido 
e OLAP Web.
O MOLAP refere-se à utilização de banco de dados com características 
multidimensionais, permitindo a navegação com níveis de detalhamento 
em tempo real, a partir da combinação das dimensões do cubo, 
proporcionando análises sofisticadas com ótimo desempenho. 
Segundo Machado (2013), em um banco de dados multidimensional, os 
cruzamentos de valores são realizados automaticamente, agilizando a 
visualização multidimensional das informações sob o ponto de vista de 
todas as dimensões. A forma de acesso e de agregação dos dados faz 
com que essa ferramenta tenha um excelente desempenho.
O ROLAP refere-se à utilização do banco de dados relacional para 
implementar soluções OLAP. Segundo Colaço Jr. (2004): 
Os sistemas ROLAP permitem análise multidimensional dos dados que 
estão armazenados em uma base de dados relacional, podendo ser feito 
todo o processamento no servidor da base de dados e depois gerados 
os comandos SQL e as tabelas temporárias. De forma inversa podem ser 
executados os comandos SQL para recuperação dos dados e posterior 
processamento no servidor OLAP. (COLAÇO JR., 2004, p. 37)
A vantagem dessa ferramenta é a utilização de banco de dados 
relacional, de arquitetura aberta e padronizada.
O ROLAP representa uma abordagem de uso combinado das duas 
estratégias anteriores em que as estruturas relacionais são utilizadas 
para os dados com maior granularidade, enquanto as estruturas 
147
multidimensionais são utilizadas para dados com menor granularidade, 
ou seja, nos dados agregados.
O WOLAP refere-se à utilização da ferramenta OLAP em ambiente 
remoto, disparando consultas via um navegador web para o servidor, 
que, por sua vez retorna o cubo processado para a análise do usuário.
A escolha de uma ferramenta OLAP envolve a análise dos recursos e 
das funcionalidades que a ferramenta implementa, pois diferentes 
ferramentas OLAP integram um conjunto de módulos que abrange 
parcial ou totalmente as funcionalidades apresentadas no item anterior. 
A seguir, é apresentada uma introdução da ferramenta CASE Microsoft 
Analysis Services.
3.1 Microsoft Analysis Services
O Analysis Services é um gerenciador de informações que oferece ao 
desenvolvedor e aos usuários estratégicos uma série de recursos 
para auxiliarem o processo de análise de dados com uma visão 
multidimensional com fácil interação e usabilidade. Ele disponibiliza 
modelos de dados semânticos para relatórios de negócios compatíveis 
com diferentes plataformas, como relatórios do Power BI, Excel, 
relatórios de serviços e outras ferramentas de visualização de dados. 
Ele está disponível nas plataformas Azure Analysis Services e SQL Server 
Analysis Services (MICROSOFT, 2017).
O Analysis Services não precisa ser utilizado apenas com o SQL Server, é 
possível utilizá-lo com qualquer banco de dados que possua um driver 
Open Database Connectivity (ODBC) ou um Provider Object Linking and 
Embedding for Databases (OLE DB). Assim, ele destaca-se com a vantagem 
competitiva de custo zero.
Outro ponto importante a ser observado é a forma de armazenamento 
dos dados. O Analysis Services permite que os dados sejam 
148
armazenados em tabelas relacionais (ROLAP), em um cubo proprietário 
multidimensional (MOLAP) ou na forma híbrida HOLAP.
Segundo Machado (2013), na opção ROLAP, os dados são lidos 
diretamente da fonte de dados. Na opção MOLAP, os dados são 
gravados em um formato proprietário, e, na opção HOLAP, é oferecida 
uma combinação das duas opções anteriores, mas é o próprio Analysis 
Services que gerencia quais agregações serão armazenadas como 
MOLAP e quais serão ROLAP.
De acordo com a Microsoft (2017), o Analysis Services utiliza uma 
linguagem criada pela Microsoft, conhecida como Multidimensional 
Expressions (MDX), específica para manipulação de bases 
multidimensionais. A linguagem MDX foi criada para atender a requisitos 
que a SQL não supria. Sendo assim, quando são consultados os dados 
de um cubo dentro do Analysis Manager ou por meio de uma planilha 
Excel, é disponibilizada uma fatia do cubo (slice), que é caracterizada 
pelos eixos do relatório (linhas e colunas) e pela sua paginação, ou seja, 
são declarações MDX que estão sendo executadas.
O Microsoft Analysis Services oferece aos usuários um sofisticado 
ambiente de análises, com boa performance, recursos avançados de 
cálculo e, principalmente, autonomia para os usuários montarem seus 
próprios relatórios.
4.	Considerações	finais
As ferramentas
que integram um ambiente de DW, como as 
ferramentas OLAP e de Data Mining, surgiram para auxiliar o processo 
de disseminação das informações, formando a base para os sistemas de 
BI, a fim de que seja possível encontrar correlações de dados que antes 
eram desconhecidas e transformar a informação em conhecimento. 
149
As ferramentas OLAP disponibilizam o recurso para gerar consultas 
dinâmicas com ótimo desempenho, permitindo que a partir de uma 
resposta o usuário faça outras interações, combinando as dimensões do 
cubo com diferentes níveis de detalhamento e agregação.
TEORIA EM PRÁTICA
Vamos tomar como base um Data Mart de vendas por brick 
referente ao Data Warehouse (DW) organizacional de uma 
indústria farmacêutica que precisa simular as vendas, por 
categoria de produtos, realizadas para uma distribuidora, 
por brick. Um brick representa uma cidade, um bairro ou um 
CEP de um distrito com potencial de venda e, além disso, 
pode ser mantido por nenhum ou por muitos vendedores. 
Considerando essas informações:
1. 1. Elabore o esquema para compreender o fato Vendas 
por brick, considerando as dimensões: categoria de produto, 
brick e distribuidora. A dimensão categoria de produto 
representa uma classificação dos produtos por categoria, 
por exemplo: genérico, similar, OTC e outros; a dimensão 
brick representa as regiões de venda, podendo ser uma 
cidade, um bairro ou um CEP de um distrito; e a tabela 
dimensão distribuidora representa as distribuidoras que 
atendem às vendas da empresa.
2. 2. Em uma ferramenta com recursos OLAP, implemente 
o esquema descrito no item anterior, contemplando 
simulações do fato Vendas por brick.
150
VERIFICAÇÃO DE LEITURA
1. O processo de tomada de decisão envolve grandes 
esforços no sentido de coleta de informações e de uso 
de métodos, técnicas e ferramentas computacionais, 
requerendo muita consciência e habilidade por parte 
dos gestores. A viabilização e extração eficaz de 
informações de um ambiente de Data Warehouse (DW) 
é possível a partir de ferramentas que disponibilizam 
recursos avançados para suportar operações sobre o 
conjunto de dados multidimensional.
 Assinale a alternativa correta que descreve esse tipo de 
ferramenta:
a. Online Transaction Processing (OLTP).
b. Online Analytical Processing (OLAP).
c. Business Intelligence (BI).
d. DataBase Management System (DBMS).
e. Extensible Markup Language (XML).
2. A Tecnologia da Informação tem uma grande 
influência no desenvolvimento das atividades de 
uma empresa. Manipular os dados coletados pelos 
sistemas e transformá-los em informações é um grande 
diferencial para a tomada de decisão, de forma a 
agregar inteligência aos negócios. Em contraste com 
os sistemas________________________, as ferramentas 
________________________ destacam-se pelo potencial 
de recuperação e capacidade de prover análise 
multidimensional para o usuário.
151
 Assinale a alternativa correta que indica os termos que 
preenchem as lacunas:
a. Online Transaction Processing (OLTP); Business 
Inteligence (BI).
b. Online Analytical Processing (OLAP); Online Transaction 
Processing (OLTP).
c. Online Transaction Processing (OLTP); Online Analytical 
Processing (OLAP).
d. Online Analytical Processing (OLAP); Business 
Inteligence (BI).
e. Business Intelligence; DataBase Management 
System (DBMS).
3. As ferramentas que apresentam características OLAP 
passaram a ser referenciadas como ferramentas OLAP. 
Uma característica importante que deve estar presente 
nessas ferramentas é a capacidade de efetuar operações 
que permitem acessar os dados em esquemas 
multidimensionais.
 Assinale a alternativa correta que indica 
operações OLAP:
a. Drill Down, Drill Up; Slice; Dice.
b. Drill Down, Drill Up, Drill Rolap; Drill Molap.
c. Drill Rolap; Drill Molap; Slice; Dice.
d. Slice; Dice; Roll Up; Molap.
e. Drill Across, Drill Throught; Drill Rolap; 
Drill Molap.
152
Referências	Bibliográficas
BARBIERI, Carlos. BI – Business Intelligence: modelagem & tecnologia. Rio de 
Janeiro: Axcel Books, 2001.
BISPO, Carlos Alberto Ferreira. Uma análise da nova geração de sistemas de 
apoio à decisão. 1998. 174 f. Dissertação (Mestrado em Engenharia da Produção) – 
Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos. 1998.
CODD, Edgar F. & CODD, Sharon B.; SALLEY, Clynch T. Providing OLAP (on-
line analytical processing) to user-analysts: An IT mandate. v. 32. Codd and 
Date, 1993.
COLAÇO, M. Jr. Projetando sistemas de apoio à decisão baseados em data 
warehouse. Rio de Janeiro: Axcel Books do Brasil, 2004.
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro: 
Campus, 2004.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São 
Paulo: Pearson Addison Wesley, 2005.
MACHADO, Felipe N. Tecnologia e projeto de data warehouse. 6. ed. São Paulo: 
Erica, 2013.
MICROSOFT DEVELOPER NETWORK. O que há de novo no SQL Server 2017 
Analysis Services: documentação do produto. Disponível em: <https://docs.
microsoft.com/pt-br/sql/analysis-services/what-s-new-in-analysis-services?view=sql-
server-2017>. Acesso em: 30 maio 2019.
ROB, P.; CORONEL, C. Sistemas de banco de dados: projeto, implementação e 
administração. 8. ed. São Paulo: Cengage Learning, 2011.
Gabarito
Questão 1 - Resposta B.
Resolução: Machado (2013) descreve que as ferramentas OLAP 
surgiram com os sistemas de apoio à decisão para fazerem a 
consulta e a análise dos dados do DW, sendo as aplicações às 
quais os usuários têm acesso para extrair os dados de suas bases e 
construir os relatórios com recursos que atendam aos gestores.
Segundo Rob e Coronel (2011), a característica mais marcante 
das modernas ferramentas OLAP é a capacidade de análise 
https://docs.microsoft.com/pt-br/sql/analysis-services/what-s-new-in-analysis-services?view=sql-serv
https://docs.microsoft.com/pt-br/sql/analysis-services/what-s-new-in-analysis-services?view=sql-serv
https://docs.microsoft.com/pt-br/sql/analysis-services/what-s-new-in-analysis-services?view=sql-serv
153
multidimensional. Os dados são processados e visualizados em 
uma estrutura multidimensional, sendo especialmente atrativos 
para os tomadores de decisões de negócios. Enquanto o DW 
mantém dados de suporte a decisões integrados, orientados por 
assunto, variáveis no tempo e não voláteis, o sistema OLAP fornece 
o front end por meio do qual os usuários finais acessam e analisam 
esses dados.
Questão 2 - Resposta C.
Resolução: Online Transaction Processing (OLTP – Processamento de 
Transações On-line): o termo refere-se aos sistemas transacionais, 
que são utilizados no processamento dos dados de rotina, 
gerados diariamente, a partir dos sistemas informacionais de uma 
organização.
Online Analytical Processing (OLAP – Processamento Analítico Online): 
desempenha a análise multidimensional de dados empresariais 
e oferece capacidades para cálculos complexos, análises de 
tendências e modelagem de dados sofisticados. O OLAP habilita 
usuários finais a fazerem análises ad hoc de dados em múltiplas 
dimensões, provendo, dessa forma, o insight e o entendimento que 
eles necessitam para a melhor tomada de decisão.
Questão 3 - Resposta A.
Resolução: Existem diversas operações OLAP que permitem 
acessar os dados em esquemas multidimensionais. Cada 
operação sobre um conjunto de dados multidimensional retorna 
uma apresentação ou sumarização diferente de informações. 
As operações do tipo Drill (Drill Down, Drill Up, Drill Across e Drill 
Throught) permitem a navegação ao longo dos níveis hierárquicos 
de uma dimensão. As operações do tipo Slice and Dice são 
operações para realizar a navegação por meio dos dados na 
visualização do cubo.
Mineração de Dados em Data 
Warehouse
Autora: Iolanda Cláudia Sanches Catarino
Objetivos
• Conhecer e compreender o processo de Descoberta 
de Conhecimento em Bases de Dados (Knowledge 
Discovery in Databases – KDD).
• Conhecer e compreender os fundamentos sobre 
mineração de dados (Data Mining);
• Conhecer e compreender técnicas de Data Mining.
155
1. Processo de Descoberta de Conhecimento em 
Bases de Dados
Muitas organizações estão dispondo de tecnologias de análise de dados 
para auxiliarem na descoberta de padrões de dados e suas relações. As 
ferramentas de mineração de dados (Data Mining) podem ser integradas 
aos ambientes de Data Warehouse (DW), ou utilizadas com outros tipos 
de armazenamento de dados, para obterem informações e, assim, 
gerarem conhecimento sobre as operações realizadas pelos sistemas 
transacionais que mantêm imensas quantidades de dados armazenados 
ao longo dos anos.
A mineração de dados é somente uma parte do processo de exploração, 
descoberta e transformação da informação em conhecimento, fazendo 
parte de um processo maior conhecido como Knowledge Discovery in 
Databases (KDD – Descoberta de Conhecimento em Bases de Dados). 
Ele passou a ser reconhecido no mercado em 1989 como referência ao 
processo de encontrar conhecimento útil em grandes bases de dados, 
enquanto a mineração de dados refere-se à aplicação de algoritmos 
para extrair modelos e relações de dados (FAYYAD et al., 1996). 
O processo de KDD contempla um conjunto de atividades contínuas 
que compartilham o conhecimento descoberto a partir de bases de 
dados em cinco etapas: seleção dos dados, pré-processamento dos 
dados, transformação dos dados, mineração dos dados e interpretação 
dos resultados, como ilustra a Figura 1. Brachman e Anand (1994) 
enfatizam que as etapas do processo KDD são interativas e iterativas. 
Interativas, porque envolvem a cooperação e a habilidade dos usuários 
responsáveis pela análise de dados durante a execução do processo; 
e iterativas, porque podem envolver repetidas seleções de parâmetros 
e conjunto de dados à aplicação das técnicas de mineração de dados 
e, posteriormente, à análise e interpretação dos resultados obtidos, 
refinando e detalhando os conhecimentos extraídos das bases de dados.
156
Figura 1 – Etapas do Processo KDD
Fonte: adaptada de Fayyad et al. (1996, p. 84).
Conforme mostra a Figura 1, na primeira etapa, Seleção de Dados, 
considera-se que, a partir do entendimento do domínio da aplicação a 
ser explorada, são identificadas as bases de dados a serem utilizadas 
para a descoberta de conhecimentos, em conformidade com os 
objetivos a serem atingidos. Na segunda etapa, Pré-Processamento 
de Dados, é feito o agrupamento organizado dos dados de uma ou 
mais bases de dados e realizada a limpeza dos dados, identificando e 
resolvendo problemas de integridade, inconsistências e adaptação dos 
dados ao formato desejado. Essa etapa pode despender até 80% do 
tempo necessário do processo em função das dificuldades de integração 
de dados heterogêneos; por exemplo, a forma de armazenamento de 
dados discretos, como o sexo do cliente, que pode ter sido armazenado 
em uma base de dados como “M” e “F” e, em outra, como “0” e “1”. 
Na terceira etapa do processo KDD, Transformação de Dados, os 
dados pré-processados são transformados para serem armazenados 
adequadamente em DW, de modo a torná-los compatíveis com o uso 
das técnicas de mineração de dados. A quarta etapa, Mineração de 
157
Dados, é considerada a principal atividade do processo KDD, em que 
define-se e aplica-se uma ou mais técnicas (redes neurais, árvores 
de decisão, sistemas baseados em regras e programas estatísticos) 
adequadas de mineração de dados, em conformidade com o domínio 
do problema, ou seja, as técnicas que melhor se adaptam ao contexto 
do negócio.
A última etapa, Interpretação dos Resultados, consiste na análise e 
interpretação das informações com os padrões de dados descobertos, 
induzindo e proporcionando, dessa forma, a geração de conhecimento 
aos analistas de negócio e demais profissionais estratégicos. Não sendo 
satisfatórios os resultados esperados, retorna-se a qualquer uma das 
etapas anteriores de forma interativa e iterativa, iniciando um novo 
processo de descoberta de conhecimento em bases de dados.
Colaço Jr. (2004) enfatiza que o processo KDD é interativo e 
semiautomático, considerando que a interação com o usuário é 
indispensável desde a definição dos dados a serem analisados a até 
a análise e interpretação do conhecimento gerado. Além disso, se a 
organização já possui banco de dados integrados e/ou DW, precisará 
aproveitar as estruturas existentes. Ainda, Lemos, Steiner e Nievola 
(2005) reforçam que a etapa de mineração de dados é a mais importante 
do processo KDD e, no contexto de negócios, é a fase que apoia os 
usuários estratégicos a descobrirem oportunidades de mercado e 
soluções inteligentes e inovadoras.
2. Fundamentos sobre mineração de dados 
(Data Mining)
No cenário competitivo dos negócios, ferramentas de mineração 
de dados são utilizadas nos diferentes segmentos do mercado para 
sustentar e consolidar estratégias que auxiliem no processo de tomada 
158
de decisão, automatizando a detecção de padrões relevantes de grandes 
bases de dados das organizações a partir da utilização de técnicas 
estatísticas e de inteligência artificial, que extraem informações úteis, 
valiosas e previamente desconhecidas, para construir modelos que 
predizem comportamentos, tendências desconhecidas dos dados, 
correlações das informações, entre outros aspectos mensuráveis que 
apoiam as necessidades dos negócios.
Na concepção de Date (2004), a Data Mining pode ser descrita como 
“análise de dados exploratória. O objetivo é procurar padrões 
interessantes nos dados – padrões que possam ser usados para definir a 
estratégia do negócio ou para identificar um comportamento incomum” 
(DATE, 2004, p. 614). Já de acordo com Silberschatz, Korth e Sudarshan 
(2006), Data Mining refere-se ao processo de analisar grandes bancos 
de dados de forma semiautomática para encontrar regras e padrões 
úteis a partir dos dados, lidando com a descoberta de conhecimento nos 
bancos de dados. 
Ainda, Laudon e Laudon (2014) enfatizam que o conceito de Data Mining 
pode ser definido como o processo de descoberta de novas correlações, 
padrões e tendências entre as informações de uma empresa, a partir da 
análise de grandes quantidades de dados armazenados em um banco 
de dados, usando técnicas de reconhecimento de padrões, estatísticas e 
matemáticas. Para Rob e Coronel (2011):
A mineração de dados refere-se às atividades que analisam os dados, 
descobrem problemas e oportunidades ocultas em seus relacionamentos, 
formam modelos computacionais com base nessas descobertas e, então, 
utilizam esses modelos para prever o comportamento do negócio – exigindo 
a mínima intervenção do usuário final. (ROB; CORONEL, 2011, p. 580)
A inteligência de mercado exige soluções que agreguem valor aos 
negócios que possibilitem o acesso e o processo de apresentação 
das informações para sustentar descobertas e análises de dados com 
159
visão sistêmica. Assim, a mineração de dados pode ser adotada como 
uma solução para apoiar a tomada de decisões nas diversas áreas e 
segmentos, como em empresas bancárias e de cartões de crédito, que 
utilizam a análise baseada em conhecimento para detectar fraudes nas 
transações financeiras; para prever eventos e projeções de valores, 
como retornos de vendas; para identificar padrões de compras dos 
clientes e resolver situações que envolvam negociação com clientes; 
para aprimorar o desenvolvimento e a aceitação de produtos lançados 
ou novos produtos; para analisar as perspectivas do mercado de ações; 
para avaliar os clientes e precificar as apólices de seguro; para apoiar a 
gestão de compliance; e muitas outras áreas de negócio.
PARA SABER MAIS
Visão sistêmica: consiste na habilidade de compreender 
o todo a partir de uma análise global das partes e da 
interação entre estas, ponderando os diversos elementos 
que influenciam seu funcionamento, o que inclui fatores 
internos e externos. A visão sistêmica é formada a partir 
do conhecimento do conceito e das características 
dos sistemas.
Rob e Coronel (2011) enfatizam
que a mineração de dados é proativa, 
ou seja, as ferramentas buscam automaticamente identificar anomalias 
e possíveis relacionamentos entre os dados, identificando problemas 
ainda não identificados pelos usuários estratégicos, para, dessa forma, 
prover o conhecimento e aplicá-lo às necessidades dos negócios. A 
mineração de dados contempla quatro fases básicas, exemplificadas 
na Figura 2.
160
A fase de preparação de dados ilustrada na figura como a primeira 
etapa do processo de mineração de dados refere-se à identificação dos 
principais conjuntos de dados e do tratamento de limpeza e integração 
desses dados a serem utilizados pela operação de mineração de dados, 
considerando que os dados de DW já estão integrados e filtrados, a 
partir dos dados operacionais oriundos dos sistemas transacionais.
A fase de análise e classificação de dados, ilustrada na figura como a 
segunda etapa do processo de mineração de dados, refere-se à etapa de 
estudo dos dados para identificar características e padrões comuns com 
a aplicação de algoritmos das ferramentas de Data Mining, encontrando, 
assim, análises de agrupamentos, classificações e grupos de dados; 
vínculos ou dependências entre os dados; e padrões, tendências e 
desvios de dados.
Figura 2 – Fases básicas do processo de mineração de dados
Fonte: adaptada de Rob e Coronel (2011).
A fase de aquisição de conhecimento ilustrada na figura como a terceira 
etapa do processo de mineração de dados refere-se à seleção dos 
algoritmos mais comuns de modelagem e aquisição de conhecimentos, 
161
baseados em redes neurais, lógica indutiva, árvores de decisão, 
classificação ou regressão etc., e a definição desses algoritmos com 
possível interação dos usuários finais.
A fase de prognóstico, ilustrada na figura como a quarta e última 
etapa do processo de mineração de dados, refere-se às descobertas 
de mineração de dados para preverem o comportamento futuro e 
projetarem resultados de negócios, como o provável lançamento de um 
produto novo ou de uma campanha de marketing. Contudo, algumas 
ferramentas de Data Mining não contemplam recursos para essa fase.
De acordo com Barbieri (2001), as ferramentas Online Analytical 
Processing (OLAP – Processamento Analítico On-line) objetivam trabalhar 
os dados existentes, buscando consolidações em vários níveis e tratando 
fatos em dimensões variadas, enquanto as ferramentas de Data Mining 
buscam algo mais que a interpretação dos dados existentes e visam 
essencialmente realizar inferências, tentando descobrir possíveis fatos e 
correlações não explicitadas nos dados de um DW.
A mineração de dados é comumente classificada pela sua capacidade 
em realizar tarefas para diferentes domínios. A literatura indica que 
não existe um consenso de denominação quanto à classificação, às 
funcionalidades, às tarefas, aos métodos ou às técnicas de mineração de 
dados. Contudo, Fayyad et al. (1996) apresentam os seguintes métodos 
de mineração de dados, que têm como objetivo a predição ou descrição 
dos resultados:
a. Classificação: refere-se à tarefa de classificação, sendo uma 
das tarefas mais importantes e mais populares das análises 
discriminantes de bases de dados. Na classificação, o modelo 
analisa o conjunto de dados fornecido, associando ou classificando 
um item a uma ou a várias categorias pré-definidas e derivando 
uma regra que possa ser usada para classificar uma observação, 
referente a um conjunto de dados identificados categorizados 
162
por um assunto. Aplica-se em diversas áreas da saúde, como no 
diagnóstico médico, visando classificar os pacientes e os tipos de 
doenças; na área financeira, para avaliação de risco de crédito etc.
b. Regressão: refere-se à tarefa similar à classificação, porém 
é usada quando os dados são identificados por predição de 
valores numéricos, considerados variáveis independentes ou 
exploratórias, e não pela categorização dos itens analisados. 
Assim, é possível verificar o eventual relacionamento funcional que 
possa existir entre duas ou mais variáveis quantitativas. Observa-
se que a diferença básica entre o relacionamento entre variáveis 
e o método de classificação é que naquele a tarefa estimada lida 
com resultados discretos, enquanto o de classificação lida com 
resultados contínuos. É usada principalmente na área de vendas e 
marketing.
c. Agrupamentos (Clusters): refere-se à tarefa de segmentar 
um conjunto de dados em grupos diferentes cujos itens são 
semelhantes, ou seja, subdivide o conjunto de dados em um 
conjunto menor, sendo similar no comportamento dos atributos 
de segmentação. A partir da mineração de dados, são descobertos 
grupos diferentes entre o conjunto de dados selecionado, 
diferentemente do método de classificação, em que as classes 
de categorias são pré-definidas. São usados em problemas 
relacionados ao processo de linha de produção, por exemplo, para 
detecção de defeitos de fabricação.
d. Sumarização: refere-se à tarefa de descrever padrões e 
tendências, que são reveladas por subconjuntos de dados 
compactados. Funções mais sofisticadas envolvem técnicas de 
apresentação e visualização, que facilitam a interpretação dos 
resultados, como no formato de histogramas e diagramas de 
dispersão. Isso é possível a partir da geração automática de 
relatórios que demostram uma descrição compacta para um 
163
subconjunto de dados com características similares, demostrando, 
assim, as relações funcionais entre as variáveis definidas para 
a análise exploratória do subconjunto de dados. É usada em 
aplicações de diferentes domínios, como para identificar o 
perfil dos clientes de uma operadora de telefonia que residem 
em determinada região e identificar o perfil dos clientes de 
e-commerce para direcionar ofertas de produtos.
e. Regras de Associação: refere-se à tarefa de identificar as regras 
de associação entre variáveis que ocorrem juntas em conjuntos 
de dados para estudar, principalmente, preferências e afinidades, 
orientar análises e investigações, visando principalmente definir 
oportunidades na área de marketing. Uma regra de associação 
é definida como se X então Y, ou X ⇒ Y, onde X e Y são conjuntos 
de itens e X ∩ Y = ∅. Por exemplo, um modelo de análise de 
associação poderia descobrir que um cliente em 65% das vezes, 
ao comprar um produto X, também compra o produto Y. Esse 
é o exemplo clássico de uma grande rede de supermercados 
norte-americana, o Wall Mart, que descobriu que um número 
razoável de homens comprava as fraldas e também as cervejas 
na véspera de finais de semana. De acordo com a história, a partir 
dessa análise de associação entre os dois produtos, a rede de 
supermercados utilizou o novo conhecimento para aproximar as 
gôndolas desses produtos, incrementando a venda conjunta das 
fraldas e das cervejas.
f. Análise de Séries Temporais: refere-se à tarefa similar à regra 
de associação com objetivo de aplicar algum tipo de padrão 
(tendências, variações sazonais, variações cíclicas e variações 
irregulares) no conjunto de dados, para determinar que tipos 
de sequências podem ocorrer em um determinado período, ou 
seja, sequencial no tempo. Como exemplo, a análise temporal de 
ocorrências e frequência de abalos sísmicos em uma determinada 
região; na área de vendas, é comum analisar a frequência que 
um cliente adquire um produto ou que, a partir da compra de um 
164
produto, ele retorna após um período de tempo para comprar um 
outro produto relacionado.
ASSIMILE
Machine Learning (Aprendizado de máquina): é uma área 
da ciência da computação que significa aprendizagem de 
máquina ou aprendizado automático. Ela evoluiu do estudo 
de reconhecimento de padrões em dados e da teoria da 
aprendizagem computacional em inteligência artificial, 
permitindo que sistemas aprendam e tomem decisões com 
o mínimo de intervenção humana.
3. Técnicas aplicadas em Data Mining
Um conjunto de técnicas de natureza estatística e de inteligência 
artificial evoluiu ao longo das décadas, adaptando-se com as
técnicas de 
aprendizado de máquina, a partir da década de 1990, e constituindo, assim, 
as características das ferramentas de Data Mining (BARBIERI, 2001).
Não existe uma técnica de mineração de dados que possa ser 
considerada melhor que outra. O sucesso da aplicação de Data Mining 
depende muito da experiência, sensibilidade e expertise do analista 
de negócio, o qual terá que identificar qual a melhor ferramenta a ser 
utilizada, considerando como e onde os dados estão armazenados, 
bem como qual método será adotado para gerar o conhecimento 
pretendido. A seguir, estão descritas algumas técnicas que são adotadas 
na implementação dos processos das ferramentas de Data Mining, 
em conformidade com as características dos métodos de mineração, 
segundo Barbieri (2001).
165
a. Árvores de Decisão (Decision Tree): as árvores de decisão 
caracterizam-se pelo método de classificação de dados, sendo 
conveniente adotar essa técnica quando o objetivo é gerar regras 
que possam ser entendidas, explicadas e traduzidas para a 
linguagem natural. A árvore de decisão é uma técnica que, a partir 
de uma massa de dados, cria e organiza regras de classificação 
e decisão em formato de diagramas de árvores, que classificam 
suas observações ou predizem classes baseadas nos valores dos 
atributos de um conjunto de dados.
b. Redes neurais: as redes neurais artificiais tentam construir 
representações internas de modelos ou padrões detectados 
nos dados que envolvem o desenvolvimento de estruturas 
matemáticas com habilidade de aprendizado, por meio de 
experiências de operações da própria máquina. As redes neurais 
utilizam um conjunto de elementos de processamento, também 
chamados de nós e links, análogos aos neurônios. Os elementos 
são interconectados em uma rede que implementa detecções 
sofisticadas de padrões e algoritmos de aprendizado de máquina, 
construindo modelos de dados. Aplicações de redes neurais estão 
sendo adotadas principalmente nos campos da medicina, da 
ciência e dos negócios.
c. Algoritmos Genéticos: são utilizados para encontrar soluções 
de problemas dinâmicos e complexos que envolvem centenas 
ou milhares de variáveis e/ou fórmulas para identificar as 
descobertas, gerando possíveis soluções simultaneamente. 
As técnicas são baseadas em métodos inspirados na biologia 
evolucionária, como herança, mutação, seleção e cruzamento, 
capazes de realizar pesquisas adaptativas e robustas para o 
domínio explorado, principalmente na área de análise de imagens 
e projetos de engenharia.
d. Análise de Aglomerações (Cluster Analysis): a técnica de 
análise de aglomeração ou clusterização identifica a existência de 
diferentes grupos dentro de um conjunto de dados. Constatada 
essa existência, agrupam-se os elementos estudados de acordo 
166
com suas similaridades, podendo refiná-los e definir a priorização 
entre eles.
e. Análise de Regressão: a técnica de análise de regressão processa 
os dados das bases de dados de maneira a determinar um 
modelo/equação que represente o relacionamento existente 
entre as variáveis em estudo, ajustando uma linha reta em uma 
nuvem de pontos de dados e decidindo qual reta é a melhor 
representação de todas as observações consideradas de tarefas 
de sumarização, predição e estimativa. Os resultados de uma só 
análise podem atender a mais de um objetivo proposto.
f. Predição com Séries Temporais: a técnica de predição com 
séries temporais de tempo, espaço físico ou volume é utilizada 
principalmente no cálculo de previsão de um conjunto de 
observação, dados seus valores ao longo do tempo, utilizando-
os na predição de valores futuros da série em questão. Assim, é 
possível armazenar as informações das variáveis ao longo de um 
período, permitindo que sejam observadas repetidamente em 
ciclos distintos.
As técnicas do Data Mining têm sido frequentemente aplicadas com 
sucesso para a solução em diversas áreas, por exemplo:
• Saúde e medicina: identificar tratamentos de sucesso para 
os diferentes diagnósticos de doenças; prever qual perfil 
de pacientes que apresentam maior probabilidade de 
desenvolverem doenças; identificar práticas assertivas que 
melhorem o atendimento e otimizem os custos; identificar e 
prever doenças a partir da análise de imagens.
• Mercado financeiro: prever as oscilações das ações na bolsa 
de valores decorrentes do cenário econômico nacional ou 
internacional; prever e detectar fraudes no uso de cartões de 
crédito; prever análises de créditos aos clientes.
• Vendas: identificar padrões de comportamento dos 
consumidores; identificar clientes que possam migrar para o 
167
concorrente e tentar retê-los; analisar cestas de mercado a 
partir das associações entre produtos adquiridos; encontrar 
características dos consumidores em função da região 
demográfica em que vivem; prever quais consumidores serão 
atingidos nas campanhas de marketing.
• Seguros e planos de saúde: detectar procedimentos médicos 
requisitados ao mesmo tempo; identificar comportamentos 
fraudulentos dos segurados; prever quais consumidores têm 
tendência a comprar novas apólices.
• Telecomunicação: classificar clientes de acordo com seu 
potencial de compra de serviços; identificar fraudes em ligações 
telefônicas.
• Transporte: determinar a distribuição de trajetos e horários 
decorrentes das atividades diárias ou sazonais dos passageiros; 
analisar padrões de sobrecarga; definir a maneira mais 
produtiva com otimização de custos dos itinerários de frotas 
de veículos.
Muitas ferramentas modernas de Data Mining oferecem recursos 
visuais que mostram os dados multidimensionais em telas 
bidimensionais, associando os registros de dados ou conjuntos 
de registros de dados a uma série de atributos visuais de fácil 
usabilidade e compreensão aos usuários, assim combinando 
as complexas demonstrações visuais com controles de seleção 
interativa. A Figura 3 mostra algumas interfaces de uma ferramenta 
de Data Mining, o software TIBCO Spotfire Desktop, que contempla uma 
plataforma para exploração de dados com diferentes representações 
e perspectivas para a análise dos dados.
As quatro interfaces visuais do software TIBCO Spotfire Desktop, 
demonstradas na Figura 3, possuem uma série de recursos para 
configurar os atributos quanto à forma, à cor, ao brilho, à rotação, 
ao tamanho, ao posicionamento, ao reposicionamento e à varredura, 
168
ilustrando o resultado por meio de gráficos multidimensionais e 
facilitando, assim, a navegação interativa do usuário e as análises e 
interpretação dos resultados.
Figura 3 – Interfaces do Software TIBCO Spotfire Desktop
Fonte: <https://software.com.br/p/tibco-spotfire-desktop>. Acesso em: 18 jun. 2019.
4.	Considerações	finais
As técnicas estatísticas aplicadas à análise analítica dos dados estão 
cada vez mais sofisticadas, auxiliando as organizações na transformação 
de dados e informações em conhecimento para, assim, apoiarem a 
construção de estratégias inteligentes e, com isso, proporcionarem 
inteligência de mercado e inteligência competitiva.
https://software.com.br/p/tibco-spotfire-desktop
169
Ferramentas de mineração de dados são integradas aos ambientes 
de DW ou a outros tipos de armazenamento para transformarem 
informações em conhecimento potencialmente útil. Sua função principal 
é a extração de grande volume de dados com o objetivo de encontrar 
padrões e correlações significativas e de estimar tendências e novas 
perspectivas que agreguem satisfatoriamente ao contexto do negócio 
explorado.
TEORIA EM PRÁTICA
Considere o contexto de uma agência financeira que 
disponibiliza linha de crédito para seus clientes do tipo 
microempreendedores individuais e para microempresas 
que precisam de crédito para investimento. Ela necessita 
adotar uma ferramenta de mineração de dados para apoiar 
suas decisões de conceder ou não o crédito de investimento 
a esses clientes. De acordo com os métodos e as técnicas 
de Data Mining, definiu-se para especificar essa solução o 
método de classificação
e a técnica de Árvore de Decisão 
com duas possíveis classes: “Sim” – adimplente/receber 
crédito e “Não” – inadimplente/não receber crédito; e os 
seguintes atributos: A) existência de restrições em nome 
da empresa – valores: 1 = Sim e 2 = Não; B) tempo de conta 
com a agência – valores: 1 = de 0 a 12 meses, 2 = de 13 a 24 
meses e 3 = mais de 24 meses; e C) Tempo de Atividade – 
valores: 1 = menos de um ano, 2 = de 1 a 3 anos e 3 = mais 
de 3 anos.
Assim, represente o diagrama de Árvore de Decisão 
com o intuito de facilitar a leitura e compreensão dos 
usuários que usarão a aplicação, conforme os atributos 
e as duas classes de resultado estipuladas e de acordo 
170
com	as	seguintes	regras	de	classificação	do	tipo	
“se-então”:
Regras:
1. Se Restrição = 2 e Tempo de conta ≥2 e Tempo de atividade 
≥2,então Adimplente.
2. Se Restrição = 1 e Tempo de conta =2 e Tempo de 
atividade=3,então Adimplente.
3. Se Restrição = 1 e Tempo de conta = 3 e Tempo de atividade 
≥2,então Adimplente. 
VERIFICAÇÃO DE LEITURA
1. As técnicas e ferramentas de armazenamento de 
dados buscam transformar dados e informações em 
conhecimento. A mineração de dados é somente 
uma parte do processo de exploração, descoberta 
e transformação da informação em conhecimento, 
fazendo parte de um processo maior, conhecido como 
____________________________.
 Assinale a alternativa que indica o termo que 
preenche a lacuna:
a. Online Transaction Processing (OLTP).
b. Online Analytical Processing (OLAP).
c. Business Intelligence (BI).
d. DataBase Management System (DBMS).
e. Knowledge Discovery in Databases (KDD).
171
2. O processo conhecido como Knowledge Discovery in 
Databases (KDD – Descoberta de Conhecimento em 
Bases de Dados), que passou a ser reconhecido no 
mercado em 1989 como referência ao processo de 
encontrar conhecimento útil em grandes bases de 
dados, é constituído por um conjunto de atividades 
contínuas que compartilham o conhecimento 
descoberto a partir de bases de dados em cinco etapas.
 Assinale a alternativa correta que indica as 
etapas do KDD:
a. Seleção das bases de dados, processamento dos 
dados, migração dos dados para Data Warehouse, 
mineração dos dados e validação dos dados.
b. Seleção dos dados, pré-processamento dos dados, 
transformação dos dados, mineração dos dados e 
interpretação dos resultados.
c. Diagnóstico dos dados, seleção dos dados, análise 
dos dados, interpretação dos dados e validação dos 
resultados.
d. Levantamento dos requisitos, análise dos dados, 
projeto dos dados, implementação dos dados e teste 
com os dados.
e. Análise dos dados, projeto das informações, 
mineração dos dados, implementação dos algoritmos 
e Interpretação dos resultados.
3. A mineração de dados é comumente classificada pela 
sua capacidade de realizar tarefas para diferentes 
domínios. Fayyad et al. (1996) apresentam os métodos 
de mineração de dados que têm como objetivo a 
predição ou descrição dos resultados. Considerando 
a aplicabilidade dos diferentes métodos, assinale a 
172
alternativa que apresenta as características do método 
de Classificação.
a. Usa-se quando os dados são identificados por 
predição de valores numéricos, consideradas as 
variáveis independentes ou exploratórias, e não 
pela categorização dos itens analisados, sendo 
possível verificar o eventual relacionamento funcional 
que possa existir entre duas ou mais variáveis 
quantitativas.
b. Usa-se para segmentar um conjunto de dados em 
grupos diferentes cujos itens são semelhantes, 
ou seja, subdivide o conjunto de dados em um 
conjunto menor, sendo similar no comportamento 
dos atributos de segmentação, descobrindo grupos 
diferentes entre o conjunto de dados selecionado.
c. Usa-se para associar um item a uma ou a várias 
categorias pré-definidas, derivando uma regra que 
possa ser usada para classificar uma observação, 
referente a um conjunto de dados identificados que 
são categorizados por um assunto.
d. Usa-se para descrever padrões e tendências que são 
reveladas por subconjuntos de dados compactados, 
a partir de um subconjunto de dados com 
características similares, demostrando as relações 
funcionais entre as variáveis definidas para a análise 
exploratória do subconjunto de dados.
e. Usa-se para aplicar algum tipo de padrão (tendências, 
variações sazonais, variações cíclicas e variações 
irregulares) no conjunto de dados, para determinar 
que tipos de sequências podem ocorrer em um 
determinado período, ou seja, sequencial no tempo.
173
Referências	Bibliográficas
BARBIERI, C. BI – Business Intelligence: modelagem & tecnologia. Rio de Janeiro: 
Axcel Books, 2001.
BRACHMAN, R. J.; ANAND, T. The process of knowledge discovery in databases: 
a first sketch. In: FAYYAD, U. M. et al. Advances in Knowledge Discovery in 
Databases. Menlo Park: AAAI Press, 1994.
COLAÇO, M. Jr. Projetando sistemas de apoio à decisão baseados em data 
warehouse. Rio de Janeiro: Axcel Books do Brasil, 2004.
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro: 
Campus, 2004.
FAYYAD, U. M. et al. Advances in knowledge discovery and data mining. 
California: AAAI Press, 1996.
LAUDON, K. C. & LAUDON, J. P. Sistemas de informação gerenciais. 11. ed. São 
Paulo: Pearson Prentice Hall, 2014.
LEMOS, E. P.; Steiner, M. T. A; Nievola, J. C. Análise de crédito bancário por meio de 
redes neurais e árvores de decisão: uma aplicação simples de data mining. Revista 
de Administração, São Paulo, v. 40, n. 3, p. 225-234, jul./set. 2005.
ROB, P.; CORONEL, C. Sistemas de banco de dados: projeto, implementação e 
administração. 8. ed. São Paulo: Cengage Learning, 2011.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. 5. ed. 
Rio de Janeiro: Elsevier, 2006.
Gabarito
Questão 1 - Resposta E.
Resolução: A mineração de dados é somente uma parte do 
processo de exploração, descoberta e transformação da informação 
em conhecimento, fazendo parte de um processo maior conhecido 
como Knowledge Discovery in Databases (KDD – Descoberta de 
Conhecimento em Bases de Dados), que passou a ser reconhecido 
no mercado em 1989 como referência ao processo de encontrar 
conhecimento útil em grandes bases de dados, enquanto a 
mineração de dados refere-se à aplicação de algoritmos para 
extrair modelos e relações de dados (FAYYAD et al., 1996).
174
Questão 2 - Resposta B.
Resolução: O processo de KDD é constituído por um conjunto de 
atividades contínuas que compartilham o conhecimento descoberto 
a partir de bases de dados em cinco etapas: seleção dos dados, pré-
processamento dos dados, transformação dos dados, mineração 
dos dados e interpretação dos resultados.
Questão 3 - Resposta C.
Resolução: Refere-se à tarefa de classificação, que é uma 
das tarefas mais importantes e mais populares das análises 
discriminantes de bases de dados. Na classificação, o modelo 
analisa o conjunto de dados fornecido, associando ou classificando 
um item a uma ou a várias categorias pré-definidas, derivando 
uma regra que possa ser usada para classificar uma observação, 
referente a um conjunto de dados identificados que são 
categorizados por um assunto. Aplica-se em diversas áreas da 
saúde, como no diagnóstico médico, visando classificar os pacientes 
e os tipos de doenças; na área financeira, para avaliação de risco de 
crédito etc.
175
Modelagem e arquitetura 
do DW (data warehouse)
Banco de Dados Transacionais x 
Banco de Analíticos
Bloco 1
Marise Miranda
Consolidação de diferentes fontes de dados
• Contexto histórico
• Produção fabril.
• Dados ad hoc.
• Dados centrados na produção.
• Contexto social
• Diversidade das fontes de dados.
• Automação de serviços.
• Redes sociais.
• Conectividade e internet.
• Contexto computacional
• Conectividade e internet.
• Processamento e armazenamento.
Fonte: Rawpixel/iStock.com
Dados – volume e variabilidade
Fonte: elaborada pela autora 
Equipamentos 
e máquinas 
Serviços e 
produção
empresas 
Pessoas/
redes 
sociais
IoT
(internet
das coisas)
I N T E G R A Ç Ã Oo
AUMENTO DO VOLUME
AUMENTO DA VARIABILIDADE
Computação, Conectividade e Internet
Banco de dados transacionais
INCLUIR
EXCLUIR
ALTERAR
ACESSAR
BD TRANSACIONAL
DADOS
DADOS
DADOS
Diagrama ER – base de dados transacional
CAT_PROD 
PRODUTO
DEPTO
VENDEDORES
CLIENTES
PROD_VD
LOJAS
CIDADES
Banco de dados Transacionais Modelo DW
Dimensão 1 
Dimensão 2 
Dimensão 3 
CAT_PROD 
PRODUTO
DEPTO
VENDAS
CLIENTES
PROD_VD
LOJAS
CIDADES
Diagrama ER – base de dados transacional  Diagrama 
ER do data warehouse
Modelo DW
Dimensão 1 
Dimensão 2 
Dimensão 3 
INCLUIR
EXCLUIR
ALTERAR
ACESSAR
CARREGA 
ACESSA
BD TRANSACIONAL MODELO DW
Δ𝑦
Δ𝑥
𝛴
Diagrama ER do data warehouse
PERÍODO 
PRODUTO
FATO_VENDASCLIENTES LOJAS
PROMOÇÃO 
Modelo DW Banco de dados analíticos
INCLUIR
EXCLUIR
ALTERAR
ACESSAR
BD TRANSACIONAL
OLTP 
CARREGA 
ACESSA
MODELO DW
Δ𝑦
Δ𝑥
𝛴 𝑥𝑦2
1 0 0
0 1 0
0 0 1
OLAP 
BD ANALÍTICO
Fonte: ojogabonitoo/iStock.com
Fonte: zmicierkavabata/iStock.com
Conclusão
Um banco de dados transacional integra as bases de dados da 
organização que, em geral, advém dos processos. 
Um banco de dados analítico integra um conjunto de dimensões 
construídas dentro da modelagem do DW. Em geral, são consumidas 
como apoio a tomada de decisão.
Um DW é o caminho intermediário entre os dados transacionais e os 
dados analíticos.
Os datasets para o BD Analítico
Bloco 2
Marise Miranda
Datasets não podem ser chamados de conjunto de dados
Fonte: matejmo/iStock.com
• Datasets são a matéria prima das análises.
• Datasets são coleções de dados tabulares em 
formato tabela, linha e coluna, as linhas são 
os registros/campos e as colunas são 
características.
• Dataset é uma coleção de registros de dados 
logicamente relacionados e armazenados.
• Dataset é ad hoc, personalizado, autocontido, 
sem formatação.
• Datasets podem ser enriquecidos por meio 
de cruzamento com outros dados.
• Relatórios não são datsets.
• Conjuntos de dados tem maior abrangência.
Consolidação de diferentes fontes de dados
Conclusão
Quando se organiza um dataset, este deve partir do princípio do que ser 
quer representar. O que cada atributo significa.
Analogamente, um dataset deve preservar as mesmas características 
quando exposto à amostragem.
A abordagem por amostra dos dados não deve implicar na modelagem 
das análises.
Teoria em prática
Bloco 3
Marise Miranda
Criação de um dataset – Estudo de Caso – Cafeteria
Criar dataset para análises, é uma tarefa complexa. Suponha que você tenha 
que criar um dataset em um Excel, relativo ao desempenho de uma cafeteria. 
São vendidos em média 200 cafés diariamente. A cafeteria abre de domingo a 
domingo, das 7 horas da manhã até às 20 horas.
Além do tradicional café, água, chá e leite também são vendidos. E ainda 
podem ser consumidos pão de queijo, pão com manteiga e brigadeiro.
A média de vendas de todos as bebidas, com exceção do café, é de R$ 77,00 
diariamente.
A média diária de vendas dos produtos alimentícios fica em R$ 65,00 por dia.
Criação de um dataset – Estudo de Caso – Cafeteria
Você poderá elaborar um dataset simulando as vendas dos itens descritos. Leve 
em consideração o desempenho de um mês dessa cafeteria.
Dica: os dados podem ser preenchidos na tabela como data, hora, produto, tipo 
de produto, quantidade, número do pedido, ID do pedido.
Em 10 anos de vendas de café, houve uma variação de 16%, variando de R$ 1,00 
para R$ 4,40 reais.
720.000 cafés vendidos em 10 anos, aproximadamente.
Tabule os dados e crie conceito de perspectiva analítica, siga o modelo.
Verificando as regras de negócio da cafeteria
Tabule os dados e crie conceito de perspectiva analítica. Siga o modelo.
ID
pedid
o
data
hor
a
produt
o
tipo de 
produto
qte
nº 
pedido
preço 
uni
preço 
tot
1
14/01/201
9
07:2
3 bebida
café 
expresso 2 321 R$4,40 R$8,80
2
14/01/201
9
07:2
5 bebida média 1 322 R$5,40 R$9,40
comida
pão de 
queijo 1 322 R$4,00
3
14/01/201
9
07:2
7 comida
pão 
manteiga 1 323 R$2,50 R$2,50
4
5
6
Etc. Etc. Etc. Etc. Etc. Etc. Etc. Etc. Etc.
Dica: 200 * 30 dias = 6000/ mês, 
72.000/ano, em 10 anos = 720.000 cafés 
Dica do professor
Bloco 4
Marise Miranda
Ferramentas SGBD de mercado e projeto Anvisa
Pesquise na internet quais são as principais ferramentas SGBDs, 
e compare suas vantagens e desafios. Fica como dica o Mysql e o 
SQL Server.
Ferramentas SGBD de mercado e projeto Anvisa
Acesse o portal da Anvisa, que apresenta o controle de medicamentos 
do governo brasileiro, e verifique como os dados dos produtos para 
saúde homologados estão disponibilizados para acesso público. Há 
informações sobre o projeto e quais tipos de dados estão 
disponibilizados, bem como o modo de como acessá-los.
Referências
INMON, W. H. Como Construir o Data Warehouse. Rio de Janeiro: 
Campus, 1997.
KIMBALL, R. The Data Warehouse Toolkit: guia completo para 
modelagem dimensional. Rio de Janeiro: Campus, 2002.
Modelagem e arquitetura 
do DW (data warehouse)
Conceitos básicos sobre Data 
Warehouse
Bloco 1
Nome do autor
A viabilização de um DW
• Segmentação de clientes, indicadores da campanha de marketing.
• Performance das vendas.
• Análise da fidelização dos clientes.
• Mensuração do atendimento ao cliente.
• Status da lucratividade, comportamento das oscilações dos negócios.
Fonte: AndreyPopov/iStock.comFonte: firstpentuer /iStock.com
Figura 2 – Status das oscilações da lucratividadeFigura 1 – Segmentação de clientes
Integração de dados 
(a) Dados operacionais e 
Relacionamento com o cliente (CRM)
Fonte: cnythzl/iStock.com
Figura 3 – Integração de dados 
entre ferramentas
(b) DW – Integração e 
análise dos dados.
Fonte: priyanka gupta/iStock.com
Justificativas da divisão entre dados 
brutos/operacionais e analíticos/informacionais
Fonte: blackred/iStock.com
Dados operacionais não 
atendem as demandas analíticas.
Fonte: a-image/iStock.com.
Usuários de dados operacionais são 
diferentes dos usuários que consumem 
dados informativos ou analíticos.
A tecnologia para o 
processamento operacional 
é tecnicamente diferente 
da tecnologia para 
informações ou análises.
Processamento de 
dados operacionais tem 
características 
diferentes de 
processamento analítico 
ou informacional.
https://www.istockphoto.com/br/portfolio/blackred?mediatype=photography
https://www.istockphoto.com/br/portfolio/a-image?mediatype=photography
Percentual de tempo gasto em atividades relacionadas 
aos dados 
Gráfico 1 – Percentual de tempo gasto em atividades relacionadas aos dados 
Fonte: adaptado de Machado (2011, p. 20).
0
5
10
15
20
25
30
35
Sem aplicações estratégicas Com aplicações estratégicas
Acesso aos dados Análise dos dados
Desenvolvimento das decisões Preparação do cenário
%
Sistemas de Informação x níveis organizacionais
Figura 4 – Sistemas de Informação versus Níves organizacionais
Fonte: adaptada de Turban (2007, p. 41).
GESTÃO DAS 
OPERAÇÕES
GESTÃO TÁTICA
GESTÃO 
ESTRATÉGIC
A
TPS
MI
S
DSS
EIS
STAFF OPERACIONAL 
Ambiente de
Data Warehouse (DW)
Atribuições de um DW
Especialização
Dados podem ser extraídos ou não para níveis mais específicos, os
Data Marts, e destes para bases de dados individualizadas.
Acesso
Personalizado por meio de ferramentas que promovem acessos com
diferentes níveis de apresentação.
Não há atualização As atualizações ou updates não ocorrem diretamente no DW.
Extração dos dados Fontes diversas ( internas e externas).
Transformação dos dados
Necessidade de mesclagem ou combinação de dados, gerando novos dados 
específicos.
Infraestrutura tecnológica e manutenção Específica para essa finalidade.
Representação dos dados
Visualizações gráficas, tabuladas, sumarizadas, prontas para consumo, 
conforme perfil dos usuários.
Fluxo Entrada e Saída do Ambiente de DW 
Figura 5 – Entrada e saída do ambiente de DW
Fonte: adaptada
de Turban (2005, p. 82, 84, 87).
DATA
WAREHOUSE
EXTRAÇÃ
O FILTRO
DATA SOURCE 1
Sexo “m”
Sexo “f”
DATA SOURCE 2
Sexo “masc”
Sexo “fem”
DATA SOURCE 3
Sexo “M”
Sexo “F”
ETL
GRÁFICOS
RELATÓRIOS 
RELATÓRIOS 
FILTRO 
CUBO
Conclusão
O DW auxilia a empresa a entender o desempenho dos negócios a 
partir do conhecimento sobre os seus dados.
É preciso que se crie um contínuo fluxo de entrada e saída de 
dados, e que gere valor para quem os consuma dentro da empresa.
Alinhamento do projeto com todos os envolvidos para a preparação 
da implantação, manutenção e atualização, e o uso estratégico 
efetivo do DW dentro da corporação.
Características da visão macro 
de um projeto DW
Bloco 2
Marise Miranda
Por assunto e Temporalidade
• Agrupamento por assuntos de interesse.
• Indicadores analíticos e desempenho.
• Datas são componentes chave.
• Janelas de tempo.
• Alta temporalidade.
Variação 
de 
tempo
Orientação
por assunto
Conclusão
• Carga inicial e incremental.
• Acesso em modo leitura (read).
• Padronização dos dados.
• Filtragem, amostra e agregação.
V O L A T I L I D A D E
I N T E G R A Ç Ã Oo
Quanto a arquitetura, papeis e competências
• BI
Arquitetura
Centralização de 
Competências
• Recursos 
Humanos.
• Ferramentas de carga inicial e atualizações periódicas.
• Ferramentas de limpeza dos dados.
• Ferramentas de consultas.
• Data Marts.
Conclusão
O projeto de DW responde as perguntas feitas pelos gestores.
O projeto de DW é contínuo, orientado por assunto, volátil e exige 
um alto nível de integração ao fluxo empresarial.
A central de competências é diretamente relacionada com a 
Inteligência dos Negócios (BI).
Teoria em prática
Bloco 3
Marise Miranda
Estudo de Caso – Projeto de DW na Fisioampla
A empresa Fisioampla é especializada em serviços de saúde de fisioterapia, e possui filiais em 
diversos locais do país. A Fisiampla tem cadastrados cerca de 1.200.000 clientes que utilizam os 
serviços especializados de fisioterapia, na matriz e em 30 filiais. Além dos serviços, presta consultas 
especializadas para reabilitação de acidentados, pessoas com mobilidade reduzida e idosos.
Cada clínica possui um amplo sistema de reabilitação e atendimento, com fisioterapeutas 
associados. Há consultas clínicas que, além de recomendar as sessões de fisioterapia, recomendam 
o uso de produtos que vão auxiliar na reabilitação ou na redução dos problemas relacionados.
Para extrair valor dos seus dados, a Fisioampla contratou você para estruturar um projeto de DW.
Analise o cenário e proponha uma arquitetura para que a Fisioampla tenha ideia de como os seus 
dados serão utilizados.
Apresentando um modelo de solução DW para a Fisioampla
Faça simulações de quais análises poderiam ser alcançadas com visualizações 
analíticas, que surgiram do uso dessa arquitetura. Você poderia listar alguns 
exemplos de visualizações em relação à dimensão tempo. A partir dos dois 
exemplos a seguir, elabore mais oito questões que poderiam ser de interesse 
da Fisioampla associadas com a dimensões tempo.
Que tipo de paciente é atendido nos 4 trimestres do ano?
Qual tipo de fisoterapia é mais solicitada e em qual época do ano?
Desenhe uma arquitetura conceitual para este caso. Ao propor uma 
arquitetura padrão, verifique a necessidade de criação de um fluxo de dados 
para que o DW seja alimentado.
Dica do professor
Bloco 4
Marise Miranda
Ferramentas ETL e OLAP 
Pesquise na internet quais são as principais ferramentas ETL e OLAP, 
e compare suas vantagens e desafios. Segue a dica da Pentaho e da 
ferramenta Palo.
Referências
INMON, W. H. Building the Data Warehouse. 4. ed. New York: Wiley
Computer Publishing, 2005.
KIMBALL, R. The Data Warehouse Toolkit: guia completo para 
modelagem dimensional. Rio de Janeiro: Campus, 2002.
Machado, F. N. R. Tecnologia e Projeto de Data Warehouse. 5. ed. São 
Paulo, Editora Érica, 2011.
TURBAN, E. Administração de tecnologia da Informação. Editora 
Campus, 2005.
PÓS-GRADUAÇÃO
Modelagem e 
Arquitetura do DW 
(Data Warehouse)
PÓS-GRADUAÇÃO
Data Marts
Bloco 1
Iolanda Cláudia Sanches Catarino
Fundamentos sobre Data Marts
Gestão do 
conhecimento
Pessoas
Processos
TecnologiasEstrutura
Cultura
Fonte: Olena_T/iStock.com
• Transformação da informação em conhecimento:
Figura 1 – Banco de dados
Fundamentos sobre Data Marts
Fonte: vaeenma/iStock.com
• Ambiente básico de um Data Warehouse:
Figura 2 – Ambiente de um Data Warehouse
Arquitetura de Data Warehouse e Data 
Marts
Fonte: elaborado pela autora.
• Ambiente de um Data Warehouse:
Figura 3 – Ambiente de Data Warehouse com 
Staging Area e Data Marts
Tipos de arquitetura de Data Warehouse e 
Data Marts
Fonte: adaptado de Machado (2013).
• Arquitetura do tipo global, centralizada e distribuída:
Figura 4 – Arquitetura global, 
centralizada e distribuída de Data Marts
Tipos de arquitetura de Data Warehouse e 
Data Marts
• Arquitetura do tipo independente:
Figura 5 – Arquitetura independente de 
Data Marts
Fonte: adaptado de Machado (2013).
Tipos de arquitetura de Data Warehouse e 
Data Marts
• Arquitetura do tipo integrada:
Figura 6 – Arquitetura integrada de Data 
Marts
Fonte: adaptado de Machado (2013).
Conclusão
• A arquitetura de um Data Warehouse e de Data 
Marts é determinada por meio de um conjunto de 
ferramentas, que envolve a carga inicial dos dados 
até a geração de consultas que apoiam os usuários 
no processo de tomada de decisão. 
• A definição de uma arquitetura determina o local 
onde o Data Warehouse ou os Data Marts estarão 
residindo fisicamente. 
PÓS-GRADUAÇÃO
Data Marts
Bloco 2
Iolanda Cláudia Sanches Catarino
Tipos de implementação de Data Marts
Fonte: elaborado pela autora.
• Tipo de implementação Top Down:
Figura 7 – Implementação Top Down de Data Marts
Tipos de implementação de Data Marts
• Tipo de implementação Bottom Up:
Figura 8 – Implementação Bottom Up de 
Data Marts
Fonte: adaptado de Machado (2013).
Tipos de implementação de Data Marts
• Tipo de implementação combinada:
Figura 9 – Implementação 
combinada de Data Marts
Fonte: adaptado de Machado (2013).
Conclusão
• A implementação do tipo top down é conhecida 
como a padrão de inicial do conceito de Data 
Warehouse. Esse tipo de implementação força a 
empresa a definir regras de negócios de forma 
corporativa antes de iniciar o projeto do Data 
Warehouse. 
• A implementação do tipo bottom up permite a 
implementação incremental do Data 
Warehouse, por meio do desenvolvimento de 
Data Marts independentes. 
Conclusão
• A implementação do tipo combinada integra as 
arquiteturas top down e bottom up. 
PÓS-GRADUAÇÃO
Teoria em prática
Bloco 3
Iolanda Cláudia Sanches Catarino
Ambiente do Data Warehouse com 
serviços de IA
 Teoria em prática:
• Redes de farmácias e drogarias do segmento de 
varejo farmacêutico nacional, com 
aproximadamente 550 lojas no Brasil. Investiu R$ 
35 milhões em novas lojas e reformas, incluindo a 
reestruturação da arquitetura global do tipo 
distribuída no ambiente de Data Warehouse e 
Data Marts, que está concentrado nas regiões Sul 
e Sudeste. A rede pretende aprimorar os serviço 
de atendimento personalizado aos seus clientes.
Ambiente do Data Warehouse com 
serviços de IA
 Teoria em prática:
• Faça um levantamento e escolha uma tecnologia 
emergente para integrar ao novo ambiente, de Data 
Warehouse, organizacional, com serviços de 
inteligência artificial que agreguem inteligência ao 
negócio e, principalmente, proporcionem novas 
funcionaliades para garantir customização ágil aos 
clientes. 
• Elenque as principais etapas para o projeto da nova 
arquitetura do Data Warehouse e relacione alguns 
dos serviços que poderão ser disponibilizados aos 
usuários estratégicos e/ou clientes.
Ambiente do Data Warehouse com 
serviços de IA
C
u
st
o
m
iz
aç
ão
 d
e
 
se
rv
iç
o
s 
p
ar
a 
o
s 
C
lie
n
te
s 
1. Planejamento sobre:
as fontes de dados s serem 
utilizadas; análise e projeto dos requisitos e das 
estruturas de dados; especificação da qualidade de 
dados a serem considerados; definição da 
padronização dos dados; recuperação dos modelos de 
dados dos sistemas transacionais vigentes; projeto de 
segurança; e definições das tecnologias que serão 
adotadas para o desenvolvimento do DW.
2. Adoção da tecnologia de Inteligência Artificial 
Watson, da IBM, e modelagem dimensional do novo 
modelo da arquitetura global distribuída, integrando 
do Data Warehouse organizacional com a tecnologia 
Watson. 
3. Exemplos de serviços: a) consulta quantitativa por 
região, período e categoria de produto sobre os 
atendimentos realizados on-line (chabot) que 
efetivaram a venda no prazo de 48 horas; b) serviço 
disponível, em app, para os clientes acompanharem as 
tendências dos produtos consumidos por categoria de 
perfil. 
PÓS-GRADUAÇÃO
Dica da professora
Bloco 4
Iolanda Cláudia Sanches Catarino
Fundamentos sobre Business Intelligence
• Leia os capítulos 1 e 2 Introdução ao Business 
Intelligence e Data warehousing, respectivamente, 
do livro Business Inteligence: um enfoque 
gerencial para a inteligência do negócio, de Efraim 
Turban et al., para fixar os conceitos e evolução 
dos Business Intelligence e da arquitetura de um 
ambiente de Data Warehouse e Data Marts. 
Disponível na biblioteca virtual da Instituição.
• Referência: 
TURBAN, E. et al. Business inteligence: um enfoque 
gerencial para a inteligência do negócio. São Paulo: 
Bookman, 2009.
Referências Bibliográficas
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio 
de Janeiro: Campus Ltda., 2004. 
MACHADO, Felipe N. Tecnologia e projeto de data warehouse. 6. 
ed. São Paulo, SP: Erica, 2013.
RAINER, R. K.; CEGIELSKI, C. G. Introdução a sistemas de 
informação: apoiando e transformando negócios na era da 
mobilidade. 3. ed. Rio de Janeiro: Elsevier, 2011.
TURBAN, E. et al. Business inteligence: um enfoque gerencial para 
a inteligência do negócio. São Paulo: Bookman, 2009.
Modelagem e arquitetura 
do DW (data warehouse)
Modelagem de Dados para um 
Data Warehouse
Bloco 1
Marise MIranda
Granularidade de dados
Figura 1 – Níveis de granularidade dos dados
< DETALHAMENTO
< VOLUME
< LATÊNCIA
REPOSTAS MENOS
FLEXÍVEIS
< 
GRANULARIDADE
>
GRANULARIDADE
> 
DETALHAMENTO
> VOLUME 
> LATÊNCIA
REPOSTAS MAIS
FLEXÍVEIS
Fonte: adaptada de Kimball (2002, p. 133-134).
Fonte: adaptado de feellife/iStock.com
A granularidade de dados faz 
referência ao nível de sumarização
dos dados
Exemplo de granularidade
Figura 2 – Exemplo de granularidade e nível de detalhamento
Fonte: elaborada pela autora.
Fonte: izusek /iStock.com
Granularidade?
Exemplo de baixa granularidade e 
alto nível de detalhamento 
Tabelas do banco de dados transacional
Fonte: elaborada pela autora.
Id_Vendas Data Hora Vendedor Valor
1 14/06/2012 16:03:12 Paulo M R$ 2.500,00
2 15/06/2012 16:33:01 Julio W R$ 1.850,00
3 16/06/2012 18:50:10 Paulo M R$ 3.300,00
4 17/06/2012 16:33:01 Paulo M R$ 4.500,00
5 18/06/2012 17:25:06 Maria T R$ 200,00
6 13/07/2012 12:03:12 Julio W R$ 2.135,00
7 14/07/2012 14:40:59 Paulo M R$ 100,00
8 15/07/2012 13:22:08 Paulo M R$ 130,00
9 16/07/2012 14:15:16 Maria T R$ 4.750,00
10 17/07/2012 15:17:30 Maria T R$ 1.889,00
Baixa granularidade Alto detalhamento
Relatório Vendedor x Valor
Exemplo de alta granularidade e baixo nível de detalhamento 
Dados sumarizados para análises
Fonte: elaborada pela autora.
Mês Soma_Valor
jun/12 R$ 12.350,00
jul/12 R$ 9.004,00
Alta granularidade Baixo detalhamento
Qual mês vendeu 
mais, das 50 lojas, 
no ano de 2012? 
Fonte: adaptada de Deagreez/ iStock.com
Estudo de caso: simulação a 
partir de quatro lojas - parte 1 
R$0,00
R$1.000,00
R$2.000,00
R$3.000,00
R$4.000,00
R$5.000,00
R$6.000,00
R$7.000,00
R$8.000,00
Valor
Valores vendas/dia
Loja 1 Loja 2 
Loja 4 Loja 3 
Estudo de caso: simulação a partir de quatro lojas – parte 2 
BG
BG
AG
 R$-
 R$2.000,00
 R$4.000,00
 R$6.000,00
 R$8.000,00
 R$10.000,00
 R$12.000,00
 R$14.000,00
 R$16.000,00
jan/12 fev/12 mar/12 abr/12 mai/12 jun/12 jul/12 ago/12 set/12 out/12
Sumarização: Soma_Valor
Id_Vendas Data Hora Vendedor Valor
1 14/01/2012 16:03:12 Paulo M R$2.200,00
2 15/01/2012 16:33:01 Julio W R$1.550,00
3 16/01/2012 18:50:10 Paulo M R$2.500,00
4 17/02/2012 16:33:01 Paulo M R$1.850,00
5 18/02/2012 17:25:06 Maria T R$3.300,00
6 13/02/2012 12:03:12 Julio W R$4.500,00
7 14/03/2012 14:40:59 Paulo M R$200,00
8 15/03/2012 13:22:08 Paulo M R$430,00
9 16/03/2012 14:15:16 Maria T R$2.110,00
10 17/03/2012 15:17:30 Maria T R$1.123,00
Id_Vendas Data Hora Vendedor Valor
1 14/08/2012 16:03:12 Paulo M R$2.600,00
2 15/08/2012 16:33:01 Julio W R$1.550,00
3 16/08/2012 18:50:10 Paulo M R$1.300,00
4 17/09/2012 16:33:01 Paulo M R$4.200,00
5 18/09/2012 17:25:06 Maria T R$800,00
6 13/09/2012 12:03:12 Julio W R$1.136,00
7 14/10/2012 14:40:59 Paulo M R$200,00
8 15/10/2012 13:22:08 Paulo M R$430,00
9 16/10/2012 14:15:16 Maria T R$4.110,00
10 17/10/2012 15:17:30 Maria T R$123,00
Id_Vendas Data Hora Vendedor Valor
1 14/06/2012 16:03:12 Paulo M R$2.500,00
2 15/06/2012 16:33:01 Julio W R$1.850,00
3 16/06/2012 18:50:10 Paulo M R$3.300,00
4 17/06/2012 16:33:01 Paulo M R$4.500,00
5 18/06/2012 17:25:06 Maria T R$200,00
6 13/07/2012 12:03:12 Julio W R$2.135,00
7 14/07/2012 14:40:59 Paulo M R$100,00
8 15/07/2012 13:22:08 Paulo M R$130,00
9 16/07/2012 14:15:16 Maria T R$4.750,00
10 17/07/2012 15:17:30 Maria T R$1.889,00
Id_Vendas Data Hora Vendedor Valor
1 14/04/2012 16:03:12 Paulo M R$1.200,00
2 15/04/2012 16:33:01 Julio W R$150,00
3 16/04/2012 18:50:10 Paulo M R$200,00
4 17/04/2012 16:33:01 Paulo M R$150,00
5 18/04/2012 17:25:06 Maria T R$3.200,00
6 13/04/2012 12:03:12 Julio W R$1.500,00
7 14/05/2012 14:40:59 Paulo M R$700,00
8 15/05/2012 13:22:08 Paulo M R$830,00
9 16/05/2012 14:15:16 Maria T R$5.110,00
10 17/05/2012 15:17:30 Maria T R$7.123,00
BG
BG
Modelagem operacional e multidimensional – parte 1
MODELO ENTIDADE RELACIONAMENTO - MER
Modelagem operacional e multidimensional – parte 2
MODELO MULTIDIMENSIONAL
Id_vendedor Nome total_vendedor
1 Mario 4.139,00R$ 
2 Luis 1.440,00R$ 
3 Sergio 2.789,00R$ 
4 Augusto 3.230,00R$ 
5 Juvenal -R$ 
Desempenho vendedores
p
ro
d
u
to
s
Tabela dimensão 1 Tabela fato
Exemplo de modelo multidimensional
Tabela dimensão 2
Fonte: adaptada de 
hh5800/ iStock.com
Conclusão
A modelagem de dados é o inicio de um projeto de DW. Deve levar em 
consideração os níveis de granularidade e detalhamento dos dados.
A abordagem deve começar pelo desenho do modelo “entidade 
relacionamento” a fim de sistematizar os conceitos de granularidade, 
correlacionando tabelas dimensões e tabelas fatos
A modelagem multidimensional irá se tornar mais eficiente na medida 
em que a base do modelo ER estiver compreendida, pondo em prática a 
construção de cubos multidimensionais.
Processo de desenho de 
modelo dimensional
Bloco 2
Marise Miranda
Passos para desenho do processo de modelagem
Passo 1 – Desenhe os processos de negócio da organização
• Entender as operações diárias.
• Desenhar os processos.
• Verificar as ligações do processo.
• Cada processo tem entradas e saídas.
• Verificar o fluxo de funcionamento entre processos.
Passos para desenho do processo de modelagem
Passo 2 – Represente o grão
• O grão transmite o nível de detalhe associado à tabela de fatos.
• Uma grão pode ser o registro na linha da tabela de um produto 
adquirido por um cliente.
• As transações de uma conta bancária.
Passos para desenho do processo de modelagem
Passo 3 – Identifique as dimensões
• As dimensões descrevem os dados resultantes dos eventos de 
medição do processo de negócio. 
• Incluir nas tabelas de fatos um conjunto robusto de dimensões, 
representando todas as descrições possíveis que assumem valores
únicos no contexto de cada medição.
• As dimensões normalmente podem ser facilmente identificadas, pois 
representam “Quem, o quê, onde, quando, por que e como”, 
associado ao evento.
Passos para desenho do processo de modelagem
Passo 4 – Identifique as fatos
• Os fatos devem dar respostas sobre o processo de mediação.
• Analisar as métricas de desempenho das tabelas fato.
• Tomar decisões com base nos conjuntos de dados de origem.
Conclusão
As tabelas fato são usadas para expor a métricas em gráficos ou tabelas 
sumarizadas
As dimensões devem ser desenhadas de modo a obedecer a uma 
organização hierárquica. Dimensões e dimensões filhas.
Métricas são geralmente observadas nas tabelas fato. Existem casos de 
realizar sumarizações, transformações, agregações ou cálculos em 
tabelas dimensões. 
Teoria em prática
Bloco 3
Marise Miranda
Estudo de Caso – Vendas no varejo
Uma empresa produtora de grãos para exportação e abastecimento no mercado brasileiro deseja 
iniciar um projeto de data warehouse. A empresa compra os grãos in natura de três fazendas, faz a 
coleta nos silos, leva para a produção de lotes para comercialização interna e internacional. Faça 
uma simulação de uma modelagem muldimensional, considerando, cinco tipos de grãos: feijão 
fradinho, feijão carioca, feijão preto, feijão branco e feijão fava.
A produção é trimestral, com variações de 10% em cada trimestre, a melhor safra é nos três 
últimos meses do ano, quando não é afetada pelas variações climáticas e chuvas. As fazendas estão 
localizadas no Norte, Nordeste e Centro-Oeste, a fábrica de separação e ensacamento fica no Sul 
do país. A logística para transporte dos silos das fazendas é quinzenal. A produção dos feijões é 
afetada pela variação climática, nos seis primeiros meses do ano, clima muito quente e chuvas.
Com base nesse cenário, projete um banco de DW por meio das técnicas de modelagem 
multidimensional. Simule o ambiente populando as tabelas dimensões com dados fictícios de 
produção agrícola, temperatura, tempo e localidade.
Utilizando os quatro passos
Verificar as regras de negócios e os processos da organização.
Represente a granularidade.
Construa as tabelas dimensões.
Construa as tabelas fato.
Dica do professor
Bloco 4
Marise Miranda
Características de capacidade do banco de dados de um 
data warehouse na prática
A empresa Microsoft disponibilizou um conjunto de informações sobre 
dimensionamento da carga de trabalho de um data warehouse.
O objetivo é dividir as consultas ao banco de dados balanceando a carga de 
trabalho.
Supondo que a base de dados de um DW seja de 20 milhões de registros e com 
base nas informações técnicas do SQL Data Warehouse (Microsoft), há a 
necessidade de dimensionar a memória acelerando as consultas.
Faça uma busca na internet com informações de Data Warehouse da Microsoft.
Referências
MACHADO, F. N. R. Tecnologia e Projeto de Data Warehouse. 5. ed. São 
Paulo, Editora Érica, 2010.
INMON, W. H. Building the Data Warehouse. 4. ed. New York: Wiley
Computer Publishing, 2005.
KIMBALL, R. The Data Warehouse Toolkit: guia completo para 
modelagem dimensional. Rio de Janeiro: Campus, 2002.
PÓS-GRADUAÇÃO
Modelagem e 
Arquitetura do DW 
(Data Warehouse)
PÓS-GRADUAÇÃO
Esquema Estrela e 
esquema Floco de Neve
Bloco 1
Iolanda Cláudia Sanches Catarino
Fundamentos sobre a modelagem 
multidimensional
Fonte: ClaudioVentrella/iStock.com
Modelagem 
de negócio
Modelos de 
dados 
lógicos
Modelos de 
dados 
físicos
Esquemas 
Estrela e 
Floco de 
Neves
• Modelagem de dados:
Figura 1 – Modelagem multidimensional 
– cubo de Dados
Fundamentos sobre a modelagem 
multidimensional
Modelagem 
multidimensional
Tabelas de fatos
Tabelas de 
dimensões
• Componentes da modelagem multidimensional:
Figura 2 – Fundamentos
Fonte: elaborado pela autora.
Fundamentos sobre a modelagem 
multidimensional
Fonte: elaborado pela autora.
• Cubo de dados:
Figura 3 – Exemplo de cubo de dados
Esquema Estrela (Star Schema)
Fonte: adaptado de Machado (2013).
• Notação do Esquema Estrela:
Figura 4 – Esquema Estrela
Esquema Estrela (Star Schema)
Fonte: adaptado de Rob e Coronel (2011).
• Hierarquia de atributos:
Figura 5 – Exemplo de hierarquia de atributos
Esquema Estrela (Star Schema)
Fonte: elaborado pela autora.
• Exemplo de Esquema Estrela:
Figura 6 – Esquema Estrela - fato vendas
Esquema Estrela (Star Schema)
• Exemplo de Esquema Estrela:
Figura 7 – Esquema Estrela – fatos vendas e 
compras
Fonte: elaborado pela autora.
Conclusão
O Esquema 
Estrela 
aproxima-se 
bastante do 
modelo de 
negócio.
Facilita a 
criação de 
consultas 
complexas e a 
execução de 
forma intuitiva.
Permite a 
leitura e 
compreensão 
de usuários 
que não estão 
adaptados com 
estruturas de 
banco de 
dados. 
• Modelagem multidimensional:
PÓS-GRADUAÇÃO
Esquema Estrela e 
Esquema Floco de Neve
Bloco 2
Iolanda Cláudia Sanches Catarino
Esquema Floco de Neve
• Notação do Esquema Floco de Neve:
Figura 8 – Esquema Floco de Neve
Fonte: adaptado de Machado (2013).
Esquema Floco de Neve
Fonte: elaborado pela autora.
• Exemplo do Esquema Floco de Neve:
Figura 9 – Esquema Floco de Neve – fato vendas
Conclusão
Características Esquema Estrela
Esquema Floco de 
Neve
Tabela de 
dimensão.
Não normalizada. Normalizada.
Tamanho físico. Grande volume de 
dados nas tabelas de 
dimensões.
Volume de dados 
reduzido nas tabelas de 
dimensões.
Velocidade das 
consultas.
Rápida. Menos rápida, devido a 
normalização.
Tabela 1 - Comparativo entre os Esquemas Estrela e 
Floco de Neve
Fonte: elaborado pela autora.
PÓS-GRADUAÇÃO
Teoria em prática
Bloco 3
Iolanda Cláudia Sanches Catarino
Esquema Estrela da locadora de veículos
 Contexto:
• A locadora tem 143 filiais localizadas em vários estados 
brasileiros e 18 filiais em 4 países da América Latina. Cada 
filial disponibiliza o serviço de aluguel de seus veículos para 
clientes nacionais e estrangeiros. 
• Possui ampla frota com veículos de diferentes categorias 
(ônibus, carros de passeio, utilitários, entre outros), variadas 
marcas e modelos. 
• Os gestores da locadora pretendem analisar os custos, 
faturamento e lucros das filiais, de diferentes períodos das 
locações. 
• Represente a modelagem multidimensional, no formato do 
Esquema Estrela.
Esquema Estrela da Locadora de Veículos
Fonte: elaborado pela autora.
• Esquema Estrela do Fato Aluguel:
Figura 10 – Esquema Estrela – fato aluguel
PÓS-GRADUAÇÃO
Dica da professora
Bloco 4
Iolanda Cláudia Sanches Catarino
Modelagem multidimensional
 Leia os capítulos 3, 5, 6 e 7 da dissertação Uma 
metodologia para desenvolvimento da data 
warehouse e estudo de caso (DILL, 2002), 
disponível no Repositório Institucional da UFSC, 
que descrevem a modelagem multidimensional e 
uma metodologia para o desenvolvimento de Data 
Warehouses. No capítulo 7, há exemplo de um 
estudo de caso especificado desde o projeto lógico 
até sua implementação.
TURBAN, Efraim ; SHARDA, Ramesh ; ARONSON, Jay E. ; KI
Referências Bibliográficas
DILL, S. L. Uma metodologia para desenvolvimento 
da data warehouse e estudo de caso. Dissertação do 
mestrado da Universidade Federal de Santa Catarina, 
Centro Tecnológico. Programa de Pós-Graduação em 
Ciência da Computação, 2002.
MACHADO, F. N. Tecnologia e projeto de data 
warehouse. 6. ed. São Paulo, SP: Erica, 2013.
Referências Bibliográficas
ROB, P.; CORONEL, C.. Sistemas de banco de dados: 
projeto, implementação e administração. 8. ed. São 
Paulo: Cengage Learning, 2011. 
PÓS-GRADUAÇÃO
Modelagem e 
Arquitetura do DW 
(Data Warehouse)
PÓS-GRADUAÇÃO
Ferramentas de Dados 
em um Data Warehouse
Bloco 1
Iolanda Cláudia Sanches Catarino
Fundamentos sobre o Processamento Analítico 
On-line (OLAP)
OLAP
Análise 
multidi-
mensional
Análises de 
tendências
Consultas 
dinâmicas 
Interface 
intuitiva
Cálculos 
complexos
Fonte: ClaudioVentrella/iStock.com
• Características OLAP:
Figura 1 – Cubo de dados
Operações OLAP
Fonte: adaptado de Machado (2013).
• Operação Drill Down:
Figura 2 – Exemplo de Drill Down
Operações OLAP
• Operação Drill Up ou Roll Up: 
Figura 3 – Exemplo de Drill Up
Fonte: adaptado de Machado (2013).
Operações OLAP
• Operação Drill Across:
Figura 4 – Exemplo de Drill Across
Fonte: adaptado de Machado (2013).
Operações OLAP
• Operação Drill Throught:
Figura 5 – Exemplo de Drill Throught
Fonte: adaptado de Machado (2013).
Operações OLAP
• Operação Slice:
Figura 6 – Exemplo de Slice
Fonte: adaptado de Machado (2013).
Operações OLAP
• Operação Dice:
Figura 7 – Exemplo de Dice
Fonte: adaptado de Machado (2013).
Conclusão – OLAP: 
Capacidade de efetuar operações.
•Cada operação retorna uma apresentação ou sumarização.
Geram consultas dinâmicas, com ótimo desempenho.
Permitem interações dos usuários, combinações das 
dimensões e diferentes níveis de detalhamento e agregação. 
PÓS-GRADUAÇÃO
Ferramentas de Dados 
em um Data Warehouse
Bloco 2
Iolanda Cláudia Sanches Catarino
Ferramentas OLAP
Visão conceitual 
multidimensional
Dimensionalidade 
genérica
Dimensões e níveis 
de agregação 
ilimitados
Operações 
dimensionais
Manipulação de 
matriz esparsa 
dinâmica
Arquitetura cliente-
servidor
Acessibilidade
Transparência
Manipulação de 
dados intuitiva
Desempenho 
consistente de 
relatório
Flexibilidade nas 
consultas
Suporte 
multiusuário
• Critérios para as Ferramentas OLAP:
Figura 8 – Critérios
Fonte: elaborado pela autora.
Ferramentas OLAP
 Classificação das Ferramentas OLAP:
• OLAP Multidimensional (MOLAP).
• OLAP Relacional (ROLAP).
• OLAP Híbrido (HOLAP).
• OLAP Web (WOLAP).
Conclusão – Ferramentas OLAP:
A escolha de uma ferramenta OLAP envolve a análise das 
funcionalidades que a ferramenta implementa. 
•Existe uma grande variedade de fornecedores das 
ferramentas OLAP.
As ferramentas integram um conjunto de módulos, 
abrangendo parcial ou totalmente as funcionalidades de cada 
tipo.
PÓS-GRADUAÇÃO
Teoria em prática
Bloco 3
Iolanda Cláudia Sanches Catarino
Data Mart de vendas por brick
 Contexto:
• Data Mart de Vendas por brick referente ao Data 
Warehouse (DW) organizacional de uma indústria 
farmacêutica, que precisa simular as vendas, por 
categoria de produtos, realizadas para uma 
distribuidora, por brick.
Data Mart de vendas por brick
 Contexto:
• Uma brick representa uma cidade, bairro ou CEP de 
um distrito, com potencial de venda. Considerando 
que um brick pode ser mantido por nenhum ou por 
muitos vendedores:
a. Elabore o esquema para compreender o fato –
vendas por brick.
b. Implemente o esquema descrito em uma 
ferramenta OLAP. 
Data Mart de vendas por brick
• Esquema Estrela:
Fonte: elaborado pela autora.
Figura 9 – Esquema Estrela para vendas
Data Mart de vendas por brick
• Implementação do esquema – Etapa 1:
Fonte: Elaborada pela Autora.
Figura 10 – Implementação do Esquema Estrela – Etapa 1
Data Mart de vendas por brick
• Implementação do Esquema – Etapa 2:
Figura 11 – Implementação do Esquema Estrela – Etapa 2
Fonte: elaborado pela autora.
Data Mart de vendas por brick
• Implementação do Esquema – Etapa 3:
Figura 12 – Implementação do Esquema Estrela – Etapa 3
Fonte: elaborada pela autora.
Data Mart de vendas por brick
• Implementação do Esquema – Consulta Dinâmica:
Figura 13 – Implementação do Esquema Estrela – Cubo da consulta
Fonte: elaborado pela autora.
PÓS-GRADUAÇÃO
Dica da professora
Bloco 4
Iolanda Cláudia Sanches Catarino
Ferramentas OLAP
 Consulte na Web o guia de apresentação e/ ou 
documentação sobre a ferramenta Analysis
Services, da Microsoft, e sobre a plataforma de 
Business Intelligence Pentaho – suíte Data 
Integration and Analytics da Hitachi Vantara, a 
fim de conhecer a arquitetura e componentes 
dessas ferramentas que integram recursos de 
ferramentas OLAP. 
Referências Bibliográficas
MACHADO, Felipe N. Tecnologia e projeto de data 
warehouse. 6. ed. São Paulo, SP: Erica, 2013.
ROB, P.; CORONEL, C.. Sistemas de banco de dados: 
projeto, implementação e administração. 8. ed. São 
Paulo: Cengage Learning, 2011. 
PÓS-GRADUAÇÃO
Modelagem e 
Arquitetura do DW 
(Data Warehouse)
PÓS-GRADUAÇÃO
Mineração de Dados 
em Data Warehouse
Bloco 1
Iolanda Cláudia Sanches Catarino
Processo de descoberta de conhecimento 
em bases de dados
Etapas do processo Knowledge Discovery in Databases
(KDD) - Descoberta de Conhecimento em Bases de Dados:
Fonte: adaptado de Fayyad et al. (1996).
Figura 1 – Etapas do Processo KDD
Fundamentos sobre Mineração de Dados 
(Data Mining)
Fonte: adaptado de Rob e Coronel (2011).
Processo de mineração de dados:
Figura 2 – Fases básicas do processo de 
mineração de dados
Fundamentos sobre Mineração de Dados 
(Data Mining)
• Métodos de mineração de dados, segundo Fayyad et al. 
(1996): 
M
ét
o
d
o
s:
Classificação
Regressão
Agrupamentos (clusters)
Sumarização
Regras de associação
Análise de séries temporais
Conclusão
 A mineração de dados é comumente classificada 
por sua capacidade em realizar tarefas para 
diferentes domínios.
 As ferramentas de mineração de dados buscam 
algo mais que a interpretação dos dados 
existentes. Sua função principal é a extração de 
grande volume de dados, com o objetivo de 
encontrarem padrões e correlações significativas, 
estimarem tendências e novas perspectivas que 
agreguem satisfatoriamente com o contexto do 
negócio explorado.
PÓS-GRADUAÇÃO
Mineração de Dados 
em Data Warehouse
Bloco 2
Iolanda Cláudia Sanches Catarino
Técnicas aplicadas em Data Mining
Principais técnicas de Data Mining:
Té
cn
ic
as
:
Árvores de decisão
Redes neurais
Algoritmos genéticos
Análise de aglomerações
Análise de regressão 
Predição com séries temporais
Técnicas aplicadas em Data Mining
Fonte: <https://software.com.br/p/tibco-spotfire-desktop>. 
Acesso em: 17 jul. 2019.
Ferramentas de Data Mining - Software TIBCO 
Spotfire Desktop:
Figura 3 – Exemplo de interface 1
https://software.com.br/p/tibco-spotfire-desktop
Técnicas aplicadas em Data Mining
Fonte: <https://software.com.br/p/tibco-spotfire-
desktop>. Acesso em: 17 jul. 2019.
Ferramentas de Data Mining - Software TIBCO 
Spotfire Desktop:
Figura 4 – Exemplo de interface 2
https://software.com.br/p/tibco-spotfire-desktop
Conclusão
• Ferramentas de mineração de dados são integradas 
aos ambientes de Data Warehouse ou a outros 
tipos de armazenamento para gerar informações 
em conhecimento potencialmente útil. 
• As técnicas estatísticas aplicadas à análise analítica 
dos dados estão cada vez mais sofisticadas, 
auxiliando as organizações na transformação de 
dados e informações em conhecimento. 
PÓS-GRADUAÇÃO
Teoria em prática
Bloco 3
Iolanda Cláudia Sanches Catarino
Técnicas aplicadas em Data Mining
 Uma agência financeira disponibiliza linha de crédito para seus 
clientes do tipo microempreendedores individuais e para 
microempresas que precisam de crédito. Definiu-se, para especificar 
essa solução, o método de classificação e a técnica de Árvore de 
Decisão com:
• Duas Classes: 
1. Sim: adimplente/receber crédito.
2. Não: inadimplente/não receber crédito.
• Aributos: 
A. Existência de restrições em nome da 
empresa – valores:
1 = Sim e 2 = Não;
A. Tempo de conta com a agência – valores:
1 = de 0 a 12 meses, 2 = de 13 a 24 meses e 3 
= mais de 24 meses;
A. Tempo de Atividade – valores:
1 = menos de um ano, 2 = de 1 a 3 anos, 3 = 
mais de 3 anos. 
Técnicas aplicadas em Data Mining
 Represente o diagrama de Árvore de Decisão, de acordo com 
as seguintes regras de classificação do tipo se-então:
Regras:
• Se Restrição = 2 e Tempo de conta ≥ 
2 e Tempo de atividade ≥ 2, então 
Adimplente
• Se Restrição = 1 e Tempo de conta = 
2 e Tempo de atividade = 3, então 
Adimplente
• Se Restrição = 1 e Tempo de conta = 
e Tempo de atividade ≥ 2, então 
Adimplente
Técnicas aplicadas em Data Mining
• Árvore de Decisão para solução:
Fonte: elaborado pela autora.
Figura 5 – Árvore de decisão
PÓS-GRADUAÇÃO
Dica da professora
Bloco 4
Iolanda Cláudia Sanches Catarino
Fundamentos sobre Business Inteligence
 Leia o capítulo 4, Data, Text e Web Mining, do livro 
Business Inteligence: um enfoque gerencial para a 
inteligência do negócio, de Efraim Turban et al., para 
fixar os conceitos, características, métodos e 
técnicas adotadas para identificar os padrões de 
dados e conferir mais exemplos de aplicações.
 Disponível na biblioteca virtual da instituição.
 Referência: 
TURBAN, E. et al. Business inteligence: um enfoque 
gerencial para a inteligência do negócio. São Paulo: 
Bookman, 2009.
TURBAN, Efraim ; SHARDA, Ramesh ; ARONSON, Jay E. ; KI
Referências Bibliográficas
FAYYAD, U.M.; PIATETSKY-SHAPIRO, G.; SMITH, P.; 
UTHURUSAMY, R. Advances in knowledge discovery and
data mining. California: AAAI Press, 1996.
ROB, P.; CORONEL, C.. Sistemas de banco de dados: 
projeto, implementação e administração. 8. ed. São Paulo: 
Cengage Learning, 2011. 
TURBAN, E. et al. Business inteligence: um enfoque 
gerencial para a inteligência do negócio. São Paulo: 
Bookman, 2009.
 
 
 
Modelagem e Arquitetura do DW 
(Data Warehouse) 
W
BA
07
48
v1
.0
 
 
 
 
Autoria do Desafio Profissional: Iolanda Cláudia Sanches Catarino. 
Leitor Crítico: Wendel Brustolin da Silva. 
 
 Desafio Profissional 
 
1. Caso - Novos Fatos de Data Marts para Agripoli Brasil 
A distribuidora de insumos químicos agrícolas, Agripoli Brasil, está há trinta e cinco anos no 
mercado brasileiro, em Cuiabá, estado do Mato Grosso, atuando com fornecedores, produtores 
rurais, revendas e cooperativas, na venda de defensivos e fertilizantes. Dos 409 distribuidores/ 
comerciantes cadastrados pelo Órgão Estadual de Defesa Sanitária Vegetal (OEDSV) do Mato 
Grosso, a Agripoli Brasil é a terceira maior distribuidora do estado, representando 
aproximadamente 9% do total das vendas nacionais de insumos químicos agrícolas, em 2018. 
Nas instalações da empresa, o setor de Tecnologia da Informação e Comunicação (TIC) é 
denominado de Núcleo de Tecnologia da Informação (NTI). O NIT apoia, integra e flexibiliza as 
atividades operacionais e estratégias de todos os níveis funcionais da empresa. É constituído por 
uma equipe de profissionais responsáveis pelo suporte de toda infraestrutura tecnológica de rede e 
pelo sistema de Business Intelligence (BI), implantado recentemente, que é mantido em quatro 
servidores locais e sob contingência de réplica contínua em ambiente datacenter Tier 3 
terceirizado, com contratos firmados em nível de serviço para recuperação e ajuste, no padrão 
vinte e quatro horas por dia e sete dias por semana. 
O projeto do BI despendeu um longo período de desenvolvimento, pois a empresa mantinha sistemas 
legados, sistemas de informação e sistemas de gestão em diversos bancos de dados e em demais 
fontes de armazenamento. No BI, a arquitetura do Data Warehouse é do tipo global centralizada com 
implementação bottom-up dos Data Marts. 
Os Data Marts de marketing, financeiro, compra e venda constantemente estão sendo 
incrementados com novas funcionalidades (fatos) e manipulados com as ferramentas On-line 
Analytical Processing (OLAP) e de Data Mining, diante das necessidades dos usuários analistas e 
estratégicos. 
 
 
2. Papel do aluno e sua participação na resolução do problema 
Você, como profissional de TI, e gestor da informação da Agripoli Brasil, precisa atender uma 
solicitação do diretor de vendas da empresa, para projetar duas novas funcionalidades do Data Mart 
de vendas, sendo: 
1. Vendas realizadas pelos representantes para os produtores rurais por localização e período. 
2. Vendas realizadas pelos vendedores para os revendedores por localização e período. 
Considere algumas regras de negócio dos bancos de dados transacionais: 
• Quanto aos produtos: um produto possui nome; descrição, tipo do produto (defensivos ou 
fertilizantes); categoria (exemplo correspondente ao tipo defensivo: herbicidas, fungicidas, 
inseticidas, acaricidas etc); marca (exemplo: Syngenta, Bayer, Basf, Dow AgroSciences, 
Monsanto, DuPont etc); quantidade; preço de custo; preço de venda; e desconto. Cada 
produto é adquirido diretamente de um fornecedor (indústria química fabricante), que 
caracteriza uma marca, sendo que o mesmo fornecedor pode fornecer vários produtos. 
• Quanto aos produtores rurais: mantida por Inscrição Estadual (IE); nome; CPF do produtor; 
CNPJ (apenas para os estados que exigem, como, por exemplo, estado de São Paulo); dados 
da localização da propriedade; data de habilitação; situação; CNAE; telefones e demais dados 
de contatos. Um produtor rural pode realizar várias compras de defensivos e/ ou fertilizantes 
da distribuidora, via pedido, emitido por um representante (vendedor externo que visita 
periodicamente os produtores). Cada representante atende vários produtores rurais por 
região/ estado. 
• Quanto as revendas: mantida por CNPJ; Inscrição Estadual (IE); razão social; nome fantasia; 
endereço completo; situação; CNAE; telefones e demais dados de contatos. Uma revenda 
pode realizar várias compras de defensivos e/ ou fertilizantes da distribuidora, via pedido, 
emitido por um vendedor interno da distribuidora. Cada representante atende vários 
produtores rurais. 
• Quanto as cooperativas: mantida por CNPJ; Inscrição Estadual (IE); nome; endereço completo; 
situação; CNAE; telefones e demais dados de contatos. Uma cooperativa pode realizar várias 
compras de defensivos e/ ou fertilizantes da distribuidora, via pedido, emitido por um 
 
 
representante da distribuidora. Cada representante atende várias cooperativas região/ 
estado. Os cooperados são produtores rurais do tipo pessoa física. 
A partir das regras definidas e dos dados descritos, elabore: 
a. O modelo Entidade Relacionamento (ER) conceitual para melhor compreensão do contexto, 
representando o Diagrama Entidade-Relacionamento (DER). 
b. O Esquema Estrela correspondente ao fato “vendas realizadas pelos representantes para os 
produtores rurais por localização e período”. 
c. O Esquema Floco de Neve correspondente ao fato “vendas realizadas pelos vendedores para 
os revendedores por localização e período”. 
Para resolver este desafio profissional, você deverá ler com atenção o conteúdo da disciplina, 
disponível no ambiente virtual e aprofundar os estudos mediante leituras complementares sobre 
projeto de banco de dados. 
Leitura sugerida, disponível na biblioteca virtual: 
HEUSER, Alberto, C. Projeto de Banco de Dados. 6. ed. São Paulo: Bookman, 2009. 
 
3. Resolução do Desafio Profissional 
Caro(a) aluno(a)! 
Lembre-se de que o conteúdo da disciplina deverá ser considerado no processo de resolução do 
desafio. Além disso, a Biblioteca Virtual está à disposição para pesquisas complementares. 
Outro ponto importante é que o trabalho desenvolvido por você, no processo de resolução do 
desafio, deverá ser submetido à um processo de autoavaliação. O objetivo é estimular a autocrítica 
e reflexão sobre o próprio desempenho a fim de aprimorar sua autonomia e envolvimento pelo 
próprio aprendizado. 
Para isso, você deverá levar em consideração os itens dispostos na grade de autoavaliação que se 
encontra disponível a seguir. 
 
 
 
4. Grade de autoavaliação 
Com o objetivo é estimular a autocrítica e a reflexão sobre o próprio desempenho a fim de 
aprimorar sua autonomia e envolvimento pelo próprio aprendizado, leve em consideração os itens 
dispostos na grade de autoavaliação e pontue o seu desempenho na resolução deste Desafio 
Profissional. 
Tema Objetivos Gerais Objetivos Específicos Peso 
1 
Utilização dos 
referenciais 
teóricos 
Verificar se os 
pressupostos teóricos 
presentes na Leitura 
Fundamental foram 
utilizados para o 
cumprimento da 
proposta. 
1) Os pressupostos
teóricos foram apreendidos? 
2) A problematização do caso contribuiu para sua 
aprendizagem? 
3) A problematização estimulou enriquecimento 
teórico/prático em relação à temática? 
20 
2 
Execução da 
tarefa 
Verificar se a execução 
da tarefa ocorreu de 
forma eficiente, 
conforme sua proposta. 
1) Você atingiu os objetivos propostos? 
2) O Desafio Profissional foi resolvido com base na 
fundamentação teórica e em pesquisas 
complementares? 
3) Você considera sua capacidade de articulação 
dos conceitos mobilizados satisfatória? 
4) Você se sentiria capaz de se posicionar e 
argumentar caso a situação apresentada fosse 
real? 
30 
3 
Estrutura do 
trabalho final 
Avaliar se o produto final 
apresentado como 
resolução do Desafio 
Profissional é 
satisfatório. 
1) A resolução contempla as etapas explicitadas 
pelo Desafio Profissional? 
2) O resultado final apresentado corresponde ao 
desafio apresentado? 
3) O produto final elaborado por você é condizente 
com a proposta de solução? 
30 
4 Desafio 
Avaliar se os objetivos de 
aprendizagem foram 
alcançados. 
1) Você aplicou os conhecimentos teóricos da 
disciplina? 
2) Considera que o trabalho final expressa o 
conhecimento construído por você em termos 
práticos e teóricos? 
3) O trabalho final demonstra as habilidades e 
competências desenvolvidas a partir dos objetivos 
propostos pelo Desafio Profissional? 
20 
 TOTAL 100 
 
 
 
 
 
 
Modelagem e Arquitetura do DW 
(Data Warehouse) WB
A0
74
8
v1
.0
 
 
 
 
 
Autoria do Desafio Profissional: Iolanda Cláudia Sanches Catarino. 
Leitor Crítico: Wendel Brustolin da Silva. 
 
 Proposta de Resolução 
 
a. Modelo ER lógico - DER: 
Figura 1 - Modelo 
 
Fonte: elaborado pela autora. 
b. Esquema Estrela correspondente ao fato “vendas realizadas pelos representantes para os 
produtores rurais por localização e período”: 
 
 
Figura 2 – Esquema Estrela
 
Fonte: elaborado pela autora. 
c. Esquema Floco de Neve correspondente ao fato “vendas realizadas pelos vendedores para os 
revendedores por localização e período”: 
 
Figura 3 – Esquema Floco de Neve 
 
Fonte: elaborado pela autora. 
 
 
 
W
BA
07
48
_v
1.
0
Leitura Complementar 
Disciplina: : Modelagem e arquitetura do DW (Data Warehouse) 
Autora: Iolanda Cláudia Sanches Catarino. 
Prezado aluno, selecionamos as referências abaixo visando 
o aprofundamento das temáticas estudadas na disciplina e a 
complementação dos seus estudos. Para conferir as indicações, acesse a 
nossa biblioteca virtual: <https://biblioteca-virtual.com/> e boa leitura! 
Tema 01 - Banco de Dados Transacionais X Bancos 
de Dados Analíticos. 
O capítulo 1, Introdução ao Gerenciamento de Banco de Dados, apresenta 
uma introdução à tecnologia de banco de dados e sua aplicação 
nas organizações. Descreve os recursos e avanços dos sistemas 
gerenciadores de banco de dados e o impacto das arquiteturas desses 
sistemas no processamento distribuído e na manutenção de softwares. 
Livro disponível no parceito Minha Biblioteca, da Biblioteca Virtual 
da Kroton. 
MANNINO, V., M. Projeto, Desenvolvimento de Aplicações e Administração de 
Banco de Dados. 3. ed. Porto Alegre: AMGH, 2014, cap 1, pág. 27 - 46. 
O artigo discorre sobre o desenvolvimento de um novo método 
(denominado TEM-CM) para transformação formal de modelo de 
dados conceitual para o modelo de dados multidimensionais com 
seus esquemas. O método consiste em formalizar o processo de 
transferência da função de produção na agricultura para modelo de 
dados multidimensional, contribuindo para um projeto mais eficiente 
de Data Warehouses e bases de dados OLAP, para suporte à decisão nos 
sistemas de análise agrícola. Artigo disponível no parceiro EBSCO Host, 
da Biblioteca Virtual da Kroton. 
TYRYCHTR, J.; VASILENKO, A. Transformation Econometric Model to 
Multidimensional Databases to Support the Analytical Systems in Agriculture. Agris 
On-Line Papers in Economics & Informatics, [s. l.], v. 7, n. 3, p. 71–77, 2015. 
2 
https://biblioteca-virtual.com
Tema 02 - Conceitos básicos sobre Data Warehouse 
O capítulo 2, Data Warehousing, aborda as definições e os conceitos 
básicos sobre Data Warehouses (DW), compreendendo a arquitetura, 
componentes e operações de DW; os processos usados no 
desenvolvimento e gerenciamento dos DW; o papel dos DW no suporte 
à decisão e as questões de administração e segurança do DW. Livro 
disponível no parceito Minha Biblioteca, da Biblioteca Virtual da Kroton. 
TURBAN, Efraim et al. Business intelligence: um enfoque gerencial para a 
inteligência do negócio. São Paulo: Bookman, 2009, cap 2, pág. 51- 97. 
O artigo discorre sobre a implantação de um Business Intelligence (BI) 
para gestão de hospitais universitários federais brasileiros, aplicado ao 
gerenciamento da análise da Taxa de Ocupação Hospitalar (TOH) e apoio 
à tomada de decisão clínica, implementado com a ferramenta open 
source de BI Pentaho. O artigo também aborda os principais pontos da 
documentação de eficiência EEFI- 01 estabelecida pela Agência Nacional 
de Saúde Suplementar (ANS), com destaque ao Indicador Hospitalar 
Taxa de Ocupação, que deve sustentar as funcionalidades do BI. Artigo 
disponível no parceiro EBSCO Host, da Biblioteca Virtual da Kroton. 
MELO NOCE, C. A.; AMVAME NZE, G. D.; MATTOS BRASIL, L. Análise da taxa de 
ocupação hospitalar dos hospitais universitários federais brasileiros via Business 
Intelligence. CISTI (Iberian Conference on Information Systems & Technologies/ 
Conferência Ibérica de Sistemas e Tecnologias de Informação) Proceedings, [s. 
l.], v. 1, p. 897–903, 2017. 
Tema 03 - Data Marts 
O artigo discorre sobre o termo de Business Intelligence e os 
componentes que integram esse ambiente, enfatizando os conceitos de 
Data Warehouse e Data Marts. O estudo apresenta o desenvolvimento 
de um protótipo de Data Mart para os recursos financeiros de uma 
3 
organização pública, com o objetivo de responder às necessidades de 
visualização e tratamento de dados da respetiva organização, avaliando 
por meio do modelo TAM a usabilidade, utilidade e a facilidade de uso 
do Data Mart proposto. Artigo disponível no parceiro EBSCO Host, da 
Biblioteca Virtual da Kroton. 
RAMOS, Joel; ALTURAS, B.; MORO, S. Business Intelligence num Organismo Público --
Avaliação de urn Data Mart Financeiro. CISTI (Iberian Conference on Information 
Systems & Technologies/ Conferência Ibérica de Sistemas e Tecnologias de 
Informação) Proceedings, [s. l.], v. 1, p. 2274–2279, 2017. 
O artigo apresenta a proposta de um Data Mart para análise de 
reputação das empresas usuárias da rede social Twitter, com o 
objetivo de fornecer subsídios para a tomada de decisão de futuros 
consumidores e fornecedores. O artigo contempla uma breve revisão 
de literatura sobre Data Warehouse e Data Mart e o desenvolvimento do 
Data Mart proposto, contemplando sua modelagem dimensional e sua 
implementação. Artigo disponível no parceiro EBSCO Host, da Biblioteca 
Virtual da Kroton. 
DE MAGALHÃES, C. V. C. et al. Proposta de um Data Mart para avaliação de 
empresas usuárias do Twitter através das mensagens postadas pelos clientes. 
Revista Brasileira de Administração Científica, [s. l.], v. 3, n. 2, p. 123–135, 2012. 
Tema 04 - Modelagem de Dados para um 
Data Warehouse 
O capítulo 2, Construindo Modelo ER, descreve os conceitos básicos e a 
especificação da modelagem de dados dos bancos de dados relacionais, 
que fundamenta o modelo de Entidade Relacionamento como base 
para consolidar o entendimento sobre os conceitos que envolvem a 
modelagem multidimensional. 
HEUSER, Alberto, C. Projeto de banco de Dados. 6. ed. São Paulo: Bookman, 2009, 
cap. 2, pág. 34 – 71. 
4 
O artigo discorre sobre a proposta de um modelo multidimensional 
e uma linguagem para construir cubos, com o objetivo de especificar 
o processamento analítico on-line. O modelo multidimensional é 
apresentado em duas camadas, a do diagrama de classes e a de pacotes. 
Ambas as camadas
são usadas por uma operação de projeção, que visa 
extrair os cubos projetados. O conjunto de operações para a construção 
de cubos é demostrado por operadores formais, formando uma 
linguagem. Para mostrar a viabilidade do modelo multidimensional e 
operadores, apresenta-se detalhes de implementação de um estudo de 
caso real. Artigo disponível no parceiro EBSCO Host, da Biblioteca Virtual 
da Kroton. 
BOUKRAA, D.; BOUSSAID, O.; BENTAYEB, F. Complex Object-Based Multidimensional 
Modeling and Cube Construction. Fundamenta Informaticae, [s. l.], v. 132, n. 2, p. 
203–238, 2014. 
Tema 05 - Esquema Estrela e Esquema 
Floco de Neve 
O artigo discorre sobre o projeto, modelagem de esquemas dos 
Data Marts definidos e a implementação dos aplicativos de um Data 
Warehouse de processamento analítico on-line multidimensional, 
chamado VecNet Data. É a primeira plataforma on-line globalmente 
integrada que fornece busca, recuperação e visualização eficientes de 
dados históricos, preditivos e estáticos sobre a malária, organizados 
em Data Marts. Artigo disponível no parceiro EBSCO Host, da Biblioteca 
Virtual da Kroton. 
ARIFIN, S. M. N. et al. An online analytical processing multi-dimensional data 
warehouse for malaria data. Database: The Journal of Biological Databases & 
Curation, [s. l.], v. 2017, n. 1, p. 1–20, 2017. 
O artigo descreve um guia metodológico para o desenvolvimento de 
um ambiente de Data Warehouse, composto por Data Marts, para uma 
universidade chilena gerar indicadores de produtividade acadêmica. 
5 
Para isso, o guia metodológico integra diversas abordagens e técnicas, 
tais como: especificação de requisitos de informação; modelagem 
relacional; modelo de desenvolvimento combinado de propostas de 
Kimball e Hefesto; o processo de extração; transformação e carga, com 
uma fase de validação de indicadores; e visualizações integradas e 
interativas para a análise multidimensional dos indicadores, com o uso 
de dashboards. Os Data Marts foram especificados em dois esquemas, 
uma estrela e outro floco de neve. Artigo disponível no parceiro EBSCO 
Host, da Biblioteca Virtual da Kroton. 
ACASTILLO-ROJAS, W.; MEDINA-QUISPE, F. Methodological Guide for a Data 
Warehousing Process. Proceedings of the IADIS International Conference on 
WWW/Internet, [s. l.], p. 221–229, 2017. 
Tema 06 - Ferramentas de Dados em um 
Data Warehouse 
O capítulo 3, Análise de Negócios e Visualização de Dados, descreve a 
análise de negócios e sua importância para as organizações, destacando 
os principais métodos e ferramentas de análise de negócios e de análise 
avançada, com as diferentes ferramentas e plataformas de visualização 
de dados que integram um ambiente de inteligência de negócio (Business 
Intelligence) para dar suporte à inteligência competitiva das organizações. 
TURBAN, Efraim et al. Business intelligence: um enfoque gerencial para a 
inteligência do negócio. São Paulo: Bookman, 2009, cap. 3, pág. 98 - 146. 
O artigo discorre sobre o uso de tecnologias de desenvolvimento da 
Microsoft para demonstrar o desenvolvimento de projetos de Business 
Intelligence em organizações de grande e médio porte, destacando a 
tecnologia padrão de cubos On-line Analitical Processing (OLAP) para 
desenvolver soluções OLAP. Artigo disponível no parceiro EBSCO Host, 
da Biblioteca Virtual da Kroton. 
CRISTESCU, M. P. Using Olap Data Cubes in Business Intelligence. Buletin Stiintific, 
[s. l.], v. 21, n. 2, p. 80–86, 2016. 
6 
Tema 7 - Mineração de Dados em Data Warehouse 
O artigo discorre sobre o uso de método e técnicas de classificação de 
mineração de dados como abordagem para identificação manual de 
fatores de riscos de acidentes aéreos e, com isso, definir estratégias 
eficazes de prevenção de acidentes, considerando os dados da Aviation 
Safety Reporting System (Administração Federal da Aviação). Artigo 
disponível no parceiro EBSCO Host, da Biblioteca Virtual da Kroton. 
SHI, D. et al. A Data-Mining Approach to Identification of Risk Factors in Safety 
Management Systems. Journal of Management Information Systems, [s. l.], v. 34, 
n. 4, p. 1054–1081, 2017. 
O artigo descreve sobre uma proposta de combinação de criação de 
novos algoritmos para análise de grande volume de dados e de sistemas 
de interação para a descoberta do conhecimento, provenientes de 
sensores, dispositivos móveis, imagens, redes sociais, vídeos digitais, 
registros de compras, transações bancárias, computação móvel 
etc. Artigo disponível no parceiro EBSCO Host, da Biblioteca Virtual 
da Kroton.. 
MOLERO CASTILLO, G. G.; BENÍTEZ GUERRERO, E. I.; MEZURA GODOY, C. Interacción 
humano computadora y minería de datos para la generación y representación 
de conocimiento útil. Ciencias de la Información, [s. l.], v. 48, n. 1, p. 3–10, 2017. 
Disponível em: <http://search.ebscohost.com/login.aspx?direct=true&db=a9h&AN= 
126071830&lang=pt-br&site=ehost-live>. Acesso em: 13 ago. 2019. 
7 
http://search.ebscohost.com/login.aspx?direct=true&db=a9h&AN=126071830&lang=pt-br&site=ehost-live
http://search.ebscohost.com/login.aspx?direct=true&db=a9h&AN=126071830&lang=pt-br&site=ehost-live
8 
Bons estudos! 
	Sumário
	Apresentação da disciplina
	Banco de Dados Transacionais versus Bancos de Dados Analíticos 
	Objetivos
	1. Consolidação de diferentes fontes de dados
	2. Banco de dados transacionais
	3. Banco de dados analítico
	4. Considerações finais
	Verificação de leitura
	Referências Bibliográficas
	Gabarito
	Conceitos básicos sobre Data Warehouse
	Objetivos
	1. A viabilização de um Data Warehouse
	2. Construção de um DW
	3. Composição do ambiente de Data Warehouse
	4. Considerações finais
	Verificação de leitura
	Referências Bibliográficas
	Gabarito
	Data Marts
	Objetivos
	1. Fundamentos sobre Data Marts
	2. Arquitetura de Data Warehouses e Data Marts
	3. Tipos de arquitetura e implementação
	4. Considerações Finais
	Verificação de leitura
	Referências Bibliográficas
	Gabarito
	Modelagem de dados para um Data Warehouse 
	Objetivos
	1. Aspectos sobre granularidade de dados
	2. Modelagem de dados para DW
	3. Considerações Finais
	Verificação de leitura
	Referências Bibliográficas
	Gabarito
	Esquema Estrela e Esquema Floco de Neve
	Objetivos
	1. Fundamentos da modelagem multidimensional
	2. Esquema Estrela (Star Schema)
	3. Esquema Floco de Neve (Snow Flake Schema)
	4. Considerações Finais
	Verificação de leitura
	Referências Bibliográficas
	Gabarito
	Ferramentas de Dados em um Data Warehouse
	Objetivos
	1. Fundamentos sobre o Processamento Analítico On-line (OLAP)
	2. Operações OLAP
	3. Classificação das ferramentas OLAP
	4. Considerações finais
	Verificação de leitura
	Referências Bibliográficas
	Gabarito
	Mineração de Dados em Data Warehouse
	Objetivos
	1. Processo de Descoberta de Conhecimento em Bases de Dados
	2. Fundamentos sobre mineração de dados (Data Mining)
	3. Técnicas aplicadas em Data Mining
	4. Considerações finais
	Verificação de leitura
	Referências Bibliográficas
	Gabarito