Questão de Banco de Dados — Procedimentos armazenados (Stored Procedures) — Avança SP 2024

Procedimentos armazenados (Stored Procedures)

Gabarito: letra B. Os Stored Procedures (procedimentos armazenados) são conjuntos de comandos SQL armazenados no servidor do banco de dados, que encapsulam operações sobre os dados, escondendo a complexidade das alterações do SGBD das aplicações e permitindo acesso uniforme. Essa é a definição clássica do conceito, conforme a literatura de banco de dados.

O enunciado descreve exatamente o que é um procedimento armazenado: um bloco de código SQL que fica "guardado" no SGBD e pode ser chamado por diferentes aplicações. A ideia central é a modularidade: em vez de cada aplicação repetir a mesma lógica de acesso aos dados, ela chama um procedimento que já encapsula essa lógica. Isso traz vantagens como redução de tráfego na rede (só o nome do procedimento e os parâmetros trafegam), melhoria de desempenho, segurança (o acesso aos dados é controlado pelo procedimento) e manutenção centralizada (qualquer alteração é feita no servidor, sem precisar mudar as aplicações).

Um exemplo prático: imagine um sistema de vendas onde várias aplicações (web, mobile, desktop) precisam inserir uma venda. Em vez de cada uma repetir o comando INSERT com todas as regras de negócio (validações, cálculo de impostos, atualização de estoque), cria-se uma procedure InserirVenda que encapsula tudo. As aplicações apenas chamam CALL InserirVenda(parametros). Se a regra de negócio mudar, altera-se apenas a procedure, e todas as aplicações passam a usar a nova regra automaticamente.

A distinção importante aqui é entre procedimentos armazenados e triggers. Enquanto os procedimentos são executados explicitamente quando chamados por uma aplicação ou usuário, os triggers (gatilhos) são executados automaticamente pelo SGBD em resposta a eventos como INSERT, UPDATE ou DELETE. O enunciado fala em "encapsular conjuntos de operações" e "permitir que aplicações possam acessar o SGBD de maneira uniforme" — isso é característica de procedimentos, não de gatilhos, que são reativos e não são chamados diretamente pelas aplicações.

A pegadinha da banca está em confundir o candidato com Triggers (alternativa A), que também são procedimentos armazenados, mas com a característica de serem acionados automaticamente por eventos, e não chamados diretamente pelas aplicações. O texto do enunciado deixa claro que as aplicações "fazem o acesso ao banco por meio deles", ou seja, há uma chamada explícita — o que é típico de Stored Procedures.

Guarde a fronteira: procedimento = chamado explicitamente (via CALL ou EXEC); trigger = disparado automaticamente por um evento. É exatamente nessa distinção que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Triggers (gatilhos) são procedimentos armazenados no banco de dados, mas com uma diferença crucial: são acionados automaticamente pelo SGBD sempre que ocorre um evento específico (como INSERT, UPDATE ou DELETE) em uma tabela. Eles não são chamados diretamente pelas aplicações — pelo contrário, são disparados de forma reativa. O enunciado fala em "aplicações que fazem o acesso ao banco por meio deles", o que indica uma chamada explícita, característica de Stored Procedures, não de Triggers.

Alternativa B — ✅ Correta ⟵ GABARITO

Stored Procedures (procedimentos armazenados) são exatamente o que o enunciado descreve: conjuntos de comandos SQL armazenados no servidor do banco de dados, que encapsulam operações sobre os dados. Eles permitem que as aplicações acessem o SGBD de maneira uniforme, chamando o procedimento em vez de repetir a lógica de acesso. Isso proporciona modularidade, redução de tráfego de rede, segurança e manutenção centralizada — todas as características citadas no texto.

Alternativa C — ❌ Incorreta

Transactions (transações) são unidades lógicas de trabalho que agrupam uma ou mais operações de banco de dados (leituras e escritas) que devem ser executadas de forma atômica, garantindo as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade). Elas não são programação modular nem encapsulam operações para acesso uniforme das aplicações — são um mecanismo de controle de concorrência e consistência, não um recurso de programação.

Alternativa D — ❌ Incorreta

ALTER FUNCTIONS não é um conceito padrão em banco de dados. O comando ALTER é usado para modificar a estrutura de objetos existentes (como tabelas, views, procedures, funções), mas "ALTER FUNCTIONS" como um conjunto de operações encapsuladas não existe. A alternativa parece uma tentativa de confundir com o comando ALTER FUNCTION, que apenas altera a definição de uma função já criada — não é um mecanismo de programação modular.

Alternativa E — ❌ Incorreta

SETs não é um conceito relacionado a programação modular em banco de dados. O comando SET é usado para atribuir valores a variáveis ou configurar parâmetros de sessão no SGBD (ex.: SET @var = 10). Não encapsula operações sobre dados nem permite acesso uniforme das aplicações ao banco.

Gabarito: letra B