Questão de Banco de Dados — SGBD - Sistema de Gerenciamento de Banco de Dados — Avança SP 2024

Stored Procedures: encapsulamento e uniformidade de acesso

Gabarito: letra B. As Stored Procedures (procedimentos armazenados) são blocos de código SQL pré-compilados e armazenados no SGBD, que encapsulam conjuntos de operações sobre os dados — exatamente o que o enunciado descreve: qualquer alteração no SGBD fica "escondida" da aplicação, que passa a acessar o banco de forma uniforme por meio delas. As demais alternativas não se encaixam: triggers são disparadas automaticamente por eventos, transactions são unidades lógicas de trabalho, e as opções D e E não são conceitos válidos de programação modular em banco de dados.

O que são Stored Procedures? São procedimentos armazenados no banco de dados, escritos em SQL (ou em linguagens procedurais como PL/SQL, T-SQL, PL/pgSQL), que agrupam uma sequência de comandos — consultas, inserções, atualizações, deleções, controle de fluxo — sob um nome. Quando uma aplicação precisa executar aquela lógica, ela simplesmente chama o procedimento, em vez de enviar cada comando SQL individualmente. Isso traz três benefícios centrais:

1. Encapsulamento: a lógica de acesso aos dados fica centralizada no SGBD. Se a estrutura das tabelas mudar, ou se a regra de negócio for alterada, o procedimento é atualizado uma única vez — a aplicação continua chamando o mesmo nome, sem precisar ser modificada. É a "programação modular" citada no enunciado.

2. Uniformidade de acesso: diferentes aplicações (web, desktop, mobile) podem chamar a mesma stored procedure da mesma forma, garantindo que todas usem a mesma lógica de acesso aos dados, com as mesmas regras de validação e segurança.

3. Desempenho e segurança: por serem pré-compiladas, reduzem o tráfego de rede (a aplicação envia apenas a chamada, não o script inteiro) e permitem conceder permissões de execução sem expor as tabelas diretamente.

Vamos comparar com os conceitos vizinhos para fixar:

A pegadinha da banca está em confundir stored procedure com trigger: ambas são objetos de programação no banco, mas a trigger não é chamada pela aplicação — ela é executada automaticamente quando um evento ocorre. O enunciado fala em "aplicações que fazem o acesso ao banco por meio deles" e "permitem que aplicações possam acessar o SGBD de maneira uniforme", o que aponta claramente para a chamada explícita de uma stored procedure.

Outra confusão comum é com transactions: uma transação é uma sequência de operações tratadas como uma unidade indivisível (atomicidade), mas ela não encapsula lógica de negócio nem é um objeto persistente chamado pela aplicação — é um conceito de controle de concorrência e recuperação. Já as stored procedures podem conter transações internamente, mas não se confundem com elas.

Guarde a fronteira: encapsulamento + chamada explícita + uniformidade = stored procedure. É exatamente esse trio que as alternativas tentam embaralhar.

Alternativa A — ❌ Incorreta

Triggers (gatilhos) são procedimentos que o SGBD executa automaticamente em resposta a eventos de manipulação de dados (INSERT, UPDATE, DELETE) em uma tabela. Elas não são chamadas pela aplicação e não servem para "acessar o SGBD de maneira uniforme" — pelo contrário, são disparadas pelo próprio banco, sem intervenção da aplicação. O enunciado descreve um objeto que a aplicação invoca explicitamente, o que não é o caso da trigger.

Alternativa B — ✅ Correta ⟵ GABARITO

Stored Procedures (procedimentos armazenados) são exatamente o que o texto descreve: utilizam programação modular, encapsulam conjuntos de operações sobre os dados, escondem alterações no SGBD da aplicação e permitem acesso uniforme. A aplicação chama o procedimento pelo nome, e o SGBD executa a lógica interna — se algo mudar no banco, só o procedimento é atualizado, e todas as aplicações continuam funcionando sem alteração.

Alternativa C — ❌ Incorreta

Transactions (transações) são unidades lógicas de trabalho compostas por uma ou mais operações de leitura/escrita, que devem ser executadas de forma atômica (tudo ou nada), garantindo consistência, isolamento e durabilidade. Elas não são objetos de programação modular que encapsulam operações de forma persistente, nem são chamadas pela aplicação como uma rotina — são um mecanismo de controle de concorrência e recuperação. O enunciado fala de "programação modular" e "encapsulam conjuntos de operações", o que não se aplica a transações.

Alternativa D — ❌ Incorreta

"ALTER FUNCTIONS" não é um conceito válido em banco de dados. O comando ALTER é usado para modificar a definição de objetos existentes (como ALTER TABLE, ALTER FUNCTION), mas "ALTER FUNCTIONS" como um tipo de objeto ou técnica de programação modular não existe. A banca incluiu essa opção apenas como distrator, misturando o comando SQL ALTER com o conceito de funções — que, aliás, são semelhantes a stored procedures, mas não são o que o enunciado descreve.

Alternativa E — ❌ Incorreta

"SETs" não é um conceito de programação modular em banco de dados. O comando SET é usado em SQL para atribuir valores (ex.: SET @var = 1) ou em operações de conjunto (UNION, INTERSECT, EXCEPT), mas não encapsula operações sobre dados nem é chamado pela aplicação como uma rotina. É um distrator sem relação com o enunciado.

Gabarito: letra B — Stored Procedures são a única alternativa que corresponde à descrição de programação modular, encapsulamento de operações e acesso uniforme ao SGBD.