Post on 27-Nov-2015
1
1
SAD – Sistemas de Apoio à Decisão
Projeto Físico DW e ETL
Profa.: Ellen Souza
UFRPE
Universidade Federal Rural de PernambucoUnidade Acadêmica de Serra Talhada
2/23
Projeto Físico do DW� Vários aspectos relacionados ao projeto físico
de BDs deverão ser considerados para garantirperformance no acesso às estruturasrelacionais ou dimensionais:� Estimativa de Tamanho do DW/DM� Criação do Data Base� Criação de Espaços e Tabelas� Criação das Tabelas� Definição de Campos Chaves e Restrições� Definição de Índices e Estruturas especiais para
acesso aos DW/DM
2
3/23
Estimativa de Tamanho� Tabelas Fatos
� Supor 5 transações de cliente dia, 15.000 clientes eperspectiva de armazenamento para 6 anos5 x 15.000 x 365 x 6 = 164.250.000 ocorrências
� Supor 7 chaves na tabela Fato, cada qual com 4bytes. Quatro métricas, cada qual com 4 bytes.Logo, cada linha da tabela Fato, ocupa 44 bytes
� Estimativa Final = 164.250.000 x 44 bytes = 7,2 GB
� Tabelas Dimensão e Índices� Média de 20 a 25% do tamanho da Fato = 1,4 GB
� Total = 7,2 GB + 1,4 GB = 8,6GB
Lembrar de Estimar as Tabelas Agregadas!!
4/23
Criação do Banco de Dados� Pontos importantes a considerar na definição
de BDs para DW/DM são:� Analisar o valor default do bloco usado pelo SGBD
para o armazenamento dos dados � Quanto maiorfor o tamanho dos blocos, maior será a capacidadede armazenamento de estruturas recuperadas numúnica operação de input/output (I/O)
� Avaliar o overhead de cada bloco, para ter idéia dovalor líquido de bytes de cada bloco, uma vez queestes deixam certo percentual de espaço reservadopara estruturas internas de controle
3
5/23
Criação de Espaços e Tabelas� As tabelas e índices que compõem um BD
habitam um espaço lógico denominado Espaçode Tabela ou Table Space. Considerações:� Dados e Índices, se possível, devem ficar em
espaços físicos separados� Avaliar a possibilidade de distribuir os dados em
unidades independentes de armazenamento com opropósito de explorar o processamento paralelooferecido por alguns SGBDs
� Adotar estratégia de particionamento para DWs:� Horizontal: Divisão de tabelas com muitos campos� Vertical: Divisão de tabelas em segmentos (range)� Data: Comum em DW/DM é a separação por Tempo
6/23
Criação das Tabelas� Algumas considerações para a criação de
tabelas para DW/DM� Atentar para o tamanho limite (em bytes) de linhas e
colunas do SGBD� Atentar para a definição default de valores nulos
para campos, evitando a sua definição (nulo) emcampos de tabela Fato
� Lembrar do conceito de Surrogate Key (chaveartificial), ou seja, campo chave sem valor semânticoespecífico
4
7/23
Definição de Campos Chaves e Restrições
� A principal definição de restrição é para aschaves primária e estrangeiras� Defina chave primária (PK) para cada tabela
Dimensão. Isso criará um índice automático� Considere a definição de restrição de chave
estrangeira (FK) de fato com a chave primária (PK)de cada dimensão. Snowflake também precisa derestrições
� Definir PK para tabela Fato, incluindo todas aschaves estrangeiras das Dimensões
� Definir índices separados para cada FK da Fato� Índices bit map, B-tree, clusterizados e etc.
8/23
Definição de Campos Chaves e Restrições
� Esquema de chaves e índices de Tabelas Dimensão e Fato
5
9/23
Opções de Armazenamento� A estratégia de armazenamento do DW/DM
permite as seguintes opções:� ROLAP: são usados os próprios SGBDs relacionais,
com as tabelas sendo implementadas com estruturasrelacionais clássicas� Oferece todas as vantagens de um SGBDR como
debug, paralelismo, otimizadores, monitoração eetc.
� Exige cuidado no projeto, onde o excesso de tabelasnormalizadas podem comprometer a performancedas buscas
� Esquema estrele e floco de neve
10/23
Opções de Armazenamento� MOLAP: são usado gerenciadores de BDs
proprietários, com características dearmazenamentos especiais e ferramentas paratratamento dimensional de dados� Dispõem de propriedades especiais de
armazenamento como matrizes, operações comarray e indexação de bitmap
� Não oferece recursos de debug, paralelismo, log,otimizadores e monitoração encontrados nosSGBDR, vista que a especialidade é para análisemultidimensional
� Tanto as estruturas básicas (maior granularidade),quanto as estruturas agregadas são armazenadasnesse formato
6
11/23
Opções de Armazenamento� HOLAP: representa uma abordagem hibrida, um
misto das estratégias ROLAP e MOLAP� As estruturas relacionais são normalmente utilizadas
para os dados de maior granularidade� As estruturas dimensionais nativas são dedicadas ao
armazenamento de agregados (menor grão)� DOLAP: representa uma abordagem entre estruturas
dimensionais ou relacionais, transferidas do DW/DMpara as estações cliente� São armazenadas com o objetivo de facilitar a
performance de certas análises, minimizando otráfego de informações entre o ambiente cliente e oambiente servidor
12/23
Opções de Armazenamento� Opções de
armazenamento/implementação de estruturas dimensionais
7
13/23
Processo de ETL� ETL, do inglês Extract Transform Load
(Extração, Transformação e Carga), é oprocesso de extrair dados de um sistema (umbanco de dados), transformá-los de algumaforma e inseri-los em outro banco de dadosespecial, o Data warehouse (DW).
� A transformação pode ser uma limpeza dosdados, alteração de acordo com regras denegócios, tradução etc.
� Em português, podemos encontrar a sigla ETCno lugar de ETL.
14/23
Processo de ETL� A aquisição de dados par o DW envolve os
seguintes passos:1. Os dados precisam ser extraídos de fontes múltiplas,
heterogêneas. Ex.: BDs, arquivos textos (flat files),mercado financeiro, dados do ambiente e etc.
2. Os dados precisam ser formatados visando àconsistência dentro do DW. Ex.: empresassubsidiárias de uma corporação podem calendáriosfiscais diferentes, com trimestres fiscais queterminam em datas diferentes, tornando difícilagregar os dados financeiros por trimestre
8
15/23
Processo de ETL� A aquisição de dados par o DW envolve os
seguintes passos:3. Os dados precisam ser limpos para assegurar a
validade. A limpeza é um processo complicado ecomplexo que tem sido identificado como ocomponente com maior exigência de trabalho naconstrução do DW. Ex.: uma mesma cidade podeaparecer com diversos nomes � Joao Pessoa, JoãoPessoa, João Pessoa – PBEsse processo é também chamado de backflushing
16/23
Processo de ETL� A aquisição de dados par o DW envolve os
seguintes passos:4. Os dados precisam ser ajustados ao modelo de
dados do DW. Os dados precisam ser convertidos demodelo OO, ER, rede, hierárquico para um modelomultidimensional. Ex.: O campo Nome da tabelaCliente, será divido em dois campo na tabelaDimensão Cliente: PrimeiroNome, ÚltimoNome; Ex.:Os dados das tabelas Produto e Fornecedor, serãoagrupados na dimensão Produto, que també contéminformação de Fornecedores
9
17/23
Processo de ETL� A aquisição de dados para o DW envolve os
seguintes passos:5. Os dados precisam ser carregados no DW. O volume
dos dados torna a carga uma tarefa significativa.� Ferramentas de monitoração de carga, bem como
métodos de recuperação de cargas incompletas ouincorretas
� Atualização Incremental x Carga Total� Quão atualizados os dados devem estar?� O DW pode ficar fora de serviço por quanto tempo?� Quais os requisitos de distribuição (replicação e
partição?� Qual o tempo de carga?
18/23
Processo de ETL� Considerações sobre a carga das Tabelas:
� Planeje cuidadosamente a carga dos DW/DM,analisando estratégias de mapeamento entre osdados fonte e o DW/DM
� Planeje o processo de transformação dos dados,atentando para a sequência dos processamentos,arquivos intermediários, tabelas de mapeamento decódigo e etc. Alguns processos de transformaçãosão:� Filtro: somente valores especificados serão
considerados
10
19/23
Processo de ETL� Considerações sobre a carga das Tabelas:
� Integração: quando o mesmo dado se origina defontes diversas
� Condensação: redução e sumarização (modificaçãode granularidade). Ex.: data (ddmmaaaa) em trêsunidades separadas: dia, mês, ano
� Conversão: tipos, formatos, unidades,obscurecimento (efeito de segurança). Ex.: 1, 2, 3para ruim, médio, bom
� Derivação: dados obtidos por cálculos no processode transformação
20/23
Processo de ETL� Considerações sobre a carga das Tabelas:
� Considere os processos de transferência entreambientes operacionais diferentes, como legado ecliente/servidor
� Considere a possibilidade de usar utilitários de cargaoferecidos pelos SGBDs ou ferramentas específicas� SQL*Loader (Oracle), BCP (SQL Server)
� Quando um certo volume de dados é atingido, ficaimpraticável a carga total. Neste momento recursospara realização de atualização incremental devemestar disponíveis
11
21/23
Processo de ETL� Considerações sobre a carga das Tabelas:
� Considere a possibilidade eliminar (drop) os índicesantes de efetuar as cargas e recriá-losposteriormente
22/23
Projeto
� Construir o projeto físico do DW para os modelos dimensionais do projeto final da disciplina
Coluna A, tamanho 4 bytes
12
23/23
� Leitura Obrigatória� Capítulo 7 - Barbieri, Carlos. BI – Business
Intelligence. Axcel Books. 2001.
� Leitura Sugerida� Capítulo 28 - Visão geral de data
warehousing e OLAP. Elmasri, R., Sistemasde Bancos de Dados. Addison Wesley, 2005.
Referências