Uma ferramenta para Correção de Consultas SQL

Corrigir provas sobre SQL é tarefa trabalhosa, pois cada questão pode ser respondida corretamente de diversas formas. Nota-se que, à medida que a complexidade da prova cresce, o número de respostas certas possíveis e, conseqüentemente, a margem de erro do professor, aumentam.

Este artigo apresenta uma ferramenta para correção automática de provas sobre consultas SQL, a qual está sendo desenvolvida pela aluna Cristiane Paula Gomes, do 4º ano do curso de Ciência da Computação da Fundação Educacional Comunitária Formiguense (FUOM), em Formiga-MG, sob orientação da professora Marinalva Soares.

O problema da correção de consultas SQL

Para esclarecer melhor como uma mesma consulta pode ser expressa de várias formas, considere o esquema e a consulta abaixo:

Esquema:

agencia(nome_agencia, cidade, fundos)

conta(nome_agencia, numero_conta, saldo)

depositante(nome_cliente, numero_conta)

Consulta:

“Encontre o nome de todos os clientes que possuem uma conta em qualquer agência localizada em Brooklyn”. Algumas consultas para recuperar essas informações seriam:

1.     Select D.nome_cliente

from agencia A, conta C, depositante D

where A.cidade=”Brooklyn” and

D.numero_conta=C.numero.conta and

C.nome_agencia=A.nome_agencia

2.     Select D.nome_cliente

from Depositante D inner join

conta C on D.numero_conta=C.numero_conta

inner join agencia A on A.nome_agencia=C.nome_agencia

where A.cidade=”Brooklyn”

3.     Select D.nome_cliente

from conta C, depositante D

where C.numero_conta=D.numero_conta and

C.nome_agencia in

(select nome_agencia

from agencia

where cidade=”Brooklyn”)

Além dessas opções, existem várias outras possíveis, não listadas aqui. O objetivo da ferramenta apresentada neste artigo é verificar se as diferentes consultas elaboradas pelo aluno apresentam os resultados esperados pelo professor.

Operação da ferramenta

Atualmente, a ferramenta acessa bases de dados em Access ou InterBase. A aplicação está sendo desenvolvida em Java e utiliza basicamente 2 applets:

·   uma para o professor, com as funcionalidades de criação e manipulação da base de dados, cadastro das turmas, elaboração das provas, gabaritos e geração de relatórios relacionados às respostas do aluno;

·   uma para o aluno, com acesso a todas as questões da prova e que pode formular e executar consultas, visualizar resultados e gerar relatórios com seu resultado final (esse relatório é o mesmo do professor).

A applet do professor possui apenas um modo de funcionamento (local). Desse modo, o professor deverá utilizar a máquina que contém o SGBD no qual serão armazenadas informações como gabaritos e respostas dos alunos. Já a applet do aluno poderá funcionar em dois modos: local ou remoto. Os fatores que mais contribuíram para a elaboração de uma arquitetura que permita a execução em dois modos (acesso local ou remoto ao banco) foram a disponibilidade do SGBD e o transporte do banco de dados pela rede. Os tópicos a seguir apresentam estas alternativas.

Funcionamento Remoto

No modo remoto, todas as operações que envolvem acesso ao banco de dados são executadas no servidor. Isso possibilita usar a ferramenta em ambientes que não permitem a instalação dos SGBDs nas máquinas dos usuários. Outra vantagem é o fato de se eliminar o tráfego causado pelo envio da base de dados na rede, especialmente se a base for muito grande.

Mais especificamente, o aluno acessa a applet que contém a prova, mas a execução das consultas e a correção são realizadas no servidor. Assim, a base de dados e a resposta SQL doprofessor não precisam trafegar pela rede. O aluno apenas submete o código SQL para ser executado no servidor e este apenas devolve a resposta (dados resultantes da busca) para que o aluno possa visualizá-la. A questão só é corrigida definitivamente quando o aluno opta por finalizá-la. Nesse caso, ele submete a resposta atual e as ações de correção e armazenamento de notas são executadas no servidor.

Entretanto, esse modo de operação traz uma desvantagem: a comunicação intensa com o servidor. Os alunos podem executar uma mesma consulta várias vezes (até que obtenham o resultado desejado) e nada impede que os resultados obtidos (as tabelas resultantes são enviadas pela rede a cada execução para que eles possam verificar se suas respostas estão corretas) causem transtornos à rede e ao servidor. A Figura 1 mostra a arquitetura simplificada da ferramenta para utilização remota.

Figura 1 - Arquitetura básica da ferramenta para execução e correção das consultas remotamente

Funcionamento Local

No modo local, a maioria das operações que envolvem acesso ao banco de dados por meio da applet do aluno é executada localmente em um SGBD existente na máquina cliente. Esta solução foi desenvolvida com o intuito de diminuir a utilização da rede e de não sobrecarregar o servidor com o excesso de acessos e consultas feitos pelos alunos. Nesse modo de funcionamento, a freqüência da comunicação com o servidor é menor, pois só existe comunicação efetiva quando as respostas do aluno são armazenadas no servidor. Assim, enquanto o aluno estiver respondendo à prova, as consultas (e a comparação com a resposta do professor) são todas executadas localmente.

Nesse tipo de funcionamento, a base de dados e o gabarito do professor são enviados pela rede para a máquina cliente no momento em que o aluno acessa a applet. Embora o envio da base de dados pela rede possa influenciar no desempenho, normalmente essa base de dados é pequena. A Figura 2 mostra a arquitetura simplificada da ferramenta para utilização local.

Figura 2 - Arquitetura básica da ferramenta para execução e correção das consultas localmente

Examinaremos agora a ferramenta do ponto de vista de seus usuários: professor e aluno.

Applet do professor

Esta applet permitirá ao professor elaborar a prova (Figura 3) e o gabarito. A applet exibe o esquema da base de dados, o cabeçalho da prova, a área de texto para formulação das questões, o valor de cada questão, a área de visualização das questões já cadastradas para a prova e algumas cláusulas da instrução SELECT, que o professor deve marcar para estabelecer os critérios (armazenados no gabarito) de correção da prova. Depois de elaborar a prova, o professor poderá fazer o gabarito na interface (da mesma applet) mostrada na Figura 4.

Figura 3 - Interface a ser usada pelo professor para elaboração das provas

Figura 4 - Interface para elaboração do gabarito

Applet do aluno

A applet do aluno contém um cabeçalho com o seu nome, turma e valor da prova. Todas as questões com seus respectivos valores podem ser visualizadas em um grid. Isso permite que o aluno selecione a questão e formule a resposta na área de texto logo abaixo (Figura 5). O aluno poderá executar a consulta e visualizar os resultados, e a correção só será realizada depois que ele escolher a opção Gravar.

Figura 5 - Interface a ser usada pelo aluno para realizar a prova

Uma vez finalizada a prova, o software permitirá que o aluno tenha acesso a um relatório com informações sobre a correção de sua prova. Esse relatório também estará disponível na applet do professor.

Processo de correção das consultas

A correção da prova é feita por meio da comparação das tabelas resultantes das consultas do aluno e do professor. No caso da execução local, o código SQL do professor é transportado ( junto com a applet) e executado na máquina cliente. Essa operação permite melhorar o desempenho da aplicação, já que o código SQL consiste em um volume de dados bem pequeno, de fácil transporte.

Desse modo, quando o aluno realiza localmente uma consulta, esta é executada pelo SGBD da máquina cliente sobre a base de dados descarregada pela applet. Uma vez selecionada a opção Gravar, a consulta SQL do professor também é executada localmente, e as tabelas resultantes das duas consultas são comparadas. O resultado do aluno é então enviado para o servidor juntamente com suas informações de identificação. Como esse processo é feito a cada questão resolvida pelo aluno, se ocorrerem falhas, o aluno não precisará refazer as questões.

Na execução remota, o processo é bastante semelhante à execução local mas, em vez de interagir com o banco local, o acesso é feito de forma remota no servidor.

Nota: o aluno só tem permissão de acesso “somente leitura” à base de dados local (para executar apenas instruções SELECT). De outro modo, ficaria difícil controlar os resultados da prova, já que o aluno poderia alterar o conteúdo da base.

Entretanto, não basta apenas comparar a igualdade entre as linhas das tabelas resultantes no processo de correção. Existem algumas restrições que devem ser tratadas pela ferramenta para garantir uma correção mais próxima da realidade. Para identificar essas restrições, foi realizada uma análise antes do desenvolvimento da ferramenta. Essa análise revelou quatro cláusulas SQL que podem gerar resultados diferentes (e todos eles corretos): distinct, as, order by e group by.

A maneira como a ferramenta irá reagir a essas restrições é definida pelo professor durante a elaboração de cada questão da prova, nas opções de restrições da Figura 6. Essas cláusulas devem ser marcadas porque podem existir múltiplas respostas corretas e o professor cadastrar apenas uma. Essas restrições são enviadas junto com o gabarito na applet do aluno.

Figura 6 - Opções para correção da prova – ampliação da figura 3

Veja abaixo alguns exemplos de consultas que poderiam retornar resultados diferentes e como a ferramenta deve considerar as respostas:

·   o professor pede uma consulta que retorne x campos e o aluno satisfaz às condições da consulta, porém retorna x+1 campos (a ferramenta deverá considerar correto). Neste caso, a ferramenta remove os campos que estão sobrando no resultado da consulta do aluno antes de iniciar a correção. Feito isso, as tabelas deverão estar equivalentes em número de campos e o processo de correção se iniciará;

·   o professor pede uma consulta e o seu resultado não é ordenado, porém o aluno pode formular a consulta correta e ordenar o resultado. Neste caso, a ordem das linhas na tabela resultante será diferente (a ferramenta deverá considerar correto). Quando isso ocorre, a ferramenta verifica se cada linha da tabela do professor existe na tabela do aluno, não importando a ordem.

·   o professor pede uma consulta que agrupe o resultado por determinado valor e o aluno não agrupa; pode ocorrer a coincidência de na tabela não haver valores para agrupamento e a consulta gerar o mesmo resultado (a ferramenta deverá considerar errado). Neste caso, verificasese o professor, ao elaborar a questão, marcou a opção group by. Caso positivo, é feita também uma busca no código SQL do aluno pela cláusula group by para verificar se foi ou não coincidência;

·   o professor pede uma consulta com eliminação das linhas replicadas (usar o distinct) mas o aluno não usa; entretanto, pode coincidir de o resultado ser o mesmo se na tabela original não houver replicações (a ferramenta deverá considerar errado). A ferramenta se comporta como no caso anterior: verifica se o professor marcou essa opção ao elaborar a questão e busca a cláusula distinct no código SQL do aluno.

Dessa forma, o software tenta cobrir a maioria das questões subjetivas para tornar o resultado da correção o mais próximo possível da realidade.

Conclusão

Este artigo apresentou uma ferramenta para correção automática de provas que contêm consultas SQL. Ela é útil tanto para professores como para alunos. No primeiro caso, o professor não precisa mais se preocupar em corrigir cada consulta individualmente e, muitas vezes, nem em testá-la no SGBD. No caso do aluno, este poderá realizar as provas e ter acesso à correção imediata para testar e aprimorar seus conhecimentos. Além disso, qualquer pessoa que trabalhe com consultas SQL poderá usar essa ferramenta para treinamento.

Quando a ferramenta estiver pronta, pretendemos disponibilizá-la para download no site da faculdade (juntamente com o manual de instrução de instalação e uso).

Cristiane Paula Gomes (eva@facic.fuom.br) Aluna do quarto ano de ciência da computação