Bancos de Dados IV - inf.puc-rio.brrogcosta/inf1374/bd4-DW-Arquiteturas.pdf específicas – ex data...

Post on 28-Jan-2019

216 views 0 download

Transcript of Bancos de Dados IV - inf.puc-rio.brrogcosta/inf1374/bd4-DW-Arquiteturas.pdf específicas – ex data...

1

Bancos de Dados IV

Arquiteturas

Rogério Costa

rogcosta@inf.puc-rio.br

Arquiteturas para DW

� DW Virtuais

� Fortemente Acoplada (Empresa Inteira)

� Fracamente Acoplada

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

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;

Arquiteturas

� Fortemente Acoplada

� Ambiente centralizado com grande controle;

� Separa o processamento de consultas do

processamento OLTP – libera recursos;

Arquiteturas

Fortemente Acoplada

Extração

Limpeza

ConsolidaçãoDW

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

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

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

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;

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;

Arquiteturas

� Fracamente Acoplada

� Não resolve diferenças conceituais na empresa;

� Aumenta heterogeneidade de softwares na

empresa;

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

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)

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

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.

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.

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

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

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

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;

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

Modelagem

Prod. No.

Prod. Name

Prod. Descr.

Prod. Style

Prod. Line

PRODUCT

QUARTER

REGIION

QTR

YEAR

BEG DATE

END DATE

REGION

SUBREGION

DIMENSION

TABLE

PRODUCT

FACT TABLE

BUSINESS RESULTS

DIMENSION

TABLES

FISCAL QUARTER

SALES REVENUE

Esquema

Estrela

Fonte: Sistemas de Bancos de Dados –Elmasri e Navathe

Modelagem

� Constelação de fatos

� Conjunto de tabelas de fatos que compartilham a

mesma tabela de dimensões

Modelagem

Constelação

de fatos

Fonte: Sistemas de Bancos de Dados – Elmasri e Navathe

Modelagem

� Esquema Snowflake (Bloco de Neve)

� Normalização das tabelas de dimensões

� Estrutura mais complexa

� Menor utilização de espaço

ModelagemEsquema

Flocos de

Neve

Prod. Name

Prod. Descr.

Prod. No.

Prod. Name

Style

Prod. Line No.

PRODUCT

QUARTER

REGION

REVENUE

QTR

YEAR

BEG DATE

BEG DATE

END DATE

Prod. Line No.

Prod. Line Name

REGION

SUBREGION

DIMENSION TABLES

PNAME PRODUCT

FACT TABLEBUSINESS RESULTS

DIMENSION TABLES

Fiscal Quarter FQ DATES

SALES REVENUEPLINE

Snowflake Schema

Fonte: Sistemas de Bancos de Dados – Elmasri e Navathe

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

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