THAIS KATARINA DA SILVA FRANCISCO
OTIMIZAÇÃO DE CONSULTAS EM BANCO DE DADOS RELACIONAIS UTILIZANDO ÍNDICES.
Palhoça 2018
OTIMIZAÇÃO DE CONSULTAS EM BANCO DE DADOS RELACIONAIS UTILIZANDO ÍNDICES.
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistema de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistema de Informação.
Orientador: Prof. Flávio Ceci, Dr.
Palhoça 2018
OTIMIZAÇÃO DE CONSULTAS EM BANCO DE DADOS RELACIONAIS UTILIZANDO ÍNDICES.
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina.
Palhoça, 20 de novembro de 2018.
__________________________________________________ Professor e orientador Prof. Flávio Ceci, Dr.
Universidade do Sul de Santa Catarina
Dedico este trabalho à minha mãe, Jandira Maria da Silva, que me criou da melhor forma possível, com o suor de seu
trabalho, tornando-se também
Agradeço à minha mãe, Jandira Maria da Silva, pelo apoio e suporte nesses anos decorridos e por todo o seu amor dedicado.
Aos meus amigos Aquira, Jéssica e Paulo que sempre reconheceram minha aptidão em relação aos estudos, me incentivaram a buscar o crescimento acadêmico e me auxiliaram em diversas ocasiões.
Agradeço ao meu professor e orientador Flávio Ceci, por sua excelente didática, sendo um grande mestre e o responsável por aguçar meu interesse em banco de dados, por acreditar em minha competência em diversos momentos, por todas as oportunidades proporcionadas e por todas as dúvidas esclarecidas.
À professora Maria Inês, por todo seu carinho, sua atenção, dedicação e cuidado. Pelas conversas, explicações e conselhos.
À nossa orientadora do curso de Sistemas de Informação, Vera Schuhmacher, por sempre pensar nos alunos e buscar o melhor para nós.
Ao grande professor Ingo Hermann, por interceder e me apoiar em momentos decisivos.
A toda a equipe do setor de assistência social da Unisul, responsáveis por tornar o dia de hoje realidade, meu muito obrigada.
Agradeço a todos os meus professores do curso de Sistemas de Informação da Universidade do Sul de Santa Catarina, por todo o conhecimento compartilhado ao longo dessa jornada.
A todos os meus amigos, por entenderem minhas ausências, meus momentos de estresse e cansaço.
Agradeço pelas amizades que fiz, por toda a cooperação, por todas as risadas e momentos de descontração.
Em decorrência da disseminação da internet no mundo, novas tecnologias surgiram, empresas largaram o papel e passaram a utilizar softwares, o investimento na era digital cresceu e nas últimas décadas tivemos um crescimento exponencial de geração de informações digitais.
Para armazenar essas informações é utilizado um banco de dados, mas o simples armazenamento dessa grande quantidade de dados não basta, é necessário organizá-los de maneira que sejam facilmente recuperados, caso contrário o desempenho na manipulação pode afetar negativamente quem acessa.
Portanto, é necessário encontrar possibilidades que auxiliem na otimização das consultas aos bancos de dados. Este trabalho de conclusão de curso tem como objetivo buscar essas possibilidades e aplicá-los em um cenário real.
Para isso foi elaborado um comparativo em um determinado cenário. Os resultados apresentados nos testes foram convincentes e solucionaram o problema que a empresa estava enfrentando, pelo menos de maneira paliativa, e despertou possibilidades que podem ser aplicadas a fim de tornar o desempenho ainda mais satisfatório.
Figura 1 – Tabelas no banco de dados relacional ... 21
Figura 2 – Pilha ... 25
Figura 3 – Fila ... 26
Figura 4 – Lista encadeada ... 27
Figura 5 – Lista duplamente encadeada ... 27
Figura 6 – Arvore B+ ... 30
Figura 7 – Estrutura de índice de hashing ... 31
Figura 8 – Fluxograma ... 38
Figura 9 – Metodologia Scrum ... 41
Figura 10 – Farol checklist ... 46
Figura 11 – Ordens de serviços ... 47
Figura 12 – Tabela checklist... 48
Figura 13 – Tabela checklist_perguntas ... 49
Figura 14 – Tabela checklist_alternativa_pergunta ... 49
Figura 15 – Tabela checklist_respostas ... 50
Figura 16 – Tabela checklist_ordem_servico ... 50
Figura 17 – Tabela checklist_ordem_servico_itens ... 51
Figura 18 – Tabela checklist_manutencao ... 51
Figura 19 – Tabela checklist_modelo ... 52
Figura 20 – Tabela checklist_modelo_funcao ... 52
Figura 21 – Tabela checklist_modelo_veiculo_tipo ... 53
Figura 22 – Relacionamento das tabelas checklist, chscklist_modelo, checklist_perguntas, checklist_alternativa_pergunta, checklist_respostas ... 54
Figura 23 – Relacionamento das tabelas checklist_modelo, checklist_perguntas, checklist_manutencao ... 55
Figura 24 – Relacionamento das tabelas checklist, checklist_ordem_servico, checklist_ordem_servico_itens ... 56
Figura 25 – Relacionamento das tabelas checklist_modelo, checklist_modelo_funcao ... 57
Figura 26 – Relacionamento das tabelas checklist_modelo, checklist_modelo_veiculo_tipo ... 58
Figura 27 – View estratificacao_os ... 59
Figura 28 – Exclusão da view estratificacao_os ... 60
Figura 29 – Exclusão das constraints da tabela checklist_modelo... 61
Figura 30 – Remoção da primary key da tabela checklist_modelo ... 61
Figura 31 – Deleção dos checklists realizados e modelos de checklists. ... 62
Figura 32 – Criação da primary key e da constraint. ... 62
Figura 33 – Recriação das chaves estrangeiras. ... 62
Figura 34 – Criação de vínculo entre as tabelas checklist_alternativa_pergunta e a checklist_modelo. ... 62
Figura 35 – Adição de coluna provisória. ... 63
Figura 36 – Exclusão das constraints ... 63
Figura 37 – Criação de uma nova coluna ... 64
Figura 38 – Atualização da chave estrangeira que vinha da tabela checklist_perguntas na tabela checklist_respostas. ... 64
Figura 40 – Atualização da chave estrangeira que vinha da tabela checklist_perguntas
na tabela checklist_ordem_servico_itens. ... 65
Figura 41 – Exclui o código antigo tabela checklist_perguntas ... 65
Figura 42 – Recriação das primaries keys. ... 65
Figura 43 – Criação das chaves primárias e chaves estrangeiras na tabela checklist_alternativa_pergunta ... 66
Figura 44 – Criação da chave primária na tabela checklist_perguntas ... 66
Figura 45 – Criação da chaves estrangeiras na tabela checklist_alternativa_pergunta. ... 66
Figura 46 – Remoção das chaves estrangeiras. ... 67
Figura 47 – Remoção da chave primária. ... 67
Figura 48 – Criação de nova chave primária na tabela checklist_alternativa_pergunta. ... 67
Figura 49 – Remoção da constraint unique e da primary key da tabela checklist_ordem_servico_itens. ... 68
Figura 50 – Alteração das colunas ... 68
Figura 51 – População da nova coluna. ... 68
Figura 52 – Adição da constraint unique e da primary key ... 69
Figura 53 – Renomeação da coluna cod_alternativa e criação de uma nova. ... 69
Figura 54 – Migração dos códigos ... 69
Figura 55 – Restrição not null e exclusão da coluna cod_alternativo_antigo ... 70
Figura 56 – Criação da chave primária ... 70
Figura 57 – Recriação da chave estrangeira e restrição unique ... 70
Figura 58 – Deleção das colunas codigo_antigo e cod_checklist_modelo ... 70
Figura 59 – Exclusão da tabela checklist_manutencao ... 71
Figura 60 – Tabelas que não sofreram alterações estruturais ... 72
Figura 61 – Exclusão da tabela checklist_manutencao ... 73
Figura 62 – Antes e depois da tabela checklist_modelo ... 73
Figura 63 – Antes e depois da tabela checklist_perguntas. ... 74
Figura 64 – Antes e depois da tabela checklist_alternativa_pergunta ... 74
Figura 65 – Antes e depois da tabela checklist_respostas ... 75
Figura 66 – Antes e depois da tabela checklist_ ordem_servico_itens ... 75
Figura 67 – Relacionamento entre as tabelas checklist, checklist_perguntas, checklist_alternativa_pergunta, checklist_respostas e checklist_modelo ... 77
Fonte: Autoria própria. ... 77
Figura 68 – Tabelas checklist_ordem_servico e checklist_ordem_servico_itens ... 78
Figura 67 – Relação entre as tabelas checklist_modelo_veiculo_tipo de checklist_modelo ... 79
Figura 70 – Relação entre as tabelas checklist_modelo_funcao e checklist_modelo. ... 80
Figura 71 – Comparação entre o tempo de execução da function func_checklist_get_fatol_checklist ... 81
1 INTRODUÇÃO ... 12 1.1 PROBLEMÁTICA ...13 1.2 OBJETIVOS ...14 1.2.1 Objetivo Geral ...14 1.2.2 Objetivos Específicos ...14 1.3 JUSTIFICATIVA ...15 1.4 ESTRUTURA DA MONOGRAFIA ...17 2 FUNDAMENTAÇÃO TEÓRICA ... 18 2.1 BANCO DE DADOS ...18
2.1.1 Sistemas gerenciadores de banco de dados ...19
2.1.2 Banco de dados relacionais ...20
2.2 TUNING E SELF-TUNING ...22
2.2.1 Ferramentas de tuning ...22
2.3 ESTRUTURA DE DADOS ...23
2.3.1 Estruturas lineares ...24
2.3.1.1 Lista sequencial estática ... 25
2.3.1.2 Lista encadeada dinâmica ... 27
2.4 INDEXAÇÃO ...28
2.4.1 Índice baseado em árvore B ...29
2.4.1.1 Árvore B+ ... 30
2.4.2 Índice baseado em hashing ...31
3 MÉTODO ... 33
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA ...33
3.2 ABORDAGEM METODOLÓGICA ...34
3.3 DESCRIÇÃO DO OBJETO DE ESTUDO ...35
3.4 PROCEDIMENTOS TÉCNICOS ...35 3.5 ETAPAS METODOLÓGICAS ...36 3.6 DELIMITAÇÕES ...39 4 ESTUDO DO CASO ... 40 4.1 AMBIENTE ORGANIZACIONAL ...40 4.1.1 PostgreSQL ...42 4.1.2 ProLog ...43 4.1.1.1 Checklist ... 44 4.1.3 Apresentação ...48 4.2 PROPOSTA DE SOLUÇÃO ...60 4.2.1 Aplicação ...60 4.2.2 Comparativo ...71 4.2.2.1 Comparativo estrutural ... 71 4.2.2.2 Comparativo relacional ... 76 4.2.2.3 Comparativo de velocidade ... 80
5 CONCLUSÃO E TRABALHOS FUTUROS ... 83
REFERÊNCIAS ... 85
APÊNDICES ... 89
APENDICE A - CRONOGRAMA ...89
APENDICE B – DECLARAÇÃO DE CIÊNCIA E CONCORDÂNCIA DAS INSTITUIÇÕES ENVOLVIDAS NO TRABALHO DE CONCLUSÃO DE CURSO ...90
1 INTRODUÇÃO
Com o passar dos anos, a internet está cada vez mais presente no cotidiano das pessoas. O surgimento de novas tecnologias fez com que o acesso à informação fosse otimizado, ficando mais rápido e fácil. Sendo assim, nas últimas décadas, o crescimento constante de troca de dados tornou-se algo contínuo e habitual na vida das pessoas, seja no âmbito pessoal ou profissional.
Davenport e Ho-Kim (2014, p. 1) afirmam que “Dispomos de cada vez mais dados, e grande parte deles foi coletada a fim de melhorar as decisões no setor privado, no setor público e na sociedade em geral.”. Ramakrishnan e Gehrke (2008, p. 27) também, compartilham do mesmo pensamento “A quantidade de informações que nos são disponíveis está literalmente explodindo, e o valor dos dados como um ativo organizacional é amplamente reconhecido.”.
Portanto, o armazenamento e o processamento desse grande volume de dados são de grande importância para que os usuários possam extrair informações pertinentes. Puga, França e Goya (2013, p. XVIII) conceituam que “banco de dados é uma coleção de dados armazenados e organizados de modo a atender as necessidades integradas dos seus usuários”, tem como objetivo facilitar a consulta e a manipulação de informações, estando elas armazenadas de forma física ou computadorizada. Esta pesquisa aborda sistemas de bancos de dados computadorizados, que envolvem o armazenamento de informações em estruturas organizadas e implementadas em um software.
Vicci (2014, p. 3) comenta que os bancos de dados estão cada vez mais indispensáveis na vida da sociedade atual, pois estão envolvidos em diversas atividades como “quando vamos ao banco depositar ou retirar dinheiro, acessamos uma biblioteca virtual para procurar um livro, ou compramos um produto em um site”. Em concordância, Elmasri e Navathe (2011) sustentam que, atualmente, os sistemas de banco de dados são essenciais em nossa vida, pois, a todo momento, estamos nos conectando a algo que está ligado a isso, como, por exemplo, realizar uma compra online. Para isso, é necessário acessar a base de dados da loja, que garante a disponibilidade do produto, as características, entre outras informações, e isso tornou-se tão habitual que, constantemente, acessamos o tornou-serviço de banco de dados tornou-sem nos darmos conta. Como afirma Amaral (2016, p. 8):
Se há algumas décadas tínhamos mainframes e alguns computadores pessoais produzindo dados, hoje dados são produzidos massivamente em redes sociais, comunidade virtuais, blogs, dispositivos médicos, TVs digitais, cartões inteligentes, sensores em carros, trens e aviões, leitores de código de barra e identificadores por radiofrequência, câmeras de vigilância, celulares, sistemas informatizados, satélites, entre outros. Tudo isso produz dados em formatos, velocidades e volumes variados.
Tendo em vista tudo que foi descrito, este trabalho procura encontrar uma solução para a otimização de consultas em banco de dados relacionais que contenham grande número de informações. No que se refere ao banco de dados relacionais, Puga, França e Goya (2013) fundamentam que sua estrutura é formada por tabelas, as quais podem ser relacionadas entre si através de índices (chaves), visando a evitar a redundância de informações, facilitando buscas futuras.
1.1 PROBLEMÁTICA
O grande número de conteúdos existentes nos bancos de dados e o crescente número de dados que são gerados a cada minuto podem dificultar o processamento de consultas no sistema, fazendo com que esse procedimento fique lento e demorado.
Silberschatz, Korth e Sudarshan (1999, p. 381) conceituam que “Os processamentos de consultas são as atividades envolvidas em extrair dados de um banco de dados”, essas atividades traduzem a linguagem de alto nível do banco de dados em expressões que podem ser executadas no nível físico do sistema de banco de dados.
Ainda, sob o ponto de vista de Silberschatz, Korth e Sudarshan (1999), ao realizar uma consulta, seu custo de processamento é estabelecido pelo acesso ao disco, em vez de pelo acesso à memória, e, ao compararmos as duas memórias, podemos dizer que o processamento do disco é lento. Entretanto, há estratégias que podem ser abordadas para melhorar o processamento de uma consulta, como dizem Silberschatz, Korth e Sudarshan (1999, p. 381):
Normalmente, há muitas estratégias possíveis para processar uma determinada consulta, especialmente se a consulta for complexa. A diferença entre uma estratégia boa e uma estratégia ruim, em termos do número de acessos de disco exigidos, é frequentemente significativa, e pode ser de grande magnitude. Consequentemente, vale a pena para o sistema gastar uma quantia significativa de tempo na seleção de uma estratégia boa para processar uma consulta, até mesmo se a consulta for executada somente uma vez.
Sendo assim, visando a esse crescente aumento de número de dados e informações geradas, novas práticas e novos métodos de consultas passaram ser necessárias para que seja possível garantir um tempo de resposta aceitável para a dinâmica de uma organização. Então, o que poderia ser feito para que essa otimização ocorra?
1.2 OBJETIVOS
Esta seção é destinada a apresentar o objetivo geral e os objetivos específicos do trabalho de conclusão de curso.
1.2.1 Objetivo Geral
Otimizar consultas em bancos de dados relacionais utilizando índices.
1.2.2 Objetivos Específicos
Os objetivos específicos são:
a) identificar os tipos de índices mais comuns disponíveis em bancos de dados relacionais;
b) usar a base de dados da empresa Zalf Sistemas, utilizando um problema real para efetuar o experimento;
c) executar um estudo de caso para identificar as situações em que cada tipo de índice tem seu uso recomendado;
d) avaliar os resultados das consultas, utilizando como base o tempo de resposta.
1.3 JUSTIFICATIVA
Tendo em vista o que foi abordado na problemática sobre a grande massa de dados, a escolha de um banco de dados adequado garante efetividade no tempo de resposta de consultas. Barcelar (2012) acredita que os modelos de banco de dados relacionais predominam nos dias atuais. O acesso e a manipulação dos dados no banco relacional tornam-se simples, pois esse modelo utiliza tabelas em sua criação, ou seja, os dados são inseridos e organizados em forma de linhas e colunas logicamente relacionadas. Após as informações estarem inseridos no banco, é possível realizar diversas operações, como seleção, projeção e agrupamento. De acordo com Date (2004, p. 67), o modelo relacional tem “três aspectos principais dos dados: a estrutura de dados, a integridade de dados e a manipulação de dados”.
Um grande exemplo de empresa que implementou um banco dados relacional é a Coca-Cola Bottling Company do Egito. Segundo Baltzan e Phillips (2012), a empresa implementou o sistema buscando a melhoria na precisão dos pedidos em 27%, a diminuição do tempo de atendimento de pedidos em 66% e o aumento das vendas em 20%.
Acredita-se que o modelo relacional consegue lidar com amplos volumes de dados, eliminando redundâncias. Baltzan e Phillips (2012, p. 148) afirmam que um banco de dados relacional oferece vantagens como “maior flexibilidade, maior escalabilidade e desempenho, menos informações redundantes, maior integridade de informação (qualidade), maior segurança de informação.”.
Mas somente a escolha de um banco de dados adequado não garante total efetividade, na compreensão de Elmasri e Navathe (2005), o projeto de um banco de
dados tem uma importância fundamental e nele deve-se considerar prováveis modificações em sua estrutura, ou seja, sintonização (tuning).
A técnica de tuning consiste em realizar modificações no projeto físico, reorganizar, alocar os dados e indexar, após a implementação do banco e realização de testes. Caso o banco de dados continue evoluindo, caso problemas de desempenho venham a aparecer, essa técnica segue existindo durante todo o ciclo de vida do banco de dados, possibilitando sua otimização.
Ainda dentro da técnica de tuning, um dos procedimentos utilizados para a otimização de consultas é a criação de índices, uma vez que, ao utilizar esse tratamento, os dados são reorganizados com o propósito de satisfazer com eficácia as consultas realizadas. A criação de índices adicionais também pode acelerar esse processo de recuperação de dados, como abordam Ramarkrishnan e Gehrke (2011):
Um índice é uma estrutura de dados que organiza registros de dados em disco para otimizar determinados tipos de operações de recuperação. Um índice nos permite recuperar de forma eficiente todos os registros que satisfaçam a condições de pesquisa nos campos de chave de pesquisa do índice. Também podemos criar índices adicionais em determinado conjunto de registros de dados, cada um com uma chave de pesquisa diferente, para acelerar operações de pesquisa não suportadas de maneira eficiente pela organização de arquivo usada para armazenar os registros de dados. (RAMARKRISHNAN E GEHRKE, 2011, p. 228)
Corroborando com os pensamentos de Elmasri e Navathe (2005), que afirmam sobre o aumento de velocidade na recuperação de registro após o uso de índices, pois geralmente proporcionam caminhos diferentes de acesso, além de ser possível criar índices múltiplos, já que se pode utilizar campos diversos do mesmo arquivo.
Um banco de dados que contém grandes volumes de informações, muitas vezes tem seus procedimentos sobrecarregados, tornando-se lento. Ao utilizar técnicas tuning, juntamente com o procedimento de indexação, as necessidades de otimização podem ser atendidas. Desta forma, procedimentos, como consultas em um banco de dados, podem ser realizadas com maior velocidade.
1.4 ESTRUTURA DA MONOGRAFIA
Este trabalho é composto por 5 capítulos, sendo que no capitulo 1 são apresentados elementos norteadores desta pesquisa. O capitulo 2 tem como objetivo apresentar uma revisão teórica sobre os temas relacionados com esta pesquisa. O capitulo 3 apresenta o método de pesquisa utilizado. No capítulo 4 são apresentados os elementos relacionados com o experimento, bem com os resultados obtidos. Por fim, no capitulo 5, são apresentadas as conclusões e trabalhos futuros.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo, são abordados os assuntos temas deste trabalho de conclusão de curso, que são: banco de dados, banco de dados relacionais, estrutura de dados, indexação, índice baseado em árvore e índice baseado em hash.
2.1 BANCO DE DADOS
Segundo Elmasri e Navathe (2011, p. 3), “um banco de dados é uma coleção de dados relacionados. Com dados queremos dizer fatos conhecidos que podem ser registrados e possuem significado implícito”. No entendimento de Silberschatz, Korth e Sudarshan (1999), os bancos de dados são estruturas criadas para armazenar grandes volumes de informações, que possuam uma finalidade para com um grupo determinado de usuários. Date (2004) acredita que banco de dados são registros armazenados usados por uma empresa, um conjunto de informações persistentes usados por uma ou mais pessoas.
Elmasri e Navathe (2011), ainda, ressaltam que, muitas vezes, um banco de dados é chamado de minimundo ou universo de discurso, pois eles representam alguma concepção do mundo real. Medeiros (2013) acrescenta que o banco de dados deve ser dinâmico, pois, se há alguma alteração no minimundo, as alterações também devem ser feitas no banco.
Além disso, os bancos de dados têm a característica de possuírem uma coleção lógica de dados com algum significado específico, uma variedade de dados armazenadas aleatoriamente não podem ser chamadas de banco de dados. O’Brien (2004, p. 136), também, defende o mesmo pensamento, afirmando que banco de dados é “um conjunto integrado de elementos de dados relacionados logicamente”.
Medeiros (2013, p. 15) ressalta que “é necessário que um BD tenha uma representação eficiente que possibilite acesso a informações corretas, em tempo hábil”. Há diversas premissas para que um banco de dados tenha um tempo de
resposta rápido. Este trabalho irá abordar a otimização das consultas em bancos de dados relacionais, utilizando índices.
2.1.1 Sistemas gerenciadores de banco de dados
Antes de prosseguir, é importante explanar os sistemas gerenciadores de banco de dados (SGBDs), os quais são softwares que possibilitam o armazenamento e o gerenciamento de informações. Na compreensão de Puga, França e Goya (2013, p. XVIII), “Os SGBDs proporcionam recursos para criar as estruturas de um banco de dados, armazenar e manipular os dados, controlar o acesso aos dados e implementar regras de segurança.”.
Elmasri e Navathe (2005) entendem que um sistema gerenciador de banco de dados tem como propósito tornar os processos de definição, construção, manipulação e compartilhamento de dados menos complicados. No tocante, afirma:
A definição de um banco de dados implica em especificar os tipos de dados, as estruturas e as restrições para os dados a serem armazenados em um banco de dados. A construção de um banco de dados é o processo de armazenar os dados em alguma mídia apropriada controlada pelo SGBD. A manipulação inclui algumas funções, como pesquisas em banco de dados para recuperar um dado específico, atualização do banco para refletir as mudanças do minimundo e gerar os relatórios dos dados. O compartilhamento permite aos múltiplos usuários e programas acessar, de forma concorrente, o banco de dados. (ELMASRI E NAVATHE, 2005, p. 4)
Diante do aspecto segurança, os autores supracitados comentam que um sistema de gerenciamento de banco de dados tem como demais funções a proteção contra falhas e mau funcionamento, a manutenção das informações armazenadas por um longo período, a segurança da informação contra acessos indevidos e a possibilidade de evolução e atualização ao passar dos anos.
Este trabalho irá utilizar o PostgreSQL, o qual é um sistema gerenciador de banco de dados objeto relacional.
2.1.2 Banco de dados relacionais
Segundo Ramarkrishnan e Gehrke (2011), o banco de dados relacional surgiu em 1970 quando uma nova estrutura de representação foi proposta por Edgar Codd, do Laboratório de Pesquisa de San Jose, da IBM. A partir desse momento, diversos SGBDs (Sistemas Gerenciadores de Banco de Dados) com foco no modelo relacional foram desenvolvidos, mudando o cenário comercial. Silberschatz, Korth e Sudarshan (1999), afirmam que o primeiro modelo de banco de dados para aplicações comerciais foi o modelo relacional e atualmente continua sendo usado para inúmeras aplicações. Na compreensão de Takai, Italiano e Ferreira (2005, p. 8), as seguintes necessidades foram significativas para o surgimento do banco de dados relacional: “aumentar a independência de dados nos sistemas gerenciadores de banco de dados; prover um conjunto de funções apoiadas em álgebra relacional para armazenamento e recuperação de dados; permitir processamento exclusivo”.
Diversos benefícios foram apontados para a utilização do modelo relacional, Takai, Italiano e Ferreira (2005), defendem que o modelo relacional apresenta grande flexibilidade para a resolver problemas no nível de criação e implementação da base de dados. Ramarkrishnan e Gehrke (2011), comentam que, logo após sua criação, os bancos de dados relacionais amadureceram, seus benefícios foram amplamente reconhecidos e tornaram-se uma prática padrão para gerenciar dados corporativos.
A arquitetura de um banco de dados relacional é formada por um conjunto de tabelas (relação), as quais possuem ligações entre si. A estrutura da tabela é formada por tuplas (linhas), atributos (colunas) e domínios, que descrevem o tipo de dado que os atributos devem possuir, como contemplam Silberschatz, Korth e Sudarshan (1999, p. 9), “O modelo relacional usa um conjunto de tabelas para representar tanto os dados como a relação entre eles. Cada tabela possui múltiplas colunas e cada uma possui um nome único”. A ligação é realizada através de regras de relacionamentos, que realizam a associação de um ou mais atributos de uma tabela com um ou mais atributos de outra tabela.
Para que essa ligação aconteça, toda tabela tem, ao menos, um atributo que será a chave primária. A chave primária pode ser simples ou composta, e seus
valores são únicos. Quando ela é simples, na tabela, há apenas um atributo que é uma chave, quando composta, dois ou mais atributos são chaves, e é a combinação entre elas que as tornam compostas.
Além da chave primária, um banco relacional possui também chaves estrangeiras, as quais são referenciadas de uma tabela para outra. Na figura 1, pode-se obpode-servar um exemplo de duas tabelas que possuem vínculo, veiculo e pneu, na tabela veiculo, o atributo id_veiculo e cod_veiculo são chaves primárias compostas, na tabela pneu, o atributo cod_pneu é uma chave primária simples. Entretanto, pode-se obpode-servar na figura 1 que, na tabela veiculo, o atributo cod_pneu é uma chave estrangeira, pois ela é referenciada da tabela pneu, dessa forma, é criado o vínculo entre as tabelas.
Figura 1 – Tabelas no banco de dados relacional
Fonte: Autoria própria.
As chaves são importantes não apenas para a criação de relação entre tabelas no banco, mas também para a indexação. Silberschatz, Korth e Sudarshan (2012) entendem que as próprias chaves, primárias e/ou compostas, são índices. A indexação é um tema aprofundado na seção 2.4 deste capítulo.
2.2 TUNING E SELF-TUNING
Como abordado na seção 1.3 desta monografia, a técnica tuning tem como perspectiva otimizar o acesso às informações no banco de dados. Nas palavras de Costa (2006, p. 5), “à realização de alterações nos parâmetros do SGBD ou à criação ou modificação de objetos ou estruturas com o objetivo de obter melhor desempenho, chamamos tuning (ajuste) do banco de dados”. Para colocar essa técnica em prática, é necessário um bom conhecimento de teoria e técnicas de banco de dados, assim como conhecimentos específicos sobre o SGBD que será utilizado.
O ajuste de desempenho durante, o ciclo de vida de cada aplicação de banco não deve demorar para ser realizado. No entendimento de Bryla e Loney (2009), a técnica de tuning ajuda a encontrar e corrigir as falhas que resultam em um desempenho abaixo do esperado.
Com o passar do tempo, o tuning tornou-se uma técnica realizada constantemente em sistemas de banco de dados, com isso, de acordo com Costa (2006), começou-se a pesquisar sobre a técnica de self-tuning. Essa técnica propõe que os próprios SGBDs possam realizar o tuning de maneira autônoma, sugerindo a criação de índices, podendo se auto-ajustar para obter melhor desempenho, alterando automaticamente o tamanho das áreas de memória alocada, entre outras funções. Várias pesquisas foram realizadas nessa área e, atualmente, os Sistemas Gerenciadores de Banco de Dados já incorporam algumas características de auto-ajuste.
2.2.1 Ferramentas de tuning
Algumas ferramentas de tuning têm se destacado entre outras no mercado, mostrando-se eficazes em sua utilização. O Automatic SQL Tuning Advisor (Oracle) e o Index Tuning Wizard do Microsoft SQL Server 2000 (Microsoft) são exemplos disso.
Nas palavras de Ramakrishnan e Gehrke (2011), a Microsoft foi a primeira a implementar uma ferramenta tuning e explanam suas características:
A Microsoft foi pioneira na implementação de um assistente de sintonização integrado com o otimizador de consultas de banco de dados. O Tuning Wizard da Microsoft tem três modos de sintonização que permitem ao usuário ponderar o custo-benefício entre o tempo de execução da análise e o número de configurações de índices candidatas examinadas: fast, medium e thorough, com fast tendo o menor tempo de execução e thorough examinando o maior número de configurações. Para reduzir ainda mais o tempo de execução, a ferramenta tem um modo de amostragem no qual o assistente de sintonização exibe consultas aleatoriamente, a partir da carga de trabalho de entrada, para acelerar a análise. Outros parâmetros incluem o espaço máximo permitido para os índices recomendados, o número máximo de atributos por índice considerado e as tabelas nas quais os índices podem ser gerados. O Index Tuning Wizard da Microsoft também permite tabela scaling, em que o usuário pode especificar um número antecipado de registros para as tabelas envolvidas na carga de trabalho. Isso permite que o usuário planeje o crescimento futuro das tabelas. (RAMAKRISHNAN E GEHRKE, 2011, p. 554).
Bryla e Loney (2009, p. 296) mostram a execução da ferramenta Automatic SQL Tuning Advisor. Com ela, é possível visualizar se o desempenho será maior após os ajustes através de um relatório. Ela nos mostra um resumo de suas tarefas, classificando a carga e procurando maneiras de melhorar o desempenho das atuais instruções. Perez, Dodwal e Soares (2014) definem:
SQL Tuning Advisor é um advisor disponível no tuning pack e leva a entrada das instruções SQL e realiza análises sobre elas. Ele faz 4 tipos de análises sobre as instruções e, em seguida, dá as suas recomendações para o DBA implementar caso o percentual de melhoria for positivo, com base em seus requisitos e os acordos de nível de serviço (SLA).
Além dessas ferramentas apresentadas, é importante lembrar que, atualmente, existem diversas outras no mercado, geralmente, inclusas em sistemas gerenciadores de banco de dados.
2.3 ESTRUTURA DE DADOS
O principal propósito da estruturação de dados é organizar os dados de uma forma inteligente, que facilite o acesso em ocasiões como ao realizar uma busca,
tendo como objetivo tanto a diminuição do tempo de processo como a diminuição do consumo de memória. Cormen (2002) conceitua que:
Uma estrutura de dados é um meio para armazenar e organizar dados com o objetivo de facilitar o acesso e as modificações. Nenhuma estrutura de dados única funciona bem para todos os propósitos, e assim é importante conhecer os pontos fortes e as limitações de várias delas. (CORMEN, 2002, p. 6)
Com essa afirmação, pode-se entender que há diversas maneiras de armazenar os dados, e cada forma diferente apresenta um objetivo específico. Segundo Edelweiss (2009, p. 30), “Para tornar os programas mais eficientes, surgiu a necessidade de serem definidas estruturas de dados mais apropriadas, com a definição de operações eficientes para cada uma delas.”. Dentro desse contexto, Backes (2016) contempla que estrutura de dados é um relacionamento lógico entre dados variados e tem como objetivo a resolução de problemas que venham a ser apresentados, sempre buscando a melhor solução com a maior eficiência.
2.3.1 Estruturas lineares
Estruturas lineares têm como característica organizar elementos do mesmo tipo de maneira sequencial a fim de representar um conjunto de dados preservando a relação de ordem entre os elementos. De acordo com Ascencio e Araújo (2010), quanto a estrutura da lista utiliza um vetor para sua representação, há o uso de endereços já pré-determinados e a ordem linear é determinada pelos índices. Este tipo de representação é conhecido como lista sequencial estática, diferente de quando a estrutura possui além das informações um ponteiro para o próximo elemento, estas se chamam listas encadeadas dinâmicas.
Na sequência são explanados as características de listas sequenciais estáticas e listas encadeadas dinâmicas.
2.3.1.1 Lista sequencial estática
A lista sequencial estática é o tipo mais simples que existe. Essas listas são estruturas de dados organizadas de maneira sequencial e utilizam alocação estática. Segundo Backes (2016), a lista sequencial é estabelecida, utilizando um array, onde o próximo elemento ocupa a posição seguinte.
Os tipos de listas sequenciais estáticas mais conhecidos são a pilha e a fila, e cada uma possui suas particularidades.
A estrutura de dado do tipo pilha tem seu conceito de entrada e saída de dados, denominada como LIFO (Last In First Out), ou seja, os dados na estrutura pilha se organizam de uma forma em que o último dado inserido é o primeiro a ser removido, como mostra a figura 2:
Figura 2 – Pilha
Fonte: Ricardo Farias
Já a fila possui sua estrutura considerada como FIFO (First In First Out), que significa “primeiro a entrar, primeiro a sair”, ou seja, o primeiro elemento que é inserido será o primeiro a ser retirado. Nesta abordagem, os elementos são adicionados ao fim da fila e removidos do início. A figura 3 mostra exemplos de inserção e remoção em uma fila.
Figura 3 – Fila
Fonte: Ricardo Farias.
Segundo Ascencio e Araújo (2010), na fila os elementos são inseridos sempre na posição seguinte, mantendo assim o encadeamento e a estrutura linear. Nessas estruturas, não é possível adicionar ou remover em posições específicas as operações sempre ocorrem nas extremidades.
2.3.1.2 Lista encadeada dinâmica
A lista encadeada dinâmica, diferentemente das listas sequenciais estáticas, tem seus elementos não necessariamente armazenados de forma sequencial na memória. Então, para a ordem lógica ser mantida entre os elementos, sua estrutura possui um funcionamento semelhante ao de um vetor com a possibilidade vantajosa de deter uma maior economia de espaço na memória. As listas são compostas por nodos que, por sua vez, contêm ponteiros indicadores do próximo nó, como afirmam Celes, Cerqueira e Rangel (2004).
Para Goodrich e Tamassia (2013), uma lista encadeada “é uma coleção de nodos que juntos formam uma ordem linear”. Os nodos, ou nó, são objetos que armazenam uma referência para as informações e outra para outro nó, chamado next. A estrutura de nó fica localizada em uma única célula de memória, fazendo com que ele se assemelhe com uma struct. Na figura 4, pode-se observar que o nó é formado de dois campos, sendo o primeiro deles a informação guardada e o segundo que é o ponteiro para o nó seguinte. O ponteiro final sempre será Null.
Figura 4 – Lista encadeada
Fonte: Autoria própria
As listas encadeadas podem ser simplesmente encadeadas, simplesmente encadeadas com descritor, duplamente encadeadas ou duplamente encadeadas com descritor. O descritor permite armazenar informações referenciando o ponteiro do início da lista, do final e o tamanho da lista. A lista duplamente encadeada possui referência tanto ao próximo nó quanto ao anterior, como mostra a figura 5.
Figura 5 – Lista duplamente encadeada
Goodrich e Tamassia (2013) acrescentam que os nós de uma lista encadeada não possuem indexação, deste modo, ao examinar um nó individualmente, não é possível dizer em qual posição ele se encontra. Ao contrário de um vetor, o qual possui índices e tamanho fixo, uma lista encadeada não possui tamanho fixo pré-estabelecido, e, sim, um tamanho proporcional a quantidade de elementos que possui.
Na seção subsequente, recursos de desempenho, baseados em índices, que é foco do trabalho, serão aprofundados
2.4 INDEXAÇÃO
O ponto de entrada para tabelas com otimização de memória é chamado de índice. A leitura das linhas das tabelas requer um índice para localizar os dados na memória. A indexação é uma estrutura de acesso que tem a finalidade de melhorar o desempenho na recuperação de registros arquivados.
Em concordância, Inácio (2013) diz que a criação dos índices aumenta a performance de consultas. A Microsoft (2018) acrescenta que os índices são usados para acessar dados com eficiência nas tabelas e que a utilização correta dos índices pode aumentar significativamente o desempenho de uma consulta. No entender de Silberschatz, Korth e Sudarshan (2012), a indexação aumenta a performance não apenas da consulta, mas também para o processamento eficiente de transações e atualizações e são importantes para a restrição de integridade. Ramakrishnan e Gehrke (2008, p. 228) fundamentam:
Um índice é uma estrutura de dados que organiza registros de dados em disco para otimizar determinados tipos de operações de recuperação. Um índice nos permite recuperar de forma eficiente todos os registros que satisfaçam a condições de pesquisa nos campos de chave de pesquisa do índice. Também podemos criar índices adicionais em determinado conjunto de registros de dados, cada um com uma chave de pesquisa diferente, para acelerar operações de pesquisa não suportadas de maneira eficiente pela organização de arquivo usada para armazenar os registros de dados.
Silberschatz, Korth e Sudarshan (2012) chamam a atenção que os índices podem reduzir a sobrecarga das pesquisas nos registros de um arquivo.
Ramakrishnan e Gehrke (2008) esclarecem que o arquivo de registro é uma concepção importante em Sistemas Gerenciadores de Banco de Dados (SGBD). Sua implementação acontece pela camada de métodos de acesso e arquivos do código, ele suporta diversos tipos de operações, pode ser gerado, deletado, ter registros inseridos, excluídos ou alterados, suportar varreduras, as quais tornam possível a recuperação de todos os registros de um arquivo, um a um.
Segundo a Microsoft (2016), cada tabela que desejasse otimizar deve conter ao menos um índice. Caso uma tabela tenha uma chave primária, ela automaticamente terá um índice, pois cada restrição da chave primária cria um índice e, para a otimização de memória durável de uma tabela, a chave primária é pré-requisito. Para Silberschatz, Korth e Sudarshan (2012), os índices podem ser criados automaticamente pelo banco, entretanto as escolhas de quais manter, quais criar, ou quais excluir devem ser decididas pelo administrador, a fim de manter controle e diminuir o custo de espaço dos índices. Diversos sistemas de banco de dados também oferecem meios de caracterizar qual tipo de índice é desejado usar, como por exemplo, os índices baseados em árvore binária ou os baseados em hashing.
2.4.1 Índice baseado em árvore B
Silberschatz, Korth e Sudarshan (2012) citam exemplos de alguns índices baseados no padrão GiST, que são as árvores B e R. A indexação baseada em arvore B organiza os dados de forma ordenada pelo valor de sua chave de pesquisa e possui uma estrutura hierárquica, que direciona as pesquisas às páginas certas das entradas de dados. Ramakrishnan e Gehrke (2008).
2.4.1.1 Árvore B+
Segundo Silberschatz, Korth e Sudarshan (2012), o índice baseado em árvore B+ é capaz de aumentar o desempenho de arquivos volumosos que possuem uma sequência indexada. Ele possui o modelo de uma árvore balanceada, ou seja, cada caminho possui o mesmo tamanho. Além disso, o tamanho do caminho da raiz até a última camada de folhas é menor, em comparado a estrutura de qualquer outra árvore binária balanceada, isso é o que o torna mais ágil, pois exige menos acesso ao disco para localizar registros. Nas palavras de Ramakrishnan e Gehrke (2008, p. 258):
A árvore B+ é uma estrutura de índice que assegura que todos os caminhos da raiz até́ uma folha em determinada árvore tenham o mesmo comprimento, ou seja, a estrutura está́ sempre balanceada em altura. Encontrar a página folha correta é mais rápido do que a pesquisa binária das páginas em um arquivo ordenado porque cada nó não folha pode acomodar um número muito grande de ponteiros de nó, e a altura da árvore raramente é maior que três ou quatro na prática. A altura de uma árvore balanceada é o comprimento de um caminho da raiz até uma folha.
A indexação por árvore B+ não só contribui para a otimização de consultas como também pode ser utilizada para organizar os registros de um arquivo. Na figura 6, observa-se a estrutura e organização de uma árvore B+, os nós folha estão destacados em amarelo, enquanto os azuis são os nós internos.
Figura 6 – Arvore B+
Silberschatz, Korth e Sudarshan (2011) acrescentam que, apesar das vantagens que a árvore B+ possui para a realização de consultas, ela possui dificuldades ao realizar tarefas de inserção ou exclusão. Essas tarefas se tornam mais complicadas por conta do número de operações exigidas.
2.4.2 Índice baseado em hashing
Os índices baseados em hash possuem as estruturas dos registros agrupados em buckets. Ramarkrishnan e Gehrke (2011) conceituam que “um bucket consiste em uma página primária e, possivelmente, páginas adicionais conectadas em uma cadeia”. Uma coleção de buckets organizados em uma matriz nada mais é que um índice de hash. Uma função de hash mapeia chaves de índice para buckets correspondentes no índice de hash. Na figura 7, é possível visualizar como é formada uma estrutura de índices de hash.
Figura 7 – Estrutura de índice de hashing
Fonte: Microsoft
Microsoft (2018) fundamenta que a função de hash usada para índices de hashing tem as seguintes características: partir de três critérios, a saber:
a) a mesma chave de índice sempre é mapeada para o mesmo bucket no índice de hash, ou seja, a função de hash é determinística;
c) o SQL Server tem uma função de hash que é usada para todos os índices de hash;
d) a função de hash é equilibrada, o que significa que a distribuição de valores de chave do índice sobre buckets de hash geralmente segue uma distribuição de Poisson.
A distribuição de Poisson não é uma distribuição uniforme. Os valores de chave de índice não são distribuídos uniformemente nos buckets de hash. Por exemplo, uma distribuição de Poisson de n chaves de índices distintos sobre n, resulta em aproximadamente um terço de buckets vazios, um terço de buckets que contêm uma chave de índice de buckets de hash e outro terço contendo duas chaves de índice. Um número pequeno de buckets conterá mais de duas chaves.
Pedro Pisa (2012) aponta que, se por acaso, duas chaves de índice forem mapeadas para o mesmo bucket de hash, haverá uma colisão de hash e o desempenho das operações de leitura poderá ser afetado, se houver um número grande de colisões de hash.
Segundo Raghu Ramakrishnan e Johannes Gehrke (2011), a estrutura de índice de hash na memória consiste em uma matriz de ponteiros de memória. Cada bucket é mapeado para um deslocamento nesta matriz. Cada bucket na matriz aponta para a primeira linha desse bucket de hash. Cada linha no bucket aponta para a próxima linha, resultando em uma cadeia de linhas para cada bucket de hash.
3 MÉTODO
Método ou metodologia é a realização de um estudo que tem como intuito investigar a verdade com base em uma proposta apresentada. Na compreensão de Henriques e Medeiros (2017), a metodologia “é um instrumento, uma forma de fazer ciência, que cuida dos procedimentos, das ferramentas, dos caminhos da pesquisa. O método científico consiste na lógica para justificar ou rejeitar um conhecimento”.
Para Azevedo (2009, pg. 10), o método científico é uma forma de testar novas ideias, fazer questionamentos e encontrar respostas, as quais são obtidas seguindo as seguintes etapas:
a) observação – observam um fato, reconhecem nele um problema e buscam solucioná-lo;
b) pesquisa bibliográfica – reúnem informações sobre o assunto; c) hipótese – a partir das informações coletadas, procuram explicar o problema;
d) experiências – planejam e realizam experiências para confirmar ou negar suas hipóteses;
e) conclusão – tiram conclusões sobre o que descobriram nas experiências e aplicam-nas para dar resposta ao problema.
No entendimento de Henriques e Medeiros (2017), a metodologia é fundamental para que se consiga adquirir o pensamento crítico sobre o que foi feito e o que ainda poderá ser realizado.
Esta seção irá descrever o tipo de pesquisa a ser realizado neste trabalho, as atividades metodológicas, os objetivos de estudo, as delimitações e o cronograma para a sua realização.
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA
Quanto à caracterização do tipo de pesquisa, é importante ressaltar que a proposta do estudo é ampliar o conhecimento acerca da otimização de consultas em
bancos de dados relacionais. Neste sentido, a natureza deste estudo caracteriza-se como pesquisa aplicada, que é aquela que serve para resolver um problema específico. Conforme Gil (1999, p. 43), “tem como característica fundamental o interesse de aplicação, utilização e consequências práticas dos conhecimentos. Está voltada para interesses e verdades locais.
Nesta pesquisa, os problemas costumam ser mais específicos, definidos e resolvidos de maneira concreta pelo investigador, havendo uma relação imediata entre o problema real e o problema abordado na pesquisa, Santo (1992).
3.2 ABORDAGEM METODOLÓGICA
Em relação à abordagem metodológica do problema, este estudo é considerado uma pesquisa qualitativa, pois utiliza técnicas de dados como a observação participante, a pesquisa bibliográfica, pesquisa documental, pesquisa ação, entre outros, como abordam Henriques e Medeiros (2017), citando Sampieri, Collado e Lucio (2013, p. 33):
Geralmente, essas atividades servem para primeiro descobrir quais são as perguntas de pesquisa mais importantes e, depois, para aprimorá-las e respondê-las. A ação indagativa se move de maneira dinâmica em ambos os sentidos: entre os fatos e sua interpretação, e é um processo mais “circular” no qual a sequência nem sempre é a mesma, ela varia de acordo com cada estudo específico.
Neste tipo de abordagem, é possível criar perguntas e hipóteses a qualquer momento, ou seja, antes, durante e depois da coleta e da análise dos dados. Nas palavras de Sampieri, Collado e Lucio (2013, p. 33), a abordagem qualitativa também utiliza coleta de dados, mas não há medição numérica “para descobrir ou aprimorar perguntas de pesquisa no processo de interpretação”. Segundo Gil (1999), o ambiente natural é a fonte direta para coleta de dados e o pesquisador é o instrumento chave.
3.3 DESCRIÇÃO DO OBJETO DE ESTUDO
Concernente aos objetivos, esta pesquisa pode ser considerada exploratória. Uma pesquisa exploratória busca conhecer melhor a problemática apresentada e sobre o assunto.
Na compreensão de Gil (1999, p. 43):
A pesquisa exploratória tem como finalidade desenvolver, esclarecer e modificar conceitos e ideias, tendo em vista, a formulação de problemas mais precisos ou hipóteses pesquisáveis para estudos posteriores. Habitualmente envolvem levantamento bibliográfico e documental, entrevistas não padronizadas e estudos de caso.
Cervo, Bervian e Da Silva (2007) consideram que os objetivos da pesquisa exploratória é a familiarização com o assunto e o alcance de novas percepções e ideias. Nela é realizada a descrição de situações em que o pesquisador deseja descobrir relações presentes. Em última análise, a pesquisa exploratória requer um planejamento flexível, que possibilite observações de diferentes pontos de vista sobre a problemática.
3.4 PROCEDIMENTOS TÉCNICOS
No que se refere aos procedimentos técnicos, esta pesquisa pode ser classificada em bibliográfica por utilizar material já publicado, constituído basicamente de livros, artigos, periódicos e informações disponibilizadas na internet. Corroborando com o pensamento de Gil (1999), caracteriza-se, também, como documental por utilizar documentos como, por exemplo, relatórios de empresa. E, ainda, esta pesquisa é considerada um estudo de caso, pois “consiste na coleta direta de informações no local em que acontecem os fenômenos; é o que se realiza fora do laboratório, no próprio terreno das ocorrências”, contempla Silva (2010, p. 57).
Quanto à coleta de dados, sua operacionalização ocorre através de leituras de bibliografias, tais como livros, artigos, revistas, documentações para embasar a
fundamentação teórica; documentos disponibilizados pela empresa estudada para identificar a origem do custo temporal ao realizar uma consulta no banco de dados; observação às formas de realizar consultas da empresa objeto do estudo de caso, sendo que a observação pode ser definida como uso dos sentidos com a finalidade de adquirir conhecimentos do cotidiano, sendo que a observação participante tende a utilizar formas não estruturadas, e o observador assume papel de membro do grupo, como explana Gil (1999).
No que tange a análise e interpretação de dados, considerando que a pesquisa é voltada à otimização de consultas em banco de dados relacionais utilizando índices, a fim de apresentar propostas de melhorias, analisam-se os custos de uma consulta em um determinado conjunto de tabelas, a forma como a consulta está sendo realizada e os índices que estão sendo buscados. Tal análise busca apresentar pontos deficitários do gerenciamento de consultas e propor aprimoramentos com base nos conceitos estudados. Na concepção de Gil (1999, p. 168):
A análise tem como objetivo organizar e sumariar os dados de forma tal que possibilitem o fornecimento de respostas ao problema proposto para a investigação. Já a interpretação tem como objetivo a procura do sentido mais amplo das respostas, o que é feito mediante sua ligação a outros conhecimentos anteriores obtidos.
Em suma, para este estudo foi realizada pesquisa em bibliografias com assuntos relacionados ao estudado, considerando os mais relevantes para usá-los como fonte de pesquisa, bem como considerá-los para a sugestão de ações na empresa estudada. Além disso, será realizado pesquisa em campo para análise documental e consequente levantamento de informações relevantes na empresa para possibilitar o estudo e as sugestões.
3.5 ETAPAS METODOLÓGICAS
A elaboração deste trabalho de conclusão de curso será realizada respeitando as seguintes etapas:
a) definição do problema: nesta etapa, foi realizada uma busca de possíveis situações que possam ser resolvidas em banco de dados relacionais. Após a realização da pesquisa, a escolha da problemática referente ao tempo de processamento de consulta foi definida;
b) definição da proposta da solução: com a problemática definida, a realização de uma investigação sobre possíveis formas de solucionar o problema foi realizada. Deste modo, a utilização de índices para otimização de consultas foi definida como proposta de solução;
c) definição do experimento: o experimento será realizado em consultas de bancos de dados relacionais;
d) revisão bibliográfica: nesse momento a pesquisa de informações sobre o conteúdo foi efetuada, a pesquisa abrangeu livros, artigos, periódicos online e sites na internet sobre o assunto supracitado;
e) definição do domínio de aplicação: o experimento será aplicado como estudo de caso na empresa Zalf Sistemas, a qual trabalha com um sistema de banco de dados relacional e possui tabelas que requerem tempo de seleção demasiadamente alto;
f) busca de consultas problemáticas: a busca de consultas problemáticas será realizada no banco de dados, citado à cima, e, após prévia análise, serão otimizadas;
g) busca de referencial teórico para melhoria de desempenho: a este propósito será efetuada uma pesquisa sobre assuntos focados na melhoria de desempenho que será aplicada;
h) avaliação referente ao que será aplicado: em suma, a escolha do que será aplicado para que a problemática seja resolvida será escolhida;
i) execução do experimento: a realização do experimento acontecerá neste estágio, neste momento, a teoria será colocada em prática;
j) testes de desempenho: verifica-se, então, o desempenho obtido, após a execução do experimento;
k) quadro comparativo: após o teste de desempenho, um quadro comparativo será criado para que seja possível visualizar as melhorias de desempenho;
l) apresentação e avaliação dos resultados: por fim, os resultados serão apresentados e avaliados.
Figura 8 – Fluxograma
Fonte: Autoria própria.
Em última análise, na figura 8, pode-se observar o fluxograma das etapas metodológicas apresentadas.
3.6 DELIMITAÇÕES
Este trabalho aborda apenas modelos relacionais, o banco de dados escolhido para a realização da otimização de consultas utilizando índices é o PostgreSQL, versão 9.4. A Zalf Sistemas possui quatro pilares: gente, frota, segurança e entrega. A otimização será realizada no pilar frota, nas tabelas referentes ao modelo de checklist, presentes no banco de dados da empresa.
Não é foco deste trabalho apresentar um método genérico para otimização de consultas, assim, como, também não é foco tratar questões de infraestrutura, tais como: rede, troca de hardware, troca de servidor, troca de demais softwares, entre outras. Também, não é foco deste trabalho a reestruturação do banco de dados utilizado atualmente.
4 ESTUDO DO CASO
O estudo apresentado, a seguir, trata da otimização das consultas de banco de dados no sistema utilizado pela empresa do caso, repercutindo no cenário as percepções dos gestores acerca dos resultados apresentados.
Num primeiro momento, far-se-á uma descrição do ambiente organizacional estudado, seguido de análise na perspectiva da modelagem de dados, com proposta relacionada à utilização de índices e a verificação do ganho de produtividade, oriundo da otimização no tempo de consulta. A seguir, são apresentadas análises e os resultados da utilização de índices no banco de dados da companhia.
4.1 AMBIENTE ORGANIZACIONAL
A entidade, objeto deste estudo, é uma empresa fundada em janeiro de 2016. Caracterizada como uma empresa de tecnologia da informação, a Zalf Sistemas conta atualmente com nove pessoas em sua equipe. Os treinamentos são feitos pelos responsáveis dos setores com seus respectivos membros de equipe.
Os gestores atuam diaria e diretamente com os colaboradores, sendo que esta aproximação é apontada como facilitador ao cumprimento das tarefas, na administração de conflitos e na elaboração de produtos com qualidade.
O ambiente de desenvolvimento é democrático, todos os níveis hierárquicos opinam, e a decisão final é influenciada com base nessas opiniões. A Zalf Sistemas utiliza como metodologia de desenvolvimento o Scrum, que é um método ágil em que os projetos são divididos em ciclos de desenvolvimentos chamados de Sprints que podem ter duração de duas a quatro semanas (Figura 9).
Figura 9 – Metodologia Scrum
Fonte: https://www.desenvolvimentoagil.com.br/scrum/.
As funcionalidades, correções e alterações que devem ser desenvolvidas são mantidas em uma lista de pendências denominada Backlog. A duração da Sprint na Zalf Sistemas, geralmente, é de três semanas. No início de cada uma delas, é realizado o seu planejamento, momento que é escolhido quais tarefas sairão do Backlog e farão parte do ciclo de desenvolvimento. A cada escolha, é realizada a estimativa do peso que a tarefa terá dentro da Sprint. Este peso é chamado de Task Point, com ele, é possível estimar como está a produtividade da equipe. Dentre as tarefas escolhidas há os Goals, que são as tarefas prioritárias da Sprint.
Todos os dias é realizada uma reunião de quinze minutos para deixar toda a equipe inteirada sobre o andamento das tarefas. Nessa reunião, cada membro da equipe resume o que fez no dia anterior e o que pretende realizar naquele dia. É, nesse momento que as tarefas são movidas de “to do” (tarefas que estão esperando para serem realizadas) para “in progress” (tarefas em progresso), depois de “in progress” para “under review” (quando a tarefa é muito complexa e necessita que outra pessoa faça uma revisão) e, então, finalmente para “done” (tarefas finalizadas).
Ao final de cada Sprint, a equipe de desenvolvimento apresenta o Review para todos os colaboradores, onde exibem as novidades e tudo que foi realizado. Após a Review, a equipe de desenvolvimento se reúne, à parte, e faz uma retrospectiva
para apontar o que achou bom no ciclo de desenvolvimento, quais pontos podem melhorar e o que tem que mudar.
O acompanhamento da Sprint ativa é feito tanto em um quadro, onde se tem uma ampla visão de tudo que está acontecendo quanto na ferramenta Jira, que é uma ferramenta de gerenciamento e organização de projetos, onde se pode rastrear tudo que já foi realizado, acompanhar o que está sendo feito, priorizar e delegar as atividades, emitir relatórios, dentre outras funcionalidades.
A Zalf Sistemas tem como seu principal produto o ProLog, que é um aplicativo que possibilita o gerenciamento e realização de diversas atividades relacionadas a operações de transportes. Os dados são armazenados em um modelo relacional utilizando o PostgreSQL. Na seção subsequente, serão apresentadas informações sobre o sistema de banco de dados utilizado.
4.1.1 PostgreSQL
O PostgreSQL é um sistema de banco de dados de código aberto que surgiu por volta de 1986 como parte de um projeto chamado Postgres da Universidade da Califórnia. Durante esses mais de 30 anos de desenvolvimento, ganhou força e notoriedade por ter sua arquitetura considerada confiável, íntegra, ter um conjunto grande de recursos e uma comunidade dedicada sempre em busca de soluções inovadoras.
De acordo com o site postgresql.org (2018), o PostgreSQL é um SGBD objeto-relacional que usa e estende a linguagem relacional. Possui diversos recursos que possibilitam o armazenamento e segurança das mais diversas e complicadas informações, independentemente de qual seja o tamanho do conjunto de dados, e pode ser executado nos principais sistemas operacionais.
Entre seus principais recursos estão:
a) tipos de dados: o PostgreSQL abrange os mais diversos tipos de dados, como por exemplo: primitivos (integer, boolean, String), estruturados (data, hora, matriz), documento (JSON, xml), geometria (ponto, triangulo, circulo), personalização (tipos personalizados, composições);
b) integridade de dados: permite que condições sejam aplicadas aos atributos, como: não nulo (not null), único (unique), criação de chaves primárias e estrangeiras, restrição de exclusão, além de bloqueios explícitos ou consultivos;
c) desempenho: possibilita a criação de indexação baseada em árvore binária, indexação avançada como GiST e GIN, transações e transações aninhadas, controle de múltiplas versões, paralelização de consultas de leitura, particionamentos de tabelas, planejadores e otimizadores de consultas sofisticadas e isolamentos de transações incluindo Serializable;
d) confiabilidade e recuperação: o PostgreSQL possui registros de
write-ahead, replicações assíncrona, síncrona e lógica, recuperação por point-in-time, standby ativo e espaços de tabela;
e) segurança: quanto à segurança, seu sistema tem diversos tipos de
controle de acesso, e a segurança pode ser realizada por nível de coluna e linha. Além de possuir autenticação GSSAPI, SSPI, LDAP, SCRAM-SHA-256, entre outras;
f) extensibilidade: tem a possibilidade de conectar-se a outros bancos de
dados, trabalha com linguagens procedurais como Python e suas extensões fornecem funcionalidades adicionais;
g) internacionalização: o PostgreSQL contém suporte para caracteres
internacionais através de agrupamentos de UTI e possui pesquisa de texto completo.
Este sistema gerenciador de banco de dados procura sempre estar de acordo com o padrão SQL, ele atende pelo menos 160 dos 179 recursos obrigatórios e, até o momento, é o único que atende as conformidades com o Core 2011. Além disso, segundo o site “O PostgreSQL, provou ser altamente escalável, tanto na grande quantidade de dados que pode gerenciar quanto no número de usuários simultâneos que pode acomodar.
A seguir, informações sobre o sistema ProLog serão apresentadas.
4.1.2 ProLog
O ProLog surgiu com a intenção de automatizar as operações realizadas e diminuir as burocracias dos processos, tornando-os mais modernos, rápidos e
eficientes. O sistema pode ser integrado ao sistema de gestão empresarial do cliente, tornando ainda mais fácil as rotinas e reduzindo o retrabalho no lançamento de informações.
A plataforma abrange diversas funcionalidades divididas entre itens que estão inseridos em quatro grandes pilares: frota, gente, entrega e segurança. No pilar frota, temos os seguintes itens: pneus, veículos, checklist, recapadoras e aferições. É o item checklist que, atualmente, preocupa os gestores da Zalf Sistemas por conta de seu exponencial crescimento.
A seguir a funcionalidade checklist será apresentada com a finalidade de analisar suas particularidades.
4.1.1.1 Checklist
Checklist é uma lista de verificações que serve como instrumento de controle. Em empresas de transporte, é comum realizar checklists de retorno e de saída com a intenção de verificar quais as condições em que o veículo se encontra. Muitas empresas realizam o checklist, utilizando papel. O colaborador anota os pontos que estão e que não estão dentro do esperado, repassa a seu supervisor, que transpõe essas informações para o sistema, e abre uma ordem de serviço para os itens que não estão corretos. Todo esse processo tem um custo de tempo elevado e um grande desperdício com papel e impressões.
Visando tornar o processo mais ágil e sustentável, a Zalf Sistemas desenvolveu a funcionalidade “checklist” para o ProLog. Os checklists são questionários customizáveis a nível de unidade, ou seja, cada unidade de cada empresa pode ter um questionário diferente. Nele, é possível inserir perguntas e alternativas diversas, com imagens que podem ser coletadas pelo usuário ou selecionadas na galeria que o ProLog oferece. Também, é possível selecionar o tipo de veículo e informar se o checklist é de saída ou de retorno.
Esta funcionalidade elimina o uso do papel, diminuindo o impacto ambiental. A realização do checklist torna-se mais rápida e precisa, as informações coletadas são enviadas, em tempo real, para o sistema e ordens de serviços são
abertas, instantaneamente, para itens que estiverem fora do esperado, evitando o retrabalho.
A maior parte das tabelas do checklists são estratificadas para uma view chamada estratificacao_os. Esta view tem como objetivo juntar o máximo de informações disponíveis para conseguir ser flexível e poder ser usada em diversas funcionalidades, como geração de relatórios, consultas de ordem de serviço abertas e realizadas, visualização dos checklists que foram realizados, farol – para realizar o acompanhamento dos veículos, verificado se estão ápitos a sair para a rota, entre outras.
Atualmente, cerca de mil e quinhentos checklists são realizados por dia, isso significa um aumento de quase cento e cinquenta mil linhas na tabela checklist_respostas diariamente e isso está fazendo com que a view fique mais pesada e as funções que acessam ela como farol checklist (figura 10) e ordens de
serviços (figura 11) estão apresentando complicações em sua execução por conta do
Figura 10 – Farol checklist
Figura 11 – Ordens de serviços
Fonte: Aplicativo Prolog.
Como a maioria das tabelas do checklist não possuem chaves primárias únicas, índices, as queries, consultas, tornam-se lentas. Algumas tabelas possuem chaves compostas por uma coluna bigserial, a qual é informada manualmente fazendo com que hajam valores repetidos.
Além das queries e tabelas mal otimizadas, a própria busca no servidor também está mal desenvolvida. A busca realiza uma nova conexão ao banco de dados para cada placa da unidade, e essa busca utiliza a estratificacao_os que, como já mencionado, faz joins com quase todas as tabelas de checklist.
Estes problemas estão levando a funcionalidade farol a parar, quando uma unidade possui muitos checklists já realizados devido ao tempo que a busca leva para ser realizada e a geração de determinados relatórios demorada.
