Você está na página 1de 29

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  Desvantagens
 Isolamento entre  Requer outra
Sistemas Transacionais modelagem de dados
e Sistemas Gerenciais  Requer mais
 Ajuste melhor dos administração de
bancos de dados para servidores
seus diferentes fins  Requer constante carga
 Maior flexibilidade de dados
permitindo o  A transferência de dados
desenvolvimento de entre servidores
diferentes aplicações demanda mais infra-
gerenciais estrutura de
comunicação

Tipo de Processamento :
OLTP x OLAP
 OLTP  OLAP
 On-line transactional  On-line analytical
processing processing
 transações pontuais (1  “Pequeno” número de
registro por vez) consultas “variáveis”
 Muita atualização  centenas, milhares, ... de
 Resultados de consultas registros por consulta
com poucos registros  Oferece Diferentes
 Consultas pontuais e perspectivas sobre os
pouco exploradas 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