Aula - Aspectos Avançados em Modelagem Multidimensional

5,308 views

Published on

Published in: Technology
1 Comment
7 Likes
Statistics
Notes
  • Mauricio, tudo bem?!

    Essa aula realmente caiu como uma luva para o meu trabalho. Gostaria de entender como modelar fluxo de demanda com situação, por exemplo, em um determinado momento a demanda entra com data e situação A, depois passa para a situação B com registro de outra data e assim por diante, tipo um ciclo, até o fechamento. Eu criei uma tabela de dimensão chamada Demanda com detalhes e as respectivas datas de abertura, data de expectativa de entrega e data negociada e uma relação multos para um com uma tabela de dimensão de Ciclo da Situação que estará acumulando cada passo do ciclo da demanda. Esta ligada só à dimensão Demandas e não à tabela de fato GerirDemandas. Esse seria um bom caminho? agradeço!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
5,308
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide

Aula - Aspectos Avançados em Modelagem Multidimensional

  1. 1. Aspectos Avançados em Modelagem Multidimensional Novembro / 2009 1
  2. 2. AgendaI. Esquema Estrela e VariaçõesII. Esquema Snowflake e VariaçõesIII.Dimensão TempoIV. Role Playing DimensionsV. Slowly Changing DimensionsVI. Dimensões DegeneradasVII.Campos Chaves de Tabelas de DimensõesVIII.Fatos Aditivos * Semi-Aditivos * Não-AditivosIX. Tabelas de Fatos Sem FatosX. Dez Erros Comuns a Evitar em Modelagem Dimensional 2
  3. 3. Esquema Estrela e Variações Modelo Estrela 3
  4. 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. 5. Modelo Estrela Parcial Exemplo de Duas Estrelas no Modelo Estrela Parcial 5
  6. 6. Modelo Estrela Parcial Modelo Estrela Parcial para Composições de 6 Agregações
  7. 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. 8. Modelo Estrela com Particionamento de Fatos(ou Modelo Constelação de Fatos) 8 Modelo Particionamento de Fatos
  9. 9. Modelo Estrela com Particionamento deDimensõesModelo Particionamento de Dimensões, para local e tempo. Note a granularidade da 9tabela de fatos.
  10. 10. Snowflake e Suas Variações 10Modelo Snowflake, Após Normalização Do Modelo Estrela
  11. 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. 12. Modelo Snowflake Chain 12
  13. 13. Modelo Snowflake ChainA recomendação de uso deste modelo ocorre quando o nível de detalhe maisbaixo está armazenado na tabela de fatos.A contra-indicação, por sua vez, é para os casos em que a pesquisa requervários níveis de sumarização da informação, já que são necessários váriospassos 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. 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. 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. 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. 17. Importância da Dimensão TempoA 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• FeriadosQual a granularidade ideal? É claro, depende do projetoExemplo: Granuralidade DiáriaCom granularidade diária, podemos organizar os dados por dias,meses, anos, por periodos fiscais (artificiais) da empresa, etc. Essamodelagem, é mais flexível a mudanças nos requisitos do negócio. 17
  18. 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. 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. 20. Detalhe da Dimensão Tempo week day day day week week week begin monthdate day of num in num day abbre weekday num in num begin date num month monthkey 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31. Role Playing DimensionsPROBLEMA: 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. 32. Soluções SQL para Dimensões com PapéisCada um dos papéis da dimensão é representado por uma tabela lógicaseparada 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. 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. 34. Mais De Uma Dimensão Com Vários Papéis Tráfego Tarifado de ComutaçãoDimensão Tempo Data da Chamada Data da Tarifação Data do Faturamento Data do Pagamento Provedor do Sistema de OrigemDimensã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. 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. 36. Dimensões que Evoluem no TempoAlgumas dimensões não constantes ao longo do tempo, são asdimensõ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. 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ãoConsideremos 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. 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. 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 referenteao 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 Vendasanteriores a 15/01/94, e o segundo estará vinculado as vendas posterioresa essa data 39
  40. 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. 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. 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. 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. 44. Dimensões que Evoluem no TempoO atributo estado civil, seria renomeado para estado civil original e seriam incluídosos atributos estado civil atual e data efetiva do estado civil.Sempre que aconteceruma mudança no estado civil de Mary, substituiremos o valor do campo estado civilatual e mudaremos a data efetiva. O campo estado civil original nunca é modificado 44
  45. 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. 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. 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. 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. 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. 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. 51. Dimensões Degeneradas POS Transaction Number é uma Dimensão Degenerada (DD) 51
  52. 52. Campos Chaves de Tabela de DimensõesRegra 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 tabelasfatos.– Chaves naturais podem ter problemas de unicidade, ausência,tamanhosexagerados.– Chaves artificiais podem ser especificadas como inteiros de 4bytes, alcançandoaté 232, isto é, mais de 2 bilhões de ocorrências (inteiros positivos),o que é mais doque necessário para qualquer tabela dimensão. 52
  53. 53. Campos Chaves de Tabela de Dimensões– Chaves artificiais ficam transparentes (invisíveis) para os usuários,servindoapenas como ligação entre dimensões e fatos.– Campos naturais não chave poderão ser indexados, tornando asconsultasamistosas.– Se produzidas automaticamente, deve-se ter cuidado no processode preparação(ETL), especialmente nos reprocessamentos.– A única desvantagem das chaves artificiais é que não faz sentido atabela fato serconsultada diretamente, pois os campos descritivos de filtro estarãoarmazenadosnas dimensões. 53
  54. 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. 55. Fatos Aditivos x Semi-Aditivos x Não-Aditivos Dimensão Loja Fato Venda Dimensão Tempo chave_tempo chave_produtoDimensão Promoção chave_loja Dimensão Produto chave_promocaoChave_promocao chave_produto qtde_vendidanome_promocao descricao_sku rendimento_dolartipo_reducao_preco numero_sku custo_dolartipo_cupom categoria numero_freguesescusto_promocao departamentodata_inicio_prom peso... ... 55
  56. 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. 57. Tabelas de Fatos Sem Fatos (Factless FactTables) 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. 58. Tabelas de Rastreamento de Eventos (Ex I)Freqüência Diária em FaculdadeModelar a freqüência diária a um curso de uma faculdade em umatabela de fatos com as dimensões:• Data• Aluno• Curso• Professor• Instalação 58
  59. 59. 59
  60. 60. Tabelas de Rastreamento de Eventos (Ex I)Este esquema estrela permite visualizar questões taiscomo:• 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 outrosdepartamentos• Taxa média de ocupação das instalações durante ohorário de atendimento 60
  61. 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. 62. Tabelas de Rastreamento de Eventos (Ex II)Procedimentos Hospital/Paciente 62
  63. 63. Tabelas de Rastreamento de Eventos (Ex III) Partes Envolvidas Em Acidentes 63
  64. 64. Tabela de Cobertura (Ex IV) Promoções 64
  65. 65. Dez Erros Comuns a Evitar emModelagem 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. 66. Dez Erros Comuns a Evitar emModelagem 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

×