Livro Fundamentos BI

Prévia do material em texto

W
BA
07
48
_v
1.
0 
MODELAGEM E ARQUITETURA 
DO DW (DATA WAREHOUSE) 
 
 
 
 
 
 
© 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. 
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 
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/ 
http://www.kroton.com.br
 
 
 
 
 
 
 
 
 
 MODELAGEM E ARQUITETURA DO DW (DATA WAREHOUSE) 
SUMÁRIO 
Apresentação da disciplina......................................................................................04 
Banco de Dados Transacionais versus Bancos de Dados Analíticos.................05 
Conceitos básicos sobre Data Warehouse..............................................................32 
Data Marts...................................................................................................................58 
Modelagem de dados para um Data Warehouse................................................82 
Esquema Estrela e Esquema Floco de Neve .................................................. 110 
Ferramentas de Dados em um Data Warehouse ..................................................131 
Mineração de Dados em Data Warehouse .............................................................154 
3 
Apresentação da disciplina 
A disciplina Modelagem e Arquitetura de Data Warehouse contempla 
a modelagem, arquitetura com seus componentes e os tipos de 
ferramentas que integram um ambiente de Data Warehouse. No 
primeiro tema da disciplina, contextualiza-se os princípios, elementos 
e características dos bancos de dados transacionais e dos bancos de 
dados analíticos. No segundo e terceiro temas, fundamenta-se 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 estrutura da modelagem 
multidimensional. O quinto tema compreende a representação da 
modelagem multimensional para Data Warehouse, demonstrando 
e exemplificando as características, elementos e 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 do Processamento 
Analítico Online (Online Analytical Processing – OLAP) em comparação 
com o Processamento de Transações Online (Online Transaction 
Processing – OLTP), apresenta as operações OLAP e a classificação das 
ferramentas OLAP, de acordo com a estratégia de armazenamento 
dessas ferramentas. O último tema da disciplina aborda o processo de 
Descoberta de Conhecimento em Bases de Dados (Knowledge Discovery in 
Databases – KDD) e suas etapas, os fundamentos e as 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 aplicadas 
nas ferramentas de Data Mining. 
4 
 
 
 
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 às transações dos sistemas de informação. 
• Escolher a estrutura tecnológica e de dados para 
suportar as atividades analíticas que envolvem áreas 
de conhecimento especializadas, como apoio à 
tomada de decisão. 
 
 
 
 
 
 
 
1.Consolidação de diferentes fontes de dados 
Quantidades de dados crescentes são disponibilizadas, nas 
organizações, por meio de diversas fontes internas e externas, todos os 
dias e também pela internet. A automação de serviços, como exemplo 
as vendas on-line, está constantemente produzindo e divulgando 
dados sobre bens de consumo e a 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, dentre outras informações, 
são incluídas pelo usuário. O uso de tecnologias integradas nos 
serviços por aplicativos, geram enormes volumes de dados, como 
uso de transações bancárias, navegação na internet e troca de 
informações digitais. 
Todos esses dados gerados em larga escala, de diferentes fontes, fontes 
externas, dados internos das empresas, forma um conjunto de dados, 
que, normalmente, denominam-se de datasource, e quando reunidos 
em um único local, são os sistemas de banco de dados. Os sistemas 
gerecniadores desses ambientes denominam-se SGBD (Sistema de 
Gereciamento de Banco de Dados). 
Esses conjuntos de dados, podem ser formados por um arquivo, um 
banco de dados específico em um DBMS (Database Management System) 
ou até mesmo um feed de dados ativo. SGBD (Sistema de Gerenciamento 
de Banco de dados) ou DBMS (DataBase Management System): são 
softwares que gerenciam a base de dados, retira da aplicação cliente o 
gerenciamento do acesso, a organização e a manipulação dos dados. 
Feeds de dados: são fluxos de dados XML gerados a partir de uma fonte 
6 
 
 
 
 
 
 
de dados on-line e transmitidos para um documento ou aplicativo 
de destino. 
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 as características de funcionamento e 
comportamento desses dados. 
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 os dados podem ser armazenados e acessados. 
Os tipos de modelos de dados estão associados a tipologia, e os mais 
comuns estão 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 personalizadae 
é projetado com base em regras e conceitos que são adotados pelos 
projetistas. A maioria dos modelos de dados podem ser representados 
por um diagrama de banco de dados a ele associado (Figura 1). 
7 
 
 
 
 
 
 
 
 
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 suas dependências, são o modelo dos dados e como se 
relacionam. Nesse sentido, é importante adotar um SGBD, para dar 
suporte o 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. Os modelos refletem a forma como o especialista 
enxerga os dados. O administrador de banco de dados está ligado 
ao modelo físico dos dados, o tipo, os atributos, o armazenamento, a 
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. O modelo conceitual de banco de dados abstrai 
o relacionamento entre as entidades e suas especializações. Esses 
modelos facilitam 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. 
8 
 
Definir qual modelo de dados será usado requer a sua 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 velocidade, redução de custos, usabilidade, dentre 
outras características intrínsecas. Ao escolher um modelo, este deve 
refletir o ambiente observado em que os dados são gerados; serve 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 relacionamentos. A entidades refletem os objetos 
de acordo com sua existência no mundo real, sejam abstratos ou 
concretos, por exemplo, cliente, vendas, rodutos, estoque, etc. As 
entidades possuem relacionamentos entre si. 
Figura 2 – Modelo hierárquico 
Fonte: elaborada pela autora. 
Esse modelo foi usado em SGBD das décadas de 1960 e 1970, 
atualmente mantido apenas em poucos sistemas legados (sistemas 
informacionais ou gerenciais existentes na empresa, que podem 
9 
ser antigos ou recentes). Hoje em desuso por conta de ineficiências 
operacionais, é apenas explorado neste contexto para acrescentar um 
time line sobre a evolução dos modelos. 
1.3 Modelo relacional 
O modelo relacional é o mais utilizado atualmente. Machado (2011) 
descreve que o este classifica os dados em tabelas, também conhecidas 
como relações, em que cada tabela é composta por colunas e 
linhas. Cada coluna lista um atributo da entidade em questão, como 
produto, preço ou data de venda. Os atributos em uma relação 
são chamados de domínio. Na Figura 3, exemplo que 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 para qual 
foi referenciada, no caso, ID_Paciente e Cod_convenio. Em um modelo 
de banco de dados relacional, a chave primária refere-se a 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. 
10 
Cada uma das linhas, também chamada de tuplas, inclui dados sobre 
uma instância específica da entidade em questão, como o ID do 
paciente. Este modelo reflete os tipos de relacionamentos entre essas 
tabelas, incluindo relacionamentos um-para-um, um-para-muitos e 
muitos-para-muitos. Isto 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, um relacionamento de 1 escola relacionado com várias turmas. 
Um aluno pertence somente a uma turma (um para um). Alunos cursam 
disciplinas (N para N). 
Em banco de dados, as tabelas podem ser normalizadas ou trazidas para 
obedecer às regras de normalização. Essas regras organizam os dados 
em projeto de banco de dados, reduzem as redundâncias, aumentam 
a integridade para os dados e melhoram seu desempenho. As regras 
de normalização 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. Isto 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 normaização. Quando 
normalizado, cada dado é atômico ou dividido nas menores partes 
úteis. Bancos de dados relacionais geralmente são gravados em SQL 
(Structured Query Language). 
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, por exemplo, alunos matriculados em disciplinas. Isto 
implica na necessidade de vários registros pai (MACHADO, 2011). Esse 
modelo possibilita relações complexas (Figura 4). 
11 
 
 
 
 
 
 
 
 
 
 
 
 
 
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 de banco 
de dados 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 
12 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
usado para projetar um banco de dados conceitual. Este modelo auxilia 
nas visões existentes dos relacionamentos entre as tabelas e também 
na construção de novas visões em um DW, utilizadas para compor as 
dimensões e as tabelas fato. 
Os dados armazenados em tabelas, como nomes, locais, produto, 
etc., são denominados de entidades, em cada uma possui certos 
atributos, quando juntos formam seu domínio. A entidade pessoa, 
possue dados armazenados com o nome de pessoas, por exemplo. A 
entidade endereço, tem que ter o local onde a pessoa mora, a rua e o 
número, o CEP, o bairro, a cidade, o Estado e o país. A cardinalidade, 
ou relacionamentos entre entidades, também podem e devem serem 
mapeados. Por exemplo se a entidade pessoa possui mais de um local, 
residência ou trabalho. 
Machado (2011) ilustra que este 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 osrelacionamentos entre as tabelas. A Figura 5 apresenta um 
exemplo de modelo ER, ou simplesmentes, 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. 
13 
 
 
 
 
 
 
 
 
 
 
 
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). 
Figura 6 – Modelo Estrela 
Dimensão 3 Fato 
Dimensão 4 
Dimensão 1 
Dimensão 2 
Dimensão 5 
Fonte: elaborado pela autora. 
As dimensões e fatos são componentes complementares e dependentes 
entre si. Em um modelo dimensional, é obrigatório a existência de 
ambos (MACHADO, 2011, p 79). Esses elementos são fundamentais 
para a compreensão e análise das informações, sem eles no modelo 
dimensional, pode haver comprometimento ou inviabilização nas 
análises pretendidas. 
14 
Esta percepção é muito importante para elaborar projetos em DW, uma 
série de agregações, sumarizações, tratamentos são necessários 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 se mantém 
preservado, 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. Na tabela fato 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, em que suas FK ligam às 
dimensões que as descrevem. 
Tabela dimensões: é a tabela que qualifica os dados 
provenientes da tabela fato. Por meio da tabela dimensão 
pode-se criar análises dos dados em múltiplas perspectivas. 
1.6.1 Modelo multidimensional 
Este modelo é uma variação do modelo relacional. Ele é 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), e 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 
15 
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). 
É 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, da qual o acesso deve ser preservado e restrito. 
Já quando se trata das análises, das métricas, das visões, e dimensões, 
o modelo deve ser projetado para ser consumido em ferramentas 
analíticas, dashboards, gráficos e relatórios, neste caso, o OLAP. 
1.7 Modelo de BD NoSQL 
A obtenção de dados de outras fontes que não são modelos SQL, 
surgiram em contraste ao modelo relacional. Por exemplo, um modelo 
de banco de dados semi-estruturados e não estruturados, chamados de 
NoSQL. Além desse, dados provenientes da web, onde várias consultas 
são realizadas, são semi-estruturados, isto 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 dos 
vídeos, áudios, texto, das redes sociais, da web. Em geral aqui 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 estrtuturados ou semi-estruturados precisam ser 
pré-processados para serem tradados como dados estruturados. 
2. Banco de dados transacionais 
Os bancos de dados transacionais são otimizados para executar 
sistemas de produção, como desde portais a instituições financeiras até 
lojas de varejo. Nestes bancos, leitura e escrita em registros individuais 
16 
de dados muito rapidamente, mantendo a integridade dos dados. Os 
bancos de dados transacionais não são criados com a finalidade voltada 
para análises, embora muitas vezes se tornam ambientes analíticos, 
pelo fato de já estarem em funcionamento como bancos de dados, em 
produção, que 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, não para análises. Usá-los como 
análise é um ótimo começo, mas pode ter limitações que impedem 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 
ACID (Atomicidade, Consistência, Isolamento e Durabilidade), o que 
garante que as gravações no banco de dados sejam bem-sucedidas 
ou falhem juntas, mantendo um alto nível de integridade de dados ao 
gravar dados no banco de dados. Os bancos de dados transacionais são, 
portanto, essenciais para transações comerciais em que um alto nível de 
integridade de dados é necessário. 
Exemplo de uma transação bancária: o cliente realizando um débito 
de uma conta corrente e crédito para outra conta corrente. Esta ação 
do cliente desencadeará um processo de transações financeiras, que 
utilizaram um banco de dados, e a arquitetura deste banco/processo 
deve garantir o sucesso ou falha na transação. 
ACID é um conjunto de propriedades que descreve como os bancos de 
dados transacionais são projetados para preservar a integridade das 
gravações no banco de dados. As principais propriedades são descritas 
no Quadro 1. 
17 
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á. Desta forma, todas 
as transações devem ser 100% bem-sucedi-
das para serem confirmadas com êxito no 
banco de dados. 
Consistência 
Uma transação é gravada no banco de dados 
(trazendo o banco de dados 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 ban-
co de dados, ela permanecerá lá, mesmo no 
caso de uma falha no banco de dados. 
Fonte: adaptado de Mysql Reference Manual ([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. A baixa latência é uma característica 
dos bancos transacionais. 
2.3 Principais características do BD transacional 
A seguir, um resumo das principais carcaterísticas que identificam um 
banco de dados transacional (Quadro 2). 
18 
 
Quadro 2 – Características BD Transacional 
Requerimentos Descrições 
Normalização Altamente normalizado 
Esquema Gravação impositiva 
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 deconsulta Altamente flexível 
Escalabilidade Pequeno (MBs) a grande (alguns TBs) (*) 
(*) MBs – MegaBytes; TBs – TeraBytes. 
Fonte: adaptado de Kimball (2002). 
3. Banco de dados analíticos 
Um banco de dados analítico é um sistema somente de leitura 
que armazena dados para históricos ou métricas de negócios, 
como exemplo, o desempenho de vendas e 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, na medida em 
19 
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 
para de Business Intelligence (BI), métricas analíticas e Big Data, em geral, 
como de um Data Warehouseou ou Data Mart. 
O banco de dados analítico é diferente do banco de dados operacional, 
transacional ou OLTP, o primeiro usado para análises e o segundo usado 
para processar as transações. Embora os bancos de dados transacionais 
possam ser usados para suportar o armazenamento de dados e as 
aplicações de BI, não é recomendado por questões de integridade e 
escalabilidade. O banco de dados convencial deve ser preservado, e o 
banco de dados analíticos devem estar em outro schema. 
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, aplicados 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, os bancos de dados analíticos 
20 
https://searchbusinessanalytics.techtarget.com/definition/business-intelligence-BI
https://searchdatamanagement.techtarget.com/definition/data-warehouse
https://searchsqlserver.techtarget.com/definition/data-mart
 
 
 
 
são criados para analisar volumes extremamente grandes de dados 
com maior rapidez do que os bancos transacionais. Os bancos de dados 
analíticos utilizam 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, na qual 
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. 
A vantagem do processamento orientado por colunas é que os 
cálculos em colunas individuais são muito rápidos. Por exemplo, 
uma consulta ao banco de dados, que é para determinar o maior 
salário mensal – máximo (salário) – entre todos os funcionários, 
só precisa 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 
21 
 
 
de dados é fator determinante, quanto ao espaço que os dados 
ocuparão, e com que rapidez poderá ser manipulado. 
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 
e o Redshift coordena 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 AWS (Amazon Web Services) 
e é um serviço de armazenamento de dados em escala 
de petabytes totalmente gerenciado na nuvem. Um Data 
Warehouse do Amazon Redshift é um conjunto de recursos 
de computação chamados 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 banco de dados transacionais e banco de 
dados analíticos 
Há ainda dúvidas quanto aos bancos de dados transacionais e analíticos, 
no que se refere a usar um ou outro. Quando uma transação bancária é 
realizada, por exemplo, um depósito em cheque em determinada conta 
corrente, um processo transacional é disparado. Essa ação irá gerar um 
conjunto de dados para ser associados, armazenados e recuperados, 
22 
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 são caracterizados 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, 
dentre 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óstito. Por este 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 as decisões organizacionais e 
estratégicas. A atividade de análise sobre esses dados, do banco 
analítico, em geral ocorre em modo off-line, em que englobam os dados 
transacionais, agrupados, sumarizados ou amostrados para responder 
as indagações feitas pelos analistas da empresa ou de negócios. 
Diferentemente dos dados transacionais, os dados analíticos requerem e 
necessitam 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. 
Datasets ou conjunto de dados são necessários para as análises de 
dados, representam agrupamentos, comportamentos e amostragens, 
que permitem a aplicação de modelos matemáticos, como tentativa 
de explicar e dar um significado aqueles dados. Os datasets são 
representações de dados tabulares, formatados em registros nas linhas, 
representando os acontecimentos ou ocorrências, e as características 
23 
desses acontecimentos nas colunas. Esse dataset resultará em um 
comportamento associado aqueles acontecimentos e características. 
O Quadro 3 representa uma comparação geral entre o BD analítico e o 
transacional, paraauxiliar no projeto de uma BD com foco em DW. 
Quadro 3 – Comparação geral entre BD ananlítico e BD transacional 
Característica Analítico Transacional 
Caso de uso. 
Analisando grandes 
volumes de dados para 
análise de negócios. 
Processando 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. 
Existem questões de relevância quando ocorre uma tentativa 
reducionista de comparar um banco de dados transacionais e um 
banco de dados analíticos. Neste contexto, vale ressaltar que a 
comparatividade serve como apoio a tomada de decisão. 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. 
24 
Outro ponto fundamental, os bancos de dados de exemplo no Quadro 
3 com capacidade analítica demandam 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 banco de dados 
tradicionais para transações. Mas isso não tira a capacidade de um SGBD 
tradicional, para bancos de dados transacionais, de suportar as análises. 
A questão não é tão simplista. Deve-se considerar o volume, a 
integridade, a velocidade, dentre 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, e isso 
demanda capacidade do banco. A melhor maneira é sempre partir 
de um conceito básico; banco de dados de repositório, que armazena 
as transações, não é um banco 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. 
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 é um banco de dimensões para construir as visões 
analíticas. Portanto, um DW é um repositório que abarca as dimensões, 
tabelas fato e visões que serão consumidas como apoio a tomada de 
decisão. O DW é o caminho intermediário entre os dados transacionais e 
os dados analíticos. 
25 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
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. Também 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. 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, ID do 
pedido. A simulação precisa ter regras estabelecidas 
neste contexto, então pode-se vislumbrar um cenário em 
dez anos de vendas de café. Por exemplo, houve uma 
variação de 16%, e o preço saiu de R$1,00 há dez anos, 
e agora o preço do café custa R$ 4,40. A contabilização 
destes 10 anos, resultou em 720.000 cafés vendidos, 
aproximadamente. Tabule os dados e crie conceito de 
perspectiva analítica, siga o modelo: 
26 
 
 
 
 
 
 
 
 
id_pedido data hora produto tipo de produto qte 
nº pe-
dido 
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édia 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 322 já consiste 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 extratificadas 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. 
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 a as 
visões dos datasets e, portanto, não é recomendável 
utilizá-lo para análises. 
27 
 
 
 
 
 
 
 
 
 
 
 
 
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ítco. 
a. Matricial. 
b. Colunar. 
c. Em linha. 
28 
 
 
 
d. Tabular. 
e. 1ª coluna e 1ª linha da tabela. 
Referências Bibliográficas 
KIMBALL, R. The Data Warehouse Toolkit: guia completo para modelagem 
dimensional. Rio de Janeiro: Campus, 2002. 
INMON, W. H. Building the Data Warehouse. 4. ed. New York: Wiley Computer 
Publishing, 2005. 
MACHADO, F. N. Tecnologia e Projeto de Data Warehouse: uma visão 
multidimensional. São Paulo: Érica, 2011. 
MY SQL. MySQL 5.6 Reference Manual. 14.2 InnoDB and the ACID Model. 
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. 
Brasília, 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 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 de dados ao gravar dadosno banco de 
dados. Os bancos de dados transacionais são, portanto, essenciais 
para transações comerciais em que um alto nível de integridade de 
dados é necessário. 
Exemplo de uma transação bancária: débito de uma conta corrente 
e crédito para outra conta corrente. A arquitetura deve garantir o 
sucesso ou falhar na transação. 
29 
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
 
Questão 2 - Resposta D. 
Resolução: Quadro 3 – Comparação geral entre BD ananlítico e BD 
transacional. 
Característica Analítico Transacional 
Caso de uso. Analisando grandes 
volumes de dados 
para análise 
de negócios. 
Processando 
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. 
Conforme o quadro comparativo a carcaterística das consultas em 
um banco de dados analítico é especializada ou personalizada, pois 
tende a representar alguma agragação, sumarização, 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, na 
qual 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. 
31 
 
 
 
 
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. 
• Composição do ambiente de inicialização de 
projeto DW. 
 
1. A viabilização de um Data Warehouse 
Os sitemas transacionais priorizavam o foco nas técnicas estruturadas 
para manter a integridade e a qualidade dos dados ali armazenados. 
Todos tipos de transações em um processo eram armazenados, por 
exemplo, baixa em estoque de peças, venda de produto unitário, dentre 
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, por exemplo, 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 
a soma das peças baixadas em estoque para controle são exemplos 
de informações executivas. Mas, 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, para 
que a empresa não incorra em prejuízo, comprando peças que não 
serão utilizadas, ficando ociosas no estoque ou perdendo vendas por 
falta de peças que não foram repostas em estoque. Este último exemplo 
implica em informações estratégicas. 
Nesse sentido, há uma diferença entre um projeto de banco de dados 
transacionais, OLTP (Online Transaction Processingn ou Processamento 
de Transações em Tempo Real), e um projeto para DW com tecnologia 
OLAP (Online Analytical Processing, ou Processamento Analítico em 
Tempo Real). O primeiro utilizado no dia a dia da empresa, registrando 
cada operação, 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, 
e podendo ser um modo dinâmico. Porém, a informação não é 
extratificada 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 suscedida 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 
https://AndreyPopov/iStock.com
 
 
o o 
o 
m-
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 caso de 
um CRM (customer relationship management, ou relacionamento com o 
cliente). A integração de dados entre ferramentas pode ser observada 
nas figuras abaixo: 
Figura 3 – Dados operacionais Figura 4 – DW – Integração e 
e relacionamento com o análise dos dados 
cliente (CRM) 
Fonte: cnythzl/iStock.com. Fonte: priyanka gupta/iStock.com. 
35 
https://gupta/iStock.com
https://cnythzl/iStock.com
https://firstpentuer/iStock.com
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, numa 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. Este 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 em 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 anamnesi, que é uma entrevista do médico para ouvir 
os relatos do paciente sobre suas dores e queixas, com isso estabelece 
um diagnóstico, mas 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 pronfundidade. Por isso, as análises sobre 
sazonalidades, 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 quemanalisa. 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 amarzenada. 
36 
 
2. Construção de um DW 
A realidade histórica da organização, seus clientes, fornecedores, suas 
operações, suas despesas e lucratividade são a base para construir um 
Data Warehouse (armazém de dados). Este 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. 
Observe que não há uma referência a 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, neste 
contexto, dize-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, é referencido assim, como uma área de 
stage, uma área estacionária para armazenar somente aqueles dados 
que serão utilizados para análises. E o que se armazena é uma cópia 
dos dados necessários para as análises, preservavndo os dados originais 
guardados no banco transacional. 
O conceito de DW mudou também o contexto de banco de dados, 
separando os bancos de dados 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, que no início dos registros de dados não havia a experiência que 
pudesse prever arranjos diferentes para suportar análises. O objetivo 
de arquiteturas básicas para banco de dados eram 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. Os dados 
resumidos, agregados, sumarizados ou calculados são os dados 
derivados. 
37 
 
Essa divisão, dados brutos e informacionais/analíticos, proposta 
por Inmon (2005) justifica a 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 
Os dados que suportam as demandas 
operacionais, são fisicamente 
distintos, não servindo para atender 
as necessidades informacionais ou 
analíticas. 
Fonte: blackred/iStock.com. 
A tecnologia para o processamento operacional é tecnicamente 
diferente da tecnologia necessária em suportar informações 
ou análises. 
Os usuários de dados operacionais são 
diferentes para usuários que consomem 
dados informativos ou analíticos. 
Fonte: a-image/iStock.com. 
O processamento de dados operacionais tem características diferentes 
de processamento analítico ou informacional. 
Fonte: adaptado de Inmon (2005). 
38 
https://www.istockphoto.com/br/portfolio/blackred?mediatype=photography
https://www.istockphoto.com/br/portfolio/a-image?mediatype=photography
 
 
As justificativas levam em consideração a finalidade de uso dos dados. A 
base de dados bruta é consistente, original e necessita ser preservada. 
Desta, 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 usuários que 
controlam ou realizam as operações diárias. 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 de uma base de dados operacionais 
de uma base de dados 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, proposto por Inmon (2005, p. 16) destaca as diferenças, entre 
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. 
Explorando o exemplo da Figura 6, em que uma empresa fabricante de 
produtos alimentícios tem 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. Depedendo de como o relatório é extraído pela matriz, 
discrepâncias podem ocorrer, tais como relatórios 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 também, ambos referentes ao 
produto 2. Obviamente, os relatórios não vão coincidir, porque a forma 
de extração dos dados coletados levando em consideração o período 
são diferentes – 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 
 
 
 
 
 
 
 
 
 
 
Filial 1 
Filial 2 
Filial 3 
§ 
ó□' 
VENDA VENDA VENDA 
PRODUTO 1 PRODUTO 2 PRODUTO 3 
PRODUTO 5 VENDA 
PRODUTO4 
PRODUTO 2 
§ 
/□' D □VENDA 
VENDA VENDA PRODUTOS 
PRODUTO 3 PRODUTO 2 
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. 
Suponha que os produtos alimentícios sejam os seguintes: produto 1 
(feijão), produto 2 (arroz), produto 3 (macarrão), produto 4 (farinha), 
produto 5 (tempero). A linha tracejada em vermelho e amarelo 
representam a perspectiva de extração de diferentes maneiras em 
relação ao produto 2. A diferença consiste da necessidade de extração 
de venda do produto 2 da filial 3, e 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 de arroz e a matriz 
analisa as vendas de arroz, produto 2, de todas as filiais. Se o acesso 
a 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. 
Este cenário pode remeter a análises distintas, sendo que 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 
40 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
contrário da matriz que poderá questionar alguma tomada de decisão 
da filial 3, em função das análises diárias. 
Para que as divergências nas análises não ocorram, é recomendável 
que na construção de um DW, a sua arquitetura deva preconizar 
referências analíticas comuns, como desempenho comparativo entre 
as filiais, ranking de vendas de produtos, os produtos com maior 
rentabilidade, setorização das vendas, aumento da eficiência das 
vendas sem afetar as outras filiais, dentre outras análises. 
Em grande parte, os dados são estratificados empiricamente, sem 
que testes amostrais garantam que o comportamento é o mesmo em 
diferentes datasets. 
As análises de dados são implementadas para responder as 
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 o 
Gráfico 1. A análise de dados sem aplicações estratégicas, desde 
o acesso, a preparação, as decisões e as ações, gastam 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às análises e destas às 
decisões, consequentemente ações. 
O Gráfico 1 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, perguntas corretas do que se quer analisar, 
os dados necessários às repostas e às análises tem menor esforço 
de tempo gasto, deixando maior tempo para o desenvolvimento 
das decisões. 
41 
■ Ac= aos dados 
■ Anil li~ dos dados 
■ Desenvolvimento das 
dec-sôes 
Prepa- ação do cenàrio 
■ lmplemen a;ão das 
ações 
35 
30 
25 
20 
15 
10 
s 
o 1 1 
Sen apli:ações estratégicas Com apl icar;ões estratégieas 
Gráfico 1 – 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 análises demadam maior percentual de tempo, 
30%, resultando em pouco tempo para transformar essas análises em 
decisões, decorrendo daí, 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, em média 10% do 
tempo gasto 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 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. Estratégia de dados garante que os dados sejam 
consumidos como ativo dentro da organização. 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. 
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), 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. Por isso, Machado 
(2011) deixa claro que “DW é uma arquitetura e não uma tecnologia” 
(MACHADO, 2011, p. 25). 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. Isso significa realizar cópias da história da organização, 
pelos dois anos anteriores, recomenda Machado (2011). Porque o banco 
de dados de um DW não é o mesmo banco dos dados transacionais, 
fisicamente. 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, 
indicadores de performance da organização. Uma base histórica 
auxilia na criação de comparações com dados atuais e tendências 
43 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
TPS 
r------ ------------., 
GESTÃO 
ESTRATÉGICA 
GESTÃO TÁTICA 
GESTÃO DAS OPERAÇÕES 
STAFF OPERACIONAL 
1 
_J 
futuras. A construção prevê também a utilização de ferramentas de 
EIS e DSS. Essas ferramentas são utilizadas em diferentes níveis de 
gestão das organizações, de acordo com Turban (2005). A Figura 7 
representa o modelo de Turban (2005) e os sistemas de informação 
relacionados a cada nível organizacional. 
Figura 7 – 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 proecessa os sistemas transacionais 
(TPS), o gerenciamento de operações acessa os SIG (Sistema de 
Informação Gerencial, MIS em inglês), a gestão tática acessa o DSS 
(Sistemas de Suporte a Decisão) para apoio as decisões, e por último a 
gestão estratégica acessa o EIS (Sistemas Especialistas). 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, são 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. Isto 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, constituidos 
de repositórios de Data Marts (DM). Vários DM compõem o DW. 
Data Mart 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 Data Marts podem ser reconhecidos 
como uma versão reduzida de um DW, facilitando a implementação 
de alanytics departamental. O Data Mart é representado como um 
pequeno Data Warehouse 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 
Data Mart em relação aos seus dados e 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, por meio de 
sumarizações, agrupamentos filtragem e preparação de dados. 
Sob um ponto de vista físico o Data Warehouse é um banco descendente 
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, estas 
são características do banco transacional. 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ída na 
coluna de uma tabela. 
47 
 
 
O DW tem uma composição que separa a carga de trabalho para análise 
da carga de trabalho para transações. No 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 a DW. Por exemplo: uma empresa 
no 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 é que a ETL é 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 serem carregados pela ETL 
• OLAP: Online Analytical Processing – Processamento analítico em 
tempo real. Como exemplo, uma análise que está sendo feita por 
ano, na dimensão temporal, na qual 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, diário e trimestre conforme sua 
interação. É interação por meio de filtros na dimensão tempo. 
Um DW possui um conjunto carcaterístico personalizado, distintamente 
dos ambientes convencionais das organizações. Por este motivo, não há 
como replicar um DW de uma empresa para outra. 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, o DW deverá possuir um rol de 
atribuições para cumprir a sua finalidade, elencadas a seguir, 
no Quadro 1. 
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 antes do DW. Isto significa que estes 
dados provenientes de atualizaçãoes em outras fontes são extraídos, 
49 
uj,€,Y~ ___ ,,,, 
fRP---77 ETL 
transformados e depois carregados para o DW. Em geral ficam em uma 
área chamada stage, um banco estacionário, de espera da carga. 
Para ilustrar a compreensão, a Figura 8 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, 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), 
mineração de dados (Data Mining) e visualização de relatórios (reporting). 
Figura 8 – Fluxo de dados de um DW 
Fonte: vaeenma/iStock.com. 
50 
https://vaeenma/iStock.com
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
O DW da Figura 8 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, e o 
DW é orientado por assunto, seu armazenamento é, na realidade, 
uma transformação dos dados operacionais, 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 estas 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 um conjunto de dados, a média, 
mediana, moda, quartis, valores máximo e mínimo. Um filtro pode 
associar lógicas como “e”, “ou”, “=”, entre outras lógicas 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, de certa forma, contribuem 
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 é aquele que 
interfere nos resultados das análises e o filtro como extratificador no 
ETL. O primeiro como filtro refere-se a 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, leitura do banco de dados do DW. No segundo caso, um 
filtro como extratificador, na ETL, significa a disponibilização de parte 
dos dados, uma amostra, um extrato dos dados que serão carregados 
para o banco do DW. A Figura 9, mostra o fluxo dos dados, na entrada e 
51 
 
Sexo "m" 
Sexo "f' 
DATA SOURCE 1 
Sexo "masc" 
Sexo "fem" 
DATA SOURCE 2 
Sexo "M" r--.-111' 
Sexo "F" 
DATA SOURCE 3 
ETL 
EXTRAÇÃO 
FILTRO 
RELATÓRIOS 
--60 
65 
RELATÓRIOS FILTRO 
m:mmm 
M 81 
saída do DW, assim como o filtro na ETL como extrator e o filtro no cubo 
para análises. 
Figura 9 – 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 à tomada de decisões. Essa construção vem da necessidade 
gerada por esse grupo em um contexto norteado pelas competências 
daquele tipo de negócio. 
A entrada e saída do DW requer 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 doprojeto 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, dos negócios, 
que tipo de produto ou serviço está em um ciclo de lucro e de queda. 
Quanto tempo o cilco positivo desses produtos ou serviços duram? 
Perguntas são feitas por essas pessoas e precisam amparar suas 
respostas na relevância dos dados de sua empresa. 
De uma maneira ampla, a composição de um DW inclui os dados 
estruturados, formas de comunicação dos dados em diferentes pontos 
de armazenamento, 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 gere 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, o 
alto escalão, de maneira a estarem alinhados com o projeto, bem como 
com a preparação da implantação, a manutenção e atualização, e o uso 
estratégico efetivo do DW dentro da corporação. Vale refletir em 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 as 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. 
A Fisiampla 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 recomendar 
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 Fisioampla 
tenha ideia de como os seus dados serão utilizados. 
54 
 
 
 
 
 
 
 
 
Também 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 a dimensão tempo, como 
exemplo: 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 que 
poderiam ser de interesse da Fisioampla associadas com a 
dimensões tempo. 
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 utilizados, 
compartilhados e manejados de forma fácil e eficiente? 
a. As consultas ao banco de dados. 
55 
 
 
 
 
 
 
 
 
 
 
 
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 Data Warehouse. 
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 
MACHADO, F. N. R. Tecnologia e Projeto de Data Warehouse. 5. ed. São Paulo, 
Editora Érica, 2011. 
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. 
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 
os dados operacionais e os dados analíticos. Essa diferença é 
decorrente na evolução de sistema de suporte a decisão e a 
56 
 
 
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. Estratégia de dados garante 
que os dados 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), 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), 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. Por isso, Machado (2010) deixa claro que “DW é 
uma arquitetura e não uma tecnologia”. A tecnologia sim ajuda a 
construir, operar e monitorar um projeto DW implantado. 
57 
 
 
 
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. 
 
.. 
e 
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 Warehouses (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. Ela apresenta 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 usados 
principalmente