O documento discute vários aspectos avançados de modelagem dimensional, incluindo: (1) esquemas estrela e snowflake e suas variações, (2) dimensão tempo e como modelá-la, (3) dimensões que podem ter múltiplos papéis e (4) dimensões que evoluem no tempo (slowly changing dimensions).

1. Aspectos Avançados em Modelagem
Multidimensional
Novembro / 2009
1

2. Agenda
I. Esquema Estrela e Variações
II. Esquema Snowflake e Variações
III.Dimensão Tempo
IV. Role Playing Dimensions
V. Slowly Changing Dimensions
VI. Dimensões Degeneradas
VII.Campos Chaves de Tabelas de Dimensões
VIII.Fatos Aditivos * Semi-Aditivos * Não-Aditivos
IX. Tabelas de Fatos Sem Fatos
X. Dez Erros Comuns a Evitar em Modelagem Dimensional
2

3. Esquema Estrela e Variações
Modelo Estrela 3

4. Esquema Estrela e Variações
A Figura ilustra uma tabela para a dimensão “Geografia”, com os pontos acima
representados. Note que a coluna “nível” determina a hierarquia (Região/Estado/Cidade)
4

5. Modelo Estrela Parcial
Exemplo de Duas Estrelas no Modelo Estrela Parcial
5

6. Modelo Estrela Parcial
Modelo Estrela Parcial para Composições de 6
Agregações

7. Modelo Estrela Parcial
Os pontos positivos deste modelo são a maior economia de espaço,
eliminando redundâncias e colunas que não têm sentido para
determinado nível de agregação e o melhor desempenho para consultas
de nível específico de agregação.
Por outro lado, a complexidade do modelo é maior e as consultas que
combinam níveis de agregação distintos são mais elaboradas, podendo
resultar em queda de desempenho.
7

8. Modelo Estrela com Particionamento de Fatos
(ou Modelo Constelação de Fatos)
8
Modelo Particionamento de Fatos

9. Modelo Estrela com Particionamento de
Dimensões
Modelo Particionamento de Dimensões, para local e tempo. Note a granularidade da 9
tabela de fatos.

10. Snowflake e Suas Variações
10
Modelo Snowflake, Após Normalização Do Modelo Estrela

11. Modelo Snowflake Lookup
Note que a tabela de
dimensão
“PrincipalClientes”
possui apenas os dados
de cada cliente e
chaves estrangeiras
para outros elementos,
sendo que a
manutenção destes é
feita de modo mais
consistente ao
promover alterações
apenas nas tabelas de
busca (lookup).
11
Parte Do Modelo Snowflake Lookup, Mostrando A Normalização Da Tabela Clientes

12. Modelo Snowflake Chain
12

13. Modelo Snowflake Chain
A recomendação de uso deste modelo ocorre quando o nível de detalhe mais
baixo está armazenado na tabela de fatos.
A contra-indicação, por sua vez, é para os casos em que a pesquisa requer
vários níveis de sumarização da informação, já que são necessários vários
passos para recuperar as informações.
A fim de melhorar o desempenho, uma sugestão é desnormalizar a cadeia,
inserindo as chaves de níveis mais altos nos níveis mais baixos.
13

14. Modelo Snowflake Attribute
Com o objetivo de reduzir o número de informações referentes a atributos nas
tabelas de fatos, geralmente utilizados para obtenção de detalhes
(drillthrough), inserimos todos eles em uma tabela de atributos:
Modelo Snowflake, Antes De Separar Os Atributos
14

15. Modelo Snowflake Attribute
Outra utilidade
deste modelo é a
consolidação de
informações
sobre diversas
pequenas
dimensões que
possuam poucos
campos (muitas
vezes apenas a
descrição) em uma
única tabela.
Desse modo, o
número de tabelas
em junções pode
ser reduzido,
melhorando o
desempenho.
Modelo Snowflake Attribute 15

16. Dimensão Tempo
A dimensão tempo é muito poderosa e importante em todo data
mart e data warehouse corporativo. Como tal deve ser tratada de
forma diferenciada em relação às outras dimensões.
(Ralph Kimball)
16

17. Importância da Dimensão Tempo
A Dimensão Tempo costuma ser complexa no mundo real:
• Dia, Mês, Trimestre, Semestre, Ano
• Acumulado no Mês
• Período Fiscal, Semana de Cinco Dias
• Feriados
Qual a granularidade ideal? É claro, depende do projeto
Exemplo: Granuralidade Diária
Com granularidade diária, podemos organizar os dados por dias,
meses, anos, por periodos fiscais (artificiais) da empresa, etc. Essa
modelagem, é mais flexível a mudanças nos requisitos do negócio.
17

18. Dimensão Tempo
• Diferente das outras dimensões, a tabela pode ser
carregada antecipadamente, de uma só vez e não
requer fonte de dados.
• É razoável que carreguemos 5 ou 10 anos de dias
válidos Ex: De 1995 a 2005.
Temos que cobrir dias passados devido a
análises históricas e os dias futuros
18

19. Exemplo de Dimensão Tempo
time_key
full_date
day_of_week
day_number_in_month
day_number_overall
week_number_in_year
week_number_overall
month
month_number_overall
quarter
fiscal_period
weekday_flag
last_day_in_month_flag
19

20. Detalhe da Dimensão 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
20

21. Detalhe da Dimensão Tempo
• O campo day_of_week contém o nome do dia. Ex: terça.
• Pode ser usado em relatórios comparando negócios de terça
com sábado
• O campo day_number_in_month começa com 1 e vai até 28, 29,
30 ou 31 dependendo do mês
• O campo last_day_in_month_flag é usado para selecionar o último
dia do mês
• O campo day_number_overall é o dia no calendário juliano
• Permite aritmética simples entre dias no ano ou no mês
• Os campos quarter e fiscal_period são campos textos que contém
uma designação para qual quinzena ou período fiscal que o dia cai
21

22. Dimensão Tempo
Porque não acrescentar um atributo data na tabela de fatos ao invés
de criar uma dimensão tempo, aproveitando os recursos oferecidos
pelo SQL?
As tabelas de dimensões servem como fonte para filtros e
cabeçalhos de relatórios.
Apesar do SQL oferecer assistência razoável para navegar através
de datas, as suas funcionalidades não são suficientes para atender as
necessidades típicas de uma organização, tal como: calendário
corporativo, período fiscal ou de estações.
Se você não possui bons atributos descritivos você não pode
construir os relatórios que precisa
22

23. Como Guardar Horas e Minutos ?
1ª Alternativa: Colocar a “hora do dia” na Tabela de
Fatos
Time Fact
time_key time_key
...
time_of_day
23

24. Como Guardar Horas e Minutos ?
2ª Alternativa: Criar uma Dimensão Hora (24 h
X 60 min = 1440 valores)
Time Fact
time_key time_key
minute_key
Minute
minute_key
hour Agrupamentos úteis de minutos:
minute (nomes de horas, nomes de turnos )
24

25. Como Guardar Horas e Minutos ?
3ª Alternativa : Na mesma tabela de dimensão
que as datas
Time
time_key Fact
day time_key
...
month time_of_day
hour
minute
Tabela muito grande
25

26. Questões Avançadas Envolvendo o Tempo
• “Time alignment of similar events”
Aplicação onde você quer analisar grupos de
registros que são classificados juntos por um
determinado evento.
Como cruzar informações relativas a um
determinado evento?
26

27. Questões Avançadas Envolvendo o Tempo
Ex: Data mart de compras de clientes. Os clientes
com limite de crédito > 1000 reais pertencem ao
mesmo grupo de análise
– O que acontece com um cliente quando seu
limite de crédito é aumentado para 1.000 reais?
– Qual a média de tempo que clientes alcançam um
crédito default ?
27

28. Questões Avançadas Envolvendo o Tempo
• “Progressive Subsetting”
– Como cruzar informações sobre conjuntos de
dados no tempo?
– Caso típico em diagnóstico
• Ex:
– Quais pacientes sentiram dor, e que depois
foram tratados durante um mês com a droga A
ou B, e que não sofreram operação subsequente,
e que tiveram dores 3 meses depois, e que ainda
estão vivos?
28

29. Role Playing Dimensions
“Role Playing” ou dimensões com papéis em Data
Warehouse é uma situação na qual uma única
dimensão aparece várias vezes na mesma tabela de
fatos
29

30. Dimensão Tempo Com Vários Papéis
Inventário de Entrega
Chave do Produto
Dimensão Chave do Armazém Dimensão
Chave de Venda
Armazém Produto
Data do Pedido
Data da Entrega
Dimensão Data do Pagamento Dimensão
Tempo Data da Devolução Venda
Status do Pedido
...
30

31. Role Playing Dimensions
PROBLEMA:
Os itens Data de Pedido, Data da Entrega, Data do Pagamento e
Data da Devolução referem-se a uma única tabela de dimensão, a
Dimensão Tempo.
Não podemos associar estes campos a uma única tabela, pois o SQL
poderia interpretar tal associação simultânea como exigência para
que todas as datas fossem iguais, o que não parece muito provável.
Precisamos “enganar” o SQL para que ele acredite que existem
quatro tabelas independentes na Dimensão Tempo. Assim, temos que
rotular todas as colunas de cada uma das tabelas de forma exclusiva.
Se não fizermos isso, não conseguirmos separar as colunas quando
várias delas forem arrastadas para um relatório.
31

32. Soluções SQL para Dimensões com Papéis
Cada um dos papéis da dimensão é representado por uma tabela lógica
separada com nomes de coluna únicos através de visões.
CREATE VIEW order_date (order_date_key, order_day_of_week,
order_month...)
AS SELECT date_key, day_of_week, month, . . . FROM Date
CREATE VIEW req_ship_date (req_ship_date_key, req_ship_day_of_week,
req_ship_month ...)
AS SELECT date_key, day_of_week, month, . . . FROM Date
32

33. Dimensão Aeroporto Com Vários Papéis
Dimensão Cliente
Data do Vôo
Dimensão Aeroporto
Origem do Segmento
Destino do Segmento
Dimensão Vôo
Origem da Viagem Dimensão Tarifa
Destino da Viagem
Vôo
Dimensão Data Tarifa
Classe
33
Cliente …

34. Mais De Uma Dimensão Com Vários Papéis
Tráfego Tarifado de Comutação
Dimensão Tempo Data da Chamada
Data da Tarifação
Data do Faturamento
Data do Pagamento
Provedor do Sistema de Origem
Dimensão Provedor Provedor da Comutação Local
Provedor dos Interurbanos
Provedor do Serviço de Valor Agregado
Parte que Ligou
Parte que Recebeu a Ligação
Comutação Anterior
Dimensão Localização Comutação Subsequente
34

35. Dimensões que Evoluem no Tempo
• Chamadas de Slowly Changing Dimensions
• Dimensões que se mantém constantes durante a
maior parte do tempo, necessitando de algumas
pequenas adições para capturar as mudanças ao
longo do tempo
35

36. Dimensões que Evoluem no Tempo
Algumas dimensões não constantes ao longo do tempo, são as
dimensões de modificação lenta. Ex: produto, cliente...
Tornar as dimensões dependentes do tempo ou incluir
tudo na tabela de fatos....
Entidades altamente relacionadas, perda de consistência
e desempenho
A capacidade do data warehouse de mostrar corretamente os fatos
históricos pode ser afetada pelas dimensões de modificação lenta e
depende de como as mudanças nas dimensões são rastreadas.
36

37. Dimensões que Evoluem no Tempo
Existem basicamente três alternativas para lidarmos com essa
situação:
Tipo um :
Atualizar os valores antigos os registros da dimensão
Tipo dois:
Adicionar um novo registro à dimensão contendo os novos valores do atributo
Tipo três:
Criar novos campos “atuais” no registro original da dimensão
Consideremos como exemplo:
Mary Jones - tinha estado civil solteira até 15/01/1994.
Casou-se em 15/01/1994. Como refletir esta “evolução” no DW ?
37

38. Dimensões que Evoluem no Tempo
O atributo da dimensão é atualizado com o novo valor
Não é necessário mais nenhuma alteração no registro da dimensão
Nenhuma chave é afetada no banco de dados
Muito fácil de implementar mas os dados históricos ficam inconsistentes
Duas questões básicas devem ser feitas antes de decidir por esta solução:
Qual a importância desse valor para as análises do usuário final?
Qual a importância de se rastrear o histórico ?
Mary Jones teria seu atributo estado civil atualizado para casada.
38

39. Dimensões que Evoluem no Tempo
Inserção de um novo registro na mesma entidade dimensional, refletindo
a “mudança de estado”;
Uma “nova instância” da chave dimensional é a criada e referencia o novo
registro;
É necessário a criação de uma chave generalizada. Uma forrma simples
de fazê-lo é criar dígitos de versões no final da chave;
Todas essas chaves precisam ser criadas, mantidas e gerenciadas pela
equipe de DW. É necessário o uso de metadados para rastrear as chaves
já utilizadas
O banco de dados mantém sua consistência e as versões podem ser
chamadas “partition history”
Existirão dois registros de Mary Jones na dimensão cliente. O primeiro referente
ao seu estado civil até 15/01/1994 - solteira e o outro ao estado civil casada.
Na tabela de fatos vendas, o primeiro registro de Mary está vinculado as Vendas
anteriores a 15/01/94, e o segundo estará vinculado as vendas posteriores
a essa data
39

40. Dimensões que Evoluem no Tempo
• A dimensão de modificação lenta divide o histórico automaticamente,
através da associação de cada “versão” com seus registros de fatos
correspondentes
• É permitido também colocar uma data efetiva de início e fim em cada
registro, por exemplo, de uma dimensão produto, permitindo assim
rastrear a data de validade de determinada composição.
– Mas deve-se ter cuidado, pois estas datas neste caso não tem o
mesmo significado da chave de data na tabela de fatos: a chave na
tabela de fatos se refere, por exemplo, a data de venda do
produto, que não ecessariamente deve estar contida no intervalo de
tempo definido na tabela de dimensão.
• Mas o que fazer com esta data efetiva no caso de dimensões onde
diversos atributos podem ser modificados?
40

41. Dimensões que Evoluem no Tempo
• Caso de um data mart de recursos humanos, onde para cada empregado
tem-se um rico conjunto de atributos (digamos 100!): data de
contratação, função, nível, salário, plano de seguro, etc.
• Na verdade, há uma série de transações atuando sobre estes dados,
pois os empregados são promovidos, transferidos, etc.
• Pode-se querer fazer análises como:
– Status resumido da base de empregados a cada fechamento de mes
• Usa-se a tabela de fatos
– Status novamente, mas numa data em particular
• Uso a tabela de dimensão
– Histórico de transações de uma determinado empregado
• Uso a tabela de dimensão
41

42. Dimensões que Evoluem no Tempo
Emp Transaction Dimension
emp_trans_key (PK)
emp_Id
transaction_descriptiontt
ransaction_date_time
transaction_end_date_ti Human Resources Facts
me
last_transaction_flag emp_trans_key
name month_key
address Month Dimension organization_key
jog_grade salary_payed
education month_key (PK) overtime_payed
.... month_attributes ... vacation_taken
number_promotions
number_transfers
Organization Dimension ....
organization_key (PK)
organization_attributes
...
42

43. Dimensões que Evoluem no Tempo
Utiliza uma estrutura um pouco diferente. São necessários campos para
armazenar:
status original do atributo dimensional
status atual do atributo dimensional
data efetiva da ultima alteração do campo (status atual)
Apenas dois status podem ser rastreados: o atual e o original;
É possível fazer análises comparando com os resultados utilizando os
status original e atual
É usado para avaliações simultaneas ou tentativas
43

44. Dimensões que Evoluem no Tempo
O atributo estado civil, seria renomeado para estado civil original e seriam incluídos
os atributos estado civil atual e data efetiva do estado civil.Sempre que acontecer
uma mudança no estado civil de Mary, substituiremos o valor do campo estado civil
atual e mudaremos a data efetiva. O campo estado civil original nunca é modificado
44

45. Slowly Changing e o Tempo
Dimensões que mudam com o tempo tem um
relacionamento com a Dimensão Tempo?
Product Fact Time
product_key
product_key time_key
time_key
time_key
45

46. Slowly Changing e o Tempo
Dimensões que mudam com o tempo tem um
relacionamento com a Dimensão Tempo?
Product Fact Time
product_key
product_key time_key
time_key
time_key
46

47. Dimensões Degeneradas
• Também chamadas de descaracterizadas
• Existe um valor correspondente a algum objeto do
mundo real na tabela de fatos mas todos os seus
atributos já aparecem na própria tabela de fatos ou
em alguma outra dimensão
• Dimensões degeneradas geralmente se encontram nas
modelagens em que a granularidade da tabelas de
fatos é o item.
47

48. Dimensões Degeneradas
Número_faturaData_compraProdutoValor Desconto Loja
0312 12/09/1999 A 15,00 0,0% XYZ
0313 12/09/1999 B 25,00 10,0% XYZ
Necessário ou Não?
48

49. Dimensões Degeneradas
Número_fatura Data_compra Produto Valor Desconto Loja
0312 12/09/1999 A 15,00 0,0% XYZ
0313 12/09/1999 B 25,00 10,0% XYZ
Chave Produto
Tabela de Fatos
Chave Loja
1. Chaves das Dimensões
Outras chaves
2. Número_fatura
3. Fatos numéricos normais Dimensão
Degenerada
Não tem atributos
49

50. Dimensões Degeneradas
• Dimensões degeneradas normalmente ocorrem na criação de
tabelas de fatos de item orientado a linha.
• São dimensões normais, esperadas e úteis.
• A “chave degenerada” pode ser usada para se agrupar itens
de linha em uma única ordem.
• Exemplo de pedido: O número médio de itens de linha que
estão em uma ordem.
•Pedido
• Fatura
Usadas para:
• Conta
• Tiquete
50

51. Dimensões Degeneradas
POS Transaction Number é uma Dimensão Degenerada (DD)
51

52. Campos Chaves de Tabela de Dimensões
Regra básica: uso de surrogates ou chaves artificiais.
– Ajudam a manter a estabilidade, através da neutralidade.
– Evitam manutenção custosa de tabelas, especialmente das tabelas
fatos.
– Chaves naturais podem ter problemas de unicidade, ausência,
tamanhos
exagerados.
– Chaves artificiais podem ser especificadas como inteiros de 4
bytes, alcançando
até 232, isto é, mais de 2 bilhões de ocorrências (inteiros positivos),
o que é mais do
que necessário para qualquer tabela dimensão.
52

53. Campos Chaves de Tabela de Dimensões
– Chaves artificiais ficam transparentes (invisíveis) para os usuários,
servindo
apenas como ligação entre dimensões e fatos.
– Campos naturais não chave poderão ser indexados, tornando as
consultas
amistosas.
– Se produzidas automaticamente, deve-se ter cuidado no processo
de preparação
(ETL), especialmente nos reprocessamentos.
– A única desvantagem das chaves artificiais é que não faz sentido a
tabela fato ser
consultada diretamente, pois os campos descritivos de filtro estarão
armazenados
nas dimensões.
53

54. Fatos Aditivos x Semi-Aditivos x Não-
Aditivos
• Fatos Aditivos - podem sempre ser adicionados ao longo das
dimensões.
Ex: número de produtos vendidos.
• Fatos Semi-aditivos - podem ser adicionados ao longo de algumas
dimensões.
Ex: Níveis de estoque e medições de intensidade
(temperatura).
• Fatos Não-aditivos - não podem ser adicionados
Análise um a um dos registros do fato.
Ex: taxas.
54

55. Fatos Aditivos x Semi-Aditivos x Não-
Aditivos
Dimensão Loja Fato Venda Dimensão Tempo
chave_tempo
chave_produto
Dimensão Promoção chave_loja Dimensão Produto
chave_promocao
Chave_promocao chave_produto
qtde_vendida
nome_promocao descricao_sku
rendimento_dolar
tipo_reducao_preco numero_sku
custo_dolar
tipo_cupom categoria
numero_fregueses
custo_promocao departamento
data_inicio_prom peso
... ...
55

56. Fatos Aditivos x Semi-Aditivos x Não-
Aditivos
• Os três primeiros fatos são aditivos ao longo de todas
as dimensões. Podemos agrupar dados da tabela de
fatos sem problemas e toda soma desses três fatos é
válida e correta.
• O 4º fato, numero_fregueses, não é aditivo ao longo
da dimensão produto, caracterizando-o como semi-
aditivo. Se fizermos a pergunta, “Quantos foram os
fregueses que compraram o produto A ou B?”
poderemos ter uma resposta incorreta, pois um mesmo
cliente pode comprar mais de um produto ao mesmo
tempo. 56

57. Tabelas de Fatos Sem Fatos (Factless Fact
Tables)
Ocorre quando há ausência de fatos significativos na
tabela de fatos.
Existem duas variações principais:
• Tabelas de Rastreamento de Eventos
• Tabelas de Cobertura
57

58. Tabelas de Rastreamento de Eventos (Ex I)
Freqüência Diária em Faculdade
Modelar a freqüência diária a um curso de uma faculdade em uma
tabela de fatos com as dimensões:
• Data
• Aluno
• Curso
• Professor
• Instalação
58

59. 59

60. Tabelas de Rastreamento de Eventos (Ex I)
Este esquema estrela permite visualizar questões tais
como:
• Freqüência consolidada dos cursos
• Desistência de cursos ao longo do tempo
• Freqüência de alunos por cursos
• Utilização de instalações por professores de outros
departamentos
• Taxa média de ocupação das instalações durante o
horário de atendimento
60

61. Tabelas de Rastreamento de Eventos (Ex I)
Visualizar freqüência consolidada dos cursos:
SELECT CURSO, COUNT(CH_CURSO)
... GROUP BY CURSO
ou
SELECT CURSO, COUNT(CH_PROFESSOR)
... GROUP BY CURSO
ou CH_INSTALAÇÃO, ou CH_PROFESSOR,
ou CH_TEMPO
61

62. Tabelas de Rastreamento de Eventos (Ex II)
Procedimentos Hospital/Paciente
62

63. Tabelas de Rastreamento de Eventos (Ex III)
Partes Envolvidas Em Acidentes
63

64. Tabela de Cobertura (Ex IV)
Promoções
64

65. Dez Erros Comuns a Evitar em
Modelagem Dimensional
•Erro 10: Colocar atributos de texto usados para restrições
e agrupamento numa tabela de fatos.
•Erro 9: Limitar atributos descritivos verbosos em
dimensões para economizar espaço.
•Erro 8: Separar hierarquias e níveis de hierarquia em
dimensões múltiplas.
•Erro 7: Ignorar a necessidade de cuidar de mudanças em
atributos de dimensões.
•Erro 6: Resolver todos os problemas de desempenho de
consultas adicionando mais hardware.
65

66. Dez Erros Comuns a Evitar em
Modelagem Dimensional
•Erro 5: Usar chaves operacionais ou “inteligentes” para
junções de tabelas de dimensão com tabela de fatos.
•Erro 4: Negligenciar a declaração e depois a consistência
com o grão da tabela de fatos.
•Erro 3: Projetar o modelo dimensional baseado em um
relatório específico.
•Erro 2: Esperar que usuários consultem dados de nível
atômico mais baixo num formato normalizado.
•Erro 1: Falhar em conformar fatos e dimensões através de
diferentes data marts.
66