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õesestraté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 (sistemastransacionais)
� Integrada� Os vários BDs por trás das aplicações de uma empresa
precisam ser integrados de modo consistente para provervisã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:� Consultas, alterações e inserções (transação)
� Foco no registro� Representa o tempo presente
� Procura resolver problemas específicos
Apoio a Decisão:� Não-Volátil (foco nas consultas)
� Foco no conjunto deregistros (agregados)
� Envolve tempos passados, presentes e futuros
� Voltado para análises
Aplicações
Transacionais
Aplicações
Transacionais
Consultas,
Análises,
Aplicações
Analíticas
Ferramentas
OLAP
Consultas,
Análises,
Aplicações
Analíticas
Ferramentas
OLAP
VáriosBancosde DadosPor favor, reserve o
assento 2B no vôo
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!
Transacionais X Gerenciais
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
OLTP
Aplic.Gerencial �Não existe integração
�Não existe uniformidade
�Não existe confiabilidade
�Custos de operação muito altos
�Manutenção difícil
Como consultar TODOS os bancos de dados transacionais ao mesmo tempo?
OLTPOLTP
Caracterizando Separadamente
BDs Transacionais • constituídos de dados granulares
• usualmente tem dados de poucas fontes
• Atualizações frequentes nos dados
• Dados atuais
BDs Gerenciais • constituídos de dados sumarizados
• usualmente os dados provêm de múltiplas fontes
• consultas intensivas com atualizações em modo batch
• 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
� 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
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
� 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
Q Query ToolsQuery Tools
OLAP ToolsOLAP Tools
Data MiningData Mining
Base Operational
EntidadesExternas
Ferramentas
ETL
Ferramentas
ETL
e / oue / ou
ProcedimentosProcedimentos
Data
Warehouse
BIS, EIS,
DSS
BIS, EIS,
DSSDataMart MD
Data Mart
Relacional
Data Mart
Relational
ListasExternas
Gerenciador
de Campanhas
Gerenciador
de Campanhas
Ambiente
Transacional
Ambiente
de Extração
Ambiente
de Data
Warehouse
Ambiente Usuário
Front-End
Ambiente do
Data Mart
Abordagem usada para permitir uma evolução gradual do Data Warehouse
Data Staging
Area
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, melhordesempenho, menor número de usuários
� Ambiente do usuário� OLAP, mineração de dados, reports, aplicações, etc.
Arquitetura Centralizada
Q Query ToolsQuery Tools
OLAP ToolsOLAP Tools
Data MiningData Mining
Base Operational
EntidadesExternas
FerramentasFerramentas
e / oue / ou
ProcedimentosProcedimentos
Data
Warehouse
BIS, EIS,
DSS
BIS, EIS,
DSSListas
Externas
Ambiente
Transacional
Ambiente
de Extração
Ambiente
de Data
Warehouse
Ambiente Usuário
Front-End
Quando a empresa tem um entendimento claro sobre suas necessidades de acesso
Data Staging
Area
Arquitetura Virtual ~ mediadores
Query ToolsQuery Tools
OLAP ToolsOLAP Tools
Data MiningData Mining
Base Operational
EntidadesExternas
FerramentasFerramentas
e / oue / ou
ProcedimentosProcedimentosBIS, EIS,
DSS
BIS, EIS,
DSSListas
Externas
Ambiente
Transacional
Ambiente
de Extração
Ambiente Usuário
Front-End
Quando há pouca demanda pelos dados, ou quando é necessário
estudar a real necessidade dos usuários de um Data Warehouse
Data Staging
Area
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
� Visão multidimensional
4 5 8
3 6 5
6 8 4
LOJA
TIJUCA
URCA
GRAJAÚ
MUZZ CALAB MARG
SABOR
UnidadesVendidas
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
Tijuca
Urca
Botafogo
Muzz Calab Marg
Brotinho
Média
Grande
LOJA
SABOR
TAMANHO
Hipercubos
� Cubos com mais de 3 dimensões
MODEL
Mini Van
Coupe
Sedan
Blue Red White
ClydeGleason
Carr
COLOR
Coupe
Sedan
Blue Red White
ClydeGleason
Carr
COLOR
DEALERSHIP
Mini Van
Coupe
Sedan
Blue Red White
ClydeGleason
Carr
COLOR
Janeiro Fevereiro Março
Mini VanLOJA
SABOR SABOR SABOR
TAMANHO
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
País
Região
Estado
Municípios
Distritos
RegiãoFiscal
SE
RJ
Rio de Janeiro
PE
NE
Brasil
SP
Macaé
BA
Campinas Recife Olinda Salvador
Instâncias
� Uma mesma dimensão pode apresentar mais de uma categoria
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?
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
“O Share Nielsen de AS JJ98
é 14 para GUIMBA e
25 para MUAMBA.”
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
LOJA SABOR UNID. Vendidas
TIJUCA MUZZ 4
TIJUCA CALAB 5
TIJUCA MARG 8
IPANEMA MUZZ 3
IPANEMA CALAB 6
IPANEMA MARG 5
GRAJAÚ MUZZ 6
GRAJAÚ CALAB 8
GRAJAÚ MARG 4
4 5 8
3 6 5
6 8 4
LOJA
TIJUCA
IPANEMA
GRAJAÚ
MUZZ CALAB MARGSABOR
Totais de Unidades Vendidas
Esquema Estrela
Uma tabela de fatos cercada de tabelas de dimensões
Esquema Estrela
Fatos de
VENDASCod_tempo
Cod_produto
Cod_loja
Vendas_reais
Vendas_unidades
Custos_reais
Dimensão TEMPO
Cod_tempo
DataCompleta
Mes
Quadrimestre
Ano
Flag_feriado
Dimensão PRODUTO
Cod_produto
descrição
categoria
marca
Dimensão LOJA
Cod_loja
Nome_loja
endereço
cidade
estado
Um exemplo:
Consulta SQL sobre um esquema estrela
select
Loja.Estado, Tempo.DataCompleta,
Produto.Descricao,
Sum( Vendas.Vendas_unidades) as Total
from
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
Qtd Vendida de cada Produto por Estado e por Data
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
� Histórica� Variáveis/Fatos
� Usualmente numéricos� tipicamente aditivos
� Armazenamento de agregados� Agiliza consultas� Critérios de escolha do que for mais útil� Onde armazenar: tabela de fatos auxiliar?
Fatos de
VENDASCod_tempo
Cod_produto
Cod_loja
Vendas_reais
Vendas_unidades
Custos_reais
Tabelas de Dimensão
� Volume comparativamentemenor
� Chave simples� Descrevem os fatos� Atributos usados comofiltro nas consultas
� Hierarquias implícitas� Desnormalizada => redundâncias
CodLoj123…
NomeSaraivaSodilerTravessa
End………
CidadeRioRio Rio
EstadoRJRJRJ
Dimensão LOJA
Cod_loja
Nome_loja
endereço
cidade
estado
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
FatoTabelas de dimensões normalizadas
Dimensão Dimensão Dimensão Dimensão
VendedorVendedorVendedorVendedor
Dimensão Cliente Dimensão Produto
Produto
Código Produto
Nome Produto
Código Grupo
Fato Vendas
Data
Código Vendedor
Código Produto
Código Cliente
Valor da Venda
Quantidade
Margem
Margem %
Vendedor
Código Vendedor
Nome Vendedor
Código Região
Cliente
Código Cliente
Nome Cliente
Código Atividade
Código Segmento
Grupo
Código Grupo
Nome Grupo
Atividade
Código Atividade
Descrição
Segmento
Código Segmento
Descrição
Região
Código Região
Nome Região
Esquema Constelação de Fatos
� Múltiplas tabelas de fatos com dimensões compartilhadas� Maior complexidade
Esquema Constelação de Fatos
Sales Fact
time_key
product_key
location_key
dollar_sold
unit_sold
dollar_cost
Time Dimension
time_key
day_of_week
month
quarter
year
holiday_flag
Product Dimension
product_key
description
brand
category
Location Dimension
loc_key
loc_name
address
city
state
Shipping Fact
time_key
product_key
from_location_key
to_location_key
shipper_key
dollar_cost
units_shipped
Shipper Dimension
shipper_key
shipper_name
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ões4 os fatos e suas unidades de medida5 os atributos das dimensões6 amplitude de tempo do DW7 Como rastrear mudanças nas dimensões8 aspectos de armazenamento físico9 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 fatorepresenta
• Ex: uma venda de propriedade
• Identificar as dimensõesenvolvidas no fato
• Dimensão tempo é incluída
• “Conformed dimension tables” : dimensões usadasem 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 queracompanhar?
� Devem estar no nível do grão do fato
� Ex: todos os fatos devemse 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ãomais ú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
date
key full date
day of
week
day
num in
month
day
num
overall
day
name
day
abbre
v
weekday
flag
week
num in
year
week
num
overall
week
begin
date
week
begin
date
key month
month
num
overall
month
name
month
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 vaiacumular 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
Staff_Key Staff_Code Staff_Name Staff_State Version
123 ABC Alfredo Neves CA 0
124 ABC Alfredo Neves IL 1
� Manter o histórico de mudanças aolongo do tempo
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
JANUARY FEBRUARY MARCH
M
O
D
E
L
Mini Van
Coupe
Sedan
NY LA Madison
Clyde
Gleason
Carr
CITY
Mini Van
Coupe
Sedan
NY LA Madison
Clyde
Gleason
Carr
CITY
Mini Van
Coupe
Sedan
NY LA Madison
Clyde
Gleason
Carr
CITY
DEALERSHIP
Janeiro Fevereiro Março
M
O
D
E
L
Mini Van
Coupe
Sedan
NY LA Madison
ClydeGleason
Carr
Cidade
Mini Van
Coupe
Sedan
NY LA Madison
ClydeGleason
Carr
cidade
Mini Van
Coupe
Sedan
NY LA Madison
ClydeGleason
Carr
cidade
Fornecedor
MODELO