Skip to content

Instantly share code, notes, and snippets.

@mateusmaso
Created May 24, 2012 16:39
Show Gist options
  • Save mateusmaso/2782630 to your computer and use it in GitHub Desktop.
Save mateusmaso/2782630 to your computer and use it in GitHub Desktop.
resumo
Para se fazer um projeto físico de um banco de dados, não basta apenas obter uma estrutura de dados apropriada para armazenamento, mas sim é preciso ser estudado e para isso desenvolver de uma maneira a garantir um resultado eficiênte no final.
Conhecendo as consultas, transações e as aplicações executadas pelo banco de dados, conseguimos realizar análises de desempenho e tomar decisões de projeto físico e significativas. Fazendo uma especificação dos arquivos que serão acessados pela consulta, os atributos nas condições de seleção, junção e cujos valores sao recuperados pela consulta é possível traçar os pontos para otimização.
Além disso, para cada transação é preciso especificar os arquivos que serão atualizados, tipo de operação e aqueles atributos onde as condições de seleção de uma exclusão ou de atualização são especificadas
Não basta aplicarmos todas estas condições sem levar em conta a frequencia em que cada consulta e transação serão realizadas, uma vez que seria ineficiênte realizar para cada um estatísticas com o intuito de otimizar, sabendo que isso acabaria deixando exaustivo o processo e não traria muito retorno para a aplicação.
Outro ponto importante é a restrição de tempo nas consultas e transações, já que acaba cada uma realiza em tempos diferentes, dependendo do estado na máquina. Assim, é possível marcar prioridades e melhorar a administração do tempo no caso de consultas que demoram muito, para não criar uma fila de processos em espera.
Analisando um numero mínimo de caminhos para atualização de atributos e restrições de unicidade (para todos atributos candidatos a chave), ressalta-se a importância da criação de indices para aqueles atributos onde haverá maior acesso no caso de consulta. Desta forma não consumimos tempo e processamento desnecessário para consultas com um grande volume de dados e que são acessadas com frequencia.
Após toda essa análise, podemos realizar decisões para o projeto físico já que a maioria dos sistemas relacionais representa cada relação base como um arquivo físico no banco de dados. As opções de caminho de acesso incluem a especificação do tipo do arquivo para cada relação e dos atributos sobre quais índices devem ser definidos. No máximo um dos índices para cada arquivo pode ser um índice primário ou clustering. Podem ser criados quaisquer números de índices secundários adicionais.
O desempenho das consultas depende muito de quais índices ou esquemas de hash existem para acelerar o processamento de seleções e junções. Porém, durante as operações de inclusão, exclusão ou atualização, a existência de índices acrescenta uma sobrecarga que precisa se justificar pelo ganho em eficiência por meio da aceleração das consultas e das transações.
Após um banco de dados ser desenvolvido e estar em operação, o uso real das aplicações, das transações, das consultas e das visões revela fatores e áreas de problemas que podem não ter sido considerados durante o projeto físico inicial. Dessa forma os objetivos da sintonização seria fazer com que as aplicações sejam executadas mais rapidamente, diminuir o tempo de resposta de consultas/transações e melhorar o desempenho geral das transações.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment