Leitura Fundamental

WBA0748_v1.
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/
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...............................................................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
3
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.
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 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.
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.
6
Os dados podem estar localizados no mesmo computador que o
programa ou em outro computador em algum lugar da rede. O conjunto
de dados provenientes de diversas fontes deve ser modelado em
uma certa estrutura para que possa ser armazenado, manipulado e
recuperado. A necessidade de estruturar esse conjunto em um modelo
de dados serve para explicar suas características de funcionamento e
comportamento.
1.1 Modelo de dados
As fontes de dados são armazenadas segundo um modelo de banco de

dados, organizados em uma estrutura lógica de um banco de dados,
incluindo os relacionamentos, os tipos de dados e as restrições que
determinam como eles podem ser armazenados e acessados. Os tipos
de modelos de dados estão associados à tipologia, estando os mais
comuns listados a seguir:
• Modelo de banco de dados hierárquico.
• Modelo relacional.
• Modelo de rede.
• Modelo de banco de dados orientado a objetos.
• Modelo de relacionamento entre entidades.
• Modelo de BD NoSQL.
Cada modelo de banco de dados é tratado de forma personalizada e

é projetado com base em regras e conceitos que são adotados pelos
projetistas. A maioria dos modelos de dados pode ser representada por
um diagrama de banco de dados a ele associado (Figura 1).
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 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
8
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
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.
9
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
10
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).
11
Figura 4 – Modelo de rede em banco de dados
Vendedor
Empregado Cliente Produto
Transacoes_Vendas
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.
12
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 Tbl_categoria
id_prodt (INT) id_categ (INT)

prodt_name (TEXT) nome_categ (TEXT)
prodt_qt (INT) prodt_qt (INT)
Id_categoria (INT) descricao categ (INT)
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).
13
Figura 6 – Modelo Estrela
Dimensão 1
Dimensão 3 Fato Dimensão 2
Dimensão 4 Dimensão 5
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
14
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).
15
É 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,
16
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.
17
Quadro 1 – Propriedades ACID – Banco de Dados Transacional
Propriedades Descrição
Se mesmo uma parte da transação falhar, toda a
transação falhará. Dessa forma, todas as transações
Atomicidade
devem ser 100% bem-sucedidas para serem
confirmadas com êxito no banco de dados.
Uma transação é gravada no banco de
Consistência dados (trazendo-o de um estado válido para
outro) ou a transação é revertida.
As transações que ainda não foram
Isolamento concluídas não podem ser processadas/
modificadas por outras transações.
Depois que uma transação é gravada no banco
Durabilidade 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
18
Consistência Coerência forte, garantia de ACID
Integridade Alta integridade
Usa transações SIM
Atualizável SIM
Escalável SIM
Carga de trabalho Gravações intensas, leituras moderadas
Indexação Índices primários e secundários
Tamanho do dado De pequeno a médio
Modelo Relacional
Flexibilidade de consulta Altamente flexível
Escalabilidade Pequeno (MBs) a grande (alguns TBs) (*)
(*) MBs – MegaBytes; TBs – TeraBytes.
Fonte: adaptado de Kimball (2002).
3. Banco de dados analítico
Um banco de dados analítico é um sistema somente de leitura que

armazena dados para históricos ou métricas de negócios, como o
desempenho de vendas e a projeção de níveis de estoque. Os analistas
da área de negócios, executivos corporativos e outros funcionários
podem consumir consultas e analisar relatórios provenientes de um
banco de dados analítico. Os conjuntos das informações, por sua vez,
são atualizados regularmente, à medida que os dados de transações
recentes são incorporados ao banco de dados analítico.
O projeto de um banco de dados analítico permite suportar aplicações

tanto de Business Intelligence (BI), métricas analíticas e Big Data, em geral,
como de um Data Warehouse ou Data Mart.
O banco de dados analítico é diferente dos banco de dados operacional,

transacional ou OLTP, sendo o primeiro usado para análises e o segundo
para processar as transações. Embora os bancos transacionais possam
ser usados para suportar o armazenamento de dados e as aplicações de
BI, não são recomendados por questões de integridade e escalabilidade.
O banco convencional deve ser preservado, e o banco analítico deve
estar em outro schema.
19
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.
20
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
21
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
22
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 Processa grandes
de dados para a volumes de transações
análise de negócios. em tempo real.
Objetivo da otimização Insere rapidamente e Inserções, atualizações,
seleciona um grande seleções e exclusões em
número de linhas. tempo real em menos linhas.
Consultas Especializadas e Amplas e genéricas.
personalizadas.
Consulta de tempos Segundos para uma Milissegundos para uma
de resposta consulta analítica. consulta transacional.
Bancos de dados Vertica, Redshift, Greenplum, MySQL, PostgreSQL,
de exemplo Teradata, ParAccel. Microsoft SQL Server.
Fonte: elaborado pela autora.
23
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.
24
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-
25
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.
26
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.
27
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.
28
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 Processa grandes
volumes de dados para volumes de transações
análise de negócios. em tempo real.
Objetivo da otimização Insere rapidamente e Inserções, atualizações,
seleciona um grande seleções e exclusões
número de linhas. em tempo real em
menos linhas.
Consultas Especializadas e Amplas e genéricas.
personalizadas.
Consulta de tempos Segundos para uma Milissegundos para uma
de resposta consulta analítica. consulta transacional.
Bancos de dados Vertica, Redshift, MySQL, PostgreSQL,
de exemplo Greenplum, Microsoft SQL Server.
Teradata, ParAccel.
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
29
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.
30
Conceitos básicos sobre
Data Warehouse
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.
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.
32
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.
33
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 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.
34
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.
35
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,
36
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
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).
37
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.
38
Figura 6 – Modelo de extração de venda do produto 2 por duas
perspectivas distintas em relação ao período
Matriz
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.
39
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.
40
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
41
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
42
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.
43
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:
44
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.
45
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
46
primeiro caso, permite a consolidação de diferentes fontes nessa carga
de trabalho analítica.
Além de ferramentas analytics e demais aplicações para o

gerenciamento da coleta de dados e da entrega dos resultados prontos
para serem consumidos, a composição do DW inclui:
• ETL - Extract Tranform Load : extração, transformação e

carregamento dos dados para o DW. Por exemplo: uma empresa
do ramo alimentício tem seus dados armazenados no banco de
dados transacionais, e a ferramenta de ETL irá carregar somente
os dados de interesse para análises para o banco de dados
repositório do DW. Outro exemplo é a ETL ser feita somente com
as vendas diárias dos produtos alimentícios, mas, se houver a
necessidade de uma análise por hora, os dados dos horários das
vendas deverão ser carregados pela ETL.
• OLAP - Online Analytical Processing : processamento analítico em
tempo real. Por exemplo, uma análise está sendo feita por ano, na
dimensão temporal, mas o usuário precisar mudar para uma visão
por trimestre ou diária. A ferramenta OLAP tem que possibilitar
essa granularidade da dimensão tempo para que o usuário tenha
as visões por ano, por dia e por trimestre, conforme sua interação.
A interação acontece por meio de filtros na dimensão tempo.
Um DW possui um conjunto característico personalizado, distintamente

dos ambientes convencionais das organizações. Por esse motivo, não
há como replicar um DW de uma empresa para outra. Assim, cada
projeto de DW é único, não na essência, mas no seu modo de operação
e aplicação. Ao final do desenho do projeto, ele deverá apresentar um
rol de atribuições, elencadas a seguir no Quadro 1, para cumprir a sua
finalidade.
47
Quadro 1 – Atribuições de um DW
Atribuição Caracterização Exemplo
a) Extração dos dados. Fontes diversas (internas e Data completa,
externas). produtos, preço.
b) Transformação Necessidade de mesclagem Normalização da data,
dos dados. ou combinação de dados, valores maiores que zero.
gerando novos dados
específicos.
c) Infraestrutura Específica para essa Servidores de serviços.
tecnológica e manutenção. finalidade.
d) Representação Visualizações gráficas, Gráfico percentual de
dos dados. tabuladas, sumarizadas desepenho de vendas.
pronta para consumo
conforme perfil
dos usuários.
e) Especialização. Dados podem ser extraídos Inclusão de filtros nas visões
ou não para níveis mais
específicos, os Data Marts, e
destes para bases de dados
individualizadas.
f) Acesso. Personalizado por meio de Usuários com níveis de
ferramentas que promovem acesso as visões.
acessos com diferentes
níveis de apresentação.
g) Não há atualização. As atualizações ou As atualizações de dados
updates não ocorrem ocorrem no banco
diretamente no DW. 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
48
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.
49
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.
50
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.
51
Quadro 2 – Características da visão macro de um projeto DW
Características Detalhamento
Orientação • Agrupamento por assuntos de interesse.
por assunto. • 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 • BI.
competências.
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.
52
Fazendo um fechamento, vale reforçar que o DW auxilia a empresa a

entender o desempenho dos negócios a partir do conhecimento sobre
os seus dados. Para isso, não basta disponibilizá-lo a quem decide, é
preciso que se crie um contínuo fluxo de entrada e saída de dados e
que se gere um valor para quem os consume dentro da empresa. As
considerações apresentadas mostram a necessidade da participação
de várias entidades da organização, como a área de TI, a área de
banco de dados, os gestores de departamentos, os funcionários do
operacional e o alto escalão, de maneira a estarem alinhados com
o projeto. Também são necessários a preparação da implantação, a
manutenção e a atualização e o uso estratégico efetivo do DW dentro
da corporação. Vale refletir sobre como criar um fluxo contínuo dentro
da organização, desde a origem dos dados até as análises oferecidas
aos analistas, para que o projeto de DW se torne indispensável às ações
estratégicas internas.
TEORIA EM PRÁTICA
A empresa Fisioampla é especailizada em serviços de saúde
de fisioterapia e possui filiais em diversos locais do País. Ela
tem cadastrados cerca de 1.200.000 clientes que utilizam
os serviços especilizados de fisioterapia na matriz e em 30
filiais. Além dos serviços, presta consultas especilizadas
para reabilitação de acidentados, pessoas com mobilidade
reduzida e idosos. Cada clínica possui um amplo sistema de
reabilitação e atendimento com fisioterapeutas associados.
Há consultas clínicas que, além de recomendarem as
sessões de fisiterapia, recomendam o uso de produtos que
vão auxiliar na reabilitação ou na redução dos problemas
relacionados.
Para extrair valor dos seus dados, a Fisioampla contratou
você para estruturar um projeto de DW. Analise o
cenário e proponha uma arquitetura para que a empresa
53
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.
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?
54
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.
Publishing, 2005.
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
55
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.
56
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.
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
58
modificações durante o seu acesso. Apenas novas cargas com dados
atuais são inseridas, a partir de critérios previamente estabelecidos,
permitindo, assim, o seu acesso por meio de ferramentas front-end e/ou
aplicativos.
Na concepção de Inmon (1997), o DW é um agrupamento de dados

que deve ser guiado por temas normalizados (integrados) para
facilitar as consultas analíticas. É necessário também possuir níveis de
granularidade e de armazenamento bem apurados. Além disso, em
nenhuma hipótese, devem ser modificados (não-voláteis), pois esses
dados são uma “fotografia” (snapshot) de determinada situação em um
período específico.
Esse procedimento certifica ao DW uma particularidade em sua

utilização, tornando-o um ambiente com dois propósitos específicos
distintos, o de carga de dados e o de acesso aos usuários. Dessa forma,
para que um ambiente de DW seja consistente e eficaz, os dados
precisam ser padronizados e consolidados para só depois serem
disponibilizados no sistema, de modo que os administradores possam
utilizá-los como ferramenta de apoio no processo decisório.
O DW organizacional pode manter um armazém central de dados

da organização inteira ou pode manter armazéns menores,
descentralizados, denominados Data Marts. Portanto, muitas empresas
iniciam o desenvolvimento de DW estruturando-o em conjuntos
de dados orientados por assunto ou categoria, para atenderem às
necessidades de pequenos grupos de usuários ou de níveis funcionais
da empresa, investindo, assim, na implementação de Data Marts.
Segundo Date (2004), os DW surgiram pela necessidade de fornecer

uma origem de dados única, limpa e consistente para fins de apoio à
decisão e pela necessidade de fazê-lo sem causar impacto sobre os
sistemas operacionais que normalmente têm exigências restritas de
desempenho com cargas de trabalho previsíveis. Porém, percebeu-se
59
que os usuários executavam extensivas operações de análise de dados
sobre um subconjunto do DW completo, repetindo com frequência as
mesmas operações sobre o mesmo subconjunto de dados. Dessa forma,
a ideia de construir um espaço de armazenamento limitado, adaptado
à finalidade imediata, extraindo e preparando os dados exigidos
diretamente de fontes locais, assim como fornecendo acesso mais
rápido aos dados, levou ao conceito de Data Marts.
Date (2004) descreve o Data Mart como “um depósito de dados

especializado, orientado por assunto, integrado, volátil e variável no
tempo, que fornece apoio a um subconjunto específico de decisões da
gerência” (DATE, 2004, p. 604). Por especializado, entende-se que ele
contém dados para apoio a uma área específica de análise comercial
e, por volátil, entende-se que os usuários podem atualizar os dados e
talvez até mesmo criar novos dados para algum propósito.
Na concepção de Rob e Coronel (2011), um Data Mart é um pequeno

subconjunto de um DW, sobre um único assunto, que fornece suporte às
decisões de um pequeno grupo de pessoas, podendo ser criado a partir
de dados extraídos de um DW maior, com o objetivo específico de dar
suporte a acessos mais rápido para determinado grupo ou função, como
ilustra a Figura 2, a qual conta com o DW Organizacional composto por
três Data Marts: marketing, vendas e financeiro.
Rob e Coronel (2011) enfatizam que:
A única diferença entre um Data Mart e um Data Warehouse é o tamanho

e o escopo do problema a ser resolvido. Portanto, as definições de
problemas e as exigências de dados são essencialmente a elas para
ambos. (ROB; CORONEL, 2011, p. 551)
De acordo com Laudon e Laudon (2014), um Data Mart é:
60
Um subconjunto de um Data Warehouse, no qual uma porção resumida ou
altamente focalizada dos dados da organização é colocada em um banco
separado destinado a uma população específica de usuários (LAUDON;
LAUDON, 2014, p. 194)
Assim como na visão de Machado (2013), os Data Marts representam

um subconjunto dos DW que permitem o acesso descentralizado à
informação, podendo ser direcionados a um departamento ou a uma
área específica do negócio.
Figura 2 – Ambiente básico de Data Warehouse
Rainer e Cegielski (2011) destacam que um “Data Mart é um data

warehouse pequeno, projetado para as necessidades do usuário
final em uma unidade estratégica de negócios ou um departamento”
(RAINER; CEGIELSKI, 2011, p. 126). Já Kimball et al. (1998), especialista no
assunto, define que um Data Mart, também conhecido como Warehouse
Departamental, é uma abordagem descentralizada do conceito de DW,
caracterizando os seus principais benefícios como:
a. Demandam menos investimento porque são mais baratos.

b. Podem ser implementados mais rapidamente.
61
c. Apoiam as necessidades e o controle local de grupos de usuários
por níveis funcionais.
d. Fornecem uma resposta mais rápida aos grupos de usuários.
e. Disponibilizam consultas mais fáceis de serem analisadas e
navegadas.
Machado (2013) afirma que uma das principais vantagens de se

implantar um Data Mart em uma empresa é a possibilidade de
retorno rápido, garantindo um maior envolvimento do usuário final,
capaz de avaliar os benefícios extraídos de seu investimento.
A partir das definições apresentadas, conclui-se que um Data Mart é

um subconjunto lógico e físico da área de representação de um DW
que agrupa dados sobre um único assunto para fornecer suporte
às decisões de um grupo de pessoas específicas. Contudo, algumas
empresas optam por implementarem primeiramente o Data Marts
para a posterior migração para um DW, considerando que pessoas
em níveis organizacionais e funcionais diferentes necessitam de
dados com formatos distintos de agregação, síntese e apresentação,
além de menor investimento.
2. Arquitetura de Data Warehouses e Data Marts
O funcionamento de uma arquitetura padrão de DW consiste na

integração das diversas fontes de dados com o ambiente de extração
e transformação, com a base de dados do DW, mecanismos de
comunicação, processamento e com ambientes intuitivos para os
usuários, a partir de ferramentas de consultas dinâmicas com interfaces
de apresentação das informações interativas.
O processo de extração dos dados obtidos de diversas fontes de dados

operacionais, transformação e carga em DW normalmente prevê um
62
estágio intermediário de preparação, sincronização e integração dos
dados. Ferramentas de Extraction, Transformation and Load (ETL) são
responsáveis pela extração, transformação e carregamento dos dados
no DW. Durante esse estágio, eles permanecem em uma área de
armazenamento intermediária entre as bases de dados operacionais
e o DW para realização das ações de limpeza e integração dos dados.
Essa área de armazenamento intermediária é conhecida como Staging
Area, Data Staging ou Operational Data Store (ODS – Depósito de Dados
Operacionais).
Inmon (1997) explica que um depósito de dados operacional é uma

coleção de dados orientada por assunto, integrada, volátil (atualizável),
atual ou quase atual. O objetivo principal do Staging Area é criar um
ambiente intermediário de armazenamento e processamento dos
dados para o processo ETL, possibilitando o tratamento dos dados
para permitir sua posterior integração em formato e tempo, o que evita
problemas após a criação do DW e a concorrência com o ambiente
transacional no que diz respeito ao consumo de recursos. A Figura 3
representa o processo de ETL com o Staging Area.
No lado esquerdo da figura, estão as fontes de dados, que são

compostas respectivamente por sistemas Online Transaction Processing
(OLTP), dados externos, outras fontes e arquivos simples (flat files).
No centro da figura, está a Staging Area e no lado direito está o DW. A
extração é a fase em que os dados dos sistemas são transportados de
diferentes fontes para uma base de dados para serem transformados.
A transformação é a etapa em que são tratados, corrigindo erros de
integridade, de redundância, de digitação etc. e integrando-os em um
modelo único para ser utilizado no DW. A carga é a fase em que os
dados são levados da Staging Area para um ou mais Data Marts, para
então serem consultados por meio das aplicações dos usuários.
63
Figura 3 – Processo de ETL com Staging Area
PARA SABER MAIS

Online Transaction Processing (OLTP – Processamento
de Transações em Tempo Real): os sistemas OLTP são
transacionais e registram todas as transações operacionais
das organizações. São utilizados no processamento dos
dados que são gerados diariamente por meio dos sistemas
informacionais das empresas.
ASSIMILE
O ambiente de processamento de dados analíticos difere
do ambiente de dados transacionais ou operacionais.
Os sistemas OLTP servem como fonte de dados para o
ambiente de DW, enquanto as ferramentas Online Analytical
Processing (OLAP – Processamento Analítico On-line)
64
auxiliam na análise dinâmica e multidimensional de dados
consolidados, permitindo que o usuário final tenha uma
visão completa das informações analiticamente.
Machado (2013) descreve que uma Staging Area permite ao

administrador do DW extrair os dados no momento em que estão
disponíveis, para, posteriormente, integrá-los, facilitando as extrações
dos sistemas operacionais durante períodos fora do pico de operações.
Um ODS pode ser usado também como área provisória para
reorganização física dos dados operacionais extraídos de várias fontes,
como dos sistemas legados da empresa e de demais sistemas e serviços
da internet, em um único formato que será mantido no DW.
Segundo Kimball et al. (1998), além da Staging Area, o ideal é que exista
uma segunda área intermediária, o ODS, antes da carga definitiva
para o DW. Um ODS deve ser uma base de dados obtida da extração,
transformação e limpeza de dados dos sistemas fontes operacionais da
empresa. Com um ODS, não é necessário refazer toda a extração para
corrigir eventuais problemas na transferência dos dados para o DW.
Para Machado (2013), o ODS não é um componente indispensável

em um DW, sendo sua criação uma decisão de projeto. Contudo, por
economia de espaço de armazenamento em disco, muitos DW são
implementados sem ODS.
Muitos projetos de DW possuem ODS e utilizam essa área para fazerem

validações de regras de negócio, enquanto na Staging Area ocorre a
limpeza, verificando chaves repetidas e problemas de integridade
referencial. A Figura 4 ilustra a arquitetura de um DW com Staging Area e
Data Marts.
65
Figura 4 – Arquitetura de um Data Warehouse
com uma Staging Area e Data Marts
No lado esquerdo da figura, estão as fontes de dados, que, nesse

exemplo, são compostas pelos sistemas operacionais e flat files
(arquivos simples). Um pouco mais à direita, está a Staging Area.
No centro da figura está o DW, que é composto pelos metadados,
dados resumidos e dados brutos, ou seja, os dados obtidos com
seus valores de origem e que são armazenados sem sofrerem
nenhum tratamento. Um pouco mais à direita, estão os Data Marts
categorizados em marketing, vendas e financeiro. Por fim, no lado
direito da figura, estão as ferramentas de apoio à decisão – Analysis
Reporting, OLAP e Data Mining.
De acordo com a figura, os dados são extraídos das fontes de

dados e transportados para a Staging Area, na qual os dados
são transformados. Após o processo de transformação, eles são
carregados no DW. Em seguida, são extraídos do DW e carregados
66
nos Data Marts para uso posterior, e, quando necessário, os usuários
acessam os Data Marts utilizando ferramentas de apoio à decisão.
Em certos casos, um projeto começa com o desenvolvimento de um

DW e se compõe em vários Data Marts. No entanto, um Data Mart
pode também ser criado de modo independente, sem a necessidade
de extrair os dados do DW. Algumas empresas utilizam essa técnica,
criando primeiro os Data Marts conforme a necessidade e depois o
Data Warehouse, como uma consolidação dos diversos Data Marts
(DATE, 2004).
3. Tipos de arquitetura e implementação
A escolha da arquitetura é uma decisão que causa impactos quanto

ao sucesso do projeto, podendo afetar no tempo de execução, no
retorno do investimento, na velocidade dos benefícios da utilização
das informações, na satisfação do usuário e nos recursos necessários à
implementação de uma arquitetura.
Para a definição de uma arquitetura de DW ou de Data Marts, deve-

se levar em conta, principalmente, o porte da empresa, a qualificação
e a experiência dos profissionais de tecnologia da informação e
comunicação e os recursos disponibilizados para o investimento.
Contudo, a arquitetura pode ser definida ou modificada após o começo
da implementação. Nesse caso, depois que o projeto de DW é iniciado,
para mudar a sua arquitetura, será despendido um longo tempo,
atrapalhando o andamento do projeto. Por isso, é importante ela já
estar definida no início do projeto.
A arquitetura de um DW abrange um conjunto de ferramentas que

envolve a carga inicial dos dados até a geração de consultas que
67
apoiam os usuários no processo de tomada de decisão. Alguns fatores
interferem na escolha da arquitetura e implementação, tais como:
a. Tempo para execução do projeto.

b. Estrutura das instalações físicas da empresa.
c. Rápido retorno do investimento.
d. Satisfação dos usuários estratégicos.
A definição de uma arquitetura determina o local em que o DW ou os

Data Marts estarão alocados fisicamente. Machado (2013) apresenta
a seguinte classificação das arquiteturas: global, independente e
integrada, podendo o tipo de implementação ser top down, bottom up e a
combinada.
A arquitetura global é considerada a que mais comporta as necessidades

de um DW integrado com alto nível de acessos e utilização das
informações para todos os departamentos de uma empresa, podendo
ser fisicamente centralizada ou fisicamente distribuída nas instalações
da empresa. Normalmente, o DW é global, ou seja, reflete o escopo
de acessos em um repositório comum de dados com a geração
das informações para o suporte à decisão, disponível para toda a
empresa. Nesse tipo de arquitetura, consome-se muito tempo de
desenvolvimento e administração, e seu custo de implementação é
muito alto. (MACHADO, 2013).
A Figura 5 ilustra os dois caminhos de utilização de uma arquitetura

global, a global centralizada e a global distribuída, podendo em ambas
o acesso aos dados ser realizado de locais fisicamente separados.
Mesmo assim, todas as estruturas têm acesso a todas as informações
da empresa. O topo da Figura 5 ilustra que o DW está distribuído em
três instalações físicas de uma empresa e, na parte inferior, mostra que
o DW está mantido em uma única instalação física da empresa, ou seja,
centralizado, considerando que a empresa existe em um único local.
68
Figura 5 – Arquitetura global do tipo centralizada e distribuída
Fonte: adapatada de Machado (2013).
A arquitetura independente mantém Data Marts stand-alone, em

que há dados específicos da necessidade da empresa, considerando
que cada departamento tem sua informação sem a integração com
outros departamentos. Contudo, há restrição quanto a um mínimo de
integração organizacional e não permite nenhuma visão global. Esse
tipo de arquitetura é controlado por um grupo específico de usuários,
atendendo às necessidades específicas. Sua implementação é rápida e
de poucos impactos nos recursos de tecnologia da informação, sendo,
assim, a arquitetura mais adotada pelas empresas.
A Figura 6 exemplifica a arquitetura do tipo independente, na

qual cada estrutura ou departamento pode ter suas informações
específicas, categorizando-as em Data Marts separados, não se tendo a
obrigatoriedade de essas informações serem integradas.
69
A arquitetura integrada de Data Marts é implementada por Data Marts
separadamente em grupos específicos ou departamentos, os quais são
integrados ou interconectados, provendo uma visão organizacional
maior dos dados e das informações (MACHADO, 2013).
Figura 6 – Arquitetura independente de Data Marts
A arquitetura integrada requer mais complexidade no projeto de

especificação dos requisitos dos Data Marts, devido à proposta de
integração dos dados e das informações, aumentando a capacidade e
a qualidade de visão corporativa das informações. Uma vantagem da
arquitetura integrada é que os usuários de um departamento podem
acessar e utilizar os dados de um Data Mart de outro departamento. A
Figura 7 ilustra uma arquitetura integrada, em que cada departamento
tem suas informações específicas, mas suas informações são integradas
com os outros departamentos, a partir da integração de dois ou mais
Data Marts.
70
Figura 7 – Arquitetura integrada de Data Marts
As abordagens de implementação de Data Marts são classificadas em top

down, bottom up e a combinada.
A implementação do tipo top down é conhecida como a proposta

mais adotada e recomendada de implementação de Data Marts para
um ambiente de DW. Exige-se inicialmente o envolvimento de todos
os departamentos da empresa para planejamento completo sobre
as fontes de dados que serão utilizadas; a análise e o projeto dos
requisitos e das estruturas de dados; a especificação da qualidade dos
dados a serem considerados; a definição da padronização dos dados; a
recuperação dos modelos de dados dos sistemas transacionais vigentes;
o projeto de segurança; e as definições das tecnologias que serão
adotadas para o desenvolvimento do DW.
Esse tipo de implementação força a empresa a definir regras de

negócios de forma corporativa antes de iniciar o projeto de DW. O
processo inicia-se com a extração, a transformação e a integração dos
71
dados dos sistemas operativos e dos dados externos para a Staging Area
e/ou para um ODS, para, posteriormente, serem transferidos para o DW.
A partir do DW, são extraídos os dados e metadados para os Data Marts
(MACHADO, 2013).
A Figura 8 ilustra a implementação do tipo top down, com a extração de

dados de sistemas transacionais, fontes externas, sistemas legados e
arquivos simples, nos quais essas informações passam por um processo
de extração e transformação, iniciando na Staging Area e no ODS até
o desenvolvimento dos Data Marts, a partir do DW, para posterior
disponibilização das informações, a partir de diferentes ferramentas de
apoio à decisão – Analysis Reporting, OLAP e Data Mining.
Figura 8 – Tipo de implementação Top Down
O Quadro 1 elenca as vantagens e desvantagens da implementação top

down, segundo Machado (2013).
72
Quadro 1 – Vantagens e desvantagens da implementação Top Down
Vantagens
1. Herança de arquitetura: os Data Marts originados a partir de um DW utilizam a

mesma arquitetura e os mesmos dados, permitindo uma fácil manutenção.
2. Visão de empreendimento: o DW concentra o histórico de negócio da empresa,
permitindo a extração em níveis menores de informações.
3. Repositório de metadados centralizado e simples: o DW provê um repositório de
metadados central para o sistema, provendo manutenções mais simples.
4. Controle e centralização de regras: garante a existência de um único conjunto de
aplicações para extração, limpeza e integração dos dados, e de processos centra-
lizados de manutenção e monitoração.
Desvantagens
1. Implementações muito longas: os DW são normalmente desenvolvidos de modo

iterativo por áreas de assunto, sendo necessário uma média de 15 ou mais me-
ses para que a primeira área de assunto entre em produção.
2. Alta taxa de risco: dificuldade em garantir e sustentar o investimento neste tipo
de ambiente.
3. Heranças de cruzamentos funcionais: necessidade de equipes de desenvolvi-
mento e de usuários finais altamente qualificados que acompanhem as deman-
das vigentes e emergentes da organização.
4. Expectativas relacionadas ao ambiente: a demora do projeto e a falta de retorno
rápido podem induzir expectativas desagradáveis nos usuários.
Fonte: adaptado de Machado (2013).
A implementação do tipo bottom up permite a implementação

incremental do DW por meio do desenvolvimento de Data
Marts independentes. Ela vem se popularizando em virtude de
a implementação top down exigir alto investimento financeiro e
tecnológico. O processo começa na extração, transformação e
integração dos dados para um ou mais Data Marts, baseados em um
modelo dimensional. Esse tipo de implementação pode trazer um
grande problema de redundância de dados e inconsistências, devido ao
DW ser desenvolvido de forma incremental, mas poderá ser minimizado
por meio de planejamentos e boas práticas de projetos de software.
73
A Figura 9 exemplifica a implementação bottom up, a qual se inicia de
forma incremental em cada Data Mart para a posterior composição do
DW, formando, assim, uma estrutura de múltiplos Data Marts.
Figura 9 – Tipo de Implementação Bottom Up
O Quadro 2 elenca as vantagens e desvantagens da implementação

bottom up, segundo Machado (2013).
Quadro 2 – Vantagens e desvantagens

da implementação Bottom Up
Vantagens
1. Implementação rápida: o desenvolvimento dos Data Marts é direcionado por as-

sunto, permitindo um rápido desenvolvimento e, posteriormente, em produção.
2. Retorno rápido: a arquitetura baseada no desenvolvimento incremental de Data
Marts demonstra o seu valor e confiança para o usuário final.
3. Manutenção do enfoque da equipe: a elaboração de Data Marts incrementais
permite que os principais negócios sejam focados inicialmente, sem que haja
gastos no desenvolvimento de áreas que não são essenciais ao problema.
4. Herança incremental: a estratégia de desenvolvimento de Data Marts de forma
incremental porporciona confiança e expertise das equipes, minimizando os ris-
cos e problemas característicos de projetos de software.
74
Desvantagens
1. Perigo de legamarts: os Data Marts independentes transformam-se em Data Mar-

ts legados, ou legamarts que podem dificultar, quando não inviabilizam futuras
integrações, gerando problemas e não soluções.
2. Desafio de possuir a visão de empreendimento: dificuldade em manter um rí-
gido controle de negócio ao extrair e combinar as fontes individuais durante o
desenvolvimento de Data Marts incrementais.
3. Administrar e coordenar múltiplas equipes e iniciativas: dificuldade em manter
um rígido controle durante o processo de desenvolvimento de Data Marts em
paralelo, tentando coordenar os esforços e recursos das múltiplas equipes, es-
pecialmente nas áreas de regras e semântica empresariais.
Fonte: adaptado de Machado (2013).
A Figura 10 representa a implementação do tipo combinada, que tem o

propósito de integrar as arquiteturas top down e a bottom up. Segundo
Machado (2013), nessa abordagem, elabora-se a modelagem de dados
da visão macro do DW e, posteriormente, implementa-se os Data Marts.
A principal vantagem dessa abordagem é a garantia da consistência dos
dados obtida em virtude do modelo de dados único do DW, consistindo
no mapeamento e na implementação dos Data Marts.
Figura 10 – Tipo de implementação combinada
75
4. Considerações Finais
A busca por informações que amparassem o trabalho dos tomadores de

decisão passou a ser uma constante, pois percebeu-se que as empresas
guardavam um patrimônio digital em seus bancos de dados e que os
administradores poderiam aprimorar seus processos e usufruir desse
patrimônio digital. Ao transformar a informação em conhecimento, poder-
se-ia potencializar e agregar valor aos negócios.
Ao longo das décadas, identificou-se a necessidade de dividir as tarefas

de gerenciamento e análise dos dados em diferentes níveis gerenciais,
crescendo, assim, a necessidade de respostas mais rápidas, seguras,
confiáveis e que melhor se adaptassem às necessidades do gerenciamento
da empresa e dos negócios. A partir desse cenário, surgiram os ambientes
de DW organizacional, que geralmente mantêm um armazém central de
dados da organização inteira, ou armazéns menores, descentralizados,
denominados Data Marts. Assim, um Data Mart é um subconjunto de um
DW que agrupa dados sobre um único assunto para fornecer suporte às
decisões de um grupo de pessoas específicas.
TEORIA EM PRÁTICA
Vamos tomar como base uma das maiores redes de

farmácias e drogarias do segmento de varejo farmacêutico
nacional, com aproximadamente 550 lojas nos 25 estados
e Distrito Federal. Essa rede investiu R$ 35 milhoes em
novas lojas e reformas, incluindo a reestruturação da
arquitetura global do tipo distribuída do ambiente de Data
Warehouse e Data Marts da rede que está concentrada nas
regiões Sul e Sudeste do País. Assim, considerando que
a rede pretende aprimorar os serviço de atendimento
personalizado aos seus clientes, faça um levantamento e
escolha uma tecnologia emergente para integrar o novo
76
ambiente de Data Warehouse organizacional de serviços de
inteligência artificial que agregue inteligência ao negócio
e principalmente proporcione novas funcionaliades, a fim
de garantir a customização ágil aos clientes. A partir da
definição da tecnologia emergente de inteligência artificial,
elenque as principais etapas para o projeto da nova
arquitetura do Data Warehouse organizacional e relacione
algumas nos serviços que poderão ser disponibilizados aos
usuários estratégicos e/ou clientes.
1. Uma das principais características de um ambiente de

Data Warehouse é a interação dos dados de diversas
fontes distintas, proporcionando um ambiente estático,
que não sofre modificações. O Data Warehouse
organizacional pode manter um armazém central de
dados da organização inteira ou também menores,
descentralizados, denominados ____________________.
Assinale a alternativa correta que preenche a lacuna:
a. Data Sources.
b. Data Marts.
c. Data Mining.
d. Ferramentas OLAP.
e. Staging Area.
77
2. Um Data Mart é um subconjunto lógico e físico da área
de representação de um Data Warehouse que agrupa
dados sobre um único assunto para fornecer suporte
às decisões de um grupo de pessoas específicas.
Sobre as principais características e/ou benefícios do
desenvolvimento de Data Marts, julgue os itens a seguir:
I. Apoiam as necessidades e o controle local de grupos
de usuários por níveis funcionais ou departamentos de
uma empresa.
II. Demandam menos investimento que o
desenvolvimento do Data Warehouse organizacional.
III. Podem ser implementados mais rapidamente,
fornecendo uma resposta mais rápida aos grupos
de usuários.
IV. Mantêm um depósito de dados central com níveis
de granularidade e de armazenamento bem apurados e
não são não-voláteis.
Estão corretos os itens:
a. I – II.
b. II – III.
c. III – IV.
d. I – II – III.
e. I – II – III – IV.
3. A definição de uma arquitetura determina o local onde

o Data Warehouse ou os Data Marts estarão alocados
fisicamente. Para a definição de uma arquitetura, deve-
se levar em conta principalmente o porte da empresa, a
qualificação e expertise dos colaboradores e os recursos
disponibilizados para os investimentos.
78
Assinale a alternativa correta que indica a classificação
dos tipos de arquitetura de Data Warehouse e Data Marts:
a. Independente, centralizada e acoplada.

b. Independente, acoplada e coesa.
c. Transacional, integrada e funcional.
d. Global, transacional e aglomerada.
e. Global, independente e integrada.
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro:
Campus, 2004.
INMON, W. H. Como construir o data warehouse. Rio de Janeiro: Campus, 1997.
KIMBALL, R. et al. The data warehouse lifecycle toolkit. New York: John Wiley &
Sons, 1998.
LAUDON, K. C.; LAUDON, J. P. Sistemas de informação gerenciais. 11. ed. São Paulo:
Pearson Prentice Hall, 2014.
MACHADO, Felipe N. Tecnologia e projeto de data warehouse. 6. ed. São Paulo:
Erica, 2013.
RAINER, R. K.; CEGIELSKI, C. G. Introdução a sistemas de informação: apoiando e
transformando negócios na era da mobilidade. 3. ed. Rio de Janeiro: Elsevier, 2011.
ROB, P.; CORONEL, C. Sistemas de banco de dados: projeto, implementação e
adminsitração. 8. ed. São Paulo: Cengage Learning, 2011.
Gabarito
Questão 1 - Resposta B.
Resolução: Na concepção de Rob e Coronel (2011), um Data Mart
é um pequeno subconjunto de um DW, sobre um único assunto,
que fornece suporte às decisões de um pequeno grupo de pessoas,
podendo ser criado a partir de dados extraídos de um DW maior,
79
com o objetivo específico de dar suporte a acessos mais rápido
para determinado grupo ou função.
Questão 2 - Resposta D.
Resolução: Os itens I, II e III estão corretos. O item IV é uma
característica do Data Warehouse, e não dos Data Marts, pois,
segundo Inmon (1997), o Data Warehouse refere-se a um conjunto
de dados baseado em assuntos, integrado, não-volátil e variável
ao longo do tempo, de apoio às decisões gerenciais. Uma das
principais características do Data Warehouse é a interação dos
dados de diversas fontes distintas, proporcionando um ambiente
estático, que não sofre modificações.
Questão 3 - Resposta E.
Resolução: A escolha da arquitetura é uma decisão que causa
impactos quanto ao sucesso do projeto, podendo afetar o tempo de
execução, o retorno do investimento, a velocidade dos benefícios
da utilização das informações, a satisfação do usuário e os recursos
necessários a sua implementação. A definição de uma arquitetura
determina o local em que o DW ou os Data Marts estarão alocados
fisicamente. Machado (2013) apresenta a seguinte classificação das
arquiteturas: global, independente e a integrada, podendo o tipo de
implementação ser top down, bottom up ou a combinada.
80
Modelagem de dados para um
Data Warehouse
Objetivos
• Reconhecer os aspectos da granularidade e como

eles afetam as análises dos negócios.
• Aplicar as técnicas de modelagem de dados.
• Caracterizar a modelagem multidimensional para

conceber as visualizações e medidas relacionadas
sobre um conjunto de dados.
1. Aspectos sobre granularidade de dados
A compreensão sobre os dados e a granularidade assume uma etapa

importante para modelar os dados em estruturas por níveis. Por
exemplo, a venda de determinado produto se relaciona a seu preço,
à baixa no estoque desse produto e ao cliente que o adquiriu, mas a
quantidade de vendas dos produtos também são dados, no entanto,
representa já um modelo em que vários produtos vendidos foram
somados, não interessando nesse nível elevado de granularidade os
nomes dos clientes para os quais o produto foi vendido. A granularidade
tem a ver com o grau de sumarização, redução ou agregação dos dados.
O produto em si é o grão, o nível mais baixo de granularidade, mas a
quantidade desse mesmo produto vendido representa uma abstração,
um nível e uma granularidade elevados. O dado, nesse caso, faz
referência à soma desses produtos vendidos.
Kimball (2002) explica que especificar o grau de granularidade

dos conjuntos de dados que serão analisados deve ser de comum
entendimento entre os analistas que estão projetando o DW e os
usuários que consumirão as análises. O grau de granularidade se
apresenta em níveis: o baixo nível está relacionado com o dado
bruto sem transformação, enquanto o alto nível está com os dados
transformados, por exemplo, uma soma de quantidades vendidas de
determinado produto.
As tabelas utilizadas no processo de análises devem ser construídas

no nível mais baixo de granularidade possível, aumentando a
flexibilidade e extensibilidade conforme o tipo de filtragem ou os
agrupamentos exigidos nas consultas pelos usuários (KIMBALL, 2002).
Para compreendermos as recomendações propostas pelo mesmo autor,
82
vejamos a seguir um modelo que expressa as restrições relativas à
granularidade (Figura 1).
Figura 1 – Níveis de granularidade dos dados
Fonte: adaptada de Kimball (2002, p. 133-134).
Machado (2011) destaca que a granularidade de dados faz referência

ao nível de sumarização dos dados, considerando este como um
aspecto importante em projetos de DW. Quanto mais detalhes
dos dados, menor será a granularidade; já quanto menos detalhes
houver, maior será a granularidade.
Em bancos transacionais, a granularidade é importante, porque

o dado mais bruto está armazenado lá, diferentemente de
banco de dados analítico, que opera os ambientes de DW, nos
quais sumarizações e agregações afetam a granularidade. A
granularidade afeta profundamente o volume de dados que estão
armazenados em um DW.
A Figura 2 exemplifica a abordagem da granularidade em baixo

e em alto níveis, considerando os detalhamentos pelos dados ou
83
pelas sumarizações. O modelo mostra a diferença entre os dois
níveis, um refere-se às vendas por vendedor, e o outro à soma das
vendas no mês.
Figura 2 – Exemplo de granularidade e nível de detalhamento
A entidade venda mostra os detalhes relacionados à venda de cada

vendedor, a data, a hora, o vendedor associado e o valor da venda. É
possível extrair um relatório das vendas por vendedor, ou seja, aqui há
um nível baixo de granularidade e nível alto de detalhes. Já na entidade
Soma_Vendas, a granularidade é alta e não expressa especificidade sobre
os detalhes da venda, mas consolida o valor das vendas no mês. O primeiro
modelo pode ser importante para a promoção de algum vendedor,
já o segundo serve de apoio para a tomada de decisão da alta gestão
da empresa.
Machado (2011) alerta que a granularidade de um DW auxilia no foco do

projeto, e a modelagem fica mais fácil. Trazendo como exemplo, uma
84
sumarização mensal é fácil e rápida, mas se a sumarização requer saber as
vendas relativas à semana da Páscoa, com promoções que iniciam 45 dias
antes, há a necessidade da elaboração da sumarização mais detalhada, a
cada 15 dias, obtendo três conjuntos quinzenais de dados sumarizados.
O Quadro 1 contempla o exemplo de forma detalhada, a nível de dado,

baixa granularidade. O quadro consiste no detalhamento de dez vendas,
sendo registrados as vendas por vendedor, o valor, a data e a hora.
Todos os registros são lançados em uma base de dados transacional.
O ID (identificação) de cada venda está associado a um número, que
relaciona um dos três vendedores, o valor de cada venda por vendedor,
a data e a hora, respectivamente.
Quadro 1 – Dados armazenados no banco transacional
Id_Vendas Data Hora Vendedor Valor

1 14/06/2012 16:03:12 Paulo M. R$ 2.500,00
2 15/06/2012 16:33:01 Julio W. R$ 1.850,00
3 16/06/2012 18:50:10 Paulo M. R$ 3.300,00
4 17/06/2012 16:33:01 Paulo M. R$ 4.500,00
5 18/06/2012 17:25:06 Maria T. R$ 200,00
6 13/07/2012 12:03:12 Julio W. R$ 2.135,00
7 14/07/2012 14:40:59 Paulo M. R$ 100,00
8 15/07/2012 13:22:08 Paulo M. R$ 130,00
9 16/07/2012 14:15:16 Maria T. R$ 4.750,00
10 17/07/2012 15:17:30 Maria T. R$ 1.889,00
Caso um relatório de vendas seja emitido a partir dos dados do Quadro

1, ele poderia ser executado como na Figura 3.
85
Figura 3 – Relatório de valor de vendas versus vendedor
Relatório Vendedor versus Valor
O relatório de vendedor versus valor das vendas realizadas representa

a totalidade dos dados registrados na base. No entanto, esse exemplo
é meramente ilustrativo. Em um banco de dados real, os registros de
vendas de grandes lojas têm um volume que impossibilitaria a sua
representação. Por esse motivo, são necessárias a seleção de conjuntos
e realização das sumarizações.
O Quadro 2 representa a sumarização realizada mensalmente; nela,

a granularidade aumenta e o nível de detalhamento diminui, pois
não é possível saber quais dias tiveram a melhor venda, não se tem o
detalhe de qual vendedor vendeu mais, ou, ainda, em qual horário está
ocorrendo a venda. Porém, para a tomada de decisão, o mês de junho
teve desempenho de 57% aproximadamente sobre o total das vendas
dos dois meses somados.
86
Quadro 2 – Dados sumarizados para análises
Mês Soma_Valor
Jun/12 R$ 12.350,00
Jul/12 R$ 9.004,00
As vendas somadas nos meses de junho e julho do ano de 2012 foram

de R$ 21.354,00. O exemplo é bastante reduzido, e, por esse motivo, a
elaboração de sumarizações é didática e bastante simples. No entanto,
em um DW em que os dados de diversas lojas são carregados para
analisar o desempenho do ano de 2012, por exemplo, com 50 lojas
de uma rede, com vendas diárias acima de R$ 20.000,00, as consultas
deverão ser elaboradas de maneira a responder à pergunta a seguir
(Figura 4).
Figura 4 – Pergunta analítica
Fonte: adaptado de Deagreez/ iStock.com.
87
Para responder a esse alto nível de granularidade, foi necessário criar
sumarizações mensais que não estavam armazenadas, mas calculadas
por meio de consultas no banco de dados analítico. Vamos supor que,
na coleta de dados das 50 lojas, apenas quatro diferentes lojas tenham
os dados registrados no banco; ao analisar as tabelas fornecidas
apenas por essas quatro lojas, fica difícil concluir qual mês teve melhor
desempenho. O nível de granularidade é muito baixo em função do
detalhamento na Figura 5.
Figura 5 – Dados coletados das vendas mensais de quatro lojas
Loja 1 Loja 2
Loja 3 Loja 4
88
Com base nos resultados coletados, estratificados na Figura 5, é possível
responder à pergunta com apenas quatro lojas? Se fôssemos aguardar
a obtenção dos dados de 50 lojas, poderíamos incorrer em demora
ou muitas vezes os dados nem serem disponibilizados a tempo para
a análise de tomada de decisão, cujo principal objetivo é responder o
mais rápido possível à pergunta realizada. Sendo assim, o modelo de
sumarização deve estar preparado para receber os dados das outras
46 lojas, mas não pode ser impeditivo para a realização das consultas
analíticas, o que deve estar claro também para a alta gestão, que terá
uma visão parcial.
A granularidade precisa estar explícita, o que quer dizer que a

sumarização será realizada para apenas quatro lojas com a expectativa
para mais 46 lojas. Uma estratégia de granularidade deve ser executada
em acordo com os projetistas e usuários que irão analisar os dados.
Dessa maneira, a sumarização terá como base inicial as quatro lojas
com os respectivos faturamentos mensais, conforme apresentado no
Quadro 3.
No quadro a seguir, as tabelas periféricas servem de insumo para as

sumarizações na tabela central, cuja granularidade é maior, sem o nível
de detalhamento das tabelas adjacentes.
89
Quadro 3 – Tabela sumarizada a partir das tabelas adjacentes
Filial 1 Filial 2
Id_ Id_
Data Hora Vendedor Valor Data Hora Vendedor Valor
Vendas Vendas
1 14/01/2012 16:03:12 Paulo M. R$ 2.200,00 BG 1 14/06/2012 16:03:12 Paulo M. R $2.500,00
2 15/01/2012 16:33:01 Julio W. R$ 1.550,00 2 15/06/2012 16:33:01 Julio W. R$ 1.850,00
3 16/01/2012 18:50:10 Paulo M. R$ 2.500,00 Fato 3 16/06/2012 18:50:10 Paulo M. R$ 3.300,00
4 17/02/2012 16:33:01 Paulo M. R$ 1.850,00 4 17/06/2012 16:33:01 Paulo M. R$ 4.500,00
5 18/02/2012 17:25:06 Maria T. R$ 3.300,00 Mês Soma_Valor 5 18/06/2012 17:25:06 Maria T. R$ 200,00
6 13/02/2012 12:03:12 Julio W. R$ 4.500,00 jan/12 R$6.250,00 6 13/07/2012 12:03:12 Julio W. R$ 2.135,00
7 14/03/2012 14:40:59 Paulo M. R$ 200,00 fev/12 R$9.650,00 7 14/07/2012 14:40:59 Paulo M. R$ 100,00
8 15/03/2012 13:22:08 Paulo M. R$ 430,00 mar/12 R$ 3.863,00 8 15/07/2012 13:22:08 Paulo M. R$ 130,00
9 16/03/2012 14:15:16 Maria T. R$ 2.110,00 abr/12 R$ 6.400,00 9 16/07/2012 14:15:16 Maria T. R$ 4.750,00
10 17/03/2012 15:17:30 Maria T. R$ 1.123,00 mai/12 R$13.763,00 10 17/07/2012 15:17:30 Maria T. R$ 1.889,00
jun/12 R$12.350,00
Filial 3 jul/12 R$ 9.004,00 Filial 4

Id_ Id_
Data Hora Vendedor Valor ago/12 R$ 5.450,00 Data Hora Vendedor Valor
Vendas Vendas
1 14/08/2012 16:03:12 Paulo M. R$ 2.600,00 set/12 R$ 6.136,00 1 14/04/2012 16:03:12 Paulo M. R$ 1.200,00
2 15/08/2012 16:33:01 Julio W. R$ 1.550,00 out/12 R$ 4.863,00 2 15/04/2012 16:33:01 Julio W. R$ 150,00
3 16/08/2012 18:50:10 Paulo M. R$ 1.300,00 3 16/04/2012 18:50:10 Paulo M. R$ 200,00
4 17/09/2012 16:33:01 Paulo M. R $4.200,00 4 17/04/2012 16:33:01 Paulo M. R$ 150,00
5 18/09/2012 17:25:06 Maria T. R $800,00 5 18/04/2012 17:25:06 Maria T. R$ 3.200,00
6 13/09/2012 12:03:12 Julio W. R$ 1.136,00 6 13/04/2012 12:03:12 Julio W. R$ 1.500,00
7 14/10/2012 14:40:59 Paulo M. R$ 200,00 7 14/05/2012 14:40:59 Paulo M. R$ 700,00
8 15/10/2012 13:22:08 Paulo M. R$ 430,00 AG 8 15/05/2012 13:22:08 Paulo M. R$ 830,00
9 16/10/2012 14:15:16 Maria T. R$ 4.110,00 9 16/05/2012 14:15:16 Maria T. R$ 5.110,00
10 17/10/2012 15:17:30 Maria T. R$ 123,00 10 17/05/2012 15:17:30 Maria T. R$ 7.123,00
Legenda: AG – Alta granularidade; BG – Baixa granularidade.

A tabela sumarizada contém os valores das somas de cada mês, sendo

alimentada a partir dos dados provenientes das tabelas das lojas. Esse
conjunto forma o DW do exemplo.
Se esses dois níveis de granularidade fossem usados para uma

representação gráfica, como mostra o Gráfico 1, pode-se verificar que o
gráfico com a nível de granularidade baixo fica impossível de analisar, no
90
entanto, quando a tabela sumarizada e explicitada em modo gráfico é
possível realizar as leituras de forma eficiente.
Gráfico 1 – Representação dos dados versus granularidade
A representação gráfica Valores vendas/dia remete a uma relação de

alta densidade dos dados para uma baixa granularidade, portanto,
sua interpretação fica prejudicada. No entanto, a alta granularidade
propicia melhor representação da sumarização, tornando mais
eficientes as comparações e a análise do comportamento dos dados
em uma visão de conjunto. Nesse caso, o mês de maio de 2012 teve o
melhor desempenho.
PARA SABER MAIS

Dados históricos: são os dados provenientes do ambiente
operacional levemente resumidos (MACHADO, 2011). Há,
assim, dois níveis de granularidade: os dados históricos
nos quais possam ser alcançados níveis de detalhes;
e os dados resumidos, compactos e de fácil acesso,
disponíveis para análises.
91
À medida que a granularidade se eleva, esta corresponde à diminuição
da utilização de consultas às bases dos dados operacionais. Nesse
sentido, a modelagem dos dados para um projeto DW é diferente da de
um ambiente operacional.
Esse é também o motivo de não ser possível mover um banco

transacional para um banco analítico, pois acarretaria alta complexidade
para realizar consultas ad hoc, que exigem cálculos acessórios. Os
modelos de dados transacionais são construídos de acordo com a 3ª
Forma Normal (3FN) e não respondem com rapidez às consultas, que
necessitam de mais de cinco joins de tabelas.
PARA SABER MAIS

3FN: é uma forma de normalização; nesse caso, cálculos
são excluídos da tabela, pois eles dependem de colunas
dessa tabela.
Consultas ad hoc: são consultas especializadas ou específicas,
como um cálculo, uma sumarização ou uma junção de duas
tabelas, para estabelecer uma correspondência.
Join: são métodos de junção de dados de tabelas diferentes,
respeitando-se os modelos de conjuntos. Por exemplo, o
inner join da tabela A com a tabela B retorna os dados que são
comuns nas duas tabelas; o left join entre a tabela A e a tabela
B retorna todos os dados da tabela A mais os dados comuns
entre A e B.
A modelagem de dados é um requisito fundamental para o DW e não

pode utilizar as mesmas técnicas que são aplicadas para modelar os
bancos transacionais. Existem duas técnicas distintas, a modelagem
92
ER (Entidade Relacionamento) e a multidimensional, ambas com
abordagem específica para modelos DW.
2. Modelagem de dados para DW
Um modelo é uma abstração e tenta refletir o mundo real. Modelar

é uma abordagem que vislumbra o que ser quer realizar ou fazer.
Como exemplo, um esquema ou um desenho que tenta refletir um
pensamento ou uma ideia. A equação de uma reta que liga dois pontos
do espaço é um modelo que tenta refletir ou explicar uma linha feita por
um conjunto de pontos alinhados. Funciona da mesma maneira quando
se trata de dados (MACHADO, 2011). O dado sozinho é um número ou
uma variável e pouco representa algo, mas, quando associado a outros
dados e transformado, revela contextos e associa ideias.
O diagrama ER é uma ferramenta que ajuda na análise de requisitos de

negócio e no desenho da estrutura de dados relacionada a esse negócio
(MACHADO, 2011). Inmon (2005) afirma que há três tipos de modelagem
de dados, mas destaca o ERD (Entity Relationship Diagram – Diagrama
Entidade Relacionamento), que representa um alto nível de abstração,
cuja integração define os limites do modelo de dados, sendo necessária
sua definição antes que a modelagem ERD comece.
Como exemplo, uma casa tem orçamento mensal para que as despesas
sejam realizadas. Sendo assim, deve haver um controle de despesas em
relação ao orçamento, ou seja, elas não podem ultrapassar o orçamento
mensal disponível. Exemplos de despesas podem ser produtos ou serviços
que serão consumidos ou usados com um valor monetário associado. Com
base nesses requisitos mínimos, é possível fazer a modelagem elaborando
uma tabela “Controle de despesas”, com colunas para o tipo e o valor das
despesas e com o orçamento disponível, a ser decrementado do valor total
como uma forma de controle.
93
As características da modelagem requerem a análise prévia em relação
aos dados. O orçamento disponível deve ter um valor previsto e uma data
de previsão. Despesas é uma entidade que tem como atributos a data
em que ocorreu a despesa, a sequência da despesa (número de vezes),
o nome da pessoa que realizou a despesa, a sua identificação com a
tabela de classificação do orçamento, o mês em que a despesa ocorreu,
o tipo de despesa e o valor da despesa. Outras entidades são incluídas na
modelagem com o objetivo de associar o nome da pessoa que realizou a
despesa, o tipo de despesa, como é a sua classificação no orçamento, se o
valor da despesa foi incluído e se ela cabe no orçamento mensal.
Para ilustrar as duas abordagens sobre modelagem do exemplo

anterior, sob o ponto de vista de negócio, o diagrama da Figura 6
representa um modelo para operacionalizar esse negócio.
Figura 6 – MER da operacionalização do negócio despesa

versus orçamento
Fonte: adaptado de Machado (2011, p. 67).
94
O modelo ER descreve as operações relacionadas ao negócio e às
ligações entre as entidades do modelo. A abordagem dessa modelagem
é operacional. Outra abordagem para esse contexto do exemplo das
despesas versus orçamento é a da gestão do negócio. Nessa perspectiva,
pode-se analisar como ocorre a necessidade de encontrar respostas
com respeito à evolução orçamentária anual.
Ainda como ponto de reflexão, qual a taxa da relação entre despesa e

orçamento? Pensando um pouco mais além, quais produtos ou serviços
apresentam evolução histórica de aumento?
As respostas a essas perguntas permitem encontrar o comportamento

do desempenho do negócio, buscar simulações de cenários para
embasar as análises estratégicas e alocar decisões. Essa abordagem
remete à necessidade de construir um modelo dimensional. No
exemplo, as perguntas feitas são abstrações de localidade (onde),
temporalidade (quando), responsabilidade (quem) e classificação (o quê).
Essas abstrações podem ser exemplificadas da seguinte forma:
a. Localidade (Onde?): local, cidade, região, país, etc.

b. Temporalidade (Quando?): trimestral, mensal, anual, semanal,
diário, etc.
c. Responsabilidade (Quem?): vendedor, promotor, pessoa,
fornecedor, etc.
d. Classificação (O quê?): venda, promoção, despesa, gastos, etc.
Uma modelagem pode ser construída com base nas abstrações de

localidade, tempo, responsáveis e classificação. Outras abstrações
novas podem ser incluídas conforme o negócio da empresa. A Figura
7 representa um diagrama, sobre o mesmo exemplo, mas em outra
perspectiva, a multidimensional.
95
Figura 7 – Modelo multidimensional
Fonte: adaptada de Machado (2011, p. 68).
Os questionamentos apresentados não podem ser respondidos por

meio de consultas às bases de dados operacionais, pois são necessários
cálculos de percentuais destinados às despesas que afetaram o
orçamento. Esses dados calculados são provenientes das operações de
entrada dos dados e da relação entre despesa e orçamento calculada
em tabelas acessórias.
Esse exemplo permite contextualizar dois modelos de dados: um seria o

modelo ER e o outro o modelo multidimensional. Um depende do outro,
em que o MER contém os elementos operacionais da empresa, e o
modelo multidimensional reflete as métricas às dimensões relacionadas.
2.1 Modelagem ER
Um modelo ER utiliza três caracterizações para os dados: entidade,

relacionamento e atributos. A entidade é o objeto do mundo real, identificado
96
e com significado próprio, podendo ser um lugar, uma pessoa ou um evento.
Ela representa classes de objetos e pode ser observada e classificada de
acordo com suas caraterísticas e propriedades (MACHADO, 2011). Esses
objetos do mundo remetem a um escopo de integração do mundo real, que
determina qual parte poderá refletir um modelo (INMON, 2005). O modelo
é descrito em suas partes e como elas se relacionam; no caso de dado, é o
Modelo Entidade Relacionamento (MER).
Para elucidar esse contexto, a Figura 8 exemplifica um MER de vendas, em

que o vendedor vende o produto. Vendedor e produto são as entidades
e “vende” é o relacionamento entre as duas entidades. O Id_produto e Id_
vendedor são as chaves primárias de cada entidade, Produto é valor_produto
e Nome são os atributos relativos a cada entidade.
Figura 8 – Modelo ER Vendedor Produto

– modelo conceitual
O reconhecimento de uma entidade é orientado pelo mundo real, no

ambiente em que ela existe, retratando a sua realidade por meio dos
dados. Pelo exemplo, o vendedor tem um nome a ele associado e tem a
ação de vender algo, que são produtos, os quais têm um tipo e um valor
(MACHADO, 2011).
97
A nomeação da entidade deve ser clara e refletir uma comunicação
acessível sobre ela, orientando-se por uma nomenclatura que
represente suas características e seu escopo. Por exemplo, venda,
pessoa, produto: venda é a ação em si, que relaciona a pessoa ao
produto; pessoa é quem compra ou até quem vende; e produto é o
objeto que foi vendido.
Cada entidade contém atributos, e um deles é o atributo chave, que

se identifica exclusivamente ao registro ao qual a chave pertence.
Na entidade Vendedor, a chave primária (PK) é o Id_Vendedor, é o
identificador numérico de cada nome de vendedor. Em uma tabela do
banco de dados, a chave primária é incluída em outra tabela e passa a
ser uma chave estrangeira (FK), para que os relacionamentos funcionem.
O mesmo acontece com produto, que tem um Id e um PK, conforme o
modelo da Figura 9.
ASSIMILE
Chave estrangeira (FK – Foreign Key): é um atributo em um

sistema relacional, cujos valores são os valores da chave
primária de outra entidade relacionada. Não é uma chave
primária (INMON, 2005, p. 497).
Chave primária (PK – Primary Key): é um atributo que
contém valores que identificam exclusivamente o registro
no qual a chave existe (INMON, 2005, p. 501).
Analisando sob o ponto de vista de tabelas no banco de dados, o modelo

ER Vendas pode ter as tabelas criadas conforme a Figura 9.
98
Figura 9 – Modelo Lógico “Venda”
O modelo lógico representa as entidades e seus relacionamentos, com

as indicações da chave primária na tabela Vendedor (desenho da chave
preta) e da chave estrangeira na tabela Produto Venda (desenho da
chave verde). Ao construir as tabelas que serão inseridas no banco de
dados, uma possível organização pode ser verificada no Quadro 4. A
tabela Produto Venda contém o Id_vendedor como FK, para que a venda
possa estar relacionada com a tabela de vendedor.
99
Quadro 4 – Tabelas dimensão do banco de dados
Produto Venda
Id_pro- valor_pro-
Vendedor duto tipo_produto duto id_vendedor
1 Geladeira soft R$ 2.500,00 4
Id_vendedor Nome
2 Fogão galaxi R$ 899,00 3
1 Mario 3 Geladeira alfa R$ 1.890,00 3
Microondas
2 Luis
4 wave R$ 450,00 1
3 Sergio 5 Ferro pass R$ 120,00 2

Aquecedor
4 Augusto 6 ice5 R$ 3.689,00 1
Microndas
5 Juvenal 7 wavelet R$ 730,00 4
8 geladeira first R$ 1.320,00 2
A partir das tabelas Vendedor e Produto Venda, é possível criar uma

tabela sumarizada do total de vendas de cada vendedor. Essa nova
tabela poderia ser criada a partir da tabela Vendedor e da Produto
Venda (Quadro 5), com o objetivo de representar o resultado do
desempenho de cada vendedor. São duas tabelas dimensões que
participam da tabela Fato Desempenho Vendedor, uma dimensão
Vendedor e outra Produto Venda.
Quadro 5 – Tabela Fato Desempenho Vendedor

Desempenho vendedor
Id_vendedor Nome total_vendedor
1 Mario R$ 4.139,00
2 Luis R$ 1.440,00
3 Sergio R$ 2.789,00
4 Augusto R$ 3.230,00
5 Juvenal R$ -
100
O Quadro 5 representa a sumarização dos valores de cada produto
vendido por vendedor. A tabela Fato é concebida para visualizar um
conjunto de medidas que descrevem o desempenho característico
dos vendedores relacionados com o tipo de negócio, com a venda de
produtos na categoria eletrodomésticos. Ela é composta por partes da
tabela Vendedor e partes da tabela Produto Venda, incluindo as somas
das vendas por vendedor. Essa abordagem é denominada modelagem
multidimensional e está representada pelo caso em estudo no Quadro
6. A modelagem multidimensional será explorada posteriormente,
detalhando a composição das tabelas Fato e das tabelas dimensões,
formando um cubo de interações.
Quadro 6 – Modelo muldimensional vendas

Vendedor Desempenho vendedor
Id_vendedor Nome Id_vendedor Nome total_vendedor
1 Mario 1 Mario R$ 4.139,00
medidas
2
3
Luis
Sergio
= 2
3
Luis
Sergio
R$ 1.440,00
R$ 2.789,00
4 Augusto 4 Augusto R$ 3.230,00
5 Juvenal 5 Juvenal R$–
=
Produto Venda
Id_produto tipo_produto valor_produto id_vendedor
1 Geladeira soft R$ 2.500,00 4
2 Fogão galaxi R$ 899,00 3
3 Geladeira alfa R$ 1.890,00 3
4 Microondas wave R$ 450,00 1
5 Ferro pass R$ 120,00 2
6 Aaquecedor ice5 R$ 3.689,00 1
7 Microndas wavelet R$ 730,00 4
8 Geladeira first R$ 1.320,00 2
101
Machado (2011) observa que a modelagem multidimensional é mais
simples e inteligível do que a modelagem ER. Embora o nível de
abstração seja elevado, o modelo multidimensional está mais acessível
em termos de oferta de informação e é usado em projetos de DW,
justamente por ser objetivo e compor conjuntos de dados que possam
representar alguma resposta às perguntas.
2.2 Modelagem muldimensional
Uma questão emblemática no projeto de DW é a utilização do modelo

relacional (MER) e do modelo muldimensional para o design do banco
de dados de DW. Inmon (2005) orienta o uso do modelo relacional
para projetos DW, no entanto, Kimball (2002) orienta que o modelo
multidimensional deve ser levado em consideração em projetos de DW.
Fazendo uma análise das duas orientações, conclui-se que a modelagem
relacional é a abordagem de longo prazo no desenho de projetos DW,
enquanto a modelagem multidimensional permite implementações a
curto prazo, quando o escopo é reduzido.
A modelagem multidimensional, segundo Machado (2011, p. 79), é

uma técnica para concepção e visão de dados a partir de um conjunto,
que pode formular respostas às perguntas de negócios. Essa técnica é
utilizada para sumarizar e restruturar dados, de modo a representá-los
em visões que tragam suporte às análises necessárias. Como exemplo,
as companhias aéreas utilizam essa técnica para representar seus DW
por causa do tipo de negócio, agência reguladora do governo, agências
de viagens e aeroportos.
Machado (2011) esclarece que o modelo multidimensional é composto

por três elementos básicos:
102
a. Fatos.
b. Dimensões.
c. Métricas.
Uma tabela Fato é composta por dados, medidas e contexto

provenientes de dimensões. Uma Fato representa um item, uma
transação ou um evento relacionado ao negócio e possui valores
numéricos, sendo sua implementação feita em tabelas denominadas
tabela Fato (fact tables).
As dimensões, para Machado (2011), são os elementos, os dados, as

fórmulas e os cálculos processados que participam ou são chamados
por meio de chaves estrangeiras (FK) dentro de uma Fato. As dimensões
são os assuntos do negócio, por exemplo, faturamento por mês, gastos
por semana, vendas por região etc. As dimensões apresentam um
contexto do negócio, supondo uma análise de vendas; ou melhor, em
uma tabela Fato de vendas, as dimensões que participam dessa Fato
podem ser vendas dos produtos em relação ao tempo, à localização, aos
clientes, aos vendedores, às sazonalidades, entre outros cenários que
influenciam no negócio.
Já as medidas são os atributos valorados numericamente que

representam uma tabela Fato. Como exemplo de medida, a quantidade
de unidades de um produto vendidas, a quantidade de produtos em
estoque, o percentual de lucro, entre outras medições.
Portanto, ao casar as três técnicas, as dimensões, a Fato e as medidas,

a melhor maneira de visualizar é por intermédio de um cubo. A forma
facilitadora de representar o modelo multimensional é pelo desenho
de um cubo tridimensional, colocando as características técnicas
nele. A Figura 10 mostra uma representação cúbica multidimensional,
considerando um negócio genérico de venda de produtos por cidade.
103
Figura 10 – Modelagem muldimensional vendas
Vendedor
es
jas
Lo
Produtos
Temp
oralid
ade
DIMENSÕES: PRODUTO, CIDADE, TRIMESTRE.

Fato: produtos por cidade no trimestre.
Medidas: soma das vendas trimestrais por produto.
Fonte: hh5800/ iStock.com.
O exemplo demostra claramente como a modelagem multidimensional

pode ser representada por meio de um cubo, formado por tabelas
que se associam, sumarizam ou se agregam e que compõem alguma
métrica. Cada tabela pode ser interpretada como uma dimensão, todas
as tabelas juntas formam o cubo e, hieraquicamente, a granularidade
em nível alto ou baixo. Disso são extraidas as tabelas Fato e destas
as medidas. Há casos em que medidas e cálculos são realizados nas
104
dimensões para depois serem indexados nas tabelas Fato. A partir das
Fatos, medidas, sumarizações e agregações podem ser representadas
por meio de visualizações a serem consumidas pelos usuários.
A modelagem de dados é uma das etapas importantes em um projeto

de DW, levando em consideração os níveis de granularidade do dado e/
ou do conjunto de dados a partir dos quais se quer obter resultados ou
respostas. Além disso, a modelagem entidade relacionamento propõe
um caminho inicial para sistematizar conceitos mais complexos, como
a granularidade, e a abordagem sobre como construir tabelas Fato a
partir de tabelas dimensões. A maturidade necessária empregada à
modelagem multidimensional se tornará mais eficiente à medida que
a base do modelo ER estiver compreendida. Projetos de DW requerem
um acúmulo de experiências dos profissionais, principalmente na fase
inicial, na modelagem. Na prática, cubos, dimensões, Fatos e medidas
devem ser modelados multidimensionalmente em um projeto de DW
por serem mais fáceis de implementar.
TEORIA EM PRÁTICA
Uma empresa produtora de grãos para exportação e
abastecimento no mercado brasileiro deseja iniciar um
projeto de Data Warehouse. A empresa compra os grãos
in natura de três fazendas, faz a coleta nos silos e leva
para a produção de lotes para a comercialização interna
e internacional. Faça uma simulação de uma modelagem
muldimensional, considerando cinco tipos de grãos: feijão
fradinho, feijão carioca, feijão preto, feijão branco e feijão
fava. A produção é trimestral, com variações de 10% em
105
cada trimestre, sendo a melhor safra nos três ultimos
meses do ano, quando não esta é afetada pelas variações
climáticas e pelas chuvas. As fazendas estão localizadas
nas regiões Norte, Nordeste e Centro-Oeste, e a fábrica de
separação e ensacamento fica no sul do país. A logística
para transporte dos silos das fazendas é quinzenal. A
produção dos feijões é afetada pela variação climática
nos seis primeiros meses do ano – clima muito quente e
chuvas. Com base nesse cenário, projete um banco de DW
por meio das técnicas de modelagem multidimensional.
Simule o ambiente populando as tabelas dimensões com
dados fictícios de produção agrícula, temperatura, tempo e
localidade.
1. Quais os elementos básicos que compõem um

modelo multidimensional e um modelo relacional,
respectivamente?
a. Modelo multidimensional: Fatos, dimensões

e métricas; modelo relacional: entidade,
relacionamento, atributos.
b. Modelo multidimensional: entidade, dimensões e
métricas; modelo relacional: Fatos, relacionamento,
atributos.
c. Modelo multidimensional: Fatos, entidades e métricas;
modelo relacional: entidade, relacionamento,
dimensões.
106
d. Modelo multidimensional: entidade, relacionamento,
atributos; modelo relacional: fatos, dimensões
e métricas.
e. Modelo multidimensional: entidade e dimensões;
modelo relacional: fatos e relacionamento.
2. A sumarização e reestruturação dos dados permite

representá-los em visões que suportem as análises. Para
que isso ocorra, é necessária a utilização de técnica que
auxilie na concepção e no desenho da visão dos dados
em conjunto, indo do nível mais alto ao nível mais baixo
de detalhamento desses dados. Aponte a alternativa
correta que cite essa técnica.
a. Modelagem.
b. Granularidade.
c. Relacionamento.
d. Entidade.
e. Especialização.
3. O que representa atributos valorados numericamente e

as tabelas Fato, associando, por exemplo, quantidades
de vendas, quantidade em estoque, percentual de
lucro etc.
a. Relacionamento.
b. Chave estrangeira.
c. Medidas.
d. Modelos.
e. Chave primária.
107
Publishing, 2005.
MACHADO, F. N. R. Tecnologia e Projeto de Data Warehouse. 5. ed. São Paulo,
Editora Érica, 2011.
Gabarito
Questão 1 - Resposta A.
Resolução: De acordo com Machado (2011), o modelo

multidimensional é composto por elementos básicos fatos,
dimensões e métricas, enquanto uma tabela Fato é composta por
dados, medidas e contexto, provenientes de dimensões. Essas
dimensões são assuntos do negócio e têm três outros elementos
básicos, dados, fórmulas e cálculos processados, que participam
ou são chamados por meio de chaves estrangeiras dentro de uma
Fato. Já o modelo relacional utiliza três caracterizações para os
dados: entidade, relacionamento e atributos.
Resolução: A granularidade é uma técnica que visa auxiliar nas

sumarizações, nas visões e na concepção de análises de conjuntos
de dados. Essa técnica pode ser utilizada para representar níveis
de detalhamento dos negócios, desde as operações até as análises
específicas. Quanto maior o nível de detalhamento menor a
granularidade e vice-versa.
108
Questão 3 - Resposta C.
Resolução: As medidas ou métricas são os atributos valorados
numericamente que representam uma tabela Fato, que será usada
para compor as representações da mensuração pretendida. São
exemplos de medida: a quantidade de unidades de um produto
vendidas, a quantidade de produtos em estoque, o percentual de
lucro, entre outras medições.
109
Esquema Estrela e Esquema Floco
de Neve
Objetivos
• Conhecer e compreender a modelagem

multidimensional e seus elementos.
• Conhecer e compreender o Esquema Estrela (Star

Schema) da modelagem multidimensional.
• Conhecer e compreender o Esquema Floco

de Neve (Snow Flake Schema) da modelagem
multidimensional.
1. Fundamentos da modelagem multidimensional
Nos sistemas transacionais com o uso de bancos de dados

relacionais, a performance em tempo de resposta, bem como a
minimização da redundância e inconsistência dos dados, pode
ser garantida com o processo formal de normalização de dados,
tornando as consultas mais simples para atenderem às tarefas
rotineiras dos usuários. Já nos Data Warehouses (DW), as consultas são
mais complexas, envolvendo um grande volume de dados históricos
com diferentes codificações e predominando-se a não-volatilidade.
Para o projeto e as especificação dos DW, adota-se a modelagem
multidimensional, a qual representa uma abstração dos dados
armazenados, consistindo em um modelo composto por tabelas Fato
e de Dimensões, que proporcionam uma visão multidimensional de
grande quantidade de dados.
Segundo Kimball (1998), os Fatos representam uma coleção de itens

de dados, composta de dados de medidas, representando uma
transação ou um evento de negócio. Um fato é representado por
valores numéricos em um esquema e implementado em tabelas
denominadas de tabelas Fato. As dimensões são os elementos que
participam de um fato, ou seja, são as possíveis formas de visualizar
os dados de forma descritiva e classificatória, determinando o
contexto de um assunto de negócio. Os elementos que representam
uma dimensão são especificados em um esquema e implementados
em tabelas denominadas de tabelas de Dimensões.
O modelo multidimensional contém as mesmas informações que

um modelo normalizado, mas agrupa os dados com o objetivo
de reestruturá-los para facilitar a compreensão dos usuários e
melhorar o desempenho de consultas dinâmicas, a partir de uma
111
representação conceitual dos dados em várias visões, que exibem
as informações no formato de um cubo. Esse cubo pode ser fatiado
e aprofundado em cada dimensão ou em seu eixo para permitir
a extração dos detalhes e processos internos de uma empresa de
forma simples de serem analisados.
Na visão de Barbieri (2001), a modelagem multidimensional é uma

técnica de projeto que conduz os dados a uma fase (cubo) em que
a informação reside na interseção de várias dimensões, permitindo
que o usuário perceba os dados em uma forma próxima de seu
entendimento, com várias perspectivas possíveis, entre elas o tempo
e o espaço. Elmasri e Navathe (2011) explicam que:
Modelos multidimensionais tiram proveito dos relacionamentos

inerentes nos dados para preencherem os dados em matrizes
multidimensionais, chamadas cubos de dados. Se tiverem mais de
três dimensões, estes podem ser chamados de hipercubos. (ELMASRI;
NAVATHE, 2011, p. 722)
Um processamento Online Analytical Processing (OLAP –

Processamento Analítico On-line) estrutura logicamente dados
multidimensionais no formato de um cubo, a partir do qual os
usuários finais visualizam os dados armazenados como um cubo de
dados. O cubo apresenta várias dimensões que são subconjuntos
de atributos. A Figura 1 mostra um exemplo de cubo de dados com
três dimensões: localização com hierarquia dos dados por estado
e cidade; tempo com hierarquia dos dados por ano e trimestre; e
produto, a partir do qual é possível mensurar o volume de vendas
calculando o valor total/quantidade de vendas dos produtos por
estado/cidade no ano/trimestre.
112
Figura 1 – Exemplo de cubo de dados
PARA SABER MAIS

Online Analytical Processing (OLAP – Processamento
Analítico On-line): o termo representa a característica
de trabalhar os dados com operadores dimensionais,
possibilitando uma forma múltipla e combinada de análise. O
ambiente de processamento analítico OLAP é caracterizado
por consultas complexas, estruturadas e frequentes,
envolvendo agregação ou relacionamento de dados para
gerar informações que apoiam processos decisórios.
Um modelo de dados multidimensional poder ser representado por

um cubo tridimensional não implica que haja um limite para o número
113
de dimensões que podem ser associadas a uma tabela Fato. Não
há limite matemático para o número de dimensões utilizadas (ROB;
CORONEL, 2011).
Existem algumas abordagens específicas para a modelagem

multidimensional, derivadas da aparência do esquema traçado, a partir
do Diagrama de Entidades e Relacionamentos (DER), relacionando as
tabelas Fato com as tabelas de Dimensões. A mais utilizada é o Esquema
Estrela (Star Schema) e uma variante deste esquema é denominada de
Esquema Floco de Neve (Snow Flake Schema), as quais são apresentadas
nos itens a seguir.
2. Esquema Estrela (Star Schema)
O Esquema Estrela (Star Schema) é a abordagem proposta por Ralph

Kimball que visa criar esquemas físicos mais simples e incrementais.
O nome estrela foi definido em função da disposição em que se
encontram as tabelas, sendo a tabela Fato centralizada no esquema
e as tabelas de Dimensões relacionadas nas pontas do esquema, de
forma independente entre as dimensões. Segundo Kimball (1998),
o esquema de dados mais utilizado na especificação de um DW é o
Esquema Estrela.
Na concepção de Poe, Klauer e Brobst (1998), o Esquema Estrela

possui uma estrutura simples com poucas tabelas e associações
bem definidas, aproximando do contexto do modelo de negócio
e facilitando a geração de consultas complexas de forma intuitiva
e interativa, por meio dos vários parâmetros de consultas.
Nesse esquema, o assunto principal fica ao centro do esquema,
representado pela tabela Fato, enquanto suas características,
as dimensões, representadas por tabelas de Dimensões, ficam
114
posicionadas ao seu redor, permitindo a leitura e compreensão até
mesmo de usuários finais que não estão adaptados às estruturas de
banco de dados.
As tabelas de Dimensões contêm a descrição textual do negócio

representada pelos atributos e com a indicação da chave primária,
que serve como base para manter a integridade referencial quando
relacionada com a tabela Fato. Ela é a tabela dominante do Esquema
Estrela composta por dois tipos de atributos: as chaves estrangeiras,
que caracterizam as métricas estabelecidas nas tabelas de
Dimensões, e os atributos, que definem os fatos a serem medidos.
Na concepção de Colaço Jr. (2004), o nome Esquema Estrela foi

adotado pela semelhança com uma estrela, sendo composto de
uma tabela dominante no centro, chamada de Fatos, rodeada por
tabelas auxiliares, chamadas de tabelas de Dimensões. A tabela
Fato conecta-se às tabelas de Dimensões por várias junções e cada
tabela de Dimensão se conecta com apenas uma junção à tabela
Fato. O esquema tem como característica básica a presença de dados
altamente redundantes, considerando a desnormalização das tabelas
dimensionais dos dados, para se obter um melhor desempenho em
tempo de execução.
De acordo com Machado (2013), o Esquema Estrela é a estrutura

básica de um modelo de dados multidimensional composto por uma
grande entidade central denominada Fato (Fact Table) e um conjunto
de entidades menores denominadas Dimensões (Dimension Tables),
organizadas ao redor da entidade central, formando uma estrela, como
mostra a Figura 2. Os relacionamentos entre a tabela Fato e as tabelas
de Dimensões são definidos por ligações simples em um relacionamento
de um para muitos (1:N), no sentido das dimensões para o fato.
115
Figura 2 – Esquema Estrela (Star Schema)
Fonte: adaptada de Machado (2013).
Rob e Coronel (2011) descrevem que o Esquema Estrela é uma técnica

de modelagem de dados utilizada para mapear dados multidimensionais
de suporte às decisões em um banco de dados relacional, por meio de
seus fatos e de suas dimensões, que são representados como tabelas
físicas no banco de dados do DW, sendo a tabela Fato relacionada a
cada tabela de Dimensão em um relacionamento “muitos para um”. Os
seguintes componentes são relacionados nesse esquema:
a. Fatos: são medidas numéricas que representam um aspecto

ou uma atividade específica do negócio e que podem ser
calculados ou derivados em tempo de execução, sendo
armazenados em uma tabela Fato que constitui o centro
do Esquema Estrela. Os fatos normalmente utilizados em
análise de dados comerciais referem-se aos indicadores de
desempenho do negócio.
116
b. Dimensões: são as características descritivas que fornecem
as perspectivas adicionais a um determinado fato por
meio de seus atributos. As dimensões são armazenadas
em tabelas de Dimensões vinculadas à tabela Fato. As
dimensões normalmente utilizadas em uma análise de dados
de vendas (Fatos Vendas) podem ser as de produto/serviço,
localização e tempo.
c. Atributos: representam os valores das características descritivas
sobre os fatos. Cada tabela de Dimensão contém atributos
que costumam ser utilizados para buscarem, filtrarem e
classificarem fatos.
d. d. Hierarquias: representam a ordenação em hierarquias
de atributos no interior das dimensões, fornecendo uma
organização vertical adotada com a finalidade de detalhamento
e agregação de dados no DW por operações de drill down ou
roll up (também chamado de drill up). As operações permitem
o detalhamento dos atributos, definindo um caminho para
identificar como os dados devem ser dissociados ou agregados.
A Figura 3 mostra o exemplo de hierarquias dos atributos
de localização detalhada por região, estado, cidade e loja;
tempo detalhado por ano, trimestre, mês e semana; e produto
detalhado por tipo, categoria, grupo e subgrupo.
ASSIMILE
A granularidade de dados faz referência ao nível de

detalhamento dos dados de uma tabela. Quanto maior o
nível de detalhe, menor será a granularidade.
117
Figura 3 – Hierarquia de atributos
Fonte: adaptada de Rob e Coronel (2011).
Os DW geralmente são constituídos de muitas tabelas Fato que

armazenam grande quantidade de dados históricos relacionados com as
tabelas de Dimensões, cada uma projetada para responder a questões
específicas de suporte a decisões. As tabelas Fato e de Dimensões são
relacionadas por chaves estrangeiras, sendo a chave primária do lado
“1” da tabela de Dimensão armazenada como parte da chave primária
do lado “muitos” da tabela Fato. Como a tabela Fato está relacionada
com várias tabelas de Dimensões, sua chave primária é sempre formada
combinando-se as chaves estrangeiras que apontam para as tabelas de
Dimensões, o que forma uma chave composta.
A Figura 4 ilustra um exemplo do Esquema Estrela com os

relacionamentos entre as tabelas Fato de Vendas e as tabelas de
Dimensões de localização, tempo, loja filial e produto. A chave primária
da tabela Fato vendas é composta de loc_ID, tem_ID, loj_ID e pro_ID.
Cada registro da tabela Fato vendas representa os produtos vendidos
118
por uma loja, em uma localização específica e em uma data específica,
identificado exclusivamente pela combinação dos valores de cada uma
de suas chaves estrangeiras.
Figura 4 – Esquema Estrela para vendas
Colaço Jr. (2004) descreve que o Esquema Estrela é assimétrico, uma vez
que se percebe nitidamente a tabela Fato como dominante do esquema,
e flexível, para suportar a inclusão de novos elementos de dados, bem
como mudanças que ocorram no projeto.
A Figura 5 ilustra um esquema com duas tabelas Fato, também

conhecido como uma constelação de fatos, ou seja, um conjunto
de tabelas Fato que compartilham algumas tabelas de Dimensões
do mesmo esquema. Na figura, as tabelas Fato vendas e compras
compartilham as tabelas de Dimensões de produto e tempo.
119
Figura 5 – Esquema Estrela para vendas e compras
Destacam-se como as principais vantagens do Esquema Estrela:
• A estrutura padronizada e regular do esquema é bastante simples,

permitindo que a modelagem do esquema e as ferramentas de
acesso aos dados disponibilizem funcionalidades intuitivas que
facilitem a interação dos usuários com a manipulação dos dados,
bem como acesso à apresentação e ao desempenho das consultas
geradas para análise das informações (KIMBALL; ROSS, 2013).
• A facilidade e a flexibilidade da inclusão de novos elementos de
dados, a partir do relacionamento da tabela Fato com uma nova
tabela de Dimensão, bem como o acréscimo de novas colunas às
mesmas tabelas de Dimensões (COLAÇO JR., 2004).
• As consultas ocorrem inicialmente nas tabelas de Dimensões e
depois nas tabelas Fato, assegurando a consistência dos dados
por meio de uma estrutura de chaves que garanta o acesso aos
dados com melhor desempenho.
• O fornecimento de um mapeamento direto e intuitivo entre as
entidades de negócios de um modelo de dados para as tabelas
Fato e tabelas de Dimensões do esquema facilita o entendimento
de usuários finais que não estejam adaptados às estruturas de
bancos de dados.
120
Date (2004) aponta como uma desvantagem do Esquema Estrela o fato
de nem sempre os esquemas resultarem em projetos físicos legítimos,
ou seja, um projeto que preserve todas as informações e restrições em
um projeto lógico correto, considerando os princípios da modelagem
relacional. Assim, muitas vezes é necessário normalizar as tabelas de
Dimensões. Já Barbieri (2001) destaca como uma desvantagem do
Esquema Estrela a falta de estruturas previstas para armazenar dados já
dissociados ou agregados.
3. Esquema Floco de Neve (Snow Flake Schema)
O Esquema Floco de Neve (Snow Flake Schema) pode ser considerado

uma extensão do Esquema Estrela. Nesse esquema, as tabelas
de Dimensões visam eliminar a redundância dos atributos
descritivos, organizando-os em uma hierarquia de tabelas de
Dimensões normalizadas. Contudo, isso aumenta o número de
tabelas de Dimensões, resultando em consultas mais complexas e
desempenho reduzido.
Machado (2013) descreve que o Esquema Floco de Neve é uma

decomposição de uma ou mais dimensões que possuem hierarquias
entre seus elementos. Dessa forma, cada uma das “pontas da estrela”
passa a ser o centro de outras estrelas com suas tabelas de Dimensões
normalizadas até a terceira forma normal, definindo relacionamentos
muitos para um entre as tabelas de Dimensões decompostas e
formando, assim, uma hierarquia por meio desses relacionamentos,
como mostra a Figura 6, a dimensão localização decomposta em cidade,
estado e região, e a dimensão produto decomposta em tipo de produto.
Elmasri e Navathe descrevem que o “esquema floco de neve é uma

variação do esquema estrela em que as tabelas dimensões de um
121
esquema estrela são organizadas em uma hierarquia ao normalizá-
las” (ELMASRI; NAVATHE, 2011, p. 725). A Figura 6 ilustra o Esquema
Floco de Neve.
Figura 6 – Esquema Floco de Neve
O Esquema Floco de Neve separa as hierarquias das dimensões em

tabelas diferentes, especificando variantes da dimensão principal.
Considera-se que a aplicação da técnica de normalização nas tabelas
de Dimensões aumenta consideravelmente o número de dimensões,
diminuindo consequentemente a performance das consultas dinâmicas.
A Figura 7 mostra uma representação do Esquema Floco de Neve e
ilustra a dimensão de localização normalizada na terceira forma normal
com as tabelas de dimensões cidade, estado, região e país, obtendo
simplicidade semântica e facilitando a navegação do usuário final pelas
dimensões.
122
Figura 6 – Esquema Floco de Neve para Vendas
Kimball e Ross (2013) afirmam que os projetistas devem minimizar a

transformação de um Esquema Estrela em Esquema Floco de Neve
devido ao impacto da complexidade desse tipo de estrutura sobre
o usuário final, considerando que o ganho em termos de espaço de
armazenamento é pouco relevante.
A utilização do Esquema Estrela é extremamente recomendável pelos

aspectos de ganhos de performance, quando comparado com o
Esquema Floco de Neve, que resulta normalmente da normalização
de tabelas de Dimensões. Considera-se que a redundância no caso da
adoção do Esquema Estrela é amplamente compensada pelas reduções
de operações de junção, que são necessárias para a recuperação de
dados em tempo de execução.
123
Soluções eficientes e que envolvem questões de análises complexas

dos processos de negócio de uma empresa requerem uma visão das
informações de diferentes perspectivas para permitir a identificação de
problemas, tendências e oportunidades de negócios.
Na modelagem multidimensional de um DW, o contexto das

funcionalidades que determinam os processos de negócio de uma
empresa é especificado em tabelas Fato. Ela é a principal tabela de um
esquema dimensional, que contém vários fatos correspondentes a cada
uma de suas linhas que armazenam uma ou mais medidas numéricas,
constituindo valores para a análise dimensional. A tabela Fato relaciona-
se com as tabelas de Dimensões, que representam as entidades de
negócio e constituem as estruturas de entrada, que realizam os filtros
de valores aplicados na manipulação dos fatos. Kimball e Ross (2013)
reforçam que, quanto maiores o tempo e a atenção nesse processo,
melhor será a qualidade da base de dados de um DW.
A decisão de optar pelo Esquema Estrela ou pelo Esquema Floco de

Neve deve ser tomada levando em consideração principalmente a
complexidade da solução e o volume de dados a ser manipulado,
ou seja, é uma decisão que compete às boas práticas de projetos.
Os esquemas, por meio de seus fatos e de suas dimensões, podem
fornecer informações em diferentes formatos e graus de detalhamento,
auxiliando, assim, na transformação das informações em conhecimento
para o suporte às decisões.
TEORIA EM PRÁTICA
Considere que uma das maiores locadoras de veículos
do país tem 143 filiais localizadas em vários estados
brasileiros e 18 filiais em 4 países da América Latina. Cada
124
filial disponibiliza o serviço de aluguel de seus veículos
para clientes nacionais e estrangeiros. A locadora possui
uma ampla frota com veículos de diferentes categorias
(ônibus, carros de passeio, utilitários etc), variadas
marcas e modelos. Os gestores da locadora pretendem
analisar os custos, o faturamento e os lucros das filiais
de diferentes períodos das locações, principalmente
de datas festivas, para tomarem decisões estratégicas
para a expansão de novas filiais. Para isso, represente a
modelagem multidimensional, no formato do Esquema
Estrela, contemplando as dimensões que participarão dos
fatos mensuráveis para a geração de consultas dinâmicas, a
partir de ferramentas OLAP, disponibilizadas no projeto de
desenvolvimento do Data Warehouse da locadora.
1. Os esquemas de dados utilizados na modelagem

dos Data Warehouses (DW) compreendem a chamada
modelagem multidimensional. Ela representa uma
abstração dos dados armazenados, consistindo em um
modelo composto por tabelas Fato e de Dimensões,
que proporcionam uma visão multidimensional de
grande quantidade de dados. A tabela Fato é a principal
tabela de um esquema dimensional, que geralmente
contém vários fatos que indicam valores para a análise
dimensional, enquanto as tabelas de Dimensões
representam as características descritivas que fornecem
as perspectivas adicionais aos fatos.
Assinale a alternativa correta que descreve as

características das tabelas Fato e de Dimensões.
125
a. A tabela Fato representa entidades de negócio e
constituem as estruturas de entrada que servem
para armazenar informações como tempo, produto,
cliente etc. Ela tem uma relação 1:N com as tabelas de
Dimensões.
b. A tabela Fato deve ser entendida como a tabela que
realiza os filtros de valores aplicados na manipulação
dos dados, determinando o contexto de um assunto
de negócio.
c. As tabelas de Dimensões servem para armazenar
medidas numéricas associadas a eventos de negócio.
Possuem como chave primária uma chave única.
d. As tabelas de Dimensões servem para armazenar
uma ou mais medidas numéricas, que constituem
os valores objetos da análise dimensional.
Possuem normalmente como chave primária uma
chave composta.
e. As tabelas de Dimensões representam as
características descritivas, que fornecem as
perspectivas adicionais a um determinado fato por
meio de seus atributos. Elas têm uma relação 1:N com
a tabela Fato.
2. Existem algumas abordagens específicas para a

modelagem multidimensional, derivadas da aparência
do esquema traçado, a partir do Diagrama de Entidades
e Relacionamentos (DER), relacionando as tabelas Fato
com as tabelas de Dimensões. O ___________________
é a abordagem que visa criar esquemas físicos mais
simples e incrementais devido à disposição em que se
126
encontram as tabelas, sendo a tabela Fato centralizada
no esquema e as tabelas de Dimensões relacionandas
nas pontas do esquema.
Assinale a alternativa que preenche

corretamente a lacuna:
a. Esquema Cubo.
b. Esquema Estrela.
c. Esquema Floco de Neve.
d. Esquema MER.
e. Esquema Multifocal.
3. O nome do Esquema Estrela foi definido em função da

disposição em que se encontram as tabelas, sendo a
tabela Fato centralizada no esquema e as tabelas de
Dimensões relacionadas nas pontas do esquema, de
forma independente entre as dimensões.
Sobre as principais vantagens do Esquema Estrela, julgue

os itens a seguir:
I. A presença de dados altamente redundantes,

considerando a desnormalização das tabelas
dimensionais dos dados, para se obter um melhor
desempenho em tempo de execução.
II.
As consultas ocorrem inicialmente na tabela Fato e
depois nas tabelas de Dimensões, assegurando a
precisão dos dados por meio de uma estrutura de
chaves que garante o acesso aos dados com melhor
desempenho.
127
III. A estrutura padronizada e regular do esquema é
bastante simples, faciliatando a apresentação, o
desempenho das consultas geradas e a compreensão
até mesmo de usuários finais que não estão adaptados
às estruturas de banco de dados.
IV. A flexibilidade da inclusão de novos elementos de dados,

a partir do relacionamento da tabela Fato com uma nova
tabela de Dimensão, e o acréscimo de novas colunas às
mesmas tabelas de Dimensões.
Estão corretos os itens:
a. I – II.
b. II – III.
c. III – IV.
d. I – III – IV.
e. I – II – III – IV.
BARBIERI, Carlos. BI – Business Intelligence: modelagem & tecnologia. Rio de
Janeiro: Axcel Books, 2001.
COLAÇO, M. Jr. Projetando sistemas de apoio à decisão baseados em data
warehouse. Rio de Janeiro: Axcel Books do Brasil, 2004.
Campus, 2004.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São
Paulo: Pearson Addison Wesley, 2005.
KIMBALL, R. et al. The data warehouse lifecycle toolkit. New York: John Wiley &
Sons, 1998.
KIMBALL, R.; ROSS, M. The data warehouse toolkit: the complete guide to
dimensional modeling. 3 ed. New York: John Wiley & Sons, 2013.
128
Erica, 2013.
POE, V.; KLAUER, P.; BROBST S. Building a data warehouse for decision support.
New Jersey: Prentice Hall PTR, 1998.
administração. 8. ed. São Paulo: Cengage Learning, 2011.
Gabarito
Resolução: A modelagem multidimensional representa uma
abstração dos dados armazenados, consistindo em um modelo
composto por tabelas Fato e de Dimensões, que proporcionam
uma visão multidimensional de grande quantidade de dados.
Fatos: é uma coleção de itens de dados composta de dados de
medidas, representando uma transação ou um evento de negócio.
Um fato é representado por valores numéricos em um esquema e
implementado em tabelas denominadas tabelas Fato.
Dimensões: são os elementos que participam de um fato, ou seja,

são as possíveis formas de visualizar os dados de forma descritiva e
classificatória, determinando o contexto de um assunto de negócio.
Os elementos que representam uma dimensão são especificados
em um esquema e implementados em tabelas denominadas de
tabelas de Dimensões.
Resolução: Segundo Kimball (1998), o Esquema Estrela (Star
Schema) é a abordagem que visa criar esquemas físicos mais
simples e incrementais. O nome estrela se dá devido à disposição
em que se encontram as tabelas, sendo a tabela Fato centralizada
129
no esquema e as tabelas de Dimensões relacionandas nas pontas
do esquema.
Questão 3 - Resposta D.
Resolução: Considerando a abordagem do Esquema Estrela da
modelagem multidimensional, o item II está errado, porque as
consultas ocorrem inicialmente nas tabelas de Dimensões e depois
nas tabelas Fato, para assegurar a consistência dos dados por meio
de uma estrutura de chaves, que garante o acesso aos dados com
melhor desempenho.
.
130
Ferramentas de Dados em um
Data Warehouse
Objetivos
• Conhecer e compreender os fundamentos do

Processamento Analítico On-line (OLAP).
• Conhecer e compreender as operações OLAP.
• Conhecer e compreender a classificação das

ferramentas OLAP.
1. Fundamentos sobre o Processamento Analítico
On-line (OLAP)
O número de usuários que precisa de análises de dados mais

sofisticadas vem crescendo nas organizações, indo além dos níveis
gerenciais mais altos. A viabilização e a extração eficazes de informações
de um ambiente de Data Warehouse (DW) para proporcionar essas
análises são possíveis a partir de ferramentas que disponibilizam
recursos avançados para suportar operações sobre o conjunto de dados
multidimensional, gerando consultas dinâmicas com interface intuitiva
para os usuários.
As ferramentas de apoio à decisão estão relacionadas com o conceito de

Business Intelligence (BI) – inteligência aplicada aos negócios –, que “refere-
se ao conjunto de tecnologias que permitem o cruzamento de informações
e suportam a análise dos indicadores de desempenho de um negócio”
(COLAÇO JR., 2004, p. 26). Pela maior popularidade do uso das ferramentas
de acesso a um DW, destacam-se as ferramentas Online Analytical
Processing (OLAP – Processamento Analítico On-line), termo criado como
tecnologia OLAP em 1993 por Edgar Frank Codd, matemático britânico que
desenvolveu o modelo de banco de dados relacional.
PARA SABER MAIS

Business Inteligence: de acordo com Barbieri (2001), esse
termo é referente a um “guarda-chuva” conceitual, visto que
se dedica à captura de dados, informações e conhecimentos
que permitam as empresas competirem com maior
eficiência em uma abordagem evolutiva de modelagem de
dados, capaz de promover a estruturação de informações
em depósitos retrospectivos e históricos, permitindo sua
modelagem por ferramentas analíticas.
132
Barbieri (2001) enfatiza que o termo Processamento Analítico On-line
representa a característica de se trabalhar os dados com operadores
dimensionais, possibilitando uma forma múltipla e combinada
de análise.
O OLAP desempenha análise multidimensional de dados empresariais

e oferece capacidades para cálculos complexos, análises de
tendências e modelagem de dados sofisticados. Ele habilita usuários
finais a fazerem análises de dados em múltiplas dimensões com
recursos diversos para visualização das informações, provendo o
entendimento de que eles necessitam para a melhor tomada de
decisão. Pode ser um processo simples, fácil, rápido, controlável e de
acesso à inteligência implícita nos dados.
Um processamento OLAP estrutura logicamente dados

multidimensionais na forma de um cubo, possibilitando que os
usuários finais visualizem os dados armazenados como um cubo de
dados, o qual apresenta várias dimensões, que são subconjuntos
de atributos. É interessante destacar que os cubos são estáticos, ou
seja, não estão sujeitos a alterações e devem ser criados antes de sua
utilização. No entanto, eles não podem ser criados por consultas ad
hoc. Em vez disso, a consulta é realizada em cubos pré-criados com
eixos definidos.
Date (2004) explica que o termo OLAP pode ser definido como o
processo interativo de criar, gerenciar, analisar e gerar relatórios
sobre dados. Os dados, então, são percebidos e manipulados como
se estivessem armazenados em um array multidimensional.
O OLAP proporciona acesso aos dados de um determinado negócio,

podendo o usuário obter uma compreensão que lhe ofereça
133
condições de melhor planejamento e gerenciamento. O arranjo em
cubos do OLAP permite analisar as múltiplas dimensões dos dados
utilizados pela empresa, em múltiplas combinações, sob ângulos
variados, podendo o executivo identificar também tendências e
descobrir o que está acontecendo nos negócios (BISPO, 1998).
As ferramentas que apresentam características OLAP passaram

a ser referenciadas como ferramentas OLAP. A maioria delas é
implementada para ambientes multiusuários em arquitetura Cliente-
Servidor, proporcionando resultados rápidos e consistentes às
consultas interativas executadas pelos usuários. Em um projeto de
implementação de uma ferramenta OLAP, pode haver a necessidade
de integração de dados de diferentes plataformas de bases de dados,
e, com isso, soluções de conectividade devem ser definidas. Consultas
complexas podem demandar respostas que requeiram flexibilidade e
performance, que se tornam possíveis pela modelagem dos dados.
Machado (2013) descreve que as ferramentas OLAP surgiram com

os sistemas de apoio à decisão para fazerem a consulta e a análise
dos dados dos DW, sendo as aplicações às quais os usuários têm
acesso para extrair os dados de suas bases e construir os relatórios
com recursos que atendam aos gestores. Por ser uma ferramenta
de processamento analítico on-line de dados, uma aplicação OLAP
soluciona vários problemas de análise e consolidação dos dados, com
capacidade de visualização das informações a partir de diferentes
perspectivas para os usuários estratégicos, utilizando-se de consultas
dinâmicas em tempo de execução do sistema.
A característica mais marcante das modernas ferramentas OLAP é a

capacidade de análise multidimensional. Os dados são processados
e visualizados em uma estrutura multidimensional, sendo
134
especialmente atrativos para os tomadores de decisões de negócios.
Enquanto o DW mantém os dados de suporte a decisões integrados,
orientados por assunto, variáveis no tempo e não voláteis, o sistema
OLAP fornece o front end por meio do qual os usuários finais acessam
e analisam esses dados (ROB; CORONEL, 2011).
Adicionalmente, é interessante observar que os sistemas OLAP são

projetados para utilizar os dados operacionais de DW, ou seja, um
sistema OLAP pode acessar os dados armazenados em um DW ou
os dados armazenados em um banco de dados operacional ou até
mesmo ambos, dependendo da implementação. Em qualquer caso, a
análise multidimensional de dados exige algum tipo de representação
de dados nessa mesma dimensão, o que normalmente é fornecido
pelo mecanismo de OLAP (ROB; CORONEL, 2011). Em contraste com
os sistemas Online Transaction Processing (OLTP – Processamento
de Transações On-line), as ferramentas OLAP destacam-se pelo
potencial de recuperação de grande volume de dados e pela análise
de informações de forma rápida e com diferentes perspectivas.
ASSIMILE
Online Transaction Processing (OLTP - Processamento

de Transações On-line): o termo refere-se aos sistemas
transacionais, que são utilizados no processamento dos
dados de rotina, gerados diariamente, a partir dos sistemas
informacionais de uma organização.
O Quadro 1 apresenta as principais diferenças entre os processamentos

OLAP e OLTP, segundo Barbieri (2001).
135
Quadro 1 – Diferenças entre OLAP e OLTP
OLAP OLTP
Baseado em dados
Baseado em transações de dados
históricos, consolidados e
atuais de funções repetitivas.
frequentemente totalizados.
Operações de manipulação de
Operações de agregação
dados individuais, por meio
e cruzamentos de dados
dos comandos de inserção,
sumarizados.
atualização e exclusão.
Atualizações quase inexistentes, Atualizações em grande
apenas novas inserções. número de registros.
Disponibiliza as informações sob Organiza os dados orientados

diferentes perspectivas do negócio. aos processos.
Codd, Codd e Salley (1993) descrevem que uma ferramenta OLAP deve
conter 12 critérios, relacionados a seguir:
1. Visão conceitual multidimensional: os dados são modelados em

diversas dimensões, possibilitando a extração de dados mais
intuitivos e o cruzamento de todos os tipos de dados para gerar
informações de fácil leitura e análise.
2. Dimensionalidade genérica: a ferramenta deve proporcionar
condições ao usuário para executar manipulações ou cálculos
entre as dimensões. Dessa forma, a estrutura básica dos dados e o
formato dos relatórios não devem ser influenciados por nenhuma
dimensão de dados.
3. Dimensões e níveis de agregação ilimitados: um modelo analítico
comum pode conter de 15 a 20 dimensões de dados. Paralelamente,
136
os níveis de agregação devem ser ilimitados, desde a mínima até a
máxima granularidade.
4. Operações dimensionais: considera-se um modelo analítico e
tomam-se duas ou mais células pertencentes a diferentes dimensões
dentro desse modelo para serem usadas na realização de cálculos.
5. Manipulação de matriz esparsa dinâmica: para qualquer matriz
esparsa de dados, existe um e somente um esquema físico, o qual
provê a máxima eficiência e operacionalidade, para maximizar o
desempenho, baseada na densidade dos dados armazenados.
6. Arquitetura cliente-servidor: a maioria dos dados é armazenada em
um servidor de rede e acessada por meio de computadores pessoais.
Portanto, é necessário que a ferramenta seja capaz de operar em um
ambiente cliente-servidor para atender a multiusuários.
7. Acessibilidade: a ferramenta tem que traçar seu próprio esquema
lógico para tratar os dados heterogêneos armazenados e, assim,
executar qualquer conversão necessária para apresentar ao usuário
uma única e consistente visão dos dados.
8. Transparência: a ferramenta deve atender a todas as solicitações
dos usuários, a partir de planilhas eletrônicas, aplicativos de
suporte à decisão ou outras interfaces. Se a ferramenta está em
uma arquitetura cliente/servidor, então os acessos devem ser
transparentes aos usuários.
9. Manipulação de dados intuitiva: todo o processo de criação de
modelos, manipulação de dados e realização de cálculos deve
acontecer da forma mais intuitiva para os usuários, sem necessitar de
nenhum tipo de auxílio.
10. Desempenho consistente de relatório: mesmo com o aumento do
número de dimensões ou do tamanho do banco de dados, o usuário
não deve perceber uma degradação significativa no desempenho do
fornecimento de informações.
137
11. Flexibilidade nas consultas: a análise e a apresentação dos dados
tornam-se mais simples quando linhas, colunas e células que vão ser
comparadas visualmente são organizadas por agrupamentos lógicos
para efetuarem qualquer tipo de consulta.
12. Suporte multiusuário: muitas vezes, vários usuários necessitam
trabalhar simultaneamente com o mesmo modelo analítico ou
criar modelos diferentes a partir dos mesmos dados. Assim, a
ferramenta tem que prover esses acessos simultâneos sem prejuízo
à integridade e à segurança dos dados.
2. Operações OLAP
Uma característica importante que deve estar presente em ferramentas

OLAP é a capacidade de efetuar algumas operações. Existem diversos
operadores OLAP que permitem acessar os dados em esquemas
multidimensionais. Cada operação sobre um conjunto de dados
multidimensional retorna uma apresentação ou sumarização diferente
de informações.
Em seguida, são apresentadas as principais operações realizadas

com cubos de dados. As operações do tipo Drill (Drill Down, Drill
Up, Drill Across e Drill Through) permitem a navegação ao longo dos
níveis hierárquicos de uma dimensão. As operações do tipo Slice and
Dice têm como objetivo realizar a navegação por meio dos dados na
visualização do cubo.
2.1 Drill Down
Essa operação ocorre quando o usuário aumenta o nível de detalhe da

informação, diminuindo a granularidade, ou seja, navega verticalmente,
descendo a hierarquia no sentido mais específico.
138
De acordo com Elmasri e Navathe (2011):
Uma exibição Drill-Down fornece uma visão mais detalhada”. Por exemplo,
desagregar “as vendas do país por região e, depois, as vendas regionais
por sub-região e também separando produtos por estilos. (ELMASRI;
NAVATHE, 2011, p. 724)
A Figura 1 mostra um exemplo de Drill Down:
Figura 1 – Exemplo de Drill Down
Volume de produção Telefone celular Tablet

(em milhar) 2017 2018 2017 2018
RS 35 29 18 21
Região Sul
SC 47 38 20 23
Drill Down
Dimensão localização geográfica
Membro RS

(em milhar) 2017 2018 2017 2018
Canoas 9 7 5 6
RS
Porto Alegre 12 11 6 8
No exemplo da Figura 1, uma operação de Drill Down acontece sobre

a dimensão localização geográfica. O primeiro quadro, localizado no
topo da figura, apresenta o volume de produção por região geográfica
e pelos estados dessa região. Ao realizar um Drill Down, abre-se o nível
139
de detalhe da dimensão localização geográfica, visualizando somente
um estado da região anterior (no exemplo, o RS – Rio Grande do
Sul), entretanto, abrindo os valores para as cidades desse estado (no
exemplo, Canoas e Porto Alegre) (MACHADO, 2013).
2.2 Drill Up ou Roll Up
Essa operação é o oposto do Drill Down e ocorre quando o usuário

aumenta o nível de granularidade, diminuindo o nível de detalhamento
da informação, ou seja, permite ao usuário uma visão mais agregada das
informações.
Elmasri e Navathe (2011) explicam que “uma exibição Roll-Up sobe

na hierarquia, agrupando em unidades maiores ao longo de uma
dimensão” (ELMASRI; NAVATHE, 2011, p. 723). Na concepção de Date,
Drill Up “significa ir de um nível mais baixo de agregação até um nível
mais alto” (DATE, 2004, p. 613). Por exemplo, mover de produtos
individuais para uma categorização maior dos produtos.
A Figura 2 mostra um exemplo de Drill Up, cuja operação está sendo

realizada sobre a dimensão tempo. O primeiro quadro, localizado no
topo da figura, apresenta o volume de produção global independente
de produtos na região Sul, nos estados do Rio Grande do Sul e de
Santa Catarina, distribuídos por trimestre em 2018. O segundo
quadro, localizado na parte inferior da figura, apresenta os mesmos
dados, mas somente de um dos trimestres, o primeiro. A operação de
sair do segundo quadro para o primeiro é uma Drill Up, pois o usuário
sai de um nível mais baixo de detalhe (um trimestre específico de
um ano) para um nível mais alto (todos os trimestres de um ano)
(MACHADO, 2013).
140
Figura 2 – Exemplo de Drill Up
Volume de produção 2018

(em milhar) 1ª Trimestre 2ª Trimestre 3ª Trimestre 4ª Trimestre
RS 12 12 11 15
Região Sul
SC 15 13 12 21
Drill Up
Dimensão tempo
Volume de produção 1ª Trimestre

(em milhar) Janeiro Fevereiro Março
RS 5 3 4
Região Sul
SC 7 4 4
É importante destacar que, apesar de alguns autores tratarem Drill Up e

Roll Up como sinônimos, Date (2004) argumenta que há uma diferença
sutil entre elas: Roll Up é a operação de criar os agrupamentos e as
agregações desejadas, enquanto Drill Up é a operação de acessar essas
agregações.
2.3 Drill Across
Essa operação permite navegar transversalmente no eixo da dimensão,

retirando ou inserindo posições da dimensão, ou seja, ocorre quando
o usuário pula um nível intermediário dentro da mesma dimensão. Por
exemplo, a dimensão tempo é composta por ano, semestre, trimestre,
mês e dia (MACHADO, 2013). A operação Drill Across é executada quando
141
o usuário passar de ano direto para trimestre ou mês. A Figura 3
apresenta um exemplo de Drill Across:
Figura 3 – Exemplo de Drill Across

(em milhar) 2017 2018 2017 2018
RS 35 29 18 21
Região Sul
SC 47 38 20 23
Drill Down
Dimensão localização geográfica
Membro RS

(em milhar) Janeiro 2017 Janeiro 2018 Janeiro 2017 Janeiro 2018
RS 5 3 2 2
Região Sul
SC 7 4 3 2
No exemplo da Figura 3, há dois quadros com o volume de produção.

O primeiro, localizado no topo da figura, mostra os valores antes de
executar um Drill Across. O segundo, localizado na parte inferior da
figura, mostra os valores após a execução de um Drill Across. Nesse
exemplo, foi executado um Drill Across de ano para mês (janeiro).
Notemos que, no primeiro quadro, os valores correspondem ao volume
de produção por ano (2017 e 2018). No segundo quadro, após executar
um Drill Across, os valores correspondem apenas ao volume de produção
do mês de janeiro de 2017 e 2018.
142
2.4 Drill Throught
Essa operação ocorre quando o usuário navega de uma informação

contida em uma dimensão para uma outra dimensão. Por exemplo,
quando o usuário está na dimensão de tempo e no próximo passo
começa a analisar a informação por região (MACHADO, 2013).
A Figura 4 mostra um exemplo de Drill Throught. O primeiro quadro,

localizado no topo da figura, apresenta a quantidade de produtos
vendidos por região e cidades, distribuídos por ano. O segundo
quadro, localizado na parte inferior da figura, apresenta a quantidade
de produtos vendidos por ano, mas distribuídos por lojas da cidade
de Porto Alegre, da região Sul. A operação de sair do primeiro para o
segundo é conhecida como Drill Throught, pois o usuário seleciona um
membro (cidade Porto Alegre) dentro de uma dimensão (região) e passa
a analisar uma outra dimensão (loja).
Figura 4 – Exemplo de Drill Throught

(em milhar) 2017 2018 2017 2018
Canoas 9 7 5 6
RS
Caxias do Sul 11 11 5 6
Pelotas 8 7 5 5
Drill Throught
Membro Porto Alegre

(em milhar) 2017 2018 2017 2018
Loja 18 2 2 1 1
Loja 19 3 2 1 2
Loja 20 4 5 3 3
Loja 21 3 2 1 2
143
2.5 Slice and Dice
Essas operações ocorrem para realizar a navegação por meio dos dados
na visualização de um cubo. Slice and Dice significa a redução do escopo
dos dados em análise, além da mudança da ordem das dimensões,
mudando assim a orientação com que os dados são visualizados.
Entretanto, Machado (2013) explica que Slice é:
A operação que corta o cubo, mas mantém a mesma perspectiva de

visualização dos dados, [ou seja], fatiar ou realizar Slice é a operação de
visualizar somente a produção de um tipo de produto, por exemplo,
celulares. (MACHADO, 2013, p. 89)
No exemplo da Figura 5, está sendo realizado um Slice sobre a

dimensão produto. O primeiro quadro, localizado no topo da figura,
apresenta o volume de produção de celulares e tablets na região Sul
nos dois últimos anos. O segundo quadro, localizado na parte inferior
da figura, apresenta os mesmos dados somente de celulares, ou seja,
apenas uma fatia dos dados. A operação de visualizarmos somente a
produção de um tipo de produto (celulares) é conhecida como Slice.
Figura 5 – Exemplo de Slice

Volume de produção Celulares e tablets
RS 12 10 8
Região Sul
SC 16 15 10
Slice
Dimensão produto
Membro Celulares
Volume de Produção Celulares

RS 8 5 5
Região Sul
SC 11 9 6
144
A operação Dice é utilizada para limitar o conjunto de valores a ser
mostrado, fixando-se algumas dimensões. Segundo Machado (2013),
Dice é “a mudança de perspectiva da visão”, ou seja, “é a extração de um
‘subcubo’ ou a interseção de vários Slices” (MACHADO, 2013, p. 90).
A Figura 6 mostra um exemplo da operação Dice. No primeiro quadro,

localizado no topo da figura, é possível visualizar o volume de produção
no sentido estado, cidade, ano, modelo de produto e produto, ou seja,
cada valor apresentado significa o volume produzido em um estado, em
uma cidade, em um ano, de um modelo de produto e de um produto.
No segundo quadro, localizado na parte inferior da figura, foi alterada
a perspectiva para modelo de produto, produto, ano, estado e cidade,
ou seja, cada valor agora representa a produção de um modelo de
produto e um produto, em um ano, em um estado e em uma cidade. O
objetivo desse tipo de análise é descobrir comportamentos conforme a
perspectiva de análise dos dados. (MACHADO, 2013).
Figura 6 – Exemplo de Dice

(em milhar) 2017 2018 2017 2018
RS
Canoas 9 7 5 6
Dice
Modelo CT1
Volume de produção
RS
(em milhar)
Canoas Porto Alegre
2017 9 12
Telefone celular
2018 7 11
2017 5 6
Tablet
2018 6 8
145
3. Classificação das ferramentas OLAP
As ferramentas OLAP podem ser classificadas de acordo com

a estratégia de armazenamento, sendo chamadas de OLAP
Multidimensional (MOLAP), OLAP Relacional (ROLAP), OLAP Híbrido
e OLAP Web.
O MOLAP refere-se à utilização de banco de dados com características

multidimensionais, permitindo a navegação com níveis de detalhamento
em tempo real, a partir da combinação das dimensões do cubo,
proporcionando análises sofisticadas com ótimo desempenho.
Segundo Machado (2013), em um banco de dados multidimensional, os
cruzamentos de valores são realizados automaticamente, agilizando a
visualização multidimensional das informações sob o ponto de vista de
todas as dimensões. A forma de acesso e de agregação dos dados faz
com que essa ferramenta tenha um excelente desempenho.
O ROLAP refere-se à utilização do banco de dados relacional para

implementar soluções OLAP. Segundo Colaço Jr. (2004):
Os sistemas ROLAP permitem análise multidimensional dos dados que

estão armazenados em uma base de dados relacional, podendo ser feito
todo o processamento no servidor da base de dados e depois gerados
os comandos SQL e as tabelas temporárias. De forma inversa podem ser
executados os comandos SQL para recuperação dos dados e posterior
processamento no servidor OLAP. (COLAÇO JR., 2004, p. 37)
A vantagem dessa ferramenta é a utilização de banco de dados

relacional, de arquitetura aberta e padronizada.
O ROLAP representa uma abordagem de uso combinado das duas

estratégias anteriores em que as estruturas relacionais são utilizadas
para os dados com maior granularidade, enquanto as estruturas
146
multidimensionais são utilizadas para dados com menor granularidade,
ou seja, nos dados agregados.
O WOLAP refere-se à utilização da ferramenta OLAP em ambiente

remoto, disparando consultas via um navegador web para o servidor,
que, por sua vez retorna o cubo processado para a análise do usuário.
A escolha de uma ferramenta OLAP envolve a análise dos recursos e

das funcionalidades que a ferramenta implementa, pois diferentes
ferramentas OLAP integram um conjunto de módulos que abrange
parcial ou totalmente as funcionalidades apresentadas no item anterior.
A seguir, é apresentada uma introdução da ferramenta CASE Microsoft
Analysis Services.
3.1 Microsoft Analysis Services
O Analysis Services é um gerenciador de informações que oferece ao

desenvolvedor e aos usuários estratégicos uma série de recursos
para auxiliarem o processo de análise de dados com uma visão
multidimensional com fácil interação e usabilidade. Ele disponibiliza
modelos de dados semânticos para relatórios de negócios compatíveis
com diferentes plataformas, como relatórios do Power BI, Excel,
relatórios de serviços e outras ferramentas de visualização de dados.
Ele está disponível nas plataformas Azure Analysis Services e SQL Server
Analysis Services (MICROSOFT, 2017).
O Analysis Services não precisa ser utilizado apenas com o SQL Server, é
possível utilizá-lo com qualquer banco de dados que possua um driver
Open Database Connectivity (ODBC) ou um Provider Object Linking and
Embedding for Databases (OLE DB). Assim, ele destaca-se com a vantagem
competitiva de custo zero.
Outro ponto importante a ser observado é a forma de armazenamento

dos dados. O Analysis Services permite que os dados sejam
147
armazenados em tabelas relacionais (ROLAP), em um cubo proprietário
multidimensional (MOLAP) ou na forma híbrida HOLAP.
Segundo Machado (2013), na opção ROLAP, os dados são lidos

diretamente da fonte de dados. Na opção MOLAP, os dados são
gravados em um formato proprietário, e, na opção HOLAP, é oferecida
uma combinação das duas opções anteriores, mas é o próprio Analysis
Services que gerencia quais agregações serão armazenadas como
MOLAP e quais serão ROLAP.
De acordo com a Microsoft (2017), o Analysis Services utiliza uma

linguagem criada pela Microsoft, conhecida como Multidimensional
Expressions (MDX), específica para manipulação de bases
multidimensionais. A linguagem MDX foi criada para atender a requisitos
que a SQL não supria. Sendo assim, quando são consultados os dados
de um cubo dentro do Analysis Manager ou por meio de uma planilha
Excel, é disponibilizada uma fatia do cubo (slice), que é caracterizada
pelos eixos do relatório (linhas e colunas) e pela sua paginação, ou seja,
são declarações MDX que estão sendo executadas.
O Microsoft Analysis Services oferece aos usuários um sofisticado

ambiente de análises, com boa performance, recursos avançados de
cálculo e, principalmente, autonomia para os usuários montarem seus
próprios relatórios.
As ferramentas que integram um ambiente de DW, como as

ferramentas OLAP e de Data Mining, surgiram para auxiliar o processo
de disseminação das informações, formando a base para os sistemas de
BI, a fim de que seja possível encontrar correlações de dados que antes
eram desconhecidas e transformar a informação em conhecimento.
148
As ferramentas OLAP disponibilizam o recurso para gerar consultas
dinâmicas com ótimo desempenho, permitindo que a partir de uma
resposta o usuário faça outras interações, combinando as dimensões do
cubo com diferentes níveis de detalhamento e agregação.
TEORIA EM PRÁTICA
Vamos tomar como base um Data Mart de vendas por brick

referente ao Data Warehouse (DW) organizacional de uma
indústria farmacêutica que precisa simular as vendas, por
categoria de produtos, realizadas para uma distribuidora,
por brick. Um brick representa uma cidade, um bairro ou um
CEP de um distrito com potencial de venda e, além disso,
pode ser mantido por nenhum ou por muitos vendedores.
Considerando essas informações:
1. 1. Elabore o esquema para compreender o fato Vendas

por brick, considerando as dimensões: categoria de produto,
brick e distribuidora. A dimensão categoria de produto
representa uma classificação dos produtos por categoria,
por exemplo: genérico, similar, OTC e outros; a dimensão
brick representa as regiões de venda, podendo ser uma
cidade, um bairro ou um CEP de um distrito; e a tabela
dimensão distribuidora representa as distribuidoras que
atendem às vendas da empresa.
2. 2. Em uma ferramenta com recursos OLAP, implemente

o esquema descrito no item anterior, contemplando
simulações do fato Vendas por brick.
149
1. O processo de tomada de decisão envolve grandes

esforços no sentido de coleta de informações e de uso
de métodos, técnicas e ferramentas computacionais,
requerendo muita consciência e habilidade por parte
dos gestores. A viabilização e extração eficaz de
informações de um ambiente de Data Warehouse (DW)
é possível a partir de ferramentas que disponibilizam
recursos avançados para suportar operações sobre o
conjunto de dados multidimensional.
Assinale a alternativa correta que descreve esse tipo de

ferramenta:
a. Online Transaction Processing (OLTP).

b. Online Analytical Processing (OLAP).
c. Business Intelligence (BI).
d. DataBase Management System (DBMS).
e. Extensible Markup Language (XML).
2. A Tecnologia da Informação tem uma grande

influência no desenvolvimento das atividades de
uma empresa. Manipular os dados coletados pelos
sistemas e transformá-los em informações é um grande
diferencial para a tomada de decisão, de forma a
agregar inteligência aos negócios. Em contraste com
os sistemas________________________, as ferramentas
________________________ destacam-se pelo potencial
de recuperação e capacidade de prover análise
multidimensional para o usuário.
150
Assinale a alternativa correta que indica os termos que
preenchem as lacunas:
a. Online Transaction Processing (OLTP); Business

Inteligence (BI).
b. Online Analytical Processing (OLAP); Online Transaction
Processing (OLTP).
c. Online Transaction Processing (OLTP); Online Analytical
Processing (OLAP).
d. Online Analytical Processing (OLAP); Business
Inteligence (BI).
e. Business Intelligence; DataBase Management
System (DBMS).
3. As ferramentas que apresentam características OLAP

passaram a ser referenciadas como ferramentas OLAP.
Uma característica importante que deve estar presente
nessas ferramentas é a capacidade de efetuar operações
que permitem acessar os dados em esquemas
multidimensionais.
Assinale a alternativa correta que indica

operações OLAP:
a. Drill Down, Drill Up; Slice; Dice.

b. Drill Down, Drill Up, Drill Rolap; Drill Molap.
c. Drill Rolap; Drill Molap; Slice; Dice.
d. Slice; Dice; Roll Up; Molap.
e. Drill Across, Drill Throught; Drill Rolap;
Drill Molap.
151
BARBIERI, Carlos. BI – Business Intelligence: modelagem & tecnologia. Rio de
Janeiro: Axcel Books, 2001.
BISPO, Carlos Alberto Ferreira. Uma análise da nova geração de sistemas de
apoio à decisão. 1998. 174 f. Dissertação (Mestrado em Engenharia da Produção) –
Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos. 1998.
CODD, Edgar F. & CODD, Sharon B.; SALLEY, Clynch T. Providing OLAP (on-
line analytical processing) to user-analysts: An IT mandate. v. 32. Codd and
Date, 1993.
Campus, 2004.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São
Paulo: Pearson Addison Wesley, 2005.
Erica, 2013.
MICROSOFT DEVELOPER NETWORK. O que há de novo no SQL Server 2017
Analysis Services: documentação do produto. Disponível em: <https://docs.
microsoft.com/pt-br/sql/analysis-services/what-s-new-in-analysis-services?view=sql-
server-2017>. Acesso em: 30 maio 2019.
Gabarito
Resolução: Machado (2013) descreve que as ferramentas OLAP
surgiram com os sistemas de apoio à decisão para fazerem a
consulta e a análise dos dados do DW, sendo as aplicações às
quais os usuários têm acesso para extrair os dados de suas bases e
construir os relatórios com recursos que atendam aos gestores.
Segundo Rob e Coronel (2011), a característica mais marcante
das modernas ferramentas OLAP é a capacidade de análise
152
multidimensional. Os dados são processados e visualizados em
uma estrutura multidimensional, sendo especialmente atrativos
para os tomadores de decisões de negócios. Enquanto o DW
mantém dados de suporte a decisões integrados, orientados por
assunto, variáveis no tempo e não voláteis, o sistema OLAP fornece
o front end por meio do qual os usuários finais acessam e analisam
esses dados.
Resolução: Online Transaction Processing (OLTP – Processamento de
Transações On-line): o termo refere-se aos sistemas transacionais,
que são utilizados no processamento dos dados de rotina,
gerados diariamente, a partir dos sistemas informacionais de uma
organização.
Online Analytical Processing (OLAP – Processamento Analítico Online):
desempenha a análise multidimensional de dados empresariais
e oferece capacidades para cálculos complexos, análises de
tendências e modelagem de dados sofisticados. O OLAP habilita
usuários finais a fazerem análises ad hoc de dados em múltiplas
dimensões, provendo, dessa forma, o insight e o entendimento que
eles necessitam para a melhor tomada de decisão.
Questão 3 - Resposta A.
Resolução: Existem diversas operações OLAP que permitem
acessar os dados em esquemas multidimensionais. Cada
operação sobre um conjunto de dados multidimensional retorna
uma apresentação ou sumarização diferente de informações.
As operações do tipo Drill (Drill Down, Drill Up, Drill Across e Drill
Throught) permitem a navegação ao longo dos níveis hierárquicos
de uma dimensão. As operações do tipo Slice and Dice são
operações para realizar a navegação por meio dos dados na
visualização do cubo.
153
Mineração de Dados em Data
Warehouse
Objetivos
• Conhecer e compreender o processo de Descoberta

de Conhecimento em Bases de Dados (Knowledge
Discovery in Databases – KDD).
• Conhecer e compreender os fundamentos sobre

mineração de dados (Data Mining);
• Conhecer e compreender técnicas de Data Mining.

1. Processo de Descoberta de Conhecimento em
Bases de Dados
Muitas organizações estão dispondo de tecnologias de análise de dados

para auxiliarem na descoberta de padrões de dados e suas relações. As
ferramentas de mineração de dados (Data Mining) podem ser integradas
aos ambientes de Data Warehouse (DW), ou utilizadas com outros tipos
de armazenamento de dados, para obterem informações e, assim,
gerarem conhecimento sobre as operações realizadas pelos sistemas
transacionais que mantêm imensas quantidades de dados armazenados
ao longo dos anos.
A mineração de dados é somente uma parte do processo de exploração,

descoberta e transformação da informação em conhecimento, fazendo
parte de um processo maior conhecido como Knowledge Discovery in
Databases (KDD – Descoberta de Conhecimento em Bases de Dados).
Ele passou a ser reconhecido no mercado em 1989 como referência ao
processo de encontrar conhecimento útil em grandes bases de dados,
enquanto a mineração de dados refere-se à aplicação de algoritmos
para extrair modelos e relações de dados (FAYYAD et al., 1996).
O processo de KDD contempla um conjunto de atividades contínuas

que compartilham o conhecimento descoberto a partir de bases de
dados em cinco etapas: seleção dos dados, pré-processamento dos
dados, transformação dos dados, mineração dos dados e interpretação
dos resultados, como ilustra a Figura 1. Brachman e Anand (1994)
enfatizam que as etapas do processo KDD são interativas e iterativas.
Interativas, porque envolvem a cooperação e a habilidade dos usuários
responsáveis pela análise de dados durante a execução do processo;
e iterativas, porque podem envolver repetidas seleções de parâmetros
e conjunto de dados à aplicação das técnicas de mineração de dados
e, posteriormente, à análise e interpretação dos resultados obtidos,
refinando e detalhando os conhecimentos extraídos das bases de dados.
155
Figura 1 – Etapas do Processo KDD
Fonte: adaptada de Fayyad et al. (1996, p. 84).
Conforme mostra a Figura 1, na primeira etapa, Seleção de Dados,

considera-se que, a partir do entendimento do domínio da aplicação a
ser explorada, são identificadas as bases de dados a serem utilizadas
para a descoberta de conhecimentos, em conformidade com os
objetivos a serem atingidos. Na segunda etapa, Pré-Processamento
de Dados, é feito o agrupamento organizado dos dados de uma ou
mais bases de dados e realizada a limpeza dos dados, identificando e
resolvendo problemas de integridade, inconsistências e adaptação dos
dados ao formato desejado. Essa etapa pode despender até 80% do
tempo necessário do processo em função das dificuldades de integração
de dados heterogêneos; por exemplo, a forma de armazenamento de
dados discretos, como o sexo do cliente, que pode ter sido armazenado
em uma base de dados como “M” e “F” e, em outra, como “0” e “1”.
Na terceira etapa do processo KDD, Transformação de Dados, os

dados pré-processados são transformados para serem armazenados
adequadamente em DW, de modo a torná-los compatíveis com o uso
das técnicas de mineração de dados. A quarta etapa, Mineração de
156
Dados, é considerada a principal atividade do processo KDD, em que
define-se e aplica-se uma ou mais técnicas (redes neurais, árvores
de decisão, sistemas baseados em regras e programas estatísticos)
adequadas de mineração de dados, em conformidade com o domínio
do problema, ou seja, as técnicas que melhor se adaptam ao contexto
do negócio.
A última etapa, Interpretação dos Resultados, consiste na análise e

interpretação das informações com os padrões de dados descobertos,
induzindo e proporcionando, dessa forma, a geração de conhecimento
aos analistas de negócio e demais profissionais estratégicos. Não sendo
satisfatórios os resultados esperados, retorna-se a qualquer uma das
etapas anteriores de forma interativa e iterativa, iniciando um novo
processo de descoberta de conhecimento em bases de dados.
Colaço Jr. (2004) enfatiza que o processo KDD é interativo e

semiautomático, considerando que a interação com o usuário é
indispensável desde a definição dos dados a serem analisados a até
a análise e interpretação do conhecimento gerado. Além disso, se a
organização já possui banco de dados integrados e/ou DW, precisará
aproveitar as estruturas existentes. Ainda, Lemos, Steiner e Nievola
(2005) reforçam que a etapa de mineração de dados é a mais importante
do processo KDD e, no contexto de negócios, é a fase que apoia os
usuários estratégicos a descobrirem oportunidades de mercado e
soluções inteligentes e inovadoras.
2. Fundamentos sobre mineração de dados

(Data Mining)
No cenário competitivo dos negócios, ferramentas de mineração

de dados são utilizadas nos diferentes segmentos do mercado para
sustentar e consolidar estratégias que auxiliem no processo de tomada
157
de decisão, automatizando a detecção de padrões relevantes de grandes
bases de dados das organizações a partir da utilização de técnicas
estatísticas e de inteligência artificial, que extraem informações úteis,
valiosas e previamente desconhecidas, para construir modelos que
predizem comportamentos, tendências desconhecidas dos dados,
correlações das informações, entre outros aspectos mensuráveis que
apoiam as necessidades dos negócios.
Na concepção de Date (2004), a Data Mining pode ser descrita como

“análise de dados exploratória. O objetivo é procurar padrões
interessantes nos dados – padrões que possam ser usados para definir a
estratégia do negócio ou para identificar um comportamento incomum”
(DATE, 2004, p. 614). Já de acordo com Silberschatz, Korth e Sudarshan
(2006), Data Mining refere-se ao processo de analisar grandes bancos
de dados de forma semiautomática para encontrar regras e padrões
úteis a partir dos dados, lidando com a descoberta de conhecimento nos
bancos de dados.
Ainda, Laudon e Laudon (2014) enfatizam que o conceito de Data Mining

pode ser definido como o processo de descoberta de novas correlações,
padrões e tendências entre as informações de uma empresa, a partir da
análise de grandes quantidades de dados armazenados em um banco
de dados, usando técnicas de reconhecimento de padrões, estatísticas e
matemáticas. Para Rob e Coronel (2011):
A mineração de dados refere-se às atividades que analisam os dados,

descobrem problemas e oportunidades ocultas em seus relacionamentos,
formam modelos computacionais com base nessas descobertas e, então,
utilizam esses modelos para prever o comportamento do negócio – exigindo
a mínima intervenção do usuário final. (ROB; CORONEL, 2011, p. 580)
A inteligência de mercado exige soluções que agreguem valor aos

negócios que possibilitem o acesso e o processo de apresentação
das informações para sustentar descobertas e análises de dados com
158
visão sistêmica. Assim, a mineração de dados pode ser adotada como
uma solução para apoiar a tomada de decisões nas diversas áreas e
segmentos, como em empresas bancárias e de cartões de crédito, que
utilizam a análise baseada em conhecimento para detectar fraudes nas
transações financeiras; para prever eventos e projeções de valores,
como retornos de vendas; para identificar padrões de compras dos
clientes e resolver situações que envolvam negociação com clientes;
para aprimorar o desenvolvimento e a aceitação de produtos lançados
ou novos produtos; para analisar as perspectivas do mercado de ações;
para avaliar os clientes e precificar as apólices de seguro; para apoiar a
gestão de compliance; e muitas outras áreas de negócio.
PARA SABER MAIS

Visão sistêmica: consiste na habilidade de compreender
o todo a partir de uma análise global das partes e da
interação entre estas, ponderando os diversos elementos
que influenciam seu funcionamento, o que inclui fatores
internos e externos. A visão sistêmica é formada a partir
do conhecimento do conceito e das características
dos sistemas.
Rob e Coronel (2011) enfatizam que a mineração de dados é proativa,

ou seja, as ferramentas buscam automaticamente identificar anomalias
e possíveis relacionamentos entre os dados, identificando problemas
ainda não identificados pelos usuários estratégicos, para, dessa forma,
prover o conhecimento e aplicá-lo às necessidades dos negócios. A
mineração de dados contempla quatro fases básicas, exemplificadas
na Figura 2.
159
A fase de preparação de dados ilustrada na figura como a primeira
etapa do processo de mineração de dados refere-se à identificação dos
principais conjuntos de dados e do tratamento de limpeza e integração
desses dados a serem utilizados pela operação de mineração de dados,
considerando que os dados de DW já estão integrados e filtrados, a
partir dos dados operacionais oriundos dos sistemas transacionais.
A fase de análise e classificação de dados, ilustrada na figura como a

segunda etapa do processo de mineração de dados, refere-se à etapa de
estudo dos dados para identificar características e padrões comuns com
a aplicação de algoritmos das ferramentas de Data Mining, encontrando,
assim, análises de agrupamentos, classificações e grupos de dados;
vínculos ou dependências entre os dados; e padrões, tendências e
desvios de dados.
Figura 2 – Fases básicas do processo de mineração de dados
Fonte: adaptada de Rob e Coronel (2011).
A fase de aquisição de conhecimento ilustrada na figura como a terceira

etapa do processo de mineração de dados refere-se à seleção dos
algoritmos mais comuns de modelagem e aquisição de conhecimentos,
160
baseados em redes neurais, lógica indutiva, árvores de decisão,
classificação ou regressão etc., e a definição desses algoritmos com
possível interação dos usuários finais.
A fase de prognóstico, ilustrada na figura como a quarta e última

etapa do processo de mineração de dados, refere-se às descobertas
de mineração de dados para preverem o comportamento futuro e
projetarem resultados de negócios, como o provável lançamento de um
produto novo ou de uma campanha de marketing. Contudo, algumas
ferramentas de Data Mining não contemplam recursos para essa fase.
De acordo com Barbieri (2001), as ferramentas Online Analytical

Processing (OLAP – Processamento Analítico On-line) objetivam trabalhar
os dados existentes, buscando consolidações em vários níveis e tratando
fatos em dimensões variadas, enquanto as ferramentas de Data Mining
buscam algo mais que a interpretação dos dados existentes e visam
essencialmente realizar inferências, tentando descobrir possíveis fatos e
correlações não explicitadas nos dados de um DW.
A mineração de dados é comumente classificada pela sua capacidade

em realizar tarefas para diferentes domínios. A literatura indica que
não existe um consenso de denominação quanto à classificação, às
funcionalidades, às tarefas, aos métodos ou às técnicas de mineração de
dados. Contudo, Fayyad et al. (1996) apresentam os seguintes métodos
de mineração de dados, que têm como objetivo a predição ou descrição
dos resultados:
a. Classificação: refere-se à tarefa de classificação, sendo uma

das tarefas mais importantes e mais populares das análises
discriminantes de bases de dados. Na classificação, o modelo
analisa o conjunto de dados fornecido, associando ou classificando
um item a uma ou a várias categorias pré-definidas e derivando
uma regra que possa ser usada para classificar uma observação,
referente a um conjunto de dados identificados categorizados
161
por um assunto. Aplica-se em diversas áreas da saúde, como no
diagnóstico médico, visando classificar os pacientes e os tipos de
doenças; na área financeira, para avaliação de risco de crédito etc.
b. Regressão: refere-se à tarefa similar à classificação, porém
é usada quando os dados são identificados por predição de
valores numéricos, considerados variáveis independentes ou
exploratórias, e não pela categorização dos itens analisados.
Assim, é possível verificar o eventual relacionamento funcional que
possa existir entre duas ou mais variáveis quantitativas. Observa-
se que a diferença básica entre o relacionamento entre variáveis
e o método de classificação é que naquele a tarefa estimada lida
com resultados discretos, enquanto o de classificação lida com
resultados contínuos. É usada principalmente na área de vendas e
marketing.
c. Agrupamentos (Clusters): refere-se à tarefa de segmentar
um conjunto de dados em grupos diferentes cujos itens são
semelhantes, ou seja, subdivide o conjunto de dados em um
conjunto menor, sendo similar no comportamento dos atributos
de segmentação. A partir da mineração de dados, são descobertos
grupos diferentes entre o conjunto de dados selecionado,
diferentemente do método de classificação, em que as classes
de categorias são pré-definidas. São usados em problemas
relacionados ao processo de linha de produção, por exemplo, para
detecção de defeitos de fabricação.
d. Sumarização: refere-se à tarefa de descrever padrões e
tendências, que são reveladas por subconjuntos de dados
compactados. Funções mais sofisticadas envolvem técnicas de
apresentação e visualização, que facilitam a interpretação dos
resultados, como no formato de histogramas e diagramas de
dispersão. Isso é possível a partir da geração automática de
relatórios que demostram uma descrição compacta para um
162
subconjunto de dados com características similares, demostrando,
assim, as relações funcionais entre as variáveis definidas para
a análise exploratória do subconjunto de dados. É usada em
aplicações de diferentes domínios, como para identificar o
perfil dos clientes de uma operadora de telefonia que residem
em determinada região e identificar o perfil dos clientes de
e-commerce para direcionar ofertas de produtos.
e. Regras de Associação: refere-se à tarefa de identificar as regras
de associação entre variáveis que ocorrem juntas em conjuntos
de dados para estudar, principalmente, preferências e afinidades,
orientar análises e investigações, visando principalmente definir
oportunidades na área de marketing. Uma regra de associação
é definida como se X então Y, ou X ⇒ Y, onde X e Y são conjuntos
de itens e X ∩ Y = ∅. Por exemplo, um modelo de análise de
associação poderia descobrir que um cliente em 65% das vezes,
ao comprar um produto X, também compra o produto Y. Esse
é o exemplo clássico de uma grande rede de supermercados
norte-americana, o Wall Mart, que descobriu que um número
razoável de homens comprava as fraldas e também as cervejas
na véspera de finais de semana. De acordo com a história, a partir
dessa análise de associação entre os dois produtos, a rede de
supermercados utilizou o novo conhecimento para aproximar as
gôndolas desses produtos, incrementando a venda conjunta das
fraldas e das cervejas.
f. Análise de Séries Temporais: refere-se à tarefa similar à regra
de associação com objetivo de aplicar algum tipo de padrão
(tendências, variações sazonais, variações cíclicas e variações
irregulares) no conjunto de dados, para determinar que tipos
de sequências podem ocorrer em um determinado período, ou
seja, sequencial no tempo. Como exemplo, a análise temporal de
ocorrências e frequência de abalos sísmicos em uma determinada
região; na área de vendas, é comum analisar a frequência que
um cliente adquire um produto ou que, a partir da compra de um
163
produto, ele retorna após um período de tempo para comprar um
outro produto relacionado.
ASSIMILE
Machine Learning (Aprendizado de máquina): é uma área
da ciência da computação que significa aprendizagem de
máquina ou aprendizado automático. Ela evoluiu do estudo
de reconhecimento de padrões em dados e da teoria da
aprendizagem computacional em inteligência artificial,
permitindo que sistemas aprendam e tomem decisões com
o mínimo de intervenção humana.
3. Técnicas aplicadas em Data Mining
Um conjunto de técnicas de natureza estatística e de inteligência

artificial evoluiu ao longo das décadas, adaptando-se com as técnicas de
aprendizado de máquina, a partir da década de 1990, e constituindo, assim,
as características das ferramentas de Data Mining (BARBIERI, 2001).
Não existe uma técnica de mineração de dados que possa ser

considerada melhor que outra. O sucesso da aplicação de Data Mining
depende muito da experiência, sensibilidade e expertise do analista
de negócio, o qual terá que identificar qual a melhor ferramenta a ser
utilizada, considerando como e onde os dados estão armazenados,
bem como qual método será adotado para gerar o conhecimento
pretendido. A seguir, estão descritas algumas técnicas que são adotadas
na implementação dos processos das ferramentas de Data Mining,
em conformidade com as características dos métodos de mineração,
segundo Barbieri (2001).
164
a. Árvores de Decisão (Decision Tree): as árvores de decisão
caracterizam-se pelo método de classificação de dados, sendo
conveniente adotar essa técnica quando o objetivo é gerar regras
que possam ser entendidas, explicadas e traduzidas para a
linguagem natural. A árvore de decisão é uma técnica que, a partir
de uma massa de dados, cria e organiza regras de classificação
e decisão em formato de diagramas de árvores, que classificam
suas observações ou predizem classes baseadas nos valores dos
atributos de um conjunto de dados.
b. Redes neurais: as redes neurais artificiais tentam construir
representações internas de modelos ou padrões detectados
nos dados que envolvem o desenvolvimento de estruturas
matemáticas com habilidade de aprendizado, por meio de
experiências de operações da própria máquina. As redes neurais
utilizam um conjunto de elementos de processamento, também
chamados de nós e links, análogos aos neurônios. Os elementos
são interconectados em uma rede que implementa detecções
sofisticadas de padrões e algoritmos de aprendizado de máquina,
construindo modelos de dados. Aplicações de redes neurais estão
sendo adotadas principalmente nos campos da medicina, da
ciência e dos negócios.
c. Algoritmos Genéticos: são utilizados para encontrar soluções
de problemas dinâmicos e complexos que envolvem centenas
ou milhares de variáveis e/ou fórmulas para identificar as
descobertas, gerando possíveis soluções simultaneamente.
As técnicas são baseadas em métodos inspirados na biologia
evolucionária, como herança, mutação, seleção e cruzamento,
capazes de realizar pesquisas adaptativas e robustas para o
domínio explorado, principalmente na área de análise de imagens
e projetos de engenharia.
d. Análise de Aglomerações (Cluster Analysis): a técnica de
análise de aglomeração ou clusterização identifica a existência de
diferentes grupos dentro de um conjunto de dados. Constatada
essa existência, agrupam-se os elementos estudados de acordo
165
com suas similaridades, podendo refiná-los e definir a priorização
entre eles.
e. Análise de Regressão: a técnica de análise de regressão processa
os dados das bases de dados de maneira a determinar um
modelo/equação que represente o relacionamento existente
entre as variáveis em estudo, ajustando uma linha reta em uma
nuvem de pontos de dados e decidindo qual reta é a melhor
representação de todas as observações consideradas de tarefas
de sumarização, predição e estimativa. Os resultados de uma só
análise podem atender a mais de um objetivo proposto.
f. Predição com Séries Temporais: a técnica de predição com
séries temporais de tempo, espaço físico ou volume é utilizada
principalmente no cálculo de previsão de um conjunto de
observação, dados seus valores ao longo do tempo, utilizando-
os na predição de valores futuros da série em questão. Assim, é
possível armazenar as informações das variáveis ao longo de um
período, permitindo que sejam observadas repetidamente em
ciclos distintos.
As técnicas do Data Mining têm sido frequentemente aplicadas com

sucesso para a solução em diversas áreas, por exemplo:
• Saúde e medicina: identificar tratamentos de sucesso para

os diferentes diagnósticos de doenças; prever qual perfil
de pacientes que apresentam maior probabilidade de
desenvolverem doenças; identificar práticas assertivas que
melhorem o atendimento e otimizem os custos; identificar e
prever doenças a partir da análise de imagens.
• Mercado financeiro: prever as oscilações das ações na bolsa
de valores decorrentes do cenário econômico nacional ou
internacional; prever e detectar fraudes no uso de cartões de
crédito; prever análises de créditos aos clientes.
• Vendas: identificar padrões de comportamento dos
consumidores; identificar clientes que possam migrar para o
166
concorrente e tentar retê-los; analisar cestas de mercado a
partir das associações entre produtos adquiridos; encontrar
características dos consumidores em função da região
demográfica em que vivem; prever quais consumidores serão
atingidos nas campanhas de marketing.
• Seguros e planos de saúde: detectar procedimentos médicos
requisitados ao mesmo tempo; identificar comportamentos
fraudulentos dos segurados; prever quais consumidores têm
tendência a comprar novas apólices.
• Telecomunicação: classificar clientes de acordo com seu
potencial de compra de serviços; identificar fraudes em ligações
telefônicas.
• Transporte: determinar a distribuição de trajetos e horários
decorrentes das atividades diárias ou sazonais dos passageiros;
analisar padrões de sobrecarga; definir a maneira mais
produtiva com otimização de custos dos itinerários de frotas
de veículos.
Muitas ferramentas modernas de Data Mining oferecem recursos

visuais que mostram os dados multidimensionais em telas
bidimensionais, associando os registros de dados ou conjuntos
de registros de dados a uma série de atributos visuais de fácil
usabilidade e compreensão aos usuários, assim combinando
as complexas demonstrações visuais com controles de seleção
interativa. A Figura 3 mostra algumas interfaces de uma ferramenta
de Data Mining, o software TIBCO Spotfire Desktop, que contempla uma
plataforma para exploração de dados com diferentes representações
e perspectivas para a análise dos dados.
As quatro interfaces visuais do software TIBCO Spotfire Desktop,

demonstradas na Figura 3, possuem uma série de recursos para
configurar os atributos quanto à forma, à cor, ao brilho, à rotação,
ao tamanho, ao posicionamento, ao reposicionamento e à varredura,
167
ilustrando o resultado por meio de gráficos multidimensionais e
facilitando, assim, a navegação interativa do usuário e as análises e
interpretação dos resultados.
Figura 3 – Interfaces do Software TIBCO Spotfire Desktop
Fonte: <https://software.com.br/p/tibco-spotfire-desktop>. Acesso em: 18 jun. 2019.
As técnicas estatísticas aplicadas à análise analítica dos dados estão

cada vez mais sofisticadas, auxiliando as organizações na transformação
de dados e informações em conhecimento para, assim, apoiarem a
construção de estratégias inteligentes e, com isso, proporcionarem
inteligência de mercado e inteligência competitiva.
168
Ferramentas de mineração de dados são integradas aos ambientes
de DW ou a outros tipos de armazenamento para transformarem
informações em conhecimento potencialmente útil. Sua função principal
é a extração de grande volume de dados com o objetivo de encontrar
padrões e correlações significativas e de estimar tendências e novas
perspectivas que agreguem satisfatoriamente ao contexto do negócio
explorado.
TEORIA EM PRÁTICA
Considere o contexto de uma agência financeira que
disponibiliza linha de crédito para seus clientes do tipo
microempreendedores individuais e para microempresas
que precisam de crédito para investimento. Ela necessita
adotar uma ferramenta de mineração de dados para apoiar
suas decisões de conceder ou não o crédito de investimento
a esses clientes. De acordo com os métodos e as técnicas
de Data Mining, definiu-se para especificar essa solução o
método de classificação e a técnica de Árvore de Decisão
com duas possíveis classes: “Sim” – adimplente/receber
crédito e “Não” – inadimplente/não receber crédito; e os
seguintes atributos: A) existência de restrições em nome
da empresa – valores: 1 = Sim e 2 = Não; B) tempo de conta
com a agência – valores: 1 = de 0 a 12 meses, 2 = de 13 a 24
meses e 3 = mais de 24 meses; e C) Tempo de Atividade –
valores: 1 = menos de um ano, 2 = de 1 a 3 anos e 3 = mais
de 3 anos.
Assim, represente o diagrama de Árvore de Decisão
com o intuito de facilitar a leitura e compreensão dos
usuários que usarão a aplicação, conforme os atributos
e as duas classes de resultado estipuladas e de acordo
169
com as seguintes regras de classificação do tipo
“se-então”:
Regras:
1. Se Restrição = 2 e Tempo de conta ≥2 e Tempo de atividade
≥2,então Adimplente.
2. Se Restrição = 1 e Tempo de conta =2 e Tempo de

atividade=3,então Adimplente.
3. Se Restrição = 1 e Tempo de conta = 3 e Tempo de atividade

≥2,então Adimplente.
1. As técnicas e ferramentas de armazenamento de

dados buscam transformar dados e informações em
conhecimento. A mineração de dados é somente
uma parte do processo de exploração, descoberta
e transformação da informação em conhecimento,
fazendo parte de um processo maior, conhecido como
____________________________.
Assinale a alternativa que indica o termo que

preenche a lacuna:
a. Online Transaction Processing (OLTP).

b. Online Analytical Processing (OLAP).
c. Business Intelligence (BI).
d. DataBase Management System (DBMS).
e. Knowledge Discovery in Databases (KDD).
170
2. O processo conhecido como Knowledge Discovery in
Databases (KDD – Descoberta de Conhecimento em
Bases de Dados), que passou a ser reconhecido no
mercado em 1989 como referência ao processo de
encontrar conhecimento útil em grandes bases de
dados, é constituído por um conjunto de atividades
contínuas que compartilham o conhecimento
descoberto a partir de bases de dados em cinco etapas.

Assinale a alternativa correta que indica as
etapas do KDD:
a. Seleção das bases de dados, processamento dos

dados, migração dos dados para Data Warehouse,
mineração dos dados e validação dos dados.
b. Seleção dos dados, pré-processamento dos dados,
transformação dos dados, mineração dos dados e
interpretação dos resultados.
c. Diagnóstico dos dados, seleção dos dados, análise
dos dados, interpretação dos dados e validação dos
resultados.
d. Levantamento dos requisitos, análise dos dados,
projeto dos dados, implementação dos dados e teste
com os dados.
e. Análise dos dados, projeto das informações,
mineração dos dados, implementação dos algoritmos
e Interpretação dos resultados.
3. A mineração de dados é comumente classificada pela

sua capacidade de realizar tarefas para diferentes
domínios. Fayyad et al. (1996) apresentam os métodos
de mineração de dados que têm como objetivo a
predição ou descrição dos resultados. Considerando
a aplicabilidade dos diferentes métodos, assinale a
171
alternativa que apresenta as características do método
de Classificação.
a. Usa-se quando os dados são identificados por

predição de valores numéricos, consideradas as
variáveis independentes ou exploratórias, e não
pela categorização dos itens analisados, sendo
possível verificar o eventual relacionamento funcional
que possa existir entre duas ou mais variáveis
quantitativas.
b. Usa-se para segmentar um conjunto de dados em
grupos diferentes cujos itens são semelhantes,
ou seja, subdivide o conjunto de dados em um
conjunto menor, sendo similar no comportamento
dos atributos de segmentação, descobrindo grupos
diferentes entre o conjunto de dados selecionado.
c. Usa-se para associar um item a uma ou a várias
categorias pré-definidas, derivando uma regra que
possa ser usada para classificar uma observação,
referente a um conjunto de dados identificados que
são categorizados por um assunto.
d. Usa-se para descrever padrões e tendências que são
reveladas por subconjuntos de dados compactados,
a partir de um subconjunto de dados com
características similares, demostrando as relações
funcionais entre as variáveis definidas para a análise
exploratória do subconjunto de dados.
e. Usa-se para aplicar algum tipo de padrão (tendências,
variações sazonais, variações cíclicas e variações
irregulares) no conjunto de dados, para determinar
que tipos de sequências podem ocorrer em um
determinado período, ou seja, sequencial no tempo.
172
BARBIERI, C. BI – Business Intelligence: modelagem & tecnologia. Rio de Janeiro:
Axcel Books, 2001.
BRACHMAN, R. J.; ANAND, T. The process of knowledge discovery in databases:
a first sketch. In: FAYYAD, U. M. et al. Advances in Knowledge Discovery in
Databases. Menlo Park: AAAI Press, 1994.
Campus, 2004.
FAYYAD, U. M. et al. Advances in knowledge discovery and data mining.
California: AAAI Press, 1996.
LAUDON, K. C. & LAUDON, J. P. Sistemas de informação gerenciais. 11. ed. São
Paulo: Pearson Prentice Hall, 2014.
LEMOS, E. P.; Steiner, M. T. A; Nievola, J. C. Análise de crédito bancário por meio de
redes neurais e árvores de decisão: uma aplicação simples de data mining. Revista
de Administração, São Paulo, v. 40, n. 3, p. 225-234, jul./set. 2005.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. 5. ed.
Rio de Janeiro: Elsevier, 2006.
Gabarito
Resolução: A mineração de dados é somente uma parte do
processo de exploração, descoberta e transformação da informação
em conhecimento, fazendo parte de um processo maior conhecido
como Knowledge Discovery in Databases (KDD – Descoberta de
Conhecimento em Bases de Dados), que passou a ser reconhecido
no mercado em 1989 como referência ao processo de encontrar
conhecimento útil em grandes bases de dados, enquanto a
mineração de dados refere-se à aplicação de algoritmos para
extrair modelos e relações de dados (FAYYAD et al., 1996).
173
Resolução: O processo de KDD é constituído por um conjunto de
atividades contínuas que compartilham o conhecimento descoberto
a partir de bases de dados em cinco etapas: seleção dos dados, pré-
processamento dos dados, transformação dos dados, mineração
dos dados e interpretação dos resultados.
Resolução: Refere-se à tarefa de classificação, que é uma
das tarefas mais importantes e mais populares das análises
discriminantes de bases de dados. Na classificação, o modelo
analisa o conjunto de dados fornecido, associando ou classificando
um item a uma ou a várias categorias pré-definidas, derivando
uma regra que possa ser usada para classificar uma observação,
referente a um conjunto de dados identificados que são
categorizados por um assunto. Aplica-se em diversas áreas da
saúde, como no diagnóstico médico, visando classificar os pacientes
e os tipos de doenças; na área financeira, para avaliação de risco de
crédito etc.
174
175

Leitura Fundamental

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Leitura Fundamental

Enviado por

Direitos autorais:

Formatos disponíveis

WBA0748_v1.

Vice-Presidente de Pós-Graduação e Educação Continuada

Dados Internacionais de Catalogação na Publicação (CIP)

Catarino, Iolanda Claudia Sanches

1. Big data. 2. Banco de dados. I. Catarino, Iolanda

Banco de Dados Transacionais versus Bancos de Dados Analíticos..................05

Conceitos básicos sobre Data Warehouse...............................................................31

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

A disciplina Modelagem e Arquitetura de Data Warehouse contempla

Assim, no primeiro tema da disciplina, são contextualizados os

O quarto tema introduz a modelagem de dados para Data Warehouse,

O sexto tema introduz os fundamentos sobre o Processamento Analítico

• Reconhecer os contextos em que se aplicam os

• Acompanhar a estrutura tecnológica e de dados que

• Escolher a estrutura tecnológica e de dados para

Todos os dias, crescentes quantidades de dados são disponibilizadas

Os comportamentos das pessoas são expostos constantemente

Todos esses dados gerados em larga escala, vindos de diferentes

Esses conjuntos de dados podem ser formados por um arquivo, por

1.1 Modelo de dados

As fontes de dados são armazenadas segundo um modelo de banco de

• Modelo de banco de dados hierárquico.

• Modelo de banco de dados orientado a objetos.

• Modelo de relacionamento entre entidades.

Cada modelo de banco de dados é tratado de forma personalizada e

Fonte: elaborada pela autora.

Os diagramas de banco de dados auxiliam na descrição de um banco de

Os modelos de dados podem ser também conceituais, que é uma

Definir qual modelo será usado requer a compreensão e adequação

1.2 Modelo de banco de dados hierárquico

O modelo hierárquico organiza os dados em uma estrutura semelhante

Figura 2 – Modelo hierárquico

Fonte: elaborada pela autora.

O modelo relacional é o mais utilizado atualmente. Segundo Machado

Na Figura 3, o exemplo mostra um determinado atributo ou combinação

Figura 3 – Modelo relacional de convênio médico

ID Paciente Cod_convenio Tipo_plano Data_adesao

Cada uma das linhas, também chamadas de tuplas, inclui dados

Em bancos de dados, as tabelas podem ser normalizadas ou trazidas

A utilização das regras de normalização produz resultados adaptáveis

1.4 Modelo de rede

O modelo de rede em banco de dados baseia-se no modelo hierárquico,

Empregado Cliente 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-

1.6 Modelo de relacionamento entre entidades

Esse modelo captura as relações entre entidades do mundo real muito

Machado (2011) ilustra que esse modelo é utilizado em nível

id_prodt (INT) id_categ (INT)

Fonte: elaborada pela autora.

O MER é uma forma comum do diagrama de esquema em estrela,

Dimensão 3 Fato Dimensão 2

Fonte: elaborada pela autora.

As dimensões e os fatos são componentes complementares e

Essa percepção é muito importante para elaborar projetos em DW, já

PARA SABER MAIS

1.6.1 Modelo multidimensional

Esse modelo é uma variação do modelo relacional, sendo projetado

1.7 Modelo de BD NoSQL