Digamos que um data mart processasse continuamente consultas usando as colunas PURCHASE_DATE e CUST_NUM como parte do predicado. Essas duas colunas devem ser consideradas para índices. As colunas apresentadas como parte dos resultados da consulta, mas não utilizadas como parte de um predicado, não são boas candidatas para índice. Em outras palavras, a coluna em itálico na listagem a seguir pode não ser conveniente para um índice, enquanto a que parece em negrito pode ser uma candidata ideal:
select sum(aggr_day), region, ...
from day_summary, region
where trans_date between '01-jan-2002' and '31-jan-2002' ...;
Isso nos leva à segunda diretriz de indexação importante.
DICA: As colunas que normalmente fazem parte de critérios de seleção de consulta são candidatas para índices.
Naturalmente, como essa é uma regra (na verdade, uma diretriz), existem exceções. As colunas continuamente mencionadas em um predicado, mas nas quais uma função ou operação é efetuada, não são candidatas para índices. Se uma função deve ser executada em uma coluna, o índice da coluna não é usado. Chamamos isso de supressão de índice. A listagem a seguir mostra dois exemplos de como a coluna TRANS_DATE, da listagem anterior, pode ser usada, mas que não garante um índice:
select sum(aggr_day), region, ...
from day_summary, region
where to_char(trans_date, 'Dy') in ('Mon', 'Tue') ...;
select sum(aggr_day), region, ...
from day_summary, region
where months_between (trans_date, sysdate) > 6 ...;
Existe mais uma diretriz que trata com colunas mencionadas em predicados, com e sem função. Suponha que tenhamos um exemplo de quando a coluna TRANS_DATE de DAY_SUMMARY é usada na instrução SQL:
select ...
from day_summary ...
where to_char (trans_date) ...;
Assim como na instrução SQL:
select ...
from day_summary ...
where trans_date between ...;
DICA: Uma coluna que é usada em um predicado - com e sem função executada nela - ainda pode ser candidata para um índice. Analise o número de instruções SQL que estão usando uma função e implemente um índice, caso ele otimize as instruções sem uma função.
Exclusividade do data warehouse
De certa forma, verificamos aqui que a indexação de um data warehouse ou mesmo um data mart é um ponto importante a ser observado e tratado pelos arquitetos de solução juntamente com os administradores de banco de dados e que não pode ser colocado em segundo plano. Uma ocorrência comum encontrada no projeto de sistemas operacionais/transacionais é que o banco de dados usado durante o desenvolvimento é muito diferente de seu equivalente de produção. Por exemplo, ele poderia conter apenas um pequeno subconjunto dos dados de produção ou as tabelas usadas seriam uma fração de seu tamanho de produção.
Em algumas empresa é possível encontrar tabelas muito grandes, com 30 ou 40 milhões de linhas na produção e um subconjunto de 30 ou 40 mil linhas no desenvolvimento. No ambiente de data warehouse ou data mart, devem existir dados de desenvolvimento suficientes para que decisões de indexação bem pensadas possam ser tomadas em relação a volumes de dados realistas. Sob essas condições, torna-se mais fácil avaliar a eficiência dos índices e realizar testes para ajustar os índices adicionais que poderiam ajudar no desempenho das consultas a serem realizadas. As tabelas podem ser analisadas e cálculos sobre a seletividade podem ser feitos, para decidir quais são as colunas apropriadas para indexação.
DICA: As colunas indexadas nos sistemas operacionais/transacionais não são necessariamente boas candidatas à indexação no data warehouse.
No comments:
Post a Comment