Data Warehousing

Modelagem Dimensional
Maria Cláudia Reis Cavalcanti

Roteiro

Conceitos

Arquitetura

Modelagem Dimensional

Passo a passo
Contexto

Desde 1970
 Automação dos processos

Sistemas transacionais ou operacionais
 Organizações ganham competitividade
 Crescente quantidade de bancos de dados

Uso dos dados para apoiar decisões
estratégicas

Sistemas nao foram projetados para este fim

Sistemas sem integração

Nos anos 90 surge o Data Warehouse

Conceitos

“Data Warehouse é uma coleção de dados
orientada por assunto, integrada, variante no
tempo e não volátil que tem por objetivo dar
suporte aos processos de tomada de decisão.”
-- -- INMON 1993

O DW tem como objetivo prover “uma imagem

única da realidade do negócio” – HACKARTORN
 ou seja, integrar os dados da empresa para viabilizar
a análise desses dados sob uma ótica administrativa.
 Conceitos

Orientada a assunto
 Na empresa há vários temas a tratar - Produtos, clientes,
vendas - que vão além das aplicações (sistemas
transacionais)

Integrada
 Os vários BDs por trás das aplicações de uma empresa
precisam ser integrados de modo consistente para prover
visão única

Variante no tempo
 Dados válidos apenas para um intervalo de tempo
 Dados representam vários instantes (snapshots)

Não volátil
 Não há atualização em tempo real
 É periodicamente atualizado (janelas de tempo)
 Apenas inclusão de registros (não há updates)

Sistemas Transacionais X
Sist. de Apoio a Decisão (Gerenciais)
Transacionais: Apoio a Decisão:

Consultas, alterações e
Não-Volátil (foco nas
inserções (transação) consultas)

Foco no registro
Foco no conjunto de

Representa o tempo registros (agregados)

presente
Envolve tempos

Procura resolver passados, presentes e

problemas específicos futuros

Voltado para análises
 Transacionais X Gerenciais

Aplicações Consultas,
Transacionais Análises,
Vários Aplicações
Bancos Analíticas
Por favor, reserve o de Dados Ferramentas
assento 2B no vôo OLAP
231... Quantos vôos
originaram-se de
Congonhas com mais de
80% de ocupação em
1998...

Um único banco de dados

não atende bem a ambos as aplicações!

Consultas típicas - Gerenciais

What was the total revenue for Scotland in the third quarter of
2004?

What was the total revenue for property sales for each type of
property in Great Britain in 2003?

What are the three most popular areas in each city for the
renting of property in 2004 and how does this compare with the
figures for the previous two years?

What is the monthly revenue for property sales at each branch
office, compared with rolling 12-monthly prior figures?

What would be the effect on property sales in the different
regions of Britain if legal costs went up by 3.5% and
Government taxes went down by 1.5% for properties over
£100,000?

Which type of property sells for prices above the average selling
price for properties in the main cities of Great Britain and how
does this correlate to demographic data?

What is the relationship between the total annual revenue
generated by each branch office and the total number of sales
staff assigned to each branch office?
 Transacionais X Gerenciais
Como consultar TODOS
os bancos de dados transacionais ao mesmo tempo?

OLTP OLTP

Aplic.
Gerencial  Não existe integração
 Não existe uniformidade
OLTP  Não existe confiabilidade
 Custos de operação muito altos
 Manutenção difícil

Caracterizando Separadamente

BDs Transacionais BDs Gerenciais

• constituídos de • constituídos de
dados granulares dados sumarizados
• usualmente tem • usualmente os
dados de poucas dados provêm de
fontes múltiplas fontes
• Atualizações • consultas intensivas
frequentes nos com atualizações
dados em modo batch
• Dados atuais • Dados históricos
 BDs separados

Vantagens
 Isolamento entre
Sistemas Transacionais
e Sistemas Gerenciais
 Ajuste melhor dos
bancos de dados para
seus diferentes fins
 Maior flexibilidade
permitindo o
desenvolvimento de
diferentes aplicações
gerenciais
Tipo de Processamento :
OLTP x OLAP

OLTP
 On-line transactional
processing
 transações pontuais (1
registro por vez)
 Muita atualização
 Resultados de consultas
com poucos registros
 Consultas pontuais e
pouco exploradas

Desvantagens
 Requer outra
modelagem de dados
 Requer mais
administração de
servidores
 Requer constante carga
de dados
 A transferência de dados
entre servidores
demanda mais infra-
estrutura de
comunicação

OLAP
 On-line analytical
processing
 “Pequeno” número de
consultas “variáveis”
 centenas, milhares, ... de
registros por consulta
 Oferece Diferentes
perspectivas sobre os
dados
 Operações de agregação
e cruzamentos
 Atualização quase
inexistente, apenas
novas inserções
 Data Warehouse: revendo definição
“Data Warehouse é um processo,
não um produto. Ele é uma forma de
apropriadamente construir e gerenciar
dados oriundos de diversas fontes com
o propósito de obter desde uma simples
visão de partes, até uma visão global de
todo um negócio.” Building the
Data Warehouse
STEPHEN R.
GARDNER
ACM Communications
Vol.9, September, 1998

Arquitetura Distribuída
Ambiente Ambiente Ambiente Ambiente do Ambiente Usuário
Transacional de Extração de Data Data Mart
Warehouse Front-End

Base
Operational
Ferramentas
ETL
Data Mart
Relacional
Q Query Tools

Data Mart Data Mining

Entidades
Externas Data
Relational
e /Staging
ou
Area
Data
OLAP Tools
Warehouse
Procedimentos
Listas
BIS, EIS,
Externas DataMart MD DSS

Gerenciador
de Campanhas

Abordagem usada para permitir uma evolução gradual do Data Warehouse

Arquitetura do DW

Ambiente transacional
 Bds legados
 Bds externos (de outras organizações)
 Web (bds, textos, documentos)

Ambiente de extração
 Procedimentos e Ferramentas de ETL

extração, Transformação e Carga (load)

Nem tudo pode ser automatizado
 Operational Data Store

Data staging area (área de manobra): Área de preparação para a Carga
no BD do Ambiente do DW
 Visa garantir a qualidade dos dados

acurado, pois é importante que os usuários finais confiem na qualidade
dos dados fornecidos.

corretivo, pois a detecção de erros nos dados deve sempre promover a
sua correção.

transparente, pois é importante mostrar que os erros detectados são
sempre corrigidos.

rápido, pois o processamento de grandes volumes de dados abre pouca
margem para atrasos.

Arquitetura do DW

Ambiente do DW
 Dados já agregados e prontos para consulta analítica
 Índices para melhorar desempenho
 Política de backup
 Política de arquivamento
 Auto ajuste: materialização de agregações e indexação
conforme consultas dos usuários

Ambiente dos Data Marts
 “Um Data Mart é um subconjunto lógico do Data
Warehouse, geralmente visto como um data warehouse
setorial.” [Kimball]
 Mais simples, menor custo de construção, melhor
desempenho, menor número de usuários

Ambiente do usuário
 OLAP, mineração de dados, reports, aplicações, etc.
 Arquitetura Centralizada
Ambiente Ambiente Ambiente Ambiente Usuário
Transacional de Extração de Data
Warehouse Front-End

Base
Operational
Ferramentas
Q Query Tools

Data Mining
Entidades
Externas Data
e /Staging
ou
Area
Data OLAP Tools
Warehouse
Procedimentos
Listas BIS, EIS,
Externas DSS

Quando a empresa tem um entendimento claro sobre suas necessidades de acesso

Ambiente
Arquitetura Virtual ~ mediadores
Ambiente Ambiente Usuário
Transacional de Extração
Front-End

Base
Operational
Query Tools
Ferramentas

Data Mining
Entidades
Externas Data
e /Staging
ou
Area
OLAP Tools

Procedimentos
Listas BIS, EIS,
Externas DSS

Quando há pouca demanda pelos dados, ou quando é necessário

estudar a real necessidade dos usuários de um Data Warehouse
 Metadados

Vital para o ambiente de DW

Podemos identificar pelo menos 3 tipos:
 Metadados operacionais

Metadados sobre os dados do BD transacional,

Origem dos dados

 Metadados centrais

Transformações,

Sumarizações,

Cálculos, fórmulas,

Estratégias de limpeza

 Metadados do usuário

índices de qualidade dos dados, padrões de acesso

Building the
Data Warehouse
STEPHEN R.
GARDNER
ACM Communications
Vol.9, September, 1998
Modelagem de Dados
para Data Warehouses

Modelagem Dimensional

Visão Multidimensional

Implementações do modelo
Dimensional

Esquema Estrela e Snowflake

Modelagem de Dados
para Data Warehouses

Modelagem Dimensional
 Simplicidade

Fatos e dimensões
 Flexibilidade no suporte às análises

várias visões sobre os dados
 Fatos ou variáveis identificam dados a
analisar
 Estes dados podem ser expressos segundo
diferentes parâmetros ou dimensões
 Modelagem de Dados
para Data Warehouses
Unidades

Visão Vendidas
multidimensional
L TIJUCA 4 5 8
O
J URCA 3 6 5
A
GRAJAÚ 6 8 4

MUZZ CALAB MARG

SABOR

Cubos

Os cubos são uma metáfora visual para fatos
(variáveis) associados a 3 dimensões

Para toda combinação de valores de dimensão
há uma célula no cubo para armazenar o dado
correspondente

L Tijuca
O
J Urca

A Grande
Botafogo Média TAMANHO
Brotinho
Muzz Calab Marg

SABOR
 Hipercubos

Cubos com mais de 3 dimensões

L
M
O
Mini Van Mini Van Mini Van

O
D
E
Coupe Coupe Coupe

L Carr Carr Carr

J Sedan
Gleason Sedan Gleason Sedan Gleason
Clyde Clyde Clyde
TAMANHO
DEALERSHIP
A Blue Red White Blue Red White Blue Red White

COLOR
SABOR SABOR
COLOR COLOR
SABOR

Janeiro Fevereiro Março

Categorias

Os valores que uma dimensão pode
assumir são chamados de categorias

Cada dimensão pode conter uma
grande quantidade de categorias

É comum que as categorias de cada
dimensão sejam organizadas de forma
hierárquica, formando as hierarquias
de dimensão

As hierarquias são a base para as
agregações
 Hierarquias
Dimensão Geografia Uma mesma dimensão pode
País apresentar mais de uma categoria

Instâncias Brasil

Região Região
Fiscal
SE NE

Estado Distritos

SP RJ PE BA
Municípios

Campinas Rio de Janeiro Macaé Recife Olinda Salvador

Agregados

As hierarquias permitem que o usuário

possa ter acesso a dados com maior ou
menor detalhe

Os valores apresentados quando o
analista consulta dados em níveis
hierárquicos mais altos são valores
agregados
Exemplo

Qual a margem de
contribuição de cada
área de vendas?

“O Share Nielsen de AS JJ98

é 14 para GUIMBA e
25 para MUAMBA.”

Share Nielsen = fração de mercado de um produto

AS = supermercados
JJ98 = bimestre junho-julho em 1998
GUIMBA = nome de uma marca
MUAMBA = nome de uma outra marca
 Nesta visão analisamos como foi o suporte promocional (dias de promoção)
para cada SKU, por tipo de promoção

Implementação do Modelo
Dimensional

SGBDs multidimensionais
 implementam fisicamente o modelo
dimensional
 problemas de desempenho qdo são muitas
dimensões
 Esparsidade: células onde não há dados

SGBDs relacionais
 Maior aceitação
 Exige adaptação
 SGBD Multidimensional X Relacional

Totais de Unidades Vendidas

LOJA SABOR UNID.

L TIJUCA 4 5 8 Vendidas
O
TIJUCA MUZZ 4
J IPANEMA 3 6 5
A TIJUCA CALAB 5
GRAJAÚ 6 8 4 TIJUCA MARG 8
IPANEMA MUZZ 3
MUZZ CALAB MARG IPANEMA CALAB 6
SABOR
IPANEMA MARG 5
GRAJAÚ MUZZ 6
GRAJAÚ CALAB 8
GRAJAÚ MARG 4

Esquema Estrela
Uma tabela de fatos cercada de tabelas de dimensões
 Esquema Estrela
Um exemplo:

Dimensão TEMPO
Fatos de
VENDAS Dimensão PRODUTO
Cod_tempo Cod_produto
Cod_tempo
DataCompleta descrição
Cod_produto
Mes categoria
Cod_loja
Quadrimestre marca
Vendas_reais
Ano
Vendas_unidades
Flag_feriado
Custos_reais
Dimensão LOJA
Cod_loja
Nome_loja
endereço
cidade
estado

Consulta SQL sobre um esquema estrela

select Qtd Vendida
Loja.Estado, Tempo.DataCompleta,
Produto.Descricao,
de cada Produto
Sum( Vendas.Vendas_unidades) as Total por Estado e
from por Data
Vendas, Tempo, Produto, Loja
where
Vendas.CodTempo = Tempo.CodTempo and
Vendas.CodProduto = Produto.CodProduto and
Vendas.CodLoja = Loja.CodLoja
group by
Loja.Estado, Tempo.DataCompleta, Produto.Descricao
order by
Tempo.DataCompleta, Loja.Estado,
Produto.Descricao
 Resultados
Estado DataCompleta Descricao Total
================================================
CA Oct 1, 1994 Athletic Drink 57
CA Oct 1, 1994 Beef Stew 128
CA Oct 1, 1994 Buffalo Jerky 202
CA Oct 1, 1994 Chicken Dinner 161
CA Oct 1, 1994 Clear Refresher 73
CA Oct 1, 1994 Dried Grits 102
CA Oct 1, 1994 Dry Tissues 16
CA Oct 1, 1994 Extra Nougat 442
CA Oct 1, 1994 Fizzy Classic 46
CA Oct 1, 1994 Fizzy Light 65
CA Oct 1, 1994 Lasagna 162
CA Oct 1, 1994 Lots of Nuts 248
CA Oct 1, 1994 Onion Slices 120

Tabela de Fatos

Grande volume de dados

Chave composta
 referencia cada tabela de dimensão
Fatos de

Histórica
VENDAS

Variáveis/Fatos Cod_tempo
 Usualmente numéricos Cod_produto
 tipicamente aditivos Cod_loja
Vendas_reais

Armazenamento de agregados Vendas_unidades
 Agiliza consultas Custos_reais
 Critérios de escolha do que for mais útil
 Onde armazenar: tabela de fatos auxiliar?
 Tabelas de Dimensão

Volume Dimensão LOJA
Cod_loja
comparativamente Nome_loja
menor endereço
cidade

Chave simples estado

Descrevem os fatos

Atributos usados como
filtro nas consultas CodLoj Nome End Cidade Estado
1 Saraiva … Rio RJ

Hierarquias implícitas 2 Sodiler … Rio RJ

Desnormalizada => 3 Travessa … Rio RJ
redundâncias …

Tabelas de Dimensão

Segundo KIMBALL, as tabelas de

dimensão não devem ser
normalizadas pois:
1) não há atualização freqüente nas bases;
2) o espaço em disco economizado é
relativamente pequeno e;
3) esse ganho de espaço não justifica a
perda de performance na realização de
consultas por conta dos joins necessários
em caso de normalização.
 Esquema Snowflake
Refinamento do esquema estrela onde as hierarquias das dimensões são
representadas explicitamente através da normalização das tabelas de dimensões
Tabelas de dimensões normalizadas
Fato
Cliente Fato Vendas Vendedor

Código Cliente Data Código Vendedor

Nome Cliente Código Vendedor Nome Vendedor
Código Atividade Código Produto Código Região
Código Segmento Código Cliente
Valor da Venda Dimensão
Quantidade
Margem Vendedor Região
Margem %
Código Região
Atividade Nome Região
Código Atividade
Descrição

Produto Grupo
Segmento
Código Produto Código Grupo
Código Segmento
Nome Produto Nome Grupo
Descrição
Código Grupo

Dimensão Cliente Dimensão Produto

Esquema Constelação de Fatos

Múltiplas tabelas de fatos com dimensões
compartilhadas
 Maior complexidade
 Esquema Constelação de Fatos

Time Dimension Shipping Fact

time_key
Product Dimension time_key
day_of_week
product_key product_key
month
quarter Sales Fact description from_location_key
brand to_location_key
year
time_key category shipper_key
holiday_flag
product_key dollar_cost
location_key units_shipped
dollar_sold Location Dimension
unit_sold loc_key Shipper Dimension
dollar_cost loc_name
address shipper_key
city shipper_name
state location_key

Ferramentas OLAP

Ferramentas para visualização dos
dados em um DW

Funcionalidades típicas
 Pivoteamento ou rotação
 Slice (projeções sobre o cubo)
 Dice (seleções sobre o cubo)
 Roll up/Drill down (agregações ou
detalhamento)
 Drill accross (através de diferentes tabelas
de fatos)
Modelando um DW dimensional

Segundo Kimball [DW Tookit]
1 Selecionar o processo da empresa
 Definir para cada tabela de fatos:
2 o nível de detalhe (granulosidade)
3 as dimensões
4 os fatos e suas unidades de medida
5 os atributos das dimensões
6 amplitude de tempo do DW
7 Como rastrear mudanças nas dimensões
8 aspectos de armazenamento físico
9 periodicidade de extração, transformação e carga

Passo 1: Selecionando o Processo

Esquema da Imobiliária DreamHome

 Passo 1: Selecionando o Processo

Processo de Vendas da Imobiliária

Passos 2 e 3:
Granulosidade e
dimensões
• Decidir o que um fato
representa
• Ex: uma venda de
propriedade

• Identificar as dimensões
envolvidas no fato

• Dimensão tempo é incluída

• “Conformed dimension
tables” : dimensões usadas
em mais de uma tabela de
fatos (2 Data marts)

• Grão da dimensão também

é definido aqui
• Ex: venda no dia ou no
mês? Venda por tipo de
promocao ou por
promocao?
Passo 4: Identificando Fatos

O que se quer
acompanhar?

Devem estar no nível do
grão do fato
 Ex: todos os fatos devem
se referir a um aluguel:

rentDuration

totalRent

ClientAllowance

staffCommission

TotalRevenue

Devem ser numéricos e
aditivos
 Podem ser semi-aditivos
 Ex. %totalRent no ano: soma
só por ano

Podem ser pré-calculados
 TotalRevenue = TotalRent
 – ClientAllowance
 - StaffCommission

Passo 5: Detalhando Dimensões

Qto mais rica a dimensão
mais útil pode ser o Data
Mart

Descrever
 Nome, descrição, sexo do staff

Categorizar
 Para cada dimensão que
categorias usar?
 Usar taxonomias ou padroes

Hierarquias
 City, region, country
 Exemplo de tabela Tempo

week
day day day week week week begin month
date day of num in num day abbre weekday num in num begin date num month month
key full date week month overall name v flag year overall date key month overall name abbrev
1 1/1/96 1 1 1 Monday Mon y 1 1 1/1/96 1 1 1 January Jan
2 1/2/96 2 2 2 Tuesday Tue y 1 1 1/1/96 1 1 1 January Jan
3 1/3/96 3 3 3 WednesdayWed y 1 1 1/1/96 1 1 1 January Jan
4 1/4/96 4 4 4 Thursday Thu y 1 1 1/1/96 1 1 1 January Jan
5 1/5/96 5 5 5 Friday Fri y 1 1 1/1/96 1 1 1 January Jan
6 1/6/96 6 6 6 Saturday Sat n 1 1 1/1/96 1 1 1 January Jan
7 1/7/96 7 7 7 Sunday Sun n 1 1 1/1/96 1 1 1 January Jan
8 1/8/96 1 8 8 Monday Mon y 2 2 1/8/96 8 1 1 January Jan
9 1/9/96 2 9 9 Tuesday Tue y 2 2 1/8/96 8 1 1 January Jan

Passo 6: Amplitude de tempo

Por quanto tempo a tabela de fatos vai
acumular fatos?
 Ultimos 5 anos?
 Por quanto tempo se quer observar e analisar?

Surgem questões de desempenho e de

rastreamento de mudanças
 Ex. Nova versão de um produto, novo endereço do
proprietário
Passo 7: Como rastrear mudanças
nas dimensões

Vamos imaginar que um vendedor é transferido para uma filial
em outra cidade, e agora precisamos implementar um relatório
de vendas, agrupados por vendedores e filiais, comparando
performance de vendas entre os vendedores. Se o vendedor foi
transferido para outro estado com um mercado aquecido, onde
as vendas não são tão fáceis, podemos ter problemas, pois em
uma análise comparativa entre vendedores, as vendas do
vendedor transferido podem parecer absurdamente exageradas
em comparação com os outros

Staff_Key Staff_Code Staff_Name Staff_State

123 ABC Alfredo Neves CA

IL

Passo 7: Como rastrear mudanças

nas dimensões

Manter o histórico de mudanças ao

longo do tempo
Staff_Key Staff_Code Staff_Name Staff_State Version

123 ABC Alfredo Neves CA 0

124 ABC Alfredo Neves IL 1

Staff_Key Staff_Code Staff_Name Staff_State StartDate EndDate

123 ABC Alfredo Neves CA 11/03/2009 01/12/2010
124 ABC Alfredo Neves IL 02/12/2010
Questões críticas para modelagem
dimensional

Foco nos requisitos e objetivos do negócio
 Não na tecnologia e nos dados

Envolvimento do patrocinador e usuários gerenciais é
essencial para o sucesso

Adote uma abordagem incremental e iterativa para o
desenvolvimento do DW
 Não tente fazer tudo de uma vez

Desempenho das consultas do usuário e facilidade de uso
são os fatores mais críticos
 Otimização de consultas OLAP

Apresente os dados de forma simples, e com a semântica
clara

Nível de detalhe deve chegar até os dados atômicos

Esteja preparado para mudanças no negócio e nos dados

Dê especial atenção à aceitação dos usuários

Exercício

Suponha o exemplo da concessionária
Xcar já apresentado, onde um gerente
geral de marketing deseja analisar o
volume de vendas dos modelos de carro
de cada fornecedor em cada cidade de
cada estado dos EUA, onde a
concessionária possua filiais. Especifique
um esquema estrela para esta
concessionária. Dê alguns exemplos de
consultas e análises que poderiam ser
úteis para o gerente.
 Exercício

Concessionária XCar

M
M Mini
MiniVan
Van Mini
MiniVan
Van Mini
MiniVan
Van
O
O
O
D
D Coupe
Coupe Coupe
Coupe Coupe
Coupe
D
E
E
E
L Sedan
Sedan
Carr
Carr
Gleason
Gleason
Sedan
Sedan
Carr
Carr
Gleason
Gleason
Sedan
Sedan
Carr
Carr
Gleason
Gleason Fornecedor
DEALERSHIP
L
L NY LA Madison
Madison
Clyde
Clyde
NY LA Madison
Clyde
Clyde
NY LA Madison
Madison
Clyde
Clyde
NY LA NY LA Madison NY LA
O
CITY CITY CITY
Cidade cidade cidade

Janeiro
JANUARY FEBRUARY
Fevereiro MARCH
Março