Bancos de Dados IV. Arquiteturas. Rogério Costa

Transcrição

1 Bancos de Dados IV Arquiteturas Rogério Costa 1

2 Arquiteturas para DW DW Virtuais Fortemente Acoplada (Empresa Inteira) Fracamente Acoplada

3 Arquiteturas para DW DW Virtuais São visões (materializadas) baseadas nos dados operacionais e que fornecem apoio à tomada de decisão Rápida implementação e relativamente baixos custos Ganhos limitados

4 Arquiteturas Fortemente Acoplada Extração de todos os dados das fontes de dados, seguida das etapas de limpeza, consolidação e armazenamento em um banco de dados único, com disponibilização das informações para usuários e aplicações;

5 Arquiteturas Fortemente Acoplada Ambiente centralizado com grande controle; Separa o processamento de consultas do processamento OLTP libera recursos;

6 Arquiteturas Fortemente Acoplada Extração Limpeza Consolidação DW

7 Arquiteturas Fortemente Acoplada Robusta Maior volume de dados Grandes corporações Alto investimento na montagem e maior prazo para implantação Mudança de requisitos ao longo da implantação Dificuldade na unificação de conceitos

8 Data Mart Armazena um conjunto limitado de assuntos ex. marketing Utilizado para atender a aplicações específicas ex data mart departamental Pode ser: Independente - criado a partir das fontes de dados Dependente criado a partir do DW corporativo

9 Arquiteturas Fracamente Acoplada Baseada em Data Marts Podem existir um ou mais DM, mas não existe um DW central Diferentes grupos poderão estar extraindo e transformando informações das mesmas fontes - > possíveis diferenças em resultados e queda no desempenho

10 Arquiteturas Fracamente Acoplada Mais facilmente implementável que a arquitetura fortemente acoplada: Nível decisório departamental; Pequena abrangência funcional; Definições locais para um grupo de usuários; Ferramentas locais específicas para cada grupo sem a necessidade de atenderem a empresa inteira; Homogeneidade local;

11 Arquiteturas Fracamente Acoplada Menos complexo e com mais fácil gerenciamento; Custos mais baixos; Empresas de diferentes portes; Limitante na capacidade de troca de informações entre áreas -> ilhas de informação;

12 Arquiteturas Fracamente Acoplada Não resolve diferenças conceituais na empresa; Aumenta heterogeneidade de softwares na empresa;

13 Arquiteturas Híbrida Utiliza um data warehouse e vários data marts combinação das arquiteturas fortemente e fracamente acopladas Informações integradas no data warehouse são disponibilizadas para vários grupos de usuários em diferentes formatos, via data marts Unificação de conceitos e ganho em escala

14 Abordagens Abordagem top-down -> um DW completo pode ser desenvolvido antes que partes dele (DM) o sejam (Metodologia Inmon) Abordagem botton-up -> um DW pode ser composto a partir de data marts desenvolvidos (Metodologia Kimball)

15 Estratégia Dividir para conquistar Planejar top-down, implementar botton-up Menor tempo para obtenção de resultados Acúmulo de experiência, menor risco Dificuldade: manter a coerência entre os data marts

16 Estratégia Considerar: Gerar primeiros resultados rapidamente é importante realização em etapas Dados de produção e de fontes externas precisam ser mapeados para o modelo de dados do DW.

17 Estratégia Considerar: Alguns critérios para a escolha do SGBD de suporte Desempenho na carga e indexação dos dados, Tempo de resposta, Capacidade de armazenamento, Paralelismo, Escalabilidade. Ferramentas utilizadas devem prover: Interfaces amigáveis, Geração de relatórios, Análises multi-dimensionais, Acesso via Web e data mining.

18 Estratégia Considerar: DW deve poder ser expansível, mantendo níveis aceitáveis de desempenho até gigabytes. Tráfego Alocação Backup Restauração dos dados

19 Modelagem Multidimensional - Principais elementos Fatos a observação do que quer ser registrado. Por exemplo, um determinado valor. Dimensões o que queremos medir nos fatos, tal como produtos, fábricas, mês

20 Modelagem Multidimensional - Principais elementos Hierarquias formadas em função dos atributos das dimensões Esparcidade ausência de observação. Exemplo: para um dado produto, em uma dada fábrica, em um determinado período, podemos não ter dados

21 Modelagem Tabelas de fatos: Analogia: contém tuplas, uma para cada fato registrado interseção das dimensões; Usualmente, as maiores; O menor grão é um registro na tabela de fatos; Tabelas de dimensões: Tuplas com os atributos da dimensão; Utiliza terminologia do negócio; Dados textuais e descritivos;

22 Modelagem Esquema Estrela (star schema) Uma tabela de fatos com uma única tabela para cada dimensão As tabelas de dimensões estão desnormalizadas

23 Modelagem Esquema Estrela DIMENSION TABLE PRODUCT Prod. No. Prod. Name Prod. Descr. FACT TABLE BUSINESS RESULTS PRODUCT QUARTER REGIION DIMENSION TABLES FISCAL QUARTER QTR YEAR BEG DATE END DATE Prod. Style Fonte: Sistemas de Bancos de Dados Elmasri e Navathe Prod. Line SALES REVENUE REGION SUBREGION

24 Modelagem Constelação de fatos Conjunto de tabelas de fatos que compartilham a mesma tabela de dimensões

25 Modelagem Constelação de fatos Fonte: Sistemas de Bancos de Dados Elmasri e Navathe

26 Modelagem Esquema Snowflake (Bloco de Neve) Normalização das tabelas de dimensões Estrutura mais complexa Menor utilização de espaço

27 Esquema Flocos de Neve Modelagem DIMENSION TABLES DIMENSION TABLES PNAME PRODUCT FACT TABLE BUSINESS RESULTS Fiscal Quarter QTR YEAR FQ DATES BEG DATE END DATE Prod. Name Prod. No. PRODUCT BEG DATE Prod. Descr. Prod. Name Style QUARTER REGION Prod. Line No. REVENUE PLINE Prod. Line No. Prod. Line Name Snowflake Schema SALES REVENUE REGION SUBREGION Fonte: Sistemas de Bancos de Dados Elmasri e Navathe

28 Modelagem Escolher o X da questão, ou seja, a área mais importante Decidir o que uma estrela de fatos representa Identificar e adaptar dimensões Escolher os fatos

29 Modelagem Armazenar dados pré calculados na tabela de fatos Ajustar as tabelas de dimensões Escolher a duração do BD Rastrear as alterações nas dimensões Decidir as propriedades e modos de consulta