Aula - Aspectos Avançados em Modelagem Multidimensional
13 gostaram9,034 visualizações
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).
Aula - Aspectos Avançados em Modelagem Multidimensional
- 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