aula 02 - banco de dados 3

Prévia do material em texto

Prof. Arthur Mendonça 
 Aula 02 
 
 
1 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
Aula 02 
Bancos de Dados para Analista - 
Tecnologia da Informação do TCE/RJ 
Prof. Arthur Mendonça 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
2 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
Sumário 
SUMÁRIO 2 
INTRODUÇÃO 3 
TEORIA DA AULA 4 
BUSINESS INTELLIGENCE 4 
ETL 4 
Integração 6 
Recuperação 6 
MODELAGEM DIMENSIONAL, DW E OLAP 8 
OLTP x DW/BI 9 
Data Marts 14 
O MODELO 16 
Esquema Estrela 16 
Tabela Fato 17 
Dimensões 21 
OLAP 26 
TÓPICOS AVANÇADOS 38 
Modelagem de Dimensões 38 
Slowly Changing Dimensions 40 
Modelagem das tabelas Fato 42 
Uso de índices em DW 44 
QUESTÕES COMENTADAS PELO PROFESSOR 47 
LISTA DE QUESTÕES COMENTADAS 64 
GABARITO 73 
RESUMO DIRECIONADO 74 
REFERÊNCIAS 78 
 
 
 
 
 
 
 
 
 
 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
3 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
 
 
 
Introdução 
 Olá! Bem-vindo a mais uma aula do nosso curso de Bancos de Dados para o TCE/RJ! Na aula de hoje vamos 
abordar um conceito muito interessante chamado modelagem dimensional. 
 Os tópicos abordados serão os seguintes: 
 
2.1 Arquitetura e aplicações de data warehousing, ETL e Olap. 2.2 Técnicas de modelagem e otimização de bases de 
dados multidimensionais. 
 
 A aula de hoje foca em sistemas analíticos, explicando o que é Business Intelligence e como funciona a 
modelagem dimensional, abordagem que tem bastante utilidade no subsídio à tomada de decisão. 
 
ATENÇÃO! 
 Se você também é aluno do nosso curso de Análise de Dados e Informações, já deve ter estudando boa 
parte do assunto de hoje na Aula 03. Se esse foi o caso e você não julga ser necessário revisar os 
tópicos, sugiro que pule a maior parte da aula e estude somente a seção de TÓPICOS AVANÇADOS 
EM MODELAGEM DIMENSIONAL. Ela contém alguns diferenciais que podem ser explorados na sua 
prova, que tende a ter um enfoque mais técnico na modelagem de sistemas dimensionais. 
 
 Vamos lá? 
 
 
 
 
 
 
 
 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
4 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
 
 
 
 
Teoria da aula 
Business Intelligence 
Para começar a nossa aula, vamos relembrar o que falamos a respeito do processo de Business Intelligence 
(BI), ou Inteligência de Negócio, que ocorre no âmbito de organizações. Nós já vimos esse assunto na primeira 
aula, mas julgo importante que você dê uma nova leitura, mesmo que breve, para contextualizar o restante dos 
temas da aula! 
BI é uma área da tecnologia da informação que tem como objetivo geral coletar e processar dados para que 
se extraia informações relevantes para tomada de decisão. Embora tenha a palavra business – ou negócio – no 
nome, as técnicas de BI são plenamente aplicáveis ao setor público e estão ganhando crescente importância nos 
mais diversos órgãos e entidades. Tome “negócio” aqui como sendo o ambiente de qualquer organização. 
Não há um processo rígido definido para Business Intelligence, mas em linhas gerais podemos apresentar o 
seguinte fluxograma que guarda relação com o assunto cobrado no seu concurso: 
 
 
ETL 
 No início desse processo de Business Intelligence, temos a parte que envolve coleta, tratamento e 
armazenamento dos dados. Essa etapa é conhecida como ETL – Extract, Transform, Load. As tarefas 
efetivamente executadas em um processo de ETL variam bastante e vão depender da natureza dos dados e dos 
objetivos dos usuários. 
 Em linhas gerais, as fases do ETL são as seguintes: 
 A coleta (ou extração) se destina a capturar os dados de diversas fontes e sistemas que serão utilizados no 
processo de BI. Por exemplo, em uma empresa é comum que haja um ERP, o famigerado “sistema”, que é aquele 
software que gerencia a maior parte das atividades da empresa, possibilitando o controle de vendas, clientes, 
ETL
•Coleta
•Tratamento
•Armazenamento
Integração
•Data Warehouse 
(DW)
Recuperação
•Relatórios e 
dashboards
•OLAP 
(Multidimensional)
•Mineração de Dados
•Análise
Prof. Arthur Mendonça 
 Aula 02 
 
 
5 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
fornecedores, contas a pagar e a receber, RH, etc. Esse ERP é uma fonte muito valiosa para a coleta, já que por ele 
circula boa parte dos dados relevantes para a organização. 
 Também podem ser coletadas informações de planilhas, arquivos .txt, sites da internet, sistemas auxiliares, 
dentre outros. A escolha das fontes é um importante passo no âmbito de BI, pois esses dados inicialmente 
coletados é que serão a base para o resto do processo. 
Em seguida, na etapa de transformação, pode ocorrer a limpeza dos dados, corrigindo possíveis erros de 
entrada nos dados (erros de digitação na inserção, por exemplo), ajustes de tipo de dados e demais 
desconformidades com os padrões de qualidades definidos pelos usuários e projetistas do sistema. Nessa etapa, 
os dados são tratados para que se tornem mais corretos ou relevantes para os propósitos do BI. 
Outra tarefa que é realizada no âmbito da transformação diz respeito à padronização dos dados para a 
futura integração. Essa tarefa é de fundamental importância quando estamos coletando dados de muitas fontes, 
já que os dados de diferentes sistemas ou arquivos podem assumir diferentes padrões para representar a mesma 
coisa. 
 Para exemplificar, imagine que você está trabalhando na fiscalização de uma empresa pública e precisa 
cruzar informações de diversos sistema. Contudo, o CNPJ da entidade está escrito de forma diferente em cada um 
desses sistemas. A fase de transformação é responsável por tratar os dados dessas fontes e, dentre outras tarefas, 
convertê-los em um único padrão: 
 
 
O mesmo processo poderia se aplicar, por exemplo, à conversão de diversas escalas de dados em uma só. 
Imagine que uma fonte registra uma determinada medida em milímetros, outra em metros e uma terceira em 
centímetros. Para facilitar a análise e, por consequência, a tomada de decisão, seria interessante construir uma 
representação unificada, com a escolha de uma só unidade (por exemplo, centímetros) e a conversão de todas as 
outras para essa escolhida. 
Essas duas primeiras etapas do ETL, de extração e transformação geralmente se utilizam de uma base de 
dados temporária, chamada staging area. Esse banco de dados intermediário é considerado uma área de 
12.345.678/0001-10
CNPJ:12.345
.678/0001-10
1234567800
0110
12.345.678/0
001-10
Prof. Arthur Mendonça 
 Aula 02 
 
 
6 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
transição onde se pode inserir os dados oriundos da extração e realizar as transformações necessárias, tudo isso 
antes de carregá-los no data warehouse (que será o destino dos dados). 
A utilização dessa staging area se dá de modo a não sobrecarregar nem o ambiente de produção (os 
sistemas operacionais da empresa) nem o próprio data warehouse com as operações de transformação. 
Por fim, temos o armazenamento ou carregamento. Nesta etapa, os dados já coletados e tratados são 
transferidos para o banco de dados (ou qualquer estrutura que armazene dados) de destino, que geralmente é um 
BD especial voltado para análise chamado data warehouse. O processo de ETL costuma ser o mais crítico e mais 
demorado na formação de um sistema de BI. 
Periodicidade do ETL 
Esse processo de ETL ocorre de forma periódica. O quão frequente ele será vai depender de muitos fatores, como a 
complexidade do processo, as necessidades dos usuários de enxergarem dados atualizados ou mesmo a frequência de 
atualização das diversas fontes de dados. Assim, podemos ter processos de ETL que serão executadosa cada 5 minutos, 1 
hora, 1 semana ou mesmo 1 mês, por exemplo. 
 
Integração 
 O Data Warehouse (DW) ou Armazém de Dados é, na maioria das vezes, o responsável por conter essa 
integração de dados de diferentes fontes. O DW é um repositório que contém os dados dos mais diversos setores 
de uma organização, servindo de base para que se criem relatórios, dashboards, cubos OLAP ou se realize outras 
formas de análise. Não vamos aprofundar muito o conceito aqui, já que teremos um momento específico para isso. 
 O importante é que você saiba que a integração de dados nada mais é do que esse processo de combinação 
de dados de diversas fontes em uma base de dados unificada e tudo que o envolve. Preste atenção: a integração é 
um processo que se inicia já desde a coleta, com o planejamento das diferentes fontes de dados que vão compor 
o conjunto final, e passa pelas etapas subsequentes até que se chegue na base de dados final. 
 
Recuperação 
Os dados já coletados, tratados, armazenados e integrados devem ser tornados acessíveis para que sejam 
úteis. Neste processo de recuperação ou extração é possível alimentar diferentes sistemas de visualização e 
análise de dados para subsidiar a tomada de decisão. 
 Esta etapa requer um forte conhecimento a respeito dos propósitos que se têm para a utilização da 
informação e a respeito do negócio subjacente. Ou seja, para que possamos trabalhar com esses dados refinados 
de modo a torná-los úteis à tomada de decisão, precisamos saber primeiro para que queremos fazer isso e quais 
são os aspectos importantes do negócio que precisam ser representados. 
 Qual a decisão precisa ser tomada? Qual a aplicabilidade da informação recuperada? Como explicitar os dados 
de uma maneira útil e clara? Essas perguntas devem permear todo este processo. 
Visualização se refere à produção de relatórios e dashboards que ajudam a compreender a dinâmica dos 
dados em um contexto de negócio. São documentos que contém muitas vezes gráficos, tabelas e dados em uma 
forma visualmente agradável. 
Prof. Arthur Mendonça 
 Aula 02 
 
 
7 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
 
 
Fonte: https://powerbi.microsoft.com/pt-br/what-is-power-bi/ 
 
 A partir da integração dos dados transformados em um data warehouse, também é possível se utilizar de 
cubos OLAP e de Mineração de Dados para enriquecer a análise dos dados. Ainda vamos ver esses conceitos, então 
não se preocupe! 
 
(CESPE – ANTAQ – 2014) 
Acerca de ferramentas de BI (business intelligence), julgue o próximo item. 
O Módulo de ETL (extract transform load), dedicado à extração, carga e transformação de dados, coleta 
informações em fontes como sistemas ERP, arquivos com extensão TXT e planilhas Excel. 
RESOLUÇÃO: 
A etapa de extração do módulo de ETL de um sistema de Business Intelligence se dedica a coletar dados de 
diversas fontes para posterior transformação e carregamento na base de destino. Você pode ter achado que a 
assertiva estava errada por dizer que são coletadas informações de diferentes fontes, mas a questão foi 
considerada correta. 
Acontece que as bancas não costumam focar muito nesse aspecto formal da diferença entre dado, informação e 
conhecimento em questões que não dizem respeito a esse assunto. Então, minha recomendação é: a não ser que 
a questão trate explicitamente da diferença entre esses conceitos ou o erro seja muito óbvio, você pode considerar 
a diferença como sendo irrelevante para a resposta. 
Gabarito: C 
 
(CESPE – Banco da Amazônia – 2012) 
Julgue o item que se segue: 
O processo de extração, transformação e carga (ETL) ilustrado permite extrair dados de diversas fontes de dados 
e migrá-los para o data warehouse, mantendo sua estrutura e normalização originais. 
Prof. Arthur Mendonça 
 Aula 02 
 
 
8 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
RESOLUÇÃO: 
Pense comigo. As fontes de dados em um processo de ETL costumam ser heterogêneas, variadas. Dessa maneira, 
não há como manter sua estrutura original. Aliás, o propósito do processo é justamente extrair os dados e 
transformá-los, preparando-os para a integração no seu destino, geralmente o data warehouse. 
Gabarito: E 
 
Modelagem dimensional, DW e OLAP 
 As organizações, tanto do setor privado quanto do público, têm uma grande necessidade de extrair 
informações úteis a partir da infinidade de dados que trafegam todos os dias em seus ambientes computacionais. 
A informação adequada fornecida na hora certa pode ser a diferença competitiva para uma empresa ou a chave 
para uma política pública bem-sucedida. 
 O processo que parte da coleta dos dados brutos de diversas fontes e chega até o compartilhamento e o 
monitoramento pelo usuário é chamado de Business Intelligence (Inteligência de Negócios). O BI, como é 
chamado, é o conjunto de técnicas e ferramentas que propicia esse processo e apoia a gestão, servindo de suporte 
à tomada de decisão. Falamos um pouco sobre esse processo na nossa primeira aula. 
 Parte do processo de BI envolve a construção de um Data Warehouse (Armazém de Dados). O DW de uma 
empresa é um banco de dados especializado, que serve como repositório central de dados de toda a empresa. 
Ele tem como objetivo servir de base de consulta para que se realize análises através de relatórios visuais, painéis 
gerenciais, técnicas de mineração de dados e outras ferramentas que citaremos mais à frente. 
 
 
 
DW
Relatórios
Painéis 
Gerenciais
Análise 
OLAP
Mineração 
de Dados
Prof. Arthur Mendonça 
 Aula 02 
 
 
9 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
OLTP x DW/BI 
 Bom, até aí tudo bem, mas creio que ainda não ficou muito clara qual é a diferença entre um banco de dados 
relacional utilizado pelos sistemas transacionais de uma empresa e um DW, não é? 
 Os sistemas transacionais das organizações, como aqueles que lidam com transações bancárias, registram 
vendas, processam as atividades operacionais, dentre outras inúmeras funcionalidades, são conhecidos como 
OLTP – Online Transaction Processing, ou Processamento de Transações em Tempo Real. 
 Esses sistemas OLTP comumente fazem uso de bancos de dados relacionais normalizados, pois são mais 
focados em ter rapidez na execução das inserções e atualizações de dados e diminuir as redundâncias. 
 Contudo, ao realizar esse processo de normalização geralmente temos a geração de mais entidades (tabelas) 
no modelo de dados. Se por um lado essa abordagem economiza o espaço em disco e otimiza a execução dos 
sistemas OLTP, por outro lado esse fator dificulta a extração e a análise dos dados, já que para obter determinada 
informação muitas vezes precisamos realizar operações de junção entre diversas tabelas distintas. 
 Esses sistemas OLTP também são otimizados para lidar com uma transação por vez, devido à necessidade 
de manutenção da integridade do banco de dados relacional que está sendo utilizado. Além disso, os dados 
tendem a ter uma frequência maior de atualizações. Se uma filial da organização muda de endereço, por 
exemplo, o OLTP provavelmente irá apenas atualizar os campos correspondentes da tabela, ao invés de manter 
um histórico da informação. 
 Já os sistemas de Data Warehouse/Business Intelligence têm outros propósitos. A ideia aqui passa a ser no 
fácil acesso aos dados para leitura, ao contrário da escrita, de modo a criar novas visões intuitivas sobre os dados 
para facilitar a tomada de decisão. 
 Veja as principais diferenças entre OLTP e os sistemas de BI/DW no quadro a seguir, para então passarmos a 
definir o que é exatamente um data warehouse e a modelagem dimensional. 
 
 
OLTP
Execução operacional do 
negócio 
Alta frequência de atualização
Normalizados
Alta performance para 
manipulação de dados
BI/DW
Fator estratégico e tomada de 
decisão
Poucas atualizações,manutenção de histórico
Desnormalizados
Possibilitam análise de grandes 
volumes de dados
Prof. Arthur Mendonça 
 Aula 02 
 
 
10 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
 
 Kimball (2013) definiu alguns objetivos para um sistema de DW/BI. Não precisa decorar a lista a seguir, só 
entender, pois ela não costuma ser cobrada diretamente nas provas de concurso. 
• O sistema deve tornar a informação facilmente acessível. 
o O conteúdo desse tipo de sistema deve ser compreensível para o usuário, não somente para o 
desenvolvedor. O sistema deve utilizar termos utilizados pelos usuários, ser fácil e intuitivo de se 
utilizar. 
• O sistema deve apresentar a informação de forma consistente 
o Os dados só devem ser apresentados ao usuário final quando corretamente processados, limpos 
e com sua qualidade assegurada. 
• O sistema deve ser adaptável a mudanças 
o Requisitos de usuários e regras de negócio mudam o tempo todo. Um bom sistema de DW/BI deve 
ser capaz de se adaptar a essas mudanças. 
• O sistema deve apresentar as informações de uma maneira tempestiva 
o Não adianta nada apresentar uma informação estratégica sem que os dados estejam atualizados 
na janela de tempo adequada. Dependendo do negócio, pode ser necessário que os dados estejam 
atualizados até mesmo segundo a segundo. 
• O sistema deve proteger os ativos informacionais da entidade 
o Os dados em um DW têm informações potencialmente sigilosas e estratégicas, como carteira de 
clientes e margens de lucro. O sistema deve ser seguro o suficiente para prevenir o acesso não 
autorizado. 
• O sistema deve servir como uma fundação confiável para uma melhor tomada de decisões. 
• O sistema deve ter uma boa aceitação pela comunidade do negócio para que ele possa ser considerado 
bem-sucedido. 
 
 Com esses requisitos em mente, temos que a modelagem dimensional, ainda segundo Kimball (2013), é a 
preferida para apresentar dados analíticos, já que atende a dois requisitos principais: 
 
ü Entrega dados compreensíveis para os usuários de negócio 
ü Entrega uma boa performance de consulta 
 
 Assim, podemos concluir que modelagem dimensional pode trabalhar com o mesmo conjunto de dados de 
um sistema OLTP, mas os organiza de maneira a maximizar a compreensibilidade e a performance de leitura (ao 
invés de escrita). 
 Para completar essa conceituação inicial, trago quatro características importantíssimas dos data warehouses 
definidas por Bill Inmon, que é considerado o pai de Data Warehousing. Grave bem pois sempre cai em prova! Para 
Inmon (2005), um DW é: 
 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
11 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
 
 
 
Orientado a Assuntos 
 
Os dados estão organizados de tal maneira que todas as estruturas associadas a determinado assunto estão 
interligadas. Por exemplo, o assunto “Vendas” em uma empresa possui o envolvimento de diversos setores e 
sistemas, incluindo as atividades de processamento do pedido, do pagamento, de logística, cobrança, etc. Assim, 
um DW que contém informações a respeito de Vendas vai incluir dados de todos esses locais. 
 
Integrado 
Como os dados são orientados a assuntos e vêm de múltiplas fontes (outros bancos de dados, planilhas, 
sistemas transacionais, etc.), é comum que determinadas informações estejam representadas de maneiras 
distintas, já que os desenvolvedores desses outros sistemas e arquivos não os criaram pensando em uma 
integração futura. 
Acontece que em um data warehouse essa representação precisa ser unificada de modo a permitir a análise 
conjunta dos dados, tendo em vista determinado assunto. Assim, nomes de campos, tamanhos e tipos de 
atributos, estrutura de chaves primárias, etc. precisam ser unificados. 
Um exemplo clássico desse processo de integração é o campo Sexo (ou Gênero). O mesmo dado pode estar 
representado de diferentes maneiras nas diversas fontes, mas no processo de BI/DW é realizada essa integração: 
 
Vendas
Contas
Produtos
Prof. Arthur Mendonça 
 Aula 02 
 
 
12 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
 
 Além disso, pode haver redundância indesejada de dados, já que registros de múltiplas fontes podem conter 
as mesmas informações. Essas redundâncias também devem ser atacadas durante a transformação realizada 
durante o processo de integração realizado pelo ETL. 
 
Não-volátil 
 
 Os dados em um DW são carregados periodicamente (geralmente em grande quantidade de registros de 
uma só vez) e depois disso podem ser acessados pelos usuários, mas nunca atualizados. Isso é um 
comportamento distinto dos sistemas transacionais, que, como vimos, sofrem vários acessos, inserções, 
remoções e atualizações de dados conforme a necessidade. 
O propósito dessa característica do DW é manter um histórico dos dados. Quando há alguma modificação, 
um novo registro é armazenado e uma data/hora atribuída a ele. Assim, um registro é uma “fotografia” dos dados 
estática no tempo. 
Entenda que uma tabela presente em um DW pode ser atualizada, adicionando-se novos registros quando 
ocorre a carga de dados, o que geralmente é evitada é a atualização ou remoção dos registros já existentes nessas 
tabelas. 
Note, contudo, que não é absolutamente proibido que se altere ou remova um registro no data warehouse, 
já que é possível que tenham ocorrido erros nas inserções iniciais que precisem ser corrigidos ou mesmo seja 
necessário remover dados muito antigos, que não servem mais para a análise, liberando assim espaço em disco 
para novos registros. 
m, f
homem, 
mulher
h, m
m, f
Cliente
•Endereço atual
Cliente
•Endereço 
antigo
•Endereço atual
Cliente
•Endereço antigo
•Endereço antigo
•Endereço atual
Prof. Arthur Mendonça 
 Aula 02 
 
 
13 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
Em via de regra, para fins de prova, você pode considerar que os dados já presentes em um DW não são 
atualizados. Contudo, se o examinador fosse muito taxativo, dizendo “em hipótese alguma é possível que se remova 
ou altere algum registro de um data warehouse...”, eu mesmo marcaria falso! 
 
Variante no tempo 
Pode parecer redundante com a característica anterior, pois a variância no tempo é uma característica 
decorrente da última. Ela diz respeito ao fato de que um registro no DW sempre está ou esteve correto (válido) 
em algum período no tempo. 
 Em alguns casos, um registro possui uma data de inserção, em outros, datas em que esteve “em vigor”. 
Sempre há algum componente temporal no DW que vai indicar qual é o dado correto quando se estiver analisando 
determinado período. 
 Um bom exemplo para isso são os dados de um cliente. É comum que clientes troquem de endereço. Para 
realizar determinadas análises, como por exemplo levantamentos a respeito do mercado consumidor em 
determinadas cidades, precisaríamos ter essas informações atuais (para saber como está o agora) e históricas 
(para analisar a evolução do mercado ao longo dos anos). 
Assim, é importante que se guarde a informação original e suas modificações posteriores. Essa abordagem 
pode ser feita populando assim os registros de uma tabela: 
 
Cliente Cidade Data de Modificação 
José da Silva Recife - PE 17/08/2003 
José da Silva Fortaleza - CE 21/03/2011 
José da Silva Crato - CE 06/02/2018 
 
 Veja que há múltiplos registros para uma mesma pessoa, cada um válido em um determinado ponto no 
tempo. 
 
 
 
 
 
 
 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
14 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
Data Marts 
 
 
 
Um outro conceito interessante para a sua prova é o de data mart, ou repositório de dados. Um data mart 
(DM) é nada mais que um subconjunto de um data warehouse quegeralmente foca em uma área específica da 
organização, como por exemplo Vendas, Contabilidade, Marketing, etc. 
 A diferença de um data mart para um data warehouse, então, reside apenas no escopo abarcado pelo 
sistema. É lógico concluir que os data marts apresentam escopo mais reduzido, enquanto que DWs costumam 
abarcar todas os assuntos pertinentes a uma determinada organização. 
Esses DMs podem ser dependentes ou independentes. Um data mart dependente nada mais é do que um 
data mart originado de um data warehouse, uma segregação do DW empresarial. Enquanto isso, por razões de 
custos ou estratégia, uma organização pode decidir criar somente um pequeno DW setorial, que não abarque toda 
a empresa, mas só uma área ou setor. Esse último é o chamado data mart independente. Posteriormente, os 
vários data marts independentes podem vir a compor um DW empresarial. 
Inmon e Kimball defendem abordagens diferentes para a construção de data warehouse e data marts. Inmon 
(2005) defende que o processo deve ser top-down: 
 
Ou seja, no processo de BI/DW de Inmon há primeiro a criação de um DW para posterior segregação em data 
marts específicos e daí o acesso aos dados pelos usuários através da geração de relatórios, mineração de dados, 
etc. 
 Isso traz algumas desvantagens, já que o processo de desenvolvimento é mais longo e o custo inicial é mais 
alto. Contudo, a manutenção é mais fácil e os custos posteriores para a segregação dos data marts são 
consideravelmente menores, já que a estrutura como um todo já está pronta em forma de DW de nível 
empresarial. 
Já Kimball (2013) define o processo como sendo mais ou menos assim: 
Data Warehouse
Data 
Mart
Fontes de 
Dados
ETL (staging 
area)
DW 
Empresarial Data Marts
Acesso aos 
Dados
Prof. Arthur Mendonça 
 Aula 02 
 
 
15 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
 
 
 
No modelo de Kimball, os dados são extraídos das fontes e transformados para serem carregados em um 
DW modelado de acordo com o esquema estrela ou em um cubo OLAP. Falaremos sobre essas estruturas em 
breve, o importante agora é que você saiba que o DW de Kimball é criado através da composição de diversos data 
marts. Logo, tem-se que essa abordagem é conhecida como bottom-up. 
 
Kimball concebeu uma arquitetura chamada matriz de barramento para auxiliar no desenvolvimento de um data warehouse. 
Essa matriz é um diagrama que dispõe, nas linhas, os processos de negócio da organização. Já nas colunas, são dispostas as 
dimensões comuns a esses processos. Esse detalhe já apareceu em provas de concurso! Veja um exemplo de matriz de 
barramento (em inglês): 
 
 
(Kimball Group) 
 
(VUNESP – TJ/SP – 2012) 
Uma das técnicas utilizadas no projeto de um data warehouse corporativo consiste no uso da chamada matriz de 
barramento, na qual as linhas e colunas representam, respectivamente, 
a) cubos e medições. 
b) data staging e cubos. 
c) cardinalidades e hierarquias. 
Fontes 
de 
Dados
ETL 
(staging 
area)
Data 
Marts 
(DW)
Acesso 
aos 
Dados
Prof. Arthur Mendonça 
 Aula 02 
 
 
16 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
d) dimensões e cardinalidades. 
e) processos de negócio e dimensões. 
RESOLUÇÃO: 
A matriz de barramento é uma ferramenta concebida por Kimball que dispõe, nas suas linhas, os processos de 
negócio da organização e em suas colunas as dimensões comuns. 
Gabarito: E 
 
O modelo 
 “Beleza, professor. Mas, afinal, como é o modelo dimensional?” Tenho certeza que é exatamente isso que você 
está se perguntando agora! Para sua felicidade, vamos abordar este assunto nesta seção da aula. 
 Não é necessário que uma organização adquira um novo SGBD para implementar seu data warehouse. 
Kimball (2013) mostra que um DW pode ser implementado em um SGBD relacional, através do esquema estrela, ou 
em um ambiente de banco de dados multidimensional, através de um cubo OLAP. 
Vamos definir esses conceitos a seguir. 
Esquema Estrela 
Os esquemas estrela ou star schemas são os modelos dimensionais implementados em SGBDs relacionais. 
Esse conceito foi criado por Kimball e é utilizado em diversas organizações. Eu mesmo já trabalhei com vários! O 
esquema leva esse nome devido à sua estrutura, que lembra uma estrela quando representada em um diagrama: 
 
 
Figura: Um exemplo de esquema estrela 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
17 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
 Você consegue enxergar que a figura acima é muito parecida com um diagrama lógico de um banco de dados 
relacional, não é? Temos tabelas com chaves primárias e relacionamentos representados através de chaves 
estrangeiras. A diferença reside na disposição das entidades e dos relacionamentos, que seguem o modelo 
dimensional, não a modelagem relacional padrão. 
 A tabela central é chamada tabela fato e as periféricas são as dimensões do modelo. 
Tabela Fato 
A respeito desse conceito, Kimball (2013) diz o seguinte: 
A ideia de que um evento mensurável do mundo físico tem uma relação um para um com um registro da 
tabela fato é o princípio fundamental da modelagem dimensional. 
Mas o que isso quer dizer? O termo fato corresponde a uma métrica ou medida a respeito de um processo 
de negócio da organização. Vamos usar os três termos indistintamente ao longo da aula, pois qualquer um deles 
pode ser utilizado na sua prova. 
Para caracterizar os fatos e a tabela de fatos, Kimball (2013) dá como exemplo a situação de um mercado: 
Imagine estar em frente ao caixa observando os produtos sendo vendidos, e que a cada produto em cada transação 
você anota a quantidade vendida e o valor em reais gasto com aquele produto. 
Esse seu bloco de notas seria equivalente a uma tabela fato; já a quantidade vendida e o valor em reais 
seriam os fatos, medidas ou métricas (fique atento à diferença entre uma (tabela) fato e um fato). 
 Da mesma maneira poderíamos considerar uma tabela fato cujo objetivo fosse levantar estatísticas sobre os 
jogadores em um campeonato de futebol. A cada jogo poderia haver um registro por atuação de um jogador em 
uma partida na tabela fato, contendo métricas como gols marcados, faltas sofridas, roubadas de bola, etc. 
 Esses fatos devem ser registrados na menor granularidade possível, ou seja, no maior nível de detalhe, de 
modo a enriquecer as possibilidades futuras de análise, já que posteriormente os dados poderão ser agregados 
como o usuário desejar. A definição do grão, ou o evento básico que será registrado na tabela fato, é parte 
fundamental da modelagem de um data warehouse. 
 Os grãos dos nossos exemplos dados seriam a venda de um produto (ou de várias unidades dele para um mesmo 
cliente) e uma atuação de um jogador, respectivamente. 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
18 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
 
Figura: Ilustração em (Inmon, 2005), indicando que as fatos, no caso Order (Pedido), possuem um volume bem maior de registros do que 
as tabelas restantes do modelo dimensional. 
 
Assim, podemos concluir que a tabela fato é a tabela que armazena as métricas que representam o desempenho 
do negócio. Ela vai conter um registro para cada evento ocorrido, como é o caso de uma venda em uma loja virtual, 
por exemplo. 
 As tabelas fato são compostas por chaves estrangeiras e pelos valores das medidas ou fatos (veja a tabela 
fato Vendas no esquema estrela mais acima). 
 Aqui, o conceito de relacionamento e chave estrangeira é o mesmo do modelo relacional: essas chaves 
referenciam as outras tabelas do modelo, as dimensões. A chave primária de uma tabela fato é geralmente 
composta pelas chaves estrangeiras ou por um conjunto delas. 
Outra possibilidade não contemplada pelo nosso esquema estrela de exemplo é a existência de umaconstelação de fatos. Ou seja, termos mais de uma tabela fato ligadas ao mesmo conjunto de dimensões. Isso 
não implica que todas as fatos têm que estar ligadas a todas as dimensões, não é isso. O que estou querendo dizer 
é que as múltiplas fatos compartilham um conjunto de dimensões. 
 Veja o esquema a seguir, em que as duas tabelas fato se relacionam com as dimensões de Produto e Data. O 
texto está um pouco pequeno, mas dá pra pegar a ideia. Esse esquema é às vezes chamado de multiestrela. 
 
Figura: Constelação de fatos ou esquema multiestrela 
Prof. Arthur Mendonça 
 Aula 02 
 
 
19 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
 
É interessante que você perceba que a dimensão Data está ligada às duas fatos no nosso exemplo. Isso ocorre com bastante 
frequência. As dimensões Calendário ou Data estão quase sempre ligadas às tabelas fato, já que o aspecto temporal costuma 
ser fundamental para análise de dados. 
Essas dimensões costumam conter vários atributos que descrevem uma data, como dia, semestre, bimestre, indicadores de 
feriados, dentre outras inúmeras possibilidades. A chave primária dessas dimensões costuma ser a própria data, ao contrário 
de outras dimensões, que costumam ter uma chave substituta (sem significado real). 
Kimball, inclusive, recomenda que as dimensões de modo geral sempre utilizem chaves substitutas, de modo a facilitar o 
gerenciamento dos identificadores únicos de cada dimensão. 
 
Tipos de Tabela Fato 
 Segundo Kimball (2013), as tabelas fato se dividem em três tipos fundamentais, de acordo com sua 
granularidade: 
 
1) Transacionais 
 
Figura: Leitura de código de barras alimentando tabela fato transacional (Kimball & Ross, 2013) 
 
Essas tabelas fato são as que temos mostrado até agora. Elas armazenam registro a registro as transações 
que ocorrem, tendo um alto nível de detalhe. O grão é a unidade mínima do negócio, como por exemplo uma 
venda de um produto para um cliente. 
 
 
 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
20 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
2) Snapshot Periódico 
 
Figura: Exemplo de snapshot periódico 
 
Seria ótimo ter sempre todos os registros de transação em nossa base de dados dimensional, trazendo 
grande poder de análise. Contudo, isso nem sempre é factível ou faz sentido para o negócio. Em tabelas fato 
muito grandes, uma transação individual traz uma mudança quase que imperceptível no valor total das 
medidas. 
Para esses casos, é suficiente que se tenha atualizações ao final de um curto período de tempo. Podemos 
então tirar uma “fotografia”, ou snapshot, da situação das vendas ao final de cada dia, por exemplo, somando 
todas as transações que ocorreram naquele dia e escrevendo apenas um registro na tabela fato. 
Assim, ao utilizar-se essa agregação de dados diminui-se drasticamente o tamanho das tabelas e melhora-
se a performance do sistema de BI/DW. 
 
3) Snapshot Acumulativo 
 
Nº Pedido Data Pedido Data Pagamento Data Envio Data Entrega 
0001 01/01/2018 02/01/2018 02/01/2018 10/01/2018 
0002 11/01/2018 11/01/2018 --- --- 
 
Esse tipo não é tão comum, mas pode ser bastante útil para determinados tipos de aplicação que seguem 
um fluxo ou processo bem definido, com pontos intermediários constantes. As tabelas fato desse modelo 
contém diversas colunas com chave estrangeira para a dimensão data, que vão sendo atualizadas à medida 
que o processo caminha. 
Repare que esse é o único caso entre os três tipos em que atualizamos os valores de registros em uma 
tabela fato. É uma exceção àquela propriedade de não volatilidade. 
Um exemplo clássico de aplicação para esse tipo é um pedido em uma loja virtual. Veja como os passos 
são bem definidos e vão sendo preenchidos à medida que ocorrem. 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
21 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
(CESPE – TCE/PB – 2018) A modelagem dimensional é uma técnica de projeto de banco de dados capaz de 
suportar, em um data warehouse, consultas de usuários finalísticos ligados a um negócio. Conceitos como tabela-
fato, tabela agregada e métricas fazem parte da modelagem dimensional. A respeito dessa modalidade de 
modelagem, julgue os itens a seguir. 
I. Uma tabela-fato armazena, para fins estatísticos, as medições de desempenho. 
II. A tabela agregada é composta de atributos e contém a descrição do negócio. 
III. A tabela agregada é utilizada para reduzir o tempo de acesso de uma consulta ao banco de dados. 
IV. Métricas são as informações que se armazenam em tabela-fato e permitem medir o desempenho dos processos 
do negócio. 
V. As métricas não aditivas, assim como os valores percentuais ou relativos, podem ser manipuladas livremente. 
Estão certos apenas os itens 
a) I e II. 
b) I e III. 
c) II e V. 
d) III e IV. 
e) IV e V. 
RESOLUÇÃO: 
I. Na minha opinião, esta alternativa está correta. Uma tabela fato armazena vários tipos de medições, incluindo 
medições de desempenho, para diversos fins, incluindo fins estatísticos. A banca inicialmente deu o gabarito como 
errada, mas depois considerou que a redação era ambígua e anulou o item. ANULADA 
II. Uma tabela agregada é uma fato. A agregação dos registros da fato, como ocorre nas fatos de Snapshot 
Periódico, é uma técnica que visa reduzir a quantidade de registros nessa tabela, melhorando a performance de 
consulta. ERRADA 
III. Como acabei de explicar, as tabelas fato agregadas melhoram a performance de consulta, reduzindo assim o 
tempo de acesso. CERTA 
IV. As métricas são armazenadas nas fatos e permitem realizar diversas medições a respeito do negócio, incluindo 
o desempenho dos processos. CERTA 
V. Não! As métricas não aditivas não podem ser somadas ou subtraídas umas das outras no momento da 
agregação. Portanto, elas não podem ser manipuladas livremente. ERRADA 
 
Gabarito: I, III e IV (ANULADA) 
 
Dimensões 
 As dimensões compõem o restante das tabelas do esquema estrela. Elas são companheiras inseparáveis da 
tabela fato, estando ligadas a ela em um relacionamento um para muitos (um registro de dimensão pode se 
Prof. Arthur Mendonça 
 Aula 02 
 
 
22 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
relacionar com vários registros da tabela fato). Essas tabelas contêm o contexto descritivo associado aos fatos, 
dessa forma tendem a focar no aspecto qualitativo enquanto que as tabelas fato focam no aspecto quantitativo. 
 Essas tabelas, segundo Kimball (2013), nos ajudam a responder o “quem, o quê, onde, quando, como e por 
quê”. É fácil de perceber quando consideramos o nosso diagrama. Considere a fato “Vendas” que apresentamos 
mais acima. Temos nas dimensões as respostas para as perguntas: 
 
ü “O que é vendido?” – Produto 
ü “Onde foi vendido?” – Filial 
ü “Quando foi vendido?” – Data 
ü “Quem vendeu?” – Vendedor 
ü “Para quem foi vendido?” – Cliente 
 
 Por essas características, as dimensões contêm os códigos e descrições que vão, em última instância, virar 
os nomes das colunas das tabelas dos relatórios produzidos com base no modelo dimensional, e vão ser utilizadas 
como filtros nas consultas que realizemos. Por exemplo, poderíamos fazer a seguinte “pergunta” através dos 
filtros de relatórios em nossas análises: “Retorne a quantidade total de vendas dividida por produto, por ano, por 
local.” 
 As dimensões são geralmente desnormalizadas. Passamos a nos preocupar menos com a redundância de 
dados e com o espaço em disco e mais com a simplicidade do modelo para facilitar operações de filtragem e 
extração de dados realizadas pelos usuários. 
 Devido a essa desnormalização, é comum que se represente relacionamentos um para muitos (1:N) em uma 
tabela só. Simplesmente replicamos os registros dos dois lados do relacionamento quantasvezes seja necessário 
em uma tabela só. Como isso é um assunto um pouco árido, aqui vai um exemplo mais detalhado: 
 Em um BD relacional comum, normalizado, poderíamos representar o relacionamento entre produtos e suas 
categorias em uma loja de departamentos da seguinte maneira: 
 
Categoria: 
Código Categoria Andar 
C1 Brinquedos 2º 
X8 Decoração 3º 
Z3 Artigos Esportivos 1º 
 
Produto: 
Código Produto Categoria 
99816 Boneco C1 
15923 Lustre X8 
98562 Jogo de Tabuleiro C1 
35366 Camisa da Seleção Z3 
Prof. Arthur Mendonça 
 Aula 02 
 
 
23 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
 Já na modelagem dimensional, seria mais apropriado que incluíssemos toas as informações a respeito da 
categoria já na tabela de produto, desnormalizando assim o esquema: 
 
Tabela Produto (desnormalizada): 
Código Produto Categoria Andar 
99816 Boneco Brinquedos 2º 
15923 Lustre Decoração 3º 
98562 Jogo de Tabuleiro Brinquedos 2º 
35366 Camisa da Seleção Artigos Esportivos 1º 
 
 Perdemos um pouco em relação à redundância dos dados e consequentemente em espaço em disco, já que 
repetimos os mesmos dados das categorias várias vezes (uma vez para cada produto), mas ganhamos em 
facilidade de consulta, já que precisamos fazer menos junções entre as tabelas para obtermos os resultados 
desejados. 
 Existem casos em que o projetista do modelo entende que é realmente melhor manter algumas tabelas 
normalizadas, da maneira como ficaria em um Banco de Dados Relacional. Esse fenômeno é conhecido como 
snowflaking, verbo derivado da palavra snowflake, ou floco de neve. 
O esquema resultante, então, pode ser chamado de esquema floco de neve. Isso se deve, novamente, ao 
formato do esquema resultante, que, quando possui muitas tabelas, lembra a estrutura intrincada de um floco de 
neve. A seguir, uma adaptação no nosso esquema estrela para incluir o endereço dos clientes de forma 
normalizada, tornando-o assim um esquema floco de neve: 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
24 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
Valores nulos nas dimensões 
Como o modelo dimensional está voltado para aplicações de análise, como a geração de relatórios, dashboards, dentre outras 
técnicas, recomenda-se que não se utilize o valor NULL nas dimensões, substituindo-os por valores textuais mais intuitivos 
para o usuário, como “Desconhecido”, “Não Aplicável”, etc. 
 
(CESPE – CGM João Pessoa/PB – 2018) 
Com relação à modelagem dimensional e à otimização de bases de dados para business intelligence, julgue o item 
subsequente. 
O modelo snowflake acrescenta graus de normalização às tabelas de dimensões, eliminando redundâncias; em 
termos de eficiência na obtenção de informações, seu desempenho é melhor que o do modelo estrela, o qual, 
apesar de possuir um único fato, possui tamanho maior que o do snowflake, considerando-se a desnormalização 
das tabelas de dimensões. 
RESOLUÇÃO: 
A definição inicial está correta. Contudo, o desempenho na obtenção da informação no snowflake é pior do que o 
estrela, que é desnormalizado. Isso ocorre porque o modelo snowflake é mais complexo, apesar de ocupar menos 
espaço no BD devido à eliminação de redundâncias. 
Gabarito: E 
 
(CESPE – TCE/PE – 2017) A respeito da modelagem dimensional, julgue o próximo item. 
No modelo floco de neve (snow flake), todas as tabelas estão relacionadas diretamente com a tabela de fatos, e 
as tabelas dimensionais devem conter todas as descrições necessárias para definir uma classe nelas mesmas. 
RESOLUÇÃO: 
Falso. A característica do modelo floco de neve é justamente a existência de dimensões ligadas a outras 
dimensões, em obediência à terceira forma normal. 
Gabarito: E 
 
 
 
 
 
 
 
 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
25 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
Medidas aditivas, semiaditivas e não aditivas 
Os fatos mais interessantes que podem ser representados no modelo dimensional são os fatos numéricos 
aditivos, como os que apresentamos acima. Isso ocorre porque em aplicações de BI raramente se tem o interesse 
de visualizar um único registro da tabela fato por vez. O propósito é geralmente extrair de uma vez inúmeros 
registros que se amoldem a determinados parâmetros e filtros. Por exemplo, realizar uma análise a respeito de 
todas as vendas de uma determinada categoria de produto que foram realizadas ao longo dos meses de um ano. 
Também existem os fatos semiaditivos, que são aqueles que são aditivos somente em relação a algumas 
dimensões, não a todas. Um exemplo clássico é o saldo das contas 
contábeis. Se tivermos uma tabela fato que tenha como grão o saldo de 
uma conta contábil a cada dia, não podemos somar esta medida ao longo 
do tempo, já que não faz sentido somar o saldo de um dia com o saldo do 
dia seguinte. Por outro lado, pode fazer sentido somar estes saldos ao longo 
de outras dimensões para se obter valores totais, como por Setor, Filial, etc. 
 Por fim, temos as medidas não aditivas. Podemos usar como exemplo os 
valores percentuais. Imagine uma tabela fato que contém alíquotas de um 
determinado imposto, que variam ao longo do tempo e por estado. Não faz 
sentido somar a alíquota vigente em um ano com do ano seguinte, e muito 
menos somar a alíquota de um estado com a do outro. Logo, essas medidas 
precisam de um tratamento especial para que sejam agregadas, não 
podemos simplesmente somá-las ao longo das dimensões. 
 Veja esse exemplo para sumarizar o que você acabou de ler: 
Data Venda Valor Venda Qtd. Vendida Saldo da Conta Alíquota ICMS 
01/01/2018 R$ 100,00 10 R$ 2.000,00 21% 
02/01/2018 R$ 500,00 4 R$ 2.500,00 19% 
03/01/2018 R$ 350,00 5 R$ 2.850,00 20% 
TOTAL: R$ 950,00 19 R$ 2.850, 00 ? 
 
• As medidas aditivas, valor de venda e quantidade vendida, podem ser somadas normalmente ao longo da 
nossa tabela fato. 
• Já a medida semiaditiva, o saldo da conta corrente, não pode ser somada ao longo do tempo. Não faz 
sentido! O saldo correto é o mesmo do registro mais recente. Se estivéssemos analisando os totais por outra 
dimensão, como região, poderia fazer sentido somar os saldos das contas de cada local, mas esse não é o caso. 
• Por último, temos a medida não aditiva, a alíquota do ICMS. Essa medida nos traz alguns problemas. Está 
claro que não faz sentido somar os valores, não é? Você poderia imaginar que é possível tirar a média aritmética 
dos registros, ao invés de somá-los. Seria uma ideia interessante, mas também não faz muito sentido, já que a 
média das três alíquotas também não nos dá uma informação importante. Para obter a alíquota média total das 
nossas vendas, precisaríamos realizar uma média ponderada de acordo com o valor das vendas. Teríamos, então, 
M
ed
id
as Aditivas
Semiaditivas
Não aditivas
Prof. Arthur Mendonça 
 Aula 02 
 
 
26 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
que desenvolver uma fórmula na linguagem de programação suportada pelo sistema de DW/BI para conseguir 
algo de útil a partir desse tipo de medida. 
 Ah! Só mais um detalhe a respeito das tabelas fato: é teoricamente possível que tenhamos fatos (medidas) 
textuais, mas este raramente é o caso. Você pode considerar que, na maioria dos casos, quando estamos falando 
de uma medida, estamos nos referindo a um valor numérico. 
 
OLAP 
 
Figura: Representação gráfica de um cubo de dados. 
 
A outra alternativa para implementação do nosso modelo dimensional é a utilização de um cubo OLAP 
(Online Analytical Processing). Esses cubos são ambientes de bancos de dados multidimensionais, que seguem o 
mesmo modelo dimensional das implementações em esquema estrela. 
A diferença é que OLAP é uma espécie de interface que visa permitir a análise flexível de grandes volumes 
de dados comuma performance de consulta melhorada em relação a implementações em SGBDs relacionais. Para 
isso, os sistemas OLAP utilizam agregações pré-calculadas, índices e outras técnicas de otimização. 
O termo cubo é utilizado para se referir a uma representação multidimensional dos dados. A forma 
geométrica de um cubo só tem três eixos e, portanto, três dimensões. Contudo, um cubo OLAP pode ter infinitas 
dimensões, a depender da capacidade do sistema. Os cubos com mais de três dimensões são às vezes chamados 
de hipercubos. 
 
Motivação 
Para propósitos de análise de dados, os cubos OLAP apresentam algumas vantagens em relação aos 
esquemas estrela implementados em SGBDs relacionais. Algumas delas são: 
• Eles oferecem ricas possibilidades de análise, já que não estão presos à linguagem SQL. SQL é uma 
linguagem poderosa para a manipulação de SGBDs relacionais, mas em quando se realiza análise de 
grandes volumes de dados em múltiplas dimensões, as consultas podem se tornar complexas demais e o 
usuário pode se deparar com algumas limitações. 
• Os sistemas OLAP geralmente oferecem mais recursos de segurança e controle de acesso aos dados. 
Prof. Arthur Mendonça 
 Aula 02 
 
 
27 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
o Kimball (2013) cita a possibilidade de limitar acesso de um usuário aos dados detalhados, mas 
permitir acesso aos dados sumarizados (já agregados). 
o Os cubos OLAP geralmente oferecem também recursos de segurança em nível de linha. Ou seja, 
é possível restringir o acesso a usuários ou grupos de usuários a registros individuais em uma 
dimensão. 
• Os cubos dão maior suporte para se trabalhar com hierarquias de dados, sejam elas regulares ou 
desbalanceadas. 
 
Hierarquias 
Os atributos das dimensões em um modelo dimensional podem estar organizados em hierarquias. As 
hierarquias são, como o nome diz, conjuntos de atributos dispostos seguindo uma ordem de grandeza. 
Tanto os cubos OLAP quanto o esquema estrela oferecem suporte para trabalhar com essas hierarquias, mas 
geralmente os cubos OLAP têm mais ferramentas e permitem uma manipulação mais avançada através de 
linguagens de análise mais sofisticadas que o SQL. 
 
Figura: Representação gráfica em árvore de uma hierarquia de datas 
 Temos no diagrama acima uma hierarquia presente na dimensão data. Essa é uma hierarquia natural, pois 
não foi simplesmente criada pelo projetista, ela segue uma lógica do mundo real. Outra hierarquia que ocorre com 
frequência nos modelos multidimensionais é a geográfica, comumente na forma País > Estado > Cidade > Bairro. 
 As hierarquias costumam ter o membro “Todos” em seu nível mais alto, englobando todos os membros dos 
níveis inferiores. Da mesma maneira, os membros individuais do nível mais baixo da hierarquia são chamados de 
folhas, em uma analogia a uma árvore. 
 
Operações OLAP 
 As ferramentas de BI/DW propiciam uma fácil navegação através dos dados, possibilitando que se visualize 
as informações através de diferentes perspectivas, utilizando as mais diversas combinações entre as dimensões e 
em todos os níveis das hierarquias. 
Prof. Arthur Mendonça 
 Aula 02 
 
 
28 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
 As ferramentas de BI costumam dar suporte a um processo de navegação interativa que é chamado de slice 
and dice. Esse nome diz respeito a “cortes” que podem ser realizados nos cubos para limitar a análise de dados a 
um escopo menor do que o cubo inteiro. 
 Vamos ver algumas definições dessas operações a seguir: 
 
v Slice and dice 
 
Figura: Operação de slicing 
 
 To slice é o verbo “fatiar” em inglês. Essa operação faz um corte (ou filtragem) no cubo baseado no valor de 
alguma dimensão. Por exemplo, podemos extrair uma fatia do cubo que consiste nas vendas de produtos por 
cidade para um ano específico ou para um intervalo de anos. 
 
 
Figura: Operação de dicing 
 
 Dice é um termo inglês que tem vários significados. Um deles quer dizer “cortar em cubos”. O que acontece 
nessa operação é que se faz um corte no cubo OLAP baseado nos valores de mais de uma dimensão, criando assim 
um subcubo. 
 
 
 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
29 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
v Pivotagem (rotação) 
 
Figura: Representação gráfica da rotação de um cubo 
 
 Consiste em rotacionar o cubo para visualizar os dados em diferentes perspectivas, para realizar análises 
baseadas em dimensões diferentes. Por exemplo, poderíamos rodar o a fatia do nosso cubo de exemplo da 
operação de slicing para visualizar nas linhas os produtos, e nas colunas os locais de venda. 
 Além dessas, temos mais algumas operações OLAP possíveis em um sistema de BI/DW, os drills. Essas 
operações têm sua natureza associada com as hierarquias. Todas elas, incluindo as já apresentadas acima, 
podem ser combinadas para enriquecer a análise do usuário: 
 
•Ocorre quando o usuário está analisando um dado cortado por determinada 
dimensão e passa para outra que não faz parte da mesma hierarquia. Ex.: Da análise 
de vendas por filial para vendas por data.
Drill through
•Kimball (2013) diz que drill-across é a operação que permite juntar métricas de 
diversas fatos em um mesmo relatório combinado, desde que todas as fatos estejam 
relacionadas com dimensões em comum. Esse é o entendimento mais "oficial". Por 
exemplo, pense no nosso esquema mutliestrela mais acima: poderíamos gerar um 
relatório conjunto que exibisse as vendas e compras por produto e por data.
Drill across
•É Passar de uma análise de um nível maior para um nível menor, mais detalhado, 
dentro de uma hierarquia. Ex.: Vendas por ano -> vendas por mês.
Drill down
•O processo inverso do anterior. Sai-se de um nível menor, de mais detalhe, para um 
nível de maior generalização. Também é conhecida como roll up. Ex.: Vendas por 
semana -> vendas por mês.
Drill up
Prof. Arthur Mendonça 
 Aula 02 
 
 
30 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
Atenção! 
Já me deparei com 0utras definições para drill across. Uma delas, que 
já caiu em prova, dizia que essa é a operação que “pula” níveis dentro 
de uma hierarquia. É como se fosse um drill down, sendo que 
passando por cima de um ou mais níveis intermediários. Ex.: Vendas 
por ano -> vendas por dia, não passando antes pelo nível de mês. 
 
Fique ligado! 
 
(CESPE – MEC – 2015) Com relação a bancos de dados transacionais e analíticos, julgue o seguinte item. 
As operações slice and dice dos sistemas OLAP permitem selecionar e modificar a posição de uma informação, a 
troca de linhas por colunas e o giro do cubo multidimensional. Entretanto, não é permitido combiná-las com as 
operações drill down ou roll up. 
RESOLUÇÃO: 
Esse giro do cubo multidimensional é a pivotagem ou rotação. Além disso, essas operações podem ser combinadas 
livremente. 
Gabarito: E 
 
(CESPE – TCU – 2015) Julgue o item subsequente, a respeito de modelagem dimensional e análise de requisitos 
para sistemas analíticos. 
Na análise dos dados de um sistema com o apoio de uma ferramenta OLAP, quando uma informação passa de 
uma dimensão para outra, inexistindo hierarquia entre elas, ocorre uma operação drill through. 
RESOLUÇÃO: 
O drill through ocorre quando estamos analisando uma informação com base em uma dimensão e passamos para 
outra. Essa é a definição adotada pelo CESPE. 
Gabarito: C 
 
(CESPE – MEC – 2015) No que se refere a bancos de dados transacionais (OLTP) e a banco de dados analíticos 
(OLAP), julgue o item que se segue. 
 
Em ambientes corporativos, o uso de ambientes OLTP visa eliminar ao máximo a redundância de forma que a 
transação promova mudanças de estado o mais pontualmente possível, ao passo que o uso de ambientes OLAP 
objetiva prover uma visão dosdados orientados à análise com uma navegação rápida de dados agregados. 
RESOLUÇÃO: 
Perfeito! Os ambientes OLTP costumam ser normalizados, de modo a diminuir a redundância e maximizar a 
performance de escrita e atualização de dados. Já os sistemas OLAP visam prover recursos para análise, tendo 
ótima performance de leitura para navegação em dados agregados. 
Prof. Arthur Mendonça 
 Aula 02 
 
 
31 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
Gabarito: C 
 
(CESPE – ANTT – 2013) Julgue o item seguinte, relativo a conceito de qualidade, produtividade e a ferramentas 
de gestão. 
Considere-se que a ANTT deseje implantar um sistema de gestão estratégica com base em bancos de dados 
operacionais de empresas de transporte. Nesse caso, é correto afirmar que a ferramenta OLAP (online analytical 
processing), que permite a agregação de dados operacionais em múltiplas dimensões, é a ideal para apoiar a 
montagem de um painel gerencial de indicadores de qualidade e produtividade. 
RESOLUÇÃO: 
Isso. A definição de OLAP você já conhece. Um dos propósitos da utilização desse tipo de ferramentas é a 
montagem de relatórios e painéis gerenciais com indicadores a respeito da performance do negócio. 
Gabarito: C 
 
Regras de Codd 
 O criador do modelo relacional, Codd, também foi quem cunhou o termo OLAP. Codd dizia que as 
ferramentas OLAP deveriam seguir 12 regras. Essas regras são requisitos de funcionalidades para esses sistemas 
OLAP. Algumas delas já foram apresentadas de forma indireta durante a aula, pois têm a ver com os conceitos de 
modelagem dimensional como um todo, outras serão novidade, caso em que explicarei com mais detalhes. 
 A banca CESPE já cobrou algumas dessas regras, então fique ligado! 
 
1) Visão conceitual multidimensional 
O usuário deve ter uma visão conceitual dos modelos que seja multidimensional, já que sua análise do mundo 
real também é. As ferramentas OLAP, assim, devem suportar as operações multidimensionais como slice and dice. 
 
2) Transparência 
As etapas de construção do modelo OLAP devem ser transparentes, ou seja, ficarem invisíveis ao usuário. 
Este deve ser capaz de utilizar o sistema sem se importar com os detalhes das origens dos dados, com que 
transformações que foram realizadas ou com o processamento de agregações que está sendo realizado, por 
exemplo. 
 
3) Acessibilidade 
O sistema deve prover o usuário com somente um esquema lógico integrado dos dados. Veja que esta etapa 
também tem a ver com a integração, pois só após um processo do tipo é possível montar um único esquema lógico 
coerente a partir das diversas fontes heterogêneas. 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
32 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
4) Performance consistente de relatórios 
A performance do sistema não deve se degradar quando o número de dimensões crescer. Ou seja, o sistema 
deve ser escalável, permitindo que se aumente bastante a complexidade do modelo sem comprometer a 
capacidade de exibir os dados da maneira que os usuários requisitarem. 
 
5) Arquitetura cliente/servidor 
 
Figura: Ilustração da arquitetura cliente-servidori 
De forma grosseira, podemos dizer que a arquitetura cliente/servidor é um conceito da computação que 
implica na existência de um servidor de dados, que contém o sistema, e máquinas cliente, que acessam os dados 
contidos no servidor. 
Para entender como isso funciona, veja o caso do nosso site, o Direção Concursos. Você pode acessá-lo 
livremente através de sua máquina sem que precise instalar nada (além de um navegador de internet) ou mesmo 
baixar todo o conteúdo do site. O que acontece é que você vai navegando e clicando no que quer acessar, como 
você deve ter feito até chegar a este PDF. O download do PDF foi realizado através de uma requisição do cliente 
– o seu computador – ao servidor do Direção Concursos, que é a máquina que armazena todos os dados do site. 
Numa arquitetura cliente/servidor de uma ferramenta OLAP, os usuários não precisam instalar todos os 
sistemas utilizados ou salvar uma cópia completa dos dados armazenados no OLAP em seus dispositivos, basta 
possuir o lado cliente da aplicação, que permite se comunicar com o servidor. 
Dessa maneira, usuários de negócio podem acessar sistemas OLAP através de máquinas pouco poderosas, 
como telefones celulares ou computadores domésticos, sem que isso impacte na performance. Da mesma 
maneira, pode-se atualizar os dados no servidor sem causar impactos significativos nos dispositivos dos usuários. 
Os sistemas, assim, são mais abertos e modulares. 
 
6) Dimensionalidade genérica 
Os cubos não estão limitados a um número de dimensões, eles podem ter infinitas. As funções de análise dos 
sistemas OLAP devem permitir também que se trabalhe com cada uma delas indistintamente. 
 
 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
33 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
7) Capacidade de lidar com matrizes esparsas de forma dinâmica 
O nome é esquisito, mas a propriedade é relativamente tranquila de se entender. Uma matriz esparsa é uma 
estrutura bidimensional (ou seja, as tabelas, dimensões e fatos) que possui diversas células vazias. 
 Veja o caso, por exemplo, na hierarquia de locais de um determinado modelo dimensional: 
 
 
 
 Observe que, ao contrário do Brasil, o Vaticano não possui estados. Esse é o caso em vários outros países 
pequenos, que não têm a necessidade de dividir seu território dessa maneira. Quando tivermos várias ocorrências 
desse tipo na nossa tabela, poderemos considerá-la esparsa, já que o campo estado frequentemente estará vazio. 
 Essa regra nº 7 diz que as ferramentas OLAP devem ser capazes de lidar com essas ausências frequentes de 
dados, fornecendo funcionalidades para seu adequado tratamento - no exemplo acima, as consultas não deveriam 
simplesmente dar erro quando tentamos ver as vendas por estado para o Vaticano, e sim mostrar o valor total para 
sua única cidade sob a nomenclatura “Sem Estado”, por exemplo. 
 Essa regra também tem a ver com o armazenamento mais eficiente de dados, realizado utilizando-se de 
técnicas de compressão, que é uma abordagem que se aproveita desses valores em branco para diminuir o 
tamanho que o conjunto de dados ocupa no disco. 
 
8) Suporte a múltiplos usuários 
Os sistemas OLAP devem poder ser acessados por diversos usuários simultaneamente. Esses usuários, por 
sua vez, devem ser capazes de enxergar somente as fatias dos dados a que têm acesso, como já falamos a respeito 
durante a aula. 
 
 
 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
34 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
9) Operações de cruzamento dimensional ilimitadas 
Os usuários devem poder realizar todos os cálculos possíveis em relação às dimensões, mesmo que os 
relacionamentos adequados não tenham sido inicialmente definidos no modelo. Para isso, deve ser fornecida uma 
linguagem para a definição de fórmulas. 
Imagine que estamos calculando a média diária de vendas dos funcionários de uma empresa. Considere que 
a fato desse sistema OLAP contém os seguintes registros: 
 
Funcionário Dia Vendas 
José 06/09/2018 3 
José 07/09/2018 0 
José 08/09/2018 9 
 
 Veja que não podemos simplesmente calcular a média aritmética para o campo “Vendas”, pois, como o dia 
07/09/2019 foi um feriado, nenhum funcionário vai ter vendido nada nesse dia. Não podemos penalizar a média de 
José por não ter vendido nada em um dia sem expediente, seria injusto. 
 Dessa forma, precisamos ir além do relacionamento normal entre a tabela de vendas e a de datas, e definir 
uma fórmula alternativa para o cálculo desse índice de média diária que leve em conta a existência dos feriados. 
É mais ou menos isso que essa propriedade quer dizer!10) Manipulação intuitiva de dados 
Como os sistemas OLAP estão voltados para os usuários de negócio, essas ferramentas devem ser simples 
de se utilizar, permitindo que esses usuários realizem suas análises e manipulem os dados sem precisar de um 
vasto conhecimento técnico ou de um manual. 
 
11) Relatórios flexíveis 
Os usuários devem ser capazes de realizar os mais diversos tipos de consultas e análises com as ferramentas. 
As mudanças nos dados armazenados devem ser refletidas nos relatórios. 
 
12) Níveis de dimensões e agregações ilimitados 
Como o OLAP tem dimensões infinitas, também existem níveis de agregação infinitos para os dados! 
 
(CESPE – SEFAZ/RS – 2019) 
Com relação aos modelos de dados multidimensionais, assinale a opção correta. 
Prof. Arthur Mendonça 
 Aula 02 
 
 
35 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
a) A principal característica da tabela de fatos é a ausência de dados redundantes, o que melhora o desempenho 
nas consultas. 
b) Esses modelos são cubos de dados, sendo cada cubo representado por uma única tupla com vários atributos. 
c) Esses modelos proporcionam visões hierárquicas, ou seja, exibição roll-up ou drill-down. 
d) Os modelos de dados multidimensionais dão ênfase à coleta e às transações de dados. 
e) Esses modelos não utilizam processos de transferência de dados, mas sim acessos nativos do próprio SGBD 
utilizado. 
RESOLUÇÃO: 
a) O modelo dimensional tem como característica a desnormalização, algo que ocasiona redundâncias, mas 
facilita a extração de dados por diminuir a complexidade do modelo e o número de junções necessárias entre 
tabelas para se realizar as consultas. ERRADA 
b) Um cubo de dados possui inúmeras dimensões e registros, não somente uma tupla com seus atributos. ERRADA 
c) Essa é a resposta correta. Apesar da redação não ser das melhores, temos que os modelos multidimensionais, 
expressos nos sitemas OLAP, proporcionam ferramentas para se trabalhar com hierarquias, o que inclui as 
operações roll-up e drill down, que permitem aumentar ou diminuir o nível de detalhe das consultas analíticas. 
CERTA 
d) Os sistemas que dão ênfase à coleta e a múltiplas transações de dados são os sistemas OLTP, transacionais. 
ERRADA 
e) Os modelos dimensionais utilizam um processo de coleta, transformação e carregamento dos dados conhecido 
como ETL para a sua alimentação. Essa carga de dados é realizada de forma periódica e vai depender da estratégia 
cuidadosamente definida pela organização. ERRADA 
Gabarito: E 
 
(CESPE – SEFAZ/RS – 2019) 
O data warehouse diferencia-se dos bancos de dados transacionais porque 
a) trabalha com dados atuais, mas não com dados históricos. 
b) faz uso intenso de operações diárias e de processamento de transações continuamente. 
c) possui milhares de usuários de diferentes níveis hierárquicos dentro da organização. 
d) tem dimensionalidade genérica e níveis de agregação ilimitados. 
e) utiliza ferramentas de prospecção e consulta de dados baseadas em OLTP (on-line transaction processing). 
RESOLUÇÃO: 
a) O DW tem como umas de suas principais características ser variante no tempo e não volátil, ou seja, trabalha 
com dados históricos e não os atualiza! ERRADA 
b) Essa característica é dos sistemas transacionais, ou OLTP. Os data warehouse são carregados periodicamente 
através do processo de ETL. ERRADA 
Prof. Arthur Mendonça 
 Aula 02 
 
 
36 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
c) Como são voltados à tomada de decisão, os data warehouses geralmente são mais utilizados por gestores, 
tendo sua utilidade um pouco mais restrita em termos de números de usuários em relação aos sistemas OLTP. 
ERRADA 
d) Essa é a resposta correta! As regras de Codd para o modelo dimensional incluem a dimensionalidade genérica 
(regra que determina que todas as infinitas dimensões são tratadas indistintamente) e níveis de agregação 
ilimitados. CERTA 
e) OLTP são justamente os sistemas transacionais! ERRADA 
Gabarito: E 
 
Armazenamento 
 OLAP é um conceito de análise que diz respeito à interação com o usuário. O objetivo é fornecer uma série 
de conceitos e mecanismos que favorecem a análise de dados para subsidiar a tomada de decisão. 
 Contudo, você deve ter percebido que falamos muito em abstrações, como o próprio conceito de cubo, 
esquema estrela, etc., mas não falamos muito sobre como os dados ficam efetivamente armazenados em um 
banco de dados que segue a modelagem multidimensional. 
Há alguns tipos de armazenamento que um sistema OLAP pode utilizar: 
 
• MOLAP (Multidimensional OLAP): Os dados são extraídos das fontes e armazenados em uma estrutura 
multidimensional, não sendo necessário que se consulte diretamente dos bancos de dados da origem. 
Essa estrutura oferece uma performance de consulta maximizada, já que armazena diversos resultados 
pré-calculados de agregações e o acesso aos dados não é concorrente com os acessos à origem. 
 
• ROLAP (Relational OLAP): Os dados são consultados diretamente do banco de dados relacional. Por 
debaixo dos panos, são criadas views em cima do banco de dados relacional da organização para adaptar 
a estrutura de origem para o esquema multidimensional. Isso permite que sejam realizadas as análises no 
sistema OLAP. 
Esses sistemas ROLAP são escaláveis, ou seja, permitem que se trabalhe com grande volume de dados, 
mas há uma perda de performance considerável quando se trabalha com consultas complexas 
envolvendo muitas agregações e junções. 
 
• HOLAP (Hybrid OLAP): É uma combinação dos dois métodos acima. Agregações são armazenadas numa 
estrutura OLAP e dados mais detalhados são consultados a partir do banco de dados relacional. A 
performance, como era de se esperar, fica em um meio termo. 
 
 Veja a tabela a seguir para entender como é que funciona o armazenamento de dados em cada tipo de 
sistema OLAP: 
 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
37 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
 ROLAP MOLAP HOLAP 
Camada 
Multidimensional 
 
Agregações Pré-
Calculadas 
 
Valores em Nível de 
Detalhe 
 
 
 
(CESPE – TCE/PA – 2016) Julgue o item subsequente, acerca de segurança da informação de um SGBD e de um 
BI (Business Intelligence). 
MOLAP é um método utilizado para apresentar, fisicamente e em formato relacional, os dados em formato OLAP. 
RESOLUÇÃO: 
MOLAP armazena os dados em uma estrutura multidimensional, não relacional. Essa seria a definição de ROLAP. 
Gabarito: E 
 
(CESPE – MEC – 2015) Acerca dos conceitos de banco de dados transacionais (OLTP) e analíticos (OLAP), julgue 
o item que se segue. 
O ROLAP, sistema que se baseia na manipulação dos dados armazenados na base de dado relacional, apresenta a 
desvantagem de não lidar com grandes quantidades de dados. 
RESOLUÇÃO: 
Errado... o ROLAP lida sim com grandes quantidades de dados, principalmente porque não armazena dados pré-
agregados como o MOLAP. Quando a consulta a ser realizada é complexa, o ROLAP tende a perder performance 
em relação aos outros métodos. 
Gabarito: E 
 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
38 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
Tópicos Avançados 
Nesta seção vamos abordar alguns temas menos cobrados em provas de Análise de Informações, mas que 
podem ser explorados na prova desta disciplina, que deve ter um enfoque mais técnico! 
 
Modelagem de Dimensões 
Aqui traremos algumas situações específicas que ocorrem com as dimensões em um modelo dimensional. 
São alguns conceitos diferentes e sem muita ligação entre si, mas que você deve conhecer, pois são situações que 
são relativamente comuns no momento da criação ou evolução do modelo. 
Dimensões Degeneradas (Degenerate dimensions) 
Em determinados casos, principalmente emtabelas fato transacionais e de snapshot acumulativo, existem 
casos em que há uma chave que aponta para uma dimensão que não existe fisicamente. Parece estranho, mas 
pode fazer sentido! 
Um exemplo clássico dado por Kimball é o da dimensão pedido. É comum que um pedido (de vendas) em 
uma loja contenha vários itens. Por exemplo, você vai no seu site de compras favorito, adiciona vários produtos 
ao carrinho e paga tudo de uma vez só. 
O pedido em si não tem nenhuma grande informação, pois ele é uma mera composição dos itens 
comprados. Ou seja, para saber o valor do pedido, basta somar os valores individuais dos produtos. Para saber 
informações sobre os produtos vendidos, também se verifica os itens individuais, e assim sucessivamente. No 
entanto, é importante guardar pelo menos a chave primária que identifica unicamente um pedido, pois assim 
podemos saber que um determinado conjunto de itens pertencem a um determinado pedido. 
Nesses casos, temos que a tabela fato fica com uma espécie de chave de dimensão que referencia uma 
dimensão que, na prática, não possui uma tabela. Assim, essa chave de dimensão não é exatamente uma chave 
estrangeira, pois não há uma referência completa a uma linha em outra tabela. Veja: 
 
 
Figura: Tabela Fato com dimensão degenerada Pedido 
 
 Para terminar, algumas observações sobre as dimensões degeneradas: 
Prof. Arthur Mendonça 
 Aula 02 
 
 
39 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
Ø Dimensões degeneradas são úteis, por exemplo, para agrupar determinados registros da tabela fato 
com base na chave da dimensão. Assim, é possível calcular métricas agregadas como valor médio de 
uma venda. 
Ø Nas fatos de snapshot acumulativo, as dimensões degeneradas podem ser úteis para identificar os 
diferentes passos de um mesmo processo. Por exemplo, as diferentes etapas de um mesmo pedido 
podem ser rastreadas pelo número do pedido. 
Ø Pode haver mais de uma dimensão degenerada em uma mesma tabela fato. 
 
Dimensões Lixo (Junk dimensions) 
Como aponta Kimball, processos de negócio geralmente requerem que se represente alguns dados simples, 
como flags (bandeiras) e indicadores, que costumam ter baixa cardinalidade, ou seja, só podem assumir um 
conjunto pequeno de valores diferentes. 
Muitas vezes é pouco prático utilizar uma dimensão para cada um desses indicadores, pois isso acaba criando 
muitas dimensões para representar dados muito simples, que geralmente só podem assumir poucos valores 
distintos. Isso gera impacto na quantidade de chaves estrangeiras na tabela de fatos e na complexidade do modelo 
de modo geral. 
A solução para simplificar essa situação é agrupar todos esses indicadores em uma só dimensão, conhecida 
como dimensão lixo ou dimensão sucata. Esse tipo de dimensão possui uma chave primária convencional 
(geralmente substituta) e os valores para cada combinação de indicadores que ocorre na fato. Veja o exemplo: 
 
idDimensãoLixo Pedido Online Tipo do Frete Cliente Novo Venda a Prazo 
1 Sim Convencional Sim Não 
2 Sim Expresso Não Sim 
3 Não Convencional Não Não 
... ... ... ... ... 
 
 Assim, essa dimensão funciona como qualquer outra, sendo ligada à fato por sua chave em um 
relacionamento 1:n. A diferença é que seus atributos não costumam ter muita ligação entre si, sendo um 
amontoado de indicadores que servem a propósitos diversos. 
 
 
 
 
Prof. Arthur Mendonça 
 Aula 02 
 
 
40 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
Role-Playing Dimensions 
 Um outro caso particular que ocorre com dimensões é a quando uma mesma dimensão tem vários 
relacionamentos com a fato. Nesse caso, a dimensão atua em vários papéis diferentes em relação à fato, por isso 
sendo chamada de role-playing dimension. 
 Um exemplo muito comum desse tipo da dimensão ocorre em relação à tabela de Datas. Por exemplo, um 
pedido pode conter a data do pedido, a data do envio e a data da entrega. Seria um desperdício de espaço 
criarmos três dimensões de data distintas, já que elas iriam conter os mesmos valores entre si. Assim, fazemos 
várias ligações entre a fato e a mesma dimensão, cada uma dessas ligações representando um papel diferente. 
 Veja o exemplo: 
 
 
Figura: Dimensão role-playing Data 
 
 É comum que isso ocorra, por exemplo, em fatos de snapshot acumulativo, já que essas fatos costumam 
representar etapas de um mesmo processo. Como o elemento cronológico costuma ser importante nesse tipo de 
situação, deve haver diversas referências à tabela de datas. No entanto, não há impedimento para o uso nos 
demais tipos de tabela fato. 
Para terminarmos nossas considerações sobre as dimensões, note que é plenamente possível que tenhamos múltiplas 
hierarquias dentro de uma mesma dimensão. Por exemplo, podemos definir que na tabela de datas faz sentido criar uma 
hierarquia natural Ano -> Mês -> Dia, com o objetivo de permitir que os usuários naveguem livremente por esses períodos. 
No entanto, em alguns casos há análises que pedem um outro tipo de divisão hierárquica dentro da mesma dimensão. Por 
exemplo, pode ser necessário criar a hierarquia Ano -> Semestre -> Trimestre -> Bimestre. 
 
Slowly Changing Dimensions 
Como você já deve saber, os registros nas dimensões não costumam ser alterados, dada a propriedade da 
não volatilidade que é aplicável aos data warehouses. No entanto, mudanças nos valores de atributos acontecem 
no mundo real e precisam ser refletidas de alguma maneira nesses sistemas analíticos, de modo a manter as 
representações coerentes com os valores corretos ou atualizados. 
Prof. Arthur Mendonça 
 Aula 02 
 
 
41 de 78| www.direcaoconcursos.com.br 
Bancos de Dados para Analista – Tecnologia da Informação do TCE/RJ 
Por exemplo, se um cliente reside em um determinado estado do Brasil e posteriormente se muda para 
outro, as vendas devem ser associadas ao estado em que o cliente morava no momento em que o pedido foi 
realizado. Se o cliente morava em São Paulo quando fez pedidos no montante de R$ 500,00 e em Brasília quando 
fez pedidos no valor de R$ 300,00, o usuário do sistema analítico deve enxergar essa repartição de valores de forma 
correta entre os estados. Assim, é importante guardar esse histórico dos valores dos atributos. 
Em outros casos, mudanças de entendimento e de requisitos de negócio implicam a necessidade de 
atualização dos valores de atributos, pois o anterior passa a ser entendido como incorreto ou desatualizado. 
Nesses casos, como poderíamos proceder em um banco de dados considerado não volátil? 
Para lidar com essas variações, conhecidas como slowly changing dimensions (SCD), existem vários tipos de 
técnicas distintas. Kimball aponta que, dentro de uma mesma dimensão, podem ser adotadas técnicas diferentes 
de SCD para cada atributo que varia no tempo. 
Vamos ver quais são essas técnicas: 
 
Tipos de SCD (Kimball): 
Tipo 0: Manter original. No tipo zero, o valor do atributo da dimensão nunca muda. Por exemplo, como as 
chaves de dimensão devem ser substitutas, não deve surgir a situação em que há a necessidade de alterar seu 
valor. 
Tipo 1: Sobrescrever. Essa técnica é uma das mais simples utilizadas para se lidar com a mudança de valores de 
atributos. Nela, simplesmente se sobrescreve o valor anterior. Assim, se há a necessidade de modificar o 
atributo, se atualiza o registro. Note que esta propriedade implica uma perda do valor antigo. 
Imagine, por exemplo, que a empresa “Brinquedos Divertidos S.A.” quis ser mais moderna e alterou seu nome 
para Fun Toys. A empresa continua sendo a mesma, então não faz sentido termos algumas vendas para a 
empresa “Brinquedos Divertidos” e outras associadas a “Fun Toys”. Assim, simplesmente substituímos o 
registro da dimensão com o novo nome. 
Tipo 2: Adicionar novo registro. Esse tipo consiste em manter o histórico de alterações com o auxílio de 
atributos. Isso geralmente