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.

4.1.3 Apresentação

A partir desse momento será necessário um maior conhecimento sobre bancos de dados relacionais a fim de que todos os procedimentos e comandos sejam entendidos.

Para que seja possível relatar as mudanças que foram executadas, primeiramente far-se-á necessário uma apresentação de como era a estrutura de tabelas da funcionalidade checklist.

O checklist possuía as seguintes tabelas:

a) checklist: esta tabela continha uma chave primária chamada codigo, e se relacionava com mais 4 tabelas através das chaves estrangeiras: cod_unidade que vinha das tabelas unidade e checklist_modelo, cod_checklist_modelo que referenciava a tabela checklist_modelo, cpf_colaborador que vinha da tabela colaborador e placa_veiculo vinda da tabela veiculo. Além das chaves a tabela checklist tinha outros atributos como: tipo, tempo_realizacao, data_hora e km_veiculo como pode ser visto na figura 12: Figura 12 – Tabela checklist

Fonte: Autoria própria.

b) checklist_perguntas: esta tabela possuía uma chave composta formada pelos atributos cod_checklist_modelo vinda da tabela checklist_modelo, cod_unidade vinda da tabela unidade e checklist_modelo, e codigo que era a chave primária desta tabela. Outros atributos, que podem ser visualizados na

figura 13, são: ordem, pergunta, url_imagem, status_ativo, prioridade, single_choice.

Figura 13 – Tabela checklist_perguntas

Fonte: Autoria própria.

c) checklist_alternativa_pergunta: esta tabela possuía uma chave composta pelos atributos cod_unidade, cod_checklist_modelo e cod_pergunta vindos da tabela checklist_perguntas, codigo que era a chave primária da própria tabela e além disso o atributo cod_unidade também referenciava a tabela unidade. Conforme a figura 14, esta tabela possuía os atributos: alternativa, ordem, status_ativo.

Figura 14 – Tabela checklist_alternativa_pergunta

Fonte: Autoria própria.

d) checklist_respostas: pode-se observar, na figura 15, que a tabela checklist_respostas era formada quase totalmente por chaves compostas, apenas um atributo não fazia parte das chaves: respostas. A chave composta era constituída pelos atributos cod_unidade, cod_checklist_modelo, cod_pergunta,

cod_alternativa referenciados da tabela checklist_alternativa_pergunta e cod_checklist vindo da tabela checklist.

Figura 15 – Tabela checklist_respostas

Fonte: Autoria própria.

e) checklist_ordem_servico: era uma das tabelas mais simples, possuía uma chave composta pelo atributo codigo, que era a chave primária desta tabela, e pelo atributo cod_unidade vinda da tabela unidade. Além disso tinha uma chave estrangeira cod_checklist que vinha da tabela checklist. Na figura 16 os demais atributos, status e data_hora_fechamento, juntamente com toda a estrutura da tabela, podem ser visualizados.

Figura 16 – Tabela checklist_ordem_servico

Fonte: Autoria própria.

f) checklist_ordem_servico_itens: como pode-se observar na figura 17, nesta tabela haviam mais atributos, ela possuía as chaves estrangeiras cpf_mecanico vinda da tabela colaborador, cod_unidade que fazia referencia tanto para tabela unidade quanto para a cheklist_ordem_servico, e cod_os também vinda da tabela cheklist_ordem_servico. Esta tabela não possuía chave primária própria, os atributos cod_pergunta e cod_alternativa não estavam como chave estrangeira das tabelas checklist_perguntas e checklist_respostas mas eram

informados manualmente através de uma consulta. Por fim, a chave composta era formada por cod_os, cod_pergunta, cod_alternativa.

Figura 17 – Tabela checklist_ordem_servico_itens

Fonte: Autoria própria.

g) checklist_manutencao: esta tabela continha as chaves estrangeiras: placa referenciada da tabela veículo, cpf_frota que vinha da tabela colaborador e cod_unidade, cod_checklist_modelo e item vindas da tabela checklist_perguntas. A chave composta é formada pelos atributos data_apontamento, placa e item, como pode-se observar na figura 18 e os demais atributos são: qt_apontamentos, data_resolucao, status_resolucao.

Figura 18 – Tabela checklist_manutencao

h) checklist_modelo: possuía uma chave primária código que formava uma chave composta com a chave estrangeira cod_unidade que vinha da tabela unidade. Os demais atributos que compõem a tabela são: nome, status_ativo (figura 19).

Figura 19 – Tabela checklist_modelo

Fonte: Autoria própria.

i) checklist_modelo_funcao: esta é uma tabela de relacionamento (figura 20), portanto possuía uma chave composta formada pelas chaves estrangeiras: cod_unidade que tinha referência nas tabelas unidade e unidade_funcao, cod_checklist_modelo vinda da tabela checklist_modelo e cod_funcao vinda de uma tabela de relacionamento unidade_funcao.

Figura 20 – Tabela checklist_modelo_funcao

Fonte: Autoria própria.

j) checklist_modelo_veiculo_tipo: por fim, esta é mais uma tabela de relacionamento que possuía as chaves estrangeiras: cod_unidade a qual era referênciada das tabelas unidade, checklist_modelo e veiculo_tipo, cod_modelo vinda da tabela checklist_modelo e cod_tipo_veiculo que vinha da tabela veiculo_tipo. Todas formavam uma chave composta (figura 21).

Figura 21 – Tabela checklist_modelo_veiculo_tipo

Fonte: Autoria própria.

A seguir as figuras 22, 23, 24, 25 e 26 mostram de uma maneira mais ampla o relacionamento das tabelas mencionadas anteriormente:

Figura 22 – Relacionamento das tabelas checklist, chscklist_modelo, checklist_perguntas, checklist_alternativa_pergunta, checklist_respostas