Modelação Dimensional 2

Transcrição

1 INTEGRAÇÃO E PROCESSAMENTO ANALÍTICO DE INFORMAÇÃO Modelação Dimensional 2 António Manuel Silva Ferreira UNIVERSIDADE DE LISBOA FACULDADE DE CIÊNCIAS DEPARTAMENTO DE INFORMÁTICA asfe@di.fc.ul.pt

2 Sumário Modelação dimensional Exemplo das vendas a retalho Chaves primárias e dimensões degeneradas Dimensão data e hierarquias fixas Chaves subsvtutas Snowflaking Análise de dimensões Inteligibilidade versus desempenho Mais sobre modelação de factos Medidas, adivvidade, e semiadivvidade Tabelas de factos sem factos 2

3 Revisão de Conceitos Medida Valor numérico usado para avaliar um negócio Dimensão EnVdade independente que parvcipa na análise de medidas Facto Evento expresso através de dimensões e medidas Esquema em estrela Tabelas de dimensões em redor da tabela de factos Tabela de factos Guarda dados referentes a um processo de negócio Colunas são chaves estrangeiras para dimensões e medidas Tabelas de dimensões Guardam atributos de cada dimensão, com o nível de detalhe apropriado Dim. Dimensão Factos Dim. Dim. 3

4 Exemplo das Vendas a Retalho Empresa retalhista com registo de vendas em cada loja 100 lojas em 5 países produtos únicos Alguns têm UPCs (universal product code) Outros não têm UPC (padaria, peixaria, charcutaria, talho,...) ObjeVvo Entender o impacto dos preços e das promoções nas vendas 4

5 Exemplos de Perguntas AnalíEcas Qual o li7 movvado por uma promoção? Ganho em vendas num produto porque está a ser promovido Houve deslocações no tempo? Clientes armazenam e deixam de comprar o produto por muito tempo Efeito de canibalismo? Clientes compram o produto promovido em vez de outros Vendas cruzadas? Mais vendas de morangos implicam mais vendas de chanvli Mercado cresceu? Produtos do mesmo Vpo venderam mais durante e depois da promoção Qual o lucro de uma promoção? Considerando os custos e todos os aspetos anteriores 5

6 Modelação Dimensional para Vendas a Retalho 1. IdenVficação dos processos a modelar Vital para sucesso do data warehouse Focar nas vendas a retalho, incluindo promoções 2. Determinação do grão da tabela de factos Cada evento corresponde a um item individual vendido numa transação 3. Modelação das dimensões em tabelas Data, produto, promoção, loja, cliente, e respevvos atributos Transação (dimensão especial, sem tabela própria) 4. IdenVficação das medidas numéricas na tabela de factos QuanVdade, euros de venda, euros de compra Euros de lucro = euros de venda euros de compra 6

7 Chave Primária da Tabela de Factos Cada valor da chave primária idenefica univocamente um facto Tipicamente composta por chaves estrangeiras para as dimensões Grão mais fino mais dimensões mais atributos na chave primária Exemplo HyperVending (das aulas teórico- právcas) 4 dimensões: chave primária composta por 4 chaves estrangeiras Vendas(sData, ssucursal, scliente, sproduto, Unidades, Euros) Chave primária pode excluir algumas dimensões Mas todas as dimensões convnuam a ter as suas chaves estrangeiras Exemplo: item em talão de caixa de supermercado Chave primária: idenvficador da transação e código do produto Detalhes podem ser obvdos pelas chaves estrangeiras para dimensões VendasRetalho(IdTransação, sproduto, sloja, sdata, spromoção, scliente, Unidades, EurosVenda, EurosCompra) 7

8 Dimensões Degeneradas Algumas dimensões servem apenas para agrupar factos Agrupamento tem de ter significado forte no contexto Ex. idenvficador de transação, número de fatura, número de encomenda, Sem outros atributos próprios e sem tabela de dimensão associada Detalhes já existem nas outras tabelas de dimensões Exemplo: idenvficador de transação em talão de supermercado Chave primária é idenvficador da transação e código de produto ID da transação serve para agrupar produtos vendidos na mesma ocasião Tem embebida a loja e a data Dimensões degeneradas podem ser: Descartadas, se não fizerem falta à análise SubsEtuídas por chaves estrangeiras para dimensões VendasRetalho(IdTransação, sproduto, sloja, sdata, spromoção, scliente, ) VendasRetalho(Idtransação, sproduto, sloja, sdata, spromoção, scliente, ) 8

9 Dimensão Data Presente em quase todos os data warehouses Essencial para análises de dados históricos Nível de detalhe Tem de ser adequado ao grão da tabela de factos Detalhe xpico ao dia: em que dia aconteceu o facto? Noutros casos: hora, minuto, segundo, Atributos xpicos Ano, mês, dia, hora, minuto, segundo, Feriado ou não, dia da semana, fim de semana, Estação: volta às aulas, Natal, saldos, férias, Calendário fiscal: trimestre, semestre, ano fiscal, Semana do ano, semana do mês, Date Dimension Date Key (PK) Date Full Date Description Day of Week Day Number in Epoch Week Number in Epoch Month Number in Epoch Day Number in Calendar Month Day Number in Calendar Year Day Number in Fiscal Month Day Number in Fiscal Year Last Day in Week Indicator Last Day in Month Indicator Calendar Week Ending Date Calendar Week Number in Year Calendar Month Name Calendar Month Number in Year Calendar Year-Month (YYYY-MM) Calendar Quarter Calendar Year-Quarter Calendar Half Year Calendar Year Fiscal Week Fiscal Week Number in Year Fiscal Month Fiscal Month Number in Year Fiscal Year-Month Fiscal Quarter Fiscal Year-Quarter Fiscal Half Year Fiscal Year Holiday Indicator Weekday Indicator Selling Season Major Event SQL Date Stamp and more 9

10 Dimensões Hierárquicas 1 Permitem a análise de medidas em vários níveis de detalhe Suportam as operações de drill- down e roll- up em cubos de dados Dimensão data é hierárquica Muitos dos seus atributos têm relações de hierarquia Ano > semestre > mês > dia Pode haver mais de uma hierarquia disponível para o decisor Ex. ano > semana do ano (1 a 52/53), mês > semana do mês (1 a 4/5) Outras dimensões também têm expressão hierárquica Geografia: convnente > país > distrito > cidade Posição na empresa (organogramas) Produtos: Vpo > gama > modelo 10

11 Dimensões Hierárquicas 2 Hierarquias podem ou não ser equilibradas Todos os anos têm meses e todos os meses têm dias, Todos os convnentes têm países e todos os países têm cidades, Nem todos os departamentos têm o mesmo Vpo de funcionários Cada nível hierárquico deve ser um atributo da dimensão Decisores Vpicamente reconhecem níveis hierárquicos nos atributos Níveis de uma hierarquia devem ser colunas consecutivas da tabela de dimensão Na construção do data warehouse São especificados os atributos da hierarquia na tabela de dimensão São estabelecidas as relações hierárquicas entre os atributos Chave primária de dimensão hierárquica Deve idenvficar univocamente valores no nível de detalhe mais fino 11

12 Dimensões Hierárquicas 3 Exemplo: número de fotos Vradas em viagens factviagem(sdata, slocal, QuanVdadeFotos) dimdata(iddata, Ano, Semestre, Mês, Dia, Data) dimlocal(idlocal, ConVnente, País, Cidade, Coordenadas) Dimensões Data: dias em que foram Vradas fotos Possível obter mais detalhes (horas, minutos, ) através do atributo data Local: cidades onde foram Vradas fotos Mais pormenores da localização através das coordenadas Contagens do número de fotos Vradas Por dia, mês, semestre, Por cidade, país, ou convnente Ou outra combinação de níveis hierárquicos destas duas dimensões 12

13 Chaves Substitutas em Tabelas de Dimensões 1 Chave primária de tabela de dimensão deve ser subsetuta IdenVfica univocamente cada linha da dimensão Sem qualquer significado para o decisor Sem ligação com os ideneficadores dos sistemas operacionais Assunções subjacentes podem ser invalidadas com o passar do tempo Ex. atual código operacional A123 pode referir outro produto mais tarde Chave subsvtuta (surrogate key) xpica Número inteiro, posivvo, e sequencial Primeira linha tem idenvficador 1, depois 2, 3, Único propósito PermiEr a junção da tabela de dimensão com a tabela de factos 13

14 Chaves Substitutas em Tabelas de Dimensões 2 Vantagens Chaves mais pequenas e de pesquisa eficiente Protegem o data warehouse das alterações nos sistemas operacionais Exemplo: reciclagem de dez em dez anos de códigos de produto Mesmo ID no sistema operacional, mas ID diferente no data warehouse Simplificam a integração de dados de várias fontes Códigos incoerentes do mesmo produto traduzidos para a mesma chave substituta Permitem registar eventos que não existem no sistema operacional Exemplos: idenvficadores para promoção não aplicável, data desconhecida, Desvantagem Carregamento de dados mais complexo Necessária correspondência entre códigos operacionais e chaves subsvtutas Data staging area requer mais espaço em disco 14

15 Snowflaking 1 Tabelas de dimensões são não normalizadas Informação redundante é mais fácil de entender pelo decisor Ex: dimproduto(id, DescriçãoProduto, TipoEmbalagem, DuraçãoEmbalagem, ) Normalização relacional conduz ao snowflaking Menor redundância menos espaço em disco Escritas mais eficientes Mas Dim. Dimensão Factos Dim. Dim. Normalização 15

16 Snowflaking 2 O que é mais fácil de entender? a) Uma tabela não normalizada com todos os atributos de produto Product Dimension Product Dimension Brand Dimension Category Dimension Department Dimension Product Key (PK) Product Description SKU Number (Natural Key) Brand Description Category Description Department Description Package Type Description Package Size Fat Content Diet Type Weight Weight Units of Measure Storage Type Shelf Life Type Shelf Width Shelf Height Shelf Depth and more Product Key (PK) Product Description SKU Number (Natural Key) Brand Key (FK) Package Type Key (FK) Fat Content Weight Weight Units of Measure Storage Type Key (FK) Shelf Width Shelf Height Shelf Depth and more Brand Key (PK) Brand Description Category Key (FK) Package Type Dimension Package Type Key (PK) Package Type Description Storage Type Dimension Storage Type Key (PK) Storage Type Description Shelf Life Type Key (FK) Category Key (PK) Category Description Department Key (FK) Shelf Life Type Dimension Shelf Life Type Key (PK) Shelf Life Type Description Department Key (PK) Department Description b) Várias tabelas normalizadas para a mesma dimensão produto 16

17 Snowflaking 3 Tabelas de dimensões não devem ser normalizadas Aumentaria o número de tabelas Tornaria o design lógico mais complexo Interrogações seriam mais di~ceis de escrever Interrogações seriam mais demoradas (mais junções de tabelas) Acessos a tabelas de dimensões são Epicamente leituras e não escritas Poupança do espaço ocupado pelas dimensões seria insignificante Tabelas de dimensões ocupam Vpicamente 10% do espaço do data warehouse Exceções Dimensões monstras e com muitos atributos relacionados entre si Ex. dimensão cliente com rendimento e dados demográficos da região Facilita comparação de rendimento do cliente com a média da região onde vive Mas dados demográficos são repevdos para todos os clientes da mesma região 17

18 Análise de Dimensões 1 Interrogações OLAP limitadas pelos acessos a disco Mais espaço ocupado no disco tem geralmente pior desempenho Design das dimensões afeta diretamente o espaço ocupado em disco Caso de estudo 100 milhões de linhas de factos 3 medidas de negócio com 4 bytes cada (12 bytes no total) 100 atributos de dimensões, cada um ocupando 20 bytes em média 3 designs alternavvos A. Uma dimensão com todos os atributos B. Cada atributo numa tabela de dimensão Casos extremos C. 5 dimensões: data, produto, loja, promoção, transação 18

19 Análise de Dimensões 2 Design A: uma tabela de dimensão com todos os atributos Tabela pouco inteligível Tabela de factos muito estreita Assumindo chaves estrangeiras com 4 bytes 16 bytes/linha = (4+4+4) medidas + 4 sdimensão Espaço em disco = 100 milhões linhas 16 bytes/linha 1,5 GBytes Tabela de dimensão muito larga 2004 bytes/linha = 20 bytes/atributo 100 atributos + 4 bytes chave Tabela de dimensão tem mesmo número de linhas que tabela de factos Espaço em disco = 100 milhões linhas 2004 bytes/linha 186 GBytes Espaço total ocupado em disco 190 GBytes 19

20 Análise de Dimensões 3 Design B: uma tabela por atributo de dimensão Design de Vpo centopeia (com demasiadas dimensões) Tabela de factos larga Assumindo chaves estrangeiras com 2 bytes 212 bytes/linha = (4+4+4) medidas + (100 2) chaves estrangeiras Espaço em disco = 100 milhões linhas 212 bytes/linha 20 GBytes Tabelas de dimensões muito finas e com poucas linhas Cada linha de tabela de dimensão ocupa 22 bytes = 2 chave + 20 atributo 2 bytes da chave primária permitem até = 2 16 valores diferentes Espaço máximo/dimensão = linhas 22 bytes/linha 1,4 MBytes Espaço em disco = 100 tabelas 1,4 MBytes/tabela 138 MBytes Espaço máximo ocupado em disco 20 GBytes 20

21 Análise de Dimensões 4 Design C: 5 dimensões naturais Data, produto, loja, promoção, transação Tabela de factos fina 2 bytes para cada chave estrangeira que referencia data e loja 4 bytes para cada referência a produto, promoção, e transação 28 bytes/linha = (4+4+4) medidas + (2 2) + (4 3) Espaço em disco = 100 milhões linhas 28 bytes/linha 2,6 GBytes Tabelas de dimensões largas e com poucas linhas Em geral, 10% do espaço total do data warehouse Espaço para as dimensões muito inferior a 1 GByte Espaço total ocupado em disco 3 GBytes 21

22 Análise de Dimensões 5 Em síntese Para os mesmos atributos e factos Espaço ocupado em disco varia com o número de dimensões Design Dimensões GBytes A B C 5 3 Fator importante a ter em conta Como é que os decisores pensam nos dados? Resposta ajuda a colocar os atributos nas dimensões Ex. 2 tipos de promoções (cupões e fim de stock) em 2 dimensões ou 1? Se análises xpicas requerem ambos os Vpos de promoções uma só dimensão Em geral, preferível ter poucas dimensões, pois design mais simples Até 15 dimensões é um número aceitável em vários contextos 25 ou mais dimensões sugerem um design de tipo centopeia (a evitar) 22

23 Medidas e AdiEvidade Tabelas de factos geralmente contêm medidas adievas Permitem a soma de valores ao longo de todas as dimensões Soma é das operações mais úteis Exemplos QuanVdades, vendas, erros, durações Medidas não adivvas Temperaturas, níveis de humidade, Médias, mínimos, máximos Mês Vendas Abril 1455,02 Maio 1845,32 Junho 2012,23 Q2 5312,57 Devem ser apenas guardados dados agregáveis Em vez de preço unitário, guardar quanvdade vendida e valor total Regra geral, guardar o numerador e denominador em vez do resultado 23

24 Medidas SemiadiEvas Factos de natureza periódica têm medidas semiadivvas Ex. saldos mensais de conta bancária, inventários semanais de armazém Nestes casos, medidas só são adievas em algumas dimensões Não faz sentido adicionar saldos/níveis de inventário ao longo do tempo Mas é legívmo somar ao longo de outras dimensões Dinheiro total do cliente é a soma dos saldos das suas várias contas Total de produtos no armazém é a soma da quanvdade de cada produto Operações agregadoras semiadivvas Podem ser aplicadas mesmo quando não é possível somar Média, mínimo, máximo, e contagem Ex. média de saldos mensais/níveis semanais de inventário 24

25 Tabelas de Factos sem Factos Guardam factos sem medidas de negócio Servem para acompanhamento simples de eventos Exemplo 1: assiduidade às aulas Grão: uma linha por presença de aluno numa aula Dimensões: data, aluno, professor, disciplina, sala Responde a: Disciplinas com mais alunos? Salas mais usadas? Exemplo 2: épocas de promoção de produtos Grão: uma linha por cada promoção de produto, quando, e em que loja Dimensões: promoção, produto, data, loja Semelhante a tabela de factos de vendas, mas sem medidas Responde a: que produtos esvveram em promoção e não venderam? 25

26 Bibliografia Ralph Kimball e Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Wiley, 2002 Capítulos 1 e 2 Ralph Kimball e Margy Ross, The Kimball Group Reader: Relentlessly PracGcal Tools for Data Warehousing and Business Intelligence, Wiley, 2010 Secções 5.1, 6.1, 8.10, 8.17, , 10.1,