Utilização dos Métodos Armazenados no SGDB

Moacir Moraes Viana

CESF – Centro de Ensino Superior Fucapi
moacir_viana@vivax.com.br

Resumo

Com o aumento do poder computacional dos microcomputadores, as máquinas clientes passaram a

ter uma performance próxima à dos servidores. Com isso as aplicações começaram a ser divididas,
sendo que parte era executada no servidor, parte era executada nos clientes. O que parecia ser uma
boa idéia, servidor mais “livre”, trouxe também sérios problemas: os processos de instalação e
manutenção tornaram-se atividades extremamente vulneráveis.
Apesar de ser um assunto que ainda gera polêmica, há os que preferem clientes “gordos” e há os que
preferem os clientes “magros”, mas o aspecto principal abordado neste artigo será um meio termo,
através da utilização dos métodos armazenados no servidor.

Palavras-chave: Métodos armazenados. Stored procedure. Functions. Triggers.

 1. Introdução

Um Sistema Gerenciador de Banco de Dados (SGDB) oferece aos seus usuários acesso a
dados e os ajuda a transformar estes dados em informações. Estes sistemas permitem aos usuários
criar, atualizar e extrair informações de suas bases de dados. A maioria dos aplicativos construídos
para este fim é constituída por diversas unidades independentes, cada uma com um repositório de
comandos e procedimentos locais, qualquer alteração na regra de negócio implica na alteração do
código fonte e re-compilação de todo o sistema. Requisições de recursos de rede são constantemente
utilizados por essas aplicações clientes. A dificuldade de manter a segurança das operações em nível
de usuário são complexas e com soluções controladas via programação. Apresentaremos a seguir
algumas sugestões para proporcionar um ambiente capaz de compartilhar os recursos
computacionais a fim de promover uma maneira cooperativa de executar as aplicações dos usuários
finais.

2. Distribuição da Consistência e Integridade dos Dados

A principal vantagem em se colocar todas as regras no banco de dados é que esse mantém a
consistência e integridade dos dados independente da ferramenta de acesso utilizada pelo usuário.
Além disso, as manutenções dessas regras ficam localizadas em um único local, ao invés de ficarem
espalhadas por toda a aplicação ou por diversas aplicações. A programação no servidor traz algumas
vantagens:
• Se muitos programas compartilham um banco de dados e houver funcionalidades,
que lidam com o banco, comuns a eles, então pode-se implementá-las no servidor,
evitando redundância de código[1];
• Caso seja necessário executar várias vezes um grupo de comandos SQL
consecutivos, convém criar um bloco, compilá-lo e armazená-lo no servidor. Isto
trará um evidente ganho de performance, já que serão realizados menos acessos
pela rede[1];
• De uma forma geral, o software de banco de dados é mais estável do que uma
ferramenta de programação, isto é, é mais provável uma determinada empresa
mudar seu front-end do que seu banco de dados.
Apresentaremos a seguir, alguns métodos que podem ser armazenados no banco de dados a
fim de promoverem uma boa solução na manipulação de dados.

3. Stored Procedures

Uma Stored Procedure é um programa compilado e que pode executar comandos SQL. São
geralmente utilizadas em aplicações cliente/servidor, especialmente em transações on-line. Permitem
a manipulação direta dos dados, sem qualquer intervenção do usuário, e sem impor tráfego sobre a
rede. Uma Stored Procedure pode executar vários comandos SQL e retornar um único resultado com
dados relevantes a essa execução, razão para uma integridade transacional. Desta forma, o código
executado na parte cliente efetua somente uma chamada, que é executada no servidor, e recebe o
resultado com dados solicitados. Existem boas razões para utilizar Stored Procedures: integridade
transacional, segurança, além de uma melhor performance obtida em aplicações cliente/servidor e
web com grande processamento transacional on-line, utilizando a lógica da programação no

2
servidor[2]. Caso sejam incluídos comandos SQL tanto dinâmicos como estáticos, os mesmos são
preparados quando o programa é compilado, o que melhora sua performance. Para uma aplicação
cliente/servidor com grande volume de transações e acesso ao banco de dados, o número de
operações de I/O solicitado pela estação-cliente é significativamente reduzido, pois são substituídas
pela chamada à Stored Procedure, a qual, já no servidor, executa todas as operações de I/O relativas
à transação solicitada pela mesma[3]. A utilização desta técnica também proporciona segurança, pois
a aplicação pode ter acesso somente para executar a Stored Procedure, e não ter acesso às diversas
tabelas e bancos de dados para efetuar diretamente a operação pela aplicação. A figura 1 mostra o
esquema de armazenamento de uma stored procedure no bando de dados.

Procedure SET_DATA_ELEICAO
( Arg_codigo_el IN data_eleicao.codigo_el%TYPE )
IS
begin
set transaction read write;
BEGIN
UPDATE data_eleicao set ativo=0 WHERE ativo=1;
UPDATE data_eleicao set ativo=1
WHERE codigo_el=Arg_codigo_el;
EXCEPTION
WHEN OTHERS THEN
ROLLBACK;
raise_application_error(-20000,'Não é
possível setar a data eleição');
END;
COMMIT;
end;

Figura 1 – Stored procedure armazenada no banco de dados

Stored Procedures devem ser usadas sob as seguintes circunstâncias:

• Seu aplicativo executar a mesma consulta várias vezes;
• Se a operação requer o processamento de um grande número de linhas, que
excessivamente são caras em termos de tráfego na rede;
• Mais de um aplicativo precisa acessar a mesma consulta;
• Você precisa acessar uma consulta em um loop;

4. Functions

Enquanto procedure podem receber vários parâmetros de entrada, saída ou entrada-saída,

functions recebem parâmetros de entrada e devolvem um valor em seu nome[1]. Uma grande
vantagem de usar functions é que ela podem ser ativadas a partir de um comando SQL do tipo DML
nas cláusulas where, having, order by em select; values em insert; set em update e where em delete.
Também deve-se observar que quem emitir um comando SQL possuindo uma function e não for o
dono dela, deve possuir privilégios de execução. A figura 2 mostra uma function escrita em PL/SQL.

3
 CREATE FUNCTION ValorEmDolar
( reais IN number, cotacao IN number)
RETURN number
IS
BEGIN
RETURN reais/cotação;
END;

Figura 2 – Function escrita em PL/SQL

5. Triggers

Durante o desenvolvimento de uma aplicação, percebe-se que muitas ações acontecem

como conseqüência de outras. Por exemplo, no caso de um sistema de vendas, ao efetuar uma venda,
seria desejável após sua atualização fazer automaticamente a baixa do estoque de produtos. Uma
Trigger faz exatamente isso, executa unidades de programa automaticamente toda vez que uma
instrução SQL/DML for aplicada a uma tabela específica. Eventos DML que podem acionar as
triggers: DELETE, INSERT ou UPDATE. A figura 2 mostra o esquema de uma trigger.

CREATE TRIGGER next_chaveAluno

BEFORE INSERT on alunos
FOR EACH ROW
DECLARE
novaMatricula number;
BEGIN
SELECT prox_numAluno.NEXTVAL
INTO novaMatricula
FROM dual;
:new.matricula := novaMatricula;
END;

Figura 3 – Triggers acionada quando certos tipos de eventos ocorrem na tabela.

Devemos tomar algumas precauções sobre a implementação das Triggers dentro do banco,
deve-se ficar atento para estes tópicos :

• Não crie triggers que duplique regras já definidas em Constraints do banco[5];

• Alguns bancos recomendam limitar os códigos no máximo em 60 linhas, caso tenha
de criar algo mais complexo recomenda-se criar stored procedure[5];
• Ter cuidado ao criar as Triggers que disparem sob uma instrução UPDATE. Não
pode alterar a tabela porque isso iria disparar a Triggers mais de N vezes no
sistema, podendo ocasionar overflow de memória ou resultados errôneos[5].

4
 6. Por que utilizar Procedures e Triggers?

6.1 As vantagens obtidas na utilização de stored procedures e triggers são várias:

• Eles permitem que o servidor efetue operações complexas em seus bancos de dados
sem envolver o software cliente[4];
• Podem ser compartilhados por todas as aplicações cliente que acessam o banco de
dados. Não precisa programar a mesma regra de negócio dentro de cada aplicação;
• Reduzem tráfego na rede por transferir o processamento mais pesado dos ambientes
das aplicações para o servidor, principalmente para usuários remotos que trabalham
através de uma conexão com um banco de dados muito lenta.
• Tarefas freqüentemente utilizadas são executadas mais rapidamente, pois são
armazenadas e compiladas no servidor.
• Stored procedures permitem que você divida tarefas complexas em módulos menores
e mais lógicos. Podem ser invocados uns dos outros, permitindo que você construa
um conjunto de rotinas padronizadas que são chamadas de diferentes formas[4];
• Stored procedures são muito úteis para efetuar tarefas de processamento periódico e
complexo, tais como fechamento de fim de mês ou uma operação de arquivamento.
Fornecem melhor concorrência entre cliente e o servidor;
• Triggers são executadas automaticamente, assim, podemos utilizá-las para fazer
auditoria sobre o acesso ao banco de dados. São excelentes para replicação de dados;
• Triggers podem controlar a integridade referencial de maneira mais facilitada, já que
pode-se permitir ou não que inclusões, alterações ou exclusões ocorram em cascata;

6.2 Desvantagens de utilizar stored procedures e triggers:

• O desenvolvimento utilizando essa linha de trabalho é muito mais árduo e

demorado;
• As linguagens utilizadas para escrever as “stored procedures” e “triggers” são
proprietárias dos fornecedores, tornando a empresa dependente de único fornecedor,
dificultando a distribuição dos dados em bancos de fornecedores diferentes[2];
• Portabilidade x Eficiência. Será sempre um dilema: portável ou eficiente? O que é
melhor colocar no SGDB e o que é melhor deixar fora?

7. Conclusão

Abordamos neste artigo as vantagens e desvantagens dos métodos armazenados no SGDB.

Entretanto, antes de utilizar os métodos citados, é importante analisar o cenário e a política adotada
de desenvolvimento. O uso desses métodos é uma questão de planejamento e análise, não pode ser
adotado por simples ‘conveniência’. É importante citar que esses métodos precisam ser analisados
por um profissional da área de bando de dados, a fim de que sejam bem utilizadas para proporcionar
funcionalidade e performance em sua aplicação.

5
Referencias Bibliográfica

[1]
Morelli, Eduardo Terra, Oracle 8 – SQL, PL/SQL e Administração, páginas 88-93, 2000.
[3]
http://www.itec.com.br/semanal/NEWSSWdb2domino.htm, acessado em 18/05/2005
[5]
http://www.linhadecodigo.com.br/artigos.asp?id_ac=611&sub=0, acessado em 20/05/2005
[4]
http://www2.fundao.pro.articles.asp?cod=162, acessado em 19/05/2005
[2]
http://www.freecod.com.br/artigos/detalhe.php?s=869473953, acessado em 15/05/2005