Modelagem e arquitetura do DW (Data Warehouse)

Prévia do material em texto

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 pelosprojetistas. 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, executivoscorporativos 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.
Consultade 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 dadospara 
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 feitasomente 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 estaremalinhados 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