ÍNDICE

SCROLL DOWN

A IMPORTÂNCIA
DA MODELAGEM DE DADOS IR PARA O TOPO
ÍNDICE Para entendermos a importância da Modelagem de Dados em um Data Warehouse, é fundamental relembramos

duas colocações importantes, detalhadas a seguir.

Inmon, considerado o pai do Data Warehouse, define DW como um conjunto de dados de apoio às

decisões gerenciais, integrado, não volátil, variável em relação ao tempo e baseado em assuntos.

Integrado: os dados são coletados a partir de uma variedade de fontes e fundidos em um todo

coerente.

Não volátil: nenhum dado pode ser alterado ou excluído no DW. Qualquer consulta a um dado

relativo a um período de tempo sempre produzirá o mesmo resultado; nenhum dado será excluído

enquanto não se tornar obsoleto para o negócio. Em soluções de BI específicas para alguns tipos

de negócio, isso pode ocorrer.

Variável em relação ao tempo: todos os dados no data warehouse são identificados com um

período de tempo particular. O DW é focado na manutenção do histórico.

Orientado ao assunto: possui dados que fornecem informações sobre um assunto específico em vez

de fazê-lo sobre as operações em curso de uma empresa.

Segundo Kimball (2011), “Ao processo de preparar os dados de um sistema de informação operacional

de forma a se ter uma fonte de informações que possam dar suporte à tomada de decisões deu-se o

nome de Data Warehousing”.

Os maiores influenciadores sobre DW, Inmon e Kimball (2011), citam dados e “apoio” ou “suporte” a decisões,

nas respectivas definições de Data Warehouse. Juntando as colocações, percebemos que tais dados provêm de

sistemas de informações operacionais e devem ser preparados, para serem armazenados por assuntos, de

forma não volátil e variável em relação ao tempo, para servirem de fonte de informações, utilizadas para su‐

porte a decisões.

Portanto, a Modelagem de Dados é, por necessidade, parte fundamental da estrutura e do processamento de

uma solução DW, pois o modelo deve ser capaz de comportar o armazenamento de todos os dados relevantes,

para apoio à tomada de decisões, bem como, prover alto desempenho de acesso, requisito fundamental para

processamentos analíticos complexos.

Neste capítulo, apresentaremos duas técnicas básicas de modelagem para DW, a já conhecida Modelagem Enti‐

dade Relacionamento (MER) e a Modelagem Dimensional. Apresentaremos as diferenças entre as duas aborda‐

gens e nos aprofundaremos na técnica Dimensional, por ser a abordagem amplamente adotada para modela‐

gem de soluções DW e DM na atualidade.

ABORDAGENS TÉCNICAS

Existem duas abordagens principais para a modelagem de dados em um DW. Inmon defende a criação de mo‐

delos baseados em entidade relacionamento. Kimball (2011), por sua vez, propôs a técnica de modelagem di‐

mensional, basicamente formada por tabelas dimensionais e fato.

IR PARA O TOPO
ÍNDICE No capítulo sobre BI, comentamos que as soluções de Inteligência de Negócios evoluíram rapidamente para o

conceito de autoatendimento, possibilitando aos usuários sem conhecimento técnico selecionar dados de diver‐

sas fontes e combiná-los de forma livre, para fins de análise, geração de relatórios dinâmicos e tomada de deci‐

sões. Também comentamos que, para dar aos usuários tal capacidade, simplicidade é fundamental. Para nave‐

gar, selecionar e cruzar os dados sozinhos, os usuários precisam compreender a modelagem do banco de da‐

dos, sem grandes dificuldades.

PRÓS E CONTRAS DO MER EM UM DW

O modelo Entidade-Relacionamento é uma técnica de modelagem de Banco de Dados que tem como objetivos

o armazenamento estruturado, otimizado, consistente e, por fim, com o menor nível de redundância de dados

possível.

Devido às regras de normalização e à criação das entidades atendendo a tais regras, geralmente, a interpreta‐

ção e o entendimento de modelos ER são realizados com facilidade apenas por especialistas.

Modelagens ER possuem fortíssima semelhança com banco de dados modelados para o controle de transações

diárias. A técnica ER aplica, no DW, os mesmos elementos básicos aplicados nos sistemas OLTP:

Entidades;

Relações entre entidades;

Atributos.

Conceitos como herança e o mecanismo de constraint também são empregados. Podemos dizer que apenas

uma característica que é minimizada como uso em modelos ER para sistemas OLTP é maximizada para o uso

em DW, o emprego de atributos calculados. Esse tipo de atributo reduz a necessidade de cálculos em tempo de

processamento, aumentando a performance de consultas complexas.

Como já vimos, nesse tipo de banco de dados, o acesso é realizado incluindo atributo a atributo, através de

queries SQL, geralmente com quantidades elevadas de junções entre tabelas e perda de performance, a cada

junção adicionada na query.

Não existe uma adequação que facilite a navegação do usuário pelas entidades, requerendo que eles possuam

habilidades técnicas. Ponto contrário à tendência crescente no mercado, de adotar soluções de autoatendi‐

mento para suporte a decisões.

Nem todos os pontos são negativos, modelos ER para DW, por natureza, controlam a redundância de dados,

fato que, se bem explorado, pode gerar uma economia de espaço físico. Outro aspecto comum é que, adotando

essa abordagem de modelagem, o reaproveitamento do modelo OLTP é maior, em poucos aspectos, reduzindo

os esforços da equipe de modelagem.

Perceba que os pontos positivos são essencialmente técnicos e não geram valor ao usuário da solução DW,

mais um fator para o mercado adotar a Modelagem Dimensional como abordagem predominante.

MODELAGEM DIMENSIONAL
Kimball afirma que a Modelagem Dimensional é uma técnica de design diferente do tradicional modelo ER, utili‐

zado nos sistemas de caráter operacional. A abordagem dimensional tem como objetivo criar bancos de dados
IR PARA O TOPO
ÍNDICE para suporte à decisão, que apresentem os dados de uma maneira padronizada, intuitiva e que permitam

acesso de alto-desempenho.

A modelagem dimensional é amplamente aceita como abordagem preferida em soluções DW, porque atende a

dois requisitos importantes:

Entrega dados compreensíveis para os usuários;

Provê desempenho em consultas.

A modelagem dimensional é uma técnica para se elaborar modelos de dados como um conjunto de medidas

que são descritas e acessadas por aspectos comuns do negócio. É especialmente útil para organizar, consultar,

filtrar, sumarizar, detalhar e suportar a análise de dados.

CONCEITOS BÁSICOS

A modelagem dimensional possui três conceitos básicos:

FATO

Fato é uma coleção de dados relacionados que representam um evento do negócio, usado em um DW ou

DM, para análise e tomada de decisões empresariais. Em um Data Warehouse ou Data Mart, cada fato é re‐

gistrado em uma linha de uma tabela também chamada de Fato, que trata um processo específico do

negócio.

Como exemplo, em um modelo que abrange o processo de Vendas, a tabela Fato pode receber o nome de

FATO_VENDAS e deve possuir, em cada linha, um item de uma venda, armazenado, principalmente, em

atributos numéricos conhecidos como medidas.

Nesse exemplo, o item de venda é chamado de grão. Segundo Kimball, definir o grão é o passo fundamen‐

tal de um design dimensional. O grão deve estabelecer exatamente o nível de detalhe que será armaze‐

nado em uma linha da Tabela Fato. Portanto, o grão deve ser definido antes de escolhermos as dimensões

e deve ser o mais atômico possível.

Falaremos sobre grão mais à frente.

MEDIDAS

DIMENSÕES

DATAS

ENDEREÇO

Para exemplificarmos, o resultado de uma query a partir de um dia aleatório, como 03/06/2000, em uma di‐

mensão Data, retornaria algo como a imagem a seguir.

IR PARA O TOPO
ÍNDICE

Fig. 1 - Consulta a dimensão data

É muito comum ter cargas de mais de 20 anos em uma dimensão Data, cada 20 anos geram aproximadamente

7.300 linhas na tabela, cada linha será um dia do período inserido. As cargas dessa tabela e das demais do Mo‐

delo Dimensional serão vistas no capítulo sobre ETL.

EXEMPLO DE MODELO DIMENSIONAL

Quando comentamos sobre medidas aditivas, utilizamos, como exemplo, a obtenção da somatória do lucro

bruto, de um determinado produto, vendido no ano de 2016.

Essa consulta será facilmente realizada pelo usuário, quando ele selecionar o produto através do atributo

nm_produto, da DIM_PRODUTO e o ano de 2016, filtrando-o pelo atributo ano, da DIM_DATA. Em uma solução

de BI, tal operação será realizada por uma ferramenta, dispensando quaisquer conhecimentos técnicos por

parte do usuário. O importante é que o Modelo seja simples e facilmente navegável.

IR PARA O TOPO
ÍNDICE

DIM_PROMOCAO

P * sk_promocao
nk_promocao
nm_promocao
ds_promocao
Outros...

DIM_VENDEDOR DIM_PRODUTO

P * sk_vendedor P * sk_produto
FATO_VENDAS
nk_vendedor nk_produto
nm_vendedor PF * sk_data nm_produto
dt_nascimento PF * sk_cliente ds_produto
ds_sexo PF * sk_vendedor nk_marca
dt_contratacao PF * sk_promocao nm_marca
Outros... PF * sk_loja Outros...
PF * sk_produto
P * dd_nota_fiscal
qbd_vendida
vl_preco_unitario
vl_custo_unitario
DIM_DATA vl_desconto_unitario DIM_LOJA
vl_total_preco
P * sk_data
P * sk_loja
vl_total_custo
data
nk_loja
vl_total_desconto
data_extenso
nm_loja
vl_lucro_bruto
ano
ds_endereco
Outros...
semestre
ds_bairro
trimestre
ds_zona
bimestre
ds_cidade
mes
ds_estado
feriado
ds_regiao
Outros...
Outros...

DIM_CLIENTE

P * sk_cliente
nk_cliente
nm_cliente
dt_nascimento
ds_sexto
Outros...

Fig. 2 - Modelo dimensional sobre vendas

Olhando o modelo, é fácil perceber que Modelos Dimensionais, implementados em Banco de Dados Relacionais,

possuem as mesmas características da modelagem ER, mas com os três conceitos básicos (Fato, Medidas e Di‐

mensões) empregados como restrições.

Todo modelo dimensional possui, no mínimo, uma tabela com chave composta, chamada de tabela Fato, relaci‐

onada com um conjunto de tabelas chamadas Dimensões. Cada dimensão deve possuir uma chave primária

simples (Surrogate Key), correspondente a uma das chaves estrangeiras e que, juntas, formam a chave com‐

posta da tabela Fato.

SURROGATE KEYS, NATURAL KEYS E SMART KEYS

SURROGATE KEYS NATURA

Analisando o Modelo Dimensional de exemplo, percebemos que as chaves primárias das dimensões Note que a

são simples e, pela nomenclatura adotada, possuem, no nome do campo, o sufixo sk. com os de

pois possi
Sk ou Surrogate key é uma chave substituta para a chave primária natural dos dados de origem. Uma
como filtro
sk deve ser um identificador único, numérico do tipo inteiro e sequencial, gerado para cada linha de
origem.
uma entidade dimensional. Em geral, a primeira linha deve ser preenchida com o valor 1, a segunda,

com o valor 2 e assim por diante.

Sks não têm valor reconhecido pelo cliente, servem exclusivamente para relacionar as tabelas em um

modelo dimensional, portanto, não devem ser visíveis e, muito menos, manipuláveis pelos usuários.

Como sabemos, as tabelas do modelo dimensional sofrerão cargas de dados, obtidos no(s) sistema(s)

de origem (OLTP). Durante tais cargas, as Surrogate Keys deverão ser geradas automaticamente pelo

programa responsável ou ferramenta de ETL.

IR PARA O TOPO
ÍNDICE

DIMENSÕES DEGENERADAS

Com os nossos olhos novamente sobre o modelo, podemos identificar um atributo que faz parte da chave com‐

posta da tabela Fato, não é uma FK dimensional e possui um sufixo diferente, dd.

O sufixo corresponde ao conceito de Dimensão Degenerada, que, de forma simplificada, é uma dimensão que

não possui atributos descritivos relevantes para análise, apenas uma chave natural, absorvida pela tabela Fato.

Pois bem, no sistema de origem, uma venda é modelada com o conceito de tabela pai “NF” e tabela filha “Item

da Nota Fiscal”, cada item da Nota Fiscal será carregado pelo ETL e gerará uma linha na tabela FATO_VENDAS.

Esse é o nosso grão. Dúvida: como podemos saber a qual NF o item vendido pertence?

Podemos analisar os fatos por produto, data, cliente, vendedor, loja e promoção, mas e por NF?

Para esse tipo de situação, que não requer uma dimensão só para um atributo, o conceito de Dimensão Dege‐

nerada é aplicável. O número da NF correspondente será gravado junto com as medidas, em cada linha da Fato,

pelo processo ETL.

STAR SCHEMA
Star Schema ou modelo estrela são termos comumente utilizados como sinônimos de modelos dimensionais. Se

repararmos novamente em nosso exemplo, a tabela Fato é o centro da estrela e as Dimensões são as pontas

dela. Como schema é um termo mais técnico, star model ou modelo estrela acabaram sendo os nomes mais

adotados pelo mercado.

DIM_PROMOCAO

DIM_VENDEDOR DIM_PRODUTO

FATO_VENDAS

DIM_DATA DIM_LOJA

DIM_CLIENTE

Fig. 3 - Star Schema

STAR SCHEMA, CUBES, OLAP, ROLAP E MOLAP

OLAP (Processamento Analítico On-Line, em português) é a capacidade de manipular e analisar um grande vo‐
IR PARA O TOPO
lume de dados através de múltiplas perspectivas e assim, monitorar os fatos e os indicadores mais relevantes da
ÍNDICE organização para a tomada de decisões.

Modelos dimensionais implementados em SGDBs relacionais são conhecidos como modelos estrela, pela seme‐

lhança que vimos com o formato de uma estrela. Como o armazenamento dos dados é feito em um banco rela‐

cional, esse tipo de implementação leva o nome de ROLAP (Relational On-Line Analytical Processing).

Já os modelos dimensionais implementados em banco de dados multidimensionais são conhecidos como cubos

MOLAP (Multidimensional On-Line Analytical Processing). Os dados, nesse tipo de implementação, são armaze‐

nados em formatos proprietários de cada ferramenta. As duas implementações OLAP permitem que os pró‐

prios usuários explorem, analisem e respondam a perguntas relevantes para o negócio, por meio de visões

dimensionais.

Portanto, os projetos lógicos dimensionais são iguais para os dois tipos de implementação, mas os projetos físi‐

cos são diferentes, face às diferenças de armazenamento de cada ferramenta ou SGBD. Este capítulo foca em

modelos dimensionais para SGDBs relacionais, mas boa parte do conteúdo pode ser aproveitada em projetos

lógicos para bancos multidimensionais.

A abordagem utilizando bancos relacionais possibilita que ferramentas OLAP construam as visões dimensionais

a partir dos dados armazenados em modelos dimensionais, utilizando as técnicas de ER, aplicando as restrições

que apresentamos até este ponto. Esse tipo de implementação se beneficia da maturidade dos SGBDs em

ações importantes, tais como, backup e recovery e escapa de particularidades exclusivas, portanto indesejáveis,

de soluções MOLAP.

Soluções MOLAP eram reconhecidas pela maior performance em análises utilizando cubos, mas essa vantagem

diminuiu consideravelmente, com os avanços em hardware e com o aumento exponencial de dados; no entanto,

ainda existem características positivas como capacidades mais ricas de análise e suporte a hierarquias muito

complexas, mas tais vantagens variam muito de ferramenta para ferramenta.

DIM_PROMOCAO

Produto
DIM_PRODUTO
Promoção

FATO_VENDAS
ja
Lo

DIM_LOJA

Cliente

DIM_CLIENTE

Fig. 4 - Star Schema – OLAP Cube

Comparando graficamente cada abordagem, percebemos que as pontas da estrela são as faces do cubo e, cada

vez que o usuário busca uma análise por um atributo de uma dimensão ou por um campo da face do cubo, ele
IR PARA O TOPO
ÍNDICE acessa uma perspectiva dimensional sobre os dados que serão analisados.

Como comentamos, independentemente da implementação, soluções OLAP permitem que os próprios usuários

explorem, analisem por perspectivas e respondam a perguntas do tipo:

Qual loja vendeu mais em valores financeiros neste ano?

Qual loja vendeu mais em valores financeiros, no primeiro trimestre deste ano, por região?

SNOWFLAKE
Snowflake, ou floco de neve, é uma variação do modelo estrela que normaliza uma ou mais dimensões que te‐

nham hierarquia interna, com o objetivo de economizar espaço. Esta variação permite que existam tabelas com‐

plementares que se relacionem com as dimensões, além dos relacionamentos existentes entre dimensões e fato.

O floco de neve ainda é um modelo dimensional, mas as dimensões seguem a terceira forma normal (3NF) da

técnica ER.

DIM_PROMOCAO DIM_PRODUTO

DIM_DATA

FATO_VENDAS

DIM_LOJA
DIM_VENDEDOR
DIM_CLIENTE

TBL_LOGRADOURO TBL_BAIRRO TBL_CIDADE TBL_ESTADO TBL_REGIAO

Fig. 5 - Exemplo de Snowflake

O modelo floco de neve reduz o espaço de armazenamento dos dados dimensionais, mas acrescenta várias ta‐

belas ao modelo, deixando-o mais complexo para os softwares que utilizarão o banco de dados dimensional e

mais complexa a navegação do usuário final pelo modelo. De fato, muitos especialistas argumentam que a eco‐

nomia representada pela redução do espaço de armazenamento não é significante, pelo tamanho economizado

ou pela redução de custos de armazenamento.

Outro fator importante é que mais tabelas serão utilizadas para executar uma consulta, então, mais JOINS SQL

serão feitos, impactando a performance. Nos dias de hoje, performance X armazenamento possui forte tendên‐

cia pela priorização da performance em momentos de tomada de decisão.

IR PARA O TOPO
ÍNDICE

BOAS PRÁTICAS
EM PROJETOS DE DW/BI

No livro The Data Warehouse Toolkit, o uso de práticas de desenvolvimento ágeis é encorajado, pois muitos dos

princípios fundamentais estão alinhados com as melhores práticas de Kimball, tais como:

Foco em entregar valor ao negócio. Esse tem sido o mantra de Kimball por décadas;

Potencializar a colaboração entre a equipe de desenvolvimento e partes interessadas no negócio;

Comunicação face a face, feedback e constante priorização com as partes interessadas no negócio;

Adaptar-se rapidamente às inevitáveis evoluções de requisitos;

Realizar o desenvolvimento de forma iterativa e incremental.

PROCESSO DE
DESIGN DIMENSIONAL

Em um projeto típico, antes de iniciar a modelagem dimensional, a equipe que realizará o trabalho precisa ques‐

tionar e compreender muito bem as necessidades do negócio, bem como identificar as reais condições dos da‐

dos de origem.

Os requisitos de negócio devem ser levantados por meio de reuniões de entendimento, envolvendo tomadores

de decisão ou seus representantes, para que a equipe de modelagem entenda os objetivos de análise, utili‐

zando como base indicadores de desempenho. A equipe deve levantar os processos de negócio envolvidos,

compreender a dinâmica das tomadas de decisão, de acordo com o nível gerencial ou natureza do objeto de

análise e identificar as necessidades analíticas de suporte, para que as decisões sejam tomadas da melhor

forma possível.

Em paralelo, a cada objetivo de análise entendido, consultas devem ser feitas às documentações e aos especia‐

listas dos sistemas OLTP selecionados como fonte dos dados de origem, para avaliar a existência e as reais pos‐

sibilidades de extração desses dados.

Ainda se apoiando em Kimball (2011), o autor sugere um conjunto de técnicas que orienta em quatro passos as

principais decisões que devem ser feitas durante o processo de design de uma modelagem dimensional.

Os quatro passos sugeridos são:

Selecione o processo;

Determine o grão;

IR PARA O TOPO
Identifique as dimensões;
ÍNDICE Identifique os fatos.

APLICANDO EM UM CENÁRIO HIPOTÉTICO

Imagine uma rede com 50 lojas de departamentos, espalhadas em quatro regiões do país, cada loja possui

aproximadamente 30.000 produtos disponíveis para venda e, em face da crise, a gerência está preocupada em

aumentar as vendas e maximizar o lucro. A rede de lojas utiliza promoções que ofertam descontos, publicadas

e divulgadas em panfletos, nos sistemas de som das lojas e nas rádios locais.

Saber o que está dando certo é muito importante e, nesse momento, deve ser potencializado.

SELECIONE O PROCESSO
Ao primeiro passo, cabe a decisão de qual ou quais processos serão possíveis de serem modelados, por meio

do cruzamento dos requisitos de negócios para análise, com o levantamento dos dados disponíveis.

O primeiro modelo deve focar as questões mais críticas (FCS) para os usuários, desde que factíveis. A ideia de

“factíveis” envolve diversas considerações, tais como, a disponibilidade dos dados, sua qualidade e o compro‐

misso da organização em relação ao contexto.

No cenário descrito, a questão mais crítica identificada junto aos tomadores de decisão foi um melhor entendi‐

mento das compras dos clientes. Sendo assim, o processo de negócio que será modelado é a transação de ven‐

das, possibilitando a análise de quais produtos estão vendendo mais, em quais lojas, períodos e condições

promocionais.

DETERMINE O GRÃO
Após a identificação do processo, encontramos uma importante e crítica tomada de decisão sobre granulari‐

dade dos dados.

Qual o nível de detalhe sobre vendas que ficará disponível no modelo dimensional?

O objetivo que devemos manter em mente é prover aos usuários o nível de detalhe mais atômico, possível de

ser capturado no processo de negócio que selecionamos para modelar.

Segundo Kimbal, quanto mais detalhada e atômica for a medida dos fatos, mais coisas saberemos com certeza.

No processo escolhido, o grão adequado é o item vendido, ou seja, o item da nota fiscal, pois nele está o maior

nível de detalhe da venda.

Se, por engano, escolhêssemos como grão a nota fiscal e não o item da nota, não conseguiríamos descobrir os

produtos que mais venderam, pois eles são relativos ao item da nota e não à nota fiscal. Lembrando que: uma

nota fiscal é composta por um ou mais itens e cada item possui um produto, vendido em uma quantidade igual

ou superior a 01.

Apesar do que explicamos, em outras situações, a equipe pode, por sua conta e risco, escolher uma granulari‐

dade mais alta, uma agregação de um dado atômico. Entretanto, a escolha do grão em um nível mais alto limi‐

tará a modelagem a relacionar um número menor de dimensões e/ou envolver dimensões menos detalhadas.

Uma escolha desse tipo, com certeza, deixará o modelo dimensional vulnerável e insuficiente, caso os usuários
IR PARA O TOPO
apresentem novos requisitos, com maior profundidade nos detalhes em que eles pretendem mergulhar.
ÍNDICE Nesses casos, Kimball salienta que os usuários se defrontarão com um muro analítico, pois será impossível visu‐

alizar os detalhes dos dados nas consultas, uma vez que serão extraídos dos sistemas OLTP, sumarizados e gra‐

vados sem os detalhes no modelo dimensional, pelo processo de ETL.

Sendo assim, em nosso exemplo, o grão adequado continua sendo o item da nota fiscal.

IDENTIFIQUE AS DIMENSÕES

Definido o grão da tabela Fato, a identificação das dimensões primárias é o próximo passo e elas surgem natu‐

ralmente, considerando as perspectivas pelas quais o negócio pretende analisar, os relacionamentos que o grão

possui na fonte de origem dos dados e aplicando uma técnica chamada 5w3h, adaptada da área de administra‐

ção, que funcionará como um mecanismo de melhor entendimento do modelo e de identificação das principais

dimensões.

Dia > Loja >

Mês > When Where Endereço >
Trimestre ... Cidade >
Estado ...

Aumentar
Produtos Vendas
What How Much Medidas Why
Promoções Melhorar
How Many de Vendas
Rentabilidade

Vencedores
Clientes Who How Será decidido...

Identificam as dimensões mais comuns

Fig. 6 - Técnica 5w3h

Técnica 5w3h aplicada, encontramos:

IR PARA O TOPO
ÍNDICE

DIM_PROMOCAO

P * sk_promocao

FATO_VENDAS

PF * sk_data
DIM_DATA
DIM_PRODUTO
PF * sk_cliente
P * sk_data PF * sk_vendedor P * sk_produto
PF * sk_promocao
PF * sk_loja
DIM_VENDEDOR PF * sk_produto
DIM_LOJA
P * dd_nota_fiscal
P * sk_vendedor P * sk_loja

DIM_CLIENTE

P * sk_cliente

Fig. 7 - Dimensões primárias

Identificadas as dimensões primárias, a sugestão é seguir para o próximo passo, ainda não é o momento de

mergulhar na definição de todos os atributos das dimensões primárias. Novas dimensões podem surgir, e pior, a

equipe pode perder a visão geral do design, se envolvendo nos detalhes. A equipe deve se aprofundar no final

do último passo.

IDENTIFIQUE OS FATOS
O último passo do design é responsável por determinar cuidadosamente os fatos que aparecerão na tabela

Fato. Novamente, a declaração do grão ajudará na definição dos atributos que aparecerão na tabela.

Os tomadores de decisão estão especialmente interessados ​em analisar as métricas de desempenho e os deta‐

lhes sobre o que o processo de negócio deve medir deverá ser informado por eles.

Todos os fatos candidatos devem ser verdadeiros para o grão já definido. Fatos que não pertençam ao grão de‐

vem ser pensados em uma tabela Fato separada ou gerar uma revisão no grão escolhido. A equipe não deve

tentar criar adaptações, elas não funcionarão. Fatos típicos são medidas numéricas, como a quantidade ven‐

dida, o preço unitário, o custo unitário, o desconto unitário, o valor total, o custo total, o desconto total e o lucro

bruto.

IR PARA O TOPO
ÍNDICE

DIM_PROMOCAO

P * sk_promocao

FATO_VENDAS
DIM_DATA
PF * sk_data DIM_PRODUTO
P * sk_data
PF * sk_cliente
P * sk_produto
PF * sk_vendedor
PF * sk_promocao
PF * sk_loja
PF * sk_produto
P * dd_nota_fiscal
qbd_vendida
vl_preco_unitario
vl_custo_unitario
vl_desconto_unitario
vl_total_preco
vl_total_custo
DIM_VENDEDOR
vl_total_desconto DIM_LOJA
P * sk_vendedor vl_lucro_bruto
P * sk_loja

DIM_CLIENTE

P * sk_cliente

Fig. 8 - Fatos identificados

Os totais serão muito utilizados por análises feitas por todas as dimensões. Os usuários poderão realizar opera‐

ções de slice e dice pelos atributos das dimensões sem se preocupar, pois cada soma dessas medidas será vá‐

lida e correta.

Uma recomendação importante é resistir à tentação de modelar dando mais atenção às documentações dos

sistemas ou aos especialistas envolvidos com os dados da fonte, do que conversando com as pessoas de negó‐

cios. A origem é importante, mas ela não reflete o que o negócio precisa saber.

Por fim, dados calculados devem ser persistidos ou não?

Kimball geralmente recomenda que sejam armazenados fisicamente e computados consistentemente

pelo ETL, eliminando a possibilidade do usuário ou alguém de TI calcular errado;

O custo de um usuário que tome decisões sobre um dado calculado erroneamente supera o custo de

armazenamento;

O armazenamento garante que todos os usuários e aplicações de BI façam referências aos dados

calculados de forma consistente.

Ao terminar a identificação dos Fatos, a equipe deve se debruçar nos detalhes das dimensões primárias e nos

detalhes de quaisquer outras dimensões que tenham surgido durante os quatro passos.

Como estamos trabalhando com um cenário hipotético, vamos apresentar sugestões de atributos mais comuns

para as dimensões.

ATRIBUTOS COMUNS PARA A DIMENSÃO DATA

Para que o usuário analise adequadamente todas as medidas, elas devem ser apresentadas em contextos apro‐

priados. Tais contextos sempre possuem um elemento envolvendo datas. Portanto, recomenda-se, sempre, a
IR PARA O TOPO
ÍNDICE criação de uma dimensão para tanto. Alguns autores utilizam como nome “dimensão tempo”, outros utilizam

“dimensão data” e outros, ambos os nomes, dependendo da granularidade necessária para a análise.

Imagine que o contexto analisado precise ser filtrado por dia, mas, em certos casos, por hora do dia. Uma carga

de 20 anos, dia a dia, já é considerável. Imagine com 24 linhas para cada dia, se considerarmos tudo na mesma

dimensão.

Em situações específicas como essa, podemos considerar a criação de duas dimensões, uma representando os

dias, no período de décadas, e a segunda, com 24 linhas, representando a quantidade de horas de um dia. Com

ambas relacionadas a Fato, podemos saber facilmente o dia e a hora em que o evento ocorreu.

Vários atributos são relevantes, de acordo com o negócio, por exemplo, marcar se no dia possui ou faz parte de

um evento, ou se o dia é anterior ou posterior a um evento podem ser informações muito relevantes. Você acha

que a Oktoberfest não influencia a venda de cervejas em Blumenau?

DIM_DATA

P * sk_data
data
data_extenso
ano
mes
mes_extenso
mes_abreviado
semana_mes
semana_ano
dia_mes
dia_semana
dia_semana_extenso
dia_semana_abreviado
dia_dds_fds
dia_ano
ano_bissexto
feriado
feriado_extenso
pre_feriado
pos_feriado
quinzena_mes
quinzena_ano
bimestre
trimestre
semestre
bimestre_ano
trimestre_ano
semestre_ano
estacao_ano
ultimo_dia_mes
ultimo_dia_
ultimo_dia_bimestre
ultimo_dia_semestre
evento
pre_evento
pos_evento
Outros...

Fig. 9 - Dimensão data

ATRIBUTOS COMUNS PARA A DIMENSÃO PRODUTO

A DIM_PRODUTO costuma ter muitos registros a mais do que a quantidade de produtos atualmente vendida,

pois contém produtos não mais disponíveis como histórico de vendas.

A hierarquia dos produtos geralmente possibilita vários grupamentos: Por exemplo, um produto pode ser agru‐

pado por marca, que, por sua vez, pode ser agrupada em categorias e essas, depois, em departamentos. Esse

tipo de análise é muito usual e ajuda muito os tomadores de decisão, ampliando o entendimento e reduzindo

tempo.

Outros atributos que não fazem parte da hierarquia de produtos geralmente devem estar presentes, pois são

importantes. Veja o tipo de embalagem.

Esse atributo pode conter valores, tais como: garrafa, caixa, saco ou outro qualquer, que, em determinados con‐

textos, podem ser relevantes aos analistas de negócio. Portanto, devemos resistir à tentação de normalizar essa
IR PARA O TOPO
dimensão.
ÍNDICE

DIM_PRODUTO

P * sk_produto
nk_produto
nm_produto
ds_produto
nk_marca
nm_marca
nk_tipo_marca
ds_tipo_marca
nk_subcategoria
nm_subcategoria
nk_categoria
nm_categoria
nr_departamento
ds_departamento
ds_tipo_embalagem
nr_largura_embalagem
nr_altura_embalagem
nr_peso
nr_prazo_validade
dt_incio_venda
dt_fim_venda
Outros...

Fig. 10 - Dimensão produto

ATRIBUTOS COMUNS PARA A DIMENSÃO PROMOÇÃO

Essa é uma das dimensões mais importantes para o nosso cenário hipotético. Relembramos que por meio dessa

dimensão será possível entender sob quais condições um produto foi vendido.

Podemos realizar, por ela, as seguintes análises:

Análise do ganho de vendas;

Quedas de vendas no período anterior ou após a promoção;

Análise de ganho e perda relacionados;

Análise de ganho total de vendas;

Análise da lucratividade da promoção.

IR PARA O TOPO
ÍNDICE

DIM_PROMOCAO

P * sk_promocao
nk_promocao
nm_promocao
ds_promocao
ds_publico_alvo
ds_objetos_promocao
ds_tipo_promocao
ds_cupom_desconto
ds_categoria_promocao
ds_tipo_midia
nr_percentual_desconto
qtd_minima
qtd_maxima
dt_inicio
dt_fim
vl_custo_promocao
Outros...

Fig. 11 - Dimensão promoção

Somente a dimensão Promoção pode nos fornecer maneiras tão ricas de cruzar dados tão diferentes, tais

como: “Qual o efeito da primeira promoção que combinou uma redução do preço de vendas, com cartazes na

entrada da loja?”.

Perceba, existem várias condições causais possíveis, altamente correlacionadas.

Importante: como o relacionamento entre a dimensão promoção e a tabela fato é identificado, devemos

criar um registro do tipo “Nenhuma Promoção em Vigor”, para todos os casos de vendas, sem nenhuma

promoção associada.

ATRIBUTOS COMUNS PARA A DIMENSÃO LOJA

A dimensão Loja armazena todas as lojas da rede que estamos analisando e possibilita a análise por outra pers‐

pectiva muito importante, a perspectiva geográfica.

Por exemplo, os usuários podem iniciar a análise por uma cidade e fazer o Roll Up para estado, região e país. Ou

começar pelo país e fazer Drill Down até chegar à cidade.

IR PARA O TOPO
ÍNDICE

DIM_LOJA

P * sk_loja
nk_loja
nm_loja
ds_loja
ds_endereço
ds_bairro
ds_zona
ds_cidade
ds_estado
ds_regiao
ds_tipo_loja
nr_metros_quadrados
ds_cep
ds_tipo_planta
dt_abertura_loja
dt_ultimo_reforma
nm_gerente
Outros...

Fig. 12 - Dimensão loja

ATRIBUTOS COMUNS PARA A DIMENSÃO VENDEDOR E CLIENTE

Essas dimensões possuem informações sobre os vendedores e os clientes da rede, ambos os casos variam

muito em relação à forma como a rede de lojas hipotética trata informações pessoais. Em geral, a dimensão

vendedor será utilizada para análise de performance por classe, grau de instrução, departamento, entre outras.

Em relação aos clientes, a rede precisa criar mecanismos para conhecê-los, como cartão fidelidade e descontos

por perfil.

Da mesma forma sugerida na dimensão promoção, devemos criar um registro do tipo “Cliente não identifi‐

cado”, para todos os casos de vendas, nos quais o cliente não queira se identificar.

DIM_VENDEDOR

P * sk_vendedor
nk_vendedor
nm_vendedor
ds_estado_civil
nr_dependentes
DIM_CLIENTE
ds_grau_instrucao
bo_grau_intru_completo P * sk_cliente
nk_classe_vendedor nk_cliente
ds_classe_vendedor nm_cliente
nk_departamento ds_estado_civil
ds_departamento nr_dependentes
nk_superior_imediato ds_grau_instrucao
nm_superior_imediato bo_grau_intru_completo
dt_nascimento nk_classe_cliente
ds_sexo ds_classe_cliente
dt_contratacao dt_nascimento
dt_liberacao ds_sexo
bo_atualmente_contratado dt_cliente_desde
Outros... Outros...

IR PARA O TOPO
ÍNDICE Fig. 13 - Dimensões vendedor e cliente

A DIMENSÃO DEGENERADA
O número da nota fiscal, apesar de ser uma perspectiva de análise, não dá origem a uma dimensão. Em casos

nos quais o grão representa uma única transação de um conjunto reconhecido pelo negócio é muito comum ter

uma dimensão degenerada, representando tal conjunto.

Número de Nota Fiscal, Número de Pedido e Número da Prescrição Médica, usualmente, dão origem a dimen‐

sões vazias que são representadas por meio de dimensões degeneradas em tabelas Fato. No nosso exemplo, te‐

mos como DD o número da nota fiscal.

FATO_VENDAS

PF * sk_data
PF * sk_cliente
PF * sk_vendedor
PF * sk_promocao
PF * sk_loja
PF * sk_produto
P * dd_nota_fiscal
qbd_vendida
vl_preco_unitario
vl_custo_unitario
vl_desconto_unitario
vl_total_preco
vl_total_custo
vl_total_desconto
vl_lucro_bruto

Fig. 14 - Exemplo dd_nota_fiscal

ESTRELA OU CENTOPEIA
Quando identificamos um número muito grande de dimensões, devemos avaliar se entre elas existem dimen‐

sões dependentes ou parcialmente independentes.

Nessas situações, Kimball recomenda a combinação de duas ou mais dimensões em uma única e considera

como um erro de modelagem a representação de elementos de uma hierarquia, como dimensões separadas na

tabela de Fatos.

Como parâmetro, qualquer modelo que exceda a 15 dimensões deve ser alvo de melhor análise.

DIMENSÕES QUE MUDAM LENTAMENTE

(SLOWLY CHANGING DIMENSIONS)
IR PARA O TOPO
ÍNDICE Imagine uma situação na qual um fabricante altera o tipo de embalagem de um produto. Apesar de não aconte‐

cer com frequência, essa mudança impacta a dimensão. O que devemos fazer?

Vamos olhar as três opções mais adotadas para tratar Slowly Changing Dimensions ou SCD.

1 2 3

Atualizar o valor, gravando o novo por cima do valor antigo.

Solução simples, mas que não preserva histórico. Ou seja, se vendíamos leite em saquinho e ele passou

a ser engarrafado, ao gravarmos por cima, todas as vendas anteriores serão enxergadas como um pro‐

duto engarrafado.

DIMENSÕES QUE MUDAM RAPIDAMENTE

(RAPIDLY CHANGING MONSTER DIMENSIONS)

Imagine outra situação: desta vez estamos fazendo um modelo dimensional para uma empresa que pratica,

mensalmente, o rodízio de funcionários por área demográfica. Já conhecemos técnicas para tratar mudanças

em dimensões, mas as técnicas que vimos resolvem bem mudanças esporádicas. Pensando na solução mais

adotada, criar uma linha, todo mês, para cada funcionário, com o objetivo de registrar a área atual não é uma

boa solução, concorda?

Para esses casos, particionar a dimensão é uma boa solução, deixe os dados estáticos em uma parte e acomode

os dados voláteis em uma segunda. Ou seja, crie uma dimensão para tratar apenas os dados demográficos. A

aplicação dessa técnica gera dimensões menores, conhecidas como mini dimensões.

TIPOS ESPECIAIS
DE DIMENSÕES E TABELAS

JUNK DIMENSION OUTRIGG

Um tipo de dimensão abstrata para acomodar a decodificação de flags e indicadores de baixa cardi‐ É o nome

nalidade, evitando que eles fiquem na tabela Fato.

IR PARA O TOPO
ÍNDICE

CONCLUSÃO

O objetivo deste conteúdo foi abordar o básico e essencial sobre Modelagem Dimensional. Neste capítulo, apre‐

sentamos a importância da modelagem de dados em um DW, as diferentes abordagens técnicas de modela‐

gem, os conceitos básicos de modelagem dimensional e as boas práticas de projeto.

Tais conteúdos geraram a base necessária para a aplicação das técnicas em um cenário hipotético, por meio do

qual foi possível apresentar uma sugestão de processo para design dimensional e exemplificar tabelas fato, di‐

mensões e atributos mais comuns.

Ao final, foram apresentadas técnicas para lidar com mudanças em dimensões e alguns tipos de dimensões

especiais.

Antes de o usuário tomar qualquer decisão a partir de um Data Warehouse, é necessário passarmos por um

processo de extração, transformação e carga de dados: o famoso ETL vem aí!

LISTA DE VÍDEOS

06:21 05

QUER SE APROFUNDAR MAIS?

IR PARA O TOPO
ÍNDICE

REFERÊNCIAS 

BALLARD, Chuck et al. Dimensional Modeling: In a Business Intelligence Environment. IBM-International

Technical Support Organization, 2006.

______. Data modeling techniques for data warehousing. IBM Corporation International Technical Support

Organization, 1998.

GONÇALVES, Marcio. Extração de dados para Data Warehouse. Rio de Janeiro/RJ: Axcell Books, 2003.

HAHN, Seungrahn et al. Capacity planning for business intelligence applications: Approaches and

methodologies. IBM Redbooks, 2000.

INMON, William H. Building the data warehouse. John wiley & sons, 2005.

KIMBALL, Ralph; CASERTA, Joe. The Data Warehouse ETL Toolkit: Practical Techniques for Extracting,

Cleaning, Conforming, and Delivering Data. John Wiley & Sons, 2011.

KIMBALL, Ralph; ROSS, Margy. The data warehouse toolkit: the complete guide to dimensional modeling.

John Wiley & Sons, 2011.

KIMBALL GROUP. Slowly Changing [Link]ível em: <[Link] Acesso em: 15 dez.

2017.

______. Role-Playing Dimensions. Disponível em: <[Link] . Acesso em: 15 dez. 2017.

______. Multivalued Dimensions and Bridge Tables. Disponível em: <[Link] Acesso em: 15

dez. 2017.

______. Design Tip #105 Snowflakes, Outriggers, and Bridges. Disponível em: <[Link]

Acesso em: 15 dez. 2017.

______. Design Tip #113 Creating, Using, and Maintaining Junk Dimensions. Disponível em:

<[Link] Acesso em: 15 dez. 2017.

______. Add Mini-Dimension. Disponível em: <[Link] Acesso em: 15 dez. 2017.

MACHADO, Felipe Nery Rodrigues. Tecnologia e Projeto de Data Warehouse: uma visão multidimensional.

Érica, 2006.

REINSCHMIDT, Joerg; FRANCOISE, Allison. Business intelligence certification guide. IBM International

Technical Support Organisation, 2000.

SINGH, Harry S. Data warehouse: conceitos, tecnologias, implementação e gerenciamento. Tradução Mônica

Rosemberg. Makron Books: São Paulo, 2001.

TURBAN, Efraim et al. Business Intelligence: um enfoque gerencial para a inteligência do negócio. Bookman

Editora, 2009.

IR PARA O TOPO