Tópicos Avançados de Bases de Dados

Transcrição

1 , 2004/2005 Tópicos Avançados de Bases de Dados Henrique Madeira 2004/ Data Warehousing e OLAP 2 Data Warehousing e OLAP 1

2 , 2004/2005 Bibliografia (tópico de Data Warehousing) Apontamentos do docente; Livros sobre DW: - The Data Warehouse Lifecycle Toolkit, Ralph Kimbal, Ed. J. Wiley & Sons, Inc, "The Data Warehouse Toolkit", Ralph Kimbal, Ed. J. Wiley & Sons, Inc, 1996; - "Building the data warehouse", W. H. Inmon, Ed. J. Wiley & Sons, Inc, 1996; - "The data model resouce book", L. Silverston, W. H. Inmon e K. Graziano, Ed. J. Wiley & Sons, Inc, 1997; - "Data Warehousing, Concepts, Technologies, Implementations, and Management", Harry Singh, Ed. Prentice Hall, 1998; - "The Internet Data Warehouse", Rick Tanler, Ed. J. Wiley & Sons, Inc, 1997; - "Managing the Data Warehouse", W. H. Inmon, J. Welch, K. Glassey, Ed. J. Wiley & Sons, Inc, 1997; - "Oracle data warehousing", M. Corey e M. Abbey, Osborne McGraw Hill, 1997; 3 Características genéricas das Data Warehouses 4 Data Warehousing e OLAP 2

3 , 2004/2005 O que é uma data warehouse? Base de dados de grande dimensão que armazena dados para apoio à decisão estratégica. São construídas a partir de bases de dados operacionais e de outros sistemas usados numa organização. BD operacionais e outros sistemas Data Warehouse Utilizadores Utilizadores 5 Volume de dados Até 20 Gbytes Pequena dimensão; corre num bom PC De 20 a 100 Gbytes Média dimensão; precisa de workstation poderosa; De 100 Gbytes a 1 TBytes Grande dimensão; servidores poderosos, normalmente com processamento paralelo Superior a 1 TBytes Enorme dimensão; necessita processamento maciçamente paralelo. 6 Data Warehousing e OLAP 3

4 , 2004/2005 Algumas características de DW Dependência temporal; Não volatilidade; Orientadas para fins específicos; Integração e consistência informação; Estrutura de dados optimizada para a consulta. 7 Dependência temporal Os dados na DW foram recolhidos ao longo do tempo (não são instantâneos); É preciso adicionar aos dados o instante temporal a que estes se reportam. 8 Data Warehousing e OLAP 4

5 , 2004/2005 Não volatilidade Os dados numa DW são actualizados; A DW armazena os dados históricos (memória histórica) das BD operacionais de onde foi gerada; Depois de carregados (a partir de uma BD operacional) a única operação é fazer queries. 9 Orientadas para fins específicos Devem ser guardados apenas os dados relevantes para a tomada de decisões; Muitos dados necessários à gestão do dia-a-dia dos sistemas operacionais não têm relevo para a DW. 10 Data Warehousing e OLAP 5

6 , 2004/2005 Integração e consistência de informação No ambiente operacional a mesma informação pode residir em dados com nome e aspecto diferente; É necessário integrar e dar consistência aos dados provenientes das BD operacionais antes de os armazenar na DW. 11 Optimização das consultas Uma vez carregados, os dados só são alvo de consultas; As DW têm quantidades enormes de dados. Visão multidimensional Desnormalização parcial Os dados devem ser armazenados de forma a acelerar ao máximo as consultas 12 Data Warehousing e OLAP 6

7 , 2004/2005 Visão genérica do modelo dimensional 13 Modelo dimensional Modelo usual em bases de dados operacionais: E/R O modelo dimensional é uma alternativa contém a mesma informação... organiza-a de forma simétrica orientada para o utilizador: Fácil compreensão Bom desempenho nas pesquisa Data Warehouses construídas sobre E/R complexos falham 14 Data Warehousing e OLAP 7

8 , 2004/2005 Modelo multidimensional Continente Leiria Continente Coimbra Hipermercado Produto Leite Farinha Açúcar Café Vendas Jan Fev Mar Abr Data 15 Exemplo de esquema em estrela Tempo Cadeia de Lojas ID_data Dia Dia_da_semana Semana_do_ano Mês Trimestre Ano Produto ID_produto Nome Tipo Marca Categoria Embalagem Descrição Venda ID_data ID_produto ID_loja Unid_vendidas Custo_compra Valor_venda Nº_Clientes Loja ID_loja Nome Localidade Distrito Área Nº_Caixas 16 Data Warehousing e OLAP 8

9 , 2004/2005 Modelo em estrela O modelo dimensional típico conduz a uma estrutura em estrela, contendo uma tabela central com os factos à qual estão ligadas as tabelas das dimensões. Tabela dimensão 1 ID_dimensão 1 Descrição 1 Atributo. Tabela dimensão 2 ID_dimensão 2 Descrição 2 Atributo. Tabela Factos ID_dimensão 1 ID_dimensão 2 ID_dimensão 3 ID_dimensão 4 Facto 1 Facto 2. Facto n Tabela dimensão 3 ID_dimensão 3 Descrição 3 Atributo. Tabela dimensão 1 ID_dimensão 4 Descrição 4 Atributo. 17 Tabela de factos Contém as medidas do negócio Os factos mais uteis são numéricos aditivos Representam relacionamentos M:1 com as dimensões do negócio 18 Data Warehousing e OLAP 9

10 , 2004/2005 Tabelas de dimensão Tabelas companheiras da tabela de factos Cada dimensão representa parâmetros do negócio tempo, clientes, produtos, etc Chave primária determina o dado específico Outros atributos específicos da dimensão Desnormalizada e com hieraquias. 19 OLAP - Online Analytical Processing Pesquisa e apresentação de texto e dados numéricos das Data Warehouses ROLAP (Relational OLAP) Estrutura, interfaces com o utilizador e aplicações que permitem implementar o modelo dimensional num motor de base de dados relacional MOLAP (Multidimensional OLAP) o mesmo sobre um motor não relacional 20 Data Warehousing e OLAP 10

11 , 2004/2005 Pesquisas - baixo nível Tempo ID_data Dia Dia_da_semana Semana_do_ano Mês Trimestre Ano Produto ID_produto Nome Tipo Marca Categoria Embalagem Descrição Cadeia de Lojas Venda ID_data ID_produto ID_loja Unid_vendidas Custo_compra Valor_venda Nº_Clientes Loja ID_loja Nome Localidade Distrito Área Nº_Caixas Select avg(valor_venda x Unid_vendidas) from Venda V, Tempo T, Produto P where JOIN_TABELAS group by P.Marca, T. Mês 21 Interfaces com o utilizador Exploração de dados na Data Warehouse Ferramenta OLAP típica acesso a motor relacional via SQL apresentação em tabela, gráfico, relatório, etc normalmente orientado para pesquisas ad-hoc Outras ferramentas Data mining Modelação 22 Data Warehousing e OLAP 11

12 , 2004/2005 Browsing Explorar uma das dimensões definindo restrições e escolhendo as colunas pretendidas. coluna Nome_Loja Localidade Distrito Area_total Nºcaixas restrição valores Loja Zé Ansião Coimbra distintos Super Mário Aveiro Leiria Super Bill Coimbra Aveiro Loja da Maria Leiria 1000 Loja do Manel Penacova 1500 John's Market Penela Vieiras Pombal Loja 007 Cadeia Joel Loja dos Browsing (exemplo) Quais os nomes e onde se situam as lojas do distrito de Coimbra com área igual a 750 m 2 e com 4 caixas? coluna Nome_Loja Localidade Distrito Area_total Nºcaixas restrição Coimbra valores Loja do Manel Coimbra Coimbra distintos John's Market Penacova Vieiras Loja dos Data Warehousing e OLAP 12

13 , 2004/2005 Pesquisas - Slice and Dice Vendas por tempo e produto Vendas por loja e marca 25 Drill-Down & Roll-Up Drill-Down Categoria mais genérica Roll-up Categoria intermédia Categoria mais detalhada Detalhe completo 26 Data Warehousing e OLAP 13

14 , 2004/2005 Tempo: Drill-Down & Roll-Up Drill-Down ALL Ano Trimestre Roll-up Mês Semana Dia 27 Tempo: Drill-Down (exemplo) Select avg(valor_venda x Unid_vendidas) from Venda V, Tempo T, Produto P where JOIN_TABELAS group by P.Marca, T. Mês; Select avg(valor_venda x Unid_vendidas) from Venda V, Tempo T, Produto P where JOIN_TABELAS group by P.Marca, T. Dia; Questão: como se representa o ALL na pesquisa? 28 Data Warehousing e OLAP 14

15 , 2004/2005 Arquitectura geral da Data Warehouse 29 Elementos básicos de uma data warehouse BDs operacionais Sistemas legados Data warehouse (presentation servers) ROLAP/ MOLAP Utilizadores Ad hoc queries Relatórios Folhas de cálculo, ficheiros,... Fontes externas Data Staging Area Aplicações específicas Modelos e outras ferramentas 30 Data Warehousing e OLAP 15

16 , 2004/2005 Data Marts É, normalmente, um subconjunto de uma DW; Numa Data Mart os dados são focalizados numa área específica (processo de negócio); Muitas vezes uma Data Mart é feita para responder rápidamente a uma área de actividade. 31 Arquitectura de BDs de uma organização 1 BDs operacionais Sistemas legados Data Warehouse Data Mart Folhas de cálculo, ficheiros,... Fontes externas Utilizadores Utilizadores 32 Data Warehousing e OLAP 16

17 , 2004/2005 Arquitectura de BDs de uma organização 2 BDs operacionais Data Mart Sistemas legados Data Warehouse Folhas de cálculo, ficheiros,... Fontes externas Utilizadores Utilizadores 33 Sistemas fonte sistema de registo de transacções gestão de clientes, gestão de produtos, gestão de vendas, etc principais características assumidas disponibilidade pesquisas típicas limitadas a fichas individuais mantêm pouca informação histórica A obtenção de relatórios de gestão é complicada e pesada Pouca ligação com restantes sistemas da empresa registos de facturação não ligados a base de produtos ou clientes 34 Data Warehousing e OLAP 17

18 , 2004/2005 Área de processamento temporário (Staging Area) Área e processos que actuam sobre os dados fonte limpeza transformação combinação preparação Staging Area Data Warehouse 35 Metadados É necessário uma estrutura (na prática outra base de dados) para descrever os dados da DW. Deve descrever: Que dados existem na DW; Qual o seu formato; Onde estão armazenados; Como se relacionam com os dados de outras bases de dados; Qual a proveniência dos dados e quem são os seus donos. 36 Data Warehousing e OLAP 18

19 , 2004/2005 Processos básicos da DW Extracção (a partir dos sistemas fonte) Transformação e limpeza de dados (na staging area) Carregamento e indexação Tratamento de erros Pesquisa (utilização normal) 37 Transformação Limpeza dos dados Eliminação de campos inuteis campos dos sistemas opeacionais que são desnecessários na DW Combinação de fontes de dados coincidência exacta de chaves ou fuzzy matches Criação de chaves primárias da DW independentes dos sistemas operacionais Criação de dimensão temporal Construção de agregados para melhoria de velocidade em pesquisas 38 Data Warehousing e OLAP 19

20 , 2004/2005 Limpeza dos dados Limpeza dos dados correcção de erros (de escrita) correcção de inconsistências (cidade-código postal) eliminação de duplicados (o mesmo nome PEDRO e Pedro) tratamento de faltas de dados (campos vazios) pôr os dados em formatos standard 39 Carregamento Staging Area Transformação Carregamento DW Preenche dimensões e factos temporários com dados do período em causa Realiza o carregamento BULK LOAD carregamento ficha-a-ficha seria demasiado lento Indexa os dados carregados 40 Data Warehousing e OLAP 20

21 , 2004/2005 BD operacionais vs Data Warehouses Dados operacionais Objectivos operacionais Acessos de leitura/escrita Acesso por transacções pré-definidas Acesso a poucos registos de cada vez Dados da Warehouse Registo histórico Acessos só de leitura Acesso por queries ad hoc e relatórios periódicos Muitos registos em cada acesso Dados actualizados em tempo real Estrutura optimizada para actualizações Event-driven: os processos geram dados Carregamentos periódicos de mais dados Estrutura optimizada para queries complexas Data-driven: os dados geram respostas 41 Visão genérica sobre o processo de construção de uma Data Warehouse 42 Data Warehousing e OLAP 21

22 , 2004/2005 Infraestrutura para projecto Construir uma DW é complexo e requer conhecimento especializado em várias áreas Definir equipa; Definir ferramentas e sistemas; Identificar fases do projecto; Definir métodos de trabalho; Identificar responsabilidades para cada tarefa/fase. 43 Esquema geral do projecto de uma Data Warehouse (R. Kimball) Planeamento do projecto Definição dos requisitos do negócio Desenho da arquitectura Modelação dimensional Desenho físico Selecção e instalação de produtos Desenho do Data Staing Colocação em Produção Especificação das aplicações de utilizador Gestão do projecto Desenvolvimento das aplicações 44 Data Warehousing e OLAP 22

23 , 2004/2005 Passos na construção de uma DW Identificação de objectivos (de gestão) a atingir com a DW; Definir infraestrutura para o projecto; Identificar modelo de dados das BD operacionais fonte; Definir modelo de dados para a DW; Definir regras para o mapeamento de dados; Extrair, integrar, purificar e consolidar os dados; Ferramentas de exploração, afinação de desempenho e avaliação de eficácia. 45 Objectivos a atingir com a DW É necessário ter um entendimento profundo do processo de negócio que a DW vai apoiar. Quais são os objectivos e estratégia da empresa/instituição? Qual a informação necessária para atingir esses objectivos? Porque é que a informação é necessária? Quem vai usar essa informação (dentro da empresa)? Como é que a informação vai ser usada? 46 Data Warehousing e OLAP 23

24 , 2004/2005 Identificar modelo de dados das BD fonte Bases de dados operacionais 47 Modelo de dados das BD fonte (cont.) Responder à questão: quais os dados fonte para a DW? Muitas vezes os modelos de dados das BD operacionais não existem ou estão desactualizados; Necessário usar ferramentas de reverse-engineering; Alguns dados da DW podem ter outras origens que não as BD operacionais. 48 Data Warehousing e OLAP 24

25 , 2004/2005 Dados históricos, de referência e sínteses No processo de indentificar os dados a extrair para a DW é útil olhar os dados sob grandes grupos: Dados históricos (factos) Dados correspondentes a entidades que descrevem factos (vendas, encomendas, facturas, consultas, pagamentos, etc) Dados de referência (dimensões) Dados correspondentes a entidades de referência que permitem completar e situar os dados dos factos históricos (clientes, fornecedores, pessoas, etc) Sínteses Dados previamente calculados e que se prevê virem a ser necessários (relatórios de vendas mensais, movimentos semanais de stock, etc) 49 Definir modelo de dados da DW Desenvolver/entender o modelo de negócio da DW, identificar processos de negócio e identificar dados disponíveis (nas BDs operacionais); Par cada processo de negócio: Identificar os factos (valores numéricos); Escolher a granularidade dos factos (determina a precisão com que poderá ser feita a análise); Definir as dimensões de interesse. 50 Data Warehousing e OLAP 25

26 , 2004/2005 Modelos na construção de uma DW Modelo do negócio (ER) Desnormalização sistemática Que transações? Que queries? Modelo dimensional Modelo físico 51 Definir regras para o mapeamento de dados Identificar os dados a extrair; Identificar os dados que faltam (impossíveis de extrair das BD operacionais); Definir regras e processos para integrar, compatibilizar e limpar os dados; Documentar todas os passos para permitir que os dados históricos possam ser entendidos posteriormente. 52 Data Warehousing e OLAP 26

27 , 2004/2005 Extrair, integrar, purificar e racionalizar os dados Usar ou construir as ferramentas que concretizam as regras para mapeamento dos dados; Rever regras e processos de mapeamento sempre que são detectadas inconsistências; Documentar todos os passos. 53 Exploração, afinação e avaliação de eficácia Definição/construção de ferramentas de exploração; Afinação de desempenho; Administração da data warehouse. 54 Data Warehousing e OLAP 27

28 , 2004/2005 O modelo multidimensional 55 Modelo multidimensional Factos armazenados num array multidimensional; As dimensões são usadas para indexar o array; Normalmente construídas sobre bases de dados relacionais. Continente Leiria Continente Coimbra Hipermercado Produto Leite Farinha Açúcar Café Vendas Jan Fev Mar Abr Data 56 Data Warehousing e OLAP 28

29 , 2004/2005 Exemplo de esquema em estrela Cadeia de Lojas Tempo ID_data Dia Dia_da_semana Semana_do_ano Mês Trimestre Ano Produto ID_produto Nome Tipo Marca Categoria Embalagem Descrição Venda ID_data ID_produto ID_loja Unid_vendidas Custo_compra Valor_venda Nº_Clientes Loja ID_loja Nome Localidade Distrito Área Nº_Caixas 57 Modelo em estrela O modelo dimensional típico conduz a uma estrutura em estrela, contendo uma tabela central com os factos à qual estão ligadas as tabelas das dimensões Tabela dimensão 1 ID_dimensão 1 Descrição 1 Atributo. Tabela dimensão 2 ID_dimensão 2 Descrição 2 Atributo. Tabela Factos ID_dimensão 1 ID_dimensão 2 ID_dimensão 3 ID_dimensão 4 Facto 1 Facto 2. Facto n Tabela dimensão 3 ID_dimensão 3 Descrição 3 Atributo. Tabela dimensão 1 ID_dimensão 4 Descrição 4 Atributo. 58 Data Warehousing e OLAP 29

30 , 2004/2005 Algumas características do modelo em estrela Tabela de Factos Constituída por atributos numéricos (factos) e pelas chaves forasteiras que a ligam à tabelas de dimensões; A tabela de factos está bastante normalizada; Contém normalmente uma enorme quantidade de registo (ocupa vulgarmente mais de 95% do espaço da DW). Tabelas de Dimensões Tabela ID_dimensão dimensão 1 Descrição 1 Atributo. Tabela ID_dimensão dimensão 2 Descrição 2 Atributo. Tabela Factos ID_dimensão 1 ID_dimensão 2 ID_dimensão 3 ID_dimensão 4 Facto 1 Facto 2. Facto n Há tantas dimensões quantas vertentes sob as quais se pretende analisar os factos; As tabelas de dimensões são fortemente desnormalizadas, sendo normalmente tabelas com muitos atributos; Normalmente, apesar de terem muitos atributos, contêm poucos registos (quando comparados com a tabela de factos). Tabela ID_dimensão dimensão 3 Descrição 3 Atributo. Tabela ID_dimensão dimensão 14 Descrição 4 Atributo. 59 Passos para definir modelos em estrela 1 - Identificar os processos de negócio/actividade 2 - Identificar os factos; 3 - Identificar dimensões; 4 - Escolher a ganularidade dos dados a registar. Sem perder de vistas os dados efectivamente disponíveis (BDs operacionais, ficheiros, etc) 60 Data Warehousing e OLAP 30

31 , 2004/2005 Exemplo Cadeia de supermercados Cadeia de supermercados de uma mesma empresa Vamos pensar apenas nas vendas (a aquisição de produtos aos fornecedores é global para toda a empresa) Cada supermercado tem vários departamentos (mercearia, higiene e limpeza, etc) Vende vários milhares de produtos Os produtos são identificados univocamente por códigos. código SKU ( Stock Keeping Units ) códigos de barras universais SKU = UPC 61 Dados do negócio Onde recolher os dados? Caixa registadora (POS - point of sales). Na prática, os dados são recolhidos na base de dados que gere as existências, sendo as caixas registadoras meros terminais. O que interessa medir? Vendas Qual o objectivo? Maximização do lucro máximo preço de venda possível mais baixos custos de aquisição e administrativos mais clientes 62 Data Warehousing e OLAP 31

32 , 2004/2005 Factos - Cadeia de Lojas Identificar os factos de Vendas Exemplo de factos relevantes para a gestão: Número de unidades vendidas, custo do produto quando fornecido pelo vendedor, valor total das vendas do produto, número de clientes que comprou o produto. Questão: será que é possível obter dados base (no sistema operacional) para obter estes factos? Dimensão Loja Dimensão Tempo ID_data atributos. Dimensão Produto ID_produto atributos... Factos VENDAS ID_data ID_produto ID_loja ID_promoção Unid_vendidas Custo_compra Valor_venda Nº_clientes ID_loja atributos... Dimensão Promoção ID_promoção atributos Dimensões - Cadeia de Hipermercados Dimensões principais Produto x Tempo x Loja Existirão outras dimensões de interesse? Fornecedores? Promoções? Cliente? Nome do empregado responsável naquele dia? É normalmente possível adicionar dimensões extra às dimensões principais Todas dimensões tomam um só valor para cada combinação 64 Data Warehousing e OLAP 32

33 , 2004/2005 Dimensões - Cadeia de Hipermercados Dimensão Tempo ID_data atributos. Dimensão Produto ID_produto atributos... Factos VENDAS ID_data ID_produto ID_loja ID_promoção Unid_vendidas Custo_compra Valor_venda Nº_clientes Dimensão Loja ID_loja atributos... Dimensão Promoção ID_promoção atributos Granularidade Exemplo: registar as vendas de todos os produtos diariamente Podemos ver de forma detalhada que produtos são vendidos e em que lojas, a que preços e em que dias, Granularidade: produtos x loja x promoção x dia A granularidade determina a dimensionalidade da DW e tem um forte impacto no seu tamanho A granularidade deve ser adequada às necessidades de análise. 66 Data Warehousing e OLAP 33

34 , 2004/2005 Granularidade: alternativas Porquê SKU em vez de marca ou tipo de produto? Valerá a pena ter tantas unidades de um determinado tamanho para um dado produto? Ao nível da factura tamanho da base de dados poderia tornar-se gigantesco identificação do cliente não existe assim não é possivel analisar os dados de comportamento de compras Semanal ou mensal perder-se-iam efeitos interessantes a nível diário variações de vendas entre 2ªs e Sábados efeitos de promoções de dois dias 67 Detalhe selectivo Porque é que os dados devem ser expressos com um detalhe grande num Data Warehouse? Não por ser necessário aceder a valores específicos mas as pesquisas cortam dimensões selectivamente e de forma precisa Select Join Group By produto, mês 68 Data Warehousing e OLAP 34

35 , 2004/2005 Refinar o modelo Detalhar as dimensões Rever os factos Verificar a consistência (entre factos, entre factos e dimensões, etc) Reavaliar granularidade 69 Exemplo 1 - Cadeia de lojas Produto ID_produto Número Nome Marca Categoria Subcategoria Departamento Tam_embalagem Tipo_embalagem Tipo_dieta Peso Unidade_de_peso Quant_caixa Caixas_p_pallete Larg_prateleira Altura_prateleira Profun_prateleira... Tempo ID_data Dia_do_mês Dia_da_semana Dia_do_ano Semana_do_ano Mês Número_do_mês Trimestre Período_fiscal Flag_feriado Flag_dia_semana Flag_últ_dia_mês Estação_ano Aconteci_espec. ID_produto ID_data ID_Loja ID_Promoção Unid_vendidas Custo_compra Valor_venda Nº_clientes Promoção ID_promoção Número Nome_promo Tipo_red_preço Tipo_anúncio Tipo_cartaz Tipo_coupons Meio_anúncio Meio_cartaz Custo_promoção Início_promoção Fim_promoção... Loja ID_loja Nome Número_loja Endereço Localidade Código_postal Distrito Região Telefone Fax Gestor_loja Área_total Área_mercearias Área_congelados Área_bazar Nº_Caixas Data_inauguração Data_ult_remod Data Warehousing e OLAP 35

36 , 2004/2005 Exemplo 1: Dimensão tempo Tempo ID_data Dia_do_mês Dia_da_semana Dia_do_ano Semana_do_ano Mês Número_do_mês Trimestre Período_fiscal Flag_feriado Flag_dia_semana Flag_último_dia_mês Estação_ano Acontecimento_espec. Existe sempre, pois representa a dependência temporal inerente à DW; Deve descrever o tempo tal como ele é visto para fins de gestão da actividade (negócio) em causa; Deve conter a caraterização do tempo nos atributos pelos quais se pretende posteriormente fazer pesquisas; É gerada, normalmente, de uma forma sintética (i.e., sem ser a partir de uma BD operacional) para todo o período de tempo considerado na DW. 71 Exemplo 1: Dimensão produto Produto ID_produto Número Nome Marca Categoria Subcategoria Departamento Tam_embalagem Tipo_embalagem Tipo_dieta Peso Unidade_de_peso Quantidade_caixa Caixas_por_pallete Largura_prateleira Altura_prateleira Profud_prateleira... Deve conter a caraterização dos produtos tal como eles são vistos pelo gestor da cadeia de lojas; Contém todos os atributos pelos quais se pretende posteriormente fazer perguntas; Como acontece normalmente nas tabelas de dimensões, é uma tabela bastante desnormalizada. 72 Data Warehousing e OLAP 36

37 , 2004/2005 Exemplo 1: Dimensão loja Loja ID_loja Nome Número_loja Endereço Localidade Código_postal Distrito Região Telefone Fax Gestor_loja Área_total Área_mercearias Área_congelados Área_bazar Nº_Caixas Data_inauguração Data_ultim_remod.... Contém a caraterização das lojas tal como eles são vistos pelo gestão da cadeia de lojas; Contém todos os atributos pelos quais se pretende posteriormente fazer perguntas, incluindo atributos de natureza geográfica (localização) e de natureza temporal (datas de inauguração, ). 73 Exemplo 1: Dimensão promoções Promoção ID_promoção Número Nome_promo Tipo_red_preço Tipo_anúncio Tipo_cartaz Tipo_coupons Meio_anúncio Meio_cartaz Custo_promoção Início_promoção Fim_promoção... Contém a caraterização das promoções efectuadas; Neste exemplo há apenas uma dimensão de promoções (para todos os tipos de promoções), mas seria possível ter em alternativa uma dimensão para cada tipo de promoção; A dimensão promoção representa, neste exemplo, uma dimensão muito sensível e importante, pois as promoções são um dos aspectos em que o gestor mais facilmente pode actuar quando pretende incrementar as vendas numa loja ou num determinado produto. 74 Data Warehousing e OLAP 37

38 , 2004/2005 Cálculo simplificado do espaço ocupado Granularidade = Produtos vendidos / em cada loja / em cada dia Tempo = 3 anos Nº Produtos = (apenas 20% dos produtos são vendidos diariamente) Lojas = 100 Tamanho médio de registo = 8 atributos x 4 Bytes = 32 Bytes Nº de registos de factos = 3 x 365 x x 100 = Tamanho aproximado da DW = 32 x = 70 GBytes Despreza-se o espaço ocupado pelas tabelas de dimensões; Não considera o armazenamento dos índices nem vistas materializadas; 75 Exemplo 2: Existências em armazéns Caracterização da actividade de gestão de existências Recepção; Recolha do stock; Inspecção; Embalagem; Armazém Entrada no stock; Saída Autorização de venda; Procedimentos excepcionais: Detecção de falha na inspecção Devolução ao fornecedor Deteriorização no manuseamento Perda do produto Devolução do cliente Reentrada no stock ; 76 Data Warehousing e OLAP 38

39 , 2004/2005 Ex. 2: Fotografia periódica de existências Tempo Produto Existências ID_tempo ID_produto ID_armazém Quant_existente Valor_de_custo Último_preço_venda Quant_saída Armazém Registo periódico das existências em stock; A Quantidade_existente não é aditiva na dimensão tempo A Quantidade_saída permite saber quantos produtos saíram no intervalo de tempo correspondente a dois registos. 77 Ex. 2: Registo de transações de existências Tempo Produto Existências ID_tempo ID_produto ID_armazém ID_transacção Nº_Documento Quantidade Quant_existente Armazém Transacção Contém um registo por cada possível alteração (transacção) das existências, constituindo a forma mais detalhada de representar a evolução do stock; O conjunto de possíveis transacções é reduzido. Necessita de atributos como Quant_existente (típicos do modelo fotográfico ) para dar uma visão prática do processo. 78 Data Warehousing e OLAP 39

40 , 2004/2005 Ex. 2: Cálculo simplificado do espaço ocupado Tempo = 3 anos Fotografia periódica das existências Nº Produtos = Armazéns = 4 Tamanho médio de registo = 7 atributos x 4 Bytes = 28 Bytes Nº de registos de factos = 3 x 365 x x 4 = Tamanho aproximado da DW = 28 x = 61,32 GBytes Tempo = 3 anos Registo de transacções de existências Nº Produtos = Armazéns = 4 Tamanho médio de registo = 7 atributos x 4 Bytes = 28 Bytes Nº entregas (no armazém) por ano = 10 Nº de transacções por cada entrega de produto = 50 Nº de registos de factos = 3 x x 4 x 10 x 50 = Tamanho aproximado da DW = 24 x = 84 GBytes 79 Redução espaço ocupado: abordagem simplista Em muitas situações poderá ser aceitável ter informação detalhada para as existências apenas relativa ao último mês: Exemplo (método da fotografia periódica das existências) Registo diário das existências do último mês; Média semanal das restantes semanas do ano (48 semanas); Média mensal dos meses dos últimos dois anos. Nº de fotografias = 30 (dias) + 48 (semanas) + 24 (meses) = 102 (em vez de 3 x 365 = 1100) 80 Data Warehousing e OLAP 40

41 , 2004/2005 Cruzamento de dados entre processo de negócio diferentes Data Mart - marketing Como cruzar os dados? Definições e carregamentos de dimensões e factos de forma independente? Data Mart - facturação 81 Mais do que uma estrela Loja Vendas ID_data ID_produto ID_Loja Unid_vendidas Custo_compra Valor_venda Nº_Clientes Tempo Produto Existências ID_tempo ID_produto ID_armazém Quant_existente Quant_saída Valor_de_custo Últim_preço_venda Armazém Uma ou mais estrelas interligam-se por uma ou mais dimensões; As dimensões que promovem a interligação têm de ser conformes (conter informação consistente entre si); Drill across: consulta à DW que cruza mais do que uma estrela. 82 Data Warehousing e OLAP 41

42 , 2004/2005 Exemplo de múltiplas estrelas Armazenistas distribuidores Encomendas Dimensão: Tempo Dimensão: Componente Dimensão: Fornecedor Dimensão: Contrato Vendas Dimensão: Tempo Dimensão: Componente Dimensão: Cliente Dimensão: Contrato Existências Dimensão: Tempo Dimensão: Componente Dimensão: Armazém 83 Exemplo de dimensões conformes Dimensão_1 Dimensão_5 Dimensão_4 Tabela de Factos Dimensão_2 Tabela de Factos Dimensão_6 Dimensão_1 Dimensão_3 Dimensão_7 Dimensão10 Tabela de Factos Dimensão_9 Dimensão_8 Têm de ser conformes 84 Data Warehousing e OLAP 42

43 , 2004/2005 Factos não aditivos (ou semi-aditivos) Os factos não são aditivos ao longo de uma ou mais dimensões quando a sua soma não tem significado real (mas a média já pode ter, pelo que o facto é útil). Nem sempre é fácil para o utilizador perceber que está a fazer adições de factos não aditivos, o que pode levar a conclusões erradas. Exemplos: Factos que representam níveis estáticos como saldos de contas ou existências num inventário; A não aditividade pode resultar de peculiariedades do modelos de estrela (por exemplo, o facto Nº_Clientes no exemplo Cadeia de Lojas ) 85 Grandes dimensões Em certas situações dimensões como Produtos ou Clientes podem ter milhões de registos; É muito frequente estas dimensões terem até uma centena de atrubutos; Pode ser interessante normalizar parcialmente estas dimensões 86 Data Warehousing e OLAP 43

44 , 2004/2005 Flocos de neve Produto ID_produto Número Nome ID_Tam_emb ID_marca Peso Unidade_de_peso Quantidade_caixa Caixas_por_pallete Largura_prateleira Altura_prateleira Profud_prateleira... ID_Tam_emb Tipo_embalag ID_marca ID_marca Categoria ID_subcat ID_subcat Categoria ID_dept ID_Dept Departamento Uma dimensão pode ter múltiplas hierarquias (flocos de neve); Uma hierarquia consiste numa cadeia de típicos relacionamentos 1 para N 87 Vantagens e desvantagens de flocos Vantagens Economiza espaço; Desvantagens Aumenta o tempo de resposta a queries; Torna a construção das queries mais complexa. Por muito grande que seja uma dimensão, ela representa sempre uma percentagem pequena da espaço ocupado pela tabela de factos, pelo que estruturar uma dimensão em flocos de neve raramente se justifica 88 Data Warehousing e OLAP 44

45 , 2004/2005 Mini-dimensões Vendas ID_data ID_demograf ID_cliente ID_produto ID_promoção Unid_vendidas Custo_compra Valor_venda As combinações possíveis relativas a demografia (neste exemplo) ficam numa tabela própria. Permite economizar espaço e ganhar velocidade; Demográfica ID_demograf Faixa_etária Nível_rendimento Estado_civíl Sexo Hábitos_consumo Clientes ID_cliente Nome Apelido Rua Cidade Código_postal ID_demograf Alterações (actualizações) em dimensões O que fazer quando é necessário actualizar um dado registo de uma dimensão? Três alternativas: 1) Escrever por cima (perde-se a história); 2) Inserir um registo novo na dimensão com os valores actualizados; 3) Ter atributos na dimensão que permitam registar a evolução no tempo. 90 Data Warehousing e OLAP 45

46 , 2004/2005 1ª Escrever por cima Vendas ID_data ID_cliente ID_produto ID_promoção Unid_vendidas Custo_compra Valor_venda Clientes ID_cliente Nome Apelido Rua Cidade Código_postal Sexo Data_nascimento Estado_civil Rendimento_médio... Um dado cliente alterou o estado_civil Actualiza-se directamente o atributo da dimensão. Muito simples de tratar; Perde-se a história (o que é inaceitável na maior parte dos casos). 91 2ª Novo registo na tabela da dimensão Vendas ID_data ID_cliente ID_produto ID_promoção Unid_vendidas Custo_compra Valor_venda Clientes ID_cliente Nome Apelido Rua Cidade Código_postal Sexo Data_nascimento Estado_civil Rendimento_médio... Um dado cliente alterou o estado_civil Insere-se um novo registo na dimensão igual ao registo já existente desse cliente mas com o novo estado civíl. Mantém toda a informação histórica; Complexo; Necessita de chaves com estrutura (parte da chave é usada para identificar os registos que correspondem a alterações do cliente). 92 Data Warehousing e OLAP 46

47 , 2004/2005 Chaves com estrutura Cliente ID_Cliente Nome Apelido Estado_civil Ana Maria Silva Solteira Ana Maria Silva Casada Reserva-se três dígitos, por exemplo, para identificar sucessivas alterações de um mesmo cliente. Alternativamente, a chave pode ser composta por dois atributos: um que identifica o cliente outro que identifica a alteração. 93 3ª Atributos para registar alterações Vendas ID_data ID_cliente ID_produto ID_promoção Unid_vendidas Custo_compra Valor_venda Clientes ID_cliente Nome Apelido Rua Cidade Código_postal Sexo Data_nascimento Estado_civil_original Estado_civil_actual... Um dado cliente alterou o estado_civil Para cada atributo que pode variar no tempo passa-se a ter um conjunto de atributos que regista alguns passos (de alterações). Simples; Mantém apenas parcialmente a informação histórica. 94 Data Warehousing e OLAP 47

48 , 2004/2005 Exemplo 3: DW de um Banco Objectivo Vender melhor os seus produtos e oferecer serviços adicionais aos clientes que já possuem conta(s). 95 Exemplo 3: requisitos específicos: Pretende-se ver os dados históricos relativos aos últimos 5 anos. Para todos os meses anteriores ao actual é suficiente saber o saldo final do mês; Para o mês corrente apenas interessa a fotografia do dia anterior. Não são necessários os outros dias; Cada tipo de conta tem um saldo_primário; uma lista de atributos diferentes e factos numéricos também diferentes conforme o tipo de conta; Cada conta pertence a um cliente; Os nomes dos clientes podem diferir de conta para conta; Além da identificação do cliente estamos interessados em informação demográfica. 96 Data Warehousing e OLAP 48

49 , 2004/2005 Exemplo 3: DW de um banco: possíveis dimensões Dimensões: Conta Cliente Agência Produto Estado Tempo Granularidade: Conta por mês. 97 Exemplo 3: dimensões CONTA e CLIENTE Porquê dimensões diferentes CONTA e CLIENTE? Devido ao tamanho da dimensão conta e à sua volatilidade; podemos ter num grande banco : 10 milhões de contas e 3 milhões de clientes 98 Data Warehousing e OLAP 49

50 , 2004/2005 Exemplo 3: dimensões PRODUTO e ESTADO Dimensão PRODUTO contêm os atributos usados para descrever todos os produtos do banco; hierarquia: nome_do_produto tipo categoria; Dimensão ESTADO útil para gravar o estado da conta. Conta activa ou inactiva. 99 Exemplo 3: esquema da DW de um banco Conta ID_conta Titular Seg_titular Endereço Localidade Data_abertura D_nasc_titular Sexo_titular Est_civil_titular Cliente ID_cliente Nome_cliente Endereço Localidade Rendimento Tipo_cliente Tempo ID_tempo Mês Ano Trim_fiscal Factos_banco ID_conta ID_cliente ID_tempo ID_agência ID_produto ID_estado Saldo_primário Nºtransacções Estado ID_estado Descrição Motivo Flag_conta_nova Flag_conta_fechada Agência ID_agência Nome Endereço Localidade Tipo_agência Produto ID_produto Descrição Tipo Categoria 100 Data Warehousing e OLAP 50

51 , 2004/2005 Exemplo 3: dimensões sujas Conta ID_conta Titular Seg_titular Endereço Localidade Data_abertura D_nasc_titular Sexo_titular Est_civil_titular Factos_banco ID_conta ID_cliente ID_tempo ID_agência ID_produto ID_estado Saldo_primário Nºtransacções Cliente ID_cliente Nome_cliente Endereço Localidade Rendimento Tipo_ cliente Como a ênfase da actividade bancária começou por ser centrada nas contas (e não nos clientes) não é fácil estabelecer uma lista de clientes limpa a partir das contas. A constituição da dimensão Cliente contem seguramente duplicações e diferentes nomes da mesma pessoa que seriam assumidos como clientes diferentes. É uma dimensão suja. Na maior parte dos bancos e companhias de seguros esta dimensão tem uma precisão de 80%. 101 Exemplo 3: produtos heterogéneos Factos_banco ID_conta ID_hipoteca ID_tempo ID_agência ID_produto ID_estado Saldo_primário Nºtransacções (factos contas à ordem) (factos depósitos a prazo) (factos planos poupança) (factos cartões de crédito)... Produto ID_produto Descrição Tipo Categoria (atributos contas à ordem) (atributos depósitos a prazo) (atributos planos poupança) (atributos cartões de crédito).. Este tipo de situações leva a que as tabelas de factos e da dimensão produtos tenham muitos valores nulos para cada registo. 102 Data Warehousing e OLAP 51

52 , 2004/2005 Solução para a heterogenidade numa dimensão Factos_banco ID_conta ID_hipoteca ID_tempo ID_agência ID_produto ID_estado Saldo_primário Nºtransacções Produto ID_produto Descrição Tipo Categoria Factos e dimensão nucleares referentes a todos os produtos Factos e dimensões referentes a produtos específicos Factos_Contas_ordem ID_conta ID_hipoteca ID_tempo ID_agência ID_produto_ordem ID_estado Saldo_primário Nºtransacções (factos contas à ordem) Factos_Contas_Prazo ID_conta ID_hipoteca ID_tempo ID_agência ID_produto_prazo ID_estado Saldo_primário Nºtransacções (factos contas a prazo) Produto_contas_ordem ID_produto_ordem Descrição Tipo Categoria (atributos contas à ordem) Produto_contas_prazo ID_produto_prazo Descrição Tipo Categoria (atributos contas a prazo) 103 Tabelas de factos sem factos Disciplina Aluno Tempo Factos_escola ID_disciplina ID_aluno ID_tempo ID_professor ID_sala Professor Salas A tabela de factos reduz-se ao cruzamento das chaves; A presença de um aluno numa aula de um professor, numa dada sala e num determinado dia fica assinalada pelo conjunto das chaves 104 Data Warehousing e OLAP 52

53 , 2004/2005 Tabelas de factos sem factos: exemplo Hospital Médico Diagnóstico Factos_hospital ID_hospital ID_médico ID_diagnóstico ID_doente ID_procedimento ID_tempo Doente Procedimento Tempo E muitas outras situações onde é necessário registar apenas ocorrências ou eventos. Se houver necessidade de registar outros factos então a tabela de factos já conterá atributos numéricos descrevendo esses factos. 105 Representar eventos que não aconteceram Tempo ID_data Dia Dia_da_semana Semana_do_ano Mês Trimestre Ano... Produto ID_produto Nome Tipo Marca Categoria Embalagem Descrição Factos_vendas ID_data ID_produto ID_loja ID_promo Unid_vendidas Custo_compra Valor_venda Nº_Clientes Quais os artigos em promoção que não de venderam? Como tratar o facto de as promoções poderem ser diferentes de loja para loja? Loja ID_loja Nome Localidade Distrito Área Nº_Caixas... Promoções ID_promo Número Tipo_promo Data_início Data_fim Data Warehousing e OLAP 53

54 , 2004/2005 Tabelas de cobertura Indicam, para o caso do exemplo das lojas, que artigos estão em promoção, qual a promoção, em que lojas e durante quanto tempo. Tempo Produto Promoções ID_data ID_produto ID_loja ID_promo Loja Promoções As tabelas de coberturas registam eventos: não têm factos A granularidade do tempo poderá, eventualmente, ser semanal 107 Cadeia de lojas, com cobertura de promoções Tempo Factos_vendas Loja ID_data Dia Dia_da_semana Semana_do_ano Mês Trimestre Ano... ID_data ID_produto ID_loja ID_promo Unid_vendidas Custo_compra Valor_venda Nº_Clientes ID_loja Nome Localidade Distrito Área Nº_Caixas... Produto ID_produto Nome Tipo Marca Categoria Embalagem Descrição Promoções ID_data ID_produto ID_loja ID_promo Promoções ID_promo Número Tipo_promo Data_início Data_fim Data Warehousing e OLAP 54

55 , 2004/2005 Entrevistar utilizadores Qual é o papel do seu grupo/ departamento/ divisão? Qual foi a alteração mais significativa e recente na forma como estão a fazer o vosso negócio? O que significa foco no cliente? Quantos clientes é que têm? Como é que os agrupam? O que é que os vossos competidores fazem que vocês não fazem? E querem também fazer? Como é que medem o sucesso no vosso grupo? Lucro, volume vendas, O vosso grupo precisa da informação das ordens de compra, inventários, vendas? Precisam de ver os dados ao nível do dia? Entrevistar os administradores da BD O DBA tem que levar relatórios que descrevam a BD; Como é que os vários sistemas de produção se relacionam uns com os outros? Que sistema alimenta o outro? Onde é que os dados começam a ser produzidos? Por favor, descreva por escrito cada uma das tabelas mais importantes da BD; Fazer o mesmo para cada um dos campos mais importantes dessas tabelas; Forneça o número de registos de cada uma das tabelas. Como é que são administradas as chaves das tabelas? Como é que são atribuídos os números de cliente? 110 Data Warehousing e OLAP 55

56 , 2004/2005 Nove decisões na construção de uma DW 1. Identificar processos de negócio 2. Identificar factos de cada processo (tabela de factos) 3. Definir a granularidade de cada tabela de factos 4. Identificar as dimensões para cada tabela de factos 5. Definir os atributos das dimensões 6. Estimar tamanho e confirmar granularidade 7. Decidir como resolver as alterações nas dimensões 8. Tratar iregularidades das dimensões: Dimensões heterogéneas Mini-dimensões Normalização e flocos-de-neve Relacionamentos M para N Etc 9. Decidir qual a duração histórica da DW 10. A periodicidade em que os dados das diferentes estrelas devem ser carregados. 111 Aspectos básicos relativos ao desempenho 112 Data Warehousing e OLAP 56

57 , 2004/2005 Como acelerar as respostas a queries? Bom projecto lógico dos esquemas em estrela Bom projecto físico (as coisas básicas) Infraestrutura HW + SO + SGDB correctamente administrada e afinada. Cuidados particulares com os sistemas de discos (vários discos, particionamento, RAID). Parâmetros físicos correctos para as tabelas (e todos os outros objectos). Particionar tabelas muito grandes Correcta indexação (B*Tree e Bit-map) com parametros físicos correctamente definidos. Manutenção das estatísticas do SGBD para permitir optimização das queries. Usar agregados (vistas materializadas) Usar processamento paralelo Redução de dados Alguns destes assuntos já foram aprendidos na disciplina de BD2 113 Agregados Resultados pré-calculados que são armazenados com o objectivo de acelerar a resposta a queries Exemplos (considerando a DW de cadeia de lojas): Totais relativos a categoria de produto, por loja e por dia; Totais mensais por produto e por loja; Razão entre a margem de lucro nos dias de semana e nos fins de semana para cada loja. 114 Data Warehousing e OLAP 57

58 , 2004/2005 Agregados: vantagens e problemas Vantagens: Os agregados (também conhecidos por vistas materializadas) permitem optimizar o desempenho de uma Data Warehause; São controlados pelo administrador, o que permite assegurar a sua correcção; São partilhados e estão disponíveis para diferentes utilizadores. Problemas fundamentais: Só aceleram as respostas para as perguntas previstas (i.e., previamente calculadas e armazenadas); Obrigam a atenção constante do administrador para construir novos agregados que respondam às perguntas mais frequentes feitas pelos utilizadores em cada momento e eliminar agregados que se tornaram desnecessários; Ocupamespaçoemdisco. 115 Armazenamento de agregados Um agregado é um registo (de factos) representando uma sumarização (um cálculo) de um conjunto de factos base; Um agregado está sempre associado com uma ou mais dimensões agregadas. Exemplo: Totais relativos a categoria de produto, por loja e por dia; Factos (cálculo de totais por categoria) Dimensão agregada (substitui a dimensão produto) Dimensões originais 116 Data Warehousing e OLAP 58

59 , 2004/2005 Exemplo de agregados: cadeia de lojas ID_data Produto ID_produto ID_produto ID_Loja Número ID_Promoção Nome Unid_vendidas Marca Custo_compra Categoria Subcategoria Valor_venda Departamento Nº_clientes Tempo Tam_embalagem Tipo_embalagem ID_data Promoção Tipo_dieta Dia_do_mês ID_promoção Peso Dia_da_semana Número Unidade_de_peso Dia_do_ano Nome_promo Quant_caixa Semana_do_ano Caixas_p_pallete Objectivo: criar agregados por: Tipo_red_preço Mês Tipo_anúncio Larg_prateleira Número_do_mês Tipo_cartaz Altura_prateleira Trimestre Tipo_coupons Profun_prateleira Período_fiscal Meio_anúncio... Totais por Flag_feriado distritos (dimensão Meio_cartaz loja); Flag_dia_semana Custo_promoção Flag_últ_dia_mês Totais mensais (dimensão tempo) Início_promoção Estação_ano Fim_promoção Aconteci_espec.... Totais por categoria (dimensão produtos); Loja Quantas tabelas de factos agregados são necessárias? ID_loja Nome Número_loja Endereço Localidade Código_postal Distrito Região Telefone Fax Gestor_loja Área_total Área_mercearias Área_congelados Área_bazar Nº_Caixas Data_inauguração Data_ult_remod Agregados na cadeia de lojas: tabelas de factos São necessárias tantas tabelas de factos agregados quantas combinações de dimensões agregadas 1 - Totais por categoria, por loja, por dia 2 - Totais por distrito, por produto, por dia 3 - Totais por mês, por produto, por loja 4 - Totais por categoria, por totais de distrito, por dia 5 - Totais por categoria, por totais mensais, por loja 6 - Totais por distrito, por totais mensais, por produto 7 - Totais por categoria, por totais mensais, por totais por distrito 118 Data Warehousing e OLAP 59

60 , 2004/2005 Aspecto final: factos e agregados Estrela base: tabela de factos + 4 dimensões 3 dimensões agregadas Categoria; Distritos; Meses. 7 tabelas de factos agregados Totais por categoria, por loja, por dia Totais por distrito, por produto, por dia Totais por mês, por produto, por loja Totais por categoria, por totais de distrito, por dia Totais por categoria, por totais mensais, por loja Totais por distrito, por totais mensais, por produto Totais por categoria, por totais mensais, por distrito Estas tabelas não são visíveis para o utilizador final. 119 Nº de tabelas de agregados: outro exemplo Objectivo - criar agregados por: Produto: totais por categoria, totais por todos os produtos Loja: totais por distritos, totais por divisão, totais por todas as lojas Tempo: totais mensais, totais anuais Quantas dimensões agregadas? 7 Dimensões agregadas. Quantas tabelas de factos agregados? 35 tabelas de factos agregadas. 120 Data Warehousing e OLAP 60

61 , 2004/2005 Quantos agregados são necessários? O administrador decide criar ou eliminar agregados, de acordo com as queries mais frequentes; Na definição das dimensões agregadas pode decidir-se evitar a criação de certos agregados Tabela de factos de agregados por categoria Dimensão categoria (agregada) Dimensão Tempo Dimensão Loja Dimensão Promoções ID_data ID_categoria ID_Loja ID_Promoção Unid_vendidas Custo_compra Valor_venda Nº_clientes ID_categoria Categoria Departamento Em vez de criar um agregado separado para departamento é usado o agregado por categorias para acelerar a resposta 121 Técnicas para armazenamento de agregados 1) Armazenados em novas tabelas de factos e dimensões agregadas (o método usado normalmente) 2) Atributos de nível: os agregados são armazenados na tabela de factos base, com a introdução de atributos de nível nas dimensões. 122 Data Warehousing e OLAP 61

62 , 2004/2005 Método dos atributos de nível Os agregados são armazenados na mesma tabela dos factos base; As dimensões a agregar são aumentadas para conter um atributo de nível: O atributo de nível indica o nível de agregação de cada registo na tabela da dimensão: Os registos originais têm Nível = Base; Os agregados por categoria têm Nível = Categoria; etc 123 Exemplo: método dos atributos de nível Registo originais: Factos de vendas ID_data ID_produto ID_Loja ID_Promoção Unid_vendidas Custo_compra Valor_venda Nº_clientes Nivel = Base Todos os atributos preenchidos com valores originais Registos correspondentes ao agregado por Categoria Nivel = Categoria Todos os atributos preenchidos com Não Disponível Dimensão produto aumentada ID_produto Nivel Número Nome Marca Categoria Subcategoria Departamento Tam_embalagem Tipo_embalagem Tipo_dieta Peso Unidade_de_peso Quant_caixa Caixas_p_pallete Larg_prateleira Altura_prateleira Profun_prateleira Data Warehousing e OLAP 62

63 , 2004/2005 Contagem dupla Contagem dupla: Factos de vendas ID_data ID_produto ID_Loja ID_Promoção Unid_vendidas Custo_compra Valor_venda Nº_clientes Se uma query restringir apenas Categoria = Bebida serão incluído os registos base e os registos da Nível = Categoria para o caso em que Categoria = Bebida As queries têm de restringir sempre o atributo Nível Dimensão produto aumentada ID_produto Nivel Número Nome Marca Categoria Subcategoria Departamento Tam_embalagem Tipo_embalagem Tipo_dieta Peso Unidade_de_peso Quant_caixa Caixas_p_pallete Larg_prateleira Altura_prateleira Profun_prateleira Comparação dos dois métodos O número de registo criados pelos agregados é o mesmo em qualquer dos métodos; Tabelas separadas: As tabelas correspondentes ao agregados não são visíveis para o utilizador final. Normalmente existe uma camada de software (agregate navigator) que optimiza a utilização dos agregados para cada query; Agregados em tabelas separadas podem ser facilmente criados, apagados, carregados e indexados; Atributos de nível Poder conduzir a contagens duplas; Para os registos correspondentes aos agregados todos os restantes atributos das dimensões estão preenchidos com não disponível ; Difícil de gerir quando há muitos níveis. 126 Data Warehousing e OLAP 63

64 , 2004/2005 Agregados e esparsidão Os agredados são muito menos esparsos do que os dados base; O espaço necessário para o seu armazenamento é um problema sério; O administrador deve gerir cuidadosamente os agregados. 127 Vistas materializadas (Oracle) CREATE MATERIALIZED VIEW sales_summary BUILD IMMEDIATE REFRESH COMPLETE ON DEMAND ENABLE QUERY REWRITE AS SELECT i.ord_ord_id AS order_id, MAX(TO_CHAR(orderdate,'MonthYYYY')) AS orderdate, SUM(i.quantity * p.unitprice) AS total FROM orders o, items i, parts p WHERE o.ord_id = i.ord_ord_id AND p.part_id = i.part_part_id GROUP BY i.ord_ord_id; 128 Data Warehousing e OLAP 64

65 , 2004/2005 Vistas materializadas (cont.) (Oracle) Refrescar as estatísticas do optimizador BEGIN dbms_utility.analyze_schema('sales_app','estimate',15); END; Refrescar as vistas materializadas BEGIN dbms_mview.refresh('sales_app.sales_summary', 'A'); END; Ver artigo Using Materialized Views to Speed Up Queries by Steve Bobrowski em September/October Índices em Data Warehousing 130 Data Warehousing e OLAP 65

66 , 2004/2005 Índices em DW Índices B-Tree (já estudados) Atributos de elevada cardinalidade Índices Bit-map Atributos de baixa cardinalidade 131 Estrutura de um índices B-Tree: breve revisão Martins Ventura Bento Justino Matos Tavares Álvares ROWID Bento ROWID Justino ROWID Martins ROWID Matos ROWID Tavares ROWID Antunes ROWID Canelas ROWID Lemos ROWID Soares ROWID Teixeira ROWID Ferreira ROWID Os índices são armazenados como B*-trees B*-Tree é uma B + -Tree com uma política de ocupação média de blocos diferente de 50%. Rever as seguintes estruturas de dados: árvores equlibradas AVL, B-Trees e B + -Trees 132 Data Warehousing e OLAP 66

67 , 2004/2005 Como funciona um índice B-Tree Martins Bento Justino Matos Tavares Álvares ROWID Antunes ROWID Bento ROWID Canelas ROWID Ferreira ROWID Justino Lemos ROWID ROWID Martins ROWID Matos ROWID Soares ROWID Tavares ROWID Teixeira ROWID SELECT * FROM Empregados Where nome = Lemos ; O sistema começa por usar o índice para determinar o ROWID do registo pretendido Depois usa o ROWID para encontrar o registo 133 Porque é que os índices B-Tree são insuficientes? Produto ID_produto Número Nome Marca Categoria Subcategoria Departamento Tipo_embalagem Tipo_dieta Peso Unidade_de_peso Quant_caixa Caixas_p_pallete Larg_prateleira Altura_prateleira Profun_pratelei... Tempo ID_data Dia_do_mês Dia_da_semana Dia_do_ano Semana_do_ano Mês Número_do_mês Trimestre Período_fiscal Flag_feriado Flag_dia_semana Flag_últ_dia_mês Estação_ano Aconteci_espec. Atenção às cardinalidades!!! ID_produto ID_data ID_Loja ID_Promoção Unid_vendidas Custo_compra Valor_venda Nº_clientes Promoção ID_promoção Número Nome_promo Tipo_red_preço Tipo_anúncio Tipo_cartaz Tipo_coupons Meio_anúncio Meio_cartaz Custo_promoção Início_promoção Fim_promoção... Loja ID_loja Nome Número_loja Endereço Localidade Código_postal Distrito Região Telefone Gestor_loja Área_total Área_mercearias Área_congelados Área_bazar Nº_Caixas Data_inauguração Data_ult_remod Data Warehousing e OLAP 67

68 , 2004/2005 Índices Bit-map Cliente ID_Cliente Sexo Distrito Estado_civil Rendimento M Coimbra Casado A M Faro Solteiro B F Guarda Casado A M Faro Solteiro C F Beja Solteiro A Índice B-tree Possíveis colunas para índices Bit-map 135 Exemplos de índices Bit-map Índices para Sexo e para Rendimento. Outros atributos da tabela Cliente tais como Distrito e Estado_cívil também poderiam ter índices bit-map. Sexo = M Sexo = F Rendimento = A Rendimento = B Rendimento = C Data Warehousing e OLAP 68

69 , 2004/2005 Execução de queries usando índices Bit-map Sexo = M Rendimento = A Rendimento = B AND 1 OR SELECT COUNT(*) FROM Cliente WHERE Sexo = M' AND Rendimento IN ( A', B'); 137 Como indexar um esquema em estrela? Produto ID_produto Número Nome Marca Categoria Subcategoria Departamento Tam_embalagem Tipo_embalagem Tipo_dieta Peso Unidade_de_peso Quant_caixa Caixas_p_pallete Larg_prateleira Altura_prateleira Profun_prateleira... Tempo ID_data Dia_do_mês Dia_da_semana Dia_do_ano Semana_do_ano Mês Número_do_mês Trimestre Período_fiscal Flag_feriado Flag_dia_semana Flag_últ_dia_mês Estação_ano Aconteci_espec. ID_produto ID_data ID_Loja ID_Promoção Unid_vendidas Custo_compra Valor_venda Nº_clientes Promoção ID_promoção Número Nome_promo Tipo_red_preço Tipo_anúncio Tipo_cartaz Tipo_coupons Meio_anúncio Meio_cartaz Custo_promoção Início_promoção Fim_promoção... Loja ID_loja Nome Número_loja Endereço Localidade Código_postal Distrito Região Telefone Fax Gestor_loja Área_total Área_mercearias Área_congelados Área_bazar Nº_Caixas Data_inauguração Data_ult_remod Data Warehousing e OLAP 69

70 , 2004/2005 Planos de execução de queries e métodos de acesso específicos para Data Warehousing 139 Execução de queries Planos de execução de queries Sequência de passos físicos necessários para executar uma querie, incluindo encontrar fisicamente os dados necessários e prepará-los de modo a poder devolver os resultados ao utilizador. Query Parser Optimizador Execução Query parsed Plano de execução Resultados 140 Data Warehousing e OLAP 70

71 , 2004/2005 Optimizador de queries Para definir os planos o optimizador considera muitas coisas: Aspectos específicos da sintaxe da querie Tabelas que têm de ser acedidas e suas características físicas Existência de estruturas auxiliares tais como índices e vistas materializadas Modo seleccionado para o optimizador (baseado em regras ou custos) Estado das caches Sugestões explicitas do utilizador (hints) Etc, etc 141 Planos de execução de queries Duas grandes abordagens para definir planos - Baseado em regras - Baseado em estimativas de custos a partir de estatísticas Actualmente os planos baseados em estimativas de custos são os mais usados. 142 Data Warehousing e OLAP 71

72 , 2004/2005 Planos baseados em regras O optimizador de queries define o plano baseado em: - Conjunto prédefinido de regras de precedência (regras de ouro) - Estas regras são: - Fixas - Predeterminadas - Estão ordenadas (da melhor para a menos boa) - Não dependem de aspectos relativos aos dados tais como volumes das tabelas, distribuição dos índices, etc - As regras indicam ao optimizador que tipo de acesso a uma dada tabela deve fazer, como deve executar um join, se deve usar um índice ou não, etc - O Oracle tem um conjunto primário de cerca de 20 regras. 143 Planos baseados em custos O optimizador faz o seguinte: 1. Gera vários planos alternativos. 2. Estima os custos para cada plano baseados nos recursos necessários para executar o plano (I/O, CPU, memória,...). 3. Compara os custos de cada plano possível e escolhe o que tem menor custo. 144 Data Warehousing e OLAP 72

73 , 2004/2005 Planos baseados em custos (diagrama) Parser Query Query parsed Optimizador Gerador de planos Execução Estimador de custos Avaliador de planos Plano de execução Resultados Gestor de catálogo 145 Ojectivos e meios dos planos baseados em custos Objectivos: Normalmente os custos são calculados para optimização da execução do maior número de queries por unidade de tempo (throughput) Pode-se também establecer como objectivo a minimização do tempo de resposta (importante para DW) ou da utilização dos recursos. Meios Estatísticas sobre os objectos e os dados (clusters, tabelas, índices,..). O comando ANALIZE é o principal método para recolher as estatísticas. Sugestões do utilizador (hints) Data Warehousing e OLAP 73

74 , 2004/2005 Planos baseados em custos e DW Não há actualizações, pelo que a manutenção das estatísticas é pequena. A actualização das estatísticas pode ser feita a seguir aos carregamentos periódicos. Queries muito complexas, pelo que a análise de custos permite grandes optimizações. 147 Métodos de acesso aos dados Todos os dados estão em tabelas. Não é difícil encontrar os dados numa base de dados; o problema é fazê-lo da maneira mais eficaz. Os planos de execução de queries usam muitos métodos de acesso aos dados que é necessário entender (alguns são novos para DW): Full table scan Por ROWID (através de índices B*-Tree ou bit-map) Join indexes Hash indexes Diferentes tipos de junções Etc. 148 Data Warehousing e OLAP 74

75 , 2004/2005 Métodos de junções para DW Starjoin Star join em Oracle Oracle star transformation 149 Star Join Tem de existir um bit-map join index (semelhante a um bit-map) entre a tabela de factos e cada uma das dimensões. A query é executada começando pelas dimensões e encontrando as suas entradas nos join indexes. São processados todos os bit-map join indexes para encontrar as linhas da tabela de factos que são necessárias (e só essas). Dim 1 Dim Dim 4 8 factos PKs ji ji factos factos PKs ji ji factos PKs 5 4 Dim 3 Conjunto temporário de chaves para factos 150 Data Warehousing e OLAP 75

76 , 2004/2005 Star Join em Oracle (Oracle star query) O Oracle não tem join index pelo que o método é realizado fazendo o produto cartesiano entre as linhas seleccionas de cada dimensão. Pode ser muito menos eficiente do que o star join original porque os produtos cartesinos podem conter muitas linhas. Dim 1 Dim Dim 4 6 linhas de Dim 1 8 producto cartesiano 7 linhas de Dim 4 3 factos producto cartesiano linhas de Dim 2 producto cartesiano 5 linhas de Dim 3 Dim 3 Inclui conjunto temporário de chaves para factos Oracle star transformation Destina-se a resolver os casos em que no Oracle star query os produto cartesianos dos registos selecionados nas dimensões são muito grandes. Requer um índice bit-map em cada uma das colunas de chave estrangeira na tabela de factos. Estes índices são combinados de modo a encontrar os registos pretendidos na tabela de factos (o que é muito semelhante ao star join original). 152 Data Warehousing e OLAP 76

77 , 2004/2005 Oracle start transformation: execução de queries Este método obriga à reescrita das queries. Por exemplo: SELECT f.* FROM factos f, dim1 d1, dim2 d2, dim3 d3, dim4 d4 WHERE f.fk1 = d1.pk /* junção */ AND f.fk2 = d2.pk /* junção */ AND f.fk3 = d3.pk /* junção */ AND f.fk4 = d4.pk /* junção */ AND d1.atr1 = 'aaa' /* restrição */ AND d2.atr2 = 'ccc' /* restrição */ AND d3.atr3 = 'eee' /* restrição */ AND d4.atr4 = 'ggg'; /* restrição */ é transformada em SELECT f.* FROM factos f WHERE f.fk1 IN (SELECT pk FROM dim1 WHERE atr1 = 'aaa') AND f.fk2 IN (SELECT pk FROM dim2 WHERE atr2 = 'ccc') AND f.fk3 IN (SELECT pk FROM dim3 WHERE atr3 = 'eee') AND f.fk4 IN (SELECT pk FROM dim4 WHERE atr4 = 'ggg'); 153 Particionamento 154 Data Warehousing e OLAP 77

78 , 2004/2005 Particionamento de tabelas e índices Decompõe as tabelas é bocados mais pequenos chamados partições Muito útil para gerir tabelas (e índices) muito grandes Uma vez definidas, os comandos SQL podem manipular as partições em vez da tabela inteira. O particionamento é particularmente útil quando as partições ficam em discos diferentes (no Oracle criando vários tablespaces tendo cada um ficheiros em discos diferentes) Transparência nas partições: o SGBD decide que partições são usadas na resposta a uma query. 155 Particionamento de tabelas e de índices (cont.) Em quase todos os SGBD o particionamento de tabelas e índices pode-se combinar livremente. Exemplos: Tabela particionada com índices não particionados; Tabela particionada com índices particionados; Tabela particionada com parte dos índices particionados e com outros não particionados; Tabela não particionada com índices particionados (todos ou parte). 156 Data Warehousing e OLAP 78

79 , 2004/2005 Vantagens e desvantages do particionamento Vantagens: Acessos mais rápidos (menos dados) Pode-se conter o impacto de falhas (backup e recuperação independente para cada partição) Muito melhor gestão dos discos. Desvantagens: Complica ainda mais a administração; A sua eficácia depende muito de como são decididas as partições e de como as queries acedem aos dados. 157 Particionamento horizontal e vertical Horizontal: Cada partição contém parte dos registos da tabela A estrutura é a mesma em todas as partições (mas o projecto físico pode ser diferente). Conhecido vulgarmente por range partitioning mas inclui na verdade vários métodos de particionamento. É de longe o tipo de particionamento mais utilizado. Vertical: Cada partição tem parte das colunas da tabela A estrutura é diferente de partição para partição. 158 Data Warehousing e OLAP 79

80 , 2004/2005 Chave de particionamento (horizontal) Cada registo numa tabela particionada tem de ser associado a uma (e só uma) partição. Chave de particionamento: atributo ou atributos de uma tabela particionada que permitem associar de forma não ambígua cada registo a uma dada partição. A chave de particionamento é usada nas operações de Insert, Update, Delete e Select para encontrar a partição para cada registo. 159 Métodos de particionamento horizontal Particionamento por gama de valores (range partitioning) Particionamento por lista explícita (list partitioning) Particionamento uniforme por chave (hash partitioning) Sub-particionamento (composite partitioning) Range-hash partitioning Range-list partitioning 160 Data Warehousing e OLAP 80

81 , 2004/2005 Particionamento por gama de valores (range partitioning) As partições são criadas de acordo com gamas de valores especificadas para um dado atributo (ou conjunto de atributos). Pressupõe que os valores do atributo usado para particionamento forma um conjunto ordenado. Muito útil quando os dados se distribuem naturalmente em gamas de valores (e.g., meses do ano, faixas etárias, etc). Os melhores resultados (em performance) quando: O tamanho das partições resulta razoavelmente uniforme As queries coincidem com a lógica do particionamento, levando a que os acessos sejam feitos a um pequeno conjunto de partições. Assume que a distribuição dos dados nos atributos usados para o particionamento é conhecida no momento em que se cria a tabela 161 Exemplo de range partitioning (Oracle) CREATE TABLE sales_range (salesman_id NUMBER(5), salesman_name VARCHAR2(30), sales_amount NUMBER(10), sales_date DATE) PARTITION BY RANGE (sales_date) ( Método de particionamento PARTITION sales_jan2000 VALUES LESS THAN(TO_DATE('02/01/2000','DD/MM/YYYY')), PARTITION sales_feb2000 VALUES LESS THAN(TO_DATE('03/01/2000','DD/MM/YYYY')), PARTITION sales_mar2000 VALUES LESS THAN(TO_DATE('04/01/2000','DD/MM/YYYY')), PARTITION sales_apr2000 VALUES LESS THAN(TO_DATE('05/01/2000','DD/MM/YYYY')) ); Definição das fronteiras que definem cada partição A tabela é criada em quantas partições? Em que tablespaces são criadas as partições? Atributo de particionamento 162 Data Warehousing e OLAP 81

82 , 2004/2005 Exemplo de range partitioning com vários atributos (Oracle) CREATE TABLE sales ( invoice_no NUMBER, Múltiplos atributos de sale_year INT NOT NULL, particionamento sale_month INT NOT NULL, sale_day INT NOT NULL ) PARTITION BY RANGE (sale_year, sale_month, sale_day) ( PARTITION sales_q1 VALUES LESS THAN (1999, 04, 01) TABLESPACE tsa, PARTITION sales_q2 VALUES LESS THAN (1999, 07, 01) TABLESPACE tsb, PARTITION sales_q3 VALUES LESS THAN (1999, 10, 01) TABLESPACE tsc, PARTITION sales_q4 VALUES LESS THAN (2000, 01, 01) TABLESPACE tsd ); Indicação explícita do tablespace onde fica a partição 163 Particionamento por lista explícita (list partitioning) As partições são criadas de acordo com uma lista de valores (de um dado atributo) explicitamente especificada. Muito útil quando os dados não formam conjuntos ordenados nem tem relação entre si (as partições são indicadas explicitamente). Só se pode usar um atributo para definir a lista (Oracle) Os bons (ou menos bons) resultados no que toca à distribuição uniforme dos dados pelas partições e à relação entre as partições e as queries depende da lista de valores especificada Assume que se conhece previamente os valores exactos dos dados do atributos usado para o particionamento 164 Data Warehousing e OLAP 82

83 , 2004/2005 Exemplo de list partitioning (Oracle) Método de CREATE TABLE sales_list particionamento (salesman_id NUMBER(5), salesman_name VARCHAR2(30), sales_state VARCHAR2(20), Atributo de particionamento sales_amount NUMBER(10), sales_date DATE) PARTITION BY LIST(sales_state) ( PARTITION sales_west VALUES('California', 'Hawaii'), PARTITION sales_east VALUES ('New York', 'Virginia', 'Florida'), PARTITION sales_central VALUES('Texas', 'Illinois') PARTITION sales_other VALUES(DEFAULT) ); Partição por defeito para quando os dados não correspondem a nenhum dos valores especificados Definição explícita do valores 165 Particionamento uniforme (hash partitioning) As partições são definidas através de uma função de hash, pelo que não dependem directamente dos valores dos atributos. Muito útil nas seguintes situações: Quando não se sabe à priori como os dados se vão distribuir (por isso é arriscado usar particionamento por gama ou lista); Quando se sabe como os dados se distribuem mas é difícil gerar partições regulares; Quando o particionamento por gama ou lista leva a que os dados sejam particionados de um modo não favorável face às queries mais frequentes. 166 Data Warehousing e OLAP 83

84 , 2004/2005 Exemplo de hash partitioning (Oracle) CREATE TABLE sales_hash (salesman_id NUMBER(5), salesman_name VARCHAR2(30), sales_amount NUMBER(10), week_no NUMBER(2)) PARTITION BY HASH(salesman_id) PARTITIONS 4 STORE IN (data1, data2, data3, data4); Método de particionamento Atributo a que é aplicada a função de hash Número de partições Tablespaces onde as partições ficam armazenadas 167 Sub-particionamento (Oracle) O método de particionamento base é range: Range + hash partitioning Range + list partitioning Útil quando os objectos são mesmos muito grandes. A utilização de hash ou list nas sub-partições segue a mesma lógica de quando estes métodos são usados em particionamento normal: hash para particionamento regular; list para controlar específicamente as partições. 168 Data Warehousing e OLAP 84

85 , 2004/2005 Exemplo de range-hash partitioning (Oracle) CREATE TABLE sales_composite (salesman_id NUMBER(5), salesman_name VARCHAR2(30), sales_amount NUMBER(10), sales_date DATE) PARTITION BY RANGE(sales_date) SUBPARTITION BY HASH(salesman_id) SUBPARTITION TEMPLATE( SUBPARTITION sp1 TABLESPACE data1, SUBPARTITION sp2 TABLESPACE data2, SUBPARTITION sp3 TABLESPACE data3, SUBPARTITION sp4 TABLESPACE data4) Método de particionamento primário (range) (PARTITION sales_jan2000 VALUES LESS THAN(TO_DATE('02/01/2000','DD/MM/YYYY')) PARTITION sales_feb2000 VALUES LESS THAN(TO_DATE('03/01/2000','DD/MM/YYYY')) PARTITION sales_mar2000 VALUES LESS THAN(TO_DATE('04/01/2000','DD/MM/YYYY')) PARTITION sales_apr2000 VALUES LESS THAN(TO_DATE('05/01/2000','DD/MM/YYYY')) PARTITION sales_may2000 VALUES LESS THAN(TO_DATE('06/01/2000','DD/MM/YYYY'))); Definição das partições primárias Chave para o particionamento primário Chave para o subparticionamento (hash) As sub-partições e respectivos tablespaces são indicados por um template 169 Exemplo de range-list partitioning (Oracle) CREATE TABLE bimonthly_regional_sales (deptno NUMBER, item_no VARCHAR2(20), txn_date DATE, txn_amount NUMBER, state VARCHAR2(2)) PARTITION BY RANGE (txn_date) SUBPARTITION BY LIST (state) SUBPARTITION TEMPLATE( SUBPARTITION east VALUES('NY', 'VA', 'FL') TABLESPACE ts1, SUBPARTITION west VALUES('CA', 'OR', 'HI') TABLESPACE ts2, SUBPARTITION central VALUES('IL', 'TX', 'MO') TABLESPACE ts3) ( PARTITION janfeb_2000 VALUES LESS THAN (TO_DATE('1-MAR-2000','DD-MON-YYYY')), PARTITION marapr_2000 VALUES LESS THAN (TO_DATE('1-MAY-2000','DD-MON-YYYY')), PARTITION mayjun_2000 VALUES LESS THAN (TO_DATE('1-JUL-2000','DD-MON-YYYY')) ); 170 Data Warehousing e OLAP 85

86 , 2004/2005 Particionamento de índices (Oracle) Global indexes: particionados independentemente das tabelas (bons resultados em bases de dados operacionais). Local indexes: o particionamento é associado às partições definidas para as tabelas (são estes os mais usados em data warehousing). 171 Discos RAID Redundant Arrays of Inexpensive Disk 172 Data Warehousing e OLAP 86

87 , 2004/2005 RAID - Redundant Arrays of Inexpensive Disk Objectivos de estudo: Entender os problemas e as limitações do sistema de discos numa base de dados; Conhecer os principais conceitos da tecnologia RAID; Saber quais os benefícios que a tecnologia RAID pode trazer; Saber quando é útil usar RAID e em que configuração (nível), dependendo do tipo de base de dados. 173 Evolução da velocidade de processadores Velocidade Tempo In Computer Architecture: A Quantitative Approach, J. Hennessy and D. Patterson, Morgan Kaufmann Publishers, Inc Data Warehousing e OLAP 87

88 , 2004/2005 Evolução dos discos (custo e velocidade) Custo MBytes Velocidade Tempo O tempo de acesso médio baixou pouco, pois há limites mecanicos à sua melhoria In Computer Architecture: A Quantitative Approach, J. Hennessy and D. Patterson, Morgan Kaufmann Publishers, Inc Requisitos do armazenamento de dados Baixo custo Grande velocidade Grande disponibilidade 176 Data Warehousing e OLAP 88

89 , 2004/2005 Alguns factos acerca dos acessos a discos O acesso às diferentes áreas do disco não é uniforme; Regras 80/20 80% dos acessos são efectuados a dados que correspondem a apenas 20% da capacidade do disco (os hot spots );. Melhorar a velocidade colocando os ficheiros que correspondem a hot spots em vários discos 177 Distribuição dos ficheiros por vários discos Bus de E/S Controlador de Disco Concentração de hot spots Melhora-se a velocidade de acesso distribuindo os ficheiros por diversos discos. Problemas É difícil, por vezes, identificar os ficheiros com mais acessos; Os ficheiros com mais acessos variam com o tempo. 178 Data Warehousing e OLAP 89

90 , 2004/2005 Consequências de ter vários discos Melhora (potencialmente) a velocidade; Aumenta a capacidade a custos reduzidos; mas O tempo médio entre falhas (MTBF) reduz-se É necessário tolerar as falhas nos discos Notar que os discos já são, por inerência, a parte de um computador mais susceptível de falhas 179 Controlador do disco O controlador tem um papel muito importante na disponibilidade na fiabilidade e na velocidade. Bus de E/S Bus de E/S Controlador de Disco Ponto único de falha Contr. Disco Contr. Disco Contr. Disco 180 Data Warehousing e OLAP 90

91 , 2004/2005 Conceito de Striping Os dados são fragmentados em porções (chunks) e distribuídos por diversos discos; O conjunto de discos é visto pelo utilizador como um único disco lógico. A D G A B C D E F B E Disco 1 Disco 2 Disco 3 H G C F I Velocidade do acesso (bytes/seg) = vel. de acesso de 1 disco * N N discos 181 Consequências da utilização de striping Melhora a velocidade de acesso a disco, mas A probabilidade de falha num dos discos aumenta proporcionalmente ao número de discos; Uma falha num disco leva à perda de dados em todo o conjunto. 182 Data Warehousing e OLAP 91

92 , 2004/2005 Atributos de um RAID Conjunto de discos físicos vistos pelo utilizador como um único disco lógico; Os dados são distribuídos pelos diferentes discos físicos de um modo bem definido; Uma parte da capacidade dos discos é usada para armazenar informação redundante de modo a poder recuperar os dados mesmo quando um disco avaria completamente. 183 Tipos (níveis) de RAID A proposta original de RAID apresentava 5 alterantivas para a utilização de arrays de discos, designadas por níveis: RAID 1 a RAID5; Foram, posteriormente, acrescentados dois níveis: RAID 0 Baixo custo e RAID 6; Cada nível de RAID corresponde a um diferente compromisso do triângulo Grande velocidade Grande disponibilidade Os principais conceitos de RAID foram definidos num artigo muito famoso chamado A Case for Redundant Arrays of Inexpensive Disk (RAID) de D. Patterson et. Al., Data Warehousing e OLAP 92

93 , 2004/2005 RAID 0 - striping sem redundância Do ponto de vista do utilizador corresponde a um único disco Velocidade Disponibilidade A B C D E F G Custo E I F J G L A B C Disco 1 Disco 2 Disco 3 H M D Disco 4 Pode ter um número de discos qualquer 185 Tamanho escolhido para striping A escolha do tamanho das porções usadas para striping (chunks) é muito importante para a velocidade de acesso Grande Pequeno comparando com o tamanho médio de dados trocados em cada acesso 186 Data Warehousing e OLAP 93

94 , 2004/2005 Chunks grandes A B C D E F G A maior parte dos acesso reduzem-se a um único chunk. A E I B F Disco 1 Disco 2 Disco 3 J C G L Chunk grandes são bons para: acesso muito frequentes; pequena quantidade de dados trocada em cada acesso. D H M Disco 4 Os outros discos estão livres para ser acedidos 187 Chunks pequenos A E I A B C D E F B F Disco 1 Disco 2 Disco 3 J Chunk pequenos são bons para: acesso pouco frequentes; G C G L grande quantidade de dados trocada em cada acesso. D H M Disco 4 Os acessos espalham-se pelos diversos discos em paralelo, pelo que a velocidade de acesso é multiplicada pelo número de discos. Mas só é possível um acesso de cada vez. Bases de Dados com transações longas 188 Data Warehousing e OLAP 94

95 , 2004/2005 RAID 1 - Discos duplicados Primeira (e óbvia) abordagem para tolerar falhas em discos Do ponto de vista do utilizador corresponde a um único disco Velocidade Disponibilidade A B C D E F G B C B C A A Disco 1 Disco 2 Custo Cada disco contém uma cópia do outro. As leituras podem ser aceleradas lendo metade dos dados de cada disco. 189 RAID 1 - Discos duplicados com striping A B C D E F G Os dados são distribuídos por dois pares de discos A C A C B D B D Disco 1 Disco 2 Disco 3 Disco 4 Usar pares de discos mais pequenos em vez de um único par de discos de grande capacidade; O striping leva a que os acessos possam ser distribuídos em paralelo pelos diversos discos; O tamanho do chunk deve ser afinado tendo em conta o tipo de acessos mais frequentes. 190 Data Warehousing e OLAP 95

96 , 2004/2005 RAID 2 - Códigos de detecção/correcção Transaposição dos mecanismos de detecção e correcção de erros usados na memória para os discos Dados Códigos de detecção/correcção (paridade, Hamming, ) Esta configuração tem mero interesse académico porque: Gastar discos extra para a detecção de erros é desnecessário visto a detecção já existir num disco normal (através de CRCs); Os códigos de correcção são pouco eficientes, no que toca a espaço em disco ocupado. 191 RAID 3 - Paridade do tipo bit-interleaved Do ponto de vista do utilizador corresponde a um único disco com grande velocidade e fiabilidade D + E + F A B C D E F G A + B + C Velocidade Disponibilidade A D G B E H Disco 1 Disco 2 Disco 3 Disco 4 C F I Custo Mas o controlador é caro O tamanho do chunk é pequeno (1 bit ou 1 byte); Os acessos são simultaneos a todos os discos para que a operação de XOR possa ser feita em tempo real e porque o chunk é pequeno. 192 Data Warehousing e OLAP 96

97 , 2004/2005 Falha de um disco num RAID 3 A falha de um disco não interrompe o funcionamento (é sempre possível ler a informação); Ao substituir o disco estragado por um novo o sistema consegue regenerar a informação que estava no disco estragado; Esta regeneração pode decorrer com os restantes discos em funcionamento normal; A falha de um segundo disco antes de ter sido regenerado o disco estragado é fatal. Este é o único factor que limita o número de disco usados para cada disco com a informação de paridade. 193 RAID 4 - Paridade do tipo bloco- entremeado Identico a RAID 3 mas com o tamanho do chunk maior (um sector, tipicamente); Melhora a velocidade de leitura nos casos em que há leituras muito frequentes mas com poucos dados a ser lidos A D de cada vez. G A B C D E F G B E H C F I A + B + C Disco 1 Disco 2 Disco 3 Disco 4 Podem decorrer várias leituras em simultâneo, pois o disco onde está a paridade não é necessário para as leituras quando não há nenhum disco avariado. A velocidade de cada leitura é mais baixa do que no RAID 3. Bom para BD com muitas transações mas cada uma de curta duração 194 Data Warehousing e OLAP 97

98 , 2004/2005 Acessos de leitura num RAID 4 Em circunstâncias normais, i.e., sem discos avariados, as leituras são feitas apenas aos sectores onde está a informação. Pode haver várias leituras em simultaneo se os acessos forem de poucos dados; 195 Acessos de escrita num RAID 4 Escritas Ler sector onde estão os dados antigos; Ler sector do disco de paridade onde está o resultados do XOR correspondente a esse sector; É calculado um novo XOR (fazendo o XOR dos novos dados com o XOR antigo) São escritos os novos dados e o novo XOR Uma escrita envolve sempre duas leitura e duas escritas Como só há um disco de paridade só pode haver uma escrita de cada vez. 196 Data Warehousing e OLAP 98

99 , 2004/2005 RAID 5 - Paridade bloco-entremeado rotativa Semelhante a RAID 4, mas com a diferença que os chunks contendo a paridade estão distribuídos pelos discos (Rotating Parity Array); Possibilita mais do que uma escrita ao mesmo tempo, pois a informação de paridade (XOR) não está concentrada num único disco; Tal como RAID 4, o tamanho dos chunks é grande (bom para acessos curtos mas muito frequentes). 197 RAID 5 Velocidade Disponibilidade Custo G + H + I D + E + F Mas o controlador é mais caro A B C D E F G A + B + C D G E I F H A B C Disco 1 Disco 2 Disco 3 Disco 4 Permite várias escritas simultâneas porque a informação de paridade está espalhada por todos os discos 198 Data Warehousing e OLAP 99

100 , 2004/2005 Falhas em RAID 5 O sistema interrompe a actividade normal; Todos os discos são lidos; O conteúdo do novo disco é reconstruído; O sistema volta a funcionar normalmente. Usando controladores sofisticados é possível fazer a recuperação mantendo o sistema a funcionar. 199 RAID 6 - Redundância dupla São necessários dois discos extra para guardar a paridade A paridade dos mesmos dados é guardada segundo dois códigos diferentes (P e Q) Pode recuperar de falhas em dois discos. A B C D E F G Velocidade C F E D A B Disco 1 Disco 2 Disco 3 Disco 4 P(C,D) Q(C,D) P(A,B) Disponibilidade Custo Q(A,B) 200 Data Warehousing e OLAP 100

101 , 2004/2005 Acessos em RAID 6 Semelhantes a RAID 5 com a diferença que nas escritas são sempre envolvidos três discos (três leituras e três escritas). Tal como no RAID 5 o chunk é grande, pelo que favorece acessos curtos mas muito frequentes. 201 Nível Níveis de RAID Sem redundância Discos duplicados Códigos de detecção/correcção Paridade do tipo bit-entremeado Paridade do tipo bloco-entremeado Paridade bloco-entremeado rotativa Redundância dupla 202 Data Warehousing e OLAP 101

102 , 2004/2005 Área de Estágio: Extracção, Transformação e Transporte (ETT) 203 Qual a estratégia para ETT? BDs operacionais Sistemas legados Tempo Clientes Folhas de cálculo, ficheiros,... Fontes externas Área de estágio Produtos Factos vendas Promoções Lojas 204 Data Warehousing e OLAP 102

103 , 2004/2005 Passos no processo de ETT I. Planificação 1. Definir um plano geral (do tipo end-to-end) 2. Definir infraestrutura para a área de estágio 3. Escolher as ferramentas ETT 4. Fazer plano detalhado analisando todos os problemas que é necessário resolver para carregar cada tabela destino (e.g., fontes, transformações, etc) II. III. IV. Carregamento de dimensões 1. Fazer, testar e executar planos ETT para as dimensões estáticas e simples. Permite testar toda a infraestrutura. 2. Fazer, testar e executar planos ETT para as dimensões que mudam. 3. Tratar todos os restantes casos (dimensões geradas, com dados manuais, etc) Carregamento de factos 1. Fazer, testar e executar planos ETT para tabelas de factos 2. Fazer e testar processo de carregamentos periódicos Automatizar o processo ao máximo 205 Exemplo: ETT numa DW de cadeias de lojas Produto ID_produto Número Nome Marca Categoria Subcategoria Departamento Tam_embalagem Tipo_embalagem Tipo_dieta Peso Unidade_de_peso Quant_caixa Caixas_p_pallete Larg_prateleira Altura_prateleira Profun_prateleira... Tempo ID_data Dia_do_mês Dia_da_semana Dia_do_ano Semana_do_ano Mês Número_do_mês Trimestre Período_fiscal Flag_feriado Flag_dia_semana Flag_últ_dia_mês Estação_ano Aconteci_espec. ID_produto ID_data ID_Loja ID_Cliente ID_Promoção Num_produtos Num_items Custo_compra Valor_venda Promoção ID_promoção Número Nome_promo Tipo_red_preço Tipo_anúncio Tipo_cartaz Tipo_coupons Meio_anúncio Meio_cartaz Custo_promoção Início_promoção Fim_promoção... Clientes ID_Cliente Número_cartão Nome Endereço Localidade Código_postal Distrito Região Telefone (outros atributos demográficos)... Loja ID_loja Nome Número_loja Endereço Localidade Código_postal Distrito Região Telefone Fax Gestor_loja Área_total Área_mercearias Área_congelados Área_bazar Nº_Caixas Data_inaug Data_ult_remod Data Warehousing e OLAP 103

104 , 2004/2005 Fontes Plano geral: ideia básica BDs operacionais Sistemas legados Folhas de cálculo, ficheiros,... Outras fontes DB existências Processa 50K vendas por dia 40% clientes desconhecidos etc Destinos Factos vendas Muda muito lentamente Cerca de 100K ~0,01% muda diariamente DB corporação Muda lentamente 700K clientes ~0,1% mudam diariamente em atributos demográficos Testar e conciliar clientes em sistemas antigos ~100 promoções ano Vários ficheiros Excel Ficheiro em máquinas diferentes Máquinas de utilização pessoal Ficheiros de texto com características das lojas. Precisam limpeza manual. Produtos Clientes Promoções Lojas Introdução manual de dados Gerada sinteticamente por ferramenta/ programa Tempo 207 Definir infraestrutura para a área de estágio De uma simples conta no servidor onde vai ficar a DW a máquinas dedicadas de grandes capacidade. A decisão depende do volume de dados envolvidos e da complexidade das operações a fazer nos dados antes de os carregar na DW. Tipicamente, para cada dimensão e tabela de facto, prepara-se tudo na área de estágio para depois fazer um carregamento directo. A área de estágio deve ter em conta que carregamentos parciais são frequentes para factos e dimensões muito grandes. 208 Data Warehousing e OLAP 104

105 , 2004/2005 Carregamentos iniciais Feitos directamente da área de estágio para as tabelas da DW (depois dos dados preparados) Alguns cuidados: Desligar (ou configurar para para mínimo impacto na performance) sistemas de logging. Ordenar previamente os dados a carregar pela chave primária Fazer, eventualmente, algumas agregações básicas durante o load. Gestão de índices: Drop + reindex se inserir mais do que 10% a 15% dos registos Manter os índices. Neste caso é preciso ter em atenção se as estruturas físicas dos índices estão preparadas para o crescimento. 209 Carregamentos incrementais Definir estratégia para identificar novos dados nos sistemas fonte: Novas transacções Actualizações a dados de transacções anteriores Identificar: 1. Registos novos a introduzir em cada dimensão 2. Actualizações de atributos de dimensões e como estas vão ser tratadas 3. Novos factos 210 Data Warehousing e OLAP 105

106 , 2004/2005 Identificação de novos dados nos sistemas fonte Usar o sistema de logs existente no sistema fonte Usar características das aplicações dos sistemas fontes: Utilização de timestamps; Regras usadas para a atribuição de chaves Atributos de certas tabelas que determinam momentos no tempo com precisão. Etc. Se possível, construir um sistema de log específico para sistemas fonte (e.g., usando snapshots): Interfere com desempenho do sistema fonte. Nem sempre é viável 211 Administração da DW Construir, utilizar e manter as ferramentas de extracção de dados dos sistemas operacionais; Garantir a qualidade dos dados (após cada extração); Construir e manter agregados; Vigiar e afinar o desempenho do sistema; Fazer cópias de segurança periodicamente e recuperar o estado da base de dados em caso de falha; Construir e manter templates para exploração de dados; Formar e treinar utilizadores; 212 Data Warehousing e OLAP 106

107 , 2004/2005 Ritmo típico de uma DW A DW transita periodicamente (diariamente, semanalmente, etc) entre dois estados: Exploração (16 a 22 horas por dia, no caso de um ritmo diário) Carregamento (2 a 8 horas por dia, no caso de um ritmo diário) Carregar novos dados; (Re)construir índices e outras estruturas necessárias à optimização do desempenho; Verificar qualidade dos dados; Abrir o acesso ao novos dados. 213 O Futuro das DW Optimização das estratégias de execução para as queries; Indexação das tabelas de dimensões para browsing e restrições; Acesso (e indexação) das chaves compostas da tabela de factos; Aumento do SQL de modo a suportar perguntas de negócio; Suporte de compressão de dados a baixo-nível; Suporte de processamento paralelo; Ferramentas de projecto de BD dimensionais; Ferramentas de extracção e administração de dados; End user query tools. Integração de dados mantendo-os nos sistemas fonte Webhouses. 214 Data Warehousing e OLAP 107