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